Broadcom firmware with iwconfig support not working on WGR614L

15 posts / 0 new
Last post
achilles
achilles's picture
Broadcom firmware with iwconfig support not working on WGR614L

Hi All,

I have ported the broadcom firmware on WGR614L and it was working OK .

Now , I have added support for few commands like iwconfig, iwlist etc to this firmware but with these changes my board is not booting properly and I am getting following error messages when I put this image to my WGR614L through TFTP.

 

CFE for WGR614v8 version: 1.3
Build Date: Fri Apr 20 14:04:44 CST 2007
et0: Broadcom BCM47xx 10/100 Mbps Ethernet Controller 4.138.1.0
Device eth0:  hwaddr 00-01-02-03-04-05, ipaddr 192.168.1.1, mask 255.255.255.0
        gateway not set, nameserver not set
Loading ............................................
Image chksum: 0xBCFDF79C
Calc  chksum: 0x276FF779
Boot program checksum is invalid
Start TFTP server

 

could anybody please help me in this regard.

thanks in advnc, 

bzing2
bzing2's picture
I am guessing you get this

I am guessing you get this problem when you boot for the second time after flashing an image into the device?

The WGR614L stores a length and checksum in flash; note this is separate to the usual checksum stored in the TRX header. There are two possibles causes, that I have seen so far.

1) Linux will occasionally decide to reorganize its MTD mapping, and thus rewrite the TRX header; although it fixes the CRC in the TRX, it doesn't fix this additional checksum and length. Hence the problem your getting. The short solution to this is to correctly align partitions in the CHK image so that the TRX header does not get rewritten. Thats easy enough to do.

2) You have placed an mtd partition over the "magic boot undocumented boot variables". Thus you end up setting them to silly things. I have seen people place jffs2 partitions into this space, and get the above effect.

Take a look atthe ngr-flash utility utility. The description in the download may shead some light on the problem (and the code as well perhaps). You also may glean some stuff about the boot process from Unmasking the Netgear Bootloader and Flash. (Shameless plug I know).

achilles
achilles's picture
bzing2 said:

bzing2 said:
I am guessing you get this problem when you boot for the second time after flashing an image into the device?
The WGR614L stores a length and checksum in flash; note this is separate to the usual checksum stored in the TRX header. There are two possibles causes, that I have seen so far.
1) Linux will occasionally decide to reorganize its MTD mapping, and thus rewrite the TRX header; although it fixes the CRC in the TRX, it doesn't fix this additional checksum and length. Hence the problem your getting. The short solution to this is to correctly align partitions in the CHK image so that the TRX header does not get rewritten. Thats easy enough to do.
2) You have placed an mtd partition over the "magic boot undocumented boot variables". Thus you end up setting them to silly things. I have seen people place jffs2 partitions into this space, and get the above effect.
Take a look atthe ngr-flash utility utility. The description in the download may shead some light on the problem (and the code as well perhaps). You also may glean some stuff about the boot process from Unmasking the Netgear Bootloader and Flash. (Shameless plug I know).

Hi,

Thanx for ur suggestion but I would like to inform you that I am getting this problem when I flash the image and boot the board for the first time only .

If I boot the board with an image which does not contain support for iwconfig it goes ahead without any problem but now if I flash an image with iwconfig support and boot the board , I am getting this problem.

Please let me know what should I do in this case ?

thanks in advance , 

bzing2
bzing2's picture
Hmmm, well perhaps you have

Hmmm, well perhaps you have created a CHK file that has an incorrect checksum. The following suggests that, I was assuming it was the second boot.

Image chksum: 0xBCFDF79C
Calc  chksum: 0x276FF779

If the checksum in the CHK image is incorrect, then iwconfig extensions or not, the kernel is not even being booted, so the changes of it being that are slim.

Could you include a complete boot log, including the bit where you upload a new image. Also the output from the following on your CHK file may be helpful.

hexdump -C -n 58 blah-blah-blah.chk
achilles
achilles's picture
here is the ouput of the

here is the ouput of the "hexdump -C -n 58 image.chk" command :

00000000 2a 23 24 5e 00 00 00 3a 00 01 00 00 a8 41 34 00 |*#$^...:.....A4.|
00000010 b7 f9 84 cb 00 00 00 00 00 3c d0 00 00 00 00 00 |.........<......> 00000020 b7 f9 84 cb 7a ff 0d e3 55 31 32 48 30 37 32 54 |....z...U12H072T|
00000030 30 30 5f 4e 45 54 47 45 41 52 |00_NETGEAR|
0000003a

Could you please tell me where I am messing things up ....

bzing2
bzing2's picture
Well that header does not

Well that header does not contain the same checksums as you original post; however, the header does look correct as far as I can tell.

Ok this is what I think is happening. For what ever reason the checksum of the CHK image is incorrect. This is what causes the "Image chksum" and "Calc chksum" messages. After that the bootloader attempts to load the TRX image anyway, and I believe the "Boot program checksum is invalid" message comes from the fact that the CRC32 in the TRX is also broken! (Which could be either due to checking the TRX or from a CFE boot -raw command).

So what are you using to create the trx images, and the chk images? Also can you send me a trace of you flashing the device as well? So I can see the messages when it writes the image into the flash.

achilles
achilles's picture
This is the log of the

This is the log of the message that I am getting if I flash the board with my image .

CFE> tftpd
Start TFTP server
Reading :: Done. 3895354 bytes read
Loading .............................................
Programming...done. 3895354 bytes written
Write len/chksum offset @ 0x0038FFF8...done.

CFE for WGR614v8 version: 1.3

Build Date: Fri Apr 20 14:04:44 CST 2007
et0: Broadcom BCM47xx 10/100 Mbps Ethernet Controller 4.138.1.0
Device eth0: hwaddr 8B-6E-24-CF-CC-9C, ipaddr 192.168.1.1, mask 255.255.255.0
gateway not set, nameserver not set
Loading .............................................
Image chksum: 0x0B62CD9A
Calc chksum: 0xCD88CBE5
Boot program checksum is invalid
Start TFTP server
Reading ::

I am using vmlinuz and target.cramfs to create trx image and then using a script as the one given below to convert to chk format :

echo ""
touch emptyfile
echo U12H072T00_NETGEAR >> compatible.txt
wgr614tool/packet -k linux-glibc.trx -f emptyfile -b compatible.txt -ok kernel_image -oall broadcom -or rootfs_image -i emptyfile
rm -f emptyfile compatible.txt kernel_image.chk rootfs_image.chk

Please let me know if I am able to provide you the information you intended ...

bzing2
bzing2's picture
Ok well I have to say that

Ok well I have to say that that all looks ok! Very strange!!

The only suggestion I have is to try the mkchkimg tool instead of the packet tool. If you have the same problem then we can rule that out as a problem. If not then we will have to take a look at the trx.

achilles
achilles's picture
Well I have tried with

Well I have tried with mkchkimg tool in my script :

echo ""
touch emptyfile
echo U12H072T00_NETGEAR >> compatible.txt
wgr614tool/mkchkimg -k linux-glibc.trx -f emptyfile -b compatible.txt -o broadcom.chk
rm -f emptyfile compatible.txt

and got the following output :


mkchkimg: Netgear CHK writer - v0.1
mkchkimg: Board Id: compatible.txt
mkchkimg: Region: World Wide (WW)
mkchkimg: Kernel Len: 3895296
mkchkimg: Kernel Checksum: 0x0b62cd9a
mkchkimg: Rootfs Len: 0
mkchkimg: Rootfs Checksum: 0x00000000
mkchkimg: Image Checksum: 0x0b62cd9a

but still if I use this image to flash the board I am getting the same problem and console of board shows messages :

CFE> tftpd
Start TFTP server
Reading :: Done. 3895350 bytes read
Loading .............................................
Programming...done. 3895350 bytes written
Write len/chksum offset @ 0x0038FFF8...done.

CFE for WGR614v8 version: 1.3
Build Date: Fri Apr 20 14:04:44 CST 2007
et0: Broadcom BCM47xx 10/100 Mbps Ethernet Controller 4.138.1.0
Device eth0: hwaddr 8B-6E-24-CF-CC-9C, ipaddr 192.168.1.1, mask 255.255.255.0
gateway not set, nameserver not set
Loading .............................................
Image chksum: 0x0B62CD9A
Calc chksum: 0xCD88CBE5
Boot program checksum is invalid
Start TFTP server

So do you have any suggestion regarding what should I do now ?
One thing I was thinking that I should try adding support of iwconfig on some other open source firmwares like DD-WRT and see if I face the same problem there or not but that will be a time consuming process and would not shed much light on this problem ....
What is your suggestion regarding this ....

bzing2
bzing2's picture
You probably meant to type

You probably meant to type the following; but I suspect that is not what is causing your problem, its just good for clarification.

mkchkimg -k linux-glibc.trx -f emptyfile -b U12H072T00_NETGEAR -o broadcom.chk

I am running OpenWRT on my box (look for the OpenWRT "bleeding edge" download). It has some form of iwconfig support. However most of what your likely to want to do with the wireless can be got at through the "wl" and "wlc" command line tools. These are included in OpenWRT. What in particular were you trying to achieve??

I have to say I am a little confused, it almost looks like your board is calculating the checksum in a different way that mine. As you can see its stored the image checksum, but it is calculating a different one. What region is your board?

Have you tried putting back an orignal Netgear firmware, if so exactly which one?

I get the feeling you may have a hardware problem...

achilles
achilles's picture
bzing2 said:

bzing2 said:
You probably meant to type the following; but I suspect that is not what is causing your problem, its just good for clarification.

	mkchkimg -k linux-glibc.trx -f emptyfile -b U12H072T00_NETGEAR -o broadcom.chk
	

I am running OpenWRT on my box (look for the OpenWRT "bleeding edge" download). It has some form of iwconfig support. However most of what your likely to want to do with the wireless can be got at through the "wl" and "wlc" command line tools. These are included in OpenWRT. What in particular were you trying to achieve??
I have to say I am a little confused, it almost looks like your board is calculating the checksum in a different way that mine. As you can see its stored the image checksum, but it is calculating a different one. What region is your board?
Have you tried putting back an orignal Netgear firmware, if so exactly which one?
I get the feeling you may have a hardware problem...

 

Well I was trying to configure my board as a client  through iwconfig ...... I have not yet checked if I can do this through GUI or not ..... besides that my other intention was to see how a new package could be added to broadcom's firmware

My board is of NA region .... I have not checked it with original Netgear firmware but it works OK with other firmwares like DD-WRT  or Open-WRT .... It works ok even with my image if it does not have the support for iwconfig ... 

bzing2
bzing2's picture
I have just noticed that your

I have just noticed that your image is 3.8MB big, remember that the flash is only 4M in total. Now this is only a theory but perhaps the image that your trying to write is too big. The boot loader thus discards the end of the image and clips the length. Then at next boot the stored length is not the same (not printed) as that of the CHK, thus the checksums are different!

Start of Kernel in flash: 0x20000 = 131072
Size of Your image: 3895296
End of your image in flash: 3895296 + 131072 = 4026368 (0x3d7000)

The checksum and length are stored at 0x3afff8 and 0x3afffc. These values are written after flashing, but are contained within your image. This is most likely why the checksums are wrong.

achilles
achilles's picture
thanks a lot for your

thanks a lot for your suggestion .... I will try to reduce my image size by removing some applications ....

bzing2
bzing2's picture
Did it work?

Did it work?

achilles
achilles's picture
bzing2 said:

bzing2 said:
Did it work?

Yes .... It is working ... I have removed few applications and now my image size is 365776 ....

With this image booting happens properly ..... thanks again for your suggestions ....