Adding files #3

Merged
PeterSurda merged 7 commits from lee.miller/openwrt:quectel into main 2023-05-23 04:45:04 +00:00
Collaborator

Hi!

If I got it right, those files are device tree overlays, not OverlayFS. You can add them using the FILES variable with the imagebuilder.

As for CONFIG_I2C_BRCMSTB, I cannot find it at all. Based on a short google search adding the kmod-i2c-bcm2835 seems to be a move in the right direction.

Hi! If I got it right, those files are device tree overlays, not [OverlayFS](https://openwrt.org/docs/techref/filesystems#overlayfs). You can add them using the [FILES](https://openwrt.org/docs/guide-user/additional-software/imagebuilder#custom_files) variable with the imagebuilder. As for `CONFIG_I2C_BRCMSTB`, I cannot find it at all. Based on a short google search adding the `kmod-i2c-bcm2835` seems to be a move in the right direction.
lee.miller added 1 commit 2023-01-21 13:56:29 +00:00
Owner

Ok I'll investigate.

Hi!

If I got it right, those files are device tree overlays, not OverlayFS. You can add them using the FILES variable with the imagebuilder.

These files I need to go into the boot partition, which for a RPi is used for special pre-boot files. I'll test if the PR does this (I'll have the hardware available on Thursday).

As for CONFIG_I2C_BRCMSTB, I cannot find it at all. Based on a short google search adding the kmod-i2c-bcm2835 seems to be a move in the right direction.

This is a different module. The kernel config file needs to be changed so that the module builds in the first place. I think it's this file: openwrt-imagebuilder-22.03.2-bcm27xx-bcm2711.Linux-x86_64/target/linux/bcm27xx/bcm2711/config-5.10.

Ok I'll investigate. > Hi! > > If I got it right, those files are device tree overlays, not [OverlayFS](https://openwrt.org/docs/techref/filesystems#overlayfs). You can add them using the [FILES](https://openwrt.org/docs/guide-user/additional-software/imagebuilder#custom_files) variable with the imagebuilder. These files I need to go into the boot partition, which for a RPi is used for special pre-boot files. I'll test if the PR does this (I'll have the hardware available on Thursday). > > As for `CONFIG_I2C_BRCMSTB`, I cannot find it at all. Based on a short google search adding the `kmod-i2c-bcm2835` seems to be a move in the right direction. This is a different module. The kernel config file needs to be changed so that the module builds in the first place. I think it's this file: `openwrt-imagebuilder-22.03.2-bcm27xx-bcm2711.Linux-x86_64/target/linux/bcm27xx/bcm2711/config-5.10`.
Owner

The image has two filesystems: a vfat /boot, and a squashfs /rom. I also think there is an ext4 appended to the squashfs but that's not important for now, I think it's empty when the image is built. I need the overlays (the *.dtbo files) to be in /boot/overlays, and ideally the two *.txt files in /boot. Unfortunately, it looks like the text files aren't deployed at all in either filesystems:

root@OpenWrt:~# mount
/dev/root on /rom type squashfs (ro,relatime)
proc on /proc type proc (rw,nosuid,nodev,noexec,noatime)
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,noatime)
cgroup2 on /sys/fs/cgroup type cgroup2 (rw,nosuid,nodev,noexec,relatime,nsdelegate)
tmpfs on /tmp type tmpfs (rw,nosuid,nodev,noatime)
/dev/loop0 on /overlay type ext4 (rw,noatime)
overlayfs:/overlay on / type overlay (rw,noatime,lowerdir=/,upperdir=/overlay/upper,workdir=/overlay/work)
/dev/mmcblk0p1 on /boot type vfat (rw,noatime,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro)
tmpfs on /dev type tmpfs (rw,nosuid,noexec,noatime,size=512k,mode=755)
devpts on /dev/pts type devpts (rw,nosuid,noexec,noatime,mode=600,ptmxmode=000)
debugfs on /sys/kernel/debug type debugfs (rw,noatime)
none on /sys/fs/bpf type bpf (rw,nosuid,nodev,noexec,noatime,mode=700)
root@OpenWrt:~# find / -iname dualeth.txt
root@OpenWrt:~# find / -iname overlays
/boot/overlays
root@OpenWrt:~# ls /boot/overlays/*.txt
ls: /boot/overlays/*.txt: No such file or directory
root@OpenWrt:~# 
The image has two filesystems: a vfat `/boot`, and a squashfs `/rom`. I also think there is an ext4 appended to the squashfs but that's not important for now, I think it's empty when the image is built. I need the overlays (the `*.dtbo` files) to be in `/boot/overlays`, and ideally the two `*.txt` files in `/boot`. Unfortunately, it looks like the text files aren't deployed at all in either filesystems: ``` root@OpenWrt:~# mount /dev/root on /rom type squashfs (ro,relatime) proc on /proc type proc (rw,nosuid,nodev,noexec,noatime) sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,noatime) cgroup2 on /sys/fs/cgroup type cgroup2 (rw,nosuid,nodev,noexec,relatime,nsdelegate) tmpfs on /tmp type tmpfs (rw,nosuid,nodev,noatime) /dev/loop0 on /overlay type ext4 (rw,noatime) overlayfs:/overlay on / type overlay (rw,noatime,lowerdir=/,upperdir=/overlay/upper,workdir=/overlay/work) /dev/mmcblk0p1 on /boot type vfat (rw,noatime,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro) tmpfs on /dev type tmpfs (rw,nosuid,noexec,noatime,size=512k,mode=755) devpts on /dev/pts type devpts (rw,nosuid,noexec,noatime,mode=600,ptmxmode=000) debugfs on /sys/kernel/debug type debugfs (rw,noatime) none on /sys/fs/bpf type bpf (rw,nosuid,nodev,noexec,noatime,mode=700) root@OpenWrt:~# find / -iname dualeth.txt root@OpenWrt:~# find / -iname overlays /boot/overlays root@OpenWrt:~# ls /boot/overlays/*.txt ls: /boot/overlays/*.txt: No such file or directory root@OpenWrt:~# ```
lee.miller force-pushed quectel from c0e2cd5e9d to de4a4c5d87 2023-01-26 16:54:47 +00:00 Compare
Author
Collaborator

I was editing the build.sh when electricity turned out. Now I found another mistake: overlays dir was not inside of the openwrt-imagebuilder-*.

Used this article as a hint.

I was editing the build.sh when electricity turned out. Now I found another mistake: overlays dir was not inside of the `openwrt-imagebuilder-*`. Used [this article](https://openwrt.org/inbox/toh/arcadyan/astoria/we420223-99?s[]=dtbo) as a hint.
lee.miller force-pushed quectel from de4a4c5d87 to d2680fa98f 2023-02-02 21:15:25 +00:00 Compare
lee.miller added 1 commit 2023-02-02 21:27:54 +00:00
Author
Collaborator

As for CONFIG_I2C_BRCMSTB, I cannot find it at all. Based on a short google search adding the kmod-i2c-bcm2835 seems to be a move in the right direction.

This is a different module. The kernel config file needs to be changed so that the module builds in the first place. I think it's this file: openwrt-imagebuilder-22.03.2-bcm27xx-bcm2711.Linux-x86_64/target/linux/bcm27xx/bcm2711/config-5.10.

Well, just adding the kmod seems to be not enough. I used this doc.

> > > > As for `CONFIG_I2C_BRCMSTB`, I cannot find it at all. Based on a short google search adding the `kmod-i2c-bcm2835` seems to be a move in the right direction. > > This is a different module. The kernel config file needs to be changed so that the module builds in the first place. I think it's this file: `openwrt-imagebuilder-22.03.2-bcm27xx-bcm2711.Linux-x86_64/target/linux/bcm27xx/bcm2711/config-5.10`. Well, just adding the kmod seems to be not enough. I used [this doc](https://openwrt.org/toh/raspberry_pi_foundation/raspberry_pi#using_i2c_and_spi).
lee.miller force-pushed quectel from 879b0b6f0a to 4e38ff4c60 2023-02-09 20:15:31 +00:00 Compare
Owner

I haven't had time to test this thoroughly yet. It kind of seems to work. It's an interesting workaround. However I'm not sure this will work for upgrades. sysupgrade overwrites the /boot partition too, but the uci-defaults will already be deleted from the f2fs overlay.

I haven't had time to test this thoroughly yet. It kind of seems to work. It's an interesting workaround. However I'm not sure this will work for upgrades. `sysupgrade` overwrites the `/boot` partition too, but the `uci-defaults` will already be deleted from the f2fs overlay.
Author
Collaborator

I haven't had time to test this thoroughly yet. It kind of seems to work. It's an interesting workaround. However I'm not sure this will work for upgrades. sysupgrade overwrites the /boot partition too, but the uci-defaults will already be deleted from the f2fs overlay.

Another possible way is adding a new device.

> I haven't had time to test this thoroughly yet. It kind of seems to work. It's an interesting workaround. However I'm not sure this will work for upgrades. `sysupgrade` overwrites the `/boot` partition too, but the `uci-defaults` will already be deleted from the f2fs overlay. Another possible way is [adding a new device](https://openwrt.org/docs/guide-developer/adding_new_device).
Owner

I found this: https://forum.openwrt.org/t/raspberry-pi-change-config-txt-and-cmdline-txt-at-build-time/56762

It looks like the files you're looking for are here:

  • target/linux/bcm27xx/bcm2711/config-5.10 - this is where you can add a line with CONFIG_I2C_BRCMSTB=M or something like that
  • target/linux/bcm27xx/image/Makefile - this is where you can put instructions to copy the additional overlay files
  • target/linux/bcm27xx/image/config.txt (or distroconfig.txt) - just append lines to one of these files.

I haven't checked it in detail but these files are in the current imagebuilder archive so it should work.

I found this: https://forum.openwrt.org/t/raspberry-pi-change-config-txt-and-cmdline-txt-at-build-time/56762 It looks like the files you're looking for are here: - `target/linux/bcm27xx/bcm2711/config-5.10` - this is where you can add a line with `CONFIG_I2C_BRCMSTB=M` or something like that - `target/linux/bcm27xx/image/Makefile` - this is where you can put instructions to copy the additional overlay files - `target/linux/bcm27xx/image/config.txt` (or `distroconfig.txt`) - just append lines to one of these files. I haven't checked it in detail but these files are in the current `imagebuilder` archive so it should work.
lee.miller force-pushed quectel from 4e38ff4c60 to d5ee8cddf7 2023-02-15 04:07:09 +00:00 Compare
lee.miller added 1 commit 2023-02-15 05:25:25 +00:00
lee.miller added 1 commit 2023-02-16 03:28:18 +00:00
Owner

I found this in the build logs:

WARNING: Makefile 'package/kernel/linux/Makefile' has a dependency on 'kmod-phy-bcm-ns-usb2', which does not exist
WARNING: Makefile 'package/kernel/linux/Makefile' has a dependency on 'kmod-phy-bcm-ns-usb3', which does not exist

So maybe we need to build it as a module. Also, the packages mentioned don't exist in the currrent repo ( https://downloads.openwrt.org/releases/22.03.1/targets/bcm27xx/bcm2711/kmods/5.10.146-1-95a6f54a506dab9cc0703d95855cfeaa/ ) so maybe we need to build them too?

I found this in the build logs: ``` WARNING: Makefile 'package/kernel/linux/Makefile' has a dependency on 'kmod-phy-bcm-ns-usb2', which does not exist WARNING: Makefile 'package/kernel/linux/Makefile' has a dependency on 'kmod-phy-bcm-ns-usb3', which does not exist ``` So maybe we need to build it as a module. Also, the packages mentioned don't exist in the currrent repo ( https://downloads.openwrt.org/releases/22.03.1/targets/bcm27xx/bcm2711/kmods/5.10.146-1-95a6f54a506dab9cc0703d95855cfeaa/ ) so maybe we need to build them too?
lee.miller force-pushed quectel from e46c1e8a4a to 75c54d9585 2023-02-18 13:23:24 +00:00 Compare
Author
Collaborator

Hmm, there is a section about rtc in the openwrt raspberry_pi page. I tried to follow that doc once again.

On the other hand there is also a forum thread. It is not clear if it's OP solved the issue.

Hmm, there is a [section about rtc](https://openwrt.org/toh/raspberry_pi_foundation/raspberry_pi#adding_a_real-time_clock_rtc) in the openwrt raspberry_pi page. I tried to follow that doc once again. On the other hand there is also a [forum thread](https://forum.openwrt.org/t/enable-real-time-clock-ds3231-module-on-raspberry-pi-4/68557/18). It is not clear if it's OP solved the issue.
PeterSurda requested changes 2023-02-21 04:53:28 +00:00
PeterSurda left a comment
Owner

the modified config.txt seems to work ok now, but the other components, like copying the overlays, doesn't.

the modified `config.txt` seems to work ok now, but the other components, like copying the overlays, doesn't.
@ -98,0 +103,4 @@
BOOTCONFIG=target/linux/${OPENWRT_TARGET}/image/config.txt
cat << "EOF" >> ${BOOTCONFIG}
Owner

this seems to work now

this seems to work now
@ -101,0 +123,4 @@
cp ${pwd}/overlays/ed-sdhost.dtbo overlays/sensing.txt files/boot/overlays/
cp config.txt ${BOOTCONFIG}
echo "dtoverlay=ed-sdhost" >> ${BOOTCONFIG}
Owner

this also seems to work ok

this also seems to work ok
Author
Collaborator

The cause seems to be in the line 124. There should be ${pwd}/overlays/sensing.txt.

The cause seems to be in the line 124. There should be `${pwd}/overlays/sensing.txt`.
Author
Collaborator

I found this in the build logs:

WARNING: Makefile 'package/kernel/linux/Makefile' has a dependency on 'kmod-phy-bcm-ns-usb2', which does not exist
WARNING: Makefile 'package/kernel/linux/Makefile' has a dependency on 'kmod-phy-bcm-ns-usb3', which does not exist

So maybe we need to build it as a module. Also, the packages mentioned don't exist in the currrent repo ( https://downloads.openwrt.org/releases/22.03.1/targets/bcm27xx/bcm2711/kmods/5.10.146-1-95a6f54a506dab9cc0703d95855cfeaa/ ) so maybe we need to build them too?

I've seen these warnings while building a python package in another branch, so I guess they are not related to i2c kmod.

> I found this in the build logs: > > ``` > WARNING: Makefile 'package/kernel/linux/Makefile' has a dependency on 'kmod-phy-bcm-ns-usb2', which does not exist > WARNING: Makefile 'package/kernel/linux/Makefile' has a dependency on 'kmod-phy-bcm-ns-usb3', which does not exist > ``` > > So maybe we need to build it as a module. Also, the packages mentioned don't exist in the currrent repo ( https://downloads.openwrt.org/releases/22.03.1/targets/bcm27xx/bcm2711/kmods/5.10.146-1-95a6f54a506dab9cc0703d95855cfeaa/ ) so maybe we need to build them too? I've seen these warnings while building a python package in another branch, so I guess they are not related to i2c kmod.
lee.miller added 1 commit 2023-02-22 02:19:56 +00:00
Owner

I think maybe you need to add the list of dtbos here: ${OPENWRT_TARGET}/${OPENWRT_DEVICE}/arch/arm64/boot/dts/overlays/Makefile

Maybe you can work around it somehow like:

make image ... \
    ... \
    'dtbo-$(CONFIG_ARCH_BCM2835)=ed-mcp2515-spi1-can0.dtbo ed-sdhost.dtbo'

The syntax/escaping is almost certainly wrong but I hope I was able to explain the principle. In the worst case you can use sed or something to patch the Makefile.

I think maybe you need to add the list of dtbos here: `${OPENWRT_TARGET}/${OPENWRT_DEVICE}/arch/arm64/boot/dts/overlays/Makefile` Maybe you can work around it somehow like: ``` make image ... \ ... \ 'dtbo-$(CONFIG_ARCH_BCM2835)=ed-mcp2515-spi1-can0.dtbo ed-sdhost.dtbo' ``` The syntax/escaping is almost certainly wrong but I hope I was able to explain the principle. In the worst case you can use `sed` or something to patch the `Makefile`.
Owner

Still no additional files in /boot/overlays. However the driver now seems loaded, except other drivers are missing: i2c_mux, i2c_mux_pinctrl, rtc_pcf85063. Probably needs additional kernel config changes for these to build.

Also the config.txt files are incorrect, they don't correspond to the description in TODO.md, they also look switched (dualeth vs sensing) but not completely.

Still no additional files in `/boot/overlays`. However the driver now seems loaded, except other drivers are missing: `i2c_mux`, `i2c_mux_pinctrl`, `rtc_pcf85063`. Probably needs additional kernel config changes for these to build. Also the `config.txt` files are incorrect, they don't correspond to the description in `TODO.md`, they also look switched (dualeth vs sensing) but not completely.
Owner

On RaspiOS the RTC on the CM4 IO board works out of the box. I also do most of the openwrt tests on this board. The RTC should be identical do the "dualeth" box, it's also the one with higher priority, that's the one I'll deploy in the next couple of days, the "sensing" one can wait.

On RaspiOS the RTC on the CM4 IO board works out of the box. I also do most of the openwrt tests on this board. The RTC should be identical do the "dualeth" box, it's also the one with higher priority, that's the one I'll deploy in the next couple of days, the "sensing" one can wait.
Owner

Maybe you can then download the RaspiOS image, it's vfat + ext4 so you can easily mount it and check the files on its filesystem.

Maybe you can then download the RaspiOS image, it's vfat + ext4 so you can easily mount it and check the files on its filesystem.
lee.miller force-pushed quectel from 3aaf69b20f to 3f106cc1f3 2023-02-24 01:29:44 +00:00 Compare
Author
Collaborator

Still no additional files in /boot/overlays. However the driver now seems loaded, except other drivers are missing: i2c_mux, i2c_mux_pinctrl, rtc_pcf85063. Probably needs additional kernel config changes for these to build.

I couldn't found kmod-rtc-pcf85063a in OpenWrt, searching for a patch.

Also the config.txt files are incorrect, they don't correspond to the description in TODO.md, they also look switched (dualeth vs sensing) but not completely.

I read it again and noticed that both dtbo is for sensing and the bootconfigs need to be included. So I commented the bootconfig patch. Maybe apply it for dualeth?

> Still no additional files in `/boot/overlays`. However the driver now seems loaded, except other drivers are missing: `i2c_mux`, `i2c_mux_pinctrl`, `rtc_pcf85063`. Probably needs additional kernel config changes for these to build. I couldn't found kmod-rtc-pcf85063a in OpenWrt, searching for a patch. > Also the `config.txt` files are incorrect, they don't correspond to the description in `TODO.md`, they also look switched (dualeth vs sensing) but not completely. I read it again and noticed that both dtbo is for sensing and the bootconfigs need to be included. So I commented the bootconfig patch. Maybe apply it for dualeth?
Author
Collaborator

Hmm, a PR with the i2c_mux_pinctrl patch was closed.

Hmm, [a PR](https://github.com/openwrt/openwrt/pull/4949) with the i2c_mux_pinctrl patch was closed.
Author
Collaborator

I think maybe you need to add the list of dtbos here: ${OPENWRT_TARGET}/${OPENWRT_DEVICE}/arch/arm64/boot/dts/overlays/Makefile

Maybe build_dir/target-aarch64_cortex-a72_musl/linux-bcm27xx_bcm2711/linux-5.10.146/arch/arm64/boot/dts/overlays?

> I think maybe you need to add the list of dtbos here: `${OPENWRT_TARGET}/${OPENWRT_DEVICE}/arch/arm64/boot/dts/overlays/Makefile` > Maybe build_dir/target-aarch64_cortex-a72_musl/linux-bcm27xx_bcm2711/linux-5.10.146/arch/arm64/boot/dts/overlays?
Owner

Still no additional files in /boot/overlays. However the driver now seems loaded, except other drivers are missing: i2c_mux, i2c_mux_pinctrl, rtc_pcf85063. Probably needs additional kernel config changes for these to build.

I couldn't found kmod-rtc-pcf85063a in OpenWrt, searching for a patch.

Check RaspiOS build scripts and / or image, as I said it works out of the box there.

Also the config.txt files are incorrect, they don't correspond to the description in TODO.md, they also look switched (dualeth vs sensing) but not completely.

I read it again and noticed that both dtbo is for sensing

Yes I think for "dualeth" no additional dtbo is needed. Since I don't need "sensing" now, maybe you can skip it.

and the bootconfigs need to be included. So I commented the bootconfig patch. Maybe apply it for dualeth?

bootconfigs are different for each of them, but the process you are using is working now, the config.txt in the image is modified, it just doesn't exactly match what I described in the TODO.md file (well maybe it does now, I haven't checked your today's code yet).

> > Still no additional files in `/boot/overlays`. However the driver now seems loaded, except other drivers are missing: `i2c_mux`, `i2c_mux_pinctrl`, `rtc_pcf85063`. Probably needs additional kernel config changes for these to build. > > I couldn't found kmod-rtc-pcf85063a in OpenWrt, searching for a patch. Check RaspiOS build scripts and / or image, as I said it works out of the box there. > > > Also the `config.txt` files are incorrect, they don't correspond to the description in `TODO.md`, they also look switched (dualeth vs sensing) but not completely. > > I read it again and noticed that both dtbo is for sensing Yes I think for "dualeth" no additional dtbo is needed. Since I don't need "sensing" now, maybe you can skip it. > and the bootconfigs need to be included. So I commented the bootconfig patch. Maybe apply it for dualeth? bootconfigs are different for each of them, but the process you are using is working now, the config.txt in the image is modified, it just doesn't exactly match what I described in the `TODO.md` file (well maybe it does now, I haven't checked your today's code yet).
Owner

I still haven't tested but it looks ok to me now, except for the missing drivers and I don't think the dtbo will work. How about I test it and the missing drivers can be fixed in a separate PR? I don't need the dtbo's working now, fixing that isn't a priority.

I still haven't tested but it looks ok to me now, except for the missing drivers and I don't think the dtbo will work. How about I test it and the missing drivers can be fixed in a separate PR? I don't need the dtbo's working now, fixing that isn't a priority.
Owner

I think maybe you need to add the list of dtbos here: ${OPENWRT_TARGET}/${OPENWRT_DEVICE}/arch/arm64/boot/dts/overlays/Makefile

Maybe build_dir/target-aarch64_cortex-a72_musl/linux-bcm27xx_bcm2711/linux-5.10.146/arch/arm64/boot/dts/overlays?

I think the files need to be copied, but also the Makefile needs to be updated to add the new files into the list. But as I said this isn't a priority now, it can be done some other time. The RTC on the "dualeth" is a priority. Well I worked around the issues that happen if the clock time is old (DoH doesn't work as the SSL cert looks like coming from the future, and without DNS NTP won't work, so I disabled DoH, it's not a priority, it's more of a wish list).

One thing that can be done to improve the clock issue even without RTC, the documentation says that during boot it looks for the newest file in /etc and then bumps the time based on that. I tested it and it works. The /etc folder in the squashfs is dated Oct 14th, when 22.03.2 was released. If you can make one of the files dated as the time the build job runs, that would help a bit too.

> > I think maybe you need to add the list of dtbos here: `${OPENWRT_TARGET}/${OPENWRT_DEVICE}/arch/arm64/boot/dts/overlays/Makefile` > > > > Maybe build_dir/target-aarch64_cortex-a72_musl/linux-bcm27xx_bcm2711/linux-5.10.146/arch/arm64/boot/dts/overlays? I think the files need to be copied, but also the `Makefile` needs to be updated to add the new files into the list. But as I said this isn't a priority now, it can be done some other time. The RTC on the "dualeth" is a priority. Well I worked around the issues that happen if the clock time is old (DoH doesn't work as the SSL cert looks like coming from the future, and without DNS NTP won't work, so I disabled DoH, it's not a priority, it's more of a wish list). One thing that can be done to improve the clock issue even without RTC, the documentation says that during boot it looks for the newest file in `/etc` and then bumps the time based on that. I tested it and it works. The `/etc` folder in the squashfs is dated Oct 14th, when 22.03.2 was released. If you can make one of the files dated as the time the build job runs, that would help a bit too.
lee.miller force-pushed quectel from 3f106cc1f3 to 0418fabf93 2023-02-24 04:19:40 +00:00 Compare
Author
Collaborator

Hmm, a PR with the i2c_mux_pinctrl patch was closed.

It doesn't work. I suspect that i2c_mux_pinctrl and rtc_pcf85063 were added in linux-5.15.

> Hmm, [a PR](https://github.com/openwrt/openwrt/pull/4949) with the i2c_mux_pinctrl patch was closed. It doesn't work. I suspect that `i2c_mux_pinctrl` and `rtc_pcf85063` were added in linux-5.15.
lee.miller closed this pull request 2023-02-24 04:24:08 +00:00
lee.miller reopened this pull request 2023-02-24 04:24:35 +00:00
lee.miller force-pushed quectel from 0418fabf93 to 18475fca74 2023-03-03 01:35:58 +00:00 Compare
Owner

Hmm, a PR with the i2c_mux_pinctrl patch was closed.

It doesn't work. I suspect that i2c_mux_pinctrl and rtc_pcf85063 were added in linux-5.15.

well, it looks like it is in the kernel, just not built.

./openwrt-imagebuilder-22.03.2-bcm27xx-bcm2711.Linux-x86_64/target/linux/generic/config-5.10:# CONFIG_RTC_DRV_PCF85063 is not set
./openwrt-imagebuilder-22.03.2-bcm27xx-bcm2711.Linux-x86_64/target/linux/generic/config-5.10:# CONFIG_I2C_MUX_PINCTRL is not set

I have now a bit more time again, I'll look at it in more detail.

> > Hmm, [a PR](https://github.com/openwrt/openwrt/pull/4949) with the i2c_mux_pinctrl patch was closed. > > It doesn't work. I suspect that `i2c_mux_pinctrl` and `rtc_pcf85063` were added in linux-5.15. well, it looks like it is in the kernel, just not built. ``` ./openwrt-imagebuilder-22.03.2-bcm27xx-bcm2711.Linux-x86_64/target/linux/generic/config-5.10:# CONFIG_RTC_DRV_PCF85063 is not set ./openwrt-imagebuilder-22.03.2-bcm27xx-bcm2711.Linux-x86_64/target/linux/generic/config-5.10:# CONFIG_I2C_MUX_PINCTRL is not set ``` I have now a bit more time again, I'll look at it in more detail.
Owner

How about I'll first try to build a kernel that does have the drivers, and then we rebase this on top of that and see if it works that way?

How about I'll first try to build a kernel that does have the drivers, and then we rebase this on top of that and see if it works that way?
Author
Collaborator

Hmm, a PR with the i2c_mux_pinctrl patch was closed.

It doesn't work. I suspect that i2c_mux_pinctrl and rtc_pcf85063 were added in linux-5.15.

well, it looks like it is in the kernel, just not built.

./openwrt-imagebuilder-22.03.2-bcm27xx-bcm2711.Linux-x86_64/target/linux/generic/config-5.10:# CONFIG_RTC_DRV_PCF85063 is not set
./openwrt-imagebuilder-22.03.2-bcm27xx-bcm2711.Linux-x86_64/target/linux/generic/config-5.10:# CONFIG_I2C_MUX_PINCTRL is not set

I have now a bit more time again, I'll look at it in more detail.

As you can see in the PR, to set a particular kmod variable you need to add the definitions in makefile. However I tried adding that patch with no luck. The kernel seems to be built every time, it's indicated by the line package/kernel/linux compile

> > > Hmm, [a PR](https://github.com/openwrt/openwrt/pull/4949) with the i2c_mux_pinctrl patch was closed. > > > > It doesn't work. I suspect that `i2c_mux_pinctrl` and `rtc_pcf85063` were added in linux-5.15. > > well, it looks like it is in the kernel, just not built. > > ``` > ./openwrt-imagebuilder-22.03.2-bcm27xx-bcm2711.Linux-x86_64/target/linux/generic/config-5.10:# CONFIG_RTC_DRV_PCF85063 is not set > ./openwrt-imagebuilder-22.03.2-bcm27xx-bcm2711.Linux-x86_64/target/linux/generic/config-5.10:# CONFIG_I2C_MUX_PINCTRL is not set > ``` > > I have now a bit more time again, I'll look at it in more detail. As you can see in the PR, to set a particular kmod variable you need to add the definitions in makefile. However I tried adding that patch with no luck. The kernel seems to be built every time, it's indicated by the line `package/kernel/linux compile`
lee.miller added 2 commits 2023-03-19 01:50:33 +00:00
lee.miller added 1 commit 2023-03-19 03:15:24 +00:00
Author
Collaborator

Well, I kind of got it. At least kmod-i2c-mux-pinctrl is built and included in build 15888 and kmod-rtc-pcf85063 is on the way.

Maybe I need to change bootconfig for the dualeth.

Well, I kind of got it. At least `kmod-i2c-mux-pinctrl` is built and included in [build 15888](https://buildbot.bitmessage.org/#/builders/33/builds/15888) and `kmod-rtc-pcf85063` is [on the way](https://buildbot.bitmessage.org/#/builders/33/builds/15889). Maybe I need to change bootconfig for the dualeth.
lee.miller requested review from PeterSurda 2023-03-19 03:19:07 +00:00
lee.miller force-pushed quectel from ec0c67a138 to c28be5872c 2023-03-19 13:36:11 +00:00 Compare
Owner

I updated the IO board to the latest artifact built from this branch.

  • the config.txt is still unmodified
  • the rtc_pcf8563 driver is present in /lib/modules and auto-loads on boot
  • the i2c_mux_pinctrl driver I can't locate in /lib/modules and doesn't load

I don't see any errors in the build log. Maybe there is some sort of typo when building the i2c_mux_pinctrl driver?

I updated the IO board to the latest artifact built from this branch. - [ ] the `config.txt` is still unmodified - [x] the `rtc_pcf8563` driver is present in `/lib/modules` and auto-loads on boot - [ ] the `i2c_mux_pinctrl` driver I can't locate in `/lib/modules` and doesn't load I don't see any errors in the build log. Maybe there is some sort of typo when building the `i2c_mux_pinctrl` driver?
Author
Collaborator

I found this:
WARNING: kmod-rtc-pcf85063 is not available in the kernel config - generating empty package

and the same warning for i2c-mux-pinctrl

I found this: `WARNING: kmod-rtc-pcf85063 is not available in the kernel config - generating empty package` and the same warning for `i2c-mux-pinctrl`
Owner

maybe I made a mistake, CONFIG_RTC_DRV_PCF85063 isn't the same as CONFIG_RTC_DRV_PCF8563. I don't know what's the correct procedure in openwrt to compile a kernel module and make a package out of it.

maybe I made a mistake, CONFIG_RTC_DRV_PCF85063 isn't the same as CONFIG_RTC_DRV_PCF8563. I don't know what's the correct procedure in openwrt to compile a kernel module and make a package out of it.
Author
Collaborator

Also changing the target/linux/${OPENWRT_TARGET}/image/config.txt seems not working.

Also changing the `target/linux/${OPENWRT_TARGET}/image/config.txt` seems not working.
Owner

Maybe there is an additional command that needs to be executed to build the kernel / modules?

Maybe there is an additional command that needs to be executed to build the kernel / modules?
Author
Collaborator

maybe I made a mistake, CONFIG_RTC_DRV_PCF85063 isn't the same as CONFIG_RTC_DRV_PCF8563. I don't know what's the correct procedure in openwrt to compile a kernel module and make a package out of it.

There are both of them: dualeth, sensing.

> maybe I made a mistake, CONFIG_RTC_DRV_PCF85063 isn't the same as CONFIG_RTC_DRV_PCF8563. I don't know what's the correct procedure in openwrt to compile a kernel module and make a package out of it. There are both of them: [dualeth](https://git.bitmessage.org/lee.miller/openwrt/src/branch/quectel/overlays/dualeth.txt#L2), [sensing](https://git.bitmessage.org/lee.miller/openwrt/src/branch/quectel/overlays/sensing.txt#L5).
Author
Collaborator

Maybe there is an additional command that needs to be executed to build the kernel / modules?

As far as I understand it's make package/kernel/linux/compile and it's done as a dependency for other packages. Executing it separately changes nothing. There are no .ko files in the build dir as well.

My problem here is that I don't even understand the build process: I see the binary files in the build dir, but there is no sources.

> Maybe there is an additional command that needs to be executed to build the kernel / modules? As far as I understand it's [make package/kernel/linux/compile](https://git.bitmessage.org/Sysdeploy/openwrt/pulls/3#issuecomment-7779621) and it's done as a dependency for other packages. Executing it separately changes nothing. There are no .ko files in the build dir as well. My problem here is that I don't even understand the build process: I see the binary files in the build dir, but there is no sources.
Author
Collaborator

Maybe there is an additional command that needs to be executed to build the kernel / modules?

As far as I understand it's make package/kernel/linux/compile and it's done as a dependency for other packages. Executing it separately changes nothing. There are no .ko files in the build dir as well.

My problem here is that I don't even understand the build process: I see the binary files in the build dir, but there is no sources.

Hmm, in this archive forum thread I found a suggestion that the command above doesn't compile kernel, but just packages it. Unfortunately it's 9 years old, and make target/linux/compile is not actual target anymore.

> > Maybe there is an additional command that needs to be executed to build the kernel / modules? > > As far as I understand it's [make package/kernel/linux/compile](https://git.bitmessage.org/Sysdeploy/openwrt/pulls/3#issuecomment-7779621) and it's done as a dependency for other packages. Executing it separately changes nothing. There are no .ko files in the build dir as well. > > My problem here is that I don't even understand the build process: I see the binary files in the build dir, but there is no sources. Hmm, in [this](https://narkive.com/lcuNw9lq.2) archive forum thread I found a suggestion that the command above doesn't compile kernel, but just packages it. Unfortunately it's 9 years old, and `make target/linux/compile` is not actual target anymore.
Owner

How about make kernel_oldconfig?

How about `make kernel_oldconfig`?
Owner

This post appears to be the opposite problem you're having. The author did build the module but didn't create the package definitions. It's a half a year old post referring to 22.03.

To make it run in a pipeline, probably better to use make kernel_oldconfig and not make kernel_menuconfig the post refers to. I looked at the sources, both ...oldconfig and ...menuconfig are defined in ./openwrt-imagebuilder-22.03.2-bcm27xx-bcm2711.Linux-x86_64/include/toplevel.mk.

[This post](https://forum.openwrt.org/t/openwrt-22-03-build-kernel-modules-compiling-but-missing-in-install-image/145842) appears to be the opposite problem you're having. The author did build the module but didn't create the package definitions. It's a half a year old post referring to 22.03. To make it run in a pipeline, probably better to use `make kernel_oldconfig` and not `make kernel_menuconfig` the post refers to. I looked at the sources, both `...oldconfig` and `...menuconfig` are defined in `./openwrt-imagebuilder-22.03.2-bcm27xx-bcm2711.Linux-x86_64/include/toplevel.mk`.
lee.miller force-pushed quectel from c28be5872c to 0a0851250a 2023-05-11 02:58:41 +00:00 Compare
Author
Collaborator

I end up making packages using button-hotplug as example.

I end up making packages using [button-hotplug](https://git.openwrt.org/?p=openwrt/openwrt.git;a=tree;f=package/kernel/button-hotplug;h=4bfc9a282738f6f6c5e02120b0ce74b74e693140;hb=ea845f76ea2406a4c70d96141d6386b81bba5431) as example.
Author
Collaborator

This post appears to be the opposite problem you're having. The author did build the module but didn't create the package definitions. It's a half a year old post referring to 22.03.

To make it run in a pipeline, probably better to use make kernel_oldconfig and not make kernel_menuconfig the post refers to. I looked at the sources, both ...oldconfig and ...menuconfig are defined in ./openwrt-imagebuilder-22.03.2-bcm27xx-bcm2711.Linux-x86_64/include/toplevel.mk.

I believe all those make kernel_* commands are for a full OpenWrt tree, not SDK. People in various forum posts keep suggesting to use the full tree, don't be fulled by the [SOLVED] label, most of such threads were closed automatically.

> [This post](https://forum.openwrt.org/t/openwrt-22-03-build-kernel-modules-compiling-but-missing-in-install-image/145842) appears to be the opposite problem you're having. The author did build the module but didn't create the package definitions. It's a half a year old post referring to 22.03. > > To make it run in a pipeline, probably better to use `make kernel_oldconfig` and not `make kernel_menuconfig` the post refers to. I looked at the sources, both `...oldconfig` and `...menuconfig` are defined in `./openwrt-imagebuilder-22.03.2-bcm27xx-bcm2711.Linux-x86_64/include/toplevel.mk`. I believe all those `make kernel_*` commands are for a full OpenWrt tree, not SDK. People in various [forum posts](https://forum.openwrt.org/t/solved-how-to-recompile-kernel-module-in-sdk/31673/11) keep suggesting to use the full tree, don't be fulled by the `[SOLVED]` label, most of such threads were closed automatically.
Owner

One of the posters says

The kernel sources are automatically downloaded to the build directory, then the patches in the OpenWrt tree are applied to them. Look in ./target/linux//patches-<kernel.version> for examples.

To me that sounds like downloading sources separately shouldn't be necessary, we probably just need to:

  • find a way to patch the kernel config file
  • build modules with the patched source
  • package the modules into kmod-blabla.opkg

Well we'll see if the current build job shows some progress.

One of the posters says > The kernel sources are automatically downloaded to the build directory, then the patches in the OpenWrt tree are applied to them. Look in ./target/linux/<your target>/patches-<kernel.version> for examples. To me that sounds like downloading sources separately shouldn't be necessary, we probably just need to: - find a way to patch the kernel config file - build modules with the patched source - package the modules into kmod-blabla.opkg Well we'll see if the current build job shows some progress.
Owner

I'm trying to follow this: https://forum.openwrt.org/t/kernel-module-build-but-not-installed-to-image/62892

As I have to build kmod-nvme, this is absent in the RPi packages.

I'm trying to follow this: https://forum.openwrt.org/t/kernel-module-build-but-not-installed-to-image/62892 As I have to build kmod-nvme, this is absent in the RPi packages.
Owner

Hmm, in this archive forum thread I found a suggestion that the command above doesn't compile kernel, but just packages it. Unfortunately it's 9 years old, and make target/linux/compile is not actual target anymore.

After many hours of guessing, it looks like it's make package/kernel/linux/compile. However, I still think I'm missing something else, as the module isn't being built. Maybe I need to run clean first?

> Hmm, in [this](https://narkive.com/lcuNw9lq.2) archive forum thread I found a suggestion that the command above doesn't compile kernel, but just packages it. Unfortunately it's 9 years old, and `make target/linux/compile` is not actual target anymore. After many hours of guessing, it looks like it's `make package/kernel/linux/compile`. However, I still think I'm missing something else, as the module isn't being built. Maybe I need to run `clean` first?
lee.miller added 1 commit 2023-05-17 15:20:12 +00:00
buildbot/multibuild_parent Build done. Details
buildbot/travis_bionic Build done. Details
buildbot/job/openwrt Build done. Details
644618d9c4
Copy additional bootconfig as current.txt
Owner

I have good news. I tried the "dualeth" image on the official CM4 io board, and the "sensing" on the "sensing" board. RTC now works on both. I didn't have to do anything, both worked automatically.

I'm merging now.

I have good news. I tried the "dualeth" image on the official CM4 io board, and the "sensing" on the "sensing" board. RTC now works on both. I didn't have to do anything, both worked automatically. I'm merging now.
PeterSurda approved these changes 2023-05-23 04:44:52 +00:00
PeterSurda merged commit 644618d9c4 into main 2023-05-23 04:45:04 +00:00
Sign in to join this conversation.
No reviewers
No Label
No Milestone
No project
No Assignees
2 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: Sysdeploy/openwrt#3
No description provided.