[PATCH] mediatek: bpi-r2 uses kmod-ata-ahci for block access
Fixes accessing block devices. kmod-ata-ahci-mtk is used only on R64 board. Signed-off-by: Pablo Pita --- target/linux/mediatek/image/mt7623.mk | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/target/linux/mediatek/image/mt7623.mk b/target/linux/mediatek/image/mt7623.mk index 72758ddbaa..132b603b31 100644 --- a/target/linux/mediatek/image/mt7623.mk +++ b/target/linux/mediatek/image/mt7623.mk @@ -42,7 +42,7 @@ define Device/bpi_bananapi-r2 DEVICE_MODEL := Banana Pi R2 DEVICE_DTS := mt7623n-bananapi-bpi-r2 DEVICE_PACKAGES := kmod-fs-vfat kmod-nls-cp437 kmod-nls-iso8859-1 kmod-mmc \ - mkf2fs e2fsprogs kmod-usb-ohci kmod-usb2 kmod-usb3 kmod-ata-ahci-mtk + mkf2fs e2fsprogs kmod-usb-ohci kmod-usb2 kmod-usb3 kmod-ata-ahci UBOOT_ENVSIZE := 0x2000 UBOOT_OFFSET := 320k UBOOT_TARGET := mt7623n_bpir2 -- 2.25.1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] kernel: bpi-r2 uses kmod-ata-ahci for block access
Fixes accessing block devices. kmod-ata-ahci-mtk is used only on R64 board. Signed-off-by: Pablo Pita --- target/linux/mediatek/image/mt7623.mk | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/target/linux/mediatek/image/mt7623.mk b/target/linux/mediatek/image/mt7623.mk index 72758ddbaa..132b603b31 100644 --- a/target/linux/mediatek/image/mt7623.mk +++ b/target/linux/mediatek/image/mt7623.mk @@ -42,7 +42,7 @@ define Device/bpi_bananapi-r2 DEVICE_MODEL := Banana Pi R2 DEVICE_DTS := mt7623n-bananapi-bpi-r2 DEVICE_PACKAGES := kmod-fs-vfat kmod-nls-cp437 kmod-nls-iso8859-1 kmod-mmc \ - mkf2fs e2fsprogs kmod-usb-ohci kmod-usb2 kmod-usb3 kmod-ata-ahci-mtk + mkf2fs e2fsprogs kmod-usb-ohci kmod-usb2 kmod-usb3 kmod-ata-ahci UBOOT_ENVSIZE := 0x2000 UBOOT_OFFSET := 320k UBOOT_TARGET := mt7623n_bpir2 -- 2.25.1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
RE: [PATCH] kernel: bpi-r2 uses kmod-ata-ahci for block access
Hi, > -Original Message- > From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org] > On Behalf Of Pablo Pita > Sent: Dienstag, 15. Juni 2021 16:45 > To: openwrt-devel@lists.openwrt.org > Cc: Pablo Pita > Subject: [PATCH] kernel: bpi-r2 uses kmod-ata-ahci for block access > this is target-specific, so the commit title prefix should be "mediatek:" Best Adrian > Fixes accessing block devices. > kmod-ata-ahci-mtk is used only on R64 board. > > Signed-off-by: Pablo Pita > --- > target/linux/mediatek/image/mt7623.mk | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/target/linux/mediatek/image/mt7623.mk > b/target/linux/mediatek/image/mt7623.mk > index 72758ddbaa..132b603b31 100644 > --- a/target/linux/mediatek/image/mt7623.mk > +++ b/target/linux/mediatek/image/mt7623.mk > @@ -42,7 +42,7 @@ define Device/bpi_bananapi-r2 >DEVICE_MODEL := Banana Pi R2 >DEVICE_DTS := mt7623n-bananapi-bpi-r2 >DEVICE_PACKAGES := kmod-fs-vfat kmod-nls-cp437 kmod-nls-iso8859-1 > kmod-mmc \ > - mkf2fs e2fsprogs kmod-usb-ohci kmod-usb2 kmod-usb3 kmod-ata- > ahci-mtk > + mkf2fs e2fsprogs kmod-usb-ohci kmod-usb2 kmod-usb3 kmod-ata- > ahci >UBOOT_ENVSIZE := 0x2000 >UBOOT_OFFSET := 320k >UBOOT_TARGET := mt7623n_bpir2 > -- > 2.25.1 > > > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel openpgp-digital-signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: ip rule processing partly broken (21.02 and Master)
Interesting. When I install ip-tiny I see the rule displaying correctly. I have also checked and it appears ip-tiny was installed in my 19.07 systems, likely as a dependent package, so that is why it displays correctly there. I will add the information to by bug report and close it on the tracker. I am still having odd routing problems on the 2102rc router, and am investigating why that is happening, but that is outside the scope of this email. Thanks for your help! M On Mon, 14 Jun 2021 at 10:48, Jo-Philipp Wich wrote: > > Hi, > > the ip rules encoded in /etc/config/network are processed by netifd C > code directly, they're not translated into busybox ip calls. > > The entire busybox ip.c code contains not a single instance of > FIB_RULE_INVERT so it simply does not implement inversion. It will also > not be able to report inverted rules properly, since there is no code to > print the FIB_RULE_INVERT flag. > > Are you absolutely sure that the uci rules are improperly applied or is > this just a case of busybox ip rule displaying them wrongly without the > "not" flag? > > Can you install ip-full or ip-tiny from the iproute2 suite and verify > the "ip rule" output again? > > ~ 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
Re: download: regression with USE_SOURCE_DIR and non-tarball packages?
Lukas Zeller [2021-06-14 14:11:27]: Hi, > For packages with PKG_SOURCE_PROTO=git the new line in package.mk > `$(DL_DIR)/$(FILE): FORCE` forces re-cloning the upstream repo and thus > rebuilding the entire package every time. yes, it would do that in case PKG_MIRROR_HASH is invalid and this is wanted behavior. That issue should be visible when building in verbose mode with V=s. > Also, the USE_SOURCE_DIR mechanism does not work any more. And what doesn't work exactly? I've just checked it and it works just fine for me: $ git clone git://git.openwrt.org/project/libubox /tmp/libubox $ make package/libubox/clean $ make package/libubox/prepare USE_SOURCE_DIR=/tmp/libubox $ time make package/libubox/compile V=s &> /dev/null real 0m8.241s user 0m7.179s sys0m1.643s $ time make package/libubox/compile V=s &> /dev/null real 0m4.608s user 0m3.692s sys0m1.251s $ time make package/libubox/compile V=s &> /dev/null real 0m4.625s user 0m3.740s sys0m1.239s -- ynezz ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 1/3] ath79: add gpio-latch driver for MikroTik RouterBOARDs
On Thu, May 27, 2021 at 11:18 AM Denis Kalashnikov wrote: > From: Denis Kalashnikov > > This is a slighty modified version of ar71xx gpio-latch driver > written by Gabor Juhos . > > Changes: > * DTS support, > * New gpio API (gpiod_*). > > Signed-off-by: Denis Kalashnikov Reviewed-by: Sergey Ryazanov ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: download: regression with USE_SOURCE_DIR and non-tarball packages?
Hi, > On 15 Jun 2021, at 10:05, Petr Štetiar wrote: > [...] yes, it would do that in case PKG_MIRROR_HASH is invalid [...] Thanks, that helped a lot! I ran the exact same tests with libubox and as those worked, I realized that the difference between the packages I tried and libubox is that the latter has (of course) a PKG_MIRROR_HASH. The packages I wanted to work with did not have a PKG_MIRROR_HASH at all, because under development and not yet released (PKG_SOURCE_VERSION:=master). > [...] That issue should be visible when building in verbose mode with V=s. Only if there is a PKG_MIRROR_HASH in the makefile. Otherwise, the repo is just re-cloned every time without an indication why (I now found that make package/xxx/check would have revealed it) But finally I found out about PKG_MIRROR_HASH=skip, which seems to be the solution for packages under development. It is not documented as such, but as a step for updating the hash. Would it make sense if I try to add a note explaining this under "Working on local application source" in the "Creating Packages" wiki page? Lukas signature.asc Description: Message signed with OpenPGP ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 2/3] ath79: add NAND driver for MikroTik RB91xG series
On Thu, May 27, 2021 at 11:18 AM Denis Kalashnikov wrote: > From: Denis Kalashnikov > > Main part is copied from ar71xx original driver rb91x_nand > written by Gabor Juhos . > > What is done: > * Support of kernel 5.4 and 5.10, > * DTS support, > * New gpio API (gpiod_*) support. > > Signed-off-by: Denis Kalashnikov Reviewed-by: Sergey Ryazanov ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 0/3] ath79: add support for MikroTik RouterBOARD 912UAG-2HPnD
On Mon, Jun 14, 2021 at 6:29 PM Koen Vandeputte wrote: > On 27.05.21 10:16, Denis Kalashnikov wrote: > > From: Denis Kalashnikov > > > > RB912 needs two ad hoc drivers: gpio-latch and rb91x_nand. So I've ported > > them > > from ar71xx and added DTS. > > > > In RFC v1 I added a MFD driver that provided API for manipulating shared > > gpio > > lines to gpio-latch and nand drivers. In RFC v2 I just ported gpio-latch and > > rb91x_nand drivers from ar71xx to ath79 by adding DTS support and usage of > > a new gpio API (gpiod_*). This way is turned to be more clear and compact. > > So, I've tried to fix what you guys advised me and here is my patches v1. > > > > All seems to be working on my RB912UAG-2HPnD. Except a button and a beeper. > > The > > beeper seems is not important thing, but the button is. The button shares > > gpio > > 15 with NAND ALE and NAND IO7, but this is not easily supported by the > > current > > drivers. May be we need ad hoc driver for button. Or may be there is a more > > general solution for this problem (like rb91x-gpio driver that arbitrates > > all gpio lines instead of gpio-latch). This can be fixed in the next > > patches. > > > > Denis Kalashnikov (3): > >ath79: add gpio-latch driver for MikroTik RouterBOARDs > >ath79: add NAND driver for MikroTik RB91xG series > >ath79: add support for MikroTik RouterBOARD 912UAG-2HPnD > > > > ...9342_mikrotik_routerboard-912uag-2hpnd.dts | 214 ++ > > .../ath79/files/drivers/gpio/gpio-latch.c | 203 ++ > > .../files/drivers/mtd/nand/raw/rb91x_nand.c | 375 ++ > > target/linux/ath79/image/mikrotik.mk | 9 + > > .../base-files/etc/board.d/02_network | 2 + > > .../etc/hotplug.d/firmware/10-ath9k-eeprom| 1 + > > .../base-files/lib/upgrade/platform.sh| 1 + > > target/linux/ath79/mikrotik/config-default| 1 + > > .../patches-5.10/939-mikrotik-rb91x.patch | 49 +++ > > .../patches-5.4/939-mikrotik-rb91x.patch | 44 ++ > > 10 files changed, 899 insertions(+) > > create mode 100644 > > target/linux/ath79/dts/ar9342_mikrotik_routerboard-912uag-2hpnd.dts > > create mode 100644 target/linux/ath79/files/drivers/gpio/gpio-latch.c > > create mode 100644 > > target/linux/ath79/files/drivers/mtd/nand/raw/rb91x_nand.c > > create mode 100644 > > target/linux/ath79/patches-5.10/939-mikrotik-rb91x.patch > > create mode 100644 target/linux/ath79/patches-5.4/939-mikrotik-rb91x.patch > > > Tested on the 5GHz flavor and works fine > > > Any other objections/remarks? Still have no chance to run-test it, but the code looks overly good for me. > I will merge this otherwise tomorrow. Thanks for taking care of this. Just curious. Are there any chances that support for this board will be backported to the 21.02 branch? -- Sergey ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] kernel: bpi-r2 uses kmod-ata-ahci for block access
Fixes accessing block devices. kmod-ata-ahci-mtk is used only on R64 board. Signed-off-by: Pablo Pita --- target/linux/mediatek/image/mt7623.mk | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/target/linux/mediatek/image/mt7623.mk b/target/linux/mediatek/image/mt7623.mk index 72758ddbaa..132b603b31 100644 --- a/target/linux/mediatek/image/mt7623.mk +++ b/target/linux/mediatek/image/mt7623.mk @@ -42,7 +42,7 @@ define Device/bpi_bananapi-r2 DEVICE_MODEL := Banana Pi R2 DEVICE_DTS := mt7623n-bananapi-bpi-r2 DEVICE_PACKAGES := kmod-fs-vfat kmod-nls-cp437 kmod-nls-iso8859-1 kmod-mmc \ - mkf2fs e2fsprogs kmod-usb-ohci kmod-usb2 kmod-usb3 kmod-ata-ahci-mtk + mkf2fs e2fsprogs kmod-usb-ohci kmod-usb2 kmod-usb3 kmod-ata-ahci UBOOT_ENVSIZE := 0x2000 UBOOT_OFFSET := 320k UBOOT_TARGET := mt7623n_bpir2 -- 2.25.1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH v4] ath79: add support for Ubiquiti PowerBeam M (XW)
Random observations follow: I received another PBE-M5-400 feedhorn today. It arrived with XW.v6.1.4 installed. Using its GUI, I tried directly flashing a recent master branch OpenWrt with my support commit on top and it complained with a "firmware image check failed". Using the v6.1.4 GUI, I downgraded to XW.v5.6.15-sign.31612.170908.1440.bin. That was accepted and the device rebooted into v5.6.15. Using the v5.6.15 GUI, I tried to flash my same OpenWrt image and got: "This firmware is not trusted by airOS. To maintain security, it will not be loaded. Please load trusted firmware." >From those observations, I infer that reverting to 5.5.x is still needed to use the GUI to flash. Reverting to 5.5.x still requires some ssh'ing and scp'ing, but it does not require TFTP, and might still be a desirable path for people allergic to TFTP for whatever reason. I also tried directly TFTP flashing from v6.1.4 to my openwrt factory image and confirmed that worked. When I tried TFTP flashing from v6.1.4 to v5.5.10-u2, I got the message: "Error code 2: Firmware check failed". When I tried TFTP flashing from v6.1.4 to v5.6.15 (unsigned), that succeeded, (the uboot partition /dev/mtdblock0 had the same md5sum hash as on v6.1.4), but from v5.6.15 (unsigned) I could scp v5.5.10-u2 to /tmp/fwupdate.bin and use the built in fwupdate.real to update: XW.v5.6.15# fwupdate.real -m fwupdate.bin Current ver: 329231 New version: 328970 No need to fix. Writing 'u-boot ' to /dev/mtd0(u-boot ) ... [%100] Writing 'kernel ' to /dev/mtd2(kernel ) ... [%100] Writing 'rootfs ' to /dev/mtd3(rootfs ) ... [%100] Done Then you can ssh into v5.5.10-u2 (with a relaxation of modern ssh key exchange algorithms): $ ssh -oKexAlgorithms=+diffie-hellman-group1-sha1 ubnt@192.168.1.20 and confirm the md5sum of the u-boot has changed: XW.v5.5.10-u2# dd if=/dev/mtdblock0 | md5sum 512+0 records in 512+0 records out 753d74c53339edfd8f8289e772f5abeb - and you won't have any pesky "Firmware checks" anymore, if you need that. I also did some experiments with the current firmware v6.3.2. It has a yet again different u-boot md5sum, and for as-yet-unknown reasons I started to have trouble connecting with it at 192.168.1.20. I have some packet captures that suggest it's trying to phone home, requesting DHCP and so forth. On an isolated network, I was able to TFTP directly from v6.3.2 to my OpenWrt firmware. I'll continue experimenting, but I don't see any of this as a reason to hold up merging the support-adding commit. On Mon, Jun 14, 2021 at 1:05 PM Russell Senior wrote: > > On Mon, Jun 14, 2021 at 6:54 AM Joe Ayers wrote: > > > > > > I'm having a bit of heartburn with continuing with these instructions: > > > > > > > > > Flashing via stock GUI: > > > > > - Downgrade to AirOS v5.5.x (latest available is 5.5.10-u2) first > > > > > (see > > > > >https://openwrt.org/toh/ubiquiti/powerbeam installation > > > > > instructions) > > > > > > > > This issue was resolved with: > > > > > > > > https://github.com/openwrt/openwrt/commit/076d58d3440f382c536ea8874f58b0df23c263bc > > > > https://github.com/openwrt/openwrt/commit/6009b3fd586a1fd91400074080afb9545c6cf7e2 > > > > > > Those commits resolve the problem for TFTP, but if people want to use > > > the GUI, they still need to downgrade, right? Both instructions are > > > included in the commit message. Note that the TFTP instructions don't > > > mention downgrading. > > > > I remember flashing via the stock GUI in AirOS v5.6.? had worked. As > > I recall, firmware signatures were not required until a future AirOS > > version . If so, downgrading shouldn't need to occur all the way > > back to v5.5.10-u2. The AirOS release note history should tell us > > when firmware signing was introduced. I'm sorry, I don't have time > > available to substantiate right now, to make sure my memory is > > correct. > > > > Would anyone ever follow the GUI flash with all the steps, when 1 tftp > > flash works?I suspect there is no impact regardless, might just > > move forward, not worth the time. > > No one seems to have tried all the starting condition possibilities, I > certainly haven't. If we were being crushingly complete in testing, we > would try every one of them. If we knew how likely each starting > condition is, we could even weight our instructions accordingly. Given > that serial access is not easy right now, because of not being able > (at least I'm not able) to non-destructively open the feedhorn > enclosure to get access to the serial console pins, I'd rather not > risk trying an AirOS that might make it impossible to recover. Given > that this is *JUST A COMMIT MESSAGE* and not a mutable, improvable, > instruction (which should live on the wiki anyway), it seems to me > reasonable to accept being a little conservative in the instructions > here, even if some of the steps turn out to not be strictly necessary. > > -- > Russell Senior >
Re: [PATCH 5/5] tegra: make target source-only
On 13.06.21 18:28, Tomasz Maciej Nowak wrote: Looking at OpenWrt downloading statistics this target has non-existent userbase apart from me. Mark it as source-only to skip the build by buildbots and not waste further the resources. Signed-off-by: Tomasz Maciej Nowak --- I'll keep this target in good condition in forseable future. If anyone would suggest to drop the target, I'm not opposed. I've been thinking for some time to try to support nvidia Jetson (and some carrier boards) as L4T is really .. really buggy and running way behind. Also some commonly used packages are also present in OpenWRT like gstreamer, opencv, .. I was thinking to use this target as a guideline for trying to do that. Would you be interested? Regards, Koen ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 3/3] ath79: add support for MikroTik RouterBOARD 912UAG-2HPnD
On Thu, May 27, 2021 at 11:18 AM Denis Kalashnikov wrote: > From: Denis Kalashnikov > > This board has been supported in the ar71xx. > > Links: > * https://mikrotik.com/product/RB912UAG-2HPnD > * https://openwrt.org/toh/hwdata/mikrotik/mikrotik_rb912uag-2hpnd > > Hardware: > * SoC: Atheros AR9342, > * RAM: DDR 64MB, > * SPI NOR: 64KB, > * NAND: 128MB, > * Ethernet: x1 10/100/1000 port with passive POE in, > * Wi-Fi: 802.11 b/g/n, > * PCIe, > * USB: 2.0 EHCI controller, connected to mPCIe slot and a Type-A > port -- both can be used for LTE modem. But only one can be used. > * LEDs: 5 general purpose LEDs (led1..led5), power LED, user LED, > Ethernet phy LED, > * Button, > * Beeper. > > Not working: > * Button: it shares gpio line 15 with NAND ALE and NAND IO7, > and current drivers doesn't easily support this configuration, > * Beeper: it is connected to bit 5 of a serial shift register > (tested with sysfs led trigger timer). But kmod-gpio-beeper > doesn't work -- we left this as is for now. > > Flashing: > * Use the RouterBOARD Reset button to enable TFTP netboot, > boot kernel and initramfs and then perform sysupgrade. > * From ar71xx OpenWrt firmware run: > $ sysupgrade -F /tmp/ > For more info see: https://openwrt.org/toh/mikrotik/common. > > Co-Developed-by: Koen Vandeputte > Signed-off-by: Denis Kalashnikov Reviewed-by: Sergey Ryazanov ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 3/3] ath79: add support for MikroTik RouterBOARD 912UAG-2HPnD
On Mon, Jun 14, 2021 at 9:02 PM Adrian Schmutzler
wrote:
>
> Hi,
>
> a few remaining comments below.
>
>> + gpio-export {
>> + compatible = "gpio-export";
>> +
>> + usb_power {
>> + label = "power:usb";
>
> gpio-export nodes normally don't have a label property. We have
> gpio-export,name instead.
>
>> + gpio-export,name = "power-usb";
>> + gpio-export,output = <1>;
>> + gpios = < 6 GPIO_ACTIVE_HIGH>;
>> + };
>> +
>> + pcie_power {
>> + label = "power:pcie";
>> + gpio-export,name = "power-pcie";
>> + gpio-export,output = <0>;
>> + gpios = < 7 GPIO_ACTIVE_HIGH>;
>> + };
>> + };
>> +};
>> +
>> + {
>> + status = "okay";
>> +
>> + compatible = "qca,ar7100-spi";
>> +
>> + cs-gpios = <0>, <_latch 0 GPIO_ACTIVE_LOW>;
>
> I still don't think this belongs here. Why would it be the only device
> requiring this, while we removed it everywhere else?
Every other board uses SPI controller CS lines, so they are not needed
in this property. While the RB912 board uses the controller CS line
only to control the first device on the bus, and the regular GPIO line
to control the second device. So yes, this board requires the cs-gpios
property.
This board is overly special, the latch based GPIO controller will
just suffice to mention.
>> +
>> + flash@0 {
>> + compatible = "jedec,spi-nor";
>> + reg = <0>;
>> + spi-max-frequency = <8000>;
>
> Typically, speeds > 50 MHz require m25p,fast-read?
--
Sergey
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 3/3] ath79: add support for MikroTik RouterBOARD 912UAG-2HPnD
On 14.06.21 20:02, Adrian Schmutzler wrote:
Hi,
a few remaining comments below.
+ gpio-export {
+ compatible = "gpio-export";
+
+ usb_power {
+ label = "power:usb";
gpio-export nodes normally don't have a label property. We have
gpio-export,name instead.
OK. Thanks
+ gpio-export,name = "power-usb";
+ gpio-export,output = <1>;
+ gpios = < 6 GPIO_ACTIVE_HIGH>;
+ };
+
+ pcie_power {
+ label = "power:pcie";
+ gpio-export,name = "power-pcie";
+ gpio-export,output = <0>;
+ gpios = < 7 GPIO_ACTIVE_HIGH>;
+ };
+ };
+};
+
+ {
+ status = "okay";
+
+ compatible = "qca,ar7100-spi";
+
+ cs-gpios = <0>, <_latch 0 GPIO_ACTIVE_LOW>;
I still don't think this belongs here. Why would it be the only device
requiring this, while we removed it everywhere else?
+
+ flash@0 {
+ compatible = "jedec,spi-nor";
+ reg = <0>;
+ spi-max-frequency = <8000>;
Typically, speeds > 50 MHz require m25p,fast-read?
I checked datasheets for all revisions (carrying different NOR's) and
80MHz was the lowest common for all.
This was also tested on all various boards.
But I do agree to play safe here and reduce to 50.
The performance impact is nearly 0 while avoiding issues on potential
newer revisions later on.
Thanks for the insights.
Best
Adrian
@ Denis
I can adapt this right away in my staging tree if that's ok with you.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
