Target bananapi_bpi-r4-common

[Philip Prindeville]

> On Jul 4, 2025, at 12:54 PM, Daniel Golle <daniel at makrotopia.org> wrote:
> 
> On Fri, Jul 04, 2025 at 11:47:26AM -0600, Philip Prindeville wrote:
>> 
>> Yeah, I’ve been thinking about us developing an Amazon EC2 image for the market place for people who have CGNAT, for instance, but might want to lease a VM with a fixed IP address, host DNS there, and then do port-forwarding over VPN...  and we could have the royalties go to the project.
> 
> Yes, I agree we need to do that and facilitate easy deployment of
> OpenWrt images on the various clouds. It's not my area of expertise, but
> I know that Paul Spooren has previously been working on that.


I’ll ask the #homelab group at Amazon if they have interest in contributing to this.  We might even be able to get a few free VMs to help with development.


>> 
>> 
>>> 
>>>> This is, after all, a 2-way street.  If vendors see richly provisioned platforms as being the norm, perhaps they’ll react by increasing the amount of DRAM and Flash that comes on their base models.
>>> 
>>> I think vendors mostly see the SDK provided to them by the chip vendors,
>>> and with the bill of materials in mind they envision a set of features
>>> they want to support. By "support" I mean also in terms of providing
>>> actual support to users, which may cost more than giving a board a
>>> little bit of extra storage or RAM. I highly doubt that OpenWrt's
>>> selection of default packages for any specific board will influence
>>> hardware vendors to provide more flash or RAM -- either we are talking
>>> about consumer electronics stuff in a plastic case which mostly just has
>>> to be cheap and comes with a fixed set of features, or we are talking
>>> about "consumer devboards" like the BananaPi boards which are already
>>> equipped with (for OpenWrt terms) huge amounts of storage and RAM, often
>>> maxing out the amount of RAM the underlying SoC is able to deal with,
>>> and providing easy ways to extend the storage using an SSD.
>> 
>> 
>> Except of course, when there’s a M.2 slot that supports NVMe but we don’t support it.  Or there’s a way of installing persistent storage, but we don’t easily support that either.
> 
> You can easily install `kmod-nvme` or `kmod-ata-ahci`, depending on the
> type of storage you are adding. Being able to install additional
> packages just like on any other Linux distrubition, or even creating
> custom images including any combination of packages you like is exactly
> the strength of OpenWrt. Again, no need to change anything for that,
> it's already supported.


Kernel modules are a special breed.  They’re typically not very big.  And storage is particularly useful, more so if it matches what’s already on the “bare board”, which this is.

We have an SD driver even if the SD slot is empty from the factory.  Why not an NVMe driver baked in, even if the M.2 slot is empty from the factory?  I don’t really see the difference.


> 
>> 
>> How much work would it be, anyway, to have the options to build images that provision /var at install time, and a “sysupgrade” that supports it and doesn’t lose your configuration…
> 
> One solution could be to have two variants of the 'base-files' package:
> One with /var being tmpfs (like now), and one new, let's call it
> 'base-files-persistent-var' which would treat /var as persistent storage
> on an additional volume, or even as part of rootfs_data.


Or the boot script could simply peek into /etc/config/fstab and see if there’s a mount for /var ...


> The problem is that it doesn't end there, as an unknown number of
> packages also assumes that /var == /tmp, and all of them will have to be
> fixed.


At this point I’d settle for /var/log working… though if I ran a mail front-end (a relay only, not a mail store) on my OpenWRT, I’d probably want mail storage (/var/spool/mqueue or whatever) to be persistent so that undelivered email doesn’t get lost in the case of a reboot.