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#3057 - ramips/mt7621/edimax_ra21s boot failure with kernel 5.4 #8094

Closed
openwrt-bot opened this issue Apr 28, 2020 · 9 comments
Closed

FS#3057 - ramips/mt7621/edimax_ra21s boot failure with kernel 5.4 #8094

openwrt-bot opened this issue Apr 28, 2020 · 9 comments
Labels

Comments

@openwrt-bot
Copy link

UAb5eSMn:

Boot fails on snapshot images with kernel 5.4

  • Device: ramips/mt7621/edimax_ra21s
  • Software: Any snapshot image with kernel 5.4

Partial serial console log with an official snapshot image. The boot process hangs after printing the kernel version line:

....
3: System Boot system code via Flash.

Booting image at bfc50000 ...

Image Name: MIPS OpenWrt Linux-5.4.35

Image Type: MIPS Linux Kernel Image (lzma compressed)

Data Size: 2439444 Bytes = 2.3 MB

Load Address: 80001000

Entry Point: 80001000

Verifying Checksum ... OK

Uncompressing Kernel Image ... OK

No initrd

Transferring control to Linux (at address 80001000) ...

Giving linux memsize in MB, 256

Starting kernel ...

[ 0.000000] Linux version 5.4.35 (builder@buildhost) (gcc version 8.4.0 (OpenWrt GCC 8.4.0 r13089-3fdb08681b)) #0 SMP Sun Apr 26 22:25:12 2020

Partial serial console log after booting an image I compiled myself. An LZMA error is displayed and the device gets into a reboot loop:

....
3: System Boot system code via Flash.

Booting image at bfc50000 ...

Image Name: MIPS OpenWrt Linux-5.4.35

Image Type: MIPS Linux Kernel Image (lzma compressed)

Data Size: 2439479 Bytes = 2.3 MB

Load Address: 80001000

Entry Point: 80001000

Verifying Checksum ... OK

Uncompressing Kernel Image ... LZMA ERROR 1 - must RESET board to recover

===================================================================

            MT7621   stage1 code Mar 12 2015 14:43:30 (ASIC)

            CPU=50000000 HZ BUS=12500000 HZ

==================================================================
....

With the patch below, the device boots correctly:

diff --git a/target/linux/ramips/image/mt7621.mk b/target/linux/ramips/image/mt7621.mk
index d5527cd98d..43eb04e53f 100644
--- a/target/linux/ramips/image/mt7621.mk
+++ b/target/linux/ramips/image/mt7621.mk
@@ -249,6 +249,7 @@ endef
TARGET_DEVICES += d-team_pbr-m1

define Device/edimax_ra21s

  • $(Device/uimage-lzma-loader)
    IMAGE_SIZE := 16064k
    DEVICE_VENDOR := Edimax
    DEVICE_MODEL := RA21S
    @@ -262,6 +263,7 @@ endef
    TARGET_DEVICES += edimax_ra21s

define Device/edimax_rg21s

  • $(Device/uimage-lzma-loader)
    IMAGE_SIZE := 16064k
    DEVICE_VENDOR := Edimax
    DEVICE_MODEL := Gemini AC2600 RG21S

Note that the patch should also work on the edimax_rg21s, which has identical hardware. I've not tested on that device. The bootloader searches for the default tftp image uImage_ELECOM-WRC-2533GHBK-I, so it's likely that more devices exist that are based on the same ELECOM WRC-2533GHBK-I hardware:

2: System Load Linux Kernel then write to Flash via TFTP.

Warning!! Erase Linux in Flash then burn new one. Are you sure?(Y/N)

Please Input new ones /or Ctrl-C to discard

    Input device IP (192.168.99.9) ==:192.168.99.9

    Input server IP (192.168.99.8) ==:192.168.99.8

    Input Linux Kernel filename (uImage_ELECOM-WRC-2533GHBK-I) ==:uImage_ELECOM-WRC-2533GHBK-I
@openwrt-bot
Copy link
Author

UAb5eSMn:

I don't understand why it's closed as not a bug?

@openwrt-bot
Copy link
Author

ynezz:

If you look at the [[https://bugs.openwrt.org/index.php?do=details&task_id=3057#history|history]], you can see, that it was requested.

@openwrt-bot
Copy link
Author

falaca:

I can confirm that my Edimax RG21S fails to boot from the kernel in the official nightly build from the website. It hangs right after the following output:

Starting kernel ...

[ 0.000000] Linux version 5.4.43 (builder@buildhost) (gcc version 8.4.0 (OpenWrt GCC 8.4.0 r13438-e73c61a978)) #0 SMP Tue Jun 2 16:25:44 2020

When I build the image myself from git, using the device profile for the RG21S, it boots successfully. So the following was suggested to me on IRC:

pkgadd: there is one thing that might differ between official builds and your self-built ones, which might be particularly pronounced on ramips. if you build your own image, you're likely building with a rather targetted build config for your device - the official builds cover all devices, that has slight impact on the number of kernel features to be enabled and might raise the kernel size a bit. with kernel 5.4,
pkgadd: we've already seen that some OEM bootloaders on ramips don't cope well with that - so you might see that on your device

I compared my self-built kernel with the downloaded version, and it was indeed smaller (2331557 vs. 2444793 bytes). Using the "config.buildinfo" from this page, I built a similarly-configured image (e.g., with all modules enabled) that was larger in size: https://downloads.openwrt.org/snapshots/targets/ramips/mt7621/

After flashing my new (larger) self-built image, I ran into the same result as the image downloaded from openwrt.org, i.e., it fails to boot. So I gradually cut down on the kernel modules to see if I could find some threshold for where the failure occurs. Here is the summary of all the kernels that I attempted, along with their respective sizes:

2444793 bytes (downloaded): Fails to boot
2444330 bytes (self-built, almost all modules enabled): Fails to boot
2437280 bytes (self-built, some modules disabled): Begins to boot, but kernel panic occurs during boot process
2433139 bytes (self-built, more modules disabled): Boots successfully
2402126 bytes (self-built, even more modules disabled): Boots successfully
2331557 bytes (self-built, with minimum required modules for RG21S): Boots successfully

So, it seems that the threshold where it fails is somewhere between 2433139 and 2437280 bytes.

Here is the log of the kernel that begins booting but panics (when comparing with a successful boot, it seems normal to me until the last 3 lines):

## Booting image at bfc50000 ... Image Name: MIPS OpenWrt Linux-5.4.43 Image Type: MIPS Linux Kernel Image (lzma compressed) Data Size: 2437280 Bytes = 2.3 MB Load Address: 80001000 Entry Point: 80001000 Verifying Checksum ... OK Uncompressing Kernel Image ... OK No initrd ## Transferring control to Linux (at address 80001000) ... ## Giving linux memsize in MB, 256

Starting kernel ...

[ 0.000000] Linux version 5.4.43 (furkan@t) (gcc version 8.4.0 (OpenWrt GCC 8.4.0 r13145-0836d0dea2)) #0 SMP Tue Jun 2 16:25:44 2020
[ 0.000000] SoC Type: MediaTek MT7621 ver:1 eco:3
[ 0.000000] printk: bootconsole [early0] enabled
[ 0.000000] CPU0 revision is: 0001992f (MIPS 1004Kc)
[ 0.000000] Initrd not found or empty - disabling initrd
[ 0.000000] VPE topology {2,2} total 4
[ 0.000000] Primary instruction cache 32kB, VIPT, 4-way, linesize 32 bytes.
[ 0.000000] Primary data cache 32kB, 4-way, PIPT, no aliases, linesize 32 bytes
[ 0.000000] MIPS secondary cache 256kB, 8-way, linesize 32 bytes.
[ 0.000000] Zone ranges:
[ 0.000000] Normal [mem 0x0000000000000000-0x000000000fffffff]
[ 0.000000] HighMem empty
[ 0.000000] Movable zone start for each node
[ 0.000000] Early memory node ranges
[ 0.000000] node 0: [mem 0x0000000000000000-0x000000000fffffff]
[ 0.000000] Initmem setup node 0 [mem 0x0000000000000000-0x000000000fffffff]
[ 0.000000] OF: fdt: No valid device tree found, continuing without
[ 0.000000] percpu: Embedded 14 pages/cpu s26704 r8192 d22448 u57344
[ 0.000000] Built 1 zonelists, mobility grouping on. Total pages: 64960
[ 0.000000] Kernel command line: rootfstype=squashfs,jffs2
[ 0.000000] Dentry cache hash table entries: 32768 (order: 5, 131072 bytes, linear)
[ 0.000000] Inode-cache hash table entries: 16384 (order: 4, 65536 bytes, linear)
[ 0.000000] Writing ErrCtl register=00066094
[ 0.000000] Readback ErrCtl register=00066094
[ 0.000000] mem auto-init: stack:off, heap alloc:off, heap free:off
[ 0.000000] Memory: 250576K/262144K available (5826K kernel code, 202K rwdata, 1256K rodata, 1280K init, 237K bss, 11568K reserved, 0K cma-reserved, 0K highmem)
[ 0.000000] SLUB: HWalign=32, Order=0-3, MinObjects=0, CPUs=4, Nodes=1
[ 0.000000] rcu: Hierarchical RCU implementation.
[ 0.000000] rcu: RCU calculated value of scheduler-enlistment delay is 25 jiffies.
[ 0.000000] NR_IRQS: 256
[ 0.000000] random: get_random_bytes called from start_kernel+0x340/0x558 with crng_init=0
[ 0.000000] Kernel panic - not syncing: Failed to find mtk,mt7621-sysc node
[ 0.000000] Rebooting in 1 seconds..
[ 0.000000] Reboot failed -- System halted

BTW, the bootloader on the RG21S might be configured slightly differently than on the RA21S. The RG21S does not attempt TFTP recovery unless you enter "2" from the boot menu in the serial console, and the default file name it looks for is "uImage_EDIMAX-6877AC-RG21S".

@openwrt-bot
Copy link
Author

UAb5eSMn:

Your RG21S error appears to be the same issue as mine, so I'm pretty sure that the $(Device/uimage-lzma-loader) patch to target/linux/ramips/image/mt7621.mk will work for you too.

It has been fixed for some devices. E.g. https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=ad19751edc21ae713bd95df6b93be64bd1e0c612

On my RA21S, TFTP isn't automatic either. I also have to enter "2" in the boot menu.

@openwrt-bot
Copy link
Author

falaca:

Confirmed that the patch solves the problem for me too, on my RG21s. Could you submit a pull request? If not, let me know and I can submit one. Seems simple enough that it should be pretty straightforward to have it accepted.

@openwrt-bot
Copy link
Author

UAb5eSMn:

Good that it works for you too.
If you can submit a pull request, that would be great. I'd rather not do that myself, because of the real-name policy.

@openwrt-bot
Copy link
Author

UAb5eSMn:

Thanks furkan, the pull request got merged. Todays snapshot edimax_ra21s-squashfs-sysupgrade.bin boots successfully (commit r13762-358aec7775 / 358aec7).

If your RG21S also works, this ticket can be closed.

@openwrt-bot
Copy link
Author

falaca:

No problem, and thanks to you too - I just installed r13831-52cdd6185e on my rg21s and it's working for me as well.

@openwrt-bot
Copy link
Author

camel:

seems to be - more devices are having the same problems ... eg: zbt3526 also hanging in boot loop - since months now !

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

1 participant