Loading StarterWare via u-boot on AM3359

Some guesses. I checked the U-Boot GIT and the standalone type was added in 2009-07-23. If you have an older u-boot, a type of mutli might work. Never tried any of this myself though.

There is an odd mismatch between mkimage parameters and bootm messages. Your mkimage says arm, u-boot, standalone but bootm says arm, linux, firmware. Maybe an old image in flash?

Hi Norman,

                 The mismatch is my error of cutting and pasting. I have been trying different combinations hoping to get one that will work. Here is a better example:

>mkimage -A arm -O ncr -T standalone -C none -a 0x80000000 -e 0x800000 00 -n "Test image" -d Test.bin Test.img gives a:

U-Boot# bootm 8C100000
## Booting kernel from Legacy Image at 8c100000 ...
   Image Name:   Test image
   Image Type:   ARM Unknown OS Standalone Program (uncompressed)
   Data Size:    3595909 Bytes = 3.4 MiB
   Load Address: 80000000
   Entry Point:  80000000
   Verifying Checksum ... OK
   Loading Standalone Program ... OK
OK

     The booting then stops. The common issue I can see is that when I check location 80000000, the image data is not there:

U-Boot# md.l 80000000 50
80000000: 80800020 00000011 807fffc0 80800000     ...............
80000010: 0005b23c 50000000 48080000 012c0138    <......P...H8.,.
80000020: 00010001 00000000 00000000 00000000    ................
80000030: 00000000 0001d9ef 39353333 2d58452d    ........3359-EX-
80000040: 2d373232 582d4352 00412000 00000000    227-RC-X. A.....

It should be something like:

U-Boot# md.l 80000000 50
80000000: e59f00a8 e2400008 e3c00007 e321f0db    ......@.......!.
80000010: e1a0d000 e2400008 e321f0d7 e1a0d000    ......@...!.....
80000020: e2400008 e321f0d1 e1a0d000 e2400008    ..@...!.......@.
80000030: e321f0d2 e1a0d000 e2400c05 e321f0d3    ..!.......@...!.
80000040: e1a0d000 e2400008 e321f0df e1a0d000    ......@...!.....

and boot like this:

U-Boot# go 80000000
## Starting application at 0x80000000 ...


***** CiDRA Test V01.00.21 Starting *****
FPGA Hardcoded
Watchdog Timer DISABLED
USB Mass Storage Host Init
Timers Initialized
Cache Enabled

           So to the best of my knowledge, bootm is not loading the image into the memory location in the header. I could do this other ways if I could get u-boot to unzip memory but as far as I know, only bootm will do it. Do you have any other suggestions?

Thanks,

     John C.

According to code and doc, environment variable autostart must yes for bootm to jump to the entry point. No idea why the memory is not as it should be. All appearances, the image was parsed and copied. Maybe init 80000000 to zero before just to see if bootm is doing copying anyting at all. Reference:

http://www.denx.de/wiki/view/DULG/HowCanILoadAndUncompressACompressedImage

U-boot does have an unzip command. Assuming it is compiled into u-boot: Something like:

sf probe 0:0
sf read 8C100000 410000 36DEC5
unzip 8C100000 80000000
go 80000000

Hey Norman,

                  I checked for the autostart, but there is only a autoload environmental variable. I tried setting that environmental variable to 'yes' that with the same results(system hangs.) The version of u-boot that I'm running:

U-Boot 2011.09-00000-g045cda5 (Jul 12 2012 - 16:03:00)
arm-arago-linux-gnueabi-gcc (GCC) 4.5.3 20110311 (prerelease)
GNU ld (GNU Binutils) 2.20.1.20100303

                  I'm guessing this is really old as there is no unzip command in it. The reason we are using this is that our CPU module comes from Critical Link. I'll have to see if there is a way to build a newer u-boot with their changes in it (I am not a u-boot building expert.) I would try to see if there was a way to get the current bootm to work but after the system hangs, I'm not really sure that what I see at the 0x80000000 location is because of bootm, or u-boot coming up.

                 Any other words of wisdom?

Thanks,

     John C.

set autostart to no and bootm returns to uboot and the memory looks good. So why then would it hang up? bootm must not be jumping

to the 80000000 location because if I just do a go 80000000 after the bootm, it works. Thank you much for all the

help but I guess I'm going to have to resort to a u-boot debugger before I find the answer.

John C.

U-Boot# bootm 8c100000
## Booting kernel from Legacy Image at 8c100000 ...
   Image Name:   AIRtrac image
   Image Type:   ARM U-Boot Standalone Program (gzip compressed)
   Data Size:    188980 Bytes = 184.6 KiB
   Load Address: 80000000
   Entry Point:  80000000
   Verifying Checksum ... OK
   Uncompressing Standalone Program ... OK
U-Boot# md.l 80000000 50
80000000: e59f00a8 e2400008 e3c00007 e321f0db    ......@.......!.
80000010: e1a0d000 e2400008 e321f0d7 e1a0d000    ......@...!.....
80000020: e2400008 e321f0d1 e1a0d000 e2400008    ..@...!.......@.
80000030: e321f0d2 e1a0d000 e2400c05 e321f0d3    ..!.......@...!.
80000040: e1a0d000 e2400008 e321f0df e1a0d000    ......@...!.....
80000050: e3a00000 ee070fd5 f57ff06f ee110f10    ........o.......
80000060: e3800b02 ee010f10 ee113f50 e383360f    ........P?...6..
80000070: ee013f50 e3a00101 eee80a10 eef01a10    P?..............
80000080: e59f002c e59f102c e2411004 e3a02000    ,...,.....A.. ..
80000090: e4802004 e1500001 dafffffc eb0d2f96    . ....P....../..
800000a0: e59fa014 e1a0e00f e12fff1a e24ff008    ........../...O.
800000b0: 87fffff8 80001450 80001c50 8034c418    ....P...P.....4.
800000c0: 8034befc ea0d2f8c e1a00000 e1a00000    ..4../..........

No idea about bootm weirdness. No joy in tracing u-boot bootm code. It does a lot of stuff depending on so many flags. Spaghetti logic. Looks like you added compression to the mix. Maybe compression works but no-compression doesn't.

I suppose you could use bootm as a workaround for unzip. Your bootcmd could be something like this:

set autostart no
sf probe 0:0
sf read 8C100000 410000 36DEC5
bootm 8C100000
go 80000000

That 36DEC5 should probably set to an reasonable maximum amount to allow for future expansion.

Hey Norman,

     Thanks for all the help. At least I have a solution that will keep me moving until I get a little more time to debug what I would consider the best solution (bootm). I think that he ties between mkimage and bootm are pretty critical but there is not a lot of information/documentation about all the different combinations of OS and Type and how they interact.

Thanks again,

     John C.

Hi John,
Could you share your solution about how to use u-boot to boot starterware app image?
I have the same issue as yours.

Hey Gary,

                  In Code Composer's project settings->Build->Steps,  Post-build steps we added the following line:

"${PROJECT_ROOT}/tiobj2bin.bat"

In the tiobj2bin.bat we added the following lines at the bottom(we did it this way because we could not add more than one line in Post build steps.)

rem Copy the newly compiler binary to a new name.

rem Zip the new binary

rem Use the mkimage utility on your zipped image

copy sysbios.bin testOS.bin

gzip -f testOS.bin

mkimage -A arm -O u-boot -T standalone -C gzip -a 0x80000000 -e 0x80000000 -n "00.xx.xx" -d testOS.bin.gz testOS.img

The output of this will give you a zipped image file version of your binary, the zipping is optional. If you do zip it them you will need to insure your uboot image has zip built(by default it is not in uboot, so unless you can build uboot, leave the zipping out.) I'm not sure if you need the "0x" in front of the address when you are at the uboot prompt.

Hope this helps,

     John C.

// Loading into NAND flash from MMC card

// testOS.img on MMC card

// load the image into ddr memory address 8d000000

// Erase flash address 0x400000 for a size of 0x200000

// Burn the image that was loaded into ram into flash at the address you just cleared

mmc rescan

fatload mmc 0 0x8D000000 testOS.img

nand erase 0x00400000 0x00200000

nand write.i 0x8D000000 0x00400000 filesize

// From the uboot prompt

nand read 0x8D000000 0x400000 0x200000

imi 0x8D000000

Hi John:

I also tried to load starterware via uboot with go command, but nothing happened. I using the uartEcho.bin with starterware's MLO, it run well. But I using uartEcho.bin with uboot via go command, nothing happened.

Following message is captured by me
******************************************************************************************************************************************
U-Boot# fatload mmc 0 80000000 bert //==&gt; bert is renamed from uartEcho.bin
reading bert
14556 bytes read in 10 ms (1.4 MiB/s)
U-Boot# md.l 80000000
80000000: e59f00ac e2400008 e3c00007 e321f0db ......@.......!.
80000010: e1a0d000 e2400008 e321f0d7 e1a0d000 ......@...!.....
80000020: e2400008 e321f0d1 e1a0d000 e2400008 ..@...!.......@.
80000030: e321f0d2 e1a0d000 e2400a01 e321f0d3 ..!.......@...!.
80000040: e1a0d000 e2400008 e321f0df e1a0d000 ......@...!.....
80000050: e3a00000 ee070fd5 f57ff06f ee110f10 ........o.......
80000060: e3800b02 ee010f10 ee111f50 e381160f ........P.......
80000070: ee011f50 e3a01000 ee071f95 e3a00101 P...............
80000080: eee80a10 e59f002c e59f102c e2411004 ....,...,.....A.
80000090: e3a02000 e4802004 e1500001 dafffffc . ... ....P.....
800000a0: eb000cfa e59fa014 e1a0e00f e12fff1a ............../.
800000b0: e24ff008 87fffff8 80003668 80003869 ..O.....h6..i8..
800000c0: 80003644 80003490 ea000cf0 e1a00000 D6...4..........
800000d0: e92d4070 e3510000 e1a05001 03a06000 p@-...Q..P...`..
800000e0: 0a00000a e2404001 e1a06005 e5f40001 .....@@..`......
800000f0: e350000a 1a000002 e3a0000d eb000bf4 ..P.............
U-Boot# go 80000000
## Starting application at 0x80000000 ...
******************************************************************************************************************************************

Could you give me a suggestion? If you need other information, please let me know?

Any help greatly appreciated.

Thanks,

Alvin