Maxime Ripard <maxime.ripard@xxxxxxxxxxx> [2019-05-12 14:19:10]:
> > @@ -29,6 +31,19 @@ Optional properties:
> > bits: Is pair of bit location and number of bits, which specifies offset
> > in bit and number of bits within the address range specified by reg property.
> > Offset takes values from 0-7.
> > +byte-indices: array, encoded as an arbitrary number of (offset, length) pairs,
> > + within the address range specified by reg property. Each pair is
> > + then processed with byte-transform in order to produce single u8
> > + sized byte.
> > +byte-transform: string, specifies the transformation which should be applied
> > + to every byte-indices pair in order to produce usable u8 sized byte,
> > + possible values are "none", "ascii" and "bcd". Default is "none".
> > +byte-adjust: number, value by which should be adjusted resulting output byte at
> > + byte-adjust-at offset.
> > +byte-adjust-at: number, specifies offset of resulting output byte which should be
> > + adjusted by byte-adjust value, default is 0.
> > +byte-result-swap: boolean, specifies if the resulting output bytes should be
> > + swapped prior to return
> >
> > For example:
> >
> > @@ -59,6 +74,36 @@ For example:
> > ...
> > };
> >
> > +Another example where we've MAC address for eth1 stored in the NOR EEPROM as
> > +following sequence of bytes (output of hexdump -C /dev/mtdX):
> > +
> > + 00000180 66 61 63 5f 6d 61 63 20 3d 20 44 34 3a 45 45 3a |fac_mac = D4:EE:|
> > + 00000190 30 37 3a 33 33 3a 36 43 3a 32 30 0a 42 44 49 4e |07:33:6C:20.BDIN|
> > +
> > +Which means, that MAC address is stored in EEPROM as D4:EE:07:33:6C:20, so
> > +ASCII delimited by colons, but we can't use this MAC address directly as
> > +there's only one MAC address stored in the EEPROM and we need to increment last
> > +octet/byte in this address in order to get usable MAC address for eth1 device.
> > +
> > + eth1_addr: eth-mac-addr@18a {
> > + reg = <0x18a 0x11>;
> > + byte-indices = < 0 2
> > + 3 2
> > + 6 2
> > + 9 2
> > + 12 2
> > + 15 2>;
> > + byte-transform = "ascii";
> > + byte-increment = <1>;
> > + byte-increment-at = <5>;
> > + byte-result-swap;
> > + };
> > +
> > + ð1 {
> > + nvmem-cells = <ð1_addr>;
> > + nvmem-cell-names = "mac-address";
> > + };
> > +
>
> Something along those lines yes. I'm not sure why in your example the
> cell doesn't start at the mac address itself, instead of starting at
> the key + having to specify an offset though. The reg property is the
> offset already.
The cell starts at the MAC address itself, 0x180 is offset within the EEPROM
and 0xa is byte within the offset (off-by-one, correct should be 0x9 though).
EEPROM byte within EEPROM offset
offset 1 2 3 4 5 5 6 7 8 9 a b c d e f
------------------------------------------------------------|-----------------
00000180 66 61 63 5f 6d 61 63 20 3d 20 44 34 3a 45 45 3a |fac_mac = D4:EE:|
00000190 30 37 3a 33 33 3a 36 43 3a 32 30 0a 42 44 49 4e |07:33:6C:20.BDIN|
So this would produce following:
eth1_addr: eth-mac-addr@189 {
reg = <0x189 0x11>; /* 0x44 0x34 0x3a 0x45 0x45 0x3a 0x30 0x37
* 0x3a 0x33 0x33 0x3a 0x36 0x43 0x3a 0x32 0x30 */
byte-indices = < 0 2 /* 0x44 0x34 */
3 2 /* 0x45 0x45 */
6 2 /* 0x30 0x37 */
9 2 /* 0x33 0x33 */
12 2 /* 0x36 0x43 */
15 2>; /* 0x32 0x30 */
byte-transform = "ascii"; /* 0xd4 0xee 0x7 0x33 0x6c 0x20 */
byte-increment = <1>;
byte-increment-at = <5>; /* 0xd4 0xee 0x7 0x33 0x6c 0x21 */
byte-result-swap; /* 0x21 0x6c 0x33 0x7 0xee 0xd4 */
};
-- ynezz
