Hey Iain,
On 17-03-15 01:38, Iain Paton wrote:
On 16/03/15 09:51, Hans de Goede wrote:
2) Are the eeproms prepolulated on ALL olinuxino-s ? If they are not
populated from the factory, I see little added value and I think I may
end up nacking any patches for this, but first lets hear your arguments :)
The eeproms are physically present on all boards as far as I can tell,
however on every olinuxino I have, they are blank from the factory (i.e.
content of every byte is 0xFF).
Yeah they are all blank, with good purpose, it's for the user to define
what to do with it ;)
If Olimex have defined a format for the contents of the eeprom, I've
not been able to find it.
So while I have no objection to using the eeprom for something like this,
can we at least try to come up with something that:
1) Is optional.
2) Is disabled by default.
3) Allows for configurable format
4) Allows for configurable i2c bus and address (i.e. so you can add an
eeprom to a cb2)
That's almost so obvious it may be overlooked, but of naturally. I think
i put it in one of the previous e-mails, but that's why you want a
crc/checksum, if it's valid, use it, if not don't. Making it
configurable is also one of those obvious things of course.
As for 3, not sure how feasible that is. Where do you store the storage
definition? First few bytes defines the storage, then the actual
storage? While possible, it adds a lot of overhead. But as always,
everything is up for discussion.
That way we don't stomp all over existing users while allowing people who
want the feature to easily enable it.
of course :)
It would obviously also be good if when the feature is disabled, or we
detect that the eeprom contains invalid data, then we fall back to using
the current SID based method for generating the MAC.
There's one obvious question for me with any scheme like this. Olliver
might want a 10 character serial number, I might want 12, someone else
wants 15. How do we handle that?
We can prefix the serial with a length byte :)
Would have been easier if Olimex put a unique serial number in the
eeprom, but as it's already too late for that we shouldn't put ourselves
in a corner that results in everyone using the same set of serial numbers.
Easier, yes, but not useful at all. On our end, for example, we want to
have our own unique serial numbering scheme, unrelated to Olimex's
numbering. Now we may use olimex boards, in the future, we may decide to
build our own boards, for example.
Is there any chance of using something in DT to define the format?
Good question ...
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
