[bpi-r4] eeprom

Banana Pi Router design BPI-R4(MT7988)
1

Hi,

to no more hijacking the old thread i made one for this topic

We have the eeprom detected, it reports writable, but write does not work. 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
#

dts-property should be

wp-gpios = <&pio 79 GPIO_ACTIVE_LOW>;

so i added it to my dts, but there is no change :frowning:

any idea?

2

It does not need any extra gpio lines in the .dts file. Adding the wp-gpio lines actually causes the at24 module to fail to load because it notices the conflict with the green led driver.

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
1 Like
3

nice, right, it is also stated in schematics, but not noticed it :stuck_out_tongue:

can confirm it works like you’ve wrote

# echo 0 > /sys/devices/platform/gpio-leds/leds/green:status/brightness
root@bpi-r4-v11:~
# echo "test" > /sys/bus/i2c/devices/2-0057/eeprom
root@bpi-r4-v11:~
# hexdump -C /sys/bus/i2c/devices/2-0057/eeprom
00000000  74 65 73 74 0a ff ff ff  ff ff ff ff ff ff ff ff  |test............|
00000010  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
*
00000100
root@bpi-r4-v11:~
# echo 1 > /sys/devices/platform/gpio-leds/leds/green:status/brightness
root@bpi-r4-v11:~
4

Just out of interest, now that the eeprom works, do you have any ideas what to use it for?

5

you can write a mac-adress there for ethernet and wifi as imho these are not fixed, but not sure if they can be read via dts linking or changed from userspace afterwards

6

Regarding MAC addresses. I have seen on other platforms two different methods used, so I expect they are both already in the kernel source code:

On ARM platforms:

  1. stored in uboot env variables, then uboot passes them in the command line. uboot can also use these for net-boot. This is quite a good solution as it can be both used by uboot and edited by the user if needed. I think uboot can also insert these from the env into the device tree.
  2. stored in the device tree.

On X86:

  1. Stored in the ethernet device hardware
  2. Stored in the BIOS

I don’t see any harm in adding the eeprom as an option for a source of MAC addresses.

7

afaik for the uboot-way it needs to support all ethernet-interfaces in uboot, imho only eth0 from r4 is currently supported

8

We could read MAC addresses from eeprom in uboot, and modify dtb that uboot passes to Linux. This doesn’t need uboot to have driver for the ethernet MAC.

9

Do you have an example code? I found some threads only defining nodes in dts (seems like linux is also able to do this).

Does this happen after dtos are applied from fit?

And can we only set mac of mac or for dsa user ports too?

10

Edit: Uboot would automatically patch “/aliases/ethernet” items in dtb with mac address inside the u-boot environment, by using fdt_fixup_ethernet() function. This should work for MACs but not for DSA ports. And for switch ports, I only find this, maybe we need some modification on the switch driver to make it work: linux/Documentation/devicetree/bindings/net/ti,cpsw-switch.yaml at 448b3fe5a0eab5b625a7e15c67c7972169e47ff8 · torvalds/linux · GitHub

For eeprom operation implementation, you can check this: u-boot/board/starfive/visionfive2/visionfive2-i2c-eeprom.c at master · u-boot/u-boot · GitHub

For mac address modification, it could be done in uboot’s board support file using ft_board_setup function. Tegra has an implementation here:

11

as u-boot does not see the dsa-ports the only (and maybe the easiest) way will be mapping a mac-adress-property there, but would be better to have phandle to eeprom-subnode

12

We need to write a driver for handling mac address inside the eeprom if we want to do in in linux rather than uboot. I don’t think upstream would accept it.

13

I have another device that has the same chips as the bpi-r4. It looks for local-mac-address in the device tree.

E.g.

                     mac@0 {
                                local-mac-address = [38 f8 f6 01 02 03];
                                compatible = "mediatek,eth-mac";

local-mac-address is not in the dtb file, it must get injected into the device tree by uboot. It uses the single mac address it finds, and then just adds one to the last digit for any other ethernet interfaces it needs.

14

Looking at the kernel source code. It can get the MAC address from two locations:

  1. device-tree
  2. nvram

If we wish to get it from nvram, we probably need to have the nvram calls read the eeprom In which case, the variables stored in nvram are of the string form "mac-address= … " One would have to check the kernel source code to check exactly what format the MAC address is expected to be. So, in summary, so long as we store the MAC address in a format that the existing Linux kernel source code expects, we should not need to upstream anything.

15

Sdk uses mtd-mac-address property to load mac from nand/nor

https://git01.mediatek.com/plugins/gitiles/openwrt/feeds/mtk-openwrt-feeds/+/9cc6da78fb163c3b30c13dd8b20d6a70f145bda0

16

but that requires changes to the Linux kernel source code for a mediatek specific method of setting MAC addresses. Upstream will probably reject it, in favor of a more generic method of setting MAC address. I.e. the methods already available in the upstream linux kernel source code. I think we could get the upstream method of reading the MAC address from NVRAM to work on the BPI-R4, and thus no need any upstream changes. It would just be a matter of formatting the MAC address correctly and putting it where the upstream kernel expects to see it.

17

No, local-mac-address could be coded in original dts as a default address. And mac-address would override that and should be injected to dtb by bootloader.