[PATCH] board: sl28: add DSA support for variant 2

Michael Walle michael at walle.cc
Wed Feb 17 00:29:33 CET 2021


Am 2021-02-16 23:53, schrieb Vladimir Oltean:
> On Tue, Feb 16, 2021 at 11:25:25PM +0100, Michael Walle wrote:
>> Now that u-boot gained DSA support, and it is already enabled for the
>> kontron_sl28 board, add the last missing piece and enable the
>> corresponding devices it in the device tree.
>> 
>> Signed-off-by: Michael Walle <michael at walle.cc>
>> ---
>>  .../arm/dts/fsl-ls1028a-kontron-sl28-var2.dts | 46 
>> +++++++++++++++++++
>>  1 file changed, 46 insertions(+)
>> 
>> diff --git a/arch/arm/dts/fsl-ls1028a-kontron-sl28-var2.dts 
>> b/arch/arm/dts/fsl-ls1028a-kontron-sl28-var2.dts
>> index 1ea1265bcf..39280cd1c7 100644
>> --- a/arch/arm/dts/fsl-ls1028a-kontron-sl28-var2.dts
>> +++ b/arch/arm/dts/fsl-ls1028a-kontron-sl28-var2.dts
>> @@ -15,6 +15,12 @@
>>  / {
>>  	model = "Kontron SMARC-sAL28 (TSN-on-module)";
>>  	compatible = "kontron,sl28-var2", "kontron,sl28", "fsl,ls1028a";
>> +
>> +	aliases {
>> +		eth0 = &mscc_felix_port0;
>> +		eth1 = &mscc_felix_port1;
>> +		eth2 = &enetc2;
> 
> The way DSA is intended to be used is that the alias for the DSA master
> (host port) comes first, then the alias for switch ports.
> 
> The reasoning is that U-Boot has MAC address inheritance rules. If
> ethNaddr (where N is the sequence id of the Ethernet udevice
> corresponding to a switch port) is not defined in the env, then the MAC
> address is inherited from the master interface.
> 
> But the address cannot be inherited unless the master has already been
> probed. So it must be probed first, so it needs to have a lower 
> numbered
> alias.

Hm. I reordered the aliases because ethaddr should be the MAC
address for the first port and eth1addr the one for the second
port.

Every board has a pool of MAC addresses and the vendor version of
u-boot will populate the environment accoring to the pool. I.e.
there will be ethaddr, eth1addr, .. ethNaddr. This is still missing
in the vanilla bootloader (no EEPROM decode and no access to the
SPI OTP area yet). So for now, the user will have to supply the
ethNaddr variables.

So it should be OK in principle. But if - for some reason - there
is only one ethaddr, it won't work, right?

Unfortunately, I don't see a way to make both work:
  (1) the first port should have ethaddr and the second ethaddr
  (2) it should work with just one ethaddr

-michael


More information about the U-Boot mailing list