[U-Boot] [Turris Omnia] Is there a standard approach to write a driver for CryptoAuthentication/EEPROM chip?
Hello, I have few questions about upstreaming support for the Turris Omnia into u-boot.
The Turris Omnia has (on I2C interface) an Atmel ATSHA204 CryptoAuthentication chip for storage of MAC adresses, device serial number, device configuration (1 GB RAM vs 2 GB RAM). This data is stored in the internal EEPROM of ATSHA204. The chip is capable of more: for example there is also a random number generator. For more info see http://www.atmel.com/Images/Atmel-8740-CryptoAuth-ATSHA204-Datasheet.pdf
I want to write support for the ATSHA204 for upstream U-Boot so that I can then continue working on support for Turris Omnia. Currently we have our internal branch of U-Boot, in which the ATSHA204 code is in drivers/misc (see https://gitlab.labs.nic.cz/turris/turris-omnia-uboot/blob/master/drivers/mis... ).
My question: Does U-Boot have a standard approach how to write a driver for such a chip? Does this device need to be defined in the Device Tree?
Thank you.
Marek
Hello Marek,
Am 25.04.2017 um 15:27 schrieb Marek Behún:
The Turris Omnia has (on I2C interface) an Atmel ATSHA204 CryptoAuthentication chip for storage of MAC adresses, device serial number, device configuration (1 GB RAM vs 2 GB RAM). This data is stored in the internal EEPROM of ATSHA204. The chip is capable of more: for example there is also a random number generator. For more info see http://www.atmel.com/Images/Atmel-8740-CryptoAuth-ATSHA204-Datasheet.pdf
I want to write support for the ATSHA204 for upstream U-Boot so that I can then continue working on support for Turris Omnia.
First of all, why do you see that as a blocking component? You could initially assume the RAM size to be the lower of the two, i.e. taken from the device tree. An RNG seems nice to have, not crucial!
Getting a defconfig that boots to a serial prompt from an Omnia device tree (without getting reset by your MCU watchdog) would already be a good initial patchset, that further features could then be added to in follow-up patchsets. Just like current lack of btrfs support would still allow booting from an ext4 medium initially.
Currently we have our internal branch of U-Boot, in which the ATSHA204 code is in drivers/misc (see https://gitlab.labs.nic.cz/turris/turris-omnia-uboot/blob/master/drivers/mis... ).
My question: Does U-Boot have a standard approach how to write a driver for such a chip? Does this device need to be defined in the Device Tree?
I think the first step would be to get a driver into the Linux kernel - when I checked during my Omnia upstreaming attempt, there was none.
The driver framework you probably need is called mfd, and on the kernel side you would also determine the device tree bindings. Yes, the device needs to get added to the device tree, but U-Boot usually imports the device tree from Linux, so don't try to invent things differently here please.
Don't really know about EEPROM drivers, but Rockchip has an efuse driver and there will probably be many more in-tree examples in U-Boot.
Please keep me CC'ed on your Turris Omnia efforts.
Thanks, Andreas
participants (2)
-
Andreas Färber -
Marek Behún