Hello,
have anybody got a chance to build and run Kernel > 5.0 or even better > 5.8 which should support RTD1395 natively (https://patchwork.kernel.org/project/linux-arm-kernel/cover/[email protected]/)?
Thanks! Martin
You could try using defconfig from bpi repo in newer codebase
Clone mainline linux from kernel.org,copy defconfig to arch/arm64/configs and compile like r64
export ARCH=arm64;export CROSS_COMPILE='ccache aarch64-linux-gnu-'
make rtd139x_bpi_defconfig
Maybe without ccache. This is how kernel is built with build.sh
on importing the defconfig i see these warnings:
arch/arm64/configs/rtd139x_bpi_defconfig:805:warning: symbol value 'm' invalid for NF_TABLES_NETDEV
arch/arm64/configs/rtd139x_bpi_defconfig:986:warning: symbol value 'm' invalid for NF_TABLES_ARP
these need to be set to y instead of m, because these options are type bool. then continue with
make menuconfig #if you want to change anything
CFLAGS=-j$(grep ^processor /proc/cpuinfo | wc -l)
make $CFLAGS UIMAGE_LOADADDR=0x40008000 Image dtbs modules
make INSTALL_MOD_PATH=output modules_install
i can build with these steps, but cannot test, because i have no such board
For further steps take a look in build.sh on bpi repo,Makefile and in configure file. It looks like the kernels Image is copied as uImage
edit: you need to copy also dts-files (rtd-1395-bananapi-m4-*.dts and rtd-139x.dtsi,rtd-139x-pinctrl.dtsi,rtd-139x-irda.dtsi,rtd-1395-usb.dtsi, rtd-139x-dcsys-debug.dtsi) and link it in makefile
i guess not all drivers are available in mainline linux as dts(i) is missing
edit: ah, i see path of dts has changed a bit: arch/arm64/boot/dts/realtek/rtd1395-bpi-m4.dts, to build this CONFIG_ARCH_REALTEK needs to be set, which is not, add this to defconfig near top to make sure drivers depending on this are set. i see rtc and wdt drivers not compiled before…but i guess for usb and others the configs do not match…so you need to look which drivers need to be enabled for compatible in dts
i prepared the defconfig a bit in my repo, but build.sh does not support it so you need to compile as stated above/in the defconfig-commit
1 Like
Hello Frank,
thanks for the detailed guide. Ive been playing with the original bsp provided by the Sinovoip for some time already, so I decided to create my own fork:
https://github.com/yourwificz/BPI-M4-bsp/tree/5.10.y
I can build everything with no obvious error, but seems like the u-boot is unable to run the new uInitrd and then load the kernel image. I also tried to make a real uImage (not just zImage renamed by the build.sh script) and ommit uInitrd, but the booting stuck at “Loading kernel image…”.
Here is a bootlog of a board running the original image 4.9.119 bpi-m4_boot-ok.txt (8.8 KB)
And here is a bootlog of a board running the 5.10 image bpi-m4_boot-nok.txt (7.2 KB)
Just to make the bootlogs shorter I disabled a loading of an audio firmware.
Thanks for any advice!
How did you try to create uImage?
This is how i do for r64:
It depends on uboot supports armhf (arm as uimagearch) uImage or arm64…i guess you need arm. And change address to your loadaddress twice
Imho you don’t need a initrd for first test.but it seems your uboot is configured for using it
Using booti seems booting linux without uboot header
booti - boot arm64 Linux Image image from memory
bootm - boot application image from memory
Maybe @sinovoip can tell us,why your boot fails. Normally a init-ramdisk is not needed…only linux-kernel and devicetree (fdt,*.dtb). If linux is booted directly imho the loadaddress is not used as this is set in uimage (ubootheader),but this needs to be loaded by bootm,not booti. But for now we do not want to change uboot…only linux
Have you copied and changed (in uenv.txt) dtb too? Maybe old dtb is not compatible to new linux binary…then you also see only booting linux message. Also is serial config in dts is wrong (had to change dts for r2).
I tried the command below with loadaddress and/or enrty point 40080000 or 03000000 or just 00000000. I also tried various combinations of these addresses. With some I got “Error: Bad gzipped data” with some others booting stuck at “Loading Kernel Image …”.
mkimage -A arm64 -O linux -T kernel -C none -a 40080000 -e 40080000 -n “Linux Kernel” -d arch/arm64/boot/Image ./uImage
With this one (using new dtb and disabled initrd) I got “Loading Kernel Image …” as well. Here is the bootlog bpi-m4_boot-loading.txt (3.8 KB)
Tried it. No change, unfortunately. See above.
Not sure how I can configure that. According to the U-Boot GitHub Looks the version 2015.07 used in the bsp, does not support booti or at least not as a separate option (used to be a part of bootm code).
Yep, I am using the new dtb since beginning of all my testing. Interestingly, looking into the source, the new dtb is pretty different than the old one. A filesize of the new compiled dtb is pretty different as well, in compare to the old one (36kB old one vs. 4kB new one). Not sure if it means something.
Thanks in advance for any other hints 
I see error FDT_ERR_NOTFOUND. Don’t know why but it looks like the old one is loaded (4kb).
Edit new one is 4kb and old was 36…so this should be right…
The same error can be seen also in the “normal” boot with the original 4.9.119 image and initrd
…
flushing dcache successfully.
[Info] convert some env variable to fdt:factory node
libfdt fdt_path_offset() returned FDT_ERR_NOTFOUND
Info: Try to add new node /factory…
libfdt fdt_add_subnode(): FDT_ERR_NOSPACE
Wrong Image Format for do_booti command
ERROR: can’t get kernel image!
Loading init Ramdisk from Legacy Image at 31400000 …
…
Maybe you should check serial-config (address in dtb). Maybe your debuguart is not the one defined in cmdline
So it seems uart0 is used and this should be definition:
So at least address (reg) does not match…but it looks more like an offset with base of another adress.
rbus: bus@98000000
{
iso: syscon@7000 {
uart0: serial@800 {}
}
}
vs.
uart0: serial0@98007800
So it should match.serial0 is also set to uart0
But i miss the pinctl,maybe it works without,but maybe not
How is it realed to the image loading?
only if uart is set/used right it can display anything after unpacking kernel-image. it can work, if pins are in right state, but in old kernel they are set
make sure CONFIG_SERIAL_8250_DW is set in kernel config, as compatible is handled by this driver:
$ grep -Rni 'snps,dw-apb-uart' drivers
drivers/tty/serial/8250/8250_early.c:182:OF_EARLYCON_DECLARE(uart, "snps,dw-apb-uart", early_serial8250_setup);
drivers/tty/serial/8250/8250_dw.c:699: { .compatible = "snps,dw-apb-uart" }Thanks for the explanation
The CONFIG_SERIAL_8250_DW was not set. So I’ve rebuilt the image with the new config and also the original rtd-139x-pinctrl.dtsi included into the rtd139x.dtsi.
Unfortunately the boot process still ends with “Loading Kernel Image … ”
imho you need to check if the main-devices have drivers for corresponding compatibles
$ grep -ni 'compatible' arch/arm64/boot/dts/realtek/{rtd139x.dtsi,rtd1395.dtsi,rtd1395-bpi-m4.dts}
arch/arm64/boot/dts/realtek/rtd139x.dtsi:39: compatible = "arm,cortex-a53-pmu";
arch/arm64/boot/dts/realtek/rtd139x.dtsi:44: compatible = "fixed-clock";
arch/arm64/boot/dts/realtek/rtd139x.dtsi:51: compatible = "simple-bus";
arch/arm64/boot/dts/realtek/rtd139x.dtsi:58: compatible = "simple-bus";
arch/arm64/boot/dts/realtek/rtd139x.dtsi:65: compatible = "syscon", "simple-mfd";
arch/arm64/boot/dts/realtek/rtd139x.dtsi:74: compatible = "syscon", "simple-mfd";
arch/arm64/boot/dts/realtek/rtd139x.dtsi:83: compatible = "syscon", "simple-mfd";
arch/arm64/boot/dts/realtek/rtd139x.dtsi:92: compatible = "syscon", "simple-mfd";
arch/arm64/boot/dts/realtek/rtd139x.dtsi:101: compatible = "syscon", "simple-mfd";
arch/arm64/boot/dts/realtek/rtd139x.dtsi:111: compatible = "arm,gic-400";
arch/arm64/boot/dts/realtek/rtd139x.dtsi:125: compatible = "snps,dw-low-reset";
arch/arm64/boot/dts/realtek/rtd139x.dtsi:131: compatible = "snps,dw-low-reset";
arch/arm64/boot/dts/realtek/rtd139x.dtsi:137: compatible = "snps,dw-low-reset";
arch/arm64/boot/dts/realtek/rtd139x.dtsi:143: compatible = "snps,dw-low-reset";
arch/arm64/boot/dts/realtek/rtd139x.dtsi:151: compatible = "snps,dw-low-reset";
arch/arm64/boot/dts/realtek/rtd139x.dtsi:157: compatible = "realtek,rtd1295-watchdog";
arch/arm64/boot/dts/realtek/rtd139x.dtsi:163: compatible = "snps,dw-apb-uart";
arch/arm64/boot/dts/realtek/rtd139x.dtsi:175: compatible = "snps,dw-apb-uart";
arch/arm64/boot/dts/realtek/rtd139x.dtsi:185: compatible = "snps,dw-apb-uart";
arch/arm64/boot/dts/realtek/rtd1395.dtsi:11: compatible = "realtek,rtd1395";
arch/arm64/boot/dts/realtek/rtd1395.dtsi:19: compatible = "arm,cortex-a53";
arch/arm64/boot/dts/realtek/rtd1395.dtsi:26: compatible = "arm,cortex-a53";
arch/arm64/boot/dts/realtek/rtd1395.dtsi:33: compatible = "arm,cortex-a53";
arch/arm64/boot/dts/realtek/rtd1395.dtsi:40: compatible = "arm,cortex-a53";
arch/arm64/boot/dts/realtek/rtd1395.dtsi:46: compatible = "cache";
arch/arm64/boot/dts/realtek/rtd1395.dtsi:51: compatible = "arm,armv8-timer";
arch/arm64/boot/dts/realtek/rtd1395-bpi-m4.dts:11: compatible = "bananapi,bpi-m4", "realtek,rtd1395";
unfortunately i did not found drivers for arm,cortex-a53 and realtek,rtd1395
i guess rtd1395 uses some realtek specific init-code but did not found it. i found only
$ grep -Rni 'arm,cortex-a53' arch/arm64 | grep -v 'boot/dts'
arch/arm64/kernel/perf_event.c:1219: {.compatible = "arm,cortex-a53-pmu", .data = armv8_a53_pmu_init},
which is enabled via CONFIG_PERF_EVENTS
maybe you can try generic arm64 defconfig (arch/arm64/configs/defconfig), at least the console-driver is selected in it.
ARCH=arm64 make defconfig
and try to boot the image build with this and your dtb…if this works you can remove the options not needed. but basicly not much hardware (e.g. usb,eth,hdmi,gpio) is linked in the dts and so it will not work
Looks pretty much the same unfortunately: bpi-m4_boot-armdef.txt (7.5 KB)
You mean the one built with the image using defconfig, right?
i guess there is some bringup-code missing…try to find the compatibles from the dtsi file and look for their implementation in the bpi-repo
for r2/r64/r2pro i had this already in mainline-linux and got a booting kernel this way, but here i guess there is more missing
can u share ur kernel i will try in my board
Did you manage to build the image? I could try testing it out.
Thanks