Project

General

Profile

Assigning params from memory in u-boot

Added by Anonymous almost 11 years ago

Hi,
Were are in the final stages of booting our StarterWare image from uboot. Currently we have our compressed image
loaded into SPI flash with a mkimage header attached on the top. I am trying to make a uboot script that will load the image
from flash and check the CRC. I have one main issue:

1) The image size I need to load into memory is in the header of the image. So when I try to run
a sf read command, I need to use the size from the mkimage header. The normal command would be
"sf read 82000000 300000 2e7f2". The 2e7f2 is the size of the image and its long word location
30000C. Is there a way to set a size parameter based on the contents of 30000C?
set imagelength ${83000000} or something like this.

Thanks,
John C.


Replies (9)

RE: Assigning params from memory in u-boot - Added by Jonathan Cormier almost 11 years ago

I'm unsure how to do what your looking for. All the references I could find have you set the image size in an environment variable when it is flashed to the spi flash.
Example: http://wiki.atlas-embedded.com/index.php?title=Flashing_Linux_and_FileSystem

RE: Assigning params from memory in u-boot - Added by Anonymous almost 11 years ago

Hey Jonathan,

The issue is that we are burning our image into flash from our StarterWare code base. The new 
StarterWare image is burned into SPI flash memory location 0x300000 and has a mkimage header. When you
read the flash and put it into regular memory 82000000 it looks like this:

82000000: 56190527 a135554f 7c256351 34e20200 '..VOU5.Qc%|...4
82000010: 00000080 00000080 7dc8d0e5 01010211 ...........}....
82000020: 74524941 20636172 67616d69 00000065 AIRtrac image...
82000030: 00000000 00000000 00000000 00000000 ................

Location 8200000C contains the length of the image that has been checksummed by mkimage
0x0002E234. I need to set a param to 2E234 so that I can run the CRC32 command using
the proper image size. I can find no examples of how to make a script that will
use the contents of that location in in the command:
crc32 address count

Typed in it would be
crc32 82000040 2E234, but because I need a uboot command to take any image size, I need
to be able to use the "contents of address 8200000C".

Any way to do this?

Thanks,
John C.

RE: Assigning params from memory in u-boot - Added by Michael Williamson almost 11 years ago

Hi John,

u-Boot doesn't really have much for interpretative type scripting. I don't think you can accomplish this with the stock u-Boot.

Options:

1. You could easily extend the u-Boot crc32 command or add your own to create a environment text variable from a location in memory. We've done this when adding the factoryconfig and the config commands in the u-Boot provided by CL, it's not that hard.

2. You could have your starterware code update the u-Boot environment (also stored in SPI FLASH) to contain the crc32 command for the specific image size programmed. The u-Boot environment is in a single sector and is a pile of concantenated strings with a checksum at the end. There are linux utilities for doing this, you could adapt them for Starterware.

That's pretty much all I've got....

-Mike

RE: Assigning params from memory in u-boot - Added by Tim Iskander almost 11 years ago

Not sure if this will do what you really want, but if you load the image from flash (read the max image size into ram, thus avoiding the need to know it beforehand)
you can then run the imi command on it (as it has a u-boot image header).
The imi command will verify the checksum and you can test for success there.
i.e.

nand_img_siz=0x500000
nand_src_addr=0x20000
kloadaddr=0x80007fc0

nand read.i ${kloadaddr} ${nand_src_addr} ${nand_img_siz}
if imi ${kloadaddr};then echo Image is OK;fi

The bootm command also verifies the checksum before executing the code.

cheers
/Tim

RE: Assigning params from memory in u-boot - Added by Anonymous almost 11 years ago

Thanks Tim and Mike,

I think that unless it is an easy port of updating/saving the u-boot environment params(like in I need to be
done today), modifying one of the u-boot commands might be the way to go. We also have another location in flash
that tells u-boot which image (we have two) to boot from. So being unable use the contents of memory off the
command line was not expected. Mike where would the functions for modifying the environment params be?

Thanks again,
John C.

RE: Assigning params from memory in u-boot - Added by Anonymous almost 11 years ago

Tim and Mike,

I found this command that works in testing the contents of memory. Is there any way to get that value into
a param?

if itest.l *80000000 == 80800020; then echo error; fi;

Thanks,
John C.

RE: Assigning params from memory in u-boot - Added by Jonathan Cormier almost 11 years ago

John C.

Heres a link to the source code for the itest command.
http://support.criticallink.com/gitweb/?p=u-boot-mityarm-335x.git;a=blob;f=common/cmd_itest.c;h=2a238a43e5d13e56db36665562162eee5e512705;hb=HEAD

It doesn't have any options for returning the value only a true/false.

RE: Assigning params from memory in u-boot - Added by Jonathan Cormier almost 11 years ago

John C.,

Looks like md might do what you want.

/* Memory Display * * Syntax: * md{.b, .w, .l} {addr} {len}
*/
md.l 80000000 1
80000000: 807fffe0 ....

Unfortunately its output seems rather verbose.

http://support.criticallink.com/gitweb/?p=u-boot-mityarm-335x.git;a=blob;f=common/cmd_mem.c;h=4daa1b3db0032ce16e80cefd94dc4a923260efe1;hb=HEAD#l54

RE: Assigning params from memory in u-boot - Added by Anonymous almost 11 years ago

We finally have something that will work, but is not ideal. By using itest we look to see which
of our images is the preferred for booting and then checks the image, and if it is good, unzips
it and jumps. The main issue is that this method has to load the maximum size of our images
from SPI flash instead of the true image size in the mkimage header.

Thanks for all the help,
John C.

set airtrac_boot 'run airtrac_boot1; run airtrac_boot2;'
set airtrac_boot_args_addr 230000
set airtrac_image_size 200000
set airtrac_load_addr 8D000000
set airtrac_ddr_addr 8D000040
set airtrac_unzip_addr 80000000
set airtrac_primary_boot 'set airtrac_image_addr 300000;set airtrac_bkup_image_addr 50000;'
set airtrac_secondary_boot 'set airtrac_image_addr 500000;set airtrac_bkup_image_addr 30000;'
set unzip_primary_cmd 'echo AIRtrac primary image is good; unzip ${airtrac_ddr_addr} ${airtrac_unzip_addr}; go ${airtrac_unzip_addr};'
set unzip_bkup_cmd 'echo AIRtrac backup image is good; unzip ${airtrac_ddr_addr} ${airtrac_unzip_addr}; go ${airtrac_unzip_addr};'

----airtrac_boot1---
sf probe 0:0;
sf read ${airtrac_load_addr} ${airtrac_boot_args_addr} 4;
if itest.b *8D000000 0; then
echo AIRtrac normal boot, go to primary;
run airtrac_primary_boot;
elif itest.b *8D000000 1; then
echo AIRtrac force image 1 bit is on;
run airtrac_primary_boot;
elif itest.b *8D000000 == 2; then
echo AIRtrac force image 2 bit is on;
run airtrac_secondary_boot;
else
echo AIRtrac unknown image, go to primary;
run airtrac_primary_boot;
fi;

----airtrac_boot2---
sf read ${airtrac_load_addr} ${airtrac_image_addr} ${airtrac_image_size};
if imi ${airtrac_load_addr}; then
run unzip_primary_cmd;
else
echo Error loading AIRtrac primary image;
sf read ${airtrac_load_addr} ${airtrac_bkup_image_addr} ${airtrac_image_size};
if imi ${airtrac_load_addr}; then
run unzip_bkup_cmd;
fi;
fi;

    (1-9/9)
    Go to top
    Add picture from clipboard (Maximum size: 1 GB)