OpenWrt/LEDE Project

  • Status Unconfirmed   Reopened
  • Percent Complete
    0%
  • Task Type Bug Report
  • Category Base system
  • Assigned To No-one
  • Operating System All
  • Severity Low
  • Priority Very Low
  • Reported Version Trunk
  • Due in Version Undecided
  • Due Date Undecided
  • Private
Attached to Project: OpenWrt/LEDE Project
Opened by Thomas Reifferscheid - 27.12.2020
Last edited by Hans Dedecker - 31.12.2020

FS#3539 - ramips/mt7620 snapshot does not boot

It’s happening on
- ramips/mt7620 D-Link DWR 960 with the snapshot of 2020/12/26
- r14281 from 2020/08/26 is working good.

- Steps to reproduce:

Install the factory image onto the stock firmware - or - install the sysupgrade onto the running r14281.

- Findings:

The snapshot version is booted when attempting to get into JBOOT but doesn’t come up automatically.

Please guide/advise. Thank you.
Thomas

- Console output:

1. Regular/Working:
CDG56CDL_0T3 Jboot B972
JRecovery Version R1.2 2016/11/15 14:11
spi device id: ef 40 18 0 0 (40180000)
SPI FLASH: W25Q128FV 16M
.
....................
Starting kernel @ 80000000 ...

2. Bricked state, regular boot:
CDG56CDL_0T3 Jboot B972
JRecovery Version R1.2 2016/11/15 14:11
spi device id: ef 40 18 0 0 (40180000)
SPI FLASH: W25Q128FV 16M
.
.<nothing from here>

3. Bricked state, booting into JBOOT (Hold reset button, power on)
CDG56CDL_0T3 Jboot B972
JRecovery Version R1.2 2016/11/15 14:11
spi device id: ef 40 18 0 0 (40180000)
SPI FLASH: W25Q128FV 16M
.
Reset button had been pressed. <Release Reset button here>
....................
Starting kernel @ 80000000 ...
and the snapshot is booted

4. JBOOT in working state:

CDG56CDL_0T3 Jboot B972
JRecovery Version R1.2 2016/11/15 14:11
spi device id: ef 40 18 0 0 (40180000)
SPI FLASH: W25Q128FV 16M
.
Reset button had been pressed.
Reset button had been pressed
IP = 192.168.123.254 NA = XX:XX:XX:XX:XX:XX

mtd layout on working r14281 (2020/08/26):
root@OpenWrt:~# cat /proc/mtd
dev: size erasesize name
mtd0: 00010000 00001000 “jboot” mtd1: 00fe0000 00001000 “firmware” mtd2: 001fc82e 00001000 “kernel” mtd3: 00de37d2 00001000 “rootfs” mtd4: 00b4d000 00001000 “rootfs_data” mtd5: 00010000 00001000 “config” root@OpenWrt:~#

Thomas Reifferscheid commented on 29.12.2020 20:46

Please do not close the task.

The latest findings is: When compiling trunk/master myself then both options work great. Installing the factory.bin on top of the native firmware and using sysupgrade with the sysupgrade.bin.

As soon as I download and install a snapshot build it fails.

Please find the config attached when compiling trunk/master myself - installing the image goes well with it.

   config (224.9 KiB)
Thomas Reifferscheid commented on 30.12.2020 08:58

The config of the working build:

:~/openwrt$ ./scripts/diffconfig.sh 
CONFIG_TARGET_ramips=y
CONFIG_TARGET_ramips_mt7620=y
CONFIG_TARGET_ramips_mt7620_DEVICE_dlink_dwr-960=y
# CONFIG_DROPBEAR_ED25519 is not set
# CONFIG_KERNEL_KEYS is not set
CONFIG_PACKAGE_ca-certificates=y
CONFIG_PACKAGE_libmbedtls=y
CONFIG_PACKAGE_libustream-mbedtls=y
# CONFIG_PACKAGE_libustream-wolfssl is not set

The mtd layout of the bricked openwrt snapshot install. It was booting after attempting to get into the JBOOT/recovery, pressing reset, switching device on, releasing the reset button after 8 seconds.

 -----------------------------------------------------
 OpenWrt SNAPSHOT, r15371-7e4585e593
 -----------------------------------------------------
root@OpenWrt:~# cat /proc/mtd 
dev:    size   erasesize  name
mtd0: 00010000 00001000 "jboot"
mtd1: 00fe0000 00001000 "firmware"
mtd2: 00203135 00001000 "kernel"
mtd3: 00ddcecb 00001000 "rootfs"
mtd4: 00b20000 00001000 "rootfs_data"
mtd5: 00010000 00001000 "config"
root@OpenWrt:~# 
Russell Senior commented on 30.12.2020 10:55

Fwiw, /proc/mtd doesn't tell you the layout, it only tells you the mapping of partition number to name and size, not offset. You can get offset by looking in dmesg output not too long after boot. I typically pipe dmesg through grep 0x0 for something like this:

# dmesg | grep 0x0
[    0.000000]   Normal   [mem 0x0000000000000000-0x0000000007ffffff]
[    0.000000]   node   0: [mem 0x0000000000000000-0x0000000007ffffff]
[    0.000000] Initmem setup node 0 [mem 0x0000000000000000-0x0000000007ffffff]
[    0.600627] 0x000000000000-0x000000030000 : "u-boot"
[    0.611598] 0x000000030000-0x000000040000 : "u-boot-env"
[    0.623275] 0x000000040000-0x000000050000 : "factory"
[    0.634397] 0x000000050000-0x000002000000 : "firmware"
[    0.670696] 0x000000000000-0x0000001dad67 : "kernel"
[    0.681597] 0x0000001dad67-0x000001fb0000 : "rootfs"
[    0.717737] 0x0000006a0000-0x000001fb0000 : "rootfs_data"

The kernel, rootfs and rootfs_data offsets are relative to the firmware partition, in this case.

Thomas Reifferscheid commented on 31.12.2020 11:16

Please reopen

DazzyWalkman commented on 24.01.2021 15:39

I'd like to share my recent similar experience and workaround.

In short, you may like to try sysupgrade -p <sysupgrade.bin> from CLI.

Now here comes the long part.

Please note, there are no hard findings. Only my observations of a different device and a possible workaround.

My device is mt7621 powered Youhua WR1200JS. Sysupgrades on it were always fine up to r15473-5876ba6460. But when I sysupgraded from r15473 to r15491-7babb978ad, I came across the issue described in the OP, that is, my device won't boot without pressing the reset key when the device rebooted or was powered on.

The bootloader on my device is Breed. Unfortunately I don't have a serial cable to see what actually was going on during startup.

After successful boot with user intervention, the device is running normally. But I don't like the situation as it's not possible to perform remote sysupgrade and the device won't come up on its own when power resumes.

I searched and found this thread. The focus on flash layout indeed shed some light on this problem.

I wondered if a recently enabled kernel module (https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=a1a7f3274e0ed27511d45f62ee20281d8d57c7af) drastically increased the size of the kernel partition and the bootloader did not like it.

So I tried compiling builds with and without lwtunnel enabled, from r15503-33646a51ab to r15533-f13b623f5e, to find that it's not the case. While the size of the kernel partition went up and down as the module flag was switched on/off, it made no difference. The device still needed reset key pressed to boot.

Then I recalled the procedure of installing OpenWRT onto my device. First flash initramfs-kernel.bin, then take a relatedly important however undocumented step: execute sysupgrade -n <sysupgrade.bin> from CLI or flash <sysupgrade.bin> with "don't restore config" checked from Web-UI after the initramfs-kernel boot.

So I tried sysupgrade -n (no restore config), the device reboot ok unattended with all default settings. I experimented further, this time with sysupgrade -p (don't keep partition table, but restore config), this also works, and better with settings kept.

Subsequent sysupgrade -p to r15540-20a7c9d5c9 build with lwtunnel enabled went smoothly.

Then sysupgrade from r15540 to r15554-1bd005ea53 was also ok, even without -p.

Nevertheless, to be on the safe side I've decided to sysupgrade -p every time from now on, for there are some ongoing development activities regarding mtdsplit, may or may not be affecting my device.

Hope this info can help.

Loading...

Available keyboard shortcuts

Tasklist

Task Details

Task Editing