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?
@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.
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.
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.
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?