[BPI-R64] Image builder Ubuntu and Debian Update 18-09-2021:
I have pushed the third release candidate of my image builder for R64 on github.
It builds an image from scratch for running Arch Linux, Ubuntu or Debian on the R64. Thanks to Frank-W for his work, which helped a lot!
There are also pre-build images ready for download, see assets in the release. You can use these images as try-out. If you like it, then you can use the script later.
Note: With the emmc version, wan only works with bootswitch set to boot from emmc first! (see closed issues)
Download v1.0-rc3 Arch Router Emmc version (136MB)
Download v1.0-rc3 Arch Router SDmmc version (136MB)
Major update 18-09-2021
- Boot without U-Boot (by default, it is an option)
- Root is now F2FS File System, this is specially designed for devices that use Flash Translation Layer, such as mmc devices.
- Enabled sd high speed mode on emmc/sdmmc in ATF.
- Kernel 5.15-rc1, now with IVL bit fix and DSA cpu assisted learning.
Major update 31-08-2021
- Able to install Arch-Linux, it is also now the default. Guess the repo needs a name change.
- Using systemd’s dhcp server.
- Using systemd-resolved
- Many other small changes
Banana Pi BPI-R64 open source smart router:
Hi,does it compile ubuntu-packages or does it do a debootstrap after generating the base image?
Btw. My name is written with “k” (also risk) (readme.md)
You use port5 of switch with gmac2? This does work with mainline without additional patches (except dts for port5)?
In my repo i test dsa multi cpu patches…but gmac2 seems not running stable enough (see retransmitts on iperf3)
But good to see that alex and i’m not the only developer here thanks for sharing
It only uses debootstrap, adding packages in an early stage. All packages pre-compiled from ports.ubuntu.com/ubuntu-ports
C -> K next commit
Patch mainline for port 5 only in the dts, no further patches… Only changes in network setup.
Have not performed any iperf3 yet.
Also feel free to use formatdefconfig.sh
First need to fix the CPU speed… It is way too slow. Work in progress…
time $(i=0; while (( i < 999999 )); do (( i ++ )); done)
Takes 16 seconds on my WRT1900ACS, and 4 minutes and 2 seconds now on the BRI-R64. Something is not set right
It seems you use mainline uboot,mtk atf and ubuntus kernel,not mine,right?
Will try cpu test on my board if i find some time
Mtk-openwrt atf, mt7622-bpir64 branch, quite similar to yours I believe.
Mainline uboot 2021-01
Ubuntu’s mainline, with a defconfig from your 5.12-main branch, which ended up with quite a few changes after performing a savedefconfig on it again… Anyway, had to start somewhere…
On original 2020-12-20-ubuntu-18.04.3-bpi-r64-5.4-sd-emmc it also takes 3 minutes and 55 seconds!
This not only in my image. I will open another topic, as this is not directly related to buildR64ubuntu.
On r2 with 5.10 it takes 38s…so it seems r64 specific
For atf there is a newer version (branch soc),but i think there were no cpu related fixes…problem should be more in linux
I’ve tried that branch of atf earlier, but it hangs at reboot. Switching on debug messages helpes a lot, then it hangs ever 10th reboot or so… For now I dropped using that version untils reboots are stable.
If the other branch works better you can compare these 2 branches for differences
Added thermal patch now.
Bpi R64 starts up real quick now.
Rebooting in about 15 seconds
Connection to 192.168.1.33 closed by remote host.
Connection to 192.168.1.33 closed.
nathalieeneric@BLUE:~$ ping 192.168.1.33
PING 192.168.1.33 (192.168.1.33) 56(84) bytes of data.
64 bytes from 192.168.1.33: icmp_seq=1 ttl=64 time=6.64 ms
64 bytes from 192.168.1.33: icmp_seq=13 ttl=64 time=23.1 ms
And the BPI R64 is running again, ready to login again on ssh
Maybe we can use imagebuilder (build.sh) to build debian and for r2 too and using my kernel,uboot,atf (define branch/board to use)?
The main goal was to use as much as possible mainline repositories, but to have it configurable for other choices All patches are in the corresponding folders in the buildiR64image repo. This way everything that is deviating from mainline/default is to be found in 1 repo in readable source code or patches.
I can easily adapt the script so that the origiin of the kernel source is configurable. It already is, but never checked with Debian kernel or torvalds kernel, only ubuntu kernel different versions
I believe the difference for ubuntu or Debian is also not so big concerning debootstrap so this is also possible.
About the R2 I think this would be such a change to quite a lot of aspects of the script, I believe it would be better to write a R2 version of the script separately. It will help keep the script more simple and clear.
In my repo there are some patches for better hw support like bluetooth,pcie for r64 and wifi for r2.
So it would be good to have ability to use my repo and maybe use build.sh for building.
I do not want to add all patches as patchfiles.
How do you compile/install kernel to your image,maybe i can change build.sh a bit
debootstrap is similar
Will generalize the git clone part so the script can take any git/branch
Will add possibility to debootstrap Debian instead.
Kernel is build in the same way as you already build yours.
Thanks,i dont’t know if bpi-r2 boot chain works with gpt,imho uboot needs to be at fixed offset loaded by preloader. at least my r2 uboot is not prepared for gpt.
Btw. Here you have a warning resulting in calling build.sh self again and will cause endless loop due recursion: https://github.com/ericwoud/buildR64ubuntu/blob/master/build.sh#L412
Luckily there is an exit statement above it. It was just some reminder comment. Will be removed.
About R2 that’s also why I think it needs a separate script.
You’re right, focused on the last line and missed the exit above
As first start a separate script will be fine
some parts i have here:
how did you transform the headerfiles (head*.bin) to string-data?
Script now can build debian. Only tested building, have not run the image yet…
Script can also build from any kernel .git. It defaults now to torvalds kernel. Also have not run this yet, but it should be fine.
Only some issue left with locale on debian, should not be a big issue.
Just used hexdump on the images and some find/replace. The first part of the images are all zeros, so these are not included. Script runs dd /dev/zero first on the whole first block.
It seems you use old bootchain (uimage+dtb instead of fit),right?
But i see you build uboot fip