I think our camera supplier gave us a proper dtb that could be copied to a partition on the mmc.
WITHOUT USING flash.sh, can you tell me how to build the proper dtb and which partition to use to update the dtb.
Also can I build a proper uboot and put it on the device without USING flash.sh
During manufacturing we use flash.sh, but after it is done being built, there is no access the the usb used by flash.sh, and need to address updates in the field.
Thanks,
Terry
hello terrysu50z,
kernel-dtb partition for device tree blob. you may use dd commands to update this partition remotely.$ ls -al /dev/disk/by-partlabel/ for it.lrwxrwxrwx 1 root root 16 Oct 21 03:57 kernel-dtb -> ../../mmcblk0p30dd utility to update that.$ sudo dd if=tegra186-quill-p3310-1000-c03-00-base_sigheader.dtb.encrypt of=/dev/mmcblk0p30 bs=1M
[Edit] please see-also comment #16 it’s able to update uboot with dd utility remotely.
$ sudo ./flash.sh -r -k kernel jetson-tx2-devkit mmcblk0p1dd utility to update it remotely.thanks for the info, but I still don’t know how to create the file so I can dd it.
Need to create the device tree blob and then use your info to get it to the device.
Why is u-boot different? can’t a blob be created and then moved to the mmc also?
Thanks,
Partial answer: For encrypted content, you can flash with the “--noflash” option. It won’t actually flash, but it will leave behind the “.encrypt” file version and not actually flash. Example:
sudo ./flash.sh --no-flash -k kernel-dtb jetson-tx2 mmcblk0p1
(or different partition, e.g., “-k kernel”)
The same thing with logging (useful for finding files):
sudo ./flash.sh --no-flash -k kernel-dtb jetson-tx2 mmcblk0p1 2>&1 | tee log_noflash.txt
I’m not sure if you can just flash “everything” (but not really flash) using “--no-flash” without specifying a partition, e.g., without using “-k something”. Wouldn’t hurt to try though. Perhaps also use the “-r” so the rootfs is not generated.
@linuxdev winner winner chicken dinner, that is what I needed, THANK YOU.
new dtb file with encrypted in the bootloader dir.
Any clue why there is no way to do u-boot copy to mmc partition also, Nvidia claims it will only be updated with flash.sh
Thank You again,
Terry
hello terrysu50z,
there’s u-boot.bin binary under $OUT/Linux_for_Tegra/bootloader/t186ref/p2771-0000/000/u-boot.bin, uboot (u-boot.bin) were actually working with kernel image (boot.img) and it flashed to kernel partition,
so,
you may try updating your u-boot binary, recreating kernel image with flash script, and using dd utility to update it remotely.
I’d like to put in a request for a new feature on command line related to this. That would be a “range” of contiguous partitions. Right now we could flash or clone like this for a single example partition:
sudo ./flash.sh --no-flash -k kernel-dtb jetson-tx2 mmcblk0p1
I imagine a “range” of start and stop partitions, with everything between. As an example, a single contiguous copy (like with dd) of kernel-dtb through UDA (example case is a TX2 with kernel-dtb at mmcblk0p26, and UDA at mmcblk0p31, with everything between and no holes), and no “sparse” partition attempt):
sudo ./flash.sh --no-flash -k kernel-dtb::UDA jetson-tx2 mmcblk0p1
(this would assume some standard file name, e.g., it might create “partitions.img” in the “Linux_for_Tegra/” directory)
Or the reverse flash of the same example using a single contiguous image (new option “-”):
sudo ./flash.sh -r -k kernel-dtb::UDA jetson-tx2f mmcblk0p1
(and it would assume filename in “bootloader/”, perhaps named “partitions.img”, reading labels inside this to find the partitions matching the XML layout, rejecting if it isn’t from that layout or the size is wrong for that layout)
Or to do the same thing using device specs, e.g.:
sudo ./flash.sh --no-flash -k mmcblk0p5::mmcblk0p10 jetson-tx2 mmcblk0p1
(everything between p5 and p10)
hello linuxdev,
instead of having request as a reply.
could you please init a new discussion thread to submit this feature request.
I’ll arrange resources to review this.
thanks
so is u-boot.bin in the boot.img, and which partition is used for it.
I can get the good data off my system and move it to other systems, but I don’t know which partition I need to copy.
Is there a document that describes the contents of each of the partitions?
Thanks,
Terry
Sure…since this is not a particular Jetson model though, which forum would I add this to?
I am embarrassed we have the correct files on a system that is built with flash.sh, so find the partition you want to move to other system, dd it out and then back into the other system.
No need to do anything special for u-boot or dtb, use flash.sh to build the system the way you want and dd it to the next system.
I found u-boot in kernel, partition 29 on my system, I dd it out and then dd’d it into the target system.
Later,
Terry
It’s almost like nvidia needs a “request” forum, for flash.sh, otherwise a forum for flash.sh itself.
Terry
actually, which JetPack release version you’re looking for should be more important.
you may init a thread with TX2 series if you request this for JP-4.x, otherwise, please file with Xavier/Orin series for JP-5.x.
hello terrysu50z,
may I know your test results?
had you manage to update uboot correctly with dd utility to remote update kernel partition?
sudo dd if=/dev/mmcblk0p29 bs=1M of=/tmp/file2
moved the file2 to the target system and reversed the dd
New target has the correct u-boot, you can tell by do a strings on file2 and greping for 2022, to get the date, and in my case grep for boot_target which showed I remove the mmc1 from the target path,
on my system u-boot does not look at mmc1 or my sdcard during the boot, no delay is seen scanning the mmc1 device, if there is a large number of files on the mmc1 it can get very slow and make boot time unacceptable.
Terry
hello terrysu50z,
thanks for sharing, I’ll revise my previous comments that we’re able to update uboot binary remotely.
is there anything wait for confirmation in this discussion thread? can we close this?
done, hope this helps others,
Terry
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.