Re: [PATCH] mvebu: add support for MACCHIATObin Single Shot
Hi, The included device tree file is for the Double Shot only, so it should work there. We need a seperate Image for the Single Shot with the correct device tree file so the SFP+ Ports will work. Thanks a lot Alexandra > Am 09.07.2020 um 21:59 schrieb m...@adrianschmutzler.de: > > Hi, > >> -Original Message- >> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org] >> On Behalf Of Tomasz Maciej Nowak >> Sent: Donnerstag, 9. Juli 2020 21:16 >> To: openwrt-devel@lists.openwrt.org >> Cc: Alexandra Alth >> Subject: [PATCH] mvebu: add support for MACCHIATObin Single Shot >> >> The currently supported Double Shot variant provides dts which is not >> entirely compatible with Single Shot variant. The symptoms are that SFP >> ports are not working. To remedy this, add two images to distinguish both >> boards, wich have proper dtb assigned. >> >> Reported-by: Alexandra Alth >> Signed-off-by: Tomasz Maciej Nowak >> --- >> target/linux/mvebu/image/cortexa72.mk | 20 ++-- >> 1 file changed, 18 insertions(+), 2 deletions(-) >> >> diff --git a/target/linux/mvebu/image/cortexa72.mk >> b/target/linux/mvebu/image/cortexa72.mk >> index 50233540ed2e..cab2ffcaa251 100644 >> --- a/target/linux/mvebu/image/cortexa72.mk >> +++ b/target/linux/mvebu/image/cortexa72.mk >> @@ -16,14 +16,30 @@ define Device/marvell_armada8040-db endef >> TARGET_DEVICES += marvell_armada8040-db >> >> -define Device/marvell_macchiatobin >> +define Device/marvell_macchiatobin-doubleshot >> $(call Device/Default-arm64) >> DEVICE_VENDOR := SolidRun >> DEVICE_MODEL := MACCHIATObin >> + DEVICE_VARIANT := Double Shot >> DEVICE_ALT0_VENDOR := SolidRun >> DEVICE_ALT0_MODEL := Armada 8040 Community Board >> + DEVICE_ALT0_VARIANT := Double Shot >> DEVICE_PACKAGES += kmod-i2c-mux-pca954x >> DEVICE_DTS := armada-8040-mcbin >> SUPPORTED_DEVICES := marvell,armada8040-mcbin endef - >> TARGET_DEVICES += marvell_macchiatobin >> +TARGET_DEVICES += marvell_macchiatobin-doubleshot >> + >> +define Device/marvell_macchiatobin-singleshot >> + $(call Device/Default-arm64) >> + DEVICE_VENDOR := SolidRun >> + DEVICE_MODEL := MACCHIATObin >> + DEVICE_VARIANT := Single Shot >> + DEVICE_ALT0_VENDOR := SolidRun >> + DEVICE_ALT0_MODEL := Armada 8040 Community Board >> + DEVICE_ALT0_VARIANT := Single Shot >> + DEVICE_PACKAGES += kmod-i2c-mux-pca954x >> + DEVICE_DTS := armada-8040-mcbin-singleshot >> + SUPPORTED_DEVICES := marvell,armada8040-mcbin-singleshot >> +endef >> +TARGET_DEVICES += marvell_macchiatobin-singleshot > > Kernel tells me that the compatible for these devices is > marvell,armada8040-mcbin-doubleshot > and > marvell,armada8040-mcbin-singleshot > > However, we seem to implement something different: > adsc@buildfff:/data/openwrt$ grep -rn "mcbin" target/linux/mvebu/ | sort > target/linux/mvebu/cortexa72/base-files/etc/board.d/02_network:14:marvell,armada8040-mcbin) > target/linux/mvebu/cortexa72/base-files/lib/upgrade/platform.sh:12: > marvell,armada8040-mcbin) > target/linux/mvebu/cortexa72/base-files/lib/upgrade/platform.sh:23: > marvell,armada8040-mcbin) > target/linux/mvebu/cortexa72/base-files/lib/upgrade/platform.sh:33: > marvell,armada8040-mcbin) > target/linux/mvebu/image/cortexa72.mk:26: DEVICE_DTS := armada-8040-mcbin > target/linux/mvebu/image/cortexa72.mk:27: SUPPORTED_DEVICES := > marvell,armada8040-mcbin > > So, ... > 1. is the current setup broken for the doubleshot already? > 2. If yes, the relevant sections seem to be updated for the singleshot as > well ... > > Best > > Adrian > > >> -- >> 2.27.0 >> >> >> ___ >> 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] mvebu: add support for MACCHIATObin Single Shot
Hi, > -Original Message- > From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org] > On Behalf Of Tomasz Maciej Nowak > Sent: Donnerstag, 9. Juli 2020 21:16 > To: openwrt-devel@lists.openwrt.org > Cc: Alexandra Alth > Subject: [PATCH] mvebu: add support for MACCHIATObin Single Shot > > The currently supported Double Shot variant provides dts which is not > entirely compatible with Single Shot variant. The symptoms are that SFP > ports are not working. To remedy this, add two images to distinguish both > boards, wich have proper dtb assigned. > > Reported-by: Alexandra Alth > Signed-off-by: Tomasz Maciej Nowak > --- > target/linux/mvebu/image/cortexa72.mk | 20 ++-- > 1 file changed, 18 insertions(+), 2 deletions(-) > > diff --git a/target/linux/mvebu/image/cortexa72.mk > b/target/linux/mvebu/image/cortexa72.mk > index 50233540ed2e..cab2ffcaa251 100644 > --- a/target/linux/mvebu/image/cortexa72.mk > +++ b/target/linux/mvebu/image/cortexa72.mk > @@ -16,14 +16,30 @@ define Device/marvell_armada8040-db endef > TARGET_DEVICES += marvell_armada8040-db > > -define Device/marvell_macchiatobin > +define Device/marvell_macchiatobin-doubleshot >$(call Device/Default-arm64) >DEVICE_VENDOR := SolidRun >DEVICE_MODEL := MACCHIATObin > + DEVICE_VARIANT := Double Shot >DEVICE_ALT0_VENDOR := SolidRun >DEVICE_ALT0_MODEL := Armada 8040 Community Board > + DEVICE_ALT0_VARIANT := Double Shot >DEVICE_PACKAGES += kmod-i2c-mux-pca954x >DEVICE_DTS := armada-8040-mcbin >SUPPORTED_DEVICES := marvell,armada8040-mcbin endef - > TARGET_DEVICES += marvell_macchiatobin > +TARGET_DEVICES += marvell_macchiatobin-doubleshot > + > +define Device/marvell_macchiatobin-singleshot > + $(call Device/Default-arm64) > + DEVICE_VENDOR := SolidRun > + DEVICE_MODEL := MACCHIATObin > + DEVICE_VARIANT := Single Shot > + DEVICE_ALT0_VENDOR := SolidRun > + DEVICE_ALT0_MODEL := Armada 8040 Community Board > + DEVICE_ALT0_VARIANT := Single Shot > + DEVICE_PACKAGES += kmod-i2c-mux-pca954x > + DEVICE_DTS := armada-8040-mcbin-singleshot > + SUPPORTED_DEVICES := marvell,armada8040-mcbin-singleshot > +endef > +TARGET_DEVICES += marvell_macchiatobin-singleshot Kernel tells me that the compatible for these devices is marvell,armada8040-mcbin-doubleshot and marvell,armada8040-mcbin-singleshot However, we seem to implement something different: adsc@buildfff:/data/openwrt$ grep -rn "mcbin" target/linux/mvebu/ | sort target/linux/mvebu/cortexa72/base-files/etc/board.d/02_network:14:marvell,armada8040-mcbin) target/linux/mvebu/cortexa72/base-files/lib/upgrade/platform.sh:12: marvell,armada8040-mcbin) target/linux/mvebu/cortexa72/base-files/lib/upgrade/platform.sh:23: marvell,armada8040-mcbin) target/linux/mvebu/cortexa72/base-files/lib/upgrade/platform.sh:33: marvell,armada8040-mcbin) target/linux/mvebu/image/cortexa72.mk:26: DEVICE_DTS := armada-8040-mcbin target/linux/mvebu/image/cortexa72.mk:27: SUPPORTED_DEVICES := marvell,armada8040-mcbin So, ... 1. is the current setup broken for the doubleshot already? 2. If yes, the relevant sections seem to be updated for the singleshot as well ... Best Adrian > -- > 2.27.0 > > > ___ > 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
[PATCH] mvebu: add support for MACCHIATObin Single Shot
The currently supported Double Shot variant provides dts which is not entirely compatible with Single Shot variant. The symptoms are that SFP ports are not working. To remedy this, add two images to distinguish both boards, wich have proper dtb assigned. Reported-by: Alexandra Alth Signed-off-by: Tomasz Maciej Nowak --- target/linux/mvebu/image/cortexa72.mk | 20 ++-- 1 file changed, 18 insertions(+), 2 deletions(-) diff --git a/target/linux/mvebu/image/cortexa72.mk b/target/linux/mvebu/image/cortexa72.mk index 50233540ed2e..cab2ffcaa251 100644 --- a/target/linux/mvebu/image/cortexa72.mk +++ b/target/linux/mvebu/image/cortexa72.mk @@ -16,14 +16,30 @@ define Device/marvell_armada8040-db endef TARGET_DEVICES += marvell_armada8040-db -define Device/marvell_macchiatobin +define Device/marvell_macchiatobin-doubleshot $(call Device/Default-arm64) DEVICE_VENDOR := SolidRun DEVICE_MODEL := MACCHIATObin + DEVICE_VARIANT := Double Shot DEVICE_ALT0_VENDOR := SolidRun DEVICE_ALT0_MODEL := Armada 8040 Community Board + DEVICE_ALT0_VARIANT := Double Shot DEVICE_PACKAGES += kmod-i2c-mux-pca954x DEVICE_DTS := armada-8040-mcbin SUPPORTED_DEVICES := marvell,armada8040-mcbin endef -TARGET_DEVICES += marvell_macchiatobin +TARGET_DEVICES += marvell_macchiatobin-doubleshot + +define Device/marvell_macchiatobin-singleshot + $(call Device/Default-arm64) + DEVICE_VENDOR := SolidRun + DEVICE_MODEL := MACCHIATObin + DEVICE_VARIANT := Single Shot + DEVICE_ALT0_VENDOR := SolidRun + DEVICE_ALT0_MODEL := Armada 8040 Community Board + DEVICE_ALT0_VARIANT := Single Shot + DEVICE_PACKAGES += kmod-i2c-mux-pca954x + DEVICE_DTS := armada-8040-mcbin-singleshot + SUPPORTED_DEVICES := marvell,armada8040-mcbin-singleshot +endef +TARGET_DEVICES += marvell_macchiatobin-singleshot -- 2.27.0 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] linux-firmware: package EIP197 mini firmware
Quoting part of original message from eefb5f741015 commit in linux-firmware repository: This adds the "minifw" version of the EIP197 firmware, which the inside- secure driver will use as a fallback if the original full-featured firmware cannot be found. This allows for using the inside-secure driver and hardware without access to "official" firmware only available under NDA. Signed-off-by: Tomasz Maciej Nowak --- package/firmware/linux-firmware/misc.mk | 9 + package/kernel/linux/modules/crypto.mk | 10 ++ 2 files changed, 15 insertions(+), 4 deletions(-) create mode 100644 package/firmware/linux-firmware/misc.mk diff --git a/package/firmware/linux-firmware/misc.mk b/package/firmware/linux-firmware/misc.mk new file mode 100644 index ..d0956f77b33b --- /dev/null +++ b/package/firmware/linux-firmware/misc.mk @@ -0,0 +1,9 @@ +Package/eip197-mini-firmware = $(call Package/firmware-default,Inside Secure EIP197 mini firmware) +define Package/eip197-mini-firmware/install + $(INSTALL_DIR) $(1)/lib/firmware/inside-secure/eip197_minifw + $(INSTALL_DATA) \ + $(PKG_BUILD_DIR)/inside-secure/eip197_minifw/ifpp.bin \ + $(PKG_BUILD_DIR)/inside-secure/eip197_minifw/ipue.bin \ + $(1)/lib/firmware/inside-secure/eip197_minifw +endef +$(eval $(call BuildPackage,eip197-mini-firmware)) diff --git a/package/kernel/linux/modules/crypto.mk b/package/kernel/linux/modules/crypto.mk index 900172179297..4864a8fa 100644 --- a/package/kernel/linux/modules/crypto.mk +++ b/package/kernel/linux/modules/crypto.mk @@ -377,7 +377,7 @@ $(eval $(call KernelPackage,crypto-hw-padlock)) define KernelPackage/crypto-hw-safexcel TITLE:= MVEBU SafeXcel Crypto Engine module - DEPENDS:=@!LINUX_4_14 @(TARGET_mvebu_cortexa53||TARGET_mvebu_cortexa72) \ + DEPENDS:=@!LINUX_4_14 @(TARGET_mvebu_cortexa53||TARGET_mvebu_cortexa72) +eip197-mini-firmware \ +kmod-crypto-authenc +kmod-crypto-md5 +kmod-crypto-hmac +kmod-crypto-sha256 +kmod-crypto-sha512 KCONFIG:= \ CONFIG_CRYPTO_HW=y \ @@ -392,9 +392,11 @@ MVEBU's EIP97 and EIP197 Cryptographic Engine driver designed by Inside Secure. This is found on Marvell Armada 37xx/7k/8k SoCs. Particular version of these IP (EIP197B and EIP197D) require firmware. -Unfortunately it's not freely available and needs signed Non-Disclosure -Agreement (NDA) with Marvell. For those who have signed NDA the firmware can be -obtained at https://extranet.marvell.com. +The mini firmware package provides limited functionality, for most operations +a full-featured firmware is required. Unfortunately the "full" firmware is not +freely available and needs signed Non-Disclosure Agreement (NDA) with Marvell. +For those who have signed NDA the firmware can be obtained at +https://extranet.marvell.com. endef $(eval $(call KernelPackage,crypto-hw-safexcel)) -- 2.27.0 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH 1/5] build: add DEVICE_COMPAT_VERSION and DEVICE_COMPAT_MESSAGE
We regularly encounter the situation that devices are subject to
changes that will make them incompatible to previous versions.
Removing SUPPORTED_DEVICES will not really be helpful in most of these
cases, as this only helps after a rename.
To solve this situation, this patchset introduces a compatibility
version for devices. It will be implemented via a per-device
Make variable DEVICE_COMPAT_VERSION, which will be set to 1.0
globally by default and then can be overwritten as needed.
Furthermore, a variable DEVICE_COMPAT_MESSAGE is added, where
a message to be displayed during sysupgrade may be specified
optionally.
This patch only implements the build variables and adds them
to the sysupgrade metadata, the evaluation will be addressed
in a subsequent patch.
To set it, one would just need to add the following to a device node:
define Device/somedevice
...
DEVICE_COMPAT_VERSION := 1.1
DEVICE_COMPAT_MESSAGE := Config cannot be migrated from swconfig to DSA
endef
Signed-off-by: Adrian Schmutzler
---
include/image-commands.mk | 7 +--
include/image.mk | 3 +++
2 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/include/image-commands.mk b/include/image-commands.mk
index e7db7128b4..9da712e733 100644
--- a/include/image-commands.mk
+++ b/include/image-commands.mk
@@ -384,13 +384,16 @@ define Build/tplink-v2-image
rm -rf $@.new
endef
+compat_version=$(if $(DEVICE_COMPAT_VERSION),$(DEVICE_COMPAT_VERSION),1.0)
json_quote=$(subst ','\'',$(subst ",\",$(1)))
#")')
metadata_devices=$(if $(1),$(subst "$(space)","$(comma)",$(strip $(foreach
v,$(1),"$(call json_quote,$(v))"
metadata_json = \
'{ $(if $(IMAGE_METADATA),$(IMAGE_METADATA)$(comma)) \
"metadata_version": "1.0", \
- "supported_devices":[$(call metadata_devices,$(1))], \
+ "compat_version": "$(call json_quote,$(compat_version))", \
+ $(if $(DEVICE_COMPAT_MESSAGE),"compat_message": "$(call
json_quote,$(DEVICE_COMPAT_MESSAGE))"$(comma)) \
+ "supported_devices":[$(call
metadata_devices,$(SUPPORTED_DEVICES))], \
"version": { \
"dist": "$(call json_quote,$(VERSION_DIST))", \
"version": "$(call json_quote,$(VERSION_NUMBER))", \
@@ -401,7 +404,7 @@ metadata_json = \
}'
define Build/append-metadata
- $(if $(SUPPORTED_DEVICES),-echo $(call
metadata_json,$(SUPPORTED_DEVICES)) | fwtool -I - $@)
+ $(if $(SUPPORTED_DEVICES),-echo $(call metadata_json) | fwtool -I - $@)
[ ! -s "$(BUILD_KEY)" -o ! -s "$(BUILD_KEY).ucert" -o ! -s "$@" ] || { \
cp "$(BUILD_KEY).ucert" "$@.ucert" ;\
usign -S -m "$@" -s "$(BUILD_KEY)" -x "$@.sig" ;\
diff --git a/include/image.mk b/include/image.mk
index 300f7a6619..dbdc820f4d 100644
--- a/include/image.mk
+++ b/include/image.mk
@@ -419,6 +419,8 @@ define Device/Init
BOARD_NAME :=
UIMAGE_NAME :=
+ DEVICE_COMPAT_VERSION := 1.0
+ DEVICE_COMPAT_MESSAGE :=
SUPPORTED_DEVICES :=
IMAGE_METADATA :=
@@ -435,6 +437,7 @@ DEFAULT_DEVICE_VARS := \
VID_HDR_OFFSET UBINIZE_OPTS UBINIZE_PARTS MKUBIFS_OPTS DEVICE_DTS \
DEVICE_DTS_CONFIG DEVICE_DTS_DIR SOC BOARD_NAME UIMAGE_NAME
SUPPORTED_DEVICES \
IMAGE_METADATA KERNEL_ENTRY KERNEL_LOADADDR UBOOT_PATH IMAGE_SIZE \
+ DEVICE_COMPAT_VERSION DEVICE_COMPAT_MESSAGE \
DEVICE_VENDOR DEVICE_MODEL DEVICE_VARIANT \
DEVICE_ALT0_VENDOR DEVICE_ALT0_MODEL DEVICE_ALT0_VARIANT \
DEVICE_ALT1_VENDOR DEVICE_ALT1_MODEL DEVICE_ALT1_VARIANT \
--
2.20.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH 2/5] base-files: add support for compat_version on device
We regularly encounter the situation that devices are subject to
changes that will make them incompatible to previous versions.
Removing SUPPORTED_DEVICES will not really be helpful in most of these
cases, as this only helps after a rename.
To solve this situation, this patchset introduces a compatibility
version for devices. To complement the DEVICE_COMPAT_VERSION set
for the image to be flashed, this implements a compat_version on
the device, so it will have something to compare with the image.
The only viable way to achieve this seems to be via board.d files,
i.e. this is technically adding a compat version for the device's
config.
Like for the network setup, this will set up a command
ucidef_set_compat_version to set the compat_version in board.d.
This will then add a string to /etc/board.json, which will be
translated into uci system config by bin/config_generate.
By this, the compat_version, being a version of the config, will
also be exposed to the user.
As with DEVICE_COMPAT_VERSION, missing uci entry will be assumed
as compat_version "1.0", so we only need to add this if a device
needs to be bumped, e.g.
ucidef_set_compat_version "1.1"
Signed-off-by: Adrian Schmutzler
---
package/base-files/files/bin/config_generate | 7 +++
package/base-files/files/lib/functions/uci-defaults.sh | 6 ++
2 files changed, 13 insertions(+)
diff --git a/package/base-files/files/bin/config_generate
b/package/base-files/files/bin/config_generate
index abb1388ba1..eb6816e519 100755
--- a/package/base-files/files/bin/config_generate
+++ b/package/base-files/files/bin/config_generate
@@ -264,6 +264,13 @@ generate_static_system() {
uci -q set
"system.@system[-1].hostname=$hostname"
fi
+ local compat_version
+ if json_get_var compat_version compat_version; then
+ uci -q set
"system.@system[-1].compat_version=$compat_version"
+ else
+ uci -q set
"system.@system[-1].compat_version=1.0"
+ fi
+
if json_is_a ntpserver array; then
local keys key
json_get_keys keys ntpserver
diff --git a/package/base-files/files/lib/functions/uci-defaults.sh
b/package/base-files/files/lib/functions/uci-defaults.sh
index 12b900031d..27a409fe3b 100755
--- a/package/base-files/files/lib/functions/uci-defaults.sh
+++ b/package/base-files/files/lib/functions/uci-defaults.sh
@@ -68,6 +68,12 @@ ucidef_set_model_name() {
json_select ..
}
+ucidef_set_compat_version() {
+ json_select_object system
+ json_add_string compat_version "${1:-1.0}"
+ json_select ..
+}
+
ucidef_set_interface_lan() {
ucidef_set_interface "lan" ifname "$1" protocol "${2:-static}"
}
--
2.20.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH 4/5] base-files: fwtool: make compat_version backward compatible
So far, the compatibility mechanism only works if both device and
image are already updated to the new routines. This patch extends
the sysupgrade metadata and fwtool_check_image() to account for
"older" images as well:
The basic mechanism for older devices to check for image compatibility
is the supported_devices entry. This can be exploited by putting
a custom message into this variable of the metadata, so older FW
will produce a mismatch and print the message as it thinks it's the
list of supported devices. So, we have two cases:
device 1.0, image 1.0:
The metadata will just contain supported_devices as before.
device 1.0, image 1.1:
The metadata will contain:
"new_supported_devices":["device_string1", "device_string2", ...],
"supported_devices":["Upgrade incompatible. Please check Wiki ..."]
If the device is "legacy", i.e. does not have the updated fwtool.sh,
it will just fail with image check and print the content of
supported_devices. Upgrade can still be performed with -F like when
SUPPORTED_DEVICES has been removed to prevent bricking.
If the device has updated fwtool.sh (but is 1.0), it will just use
the new_supported_devices instead, and work as intended (flashing
with -n will work, flashing without will print the appropriate
warning).
This mechanism should provide a fair tradeoff between simplicity
and functionality.
Signed-off-by: Adrian Schmutzler
---
include/image-commands.mk | 4 +++-
package/base-files/files/lib/upgrade/fwtool.sh | 7 ++-
2 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/include/image-commands.mk b/include/image-commands.mk
index 9da712e733..42e735314b 100644
--- a/include/image-commands.mk
+++ b/include/image-commands.mk
@@ -393,7 +393,9 @@ metadata_json = \
"metadata_version": "1.0", \
"compat_version": "$(call json_quote,$(compat_version))", \
$(if $(DEVICE_COMPAT_MESSAGE),"compat_message": "$(call
json_quote,$(DEVICE_COMPAT_MESSAGE))"$(comma)) \
- "supported_devices":[$(call
metadata_devices,$(SUPPORTED_DEVICES))], \
+ $(if $(filter-out
1.0,$(compat_version)),"new_supported_devices":[$(call
metadata_devices,$(SUPPORTED_DEVICES))]$(comma)) \
+ $(if $(filter-out
1.0,$(compat_version)),"supported_devices":["$(call json_quote,Upgrade
incompatible. Please check Wiki ...)"]$(comma)) \
+ $(if $(filter
1.0,$(compat_version)),"supported_devices":[$(call
metadata_devices,$(SUPPORTED_DEVICES))]$(comma)) \
"version": { \
"dist": "$(call json_quote,$(VERSION_DIST))", \
"version": "$(call json_quote,$(VERSION_NUMBER))", \
diff --git a/package/base-files/files/lib/upgrade/fwtool.sh
b/package/base-files/files/lib/upgrade/fwtool.sh
index dc064fee80..f622e8bd71 100644
--- a/package/base-files/files/lib/upgrade/fwtool.sh
+++ b/package/base-files/files/lib/upgrade/fwtool.sh
@@ -65,7 +65,12 @@ fwtool_check_image() {
return 1
fi
- json_select supported_devices || return 1
+ # select correct supported list based on compat_version
+ # (using this ensures that compatibility check works for devices
+ # not knowing about compat-version)
+ local supported=supported_devices
+ [ "$imagecompat" != "1.0" ] && supported=new_supported_devices
+ json_select $supported || return 1
json_get_keys dev_keys
for k in $dev_keys; do
--
2.20.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH 5/5] example: implement compat_version for devices
This is a stupid example of how the compat_version can be implemented. It's just for illustration and should not be used except for testing. While there is nothing remarkable to say about the DEVICE_COMPAT_* variables, note that the placement of the ucidef_set_compat_version variable is suboptimal in the example and might actually be done in a separate file or function. This also gives rise to interesting possibilities: If ath79 hadn't been introduced already, we could e.g. set ucidef_set_compat_version 1.1 in a default case for ath79, so all ar71xx devices would be required to upgrade without keeping settings... --- .../ath79/generic/base-files/etc/board.d/02_network | 12 ++-- target/linux/ath79/image/generic-tp-link.mk | 3 +++ 2 files changed, 13 insertions(+), 2 deletions(-) diff --git a/target/linux/ath79/generic/base-files/etc/board.d/02_network b/target/linux/ath79/generic/base-files/etc/board.d/02_network index f93d914374..1df6826e9e 100755 --- a/target/linux/ath79/generic/base-files/etc/board.d/02_network +++ b/target/linux/ath79/generic/base-files/etc/board.d/02_network @@ -167,11 +167,15 @@ ath79_setup_interfaces() dlink,dir-859-a1|\ engenius,epg5000|\ tplink,archer-c2-v3|\ - tplink,tl-wr1043nd-v4|\ tplink,tl-wr1043n-v5) ucidef_add_switch "switch0" \ "0@eth0" "1:lan:4" "2:lan:3" "3:lan:2" "4:lan:1" "5:wan" ;; + tplink,tl-wr1043nd-v4) + ucidef_add_switch "switch0" \ + "0@eth0" "1:lan:4" "2:lan:3" "3:lan:2" "4:lan:1" "5:wan" + ucidef_set_compat_version "2.0" + ;; elecom,wrc-1750ghbk2-i|\ elecom,wrc-300ghbk2-i|\ sitecom,wlr-8100) @@ -264,12 +268,16 @@ ath79_setup_interfaces() tplink,archer-c7-v4|\ tplink,archer-c7-v5|\ tplink,tl-wdr3600-v1|\ - tplink,tl-wdr4300-v1|\ tplink,tl-wdr4300-v1-il|\ tplink,tl-wdr4310-v1) ucidef_add_switch "switch0" \ "0@eth0" "2:lan:1" "3:lan:2" "4:lan:3" "5:lan:4" "1:wan" ;; + tplink,tl-wdr4300-v1) + ucidef_add_switch "switch0" \ + "0@eth0" "2:lan:1" "3:lan:2" "4:lan:3" "5:lan:4" "1:wan" + ucidef_set_compat_version "1.1" + ;; tplink,archer-c5-v1|\ tplink,archer-c7-v1|\ tplink,archer-c7-v2|\ diff --git a/target/linux/ath79/image/generic-tp-link.mk b/target/linux/ath79/image/generic-tp-link.mk index 967eb2a7c3..e18d6aad91 100644 --- a/target/linux/ath79/image/generic-tp-link.mk +++ b/target/linux/ath79/image/generic-tp-link.mk @@ -464,6 +464,7 @@ define Device/tplink_tl-wdr4300-v1 DEVICE_PACKAGES := kmod-usb2 kmod-usb-ledtrig-usbport TPLINK_HWID := 0x4301 SUPPORTED_DEVICES += tl-wdr4300 + DEVICE_COMPAT_VERSION := 1.1 endef TARGET_DEVICES += tplink_tl-wdr4300-v1 @@ -543,6 +544,8 @@ define Device/tplink_tl-wr1043nd-v4 TPLINK_HWID := 0x10430004 TPLINK_BOARD_ID := TLWR1043NDV4 SUPPORTED_DEVICES += tl-wr1043nd-v4 + DEVICE_COMPAT_VERSION := 2.0 + DEVICE_COMPAT_MESSAGE := The router cannot be updated because it will explode. Flash factory via TFTP instead. endef TARGET_DEVICES += tplink_tl-wr1043nd-v4 -- 2.20.1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH 3/5] base-files: fwtool: implement compatibility check for images
We regularly encounter the situation that devices are subject to
changes that will make them incompatible to previous versions.
Removing SUPPORTED_DEVICES will not really be helpful in most of these
cases, as this only helps after a rename.
To solve this situation, this patchset introduces a compatibility
version for devices. In this patch, the actual checks are implemented
into fwtool_check_image():
If an incompatible change is introduced, one can increase either
the minor version (1.0->1.1) or the major version (1.0->2.0).
Minor version increment:
This will still allow sysupgrade, but require to reset config
(-n or SAVE_CONFIG=0). If sysupgrade is called without -n, a
corresponding message will be printed. If sysupgrade is called
with -n, it will just pass, with supported devices being checked
as usual. (Which will allow us to add back SUPPORTED_DEVICES for
many cases.)
Major version increment:
This is meant for potential (rare) cases where sysupgrade is
not possible at all, because it would break the device.
In this case, a warning will be printed, and -n won't help.
If image check fails because of one of the versions parts not
matching, the content of DEVICE_COMPAT_MESSAGE is printed in
addition to the generic message (if set).
For both cases, upgrade can still be forced with -F as usual.
Signed-off-by: Adrian Schmutzler
---
.../base-files/files/lib/upgrade/fwtool.sh| 20 +++
1 file changed, 20 insertions(+)
diff --git a/package/base-files/files/lib/upgrade/fwtool.sh
b/package/base-files/files/lib/upgrade/fwtool.sh
index a0b3fb0a04..dc064fee80 100644
--- a/package/base-files/files/lib/upgrade/fwtool.sh
+++ b/package/base-files/files/lib/upgrade/fwtool.sh
@@ -44,6 +44,26 @@ fwtool_check_image() {
}
device="$(cat /tmp/sysinfo/board_name)"
+ devicecompat="$(uci -q get system.@system[0].compat_version)"
+ [ -n "$devicecompat" ] || devicecompat="1.0"
+
+ json_get_var imagecompat compat_version
+ json_get_var compatmessage compat_message
+ [ -n "$imagecompat" ] || imagecompat="1.0"
+
+ # major compat version -> no sysupgrade
+ if [ "${devicecompat%.*}" != "${imagecompat%.*}" ]; then
+ echo "This image is incompatible for sysupgrading based on the
image version."
+ [ -n "$compatmessage" ] && echo "$compatmessage"
+ return 1
+ fi
+
+ # minor compat version -> sysupgrade with -n required
+ if [ "${devicecompat#.*}" != "${imagecompat#.*}" ] && [ "$SAVE_CONFIG"
= "1" ]; then
+ echo "This config is incompatible to the new image. Please
upgrade with -n"
+ [ -n "$compatmessage" ] && echo "$compatmessage"
+ return 1
+ fi
json_select supported_devices || return 1
--
2.20.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH 0/5] sysupgrade: introduce compatibility version for devices
We regularly encounter the situation that devices are subject to changes that will make them incompatible to previous versions. Removing SUPPORTED_DEVICES will not really be helpful in most of these cases, as this only helps after a rename. To solve this situation, this patchset introduces a compatibility version for devices. It is implemented by a compat_version set for the device and in image metadata, where old images default to 1.0. If an incompatible change is introduced, one can increase either the minor version (1.0->1.1) or the major version (1.0->2.0). Minor version increment: This will still allow sysupgrade, but require to reset config (-n or SAVE_CONFIG=0). If sysupgrade is called without -n, a corresponding message will be printed. If sysupgrade is called with -n, it will just pass, with supported devices being checked as usual. (Which will allow us to add back SUPPORTED_DEVICES for many cases.) Major version increment: This is meant for potential (rare) cases where sysupgrade is not possible at all, because it would break the device. In this case, a warning will be printed, and -n won't help. If image check fails because of one of the versions parts not matching, the content of DEVICE_COMPAT_MESSAGE is printed in addition to the generic message (if set). For both cases, upgrade can still be forced with -F as usual. By a small trick, this is also applied in a way that will work sufficiently well for old devices not having the updated fwtool.sh I hope that this will allow to improve the update experience for incompatible changes beyond just removing SUPPORTED_DEVICES as it has been done in the past. This has been tested on device and appear to work. I have no idea what this will do with LuCI... Adrian Schmutzler (5): build: add DEVICE_COMPAT_VERSION and DEVICE_COMPAT_MESSAGE base-files: add support for compat_version on device base-files: fwtool: implement compatibility check for images base-files: fwtool: make compat_version backward compatible example: implement compat_version for devices include/image-commands.mk | 9 +-- include/image.mk | 3 +++ package/base-files/files/bin/config_generate | 7 + .../files/lib/functions/uci-defaults.sh | 6 + .../base-files/files/lib/upgrade/fwtool.sh| 27 ++- .../generic/base-files/etc/board.d/02_network | 12 +++-- target/linux/ath79/image/generic-tp-link.mk | 3 +++ 7 files changed, 62 insertions(+), 5 deletions(-) -- 2.20.1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] busybox: store applet usage messages uncompressed
Hi, Petr! On Thu, 9 Jul 2020 at 16:46, Petr Štetiar wrote: > > Numbers please! :) Here you go (compressed vs uncompressed): busybox (the executable): 364596 vs 384804 bytes. OpenWrt target images (the kernel image is unchanged, obviously): omnia-medkit-openwrt-mvebu-cortexa9-cznic_turris-omnia-initramfs.tar.gz: 9163597 vs 9162531 bytes (1066 bytes difference). openwrt-mvebu-cortexa9-cznic_turris-omnia-initramfs-kernel.bin: 9161688 vs 9160600 bytes (1088 bytes difference). openwrt-mvebu-cortexa9-cznic_turris-omnia-sysupgrade.img.gz: 9729550 vs 9729230 bytes (320 bytes difference). All in all, we save just a little bit over 1 kiB. As an added bonus, we also don't have to decompress the messages twice, (first from squashfs, then from the bzip2 message storage). Thanks, Rui ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
uboot-sunxi: SPI Flash support for Orange Pi R1. Need help with sysupgrade.bin image
Dear Mr. Mehrtens, I'd like install Openwrt on SPI Flash by Orange Pi R1 (without SD-Card). 1. uboot-sunxi with SPI Support. It was simple: ( https://github.com/u-boot/u-boot/pull/34 ... Yes, i know about u-boot patch rules. I'll do it later) 2. SPI Flash partitions. It was also easy. (Example: https://github.com/openwrt/openwrt/blob/f003d732d726758f11f0c308758637c434c37c1a/target/linux/sunxi/patches-4.19/400-arm64-allwinner-a64-sopine-Add-Sopine-flash-partitio.patch) 3. Prepare u-boot env rules (it should be also easy: https://linux-sunxi.org/Bootable_SPI_flash ) My problem is build a sysuprade.bin image. Right now the sunxi target use SD-Card images. And I have no idea how it should be implemented in target/linux/sunxi/image/Makefile Can you please provide me ? or maybe you know who can help me ? We need Orange Pi R1 SPI image for our Freifunk-Dresden community: https://gitlab.freifunk-dresden.de/firmware-developer/firmware/issues/56 Best regards Yaroslav Petrov ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] busybox: store applet usage messages uncompressed
Rui Salvaterra [2020-07-07 14:16:47]: > The rootfs squashfs is already highly (XZ) compressed. Storing the applet > messages in compressed form will increase the entropy and reduce the overall > image compression ratio. Numbers please! :) -- ynezz ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] busybox: disable SUSv2 compatibility by default
Hi, Henrique,
On Thu, 9 Jul 2020 at 14:27, Henrique de Moraes Holschuh
wrote:
>
> As you found yourself ("head -1", "tail -1"...), this is hard to access,
> and it is going to introduce (sometimes subtle) bugs in scripts not just
> from openwrt upstream, but also downstream and users.
>
> Unless you're saving a very large amount of FLASH with this change, it
> *really* isn't worth it. Not even for the 4MiB targets.
It's not worth it at all. On my config (-march=cortex-a9+neon -mthumb)
the difference is exactly 0 bytes (yes, really).
> Please reconsider.
Already did, please drop this for good.
Thanks,
Rui
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] treewide: switch head to SUSv3-style arguments
On 09/07/2020 10:19, Rui Salvaterra wrote: down this rabbit hole. Please disregard this patch, as well as the one I sent to change the default behaviour of BusyBox. It's just not worth the hassle and potential issues, at all. I do not oppose any patches to switch scripts to SuSv3 syntax: in the end the increase of a few bytes (use "-n1" instead of "-n 1" maybe) is but noise on the compressed image, might even reduce its size for all I know depending on what happens to the huffman dictionaries or equivalent. It is just the busybox removal of susv2 support that would cause trouble. -- Henrique de Moraes Holschuh ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] busybox: disable SUSv2 compatibility by default
On 08/07/2020 08:27, Rui Salvaterra wrote:
The Single UNIX Specification, Version 3, came out on the 30th January 2002 [1].
There's nothing in the OpenWrt userspace which needs support for legacy SUSv2
compatibility.
As you found yourself ("head -1", "tail -1"...), this is hard to access,
and it is going to introduce (sometimes subtle) bugs in scripts not just
from openwrt upstream, but also downstream and users.
Unless you're saving a very large amount of FLASH with this change, it
*really* isn't worth it. Not even for the 4MiB targets.
Please reconsider.
--
Henrique de Moraes Holschuh
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] treewide: switch head to SUSv3-style arguments
Hi, Henrique, On Thu, 9 Jul 2020 at 14:00, Henrique de Moraes Holschuh wrote: > > Unless the size savings are very high to justify it, it is probably a > very bad idea to disable SuS-v2 support in busybox. > > And it would need to be a sizeable reduction to be worth it indeed: as > you already noticed, some of it will be lost with compatibility syntax > changes. > > Removing SuSv2 from busybox is too damn likely to bite people badly > downstream. Please reconsider. This is *NOT* a "no-brainer" change, it > is a tidal wave that ripples down to everything that uses OpenWRT, every > feed, every downstream, and users. You are absolutely right, and I found it out the hard way by going down this rabbit hole. Please disregard this patch, as well as the one I sent to change the default behaviour of BusyBox. It's just not worth the hassle and potential issues, at all. Sorry for the noise, Rui ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] treewide: switch head to SUSv3-style arguments
On 09/07/2020 05:04, Rui Salvaterra wrote: Before disabling support for SUSv2 by default on BusyBox, care must be taken to ensure the arguments are SUSv3-compliant. Make it so. Unless the size savings are very high to justify it, it is probably a very bad idea to disable SuS-v2 support in busybox. And it would need to be a sizeable reduction to be worth it indeed: as you already noticed, some of it will be lost with compatibility syntax changes. Removing SuSv2 from busybox is too damn likely to bite people badly downstream. Please reconsider. This is *NOT* a "no-brainer" change, it is a tidal wave that ripples down to everything that uses OpenWRT, every feed, every downstream, and users. -- Henrique de Moraes Holschuh Analista de Projetos Centro de Estudos e Pesquisas em Tecnologias de Redes e Operações (Ceptro.br) +55 11 5509-3537 R.:4023 INOC 22548*625 www.nic.br ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] netifd: Ensure custom MTU is respected for bridges
When an interface is added or removed from a bridge, the kernel updates
the MTU to ETH_DATA_LEN or the minimum MTU of the ports (see
br_min_mtu() in net/bridge/br_if.c). netifd already works around this
behavior by updating the MTU when an interface is added to a bridge.
However, remove is not handled.
This commit introduces a new callback in the device-struct named
update_mtu. If the callback is set, it is called from cb_rtnl_event for
devices with a custom MTU.
The bridge code has been extended to make use of this callback. If the
MTU received from the kernel differs from the custom MTU, the MTU of the
bridge device is update. The callback covers both the case when a device
is added and removed (NEWLINK events are received in both cases), so the
old work-around is removed.
Signed-off-by: Kristian Evensen
---
bridge.c | 22 +-
device.h | 2 ++
system-linux.c | 3 +++
3 files changed, 18 insertions(+), 9 deletions(-)
diff --git a/bridge.c b/bridge.c
index c1f4ffa..8421366 100644
--- a/bridge.c
+++ b/bridge.c
@@ -304,15 +304,9 @@ bridge_member_cb(struct device_user *dev, enum
device_event ev)
if (bst->n_present == 1)
device_set_present(>dev, true);
- if (bst->dev.active && !bridge_enable_member(bm)) {
- /*
-* Adding a bridge member can overwrite the bridge mtu
-* in the kernel, apply the bridge settings in case the
-* bridge mtu is set
-*/
- system_if_apply_settings(>dev, >dev.settings,
-DEV_OPT_MTU | DEV_OPT_MTU6);
- }
+
+ if (bst->dev.active)
+ bridge_enable_member(bm);
break;
case DEV_EVENT_REMOVE:
@@ -710,6 +704,14 @@ bridge_retry_members(struct uloop_timeout *timeout)
}
}
+static void
+bridge_update_mtu(struct device *dev, uint32_t mtu)
+{
+ if (dev->settings.mtu != mtu || dev->settings.mtu6 != mtu)
+ system_if_apply_settings(dev, >settings, DEV_OPT_MTU |
+ DEV_OPT_MTU6);
+}
+
static struct device *
bridge_create(const char *name, struct device_type *devtype,
struct blob_attr *attr)
@@ -735,6 +737,8 @@ bridge_create(const char *name, struct device_type *devtype,
bst->set_state = dev->set_state;
dev->set_state = bridge_set_state;
+ dev->update_mtu = bridge_update_mtu;
+
dev->hotplug_ops = _ops;
vlist_init(>members, avl_strcmp, bridge_member_update);
diff --git a/device.h b/device.h
index 5f3fae2..382af81 100644
--- a/device.h
+++ b/device.h
@@ -25,6 +25,7 @@ struct device_hotplug_ops;
struct interface;
typedef int (*device_state_cb)(struct device *, bool up);
+typedef void (*device_mtu_cb)(struct device *, uint32_t mtu);
enum {
DEV_ATTR_TYPE,
@@ -213,6 +214,7 @@ struct device {
/* set interface up or down */
device_state_cb set_state;
+ device_mtu_cb update_mtu;
const struct device_hotplug_ops *hotplug_ops;
diff --git a/system-linux.c b/system-linux.c
index 3b09bbb..54a35d0 100644
--- a/system-linux.c
+++ b/system-linux.c
@@ -597,6 +597,9 @@ static int cb_rtnl_event(struct nl_msg *msg, void *arg)
device_set_link(dev, link_state ? true : false);
+ if (nla[IFLA_MTU] && (dev->settings.flags & DEV_OPT_MTU) &&
+ dev->update_mtu)
+ dev->update_mtu(dev, nla_get_u32(nla[IFLA_MTU]));
out:
return 0;
}
--
2.20.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
RE: [PATCH] build: put DT "compatible" value as "board_name" in profiles.json
> -Original Message- > From: Rafał Miłecki [mailto:ra...@milecki.pl] > Sent: Donnerstag, 9. Juli 2020 11:12 > To: Daniel Golle > Cc: Rafał Miłecki ; Paul Spooren ; > openwrt-devel@lists.openwrt.org; Adrian Schmutzler > ; Petr Štetiar ; Moritz > Warning ; Imre Kaloz > Subject: Re: [PATCH] build: put DT "compatible" value as "board_name" in > profiles.json > > On 2020-07-09 10:49, Daniel Golle wrote: > > On Wed, Jul 08, 2020 at 11:32:43PM +0200, Rafał Miłecki wrote: > >> On 08.07.2020 21:34, Paul Spooren wrote: > >> > I think there is a policy for new DT devices to use the compatible string > as profile. > >> > > >> > Multiple targets contain the following line in the target Makefile, which > automatically adds the profile name as supported device: > >> > > >> > SUPPORTED_DEVICES := $(subst _,$(comma),$(1)) > >> > > >> > So ideally for all devices using DT, the profile and compatible string > >> > are > the same except for '_' replaced by ','. > >> > > >> > For instance, the "Linksys WRT3200ACM" has the profile ID > `linksys_wrt3200acm` and the automatically added compatible string > `linksys,wrt3200acm`. So if that device wanted to search the > `mvebu/cortexa9/profiles.json` for available sysupgrades, it takes the first > entry from /proc/device-tree/compatible, replaces ',' with '_' find images in > profiles.json['profiles']['linksys_wrt3200acm']['images']. > >> > > >> > For cases where DT compatible and OpenWrt profile ID/name where > different either one was patched[0]. > >> > >> There are still few exceptions like: > >> linksys-ea9500 vs. compatible = "linksys,panamera" > >> luxul-xwr-3150 vs. compatible = "luxul,xwr-3150-v1" > >> luxul-xbr-4500 vs. compatible = "luxul,xbr-4500-v1" Essentially, we should be able to exploit SUPPORTED_DEVICES for that. Even if there is no sysupgrade with metadata available on the target, the SUPPORTED_DEVICES could indicate which board names would be possible for upgrade. This would also enable the possibility of a 1:n relationship (instead of a 1:1), i.e. one profile might be used for multiple "board names" (e.g. if you look at x86). The problem will arise from the opposite situation: e.g. in ar71xx, the same board name might be used for many profiles. With a board-name-based approach, we will never be able to support these for auto-upgrade or similar. However, I think ar71xx has been the last target that does this to a big extent. There are rare cases where the same DTS is used for more than one profile, but I think we can just ignore those for the moment. However, if we exploit the board name for that purpose, we should be aware that we move its use away from the initial intention (as in ar71xx, where it really described a board, not a device). I'm fine with that, as that's what I'm trying to enforce lately anyway, but not everyone might be. The implementation of "proper" board names for the non-DT targets then is not much more than some boring work to do (though e.g. bcm47xx could actually benefit from it). Best Adrian > >> > >> This is a bit of problem because: > >> 1. I can't change "panamera" to "ea9500" as I was explicitly asked to > >>stick to "panamera" by Imre when upstreaming that DTS > > > > I agree we should respect the artistic preferences of contributors to > > some degree. > > However, in this case, is there any reason for that somehow secretive > > naming scheme beyond personal preference? > > Having a consistent and easy to understand codebase also weights a bit > > higher than that to me. > > For Linksys, as said, I was told by Imre to use that magic "paramera" > string. The only explanation I got was that it was "discussed for other > platforms". For reference, see: > > [PATCH] ARM: dts: BCM5301X: Add basic DT for Linksys EA9500 > https://patchwork.kernel.org/patch/9588095/ > > For Luxul devices "-v1" suffix was initially used (during development) and > later it was decided V2 won't ever appear. So filename got simplified. 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: [PATCH] build: put DT "compatible" value as "board_name" in profiles.json
On 2020-07-09 10:49, Daniel Golle wrote: On Wed, Jul 08, 2020 at 11:32:43PM +0200, Rafał Miłecki wrote: On 08.07.2020 21:34, Paul Spooren wrote: > I think there is a policy for new DT devices to use the compatible string as profile. > > Multiple targets contain the following line in the target Makefile, which automatically adds the profile name as supported device: > > SUPPORTED_DEVICES := $(subst _,$(comma),$(1)) > > So ideally for all devices using DT, the profile and compatible string are the same except for '_' replaced by ','. > > For instance, the "Linksys WRT3200ACM" has the profile ID `linksys_wrt3200acm` and the automatically added compatible string `linksys,wrt3200acm`. So if that device wanted to search the `mvebu/cortexa9/profiles.json` for available sysupgrades, it takes the first entry from /proc/device-tree/compatible, replaces ',' with '_' find images in profiles.json['profiles']['linksys_wrt3200acm']['images']. > > For cases where DT compatible and OpenWrt profile ID/name where different either one was patched[0]. There are still few exceptions like: linksys-ea9500 vs. compatible = "linksys,panamera" luxul-xwr-3150 vs. compatible = "luxul,xwr-3150-v1" luxul-xbr-4500 vs. compatible = "luxul,xbr-4500-v1" This is a bit of problem because: 1. I can't change "panamera" to "ea9500" as I was explicitly asked to stick to "panamera" by Imre when upstreaming that DTS I agree we should respect the artistic preferences of contributors to some degree. However, in this case, is there any reason for that somehow secretive naming scheme beyond personal preference? Having a consistent and easy to understand codebase also weights a bit higher than that to me. For Linksys, as said, I was told by Imre to use that magic "paramera" string. The only explanation I got was that it was "discussed for other platforms". For reference, see: [PATCH] ARM: dts: BCM5301X: Add basic DT for Linksys EA9500 https://patchwork.kernel.org/patch/9588095/ For Luxul devices "-v1" suffix was initially used (during development) and later it was decided V2 won't ever appear. So filename got simplified. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] mediatek: fix bashism in gen_banana_pi_img.sh
There was a bashism in the script. This fixes the script so that it
doesn't actually require bash, and can be run with any POSIX shell as
its shebang suggests.
Signed-off-by: David Woodhouse
---
Oops, didn't realise that 'function' was a bashism too.
target/linux/mediatek/image/gen_banana_pi_img.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/target/linux/mediatek/image/gen_banana_pi_img.sh
b/target/linux/mediatek/image/gen_banana_pi_img.sh
index 26fbca1388..d46e92fa42 100755
--- a/target/linux/mediatek/image/gen_banana_pi_img.sh
+++ b/target/linux/mediatek/image/gen_banana_pi_img.sh
@@ -78,7 +78,7 @@
# The contents of the main eMMC are identical to the SD card layout,
# with the preloader loading 512KiB of U-Boot starting at 0x5.
-function usage() {
+usage() {
echo "SYNTAX: $0 sd
"
echo " OR:$0 emmc "
exit 1
smime.p7s
Description: S/MIME cryptographic signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: source definition in package stubby
On 7/9/20 10:40 AM, Moritz Warning wrote: > On 7/9/20 8:46 AM, e9hack wrote: >> Am 09.07.2020 um 08:36 schrieb e9hack: >>> Hi, >>> >>> something in the source definition of package stubby is wrong. The build >>> process tries to download >>> https://github.com/getdnsapi/stubby/stubby-0.3.0.tar.xz but the real >>> download location is >>> https://github.com/getdnsapi/stubby/archive/stubby-0.3.0.tar.gz. It fails >>> and it builds its own source package from git checkout. For checkout no >>> hash is used. The given hash from Makefile is never used. I can change the >>> hash to what I want. The build process doesn't complain about a wrong hash. >>> >>> Regards, >>> Hartmut >>> >> >> Sorry the download path is >> https://github.com/getdnsapi/stubby/archive/v0.3.0.tar.gz which results in >> downloading of stubby-0.3.0.tar.gz from somewhere in the github code cloud. >> >> Regards, >> Hartmut >> >> ___ >> openwrt-devel mailing list >> openwrt-devel@lists.openwrt.org >> https://lists.openwrt.org/mailman/listinfo/openwrt-devel >> > >>From what I see in include/download.mk, if dl_github_archive.py fails (e.g. >>due to a PKG_MIRROR_HASH mismatch), then DownloadMethod/rawgit is used - >>which does not check the hash but is fine if the sha1 commit id is valid. > This does not look good, since the commit hash is not meant to be a security > guarantee. No? The stubby package does not even have a commit hash, but a git tag (PKG_SOURCE_VERSION:=v$(PKG_VERSION)). That means, the git tag can be changed by the source repository and openwrt won't complain. :/ > > best, > mwarning > > ___ > 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] build: put DT "compatible" value as "board_name" in profiles.json
On Wed, Jul 08, 2020 at 11:32:43PM +0200, Rafał Miłecki wrote: > On 08.07.2020 21:34, Paul Spooren wrote: > > I think there is a policy for new DT devices to use the compatible string > > as profile. > > > > Multiple targets contain the following line in the target Makefile, which > > automatically adds the profile name as supported device: > > > > SUPPORTED_DEVICES := $(subst _,$(comma),$(1)) > > > > So ideally for all devices using DT, the profile and compatible string are > > the same except for '_' replaced by ','. > > > > For instance, the "Linksys WRT3200ACM" has the profile ID > > `linksys_wrt3200acm` and the automatically added compatible string > > `linksys,wrt3200acm`. So if that device wanted to search the > > `mvebu/cortexa9/profiles.json` for available sysupgrades, it takes the > > first entry from /proc/device-tree/compatible, replaces ',' with '_' find > > images in profiles.json['profiles']['linksys_wrt3200acm']['images']. > > > > For cases where DT compatible and OpenWrt profile ID/name where different > > either one was patched[0]. > > There are still few exceptions like: > linksys-ea9500 vs. compatible = "linksys,panamera" > luxul-xwr-3150 vs. compatible = "luxul,xwr-3150-v1" > luxul-xbr-4500 vs. compatible = "luxul,xbr-4500-v1" > > This is a bit of problem because: > 1. I can't change "panamera" to "ea9500" as I was explicitly asked to >stick to "panamera" by Imre when upstreaming that DTS I agree we should respect the artistic preferences of contributors to some degree. However, in this case, is there any reason for that somehow secretive naming scheme beyond personal preference? Having a consistent and easy to understand codebase also weights a bit higher than that to me. Cheers Daniel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: source definition in package stubby
On 7/9/20 8:46 AM, e9hack wrote: > Am 09.07.2020 um 08:36 schrieb e9hack: >> Hi, >> >> something in the source definition of package stubby is wrong. The build >> process tries to download >> https://github.com/getdnsapi/stubby/stubby-0.3.0.tar.xz but the real >> download location is >> https://github.com/getdnsapi/stubby/archive/stubby-0.3.0.tar.gz. It fails >> and it builds its own source package from git checkout. For checkout no hash >> is used. The given hash from Makefile is never used. I can change the hash >> to what I want. The build process doesn't complain about a wrong hash. >> >> Regards, >> Hartmut >> > > Sorry the download path is > https://github.com/getdnsapi/stubby/archive/v0.3.0.tar.gz which results in > downloading of stubby-0.3.0.tar.gz from somewhere in the github code cloud. > > Regards, > Hartmut > > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel > >From what I see in include/download.mk, if dl_github_archive.py fails (e.g. >due to a PKG_MIRROR_HASH mismatch), then DownloadMethod/rawgit is used - which >does not check the hash but is fine if the sha1 commit id is valid. This does not look good, since the commit hash is not meant to be a security guarantee. No? best, mwarning ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] treewide: switch head to SUSv3-style arguments
Before disabling support for SUSv2 by default on BusyBox, care must be taken to
ensure the arguments are SUSv3-compliant. Make it so.
Signed-off-by: Rui Salvaterra
---
package/base-files/files/lib/preinit/02_sysinfo | 2 +-
package/base-files/files/lib/preinit/99_10_failsafe_login | 2 +-
package/utils/busybox/config/init/Config.in | 2 +-
target/linux/ar71xx/image/lzma-loader/src/Makefile| 2 +-
target/linux/ath79/image/lzma-loader/src/Makefile | 2 +-
target/linux/bcm63xx/image/lzma-loader/src/Makefile | 2 +-
...-sch_cake-Permit-use-of-connmarks-as-tin-classifiers.patch | 4 ++--
target/linux/generic/image/lzma-loader/src/Makefile | 2 +-
target/linux/generic/image/relocate/Makefile | 2 +-
target/linux/mvebu/cortexa53/base-files/lib/upgrade/uDPU.sh | 2 +-
target/linux/ramips/image/lzma-loader/src/Makefile| 2 +-
11 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/package/base-files/files/lib/preinit/02_sysinfo
b/package/base-files/files/lib/preinit/02_sysinfo
index 65b50968e2..45eba73eca 100644
--- a/package/base-files/files/lib/preinit/02_sysinfo
+++ b/package/base-files/files/lib/preinit/02_sysinfo
@@ -2,7 +2,7 @@ do_sysinfo_generic() {
[ -d /proc/device-tree ] || return
mkdir -p /tmp/sysinfo
[ -e /tmp/sysinfo/board_name ] || \
- echo "$(strings /proc/device-tree/compatible | head -1)" >
/tmp/sysinfo/board_name
+ echo "$(strings /proc/device-tree/compatible | head -n 1)" >
/tmp/sysinfo/board_name
[ ! -e /tmp/sysinfo/model -a -e /proc/device-tree/model ] && \
echo "$(cat /proc/device-tree/model)" > /tmp/sysinfo/model
}
diff --git a/package/base-files/files/lib/preinit/99_10_failsafe_login
b/package/base-files/files/lib/preinit/99_10_failsafe_login
index 16ad84f4ba..f1faeac8c9 100644
--- a/package/base-files/files/lib/preinit/99_10_failsafe_login
+++ b/package/base-files/files/lib/preinit/99_10_failsafe_login
@@ -3,7 +3,7 @@
# Copyright (C) 2010 Vertical Communications
failsafe_shell() {
- local console="$(sed -e 's/ /\n/g' /proc/cmdline | grep '^console=' |
head -1 | sed -e 's/^console=//' -e 's/,.*//')"
+ local console="$(sed -e 's/ /\n/g' /proc/cmdline | grep '^console=' |
head -n 1 | sed -e 's/^console=//' -e 's/,.*//')"
[ -n "$console" ] || console=console
[ -c "/dev/$console" ] || return 0
while true; do
diff --git a/package/utils/busybox/config/init/Config.in
b/package/utils/busybox/config/init/Config.in
index fc6c916a68..8d5f8694c3 100644
--- a/package/utils/busybox/config/init/Config.in
+++ b/package/utils/busybox/config/init/Config.in
@@ -31,7 +31,7 @@ config BUSYBOX_CONFIG_FEATURE_BOOTCHARTD_BLOATED_HEADER
title = Boot chart for `hostname` (`date`)
system.uname = `uname -srvm`
system.release = `cat /etc/DISTRO-release`
- system.cpu = `grep '^model name' /proc/cpuinfo | head -1`
($cpucount)
+ system.cpu = `grep '^model name' /proc/cpuinfo | head -n 1`
($cpucount)
system.kernel.options = `cat /proc/cmdline`
This data is not mandatory for bootchart graph generation,
and is considered bloat. Nevertheless, this option
diff --git a/target/linux/ar71xx/image/lzma-loader/src/Makefile
b/target/linux/ar71xx/image/lzma-loader/src/Makefile
index 7773f027a2..a5aaccdf69 100644
--- a/target/linux/ar71xx/image/lzma-loader/src/Makefile
+++ b/target/linux/ar71xx/image/lzma-loader/src/Makefile
@@ -45,7 +45,7 @@ LDFLAGS = -static -Wl,--gc-sections
-Wl,-no-warn-mismatch
LDFLAGS+= -Wl,-e,startup -T loader.lds
-Wl,-Ttext,$(LZMA_TEXT_START)
LDFLAGS+= -flto -fwhole-program
-O_FORMAT = $(shell $(OBJDUMP) -i | head -2 | grep elf32)
+O_FORMAT = $(shell $(OBJDUMP) -i | head -n 2 | grep elf32)
OBJECTS:= head.o loader.o cache.o board.o printf.o LzmaDecode.o
diff --git a/target/linux/ath79/image/lzma-loader/src/Makefile
b/target/linux/ath79/image/lzma-loader/src/Makefile
index 7773f027a2..a5aaccdf69 100644
--- a/target/linux/ath79/image/lzma-loader/src/Makefile
+++ b/target/linux/ath79/image/lzma-loader/src/Makefile
@@ -45,7 +45,7 @@ LDFLAGS = -static -Wl,--gc-sections
-Wl,-no-warn-mismatch
LDFLAGS+= -Wl,-e,startup -T loader.lds
-Wl,-Ttext,$(LZMA_TEXT_START)
LDFLAGS+= -flto -fwhole-program
-O_FORMAT = $(shell $(OBJDUMP) -i | head -2 | grep elf32)
+O_FORMAT = $(shell $(OBJDUMP) -i | head -n 2 | grep elf32)
OBJECTS:= head.o loader.o cache.o board.o printf.o LzmaDecode.o
diff --git a/target/linux/bcm63xx/image/lzma-loader/src/Makefile
b/target/linux/bcm63xx/image/lzma-loader/src/Makefile
index 0310051a93..2fc5e4a5b0 100644
--- a/target/linux/bcm63xx/image/lzma-loader/src/Makefile
+++
Re: source definition in package stubby
Am 09.07.2020 um 08:36 schrieb e9hack: > Hi, > > something in the source definition of package stubby is wrong. The build > process tries to download > https://github.com/getdnsapi/stubby/stubby-0.3.0.tar.xz but the real download > location is https://github.com/getdnsapi/stubby/archive/stubby-0.3.0.tar.gz. > It fails and it builds its own source package from git checkout. For checkout > no hash is used. The given hash from Makefile is never used. I can change the > hash to what I want. The build process doesn't complain about a wrong hash. > > Regards, > Hartmut > Sorry the download path is https://github.com/getdnsapi/stubby/archive/v0.3.0.tar.gz which results in downloading of stubby-0.3.0.tar.gz from somewhere in the github code cloud. Regards, Hartmut ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
source definition in package stubby
Hi, something in the source definition of package stubby is wrong. The build process tries to download https://github.com/getdnsapi/stubby/stubby-0.3.0.tar.xz but the real download location is https://github.com/getdnsapi/stubby/archive/stubby-0.3.0.tar.gz. It fails and it builds its own source package from git checkout. For checkout no hash is used. The given hash from Makefile is never used. I can change the hash to what I want. The build process doesn't complain about a wrong hash. Regards, Hartmut ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
