lurk101

That did the trick. Thank you

https://paste.armbian.com/alanupoxos

pi@opi5:~/AoC-2023-cplusplus$ lscpu --all --extended CPU SOCKET CORE L1d:L1i:L2:L3 ONLINE MAXMHZ MINMHZ MHZ 0 0 0 0:0:0:0 yes 1800.0000 408.0000 1800.0000 1 0 1 1:1:1:0 yes 1800.0000 408.0000 1800.0000 2 0 2 2:2:2:0 yes 1800.0000 408.0000 1800.0000 3 0 3 3:3:3:0 yes 1800.0000 408.0000 1800.0000 4 0 0 4:4:4:0 yes 2256.0000 408.0000 2256.0000 5 0 1 5:5:5:0 yes 2256.0000 408.0000 2256.0000 6 1 2 6:6:6:0 yes 2304.0000 408.0000 2304.0000 7 1 3 7:7:7:0 yes 2304.0000 408.0000 2304.0000 Why the odd cortex a76 MAXMHZ values. pi@opi5:~/AoC-2023-cplusplus$ uname -a Linux opi5 5.10.160-legacy-rk35xx #1 SMP Tue Nov 28 02:45:16 UTC 2023 aarch64 GNU/Linux

Boots but eth interface doesn't acquire IP address.

Use nmcli connection show to get the interface's UUID

Well, this fool had the required partition pre-created on the nvme drive and yet the standard install procedure did NOT work.

The standard armbia-install boot from MTD with system on NVME did not work for me! What did work: - Boot from standard Armbian image from SD, then use armbian-install to flash the bootloader to MTD. - dd the standard Armbian image to nvme0n1, power down, remove the SD card, power up.

Problem solved. It was a DNS issue.

Nope. Same problem today. Yet, the addresses resolve just fine. pi@compute:~/build$ ping ports.ubuntu.com PING ports.ubuntu.com(aerodent.canonical.com (2620:2d:4000:1::19)) 56 data bytes 64 bytes from aerodent.canonical.com (2620:2d:4000:1::19): icmp_seq=1 ttl=52 time=94.9 ms 64 bytes from aerodent.canonical.com (2620:2d:4000:1::19): icmp_seq=2 ttl=52 time=94.9 ms 64 bytes from aerodent.canonical.com (2620:2d:4000:1::19): icmp_seq=3 ttl=52 time=94.9 ms 64 bytes from aerodent.canonical.com (2620:2d:4000:1::19): icmp_seq=4 ttl=52 time=93.9 ms ^C --- ports.ubuntu.com ping statistics --- 5 packets transmitted, 4 received, 20% packet loss, time 4004ms rtt min/avg/max/mdev = 93.915/94.648/94.924/0.424 ms pi@compute:~/build$ ping apt.arbian.com PING apt.arbian.com (205.144.171.183) 56(84) bytes of data. 64 bytes from 205-144-171-183.alchemy.net (205.144.171.183): icmp_seq=1 ttl=110 time=62.9 ms 64 bytes from 205-144-171-183.alchemy.net (205.144.171.183): icmp_seq=2 ttl=110 time=63.5 ms 64 bytes from 205-144-171-183.alchemy.net (205.144.171.183): icmp_seq=3 ttl=110 time=63.0 ms 64 bytes from 205-144-171-183.alchemy.net (205.144.171.183): icmp_seq=4 ttl=110 time=63.0 ms

Hmm... doesn't work here! I see the following errors [🌿] Temporarily disabling [ initramfs-tools hook for kernel ] [🔨] mode of '/etc/kernel/postinst.d/initramfs-tools' changed from 0755 (rwxr-xr-x) to 0644 (rw-r--r--) [🌿] Updating [ apt package lists ] [🔨] Ign:1 http://apt.armbian.com lunar InRelease [🔨] Ign:2 http://ports.ubuntu.com lunar InRelease [🔨] Ign:3 http://ports.ubuntu.com lunar-security InRelease [🔨] Ign:1 http://apt.armbian.com lunar InRelease [🔨] Ign:4 http://ports.ubuntu.com lunar-updates InRelease [🔨] Ign:1 http://apt.armbian.com lunar InRelease [🔨] Ign:5 http://ports.ubuntu.com lunar-backports InRelease [🔨] Err:1 http://apt.armbian.com lunar InRelease [🔨] Could not resolve 'apt.armbian.com' [🔨] Ign:2 http://ports.ubuntu.com lunar InRelease [🔨] Ign:3 http://ports.ubuntu.com lunar-security InRelease [🔨] Ign:4 http://ports.ubuntu.com lunar-updates InRelease [🔨] Ign:5 http://ports.ubuntu.com lunar-backports InRelease [🔨] Ign:2 http://ports.ubuntu.com lunar InRelease [🔨] Ign:3 http://ports.ubuntu.com lunar-security InRelease [🔨] Ign:4 http://ports.ubuntu.com lunar-updates InRelease [🔨] Ign:5 http://ports.ubuntu.com lunar-backports InRelease [🔨] Err:2 http://ports.ubuntu.com lunar InRelease [🔨] Could not resolve 'ports.ubuntu.com' [🔨] Err:3 http://ports.ubuntu.com lunar-security InRelease [🔨] Could not resolve 'ports.ubuntu.com' [🔨] Err:4 http://ports.ubuntu.com lunar-updates InRelease [🔨] Could not resolve 'ports.ubuntu.com' [🔨] Err:5 http://ports.ubuntu.com lunar-backports InRelease [🔨] Could not resolve 'ports.ubuntu.com' [🔨] Reading package lists... [🔨] W: Failed to fetch http://ports.ubuntu.com/dists/lunar/InRelease Could not resolve 'ports.ubuntu.com' [🔨] W: Failed to fetch http://ports.ubuntu.com/dists/lunar-security/InRelease Could not resolve 'ports.ubuntu.com' [🔨] W: Failed to fetch http://ports.ubuntu.com/dists/lunar-updates/InRelease Could not resolve 'ports.ubuntu.com' [🔨] W: Failed to fetch http://ports.ubuntu.com/dists/lunar-backports/InRelease Could not resolve 'ports.ubuntu.com' [🔨] W: Failed to fetch http://apt.armbian.com/dists/lunar/InRelease Could not resolve 'apt.armbian.com' [🔨] W: Some index files failed to download. They have been ignored, or old ones used instead. Followed not long after with /build/.tmp/rootfs-df513ef6-6330-4818-aa75-8491643af7fd/root/armbian-bsp-cli-rock-5b-midstream_23.05.0-trunk--1-PC7446-Ve101-H1e37-Be6c1_arm64.deb' [🔨] E: Unable to correct problems, you have held broken packages. [💥] Error context msg [ Installation of /root/armbian-bsp-cli-rock-5b-midstream_23.05.0-trunk--1-PC7446-Ve101-H1e37-Be6c1_arm64.deb failed rock-5b lunar no rockchip-rk3588 ] What am I doing wrong?

The latest versions I see are dated 2023-02-19, the yandex is broken from here. Ah, nevermind. Found it at https://disk.yandex.ru/d/V5AxXNN2yJnOfg

Odd, my boot.cmd file has setenv rootdev "/dev/mmcblk0p1" yet boots just fine from nvme, without sdcard of emmc installed. How did you create boot.scr from boot.cmd? Found it! # Recompile with: # mkimage -C none -A arm -T script -d /boot/boot.cmd /boot/boot.scr

Ok, this works rather well using a non PD 12V supply, however I can't locate any of the dtb overlay files for enabling things like uarts and pwms, nor do I see the /boot/armbianExt.txt file I've grown accustomed to. How does support for system and user selected dtb overlays work here?

I suspect that the Ethernet and wifi failures are because of the 5V 15 watt rpi brick. I've had no problem with my PD supply, but with NVME and Ethernet working I've noticed 1.5 A peak current draw at 12 V (18 W). This is more power than the 5V brick can supply.

@Efe Çetin How does you PR finally resolve the issue? Rename all the .dtbo files, or change the overlay-prefix? BTW, the pd-max-voltage-12v.dtbo for forcing a PD supply negotiation to 12V instead of a default 20V also works well when renamed appropriately.

In the mean time I had to rename the DTBO files from rock3588-....dtbo to rockchip-rk3588-....dtbo so that they could be used in arbianEnv.txt in the overlays= specification. Works fine for UART and PWM.

Thanks, the critical part I'd missed is 'support for PD has been removed'. Not sure where I got the misinformation, but I thought PD negotiation was done early in the kernel, not the bootloader. Things make a lot more sense now.

Pretend I'm a moron and try again. The question I asked was: With the NVME SSD disconnected, why does my Rock 5b boot a Radxa or standard Armbian image from SD, but fails to boot your image. You responded with: The PD power system is 'crap'. As I understand the problem, most PD power supplies will time out before the power negotiation software which resides in the kernel gets to run. The PD supply I'm using has never had that problem. I find it hard to believe that your uboot version is so much slower that it causes this timeout on my PD supply. I don't care either what runs on the box, but I do care that the boot device ordering is wrong on all of the bootloaders I've tried so far. Your bootloader would have fixed that.

Hard to say, I've had so many different configurations on this board in the last 6 weeks. Here's how I did it last time. - The 1st time I started with an unformatted nvme SSD. Then using https://github.com/armbian/build/releases/download/23.02.0-trunk.0186/Armbian_23.02.0-trunk.0186_Rock-5b_jammy_legacy_5.10.110_minimal.img.xz burnt to SD. - Booted the SD then used arbian-install and selected the 3rd option (i think) to flash the boot loader to SPI flash. It's a slow operation, be patient. - Then selected option 1, install to mmc, nvme, or something like that. - Power cycle after removing the SD card. The downside of this configuration is that you can no longer boot from SD, as pointed out previously. This leads to problem with consecutive installs. To workaround the problem I zero out the 1st few blocks of the nvme before shutting down prior to the install. That said, for the time being I've given up on Armbian for the rock-5b and have reverted to to Radxa's Ubuntu server image. I run exclusively headless, except for installs, and that configuration best meets my needs. I've alsways had a trouble free experience with Armbian running on all my previous Rockchip based SBCs so this is a 1st!

Yes, I understand all that, but instead of of giving reasons why it's a bad design maybe tell us why the design fails for so many? I'm not that interested in subjective assessments, I'd like to understand the root cause and how it might be mitigated. As for why the design was chosen, who knows! I would guess that most consumers (of the non nerdy class) already have a PD charger for use with their other devices. After all, who wants to mess around with specialized adapters, risking the possibility of getting a reverse polarity barrel jack (there's no official standard). I agree that 12V would be a better choice and perhaps that could be accommodated in software since a software component has its fingers in the negotiation.

Ok, you have no clue why your image won't boot from SD, so you blame the supply. Fine, I'll just keep using the standard Armbian image. I've wasted enough time on this. I don't need to boot from SD and NVME boot works well.

@balbes150 I use an INVZI USB C Charger 67W, GaN III. As I've said before I've had 0 issues with it. It never fails to negotiate 20V with the standard Arbian image or the Radxa image. I don't think the hardware is crap, I think the idea of negotiating voltage in the kernel rather than in uboot is crap. The bootloader was flashed to SPI flash using the standard Armbian image. As I pointed out, with no NVME connected the standard Armbian image boots fine from SD, but does not boot your image. I can't understand why that would be!!! I thought it might be an MBR vs GPT formatted SD thing, but no that's not it. I tried your image as is, then converted it to MBR but still no-go.

This is very perplexing! With NVME removed https://users.armbian.com/balbes150/edk2/rock5b/Armbian_23.02.0-trunk_Rock-5b_jammy_legacy_5.10.110.img.xz Will not boot from SD. I get solid green LED then nothing else. However, the standard Armbian image boots fine from SD with NVME removed.

Ah! Ok, unplug the NVME 1st.

Ok, but I also tried this one https://users.armbian.com/balbes150/edk2/rock5b/Armbian_23.02.0-trunk_Rock-5b_jammy_legacy_5.10.110.img.xz The SD image wouldn't boot! It boots to nvme and does not use the SD card image.