Werner

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.

OK. I'll repeat it again with details. Armbian and Radxa images use essentially the same u-boot (in any case, this was the case at the time when I analyzed them). They are assembled from the same sources, so their behavior is the same. My u-boot is significantly different, it is a different source code and configuration, in which errors have been fixed and the configuration has been changed (UART is enabled, the startup order has been fixed, support for PD has been removed, etc.). Therefore, when using a power supply with PD, my version will not work. By the way, I recommend thinking about why radxa disabled the UART console in its u-boot. For the correct launch of my u-boot, you also need to completely erase the SPI, so that its "pieces" do not interfere with the correct launch of the new u-boot from the SD card. For reference, the primary loader (the first stage) is always launched in the strict order of SPI-eMMC-SD polling.

Hardware menu is not exists due to linuxfamily property. Today i'll make a pr to fix it.

I think the power supply might deserve it's own topic.
 
Like balbes mentioned PD is meant for devices with internal battery. There it saves the battery during fast charging by preventing overcharging.
The Rock 5B is further 'borked' since the negotiation starts after the system starts. The advantage is it can be open source (more or less), but the big disadvantage it is so slow most PD chargers stop negotiating during system start in the meantime.
 
If you realise that the power supply in the Rock 5B (IP2315) is just a step-down converter with some logic and a PD car-adapter adds an step-up adapter to the equation you might realise it makes no sence to operate the power input at 20V. While the resistance in the cable might be minimized the power loss in the step-down and the step-up converters are maximized. Most power supplies can achieve 95% efficiency, but cheap step-up/step-down converters can only achieve that when V_in is almost equal to V_out. Normal PD-adapter should work more efficient than 12V car-adapters, but even then if they very efficiently produce 20V which the R5B very inefficiently transformes to 3.3-5V does that make sense?
 
A 20W PD car-adapter adds roughly 0.5W to the power consumption. With a 65W/20V PD car-adapter the adapter might add more, but the step-down converter in the R5B will definitely work more inefficient than at 9V.

We could delete but it would be worth more if you would share your solution.

Hi Namexx
 
If you have anything plugged into the USB port, try it without.

There are some home  routers that only do IPv4 some are known to cause issues if IPv6 is enabled.
If you are on  network using IPv4 then you can try adding a line into /boot/armbianEnv.txt
extraargs="ipv6.disable=1"

I'm traveling at present, but when I get home, I will download an image and test on my board.  
Which image are you using, and how are you flashing it to SD card?

I tested the current build successfully when it was released, but it's always possible that something has gone wrong since then.

Edit:  I was very lucky and got an earlier flight.  I should be back home about one or two hours.

https://docs.armbian.com/User-Guide_Basic-Troubleshooting/

The boot partition is flagged ESP, which the PI3 does not support.
 
Model: Generic MassStorageClass (scsi) Disk /dev/sdd: 32.0GB Sector size (logical/physical): 512B/512B Partition Table: msdos Disk Flags: Number Start End Size Type File system Flags 1 4194kB 273MB 268MB primary fat32 esp 2 273MB 4106MB 3834MB primary ext4  
Removing the ESP flag from the boot partition should allow the image to boot on both the RPi3 and RPi4. This can be easily done using gparted.
 
if you are comfortable using the command line:
sudo parted /dev/XXX set 1 esp off   

Serial console is still best chance to get at least something. Make sure to change verbosity to 7 in /boot/armbianEnv.txt and reboot before attempting this again.

WordPad is even worse. Use only Notepad++ or follow @SteeMan's advise (don't allow the sd card to touch a windows machine).

If you follow that way you could rip kernel package as well. That way the first working images for OPi Zero 2 were made. However Armbian does not want or like to do that since then you could basically directly use vendor provided images.https://docs.armbian.com/User-Guide_FAQ/#why-does-hardware-feature-xy-work-in-old-kernel-but-not-in-more-recent-one
 
At the bottom line it all depends on the development for the SoC or family which in this case is rk35xx. If that grows adding support for different boards that are built around that SoC is easy in comparison but that also depends on having a person that knows how to do that and want to donate their precious time doing so. Both aren't easy to find .
 

Once somebody starts dealing with this hardware. No ETA though
 

Nobody wants to wait but also very few of those are a willing to do something to decrease waiting time. One year was a rough estimation. Mainline development of arm platform is very slow in comparison to x86.
For example it took several years to bring RK3399 SoC to a well matured state and still not all functions are well supported yet. Now think about how long it might take for a mid-grade SoC like H616

Bulk is recommended 😎
 

 

Hi,
 
This is my first try to add a board to armbian build system.
I got a BPI M2S since several months, but only had time recently to investigate on this promising SBC.
I made a PR here, if somebody wants to try it: https://github.com/armbian/build/pull/4597
The main improvements are to be done for the dts file, since I'm not an expert about such file definition. Only 1 ethernet of the Gbit ports is working, since I copy the config from vim3 that share the same hardware for it.
I didn't try to customize u-boot and I use the one for radxa zero2 that works to launch armbian on the board.
armbianmonitor -u is here: https://paste.armbian.com/piyuqajeye
 

PCIe is fully broken by design on H6 SoC. There were some community efforts (mainly by Icenowy) to wrote some hacks that "translate" the broken part into usable data but not sure how successful that was. In conclusion if you want to rely on PCIe avoid Allwinner H6.
 
Also I strongly recommend avoiding tvboxes. For once they are not officially supported (and most likely never will) and for the other these things are sold as cheap as possible and vendors tell you everything that is necessary (including lies like claiming H6 tvbox has 4G of memory which is technically impossible) to make you buy their crap. Also there is a chance that even tough buying the same product as somebody else that internal components change without telling you and breaking potential ways to install Armbian. Solving such issues is up to you. Check https://docs.armbian.com/User-Guide_FAQ/#i-have-a-tv-boxtablet-from-insert-random-vendor-can-i-use-armbian-on-it
 
I personally have a pihole running for years on an Orange Pi One. Yes, that low budged Allwinner H3 with 512M of memory. It is way enough for that purpose. Orange Pi Zero (the older one with H2+ SoC) could do the same with smaller package but no HDMI (who needs monitor anyways when you have SSH). Its onboard Wi-Fi is crap though so don't rely on it.

moved to tvboxes

fixed. Thanks

@cryk_ Provide diagnostic logs with ...
armbianmonitor -u ... and post the link here.  It'll may help others determine what the issue is.
 
The diagnostic logs might reveal why your file system is read-only and not read-write.

This opportunity is necessary for professionals.
I have almost implemented such an opportunity to build and develop packages in a chroot environment.
And this remains only in my local branch for now.
 
First, we need to make a small adjustment in the logic of choosing goals.

Standard comes with all standard tool to be ready to do most common tasks oob.
Minimal comes, as the name implies, with a bare minimum of packages to get a somehow running system.
You can check the build repository on github for package lists.

moved to tvboxes

USBimager
 
https://gitlab.com/bztsrc/usbimager

This seems to fix it.

Ah my bad then. Didn't get that it was onboard.

Probably. I assume some capacitor needs to discharge to erase some transient  memory. Probably unfixable via software.