john says he tested it with r3, i have only tried with r3mini, but cannot get my nvme working with it
I’m tempted to give it a go. Is that the only patch I need to cherry pick, assuming I would use your 2024-01-bpi branch?
Yes and the patch for missing constant and of course enabling the options like i did for r3mini
Then you should be able to do this
OpenWrtOne> pci enum
OpenWrtOne> pci
BusDevFun VendorId DeviceId Device Class Sub-Class
00.00.00 0x14c3 0x1f32 Bridge device 0x04
01.00.00 0x144d 0xa80b Mass storage controller 0x08
OpenWrtOne> nvme scan
OpenWrtOne> nvme info
Device 0: Vendor: 0x144d Rev: 7L1QHXC7 Prod: S67PNF0W854510
Type: Hard Disk
Capacity: 244198.3 MB = 238.4 GB (500118192 x 512)
For debugging purposes you can load u-boot.bin from usb/tftp and use go command on the loadaddr. This way you don’t need built with atf everytime and flash it…but i guess your current uboot does not have go command yet,so you have to do it once…ah you using erics image and loading uboot from atf? Then you will not need atf compile around uboot i guess
Had to change the constant patch a little bit (see attached) but other than that it worked perfectly. I now have u-boot on my sdcard and everything else on my nvme. No more messy backup restores for me. Thanks for all the help.
Btw, if anyone is interested, my nvme is a Samsung 980 1TB.
1 Like
thank you very much for finding my mistake…with this fixed i can also see my nvme on r3mini
BPI-R3M> pci enum
drivers/pci/pcie_mediatek_gen3.c:mtk_pcie_startup_port[261] detected a card
set trans table 0: 0x20000000 0x20000000, 0x10000000
BPI-R3M> pci
BusDevFun VendorId DeviceId Device Class Sub-Class
_____________________________________________________________
00.00.00 0x14c3 0x1f32 Bridge device 0x04
01.00.00 0x1c5c 0x1327 Mass storage controller 0x08
BPI-R3M> nvme scan
BPI-R3M>
BPI-R3M> nvme info
Device 0: Vendor: 0x1c5c Rev: 80002C00 Prod: ND94N163610404F0R
Type: Hard Disk
Capacity: 244198.3 MB = 238.4 GB (500118192 x 512)
BPI-R3M>
So we got PCIe support in U-Boot and we also got lots of on-board SPI-NOR flash and want to boot from NVMe. What I would do is what every PC or Apple mainboard is doing: store system firmware (“BIOS”) in the SPI-NOR and have that use some generic method to boot from the NVMe (e.g. UEFI or U-Boot’s distro standard boot).
In case of the R3 (or R3 mini or R4) this means that TF-A and U-Boot should be in SPI-NOR, and U-Boot can be configured to carry out UEFI Standard boot and consider both USB and NVMe according to EFI boot variables, just like on a PC. That would put an end to writing endless how-tos for each and every board, and would allow standard installers of most Linux distributions with sufficient kernel driver support to just work.
Maybe porting Tow-Boot for the R3 (and the R4 and esp. also the R2 and R2Pro!) would be a worthwhile idea for that use-case. I’m using that every day on the PineBook Pro… https://tow-boot.org/
For OpenWrt (and hence for me) this is not so attractive: OpenWrt is headless and fits in a couple of megabytes of flash; the userland is tightly tied to the kernel – no need for even a EFI boot filesystem to chose which kernel to load as kernel and userland are inseparable anyway, all in one uImage.FIT.
But I was kinda betting that all other (more storage intense) distros would jump on the Standard Boot train to rid themselves of per-board custom installer images and all the maintenance effort associated with that.
1 Like
Finally got to testing eMMC installation from Openwrt (in NAND). Downloaded pre-made AP image.gz from http://www.woudstra.mywire.org/images/bpir3-emmc-ap.img.gz and prepared to sda1 USB as instructed… Managed to install all necessary packages to openwrt and run the commands:
gunzip -c /mnt/sda1/bpir.img.gz | dd of=/dev/mmcblk0 bs=4M conv=fsync
mmc bootpart enable 7 1 /dev/mmcblk0
After few minutes all was done, but after switching DIPS to eMMC(LHHL) and PowerOn I can’t access AP on 192.168.1.33 and no WIFI24 on air.
Seems something is not working as expected…
Is the ’ bootpart enable 7 1 /dev/mmcblk0’ still valid for the latest image?
Can I do something for diagnostics from openwrt?
You can connect debuguart before powering on and share log how far the system goes…maybe system boots completely and wifi firmware is missing or any setting is wrong which basicly prevents wifi to work
I have a trick on R3, so that atf is on /dev/mmcblk0 , not boot0.
Needs dipswitches LLLH., or HLLL depends which way you look at it.
I’ll check if this is in the readme also.
“Flip SD/EMMC switch (most near to power plug), the rest stay up!”
Anyway, on the R3 the Emmc image can be written to booting from my sdmmc image. That is described in the readme.
Edit: it can actually be used to write any image to emmc while booting from sd.
Thanks, no need to messing with NAND to install eMMC image is fantastic news for me, but I’m still a bit confused and need some clarification 
I’m sorry have read the readme but didn’t understand that I can do this (haven’t run your build script yet).
I prefer to flash pre-built images if possible, not used to build anything myself until I’m familiar with the process. So if I understand it correctly I can download your pre-built sdmmc image and flash it to SD card. The DIPS should stay LLLH during SD boot and eMMC installation. After booting from SD I can flash the same image file(or emmc version?) to eMMC somehow (using your script)?
Need to find some details how to format eMMC via putty (without uart) after boot from SD, or does your script also include re-formatting eMMC before image installation?
Before booting from eMMC I should switch the DIPS back to LHHL…
Everything is pre-build in packages, so even using my build script, you are not really building, only installing fully automated…
But it can be done with prebuild images.
dd the sd image to a sd card. Then cp the emmc image in the tmp folder of the sd card.(root partition), rename it bpir.img.gz.
Boot sd with the normal sd card dip settings, keep shift+e pressed. Then follow the instuctions, it tells you when to flip which dip switch. Then you are done, remove sd card and boot archlinux-arm from emmc. I could not make it easier… I have done some updates after that, but it still should work like this. If not, I would like to hear that.
1 Like
Thanks, I have finally booted my Openwrt NAND to eMMC Arch installation, working fine now.
Not sure whether changing DIPS to HHHL or activating boot partition via mmc bootpart enable 1 1 /dev/mmcblk0 helped but after these 2 changes booting Arch from eMMC started to work, yay.
I’m close to replacing my old OpenWrt router for R3@ArchLinux but have last remaining WiFi issue to resolve.
Fast Transition between R3@ArchLinux and 2 remaining OpenWrt routers is not working. Same ssid & wpa_passphrase, mobility_domain set to default(which calculation is identical on both systems) but devices connected to OpenWrt refuse connection to R3@Arch. have following settings enabled on both systems:
ft_psk_generate_local=1
ft_over_ds=1
Seems something is still missing in my /etc/hostapd/wlan0.conf. Anyone with Fast transition working between Arch and OpenWrt APs with some advice?
Did you:
wpa_key_mgmt=WPA-PSK FT-PSK
You could just try to set
mobility_domain=a1b2
On all systems.
Then it is most important that everything is connected at layer-2 level. That means, only using bridges and sort. No ipforward (wan to lan transistion, nat translation, etc) in the chain between the bridges that contain the wifi interfaces.
I have only used FT, all systems running archlinuxarm.
Sure, pls see my PK & FT configuration below:
wpa=2
wpa_passphrase=xxxxxxxx
wpa_key_mgmt=WPA-PSK FT-PSK
wpa_pairwise=CCMP
# 802.11r
mobility_domain=$(echo $ssid | md5sum | cut -c1-4)
nas_identifier=$HOSTNAME-$interface
ft_psk_generate_local=1
ft_over_ds=1
According to OpenWrt developer mobility_domain calculation is the same:
Have checked the echo command on both systems and result was identical, but will test also with hard-coded value. Between APs is only core managed switch without VLANs. Seems to me something else must be different but can’t find it…
Also hardcoded then, different on all systems
Is openwrt also set to WPA-PSK and CCMP?
OpenWrt settings are following:
Have cipher set to “Force TKIP and CCMP (AES)”, there is another option “Force CCMP”… Do you think TKIP enabled on OpenWrt could be the reason?
My experience is that almost eveything in the hostapd.conf, as I have it in archlinuxarn, needs to match, also these settings. Although it has been a while since I last experimented with it.
Btw, in /run/ you can find the real hostapd.conf with all bash variables expanded.
OK, will try to match all the settings and test again…thanks
After upgrade from previous quick pre-built AP image (2024-02-06) to the latest version (2024-03-15) Fast Transition works. Not sure what was wrong with my previous installation but WiFi client migration from Openwrt to Arch works now(with default mobility_domain).
Some missing packages occurred when tried to install networkmanager for cockpit which worked fine with previous version.
error: failed retrieving file 'nss-3.98-1-aarch64.pkg.tar.xz' from mirror.archlinuxarm.org : The requested URL returned error: 404
P.S. There is a newer package version nss-3.99-1-aarch64.pkg.tar.xz online…after full upgrade (pacman -Syu) the installation worked fine. But it seems WiFi problems start after networkmanager installation. Will try to figure-out how to create AP with networkmanager so I can manage system via cockpit webpages.
Always use the y in the options here, to prevent those errors. Partial upgrades usually work, but officially is not supported. This means when installing/upgrading 1 package, all packages need upgrading.