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 
root@bpi-r64:~# reboot
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:
https://wiki.fw-web.de/doku.php?id=en/bpi-r2/storage#short_install-guide
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
New chain uboot and fip, but uImage and dtb separately (no fit).
Good to know that this is possible…i thought new atf needs fit image
It looks like you install directly to sdcard. Imho it would be better to create img which can be dd’d to sdcard
What may be good alignment settings for page and block sizes, may be bad settings for another SD card.
This will result in more read/write operations and thus is bad for performance and wear.
The script also installs sources and builds from there. After that you can build also running on R64
If you really need image you can dd from SD card… Could add this as option…
Problem i see is if booting from sdcard and creating system on sd you kill existing system (if not booted from emmc or into ramdisk)
For now only kernel and boot can be build on R64.
For kernel one could use a different local version number. New kernel only installed if build is successful. Only uEnv.txt needs to be altered to switch to old kernel.
If boot is messed up, for now SD card needs to be removed and boot reinstalled from laptop or so.
Creating new rootfs (on emmc) when running on R64 is still to be implemented, but disabled for now. Everything about installing to emmc is still untested.