Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

FS#3539 - ramips/mt7620 snapshot does not boot #8576

Closed
openwrt-bot opened this issue Dec 27, 2020 · 7 comments
Closed

FS#3539 - ramips/mt7620 snapshot does not boot #8576

openwrt-bot opened this issue Dec 27, 2020 · 7 comments
Labels

Comments

@openwrt-bot
Copy link

reiffert:

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

  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.
    ....................
    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:
#

@openwrt-bot
Copy link
Author

reiffert:

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.

@openwrt-bot
Copy link
Author

reiffert:

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:
#

@openwrt-bot
Copy link
Author

russell:

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.

@openwrt-bot
Copy link
Author

reiffert:

Please reopen

@openwrt-bot
Copy link
Author

DazzyWalkman:

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.

@openwrt-bot
Copy link
Author

CHKDSK88:

It looks, that Jboot can not read images with kernel bigger than 2MB:

#4249 (comment)

@CHKDSK88
Copy link
Contributor

@aparcar

With #4249 and #4255 this was resolved.

This issue could be closed.

@aparcar aparcar closed this as completed Feb 15, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants