I guess frank you discovered how to compile bl2 
to work with 8GB?
I forgot one thing… Compilation should be done only on Intel/amd structure as atf uses cross compiling and all compilation on arm units fails
Yes i did crosscompile on amd64 host,but it seemed my old atf code missed something (got only 4gb recognized).with new atf code i needed to remove build dir to no get build errors,but then 8gb are detected
Should be ok, I’ve build it many times on aarch64.
With @frank-w’s new release, and the following script:
split() {
local in="$1"
local model="${2:-bpi-r4}"
local base="$(basename "${in}" .img)"
dd "if=${in}" bs=1024 count=17 "of=${base}-gpt.img"
dd "if=${in}" bs=1024 skip=6656 count=$((1024*44-6656)) "of=${base}-uboot-recovery.img"
dd "if=${in}" bs=1048576 skip=45 count=$((51-45)) "of=${base}-uboot-snand.img"
dd "if=${in}" bs=1048576 skip=52 "of=${base}-rest.img"
cp -f "${model}_sdmmc_8GB_bl2.img" "${base}-sdmmc-bl2.img"
dd "if=/dev/zero" "of=${base}-sdmmc-bl2.img" seek=$(((6656-17)*1024-1)) bs=1 count=1
cp -f "${model}_spim-nand_ubi_8GB_bl2.img" "${base}-spim-nand-bl2.img"
dd "if=/dev/zero" "of=${base}-spim-nand-bl2.img" seek=$((1024*1024-1)) bs=1 count=1
cp -f "${model}_emmc_8GB_bl2.img" "${base}-emmc-bl2.img"
dd "if=/dev/zero" "of=${base}-emmc-bl2.img" seek=$((1024*1024-1)) bs=1 count=1
rm -f "${base}-new.img"
cat "${base}-"{gpt,sdmmc-bl2,uboot-recovery,spim-nand-bl2,uboot-snand,emmc-bl2,rest}".img" > "${base}-new.img"
rm "${base}-"{gpt,sdmmc-bl2,uboot-recovery,spim-nand-bl2,uboot-snand,emmc-bl2,rest}".img"
}
gunzip "path-to-openwrt-sdcard-image.img.gz"
split "path-to-openwrt-image.img"
# flash path-to-openwrt-image-new.img
I managed to get 8GB to show up. Should we figure out how/what to upstream to OpenWrt next? What was the missing piece of the puzzle compared to your earlier release/
To be honest i do not undestand why such big script is needed when using my binaries (looks like you disassemble full image instead of replacing the bl2 only)…it should be a simple dd replacing openwrt bl2 with mine. Hardcoded offsets and overwriting something in the bl2.img looks somehow strange. Maybe you can comment why it is needed from your PoV?
Imho it does not make sense to create 8gb images where only bl2 differs. As 4gb works on both boards it would be enough if openwrt releases 8gb bl2 for all boot devices and tutorial to replace the 4gb bl2 in image and system.
Exactly i prefer to stay with 4gb images to create/compile and change later bl2 if needed for sd or emmc
Eric i dont know what happen on my aarch64 - maybe os or some libraries differ but this year i was not successful to compile bl2 on my standard dev env orangepi5+. I did IT on my laptop. Copy 1:1.
You’re absolutely right. I disassembled the sdcard image and replaced all 3 bl2 sections of the image. The hardcoded offsets are in the OpenWrt image building makefile.
I do this because that is the most surefire way to make sure a person who’s new to the device will get a working device to spec. This prevents:
- following the OpenWrt instructions and getting a different RAM capacity than expected
- picking the wrong bl2 to flash (there are 9 on your uboot release page)
- wondering why booting from each boot source gives a different amount of detected ram (because it was not obvious to me each source had a different bl2)
- and as a corollary, the method for flashing nand using the bootloader involves copying the bl2 from an unloaded bl2 of the sdcard
None of these are necessary – and you could say that it’s all rookie mistakes – but reduces the amount of problems a new user who wants to get up and running quickly would encounter. The tradeoff would be needing a different sdcard image.
I think it’s worth it, especially since in my case I have had to get documentation from this forum, OpenWrt docs, and the OpenWrt forum to assemble a set of instructions that can work. This would also hopefully reduce the number of times experienced folk have to answer repeated questions (on all the different sources of information).
But ultimately at the end of the day it’s for you and the other maintainers who should make a call on what’s desirable – few people would have the deep and intimate knowledge of the hardware as you would.
1 Like
by the way - my offer of trying to get this upstreamed to OpenWrt still stands. I would want a smooth user experience for users of this hardware. I’ll start with the commits I can identify from your uboot repository which affects bl2 and 8G RAM; may need you to chime in later on (or with @\dangowrt) if the OpenWrt maintainers have questions
1 Like