Driver for Ethernet/PCI as found with Xunlong/Ky on the
OrangePi RV2/R2S source tree. Added as kernel patch since
the current spacemit family has conflicting changes with
rtl8852bs when enabling EXTRAWIFI=yes
Note: on the Xunlong/Ky tree, there is also a realtek_pgtool/
subdir that compiles a pgdrv.ko. B/c this does not have a
license indication, is only needed e.g. for MAC address
programming of efuse / eeprom, and generally does not look
required this is ommited here. For details, you may refer
to https://github.com/redchenjs/rtnicpg
Signed-off-by: Sven-Ola Tuecke <sven-ola@gmx.de>
Disable U-Boot CONFIG_MMC_UHS_SUPPORT otherwise a fast SD card does not
report "1.8 Volt mode switch possible" on kernel init which in turn does
not enable SDR104 for my SDXC card.
Fast mode ok is visible in the kernel log after booting from SD card:
root@orangepirv2:~# dmesg |grep mmc
[ 2.198816] mmc0: SDHCI controller on d4280000.sdh [d4280000.sdh] using ADMA
[ 2.224576] mmc1: SDHCI controller on d4280800.sdh [d4280800.sdh] using ADMA
[ 2.272657] mmc0: set tx_delaycode: 159
[ 2.273950] mmc0: pass window [6 68)
[ 2.276301] mmc0: pass window [72 198)
[ 2.277591] mmc0: pass window [219 255)
[ 2.277599] mmc0: tuning done, use the firstly delay_code:134
[ 2.277611] mmc0: new ultra high speed SDR104 SDXC card at address b36b
With UHS already enabled in u-boot, no tuning and no SDR104 mode is switched on
in the Linux kernel. Seems to be a side effect of an un-complete mmc_deinit() in
u-boot/driver/mmc/mmc.c. With MMC_UHS_SUPPORT disabled, the SD card does report
SD_ROCR_S18A with then leads to enter spacemit_sdhci_execute_sw_tuning() and the
subsequent switch to SDK104 or probably other 1.8 Volt modes is fine. This is at
least true for my OrangePi RV2 board.
Signed-off-by: Sven-Ola Tuecke <sven-ola@gmx.de>
This is for use with fdtoverlays directive in extlinux.conf
to enabled different configs for the Opi rv2 pin headers
Signed-off-by: Sven-Ola Tuecke <sven-ola@gmx.de>
Note: HW AES is really slow with LUKS2 when using default 512 byte block
size, regardless what cryptsetup benchmark prints out (this uses 65536
bytes). Performance is much better with luksFormat --sector-size 4096.
Signed-off-by: Sven-Ola Tuecke <sven-ola@gmx.de>
- This reverts commit e94425f6944b5a751e19f4bf7ac7dfce9f8b1035.
- I am clearly not up to par with type-c/fusb302 stuff yet
- sending this for future reference
- u-boot v2026.04-rcX has bumped dt-rebasing to v6.18, thus it knows about
NPU nodes now and we can simply symlink to kernel DT, reducing duplication by a lot
- fileenv patch (same as v2026.01)
- fdt_fixup_ethernet logging patch (same as v2026.01)
- 0000.patching_config.yaml: defconfig/dt_upstream_rockchip/dt_uboot
- notable in v2026.04:
- dt-rebasing bumped up to v6.18 (which has NPU nodes)
- this allows us to share complete DTs between kernel and u-boot via symlinks
- Kwiboo had a go at LWIP which should be usable now; Kwiboo rocks.
- drop invalid and useless enable-gpios on hdmi0 node
- was from vendor kernel
- does nothing in mainline
- is not required in mainline for working HDMI
and 8002936aac
because:
The ...fix-10mbit-ethernet patch is still necessary
Without it, the RK3308 does not connect via DHCP to 10-mbit Ethernets
The ...pinctl-slow-mux patch still compiles without error
It is <100 bytes and helps debugging GPIO issues.
I don't understand why above patches were flagged as "broken"
- rockchip64-6.19: mainline kernel (edge/6.19):
- most stuff works, incl 4G modem, NPU, RS-485, RS-232, HDMI-RX
- except:
- type-c (fusb302, I've no schematics nor will to reverse)
- DisplayPort (I don't have test hardware)
- Analog Audio (ditto)
- keep vendor u-boot for vendor branch
- mainline u-boot v2026.01:
- same DT as edge kernel, save for NPU nodes
- boot order: NVMe -> SATA -> USB -> eMMC -> Ethernet/PXE
- stable MAC addresses for GMAC0/1 via DT aliases (confirm with logging patch)
