[BPI-R3] [BPi-R3-Mini] Imagebuilder R3 ArchlinuxArm, linux-rolling-stable

Updated my installscript so it can build an image for BPI-R3 too. :slight_smile:

Here I start a topic for R3 related issues with the script.

Edit:

Download link below, Linux version latest (Arch Linux has rolling updates)

It is nearly finished, almost all things work now with many new extra’s.

What works so far:

  • Boot from ATF version 2.8, directly in to linux kernel. Although it is also possible to change the linux image path to u-boot image path and boot into u-boot this way.

  • ATF can load from fat32 boot partition, tool includes option to change from fip ↔ boot partition.

  • Use overlays from source (.dts located on /boot/, applied into .dtb in fip/boot partition).

  • Added working LAN (non sfp ports)

  • Added wlan0 and wlan1 setup.

  • Added correct setup of initrd, keep ‘x’ pressed to run busybox ash.

  • Possibility to flash emmc, when booting up from SD card. No NAND/NOR needed.

  • Possibility to use U-Boot.

  • Kernel version is following linux rolling stable and is now at 6.3.3. Within 24 hours of new version on git, it should be ready for update through normal package update. No need to build kernel yourself, but it is possible if you want with a very simple command, just like any archlinux (AUR) package.

Issues:

  • Only real issue so far is EMMC not running at HS400, but on HS200. See separate topic for more info what’s going wrong… SOLVED now for new installs. See post here how to apply fix on existing system.

Some technical details:

  • BL31 image is loaded together with the BL2 image. It does not need to be on the fip/boot partition (but if it is it will be used from fip/boot).

  • FIP partition does not need to be at specific sectors. ATF just uses the partition label, same as the ATF of the R64.

ATF:

Prebuild atf images in the bpir-atf-git-xxxx-.pkg.gz www.woudstra.mywire.org/images/

2 Likes

Two new options, tested on R3 (R64 not yet tested, but should work):

  1. The latest atf can boot from boot partition instead of fip partition, see [BPI-R3] & {BPI-R64] ATF with FAT32 load capabilities

Make some backups of important stuff, then update the `bpir64-atf-git’ with

pacman -Sy bpir64-atf-git

Then change your setup with:

bpir-writefip --fip2boot

Your fip partition has now transformed to a boot partition. Files from /boot/ are moved in to it. You can revert with:

bpir-writefip --boot2fip
  1. I have now added a U-Boot package, called bpir-uboot-git. You can consider it as an example package how to setup U-Boot, if you need it. With my fork of ATF you do not need it, but you now can if you want. Edit the package as you like and easily build U-Boot any way you customize it. For R3 it is based on sd card for now

It uses distro-boot to keep the package simple, using a flexible startup environment.

Anyway, it is fully functional and is also pre-build, uses the latest ATF. install it with:

pacman -Sy bpir64-atf-git bpir-uboot-git

When booting from boot partition, you are now already set.

When still booting with fip partition, Change the contents of /boot/bootcfg/linux to read /boot/u-boot.bin, then run bpir-writefip

The uboot package can be viewed here:

https://aur.archlinux.org/cgit/aur.git/tree/?h=bpir-uboot-git

Remove u-boot and change back to atf -> kernel boot:

pacman -R bpir-uboot-git

The script now is much more fool proof. Continuing after download hickups.

Major settings are now chosen with an interactive menu. Some advanced tweaks can be done by changing definitions at top of script.

Hi! I just received my BPI-R3 and am giving this a try. I built the image and wrote it to an SD card. I connected my serial console (standard Sparkfun FTDI FT231X USB adapter) and connect to the console with picocom -s 115200 /dev/ttyUSB0. When the board boots, it writes a lot of garbage to the console over a few minutes, but then presents a fully working login prompt. I’m able to log in and use the board normally, but I’m not able to see any boot messages. Do you know what’s going on with that? It seems almost like whatever is running while the board is booting is using different settings, e.g. a different speed? I’ve not been able to get it to show me anything other than garbage.

You should at least be able to see ATF, this is the first couple of readable lines and is always the same setting. Just to make sure, you could boot without sd card and you should see some hex numbers. The settings for this part is in bootrom so will never change.

I have had partly working serial before, turned out a bad ground connection. Also first check if the adapter is set to 3.3v, usually a jumper. It determines the voltage to the pull-up resistors.

Sparkfun basic breakout board has two different boards for voltage selection

I do not see the ATF when I boot the board without the SD card. The hardware I’m using works fine otherwise, just not when this specific board boots, and only when it boots. I’m sure that it’s using 3.3v. Is it possible I have a bad board?

Without sd card no ATF, only a few hex numbers. If that is garbage, check your ground connection. Otherwise try another serial adapter.

Curiously, if I connect the same serial console hardware to my Mac, I see bootup messages. But not on my Linux machine. Not sure what’s going on there, but clearly a bug somewhere :slight_smile:

Am I required to use the sd card then, or can it run without ATF? I’m interested to use the eMMC storage because sd cards get damaged too quickly.

I can’t answer the question about the ATF (and see my previous comment, I do see everything when I connect the serial console to my Mac), but I’m sticking with an external SD card right now specifically because they’re replaceable. It’s a lot easier to replace an SD card than it is to replace the onboard eMMC. Additionally, all my config for the board is in an ansible playbook in a git repo, and I’m investing in max endurance SD cards to reduce the risk of cards getting damaged.

Also, when you make some mistake and booting fails because of it, you can move the sd back to the PC/laptop and run it in a chroot. It is made easily available by the script that will do all mounting and unmounting for you.

From chroot you can repair whatever is broken much easier.

The EMMC HS400 problem is now fixed for new installations.

To use HS400 on existing systems:

1 Like

Latest ready to download image:

Download v1.3 SD card version Router setup (301MB) Kernel version v6.3.10 (linux-rolling-stable), Linux version latest (Arch Linux has rolling updates)

Write the image file for sd-card to the appropriate device, MAKE SURE YOU HAVE THE CORRECT DEVICE!

xz -dcv ~/Downloads/bpir3-RTnoSFP.img.xz | sudo dd of=/dev/sdX

I tried upgrading to the 6.4.3 kernel but ran into an issue where some of my devices wouldn’t stay connected to wifi. Downgrading to 6.3.9 immediately resolved the issue. Nothing useful in the logs, just what looks like normal authentication/deuathentication messages. Any suggestions on what to look at over the weekend when I have time to troubleshoot?

You could look what are differences between these versions in drivers/net/wireless/mt76 and maybe mac80211/cfg80211 (but these will affect all wifi drivers). Easiest way is cloning linux stable and use git diff between these versions an passing folders/files

E.g.

git diff v6.3.9..v6.4.3 -- drivers/net/wireless/mt76

You can look for the commits with git log…

If you are able to compile/install kernel you can try apply patches between these versions step by step and look which one breaks

Yeah, fair enough, sounds like I’ll be doing some git bisecting :slight_smile: I was hoping this was a known issue that had a solution already.

I was not even aware that linux rolling-stable had moved to 6.4.x. My archlinux linux package gets checked for updates and build automatically :wink: I see it got build yesterday.

Guess sometimes stable is not very stable…

I’m troubleshooting the OEM 2.5G SFP at the moment, so I have not really tested 6.4 on the wifi interfaces.

You could build the netdev/net-next linux version, see if the problem is already resolved but not mainlined yet.

git clone https://aur.archlinux.org/linux-bpir64-git.git
cd linux-bpir64-git

nano PKGBUILD

_gitroot="https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next"
_gitbranch="main"

Then

makepkg

After building, you can cd to linux-bpir64-git/src/linux and checkout any branch or commit from there. Or use git diff as Frank described. Or manually change something in the source code. You can do this on rolling-stable or on net-next.

Then build the package again, without makepkg changing the sources:

makepkg --noprepare --force

PS: this all need to be done on an aarch64 soc. I use my rk3588 board with nvme ssd, but ofcourse you can use the BPI-R3 too. Preferably something with nvme as sd will eventually wear out after building a couple of hundred times…

Looks like the 6.4.4 update fixed things? Or maybe I just needed to reboot the device again :woman_shrugging: Either way, it’s working again \o/

Always need to reboot after kernel update, as the old kernel modules are deleted…

Yeah, I did reboot the first time, of course, I was more saying that perhaps there was a bug and the board didn’t come up properly the first time. Either way, glad it’s fixed. :slight_smile: