phelum

It's looks like I'm wrong. If it's mentioned on the download page then there is support. I'd give it a try. Cheers, Steven

Hi, I don't think that Armbian supports the Nano. I've managed to get my Nano running (except for power-off) with the standard kernels (e.g. 5.16.11) but if you need the Nvidia graphics driver then I think you're stuck with the 4.9.253 kernel supplied by Nvidia. Also, it's not as easy as you might expect to update U-Boot. I'm assuming you have a Nano developer kit where the board has 4GB flash and an SD-card. U-Boot does exist on the SD-card but if you reload the relevant partition you'll also need to update the checksum at the start of the partition. I've tried to work out how to calculate the digest but given up and it seems to be an Nvidia secret. Regardless of this, the boot code on the card isn't used anyway. The boot sequence runs tboot, then cboot, then U-Boot. But all these files are sourced from the 4GB flash rather than the SD-card. It is possible to write to the flash but again the relevant checksum must be written. The code to do this is probably buried in some of the Nvidia x86 programs but these are not open-source. Back in the L4T 4.4 days the boot code sourced U-Boot from the SD-card. But when L4T 4.6 came out the process was changed and U-Boot was added to the flash code and cboot changed to read U-Boot from this flash partition. So changing U-Boot requires re-flashing the relevant partition. All the above is from my research and might not be correct. The Nano is quite a powerful little board but unless you need the Nvidia AI specials then maybe it's not worth playing with due to all the Nvidia specials. If anybody here knows the checksum algorithm then please let me know. Cheers, Steven

Hi, Thanks for the tip. I've added "system-power-controller" to the 77620 node but it has no effect. The Nvidia kernels contain driver code for the "tmpm32xi2c" which seems to be associated with system power. But there is no such code in the standard kernels (e.g. 5.16.5). This is why I was asking if people here were using a standard kernel or a modified one. Cheers, Steven

No, the log is what happens with all the 5.1x kernels (including your 5.10.60 and 5.16.4). The Nvidia kernels (4.9.140 and 4.9.253) do power off the Nano correctly. What I've noted here is that the "Tegra System Off: operation not handled." message appears in the Nvidia cboot code which is in one of the partitions on the SD card and also in the later versions (e.g. 4.6) of the code in the QSPI EMMC.

Hi, Thanks for your work here. I've been playing with the 5.1x kernels on my Jetson Nano and using your configuration has solved some problems for me. One outstanding issue is that I can't power the unit off. "halt -p" goes through the shutdown motions but I end up with the error list below. The standard Nvidia 4.9 kernels do work here. [[36minfo[39;49m] Will now halt. [ 1727.490264] sd 1:0:0:0: [sdb] Synchronizing SCSI cache [ 1727.537882] pci_generic_config_write32: 16 callbacks suppressed [ 1727.537896] pci_bus 0000:00: 2-byte config write to 0000:00:02.0 offset 0x9c may corrupt adjacent RW1C bits [ 1727.553677] pci_bus 0000:00: 2-byte config write to 0000:00:02.0 offset 0x88 may corrupt adjacent RW1C bits [ 1727.563691] pci_bus 0000:00: 2-byte config write to 0000:00:02.0 offset 0x4 may corrupt adjacent RW1C bits [ 1727.575332] reboot: Power down ERROR: Tegra System Off: operation not handled. PANIC in EL3 at x30 = 0x00000000ff8024c8 x0 = 0x0000000000000000 x1 = 0x0000000070006000 x2 = 0x0000000000000060 x3 = 0x00000000ff805570 x4 = 0x00000000ff8054f0 x5 = 0x0000000084000008 x6 = 0x00000000ff80fd40 x7 = 0x0000000000000001 x8 = 0x0000000000017fe8 x9 = 0xffff800011fa5f70 x10 = 0x0000000000000040 x11 = 0x00000000ff80c810 x12 = 0x00000000ff80d5c0 x13 = 0x00000000ffffffea x14 = 0x00000000ff814e28 x15 = 0x00000000ff803b94 x16 = 0x0000000060000085 x17 = 0xffff80001002593c x18 = 0x0000000000000735 x19 = 0x00000000ff815000 x20 = 0xffff800011f31948 x21 = 0x0000000028121969 x22 = 0xffff800011f4b590 x23 = 0x00000000fee1dead x24 = 0x0000000000000802 x25 = 0x0000000000000000 x26 = 0x0000000000000000 x27 = 0x0000000000000000 x28 = 0xffff000085308e40 x29 = 0x00000000ff80d550 scr_el3 = 0x0000000000000735 sctlr_el3 = 0x0000000000cd183f cptr_el3 = 0x0000000000000000 tcr_el3 = 0x000000008081351d daif = 0x00000000000002c0 mair_el3 = 0x00000000004404ff spsr_el3 = 0x0000000060000085 elr_el3 = 0xffff80001002593c ttbr0_el3 = 0x00000000ff814b00 esr_el3 = 0x000000005e000000 far_el3 = 0x0000000000000000 spsr_el1 = 0x0000000020000005 elr_el1 = 0xffff8000100f1cf8 spsr_abt = 0x0000000000000000 spsr_und = 0x0000000000000000 spsr_irq = 0x0000000000000000 spsr_fiq = 0x0000000000000000 sctlr_el1 = 0x0000000034d4d91d actlr_el1 = 0x0000000000000000 cpacr_el1 = 0x0000000000300000 csselr_el1 = 0x0000000000000000 sp_el1 = 0xffff800014043c50 esr_el1 = 0x0000000000000000 ttbr0_el1 = 0x00000001075d8000 ttbr1_el1 = 0x1edc000085b22000 mair_el1 = 0x000c0400bb44ffff amair_el1 = 0x0000000000000000 tcr_el1 = 0x00000034b5503510 tpidr_el1 = 0xffff8000ecd0b000 tpidr_el0 = 0x0000ffff80cd02c0 tpidrro_el0 = 0x0000000000000000 dacr32_el2 = 0x0000000000000000 ifsr32_el2 = 0x0000000000000000 par_el1 = 0x0000000000000000 mpidr_el1 = 0x0000000080000000 afsr0_el1 = 0x0000000000000000 afsr1_el1 = 0x0000000000000000 contextidr_el1 = 0x0000000000000000 vbar_el1 = 0xffff800010010800 cntp_ctl_el0 = 0x0000000000000000 cntp_cval_el0 = 0x0000000000000000 cntv_ctl_el0 = 0x0000000000000000 cntv_cval_el0 = 0x0000000000000000 cntkctl_el1 = 0x00000000000000a6 fpexc32_el2 = 0x0000000000000700 sp_el0 = 0x00000000ff80d550 isr_el1 = 0x0000000000000080 cpuectlr_el1 = 0x0000001b00000047 cpumerrsr_el1 = 0x0000000000000000 l2merrsr_el1 = 0x0000000000000000 gicc_hppir = 0x00000000000003fe gicc_ahppir = 0x00000000000000d0 gicc_ctlr = 0x00000000000005eb gicd_ispendr regs (Offsets 0x200 - 0x278) Offset: value 0000000000000200: 0x0000000000000000 0000000000000204: 0x0000000000000400 0000000000000208: 0x0000000000000000 000000000000020c: 0x0000000000000000 0000000000000210: 0x0000000000000000 0000000000000214: 0x0000000000000000 0000000000000218: 0x00000000000b0000 000000000000021c: 0x0000000000000000 0000000000000220: 0x0000000000000000 0000000000000224: 0x0000000000000000 0000000000000228: 0x0000000000000000 000000000000022c: 0x0000000000000000 0000000000000230: 0x0000000000000000 0000000000000234: 0x0000000000000000 0000000000000238: 0x0000000000000000 000000000000023c: 0x0000000000000000 0000000000000240: 0x0000000000000000 0000000000000244: 0x0000000000000000 0000000000000248: 0x0000000000000000 000000000000024c: 0x0000000000000000 0000000000000250: 0x0000000000000000 0000000000000254: 0x0000000000000000 0000000000000258: 0x0000000000000000 000000000000025c: 0x0000000000000000 0000000000000260: 0x0000000000000000 0000000000000264: 0x0000000000000000 0000000000000268: 0x0000000000000000 000000000000026c: 0x0000000000000000 0000000000000270: 0x0000000000000000 0000000000000274: 0x0000000000000000 0000000000000278: 0x0000000000000000 000000000000027c: 0x0000000000000000 Any suggestions will be greatly appreciated. Are you using the standard kernel or are patches required ? Thanks, Steven

Hi, Great news that you've got somewhere. With the "eth0" name being changed to "eth............", this occurs because the kernel (or udev or something) wants to include the MAC address in the name. This can be stopped by adding "net.ifnames=0" in the kernel bootargs command line. I was chasing a bad idea because I figured your board was an "HC2" and U-Boot was intended for an "xu4". But apparently they're the same or compatible at least. But note the single line "if" test under the 4 lines that set fdtfile for various boards. It's a long line that checks for a file called ".next" and if it's not found the code sets fdtfile to ".....xu3". The check for whatever file was 88701 bytes was a clue. As you say, adding a dummy file called ".next" to your /boot directory probably would solve the problem here. From a software distribution viewpoint I would add the "net.ifnames=0" to the bootargs so the DEVICE= clause doesn't have to be changed for every board and the standard "DEVICE=eth0" should work for all boards. Also I don't see why the ".next" file is missing. Most Armbian distributions contain such a file (size 0) and this is detected by the U-Boot script and tells it to use the mainline kernel (and ....dtb in your case). But it's great that it's working now so I'd leave things as they are and all the work you've done will help anybody else that hits the same problems. Cheers, Steven

Hi, In one of your previous posts you listed some U-Boot code that changed the fdtfile variable depending on the board name and you noted that your board wasn't mentioned. The U-Boot log shows it is loading a flattened device tree file that is 88701 bytes long. Can you check in your /boot/dts directory and check if the .dts file for your board is 88701 bytes ? Somefile.dts files provide hardware details for the drivers and using the wrong one might cause all sorts of problems. What I.m checking here is that U-Boot is loading the correct .dts file for your board. -- Steven

Hi, Good to see you've got the monitor. Can you check that the correct .dts is being loaded ? See if the one you should use is 88701 bytes ? If not you could override the choice in boot.scr (setenv fdtfile .....). Cheers, Steven

Hi, What OrangePi board do you have ? I have an early model OrangePi A20 board and the .dtb you mention does work, This is when using a 5.x.x kernel. It will also run with an old 3.4 kernel but this doesn't use a .dtb and I don't think the standard boot.src will boot it anyway. Cheers, Steven

Granted it's not a very attractive suggestion. It does involve purchasing a specialised device and then learning how to use it. And it won't actually provide a solution, just some clues hopefully. Can you download the software release again and try with a different uSD card ? Or just try some other release to verify that the hardware is okay ? Cheers, Steven

Hi, The M=/sr/src/... looks wrong to me. Shouldn't it be M=/usr/src/... ? Update: I think that this make has to be done on the system that built the kernel. This was the case with the old Realtek drivers I built for RPi kernels. The make needs a valid "build" softlink in the modules directory. This softlink is only valid where the modules were created. Cheers, Steven

Hi, I think you need a serial cable connected to the UART0 port (try 115200 8N1). This will show you the U-Boot output. The U-Boot output should end with "Starting kernel ...". If you see nothing after this then either the kernel isn't starting or its bootargs are specifying the wrong console for output. The primary console in the bootargs should be "ttyS0,115200". I hope this helps. I don't know the board and are assuming it uses the standard Armbian boot script. Cheers, Steven

Hi, Thanks for the pointer to the patches. I've applied some to the Denx master and it now works. I suspect the clock patches were the critical ones. Cheers, Steven

Hi, I'm trying to generate a U-Boot for my OrangePi Plus board (H3). I'm using the Denx 2021.10 release and have tried the standard defconfig for this board and also variations of this config. Starting the kernel is fine but the kernel crashes/hangs when starting if I'm using HYP (nonsec) mode. Starting in sec mode works but this only enables one of the four CPU cores. The kernel crash/hang occurs while executing "udevadm trigger --action=add" but I can't determine exactly what is being enabled when the error occurs. Trying different kernels (including the Armbian 5.10 version) show no difference. The Armbian U-Boot (2021-10 dated August 2021) does work but I can't get a similar version even when I use the Armbian config from apt.armbian.com. Can anyone provide a link to the Armbian source so I can find out what has been fixed for this H3 board. Perhaps a board_init function has been added. Thanks, Steven

To enable U-Boot to boot an old kernel the U-Boot option CONFIG_ARMV7_NONSEC must NOT be selected. I suspect it is selected in the Armbian U-Boot. There is also the CONFIG_OLD_SUNXI_KERNEL_COMPAT option that apparently slows DRAM access and is sub-optimal for new kernels. I've tested with this option not selected and the OrangePi A20 board here works fine with both old and new kernels booting with this new U-Boot. Cheers, Steven