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

Loading...

Available keyboard shortcuts

Tasklist

Task Details

Task Editing