Re: next OpenWrt 22.03 and 21.02 minor release
Hi Hauke,
May I have a little offtopic question about backporting?
I opened a pull request ("comgt: support Mikrotik R11e-LTE6 modem", [1])
where I move a file dependency from "comgt-ncm" to "comgt".
Are such a change allowed to be backported?
[1]: https://github.com/openwrt/openwrt/pull/12261
Thanks,
Szabolcs
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: OpenWrt 21.02.4 and OpenWrt 22.03.1 release planning
Hi Hauke, There is another LZMA ERROR 1 issue [0] for a ramips/rt3883 device. I have sent a fix for that to GitHub as PR#10834 [1]. It's not on the master, as it is not reviewed yet. The problem is that this device is a SEAMA device, and it got the "$(Device/uimage-lzma-loader)" fix already, exactly for this LZMA ERROR 1 in the 21.02 times. [2] Due to this, my fix is not just a oneliner, but it contains a new recipe to avoid future recipe misunderstandings. Should I resend the series to ML and close my pull request? [0]: https://github.com/openwrt/openwrt/issues/10634 [1]: https://github.com/openwrt/openwrt/pull/10834 [2]: https://git.openwrt.org/09faa73c53bd097666cbbe68176dd46cfcf80ee8 -- Thanks, Szabolcs ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH 21.02] ramips: mt7621: do memory detection on KSEG1
From: Chuanhong Guo
It's reported that current memory detection code occasionally detects
larger memory under some bootloaders.
Current memory detection code tests whether address space wraps around
on KSEG0, which is unreliable because it's cached.
Rewrite memory size detection to perform the same test on KSEG1 instead.
While at it, this patch also does the following two things:
1. use a fixed pattern instead of a random function pointer as the magic
value.
2. add an additional memory write and a second comparison as part of the
test to prevent possible smaller memory detection result due to
leftover values in memory.
Fixes: 6d91ddf517 ("ramips: mt7621: add support for memory detection")
Reported-by: Rui Salvaterra
Tested-by: Rui Salvaterra
Signed-off-by: Chuanhong Guo
(cherry picked from commit 2f024b79331141e2a62c9bf3601c803b26bde77b)
[backport for OpenWrt 21.02 as it was reproducible with Kernel 5.4, see [1]]
[1]: https://forum.openwrt.org/t/113081
Tested-by: Dimitri Souza [mt7621/archer-c6-v3]
Signed-off-by: Szabolcs Hubai
---
.../325-mt7621-fix-memory-detect.patch| 62 +++
1 file changed, 62 insertions(+)
create mode 100644
target/linux/ramips/patches-5.4/325-mt7621-fix-memory-detect.patch
diff --git a/target/linux/ramips/patches-5.4/325-mt7621-fix-memory-detect.patch
b/target/linux/ramips/patches-5.4/325-mt7621-fix-memory-detect.patch
new file mode 100644
index 00..f8616c31fc
--- /dev/null
+++ b/target/linux/ramips/patches-5.4/325-mt7621-fix-memory-detect.patch
@@ -0,0 +1,62 @@
+--- a/arch/mips/ralink/mt7621.c
b/arch/mips/ralink/mt7621.c
+@@ -58,7 +58,9 @@
+ #define MT7621_GPIO_MODE_SDHCI_SHIFT 18
+ #define MT7621_GPIO_MODE_SDHCI_GPIO 1
+
+-static void *detect_magic __initdata = detect_memory_region;
++#define MT7621_MEM_TEST_PATTERN 0xaaaa
++
++static u32 detect_magic __initdata;
+
+ static struct rt2880_pmx_func uart1_grp[] = { FUNC("uart1", 0, 1, 2) };
+ static struct rt2880_pmx_func i2c_grp[] = { FUNC("i2c", 0, 3, 2) };
+@@ -144,26 +146,34 @@ static struct clk *__init mt7621_add_sys
+ return clk;
+ }
+
++static bool __init mt7621_addr_wraparound_test(phys_addr_t size)
++{
++ void *dm = (void *)KSEG1ADDR(_magic);
++ if (CPHYSADDR(dm + size) >= MT7621_LOWMEM_MAX_SIZE)
++ return true;
++ __raw_writel(MT7621_MEM_TEST_PATTERN, dm);
++ if (__raw_readl(dm) != __raw_readl(dm + size))
++ return false;
++ __raw_writel(!MT7621_MEM_TEST_PATTERN, dm);
++ return __raw_readl(dm) == __raw_readl(dm + size);
++}
++
+ void __init mt7621_memory_detect(void)
+ {
+- void *dm = _magic;
+ phys_addr_t size;
+
+- for (size = 32 * SZ_1M; size < 256 * SZ_1M; size <<= 1) {
+- if (!__builtin_memcmp(dm, dm + size, sizeof(detect_magic)))
+- break;
++ for (size = 32 * SZ_1M; size <= 256 * SZ_1M; size <<= 1) {
++ if (mt7621_addr_wraparound_test(size)) {
++ add_memory_region(MT7621_LOWMEM_BASE, size,
BOOT_MEM_RAM);
++ return;
++ }
+ }
+
+- if ((size == 256 * SZ_1M) &&
+- (CPHYSADDR(dm + size) < MT7621_LOWMEM_MAX_SIZE) &&
+- __builtin_memcmp(dm, dm + size, sizeof(detect_magic))) {
+- add_memory_region(MT7621_LOWMEM_BASE, MT7621_LOWMEM_MAX_SIZE,
+-BOOT_MEM_RAM);
+- add_memory_region(MT7621_HIGHMEM_BASE, MT7621_HIGHMEM_SIZE,
+-BOOT_MEM_RAM);
+- } else {
+- add_memory_region(MT7621_LOWMEM_BASE, size, BOOT_MEM_RAM);
+- }
++ /* addr doesn't wrap around at dm + 256M, assume 512M memory. */
++ add_memory_region(MT7621_LOWMEM_BASE, MT7621_LOWMEM_MAX_SIZE,
++BOOT_MEM_RAM);
++ add_memory_region(MT7621_HIGHMEM_BASE, MT7621_HIGHMEM_SIZE,
++BOOT_MEM_RAM);
+ }
+
+ void __init ralink_clk_init(void)
--
2.25.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] ipq40xx: add support for GL.iNet GL-B2200
Enrico Mioso ezt írta (időpont: 2021. okt. 10., V, 19:37): > > Hello Li, > Hello Adrian, > Hello Szabolcs, > and all!! > > First of all, what's the state of this patch? Is it mergeable as-is, or are > further changes required? > > Secondly, does this device require the use of zImage or will the u-boot > happily load larger kernels? > See commit 81d694e30b4926fea057bd3e46d996a8f098b95a authored by Szabolcs. > > Thanks a lot! > > Enrico > > > On Mon, 13 Sep 2021, Li Zhang wrote: > > > Date: Mon, 13 Sep 2021 10:02:00 > > From: Li Zhang > > To: openwrt-devel@lists.openwrt.org > > Cc: Li Zhang > > Subject: [PATCH] ipq40xx: add support for GL.iNet GL-B2200 > > > > This patch adds supports for GL-B2200. > > > > Specifications: > > - SOC: Qualcomm IPQ4019 ARM Quad-Core > > - RAM: 512 MiB > > - Flash: 16 MiB NOR - SPI0 > > - EMMC: 8GB EMMC > > - ETH: Qualcomm QCA8075 > > - WLAN1: Qualcomm Atheros QCA4019 2.4GHz 802.11b/g/n 2x2 > > - WLAN2: Qualcomm Atheros QCA4019 5GHz 802.11n/ac W2 2x2 > > - WLAN3: Qualcomm Atheros QCA9886 5GHz 802.11n/ac W2 2x2 > > - INPUT: Reset, WPS > > - LED: Power, Internet > > - UART1: On board pin header near to LED (3.3V, TX, RX, GND), 3.3V > > without pin - 115200 8N1 > > - UART2: On board with BLE module > > - SPI1: On board socket for Zigbee module > > > > Update firmware instructions > > > > Pleae update firmware on uboot web(default 192.168.1.1). > > > > Signed-off-by: Li Zhang > > --- > > package/firmware/ipq-wifi/Makefile | 2 + > > .../ipq-wifi/board-glinet_gl-b2200.qca4019 | Bin 0 -> 24308 bytes > > .../ipq-wifi/board-glinet_gl-b2200.qca9888 | Bin 0 -> 12200 bytes > > target/linux/ipq40xx/Makefile | 2 +- > > .../ipq40xx/base-files/etc/board.d/02_network | 5 + > > .../etc/hotplug.d/firmware/11-ath10k-caldata | 3 + > > .../arch/arm/boot/dts/qcom-ipq4019-gl-b2200.dts| 364 > > + > > target/linux/ipq40xx/image/generic.mk | 27 ++ > > .../patches-5.4/901-arm-boot-add-dts-files.patch | 3 +- > > 9 files changed, 404 insertions(+), 2 deletions(-) > > create mode 100644 package/firmware/ipq-wifi/board-glinet_gl-b2200.qca4019 > > create mode 100644 package/firmware/ipq-wifi/board-glinet_gl-b2200.qca9888 > > create mode 100644 > > target/linux/ipq40xx/files/arch/arm/boot/dts/qcom-ipq4019-gl-b2200.dts > > > > > > diff --git a/target/linux/ipq40xx/image/generic.mk > > b/target/linux/ipq40xx/image/generic.mk > > index 18f5d23..b0d6cf5 100644 > > --- a/target/linux/ipq40xx/image/generic.mk > > +++ b/target/linux/ipq40xx/image/generic.mk > > @@ -81,6 +81,17 @@ define Build/qsdk-ipq-factory-nand-askey > > @mv $@.new $@ > > endef > > > > +define Build/qsdk-ipq-app-gpt > > + cp $@ $@.tmp 2>/dev/null || true > > + ptgen -g -o $@.tmp -a 1 -l 1024 \ > > + -t 0x2e -N 0:HLOS -r -p 32M \ > > + -t 0x83 -N rootfs -r -p 128M \ > > + -N rootfs_data -p 512M \ > > + -N user_data -p 6766M > > + cat $@.tmp >> $@ > > + rm $@.tmp > > +endef > > + > > define Build/SenaoFW > > -$(STAGING_DIR_HOST)/bin/mksenaofw \ > > -n $(BOARD_NAME) -r $(VENDOR_ID) -p $(1) \ > > @@ -506,6 +517,22 @@ define Device/glinet_gl-b1300 > > endef > > TARGET_DEVICES += glinet_gl-b1300 > > > > +define Device/glinet_gl-b2200 > > + $(call Device/FitImage) > > + DEVICE_VENDOR := GL.iNet > > + DEVICE_MODEL := GL-B2200 > > + SOC := qcom-ipq4019 > > + DEVICE_DTS_CONFIG := config@ap.dk04.1-c3 > > + KERNEL_INITRAMFS_SUFFIX := -recovery.itb > > + IMAGES := sdcard.img.gz > > + IMAGE/sdcard.img.gz := qsdk-ipq-app-gpt |\ > > + pad-to 1024k | append-kernel |\ > > + pad-to 33792k | append-rootfs |\ > > + append-metadata | gzip > > + DEVICE_PACKAGES := ipq-wifi-glinet_gl-b2200 kmod-fs-ext4 kmod-mmc > > kmod-spi-dev mkf2fs e2fsprogs kmod-fs-f2fs > > +endef > > +TARGET_DEVICES += glinet_gl-b2200 > > + > > define Device/glinet_gl-s1300 > > $(call Device/FitImage) > > DEVICE_VENDOR := GL.iNet > > > > -- > > 2.7.4 > > > > > > > > Hi Enrico, In the device recipe "Device/glinet_gl-b2200" there is no "KERNEL_SIZE", like in the other GL.Inet device recipe "Device/glinet_gl-ap1300" which is already in tree. While they use the same U-Boot binary [0], I hope these two devices are able to load 4MB kernels already. In the meantime Dongming answered my question on GL.Inet forums [1]: > Thanks for that solution. It’s possible to load >4MB kernel after patching > uboot [0]. I’ll do some test. [0]: https://github.com/gl-inet/uboot-ipq40xx [1]: https://forum.gl-inet.com/t/ipq40xx-kernel-size-and-u-boot-v5-10-is-too-big-for-4-mb/17619/4 Szabolcs
Re: OpenWrt 21.02-rc1
On Tue, Apr 6, 2021 at 3:43 PM Hauke Mehrtens wrote: > > [snip] > > If there are some other bugs in the 21.02 branch which are fixed in > master, we can backport the fixed as long as they are not so big. If > there is something missing, just ask on the mainling list. > Hi! I have a oneliner fix for ZyXEL Keenetic Lite rev.B on the GitHub. [0] It would be an average LZMA ERROR 1 fix in the ramips target, but the device's support commit landed on 8 Jul 2020. [1] 21.02 would be it's first release, but it's already unusable due to the LZMA ERROR 1. Please land the fix on master and backport it to the 21.02 release! Thank you, Szabolcs [0]: https://github.com/openwrt/openwrt/pull/3834 [1]: https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=4dc9ad4af8c921494d20b303b6772fc6b5af3a69 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] ramips: disable default build for HooToo HT-TM02
While the latest version of 19.07 release is usable, the current master is unbootable on the device in a normal way. "Normal way" installations includes: - sysupgrade (e.g. from 19.07) - RESET button recovery with Ron Curry's (Wingspinner) UBoot image (10.10.10.3 + "Kernal.bin") - RESET button recovery with original U-Boot (10.10.10.254 + "kernel") One could flash and boot the latest master sysupgrade image successfully with serial access to the device. But a sysupgrade from this state still breaks the U-Boot and soft-bricks the device. Signed-off-by: Szabolcs Hubai --- target/linux/ramips/image/rt305x.mk | 1 + 1 file changed, 1 insertion(+) diff --git a/target/linux/ramips/image/rt305x.mk b/target/linux/ramips/image/rt305x.mk index 7d145c3992..2188aaa268 100644 --- a/target/linux/ramips/image/rt305x.mk +++ b/target/linux/ramips/image/rt305x.mk @@ -602,6 +602,7 @@ define Device/hootoo_ht-tm02 DEVICE_MODEL := HT-TM02 DEVICE_PACKAGES := kmod-usb-ohci kmod-usb2 kmod-usb-ledtrig-usbport SUPPORTED_DEVICES += ht-tm02 + DEFAULT := n endef TARGET_DEVICES += hootoo_ht-tm02 -- 2.17.1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Preparing commit description for "ramips: disable default build for HooToo HT-TM02"
Hi, On 12/14/20 5:32 PM, Adrian Schmutzler wrote: > Sorry, I don't understand what this is about. > > Do you want to disable that device by default? Then just put DEFAULT := n > into the device definition. > > Do you want to improve the support? Then you might need to rephrase the > "question". > > Best > > Adrian > >> -Original Message- >> From: Szabolcs Hubai [mailto:szab...@gmail.com] >> Sent: Dienstag, 8. Dezember 2020 01:37 >> To: openwrt-devel@lists.openwrt.org >> Cc: Russell Morris ; Adrian Schmutzler >> ; David Bauer >> Subject: Re: Preparing commit description for "ramips: disable default build >> for HooToo HT-TM02" >> Thank you Adrian for replying to my confusing mail. Yes, I would like to introduce that 'DEFAULT := n' line in the device definition. As you wrote already, the change is easy, it's a oneliner. I have problems with the commit description, as I can't write simply "This device has a 1.5M kernel size limit during boot and is unbootable since x.", like RP-WD02 disabling commit. [0] I can't write, because it's not true: as I wrote in my previous mail, one could flash and boot successfully the latest version of master through serial. Maybe I should try my luck and send this disabling patch. On the long run, I would like improve support, but it won't be as straightforward as it was in mt7620. But that's for another thread. [0]: https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=2dda301d40ec0937f4de1bcec307bbc8adb66958 -- Szabolcs ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Preparing commit description for "ramips: disable default build for HooToo HT-TM02"
On 12/8/20 12:08 AM, Szabolcs Hubai wrote:
> Hi,
>
>
> I planned to refresh the support of a rt305x SunValley Filehub device:
> HooToo HT-TM02.
>
> I wanted to follow Adrian's and Russel's work for HooToo HT-TM05 and
> RAVPower RP-WD03 in mt7620 [0].
>
>
> I toought disabling the image generation would be easy,
> as binwalk showed an oversized kernel: "image size: 1624829 bytes",
> so it won't boot anyway.
>
> DECIMAL HEXADECIMAL DESCRIPTION
>
> 0 0x0 uImage header, header size: 64 bytes,
> header CRC: 0xCB63E9C7, created: 2020-12-06 08:18:07, image size:
> 1624829 bytes, Data Address: 0x8000, Entry Point: 0x8000, data
> CRC: 0x10379393, OS: Linux, CPU: MIPS, image type: OS Kernel Image,
> compression type: lzma, image name: "MIPS OpenWrt Linux-5.4.81"
> 640x40LZMA compressed data, properties: 0x6D,
> dictionary size: 8388608 bytes, uncompressed size: 5182719 bytes
> 5493110x861BF Cisco IOS microcode, for ""
>
>
> But I was unable to verify this because of the following:
> - wingspinner's uboot [1],[2],[3] reads successfully the whole kernel,
> but throws "LZMA ERROR 1 - must RESET board to recover" - which is maybe
> fixable by $(Device/uimage-lzma-loader)
> - original u-boot loads and boots nicely the oversized kernel
To be correct:
- original u-boot is able to boot the oversized kernel only when it was
flashed through serial access ("IOVST MAIN MENU" -> "U SPIFlash Upgrade")
- original u-boot throws "Bad Data CRC" when the oversized kernel is
flashed through reset button TFTP recovery (10.10.10.254 + "kernel").
Cheers,
Szabolcs
>
>
> And all compatible rt305x devices (HT-TM02, HT-TM01, RP-WD02 and maybe
> RP-WD01) uses wingspinner's image, as it is installable through the OEM
> web interface. And it comes with he's custom uboot.
>
>
> What should I write in the commit description now?
>
>
> My plans on refreshing have bad times too as the OKLI Loader is unable
> to find the "OKLI" magic as the device doesn't map the flash to any
> memory address.
>
> While David ported official U-Boot to ramips target already with the
> RAVPower RP-WD009 support, I'm little bit afraid of my success
> porting it to rt305x as U-Boot doesn't have "rt5350.dtsi" to start with.
>
>
>
> May I ask for help not just for commit description but for creating
> a second stage loader for ramips/rt305x too?
>
>
>
> Thanks,
> Szabolcs
>
>
>
> [0]:
> https://git.openwrt.org/?p=openwrt/openwrt.git;a=log;h=c4110a524e9a026cf570b6dadf325c037b7527d0
> [1]: https://openwrt.org/toh/hootoo/tripmate-nano#supported_versions
> [2]: https://forum.archive.openwrt.org/viewtopic.php?id=53014
> [3]:
> https://github.com/wingspinner/HooToo-Tripmate-HT-TM02-OpenWRT/tree/master/uboot
>
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Preparing commit description for "ramips: disable default build for HooToo HT-TM02"
Hi, I planned to refresh the support of a rt305x SunValley Filehub device: HooToo HT-TM02. I wanted to follow Adrian's and Russel's work for HooToo HT-TM05 and RAVPower RP-WD03 in mt7620 [0]. I toought disabling the image generation would be easy, as binwalk showed an oversized kernel: "image size: 1624829 bytes", so it won't boot anyway. DECIMAL HEXADECIMAL DESCRIPTION 0 0x0 uImage header, header size: 64 bytes, header CRC: 0xCB63E9C7, created: 2020-12-06 08:18:07, image size: 1624829 bytes, Data Address: 0x8000, Entry Point: 0x8000, data CRC: 0x10379393, OS: Linux, CPU: MIPS, image type: OS Kernel Image, compression type: lzma, image name: "MIPS OpenWrt Linux-5.4.81" 640x40LZMA compressed data, properties: 0x6D, dictionary size: 8388608 bytes, uncompressed size: 5182719 bytes 5493110x861BF Cisco IOS microcode, for "" But I was unable to verify this because of the following: - wingspinner's uboot [1],[2],[3] reads successfully the whole kernel, but throws "LZMA ERROR 1 - must RESET board to recover" - which is maybe fixable by $(Device/uimage-lzma-loader) - original u-boot loads and boots nicely the oversized kernel And all compatible rt305x devices (HT-TM02, HT-TM01, RP-WD02 and maybe RP-WD01) uses wingspinner's image, as it is installable through the OEM web interface. And it comes with he's custom uboot. What should I write in the commit description now? My plans on refreshing have bad times too as the OKLI Loader is unable to find the "OKLI" magic as the device doesn't map the flash to any memory address. While David ported official U-Boot to ramips target already with the RAVPower RP-WD009 support, I'm little bit afraid of my success porting it to rt305x as U-Boot doesn't have "rt5350.dtsi" to start with. May I ask for help not just for commit description but for creating a second stage loader for ramips/rt305x too? Thanks, Szabolcs [0]: https://git.openwrt.org/?p=openwrt/openwrt.git;a=log;h=c4110a524e9a026cf570b6dadf325c037b7527d0 [1]: https://openwrt.org/toh/hootoo/tripmate-nano#supported_versions [2]: https://forum.archive.openwrt.org/viewtopic.php?id=53014 [3]: https://github.com/wingspinner/HooToo-Tripmate-HT-TM02-OpenWRT/tree/master/uboot ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [RFC, PATCH] ramips: mt7621: use OKLI lzma-loader for D-Link DIR-860L B1
In commit ce1957100411b0a751d6431d36def9c28048b4dc this device started using lzma-loader to enable booting bigger kernels from flash. Chuanhong Guo noted [0], if the kernel can be put at a fixed offset in flash, we could compress lzma loader separately and let u-boot decompress only the loader. This patch use this OKLI method for sysupgrade and factory images. [0] http://lists.infradead.org/pipermail/openwrt-devel/2020-April/022926.html Signed-off-by: Szabolcs Hubai --- target/linux/ramips/image/Makefile| 20 +++ .../ramips/image/lzma-loader/src/loader.c | 2 +- target/linux/ramips/image/mt7621.mk | 9 - 3 files changed, 29 insertions(+), 2 deletions(-) diff --git a/target/linux/ramips/image/Makefile b/target/linux/ramips/image/Makefile index f93ea8ab2a..76568d7c6c 100644 --- a/target/linux/ramips/image/Makefile +++ b/target/linux/ramips/image/Makefile @@ -88,6 +88,26 @@ define Build/loader-kernel $(call Build/loader-common,LOADER_DATA="$@") endef +define Build/loader-okli-compile + $(call Build/loader-common,FLASH_OFFS=$(LOADER_FLASH_OFFS) FLASH_MAX=0) +endef + +# Arguments: +define Build/loader-okli-with-type + dd if=$(KDIR)/loader-$(word 1,$(1)).$(word 3,$(1)) bs=$(word 2,$(1)) conv=sync of="$@.new" + cat "$@" >> "$@.new" + mv "$@.new" "$@" +endef + +# Arguments: +define Build/loader-okli + $(call Build/loader-okli-with-type,$(word 1,$(1)) $(word 2,$(1)) $(LOADER_TYPE)) +endef + +define Build/append-loader-okli + cat "$(KDIR)/loader-$(word 1,$(1)).$(LOADER_TYPE)" >> "$@" +endef + define Build/relocate-kernel rm -rf $@.relocate $(CP) ../../generic/image/relocate $@.relocate diff --git a/target/linux/ramips/image/lzma-loader/src/loader.c b/target/linux/ramips/image/lzma-loader/src/loader.c index c73b60b351..8b7756b931 100644 --- a/target/linux/ramips/image/lzma-loader/src/loader.c +++ b/target/linux/ramips/image/lzma-loader/src/loader.c @@ -28,7 +28,7 @@ #include "printf.h" #include "LzmaDecode.h" -#define AR71XX_FLASH_START 0x1f00 +#define AR71XX_FLASH_START 0x1000 #define AR71XX_FLASH_END 0x1fe0 #define KSEG0 0x8000 diff --git a/target/linux/ramips/image/mt7621.mk b/target/linux/ramips/image/mt7621.mk index 88db43cb65..9438e5c09e 100644 --- a/target/linux/ramips/image/mt7621.mk +++ b/target/linux/ramips/image/mt7621.mk @@ -221,7 +221,14 @@ define Device/dlink_dir-860l-b1 BLOCKSIZE := 64k SEAMA_SIGNATURE := wrgac13_dlink.2013gui_dir860lb LOADER_TYPE := bin - KERNEL := kernel-bin | append-dtb | lzma | loader-kernel | \ + LOADER_FLASH_OFFS := 0x501040 + COMPILE := loader-$(1).bin loader-$(1).lzma + COMPILE/loader-$(1).bin := loader-okli-compile + COMPILE/loader-$(1).lzma := append-loader-okli $(1) | pad-to 32k | \ + relocate-kernel | lzma + KERNEL := kernel-bin | append-dtb | lzma | uImage lzma -M 0x4f4b4c49 | \ + loader-okli-with-type $(1) 4096 lzma + KERNEL_INITRAMFS := kernel-bin | append-dtb | lzma | loader-kernel | \ relocate-kernel | lzma -a0 | uImage lzma IMAGE_SIZE := 16064k DEVICE_VENDOR := D-Link -- 2.17.1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [RFC, PATCH] ramips: mt7621: use OKLI lzma-loader for D-Link DIR-860L B1 (was: Re: [PATCH 2/2] ramips: mt7621: use lzma-loader for D-Link DIR-860L)
Hi!
Chuanhong Guo ezt írta (időpont: 2020. ápr. 19., V,
17:42):
>
> Hi!
>
>
>
> My original thought on this device is to use a different loader. The first
> 4MB of SPI-NOR flash on mt7621 is mapped to 0x1fc0 and lzma
> loader can read compressed kernel directly from flash. If the kernel
> can be put at a fixed offset in flash, we could compress lzma loader
> separately and let u-boot decompress only the loader.
> You could take a look at the tp-link-nolzma recipe in:
> target/linux/ath79/image/common-tp-link.mk
> and see if you could implement a similar solution for mt7621.
> Note: You need to fix AR71XX_FLASH_START defined in:
> target/linux/ramips/image/lzma-loader/src/loader.c
> to 0x1fc0 for this method to work.
>
I managed to make the loader-okli recipes work on this DIR-860L router.
It's ugly:
target/linux/ramips/image/Makefile | 20
target/linux/ramips/image/lzma-loader/src/loader.c | 2 +-
target/linux/ramips/image/mt7621.mk | 9 -
3 files changed, 29 insertions(+), 2 deletions(-)
... compared to the my original change:
target/linux/ramips/image/mt7621.mk | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
And it's fragile!
LOADER_FLASH_OFFS consists of:
- the address of the firmware partition (0x50)
- loader-okli recipe's "kernel offset" argument (and the compressed size of the
loader)
- the 64 byte length header from the Device/seama recipe
- and the AR71XX_FLASH_START value in loader.c
And there is a "pad to 32k" step while building the loader separately
and I don't know why it's needed to be 32k - sure it doesn't work with 24k, 16k
and below.
About the AR71XX_FLASH_START= 0x1000 in loader.c:
This is now 100% DIR-860L specific value. As you can see in the serial log
that the loader finds the kernel at 0xb0501040 which consits of the following
components:
- 0x0040: SEAMA header and metadata (see Device/seama)
- 0x1000: the 4096 "kernel offset" argument of loader-okli
- 0x0050: start adress of "firmware" partition
- 0xa000: KSEG1 address
The rest (0x1000) is AR71XX_FLASH_START and other unknown (at lest to me)
parts.
So I chose AR71XX_FLASH_START= 0x1000.
Sure there is a room to improvement. At least move AR71XX_FLASH_START to the
board file, and rename! ;)
The 4096 byte "kernel offset" is a freely chosen value: it's little bigger than
the compressed lzma loader and it is padded to 4k. ;)
Anyway! It works! And it works nicely! :D
Check the timestamped serial logs below!
The double compressed lzma-loader method needs
- 1.9s for u-boot ("Uncompressing SEAMA linux.lzma ... OK")
- 1.1s for the kernel loader ("Decompressing kernel... done!")
The OKLI method needs:
- no time (0.05s) for u-boot
- 1.4s for the kernel loader
Serial log without this patch:
2020-05-03 20:09:55.367155157: 3: System Boot system code via Flash.
2020-05-03 20:09:55.373933177: ## Booting image at bfc5 ...
2020-05-03 20:09:57.300117502: addr:8050
2020-05-03 20:09:57.308441445: We have SEAMA, Image Size = 2490304
2020-05-03 20:09:57.315410096: Verifying Checksum ...
2020-05-03 20:09:59.205312048: Uncompressing SEAMA linux.lzma ... OK
2020-05-03 20:09:59.216341009: ## Transferring control to Linux (at address
) ...
2020-05-03 20:09:59.222500408: ## Giving linux memsize in MB, 128
2020-05-03 20:09:59.224349797:
2020-05-03 20:09:59.226204307: Starting kernel ...
2020-05-03 20:09:59.227824058:
2020-05-03 20:09:59.289356732:
2020-05-03 20:09:59.290995300:
2020-05-03 20:09:59.297258876: OpenWrt kernel loader for MIPS based SoC
2020-05-03 20:09:59.306245212: Copyright (C) 2011 Gabor Juhos
2020-05-03 20:10:00.417134281: Decompressing kernel... done!
2020-05-03 20:10:00.425918694: Starting kernel at 80001000...
2020-05-03 20:10:00.432489649:
2020-05-03 20:10:00.453684838: [ 0.00] Linux version 5.4.35
(builder@buildhost) (gcc version 8.4.0 (OpenWrt GCC 8.4.0 r13108-87c909e969))
#0 SMP Mon Apr 27 23:10:48 2020
2020-05-03 20:10:00.462322280: [ 0.00] SoC Type: MediaTek MT7621 ver:1 eco:3
2020-05-03 20:10:00.471916788: [ 0.00] printk: bootconsole [early0] enabled
2020-05-03 20:10:00.480939230: [ 0.00] CPU0 revision is: 0001992f (MIPS
1004Kc)
2020-05-03 20:10:00.491938368: [ 0.00] MIPS: machine is D-Link DIR-860L B1
2020-05-03 20:10:00.503935082: [ 0.00] Initrd not found or empty -
disabling initrd
Serial log with OKLI:
2020-05-03 22:36:18.360052605: 3: System Boot system code via Flash.
2020-05-03 22:36:18.365448792: ## Booting image at bfc5 ...
2020-05-03 22:36:20.299329593: addr:8050
2020-05-03 22:36:20.320272229: We have SEAMA, Image Size = 2490304
2020-05-03 22:36:20.333914984: Verifying Checksum ...
2020-05-03 22:36:20.381790212: Uncompressing SEAMA linux.lzma ... OK
2020-05-03 22:36:20.397034839: ## Transferring control to Linux (at address
) ...
2020-05-03 22:36:20.413734125: ## Giving linux memsize in MB, 128
2020-05-03
Re: [OpenWrt-Devel] [PATCH] ramips: mt7621: use lzma-loader for D-Link DIR-860L B1
Hi David! Sorry for the long mail, it's full of serial log. Szabolcs Hubai ezt írta (időpont: 2020. ápr. 26., V, 16:43): > > Hi David! > > David Bauer ezt írta (időpont: 2020. ápr. 26., V, > 14:42): > > > > Hi Szabolcs, > > > > On 4/19/20 8:49 PM, Szabolcs Hubai wrote: > > > - KERNEL := kernel-bin | append-dtb | relocate-kernel | lzma | uImage > > > lzma > > > + LOADER_TYPE := bin > > > + KERNEL := kernel-bin | append-dtb | lzma | loader-kernel | \ > > > + relocate-kernel | lzma -a0 | uImage lzma > > > > Sorry for going over this one more time. Is there a specific reason > > to pack the resulting uImage using lzma? Also the lzma-loader relocates > > itself afaik, so relocate-kernel shouldn't be necessary when using our > > own loader (i might be wrong here). > > > > Could you try the attached patch on your device? > > > > No problem at all, as it's still not landed. :) > Meanwhile I started playing with that loader-okli what Guo was referring. > Looks like it needs more magic. :D > > > I tried your proposed path when the recipe hit master, without lack. [0] > Will try again for you. I built your patch, let's see the logs! Here is the initramfs boot - it works because uncompressed image works through tftp: Got it # # # # # # # # # # # # # # ## done Bytes transferred = 4667492 (473864 hex) NetBootFileXferSize= 00473864 Automatic boot of image at addr 0x80A0 ... ## Booting image at 80a0 ... Image Name: MIPS OpenWrt Linux-5.4.34 Image Type: MIPS Linux Kernel Image (uncompressed) Data Size:4667428 Bytes = 4.5 MB Load Address: 80001000 Entry Point: 80001000 Verifying Checksum ... OK OK Starting kernel ... OpenWrt kernel loader for MIPS based SoC Copyright (C) 2011 Gabor Juhos Decompressing kernel... done! Starting kernel at 80001000... [0.00] Linux version 5.4.34 (xabolcs@ut1804) (gcc version 8.4.0 (OpenWrt GCC 8.4.0 r13060-471b8bf8c1)) #0 SMP Sat Apr 25 09:31:33 2020 [0.00] SoC Type: MediaTek MT7621 ver:1 eco:3 [0.00] printk: bootconsole [early0] enabled [0.00] CPU0 revision is: 0001992f (MIPS 1004Kc) [0.00] MIPS: machine is D-Link DIR-860L B1 [0.00] Initrd not found or empty - disabling initrd And here is the boot from flash: Please choose the operation: 1: Load system code to SDRAM via TFTP. 2: Load system code then write to Flash via TFTP. 3: Boot system code via Flash (default). 4: Entr boot command line interface. 7: Load Boot Loader code then write to Flash via Serial. 9: Load Boot Loader code then write to Flash via TFTP. 0 3: System Boot system code via Flash. ## Booting image at bfc5 ... addr:8050 We have SEAMA, Image Size = 4784068 Verifying Checksum ... Uncompressing SEAMA linux.lzma ... LZMA ERROR 1 - must RESET board to re
Re: [OpenWrt-Devel] [PATCH] ramips: mt7621: use lzma-loader for D-Link DIR-860L B1
Hi again! Szabolcs Hubai ezt írta (időpont: 2020. ápr. 26., V, 16:43): > > Hi David! > > David Bauer ezt írta (időpont: 2020. ápr. 26., V, > 14:42): > > > > Hi Szabolcs, > > > > On 4/19/20 8:49 PM, Szabolcs Hubai wrote: > > > - KERNEL := kernel-bin | append-dtb | relocate-kernel | lzma | uImage > > > lzma > > > + LOADER_TYPE := bin > > > + KERNEL := kernel-bin | append-dtb | lzma | loader-kernel | \ > > > + relocate-kernel | lzma -a0 | uImage lzma > > > > Sorry for going over this one more time. Is there a specific reason > > to pack the resulting uImage using lzma? Also the lzma-loader relocates > > itself afaik, so relocate-kernel shouldn't be necessary when using our > > own loader (i might be wrong here). > > > > Could you try the attached patch on your device? > > > > No problem at all, as it's still not landed. :) > Meanwhile I started playing with that loader-okli what Guo was referring. > Looks like it needs more magic. :D > > > I tried your proposed path when the recipe hit master, without lack. [0] > Will try again for you. > Forgot to mention that Guo also noted his original thread [0] that DIR-860L is an exception. [0] http://lists.infradead.org/pipermail/openwrt-devel/2020-April/022834.html BR, Szabolcs > About the lzma repack: I found out that the U-Boot accepts > uncompressed and lzma compressed initramfs images. > It doesn't accepts gzip initramfs, but I didn't tested other compressions. > I also found that the U-Boot expects lzma compressed kernel images > from the flash and doesn't care about uImage header. > > About relocate-kernel: without it the router hangs after "transferring > control to Linux", like below! > > > Please choose the operation: >1: Load system code to SDRAM via TFTP. >2: Load system code then write to Flash via TFTP. >3: Boot system code via Flash (default). >4: Entr boot command line interface. >7: Load Boot Loader code then write to Flash via Serial. >9: Load Boot Loader code then write to Flash via TFTP. > 0 > > 3: System Boot system code via Flash. > ## Booting image at bfc5 ... > addr:8050 > We have SEAMA, Image Size = 4759794 > Verifying Checksum ... > Uncompressing SEAMA linux.lzma ... OK > ## Transferring control to Linux (at address ) ... > ## Giving linux memsize in MB, 128 > > Starting kernel ... > > (hang) > > > > [0] > https://forum.openwrt.org/t/optimized-build-for-the-d-link-dir-860l/948/1089?u=xabolcs > > > Regards, > Szabolcs > > > Best wishes > > David ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] ramips: mt7621: use lzma-loader for D-Link DIR-860L B1
Hi David! David Bauer ezt írta (időpont: 2020. ápr. 26., V, 14:42): > > Hi Szabolcs, > > On 4/19/20 8:49 PM, Szabolcs Hubai wrote: > > - KERNEL := kernel-bin | append-dtb | relocate-kernel | lzma | uImage lzma > > + LOADER_TYPE := bin > > + KERNEL := kernel-bin | append-dtb | lzma | loader-kernel | \ > > + relocate-kernel | lzma -a0 | uImage lzma > > Sorry for going over this one more time. Is there a specific reason > to pack the resulting uImage using lzma? Also the lzma-loader relocates > itself afaik, so relocate-kernel shouldn't be necessary when using our > own loader (i might be wrong here). > > Could you try the attached patch on your device? > No problem at all, as it's still not landed. :) Meanwhile I started playing with that loader-okli what Guo was referring. Looks like it needs more magic. :D I tried your proposed path when the recipe hit master, without lack. [0] Will try again for you. About the lzma repack: I found out that the U-Boot accepts uncompressed and lzma compressed initramfs images. It doesn't accepts gzip initramfs, but I didn't tested other compressions. I also found that the U-Boot expects lzma compressed kernel images from the flash and doesn't care about uImage header. About relocate-kernel: without it the router hangs after "transferring control to Linux", like below! Please choose the operation: 1: Load system code to SDRAM via TFTP. 2: Load system code then write to Flash via TFTP. 3: Boot system code via Flash (default). 4: Entr boot command line interface. 7: Load Boot Loader code then write to Flash via Serial. 9: Load Boot Loader code then write to Flash via TFTP. 0 3: System Boot system code via Flash. ## Booting image at bfc5 ... addr:8050 We have SEAMA, Image Size = 4759794 Verifying Checksum ... Uncompressing SEAMA linux.lzma ... OK ## Transferring control to Linux (at address ) ... ## Giving linux memsize in MB, 128 Starting kernel ... (hang) [0] https://forum.openwrt.org/t/optimized-build-for-the-d-link-dir-860l/948/1089?u=xabolcs Regards, Szabolcs > Best wishes > David ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] ramips: mt7621: use lzma-loader for D-Link DIR-860L B1
Hi Stijn,
Stijn Segers ezt írta (időpont: 2020. ápr.
21., K, 17:52):
>
> Hi,
>
>
> Op dinsdag 21 april 2020 om 15:12 schreef Stijn Segers
> :
> > Hi Szabolcs,
> >
> > Op maandag 20 april 2020 om 11:01 schreef Szabolcs Hubai
> > :
> >> Hello,
> >>
> >> Stijn Segers ezt írta (időpont: 2020.
> >> ápr.
> >> 20., H, 9:25):
> >>>
> >>> Hi Szabolcs,
> >>>
> >>> Op zondag 19 april 2020 om 20u49 schreef Szabolcs Hubai
> >>> :
> >>> > This device has trouble extracting big kernel from flash,
> >>> > and supports LZMA compressed kernels only.
> >>> >
> >>> > Using OpenWrt kernel loader saves us 64 KB compared to the
> >>> dictionary
> >>> > size limiting workaround.
> >>> >
> >>> > Factory image sizes (commit: 5f126c541a74) with
> >>> "CONFIG_ALL_KMODS=y":
> >>> > - original ("-d23", default): 4784188 bytes, LZMA ERROR 1
> >>> > - with "-d19": 4915260, LZMA ERROR 1
> >>> > - with "-d18": 4915260, diff to original: +128 KB
> >>> > - with "-d17": 4980796, diff to original: +192 KB
> >>> > - with this patch: 4849724, diff to original: +64 KB
> >>> >
> >>> > To save some CPU cycle, use minimal compression ("-a0") for the
> >>> LZMA
> >>> > compressed uImage.
> >>> >
> >>> > The most robust solution would use a different loader,
> >>> > which reads the compressed kernel directly from the flash.
> >>> > See the thread at [0] for more details!
> >>>
> >>> Thanks for giving the DIR-860L some love. I'd like to test (in
> >>> fact I
> >>> already
> >>> did with your previous patches) and hook up serial, because first
> >>> boot
> >>> will
> >>> work but any reboot (whether I change settings or not) will just
> >>> give
> >>> me a
> >>> blinking orange LED. Like clockwork.
> >>>
> >>> Would you happen to have any pointers (or pictures) on how to open
> >>> the
> >>> case?
> >>> I have unscrewed the bottom but there seem to be latches on the
> >>> inside
> >>> (judging
> >>> from the FCC pictures) and I am unable to pry it open.
> >>>
> >>> Thanks and sorry for the topic hijack :-).
> >>>
> >>> Stijn
> >>>
> >>
> >> I got my clue from the "D-LINK DIR-860L - disassemble" titled
> >> YouTube video. [0]
> >> In short:
> >> - 3 screws on the bottom, under the pads: if you are looking at the
> >> bottom of the router, the screws are under the left, the right and
> >> the
> >> bottom pads
> >> - one, "DIR-860L" titled sticker on the top, with a "cut in" starting
> >> point in the front, where the leds reside
> >
> >
> > Thanks! That sticker turned out to be so sturdy - it doesn't look or
> > feel like a sticker *at all*. That's what got me.
> >
> > So, I have serial now. A few things I can tell from my side:
> > - vanilla master image (yesterday's image): does not boot, which is
> > expected of course. Error I'm seeing: "LZMA ERROR 1 - must RESET
> > board to recover"
> > - local master branch image (with your last patch) with default
> > .config: boots fine, even after multiple reboots.
> > - local master branch image (with your last patch) with my own
> > config: boots fine the first time. After that, it just barks and says
> > 'Bad Header checksum'.
> >
> > It looks like there's something with my .config that breaks it... The
> > (kernel?) image is pretty big (9109444 bytes?) from what I can tell,
> > maybe that's still an issue here.
> >
> As a follow-up: wiping my ccache worked wonders it seems. All good now.
>
Great news, thanks! :)
--
Szabolcs
> Cheers
>
> Stijn
>
>
> > This is what default config prints:
> >
> > 3: System Boot system code via Flash.
> > ## Booting image at bfc5 ...
> > addr:8050
> > We have SEAMA, Image Size = 2359232
> > Verifying Checksum ...
> > Uncompressing SEAMA linux.lzma ... OK
> >
> > And my custom config (which boots fine the first time after flashing
> > somehow, then goes straight to recove
Re: [OpenWrt-Devel] [PATCH] ramips: mt7621: use lzma-loader for D-Link DIR-860L B1
Hello,
Stijn Segers ezt írta (időpont: 2020. ápr.
20., H, 9:25):
>
> Hi Szabolcs,
>
> Op zondag 19 april 2020 om 20u49 schreef Szabolcs Hubai
> :
> > This device has trouble extracting big kernel from flash,
> > and supports LZMA compressed kernels only.
> >
> > Using OpenWrt kernel loader saves us 64 KB compared to the dictionary
> > size limiting workaround.
> >
> > Factory image sizes (commit: 5f126c541a74) with "CONFIG_ALL_KMODS=y":
> > - original ("-d23", default): 4784188 bytes, LZMA ERROR 1
> > - with "-d19": 4915260, LZMA ERROR 1
> > - with "-d18": 4915260, diff to original: +128 KB
> > - with "-d17": 4980796, diff to original: +192 KB
> > - with this patch: 4849724, diff to original: +64 KB
> >
> > To save some CPU cycle, use minimal compression ("-a0") for the LZMA
> > compressed uImage.
> >
> > The most robust solution would use a different loader,
> > which reads the compressed kernel directly from the flash.
> > See the thread at [0] for more details!
>
> Thanks for giving the DIR-860L some love. I'd like to test (in fact I
> already
> did with your previous patches) and hook up serial, because first boot
> will
> work but any reboot (whether I change settings or not) will just give
> me a
> blinking orange LED. Like clockwork.
>
> Would you happen to have any pointers (or pictures) on how to open the
> case?
> I have unscrewed the bottom but there seem to be latches on the inside
> (judging
> from the FCC pictures) and I am unable to pry it open.
>
> Thanks and sorry for the topic hijack :-).
>
> Stijn
>
I got my clue from the "D-LINK DIR-860L - disassemble" titled YouTube video. [0]
In short:
- 3 screws on the bottom, under the pads: if you are looking at the
bottom of the router, the screws are under the left, the right and the
bottom pads
- one, "DIR-860L" titled sticker on the top, with a "cut in" starting
point in the front, where the leds reside
- 3 screws on the top, under the sticker
Disassemble:
- get off the pads (they won't stick back after a few days ;), use
very thin double sided sticker to help them)
- get the bottom screws
- peel off the rounded sticker from the top with thin but flexible
knife or razor blade, etc ...
- get the upper screws
- slide the front and rear half vertically a little
- separate them
The serial settings can be found on the wiki [1]:
- Pinout: TX, GND, 3v3, empty, RX
- Bits per second: 57600
- Data bits: 8
- Parity: None
- Stop bits: 1
- Flow control: None
I have a CP2102 USB to TTL module, and used with "minicom -D /dev/ttyUSB0".
Intereestingly, when I connected with serial to the router it was
sometime unstable:
* refuse to start
* freeze at boot soon after: "Error applying setting, reverse things
back" messge
Other than this, I have no problem with k5.4.
[0]: https://youtu.be/tf7nMqdUKD4
[1]: https://openwrt.org/toh/d-link/dir-860l#access_with_serial_cable
--
Regards,
Szabolcs
>
> >
> > [0]
> > http://lists.infradead.org/pipermail/openwrt-devel/2020-April/022926.html
> >
> > Signed-off-by: Szabolcs Hubai
> > ---
> > target/linux/ramips/image/mt7621.mk | 4 +++-
> > 1 file changed, 3 insertions(+), 1 deletion(-)
> >
> > diff --git a/target/linux/ramips/image/mt7621.mk
> > b/target/linux/ramips/image/mt7621.mk
> > index aa6836d50a..e954f730da 100644
> > --- a/target/linux/ramips/image/mt7621.mk
> > +++ b/target/linux/ramips/image/mt7621.mk
> > @@ -218,7 +218,9 @@ define Device/dlink_dir-860l-b1
> >$(Device/seama)
> >BLOCKSIZE := 64k
> >SEAMA_SIGNATURE := wrgac13_dlink.2013gui_dir860lb
> > - KERNEL := kernel-bin | append-dtb | relocate-kernel | lzma |
> > uImage lzma
> > + LOADER_TYPE := bin
> > + KERNEL := kernel-bin | append-dtb | lzma | loader-kernel | \
> > + relocate-kernel | lzma -a0 | uImage lzma
> >IMAGE_SIZE := 16064k
> >DEVICE_VENDOR := D-Link
> >DEVICE_MODEL := DIR-860L
> > --
> > 2.17.1
> >
> >
> > ___
> > openwrt-devel mailing list
> > openwrt-devel@lists.openwrt.org
> > https://lists.openwrt.org/mailman/listinfo/openwrt-devel
>
>
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] ramips: mt7621: use lzma-loader for D-Link DIR-860L B1
This device has trouble extracting big kernel from flash,
and supports LZMA compressed kernels only.
Using OpenWrt kernel loader saves us 64 KB compared to the dictionary
size limiting workaround.
Factory image sizes (commit: 5f126c541a74) with "CONFIG_ALL_KMODS=y":
- original ("-d23", default): 4784188 bytes, LZMA ERROR 1
- with "-d19": 4915260, LZMA ERROR 1
- with "-d18": 4915260, diff to original: +128 KB
- with "-d17": 4980796, diff to original: +192 KB
- with this patch: 4849724, diff to original: +64 KB
To save some CPU cycle, use minimal compression ("-a0") for the LZMA
compressed uImage.
The most robust solution would use a different loader,
which reads the compressed kernel directly from the flash.
See the thread at [0] for more details!
[0] http://lists.infradead.org/pipermail/openwrt-devel/2020-April/022926.html
Signed-off-by: Szabolcs Hubai
---
target/linux/ramips/image/mt7621.mk | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/target/linux/ramips/image/mt7621.mk
b/target/linux/ramips/image/mt7621.mk
index aa6836d50a..e954f730da 100644
--- a/target/linux/ramips/image/mt7621.mk
+++ b/target/linux/ramips/image/mt7621.mk
@@ -218,7 +218,9 @@ define Device/dlink_dir-860l-b1
$(Device/seama)
BLOCKSIZE := 64k
SEAMA_SIGNATURE := wrgac13_dlink.2013gui_dir860lb
- KERNEL := kernel-bin | append-dtb | relocate-kernel | lzma | uImage lzma
+ LOADER_TYPE := bin
+ KERNEL := kernel-bin | append-dtb | lzma | loader-kernel | \
+ relocate-kernel | lzma -a0 | uImage lzma
IMAGE_SIZE := 16064k
DEVICE_VENDOR := D-Link
DEVICE_MODEL := DIR-860L
--
2.17.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH v3] ramips: mt7621: use lzma-loader for D-Link DIR-860L B1
Hello, This is my third attempt to revive the snapshot images for D-Link DIR-860L B1. In this version, only the dlink_dir-860l-b1 recipe is modified. -- Regards, Szabolcs ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 2/2] ramips: mt7621: use lzma-loader for D-Link DIR-860L
Hello!
Chuanhong Guo ezt írta (időpont: 2020. ápr. 19.,
V, 17:42):
>
> Hi!
>
> On Sun, Apr 19, 2020 at 8:38 AM Szabolcs Hubai wrote:
> >
> > This device has trouble extracting big kernel from flash,
> > and supports LZMA compressed kernels only.
> >
> > Using OpenWrt kernel loader saves us 64 KB compared to the dictionary
> > size limiting workaround.
> >
> > Factory image sizes (commit: 5f126c541a74) with "CONFIG_ALL_KMODS=y":
> > - original ("-d23", default): 4784188 bytes, LZMA ERROR 1
> > - with "-d19": 4915260, LZMA ERROR 1
> > - with "-d18": 4915260, diff to original: +128 KB
> > - with "-d17": 4980796, diff to original: +192 KB
> > - with this patch: 4849724, diff to original: +64 KB
> >
> > To save some CPU cycle, use minimal compression ("-a0") for the LZMA
> > compressed uImage.
>
> My original thought on this device is to use a different loader. The first
> 4MB of SPI-NOR flash on mt7621 is mapped to 0x1fc0 and lzma
> loader can read compressed kernel directly from flash. If the kernel
> can be put at a fixed offset in flash, we could compress lzma loader
> separately and let u-boot decompress only the loader.
> You could take a look at the tp-link-nolzma recipe in:
> target/linux/ath79/image/common-tp-link.mk
> and see if you could implement a similar solution for mt7621.
> Note: You need to fix AR71XX_FLASH_START defined in:
> target/linux/ramips/image/lzma-loader/src/loader.c
> to 0x1fc0 for this method to work.
>
Yes, that new loader would be best solution.
I'm a DevOps guy and my C-fu is just Googling and copy-pasting. :D
I'm interested in the implementation, so I would play with the source code
as a homework, but those patches wouldn't be ready for the 20.xx release. ;)
> If you can't implement it, I'm fine with your current solution too.
> but I prefer to drop patch 1/2 and write the complete kernel
> recipe for dir-860l only. It's a bit confusing to use "KERNEL +="
>
I'm going to go this way. Thank you both for the comments.
--
BR,
Szabolcs
> --
> Regards,
> Chuanhong Guo
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 2/2] ramips: mt7621: use lzma-loader for D-Link DIR-860L
ezt írta (időpont: 2020. ápr. 19., V, 14:40):
>
> Hi,
>
> > -Original Message-
> > From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> > On Behalf Of Szabolcs Hubai
> > Sent: Sonntag, 19. April 2020 02:37
> > To: openwrt-devel@lists.openwrt.org
> > Cc: Szabolcs Hubai
> > Subject: [OpenWrt-Devel] [PATCH 2/2] ramips: mt7621: use lzma-loader for
> > D-Link DIR-860L
> >
> > This device has trouble extracting big kernel from flash, and supports LZMA
> > compressed kernels only.
> >
> > Using OpenWrt kernel loader saves us 64 KB compared to the dictionary size
> > limiting workaround.
> >
> > Factory image sizes (commit: 5f126c541a74) with "CONFIG_ALL_KMODS=y":
> > - original ("-d23", default): 4784188 bytes, LZMA ERROR 1
> > - with "-d19": 4915260, LZMA ERROR 1
> > - with "-d18": 4915260, diff to original: +128 KB
> > - with "-d17": 4980796, diff to original: +192 KB
> > - with this patch: 4849724, diff to original: +64 KB
> >
> > To save some CPU cycle, use minimal compression ("-a0") for the LZMA
> > compressed uImage.
> >
> > Signed-off-by: Szabolcs Hubai
> > ---
> > target/linux/ramips/image/mt7621.mk | 3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/target/linux/ramips/image/mt7621.mk
> > b/target/linux/ramips/image/mt7621.mk
> > index aa6836d50a..28d2637bd3 100644
> > --- a/target/linux/ramips/image/mt7621.mk
> > +++ b/target/linux/ramips/image/mt7621.mk
> > @@ -216,9 +216,10 @@ TARGET_DEVICES += buffalo_wsr-600dhp
> >
> > define Device/dlink_dir-860l-b1
> >$(Device/seama)
> > + $(Device/lzma-loader)
>
> I do not really see the benefit of having this definition if you have to
> modify it below anyway.
> Having seen this, I'd prefer to drop patch 1/2 entirely and just add the
> necessary adjustments directly to this particular device:
>
> LOADER_TYPE := bin
> KERNEL := kernel-bin | append-dtb | lzma | loader-kernel | relocate-kernel |
> lzma -a0 | uImage lzma
> (properly wrapped of course)
>
> If we have five devices like this at some point, I'll be happy to discuss how
> we can create a shared recipe.
>
> Best
>
> Adrian
>
As a newcomer it took me days to leave the "KERNEL_DTB += -d21" line
alone while debugging this LZMA ERROR on this device.
With the new recipe I wanted to emphasize that D-Link DIR-860L also
uses the kernel loader method, but it needs more magic to complete the
workaround.
Sure, that one properly wrapped line should also fix the snapshot images,
but I think creating and reusing that new recipe has the added value.
I like the new recipe better, but I'm OK with the one-liner, if you
think that the new recipe is overkill for this fix.
--
Szabolcs
> >BLOCKSIZE := 64k
> >SEAMA_SIGNATURE := wrgac13_dlink.2013gui_dir860lb
> > - KERNEL := kernel-bin | append-dtb | relocate-kernel | lzma | uImage lzma
> > + KERNEL += | relocate-kernel | lzma -a0 | uImage lzma
> >IMAGE_SIZE := 16064k
> >DEVICE_VENDOR := D-Link
> >DEVICE_MODEL := DIR-860L
> > --
> > 2.17.1
> >
> >
> > ___
> > openwrt-devel mailing list
> > openwrt-devel@lists.openwrt.org
> > https://lists.openwrt.org/mailman/listinfo/openwrt-devel
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] (no subject)
Hello,
This is my second attempt to fix the snapshot images for D-Link DIR 860L B1.
This device accepts uncompressed uImages as initramfs only.
>From the flash it expects LZMA compressed image and ignores the uImage header.
To create a bootable image, the LZMA packed kernel prepared with the LZMA loader
has to be packed again with LZMA.
For the initramfs, it needs an LZMA compressed uImage header too.
In the second LZMA compression stage I use the fastest compression ("-a0") to
save some CPU power.
In my previous attempt the "-d18" LZMA parameter needs 128K more space,
while "-d19" and above causes LZMA ERROR 1.
With this patch (LZMA loader + double LZMA compression) it needs 64K more space,
compared to the snapshot image, which uses "-d23" as default.
--
Regards,
Szabolcs
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 1/2] ramips: define image recipe for plain lzma-loader for advanced cases
This change allows to make other transformations to kernel before uImage Signed-off-by: Szabolcs Hubai --- target/linux/ramips/image/Makefile | 9 +++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/target/linux/ramips/image/Makefile b/target/linux/ramips/image/Makefile index f93ea8ab2a..707bc85f9a 100644 --- a/target/linux/ramips/image/Makefile +++ b/target/linux/ramips/image/Makefile @@ -37,9 +37,14 @@ define Device/Default IMAGE/sysupgrade.bin := append-kernel | append-rootfs | pad-rootfs | append-metadata | check-size endef -define Device/uimage-lzma-loader +define Device/lzma-loader LOADER_TYPE := bin - KERNEL := kernel-bin | append-dtb | lzma | loader-kernel | uImage none + KERNEL := kernel-bin | append-dtb | lzma | loader-kernel +endef + +define Device/uimage-lzma-loader + $(Device/lzma-loader) + KERNEL += | uImage none endef define Device/seama -- 2.17.1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 2/2] ramips: mt7621: use lzma-loader for D-Link DIR-860L
This device has trouble extracting big kernel from flash,
and supports LZMA compressed kernels only.
Using OpenWrt kernel loader saves us 64 KB compared to the dictionary
size limiting workaround.
Factory image sizes (commit: 5f126c541a74) with "CONFIG_ALL_KMODS=y":
- original ("-d23", default): 4784188 bytes, LZMA ERROR 1
- with "-d19": 4915260, LZMA ERROR 1
- with "-d18": 4915260, diff to original: +128 KB
- with "-d17": 4980796, diff to original: +192 KB
- with this patch: 4849724, diff to original: +64 KB
To save some CPU cycle, use minimal compression ("-a0") for the LZMA
compressed uImage.
Signed-off-by: Szabolcs Hubai
---
target/linux/ramips/image/mt7621.mk | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/target/linux/ramips/image/mt7621.mk
b/target/linux/ramips/image/mt7621.mk
index aa6836d50a..28d2637bd3 100644
--- a/target/linux/ramips/image/mt7621.mk
+++ b/target/linux/ramips/image/mt7621.mk
@@ -216,9 +216,10 @@ TARGET_DEVICES += buffalo_wsr-600dhp
define Device/dlink_dir-860l-b1
$(Device/seama)
+ $(Device/lzma-loader)
BLOCKSIZE := 64k
SEAMA_SIGNATURE := wrgac13_dlink.2013gui_dir860lb
- KERNEL := kernel-bin | append-dtb | relocate-kernel | lzma | uImage lzma
+ KERNEL += | relocate-kernel | lzma -a0 | uImage lzma
IMAGE_SIZE := 16064k
DEVICE_VENDOR := D-Link
DEVICE_MODEL := DIR-860L
--
2.17.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] ramips: mt7621: limit dictionary size for DIR-860L due to kernel 5.4
Hi!
Sorry, I didn't noticed that the lzma-loader thread [0] originally had
a note about DIR-860L.
I read the landed commits only which didn't talk about followups.
Sure, this dictionary size adjustment is just a workaround, the real
fix would be that updated lzma-loader.
Sorry for the noise!
Szabolcs
[0] http://lists.infradead.org/pipermail/openwrt-devel/2020-April/022834.html
Szabolcs Hubai ezt írta (időpont: 2020. ápr. 16.,
Cs, 17:32):
>
> Snapshot images for DIR-860L after the initial kernel 5.4 landing
> (on Apr 4, 2020 commits from b51ea43f9001 to 4d979a4d1969)
> are broken: they causes "LZMA ERROR 1 - must RESET board to recover"
>
> Snapshot factory image serial log:
>
> Please choose the operation:
>1: Load system code to SDRAM via TFTP.
>2: Load system code then write to Flash via TFTP.
>3: Boot system code via Flash (default).
>4: Entr boot command line interface.
>7: Load Boot Loader code then write to Flash via Serial.
>9: Load Boot Loader code then write to Flash via TFTP.
>
> You choosed 3
>
> 0
>
> 3: System Boot system code via Flash.
> addr:8050
> We have SEAMA, Image Size = 2424768
> Verifying Checksum ...
> Uncompressing SEAMA linux.lzma ... LZMA ERROR 1 - must RESET board to recover
>
>
> The local defconfig build works, also the snapshot initramfs images.
>
> The bug can be reproduced with the "CONFIG_ALL_KMODS=y" configuration.
>
> As this "LZMA ERROR 1" isn't new (e.g. 77e2bccde8f7),
> I tried to adjust the lzma dictionary parameter:
> - with "-d20" and above it causes "LZMA ERROR 1"
> - with "-d19" it boots but doesn't find the device tree (see below)
> - with "-d18" it boots fine
>
> Serial log with "-d19" lzma dictionary:
>
> Please choose the operation:
>1: Load system code to SDRAM via TFTP.
>2: Load system code then write to Flash via TFTP.
>3: Boot system code via Flash (default).
>4: Entr boot command line interface.
>7: Load Boot Loader code then write to Flash via Serial.
>9: Load Boot Loader code then write to Flash via TFTP.
> 0
>
> 3: System Boot system code via Flash.
> addr:8050
> We have SEAMA, Image Size = 4915140
> Verifying Checksum ...
> Uncompressing SEAMA linux.lzma ... OK
>
> Starting kernel ...
>
> [0.00] Linux version 5.4.32 (xabolcs@ut1804) (gcc version 8.4.0
> (OpenWrt GCC 8.4.0 r12974-75f19deb3a)) #0 SMP Wed Apr 15 02:14:19 2020
> [0.00] SoC Type: MediaTek MT7621 ver:1 eco:3
> [0.00] printk: bootconsole [early0] enabled
> [0.00] CPU0 revision is: 0001992f (MIPS 1004Kc)
> [0.00] Initrd not found or empty - disabling initrd
> [0.00] VPE topology {2,2} total 4
> [0.00] Primary instruction cache 32kB, VIPT, 4-way, linesize 32 bytes.
> [0.00] Primary data cache 32kB, 4-way, PIPT, no aliases, linesize 32
> bytes
> [0.00] MIPS secondary cache 256kB, 8-way, linesize 32 bytes.
> [0.00] Zone ranges:
> [0.00] Normal [mem 0x-0x07ff]
> [0.00] HighMem empty
> [0.00] Movable zone start for each node
> [0.00] Early memory node ranges
> [0.00] node 0: [mem 0x-0x07ff]
> [0.00] Initmem setup node 0 [mem
> 0x-0x07ff]
> [0.00] OF: fdt: No valid device tree found, continuing without
> [0.00] percpu: Embedded 14 pages/cpu s26704 r8192 d22448 u57344
> [0.00] Built 1 zonelists, mobility grouping on. Total pages: 32480
> [0.00] Kernel command line: rootfstype=squashfs,jffs2
> [0.00] Dentry cache hash table entries: 16384 (order: 4, 65536 bytes,
> linear)
> [0.00] Inode-cache hash table entries: 8192 (order: 3, 32768 bytes,
> linear)
> [0.00] Writing ErrCtl register=0004050c
> [0.00] Readback ErrCtl register=0004050c
> [0.00] mem auto-init: stack:off, heap alloc:off, heap free:off
> [0.00] Memory: 120752K/131072K available (5826K kernel code, 206K
> rwdata, 1252K rodata, 1280K init, 237K bss, 10320K reserved, 0K cma-reserved,
> 0K highmem)
> [0.00] SLUB: HWalign=32, Order=0-3, MinObjects=0, CPUs=4, Nodes=1
> [0.00] rcu: Hierarchical RCU implementation.
> [0.00] rcu: RCU calculated value of scheduler-enlistment delay is 25
> jiffies.
> [0.00] [ cut here ]
> [0.00] WARNING: CPU: 0 PID: 0 at kernel/rcu/tree.c:2998
> rcu_init+0x55c/0x774
> [0.00] Modules linked in:
> [0.00] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.4.32 #0
> [0.00] Stack :
[OpenWrt-Devel] [PATCH] ramips: mt7621: limit dictionary size for DIR-860L due to kernel 5.4
] random: get_random_bytes called from print_oops_end_marker+0x2c/0x64 with crng_init=0 [0.00] ---[ end trace ]--- [0.00] [ cut here ] [0.00] WARNING: CPU: 0 PID: 0 at kernel/rcu/tree.c:2999 rcu_init+0x5ac/0x774 [0.00] Modules linked in: [0.00] CPU: 0 PID: 0 Comm: swapper/0 Tainted: GW 5.4.32 #0 [0.00] Stack : 800774cc 806b 806b6474 8072 806b643c 806b5590 806efdb4 [0.00] 8086 80701248 80700d83 8064c7e4 0001 806efd58 [0.00] 808a 0030 003b 342e3520 2032332e [0.00] 8072 80729a40 [0.00] 0009 806451a4 806fe2b0 8070 0002 0010 87ff [0.00] ... [0.00] Call Trace: [0.00] [<8000b72c>] show_stack+0x30/0x100 [0.00] [<8058fac4>] dump_stack+0xa4/0xdc [0.00] [<80028038>] __warn+0xc0/0x10c [0.00] [<800280e0>] warn_slowpath_fmt+0x5c/0xac [0.00] [<80729a40>] rcu_init+0x5ac/0x774 [0.00] [<80720a7c>] start_kernel+0x2dc/0x55c [0.00] [<80011044>] start_secondary+0xb0/0x3a0 [0.00] ---[ end trace f68728a0d3053b52 ]--- [0.00] NR_IRQS: 256 [0.00] Kernel panic - not syncing: Failed to find mtk,mt7621-sysc node [0.00] Rebooting in 1 seconds.. [0.00] Reboot failed -- System halted Signed-off-by: Szabolcs Hubai --- target/linux/ramips/image/mt7621.mk | 1 + 1 file changed, 1 insertion(+) diff --git a/target/linux/ramips/image/mt7621.mk b/target/linux/ramips/image/mt7621.mk index 6e64fb8bf1..cfae103d22 100644 --- a/target/linux/ramips/image/mt7621.mk +++ b/target/linux/ramips/image/mt7621.mk @@ -218,6 +218,7 @@ define Device/dlink_dir-860l-b1 $(Device/seama) BLOCKSIZE := 64k SEAMA_SIGNATURE := wrgac13_dlink.2013gui_dir860lb + KERNEL := kernel-bin | append-dtb | relocate-kernel | lzma -d18 | uImage lzma KERNEL := kernel-bin | append-dtb | relocate-kernel | lzma | uImage lzma IMAGE_SIZE := 16064k DEVICE_VENDOR := D-Link -- 2.17.1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 2/2] ath79: GL.iNet AR300M family: Correct DTS LED definitions
Jeff Kletsky ezt írta (időpont: 2019. febr. 6., Sze, 2:25): > > > On 2/5/19 4:19 PM, Szabolcs Hubai wrote: > > Hi Jeff, > > > > sorry for being late in the topic, but that [1] red "status" LED is > > GL-AR300M-Lite specific, and isn't suitable for the original GL-AR300M > > model, IMHO. > > > > > > Here are my points: > > > > I opened my GL-AR300MD's case (a limited, dualband model), and it has > > a "GL-AR300M-V1.3.1" print on it's PCB. > > It has the exactly same pinouts as it could be seen on the > > documentation page [2] (picture attached) and it's WLAN LED is red, > > the other two, LAN and SYS (in DTS: "status") are green. > > > > I'm unsure how are the LED colors in the other GL-AR300M sub-models. > > > I checked the GL.iNet site and the video of the GL-AR300M at > <https://docs.gl-inet.com/en/2/hardware/ar300m/#debrick> > published in January, 2017, shows two green and a red LED, > consistent with your description. > > On the other hand, GL.iNet's source shows them as all "green" > (as is the AR300M-Lite I have in hand) > > <https://github.com/gl-inet/openwrt/blob/develop/target/linux/ar71xx/files/arch/mips/ath79/mach-gl-ar300m.c#L49> > > I'm fine with leaving the color alone or being consistent with current > production > and the OEM's definitions. Shoot, my Archer C7 v2 has "blue" LEDs under > OpenWrt. > Too bad that doesn't actually change the color of them ;) > > The GPIO assignments are still in need of correction, as far as I can > tell, for all variants. > > > Jeff > > My GL-AR300MD is pretty old, I bought it when that debrick video was created. :) It would be nice, that you could introduce the Lite support with red "status" LED color. And the GL-AR300M model "status" LED should have at least a comment about this inconsistency to avoid the "fixes" to change it back and forth. It is also possible that the newly produced versions of GL-AR300M (not just the -Lite edition) has the new colors. Yup, the GPIO change was correct. Szabolcs ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
