To update the bootloader from the u-boot prompt itself.
as follows
Tegra124 (Jetson TK1) # mw.b ${loadaddr} 0x00 0x1000000
Tegra124 (Jetson TK1) # tftp ${loadaddr} u-boot-dtb-tegra.bin
Tegra124 (Jetson TK1) # mmc erase 2000 2000
Caution! Your devices Erase group is 0x400
The erase range would be change to 0x2000~0x23ff
mmc_send_cmd_bounced: waiting for status update
mmc erase failed
0 blocks erased: ERROR
Tegra124 (Jetson TK1) # mmc write ${loadaddr} 2000 2000
Tegra124 (Jetson TK1) # reset
1> I saw “mmc erase failed” message.
2> After reset, TK1 board is well booting.
But, i modified the environments of u-boot source.
And i tried a fusing again.
Tegra124 (Jetson TK1) # mw.b ${loadaddr} 0x00 0x1000000
Tegra124 (Jetson TK1) # tftp ${loadaddr} u-boot-dtb-tegra.bin
Tegra124 (Jetson TK1) # mmc write ${loadaddr} 2000 2000
Tegra124 (Jetson TK1) # reset
resetting …
1> I can’t see any messages.
I can use about flash.sh.
But, only i want to know a fusing method in u-boot prompt.
We would also like to know how to update uboot without putting the board into recovery mode.
Once deployed, our tegra-based boards are in sealed units with access to only serial and ethernet. We have a way to write to the boot loader partition, and any user partition from a web page to support remote software updates. We have no problem updating any of the user partitions using this method but we noticed that it does not work for updating UBOOT. Doing a dump of the EBT partition using Nvidia’s nvflash tool shows that the contents of the uboot partition is correct, but the board will not boot until flashing the identical image using recovery mode and a usb connection.
Is there some CRC of the boot image stored somewhere that is checked and if not valid prevents UBOOT from loading? If so is there an easy way to disable this? Remote update of all software components is an extremely important feature for us. We currently have over 1000 units deployed, and many more shipping soon.
Any help from Nvidia on this would be greatly appreciated.
I’m very interesting on the same questions.
We are working to create our firmware and needs to make mechanism to flashing from inside the board, after OTA download of new firmware version, the new firmware.
Some people on Nvidia could provide a full guide for u-boot and sam script example to implement this?.
Just some thoughts on the topic. First, u-boot would have to be entirely in RAM for it to be successfully overwritten by itself while it runs. If any of the environment is read “as needed” while operating, I would expect odd or failing behavior.
Because u-boot has a number of parameters which can be set from the prompt, perhaps setting those parameters first to match the upcoming u-boot image, then rebooting, and then in the second boot finally overwriting u-boot may get around that. Then again, if changing the u-boot image changes where the offsets are for components it is looking for, this wouldn’t help.
Another possibility is if you have two u-boot partitions, and only one is active; flashing to the alternate inactive location and then swapping which one is active might do the job. The issue there is that I don’t know how to edit which u-boot image is active. Additionally, you’d waste about 512k of space.
One thing I’ve noticed which may be relevant is that the u-boot image is padded with NULL bytes at the end. The starting image in bootloader/ardbeg/u-boot.bin for R21.4 is 440004 bytes, which is padded and placed in bootloader/u-boot.bin prior to flash; the bootloader/u-boot.bin is 440016 bytes, so it has 12 extra NULL bytes on the tail of the file. I do not know what formula is used for padding (this case of padding makes the image divisible by 16, but I do not know if that is the rule or something else).