Rpi4 < $(community_build)

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

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'...


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...

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
 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
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_RPIVID_MEM is not set
+# CONFIG_RTC_DRV_CMOS is not set
+# CONFIG_RTC_DRV_IMXDI is not set
+# CONFIG_RTC_DRV_MXC is not set
+# CONFIG_RTC_DRV_MXC_V2 is not set
1 Like

you never know... a magic genie may expedite something like this into 21.02 :wink:

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!


true words of wisdom :genie:

yeah... i'm pretty surprised at just how little opkg is really used...
( to be honest most things aren't... updates / migrations / sqm / a few minor optimizations are the only really 'killer' features that panned out... i.e. what is common to the masses )

thanks for the insight

1 Like


Ok raspberry family, for all of you wishing for stable USB Ethernet dongle interface names, @bobafetthotmail and @anon50098793 have patiently worked me through what is now a working script and config file.

  1. Who wants this?
  2. in order for it to work, a config file needs to be created with the mac id's and interface names. Are you comfortable editing it? This would include figuring out the mac addresses of your dongles.
  3. would working at boot time be sufficient or would you be expecting to hotplug as well

Your views would be most appreciated.

1 Like

Hi Guys!
Im using OpenWRT Community Build on my RPI4 Router since a few Months. What i miss is the Support of my external USB3 NVME Case. I selected a NVME because of Power consumption and i`m very sad, that there is no support for this Harddisk in OpenWRT.
Could you please add some Kernel Drivers for NVME Support in the next Release?
Thx a lot!
Greetings from Austria!

1 Like

re: NVME... I think it would be good to have

may be subject to target module requirements raised here;

so, mainline may be a better place to approach initially for this query...

otherwise, if 3+ people have a need ( I don't own NVME so cannot test this )... happy to generate a test build if you tell me what is required to add support... ( kmod / base eeprom version etc) and it is in fact possible without kconfig method.

see also:

I don't think he means native NVME (that requires PCIe lanes that are used for a USB 3.0 controller in the Raspi 4) but actually a USB enclosure for a NVME drive.
Which should theoretically work fine already if you have kmod-usb-storage package because it's seen as a generic USB 3.0 storage drive.

Seems like some of these adapters don't work properly and need an external power supply (powered USB hub) to work https://github.com/raspberrypi/linux/issues/4130

1 Like

do these things show up with a differnet /dev name?


or something?

No they show up as /dev/sdxx like any other storage on USB. NVMe or Sata or IDE is irrelevant, the system sees the USB-to-something bridge chip, not the drive controller.
See this tutorial where they use one of such adapters. https://dopedesi.com/2020/11/24/upgrade-your-raspberry-pi-4-with-a-nvme-boot-drive-by-alex-ellis-nov-2020/


yup+extras... based on the above i'd agree with that (show up at least... not sure about boot)...
unless some unknown controller...

wait to hear back re: chipset


  • do you know the chipset? (of usb3<>nvme ic)
  • does it show up if you boot from sdcard with it connected?
  • what does raspianOS show with it under 'lsusb'

p.s. greetings from australia :stuck_out_tongue:

Hi wulfy23!

The Chipset of the NVME USB3 Enclosure (Ugreen M.2 SSD Case) is ASM2362.
Now on OpenWRT i tried the Standard Build for RPI 4 and the community build.
opkg says "Package kmod-usb-storage (5.4.113-1) installed in root is up to date."

Output of lsusb is:
Bus 002 Device 002: ID 0b95:1790 ASIX Elec. Corp. AX88179
Bus 002 Device 001: ID 1d6b:0003 Linux 5.4.113 xhci-hcd xHCI Host Controller
Bus 001 Device 002: ID 2109:3431 USB2.0 Hub
Bus 001 Device 001: ID 1d6b:0002 Linux 5.4.113 xhci-hcd xHCI Host Controller

ASIX is my USB to GBit Lan Adapter used for WAN Port.

blkid and fdisk -l do not show my external SSD.


1 Like

you may try;

opkg update

then attempt to install some kmods and see if it shows up in 'dmesg' or 'lsusb -t'

i'm not really sure what it would be off the top of my head... this command helps to look through the kmods (there are lots and it can be hard to find something if you are not sure what you are looking for);

opkg list | grep '^kmod' | grep -i SOMEWORD

maybe something like 'uasp' ... or 'ata' or 'xhci' or 'usb-*' or something... someone else might have suggestions...

could also be something to do with 'quirks' in cmdline.txt or related upstream patches filtering down... (likely)

so doing a websearch for that chipset and 'quirks' may turn something relevant up...

and the power is also a possibility as bobafett suggested... we have not confirmed yet this is working for you in raspbi(ian|OS)

Thx for your Help. Now i tried to install kmod-usb-xhci-hcd, kmod-usb3 and kmod-usb-storage-uas, but nothing helps. Device is still unrecognized.

I can remember, that it worked on Raspberry Pi OS. As it do not work on OpenWrt i use this external SSD on my Odroid XU4 with Raspbian Stretch witch Armbian Linux. There it works perfect.

Any other Ideas?

Thx and Greetings

1 Like