Hey @WayneWWW ,
my topic has been closed without Solution.
After flashing with initrd flash to nvme the UEFI is set to boot from emmc.
Can you please provide a solution?
Sorry that I totally forgot what is your question. Could you elaborate it again?
Hey @WayneWWW , I think the last post in the old topic describes it very well.
tl;dr
The QSPI which gets flashed onto the board does not seem to take in acount for which target storage device the flash prodecure is performed. No matter what you flash for, the boot order is set to emmc/sdcard.
Without accessing the system with a serial console you can’t use a flashed nvme system.
I think the reason for this is that I use the procedure provided in Linux_for_Tegra\tools\kernel_flash\README_initrd_flash.txt Workflow 10, as it creates the flash package for the QSPI first and then appends the NVMe flash part. The first command though, does not mention the nvme at all, so I am not sure if it could know anything about it. I have unfortunately not been able to flash the NVMe with any other method than workflow 10.
So even change the boot order in UEFI menu does not help? Is that what you are telling?
You can change it in the UEFI after flashing, that works.
What I am concerned about is our production process. We’ll have a a system which will be used to massflash the systems. They are tested when they are fully assembled, though. In that state the serial port is not physically exposed anymore. Having to connect every system to a PC after flashing just to go into UEFI to change the boot order feels a bit cumbersome. Especially that the change in uefi is not very fast and when you accidently press “continue” instead of “reset” when you exit UEFI, the change does not get applied.
Is it a acceptable solution if I can give you some method to change the boot order before reflash?
I think that might work. I’ve got a flash script anyway which evaluates the target device. So I might be able to add something there. It depends on your solution of course.
will reply later.
Just bumping this, as I have the same need for my product.
Hi,
We have confirmed that next rel-35.x release will have a overlay dtbo which can change the boot order in it before flashing.
However, this dtbo won’t work with current UEFI software. Thus, only initrd workflow 10 in rel-35.1 could change the boot order at this moment. (or only runtime UEFI menu)
Hey @WayneWWW
how can I change the boot order then with initrd workflow 10?
When I use it to flash, the board always is set to boot from emmc.
Sorry, should be Workflow 11: Manually generate a bootable external storage device. Not workflow 10.
Hey @WayneWWW
okay then I will have only the NVME formatted, as I do now.
Afterwards I should use the normal flash.sh like this?
./flash.sh -c $BASEDIR/boardconfig/$PARTITION_FILE jetson-xavier-nx-devkit-qspi nvme0n1p1
So I’d flash it two times, first the nvme only, and then the QSPI with the correct boot parameter?
If that’s the case I’ll revert to my old “wrong” scripts, and just simply always use the flash.sh for everything except flashing the NVMe part…I hope that will work for A/B too, did not test with that yet. I remember that the UUID should be set when using NVMe.
If your board was flashed by sdkmanager/jetpack with rel-35.1 before, then running workflow 11 would be sufficient.
Running it to flash nvme drive, put it back to device and it will be able to boot from nvme.
I don’t get it.
I assume we get production modules from our distributor.
As I understood those modules are pre-flashed with the standard image on their emmc. So the QSPI should be set to boot from emmc?
When I now just flash the NVMe, would they not still boot from emmc? What you say makes only sense if the production modules come with the UEFI order preconfigured to NVMe > SD/EMMC?
You can try workflow 11 first.
I currently have no option to attach an NVMe disk to the flash PC. There is no connector. I’d have to order one.
But let’s be serious. I am sure that you are misunderstanding what I am trying to achieve.
What makes you think that your suggestion could work?
I have a SOM with QSPI UEFI set to boot from EMMC and a working image in EMMC. So it always boots from emmc and ignores the NVMe.
Why would it make any difference if I change only the content on the NVMe? Workflow 11 does not even have the board connected, so it can’t influence the UEFI boot order. It has simply no effect on the UEFI!
If you can explain my what magic should happen here I’ll set up a PC and test it, otherwise I can’t waste any time and money on such a try.
I could be wrong, but the search order likely exists in eMMC (or more specifically, QSPI NOR memory). Naturally, if you boot without NVMe, then search won’t find the NVMe. However, by changing it to search first for NVMe instead of eMMC, the boot device depends on what is present. If search order says to search first for the NVMe, as set up during QSPI flash, then the presence of an NVMe with a prerequisite extlinux.conf (or just “/boot”?) should in fact cause the NVMe to boot first without there ever being a change to the NVMe. It is true that the extlinux.conf of the NVMe can then chain load a different device, but the initial search order is not found on the NVMe. Also, device tree can also have an effect since it specifies some inherited environment. It might have been something needed on the NVMe which triggers detection, or it might be QSPI. Both work together.
@linuxdev In the case you describe the NVMe content could of course have an effect. But I am quite sure that in my specific case the issue lies somewhere else:
After flashing the search order is set to look for emmc and then for nvme. When I plug in an NVMe device I can boot from it by manually selecting the entry. Due to the search order, the system will always boot from the emmc though, as it has a working system on it. The search order skips boot options which are not found. I can not see how modifying the NVMe can have an effect on the search order and the successful boot of the emmc, which prevents the system from even attempting to boot from the NVMe…
To boot from NVMe I have to do one of these:
- Add the NVMe to the extlinux of the emmc
- Change the UEFI boot order in the QSPI to first look for the NVMe.
Workflow 10 (Flash QSPI and NVMe seperately), does not set the UEFI order correctly, that is a bug in my eyes. And Workflow 11 does work with the NVMe disk directly connected to the host PC. So I fail to understand how reflashing the NVMe with the same content as before would affect the boot order.
In that case you should in theory be able to edit the “extlinux.conf” to name the NVMe as the rootfs, although I’d suggest keeping a second boot entry to still point at the eMMC until you are sure things are as you wish. In some cases there were bugs whereby the “DEFAULT” for extlinux.conf would not correctly go to the desired entry unless that entry is also the first entry in the list, but I think this is probably fixed on the latest of R32.x and R34.x+ (not certain though). Think chain loading, in which it might go through eMMC extlinux.conf first, but still load NVMe first. It isn’t a bad idea to do as you mention, to add NVMe to extlinux.conf in eMMC. UEFI does change things though, and I’ve not experimented with this enough to say anything useful for UEFI configuration.
Do make sure any extlinux.conf in the NVMe does not accidentally name eMMC as rootfs, and do make sure that in both cases (eMMC and NVMe extlinux.conf) that the DEFAULT entry is the first entry.
Incidentally, Jetsons have always had to flash QSPI separately. The boot content software release versions have to match between early boot and rootfs content or it will fail. Simply flashing QSPI again and getting boot to succeed (even if it requires manually selecting NVMe via serial console) is how you verify the software releases are compatible. Anytime it fails to do what you want, then that has to be set up to guarantee it isn’t a mismatch of releases causing it (it is undefined how it will behave when QSPI and other content is mismatched).
So I am just saying that it is a somewhat object-oriented approach. QSPI and NVMe and eMMC are all modular components, and you have make sure each is designed to operate with the other or something “undefined” will occur.