sounds reasonable... mind sharing the runtime code/config for that?
I haven't got it working on OpenWRT (since neither snapshot nor your community builds include support yet 
), but with Raspbian, I was able to follow this process successfully:
1 Like
no worries... there are no kernel incompatibilities on this build... 
opkg install <package>
let us know if you nail down some specifics on the config (hint: it's less than three lines)
edit: seems that kmod is not available / bundled for this target... there are upm/high level packages only... so maybe more than three lines until support is added...
you can test/get(builtin support) in a buildroot by adding;
# CONFIG_RTC_CLASS is not set > CONFIG_RTC_CLASS=y
CONFIG_RTC_DRV_DS1307=y
CONFIG_RTC_I2C_AND_SPI=y
to target/linux/bcm27xx/bcm2711/config-5.4
to prevent kernel incompatibilites this build is created with the imagebuilder... which means i'm unable to perform the actions above
or use higher level utilities over i2c which is included by default...
as a final option for anyone good at C ... I have some basic support for microcontroller over usb-serial for vfd / rtc / relay / whatever... I suck at C tho' (actually that's an overstatement) so stopped development(at vfd)... for rtc... it's a bit of a pain because you have to provide the date string conversion and hwclock abstraction...
I'm new to building OpenWRT (but not at all new to configuring/building the Linux kernel) -- can you point me to something that explains this limitation?
(edited to reply since my Discourse account is too new to reply >3x)
Ah, ok, you're just passing through the snapshot kernel, not building a new one, so can't just add kmods.
good question...
put simply... kernel modules 'kmods' are tied to the kernel from the same compile run...
https://forum.openwrt.org/search?q=opkg%20kernel%20incompatible
- you compile your own OpenWrt you can't install official kmod packages
- you use snapshot ( which is rebuilt daily-ish ) you cannot install kmods tommorrow ( without installing the matching tommorrow kernel )
bingo
future of the build
guys... I don't want to be alarmist... but with 21.02 stable coming up... following a discussion... I wanted to get the ball rolling with a discussion about the future of the build...
some points...
get a wider community support (i.e. more people will be willing to contribute) if the build process is transparent and automated
reaching the point where the code is getting stale / needs rewriting in several places... and unsure of just how long or to what extent I can keep pushing on... likely outcome (without qualified help) is 2-3 months max and the build will need to be retired...
files structure has been coded to be portable across devices... ( you will see an experimental "ventoy_x64" community build in the devel folder )... [snip whinge about expecting help] if any decent coders jump onboard the "files" project we can likely switch to master ( buildroot ) and open the whole process up
The build has approx 25-30 (regular) users which has doubled over the last 5-6months... ( it's not my goal to make it famous... just worth it to see all the sweat for a reason )...
I would ask for general input... but surveys seem to work alot better... so let's see if I can whip something up...
- I like the build how it is... master based... opkg works...
- Switching to 21.02(ib) seems sensible... with or without github automated builds (leave comment)
- Switching to master buildroot and no opkg or limited repo/installable ipks is the way forward via github actions (leave comment)
- Open up the files and concentrate on portability across many devices via github actions (with either ib or buildroot > leave comment)
0
voters
note: "via github actions" could potentially be any automated framework... i.e. a single downloadable script + files... etc. etc.
2 Likes
I'm not sure which voting option expresses me, so I'll better write here.
The point of the community build, for me at least, was to have something stable and optimized. I am not using the wifi, but it was nice to have most of the applications already installed in the image. If it is a burden for you to maintain the build and the packages in your repository, I truly understand and the stable release will work fine for me, hopefully the openssl optimization too.
Elseif on the other hand you want to keep doing it for you primarily and share with the community, I'd be happy to continue using it and promise not to bust your balls too often 
3 Likes
I'm a newbie, and I do not intend to develop OpenWRT skills. I did not adopt this build initially, but have done it as soon as I thought it was stable. Compared with official builds it has three major advantages for me:
- It comes with preinstalled packages and with a very nice Luci UI
- It includes drivers for usb2ethernet adapters (great idea, I have internet access from the beggining without the need to rewire Pi and switch during upgrade)
- The SD card does not need repartitioning
Upgrading with wulfy23's build takes 5 minutes, with the official build it's almost 1h. I will glady pay a beer to thank all the effort.
Of course I understand if @anon50098793 does not continue the effort on this build.
2 Likes
gee guys... big head now... poll closed... made things very clear... i'm clear on the best direction to head in.... (combination of options that have selections)...
i think the biggest issues has been finding it difficult to switch off... and needing to stay on top of changes picking the 'better times' to create images... the system is setup... its mostly self managing at the moment...
i'll see about maybe committing to some sort of schedule ( once a month or something ) although i'm hopeless with 'order'... that should make some decent room(excuse) and reclaim alot more time and energy...
1 Like
You Da Man!
1 Like
Hey @anon50098793,
I'm the guy who posted this issue on your repo the other day. I didn't see the poll you posted yesterday, but my 2 cents are as follows:
- If you open up the files and concentrate on portability you can ensure that the project continues in the long run. You can also maintain different builds (e.g. continue support on the current version and also work on 21.02 if you like).
- I would encourage you to enable Sponsorships on your GitHub repo, so that all of us could 'buy you a beer' to help out
I'm sure that plenty of people, including myself would be happy to help out with development when we can . By documenting your roadmap for this project (via GitHub Project Boards) and maintaining your scripts on GitHub you will also enable future contributors to fork your repo and contribute via pull requests which you can review and approve if it fits.
Just a small suggestion - I have a feeling that more than ~25 people use your build of RPi 
it would be interesting if you could publish the build somewhere where you can pull metrics off downloads (maybe GitHub Releases or SourceForge).
4 Likes
OK, I've poked at the image builder and now I understand that it just builds an image from packages that already exist in the repo. Working back to what I'm trying to do -- I want to support an RTC and a UPS. For those, I need kmod-rtc-ds1307 and nut-(server|common|upsc|upscmd|upsrw|upsmon|usbhidups). I see that those packages exist for other targets, but not for rpi-4.
Theoretically I can build OpenWRT completely from scratch to create them myself, but the real question is, how/where do I request that the OpenWRT project build those packages for rpi-4 by default? I just don't get where the default package list for rpi-4 lives in the repository, so I could submit a PR against it.
1 Like
verbage1
afiak there is no (package generation) issue with nut on this target...
[root@dca632 /usbstick 42°]# opkg list | grep '^nut' | awk '{print $1}' | tr -s '\n' ' '
nut nut-avahi-service nut-common nut-driver-al175 nut-driver-apcsmart nut-driver-apcsmart-old nut-driver-apcupsd-ups nut-driver-bcmxcp nut-driver-bcmxcp_usb nut-driver-belkin nut-driver-belkinunv nut-driver-bestfcom nut-driver-bestfortress nut-driver-bestuferrups nut-driver-bestups nut-driver-blazer_ser nut-driver-blazer_usb nut-driver-clone nut-driver-dummy-ups nut-driver-etapro nut-driver-everups nut-driver-gamatronic nut-driver-genericups nut-driver-isbmex nut-driver-ivtscd nut-driver-liebert nut-driver-liebert-esp2 nut-driver-masterguard nut-driver-metasys nut-driver-mge-shut nut-driver-mge-utalk nut-driver-microdowell nut-driver-nutdrv_atcl_usb nut-driver-nutdrv_qx nut-driver-oldmge-shut nut-driver-oneac nut-driver-optiups nut-driver-powercom nut-driver-powerpanel nut-driver-rhino nut-driver-richcomm_usb nut-driver-riello_ser nut-driver-riello_usb nut-driver-safenet nut-driver-solis nut-driver-tripplite nut-driver-tripplite_usb nut-driver-tripplitesu nut-driver-upscode2 nut-driver-usbhid-ups nut-driver-victronups nut-server nut-upsc nut-upscmd nut-upslog nut-upsmon nut-upsmon-sendmail-notify nut-upsrw nut-upssched nut-web-cgi
just a small terminology 'nitpick'...
- 'default packages' will typically refer to 'default installed into the rom image' package...
in this case... a closer phrase would be 'generate kmod-rtc-xyz... for this target'...
verbage2
it's not a bug... so asking on the mailing-list or a separate thread is probably your next best course of action... in the case of rtc... there may be some buildroot selection / target implications i'm not so familiar with... so best I not guesstimate...
(and it's not specifically a build related discussion from that point on... once the module exists... then we can re-assess)
( edit: if we are lucky @Noltari may take a peek at this in his travels... but like I said rtc may invoke some broader complexities )
1 Like
@cesarvog you also may wish to checkout @damianperera s cool github repo / actions...
very interesting way to handle the question you had about a second device network config...
( not for everyone i'm sure... but innovative and handy for those interested in that sort of thing )
download metrics can be deceptive (multiple single person... longer availability, people stockpiling (i would))... hence 'regular users'... but point taken ( and a very good one... )
one side effect of the update check is it shows in the github traffic page of unique visitors ( this was never my intention when implementing it... but is usefull none-the-less... no identifyable info is visible to me )... obviously this wont show those who disable the updatecheck... or maybe run it without a gateway or whatnot...
blue line = uniq visits
(edit: you know what... I think your right... I keep forgetting that this is not a cron task... but luci/login initiated... so if nobody logs into the router... then no visit would happen.... )
1 Like
So weird, I've been trying for two days to build it because I could swear it wasn't there, but obviously you're right. At least I learned a lot about building packages and images.
1 Like
speculative patch that may enable the kmod rtc generation... features bit might be un-needed as it's not onboard...
patch
diff --git a/target/linux/bcm27xx/Makefile b/target/linux/bcm27xx/Makefile
index d8a6aedf18..5221d56353 100644
--- a/target/linux/bcm27xx/Makefile
+++ b/target/linux/bcm27xx/Makefile
@@ -8,7 +8,7 @@ include $(TOPDIR)/rules.mk
ARCH:=arm
BOARD:=bcm27xx
BOARDNAME:=Broadcom BCM27xx
-FEATURES:=ext4 audio usb usbgadget display gpio fpu squashfs rootfs-part boot-part
+FEATURES:=ext4 audio usb usbgadget display gpio rtc fpu squashfs rootfs-part boot-part
SUBTARGETS:=bcm2708 bcm2709 bcm2710 bcm2711
KERNEL_PATCHVER=5.4
diff --git a/target/linux/bcm27xx/bcm2711/config-5.4 b/target/linux/bcm27xx/bcm2711/config-5.4
index c82ae44942..461d550109 100644
--- a/target/linux/bcm27xx/bcm2711/config-5.4
+++ b/target/linux/bcm27xx/bcm2711/config-5.4
@@ -390,6 +390,14 @@ CONFIG_RFS_ACCEL=y
CONFIG_RODATA_FULL_DEFAULT_ENABLED=y
# CONFIG_RPIVID_MEM is not set
CONFIG_RPS=y
+CONFIG_RTC_CLASS=y
+# CONFIG_RTC_DRV_CMOS is not set
+CONFIG_RTC_DRV_DS1307=y
+CONFIG_RTC_DRV_DS1672=y
+# CONFIG_RTC_DRV_IMXDI is not set
+# CONFIG_RTC_DRV_MXC is not set
+# CONFIG_RTC_DRV_MXC_V2 is not set
+CONFIG_RTC_I2C_AND_SPI=y
CONFIG_RWSEM_SPIN_ON_OWNER=y
CONFIG_SCSI=y
# CONFIG_SCSI_LOWLEVEL is not set
1 Like
Wow. It would be awesome.
Things have been hectic lately (well, honestly, always) & I missed the poll because I haven't been keeping up here. I see that voting is closed but I owe you my input because of the amazing work you've done.
I initially switched to the community build because it was a royal pain in the butt to get OpenWrt working on my rpi 4. Even when I did get it working there was a whole other layer of pain getting the right packages for my needs. Don't even get me started on upgrades... All of those pains disappear with the community build.
To the poll:
- I like the way things are working but it's not up to me. It is up to you and your team (team of one counts!). master- based is easy & sane with a small, disciplined team. For instance, in my day job we only recently switched to a more formal method on a ~2yr project because it is finally stable enough to justify the "overhead" of a more robust strategy. Do what works now & change later if necessary.
- Open up the files? Absolutely! Portability across many devices? Meh. You did this to scratch the rpi4 itch. Right? It kicks ass, don't sacrifice that. But, yea if you open it up & others want to contribute and be responsible for supporting those... why not? Don't fall into the "everything for everyone" trap. I've seen a lot of custom Android ROMs die over the years because of that.
- Switching to a stable upstream is smart. I (mostly) don't care, what's here works. Many of us probably feel that way. But a stable upstream should mean fewer tweaks/fixes/whatever so, yea, leverage all of that good work & use your time/skills/passion to add value that nobody else can.
- I dunno about buildroot. I suspect that if you're not doing it now it may be non-trivial to migrate but I have no direct experience to back that up. On the one hand it would probably be good to move to a standard/common solution. On the other, is that where you really want to spend your time? Maybe someone in the community would enjoy the challenge (it sounds dreadful to me). opkg, much like upstream, is an "implementation detail" that I don't (and others might not) care too much about. It's that "just works" magic that makes the community build, well, magic.
I don't know how long you've been in the game so here's some old-man advice you may or may not have accumulated on your own: Take a break every now and then. Rest and recharge. You've given us a helluva thing here and nobody wants to see you burn out!
3 Likes