Re: Compile only root filesystem like Buildroot

2023-01-08 Thread Arınç ÜNAL

Quoting me and Luiz's message.


On 9.01.2023 05:17, Luiz Angelo Daros de Luca wrote:

Hi Arınç,


Is it possible to create a root filesystem archive?


CONFIG_TARGET_ROOTFS_TARGZ ?


Ah, of course. Thanks.

OpenWrt filesystem hasn’t got /init. I get this error when I link the 
filesystem with the kernel.

[3.495199] List of all partitions:
[3.498698] No filesystem could mount root, tried:
[3.498706]
[3.505060] Kernel panic - not syncing: VFS: Unable to mount root fs on 
unknown-block(0,0)
[3.513308] ---[ end Kernel panic - not syncing: VFS: Unable to mount root 
fs on unknown-block(0,0) ]---

Configuring CONFIG_DEFAULT_INIT to /sbin/init on kernel or adding 
init=/sbin/init to kernel command line surprisingly won’t change anything. So I 
put this as /init. Now it boots fine.

#!/bin/sh
exec /sbin/init "$@"




Is there a directory
where the final filesystem is extracted before turned to a squashfs image?


build_dir/target-mipsel_24kc_musl/root-ramips/ ?



I know there's buildroot for this but I want to use LuCI, buildroot
seems to only have uci.


BTW, I'm working back with rtl8365mb driver. I implemented forwarding
offload and mtu change but it breaks vlan security. We need a proper
vlan support before the HW does the forwarding. I'm working on that
right now.


Hey that's great! Not to put more work on you but could you take a look at 
supporting the BR_ISOLATED port flag once you're done? My folks did some work 
messing with the port matrix on mt7530.c to support port isolation for DSA 
interfaces on MT7530 and MT7531 switches.


Arınç



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


Re: [PATCH v2 6/7] coreutils: Import from packages feed

2023-01-08 Thread Brian Norris
On Sun, Jan 8, 2023 at 1:37 PM Thibaut  wrote:
> > Le 8 janv. 2023 à 21:53, Christian Marangi  a écrit :
> >
> > On Sun, Jan 08, 2023 at 09:00:58PM +0100, Petr Štetiar wrote:
> >> Brian Norris  [2023-01-06 23:49:44]:
> >>
> >> Hi Brian,
> >>
> >>> I need to express a per-target dependency on the 'base64' utility, and
> >>> that's seemingly impossible to do for busybox.
> >>
> >>  --- a/target/linux/ipq806x/Makefile
> >>  +++ b/target/linux/ipq806x/Makefile
> >>  @@ -15,6 +15,11 @@ KERNEL_PATCHVER:=5.15
> >>   KERNELNAME:=zImage Image dtbs
> >>
> >>   include $(INCLUDE_DIR)/target.mk
> >>  +
> >>  +DEPENDS:= \
> >>  +   +@BUSYBOX_DEFAULT_BASE64
> >>  +

Thanks! That does indeed work for me. And I might just throw it into
target/linux/ipq806x/chromium/target.mk instead, since the generic
target won't be using base64.

> > Is this already used for other target? Wonder if this special thing
> > would cause some problem for packages of this target? Like discrepancy
> > with stage2 and final image?

stage2 as in sysupgrade? I don't immediately see how that would be a
problem, but maybe I'm not understanding well enough.

> AFAICT this isn’t used anywhere so far (at least according to a quick git 
> grep).

Right, I couldn't find any other target tweaking BUSYBOX_DEFAULT_* in
the current tree or in the git history.

And I can't even find anyone doing a bare 'DEPENDS:=' in their
Makefile under target/linux/ at all. All usages are as part of
packages (modules), not device/target specifications.

> > Anyway this looks to be the best solution for the problem.
>
> I wonder if it’s such a good idea to have discrepancies in busybox features 
> between targets?

I don't think I know enough about OpenWrt development yet to have a
good answer on this, so I'll let you all try to answer this.

But if I don't hear some specific negatives or some other consensus
within a day or few, I'll try BUSYBOX_DEFAULT_BASE64 for a v3.

Of course, I can also hold off sending if people were actively looking
at the other parts of this series still.

Brian

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


OpenWrt 22.03.3 third service release

2023-01-08 Thread Hauke Mehrtens

Hi,

The OpenWrt community is proud to announce the newest stable release of 
the OpenWrt 22.03 stable version series. It fixes security issues, 
improves device support, and brings a few bug fixes.


Download firmware images using the OpenWrt Firmware Selector:
 * https://firmware-selector.openwrt.org/?version=22.03.3
Download firmware images directly from our download servers:
 * https://downloads.openwrt.org/releases/22.03.3/targets/


Main changes between OpenWrt 22.03.2 and OpenWrt 22.03.3:


Security fixes
==

  * CVE-2022-30065: busybox: Fix a use-after-free in Busybox 1.35-x's
awk applet
  * CVE-2022-0934: dnsmasq: Fixes single-byte, non-arbitrary write/use-
after-free flaw in dnsmasq DHCPv6 server
  * CVE-2022-1304: e2fsprogs: An out-of-bounds read/write vulnerability
was found in e2fsprogs 1.46.5
  * CVE-2022-47939: kmod-ksmbd: ZDI-22-1690: Linux Kernel ksmbd Use-
After-Free Remote Code Execution Vulnerability
  * CVE-2022-46393: mbedtls: Fix potential heap buffer overread and
overwrite
  * CVE-2022-46392: mbedtls: An adversary with access to precise enough
information about memory accesses can recover an RSA private key
  * CVE 2022-42905: wolfssl: In the case that the WOLFSSL_CALLBACKS
macro is set when building wolfSSL, there is a potential heap over
read of 5 bytes when handling TLS 1.3 client connections.


Device support
==

  * Support for the following devices was added:
* Ruckus ZoneFlex 7372
* Ruckus ZoneFlex 7321
* ZTE MF289F
* TrendNet TEW-673GRU
* Linksys EA4500 v3
* Wavlink WS-WN572HP3 4G
  * Fix reboot loop by using LZMA loader. This affects the following
devices:
* NETGEAR EX6150
* HiWiFi HC5962
* ASUS RT-N56U B1
* Belkin F9K1109v1
* D-Link DIR-645
* D-Link DIR-860L B1
* NETIS WF2881
* ZyXEL WAP6805
  * Fix WAN mac address assignment. This affects the following devices:
* UniElec U7621-01
* UniElec U7621-06
* TP-Link AR7241
* TP-Link TL-WR740N
* TP-Link TL-WR741ND v4
* Teltonika RUT230
* Luma Home WRTQ-329ACN
  * mvebu: Disable devices using broken mv88e6176 switch. This affects
the following devices:
* CZ.NIC Turris Omnia
* Linksys WRT1200AC
* Linksys WRT1900ACS
* Linksys WRT1900AC v1
* Linksys WRT1900AC v2
* Linksys WRT3200ACM
* Linksys WRT32X
* Linksys WRT3200ACM
* SolidRun ClearFog Pro
  * lantiq/xrx200: Enable interrupts on second VPE
  * layerscape: Fix SPI-NOR issues with vendor patches
  * RouterBoard 912UAG: Fix reference clock
  * TP-Link RE200 v3/v4: Fix LED configuration
  * GL.iNet GL-MT1300: Fix flash access by reducing SPI clock
  * Youku YK-L2 and YK-L1: Allow installing initramfs-kernel.bin over
vendor web UI
  * D-Link DIR-825 B1: Add factory image recipe
  * D-Link DIR-825-B1: Expand rootfs
  * D-Link DGS-1210-10P: Add support for extra buttons and LEDs
  * Asus RT-AC88U: Include Broadcom 4366b1 firmware by default
  * AVM FRITZ!Box 7430: Include USB driver by default
  * HAOYU Electronics MarsBoard A10: Include sound driver by default
  * Linksys EA6350v3, EA8300, MR8300 and WHW01: Allow flashing Linksys
factory firmware


Various fixes and improvements
==

  * firewall4: Fix boot hang with firewall4 and loadfile
  * Added the following kernel packages:
* kmod-sched-prio (extracted from kmod-sched)
* kmod-sched-red (extracted from kmod-sched)
* kmod-sched-act-police (extracted from kmod-sched)
* kmod-sched-act-ipt (extracted from kmod-sched)
* kmod-sched-pie (extracted from kmod-sched)
* kmod-sched-drr
* kmod-sched-fq-pie
* kmod-sched-act-sample
* kmod-nvme
* kmod-phy-marvell
* kmod-hwmon-sht3x
* kmod-netconsole
* kmod-btsdio
  * Added firmware files for mt7916 and mt7921 devices
  * ucode: lexer: Fixes for regex literal parsing
  * hostapd: Remove dtim_period option from device, it is already a BSS
property
  * procd: Service: pass all arguments to service
  * ustream-openssl: Disable renegotiation in TLSv1.2 and earlier
  * comgt-ncm: Add support for quectel modem EC200T-EU
  * umbim: Allow roaming and partner connections
  * kernel: Add support for EON EN25QX128A spi nor flash
  * iwinfo: Many bugfixes and improvements:
* improvements in showing the used band, ht mode and hw mode
* Added support for HE (Wifi 6) modes
* Added support for new devices (MT7921AU, MT7986 WiSoC)
* Add support for CCMP-256 and GCMP-256 ciphers
  * uhttpd: Fix incorrectly emitting HTTP 413 for certain content
lengths
  * gcc: Import patch fixing asm machine directive for powerpc


Core components update
==

  * Update Linux kernel from 5.10.146 to 5.10.161
  * Update mac80211 backports from 5.15.58-1 to 5.15.81-1
  * Update strace from 5.16 to 5.19
  * Update mbedtls from 2.28.1 to 2.28.2
  * Update openssl from 

[sdwalker/sdwalker.github.io] 97238d: This week's update

2023-01-08 Thread Stephen Walker 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 ---
  Branch: refs/heads/master
  Home:   https://github.com/sdwalker/sdwalker.github.io
  Commit: 97238d72144a00cd989488db3289e98c41805024
  
https://github.com/sdwalker/sdwalker.github.io/commit/97238d72144a00cd989488db3289e98c41805024
  Author: Stephen Walker 
  Date:   2023-01-08 (Sun, 08 Jan 2023)

  Changed paths:
M uscan/index-21.02.html
M uscan/index-22.03.html
M uscan/index.html

  Log Message:
  ---
  This week's update



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


Re: [PATCH v2 6/7] coreutils: Import from packages feed

2023-01-08 Thread Thibaut


> Le 8 janv. 2023 à 21:53, Christian Marangi  a écrit :
> 
> On Sun, Jan 08, 2023 at 09:00:58PM +0100, Petr Štetiar wrote:
>> Brian Norris  [2023-01-06 23:49:44]:
>> 
>> Hi Brian,
>> 
>>> I need to express a per-target dependency on the 'base64' utility, and
>>> that's seemingly impossible to do for busybox.
>> 
>>  --- a/target/linux/ipq806x/Makefile
>>  +++ b/target/linux/ipq806x/Makefile
>>  @@ -15,6 +15,11 @@ KERNEL_PATCHVER:=5.15
>>   KERNELNAME:=zImage Image dtbs
>>   
>>   include $(INCLUDE_DIR)/target.mk
>>  +
>>  +DEPENDS:= \
>>  +   +@BUSYBOX_DEFAULT_BASE64
>>  +
>> 
> 
> Is this already used for other target? Wonder if this special thing
> would cause some problem for packages of this target? Like discrepancy
> with stage2 and final image?

AFAICT this isn’t used anywhere so far (at least according to a quick git grep).

> Anyway this looks to be the best solution for the problem.

I wonder if it’s such a good idea to have discrepancies in busybox features 
between targets?

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


Re: [PATCH v2 6/7] coreutils: Import from packages feed

2023-01-08 Thread Christian Marangi
On Sun, Jan 08, 2023 at 09:00:58PM +0100, Petr Štetiar wrote:
> Brian Norris  [2023-01-06 23:49:44]:
> 
> Hi Brian,
> 
> > I need to express a per-target dependency on the 'base64' utility, and
> > that's seemingly impossible to do for busybox.
> 
>   --- a/target/linux/ipq806x/Makefile
>   +++ b/target/linux/ipq806x/Makefile
>   @@ -15,6 +15,11 @@ KERNEL_PATCHVER:=5.15
>KERNELNAME:=zImage Image dtbs
>
>include $(INCLUDE_DIR)/target.mk
>   +
>   +DEPENDS:= \
>   +   +@BUSYBOX_DEFAULT_BASE64
>   +
> 

Is this already used for other target? Wonder if this special thing
would cause some problem for packages of this target? Like discrepancy
with stage2 and final image?

Anyway this looks to be the best solution for the problem.

-- 
Ansuel

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


Re: [PATCH v2 6/7] coreutils: Import from packages feed

2023-01-08 Thread Petr Štetiar
Brian Norris  [2023-01-06 23:49:44]:

Hi Brian,

> I need to express a per-target dependency on the 'base64' utility, and
> that's seemingly impossible to do for busybox.

--- a/target/linux/ipq806x/Makefile
+++ b/target/linux/ipq806x/Makefile
@@ -15,6 +15,11 @@ KERNEL_PATCHVER:=5.15
 KERNELNAME:=zImage Image dtbs
 
 include $(INCLUDE_DIR)/target.mk
+
+DEPENDS:= \
+   +@BUSYBOX_DEFAULT_BASE64
+

Cheers,

Petr

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


Compile only root filesystem like Buildroot

2023-01-08 Thread Arınç ÜNAL
Is it possible to create a root filesystem archive? Is there a directory 
where the final filesystem is extracted before turned to a squashfs image?


I know there's buildroot for this but I want to use LuCI, buildroot 
seems to only have uci.


Arınç

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


Re: [PATCH v4] ramips: mt7621: Add Arcadyan WE420223-99 support

2023-01-08 Thread Arınç ÜNAL

On 8.01.2023 19:03, Harm Berntsen wrote:

The Arcadyan WE420223-99 is a WiFi AC simultaneous dual-band access
point distributed as Experia WiFi by KPN in the Netherlands. It features
two ethernet ports and 2 internal antennas.

Specifications
--
SOC   : Mediatek MT7621AT
ETH   : Two 1 gigabit ports, built into the SOC
WIFI  : MT7615DN
BUTTON: Reset
BUTTON: WPS
LED   : Power (green+red)
LED   : WiFi (green+blue)
LED   : WPS (green+red)
LED   : Followme (green+red)
Power : 12 VDC, 1A barrel plug

Winbond variant:
RAM   : Winbond W631GG6MB12J, 1GBIT DDR3 SDRAM
Flash : Winbond W25Q256JVFQ, 256Mb SPI
U-Boot: 1.1.3 (Nov 23 2017 - 16:40:17), Ralink 5.0.0.1

Macronix variant:
RAM   : Nanya NT5CC64M16GP-DI, 1GBIT DDR3 SDRAM
Flash : MX25l25635FMI-10G, 256Mb SPI
U-Boot: 1.1.3 (Dec  4 2017 - 11:37:57), Ralink 5.0.0.1

Serial
--
The serial port needs a TTL/RS-232 3V3 level converter! The Serial
setting is 57600-8-N-1. The board has an unpopulated 2.54mm straight pin
header.

The pinout is: VCC (the square), RX, TX, GND.

Installation

See the Wiki page [1] for more details, it comes down to:

1. Open the device, take off the heat sink
2. Connect the SPI flash chip to a flasher, e.g. a Raspberry Pi. Also
connect the RESET pin for stability (thanks @FPSUsername for reporting)
3. Make a backup in case you want to revert to stock later
4. Flash the squashfs-factory.trx file to offset 0x5 of the flash
5. Ensure the bootpartition variable is set to 0 in the U-Boot
environment located at 0x3

Note that the U-Boot is password protected, this can optionally be
removed. See the forum [2] for more details.

MAC Addresses(stock)

+--+--+---+
| use  | address  | example   |
+--+--+---+
| Device   | label| 00:00:00:11:00:00 |
| Ethernet | + 3  | 00:00:00:11:00:03 |
| 2g   | + 0x02f1 | 02:00:00:01:00:01 |
| 5g   | + 1  | 00:00:00:11:00:01 |
+--+--+---+

The label address is stored in ASCII in the board_data partition

Notes
-
- This device has a dual-boot partition scheme, but OpenWRT will claim
   both partitions for more storage space.

Known issues

- 2g MAC address does not match stock due to missing support for that in
   macaddr_add
- Only the power LED is configured by default

References
--
[1] https://openwrt.org/inbox/toh/arcadyan/astoria/we420223-99
[2] 
https://forum.openwrt.org/t/adding-openwrt-support-for-arcadyan-we420223-99-kpn-experia-wifi/132653

Signed-off-by: Harm Berntsen 


Acked-by: Arınç ÜNAL 

Hold on to this next time.

Arınç

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


[PATCH v4] ramips: mt7621: Add Arcadyan WE420223-99 support

2023-01-08 Thread Harm Berntsen 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 ---
The Arcadyan WE420223-99 is a WiFi AC simultaneous dual-band access
point distributed as Experia WiFi by KPN in the Netherlands. It features
two ethernet ports and 2 internal antennas.

Specifications
--
SOC   : Mediatek MT7621AT
ETH   : Two 1 gigabit ports, built into the SOC
WIFI  : MT7615DN
BUTTON: Reset
BUTTON: WPS
LED   : Power (green+red)
LED   : WiFi (green+blue)
LED   : WPS (green+red)
LED   : Followme (green+red)
Power : 12 VDC, 1A barrel plug

Winbond variant:
RAM   : Winbond W631GG6MB12J, 1GBIT DDR3 SDRAM
Flash : Winbond W25Q256JVFQ, 256Mb SPI
U-Boot: 1.1.3 (Nov 23 2017 - 16:40:17), Ralink 5.0.0.1

Macronix variant:
RAM   : Nanya NT5CC64M16GP-DI, 1GBIT DDR3 SDRAM
Flash : MX25l25635FMI-10G, 256Mb SPI
U-Boot: 1.1.3 (Dec  4 2017 - 11:37:57), Ralink 5.0.0.1

Serial
--
The serial port needs a TTL/RS-232 3V3 level converter! The Serial
setting is 57600-8-N-1. The board has an unpopulated 2.54mm straight pin
header.

The pinout is: VCC (the square), RX, TX, GND.

Installation

See the Wiki page [1] for more details, it comes down to:

1. Open the device, take off the heat sink
2. Connect the SPI flash chip to a flasher, e.g. a Raspberry Pi. Also
   connect the RESET pin for stability (thanks @FPSUsername for reporting)
3. Make a backup in case you want to revert to stock later
4. Flash the squashfs-factory.trx file to offset 0x5 of the flash
5. Ensure the bootpartition variable is set to 0 in the U-Boot
   environment located at 0x3

Note that the U-Boot is password protected, this can optionally be
removed. See the forum [2] for more details.

MAC Addresses(stock)

+--+--+---+
| use  | address  | example   |
+--+--+---+
| Device   | label| 00:00:00:11:00:00 |
| Ethernet | + 3  | 00:00:00:11:00:03 |
| 2g   | + 0x02f1 | 02:00:00:01:00:01 |
| 5g   | + 1  | 00:00:00:11:00:01 |
+--+--+---+

The label address is stored in ASCII in the board_data partition

Notes
-
- This device has a dual-boot partition scheme, but OpenWRT will claim
  both partitions for more storage space.

Known issues

- 2g MAC address does not match stock due to missing support for that in
  macaddr_add
- Only the power LED is configured by default

References
--
[1] https://openwrt.org/inbox/toh/arcadyan/astoria/we420223-99
[2] 
https://forum.openwrt.org/t/adding-openwrt-support-for-arcadyan-we420223-99-kpn-experia-wifi/132653

Signed-off-by: Harm Berntsen 
---
Changed in v4:

- Fix uboot-envtools config. Well spotted Hauke!
- Update mt7621.mk: remove dependency on kmod-mt7615e, akin to
  9a07895729 (mt76: add stand-alone MT7622 firmware package, 2022-12-17)


 package/boot/uboot-envtools/files/ramips  |   3 +
 .../dts/mt7621_arcadyan_we420223-99.dts   | 219 ++
 target/linux/ramips/image/mt7621.mk   |  25 ++
 .../mt7621/base-files/etc/board.d/02_network  |   8 +
 .../etc/hotplug.d/ieee80211/10_fix_wifi_mac   |   9 +
 .../mt7621/base-files/lib/upgrade/platform.sh |   1 +
 6 files changed, 265 insertions(+)
 create mode 100644 target/linux/ramips/dts/mt7621_arcadyan_we420223-99.dts

diff --git a/package/boot/uboot-envtools/files/ramips 
b/package/boot/uboot-envtools/files/ramips
index 372b8a49e2..6086682783 100644
--- a/package/boot/uboot-envtools/files/ramips
+++ b/package/boot/uboot-envtools/files/ramips
@@ -21,6 +21,9 @@ engenius,esr600h|\
 sitecom,wlr-4100-v1-002)
ubootenv_add_uci_config "/dev/mtd1" "0x0" "0x1000" "0x1000"
;;
+arcadyan,we420223-99)
+   ubootenv_add_uci_config "/dev/mtd2" "0x0" "0x1000" "0x1000"
+   ;;
 allnet,all0256n-4m|\
 allnet,all0256n-8m|\
 allnet,all5002|\
diff --git a/target/linux/ramips/dts/mt7621_arcadyan_we420223-99.dts 
b/target/linux/ramips/dts/mt7621_arcadyan_we420223-99.dts
new file mode 100644
index 00..99de770707
--- /dev/null
+++ b/target/linux/ramips/dts/mt7621_arcadyan_we420223-99.dts
@@ -0,0 +1,219 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+
+#include "mt7621.dtsi"
+
+#include 
+#include 
+#include 
+
+/ {
+   model = "Arcadyan WE420223-99";
+   compatible = "arcadyan,we420223-99", "mediatek,mt7621-soc";
+
+   aliases {
+   led-boot = _power_green;
+   led-failsafe = _power_red;
+   led-running = _power_green;
+   led-upgrade = _wps_green;
+   led-wifi = _wifi_green;
+   };
+
+   chosen {
+   bootargs = "console=ttyS0,57600 ubi.mtd=5 
root=/dev/ubiblock0_0";
+   };
+
+   keys {
+   

Re: [PATCH v2 6/7] coreutils: Import from packages feed

2023-01-08 Thread edgar . soldin

On 08.01.2023 00:02, Thibaut wrote:




Le 7 janv. 2023 à 22:41, Robert Marko  a écrit :

On Sat, 7 Jan 2023 at 16:26, Thibaut VARÈNE  wrote:





Le 7 janv. 2023 à 15:06, Christian Marangi  a écrit :

On Fri, Jan 06, 2023 at 11:49:44PM -0800, Brian Norris wrote:

I need to express a per-target dependency on the 'base64' utility, and
that's seemingly impossible to do for busybox. Pull in coreutils to make
that easier.

Signed-off-by: Brian Norris 


We still need to think of a correct solution for this... coreutils is an
option but wonder if a better one is openssl... Actually we have a small
tool to handle specific decryption of some stuff... Wonder if that can
be expanded for this task and just use wolfssl or openssl api to decode
base64 stuff?


Using one or the other would impose (i.e. (en)force) that SSL library on this 
particular target. Do we want this, especially considering the ongoing 
conversation about mbedTLS?

Also pulling an entire SSL implementation just to decode base64 seems a tad 
overkill too.


I agree on this one, forcing usage of OpenSSL isn't ideal, coreutils
is a better option for sure.


There might be an even easier/lighter way (short of enabling base64 in 
busybox), AWK to the rescue:
https://github.com/shane-kerr/AWK-base64decode

The code is clean and judging by the comment line 97, works with busybox awk.


how is luci doing base64 en/decoding? that should be available in default 
images. if it's using lua, that should be available in every image even without 
web-interface or?

..ede

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


Re: [PATCH] archs38: mark as source-only

2023-01-08 Thread Robert Marko
On Thu, 29 Dec 2022 at 19:23, Robert Marko  wrote:
>
> archs38 seems to be pretty much unused, usually only treewide changes or
> kernel bumps in order to branch off new stable are done to it.
>
> Considering that target only support some Synopsis HS38 ARC reference
> boards and no consumer hardware so mark the target as source-only to stop
> using Buildbot resources on building the target and packages for it.

Just a friendly ping, to see if there are any objections against this.

Regards,
Robert
>
> Signed-off-by: Robert Marko 
> ---
>  target/linux/archs38/Makefile | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/target/linux/archs38/Makefile b/target/linux/archs38/Makefile
> index e08f779170..756de43561 100644
> --- a/target/linux/archs38/Makefile
> +++ b/target/linux/archs38/Makefile
> @@ -8,6 +8,7 @@ ARCH:=arc
>  CPU_TYPE:=archs
>  BOARD:=archs38
>  BOARDNAME:=Synopsys DesignWare ARC HS38
> +FEATURES:=source-only
>  SUBTARGETS:=generic
>
>  KERNEL_PATCHVER:=5.10
> --
> 2.38.1
>

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


Re: BCM53xx on D-Link DIR-890L - 2MB max problem

2023-01-08 Thread Linus Walleij
On Sun, Jan 8, 2023 at 9:48 AM Arınç ÜNAL  wrote:

> Then why is it CFE that tries to decompress the image in this case? This
> is what I understand when I look at the log Linus put.

The CFE on BCM53xx always expects an LZMA object inside a SEAMA
container I think, we take the already compressed zImage for ARM
and compress it again with LZMA.

Sadly it gets more than 2MB in size so CFE can't handle it...

Yours,
Linus Walleij

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


Re: BCM53xx on D-Link DIR-890L - 2MB max problem

2023-01-08 Thread Arınç ÜNAL
Funny Linus thought to mention me since I've been working on booting 
stuff on arm and mips boards very recently.


On 8.01.2023 06:18, Chuanhong Guo wrote:

Hi!

On Sun, Jan 8, 2023 at 7:38 AM Linus Walleij  wrote:

I guess trying to figure out what lzma-loader does and implement
the same for ARM is the way to go, or at some point I felt like
implementing U-Boot for the BCM53xx and implement SEAMA
loading from NAND in U-Boot is maybe easier...


The ARM zImage is supposed to be self-extracting, right?
Is it possible to package that as an uncompressed code for
u-boot?


That's correct, take a look at this answer.

https://stackoverflow.com/a/22338835


lzma-loader was created at the time when MIPS didn't have
zboot support. In ramips, the lzma-loader does the same
work as the kernel zboot image: It's a loader which extracts
the actual kernel code to the memory. The compressed kernel
is linked as a part of the lzma-loader so it doesn't need any
flash access.


Then why is it CFE that tries to decompress the image in this case? This 
is what I understand when I look at the log Linus put. It should see the 
image on NAND memory as uncompressed and just leave it to the 
lzma-loader linked with the kernel code to decompress.


We can add compression information of the kernel for U-Boot with mkimage 
but I don't know how it works with CFE.


Arınç

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