[BPI-R3][BPI-R4] Normal Linux OS instead of openwrt

Banana Pi Router design BPI-R4(MT7988)
1

Hi,

The BPI-R3 and BPI-R4 have more than 512MB of RAM and SD Card and NVME storage.

With these larger systems, there is no need for smaller systems like openwrt, and one can use a real Linux OS distro on them. There is still a need for openwrt for space limited systems. I am only suggesting this for larger systems.

I would like to make some effort to port something like Luci over to a real Linux OS distro like debian or ubuntu. I.e. A web based status and configuration tool for Wifi AP capabilities etc.

Is there anyone else here who would like this, or is it only me?

2

Hi， we have Debian and ubuntu releared.

3

I don’t think porting LuCi is necessary or even feasible, since it is probably very tightly integrated with OpenWrt.

Instead, there are plenty of other tools available for web-based server management. I just googled and found this https://cockpit-project.org, but also remembered this name https://webmin.com. And if you search some more, there will be plenty of others.

What we could instead work on, is a generic U-Boot image that can load any (Linux) OS using UEFI and ARM SystemReady if you want something to do. :wink:

4

U-Boot already loads any Linux OS on the BPI-R3 and BPI-R4. Why does it need any development?

Also, I don’t think either cockpit or webmin can manage Wifi APs.

5

Only with additional work. Not out of the box with just dd’ing any Linux image to the SD card or NVME and just boot it like you would on a PC.

I haven’t checked that. Those were the results of 5 seconds of online search. There are probably others out there. I just have doubts that LuCi is that easy to port to other systems, especially if it integrates with the UCI configuration system that is not standard on Linux.

6

@totkeks I don’t think you understand what you are asking for.

Any arm64 / aarch64 is not a PC.

I PC has a BIOS / UEFI that is provided by the manufacturer of the board. The BIOS / UEFI contains a lot of board specific details in ACPI tables.

arm64 platforms have no BIOS / UEFI.

arm64 platforms have to supply a device tree file that is essentially the equivalent of the ACPI tables.

arm64 platforms have a uboot that is equivalent to the BIOS / UEFI, but it has to be put on a storage device, e.g. sd card, nand, mmc by the user.

In summary, arm64 platforms are just different and achieving what you are asking for is not feasible.

The best you can do is have a single Linux kernel image that runs on many different arm64 platforms, with the device-tree and uboot being specific to the particular board.

7

Web configuration tools cannot do all whats possible in system and they are mostly a high security risk…

So if you have freetime you can help gerting linux kernel things to work…there are many not yet working on r4 and mainline kernel…e.g. rtc,eeprom,wifi card, rss/lro, …

8

This what has been described by Daniel multiple times: A boot loader (on NAND/NOR) that supports UEFI boot / ARM SystemReady. Which could be achieved with a modified U-Boot, now that NVMe support for R3 and R4 is in U-Boot.

Of course, one would still need a specific bootloader for each type of board, just like with a PC BIOS. But it would be another step towards standardization for SBCs, Banana PIs in particular.

No more need for special images for Debian, Armbian, Arch and so on. That would be the goal.

9

@totkeks You can do that already if you wish. No dev work needed.

Just load the uboot onto the NAND/eMMC and use the correct uenv settings and dip switch settings.

Summary:

The device you use for loading uboot does not have to be the same device you use to load the linux kernel.

10

That’s exactly the dev work that I’m talking about, because no one has set U-Boot up that way yet.

11

Well, rtc and eeprom already works. My BPI-R4 eeprom is just filled with 0xff

12

How do you acceess eeprom? I do not see 0x57 in i2cdetect? Have you changed its address too?

Uboot-setup is a bit tricky as uboot needs to probe available devices (sdmmc/emmc and nand/nor) on r3/r4 to set bootconf for fip. I’m not sure this works with stdboot

13

Hi,

The eeprom uses the at24.ko linux kernel module. Its on i2c bus 2, device 0x57

i2cdetect -y 2    <- The UU in the output means the Linux kernel is using those devices, and user-space is then denied access to it.
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:                         -- -- -- -- -- -- -- -- 
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
50: -- UU -- -- -- -- -- UU -- -- -- -- -- -- -- -- 
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
70: UU -- -- -- -- -- -- --                         


modprobe at24    (general driver for most i2c eeproms)
hexdump -C /sys/bus/i2c/devices/2-0057/eeprom

One will need to add the write protect gpio to the eeprom device tree before one can write to it.

14

Do you see a device on this i2c bus at address 0x57…i only see 0x32 on same bus as rtc. Any message in dmesg (maybe it is detected and i have not seen it)? Have builtin at24 driver (CONFIG_EEPROM_AT24=y). Can we give the gpio (seems 79) to the devicetree for write enable?

15

I used “CONFIG_EEPROM_AT24=m” but “y” should work just as well.

If you tell me what line to add to the .dts file, I can do that.

16

[ 1.515672] at24 2-0057: 256 byte 24c02 EEPROM, writable, 1 bytes/write

booted again and already see it and it is writable…strange that it was not visible to i2cdetect, and yes now i see it also as UU…no dts change needed

17

Ah, I cannot get it to be writable. The dmesg says writable, but this does not actually write anything:

echo "Hello" > /sys/bus/i2c/devices/2-0057/eeprom
18

mhm, there is no error, but readback returns only 0xff

# echo "Hello" > /sys/bus/i2c/devices/2-0057/eeprom
# hexdump -C /sys/bus/i2c/devices/2-0057/eeprom
00000000  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
*
00000100
#

but we are going offtopic, sorry…we should create new thread for eeprom…

dts-property should be

wp-gpios = <&pio 79 GPIO_ACTIVE_LOW>;
19

Thus I think it needs an extra line in the .dts file.

20

It does not need any extra gpio lines in the .dts file. The WP line is linked to the Green LED line.

High == Green LED on. WP enabled.
Low == Green LED off, WP disabled.

echo 0 > /sys/devices/platform/gpio-leds/leds/green:status/brightness
echo "Hello" > /sys/bus/i2c/devices/2-0057/eeprom
hexdump -C /sys/bus/i2c/devices/2-0057/eeprom
00000000  48 65 6c 6c 6f 0a ff ff  ff ff ff ff ff ff ff ff  |Hello...........|
00000010  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
*
00000100
echo 1 > /sys/devices/platform/gpio-leds/leds/green:status/brightness