ps How do I delete this posting? Thanks again…
Dear Dear gtj,
I followed your advice and flashed a new jetpack 2.3.2 to a 256 GB sd card.
It turned out just as you said.
I then attached the SD Card via USB port on my Nano.
Using Gparted, I resized the App partition.
The attachment shows a snapshot of the result.
Thank you gtj for you knowledge in this area.
My next step is boot the new SD card and try to use SDK Manager in offline mode to install target apps.
I am a little worried about the partition differences between SDK manager and Flash to SD card methods.
I did read this article about EFI.
A part that caught my attention:
"Linux
See also: UEFI and Linux disk device compatibility
GRUB 2, elilo, and rEFInd serve as conventional, full-fledged standalone UEFI boot managers for Linux. Once loaded by a UEFI firmware, they both can access and boot kernel images from all devices, partitions and file systems they support, without being limited to the EFI system partition.
EFI Boot Stub makes it possible to boot a Linux kernel image without the use of a conventional UEFI boot loader. By masquerading itself as a PE/COFF image and appearing to the firmware as a UEFI application, an x86 kernel image with EFI Boot Stub enabled can be directly loaded and executed by a UEFI firmware. Such kernel images can still be loaded and run by BIOS-based boot loaders; thus, EFI Boot Stub allows a single kernel image to work in any boot environment.[5]
Linux kernel’s support for the EFI Boot Stub is enabled by turning on option CONFIG_EFI_STUB (EFI stub support) during the kernel configuration.[6] It was merged into version 3.3 of the Linux kernel mainline, released on March 18, 2012.[7] Gummiboot (a.k.a. systemd-boot) is a simple UEFI boot manager that loads and runs configured UEFI images, accessing only the EFI system partition. Configuration file fragments, kernel images and initrd images are required to reside on the EFI system partition, as Gummiboot does not provide support for accessing files on other partitions or file systems. Linux kernels need to be built with CONFIG_EFI_STUB enabled so they can be directly executed as UEFI images.[8]
The mount point for the EFI system partition is usually /boot/efi, where its content is accessible after Linux is booted.[9]"
I looked in /boot/efi/* and found
- /boot/efi/EFI/ubuntu/fwupaa64.efi
and
- /boot/efi/EFI/ubuntu/fw an empty folder
with no other visible entries.
Does fwupaa64.efi support NVMe devices?
A more formal question might be:
Do any current Nvidia systems components (jetpacks, LAT, others) include CONFIG_EFI_STUB support or other NVMe implementation equivalents?
- If not, does Nvidia currently support NVMe at all?
- If so, what documentation or standards should developers use to build high quality and secure components using NVMe for Nvidia, now and in the future?
Could Nvidia folk with knowledge about current and future Nvidia standards and systems please reply.
This information could be critical for vendors such as Geekworm.
https://geekworm.com/collections/nvidia/products/nvidia-jetson-nano-nvme-m-2-ssd-shield-t100-v1-1
Sincerely
Kent Smith
Things to know…
-
When working with the Jetson platforms you have to throw out 90% of what you know or read about the traditional Linux boot processes. You have to completely ignore anything to do with BIOS, EFI, Grub, Lilo, etc. More about that in a minute.
-
The chipset on the T100 board is a USB3 <> PCIe bridge. The side towards the Nano is USB3 and the NVMe plugs into the PCIe side. As far as Linux knows, it’s a USB Storage Device (mostly) like any other. The fact that the storage is provided by an NVMe device is irrelevant.
-
The reason the partition layout is different between an SDK install and the downloaded raw image is that the SDK install includes 2 extra partitions that aren’t actually used making the total 14 instead of 12. The SDK’s goal I believe is to create a quick no-nonsense install that will get a new user a working Nano with the minimum of interaction. I think that’s why it assumes a 16gb SDCard and places the APP partition at the front of the card. If you want more control, you need to use the pre-built SDCard image and burn that to an SDCard yourself.
Ok, back to the boot process. There’s a description here…
https://docs.nvidia.com/jetson/l4t/index.html#page/Tegra%2520Linux%2520Driver%2520Package%2520Development%2520Guide%2Fbootflow_jetson_nano.html%23
After reading that you should now be scratching your head. :)
The very first part of the boot process is the BootROM burned into the Nano module. It doesn’t even run on the main CPU, is runs on a special BPMP processor and it’s main job is to set up the CPU.
There are a few more steps that are run from a small NOR memory device but ultimately, control passes to TBoot. At this time, there is no access to the USB subsystem so the only place that TBoot can be loaded from is the SDCard. That’s the TBC partition. The next step is the CBoot boot loader. Again the USB subsystem isn’t initialized yet so TBoot can only load it from the SDCard partition EBT. All of the process up to now is custom Nvidia process. The next steps are more common to most ARM based platforms… The next step is the U-Boot bootloader. It’s job is to actually start the Linux kernel. Once again, the USB subsystem isn’t available so the only place it can look is the SDCard LNX partition. U-Boot looks for the /boot/extlinux/extlinux.conf file to find the kernel image and the initial ramdisk image. When found, it loads them into memory and starts the real kernel. Once the kernel is in control, it’s all standard Linux from here. It initializes all the hardware, including the USB subsystem and then tries to mount the root filesystem. Since the USB subsystem is theoretically available, the root filesystem can be on any USB storage device, including the T100.
Whew! There’s a problem though. Although the device drivers for the USB subsystem are included in the kernel, The firmware for the USB subsystem isn’t so without further action, you really can’t use the T100 as the root filesystem. The link I posted in my previous post explains how to get around that. Of course there are still the two issues I started this post with. :)
So…
Does Nvidia support NVMe? If you’re using a device like the T100 then it doesn’t matter because it appears like a USB device to the Nano and Linux. If you’re using a custom carrier board that has an NVMe interface connected directly to the Nano module, then the answer is kinda yes. As far as the Linux kernel goes, direct NVMe support is there so the device could be used as the root filesystem. Whether you can actually start TBoot, et. al. from a directly attached NVMe device I don’t know.
Thanks man.
That solved the problem for me as well.
Thumbs up! and great work ;)