Hi Anand,
On Tue, Feb 26, 2019 at 11:26 AM Anand Moon <linux.am...@gmail.com> wrote:
>
> Hi Martin,
>
> On Mon, 25 Feb 2019 at 17:49, Anand Moon <linux.am...@gmail.com> wrote:
> >
> > hi Martin,
> >
> > +Bartosz Golaszewski <bgolaszew...@baylibre.com>
> >
> > On Mon, 25 Feb 2019 at 02:25, Martin Blumenstingl
> > <martin.blumensti...@googlemail.com> wrote:
> > >
> > > I have seen Anand's your question in [0]:
> > > > only issue is I have is the each time their is random MAC address so I
> > > > get new IP from dhcp server.
> > > > How can I avoid this. I have tried to enable eFuse driver but with no
> > > > success.
> > >
> > > u-boot on the 64-bit SoCs can read the MAC address from the eFuse and
> > > pass it (via the .dtb) to the kernel.
> > > This requires an ethernet0 alias in the mainline .dts though, see [1]
> > > for and example.
> > >
> > > I'm not sure if this also works with the older u-boot on the 32-bit SoCs.
> > > if it doesn't then there's a nvmem-cells binding for all Ethernet
> > > controllers: [2] (please note that the function implementing this
> > > binding was recently renamed: [3])
> > > as far as I can tell the stmmac driver doesn't support the nvmem-cells
> > > based binding yet
> > >
> > > Anand, if you want to work on this: feel free to do so!
> > > I have the SDHC MMC driver and a discussion about the power-domain
> > > drivers on my TODO-list, so I'm pretty busy at the moment.
> > >
> > >
> > > Regards
> > > Martin
> > >
> >
> > Thanks for your inputs :) 8)
> >
> > After enable CONFIG_MESON_MX_EFUSE and added the alias
> >
>
> As far as I can tell this nvmem consist of field.
> Board ID
> MAC address
> Serial Number
> UID
>
> I feel efues value in nvmem are read with following offset just for testing.
> but it also need some driver changes to read from secure memory
> by enable CONFIG_MESON_SM and get the mac address to be set in ethernet
> driver.
> > On Odroid C1+
> > # hexdump
> > /sys/devices/platform/soc/da000000.secbus/da000000.nvmem/meson8b-efuse0/nvmem
> > 0000000 1143 0000 4b48 3143 3131 3232 3346 4537
> > 0000010 3942 4432 0000 0000 0000 0000 0000 0000
> > 0000020 0000 0000 0000 0000 0000 0000 0000 0000
> > *
> > 00001b0 0000 0000 1e00 1006 addc 0000 0000 0000 *00:1e:06:10:dc:ad*
> > mac address from nvmem
> > 00001c0 0000 0000 0000 4b48 3143 3133 3631 3131
> > 00001d0 3732 3130 6237 6537 3165 6437 3034 3764
> > 00001e0 02ad ec24 ff7f acfb d692 5300 0047 0000
> > 00001f0 0000 0000 0000 aff6 a000 0000 1400 c100
> > 0000200
> >
> arch/arm/boot/dts/meson8b.dtsi
> @@ -360,6 +360,18 @@
> compatible = "amlogic,meson8b-efuse";
> clocks = <&clkc CLKID_EFUSE>;
> clock-names = "core";
> +
> + board_sn: board-sn@0000000 {
> + reg = <0x0000000 0x10>;
> + };
> +
> + eth_mac: eth-mac@00001b4 {
> + reg = <0x00001b4 0x6>;
> + };
> +
> + board_sno: board-sno@00001c0 {
> + reg = <0x00001c0 0x30>;
> + };
>
> This is what I am looking into.
> If you have some input please share.
your findings are looking good to me!
I believe that some of the offsets are specific to the Odroid-C1.
this is what the Endless Mini EC-100's kernel uses: [0] (eth_mac
matches, but it seems that the other two don't)
Regards
Martin
[0]
https://github.com/endlessm/linux-meson/blob/9969d20dc0f034e7a5addd4f6d28a8193e956b16/drivers/amlogic/efuse/efuse_version.c#L519
