OK. Added such module.
Turns out iwconfig cannot connect to WPA networks… installed wpa_supplicant
Still have errors though:
OK after playing around a bit, finally could connect to wifi network! (WiFi blue LEDs still toggle in a funny way though)
Only thing left i think is the booting problems… any thoughts on this?
Maybe this is a stupid idea but, is it possible to put a really simple program that is executed if boot fails, which just sends “panic” to u-boot console so board reboots?
Also, can you point me to a tool to shrink images created from your base image? I used to use pishrink on a raspberry pi images but we tested on this and did not work.
What have you changed to get it working? What is strange with leds?
Which booting problems?
Linux kernel has a function to reboot at kernel crash,imho openwrt sets it by default,but don’t remember the config key
But this depends on linux loaded…only issue i know is the gpt sometimes cannot be read in uboot and imho fixed so far by the sgdisk-commands for backup+restore…here linux is not loaded as this happens in uboot
Why do you want to shrink it? Image is done in a 7G img file…do you mean you flash my image to a larger card and want to get the old filesize when dd from the card (depends on not changed partition size)? This can be done with truncate command which simply cuts off data from file after a specific size
Documented way to shrink image based on partitionlayout here,but this is only fdisk for old mbr,not gpt so maybe this has to be adjusted a bit
https://wiki.fw-web.de/doku.php?id=en:bpi-r2:ubuntu&s[]=truncate#create_the_image
But if you have not changed partitionlayout you can cut off after 7000MB
The image file is already packed with gzip. If you unpack/flash it with:
gunzip -c ~/some-image.img.gz | sudo dd of=/dev/mmcblkX
Then you never need to unpack and handle the large .img file yourself.
No matter what the .img file size will be, the .img.gz will be approx the same.
I guess he has flashed my image,replaced kernel,configured system and want to get a such small image again from his card
But yes,you can also dd from the card and directly pack it
dd if=/dev/sdx | gzip > file.img.gz
And restore like eric wrote…but maybe not compatible with other cards (different size) and writes more data than necessary
Exactly. I flashed yours, replaced kernel and mediatek firmware, configured and want to shrink it now because dd created img with SD card size (32GB).
Regarding tweaking wifi, i installed wpa_supplicant, wireless-tools, rfkill, netplan
All networking is configured in netplan, i believe (i have wpa supplicant file but only should work for 1 interface and i have both connected to different networks, as per netplan configuration).
Sent some more iw and ip commands which i cannot enumerate for sure but this is my shell history:
The issue im addressing is the GPT yes. Your fix with sgdisk commands did not work for me. Tried several times in several images. In this case, i assume such function you mentioned to reboot at kernel crash will not work as kernel does not even load, right?
Is there a way to put that functionality in uboot? or do any kind of failsafe boot that would load just that panic/reboot command?
You have done the fix on card,not in the img,right? Because this backups the main gpt and restores it to the back too (at the end of disk).
And yes you are in uboot which cannot read gpt and so not load kernel.
You can change my uboot to make a reboot when kernel cannot be loaded…but gpt error can’t be fixed by a reboot in my tests and also not by powercycle so it makes debugging harder
if run loadkernel; then bootm ${kaddr}${bootconf}; fi
This can have an else part where you can call “reset” or something other. If it fails at this position…have not debugged it further
When do you still get booting problems? Do you mean
*** ERROR: Can’t read GPT Entries *** find_valid_gpt: *** ERROR: Invalid GPT ***
Do you get it after some changes? Or do you get it randomly? Did you try another SD card?
We noticed high probability of this happening after reboots. With just power cycles it happens occasionally if we re-power it right after, if we wait a while it reduces significantly the probability of it happening.
We do need to make changes like installing software and pyhton packages. We also tried many SD cards from SandDisk (Industrial) and it happens to all of them.
Do you know why this happens to the GPT? We can’t tell if it’s a hardware thing or an software issue. To me its not software as it is sort of random and its mitigated with wait time between power cycle.
In my experience uboot is confused on reboot when main gpt (from image) does not match backup gpt (not overridden by image because at end of disk). In my tests rewriting the gpt had fixed it for me…but maybe there is an additional trigger
@frank-w truncate did the trick. Thanks once again!
Regarding GPT issue. We tried several SD cards and images… could not get rid of this.
It just goes to uboot console i write cmd “panic” so it reboots… eventually boots ok.
Do you think problems are minimized if we write firmware to emmc instead of booting via SD card?
I have done the gdisk trick on the sd yes… the way that you initially wrote it.
uboot trick may worth to be tested.
One question. Do i only need to chage uEnv.txt or does this require any further compilation?
Im a bit confused because when i mount flashed SD card, there is a uEnv.txt in boot partition but only contains
fit=6.1.12-main.itb
Normally my uboot loads uEnv.txt from card and extends/overrides builtin environment (which is uEnv_r3.txt in the repo)…but here the BPI-BOOT partition is not found so to archive this you have to compile/flash uboot. Note: for r3 (and r64) uboot is packed into atf…so you have first to compile uboot and then switch to mtk-atf branch and compile again to get the right binaries…there you can use install function of build.sh to flash
See github actions config on how to compile
Normally the GPT table is only written to, when there are changes made to the partition setup.
So if nothing is being changed to the partiton table and the gpt error still occurs, it must be a read error.
Can you find anything about mmc errors with dmesg? (but then already passed uboot, so perhapse not.)
Edit: Just a thought, did you try CONFIG_MMC_QUIRKS in uboot?
I could not find any emmc related log in dmesg.
@frank-w To see if i get this right.
1- So first i clone that repo switch to the branch you mentioned (2023-01-bpi) and edit uEnv_r3.txt, that line you highlighted to:
newboot=run checkrd; run setbootconf; run buildargs;if printenv fit;then setenv kernel ${fit};if run loadkernel; then bootm ${kaddr}${bootconf}; else reset; fi;fi;
2- Run your github action commands which will build uboot, change git branch and build atf (or pack uboot into atf??):
sed -i 's/#\(board=bpi-r3\)/\1/' build.conf #change board to r3
bash build.sh importconfig
bash build.sh build
bash build.sh rename
git stash #stash build.conf
git checkout mtk-atf
echo -e "board=bpi-r3\ndevice=sdmmc" > build.conf
bash build.sh build
bash build.sh rename
bash build.sh createimg non-interactive
rm build.conf
OR do i need to run the entire action. So everything under
- name: Build for BananaPi-R3
run: |
After this, i will get files to replace directly (copy paste) into the SD card that holds your Debian 11 img with custom kernel?
@ericwoud That is an option when compiling u-boot? I did not compile u-boot yet. will try now to implant that reset instruction
Mmc is both sd or emmc 
both are handled via the mmc-controller (only one can be used at one time…currently sd)
Basicly you have to (first uboot,then atf)
- change build.conf (like you did for kernel)
- run build.sh importconfig
- run build.sh (building uboot)
- switch branch to mtk-atf which will require stash or checkout build.conf
- change build.conf again to right device
- build atf with u-boot.bin for the right device (sd is default)
- run build.sh install to flash atf/uboot to your card
- rename is optional,i do this to not override files with later compilations (ci do all bootdevices for r3…thats why there are same steps 4 times…only changing config different)
Ah ok. So emmc boot will not do any change i guess.
So that is basically executing this (your) commands, after cloning your repo and checkout to 2023-01-bpi right?:
sed -i 's/#\(board=bpi-r3\)/\1/' build.conf #change board to r3
bash build.sh importconfig
bash build.sh build
bash build.sh rename
git stash #stash build.conf
git checkout mtk-atf
echo -e "board=bpi-r3\ndevice=sdmmc" > build.conf
bash build.sh build
bash build.sh rename
bash build.sh createimg non-interactive
rm build.conf
Then, to copy to SD card:
build.sh install
Since bootloader uses different partition, (partition 1, i guess), i can insert SD card with my already customized img and swap bootloader with this previous command, right?
Basicly yes,but you do not need rename and createimg lines…you only want build and install. The sed/echo changes build.conf the script way…you can do changes with an editor…
a see i set device for atf too…but this was because ci creates this for r64 too…default is r3 and sdmmc
This is what install do for r3
OK. Managed to compile uboot/atf and install it as per instructions. Strange thing is that i am not having GPT boot problem anymore. I rebooted quite sometimes (roughly 20), which should be enough to see the problem.
So at this point, i dont really know if GPT problem went away or if is the uboot hack restarting everything behind the scenes.
I will post here when i take any conclusion.