From: "Marek Behún" <kabel@kernel.org>
To: Luka Kovacic <luka.kovacic@sartura.hr>
Cc: "Pali Rohár" <pali@kernel.org>,
"Robert Marko" <robert.marko@sartura.hr>,
U-Boot-Denx <u-boot@lists.denx.de>, "Stefan Roese" <sr@denx.de>,
"Luka Perkov" <luka.perkov@sartura.hr>
Subject: Re: [PATCH 1/2] arm: mvebu: Implement the mac command (Marvell hw_info)
Date: Mon, 11 Oct 2021 12:56:34 +0200 [thread overview]
Message-ID: <20211011125634.32dab223@dellmb> (raw)
In-Reply-To: <CADZsf3YF3N5+vzsBfYBzDCQ7Ja3JTz-WGUJ0_gikuqHcOXsXUw@mail.gmail.com>
On Mon, 11 Oct 2021 12:19:07 +0200
Luka Kovacic <luka.kovacic@sartura.hr> wrote:
> Hello Pali,
>
> > Something like this? compatible = "marvell,hw-info"
>
> This compatible string looks good to me.
> We will send a new patch version, which implements the discussed DT
> functionality.
>
> > > I am sure Luka knows more about the format than me.
>
> The Marvell hw_info partition is very similar to the U-Boot
> environment. The only difference is in the separator between the
> "key=value" pairs, which is 0x20/space in the case of hw_info.
> This is also prevents us to hard-code the parameter addresses in the
> device tree, because they can move around.
>
> The checksum is stored before the hw_info environment - this would
> have to be investigated further to implement checksum verification.
These differences between Marvell's version and U-Boot's standard
environment version can be specified in device-tree (via compatible or
other properties) and handled by one driver.
A driver for nvmem provider of standard U-Boot env could have this
binding (with "denx,u-boot-env" as compatible, changing it to
"marvell,hw-info" would make it work with spaces instead of '=' as
separator):
spi-flash {
blah blah blah;
partitions {
compatible = "fixed-partitions";
#address-cells = <1>;
#size-cells = <1>;
hw-info@18000 {
compatible = "denx,u-boot-env";
reg = <0x18000 0x1000>;
label = "hw-info";
eth0_mac_addr: ethaddr {
compatible = "mac-address-string";
name = "ethaddr";
};
eth1_mac_addr: eth1addr {
compatible = "mac-address-string";
name = "eth1addr";
};
};
};
};
ethernet@30000 {
nvmem-cells = <ð0_mac_addr>;
nvmem-cell-names = "mac-address";
};
On Turris MOX, we have the MAC address of the device stored in
One-Time-Programmable memory accesible only by the secure coprocessor,
which Linux communicates with via the turris-mox-rwtm kernel driver.
Currently this driver does not register itself as a nvmem provider, and
so isn't use by the ethernet controller driver to get MAC addresses.
MAC addresses are currently read by U-Boot board code and the
controller keeps these to Linux.
But I plan to extend the turris-mox-rwtm driver to also provide MAC
addresses via nvmem API, and then specify in device-tree
ð1 {
nvmem-cells = <&rwtm_eth1_mac>;
nvmem-cell-names = "address";
};
Maybe in the future you will also want to implement this in Linux.
It could be done simply by adding a new type of nvmem provider, with
compatible = "marvell,hw-info".
Luka, what do you think?
Marek
next prev parent reply other threads:[~2021-10-11 10:56 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-10-08 12:09 [PATCH 1/2] arm: mvebu: Implement the mac command (Marvell hw_info) Robert Marko
2021-10-08 12:09 ` [PATCH 2/2] arm: mvebu: add Globalscale MOCHAbin support Robert Marko
2021-10-08 12:53 ` [PATCH 1/2] arm: mvebu: Implement the mac command (Marvell hw_info) Pali Rohár
2021-10-08 13:28 ` Luka Kovacic
2021-10-08 18:06 ` Pali Rohár
2021-10-09 9:42 ` Marek Behún
2021-10-09 10:09 ` Robert Marko
2021-10-09 10:29 ` Pali Rohár
2021-10-11 10:19 ` Luka Kovacic
2021-10-11 10:56 ` Marek Behún [this message]
2021-10-11 16:16 ` Luka Kovacic
2021-10-13 14:44 ` Marek Behún
2021-10-13 15:35 ` Luka Kovacic
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20211011125634.32dab223@dellmb \
--to=kabel@kernel.org \
--cc=luka.kovacic@sartura.hr \
--cc=luka.perkov@sartura.hr \
--cc=pali@kernel.org \
--cc=robert.marko@sartura.hr \
--cc=sr@denx.de \
--cc=u-boot@lists.denx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox