Hi
I noticed my Nano module is “P3448 180-13448-DAAA-B01”
In Jetson-210_Linux_R32.7.4_aarch64.tbz2.
Questions:
- I have no idea which config is suitable for me.
- I noticed my nano module no emmc built-in, is it normal?
Hi @pantungmin, yeah there is a micro sd card version and emmc version. To flash you can use the “jetson-nano-devkit” config. There is an old post with a similar case here.
Regards,
Andres
Embedded SW Engineer at RidgeRun
Contact us: support@ridgerun.com
Developers wiki: https://developer.ridgerun.c om/
Website: www.ridgerun.com
Thank your clarify
- Also want to know Jetson-210_Linux_R32.7.4_aarch64.tbz2 . included prebuild loader binaries
- Due to I get loader always reboot during power on(see below) and want to reflash loader. I am newer about Nano, and spent time to read online doc below. But no idea to begining flash bootloader. could you have any hints for me about upgrade loader.
[0002.871] Loading kernel from LNX
[0002.880] Found 19 BFS partitions in “spiflash0”
[0003.205] Failed to validate boot-image
[0003.209] Set to failover in the next boot
About eMMC: The Nano and NX format developer kits do not have eMMC. The SD card slot is on the module itself, and not on the carrier board. The full sized TX1 (or any of the full-sized models) have eMMC. Third party modules sold separately are all eMMC models, and none have an SD card slot on the module (any such slot is on the carrier board, and thus firmware and boot is quite different between the two models). SD card models don’t have obvious extra partitions, at least not with tools for looking at ordinary disk partitions. SD card models do have QSPI memory on the module itself, and this is where bootloaders and other “partition-like” content goes on those models. If I mention signing of a partition below, for SD card models, just assume I’m talking about content in QSPI memory.
Something which I am curious about (excerpt of above):
[0002.871] Loading kernel from LNX
...
[0003.205] Failed to validate boot-image
First, it is loading from a partition. Second, the partition being loaded appears to be incorrectly signed.
The reason I find this of interest is that this is not a bootloader issue at this point. There are two ways some content can be loaded: (A) from “/boot” if extlinux.conf specifies such content, and if the content can be found; or (B), from a partition (QSPI in SD card models) if either “A” fails for any reason, or if no extlinux.conf specifies this content. A shorter way of saying this is that valid /boot content takes priority over partition content, but some conditions revert to partition content. For whatever reason we are using partition content and the /boot content cannot be used. Sometimes the content in /boot simply isn’t specified, and sometimes something goes wrong (at this point it doesn’t matter why, but we know we are using partition content).
When a Jetson is flashed, and when those partitions are created (or QSPI if an SD card model), they are signed. The default is a NULL key signing, but it is still signed. In the case of eMMC models there is also a security fuse which can be burned (with a key), in which case the content being flashed to a partition is signed exactly like default content, except that it uses the key used to burn the security fuses (SD card models don’t have the ability to burn those fuses, they only have the NULL key signature).
What I am wondering about is this: Have you ever put anything in a partition with any method other than the flash in recovery mode via a host PC? For example, if dd was used, this won’t honor signing unless you know to use the signing tools first. We don’t have to worry about security fuses since dev kits which are SD card models don’t have fuses which can be burned (they are permanently set to use a NULL key), but the method of adding content to non-rootfs partitions (rootfs is the only unsigned partition) still matters. Either the content you have was not signed, or it was corrupted in some way.
Unless you have a reason for it you could try flashing the Nano without the SD card in it, and just replace all of the content other than the operating system (which is on rootfs, and this in turn is on the SD card of an SD card model dev kit).
If you have the flash software installed on the host PC, then you’ll have the “~/nvidia/nvidia_sdk/JetPack...version.../Linux_for_Tegra/” directory. Within that take a look at the .conf files:
ls -l *.conf
Notice that the common names starting with “jetson-” are symbolic links pointing at combinations of module and carrier board models. One of those is for a nano, and also has qspi in its name. A recovery mode Nano, probably with SD card removed might be flashed by naming that as the target board, and mmcblk1p1 as the location. Example, if you have file “jetson-nano-qspi.conf”:
sudo ./flash.sh jetson-nano-qspi mmcblk1p1
Do you really need to flash just the bootloader? Or are you just wanting to not lose the SD card content?
Incidentally, you could just clone the SD card and use a copy if the latter is the case.
2 Likes
Hi
Thanks your help.
I ran your command, then it could bootup to u-boot and linux kernel now.
sudo ./flash.sh jetson-nano-qspi mmcblk1p1
Device now can get nvidia logo from HDMI and into filesystem with prompt of login, but will reboot later.
- The line @[0010.434] “boot image cmdline: root=/dev/mmcblk1p1”, means Linux kernel root filesystem? But in my case should be at /dev/sdX when ext4 rootfs at USB_storage. is normal?
- The lne at U-Boot say “Board: NVIDIA P3450-0000”, My device is “P3448 180-13448-DAAA-B01”, is normal?
Regards
Peter
[0010.389] Cmdline: tegraid=21.1.2.0.0 ddr_die=4096M@2048M section=512M memtype=0 vpr_resize usb_port_owner_info=0 lane_owner_info=0 emc_max_dvfs=0 touch_id=0@63 video=
[0010.428] DTB cmdline: earlycon=uart8250,mmio32,0x70006000
[0010.434] boot image cmdline: root=/dev/mmcblk1p1 rw rootwait rootfstype=ext4 console=ttyS0,115200n8 console=tty0 fbcon=map:0 net.ifnames=0
[0010.447] Updated bootarg info to DTB
[0010.450] Adding uuid 00000001642d9282240000000a0603c0 to DT
[0010.456] Adding eks info 0 to DT
[0010.462] WARNING: Failed to pass NS DRAM ranges to TOS, err: -7
[0010.468] Updated memory info to DTB
[0010.477] set vdd_core voltage to 1075 mv
[0010.481] setting 'vdd-core' regulator to 1075000 micro volts
[0010.487] Found secure-pmc; disable BPMP
U-Boot 2020.04-g4335beb (Jun 08 2023 - 21:16:44 -0700)sudo ./flash.sh jetson-nano-qspi mmcblk1p1
SoC: tegra210
Model: NVIDIA Jetson Nano Developer Kit
Board: NVIDIA P3450-0000
DRAM: 4 GiB
MMC: sdhci@700b0000: 1, sdhci@700b0600: 0
Loading Environment from SPI Flash... SF: Detected mx25u3235f with page size 256 Bytes, erase size 4 KiB, total 4 MiB
*** Warning - bad CRC, using default environment
...
Ubuntu 18.04.6 LTS yahboom ttyS0
yahboom login: <========== Mounted root filesystem from USB, and get login prompt
[ 23.333516] soctherm: OC ALARM 0x0000000
...
[ 27.816957] nvgpu: 57000000.gpu gk20a_fecs_dump_falcon_stats:200 [ERR] FECS_FALCON_REG_PC : 0xbadfbadf
[ 27.846846] nvgpu: 57000000.gpu gk20a_fecs_dump_falcon_stats:206 [ERR] FECS_FALCON_REG_SP : 0xbadfbadf
[ 28.141366] tegra-i2c 7000c400.i2c: no acknowledge from address 0x3c
[ 28.351071] soctherm: OC ALARM 0x00000001
[ 28.794590] nvgpu: 57000000.gpu nvgpu_set_error_notifier_locked:137 [ERR] error notifier set to 8 for ch 507 <==== reboot
[0000.125] [L4T TegraBoot] (version 00.00.2018.01-l4t-b1625959)
- The line @[0010.434] “boot image cmdline: root=/dev/mmcblk1p1”, means Linux kernel root filesystem? But in my case should be at /dev/sdX when ext4 rootfs at USB_storage. is normal?
No, you should use the one you want to mount rootfs from.
- The lne at U-Boot say “Board: NVIDIA P3450-0000”, My device is “P3448 180-13448-DAAA-B01”, is normal?
It is normal.
I will add that sometimes those messages are from the internal workings of boot code which might be prior to the bootloader running (CBoot, MB1, or MB2 for the older Nano models). What that content (in QSPI for this case) reads or thinks about might be from an internal pointer to the next part of a chain of boot events, and not necessarily yet naming the true boot content (i.e., the boot content of earlier stages might be from a different location than that which the kernel uses in the end). Each stage of boot might be considered its own bare metal operating system with a command line which gets edited as it passes to the next stage.
Technically though, if you have a full serial console boot log, then you’d find one of those lines is the command line passed to the Linux kernel itself. I don’t know from that excerpt if that is the case here, but probably it is. The command line though is not the only way to pass bootup information to the Linux kernel as there is also the ability to inherit from the environment the same as any C/C++ program might when using this:
int main(int argc, char *argv[], char *envp[]) {
Most people seem to leave out char *envp[], but it is there to inherit from via command line. extlinux.conf and the kernel have similar abilities.
Irrelevant trivia I am reminded of: Most people think there is just stdin, stdout, and stderr (and their equivalent in various languages). There is actually a fourth I/O, stdlog. This is a buffered version of stderr. Hardly anyone thinks about it because it is used so rarely.
One reason you might see different devices listed in boot or flash is that the Jetson SoCs often just keep working parts of silicon when new models come out. As an example, if the serial UART works, why redesign it in silicon? If more are to be used, then just copy that silicon and add more silicon which repeats that pattern. The software does not change for this, but you do get a unified driver model whereby something you are using now might have bug fixes for hardware going back over a decade. It’s easier to maintain than creating new silicon which does not do anything different. As a result many of the flash parameters just include specifications for “parts” of a given SoC or carrier board, and only a subset is actually different.
To illustrate, from “Linux_for_Tegra/” on the host PC, run this command:
ls -l *.conf
Notice that the “jetson-*.conf” is just a symbolic link to a less friendly named file. Those files are a combination of the name of the module and the carrier board. If you drill down into these, then you will find they use something like a C #include<> statement. Those in turn might also include something. Part of what the module might include could be new, and part could refer to much older hardware if that part did not change in silicon.
A full serial console log is really needed any time you want to know what is going on, and part of the reason is that not only does the log line matter at the error point, but sometimes you need to see something which occurred much earlier in boot which changes the inherited environment. Or you might want to see which content was used for a subset of the hardware.
Thank your kindly reply, I already boot up success now.
- For boot from SD-Card, it just need wait for time for initilized
- For boot from SD_Storage, the USB_Storage must be the same USB port. otherwise it will reboot after mount rootfilesystem.
In this topic, what I did is only reflash bootloader by
sudo ./flash.sh jetson-nano-qspi mmcblk1p1
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.