Skip to contentSkip to conversation

SH-Sci(f) driver as console

DISCUSSION Kieran Bingham 2 participants 5 messages Jan 31, 2008 SuperH

lore
Share & tools
lore
#0 lore raw

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 __init
sci_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]>
#1 lore raw
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.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;

.
.
.
}

Quoted 7 lines

only later does uart_register_driver get called when static int __init
sci_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?

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.

#2 lore raw
In reply to Kieran Bingham
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 to early_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.

#3 lore raw
In reply to 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 :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.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;

.
.
.
}

Quoted 7 lines

only later does uart_register_driver get called when static int __init
sci_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?

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.

#4 lore raw
In reply to Kieran Bingham
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 :P

I 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 :-)