Target bananapi_bpi-r4-common

[Daniel Golle]

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.

As I said, maintaining dedicated package selections for thousands of
devices is not feasible for a small team of volunteer maintainers. There
has to be a clear rule which packages should be included for each board.
For now this rule is to include the default selection of packages for
the class of device (ie. "router" in this case) plus the kernel drivers
and userland tooling for whatever hardware the board comes with.
We risk getting into endless discussions whether packages for a specific
use-case should be included on a specific board.

Of course, again, the community is free to provide such rich images for
specific devices, and if you take a look into the forums you will find
plenty of them.

> >>> The 2.5GE PHY is built-into the SoC and apart from being populated
> >>> differently the boards are identical, there is no iway to detect in
> >>> software which variant we are dealing with. SinoVoip equips the R4 with
> >>> some I2C EEPROMs which would be perfectly suitable to be used to indicate
> >>> the board variant or even contain a factory-assigned MAC address. Sadly
> >>> they come all empty.
> >> 
> >> 
> >> Well, it's EEPROM, so it can be reblown, right?
> > 
> > Sure, but as it isn't done in factory it's just another piece of
> > persistent memory the user can do with what ever they want.
> > We cannot use it to find out which board we are dealing with.
> > 
> >> Don't know anything about that.  I do my own monolithic builds from scratch.  Don't use image-builder.
> > 
> > Ok, then you can anyway always divert from defaults in any way you
> > want. What is restricting you?
> 
> 
> Nothing, but I’m not an expert in the hardware of every platform.  Having the profile preselect most of the relevant packages and drivers for me would be helpful.
> 
> For instance, the BPi-R4 I got came with an image that doesn’t have NVMe drivers/utilities installed, nor does it seem to have a uboot that can boot from NVMe.

The board also doesn't come with an NVMe. It comes with an M.2 slot, and
PCIe drivers are included. What ever you want to connect to that M.2
slot is up to you. Without any adapters this could already in this case
as well be an AHCI SSD as well, or a SATA host controller offering
actual SATA ports, ...

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

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.

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