Hi Sharma,

On Mon, 29 Jul 2013 15:33:39 +0000, Sharma Bhupesh-B45370 B45370@freescale.com wrote:

Hi List,

I am trying to add support of a Vitesse L2 switch in u-boot (in unmanaged configuration). I was analyzing whether advanced features like flow control, link-aggregation etc are required to be supported for a L2 switch working in a u-boot bootloader level.

My point-of-view is that the L2 switch, should support only bare-minimum tftp of images, ping to other ethernet entities, bootp .. type of commands on u-boot and as such the L2 switch u-boot driver doesn't need to address flow-control and other such advanced features (probably of interest for a Linux device driver).

But, I am not sure about the design approaches used to support previous switch modules in u-boot.

Also I had a query whether there is a common switch framework in-place/under-consideration in u-boot, similar to what is already present in OpenWrt code: https://dev.openwrt.org/browser/trunk/package/boot/uboot-lantiq/patches/0019...

Would porting this to u-boot make sense to have a common framework for ethernet switch in-place?

Can you please let me know your views on the same and point me to any reference switch drivers that support these features.

There is some support for switches in U-Boot (e.g. mv88e61xx) but no framework that I know of; and I suspect what is expected from the switch in U-Boot is that it does not hamper Ethernet operations, nothing more. for mv88e61xx, this is done through a fixed configuration.

Regards, Bhupesh

Amicalement,

Dear Bhupesh,

In message A1A6EA40F8503D48BB002B42BD65974E0A0C9275@039-SN2MPN1-012.039d.mgd.msft.net you wrote:

I am trying to add support of a Vitesse L2 switch in u-boot (in unmanaged configuration). I was analyzing whether advanced features like flow control, link-aggregation etc are required to be supported for a L2 switch working in a u-boot bootloader level.

...

But, I am not sure about the design approaches used to support previous switch modules in u-boot.

Things depend _heavily_ on your specific project requiremnts. IF all you need is a working network port then you can probably do with just the default initialization, determined by the pin strapping (i. e. your hardware guys should just to The Right Thing (TM) ).

However, if you run a device in a security sensitive environment, it may be strictly forbidden to run the switch even for very short periods in some "open" configuration that would - for example - allow access from the "outside" to some (normally) protected inner networks.

There is at least one board configuration in mainline which performs a full switch initialization in a time-optimized manner (by just down- loading a register dump to the switch); see enbw_cmc_config_switch() in board/enbw/enbw_cmc/enbw_cmc.c

Normally, you should probably leave the switch just turned off / disabled and wait until proper application code in Linux can perform the needed initalizations.

Best regards,

Wolfgang Denk