Hello, I am wondering what parts of the TX2 boot sequence (https://docs.nvidia.com/jetson/l4t/index.html#page/Tegra%20Linux%20Driver%20Package%20Development%20Guide/bootflow_tx2.html) utilize eMMC. It appears that the bootrom is part the processor, but that MB1 may be utilizing eMMC. Could someone help clarify if this is the case, or where eMMC usage enters the picture here? My application requires us to limit the usage of eMMC memory.
I can’t answer the details, but as a comparison to a PC, consider that a PC has a BIOS to bring up initial clocks, power rails, and basic drivers for accessing hard drive, networking, some minimal video, so on. There is no BIOS in an embedded system, and everything you might think of as a CMOS BIOS will instead exist in a partition on the eMMC.
Aside from the rootfs partition (the “APP” label partition) most of what you see for partitions (e.g., check “
sudo gdisk -l /dev/mmcblk0”) has to remain in eMMC even if you have an alternate media for the the rootfs partition.
Depending on setup it is possible that software related to redundancy could produce two of many of the partitions, an “A” version and a “B” version. I have not worked on the redundancy part, but if you do not want this, then a setup with both “A” and “B” partitions could in theory be reduced by removing the “B” version.
Consider the non-rootfs partitions as more or less mandatory. There is no provision for putting that content on external storage.
Ah, I see. That’s quite interesting, thanks for the response. I suppose then that similar to a PC BIOS, its not possible to power down the eMMC once fully booted, as that would bring down some of the core functionality? Or, is that loaded from eMMC and then running from system RAM, so eMMC would not be used so long as there is an external storage device for rootfs partitions?
I suppose this also opens up a second question on if powering down the eMMC is even possible? I haven’t been able to locate documentation on that at this point.
I’ve heard of someone else trying to power down eMMC, but I don’t remember if there was success or not (probably not as it is likely I would remember if it had succeeded). Those partitions which are similar to a BIOS are only used during boot. Once the power rails and clocks are set up I don’t think those partitions are needed again (I could be wrong about that, especially in special cases, but mostly whatever was previously read should be in register and RAM setup without the need to read that content again).
I don’t know if it will help or not, but during startup most Linux installations will load an initial ramdisk (initrd) prior to loading the final root filesystem (rootfs). If I were to do this I’d start with studying a custom initrd which reads some minimal (but user interactive) initrd, and see what works while in that initrd. Once you’ve loaded the full operating system via eMMC as rootfs you’ll have all kinds of cases to think about which the initrd won’t have issues with (for example temp files are mandatory for a lot of software, but those are set up in RAM while in the initrd).
Someone else may be able to tell you if there is a possibility of shutting down eMMC after startup is complete.
I don’t quite understand what is the goal here. Based on the default design, lots of partition are on the emmc too.
Do you want to totally boot up the device from external storage?
It is worth mentioning we added secure erase to the uboot, which means wiping the eMMC entirely.
The uboot, which is loaded to the RAM, keeps on going (until reboot)
Basically it sounds like you are booting from disk, but then running diskless in RAM (or that is the goal).
Booting up from an external device without onboard eMMC usage would be the ideal scenario. So having a RAM disk image would be the goal. If I follow the boot flow correctly, even with the secure boot on uboot, eMMC is read from prior to uboot. The main issue at hand is if there is a way to boot if the eMMC device fails and can no longer be read or written to. From what I have gathered so far, it seems that eMMC is needed from the early stages of the boot flow and can’t be moved to be sourced from an external device.
I have not worked on it with a Jetson, but I think NFS boot and PXE boot are both possible. I can’t tell you the details though.
please note that,
by default, SecureBoot process did not handle UBoot stage, since CBoot is loaded and authenticated as the final stage of bootloader code. for the supported SecureBoot process on Jetson platform, boot device is always eMMC.
I wrote secure boot by mistake, I ment secure earse,
Currently there is no method to achieve the goal you want.
FYI, programming a fuse is non reversible,
we did not program theOEM fuses, we used erase function in uboot
please refer to the boot flow of Jetson-TX2, i.e. MB1-> MB2-> CBoot -> UBoot -> Kernel.
it’s BootROM for hardware initialization, and load MB1 image in SysRAM; MB1 to Initialize the SDRAM, create carveouts, configure pinmux, and loads MB2.
CBoot is loaded and authenticated as the final stage of bootloader code to boots the kernel, U-Boot can be used for debugging purpose during development phase after CBoot.
according to above,
you may broke the booting process if you’re adding an erase function to wipe the eMMC entirely in U-Boot
This is true, I do not expect the Jetson to boot after this erase, I re-flash it.
Since the BootROM remain untouched, this should not fail a future re-flash?
Is that not right? After this erase, the Jetson is like a new one, with no software on the eMMC.
I do not automatically erase the eMMC every boot, just manually (stopping the boot flow in uboot) and then reflashing
As a follow-on question to my initial one, is it possible to modify C-Boot to point to a different device where U-Boot is. If I wanted to load a U-Boot on an attached USB device, is that possible? I note in the documentation that the C-Boot source code is available, but not sure if the pointer to U-Boot is within that source code or is embedded earlier on in the boot sequence.