[BPI-R2] Slackware ARMv7 15.0 Development + New to Uboot and ARM

Banana Pi Router design
1

Greetings! So I just got done compiling the u-boot-2024-04-bpi from

$ make mt7623n_bpir2_defconfig && make menuconfig

*** Compiler: gcc (GCC) 11.2.0 ***

Selecting a few minor custom options like …

[*] serverip variable takes precedent over DHCP server IP and default ‘ipaddr’ and default ‘serverip’

$ make all

The compile succeeded …

HOSTCC scripts/kconfig/conf.o … to … MKIMAGE u-boot-mtk.bin …

I compiled the source on a Raspberry Pi 3B using Slackware ARMv7 15.0.

My goal is to get Slackware ARMv7 15.0 fully installed and running on a BPI-R2.

I have full remote access to a Slackware ARMv7 15.0 system running on a Raspberry Pi 3B, so I can compile source code in a native Slackware ARMv7 15.0 environment.

Slackware ARMv7 15.0 comes stock with the 5.15.21 kernel, so I am planning on using …

As my next step, for the starting point of compiling the kernel, as it is a close match to the Slackware ARMv7 15.0’s stock kernel.

I am new to ARM systems, but I am well versed in using Slackware x86 systems, any related advice would be helpful and appreciated?

Likewise, I am also new to using u-boot, as I am a custom to lilo (Linux Loader), so again any related advice would be helpful and appreciated?

2

Where do you compile? If you compile on a non arm system you have to use crosscompiler…why don’t you use my build.sh?

I do not know slackware much,but imho it should be possible to download rootfs only somehow to put on the BPI-ROOT partition created by createimg step in my build.sh (see my github ci configuration .github/workflows/build.yaml) and then same compiling for kernel (using build.sh) and unpack/install this to your prepared sdcard with slack rootfs

3

Greetings, and thank you for your reply!

I do not cross compile. I compile on a native ARM OS, Slackware ARMv7 15.0 installed on a Raspberry Pi 3b.

When I attempted to run some executable files from Slackware ARMv7 on other bpi-r2 builds, such as your builds, and some of the open-wrt builds, they fail to execute. I have not investigated this completely.

However, I thought of starting with seeing how your code, compiled on an already up and running Slackware ARMv7 system, using standard build practices.

So far, both your uboot and kernel have built successfully on Slackware ARMv7, when using standard practices.

Since, I am new to uboot I am not entirely sure how it all works yet. So, I am defaulting to how I have done things on x86 systems, until or unless it fails. When reading the README.mediatek file I notice the uboot loads after a bootrom image header, and mtk-preloader.

From README.mediatek “-Bootrom → MTK preloader → U-Boot” according the README.mediatek “The on-chip BootROM will firstly verify integrity and compatibility of the bootloader.”

Question: Can any BPI-R2 bootrom and mtk-preloader be used with any uboot or kernel, or does it require a bootrom and mtk-preloader specific to a particular uboot or kernel? Or what are the requirements between the bootrom, preloader, uboot and kernel, ect …?

4

Way is right…Bootrom is imho fixed (eeprom) and preloader is closed source for r2 so you have to use the file i used in my uboot-repo to build base image. But it does not matter as you can start imho any uboot (does not depend on external libs,only format must match - u-boot.bin afair) from it (imho you do not need to change it). Also uboot ahould be have all in already so you can start with my base image.

Imho one possible cause of your problems can be crosscompilation tools not compatible with slack (if this uses different binaries linked too).

Kernel is independ to uboot. But kernel might depend on rootfs binaries.

5

Ok, thank you for the response.

I’m guessing the Slackware packages being compiled using gcc - 11.2.0 may have played a role in the executable files failure to run. It’s one of the many reasons, I am attempting to compile and run the whole Slackware operating system on the bpi-r2.

Question: Does the system need an initrd or initramfs, to ensure proper booting? Or does the dtb make an initrd and initramfs obsolete? And if so, how and where is the best way for doing this? uEnv.txt?

6

System needs a rootfs…this can be an initrd (unpacked to ram) or lay on any storage accessible from kernel (filesystem support builtin needed). You only initrd if you have no rootfs on storage or try to make tests which possibly crash kernel (to have no dirty filesystem after crash).

Dtb is devicetree blob (binary) so only the compiled dts which describes the hardware. This dts is built into the itb,so you do not need external dtb in this case.

uEnv.txt in my concept allows overriding the builtin environment from uboot (loaded from uEnv_rX.txt). Here you can set root var to your filesystem see how it is set currently before changing it.

7

Success! I prepared and used the eMMC as the Slackware boot & install disk. I attached 2 SATA drives to the machine, as I plan on using the system as a learning tool to get a better understanding of ARM Operating Systems, and want a lot of hard drive space to compile source code, and mess around.

Thank you for your aid and support, frank-w! I hope to get a lot of use from these computers. I’m rather tired at the moment, but when I wake up hopefully, I will manage to upload the Slackware-15.0-emmc-installer.img in the near future.

Likewise, I will need to investigate this further, but the kernel failed to fully boot until I replaced the original uboot with the uboot I compiled on the Rasberry Pi 3b. Again, just as a guess, it may have something to do with version of compiler used, IDK? Regardless, after I dd the newly compiled uboot into the emmc it booted nicely.

Slackware-ARMv7-15.0-bpi-r2-boot.log (53.3 KB)