OpenWrt One - Setup, Install, and Discussion

Ping @blogic

Hi John, I received my OpenWrt One device today well ahead of my expectations. Nice looking unit.

Well, I set about setting up a buildroot, adding the device profile, added missing python3-setuptools and swig dependencies, pre-init network config, and my personal patch set only to be confronted with an mt76 failed to build because of a missing autoconf.h header file that is well beyond my abilities to figure out.

make[3]: *** No rule to make target '/home/drdeth/99/openwrt/staging_dir/target-aarch64_cortex-a53_musl/usr/include/mac80211-backport/backport/autoconf.h', needed by '/home/drdeth/99/openwrt/build_dir/target-aarch64_cortex-a53_musl/linux-mediatek_filogic/mt76-2024.09.29~680bc70f/.configured_b1c6ae92f8e974e60b47b3e5ad3573cc'.  Stop.

Not to be deterred, I toddled off to the firmware selector page and here I sit broken hearted with not a clue where to go from there. This isn’t a plastic router!

Do you have a bone or two you might throw to an old dog?

Disclaimer: I'm not an expert on compiling OpenWrt, just trying to help.

Did you set up the build system the way described here?
https://openwrt.org/docs/guide-developer/toolchain/install-buildsystem

1 Like

Yes. I’ve always built from source for every device I’ve used since pretty well day one.

There is not much available that I can find on this device atm.

1 Like

@RuralRoots do any of your patches touch mt76 and/or the buildsystem code ? I just did a fresh build to confirm that current main branch builds fine and it does for me.

@blogic Nothing that targets mt76 to my knowledge, I do patch Global Build Settings/Enable RELRO Protection (if FULL is specified) that removes:

TARGET_CFLAGS += -Wl,-z,now -Wl,-z,relro
TARGET_LDFLAGS += -znow -zrelro

and I also patch 6.6 kernel-generic-config that sets some hardening bits that has never burped on any other platform I build for.

The others just set personal sysctl.d conntrack settings and dnsmasq to listen only on br-lan.

I'll revert those two build system patches and see if that helps the build progress.

Another question if I might regarding inital flash. Can I go right to Sysupgrade image, or must I flash Factory initram image first then Sysupgrade?

@RuralRoots really odd that main branch fails to build. did you try with a fresh unpatched tree ? maybe there is old stuff in tmp/ staging/ ... ?

yes you can use stock sysupgrade images. also check out the howto PDF linked on https://one.openwrt.org/sources/

it explains how to do recovery flashing via USB

It errors out at the same point again. I’ve just blown away the buildroot to do exactly that. This time I’ll just set Target, Subtarget, and Target Profile and build from basic default config.

Thanks for the how-to link, missed that somewhere.

@RuralRoots can you email me a more complete log of the build error please ?

@blogic
Thanks for your assist John. Progress. Still craps out at the kernel initramfs.itb so still missing the factory images atm.

All my local custom feed packages are building as well as my selected openwrt/packages for my production build. Persevering.

config.buildinfo         packages
feeds.buildinfo          build-001-++-10-03-2024-++-r27647+5-b5ffbe7c75-openwrt-one-snapshot-mediatek-filogic-openwrt_one-nor-bl31-uboot.fip
mt7981-ram-ddr3-bl2.bin  build-001-++-10-03-2024-++-r27647+5-b5ffbe7c75-openwrt-one-snapshot-mediatek-filogic-openwrt_one-nor-preloader.bin
mt7981-ram-ddr4-bl2.bin  build-001-++-10-03-2024-++-r27647+5-b5ffbe7c75-openwrt-one-snapshot-mediatek-filogic-openwrt_one-snand-bl31-uboot.fip
mt7986-ram-ddr3-bl2.bin  build-001-++-10-03-2024-++-r27647+5-b5ffbe7c75-openwrt-one-snapshot-mediatek-filogic-openwrt_one-snand-preloader.bin
mt7986-ram-ddr4-bl2.bin  build-001-++-10-03-2024-++-r27647+5-b5ffbe7c75-openwrt-one-snapshot-mediatek-filogic-openwrt_one-squashfs-sysupgrade.itb
mt7988-ram-comb-bl2.bin  version.buildinfo

Regarding ssd m2 form factor from the OpenWrt One How-to https://one.openwrt.org/hardware/OpenWrtOne-HowTo.pdf : Can I confirm the two different form factors for the SSD should be - 2230/2242 and not 2232/2240?

1 Like

Hello, thank you for sharing your first experiences with OpenwrtOne.
I just received my OpenwrtOne and I don't know if I was unlucky, but I can't access the router with the selector in the NAND position, it only starts in the NOR position.
How can I know if there is something wrong with this memory?
Is there a zero step to configure the bot using NAND memory?

I don't understand the meaning of "only starts in the NOR position". Do you mean on power up the leds turn on? Can you interact with the device in the NOR position?

I would try booting into Recovery Mode with NAND enabled. If green led indicates good boot but LuCI doesn’t come up in your browser, try to see if you can access the device via ssh.

My observations so far:

Mine worked out of the box with a standard OpenWrt config (192.168.1.1, and surprising to me for a Snapshot version, with LuCI enabled, (no password, and no wireless enabled).

TBH, the first things I did was to go through the How-to:

  • I want to upgrade the firmware
    I could not upgrade a new firmware from download.openwrt.org, the firmware-selector.openwrt.org, or from my own sysupgrade image through the USB method. From the led indicators it seems to work, white led starts flashing, USB drive light turns on and device boot led shows solid, but I lose all control at this point. Still playing with this ATM.

  • I want to boot into recovery mode
    This process worked as advertised. It booted to an initram image with LuCI that I could then update to a Snapshot image. One caveat here though - if you DL a sysupgrade image from the https://firmware-selector.openwrt.org/ it will come with LuCI installed, but if you get the image from https://downloads.openwrt.org, it will not come with LuCI. You can only access it from ssh root@192.168.1.1 and manually install LuCI.

  • The unit does not boot anymore/full recovery
    This is the only time you need to set the NAND/NOR switch. I used the preloaded.bin and the factory.ubi from the current download.openwrt.org. This also worked as advertised. The same caveat applies re. LuCI depending on where you DL them. I then rebooted into initram recovery mode and I was able to update a sysupgrade image using LuCI.

Right side white led indicates ‘booting from flash’, middle static green led indicates good boot status, left side amber led indicates a fault.

Always power down before setting NAND/NOR switch.

Normal power on: white led flashes indicating firmware loading and green led comes up solid after normal boot.

I apologize for the lack of clarity.

What happens is that in the NOR position the router starts with a classic snapshop installation, without luci but I can access it via ssh and activate the network interfaces that seem to be working fine.

When I try to boot from NAND, all the router's LEDs turn on, but it doesn't seem to boot properly.

I've been trying to capture network logs via tcpdump, but in recovery mode (pressing the reset button for a few seconds while powering it on, all LEDs turn on and then only red led remains on), even though the red light blinks, no activity shows up in the tcpdump. Here's what I see on a normal boot with DHCP and ICMP traffic:

18:28:55.479065 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from f8:e4:3b:d0:06:26, length 293
...
18:29:00.590747 IP6 fe80::8e8f:1272:6790:f04 > ff02::2: ICMP6, router solicitation, length 8
...
18:29:29.467447 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from f8:e4:3b:d0:06:26, length 293

But when in recovery mode, there's no such activity, and no network responses at all.

Some additional details:

  • I’m unsure if the recovery mode is using an IP address I can't detect or if the NAND firmware might not be loading properly.
  • I’ve tried switching between NAND and NOR, and the problem only occurs when I attempt to boot from NAND.
  • I'm considering checking the serial output (UART) to see if I can gather more information from the boot process directly.
  • The MTD output shows various partitions, including ubi and others. The NAND flash is recognized as spi-nand with a size of 256 MiB.
  • The UBI device (ubi0) attached to mtd5 is operational, with no bad or corrupted physical erase blocks.
  • I successfully mounted the UBI volume /dev/ubi0_5 as writable (rw), and created and read a test file without issues.

Recovery Mode should boot into a initramfs environment with an OpenWrt 192.168.1.1 IP address.

The NOR Flash primary purpose is to essentially make the device un-brickable. It would be part of the normal manufacturing process flashed by the Vendor. It is write protected to ensure it remains pristine by a jumper on the board. You should see it on mid board labelled SPI NOR WP.

I have to think your device didn’t come with SPI NAND factory flashed. On my device OOB, a simple power on presents a normal boot experience with LuCI on 192.168.1.1.

I’d be surprised if a NAND failure would get by factory QC, but I can’t confirm NAND flashed is standard policy by the vendor either.

The Reset button on power up when a USB containing a valid sysupgrade.ith image is present, will copy it to RAM allowing you to perform a Sysupgrade from ssh. When no Sysupgrade image is present it will cause the boot loader to flash kernel and rootfs - essentially a clean slate.

The Front panel button when pressed on power up simply boots to an Initram image where you can Sysupgrade the device or use for testing purposes.

The Front panel button with NOR switch selected and nand-preloaded.bin and factory.ubi images present on an attached USB will cause a full factory refresh on the NAND flash presenting an OOB behaviour.

Maybe following a Full Recovery process might help?

I think I have a very serious problem with my NAND memory.
Just starting directly from NAND memory and connected to the serial port (which works beautifully and simply by connecting a USB-C cable to my computer) I have the following serial output:

TICE:  UBI: Bad EC magic in block 2028 ffffffff
NOTIC  UBI: ad Cmagic in block 2029 ffffffff
OTICE:  UBI: Bad EC magic in block 2030 ffffffff
OTICE:  UBI:Bad EC gic in block 2031 ffffffff
OTICE:  UBI:BadCm  lo32 ffffff
TIE:  UBI: Bad C gi inblock2033 ffffffff
TICE:  BI: ad ECmagic in block 234 ffffffff
OTICEUBI: Bad Emagic  bock 203ff
ICE:  UBI: Bad EC magic in block 2036 ffffffff
TICE:  UBI: Bad EC magic in block 2037 fffffff
E:U bckffCEd lock 2039 4e4d4d30
NICE:  UBI: scanning hedTI UBsize: 131072 bytes (128iB, LEB size: 126976 bytes
NOTICE:  UBI: VID header offset: 2048 (aligned 2048), da offset: 4096
Eofip (Id #29761NOTICE:  BL2:ng BL31
OT:(rlease):OpenWrt v2023.10.13~0ea67d-1 (mt798u : Built : 09:3538, May 21 2024

Trying full recovery I have the following error in the serial:

starting USB...
Bus xhci@11200000: xhci-mtk xhci@11200000: hcd: 0x0000000011200000, ippc: 0x0000000011203e00
xhci-mtk xhci@11200000: ports disabled mask: u3p-0x1, u2p-0x0
xhci-mtk xhci@11200000: u2p:1, u3p:1
Register 200010f NbrPorts 2
Starting the controller
USB XHCI 1.10
scanning bus xhci@11200000 for devices... 1 USB Device(s) found
       scanning usb for storage devices... 0 Storage Device(s) found
** Bad device specification usb 0 **
Couldn't find partition usb 0:1
Can't set block device

I loved the serial console interface... will I have to upload the firmware via tftp?

Has anyone tested SQM cake performance on the OpenWRT One yet? I want to make sure it won't be overloaded by softirq like many other routers are when using cake. I see that wireguard performance has been benchmarked here already Add OpenWrt One by aparcar · Pull Request #37 · cyyself/wg-bench · GitHub

Partial answer for you on the SQM question.

I’ve an 80/20 connection and ran the speedtest-netperf script on my shiny new Openwrt One with SQM on and off (default settings) and Snapshot r27893. I had irqbalance and packet steering (All CPUs) enabled and the test was for concurrent upload/download.

With SQM I saw

CPU Load: [in % busy (avg +/- std dev), 59 samples]
     cpu0:  25.9 +/-  3.3
     cpu1:  33.3 +/-  1.6
 Overhead: [in % used of total CPU available]
  netperf:   4.3

And without

CPU Load: [in % busy (avg +/- std dev), 60 samples]
     cpu0:  21.6 +/-  5.3
     cpu1:  18.7 +/-  4.6
 Overhead: [in % used of total CPU available]
  netperf:   4.4

Which looks comfortable. Going to try another connection that’s 150/20 to see how much more it struggles.

2 Likes

And here are the results for the 150/20 connection. Starting to get up to 50% busy. So not a gigabit shaping candidate(!) but fine for many common connection speeds.

SQM off

CPU Load: [in % busy (avg +/- std dev), 59 samples]
     cpu0:  28.6 +/-  1.3
     cpu1:  17.0 +/-  2.1
 Overhead: [in % used of total CPU available]
  netperf:   5.0

SQM on

CPU Load: [in % busy (avg +/- std dev), 59 samples]
     cpu0:  49.6 +/-  3.0
     cpu1:  36.5 +/-  1.6
 Overhead: [in % used of total CPU available]
  netperf:   9.0
2 Likes

It seems that some parts had their flash changed from 128MiB to 256MiB and the bootloader is still waiting for a 128MiB flash. To do this, I had to first update U-boot on NOR using the bootloader connected via the serial port (on the USB-C port on the front of the router) directly on my computer and activate TFTP by setting my computer's IP to the IP suggested by the bootloader.

I did:
Load BL31+U-Boot FIP ​​via TFTP then write to NOR.
and then:
Load BL2 preloader via TFTP then write to NOR.

Then the full recovery via USB (one detail was that I tried many models of USB stick but only the 2GB ones seemed to work)
After the full recovery, the NAND memory worked correctly and I put my libremesh firmware on it to see how it behaves.

2 Likes

Having got my One setup to my satisfaction, and running r27798-dbc2923cbe I've put an NVMe drive into it, which I'll use to keep .ipks and configs between rebuilds (and maybe some other stuff I haven't figured out yet).

It was all very straightforward. With the drive inserted and the One powered up:

opkg update
opkg install e2fsprogs
mkfs.ext4 /dev/nvme0n1
mkdir -p /mnt/nvme
mount /dev/nvme0n1 /mnt/nvme

Running df -h (after copying a few .ipks over) gets me:

Filesystem                Size      Used Available Use% Mounted on
/dev/root                 4.5M      4.5M         0 100% /rom
tmpfs                   493.4M      1.4M    492.0M   0% /tmp
/dev/ubi0_5             201.5M     10.9M    185.9M   6% /overlay
overlayfs:/overlay      201.5M     10.9M    185.9M   6% /
tmpfs                   512.0K         0    512.0K   0% /dev
/dev/nvme0n1            116.8G      4.8M    110.8G   0% /mnt/nvme

The SSD I bought was a HUADISK M2 NVMe SSD 128GB 2242 from Ali Express (after not finding anything I liked the look of on Amazon). If I'd waited a few days more I'd have been tempted by the Raspberry Pi branded SSDs as they're the right (physical) size, and (hopefully) less likely to suffer from supply chain tinkering.