Re: [PATCH] ramips/mt7621: enable support for cpuidle

2021-03-23 Thread Henrique de Moraes Holschuh

On 23/03/2021 16:46, Rui Salvaterra wrote:

On Tue, 23 Mar 2021 at 17:47, Henrique de Moraes Holschuh
 wrote:


Does this change throughput or network behavior ?


I haven't noticed absolutely any differences. And note that I'm
running at HZ = 24 in my personal configuration, so my timer frequency
is under 1/10 of the default one (HZ = 250).


Thanks!

--
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


Re: [PATCH] ramips/mt7621: enable support for cpuidle

2021-03-23 Thread Rui Salvaterra
Hi, Henrique,

On Tue, 23 Mar 2021 at 17:47, Henrique de Moraes Holschuh
 wrote:
>
> Does this change throughput or network behavior ?

I haven't noticed absolutely any differences. And note that I'm
running at HZ = 24 in my personal configuration, so my timer frequency
is under 1/10 of the default one (HZ = 250).

Thanks,
Rui

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


Re: [PATCH] ramips/mt7621: enable support for cpuidle

2021-03-23 Thread Henrique de Moraes Holschuh

On 23/03/2021 11:09, Rui Salvaterra wrote:

MIPS Coherent Processor Systems (CPS), which include the MT7621 SoC, support
deep sleep idle states and have a specific cpuidle driver for them.
Enable support for it, while also switching from constant timer ticks to the
idle dynticks model, with the TEO governor.


Does this change throughput or network behavior ?

--
Henrique de Moraes Holschuh

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


[PATCH] Revert "build: fix kernel 5.4 on macos"

2021-03-23 Thread Ronny Kotzschmar 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 ---
This reverts commit 0a06fcf608ddf1f5db389decf266283392344784.

With this commit uboot-rockchip does not build on macos.
There are some missing definitions for unsigned types:

  HOSTCC  tools/aisimage.o
In file included from tools/aisimage.c:9:
In file included from include/image.h:19:
In file included from ./arch/arm/include/asm/byteorder.h:29:
In file included from include/linux/byteorder/little_endian.h:13:
include/linux/types.h:146:9: error: unknown type name '__u64'; did you mean 
'__s64'?
typedef __u64 __bitwise __le64;
^
/work/openwrt/staging_dir/host/include/asm/types.h:19:44: note: '__s64' 
declared here
__extension__ typedef __signed__ long long __s64;
   ^

There is no build error without this commit.

build tested on macos 11.2.3-x86_64 and debian buster with
target friendlyarm_nanopi-r2s

Signed-off-by: Ronny Kotzschmar 

diff --git a/tools/Makefile b/tools/Makefile
index 8752a3e2b5..a0997b8ce1 100644
--- a/tools/Makefile
+++ b/tools/Makefile
@@ -133,10 +133,6 @@ $(STAGING_DIR_HOST)/.prepared: $(TMP_DIR)/.build
mkdir -p $(BUILD_DIR_HOST)/stamp $(STAGING_DIR_HOST)/include/sys
$(INSTALL_DATA) $(TOPDIR)/tools/include/*.h $(STAGING_DIR_HOST)/include/
$(INSTALL_DATA) $(TOPDIR)/tools/include/sys/*.h 
$(STAGING_DIR_HOST)/include/sys/
-ifneq ($(HOST_OS),Linux)
-   mkdir -p $(STAGING_DIR_HOST)/include/asm
-   $(INSTALL_DATA) $(TOPDIR)/tools/include/asm/*.h 
$(STAGING_DIR_HOST)/include/asm/
-endif
ln -snf lib $(STAGING_DIR_HOST)/lib64
touch $@
 
diff --git a/tools/include/asm/types.h b/tools/include/asm/types.h
deleted file mode 100644
index 2c91232619..00
--- a/tools/include/asm/types.h
+++ /dev/null
@@ -1,24 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */
-/*
- * asm-generic/int-ll64.h
- *
- * Integer declarations for architectures which use "long long"
- * for 64-bit types.
- */
-
-#ifndef _ASM_GENERIC_INT_LL64_H
-#define _ASM_GENERIC_INT_LL64_H
-
-typedef __signed__ char __s8;
-
-typedef __signed__ short __s16;
-
-typedef __signed__ int __s32;
-
-#ifdef __GNUC__
-__extension__ typedef __signed__ long long __s64;
-#else
-typedef __signed__ long long __s64;
-#endif
-
-#endif /* _ASM_GENERIC_INT_LL64_H */
-- 
2.24.3 (Apple Git-128)


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


[PATCH] build: fix uboot-rockchip on macos

2021-03-23 Thread Ronny Kotzschmar 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 ---
Add type definitions for unsigned "long long" 64-bit types
as in asm-generic/int-ll64.h / uapi/asm-generic/int-ll64.h.

Without this you get the following error:

  HOSTCC  tools/aisimage.o
In file included from tools/aisimage.c:9:
In file included from include/image.h:19:
In file included from ./arch/arm/include/asm/byteorder.h:29:
In file included from include/linux/byteorder/little_endian.h:13:
include/linux/types.h:146:9: error: unknown type name '__u64'; did you mean 
'__s64'?
typedef __u64 __bitwise __le64;
^
/work/openwrt/staging_dir/host/include/asm/types.h:19:44: note: '__s64' 
declared here
__extension__ typedef __signed__ long long __s64;
   ^

Signed-off-by: Ronny Kotzschmar 

diff --git a/tools/include/asm/types.h b/tools/include/asm/types.h
index 2c91232619..5a12bbe91b 100644
--- a/tools/include/asm/types.h
+++ b/tools/include/asm/types.h
@@ -10,15 +10,20 @@
 #define _ASM_GENERIC_INT_LL64_H
 
 typedef __signed__ char __s8;
+typedef unsigned char __u8;
 
 typedef __signed__ short __s16;
+typedef unsigned short __u16;
 
 typedef __signed__ int __s32;
+typedef unsigned int __u32;
 
 #ifdef __GNUC__
 __extension__ typedef __signed__ long long __s64;
+__extension__ typedef unsigned long long __u64;
 #else
 typedef __signed__ long long __s64;
+typedef unsigned long long __u64;
 #endif
 
 #endif /* _ASM_GENERIC_INT_LL64_H */
-- 
2.24.3 (Apple Git-128)


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


Re: [PATCH] ubusd: convert tx_queue to linked list

2021-03-23 Thread Petr Štetiar
Arnout Vandecappelle (Essensium/Mind)  [2021-03-23 16:23:25]:

Hi,

> To maintain the linked list, an additional structure ubus_msg_buf_list
> is created. We could also have added the linked list to the ubus_msg_buf
> struct itself, but it is not relevant in the many other uses of the
> ubus_msg_buf struct so it would just complicate things.

I've just tried to run CI pipeline[1] on this patch and got following complaints
from clang static analyzer[2]:

 ubusd_main.c:33:3: warning: Use of memory after it is freed [unix.Malloc]
 ubus_msg_list_free(ubl);
 ^~~

 ubusd_main.c:76:39: warning: Use of memory after it is freed [unix.Malloc]
 written = ubus_msg_writev(sock->fd, ubl->msg, ubl->offset);
 ^~~~

1. https://gitlab.com/ynezz/openwrt-ubus/-/pipelines/275104805
2. 
https://ynezz.gitlab.io/-/openwrt-ubus/-/jobs/1121145462/artifacts/build/scan/2021-03-23-154521-70-1/index.html

Cheers,

Petr

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


[PATCH] ubusd: convert tx_queue to linked list

2021-03-23 Thread Arnout Vandecappelle (Essensium/Mind)
ubusd maintains a per-client tx_queue containing references to message
buffers that have not been sent yet (due to the socket blocking). This
is a fixed-size, 64-element queue.

When more than 64 elements are queued, subsequent elements are simply
dropped. Thus, a client that is waiting for those messages will block
indefinitely. In particular, this happens when more than +- 250 objects
are registered on the bus and either "ubus list" or "ubus wait_for" is
called. The responses to these requests consist of a message buffer per
object. Since in practice, ubusd will not yield between the sends of
these message buffers, the client has no time to process them and
eventually the output socket blocks. After 64 more objects, the rest is
dropped, including the final message that indicates termination. Thus,
the client waits indefinitely for the termination message.

To solve this, turn the tx_queue into a variable-sized linked list
instead of a fixed-size queue.

To maintain the linked list, an additional structure ubus_msg_buf_list
is created. We could also have added the linked list to the ubus_msg_buf
struct itself, but it is not relevant in the many other uses of the
ubus_msg_buf struct so it would just complicate things.

The txq_off variable was used to keep track of which part of the current
message was already written, in case only a partial write was possible.
We take this opportunity to also move that variable under the
ubus_msg_buf_list structure (and rename it to "offset", and change its
type to size_t). This makes it clearer that it is related to that
particular queued message and not to the queue as a whole.

Note that this infinite tx_queue opens the door to a DoS attack. You can
open a client and a server connection, then send messages from the
client to the server without ever reading anything on the server side.
This will eventually lead to an out-of-memory. However, such a DoS
already existed anyway, it just requires opening multiple server
connections and filling up the fixed-size queue on each one. To protect
against such DoS attacks, we'd need to:
- keep a global maximum queue size that applies to all rx and tx queues
  together;
- stop reading from any connection when the maximum is reached;
- close any connection when it hasn't become writeable after some
  timeout.

Fixes: https://bugs.openwrt.org/index.php?do=details_id=1525

Signed-off-by: Arnout Vandecappelle (Essensium/Mind) 
---
 ubusd.c   | 23 ++-
 ubusd.h   | 10 +++---
 ubusd_main.c  | 45 +
 ubusd_proto.c |  1 +
 4 files changed, 43 insertions(+), 36 deletions(-)

diff --git a/ubusd.c b/ubusd.c
index 5993653..b7cafaf 100644
--- a/ubusd.c
+++ b/ubusd.c
@@ -133,24 +133,31 @@ ssize_t ubus_msg_writev(int fd, struct ubus_msg_buf *ub, 
size_t offset)
return ret;
 }
 
-static void ubus_msg_enqueue(struct ubus_client *cl, struct ubus_msg_buf *ub)
+static void ubus_msg_enqueue(struct ubus_client *cl, struct ubus_msg_buf *ub,
+size_t offset)
 {
-   if (cl->tx_queue[cl->txq_tail])
+   struct ubus_msg_buf_list *ubl;
+
+   ubl = calloc(1, sizeof(struct ubus_msg_buf_list));
+   if (!ubl)
return;
 
-   cl->tx_queue[cl->txq_tail] = ubus_msg_ref(ub);
-   cl->txq_tail = (cl->txq_tail + 1) % ARRAY_SIZE(cl->tx_queue);
+   INIT_LIST_HEAD(>list);
+   ubl->msg = ubus_msg_ref(ub);
+   ubl->offset = offset;
+
+   list_add_tail(>tx_queue, >list);
 }
 
 /* takes the msgbuf reference */
 void ubus_msg_send(struct ubus_client *cl, struct ubus_msg_buf *ub)
 {
-   ssize_t written;
+   ssize_t written = 0;
 
if (ub->hdr.type != UBUS_MSG_MONITOR)
ubusd_monitor_message(cl, ub, true);
 
-   if (!cl->tx_queue[cl->txq_cur]) {
+   if (list_empty(>tx_queue)) {
written = ubus_msg_writev(cl->sock.fd, ub, 0);
 
if (written < 0)
@@ -159,10 +166,8 @@ void ubus_msg_send(struct ubus_client *cl, struct 
ubus_msg_buf *ub)
if (written >= (ssize_t) (ub->len + sizeof(ub->hdr)))
return;
 
-   cl->txq_ofs = written;
-
/* get an event once we can write to the socket again */
uloop_fd_add(>sock, ULOOP_READ | ULOOP_WRITE | 
ULOOP_EDGE_TRIGGER);
}
-   ubus_msg_enqueue(cl, ub);
+   ubus_msg_enqueue(cl, ub, written);
 }
diff --git a/ubusd.h b/ubusd.h
index 923e43d..4131274 100644
--- a/ubusd.h
+++ b/ubusd.h
@@ -23,7 +23,6 @@
 #include "ubusmsg.h"
 #include "ubusd_acl.h"
 
-#define UBUSD_CLIENT_BACKLOG   32
 #define UBUS_OBJ_HASH_BITS 4
 
 extern struct blob_buf b;
@@ -36,6 +35,12 @@ struct ubus_msg_buf {
int len;
 };
 
+struct ubus_msg_buf_list {
+   struct list_head list;
+   struct ubus_msg_buf *msg;
+   size_t offset;
+};
+
 struct ubus_client {
struct ubus_id id;
struct uloop_fd sock;
@@ -48,8 +53,7 @@ struct 

[PATCH] bcm4908: implement basic sysupgrade support

2021-03-23 Thread Rafał Miłecki
From: Rafał Miłecki 

It isn't UBI aware yet - that remains to be implemented.

Signed-off-by: Rafał Miłecki 
---
 target/linux/bcm4908/Makefile |   4 +-
 .../base-files/lib/upgrade/platform.sh| 114 ++
 2 files changed, 117 insertions(+), 1 deletion(-)
 create mode 100644 target/linux/bcm4908/base-files/lib/upgrade/platform.sh

diff --git a/target/linux/bcm4908/Makefile b/target/linux/bcm4908/Makefile
index 5bee66fe2b..5f80c2f6ca 100644
--- a/target/linux/bcm4908/Makefile
+++ b/target/linux/bcm4908/Makefile
@@ -20,6 +20,8 @@ include $(INCLUDE_DIR)/target.mk
 
 KERNELNAME:=Image dtbs
 
-DEFAULT_PACKAGES += kmod-usb-ohci kmod-usb2 kmod-usb3
+DEFAULT_PACKAGES += \
+   bcm63xx-bootfs \
+   kmod-usb-ohci kmod-usb2 kmod-usb3
 
 $(eval $(call BuildTarget))
diff --git a/target/linux/bcm4908/base-files/lib/upgrade/platform.sh 
b/target/linux/bcm4908/base-files/lib/upgrade/platform.sh
new file mode 100644
index 00..e285b9e013
--- /dev/null
+++ b/target/linux/bcm4908/base-files/lib/upgrade/platform.sh
@@ -0,0 +1,114 @@
+#!/bin/sh
+# SPDX-License-Identifier: GPL-2.0 OR BSD-2-Clause
+
+RAMFS_COPY_BIN="bcm63xx-bootfs"
+
+PART_NAME=firmware
+
+# $(1): file to read magic from
+# $(2): offset in bytes
+# $(3): length in bytes
+get_content() {
+   dd if="$1" skip=$2 bs=1 count=$3 2>/dev/null
+}
+
+platform_expected_image() {
+   local machine=$(board_name)
+
+   case "$machine" in
+   "asus,gt-ac5300")   echo "asus GT-AC5300"; return;;
+   "netgear,r8000p")   echo "chk U12H359T00_NETGEAR"; 
return;;
+   "tplink,archer-c2300-v1")   echo ""; return;;
+   esac
+}
+
+platform_identify() {
+   local magic
+   local size
+
+   size=$(wc -c "$1" | cut -d ' ' -f 1)
+
+   magic=$(get_content "$1" $(($size - 20 - 64 + 8)) 12)
+   [ "$magic" = "GT-AC5300" ] && {
+   echo "asus"
+   return
+   }
+
+   echo "unknown"
+}
+
+platform_check_image() {
+   [ "$#" -gt 1 ] && return 1
+
+   local expected_image="$(platform_expected_image)"
+   local file_type=$(platform_identify "$1")
+   local error=0
+
+   case "$file_type" in
+   "asus")
+   local size=$(wc -c "$1" | cut -d ' ' -f 1)
+   local productid=$(get_content "$1" $(($size - 20 - 64 + 
8)) 12)
+
+   [ -n "$expected_image" -a "asus $productid" != 
"$expected_image" ] && {
+   echo "Firmware productid mismatch ($productid)"
+   error=1
+   }
+   ;;
+   *)
+   echo "Invalid image type. Please use firmware specific 
for this device."
+   notify_firmware_broken
+   error=1
+   ;;
+   esac
+
+   return $error
+}
+
+platform_calc_new_cferam() {
+   local mtd=$(find_mtd_part $PART_NAME)
+   [ -z "$mtd" ] && {
+   echo "Failed to find $PART_NAME partition" >&2
+   return
+   }
+
+   local idx=$(bcm63xx-bootfs ls $mtd | sed -n 's/cferam\.\(\d\d\d\)/\1/p')
+   [ -z "$idx" ] && {
+   echo "Failed to find cferam current index" >&2
+   return
+   }
+
+   idx=$(($idx + 1))
+   [ "$idx" = "1000" ] && idx=0
+
+   echo $(printf "cferam.%03d" $idx)
+}
+
+platform_img_from_asus_cmd() {
+   local size=$(wc -c "$1" | cut -d ' ' -f 1)
+
+   # Use bs=1 to workaround missing iflag=count_bytes
+   echo -n dd bs=1 count=$(($size - 20 - 64))
+}
+
+platform_do_upgrade() {
+   local file_type=$(platform_identify "$1")
+   local cmd=
+
+   # Find target cferam name
+   local cferam="$(platform_calc_new_cferam)"
+   [ -z "$cferam" ] && exit 1
+
+   bcm63xx-bootfs mv $1 cferam.000 $cferam || {
+   echo "Failed to rename cferam.000 to $cferam" >&2
+   exit 1
+   }
+
+   # Flash new firmware
+   case "$file_type" in
+   "asus") cmd=$(platform_img_from_asus_cmd "$1");;
+   esac
+   mtd erase firmware
+   default_do_upgrade "$1" "$cmd"
+
+   echo "SUCCESS! Used $cferam"
+}
-- 
2.26.2


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


[PATCH] ramips/mt7621: enable support for cpuidle

2021-03-23 Thread Rui Salvaterra
MIPS Coherent Processor Systems (CPS), which include the MT7621 SoC, support
deep sleep idle states and have a specific cpuidle driver for them.
Enable support for it, while also switching from constant timer ticks to the
idle dynticks model, with the TEO governor.

Signed-off-by: Rui Salvaterra 
---
 target/linux/ramips/mt7621/config-5.10 | 10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/target/linux/ramips/mt7621/config-5.10 
b/target/linux/ramips/mt7621/config-5.10
index c98b33c6cb..26c5c5de6b 100644
--- a/target/linux/ramips/mt7621/config-5.10
+++ b/target/linux/ramips/mt7621/config-5.10
@@ -2,6 +2,7 @@ CONFIG_ARCH_32BIT_OFF_T=y
 CONFIG_ARCH_HIBERNATION_POSSIBLE=y
 CONFIG_ARCH_MMAP_RND_BITS_MAX=15
 CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MAX=15
+CONFIG_ARCH_NEEDS_CPU_IDLE_COUPLED=y
 CONFIG_ARCH_SUSPEND_POSSIBLE=y
 CONFIG_AT803X_PHY=y
 CONFIG_BLK_MQ_PCI=y
@@ -23,6 +24,9 @@ CONFIG_CPU_HAS_DIEI=y
 CONFIG_CPU_HAS_PREFETCH=y
 CONFIG_CPU_HAS_RIXI=y
 CONFIG_CPU_HAS_SYNC=y
+CONFIG_CPU_IDLE=y
+# CONFIG_CPU_IDLE_GOV_LADDER is not set
+CONFIG_CPU_IDLE_GOV_TEO=y
 CONFIG_CPU_MIPS32=y
 # CONFIG_CPU_MIPS32_R1 is not set
 CONFIG_CPU_MIPS32_R2=y
@@ -30,6 +34,7 @@ CONFIG_CPU_MIPSR2=y
 CONFIG_CPU_MIPSR2_IRQ_EI=y
 CONFIG_CPU_MIPSR2_IRQ_VI=y
 CONFIG_CPU_NEEDS_NO_SMARTMIPS_OR_MICROMIPS=y
+CONFIG_CPU_PM=y
 CONFIG_CPU_R4K_CACHE_TLB=y
 CONFIG_CPU_RMAP=y
 CONFIG_CPU_SUPPORTS_32BIT_KERNEL=y
@@ -97,7 +102,6 @@ CONFIG_HAS_IOPORT_MAP=y
 CONFIG_HIGHMEM=y
 CONFIG_HZ=250
 CONFIG_HZ_250=y
-CONFIG_HZ_PERIODIC=y
 CONFIG_I2C=y
 CONFIG_I2C_BOARDINFO=y
 CONFIG_I2C_MT7621=y
@@ -134,7 +138,9 @@ CONFIG_MIPS_CM=y
 CONFIG_MIPS_CMDLINE_FROM_DTB=y
 CONFIG_MIPS_CPC=y
 CONFIG_MIPS_CPS=y
+CONFIG_MIPS_CPS_CPUIDLE=y
 # CONFIG_MIPS_CPS_NS16550_BOOL is not set
+CONFIG_MIPS_CPS_PM=y
 CONFIG_MIPS_CPU_SCACHE=y
 # CONFIG_MIPS_ELF_APPENDED_DTB is not set
 CONFIG_MIPS_GIC=y
@@ -182,6 +188,8 @@ CONFIG_NET_MEDIATEK_SOC=y
 CONFIG_NET_SWITCHDEV=y
 CONFIG_NET_VENDOR_MEDIATEK=y
 # CONFIG_NET_VENDOR_RALINK is not set
+CONFIG_NO_HZ_COMMON=y
+CONFIG_NO_HZ_IDLE=y
 CONFIG_NR_CPUS=4
 CONFIG_OF=y
 CONFIG_OF_ADDRESS=y
-- 
2.31.0


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


[PATCH] bcm63xx-bootfs: add tool accessing JFFS2 bootfs images

2021-03-23 Thread Rafał Miłecki
From: Rafał Miłecki 

On BCM4908 it's required to rename cferam.000 file in firmware image
before flashing it.

Signed-off-by: Rafał Miłecki 
---
 package/utils/bcm63xx-bootfs/Makefile |  34 ++
 package/utils/bcm63xx-bootfs/src/Makefile |   7 +
 .../utils/bcm63xx-bootfs/src/bcm63xx-bootfs.c | 378 ++
 3 files changed, 419 insertions(+)
 create mode 100644 package/utils/bcm63xx-bootfs/Makefile
 create mode 100644 package/utils/bcm63xx-bootfs/src/Makefile
 create mode 100644 package/utils/bcm63xx-bootfs/src/bcm63xx-bootfs.c

diff --git a/package/utils/bcm63xx-bootfs/Makefile 
b/package/utils/bcm63xx-bootfs/Makefile
new file mode 100644
index 00..f62efeba33
--- /dev/null
+++ b/package/utils/bcm63xx-bootfs/Makefile
@@ -0,0 +1,34 @@
+# SPDX-License-Identifier: GPL-2.0-only
+
+include $(TOPDIR)/rules.mk
+
+PKG_NAME:=bcm63xx-bootfs
+PKG_RELEASE:=1
+
+include $(INCLUDE_DIR)/package.mk
+
+define Package/bcm63xx-bootfs
+  SECTION:=utils
+  CATEGORY:=Base system
+  TITLE:=Utility for modifying JFFS2 bootfs images
+  MAINTAINER:=Rafał Miłecki 
+  DEPENDS:=@TARGET_bcm4908
+endef
+
+define Package/bcm63xx-bootfs/description
+ This package contains an utility that can modify bootfs images. It's useful
+ when image needs to be adjusted before flashing it.
+endef
+
+define Build/Compile
+   $(MAKE) -C $(PKG_BUILD_DIR) \
+   CC="$(TARGET_CC)" \
+   CFLAGS="$(TARGET_CFLAGS) -Wall"
+endef
+
+define Package/bcm63xx-bootfs/install
+   $(INSTALL_DIR) $(1)/usr/bin
+   $(INSTALL_BIN) $(PKG_BUILD_DIR)/bcm63xx-bootfs $(1)/usr/bin/
+endef
+
+$(eval $(call BuildPackage,bcm63xx-bootfs))
diff --git a/package/utils/bcm63xx-bootfs/src/Makefile 
b/package/utils/bcm63xx-bootfs/src/Makefile
new file mode 100644
index 00..e06de9739f
--- /dev/null
+++ b/package/utils/bcm63xx-bootfs/src/Makefile
@@ -0,0 +1,7 @@
+all: bcm63xx-bootfs
+
+bcm63xx-bootfs:
+   $(CC) $(CFLAGS) -o $@ bcm63xx-bootfs.c -Wall
+
+clean:
+   rm -f bcm63xx-bootfs
diff --git a/package/utils/bcm63xx-bootfs/src/bcm63xx-bootfs.c 
b/package/utils/bcm63xx-bootfs/src/bcm63xx-bootfs.c
new file mode 100644
index 00..07bb4d4e7d
--- /dev/null
+++ b/package/utils/bcm63xx-bootfs/src/bcm63xx-bootfs.c
@@ -0,0 +1,378 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Copyright (C) 2021 Rafał Miłecki 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+static int debug;
+
+#define JFFS2_MAGIC_BITMASK 0x1985
+
+#define JFFS2_COMPR_NONE   0x00
+#define JFFS2_COMPR_ZERO   0x01
+#define JFFS2_COMPR_RTIME  0x02
+#define JFFS2_COMPR_RUBINMIPS  0x03
+#define JFFS2_COMPR_COPY   0x04
+#define JFFS2_COMPR_DYNRUBIN   0x05
+#define JFFS2_COMPR_ZLIB   0x06
+#define JFFS2_COMPR_LZO0x07
+/* Compatibility flags. */
+#define JFFS2_COMPAT_MASK 0xc000  /* What do to if an unknown nodetype is 
found */
+#define JFFS2_NODE_ACCURATE 0x2000
+/* INCOMPAT: Fail to mount the filesystem */
+#define JFFS2_FEATURE_INCOMPAT 0xc000
+/* ROCOMPAT: Mount read-only */
+#define JFFS2_FEATURE_ROCOMPAT 0x8000
+/* RWCOMPAT_COPY: Mount read/write, and copy the node when it's GC'd */
+#define JFFS2_FEATURE_RWCOMPAT_COPY 0x4000
+/* RWCOMPAT_DELETE: Mount read/write, and delete the node when it's GC'd */
+#define JFFS2_FEATURE_RWCOMPAT_DELETE 0x
+
+#define JFFS2_NODETYPE_DIRENT (JFFS2_FEATURE_INCOMPAT | JFFS2_NODE_ACCURATE | 
1)
+
+typedef struct {
+   uint32_t v32;
+} __attribute__((packed)) jint32_t;
+
+typedef struct {
+   uint16_t v16;
+} __attribute__((packed)) jint16_t;
+
+struct jffs2_unknown_node
+{
+   /* All start like this */
+   jint16_t magic;
+   jint16_t nodetype;
+   jint32_t totlen; /* So we can skip over nodes we don't grok */
+   jint32_t hdr_crc;
+};
+
+struct jffs2_raw_dirent
+{
+   jint16_t magic;
+   jint16_t nodetype;  /* == JFFS2_NODETYPE_DIRENT */
+   jint32_t totlen;
+   jint32_t hdr_crc;
+   jint32_t pino;
+   jint32_t version;
+   jint32_t ino; /* == zero for unlink */
+   jint32_t mctime;
+   uint8_t nsize;
+   uint8_t type;
+   uint8_t unused[2];
+   jint32_t node_crc;
+   jint32_t name_crc;
+   uint8_t name[0];
+};
+
+#define je16_to_cpu(x) ((x).v16)
+#define je32_to_cpu(x) ((x).v32)
+
+/**
+ * CRC32
+ **/
+
+static const uint32_t crc32_tbl[] = {
+   0x, 0x77073096, 0xee0e612c, 0x990951ba,
+   0x076dc419, 0x706af48f, 0xe963a535, 0x9e6495a3,
+   0x0edb8832, 0x79dcb8a4, 0xe0d5e91e, 0x97d2d988,
+   0x09b64c2b, 0x7eb17cbd, 0xe7b82d07, 0x90bf1d91,
+   0x1db71064, 0x6ab020f2, 0xf3b97148, 0x84be41de,
+   0x1adad47d, 0x6ddde4eb, 0xf4d4b551, 0x83d385c7,
+   0x136c9856, 0x646ba8c0, 0xfd62f97a, 0x8a65c9ec,
+   0x14015c4f, 0x63066cd9, 0xfa0f3d63, 0x8d080df5,
+   0x3b6e20c8, 0x4c69105e, 0xd56041e4, 

Re: ath79: Fix for Mikrotik NAND bad blocks - testers needed

2021-03-23 Thread Sergey Ryazanov
Hello Danijel!

On Mon, Mar 22, 2021 at 11:54 PM Danijel  wrote:
> I'm working on restoring Mikrotik RB2011 support after ar71xx target was
> dropped after 19.07 release. While working on it, the problem with bad blocks
> and the issue of the current way of flashing kernel was also brought up.
>
> Right now, for Mikrotiks we use kernel2minor which generates a 4MiB YAFFS2
> partition image holding the kernel binary.
> This method can't take NAND bad blocks in the kernel partition area into
> account, and if there are any, flashing fails and the device is usable only
> for RouterOS, because YAFFS2 support was removed from OpenWrt a few years ago.
>
> I was able to re-add YAFFS2 driver and limit it only to Mikrotik builds of
> ath79 target, and in my tests it properly mounts the kernel partition and
> replaces the kernel binary. However, I don't have a device with bad blocks in
> the kernel area so I can't confirm if it will properly handle them, although
> it should work unless the upstream driver (or Kconfig) is messed up.

Thank you for taking care of this. Missing of YAFFS2 support causes
more issues besides the bad block in the kernel area. E.g. 'large' and
'64m' images for boards with different block formats. So I am for
YAFFS2 support!

> So now I'm looking for testers (and reviewers) who could test this change on
> the affected devices (with bad blocks) and NOR Mikrotiks.

I have a couple of RB433 boards somewhere with BB in the kernel area.
I will try to find them and test with your changes.

-- 
Sergey

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


Re: ath79: Fix for Mikrotik NAND bad blocks - testers needed

2021-03-23 Thread Danijel
> I have a few RB493G boards that will not boot OpenWrt due to the bad
> blocks problem. Might your work work with them?
Yes, if you first return to RouterOS (to create a proper kernel partition),
you can build a new image with my changes, boot initramfs and try
flashing the sysupgrade to NAND. The modified sysupgrade process
mounts the YAFFS2 kernel partition and replaces the kernel file,
instead of blindly overwriting the partition on the block level.

> I would be willing to split shipping
> and charge no more than that (I am in the USA).
I'm in the EU so maybe we should start with you testing a few
problematic boards yourself before shipping them, if you can.

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


Merged: rules: fix device and chain usage forDSCP/MARK targets

2021-03-23 Thread Jo-Philipp Wich
Merged into project/firewall3.git, branch master at
http://git.openwrt.org/?p=project/firewall3.git.

Thank you!


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


Merged: zone: avoid duplicates in devices list

2021-03-23 Thread Jo-Philipp Wich
Merged into project/firewall3.git, branch master at
http://git.openwrt.org/?p=project/firewall3.git.

Thank you!


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