aaditya

That branch was just something I played with for stateful decoding on RPi and Amlogic and not something that was finished nor do I expect it to be working.
 
https://github.com/Kwiboo/FFmpeg/commits/v4l2-request-hwaccel-4.2.2 is the branch we use in LibreELEC. I was able to hw decode h264 with that branch and vanilla linux 5.6.6 on my RK3288 Tinker Board S a few hours ago.
Also you should not need the --enable-libv4l2 configure flag, --enable-libdrm --enable-v4l2-request --enable-libudev should be enough to enable the request api hwaccels.
 
What device are you testing on? I have not done any testing with rkvdec driver and there is no rk3328/rk3399 hantro driver for h264 in upstream media tree. Mpeg-2 and VP8 should work across rk3288/rk3328/rk3399.
I do not expect h264 rkvdec to be working without changes to ffmpeg since there was some flags that got changed and now do not match between upstream rkvdec driver and my ffmpeg branch.
 
I am hoping to get some time this weekend to update ffmpeg to work with rkvdec and hopefully submit the initial hantro h264 decoder for rk3328/rk3399 vpu2 to upstream.

Same thing here.
 
As always, I think it will come down to :
 
Generating a H264 sample frame Looking at the documentation about how to send this to the driver Get the result  
But everytime I think about the 2 first steps, I'm like... "Ugh... do I really have to do this ?".
 
If that's still the case with the 5.7, I'll try to build a test framework.
 
Quite frankly, I looked at the FFMPEG patches and I still don't know how the FFMPEG select the right decoder in the first place.
As with all big projects, there might be a few "magic tricks" here and there to do the whole auto-selection of each component with the least amount of code.
And that's without counting the fact that "ffmpeg -hwaccels" list another kind of "hwaccels" so you won't know anything based on that output.
 
I also heard there were a "libva" library built around V4L2 request system. I guess this might worth a try, if it still exists and is still developed.

In this 'Let's start a collective benchmark' thread might appear a few other results (and 4 cards are already there that are missing here): 
 
But IMO we can already sum it up: 
On boards that only implement the slowest SDIO mode (4 bit @ 50 MHz) the SDIO interface between SoC and SD card becomes the bottleneck when we're talking about sequential transfer speeds. You won't exceed ~23MB/s anyway. Therefore choosing cards where sequential write/read exceed this treshold is somewhat useless unless you use them also somewhere else where the host is capable of higher speeds (this was one of my former use cases: burning OS images in minimum time with +80 MB/s on my laptop -- now mostly irrelevant since FEL/NFS booting is way more fast and convenient when it's about testing new Armbian images) Many 'normal' SanDisk, Toshiba and Transcend cards aren't that fast and show a strange random I/O write weakness with 16k record size (does not apply to the more/most expensive series from the same vendors!) The speed differences when we're talking about small record sizes (the typical card accesses when you put your rootfs or user homes on SD card) vary a lot, especially when it's about random I/O and especially random writes To my surprise the rather cheap Samsung EVOs in our scenario were as fast as the more expensive EVO+ (these show higher potential sequential performance you can't make use of if the SDIO implementation is already the bottleneck) and outperform the even more expensive Samsung Pros in most areas. The EVO's sequential write speeds are advertised as '10 MB/s' but in reality that's something +20 MB/s at least with the few samples we tested with The top performer was Hardkernel's eMMC module combined with their Micro SD adapter. Sequential transfer speeds limited as with the others but random I/O simply rocks. You get what you pay for  Things to mention:
Boards exist that do not share the slow SDIO limitation as our test boards using Allwinner's A20. On these random I/O might be nearly identical but the sequential speed limitation of ~22/23 MB/s isn't existent. With these boards you might see huge differences when using more expensive branded cards as long as we're talking about sequential transfer speeds (writing/reading huge amounts of data constantly) Regarding more recent SoCs you always have to differentiate between SoC and implementation/board. For example Allwinner's cheap 64-bit A64 is able to use the faster SDIO modes. But on cheap boards like Pine64 this isn't implemented (requires on-the-fly voltage switching between 3.3V and 1.8V for the faster modes). A64 is also able to access eMMC which could be magnitudes faster than SD cards. But since some of the needed eMMC pins are already used for other stuff on the Pine64 you're limited to the slowest SDIO access mode (which also means: all performance numbers above are valid for Pine64 -- I did some cross checks to confirm) Please keep in mind that the Kingston results above as well as all results for cheap 'normal' SanDisk, Toshiba or Transcend cards are hard to interpret. Kingston buys flash chips and controllers on spot markets and combines whatever is cheap at the moment. Therefore you get the irrelevant sequential speeds as advertised but random I/O might vary between different batches a lot (please remember: On SBCs random I/O is more important) Same applies to the cheap SanDisk, Toshiba and Transcend cards, especially if the tested cards are a few years old. Chances are great that you now get a card that is labeled identical but features both a new controller and new NAND chips that are many times faster when we're talking about random I/O Always remember that there are a few renowned storage brands that just buy bunches of unknown flash chips to combine them with unknown controllers. Both performance and reliability might vary a lot between different batches Then there exist manufacturers that own NAND factories, produce their own controllers, have engineers that do not just think about optimal combinations but realize them and ship final products. Think about the difference to the aforementioned group when buying cards And finally... reliability:
You read all of the above and thought 'Well, what can be wrong ordering 5 of these cheap and performant EVO?' Maybe, that you get something different. Fraud/counterfeit cards are still a massive problem, so always test any card you buy directly after purchase. Always! No excuses! It's really easy and worth the efforts (more info) What about longevity? SD cards were made for cameras/recorders (sequential transfers, access pattern: mostly idle). This is an absolutely different use case than using these cards with an SBC, especially when a lot of random I/O happens (Armbian already helps here with a rather high commit interval: with our defaults all disk related changes are collected and then written to the card just every 10 minutes) I talked recently to someone who deploys lots of devices built of SBCs relying on SD cards. His conclusion: Never ever buy anything again but SanDisk Extreme Plus (not Pro -- yes, those that are twice as expensive ). The costs to replace a broken card at a customer's location are many times higher than buying reliable hardware in the beginning What to do if this is not your situation but you still care about reliability/longevity? You can try to do burn-in tests (maybe lasting a few months/years of continual random writes/reads and results with no meaning since the manufacturer exchanged the controller and/or NAND dies in the meantime) or you take the trust the vendor has into his own products into account. Choosing cards with a warranty of 10 years or even more is not the worst choice in such a situation.

Warning: This whole thread is only about historical information now since it's 2018 and we can buy inexpensive and great performing A1 rated SD cards in the meantime. Buying anything else is a mistake so directly jump to the end of the thread for performance numbers and recommendations.
 
 
 
Edit: See an early 2017 update at the end of the thread regarding new SD specs also covering random IO performance.
 
Edit 2: Some thoughts/observations on lifespan/reliability of SBC storage: http://tech.scargill.net/a-question-of-lifespan/ (see also/especially the comments there)
 
Edit 3: CNX Software picked up recent performance reports (eg. by Andreas Spiess) and other important issues around SD cards: http://www.cnx-software.com/2017/06/13/micro-sd-cards-for-development-boards-classes-tools-benchmarks-reliability-and-tips-tricks/
 
Edit 4: See an early 2018 update testing real world A1 performance class products at the end of the thread.
 
Edit 5: See here and there for some rather boring but very important information about Armbian's tries to prevent SD cards wearing out too fast.
 
 

 
Preparations:
 
I tested 8 different SD/TF cards under identical conditions. I created an Armbian 5.07 image to be used on Banana Pi (A20 SoC with 4.4.6 kernel, ext4 rootfs (Armbian defaults == no journal), 960MHz scaling_max_cpufreq, scaling_governor == performance. All test runs were done using 'iozone -e -I -a -s 100M -r 4k -r 16k -r 512k -r 1024k -r 16384k -i 0 -i 1 -i 2' and monitored using 'sudo iostat 5' for anomalies (none detected).
  Kernel version matters (since with Allwinner's 3.4 kernel sequential throughput is limited to ~16MB/s, with mainline kernel we get close to Banana Pi SDIO implementation's max: ~23MB/s) and filesystem settings matter too (enabled journal for example slows down 4K writes a lot).   Sequential speeds:     Random I/O:     The 4 Samsung cards were bought within the last 3 weeks and manufactured between 09/2015 and 12/2015 according to the card's metadata. Interesting observation: I used three of these cards the first time and they all show identical behaviour especially regarding writes with small record sizes: pretty slow in the beginning and getting faster over time (the Samsung Pro for example started with only 1400KB/s 4K writes and 3 runs later the same test showed 3270KB/s -- maybe an indication that some sort of calibration happened. Anyway: I know why I always repeat tests and do not rely on a single test run)   Sequential speed mostly irrelevant / random I/O differs and matters a lot!   The SanDisk Extreme Pro has been bought nearly 3 years ago. This card shows superior sequential read/write performance compared to the three Samsung EVOs. But only when used in combination with a host that can make use of these speeds. My MacBook writes 4 times faster an OS image to the Extreme Pro compared to the EVOs. But this doesn't matter at all since the SDIO implementation of the board in question is limited to ~23MB/s (50MHz @ 4 bit). The same sequential write/read speed limitation applies to most SBCs since to be able to exceed this slow mode the voltage the SD/TF card is fed with would've to be adjusted (default 3.3V, the faster modes require a dynamic switch to 1.8V instead which some/most SoCs can perform but if the SBC vendor doesn't implement this you're limited to ~23MB/s).   Therefore cards labeled as being capable of "up to 90MB/s" do not perform different than those that can only do "up to 20MB/s" as long as we're talking about sequential transfers since the SD card interface is already the bottleneck. But since we're using SD/TF cards not in cameras but as storage media for the rootfs of an SBC something different is more important: Random I/O. And here performance of cards that are labeled identical ('class 10' for example) differs a lot.   All 4 Samsungs outperform the other cards easily in this area. The SanDisk Extreme Pro can not compete regarding random I/O compared to superiour (but mostly irrelevant) sequential transfer speeds. And funnily the 3 other cards show horribly slow random write performance, especially with 16k record size. According to card metadata the 2 Intenso are oemid 0x5048 / manfid: 0x000027 (cheap crap known to die way too early) and I would believe the SanDisk 'class 10' card is a fake or at least uses the same controller as the 2 Intenso since 16K random writes are also way slower than 4K writes.   Detailed results (summary table also available as .ods, .xlsx or .txt):   Samsung Pro 64GB (brand new) http://sprunge.us/DEYd   Samsung EVO+ 64GB (brand new) http://sprunge.us/NLQd   Samsung EVO+ 32GB (brand new) http://sprunge.us/heGL   Samsung EVO 64GB (already used some time) http://sprunge.us/DUOS   SanDisk Extreme Pro 8GB (already used some time) http://sprunge.us/ZPFZ   SanDisk 'Class 10' 8GB (already used some time) http://sprunge.us/OHjT   Intenso 'Class 10' 16GB (already used some time) http://sprunge.us/LUMZ   Intenso 'Class 4' 4GB (already used some time) http://sprunge.us/GbAY   Some updates from Igor (still showing superiour EVO results but the clear winner is ODROID's eMMC module with SD card adapter):   Transcend Premium 300x 16GB (almost new) http://sprunge.us/UcSD  
 
 
Sandisk Extreme Pro 8Gb (almost new) http://sprunge.us/aDJJ
 
 
 
Hardkernel eMMC 8G via SD reader (brand new) http://sprunge.us/SHXF
 
 
 
Sandisk Ultra 8Gb (old and very used) http://sprunge.us/OWZf
 
 
 
Sandisk 8GB (almost new) http://sprunge.us/iViT
 
 
 
Sandisk 8G (new) http://sprunge.us/XHjj
 
 
 
Transcend 8Gb (used) http://sprunge.us/NTRT
 
 
 
Samsung EVO 32Gb (brand new) http://sprunge.us/bTQh
 
 
    Further readings: http://www.bunniestudios.com/blog/?page_id=1022 http://thewirecutter.com/reviews/best-microsd-card/ http://www.jeffgeerling.com/blogs/jeff-geerling/raspberry-pi-microsd-card http://www.bradfordembedded.com/2014/05/flashbenching/ Conclusions:
If the board's SD card interface is the bottleneck since it's not supporting the faster SDIO modes using expensive cards that exceed the interface's maximum sequential bandwidth is useless. An expensive Samsung Pro Plus won't be faster than a way more cheap EVO when it's about sequential transfer speeds since you will stay at ~22MB/s anyway Sequential read and especially write speeds are all the SD association's speed ratings are about (to ensure reliable recording of videos/images in cameras/recorders) When an SD card is used in an SBC sequential speeds aren't that important. It's all about random I/O, especially with small block sizes (reading and writing small random chunks of data from/to the card) No commonly used 'random I/O' speed ratings exist so you have to check the card in question prior to usage or rely on appropriate benchmarks (see the two links directly above). Again: the 'speed class' won't tell you anything. You can get two different 'class 10' cards that differ by 500% or even more regarding real world storage performance (again: random I/O matters). In the example above the Intenso 'class 10' card is 385 slower compared to the EVOs when it's about 16K random writes (good luck if you have a database running that uses this page size) Interestingly more expensive cards are outperformed by cheaper ones (the EVOs show a better overall performance compared to the Samsung Pro since sequential speeds are limited by the interface) One extreme example: Using an identical cloned installation that was somewhat outdated on the small 4GB Intenso card and on the 64GB EVO resulted in the following times for an 'apt-get upgrade' (+200 packages): EVO less than 6 minutes vs. 390 minutes (yes, ~6.5 hours) with the Intenso. The time to finish depends largely on fast random writes. It's easy to test the card in question when running Armbian since we ship with iozone. Therefore simply execute the iozone call from the first paragraph after logging in as a normal user. Starting with Armbian 5.06 a even better method exists that also tests the whole card for errors: armbianmonitor -c will report precisely both performance and health state of your card

I added everything you used to DTS a long time ago, but the sound didn't work for me (due to the lack of settings for alsa), I thought my DTS settings weren't correct. I'm wondering how you found (defined) these parameters ? 

Strangely, when you build mesa-20, everything goes correctly, but after installing mesa, the old mesa-19 remains. Something changed in the rules, how do I install the new version ? Previously, the instruction worked correctly and mesa started using Panfrost. By the way, installation from repositories of the latest mesa-20 also does not use Panfrost.

Thanks for the instructions @NicoD!
 
I modified the mesa build options to enable egl:
meson -D egl=true -D gles1=true -D gles2=true -D shared-glapi=true -Ddri-drivers= -Dvulkan-drivers= -Dgallium-drivers=panfrost,kmsro -Dlibunwind=false -Dprefix=/usr build/  
With egl one can compile and run git version of supertuxkart.

Are you willing to take on this task and do this work?  I would say it is clear that the current maintainers here do not see this as a good investment of their time.  This is open source, and the best way to get something you need in open source is to step up and do the work and then contribute it back to the community.
 
A couple of additional thoughts on your request:
1) From what I have observed and know of the state of android on these TV boxes is that the dtb's from android are fairly worthless in helping getting things working under mainline kernels with armbian.  Everyone assumes this is not the case, but I haven't seen anything to indicate otherwise.  The gulf between ancient android based kernels and drivers (without source code in most cases) and modern mainline kernels is vast.
2) You are making an assumption that "pushing adoption" is a good thing.  The way things currently stand, there are not sufficient people on these forums with the desire and knowledge to provide end user support for the existing new users much less a larger quantity of new users in the future.  What is needed now is people willing to answer the basic questions that new users post here, and to work on high quality documentation and tutorials (and maintain them as things change), so that the core developers can be relieved of the burden of providing this information so that they can spend more time moving the project forward.

Okay,
Considering Balbes150 is a well known and has various Armbian builds on the forum, 
I figure I'd play it safe and follow one of the guides posted. 
 
Thanks Fellas!

Speaking personally, my efforts in supporting tvboxes in armbian basically starts from treating them like other SBCs. From my point of view they are just boards like any other.
This is not entirely true because SBCs have specifications, the components are always the same or at least compatible, and they usually received some quality assurance - with some clamorous exceptions. Tv boxes wildy change hardware for the same commercially named product, which makes supporting them a nightname. But forgetting for a moment the confusion around tv boxes hardware, what you ask is not so far away in my opinion, and does not require changes to armbian ecosystem.
On the contrary: it requires changes to the user expectation. The user expects that she burns the image on a sdcard, put the sdcard in the box and everything just works.
Currently for many images proposed in this forum section, it is so. It just works, but has its constraints: the system lives outside the armbian ecosystem, so don't expect to get the all the armbian ecosystem gifts and goodies, kernel updates on top of that.
 
Technically speaking, armbian puts together several parts which are expected to work with each other. The focus is on mainline u-boot and kernels, and proprietary blobs and kernels are kept as last resource.
 
To make tv box images work out of the box, you have to sacrifice the first step of openness: you need to exploit the proprietary bootloader already installed on your tvbox, specifically u-boot. Proprietary bootloades wants proprietary ways to load the kernel, device tree binary, root filesystems, and so on... So it happens that when you upgrade the kernel someone should take care of converting the kernel and other parts to make them compatible with the proprietary bootloader. But should armbian people take care about the proprietary u-boot installed on your tv box? I would say no, they absolutely have not to. And that is even more true if you think that mainline u-boot just flattens all those differences between proprietary software, so why keep using the proprietary bootloader?
 
My personal approach is draconian and requires a bit more work for the user: first step is erase your tvbox internal memory. After this, the tvbox ceases from being a tvbox and turns it into an SBC with internal flash memory. Without the constraint of the proprietary bootloader all the updates can be supplied - kernel updates included - without any change to the existing armbian code and ecosystem. You will notice that also the standard armbian-config tool will be able to install the system on the internal flash without requiring special scripts or procedures.
 
In my opinion this is the way to go if you don't just want toy installations on tv boxes.

Hi!
 
Unless mistaken, I believe audio is missing from 3.5mm jack on the RockPi4b. To enable it, I had:
- To update the dts by adding definitions close to the RockPro64 (some available starting in mainline 5.6)
- Change them to use I2S0 instead of I2S1
- Enable audio-graph-card in kernel config (I also removed some audio modules which issued warnings/errors during boot)
- Patch es8316.c to prevent a kernel panic during boot (found in Ayufan's latest mainline kernel for RockPro64)
 
yannick@rockpi-4b:~$ aplay -l **** List of PLAYBACK Hardware Devices **** card 0: rockchiprk3399 [rockchip,rk3399], device 0: ff880000.i2s-ES8316 HiFi ES8316 HiFi-0 [ff880000.i2s-ES8316 HiFi ES8316 HiFi-0] Subdevices: 1/1 Subdevice #0: subdevice #0 card 1: hdmisound [hdmi-sound], device 0: ff8a0000.i2s-i2s-hifi i2s-hifi-0 [ff8a0000.i2s-i2s-hifi i2s-hifi-0] Subdevices: 1/1 Subdevice #0: subdevice #0  
And finally, activate the proper DACs with amixer:
 
amixer set 'Right Headphone Mixer Right DAC' on amixer set 'Left Headphone Mixer Left DAC' on  
Would you like a PR for this?
 
Cheers, and thanks for your work on Armbian!

Perhaps main download pages would need some RFC that by default it shows supported + WIP. In case we leave them all it soon gets very cluttered. Once the board falls out of https://github.com/armbian/build/blob/master/config/targets.conf BSP packages are not build anymore while kernel (since its common) does. In rare cases this breaks the board functions ... and since we don't test we don't know.

A solution to this is to come out with a "last BSP package" which differ even rebuild it will always alter welcome prompt "This is EOL image" (now this is unchanged AFAIK) and freeze u-boot, kernel, BSP packages. Meaning no more update to the unknown. Perhaps this is the way to proceed or just leave as is ...
 

Sorting out all this is a serious project for a few people, perhaps not as serious as this https://mender.io/ but close.
 

If people around armbian has no time & interest, there is little to be done. I have no intention to push on anyone or try to build up a professional team on a hardware vendor behalf that contribute absolutely nothing. We already cover too much and we should perhaps kick out some hardware that is on the bottom of acceptance or has very little vendor support. Support costs is already insane high and adding more is more like a suicide. We have no choice but provide best effort support. If we can't allocate big enough resources its pointless to start with a new board or family. 
 

It would be nice to fix this. Its one of those - it works, don't touch  

Yes, I have had VPU working on 5.4 kernel since the new year started, my test images from 31 dec / 1 jan at http://kwiboo.libreelec.tv/test/ should "work", at least for MPEG-2, H264 and VP8 codecs on RK3288, RK3328 and RK3399.
The VPU patchset used in LibreELEC has not been touched/rebased for 5.5/5.6 yet, but I am hoping to get some time to work on that later this weekend and next week.

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..
 

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.



 

Tested Rockpi4a v1.4 SPI U-Boot 2017.09-2686-g18c70dba63 (Dec 31 2019 - 12:33:07 +0000), Build: jenkins-linux-build-testing-2-136
 
this works, only flash img to nvme, do nothing  armbianEnv.txt or boot.cmd, no sdcard
Intel 660p 
Armbian_20.02.1_Rockpi-4a_buster_legacy_4.4.213.img
.......................
Hit key to stop autoboot('CTRL+C'):  0
Device 0: RKPARM: Invalid parameter part table
Vendor: 0x8086 Rev: 002C     Prod: BTNH90820C73512A
            Type: Hard Disk
            Capacity: 488386.3 MB = 476.9 GB (1000215216 x 512)
... is now current device
Scanning nvme 0:1...
Found U-Boot script /boot/boot.scr
2940 bytes read in 5 ms (574.2 KiB/s)
## Executing script at 00500000
Boot script loaded from nvme 0
189 bytes read in 6 ms (30.3 KiB/s)
6758686 bytes read in 67 ms (96.2 MiB/s)
19752968 bytes read in 171 ms (110.2 MiB/s)
93124 bytes read in 23 ms (3.9 MiB/s)
** File not found /boot/dtb/rockchip/overlay/rockchip-fixup.scr **
.............................
Kingston 2000 and Gigabyte
this works, armbianEnv.txt add fdtfile=rockchip/rk3399-rock-pi-4.dtb
Armbian_20.02.7_Rockpi-4a_buster_current_5.4.28.img
.................
Hit key to stop autoboot('CTRL+C'):  0
Device 0: RKPARM: Invalid parameter part table
Vendor: 0x2646 Rev: S5Z42102 Prod: 50026B72823F1B89
            Type: Hard Disk
            Capacity: 238475.1 MB = 232.8 GB (488397168 x 512)
... is now current device
Scanning nvme 0:1...
Found U-Boot script /boot/boot.scr
2940 bytes read in 4 ms (717.8 KiB/s)
## Executing script at 00500000
Boot script loaded from nvme 0
189 bytes read in 4 ms (45.9 KiB/s)
7287636 bytes read in 69 ms (100.7 MiB/s)
20787712 bytes read in 184 ms (107.7 MiB/s)
72736 bytes read in 11 ms (6.3 MiB/s)
2698 bytes read in 6 ms (438.5 KiB/s)
Applying kernel provided DT fixup script (rockchip-fixup.scr)
................................................................................
 
These NVME not works, tested , many scripts, there is errors
 
kingston A1000
Armbian_20.02.7_Rockpi-4a_buster_current_5.4.28.img
.................
Hit key to stop autoboot('CTRL+C'):  0
Device 0: RKPARM: Invalid parameter part table
Vendor: 0x2646 Rev: E8FK11.R Prod: 50026B76826C0418
            Type: Hard Disk
            Capacity: 228936.5 MB = 223.5 GB (468862128 x 512)
... is now current device
Scanning nvme 0:1...
Found U-Boot script /boot/boot.scr
2985 bytes read in 7 ms (416 KiB/s)
## Executing script at 00500000
Boot script loaded from nvme 0
189 bytes read in 5 ms (36.1 KiB/s)
ERROR: status = 13, phase = 1, head = 1
 ** fs_devread read error - block
ERROR: status = 13, phase = 0, head = 1
 ** fs_devread read error - block
72736 bytes read in 22 ms (3.2 MiB/s)
2698 bytes read in 10 ms (262.7 KiB/s)
Applying kernel provided DT fixup script (rockchip-fixup.scr)
................
 
PNY CS3030 250GB
.........................
Armbian_20.02.7_Rockpi-4a_buster_current_5.4.28.img
....................
Hit key to stop autoboot('CTRL+C'):  0
Device 0: RKPARM: Invalid parameter part table
Vendor: 0x1987 Rev: CS303224 Prod: PNY35190025670102900
            Type: Hard Disk
            Capacity: 238475.1 MB = 232.8 GB (488397168 x 512)
... is now current device
Scanning nvme 0:1...
Found U-Boot script /boot/boot.scr
2940 bytes read in 6 ms (478.5 KiB/s)
## Executing script at 00500000
Boot script loaded from nvme 0
189 bytes read in 5 ms (36.1 KiB/s)
ERROR: status = 2013, phase = 1, head = 1
 ** fs_devread read error - block
ERROR: status = 2013, phase = 0, head = 1
 ** fs_devread read error - block
72736 bytes read in 13 ms (5.3 MiB/s)
2698 bytes read in 11 ms (239.3 KiB/s)
Applying kernel provided DT fixup script (rockchip-fixup.scr)
...............................
Samsung 970 EVOPlus
Armbian_20.02.7_Rockpi-4a_buster_current_5.4.28.img
....................
Hit key to stop autoboot('CTRL+C'):  0
Device 0: RKPARM: Invalid parameter part table
Vendor: 0x144d Rev: 1B2QEXM7 Prod: S4EUNG0M122756V
            Type: Hard Disk
            Capacity: 238475.1 MB = 232.8 GB (488397168 x 512)
... is now current device
Scanning nvme 0:1...
Found U-Boot script /boot/boot.scr
2940 bytes read in 5 ms (574.2 KiB/s)
## Executing script at 00500000
Boot script loaded from nvme 0
189 bytes read in 3 ms (61.5 KiB/s)
ERROR: status = 2013, phase = 1, head = 1
 ** fs_devread read error - block
ERROR: status = 2013, phase = 0, head = 1
 ** fs_devread read error - block
72736 bytes read in 15 ms (4.6 MiB/s)
2698 bytes read in 7 ms (376 KiB/s)
Applying kernel provided DT fixup script (rockchip-fixup.scr)
.................................
 
 

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?

That is a MUST if you wish to help figured out why your PBP doesn't boot.
 
BTW, no one here got an Armbian image working with the LCD display yet !
We still have to figure out why, but it will take time ...

There's an issue with Panfrost and Mesa 19.3 that causes X11 to crash in "OsLookupColor" which you may run into on Armbian on RK3399 devices; it can be solved by enabling the experimental branch in your /etc/apt/sources.list by adding the following line:
 
deb http://deb.debian.org/debian experimental main contrib non-free  
You can then run 'apt update' and install experimental branch packages with 'apt -t experimental install <package>'. To fix the crash in X11, update the following from experimental:
libegl-mesa0 libgbm1 libgl1-mesa-dri libglapi-mesa libglx-mesa0 mesa-va-drivers mesa-vdpau-drivers mesa-vulkan-drivers This should allow X11 to run properly.
 
Thanks to zackw at the Pine64 forums (Original post: https://forum.pine64.org/showthread.php?tid=8915&pid=61701#pid61701 )

Armbian is build from sources and build engine will reveal you a lot of how-to's: https://github.com/armbian/build/
 
For updating u-boot:
https://docs.armbian.com/User-Guide_Getting-Started/#how-to-update-u-boot

Thanks for the instructions @NicoD!
 
I modified the mesa build options to enable egl:
meson -D egl=true -D gles1=true -D gles2=true -D shared-glapi=true -Ddri-drivers= -Dvulkan-drivers= -Dgallium-drivers=panfrost,kmsro -Dlibunwind=false -Dprefix=/usr build/  
With egl one can compile and run git version of supertuxkart.

A few months later, and I have a little more time, so decided to volunteer to help tidy up the forums.
 
I never directly received a reply to this question, but someone must have heard me because I was just looking today at the Donate page, and now I see (in addition to monthly PayPal option from before):
Bitcoin address Amazon wish list (for purchasing hardware) Contact form (for setting up bank transfer, invoice option for companies, etc.) I for one was happy to see additional options and just thought I would share what I discovered.
 
You like Having Nice Things(tm)? Consider supporting Armbian today! 

We could do that but I am pretty sure, although of course may be wrong ;p, that it's not a CPU frequency issue.
 
What I observed so far is that most of the time when I cold boot the board I see following lines at the end of DDR training in Rockchip's binary:
change freq to 856MHz 1,0 ch 0 ddrconfig = 0x101, ddrsize = 0x2020 ch 1 ddrconfig = 0x101, ddrsize = 0x2020 pmugrf_os_reg[2] = 0x3AA1FAA1, stride = 0xD ddr_set_rate to 328MHZ ddr_set_rate to 666MHZ ddr_set_rate to 928MHZ channel 0, cs 0, advanced training done channel 0, cs 1, advanced training done channel 1, cs 0, advanced training done channel 1, cs 1, advanced training done channel 1, cs 0, dq 31 RISK!!! TdiVW_total violate spec channel 1, cs 1, dq 31 RISK!!! TdiVW_total violate spec ddr_set_rate to 416MHZ, ctl_index 0 ddr_set_rate to 856MHZ, ctl_index 1 Those "dq 31 RISK!!! TdiVW_total violate spec" lines do not look promising.
OTOH most of the times when I reboot the board after some time I do not see those lines which may mean that memory chips used in M4V2 require a bit different params.
As a piece of additional info, I also tried to use u-boot's TPL to train LPDDR4 in v2020.01 and although it works well for RockPi 4, RockPro64 and ROC-RK3399-PC it ends up with a kernel crash on 100% of boots with M4V2

I don't know the reason for the decision to do it, as it predates the beginning of my usage of Armbian, but I tend to agree that we should play safe by default.
 
I did not have any issues with it on my boards so I did not pursue to change it but...
When I was suspecting CPU issues with M4V2 I created the changes to disable the overclocking but also to make it easy to overclock with the overlay if one wanted to experiment:
https://github.com/armbian/build/compare/rk3399-disable-overclocking
 
It did not fix the M4V2 mainline issues but I think we can reconsider the default behaviour anyway.

The reason for this patch to exist is that it is difficult to remove / insert the eMMC module of RockPi 4 while installed with large heatsink and in general I think that SD should take precedence over eMMC in our tinkerers' world ;-)
Nonetheless I think your use case is valid and it would be great to have a solution that switches to SD only if it is actually bootable. It would then satisfy both cases.