chwe

haha my fault.. I added a more or less proper support to csc for the board back then..
 
https://github.com/armbian/build/blob/e8e0c698f19204fd63b89132867725ce7dade8db/config/boards/bananapim2zero.csc#L7
if you disable g_serial, I assume it will just work as USB otg but not tested, don't even know where in my 'retired electronics box' the board actually is..  

or... you SSH into a working SBC and use it's spare UART pins to ttl into the non-working SBC... 
Likely to be one of the most silly things I've ever did with an SBC.. But hey, it works...  (at least @martinayotte will like it.   )
 

 

 
 
do we have UART2 and UART3? at least on mine (4.14) we use UART3...  @TonyMac32? Or was it back then when we used UART2? Can't remember anymore..  

Access to a console can be mandatory when you SBC doesn't work as expected (e.g Network or HDMI output doesn't work). When SSH/Display access isn't possible access to console via UART is the best way to get a clue where your SBC hangs. This short tutorial should give you an introduction how this works. For some boards, armbian implements an USB gadget mode (a 'fake' serial console over microUSB) describen below. As a reminder an USB-UART bridge is always prefered over USB gadget mode whenever possible (UART get's initialized before the gadget driver and also before HDMI, means even if you don't get a proper output from HDMI or gadget mode console, it is possible that UART will give you the needed information).
 
Prerequisites:
We need an Terminal program to access the console. If you use Linux on your host system I prefer picocom (something like minicom will also do the job) which can be installed:
on debian a like systems:
sudo apt-get install picocom from arch community repo:
https://www.archlinux.org/packages/community/x86_64/picocom/
 
on fedora systems:
yum install picocom on Mac OS X:
brew install picocom on Widows we use PuTTY:
 
https://www.chiark.greenend.org.uk/~sgtatham/putty/latest.html
 
UART USB Adapter:
There are various USB-UART bridges e.g FT232 (and fakes of them, cause FDTI is expensive ), CH340/1,PL2303 or CP2102
Normally it doesn't matter which one you use. I prefer the (probably fake) FDTI on the right side, but the CH341 does also a good job:

The only thing which is needed is that the signal-level matches with your SBCs needs (this is mostly 3.3V expect some Odroids e.g HC1 which has only 1.8V!).  Most of these USB-UART bridges have jumpers for 5V and 3.3V, make sure that you use the 3.3V.  
You've to figure out which pins on your SBC are debug UART (they've mostly a own 3 pin header, sometimes it's on the large pin header e.g. Tinkerboard) and then connect:
GND --> GND RX --> TX TX --> RX You've to check dmesg (linux) or run devmgmt.msc (windows) to know which device you use. 
Linux:
[256597.311207] usb 3-2: Product: USB2.0-Serial [256597.402283] usbcore: registered new interface driver ch341 [256597.402341] usbserial: USB Serial support registered for ch341-uart [256597.402392] ch341 3-2:1.0: ch341-uart converter detected [256597.404012] usb 3-2: ch341-uart converter now attached to ttyUSB0 --> Device will be /dev/ttyUSB0
Windows:
for windows 10 (https://www.google.ch/search?client=opera&q=find+arduino+port+windows+10&sourceid=opera&ie=UTF-8&oe=UTF-8)
Something like the picture in USB Gadget Mode part of the tutorial should show up)
 
Armbians default settings are (expect some RK devices):
For Picocom:
picocom -b 115200 -r -l /dev/ttyUSB0 and for some RK devices:
picocom -b 1500000 -r -l /dev/ttyUSB0 For PuTTY:
You've to set configuration in 'Serial'. COM11 is just an example and needs to be checked first, Speed (baud) needs to be changed when you deal with the few RK boards which need 1500000.

 
OS X:
TBD
should be similar to Linux whereas the naming differs a bit. See: https://forum.odroid.com/viewtopic.php?f=53&t=841 as an example with minicom.
 
Normally you connect the USB-UART bridge to your host computer (and the SBC) and start picocom/putty before you power the board to ensure you get the full bootlog and not only parts of it. 
 
USB Gadget Mode
Several board (see list) for which official armbian images exist (or csc images can be built) have no HDMI display. On those boards there's USB gadget mode driver activated so that you can have console access to them via USB connection. The following short tutorial describes how you can access to console from Linux (don't have a windows machine here at the moment, I may check it later):
 
install picocom connect your board via USB to your host computer (it should be one which is able to power an SBC via its USB port) check dmesg for the device showing up:  [184372.603816] usb 3-2: Product: Gadget Serial v2.4 [184372.603818] usb 3-2: Manufacturer: Linux 4.14.65-sunxi with musb-hdrc [184372.660041] cdc_acm 3-2:2.0: ttyACM0: USB ACM device [184372.660402] usbcore: registered new interface driver cdc_acm [184372.660403] cdc_acm: USB Abstract Control Model driver for USB modems and ISDN adapters  
connect to it via picocom (in this case 'picocom /dev/ttyACM0'):  chwe@chwe-acer:~$ picocom /dev/ttyACM0 picocom v2.2 port is : /dev/ttyACM0 flowcontrol : none baudrate is : 9600 parity is : none databits are : 8 stopbits are : 1 escape is : C-a local echo is : no noinit is : no noreset is : no nolock is : no send_cmd is : sz -vv receive_cmd is : rz -vv -E imap is : omap is : emap is : crcrlf,delbs, Type [C-a] [C-h] to see available commands Terminal ready Debian GNU/Linux 9 orangepizero ttyGS0 orangepizero login: root Password: You are required to change your password immediately (root enforced) Changing password for root. (current) UNIX password:  
I assume if you use the same settings in something like putty on windows and you check which 'serial' device shows up in *where windows shows connected devices - I forgot it* you should be able to access it from windows (someone motivated may confirm this).  
For Windows:
run devmgmt.msc and search for the serial device (in this case COM3) and connect to it via PuTTY (thanks to @hjc):

for windows 10 (https://www.google.ch/search?client=opera&q=find+arduino+port+windows+10&sourceid=opera&ie=UTF-8&oe=UTF-8):
(even the tutorial is for arduinos, it should be similar for every 'COM device')
 
Currently boards with USB gadget mode:
bananapim2plus bananapim2zero nanopifire3 nanopim3 nanopineo2 nanopineocore2 nanopineoplus2 orangepizeroplus nanopiair nanopiduo nanopineo olimex-som204-a20 orangepilite orangepi-r1 orangepizero orangepizeroplus2-h3 orangepizeroplus2-h5 tritium-h3  
The silly approach
For those, who want to save 1$ for an USB-UART bridge, you can spend 10$ for an OrangePi Zero and use its spare UARTs to log into an other SBC...  SSH --> opi, ttl --> Tinkerboard
For those loving text more than videos:
SSH to your SBC sudo armbian-config --> system --> hardware  to activate an spare UART (in this case it was UART2, will give you ttyS2) reboot picocom -b 115200 -r -l /dev/ttyS2  
 

See:  https://asciinema.org/a/B87EOGhc0gx9oikMAGEG94lXR

 
 

@piter75 @Pedro Lamas
Helios64 also encounter some random crash, yesterday we tried to redefine opp just 408 MHz and 1.4/1.8 GHz and we don't see any random crash anymore.
It seems similar DVFS problem as discussed in this thread. Then our customer point us to odroid n1 issue at
https://forum.odroid.com/viewtopic.php?t=30303
Maybe you can give it a try on Nano Pi M4v2.
 
We are still testing on Helios64 (with value 40000), so far with reboot and power cycle does not trigger any kernel crash.

challenge accepted
 
Todays special:
 
Schweinshaxe mit Knöpfli
Knöpfli is Switzerlands pendant to 'Spätzle'.  Schweinshaxe (Ham hock), and for those not knowing them:
 here we go..
 
user: ~$ time meal.sh real ~2h30min user ~40min sys ~2h First we start with the Haxe. We rost them of both sides for around 2-3mins in a metal bowl on the hotplate.

First on the side where the bones are smaller, then on the other side. We add 2 roughly cutted onions and carrots and let them rost for around 5mins before adding a glass of vine.

We let the vine now reduce a little bit before adding bouillon (as much as needed so that they are not completely covered). They're no cooked for around 1h30mins at 150°C and the last 30mins at 200°C in the oven (use the liquid to 'moisten' them every 15min). 
Knöpfli:
We mix 500g flour with 300mL milk (or 150 milk 150 water), 3 eggs a bit of salt (one teaspoon) and if you like a bit of nutmeg. As soon as it is well mixed we let it rest for 30mins.
 
A big pan is filled with water and heated up until it boils. The knöpfli dough is then pressed through a 'perforated sieve' (there are special ones for 'Knöpfli' but mine comes from a steam cooking set and works also well ).

as soon as they swimm (normally immediately), they can be skimmed wit a normal sieve and collected. If you want you can roast them now in butter and add some roasted onions on top but it also works well without, or as I do add cheese on top. Similar you can add some honey on top of the 'haxen' for the last 5-10minutes for a nice crust (I guess the germans adding Soda in the end for the crust, maybe the Bavarians here knowing it? ).  
In the end, it should look somehow like that:

 
Things you need (for ~4 persons):
2 onions 2 carrots 4 haxen 500g flour 3 eggs 300mL milk a glass vine, a bit of bouillon, salt, oil (butter)  

so no more hiding for @TonyMac32 btw. didn't have @JMCC also mod rights? and speaking about mods, due to busy times I had to step back from the whole project for quite a while now... Things cleaned up a bit and I might find some time to do arm related linux stuff again but likely not as active as before and so I decided to only focus on stuff I enjoy and I'm interested in. honestly 'customer service' aka user complaining about random stuff doesn't work isn't something I enjoy anymore. So @Igor @Werner and @lanefu (or who ever is in charger for that now) feel free to revoke the mod status.

So, I tried to adapt @Kwiboo and @jernej patches on my 5.6 branch, but this made the kernel fail to boot for no visible reason.

Since I were able to boot it without the VPU patches, I'm convinced that it's their readaptation that broke something.

The patches applied are here : https://github.com/Miouyouyou/RockMyy64

If someone wants to play with them and determine which one break the boot process.



 

IMO as easy as it is.. as long as we've no proper mainline drivers for the VPU stuff and 4.4 allows us to build debian/ubuntu on top of 4.4 without affecting much. we can stick to it..
 
I assume rockchip will rebase their BSP on something newer in the future (even their most recent SoCs are integrated into 4.4, e.g rk1808 and rk1806) and I don't think they go EOS prior to 4.4 goes EOL. Btw.. all the camera stuff also is a 4.4 only thing at the moment.. and we've a bunch of boards with doublecam ect. now.. for sure something people might get interested in once it works..
 
So I guess the way to go is base rockchip64 and rk3399 on the same BSP kernel (this release), base both on the same patchset (maybe this maybe next) base all on upstream u-boot (next release - rochchip64 is based on the bsp u-boot) and then we can merge it.. I guess by compile the mali stuff as modules we might get around having Utgard (rk3328) and Midgard (rk3399) in the same kernel.. and otherwise.. we may just have 2 slightly different configs whatever works here.. Or prioritize rk3399 over rk3328 in terms of mali support (we clearly see that more boards based on rk3399 are developed for those usecases - but let's call this the nuclear option.. :D)...
 
If you feel motivated - go for it. don't let my rants about 4.4 let yourself demotivate.. :D  In general I would be a fan if the buildscript allows a quick way to produce debs for custom packages. And I'll still play with 4.4 for a while anyway cause display and cameras on rk3399 are untouched till now.. and it's on my list to play with..
 

In order to enumerate the major issues that are *still* valid now, I'm creating a 'crash dump' thread.
The idea is simple, if your RK3399 board crashed recently, you just :
 
Write what happened during the crash; Provide the link you got from sudo armbianmonitor -u , after the crash happened; Provide the content of /var/log/kern.log (if this file is present on your system) (attach it or copy the content on pastebin and link it here).  
No discussion here.
Feel free to create a new dedicated thread afterwards to talk about the problem you encountered.
 
Minor issues are welcome too, if they trigger a BUG message in your logs. Just state that it's a minor issue.

IMO as easy as it is.. as long as we've no proper mainline drivers for the VPU stuff and 4.4 allows us to build debian/ubuntu on top of 4.4 without affecting much. we can stick to it..
 
I assume rockchip will rebase their BSP on something newer in the future (even their most recent SoCs are integrated into 4.4, e.g rk1808 and rk1806) and I don't think they go EOS prior to 4.4 goes EOL. Btw.. all the camera stuff also is a 4.4 only thing at the moment.. and we've a bunch of boards with doublecam ect. now.. for sure something people might get interested in once it works..
 
So I guess the way to go is base rockchip64 and rk3399 on the same BSP kernel (this release), base both on the same patchset (maybe this maybe next) base all on upstream u-boot (next release - rochchip64 is based on the bsp u-boot) and then we can merge it.. I guess by compile the mali stuff as modules we might get around having Utgard (rk3328) and Midgard (rk3399) in the same kernel.. and otherwise.. we may just have 2 slightly different configs whatever works here.. Or prioritize rk3399 over rk3328 in terms of mali support (we clearly see that more boards based on rk3399 are developed for those usecases - but let's call this the nuclear option.. :D)...
 
If you feel motivated - go for it. don't let my rants about 4.4 let yourself demotivate.. :D  In general I would be a fan if the buildscript allows a quick way to produce debs for custom packages. And I'll still play with 4.4 for a while anyway cause display and cameras on rk3399 are untouched till now.. and it's on my list to play with..
 

Not if we put all RK3399 boards in rk3399, and all RK3328 in rockchip64. In that case, we could just keep our current kernel config and that would work.

just a short one.. and I didn't read all of it.. working on:
rk3399 to 5.6 (more or less done with: https://github.com/armbian/build/pull/1759 but testing needed especially for everything except pbp) display of pinebook pro working with mainline kernel - same PR camera working on 4.4 for pinebook - not even started yet I would love to merge rk3399 and rockchip64 bsp kernels to keep maintenance easier there - let's see if we get the mali mess sorted out there rk1808 into wip - the boards are there.. but time is missing and kernel source will be a pain maybe further cleaning of opi 4b DT

So you suggest to change the command to "command" right? I tried it but nothing happen. Maybe your suggestion works, but the command itself doesn't. As i know, all current kernel boot parameter can be found on /proc/cmdline file, but there isn't.
 
Solution found:
I tried to use some of the texts you suggest, specifically the extraargs=video=composite-1:d (without quotes) works.
Seems that the script look for the extraargs= prefix and add everything next to kernel parameters.
It appear on /proc/cmdline and the command seems to work, now that connector is listed ad "disconnected".
Thanks a lot for the help and the dedicated time!

I would try "video=composite-1:d".. this goes in over u-boot variables, and they tend to mess up stuff.. cause it's then more like extraargs=video=composite-1:d whereas it should be extraargs="video=composite-1:d"..
 
 

with the newest pushed to my PR:
https://github.com/armbian/build/pull/1759#issuecomment-601162767
 
dev images with a working display can be built, the display is currently rather dark (I guess we've to tweak the defaults from the pwm driver a bit I had it brighter in mind when using the stock OS).. The mouse is somehow bugged so an external mouse is needed and you need to build with extrawifi=no cause they didn't survive moving dev to 5.6
 
For those waiting for prebuilt images based on 5.6 this ain't gonna happen yet. it's simply not ready yet to deal with debug and users at the same time. And the PR involves to move pinebook to rk3399 with upstream u-boot but this goes in hand with a change in the bsp kernel (from ayufan to friendly arm) and guess what.. the display does not work there..
 
but mainline with 5.6-rc6 will work. The PR needs a lot of review tho..
 
for those wanna see a lot of errors in dmesg
http://ix.io/2eGz
 
so to summarize:
display works wifi works keyboard works desktop works touchpad doesn't everything else was not tested (ah and restart doesn't work neither atm). PR needs quite some review work and testing for other boards cause.. well we all know what happens when we switch a kernel right?

to our luck this is not a forum only for moderators right? @Igor/ @lanefu if my style of moderating stuff is no longer valuable you can happily revoke my moderator rights then.. I'll spend my time on github and PM depending on motivation.. A forum needs to work for its users not only for the moderators. After all we as moderators do only a bit of housekeeping to keep the rest going.
 
I favor the less active moderating style where you only take actions when things run out of control, either due to people insulting each other or it gets bloated by useless crap not related to the topic at all.. as long as things go more and less smooth I don't see a reason to either cut peoples rights or giving them 'official' warnings.. Others might have a different moderation style and that's also fine.. Different people will have different approaches how to solve things. Not everyone has to solve it the exact same way as I do but being able to edit posts is a feature people use and there are reasons to have it. and if 12 out of the 8204 users abuse it we're talking about less than 0.15% 'bad citizens'.. IMO a percentage we can and must accept. I'm confident that a higher percentage will use the same feature in a sane way..
 
Obviously if I see spammers I flag them, game over.. next one will come, next one will be banned as soon as it gets spotted.. Ofc this won't keep the forum a 100% clean from spam, but I can life without a 100% clean forum.
 
 
 

the RCs should be 'somehow' predictable.. e.g. for the linux kernel you know it's monday morning (europe) when the next one drops in how many RCs we have mostly depends on how smooth things go.. so it is possible that the releasedate is not always 100% clear.. I guess it's up to the release maintainer to decide when things are mature enough, but maybe we need a few 'must haves' and a few 'this will delay' defined (means if, it's important enough that it will delay a release).. the images which are finally released should be somehow reproducible.. something like ./compile.sh $RANDOM_FANCY_VARIABLE=release_2002 and it fetches exactly the sources which were used to produce the release (either over the armbian repo/sources) or by commit hash (which can be problematic from time to time, ask @TonyMac32 and the story of rockchip). So that someone who wants to build a 'know working' (in case it was tested for the board in question) image can build and patch on top of the release.. except the commits which alternate the rc numbers in the buildscript rc's should IMO have no commits which are not available in master as well so that after the release we can go 'back to work' without a discussion what we've to cherry pick from the release to work on master, this also means if someone wants to bring up a fancy feature during rc this must imo kept 'on hold' until the release is here.. Otherwise we end in the same mess as we had between master and our 'development' branch and all other attempts to have a 'stable' branch.. for sure stuff I didn't thought about yet..

if upstream means armbian github.. if yes.. done see:
https://github.com/armbian/build/commit/3b3d46ca7f1963e04c0ca98e68056ca14a9e94b4
 
thanks for investigating and sharing..
 
@Igor can you rebuild and push to download page.. Can't test cause I don't find my board. @Xmoe can you test after its?

What I have found out about this problem:
The Bananapi R2 needs the SD card to have special headers in the first 2k of space, after that comes a preloader which is then in turn loading u-boot. Those headers and the preloader are distributed as binary blobs (found in build/packages/blobs/mt7623n/BPI-R2-preloader-2k.img of the build tool).
As it turns out, the blob of the preloader is a bit older, which had a restriction on the size of the "u-boot.bin" it could load. There has been a newer release which increases the allowed max size of "u-boot.bin" that is loaded (http://forum.banana-pi.org/t/which-preloader-image-to-use/4602/24). So what happened is probably following: over time u-boot got more and more features and as such the u-boot-binary grew larger, so much so that at some point it was too large for the preloader. It can be fixed by upgrading the binary blob for the preloader to this one: https://github.com/BPI-SINOVOIP/BPI-files/blob/master/SD/100MB/BPI-R2-preloader-DDR1600-20191024-2k.img.gz
(as outlined in the forum post linked above).
 
Steps to fix the build process:
1) Download and unpack https://github.com/BPI-SINOVOIP/BPI-files/blob/master/SD/100MB/BPI-R2-preloader-DDR1600-20191024-2k.img.gz
2) Rename to "BPI-R2-preloader-2k.img"
3) Move to "build/packages/blobs/mt7623n/BPI-R2-preloader-2k.img" (replace the old one by doing so)
 
Steps to fix the provided images from https://dl.armbian.com/bananapir2/archive/
1) Download and unpack https://github.com/BPI-SINOVOIP/BPI-files/blob/master/SD/100MB/BPI-R2-preloader-DDR1600-20191024-2k.img.gz
2) Rename to "BPI-R2-preloader-2k.img"
3) Be careful with the `dd` command:
4) Patch the images by writing the new bootloader into the images using
dd if=BPI-R2-preloader-2k.img of=<PATH/TO/ARMBIAN.img> bs=1k seek=2 status=progress conv=notrunc So for example it looks like this:
dd if=BPI-R2-preloader-2k.img of=Armbian_19.11.3_Bananapir2_bionic_legacy_4.19.85_minimal.img bs=1k seek=2 status=progress conv=notrunc The command skips the first 2k of the armbian.img (given by seek=2 in combination with bs=1k) and then writes the new bootloader at that location, right over the old one. The `conv=notrunc` part makes sure that the rest of the original file doesn't get cut-off.
Now you have a patched img which you can burn to your SD card.
 
This would be great to be fixed upstream, but right now I don't know how to.

if there would only be a SBC which has on board LIPO charging features with powerdetection and that boardvendor would sell cells which fit to the board...
 
oh wait..
https://www.olimex.com/Products/OLinuXino/A20/A20-OLinuXino-LIME2/open-source-hardware
 
such boards exist..

and sometimes it's more or less the 'works for me' approach where it worked in the first place for 'developer x' and as long as nobody could show the opposite it was assumed to be 'good'. Mostly with one or maybe two boards of the SoC in question.. So our sample amount to optimize parameter might not be high enough to call this scientific. So our settings are based on observations but likely not on a scientific relevant sample amount.
oh most of the few OC-er I know spend an unhealthy amount of time to ensure their OC setup works perfect stable at highest possible settings for their CPU/GPU/RAM, probably a way more time than we invest in our settings (my last AMD64 except my notebook where thermals don't allow to think about OC at all is now 7years old and has probably 2-3k hours stable at slightly overclocked settings, I don't see a difference between overclocking between architectures)..
 
Now back to the topic and back to my observations.. I probably packed the linux kernel with 7z a few hundred times when I played around zram trying to find a difference in performance between lzo and lzo-rle (which is claimed to be faster on arm, and 7z is great to soak up a lot of memory). The board itself run for roughly 2 weeks with the image (5.3 kernel back then) and 7z run for hours over night packing and unpacking kernel sources. On my board I didn't notice instabilities except oom can kicks in (it mostly happened when trying to compile large libraries, but also happens sometimes with 7z and reducing available ram with kernel bootargs below 2GB iirc - could be less, I barley keep notes of such stuff when I don't see promising results. I sometimes should, turns out my brain runs oom too and I forget stuff over time). On my NanoPi M4V2 our default 2GHz/1.5GHz settings worked just fine.. Could be that I just got 'a better board than yours' which allows higher defaults (the same happens in AMD64 world - some CPUs from the same spec just perform better than others) or that something else on your settings isn't in a great shape and if this is the case I would bet on your powersupply. We see first indications that we run into the same nightmare with powering as we did with microUSB back then now on boards using USB-C in 'dump mode' being not PD compliant (USB-C is better than microUSB but the boards it's mostly used are also more powerhungry so being better doesn't mean being good). My setting was headless with a RPi4 PSU which is to my knowledge rated at 5.1V/3A. What PSU did you use for your board.
 
@piter75 (maybe adding the other usual suspects too, so @TonyMac32 and @martinayotte) if this turns out to be a issue for m4v2 whereas the other boards do fine we could simply solve it by DT overlay and having it as default for those boards do well and disable it for the M4V2. Similar to https://github.com/armbian/build/blob/e78f6db215c9444ce83b8e80c85af88158ce4c2e/config/boards/orangepizero.conf#L6 to bring up USB2 on pinheader by default.
 
 

it's not the distributor - it's the company behind NanoPi boards..
 
IMO the whole thread can be moved to: https://forum.armbian.com/forum/31-sd-card-and-psu-issues/
 
NanoPi M4 being not PD-compliant and therefore might be troublesome is mentioned on the dowloadpage:
 
linking to
btw @Igor or @lanefu we might add the same disclaimer from nanopi m4 to the orangepi 4 cause this board will have the same issues (I updated the thread but forgot my credentials to the WP admin board to do it on my own - feel free to remove my rights there anyways I didn't do much maintenance of it and honestly don't plan to change that in the future).
 
(hidden cause not really an advice more a hack to maybe achieve what you want but not what you should - having a sane powering for your setup)
 
3 amps at 5V is sufficient for the NanoPi M4 in most scenarios I had. But if you look at their "expansion hats", the USB3 and the SATA "hat" provide a barrel plug and for the sata hat additionally a ATX12V 4 Pin connector indicating that even they do not recommend using USB-C for such set-ups.. 

it's not the distributor - it's the company behind NanoPi boards..
 
IMO the whole thread can be moved to: https://forum.armbian.com/forum/31-sd-card-and-psu-issues/
 
NanoPi M4 being not PD-compliant and therefore might be troublesome is mentioned on the dowloadpage:
 
linking to
btw @Igor or @lanefu we might add the same disclaimer from nanopi m4 to the orangepi 4 cause this board will have the same issues (I updated the thread but forgot my credentials to the WP admin board to do it on my own - feel free to remove my rights there anyways I didn't do much maintenance of it and honestly don't plan to change that in the future).
 
(hidden cause not really an advice more a hack to maybe achieve what you want but not what you should - having a sane powering for your setup)
 
3 amps at 5V is sufficient for the NanoPi M4 in most scenarios I had. But if you look at their "expansion hats", the USB3 and the SATA "hat" provide a barrel plug and for the sata hat additionally a ATX12V 4 Pin connector indicating that even they do not recommend using USB-C for such set-ups.. 

it's not the distributor - it's the company behind NanoPi boards..
 
IMO the whole thread can be moved to: https://forum.armbian.com/forum/31-sd-card-and-psu-issues/
 
NanoPi M4 being not PD-compliant and therefore might be troublesome is mentioned on the dowloadpage:
 
linking to
btw @Igor or @lanefu we might add the same disclaimer from nanopi m4 to the orangepi 4 cause this board will have the same issues (I updated the thread but forgot my credentials to the WP admin board to do it on my own - feel free to remove my rights there anyways I didn't do much maintenance of it and honestly don't plan to change that in the future).
 
(hidden cause not really an advice more a hack to maybe achieve what you want but not what you should - having a sane powering for your setup)
 
3 amps at 5V is sufficient for the NanoPi M4 in most scenarios I had. But if you look at their "expansion hats", the USB3 and the SATA "hat" provide a barrel plug and for the sata hat additionally a ATX12V 4 Pin connector indicating that even they do not recommend using USB-C for such set-ups.. 

I think there is some misunderstanding here. Last time we checked, radxa u-boot in SPI with Armbian in NVMe can boot, with MBR. Maybe some boot order change in u-boot caused this? We will look into it.