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
Comments
UAb5eSMn: I don't understand why it's closed as not a bug? |
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. |
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:
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:
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 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
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". |
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. |
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. |
UAb5eSMn: Good that it works for you too. |
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. |
falaca: No problem, and thanks to you too - I just installed r13831-52cdd6185e on my rg21s and it's working for me as well. |
camel: seems to be - more devices are having the same problems ... eg: zbt3526 also hanging in boot loop - since months now ! |
UAb5eSMn:
Boot fails on snapshot images 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
===================================================================
==================================================================
....
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
IMAGE_SIZE := 16064k
DEVICE_VENDOR := Edimax
DEVICE_MODEL := RA21S
@@ -262,6 +263,7 @@ endef
TARGET_DEVICES += edimax_ra21s
define Device/edimax_rg21s
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
The text was updated successfully, but these errors were encountered: