Re: Install LuCI for snapshots builds
On Tue, May 07, 2024 at 11:52:02PM +0200, Robert Marko wrote: > On Tue, 7 May 2024 at 23:25, Paul Spooren wrote: > > > > Hi all, > > > > For some reason (resource usage?) our snapshot builds do not include the > > LuCI web interface. I think it’s an advantage to have LuCI installed in > > snapshot images since a) it installed for all releases anyway and b) often > > it’s just nice to have the web interface directly available. > > > > Is anyone against having the interface installed by default? I remember > > from multiple (in-person) discussion with fellow developers, that they’d > > prefer it being installed. > > > > If it’s an oversight I’d like to see it added to the default packages (via > > the builedbot config), if there’s a reason to keep it from snapshots, I’d > > like to understand the details. > > +1 for LuCI by default in snapshots as well from me. I understand the usability we may gain from that but you should all be aware that this basically means only having a single buildbot phase with a very slow turnover time, and that is a HUGE disadvantage for development and use of the buildbot as classic CI took. Let me explain why: Currently the snapshot builders are only building **target-specific** packages as well as packages included in the image by default. (We call that "phase1"). That means that a single build takes around 2~3 hours, depending on the target and the machine carrying out the build. In this way we manage to have every target build once approximately every 24 hours. If we wanted to include LuCI, that would basically mean that we will not only have to include all the LuCI modules and applications, but also **all their dependencies** which is basically half of the packages feed. A full build of the packages feed (called "phase2") takes around 4 additional hours (best-case) and up to 17h (worst-case). We also don't build for each (sub-)targets (think: ramips/mt7621), but only for each architecture (think: mips24kc), and many (sub-)targets share the same architecture. This results in every **architecture** being re-built approximately every two days. If we would do this for all (sub-)targets, the number would obviously be even worse, we'd probably only see fresh images once or twice a week, which is too slow to catch problems and too long for users to test changes in a timely manner. It would be a humongous slow down of development and testing on generic and core parts. For me it would mean that I would have to invest a mid four-digit $ amount into hardware to still be able to do meaningful development, and probably it would mean that for quite a few of us. What I could imaging is to have an **additional** build stop on top of that, lets call it "phase3". That could be triggered on completion of phase2 and then assemble images for all (sub-)targets using that architecture including LuCI **in addition** to the phase1 snapshot builds. From a usability point of view, maybe the answer can be much easier and the solution is already there: 1. Go to https://firmware-selector.openwrt.org/ 2. Select 'SNAPSHOT' on the right. 3. Enter the device you want to put OpenWrt on or update. 4. Click on "Customize installed packages and/or first boot script" 5. Add 'luci' (or 'luci-ssl' or 'luci-ssl-openssl', ...) to the list of to-be-installed packages. Maybe we can have an easier way to do that in that web UI and then everybody will be happy? And yes, the images generated using the firmware-selector are being cached there. In this way only the first user requesting an image with additional packages (luci in this case) would have to wait ~ 1 minute for the image to be generated, every subsequent user requesting the same image would be served instantly. The advantage would also be that we don't generated huge amounts of images for legacy devices without any users, nor for "science-fiction" R platforms. Just my 2 cents... ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Issues w/ kexec-tools when building images
The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header. To mitigate this problem, the original message has been wrapped automatically by the mailing list software.--- Begin Message --- Actually, I *am* selecting kexec which is part of kexec-tools… though I forget why. It might be a hangover from when I was bringing up various x86_64 platforms and I needed to be able to boot into a failsafe kernel if the kernel-under-test hung for whatever reason and the watchdog fired… In any case, it should still build. I’ll dig into it if I get a chance. The suspect part is here: x86_64-openwrt-linux-musl-gcc -mcmodel=large -I./purgatory/include -I./purgatory/arch/x86_64/include -I./util_lib/include -I./include -Iinclude -I/home/philipp/lede/staging_dir/toolchain-x86_64_gcc-13.2.0_musl/lib/gcc/x86_64-openwrt-linux-musl/13.2.0/include -c -MD -o purgatory/arch/i386/entry32-16.o purgatory/arch/i386/entry32-16.S And looking at the Makefile: https://git.kernel.org/pub/scm/utils/kernel/kexec/kexec-tools.git/tree/purgatory/arch/x86_64/Makefile#n18 that is indeed what it wants. The top-level Makefile says: AS = x86_64-openwrt-linux-musl-gcc -c -Os -pipe -g3 -fno-caller-saves -fno-plt -fhonour-copts -fmacro-prefix-map=/home/philipp/lede/build_dir/target-x86_64_musl/kexec-tools-2.0.28=kexec-tools-2.0.28 -ffunction-sections -fdata-sections -Wformat -Werror=format-security -fstack-protector -D_FORTIFY_SOURCE=1 -Wl,-z,now -Wl,-z,relro but that’s not how it’s being built. and no ARCH specific flags are defined: ASFLAGS = $($(ARCH)_ASFLAGS) and the top-level Makefile also has: %.o: %.S @$(MKDIR) -p $(@D) $(COMPILE.S) -MD -o $@ $< so the default definition of COMPILE.S seems to be lacking. At which point I run out of -fu, because I can’t remember how to get “make” to dump its default definitions (i.e. the equivalent of "echo | gcc -dM -E -“ for make). > On May 7, 2024, at 4:25 PM, Enéas Ulir de Queiroz > wrote: > > I’m nowhere close to being able to even check this, but I will give you a > pointer. This usually happens when some Makefile defines multiple packages, > one of them depending on kexec-tools (or any package define in its Makefile), > and another one—which you are selecting—that doesn’t. The build dependencies > are resolved at the Makefile level, so kexec is pulled if any package in that > Makefile is selected. > > To fix this, you can add a PACKAGE_foo: conditional to the kexec-tools > dependency. Then the build dependency will also have that condition, and > kexec-tools will not be built. Look at the OpenSSL Makefile for an example > (taking it from memory). > > Cheers, > > Eneas > >> Em 6 de mai. de 2024, à(s) 17:09, Philip Prindeville via openwrt-devel >> escreveu: >> >> The sender domain has a DMARC Reject/Quarantine policy which disallows >> sending mailing list messages using the original "From" header. >> >> To mitigate this problem, the original message has been wrapped >> automatically by the mailing list software. >> >> ___ >> openwrt-devel mailing list >> openwrt-devel@lists.openwrt.org >> https://lists.openwrt.org/mailman/listinfo/openwrt-devel --- End Message --- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Issues w/ kexec-tools when building images
I’m nowhere close to being able to even check this, but I will give you a pointer. This usually happens when some Makefile defines multiple packages, one of them depending on kexec-tools (or any package define in its Makefile), and another one—which you are selecting—that doesn’t. The build dependencies are resolved at the Makefile level, so kexec is pulled if any package in that Makefile is selected. To fix this, you can add a PACKAGE_foo: conditional to the kexec-tools dependency. Then the build dependency will also have that condition, and kexec-tools will not be built. Look at the OpenSSL Makefile for an example (taking it from memory). Cheers, Eneas > Em 6 de mai. de 2024, à(s) 17:09, Philip Prindeville via openwrt-devel > escreveu: > > The sender domain has a DMARC Reject/Quarantine policy which disallows > sending mailing list messages using the original "From" header. > > To mitigate this problem, the original message has been wrapped > automatically by the mailing list software. > > ___ > 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
Re: Issues w/ kexec-tools when building images (redux)
Il giorno mer 8 mag 2024 alle ore 00:03 Philip Prindeville via openwrt-devel ha scritto: > > The sender domain has a DMARC Reject/Quarantine policy which disallows > sending mailing list messages using the original "From" header. > > To mitigate this problem, the original message has been wrapped > automatically by the mailing list software. > > > -- Forwarded message -- > From: Philip Prindeville > To: openwrt-devel@lists.openwrt.org > Cc: > Bcc: > Date: Tue, 7 May 2024 16:00:37 -0600 > Subject: Issues w/ kexec-tools when building images (redux) > Hi, > > Sorry, had to add filters to turn DMARC off when sending mailing list mail…. > > I fetched/rebased recently and now I’m not able to build images. It fails in > kexec-tools, which is odd, because that’s not selected and nothing depends on > it. > > philipp@ubuntu22:~/lede$ grep kexec-tools .config > # CONFIG_PACKAGE_kexec-tools is not set > philipp@ubuntu22:~/lede$ > > Here’s how the build reliably fails: > > make[3]: Entering directory '/home/philipp/lede/package/boot/kexec-tools' > rm -f > /home/philipp/lede/build_dir/target-x86_64_musl/kexec-tools-2.0.28/.built > touch > /home/philipp/lede/build_dir/target-x86_64_musl/kexec-tools-2.0.28/.built_check > make -C /home/philipp/lede/build_dir/target-x86_64_musl/kexec-tools-2.0.28 > DESTDIR="/home/philipp/lede/build_dir/target-x86_64_musl/kexec-tools-2.0.28/ipkg-install" > all install > make[4]: Entering directory > '/home/philipp/lede/build_dir/target-x86_64_musl/kexec-tools-2.0.28' > x86_64-openwrt-linux-musl-gcc -mcmodel=large -I./purgatory/include > -I./purgatory/arch/x86_64/include -I./util_lib/include -I./include -Iinclude > -I/home/philipp/lede/staging_dir/toolchain-x86_64_gcc-13.2.0_musl/lib/gcc/x86_64-openwrt-linux-musl/13.2.0/include > -c -MD -o purgatory/arch/i386/entry32-16.o purgatory/arch/i386/entry32-16.S > purgatory/arch/i386/entry32-16.S: Assembler messages: > purgatory/arch/i386/entry32-16.S:23: Error: 64bit mode not supported on > `i386'. > make[4]: *** [Makefile:128: purgatory/arch/i386/entry32-16.o] Error 1 > make[4]: Leaving directory > '/home/philipp/lede/build_dir/target-x86_64_musl/kexec-tools-2.0.28' > make[3]: *** [Makefile:133: > /home/philipp/lede/build_dir/target-x86_64_musl/kexec-tools-2.0.28/.built] > Error 2 > make[3]: Leaving directory '/home/philipp/lede/package/boot/kexec-tools' > time: package/boot/kexec-tools/compile#0.23#0.07#0.27 > ERROR: package/boot/kexec-tools failed to build. > make[2]: *** [package/Makefile:129: package/boot/kexec-tools/compile] Error 1 > > I’m building for x86_64/generic on HEAD. > > Any ideas? And who is the maintainer for kexec-tools? > I feel this might be a straight regression from a kernel bump. I monitor the faillogs and kexec-tools appeared only recently... Would be good to understand what commit caused this. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Issues w/ kexec-tools when building images (redux)
The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header. To mitigate this problem, the original message has been wrapped automatically by the mailing list software.--- Begin Message --- Hi, Sorry, had to add filters to turn DMARC off when sending mailing list mail…. I fetched/rebased recently and now I’m not able to build images. It fails in kexec-tools, which is odd, because that’s not selected and nothing depends on it. philipp@ubuntu22:~/lede$ grep kexec-tools .config # CONFIG_PACKAGE_kexec-tools is not set philipp@ubuntu22:~/lede$ Here’s how the build reliably fails: make[3]: Entering directory '/home/philipp/lede/package/boot/kexec-tools' rm -f /home/philipp/lede/build_dir/target-x86_64_musl/kexec-tools-2.0.28/.built touch /home/philipp/lede/build_dir/target-x86_64_musl/kexec-tools-2.0.28/.built_check make -C /home/philipp/lede/build_dir/target-x86_64_musl/kexec-tools-2.0.28 DESTDIR="/home/philipp/lede/build_dir/target-x86_64_musl/kexec-tools-2.0.28/ipkg-install" all install make[4]: Entering directory '/home/philipp/lede/build_dir/target-x86_64_musl/kexec-tools-2.0.28' x86_64-openwrt-linux-musl-gcc -mcmodel=large -I./purgatory/include -I./purgatory/arch/x86_64/include -I./util_lib/include -I./include -Iinclude -I/home/philipp/lede/staging_dir/toolchain-x86_64_gcc-13.2.0_musl/lib/gcc/x86_64-openwrt-linux-musl/13.2.0/include -c -MD -o purgatory/arch/i386/entry32-16.o purgatory/arch/i386/entry32-16.S purgatory/arch/i386/entry32-16.S: Assembler messages: purgatory/arch/i386/entry32-16.S:23: Error: 64bit mode not supported on `i386'. make[4]: *** [Makefile:128: purgatory/arch/i386/entry32-16.o] Error 1 make[4]: Leaving directory '/home/philipp/lede/build_dir/target-x86_64_musl/kexec-tools-2.0.28' make[3]: *** [Makefile:133: /home/philipp/lede/build_dir/target-x86_64_musl/kexec-tools-2.0.28/.built] Error 2 make[3]: Leaving directory '/home/philipp/lede/package/boot/kexec-tools' time: package/boot/kexec-tools/compile#0.23#0.07#0.27 ERROR: package/boot/kexec-tools failed to build. make[2]: *** [package/Makefile:129: package/boot/kexec-tools/compile] Error 1 I’m building for x86_64/generic on HEAD. Any ideas? And who is the maintainer for kexec-tools? Thanks, -Philip --- End Message --- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Install LuCI for snapshots builds
On Tue, 7 May 2024 at 23:25, Paul Spooren wrote: > > Hi all, > > For some reason (resource usage?) our snapshot builds do not include the LuCI > web interface. I think it’s an advantage to have LuCI installed in snapshot > images since a) it installed for all releases anyway and b) often it’s just > nice to have the web interface directly available. > > Is anyone against having the interface installed by default? I remember from > multiple (in-person) discussion with fellow developers, that they’d prefer it > being installed. > > If it’s an oversight I’d like to see it added to the default packages (via > the builedbot config), if there’s a reason to keep it from snapshots, I’d > like to understand the details. +1 for LuCI by default in snapshots as well from me. Regards, Robert > > Thanks, > Paul > ___ > 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
Re: Install LuCI for snapshots builds
+1 - I endorse installing LuCI in snapshot builds. - A significant fraction of people will wind up installing LuCI anyway. - It's a FAQ on the forum. "I just installed a snapshot build, but there's no web GUI." (This even bites me from time to time...) - LuCI poses less of a space concern (in the days of 4MByte Flash, it might have made a difference - no more.) - People who're intentionally working on small Flash systems are rolling their own builds anyway. - It's one fewer configuration option in our build process Thanks for asking about this, Paul. Rich > On May 7, 2024, at 5:24 PM, Paul Spooren wrote: > > Hi all, > > For some reason (resource usage?) our snapshot builds do not include the LuCI > web interface. I think it’s an advantage to have LuCI installed in snapshot > images since a) it installed for all releases anyway and b) often it’s just > nice to have the web interface directly available. > > Is anyone against having the interface installed by default? I remember from > multiple (in-person) discussion with fellow developers, that they’d prefer it > being installed. > > If it’s an oversight I’d like to see it added to the default packages (via > the builedbot config), if there’s a reason to keep it from snapshots, I’d > like to understand the details. > > Thanks, > Paul > ___ > 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
Issues w/ kexec-tools when building images
The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header. To mitigate this problem, the original message has been wrapped automatically by the mailing list software.--- Begin Message --- Hi, I fetched/rebased recently and now I’m not able to build images. It fails in kexec-tools, which is odd, because that’s not selected and nothing depends on it. philipp@ubuntu22:~/lede$ grep kexec-tools .config # CONFIG_PACKAGE_kexec-tools is not set philipp@ubuntu22:~/lede$ Here’s how the build reliably fails: make[3]: Entering directory '/home/philipp/lede/package/boot/kexec-tools' rm -f /home/philipp/lede/build_dir/target-x86_64_musl/kexec-tools-2.0.28/.built touch /home/philipp/lede/build_dir/target-x86_64_musl/kexec-tools-2.0.28/.built_check make -C /home/philipp/lede/build_dir/target-x86_64_musl/kexec-tools-2.0.28 DESTDIR="/home/philipp/lede/build_dir/target-x86_64_musl/kexec-tools-2.0.28/ipkg-install" all install make[4]: Entering directory '/home/philipp/lede/build_dir/target-x86_64_musl/kexec-tools-2.0.28' x86_64-openwrt-linux-musl-gcc -mcmodel=large -I./purgatory/include -I./purgatory/arch/x86_64/include -I./util_lib/include -I./include -Iinclude -I/home/philipp/lede/staging_dir/toolchain-x86_64_gcc-13.2.0_musl/lib/gcc/x86_64-openwrt-linux-musl/13.2.0/include -c -MD -o purgatory/arch/i386/entry32-16.o purgatory/arch/i386/entry32-16.S purgatory/arch/i386/entry32-16.S: Assembler messages: purgatory/arch/i386/entry32-16.S:23: Error: 64bit mode not supported on `i386'. make[4]: *** [Makefile:128: purgatory/arch/i386/entry32-16.o] Error 1 make[4]: Leaving directory '/home/philipp/lede/build_dir/target-x86_64_musl/kexec-tools-2.0.28' make[3]: *** [Makefile:133: /home/philipp/lede/build_dir/target-x86_64_musl/kexec-tools-2.0.28/.built] Error 2 make[3]: Leaving directory '/home/philipp/lede/package/boot/kexec-tools' time: package/boot/kexec-tools/compile#0.23#0.07#0.27 ERROR: package/boot/kexec-tools failed to build. make[2]: *** [package/Makefile:129: package/boot/kexec-tools/compile] Error 1 I’m building for x86_64/generic on HEAD. Any ideas? And who is the maintainer for kexec-tools? Thanks, -Philip --- End Message --- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Install LuCI for snapshots builds
On Tue, May 07, 2024 at 11:24:32PM +0200, Paul Spooren wrote: > Hi all, > > For some reason (resource usage?) our snapshot builds do not include the LuCI > web interface. I think it’s an advantage to have LuCI installed in snapshot > images since a) it installed for all releases anyway and b) often it’s just > nice to have the web interface directly available. > > Is anyone against having the interface installed by default? I remember from > multiple (in-person) discussion with fellow developers, that they’d prefer it > being installed. > > If it’s an oversight I’d like to see it added to the default packages (via > the builedbot config), if there’s a reason to keep it from snapshots, I’d > like to understand the details. > Reason was probably when we supported very low memory device of 16/32 where it was a miracle the thing booted and could handle some traffic. uhttpd + luci was enough to make them run OOM. I didn't check how LOW SPACE device are handled and maybe this is already done, but maybe those device should not have the web ui preinstalled? I think another reason was to discourage people on using SNAPSHOT instead of STABLE release (since no luci and they had to use SSH from the start) Aside from the LOW SPACE thing to check, totally OK for me to add webui in SNAPSHOT image. -- Ansuel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Install LuCI for snapshots builds
Hi all, For some reason (resource usage?) our snapshot builds do not include the LuCI web interface. I think it’s an advantage to have LuCI installed in snapshot images since a) it installed for all releases anyway and b) often it’s just nice to have the web interface directly available. Is anyone against having the interface installed by default? I remember from multiple (in-person) discussion with fellow developers, that they’d prefer it being installed. If it’s an oversight I’d like to see it added to the default packages (via the builedbot config), if there’s a reason to keep it from snapshots, I’d like to understand the details. Thanks, Paul ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] ipq40xx: add PCIe magic hack to improve VRX518 compatibility
Il giorno mar 7 mag 2024 alle ore 18:53 Enrico Mioso ha scritto: > > Hello all!! > > is there any chance we can merge any form of this patch? > The device it is related seems pretty popular and one of the rare devices > supporting VDSL, 35B profile and with nice specs. > Even tough I can understand it is not desirable to maintain this patch > indefinitely should that be the case, I don't think leaving it out of OpenWrt > is the right answer. > Also due to the fact this seems, in my opinion, one of these things that can > act as barrier to entry for a typical setup (at least when VDSL is involved). > > Thanks a lot to all of you for your great work. > For everyone involved, I would really love if we can move here https://github.com/openwrt/openwrt/pull/15421 and test the alternative patch. It does have a different and more restricted approach. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Re: [PATCH] ramips: mt7621: add support for Keenetic Viva (KN-1910)
The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header. To mitigate this problem, the original message has been wrapped automatically by the mailing list software.--- Begin Message --- > I count 15 partitions in your dts not 17. There are 18 partitions in total (0 to 17). 15 in nand and 3 in virtual_flash. > What is /dev/mtd17 and how does the original partition table look like? This is from a running OpenWrt: root@OpenWrt:~# cat /proc/mtd dev:size erasesize name mtd0: 0008 0002 "U-Boot" mtd1: 0008 0002 "U-Config" mtd2: 0008 0002 "RF-EEPROM" mtd3: 01bc 0002 "Firmware_1" mtd4: 0008 0002 "Config_1" mtd5: 0020 0002 "Storage_Legacy" mtd6: 0004 0002 "Dump" mtd7: 01fc 0002 "Storage_A" mtd8: 0008 0002 "U-State" mtd9: 0008 0002 "U-Config_res" mtd10: 0008 0002 "RF-EEPROM_res" mtd11: 01bc 0002 "Firmware_2" mtd12: 0008 0002 "Config_2" mtd13: 0220 0002 "Storage_B" mtd14: 0008 0002 "unused" mtd15: 0040 0002 "kernel" mtd16: 0338 0002 "ubi" mtd17: 041c 0002 "storage" And the following is an excerpt from vendor's firmware log. mtd: creating 17 MTD partitions on "MT7621-NAND": 0x-0x0008 : "U-Boot" 0x0008-0x0010 : "U-Config" 0x0010-0x0018 : "RF-EEPROM" 0x0018-0x0036 : "Kernel_1" 0x0036-0x01d4 : "RootFS_1" mtd: device 4 (RootFS_1) set to be root filesystem 0x0018-0x01d4 : "Firmware_1" 0x01d4-0x01dc : "Config_1" 0x01dc-0x01fc : "Storage_Legacy" 0x01fc-0x0200 : "Dump" 0x0200-0x03fc : "Storage_A" 0x03fc-0x0404 : "U-State" 0x0404-0x040c : "U-Config_res" 0x040c-0x0414 : "RF-EEPROM_res" 0x0414-0x05d0 : "Firmware_2" 0x05d0-0x05d8 : "Config_2" 0x05d8-0x07f8 : "Storage_B" 0x-0x07f8 : "Full" ... Searching for suitable storage partitions... Found 1st storage partition of size 33292288 bytes Found 2nd storage partition of size 35651584 bytes Registering UBI data partitions parser Concatenating MTD devices: (0): "Storage_A" (1): "Storage_B" into device "NDM combined UBI partition" 1 ndmubipart partitions found on MTD device NDM combined UBI partition mtd: creating 1 MTD partitions on "NDM combined UBI partition": 0x-0x041c : "Storage" Merging storage partitions OK I have omitted overlapping partitions from dts. Otherwise the layout is identical. /dev/mtd17 "storage" in OpenWrt is the same as vendor's "Storage". --- End Message --- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] ipq40xx: add PCIe magic hack to improve VRX518 compatibility
Hello all!! is there any chance we can merge any form of this patch? The device it is related seems pretty popular and one of the rare devices supporting VDSL, 35B profile and with nice specs. Even tough I can understand it is not desirable to maintain this patch indefinitely should that be the case, I don't think leaving it out of OpenWrt is the right answer. Also due to the fact this seems, in my opinion, one of these things that can act as barrier to entry for a typical setup (at least when VDSL is involved). Thanks a lot to all of you for your great work. Enrico ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 2/2] realtek: add RTL821X_CHIP_ID
On Tue, 7 May 2024 at 12:16, Bjørn Mork wrote: > > Stijn Tintel writes: > > > On 27/04/2024 11:16, Bjørn Mork wrote: > >> st...@linux-ipv6.be writes: > >> > >>> phy_write_paged(phydev, 31, 27, 0x0002); > >>> val = phy_read_paged(phydev, 31, 28); > >> .. > >>> phy_write_paged(phydev, 0x1f, 0x1b, 0x0002); > >>> val = phy_read_paged(phydev, 0x1f, 0x1c); > >> > >> While you're doing spring cleaning That piece of cut-n-paste code > >> looks very funny. > >> > > I'd gladly do some more spring cleaning, but what's your actual > > suggestion here? Use hex everywhere instead of mixed hex/base 10? > > I would have used hex since that 0x1f looks like a mask. We can find out if we look at the function signature: int phy_read_paged(struct phy_device *phydev, int page, u32 regnum); so that's a page, not a mask. Upstream usage is mostly hex, with the icplus phy driver being the sole exception. And unsurprisingly, realtek drivers always use magic numbers, never defines. Can't have other people understand how the hardware works. Best Regards, Jonas ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] ramips: mt7621: add support for Keenetic Viva (KN-1910)
The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header. To mitigate this problem, the original message has been wrapped automatically by the mailing list software.--- Begin Message --- I count 15 partitions in your dts not 17. What is /dev/mtd17 and how does the original partition table look like? Regards Felix Baumann --- End Message --- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] ramips: mt7621: add support for Keenetic Viva (KN-1910)
The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.
To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
From: Andrew Worn
SoC : MediaTek MT7621A
RAM : 128M DDR3
Flash : 128M NAND
Switch: MT7530, 5 ports 1Gbps
WiFi : MT7615DN, 2.4GHz n and 5GHz ac
USB : 2 ports USB 2.0
GPIO : 4 buttons, 4 LEDs, USB port power controls
LAN : RF-EEPROM + 0x04
WAN : RF-EEPROM + 0x28
2.4GHz: RF-EEPROM + 0x04
5GHz : 2.4GHz + 82:00:00:00:00:00
1. Connect to a LAN port, configure interface to use 192.168.1.2/30
2. Serve the factory image renamed to KN-1910_recovery.bin via TFTP
3. Power up the router while pressing Restart button on the back
4. Release Restart button when Power LED starts blinking
Keenetic's bootloader supports booting a LZMA compressed kernel but
seems to fail if the uncompressed data is larger than a fixed buffer
therefore it is safer to use a uimage-lzma-loader
Vendor firmware uses around half of flash for a writable UBIFS partition
that is preserved here. It may be accessed with the following commands:
ubiattach -p /dev/mtd17
mount -t ubifs /dev/ubi1_0 /mnt/
Signed-off-by: Andrew Worn
---
diff --git a/target/linux/ramips/dts/mt7621_keenetic_kn-1910.dts
b/target/linux/ramips/dts/mt7621_keenetic_kn-1910.dts
new file mode 100644
index 00..1717d274a8
--- /dev/null
+++ b/target/linux/ramips/dts/mt7621_keenetic_kn-1910.dts
@@ -0,0 +1,271 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+#include "mt7621.dtsi"
+
+#include
+#include
+
+/ {
+ compatible = "keenetic,kn-1910", "mediatek,mt7621-soc";
+ model = "Keenetic KN-1910";
+
+ aliases {
+ led-boot = _power;
+ led-failsafe = _power;
+ led-running = _power;
+ led-upgrade = _power;
+ label-mac-device =
+ };
+
+ gpio_export {
+ compatible = "gpio-export";
+ #size-cells = <0>;
+
+ left_usb_power {
+ gpio-export,name = "left-usb:power";
+ gpio-export,output = <1>;
+ gpios = < 5 GPIO_ACTIVE_HIGH>;
+ };
+
+ right_usb_power {
+ gpio-export,name = "right-usb:power";
+ gpio-export,output = <1>;
+ gpios = < 11 GPIO_ACTIVE_HIGH>;
+ };
+ };
+
+ keys {
+ compatible = "gpio-keys";
+
+ restart {
+ label = "restart";
+ gpios = < 6 GPIO_ACTIVE_LOW>;
+ linux,code = ;
+ };
+
+ wps {
+ label = "wps";
+ gpios = < 12 GPIO_ACTIVE_LOW>;
+ linux,code = ;
+ };
+
+ fn1 {
+ label = "fn1";
+ gpios = < 10 GPIO_ACTIVE_LOW>;
+ linux,code = ;
+ };
+
+ fn2 {
+ label = "fn2";
+ gpios = < 7 GPIO_ACTIVE_LOW>;
+ linux,code = ;
+ };
+ };
+
+ leds {
+ compatible = "gpio-leds";
+
+ led_power: power {
+ label = "green:power";
+ gpios = < 9 GPIO_ACTIVE_HIGH>;
+ };
+
+ internet {
+ label = "green:internet";
+ gpios = < 17 GPIO_ACTIVE_HIGH>;
+ };
+
+ fn {
+ label = "green:fn";
+ gpios = < 13 GPIO_ACTIVE_HIGH>;
+ };
+
+ wifi {
+ label = "green:wifi";
+ gpios = < 15 GPIO_ACTIVE_HIGH>;
+ };
+ };
+
+ virtual_flash {
+ compatible = "mtd-concat";
+ devices = <_1>, <_2>, <_a>,
<_b>;
+
+ partitions {
+ compatible = "fixed-partitions";
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ partition@0 {
+ label = "kernel";
+ reg = <0x0 0x40>;
+ };
+
+ partition@40 {
+ label = "ubi";
+ reg = <0x40 0x338>;
+ };
+
+ partition@378 {
+ label = "storage";
+ reg = <0x378 0x41c>;
+ };
+ };
+ };
+};
+
+ {
+ status = "okay";
+
+ partitions {
+ compatible = "fixed-partitions";
+ #address-cells = <1>;
+
Re: [PATCH 1/2] realtek/rtl839x: respect phy-is-integrated property
The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header. To mitigate this problem, the original message has been wrapped automatically by the mailing list software.--- Begin Message --- Hi, On 27/04/2024 00:40, st...@linux-ipv6.be wrote: Respect the phy-is-integrated property on ethernet-phy nodes. There are RTL8393M switches where the PHYs at address 48 and 49 are provided by an external RTL8214FC. Hardcoding them to use the internal SerDes makes it impossible to use the ports connected to such an external PHY. Respect the phy-is-integrated property on ethernet-phy nodes as a first step to support such ports. The potential impact for this should be limited to RTL8393 based switches, and looking at the commit messages and device tree files of the supported switches based on this SoC, the SFP and/or combo ports are either not working (D-Link DGS-1210-52, Netgear GS750E, TP-Link SG2452P/T1600G-52PS), use PHYs at a different address (Panasonic SwitchM48EG PN28480K), or already have the phy-is-integrated property set on the PHYs at address 48 and 49. Some time ago, Jan Hoffmann has been working on support for the HPE 1920-48G switch. He came up with a very similar patch and also with patches for the RTL8214FC. I'm using his version for quite some time now on my HPE switch. Here is his commit: https://github.com/janh/openwrt/commit/ee5d8a17b540a3a9aa7b666a679b479903799d10 Unfortunately, there are so many different patches floating around, scattered across different forks, it's hard to know who has done what. Andreas --- End Message --- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 2/2] realtek: add RTL821X_CHIP_ID
Stijn Tintel writes: > On 27/04/2024 11:16, Bjørn Mork wrote: >> st...@linux-ipv6.be writes: >> >>> phy_write_paged(phydev, 31, 27, 0x0002); >>> val = phy_read_paged(phydev, 31, 28); >> .. >>> phy_write_paged(phydev, 0x1f, 0x1b, 0x0002); >>> val = phy_read_paged(phydev, 0x1f, 0x1c); >> >> While you're doing spring cleaning That piece of cut-n-paste code >> looks very funny. >> > I'd gladly do some more spring cleaning, but what's your actual > suggestion here? Use hex everywhere instead of mixed hex/base 10? I would have used hex since that 0x1f looks like a mask. But it should at least be consistent so that it is obvious that this code is a target for de-duplication. Bjørn ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 2/2] realtek: add RTL821X_CHIP_ID
On 27/04/2024 11:16, Bjørn Mork wrote: st...@linux-ipv6.be writes: phy_write_paged(phydev, 31, 27, 0x0002); val = phy_read_paged(phydev, 31, 28); .. phy_write_paged(phydev, 0x1f, 0x1b, 0x0002); val = phy_read_paged(phydev, 0x1f, 0x1c); While you're doing spring cleaning That piece of cut-n-paste code looks very funny. I'd gladly do some more spring cleaning, but what's your actual suggestion here? Use hex everywhere instead of mixed hex/base 10? Thanks, Stijn ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH qca-wireless] ipq6018: add BDF for Edgecore EAP101
Taken from TIP OpenWiFi:
https://github.com/Telecominfraproject/wlan-ap/raw/88d6633c85acd4143cfcb1f0a4fdcfdc88f35f3e/feeds/ipq807x_v5.4/ath11k-wifi/board-edgecore-eap101.bin.IPQ6018
Signed-off-by: Stijn Tintel
---
board-edgecore_eap101.ipq6018 | Bin 0 -> 65644 bytes
1 file changed, 0 insertions(+), 0 deletions(-)
create mode 100644 board-edgecore_eap101.ipq6018
diff --git a/board-edgecore_eap101.ipq6018 b/board-edgecore_eap101.ipq6018
new file mode 100644
index
..1c8cfc15ba8d3164a843b242a842caabb9bb075f
GIT binary patch
literal 65644
zcmeHQ3wTu3o(5fB*SF#AcQ1@BtXD`yx)0|ggi|qA!Tlt)1#FI~1
zA|fhQY=Qdd@?rI(ZkOGy)~>s4t<`O9wcCDe)fU^@$9}HzZS8*6?C*E)+?ktXCYb~h
z1D-R#xpRK!od5s)&+nXj=gv*$U2R)2CNWEv_qSD3z^Sw+d3dXnc{yc&^#C
zW6|o3YYJ}Ox@qd#jhou1Zd$jf&|qt}t=_(lbjGY%1-n;o-?aLsor~75+pvD^w(aYu
zu3z0gy>R;0t)?dp9-U6ZseDkWY2vueJ+s-^t}wPO#StAzsr0y2eRgmS
zhzfSDIigMSFkj{bD^%{2t$;2*V{J9Ldg|a1N6*4AC3>*@l%)JM<*z}0S#xJ>9no=r
zVq|-p`6>C!2Y>m1g@ceB5@+jb5IP9sa^Lrtz9O$a|JuHvE{b-y#mCLmOAA#s
z5Cxo)?tj1SZjE=}K9i<>Abj?gGUPU<-kJ>ix=6IpwZGy#qxa*B=PJ;m`(#zu`
zTDP&|$g$%mPCok8vrj*B{@HK;$BQp_Yp6xV#KgoJh>mtfMUMcDiAG_!b_1Yo1F%sh
z5h>u3=Z*IZ4Qm^F0Uv=Bsw_~cGD?AAqCk|id@ScY!({j>j6qajgq$_KRQ0YqWF}(n0&4L~_
zMZiW9$$njA{I^8LJ}Q!YK*W86NPLk<^k{rG`9)`+eP+ETlJTra+E+xpuup`2+$`89
z!Tv(u_Us_*M~LCu{uu6nj~4hqw9yIh@yot_WMK?}7-(S+D!ye+vmq}B?7Po*VD_%;^~o!OWk>G*)ZPVK^FHmV43^z-Y{eaOc6V)e;>g;4
zOWL#Byj8(=hmT{kR_xJN|%DExAHdyw+y{q>x+L61)W3#>MaP!^;
z?YXN`t_!w%_~^RZm+Z`6Yj1bYk=A{*O>GRe`||zudy97GulLjh%T(^t6lgzmI{3!(
z?xp!s)>n@L)eS9cHg+66ar*4J^UuEUvUOq}c+JD*wCu-mUWfCTv>S1bj(yUD^Xmkh
z3)WD!c0yq92)bNlgMz`5;a5grdbI3G*ExlsIwP!>JQ^8OR&=s2g$_!}9p
zb5DkkvG5VsvwioHydRh`WZ---Z5`}!obp@?dz_!gM|c@9_j_StNQaM6-FxiGd$U
z7;sM5uNYoL3^>2fIEZm<^6M}KJ|d0b75`k~b5h!R+g#$@IzF~%%%Muc>d>FLz`1<}
zW8hp+2d<}n%tb!Of%P!{5Y`mdLrNWd6v7ABlq*!!UCZ(?m)R#_4;>AAyq9^dfxR2{
zj;?LPF~bMuV*Fk3fw@S*nlxg-=gxTBADYA2a|{#kS#Lbn^wS`Q!CzmulI
z2adG~(GlptxxjuAm<#L|##~^(N{I0I(04C`-{O%kuRUD2JNKp(Tobd>xkq>1H+N6Y
zX0PqJ2EXH+ZoI
ztn~2l)dv^elDi?r7T=j;n-9$TOxE>D%dJ)-#~!@po_V_`-k97REPL$e#{JiB%53#i
z1k1j5qW$h!JF?d%Vy#-~{=09vbKaJTD^qYhv(lpvZ~DTu+w(WuHGSsT$yu3X
zYj^7ShC?&9kMpSA2b)5PmjCMUcdC=?it_R2
zd!(F+ITrAZIPKjwv^T%o5uf1h9(vBi+`Rlrlcy9+jc5!G8G{i_mYK3Zils_?vQpN`
z7TF-}D9_1vapcUc3-j@>
z6i5Y=C+Fvw$r!_oz!>~Zue_Hl`tOJtLA~SR;(}y&^S+%i+PuruC#Hhc$ET50j0pztiVY5rZK!3oxMMNt2
z`t-9e_TFknXQ+1g3i6;y7$+z2pX?$lTUvZbc;$=Fhu3t?x+MMxwWBqZCjICCIEkAAA5+wVUe901zr~B3@UXql=SNqm17sSR}KO;~r*b{PyQ4pi}V+_M>3|CbWH*@$L#vOqcN%GV>`JZw`Y*uN|KY4QDSZr6BCg)
zx80fr=(usr+P8tKkQoSq`_Ez-hS9_UO~0Zs7ip@{>UIG~9mj3#>y-Dmv4XU}cs
zTG-=X68J2f%V#eBCn;2595J69ZKx4*rmbfv`>r#0`B|tw2U2$VBkRA%fy6zSHvJ#L
z<+m8j@eRcHYs%kd36VFh8ZGNcbpGVDq>zWF;_;od?f28EuWw7%@i(g)%W)5
z`hsy^V^pe3f4_sRWez!?mwKJ1w)v;_WntuN
z4}UjA**AKWWd|mw?x|F_#Qj;sOuS?N(
zC~dDqZHF@Ep`43L>1!x8xf1)j6m6BQQee0#5HA;uy9IQ<66bN~>+qfW(}I5{kOv<;
zb&9c`$H(t*dHYx_`<9N^24??soTulRx4j3IR|+TvlmbeDfhaIqE}FL$iom$t{bAhS
zVh*~W8ufDQLH8Tjz8CxZ5%nWGqwmD?Pp)L+?kjyey4^i?RATJI?pH>=h3!Y!CXW1Y
z#I})RVjja|+KnZZR2mY?>@d#>3uvFYem3SC$x$^?&>NM_>P_wKMp5vXc*c
z`$+Pp57YJuX~e_qJrY~hX80;loVYsfR|)syIcL=F*zd-^8{0EhbMB?bjGOCB#9U)N
z?O0;2yI`HUc7nXO+*08~C8dB;Kq;UUPzopolmbctrGQdEDWDWk3Md7X0-rnu62uw7
