Updated my installscript so it can build an image for BPI-R3 too.
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.
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
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
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?
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
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.
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
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 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…
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.
I see it got build yesterday.
Either way, it’s working again \o/