Re: [PATCH 1/3] base-files: sysupgrade: add tar.sh with helpers for building archives
On 26.02.2024 22:27, Paul D wrote:
diff --git a/package/base-files/files/lib/upgrade/tar.sh
b/package/base-files/files/lib/upgrade/tar.sh
new file mode 100644
index 00..00057dd760
--- /dev/null
+++ b/package/base-files/files/lib/upgrade/tar.sh
@@ -0,0 +1,84 @@
No shebang?
Files /lib/upgrade/*.sh are for including.
+# SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+
+__tar_print_padding() {
+ [ $1 -eq 0 ] || dd if=/dev/zero bs=$1 count=1 2>/dev/null
+}
+
+__tar_make_member() {
+ local name="$1"
+ local content="$2"
+ local username="$3"
+ local groupname="$4"
+ local mtime="$5"
+ local mode=644
+ local uid=0
+ local gid=0
+ local size=${#content}
+ local type=0
+ local link=""
+
recommend that they're ordered here same as struct order:
struct posix_header
{ /* byte offset */
char name[100]; /* 0 */
char mode[8]; /* 100 */
char uid[8]; /* 108 */
char gid[8]; /* 116 */
char size[12]; /* 124 */
char mtime[12]; /* 136 */
char chksum[8]; /* 148 */
char typeflag; /* 156 */
char linkname[100]; /* 157 */
char magic[6]; /* 257 */
char version[2]; /* 263 */
char uname[32]; /* 265 */
char gname[32]; /* 297 */
char devmajor[8]; /* 329 */
char devminor[8]; /* 337 */
char prefix[155]; /* 345 */
/* 500 */
};
I'm not sure about it. In the first place I want code to be easy to
understand and maintain. Using some non-natural order (like messing with
order of argument variables and local variables) will be confusing.
+ local
pad=$'\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1'
+
maybe try:
local pad=$(printf '\1%.0s' $(seq 100))
They produce the same result I believe:
# echo
$'\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1'
| md5sum
59c89925a4ef5bee948db1ec5dc9a4c4 -
# echo $(printf '\1%.0s' $(seq 100)) | md5sum
59c89925a4ef5bee948db1ec5dc9a4c4 -
The first is longer however it avoids two subshell executions. I don't
think there's a single winner here.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 1/3] base-files: sysupgrade: add tar.sh with helpers for building archives
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 --- Sent with Proton Mail secure email. On Tuesday, February 27th, 2024 at 15:46, Eric wrote: > On Tuesday, February 27th, 2024 at 13:41, Jo-Philipp Wich j...@mein.io wrote: > > > I think the uid and gid values should correspond to the given username > > and groupname values. Something like this would probably work: > > > > local uid=$(id -u "$username") > > local gid=$(sed -rne "s#^$groupname:[^:]:([0-9]+):.\$#\1#p" /etc/group) > > > Does this do the same thing? > > local gid=$(uid -g "$groupname") OOPS typo, 'id -g ...' --- End Message --- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 1/3] base-files: sysupgrade: add tar.sh with helpers for building archives
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 Tuesday, February 27th, 2024 at 13:41, Jo-Philipp Wich wrote: > I think the uid and gid values should correspond to the given username > and groupname values. Something like this would probably work: > > local uid=$(id -u "$username") > local gid=$(sed -rne "s#^$groupname:[^:]:([0-9]+):.\$#\1#p" /etc/group) Does this do the same thing? local gid=$(uid -g "$groupname") Eric --- End Message --- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 1/3] base-files: sysupgrade: add tar.sh with helpers for building archives
Hi Rafał,
thanks for taking are of this. Please find some comments below.
Am 2/26/24 um 15:14 schrieb Rafał Miłecki:
From: Jo-Philipp Wich
This allows building uncompressed tar archives from shell scripts (and
compressing them later if needed)
Signed-off-by: Rafał Miłecki
---
package/base-files/files/lib/upgrade/tar.sh | 84 +
1 file changed, 84 insertions(+)
create mode 100644 package/base-files/files/lib/upgrade/tar.sh
diff --git a/package/base-files/files/lib/upgrade/tar.sh
b/package/base-files/files/lib/upgrade/tar.sh
new file mode 100644
index 00..00057dd760
--- /dev/null
+++ b/package/base-files/files/lib/upgrade/tar.sh
@@ -0,0 +1,84 @@
+# SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+
+__tar_print_padding() {
+ [ $1 -eq 0 ] || dd if=/dev/zero bs=$1 count=1 2>/dev/null
+}
+
+__tar_make_member() {
+ local name="$1"
+ local content="$2"
+ local username="$3"
+ local groupname="$4"
+ local mtime="$5"
+ local mode=644
I think the uid and gid values should correspond to the given username
and groupname values. Something like this would probably work:
local uid=$(id -u "$username")
local gid=$(sed -rne "s#^$groupname:[^:]*:([0-9]+):.*\$#\1#p" /etc/group)
+ local uid=0
+ local gid=0
+ local size=${#content}
+ local type=0
+ local link=""
+
+ # 100 byte of padding bytes, using 0x01 since the shell does not tolate
null bytes in strings
+ local
pad=$'\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1'
+
+ # validate name
+ if [ "${name:0:1}" = "/" ]; then
+ name="${name:1}"
+ fi
+
+ # truncate string header values to their maximum length
+ name=${name:0:100}
+ link=${link:0:100}
+ username=${username:0:32}
+ groupname=${groupname:0:32}
+
+ # construct header part before checksum field
+ local header1="${name}${pad:0:$((100 - ${#name}))}"
+ header1="${header1}$(printf '%07d\1' $mode)"
+ header1="${header1}$(printf '%07o\1' $uid)"
+ header1="${header1}$(printf '%07o\1' $gid)"
+ header1="${header1}$(printf '%011o\1' $size)"
+ header1="${header1}$(printf '%011o\1' $mtime)"
+
+ # construct header part after checksum field
+ local header2="$(printf '%d' $type)"
+ header2="${header2}${link}${pad:0:$((100 - ${#link}))}"
+ header2="${header2}ustar ${pad:0:1}"
+ header2="${header2}${username}${pad:0:$((32 - ${#username}))}"
+ header2="${header2}${groupname}${pad:0:$((32 - ${#groupname}))}"
+
+ # calculate checksum over header fields
+ local checksum=0
+ for byte in $(printf '%s%8s%s' "$header1" "" "$header2" | tr '\1' '\0' | hexdump
-ve '1/1 "%u "'); do
+ checksum=$((checksum + byte))
+ done
+
+ # print member header, padded to 512 byte
+ printf '%s%06o\0 %s' "$header1" $checksum "$header2" | tr '\1' '\0'
+ __tar_print_padding 183
I checked and noticed that `dd` accepts a `count` value of 0, so we can
inline `__tar_print_padding()` (whose sole purpose was the != 0 check)
and get rid of the extra function:
dd if=/dev/zero bs=183 count=1 2>/dev/null
+
+ # print content data, padded to multiple of 512 byte
+ printf "%s" "$content"
+ __tar_print_padding $((512 - (size % 512)))
Inline this `__tar_print_padding()` as (count may be zero):
dd if=/dev/zero bs=1 count=$((512 - (size % 512))) 2>/dev/null
+}
+
+tar_make_member_from_file() {
+ local name="$1"
+ local username="$(ls -l "$1" | tr -s ' ' | cut -d ' ' -f 3)"
+ local groupname="$(ls -l "$1" | tr -s ' ' | cut -d ' ' -f 4)"
+
+ __tar_make_member "$name" "$(cat $name)" "$username" "$groupname" "$(date +%s -r
"$1")"
+}
+
+tar_make_member_inline() {
+ local name="$1"
+ local content="$2"
+ local username="${3:-root}"
+ local groupname="${4:-root}"
+ local mtime="${5:-$(date +%s)}"
+
+ __tar_make_member "$name" "$content" "$username" "$groupname" "$mtime"
+}
+
+tar_close() {
+ __tar_print_padding 1024
Inline this `__tar_print_padding()` as:
dd if=/dev/zero bs=1024 count=1 2>/dev/null
+}
~ Jo
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
lldpd: FAO stintel and all committers to openwrt repo
The last PR that you merged included some fatal copy/paste errors. At least the first PR below fixes them https://github.com/openwrt/openwrt/pull/14583 https://github.com/openwrt/openwrt/pull/14584 I have some other fixes pending but those depend on these PRs. /P ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] image: drop IB guards around dtb recipes
From: Tomasz Maciej Nowak This guard is unnecessary, since target using these recipes are already exempted from running in Image Builder. Signed-off-by: Tomasz Maciej Nowak --- include/image.mk | 2 -- 1 file changed, 2 deletions(-) diff --git a/include/image.mk b/include/image.mk index 3a92fb0c8cab..e54f06a44703 100644 --- a/include/image.mk +++ b/include/image.mk @@ -575,7 +575,6 @@ define Device/Build/compile endef -ifndef IB define Device/Build/dtb ifndef BUILD_DTS_$(1) BUILD_DTS_$(1) := 1 @@ -597,7 +596,6 @@ define Device/Build/dtbo endif endef -endif define Device/Build/kernel $$(eval $$(foreach dts,$$(DEVICE_DTS), \ -- 2.44.0 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] image: build dtb with host compiler for image builder
From: Tomasz Maciej Nowak Device tree blobs are arch agnostic, so we don't need to cross compile them. Signed-off-by: Tomasz Maciej Nowak --- include/image.mk | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/image.mk b/include/image.mk index 4b6acbe1aad6..3a92fb0c8cab 100644 --- a/include/image.mk +++ b/include/image.mk @@ -180,7 +180,7 @@ endef # $(3) extra CPP flags # $(4) extra DTC flags define Image/BuildDTB/sub - $(TARGET_CROSS)cpp -nostdinc -x assembler-with-cpp \ + $(if IB, , $(TARGET_CROSS))cpp -nostdinc -x assembler-with-cpp \ $(DTS_CPPFLAGS) \ -I$(DTS_DIR) \ -I$(DTS_DIR)/include \ -- 2.44.0 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] imagebuilder: include device tree bindings
From: Tomasz Maciej Nowak
Image Builder includes target dts which might reference device tree
bindings for various integrated peripherals and trying to build dtb
without access to bindings will fail.
Signed-off-by: Tomasz Maciej Nowak
---
target/imagebuilder/Makefile | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/target/imagebuilder/Makefile b/target/imagebuilder/Makefile
index c3b6c9c10c58..fb187c90228c 100644
--- a/target/imagebuilder/Makefile
+++ b/target/imagebuilder/Makefile
@@ -26,7 +26,7 @@ all: compile
$(BIN_DIR)/$(IB_NAME).tar.xz: clean
rm -rf $(PKG_BUILD_DIR)
- mkdir -p $(IB_KDIR) $(IB_LDIR) $(PKG_BUILD_DIR)/staging_dir/host/lib \
+ mkdir -p $(IB_KDIR) $(IB_LDIR)/include
$(PKG_BUILD_DIR)/staging_dir/host/lib \
$(PKG_BUILD_DIR)/target/linux $(PKG_BUILD_DIR)/scripts
$(IB_DTSDIR)
-cp $(TOPDIR)/.config $(PKG_BUILD_DIR)/.config
$(SED) 's/^CONFIG_BINARY_FOLDER=.*/# CONFIG_BINARY_FOLDER is not set/'
$(PKG_BUILD_DIR)/.config
@@ -99,6 +99,9 @@ endif
if [ -d $(LINUX_DIR)/arch/$(LINUX_KARCH)/boot/dts ]; then \
$(CP) -L $(LINUX_DIR)/arch/$(LINUX_KARCH)/boot/dts/*
$(IB_DTSDIR); \
fi
+ if [ -d $(LINUX_DIR)/include/dt-bindings ]; then \
+ $(CP) -L $(LINUX_DIR)/include/dt-bindings $(IB_LDIR)/include; \
+ fi
$(SED) 's,^# REVISION:=.*,REVISION:=$(REVISION),g'
$(PKG_BUILD_DIR)/include/version.mk
$(SED) 's,^#
SOURCE_DATE_EPOCH:=.*,SOURCE_DATE_EPOCH:=$(SOURCE_DATE_EPOCH),g'
$(PKG_BUILD_DIR)/include/version.mk
$(SED) '/LINUX_VERMAGIC:=/ { s,unknown,$(LINUX_VERMAGIC),g }'
$(PKG_BUILD_DIR)/include/kernel.mk
--
2.44.0
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
d1 / jh71x0 targets
Hi, I have two RISC-V targets in the pipeline for quite a long time: d1 for Allwinner D1: https://github.com/openwrt/openwrt/pull/12845 jh71x0 for StarFive JH7100/7110: https://github.com/openwrt/openwrt/pull/13372 Both are being kept re-based and tested from time to time. With no further change requests seen so far, I'd plan to merge this over the next few days, unless anyone has concerns. This intention was already highlighted with previous dates on the PRs and on the devel IRC channel as well, but apparently not many people bother to assign/review/approve larger PRs. Regards, Zoltan H ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: OpenWrt One - celebrating 20 years of OpenWrt
This is an excellent idea by Dave Taht to use multiple ath9k chips. Actually, I don't understand: how for a "modern, open, stable" WiFi platform - someone could suggest a blobbed Mediatek or even worse, Broadcom. an OpenWRT official device should be no worse than LibreCMC-supported routers in regards to openness and freedom (LibreCMC is a fork of OpenWRT for routers which could run on 100% opensource without any binary blobs) . If you take some random Mediatek with crappy binary blobs as the base, such a router won't be any better than what you could get at store for a much cheaper price :P A higher price of OpenWRT router would be much more justified by "no binary blobs" as the primary selling point. So the solution is either to put multiple blobless ath9k chips or reverse-engineer & liberate the firmware of some newer WiFi chip (or even create a new WiFi chip by crowdfunding). There are no other sane options in sight > Dave Taht wrote: > I would actually, be happy cutting even more multiplexing latency out of the > ath9k chips Best regards, Ivan On Tue, Feb 27, 2024 at 9:21 AM Bas Mevissen via openwrt-devel wrote: > > 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. > > > -- Forwarded message -- > From: Bas Mevissen > To: Paul D > Cc: John Crispin , "Rafał Miłecki" , > OpenWrt Development List , > complia...@sfconservancy.org > Bcc: > Date: Tue, 27 Feb 2024 10:19:30 +0100 > Subject: Re: OpenWrt One - celebrating 20 years of OpenWrt > On 2024-02-27 10:16, Bas Mevissen wrote: > > (former one escaped too quickly, please ignore) > > > On 2024-02-26 22:38, Paul D wrote: > >> On 2024-02-26 19:39, John Crispin wrote: > >>> Hi Rafał, > >>> > Is there any update / schedule you could share? > >>> I have been meaning to send an update for a few days. Thanks for > >>> reminding me. > > I'm really looking forward to this device. > >>> yeah, me too ;) > >>> > >>> > >>> Lots of stuff has been happening. There was a short break due to the > >>> lunar new year but we are picking up pace again. > >>> > >>> *) schematics are done > > > > Can it be shared already? I'm wondering whether some peripheral port > > can easily be used to configure an external switch chip. I would like > > not to have to use the mbus for that. > > > > >>> *) PCB is mostly routed (https://nbd.name/one-top.jpg > >>> https://nbd.name/one-bottom.png) > >> > >> If there is no price difference, can we have 90 degree angled pins for > >> GND+TX+RX serial header, so the pins face away from the board as USB > >> sockets do, and not stand up perpendicularly. > >> > >> This way serial consoles are workable even when device is in a case. > >> > >> > >> Does anyone else have opinions on this? > >> > > > > I think the console USB connector is intended for that. > > > >>> > >>> *) there was a small hiccup in registering the OUI block that we are > >>> currently resolving > >>> *) the trademark agreement is being worked on - I have a call with > >>> SFC tomorrow to discuss this > >>> > >>> I am expecting that the first 15 PCBA samples will be produced > >>> shortly and be shipped by end of march. > >>> > >>> as for the software side, I modified a mt7981 RFB to have dual > >>> flash, mikrobus, s.T. I could build and test dts files. I > >>> ordered the RTC used on a carrier board and was able to test it. > >>> > >>> all the u-boot patches are pretty much done. there is a pretty > >>> elaborate uboot-env with lots of commands to provide easy > >>> un-brickability. > >>> > >>> I have a local OpenWrt tree with ~10 patches that I hope to send as a > >>> RFC later this week. > >>> > >>> the PCB will probably be light blue (PANTONE 306 C) which is the > >>> light blue used inside the OpenWrt logo. we are still figuring this > >>> out with the supplier. > >> > >> > >> In 20 years when these devices are old and need recycling, how > >> recyclable are the PCBs? What substances go into it? Toxic ones? > > The color pigment is probably not the biggest concern... > > >> > >> > >>> > >>> I should probably start building a page inside the wiki to provide > >>> better visibility into what is happening. > >>> > > Would be great. But this mail was already great to read about the > progress! > > >>> shout out to pepe2k, SFC and MTK for the never ending support that > >>> they provide on this journey. > >>> > >>> And an extra big thank you to Simon, the designer/engineer from BPi > >>> that has been ultra cool in making this become a reality > >>> > >>> John > >>> > Agree! > > > Bas. > > >>> > >> > >> ___ > >> openwrt-devel mailing list > >> openwrt-devel@lists.openwrt.org > >> https://lists.openwrt.org/mailman/listinfo/openwrt-devel > > ___ >
Re: OpenWrt One - celebrating 20 years of OpenWrt
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 2024-02-27 10:16, Bas Mevissen wrote: (former one escaped too quickly, please ignore) On 2024-02-26 22:38, Paul D wrote: On 2024-02-26 19:39, John Crispin wrote: Hi Rafał, Is there any update / schedule you could share? I have been meaning to send an update for a few days. Thanks for reminding me. I'm really looking forward to this device. yeah, me too ;) Lots of stuff has been happening. There was a short break due to the lunar new year but we are picking up pace again. *) schematics are done Can it be shared already? I'm wondering whether some peripheral port can easily be used to configure an external switch chip. I would like not to have to use the mbus for that. *) PCB is mostly routed (https://nbd.name/one-top.jpg https://nbd.name/one-bottom.png) If there is no price difference, can we have 90 degree angled pins for GND+TX+RX serial header, so the pins face away from the board as USB sockets do, and not stand up perpendicularly. This way serial consoles are workable even when device is in a case. Does anyone else have opinions on this? I think the console USB connector is intended for that. *) there was a small hiccup in registering the OUI block that we are currently resolving *) the trademark agreement is being worked on - I have a call with SFC tomorrow to discuss this I am expecting that the first 15 PCBA samples will be produced shortly and be shipped by end of march. as for the software side, I modified a mt7981 RFB to have dual flash, mikrobus, s.T. I could build and test dts files. I ordered the RTC used on a carrier board and was able to test it. all the u-boot patches are pretty much done. there is a pretty elaborate uboot-env with lots of commands to provide easy un-brickability. I have a local OpenWrt tree with ~10 patches that I hope to send as a RFC later this week. the PCB will probably be light blue (PANTONE 306 C) which is the light blue used inside the OpenWrt logo. we are still figuring this out with the supplier. In 20 years when these devices are old and need recycling, how recyclable are the PCBs? What substances go into it? Toxic ones? The color pigment is probably not the biggest concern... I should probably start building a page inside the wiki to provide better visibility into what is happening. Would be great. But this mail was already great to read about the progress! shout out to pepe2k, SFC and MTK for the never ending support that they provide on this journey. And an extra big thank you to Simon, the designer/engineer from BPi that has been ultra cool in making this become a reality John Agree! Bas. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel --- End Message --- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: OpenWrt One - celebrating 20 years of OpenWrt
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 2024-02-26 22:38, Paul D wrote: On 2024-02-26 19:39, John Crispin wrote: Hi Rafał, Is there any update / schedule you could share? I have been meaning to send an update for a few days. Thanks for reminding me. I'm really looking forward to this device. yeah, me too ;) Lots of stuff has been happening. There was a short break due to the lunar new year but we are picking up pace again. *) schematics are done Can it be shared already? I'm wondering whether some peripheral port can easily be used to configure an external switch chip. I w *) PCB is mostly routed (https://nbd.name/one-top.jpg https://nbd.name/one-bottom.png) If there is no price difference, can we have 90 degree angled pins for GND+TX+RX serial header, so the pins face away from the board as USB sockets do, and not stand up perpendicularly. This way serial consoles are workable even when device is in a case. Does anyone else have opinions on this? I think the console USB connector is intended for that. *) there was a small hiccup in registering the OUI block that we are currently resolving *) the trademark agreement is being worked on - I have a call with SFC tomorrow to discuss this I am expecting that the first 15 PCBA samples will be produced shortly and be shipped by end of march. as for the software side, I modified a mt7981 RFB to have dual flash, mikrobus, s.T. I could build and test dts files. I ordered the RTC used on a carrier board and was able to test it. all the u-boot patches are pretty much done. there is a pretty elaborate uboot-env with lots of commands to provide easy un-brickability. I have a local OpenWrt tree with ~10 patches that I hope to send as a RFC later this week. the PCB will probably be light blue (PANTONE 306 C) which is the light blue used inside the OpenWrt logo. we are still figuring this out with the supplier. In 20 years when these devices are old and need recycling, how recyclable are the PCBs? What substances go into it? Toxic ones? I should probably start building a page inside the wiki to provide better visibility into what is happening. shout out to pepe2k, SFC and MTK for the never ending support that they provide on this journey. And an extra big thank you to Simon, the designer/engineer from BPi that has been ultra cool in making this become a reality John ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel --- End Message --- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
