Hi Marek,
On Mon, Nov 5, 2012 at 6:47 PM, Marek Vasut marex@denx.de wrote:
Dear Joe Hershberger,
Hi Marek.
On Mon, Nov 5, 2012 at 5:10 PM, Marek Vasut marex@denx.de wrote:
Dear Joe Hershberger,
Hi Marek,
On Fri, Nov 2, 2012 at 8:37 PM, Marek Vasut marex@denx.de wrote:
Dear Joe Hershberger,
This allows the default console to be specified as the nulldev. This is specifically helpful when the real serial console's init() cannot run early in the boot process. When the init can be run, then the console can be switched to the real device using the std* env vars.
Signed-off-by: Joe Hershberger joe.hershberger@ni.com
Isn't it actually better to have null stdio device? Some systems might not even use serial port (and so null serial will be useless on these systems)!
As I described in my commit log, this is for the case where the serial and console init must not touch the hardware, (since it doesn't exist yet if it's in an FPGA or on a PCI or USB connection). Making the default serial port be the nulldev avoids this issue.
So add nulldev serial device for this stupid case. Even though fixing iomux such that it'd not send anything to serial port at all if nulldev is selected would be even better idea.
It's not a problem of something being sent to the serial port. It's the call to serial_init() in arch/*/lib/board.c that kills it. That call needs to be no-op-able.
Why?
What about fixing serial_init like this:
struct serial_device *dev = get_current(); int ret = 0; if (dev) ret = dev->start();
return ret;
How does this help? Are you suggesting that default_serial_console() return "NULL"? It seems that you would then have to add a ton of checks for NULL coming back from default_serial_console() all the places that just use it assuming it's actually a device pointer. Sounds ugly. If you aren't talking about having default_serial_console() return NULL, then I don't see how this helps.
-Joe