Re: [OpenWrt-Devel] Migration in ath79 for swapped ethernet
On Mon, Jan 27, 2020 at 4:00 PM Piotr Dymacz wrote: > > 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. 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. Or a metadata package to do the conversion post flash. 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. > > [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 ___ 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
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. 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) > > 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] [PATCH 18.06] libubox: backport security patches
On 1/26/20 4:55 PM, Hauke Mehrtens wrote: > This backports some security relevant patches from libubox master. These > patches should not change the existing API and ABI so that old > applications still work like before without any recompilation. > Application can not also use more secure APIs. > > The new more secure interfaces are also available but not used. > > OpenWrt master and 19.07.0 already have these patches by using a more > recent libubox version. > > Signed-off-by: Hauke Mehrtens > --- > > This should not change the libubox ABI, but backports most of the > changes which are in master. > > I hope I didn't miss anything important. > > package/libs/libubox/Makefile | 2 +- > ...-possible-uninitialized-struct-membe.patch | 39 + > ...hn-fix-off-by-one-in-jshn_parse_file.patch | 39 + > ...-attr-parsing-into-separate-function.patch | 97 +++ > ...-blob-introduce-blob_parse_untrusted.patch | 78 + > ...ob-fix-OOB-access-in-blob_check_type.patch | 78 + > ...eap-buffer-overflow-in-blobmsg_parse.patch | 32 > ...-length-check-does-not-perform-out-o.patch | 51 ++ > ...lobmsg_check_attr-by-blobmsg_check_a.patch | 132 +++ > ...-variants-for-all-attribute-checking.patch | 157 ++ > ...x-array-out-of-bounds-GCC-10-warning.patch | 39 + > ...g-payload-len-passed-from-blobmsg_ch.patch | 38 + > .../0012-jshn-prefer-snprintf-usage.patch | 61 +++ > ...msg-blobmsg_vprintf-prefer-vsnprintf.patch | 38 + > ...blobmsg_json-fix-int16-serialization.patch | 41 + > ...5-blobmsg_json-prefer-snprintf-usage.patch | 66 > ...parse-and-blobmsg_parse_array-oob-re.patch | 110 > ...b-Check-remaining-size-in-blob_parse.patch | 28 > 18 files changed, 1125 insertions(+), 1 deletion(-) > create mode 100644 > package/libs/libubox/patches/0001-blobmsg_json-fix-possible-uninitialized-struct-membe.patch > create mode 100644 > package/libs/libubox/patches/0002-jshn-fix-off-by-one-in-jshn_parse_file.patch > create mode 100644 > package/libs/libubox/patches/0003-blob-refactor-attr-parsing-into-separate-function.patch > create mode 100644 > package/libs/libubox/patches/0004-blob-introduce-blob_parse_untrusted.patch > create mode 100644 > package/libs/libubox/patches/0005-blob-fix-OOB-access-in-blob_check_type.patch > create mode 100644 > package/libs/libubox/patches/0006-blobmsg-fix-heap-buffer-overflow-in-blobmsg_parse.patch > create mode 100644 > package/libs/libubox/patches/0007-Ensure-blob_attr-length-check-does-not-perform-out-o.patch > create mode 100644 > package/libs/libubox/patches/0008-Replace-use-of-blobmsg_check_attr-by-blobmsg_check_a.patch > create mode 100644 > package/libs/libubox/patches/0009-blobmsg-add-_len-variants-for-all-attribute-checking.patch > create mode 100644 > package/libs/libubox/patches/0010-blobmsg-fix-array-out-of-bounds-GCC-10-warning.patch > create mode 100644 > package/libs/libubox/patches/0011-blobmsg-fix-wrong-payload-len-passed-from-blobmsg_ch.patch > create mode 100644 > package/libs/libubox/patches/0012-jshn-prefer-snprintf-usage.patch > create mode 100644 > package/libs/libubox/patches/0013-blobmsg-blobmsg_vprintf-prefer-vsnprintf.patch > create mode 100644 > package/libs/libubox/patches/0014-blobmsg_json-fix-int16-serialization.patch > create mode 100644 > package/libs/libubox/patches/0015-blobmsg_json-prefer-snprintf-usage.patch > create mode 100644 > package/libs/libubox/patches/0016-blobmsg-blobmsg_parse-and-blobmsg_parse_array-oob-re.patch > create mode 100644 > package/libs/libubox/patches/0017-blob-Check-remaining-size-in-blob_parse.patch > I would drop the last patch 0017-blob-Check-remaining-size-in-blob_parse.patch and then apply this to 18.06. Hauke signature.asc Description: OpenPGP digital signature ___ 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
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. Best Adrian ___ 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
[OpenWrt-Devel] [RFC PATCH] ath9k: enable hardware random number generator.
The ath9k driver is able to leverage the PHY ADC in order to provide a
generic hardware random number generator to the kernel, filling up the
entropy pool as required. Expose this feature in the build system and
remove the old entropy patch, which only obtains entropy from the ADC
once, when the ath9k driver is initialised.
Signed-off-by: Rui Salvaterra
---
config/Config-kernel.in | 4 +
package/kernel/mac80211/ath.mk| 7 +
.../ath/543-ath9k_entropy_from_adc.patch | 186 --
3 files changed, 11 insertions(+), 186 deletions(-)
delete mode 100644
package/kernel/mac80211/patches/ath/543-ath9k_entropy_from_adc.patch
diff --git a/config/Config-kernel.in b/config/Config-kernel.in
index 20930326ca..2f4cda4275 100644
--- a/config/Config-kernel.in
+++ b/config/Config-kernel.in
@@ -220,6 +220,10 @@ config KERNEL_AIO
bool "Compile the kernel with asynchronous IO support"
default y if !SMALL_FLASH
+config KERNEL_HW_RANDOM
+ bool "Compile the kernel with support for hardware random number
generators"
+ default n
+
config KERNEL_FHANDLE
bool "Compile the kernel with support for fhandle syscalls"
default y if !SMALL_FLASH
diff --git a/package/kernel/mac80211/ath.mk b/package/kernel/mac80211/ath.mk
index 788131b751..56859cd3c1 100644
--- a/package/kernel/mac80211/ath.mk
+++ b/package/kernel/mac80211/ath.mk
@@ -8,6 +8,7 @@ PKG_CONFIG_DEPENDS += \
CONFIG_PACKAGE_ATH_SPECTRAL \
CONFIG_PACKAGE_ATH_DYNACK \
CONFIG_ATH9K_SUPPORT_PCOEM \
+ CONFIG_ATH9K_HWRNG \
CONFIG_ATH9K_TX99 \
CONFIG_ATH10K_LEDS \
CONFIG_ATH10K_THERMAL \
@@ -45,6 +46,7 @@ config-$(CONFIG_TARGET_ipq40xx) += ATH10K_AHB
config-$(CONFIG_PCI) += ATH9K_PCI
config-$(CONFIG_ATH_USER_REGD) += ATH_USER_REGD
config-$(CONFIG_ATH9K_SUPPORT_PCOEM) += ATH9K_PCOEM
+config-$(CONFIG_ATH9K_HWRNG) += ATH9K_HWRNG
config-$(CONFIG_ATH9K_TX99) += ATH9K_TX99
config-$(CONFIG_ATH9K_UBNTHSR) += ATH9K_UBNTHSR
config-$(CONFIG_ATH10K_LEDS) += ATH10K_LEDS
@@ -211,6 +213,11 @@ define KernelPackage/ath9k/config
bool "Support chips used in PC OEM cards"
depends on PACKAGE_kmod-ath9k
+ config ATH9K_HWRNG
+ bool "Random number generator support"
+ depends on PACKAGE_kmod-ath9k
+ select KERNEL_HW_RANDOM
+
config ATH9K_TX99
bool "Enable TX99 support (WARNING: testing only, breaks normal
operation!)"
depends on PACKAGE_kmod-ath9k
diff --git
a/package/kernel/mac80211/patches/ath/543-ath9k_entropy_from_adc.patch
b/package/kernel/mac80211/patches/ath/543-ath9k_entropy_from_adc.patch
deleted file mode 100644
index 64bd6cacfd..00
--- a/package/kernel/mac80211/patches/ath/543-ath9k_entropy_from_adc.patch
+++ /dev/null
@@ -1,186 +0,0 @@
a/drivers/net/wireless/ath/ath9k/hw.h
-+++ b/drivers/net/wireless/ath/ath9k/hw.h
-@@ -722,6 +722,7 @@ struct ath_spec_scan {
- * @config_pci_powersave:
- * @calibrate: periodic calibration for NF, ANI, IQ, ADC gain, ADC-DC
- *
-+ * @get_adc_entropy: get entropy from the raw ADC I/Q output
- * @spectral_scan_config: set parameters for spectral scan and enable/disable
it
- * @spectral_scan_trigger: trigger a spectral scan run
- * @spectral_scan_wait: wait for a spectral scan run to finish
-@@ -744,6 +745,7 @@ struct ath_hw_ops {
- struct ath_hw_antcomb_conf *antconf);
- void (*antdiv_comb_conf_set)(struct ath_hw *ah,
- struct ath_hw_antcomb_conf *antconf);
-+ void (*get_adc_entropy)(struct ath_hw *ah, u8 *buf, size_t len);
- void (*spectral_scan_config)(struct ath_hw *ah,
-struct ath_spec_scan *param);
- void (*spectral_scan_trigger)(struct ath_hw *ah);
a/drivers/net/wireless/ath/ath9k/ar9003_phy.c
-+++ b/drivers/net/wireless/ath/ath9k/ar9003_phy.c
-@@ -1927,6 +1927,26 @@ void ar9003_hw_init_rate_txpower(struct
- }
- }
-
-+static void ar9003_hw_get_adc_entropy(struct ath_hw *ah, u8 *buf, size_t len)
-+{
-+ int i, j;
-+
-+ REG_RMW_FIELD(ah, AR_PHY_TEST, AR_PHY_TEST_BBB_OBS_SEL, 1);
-+ REG_CLR_BIT(ah, AR_PHY_TEST, AR_PHY_TEST_RX_OBS_SEL_BIT5);
-+ REG_RMW_FIELD(ah, AR_PHY_TEST_CTL_STATUS, AR_PHY_TEST_CTL_RX_OBS_SEL,
0);
-+
-+ memset(buf, 0, len);
-+ for (i = 0; i < len; i++) {
-+ for (j = 0; j < 4; j++) {
-+ u32 regval = REG_READ(ah, AR_PHY_TST_ADC);
-+
-+ buf[i] <<= 2;
-+ buf[i] |= (regval & 1) | ((regval & BIT(10)) >> 9);
-+ udelay(1);
-+ }
-+ }
-+}
-+
- void ar9003_hw_attach_phy_ops(struct ath_hw *ah)
- {
- struct ath_hw_private_ops *priv_ops = ath9k_hw_private_ops(ah);
-@@ -1963,6 +1983,7 @@ void ar9003_hw_attach_phy_ops(struct ath
- priv_ops->set_radar_params = ar9003_hw_set_radar_params;
Re: [OpenWrt-Devel] ath79: NAND bad eraseblocks in MikroTik RouterBOARD 922UAGS-5HPacD
The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header. To mitigate this problem, the original message has been wrapped automatically by the mailing list software.--- Begin Message --- Hi Koen, Please find the bootlogs at: https://pastebin.com/PD5Lfx3p (ath79) https://pastebin.com/j1jBauQE (ar71xx) Cheers! El 27/1/20 a les 17:31, Koen Vandeputte ha escrit: > Hi Roger, > > Can you send me full bootlogs please from both? > > I have RB922-5HPnD, not the AC version over here, but I guess the > issue will also be present over there. > > Thanks again, > > Koen > > On 27.01.20 15:16, Roger Pueyo Centelles | Guifi.net via openwrt-devel > wrote: >> The sender domain has a DMARC Reject/Quarantine policy which disallows >> sending mailing list messages using the original "From" header. >> >> To mitigate this problem, the original message has been wrapped >> automatically by the mailing list software. >> >> ___ >> openwrt-devel mailing list >> openwrt-devel@lists.openwrt.org >> https://lists.openwrt.org/mailman/listinfo/openwrt-devel --- End Message --- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] ath79: NAND bad eraseblocks in MikroTik RouterBOARD 922UAGS-5HPacD
Hi Roger, Can you send me full bootlogs please from both? I have RB922-5HPnD, not the AC version over here, but I guess the issue will also be present over there. Thanks again, Koen On 27.01.20 15:16, Roger Pueyo Centelles | Guifi.net via openwrt-devel wrote: The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header. To mitigate this problem, the original message has been wrapped automatically by the mailing list software. ___ 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] 19.07.0 boot hang on Mikrotik device
On 27.01.20 17:14, Joe Ayers wrote: You should report this bug under "openwrt-19.07": https://bugs.openwrt.org/ You are apparently using ar71xx, did you try an ath79 19.07 image? the first mikrotik device in ath79 was merged to master last week, so ath79 is not an option here ATM. Best Adrian Regards, Baptiste The devices with this issue aren't supported with Openwrt images yet :) . Thus, submitting a defect may be problematic. I've added a few definitions on top of the openwrt "Mikrotik LHG 5" to add support (and hopefully I can find the time to submit an openwrt PR). There are 3 devices with exact same motherboard "LHG 2nD" and same behavior going from 18.06.2 to 19.07.0: LDF 2nD LHG 2nD LHG 2nD-XL I have narrowed down the problem. By removing "40_run_failsafe_hook", procd completes as expected. Something seems to be triggering failsafe mode and blocking procd. If anyone knows what might have changed or where to fix the root cause, would appreciate any information to save time. I'll dig a little more... Joe AE6XE I'm also a bit worried when seeing this: [0.133043] ar71xx: invalid MDIO id 1 Koen On 25-01-20, Joe Ayers wrote: At http:\\arednmesh.org, we've had several mikrotik devices working, all with "LHG" motherboards. One of the devices, RB LHG 2nD-XL no longer boots with upgrade from 18.06.2 to 19.07.0. Other devices with same "LHG" mother board continue to work fine, e.g. RB LHG 5nD-XL, LHG 5nDHP. I'm stuck on getting this working, if you have any pointers, please let me know.Here's dmesg where it hangs: ___ 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] 19.07.0 boot hang on Mikrotik device
> > > > You should report this bug under "openwrt-19.07": > > https://bugs.openwrt.org/ > > > > You are apparently using ar71xx, did you try an ath79 19.07 image? > > the first mikrotik device in ath79 was merged to master last week, so ath79 > is not an option here ATM. > > Best > > Adrian > > > > > Regards, > > Baptiste > > The devices with this issue aren't supported with Openwrt images yet :) . Thus, submitting a defect may be problematic. I've added a few definitions on top of the openwrt "Mikrotik LHG 5" to add support (and hopefully I can find the time to submit an openwrt PR). There are 3 devices with exact same motherboard "LHG 2nD" and same behavior going from 18.06.2 to 19.07.0: LDF 2nD LHG 2nD LHG 2nD-XL I have narrowed down the problem. By removing "40_run_failsafe_hook", procd completes as expected. Something seems to be triggering failsafe mode and blocking procd. If anyone knows what might have changed or where to fix the root cause, would appreciate any information to save time. I'll dig a little more... Joe AE6XE > > On 25-01-20, Joe Ayers wrote: > > > At http:\\arednmesh.org, we've had several mikrotik devices working, > > > all with "LHG" motherboards. One of the devices, RB LHG 2nD-XL no > > > longer boots with upgrade from 18.06.2 to 19.07.0. Other devices with > > > same "LHG" mother board continue to work fine, e.g. RB LHG 5nD-XL, LHG > > > 5nDHP. > > > > > > I'm stuck on getting this working, if you have any pointers, please > > > let me know.Here's dmesg where it hangs: > > > ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] ath79: do not set inherited phy-mode/status properties again
There are several cases where phy-mode and status properties are
set again in DTS(I) files although those were set to the same values
in parent DTSI files already. Remove those cases (and thus also stop
their proliferation by copy/paste).
Signed-off-by: Adrian Schmutzler
---
target/linux/ath79/dts/ar7240.dtsi | 1 -
target/linux/ath79/dts/ar7241.dtsi | 1 -
target/linux/ath79/dts/ar9132_tplink_tl-wa901nd-v2.dts | 1 -
target/linux/ath79/dts/ar9330.dtsi | 1 -
target/linux/ath79/dts/ar9341.dtsi | 4
target/linux/ath79/dts/ar9341_pcs_cr3000.dts| 6 ++
target/linux/ath79/dts/ar9342_ubnt_nanostation-m-xw.dts | 1 -
target/linux/ath79/dts/qca953x.dtsi | 2 --
target/linux/ath79/dts/qca9561_avm_fritz4020.dts| 1 -
target/linux/ath79/dts/qca9561_tplink_archer-c25-v1.dts | 1 -
target/linux/ath79/dts/qca9561_tplink_archer-c5x.dtsi | 1 -
target/linux/ath79/dts/qca9561_tplink_archer-c6x.dtsi | 1 -
target/linux/ath79/dts/qca956x.dtsi | 2 --
target/linux/ath79/dts/tp9343_tplink_tl-wr94x.dtsi | 1 -
14 files changed, 2 insertions(+), 22 deletions(-)
diff --git a/target/linux/ath79/dts/ar7240.dtsi
b/target/linux/ath79/dts/ar7240.dtsi
index 268c8780f4..5382a710f9 100644
--- a/target/linux/ath79/dts/ar7240.dtsi
+++ b/target/linux/ath79/dts/ar7240.dtsi
@@ -65,7 +65,6 @@
resets = < 9>;
reset-names = "mac";
- phy-mode = "mii";
phy-handle = <>;
};
diff --git a/target/linux/ath79/dts/ar7241.dtsi
b/target/linux/ath79/dts/ar7241.dtsi
index 8f0eb3b270..59fcd05f5e 100644
--- a/target/linux/ath79/dts/ar7241.dtsi
+++ b/target/linux/ath79/dts/ar7241.dtsi
@@ -46,7 +46,6 @@
resets = < 9>;
reset-names = "mac";
- phy-mode = "mii";
phy-handle = <>;
};
diff --git a/target/linux/ath79/dts/ar9132_tplink_tl-wa901nd-v2.dts
b/target/linux/ath79/dts/ar9132_tplink_tl-wa901nd-v2.dts
index 3e6dd2daea..e55affdf20 100644
--- a/target/linux/ath79/dts/ar9132_tplink_tl-wa901nd-v2.dts
+++ b/target/linux/ath79/dts/ar9132_tplink_tl-wa901nd-v2.dts
@@ -119,7 +119,6 @@
{
status = "okay";
- phy-mode = "mii";
mtd-mac-address = < 0x1fc00>;
phy-handle = <>;
diff --git a/target/linux/ath79/dts/ar9330.dtsi
b/target/linux/ath79/dts/ar9330.dtsi
index 64c135405b..042b70e0bb 100644
--- a/target/linux/ath79/dts/ar9330.dtsi
+++ b/target/linux/ath79/dts/ar9330.dtsi
@@ -170,7 +170,6 @@
resets = < 9>;
reset-names = "mac";
- phy-mode = "mii";
phy-handle = <>;
};
diff --git a/target/linux/ath79/dts/ar9341.dtsi
b/target/linux/ath79/dts/ar9341.dtsi
index a7c5ac6262..10161f32ac 100644
--- a/target/linux/ath79/dts/ar9341.dtsi
+++ b/target/linux/ath79/dts/ar9341.dtsi
@@ -17,10 +17,6 @@
interrupts = <2>;
};
- {
- phy-mode = "mii";
-};
-
{
status = "okay";
};
diff --git a/target/linux/ath79/dts/ar9341_pcs_cr3000.dts
b/target/linux/ath79/dts/ar9341_pcs_cr3000.dts
index 222516f9b7..272b0909b5 100644
--- a/target/linux/ath79/dts/ar9341_pcs_cr3000.dts
+++ b/target/linux/ath79/dts/ar9341_pcs_cr3000.dts
@@ -150,13 +150,11 @@
};
{
- status = "okay";
-
phy-handle = <>;
- mtd-mac-address = < 0x0>;
- phy-mode = "gmii";
pll-data = <0x0600 0x0101 0x1616>;
+ mtd-mac-address = < 0x0>;
+
gmac-config {
device = <>;
switch-phy-swap = <1>;
diff --git a/target/linux/ath79/dts/ar9342_ubnt_nanostation-m-xw.dts
b/target/linux/ath79/dts/ar9342_ubnt_nanostation-m-xw.dts
index eac2a4268a..7ca61fe27a 100644
--- a/target/linux/ath79/dts/ar9342_ubnt_nanostation-m-xw.dts
+++ b/target/linux/ath79/dts/ar9342_ubnt_nanostation-m-xw.dts
@@ -26,7 +26,6 @@
{
status = "okay";
- phy-mode = "mii";
phy-handle = <>;
gmac-config {
diff --git a/target/linux/ath79/dts/qca953x.dtsi
b/target/linux/ath79/dts/qca953x.dtsi
index f127d4d01b..73a6ad91e5 100644
--- a/target/linux/ath79/dts/qca953x.dtsi
+++ b/target/linux/ath79/dts/qca953x.dtsi
@@ -231,8 +231,6 @@
reset-names = "mac";
resets = < 9>;
-
- phy-mode = "mii";
};
{
diff --git a/target/linux/ath79/dts/qca9561_avm_fritz4020.dts
b/target/linux/ath79/dts/qca9561_avm_fritz4020.dts
index 6412252590..75cc5761ba 100644
--- a/target/linux/ath79/dts/qca9561_avm_fritz4020.dts
+++ b/target/linux/ath79/dts/qca9561_avm_fritz4020.dts
@@ -153,7 +153,6 @@
{
status = "okay";
- phy-mode = "mii";
phy-handle = <>;
gmac-config {
diff --git a/target/linux/ath79/dts/qca9561_tplink_archer-c25-v1.dts
b/target/linux/ath79/dts/qca9561_tplink_archer-c25-v1.dts
index f894fc8672..e7b30df81f 100644
--- a/target/linux/ath79/dts/qca9561_tplink_archer-c25-v1.dts
+++ b/target/linux/ath79/dts/qca9561_tplink_archer-c25-v1.dts
@@ -181,7 +181,6 @@
{
status =
[OpenWrt-Devel] ath79: NAND bad eraseblocks in MikroTik RouterBOARD 922UAGS-5HPacD
The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header. To mitigate this problem, the original message has been wrapped automatically by the mailing list software.--- Begin Message --- Hi, I'm working on porting a second MikroTik device, the RouterBOARD 922UAGS-5HPacD, from ar71xx to ath79 and I'm having trouble with the NAND storage. The chip is detected, but bad eraseblocks are reported when booting an initramfs image via TFTP (haven't tried sysupgrade yet): [ 0.791848] Creating 4 MTD partitions on "spi0.0": [ 0.796717] 0x-0xc000 : "routerboot" [ 0.802857] 0xc000-0xd000 : "art" [ 0.808379] 0xd000-0xe000 : "bios" [ 0.813924] 0xe000-0xf000 : "soft_config" [ 0.823549] nand: device found, Manufacturer ID: 0xec, Chip ID: 0xf1 [ 0.830034] nand: Samsung NAND 128MiB 3,3V 8-bit [ 0.834717] nand: 128 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64 [ 0.842435] Scanning device for bad blocks [ 0.846909] Bad eraseblock 2 at 0x0004 [ 0.851500] Bad eraseblock 3 at 0x0006 [...] eraseblocks continue on all blocks, from 4 to 15 [ 0.911492] Bad eraseblock 16 at 0x0020 [ 1.036624] 3 fixed-partitions partitions found on MTD device ar934x-nand [ 1.043531] Creating 3 MTD partitions on "ar934x-nand": [ 1.048844] 0x-0x0004 : "booter" [ 1.054605] 0x0004-0x0040 : "kernel" [ 1.060369] 0x0040-0x0080 : "ubi" [ 1.477206] UBI error: unable to read from mtd6 The current 19.07.0 or snapshot ar71xx initramfs images do not complain about any bad eraseblocks, and can properly managa the UBI fs at mtd6: [ 3.402365] nand: device found, Manufacturer ID: 0xec, Chip ID: 0xf1 [ 3.408818] nand: Samsung NAND 128MiB 3,3V 8-bit [ 3.413534] nand: 128 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64 [ 3.421239] Scanning device for bad blocks [ 3.579454] Creating 3 MTD partitions on "ar934x-nfc": [ 3.584716] 0x-0x0004 : "booter" [ 3.607604] 0x0004-0x0040 : "kernel" [ 3.630593] 0x0040-0x0800 : "ubi" It looks like the NAND chip is correctly detected, but I don't know what I'm missing that causes the [wrong] bad eraseblocks to appear. Any suggestions? The tree with the commit adding support is at https://github.com/rogerpueyo/openwrt/tree/ath79-mikrotik-rb-922uags-5hpacd_badblocks Thanks! Roger --- End Message --- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] ath79: harmonize ethernet-phy naming scheme
A minority of ethernet-phy definitions seems to use numbers in label,
name and reg property relatively random. This patch aligns their
use to have the same numeric value for all of them.
While at it, improve order of properties/add newlines for the ethX
nodes where necessary.
Signed-off-by: Adrian Schmutzler
---
target/linux/ath79/dts/ar9132_tplink_tl-wa901nd-v2.dts | 4 ++--
target/linux/ath79/dts/ar9342_ubnt_nanostation-m-xw.dts | 4 ++--
target/linux/ath79/dts/qca9558_tplink_re350k-v1.dts | 7 ---
target/linux/ath79/dts/qca9558_tplink_rex5x.dtsi| 9 ++---
target/linux/ath79/dts/qca9558_zyxel_nbg6716.dts| 8 +---
target/linux/ath79/dts/qca9563_tplink_re450-v2.dts | 8 ++--
6 files changed, 25 insertions(+), 15 deletions(-)
diff --git a/target/linux/ath79/dts/ar9132_tplink_tl-wa901nd-v2.dts
b/target/linux/ath79/dts/ar9132_tplink_tl-wa901nd-v2.dts
index 804b71170e..3e6dd2daea 100644
--- a/target/linux/ath79/dts/ar9132_tplink_tl-wa901nd-v2.dts
+++ b/target/linux/ath79/dts/ar9132_tplink_tl-wa901nd-v2.dts
@@ -110,7 +110,7 @@
{
status = "okay";
- phy0: ethernet-phy@c {
+ phy12: ethernet-phy@c {
reg = <0xc>;
phy-mode = "mii";
};
@@ -122,7 +122,7 @@
phy-mode = "mii";
mtd-mac-address = < 0x1fc00>;
- phy-handle = <>;
+ phy-handle = <>;
};
{
diff --git a/target/linux/ath79/dts/ar9342_ubnt_nanostation-m-xw.dts
b/target/linux/ath79/dts/ar9342_ubnt_nanostation-m-xw.dts
index 6ac79b0c1e..eac2a4268a 100644
--- a/target/linux/ath79/dts/ar9342_ubnt_nanostation-m-xw.dts
+++ b/target/linux/ath79/dts/ar9342_ubnt_nanostation-m-xw.dts
@@ -17,7 +17,7 @@
phy4-mii-enable;
phy-mask = <0x23>;
- phy4: ethernet-phy@0 {
+ phy0: ethernet-phy@0 {
reg = <0>;
phy-mode = "mii";
};
@@ -27,7 +27,7 @@
status = "okay";
phy-mode = "mii";
- phy-handle = <>;
+ phy-handle = <>;
gmac-config {
device = <>;
diff --git a/target/linux/ath79/dts/qca9558_tplink_re350k-v1.dts
b/target/linux/ath79/dts/qca9558_tplink_re350k-v1.dts
index a797750e7e..f802de271e 100644
--- a/target/linux/ath79/dts/qca9558_tplink_re350k-v1.dts
+++ b/target/linux/ath79/dts/qca9558_tplink_re350k-v1.dts
@@ -88,7 +88,7 @@
gpios = < 23 GPIO_ACTIVE_HIGH>,
< 18 GPIO_ACTIVE_HIGH>;
- phy0: ethernet-phy@4 {
+ phy4: ethernet-phy@4 {
reg = <4>;
phy-mode = "rgmii-rxid";
@@ -101,9 +101,10 @@
{
status = "okay";
- mtd-mac-address = < 0x10008>;
+ phy-handle = <>;
pll-data = <0x9e00 0x8101 0x80001313>;
- phy-handle = <>;
+
+ mtd-mac-address = < 0x10008>;
gmac-config {
device = <>;
diff --git a/target/linux/ath79/dts/qca9558_tplink_rex5x.dtsi
b/target/linux/ath79/dts/qca9558_tplink_rex5x.dtsi
index 17e172d547..8827990eb5 100644
--- a/target/linux/ath79/dts/qca9558_tplink_rex5x.dtsi
+++ b/target/linux/ath79/dts/qca9558_tplink_rex5x.dtsi
@@ -93,7 +93,7 @@
#address-cells = <1>;
#size-cells = <0>;
- phy0: ethernet-phy@4 {
+ phy4: ethernet-phy@4 {
reg = <4>;
reset-gpios = < 11 GPIO_ACTIVE_LOW>;
};
@@ -167,13 +167,16 @@
{
status = "okay";
- mtd-mac-address = < 0x8>;
+
+ phy-handle = <>;
pll-data = <0xa600 0x0101 0x1616>;
- phy-handle = <>;
+
+ mtd-mac-address = < 0x8>;
};
{
status = "okay";
+
mtd-cal-data = < 0x1000>;
mtd-mac-address = < 0x8>;
mtd-mac-address-increment = <(-1)>;
diff --git a/target/linux/ath79/dts/qca9558_zyxel_nbg6716.dts
b/target/linux/ath79/dts/qca9558_zyxel_nbg6716.dts
index 5a896d52bc..4ad65c31e8 100644
--- a/target/linux/ath79/dts/qca9558_zyxel_nbg6716.dts
+++ b/target/linux/ath79/dts/qca9558_zyxel_nbg6716.dts
@@ -200,8 +200,8 @@
{
status = "okay";
- phy0: ethernet-phy@0 {
- reg = <17>;
+ phy17: ethernet-phy@11 {
+ reg = <0x11>;
phy-mode = "rgmii-id";
};
@@ -236,7 +236,8 @@
status = "okay";
pll-data = <0xa600 0x0101 0x1616>;
- phy-handle = <>;
+ phy-handle = <>;
+
fixed-link {
speed = <1000>;
full-duplex;
@@ -248,6 +249,7 @@
pll-data = <0x03000101 0x0101 0x1616>;
phy-handle = <>;
+
fixed-link {
speed = <1000>;
full-duplex;
diff --git a/target/linux/ath79/dts/qca9563_tplink_re450-v2.dts
b/target/linux/ath79/dts/qca9563_tplink_re450-v2.dts
index 464be73449..28fefe224d 100644
--- a/target/linux/ath79/dts/qca9563_tplink_re450-v2.dts
+++
