seems 256 is the largest blocksize to be written.
eeprog seems having no package on debian and needs to be compiled
The 24c02 is only 256 bytes 
Yes you are right,i thought it was a bit bigger (at least kbytes),but linux kernel confirms
at24 2-0057: 256 byte 24c02 EEPROM, writable, 1 bytes/write
It is set in the devicetree,size = 256, but for this eeprom, it is the actual size.
AT24C02A/04A : PAGE WRITE: The 2K EEPROM is capable of an 8-byte page write, and the 4K device is capable of 16-byte page writes.
So should be able to add:
pagesize = <8>;
To the devicetree, but leaving it out <1> is the safer option, get it functional without first.
The WP pin is connected to the same gpio pin as the green led So you would need to switch this led on or off to enable writing to the eeprom.
1 Like
tlv_eeprom
For Board Information (Type Code and Value) https://opencomputeproject.github.io/onie/design-spec/hw_requirements.html
This information can now be used to pre-configure the device. For example, assigning mac address
How to use
Add this line to .config
CONFIG_CMD_TLV_EEPROM=y
Read and erase eeprom data
tlv_eeprom read
tlv_eeprom eraseProgramming data to eeprom
tlv_eeprom set 0x21 'BananaPI BPI-R4'
tlv_eeprom set 0x22 '<Serial Number>'
tlv_eeprom set 0x25 'DD/MM/YYYY HH:MM:SS'
tlv_eeprom set 0x26 '0x01'
tlv_eeprom set 0x24 '<Base Mac Address>'
tlv_eeprom set 0x2A '<Number of mac address (3 GMAC == 3 mac Address)>'
tlv_eeprom set 0x28 '(aarch|arm)64-bananapi_bpi_r4-r0'
tlv_eeprom set 0x2B 'Mediatek'
tlv_eeprom set 0x2D 'Sinovoip'
tlv_eeprom writeEnjoy
Ah,this is a command in mainline uboot?
Does it generate 3 mac addresses based on the base mac? Does it update devicetree for linux?
At the moment, no. But I’m working on it.
But basic read+write seems to work now,right?
Yes. i’ts work. EEPROM is now programming.
good point, but in uboot and linux i have not defined the green led yet, so at least they should operate the same way, and not only ro in linux.
so WP is GPIO79_V1P8_VBUS_P0 green led is GPIO79_V1P8_VBUS_P0 blue led is GPIO79_V1P8_VBUS_P1
so both leds seem to share same gpio which is strange (but maybe an mistake in my shematic). but i try to add green led to toggle the WP in linux.
i have found this definition (i guess from daniel):
gpio-leds {
compatible = "gpio-leds";
led_green: led-green {
function = LED_FUNCTION_STATUS;
color = <LED_COLOR_ID_GREEN>;
gpios = <&pio 79 GPIO_ACTIVE_HIGH>;
default-state = "on";
};
led_blue: led-blue {
function = LED_FUNCTION_WPS;
color = <LED_COLOR_ID_BLUE>;
gpios = <&pio 63 GPIO_ACTIVE_HIGH>;
default-state = "off";
};
};
Ok,you set the env with the eeprom…are the macs then inserted into the devicetree and used in linux? Afair thia requires changes to devicetree too.
Yes i’m set mac address from eeprom
No, changes in device tree are not needed.
my VyOS apply this settings correct
@ericwoud you were right, if i switch off the green led, i can write to the eeprom. seems like uboot driver pulls the pins down where linux leave them unconfigured, writing when green led is on also does not work
# echo 0 > /sys/class/leds/green\:status/brightness #switch led off
# echo 'Hello World!' | dd of=/sys/bus/i2c/devices/2-0057/eeprom
0+1 records in
0+1 records out
13 bytes copied, 0.0253694 s, 0.5 kB/s
root@bpi-r4-v11:~
# cat /sys/bus/i2c/devices/2-0057/eeprom | hexdump -C
00000000 48 65 6c 6c 6f 20 57 6f 72 6c 64 21 0a ff ff ff |Hello World!....|
00000010 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
*
000000f0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 00 |................|
00000100
verify write-protect by switching on the led again…
# echo 1 > /sys/class/leds/green\:status/brightness
root@bpi-r4-v11:~
# dd if=/dev/zero of=/sys/bus/i2c/devices/2-0057/eeprom bs=1 count=13
13+0 records in
13+0 records out
13 bytes copied, 0.00506746 s, 2.6 kB/s
root@bpi-r4-v11:~
# cat /sys/bus/i2c/devices/2-0057/eeprom | hexdump -C
00000000 48 65 6c 6c 6f 20 57 6f 72 6c 64 21 0a ff ff ff |Hello World!....|
00000010 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
*
000000f0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 00 |................|
00000100
root@bpi-r4-v11:~
# echo 0 > /sys/class/leds/green\:status/brightness
root@bpi-r4-v11:~
# dd if=/dev/zero of=/sys/bus/i2c/devices/2-0057/eeprom bs=1 count=13
13+0 records in
13+0 records out
13 bytes copied, 0.0260413 s, 0.5 kB/s
root@bpi-r4-v11:~
# cat /sys/bus/i2c/devices/2-0057/eeprom | hexdump -C
00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 ff ff ff |................|
00000010 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
*
000000f0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 00 |................|
00000100
# echo 1 > /sys/class/leds/green\:status/brightness
root@bpi-r4-v11:~
# dd if=/dev/zero of=/sys/bus/i2c/devices/2-0057/eeprom bs=1 count=13
13+0 records in
13+0 records out
13 bytes copied, 0.00506746 s, 2.6 kB/s
root@bpi-r4-v11:~
# cat /sys/bus/i2c/devices/2-0057/eeprom | hexdump -C
00000000 48 65 6c 6c 6f 20 57 6f 72 6c 64 21 0a ff ff ff |Hello World!....|
00000010 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
*
000000f0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 00 |................|
00000100
root@bpi-r4-v11:~
# echo 0 > /sys/class/leds/green\:status/brightness
root@bpi-r4-v11:~
# dd if=/dev/zero of=/sys/bus/i2c/devices/2-0057/eeprom bs=1 count=13
13+0 records in
13+0 records out
13 bytes copied, 0.0260413 s, 0.5 kB/s
root@bpi-r4-v11:~
# cat /sys/bus/i2c/devices/2-0057/eeprom | hexdump -C
00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 ff ff ff |................|
00000010 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
*
000000f0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 00 |................|
00000100
@xDarkmanx i have added your patch currently only in separate branch (not tested yet) because i need some time to look if we can do this generic using (and maybe extending) the tlv_eeprom header/code instead of writing board/soc specific code.
Does mac setting depend on additional settings (e.g. in devicetree) not yet in mainline linux or my patches? Afair uboot needs the ethernet aliases mapped to gmac. Am i right?
edit: tested it…with aliases u-boot sets the mac-adress (of gmac0) without them it does not (so i add them in my next dts series).
btw. setting mac manually (or via script) needs -f switch for setenv
BPI-R4> setenv ethaddr "F2:B8:7B:4D:05:D6"
## Error: Can't overwrite "ethaddr"
## Error inserting "ethaddr" variable, errno=1
BPI-R4> printenv ethaddr
ethaddr=22:28:ea:9b:09:e9
BPI-R4> setenv -f ethaddr "F2:B8:7B:4D:05:D6"
BPI-R4> printenv ethaddr
ethaddr=F2:B8:7B:4D:05:D6
BPI-R4> setenv -f eth1addr "F2:B8:7B:4D:05:D7"
BPI-R4> setenv -f eth2addr "F2:B8:7B:4D:05:D8"
added gpio-leds and ethernet-aliases to my dts-patches which i plan to send out when 6.16-rc1 is out and the cci-binding is reviewed
https://patchwork.ozlabs.org/project/devicetree-bindings/patch/[email protected]/
edit: looked a bit in the code (and did some reformatting)…looks generic so far (and consts are only comment have not seen this in patch-file). have you tested with empty eeprom (u-boot should not crash because of invalid data, but i guess this is avoided with crc-field)?
CRC-32 (0xFE field) сalculated at the time of change and does not require setting.
I have 3 identical devices
On the first device, until I entered a valid tlv header, the eeprom could not be programmed
After I entered the patch and tried it on the second one, I was able to flash it without any additional manipulations
I find it difficult to answer your question.
i mean not every user wants to use tlv…if i add the patch to my main branch there should be 3 ways possible:
- users with empty eeprom should not be affected (no crash, writing non-tlv-data must be possible)
- users with non tlv eeprom data should be affected (again no crash and no error because of “invalid” data)
- users with tlv eeprom data should be able to use it
btw. sent i2c mux driver update to ML
https://patchwork.ozlabs.org/project/uboot/patch/[email protected]/
Dts patch is not upstreamable because i use and modified rfb dts.
Aaaaa ok. I can answer this.
- if eeprom is empty. There are no errors.
- If eeprom is empty and do not use the tlv_eeprom command. The behavior of u-boot works as before.
- Usage this code begins with execution
tlv_eeprom read
tlv_eeprom erase
tlv_eeprom write
Additional information can be written to this parameter 0xFD For example
tlv_eeprom set 0xFD 'R425SDWF'
R4 - BPI-R4
25 - With 2.5 Gb Instead of 10Gb
SD - Boot from SD
WF - WiFi card installed