Re: [PATCH 3/3] arm64: dts: mediatek: Add OpenWrt One
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 ---
On 27/05/2024 13:59, Rafał Miłecki wrote:
From: Rafał Miłecki
OpenWrt One is the first ever OpenWrt product. It's based on MT7981B
(AKA Filogic 820) and has 1 GiB or DDR4 RAM. The rest of peripherals
or -> of
remains to be added later.
Signed-off-by: Rafał Miłecki
---
arch/arm64/boot/dts/mediatek/Makefile | 1 +
.../boot/dts/mediatek/mt7981b-openwrt-one.dts | 15 +++
2 files changed, 16 insertions(+)
create mode 100644 arch/arm64/boot/dts/mediatek/mt7981b-openwrt-one.dts
diff --git a/arch/arm64/boot/dts/mediatek/Makefile
b/arch/arm64/boot/dts/mediatek/Makefile
index 12f67959f257..06f960002ac2 100644
--- a/arch/arm64/boot/dts/mediatek/Makefile
+++ b/arch/arm64/boot/dts/mediatek/Makefile
@@ -9,6 +9,7 @@ dtb-$(CONFIG_ARCH_MEDIATEK) += mt6797-x20-dev.dtb
dtb-$(CONFIG_ARCH_MEDIATEK) += mt7622-rfb1.dtb
dtb-$(CONFIG_ARCH_MEDIATEK) += mt7622-bananapi-bpi-r64.dtb
dtb-$(CONFIG_ARCH_MEDIATEK) += mt7981b-cudy-wr3000-v1.dtb
+dtb-$(CONFIG_ARCH_MEDIATEK) += mt7981b-openwrt-one.dtb
dtb-$(CONFIG_ARCH_MEDIATEK) += mt7981b-xiaomi-ax3000t.dtb
dtb-$(CONFIG_ARCH_MEDIATEK) += mt7986a-acelink-ew-7886cax.dtb
dtb-$(CONFIG_ARCH_MEDIATEK) += mt7986a-bananapi-bpi-r3.dtb
diff --git a/arch/arm64/boot/dts/mediatek/mt7981b-openwrt-one.dts
b/arch/arm64/boot/dts/mediatek/mt7981b-openwrt-one.dts
new file mode 100644
index ..4f6cbb491287
--- /dev/null
+++ b/arch/arm64/boot/dts/mediatek/mt7981b-openwrt-one.dts
@@ -0,0 +1,15 @@
+// SPDX-License-Identifier: GPL-2.0-only OR MIT
+
+/dts-v1/;
+
+#include "mt7981b.dtsi"
+
+/ {
+ compatible = "openwrt,one", "mediatek,mt7981b";
+ model = "OpenWrt One";
+
+ memory@4000 {
+ reg = <0 0x4000 0 0x4000>;
+ device_type = "memory";
+ };
+};
--- End Message ---
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: OpenWrt One - celebrating 20 years of OpenWrt
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 --- On 2024-02-27 10:16, Bas Mevissen wrote: (former one escaped too quickly, please ignore) On 2024-02-26 22:38, Paul D wrote: On 2024-02-26 19:39, John Crispin wrote: Hi Rafał, Is there any update / schedule you could share? I have been meaning to send an update for a few days. Thanks for reminding me. I'm really looking forward to this device. yeah, me too ;) Lots of stuff has been happening. There was a short break due to the lunar new year but we are picking up pace again. *) schematics are done Can it be shared already? I'm wondering whether some peripheral port can easily be used to configure an external switch chip. I would like not to have to use the mbus for that. *) PCB is mostly routed (https://nbd.name/one-top.jpg https://nbd.name/one-bottom.png) If there is no price difference, can we have 90 degree angled pins for GND+TX+RX serial header, so the pins face away from the board as USB sockets do, and not stand up perpendicularly. This way serial consoles are workable even when device is in a case. Does anyone else have opinions on this? I think the console USB connector is intended for that. *) there was a small hiccup in registering the OUI block that we are currently resolving *) the trademark agreement is being worked on - I have a call with SFC tomorrow to discuss this I am expecting that the first 15 PCBA samples will be produced shortly and be shipped by end of march. as for the software side, I modified a mt7981 RFB to have dual flash, mikrobus, s.T. I could build and test dts files. I ordered the RTC used on a carrier board and was able to test it. all the u-boot patches are pretty much done. there is a pretty elaborate uboot-env with lots of commands to provide easy un-brickability. I have a local OpenWrt tree with ~10 patches that I hope to send as a RFC later this week. the PCB will probably be light blue (PANTONE 306 C) which is the light blue used inside the OpenWrt logo. we are still figuring this out with the supplier. In 20 years when these devices are old and need recycling, how recyclable are the PCBs? What substances go into it? Toxic ones? The color pigment is probably not the biggest concern... I should probably start building a page inside the wiki to provide better visibility into what is happening. Would be great. But this mail was already great to read about the progress! shout out to pepe2k, SFC and MTK for the never ending support that they provide on this journey. And an extra big thank you to Simon, the designer/engineer from BPi that has been ultra cool in making this become a reality John Agree! Bas. ___ 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: OpenWrt One - celebrating 20 years of OpenWrt
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 --- On 2024-02-26 22:38, Paul D wrote: On 2024-02-26 19:39, John Crispin wrote: Hi Rafał, Is there any update / schedule you could share? I have been meaning to send an update for a few days. Thanks for reminding me. I'm really looking forward to this device. yeah, me too ;) Lots of stuff has been happening. There was a short break due to the lunar new year but we are picking up pace again. *) schematics are done Can it be shared already? I'm wondering whether some peripheral port can easily be used to configure an external switch chip. I w *) PCB is mostly routed (https://nbd.name/one-top.jpg https://nbd.name/one-bottom.png) If there is no price difference, can we have 90 degree angled pins for GND+TX+RX serial header, so the pins face away from the board as USB sockets do, and not stand up perpendicularly. This way serial consoles are workable even when device is in a case. Does anyone else have opinions on this? I think the console USB connector is intended for that. *) there was a small hiccup in registering the OUI block that we are currently resolving *) the trademark agreement is being worked on - I have a call with SFC tomorrow to discuss this I am expecting that the first 15 PCBA samples will be produced shortly and be shipped by end of march. as for the software side, I modified a mt7981 RFB to have dual flash, mikrobus, s.T. I could build and test dts files. I ordered the RTC used on a carrier board and was able to test it. all the u-boot patches are pretty much done. there is a pretty elaborate uboot-env with lots of commands to provide easy un-brickability. I have a local OpenWrt tree with ~10 patches that I hope to send as a RFC later this week. the PCB will probably be light blue (PANTONE 306 C) which is the light blue used inside the OpenWrt logo. we are still figuring this out with the supplier. In 20 years when these devices are old and need recycling, how recyclable are the PCBs? What substances go into it? Toxic ones? I should probably start building a page inside the wiki to provide better visibility into what is happening. shout out to pepe2k, SFC and MTK for the never ending support that they provide on this journey. And an extra big thank you to Simon, the designer/engineer from BPi that has been ultra cool in making this become a reality John ___ 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: OpenWrt One - celebrating 20 years of OpenWrt
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 --- On 2024-01-17 16:21, John Crispin wrote: Additional FAQ for OpenWrt One This is a summary of some further questions regarding the OpenWrt One project gathered so far. After OpenWrt voted to move forward, it will be converted into a page within the OpenWrt wiki as a place for collecting the latest information. Q: Will the various hardware buttons and switches be fully exposed on the outside? A: The latest iteration of the design will fully expose all buttons and switches. Q: Will there be an option to purchase preassembled kits? A: We're considering that option but still need to explore possibilities with the manufacturer. Q: When do you expect general availability? A: Once we vote to move forward, it will take around 45 days until the first PCBA engineering samples get shipped. These will be passed on to developers for testing. Once they are verified it will probably take another 30-45 days until they can be ordered. So we are looking at April timeframe. Q: What kind of power supply is needed? A: While the initial announcement imprecisely referred to the power supply as "USB-PD 12V" the PCB will draw its required power from a USB-C PD 3.0/2.0 source. Q: Why does the current design not feature any USB 3.0 connectivity? A: USB 3.0 always has the risk of interference with 2.4 GHz Wi-Fi. We would like to reduce risk as much as possible. Interference proofing the board would add considerable complexity and costs. Q: Why did you implement a M.2 slot? A: After careful consideration we came to the conclusion that directly exposing a PCIe 1x lane in the form of an M.2 slot provides the most flexibility for potential expansions. It can be used for NVMe storage (up to 2242 when using an enclosure), e.g. to host containers or media files. It also enables the simple use of other, non-OpenWrt distributions with larger storage footprints. Q: Why is there no consideration for Wi-Fi 6E/7 (6GHz / Tri-Band)? A: Neither is the mac80211 upstream support for Wi-Fi 7 complete, nor is there a fully integrated tri-band SoC solution available right now, let alone fully or partially supported upstream. Supporting Wi-Fi 7 would drastically increase the overall costs and make it impossible to deliver sufficient software support in the foreseeable future. Q: Why are there only two ethernet ports? A: We didn't want to impose additional complexity and costs by including an external managed switch IC. One port is 1GBit/s capable, while the other features a speed up to 2.5GBit/s. This is a limitation of the chosen SoC. Makes sense. Most people already have additional switches at home to accommodate more than the typically 4-5 ports router have. Will there be no limitation on which of the ports is the WAN or the LAN (e.g. due to offloading)? Would it be an idea to have a connector with SPI/I2C, power and preferably direct access to the media interface to be able to connect your own switch board? Then you can still control the switch from OpenWRT. Q: Why should I get the One? There are more capable, more featured devices available! A: The OpenWrt One is intended to serve as a robust and simple educational platform for OpenWrt enthusiasts, it is neither intended to be a competitor to off the shelf SOHO routers nor do we aim for the largest possible amount of features. It also serves as a donation vehicle for the OpenWrt project. Q: Does that mean that OpenWrt will stop supporting other hardware? A: There is no intention at all to change the way OpenWrt operates or how it implements and supports current and future hardware. The OpenWrt One device will be supported as one device among many others and receive the same level of support. Q: Doesn't this draw attention away from properly supporting existing devices? A: The OpenWrt One project is a privately led initiative by a few enthusiasts, there is no intent to change the focus of the OpenWrt project in any way. ___ 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: OpenWrt One - celebrating 20 years of OpenWrt
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 --- On 09/01/2024 11:49, John Crispin wrote: This is our first design, so let's KiSS! Agreed, however as it needs to last for a long period of time, it should not be too under powered. Hardwarespecifications: * SOC: MediaTek MT7981B * Wi-Fi: MediaTek MT7976C (2x2 2.4 GHz + 3x3/2x2 + zero-wait DFS 5Ghz) Was the MT7986AV, MT7976DA combo considered? Has 4x4 for office applications (MU-MIMO), so might be useful for corporate or soho use. It also has more horse power to run some local services * DRAM: 1 GiB DDR4 What's the price difference with 2GB? For home automation purposes and other virtualisation applications it might come in handy. * Flash: 128 MiB SPI NAND+ 4 MiB SPI NOR * Ethernet: 2x RJ45 (2.5 GbE + 1 GbE) * USB (host): USB 2.0 (Type-A port) * USB (device, console): Holtek HT42B534-2 UART to USB (USB-C port) Great idea! * Storage: M.2 2042 for NVMe SSD (PCIe gen 2 x1) * Buttons: 2x (reset + user) * Mechanical switch: 1x for boot selection (recovery, regular) * LEDs: 2x (PWM driven), 2x ETH Led (GPIO driven) * External hardware watchdog: EM Microelectronic EM6324 (GPIO driven) * RTC: NXP PCF8563TS (I2C) with battery backup holder(CR1220) * Power: USB-PD-12V on USB-C port (optional802.3at/afPoE via RT5040 module) * Expansion slots: mikroBUS * Certification: FCC/EC/RoHS compliance * Case: PCB size is compatible to BPi-R4 and the case design can be re-used * JTAG for main SOC: 10-pin 1.27 mm pitch (ARM JTAG/SWD) Nice to have the connector, would be great if a supported USB JTAG adapter could be supplied as an option. * Antenna connectors: 3x MMCX for easy usage, assembly and durability * Schematics: these will be publicly available (license TBD) * GPL compliance: 3b. "Accompany it with a written offer ... to give any third party ... a complete machine-readable copy of the corresponding source code" * Price: aiming for below 100$ Or just have 1 or 2 existing Banana Pi boards with OpenWRT branding? The schematics are not really making much difference for most people. Having all SW FOSS does. Bas. --- End Message --- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: mt7621 GPIO mapping mystery
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 --- On 2023-01-21 22:42, Lukas Zeller wrote: Hi Tomasz, thanks a lot for that hint to dtbocfg and the makefile! On 21 Jan 2023, at 17:27, Tomasz Maciej Nowak wrote: [...] W dniu 21.01.2023 o 16:33, Lukas Zeller pisze: So basically, I'm suggesting to revisit the decision to reject the patch from Daniel Golle [1]. Instead of doing it the hard way of patching, why not using out-of-tree kernel module[2] for loading dtb overlay with configfs? It already exists for some time. That really looks like a great solution with all advantages combined! I agree this is better than patching, I just did not realize it was possible at all to modularize dt overlay functionality this way. It is a thing very commonly done on RPi "hats" to change the pin config on the extension header. You may find some documentation and examples there that may help you. [...] Unfortunately I didn't test it, as the board I wanted to use it has gone in flames. For ready to use recipe see the attachment. Feel free to submit it to packages feed and take over maintainership after giving it a test. I will certainly try that, as soon as I find some time for it, but that's not likely to happen before ~March, unfortunately... [...] 2. https://github.com/ikwzm/dtbocfg Lukas ___ 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: [PATCH] x86: use mkfs.fat, sed, mmd and mcopy from staging_dir
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 --- On 2023-01-20 13:24, Florian Eckert wrote: On 2023-01-20 12:49, Felix Fietkau wrote: On 20.01.23 12:42, Florian Eckert wrote: Hello Felix, During image generation, the host tools should not be used but the tools from the staging_dir. - mkfs.fat - sed - mmd - mcopy Why is this necessary? $STAGING_DIR_HOST/bin should already be in $PATH before the host system parts. I only noticed that the prefix $(STAGING_DIR_HOST) is missing for these tools on x86_64 image Makefile. If I look for this prefix in OpenWrt, it is found in some image Makefiles commands. For examples: - https://github.com/openwrt/openwrt/blob/master/target/linux/realtek/image/Makefile - https://github.com/openwrt/openwrt/blob/master/target/linux/bcm63xx/image/Makefile - https://github.com/openwrt/openwrt/blob/master/target/linux/ath25/image/Makefile If this is in the PATH through this line https://github.com/openwrt/openwrt/blob/master/Makefile, then this is not needed for the others? I only wanted to unify this with the change and make it clear that the tool from staging is used here. Thanks. I don't have a strong opinion one way or the other, but I think the code might be more readable without the explicit $(STAGING_DIR_HOST)/bin prefix. Your right It works regardless of whether the prefix is there or not. But I would just like to note that it is easier to see whether the tools are now used from staging or the build host. The tool mkisofs https://github.com/openwrt/openwrt/blob/master/target/linux/x86/image/Makefile#L100, for example, is used from the build host! There is indeed a guard here https://github.com/openwrt/openwrt/blob/master/target/linux/x86/Makefile. But I am not sure if this is the case everywhere and if it is clear to everyone which tool is now being used during development. I just wanted to say that I am more in favor of explicitly select which tool is now being used. I think the actual tool used should be in a variable, like $(STAGING_HOST_SED). This is very readable and it also makes the list of tools used explicitly known. The PATH must still be set for tools to find other staging dir tools. Actually, the host path should be unset to avoid inadvertently using the host tools instead of the one of the staging dir. I personally would prefer using a chroot-ed staging host to avoid any host interference. Regards, Bas. --- End Message --- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: DSA Terminology
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 --- On 2022-09-13 21:56, Jo-Philipp Wich wrote: Hi, IMHO changing, in /etc/config/network: "config interface" -> "config network" "config device" -> "config interface" would eliminate this semantic inconsistency and bring the naming convention more in line with what Rich referred to in his comments above. This cannot be done in a sane manner though as it would render future versions entirely backwards incompatible. Renaming `config interface` to `config network` makes sense and can be implemented easily. However we would still need to treat `config interface` as synonym for it in the forseeable future in order to retain compatibility, which means that we cannot reuse `interface` for something else. So changing `config interface` to `config network` would be possible assuming that `config device` remains `config device` (or is renamed to something other than `interface`). At the same time, the `wifi-iface` section type in /e/c/network should be changed to `wifi-network` in order to remain consistent. When you are at this level of changes and redefining and reusing names, normally it is time to reconsider the complete thing. I would suggest something like a JSON file based config with versioning so that later changes can be done in a forward compatible way. With some clever scripts, not too exotic existing configurations can be converted automatically, just like was done with the switch to DSA. Just my 2 cents.. Bas. ~ Jo ___ 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: [PATCH] build: always set CONFIG_IPV6
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 --- On 8/18/22 20:32, Robert Marko wrote: On Thu, 18 Aug 2022 at 20:07, Enrico Mioso wrote: Hello all!! In my opinion, it would be better to try keeping this option available. Surely, !IPV6 is not a common scenario these days. But I think OpenWrt might be useful to catch bugs like the one fixed in commit 77fc73ac89be96ec8f39e8efa53885caa7cb3645 in the Linux kernel's git tree. So, for what it's worth, a NACKfrom me. It's becoming increasingly hard to impossible to disable IPv6 in all of the SW that OpenWrt ships, that is the reason for this. More and more SW just doesn't have a way to disable IPv6 at all, so unless we want to carry even more patches this is kind of inevitable. It is 2022 after all, so ACK from me for what it's worth. Would it make sense to simply always build with IPV6 support and have the CONFIG_IPV6 flag repurposed to have the defaults for the network interfaces and kernel sysctls set to disable IPV6 as much as possible? This might make sense in environments where any IPV6 support is unwanted. Still many people have no IPV6 at home or at work and hence better not have it configured at their local network nor router. Rewgards, Bas. Regards, Robert Enrico On Thu, 18 Aug 2022, Paul Spooren wrote: Date: Thu, 18 Aug 2022 17:33:42 From: Paul Spooren To: Stijn Tintel Cc: Thibaut , openwrt-devel Subject: Re: [PATCH] build: always set CONFIG_IPV6 On 18. Aug 2022, at 16:07, Stijn Tintel wrote: On 18/08/2022 17:03, Thibaut wrote: Le 18 août 2022 à 15:40, Stijn Tintel a écrit : On 16/08/2022 20:00, Thibaut VARÈNE wrote: Disabling this build tunable breaks build and seems unrealistically likely to be fixed. This patch sets the related CONFIG to always true and removes the config prompt, keeping the change minimal, and, should !CONFIG_IPV6 ever be fixed, easy to revert. If we're always going to set it to yes, just drop the option entirely and enable it in the generic kernel configs. Aside from that: CONFIG_IPV6 is not a kernel config, it’s a tree-wide one. My idea was to keep the change as small as possible should we ever want to revert, while preventing further pointless bugreports[1]. Entirely removing the config option requires more invasive changes throughout the tree and the package repositories, which is significantly less trivial than this "first step". Cheers, Thibaut [1] https://github.com/openwrt/openwrt/issues/9580 OK, in that case, let's await at least one more ACK and we can start with this. Per request: Acked-by: Paul Spooren Thanks, Stijn ___ 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 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 --- End Message --- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [sdwalker/sdwalker.github.io] 2bdb42: This week's update
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 --- On 13/05/2022 01:59, Sergey Ryazanov wrote: Hello Jeffery, On Fri, May 13, 2022 at 2:03 AM Jeffery To wrote: On Fri, May 13, 2022 at 6:26 AM Sergey Ryazanov wrote: +1 Stephan, may I sincerely ask you to stop spamming the list? On Mon, May 9, 2022 at 12:08 PM wrote: is the below weekly message of any informational value to _all_? can someone maybe block this if it's not? ..thanks ede On 08.05.2022 23:05, Stephen Walker via openwrt-devel wrote: 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. As a package maintainer, I want to know that uscan is running correctly. These emails are relevant to me. Nice to hear that someone is actually using this information. May I ask why these notifications are directed to the mailing list that is dedicated for development talks? Such a notification just _looks_ irrelevant to some thread, it is not even a patchwork notification or a buildbot warning that is sent as a reply to a patch. It would be very simple to set up any competent email client to filter out these messages, if you so choose. It is a matter of balance. Everyone is happy to read these notifications, but someone will not need them and will create an automatic filtering rule. Or someone found these notifications useful, but everyone else wonders why they received them. The mail itself is currently not that informing. It is a lot of boiler plate and repetition. Only the link to the actual commit is useful information. I think it would be a huge improvement to have the highlights of the scan results posted in a nice readable format. A sort of condensed version of the page at https://sdwalker.github.io/uscan/index.html Is it possible to reconfigure these notifications to send them directly to your mailbox? Or maybe set up a dedicated mailing list? We already have the mailing list for commit notifications. I am subscribed and quite happy to be informed of development progress this way - it saves me a lot of time and does not bother people who prefer some other monitoring approach. This is a development list where the package maintainers and devs hang out, so it is relevant information. Only the current form isn't optimal IMHO. BR, Bas. --- End Message --- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: OpenWrt 21.02.3 Third service release
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 --- On 2022-04-21 00:21, Hauke Mehrtens wrote: Hi, The OpenWrt community is proud to announce the third service release of OpenWrt 21.02. It fixes security issues, improves device support, and brings a few bug fixes. Thanks for all the hard work put into this! I noticed a small issue during the upgrade using the sysupgrade in Luci. After the first attempt, it showed I was still running 21.02.2. Flashing the same file again gave me the correct version (21.02.3). (the status overview also showed the old kernel version and a low uptime, so there was a reboot and I did not misread the version). I also only have the latest binary for a single router on my PC, so no mistake possible there as well. The only difference between my first and second attempt was that I did not tick the box "Include in backup a list of current installed packages at /etc/backup/installed_packages.txt" the second time. I do have some extra packages installed and updated some during the 21.02.2 lifetime. Router is a TP Link Archer C7 v5 that was running 21.02.2 before the upgrade. If more people experience this, it might be worth spending time on it. Otherwise, it might be best to just retry and be happy! Regards, Bas. --- End Message --- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] toolchain/gcc: set dialects for each version
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 --- On 1/25/22 18:02, Stijn Tintel wrote: GCC has an option "-std=" to set the language standard for C and C++. Newer GCC versions sometimes switch to newer standards by default. This has the potential to break the OpenWrt toolchain build whenever a distro introduces a new GCC version that uses a newer dialect by default. Let's set the default dialects used for each of the GCC versions we support, to avoid these toolchain build failures in the future. Shouldn't the logic be different? It is the software that is to be compiled that is written in a certain version or versions of C or C++ language. OpenWRT should set a default C and C++ language version and packages or any other software compiled with the OpenWRT build should override it when they need it. A package might for example define that they can be compiled with version C++11 to C++20 or require at least C++17 (and hence require a minimum GCC version). How does this currently work? Are packages assumed to be compilable with the default C or C++ language version of the default (host or target) GCC version? Regards, Bas. Signed-off-by: Stijn Tintel --- toolchain/gcc/common.mk | 8 1 file changed, 8 insertions(+) diff --git a/toolchain/gcc/common.mk b/toolchain/gcc/common.mk index bef4fa37f8..3e31a139cd 100644 --- a/toolchain/gcc/common.mk +++ b/toolchain/gcc/common.mk @@ -29,14 +29,20 @@ PKG_SOURCE_URL:=@GNU/gcc/gcc-$(PKG_VERSION) PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.xz ifeq ($(PKG_VERSION),8.4.0) + C_DIALECT=-std=gnu17 + CXX_DIALECT=-std=gnu++14 PKG_HASH:=e30a6e52d10e1f27ed55104ad233c30bd1e99cfb5ff98ab022dc941edd1b2dd4 endif ifeq ($(PKG_VERSION),10.3.0) + C_DIALECT=-std=gnu17 + CXX_DIALECT=-std=gnu++14 PKG_HASH:=64f404c1a650f27fc33da242e1f2df54952e3963a49e06e73f6940f3223ac344 endif ifeq ($(PKG_VERSION),11.2.0) + C_DIALECT=-std=gnu17 + CXX_DIALECT=-std=gnu++17 PKG_HASH:=d08edc536b54c372a1010ff6619dd274c0f1603aa49212ba20f7aa2cda36fa8b endif @@ -86,6 +92,8 @@ GCC_CONFIGURE:= \ CFLAGS="-O2 -fbracket-depth=512 -pipe" \ CXXFLAGS="-O2 -fbracket-depth=512 -pipe" \ ) \ + CFLAGS="$(CFLAGS) $(C_DIALECT)" \ + CXXFLAGS="$(CXXFLAGS) $(CXX_DIALECT)" \ $(HOST_SOURCE_DIR)/configure \ --with-bugurl=$(BUGURL) \ --with-pkgversion="$(PKGVERSION)" \ --- End Message --- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [RFC] Stop providing binary package updates for release builds?
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 --- On 2021-12-12 20:42, Jo-Philipp Wich wrote: Hi, (...) Hi Jo-Philips, thanks for the detailed write-up. As an embedded software developer, I feel much and mostly agree with your reasoning. However, one of the reasons I like to use OpenWRT so much on my production router(s) is exactly that availability of quality pre-build images and release branch matching up-to-date (security, bugs) packages. For production use, I really love the "official" built and tested releases and install them to my devices, even while having my own builds available. Next to that, I install packages of what additional functionality I need. For the 20.02.1 release, it was also the way to get rid of a small bug, as advised in the release notes (in a matter of seconds): " The menu bar in LuCI is wrongly aligned If this is a real problem for you update the LuCI theme: opkg upgrade luci-theme-bootstrap " (source: https://openwrt.org/releases/21.02/notes-21.02.1) This is what, in my humble opinion, makes OpenWRT such a great piece of software for even not-so-technical users: you just pick the latest release for your router and if you need some other functionality, you can simply install a few packages from the web UI. And if there is a small security update or bugfix, it is solved in a few mouse clicks for everyone, independent of their technical skills. So apart from being convenient, I feel the packages feed for release branches also provides easy access to stability and security to all users. Given all the issues found in IOT and routers with mostly out-of-date propriety firmware, OpenWRT in its current form is such an asset! In summary, I would urge the OpenWRT devs to not too lightly drop the binary distribution of images and packages it has now. If, however, it is decided otherwise, I'm thinking of a possible solution: a docker or other container-like image that users can download with for example the host tools pre-build and an easy to use interface to update the OpenWRT sources, and configure and build them to their needs. Cheers, Bas. --- End Message --- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: ar71xx: rb941-2nd support
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 --- On 2021-10-11 10:31, Bjoern Franke via openwrt-devel wrote: Hi, is there any chance of getting support for the MikroTik hAP lite classic back? Best Regards Bjoern It only has 32MB of RAM, see https://openwrt.org/supported_devices/432_warning about these kind of devices. You can make your own build that only includes what you need to make it fit the device constraints. Regards, Bas. --- End Message --- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: ar71xx: rb941-2nd support
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 --- On 2021-10-11 10:31, Bjoern Franke via openwrt-devel wrote: Hi, is there any chance of getting support for the MikroTik hAP lite classic back? Best Regards Bjoern It only has 32MB of RAM, see https://openwrt.org/supported_devices/432_warning about these kind of devices. You can make your own build that only includes what you need to make it fit the device constraints. -- Bas. --- End Message --- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] base-files: add option to make /var persistent
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 --- On 8/7/21 10:40 AM, Stijn Tintel wrote: On 7/08/2021 10:05, Alberto Bursi wrote: On 07/08/21 02:46, Stijn Tintel wrote: On 7/08/2021 02:56, Alberto Bursi wrote: On 06/08/21 21:27, Stijn Tintel wrote: In OpenWrt, /var is symlinked to /tmp by default. This is done to reduce the amount of writes to the flash chip, which often don't have the greatest durability. As a result, things like DHCP or UPnP lease files, are not persistent across reboots. Since OpenWrt can run on devices with more durable storage, it makes sense to have an option for a persistent /var. Add an option to make /var persistent. When enabled, /var will no longer be symlinked to /tmp, but /var/run will be symlink to /tmp/run, as it should contain only files that should not be kept during reboot. The option is off by default, to maintain the current behaviour. Since it does not really need to recompile anything, I think it can/should be handled as a package, not as a compile option. When you install the package these operations are executed, if you remove the package they are undone. Removing /var at runtime, which basically happens when you remove the symlink, is very ugly and has a huge potential for breakage. Having it as a build option also avoids users from accidentally installing it as a package. If you disagree, please elaborate further, including measures to avoid random breakage caused by removing /var at runtime. My focus was more on "not using a compile option", I don't think it's necessary to do this at runtime. A simple measure to avoid breakage would be to add something that runs on boot (either initscript or preinitscript) to do these changes before any other service that needs that folder is started. So you install the package and then reboot. This approach also allows to make this a permanent change (not an optional package) and control this function with UCI config, just change the setting and reboot. IMHO this is good enough for most users, and much better than having to recompile or do the change manually. For the sake of completeness, (also shameless plug about my project): A more complex way to do it at runtime that avoids breakage is bind mounting the original folder somewhere else so you can sync the contents with the new/empty folder, then restarting all services that need it. See https://github.com/bobafetthotmail/folder2ram/blob/master/debian_package/sbin/folder2ram#L658 (the service restart is not included in that script since it has no way of knowing what services need the folders, this operation is left to the user or for OpenMediaVault it's handled by the plugin that also writes the configuration) Appreciate the input. It still sounds overly complex compared to my suggestion, especially for something that most users will probably not use. I don't feel comfortable implementing something like that. I'll just keep using my patch locally then, as I have done for almost five years. I would love to see your patch it in de main tree. It is a nice addition for everyone using extroot (like me). Even without extroot and current flashes, it might be worthwile to enable this and make thinks like dhcp leases persistent. In a soho network, they don't change that often to wear out a flash. Thanks, Stijn ___ 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: Error compiling master on WSL2 Ubuntu 20.04
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 --- On 08/06/2021 00:45, Alberto Bursi wrote: On 07/06/21 22:35, Bas Mevissen via openwrt-devel wrote: It contains /mnt/c/Program Files/dotnet/ and other unquoted paths with spaces. I would have expected them to be quoted or escaped, but none of them seems to be the case. (and shortening the path to a usual Linux path made the build finish, so no other issues at hand) Having spaces in PATH is discussed here: https://github.com/Microsoft/WSL/issues/1766 in 2017 and apparently seen as OK. If I do for example: $ which dotnet.exe /mnt/c/Program Files/dotnet//dotnet.exe it seems to work fine. Any ideas? Cheers, Bas. Afaik the OpenWrt build system does not like paths and folders with spaces, and the documentation we have for using build system with WSL explains how to get rid of the Windows stuff in the path (so you don't have things with spaces). See https://openwrt.org/docs/guide-developer/build-system/wsl Thanks for the link. I wasn't aware of the existence of such a page. I don't really like the proposed solution. The problem is not the fact that they are Windows directories, but that they contain spaces. A better way would be to call OpenWRT Make with a Linux-only path like: PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin make instead of modifying a global WSL setting. BTW. As far as I could find, spaces are legal in $PATH, so I would say that there are bugs in OpenWRT regarding handling paths with spaces. Thanks again, Bas. -Alberto ___ 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
Error compiling master on WSL2 Ubuntu 20.04
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 all,
In the last stages of compiling OpenWRT master on a WSL2 running Ubuntu
20.04, I get the following error message:
sed -i "s/Installed-Time: .*/Installed-Time: 1623018311/"
/home/bas/Workspace/openwrt/build_dir/target-mipsel_24kc_musl/root-ramips/usr/lib/opkg/status
rm -rf
/home/bas/Workspace/openwrt/build_dir/target-mipsel_24kc_musl/root-ramips/boot
/home/bas/Workspace/openwrt/build_dir/target-mipsel_24kc_musl/root-ramips/tmp/*
/home/bas/Workspace/openwrt/build_dir/target-mipsel_24kc_musl/root-ramips/usr/lib/opkg/info/*.postinst*
/home/bas/Workspace/openwrt/build_dir/target-mipsel_24kc_musl/root-ramips/usr/lib/opkg/lists/*
/home/bas/Workspace/openwrt/build_dir/target-mipsel_24kc_musl/root-ramips/var/lock/*.lock
find /home/bas/Workspace/openwrt/build_dir/target-mipsel_24kc_musl/root-ramips/ -mindepth 1
-execdir touch -hcd "@1623018311" "{}" +
find: The relative path 'Files/dotnet/' is included in the PATH environment
variable, which is insecure in combination with the -execdir action of find.
Please remove that entry from $PATH
make[2]: *** [package/Makefile:73: package/install] Error 1
make[2]: Leaving directory '/home/bas/Workspace/openwrt'
make[1]: *** [package/Makefile:111:
/home/bas/Workspace/openwrt/staging_dir/target-mipsel_24kc_musl/stamp/.package_install]
Error 2
make[1]: Leaving directory '/home/bas/Workspace/openwrt'
make: *** [/home/bas/Workspace/openwrt/include/toplevel.mk:230: world] Error 2
The actual path is: $ echo $PATH
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/usr/lib/wsl/lib:/mnt/c/Windows/System32:/mnt/c/Windows:/mnt/c/Windows/System32/wbem:/mnt/c/Windows/System32/WindowsPowerShell/v1.0/:/mnt/c/Windows/System32/OpenSSH/:/mnt/c/Program
Files/dotnet/:/mnt/c/Program Files (x86)/GnuPG/bin:/mnt/c/Program Files
(x86)/dotnet/:/mnt/c/Program Files/WireGuard/:/mnt/c/Program
Files/Git/cmd:/mnt/c/Program Files (x86)/AOMEI/AOMEI
Backupper/6.5.1:/mnt/c/Program Files (x86)/Bitvise SSH
Client:/mnt/c/WINDOWS/system32:/mnt/c/WINDOWS:/mnt/c/WINDOWS/System32/Wbem:/mnt/c/WINDOWS/System32/WindowsPowerShell/v1.0/:/mnt/c/WINDOWS/System32/OpenSSH/:/mnt/c/Users/Bas
Mevissen/AppData/Local/Microsoft/WindowsApps:/mnt/c/Users/Bas
Mevissen/.dotnet/tools
It contains /mnt/c/Program Files/dotnet/ and other unquoted paths with
spaces. I would have expected them to be quoted or escaped, but none of
them seems to be the case.
(and shortening the path to a usual Linux path made the build finish, so
no other issues at hand)
Having spaces in PATH is discussed here:
https://github.com/Microsoft/WSL/issues/1766 in 2017 and apparently seen
as OK.
If I do for example:
$ which dotnet.exe
/mnt/c/Program Files/dotnet//dotnet.exe
it seems to work fine.
Any ideas?
Cheers,
Bas.
--- End Message ---
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] ath79: rb4xx-nand: fix 512 byte pages compatibility
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 ---
On 2021-05-28 13:55, Sergey Ryazanov wrote:
Hello Bas,
thank you for your review, please find my comments below.
On Fri, May 28, 2021 at 11:41 AM Bas Mevissen
wrote:
On 2021-05-28 00:27, Sergey Ryazanov wrote:
[skipped]
+static int rb4xx_nand_attach_chip(struct nand_chip *chip)
+{
+ struct mtd_info *mtd = nand_to_mtd(chip);
+
+ /*
+ * Now we knows flash parameters and can tweak OOB the layout
for old
Rephrase to something like:
Knowing the flash parameters, we can tweak the OOB layout for old
Yeah, I am not happy with this comment too, but this is the best I was
able to compose at 01:00 :) I will rephrase it if V2 will be needed.
Here we need a comment that briefly and clearly states that the NAND
params become known at this particular moment of initialization.
Before this moment, we do not know the page size, after this moment it
is too late to reconfigure something. Do you have any thoughts?
The original comment with some spelling/grammar corrections looked fine.
Having some hint that something is deliberately done at that stage is
sufficient IMHO.
+ * (usually 64MiB) flashes.
+ *
+ * We need to use the OLD Yaffs-1 OOB layout, otherwise the RB
+ * bootloader will not be able to find the kernel that we load.
+ */
+ if (mtd->writesize == 512)
+ mtd_set_ooblayout(mtd, _nand_ecclayout_ops);
+
+ return 0;
+}
+
static u8 rb4xx_nand_read_byte(struct nand_chip *chip)
{
struct rb4xx_nand *nand = chip->priv;
@@ -135,6 +152,10 @@ static int rb4xx_nand_dev_ready(struct nand_chip
*chip)
return gpiod_get_value_cansleep(nand->rdy);
}
+static const struct nand_controller_ops rb4xx_nand_controller_ops =
{
+ .attach_chip = rb4xx_nand_attach_chip,
remove the ,
I intentionally placed the comma here to make text git-friendly. If we
will need to define more callbacks here, then we will just add a new
new line, without modifying the earlier added lines.
Agreed. It actually sounds like a good practice. Learned something today
:-)
E.g. if commit this code without the comma, then a chip detaching
callback patch will looks like this:
static const struct nand_controller_ops rb4xx_nand_controller_ops = {
- .attach_chip = rb4xx_nand_attach_chip
+ .attach_chip = rb4xx_nand_attach_chip,
+ .detach_chip = rb4xx_nand_detach_chip,
};
With this intentionally placed comma, the same theoretical patch will
looks like this:
static const struct nand_controller_ops rb4xx_nand_controller_ops = {
.attach_chip = rb4xx_nand_attach_chip,
+ .detach_chip = rb4xx_nand_detach_chip,
};
So this comma is my investment in the future ;)
+};
+
static int rb4xx_nand_probe(struct platform_device *pdev)
{
struct device *dev = >dev;
@@ -185,9 +206,6 @@ static int rb4xx_nand_probe(struct
platform_device
*pdev)
mtd->dev.parent = dev;
mtd_set_of_node(mtd, dev->of_node);
- if (mtd->writesize == 512)
- mtd_set_ooblayout(mtd, _nand_ecclayout_ops);
-
nand->chip.ecc.mode = NAND_ECC_SOFT;
nand->chip.ecc.algo = NAND_ECC_HAMMING;
nand->chip.options = NAND_NO_SUBPAGE_WRITE;
@@ -199,6 +217,7 @@ static int rb4xx_nand_probe(struct
platform_device
*pdev)
nand->chip.legacy.cmd_ctrl = rb4xx_nand_cmd_ctrl;
nand->chip.legacy.dev_ready = rb4xx_nand_dev_ready;
nand->chip.legacy.chip_delay= 25;
+ nand->chip.legacy.dummy_controller.ops =
_nand_controller_ops;
Fix indentation for all nand->something assignments to line up the =
sign
I do not think that this is a good idea for this patch. Here we add
one line that configures the single field deep inside the structure.
The line is placed after the configuration of "surface" fields. So the
overall look should not be harmed dreadfully.
In case we will rework the indentation with this patch, the 57 lines
patch will become a ~70 lines patch. Where at least 12 lines will
rework indentation, so the functional part could be easily lost. Also
the moving text back and forth within an item line, turns the history
to the white noise and makes git-blame(1) usage a pain.
If you prefer, then I could insert an empty line before the ops setup
to make it nice looking. E.g. turn this hunk:
@@ -199,6 +217,7 @@ static int rb4xx_nand_probe(struct platform_device
*pdev)
nand->chip.legacy.cmd_ctrl = rb4xx_nand_cmd_ctrl;
nand->chip.legacy.dev_ready = rb4xx_nand_dev_ready;
nand->chip.legacy.chip_delay= 25;
+ nand->chip.legacy.dummy_controller.ops =
_nand_controller_ops;
into this:
@@ -199,6 +217,7 @@ static int rb4xx_nand_probe(struct platform_device
*pdev)
nand->chip.legacy.cmd_ctrl =
Re: [PATCH] ath79: rb4xx-nand: fix 512 byte pages compatibility
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 ---
A few nitpicks:
On 2021-05-28 00:27, Sergey Ryazanov wrote:
MikroTik boards with 512 byte NAND pages require the old YAFFS1 OOB
layout for compatibility with the RouterBoot bootloader. The RB4xx NAND
driver supports such OOB layout, but checks a NAND page size too early
before the flash identification, what effectively preventing the old
OOB
layout from being used.
To fix this issue, move the page size check and OOB layout
configuration
to the chip attaching hook, which is specially intorduced for ECC and
OOB tweaking.
While at it, copy a comment from the old AR71xx driver to make it
clear,
why do we need this OOB layout tweaking.
Run tested with MikroTik RB411U board.
Signed-off-by: Sergey Ryazanov
---
.../files/drivers/mtd/nand/raw/nand_rb4xx.c | 25 ---
1 file changed, 22 insertions(+), 3 deletions(-)
diff --git
a/target/linux/ath79/files/drivers/mtd/nand/raw/nand_rb4xx.c
b/target/linux/ath79/files/drivers/mtd/nand/raw/nand_rb4xx.c
index 50bd69f6a4..00c65d14ae 100644
--- a/target/linux/ath79/files/drivers/mtd/nand/raw/nand_rb4xx.c
+++ b/target/linux/ath79/files/drivers/mtd/nand/raw/nand_rb4xx.c
@@ -81,6 +81,23 @@ static const struct mtd_ooblayout_ops
rb4xx_nand_ecclayout_ops = {
.free = rb4xx_ooblayout_free,
};
+static int rb4xx_nand_attach_chip(struct nand_chip *chip)
+{
+ struct mtd_info *mtd = nand_to_mtd(chip);
+
+ /*
+* Now we knows flash parameters and can tweak OOB the layout for old
Rephrase to something like:
Knowing the flash parameters, we can tweak the OOB layout for old
+* (usually 64MiB) flashes.
+*
+* We need to use the OLD Yaffs-1 OOB layout, otherwise the RB
+* bootloader will not be able to find the kernel that we load.
+*/
+ if (mtd->writesize == 512)
+ mtd_set_ooblayout(mtd, _nand_ecclayout_ops);
+
+ return 0;
+}
+
static u8 rb4xx_nand_read_byte(struct nand_chip *chip)
{
struct rb4xx_nand *nand = chip->priv;
@@ -135,6 +152,10 @@ static int rb4xx_nand_dev_ready(struct nand_chip
*chip)
return gpiod_get_value_cansleep(nand->rdy);
}
+static const struct nand_controller_ops rb4xx_nand_controller_ops = {
+ .attach_chip = rb4xx_nand_attach_chip,
remove the ,
+};
+
static int rb4xx_nand_probe(struct platform_device *pdev)
{
struct device *dev = >dev;
@@ -185,9 +206,6 @@ static int rb4xx_nand_probe(struct platform_device
*pdev)
mtd->dev.parent = dev;
mtd_set_of_node(mtd, dev->of_node);
- if (mtd->writesize == 512)
- mtd_set_ooblayout(mtd, _nand_ecclayout_ops);
-
nand->chip.ecc.mode = NAND_ECC_SOFT;
nand->chip.ecc.algo = NAND_ECC_HAMMING;
nand->chip.options = NAND_NO_SUBPAGE_WRITE;
@@ -199,6 +217,7 @@ static int rb4xx_nand_probe(struct platform_device
*pdev)
nand->chip.legacy.cmd_ctrl = rb4xx_nand_cmd_ctrl;
nand->chip.legacy.dev_ready = rb4xx_nand_dev_ready;
nand->chip.legacy.chip_delay = 25;
+ nand->chip.legacy.dummy_controller.ops = _nand_controller_ops;
Fix indentation for all nand->something assignments to line up the =
sign
ret = nand_scan(>chip, 1);
if (ret)
--- End Message ---
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Flagship AX routers
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 --- On 5/18/21 11:52 PM, Philip Prindeville wrote: Hi all, I noticed that there are several AX routers from TP-Link, Netgear, D-Link, etc. and some of them have even had OpenWRT ported to them. Which of these various platforms has the most CPU/RAM/FLASH? A few are discussed, but I'm not seeing consensus on "the best one currently is this..." And not to forget, which ones are affordable given the current shortages and are (still) available globally. https://forum.openwrt.org/t/802-11ax-routers/10484/281 Also saw this: https://10-0-0-0-1.org/reviews/routers/openwrt/ But it only lists AC routers. Was looking at this: https://www.amazon.com/TP-Link-WiFi-AX3000-Smart-Router/dp/B07YMFZ28Q/ But it doesn't call out CPU, memory, or storage. Got there from this page: https://www.amazon.com/OpenWrt-Routers-Networking-Products/s?k=OpenWrt=n%3A300189 Thanks, -Philip ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel Bas. --- End Message --- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 19.07] tools/mklibs: Fix compile with GCC 11
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 ---
On 2021-05-16 23:57, Hauke Mehrtens wrote:
GCC 11 defaults to C++17, but mklibs does not compile when using the
C++17 standard. This patch switches back to the gnu++98 version like
done in master commit 9437012b9ee4 ("tools/mklibs: update to 0.1.44 and
convert to Python 3")
This fixes the following compile error message:
elf.hpp:52:56: error: ISO C++17 does not allow dynamic exception
specifications
52 | const section _section(unsigned int i) const throw
(std::out_of_range) { return *sections.at(i); };
Signed-off-by: Hauke Mehrtens
---
tools/mklibs/Makefile | 1 +
1 file changed, 1 insertion(+)
diff --git a/tools/mklibs/Makefile b/tools/mklibs/Makefile
index 507c2fd394..8826840524 100644
--- a/tools/mklibs/Makefile
+++ b/tools/mklibs/Makefile
@@ -18,6 +18,7 @@ HOST_FIXUP:=autoreconf
include $(INCLUDE_DIR)/host-build.mk
HOST_CFLAGS += -I$(CURDIR)/include
+HOST_CPPFLAGS += -std=gnu++98
define Host/Install
$(INSTALL_BIN) \
Thanks, this probably the best thing to do for 19.07. I overlooked the
change above in the 9437012b9ee4 commit and assumed the mklibs 0.1.44
was gnu++17 compliant.
Bas.
--- End Message ---
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[Q] [master][openwrt-21.02] Check on 'which' in include/prereq-build.mk fails for Fedora 34 since recently, how to fix?
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 ---
tldr; A recent upgrade of the which package on Fedora 34 broke the test
in OpenWRT on 'which' being installed on the host. I would love to send
a patch, but my question is how to fix this? Any ideas welcome!
Regards,
Bas.
I ran into the following:
$ ./scripst/feeds update -a
(...)
Checking 'rsync'... ok.
Checking 'which'... failed.
Checking 'ldconfig-stub'... ok.
Build dependency: Please install 'which'
(...)
$ rpm -qa which
which-2.21-26.fc34.x86_64
I noticed that file /etc/profile.d/which2.sh had changed recently. So I
downloaded previous version of the package and extracted said file.
Sourced the old file and ran update again:
$ . ~/Downloads/which2.sh
$ ./scripts/feeds update
(...)
Checking 'rsync'... ok.
Checking 'which'... ok.
Checking 'ldconfig-stub'... ok.
(...)
The relevant part in include/prereq-build.mk is:
$(eval $(call SetupHostCommand,which,Please install 'which', \
which which | grep which))
The difference between the two versions of which2.sh is:
$ diff -u ~/Downloads/which2.sh /etc/profile.d/which2.sh
--- /home/bas/Downloads/which2.sh 2021-03-23 20:22:52.0 +0100
+++ /etc/profile.d/which2.sh2021-05-04 11:52:55.0 +0200
@@ -1,18 +1,19 @@
# shellcheck shell=sh
# Initialization script for bash, sh, mksh and ksh
-_declare="declare -f"
-_opt="-f"
-_shell="$(basename $SHELL)"
+which_declare="declare -f"
+which_opt="-f"
+which_shell="$(cat /proc/$$/comm)"
-if [ "$_shell" = "ksh" ] || [ "$_shell" = "mksh" ] || [ "$_shell" =
"zsh" ] ; then
- _declare="typeset -f"
- _opt=""
+if [ "$which_shell" = "ksh" ] || [ "$which_shell" = "mksh" ] || [
"$which_shell" = "zsh" ] ; then
+ which_declare="typeset -f"
+ which_opt=""
fi
which ()
{
-(alias; eval ${_declare}) | /usr/bin/which --tty-only --read-alias
--read-functions --show-tilde --show-dot "$@"
+(alias; eval ${which_declare}) | /usr/bin/which --tty-only --read-alias
--read-functions --show-tilde --show-dot "$@"
}
-export ${_opt} which
+export which_declare
+export ${which_opt} which
I don't see why this breaks the check. The difference is mainly in
renaming the variables used.
As said, any hint welcome!
Regards,
Bas.
--- End Message ---
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[FIX proposal] Build error of host mklibs pkg of openwrt-19.07 branch on Fedora 34
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 all,
The g++ version 11.1.1 of Fedora 34 defaults to g++17 and making the
build of host package mklibs fail. See build error below.
Obviously, least intrusive fix is to set the C++ standard to g++14 or
lower. However, on master the problem is not there due to an upgrade of
mklibs to version 0.1.44 (among some other changes). This is done in
commit 9437012b9ee4dc550e42665b71902cf885169100.
Guess we best cherry-pick that commit from master to upgrade mklibs to
0.1.44 as well. This commit was cleanly applied on top of openwrt-19.07
and the build went fine afterwards.
(build was for TP-Link Archer C7 v5 default config with ccache enabled
if that matters)
Regards,
Bas.
make[3]: Entering directory '/home/bas/Workspace/openwrt-19.07/tools/mklibs'
CFLAGS="-O2 -I/home/bas/Workspace/openwrt-19.07/staging_dir/host/include
-I/home/bas/Workspace/openwrt-19.07/tools/mklibs/include"
CPPFLAGS="-I/home/bas/Workspace/openwrt-19.07/staging_dir/host/include "
CXXFLAGS=""
LDFLAGS="-L/home/bas/Workspace/openwrt-19.07/staging_dir/host/lib " make
-j1 -C /home/bas/Workspace/openwrt-19.07/build_dir/host/mklibs-0.1.35
make[4]: Entering directory
'/home/bas/Workspace/openwrt-19.07/build_dir/host/mklibs-0.1.35'
make all-recursive
make[5]: Entering directory
'/home/bas/Workspace/openwrt-19.07/build_dir/host/mklibs-0.1.35'
Making all in lib
make[6]: Entering directory
'/home/bas/Workspace/openwrt-19.07/build_dir/host/mklibs-0.1.35/lib'
Making all in mklibs
make[7]: Entering directory
'/home/bas/Workspace/openwrt-19.07/build_dir/host/mklibs-0.1.35/lib/mklibs'
Making all in utils
make[8]: Entering directory
'/home/bas/Workspace/openwrt-19.07/build_dir/host/mklibs-0.1.35/lib/mklibs/utils'
make[8]: Nothing to be done for 'all'.
make[8]: Leaving directory
'/home/bas/Workspace/openwrt-19.07/build_dir/host/mklibs-0.1.35/lib/mklibs/utils'
make[8]: Entering directory
'/home/bas/Workspace/openwrt-19.07/build_dir/host/mklibs-0.1.35/lib/mklibs'
make[8]: Nothing to be done for 'all-am'.
make[8]: Leaving directory
'/home/bas/Workspace/openwrt-19.07/build_dir/host/mklibs-0.1.35/lib/mklibs'
make[7]: Leaving directory
'/home/bas/Workspace/openwrt-19.07/build_dir/host/mklibs-0.1.35/lib/mklibs'
make[7]: Entering directory
'/home/bas/Workspace/openwrt-19.07/build_dir/host/mklibs-0.1.35/lib'
make[7]: Nothing to be done for 'all-am'.
make[7]: Leaving directory
'/home/bas/Workspace/openwrt-19.07/build_dir/host/mklibs-0.1.35/lib'
make[6]: Leaving directory
'/home/bas/Workspace/openwrt-19.07/build_dir/host/mklibs-0.1.35/lib'
Making all in src
make[6]: Entering directory
'/home/bas/Workspace/openwrt-19.07/build_dir/host/mklibs-0.1.35/src'
Making all in mklibs-readelf
make[7]: Entering directory
'/home/bas/Workspace/openwrt-19.07/build_dir/host/mklibs-0.1.35/src/mklibs-readelf'
ccache g++ -DHAVE_CONFIG_H -I. -I../..
-I/home/bas/Workspace/openwrt-19.07/staging_dir/host/include -g -O2
-MT elf.o -MD -MP -MF .deps/elf.Tpo -c -o elf.o elf.cpp
In file included from elf_data.hpp:24,
from elf.cpp:21:
elf.hpp:52:56: error: ISO C++17 does not allow dynamic exception
specifications
52 | const section _section(unsigned int i) const throw
(std::out_of_range) { return *sections.at(i); };
|^
elf.hpp:62:47: error: ISO C++17 does not allow dynamic exception
specifications
62 | static file *open(const char *filename) throw
(std::bad_alloc, std::runtime_error);
| ^
elf.hpp:65:38: error: ISO C++17 does not allow dynamic exception
specifications
65 | file(uint8_t *mem, size_t len) throw (std::bad_alloc) :
mem(mem), len(len) { }
| ^
elf.hpp:68:52: error: ISO C++17 does not allow dynamic exception
specifications
68 | static file *open_class(uint8_t *, size_t) throw
(std::bad_alloc, std::runtime_error);
|^
elf.hpp:131:55: error: ISO C++17 does not allow dynamic exception
specifications
131 | std::string get_string(uint32_t offset) const throw
(std::bad_alloc)
| ^
elf.hpp:266:39: error: ISO C++17 does not allow dynamic exception
specifications
266 | std::string get_version() const throw (std::bad_alloc);
| ^
elf.hpp:267:44: error: ISO C++17 does not allow dynamic exception
specifications
267 | std::string get_version_file() const throw (std::bad_alloc);
|^
elf.hpp:269:44: error:
[FIX proposal] Build error of host mklibs pkg of openwrt-19.07 branch on Fedora 34
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 ---
(resent as previous attempt didn't seem to get through)
Hi all,
The g++ version 11.1.1 of Fedora 34 defaults to g++17 and making the
build of host package mklibs fail. See build error below.
Obviously, least intrusive fix is to set the C++ standard to g++14 or
lower. However, on master the problem is not there due to an upgrade of
mklibs to version 0.1.44 (among some other changes). This is done in
commit 9437012b9ee4dc550e42665b71902cf885169100.
Guess we best cherry-pick that commit from master to upgrade mklibs to
0.1.44 as well. This commit was cleanly applied on top of openwrt-19.07
and the build went fine afterwards.
(build was for TP-Link Archer C7 v5 default config with ccache enabled
if that matters)
Regards,
Bas.
make[3]: Entering directory
'/home/bas/Workspace/openwrt-19.07/tools/mklibs'
CFLAGS="-O2 -I/home/bas/Workspace/openwrt-19.07/staging_dir/host/include
-I/home/bas/Workspace/openwrt-19.07/tools/mklibs/include"
CPPFLAGS="-I/home/bas/Workspace/openwrt-19.07/staging_dir/host/include "
CXXFLAGS=""
LDFLAGS="-L/home/bas/Workspace/openwrt-19.07/staging_dir/host/lib " make
-j1 -C /home/bas/Workspace/openwrt-19.07/build_dir/host/mklibs-0.1.35
make[4]: Entering directory
'/home/bas/Workspace/openwrt-19.07/build_dir/host/mklibs-0.1.35'
make all-recursive
make[5]: Entering directory
'/home/bas/Workspace/openwrt-19.07/build_dir/host/mklibs-0.1.35'
Making all in lib
make[6]: Entering directory
'/home/bas/Workspace/openwrt-19.07/build_dir/host/mklibs-0.1.35/lib'
Making all in mklibs
make[7]: Entering directory
'/home/bas/Workspace/openwrt-19.07/build_dir/host/mklibs-0.1.35/lib/mklibs'
Making all in utils
make[8]: Entering directory
'/home/bas/Workspace/openwrt-19.07/build_dir/host/mklibs-0.1.35/lib/mklibs/utils'
make[8]: Nothing to be done for 'all'.
make[8]: Leaving directory
'/home/bas/Workspace/openwrt-19.07/build_dir/host/mklibs-0.1.35/lib/mklibs/utils'
make[8]: Entering directory
'/home/bas/Workspace/openwrt-19.07/build_dir/host/mklibs-0.1.35/lib/mklibs'
make[8]: Nothing to be done for 'all-am'.
make[8]: Leaving directory
'/home/bas/Workspace/openwrt-19.07/build_dir/host/mklibs-0.1.35/lib/mklibs'
make[7]: Leaving directory
'/home/bas/Workspace/openwrt-19.07/build_dir/host/mklibs-0.1.35/lib/mklibs'
make[7]: Entering directory
'/home/bas/Workspace/openwrt-19.07/build_dir/host/mklibs-0.1.35/lib'
make[7]: Nothing to be done for 'all-am'.
make[7]: Leaving directory
'/home/bas/Workspace/openwrt-19.07/build_dir/host/mklibs-0.1.35/lib'
make[6]: Leaving directory
'/home/bas/Workspace/openwrt-19.07/build_dir/host/mklibs-0.1.35/lib'
Making all in src
make[6]: Entering directory
'/home/bas/Workspace/openwrt-19.07/build_dir/host/mklibs-0.1.35/src'
Making all in mklibs-readelf
make[7]: Entering directory
'/home/bas/Workspace/openwrt-19.07/build_dir/host/mklibs-0.1.35/src/mklibs-readelf'
ccache g++ -DHAVE_CONFIG_H -I. -I../..
-I/home/bas/Workspace/openwrt-19.07/staging_dir/host/include -g -O2
-MT elf.o -MD -MP -MF .deps/elf.Tpo -c -o elf.o elf.cpp
In file included from elf_data.hpp:24,
from elf.cpp:21:
elf.hpp:52:56: error: ISO C++17 does not allow dynamic exception
specifications
52 | const section _section(unsigned int i) const throw
(std::out_of_range) { return *sections.at(i); };
|^
elf.hpp:62:47: error: ISO C++17 does not allow dynamic exception
specifications
62 | static file *open(const char *filename) throw
(std::bad_alloc, std::runtime_error);
| ^
elf.hpp:65:38: error: ISO C++17 does not allow dynamic exception
specifications
65 | file(uint8_t *mem, size_t len) throw (std::bad_alloc) :
mem(mem), len(len) { }
| ^
elf.hpp:68:52: error: ISO C++17 does not allow dynamic exception
specifications
68 | static file *open_class(uint8_t *, size_t) throw
(std::bad_alloc, std::runtime_error);
|^
elf.hpp:131:55: error: ISO C++17 does not allow dynamic exception
specifications
131 | std::string get_string(uint32_t offset) const throw
(std::bad_alloc)
| ^
elf.hpp:266:39: error: ISO C++17 does not allow dynamic exception
specifications
266 | std::string get_version() const throw (std::bad_alloc);
| ^
elf.hpp:267:44: error: ISO C++17 does not allow dynamic exception
specifications
267 | std::string get_version_file() const throw
(std::bad_alloc);
|
Re: [PATCH] Extend checks on build prerequisites for building OpenWRT core
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 --- Friendly ping. Bas. On 2021-04-29 22:39, Bas Mevissen wrote: On 4/29/21 11:40 AM, Paul Spooren wrote: On 4/20/21 1:08 AM, Bas Mevissen wrote: OpenWRT requires a number of Perl modules to be installed. It wasn't checking on all of them. This patch adds checks for Perl FindBin, File::Copy, File::Compare and Thread::Queue modules. Failing to install these, will have the build break at some point. By adding these to the prereq-build.mk script, they are checked on forehand. Tested on a Fedora 33 and 34 (beta) that was freshly installed. Fedora appears to break up Perl modules into small packages that need to be installed for the build to succeed. Signed-off-by: Bas Mevissen --- include/prereq-build.mk | 13 - 1 file changed, 12 insertions(+), 1 deletion(-) diff --git a/include/prereq-build.mk b/include/prereq-build.mk index 86c22f7c95..cb3dcc51e3 100644 --- a/include/prereq-build.mk +++ b/include/prereq-build.mk @@ -65,11 +65,22 @@ $(eval $(call TestHostCommand,perl-data-dumper, \ Please install the Perl Data::Dumper module, \ perl -MData::Dumper -e 1)) +$(eval $(call TestHostCommand,perl-findbin, \ + Please install the Perl FindBin module, \ + perl -MFindBin -e 1)) + +$(eval $(call TestHostCommand,perl-file-copy, \ + Please install the Perl File::Copy module, \ + perl -MFile::Copy -e 1)) + +$(eval $(call TestHostCommand,perl-file-compare, \ + Please install the Perl File::Compare module, \ + perl -MFile::Compare -e 1)) Could you please point me to where this module is required? I naively grepped through openwrt.git and couldn't find it. The other added requirements seem fine. It is in the host autoconf build. On Fedora 34, against current master, without the patch to test the need for File::Compare: $ sudo rpm -e perl-File-Compare (...) $ make -j1 V=s (...) make[3]: Entering directory '/home/bas/Workspace/openwrt-master/tools/autoconf' export SHELL="bash"; make -C /home/bas/Workspace/openwrt-master/build_dir/host/autoconf-2.69 make[4]: Entering directory '/home/bas/Workspace/openwrt-master/build_dir/host/autoconf-2.69' make all-recursive make[5]: Entering directory '/home/bas/Workspace/openwrt-master/build_dir/host/autoconf-2.69' Making all in bin make[6]: Entering directory '/home/bas/Workspace/openwrt-master/build_dir/host/autoconf-2.69/bin' autom4te_perllibdir='..'/lib AUTOM4TE_CFG='../lib/autom4te.cfg' ../bin/autom4te -B '..'/lib -B '..'/lib --language M4sh --cache '' --melt ./autoconf.as -o autoconf.in Can't locate File/Compare.pm in @INC (you may need to install the File::Compare module) (@INC contains: ../lib /usr/local/lib64/perl5/5.32 /usr/local/share/perl5/5.32 /usr/lib64/perl5/vendor_perl /usr/share/perl5/vendor_perl /usr/lib64/perl5 /usr/share/perl5) at ../lib/Autom4te/FileUtils.pm line 166. BEGIN failed--compilation aborted at ../lib/Autom4te/FileUtils.pm line 166. Compilation failed in require at ../bin/autom4te line 43. BEGIN failed--compilation aborted at ../bin/autom4te line 43. make[6]: *** [Makefile:641: autoconf.in] Error 2 (...) $ sudo dnf install -y perl-File-Compare (...) $ make -j4 (build finishes) + $(eval $(call TestHostCommand,perl-thread-queue, \ Please install the Perl Thread::Queue module, \ perl -MThread::Queue -e 1)) - $(eval $(call SetupHostCommand,tar,Please install GNU 'tar', \ gtar --version 2>&1 | grep GNU, \ gnutar --version 2>&1 | grep GNU, \ --- End Message --- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] Extend checks on build prerequisites for building OpenWRT core
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 --- On 4/29/21 11:40 AM, Paul Spooren wrote: On 4/20/21 1:08 AM, Bas Mevissen wrote: OpenWRT requires a number of Perl modules to be installed. It wasn't checking on all of them. This patch adds checks for Perl FindBin, File::Copy, File::Compare and Thread::Queue modules. Failing to install these, will have the build break at some point. By adding these to the prereq-build.mk script, they are checked on forehand. Tested on a Fedora 33 and 34 (beta) that was freshly installed. Fedora appears to break up Perl modules into small packages that need to be installed for the build to succeed. Signed-off-by: Bas Mevissen --- include/prereq-build.mk | 13 - 1 file changed, 12 insertions(+), 1 deletion(-) diff --git a/include/prereq-build.mk b/include/prereq-build.mk index 86c22f7c95..cb3dcc51e3 100644 --- a/include/prereq-build.mk +++ b/include/prereq-build.mk @@ -65,11 +65,22 @@ $(eval $(call TestHostCommand,perl-data-dumper, \ Please install the Perl Data::Dumper module, \ perl -MData::Dumper -e 1)) +$(eval $(call TestHostCommand,perl-findbin, \ + Please install the Perl FindBin module, \ + perl -MFindBin -e 1)) + +$(eval $(call TestHostCommand,perl-file-copy, \ + Please install the Perl File::Copy module, \ + perl -MFile::Copy -e 1)) + +$(eval $(call TestHostCommand,perl-file-compare, \ + Please install the Perl File::Compare module, \ + perl -MFile::Compare -e 1)) Could you please point me to where this module is required? I naively grepped through openwrt.git and couldn't find it. The other added requirements seem fine. It is in the host autoconf build. On Fedora 34, against current master, without the patch to test the need for File::Compare: $ sudo rpm -e perl-File-Compare (...) $ make -j1 V=s (...) make[3]: Entering directory '/home/bas/Workspace/openwrt-master/tools/autoconf' export SHELL="bash"; make -C /home/bas/Workspace/openwrt-master/build_dir/host/autoconf-2.69 make[4]: Entering directory '/home/bas/Workspace/openwrt-master/build_dir/host/autoconf-2.69' make all-recursive make[5]: Entering directory '/home/bas/Workspace/openwrt-master/build_dir/host/autoconf-2.69' Making all in bin make[6]: Entering directory '/home/bas/Workspace/openwrt-master/build_dir/host/autoconf-2.69/bin' autom4te_perllibdir='..'/lib AUTOM4TE_CFG='../lib/autom4te.cfg' ../bin/autom4te -B '..'/lib -B '..'/lib --language M4sh --cache '' --melt ./autoconf.as -o autoconf.in Can't locate File/Compare.pm in @INC (you may need to install the File::Compare module) (@INC contains: ../lib /usr/local/lib64/perl5/5.32 /usr/local/share/perl5/5.32 /usr/lib64/perl5/vendor_perl /usr/share/perl5/vendor_perl /usr/lib64/perl5 /usr/share/perl5) at ../lib/Autom4te/FileUtils.pm line 166. BEGIN failed--compilation aborted at ../lib/Autom4te/FileUtils.pm line 166. Compilation failed in require at ../bin/autom4te line 43. BEGIN failed--compilation aborted at ../bin/autom4te line 43. make[6]: *** [Makefile:641: autoconf.in] Error 2 (...) $ sudo dnf install -y perl-File-Compare (...) $ make -j4 (build finishes) + $(eval $(call TestHostCommand,perl-thread-queue, \ Please install the Perl Thread::Queue module, \ perl -MThread::Queue -e 1)) - $(eval $(call SetupHostCommand,tar,Please install GNU 'tar', \ gtar --version 2>&1 | grep GNU, \ gnutar --version 2>&1 | grep GNU, \ --- End Message --- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] Extend checks on build prerequisites for building OpenWRT core
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 --- OpenWRT requires a number of Perl modules to be installed. It wasn't checking on all of them. This patch adds checks for Perl FindBin, File::Copy, File::Compare and Thread::Queue modules. Failing to install these, will have the build break at some point. By adding these to the prereq-build.mk script, they are checked on forehand. Tested on a Fedora 33 and 34 (beta) that was freshly installed. Fedora appears to break up Perl modules into small packages that need to be installed for the build to succeed. Signed-off-by: Bas Mevissen --- include/prereq-build.mk | 13 - 1 file changed, 12 insertions(+), 1 deletion(-) diff --git a/include/prereq-build.mk b/include/prereq-build.mk index 86c22f7c95..cb3dcc51e3 100644 --- a/include/prereq-build.mk +++ b/include/prereq-build.mk @@ -65,11 +65,22 @@ $(eval $(call TestHostCommand,perl-data-dumper, \ Please install the Perl Data::Dumper module, \ perl -MData::Dumper -e 1)) +$(eval $(call TestHostCommand,perl-findbin, \ + Please install the Perl FindBin module, \ + perl -MFindBin -e 1)) + +$(eval $(call TestHostCommand,perl-file-copy, \ + Please install the Perl File::Copy module, \ + perl -MFile::Copy -e 1)) + +$(eval $(call TestHostCommand,perl-file-compare, \ + Please install the Perl File::Compare module, \ + perl -MFile::Compare -e 1)) + $(eval $(call TestHostCommand,perl-thread-queue, \ Please install the Perl Thread::Queue module, \ perl -MThread::Queue -e 1)) - $(eval $(call SetupHostCommand,tar,Please install GNU 'tar', \ gtar --version 2>&1 | grep GNU, \ gnutar --version 2>&1 | grep GNU, \ -- 2.31.1 Friendly ping to consider this patch for 21.02. Thanks, --- End Message --- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] Extend checks on build prerequisites for building OpenWRT core
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 --- OpenWRT requires a number of Perl modules to be installed. It wasn't checking on all of them. This patch adds checks for Perl FindBin, File::Copy, File::Compare and Thread::Queue modules. Failing to install these, will have the build break at some point. By adding these to the prereq-build.mk script, they are checked on forehand. Tested on a Fedora 33 and 34 (beta) that was freshly installed. Fedora appears to break up Perl modules into small packages that need to be installed for the build to succeed. Signed-off-by: Bas Mevissen --- include/prereq-build.mk | 13 - 1 file changed, 12 insertions(+), 1 deletion(-) diff --git a/include/prereq-build.mk b/include/prereq-build.mk index 86c22f7c95..cb3dcc51e3 100644 --- a/include/prereq-build.mk +++ b/include/prereq-build.mk @@ -65,11 +65,22 @@ $(eval $(call TestHostCommand,perl-data-dumper, \ Please install the Perl Data::Dumper module, \ perl -MData::Dumper -e 1)) +$(eval $(call TestHostCommand,perl-findbin, \ + Please install the Perl FindBin module, \ + perl -MFindBin -e 1)) + +$(eval $(call TestHostCommand,perl-file-copy, \ + Please install the Perl File::Copy module, \ + perl -MFile::Copy -e 1)) + +$(eval $(call TestHostCommand,perl-file-compare, \ + Please install the Perl File::Compare module, \ + perl -MFile::Compare -e 1)) + $(eval $(call TestHostCommand,perl-thread-queue, \ Please install the Perl Thread::Queue module, \ perl -MThread::Queue -e 1)) - $(eval $(call SetupHostCommand,tar,Please install GNU 'tar', \ gtar --version 2>&1 | grep GNU, \ gnutar --version 2>&1 | grep GNU, \ -- 2.31.1 --- End Message --- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: OpenWrt 21.02-rc1
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 --- On 2021-04-07 20:07, John Crispin wrote: On 07.04.21 12:16, Bas Mevissen via openwrt-devel wrote: Will Wifi 6 support be added to the interface? We have some support for a couple of AX routers, so it would be nice if they can work without manually tweaking things. The underlying structure seems to support it already: https://forum.openwrt.org/t/got-802-11ax-working-in-linksys-e8450/91533 I have a couple of patches pending that I will post the next few days that will make the primary HE features work on 21.02. I converged my home to 3xe8450 Good to hear. I've an X5000R waiting to be converted to OpenWRT. The E8450 or RT3200 would have been a better choice, but at the time I wanted to order a supported AX router, it was only the X5000R or the UniFi 6 Lite to choose from. The X5000R unfortunately cannot max out the Killer Wifi card in my notebook, but it still makes around 800Mbit/s with iperf3 though. Bas. John ___ 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: OpenWrt 21.02-rc1
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 --- On 4/7/21 12:29 AM, Hauke Mehrtens wrote: Hi, How do we want to go forward with OpenWrt 21.02-rc1? * I think the base system is ok. * The http (original wolfssl) problem reported by jow is fixed * LuCI in the 21.02 branch still misses DSA support, this was merged into master some time ago as far as I understood. Jow reported this end of March: > I found some serious regressions in the luci device config support. > not sure yet how long it'll take to sort out. The netifd uci config > grew so complex that it'll take a while to try all cases > * changing interface settings after previously enabling certain > options results in a brick > * wireless networks with custom ifnames are improperly bridged > * option ipv6 for ppp based protocols is broken because it clashes > with option ipv6 in device sections I would like to merge this update of iproute2 if Russel is fine with it, but I do not see this blocking 21.02-rc1: https://github.com/openwrt/openwrt/pull/4025 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. In would like to get 21.02-rc1 soon, so more users start testing it and we get more bug reports. How should we continue? 1. Tag 21.02-rc1 and do the release in the next days with the current state. 2. Merge the LuCI DSA changes from master to 21.02 branch now and do 21.02-rc1 ~3 days to see if some big problems come up. Will Wifi 6 support be added to the interface? We have some support for a couple of AX routers, so it would be nice if they can work without manually tweaking things. The underlying structure seems to support it already: https://forum.openwrt.org/t/got-802-11ax-working-in-linksys-e8450/91533 3. Wait till the problems reported by jow are fixed and do the 21.02-rc1 them. 4. Wait an other 2 weeks and see how it looks them. I would prefer if we merge the LuCI DSA changes from master to 21.02 branch now and do 21.02-rc1 soon. We should list the problems as known problems. It would be nice if someone else could also look into these problems and propose fixes. Hauke ___ 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
