You boot till uboot here and load kernel+rootfs from usb. Is there a way to flash immortalwrt to ubi-partition?
@petraant basicly it should be all erased what is written afterwards. So if you only erase ubi,the bl2+fip may stay old or cause strange issues like the bootloop
Is there a specific nand image or do you flash the emmc image to nand? Normally bootrom needs specific header for each bootdevice
Thank you very much! Where did you get the bl2 from? I can’t see it on EDIT: nevermind the preloader is the BL2
https://firmware-selector.immortalwrt.org/?version=23.05.1&target=mediatek/filogic&id=bananapi_bpi-r3-mini
and when I compile the image myself, for NAND I only get those two files:
...snand-bl31-uboot.fip
...snand-preloader.bin
I forgot to mention that the steps above I did were with the stock image and I only deleted the ubi because the wiki only provides the image .bin (Banana Pi BPI-R3 Mini - Banana Pi Wiki)
You boot till uboot here and load kernel+rootfs from usb. Is there a way to flash immortalwrt to ubi-partition?
I think if you do steps 9. and 10. from @nezar_taima post you can then either use luci to sysupgrade or scp the squashfs to /tmp and start the sysupgrade using the cli. Or was your question to do all the steps directly in U-BOOT without ever booting into openwrt/immortalwrt?
basicly it should be all erased what is written afterwards. So if you only erase ubi,the bl2+fip may stay old or cause strange issues like the bootloop
That makes sense! I was wary of deleting the rest because I flashed the official image and they only provide the image .bin. My goal is to have immortalWRT on EMMC and the “official” image on NAND in case something goes wrong on the EMMC.
Do I have to compile the image myself from SinoVoips github in order to get the bl31 and preloader for NAND?
Is there a specific nand image or do you flash the emmc image to nand? Normally bootrom needs specific header for each bootdevice
What I did until I noticed that my NAND image bootloops is:
dd if=immortalwrt-mediatek-filogic-bananapi_bpi-r3-mini-squashfs-sysupgrade.itb of=/dev/mmcblk0p5 bs=512 conv=fsync
I didn’t touch the NAND since I wanted to keep it stock. That’s why I was a bit confused how this happened.
Sidenote: Right now, when I “repair” the NAND (using the nand image of course) it boots but the EMMC bootloops. When I run the recovery image on EMMC, the EMMC works but the NAND starts bootlooping
I’ve just followed the immortalWRT official instructions by run the following once initramfs has been booted:
umount /mnt/ubi0*
ubidetach -p /dev/mtd4
ubiformat -y /dev/mtd4
ubiattach -p /dev/mtd4
ubimkvol /dev/ubi0 -n 0 -N ubootenv -s 128KiB
ubimkvol /dev/ubi0 -n 1 -N ubootenv2 -s 128KiB
ubimkvol /dev/ubi0 -n 2 -N recovery -s 20MiB
ubimkvol /dev/ubi0 -n 3 -N fit -s 20MiB
ubiupdatevol /dev/ubi0_2 initramfs.itb
ubiupdatevol /dev/ubi0_3 sysupgrade.itb
Ok,was not aware of these additional steps
My plan is to replace official image on nand with the immortalwrt,because the official image has very limited uboot and takes very long to bootup linux (with very much debugs). On emmc i want to boot a debian system like on my other boards (stil struggeling with network-support). I have the phy driver from @ericwoud and dts i’ve prepared with him,phy is detected,but cannot get link on 1g speed
Running debian sounds awesome. Is there a repo I can take a look at?
My plan is to replace official image on nand with the immortalwrt,because the official image has very limited uboot and takes very long to bootup linux (with very much debugs).
I think the steps @nezar_taima described + after booting the initramfs doing the sysupgrade should be the correct way.
not for r3mini yet as i have to get kernel fixed for it first
but for R3 and some other boards: GitHub - frank-w/BPI-Router-Images
basic steps are same, but uboot needs to be changed for r3 mini, as full r3 needs probing for sd/emmc and nand/nor where on r3mini bootconf is fixed (config inside fit image) and uboot needs some change to support network-support (have not yet got phy driver working for the airoha phys - using dts and driver from immortalwrt initial commit - maybe it is fixed afterwards)
your claim that immortalwrt uboot has no network support amaze me. I use the same uboot on EMMC and NAND, and I still can boot a recovery image from tftp. Strange behavior. are u using 1 gig or 2.5 gig nic? if its a 1 gig nic, can you try to test use one of USB 2.5 gbps adapters
I have not said immortalwrt has no network support…my uboot/kernel does not have it and i take patch from immortalwrt:) i guess i miss anything…
this is my uboot tree for r3mini: Commits · frank-w/u-boot · GitHub
I use 1g as link,but yes i can try 2g5 nic on the other side
Oh sorry, I had it wrong. pls ignore my reply
that might be why I can’t get a link in U-BOOT. I’m connecting to a 1gbe nic and nothing happens until i boot into openwrt
wan-port (right one)
BPI-R3M> setenv ipaddr 192.168.90.2
BPI-R3M> ping 192.168.90.1
ethernet@15100000 Waiting for PHY auto negotiation to complete......... TIMEOUT!
ret -110!
ping failed; host 192.168.90.1 is not alive
BPI-R3M>
lan (left port including bootup):
U-Boot 2024.01-bpi-r3mini-00008-g9448f7a5c567-dirty (Jan 17 2024 - 22:57:09 +01)
CPU: MediaTek MT7986
Model: Bananapi BPi-R3 Mini
DRAM: 2 GiB
Core: 44 devices, 19 uclasses, devicetree: separate
MMC: mmc@11230000: 0
Loading Environment from MMC... *** Warning - bad CRC, using default environment
In: serial@11002000
Out: serial@11002000
Err: serial@11002000
Net: PHY = 3a2 - a411
EN8811H PHY ready!
EN8811H Mode 1 !
Tx, Rx Polarity(0xca0f8): 01a01501
MD32 FW Version(0x3b3c) : 23051209
LED initialize OK !
EN8811H initialize OK ! (v1.0.4)
Warning: ethernet@15100000 (eth0) using random MAC address - 22:f9:43:af:15:7c
eth0: ethernet@15100000
Hit any key to stop autoboot: 0
BPI-
BPI-R3M> setenv ipaddr 192.168.90.2
BPI-R3M> ping 192.168.90.1
Using ethernet@15100000 device
ARP Retry count exceeded; starting again
ping failed; host 192.168.90.1 is not alive
BPI-R3M>
link on other side is up (with 2500/fdx) when using lan-port…not when using wan-port, netmask=255.255.255.0, and the other side has also /24 set. so ip configuration is right.
ARP Retry count exceeded; starting again
This issue might be related to using a fake (random) mac address. Try to set ethaddr to the original mac address
My guess is that the wrong phy (both are powered,but only one is connected) is connected to ethernet mac…but of course i can try setting mac address. Strange is that @1715173329 reports he connected wan port,but i see “better” state on lan. Too bad that the schematics does not show the connection between phy and mac. I try to find it out with vendors openwrt image. There it works. But i should start new thread to not pollute this one…
In both cases, using either the official or immortalwrt uboot, recommend to use tcpdump to validate whats happening on wire, also you can capture the real mac address.
Edit: Yes. you are right. phy14(LAN) is the port which is closed to the USB-C connector. may be he reported by mistake.
Is that on u-boot or linux?
Edit: Yes. you are right. phy14(LAN) is the port which is closed to the USB-C connector. may be he reported by mistake.
Thanks for mentioning this. It didn’t even occur to me to test the “LAN” port as the immortalWRT instructions said to connect to the “WAN” port. Will try this later.
I confirmed on the stock image that the RM500U-CNV is indeed working and is getting an IP from my provider without any additional configuration like setting the APN etc. Funny enough the RM500U-CNV doesn’t have “usbnet”,0 . It has 1,3,5,11,13. The Module started working on “usbnet”,3 (which I forgot I set when I was testing the 5G Module on the immortalWRT image)
First I try your changes you made to your .dts (GPIO and Voltage settings). If this doesn’t work I’ll take a look at the code in the sinovoip repo. They seem to have additional binaries in the folder sbin which loads the official quectel-CM and quectel-qmi-proxy. And they have a .patch for the RM500 & RM520 which is almost 3000 lines long.
https://github.com/BPI-SINOVOIP/BPI-R3MINI-OPENWRT-V21.02.3/tree/main/target/linux/mediatek/mt7986/base-files/sbin
My uboot…not done much with linux yet as i want to get tftp working in uboot first. But in my linux network was also not working,but i need to start a new thread for it
@nezar_taima so it works for you with lan-port…maybe i miss a config option. Have you installed a nvme (i do some tests with it too,but not yet recognized)?
For nvme, NO, but actually tried to connect AW7916-NPD through mpcie-to-m2 adapter, unfortunately it was not detected.
hello guys, I recently ported wwan support to immortalwrt, it supports qmi and mbim mode for now.
luci-proto-quectel is used for dialing, luci-app-3ginfo-lite for query module info, and luci-app-modemband for band locking.
see: GitHub - immortalwrt/wwan-packages: Applications for WWAN support
also fixed 2 bugs on bpi r3-mini: power on the wwan module, and (hopefully) r/w issue on spi-nand
Very cool! Any chance this will get into the official OpenWrt?