Re: Matter integration

[Lukas Zeller]

Hi Karsten,

I am very excited to see matter activity in the openwrt space!

For the past year, I was working on a bridge app for my OpenWrt based SmartHome 
daemon p44mbrd [1]. To make it work, I already constributed a few things to 
matter itself, in particular the possibiity to make it use libev [2] for the 
matter mainloop, and fixing the avahi implementation [3].

Back then I also hacked some openwrt platform compilation into matter [4] to 
build the daemon with gn externally, as I failed doing so from within the 
openwrt buildroot. That does not seem to be necessary any more - I am very glad 
to see the devel/gn package, and will try to build p44mbrd this way and then 
create an openwrt package for it.

My work in and around Openwrt focuses on using the platform for IoT and 
SmartHome, and using the matter SDK as a bridge with dynamic endpoints (new PR 
for that see [6]), not as a router/ap. So I probably cannot help much in the 
latter field, but still hope I might be able to contribute from general openwrt 
/ matter experience.

Looking forward to see how this moves forward :-)

Lukas

[1] https://github.com/plan44/p44mbrd
[2] https://github.com/project-chip/connectedhomeip/pull/24232
[3] https://github.com/project-chip/connectedhomeip/pull/26397
[4] 
https://github.com/plan44/connectedhomeip/commit/aabd0ee91bc6dc2906ccf5b73103a538a6dac205
[5] https://github.com/plan44/plan44-feed/tree/main
[6] https://github.com/project-chip/connectedhomeip/pull/28372



> On 27 Jul 2023, at 23:11, Karsten Sperling 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.
> From: Karsten Sperling 
> Subject: Matter integration
> Date: 27 July 2023 at 23:11:10 CEST
> To: openwrt-devel@lists.openwrt.org
> 
> 
> Hello,
> 
> I’m part of an effort by the Connectivity Standards Alliance to bring support 
> for routers and access points into Matter.  Matter is an open-source 
> connectivity standard built to enable developers and device manufacturers to 
> build reliable and secure connected home devices [1][2].
> 
> In this context we’re working on a reference implementation for 
> Matter-enabled routers / access points, which will be taking the form of an 
> OpenWRT feed.  Development on this has recently started at 
> https://github.com/project-chip/matter-openwrt.  We’re using OpenWRT as a 
> platform because of its open nature and great hardware support.  I wanted to 
> reach out to make the OpenWRT developer community aware of this effort, and 
> to invite you to collaborate with us if you’re interested.
> 
> On a more concrete level, I would also like to ask for support for this small 
> PR on OpenWRT I’ve opened here: https://github.com/openwrt/openwrt/pull/13000
> 
> The cross-platform nature of the Matter SDK combined with the fact that it 
> uses git sub-modules for dependency management results in the repo having a 
> LOT of sub-modules (about 70 direct, 130 total), only 4 of which are needed 
> when building within OpenWRT. Getting this PR merged would help us to get the 
> Matter SDK and related software to build cleanly under OpenWRT.
> 
> Thanks!
> 
> [1] https://buildwithmatter.com 
> [2] https://github.com/project-chip/connectedhomeip
> 
> 
> 
> 
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel



signature.asc
Description: Message signed with OpenPGP
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[PATCH] bcm27xx: pad image to avoid false f2fs detection

[Lukas Zeller]

From: Lukas Zeller 

Problem:

- bcm27xx SDCard images for squashfs/f2fs only contain the squashfs part.

- sysupgrade copies the image to the SDCard, with the space in the
  partition between end of the image and end of the partition untouched.

- This is the space where the f2fs overlay lives. Depending on the
  history of the SDcard, this space can contain anything.

- At reboot after sysupgrade, mount_root tries to detect a file system
  in that space.

- Usually, during a sysupgrade enough of that space gets overwritten
  to prevent detection of an existing file system (because normally,
  firmware upgrades mean increased squashfs size).
  This leads (as is correct after sysupgrade) to creation of a new f2fs.

- With a bit of bad luck however remaining parts of previous f2fs can
  lead to false detection by mount_root, but then failure to actually
  mount the overlay, or mounting a overlay with wrong data in it,
  leaving the device in an unusable state. See [1],[2] for detail
  description of how this happened in my case, [3] for another
  problem also caused by false FS detection happening to others.

Solution:

- As suggested by Michel Lespinasse in [4], padding the image with
  zeroes following the squashfs part solves the problem in a simple way.

- Michel's version did pad the image up to the full size of the rootfs
  partition, which does not make a noticeable difference in the gzipped
  form.

- However expansion, which takes place on device for sysupgrade,
  would potentially cause writing extra gigabytes of zeroes to the
  SDCard, depending on partition size, and also cause unneeded flash
  wear.

- Therefore, this patch limits padding to 1Mbytes or the remaining
  space in the rootfs partition, whichever is less.
  The 1M zero padding has been verified sufficient to prevent false
  f2fs detection with several RPi devices.

[1] http://lists.openwrt.org/pipermail/openwrt-devel/2023-May/041062.html
[2] 
https://forum.openwrt.org/t/broken-f2fs-after-sysupgrade-on-rpi-config-not-restored/159703
[3] 
https://forum.openwrt.org/t/rpi-4-sysupgrade-21-02-1-squashfs-overlay-retained/110586?u=wulfy23
[4] https://github.com/openwrt/openwrt/issues/9113#issuecomment-1293060405

Signed-off-by: Lukas Zeller 
---
 .../linux/bcm27xx/image/gen_rpi_sdcard_img.sh | 27 +++
 1 file changed, 27 insertions(+)

diff --git a/target/linux/bcm27xx/image/gen_rpi_sdcard_img.sh 
b/target/linux/bcm27xx/image/gen_rpi_sdcard_img.sh
index 5e8fb2769c..a5185003bf 100755
--- a/target/linux/bcm27xx/image/gen_rpi_sdcard_img.sh
+++ b/target/linux/bcm27xx/image/gen_rpi_sdcard_img.sh
@@ -22,7 +22,34 @@ BOOTSIZE="$(($2 / 512))"
 ROOTFSOFFSET="$(($3 / 512))"
 ROOTFSSIZE="$(($4 / 512))"

+# for sqashfs + f2fs layout, the rootfs image is only the sqashfs part, which
+# is (usually much) smaller than the rootfs partition.
+# The f2fs part (for the overlay) will be created only at first boot
+# into the new image, when mount_root does not detect a valid filesystem 
already
+# present. To make sure random data from previous installations are not falsely
+# detected (which could and did happen in earlier versions), we add 1 MB zero 
padding
+# or up to the end of the rootfs partition, whichever is less.
+# While the padding is required for the squashfs+f2fs layout only, it does not
+# interfere with other rootfs partition types such as ext4.
+
+# the image itself is usually less than the partition size (ROOTFSSIZE)
+ROOTFSBYTES="$(wc -c < $ROOTFS)"
+ROOTFSIMGSIZE="$(( ($ROOTFSBYTES+511) / 512))"
+# we start padding one block BEFORE image ends
+PADOFFSET="$(($ROOTFSOFFSET + $ROOTFSIMGSIZE - 1))"
+PADSIZE="$(($ROOTFSSIZE - ROOTFSIMGSIZE + 1))"
+# limit the padding to 1M, it needs to be just enough to prevent false fs 
detection by mount_root
+if (( $PADSIZE > 2048 )); then
+PADSIZE=2048
+fi
+
+# write the boot partition
 dd bs=512 if="$BOOTFS" of="$OUTPUT" seek="$BOOTOFFSET" conv=notrunc
+# pad out some space after rootfs image, overlapping last block
+if (( $PADSIZE > 0 )); then
+dd bs=512 if=/dev/zero of="$OUTPUT" seek="$PADOFFSET" count="$PADSIZE" 
conv=notrunc
+fi
+# write the rootfs image which does usually not fill the entire partition
 dd bs=512 if="$ROOTFS" of="$OUTPUT" seek="$ROOTFSOFFSET" conv=notrunc


--
2.37.5



signature.asc
Description: Message signed with OpenPGP
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

x86, bcm27xx: is squashfs+f2fs layout (rather than ext4) actively supported?

[Lukas Zeller]

Hello,

sorry for asking again, but I'm really stuck and seeking help/hints
about how to proceed with two issues that break sysupgrade at least
for bcm27xx (RPi) targets which use squashfs+f2fs:

- sysupgrading from a smaller to a larger /boot partition size bricks
  devices because something (f2fs?) keeps holding on the second
  partition, preventing unmounting it, preventing mounting the larger
  /boot (because it overlaps), preventing sysupgrade.tgz to be saved as
  it should. Details in [1].

- sysupgrading can occasionally fail depending on data following the
  squashfs part on disk, because there is no padding that would ensure
  mount_root cannot possibly interpret that data as start of an f2fs.
  Details in [2],[3].

As there was very little response to [1..3], I wonder if using
squashfs+f2fs on bcm27xx (and x86) might be a not really supported
option at all? At least, it seems to be a very rarely used option?

I would like to contribute fixes for these issues, and spent a lot of
time to analyze both of them, and think I pretty much could find the
exact reasons.

However I am stuck with [1] technically (no more ideas how to free the
busy partition), and while I could probably hack something for [2] on
bcm27xx, seeing that the same mechanism is used in x86's and serveral
other target's platform.sh, I'd prefer a more informed path of
actions ;-)

I don't expect others to fix this, but I really need some input from
knowledgeable OpenWrt devs to get any further with this. And if it's
only stating squashfs+f2fs is something one should NOT actually use on
these non-mtd platforms at all.

Thanks in advance
Lukas

[1] 
https://forum.openwrt.org/t/raspberrypi-sysupgrade-looses-overlay-when-boot-partition-gets-bigger/139138/2

[2] http://lists.openwrt.org/pipermail/openwrt-devel/2023-May/041062.html
[3] 
https://forum.openwrt.org/t/broken-f2fs-after-sysupgrade-on-rpi-config-not-restored/159703

--
Lukas Zeller, plan44.ch
l...@plan44.ch - https://plan44.ch





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

Re: bcm27xx: squashf/f2fs sysupgrade broken because overlay is not padded/erased

[Lukas Zeller]

Hi Michael,

> On 17 May 2023, at 20:19, Michael Richardson  wrote:
> 
>> Lukas Zeller  wrote:
>> [...]
>> - trying to just zero out enough blocks after the squashfs data in
>> `target/linux/bcm27xx/base-files/lib/upgrade/platform.sh`
>> [...]

> I'm not really clued in to the subtlies here, but it seems like a TRIM is
> missing that would have told the SDcard that there was just no data after the
> new image.

Yes, that's the objective - making sure what follows the squashfs data can't be 
falsely taken as a f2fs.

> That should result in zeros being returned rather than garbage.

I'm not sure it would actually ensure returning zeroes. AFAIK TRIM is only a 
hint to the SSD controller that it MAY erase the trimmed blocks, but it's the 
controller's decision if and when to do that. In practice, that likely depends 
on the access pattern, SSD controllers will start erasing blocks when there's 
nothing else to do or space is urgently needed. Hard to say if a given SDCard 
would actually erase between writing the image and the next boot. As these 
steps happen in immediate succession, I would rather guess the controller gets 
not enough spare time.

Anyway, the problem is more complicated because the bcm27xx sysupgrade should 
be able to handle multiple partitions possibly following the one that is 
reserved for combined squashfs/f2fs.

What is currently above my head is reliably figuring out which blocks to zero 
out (be it by TRIM or just dd-ing zeroes). Plus, I'm not sure yet that just 
zeroing space is the correct fix at all.

The entire sysupgrade is obviously cleanly architected and implemented - but 
the almost complete lack of comments makes it hard to understand it to the 
point to be able to suggest a change.
I guess I'll need to dig trough all of it until I understand every single line 
before I dare to patch something. Because that's quite a way to go, I am hoping 
somebody with more insight could help a bit ;-)

Lukas




signature.asc
Description: Message signed with OpenPGP
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

bcm27xx: squashf/f2fs sysupgrade broken because overlay is not padded/erased

[Lukas Zeller]

For quite a while, I've been updating my OpenWrt 22.03 based RPi devices, 
configured with sqashfs/f2fs layout (CONFIG_TARGET_ROOTFS_SQUASHFS, rather than 
CONFIG_TARGET_ROOTFS_EXT4FS) via sysupgrade with no problems.

However, during a recent update (22.03.5) where the squashfs area only grew 
very slightly from the previous image (+ one 64k block), all sysupgrades 
failed, leaving the devices in a state where they did start booting, but could 
neither mount nor create the overlay, so stalled in an unusable state.

I found that the SD card area immediately following the squashfs blocks was 
simply random garbage.

Apparently, in all upgrades before, the data was garbage enough for mount_root 
to detect no f2fs and creating a new one, so the issue did not surface.

In this particular case however, with only the first 64k block of the former 
f2fs overlay overwritten by the new squashfs, mount_root did detect an f2fs 
(maybe detecting the second copy of the f2fs superblock as the first?), but 
then failed to mount it:

  Press the [f] key and hit lenter] to enter failsafe mode
  Press the [1], [2], [3] or [4] key and hit [enter] to select the debug level
  [9.5984921] F2FS-fs (loop0) : inconsistent node e block, nid:3, node 
footer[nid:0,ino:0,ofs:0,cpver:0,blkaddr:0]
  [9.6144351] F2FS-fs (loop0): Failed to read root inode
  [9.6302011] mount root: failed to mount -t. f2fs /dev/loop0 /tmp/overlay: 
Invalid argument
  mkdir: can't create directory '/boot' : Read-only file system
  mount: mounting /dev/mmcblk0p1 on /boot failed: No such file or directory

In consequence, the devices then hung in an inaccessible state.

As soon as I took the SD card out, and manually dd-ed a few hundred kB of 
zeroes right following the squashfs data, the devices, otherwise untouched, 
recovered and completed the sysupgrade (i.e. did create a new f2fs, and 
restored /boot/sysupgrade.tgz into it).

AFAIK the main difference between default_do_upgrade() and bcm27xx 
platform_do_upgrade() is that the former uses mtd, which takes care of 
integrating empty (in case of sysupgrade -n) or already populated (in case of 
regular sysupgrade) f2fs data at the end of squashfs, while the latter just 
dd-es the squashfs data with no padding.

The bcm27xx upgrade is different also because it saves the sysupgrade.tgz to 
the platform specific /boot FAT partition, and only restores this AFTER 
rebooting, in 79_move_config (via preinit_mount_root hook).

I really need help to even figure out a feasible idea to fix this, let alone 
implement it in a clean way. What comes to my mind so far is:

- trying to just zero out enough blocks after the squashfs data in 
`target/linux/bcm27xx/base-files/lib/upgrade/platform.sh` platform_do_upgrade() 
to make sure a subsequent mount_root will NOT attempt to mount broken remains 
of an f2fs. However, as this function also still handles ext4-only case and 
even multiple partition images, I'm not understanding this well enough to see 
how to do that properly.

- rearranging things to separate the squashfs/f2fs case from the platform 
specific ext4 case, i.e. using the standard way of creating the empty or 
restored overlay f2fs right after writing the new squashfs, as 
default_do_upgrade() does. Only on bcm27xx, there's no mtd, but mmc. So this 
would require even more in detail knowledge I don't have.

A post about this in the openwrt forum [1] got no echo so far, so I'm trying 
here to reach someone who really understands the peculiarities of the bcm27xx 
sysupgrade (maybe @stijn?) and could help.

Thanks in advance!
Lukas

PS: while digging through this, I found a detail that might be the cause for 
another bcm27xx sysupgrade problem, see [2] - default_do_upgrade() flushes 
kernel inode caches since 3d12b479 (Nov 2020), but bcm27xx 
platform_do_upgrade() does not. Just mentioning it hoping someone with real 
knowledge might see through that issue, too...


[1] 
https://forum.openwrt.org/t/broken-f2fs-after-sysupgrade-on-rpi-config-not-restored/159703
[2] 
https://forum.openwrt.org/t/raspberrypi-sysupgrade-looses-overlay-when-boot-partition-gets-bigger/139138


signature.asc
Description: Message signed with OpenPGP
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: mt7621 GPIO mapping mystery

[Lukas Zeller]

Hi Bas,

> On 21 Jan 2023, at 22:53, Bas Mevissen  wrote:
> 
>> On 2023-01-21 22:42, Lukas Zeller wrote:
>> That really looks like a great solution with all advantages combined!
>> I agree this is better than patching, I just did not realize it was
>> possible at all to modularize dt overlay functionality this way.
> 
> It is a thing very commonly done on RPi "hats" to change the pin config on 
> the extension header.

Yes, RPi has DT overlays, but AFAIK these are merged by the rpi-specific 
bootloader according to what config.txt says, before starting the linux kernel. 
I don't think RPi offers a way to add overlays after boot via configfs by 
default.

Many other platforms don't have a bootloader which allows that pre-boot overlay 
loading. U-boot can do it [1], but it depends on how it is built, and replacing 
u-boot on a given target is more demanding than installing a kernel module.

So the dtbocfg loadable module as recommended by Tomasz enables DT overlays 
even for targets which don't have such functionality in the boot loader, just 
by installing a package, which is nice and a pretty generic solution. It is not 
totally generic because it requires the kernel to be built with 
CONFIG_OF_OVERLAY set, which seems not to be the default in most targets.

> You may find some documentation and examples there that may help you.

Indeed, due to the popularity of overlays in the RPi space, there are a lot of 
examples.

Lukas

[1] : https://u-boot.readthedocs.io/en/latest/usage/fdt_overlays.html


signature.asc
Description: Message signed with OpenPGP
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: mt7621 GPIO mapping mystery

[Lukas Zeller]

Hi Tomasz,

thanks a lot for that hint to dtbocfg and the makefile!

> On 21 Jan 2023, at 17:27, Tomasz Maciej Nowak  wrote:
> 
> [...]
> 
> W dniu 21.01.2023 o 16:33, Lukas Zeller pisze:
>> 
>> So basically, I'm suggesting to revisit the decision to reject the patch 
>> from Daniel Golle [1].
> 
> Instead of doing it the hard way of patching, why not using out-of-tree kernel
> module[2] for loading dtb overlay with configfs? It already exists for some
> time.

That really looks like a great solution with all advantages combined!

I agree this is better than patching, I just did not realize it was possible at 
all to modularize dt overlay functionality this way.

> [...] Unfortunately I didn't test it, as the board I wanted to use it has gone
> in flames. For ready to use recipe see the attachment. Feel free to submit it
> to packages feed and take over maintainership after giving it a test.

I will certainly try that, as soon as I find some time for it, but that's not 
likely to happen before ~March, unfortunately...

> [...]
> 2. https://github.com/ikwzm/dtbocfg

Lukas


signature.asc
Description: Message signed with OpenPGP
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: mt7621 GPIO mapping mystery

[Lukas Zeller]

Hi Sergio, thanks for the reply!

On 21 Jan 2023, at 14:00, Sergio Paracuellos  
wrote:

> On Sat, Jan 21, 2023 at 1:19 PM Lukas Zeller  wrote:
>> [...]So while I understand that using only the DT mechanisms for configuring 
>> GPIO modes, named gpios and libgpiod instead of /sys/class/gpio etc. is the 
>> way to go, I must also state that without loadable DT overlays, this 
>> essentially makes openwrt unsuitable for experimental/educational devices.
> 
> Configure the GPIO modes is not something that is expected to be done
> by a user since all of that belongs to the pinctrl driver space and
> AFAIK linux kernel people are not thinking in doing pinctrl driver
> user-space tools.

Apparently, yes.

I also fully understand this from a system designer's point of view.

What pin is connected to what external hardware, is something that is, in a 
given system, on a given PCB, pretty immutable and thus DT is the correct and 
only place to also define it in a way that is immutable between flashing 
firmwares.

> The libgpiod is useful to detect and set to on and
> off different pins (among other pure GPIO operations) but from the
> already function GPIO set up in them.

This draws a pretty arbitrary boundary for what a educational/experimental use 
consists of. Toggling predefined GPIOs on and off, yes, using the same pin for 
PWM (say, GPIO18 on MT76x8), no? rotary-encoder? W1? GPIO-based SPI, I2C?

> I am not doing the rules,

:-)

> I am just saying the things that are now in the kernel and user space as I
> think they are. As I have already said, I am not an expert in this
> topic at all but maybe if we want to do such complex things like
> configuring the mode of a pin from user space some kind of user space
> drivers need to be provided in some way... So, if openWRT is using
> linux kernel, at the end they have to also live with kernel people's
> decisions in some way...

In some way.

But OpenWrt does patch the kernel to adjust things that Linux mainline does not 
provide.

So it *is* an OpenWrt question whether to support HW tinkering and to what 
degree.

Having that loadable DT overlay patch (which works on 5.10, I'm using it) as a 
menuconfig option disabled by default would have two benefits:

- going with the linux kernel way, to have these HW config things in the DT, 
and only there.

- one single, completely HW independent switch, off by default, to allow HW 
experiments or not (compiling in the dynamically loadable DT overlays code).

Builds for targets that *want* to be open for educational/experimental HW 
tinkering, with the set of risks that comes with that, can set this switch. All 
normal router targets will not set set it, and thus are not affected.

I think this would be better and easier to maintain, than reverting back to 
driver-level hacks like we had in 19.x with *_gpio_custom and friends.

So basically, I'm suggesting to revisit the decision to reject the patch from 
Daniel Golle [1].

Regards,
Lukas

[1] http://lists.openwrt.org/pipermail/openwrt-devel/2021-November/037139.html



signature.asc
Description: Message signed with OpenPGP
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: mt7621 GPIO mapping mystery

[Lukas Zeller]

Hi,

> On 21 Jan 2023, at 08:56, Sergio Paracuellos  
> wrote:
> 
> [...] Yes, you have to claim the pin group as gpio on the device tree to
> make this work.

This revals a underlying problem I tried to ask about back in June 2022 [1] - 
what is the state of userland GPIO support in OpenWrt?

Changing the DT is *not* something an user of an educational/experimental 
device based on OpenWrt is able to do, as long as the DT is baked into the 
firmware image, and not modifiable from user space.

Allowing configfs loadable device tree overlays would make that possible, but 
that path was decided against (so far) [2].

So while I understand that using only the DT mechanisms for configuring GPIO 
modes, named gpios and libgpiod instead of /sys/class/gpio etc. is the way to 
go, I must also state that without loadable DT overlays, this essentially makes 
openwrt unsuitable for experimental/educational devices.

I could also understand if this was an intentional decision, after all OpenWrt 
is a router OS.

But *is* it intentional? I find OpenWrt highly useful as a base OS for small 
networked devices that are not routers, to cover the mostly empty space between 
Arduino and RaspberryPi. Useful Linux in 16M flash rather than 32GB, with no 
flash wear problems by design...

[1] http://lists.openwrt.org/pipermail/openwrt-devel/2022-June/038912.html
[2] http://lists.openwrt.org/pipermail/openwrt-devel/2021-November/037139.html

Lukas


signature.asc
Description: Message signed with OpenPGP
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: gpio fiddling from userspace [Was: Re: gpio-mt7621 offset fix for 5.10 kernel series]

[Lukas Zeller]

Hi,

> On 19 Oct 2022, at 08:55, Petr Štetiar  wrote:
> 
> IMO there should be `ugpiod` daemon available over ubus, probably written in
> ucode using libgpiod bindings. It should provide ubus events for GPIO inputs
> and should be able to control GPIO outputs using ubus calls.

What would that mean for performance, compared to more direct call chains
as when using legacy /sys/class/gpio and current libgpiod? I suspect it would
be much slower via an extra daemon.

But I see a basic underlying question here: how to look at GPIOs in the general
context of OpenWrt?

- From a systems designers perspective, a GPIO is a I/O pin of the SoC or one
  of the peripheral chips in the system which has no specific function
  determined by the silicon, but gets one by the board/device design.
  This is the main perspective in Linux, and DT is the layer to "wire" the
  GPIOs for the specific task to run a certain board or device.

- From the perspective of people who build educational or experimental
  devices, where reconfiguring GPIOs is a essential part of the USER
  experience, changing DT bindings (be it just `gpio-line-names`) is not
  a viable solution. Especially not since the mechanism to do so without
  rebuilding firmware images - dynamically loading DT overlays - is not
  approved of as well [1]. For this perspective, deprecating old GPIO numbering
  and retiring spi-gpio-custom et. al. drivers with no real substitute
  is a serious step backwards, and a reason not to upgrade to newer versions.

I see that the first of the two perspectives is the correct one for the main
usage of OpenWrt, an OS for network boxes and boards, and obviously has
priority.

However, OpenWrt is also a very good base for other uses, maybe summarizable
as "user configurable hardware controllers" (as said, education, but also
controllers for exhibitions and art installations - one of my primary
applications).

After years using and trying to contribute to OpenWrt for this
use case I still don't really understand the sentinents of core OpenWrt
towards this sideline - is it rather seen as a distracting nuisance or
an opportunity? ;-)

Somehow I need to have a clearer view on this meta level to do more than
just patch the missing things for myself. I would like to not only
profit, but also contribute, but can do only so from and for the second
of the two perspectives above, because that's what I understand and work
with.

Any thoughts?

Best Regards
Lukas

[1] http://lists.openwrt.org/pipermail/openwrt-devel/2021-November/037164.html


> Bjørn Mork  [2022-10-19 08:24:44]:
> 
>> Sergio Paracuellos via openwrt-devel 
>> writes:
>> 
>>> This is the reason we have 'gpio-line-names' property so you can set
>>> up names for your pins and use it together with actual user space
>>> tools libgpiod and gpiod. Any other gpio user space library is
>>> considered deprecated in these days.
>> 
>> Interesting.  This property doesn't seem to be used much in OpenWrt if
>> my grep foo is good. It should probably be added at least to every
>> system where we want to access GPIOs from userspace?
> 
> Yes, that is my[1] understanding as well.
> 
> 1. https://github.com/openwrt/openwrt/pull/1366#issuecomment-444177376
> 
> -- ynezz



signature.asc
Description: Message signed with OpenPGP
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: gpio-mt7621 offset fix for 5.10 kernel series

[Lukas Zeller]

Hi Peter and Martin,

> On 18 Oct 2022, at 22:02, Peter Naulls  wrote:
> 
> On 10/18/22 15:55, Martin Blumenstingl wrote:
>> [...] my understanding is that the recommended way for
>> accessing GPIOs from userspace (in case that's what you need) should
>> be done through libgpiod.
> 
> Thanks for pointing me at this. Of course, I don't keep tabs on all the
> kernel development.

I did investigate this in June on this list [1] and in the openwrt forum [2]
and tried to ask some questions about the right way to handle this, but
apparently it did not echo for some reason back then.

> I will say the following though:
> 
> It looks a bit odd - the 416 is arbitrary at best, but I'm sure it comes
> from some calculation.

The MT76xx GPIO has 3 banks with 32 GPIOs each, and the driver initializes
them in the order 0,1,2.

The automatic lecagcy GPIO number assignment works by allocating numbers
down from 512 in chunks of 32. So bank 0 gets 512-32 = 480 as base, bank1
gets 448 and bank2 gets 416.

But GPIOs *within* the chunks are counted upwards, so you'll get a very
unintuitive zigzag mapping when comparing with the pin names in the
datasheet.

> All/most of the other ramips use the ramips GPIO driver instead, which
> does specify the base, although that's in the the DTS; there's no
> facility for that in the mt7621 setup at present.

Just not any more - the mt7621 had this too. I currently patch it back into
22.03's gpio-mt7621.c for my builds and set base in the DTS, see [3]

I can follow the rationale to get rid of legacy GPIOs, but in the context
of experimenting platforms, where GPIOs are a thing to work with in
user space, there's just no real replacement yet (see details in [1],[2]).

So IMHO, at least the "base" of property should stay for a while.

Best Regards
Lukas

[1] http://lists.openwrt.org/pipermail/openwrt-devel/2022-June/038912.html
[2] 
https://forum.openwrt.org/t/state-of-userland-access-to-gpio-based-hardware/130505
[3] 
https://plan44.ch/downloads/v22.03-metapatch-readd-of-base-to-gpio-mt7621.patch




signature.asc
Description: Message signed with OpenPGP
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

State of userland access to GPIO based hardware?

[Lukas Zeller]

Hi all,

I'm trying to bring my OpenWrt-based IoT targets from 19.07 to 22.03. In this 
process I got a bit confused about the state of userland access to GPIOs.

I know that there is some ideology level discussion about userland GPIOs in 
general, and some strong opinions that these are not to be used for anything 
serious. As my target's very purpose is enabling the user to do things with 
GPIOs and software SPI/I2C from the application level, I can live with the 
verdict "not serious", but not without userland GPIOs ;-)

In 19.07 there was:

- /sys/class/gpio for accessing individual GPIOs

- kmod-spi-gpio-custom, kmod-i2c-gpio-custom to create bit-banged SPI/I2C on 
GPIOs

In 23.03:

- /sys/class/gpio still exists, but is deprecated. Switching from explicit to 
automatic `base` in gpio_chip has changed the old-style datasheet aligned GPIO 
numbers to a very non-intuitive 512-gpiochipN*32 scheme (at least in my MT76x8 
targets). The DT property `gpio-base` that was available in gpio-mt7621.c to 
set a custom base has been removed.

- the new recommended access to GPIO from userland is now gpiod, however exists 
in a strange intermediate state where apparently the already deprecated v1 ABI 
needs to be enabled in the kernel (`CONFIG_GPIO_CDEV_V1`), because the 
"official" toolset for using gpiod from userland, libgpiod, has not been 
released yet in v2 that would support the current v2 ABI.

- kmod-spi-gpio-custom and kmod-i2c-gpio-custom have been completely removed in 
"6362a04 - kernel: remove obsolete kernel version switches for 4.14".

This puts targets like mine in a situation with workable access to GPIOs 
(choosing between strange numbered old-style and deprecated V1 API based new 
style), but without any way to establish spi/i2c on GPIOs any more.

A elegant solution for using kmod-spi-gpio and similar (e.g. w1-gpio) drivers 
would have been device tree overlays loadable via configfs. Unfortunately, a 
patchset importing the needed configfs client has been rejected: 
http://lists.openwrt.org/pipermail/openwrt-devel/2021-November/037139.html.

So my bottom line questions would be:
- what is the envisioned future for GPIO userland access in OpenWrt in general?
- in particular, how to use kmod-gpio-i2c/spi/w1 etc. in 22.03 without baking 
the GPIO assignments into a fixed DT?

Best Regards,

Lukas

PS: of course I can (and currently do) patch all this such that it works for 
me, but my general goal is doing things as much as possible along the standard 
OpenWrt lines - which appear a bit blurred here, so that's why I ask.


signature.asc
Description: Message signed with OpenPGP
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [PATCH] packages: pagekitec: fix crashing due to musl time64

[Lukas Zeller]

> On 3 Jun 2022, at 23:10, Karl Palsson  wrote:
> 
> [...] Ideally, even make the patch against upstream:
> https://github.com/pagekite/libpagekite so they are involved and
> can help with it going forward, especially for cases like this,
> where it's not anything that's OpenWrt related.

Thanks for the hint. Yes, this makes more sense, so I just posted a PR
there.

I modified the fix a bit as Rosen Penev is correct to criticise the
use of %lld together with an uint64_t cast. It would replace one mismatch
with another, just less critical one...

However, I chose to keep %lld and cast to long long instead, as we
generally don't know what time_t really is. As long
as there is no PRItime_t, this seems more generic to me than uint64_t.

> I'll try and poke upstream about this personally too.

Thanks!



signature.asc
Description: Message signed with OpenPGP
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: download: regression with USE_SOURCE_DIR and non-tarball packages?

[Lukas Zeller]

Hi,

> On 15 Jun 2021, at 10:05, Petr Štetiar  wrote:
> [...] yes, it would do that in case PKG_MIRROR_HASH is invalid [...]

Thanks, that helped a lot! I ran the exact same tests with libubox and as those 
worked, I realized that the difference between the packages I tried and libubox 
is that the latter has (of course) a PKG_MIRROR_HASH.

The packages I wanted to work with did not have a PKG_MIRROR_HASH at all, 
because under development and not yet released (PKG_SOURCE_VERSION:=master).

> [...] That issue should be visible when building in verbose mode with V=s.

Only if there is a PKG_MIRROR_HASH in the makefile. Otherwise, the repo is just 
re-cloned every time without an indication why (I now found that make 
package/xxx/check would have revealed it)

But finally I found out about PKG_MIRROR_HASH=skip, which seems to be the 
solution for packages under development. It is not documented as such, but as a 
step for updating the hash.

Would it make sense if I try to add a note explaining this under "Working on 
local application source" in the "Creating Packages" wiki page?

Lukas


signature.asc
Description: Message signed with OpenPGP
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

download: regression with USE_SOURCE_DIR and non-tarball packages?

[Lukas Zeller]

Hello Petr,

a while ago (after switching projects from 19.07.3 to 19.07.6) I experienced 
unexpected rebuilds of packages. I asked about this in the forum [1] with no 
echo, so last week I dug deeper and think I found your commit from last 
november "4e19cbc - download: handle possibly invalid local tarballs" [2] 
causing what I see.

I'm a build system newbie, so please apologize if I misunderstand things here. 
But it seems to me that this patch only works for packages that pull their 
upstream source from a tarball via download.pl, because only there a hash check 
prevents redownloads (causing rebuilds) in the last possible moment by exiting 
the script before the download would happen.

For packages with PKG_SOURCE_PROTO=git the new line in package.mk 
`$(DL_DIR)/$(FILE): FORCE` forces re-cloning the upstream repo and thus 
rebuilding the entire package every time. Also, the USE_SOURCE_DIR mechanism 
does not work any more.

Both git based packages and USE_SOURCE_DIR are central to my work (which is 
building automation devices based on OpenWrt, so most work is happening *in* my 
own packages, which are in git or, during hot development phases, via 
USE_SOURCE_DIR even directly linked dirs). I realize this is not a common 
situation for OpenWrt platform developers, but only for developers basing other 
stuff on OpenWrt.

As said, I don't understand the details of the build system enough to actually 
propose a proper patch right into the heart of it. But below is my current 
workaround to re-enable USE_SOURCE_DIR and git-based packages, hopefully not 
affecting anything else I can't see. So far, works for me, but definitely needs 
a thorough look by someone who actually understands the whole thing...

Lukas


[1] 
https://forum.openwrt.org/t/does-19-07-6-trigger-package-downloads-rebuilds-more-frequently-than-19-07-3/92471
[2] http://lists.openwrt.org/pipermail/openwrt-devel/2020-November/032235.html


--- a/include/package.mk
+++ b/include/package.mk
@@ -177,6 +177,12 @@ define Build/Exports/Default
 endef
 Build/Exports=$(Build/Exports/Default)

+ifneq ($(wildcard $(PKG_BUILD_DIR)/.source_dir),)
+  FORCE_DL:=
+else
+  FORCE_DL=$(if $(findstring git,$(PKG_SOURCE_PROTO)),,$(DL_DIR)/$(FILE): 
FORCE)
+endif
+
 define Build/CoreTargets
   STAMP_PREPARED:=$$(STAMP_PREPARED)
   STAMP_CONFIGURED:=$$(STAMP_CONFIGURED)
@@ -185,7 +191,7 @@ define Build/CoreTargets
   $(call Build/Autoclean)
   $(call DefaultTargets)

-  $(DL_DIR)/$(FILE): FORCE
+  $(FORCE_DL)

   download:
$(foreach hook,$(Hooks/Download),



signature.asc
Description: Message signed with OpenPGP
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] mt76x8: Onion Omega2+ reboot problem [Was: mt76x8: Strange GPIO numbering on Onion Omega2+]

[Lukas Zeller]

Hi Martin,

> On 12 Jun 2021, at 22:02, Martin Blumenstingl 
>  wrote:
> There is a "broken-flash-reset" property which probably is missing in
> the Omega2+ .dts(i) files

Thanks a lot for the hint!

> If you have already considered this and my comment does not apply then
> please ignore it (I am not familiar with any of the Ralink/Mediatek
> SoCs, I just recognized this problem description)

I was not aware and it does apply to the MT7688 the way it is wired in the 
Omega2+ and indeed, it is not in the Omega2+ DTS for 21.02 yet. I'll suggest to 
Onion to add it.

But I was curious to learn what the feature does, and had a look at spi-nor.c 
(spi_nor/core.c). If I haven't misread the code, it restores the addressing 
mode to 3 byte at shutdown. This means an orderly reboot will work, but a 
unexpected SoC reset w/o power cycle will still hang. So if the use case is 
something that *must* reboot after any kind of reset (e.g. HW watchdog) this 
flag cannot fix the (HW) problem.

Best Regards
Lukas

> [0] 
> https://elixir.bootlin.com/linux/v5.4.48/source/Documentation/devicetree/bindings/mtd/jedec,spi-nor.txt#L72



signature.asc
Description: Message signed with OpenPGP
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: Re: [OpenWrt-Devel] mt76x8: Strange GPIO numbering on Onion Omega2+

[Lukas Zeller]

Hi Gerd,

> There is still one major issue migrating to 21.02 on my side: Reboot doesn't 
> work. I need to switch power off/on on my Omega2+. AFAIU it has somethoing to 
> do with the SPI 3byte/4byte mode. Older versions worked, but 4byte mode seems 
> to boot faster. BTW: spi-nor spi0.0: mx25l25635e (32768 Kbytes)

This is a hardware problem of the Omega2+ (so further details -> probably off 
topic for here). But in short: The SPI flash chip must be in 3-byte mode for 
the MT7688 to start the way CHIP_MODE pins are wired in the Omega2. A power 
cycle resets the flash to 3 byte mode, however just a SoC reset does not, and 
if the SPI chip is in 4 byte mode when the reset occurs, the MT7688 will try to 
boot in 3 byte mode from a chip that is in 4 byte mode. This is only a problem 
for the 32M flash, as it needs 4-byte addresses. The Omega2 (non +) with 16M 
flash is thus not affected, it stays in 3 byte mode all the time. See [1] for a 
hardware solution Onion suggests for the Omega2S+ (the SMT version), which has 
the flash VDD exposed separately, so this does not work for the THT Omega2+ :-(

Best Regards
Lukas

[1] 
https://github.com/OnionIoT/Omega2/blob/master/Documents/Omega2S%20Hardware%20Design%20Guide.pdf


signature.asc
Description: Message signed with OpenPGP
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel