aaditya

No ! Not true ! Trust me, or as Igor said, read the Rockchip datasheets !
All RK3399, as well as any other Rockchip SoC, are loading U-Boot from eMMC first.
The fact that some boards is looking at SDCard is simply that this U-Boot loaded from eMMC is checking for SDCard with specific format, partitions, or uEnv.ini, and then continue boot process from SDCard.

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.

Panfrost instructions Armbian
 
!!!! I made a script that does all this, check a few posts later for the script !!!!!  
This tutorial explains how to build an Armbian image with panfrost. And what else you need to make it work.
These are early drivers. Many things don't work yet. Only OpenGL 2.1 works now.
 
You need to build an image with kernel 5.2 or later.
For this you need an x86 pc with Ubuntu 18.04 or a virtual Ubuntu 18.04 x86 image.

First install git, then clone the build folder from Armbian, and enter the build directory.
 
apt-get -y -qq install git git clone --depth 1 https://github.com/armbian/build cd build Now run the script with EXPERT=yes so you can choose to build a dev image.
sudo ./compile EXPERT=yes Choose "Full OS image for flashing" Then "Show a kernel configuration menu before compilation" Choose your board. If it's not in the regular list, look in "Show SCS/WIP/EOS/TVB". Choose Development version kernel configuration -> device drivers -> graphic drivers -> panfrost  
Let it run until it's finished. The image will be in the /build/output/images
Burn it to an SD-card/eMMC/...
 
Now we need to install all the needed software
sudo apt install flex bison python3-mako libwayland-egl-backend-dev libxcb-dri3-dev libxcb-dri2-0-dev libxcb-glx0-dev libx11-xcb-dev libxcb-present-dev libxcb-sync-dev libxxf86vm-dev libxshmfence-dev libxrandr-dev libwayland-dev libxdamage-dev libxext-dev libxfixes-dev x11proto-dri2-dev x11proto-dri3-dev x11proto-present-dev x11proto-gl-dev x11proto-xf86vidmode-dev libexpat1-dev libudev-dev gettext glmark2 glmark2-es2 mesa-utils xutils-dev libpthread-stubs0-dev ninja-build bc python-pip flex bison cmake git valgrind llvm llvm-8-dev python3-pip pkg-config zlib1g-dev wayland-protocols Download and install meson
wget http://ftp.de.debian.org/debian/pool/main/m/meson/meson_0.55.3-1_all.deb sudo dpkg -i meson_0.55.3-1_all.deb Download and install mesa DRM
git clone git://anongit.freedesktop.org/mesa/drm cd drm meson build --prefix=/usr ninja -C build sudo -E ninja -C build install cd .. Download and install mesa graphics
git clone git://anongit.freedesktop.org/mesa/mesa cd mesa meson -Ddri-drivers= -Dvulkan-drivers= -Dgallium-drivers=panfrost,kmsro -Dlibunwind=false -Dprefix=/usr build/ ninja -C build/ sudo ninja -C build/ install REBOOT
 
Optionally, update sdl (recommended)
git clone https://github.com/SDL-mirror/SDL.git cd SDL mkdir build cd build cmake ../ make -j6 sudo make install REBOOT
 
Only thing that works ok with it is supertuxkart, to install it.
sudo apt install supertuxkart
 
Panfrost - Linux games working from repo
SuperTuxKart - Works well
ExtremeTuxRacer - lots of glitches
AssaultCube - lots of glitches
 
Instructions by Salvador Liébana & NicoD

@Panzerknacker What make/model EMMC you got? I have the 128GB which was delivered with the board. It's wierd the EMMC works in Linux but U-Boot SPL has issues. Wondering if there's patch somewhere... 
 
Edit: Many hours later...
 
Dug deep into the MMC code in UBoot and it seems there is a bug.. My EMMC will not negotiate success the advertised supported speed/mode (mmc: widths [8, 4, 1] modes [MMC legacy, MMC High Speed (26MHz), SD High Speed (50MHz), MMC High Speed (52MHz), MMC DDR52 (52MHz)] ). UBoot should revert back to the "safer" speed here: mmc.c#L2146, but it seems to be missing a call to mmc_set_clock(). I added the missing call and it successfully reverts back to "MMC High Speed (26MHz)" and EMMC can be read. Board finally boots on EMMC
trying mode MMC High Speed (26MHz) width 8 (at 26 MHz) CMD_SEND:6 ARG 0x03b70200 MMC_RSP_R1b 0x00800800 CMD_SEND:13 ARG 0x00010000 MMC_RSP_R1,5,6,7 0x00000900 CURR STATE:4 CMD_SEND:6 ARG 0x03b90100 MMC_RSP_R1b 0x00000800 CMD_SEND:13 ARG 0x00010000 MMC_RSP_R1,5,6,7 0x00000900 CURR STATE:4 CMD_SEND:8 ARG 0x00000000 MMC_RSP_R1,5,6,7 0x00000900 selecting mode MMC High Speed (26MHz) (freq : 26 MHz) clock is enabled (26000000Hz) CMD_SEND:8 ARG 0x00000000 MMC_RSP_R1,5,6,7 0x00000900 switch to partitions #0, OK mmc0(part 0) is current device Now booted kernel and the EMMC works perfectly in HS400 ES mode?!?!
Welcome to Armbian buster with Linux 5.4.6-rockchip64 System load: 0.00 0.00 0.00 Up time: 1 min Memory usage: 3 % of 3868MB IP: 192.168.0.33 CPU temp: 36°C Usage of /: 2% of 113G root@roc:~# cat /sys/kernel/debug/mmc1/ios clock: 200000000 Hz actual clock: 200000000 Hz vdd: 7 (1.65 - 1.95 V) bus mode: 2 (push-pull) chip select: 0 (don't care) power mode: 2 (on) bus width: 3 (8 bits) timing spec: 10 (mmc HS400 enhanced strobe) signal voltage: 1 (1.80 V) driver type: 0 (driver type B) Oh, and 5.4.7 is no good...
 

So it seems to be the same issue I had.
I will add the patch to the build as it does not seem to harm the eMMC modules that boot also without it.
 
The problem is definitely with 5.4.7+.
Others also started noticing and patching for it: https://gist.github.com/jakogut/bc21de0535b640f2374c1d07a710e8ab
I did not notice it as currently I am mostly spending time with NanoPi M4V2 which have mdio and phy nodes already setup in device tree.
Will dig a bit more into that issue.

This mini-tutorial is for those interested in running OpenGL applications and games on OpenGL ES.
Most (maybe all?) SoCs around support OpenGL ES, which is almost a stripped down version of OpenGL. OpenGL ES is mainly used by smartphone apps, but on Linux and generally on desktop computer OpenGL clients are the most common.
This tutorial is very simple and will teach you on how to download and compile GL4ES (github: https://github.com/ptitSeb/gl4es), a nice piece of software that converts most OpenGL calls into OpenGL ES counterparts to achieve some degree of compatibility and let your apps run on our SoCs. The target of this tutorial is the Rockchip RK3288 SoC with Mali-760 MP4 GPU, but hopefully it runs on other GPUs as well.
 
1) First of all you need git and cmake, so on your Armbian distro run:
$ sudo apt update $ sudo apt install git cmake 2) Now clone the GL4ES repository:
$ git clone 'https://github.com/ptitSeb/gl4es.git' 3) Run cmake to create the appropriate Makefile with our preferred configuration. We here use the ODROID profile and set OpenGL ES 2 as default (gl4es will look by default for OpenGLES_v2.so libary this way):
$ cd gl4es $ cmake . -DODROID=1 -DDEFAULT_ES=2 4) Compile the code:
$ make GL 5) If everything went well, copy the library into /opt:
$ sudo mkdir -p /opt/gl4es $ sudo cp lib/libGL.so.1 /opt/gl4es 6) Set the LIBGL_COPY environment variable in /etc/profile, so it will always be set at startup. This is needed because by default GL4ES applies a workaround for an issue in some drivers and the workaround is not needed on Mali drivers. Not setting this  variable will result in incredible slowdown on some scenes which use a particular OpenGL function:
$ su -c "echo export LIBGL_COPY=1 >> /etc/profile" 7) Reboot your system
 
This should be enough to run OpenGL 1.5/2 applications.
We run our preferred application setting the LD_LIBRARY_PATH environment variable pointing to /opt/gl4es, like this:
$ LD_LIBRARY_PATH=/opt/gl4es glxinfo You should get something like this:
 
The first lines (like "LIBGL: Initialising gl4es" and so on...) tells us that GL4ES library is being used and tells you what kind of extension is used too.
In particular, you should see gl4es in version string to be sure that gl4es will work.
 
If you want to see something moving, glxgears is the perfect candidate:
$ LD_LIBRARY_PATH=/opt/gl4es glxgears  
A trick I found to be very powerful in some cases is setting the LIBGL_BATCH environment variable. This trick tries to reduce the calls to the driver batching vertices together in a single call. For some games this works wonderfully and gives a huge boost (Quake II, for example), on others it is harmful for performances (Quake III) and on others creates graphical glitches. Use it when appropriate:
$ LD_LIBRARY_PATH=/opt/gl4es LIBGL_BATCH=1000 glxgears GL4ES has a lot of other environment variables that can be tested for various purposes. The complete list is available here
 
Last delicacy - Quake shareware
If all the steps have been done right, running Quake shareware should be a breeze:
$ sudo apt install quake quakespasm lhasa game-data-packager $ game-data-packager -i quake $ LD_LIBRARY_PATH=/opt/gl4es quake  

My Rock Pi 4B boots fine from eMMC in hs400es mode with 5.4.x but... I remember having similar issues to yours on one of Rock Pi 4A I had.
I found the difference between 5.x and 4.4 in regards to hs400es initialisation that made it work but finally returned the unit and did not pursue it any further.
 
Can you try building yourself an image with below patch applied or use the precompiled image I shared and see if it boots fine using eMMC?
fix-hs400es-init-on-some-boards.patch

Submitted upstream.

Is there a reason this is turned off?  From linux-rockchip64-current.config:
 
# # CD-ROM/DVD Filesystems # # CONFIG_ISO9660_FS is not set # CONFIG_UDF_FS is not set # end of CD-ROM/DVD Filesystems  
Whereas most other configs have this enabled as modules. For example,  in linux-sunxi64-current.config:
# # CD-ROM/DVD Filesystems # CONFIG_ISO9660_FS=m CONFIG_JOLIET=y # CONFIG_ZISOFS is not set CONFIG_UDF_FS=m # end of CD-ROM/DVD Filesystems  
 

Started to test Armbian_19.11.5_Rockpi-4b_buster_current_5.4.6.img and I could not boot off of the eMMC.  So I put Armbian_19.11.5_Rockpi-4b_buster_current_5.4.6.img on an SD card and formatted my eMMC.  I was then able to get the Rock Pi 4 to boot successfully.  It looks like the kernel can not initialize the eMMC.  Here are some messages from dmesg on boot:
 
[ 53.338988] dwmmc_rockchip fe310000.dwmmc: IDMAC supports 32-bit address mode. [ 53.339028] dwmmc_rockchip fe310000.dwmmc: Using internal DMA controller. [ 53.339048] dwmmc_rockchip fe310000.dwmmc: Version ID is 270a [ 53.339126] dwmmc_rockchip fe310000.dwmmc: DW MMC controller at irq 28,32 bit host data width,256 deep fifo [ 53.339411] dwmmc_rockchip fe310000.dwmmc: allocated mmc-pwrseq [ 53.339426] mmc_host mmc0: card is non-removable. [ 53.351589] mmc_host mmc0: Bus speed (slot 0) = 400000Hz (slot req 400000Hz, actual 400000HZ div = 0) [ 53.364798] dwmmc_rockchip fe320000.dwmmc: IDMAC supports 32-bit address mode. [ 53.364825] dwmmc_rockchip fe320000.dwmmc: Using internal DMA controller. [ 53.364840] dwmmc_rockchip fe320000.dwmmc: Version ID is 270a [ 53.364898] dwmmc_rockchip fe320000.dwmmc: DW MMC controller at irq 29,32 bit host data width,256 deep fifo [ 53.365040] dwmmc_rockchip fe320000.dwmmc: Got CD GPIO [ 53.377851] mmc_host mmc1: Bus speed (slot 0) = 400000Hz (slot req 400000Hz, actual 400000HZ div = 0) [ 53.393119] mmc2: CQHCI version 5.10 [ 53.399037] mmc0: queuing unknown CIS tuple 0x80 (2 bytes) [ 53.400631] mmc0: queuing unknown CIS tuple 0x80 (3 bytes) [ 53.402215] mmc0: queuing unknown CIS tuple 0x80 (3 bytes) [ 53.405068] mmc0: queuing unknown CIS tuple 0x80 (7 bytes) [ 53.408569] mmc0: queuing unknown CIS tuple 0x81 (9 bytes) [ 53.417703] mmc2: SDHCI controller on fe330000.sdhci [fe330000.sdhci] using ADMA [ 53.427277] mmc_host mmc1: Bus speed (slot 0) = 50000000Hz (slot req 50000000Hz, actual 50000000HZ div = 0) [ 53.427416] mmc1: new high speed SDHC card at address 0001 [ 53.432073] mmcblk1: mmc1:0001 00000 7.41 GiB [ 53.434118] mmcblk1: p1 [ 53.463648] mmc_host mmc0: Bus speed (slot 0) = 148500000Hz (slot req 150000000Hz, actual 148500000HZ div = 0) [ 53.515437] mmc2: mmc_select_hs400es failed, error -84 [ 53.515446] mmc2: error -84 whilst initialising MMC card [ 53.599556] dwmmc_rockchip fe310000.dwmmc: Successfully tuned phase to 224 [ 53.601739] mmc0: new ultra high speed SDR104 SDIO card at address 0001 [ 53.637621] mmc2: mmc_select_hs400es failed, error -84 [ 53.637632] mmc2: error -84 whilst initialising MMC card [ 53.777039] mmc2: mmc_select_hs400es failed, error -110 [ 53.777059] mmc2: error -110 whilst initialising MMC card [ 53.968760] mmc2: mmc_select_hs400es failed, error -110 [ 53.968777] mmc2: error -110 whilst initialising MMC card  I brought this up in the Raxda forum: https://forum.radxa.com/t/armbian-buster-5-4-6-emmc-slot-not-being-detected/2422/2 and it was suggested to switch to hs200.  I made the following modifications to the dtb like below on a freshly imaged eMMC:
 
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-rock-pi-4.dts b/arch/arm64/boot/dts/rockchip/rk3399-rock-pi-4.dts index 1ae1ebd4efdd..5ea6286e5faa 100644 --- a/arch/arm64/boot/dts/rockchip/rk3399-rock-pi-4.dts +++ b/arch/arm64/boot/dts/rockchip/rk3399-rock-pi-4.dts @@ -592,8 +592,7 @@ &sdhci { bus-width = <8>; - mmc-hs400-1_8v; - mmc-hs400-enhanced-strobe; + mmc-hs200-1_8v; non-removable; status = "okay"; }; This works, though hs400 seemed to be working on the Kernel 4.4 and I also see posts in this forum that suggests it was possibly working on 5.3.y?  I reviewed the kernel docs for ../5.4.y/Documentation/devicetree/bindings/mmc/mmc-controller.yaml, though to be honest I'm a little out of my depth on proper configuration and if there are currently config issues preventing the eMMC from being initialized properly.  My next step are to try and setup the build environment and figure out how to build 5.3.y branch to see if eMMC was working off of that branch?  If anyone could confirm booting off of eMMC on 5.3.y that would be helpful, as then I could start a git bisect in the kernel source to try and figure out what commit broke support.  Any further advice for someone more experienced with these SoC boards would be appreciated.

In the new year, I plan to focus on improving and developing Armbian-TV  (Armbian-TV is a version that is based on the official Armbian, aimed at improved support for media capabilities and ease of use by ordinary users) support for the platforms Rockchip and Allwinner  (perhaps a few more platforms will be added that are not yet in use). To do this, I have already ordered several popular models based on rk3399 (NanoPC T4, RockPi 4, Renegade-Elite), in a complete set with obligatory Support of nvme carriers (I consider this support essentially important, for transition of TV boxes and SBS to the category of mini-PC, as highly effective and improved replacement of the usual PC). I'm plan to buy several more models on Allwinner (I'm still evaluating the capabilities of the selected models). 
I had plans to buy some more models based on rk3399 from other manufacturers, but there were problems with delivery and / or payment for my country.
 
If anyone has any suggestions for models that I should consider, I'm willing to listen to reasonable descriptions of the models.

A workaround/fix for this is to edit the dts and set USB3_0 to 'host' instead of 'otg'.
 
Found here.
 

Maybe their U-Boot check for presence of SDCard and give it a new priority, but the Rockchip SoC itself looks in this specific order is SPIFlash, eMMC, and then SDCard ...
So, if their U-Boot is erased/replaced by Armbian one, the order will be the one I've mentioned.

Some further observations of mine in case it helps identifying the problems using ethernet: After noticing that the throughput using the native ethernet connection (eth0) of the M4V2 is low, I checked it using iperf3. I tested the legacy kernel, the current kernel and the dev kernel. The results are quite interesting:
 
Legacy kernel: Can receive data via TCP  from anoter host with high speed (~940MBit/s) but the other way around is quite slow (<1MBit/s).
Current/dev kernel: Can send data via TCP to another host with high speed (~950MBit/s) but the other way around is quite slow (~3MBit/s).
 
Further information:
If I set the link speed to 10MBit half duplex there seems to be almost no packet loss that slows down the connection. Using a USB3-ethernet adapter speed is good in both directions. I did not care about WiFi. It's not connected. There is a SATA hat attached to my NanoPi M4V2. Only power supply is used, no hdds are connected. Of course I only have one device at hand, so I cannot guarantee that the behavior is representative. Generally: If there is somebody working on further bringup of NanoPi M4V2 and needs somebody for testing, I'm happy to assist.

Within armbian you find following User-Supported options for GPIO and more:
ArmbianIO (sysFS) or
UserSpaceIO (libgpiod),
pyGPIO accesses 'pins' directly through /dev/mem

 ArmbianIO API
https://forum.armbian.com/topic/5655-armbianio-api-proposal/
 
 User Space IO is Python 3 and Java 8 bindings for user space GPIO, SPI, I2C, PWM and Serial interfaces
https://forum.armbian.com/topic/6523-user-space-io-is-python-3-and-java-8-bindings-for-user-space-gpio-spi-i2c-pwm-and-serial-interfaces/
 
 pyGPIO - A 'more general' python GPIO library based on pyA20
https://forum.armbian.com/topic/5662-pygpio-a-more-general-python-gpio-library/
 
 

It has gotten a lot easier to use Panfrost now.
Download one of @balbes150 5.x Bionic images for your device. 
The panfrost module is already added, all that needs to be done is installing the mesa drivers. For that I made a script. 
Download the file here in attachment and unpack it. 
Go into the folder Panfrost
 
cd Panfrost sudo ./installPanfrost.sh Install all for best results.

Panfrost has improved a lot on 5.4. Many games now work normally, some still have some smaller problems. It has become usable.
Greetings, NicoD

Edit : Script update. You now can upgrade the mesa and drm drivers after installation
Update 2 : Also Lima support now. 
 
 
 
 
 
installPanfrost.sh

You are not booting Armbian but your "empty" eMMC. Remove it for now.

Idea is good, but if you expect that I / we will do anything about this, forget. We have zero budget for any R&D. It is already extremely difficult and expensive only to maintain the core, important things / basic support.

As WiringPi was never meant to support other boards nor does the author like to support other boards and it is officially depreciated now (http://wiringpi.com/wiringpi-deprecated/). 
I want to ask why not put some efforts into libmraa https://github.com/intel-iot-devkit/mraa and put it into the Armbian repository.
 
I have already a fork which fixes Rock Pi 4 on recent mainline 5.3 kernels with updated debian build scripts here: https://github.com/bootsy52/mraa, so debian packages could be simple built using dpgk-buildpackage.
 
Why I think it is a good idea to supply libmraa with the Armbian repository
 
Supporting multiple boards is a desired goal of the project Supporting a board is really easy, for Rock Pi for example this is just the files src/arm/rockpi4.c include/arm/rockpi4.h and an entry in src/arm/arm.c, that's it Instead of multiple forks of wiringPi and different sources of different versions (or even different gpio implementations) just have one common implementation for all boards with wiringPi you need additional bridges if you want to code in other languages like Java or Python for example, with MRAA you have out of the box bindings for Python, Java, Javascript, C/C++ and NodeJS support  
What do you think? @Igor
 

The kudos belong to Levin Du of T-Firefly team who did the heavy lifting.
I merely paved the path with my u-boot PR and helped make the reboot work in mainline ATF for rk3399.
 
Oh and BTW... this is the first rk3399 board in Armbian which boots with full and fresh OSS combo: mainline u-boot's TPL/SPL + mainline ATF.

A huge kudos to @piter75 who commited a csc for this board 👍😍 Did not have the time or energy get my efforts to bear fruit. Was probably to focused on getting the U-Boot TPL+SPL combo working. Maybe this board finally gets the love it so desperately needs. Once again. Thank you for Armbian and all the work everyone puts in! 

Found this thread on here and I have sound from the audio jack on M4 v1 not tried V2 yet
 
 

In case anyone else wants to look at T4 audio I thought I'd leave a few of my notes here, as I need to move on to other things for a while.
The device tree audio widgets mention "MICBIAS1" but the rt5651 driver actually uses the lower case string "micbias1". This seems to be a bug in FriendlyElec's .dts (probably copied from some other realktek codec drivers which do use the uppercase spelling). Fixing this fixes an error message in the dmesg startup log. You can confirm this by looking for micbias in the rt5651 driver source code in the kernel tree. Armbian has a mechanism for shipping asound.state with the build. We should work out a canonical asound.state for the T4 and M4 boards and add it to Armbian build. However, I don't know if or how this interacts with pulseaudio. Maybe extra work is needed to get everything to play nice with pulse -- none the less, a working ALSA config would be a good start. I have yet to check this with an analog audio expert, but my reading of the T4 schematic is that the onboard Mic is connected to the codec in differential mode. However, by default the driver configures the codec in single-ended mode. The version of the driver in FriendlyElec's branch doesn't have the device tree binding to allow enabling differential mode for the Mic2 input (later versions of the driver for that codec do). TO TRY: add device tree binding to driver, add appropriate entry to device tree, see whether it improves onboard Mic audio quality. (should reduce noise/increase gain). NOTE: the DT binding docs for that codec which do have the binding for the differential mic input have an error in the docs. they misname the param and say something like diff-param=true; when it should just be differential-param; (not the real names). I'm still very new to Armbian and have no idea whether there are any common practices with regard to setting up audio on new boards. Guidance and feedback would be appreciated.

It appears to be decompression of initramfs taking 31 seconds:
 
[ 6.147142] RPC: Registered tcp NFSv4.1 backchannel transport module. [ 6.148094] PCI: CLS 0 bytes, default 64 [ 6.158734] Trying to unpack rootfs image as initramfs... [ 35.413752] Freeing initrd memory: 7632K [ 35.462578] hw perfevents: enabled with armv8_cortex_a53 PMU driver, 7 counters available [ 35.482492] hw perfevents: enabled with armv8_cortex_a72 PMU driver, 7 counters available I suspect this is due to the CPU starting at a very slow clock speed. The speed of these algorithms should be much faster:
 
[ 4.104906] raid6: neonx8 gen() 26 MB/s [ 4.172463] raid6: neonx8 xor() 21 MB/s [ 4.242370] raid6: neonx4 gen() 27 MB/s [ 4.309700] raid6: neonx4 xor() 21 MB/s [ 4.379941] raid6: neonx2 gen() 20 MB/s [ 4.446522] raid6: neonx2 xor() 19 MB/s [ 4.517607] raid6: neonx1 gen() 12 MB/s [ 4.583751] raid6: neonx1 xor() 14 MB/s [ 4.653424] raid6: int64x8 gen() 14 MB/s [ 4.721122] raid6: int64x8 xor() 9 MB/s [ 4.790970] raid6: int64x4 gen() 15 MB/s [ 4.860366] raid6: int64x4 xor() 10 MB/s [ 4.934680] raid6: int64x2 gen() 10 MB/s [ 5.003469] raid6: int64x2 xor() 8 MB/s [ 5.079205] raid6: int64x1 gen() 6 MB/s [ 5.151255] raid6: int64x1 xor() 6 MB/s [ 5.151948] raid6: using algorithm neonx4 gen() 27 MB/s I don't know how to check or control the initial speed of the CPU when the system is booting.

Multi-arch doesn't compensate for board differences...it's for things like 32 and 64-bitness being on the host system at the same time.

As for becoming inoperable on some other SoC...  A kernel built for SoC <X> may not have drivers, configuration, etc. built for SoC <Y>....to the point of being inoperable.  You shouldn't be trying to boot random kernels on random chips.  The only reason why X86 doesn't "work" that way is because there's a LOT of plug and play.  A tuned kernel for a given system setup there, though, CAN be inoperable on another board/system as well.  The fact that it's "tuned" is your first hint there.  A detuned setup like what Rasbian ships right now boots on every Pi because they chose to build for Original/PiZeros and limited everything to as much overlapped as possible.  In other words, they picked 32-bits ARMv6 architecture which is doable on all the chips with a moderate to major performance hit as you go up through the generations of boards.  They will all boot Raspbian, period.

The same can't be said of the Yocto derived distribution I am making after hours or for the one I'm making for Motorola Solutions, Inc. during the day.  WHEN I build for a Pi, and I do for varying reasons, I'm specific.  The build for a Pi2 won't boot for a PiZero, because it's tuned for a Pi2, which is to say it's a Quad Cortex-A7 system with a slightly different peripheral layout on the SoC than the Zero has.  The same can be said about a Pi3 or a Pi4 in either 32 or 64-bit mode, with the 64-bit modes increasing performance by up to 40% over the 32-bit ones.  Because I am pulling out more performance out of the build and SoC, the thing won't boot properly or at all on the other Pis.  The SAME can be said for any of the other SoC's you care to mention in the ARM or even X86 spaces.  The more optimized the kernel is for the specific hardware, the less likely it will boot elsewhere within the CPU architecture that the SoC belongs in.

I don't see the patches themselves doing that sort of thing.  But they won't work the same on a non-big/LITTLE core system either.  This is one of those things that lets the OS do the right things when you have hotter or weaker clusters in a given Coreplex.