U-Boot Archive on lore.kernel.org
 help / color / mirror / Atom feed
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 = <&eth0_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
  &eth1 {
    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 

  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