Serial Mux Mode in NPCM

Eugene.Cho at dell.com Eugene.Cho at dell.com
Thu Feb 15 04:29:21 AEDT 2018


Hey Jeremy and Joel, 

>Code to handle this would not be suitable as a UART driver; it handles more than a simple UART "endpoint", so we'd need something distinct from >the existing tty device here. Perhaps a separate SoC driver?

  Okay good to know. Yea unsure what to do here. I know yall wanted to get rid of the aspeed.c board file, but is the goal the get rid of that file completely or just the platform specific (barreleye, witherspoon,etc..) setup that is being done in it. Would a npcm board file be appropriate for something like this which is SoC specific and general uninteresting for the general linux population?

> However, you may not need dynamic reconfiguration of the UART routing, depending on what configurations are available and your requirements. -> If there's a routing configuration that feeds the necessary UARTs (host-side and external ports) to the BMC CPU, then obmc-console-server can handle all the routing in userspace, and you set that HW routing configuration once on boot. This is what we currently do for phosphor platforms.

Here’s my attempt at drawing this out. Hopefully the formatting doesn’t get butchered...

We support "Host SP1" and "Host SP2" both being used at the same time, depending on what the customer setting are (i.e. SOL on Host Serial Port 2 while also doing  Host Serial Port 1 -> physical port, etc.. ). Usually the BMC is only really interested in 1 of the "Host SP", while the other is used as regular Host Serial ->physical port.  But there are cases where BMC can also take over the physical port...

So for us to do 1 configuration on bootup it would mean the mux would have to look something like this: 

	[Host SP1]	[Host SP2]
		\		\_______[BMC UART 2]
		 -----------------------------------[BMC UART 1]
			_______________[BMC UART 3]
			/
	<< Physical port/ Serial Interface 2  >>

So while I agree it can be done. It seems a bit overkill for Host Serial -> physical port (since the BMC has no vested interest in it). I'm not sure what the implications are for: host serial throughput, added BMC overhead,  loss of host serial HW flow control, reliance on operational BMC for Host COM1/2-> physical port, etc. Given that the NPCM supports muxing/routing - shouldn’t we use it?


More information about the openbmc mailing list