omap nand boot question
Brett Kuehner
From there we could load "http://beagleboard.googlecode.com/files/x-load.bin.ift_for_NAND" and write it to flash, following the beagleboard recovery instructions (including nandecc hw)
We ran into two issues:
1) the first few bytes of the image in ram didn't match the file on disk, but all the other bytes were OK. I'm not sure if something is broken in our hardware or uboot build, or if loadb is doing something I'm not expecting. I'm checking this out further.
2) once it was flashed, booting from nand didn't work, it just did the "40T" serial boot prompt. This was true whether or not we corrected the first few bytes of the loadb image before writing to flash.
Are there more things to check about booting from flash? I believe the xload image is signed correctly (I wrote it to my Beagle and it worked fine). And I believe the SYS.BOOT[5] pin is set right.
Is there any additional flash prep/partitioning/formatting that needs to be done on a raw OMAP processor to get it to boot? Any suggestions appreciated.
Thanks,
Brett
Alejandro Blanca G.
Last night, I did a similar exercise, but with my beagle.
What I wanted to do was just to add some print statements in the
xloader binary. For this, I compiled the latest version in the branch
mentioned in the wikis (git clone
git://gitorious.org/x-load-omap3/mainline.git xloader; master branch),
signed it using signGP, renamed it "MLO", copied to the MMC and
"User+Reset" the beagle to try to boot it from the MMC.
The result was the same as you mentioned: got a "40T". I shot a
question today about what version of the xloader was "safe" to confirm
I was using the correct one. Still haven't got any comments on it. But
seems quite similar to your scenario.
So, would you mind sharing the commit hash / tag of the code you used
to compare against mine?
At least this would help provide a record on this for future reference.
Best Regards,
Alex B.
Brett Kuehner
>Last night, I did a similar exercise, but with my beagle.
>
>What I wanted to do was just to add some print statements in the
>xloader binary. For this, I compiled the latest version in the branch
>mentioned in the wikis (git clone
>git://gitorious.org/x-load-omap3/mainline.git xloader; master branch),
>signed it using signGP, renamed it "MLO", copied to the MMC and
>"User+Reset" the beagle to try to boot it from the MMC.
>
>The result was the same as you mentioned: got a "40T". I shot a
>question today about what version of the xloader was "safe" to confirm
>I was using the correct one. Still haven't got any comments on it. But
>seems quite similar to your scenario.
>
>So, would you mind sharing the commit hash / tag of the code you used
>to compare against mine?
>
>At least this would help provide a record on this for future reference.
I was using a pre-built binary from here:
http://beagleboard.googlecode.com/files/x-load.bin.ift_for_NAND
I did get this working ok on a beagleboard, so you may want to give
it a try as a demo that the flashing procedure you are using works. I
am currently playing with a version built from the same git source
you mention, so when I have more time to experiment I will let you
know how it worked or didn't work.
Brett
--
Brett Kuehner
b...@pobox.com
http://www.bvk.nu
Nishanth Menon
On Fri, Jan 30, 2009 at 7:54 PM, Brett Kuehner <b...@pobox.com> wrote:
> I did get this working ok on a beagleboard, so you may want to give
> it a try as a demo that the flashing procedure you are using works. I
> am currently playing with a version built from the same git source
> you mention, so when I have more time to experiment I will let you
> know how it worked or didn't work.
On my ubuntu 8.04 32bit OS PC, here are the steps I did.
------------- Build Steps ----------------
$git clone git://gitorious.org/x-load-omap3/mainline.git xloader
$git clone git://git.denx.de/u-boot-arm.git
$git clone git://git.denx.de/u-boot-v2.git
$git clone git://github.com/nmenon/omap-u-boot-utils.git
$alias mymake='make -j2 CROSS_COMPILE=arm-none-linux-gnueabi- V=1 ARCH=arm'
$cd x-loader
$mymake omap3530beagle_config;mymake
$wget "http://beagleboard.googlecode.com/files/signGP.c"
$gcc -o signGP signGP.c
$./signGP x-load.bin 0x40200800
$cd ../u-boot-v2/
$mymake omap3530_beagle_per_uart_defconfig; mymake
$cd ../u-boot-arm
$mymake omap3_beagle_config;mymake
$cd ../omap-u-boot-utils
$make;make usb
$mkdir -p ../beagle_recover/target_files;cd ../beagle_recover
$cp ../omap-u-boot-utils/pusb ../omap-u-boot-utils/pserial
../omap-u-boot-utils/ukermit ../omap-u-boot-utils/ucmd .
$cp ../u-boot-arm/u-boot.bin target_files/u-boot-v1.bin
$cp ../u-boot-v2/uboot.bin target_files/u-boot-v2.bin
$cp ../xloader/x-load.bin.ift target_files/x-load.bin.ift
------------- Flashing Steps ----------------
$TTY=/dev/ttyS0
$sudo ./pusb -f ./target_files/u-boot-v2.bin
Connected just the USB cable to the board with the user switch S1 pressed.
$./ucmd -p $TTY -c "loadb -f /dev/ram0" -e "bps..."
$./ukermit -p $TTY -f target_files/u-boot-v1.bin
$./ucmd -p $TTY -c "go 0x80000000" -e "serial";./ucmd -p $TTY -c "help" -e "#"
$./ucmd -p $TTY -c "nand erase" -e "#"
$./ucmd -p $TTY -c "nand write.i 80000000 80000 80000" -e "#"
$./ucmd -p $TTY -c "loadb 80000000" -e "bps..."
$./ukermit -p $TTY -f target_files/x-load.bin.ift
$./ucmd -p $TTY -c "nandecc hw" -e "#"
$./ucmd -p $TTY -c "nand write.i 80000000 0 80000" -e "#"
The following step is optional if you want to remove the autoboot.
$ ./ucmd -p $TTY -c "setenv bootcmd;nandecc sw;saveenv" -e "#"
The attached tarball contain prebuilt images, and you can also use a
script recover_beagle.sh which is part of the tgz attached.
once you open minicom, replugin your power/miniusb cable to beagle
board, bingo it is working.. -> I have put a video of the script in
action here: http://flickr.com/photos/nishanthmenon/3239616749/ (flash
player required)
Regards,
Nishanth Menon
Brett Kuehner
Thank you very much for the detailed instructions. One more question-
clearly this will work on a beagleboard which had some preexisting
prep done to it before it was sold. Is it possible there are any
additional preliminary steps, not covered here, which are done at the
"beagle factory", or should this be sufficient to bring up a
completely untouched OMAP chip that was never "beagleized"?
Thanks,
Nishanth Menon
Brett Kuehner said the following on 01/30/2009 10:01 PM:
>
> Thank you very much for the detailed instructions. One more question-
> clearly this will work on a beagleboard which had some preexisting
> prep done to it before it was sold. Is it possible there are any
> additional preliminary steps, not covered here, which are done at the
> "beagle factory", or should this be sufficient to bring up a
> completely untouched OMAP chip that was never "beagleized"?
>
>
Btw, i do not know the steps they do to put the bootloader at "beagle
factory" ;).. mebbe Gerald can comment..The only prep done at factory to
my knowledge is to flash a bootloader -> which is what my procedure
does.. in it's own way.. Albiet at my desk :).. You cannot modify the
OMAP in anyway, all you can do is put s/w in flash/mmc.. OMAP loads it
as part of the bootprocess. If this is what you mean by "beagleized"
Anyways, Just OMAP is enough for the procedure to work - all the
required s/w is being send over usb/uart cable. the secret lies within
OMAP which has a piece of s/w called ROM code which you cannot
modify/erase.. So, similar steps could be done at "beagle factory" or at
your machine :)..
Here is a simple way of doing this: run "nand erase" at u-boot prompt ->
this will essentially wipe out the nand flash.. so now you have a
"pre-beagleized" configuration.. Just an USB cable and UART cable is
enough.. no need for an mmc/Jtag to put a bootloader on the flash..
Ofcourse the build is specific for beagleboard, as nand and sdram needs
to be configured.. but with uboot and x-loader being ported for a new
board with OMAP on it (changes for nand/sdram and connectivity details),
the above procedure should work there too..
A bit more info in [1] and the OMAP booting process is documented in the
"initialization" chapter of the 3530 TRM..
Regards,
Nishanth Menon
Ref:
[1]:
http://nishanthmenon.blogspot.com/2009/01/omap-peripheral-boot-what-heck-is-it.html
Brett Kuehner
>Btw, i do not know the steps they do to put the bootloader at "beagle
>factory" ;).. mebbe Gerald can comment..The only prep done at factory to
>my knowledge is to flash a bootloader -> which is what my procedure
>does.. in it's own way.. Albiet at my desk :).. You cannot modify the
>OMAP in anyway, all you can do is put s/w in flash/mmc.. OMAP loads it
>as part of the bootprocess. If this is what you mean by "beagleized"
I just wondered if there was any other OMAP prep done. There seem to
be 4 partitions (X-loader, uboot, uboot env, and kernel, I think)
pre-made on the beagle, even though they aren't all pre-loaded. So
there is something that creates and names the chunks of flash.
>Here is a simple way of doing this: run "nand erase" at u-boot prompt ->
>this will essentially wipe out the nand flash.. so now you have a
>"pre-beagleized" configuration.. Just an USB cable and UART cable is
>enough.. no need for an mmc/Jtag to put a bootloader on the flash..
I'll have to try a full erase and then see if the partition names are
still there.
>Ofcourse the build is specific for beagleboard, as nand and sdram needs
>to be configured.. but with uboot and x-loader being ported for a new
>board with OMAP on it (changes for nand/sdram and connectivity details),
>the above procedure should work there too..
Right. The omap board we've made seems to run both ubootV1 and
ubootV2 OK. But for some reason on bootup it isn't loading the
x-loader we flashed into nand. I thought possibly there was some
magic byte set somewhere on the beagle. But as you point out, a nand
erase should wipe any magic bytes, so I'll give that a shot and
compare behavior.
>A bit more info in [1] and the OMAP booting process is documented in the
>"initialization" chapter of the 3530 TRM..
Yeah, I expect actual debugging work is my next thing to try. It is
very nice that so many tools work out of the box, and I'm happy our
board is working at all. The factory we're using had never done POP
stuff before, so it looks like they did a good job.
Hunyue Yau
> At 11:25 PM 1/30/2009, Nishanth Menon <menon.n...@gmail.com> wrote:
> >Btw, i do not know the steps they do to put the bootloader at "beagle
> >factory" ;).. mebbe Gerald can comment..The only prep done at factory to
> >my knowledge is to flash a bootloader -> which is what my procedure
> >does.. in it's own way.. Albiet at my desk :).. You cannot modify the
> >OMAP in anyway, all you can do is put s/w in flash/mmc.. OMAP loads it
> >as part of the bootprocess. If this is what you mean by "beagleized"
>
> I just wondered if there was any other OMAP prep done. There seem to
> be 4 partitions (X-loader, uboot, uboot env, and kernel, I think)
> pre-made on the beagle, even though they aren't all pre-loaded. So
> there is something that creates and names the chunks of flash.
Linux kernel and U-boot/X-Loader. U-boot only knows about the location of the
U-boot configuration. X-Loader only knows about the location of U-boot. The
only special is X-loader must reside at the beginning so the internal ROM can
load it.
From within U-boot, the concept of partitions don't exists and you must use
offsets to get to the right place.
Hunyue Yau
http://www.hy-research.com/
Gerald Coley
Nishanth Menon
> Right. The omap board we've made seems to run both ubootV1 and
> ubootV2 OK. But for some reason on bootup it isn't loading the
> x-loader we flashed into nand. I thought possibly there was some
> magic byte set somewhere on the beagle. But as you point out, a nand
> erase should wipe any magic bytes, so I'll give that a shot and
> compare behavior.
>
>
questions for a new board with NAND when it is not working:
a) Did you check if the device id of the device is in TRM under
supported devices? -> ROM Code should support this device if it should
ever boot..
b) Did you read your CTRL_STATUS register and verify the SYSBOOT boot
sequence in TRM -> is NAND in the sequence and nothing else preventing
it from being hit? -> this confirms if the NAND device
c) what is the status of your EMU0-1 JTAG pins are they both high or in
tristate condition during OMAP boot?
d) is it on CS0?
e) Do you have an 8 bit or a 16 bit NAND? is your config file in
x-loader, u-boot handling this correctly?
f) Did you sign x-loader.bin.ift with signGP.c? Try this in x-loader
directory: grep _start System.map|cut -d' ' -f1|xargs signGP x-load.bin
- to sign the x-loader correctly
g) Finally did you use nandecc hw for flashing x-loader.bin.ift?
h) what is the result of nand dump 0? the OOB area?
i) you could in theory write a very small piece of assembly to shut down
watchdog timer, and basically loop for ever -> flash this instead of
x-loader then once the board boots up, connect with JTAG and see if your
infinite loop is running in SRAM.. if so, you have your flashing
correct, but mebbe x-loader is goofing up somewhere..
hope these help..
Regards,
Nishanth Menon
Brett Kuehner
This is a great list of stuff to check, thanks. I get another crack
at the board tomorrow. I'll let you know how it turns out and/or
plead for more help :-)
Brett Kuehner
prompt (running from a ramdisk). Thanks for your help. It turns out
that the main remaining issue was it was configured to boot from
OneNAND instead of NAND (internal).
Now we just need to make everything else work.... :-)
Nishanth Menon
Brett Kuehner said the following on 02/02/2009 11:14 PM:
> Our board now works! It can cold boot all the way up to a shell
> prompt (running from a ramdisk). Thanks for your help. It turns out
>
coool.. congrats :)
> that the main remaining issue was it was configured to boot from
> OneNAND instead of NAND (internal).
>
Yes, getting SYSBOOT correct is important..
> Now we just need to make everything else work.... :-)
>
Good luck... if possible, do send your patches for your board also.. :)
Regards,
Nishanth Menon