[bpi-r4] eeprom

Banana Pi BPI-R4/BPI-R3 Mini/BPI-R3/BPI-R64/BPI-R2
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