Correct place to file these OpenWrt One bug reports

With the OpenWrt One the sysupgrade via flash, there is no green LED after the flash is done, although the flash succeeds.

The last line of the follow boot log is the likely clue needed:

22020894 bytes written to volume fit
## Error: "led_loop_done" not defined

Also, it is not clear from the documentation that require filename of the sysupgrade file is not sysupgrade.itb as stated on https://openwrt.org/toh/openwrt/one, but rather openwrt-mediatek-filogic-sysupgrade.itb (or somesuch; I don’t remember the exact name at the moment and am nowhere near the computer with the image I flashed), as the serial terminal bootlog will indicate if you have sysupgrade.itb on your USB stick).

And finally, the USB sysupgrade is incompatible with (at least Kingston Data Traveller) sticks >32GB, even if partitioned to <32 GB on an msdos partition table.

off
on
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... 2 USB Device(s) found
       scanning usb for storage devices... 1 Storage Device(s) found
22020894 bytes read in 763 ms (27.5 MiB/s)

## Checking Image at 46000000 ...
   FIT image found
   FIT description: ARM64 OpenWrt FIT (Flattened Image Tree)
    Image 0 (kernel-1)
     Description:  ARM64 OpenWrt Linux-6.6.110
     Type:         Kernel Image
     Compression:  gzip compressed
     Data Start:   0x46001000
     Data Size:    5646598 Bytes = 5.4 MiB
     Architecture: AArch64
     OS:           Linux
     Load Address: 0x44000000
     Entry Point:  0x44000000
     Hash algo:    crc32
     Hash value:   04cd86be
     Hash algo:    sha1
     Hash value:   883dc3591af261655e48560190d121a8f4590293
    Image 1 (fdt-1)
     Description:  ARM64 OpenWrt openwrt_one device tree blob
     Type:         Flat Device Tree
     Compression:  uncompressed
     Data Start:   0x46564000
     Data Size:    29860 Bytes = 29.2 KiB
     Architecture: AArch64
     Load Address: 0x43f00000
     Hash algo:    crc32
     Hash value:   679d6e39
     Hash algo:    sha1
     Hash value:   ce5351a5bab3d6e368d53719ef68fa64b548da9d
    Image 2 (rootfs-1)
     Description:  ARM64 OpenWrt openwrt_one rootfs
     Type:         Filesystem Image
     Compression:  uncompressed
     Data Start:   0x4656c000
     Data Size:    16330752 Bytes = 15.6 MiB
     Hash algo:    crc32
     Hash value:   b251ddb2
     Hash algo:    sha1
     Hash value:   0c3019c9ee07d6ead6333466c5d2dc6cc6f93dc8
    Default Configuration: 'config-1'
    Configuration 0 (config-1)
     Description:  OpenWrt openwrt_one
     Kernel:       kernel-1
     FDT:          fdt-1
     Loadables:    rootfs-1
## Checking hash(es) for FIT Image at 46000000 ...
   Hash(es) for Image 0 (kernel-1): crc32+ sha1+
   Hash(es) for Image 1 (fdt-1): crc32+ sha1+
   Hash(es) for Image 2 (rootfs-1): crc32+ sha1+
Remove UBI volume fit (id 4)
Remove UBI volume rootfs_data (id 5)
Creating dynamic volume fit of size 22020894
22020894 bytes written to volume fit
## Error: "led_loop_done" not defined


Although I don't own this device, I'm pretty sure that this has been known for a long time and has already been fixed (if you upgrade the bootloader/ NOR image).

Or somesuch is the keyword here, because the file name will differ (release versions will have the version number inside as well). While it might be confusing, sysupgrade.itb is the sensible (abbreviated) form here.

1 Like

sysupgrade.itb does not work - that is what I originally had and the bootloader reported no image found when looking for openwrt-mediatek-filogic-sysupgrade.itb (no version in the filename it was looking for). Changing the name to what it was looking for worked.

Which would be the correct git repository to go searching for the commit that fixes said issue? (OpenWrt has many git repositories, and it is not often to some not actively doing development which component is in play for something like this).

EDIT: As it happens I typoed in my searches.

Also, it appears the second issue is not resolved as the only bootfile mentioned is:

This I consider more of a documentation (wiki) issue.

I, however, wish to confirm my interpretation of the code, which matches my experience, before editing the wiki.

And the third issue I’m guessing (but do not know) is a U-boot issue, and is outside my expertise.

For the first issue, for future reference, here is the issue and commit fixing it:

@psherman @blogic Am I reading this correctly, or should sysupgrade.itb work as well (so that this is not just a documentation bug for me to fix on the wiki)? I’ll update the wiki noting the need for the filename to be openwrt-mediatek-filogic-openwrt_one-squashfs-sysupgrade.itb in a couple of days unless you, or someone else who knows the answer to that question, indicates that is incorrect, as said update matches what I experienced and what I see in the code.

I've never had an issue with a sysupgrade filename. I've never used a Release build, but my own builds all use this format:
openwrt-one---build-011-r31536+6-f5fd7ef888-10-21-01-2025-snapshot-6.12-mediatek-filogic-openwrt_one-squashfs-sysupgrade.itb

I used the USB method on my first build back in Oct. 2024 using a similar sysupgrade filename format without an issue. Since then I just use the typical sysupgrade process for subsequent builds.

I’ll have to do some more testing then. I know that for the sysupgrade command, owut, and luc-attendedsysupgrade the names are not an issue, but for the USB method I got an error message on the serial terminal when using sysupgrade.itb but when I changed the name as described the flash was successful. So, not sure what to conclude. Fortunately I have an OpenWrt One I bought specifically to be able to thwack on when needed, so I guess this is an opportunity to actually use it for the purpose for which I bought it. I’ll hook up serial and experiment with filenames.

EDIT: Not sure how

could use any filename other than the one at line #531 (as shown in the code above). I don’t see any reassignment of bootfile_upg anywhere in the u-boot script, but will still do testing to verify.

FYI current version of

states:

  • Prepare an USB drive that contains the file
    • openwrt-mediatek-filogic-openwrt_one-squashfs-sysupgrade.itb

I've got my test OpenWrt One ready for doing some verification, too.

Testing confirms my findings:

With filename openwrt-24.10.4-mediatek-filogic-openwrt_one-squashfs-sysupgrade.itb:

off
on
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... 2 USB Device(s) found
       scanning usb for storage devices... 1 Storage Device(s) found
Failed to load 'openwrt-mediatek-filogic-openwrt_one-squashfs-sysupgrade.itb'

With filename sysupgrade.itb:

off
on
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... 2 USB Device(s) found
       scanning usb for storage devices... 1 Storage Device(s) found
Failed to load 'openwrt-mediatek-filogic-openwrt_one-squashfs-sysupgrade.itb'

With filename openwrt-mediatek-filogic-openwrt_one-squashfs-sysupgrade.itb:

off
on
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... 2 USB Device(s) found
       scanning usb for storage devices... 1 Storage Device(s) found
10748204 bytes read in 571 ms (18 MiB/s)

## Checking Image at 46000000 ...
   FIT image found
   FIT description: ARM64 OpenWrt FIT (Flattened Image Tree)
    Image 0 (kernel-1)
     Description:  ARM64 OpenWrt Linux-6.6.110
     Type:         Kernel Image
     Compression:  gzip compressed
     Data Start:   0x46001000
     Data Size:    5646598 Bytes = 5.4 MiB
     Architecture: AArch64
     OS:           Linux
     Load Address: 0x44000000
     Entry Point:  0x44000000
     Hash algo:    crc32
     Hash value:   04cd86be
     Hash algo:    sha1
     Hash value:   883dc3591af261655e48560190d121a8f4590293
    Image 1 (fdt-1)
     Description:  ARM64 OpenWrt openwrt_one device tree blob
     Type:         Flat Device Tree
     Compression:  uncompressed
     Data Start:   0x46564000
     Data Size:    29860 Bytes = 29.2 KiB
     Architecture: AArch64
     Load Address: 0x43f00000
     Hash algo:    crc32
     Hash value:   679d6e39
     Hash algo:    sha1
     Hash value:   ce5351a5bab3d6e368d53719ef68fa64b548da9d
    Image 2 (rootfs-1)
     Description:  ARM64 OpenWrt openwrt_one rootfs
     Type:         Filesystem Image
     Compression:  uncompressed
     Data Start:   0x4656c000
     Data Size:    4997120 Bytes = 4.8 MiB
     Hash algo:    crc32
     Hash value:   6323b2b2
     Hash algo:    sha1
     Hash value:   5464c34c400f52b337812a5b8238f9d1e543ae23
    Default Configuration: 'config-1'
    Configuration 0 (config-1)
     Description:  OpenWrt openwrt_one
     Kernel:       kernel-1
     FDT:          fdt-1
     Loadables:    rootfs-1
## Checking hash(es) for FIT Image at 46000000 ...
   Hash(es) for Image 0 (kernel-1): crc32+ sha1+ 
   Hash(es) for Image 1 (fdt-1): crc32+ sha1+ 
   Hash(es) for Image 2 (rootfs-1): crc32+ sha1+ 
Remove UBI volume fit (id 4)
Remove UBI volume rootfs_data (id 5)
Creating dynamic volume fit of size 10748204
10748204 bytes written to volume fit
## Error: "led_loop_done" not defined

Which gives:

BusyBox v1.36.1 (2025-10-19 16:37:45 UTC) built-in shell (ash)

  _______                     ________        __
 |       |.-----.-----.-----.|  |  |  |.----.|  |_
 |   -   ||  _  |  -__|     ||  |  |  ||   _||   _|
 |_______||   __|_____|__|__||________||__|  |____|
          |__| W I R E L E S S   F R E E D O M
 -----------------------------------------------------
 OpenWrt 24.10.4, r28959-29397011cc
 -----------------------------------------------------

i.e. successful flash to 24.10.4 via USB, replacingthe 24.10.0 that had previously been flashed via sysupgrade.

Will update the wiki shortly.

After looking at my notes, it appears your observation is correct.

At the time of my initial testing from https://one.openwrt.org/hardware/OpenWrtOne-HowTo.pdf there was only one sysupgrade.itb from the project, so I did in fact use the openwrt-mediatek-filogic-openwrt_one-squashfs-sysupgrade.itb to flash from USB, and have never used this method since.

1 Like

Thank your for confirming. I wondered if it was something like that. No harm done, as it made sure I cross-checked multiple ways!

I probably encountered the same thing as you did.
I did name the file openwrt-mediatek-filogic-openwrt_one-squashfs-sysupgrade.itb, but on the first USB stick (8GB Kingston DataTraveler G2), I got this error msg:

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... 2 USB Device(s) found
       scanning usb for storage devices... 1 Storage Device(s) found
...
Error reading cluster
Failed to load 'openwrt-mediatek-filogic-openwrt_one-squashfs-sysupgrade.itb'

I don't think it (should) matter, but it was a custom 24.10.4 build with some additional packages and some custom uci-defaults.

I then saw that "some USB drives have incompatibility issues", so I tried another one (with only that file on it). FWIW: the sha256sum of that file was the same on both USB sticks and my 'HDD'.
First attempt didn't work. Dunno why.
Then tried it again and that worked ... at least the last message is:
## Error: "led_loop_done" not defined

So I guess that's a good sign?
Orange LED is still blinking slowly, but I guess removing the power and plugging it back in is the only way that's stop.
I had a minor issue in my uci-defaults, but it's all working now :smiley:

Full serial log here: https://paste.sr.ht/~diederik/58cfddeec3f8cc067b5614b5aa5672c117b4750e

@diedrik It sounds like you hit some of the same issues, for sure. Tthe led_loop_done issue means that you can't tell by the LED that flashing completed (but if you have a serial connected and see "led_loop_done" not defined, it has completed and you can safely remove power and plug it back in).

Glad to hear you got it working. Enjoy!

1 Like