[PATCH] sunxi: bring up DSA b53 switch on Lamobo R1

2021-09-10 Thread Daniel Golle
Build cortexa7 subtarget with DSA driver for MDIO-connected Broadcom
BCM53xxx switches. This is needed for the Lamobo R1 aka. BananaPi
BPi-R1 board which comes with such a switch IC.

Remove old swconfig driver from target kernel config as the only board
using it is now supported by the DSA driver.

No changes to device tree are needed as upstream DTS already got a
DSA switch definition and we are just using that upstream source.

Update default network config of the Lamobo R1 to create lan bridge
with all 4 lan ports.

Introduce DEVICE_COMPAT_VERSION for the board to inform users about
having the re-create their network configuration and add device alias
as Bananapi BPi-R1 while at it.

Signed-off-by: Daniel Golle 
---
 target/linux/sunxi/base-files/etc/board.d/02_network |  3 +--
 target/linux/sunxi/config-5.4|  4 
 target/linux/sunxi/cortexa7/config-5.4   | 12 
 target/linux/sunxi/image/cortexa7.mk |  5 -
 4 files changed, 17 insertions(+), 7 deletions(-)

diff --git a/target/linux/sunxi/base-files/etc/board.d/02_network 
b/target/linux/sunxi/base-files/etc/board.d/02_network
index 5b59333b1f..d5c615e7f2 100644
--- a/target/linux/sunxi/base-files/etc/board.d/02_network
+++ b/target/linux/sunxi/base-files/etc/board.d/02_network
@@ -11,8 +11,7 @@ friendlyarm,nanopi-r1)
ucidef_set_interfaces_lan_wan "eth1" "eth0"
;;
 lamobo,lamobo-r1)
-   ucidef_add_switch "switch0" \
-   "4:lan:1" "0:lan:2" "1:lan:3" "2:lan:4" "3:wan" "8@eth0"
+   ucidef_set_interfaces_lan_wan "lan1 lan2 lan3 lan4" wan
;;
 olimex,a20-olinuxino-micro)
ucidef_set_interface_lan "wlan0"
diff --git a/target/linux/sunxi/config-5.4 b/target/linux/sunxi/config-5.4
index 377234b828..e01a2cbd5e 100644
--- a/target/linux/sunxi/config-5.4
+++ b/target/linux/sunxi/config-5.4
@@ -523,10 +523,6 @@ CONFIG_SUNXI_SRAM=y
 CONFIG_SUNXI_WATCHDOG=y
 CONFIG_SUSPEND=y
 CONFIG_SUSPEND_FREEZER=y
-CONFIG_SWCONFIG=y
-CONFIG_SWCONFIG_B53=y
-CONFIG_SWCONFIG_B53_PHY_DRIVER=y
-CONFIG_SWCONFIG_B53_PHY_FIXUP=y
 CONFIG_SWIOTLB=y
 CONFIG_SWPHY=y
 CONFIG_SWP_EMULATE=y
diff --git a/target/linux/sunxi/cortexa7/config-5.4 
b/target/linux/sunxi/cortexa7/config-5.4
index 0b3697028f..4ead820881 100644
--- a/target/linux/sunxi/cortexa7/config-5.4
+++ b/target/linux/sunxi/cortexa7/config-5.4
@@ -13,3 +13,15 @@ CONFIG_MDIO_BUS_MUX=y
 # CONFIG_PINCTRL_SUN50I_H6 is not set
 # CONFIG_PINCTRL_SUN50I_H6_R is not set
 CONFIG_UNWINDER_ARM=y
+CONFIG_NET_DEVLINK=y
+CONFIG_NET_DSA=y
+CONFIG_NET_DSA_TAG_BRCM=y
+CONFIG_NET_DSA_TAG_BRCM_COMMON=y
+CONFIG_NET_DSA_TAG_BRCM_PREPEND=y
+CONFIG_NET_SWITCHDEV=y
+CONFIG_B53=y
+CONFIG_B53_MDIO_DRIVER=y
+# CONFIG_B53_MMAP_DRIVER is not set
+# CONFIG_B53_SERDES is not set
+# CONFIG_B53_SPI_DRIVER is not set
+# CONFIG_B53_SRAB_DRIVER is not set
diff --git a/target/linux/sunxi/image/cortexa7.mk 
b/target/linux/sunxi/image/cortexa7.mk
index 59f11bc83c..ac2dd1bc08 100644
--- a/target/linux/sunxi/image/cortexa7.mk
+++ b/target/linux/sunxi/image/cortexa7.mk
@@ -64,7 +64,10 @@ TARGET_DEVICES += friendlyarm_zeropi
 define Device/lamobo_lamobo-r1
   DEVICE_VENDOR := Lamobo
   DEVICE_MODEL := Lamobo R1
-  DEVICE_PACKAGES:=kmod-ata-sunxi kmod-rtl8192cu swconfig wpad-basic-wolfssl
+  DEVICE_ALT0_VENDOR := Bananapi
+  DEVICE_ALT0_MODEL := BPi-R1
+  DEVICE_PACKAGES := kmod-ata-sunxi kmod-rtl8192cu wpad-basic-wolfssl
+  DEVICE_COMPAT_VERSION := 2.0
   SOC := sun7i-a20
 endef
 TARGET_DEVICES += lamobo_lamobo-r1
-- 
2.33.0


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


Re: [PATCH] base-files: make os-release symbolic link absolute

2021-09-10 Thread Paul Spooren



On 9/9/21 19:53, Florian Eckert wrote:

* resolv.conf -> /tmp/resolv.conf
* /tmp/TZmtab -> /proc/mounts

For consistency, this should also apply to `/usr/lib/os-release`.


Is there any other reason than consistency to change this?


Yes, I have to elaborate on that.
I have a small script that boots the system into a called it "sandbox" 
mode.
If I do not save the sandbox config changes the system boots with old 
configuration.
This means that the changes to the configurations under /etc/ are not 
permanently saved, because I put a tmpfs over the /etc/.


For this to work, however, I have to copy the data somewhere else 
beforehand and then mount it.


mkdir -p /tmp/permetc
mount --bind /etc /tmp/permetc
mount -t tmpfs -o size="3M" none /etc
cp -r /tmp/permetc/* /etc

If you already run such script, can't you hard link os-release anyway?


Now I can configure the system as I need it. If I make a mistake, I 
can reboot the system and the old configuration will be reloaded.


So if I want to check what has changed (sandbox config vs. bootup 
config).

I display a diff with the command

diff -Naur /etc/permetc/ /etc

The problem now is that the file "../usr/lib/os-release" is always 
shown as not existing, because it is a relative path and the file 
under /tmp/permetc/../usr/lib/os-release/ does not exist.



I prefer relative links because they also work when the file system is
accessed by the build system like Paul said.


But if that is the case, could we not write the data into the target 
file under /usr/lib/os-release and not into the linked file?

This would make such simple changes possible.
The normal case should be that the folder structure should look like 
on the target system just as we need it.


By the way, this is the only link that is relative (at least on my 
system) all others are absolute.




Looking at this I'm wondering if there is a good reason to have the file 
twice? From my understanding there should be only a single place to have 
this file?




___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


Ramfs (and img build) compilation error

2021-09-10 Thread Ansuel Smith
Hi, i'm having some compilation error where it seems the buildroot
is using my host bin to compress the ramfs or img image. How can
I backtrack this error? I currently get this error if I change the compression
algo. Could there be a problem in detecting missing tools and
building them?

I'm 100% the buildroot is trying to use my host bin since it does complain
about "Not found" and if I install the missing tool, it then complain
for illegal
option. Is this intended?

Coincidentally now i'm building another target (from ipq806x to ath79) and this
time it started to build the lzma tools. Any hint about this?

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


[PATCH 1/2] bcm4908img: store offset of tail data

2021-09-10 Thread Rafał Miłecki
From: Rafał Miłecki 

This simplifies some operations as it doesn't have to be caculated over
and over. It will also allow adding support for more vendor formats.

Signed-off-by: Rafał Miłecki 
---
 package/utils/bcm4908img/Makefile |  2 +-
 package/utils/bcm4908img/src/bcm4908img.c | 23 +--
 2 files changed, 14 insertions(+), 11 deletions(-)

diff --git a/package/utils/bcm4908img/Makefile 
b/package/utils/bcm4908img/Makefile
index c18ac958f8..ff504a8078 100644
--- a/package/utils/bcm4908img/Makefile
+++ b/package/utils/bcm4908img/Makefile
@@ -3,7 +3,7 @@
 include $(TOPDIR)/rules.mk
 
 PKG_NAME:=bcm4908img
-PKG_RELEASE:=1
+PKG_RELEASE:=2
 
 PKG_FLAGS:=nonshared
 
diff --git a/package/utils/bcm4908img/src/bcm4908img.c 
b/package/utils/bcm4908img/src/bcm4908img.c
index 402d317190..f2023ced9f 100644
--- a/package/utils/bcm4908img/src/bcm4908img.c
+++ b/package/utils/bcm4908img/src/bcm4908img.c
@@ -79,11 +79,11 @@ struct bcm4908img_tail {
  * 6. BCM4908 tail
  */
 struct bcm4908img_info {
-   size_t file_size;
size_t cferom_offset;
size_t bootfs_offset;
size_t padding_offset;
size_t rootfs_offset;
+   size_t tail_offset;
uint32_t crc32; /* Calculated checksum */
struct bcm4908img_tail tail;
 };
@@ -219,7 +219,7 @@ static int bcm4908img_calc_crc32(FILE *fp, struct 
bcm4908img_info *info) {
fseek(fp, info->cferom_offset, SEEK_SET);
 
info->crc32 = 0x;
-   length = info->file_size - info->cferom_offset - sizeof(struct 
bcm4908img_tail);
+   length = info->tail_offset - info->cferom_offset;
while (length && (bytes = fread(buf, 1, bcm4908img_min(sizeof(buf), 
length), fp)) > 0) {
info->crc32 = bcm4908img_crc32(info->crc32, buf, bytes);
length -= bytes;
@@ -267,6 +267,7 @@ static int bcm4908img_parse(FILE *fp, struct 
bcm4908img_info *info) {
struct chk_header *chk;
struct stat st;
uint8_t buf[1024];
+   size_t file_size;
uint16_t tmp16;
size_t length;
size_t bytes;
@@ -281,7 +282,9 @@ static int bcm4908img_parse(FILE *fp, struct 
bcm4908img_info *info) {
fprintf(stderr, "Failed to fstat: %d\n", err);
return err;
}
-   info->file_size = st.st_size;
+   file_size = st.st_size;
+
+   info->tail_offset = file_size - sizeof(*tail);
 
/* Vendor formats */
 
@@ -297,7 +300,7 @@ static int bcm4908img_parse(FILE *fp, struct 
bcm4908img_info *info) {
/* Offsets */
 
for (info->bootfs_offset = info->cferom_offset;
-info->bootfs_offset < info->file_size;
+info->bootfs_offset < info->tail_offset;
 info->bootfs_offset += 0x2) {
if (fseek(fp, info->bootfs_offset, SEEK_SET)) {
err = -errno;
@@ -311,13 +314,13 @@ static int bcm4908img_parse(FILE *fp, struct 
bcm4908img_info *info) {
if (be16_to_cpu(tmp16) == 0x8519)
break;
}
-   if (info->bootfs_offset >= info->file_size) {
+   if (info->bootfs_offset >= info->tail_offset) {
fprintf(stderr, "Failed to find bootfs offset\n");
return -EPROTO;
}
 
for (info->rootfs_offset = info->bootfs_offset;
-info->rootfs_offset < info->file_size;
+info->rootfs_offset < info->tail_offset;
 info->rootfs_offset += 0x2) {
uint32_t *magic = (uint32_t *)&buf[0];
 
@@ -340,7 +343,7 @@ static int bcm4908img_parse(FILE *fp, struct 
bcm4908img_info *info) {
if (be32_to_cpu(*magic) == UBI_EC_HDR_MAGIC)
break;
}
-   if (info->rootfs_offset >= info->file_size) {
+   if (info->rootfs_offset >= info->tail_offset) {
fprintf(stderr, "Failed to find rootfs offset\n");
return -EPROTO;
}
@@ -351,7 +354,7 @@ static int bcm4908img_parse(FILE *fp, struct 
bcm4908img_info *info) {
fseek(fp, info->cferom_offset, SEEK_SET);
 
info->crc32 = 0x;
-   length = info->file_size - info->cferom_offset - sizeof(*tail);
+   length = info->tail_offset - info->cferom_offset;
while (length && (bytes = fread(buf, 1, bcm4908img_min(sizeof(buf), 
length), fp)) > 0) {
info->crc32 = bcm4908img_crc32(info->crc32, buf, bytes);
length -= bytes;
@@ -617,10 +620,10 @@ static int bcm4908img_extract(int argc, char **argv) {
length = (info.padding_offset ? info.padding_offset : 
info.rootfs_offset) - offset;
} else if (!strcmp(type, "rootfs")) {
offset = info.rootfs_offset;
-   length = info.file_size - offset - sizeof(struct 
bcm4908img_tail);
+   length = info.tail_offset - offset;
} else if (!strcmp(type, "firmware")) {
offset = info.bootfs_offset;
-   

[PATCH 2/2] bcm4908img: detect Linksys images

2021-09-10 Thread Rafał Miłecki
From: Rafał Miłecki 

Linksys uses an extra 0x100 bytes long tail for BCM4908 images.

Signed-off-by: Rafał Miłecki 
---
 package/utils/bcm4908img/Makefile |  2 +-
 package/utils/bcm4908img/src/bcm4908img.c | 22 ++
 2 files changed, 23 insertions(+), 1 deletion(-)

diff --git a/package/utils/bcm4908img/Makefile 
b/package/utils/bcm4908img/Makefile
index ff504a8078..fbb91fba73 100644
--- a/package/utils/bcm4908img/Makefile
+++ b/package/utils/bcm4908img/Makefile
@@ -3,7 +3,7 @@
 include $(TOPDIR)/rules.mk
 
 PKG_NAME:=bcm4908img
-PKG_RELEASE:=2
+PKG_RELEASE:=3
 
 PKG_FLAGS:=nonshared
 
diff --git a/package/utils/bcm4908img/src/bcm4908img.c 
b/package/utils/bcm4908img/src/bcm4908img.c
index f2023ced9f..240fe895d9 100644
--- a/package/utils/bcm4908img/src/bcm4908img.c
+++ b/package/utils/bcm4908img/src/bcm4908img.c
@@ -77,6 +77,7 @@ struct bcm4908img_tail {
  * 4. padding  ├─ firmware
  * 5. rootfs  ─┘
  * 6. BCM4908 tail
+ * 7. (Optional) vendor tail
  */
 struct bcm4908img_info {
size_t cferom_offset;
@@ -249,6 +250,16 @@ struct chk_header {
char board_id[0];
 };
 
+struct linksys_tail {
+   char magic[9];
+   uint8_t version[8];
+   char model[15];
+   uint32_t crc32;
+   uint8_t padding[9];
+   uint8_t signature[16];
+   uint8_t reserved[192];
+};
+
 static bool bcm4908img_is_all_ff(const void *buf, size_t length)
 {
const uint8_t *in = buf;
@@ -264,6 +275,7 @@ static bool bcm4908img_is_all_ff(const void *buf, size_t 
length)
 
 static int bcm4908img_parse(FILE *fp, struct bcm4908img_info *info) {
struct bcm4908img_tail *tail = &info->tail;
+   struct linksys_tail *linksys;
struct chk_header *chk;
struct stat st;
uint8_t buf[1024];
@@ -297,6 +309,16 @@ static int bcm4908img_parse(FILE *fp, struct 
bcm4908img_info *info) {
if (be32_to_cpu(chk->magic) == 0x2a23245e)
info->cferom_offset = be32_to_cpu(chk->header_len);
 
+   fseek(fp, -sizeof(buf), SEEK_END);
+   if (fread(buf, 1, sizeof(buf), fp) != sizeof(buf)) {
+   fprintf(stderr, "Failed to read file header\n");
+   return -EIO;
+   }
+   linksys = (void *)(buf + sizeof(buf) - sizeof(*linksys));
+   if (!memcmp(linksys->magic, ".LINKSYS.", sizeof(linksys->magic))) {
+   info->tail_offset -= sizeof(*linksys);
+   }
+
/* Offsets */
 
for (info->bootfs_offset = info->cferom_offset;
-- 
2.26.2


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


Re: [PATCH v3 2/6] at91: enable specific sam9x kernel config flags

2021-09-10 Thread claudiu via openwrt-devel
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 ---
On 09.09.2021 23:17, Hauke Mehrtens wrote:
> On 8/30/21 11:39 AM, Claudiu Beznea wrote:
>> Enable specific sam9x kernel config flags.
>>
>> Signed-off-by: Claudiu Beznea 
>> ---
>>   target/linux/at91/sam9x/config-default | 168 +++--
>>   1 file changed, 159 insertions(+), 9 deletions(-)
>>
> 
>> @@ -39,6 +44,7 @@ CONFIG_CLONE_BACKWARDS=y
>>   CONFIG_COMMON_CLK=y
>>   CONFIG_COMMON_CLK_AT91=y
>>   CONFIG_COMPAT_32BIT_TIME=y
>> +CONFIG_CONFIGFS_FS=m
> 
> Please remove the config options setting something to =m.
> This should only be done by packages in package/kernel/.
> This was done in multiple places.

OK, I'll do it in next version.

Thank you for your review,
Claudiu Beznea

> 
>>   CONFIG_CPU_32v4T=y
>>   CONFIG_CPU_32v5=y
>>   CONFIG_CPU_ABRT_EV4T=y
>> @@ -57,17 +63,34 @@ CONFIG_CPU_PABRT_LEGACY=y
> 


--- End Message ---
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


Re: [PATCH v3 1/6] at91: kernel: bump to 5.10

2021-09-10 Thread claudiu via openwrt-devel
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 ---
On 09.09.2021 22:52, Hauke Mehrtens wrote:
>> Bump at91 targets to kernel v5.10. With this patches and files for
>> wb45n and wb50n were removed as they are now included in upstream
>> kernel. Along with this:
>> - the kernel config for sam9x targets has been refreshed (with
>>    make kernel_menuconfig + save);
>> - CONFIG_ARCH_AT91 and specific sam9x SoCs (AT91RM9200, AT91SAM9,
>>    SAM9X60) has been enabled such that sam9x SoCs to be able to boot.
>>
>> Signed-off-by: Claudiu Beznea 
>> ---
>>   target/linux/at91/Makefile    |   2 +-
>>   .../at91/files/arch/arm/boot/dts/wb45n.dts    | 220 --
>>   .../at91/files/arch/arm/boot/dts/wb50n.dts    | 113 -
>>   .../at91/files/arch/arm/boot/dts/wb50n.dtsi   | 205 
>>   target/linux/at91/image/sam9x.mk  |   1 +
>>   target/linux/at91/image/sama5.mk  |   1 +
>>   .../101-ARM-at91-build-dtb-for-q5xr5.patch    |  10 +
>>   .../101-ARM-at91-build-dtb-for-q5xr5.patch    |  10 -
>>   .../102-ARM-at91-build-dtb-for-wb45n.patch    |  12 -
>>   ...2-ARM-at91-wb45n-fix-duplicate-label.patch |  20 --
>>   .../103-ARM-at91-build-dtb-for-wb50n.patch    |  12 -
>>   ...3-ARM-at91-wb50n-fix-duplicate-label.patch |  39 
>>   target/linux/at91/sam9x/config-default    | 105 -
>>   13 files changed, 57 insertions(+), 693 deletions(-)
>>   delete mode 100644 target/linux/at91/files/arch/arm/boot/dts/wb45n.dts
>>   delete mode 100644 target/linux/at91/files/arch/arm/boot/dts/wb50n.dts
>>   delete mode 100644 target/linux/at91/files/arch/arm/boot/dts/wb50n.dtsi
>>   create mode 04 target/linux/at91/patches-5.10
>>   create mode 100644
>> target/linux/at91/patches-5.10/101-ARM-at91-build-dtb-for-q5xr5.patch
>>   delete mode 04 target/linux/at91/patches-5.4
>>   delete mode 100644
>> target/linux/at91/patches-5.4/101-ARM-at91-build-dtb-for-q5xr5.patch
>>   delete mode 100644
>> target/linux/at91/patches-5.4/102-ARM-at91-build-dtb-for-wb45n.patch
>>   delete mode 100644
>> target/linux/at91/patches-5.4/102-ARM-at91-wb45n-fix-duplicate-label.patch
>>   delete mode 100644
>> target/linux/at91/patches-5.4/103-ARM-at91-build-dtb-for-wb50n.patch
>>   delete mode 100644
>> target/linux/at91/patches-5.4/103-ARM-at91-wb50n-fix-duplicate-label.patch
>>
> ..
>> -CONFIG_HAVE_REGS_AND_STACK_ACCESS_API=y
>> -CONFIG_HAVE_RSEQ=y
>> -CONFIG_HAVE_SYSCALL_TRACEPOINTS=y
>> -CONFIG_HAVE_UID16=y
>> -CONFIG_HAVE_VIRT_CPU_ACCOUNTING_GEN=y
>> -CONFIG_HZ_FIXED=0
>> +CONFIG_HZ=128
>> +CONFIG_HZ_FIXED=128
> 
> CONFIG_HZ=100 is set in the generic configuration, do you really need 128?

It is the result of doing make kernel_menuconfig + save as arch/arm/Kconfig
from Linux kernel tree has these lines:

config HZ_FIXED

int

default 128 if SOC_AT91RM9200

default 0


Since SOC_AT91RM9200 has been introduced in this commit (along with
SOC_AT91SAM9, SOC_SAM9X60) as the targets were not able to boot without
these config flags, the CONFIG_HZ_FIXED has been selected accordingly to 128.

The Linux commit that introduces this is:

commit 1164f672d71ac103d85207b0453f3127c0efefb3
Author: Alexandre Belloni 
Date:   Fri Mar 13 22:57:24 2015 +0100

ARM: at91: drop AT91_TIMER_HZ

Drop AT91_TIMER_HZ as this can be handled using HZ_FIXED. Initial help
message
was:

On AT91rm9200 chips where you're using a system clock derived
from the 32768 Hz hardware clock, this tick rate should divide
it exactly: use a power-of-two value, such as 128 or 256, to
reduce timing errors caused by rounding.

Signed-off-by: Alexandre Belloni 
Signed-off-by: Nicolas Ferre 

>From commit description seems better to keep it at 128.

Thank you,
Claudiu Beznea

--- End Message ---
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


Re: [PATCH v3 1/6] at91: kernel: bump to 5.10

2021-09-10 Thread claudiu via openwrt-devel
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 ---
On 09.09.2021 23:26, Hauke Mehrtens wrote:
> On 8/30/21 11:39 AM, Claudiu Beznea wrote:
>> Bump at91 targets to kernel v5.10. With this patches and files for
>> wb45n and wb50n were removed as they are now included in upstream
>> kernel. Along with this:
>> - the kernel config for sam9x targets has been refreshed (with
>>    make kernel_menuconfig + save);
>> - CONFIG_ARCH_AT91 and specific sam9x SoCs (AT91RM9200, AT91SAM9,
>>    SAM9X60) has been enabled such that sam9x SoCs to be able to boot.
>>
>> Signed-off-by: Claudiu Beznea 
>> ---
>>   target/linux/at91/Makefile    |   2 +-
>>   .../at91/files/arch/arm/boot/dts/wb45n.dts    | 220 --
>>   .../at91/files/arch/arm/boot/dts/wb50n.dts    | 113 -
>>   .../at91/files/arch/arm/boot/dts/wb50n.dtsi   | 205 
>>   target/linux/at91/image/sam9x.mk  |   1 +
>>   target/linux/at91/image/sama5.mk  |   1 +
>>   .../101-ARM-at91-build-dtb-for-q5xr5.patch    |  10 +
>>   .../101-ARM-at91-build-dtb-for-q5xr5.patch    |  10 -
>>   .../102-ARM-at91-build-dtb-for-wb45n.patch    |  12 -
>>   ...2-ARM-at91-wb45n-fix-duplicate-label.patch |  20 --
>>   .../103-ARM-at91-build-dtb-for-wb50n.patch    |  12 -
>>   ...3-ARM-at91-wb50n-fix-duplicate-label.patch |  39 
>>   target/linux/at91/sam9x/config-default    | 105 -
>>   13 files changed, 57 insertions(+), 693 deletions(-)
>>   delete mode 100644 target/linux/at91/files/arch/arm/boot/dts/wb45n.dts
>>   delete mode 100644 target/linux/at91/files/arch/arm/boot/dts/wb50n.dts
>>   delete mode 100644 target/linux/at91/files/arch/arm/boot/dts/wb50n.dtsi
>>   create mode 04 target/linux/at91/patches-5.10
>>   create mode 100644
>> target/linux/at91/patches-5.10/101-ARM-at91-build-dtb-for-q5xr5.patch
>>   delete mode 04 target/linux/at91/patches-5.4
>>   delete mode 100644
>> target/linux/at91/patches-5.4/101-ARM-at91-build-dtb-for-q5xr5.patch
>>   delete mode 100644
>> target/linux/at91/patches-5.4/102-ARM-at91-build-dtb-for-wb45n.patch
>>   delete mode 100644
>> target/linux/at91/patches-5.4/102-ARM-at91-wb45n-fix-duplicate-label.patch
>>   delete mode 100644
>> target/linux/at91/patches-5.4/103-ARM-at91-build-dtb-for-wb50n.patch
>>   delete mode 100644
>> target/linux/at91/patches-5.4/103-ARM-at91-wb50n-fix-duplicate-label.patch
>>
>> diff --git a/target/linux/at91/Makefile b/target/linux/at91/Makefile
>> index fe6a93244a5f..e4da7fb7e7da 100644
>> --- a/target/linux/at91/Makefile
>> +++ b/target/linux/at91/Makefile
>> @@ -10,7 +10,7 @@ BOARDNAME:=Microchip (Atmel AT91)
>>   FEATURES:=ext4 squashfs targz usb usbgadget ubifs
>>   SUBTARGETS:=sama5 sam9x
>>   -KERNEL_PATCHVER:=5.4
>> +KERNEL_PATCHVER:=5.10
>>     include $(INCLUDE_DIR)/target.mk
>>   
> Hi,
> 
> Is the sama5 subtarget still building after this change?

Hi! I just tested it again now, doing make distclean before, and its working.

> 
> I am surprise that there is no change to the
> target/linux/at91/sama5/config-default file done in this update from kernel
> 5.4 to 5.10.
> 
> Hauke


--- End Message ---
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


[PATCH v2 1/2] firmware-utils: tplink-safeloader: improve soft-version customisation

2021-09-10 Thread Sander Vanheule
Some devices using the safeloader firmware format require a minimum or
specific version to be set in the soft-version metadata partition.
Currently only custom text values can be provided, but not all device
firmware support this format.

Modify the device info struct to allow for more well-defined types of
soft-version overwrites, and provide a few macros for easy value
initialisation. Requires all existing values to be updated to match the
new structure.

Signed-off-by: Sander Vanheule 
---
v2: Rebase for PKG_RELEASE bump

 tools/firmware-utils/Makefile|   2 +-
 tools/firmware-utils/src/tplink-safeloader.c | 165 +++
 2 files changed, 94 insertions(+), 73 deletions(-)

diff --git a/tools/firmware-utils/Makefile b/tools/firmware-utils/Makefile
index ccc5e4609180..995fc79ece7e 100644
--- a/tools/firmware-utils/Makefile
+++ b/tools/firmware-utils/Makefile
@@ -7,7 +7,7 @@
 include $(TOPDIR)/rules.mk
 
 PKG_NAME := firmware-utils
-PKG_RELEASE := 10
+PKG_RELEASE := 11
 
 include $(INCLUDE_DIR)/host-build.mk
 include $(INCLUDE_DIR)/kernel.mk
diff --git a/tools/firmware-utils/src/tplink-safeloader.c 
b/tools/firmware-utils/src/tplink-safeloader.c
index dcc9d877a921..923cd865f64c 100644
--- a/tools/firmware-utils/src/tplink-safeloader.c
+++ b/tools/firmware-utils/src/tplink-safeloader.c
@@ -63,19 +63,40 @@ enum partition_trail_value {
PART_TRAIL_NONE = 0x100
 };
 
+/** soft-version value overwrite types
+ * The default (for an uninitialised soft_ver field) is to use the numerical
+ * version number "0.0.0"
+ */
+enum soft_ver_type {
+   SOFT_VER_TYPE_NUMERIC = 0,
+   SOFT_VER_TYPE_TEXT = 1,
+};
+
 /** Firmware layout description */
 struct device_info {
const char *id;
const char *vendor;
const char *support_list;
enum partition_trail_value part_trail;
-   const char *soft_ver;
+   struct {
+   enum soft_ver_type type;
+   union {
+   const char *text;
+   uint8_t num[3];
+   };
+   } soft_ver;
uint32_t soft_ver_compat_level;
struct flash_partition_entry partitions[MAX_PARTITIONS+1];
const char *first_sysupgrade_partition;
const char *last_sysupgrade_partition;
 };
 
+#define SOFT_VER_TEXT(_t) {.type = SOFT_VER_TYPE_TEXT, .text = _t}
+#define SOFT_VER_NUMERIC(_maj, _min, _patch) {  \
+   .type = SOFT_VER_TYPE_NUMERIC,  \
+   .num = {_maj, _min, _patch}}
+#define SOFT_VER_DEFAULT SOFT_VER_NUMERIC(0, 0, 0)
+
 struct __attribute__((__packed__)) meta_header {
uint32_t length;
uint32_t zero;
@@ -129,7 +150,7 @@ static struct device_info boards[] = {
"CPE220(TP-LINK|US|N300-2):1.1\r\n"
"CPE220(TP-LINK|EU|N300-2):1.1\r\n",
.part_trail = 0xff,
-   .soft_ver = NULL,
+   .soft_ver = SOFT_VER_DEFAULT,
 
.partitions = {
{"fs-uboot", 0x0, 0x2},
@@ -168,7 +189,7 @@ static struct device_info boards[] = {
"CPE210(TP-LINK|EU|N300-2):2.0\r\n"
"CPE210(TP-LINK|US|N300-2):2.0\r\n",
.part_trail = 0xff,
-   .soft_ver = NULL,
+   .soft_ver = SOFT_VER_DEFAULT,
 
.partitions = {
{"fs-uboot", 0x0, 0x2},
@@ -210,7 +231,7 @@ static struct device_info boards[] = {
"CPE210(TP-LINK|UN|N300-2|):3.20\r\n"
"CPE210(TP-LINK|US|N300-2|5553):3.20\r\n",
.part_trail = 0xff,
-   .soft_ver = NULL,
+   .soft_ver = SOFT_VER_DEFAULT,
 
.partitions = {
{"fs-uboot", 0x0, 0x2},
@@ -251,7 +272,7 @@ static struct device_info boards[] = {
"CPE220(TP-LINK|EU|N300-2):2.0\r\n"
"CPE220(TP-LINK|US|N300-2):2.0\r\n",
.part_trail = 0xff,
-   .soft_ver = NULL,
+   .soft_ver = SOFT_VER_DEFAULT,
 
.partitions = {
{"fs-uboot", 0x0, 0x2},
@@ -290,7 +311,7 @@ static struct device_info boards[] = {
"CPE220(TP-LINK|EU|N300-2):3.0\r\n"
"CPE220(TP-LINK|US|N300-2):3.0\r\n",
.part_trail = 0xff,
-   .soft_ver = NULL,
+   .soft_ver = SOFT_VER_DEFAULT,
 
.partitions = {
{"fs-uboot", 0x0, 0x2},
@@ -329,7 +350,7 @@ static struct device_info boards[] = {
"CPE520(TP-LINK|US|N300-5):1.1\r\n"
"CPE520(TP-LINK|EU|N300-5):1.1\r\n",
.part_trail = 0xff,
-   .soft_ver = NULL,
+   .soft_ver = SOFT_VER_DEFAULT,
 
.partitions = {
{"fs-uboot", 0x0, 0x2

[PATCH v2 0/2] Safeloader firmware images contain a soft-version partition, which encodes version info about the image. There are currently two formats: plain text and structured binary with the firmw

2021-09-10 Thread Sander Vanheule
Currently custom firmware version number values can only be provided if these
are text based. However, some device firmwares expect structured binary version
info, and do not support the plain text format.

The first patch implements a more flexible soft-version override system.
The second patch then changes the (structured) soft-version override for the
EAP235-WALL v1 to support recent vendor firmwares.

Series v1: 
https://lists.infradead.org/pipermail/openwrt-devel/2021-August/036170.html

Sander Vanheule (2):
  firmware-utils: tplink-safeloader: improve soft-version customisation
  firmware-utils: tplink-safeloader: set EAP235-Wall v1 soft-version

 tools/firmware-utils/Makefile|   2 +-
 tools/firmware-utils/src/tplink-safeloader.c | 165 +++
 2 files changed, 94 insertions(+), 73 deletions(-)

-- 
2.31.1


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


[PATCH v2 2/2] firmware-utils: tplink-safeloader: set EAP235-Wall v1 soft-version

2021-09-10 Thread Sander Vanheule
Starting with v3 of the vendor firmware for the TP-Link EAP235-Wall v1,
downgrades to firmware versions below v3 as not allowed.  Since OpenWrt
uses version 0.0.0 as a default, this causes the factory install to fail
on devices with a recent firmware. This failure is associated by the
following message on the device's serial console:

EAP235/230-Wall forbid fw reverted from 3.x.x to lower version!

Vendor firmware (v3) also uses build and release numbers to compare
images, so identical version numbers are very unlikely to cause issues.
Bump the firmware version to 3.0.0 to ensure users can install OpenWrt
on their devices.

Reported-by: Colton Conor 
Tested-by: Colton Conor 
Signed-off-by: Sander Vanheule 
---
v2: Add Colton Conor's tags

 tools/firmware-utils/src/tplink-safeloader.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/firmware-utils/src/tplink-safeloader.c 
b/tools/firmware-utils/src/tplink-safeloader.c
index 923cd865f64c..04a77fa079c9 100644
--- a/tools/firmware-utils/src/tplink-safeloader.c
+++ b/tools/firmware-utils/src/tplink-safeloader.c
@@ -1560,7 +1560,7 @@ static struct device_info boards[] = {
"SupportList:\r\n"
"EAP235-Wall(TP-Link|UN|AC1200-D):1.0\r\n",
.part_trail = PART_TRAIL_NONE,
-   .soft_ver = SOFT_VER_DEFAULT,
+   .soft_ver = SOFT_VER_NUMERIC(3, 0, 0),
.soft_ver_compat_level = 1,
 
.partitions = {
-- 
2.31.1


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel