date:20190831

Re: [OpenWrt-Devel] [PATCH procd] system: reject sysupgrade of broken firmware images

2019-08-31 Thread Reiner Karlsberg


This needs to be handled very carefully, not to break
actual usage of -F.
I had to use -F couple of times, usually when downgrading
installed firmware, but with change of name over time.
Typical example: Change of image name for the zbt-we826.
Never any problem with usage of -F, though.

But I had several problems with non-completion of
valid sysupgrade, which even left the system in inconsistent state,
as the "-f keep.tar.gz" was applied, but not the new image itself.
Or (silently ?) no sysupgrade done, because of mounted block device
or active swap file on block device, or active wifi (?).
Which was a PITA on remote installations.

Question: How are sysupgrade-errors reported/to be handled, as usually also a 
failed sysupgrade
triggered a reboot ?
documentation very unclear here, as it looks like, behaviour in case of errro 
changed during versions of openwrt.

Best would be "atomic sysupgrade", with standard error-code (+1) on exit 
instead of expected reboot after success.

I appreciate the new work on sysupgrade, but I am a bit afraid of regressions.



Am 01.09.2019 um 01:14 schrieb Karl Palsson:


What's the point of "force" if it doesn't force? Are we going to
add a second -F to "really force" ? Or is it going to be "oh, -F
failed for some lame reason, so I'll use mtd write, and still
complain anyway"

Cheers,
Karl P

Rafał Miłecki   wrote:

From: Rafał Miłecki 

This uses recently added "validate_firmware_image" to validate
passed firmware. If it happens to be invalid and marked as
impossible to force then sysupgrade simply exits with an error.

This change is needed to avoid bricking devices with some
totally broken images.

Signed-off-by: Rafał Miłecki 
---
This patch depends on the:
[PATCH procd] system: add "validate_firmware_image" ubus method
---
  system.c | 24 
  1 file changed, 24 insertions(+)

diff --git a/system.c b/system.c
index 35d5a23..7f49758 100644
--- a/system.c
+++ b/system.c
@@ -507,7 +507,18 @@ static int sysupgrade(struct ubus_context *ctx, struct 
ubus_object *obj,
  struct ubus_request_data *req, const char *method,
  struct blob_attr *msg)
  {
+   enum {
+   VALIDATION_VALID,
+   VALIDATION_FORCEABLE,
+   __VALIDATION_MAX
+   };
+   static const struct blobmsg_policy validation_policy[__VALIDATION_MAX] 
= {
+   [VALIDATION_VALID] = { .name = "valid", .type = 
BLOBMSG_TYPE_BOOL },
+   [VALIDATION_FORCEABLE] = { .name = "forceable", .type = 
BLOBMSG_TYPE_BOOL },
+   };
+   struct blob_attr *validation[__VALIDATION_MAX];
struct blob_attr *tb[__SYSUPGRADE_MAX];
+   bool valid, forceable;
  
  	if (!msg)

return UBUS_STATUS_INVALID_ARGUMENT;
@@ -516,6 +527,19 @@ static int sysupgrade(struct ubus_context *ctx, struct 
ubus_object *obj,
if (!tb[SYSUPGRADE_PATH] || !tb[SYSUPGRADE_PREFIX])
return UBUS_STATUS_INVALID_ARGUMENT;
  
+	if (validate_firmware_image_call(blobmsg_get_string(tb[SYSUPGRADE_PATH])))

+   return UBUS_STATUS_UNKNOWN_ERROR;
+
+   blobmsg_parse(validation_policy, __VALIDATION_MAX, validation, 
blob_data(b.head), blob_len(b.head));
+
+   valid = validation[VALIDATION_VALID] && 
blobmsg_get_bool(validation[VALIDATION_VALID]);
+   forceable = validation[VALIDATION_FORCEABLE] && 
blobmsg_get_bool(validation[VALIDATION_FORCEABLE]);
+
+   if (!valid && !forceable) {
+   fprintf(stderr, "Firmware image is broken and cannot be 
installed\n");
+   return UBUS_STATUS_UNKNOWN_ERROR;
+   }
+
sysupgrade_exec_upgraded(blobmsg_get_string(tb[SYSUPGRADE_PREFIX]),
 blobmsg_get_string(tb[SYSUPGRADE_PATH]),
 tb[SYSUPGRADE_COMMAND] ? 
blobmsg_get_string(tb[SYSUPGRADE_COMMAND]) : NULL,
--
2.21.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



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

Re: [OpenWrt-Devel] [PATCH procd] system: reject sysupgrade of broken firmware images

2019-08-31 Thread Karl Palsson


What's the point of "force" if it doesn't force? Are we going to
add a second -F to "really force" ? Or is it going to be "oh, -F
failed for some lame reason, so I'll use mtd write, and still
complain anyway"

Cheers,
Karl P

Rafał Miłecki   wrote:
> From: Rafał Miłecki 
> 
> This uses recently added "validate_firmware_image" to validate
> passed firmware. If it happens to be invalid and marked as
> impossible to force then sysupgrade simply exits with an error.
> 
> This change is needed to avoid bricking devices with some
> totally broken images.
> 
> Signed-off-by: Rafał Miłecki 
> ---
> This patch depends on the:
> [PATCH procd] system: add "validate_firmware_image" ubus method
> ---
>  system.c | 24 
>  1 file changed, 24 insertions(+)
> 
> diff --git a/system.c b/system.c
> index 35d5a23..7f49758 100644
> --- a/system.c
> +++ b/system.c
> @@ -507,7 +507,18 @@ static int sysupgrade(struct ubus_context *ctx, struct 
> ubus_object *obj,
> struct ubus_request_data *req, const char *method,
> struct blob_attr *msg)
>  {
> + enum {
> + VALIDATION_VALID,
> + VALIDATION_FORCEABLE,
> + __VALIDATION_MAX
> + };
> + static const struct blobmsg_policy validation_policy[__VALIDATION_MAX] 
> = {
> + [VALIDATION_VALID] = { .name = "valid", .type = 
> BLOBMSG_TYPE_BOOL },
> + [VALIDATION_FORCEABLE] = { .name = "forceable", .type = 
> BLOBMSG_TYPE_BOOL },
> + };
> + struct blob_attr *validation[__VALIDATION_MAX];
>   struct blob_attr *tb[__SYSUPGRADE_MAX];
> + bool valid, forceable;
>  
>   if (!msg)
>   return UBUS_STATUS_INVALID_ARGUMENT;
> @@ -516,6 +527,19 @@ static int sysupgrade(struct ubus_context *ctx, struct 
> ubus_object *obj,
>   if (!tb[SYSUPGRADE_PATH] || !tb[SYSUPGRADE_PREFIX])
>   return UBUS_STATUS_INVALID_ARGUMENT;
>  
> + if 
> (validate_firmware_image_call(blobmsg_get_string(tb[SYSUPGRADE_PATH])))
> + return UBUS_STATUS_UNKNOWN_ERROR;
> +
> + blobmsg_parse(validation_policy, __VALIDATION_MAX, validation, 
> blob_data(b.head), blob_len(b.head));
> +
> + valid = validation[VALIDATION_VALID] && 
> blobmsg_get_bool(validation[VALIDATION_VALID]);
> + forceable = validation[VALIDATION_FORCEABLE] && 
> blobmsg_get_bool(validation[VALIDATION_FORCEABLE]);
> +
> + if (!valid && !forceable) {
> + fprintf(stderr, "Firmware image is broken and cannot be 
> installed\n");
> + return UBUS_STATUS_UNKNOWN_ERROR;
> + }
> +
>   sysupgrade_exec_upgraded(blobmsg_get_string(tb[SYSUPGRADE_PREFIX]),
>blobmsg_get_string(tb[SYSUPGRADE_PATH]),
>tb[SYSUPGRADE_COMMAND] ? 
> blobmsg_get_string(tb[SYSUPGRADE_COMMAND]) : NULL,
> -- 
> 2.21.0
> 
> 
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel

OpenPGP-digital-signature.html
Description: OpenPGP Digital Signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH v3] ramips: add support for Xiaomi Mi Wi-Fi Router 3G v2

2019-08-31 Thread mail

Hi,

additional comments below.

> -Original Message-
> From: Paul Fertser [mailto:fercer...@gmail.com]
> Sent: Mittwoch, 28. August 2019 11:09
> To: John Crispin 
> Cc: openwrt-devel@lists.openwrt.org; Adrian Schmutzler
> ; Roger Pueyo Centelles
> ; Paul Fertser 
> Subject: [PATCH v3] ramips: add support for Xiaomi Mi Wi-Fi Router 3G v2
> 
> - CMIIT ID: 2019AP2581
> - SoC:  MediaTek MT7621
> - Flash:16MiB NOR SPI (GigaDevice GD25Q128B)
> - RAM:  128MiB DDR3 (ESMT M15T1G1664A)
> - Serial:   As marked on PCB, 3V3 logic, baudrate is 115200, 8n1
> - Ethernet: 3x 10/100/1000 Mbps (switched, 2xLAN + WAN)
> - WIFI0:MT7603E 2.4GHz 802.11b/g/n
> - WIFI1:MT7612E 5GHz 802.11ac
> - Antennas: 4x external (2 per radio), non-detachable
> - LEDs: Programmable "power" LED (two-coloured, yellow/blue)
> Non-programmable "internet" LED (shows WAN activity)
> - Buttons:  Reset
> 
> INSTALLATION:
> 
> Bootloader won't accept any serial input unless "boot_wait" u-boot
> environment variable is changed to "on". Vendor firmware (looks like an
> illegal OpenWrt fork) won't accept any serial input unless "uart_en" is set to
> "1". Tricks to force u-boot to use default environment do not help as it's
> restricted in the same way.
> 
> With bootloader unlocked the easiest way would be to TFTP the sysupgrade
> image or to sysupgrade after loading an initramfs one.
> 
> For porting the flash contents were changed externally with an SPI
> programmer (after lifting Vcc flash IC pin away from the PCB).
> 
> Forum thread [0] indicates that this device is identical to "Xiaomi Mi Router
> 4A Gigabit Edition".
> 
> [0] https://forum.openwrt.org/t/xiaomi-mi-router-4a-gigabit-edition-r4ag-
> r4a-gigabit-fully-supported-but-requires-overwriting-spi-flash-with-
> programmer/36685
> 
> Signed-off-by: Paul Fertser 
> ---
> Changes for v2:
> 
> - Addressed all Adrian Schmutzl's comments
> 
> Changes for v3:
> 
> - Add SPDX license header
> - Use new ALT variables to support R4AG model name
> 
> 
>  .../linux/ramips/base-files/etc/board.d/02_network |   7 +
>  target/linux/ramips/dts/mt7621_xiaomi_mir3g-v2.dts | 147
> +
>  target/linux/ramips/image/mt7621.mk|  12 ++
>  3 files changed, 166 insertions(+)
>  create mode 100644 target/linux/ramips/dts/mt7621_xiaomi_mir3g-v2.dts
> 
> diff --git a/target/linux/ramips/base-files/etc/board.d/02_network
> b/target/linux/ramips/base-files/etc/board.d/02_network
> index 27f85d7458..2b166dd944 100755
> --- a/target/linux/ramips/base-files/etc/board.d/02_network
> +++ b/target/linux/ramips/base-files/etc/board.d/02_network
> @@ -469,6 +469,10 @@ ramips_setup_interfaces()
>   ucidef_add_switch "switch0" \
>   "2:lan:2" "3:lan:1" "1:wan" "6t@eth0"
>   ;;
> + xiaomi,mir3g-v2)
> + ucidef_add_switch "switch0" \
> + "2:lan:2" "3:lan:1" "4:wan" "6t@eth0"
> + ;;

"6t@eth0" and "6@eth0" should be the same, so this can be merged with 
cudy,wr1000.

>   xiaomi,mir3p)
>   ucidef_add_switch "switch0" \
>   "1:lan:3" "2:lan:2" "3:lan:1" "4:wan" "6@eth0"
> @@ -683,6 +687,9 @@ ramips_setup_macs()
>   xiaomi,mir3p)
>   lan_mac=$(mtd_get_mac_binary factory 0xe006)
>   ;;
> + xiaomi,mir3g-v2)
> + wan_mac=$(mtd_get_mac_binary factory 0xe006)
> + ;;

This can be merged with elecom,wrc-1167ghbk2-s|\ etc.

Best

Adrian


openpgp-digital-signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH] treewide: Remove kmod-usb-core from DEVICE_PACKAGES

2019-08-31 Thread Adrian Schmutzler

This removes _all_ occurrences of kmod-usb-core from
DEVICE_PACKAGES and similar variables.

This package is pulled as dependency by one of the following
packages in any case:
- kmod-usb-chipidea
- kmod-usb-dwc2
- kmod-usb-ledtrig-usbport
- kmod-usb-ohci
- kmod-usb2
- kmod-usb2-pci
- kmod-usb3

Signed-off-by: Adrian Schmutzler 
---
 .../ar71xx/generic/profiles/00-default.mk |   2 +-
 .../ar71xx/image/generic-legacy-devices.mk|  90 +--
 target/linux/ar71xx/image/generic-tp-link.mk  |  44 +++---
 target/linux/ar71xx/image/generic-ubnt.mk |   6 +-
 target/linux/ar71xx/image/generic.mk  | 144 +-
 target/linux/ar71xx/image/mikrotik.mk |   2 +-
 target/linux/ar71xx/image/nand.mk |  18 +--
 .../linux/ar71xx/image/tiny-legacy-devices.mk |   8 +-
 target/linux/ar71xx/image/tiny-tp-link.mk |  24 +--
 target/linux/ar71xx/image/tiny.mk |   2 +-
 .../ar71xx/mikrotik/profiles/00-default.mk|   2 +-
 .../linux/ar71xx/nand/profiles/00-default.mk  |   2 +-
 .../linux/ar71xx/tiny/profiles/00-default.mk  |   2 +-
 .../arc770/generic/profiles/00-default.mk |   2 +-
 .../archs38/generic/profiles/00-default.mk|   2 +-
 target/linux/ath79/image/generic-tp-link.mk   |  40 ++---
 target/linux/ath79/image/generic-ubnt.mk  |   4 +-
 target/linux/ath79/image/generic.mk   |  46 +++---
 target/linux/ath79/image/nand.mk  |   2 +-
 target/linux/ath79/image/tiny-tp-link.mk  |   8 +-
 target/linux/ath79/image/tiny.mk  |   2 +-
 .../linux/ath79/nand/profiles/00-default.mk   |   2 +-
 target/linux/gemini/Makefile  |   2 +-
 target/linux/ipq806x/Makefile |   2 +-
 .../ixp4xx/generic/profiles/200-NSLU2.mk  |   2 +-
 .../ixp4xx/generic/profiles/300-NAS100d.mk|   2 +-
 .../generic/profiles/400-DSMG600RevA.mk   |   2 +-
 .../ixp4xx/generic/profiles/500-USR8200.mk|   2 +-
 .../ixp4xx/harddisk/profiles/100-FSG3.mk  |   2 +-
 target/linux/mediatek/image/mt7622.mk |   6 +-
 target/linux/ramips/image/rt288x.mk   |   2 +-
 target/linux/ramips/image/rt305x.mk   |  74 -
 target/linux/ramips/image/rt3883.mk   |  12 +-
 .../ramips/mt7620/profiles/00-default.mk  |   2 +-
 .../ramips/mt7621/profiles/00-default.mk  |   2 +-
 .../ramips/mt76x8/profiles/00-default.mk  |   2 +-
 .../ramips/rt305x/profiles/00-default.mk  |   2 +-
 .../ramips/rt3883/profiles/00-default.mk  |   2 +-
 38 files changed, 286 insertions(+), 286 deletions(-)

diff --git a/target/linux/ar71xx/generic/profiles/00-default.mk 
b/target/linux/ar71xx/generic/profiles/00-default.mk
index f5ebdd2dd8..18fd385cc3 100644
--- a/target/linux/ar71xx/generic/profiles/00-default.mk
+++ b/target/linux/ar71xx/generic/profiles/00-default.mk
@@ -8,7 +8,7 @@
 define Profile/Default
NAME:=Default Profile (all drivers)
PACKAGES:= \
-   kmod-usb-core kmod-usb-ohci kmod-usb2 kmod-usb-ledtrig-usbport
+   kmod-usb-ohci kmod-usb2 kmod-usb-ledtrig-usbport
PRIORITY := 1
 endef
 
diff --git a/target/linux/ar71xx/image/generic-legacy-devices.mk 
b/target/linux/ar71xx/image/generic-legacy-devices.mk
index 9cf405d48a..cbe039cd29 100644
--- a/target/linux/ar71xx/image/generic-legacy-devices.mk
+++ b/target/linux/ar71xx/image/generic-legacy-devices.mk
@@ -12,7 +12,7 @@ LEGACY_DEVICES += ALFANX
 
 define LegacyDevice/HORNETUB
   DEVICE_TITLE := ALFA Network Hornet-UB board (8MB flash, 32MB ram)
-  DEVICE_PACKAGES := kmod-usb-core kmod-usb2 kmod-usb-ledtrig-usbport
+  DEVICE_PACKAGES := kmod-usb2 kmod-usb-ledtrig-usbport
 endef
 LEGACY_DEVICES += HORNETUB
 
@@ -23,7 +23,7 @@ LEGACY_DEVICES += TUBE2H8M
 
 define LegacyDevice/AP96
   DEVICE_TITLE := Atheros AP96 reference board
-  DEVICE_PACKAGES := kmod-usb-core kmod-usb2
+  DEVICE_PACKAGES := kmod-usb2
 endef
 LEGACY_DEVICES += AP96
 
@@ -39,7 +39,7 @@ LEGACY_DEVICES += ALFAAP120C
 
 define LegacyDevice/ALFAAP96
   DEVICE_TITLE := ALFA Network AP96 board
-  DEVICE_PACKAGES := kmod-usb-core kmod-usb-ohci kmod-usb2 kmod-rtc-pcf2123
+  DEVICE_PACKAGES := kmod-usb-ohci kmod-usb2 kmod-rtc-pcf2123
 endef
 LEGACY_DEVICES += ALFAAP96
 
@@ -57,67 +57,67 @@ LEGACY_DEVICES += ALL0315N
 
 define LegacyDevice/AP121_8M
   DEVICE_TITLE := Atheros AP121 reference board (8MB flash)
-  DEVICE_PACKAGES := kmod-usb-core kmod-usb2
+  DEVICE_PACKAGES := kmod-usb2
 endef
 LEGACY_DEVICES += AP121_8M
 
 define LegacyDevice/AP121_16M
   DEVICE_TITLE := Atheros AP121 reference board (16MB flash)
-  DEVICE_PACKAGES := kmod-usb-core kmod-usb2
+  DEVICE_PACKAGES := kmod-usb2
 endef
 LEGACY_DEVICES += AP121_16M
 
 define LegacyDevice/AP132
   DEVICE_TITLE := Atheros AP132 reference board
-  DEVICE_PACKAGES := kmod-usb-core kmod-usb2 kmod-usb-storage
+  DEVICE_PACKAGES := kmod-usb2 kmod-usb-storage
 endef
 LEGACY_DEVICES += AP132
 
 define LegacyDevice/AP135
   DEVICE_TITLE := Atheros AP135 reference board
-

[OpenWrt-Devel] [PATCH] ramips: merge cases in 02_network

2019-08-31 Thread Adrian Schmutzler

This merges three cases with a single switch port.

6t@eth0 and 6@eth0 should be equivalent.

Signed-off-by: Adrian Schmutzler 
---
 .../linux/ramips/base-files/etc/board.d/02_network | 14 --
 1 file changed, 4 insertions(+), 10 deletions(-)

diff --git a/target/linux/ramips/base-files/etc/board.d/02_network 
b/target/linux/ramips/base-files/etc/board.d/02_network
index e19a618389..17b3af8fce 100755
--- a/target/linux/ramips/base-files/etc/board.d/02_network
+++ b/target/linux/ramips/base-files/etc/board.d/02_network
@@ -274,9 +274,11 @@ ramips_setup_interfaces()
"0:lan" "1:lan" "2:lan" "3:lan" "5:wan" "6@eth0"
;;
comfast,cf-wr800n|\
-   hnet,c108)
+   hnet,c108|\
+   tplink,tl-wr902ac-v3|\
+   trendnet,tew-638apb-v2)
ucidef_add_switch "switch0" \
-   "4:lan" "6t@eth0"
+   "4:lan" "6@eth0"
;;
cudy,wr1000)
ucidef_add_switch "switch0" \
@@ -446,14 +448,6 @@ ramips_setup_interfaces()
"0:lan" "1:lan" "2:lan" "3:lan" "6t@eth0"
ucidef_set_interface_wan "usb0"
;;
-   tplink,tl-wr902ac-v3)
-   ucidef_add_switch "switch0" \
-   "4:lan" "6@eth0"
-   ;;
-   trendnet,tew-638apb-v2)
-   ucidef_add_switch "switch0" \
-   "4:lan" "6@eth0"
-   ;;
vocore,vocore2|\
vocore,vocore2-lite)
ucidef_add_switch "switch0" \
-- 
2.20.1


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

Re: [OpenWrt-Devel] Squashfs breakage lottery with UBI WAS: [PATCH RFC 2/2] amp821xx: use newly added pad-squashfs for Meraki MR24

2019-08-31 Thread Christian Lamparter

Hello,

On Saturday, August 31, 2019 2:09:55 PM CEST Jonas Gorski wrote:
> On Sat, 31 Aug 2019 at 01:19, Christian Lamparter  wrote:
> >
> > On Friday, August 30, 2019 11:10:54 PM CEST Russell Senior wrote:
> > > > "Christian" == Christian Lamparter  writes:
> > >
> > > Christian> Ok.
> > >
> > > Christian> I did push a patch titled: "build: remove harmful -nopad
> > > Christian> option from mksquashfs"
> > > Christian> 
> > > 
> > >
> > > Christian> so, let's see if this triggers more undefined behaviour and
> > > Christian> exposes more hidden broken code.
> > >
> > > Just to re-iterate my earlier worry, if for example:
> > >
> > >   kernel_size + rootfs_with_padding_size
> > >
> > > crosses an erase block boundary that:
> > >
> > >   kernel_size + rootfs_without_padding_size
> > >
> > > does not, then we'll be wasting an erase block of flash space on NOR.
> > Not to worry. I guess that part of the magic is also explained in the wiki:
> > 
> > 
> > In case my attempt now gets too confusing :-/.
> >
> > The "rootfs" partition also contains the rootfs_data inside. It should
> > be possible to verify this with any of the routers that use the "firmware"
> > parition label.
> >
> > Please check /proc/mtd. For example on my WNDR3700v2 (which is very similar
> > to your WNDR3800). It looks like this
> >
> > |# cat /proc/mtd
> > |dev:size   erasesize  name
> > |mtd0: 0005 0001 "u-boot"
> > |mtd1: 0002 0001 "u-boot-env"
> > |mtd2: 00f8 0001 "firmware"
> > |mtd3: 0018c440 0001 "kernel"
> > |mtd4: 00df3bc0 0001 "rootfs"
> > |mtd5: 0062 0001 "rootfs_data"
> > |mtd6: 0001 0001 "art
> >
> > The rootfs is 14629824 Bytes = 13.95 MiB. (The kernel + uboot + env + art
> > fills out the remaining ~2MiB to a total of 16 MiB). So the padding we both
> > are talking about already has to exists between the squashfs portion and the
> > jffs2/overlay portion inside the "rootfs" partition and it's a full 
> > erase-size
> > block. Sadly, OpenWrt does not readily print the "end" of just the squashfs
> > partition (as it does with the kernel partition above) and your message from
> > earlier with the three routers didn't include the "squashfs-split" and its
> > results. (I think that maybe this is the missing information that got lost?)
> 
> After a bit more investigation, those devices that use padjffs2 (or
> have the rootfs
> start at an at least 4k aligned offset) will be fine.
> 
> The issue are those devices with an unaligned rootfs start, which put their 
> own
> EOF marker in the image by the firmware util (e.g. brcm63xx or tp-link 
> devices).
> 
> There it can happen that e.g. we get
> 
> 0x18fff2   00 00 00 00
> 0x19000 00 00 00 00 ...  FF FF
> 0x19010 FF FF FF ...
> *
> 0x2 DE AD C0 DE
> 
> The 0xff are only a guess, I haven't checked what the different
> firmware utils use for padding the end of the rootfs - but mksquashfs
> definitely uses 0x00.
> 
> which leads to:
> 
> 1. squashfs-split will put the roofs_data partition start at 0x19000
> because that's the first aligned erase block after the end of the
> rootfs start + squashfs length
> 2. jffs2 will see that the first block is neither a valid jff2 node,
> an EOF marker, nor all 0xff
> 3. jffs2 will refuse to erase/mount the filesystem (AFAIU the code) [1]
> 
> So removing the -nopad might actually break those devices.
> 
> We could fix this case by making sure that mksquashfs and all firmware
> utils use 0xff's to pad (so the erase block will then be treated as
> empty/all 0xff). But then there is the question how jffs2 reacts if
> the first block is 0xff, and the second block is a valid jffs2 node,
> which happens when we sysupgrade with keeping config on NOR devices.
> The jffs2 code isn't the most readable code ... .
>
No need to worry, see one of the previous mails in this thread:

http://lists.infradead.org/pipermail/openwrt-devel/2019-August/018638.html

It contains a patch at the end titled:
"[PATCH] base-files: pad root.squashfs to 64KiB in ubi volumes"
This is another approach that just deals with the UBI+squashfs
issue but works with "-nopad". Soo do we all agree there?  

Cheers,
Christian



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

Re: [OpenWrt-Devel] Squashfs breakage lottery with UBI WAS: [PATCH RFC 2/2] amp821xx: use newly added pad-squashfs for Meraki MR24

2019-08-31 Thread Jonas Gorski

Hi,

On Sat, 31 Aug 2019 at 01:19, Christian Lamparter  wrote:
>
> On Friday, August 30, 2019 11:10:54 PM CEST Russell Senior wrote:
> > > "Christian" == Christian Lamparter  writes:
> >
> > Christian> Ok.
> >
> > Christian> I did push a patch titled: "build: remove harmful -nopad
> > Christian> option from mksquashfs"
> > Christian> 
> > 
> >
> > Christian> so, let's see if this triggers more undefined behaviour and
> > Christian> exposes more hidden broken code.
> >
> > Just to re-iterate my earlier worry, if for example:
> >
> >   kernel_size + rootfs_with_padding_size
> >
> > crosses an erase block boundary that:
> >
> >   kernel_size + rootfs_without_padding_size
> >
> > does not, then we'll be wasting an erase block of flash space on NOR.
> Not to worry. I guess that part of the magic is also explained in the wiki:
> 
> 
> In case my attempt now gets too confusing :-/.
>
> The "rootfs" partition also contains the rootfs_data inside. It should
> be possible to verify this with any of the routers that use the "firmware"
> parition label.
>
> Please check /proc/mtd. For example on my WNDR3700v2 (which is very similar
> to your WNDR3800). It looks like this
>
> |# cat /proc/mtd
> |dev:size   erasesize  name
> |mtd0: 0005 0001 "u-boot"
> |mtd1: 0002 0001 "u-boot-env"
> |mtd2: 00f8 0001 "firmware"
> |mtd3: 0018c440 0001 "kernel"
> |mtd4: 00df3bc0 0001 "rootfs"
> |mtd5: 0062 0001 "rootfs_data"
> |mtd6: 0001 0001 "art
>
> The rootfs is 14629824 Bytes = 13.95 MiB. (The kernel + uboot + env + art
> fills out the remaining ~2MiB to a total of 16 MiB). So the padding we both
> are talking about already has to exists between the squashfs portion and the
> jffs2/overlay portion inside the "rootfs" partition and it's a full erase-size
> block. Sadly, OpenWrt does not readily print the "end" of just the squashfs
> partition (as it does with the kernel partition above) and your message from
> earlier with the three routers didn't include the "squashfs-split" and its
> results. (I think that maybe this is the missing information that got lost?)

After a bit more investigation, those devices that use padjffs2 (or
have the rootfs
start at an at least 4k aligned offset) will be fine.

The issue are those devices with an unaligned rootfs start, which put their own
EOF marker in the image by the firmware util (e.g. brcm63xx or tp-link devices).

There it can happen that e.g. we get

0x18fff2   00 00 00 00
0x19000 00 00 00 00 ...  FF FF
0x19010 FF FF FF ...
*
0x2 DE AD C0 DE

The 0xff are only a guess, I haven't checked what the different
firmware utils use for padding the end of the rootfs - but mksquashfs
definitely uses 0x00.

which leads to:

1. squashfs-split will put the roofs_data partition start at 0x19000
because that's the first aligned erase block after the end of the
rootfs start + squashfs length
2. jffs2 will see that the first block is neither a valid jff2 node,
an EOF marker, nor all 0xff
3. jffs2 will refuse to erase/mount the filesystem (AFAIU the code) [1]

So removing the -nopad might actually break those devices.

We could fix this case by making sure that mksquashfs and all firmware
utils use 0xff's to pad (so the erase block will then be treated as
empty/all 0xff). But then there is the question how jffs2 reacts if
the first block is 0xff, and the second block is a valid jffs2 node,
which happens when we sysupgrade with keeping config on NOR devices.
The jffs2 code isn't the most readable code ... .

Regards
Jonas

[1]  https://elixir.bootlin.com/linux/latest/source/fs/jffs2/scan.c#L263

all dirty nodes will increase neither c->nr_free_blocks nor
empty_blocks nor badblocks, so the sum will be different from
c->nr_blocks, so jffs2 will refuse to mount

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

Re: [OpenWrt-Devel] [lantiq] help in supporting FRITZ!BOX 3272 (Fritz_Box_HW198))

2019-08-31 Thread Enrico Mioso


Dear all,

So I looked at the GPL code from AVM.
I still can't understand why communications with PMU are actually failing: 
addresses seem right.
Still, I noticed AVM did some changes in arch/mips/setup.c, regarding memory 
init: currently I don't understand the impatct of those changes.

just in case it may reveal something, I am reporting here the list of pins and 
module ids of various pieces as reported in the
AVM hw config 198.
Sorry for possible erors.

Enrico


gpio_avm_led_power: pin=5 id=25 param=avm_hw_param_gpio_out_active_low, 
config=IFX_GPIO_IOCTL_PIN_CONFIG_DIR_OUT | 
IFX_GPIO_IOCTL_PIN_CONFIG_ALTSEL0_CLEAR | 
IFX_GPIO_IOCTL_PIN_CONFIG_ALTSEL1_CLEAR | IFX_GPIO_IOCTL_PIN_CONFIG_OUTPUT_SET
gpio_avm_led_lan_all: pin=4 id=25 param=avm_hw_param_gpio_out_active_low, 
config= IFX_GPIO_IOCTL_PIN_CONFIG_DIR_OUT | 
IFX_GPIO_IOCTL_PIN_CONFIG_ALTSEL0_CLEAR | 
IFX_GPIO_IOCTL_PIN_CONFIG_ALTSEL1_CLEAR | IFX_GPIO_IOCTL_PIN_CONFIG_OUTPUT_SET
gpio_avm_led_wlan: pin=11 id=25 params=active_low config=as_previous
gpio_avm_led_pppoe: pin=27 id=25 param=active_low config=as_previous
gpio_avm_led_info: pin=25 id=25 param=active_low config=as_previous
gpio_avm_led_info_red: pin=26 param=active_low config=as_previous
/* external interrupts 0 */
gpio_avm_button_wps: pin=0 id=25 param=active_low 
config=IFX_GPIO_IOCTL_PIN_CONFIG_DIR_IN | IFX_GPIO_IOCTL_PIN_CONFIG_ALTSEL0_SET 
| IFX_GPIO_IOCTL_PIN_CONFIG_ALTSEL1_CLEAR
/* external interrupts 1 */
gpio_avm_button_wlan: pin=1 id=25 param=active_low 
config=IFX_GPIO_IOCTL_PIN_CONFIG_DIR_IN | 
IFX_GPIO_IOCTL_PIN_CONFIG_ALTSEL0_CLEAR  | IFX_GPIO_IOCTL_PIN_CONFIG_ALTSEL1_SET
gpio_avm_spi_clk: pin=18 id=4 param=avm_hw_param_no_param 
config=IFX_GPIO_IOCTL_PIN_CONFIG_DIR_OUT | 
IFX_GPIO_IOCTL_PIN_CONFIG_ALTSEL0_SET | IFX_GPIO_IOCTL_PIN_CONFIG_ALTSEL1_CLEAR 
| IFX_GPIO_IOCTL_PIN_CONFIG_OD_SET
gpio_avm_spi_do: pin=17, id=4 param=no config=IFX_GPIO_IOCTL_PIN_CONFIG_DIR_OUT 
| IFX_GPIO_IOCTL_PIN_CONFIG_ALTSEL0_SET | 
IFX_GPIO_IOCTL_PIN_CONFIG_ALTSEL1_CLEAR | IFX_GPIO_IOCTL_PIN_CONFIG_OD_SET
gpio_avm_spi_di: pin=16, id=4 param=no config=IFX_GPIO_IOCTL_PIN_CONFIG_DIR_IN 
| IFX_GPIO_IOCTL_PIN_CONFIG_ALTSEL0_SET | 
IFX_GPIO_IOCTL_PIN_CONFIG_ALTSEL1_CLEAR
gpio_avm_spi_flash_cs: pin=15 id=22 param=avm_hw_param_gpio_out_active_high 
config=IFX_GPIO_IOCTL_PIN_CONFIG_DIR_OUT | 
IFX_GPIO_IOCTL_PIN_CONFIG_ALTSEL0_SET | IFX_GPIO_IOCTL_PIN_CONFIG_ALTSEL1_CLEAR 
| IFX_GPIO_IOCTL_PIN_CONFIG_OD_SET
gpio_avm_nand_ale: pin=13 id=12 param=avm_hw_param_gpio_out_active_low 
config=IFX_GPIO_IOCTL_PIN_CONFIG_DIR_OUT | 
IFX_GPIO_IOCTL_PIN_CONFIG_ALTSEL0_SET | IFX_GPIO_IOCTL_PIN_CONFIG_ALTSEL1_CLEAR 
| IFX_GPIO_IOCTL_PIN_CONFIG_OD_SET
gpio_avm_nand_cle: pin=24 id=12 param=avm_hw_param_gpio_out_active_low 
config=IFX_GPIO_IOCTL_PIN_CONFIG_DIR_OUT | 
IFX_GPIO_IOCTL_PIN_CONFIG_ALTSEL0_SET | IFX_GPIO_IOCTL_PIN_CONFIG_ALTSEL1_CLEAR 
| IFX_GPIO_IOCTL_PIN_CONFIG_OD_SET
gpio_avm_nand_rd_by: pin=48 id=12 param=avm_hw_param_gpio_in_active_low 
config=IFX_GPIO_IOCTL_PIN_CONFIG_DIR_IN | IFX_GPIO_IOCTL_PIN_CONFIG_ALTSEL0_SET 
| IFX_GPIO_IOCTL_PIN_CONFIG_ALTSEL1_CLEAR | IFX_GPIO_IOCTL_PIN_CONFIG_OD_CLEAR
gpio_avm_nand_rd: pin=49 id=12 param=avm_hw_param_gpio_out_active_low 
config=IFX_GPIO_IOCTL_PIN_CONFIG_DIR_OUT | 
IFX_GPIO_IOCTL_PIN_CONFIG_ALTSEL0_SET | IFX_GPIO_IOCTL_PIN_CONFIG_ALTSEL1_CLEAR 
| IFX_GPIO_IOCTL_PIN_CONFIG_OD_SET
gpio_avm_nand_wr: pin=59 id=12 param=avm_hw_param_gpio_out_active_low 
config=IFX_GPIO_IOCTL_PIN_CONFIG_DIR_OUT | 
IFX_GPIO_IOCTL_PIN_CONFIG_ALTSEL0_SET | IFX_GPIO_IOCTL_PIN_CONFIG_ALTSEL1_CLEAR 
| IFX_GPIO_IOCTL_PIN_CONFIG_OD_SET
gpio_avm_nand_wp: pin=60 id=12 param=avm_hw_param_gpio_out_active_low 
config=IFX_GPIO_IOCTL_PIN_CONFIG_DIR_OUT | 
IFX_GPIO_IOCTL_PIN_CONFIG_ALTSEL0_SET | IFX_GPIO_IOCTL_PIN_CONFIG_ALTSEL1_CLEAR 
| IFX_GPIO_IOCTL_PIN_CONFIG_OD_SET
gpio_avm_nand_cs1: pin=23 id=12 param=avm_hw_param_gpio_out_active_low 
config=IFX_GPIO_IOCTL_PIN_CONFIG_DIR_OUT | 
IFX_GPIO_IOCTL_PIN_CONFIG_ALTSEL0_SET | IFX_GPIO_IOCTL_PIN_CONFIG_ALTSEL1_CLEAR 
| IFX_GPIO_IOCTL_PIN_CONFIG_OD_SET
gpio_avm_nand_d0: pin=51 id=12 param=avm_hw_param_gpio_out_active_low 
config=IFX_GPIO_IOCTL_PIN_CONFIG_DIR_OUT | 
IFX_GPIO_IOCTL_PIN_CONFIG_ALTSEL0_SET | IFX_GPIO_IOCTL_PIN_CONFIG_ALTSEL1_CLEAR 
| IFX_GPIO_IOCTL_PIN_CONFIG_OD_SET
gpio_avm_nand_d1: pin=50 id=12 param=avm_hw_param_gpio_out_active_low 
config=IFX_GPIO_IOCTL_PIN_CONFIG_DIR_OUT | 
IFX_GPIO_IOCTL_PIN_CONFIG_ALTSEL0_SET | IFX_GPIO_IOCTL_PIN_CONFIG_ALTSEL1_CLEAR 
| IFX_GPIO_IOCTL_PIN_CONFIG_OD_SET
gpio_avm_nand_d2: pin=52 id=12 param=avm_hw_param_gpio_out_active_low 
IFX_GPIO_IOCTL_PIN_CONFIG_DIR_OUT | IFX_GPIO_IOCTL_PIN_CONFIG_ALTSEL0_SET | 
IFX_GPIO_IOCTL_PIN_CONFIG_ALTSEL1_CLEAR | IFX_GPIO_IOCTL_PIN_CONFIG_OD_SET
gpio_avm_nand_d3: pin=57 id=12 param=avm_hw_param_gpio_out_active_low 
config=IFX_GPIO_IOCTL_PIN_CONFIG_DIR_OUT | 
IFX_GPIO_IOCTL_PIN_CONFIG_ALTSEL0_SET | IFX_GPIO_IOCTL_PIN_CONFIG_ALTSEL1_CLEAR 
| IFX_GPIO_IOCTL_PIN_CONFIG_OD_SET

Re: [OpenWrt-Devel] MT7610En bluetooth support

2019-08-31 Thread Enrico Mioso


Thank you!! :)
Enrico


On Fri, 30 Aug 2019, John Crispin wrote:


Date: Fri, 30 Aug 2019 15:39:02
From: John Crispin 
To: Enrico Mioso ,
OpenWrt Development List 
Cc: n...@nbd.name
Subject: Re: [OpenWrt-Devel] MT7610En bluetooth support


On 30/08/2019 15:29, Enrico Mioso wrote:

Hello!!

I saw commit 7f9edadf85299cd4fc965a811b40eaa57a368486

and was wondering if we can now use the BT hardware found on this chipset.
Thanks!!

Enrico


its still WIP

    John




___
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

[OpenWrt-Devel] [PATCH v2] ipq40xx: Add support for Unielec U4019

2019-08-31 Thread Kristian Evensen

This commit adds support for the 32MB storage/512MB RAM version of the U4019
IPQ4019-based board from Unielec. The board has the following specifications:

* Qualcomm IPQ4019 (running at 717MHz)
* 512MB DDR3 RAM (optional 256MB/1GB)
* 32MB SPI NOR (optional 8/16MB or NAND)
* Five gigabit ports (Qualcomm QCA8075)
* 1x 2.4 GHz wifi (QCA4019 hw1.0)
* 1x 5 Ghz wifi (QCA4019 hw1.0)
* 1x mini-PCIe slot (only USB-pins connected)
* 1x SIM slot (mini-SIM)
* 1x USB2.0 port
* 1x button
* 1x controllable LED
* 1x micro SD-card reader

Working:
* Ethernet
* Wifi
* USB-port
* mini-PCIe slot + SIM slot
* Button
* Sysupgrade

Not working:
* SD card slot (no upstream support)

Installation instructions:

In order to install OpenWRT on the U4019, you need to go via the
initramfs-image. The installation steps are as follows:

* Connect to board via serial (header exposed and clearly marked).
* Interrupt bootloader by pressing a button.
* Copy the initramfs-image to your tftp folder, call the file C0A80079.img.
* Give the network interface connected to the U4019 the address
192.168.0.156/24.
* Start your tftp-server and run tftpboot on the board.
* Run bootm when the file has been transferred, to boot OpenWRT.
* Once OpenWRT has booted, copy the sysupgrade-image to the device and run
sysupgrade to install OpenWRT on the U4019.

Notes:

- Since IPQ4019 has been moved to 4.19, I have not added support for kernel
4.14.

- There is a bug with hardware encryption on IPQ4019, causing poor performance
with TCP and ipsec (see for example FS#2355). In order to improve performance,
I have disabled hardware encryption in the DTS. We can enable hw. enc. once/if
bug is fixed.

- In order for Ethernet to work, the phy has to be reset by setting gpio 47
low/high. Adding support for phy reset via gpio required patching the
mdio-driver, and the code added comes from the vendor driver. I do not know if
patching the driver is an acceptable approach or not.

v1->v2:
* Do not use wildcard as identifier in the board.d-scripts (thanks
Adrian Schmutzler).

Signed-off-by: Kristian Evensen 
---
 .../ipq40xx/base-files/etc/board.d/02_network |   5 +
 .../etc/hotplug.d/firmware/11-ath10k-caldata  |   6 +-
 .../dts/qcom-ipq4019-unielec-u4019-32m.dts|  79 +++
 .../boot/dts/qcom-ipq4019-unielec-u4019.dtsi  | 223 ++
 target/linux/ipq40xx/image/Makefile   |  13 +
 .../700-net-add-qualcomm-mdio.patch   |  80 ++-
 .../901-arm-boot-add-dts-files.patch  |  15 +-
 7 files changed, 410 insertions(+), 11 deletions(-)
 create mode 100644 
target/linux/ipq40xx/files-4.19/arch/arm/boot/dts/qcom-ipq4019-unielec-u4019-32m.dts
 create mode 100644 
target/linux/ipq40xx/files-4.19/arch/arm/boot/dts/qcom-ipq4019-unielec-u4019.dtsi

diff --git a/target/linux/ipq40xx/base-files/etc/board.d/02_network 
b/target/linux/ipq40xx/base-files/etc/board.d/02_network
index e5ba7260f3..f036dc842f 100755
--- a/target/linux/ipq40xx/base-files/etc/board.d/02_network
+++ b/target/linux/ipq40xx/base-files/etc/board.d/02_network
@@ -61,6 +61,11 @@ ipq40xx_setup_interfaces()
ucidef_add_switch "switch0" \
"0u@eth0" "3:lan" "4:lan" "0u@eth1" "5:wan"
;;
+   unielec,u4019-32m)
+   ucidef_set_interfaces_lan_wan "eth0" "eth1"
+   ucidef_add_switch "switch0" \
+   "0u@eth0" "1:lan" "2:lan" "3:lan" "4:lan" "0u@eth1" 
"5:wan"
+   ;;
*)
echo "Unsupported hardware. Network interfaces not initialized"
;;
diff --git 
a/target/linux/ipq40xx/base-files/etc/hotplug.d/firmware/11-ath10k-caldata 
b/target/linux/ipq40xx/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
index be57646128..ee1e899fae 100644
--- a/target/linux/ipq40xx/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
+++ b/target/linux/ipq40xx/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
@@ -161,7 +161,8 @@ case "$FIRMWARE" in
openmesh,a42 |\
openmesh,a62 |\
qxwlan,e2600ac-c1 |\
-   qxwlan,e2600ac-c2)
+   qxwlan,e2600ac-c2 |\
+   unielec,u4019-32m)
ath10kcal_extract "0:ART" 0x1000 0x2f20
;;
engenius,ens620ext)
@@ -222,7 +223,8 @@ case "$FIRMWARE" in
openmesh,a42 |\
openmesh,a62 |\
qxwlan,e2600ac-c1 |\
-   qxwlan,e2600ac-c2)
+   qxwlan,e2600ac-c2 |\
+   unielec,u4019-32m)
ath10kcal_extract "0:ART" 0x5000 0x2f20
;;
engenius,ens620ext)
diff --git 
a/target/linux/ipq40xx/files-4.19/arch/arm/boot/dts/qcom-ipq4019-unielec-u4019-32m.dts
 
b/target/linux/ipq40xx/files-4.19/arch/arm/boot/dts/qcom-ipq4019-unielec-u4019-32m.dts
new file mode 100644
index 00..606ac165ba
--- /dev/null
+++ 
b/target/linux/ipq40xx/files-4.19/arch/arm/boot/dts/qcom-ipq4019-unielec-u4019-32m.dts
@@ -0,0 +1,79 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+
+/dts-v1/;
+
+#include

Re: [OpenWrt-Devel] [PATCH procd] system: reject sysupgrade of broken firmware images

Re: [OpenWrt-Devel] [PATCH procd] system: reject sysupgrade of broken firmware images

Re: [OpenWrt-Devel] [PATCH v3] ramips: add support for Xiaomi Mi Wi-Fi Router 3G v2

[OpenWrt-Devel] [PATCH] treewide: Remove kmod-usb-core from DEVICE_PACKAGES

[OpenWrt-Devel] [PATCH] ramips: merge cases in 02_network

Re: [OpenWrt-Devel] Squashfs breakage lottery with UBI WAS: [PATCH RFC 2/2] amp821xx: use newly added pad-squashfs for Meraki MR24

Re: [OpenWrt-Devel] Squashfs breakage lottery with UBI WAS: [PATCH RFC 2/2] amp821xx: use newly added pad-squashfs for Meraki MR24

Re: [OpenWrt-Devel] [lantiq] help in supporting FRITZ!BOX 3272 (Fritz_Box_HW198))

Re: [OpenWrt-Devel] MT7610En bluetooth support

[OpenWrt-Devel] [PATCH v2] ipq40xx: Add support for Unielec U4019

10 matches

Site Navigation

Mail list logo

Footer information