Re: Subject: [PATCH] x86 64: Add new device Cordoba Edge Platform
Doesn't this just have ixgbe and igc NIC's? And the mt7915e of course. Don't think we need the amd-xgbe, bnx2, e1000e, e1000, r8169, tg3 drivers. The BIOS we've been using has some odd enumeration of the PCI bus, so you might want to include a patch for target/linux/x86/base-files/etc/board.d/02_network And bind the PCI addresses to the ethernet device names. > On Oct 18, 2023, at 8:44 PM, Xiaojun Liu wrote: > > Add new device Cordoba Edge Platform > Device name: Cordoba Edge Platform > hardware specifications: CPU - Intel Atom C3000 > WiFi - mt7915e > > Signed-off-by: Xiaojun Liu mailto:xiaojun@silicom.co.il > --- > target/linux/x86/image/64.mk | 11 +++ > 1 file changed, 11 insertions(+) > > diff --git a/target/linux/x86/image/64.mk b/target/linux/x86/image/64.mk > index 5ec9978b66..04ce0be13a 100644 > --- a/target/linux/x86/image/64.mk > +++ b/target/linux/x86/image/64.mk > @@ -8,3 +8,14 @@ define Device/generic >GRUB2_VARIANT := generic > endef > TARGET_DEVICES += generic > + > +define Device/cordoba > + DEVICE_VENDOR := Cordoba > + DEVICE_MODEL := x86/64 > + DEVICE_PACKAGES += \ > +kmod-amazon-ena kmod-amd-xgbe kmod-bnx2 kmod-e1000e kmod-e1000 \ > +kmod-forcedeth kmod-fs-vfat kmod-igb kmod-igc kmod-ixgbe kmod-r8169 \ > +kmod-tg3 kmod-mt7915-firmware > + GRUB2_VARIANT := generic > +endef > +TARGET_DEVICES += cordoba > > ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[sdwalker/sdwalker.github.io] 49fae6: This week's update
The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header. To mitigate this problem, the original message has been wrapped automatically by the mailing list software.--- Begin Message --- Branch: refs/heads/master Home: https://github.com/sdwalker/sdwalker.github.io Commit: 49fae67211d6ff6c81dee14e1dba8ccf32b94e34 https://github.com/sdwalker/sdwalker.github.io/commit/49fae67211d6ff6c81dee14e1dba8ccf32b94e34 Author: Stephen Walker Date: 2023-10-22 (Sun, 22 Oct 2023) Changed paths: M uscan/index-22.03.html M uscan/index-23.05.html M uscan/index.html Log Message: --- This week's update --- End Message --- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] mac80211: add support for rtw88_8822bu
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 --- Hello Hauke, On 10/22/23 17:53, Hauke Mehrtens wrote: > On 10/22/23 12:31, Alexis Lothoré wrote: >> From: Alexis Lothoré >> + $(PKG_BUILD_DIR)/drivers/net/wireless/realtek/rtw88/rtw88_pci.ko \ >> + $(PKG_BUILD_DIR)/drivers/net/wireless/realtek/rtw88/rtw88_usb.ko >> + AUTOLOAD:=$(call AutoProbe,rtw88_8822be rtw88_8822bu rtw88_8822ce >> rtw88_8723de) >> endef >> define KernelPackage/rtl8723bs > > Currently this package only depends on PCI support, this also adds a > dependency > to USB. > > I think the beast approach is to split this into a core part with the > rtw88_core.ko and the rtw88_88*.ko files, one package with rtw88_pci.ko and > one > with rtw88_usb.ko. Then you can install it on a system with only USB and on a > system with only PCIe support. Thanks for the review. I have shot for the easy way of enabling this support since I did not dig a lot in OpenWRT build system, but indeed, your suggestion sounds cleaner. I will take a look at how to do this split properly and come back with a v2. Kind regards, Alexis > Hauke > -- Alexis Lothoré, Bootlin Embedded Linux and Kernel engineering https://bootlin.com --- End Message --- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH libubox] jshn: Do not perform double key normalisation
Cc Felix's correct address. Sorry for the noise!
Best,
Sander
On Sun, 2023-10-22 at 17:51 +0200, Sander Vanheule wrote:
> jshn stores a JSON file in the shell environment using a set of
> variable, using the key to an object in the shell variable name. This
> restricts the allowed character set to numbers, letters, and underscore.
>
> Commit a1a97eb11e89 ("jshn: support using characters in elements that do
> not conform to shell variable restrictions") added normalisation to
> jshn.sh, to ensure the shell functions produce legal variable names. The
> original key name is stored in a 'N_normalised_key' variable, to enable
> 'jshn -o file.json' to create a JSON file with the original key name.
>
> Earlier code from commit fda6079b30a4 ("add jshn") also included the
> necessary code to perform character set normalisation while building
> variable names, which is triggered when loading files with 'jshn -R
> file.json'. While add_json_element() will normalise key names, it will
> not produce the key names lookup variables, as this concept had not been
> introduced yet.
>
> The former change resulted in double name normalisation being performed
> when loading an existing file into the environment, causing the original
> key name to be replaced by its normalised version:
>
> # cat board.json
> {
> "network-device": {
> "foo": "bar"
> }
> }
>
> # /usr/bin/jshn -R board.json
> json_init;
> json_add_object 'network_device';
> json_add_string 'foo' 'bar';
> json_close_object;
>
> By removing key normalisation from jshn.c, _json_add_generic() now has
> the required information again to correctly store the original key,
> ensuring repeated operations of 'jshn -R' and 'jshn -o' do not modify
> the original JSON file (modulo formatting).
>
> Fixes: a1a97eb11e89 ("jshn: support using characters in elements that do not
> conform to
> shell variable restrictions")
> Signed-off-by: Sander Vanheule
> ---
> This issue was uncovered by the people debugging a recent issue on
> Realtek switches [1]. A JSON section was used with the name
> 'network-device'. As per the above description, this would be normalised
> to 'network_device'. The key name was correctly stored, as long as the
> file adding that section (02_network) was the last one to be run.
>
> OpenWrt commit 4ebba8a05d09 ("realtek: add support for HPE
> 1920-8g-poe+") had added a file 03_gpio running after 02_network,
> resulting a call to 'jshn -R' and silent normalisation of
> 'network-device' to 'network_device'.
>
> The issue was fixed in OpenWrt and netifd by just always using the
> normalised key version. Note that even with this change applied, there
> is still no way with jshn to represent keys with the same normalisation
> (e.g. 'foo-bar' and 'foo_bar') in one file. Fixing that would require
> properly escaping key names in some way when building variable names.
>
> [1] https://forum.openwrt.org/t/57875/2589
>
> Cc: Christian Marangi
> Cc: Felix Fietkau
> Cc: Jan Hoffmann
> Cc: Michael Weinrich
>
>
> jshn.c | 10 +-
> 1 file changed, 1 insertion(+), 9 deletions(-)
>
> diff --git a/jshn.c b/jshn.c
> index 1b685e5fb0d8..97873a220d64 100644
> --- a/jshn.c
> +++ b/jshn.c
> @@ -96,14 +96,6 @@ static void add_json_string(const char *str)
> fwrite(ptr, len, 1, stdout);
> }
>
> -static void write_key_string(const char *key)
> -{
> - while (*key) {
> - putc(isalnum(*key) ? *key : '_', stdout);
> - key++;
> - }
> -}
> -
> static int add_json_element(const char *key, json_object *obj)
> {
> char *type;
> @@ -135,7 +127,7 @@ static int add_json_element(const char *key, json_object
> *obj)
> }
>
> fprintf(stdout, "json_add_%s '", type);
> - write_key_string(key);
> + add_json_string(key);
>
> switch (json_object_get_type(obj)) {
> case json_type_object:
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] mac80211: add support for rtw88_8822bu
On 10/22/23 12:31, Alexis Lothoré wrote: From: Alexis Lothoré Kernel 6.1 has introduced support for RTW8822BU network adapter, which is an USB variant of the rtw8822b 802.11ac chipset family. Build and install the corresponding module in the rtw88 package Signed-off-by: Alexis Lothoré --- This commit has been tested on Raspberry Pi 4 with an Archer T3U USB Nano Wifi dongle (8822BU). The resulting OpenWRT successfully acts as station or access point --- package/kernel/mac80211/realtek.mk | 12 +++- 1 file changed, 7 insertions(+), 5 deletions(-) diff --git a/package/kernel/mac80211/realtek.mk b/package/kernel/mac80211/realtek.mk index 9c143583265e..4c618e6257c7 100644 --- a/package/kernel/mac80211/realtek.mk +++ b/package/kernel/mac80211/realtek.mk @@ -21,8 +21,8 @@ config-y += RTL8XXXU_UNTESTED config-$(call config_package,rtl8723bs) += RTL8723BS config-y += STAGING -config-$(call config_package,rtw88) += RTW88 RTW88_CORE RTW88_PCI -config-y += RTW88_8822BE RTW88_8822CE RTW88_8723DE +config-$(call config_package,rtw88) += RTW88 RTW88_CORE RTW88_PCI RTW88_USB +config-y += RTW88_8822BE RTW88_8822BU RTW88_8822CE RTW88_8723DE config-$(CONFIG_PACKAGE_RTW88_DEBUG) += RTW88_DEBUG config-$(CONFIG_PACKAGE_RTW88_DEBUGFS) += RTW88_DEBUGFS @@ -168,18 +168,20 @@ endef define KernelPackage/rtw88 $(call KernelPackage/mac80211/Default) - TITLE:=Realtek RTL8822BE/RTL8822CE/RTL8723DE + TITLE:=Realtek RTL8822BE/RTL8822BU/RTL8822CE/RTL8723DE DEPENDS+= @(PCI_SUPPORT) +kmod-mac80211 +@DRIVER_11AC_SUPPORT FILES:=\ $(PKG_BUILD_DIR)/drivers/net/wireless/realtek/rtw88/rtw88_8822be.ko \ + $(PKG_BUILD_DIR)/drivers/net/wireless/realtek/rtw88/rtw88_8822bu.ko \ $(PKG_BUILD_DIR)/drivers/net/wireless/realtek/rtw88/rtw88_8822b.ko \ $(PKG_BUILD_DIR)/drivers/net/wireless/realtek/rtw88/rtw88_8822ce.ko \ $(PKG_BUILD_DIR)/drivers/net/wireless/realtek/rtw88/rtw88_8822c.ko \ $(PKG_BUILD_DIR)/drivers/net/wireless/realtek/rtw88/rtw88_8723de.ko \ $(PKG_BUILD_DIR)/drivers/net/wireless/realtek/rtw88/rtw88_8723d.ko \ $(PKG_BUILD_DIR)/drivers/net/wireless/realtek/rtw88/rtw88_core.ko \ - $(PKG_BUILD_DIR)/drivers/net/wireless/realtek/rtw88/rtw88_pci.ko - AUTOLOAD:=$(call AutoProbe,rtw88_8822be rtw88_8822ce rtw88_8723de) + $(PKG_BUILD_DIR)/drivers/net/wireless/realtek/rtw88/rtw88_pci.ko \ + $(PKG_BUILD_DIR)/drivers/net/wireless/realtek/rtw88/rtw88_usb.ko + AUTOLOAD:=$(call AutoProbe,rtw88_8822be rtw88_8822bu rtw88_8822ce rtw88_8723de) endef define KernelPackage/rtl8723bs Currently this package only depends on PCI support, this also adds a dependency to USB. I think the beast approach is to split this into a core part with the rtw88_core.ko and the rtw88_88*.ko files, one package with rtw88_pci.ko and one with rtw88_usb.ko. Then you can install it on a system with only USB and on a system with only PCIe support. Hauke ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH libubox] jshn: Do not perform double key normalisation
jshn stores a JSON file in the shell environment using a set of
variable, using the key to an object in the shell variable name. This
restricts the allowed character set to numbers, letters, and underscore.
Commit a1a97eb11e89 ("jshn: support using characters in elements that do
not conform to shell variable restrictions") added normalisation to
jshn.sh, to ensure the shell functions produce legal variable names. The
original key name is stored in a 'N_normalised_key' variable, to enable
'jshn -o file.json' to create a JSON file with the original key name.
Earlier code from commit fda6079b30a4 ("add jshn") also included the
necessary code to perform character set normalisation while building
variable names, which is triggered when loading files with 'jshn -R
file.json'. While add_json_element() will normalise key names, it will
not produce the key names lookup variables, as this concept had not been
introduced yet.
The former change resulted in double name normalisation being performed
when loading an existing file into the environment, causing the original
key name to be replaced by its normalised version:
# cat board.json
{
"network-device": {
"foo": "bar"
}
}
# /usr/bin/jshn -R board.json
json_init;
json_add_object 'network_device';
json_add_string 'foo' 'bar';
json_close_object;
By removing key normalisation from jshn.c, _json_add_generic() now has
the required information again to correctly store the original key,
ensuring repeated operations of 'jshn -R' and 'jshn -o' do not modify
the original JSON file (modulo formatting).
Fixes: a1a97eb11e89 ("jshn: support using characters in elements that do not
conform to shell variable restrictions")
Signed-off-by: Sander Vanheule
---
This issue was uncovered by the people debugging a recent issue on
Realtek switches [1]. A JSON section was used with the name
'network-device'. As per the above description, this would be normalised
to 'network_device'. The key name was correctly stored, as long as the
file adding that section (02_network) was the last one to be run.
OpenWrt commit 4ebba8a05d09 ("realtek: add support for HPE
1920-8g-poe+") had added a file 03_gpio running after 02_network,
resulting a call to 'jshn -R' and silent normalisation of
'network-device' to 'network_device'.
The issue was fixed in OpenWrt and netifd by just always using the
normalised key version. Note that even with this change applied, there
is still no way with jshn to represent keys with the same normalisation
(e.g. 'foo-bar' and 'foo_bar') in one file. Fixing that would require
properly escaping key names in some way when building variable names.
[1] https://forum.openwrt.org/t/57875/2589
Cc: Christian Marangi
Cc: Felix Fietkau
Cc: Jan Hoffmann
Cc: Michael Weinrich
jshn.c | 10 +-
1 file changed, 1 insertion(+), 9 deletions(-)
diff --git a/jshn.c b/jshn.c
index 1b685e5fb0d8..97873a220d64 100644
--- a/jshn.c
+++ b/jshn.c
@@ -96,14 +96,6 @@ static void add_json_string(const char *str)
fwrite(ptr, len, 1, stdout);
}
-static void write_key_string(const char *key)
-{
- while (*key) {
- putc(isalnum(*key) ? *key : '_', stdout);
- key++;
- }
-}
-
static int add_json_element(const char *key, json_object *obj)
{
char *type;
@@ -135,7 +127,7 @@ static int add_json_element(const char *key, json_object
*obj)
}
fprintf(stdout, "json_add_%s '", type);
- write_key_string(key);
+ add_json_string(key);
switch (json_object_get_type(obj)) {
case json_type_object:
--
2.41.0
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] mac80211: add support for rtw88_8822bu
The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header. To mitigate this problem, the original message has been wrapped automatically by the mailing list software.--- Begin Message --- From: Alexis Lothoré Kernel 6.1 has introduced support for RTW8822BU network adapter, which is an USB variant of the rtw8822b 802.11ac chipset family. Build and install the corresponding module in the rtw88 package Signed-off-by: Alexis Lothoré --- This commit has been tested on Raspberry Pi 4 with an Archer T3U USB Nano Wifi dongle (8822BU). The resulting OpenWRT successfully acts as station or access point --- package/kernel/mac80211/realtek.mk | 12 +++- 1 file changed, 7 insertions(+), 5 deletions(-) diff --git a/package/kernel/mac80211/realtek.mk b/package/kernel/mac80211/realtek.mk index 9c143583265e..4c618e6257c7 100644 --- a/package/kernel/mac80211/realtek.mk +++ b/package/kernel/mac80211/realtek.mk @@ -21,8 +21,8 @@ config-y += RTL8XXXU_UNTESTED config-$(call config_package,rtl8723bs) += RTL8723BS config-y += STAGING -config-$(call config_package,rtw88) += RTW88 RTW88_CORE RTW88_PCI -config-y += RTW88_8822BE RTW88_8822CE RTW88_8723DE +config-$(call config_package,rtw88) += RTW88 RTW88_CORE RTW88_PCI RTW88_USB +config-y += RTW88_8822BE RTW88_8822BU RTW88_8822CE RTW88_8723DE config-$(CONFIG_PACKAGE_RTW88_DEBUG) += RTW88_DEBUG config-$(CONFIG_PACKAGE_RTW88_DEBUGFS) += RTW88_DEBUGFS @@ -168,18 +168,20 @@ endef define KernelPackage/rtw88 $(call KernelPackage/mac80211/Default) - TITLE:=Realtek RTL8822BE/RTL8822CE/RTL8723DE + TITLE:=Realtek RTL8822BE/RTL8822BU/RTL8822CE/RTL8723DE DEPENDS+= @(PCI_SUPPORT) +kmod-mac80211 +@DRIVER_11AC_SUPPORT FILES:=\ $(PKG_BUILD_DIR)/drivers/net/wireless/realtek/rtw88/rtw88_8822be.ko \ + $(PKG_BUILD_DIR)/drivers/net/wireless/realtek/rtw88/rtw88_8822bu.ko \ $(PKG_BUILD_DIR)/drivers/net/wireless/realtek/rtw88/rtw88_8822b.ko \ $(PKG_BUILD_DIR)/drivers/net/wireless/realtek/rtw88/rtw88_8822ce.ko \ $(PKG_BUILD_DIR)/drivers/net/wireless/realtek/rtw88/rtw88_8822c.ko \ $(PKG_BUILD_DIR)/drivers/net/wireless/realtek/rtw88/rtw88_8723de.ko \ $(PKG_BUILD_DIR)/drivers/net/wireless/realtek/rtw88/rtw88_8723d.ko \ $(PKG_BUILD_DIR)/drivers/net/wireless/realtek/rtw88/rtw88_core.ko \ - $(PKG_BUILD_DIR)/drivers/net/wireless/realtek/rtw88/rtw88_pci.ko - AUTOLOAD:=$(call AutoProbe,rtw88_8822be rtw88_8822ce rtw88_8723de) + $(PKG_BUILD_DIR)/drivers/net/wireless/realtek/rtw88/rtw88_pci.ko \ + $(PKG_BUILD_DIR)/drivers/net/wireless/realtek/rtw88/rtw88_usb.ko + AUTOLOAD:=$(call AutoProbe,rtw88_8822be rtw88_8822bu rtw88_8822ce rtw88_8723de) endef define KernelPackage/rtl8723bs -- 2.42.0 --- End Message --- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
