Are you still trying to compile the mt76 on bpi’s repo? What do you want done and I can just build it for you with your needed options. If you want to send me your address I can send you a flash drive with a live environment and the image already there and buildable, if it will help development.
I could also build you a working environment with the mt76 bpi repo there and working. I can then use dd to create you a working live image. From there you can flash it to a flash drive and direct grub to boot it.
No,i applied their patches to a mt76 branch for easier following code and added the firmware loading to mainline code. At least the message timeouts are gone now,but i see only 2 phys and get a trace when i try to enable the interfaces
You use ubuntu18 for building? You could upload the original image built from source so i can verify the card works as expected and shows 3 phys
Maybe you can create docker-image which allows building?
Not sure what a docker image is, but explain exactly what you want and I’ll do it. Bringing my build server online now.
A docker image uses https://www.docker.com or https://podman.io to run containerized operating systems on top of your host OS. Similar to a VM, but without the overhead of virtualizing the whole machine.
It allows to keep a well-defined state in a container, without having to change things on your host OS. Useful for building kernel images when you need an older ubuntu version. Or when you want to build U-Boot/OpenWrt on Windows.
Then you also don’t necessarily need a build server, but can instead use the container image in GitHub workflows or locally on your machine.
Interesting. I use a build server because I have two servers at my home. One is for data backup/VPN/media streaming and the other is for building. It builds faster than my laptop. It has 48GB running at 8000mhz and a 14900K. My laptop would take an hour to build an image. That being said I’ll try to make a Docker image. I’ve made many VMs so this shouldn’t be hard.
https://drive.google.com/drive/folders/1Up2hMy7sSqP6K0tPLNvcjlIObxbtql9g?usp=drive_link
This is the MT76 BPI r4 I built a couple months ago
I wasted about an hour on podman. Running a vm or running off a flash drive is more dependable.
Can you build the actual code and post image here?
You could setup ubuntu18 in a chroot?
1 Like
Need to check…but if there is someone with a working build environment this is easier for me 
Installed ubuntu 24.04 today (spare OS to my configured ubuntu 22.04) on laptop 
I hope i can still download the packages via debootstrap…support of ubuntu 18 was till last year
2023-05-01 Reflect lunar release, add mantic, remove bionic.
Bionic is u18
But nethertheless,i try to do when i’m at home later…
chroot worked…this is how i did it (ubuntu 24.04):
apt update && apt install debootstrap
mkdir u18-amd64
#mount -o remount,exec /media/frank/data_ext
debootstrap --variant=buildd bionic u18-amd64
mount -o bind ../git/BPI-R4-MT76-OPENWRT-V21.02/ u18-amd64/mnt
chroot u18-amd64/
apt update
apt install gcc-aarch64-linux-gnu u-boot-tools bc make gcc ccache libc6-dev libncurses5-dev libssl-dev bison flex
apt install gawk unzip wget python3 python3-distutils rsync file
adduser pi
su pi
cd /mnt
make menuconfig
make -j8
pi@frank-u24:/mnt$ ls -lh bin/targets/mediatek/mt7988/
total 842M
-rw-r--r-- 1 pi pi 19K May 1 15:37 config.buildinfo
-rw-r--r-- 1 pi pi 355 May 1 15:37 feeds.buildinfo
-rw-r--r-- 1 pi pi 136M May 1 16:10 kernel-debug.tar.zst
-rw-r--r-- 1 pi pi 110M May 1 16:11 mtk-bpi-r4-EMMC.img
-rw-r--r-- 1 pi pi 82M May 1 16:11 mtk-bpi-r4-NAND.img
-rw-r--r-- 1 pi pi 110M May 1 16:11 mtk-bpi-r4-SD.img
-rw-r--r-- 1 pi pi 65M May 1 16:11 openwrt-mediatek-mt7988-BPI-R4-EMMC-initramfs-kernel.bin
-rw-r--r-- 1 pi pi 72M May 1 16:10 openwrt-mediatek-mt7988-BPI-R4-EMMC-squashfs-sysupgrade.bin
-rw-r--r-- 1 pi pi 65M May 1 16:11 openwrt-mediatek-mt7988-BPI-R4-NAND-initramfs-kernel.bin
-rw-r--r-- 1 pi pi 75M May 1 16:10 openwrt-mediatek-mt7988-BPI-R4-NAND-squashfs-factory.bin
-rw-r--r-- 1 pi pi 72M May 1 16:10 openwrt-mediatek-mt7988-BPI-R4-NAND-squashfs-sysupgrade.bin
-rw-r--r-- 1 pi pi 65M May 1 16:11 openwrt-mediatek-mt7988-BPI-R4-SD-initramfs-kernel.bin
-rw-r--r-- 1 pi pi 72M May 1 16:10 openwrt-mediatek-mt7988-BPI-R4-SD-squashfs-sysupgrade.bin
-rw-r--r-- 1 pi pi 15K May 1 16:11 openwrt-mediatek-mt7988.manifest
drwxr-xr-x 2 pi pi 16K May 1 16:11 packages
-rw-r--r-- 1 pi pi 1.6K May 1 16:11 sha256sums
-rw-r--r-- 1 pi pi 12 May 1 15:37 version.buildinfo
i guess mtk-bpi-r4-SD.img is the right file…uploaded my build-environment and the SD image on my gdrive
Just saying, your lives would be much easier if you would either use GitHub actions or a docker container. Always a fresh checkout, so no issues with old files breaking things. And no pollution of your host OS with tools you might not need or need newer versions of.
I will share my GitHub repository in a couple of days. Just need to finish the configuration for the OpenWrt “from source” build. Currently I only use the imagebuilder for OpenWrt.
1 Like
For compiling this repo this was easiest way…normally i have the tools installed…only because it is fresh install of ubuntu 24.4 i needed debootstrap. Most things were in the chroot. And all now need only unpack the tar.gz,mount their git repo in (or clone inside) and running make.
Now i try to load kernel with initrd instead of flashing image…lets see if this works…
seems this file is the right one:
$ dumpimage -l openwrt-mediatek-mt7988-BPI-R4-SD-initramfs-kernel.bin
FIT description: ARM64 OpenWrt FIT (Flattened Image Tree)
Created: Wed Apr 24 15:22:57 2024
Image 0 (kernel-1)
Description: ARM64 OpenWrt Linux-5.4.260
Created: Wed Apr 24 15:22:57 2024
Type: Kernel Image
Compression: lzma compressed
Data Size: 67256276 Bytes = 65679.96 KiB = 64.14 MiB
Architecture: AArch64
OS: Linux
Load Address: 0x48080000
Entry Point: 0x48080000
Hash algo: crc32
Hash value: bcc5d064
Hash algo: sha1
Hash value: 66756f5105d8316dc96740c4946d9feb04fcbe87
Image 1 (fdt-1)
Description: ARM64 OpenWrt BPI-R4-SD device tree blob
Created: Wed Apr 24 15:22:57 2024
Type: Flat Device Tree
Compression: uncompressed
Data Size: 35589 Bytes = 34.75 KiB = 0.03 MiB
Architecture: AArch64
Hash algo: crc32
Hash value: 9388e8a4
Hash algo: sha1
Hash value: 39e6a39f97d9258992010898f9a483e6b3e16e64
Configuration 0 (config-1)
Description: OpenWrt
Kernel: kernel-1
FDT: fdt-1
so also uploaded to my gdrive…will test tomorrow to load from my uboot
quick test was not working…
BPI-R4> setenv loadaddr 0x80000000
BPI-R4> load usb 0:2 $loadaddr openwrt-mediatek-mt7988-BPI-R4-SD-initramfs-kernel.bin
67293911 bytes read in 5576 ms (11.5 MiB/s)
BPI-R4>
BPI-R4> bootm $loadaddr
## Loading kernel from FIT Image at 80000000 ...
Using 'config-1' configuration
Trying 'kernel-1' kernel subimage
Description: ARM64 OpenWrt Linux-5.4.260
Type: Kernel Image
Compression: lzma compressed
Data Start: 0x800000e8
Data Size: 67256276 Bytes = 64.1 MiB
Architecture: AArch64
OS: Linux
Load Address: 0x48080000
Entry Point: 0x48080000
Hash algo: crc32
Hash value: bcc5d064
Hash algo: sha1
Hash value: 66756f5105d8316dc96740c4946d9feb04fcbe87
Verifying Hash Integrity ... crc32+ sha1+ OK
## Loading fdt from FIT Image at 80000000 ...
Using 'config-1' configuration
Trying 'fdt-1' fdt subimage
Description: ARM64 OpenWrt BPI-R4-SD device tree blob
Type: Flat Device Tree
Compression: uncompressed
Data Start: 0x840241f8
Data Size: 35589 Bytes = 34.8 KiB
Architecture: AArch64
Hash algo: crc32
Hash value: 9388e8a4
Hash algo: sha1
Hash value: 39e6a39f97d9258992010898f9a483e6b3e16e64
Verifying Hash Integrity ... crc32+ sha1+ OK
Booting using the fdt blob at 0x840241f8
Working FDT set to 840241f8
Uncompressing Kernel Image to 48080000
lzma compressed: uncompress error 7
Must RESET board to recover
Resetting the board...
loadaddr should be far away to be not overridden by unpacking fit… 
@dangowrt have you an idea how i can load this huge fit? or do i need to drop unrelated things (which can be dropped from attached config?) from it to make it smaller
config.buildinfo (18,4 KB) feeds.buildinfo (355 Bytes)
edit: flashed the img to card, it boots up, but i get many messages like this:
jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x27f10008: 0x3333 instead
and
mtk_soc_eth 15100000.ethernet eth2: resolve link status: system iface=0
at the end i do not land in openwrt system…it does a reboot 
(no crash or something like this)
maybe they make some kind of rootfs extension and the filesystem was not enlarged fast enough (or not remounted or created a squashfs on top)?
tried to look how the kernel file is loaded, but the default entry is pointing to mtkboardboot which seems to be own command in uboot instead of the bootm
after the reboot it looks like the system stays running…only eth2 spams console which i disabled then it was quiet…at least 3 phys are detected and seem to be up
bpi-r4_owrt-dmesg.txt (47,9 KB)
be14.txt (53,2 KB)
how’s the github actions build repo coming along? please share when ready. already using github actions to build bpi-r4 from openwrt maintree but need help to adapt it to build 21.02 with mediatek feeds as per this mediatek documentation on building from mediatek feeds
tia
I don’t think someone is working on it as the repo does not change much. The work for ci pipeline to work does only make sense for changing repos.
openwrt 21.02 branch doesn’t change much but mediatek feeds does. I will try adapting one to github actions workflow then. Also solves the problem of waiting for bpi to catch up to mediatek releases.
cheers
Afaik you can integrate mtk sdk feed into mainline openwrt,but i’m not sure which kernel is used as sdk is 5.4 and mainline is 6.1/6.6
i doubt it would work. mainline openwrt for filogic is already at 6.6. how will 5.4 even fit in? just a can of worms. i have mainline openwrt building with PPE patches currently. it works and doesn’t crashes but still very very rough on the edges.
was hoping a mtk “blessed” openwrt is more refined
I guess it uses 5.4 defined in sdk and only imagepart and userspace from mainline openwrt.
imho … sounds like a neither here nor there thanks for your feedback thou.