SH-Sci(f) driver as console
I'm having problems with the sh-sci driver as a console.
The early printk code works for my board; I added the register definitions into the sh-sci.h file.
However, When it comes to register_console for the ttySC - at that point, the uart's havent been registered, so the console doesn't attach, failing at the line :
static int __init serial_console_setup(struct console *co, char *options)
{
.
.
.
/*
* Also need to check port->type, we don't actually have any
* UPIO_PORT ports, but uart_report_port() handily misreports
* it anyways if we don't have a port available by the time this is
* called.
*/
if (!port->type)
return -ENODEV;
.
.
.
}
only later does uart_register_driver get called when static int __initsci_init(void) runs.
Do I need to change something to make the call to sci_init occur earlier in the kernel ? or should I just call register console again later on perhaps?
Cheers
Signature · 1 line
Kieran Bingham <[email protected]>
Quoted 31 lines · Kieran Bingham
I'm having problems with the sh-sci driver as a console.
The early printk code works for my board; I added the register definitions into the
sh-sci.hfile.However, When it comes to
register_consolefor the ttySC - at that point, the uart's havent been registered, so the console doesn't attach, failing at the line :static int
__initserial_console_setup(struct console *co, char *options)
{
.
.
.
/*
* Also need to checkport->type, we don't actually have any
*UPIO_PORTports, butuart_report_port()handily misreports
* it anyways if we don't have a port available by the time this is
* called.
*/if (!port->type)
return -ENODEV;.
.
.
}
Quoted 7 lines
only later does
uart_register_driverget called when static int__initsci_init(void)runs.Do I need to change something to make the call to
sci_initoccur earlier in the kernel ? or should I just call register console again later on perhaps?
The uart and console driver are fairly orthogonal. While the port defs overlap, one does not intrinsically depend on the other.
early_sci_setup() is provided for the cases where we want to set the port up early, but should probably be adjusted for a different pointer type. Perhaps the easiest thing to do is to take the early printk uart info and pass that in to early_sci_setup(), since we know we'll at least have something we can use early there.
Quoted 5 lines · Paul Mundt
early_sci_setup()is provided for the cases where we want to set the port up early, but should probably be adjusted for a different pointer type. Perhaps the easiest thing to do is to take the early printk uart info and pass that in toearly_sci_setup(), since we know we'll at least have something we can use early there.
And to elaborate on this, the idea was taken from 8250. Look at early_serial_setup() and setup_early_serial8250_console() for more information and ideas.
Urgh ... my head hurts from following this ENXIO error all the way through sys_open, through VFS / VT / TTY and down to Uart :P
I think I went the long way round :( silly me !
I added
early_sci_setup( &scif_port );
to the end of setup_early_printk(..);
This created the serial console that let it write out as a console printk buffer, but when it comes to sys_open(ing) /dev/console, its returning with -ENXIO from uart_get in serial_core.c
state->count++;
if (!state->port || state->port->flags & UPF_DEAD) {
DPRINTK("state->port = %x : state->port->flags = 0x%x\n",
state->port, state->port->flags);
ret = -ENXIO;
goto err_unlock;
}state->port comes out as 0.
Where is this supposed to be set up ? Is this because I've set my uart port up too early, and something has missed it ? or am I just missing something more fundamental ?
--
Cheers
KB
Quoted 48 lines · Paul Mundt
Quoted 31 lines · Kieran Bingham
I'm having problems with the sh-sci driver as a console.
The early printk code works for my board; I added the register definitions into the
sh-sci.hfile.However, When it comes to
register_consolefor the ttySC - at that point, the uart's havent been registered, so the console doesn't attach, failing at the line :static int
__initserial_console_setup(struct console *co, char *options)
{
.
.
.
/*
* Also need to checkport->type, we don't actually have any
*UPIO_PORTports, butuart_report_port()handily misreports
* it anyways if we don't have a port available by the time this is
* called.
*/if (!port->type)
return -ENODEV;.
.
.
}Quoted 7 lines
only later does
uart_register_driverget called when static int__initsci_init(void)runs.Do I need to change something to make the call to
sci_initoccur earlier in the kernel ? or should I just call register console again later on perhaps?The uart and console driver are fairly orthogonal. While the port defs overlap, one does not intrinsically depend on the other.
early_sci_setup()is provided for the cases where we want to set the port up early, but should probably be adjusted for a different pointer type. Perhaps the easiest thing to do is to take the early printk uart info and pass that in toearly_sci_setup(), since we know we'll at least have something we can use early there.
Quoted 5 lines · Kieran Bingham
Urgh ... my head hurts from following this ENXIO error all the way through
sys_open, through VFS / VT / TTY and down to Uart :PI think I went the long way round :( silly me !
Er, what? If you're getting in to userspace, you don't need to bother with an early_sci_setup(). This is the regular case, which works for every other CPU and board, suggesting that there's either something amiss in the CPU setup, or your .config.
Quoted 3 lines
Where is this supposed to be set up ? Is this because I've set my uart port up too early, and something has missed it ? or am I just missing something more fundamental ?
The early setup is just to allow you to bang some bytes down the line early incase you happen to blow up before you get that far. Usually the early printk suffices for this, so there's no need in general to hand the port def off to early_sci_setup().
If you're doing all of this to work around the fact you can't open /dev/console, you've been chasing the wrong problem :-)