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.
'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 @Noltarimay take a peek at this in his travels... but like I said rtc may invoke some broader complexities )
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.... )
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.
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
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!
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 )
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.
Who wants this?
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.
would working at boot time be sufficient or would you be expecting to hotplug as well
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!
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.
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.
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.
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)
Hi!
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.
