Re: OpenWrt One / project update
Hi, On 11.04.2024 10:52, Bjørn Mork wrote: Ivan Ivanov writes: SOC: MediaTek MT7981B , Wi-Fi: MediaTek MT7976C Are these Mediateks capable of working without any binary blobs, at least in theory? A simple question back to you: Could you please list the wifi chips you know of which ether have a) completely open source firmware, or b) no firmware at all (neither loaded in ram, nor in internal flash)? [...] And don't forget about the "bootROM", stored in silicon, taking care of (among other things) booting the SoC from different media. -- Cheers, Piotr ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH RFC/PoC] scripts: {package-}metadata: use 'SUBMENU' as subcategory path
Motivation for this change is to allow for a more nested menu structure
when manually configuring build system with 'make {menu,n,x}config'.
The current solution provides only 2 levels of nesting (without using
external/custom config/Config.in):
- top level menu/category (Makefile variable 'CATEGORY')
- 2nd level sub menu/category (Makefile variable 'SUBMENU')
To allow placing packages in a more nested menu structure, the 'SUBMENU'
variable is treated as a menu path with '\' character as separator*.
Defining 'SUBMENU' as 'Foo\Bar\Qux' for package 'Bob' and 'Foo\Bar' for
package 'Ben' with this change would create menu structure as follows:
top level menu 'CATEGORY' --->
..menu 'Foo' --->
menu 'Bar' --->
..menu 'Qux' --->
[] package 'Bob'
..[] package 'Ben'
Currently existing menus and packages sorting methods were preserved
(menu first, packages below, alphabetical order) and the only difference
applies to the usage of 'SUBMENUDEP' Makefile variable which will affect
only last path element (the one package is placed under).
* The backslash instead of a more natural slash '/' was selected due to
the fact that some of already existing core and community packages use
slash in 'SUBMENU' variables. As this is more a RFC/PoC, final change
might use different character or approach for defining menu path.
Signed-off-by: Piotr Dymacz
---
scripts/metadata.pm | 6 ++-
scripts/package-metadata.pl | 96 -
2 files changed, 68 insertions(+), 34 deletions(-)
diff --git a/scripts/metadata.pm b/scripts/metadata.pm
index ecfe42c0bc..21e1a4b250 100644
--- a/scripts/metadata.pm
+++ b/scripts/metadata.pm
@@ -283,7 +283,11 @@ sub parse_package_metadata($) {
defined $category{$1}{$src->{name}} or
$category{$1}{$src->{name}} = [];
push @{$category{$1}{$src->{name}}}, $pkg;
};
- /^Description: \s*(.*)\s*$/ and $pkg->{description} = "\t\t
$1\n". get_multiline(*FILE, "\t\t ");
+ /^Description: \s*(.*)\s*$/ and do {
+ my $tabs = 2;
+ $pkg->{submenu} and $tabs += scalar(split(/\\/,
$pkg->{submenu}));
+ $pkg->{description} = ("\t" x $tabs)."
$1\n".get_multiline(*FILE, ("\t" x $tabs)." ");
+ };
/^Type: \s*(.+)\s*$/ and do {
$pkg->{type} = [ split /\s+/, $1 ];
undef $pkg->{tristate};
diff --git a/scripts/package-metadata.pl b/scripts/package-metadata.pl
index 9e0e6dd9e5..fa6b007f38 100755
--- a/scripts/package-metadata.pl
+++ b/scripts/package-metadata.pl
@@ -143,6 +143,7 @@ sub package_depends($$) {
}
sub mconf_depends {
+ my $tabs = shift;
my $pkgname = shift;
my $depends = shift;
my $only_dep = shift;
@@ -233,24 +234,25 @@ sub mconf_depends {
}
foreach my $tdep (@t_depends) {
- mconf_depends($pkgname, $tdep->[0], 1, $dep, $seen, $tdep->[1]);
+ mconf_depends($tabs, $pkgname, $tdep->[0], 1, $dep, $seen,
$tdep->[1]);
}
foreach my $depend (sort keys %$dep) {
my $m = $dep->{$depend};
- $res .= "\t\t$m $depend\n";
+ $res .= ("\t" x $tabs)."$m $depend\n";
}
return $res;
}
sub mconf_conflicts {
+ my $tabs = shift;
my $pkgname = shift;
my $depends = shift;
my $res = "";
foreach my $depend (@$depends) {
next unless $package{$depend};
- $res .= "\t\tdepends on m || (PACKAGE_$depend != y)\n";
+ $res .= ("\t" x $tabs)."depends on m || (PACKAGE_$depend !=
y)\n";
}
return $res;
}
@@ -265,34 +267,69 @@ sub print_package_config_category($) {
print "menu \"$cat\"\n\n";
my %spkg = %{$category{$cat}};
+ $menus{$cat} = {};
+
foreach my $spkg (sort {uc($a) cmp uc($b)} keys %spkg) {
foreach my $pkg (@{$spkg{$spkg}}) {
next if $pkg->{buildonly};
- my $menu = $pkg->{submenu};
- if ($menu) {
- $menu_dep{$menu} or $menu_dep{$menu} =
$pkg->{submenudep};
+ my $menu = $menus{$cat};
+ if ($pkg->{submenu}) {
+ my @submenus = split(/\\/, $pkg->{submenu});
+ foreach (@submenus) {
+ n
Re: [VOTE] New member proposal: Robimarko (Robert Marko)
Hi, On 30.01.2024 19:15, Christian Marangi (Ansuel) wrote: Robert is active in OpenWrt since 2017 and with some recent stats, he has more than 310 commits merged in OpenWrt. He also have uncounted Reviewed-by tag on various PR and merged commits and generally helps in everything related to IPQ (ipq806x, ipq40xx and ipq807x) and some mvebu targets. He did the conversion of ipq40xx target to DSA and made possible the introduction of the ipq807x target by sorting all the QSDK downstream patch and pushing them upstream. With his help, also the ipq60xx is very close on getting merged and actually used permitting support of even more device for OpenWrt. Also he is almost always reachable on IRC openwrt-devel and never had a problem in coordinating and collaborating with him. I think Robert is a good addition to our team and would massively help me (Ansuel) in maintaining each IPQ target and review all the related PR on github and patchwork. I would like to add Robert to the OpenWrt committers team. +1 -- Cheers, Piotr ___ 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
Hi Forest, On 10.01.2024 15:18, Forest Crossman wrote: On Tue, Jan 9, 2024 at 4:52 AM John Crispin wrote: ---SNIP--- * Why is there no USB 3.x host port on the device? - the USB 3.x and PCIe buses are shared in the selected SoC silicon, hence only a single High-Speed USB port is available Perhaps you've already considered this, but it may be possible to route the shared PCIe/USB 3 traces to both an M.2 slot and a USB 3 host port using a high-speed dual-channel differential 1:2/2:1 switch/mux. It wouldn't enable both interfaces to be used at the same time, but it would make it possible to select which interface is enabled using a GPIO pin. Then U-boot could either automatically enable one port or the other depending on what devices it detects (e.g., enable PCIe and disable USB 3 if a PCIe device is connected, otherwise enable USB 3 and disable PCIe), or it could be statically configurable via a U-boot environment variable. I suppose this should work (I couldn't find anything which would prevent using pure h/w analog mux on the bus with a runtime configuration) but I don't think there is a way to actually test it without a custom hardware (usually anything which doesn't exist in reference design/s from the chipset vendor must be tested in target configuration). Assuming bus speeds we are talking here about, I'm not sure this can be tested with some home-based tinkering ;) I'm afraid that might delay the project but I will ask around. From some quick searching, the switches/muxes that would enable this cost less than $1 each in qty. 1000. For a <$100 product I understand that may be too much of an increase to the BoM cost and PCB complexity, but I think users would really appreciate being able to choose between being able to add an M.2 SSD, WiFi card, or SATA controller and being able to plug in a USB 3.x 2.5 GbE adapter, SSD/flash drive, WiFi dongle, or 5G modem. This would also require a bit more current capacity in the USB Type-A connector if we decide to make it 3.x. -- Cheers, Piotr ___ 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
Hi Daniel, Bjørn, On 10.01.2024 12:14, Daniel Golle wrote: Hi! On Wed, Jan 10, 2024 at 11:47:08AM +0100, Bjørn Mork wrote: John Crispin writes: > At the beginning we focused on the most powerful (and > expensive) configurations possible but finally ended up with something > rather simple and above all,feasible. That's a very wise choice. And most of the compromises make sense to me. Except the > * Storage: M.2 2042 for NVMe SSD (PCIe gen 2 x1) This seems like a strange priority for an OpenWrt device. It's not useful to most OpenWrt users or applications. Having two different boot devices is more than enough. > * What will the M.2 slot be used for? > - we will use M.2 with M-key for NVMe storage. There is a > work-in-progress patch to make PCIe work inside the U-Boot > bootloader. This will allow booting other Linux distributions such > as Debian and Alpine directly from NVMe And you even make a point of it being more suitable for other Linux distros. That should not be an OpenWrt priority. > * Why is there no USB 3.x host port on the device? > - the USB 3.x and PCIe buses are shared in the selected SoC silicon, > hence only a single High-Speed USB port is available And here's the biggest problem with that choice. USB3 would have allowed storage expansion as well as more OpenWrt applicable use cases like additional ethernet adapters or modems. And with a limited connector and board space cost compared to an m.2 slot. The USB A port is already there. Regarding all of the above: exposing the PCIe lane gives you the biggest possible flexibility. If you want USB 3 you can use an adapter like this: https://www.delock.com/produkt/63174/merkmale.html Exactly, you can easily find adapters for SATA, USB, NIC and even mechanical connector type change (M.2 to desktop PCIe). Including USB 3 will significantly increase the cost of the design not because of connectors, but because of the interference problems we will have to deal with and somehow mitigate (and the smaller the board the harder that will get). I've seen too many devices with such problems and only very few manage to have well-working 2.4 GHz Wi-Fi next to a USB 3 host. Even with a good shielding on the device's side, a low quality USB cable will have impact on the 2.4 GHz interface. There is an official white paper about this: [1]. > * What is the purpose of the console USB-C port? > - Holtek UART to USB bridge with CDC-ACM support on USB-C makes the > device ultra easy to communicate with. No extra hardware or drivers > will be required. Android for example has CDC-ACM support enabled by > default This is nice. But how about making it a real advantage over the traditional 4 pin header? You could have used a UART bridge with some additional GPIO pins, and connected them to useful SoC IOs. Possibly via some mux. I'd love to see reset and bootsel controlled by the USB UART bridge. Good point. That would also make it more accessible and easy automated testing a lot. My only concern here would be compatibility with other OS/platforms. Ideally we would have a more advanced USB bridge with open source firmware and more than one USB function. But I guess that adds a lot of complexity to the project. Reusing/abusing RS232 control signals is an alternative. Finally, I'd prefer a much more compact board than the BPi-R4 size. Along with a well designed minimalistic case with sufficient passive cooling and optional integrated antennas. Thinking something along the Flirc RPi4 cases, using the case itself as a cooler. With half the case radio transparent and a choice between antenna pigtails and integrated antennas. I realize that such a case will be relatively expensive. But without it all you have is yet another midrange dev board. This is your chance to make a device which shouts "OpenWrt!!!" whenever someone sees it. Just like the original WRT did. Not that that design was something to brag about beauty wise :-) I also think we should should have a pre-assembled-with-case-and-antennas option in addition to just offering the plain board. +1. [1] https://www.usb.org/sites/default/files/327216.pdf -- Cheers, Piotr ___ 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
Hi Chuanhong, On 9.01.2024 14:51, Chuanhong Guo wrote: Hi! On Tue, Jan 9, 2024 at 6:52 PM John Crispin wrote: [...] FAQ * Why are there are 2 different flash chips? - the idea is to make the device (almost!) unbrickable and very easy to recover What about a built-in JTAG probe instead of SPI-NOR+USB-UART? It'll be actually unbrickable instead. We were considering similar idea but that would involve additional testing and extra work on the manufacturer's side procedures (programming and testing the MCU). I believe avoiding this would speed up things and getting the device made. The dual-flash solution with a mechanical switch seems as simple as possible in terms of required user's actions for unbricking the device and at the same time, doesn't force user to use specific tools and/or OS. Experienced users could still use the regular JTAG connector on-board. - NAND will hold the main loader (U-Boot) and the Linux image and will be the default boot device - NOR will be write-protected by default (with WP jumper available on the board) and will hold a recovery bootloader (and other essential data, like Wi-Fi calibration) - a dedicated boot select switch will allow changing between NOR and NAND [...] * What is the purpose of the console USB-C port? - Holtek UART to USB bridge with CDC-ACM support on USB-C makes the device ultra easy to communicate with. No extra hardware or drivers will be required. Android for example has CDC-ACM support enabled by default There are several MCU-based CMSIS-DAP projects out there. They can provide a CDC-ACM serial with a JTAG interface. It may be a bit slow if a USB1.1 MCU is picked, but it should be enough to start a bootloader to unbrick the device. Here's one with USB2.0 Hi-speed interface: https://github.com/cherry-embedded/CherryDAP The Sipeed M0S module used costs 20CNY on Taobao (or 2.81 USD according to google) I like the idea, could be probably combined with some of the suggestions from Bjørn. But at least for now, let's KISS and keep these ideas for future, maybe. -- Cheers, Piotr ___ 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
Hi Janusz, On 9.01.2024 19:14, Janusz Dziedzic wrote: wt., 9 sty 2024 o 18:59 Daniel Golle napisał(a): On Tue, Jan 09, 2024 at 06:49:04PM +0100, Janusz Dziedzic wrote: > wt., 9 sty 2024 o 18:02 Robert Marko napisał(a): > > > > On Tue, 9 Jan 2024 at 17:53, Rafał Miłecki wrote: > > > > > > On 9.01.2024 13:29, John Crispin wrote: > > > > On 09.01.24 12:56, Robert Marko wrote: > > > >> ---SNIP--- > > > >> > > > >>> Why not 6GHz? > > > >> 6GHz requires an external card, and I doubt you can fit that in the > > > >> target price. > > > >> > > > >> Regards, > > > >> Robert > > > > > > > > correct. as mentioned in the email, we wanted to start out small. also upstream mac80211 is still missing a bunch of 11be related features. > > > > > > 6 GHz doesn't imply 802.11be, does it? I'm really not sure. > > > > > > Does MediaTek have any 802.11ax solutions that cover both: 5 GHz and > > > 6 GHz? Maybe it'd be worth checking if that's an option and then use > > > voting to see if people care? > > > > You can use 6GHz as part of 802.11ax as well, but you need an external card or > > you need to sacrifice the built-in 5GHz for 6GHz and that isn't really > > a good idea > > in my opinion. > > > Even will be 150$ it is still good price for router with 2.4/5/6GHz > (MTK base ACER predator W6 is about 200$). > Or at least add extra m2 AE Key slot - then we can put there mt7916 > card, as possible extension (eg. > https://asiarf.com/product/wi-fi-6e-m-2-ae-key-module-mt7916-aw7916-aed/). > What will be price in case of this extra m2 AE Key slot? You can use M.2 key adapters for that https://www.delock.com/produkt/63343/merkmale.html An additional slot is *not* an option as we got only a single PCIe lane. Hopefully there are also going to be single-band (6 GHz only) 4T4R or even 4T5R modules based on MT7916E available at some point... Seems bpi-r4 will use two miniPCIe slots for that: https://wiki.banana-pi.org/Getting_Started_with_BPI-R4#4.29_Wi-Fi7_NIC If we don't have two PCIe then probably no option for 6ghz I believe this is a preliminary approach, same as it was done with MT7621 + MT7915 (oversized modules). As this is not compliant with the standard and thus limiting platforms these modules will work with, I believe the target will be embedded design only or maybe some oversized M.2. Either way, this is a custom design. I'm pretty sure that when MediaTek designs solutions for AP platforms they consider only the "everything on-board" approach, even if the BB/MAC part utilizes PCIe bus. Usually, chipsets dedicated for module (mini PCIe or the M.2 these days) design are not part of the "AP" product line and are focused on "STA" operation. Anyway, some compromises had to be made. -- Cheers, Piotr ___ 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: OpenWrt One - celebrating 20 years of OpenWrt
Hi Enrico, On 9.01.2024 13:55, Enrico Mioso wrote: Hello!! First of all, let me thank You all for this great project. I wll do my best to buy some units - even tough I am not contributing by any mean to OpenWrt in terms of code, or very little, I am very passionate about this project and the overall router freedom. As most of you know by now, I am a blind person and OpenWrt has always been a great opportunity for accessibility as well. The OpenWrt design itself helps accessibility, and the fact you can use it entirely with no web interface is really a plus for me. It would be great if the hardware could be easily operable - and the exposed consoly and flashy plastic case. Would have loved to see that happen, but the lead time for mould casting is insane as well as the cost, specifically for small production runs. hence the choice for re-using something that already exists.e port is - indeed - an enormous plus for me. So, here are my probably unpopular opinions: 1 - I would like for the device to come pre-mounted with a case: having different cases with different designs is not great. And finding someone to help me mount one and/or shipping the device might not be as easy. Some great friends here do help me, but I think it would be a better experience to have a ready-to-use device from the beginning. 2 - Switches for booting could be exposed and easily operable without removing the case: having to open the device case could make it easier to damage the device, the case or both. :) This hasn't been decided yet but we were discussing about offering the device in just two versions: bare PCB and fully-assembled. Plan for the boot select mechanical switch is to make it available from outside, without the need to open the case. As for the Wi-Fi, I would omit itentirely - leaving the device as it is for the rest of the specs. I know the motto has been - for years - Wireless Freedom... but, personally, I am under the impression Wi-Fi is a fast moving targets these days, so packing Wi-Fi on the device wouldnt make so much sense here, to have it "deprecated" in months. You get a robust router device that you can plug in your setup. Hey - I told you this wasn't popular. :) We are heading to Wi-Fi 7 but my guess is that even the Wi-Fi 6 hasn't become the dominant standard and most people are (still?) using Wi-Fi 5 (or even 4!) in their daily usage scenarios. It will be always a personal choice but having a modern, open, stable and widely available Wi-Fi 6 platform with a great community driven support is a key here. As for the NVME storage - it would be great if there was an easy way to install / change the NVME card as well, but here I know I am asking too much. It could be enough it there was an option to purchase a device with NVME pre-installed. This would really help for me. IMHO, limited number of available "bundles" would make things easier. But I can imagine resellers offering extra versions for some additional cost (like the unofficial bundles for Raspberry Pi offered by numbers of different online shops). -- Cheers, Piotr ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] ipq95xx: Add support for IPQ9574 RDP433
Hi Robert, Adding John's correct e-mail to the loop. On 8.12.2023 11:02, Robert Marko wrote: On Fri, 8 Dec 2023 at 11:01, Piotr Dymacz wrote: Hi Robert, On 7.12.2023 12:52, Robert Marko wrote: > > On 07. 12. 2023. 12:20, Varadarajan Narayanan wrote: >> On Thu, Dec 07, 2023 at 11:11:03AM +0100, Robert Marko wrote: >>> On 07. 12. 2023. 10:59, Varadarajan Narayanan wrote: >>>>SoC : QCOM IPQ9574 >>>>RAM : 2GB DDR4 >>>>Flash : eMMC 8GB >>>>WiFi: 1 x 2.4GHz >>>> 1 x 5GHz >>>> 1 x 6GHz >>>> >>>> Signed-off-by: Varadarajan Narayanan >>> Without even looking at the code, please split this up as its >>> not reviewable at all currently. >>> >>> Also, I would strongly encourage using Github PR for this. >> This patch just has the base SoC/board support and not drivers for >> WiFi/ethernet/USB etc. Can you kindly guide on what kind >> of split is acceptable for the community. >> >> Thanks >> Varada > > Hi, > I would at least split the target itself, patches and then the board > itself for the start. Would it make sense to rename qualcommax to qualcomm and make ipq95xx just another subtarget of it (I'm aware of A53 vs. A73)? That depends on how much is shared between the AX SoC-s and the BE ones(IPQ95xx and IPQ53xx). I would say enough to keep them together. But, I would prefer that or qualcommbe target where new BE SoC-s will be subtargets. I'm personally more a fan of limiting number of top targets and deal with differences under subtargets. -- Cheers, Piotr Regards, Robert -- Cheers, Piotr > > Also, please sort the patches by prefix such as: > 0xx are backports (Kernel version from which they are backported must be > marked as well) > 1xx are pending > 9xx are usually hacks/stuff that currently cannot be upstreamed. > > Again, I would strongly encourage using Github PR for large changes such > as these as its much > easier to comment on certain changes and it has a lot larger reach than > the OpenWrt mailing list > as not all interested parties even follow this list. > > Regards, > Robert > > > ___ > 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: [PATCH] ipq95xx: Add support for IPQ9574 RDP433
Hi Robert, On 7.12.2023 12:52, Robert Marko wrote: On 07. 12. 2023. 12:20, Varadarajan Narayanan wrote: On Thu, Dec 07, 2023 at 11:11:03AM +0100, Robert Marko wrote: On 07. 12. 2023. 10:59, Varadarajan Narayanan wrote: SoC : QCOM IPQ9574 RAM : 2GB DDR4 Flash : eMMC 8GB WiFi: 1 x 2.4GHz 1 x 5GHz 1 x 6GHz Signed-off-by: Varadarajan Narayanan Without even looking at the code, please split this up as its not reviewable at all currently. Also, I would strongly encourage using Github PR for this. This patch just has the base SoC/board support and not drivers for WiFi/ethernet/USB etc. Can you kindly guide on what kind of split is acceptable for the community. Thanks Varada Hi, I would at least split the target itself, patches and then the board itself for the start. Would it make sense to rename qualcommax to qualcomm and make ipq95xx just another subtarget of it (I'm aware of A53 vs. A73)? -- Cheers, Piotr Also, please sort the patches by prefix such as: 0xx are backports (Kernel version from which they are backported must be marked as well) 1xx are pending 9xx are usually hacks/stuff that currently cannot be upstreamed. Again, I would strongly encourage using Github PR for large changes such as these as its much easier to comment on certain changes and it has a lot larger reach than the OpenWrt mailing list as not all interested parties even follow this list. Regards, Robert ___ 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
nvmem-layout and mt76 eeprom (ramips/mt7621 target, 5.15.x)
Hi Rafał, I'm trying to use the new NVMEM cells with mt76 EEPROM bindings on an mt7621 (SPI NOR flash) with mt79x5 (PCIe) based device, same way as you did in 03b3284805 [1] and daaa0c1b25 [2] (ath79 target). If I keep 'eeprom' within 'nvmem-layout', wifi doesn't work due to: root@OpenWrt:/# cat /sys/kernel/debug/devices_deferred :02:00.0pci: supplier 1e000b00.spi:flash@0:partitions:partition@5:nvmem-layout not ready Keeping 'eeprom' node outside 'nvmem-layout' gives expected results. It seems there are only one (Netgear WNDR3700 v5) similar device under ramips/mt7621, with 'eeprom' within 'nvmem-layout' defines and SPI NOR (all other are NAND based, maybe related?) but I don't see any bug reports (complains) about broken WiFi for it. Any clue? You can find related DTS in my staging tree [3]. Thanks! [1] https://git.openwrt.org/03b3284805 [2] https://git.openwrt.org/daaa0c1b25 [3] https://git.openwrt.org/?p=openwrt/staging/pepe2k.git;a=blob;f=target/linux/ramips/dts/mt7621_alfa-network_ax1800rm.dts;hb=refs/heads/main -- Cheers, Piotr ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: sysupgrade broken on imx nand targets (and maybe others too)
Hi Koen, On 24.01.2023 22:08, Koen Vandeputte wrote: [...] Piotr, Would you have any idea here? Not really, very strange. What makes me wondering is that it doesn't look like a h/w related thing (e.g. watchdog fire or some sudden current consumption spike resulting in reset) and more like a clean 'reboot' but delayed. Smells like some race condition. Could you do a test without USB support installed (just a blind shooting but maybe we could get more clear logs just before the reboot)? -- Cheers, Piotr ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [EXT] Re: [PATCH] imx: add imx8mplus platform support
Hi Andy, On 20.09.2022 08:47, Andy Tang wrote: Hi Piotr, Please look at my response about your concerns below. See my reply below. -Original Message- From: Piotr Dymacz Sent: 2022年8月23日 19:23 To: Andy Tang Cc: openwrt-devel@lists.openwrt.org; Rafał Miłecki ; Petr Štetiar Subject: Re: [EXT] Re: [PATCH] imx: add imx8mplus platform support [snip] >> > + >> > +PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).bin >> > >> +PKG_SOURCE_URL:=https://eur01.safelinks.protection.outlook.com/?url= >> +h >> > >> +ttps%3A%2F%2Fwww.nxp.com%2Flgfiles%2FNMG%2FMAD%2FYOCTO%2F& >> amp;data=05 >> > >> +%7C01%7Candy.tang%40nxp.com%7C3b32776df9fc458bdc3308da7f78c352 >> %7C686e >> > >> +a1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637962453910142398%7C >> Unknown%7 >> > >> +CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haW >> wiLCJX >> > >> +VCI6Mn0%3D%7C3000%7C%7C%7C&sdata=XYCuUHEbBXHxYglYSPaox >> nQVEGD0ivXF >> > +Ci0MaZllnKk%3D&reserved=0 >> > +PKG_HASH:=ef91390da6c8a6a48c8121a5dd667de8 >> >> OK, so a 'firmware-imx-8.15.bin' file, hosted somewhere on NXP >> servers which seems to be a self-extracting package with bunch of >> proprietary binary blobs and almost 700 lines license. And it asks >> for EULA acceptance when >> extracting: >> >> "Welcome to NXP firmware-imx-8.15.bin >> >> You need to read and accept the EULA before you can continue. >> >> LA_OPT_NXP_Software_License v34 February 2022 [...] " >> I don't think we can accept this (Rafał, Petr, any opinions?). >> Looking at other open source projects, e.g. Barebox requires users to >> manually obtain and extract the firmware [1]. U-Boot documentation >> for this board mentions only the DDR training and ATF firmware [2]. >> >> Are all the blobs really required by this platform? Is there any >> other, more open source friendly way to get these binary blobs? > Since the license issue, these blobs have been released together. > This is the only format to release these binaries even though not all of them are used on a specific platform. As Petr already stated, the EULA forbids re-distribution of that firmware (maybe this topic should be discussed with some lawyer but that's not our job). For now I don't see any (legal) way to re-distribute these binaries by OpenWrt project (embedded within a pre-built image for the platform you are adding support for). I have checked with our legal team. They say EULA doesn't forbid re-distribution the binaries. Could you then please ask your legal team to distribute those binaries under different EULA and in different form, without the statements we pointed out before? I'm sorry but your assurances here, at least for me, isn't enough. Actually we already did this on Yocto project. Please see: 1. https://git.yoctoproject.org/meta-freescale/tree/recipes-bsp/imx-sc-firmware/imx-sc-firmware_1.13.0.bb 2. https://git.yoctoproject.org/meta-freescale/tree/classes/fsl-eula-unpack.bbclass See here: https://git.yoctoproject.org/meta-freescale/tree/classes/fsl-eula-unpack.bbclass#n113 In this project, firmware binary was downloaded and self-extracted automatically. With assumption that the end customer/user has read EULA and accepted it (manually or automatically). And the whole process of downloading, accepting the license and extracting binaries is done on the end user machine. Based on my experience, the Yocto project doesn't host those proprietary binaries and doesn't share ready to use firmware images with them (please, correct me if I'm wrong here). Yocto is more like a platform for building firmware _yourself_, not a ready-to-use Linux distribution you could just download and install on the hardware. OpenWrt _is_ a Linux distribution. Customer should define a variable in local.conf file to indicate that the agreement is accepted although. So I think it should be ok too in OpenWRT project. Sorry but for me this is still a no-go for OpenWrt. As I wrote before, we could add a "generic" support for this platform, mark it as "broken" (this would result with no prebuilt images available for download from OpenWrt servers), with some kind of a note for users, with instructions (in Wiki?) how to download proprietary binaries, accept the license and then _manually_ build OpenWrt for the platform. -- Cheers, Piotr ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [EXT] Re: [PATCH] imx: add imx8mplus platform support
Hi Andy, On 17.08.2022 09:36, Andy Tang wrote: Hi Piotr, Thanks for your valuable suggestions. I will address most of your concern. Some responses are inline. -Original Message- From: Piotr Dymacz Sent: 2022年8月16日 19:16 To: Andy Tang Cc: openwrt-devel@lists.openwrt.org; Rafał Miłecki ; Petr Štetiar Subject: [EXT] Re: [PATCH] imx: add imx8mplus platform support Caution: EXT Email Hi Andy, Sorry for late reply. Please, see my comments inline below. Rafał, Petr, it would be great if you could give your thoughts regarding my concerns about the 'firmware-imx' package. > > +++ b/package/firmware/imx/Makefile > @@ -0,0 +1,47 @@ > +# SPDX-License-Identifier: GPL-2.0-only # # Copyright 2022 NXP # > + > +include $(TOPDIR)/rules.mk > + > +PKG_NAME:=firmware-imx > +PKG_VERSION:=8.15 > +PKG_RELEASE:=1 > + > +PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).bin > +PKG_SOURCE_URL:=https://eur01.safelinks.protection.outlook.com/?url=h > +ttps%3A%2F%2Fwww.nxp.com%2Flgfiles%2FNMG%2FMAD%2FYOCTO%2F& amp;data=05 > +%7C01%7Candy.tang%40nxp.com%7C3b32776df9fc458bdc3308da7f78c352 %7C686e > +a1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637962453910142398%7C Unknown%7 > +CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haW wiLCJX > +VCI6Mn0%3D%7C3000%7C%7C%7C&sdata=XYCuUHEbBXHxYglYSPaox nQVEGD0ivXF > +Ci0MaZllnKk%3D&reserved=0 > +PKG_HASH:=ef91390da6c8a6a48c8121a5dd667de8 OK, so a 'firmware-imx-8.15.bin' file, hosted somewhere on NXP servers which seems to be a self-extracting package with bunch of proprietary binary blobs and almost 700 lines license. And it asks for EULA acceptance when extracting: "Welcome to NXP firmware-imx-8.15.bin You need to read and accept the EULA before you can continue. LA_OPT_NXP_Software_License v34 February 2022 [...] " I don't think we can accept this (Rafał, Petr, any opinions?). Looking at other open source projects, e.g. Barebox requires users to manually obtain and extract the firmware [1]. U-Boot documentation for this board mentions only the DDR training and ATF firmware [2]. Are all the blobs really required by this platform? Is there any other, more open source friendly way to get these binary blobs? Since the license issue, these blobs have been released together. This is the only format to release these binaries even though not all of them are used on a specific platform. As Petr already stated, the EULA forbids re-distribution of that firmware (maybe this topic should be discussed with some lawyer but that's not our job). For now I don't see any (legal) way to re-distribute these binaries by OpenWrt project (embedded within a pre-built image for the platform you are adding support for). If this is not acceptable, what's your suggestion for it? Let the user do this manually? I don't see any other option and honestly I'm not exactly sure how this would work. Maybe you could describe in the Wiki how to built the image after manually obtaining and extracting firmware and at the same time mark the platform as broken in the main codebase so it won't get built automatically (no official pre-built images)? From what I can see, that's how other projects handle that kind of restrictive EULA and binary blobs... madness. > +endef > +TARGET_DEVICES += imx8mplus > diff --git a/target/linux/imx/image/mkits-multiple-config.sh > b/target/linux/imx/image/mkits-multiple-config.sh > new file mode 100755 > index 00..0d83f9e34d > --- /dev/null > +++ b/target/linux/imx/image/mkits-multiple-config.sh [snip] Maybe instead of introducing another copy of the same script (see the 'layerscape' target) you could reuse existing one and make some generic image commands out of it? Could you please instruct me how I can reuse the script that belongs to other targets like this? Have a look for example at 'mkits-qsdk-ipq-image.sh' script [1]. It's used by two recipes defined in image-commands.mk [2]: 'qsdk-ipq-factory-nand' and 'qsdk-ipq-factory-nor'. This way, we can make use of them within any (sub)target, like e.g. here: [3]. [1] https://github.com/openwrt/openwrt/blob/master/scripts/mkits-qsdk-ipq-image.sh [2] https://github.com/openwrt/openwrt/blob/master/include/image-commands.mk#L455 [3] https://github.com/openwrt/openwrt/blob/master/target/linux/ipq40xx/image/generic.mk#L477 -- Cheers, Piotr BR, Andy > diff --git a/target/linux/imx/imx8/config-5.15 > b/target/linux/imx/imx8/config-5.15 > new file mode 100644 > index 00..2b6ab299a0 > --- /dev/null > +++ b/target/linux/imx/imx8/config-5.15 > @@ -0,0 +1,2661 @@ [snip] > diff --git a/target/linux/imx/imx8/target.mk > b/target/linux/imx/imx8/target.mk new file mode 100644 index > 00..f990298d80 > --- /dev/null > +++ b/target/linux/
Re: [PATCH] imx: add imx8mplus platform support
Hi Andy, Sorry for late reply. Please, see my comments inline below. Rafał, Petr, it would be great if you could give your thoughts regarding my concerns about the 'firmware-imx' package. On 04.07.2022 09:24, Yuantian Tang wrote: Imx8mplus_evk device is built to meet the needs of Smart Home, Building, City and Industry 4.0, 5G gateway and router applications. Hardware specifications: CPU: 4x or 2x Cortex-A53 up to 1.8 GHz DRAM: 32-bit DDR4 & LPDDR4 up to 4.0GT/s Board: imx8mp_evk SoC: imx8mplus On-board WiFi/Bluetooth chip: NXP 88W8997 Ethernet: 2x Gigabit Ethernet with AVB, IEEE 1588, EEE and 1x w/ TSN Signed-off-by: Yuantian Tang --- package/boot/atf-imx/Makefile | 51 + package/boot/uboot-imx/Makefile | 48 +- .../uboot-imx/files/imx8mp-sdboot-uEnv.txt| 12 + package/firmware/imx/Makefile | 47 + package/utils/imx-mkimage/Makefile| 38 + target/linux/imx/Makefile |5 +- target/linux/imx/config-5.15 | 443 --- target/linux/imx/cortexa7/config-default | 441 +++ target/linux/imx/cortexa7/target.mk |2 + target/linux/imx/cortexa9/config-default | 441 +++ target/linux/imx/cortexa9/target.mk |2 + target/linux/imx/image/gen_sdcard_head_img.sh | 21 + target/linux/imx/image/imx8.mk| 98 + .../linux/imx/image/mkits-multiple-config.sh | 600 target/linux/imx/imx8/config-5.15 | 2661 + target/linux/imx/imx8/target.mk | 11 + .../0001-fix-the-compiling-error.patch| 39 + 17 files changed, 4508 insertions(+), 452 deletions(-) create mode 100644 package/boot/atf-imx/Makefile create mode 100644 package/boot/uboot-imx/files/imx8mp-sdboot-uEnv.txt create mode 100644 package/firmware/imx/Makefile create mode 100644 package/utils/imx-mkimage/Makefile delete mode 100644 target/linux/imx/config-5.15 create mode 100755 target/linux/imx/image/gen_sdcard_head_img.sh create mode 100644 target/linux/imx/image/imx8.mk create mode 100755 target/linux/imx/image/mkits-multiple-config.sh create mode 100644 target/linux/imx/imx8/config-5.15 create mode 100644 target/linux/imx/imx8/target.mk create mode 100644 target/linux/imx/patches-5.15/0001-fix-the-compiling-error.patch diff --git a/package/boot/atf-imx/Makefile b/package/boot/atf-imx/Makefile new file mode 100644 index 00..e76393d1e9 --- /dev/null +++ b/package/boot/atf-imx/Makefile We already have bunch of arm-trusted-firmware-* packages for other targets and also 'include/trusted-firmware-a.mk' template. Is there any reason to use custom approach here? [snip] diff --git a/package/boot/uboot-imx/Makefile b/package/boot/uboot-imx/Makefile index 305d127557..f323f92dce 100644 --- a/package/boot/uboot-imx/Makefile +++ b/package/boot/uboot-imx/Makefile @@ -7,10 +7,14 @@ include $(TOPDIR)/rules.mk -PKG_VERSION:=2022.01 +PKG_NAME:=uboot-imx +PKG_VERSION:=lf-5.15.5-1.0.0 PKG_RELEASE:=$(AUTORELEASE) -PKG_HASH:=81b4543227db228c03f8a1bf5ddbc813b0bb8f6555ce46064ef721a6fc680413 +PKG_SOURCE_PROTO:=git +PKG_SOURCE_URL:=https://source.codeaurora.org/external/imx/uboot-imx Please, use the upstream U-Boot. The 'imx8mp_evk' is supported since U-Boot ~2020.01 if I'm right. Are there any specific changes in your U-Boot fork required by this board/platform? [snip] diff --git a/package/firmware/imx/Makefile b/package/firmware/imx/Makefile new file mode 100644 index 00..880a882aa2 --- /dev/null +++ b/package/firmware/imx/Makefile @@ -0,0 +1,47 @@ +# SPDX-License-Identifier: GPL-2.0-only +# +# Copyright 2022 NXP +# + +include $(TOPDIR)/rules.mk + +PKG_NAME:=firmware-imx +PKG_VERSION:=8.15 +PKG_RELEASE:=1 + +PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).bin +PKG_SOURCE_URL:=https://www.nxp.com/lgfiles/NMG/MAD/YOCTO/ +PKG_HASH:=ef91390da6c8a6a48c8121a5dd667de8 OK, so a 'firmware-imx-8.15.bin' file, hosted somewhere on NXP servers which seems to be a self-extracting package with bunch of proprietary binary blobs and almost 700 lines license. And it asks for EULA acceptance when extracting: "Welcome to NXP firmware-imx-8.15.bin You need to read and accept the EULA before you can continue. LA_OPT_NXP_Software_License v34 February 2022 [...] " I don't think we can accept this (Rafał, Petr, any opinions?). Looking at other open source projects, e.g. Barebox requires users to manually obtain and extract the firmware [1]. U-Boot documentation for this board mentions only the DDR training and ATF firmware [2]. Are all the blobs really required by this platform? Is there any other, more open source friendly way to get these binary blobs? + +include $(INCLUDE_DIR)/package.mk + +define Package/firmware-imx + SECTION:=firmware + CATEGORY:=Firmware + TITLE:=NXP firmware for imx soc + MKIMG_DIR:=`find $(STAGING_DIR_IMAGE) -name imx-mkimage* | xargs basename`/iMX8M + BU
Re: [PATCH] ramips: add support for TP-Link RE650 v2
Hi Hauke, On 17.04.2022 16:40, Hauke Mehrtens wrote: On 4/8/22 00:29, Marcin Gordziejewski wrote: TP-Link RE650 v2 is largely similar to v1 that is already supported by OpenWrt. Notable differences is differnt SPI Flash - 8 MB instead of 16 MB (from cFeon instead of Winbond) and a different configuration of PCIE connections to wifi chips. Otherwise it's largely the same product as v1 Hardware specification: - SoC 880 MHz - MediaTek MT7621AT - 128 MB of DDR3 RAM - 8 MB - cFeon QH64A-104HIP - 4T4R 2.4 GHz - MediaTek MT7615E - 4T4R 5 GHz - MediaTek MT7615E Are you sure this is 4x4 on 2.4GHz and 5GHz? For me it looks more like 2x2 on 2.4GHz and 2x2 on 5GHz. The MT7615E can operate on 2.4 GHz and 5GHZ at the same time. AFAIK, only the "D" version can operate on both bands at the same time and in that case, it's 2x 2x2. The device's pictures from FCC database clearly show this one is 2x 4x4 (there are two "E", one per band) [1]. [1] https://fccid.io/2AXJ4RE650V2/Internal-Photos/2109RSU016-UE-Internal-Photograph-Rev01-5556352 -- Cheers, Piotr - 1x 1 Gbps Ethernet - MT7621AT integrated - 7x LEDs (Power, 2G, 5G, WPS(x2), Lan(x2)) - 4x buttons (Reset, Power, WPS, LED) - UART pinout - GND, RX, TX, labeled in the middle of the PCB, requires soldering because they're not through holes. Serial console @ 57600,8n1 .. Hauke ___ 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: [PATCH v2] build: target: improve UX of CONFIG_TARGET handling
On 12.04.2022 14:39, Petr Štetiar wrote:
Make it clear, that for `make kernel_{menu,old}config` it's possible to
use only following values for CONFIG_TARGET variable:
* env
* target
* subtarget
* subtarget_target
This should prevent misuse like `make kernel_menuconfig
CONFIG_TARGET=bcm2710` etc.
Keep support for obsolete `platform` and `subtarget_platform` targets
with deprecation notice so this compat stuff could be removed in the
future.
Signed-off-by: Petr Štetiar
Acked-by: Piotr Dymacz
Thanks!
--
Cheers,
Piotr
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH 21.02] ramips: fix reboot for remaining 32 MB boards
From: Michael Pratt
The following devices have a Winbond W25Q256FV flash chip,
which does not have the RESET pin enabled by default,
and otherwise would require setting a bit in a status register.
Before moving to Linux 5.4, we had the patch:
0053-mtd-spi-nor-add-w25q256-3b-mode-switch.patch
which kept specific flash chips with explicit 3-byte and 4-byte address modes
to stay in 3-byte address mode while idle (after an erase or write)
by using a custom flag SPI_NOR_4B_READ_OP that was part of the patch.
this was obsoleted by the patch:
481-mtd-spi-nor-rework-broken-flash-reset-support.patch
which uses the newer upstream flag SNOR_F_BROKEN_RESET
for devices with a flash chip that cannot be hardware reset with RESET pin
and therefore must be left in 3-byte address mode when idle.
The new patch requires that the DTS of affected devices
have the property "broken-flash-reset", which was not yet added for most of
them.
This commit adds the property for remaining affected devices in ramips target,
specifically because of the flash chip model.
However, it is possible that there are other devices
where the flash chip uses an explicit 4-byte address mode
and the RESET pin is not connected to the SOC on the board,
and those DTS would also need this property.
Ref: 22d982ea0033 ("ramips: add support for switching between 3-byte and 4-byte
addressing")
Ref: dfa521f12953 ("generic: spi-nor: rework broken-flash-reset")
Signed-off-by: Michael Pratt
[pep...@gmail.com: backported to 21.02]
Fixes: #9655, #9636, #9547
Signed-off-by: Piotr Dymacz
(backported from commit 74516f4357d281f093f0daac01c4c5c239acc443)
---
target/linux/ramips/dts/mt7620a_zbtlink_zbt-we1026-h-32m.dts | 4
target/linux/ramips/dts/mt7620a_zbtlink_zbt-we1026.dtsi | 2 +-
target/linux/ramips/dts/mt7620a_zbtlink_zbt-we826-32m.dts| 1 +
target/linux/ramips/dts/mt7620a_zbtlink_zbt-we826-e.dts | 1 +
target/linux/ramips/dts/mt7621_glinet_gl-mt1300.dts | 1 +
target/linux/ramips/dts/mt7621_xiaoyu_xy-c5.dts | 1 +
target/linux/ramips/dts/mt7621_zbtlink_zbt-wg3526-32m.dts| 4
target/linux/ramips/dts/mt7621_zbtlink_zbt-wg3526.dtsi | 2 +-
target/linux/ramips/dts/mt7628an_hak5_wifi-pineapple-mk7.dts | 1 +
target/linux/ramips/dts/mt7628an_hilink_hlk-7688a.dts| 1 +
target/linux/ramips/dts/mt7628an_jotale_js76x8-32m.dts | 4
target/linux/ramips/dts/mt7628an_jotale_js76x8.dtsi | 2 +-
target/linux/ramips/dts/mt7628an_onion_omega2.dtsi | 2 +-
target/linux/ramips/dts/mt7628an_onion_omega2p.dts | 4
target/linux/ramips/dts/mt7628an_widora_neo-32m.dts | 1 +
target/linux/ramips/dts/mt7628an_wiznet_wizfi630s.dts| 1 +
target/linux/ramips/dts/mt7628an_wrtnode_wrtnode2.dtsi | 1 +
target/linux/ramips/dts/mt7628an_zyxel_keenetic-extra-ii.dts | 1 +
18 files changed, 30 insertions(+), 4 deletions(-)
diff --git a/target/linux/ramips/dts/mt7620a_zbtlink_zbt-we1026-h-32m.dts
b/target/linux/ramips/dts/mt7620a_zbtlink_zbt-we1026-h-32m.dts
index 0fc8fc60e4..577e7e05e9 100644
--- a/target/linux/ramips/dts/mt7620a_zbtlink_zbt-we1026-h-32m.dts
+++ b/target/linux/ramips/dts/mt7620a_zbtlink_zbt-we1026-h-32m.dts
@@ -8,6 +8,10 @@
model = "Zbtlink ZBT-WE1026-H (32M)";
};
+&flash0 {
+ broken-flash-reset;
+};
+
&firmware {
reg = <0x5 0x1fb>;
};
diff --git a/target/linux/ramips/dts/mt7620a_zbtlink_zbt-we1026.dtsi
b/target/linux/ramips/dts/mt7620a_zbtlink_zbt-we1026.dtsi
index 91bbd4a044..3dae6d9515 100644
--- a/target/linux/ramips/dts/mt7620a_zbtlink_zbt-we1026.dtsi
+++ b/target/linux/ramips/dts/mt7620a_zbtlink_zbt-we1026.dtsi
@@ -30,7 +30,7 @@
&spi0 {
status = "okay";
- flash@0 {
+ flash0: flash@0 {
compatible = "jedec,spi-nor";
reg = <0>;
spi-max-frequency = <1000>;
diff --git a/target/linux/ramips/dts/mt7620a_zbtlink_zbt-we826-32m.dts
b/target/linux/ramips/dts/mt7620a_zbtlink_zbt-we826-32m.dts
index 6f5bc41d5d..ad07682c98 100644
--- a/target/linux/ramips/dts/mt7620a_zbtlink_zbt-we826-32m.dts
+++ b/target/linux/ramips/dts/mt7620a_zbtlink_zbt-we826-32m.dts
@@ -12,6 +12,7 @@
compatible = "jedec,spi-nor";
reg = <0>;
spi-max-frequency = <1000>;
+ broken-flash-reset;
partitions {
compatible = "fixed-partitions";
diff --git a/target/linux/ramips/dts/mt7620a_zbtlink_zbt-we826-e.dts
b/target/linux/ramips/dts/mt7620a_zbtlink_zbt-we826-e.dts
index bce6afe263..69502111fa 100644
--- a/target/linux/ramips/dts/mt7620a_zbtlink_zbt-we826-e.dts
+++ b/target/linux/ramips/dts/mt7620a_zbtlink_zbt-we826-e.dts
@@ -40,6 +40,7 @@
compatible = "jedec,spi-nor";
reg = <0>;
[PATCH 2/4] imx: bootscript-apalis: make it working with U-Boot 2022.01
From: Petr Štetiar
Upstream in commit 8b9c0cb46471 ("apalis_imx6: boot env configuration
updates") removed emmc legacy wrappers, but so far didn't included any
replacements. Fix it by simply defining the missing variables and UUID
gathering directly into the boot script.
Signed-off-by: Petr Štetiar
[pep...@gmail.com: updated commit title for 2022.01]
Signed-off-by: Piotr Dymacz
---
target/linux/imx/image/bootscript-toradex_apalis | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/target/linux/imx/image/bootscript-toradex_apalis
b/target/linux/imx/image/bootscript-toradex_apalis
index 3a3a6dadb1..f163b92ed0 100644
--- a/target/linux/imx/image/bootscript-toradex_apalis
+++ b/target/linux/imx/image/bootscript-toradex_apalis
@@ -1,13 +1,15 @@
echo "Toradex Apalis OpenWrt Boot script v1.1"
-run emmcfinduuid
+setenv mmcdev 0
+setenv mmcrootpart 2
+part uuid mmc ${mmcdev}:${mmcrootpart} uuid
setenv nextcon 0
setenv boot_file uImage
setenv fdt_file imx6q-apalis-ixora.dtb
setenv root root=PARTUUID=${uuid} rootfstype=squashfs rootwait
setenv bootargs earlyprintk console=${console},${baudrate}n8 ${root}
-setenv fsload ext4load mmc ${emmcdev}:${emmcbootpart}
+setenv fsload ext4load mmc ${mmcdev}:${mmcbootpart}
if ${fsload} ${kernel_addr_r} ${boot_file}; then
if ${fsload} ${fdt_addr_r} ${fdt_file}; then
--
2.35.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH 1/4] uboot-imx: bump to 2022.01 release
Two patches were removed because of the changes introduced in upstream:
1. 110-mx6cuboxi-mmc-fallback.patch
Looks like similar changes were introduced in 6c3fbf3e456c ("mx6cuboxi:
customize board_boot_order to access eMMC").
2. 111-mx6cuboxi_defconfig-force-mmc-boot.patch
The 'CONFIG_SPL_FORCE_MMC_BOOT' was removed in 15aec318ef03 ("Revert
"imx: Introduce CONFIG_SPL_FORCE_MMC_BOOT to force MMC boot on falcon
mode").
Signed-off-by: Piotr Dymacz
---
package/boot/uboot-imx/Makefile | 4 ++--
...efconfig-enable-some-useful-commands.patch | 21 -
.../patches/110-mx6cuboxi-mmc-fallback.patch | 15
...1-mx6cuboxi_defconfig-force-mmc-boot.patch | 23 ---
4 files changed, 7 insertions(+), 56 deletions(-)
delete mode 100644
package/boot/uboot-imx/patches/110-mx6cuboxi-mmc-fallback.patch
delete mode 100644
package/boot/uboot-imx/patches/111-mx6cuboxi_defconfig-force-mmc-boot.patch
diff --git a/package/boot/uboot-imx/Makefile b/package/boot/uboot-imx/Makefile
index 2faa48bd73..d5f595 100644
--- a/package/boot/uboot-imx/Makefile
+++ b/package/boot/uboot-imx/Makefile
@@ -7,10 +7,10 @@
include $(TOPDIR)/rules.mk
-PKG_VERSION:=2020.04
+PKG_VERSION:=2022.01
PKG_RELEASE:=$(AUTORELEASE)
-PKG_HASH:=fe732aaf037d9cc3c0909bad8362af366ae964bbdac6913a34081ff4ad565372
+PKG_HASH:=81b4543227db228c03f8a1bf5ddbc813b0bb8f6555ce46064ef721a6fc680413
include $(INCLUDE_DIR)/u-boot.mk
include $(INCLUDE_DIR)/package.mk
diff --git
a/package/boot/uboot-imx/patches/0001-apalis_imx6_defconfig-enable-some-useful-commands.patch
b/package/boot/uboot-imx/patches/0001-apalis_imx6_defconfig-enable-some-useful-commands.patch
index 10ed918e77..ee50b071e0 100644
---
a/package/boot/uboot-imx/patches/0001-apalis_imx6_defconfig-enable-some-useful-commands.patch
+++
b/package/boot/uboot-imx/patches/0001-apalis_imx6_defconfig-enable-some-useful-commands.patch
@@ -16,22 +16,11 @@ Signed-off-by: Petr Štetiar
--- a/configs/apalis_imx6_defconfig
+++ b/configs/apalis_imx6_defconfig
-@@ -44,6 +44,7 @@ CONFIG_CMD_GPIO=y
- CONFIG_CMD_GPT=y
- CONFIG_CMD_I2C=y
- CONFIG_CMD_MMC=y
-+CONFIG_CMD_PART=y
- CONFIG_CMD_USB=y
- CONFIG_CMD_USB_SDP=y
- CONFIG_CMD_USB_MASS_STORAGE=y
-@@ -53,6 +54,10 @@ CONFIG_CMD_PMIC=y
+@@ -60,6 +60,7 @@ CONFIG_CMD_CACHE=y
+ CONFIG_CMD_TIME=y
+ CONFIG_CMD_PMIC=y
CONFIG_CMD_REGULATOR=y
- CONFIG_OF_CONTROL=y
- CONFIG_DEFAULT_DEVICE_TREE="imx6-apalis"
-+CONFIG_CMD_EXT4=y
+CONFIG_CMD_EXT4_WRITE=y
-+CONFIG_CMD_FAT=y
-+CONFIG_CMD_FS_GENERIC=y
+ CONFIG_OF_CONTROL=y
+ CONFIG_ENV_OVERWRITE=y
CONFIG_ENV_IS_IN_MMC=y
- CONFIG_SYS_RELOC_GD_ENV_ADDR=y
- CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG=y
diff --git a/package/boot/uboot-imx/patches/110-mx6cuboxi-mmc-fallback.patch
b/package/boot/uboot-imx/patches/110-mx6cuboxi-mmc-fallback.patch
deleted file mode 100644
index 9d490ddf7e..00
--- a/package/boot/uboot-imx/patches/110-mx6cuboxi-mmc-fallback.patch
+++ /dev/null
@@ -1,15 +0,0 @@
a/board/solidrun/mx6cuboxi/mx6cuboxi.c
-+++ b/board/solidrun/mx6cuboxi/mx6cuboxi.c
-@@ -286,6 +286,12 @@ static void setup_iomux_enet(void)
- gpio_free_list_nodev(&desc, 1);
- }
-
-+void board_boot_order(u32 *spl_boot_list)
-+{
-+ spl_boot_list[0] = spl_boot_device();
-+ spl_boot_list[1] = BOOT_DEVICE_MMC1;
-+}
-+
- int board_phy_config(struct phy_device *phydev)
- {
- if (phydev->drv->config)
diff --git
a/package/boot/uboot-imx/patches/111-mx6cuboxi_defconfig-force-mmc-boot.patch
b/package/boot/uboot-imx/patches/111-mx6cuboxi_defconfig-force-mmc-boot.patch
deleted file mode 100644
index 4c3dc4ce20..00
---
a/package/boot/uboot-imx/patches/111-mx6cuboxi_defconfig-force-mmc-boot.patch
+++ /dev/null
@@ -1,23 +0,0 @@
-From 00ad8b42dfe801107db25ead8249cb10afcd0f94 Mon Sep 17 00:00:00 2001
-From: =?UTF-8?q?Petr=20=C5=A0tetiar?=
-Date: Sun, 1 Mar 2020 22:10:23 +0100
-Subject: [PATCH] mx6cuboxi_defconfig: force mmc boot
-MIME-Version: 1.0
-Content-Type: text/plain; charset=UTF-8
-Content-Transfer-Encoding: 8bit
-
-Signed-off-by: Petr Štetiar
- configs/mx6cuboxi_defconfig | 1 +
- 1 file changed, 1 insertion(+)
-
a/configs/mx6cuboxi_defconfig
-+++ b/configs/mx6cuboxi_defconfig
-@@ -9,6 +9,7 @@ CONFIG_ENV_SIZE=0x2000
- CONFIG_ENV_OFFSET=0xFE000
- CONFIG_DM_GPIO=y
- CONFIG_SPL_MMC_SUPPORT=y
-+CONFIG_SPL_FORCE_MMC_BOOT=y
- CONFIG_SPL_SERIAL_SUPPORT=y
- CONFIG_NR_DRAM_BANKS=1
- CONFIG_SPL=y
--
2.35.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH 4/4] uboot-imx: build 'u-boot-dtb.img' for SolidRun CuBox-i
Signed-off-by: Piotr Dymacz --- package/boot/uboot-imx/Makefile | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/package/boot/uboot-imx/Makefile b/package/boot/uboot-imx/Makefile index d5f595..63f145798d 100644 --- a/package/boot/uboot-imx/Makefile +++ b/package/boot/uboot-imx/Makefile @@ -30,8 +30,8 @@ endef define U-Boot/mx6cuboxi NAME:=SolidRun Cubox-i boards - UBOOT_IMAGE:=SPL u-boot.img - UBOOT_MAKE_FLAGS:=SPL u-boot.img + UBOOT_IMAGE:=SPL u-boot-dtb.img + UBOOT_MAKE_FLAGS:=SPL u-boot-dtb.img BUILD_SUBTARGET:=cortexa9 BUILD_DEVICES:=solidrun_cubox-i endef -- 2.35.1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH 3/4] imx: image: use 'u-boot-dtb.img' filename for SPL payload
For targets in U-Boot which were migrated to DM, the correct binary image filename will be 'u-boot-dtb.img'. For backward compatibility, keep support for both files and use the one which was generated with our 'uboot-imx' package. See also 'CONFIG_SPL_FS_LOAD_PAYLOAD_NAME' and 'CONFIG_OF_CONTROL' in mainline U-Boot sources. Signed-off-by: Piotr Dymacz --- target/linux/imx/image/cortexa9.mk | 11 ++- 1 file changed, 10 insertions(+), 1 deletion(-) diff --git a/target/linux/imx/image/cortexa9.mk b/target/linux/imx/image/cortexa9.mk index 75e19dc694..17a507b8da 100644 --- a/target/linux/imx/image/cortexa9.mk +++ b/target/linux/imx/image/cortexa9.mk @@ -80,7 +80,16 @@ endef define Build/imx6-sdcard $(Build/imx6-combined-image-prepare) - $(CP) $(STAGING_DIR_IMAGE)/$(UBOOT)-u-boot.img $@.boot/u-boot.img + if [ -f $(STAGING_DIR_IMAGE)/$(UBOOT)-u-boot.img ]; then \ + $(CP) $(STAGING_DIR_IMAGE)/$(UBOOT)-u-boot.img \ + $@.boot/u-boot.img; \ + fi + + if [ -f $(STAGING_DIR_IMAGE)/$(UBOOT)-u-boot-dtb.img ]; then \ + $(CP) $(STAGING_DIR_IMAGE)/$(UBOOT)-u-boot-dtb.img \ + $@.boot/u-boot-dtb.img; \ + fi + $(Build/imx6-combined-image) dd if=$(STAGING_DIR_IMAGE)/$(UBOOT)-SPL of=$@ bs=1024 seek=1 conv=notrunc -- 2.35.1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] build: target: improve UX of CONFIG_TARGET handling
Hi Petr,
On 29.03.2022 12:55, Petr Štetiar wrote:
Piotr Dymacz [2022-03-29 10:10:00]:
Hi,
It seems I've been misusing 'target' for a long time and now I'm trying to
understand how this leads to the same behavior as 'platform' :)
comments right above that code states following:
# defaults to subtarget if subtarget exists and target does not
# defaults to target otherwise
Should we maybe make 'target' as a valid value?
It's consumed by developers, so I wouldn't waste time and complicate the code
with such band aids for wrong documentation, I would simply fix the
documentation instead.
My suggestion was only about keeping things with reality. Even the
comments above, in the code you mentioned, refer to 'target' and
'subtarget', not 'platform'.
I might be simply wrong here but I believe most of us refer to 'target',
not 'platform' these days. That was the reason for my idea about
'{subtarget_}target', while keeping backward compatibility with the
'platform' but I'm really fine keeping it this way and fixing Wiki.
btw, CONFIG_TARGET=platform|subtarget|env was introduced in2011, in
caf4747f0c.
--
Cheers,
Piotr
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] build: target: improve UX of CONFIG_TARGET handling
Hi Petr,
On 29.03.2022 08:34, Petr Štetiar wrote:
Make it clear, that for `make kernel_{menu,old}config` it's possible to
use only following values for CONFIG_TARGET variable:
* env
* platform
* subtarget
* subtarget_platform
It seems I've been misusing 'target' for a long time and now I'm trying
to understand how this leads to the same behavior as 'platform' :)
Some recent changes show also one more invalid value: 'generic':
4c5d5c66ca ipq806x: 5:15: refresh config
5e43dd1fa7 kernel: bump 5.10 to 5.10.99
There are references to 'target' on our forum and even on the Wiki (!):
https://openwrt.org/docs/guide-developer/toolchain/use-buildsystem#kernel_configuration_optional
Should we maybe make 'target' as a valid value?
--
Cheers,
Piotr
This should prevent misuse like `make kernel_menuconfig CONFIG_TARGET=bcm2710`
etc.
Signed-off-by: Petr Štetiar
---
include/target.mk | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/include/target.mk b/include/target.mk
index 72fe493776b9..444cc032400f 100644
--- a/include/target.mk
+++ b/include/target.mk
@@ -177,18 +177,17 @@ LINUX_RECONFIG_TARGET = $(if
$(USE_SUBTARGET_CONFIG),$(LINUX_SUBTARGET_CONFIG),$
ifeq ($(CONFIG_TARGET),platform)
LINUX_RECONFIG_LIST = $(wildcard $(GENERIC_LINUX_CONFIG)
$(LINUX_TARGET_CONFIG))
LINUX_RECONFIG_TARGET = $(LINUX_TARGET_CONFIG)
-endif
-ifeq ($(CONFIG_TARGET),subtarget)
+else ifeq ($(CONFIG_TARGET),subtarget)
LINUX_RECONFIG_LIST = $(wildcard $(GENERIC_LINUX_CONFIG)
$(LINUX_TARGET_CONFIG) $(LINUX_SUBTARGET_CONFIG))
LINUX_RECONFIG_TARGET = $(LINUX_SUBTARGET_CONFIG)
-endif
-ifeq ($(CONFIG_TARGET),subtarget_platform)
+else ifeq ($(CONFIG_TARGET),subtarget_platform)
LINUX_RECONFIG_LIST = $(wildcard $(GENERIC_LINUX_CONFIG)
$(LINUX_SUBTARGET_CONFIG) $(LINUX_TARGET_CONFIG))
LINUX_RECONFIG_TARGET = $(LINUX_TARGET_CONFIG)
-endif
-ifeq ($(CONFIG_TARGET),env)
+else ifeq ($(CONFIG_TARGET),env)
LINUX_RECONFIG_LIST = $(LINUX_KCONFIG_LIST)
LINUX_RECONFIG_TARGET = $(TOPDIR)/env/kernel-config
+else ifneq ($(strip $(CONFIG_TARGET)),)
+ $(error ERROR: CONFIG_TARGET="$(CONFIG_TARGET)" invalid, use one of
`platform`, `subtarget`, `subtarget_platform` or `env`)
endif
__linux_confcmd = $(2) $(patsubst %,+,$(wordlist 2,,$(1))) $(1)
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH v2 1/2] firmware-utils: bump to git HEAD
Hi Stijn, On 26.02.2022 11:11, Stijn Tintel wrote: 57d0e31 tplink-safeloader: TP-Link EAP615-Wall v1 support There were more changes: eea4ee7 tplink-safeloader: add TP-Link Archer A9 v6 support 8a8da19 tplink-safeloader: add TL-WPA8631P v3 support 57d0e31 tplink-safeloader: TP-Link EAP615-Wall v1 support 2ca6462 iptime-crc32: add support for AX8004M 497726b firmware-utils: support checksum for AVM fritzbox wasp SOCs 706e9cc tplink-safeloader: support for Archer A6 v3 JP Current version is: 872c87c iptime-crc32: add image header tool for new ipTIME models -- Cheers, Piotr Signed-off-by: Stijn Tintel --- tools/firmware-utils/Makefile | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/tools/firmware-utils/Makefile b/tools/firmware-utils/Makefile index 60e0c74b45..5a1f4db077 100644 --- a/tools/firmware-utils/Makefile +++ b/tools/firmware-utils/Makefile @@ -11,9 +11,9 @@ PKG_RELEASE:=1 PKG_SOURCE_PROTO:=git PKG_SOURCE_URL=$(PROJECT_GIT)/project/firmware-utils.git -PKG_SOURCE_DATE:=2022-01-29 -PKG_SOURCE_VERSION:=872c87c6805bea08677de71b744cce7deb24903e -PKG_MIRROR_HASH:=e9bb14bca59485345c9f109f6ee2aec709e4d29cd389e3b05447a91c06806cf8 +PKG_SOURCE_DATE:=2022-02-20 +PKG_SOURCE_VERSION:=57d0e315cdaa34c922218e4d6851b52a71346786 +PKG_MIRROR_HASH:=b5b5fc15a5f4dcd8e05585ec54155c20e884368725ed4ded87aeadda267f04b8 include $(INCLUDE_DIR)/host-build.mk include $(INCLUDE_DIR)/cmake.mk ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] tplink-safeloader: add WPA8631P v3 support
Hi Joe, On 23.02.2022 00:59, jwmulla...@gmail.com wrote: From: Joe Mullally Enable creating images compatible with TP-Link's WPA8631P powerline router. This matches all current firmwares for all revisions and regions. Users with older EU "Build 20200314 Rel.3608" & EU "Build 20200508 Rel.41814" should first upgrade to EU "Build 20200927 Rel.61199" or later before flashing. [...] Thanks, merged! -- Cheers, Piotr ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] u-boot-tools: add new package for mkimage & dumpimage
Hi Rafał, On 30.11.2021 14:00, Rafał Miłecki wrote: From: Rafał Miłecki Those tools can be useful for targets that use ITB firmware format. They may need them to extract firmware images to flash them. Truly a cosmetic thing but all other U-Boot related packages we currently carry in the tree are named "uboot-..." (no dash). -- Cheers, Piotr Signed-off-by: Rafał Miłecki --- package/boot/u-boot-tools/Makefile| 50 +++ .../patches/0001-tools-disable-kwbimage.patch | 25 ++ 2 files changed, 75 insertions(+) create mode 100644 package/boot/u-boot-tools/Makefile create mode 100644 package/boot/u-boot-tools/patches/0001-tools-disable-kwbimage.patch diff --git a/package/boot/u-boot-tools/Makefile b/package/boot/u-boot-tools/Makefile new file mode 100644 index 00..e77e27e679 --- /dev/null +++ b/package/boot/u-boot-tools/Makefile @@ -0,0 +1,50 @@ +# SPDX-License-Identifier: GPL-2.0-only + +include $(TOPDIR)/rules.mk + +PKG_NAME:=u-boot-tools +PKG_DISTNAME:=u-boot +PKG_VERSION:=2021.10 +PKG_RELEASE:=$(AUTORELEASE) + +PKG_SOURCE:=$(PKG_DISTNAME)-$(PKG_VERSION).tar.bz2 +PKG_SOURCE_URL:= \ +https://ftp.denx.de/pub/u-boot \ +ftp://ftp.denx.de/pub/u-boot \ +https://mirror.cyberbits.eu/u-boot +PKG_HASH:=cde723e19262e646f2670d25e5ec4b1b368490de950d4e26275a988c36df0bd4 +PKG_SOURCE_SUBDIR:=$(PKG_DISTNAME)-$(PKG_VERSION) +PKG_BUILD_DIR:=$(BUILD_DIR)/$(PKG_DISTNAME)-$(PKG_VERSION) + +PKG_LICENSE:=GPL-2.0+ +PKG_LICENSE_FILES:=Licenses/README + +include $(INCLUDE_DIR)/package.mk + +define Package/u-boot-tools + SECTION:=utils + CATEGORY:=Utilities + SUBMENU:=Boot Loaders + TITLE:=U-Boot tools + URL:=https://www.denx.de/wiki/U-Boot +endef + +define Build/Configure + $(MAKE) -C $(PKG_BUILD_DIR) defconfig + $(MAKE) -C $(PKG_BUILD_DIR) syncconfig + $(SED) 's/CONFIG_TOOLS_LIBCRYPTO=y/# CONFIG_TOOLS_LIBCRYPTO is not set/' $(PKG_BUILD_DIR)/.config +endef + +ifeq ($(ARCH),aarch64) +MAKE_FLAGS += ARCH=arm cross_tools +else +MAKE_FLAGS += cross_tools +endif + +define Package/u-boot-tools/install + $(INSTALL_DIR) $(1)/usr/bin + $(INSTALL_BIN) $(PKG_BUILD_DIR)/tools/dumpimage $(1)/usr/bin + $(INSTALL_BIN) $(PKG_BUILD_DIR)/tools/mkimage $(1)/usr/bin +endef + +$(eval $(call BuildPackage,u-boot-tools)) diff --git a/package/boot/u-boot-tools/patches/0001-tools-disable-kwbimage.patch b/package/boot/u-boot-tools/patches/0001-tools-disable-kwbimage.patch new file mode 100644 index 00..69a42ec383 --- /dev/null +++ b/package/boot/u-boot-tools/patches/0001-tools-disable-kwbimage.patch @@ -0,0 +1,25 @@ +From: =?UTF-8?q?Rafa=C5=82=20Mi=C5=82ecki?= +Date: Tue, 30 Nov 2021 11:29:19 +0100 +Subject: [PATCH] tools: disable kwbimage +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +Without CONFIG_TOOLS_LIBCRYPTO kwbimage doesn't compile because of +multiple "undefined reference"s to SSL functions. + +Signed-off-by: Rafał Miłecki +--- + tools/Makefile | 1 - + 1 file changed, 1 deletion(-) + +--- a/tools/Makefile b/tools/Makefile +@@ -117,7 +117,6 @@ dumpimage-mkimage-objs := aisimage.o \ + imximage.o \ + imx8image.o \ + imx8mimage.o \ +- kwbimage.o \ + lib/md5.o \ + lpc32xximage.o \ + mxsimage.o \ ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: OpenWrt imx split status?
Hi, On 05.10.2021 18:45, ＠SRCHACK.ORG wrote: Hi Tim-san, Piotr-san I have an on OpenWrt based buildroot with an i.MX8M mini board. Is it a custom board? Can you tell something more about it? Since I used linux-imx, uboot-imx. it is not a code that can be merged into the original master. It running for Japanese communication robot. start porting to i.MX8M on openwrt master? I want to help as much as possible, when I have time. I just sent the patch series with imx6 to imx with arch-specific subtargets conversion: [1]. I suppose that i.MX 8M based devices should go to 'imx/cortexa53'. Please check my 'imx/cortexa7' subtarget creation commit and if you want and have time, follow it (you would need some basics like image building code and kernel config-default, then you can go step by step, ideally testing some initramfs image). [1] https://patchwork.ozlabs.org/project/openwrt/list/?series=266900 -- Cheers, Piotr On 2021/10/06 0:55, Tim Harvey wrote: On Tue, Oct 5, 2021 at 8:42 AM Piotr Dymacz wrote: Hi Tim, On 04.10.2021 00:22, Tim Harvey wrote: Piotr, How is your progress regarding submitting patches to OpenWrt to split the imx target into multiple arch related subtargets (like cortexa7, cortexa9)? I'm planning to clean it up and send patches this week. I finally got final revision of the hardware I was working on that for. Thanks, please Cc me on those when you submit. Is anyone working on i.MX8 support that you know of? I have seen people ask for it in the past but nobody has been persistent about it. I'm not aware of anyone working on something with i.MX8. Do you plan to work on Venice series support in OpenWrt? Perhaps eventually but it is not a priority at the moment. Best regards, Tim ___ 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
[PATCH 14/14] imx: remove obsolete Kernel 5.4
Signed-off-by: Piotr Dymacz --- target/linux/imx/config-5.4 | 420 - ...ARM-dts-imx-Add-GW5907-board-support.patch | 481 --- ...ARM-dts-imx-Add-GW5910-board-support.patch | 581 -- ...ARM-dts-imx-Add-GW5913-board-support.patch | 434 - ...ARM-dts-imx-Add-GW5912-board-support.patch | 549 - ...gw553x-add-lsm9ds1-iio-imu-magn-supp.patch | 68 -- ...ana-add-fxos8700-on-gateworks-boards.patch | 57 -- ...M-dts-imx6qdl-gw5910-add-CC1352-UART.patch | 54 -- ...s-imx6qdl-gw552x-add-USB-OTG-support.patch | 45 -- ...gw560x-add-lsm9ds1-iio-imu-magn-supp.patch | 76 --- ...gw5904-add-lsm9ds1-iio-imu-magn-supp.patch | 69 --- ...dl-gw5910-add-support-for-bcm4330-bt.patch | 82 --- ...ts-imx6qdl-gw5910-fix-wlan-regulator.patch | 33 - .../linux/imx/patches-5.4/100-bootargs.patch | 11 - .../301-apalis-ixora-dts-leds.patch | 86 --- .../302-apalis-ixora-dts-reset-button.patch | 76 --- 16 files changed, 3122 deletions(-) delete mode 100644 target/linux/imx/config-5.4 delete mode 100644 target/linux/imx/patches-5.4/001-ARM-dts-imx-Add-GW5907-board-support.patch delete mode 100644 target/linux/imx/patches-5.4/002-ARM-dts-imx-Add-GW5910-board-support.patch delete mode 100644 target/linux/imx/patches-5.4/003-ARM-dts-imx-Add-GW5913-board-support.patch delete mode 100644 target/linux/imx/patches-5.4/004-ARM-dts-imx-Add-GW5912-board-support.patch delete mode 100644 target/linux/imx/patches-5.4/005-v5.7-ARM-dts-imx6qdl-gw553x-add-lsm9ds1-iio-imu-magn-supp.patch delete mode 100644 target/linux/imx/patches-5.4/006-v5.7-ARM-dts-imx-ventana-add-fxos8700-on-gateworks-boards.patch delete mode 100644 target/linux/imx/patches-5.4/006-v5.7-ARM-dts-imx6qdl-gw5910-add-CC1352-UART.patch delete mode 100644 target/linux/imx/patches-5.4/006-v5.8-ARM-dts-imx6qdl-gw552x-add-USB-OTG-support.patch delete mode 100644 target/linux/imx/patches-5.4/007-v5.8-ARM-dts-imx6qdl-gw560x-add-lsm9ds1-iio-imu-magn-supp.patch delete mode 100644 target/linux/imx/patches-5.4/008-v5.8-ARM-dts-imx6qdl-gw5904-add-lsm9ds1-iio-imu-magn-supp.patch delete mode 100644 target/linux/imx/patches-5.4/009-v5.8-ARM-dts-imx6qdl-gw5910-add-support-for-bcm4330-bt.patch delete mode 100644 target/linux/imx/patches-5.4/010-v5.8-ARM-dts-imx6qdl-gw5910-fix-wlan-regulator.patch delete mode 100644 target/linux/imx/patches-5.4/100-bootargs.patch delete mode 100644 target/linux/imx/patches-5.4/301-apalis-ixora-dts-leds.patch delete mode 100644 target/linux/imx/patches-5.4/302-apalis-ixora-dts-reset-button.patch diff --git a/target/linux/imx/config-5.4 b/target/linux/imx/config-5.4 deleted file mode 100644 index 3e6cf4746a..00 --- a/target/linux/imx/config-5.4 +++ /dev/null @@ -1,420 +0,0 @@ -CONFIG_ALIGNMENT_TRAP=y -CONFIG_ARCH_32BIT_OFF_T=y -CONFIG_ARCH_CLOCKSOURCE_DATA=y -CONFIG_ARCH_HIBERNATION_POSSIBLE=y -CONFIG_ARCH_KEEP_MEMBLOCK=y -CONFIG_ARCH_MIGHT_HAVE_PC_PARPORT=y -CONFIG_ARCH_MMAP_RND_BITS_MAX=15 -CONFIG_ARCH_MULTIPLATFORM=y -CONFIG_ARCH_MULTI_V6_V7=y -CONFIG_ARCH_MULTI_V7=y -CONFIG_ARCH_MXC=y -CONFIG_ARCH_NR_GPIO=0 -CONFIG_ARCH_OPTIONAL_KERNEL_RWX=y -CONFIG_ARCH_OPTIONAL_KERNEL_RWX_DEFAULT=y -CONFIG_ARCH_SUSPEND_POSSIBLE=y -CONFIG_ARM=y -CONFIG_ARM_CRYPTO=y -CONFIG_ARM_ERRATA_754322=y -CONFIG_ARM_ERRATA_764369=y -CONFIG_ARM_ERRATA_775420=y -CONFIG_ARM_ERRATA_814220=y -CONFIG_ARM_HAS_SG_CHAIN=y -CONFIG_ARM_HEAVY_MB=y -# CONFIG_ARM_IMX_CPUFREQ_DT is not set -CONFIG_ARM_L1_CACHE_SHIFT=6 -CONFIG_ARM_L1_CACHE_SHIFT_6=y -CONFIG_ARM_PATCH_IDIV=y -CONFIG_ARM_PATCH_PHYS_VIRT=y -CONFIG_ARM_THUMB=y -CONFIG_ARM_UNWIND=y -CONFIG_ARM_VIRT_EXT=y -CONFIG_ASN1=y -CONFIG_ASSOCIATIVE_ARRAY=y -CONFIG_ATA=y -CONFIG_ATAGS=y -# CONFIG_ATA_SFF is not set -CONFIG_AUTO_ZRELADDR=y -CONFIG_BINFMT_FLAT_ARGVP_ENVP_ON_STACK=y -CONFIG_BLK_DEV_LOOP=y -CONFIG_BLK_PM=y -CONFIG_BLK_SCSI_REQUEST=y -CONFIG_CACHE_L2X0=y -CONFIG_CLKDEV_LOOKUP=y -CONFIG_CLKSRC_IMX_GPT=y -CONFIG_CLKSRC_MMIO=y -CONFIG_CLONE_BACKWARDS=y -CONFIG_CLZ_TAB=y -CONFIG_COMMON_CLK=y -CONFIG_COMPAT_32BIT_TIME=y -CONFIG_CPUFREQ_DT=y -CONFIG_CPUFREQ_DT_PLATDEV=y -CONFIG_CPU_32v6K=y -CONFIG_CPU_32v7=y -CONFIG_CPU_ABRT_EV7=y -CONFIG_CPU_CACHE_V7=y -CONFIG_CPU_CACHE_VIPT=y -CONFIG_CPU_COPY_V6=y -CONFIG_CPU_CP15=y -CONFIG_CPU_CP15_MMU=y -CONFIG_CPU_FREQ=y -CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE=y -CONFIG_CPU_FREQ_GOV_ATTR_SET=y -CONFIG_CPU_FREQ_GOV_COMMON=y -CONFIG_CPU_FREQ_GOV_CONSERVATIVE=y -CONFIG_CPU_FREQ_GOV_ONDEMAND=y -CONFIG_CPU_FREQ_GOV_PERFORMANCE=y -CONFIG_CPU_FREQ_GOV_POWERSAVE=y -CONFIG_CPU_FREQ_GOV_SCHEDUTIL=y -CONFIG_CPU_FREQ_GOV_USERSPACE=y -CONFIG_CPU_FREQ_STAT=y -CONFIG_CPU_HAS_ASID=y -CONFIG_CPU_PABRT_V7=y -CONFIG_CPU_RMAP=y -CONFIG_CPU_SPECTRE=y -CONFIG_CPU_THERMAL=y -CONFIG_CPU_THUMB_CAPABLE=y -CONFIG_CPU_TLB_V7=y -CONFIG_CPU_V7=y -CONFIG_CRC16=y -CONFIG_CRYPTO_ACOMP2=y -CONFIG_CRYPTO_AEAD=y -CONFIG_CRYPTO_AEAD2=y -CONFIG_CRYPTO_AES_ARM=y -CONFIG_CRYPTO_AES_ARM_BS=y
[PATCH 13/14] imx: update subtargets default kernel configs for 5.10
Signed-off-by: Piotr Dymacz --- target/linux/imx/cortexa7/config-default | 5 - target/linux/imx/cortexa9/config-default | 7 ++- 2 files changed, 10 insertions(+), 2 deletions(-) diff --git a/target/linux/imx/cortexa7/config-default b/target/linux/imx/cortexa7/config-default index eb1986769e..b91c01cd56 100644 --- a/target/linux/imx/cortexa7/config-default +++ b/target/linux/imx/cortexa7/config-default @@ -1,5 +1,6 @@ CONFIG_ARM_CPU_SUSPEND=y CONFIG_ARM_GIC=y +CONFIG_CLK_IMX6UL=y CONFIG_CMA=y CONFIG_CMA_AREAS=7 # CONFIG_CMA_DEBUG is not set @@ -7,7 +8,7 @@ CONFIG_CMA_AREAS=7 CONFIG_CONTIG_ALLOC=y # CONFIG_DMA_CMA is not set CONFIG_GENERIC_IRQ_EFFECTIVE_AFF_MASK=y -CONFIG_IRQ_DOMAIN_HIERARCHY=y +CONFIG_HW_RANDOM_IMX_RNGC=y CONFIG_JFFS2_FS=y CONFIG_LEDS_GPIO=y CONFIG_MEMORY_ISOLATION=y @@ -22,3 +23,5 @@ CONFIG_SOC_IMX6=y CONFIG_SOC_IMX6UL=y CONFIG_SPI_FSL_QUADSPI=y CONFIG_SPI_MEM=y +CONFIG_USB_CHIPIDEA_IMX=y +CONFIG_USB_EHCI_MXC=y diff --git a/target/linux/imx/cortexa9/config-default b/target/linux/imx/cortexa9/config-default index 5210dc0cb7..3136def5bf 100644 --- a/target/linux/imx/cortexa9/config-default +++ b/target/linux/imx/cortexa9/config-default @@ -4,6 +4,9 @@ CONFIG_ARM_GIC=y CONFIG_ARM_IMX6Q_CPUFREQ=y CONFIG_ATA_SFF=y CONFIG_BLK_MQ_PCI=y +CONFIG_CLK_IMX6Q=y +CONFIG_CLK_IMX6SL=y +CONFIG_CLK_IMX6SX=y CONFIG_CMDLINE="pci=nomsi" CONFIG_CMDLINE_EXTEND=y CONFIG_E1000E=y @@ -15,14 +18,15 @@ CONFIG_GENERIC_MSI_IRQ_DOMAIN=y CONFIG_GPIOLIB_IRQCHIP=y CONFIG_GPIO_PCA953X=y CONFIG_GPIO_PCA953X_IRQ=y +CONFIG_HW_RANDOM_IMX_RNGC=y # CONFIG_INITRAMFS_FORCE is not set -CONFIG_IRQ_DOMAIN_HIERARCHY=y CONFIG_MARVELL_PHY=y CONFIG_MICREL_PHY=y CONFIG_MMC_SDHCI_ESDHC_IMX=y CONFIG_MMC_SDHCI_IO_ACCESSORS=y CONFIG_MMC_SDHCI_OF_ESDHC=y # CONFIG_MMC_SDHCI_PCI is not set +# CONFIG_NET_DSA_MSCC_FELIX is not set CONFIG_NET_DSA_MV88E6XXX=y CONFIG_NET_DSA_MV88E6XXX_GLOBAL2=y CONFIG_PCI=y @@ -48,6 +52,7 @@ CONFIG_REGULATOR_LTC3676=y CONFIG_REGULATOR_PFUZE100=y CONFIG_RTC_DRV_DS1307=y CONFIG_RTC_DRV_DS1672=y +CONFIG_SATA_HOST=y CONFIG_SENSORS_AD7418=y CONFIG_SOC_IMX6=y CONFIG_SOC_IMX6Q=y -- 2.33.1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH 08/14] imx: split into arch-specific subtargets
Modern NXP i.MX series includes several different families, based on
single- or multi-core Arm Cortex-A CPUs. To be able to support more
families within a single target, we split the 'imx' in arch-specific
subtargets, starting with 'cortexa9' for the Cortex-A9 based i.MX 6,
already supported by the original 'imx6' target.
Signed-off-by: Piotr Dymacz
---
target/linux/imx/Makefile | 3 +-
target/linux/imx/config-5.10 | 65 +-
target/linux/imx/config-5.4 | 60 +
.../base-files/etc/board.d/02_network | 0
.../imx/{ => cortexa9}/base-files/lib/imx.sh | 0
.../base-files/lib/preinit/79_move_config | 0
.../base-files/lib/upgrade/platform.sh| 0
target/linux/imx/cortexa9/config-default | 55 +
target/linux/imx/cortexa9/target.mk | 7 +
target/linux/imx/image/Makefile | 219 +-
target/linux/imx/image/cortexa9.mk| 210 +
11 files changed, 286 insertions(+), 333 deletions(-)
rename target/linux/imx/{ => cortexa9}/base-files/etc/board.d/02_network (100%)
rename target/linux/imx/{ => cortexa9}/base-files/lib/imx.sh (100%)
rename target/linux/imx/{ => cortexa9}/base-files/lib/preinit/79_move_config
(100%)
rename target/linux/imx/{ => cortexa9}/base-files/lib/upgrade/platform.sh
(100%)
create mode 100644 target/linux/imx/cortexa9/config-default
create mode 100644 target/linux/imx/cortexa9/target.mk
create mode 100644 target/linux/imx/image/cortexa9.mk
diff --git a/target/linux/imx/Makefile b/target/linux/imx/Makefile
index 6f00cba992..66ffa9bd31 100644
--- a/target/linux/imx/Makefile
+++ b/target/linux/imx/Makefile
@@ -8,8 +8,7 @@ ARCH:=arm
BOARD:=imx
BOARDNAME:=NXP i.MX
FEATURES:=audio display fpu gpio pcie rtc usb usbgadget squashfs targz nand
ubifs boot-part rootfs-part
-CPU_TYPE:=cortex-a9
-CPU_SUBTYPE:=neon
+SUBTARGETS:=cortexa9
KERNEL_PATCHVER:=5.4
KERNEL_TESTING_PATCHVER:=5.10
diff --git a/target/linux/imx/config-5.10 b/target/linux/imx/config-5.10
index 624013aa81..a500b07a8f 100644
--- a/target/linux/imx/config-5.10
+++ b/target/linux/imx/config-5.10
@@ -1,4 +1,3 @@
-CONFIG_AHCI_IMX=y
CONFIG_ALIGNMENT_TRAP=y
CONFIG_ARCH_32BIT_OFF_T=y
CONFIG_ARCH_HIBERNATION_POSSIBLE=y
@@ -18,16 +17,13 @@ CONFIG_ARCH_SUSPEND_POSSIBLE=y
CONFIG_ARM=y
CONFIG_ARM_ARCH_TIMER=y
CONFIG_ARM_ARCH_TIMER_EVTSTREAM=y
-CONFIG_ARM_CPU_SUSPEND=y
CONFIG_ARM_CRYPTO=y
CONFIG_ARM_ERRATA_754322=y
CONFIG_ARM_ERRATA_764369=y
CONFIG_ARM_ERRATA_775420=y
CONFIG_ARM_ERRATA_814220=y
-CONFIG_ARM_GIC=y
CONFIG_ARM_HAS_SG_CHAIN=y
CONFIG_ARM_HEAVY_MB=y
-CONFIG_ARM_IMX6Q_CPUFREQ=y
# CONFIG_ARM_IMX_CPUFREQ_DT is not set
CONFIG_ARM_L1_CACHE_SHIFT=6
CONFIG_ARM_L1_CACHE_SHIFT_6=y
@@ -40,27 +36,22 @@ CONFIG_ASN1=y
CONFIG_ASSOCIATIVE_ARRAY=y
CONFIG_ATA=y
CONFIG_ATAGS=y
+# CONFIG_ATA_SFF is not set
CONFIG_AUTO_ZRELADDR=y
CONFIG_BINFMT_FLAT_ARGVP_ENVP_ON_STACK=y
CONFIG_BLK_DEV_LOOP=y
-CONFIG_BLK_MQ_PCI=y
CONFIG_BLK_PM=y
CONFIG_BLK_SCSI_REQUEST=y
CONFIG_CACHE_L2X0=y
CONFIG_CLKDEV_LOOKUP=y
CONFIG_CLKSRC_IMX_GPT=y
CONFIG_CLKSRC_MMIO=y
-CONFIG_CLK_IMX6Q=y
-CONFIG_CLK_IMX6SL=y
-CONFIG_CLK_IMX6SX=y
# CONFIG_CLK_IMX8MM is not set
# CONFIG_CLK_IMX8MN is not set
# CONFIG_CLK_IMX8MP is not set
# CONFIG_CLK_IMX8MQ is not set
CONFIG_CLONE_BACKWARDS=y
CONFIG_CLZ_TAB=y
-CONFIG_CMDLINE="pci=nomsi"
-CONFIG_CMDLINE_EXTEND=y
CONFIG_COMMON_CLK=y
CONFIG_COMPAT_32BIT_TIME=y
CONFIG_CPUFREQ_DT=y
@@ -162,7 +153,6 @@ CONFIG_DMA_OPS=y
CONFIG_DMA_REMAP=y
CONFIG_DMA_VIRTUAL_CHANNELS=y
CONFIG_DTC=y
-CONFIG_E1000E=y
CONFIG_EDAC_ATOMIC_SCRUB=y
CONFIG_EDAC_SUPPORT=y
CONFIG_ENCRYPTED_KEYS=y
@@ -173,10 +163,9 @@ CONFIG_EXTCON=y
CONFIG_EXTRA_FIRMWARE="imx/sdma/sdma-imx6q.bin"
CONFIG_EXTRA_FIRMWARE_DIR="firmware"
CONFIG_F2FS_FS=y
-CONFIG_FEC=y
+# CONFIG_FEC is not set
CONFIG_FIXED_PHY=y
CONFIG_FIX_EARLYCON_MEM=y
-CONFIG_FSL_GUTS=y
CONFIG_FS_ENCRYPTION=y
CONFIG_FS_ENCRYPTION_ALGS=y
CONFIG_FS_IOMAP=y
@@ -193,12 +182,9 @@ CONFIG_GENERIC_EARLY_IOREMAP=y
CONFIG_GENERIC_GETTIMEOFDAY=y
CONFIG_GENERIC_IDLE_POLL_SETUP=y
CONFIG_GENERIC_IRQ_CHIP=y
-CONFIG_GENERIC_IRQ_EFFECTIVE_AFF_MASK=y
CONFIG_GENERIC_IRQ_MULTI_HANDLER=y
CONFIG_GENERIC_IRQ_SHOW=y
CONFIG_GENERIC_IRQ_SHOW_LEVEL=y
-CONFIG_GENERIC_MSI_IRQ=y
-CONFIG_GENERIC_MSI_IRQ_DOMAIN=y
CONFIG_GENERIC_PCI_IOMAP=y
CONFIG_GENERIC_PINCONF=y
CONFIG_GENERIC_PINCTRL_GROUPS=y
@@ -212,11 +198,8 @@ CONFIG_GENERIC_VDSO_32=y
# CONFIG_GIANFAR is not set
CONFIG_GLOB=y
CONFIG_GPIOLIB=y
-CONFIG_GPIOLIB_IRQCHIP=y
CONFIG_GPIO_GENERIC=y
CONFIG_GPIO_MXC=y
-CONFIG_GPIO_PCA953X=y
-CONFIG_GPIO_PCA953X_IRQ=y
CONFIG_GRO_CELLS=y
CONFIG_HANDLE_DOMAIN_IRQ=y
CONFIG_HARDEN_BRANCH_PREDICTOR=y
@@ -227,7 +210,6 @@ CONFIG_HAS_IOPORT_MAP=y
CONFIG_HAVE_SMP=y
CONFIG_HWMON=y
CONFIG_HW_RANDOM=y
-CONFIG_HW_RANDOM_IMX_RNGC=y
CONFIG_HZ_FIXED=0
CONFIG_HZ_PERIODIC=y
[PATCH 12/14] imx: make kernel 5.10 default version
Signed-off-by: Piotr Dymacz --- target/linux/imx/Makefile | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/target/linux/imx/Makefile b/target/linux/imx/Makefile index 17f634a7bf..b293655a9a 100644 --- a/target/linux/imx/Makefile +++ b/target/linux/imx/Makefile @@ -10,8 +10,7 @@ BOARDNAME:=NXP i.MX FEATURES:=audio display fpu gpio pcie rtc usb usbgadget squashfs targz nand ubifs boot-part rootfs-part SUBTARGETS:=cortexa7 cortexa9 -KERNEL_PATCHVER:=5.4 -KERNEL_TESTING_PATCHVER:=5.10 +KERNEL_PATCHVER:=5.10 include $(INCLUDE_DIR)/target.mk -- 2.33.1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH 11/14] imx: introduce 'cortexa7' subtarget
This adds some essential files required by new 'cortexa7' subtarget,
dedicated for Cortex-A7 based NXP i.MX series. For now, the kernel
config-default focuses only on the i.MX 6UL family, as the following
changeset will introduce support for i.MX 6ULL based device. Support
for more platforms (e.g. i.MX 7) might be enabled later, while adding
more devices.
Signed-off-by: Piotr Dymacz
---
target/linux/imx/Makefile | 2 +-
.../base-files/etc/board.d/02_network | 15
.../base-files/lib/upgrade/platform.sh| 16 +
target/linux/imx/cortexa7/config-default | 24 +++
target/linux/imx/cortexa7/target.mk | 7 ++
target/linux/imx/image/cortexa7.mk| 10
6 files changed, 73 insertions(+), 1 deletion(-)
create mode 100644 target/linux/imx/cortexa7/base-files/etc/board.d/02_network
create mode 100644 target/linux/imx/cortexa7/base-files/lib/upgrade/platform.sh
create mode 100644 target/linux/imx/cortexa7/config-default
create mode 100644 target/linux/imx/cortexa7/target.mk
create mode 100644 target/linux/imx/image/cortexa7.mk
diff --git a/target/linux/imx/Makefile b/target/linux/imx/Makefile
index 66ffa9bd31..17f634a7bf 100644
--- a/target/linux/imx/Makefile
+++ b/target/linux/imx/Makefile
@@ -8,7 +8,7 @@ ARCH:=arm
BOARD:=imx
BOARDNAME:=NXP i.MX
FEATURES:=audio display fpu gpio pcie rtc usb usbgadget squashfs targz nand
ubifs boot-part rootfs-part
-SUBTARGETS:=cortexa9
+SUBTARGETS:=cortexa7 cortexa9
KERNEL_PATCHVER:=5.4
KERNEL_TESTING_PATCHVER:=5.10
diff --git a/target/linux/imx/cortexa7/base-files/etc/board.d/02_network
b/target/linux/imx/cortexa7/base-files/etc/board.d/02_network
new file mode 100644
index 00..75d1c7d1d8
--- /dev/null
+++ b/target/linux/imx/cortexa7/base-files/etc/board.d/02_network
@@ -0,0 +1,15 @@
+. /lib/functions/uci-defaults.sh
+
+board=$(board_name)
+
+board_config_update
+
+case "$board" in
+*)
+ ucidef_set_interfaces_lan_wan "eth0" "eth1"
+ ;;
+esac
+
+board_config_flush
+
+exit 0
diff --git a/target/linux/imx/cortexa7/base-files/lib/upgrade/platform.sh
b/target/linux/imx/cortexa7/base-files/lib/upgrade/platform.sh
new file mode 100644
index 00..9a613c43b1
--- /dev/null
+++ b/target/linux/imx/cortexa7/base-files/lib/upgrade/platform.sh
@@ -0,0 +1,16 @@
+PART_NAME=firmware
+REQUIRE_IMAGE_METADATA=1
+
+platform_check_image() {
+ return 0
+}
+
+platform_do_upgrade() {
+ local board=$(board_name)
+
+ case "$board" in
+ *)
+ default_do_upgrade "$1"
+ ;;
+ esac
+}
diff --git a/target/linux/imx/cortexa7/config-default
b/target/linux/imx/cortexa7/config-default
new file mode 100644
index 00..eb1986769e
--- /dev/null
+++ b/target/linux/imx/cortexa7/config-default
@@ -0,0 +1,24 @@
+CONFIG_ARM_CPU_SUSPEND=y
+CONFIG_ARM_GIC=y
+CONFIG_CMA=y
+CONFIG_CMA_AREAS=7
+# CONFIG_CMA_DEBUG is not set
+# CONFIG_CMA_DEBUGFS is not set
+CONFIG_CONTIG_ALLOC=y
+# CONFIG_DMA_CMA is not set
+CONFIG_GENERIC_IRQ_EFFECTIVE_AFF_MASK=y
+CONFIG_IRQ_DOMAIN_HIERARCHY=y
+CONFIG_JFFS2_FS=y
+CONFIG_LEDS_GPIO=y
+CONFIG_MEMORY_ISOLATION=y
+CONFIG_MTD_SPI_NOR=y
+CONFIG_MTD_SPLIT_FIRMWARE=y
+CONFIG_MTD_SPLIT_FIT_FW=y
+CONFIG_PINCTRL_IMX=y
+CONFIG_PINCTRL_IMX6UL=y
+CONFIG_PM_GENERIC_DOMAINS=y
+CONFIG_PM_GENERIC_DOMAINS_OF=y
+CONFIG_SOC_IMX6=y
+CONFIG_SOC_IMX6UL=y
+CONFIG_SPI_FSL_QUADSPI=y
+CONFIG_SPI_MEM=y
diff --git a/target/linux/imx/cortexa7/target.mk
b/target/linux/imx/cortexa7/target.mk
new file mode 100644
index 00..11de87507d
--- /dev/null
+++ b/target/linux/imx/cortexa7/target.mk
@@ -0,0 +1,7 @@
+BOARDNAME:=NXP i.MX with Cortex-A7
+CPU_TYPE:=cortex-a7
+CPU_SUBTYPE:=neon-vfpv4
+
+define Target/Description
+ Build firmware images for NXP i.MX (Cortex-A7) based boards.
+endef
diff --git a/target/linux/imx/image/cortexa7.mk
b/target/linux/imx/image/cortexa7.mk
new file mode 100644
index 00..063b89fdd6
--- /dev/null
+++ b/target/linux/imx/image/cortexa7.mk
@@ -0,0 +1,10 @@
+define Device/Default
+ PROFILES := Default
+ FILESYSTEMS := squashfs ext4
+ KERNEL_INSTALL := 1
+ KERNEL_SUFFIX := -uImage
+ KERNEL_NAME := zImage
+ KERNEL := kernel-bin | uImage none
+ KERNEL_LOADADDR := 0x80008000
+ IMAGES :=
+endef
--
2.33.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH 10/14] uboot-imx: set BUILD_SUBTARGET to 'cortexa9'
All currently supported devices belong to the imx/cortexa9 subtarget. Signed-off-by: Piotr Dymacz --- package/boot/uboot-imx/Makefile | 3 +++ 1 file changed, 3 insertions(+) diff --git a/package/boot/uboot-imx/Makefile b/package/boot/uboot-imx/Makefile index 9ca4d55a1c..2faa48bd73 100644 --- a/package/boot/uboot-imx/Makefile +++ b/package/boot/uboot-imx/Makefile @@ -24,6 +24,7 @@ define U-Boot/apalis_imx6 NAME:=Toradex Apalis UBOOT_IMAGE:=SPL u-boot.img u-boot-with-spl.imx UBOOT_MAKE_FLAGS:=SPL u-boot.img u-boot-with-spl.imx + BUILD_SUBTARGET:=cortexa9 BUILD_DEVICES:=toradex_apalis endef @@ -31,11 +32,13 @@ define U-Boot/mx6cuboxi NAME:=SolidRun Cubox-i boards UBOOT_IMAGE:=SPL u-boot.img UBOOT_MAKE_FLAGS:=SPL u-boot.img + BUILD_SUBTARGET:=cortexa9 BUILD_DEVICES:=solidrun_cubox-i endef define U-Boot/wandboard NAME:=Wandboard Dual Lite/Quad/Solo + BUILD_SUBTARGET:=cortexa9 BUILD_DEVICES:=wandboard_dual endef -- 2.33.1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH 09/14] uboot-envtools: move imx to imx_cortexa9
Subtarget-specific files under 'uboot-envtools' package are supported
since 6f3a05ebb0 ("uboot-envtools: support uci-default config also per
subtargets").
Signed-off-by: Piotr Dymacz
---
package/boot/uboot-envtools/files/{imx => imx_cortexa9} | 0
1 file changed, 0 insertions(+), 0 deletions(-)
rename package/boot/uboot-envtools/files/{imx => imx_cortexa9} (100%)
diff --git a/package/boot/uboot-envtools/files/imx
b/package/boot/uboot-envtools/files/imx_cortexa9
similarity index 100%
rename from package/boot/uboot-envtools/files/imx
rename to package/boot/uboot-envtools/files/imx_cortexa9
--
2.33.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH 07/14] uboot-imx6: rename to 'uboot-imx'
Signed-off-by: Piotr Dymacz
---
package/boot/{uboot-imx6 => uboot-imx}/Makefile | 2 +-
...0001-apalis_imx6_defconfig-enable-some-useful-commands.patch | 0
.../patches/110-mx6cuboxi-mmc-fallback.patch| 0
.../patches/111-mx6cuboxi_defconfig-force-mmc-boot.patch| 0
4 files changed, 1 insertion(+), 1 deletion(-)
rename package/boot/{uboot-imx6 => uboot-imx}/Makefile (98%)
rename package/boot/{uboot-imx6 =>
uboot-imx}/patches/0001-apalis_imx6_defconfig-enable-some-useful-commands.patch
(100%)
rename package/boot/{uboot-imx6 =>
uboot-imx}/patches/110-mx6cuboxi-mmc-fallback.patch (100%)
rename package/boot/{uboot-imx6 =>
uboot-imx}/patches/111-mx6cuboxi_defconfig-force-mmc-boot.patch (100%)
diff --git a/package/boot/uboot-imx6/Makefile b/package/boot/uboot-imx/Makefile
similarity index 98%
rename from package/boot/uboot-imx6/Makefile
rename to package/boot/uboot-imx/Makefile
index 6c2297dd81..9ca4d55a1c 100644
--- a/package/boot/uboot-imx6/Makefile
+++ b/package/boot/uboot-imx/Makefile
@@ -16,7 +16,7 @@ include $(INCLUDE_DIR)/u-boot.mk
include $(INCLUDE_DIR)/package.mk
define U-Boot/Default
- BUILD_TARGET:=imx6
+ BUILD_TARGET:=imx
UBOOT_IMAGE:=u-boot.imx
endef
diff --git
a/package/boot/uboot-imx6/patches/0001-apalis_imx6_defconfig-enable-some-useful-commands.patch
b/package/boot/uboot-imx/patches/0001-apalis_imx6_defconfig-enable-some-useful-commands.patch
similarity index 100%
rename from
package/boot/uboot-imx6/patches/0001-apalis_imx6_defconfig-enable-some-useful-commands.patch
rename to
package/boot/uboot-imx/patches/0001-apalis_imx6_defconfig-enable-some-useful-commands.patch
diff --git a/package/boot/uboot-imx6/patches/110-mx6cuboxi-mmc-fallback.patch
b/package/boot/uboot-imx/patches/110-mx6cuboxi-mmc-fallback.patch
similarity index 100%
rename from package/boot/uboot-imx6/patches/110-mx6cuboxi-mmc-fallback.patch
rename to package/boot/uboot-imx/patches/110-mx6cuboxi-mmc-fallback.patch
diff --git
a/package/boot/uboot-imx6/patches/111-mx6cuboxi_defconfig-force-mmc-boot.patch
b/package/boot/uboot-imx/patches/111-mx6cuboxi_defconfig-force-mmc-boot.patch
similarity index 100%
rename from
package/boot/uboot-imx6/patches/111-mx6cuboxi_defconfig-force-mmc-boot.patch
rename to
package/boot/uboot-imx/patches/111-mx6cuboxi_defconfig-force-mmc-boot.patch
--
2.33.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH 06/14] uboot-envtools: rename 'imx6' to 'imx'
Signed-off-by: Piotr Dymacz
---
package/boot/uboot-envtools/files/{imx6 => imx} | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
rename package/boot/uboot-envtools/files/{imx6 => imx} (98%)
diff --git a/package/boot/uboot-envtools/files/imx6
b/package/boot/uboot-envtools/files/imx
similarity index 98%
rename from package/boot/uboot-envtools/files/imx6
rename to package/boot/uboot-envtools/files/imx
index dac3c3792e..c6d6d94d16 100644
--- a/package/boot/uboot-envtools/files/imx6
+++ b/package/boot/uboot-envtools/files/imx
@@ -6,7 +6,7 @@
touch /etc/config/ubootenv
-. /lib/imx6.sh
+. /lib/imx.sh
. /lib/uboot-envtools.sh
. /lib/functions.sh
--
2.33.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH 03/14] imx6: rename target to 'imx'
This is first step in migrating to a generic i.MX target which in the
next steps will also get divided into arch-specific subtargets.
In the result, this will make it possible to support, within a single
target, also other modern NXP i.MX families, like the i.MX 7, i.MX 8
or recently introduced i.MX 9.
Signed-off-by: Piotr Dymacz
---
target/linux/{imx6 => imx}/Makefile | 4 ++--
.../{imx6 => imx}/base-files/etc/board.d/02_network | 0
target/linux/{imx6 => imx}/base-files/etc/inittab | 0
.../lib/imx6.sh => imx/base-files/lib/imx.sh} | 0
.../base-files/lib/preinit/79_move_config | 2 +-
.../base-files/lib/upgrade/platform.sh | 2 +-
target/linux/{imx6 => imx}/config-5.10 | 0
target/linux/{imx6 => imx}/config-5.4 | 0
.../files/firmware/imx/sdma/sdma-imx6q.bin | Bin
target/linux/{imx6 => imx}/image/Makefile | 0
.../{imx6 => imx}/image/bootscript-solidrun_cubox-i | 0
.../{imx6 => imx}/image/bootscript-toradex_apalis | 0
target/linux/{imx6 => imx}/image/bootscript-ventana | 0
.../{imx6 => imx}/image/recovery-toradex_apalis | 0
.../{imx6 => imx}/patches-5.10/100-bootargs.patch | 0
...imx6q-apalis-ixora-add-status-LEDs-aliases.patch | 0
...x6q-apalis-ixora-make-switch3-reset-button.patch | 0
.../001-ARM-dts-imx-Add-GW5907-board-support.patch | 0
.../002-ARM-dts-imx-Add-GW5910-board-support.patch | 0
.../003-ARM-dts-imx-Add-GW5913-board-support.patch | 0
.../004-ARM-dts-imx-Add-GW5912-board-support.patch | 0
...x6qdl-gw553x-add-lsm9ds1-iio-imu-magn-supp.patch | 0
...x-ventana-add-fxos8700-on-gateworks-boards.patch | 0
...5.7-ARM-dts-imx6qdl-gw5910-add-CC1352-UART.patch | 0
...ARM-dts-imx6qdl-gw552x-add-USB-OTG-support.patch | 0
...x6qdl-gw560x-add-lsm9ds1-iio-imu-magn-supp.patch | 0
...x6qdl-gw5904-add-lsm9ds1-iio-imu-magn-supp.patch | 0
...-imx6qdl-gw5910-add-support-for-bcm4330-bt.patch | 0
...-ARM-dts-imx6qdl-gw5910-fix-wlan-regulator.patch | 0
.../{imx6 => imx}/patches-5.4/100-bootargs.patch| 0
.../patches-5.4/301-apalis-ixora-dts-leds.patch | 0
.../302-apalis-ixora-dts-reset-button.patch | 0
target/linux/{imx6 => imx}/profiles/100-default.mk | 2 +-
33 files changed, 5 insertions(+), 5 deletions(-)
rename target/linux/{imx6 => imx}/Makefile (93%)
rename target/linux/{imx6 => imx}/base-files/etc/board.d/02_network (100%)
rename target/linux/{imx6 => imx}/base-files/etc/inittab (100%)
rename target/linux/{imx6/base-files/lib/imx6.sh => imx/base-files/lib/imx.sh}
(100%)
rename target/linux/{imx6 => imx}/base-files/lib/preinit/79_move_config (96%)
rename target/linux/{imx6 => imx}/base-files/lib/upgrade/platform.sh (99%)
rename target/linux/{imx6 => imx}/config-5.10 (100%)
rename target/linux/{imx6 => imx}/config-5.4 (100%)
rename target/linux/{imx6 => imx}/files/firmware/imx/sdma/sdma-imx6q.bin (100%)
rename target/linux/{imx6 => imx}/image/Makefile (100%)
rename target/linux/{imx6 => imx}/image/bootscript-solidrun_cubox-i (100%)
rename target/linux/{imx6 => imx}/image/bootscript-toradex_apalis (100%)
rename target/linux/{imx6 => imx}/image/bootscript-ventana (100%)
rename target/linux/{imx6 => imx}/image/recovery-toradex_apalis (100%)
rename target/linux/{imx6 => imx}/patches-5.10/100-bootargs.patch (100%)
rename target/linux/{imx6 =>
imx}/patches-5.10/300-ARM-dts-imx6q-apalis-ixora-add-status-LEDs-aliases.patch
(100%)
rename target/linux/{imx6 =>
imx}/patches-5.10/301-ARM-dts-imx6q-apalis-ixora-make-switch3-reset-button.patch
(100%)
rename target/linux/{imx6 =>
imx}/patches-5.4/001-ARM-dts-imx-Add-GW5907-board-support.patch (100%)
rename target/linux/{imx6 =>
imx}/patches-5.4/002-ARM-dts-imx-Add-GW5910-board-support.patch (100%)
rename target/linux/{imx6 =>
imx}/patches-5.4/003-ARM-dts-imx-Add-GW5913-board-support.patch (100%)
rename target/linux/{imx6 =>
imx}/patches-5.4/004-ARM-dts-imx-Add-GW5912-board-support.patch (100%)
rename target/linux/{imx6 =>
imx}/patches-5.4/005-v5.7-ARM-dts-imx6qdl-gw553x-add-lsm9ds1-iio-imu-magn-supp.patch
(100%)
rename target/linux/{imx6 =>
imx}/patches-5.4/006-v5.7-ARM-dts-imx-ventana-add-fxos8700-on-gateworks-boards.patch
(100%)
rename target/linux/{imx6 =>
imx}/patches-5.4/006-v5.7-ARM-dts-imx6qdl-gw5910-add-CC1352-UART.patch (100%)
rename target/linux/{imx6 =>
imx}/patches-5.4/006-v5.8-ARM-dts-imx6qdl-gw552x-add-USB-OTG-support.patch
(100%)
rename target/linux/{imx6 =>
imx}/patches-5.4/007-v5.8-ARM-dts-imx6qdl-gw560x-add-lsm9ds1-iio-imu-magn-supp.patch
(100%)
rename target/linux/{imx6 =>
imx}/patches-5.4/008-v5.8-ARM-dts-imx6qdl-gw5904-add-lsm9ds1-iio-imu-magn-supp.patch
(100%)
rename target/linux/{imx6 =>
imx}/patches-5.4/009-v5.8-ARM-dts-imx6qdl-gw5910-add-support-for-bcm4330-bt.patch
[PATCH 05/14] kobs-ng: update dependencies after 'imx6' -> 'imx' rename
Signed-off-by: Piotr Dymacz --- package/boot/kobs-ng/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/package/boot/kobs-ng/Makefile b/package/boot/kobs-ng/Makefile index 3fa8302b8c..68e6ff170c 100644 --- a/package/boot/kobs-ng/Makefile +++ b/package/boot/kobs-ng/Makefile @@ -25,7 +25,7 @@ define Package/kobs-ng SECTION:=utils CATEGORY:=Utilities TITLE:=Application for writing bootstreams to NAND flash - DEPENDS:=@TARGET_imx6 + DEPENDS:=@TARGET_imx endef define Package/kobs-ng/description -- 2.33.1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH 04/14] kernel: update dependencies after 'imx6' -> 'imx' rename
Signed-off-by: Piotr Dymacz --- package/kernel/hwmon-gsc/Makefile | 2 +- package/kernel/linux/modules/can.mk| 2 +- package/kernel/linux/modules/crypto.mk | 6 +++--- package/kernel/linux/modules/input.mk | 2 +- package/kernel/linux/modules/sound.mk | 8 package/kernel/linux/modules/video.mk | 2 +- package/kernel/linux/modules/w1.mk | 2 +- 7 files changed, 12 insertions(+), 12 deletions(-) diff --git a/package/kernel/hwmon-gsc/Makefile b/package/kernel/hwmon-gsc/Makefile index 8cf4e0ee79..34c33dc581 100644 --- a/package/kernel/hwmon-gsc/Makefile +++ b/package/kernel/hwmon-gsc/Makefile @@ -8,7 +8,7 @@ include $(INCLUDE_DIR)/package.mk define KernelPackage/hwmon-gsc SUBMENU:=Hardware Monitoring Support - DEPENDS:=@TARGET_imx6 +kmod-hwmon-core +kmod-i2c-core + DEPENDS:=@TARGET_imx +kmod-hwmon-core +kmod-i2c-core TITLE:=Driver for the Gateworks System Controller AUTOLOAD:=$(call AutoLoad,60,gsc) FILES:=$(PKG_BUILD_DIR)/gsc.ko diff --git a/package/kernel/linux/modules/can.mk b/package/kernel/linux/modules/can.mk index 3060fc0966..9cdebb9091 100644 --- a/package/kernel/linux/modules/can.mk +++ b/package/kernel/linux/modules/can.mk @@ -121,7 +121,7 @@ define KernelPackage/can-flexcan KCONFIG:=CONFIG_CAN_FLEXCAN FILES:=$(LINUX_DIR)/drivers/net/can/flexcan.ko AUTOLOAD:=$(call AutoProbe,flexcan) - $(call AddDepends/can,@TARGET_imx6) + $(call AddDepends/can,@TARGET_imx) endef define KernelPackage/can-flexcan/description diff --git a/package/kernel/linux/modules/crypto.mk b/package/kernel/linux/modules/crypto.mk index 6cecb1a0fa..4097957277 100644 --- a/package/kernel/linux/modules/crypto.mk +++ b/package/kernel/linux/modules/crypto.mk @@ -287,7 +287,7 @@ define KernelPackage/crypto-ghash/arm-ce AUTOLOAD+=$(call AutoLoad,09,ghash-arm-ce) endef -KernelPackage/crypto-ghash/imx6=$(KernelPackage/crypto-ghash/arm-ce) +KernelPackage/crypto-ghash/imx=$(KernelPackage/crypto-ghash/arm-ce) KernelPackage/crypto-ghash/ipq40xx=$(KernelPackage/crypto-ghash/arm-ce) KernelPackage/crypto-ghash/mvebu/cortexa9=$(KernelPackage/crypto-ghash/arm-ce) @@ -857,7 +857,7 @@ define KernelPackage/crypto-sha1/arm-neon AUTOLOAD+=$(call AutoLoad,09,sha1-arm-neon) endef -KernelPackage/crypto-sha1/imx6=$(KernelPackage/crypto-sha1/arm-neon) +KernelPackage/crypto-sha1/imx=$(KernelPackage/crypto-sha1/arm-neon) KernelPackage/crypto-sha1/ipq40xx=$(KernelPackage/crypto-sha1/arm-neon) KernelPackage/crypto-sha1/mvebu/cortexa9=$(KernelPackage/crypto-sha1/arm-neon) @@ -921,7 +921,7 @@ define KernelPackage/crypto-sha512/arm AUTOLOAD+=$(call AutoLoad,09,sha512-arm) endef -KernelPackage/crypto-sha512/imx6=$(KernelPackage/crypto-sha512/arm) +KernelPackage/crypto-sha512/imx=$(KernelPackage/crypto-sha512/arm) KernelPackage/crypto-sha512/ipq40xx=$(KernelPackage/crypto-sha512/arm) KernelPackage/crypto-sha512/mvebu/cortexa9=$(KernelPackage/crypto-sha512/arm) diff --git a/package/kernel/linux/modules/input.mk b/package/kernel/linux/modules/input.mk index c2f39ddd90..e870bf7f8b 100644 --- a/package/kernel/linux/modules/input.mk +++ b/package/kernel/linux/modules/input.mk @@ -196,7 +196,7 @@ $(eval $(call KernelPackage,input-touchscreen-ads7846)) define KernelPackage/keyboard-imx SUBMENU:=$(INPUT_MODULES_MENU) TITLE:=IMX keypad support - DEPENDS:=@(TARGET_mxs||TARGET_imx6) +kmod-input-matrixkmap + DEPENDS:=@(TARGET_mxs||TARGET_imx) +kmod-input-matrixkmap KCONFIG:= \ CONFIG_KEYBOARD_IMX \ CONFIG_INPUT_KEYBOARD=y diff --git a/package/kernel/linux/modules/sound.mk b/package/kernel/linux/modules/sound.mk index e43be25bc6..e1d7f72a0f 100644 --- a/package/kernel/linux/modules/sound.mk +++ b/package/kernel/linux/modules/sound.mk @@ -225,12 +225,12 @@ define KernelPackage/sound-soc-imx $(LINUX_DIR)/sound/soc/fsl/snd-soc-fsl-ssi.ko \ $(LINUX_DIR)/sound/soc/fsl/imx-pcm-dma.ko AUTOLOAD:=$(call AutoLoad,56,snd-soc-imx-audmux snd-soc-fsl-ssi snd-soc-imx-pcm) - DEPENDS:=@TARGET_imx6 +kmod-sound-soc-core + DEPENDS:=@TARGET_imx +kmod-sound-soc-core $(call AddDepends/sound) endef define KernelPackage/sound-soc-imx/description - Support for i.MX6 Platform sound (ssi/audmux/pcm) + Support for i.MX Platform sound (ssi/audmux/pcm) endef $(eval $(call KernelPackage,sound-soc-imx)) @@ -243,12 +243,12 @@ define KernelPackage/sound-soc-imx-sgtl5000 $(LINUX_DIR)/sound/soc/codecs/snd-soc-sgtl5000.ko \ $(LINUX_DIR)/sound/soc/fsl/snd-soc-imx-sgtl5000.ko AUTOLOAD:=$(call AutoLoad,57,snd-soc-sgtl5000 snd-soc-imx-sgtl5000) - DEPENDS:=@TARGET_imx6 +kmod-sound-soc-imx + DEPENDS:=@TARGET_imx +kmod-sound-soc-imx $(call AddDepends/sound) endef define KernelPackage/sound-soc-imx-sgtl5000/description - Support for i.MX6 Platform sound SGTL5000 codec + Support for i.MX Platform sound SGTL5000 codec endef $(eval $(call KernelPackage,sound-soc-imx-sgtl5000)) diff --git a/package/kernel/linux/modules/video.mk b/package
[PATCH 01/14] imx6: image: fix Gateworks Ventana boot script filename
U-Boot for the Gateworks Ventana includes filename of the boot script in
the default/embedded environment (see 'include/configs/gw_ventana.h' in
the U-Boot sources).
This restores the old boot script filename ('6x_bootscript-ventana'),
making Ventana boards boot again.
Fixes: 8dba71dd33 ("imx6: image: drop BOOT_SCRIPT and fix DEVICE_NAME")
Reported-by: Koen Vandeputte
Signed-off-by: Piotr Dymacz
---
target/linux/imx6/image/Makefile| 2 +-
.../image/{bootscript-gateworks_ventana => bootscript-ventana} | 0
2 files changed, 1 insertion(+), 1 deletion(-)
rename target/linux/imx6/image/{bootscript-gateworks_ventana =>
bootscript-ventana} (100%)
diff --git a/target/linux/imx6/image/Makefile b/target/linux/imx6/image/Makefile
index 948694381e..5f8e5f1c04 100644
--- a/target/linux/imx6/image/Makefile
+++ b/target/linux/imx6/image/Makefile
@@ -124,7 +124,7 @@ define Device/gateworks_ventana
DEVICE_VENDOR := Gateworks
DEVICE_MODEL := Ventana family
DEVICE_VARIANT := normal NAND flash
- DEVICE_NAME := gateworks_ventana
+ DEVICE_NAME := ventana
DEVICE_DTS:= \
imx6dl-gw51xx \
imx6dl-gw52xx \
diff --git a/target/linux/imx6/image/bootscript-gateworks_ventana
b/target/linux/imx6/image/bootscript-ventana
similarity index 100%
rename from target/linux/imx6/image/bootscript-gateworks_ventana
rename to target/linux/imx6/image/bootscript-ventana
--
2.33.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH 02/14] imx6: refresh and update target kernel configs
This is a minor extension of the commit 26ae69fd03 ("imx6: refresh
kernel config with 5.10 symbols"), with correct and full disable of
the Arm Cortex-A7 based i.MX 6UL and 6UL{L,Z} families support and
re-enable of the Cortex-A9 based i.MX 6L{S,X}.
Signed-off-by: Piotr Dymacz
---
target/linux/imx6/config-5.10 | 25 ++---
target/linux/imx6/config-5.4 | 5 +++--
2 files changed, 9 insertions(+), 21 deletions(-)
diff --git a/target/linux/imx6/config-5.10 b/target/linux/imx6/config-5.10
index 9238678258..624013aa81 100644
--- a/target/linux/imx6/config-5.10
+++ b/target/linux/imx6/config-5.10
@@ -16,6 +16,7 @@ CONFIG_ARCH_SELECT_MEMORY_MODEL=y
CONFIG_ARCH_SPARSEMEM_ENABLE=y
CONFIG_ARCH_SUSPEND_POSSIBLE=y
CONFIG_ARM=y
+CONFIG_ARM_ARCH_TIMER=y
CONFIG_ARM_ARCH_TIMER_EVTSTREAM=y
CONFIG_ARM_CPU_SUSPEND=y
CONFIG_ARM_CRYPTO=y
@@ -50,9 +51,8 @@ CONFIG_CLKDEV_LOOKUP=y
CONFIG_CLKSRC_IMX_GPT=y
CONFIG_CLKSRC_MMIO=y
CONFIG_CLK_IMX6Q=y
-# CONFIG_CLK_IMX6SL is not set
-# CONFIG_CLK_IMX6SX is not set
-# CONFIG_CLK_IMX6UL is not set
+CONFIG_CLK_IMX6SL=y
+CONFIG_CLK_IMX6SX=y
# CONFIG_CLK_IMX8MM is not set
# CONFIG_CLK_IMX8MN is not set
# CONFIG_CLK_IMX8MP is not set
@@ -93,13 +93,8 @@ CONFIG_CPU_THUMB_CAPABLE=y
CONFIG_CPU_TLB_V7=y
CONFIG_CPU_V7=y
CONFIG_CRC16=y
-CONFIG_CRYPTO_ACOMP2=y
-CONFIG_CRYPTO_AEAD=y
-CONFIG_CRYPTO_AEAD2=y
CONFIG_CRYPTO_AES_ARM=y
CONFIG_CRYPTO_AES_ARM_BS=y
-CONFIG_CRYPTO_AKCIPHER=y
-CONFIG_CRYPTO_AKCIPHER2=y
CONFIG_CRYPTO_ARCH_HAVE_LIB_CHACHA=y
CONFIG_CRYPTO_AUTHENC=y
CONFIG_CRYPTO_CBC=y
@@ -109,7 +104,6 @@ CONFIG_CRYPTO_CRC32=y
CONFIG_CRYPTO_CRC32C=y
CONFIG_CRYPTO_CRC32_ARM_CE=y
CONFIG_CRYPTO_CRYPTD=y
-CONFIG_CRYPTO_CTR=y
CONFIG_CRYPTO_CTS=y
CONFIG_CRYPTO_DEFLATE=y
CONFIG_CRYPTO_DEV_FSL_CAAM=y
@@ -129,8 +123,7 @@ CONFIG_CRYPTO_DRBG_HMAC=y
CONFIG_CRYPTO_DRBG_MENU=y
CONFIG_CRYPTO_ECB=y
CONFIG_CRYPTO_ENGINE=y
-CONFIG_CRYPTO_HASH=y
-CONFIG_CRYPTO_HASH2=y
+CONFIG_CRYPTO_GF128MUL=y
CONFIG_CRYPTO_HASH_INFO=y
CONFIG_CRYPTO_HMAC=y
CONFIG_CRYPTO_HW=y
@@ -139,11 +132,7 @@ CONFIG_CRYPTO_LIB_CHACHA_GENERIC=y
CONFIG_CRYPTO_LIB_DES=y
CONFIG_CRYPTO_LIB_SHA256=y
CONFIG_CRYPTO_LZO=y
-CONFIG_CRYPTO_MANAGER=y
-CONFIG_CRYPTO_MANAGER2=y
-CONFIG_CRYPTO_NULL=y
CONFIG_CRYPTO_NULL2=y
-# CONFIG_CRYPTO_POLY1305_ARM is not set
CONFIG_CRYPTO_RNG=y
CONFIG_CRYPTO_RNG2=y
CONFIG_CRYPTO_RNG_DEFAULT=y
@@ -187,7 +176,6 @@ CONFIG_F2FS_FS=y
CONFIG_FEC=y
CONFIG_FIXED_PHY=y
CONFIG_FIX_EARLYCON_MEM=y
-# CONFIG_FSL_IMX8_DDR_PMU is not set
CONFIG_FSL_GUTS=y
CONFIG_FS_ENCRYPTION=y
CONFIG_FS_ENCRYPTION_ALGS=y
@@ -236,7 +224,6 @@ CONFIG_HARDIRQS_SW_RESEND=y
CONFIG_HAS_DMA=y
CONFIG_HAS_IOMEM=y
CONFIG_HAS_IOPORT_MAP=y
-CONFIG_HAVE_ARM_ARCH_TIMER=y
CONFIG_HAVE_SMP=y
CONFIG_HWMON=y
CONFIG_HW_RANDOM=y
@@ -278,6 +265,7 @@ CONFIG_LZO_DECOMPRESS=y
CONFIG_MARVELL_PHY=y
CONFIG_MDIO_BUS=y
CONFIG_MDIO_DEVICE=y
+CONFIG_MDIO_DEVRES=y
CONFIG_MEMFD_CREATE=y
CONFIG_MFD_SYSCON=y
CONFIG_MICREL_PHY=y
@@ -363,7 +351,6 @@ CONFIG_PINCTRL_IMX=y
CONFIG_PINCTRL_IMX6Q=y
CONFIG_PINCTRL_IMX6SL=y
CONFIG_PINCTRL_IMX6SX=y
-CONFIG_PINCTRL_IMX6UL=y
# CONFIG_PINCTRL_IMX8MM is not set
# CONFIG_PINCTRL_IMX8MN is not set
# CONFIG_PINCTRL_IMX8MP is not set
@@ -428,7 +415,7 @@ CONFIG_SOC_IMX6Q=y
CONFIG_SOC_IMX6SL=y
# CONFIG_SOC_IMX6SLL is not set
CONFIG_SOC_IMX6SX=y
-CONFIG_SOC_IMX6UL=y
+# CONFIG_SOC_IMX6UL is not set
# CONFIG_SOC_IMX7D is not set
# CONFIG_SOC_IMX7ULP is not set
# CONFIG_SOC_IMX8M is not set
diff --git a/target/linux/imx6/config-5.4 b/target/linux/imx6/config-5.4
index 8bfc21a282..6f5142b012 100644
--- a/target/linux/imx6/config-5.4
+++ b/target/linux/imx6/config-5.4
@@ -90,6 +90,7 @@ CONFIG_CRYPTO_AES_ARM=y
CONFIG_CRYPTO_AES_ARM_BS=y
CONFIG_CRYPTO_AKCIPHER=y
CONFIG_CRYPTO_AKCIPHER2=y
+CONFIG_CRYPTO_ARCH_HAVE_LIB_CHACHA=y
CONFIG_CRYPTO_AUTHENC=y
CONFIG_CRYPTO_CBC=y
CONFIG_CRYPTO_CHACHA20=y
@@ -123,6 +124,7 @@ CONFIG_CRYPTO_HASH_INFO=y
CONFIG_CRYPTO_HMAC=y
CONFIG_CRYPTO_HW=y
CONFIG_CRYPTO_JITTERENTROPY=y
+CONFIG_CRYPTO_LIB_CHACHA_GENERIC=y
CONFIG_CRYPTO_LIB_DES=y
CONFIG_CRYPTO_LIB_SHA256=y
CONFIG_CRYPTO_LZO=y
@@ -338,7 +340,6 @@ CONFIG_PINCTRL_IMX=y
CONFIG_PINCTRL_IMX6Q=y
CONFIG_PINCTRL_IMX6SL=y
CONFIG_PINCTRL_IMX6SX=y
-CONFIG_PINCTRL_IMX6UL=y
CONFIG_PL310_ERRATA_769419=y
CONFIG_PM=y
CONFIG_PM_CLK=y
@@ -399,7 +400,7 @@ CONFIG_SOC_IMX6Q=y
CONFIG_SOC_IMX6SL=y
# CONFIG_SOC_IMX6SLL is not set
CONFIG_SOC_IMX6SX=y
-CONFIG_SOC_IMX6UL=y
+# CONFIG_SOC_IMX6UL is not set
# CONFIG_SOC_IMX7D is not set
# CONFIG_SOC_IMX7ULP is not set
# CONFIG_SOC_LS1021A is not set
--
2.33.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH 00/14] imx6 conversion into arch-specific subtargets
The following series includes work on making the 'imx6' target generic and universal by splitting it into arch-specifig subtargets. Devices supported withing the old 'imx6' are moved to 'imx/cortexa9' subtarget and an additional one, called'imx/cortexa7' is introduced (patches including support for devices will follow). Some examples of work-in-progress devices support in 'imx/cortexa7' subtarget are available in my and Petr's staging trees [1], [2]. Additionally, the new target is switched to kernel 5.10, support for the 5.4 is dropped and Gateworks Ventana related bug is fixed. Piotr Dymacz (14): imx6: image: fix Gateworks Ventana boot script filename imx6: refresh and update target kernel configs imx6: rename target to 'imx' kernel: update dependencies after 'imx6' -> 'imx' rename kobs-ng: update dependencies after 'imx6' -> 'imx' rename uboot-envtools: rename 'imx6' to 'imx' uboot-imx6: rename to 'uboot-imx' imx: split into arch-specific subtargets uboot-envtools: move imx to imx_cortexa9 uboot-imx: set BUILD_SUBTARGET to 'cortexa9' imx: introduce 'cortexa7' subtarget imx: make kernel 5.10 default version imx: update subtargets default kernel configs for 5.10 imx: remove obsolete Kernel 5.4 [1] https://git.openwrt.org/openwrt/staging/pepe2k.git [2] https://git.openwrt.org/?p=openwrt/staging/ynezz.git;a=log;h=refs/heads/staging -- 2.33.1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: OpenWrt imx split status?
Hi Tim, On 04.10.2021 00:22, Tim Harvey wrote: Piotr, How is your progress regarding submitting patches to OpenWrt to split the imx target into multiple arch related subtargets (like cortexa7, cortexa9)? I'm planning to clean it up and send patches this week. I finally got final revision of the hardware I was working on that for. Is anyone working on i.MX8 support that you know of? I have seen people ask for it in the past but nobody has been persistent about it. I'm not aware of anyone working on something with i.MX8. Do you plan to work on Venice series support in OpenWrt? -- Cheers, Piotr ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] uqmi: Move to community packages repo
Hi Arjun,
On 01.07.2021 21:50, Arjun AK wrote:
Signed-off-by: Arjun AK
There are many devices with uqmi dependency (more than 10?).
Personally, I would prefer to keep this one in the core packages set.
--
Cheers,
Piotr
---
package/network/utils/uqmi/Makefile | 48 --
.../utils/uqmi/files/lib/netifd/proto/qmi.sh | 471 --
2 files changed, 519 deletions(-)
delete mode 100644 package/network/utils/uqmi/Makefile
delete mode 100755 package/network/utils/uqmi/files/lib/netifd/proto/qmi.sh
diff --git a/package/network/utils/uqmi/Makefile
b/package/network/utils/uqmi/Makefile
deleted file mode 100644
index 53ca67230b..00
--- a/package/network/utils/uqmi/Makefile
+++ /dev/null
@@ -1,48 +0,0 @@
-include $(TOPDIR)/rules.mk
-
-PKG_NAME:=uqmi
-PKG_RELEASE:=3
-
-PKG_SOURCE_PROTO:=git
-PKG_SOURCE_URL=$(PROJECT_GIT)/project/uqmi.git
-PKG_SOURCE_DATE:=2020-11-22
-PKG_SOURCE_VERSION:=0a19b5b77140465c29e2afa7d611fe93abc9672f
-PKG_MIRROR_HASH:=0a6641f8e167efd21d464b0b2aeb1fec5f974dddcdb8822fbd5d7190d0b741b4
-PKG_MAINTAINER:=Matti Laakso
-
-PKG_LICENSE:=GPL-2.0
-PKG_LICENSE_FILES:=
-
-PKG_FLAGS:=nonshared
-
-include $(INCLUDE_DIR)/package.mk
-include $(INCLUDE_DIR)/cmake.mk
-
-define Package/uqmi
- SECTION:=net
- CATEGORY:=Network
- SUBMENU:=WWAN
- DEPENDS:=+libubox +libblobmsg-json +kmod-usb-net +kmod-usb-net-qmi-wwan +wwan
- TITLE:=Control utility for mobile broadband modems
-endef
-
-define Package/uqmi/description
- uqmi is a command line tool for controlling mobile broadband modems using
- the QMI-protocol.
-endef
-
-TARGET_CFLAGS += \
- -I$(STAGING_DIR)/usr/include -ffunction-sections -fdata-sections
-
-TARGET_LDFLAGS += -Wl,--gc-sections
-
-CMAKE_OPTIONS += \
- -DDEBUG=1
-
-define Package/uqmi/install
- $(INSTALL_DIR) $(1)/sbin
- $(INSTALL_BIN) $(PKG_BUILD_DIR)/uqmi $(1)/sbin/
- $(CP) ./files/* $(1)/
-endef
-
-$(eval $(call BuildPackage,uqmi))
diff --git a/package/network/utils/uqmi/files/lib/netifd/proto/qmi.sh
b/package/network/utils/uqmi/files/lib/netifd/proto/qmi.sh
deleted file mode 100755
index c0134f44dd..00
--- a/package/network/utils/uqmi/files/lib/netifd/proto/qmi.sh
+++ /dev/null
@@ -1,471 +0,0 @@
-#!/bin/sh
-
-[ -n "$INCLUDE_ONLY" ] || {
- . /lib/functions.sh
- . ../netifd-proto.sh
- init_proto "$@"
-}
-
-proto_qmi_init_config() {
- available=1
- no_device=1
- proto_config_add_string "device:device"
- proto_config_add_string apn
- proto_config_add_string auth
- proto_config_add_string username
- proto_config_add_string password
- proto_config_add_string pincode
- proto_config_add_int delay
- proto_config_add_string modes
- proto_config_add_string pdptype
- proto_config_add_int profile
- proto_config_add_boolean dhcp
- proto_config_add_boolean dhcpv6
- proto_config_add_boolean autoconnect
- proto_config_add_int plmn
- proto_config_add_int timeout
- proto_config_add_int mtu
- proto_config_add_defaults
-}
-
-proto_qmi_setup() {
- local interface="$1"
- local dataformat connstat plmn_mode mcc mnc
- local device apn auth username password pincode delay modes pdptype
- local profile dhcp dhcpv6 autoconnect plmn timeout mtu
$PROTO_DEFAULT_OPTIONS
- local ip4table ip6table
- local cid_4 pdh_4 cid_6 pdh_6
- local ip_6 ip_prefix_length gateway_6 dns1_6 dns2_6
-
- json_get_vars device apn auth username password pincode delay modes
- json_get_vars pdptype profile dhcp dhcpv6 autoconnect plmn ip4table
- json_get_vars ip6table timeout mtu $PROTO_DEFAULT_OPTIONS
-
- [ "$timeout" = "" ] && timeout="10"
-
- [ "$metric" = "" ] && metric="0"
-
- [ -n "$ctl_device" ] && device=$ctl_device
-
- [ -n "$device" ] || {
- echo "No control device specified"
- proto_notify_error "$interface" NO_DEVICE
- proto_set_available "$interface" 0
- return 1
- }
-
- [ -n "$delay" ] && sleep "$delay"
-
- device="$(readlink -f $device)"
- [ -c "$device" ] || {
- echo "The specified control device does not exist"
- proto_notify_error "$interface" NO_DEVICE
- proto_set_available "$interface" 0
- return 1
- }
-
- devname="$(basename "$device")"
- devpath="$(readlink -f /sys/class/usbmisc/$devname/device/)"
- ifname="$( ls "$devpath"/net )"
- [ -n "$ifname" ] || {
- echo "The interface could not be found."
- proto_notify_error "$interface" NO_IFACE
- proto_set_available "$interface" 0
- return 1
- }
-
- [ -n "$mtu" ] && {
- echo "Setting MTU to $mtu"
- /sbin/ip link set dev $ifname mtu $mtu
- }
-
- echo "Waiting for SIM initialization"
- local uninitialized_timeou
Re: [PATCH] comgt: Move to community packages repo
Hi Arjun, Lech, On 29.06.2021 17:57, Arjun AK wrote: On 29/06/21 2:21 am, Lech Perczak wrote: [...] OTOH, this differs a bit from such packages, by being needed to connect to WAN on such devices. This is the same way as uqmi does on some - removing it would require other Internet connection to bootstrap its installation. I too agree with this, Unlike SDCard or USB, networking is a core feature and should work out of the box. I don't think we have such a problem with this particular device. Its default network configuration [1] has a dedicated WAN port within Ethernet switch thus I don't think the 3G modem is the main/only Internet connectivity available here. I don't even think we have a device with just 3G/LTE/5G connectivity in our repository. There is always some Ethernet and/or USB on the other "end". And with tools like [2] it's now easier for the end user to get release/snapshot image with additional packages embedded. [1] https://github.com/openwrt/openwrt/blob/master/target/linux/ramips/rt305x/base-files/etc/board.d/02_network#L109 [2] https://chef.libremesh.org -- Cheers, Piotr - Arjun ___ 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: [PATCH] comgt: Move to community packages repo
Hi John, On 28.06.2021 20:32, John Crispin wrote: On 28.06.21 19:26, Piotr Dymacz wrote: I might be wrong here but I think we don't include packages from external feeds inside 'DEVICE_PACKAGES' (not sure/don't remember why). I am in favour of moving all none-core packages to the feeds. the dependency should be removed and a note should be added to the wiki indicating that if a release/snapshot image is installed an opkg call shall be issued Sounds good to me, just wanted to warn about the existing dependency. -- Cheers, Piotr John ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] comgt: Move to community packages repo
Hi Arjun, On 28.06.2021 19:43, Arjun AK wrote: On 28/06/21 10:56 pm, Piotr Dymacz wrote: Hi Arjun, On 28.06.2021 18:52, Arjun AK wrote: Signed-off-by: Arjun AK The only problem here is a D-Link DWR-512B device (ramips/rt305x target) which has 'comgt-ncm' package listed under 'DEVICE_PACKAGES', see [1]. But the package name is "comgt" not "comgt-ncm". Does this mean DWR-512B has no dependency on comgt and is trying to build a non existent package? 'comgt-ncm' is part of the 'comgt', see: https://github.com/openwrt/openwrt/blob/master/package/network/utils/comgt/Makefile#L47 -- Cheers, Piotr - Arjun ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] comgt: Move to community packages repo
Hi Arjun, On 28.06.2021 18:52, Arjun AK wrote: Signed-off-by: Arjun AK The only problem here is a D-Link DWR-512B device (ramips/rt305x target) which has 'comgt-ncm' package listed under 'DEVICE_PACKAGES', see [1]. I might be wrong here but I think we don't include packages from external feeds inside 'DEVICE_PACKAGES' (not sure/don't remember why). [1] https://github.com/openwrt/openwrt/blob/master/target/linux/ramips/image/rt305x.mk#L476 -- Cheers, Piotr --- package/network/utils/comgt/Makefile | 106 package/network/utils/comgt/files/3g.chat | 12 - package/network/utils/comgt/files/3g.sh | 116 package/network/utils/comgt/files/3g.usb | 33 --- .../utils/comgt/files/directip-stop.gcom | 16 -- .../network/utils/comgt/files/directip.gcom | 55 package/network/utils/comgt/files/directip.sh | 114 package/network/utils/comgt/files/evdo.chat | 17 -- .../utils/comgt/files/getcardinfo.gcom| 14 - .../network/utils/comgt/files/getcarrier.gcom | 20 -- .../network/utils/comgt/files/getcnum.gcom| 20 -- .../network/utils/comgt/files/getimsi.gcom| 17 -- .../utils/comgt/files/getstrength.gcom| 14 - package/network/utils/comgt/files/ncm.json| 78 -- package/network/utils/comgt/files/ncm.sh | 255 -- .../network/utils/comgt/files/runcommand.gcom | 31 --- .../network/utils/comgt/files/setmode.gcom| 26 -- package/network/utils/comgt/files/setpin.gcom | 56 package/network/utils/comgt/files/ussd.gcom | 21 -- .../utils/comgt/patches/001-compile_fix.patch | 23 -- .../utils/comgt/patches/002-termios.patch | 105 .../utils/comgt/patches/003-no_XCASE.patch| 20 -- .../utils/comgt/patches/004-check_tty.patch | 68 - 23 files changed, 1237 deletions(-) delete mode 100644 package/network/utils/comgt/Makefile delete mode 100644 package/network/utils/comgt/files/3g.chat delete mode 100644 package/network/utils/comgt/files/3g.sh delete mode 100644 package/network/utils/comgt/files/3g.usb delete mode 100644 package/network/utils/comgt/files/directip-stop.gcom delete mode 100644 package/network/utils/comgt/files/directip.gcom delete mode 100644 package/network/utils/comgt/files/directip.sh delete mode 100644 package/network/utils/comgt/files/evdo.chat delete mode 100644 package/network/utils/comgt/files/getcardinfo.gcom delete mode 100644 package/network/utils/comgt/files/getcarrier.gcom delete mode 100644 package/network/utils/comgt/files/getcnum.gcom delete mode 100644 package/network/utils/comgt/files/getimsi.gcom delete mode 100644 package/network/utils/comgt/files/getstrength.gcom delete mode 100644 package/network/utils/comgt/files/ncm.json delete mode 100644 package/network/utils/comgt/files/ncm.sh delete mode 100644 package/network/utils/comgt/files/runcommand.gcom delete mode 100644 package/network/utils/comgt/files/setmode.gcom delete mode 100644 package/network/utils/comgt/files/setpin.gcom delete mode 100644 package/network/utils/comgt/files/ussd.gcom delete mode 100644 package/network/utils/comgt/patches/001-compile_fix.patch delete mode 100644 package/network/utils/comgt/patches/002-termios.patch delete mode 100644 package/network/utils/comgt/patches/003-no_XCASE.patch delete mode 100644 package/network/utils/comgt/patches/004-check_tty.patch diff --git a/package/network/utils/comgt/Makefile b/package/network/utils/comgt/Makefile deleted file mode 100644 index db5ea57473..00 --- a/package/network/utils/comgt/Makefile +++ /dev/null @@ -1,106 +0,0 @@ -# -# Copyright (C) 2006-2014 OpenWrt.org -# -# This is free software, licensed under the GNU General Public License v2. -# See /LICENSE for more information. -# - -include $(TOPDIR)/rules.mk - -PKG_NAME:=comgt -PKG_VERSION:=0.32 -PKG_RELEASE:=33 - -PKG_SOURCE:=$(PKG_NAME).$(PKG_VERSION).tgz -PKG_SOURCE_URL:=@SF/comgt -PKG_HASH:=0cedb2a5aa608510da66a99aab74df3db363df495032e57e791a2ff55f1d7913 - -PKG_MAINTAINER:=Felix Fietkau -PKG_LICENSE:=GPL-2.0+ - -PKG_BUILD_DIR:=$(BUILD_DIR)/$(PKG_NAME).$(PKG_VERSION) -PKG_CHECK_FORMAT_SECURITY:=0 - -PKG_FLAGS:=nonshared - -include $(INCLUDE_DIR)/package.mk - -define Package/comgt/Default - SECTION:=net - CATEGORY:=Network - SUBMENU:=WWAN -endef - -define Package/comgt -$(call Package/comgt/Default) - TITLE:=Option/Vodafone 3G/GPRS control tool - DEPENDS:=+chat - URL:=http://manpages.ubuntu.com/manpages/trusty/man1/comgt.1.html -endef - -define Package/comgt-directip -$(call Package/comgt/Default) - TITLE:=Sierra Wireless Direct-IP support - DEPENDS:=+comgt +kmod-usb-serial +kmod-usb-serial-sierrawireless +kmod-usb-net +kmod-usb-net-sierrawireless -endef - -define Package/comgt-ncm -$(call Package/comgt/Default) - TITLE+=NCM 3G/4G Support - DEPENDS:=+comgt +wwan +kmod-usb-serial-option +kmod-usb-net-huawei-cdc-ncm -endef - -define Package/comgt/description
Re: [PATCH 1/1] Reset modem upon initialization.
Hi Ontje,
On 28.06.2021 13:56, ontje.luensd...@dlr.de wrote:
From: Ontje Lünsdorf
The rut955 fails to activate its modem upon every second reboot otherwise.
This will issue reset every time the qmi connection is (re-)initialized,
making the whole (re-)connection process much longer. Does the modem
really need to be reset every time the connection is brought up or just
once, after the bootup?
IIRC, RUT9xx series has a dedicated GPIO for modem power enable/disable.
How about using that instead?
--
Cheers,
Piotr
Co-authored-by: hans-hermann.reden...@dlr.de
Co-authored-by: jonas.stuehrenb...@dlr.de
---
package/network/utils/uqmi/files/lib/netifd/proto/qmi.sh | 4
1 file changed, 4 insertions(+)
diff --git a/package/network/utils/uqmi/files/lib/netifd/proto/qmi.sh
b/package/network/utils/uqmi/files/lib/netifd/proto/qmi.sh
index c0134f4..60695ec 100755
--- a/package/network/utils/uqmi/files/lib/netifd/proto/qmi.sh
+++ b/package/network/utils/uqmi/files/lib/netifd/proto/qmi.sh
@@ -81,6 +81,10 @@ proto_qmi_setup() {
echo "Waiting for SIM initialization"
local uninitialized_timeout=0
+
+ # Reset modem, workaround for a buggy modem after an reboot
+ uqmi -s -d "$device" --set-device-operating-mode reset
+
while uqmi -s -d "$device" --get-pin-status | grep '"UIM uninitialized"'
> /dev/null; do
[ -e "$device" ] || return 1
if [ "$uninitialized_timeout" -lt "$timeout" -o "$timeout" =
"0" ]; then
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: imx6 - gateworks target broken
Hi Koen, On 25.06.2021 11:04, Koen Vandeputte wrote: Hi Piotr, It seems imx6 Gateworks Ventana target got broken. I suspect it's due to following commit: https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=8dba71dd33c8e35e7f363ffdb2ba42259ab43ce2 After this commit, the bootfile generated is this one: - 6x_bootscript-gateworks_ventana While the bootloader looks for this: Loading file '/6x_bootscript-ventana' to addr 0x1200... ** File not found /6x_bootscript-ventana ** Due to this, the fixup does not happen and wrong kernel params are provided causing a panic as the rootfs is not found. Any idea how to fix this one properly? Revert the naming to plain "ventana" again? Oh, I'm sorry for that! I see that the 'script' var value is embedded in env [1] so probably the only correct way is to adjust it back on our side. Let me fix that as I also plan to send couple of patches with imx6 to imx split. [1] https://source.denx.de/u-boot/u-boot/-/blob/master/include/configs/gw_ventana.h#L154 -- Cheers, Piotr Thanks, Koen ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] ugps: start also in case device is absent
Hi Daniel,
On 27.05.2021 12:37, Daniel Golle wrote:
Don't bail out from init script in case the GPS device is missing.
Some modems take time to come up, and some people may use things like
'kplex' to feed ugpsd. Hence it is better to always start ugpsd
unconditionally and let procd's respawn take care of retrying.
Wouldn't hotplug be a better solution than respawning process forever
(not sure about kplex usage)?
--
Cheers,
Piotr
Signed-off-by: Daniel Golle
---
package/utils/ugps/Makefile| 2 +-
package/utils/ugps/files/ugps.init | 12
2 files changed, 9 insertions(+), 5 deletions(-)
diff --git a/package/utils/ugps/Makefile b/package/utils/ugps/Makefile
index 4ce64d9631..16cdbc41b9 100644
--- a/package/utils/ugps/Makefile
+++ b/package/utils/ugps/Makefile
@@ -8,7 +8,7 @@
include $(TOPDIR)/rules.mk
PKG_NAME:=ugps
-PKG_RELEASE:=1
+PKG_RELEASE:=2
PKG_SOURCE_URL=$(PROJECT_GIT)/project/ugps.git
PKG_SOURCE_PROTO:=git
diff --git a/package/utils/ugps/files/ugps.init
b/package/utils/ugps/files/ugps.init
index 3cd1ca1b8d..f52b19cc27 100644
--- a/package/utils/ugps/files/ugps.init
+++ b/package/utils/ugps/files/ugps.init
@@ -17,10 +17,14 @@ start_service() {
[ "$disabled" == "0" ] || return
- [ -c "$tty" ] || {
- tty="/dev/$tty"
- [ -c "$tty" ] || return
- }
+ case "$tty" in
+ "/"*)
+ true
+ ;;
+ *)
+ tty="/dev/$tty"
+ ;;
+ esac
procd_open_instance
procd_set_param command "$PROG"
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] uboot-envtools: support uci-default config also per subtargets
The current version of 'uboot-envtools' package generates dedicated uci-default file only per target. This change makes it possible to use subtarget-specific files, with name pattern: 'target_subtarget' (example: 'ath79_nand'). The subtarget-specific files will take precedence over target-specific one. Signed-off-by: Piotr Dymacz --- package/boot/uboot-envtools/Makefile | 10 +++--- 1 file changed, 7 insertions(+), 3 deletions(-) diff --git a/package/boot/uboot-envtools/Makefile b/package/boot/uboot-envtools/Makefile index a9eccec0ce..597a029bee 100644 --- a/package/boot/uboot-envtools/Makefile +++ b/package/boot/uboot-envtools/Makefile @@ -70,9 +70,13 @@ define Package/uboot-envtools/install $(INSTALL_DIR) $(1)/lib $(INSTALL_DATA) ./files/uboot-envtools.sh $(1)/lib $(INSTALL_DIR) $(1)/etc/uci-defaults - $(if $(wildcard ./files/$(BOARD)), \ - $(INSTALL_DATA) ./files/$(BOARD) \ - $(1)/etc/uci-defaults/30_uboot-envtools \ + $(if $(wildcard ./files/$(BOARD)_$(SUBTARGET)), \ + $(INSTALL_DATA) ./files/$(BOARD)_$(SUBTARGET) \ + $(1)/etc/uci-defaults/30_uboot-envtools, \ + $(if $(wildcard ./files/$(BOARD)), \ + $(INSTALL_DATA) ./files/$(BOARD) \ + $(1)/etc/uci-defaults/30_uboot-envtools \ + ) \ ) endef -- 2.31.1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
imx6 target split (Cortex-A9 vs. Cortex-A7)
Hi,
I have two devices based on the NXP i.MX6 ULL I would like to get
officially supported by OpenWrt.
The UL, ULL and ULZ series, in contrast to the rest of i.MX6 family
(Cortex-A9), are based on the Cortex-A7.
I'm wondering what would be the most acceptable way to handle this?
Is splitting imx6 target into two subtargets called 'cortexa7' and
'cortexa9' the way to go?
I'm also thinking about future as I will probably want to include
another one device, this time with i.MX7 (Cortex-A7) so maybe it would
make more sense to rename the 'imx6' target into something more generic,
like 'imx' and introduce arch-related subtargets ('cortexa7', 'cortexa9'
and later, if something comes up, cortexa.. for the i.MX8 family)?
--
Cheers,
Piotr
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] uboot-imx6: drop support for Nitrogen6x/SABRE devices
These devices never got officially supported in the tree thus it doesn't make much sense to waste our infrastructure resources and keep building dedicated U-Boot images for them. CC: Petr Štetiar CC: Luka Perkov Signed-off-by: Piotr Dymacz --- package/boot/uboot-imx6/Makefile | 35 1 file changed, 35 deletions(-) diff --git a/package/boot/uboot-imx6/Makefile b/package/boot/uboot-imx6/Makefile index 79acd4abf7..8090f0e62a 100644 --- a/package/boot/uboot-imx6/Makefile +++ b/package/boot/uboot-imx6/Makefile @@ -34,34 +34,6 @@ define U-Boot/mx6cuboxi HIDDEN:=1 endef -define U-Boot/mx6sabresd - NAME:=SABRE i.MX6Quad board -endef - -define U-Boot/nitrogen6dl - NAME:=Nitrogen6x i.MX6Dual-Lite 1GB board -endef - -define U-Boot/nitrogen6dl2g - NAME:=Nitrogen6x i.MX6Dual-Lite 2GB board -endef - -define U-Boot/nitrogen6q - NAME:=Nitrogen6x/SABRE Lite (MX6Q/1GB) -endef - -define U-Boot/nitrogen6q2g - NAME:=Nitrogen6x i.MX6Quad 2GB board -endef - -define U-Boot/nitrogen6s - NAME:=Nitrogen6x i.MX6Solo 512MB board -endef - -define U-Boot/nitrogen6s1g - NAME:=Nitrogen6x i.MX6Solo 1GB board -endef - define U-Boot/wandboard NAME:=Wandboard Dual Lite/Quad/Solo BUILD_DEVICES:=wandboard @@ -70,13 +42,6 @@ endef UBOOT_TARGETS := \ apalis_imx6 \ mx6cuboxi \ - mx6sabresd \ - nitrogen6dl \ - nitrogen6dl2g \ - nitrogen6q \ - nitrogen6q2g \ - nitrogen6s \ - nitrogen6s1g \ wandboard UBOOT_MAKE_FLAGS += u-boot.imx -- 2.30.1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Initial flashing over "OEM-OpenWrt"
Hi Adrian, On 06.02.2021 17:42, Adrian Schmutzler wrote: Hi, when reviewing device-support PRs, I frequently encounter the case that initial flashing means sysupgrading from an OEM-modified OpenWrt. This obviously means that the config of this OEM-OpenWrt should be wiped to prevent config-clashes, but since we only provide sysupgrade in this case we can only tell the user to do so. In this context, I wonder whether we should exploit the compat_version for that purpose, i.e. make the initial "proper" OpenWrt image version 1.1. Since the OEM-OpenWrt won't know about compat_version, this technically will have the same effect as removing SUPPORTED_DEVICES, i.e. the user will need to use -F (and we still can't check whether he uses the necessary -F -n). However, the compat_version approach will give us the chance to show an additional message, and thus at least will allow to instruct the user during the upgrade itself, and not just in the Wiki or in the commit message (which he might or might not read). The purpose of this e-mail is thus to ask: 1. Do we need this, or do we just expect the user to care, i.e. if he breaks the device by keeping config it's his fault? Users are supposed to read flashing instructions provided by the author of device's support and follow them. In case of a soft-brick, we have failsafe and factory reset which is definitely enough to fix this "problem". Let's give our users a little trust here. 2. Is the compat_version solution acceptable? Definitely not, but do we really want to introduce more bloat and magic just to prevent some extremely rare users mistakes? Please, don't. 3. Does somebody have a better idea, or are there already other solutions to the problem I don't know? Personally I don't consider it as a problem at all. I believe you should also look at this from the other side. There are vendors which are up to date with our code base and updating with preserving setting is doable and safe (I'm assuming stable releases here). -- Cheers, Piotr Recent example is e.g. this one: https://github.com/openwrt/openwrt/pull/3816 Thanks Adrian ___ 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
[PATCH] base-files: drop banner.failsafe if failsafe is disabled
Signed-off-by: Piotr Dymacz --- package/base-files/Makefile | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/package/base-files/Makefile b/package/base-files/Makefile index e13578860f..a08bcce733 100644 --- a/package/base-files/Makefile +++ b/package/base-files/Makefile @@ -12,7 +12,7 @@ include $(INCLUDE_DIR)/version.mk include $(INCLUDE_DIR)/feeds.mk PKG_NAME:=base-files -PKG_RELEASE:=237 +PKG_RELEASE:=238 PKG_FLAGS:=nonshared PKG_FILE_DEPENDS:=$(PLATFORM_DIR)/ $(GENERIC_PLATFORM_DIR)/base-files/ @@ -202,6 +202,9 @@ define Package/base-files/install $(VERSION_SED_SCRIPT) $(1)/etc/opkg/distfeeds.conf) $(if $(CONFIG_IPK_FILES_CHECKSUMS),, \ rm -f $(1)/sbin/pkg_check) + + $(if $(CONFIG_TARGET_PREINIT_DISABLE_FAILSAFE), \ + rm -f $(1)/etc/banner.failsafe,) endef ifneq ($(DUMP),1) -- 2.25.1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [RFC PATCH] ath79: remove model name from LED labels
Hi Felix, Adrian, On 30.09.2020 13:53, Felix Fietkau wrote: On 2020-09-30 13:43, Adrian Schmutzler wrote: -Original Message- From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org] On Behalf Of Adrian Schmutzler Sent: Sonntag, 27. September 2020 23:55 To: openwrt-devel@lists.openwrt.org Subject: RE: [RFC PATCH] ath79: remove model name from LED labels Hi all, since there doesn't seem to be any interest in the subject initially, I'd also be interested if there are any general objections towards dropping "devicename" and using "color:function" scheme on LEDs. I'd actually be quite happy to get rid of this obstacle that annoyed me consistently throughout my involvement with OpenWrt. The devicename in the LEDs has also annoyed me often enough. No idea why it was added in the first place. It comes from upstream (2006-2008): https://github.com/torvalds/linux/commit/75c1d31d9ea71025b73430c696b727e8aa15872d https://github.com/torvalds/linux/commit/6c152beefbf90579d21afc4f7e075b1f801f9a75 I think getting rid of it is a really good idea. It doesn't bring us closer to the current upstream approach (functions and colors IDs) but should make things easier for contributors and reviewers. -- Cheers, Piotr - Felix ___ 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: Licensing an OpenWrt router - No response to Trademark use
Hi Scott, On 19.08.2020 23:57, Heppler, J. Scott wrote: Too much effort to say "No interest at this time?" I agree, we do have problem answering e-mails from contact@ inbox. But I hope we will soon sort it out and get better at it. -- Cheers, Piotr On Aug 19, 2020: 23:25, Piotr Dymacz wrote: Hi Scott, On 18.08.2020 23:27, Heppler, J. Scott wrote: request. Reply-To: Organization: I sent an email to cont...@openwrt.org, subject line Trademark Use Request, inquiring about crowd funding an OpenWrt router. I never received a reply. The email gave the background, links to forum discussion and a poll and outlined the basic structure. The contents: Probably nobody with access to this mailbox was interested in your idea. [...] Would the project be interested in exploring this further?" Personally, I don't think so. 3y ago we (some of devs with commit access) were discussing similar idea. But there just wasn't enough interest in it. -- Cheers, Piotr ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Licensing an OpenWrt router - No response to Trademark use
Hi Scott, On 18.08.2020 23:27, Heppler, J. Scott wrote: request. Reply-To: Organization: I sent an email to cont...@openwrt.org, subject line Trademark Use Request, inquiring about crowd funding an OpenWrt router. I never received a reply. The email gave the background, links to forum discussion and a poll and outlined the basic structure. The contents: Probably nobody with access to this mailbox was interested in your idea. [...] Would the project be interested in exploring this further?" Personally, I don't think so. 3y ago we (some of devs with commit access) were discussing similar idea. But there just wasn't enough interest in it. -- Cheers, Piotr ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: ramips: mt7621 novel art_block partition
Hi, On 27.07.2020 03:30, Heppler, J. Scott wrote: I came onto a Trendnet TEW-827DRU Version 2 that is MT7621an with MT7615E x 2 wifi chips. I was able to get UART output and stock has these partitions: [2.512000] 0x-0x0100 : "ALL" [2.52] 0x-0x0003 : "Bootloader" [2.532000] 0x0003-0x0004 : "Config" [2.544000] 0x0004-0x0005 : "Factory" [2.552000] 0x0005-0x00ef : "firmware" [2.564000] 0x0005-0x0038 : "kernel" [2.576000] 0x0038-0x00ef : "rootfs" [2.584000] 0x00ef-0x00ff : "rootfs_data" [2.596000] 0x00ff-0x0100 : "art_block" I reviewed all the mt7621 *dts files and none have an art_block. grep -rn "art_block" target/linux/ramips/dts/ target/linux/ramips/dts/mt7621_elecom_wrc-1900gst.dts:31: label = "art_block"; target/linux/ramips/dts/mt7621_elecom_wrc-2533gst.dts:30: label = "art_block"; target/linux/ramips/dts/mt7621_elecom_wrc-1750gs.dts:31: label = "art_block"; My understanding is that for Qualcomm, the art* partition contains Atheros calibration data. I'm lost as to what and art_block is on a mediatek device. Trendnet can be lazy with partition naming - the TEW-810 has a partion referred to a D-Link. Does this partition contain any data or is empty? I suppose you can just ignore it (keep it as read-only), it looks like copy&paste mistake made by original board manufacturer. -- Cheers, Piotr I did find a "firmware2" partition - mt7621_asus_rt-acx5p.dtsi, a "second_config" - mt7621_mtc_wr1201.dts that are about the same size and position. Are there any Mediatek experts that can enlighten me and point me in the right direction? Thanks in advance ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 2/2] ramips: drop non-existant ralink, port-map for Ravpower WD03
Hi Adrian,
On 14.05.2020 16:02, Adrian Schmutzler wrote:
The property "ralink,port-map" never existed, and the device is a
one-port anyway. Just remove it.
Never? Did you check d57223259b?
--
Cheers,
Piotr
Fixes: 5ef79af4f80f ("ramips: add support for Ravpower WD03")
Signed-off-by: Adrian Schmutzler
---
target/linux/ramips/dts/mt7620n_ravpower_wd03.dts | 1 -
1 file changed, 1 deletion(-)
diff --git a/target/linux/ramips/dts/mt7620n_ravpower_wd03.dts
b/target/linux/ramips/dts/mt7620n_ravpower_wd03.dts
index 6d734bb836..f67f186be1 100644
--- a/target/linux/ramips/dts/mt7620n_ravpower_wd03.dts
+++ b/target/linux/ramips/dts/mt7620n_ravpower_wd03.dts
@@ -100,7 +100,6 @@
ðernet {
mtd-mac-address = <&factory 0x4000>;
- ralink,port-map = "w";
};
&wmac {
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] mvebu: add support for GL.iNet GL-MV1000
Hi Tomasz, Li,
On 14.04.2020 20:53, Tomasz Maciej Nowak wrote:
W dniu 14.04.2020 o 06:20, Li.zhang pisze:
Hi Tomasz,
Thank you very much for you correction.
+};
+
+&spi0 {
+status = "okay";
+
+flash@0 {
+reg = <0>;
+compatible = "jedec,spi-nor";
+spi-max-frequency = <10400>;
+m25p,fast-read;
+partitions {
+compatible = "fixed-partitions";
+#address-cells = <1>;
+#size-cells = <1>;
+
+partition@0 {
+label = "u-boot";
+reg = <0 0xf>;
+};
+
+partition@f {
+label = "u-boot-env";
+reg = <0Xf 0x8000>;
+};
+
+art: partition@f8000 {
+label = "art";
The name of this partition is rather strange, since the hardware
specification doesn't mention any PCIe or SDIO connected wireless
cards (don't know if there's any USB card without eeprom). Is
there any calibration data stored or only MAC address/addresses?
Does U-Boot also read information from this partition? Anyway
that's not a remark to change that name, I'm just curious.
--->MAC,SN,DDNS and ther private information are stored in the art.
Ok, still that name is weird, but that's matter of taste.
ART has a specific meaning (Atheros Radio Test) and it looks just wrong
here, not just weird.
Why not change it to something less misleading?
Maybe 'factory' or 'vendor'?
--
Cheers,
Piotr
On previous patch, there were additionnal partitions in dts
without -emmc suffix : dtb, firmware. If that space would be
unused it's better to add them here, so later You could
introduce images that could be written in SPI flash.
--->There is a short backup firmware in additionnal partitions of
flash,normally it's not visible.In addition The offical firmware is stored in
EMMC,So the previous file(gl-mv1000.dts) was deleted.
Then it would be better to specify those partitions, as some users could simply
overwrite this thinking that's unoccupied space.
+define Device/Default-arm64-emmc
Please don't add generic difinition for single device where only
image name and recipe are slightly changed, please remove it.
+ BOOT_SCRIPT := generic-arm64-emmc
+ DEVICE_DTS_DIR := $(DTS_DIR)/marvell
+ IMAGES := emmc.img
+ IMAGE/emmc.img := boot-scr | boot-img-ext4 | sdcard-img-ext4 |
append-metadata
+ KERNEL_NAME := Image
+ KERNEL := kernel-bin
+endef
+
define Device/NAND-128K
BLOCKSIZE := 128k
PAGESIZE := 2048
diff --git a/target/linux/mvebu/image/cortexa53.mk
b/target/linux/mvebu/image/cortexa53.mk
index 77f5c79..4dfd0b4 100644
--- a/target/linux/mvebu/image/cortexa53.mk
+++ b/target/linux/mvebu/image/cortexa53.mk
@@ -69,3 +69,12 @@ define Device/methode_udpu
BOOT_SCRIPT := udpu
endef
TARGET_DEVICES += methode_udpu
+
+define Device/glinet_gl-mv1000-emmc
+ $(call Device/Default-arm64-emmc)
Please call "Default-arm64" here. You can override image recipe
here adding (don't know if that'll be necessary):
--->1,It is used to distinguish between sd card and emmc.So It can let users
better reconginze that it can be applied to EMMC rather than just sd card.
But with this patch, the image has in name "emmc" only, how would users know
that
they can use it for SD card? If both images are interchangable You have to
extend
commit message with instuctions, that single image can be used on both mediums
and how to use them (the SD card is rather obvious, but more explanation is
needed for the eMMC).
Crucial question is left unanswered: Does the U-Boot by default boot OpenWrt
from
eMMC only or eMMC and SD card? And if boot from both, which is booted first?
--->2,Currently,The uboot does not support 'firmware-gzip' upgrades .So it can
not recover system via uboot, when the user's EMMC firmware fails to boot.
Ok.
--->3,Could i create another file(gl-mv1000.mk) to include 'Default-arm64-emmc'?
No, please don't. You can always override IMAGES variable and add multiple
IMAGE recipes in device
definition, there is no reason to add a common stub used ONLY by one device.
Thank you!
Li Zhang | Software Engineer
li.zh...@gl-inet.com
GL.iNet WiFi for Things
Website: www.gl-inet.com | LinkedIn: gl-inet.com | Tel:
+86-755-8660-6126
Room 305-306, Skyworth Digital Building , Shiyan Street, Baoan District,
Shenzhen, China
Email Disclaimer: The content of this email is confidential and intended for
the recipient specified in message only. It is strictly forbidden to share any
part of this message with any third party, without a written consent of the
sender. If you received this message by mistake, please reply to this message
and follow with its deletion, so that we can ensure such a mistak
Re: [OpenWrt-Devel] [PATCH] mvebu/cortexa9: use Linksys codename as PROFILE
Hi Tomasz, Paul, On 01.04.2020 14:03, Tomasz Maciej Nowak wrote: W dniu 01.04.2020 o 08:55, Piotr Dymacz pisze: Hi Paul, On 01.04.2020 01:20, Paul Spooren wrote: The PROFILE names of mvebu/cortexa9/Linksys devices are based on the consumer names (like linksys_wrt1200ac) instead of the vendor codenames (like linksys_caiman) which are however used in the rest of the build system (plathform.sh, bootcount, 01_leds). A running device is not able to know the profile used for its firmware creation as `/tmp/sysinfo/board_name` points to the device tree identifier (equal to Linksys codename) and `/tmp/sysinfo/model` is not deterministically *convertible* to the PROFILE name. The introduction of ALT titles (4ee3cf2b5a) allows to store consumer names and make them available in the `menuconfig` so the profile name is transparent to regular users. This patch changes the mvebu/cortexa9/Linksys PROFILES to use the device tree identifier aka Linksys codename as PROFILE name and uses the consumer name as ALT title. What about firmware filenames? Wouldn't this change confuse people searching for firmware files by device model name? Your change switch this from 'manufacturer_model' approach to 'manufacturer_manufacturer-codename'. Does Linksys ever mention that codenames on their website, in marketing materials, etc.? +1, not even on the device itself there's mention about these code names, and that's why from me that's a NAK. How about patching device's DTSes and include 'manufacturer,model' there instead (in front of the existing ones)? Scripts in 'basic-files' would also need to be fixed but this way we save this (in my opinion) misuse of 'DEVICE_ALT*'. I'm also not sure how many devices are affected here, only Linksys? -- Cheers, Piotr ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] mvebu/cortexa9: use Linksys codename as PROFILE
Hi Paul, On 01.04.2020 01:20, Paul Spooren wrote: The PROFILE names of mvebu/cortexa9/Linksys devices are based on the consumer names (like linksys_wrt1200ac) instead of the vendor codenames (like linksys_caiman) which are however used in the rest of the build system (plathform.sh, bootcount, 01_leds). A running device is not able to know the profile used for its firmware creation as `/tmp/sysinfo/board_name` points to the device tree identifier (equal to Linksys codename) and `/tmp/sysinfo/model` is not deterministically *convertible* to the PROFILE name. The introduction of ALT titles (4ee3cf2b5a) allows to store consumer names and make them available in the `menuconfig` so the profile name is transparent to regular users. This patch changes the mvebu/cortexa9/Linksys PROFILES to use the device tree identifier aka Linksys codename as PROFILE name and uses the consumer name as ALT title. What about firmware filenames? Wouldn't this change confuse people searching for firmware files by device model name? Your change switch this from 'manufacturer_model' approach to 'manufacturer_manufacturer-codename'. Does Linksys ever mention that codenames on their website, in marketing materials, etc.? -- Cheers, Piotr Device tree identifier and PROFILE are now identical except for a `,` replacement with `_`, which is due to Makefile naming limitations. Signed-off-by: Paul Spooren --- This is just a first step, we should follow the device tree identifier for all other PROFILE as well. target/linux/mvebu/image/cortexa9.mk | 56 ++-- 1 file changed, 28 insertions(+), 28 deletions(-) diff --git a/target/linux/mvebu/image/cortexa9.mk b/target/linux/mvebu/image/cortexa9.mk index 85bfa94dbd..53fc7c84b3 100644 --- a/target/linux/mvebu/image/cortexa9.mk +++ b/target/linux/mvebu/image/cortexa9.mk @@ -42,80 +42,80 @@ define Device/linksys KERNEL_SIZE := 6144k endef -define Device/linksys_wrt1200ac +define Device/linksys_caiman $(call Device/linksys) - DEVICE_MODEL := WRT1200AC + DEVICE_MODEL := Caiman DEVICE_ALT0_VENDOR := Linksys - DEVICE_ALT0_MODEL := Caiman + DEVICE_ALT0_MODEL := WRT1200AC DEVICE_DTS := armada-385-linksys-caiman DEVICE_PACKAGES += mwlwifi-firmware-88w8864 SUPPORTED_DEVICES := armada-385-linksys-caiman linksys,caiman endef -TARGET_DEVICES += linksys_wrt1200ac +TARGET_DEVICES += linksys_caiman -define Device/linksys_wrt1900acs +define Device/linksys_shelby $(call Device/linksys) - DEVICE_MODEL := WRT1900ACS - DEVICE_VARIANT := v1 + DEVICE_MODEL := Shelby + DEVICE_ALT0_VENDOR := Linksys + DEVICE_ALT0_MODEL := WRT1900ACS + DEVICE_ALT0_VARIANT := v1 DEVICE_ALT0_VENDOR := Linksys DEVICE_ALT0_MODEL := WRT1900ACS DEVICE_ALT0_VARIANT := v2 - DEVICE_ALT1_VENDOR := Linksys - DEVICE_ALT1_MODEL := Shelby DEVICE_DTS := armada-385-linksys-shelby DEVICE_PACKAGES += mwlwifi-firmware-88w8864 SUPPORTED_DEVICES := armada-385-linksys-shelby linksys,shelby endef -TARGET_DEVICES += linksys_wrt1900acs +TARGET_DEVICES += linksys_shelby -define Device/linksys_wrt1900ac +define Device/linksys_mamba $(call Device/linksys) - DEVICE_MODEL := WRT1900AC - DEVICE_VARIANT := v1 + DEVICE_MODEL := Mamba DEVICE_ALT0_VENDOR := Linksys - DEVICE_ALT0_MODEL := Mamba + DEVICE_ALT0_MODEL := WRT1900AC + DEVICE_ALT0_VARIANT := v1 DEVICE_DTS := armada-xp-linksys-mamba DEVICE_PACKAGES += mwlwifi-firmware-88w8864 KERNEL_SIZE := 3072k SUPPORTED_DEVICES := armada-xp-linksys-mamba linksys,mamba endef -TARGET_DEVICES += linksys_wrt1900ac +TARGET_DEVICES += linksys_mamba -define Device/linksys_wrt1900acv2 +define Device/linksys_cobra $(call Device/linksys) - DEVICE_MODEL := WRT1900AC - DEVICE_VARIANT := v2 + DEVICE_MODEL := Cobra DEVICE_ALT0_VENDOR := Linksys - DEVICE_ALT0_MODEL := Cobra + DEVICE_ALT0_MODEL := WRT1900AC + DEVICE_ALT0VARIANT := v2 DEVICE_DTS := armada-385-linksys-cobra DEVICE_PACKAGES += mwlwifi-firmware-88w8864 SUPPORTED_DEVICES := armada-385-linksys-cobra linksys,cobra endef -TARGET_DEVICES += linksys_wrt1900acv2 +TARGET_DEVICES += linksys_cobra -define Device/linksys_wrt3200acm +define Device/linksys_rango $(call Device/linksys) - DEVICE_MODEL := WRT3200ACM + DEVICE_MODEL := Rango DEVICE_ALT0_VENDOR := Linksys - DEVICE_ALT0_MODEL := Rango + DEVICE_ALT0_MODEL := WRT3200ACM DEVICE_DTS := armada-385-linksys-rango DEVICE_PACKAGES += kmod-btmrvl kmod-mwifiex-sdio mwlwifi-firmware-88w8964 SUPPORTED_DEVICES := armada-385-linksys-rango linksys,rango endef -TARGET_DEVICES += linksys_wrt3200acm +TARGET_DEVICES += linksys_rango -define Device/linksys_wrt32x +define Device/linksys_venom $(call Device/linksys) - DEVICE_MODEL := WRT32X + DEVICE_MODEL := Venom DEVICE_ALT0_VENDOR := Linksys - DEVICE_ALT0_MODEL := Venom + DEVICE_ALT0_MODEL := WRT32X DEVICE_DTS := armada-385-linksys-venom DEVICE_PACKAGES += kmod-b
Re: [OpenWrt-Devel] [PATCH] target.mk: enable iwinfo by default with any wpad variant
Hi Adrian, On 25.03.2020 16:53, m...@adrianschmutzler.de wrote: -Original Message- From: Piotr Dymacz [mailto:pep...@gmail.com] Sent: Mittwoch, 25. März 2020 15:08 To: m...@adrianschmutzler.de; openwrt-devel@lists.openwrt.org Cc: Felix Fietkau ; Jo-Philipp Wich Subject: Re: [OpenWrt-Devel] [PATCH] target.mk: enable iwinfo by default with any wpad variant Hi Adrian, On 25.03.2020 12:21, m...@adrianschmutzler.de wrote: > Hi Piotr, > >> -Original Message- >> From: openwrt-devel [mailto:openwrt-devel- boun...@lists.openwrt.org] >> On Behalf Of Piotr Dymacz >> Sent: Mittwoch, 25. März 2020 00:34 >> To: openwrt-devel@lists.openwrt.org >> Subject: [OpenWrt-Devel] [PATCH] target.mk: enable iwinfo by default >> with any wpad variant [...] > Since you are touching this, maybe you can elaborate why this > extra_packages construct is needed at all? I don't know exact reason and it was added long time ago, in 2014, see: 6435b8bb27e. I suppose that was the easy way to handle it back then? > Why can't we just add iwinfo as selective dependency to the wpad-/nas > packages as we do for all of the other packages? Could you explain what you mean by 'selective dependency'? I don't think DEPENDS is correct way to handle this. Do you mean use 'select iwinfo' in wpad/nas packages config? From the point of _functionality_, it would just be a DEPENDS := +iwinfo for the relevant packages. However, I'm aware that this is not correct from a _conceptional_ point of view, since iwinfo is not a "dependency". Exactly, plus this has also run-time consequences. > I'm asking because I recently had a downstream case where we use > hostapd instead of wpad and wanted to get of iwinfo. I expected iwinfo > to go away because nothing selected it anymore, but in this case it > turned out that iwinfo is not automatically deselected, but has to be > removed manually as well. I suppose you should first look at DEFAULT_PACKAGES and target.mk. In most cases, wpad-* is added there and that's how iwinfo gets selected. For tiny devices, we replace wpad-mini by hostapd-mini (ar71xx/ath79): CONFIG_PACKAGE_hostapd-mini=y CONFIG_PACKAGE_wpad-mini=m However, this will not unselect iwinfo (as it should theoretically according to the extra_packages condition), which will still be at "y", so will be built into the images. This can also be observed in make menuconfig, where deselecting any wpad packages does not affect the status of iwinfo. I assume that the extra-packages condition is just evaluated "too early", and not updated during evaluation in make menuconfig like "real" dependencies. Of course, removing iwinfo/libiwinfo from images can easily be achieved by CONFIG_PACKAGE_iwinfo=m CONFIG_PACKAGE_libiwinfo=m It's just not a "live-update" like we are used to from DEPENDS. If you are using custom config files for building, this is the correct way to handle it. From looking at the dependencies as described in the Wiki [1], I do not think there really is an alternate solution available at the moment, though. Are you sure (warn: haven't tried that)? https://openwrt.org/docs/guide-developer/dependencies#special_notes Somebody would have to build one, something like @TARGET_ath79, but not for visibility, but for selection. So, somebody could just add the new "dependency" (using § as symbol for the example) to the iwinfo package instead of using the extra_packages construct: DEPENDS += §wpad-mini §wpad-basic §nas ... However, I'm not sure whether implementing that would really be worth it, considering that disabling extra_packages manually is still quite easy to do. No. This is not a dependency so DEPENDS is not the correct way to handle it. -- Cheers, Piotr Best Adrian [1] https://openwrt.org/docs/guide-developer/packages#dependency_types But I see the problem here, I'm just not sure if it's safe to change current approach. Maybe Felix or Jo are able to explain reason for using extra_packages. -- Cheers, Piotr > > Best > > Adrian > >> >> define ProfileDefault >>NAME:= >> -- >> 2.20.1 >> >> >> ___ >> openwrt-devel mailing list >> openwrt-devel@lists.openwrt.org >> https://lists.openwrt.org/mailman/listinfo/openwrt-devel > ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] target.mk: enable iwinfo by default with any wpad variant
Hi Adrian, On 25.03.2020 12:21, m...@adrianschmutzler.de wrote: Hi Piotr, -Original Message- From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org] On Behalf Of Piotr Dymacz Sent: Mittwoch, 25. März 2020 00:34 To: openwrt-devel@lists.openwrt.org Subject: [OpenWrt-Devel] [PATCH] target.mk: enable iwinfo by default with any wpad variant [...] Since you are touching this, maybe you can elaborate why this extra_packages construct is needed at all? I don't know exact reason and it was added long time ago, in 2014, see: 6435b8bb27e. I suppose that was the easy way to handle it back then? Why can't we just add iwinfo as selective dependency to the wpad-/nas packages as we do for all of the other packages? Could you explain what you mean by 'selective dependency'? I don't think DEPENDS is correct way to handle this. Do you mean use 'select iwinfo' in wpad/nas packages config? I'm asking because I recently had a downstream case where we use hostapd instead of wpad and wanted to get of iwinfo. I expected iwinfo to go away because nothing selected it anymore, but in this case it turned out that iwinfo is not automatically deselected, but has to be removed manually as well. I suppose you should first look at DEFAULT_PACKAGES and target.mk. In most cases, wpad-* is added there and that's how iwinfo gets selected. But I see the problem here, I'm just not sure if it's safe to change current approach. Maybe Felix or Jo are able to explain reason for using extra_packages. -- Cheers, Piotr Best Adrian define ProfileDefault NAME:= -- 2.20.1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] target.mk: enable iwinfo by default with any wpad variant
There are currently 7 variants of 'wpad' package but 'iwinfo' is
included by default only if 'wpad', 'wpad-{basic,mini}' or 'nas'
packages are included in {DEVICE,DEFAULT}_PACKAGES. Use 'wpad-*'
pattern to include 'iwinfo' with any 'wpad' variant.
Signed-off-by: Piotr Dymacz
---
include/target.mk | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/target.mk b/include/target.mk
index 9bd4c14936..004db1f45b 100644
--- a/include/target.mk
+++ b/include/target.mk
@@ -55,7 +55,7 @@ endif
DEFAULT_PACKAGES += $(DEFAULT_PACKAGES.$(DEVICE_TYPE))
filter_packages = $(filter-out -% $(patsubst -%,%,$(filter -%,$(1))),$(1))
-extra_packages = $(if $(filter wpad-mini wpad-basic wpad nas,$(1)),iwinfo)
+extra_packages = $(if $(filter wpad wpad-% nas,$(1)),iwinfo)
define ProfileDefault
NAME:=
--
2.20.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] treewide: remove maintainer variable from targets
Hi Petr, On 11.03.2020 15:04, Petr Štetiar wrote: There is no such role as target maintainer anymore, one should always send corresponding changes for the review and anyone from the commiters is allowed to merge them or eventually use the hand break and NACK them. Lets make it clear, that it is solely a community doing the maintenance tasks. Acked-by: Piotr Dymacz -- Cheers, Piotr Signed-off-by: Petr Štetiar --- target/linux/apm821xx/Makefile | 2 -- target/linux/arc770/Makefile | 1 - target/linux/archs38/Makefile| 1 - target/linux/armvirt/Makefile| 1 - target/linux/at91/Makefile | 2 -- target/linux/ath25/Makefile | 1 - target/linux/bcm27xx/Makefile| 1 - target/linux/bcm47xx/Makefile| 1 - target/linux/bcm53xx/Makefile| 1 - target/linux/bcm63xx/Makefile| 1 - target/linux/cns3xxx/Makefile| 2 -- target/linux/gemini/Makefile | 1 - target/linux/imx6/Makefile | 1 - target/linux/ipq40xx/Makefile| 1 - target/linux/ipq806x/Makefile| 1 - target/linux/ipq807x/Makefile| 1 - target/linux/lantiq/Makefile | 1 - target/linux/layerscape/Makefile | 1 - target/linux/mediatek/Makefile | 1 - target/linux/mpc85xx/Makefile| 1 - target/linux/mvebu/Makefile | 1 - target/linux/mxs/Makefile| 1 - target/linux/octeon/Makefile | 1 - target/linux/octeontx/Makefile | 2 -- target/linux/omap/Makefile | 2 -- target/linux/oxnas/Makefile | 2 -- target/linux/pistachio/Makefile | 1 - target/linux/ramips/Makefile | 1 - target/linux/rb532/Makefile | 1 - target/linux/samsung/Makefile| 1 - target/linux/sunxi/Makefile | 1 - target/linux/tegra/Makefile | 1 - target/linux/x86/Makefile| 1 - target/linux/zynq/Makefile | 1 - 34 files changed, 40 deletions(-) diff --git a/target/linux/apm821xx/Makefile b/target/linux/apm821xx/Makefile index 9ba623535ee9..9697af77bb78 100644 --- a/target/linux/apm821xx/Makefile +++ b/target/linux/apm821xx/Makefile @@ -9,8 +9,6 @@ BOARD:=apm821xx BOARDNAME:=AppliedMicro APM821xx CPU_TYPE:=464fp FEATURES:=fpu dt gpio -MAINTAINER:=Chris Blake , \ - Christian Lamparter SUBTARGETS:=nand sata KERNEL_PATCHVER:=4.19 diff --git a/target/linux/arc770/Makefile b/target/linux/arc770/Makefile index b5e2d54065e4..8150f147c5aa 100644 --- a/target/linux/arc770/Makefile +++ b/target/linux/arc770/Makefile @@ -9,7 +9,6 @@ include $(TOPDIR)/rules.mk ARCH:=arc BOARD:=arc770 BOARDNAME:=Synopsys DesignWare ARC 770D -MAINTAINER:=Alexey Brodkin SUBTARGETS:=generic KERNEL_PATCHVER:=4.14 diff --git a/target/linux/archs38/Makefile b/target/linux/archs38/Makefile index be6be0472b5a..a6ac05b9dfb3 100644 --- a/target/linux/archs38/Makefile +++ b/target/linux/archs38/Makefile @@ -10,7 +10,6 @@ ARCH:=arc CPU_TYPE:=archs BOARD:=archs38 BOARDNAME:=Synopsys DesignWare ARC HS38 -MAINTAINER:=Alexey Brodkin SUBTARGETS:=generic KERNEL_PATCHVER:=4.14 diff --git a/target/linux/armvirt/Makefile b/target/linux/armvirt/Makefile index 03adf4436cfc..4a8c6b092c91 100644 --- a/target/linux/armvirt/Makefile +++ b/target/linux/armvirt/Makefile @@ -10,7 +10,6 @@ BOARD:=armvirt BOARDNAME:=QEMU ARM Virtual Machine FEATURES:=fpu pci rtc usb FEATURES+=cpiogz ext4 ramdisk squashfs targz -MAINTAINER:=Yousong Zhou KERNEL_PATCHVER:=5.4 diff --git a/target/linux/at91/Makefile b/target/linux/at91/Makefile index 6c1ba11c5510..4780210f36f8 100644 --- a/target/linux/at91/Makefile +++ b/target/linux/at91/Makefile @@ -8,8 +8,6 @@ include $(TOPDIR)/rules.mk ARCH:=arm BOARD:=at91 -MAINTAINER:=Claudio Mignanti \ - Sandeep Sheriker BOARDNAME:=Microchip (Atmel AT91) FEATURES:=ext4 squashfs targz usb usbgadget ubifs SUBTARGETS:=sama5 sam9x diff --git a/target/linux/ath25/Makefile b/target/linux/ath25/Makefile index cb8b7ec1be3e..4fb082edfd67 100644 --- a/target/linux/ath25/Makefile +++ b/target/linux/ath25/Makefile @@ -10,7 +10,6 @@ ARCH:=mips BOARD:=ath25 BOARDNAME:=Atheros AR231x/AR5312 FEATURES:=squashfs low_mem small_flash -MAINTAINER:=Sergey Ryazanov KERNEL_PATCHVER:=4.14 diff --git a/target/linux/bcm27xx/Makefile b/target/linux/bcm27xx/Makefile index 507690357af4..7cc2aab7009b 100644 --- a/target/linux/bcm27xx/Makefile +++ b/target/linux/bcm27xx/Makefile @@ -11,7 +11,6 @@ ARCH:=arm BOARD:=bcm27xx BOARDNAME:=Broadcom BCM27xx FEATURES:=ext4 audio usb usbgadget display gpio fpu squashfs rootfs-part boot-part -MAINTAINER:=Álvaro Fernández Rojas SUBTARGETS:=bcm2708 bcm2709 bcm2710 bcm2711 KERNEL_PATCHVER:=4.19 diff --git a/target/linux/bcm47xx/Makefile b/target/linux/bcm47xx/Makefile index 32c1e7d211b0..c5b5e69edad3 100644 --- a/target/linux/bcm47xx/Makefile +++ b/target/linux/bcm47xx/Makefile @@ -11,7 +11,6 @@ BOARD:=bcm47xx BOARDNAME:=Broadcom BCM47xx/53xx (MIPS) FEATURES:=squashfs usb SUBTARGETS:=generic mips74k legacy -MAINTAINER:=Hauke
Re: [OpenWrt-Devel] [PATCH] Revert "kernel: rewrite run_parsers_by_type() to use add_mtd_partitions()"
Hi Petr, Rafał,
On 02.03.2020 13:58, Petr Štetiar wrote:
This reverts commit 15a0701cdde8eeae2a54880b813cdb8cdc09a384.
Seems like this patch has introduced some regressions on the ramips
target which is still on 4.14 kernel as this commit touches only 4.14
kernel patches.
jffs2: Erase at 0x00378000 failed immediately: errno -22
jffs2: Node CRC != calculated CRC f09e7845 for node at 00c08510
Ref: FS#2837, FS#2862
Fixes also very serious (erase of ART) FS#2864.
Ref: https://bugs.openwrt.org/index.php?do=details&task_id=2864
--
Cheers,
Piotr
Ref:
https://forum.openwrt.org/t/jffs2-partition-not-save-new-package-installation-or-save-settings
Cc: Rafał Miłecki
Signed-off-by: Petr Štetiar
---
...for-different-partition-parser-types.patch | 33 ---
...arsers-for-rootfs-and-firmware-split.patch | 4 +--
.../404-mtd-add-more-helper-functions.patch | 2 +-
3 files changed, 24 insertions(+), 15 deletions(-)
diff --git
a/target/linux/generic/pending-4.14/401-mtd-add-support-for-different-partition-parser-types.patch
b/target/linux/generic/pending-4.14/401-mtd-add-support-for-different-partition-parser-types.patch
index ae13112ef6d0..057d47368443 100644
---
a/target/linux/generic/pending-4.14/401-mtd-add-support-for-different-partition-parser-types.patch
+++
b/target/linux/generic/pending-4.14/401-mtd-add-support-for-different-partition-parser-types.patch
@@ -20,35 +20,44 @@ Signed-off-by: Gabor Juhos
/*
* Given a pointer to the MTD object in the mtd_part structure, we can
retrieve
-@@ -762,6 +766,27 @@ int mtd_del_partition(struct mtd_info *m
+@@ -762,6 +766,36 @@ int mtd_del_partition(struct mtd_info *m
}
EXPORT_SYMBOL_GPL(mtd_del_partition);
+static int
+run_parsers_by_type(struct mtd_part *slave, enum mtd_parser_type type)
+{
-+ struct mtd_partitions pparts = { };
-+ int err;
++ struct mtd_partition *parts;
++ int nr_parts;
++ int i;
+
-+ pparts.nr_parts = parse_mtd_partitions_by_type(&slave->mtd, type,
-+ &pparts.parts, NULL);
-+ if (pparts.nr_parts <= 0)
-+ return pparts.nr_parts;
++ nr_parts = parse_mtd_partitions_by_type(&slave->mtd, type, (const struct
mtd_partition **)&parts,
++ NULL);
++ if (nr_parts <= 0)
++ return nr_parts;
+
-+ if (WARN_ON(!pparts.parts))
++ if (WARN_ON(!parts))
+ return 0;
+
-+ err = add_mtd_partitions(&slave->mtd, pparts.parts, pparts.nr_parts);
++ for (i = 0; i < nr_parts; i++) {
++ /* adjust partition offsets */
++ parts[i].offset += slave->offset;
+
-+ kfree(pparts.parts);
++ mtd_add_partition(slave->parent,
++parts[i].name,
++parts[i].offset,
++parts[i].size);
++ }
++
++ kfree(parts);
+
-+ return err ? err : pparts.nr_parts;
++ return nr_parts;
+}
+
#ifdef CONFIG_MTD_SPLIT_FIRMWARE_NAME
#define SPLIT_FIRMWARE_NAME CONFIG_MTD_SPLIT_FIRMWARE_NAME
#else
-@@ -1147,6 +1172,61 @@ void mtd_part_parser_cleanup(struct mtd_
+@@ -1147,6 +1181,61 @@ void mtd_part_parser_cleanup(struct mtd_
}
}
diff --git a/target/linux/generic/pending-4.14/402-mtd-use-typed-mtd-parsers-for-rootfs-and-firmware-split.patch b/target/linux/generic/pending-4.14/402-mtd-use-typed-mtd-parsers-for-rootfs-and-firmware-split.patch
index 149c328ac4d5..2cc06dd463b3 100644
---
a/target/linux/generic/pending-4.14/402-mtd-use-typed-mtd-parsers-for-rootfs-and-firmware-split.patch
+++
b/target/linux/generic/pending-4.14/402-mtd-use-typed-mtd-parsers-for-rootfs-and-firmware-split.patch
@@ -10,7 +10,7 @@ Signed-off-by: Gabor Juhos
--- a/drivers/mtd/mtdpart.c
+++ b/drivers/mtd/mtdpart.c
-@@ -795,6 +795,7 @@ run_parsers_by_type(struct mtd_part *sla
+@@ -804,6 +804,7 @@ run_parsers_by_type(struct mtd_part *sla
static void split_firmware(struct mtd_info *master, struct mtd_part *part)
{
@@ -18,7 +18,7 @@ Signed-off-by: Gabor Juhos
}
static void mtd_partition_split(struct mtd_info *master, struct mtd_part *part)
-@@ -804,6 +805,12 @@ static void mtd_partition_split(struct m
+@@ -813,6 +814,12 @@ static void mtd_partition_split(struct m
if (rootfs_found)
return;
diff --git a/target/linux/generic/pending-4.14/404-mtd-add-more-helper-functions.patch b/target/linux/generic/pending-4.14/404-mtd-add-more-helper-functions.patch
index d1a32872af21..7b481ffb47a5 100644
--- a/target/linux/generic/pending-4.14/404-mtd-add-more-helper-functions.patch
+++ b/target/linux/generic/pending-4.14/404-mtd-add-more-helper-functions.patch
@@ -11,7 +11,7 @@ Signed-off-by: Gabor Juhos
--- a/drivers/mtd/mtdpart.c
+++ b/drivers/mtd/mtdpart.c
-@@ -1251,6 +1251,24 @@ int mtd_is_partition(const struct mtd_in
+@
Re: [OpenWrt-Devel] gpio-export,output and GPIO_ACTIVE_*
Hi Adrian,
On 23.02.2020 20:51, m...@adrianschmutzler.de wrote:
Hi,
when defining gpio-export nodes, I'm never really sure about how the
values for "gpio-export,output" and GPIO_ACTIVE_HIGH/LOW in gpios
have to be set up correctly in relation to each other.
I also was not able to retrieve a particular system in how this is
set up currently (for different devices).
It would be nice if somebody could elaborate this to me (I've found
several shorter explanations in the PR comments throughout GitHub,
but they unfortunately were never comprehensive.)
(And I assume the same logic will apply to gpio-hogs with
output-low/high and gpios parameter?)
I think it's more about semantics, relationship between value in
user-space (0, 1) and actual value output by hardware (some voltage vs.
no voltage, for this discussion purposed, forget about open drain, etc.)
and (inverted) binary logic.
Assume we have a GPIO line which controls some kind of reset line (for
example, PCIe PERSTn signal, used by WiFi cards, GSM/GPS modules, etc.):
- if GPIO is set to 0 (0 V), the card is in reset state
- if GPIO is set to 1 (3.3 V), the card is in operational state
Sounds simple until you start considering user-space name for it. If we
use 'pcie-reset' then 'GPIO_ACTIVE_LOW' should be used (if line is set
to '1' in user-space it will means '0 V' in hardware, putting the card
in reset state -> so logic is inverted here).
On the other hand, we can also name the line as 'pcie-enable', which
with '1' in user-space gives also '1' in hardware (3.3 V) - in this case
the line should use 'GPIO_ACTIVE_HIGH'.
I don't think there is a general accepted approach here, at least for
the naming. Maybe only in case of GPIO lines which controls some power
we usually try to match user-space value with actual voltage/power ('1'
in system should mean controlled power/voltage is enabled). But this
also means that the contributor has to check what GPIO value gives the
'active' state in hardware.
Regarding the upstream 'output-{high,low}' property - it's used to set
line as output with initial, default value (low/high).
In our case, the 'gpio-export,output = ' property is used for that
and sets selected line as output (with default value '1' or '0'). If
this property is missing, then the line will be used as input, see [0].
Hope this helps.
[0]
https://github.com/openwrt/openwrt/blob/master/target/linux/ath79/patches-4.19/0036-GPIO-add-named-gpio-exports.patch#L65
--
Cheers,
Piotr
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 2/2] rssileds: restrict package to targets where it is used
Hi Adrian, On 20.02.2020 19:00, Adrian Schmutzler wrote: -Original Message- From: Piotr Dymacz [mailto:pep...@gmail.com] Sent: Donnerstag, 20. Februar 2020 18:58 To: Adrian Schmutzler ; openwrt- de...@lists.openwrt.org Subject: Re: [OpenWrt-Devel] [PATCH 2/2] rssileds: restrict package to targets where it is used Hi Adrian, On 20.02.2020 18:52, Adrian Schmutzler wrote: > It does not seem very sensible to provide the rssileds package > on targets without corresponding LEDs, so restrict it to the > targets where it is used at the moment. This package isn't hardware related and shouldn't be limited to targets where only officially supported devices make use of it. Thus, NAK from me for this one. I assume that's only for 2/2? Yes, only this one (patch). -- Cheers, Piotr -- Cheers, Piotr > > Signed-off-by: Adrian Schmutzler > --- > package/network/utils/rssileds/Makefile | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/package/network/utils/rssileds/Makefile b/package/network/utils/rssileds/Makefile > index 7a59314693..c8e8f39de9 100644 > --- a/package/network/utils/rssileds/Makefile > +++ b/package/network/utils/rssileds/Makefile > @@ -18,7 +18,7 @@ define Package/rssileds > SECTION:=net > CATEGORY:=Network > TITLE:=RSSI real-time LED indicator > - DEPENDS:=+libiwinfo +libnl-tiny +libubox +libuci > + DEPENDS:=@(TARGET_ar71xx||TARGET_ath79||TARGET_ramips) +libiwinfo +libnl-tiny +libubox +libuci > MAINTAINER:=Daniel Golle > endef > > ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 2/2] rssileds: restrict package to targets where it is used
Hi Adrian, On 20.02.2020 18:52, Adrian Schmutzler wrote: It does not seem very sensible to provide the rssileds package on targets without corresponding LEDs, so restrict it to the targets where it is used at the moment. This package isn't hardware related and shouldn't be limited to targets where only officially supported devices make use of it. Thus, NAK from me for this one. -- Cheers, Piotr Signed-off-by: Adrian Schmutzler --- package/network/utils/rssileds/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/package/network/utils/rssileds/Makefile b/package/network/utils/rssileds/Makefile index 7a59314693..c8e8f39de9 100644 --- a/package/network/utils/rssileds/Makefile +++ b/package/network/utils/rssileds/Makefile @@ -18,7 +18,7 @@ define Package/rssileds SECTION:=net CATEGORY:=Network TITLE:=RSSI real-time LED indicator - DEPENDS:=+libiwinfo +libnl-tiny +libubox +libuci + DEPENDS:=@(TARGET_ar71xx||TARGET_ath79||TARGET_ramips) +libiwinfo +libnl-tiny +libubox +libuci MAINTAINER:=Daniel Golle endef ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] SPI 104 MHz on ar7240/Spansion S25FL032P
Hi Adrian, On 10.02.2020 12:25, Adrian Schmutzler wrote: Hi, while reviewing the PR for the TL-WA830REv1 [1], I was wondered about the unusually high spi-max-frequency = <10400>; The author states it's running stable, the datasheet tells Normal READ (Serial): 40-MHz clock rate FAST_READ (Serial): 104-MHz clock rate (maximum) DUAL I/O FAST_READ: 80-MHz clock rate or 20 MB/s effective data rate QUAD I/O FAST_READ: 80 MHz clock rate or 40 MB/s effective data rate and according to the author, there are other boards with the same chip and this frequency, e.g. https://github.com/openwrt/openwrt/blob/master/target/linux/ath79/dts/ar9331_tpl ink_tl-mr3020-v1.dts#L123 So, can somebody lend me some expertise whether the value is okay? The 'spi-max-frequency' property applies to the SPI slave node and the device it represents, thus if this flash IC can run with 104 MHz clock, then (according to the standard) it's correct (see also note: [0]). But, a totally different story is: - max. frequency of SPI clock for this platform - real max. frequency on this particular PCB (it's serial, so length of traces, crosstalk and many other factors have to be considered) Based only on formula from datasheet(s) [1], on ath79 WiSOCs SPI clock could go (in theory) up to ~100 MHz (with AHB bus clocked at 200 MHz). I suppose if the spi_clk is set to the maximum possible value, it gets limited anyway by some 'internals' (hardware capabilities). For example, if you check 'SPI Timing' section in QCA9563 datasheet, you will see that min. SPI clock period is 40 ns which gives 25 MHz clock. On the other hand, in AR9331 min. period is 20 ns, so 50 MHz clock (based on my experience, running it with 35+ MHz always caused problems with data integrity on various boards). Even more information on this subject gives QCA9531 v2 datasheet (minimum TDS for QCA9531 v2 is 11 ns): "Actual SPI operating frequency is dependent on the CLK-to-SO flash delay and the CLK/MISO signals propagation delay in the board. The minimum SPI_CLK period is 2 * (TDS + (CK-to-SO flash delay) + (board propagation delay of CLK + board propagation delay of MISO signals)." So, setting 104 MHz in DTS on that particular platform means the SPI flash will operate on max. hardware possible clock (which of course would never reach 104 MHz). Is this safe for that board? I don't know and I don't know how fast SPI clock can actually run on AR7240. [0] 104 MHz applies for all single SPI mode instructions excluding 'normal READ' (opcode 0x3) thus in this case, this value can be set only together with 'm25p,fast-read' property. Otherwise, according to SPI flash IC datasheet, it should be set to 40 MHz. [1] spi_clk = ahb_clk/((clk_div + 1) * 2), where clk_div >= 0 and <= 63. -- Cheers, Piotr Best Adrian Schmutzler [1] https://github.com/openwrt/openwrt/pull/2752#discussion_r375829096 ___ 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: [OpenWrt-Devel] [PATCH] ath79: add new ar934x spi driver
Hi Chuanhong, On 06.02.2020 17:01, Chuanhong Guo wrote: Hi! On Thu, Feb 6, 2020 at 11:29 PM Piotr Dymacz wrote: Don't you think that ~24h for review this kind of patch wasn't enough? I've sent the patch upstream and got positive review there.[0] two minor comments there are already addressed in my final commit. That was quick, great! And I've done flash reading and sysupgrade tests on ar933x/ar934x/qca955x including cs1 test on ar9344. I remember having problems with all 3 CS in use on AR933x but can't find now what exactly it was (IIRC, could be related with too small TSHSL_CNT on higher clocks). But as CS1 and CS2 are muxed there with UART and it's (almost) dead hardware I doubt we would ever see device with such configuration. But I agree that I'm too impatient this time. Sorry. No problem, maybe I'm just too slow ;) I remember some initial work on that done by you in GH PR but... not every dev looks around there. -- Cheers, Piotr Regards, Chuanhong Guo [0] https://patchwork.kernel.org/patch/11367973/ ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] ath79: add new ar934x spi driver
Hi Chuanhong,
On 05.02.2020 15:44, Chuanhong Guo wrote:
A new shift mode was introduced since ar934x which has a way better
performance than current bitbang driver and can handle higher spi
clock properly. This commit adds a new driver to make use of this
new feature.
This new driver has chipselect properly configured and we don't need
cs-gpios hack in dts anymore. Remove them.
Don't you think that ~24h for review this kind of patch wasn't enough?
--
Cheers,
Piotr
Signed-off-by: Chuanhong Guo
---
The new shift mode in ar934x doesn't need all the bit-bang code in
the old ath79-spi driver at all and there isn't much code that
can be shared between two modes, so I decided to write a new
driver for it.
With this new driver, theoretical maximum spi clock could reach
AHB_CLOCK / 2 and maximum clock suitable for SPI NOR is AHB_CLOCK / 4
(50MHz on QCA953x). Flash reading speed can only reach 4.33MB/s
though, probably due to register polling time between each 4 bytes
transfer.
I'll try upstreaming this driver later when I figured out those
documentation stuff.
I'm aware that ar9331 appears to have the same feature but it's not
mentioned in datasheet. I'd like to do some stability test later
and add ar933x support in a separated commit.
target/linux/ath79/config-4.19| 1 +
target/linux/ath79/dts/ar9344_qihoo_c301.dts | 1 -
target/linux/ath79/dts/ar934x.dtsi| 2 +-
.../ath79/dts/qca9531_glinet_gl-ar300m.dtsi | 1 -
target/linux/ath79/dts/qca953x.dtsi | 4 +-
target/linux/ath79/dts/qca9557.dtsi | 4 +-
.../ath79/dts/qca9563_glinet_gl-ar750s.dtsi | 1 -
.../linux/ath79/dts/qca9563_netgear_wndr.dtsi | 1 -
target/linux/ath79/dts/qca956x.dtsi | 4 +-
...ovide-devm_platform_ioremap_resource.patch | 61
...add-driver-for-ar934x-spi-controller.patch | 275 ++
11 files changed, 344 insertions(+), 11 deletions(-)
create mode 100644
target/linux/ath79/patches-4.19/0050-v5.1-drivers-provide-devm_platform_ioremap_resource.patch
create mode 100644
target/linux/ath79/patches-4.19/0051-spi-add-driver-for-ar934x-spi-controller.patch
diff --git a/target/linux/ath79/config-4.19 b/target/linux/ath79/config-4.19
index be5e46ac76..d92da1fbe2 100644
--- a/target/linux/ath79/config-4.19
+++ b/target/linux/ath79/config-4.19
@@ -211,6 +211,7 @@ CONFIG_SERIAL_AR933X_CONSOLE=y
CONFIG_SERIAL_AR933X_NR_UARTS=2
CONFIG_SERIAL_OF_PLATFORM=y
CONFIG_SPI=y
+CONFIG_SPI_AR934X=y
CONFIG_SPI_ATH79=y
CONFIG_SPI_BITBANG=y
CONFIG_SPI_GPIO=y
diff --git a/target/linux/ath79/dts/ar9344_qihoo_c301.dts
b/target/linux/ath79/dts/ar9344_qihoo_c301.dts
index 746c7f588e..46d1f4c4c8 100644
--- a/target/linux/ath79/dts/ar9344_qihoo_c301.dts
+++ b/target/linux/ath79/dts/ar9344_qihoo_c301.dts
@@ -110,7 +110,6 @@
status = "okay";
num-cs = <2>;
- cs-gpios= <0>, <0>;
flash@0 {
#address-cells = <1>;
diff --git a/target/linux/ath79/dts/ar934x.dtsi
b/target/linux/ath79/dts/ar934x.dtsi
index 8cd0b4e086..a5e97c1a51 100644
--- a/target/linux/ath79/dts/ar934x.dtsi
+++ b/target/linux/ath79/dts/ar934x.dtsi
@@ -183,7 +183,7 @@
};
spi: spi@1f00 {
- compatible = "qca,ar9340-spi", "qca,ar7100-spi";
+ compatible = "qca,ar934x-spi";
reg = <0x1f00 0x1c>;
clocks = <&pll ATH79_CLK_AHB>;
diff --git a/target/linux/ath79/dts/qca9531_glinet_gl-ar300m.dtsi
b/target/linux/ath79/dts/qca9531_glinet_gl-ar300m.dtsi
index f06305c47f..d769225fd4 100644
--- a/target/linux/ath79/dts/qca9531_glinet_gl-ar300m.dtsi
+++ b/target/linux/ath79/dts/qca9531_glinet_gl-ar300m.dtsi
@@ -76,7 +76,6 @@
status = "okay";
num-cs = <2>;
- cs-gpios = <0>, <0>;
flash@0 {
compatible = "jedec,spi-nor";
diff --git a/target/linux/ath79/dts/qca953x.dtsi
b/target/linux/ath79/dts/qca953x.dtsi
index 73a6ad91e5..1db0ef4e5c 100644
--- a/target/linux/ath79/dts/qca953x.dtsi
+++ b/target/linux/ath79/dts/qca953x.dtsi
@@ -201,8 +201,8 @@
};
spi: spi@1f00 {
- compatible = "qca,ar9530-spi", "qca,ar7100-spi";
- reg = <0x1f00 0x10>;
+ compatible = "qca,ar934x-spi";
+ reg = <0x1f00 0x1c>;
clocks = <&pll ATH79_CLK_AHB>;
clock-names = "ahb";
diff --git a/target/linux/ath79/dts/qca9557.dtsi
b/target/linux/ath79/dts/qca9557.dtsi
index d5d3f02544..fbd12e89cb 100644
--- a/target/linux/ath79/dts/qca9557.dtsi
+++ b/target/linux/ath79/dts/qca9557.dtsi
@@ -292,8 +292,8 @@
};
spi: spi@1f00 {
- compatible = "qca,ar9557-spi", "qca,ar7100-spi";
- reg = <0x1f00 0x10>;
+ compatible = "qca,ar934x-spi";
+ reg = <0x1f00 0x1c>;
clocks = <&
Re: [OpenWrt-Devel] [PATCH] base-files: diag: restore default trigger for 'boot' LED
Hi Adrian,
On 04.02.2020 13:32, Adrian Schmutzler wrote:
Hi,
-Original Message-
From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org] On
Behalf Of Piotr Dymacz
Sent: Freitag, 31. Januar 2020 15:23
To: openwrt-devel@lists.openwrt.org
Subject: [OpenWrt-Devel] [PATCH] base-files: diag: restore default trigger for
'boot' LED
For devices without a dedicated 'diag' LED, we use sometimes one of
other LEDs for indicating at least 'boot', 'failsafe' and 'upgrade'
stages. In some cases, at the same time these LEDs have defined default
triggers in DTS using 'linux,default-trigger' property. Current 'diag'
setup removes the trigger and turns off 'boot' LED after bootup.
One of the examples of such device is TP-Link TL-WR841N v14 (ramips)
which uses 'wlan' LED with defined 'linux,default-trigger' for 'diag':
aliases {
led-boot = &led_wlan;
led-failsafe = &led_wlan;
led-upgrade = &led_wlan;
};
[...]
led_wlan: wlan {
label = "tl-wr841n-v14:green:wlan";
gpios = <&gpio1 9 GPIO_ACTIVE_LOW>;
linux,default-trigger = "phy0tpt";
};
This patch extends 'diag.sh' and 'leds.sh' scripts to make sure default
trigger defined in DTS is restored for 'diag' LED which isn't used for
indicating 'running' stage.
I'm not really a fan of using LEDs for diag in that case at all, and I'd
actually prefer to have the aliases removed there (unless vendor also used
multiple purpose LEDs the same way).
Without any LED defined at least for 'boot' and 'failsafe', users might
have problems entering failsafe and knowing whether device boots at all.
--
Cheers,
Piotr
But since we have these case in our code right now, I think this workaround is
necessary ATM.
Acked-by: Adrian Schmutzler
Best
Adrian
Signed-off-by: Piotr Dymacz
---
package/base-files/Makefile | 2 +-
package/base-files/files/etc/diag.sh | 2 ++
.../base-files/files/lib/functions/leds.sh| 27 ---
3 files changed, 26 insertions(+), 5 deletions(-)
diff --git a/package/base-files/Makefile b/package/base-files/Makefile
index e389148d47..18325564dc 100644
--- a/package/base-files/Makefile
+++ b/package/base-files/Makefile
@@ -12,7 +12,7 @@ include $(INCLUDE_DIR)/version.mk
include $(INCLUDE_DIR)/feeds.mk
PKG_NAME:=base-files
-PKG_RELEASE:=213
+PKG_RELEASE:=214
PKG_FLAGS:=nonshared
PKG_FILE_DEPENDS:=$(PLATFORM_DIR)/ $(GENERIC_PLATFORM_DIR)/base-
files/
diff --git a/package/base-files/files/etc/diag.sh b/package/base-
files/files/etc/diag.sh
index 8eb36c6feb..37a8ec758e 100644
--- a/package/base-files/files/etc/diag.sh
+++ b/package/base-files/files/etc/diag.sh
@@ -37,6 +37,8 @@ set_led_state() {
;;
done)
status_led_off
+ [ "$status_led" != "$running" ] && \
+ status_led_restore_trigger "boot"
[ -n "$running" ] && {
status_led="$running"
status_led_on
diff --git a/package/base-files/files/lib/functions/leds.sh b/package/base-
files/files/lib/functions/leds.sh
index 8a1d21caef..43b2fe02ed 100644
--- a/package/base-files/files/lib/functions/leds.sh
+++ b/package/base-files/files/lib/functions/leds.sh
@@ -1,16 +1,24 @@
#!/bin/sh
# Copyright (C) 2013 OpenWrt.org
-get_dt_led() {
- local label
+get_dt_led_path() {
local ledpath
local basepath="/proc/device-tree"
local nodepath="$basepath/aliases/led-$1"
[ -f "$nodepath" ] && ledpath=$(cat "$nodepath")
+ [ -n "$ledpath" ] && ledpath="$basepath$ledpath"
+
+ echo "$ledpath"
+}
+
+get_dt_led() {
+ local label
+ local ledpath=$(get_dt_led_path $1)
+
[ -n "$ledpath" ] && \
- label=$(cat "$basepath$ledpath/label" 2>/dev/null) || \
- label=$(cat "$basepath$ledpath/chan-name" 2>/dev/null)
+ label=$(cat "$ledpath/label" 2>/dev/null) || \
+ label=$(cat "$ledpath/chan-name" 2>/dev/null)
echo "$label"
}
@@ -35,6 +43,17 @@ led_off() {
led_set_attr $1 "brightness" 0
}
+status_led_restore_trigger() {
+ local trigger
+ local ledpath=$(get_dt_led_path $1)
+
+ [ -n "$ledpath" ] && \
+ trigger=$(cat "$ledpath/linux,default-trigger" 2>/dev/null)
+
+ [ -n "$trigger" ] && \
+ led_set_attr "$(get_dt_led $1)" "trigger" "$trigger"
+}
+
status_led_set_timer() {
led_timer $status_led "$1" "$2"
[ -n "$status_led2" ] && led_timer $status_led2 "$1" "$2"
--
2.20.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 3/3] ath79: add support for Teltonika RUT955
Hi Daniel, Adrian,
See my comments inline.
On 02.02.2020 17:41, Daniel Golle wrote:
The Teltonika RUT955 is an industrial 2G/3G/4G WiFi router with
various additional inputs and outputs.
Specification:
- 550/400/200 MHz (CPU/DDR/AHB)
- 128 MB of RAM (DDR2)
- 16 MB of FLASH (SPI NOR)
- 4x 10/100 Mbps Ethernet, with passive PoE support on LAN1
- 2T2R 2,4 GHz (AR9344)
Have you tested RF sensitivity? I remember external GPIO-driven LNA in
RUT900 has to be defined, otherwise the radio was almost deaf.
- built-in 3G module (example: Qutectel EC-25EU)
Typo: s/Qutectel/Quectel
I think the only 3G-based one in whole series is RUT900.
EC25E is a 4G one.
- RS232 on D-Sub9 port (Cypress ACM via USB, /dev/ttyACM0)
- RS422/RS485 (AR934x high speed UART, /dev/ttyATH1)
- analog 0-9V input (MCP3221)
- various digital inputs and outputs incl. a relay
- 2x miniSIM slot (can be swapped via GPIO)
- 2x RP-SMA/F (Wi-Fi), 2x SMA/F (3G), 1x GPS
- 2x 74HC595 shift registers providing 16 GPOs
- 12x LED (4 are driven by AR9344, 7 by 74HC595)
- 1x button (reset)
- DC jack for main power input (9-30 V)
- debugging UART available on PCB edge connector
Serial console (/dev/ttyS0) pinout:
- RX: pin1 (square) on top side of the main PCB (AR9344 is on top)
- TX: pin1 (square) on bottom side
Flash instruction:
Vendor firmware is based on OpenWrt CC release. Use the "factory" image
directly in GUI (make sure to uncheck "keep settings") or in U-Boot web
based recovery. To avoid any problems, make sure to first update vendor
firmware to latest version - "factory" image was successfully tested on
device running "RUT9XX_R_00.06.051" firmware and U-Boot "3.0.2".
Signed-off-by: Daniel Golle
---
target/linux/ath79/dts/ar9344_tlt_rut955.dts | 301 ++
.../generic/base-files/etc/board.d/02_network | 5 +
target/linux/ath79/image/generic.mk | 37 +++
3 files changed, 343 insertions(+)
create mode 100644 target/linux/ath79/dts/ar9344_tlt_rut955.dts
diff --git a/target/linux/ath79/dts/ar9344_tlt_rut955.dts
b/target/linux/ath79/dts/ar9344_tlt_rut955.dts
new file mode 100644
index 00..06d18f8d26
--- /dev/null
+++ b/target/linux/ath79/dts/ar9344_tlt_rut955.dts
@@ -0,0 +1,301 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+/dts-v1/;
+
+#include
+#include
+
+#include "ar9344.dtsi"
+
+/ {
+ model = "Teltonika RUT955";
+ compatible = "tlt,rut955", "qca,ar9344";
I know that Teltonika uses this prefix in their software but maybe as
Adrian suggested, full name would fit better here? I'm fine with both.
At least, until it's in [0], we can use whatever fits.
+
+ aliases {
+ serial0 = &uart;
+ serial1 = &hs_uart;
+ led-boot = &led_system_green;
+ led-failsafe = &led_system_red;
+ led-running = &led_system_green;
+ led-upgrade = &led_system_red;
+ label-mac-device = ð1;
+ };
+
+ i2c {
+ compatible = "i2c-gpio";
+ scl-gpios = <&gpio 16 (GPIO_ACTIVE_HIGH|GPIO_OPEN_DRAIN)>;
+ sda-gpios = <&gpio 17 (GPIO_ACTIVE_HIGH|GPIO_OPEN_DRAIN)>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ hwmon@4d {
+ compatible = "microchip,mcp3221";
+ reg = <0x4d>;
+ };
+ };
+
+ gpio_ext_spi {
+ compatible = "spi-gpio";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pmx_led_spi_gpio>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ sck-gpios = <&gpio 4 GPIO_ACTIVE_HIGH>; // 74HC595 SRCLK
(Serial Clock)
+ mosi-gpios = <&gpio 12 GPIO_ACTIVE_HIGH>; // 74HC595 SER
(Serial)
+ cs-gpios = <&gpio 20 GPIO_ACTIVE_HIGH>; // 74HC595 RCLK
(Register Clock)
+ num-chipselects = <1>;
+
+ gpio_ext: gpio_ext@0 {
+ compatible = "fairchild,74hc595";
+ reg = <0>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ registers-number = <2>;
+ spi-max-frequency = <1000>;
+ gpio-line-names = "signal_bar0", "signal_bar1", "signal_bar2",
"signal_bar3",
+ "signal_bar4", "status_red", "status_green",
"sim_sel",
+ "", "relay", "modem_vbus", "modem_rst",
+ "", "", "", "";
I don't think we use this property anywhere else in ath79 (or even other
DTS-based targets?) so far and AFAIK it doesn't have any usage before we
start using new char dev for GPIOs (libgpiod).
Anyway, wouldn't it be more readable to at least add "led" to names of
lines driving LEDs?
Also, maybe it would make sense to provide access to SIM select and
relay lines in user-space (with gpio-export in DTS o
Re: [OpenWrt-Devel] [PATCH 1/3] ath79: enable i2c-gpio and spi-gpio in generic subtarget
Hi Daniel, On 02.02.2020 17:40, Daniel Golle wrote: For devices having LEDs or buttons connected via I2C or SPI connected GPIO chips it is desireable to access these busses early during boot in order to signal progress and failsafe-mode. Hence have support for i2c-gpio and spi-gpio built-into the kernel on generic (ie. non-tiny) systems. For I2C two other configs should be also auto-selected: +CONFIG_I2C=y +CONFIG_I2C_ALGOBIT=y +CONFIG_I2C_BOARDINFO=y +CONFIG_I2C_GPIO=y And in case of CONFIG_SPI_GPIO, it's already selected in top-level target config: https://github.com/openwrt/openwrt/blob/master/target/linux/ath79/config-4.19#L216 https://github.com/openwrt/openwrt/blob/master/target/linux/ath79/config-4.14#L223 'make kernel_menuconfig CONFIG_TARGET=subtarget' will solve that. Signed-off-by: Daniel Golle Acked-by: Piotr Dymacz -- Cheers, Piotr --- target/linux/ath79/generic/config-default | 3 +++ 1 file changed, 3 insertions(+) diff --git a/target/linux/ath79/generic/config-default b/target/linux/ath79/generic/config-default index 2d8f7f20c2..8c3ed13fb5 100644 --- a/target/linux/ath79/generic/config-default +++ b/target/linux/ath79/generic/config-default @@ -1,6 +1,8 @@ CONFIG_AT803X_PHY=y CONFIG_GPIO_WATCHDOG=y CONFIG_GPIO_WATCHDOG_ARCH_INITCALL=y +CONFIG_I2C=y +CONFIG_I2C_GPIO=y CONFIG_INTEL_XWAY_PHY=y CONFIG_IP17XX_PHY=y CONFIG_LEDS_RESET=y @@ -18,5 +20,6 @@ CONFIG_RTL8366RB_PHY=y CONFIG_RTL8366S_PHY=y CONFIG_RTL8366_SMI=y CONFIG_RTL8367_PHY=y +CONFIG_SPI_GPIO=y CONFIG_VITESSE_PHY=y CONFIG_WATCHDOG_CORE=y ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] ath79: introduces KERNEL_LZMA variable for common build sequence
Hi Adrian, On 02.02.2020 18:20, m...@adrianschmutzler.de wrote: Hi Piotr, -Original Message- From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org] On Behalf Of Piotr Dymacz Sent: Sonntag, 2. Februar 2020 18:02 To: Adrian Schmutzler ; openwrt- de...@lists.openwrt.org Subject: Re: [OpenWrt-Devel] [PATCH] ath79: introduces KERNEL_LZMA variable for common build sequence Hi Adrian, On 02.02.2020 13:48, Adrian Schmutzler wrote: > This introduce a variable KERNEL_LZMA to replace the frequently used > sequence "kernel-bin | append-dtb | lzma", similar to the KERNEL_DTB > variable in ramips target. So in results we will have: ramips: KERNEL_DTB = kernel-bin | append-dtb | lzma ath79: KERNEL_LZMA := kernel-bin | append-dtb | lzma Is there any reason to use different var name in ath79? In ath79 we have some cases where gzip is used instead of lzma, e.g. https://github.com/openwrt/openwrt/blob/master/target/linux/ath79/image/common-tp-link.mk#L42 Plus some where no compression is used. Thus, if we use KERNEL_DTB for the case with lzma, it would be misleading, as the name only tells us about the DTB. One code base, two variables with same values using different names? That looks wrong to me. So, we could either just use " KERNEL_DTB := kernel-bin | append-dtb ", which is too short to be helpful IMO, or use a more indicative name for the VARIABLE, which I thought I found. Actually, I would consider it more correct to change the name for ramips, too. 'KERNEL_DTB := kernel-bin | append-dtb' would cover almost everything, including KERNEL_INITRAMFS, but I agree that wouldn't help much. We could also use KERNEL_DTB_LZMA of course, but I do not think this will really bring a benefit. "There are only two hard things in Computer Science: cache invalidation and naming things." :) I care more about consistency in naming variables carrying same values than the name itself. -- Cheers, Piotr Best Adrian Also, see: https://chris.beams.io/posts/git-commit/#imperative -- Cheers, Piotr > Signed-off-by: Adrian Schmutzler > --- > target/linux/ath79/image/Makefile | 5 +++-- > target/linux/ath79/image/common-mikrotik.mk | 4 ++-- > target/linux/ath79/image/common-tp-link.mk | 14 ++ > target/linux/ath79/image/generic-tp-link.mk | 5 ++--- > target/linux/ath79/image/generic-ubnt.mk| 2 +- > target/linux/ath79/image/generic.mk | 10 +- > 6 files changed, 19 insertions(+), 21 deletions(-) > > diff --git a/target/linux/ath79/image/Makefile > b/target/linux/ath79/image/Makefile > index a28658ec0b..71ffa4b429 100644 > --- a/target/linux/ath79/image/Makefile > +++ b/target/linux/ath79/image/Makefile > @@ -52,6 +52,7 @@ define Build/relocate-kernel >rm -rf $@.relocate > endef > > +KERNEL_LZMA := kernel-bin | append-dtb | lzma > > define Device/Default > DEVICE_DTS_DIR := ../dts > @@ -59,8 +60,8 @@ define Device/Default > PROFILES = Default > MTDPARTS := > BLOCKSIZE := 64k > - KERNEL := kernel-bin | append-dtb | lzma | uImage lzma > - KERNEL_INITRAMFS := kernel-bin | append-dtb | lzma | uImage lzma > + KERNEL := $(KERNEL_LZMA) | uImage lzma KERNEL_INITRAMFS := > + $(KERNEL_LZMA) | uImage lzma > COMPILE := > SUPPORTED_DEVICES := $(subst _,$(comma),$(1)) > IMAGES := sysupgrade.bin > diff --git a/target/linux/ath79/image/common-mikrotik.mk > b/target/linux/ath79/image/common-mikrotik.mk > index 292237c76a..6531619fe9 100644 > --- a/target/linux/ath79/image/common-mikrotik.mk > +++ b/target/linux/ath79/image/common-mikrotik.mk > @@ -2,6 +2,6 @@ define Device/mikrotik >DEVICE_VENDOR := MikroTik >DEVICE_PACKAGES := rbextract rbcfg >LOADER_TYPE := elf > - KERNEL := kernel-bin | append-dtb | lzma | loader-kernel > - KERNEL_INITRAMFS := kernel-bin | append-dtb | lzma | loader- kernel > + KERNEL := $(KERNEL_LZMA) | loader-kernel > + KERNEL_INITRAMFS := $(KERNEL_LZMA) | loader-kernel > endef > diff --git a/target/linux/ath79/image/common-tp-link.mk > b/target/linux/ath79/image/common-tp-link.mk > index a9fccd0fe6..abce4095c4 100644 > --- a/target/linux/ath79/image/common-tp-link.mk > +++ b/target/linux/ath79/image/common-tp-link.mk > @@ -14,8 +14,8 @@ define Device/tplink-v1 > TPLINK_HWREV := 0x1 > TPLINK_HEADER_VERSION := 1 > LOADER_TYPE := gz > - KERNEL := kernel-bin | append-dtb | lzma > - KERNEL_INITRAMFS := kernel-bin | append-dtb | lzma | > tplink-v1-header > + KERNEL := $(KERNEL_LZMA) > + KERNEL_INITRAMFS := $(KERNEL_LZMA) | tplink-v1-header > IMAGES += factory.bin > IMAGE/sysupgrade.bin := tplink-v1-image sysupgrade | append- metadata > IMAGE/factory.bin := tplink-v1-image factory @@ -26,
Re: [OpenWrt-Devel] [PATCH] ath79: introduces KERNEL_LZMA variable for common build sequence
Hi Adrian, On 02.02.2020 13:48, Adrian Schmutzler wrote: This introduce a variable KERNEL_LZMA to replace the frequently used sequence "kernel-bin | append-dtb | lzma", similar to the KERNEL_DTB variable in ramips target. So in results we will have: ramips: KERNEL_DTB = kernel-bin | append-dtb | lzma ath79: KERNEL_LZMA := kernel-bin | append-dtb | lzma Is there any reason to use different var name in ath79? Also, see: https://chris.beams.io/posts/git-commit/#imperative -- Cheers, Piotr Signed-off-by: Adrian Schmutzler --- target/linux/ath79/image/Makefile | 5 +++-- target/linux/ath79/image/common-mikrotik.mk | 4 ++-- target/linux/ath79/image/common-tp-link.mk | 14 ++ target/linux/ath79/image/generic-tp-link.mk | 5 ++--- target/linux/ath79/image/generic-ubnt.mk| 2 +- target/linux/ath79/image/generic.mk | 10 +- 6 files changed, 19 insertions(+), 21 deletions(-) diff --git a/target/linux/ath79/image/Makefile b/target/linux/ath79/image/Makefile index a28658ec0b..71ffa4b429 100644 --- a/target/linux/ath79/image/Makefile +++ b/target/linux/ath79/image/Makefile @@ -52,6 +52,7 @@ define Build/relocate-kernel rm -rf $@.relocate endef +KERNEL_LZMA := kernel-bin | append-dtb | lzma define Device/Default DEVICE_DTS_DIR := ../dts @@ -59,8 +60,8 @@ define Device/Default PROFILES = Default MTDPARTS := BLOCKSIZE := 64k - KERNEL := kernel-bin | append-dtb | lzma | uImage lzma - KERNEL_INITRAMFS := kernel-bin | append-dtb | lzma | uImage lzma + KERNEL := $(KERNEL_LZMA) | uImage lzma + KERNEL_INITRAMFS := $(KERNEL_LZMA) | uImage lzma COMPILE := SUPPORTED_DEVICES := $(subst _,$(comma),$(1)) IMAGES := sysupgrade.bin diff --git a/target/linux/ath79/image/common-mikrotik.mk b/target/linux/ath79/image/common-mikrotik.mk index 292237c76a..6531619fe9 100644 --- a/target/linux/ath79/image/common-mikrotik.mk +++ b/target/linux/ath79/image/common-mikrotik.mk @@ -2,6 +2,6 @@ define Device/mikrotik DEVICE_VENDOR := MikroTik DEVICE_PACKAGES := rbextract rbcfg LOADER_TYPE := elf - KERNEL := kernel-bin | append-dtb | lzma | loader-kernel - KERNEL_INITRAMFS := kernel-bin | append-dtb | lzma | loader-kernel + KERNEL := $(KERNEL_LZMA) | loader-kernel + KERNEL_INITRAMFS := $(KERNEL_LZMA) | loader-kernel endef diff --git a/target/linux/ath79/image/common-tp-link.mk b/target/linux/ath79/image/common-tp-link.mk index a9fccd0fe6..abce4095c4 100644 --- a/target/linux/ath79/image/common-tp-link.mk +++ b/target/linux/ath79/image/common-tp-link.mk @@ -14,8 +14,8 @@ define Device/tplink-v1 TPLINK_HWREV := 0x1 TPLINK_HEADER_VERSION := 1 LOADER_TYPE := gz - KERNEL := kernel-bin | append-dtb | lzma - KERNEL_INITRAMFS := kernel-bin | append-dtb | lzma | tplink-v1-header + KERNEL := $(KERNEL_LZMA) + KERNEL_INITRAMFS := $(KERNEL_LZMA) | tplink-v1-header IMAGES += factory.bin IMAGE/sysupgrade.bin := tplink-v1-image sysupgrade | append-metadata IMAGE/factory.bin := tplink-v1-image factory @@ -26,8 +26,7 @@ define Device/tplink-nolzma LOADER_FLASH_OFFS := 0x22000 COMPILE := loader-$(1).gz COMPILE/loader-$(1).gz := loader-okli-compile - KERNEL := kernel-bin | append-dtb | lzma | uImage lzma -M 0x4f4b4c49 | \ - loader-okli $(1) 7680 + KERNEL := $(KERNEL_LZMA) | uImage lzma -M 0x4f4b4c49 | loader-okli $(1) 7680 KERNEL_INITRAMFS := kernel-bin | append-dtb | gzip | tplink-v1-header endef @@ -63,7 +62,7 @@ endef define Device/tplink-safeloader $(Device/tplink-v1) - KERNEL := kernel-bin | append-dtb | lzma | tplink-v1-header -O + KERNEL := $(KERNEL_LZMA) | tplink-v1-header -O IMAGE/sysupgrade.bin := append-rootfs | tplink-safeloader sysupgrade | \ append-metadata | check-size (IMAGE_SIZE) IMAGE/factory.bin := append-rootfs | tplink-safeloader factory @@ -71,7 +70,7 @@ endef define Device/tplink-safeloader-uimage $(Device/tplink-safeloader) - KERNEL := kernel-bin | append-dtb | lzma | uImageArcher lzma + KERNEL := $(KERNEL_LZMA) | uImageArcher lzma endef define Device/tplink-safeloader-okli @@ -80,6 +79,5 @@ define Device/tplink-safeloader-okli LOADER_FLASH_OFFS := 0x43000 COMPILE := loader-$(1).elf COMPILE/loader-$(1).elf := loader-okli-compile - KERNEL := kernel-bin | append-dtb | lzma | uImage lzma -M 0x4f4b4c49 | \ - loader-okli $(1) 12288 + KERNEL := $(KERNEL_LZMA) | uImage lzma -M 0x4f4b4c49 | loader-okli $(1) 12288 endef diff --git a/target/linux/ath79/image/generic-tp-link.mk b/target/linux/ath79/image/generic-tp-link.mk index f1a603dc6d..30e6f979c4 100644 --- a/target/linux/ath79/image/generic-tp-link.mk +++ b/target/linux/ath79/image/generic-tp-link.mk @@ -203,9 +203,8 @@ define Device/tplink_archer-d50-v1 TPLINK_FLASHLAYOUT := 8Mqca TPLINK_HWREVADD := 0x TPLINK_HVERSION := 3 - KERNEL := kernel-bin | append-dtb | lzma - KERNEL_INITR
[OpenWrt-Devel] [PATCH] base-files: diag: restore default trigger for 'boot' LED
For devices without a dedicated 'diag' LED, we use sometimes one of
other LEDs for indicating at least 'boot', 'failsafe' and 'upgrade'
stages. In some cases, at the same time these LEDs have defined default
triggers in DTS using 'linux,default-trigger' property. Current 'diag'
setup removes the trigger and turns off 'boot' LED after bootup.
One of the examples of such device is TP-Link TL-WR841N v14 (ramips)
which uses 'wlan' LED with defined 'linux,default-trigger' for 'diag':
aliases {
led-boot = &led_wlan;
led-failsafe = &led_wlan;
led-upgrade = &led_wlan;
};
[...]
led_wlan: wlan {
label = "tl-wr841n-v14:green:wlan";
gpios = <&gpio1 9 GPIO_ACTIVE_LOW>;
linux,default-trigger = "phy0tpt";
};
This patch extends 'diag.sh' and 'leds.sh' scripts to make sure default
trigger defined in DTS is restored for 'diag' LED which isn't used for
indicating 'running' stage.
Signed-off-by: Piotr Dymacz
---
package/base-files/Makefile | 2 +-
package/base-files/files/etc/diag.sh | 2 ++
.../base-files/files/lib/functions/leds.sh| 27 ---
3 files changed, 26 insertions(+), 5 deletions(-)
diff --git a/package/base-files/Makefile b/package/base-files/Makefile
index e389148d47..18325564dc 100644
--- a/package/base-files/Makefile
+++ b/package/base-files/Makefile
@@ -12,7 +12,7 @@ include $(INCLUDE_DIR)/version.mk
include $(INCLUDE_DIR)/feeds.mk
PKG_NAME:=base-files
-PKG_RELEASE:=213
+PKG_RELEASE:=214
PKG_FLAGS:=nonshared
PKG_FILE_DEPENDS:=$(PLATFORM_DIR)/ $(GENERIC_PLATFORM_DIR)/base-files/
diff --git a/package/base-files/files/etc/diag.sh
b/package/base-files/files/etc/diag.sh
index 8eb36c6feb..37a8ec758e 100644
--- a/package/base-files/files/etc/diag.sh
+++ b/package/base-files/files/etc/diag.sh
@@ -37,6 +37,8 @@ set_led_state() {
;;
done)
status_led_off
+ [ "$status_led" != "$running" ] && \
+ status_led_restore_trigger "boot"
[ -n "$running" ] && {
status_led="$running"
status_led_on
diff --git a/package/base-files/files/lib/functions/leds.sh
b/package/base-files/files/lib/functions/leds.sh
index 8a1d21caef..43b2fe02ed 100644
--- a/package/base-files/files/lib/functions/leds.sh
+++ b/package/base-files/files/lib/functions/leds.sh
@@ -1,16 +1,24 @@
#!/bin/sh
# Copyright (C) 2013 OpenWrt.org
-get_dt_led() {
- local label
+get_dt_led_path() {
local ledpath
local basepath="/proc/device-tree"
local nodepath="$basepath/aliases/led-$1"
[ -f "$nodepath" ] && ledpath=$(cat "$nodepath")
+ [ -n "$ledpath" ] && ledpath="$basepath$ledpath"
+
+ echo "$ledpath"
+}
+
+get_dt_led() {
+ local label
+ local ledpath=$(get_dt_led_path $1)
+
[ -n "$ledpath" ] && \
- label=$(cat "$basepath$ledpath/label" 2>/dev/null) || \
- label=$(cat "$basepath$ledpath/chan-name" 2>/dev/null)
+ label=$(cat "$ledpath/label" 2>/dev/null) || \
+ label=$(cat "$ledpath/chan-name" 2>/dev/null)
echo "$label"
}
@@ -35,6 +43,17 @@ led_off() {
led_set_attr $1 "brightness" 0
}
+status_led_restore_trigger() {
+ local trigger
+ local ledpath=$(get_dt_led_path $1)
+
+ [ -n "$ledpath" ] && \
+ trigger=$(cat "$ledpath/linux,default-trigger" 2>/dev/null)
+
+ [ -n "$trigger" ] && \
+ led_set_attr "$(get_dt_led $1)" "trigger" "$trigger"
+}
+
status_led_set_timer() {
led_timer $status_led "$1" "$2"
[ -n "$status_led2" ] && led_timer $status_led2 "$1" "$2"
--
2.20.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Netgear R6260 EEPROM location
Hi David, On 30.01.2020 12:36, David Bauer wrote: Hello again, [...] So I'm waiting on feedback from other owners of these boards and using this (more or less) strange fix in the meantime. Robert complained in the meantime, that my fix broke his R6260. He also sent me the partition map of the stock firmware and it differs from mine (see below). [...] I'm still waiting for him to send ma a photo of the routers backside, but it seems we have to dynamically detect the partition map of the devices. I'll look into the SC_PART_MAP partition and the routers GPL code to find a possible solution for this problem. There was some work with custom 'SC_PART_MAP' mtd parser back in 2018 but mapping used in vendor firmware didn't match what was in flash, see: [0] and also [1] about 'different' R6220 models. Added also Mathias and Chuanhong to the loop. [0] https://github.com/openwrt/openwrt/pull/1318#issuecomment-419628452 [1] https://github.com/openwrt/openwrt/pull/1304 -- Cheers, Piotr In the meantime, I'll revert my "fix" to not break existing boards. For the record: I assume this bug has nothing to do with the partition shifting seen on the R6220, as the offending "feature" of the mtknand driver was disabled in the meantime (and the partition map differs in the stock firmware). [0] [0] https://github.com/openwrt/openwrt/pull/1304 Best wishes David ___ 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: [OpenWrt-Devel] Migration in ath79 for swapped ethernet
Hi Adrian,
On 28.01.2020 16:59, Adrian Schmutzler wrote:
Hi,
There is easy way to check GMACx <> ethX assignment order in mach-*.c
files. Just check order of ath79_register_eth() calls:
ath79_register_eth(0);
ath79_register_eth(1);
Will register GMAC0 as eth0, GMAC1 as eth1
ath79_register_eth(1);
ath79_register_eth(0);
Will register GMAC1 as eth0, GMAC0 as eth1 (current ath79 "order")
I thought that once as well, but then found several cases where I couldn't rely
on it for eth0/eth1 order on running device. (But it's too long ago for me to be
more specific.)
There are two things here:
1. Mapping of physical ports to kernel interface naming.
2. Mapping of kernel interfaces to 'our' LAN/WAN system interfaces.
AFAIK, there wasn't any official or general rule about what should be
LAN and WAN (in terms of mapping ethX to 'our' LAN/WAN), so it was
always up to the device support author (personally I preferred to have
LAN on eth0). And as you can see above, ar71xx allowed two different
orders in which ethX interfaces where registered in kernel.
Despite, from what I understand our current problem is the driver implementation
in ath79, which needs to skip/delay initialization in certain cases.
So, it's not so much about finding out the situation on ar71xx, but
understanding the situation in ath79 as well. All-in-all, I think this will come
down to having to check each device manually.
More or less, yes.
>> I have a feeling that the idea with migration script got abandoned
>> (Adrian?), so I was wondering if there is any other way we could
>> preserve ar71xx LAN/WAN <> ethX assignment in ath79?
>
> See above, yes, I effectively abandoned that.
Got it, so alternative solution is required.
>> For example, I have a QCA9531 based device with PHY4 (connected directly
>> to GMAC0) labeled as LAN (and registered as eth0 in kernel) and PHY3
>> (connected to GMAC1 over internal switch) labeled as WAN. On ath79, due
>> to change introduced in 8dde11d521, LAN and WAN order gets swapped (as
>> expected) but partially reverting above change (adding back "simple-mfd"
>> to eth1 in device's DTS, see below) brings back the "old" order of
>> interfaces.
>>
>> ð1 {
>>compatible = "qca,ar9330-eth", "syscon", "simple-mfd";
>>mtd-mac-address = <&art 0x6>;
>> };
>>
>> But it doesn't seem as a proper fix to me (maybe I'm wrong?) thus the
>> question about any other, better approach?
>
> That's how I feel. For me, this always looked like a hack to me (based on my
shallow level of understanding, though).
> There might be special cases where this is necessary (e.g. force a device to
be
eth0 due to failsafe), but I still do not like it.
I was considering also aliases in DTSes.
One could use that for failsafe (actually quite an interesting idea) and for
specifying the corresponding ethX in ar71xx. However, this still won't help us
with the migration script itself.
Lets forget about migration scripts now and try to find a way to keep
old interfaces mapping in ar71xx the same in ath79, using DTS only.
As I wrote already, it's just semantics.
--
Cheers,
Piotr
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Migration in ath79 for swapped ethernet
Hi Adrian, On 28.01.2020 16:48, Adrian Schmutzler wrote: Hi Piotr, -Original Message- From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org] On Behalf Of Piotr Dymacz Sent: Montag, 27. Januar 2020 21:45 To: Adrian Schmutzler Cc: openwrt-devel@lists.openwrt.org; gch981...@gmail.com; ansuels...@gmail.com; 'David Bauer' Subject: Re: [OpenWrt-Devel] Migration in ath79 for swapped ethernet Hi Adrian, On 27.01.2020 19:35, Adrian Schmutzler wrote: > Just a quick one: > >> > So, no matter what we do, there is no easy way forward. >> >> We could remove all ar71xx -> ath79 migration helper scripts, ar71xx >> board names from supported devices lists in ath79 images and make the >> target a brand new, without any concerns about soon-to-be obsolete ar71xx ;) > > At the moment, I'm actually mostly inclined towards this solution. I'm afraid it's a bit late for that as 19.07 is already out and it supports (at least partially) ar71xx -> ath79 migration path/s. Wouldn't that look unprofessional? Am I overreacting here? One didn't have to use -F during sysupgrade, but the release notes gave the clear advice to upgrade without keeping settings. So, IMO we actually didn't "support" any migration in 19.07.0. Fair point. > However, for me personally SUPPORTED_DEVICES was always more a "don't brick entirely" flag, so I never expected it to ensure 100 % config compatibility. More like preventing me from flashing ubnt,unifi image onto tplink,wdr-4300-v1. This impression might have been wrong, though. I think device to image matching was the main reason behind the idea. IIRC, mismatched image doesn't prevent you against upgrading with preserved settings. > But as mentioned by Ansuel, there are other incompatible switches to come (and some are already waiting), and unless we want to create new targets or rename devices in these cases, we have to think about different "levels" of compatibility anyway beyond ar71xx->ath79. I believe ar71xx -> ath79 is a special case here. First of all, that's a new DTS-enabled target and it was suppose to _replace_ ar71xx but 19.07 went out with both of them and I'm pretty sure there are users who got confused with that (some devices are supported only in one of the targets, some in both, some with seamless migration possible). On the other hand, when ar71xx gets abandoned, we (as a project) should make it clear if ath79 is a replacement (thus providing seamless upgrade from ar71xx) or a new target, without any relationship with ar71xx (thus a clean sysupgrade is required). Keeping anything in between would just confuse people. I do not really see a viable/desirable option to support eth migration at the moment. And I'm not really a fan of adding lots of migration stuff which spoils the new ath79 target already, so after all I think I also do not _want_ to add eth migration either. I wouldn't want to introduce _now_ any extra 'migration' scripts, code, etc. All I really want is to keep mapping of physical interface to kernel interface name consistent with previous releases as this is the most important thing when you perform upgrade on e.g. remote-only accessible devices (or those on mast connected with single eth cable). And it's not only about 19.07 and 18.06. There are devices in ar71xx which got supported before the LEDE 17.01 release and I'm working on keeping them alive within ath79 target. So, I'd prefer to see the ath79 new and clean. However, from the wording perspective, I do not think that a "replacement" means seamless upgrade. I'd thus keep the SUPPORTED_DEVICES just as a device-matching measure, but wouldn't implement any sophisticated migration despite that. Having SUPPORTED_DEVICES might actually be valuable for certain third parties, like I'm involved in a downstream project that regenerates the system/network config at each upgrade, but still exploits SUPPORTED_DEVICES for having the correct image. If you prefer 'new and clean' ath79 then _IMHO_ ar71xx board names must be removed from SUPPORTED_DEVICES lists together with migration scripts in ath79. If downstream projects want to keep that 'mess', it would be up to them. It should be clear that the ath79 target isn't associated with ar71xx. IMHO, anything in between would be only an unmaintainable mess (just see your recent fixes regarding SUPPORTED_DEVICES in ath79: [0], [1]). And I could well live with keeping the already present migration scripts, as having them as "undocumented feature" won't hurt. If we do not advertise it, it won't confuse people ... This smells for me like something easy to forget which would then get removed ~few years later during so
Re: [OpenWrt-Devel] Migration in ath79 for swapped ethernet
Hi Peter, On 27.01.2020 22:05, Peter Geis wrote: On Mon, Jan 27, 2020 at 4:00 PM Piotr Dymacz wrote: [...] But it's not a general rule and, at least in case of generic/basic settings, user shouldn't be worried about upgrading between major versions with preserving settings. Otherwise, the whole idea doesn't make much sense and we should just prevent settings backup during major versions switch. Excellent point! Here's an odd possibility, just to throw at the wall. What about building a special transition image, specifically for moving from ar71xx to ath79. If you want to retain the ability to return to ar71xx have an image to go the opposite way. Simply, no. Please don't make it way more complicated that it truly is. Or a metadata package to do the conversion post flash. My goal is to solve the problem without re-inventing the wheel. I prefer to solve the problem with what we already have. Because the option (which seems pretty drastic, unless the size could be minimized) of having a near permanent conversion script built into the firmware seems rather costly. Conversion scripts would be my last solution. I prefer to deal with the problem without too much overhead. -- Cheers, Piotr ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Migration in ath79 for swapped ethernet
Hi Peter, On 27.01.2020 19:57, Peter Geis wrote: On Mon, Jan 27, 2020 at 1:35 PM Adrian Schmutzler wrote: Just a quick one: > > So, no matter what we do, there is no easy way forward. > > We could remove all ar71xx -> ath79 migration helper scripts, ar71xx > board names from supported devices lists in ath79 images and make the > target a brand new, without any concerns about soon-to-be obsolete ar71xx ;) At the moment, I'm actually mostly inclined towards this solution. However, for me personally SUPPORTED_DEVICES was always more a "don't brick entirely" flag, so I never expected it to ensure 100 % config compatibility. More like preventing me from flashing ubnt,unifi image onto tplink,wdr-4300-v1. This impression might have been wrong, though. But as mentioned by Ansuel, there are other incompatible switches to come (and some are already waiting), and unless we want to create new targets or rename devices in these cases, we have to think about different "levels" of compatibility anyway beyond ar71xx->ath79. Wouldn't it be reasonable to put up a warning that migrating from ar71xx->ath79 will require a reset of networking configuration? Then all you need to do is detect when that sort of upgrade is occurring and nuke the requisite files. I believe we already have such a 'warning' on the Wiki: [0]. The exact problem is 'detecting that sort of upgrade' (what about user migrating device under 19.07 but between ar71xx -> ath79 and then back to ar71xx?). Also, the problem doesn't affect all the devices so the users have to first check whether the device they migrate/upgrade has to be (sys)upgraded without preserved settings or not. Also I don't know bout y'all, but I usually take a major revision upgrade as an opportunity to hard reset and rebuild anyways. (Years of ingrained ddwrt habits) But it's not a general rule and, at least in case of generic/basic settings, user shouldn't be worried about upgrading between major versions with preserving settings. Otherwise, the whole idea doesn't make much sense and we should just prevent settings backup during major versions switch. [0] https://openwrt.org/docs/guide-user/installation/ar71xx.to.ath79#upgrade_from_ar71xx_to_ath79 -- Cheers, Piotr ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Migration in ath79 for swapped ethernet
Hi Adrian, On 27.01.2020 19:35, Adrian Schmutzler wrote: Just a quick one: > So, no matter what we do, there is no easy way forward. We could remove all ar71xx -> ath79 migration helper scripts, ar71xx board names from supported devices lists in ath79 images and make the target a brand new, without any concerns about soon-to-be obsolete ar71xx ;) At the moment, I'm actually mostly inclined towards this solution. I'm afraid it's a bit late for that as 19.07 is already out and it supports (at least partially) ar71xx -> ath79 migration path/s. Wouldn't that look unprofessional? Am I overreacting here? However, for me personally SUPPORTED_DEVICES was always more a "don't brick entirely" flag, so I never expected it to ensure 100 % config compatibility. More like preventing me from flashing ubnt,unifi image onto tplink,wdr-4300-v1. This impression might have been wrong, though. I think device to image matching was the main reason behind the idea. IIRC, mismatched image doesn't prevent you against upgrading with preserved settings. But as mentioned by Ansuel, there are other incompatible switches to come (and some are already waiting), and unless we want to create new targets or rename devices in these cases, we have to think about different "levels" of compatibility anyway beyond ar71xx->ath79. I believe ar71xx -> ath79 is a special case here. First of all, that's a new DTS-enabled target and it was suppose to _replace_ ar71xx but 19.07 went out with both of them and I'm pretty sure there are users who got confused with that (some devices are supported only in one of the targets, some in both, some with seamless migration possible). On the other hand, when ar71xx gets abandoned, we (as a project) should make it clear if ath79 is a replacement (thus providing seamless upgrade from ar71xx) or a new target, without any relationship with ar71xx (thus a clean sysupgrade is required). Keeping anything in between would just confuse people. DSA is slightly different topic as it will touch many different targets (also ath79, think about qca8k) so probably a project-wide solution would be required. -- Cheers, Piotr ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Migration in ath79 for swapped ethernet
Hi Adrian,
On 21.01.2020 15:10, Adrian Schmutzler wrote:
[...]
I'm in the middle of migrating some devices from soon-to-be-obsolete
ar71xx to ath79 target and was wondering about status of the eth0/eth1
vs. LAN/WAN assignment issue.
To start with the end: I've decided to stop working on this.
The two major problems are obvious:
1. How to make sure we find every possible location of eth0/eth1 in user code
This is a problem which can be solved, and if it does not cover every single
special case I could live with it.
2. How to find out whether we are updating from ar71xx or not.
This is a hard one: We cannot rely on the ethernet setup itself, as the user might have changed it
for whatever reason. We could rely on some other parameters as suggested (wmac path etc.), but that
would not be generally applicable and still would impose some boundary conditions (e.g. start
before the wmac migration, as then config would be "old" and paths on the device would
already be "new", making identification of the update possible).
An alternative way would be to exploit /etc/board.json for that, given that it
is not updated during sysupgrade (I'm not sure what's happening here). If it is
not updated, it would give us access to the configuration when the user
installed the device, and without the changes the user would have made to
/etc/config/network. One could then parse and compare /etc/board.json to some
(device-specific) reference (e.g. wan=eth0) and base the decision to apply
migration on that. Afterwards, a new /etc/board.json is generated, so the
condition is not met anymore. Despite for the device-specific condition, this
would also be a generally applicable concept.
IMHO, that would never look like a clean and nice solution and we would
need to carry it in code for who knows how long (imagine some ar71xx
board will get migrated after 20.x release).
All in all, this second problem (when to migrate) is the bigger problem. We
also have a similar case in https://github.com/openwrt/openwrt/pull/2649
So far for the technical aspects. From the organizational point of view, for a
long time I thought I'm the only one caring about this topic. Since there was
not much interest in bringing this to 19.07 before the release, I do not see
much use of adding it afterwards now.
As the 19.07 was released with ar71xx I didn't consider that important
at the time. Now it's time to consider it as a problem and prepare
solution _before_ the next release which won't include ar71xx.
In any case, the migration script will be a complicated task and will certainly introduce cornercases as
well. All in all, I do not think it's worth it, and we should keep to advise people to flash with
"-n" that single time when upgrading from ar71xx to ath79. For the pros that will change their
Ethernet setup by hand later without using "-n", I'd still provide the "easy" migrations
like e.g. LED names.
At the very beginning, ath79 was considered as a brand new target
without _any_ concerns about migration path from ar71xx. But then,
things got complicated (broken).
Either we support seamless ar71xx -> ath79 migration for _all_ devices
supported in both targets or we just... don't. There shouldn't be cases
where user has to check or ask whether owned device can be upgraded with
preserving settings.
And I really don't consider LED naming migration as important as network
interfaces naming swap (LED naming convention in upstream got changed
anyway so we are expecting another change/migration at some point in
future). Also, LEDs names isn't the only problem, in some cases type of
trigger has to be changed (e.g. netdev vs. switch).
I'm aware of the 8dde11d521 ("ath79: dts: drop "simple-mfd" for gmacs in
SoC dtsi") [0] and following changes but that "fixed" the problem only
for devices which were following already reversed (I wouldn't call it
wrong or incorrect, I also prefer to have LAN on eth0 interface) SOC's
GMACx <> ethx assignment/register under ar71xx target - e.g. LAN on eth0
which is in fact SOC's GMAC1 and WAN on eth1 which is SOC's GMAC0. Good
explanation of that inverted assignment can be found in Jeff's patch
here: [1].
Well, effectively a lot of devices match ar71xx order again, but also several
do not match anymore after that.
For the underlying logic, I think Chuanhong will be the best person to discuss
with.
Chuanhong, could you join the discussion?
I've tried to start a list of devices where eth0/eth1 are swapped compared to
ar71xx _now_ here:
https://openwrt.org/docs/guide-user/installation/ar71xx.to.ath79#devices_with_known_config_changes_without_migration_available
There is easy way to check GMACx <> ethX assignment order in mach-*.c
files. Just check order of ath79_register_eth() calls:
ath79_register_eth(0);
ath79_register_eth(1);
Will register GMAC0 as eth0, GMAC1 as eth1
ath79_register_eth(1);
ath79_register_eth(0);
Will register GMAC1 as eth0, GMAC0 as eth1 (cu
Re: [OpenWrt-Devel] [PATCH 19.07] ramips: mt7621: ubnt-erx: allow sysupgrade from master
Hi Petr,
On 20.01.2020 20:40, Petr Štetiar wrote:
Currently it's not possible to downgrade from master:
Device ubiquiti,edgerouterx not supported by this image
Supported devices: ubnt-erx
So fix it by adding a DTS based device name from master into
SUPPORTED_DEVICES list.
Signed-off-by: Petr Štetiar
---
target/linux/ramips/image/mt7621.mk | 2 ++
1 file changed, 2 insertions(+)
diff --git a/target/linux/ramips/image/mt7621.mk
b/target/linux/ramips/image/mt7621.mk
index 53a264f527a6..a874731a 100644
--- a/target/linux/ramips/image/mt7621.mk
+++ b/target/linux/ramips/image/mt7621.mk
@@ -483,6 +483,7 @@ define Device/ubnt-erx
KERNEL_INITRAMFS := $$(KERNEL) | ubnt-erx-factory-image
$(KDIR)/tmp/$$(KERNEL_INITRAMFS_PREFIX)-factory.tar
IMAGE/sysupgrade.bin := sysupgrade-tar | append-metadata
DEVICE_TITLE := Ubiquiti EdgeRouter X
+ SUPPORTED_DEVICES += ubiquiti_edgerouterx
Shouldn't that be: 'ubiquiti,edgerouterx' (',' vs. '_')?
--
Cheers,
Piotr
endef
TARGET_DEVICES += ubnt-erx
@@ -491,6 +492,7 @@ define Device/ubnt-erx-sfp
DTS := UBNT-ERX-SFP
DEVICE_TITLE := Ubiquiti EdgeRouter X-SFP
DEVICE_PACKAGES += kmod-i2c-algo-pca kmod-gpio-pca953x kmod-i2c-gpio-custom
+ SUPPORTED_DEVICES += ubiquiti_edgerouterx-sfp
endef
TARGET_DEVICES += ubnt-erx-sfp
___
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: [OpenWrt-Devel] Migration in ath79 for swapped ethernet
Hi Adrian, David, Chuanhong,
On 07.09.2019 12:15, m...@adrianschmutzler.de wrote:
Hi,
> However, this will obviously swap eth0/eth1 on EVERY upgrade, not just
when coming from ar71xx.
> So, does anyone have an idea how to limit this to run only when updated
from ar71xx?
I was thinking about the same. As we have no information about the
previously installed platform, i was thinking about abusing the wmac path we
already use to migrate the WiFi configuration.
However, i think this is not the most elegant way to solve this issue.
I have to think about that. I recently thought one could just check whether the
lan/wan assignment matches the one expected for ar71xx, but that would
obviously also catch cases were the user modified it to be like this.
> Despite, while having the abstraction of "rename_all_eth", I wonder
whether it would be possible and desirable to do all renames in one step:
> sed -i -e 's/eth0/ethX/' -e 's/eth1/eth0/' -e 's/ethX/eth1/' $file or
> even sed -i -e 's/eth0/eth1/' -e 's/eth0/eth1/' $file depending on
> how sed handles this internally. These options would mean less flash writes
(although this might not be too important here).
A rewrite with sed is not sufficient, as we will possible rewrite uci section
names, possibly referenced elsewhere. We have to loop thru all interface
values and lists, rewriting each occurrence.
Actually, I could well live with that. What kind of references are you
referring to?
If just someone really named a section with ethX, it will be renamed
consistently throught all uci files (unless they are stored in another
location).
Only in case someone uses a section name with ethX and refers to it e.g. in a
custom script, this will be a problem.
And this is where I think we do not have to account for every tiny possibility.
If someone upgrades to another architecture, I think it's fair to expect him to
check whether his custom scripts still work. We do not have to overdo it.
But that's just my point of view at the moment.
I'm in the middle of migrating some devices from soon-to-be-obsolete
ar71xx to ath79 target and was wondering about status of the eth0/eth1
vs. LAN/WAN assignment issue.
I'm aware of the 8dde11d521 ("ath79: dts: drop "simple-mfd" for gmacs in
SoC dtsi") [0] and following changes but that "fixed" the problem only
for devices which were following already reversed (I wouldn't call it
wrong or incorrect, I also prefer to have LAN on eth0 interface) SOC's
GMACx <> ethx assignment/register under ar71xx target - e.g. LAN on eth0
which is in fact SOC's GMAC1 and WAN on eth1 which is SOC's GMAC0. Good
explanation of that inverted assignment can be found in Jeff's patch
here: [1].
I have a feeling that the idea with migration script got abandoned
(Adrian?), so I was wondering if there is any other way we could
preserve ar71xx LAN/WAN <> ethX assignment in ath79?
For example, I have a QCA9531 based device with PHY4 (connected directly
to GMAC0) labeled as LAN (and registered as eth0 in kernel) and PHY3
(connected to GMAC1 over internal switch) labeled as WAN. On ath79, due
to change introduced in 8dde11d521, LAN and WAN order gets swapped (as
expected) but partially reverting above change (adding back "simple-mfd"
to eth1 in device's DTS, see below) brings back the "old" order of
interfaces.
ð1 {
compatible = "qca,ar9330-eth", "syscon", "simple-mfd";
mtd-mac-address = <&art 0x6>;
};
But it doesn't seem as a proper fix to me (maybe I'm wrong?) thus the
question about any other, better approach?
[0] https://github.com/openwrt/openwrt/commit/8dde11d521
[1]
https://www.mail-archive.com/openwrt-devel@lists.openwrt.org/msg48526.html
--
Cheers,
Piotr
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] hostapd: start hostapd/wpa_supplicant for all wiphy devices
c888e17e06 ("hostapd: manage instances via procd instead of pidfile")
added procd support for managing hostapd and wpa_supplicant daemons
but at the same time limited wiphy names to 'phy*'.
This brings back initial behaviour (introduced in 60fb4c92b6 ("hostapd:
add ubus reload") and makes procd manage daemons for any wiphy device
found in '/sys/class/ieee80211'.
CC: Felix Fietkau
CC: Daniel Golle
Signed-off-by: Piotr Dymacz
---
package/network/services/hostapd/Makefile | 2 +-
package/network/services/hostapd/files/hostapd.hotplug | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/package/network/services/hostapd/Makefile
b/package/network/services/hostapd/Makefile
index 2642a263dc..1b6434674a 100644
--- a/package/network/services/hostapd/Makefile
+++ b/package/network/services/hostapd/Makefile
@@ -7,7 +7,7 @@
include $(TOPDIR)/rules.mk
PKG_NAME:=hostapd
-PKG_RELEASE:=6
+PKG_RELEASE:=7
PKG_SOURCE_URL:=http://w1.fi/hostap.git
PKG_SOURCE_PROTO:=git
diff --git a/package/network/services/hostapd/files/hostapd.hotplug
b/package/network/services/hostapd/files/hostapd.hotplug
index c319d42c1a..2c936fde75 100644
--- a/package/network/services/hostapd/files/hostapd.hotplug
+++ b/package/network/services/hostapd/files/hostapd.hotplug
@@ -21,7 +21,7 @@ service_data() {
procd_open_service hostapd
-for phy in phy*; do
+for phy in *; do
[ -d "$phy" ] || continue
mkdir -p /var/run/wpa_supplicant-$phy /var/run/hostapd-$phy
--
2.20.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Kernel version for OpenWrt 20.X
Hi Adrian, Tom, On 05.01.2020 16:57, m...@adrianschmutzler.de wrote: -Original Message- From: Tom Psyborg [mailto:pozega.tomis...@gmail.com] Sent: Sonntag, 5. Januar 2020 16:33 To: m...@adrianschmutzler.de Cc: Hauke Mehrtens ; OpenWrt Development List ; Koen Vandeputte Subject: Re: [OpenWrt-Devel] Kernel version for OpenWrt 20.X On 05/01/2020, m...@adrianschmutzler.de wrote: > Hi, > >> -Original Message- >> From: openwrt-devel [mailto:openwrt-devel- boun...@lists.openwrt.org] >> On Behalf Of Hauke Mehrtens >> Sent: Samstag, 4. Januar 2020 18:26 >> To: m...@adrianschmutzler.de; 'OpenWrt Development List' > de...@lists.openwrt.org> >> Cc: 'Koen Vandeputte' >> Subject: Re: [OpenWrt-Devel] Kernel version for OpenWrt 20.X >> >> On 1/3/20 1:53 PM, m...@adrianschmutzler.de wrote: >> > Hi Hauke, >> > >> >> -Original Message- >> >> From: openwrt-devel [mailto:openwrt-devel- >> boun...@lists.openwrt.org] >> >> On Behalf Of Hauke Mehrtens >> >> Sent: Donnerstag, 28. November 2019 19:42 >> >> To: Adrian Schmutzler ; 'OpenWrt >> >> Development List' >> >> Cc: 'Koen Vandeputte' >> >> Subject: Re: [OpenWrt-Devel] Kernel version for OpenWrt 20.X >> >> >> >> On 11/28/19 7:11 PM, Adrian Schmutzler wrote: >> >>> Hi Hauke, >> >>> >> The following are still on kernel 4.9: >> * ar7 >> * ixp4xx >> * orion >> >>> >> >>> There are patches (actually from you, May 2019) on the list which >> >>> claim to bump ar7 and orion to 4.14: >> >>> >> >>> https://patchwork.ozlabs.org/project/openwrt/list/?series=107337 >> >>> https://patchwork.ozlabs.org/project/openwrt/list/?series=107339 >> >>> >> >>> I haven't looked closer, just in case you forgot about them ;-) >> >> >> >> Nobody reported that they are working so I never applied them. I >> >> do not have the hardware, I just made them compile. >> > >> > Since there was no response of any kind from a third party, I've >> > just >> marked the two patchsets as "Deferred" in the patchwork, so we get a >> little more overview there. I hope that's okay for you. >> >> Yes fine with me, we should probably drop these targets soon. >> >> Hauke > > I think it's time to remove the three targets and kernel 4.9 support > as well after the release has been made. Or does keeping kernel 4.9 in > master (even without targets) make it easier to support 18.06 branch? > > Best > > Adrian > This LTS version will receive updates for another 3 years, why do you want to remove it? Next release will be kernel 4.19 or 5.4 only, and the respective targets are still at 4.9. So, they haven't been included in 19.07 (4.14 only) and won't be included in future releases unless someone updates them. At the moment, it looks like nobody will update them. So, we plan to remove these targets now, as they are effectively unmaintained. Those who still want to use them can have the 4.9 version in 18.06 stable branch until that one is EOL. In both cases, updating or removing the targets, there will be no need to keep kernel support if no targets are left. Thus, we can save time for maintaining that kernel version. They can also be moved here: https://github.com/openwrt/targets -- Cheers, Piotr Best Adrian ___ 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: [OpenWrt-Devel] Preserving configs over sysupgrade on ath79/tiny broken for some boards (on 19.07 and master), possible solutions
Hi David, Jo, On 30.12.2019 14:22, David Bauer wrote: Hello, On 12/30/19 12:42 PM, Jo-Philipp Wich wrote: Hi, given that (binary release) support for 4MB devices will end with 19.07, I'd vote for reverting the 4K sector change in ath79 and stick with 64K ones as common denominator across the entire target. That will be the least invasive and most robust fix. +1 IMHO this change is way to crucial to have it introduced this short before the release is built. People who built images for their devices can introduce 4K sectors to their own images. This way, we do't risk breaking boards. +1 -- Cheers, Piotr Best wishes David Regards, Jo ___ 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
Re: [OpenWrt-Devel] Inquery
On 11.12.2019 15:22, Daniel Golle wrote: As a community, we decided to give our self a set of minimal rules[1]. And even though it is in the last position, rule #12 "Be nice to each other." is meant just as serious as all the other rules. So here, not for the first time, you are using language which has the only purpose to hurt other people (for which reason ever, it doesn't matter). This is therefore a very clear violation to the above mentioned rule. You statement "suck it" (guess what) is also an obvious and disgusting example of a masculist culture which hurts our community as a whole and I strongly believe we should not tolerate that. And yes this was a spam mail. And it's even needless to say that replying to a spam email in which ever way will always make it worse. But that's not the point here and I will not engage in any discussion on that matter. Please learn to behave or leave us alone. [1]: https://openwrt.org/rules +1 -- Cheers, Piotr ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Kernel version for OpenWrt 20.X
Hi Hauke, On 28.11.2019 19:41, Hauke Mehrtens wrote: On 11/28/19 7:11 PM, Adrian Schmutzler wrote: Hi Hauke, The following are still on kernel 4.9: * ar7 * ixp4xx * orion There are patches (actually from you, May 2019) on the list which claim to bump ar7 and orion to 4.14: https://patchwork.ozlabs.org/project/openwrt/list/?series=107337 https://patchwork.ozlabs.org/project/openwrt/list/?series=107339 I haven't looked closer, just in case you forgot about them ;-) Nobody reported that they are working so I never applied them. I do not have the hardware, I just made them compile. I would just remove these 3 targets soon. Wouldn't be better to move them to 'targets' feed? -- Cheers, Piotr ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] wifi/network is broken
Hi, On 25.11.2019 22:28, e9hack wrote: Hi, this commit: Commit: b7c58a1eeba5be2e1f77ec05b417be9d87e26916 [b7c58a1] kernel: nf_conntrack_rtcache: fix cleanup on netns delete and rmmod See FS#2624: https://bugs.openwrt.org/index.php?do=details&task_id=2624 -- Cheers, Piotr floods my log every a few seconds with this message: Mon Nov 25 20:57:28 2019 kern.warn kernel: [ 318.310769] ath10k_pci :00:00.0: SWBA overrun on vdev 0, skipped old beacon Mon Nov 25 20:57:28 2019 kern.warn kernel: [ 318.318202] ath10k_pci :00:00.0: SWBA overrun on vdev 1, skipped old beacon Mon Nov 25 20:57:28 2019 kern.warn kernel: [ 318.325678] ath10k_pci :00:00.0: SWBA overrun on vdev 2, skipped old beacon Mon Nov 25 20:57:30 2019 kern.warn kernel: [ 320.919241] [ cut here ] Mon Nov 25 20:57:30 2019 kern.warn kernel: [ 320.924032] WARNING: CPU: 0 PID: 0 at net/netfilter/nf_conntrack_rtcache.c:197 0x866ec314 Mon Nov 25 20:57:30 2019 kern.warn kernel: [ 320.932345] Modules linked in: ifb ath9k ath9k_common pppoe ppp_async ath9k_hw ath10k_pci ath10k_core ath pppox ppp_generic nf_nat_pptp nf_flow_table_ipv6 nf_flow_table_ipv4 nf_flow_table_inet nf_conntrack_pptp mac80211 lz4 iptable_nat ipt_REJECT ipt_MASQUERADE cfg80211 xt_time xt_tcpudp xt_tcpmss xt_string xt_statistic xt_state xt_recent xt_quota xt_pkttype xt_owner xt_nat xt_multiport xt_mark xt_mac xt_limit xt_length xt_iprange xt_hl xt_helper xt_ecn xt_dscp xt_conntrack xt_connmark xt_connlimit xt_connbytes xt_comment xt_bpf xt_addrtype xt_TCPMSS xt_REDIRECT xt_NFQUEUE xt_NFLOG xt_NETMAP xt_LOG xt_HL xt_FLOWOFFLOAD xt_DSCP xt_CT xt_CLASSIFY wireguard vhci_hcd usbip_host usbip_core ums_usbat ums_sddr55 ums_sddr09 ums_karma ums_jumpshot ums_isd200 ums_freecom ums_datafab ums_cypress ums_alauda Mon Nov 25 20:57:30 2019 kern.warn kernel: [ 321.003959] ts_fsm ts_bm slhc nft_reject_ipv6 nft_reject_ipv4 nft_reject_inet nft_reject nft_redir_ipv4 nft_redir nft_quota nft_numgen nft_nat nft_masq_ipv4 nft_masq nft_log nft_limit nft_flow_offload nft_ct nft_counter nft_chain_route_ipv6 nft_chain_route_ipv4 nft_chain_nat_ipv4 nfnetlink_queue nfnetlink_log nf_tables nf_reject_ipv4 nf_nat_tftp nf_nat_snmp_basic nf_nat_sip nf_nat_proto_gre nf_nat_irc nf_nat_ipv4 nf_nat_h323 nf_nat_ftp nf_nat_amanda nf_nat nf_log_ipv4 nf_flow_table_hw nf_flow_table nf_conntrack_tftp nf_conntrack_snmp nf_conntrack_sip nf_conntrack_rtcache nf_conntrack_proto_gre nf_conntrack_netlink nf_conntrack_irc nf_conntrack_h323 nf_conntrack_ftp nf_conntrack_broadcast ts_kmp nf_conntrack_amanda nf_conncount lz4_decompress lz4_compress iptable_raw iptable_mangle iptable_filter Mon Nov 25 20:57:30 2019 kern.warn kernel: [ 321.075610] ipt_ECN ip_tables crc_ccitt compat asn1_decoder act_connmark sch_tbf sch_ingress sch_htb sch_hfsc em_u32 cls_u32 cls_tcindex cls_route cls_matchall cls_fw cls_flow cls_basic act_skbedit act_mirred hid evdev input_core i2c_dev i2c_core ledtrig_usbport cryptodev xt_set ip_set_list_set ip_set_hash_netportnet ip_set_hash_netport ip_set_hash_netnet ip_set_hash_netiface ip_set_hash_net ip_set_hash_mac ip_set_hash_ipportnet ip_set_hash_ipportip ip_set_hash_ipport ip_set_hash_ipmark ip_set_hash_ip ip_set_bitmap_port ip_set_bitmap_ipmac ip_set_bitmap_ip ip_set nfnetlink ip6t_rt ip6t_mh ip6t_ipv6header ip6t_hbh ip6t_frag ip6t_eui64 ip6t_ah nf_log_ipv6 nf_log_common ip6table_mangle ip6table_filter ip6_tables ip6t_REJECT x_tables nf_reject_ipv6 msdos ip6_udp_tunnel udp_tunnel tun vfat fat nls_utf8 Mon Nov 25 20:57:30 2019 kern.warn kernel: [ 321.147453] nls_iso8859_1 nls_cp437 authenc uas usb_storage uhci_hcd ohci_platform ohci_hcd ehci_platform sd_mod scsi_mod ehci_hcd gpio_button_hotplug f2fs exfat usbcore nls_base usb_common aead crypto_null crc32_generic crc32c_generic cryptomgr lzo lzo_decompress lzo_compress crypto_acompress ext4 mbcache jbd2 crypto_hash crc16 zram zsmalloc [last unloaded: ifb] Mon Nov 25 20:57:30 2019 kern.warn kernel: [ 321.180234] CPU: 0 PID: 0 Comm: swapper Tainted: GW 4.19.85 #0 Mon Nov 25 20:57:30 2019 kern.warn kernel: [ 321.187563] Stack : 0001 0003 8058 800b5580 0001 214d75cf Mon Nov 25 20:57:30 2019 kern.warn kernel: [ 321.196062] 8055fbd8 87c0980c 8058 80587f24 80587b47 0001 87c097b0 214d75cf Mon Nov 25 20:57:30 2019 kern.warn kernel: [ 321.204553] 8071 806e7cd8 0008 Mon Nov 25 20:57:30 2019 kern.warn kernel: [ 321.213046] 03ca d037dda6 0002c00a 8058 866ec314 866ed018 Mon Nov 25 20:57:30 2019 kern.warn kernel: [ 321.221536] 00c5 0001 0003 0001 802a6c6c 806e Mon Nov 25 20:57:30 2019 kern.warn kernel: [ 321.230022] ... Mon Nov 25 20:57:30 2019 kern.warn kernel: [ 321.232514] Call Trace: Mon Nov 25 20:57:30 2019 kern.warn kernel: [ 321.235017] [<8006b284>] s
[OpenWrt-Devel] [PATCH] umbim: move package to 'WWAN' submenu
'uqmi' was moved to 'WWAN' submenu in 9abdeee0b7. Let's be consistent and do the same with 'umbim'. Signed-off-by: Piotr Dymacz --- package/network/utils/umbim/Makefile | 1 + 1 file changed, 1 insertion(+) diff --git a/package/network/utils/umbim/Makefile b/package/network/utils/umbim/Makefile index 417363f4da..cc34002f6e 100644 --- a/package/network/utils/umbim/Makefile +++ b/package/network/utils/umbim/Makefile @@ -23,6 +23,7 @@ include $(INCLUDE_DIR)/cmake.mk define Package/umbim SECTION:=net CATEGORY:=Network + SUBMENU:=WWAN DEPENDS:=+libubox +kmod-usb-net +kmod-usb-net-cdc-mbim +wwan TITLE:=Control utility for mobile broadband modems endef -- 2.20.1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 19.07] ramips: use upstream RAW_APPENDED_DTB instead of our OWRTDTB
From: Chuanhong Guo
Upstream kernel added support for RAW_APPENDED_DTB on ralink arch
in the following commit:
02564fc89d3d ("ralink: Introduce fw_passed_dtb to arch/mips/ralink")
Use upstream solution and get rid of our OWRTDTB hack.
This commit set DEVICE_DTS to $$(DTS) instead of replacing DTS with
DEVICE_DTS in device profile because DTS variable will be dropped
in later commits.
Signed-off-by: Chuanhong Guo
[Tested on mt7621/mt76x8]
Tested-by: Chuanhong Guo
[Tested on rt305x/mt7620]
Tested-by: INAGAKI Hiroshi
(cherry picked from commit 7a8d3432c739c6ff038295176e8b6324e92fc116)
Signed-off-by: Piotr Dymacz
---
target/linux/ramips/image/Makefile| 11 +---
target/linux/ramips/image/mt7621.mk | 2 +-
target/linux/ramips/image/rt3883.mk | 2 +-
target/linux/ramips/mt7620/config-4.14| 4 +-
target/linux/ramips/mt7621/config-4.14| 4 +-
target/linux/ramips/mt76x8/config-4.14| 4 +-
.../ramips/patches-4.14/0100-prom_fixes.patch | 66 ---
target/linux/ramips/rt305x/config-4.14| 4 +-
target/linux/ramips/rt3883/config-4.14| 4 +-
9 files changed, 15 insertions(+), 86 deletions(-)
delete mode 100644 target/linux/ramips/patches-4.14/0100-prom_fixes.patch
diff --git a/target/linux/ramips/image/Makefile
b/target/linux/ramips/image/Makefile
index 0a32859bec..07251aebba 100644
--- a/target/linux/ramips/image/Makefile
+++ b/target/linux/ramips/image/Makefile
@@ -19,12 +19,12 @@ loadaddr-$(CONFIG_TARGET_ramips_mt7621) := 0x80001000
KERNEL_LOADADDR := $(loadaddr-y)
-KERNEL_DTB = kernel-bin | patch-dtb | lzma
+KERNEL_DTB = kernel-bin | append-dtb | lzma
define Device/Default
- PROFILES = Default $$(DTS)
- KERNEL_DEPENDS = $$(wildcard ../dts/$$(DTS).dts)
+ PROFILES = Default
KERNEL := $(KERNEL_DTB) | uImage lzma
DEVICE_DTS_DIR := ../dts
+ DEVICE_DTS = $$(DTS)
IMAGES := sysupgrade.bin
IMAGE_SIZE := $(ralink_default_fw_size_8M)
SUPPORTED_DEVICES := $(subst _,$(comma),$(1))
@@ -52,11 +52,6 @@ define Build/jcg-header
mv $@.new $@
endef
-define Build/patch-dtb
- $(call Image/BuildDTB,../dts/$(DTS).dts,$@.dtb)
- $(STAGING_DIR_HOST)/bin/patch-dtb $@ $@.dtb
-endef
-
define Build/trx
$(STAGING_DIR_HOST)/bin/trx $(1) \
-o $@ \
diff --git a/target/linux/ramips/image/mt7621.mk
b/target/linux/ramips/image/mt7621.mk
index f13e9c8a4f..fa222f7a89 100644
--- a/target/linux/ramips/image/mt7621.mk
+++ b/target/linux/ramips/image/mt7621.mk
@@ -106,7 +106,7 @@ define Device/dir-860l-b1
DTS := DIR-860L-B1
BLOCKSIZE := 64k
SEAMA_SIGNATURE := wrgac13_dlink.2013gui_dir860lb
- KERNEL := kernel-bin | patch-dtb | relocate-kernel | lzma | uImage lzma
+ KERNEL := kernel-bin | append-dtb | relocate-kernel | lzma | uImage lzma
IMAGE_SIZE := $(ralink_default_fw_size_16M)
DEVICE_TITLE := D-Link DIR-860L B1
DEVICE_PACKAGES := kmod-mt76x2 kmod-usb3 kmod-usb-ledtrig-usbport wpad-basic
diff --git a/target/linux/ramips/image/rt3883.mk
b/target/linux/ramips/image/rt3883.mk
index 4844abd1b7..b783994357 100644
--- a/target/linux/ramips/image/rt3883.mk
+++ b/target/linux/ramips/image/rt3883.mk
@@ -48,7 +48,7 @@ define Device/belkin_f9k1109v1
DEVICE_TITLE := Belkin F9K1109 Version 1.0
DEVICE_PACKAGES := kmod-usb-core kmod-usb-ohci kmod-usb2 swconfig
IMAGE_SIZE := 7224k
- KERNEL := kernel-bin | patch-dtb | lzma -d16 | uImage lzma
+ KERNEL := kernel-bin | append-dtb | lzma -d16 | uImage lzma
# Stock firmware checks for this uImage image name during upload.
UIMAGE_NAME := N750F9K1103VB
endef
diff --git a/target/linux/ramips/mt7620/config-4.14
b/target/linux/ramips/mt7620/config-4.14
index 05f3963d43..92a7a2fd38 100644
--- a/target/linux/ramips/mt7620/config-4.14
+++ b/target/linux/ramips/mt7620/config-4.14
@@ -146,8 +146,8 @@ CONFIG_MIPS_CMDLINE_FROM_DTB=y
# CONFIG_MIPS_HUGE_TLB_SUPPORT is not set
CONFIG_MIPS_L1_CACHE_SHIFT=5
# CONFIG_MIPS_MACHINE is not set
-CONFIG_MIPS_NO_APPENDED_DTB=y
-# CONFIG_MIPS_RAW_APPENDED_DTB is not set
+# CONFIG_MIPS_NO_APPENDED_DTB is not set
+CONFIG_MIPS_RAW_APPENDED_DTB=y
CONFIG_MIPS_SPRAM=y
CONFIG_MODULES_USE_ELF_REL=y
# CONFIG_MT7621_WDT is not set
diff --git a/target/linux/ramips/mt7621/config-4.14
b/target/linux/ramips/mt7621/config-4.14
index b279c69879..a2c58e030b 100644
--- a/target/linux/ramips/mt7621/config-4.14
+++ b/target/linux/ramips/mt7621/config-4.14
@@ -173,9 +173,9 @@ CONFIG_MIPS_L1_CACHE_SHIFT=5
CONFIG_MIPS_MT=y
CONFIG_MIPS_MT_FPAFF=y
CONFIG_MIPS_MT_SMP=y
-CONFIG_MIPS_NO_APPENDED_DTB=y
+# CONFIG_MIPS_NO_APPENDED_DTB is not set
CONFIG_MIPS_PERF_SHARED_TC_COUNTERS=y
-# CONFIG_MIPS_RAW_APPENDED_DTB is not set
+CONFIG_MIPS_RAW_APPENDED_DTB=y
CONFIG_MIPS_SPRAM=y
# CONFIG_MIPS_VPE_LOADER is not set
CONFIG_MODULES_USE_ELF_REL=y
diff --git a/target/linux/ramips/mt76x8/config-4.14
b/target/linux/ramips/mt76x8/config-4.14
index 5bcb948585..21cf070374 100644
--- a/target/linux/ramips/mt7
Re: [OpenWrt-Devel] [PATCH] ath79: rename EEPROM to art
Hi David, Adrian,
On 22.11.2019 22:39, David Bauer wrote:
Hello Adrian,
On 11/22/19 2:45 PM, Adrian Schmutzler wrote:
This renames all remaining occurrences of "EEPROM" to "art" to
further harmonize the partition labelling in ath79.
Hmm, I'm not sure if/why we should to these changes.
Ubiquiti names these partitions "EEPROM" in their firmware
and it contains more information (e.g. board-id / sub-revision)
than just the calibration data.
Unified and consistent naming of calibration data partition has obvious
advantages, like decrease user-space code duplication and limit
copy&paste mistakes in future. I don't think this is the first time we
change manufacturer partition naming scheme.
So:
Acked-by: Piotr Dymacz
--
Cheers,
Piotr
Best wishes
David
Signed-off-by: Adrian Schmutzler
---
.../linux/ath79/dts/ar9342_ubnt_lap-120.dts | 2 +-
.../ath79/dts/ar9342_ubnt_nanobeam-ac.dts | 2 +-
.../dts/ar9342_ubnt_nanostation-ac-loco.dts | 2 +-
.../ath79/dts/ar9342_ubnt_nanostation-ac.dts | 4 ++--
target/linux/ath79/dts/ar9342_ubnt_wa.dtsi| 6 +++---
target/linux/ath79/dts/ar9342_ubnt_xw.dtsi| 8
.../linux/ath79/dts/qca9533_ubnt_acb-isp.dts | 10 +-
.../ath79/dts/qca9563_ubnt_unifiac-lite.dtsi | 2 +-
.../ath79/dts/qca9563_ubnt_unifiac-pro.dtsi | 2 +-
.../linux/ath79/dts/qca9563_ubnt_unifiac.dtsi | 6 +++---
.../etc/hotplug.d/firmware/11-ath10k-caldata | 20 +--
11 files changed, 31 insertions(+), 33 deletions(-)
diff --git a/target/linux/ath79/dts/ar9342_ubnt_lap-120.dts
b/target/linux/ath79/dts/ar9342_ubnt_lap-120.dts
index 82f864b8e3..757654eaee 100644
--- a/target/linux/ath79/dts/ar9342_ubnt_lap-120.dts
+++ b/target/linux/ath79/dts/ar9342_ubnt_lap-120.dts
@@ -26,7 +26,7 @@
/* default for ar934x, except for 1000M and 10M */
pll-data = <0x0600 0x0101 0x1313>;
- mtd-mac-address = <&eeprom 0x0>;
+ mtd-mac-address = <&art 0x0>;
phy-mode = "rgmii";
phy-handle = <&phy4>;
diff --git a/target/linux/ath79/dts/ar9342_ubnt_nanobeam-ac.dts
b/target/linux/ath79/dts/ar9342_ubnt_nanobeam-ac.dts
index 6e64c7faad..30d054dfed 100644
--- a/target/linux/ath79/dts/ar9342_ubnt_nanobeam-ac.dts
+++ b/target/linux/ath79/dts/ar9342_ubnt_nanobeam-ac.dts
@@ -51,7 +51,7 @@
/* default for ar934x, except for 1000M and 10M */
pll-data = <0x0600 0x0101 0x1313>;
- mtd-mac-address = <&eeprom 0x0>;
+ mtd-mac-address = <&art 0x0>;
phy-mode = "rgmii";
phy-handle = <&phy4>;
diff --git a/target/linux/ath79/dts/ar9342_ubnt_nanostation-ac-loco.dts
b/target/linux/ath79/dts/ar9342_ubnt_nanostation-ac-loco.dts
index 9b26d1a628..89904721c0 100644
--- a/target/linux/ath79/dts/ar9342_ubnt_nanostation-ac-loco.dts
+++ b/target/linux/ath79/dts/ar9342_ubnt_nanostation-ac-loco.dts
@@ -27,7 +27,7 @@
/* default for ar934x, except for 1000M and 10M */
pll-data = <0x0600 0x0101 0x1313>;
- mtd-mac-address = <&eeprom 0x0>;
+ mtd-mac-address = <&art 0x0>;
phy-mode = "rgmii";
phy-handle = <&phy4>;
diff --git a/target/linux/ath79/dts/ar9342_ubnt_nanostation-ac.dts
b/target/linux/ath79/dts/ar9342_ubnt_nanostation-ac.dts
index b591925154..97597e5f15 100644
--- a/target/linux/ath79/dts/ar9342_ubnt_nanostation-ac.dts
+++ b/target/linux/ath79/dts/ar9342_ubnt_nanostation-ac.dts
@@ -58,7 +58,7 @@
/* default for ar934x, except for 1000M and 10M */
pll-data = <0x0600 0x0101 0x1313>;
- mtd-mac-address = <&eeprom 0x0>;
+ mtd-mac-address = <&art 0x0>;
phy-mode = "rgmii";
phy-handle = <&phy0>;
@@ -73,5 +73,5 @@
&wmac {
status = "okay";
- mtd-cal-data = <&eeprom 0x1000>;
+ mtd-cal-data = <&art 0x1000>;
};
diff --git a/target/linux/ath79/dts/ar9342_ubnt_wa.dtsi
b/target/linux/ath79/dts/ar9342_ubnt_wa.dtsi
index 30fa299638..2847d4098c 100644
--- a/target/linux/ath79/dts/ar9342_ubnt_wa.dtsi
+++ b/target/linux/ath79/dts/ar9342_ubnt_wa.dtsi
@@ -75,8 +75,8 @@
read-only;
};
- eeprom: partition@ff {
- label = "EEPROM";
+ art: partition@ff {
+ label = "art";
reg = <0xff 0x01>;
read-only;
};
@@ -88,5 +88,5 @@
status = "okay";
qca,disable-5ghz;
- mtd-cal-data = <&eeprom 0x1000>;
+ mtd-cal-data = <&art 0x1000>;
};
diff --git a/target/linux/ath79/dts/ar9342_ubnt_xw.dtsi
b/target/linux/ath79/dts/ar9342_
