| Message ID | 20200414064438.1172618-1-gch981213@gmail.com |
|---|---|
| State | Rejected |
| Delegated to: | Chuanhong Guo |
| Headers | show |
| Series | [OpenWrt-Devel,RFT] ramips: mt7621: use lzma-loader for all devices | expand |
Hi, be aware that LZMA_TEXT_START=0x82000000, so this won't work on any 32 MB RAM devices if I calculated right. This of course won't be a problem for mt7621, but if the same strategy is applied to other subtargets, LZMA_TEXT_START might be lowered then. So, maybe it would make sense to lower that right away before testing if that applies. (One obviously could also have subtarget-dependent values for that or just disable all 32 MB devices as well...) On ath79, for example, this value was chosen differently to work on 32 MB RAM devices as well. Best Adrian > -----Original Message----- > From: openwrt-devel [mailto:openwrt-devel-bounces@lists.openwrt.org] > On Behalf Of Chuanhong Guo > Sent: Dienstag, 14. April 2020 08:45 > To: openwrt-devel@lists.openwrt.org > Cc: Chuanhong Guo <gch981213@gmail.com> > Subject: [OpenWrt-Devel] [PATCH RFT] ramips: mt7621: use lzma-loader for > all devices > > With current kernel reaching 5MB uncompressed, several devices failed to > boot. They either fails on lzma decompression or ends up with a corrupted > kernel image. We already faced this problem two years ago and it was solved > by limiting LZMA dictionary size. Our own lzma-loader extracts data without > this limit just fine and lifting this limit saves 15KB kernel space when > compressed. > mediatek u-boot 1.1.3 comes with support for uncompressed uimage by > default and ideally no vendor bother to remove this support. > This commit uses uncompressed uimage with lzma-loader for all mt7621 > devices with default kernel template. > > Signed-off-by: Chuanhong Guo <gch981213@gmail.com> > --- > > D-Link DIR-860L B1 needs a different loader implementation and isn't > covered by this patch. > Please help testing this patch on top of current master: > 75f19deb3a ramips: define image recipe for uncompressed uimage with > loader 1. If your device fails to boot after 5.4 switch for mt7621: > Is the problem fixed by this patch? > 2. Other devices: > Does this patch break your router? > > Thanks in advance! > > target/linux/ramips/image/Makefile | 4 ++++ > target/linux/ramips/image/mt7621.mk | 1 - > 2 files changed, 4 insertions(+), 1 deletion(-) > > diff --git a/target/linux/ramips/image/Makefile > b/target/linux/ramips/image/Makefile > index a966ba4349..1fb37d7c6c 100644 > --- a/target/linux/ramips/image/Makefile > +++ b/target/linux/ramips/image/Makefile > @@ -27,7 +27,11 @@ LOADER_PLATFORM := $(ldrplatform-y) KERNEL_DTB = > kernel-bin | append-dtb | lzma define Device/Default > PROFILES = Default > +ifeq ($(SUBTARGET),mt7621) > + $(Device/uimage-lzma-loader) > +else > KERNEL := $(KERNEL_DTB) | uImage lzma > +endif > SOC := $(DEFAULT_SOC) > DEVICE_DTS_DIR := ../dts > DEVICE_DTS = $$(SOC)_$(1) > diff --git a/target/linux/ramips/image/mt7621.mk > b/target/linux/ramips/image/mt7621.mk > index 8980ff70d4..942308c29a 100644 > --- a/target/linux/ramips/image/mt7621.mk > +++ b/target/linux/ramips/image/mt7621.mk > @@ -6,7 +6,6 @@ include ./common-tp-link.mk > > DEFAULT_SOC := mt7621 > > -KERNEL_DTB += -d21 > DEVICE_VARS += UIMAGE_MAGIC SERCOMM_HWNAME > > # The OEM webinterface expects an kernel with initramfs which has the > uImage > -- > 2.25.2 > > > _______________________________________________ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Hi! On Tue, Apr 14, 2020 at 5:27 PM <mail@adrianschmutzler.de> wrote: > be aware that LZMA_TEXT_START=0x82000000, so this won't work on any 32 MB RAM devices if I calculated right. Correct. But I assume there won't be enough memory for userspace programs if uncompressed kernel reaches 5MB. > This of course won't be a problem for mt7621, but if the same strategy is applied to other subtargets, LZMA_TEXT_START might be lowered then. > So, maybe it would make sense to lower that right away before testing if that applies. (One obviously could also have subtarget-dependent values for that or just disable all 32 MB devices as well...) On ath79, for example, this value was chosen differently to work on 32 MB RAM devices as well. lzma-loader can be executed from anywhere in memory. After being executed, the first thing it does is copying itself to defined LZMA_TEXT_START. We don't really need to test a change of LZMA_TEXT_START on every boards as its our own code doing the same thing. So I'd like to leave this untouched and change it later if needed.
Hi, > -----Original Message----- > From: Chuanhong Guo [mailto:gch981213@gmail.com] > Sent: Dienstag, 14. April 2020 12:20 > To: Adrian Schmutzler <mail@adrianschmutzler.de> > Cc: OpenWrt Development List <openwrt-devel@lists.openwrt.org> > Subject: Re: [OpenWrt-Devel] [PATCH RFT] ramips: mt7621: use lzma-loader > for all devices > > Hi! > > On Tue, Apr 14, 2020 at 5:27 PM <mail@adrianschmutzler.de> wrote: > > be aware that LZMA_TEXT_START=0x82000000, so this won't work on any > 32 MB RAM devices if I calculated right. > > Correct. But I assume there won't be enough memory for userspace > programs if uncompressed kernel reaches 5MB. > > > This of course won't be a problem for mt7621, but if the same strategy is > applied to other subtargets, LZMA_TEXT_START might be lowered then. > > So, maybe it would make sense to lower that right away before testing if > that applies. (One obviously could also have subtarget-dependent values for > that or just disable all 32 MB devices as well...) On ath79, for example, this > value was chosen differently to work on 32 MB RAM devices as well. > > lzma-loader can be executed from anywhere in memory. After being > executed, the first thing it does is copying itself to defined > LZMA_TEXT_START. We don't really need to test a change of > LZMA_TEXT_START on every boards as its our own code doing the same > thing. So I'd like to leave this untouched and change it later if needed. That's not what I'm aiming at, but in ath79 we had the problem that the uncompressed part became too big and was overwriting the lzma-loader: https://github.com/openwrt/openwrt/commit/071a6372762d289b2fa5a8d1a138eff944c93c9e If we move LZMA_TEXT_START closer to the start, that might be an issue in ramips as well (though, only theoretically). That's what I meant with testing. I didn't want to stop you, though, I just wanted to make you aware of the situation. Most probably it won't matter at the end. Best Adrian > > -- > Regards, > Chuanhong Guo
Hello, I tried this change in several routers. In the following routers, kernel 5.4 without/with your patch works fine: - Buffalo WSR-1166DHP U-Boot 1.1.3 (Dec 16 2014 - 14:38:30) 0.09, Ralink UBoot Version: 4.2.1.0 - ELECOM WRC-1167GHBK2-S U-Boot 1.1.3 (Jan 23 2017 - 20:06:24), Ralink UBoot Version: 5.0.0.0 - I-O DATA WN-GX300GR U-boot Ver:1.0.4.11 2017/08/31 09:55:19, Senao Uboot Init Ver.1.0.0 But in I-O DATA WN-AX1167GR2, failed to start lzma-loader and hangs up: =================================================================== MT7621 stage1 code 10:33:11 (ASIC) CPU=50000000 HZ BUS=16666666 HZ ================================================================== Change MPLL source from XTAL to CR... do MEMPLL setting.. MEMPLL Config : 0x11100000 3PLL mode + External loopback === XTAL-40Mhz === DDR-1200Mhz === PLL3 FB_DL: 0x4, 1/0 = 544/480 11000000 PLL4 FB_DL: 0x7, 1/0 = 609/415 1D000000 PLL2 FB_DL: 0x19, 1/0 = 568/456 65000000 do DDR setting..[00320381] Apply DDR3 Setting...(use customer AC) 0 8 16 24 32 40 48 56 64 72 80 88 96 104 112 120 -------------------------------------------------------------------------------- 0000:| 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0001:| 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0002:| 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0003:| 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0004:| 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0005:| 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0006:| 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0007:| 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0008:| 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0009:| 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 000A:| 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 000B:| 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 000C:| 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 000D:| 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 000E:| 0 0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 000F:| 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 0010:| 1 1 1 1 1 1 1 1 1 1 1 0 0 0 0 0 0011:| 1 1 1 1 1 0 0 0 0 0 0 0 0 0 0 0 0012:| 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0013:| 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0014:| 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0015:| 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0016:| 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0017:| 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0018:| 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0019:| 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 001A:| 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 001B:| 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 001C:| 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 001D:| 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 001E:| 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 001F:| 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 rank 0 coarse = 16 rank 0 fine = 40 B:| 0 0 0 0 0 0 0 0 0 1 1 1 0 0 0 0 opt_dle value:10 DRAMC_R0DELDLY[018]=00002121 ================================================================== RX DQS perbit delay software calibration ================================================================== 1.0-15 bit dq delay value ================================================================== bit| 0 1 2 3 4 5 6 7 8 9 -------------------------------------- 0 | 10 9 8 10 6 7 8 6 7 6 10 | 9 8 9 9 7 9 -------------------------------------- ================================================================== 2.dqs window x=pass dqs delay value (min~max)center y=0-7bit DQ of every group input delay:DQS0 =33 DQS1 = 33 ================================================================== bit DQS0 bit DQS1 0 (1~65)33 8 (1~63)32 1 (1~66)33 9 (1~63)32 2 (0~62)31 10 (1~63)32 3 (1~66)33 11 (1~62)31 4 (1~63)32 12 (1~63)32 5 (1~66)33 13 (0~62)31 6 (1~63)32 14 (1~65)33 7 (1~66)33 15 (1~65)33 ================================================================== 3.dq delay value last ================================================================== bit| 0 1 2 3 4 5 6 7 8 9 -------------------------------------- 0 | 10 9 10 10 7 7 9 6 8 7 10 | 10 10 10 11 7 9 ================================================================== ================================================================== TX perbyte calibration ================================================================== DQS loop = 15, cmp_err_1 = ffff0000 dqs_perbyte_dly.last_dqsdly_pass[0]=15, finish count=1 dqs_perbyte_dly.last_dqsdly_pass[1]=15, finish count=2 DQ loop=15, cmp_err_1 = ffff0082 dqs_perbyte_dly.last_dqdly_pass[1]=15, finish count=1 DQ loop=14, cmp_err_1 = ffff0000 dqs_perbyte_dly.last_dqdly_pass[0]=14, finish count=2 byte:0, (DQS,DQ)=(8,8) byte:1, (DQS,DQ)=(8,8) 20,data:88 [EMI] DRAMC calibration passed =================================================================== MT7621 stage1 code done CPU=50000000 HZ BUS=16666666 HZ =================================================================== U-Boot 1.1.3 (Dec 9 2016 - 10:20:35) Board: Ralink APSoC DRAM: 128 MB relocate_code Pointer at: 87fac000 Config XHCI 40M PLL ****************************** Software System Reset Occurred ****************************** Allocate 16 byte aligned buffer: 87fdf010 Enable NFI Clock # MTK NAND # : Use HW ECC NAND ID [01 F1 80 1D 01] Device found in MTK table, ID: 1f1, EXT_ID: 801d01 Support this Device in MTK table! 1f1 select_chip [NAND]select ecc bit:4, sparesize :64 spare_per_sector=16 Signature matched and data read! load_fact_bbt success 1023 load fact bbt success [mtk_nand] probe successfully! mtd->writesize=2048 mtd->oobsize=64, mtd->erasesize=131072 devinfo.iowidth=8 ....============================================ Ralink UBoot Version: 5.0.0.0 -------------------------------------------- ASIC MT7621A DualCore (MAC to MT7530 Mode) DRAM_CONF_FROM: Auto-Detection DRAM_TYPE: DDR3 DRAM bus: 16 bit Xtal Mode=3 OCP Ratio=1/3 Flash component: NAND Flash Date:Dec 9 2016 Time:10:20:35 ============================================ icache: sets:256, ways:4, linesz:32 ,total:32768 dcache: sets:256, ways:4, linesz:32 ,total:32768 ##### The CPU freq = 880 MHZ #### estimate memory size =128 Mbytes #Reset_MT7530 set LAN/WAN WLLLL .## Starting application at 0x81E00000 ... Z-LOADER V1.24 | 12/09/2016 10:20:37 ..Hit ESC key to stop autoboot: 1 Checking image 1... Image Name: MIPS OpenWrt Linux-5.4.3 Image Type: MIPS Linux Kernel Image (uncompressed) Data Size: 2317045 Bytes = 2.2 MB Load Address: 80001000 Entry Point: 80001000 .................................... Verifying Checksum ... ## Booting image at bc400000 ... OK No initrd ## Transferring control to Linux (at address 80001000) ... ## Giving linux memsize in MB, 128 Starting kernel ... (hang up) This model uses "Z-LOADER" to boot kernel.The same loader is also used in following I-O DATA devices: - WN-AX2033GR - WN-DX1167R Regards, Hiroshi On 2020/04/14 15:44, Chuanhong Guo wrote: > With current kernel reaching 5MB uncompressed, several devices failed > to boot. They either fails on lzma decompression or ends up with a > corrupted kernel image. We already faced this problem two years ago > and it was solved by limiting LZMA dictionary size. Our own lzma-loader > extracts data without this limit just fine and lifting this limit saves > 15KB kernel space when compressed. > mediatek u-boot 1.1.3 comes with support for uncompressed uimage by > default and ideally no vendor bother to remove this support. > This commit uses uncompressed uimage with lzma-loader for all mt7621 > devices with default kernel template. > > Signed-off-by: Chuanhong Guo <gch981213@gmail.com> > --- > > D-Link DIR-860L B1 needs a different loader implementation and isn't > covered by this patch. > Please help testing this patch on top of current master: > 75f19deb3a ramips: define image recipe for uncompressed uimage with loader > 1. If your device fails to boot after 5.4 switch for mt7621: > Is the problem fixed by this patch? > 2. Other devices: > Does this patch break your router? > > Thanks in advance! > > target/linux/ramips/image/Makefile | 4 ++++ > target/linux/ramips/image/mt7621.mk | 1 - > 2 files changed, 4 insertions(+), 1 deletion(-) > > diff --git a/target/linux/ramips/image/Makefile b/target/linux/ramips/image/Makefile > index a966ba4349..1fb37d7c6c 100644 > --- a/target/linux/ramips/image/Makefile > +++ b/target/linux/ramips/image/Makefile > @@ -27,7 +27,11 @@ LOADER_PLATFORM := $(ldrplatform-y) > KERNEL_DTB = kernel-bin | append-dtb | lzma > define Device/Default > PROFILES = Default > +ifeq ($(SUBTARGET),mt7621) > + $(Device/uimage-lzma-loader) > +else > KERNEL := $(KERNEL_DTB) | uImage lzma > +endif > SOC := $(DEFAULT_SOC) > DEVICE_DTS_DIR := ../dts > DEVICE_DTS = $$(SOC)_$(1) > diff --git a/target/linux/ramips/image/mt7621.mk b/target/linux/ramips/image/mt7621.mk > index 8980ff70d4..942308c29a 100644 > --- a/target/linux/ramips/image/mt7621.mk > +++ b/target/linux/ramips/image/mt7621.mk > @@ -6,7 +6,6 @@ include ./common-tp-link.mk > > DEFAULT_SOC := mt7621 > > -KERNEL_DTB += -d21 > DEVICE_VARS += UIMAGE_MAGIC SERCOMM_HWNAME > > # The OEM webinterface expects an kernel with initramfs which has the uImage
Hi Guo, On 4/14/20 8:44 AM, Chuanhong Guo wrote: > D-Link DIR-860L B1 needs a different loader implementation and isn't > covered by this patch. > Please help testing this patch on top of current master: > 75f19deb3a ramips: define image recipe for uncompressed uimage with loader > 1. If your device fails to boot after 5.4 switch for mt7621: > Is the problem fixed by this patch? As promised on IRC, i've tested this patch with a R6220 and can confirm it fixes the issue. > 2. Other devices: > Does this patch break your router? Regarding the scope of the patch, i would propose to "play it safe" and only apply the fix to NAND and the (single?) known broken SPI-NOR boards. Sadly I was too late to the party when the discussion was going on via IRC. Best wishes David
Hi! On Wed, Apr 15, 2020 at 2:23 AM INAGAKI Hiroshi <musashino.open@gmail.com> wrote: > > Hello, > > I tried this change in several routers. > > In the following routers, kernel 5.4 without/with your patch works fine: > > - Buffalo WSR-1166DHP > U-Boot 1.1.3 (Dec 16 2014 - 14:38:30) 0.09, Ralink UBoot Version: > 4.2.1.0 > - ELECOM WRC-1167GHBK2-S > U-Boot 1.1.3 (Jan 23 2017 - 20:06:24), Ralink UBoot Version: 5.0.0.0 > - I-O DATA WN-GX300GR > U-boot Ver:1.0.4.11 2017/08/31 09:55:19, Senao Uboot Init Ver.1.0.0 > > But in I-O DATA WN-AX1167GR2, failed to start lzma-loader and hangs up: Oops. I can't debug further on this issue so I'll abandon this patch and use it only for devices affected by the kernel bump. Thanks for testing!
Hi! On Wed, Apr 15, 2020 at 5:47 AM David Bauer <mail@david-bauer.net> wrote: > > Hi Guo, > > On 4/14/20 8:44 AM, Chuanhong Guo wrote: > > D-Link DIR-860L B1 needs a different loader implementation and isn't > > covered by this patch. > > Please help testing this patch on top of current master: > > 75f19deb3a ramips: define image recipe for uncompressed uimage with loader > > 1. If your device fails to boot after 5.4 switch for mt7621: > > Is the problem fixed by this patch? > > As promised on IRC, i've tested this patch with a R6220 and can confirm it fixes the issue. > > > 2. Other devices: > > Does this patch break your router? > > Regarding the scope of the patch, i would propose to "play it safe" and only > apply the fix to NAND and the (single?) known broken SPI-NOR boards. Agree. I wasn't expecting anything to break but it actually breaks devices now. I'll abandon this patch and use lzma loader for known affected devices instead. Thanks for testing!
diff --git a/target/linux/ramips/image/Makefile b/target/linux/ramips/image/Makefile index a966ba4349..1fb37d7c6c 100644 --- a/target/linux/ramips/image/Makefile +++ b/target/linux/ramips/image/Makefile @@ -27,7 +27,11 @@ LOADER_PLATFORM := $(ldrplatform-y) KERNEL_DTB = kernel-bin | append-dtb | lzma define Device/Default PROFILES = Default +ifeq ($(SUBTARGET),mt7621) + $(Device/uimage-lzma-loader) +else KERNEL := $(KERNEL_DTB) | uImage lzma +endif SOC := $(DEFAULT_SOC) DEVICE_DTS_DIR := ../dts DEVICE_DTS = $$(SOC)_$(1) diff --git a/target/linux/ramips/image/mt7621.mk b/target/linux/ramips/image/mt7621.mk index 8980ff70d4..942308c29a 100644 --- a/target/linux/ramips/image/mt7621.mk +++ b/target/linux/ramips/image/mt7621.mk @@ -6,7 +6,6 @@ include ./common-tp-link.mk DEFAULT_SOC := mt7621 -KERNEL_DTB += -d21 DEVICE_VARS += UIMAGE_MAGIC SERCOMM_HWNAME # The OEM webinterface expects an kernel with initramfs which has the uImage
With current kernel reaching 5MB uncompressed, several devices failed to boot. They either fails on lzma decompression or ends up with a corrupted kernel image. We already faced this problem two years ago and it was solved by limiting LZMA dictionary size. Our own lzma-loader extracts data without this limit just fine and lifting this limit saves 15KB kernel space when compressed. mediatek u-boot 1.1.3 comes with support for uncompressed uimage by default and ideally no vendor bother to remove this support. This commit uses uncompressed uimage with lzma-loader for all mt7621 devices with default kernel template. Signed-off-by: Chuanhong Guo <gch981213@gmail.com> --- D-Link DIR-860L B1 needs a different loader implementation and isn't covered by this patch. Please help testing this patch on top of current master: 75f19deb3a ramips: define image recipe for uncompressed uimage with loader 1. If your device fails to boot after 5.4 switch for mt7621: Is the problem fixed by this patch? 2. Other devices: Does this patch break your router? Thanks in advance! target/linux/ramips/image/Makefile | 4 ++++ target/linux/ramips/image/mt7621.mk | 1 - 2 files changed, 4 insertions(+), 1 deletion(-)