* CPM2 uart early console
@ 2004-10-21 21:57 Rune Torgersen
2004-10-22 20:10 ` Tom Rini
0 siblings, 1 reply; 6+ messages in thread
From: Rune Torgersen @ 2004-10-21 21:57 UTC (permalink / raw)
To: Linuxppc-embedded
Is there any way of getting an early console output on a kernel on an
8260? (running u-boot as bootloader)
Right now, I don't get any console output until after the full driver is
loaded, and that is way too late, since the kernel is hanging on the PCI
init right now, and the kernel log buffer doesn't have the backtrace of
the Oops.
BTW..
What are the device node numbers for ttyCPM[0..5] ?
Rune Torgersen
System Developer
Innovative Systems LLC
1000 Innovative Drive
Mitchell, SD 57301
Ph: 605-995-6120
www.innovsys.com
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: CPM2 uart early console
2004-10-21 21:57 CPM2 uart early console Rune Torgersen
@ 2004-10-22 20:10 ` Tom Rini
0 siblings, 0 replies; 6+ messages in thread
From: Tom Rini @ 2004-10-22 20:10 UTC (permalink / raw)
To: Rune Torgersen; +Cc: Linuxppc-embedded
On Thu, Oct 21, 2004 at 04:57:56PM -0500, Rune Torgersen wrote:
> Is there any way of getting an early console output on a kernel on an
> 8260? (running u-boot as bootloader)
Yes, A mini-driver to hook into ppc_md.progress would be one method.
Another would be to do what's needed (I don't know off-hand what, sorry)
so that you can register the console much earlier, like the
early_printk.c stuff (see arch/x86_64/kernel/early_printk.c) does.
> BTW..
> What are the device node numbers for ttyCPM[0..5] ?
204 42...45 (devices.txt in linuxppc-2.5, Pantelis ever figure out what
to do about the device # conflict with the i.MX driver so we can push
that small bit upstream ?)
--
Tom Rini
http://gate.crashing.org/~trini/
^ permalink raw reply [flat|nested] 6+ messages in thread
* RE: CPM2 uart early console
@ 2004-10-22 22:01 Rune Torgersen
2004-10-26 14:35 ` Tom Rini
0 siblings, 1 reply; 6+ messages in thread
From: Rune Torgersen @ 2004-10-22 22:01 UTC (permalink / raw)
To: Linuxppc-embedded
> From: Tom Rini [mailto:trini@kernel.crashing.org]=20
> On Thu, Oct 21, 2004 at 04:57:56PM -0500, Rune Torgersen wrote:
> > BTW..
> > What are the device node numbers for ttyCPM[0..5] ?
>=20
> 204 42...45 (devices.txt in linuxppc-2.5, Pantelis ever=20
> figure out what to do about the device # conflict with the=20
> i.MX driver so we can push that small bit upstream ?)
Aparently not that simple.... I looked in the source, and it depends if=20
an 8250 stype serial port is defined or not...
#ifndef CONFIG_SERIAL_8250
#define SERIAL_CPM_MAJOR TTY_MAJOR
#define SERIAL_CPM_MINOR 64
#else
#define SERIAL_CPM_MAJOR 204
#define SERIAL_CPM_MINOR 42
#endif
Urgh...
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: CPM2 uart early console
2004-10-22 22:01 Rune Torgersen
@ 2004-10-26 14:35 ` Tom Rini
2004-10-27 6:02 ` Pantelis Antoniou
0 siblings, 1 reply; 6+ messages in thread
From: Tom Rini @ 2004-10-26 14:35 UTC (permalink / raw)
To: Rune Torgersen; +Cc: Linuxppc-embedded
On Fri, Oct 22, 2004 at 05:01:54PM -0500, Rune Torgersen wrote:
> > From: Tom Rini [mailto:trini@kernel.crashing.org]
> > On Thu, Oct 21, 2004 at 04:57:56PM -0500, Rune Torgersen wrote:
> > > BTW..
> > > What are the device node numbers for ttyCPM[0..5] ?
> >
> > 204 42...45 (devices.txt in linuxppc-2.5, Pantelis ever
> > figure out what to do about the device # conflict with the
> > i.MX driver so we can push that small bit upstream ?)
>
> Aparently not that simple.... I looked in the source, and it depends if
> an 8250 stype serial port is defined or not...
>
> #ifndef CONFIG_SERIAL_8250
> #define SERIAL_CPM_MAJOR TTY_MAJOR
> #define SERIAL_CPM_MINOR 64
> #else
> #define SERIAL_CPM_MAJOR 204
> #define SERIAL_CPM_MINOR 42
> #endif
>
> Urgh...
That doesn't make sense. Pantelis?
--
Tom Rini
http://gate.crashing.org/~trini/
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: CPM2 uart early console
2004-10-26 14:35 ` Tom Rini
@ 2004-10-27 6:02 ` Pantelis Antoniou
2004-10-27 16:39 ` Tom Rini
0 siblings, 1 reply; 6+ messages in thread
From: Pantelis Antoniou @ 2004-10-27 6:02 UTC (permalink / raw)
To: Tom Rini; +Cc: Linuxppc-embedded
Tom Rini wrote:
>On Fri, Oct 22, 2004 at 05:01:54PM -0500, Rune Torgersen wrote:
>
>>>From: Tom Rini [mailto:trini@kernel.crashing.org]
>>>On Thu, Oct 21, 2004 at 04:57:56PM -0500, Rune Torgersen wrote:
>>>
>>>>BTW..
>>>>What are the device node numbers for ttyCPM[0..5] ?
>>>>
>>>204 42...45 (devices.txt in linuxppc-2.5, Pantelis ever
>>>figure out what to do about the device # conflict with the
>>>i.MX driver so we can push that small bit upstream ?)
>>>
>>Aparently not that simple.... I looked in the source, and it depends if
>>an 8250 stype serial port is defined or not...
>>
>>#ifndef CONFIG_SERIAL_8250
>>#define SERIAL_CPM_MAJOR TTY_MAJOR
>>#define SERIAL_CPM_MINOR 64
>>#else
>>#define SERIAL_CPM_MAJOR 204
>>#define SERIAL_CPM_MINOR 42
>>#endif
>>
>>Urgh...
>>
>
>That doesn't make sense. Pantelis?
>
>
Well, it sure doesn't.
We should really try to find a generic solution to this
problem, i.e. that SoC like processors almost always have a number of serial
ports, and every single one ends up being of a different major/minor number.
IMHO the best solution would be to allocate a single major number, and
then map to the minors in order, the possible serial ports.
We could do this easily for PPC at first, and try to pursuade the other
embedded people to convert. The old device names can always be supported
via simple symbolic links.
For example let's take the 8xx family.
It is possible to have a maximum of 6 on chip serial ports; SCC1-4 + SMC1-2.
The devices could be
crw------- 1 root root 0, 64 Mar 24 2004 ttyC0 # SCC1
crw------- 1 root root 1, 64 Mar 24 2004 ttyC1 # SCC2
crw------- 1 root root 2, 64 Mar 24 2004 ttyC2 # SCC3
crw------- 1 root root 3, 64 Mar 24 2004 ttyC3 # SCC4
crw------- 1 root root 4, 64 Mar 24 2004 ttyC4 # SMC1
crw------- 1 root root 5, 64 Mar 24 2004 ttyC5 # SMC2
The compatibility link for a single SMC1 console.
lrwxrwxrwx 1 root root 5 Oct 25 16:56 ttyS0 -> ttyC4
In a similar manner we could do the same to 82xx, and every other
SoC in existance.
So what do you think?
Regards
Pantelis
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: CPM2 uart early console
2004-10-27 6:02 ` Pantelis Antoniou
@ 2004-10-27 16:39 ` Tom Rini
0 siblings, 0 replies; 6+ messages in thread
From: Tom Rini @ 2004-10-27 16:39 UTC (permalink / raw)
To: Pantelis Antoniou; +Cc: Linuxppc-embedded
On Wed, Oct 27, 2004 at 09:02:19AM +0300, Pantelis Antoniou wrote:
> Tom Rini wrote:
>
> >On Fri, Oct 22, 2004 at 05:01:54PM -0500, Rune Torgersen wrote:
> >
> >>>From: Tom Rini [mailto:trini@kernel.crashing.org]
> >>>On Thu, Oct 21, 2004 at 04:57:56PM -0500, Rune Torgersen wrote:
> >>>
> >>>>BTW..
> >>>>What are the device node numbers for ttyCPM[0..5] ?
> >>>>
> >>>204 42...45 (devices.txt in linuxppc-2.5, Pantelis ever
> >>>figure out what to do about the device # conflict with the
> >>>i.MX driver so we can push that small bit upstream ?)
> >>>
> >>Aparently not that simple.... I looked in the source, and it depends if
> >>an 8250 stype serial port is defined or not...
> >>
> >>#ifndef CONFIG_SERIAL_8250
> >>#define SERIAL_CPM_MAJOR TTY_MAJOR
> >>#define SERIAL_CPM_MINOR 64
> >>#else
> >>#define SERIAL_CPM_MAJOR 204
> >>#define SERIAL_CPM_MINOR 42
> >>#endif
> >>
> >>Urgh...
> >>
> >
> >That doesn't make sense. Pantelis?
> >
> >
> Well, it sure doesn't.
>
> We should really try to find a generic solution to this
> problem, i.e. that SoC like processors almost always have a number of serial
> ports, and every single one ends up being of a different major/minor number.
I disagree, at least in the sense that this needs to involve the kernel.
What Rune found is a real bug, in that sometimes we steal the
major/minors of ttyS, and sometimes we don't. What we need to do is to
always use our own major/minor.
> IMHO the best solution would be to allocate a single major number, and
> then map to the minors in order, the possible serial ports.
This isn't neccessary. One could handle this rather trivially with udev
so that /dev/ttyC[0-N], to use your names are just symlinks to ttyCPM0,
ttyCPM1, ttyS0, ttyS1, and so on.
--
Tom Rini
http://gate.crashing.org/~trini/
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2004-10-27 16:39 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2004-10-21 21:57 CPM2 uart early console Rune Torgersen
2004-10-22 20:10 ` Tom Rini
-- strict thread matches above, loose matches on Subject: below --
2004-10-22 22:01 Rune Torgersen
2004-10-26 14:35 ` Tom Rini
2004-10-27 6:02 ` Pantelis Antoniou
2004-10-27 16:39 ` Tom Rini
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).