Then download the driver package and the rootfs from the website and prepare the BSP by yourself.
Refer to the quick start guide to understand how to use it.
You have to learn how to use this if you want to develop product. The sdcard module is only for evaluation but not for production…
the kit is enough for our students, we want to make some lessons on it,
but the kit is expensive for them , but the usb is a good choice
If you want me to help check your issue, flash the board with above method first.
Is your monitor a pure HDMI monitor? I mean is there any adapter cable on it?
is there some video tutorials, it is difficult to understand the nv document for us
previously, we used a miniHdmi monitor,
now we try a very pure HDMI monitor, but it doesn’t work neither.
It sounds like you have one Nano for several students and you want them to have their own boot drive instead of having their own full dev kit. Perhaps the following will clear up some confusion, although it isn’t an answer…
Is this an SD card model and not eMMC model? Answers to boot questions will change depending on model. Also, if this is not a dev kit (an SD card model plus dev kit carrier board), then other things change.
On the eMMC models there is QSPI memory which changes when you flash the Jetson. Those changes go beyond just creating a boot image. This also includes what are essentially pointers to devices for booting. The implication is that in an eMMC model, even if you boot “most” of it from an external media (e.g., USB thumb drive), there is no possibility of putting all boot content on the external device. The act of flashing such a Jetson changes the Jetson itself, and not just the boot media you see.
The SD card model of a Nano does have all of this content in the SD card (not sure how the SD card model would work if it has no SD card, but other boot media, e.g., just a USB thumb drive, never tried). Basically this means that all content on an SD card for use with an SD card dev kit can be cloned and different people could have different SD cards which are customized, e.g., different login names, different optional software, but eMMC models won’t have this flexibility.
See #50.
Consider that preexisting SD card images might not be the same as flashing once with JetPack/SDKM.
Also, note that it is good you are trying to use a true HDMI monitor, but it won’t do much good if first boot setup isn’t completed. I think you would still see HDMI output though, so no HDMI is some other issue. Anyone with that issue probably needs a full serial console boot log for each hardware change, e.g., when changing monitors and it still doesn’t work, then you’d still want a new boot log to see if the EDID is present (EDID is an i2c query of the monitor by the GPU using the DDC wire of the HDMI…and is mandatory for configuration to succeed, but it doesn’t mean the monitor is within available specs).
You should have a serial UART for serial console logging, and each student should know how to use this. The serial console is both the method of getting a definitive boot log, and also for seeing what goes wrong with video since it functions even when video and networking died. If you have a serial UART cable available for each student, then point them at this URL for how to use serial console:
https://www.jetsonhacks.com/2019/04/19/jetson-nano-serial-console/
thank you for your advice.
the jetpack4.5 will flash the QSPI with the boot firmware, so we can boot the image in usb disk.
if for jetpack4.4 we can put the sd card with a normal image in the nano, then change the boot order, to first boot the image in the usb disk.
they both works.
but there will appear some issue some time
You should first deal with the i2c issue first. It has nothing to do with the topic here because you hit such issue even when you use the sdcard image.
we can boot the jetpack4.5.1 image form the usb now, priviersly we use the jetpack4.5
Your advice is usually spot-on, but I have to take issue with this part of your comment:
On the eMMC models there is QSPI memory which changes when you flash the Jetson. Those changes go beyond just creating a boot image. This also includes what are essentially pointers to devices for booting. The implication is that in an eMMC model, even if you boot “most” of it from an external media (e.g., USB thumb drive), there is no possibility of putting all boot content on the external device. The act of flashing such a Jetson changes the Jetson itself, and not just the boot media you see .
The SD card model of a Nano does have all of this content in the SD card (not sure how the SD card model would work if it has no SD card, but other boot media, e.g., just a USB thumb drive, never tried). Basically this means that all content on an SD card for use with an SD card dev kit can be cloned and different people could have different SD cards which are customized, e.g., different login names, different optional software, but eMMC models won’t have this flexibility.
That’s just not true. The SD-based Nano (SKU0) devkit has a QSPI chip that it boots from, and in later releases (MaxSPI) everything needed to boot is on QSPI, and the OS/rootfs is all that is on the SD-card. On the commercial Nano module (SKU2), it’s all eMMC-based, no QSPI. So both the boot firmware && the OS/rootfs is on eMMC.
So with a Nano devkit (QSPI+SD-card), you can boot different OSes by changing what’s on the SD-card (or USB stick, etc.). And you should update the QSPI boot firmware to the most recent release (32.5+, JP4.5+). Please don’t use older SD-card images (JP4.4 or prior) as that’s a mixed environment and may not function perfectly (as the bootloaders and the kernel/OS aren’t in sync).
Note that your point about ‘no possibility of putting all boot content on the external device’ is true for either Nano module - the BootROM in the T210 SoC will boot from the strapped boot device, either QSPI or eMMC. You can only ever load the kernel, kernel DTB, ramdisk, and rootfs/OS from external media (USB, NVMe, SD-card, etc.).
Tom
Ok, thanks for clarifying. Some of my boot chain knowledge is too limited. MaxSPI is new to me. The part I hope to know more about is:
extlinux.conf FDT entry) in the rootfs might be visible to QSPI/MaxSPI and there might be some interesting boot log change when the wrong QSPI/MaxSPI changes are not correct.MaxSPI is purely a SW construct. When Nano was first released (SKU0 devkit w/SD-card), we had a minimal set of boot components on QSPI, and then nvtboot/TegraBoot would pivot to the SD-card for the rest. In R32.5, we went with all of the boot components (firmware, bootloaders, DTBs, etc.) on QSPI, and none on the SD-card. This (a) frees up space on the SD-card for OS-related stuff and (b) allows any Linux OS to reside on the SD-card and (c) allows us to boot from USB, NVMe, etc.
Older SD-cards (<32.5) will boot on a MaxSPI board, but it uses what’s on QSPI, and only loads the kernel/dtb/ramdisk & rootfs/OS from SD, skipping any old bootloaders, etc. on SD. This isn’t fully supported, since the components on QSPI are newer than what’s on the (32.4+) SD-card, and there may be incompatibilities. We always want you to use the full set of components in any BSP, and no mix-and-match.
The opposite case just won’t work, though - older (R32.4-or-prior) QSPI format with a newer (32.5+) SD-card, since the 32.4 QSPI (call it ‘minSPI’) expects to find the remaining boot firmware/bootloaders/etc. on the SD-card, and they are not there. Again, just don’t mix and match.
As to detecting a mismatch, you’d just need to be aware of time/data stamps for kernel, etc. to see if you’ve accidentally swapped old w/new. Always best, IMO, to reflash your SD card w/each new BSP, so you don’t have an old one hanging around.
Note that for the commercial module (SKU2 Nano eMMC), none of this matters, as everything is on eMMC and there is no QSPI to worry about, max or min.
HTH,
Tom
Is the extlinux.conf FDT entry still honored in R32.5+? I assume it is, but if so, the earlier boot stages don’t use the FDT entry, and instead use the content in QSPI. Perhaps just the Linux kernel sees this FDT tree upon Linux itself loading? I ask because it might change instructions to users who want to make device tree changes (it is usually easier/safer to add an FDT entry and a file in “/boot” than it is to flash). I am assuming most users won’t care about changing a device tree in early boot stages, but will want to change device tree for the Linux kernel.
Now we’re getting a bit off-topic, but a quick synopsis:
extlinux.conf has always been able to specify a FDT label, and U-Boot will load it and pass it to the kernel on boot, after attempting to merge any in-RAM DTB info (from the DTB loaded early in boot from flash) with it. I say ‘attempt’ because we’ve discovered some problems lately with the merge when a on-disk (extlinux.conf FDT entry) DTB file is different enough from the one in flash to cause a phandle renumbering, i.e. the end user made some changes & recompiled the DTB with DTC, which can lead to differing phandles. U-Boot (until recently) isn’t aware of the phandle conflict, and can merge in data that can conflict w/other nodes in the end user’s new DTB.
We prefer, if you’ve modified your kernel DTB, that you reflash it (flash.sh -k DTB, etc.) so that the two copies match (and, in fact, if you reflash it, you don’t have to specify it in extlinux.conf). Otherwise, the next release (JP4.6, I think) will support overlays (DTBO) in U-Boot, which means any HW changes (new nodes, props, etc.) you want to make in your DTB can be handled cleanly with a .dtbo file, much like with the Jetson.IO tool already available. U-Boot then can merge in your changes and any HW-probe-related changes by the bootloader stack, w/o any conflicts, and everything is cool.
So short answer, yes, FDT is and always has been supported in extlinux.conf on Nano (and all Jetson boards). But it’s best, if you’ve modified your DTB, to reflash it instead. If that’s just not feasible (maybe your Nano isn’t nearby/accessible, etc.), then use the DTBO option (FDTOVERLAYS in extlinux.conf) instead w/the next release.
Tom
Last question: Will this also be true in Xavier which uses CBoot, but not U-Boot? I ask because it seems likely it has a similar issue with phandle renumbering, but if overlays are added to U-Boot, and not to CBoot, then needing to flash in JP4.6+ will still be true for Jetsons which don’t use U-Boot.
Xavier CBoot is unique in that it gets the DTB late in boot, either from flash or via extlinux.conf, then it probes HW (carveouts, etc.) and applies any new data to the DTB before handing it to the kernel. So there’s no ‘DTB merge’ like there is on T210/T186 w/U-Boot, and no chance for phandle conflicts. And DTBO support isn’t available in T194 CBoot via extlinux.conf, you need to use Jetson.IO to utilize overlays.
Tom