updating u-boot on SPI by u-boot

The commands that you list here seem to be generally correct.  However, the size that you erase (0x20000) is smaller than the size of the u-boot.bin file (0x29d58).  Try to erase 0x30000 instead of 0x20000 and then write the full 0x30000 instead of the exact file size that comes back from the tftp command.

U-Boot> sf erase 0x10000 0x30000

...

U-Boot > sf write 0xc0700000 0x10000 0x30000

http://processors.wiki.ti.com/index.php/Booting_Linux_kernel_using_U-Boot#SPI_Flash

Hope this helps,

Greg Turner

Greg,

Thanks for the info, but it still didn't work.  Writing something like uImage is working fine, but still it doesn't work for u-boot image.

I took a little closer look at what is actually being written and now I know why it is not working. 

Loading image ftom tftp, this is what I see in the memory:

U-Boot > tftp u-boot-mmc.bin              
Using  device
TFTP from server 172.30.2.87; our IP address is 172.30.2.100
Filename 'u-boot-mmc.bin'.
Load address: 0xc0700000
Loading: ############
done
Bytes transferred = 171352 (29d58 hex)
U-Boot > md 0xc0700000                    
c0700000: ea000012 e59ff014 e59ff014 e59ff014    ................
c0700010: e59ff014 e59ff014 e59ff014 e59ff014    ................
c0700020: c10800a0 c1080100 c1080160 c10801c0    ........`.......
c0700030: c1080220 c1080280 c10802e0 deadbeef     ...............
c0700040: c1080000 c1080000 c10a9d58 c10f13f0    ........X.......
c0700050: e10f0000 e3c0001f e38000d3 e129f000    ..............).
c0700060: e51f0028 e2400811 e2400080 e240d00c    (.....@...@...@.

 ...

Those starting bits matches exactly to what I would get if I look at binary dump of the u-boot image I'm using.

Now, If I read from u-boot image written in flash (same u-boot image which was loaded by serial flash tool), this is what I get:

U-Boot > sf read 0xc0700000 0x10000 0x30000
U-Boot > md 0xc0700000                    
c0700000: a1aced00 c1080000 00029d58 c1080000    ........X.......
c0700010: ea000012 e59ff014 e59ff014 e59ff014    ................
c0700020: e59ff014 e59ff014 e59ff014 e59ff014    ................
c0700030: c10800a0 c1080100 c1080160 c10801c0    ........`.......
c0700040: c1080220 c1080280 c10802e0 deadbeef     ...............
c0700050: c1080000 c1080000 c10a9d58 c10f13f0    ........X.......
c0700060: e10f0000 e3c0001f e38000d3 e129f000    ..............).
c0700070: e51f0028 e2400811 e2400080 e240d00c    (.....@...@...@.
c0700080: e3c0d007 e51f0034 e51f1034 e3a02000    ....4...4.... ..
c0700090: e5802000 e2800004 e1500001 dafffffb    . ........P.....

Note that there are extra 16 bytes of some kind of header attached at the beginning. 

One recognizable value is 00029d58 which is the actualy size of the file so it must be some kind of header used by the boot loader.

If I simply sf write to 0x10000, obviously this header is not created so it will simply become unbootable. 

The serial flash tool is putting that extra 16 bytes at the beginning of u-boot in NAND.  As you said, part of that info is the size of u-boot and this needed by the boot loader.  You can do the same thing by "signing" the u-boot.bin file before writing it to NAND.  I have pasted a couple of Wiki links below that should describe how to sign the u-boot.bin file.  Signing u-boot.bin will produce the u-boot.bin.ais file that has the correct header information.

http://processors.wiki.ti.com/index.php?title=GSG:_DA8x/OMAP-L1/AM1x_DVEVM_Additional_Procedures#Flashing_Boot_Images_on_Linux_Without_CCS

http://elinux.org/Hawkboard#Signing_u-boot_for_NAND_boot

Greg Turner

Thanks Greg, those information are very helpful.