Target bananapi_bpi-r4-common

[Daniel Golle]

On Fri, Jul 04, 2025 at 11:47:26AM -0600, Philip Prindeville wrote:
> > On Jun 24, 2025, at 5:52 AM, Daniel Golle <daniel at makrotopia.org> wrote:
> > 
> > On Mon, Jun 23, 2025 at 08:15:15PM -0600, Philip Prindeville wrote:
> >>> On Jun 14, 2025, at 3:33 AM, Daniel Golle <daniel at makrotopia.org> wrote:
> >>>>> On Jun 13, 2025, at 5:01 PM, Daniel Golle <daniel at makrotopia.org> wrote:
> >>>>> On Fri, Jun 13, 2025 at 04:03:37PM -0600, Philip Prindeville via openwrt-devel wrote:
> >>>>>> Should the BPi-R4 be more richly provisioned?  It's got 4 or 8GB of DRAM so it's hardly a "skinny" platform.
> >>>>> 
> >>>>> I would leave that to the user and keep the default image with just what
> >>>>> is necessary. Diverging and creating "rich" images for specific devices
> >>>>> imho opens a can of worms which will require continous maintainance.
> >>>>> How would we decide which packages to include? How would we draw the line
> >>>>> for each and every board whether in our opinion the amount of flash and
> >>>>> ram is enough for any particular feature, and why some features are
> >>>>> present while others aren't?
> >>>> 
> >>>> Busybox has defaults that people are welcome to turn off.  Why not have something homologous for targets?
> >>> 
> >>> I don't understand...? Of course anyone who builds from source is free to
> >>> select all packages they want and is in no way bound to the default
> >>> package selection.
> >> 
> >> That goes both ways.  People can also unselect all the packages they don’t want.
> > 
> > People, yes. Automated build processes, such as the buildbots generating
> > the images for downloads.openwrt.org will just use the default.
> > And that's what people expect and is written in the various (3rd party)
> > docs, how-tos and so on.
> 
> 
> You’d think there would be an easy way to mark in the targets a list of platforms to not build via the automation, so we could built the “banana pi-r4 lite” in the automation, but leave it to users to build “banana pi-r4 full” (or whatever) themselves.

Technically this is easy. However, OpenWrt is democratically goverend project
with many participants. We need clear rules regarding what is allowed and
what isn't. When it comes to images: We want one image for each hardware.

There is a grey-zone here, for boards which have different incompatible
variants and for those we can have as many images as there are variants
(some SBC devboards, for example, come with a version with eMMC and a version
with SPI-NAND, it is not really cool but acceptable to have two different
images in order to allow the stock/vendor bootloader to work).

Having several images with merely a different default software configuration
is not acceptable, and I don't think that changing the rules regarding that
would fly with the other developers.

> >> We keep acting like every platform is a WRT54G w/ 64MB.  They’re not.  If we have room, let’s stretch out legs.
> > 
> > 4MB of flash and 16MB of RAM in case of the WRT54G btw, 32MB of RAM
> > on the WRT54GL version supported by OpenWrt ;)
> > 
> > Imho it should be up to the user to decide what to do with additional
> > resources. We obviously cannot ship everything, it will always have to
> > be a subset of the available packages.
> 
> 
> Well, and that’s to my point: if we support more memory in the form of NVMe, then users will have the room for whatever they choose to install.

And that's already true. Users can install kmod-nvme and setup extroot on
the NVMe, which potentially gives you terrabytes of space for software and
data of all kinds.


> 
> 
> > We already do have a 'small_flash' flag for devices with very little
> > flash, and we do have (not very often used) device types 'basic', 'nas',
> > and 'router' which influences the default selection. We could think
> > about introducing more device types.
> > 
> > Also this is a "two way road", in the sense that users chose OpenWrt
> > images even for eg. x86_64 VMs exactly because they fit into a very
> > small amount of storage and don't need much RAM. What you see as a flaw
> > others (including myself) see as a strength.
> 
> 
> 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.

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


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

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.