Target bananapi_bpi-r4-common
Philip Prindeville
philipp_subx at redfish-solutions.com
Mon Jun 23 19:15:15 PDT 2025
> On Jun 14, 2025, at 3:33 AM, Daniel Golle <daniel at makrotopia.org> wrote:
>
> On Fri, Jun 13, 2025 at 09:00:31PM -0600, Philip Prindeville 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.
>
>>> The 2.5GE PHY is built-into the SoC and apart from being populated
>>> differently the boards are identical, there is no way 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.
We keep acting like every platform is a WRT54G w/ 64MB. They’re not. If we have room, let’s stretch out legs.
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.
-Philip
>
>> Yeah, probably. I'll look for them.
>>
>>
>>>>
>>>> Oh, one other question... I see there's a FPC connector for an extra LAN port (not clear if it's switched or not). Has anyone used that and what's the cable to make that work? Is there a knock-out machined into the case of an extra port? And the diagram here:
>>>>
>>>> https://docs.banana-pi.org/en/BPI-R4_Pro/BananaPi_BPI-R4_Pro
>>>
>>> That's the R4 Pro, it's again a different board which isn't yet
>>> publicly available.
>>
>>
>> Oh, quite right. Here's the "standard" board:
>>
>> https://docs.banana-pi.org/en/BPI-R4/BananaPi_BPI-R4
>>
>> And as you say, 10 GBE WAN (SFP), 1GBE WAN, 3x GBE switched.
>
> ... OR the 2.5G-PoE variant with only a single SFP+ cage and another
> 2.5GE RJ-45 instead instead.
More information about the openwrt-devel
mailing list