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
R4 is clear and can be also read from model string. SD does not make sense imho because eeprom value ist same when boooted from another device…but i guess you have seen the bootdevice detection code while inserting your changes?
Yes, I saw it. I wrote as an example how it could be. With those switches that I worked with, this line contained information about the license, capabilities, installed modules
Btw if you want to use eeprom to storage MAC addr/mem size and do auto load from eeprom, you can have a look at this implementation: u-boot/board/starfive/visionfive2/visionfive2-i2c-eeprom.c at master · u-boot/u-boot · GitHub
Imho such thing like setting mac address should be done generic and the tlv_eeprom goes in this direction…seems having less code than the starfive aproach.
1 Like
TLV_EEPROM it’s ONIE (Open Network Install Environment)
Onie installer it’s standart for whitebox switches I can prepare a special onie image.
And the whole installation will be done with one command. For example.
onie-nos-install https://example.com/filogic/arm64-bananapi_bpi_r4-r0.bin
ok, i tested with my “junk” data on eeprom - no error
fine so far, how is the tlv be initialized?
BPI-R4> i2c dev 2
Setting bus to 2
BPI-R4> tlv_eeprom read
EEPROM data loaded from device to memory.
tlv_eeprom - Display and program the system EEPROM data block.
Usage:
tlv_eeprom [read|write|set <type_code> <string_value>|erase|list]
tlv_eeprom
- With no arguments display the current contents.
tlv_eeprom dev [dev]
- List devices or set current EEPROM device.
tlv_eeprom read
- Load EEPROM data from device to memory.
tlv_eeprom write
- Write the EEPROM data to persistent storage.
tlv_eeprom set <type_code> <string_value>
- Set a field to a value.
- If no string_value, field is deleted.
- Use 'tlv_eeprom write' to make changes permanent.
tlv_eeprom erase
- Reset the in memory EEPROM data.
- Use 'tlv_eeprom read' to refresh the in memory EEPROM data.
- Use 'tlv_eeprom write' to make changes permanent.
tlv_eeprom list
- List the understood TLV codes and names.
BPI-R4> i2c bus
Bus 0: i2c@11004000
Bus 1: i2c@11005000 (active 1)
70: i2c-mux@70, offset len 1, flags 0
Bus 2: i2c@11005000->i2c-mux@70->i2c@0 (active 2)
57: eeprom@57, offset len 1, flags 0
i guess tlv_eeprom read only lists content if there is valid data.so i guess i need tlv_eeprom erase and then write the fields one-by-one,right?
BPI-R4> tlv_eeprom erase
EEPROM data in memory reset.
BPI-R4> tlv_eeprom set 0x2A 3
BPI-R4> tlv_eeprom set 0x24 F2:B8:7B:4D:00:01
BPI-R4> tlv_eeprom write
Programming passed.
BPI-R4> tlv_eeprom dev
BPI-R4>
imho the eeprom should be listed here, right?
BPI-R4> tlv_eeprom
TLV: 0
TlvInfo Header:
Id String: TlvInfo
Version: 1
Total Length: 18
TLV Name Code Len Value
-------------------- ---- --- -----
MAC Addresses 0x2A 2 3
Base MAC Address 0x24 6 F2:B8:7B:4D:00:01
CRC-32 0xFE 4 0x75E88454
Checksum is valid.
thought it is memory only but display with i2c command shows it on the eeprom
BPI-R4> i2c md 0x57 0 0x20
0000: 54 6c 76 49 6e 66 6f 00 01 00 12 2a 02 00 03 24 TlvInfo....*...$
0010: 06 f2 b8 7b 4d 00 01 fe 04 75 e8 84 54 ff ff ff ...{M....u..T...
seems always <code> <len bytes> <data>
but looks like the data is not applied yet (maybe needs reset), but after i did this (and loaded the tlv_eeprom binary) i got an endless loop (seems not stopping based on the mac-count field)
## Error inserting "eth1274add" variable, errno=12
## Error inserting "eth1275add" variable, errno=12
## Error inserting "eth1276add" variable, errno=12
## Error inserting "eth1277add" variable, errno=12
so something is wrong in the startup-code…i can see the eeprom-data with tlv_eeprom and mac-addresses are set.
BPI-R4> tlv_eeprom
TLV: 0
TlvInfo Header:
Id String: TlvInfo
Version: 1
Total Length: 18
TLV Name Code Len Value
-------------------- ---- --- -----
MAC Addresses 0x2A 2 3
Base MAC Address 0x24 6 F2:B8:7B:4D:00:01
CRC-32 0xFE 4 0x75E88454
Checksum is valid.
BPI-R4> printenv ethaddr
ethaddr=F2:B8:7B:4D:00:01
BPI-R4> printenv eth2addr
eth2addr=F2:B8:7B:4D:00:03
BPI-R4> printenv eth1addr
eth1addr=F2:B8:7B:4D:00:02
I guess set_mac is called before setting the length. but order seems right…
parse_tlv_data(eeprom_data, tlv_hdr, tlv_entry, td); //read data from eeprom to memory
set_mac_addr(td); //loop through (i = 0; i < td->maclen;), maclen should be 3
currently adding some debug-code and limiting the maclen before the loop 
looks like first it is set correctly, but after loading the mac address the length is set to 1278…maybe some memory corruption/overflow?
Not completely understood the code. Maybe it is important in which order the fields are written? I have first set the mac count an then the base mac
No. The order of the fields is not important.
That’s for sure! Most likely, more Fields are needed.
But I’m not sure about that.
Let’s check now.
