Re: [coreboot] alix.2c3 stops at mainboard_pre_payload: done

[Roman Yeryomin]

On Sun, Oct 12, 2008 at 3:16 AM, Roman Yeryomin  wrote:
> On Sat, Oct 11, 2008 at 8:33 PM, ron minnich  wrote:
> > > while trying to resolve this problem I've noticed following:
> > >
> > > on system with native bios (tinybios):
> > > cat /proc/tty/driver/serial
> > > serinfo:1.0 driver revision:
> > > 0: uart:16550A port:000003F8 irq:4 tx:945 rx:15 RTS|CTS|DTR|DSR|CD
> > > 1: uart:16550A port:000002F8 irq:3 tx:0 rx:0 CTS|DSR|CD
> > >
> > > but on system with coreboot:
> > > cat /proc/tty/driver/serial
> > > serinfo:1.0 driver revision:
> > > 0: uart:NS16550A port:000003F8 irq:4 tx:0 rx:0 RTS|DTR
> > > 1: uart:unknown port:000002F8 irq:3
> >
> > OK, this is kind of the problem I remember. If you have time go into
> > the kernel, IIRC, there is a test for some modem signal and the device
> > is not available otherwise. I am sorry to be so fuzzy but this was
> > seven years ago. It was a weird problem.
>
> you think this is kernel problem?
> > It seems whatever you have on that port is not asserting DTR, which is
> > also odd. Is there a loopback control in this part that routes DSR
> > back to DTR?
>
> Well, according to datasheet there is loopback control in cs5536 uart,
> but I don't think the problem is there.
> I've asked Pascal Dornier (pcengines) how he sets up uart in his bios
> but didn't receive an answer yet.
> I still think the problem is in coreboot (or libpayload)...

Pascal answered me:

After init -> changes to Linux driver, or does it still use Int 10 + Int 16 ?
My BIOS does a redirect of these BIOS interrupts to the serial console.

Roman

alix.2c3 stops at mainboard_pre_payload: done

[Peter Stuge]

Hi Roman,

Roman Yeryomin wrote:
> > > > on system with native bios (tinybios):
> > > > cat /proc/tty/driver/serial
> > > > serinfo:1.0 driver revision:
> > > > 0: uart:16550A port:000003F8 irq:4 tx:945 rx:15 RTS|CTS|DTR|DSR|CD
> > > > 1: uart:16550A port:000002F8 irq:3 tx:0 rx:0 CTS|DSR|CD
> > > >
> > > > but on system with coreboot:
> > > > cat /proc/tty/driver/serial
> > > > serinfo:1.0 driver revision:
> > > > 0: uart:NS16550A port:000003F8 irq:4 tx:0 rx:0 RTS|DTR
> > > > 1: uart:unknown port:000002F8 irq:3

Did I overlook this message on the the list? If it wasn't sent to the
list, please keep in mind that it's nicer both for you and for others
after you to keep discussion on the list, for you because you may get
quicker replies and for others because the solutions are archived.

What I find most interesting about the output above is how uart 1 is
identified differently when starting with coreboot. It would be good
to find out why.
> > > OK, this is kind of the problem I remember. If you have time go into
> > > the kernel, IIRC, there is a test for some modem signal and the device
> > > is not available otherwise. I am sorry to be so fuzzy but this was
> > > seven years ago. It was a weird problem.
> >
> > you think this is kernel problem?

I don't think serial control signals is the source of your problems.
Even if they are, the problem is not in the kernel but in the
application. Unless your kernel has a bad bug in the UART layer it
will not withhold data based on control signals.

It is much more likely that the hardware is not configured correctly.
> > > It seems whatever you have on that port is not asserting DTR,
> > > which is also odd.

Please comment on this. What do you have connected to the serial
port? Does DTR on the Geode go high when your terminal software is
running?
> > I've asked Pascal Dornier (pcengines) how he sets up uart in his
> > bios but didn't receive an answer yet.

Please don't ever bother Pascal Dornier with coreboot issues. That is
what this mailing list and the #coreboot IRC channel is meant for.
> > I still think the problem is in coreboot (or libpayload)...
>
> Pascal answered me:
>
> After init -> changes to Linux driver, or does it still use Int 10
> Int 16 ?
>
> My BIOS does a redirect of these BIOS interrupts to the serial
> console.

You can safely assume that no Linux kernel driver requires real mode
interrupts. This is an almost universal truth.

In particular: no, the Linux serial driver does not use BIOS
interrupt services.

//Peter

alix.2c3 stops at mainboard_pre_payload: done

[Roman Yeryomin]

On Monday 13 October 2008 03:01:35 Peter Stuge wrote:
> Hi Roman,
>
> Roman Yeryomin wrote:
> > > > > on system with native bios (tinybios):
> > > > > cat /proc/tty/driver/serial
> > > > > serinfo:1.0 driver revision:
> > > > > 0: uart:16550A port:000003F8 irq:4 tx:945 rx:15 RTS|CTS|DTR|DSR|CD
> > > > > 1: uart:16550A port:000002F8 irq:3 tx:0 rx:0 CTS|DSR|CD
> > > > >
> > > > > but on system with coreboot:
> > > > > cat /proc/tty/driver/serial
> > > > > serinfo:1.0 driver revision:
> > > > > 0: uart:NS16550A port:000003F8 irq:4 tx:0 rx:0 RTS|DTR
> > > > > 1: uart:unknown port:000002F8 irq:3
>
> Did I overlook this message on the the list? If it wasn't sent to the
> list, please keep in mind that it's nicer both for you and for others
> after you to keep discussion on the list, for you because you may get
> quicker replies and for others because the solutions are archived.

I understand...
didn't look at the TO: address when sending email
> What I find most interesting about the output above is how uart 1 is
> identified differently when starting with coreboot. It would be good
> to find out why.

yes, that's the main question I think
> > > > OK, this is kind of the problem I remember. If you have time go into
> > > > the kernel, IIRC, there is a test for some modem signal and the device
> > > > is not available otherwise. I am sorry to be so fuzzy but this was
> > > > seven years ago. It was a weird problem.
> > >
> > > you think this is kernel problem?
>
> I don't think serial control signals is the source of your problems.
> Even if they are, the problem is not in the kernel but in the
> application. Unless your kernel has a bad bug in the UART layer it
> will not withhold data based on control signals.
>
> It is much more likely that the hardware is not configured correctly.

agree
> > > > It seems whatever you have on that port is not asserting DTR,
> > > > which is also odd.
>
> Please comment on this. What do you have connected to the serial
> port?

I'm trying to get serial console on it -- I connect to alix from my desktop 
with null modem cable
> Does DTR on the Geode go high when your terminal software is 
> running?

m?
> > > I've asked Pascal Dornier (pcengines) how he sets up uart in his
> > > bios but didn't receive an answer yet.
>
> Please don't ever bother Pascal Dornier with coreboot issues. That is
> what this mailing list and the #coreboot IRC channel is meant for.

I just asked how he sets up uart in his tinyBIOS, that's it. I think this is 
normal question to hw manufacturer.
> > > I still think the problem is in coreboot (or libpayload)...
> >
> > Pascal answered me:
> >
> > After init -> changes to Linux driver, or does it still use Int 10
> > Int 16 ?
> >
> > My BIOS does a redirect of these BIOS interrupts to the serial
> > console.
>
> You can safely assume that no Linux kernel driver requires real mode
> interrupts. This is an almost universal truth.
>
> In particular: no, the Linux serial driver does not use BIOS
> interrupt services.

maybe coreboot could try to use similar behavior? just to see what it gives?

Roman

alix.2c3 stops at mainboard_pre_payload: done

[Roman Yeryomin]

On Mon, Oct 13, 2008 at 11:27 AM, Roman Yeryomin  wrote:
> > > > > > on system with native bios (tinybios):
> > > > > > cat /proc/tty/driver/serial
> > > > > > serinfo:1.0 driver revision:
> > > > > > 0: uart:16550A port:000003F8 irq:4 tx:945 rx:15 RTS|CTS|DTR|DSR|CD
> > > > > > 1: uart:16550A port:000002F8 irq:3 tx:0 rx:0 CTS|DSR|CD
> > > > > >
> > > > > > but on system with coreboot:
> > > > > > cat /proc/tty/driver/serial
> > > > > > serinfo:1.0 driver revision:
> > > > > > 0: uart:NS16550A port:000003F8 irq:4 tx:0 rx:0 RTS|DTR
> > > > > > 1: uart:unknown port:000002F8 irq:3
> >
> > What I find most interesting about the output above is how uart 1 is
> > identified differently when starting with coreboot. It would be good
> > to find out why.
>
> yes, that's the main question I think
> > > > > It seems whatever you have on that port is not asserting DTR,
> > > > > which is also odd.
> >
> > Please comment on this. What do you have connected to the serial
> > port?
>
> I'm trying to get serial console on it -- I connect to alix from my desktop
> with null modem cable
> > Does DTR on the Geode go high when your terminal software is
> > running?
>
> m?

Sorry, didn't really understand what you mean here.
> > > After init -> changes to Linux driver, or does it still use Int 10
> > > Int 16 ?
> > >
> > > My BIOS does a redirect of these BIOS interrupts to the serial
> > > console.
> >
> > You can safely assume that no Linux kernel driver requires real mode
> > interrupts. This is an almost universal truth.
> >
> > In particular: no, the Linux serial driver does not use BIOS
> > interrupt services.
>
> maybe coreboot could try to use similar behavior? just to see what it gives?

So... any ideas what we can do with it?

Roman