Target bananapi_bpi-r4-common

[Philip Prindeville]

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


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


Well, that depends who you buy it from.  There are a couple of vendors online that bundle with modem cards, SSD or NVMe sticks, etc.


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


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


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

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…

-Philip