This script flashes the NAND of a BeagleBoard if it exists, and if there is a valid image to flash
Signed-off-by: Joel A Fernandes <agnel.joel@gmail.com>
This script flashes the NAND of a BeagleBoard if it exists, and if there is a valid image to flash
Signed-off-by: Joel A Fernandes <agnel.joel@gmail.com>
Acked-by: Jason Kridner <jkridner@beagleboard.org>
I will eventually merge your changes into the mainline, but I believe
it is helpful to get these updates in OE for BeagleBoard users who
want to reproduce the shipping images.
Can you update the process to only flash the boards if the USER button
is held or some other similar strategy? It seems that enabling this
script would make the SD card image useless for non-flashing
activities. Of course, Gerald would need to sign-off on any flashing
process changes.
Since we're not in a ramdisk anymore, we could also dump a /etc/joel-was-here file to see if we already have flashed nand from this specific card or not.
Texas Instruments Limited, 800 Pavilion Drive, Northampton, NN4 7YL. Registered in England & Wales under company number 00574102
Since we cannot access user-button as its used as an input event, can
I put in a message like "Press any key to flash", timeout if no key is
hit and then normally boot?
Regards
Joel
Don't see how this will work when the same card is used to flash
multiple boards?
Regards,
Joel
Since we're not in a ramdisk anymore, we could also dump a /etc/joel-was-here file to see if we already have flashed nand from this specific card or not.
That would indeed make the card more useful, but it seems to be tied
to the wrong state--especially in a production environment where you
likely want to reuse the card on multiple boards.
It is critical that the public has a card image they can download to
restore the flash into its factory condition. For C5 boards, it seems
to me that the USER button is a reasonable approach as it will cause
the on-card x-loader to be used that will give preference to the
on-card u-boot. The remaining challenge is the lack of an isolated
command to read the environment from the NAND flash. The current
u-boot will always have the default environment overridden by the
environment in NAND flash.
We discussed previously on this list the idea of adding a command to
read the environment from the NAND flash and then adjusting the
default environment to perform that read and use the on-NAND
environment (as priority above any other environment settings, such as
uenv.txt on the SD card) if the USER button was not pressed. Then,
the reading of the environment from the NAND flash could be removed
and only read as part of the default environment settings.
A C5 image needs to go out, so I'm OK adding none of these changes for
this release, but I'd like it if Joel could make the above NAND/USER
button related changes to the mainline u-boot as part of the effort to
get all of the BeagleBoard u-boot patches into mainline. At that
point, a new flashing image could be released. In the meantime,
manual intervention of 'nand erase 260000 2000' may be required to
initiate flashing boards that have been modified.
This script flashes the NAND of a BeagleBoard if it exists, and if there is a valid image to flash
Signed-off-by: Joel A Fernandes <agnel.joel@gmail.com>
Acked-by: Jason Kridner <jkridner@beagleboard.org>
I will eventually merge your changes into the mainline, but I believe
it is helpful to get these updates in OE for BeagleBoard users who
want to reproduce the shipping images.Can you update the process to only flash the boards if the USER button
is held or some other similar strategy? It seems that enabling this
script would make the SD card image useless for non-flashingSince we cannot access user-button as its used as an input event, can
I put in a message like "Press any key to flash", timeout if no key is
hit and then normally boot?
You should be able to check the status similar to the way you do for
keyboards. From what I've read[1][2], you can simply use the
EVIOCGKEY ioctl to check the state.
[1] http://andrey.thedotcommune.com/2010/02/heres-another-quick-linux-input-snippet.html
[2] http://www.linuxjournal.com/node/6429/print
I just spent a fair amount of time working with the different
versions and variations of u-boot that have evolved. It seems that
perhaps there is some confusion over the boot procedure and the
userbutton. These differences in the u-boot versions are being signed-
off/approved. I can see from reading Jason's post why there are
problems being introduced. It is very subtle, but the difference is
vast.
restore the flash into its factory condition. For C5 boards, it seems
to me that the USER button is a reasonable approach as it will cause
the on-card x-loader to be used that will give preference to the
on-card u-boot. The remaining challenge is the lack of an isolated
The ROM bootloader searches for Xloader in the following order:
User button not pressed (SYS.BOOT[5] = 0): NAND -> USB -> UART3 ->
MMC1
User button is pressed (SYS.BOOT[5] = 1): USB -> UART3 -> MMC1 ->
NAND
Xloader then searches for u-boot.bin on the FAT32 partion of SD/MMC.
If not found it will then look in NAND.
After U-boot loads it reads the bootcmd variable in the NAND
environment is executed. This can lead to the following problems:
1) Newer versions of u-boot do not recognize mmc init or they may
require mmc init ${mmcdev}.
2) Since there is not a userbutton command in the newer versions, the
old method of calling user.scr instead of boot.scr is defunct.
I have a working setup of Angstrom in NAND on a revC4 board. If I
have a SD card in the slot it will boot from the u-boot and uImage in
ext3 partiton from the SD. I have this setup working for a Ubuntu
card (one that loads a ramdisk from the FAT32 partition) too.
This setup will not work with just any version of u-boot.
The card that I have for flashing NAND only works if the user button
is pressed. It is the same NAND image that koen posted here:
--Mark
So what is your recommended design approach? Do you agree with my
assertion that the reading of the NAND environment should be moved
into a command executed (optionally) by the default environment
(compiled-in environment that might test the USER button, rather than
the compiled-in option that always reads the environment from NAND)?
Hi Jason,
So what is your recommended design approach? Do you agree with my
assertion that the reading of the NAND environment should be moved
into a command executed (optionally) by the default environment
(compiled-in environment that might test the USER button, rather than
the compiled-in option that always reads the environment from NAND)?
I agree this and will work on it.
On a separate note, for now, I will like to check the user button
anyway in U-boot (once uEnv.txt takes precedence after a NAND erase of
the environment) to determine if we should flash U-boot and Uimage, or
instead, boot directly from NAND if the user button is not pressed.
Are you ok with this? Thanks,
Joel
I believe the prevailing opinion is that 2 card images are necessary:
1 for flashing boards that have flash (ie. BeagleBoard rev Bx/Cx
boards) and 1 for executing boards without flash (ie. xM rev A/B/C
boards). Despite this, I think it is still a stretch goal to try to
have one SD card image that can be shipped with BeagleBoard-xMs and be
used to flash BeagleBoards. I'd like to see as little documentation
required as possible on how to use that SD card image. The more that
can be done to reduce the permutations, the better, in my opinion. I
think what you are talking about is a difference in the default
environment and I'm not supportive of that. Having different
uenv.txt/user.txt files is something for which I'd be more supportive,
if they were necessary for initiating the flashing.
Never break what you are standing on. I would leave the default to
read the NAND environment alone. That decision was made long ago.
The only thing that needs to be common among all of the u-boot
versions is the ability to recognize the same bootcmd arguments. Old
functions should not be removed. If you do, at least leave the stub
or redirect the call.
Xloader will always read the uboot from SD card in preference to the
one in NAND. This u-boot can be much different than the one used to
load the NAND rootfs, *** as long as it can read the bootcmd args ***
and execute the conditional statements properly.
--Mark
Hi Jason,
Sorry I am afraid I'm not very clear about it.
Are you saying you're against something like this in uEnv.txt that
will go into the final image?
uenvcmd=if userbutton; then run nandflash; else run nandboot; fi
nandflash would write uImage and u-boot to NAND partitions, and then do a boot
nandboot would expect everything to be already there.
thanks,
Joel