piter75

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.

Wanted to be sure of that. It was not that long ago that we were chasing issues with OrangePi 4 not booting from Armbian with SD that had Xunlong's BSP image on that card before (because of secondary GPT) ;-)
 
Now it looks more clear and a bit unfortunate... ;-)
U-Boot 2017.09-02676-g4490220395 (Jul 01 2019 - 07:49:56 +0000) The u-boot image is pretty ancient:
g4490220395 => https://github.com/radxa/u-boot/commit/44902203959cef9d92dff2f36896c7ec27fb3d88
in next commit Radxa added DOS partition support to it => https://github.com/radxa/u-boot/commit/59412e4610af669538a057995ed2d418703723a2
I have a later g674eaa57f0 in SPI and it boots Armbian fine  => https://github.com/radxa/u-boot/commit/674eaa57f03d48aa1803650a901f0244563eea60
Full history here: https://github.com/radxa/u-boot/commits/rk3399-pie-gms-express-baseline
 
Now the positive stuff...
@raidboy to boot Armbian images without creating GPT on them you can simply connect pin 23 with 25 (or any other GND/black) pin on GPIO header. This disables onboard SPI.
To erase the SPI you could use this guide: https://wiki.radxa.com/Rockpi4/dev/spi-install#Erase_images_on_SPI_device.
Writing zeroes with dd to /dev/mtdblock0 while being booted with Radxa's image should also do the trick ;-)

Wanted to be sure of that. It was not that long ago that we were chasing issues with OrangePi 4 not booting from Armbian with SD that had Xunlong's BSP image on that card before (because of secondary GPT) ;-)
 
Now it looks more clear and a bit unfortunate... ;-)
U-Boot 2017.09-02676-g4490220395 (Jul 01 2019 - 07:49:56 +0000) The u-boot image is pretty ancient:
g4490220395 => https://github.com/radxa/u-boot/commit/44902203959cef9d92dff2f36896c7ec27fb3d88
in next commit Radxa added DOS partition support to it => https://github.com/radxa/u-boot/commit/59412e4610af669538a057995ed2d418703723a2
I have a later g674eaa57f0 in SPI and it boots Armbian fine  => https://github.com/radxa/u-boot/commit/674eaa57f03d48aa1803650a901f0244563eea60
Full history here: https://github.com/radxa/u-boot/commits/rk3399-pie-gms-express-baseline
 
Now the positive stuff...
@raidboy to boot Armbian images without creating GPT on them you can simply connect pin 23 with 25 (or any other GND/black) pin on GPIO header. This disables onboard SPI.
To erase the SPI you could use this guide: https://wiki.radxa.com/Rockpi4/dev/spi-install#Erase_images_on_SPI_device.
Writing zeroes with dd to /dev/mtdblock0 while being booted with Radxa's image should also do the trick ;-)

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.

I would add the mentioned options to kernel config, built the kernel, copied resulting ".config" file over "linux-rockchip64-current.config" and then commit it.
It would be great to do the same with "dev" kernel (which is now 5.5.y in Armbian's master) in the same PR for feature parity  

IMO the easiest way is ./compile.sh KERNEL_CONFIGURE=yes make your changes when menuconfig pops up and you get your new config in output/config after compilation. It's even named the way it should be..

I didn't have time and enough interest in Bluetooth to pursue a solution but one thing I have noticed with 5.x kernels on all rk3399 boards I own is that Bluetooth's firmware is correctly patched after cold boot / power on but not after a reboot.

@_ppiotr3k Did you by any chance use the same SD card for Armbian that was used for Xunlong image before?
 
If so, try wiping either all of the SD card (it will take a long time) or the last 33 sectors of it before writing Armbian's image there.
This will clear the recovery GPT partition table from the end of SD card.
This partition table makes Rockchip's loader trying to use GPT layout for booting - which we don't use. 
root@xyz:~# fdisk -l /dev/mmcblk1 | head -1 Disk /dev/mmcblk1: 29.7 GiB, 31914983424 bytes, 62333952 sectors # 62333952 - 33 = 62333919 root@xyz:~# dd if=/dev/zero of=/dev/mmcblk1 seek=62333919 I think a better solution is to switch u-boot's preloader to SPL/TPL from DDR/miniloader but I want to test how it behaves with Xunlong's original image in eMMC.
The precompiled buster minimal image (kernel 5.4.16), which does not require above steps, is here: https://drive.google.com/open?id=1ScMJN0VLIkuPjgnqhudK0egH42_cP1w3

Eventually I would like to end up with a tag from linux stable repo (even if it is -rcX) and a series of patches but it is more flexible to start with a custom repo now.

Eventually I would like to end up with a tag from linux stable repo (even if it is -rcX) and a series of patches but it is more flexible to start with a custom repo now.

@piter75 I have been playing around with mainline and the RockPiS (https://github.com/ashthespy/linux-rockchip/commits/rk3308-rockpis)
Have a booting board with the wired networking and console. Rest of it is quite sketchy.
Edit: opened up a PR so more people can play with it - https://github.com/armbian/build/pull/1773
Suggestions are welcome, as my experience with kernel stuff is quite low and I am learning as I go..

I never tested it with 256M as I only have 512M units.
 
It should be fixed in this branch: https://github.com/armbian/build/tree/rockpis-fix-256m-boot.
If you can build the image yourself then try it - otherwise it should make it into Armbian 20.02 release.

Well, the overlays actually work in this kernel 😜
 
It's just that they need to be Armbian style and not Radxa's so overlays for waveshare LCDs need to be named "rockchip-*.dtb, placed in /boot/dtb/rockchip/overlays folder and referenced in /boot/armbianEnv.txt's overlays stanza.
 
Dynamic overlays are not supported.

I did only test HDMI output in current (5.4.14) and it worked there. I must get myself a desktop monitor to test GUI more often ;p
 
I am glad it boots for you to the point where you can log in. At least now it is not only me who can boot it.

@Jack953 try beta images for OrangePi 4 instead . They are available in the download area: https://dl.armbian.com/orangepi4/archive/. 
 
I used buster for my preliminary support testing.
Keep in mind that the board support is in beta or even alpha state right now.

@Jack953 try beta images for OrangePi 4 instead . They are available in the download area: https://dl.armbian.com/orangepi4/archive/. 
 
I used buster for my preliminary support testing.
Keep in mind that the board support is in beta or even alpha state right now.

I did not test it with LCD but... looking at the last post in the discussion you linked one cannot expect it to display cli on LCD without programming it themselves as it is using SPI and not the DSI interface.

well you've no chance I already set up the pinebook in rk3399 with u-boot 2020:
 
U-Boot 2020.01-armbian (Jan 21 2020 - 23:08:47 +0100) Model: Pine64 Pinebook Pro DRAM: 3.9 GiB PMIC: RK808 MMC: dwmmc@fe320000: 1, sdhci@fe330000: 0 In: serial@ff1a0000 Out: serial@ff1a0000 Err: serial@ff1a0000 Model: Pine64 Pinebook Pro ## Error: Can't overwrite "serial#" ## Error inserting "serial#" variable, errno=1 rockchip_dnl_key_pressed: adc_channel_single_shot fail! Net: No ethernet found. Hit any key to stop autoboot: 0 switch to partitions #0, OK mmc1 is current device Scanning mmc 1: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 mmc 1 143 bytes read in 6 ms (22.5 KiB/s) 7118384 bytes read in 752 ms (9 MiB/s) 20722176 bytes read in 2178 ms (9.1 MiB/s) 72693 bytes read in 17 ms (4.1 MiB/s) 2698 bytes read in 9 ms (292 KiB/s) Applying kernel provided DT fixup script (rockchip-fixup.scr) ## Executing script at 39000000 ## Loading init Ramdisk from Legacy Image at 06000000 ... Image Name: uInitrd Image Type: AArch64 Linux RAMDisk Image (gzip compressed) Data Size: 7118320 Bytes = 6.8 MiB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK ## Flattened Device Tree blob at 01f00000 Booting using the fdt blob at 0x1f00000 Loading Ramdisk to f5853000, end f5f1cdf0 ... OK Loading Device Tree to 00000000f57d8000, end 00000000f5852fff ... OK Starting kernel ... [ 2.647157] Internal error: Oops: 96000004 [#1] PREEMPT SMP  
it seems it doesn't like my new DT.. but u-boot works fine and blobfree..

This is good but let's see if it keeps being stable.
I still think that we are covering up for some other issue with this cpu frequency governor behaviour change 

I didn't observe any crashes because of high load but what I encountered when compiling code were messages on the console indicating (indirectly) that there is something odd with the CPU (sorry, I don't remember the text). I tried to fix that using more powerful power supply, but that did not help. Not even the 12V supply via the SATA-hat. What did help was setting the governor for the CPU frequency to "conservative". Since I did that, I never got any strange messages anymore. So my conclusion was, that the board might have problems handling spikes or large changes in power consumption.
But of course, that's not a prove against crashes...

@Matthias the original issue with tx_delay/rx_delay (as tested with iperf) was fixed in all kernels back then.
The issue with tx programmable buffer length that exhibited itself with Samba is fixed only in 5.x for now.

@Matthias the original issue with tx_delay/rx_delay (as tested with iperf) was fixed in all kernels back then.
The issue with tx programmable buffer length that exhibited itself with Samba is fixed only in 5.x for now.

Could you possibly test it with 4.x on M4v2?

Did you build the kernel yourself?
I have committed a fix (https://github.com/armbian/build/commit/8c93385a84e2c8847ad5cf03684bee9c58596bf7) to the build system a few days ago. It should fix issues with the most common MTU of 1500.
It will be build into some future kernel / image build.

I have taken another route with this PR.
I shortened the TX programmable buffer length on all rk3399 boards as all are plagued with the same issue.
With this change the transfers should be stable with most used MTU of 1500 but hardware offloading could still be enabled.
Higher MTUs would require further shortening of the PBL.
 
I must admit that I suspect some timing issues with RAM on M4V2 as I also, sometimes - not often, experience kernel panics with my dev unit.
The other one that is a server with NVMe hat is running solid stable but it has a different u-boot configuration. I will definitely look into this issue.