Hello,
where can I download the "original" u-boot which is now shipped with
the Revision C boards?
R.
Google Code Archive - Long-term storage for Google Code Project Hosting.
Thanks! Is it possible to disable the USB-tty-stuff (U-Boot
2009.01-dirty) without recompiling u-boot? Some env variable?
R.
Thanks! Is it possible to disable the USB-tty-stuff (U-Boot
2009.01-dirty) without recompiling u-boot? Some env variable?
It also seems its resetting the env variables.
R.
I will defer to others to help on this in detail, but this uboot uses scripts to handle the booting process. You will find those scripts on the same download page.
Gerald
The u-boot.bin on the RevCValidation page ignores the environment
variables all the time and simply uses a default environment setting.
That default environment setting tries to read a script file for
further boot instructions.
The u-boot that is flashed on the the board behaves normally,
respecting the u-boot environment variables. What happens, however,
is that if you have u-boot.bin on the SD card, x-loader loads *that*
u-boot over the one on the NAND flash.
So, the process is:
* Is the USER button pressed at reset?
** Yes: Then poll for USB boot, Serial boot, SD boot (the MLO file in
a special place on the card), and then the NAND flash.
** No: Then check the NAND flash first, then try the other boot modes
if there is nothing valid on the flash.
* Assuming we are running x-loader from the NAND flash as the Rev C
boards are shipped, is there a u-boot.bin on the FAT formatted first
partition of the SD card?
** Yes: Then load and run it. This might be the "hacked" u-boot.bin
on the RevCValidation page that ignores the environment variables.
** No: Then check the location in the NAND flash reserved for u-boot
and attempt to run that. This is the u-boot-flash.bin on the
RevCValidation page. If it fails to run because it has been
corrupted, the system will hang here.
* Assuming we are running the u-boot from the NAND flash as the Rev C
boards are shipped (u-boot-flash.bin), then are the environment
variables saved?
** Yes: Then execute what the environment variables say to do,
including not enable the usbtty, if that is desired.
** No: Then run the default environment variables and poll the SD card
for a boot script, attempt to load a kernel from the SD card, then
fall back to attempting to load a kernel from the NAND flash.
Hope this helps. I think we want to avoid changing this process
again, but some people are thinking it might be a good idea to include
a Linux kernel on the boards as they ship along with a minimal file
system and some way to read the sources directly off the NAND flash.
I'm open to this if someone can make something such that the Beagle
will show up as an MSC device and all the relevant sources actually
fit on the NAND. Thoughts?
Hello,
very old but...
where can I download the "original" u-boot which is now shipped with
the Revision C boards?
Google Code Archive - Long-term storage for Google Code Project Hosting.
So it seems this is a special version and not the u-boot currently
shipped with the RevC-boards. But where can I get the source for this?
R.
Why do you say that? This is what should be being put on the RevC boards.
where can I download the "original" u-boot which is now shipped with
the Revision C boards?Google Code Archive - Long-term storage for Google Code Project Hosting.
So it seems this is a special version and not the u-boot currently
shipped with the RevC-boards. But where can I get the source for this?Why do you say that? This is what should be being put on the RevC boards.
Oh, then I misunderstood your email. You wrote:
"The u-boot.bin on the RevCValidation page ignores the environment
variables all the time and simply uses a default environment setting.
That default environment setting tries to read a script file for
further boot instructions.
The u-boot that is flashed on the the board behaves normally.."
?
R.