Adding files #3
No reviewers
PeterSurda
Labels
No Label
bug
duplicate
enhancement
help wanted
invalid
question
wontfix
No Milestone
No project
No Assignees
2 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: Sysdeploy/openwrt#3
Loading…
Reference in New Issue
Block a user
No description provided.
Delete Branch "lee.miller/openwrt:quectel"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
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 thekmod-i2c-bcm2835seems to be a move in the right direction.Ok I'll investigate.
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).
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.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*.dtbofiles) to be in/boot/overlays, and ideally the two*.txtfiles in/boot. Unfortunately, it looks like the text files aren't deployed at all in either filesystems:c0e2cd5e9dtode4a4c5d87I 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.
de4a4c5d87tod2680fa98fWell, just adding the kmod seems to be not enough. I used this doc.
879b0b6f0ato4e38ff4c60I 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.
sysupgradeoverwrites the/bootpartition too, but theuci-defaultswill already be deleted from the f2fs overlay.Another possible way is adding a new device.
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 withCONFIG_I2C_BRCMSTB=Mor something like thattarget/linux/bcm27xx/image/Makefile- this is where you can put instructions to copy the additional overlay filestarget/linux/bcm27xx/image/config.txt(ordistroconfig.txt) - just append lines to one of these files.I haven't checked it in detail but these files are in the current
imagebuilderarchive so it should work.4e38ff4c60tod5ee8cddf7I found this in the build logs:
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?
e46c1e8a4ato75c54d9585Hmm, 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.
the modified
config.txtseems 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.txtcat << "EOF" >> ${BOOTCONFIG}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}this also seems to work ok
The cause seems to be in the line 124. There should be
${pwd}/overlays/sensing.txt.I've seen these warnings while building a python package in another branch, so I guess they are not related to i2c kmod.
I think maybe you need to add the list of dtbos here:
${OPENWRT_TARGET}/${OPENWRT_DEVICE}/arch/arm64/boot/dts/overlays/MakefileMaybe you can work around it somehow like:
The syntax/escaping is almost certainly wrong but I hope I was able to explain the principle. In the worst case you can use
sedor something to patch theMakefile.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.txtfiles are incorrect, they don't correspond to the description inTODO.md, they also look switched (dualeth vs sensing) but not completely.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.
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.
3aaf69b20fto3f106cc1f3I couldn't found kmod-rtc-pcf85063a in OpenWrt, searching for a patch.
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?
Hmm, a PR with the i2c_mux_pinctrl patch was closed.
Maybe build_dir/target-aarch64_cortex-a72_musl/linux-bcm27xx_bcm2711/linux-5.10.146/arch/arm64/boot/dts/overlays?
Check RaspiOS build scripts and / or image, as I said it works out of the box there.
Yes I think for "dualeth" no additional dtbo is needed. Since I don't need "sensing" now, maybe you can skip it.
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.mdfile (well maybe it does now, I haven't checked your today's code yet).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 think the files need to be copied, but also the
Makefileneeds 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
/etcand then bumps the time based on that. I tested it and it works. The/etcfolder 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.3f106cc1f3to0418fabf93It doesn't work. I suspect that
i2c_mux_pinctrlandrtc_pcf85063were added in linux-5.15.0418fabf93to18475fca74well, it looks like it is in the kernel, just not built.
I have now a bit more time again, I'll look at it in more detail.
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?
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 compileWell, I kind of got it. At least
kmod-i2c-mux-pinctrlis built and included in build 15888 andkmod-rtc-pcf85063is on the way.Maybe I need to change bootconfig for the dualeth.
ec0c67a138toc28be5872cI updated the IO board to the latest artifact built from this branch.
config.txtis still unmodifiedrtc_pcf8563driver is present in/lib/modulesand auto-loads on booti2c_mux_pinctrldriver I can't locate in/lib/modulesand doesn't loadI don't see any errors in the build log. Maybe there is some sort of typo when building the
i2c_mux_pinctrldriver?I found this:
WARNING: kmod-rtc-pcf85063 is not available in the kernel config - generating empty packageand the same warning for
i2c-mux-pinctrlmaybe 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.
Also changing the
target/linux/${OPENWRT_TARGET}/image/config.txtseems not working.Maybe there is an additional command that needs to be executed to build the kernel / modules?
There are both of them: dualeth, sensing.
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/compileis not actual target anymore.How about
make kernel_oldconfig?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_oldconfigand notmake kernel_menuconfigthe post refers to. I looked at the sources, both...oldconfigand...menuconfigare defined in./openwrt-imagebuilder-22.03.2-bcm27xx-bcm2711.Linux-x86_64/include/toplevel.mk.c28be5872cto0a0851250aI end up making packages using button-hotplug as example.
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.One of the posters says
To me that sounds like downloading sources separately shouldn't be necessary, we probably just need to:
Well we'll see if the current build job shows some progress.
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.
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 runcleanfirst?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.