[LinuxBIOS] Support for IEI Nova4899R [1]

[Luis Correia]

Hi,

i'm currently trying to build a linuxbios ROM for this
embedded board and there are some questions that need
some answers.

This board uses the following components:

Geode GX1 300Mhz
Geode cs5530
SuperIO Winbond w83977f
sensor chip Winbond w83782
3 * realtek rtl8100 ethernet chips
1 ICP HA6629, presumably an hw watchdog and digital io chip
ac97 sound chip AD1881
a PCI slot

as for the connection, it also provides:
two serial ports
one irda pin header
the vga output
one floppy
one paralell port
one standard IDE
one laptop style 44 pin IDE
onboard compactflash socket
one socket for DoM module

The reason behind the need for linuxbios is that the original
bios does not have any good method for IRQ sharing, and it simply
freezes when eth0 is up and some device on the PCI bus is also up.

Which means that the IRQ sharing is not happening at all...
(unless i'm talking rubbish...)

I have managed to build a rom for it, using the eaglelion as a base
setup, but modifying the superio chip and the PCI device assignments.

And for my surprise, it worked right from the start with some minor
tweaking to the FILO 0.5 commandline parameters.

Since i didn't load any VGA bios i'm stuck with serial console only.

---

now for my questions:

a) can the VGA rom be loaded as some sort of payload, and thus be
automatically added during the build process, or the described
procedure here http://www.linuxbios.org/VGA_support is still
the best way ?

b) is there any way to tell where the IRQ pins for each PCI device
are connected to the IRQ router chip?

c) i built an irq_tables.c using getpir, but it didn't actually
helped much, as now i've got fewer devices working compared with
the original bios :) (which i'm not that surprised at all)
is getpir still the best method of detecting the original configuration?

d) any other input you might give for help is welcome

p.s. i apologise in advance for any blunt mistakes or typo's i may have
wrote, as English is not my native language, i'm Portuguese btw. ;)

Luis Correia

[ron minnich]

On 11/4/06, Luis Correia  wrote:
> now for my questions:
>
> a) can the VGA rom be loaded as some sort of payload, and thus be
> automatically added during the build process, or the described
> procedure here http://www.linuxbios.org/VGA_support is still
> the best way ?

that's still the only way for now.

b) is there any way to tell where the IRQ pins for each PCI device
> are connected to the IRQ router chip?

schematics. Or a volt-ohm meter. In all too many cases, the IRQ table in the
fuctory bios is wrong. It can not be trusted.

c) i built an irq_tables.c using getpir, but it didn't actually
> helped much, as now i've got fewer devices working compared with
> the original bios :) (which i'm not that surprised at all)
> is getpir still the best method of detecting the original configuration?

I used to depend on getpir, until I found out how many bioses have the wrong
PIRQ table, and then I found that after 2.4.18 Linux is parsing the IRQ
tables incorrectly for cs5530, due to the fact that about half the GX1
tables in the world are wrong ... it is a terrible mess. So, getpir is only
as good as the tables in the fuctory bios, which nowadays means ... maybe it
will be good, but it is highly probable to have errors.

d) any other input you might give for help is welcome

nice work! how much did this board cost, and where do we get one?

Everyone, I think we can NOT delete the cs5530 support, or gx1 support in
general; we have a new motherboard!

Luis, can you do an svn diff and post a patch to the list; or use the
tracker?

thanks

ron
p.s. your english is better than most US high school students :-)

[Luis Correia]

ron minnich wrote:
> On 11/4/06, *Luis Correia* <[e-mail] 
> > wrote:
> ---
>
> now for my questions:
>
> a) can the VGA rom be loaded as some sort of payload, and thus be
> automatically added during the build process, or the described
> procedure here http://www.linuxbios.org/VGA_support is still
> the best way ?
>
>
>
> that's still the only way for now.

bummer!

I've managed to reduce the overall size of the bios and added the original
VGA bios rom. But my guess (from reading the archives) that VSA is still
not supported and such, my hopes of seeing any image on teh VGA screen are
now even more reduced...
> b) is there any way to tell where the IRQ pins for each PCI device
> are connected to the IRQ router chip?
>
>
>
> schematics. Or a volt-ohm meter. In all too many cases, the IRQ table 
> in the fuctory bios is wrong. It can not be trusted.

I don't have any schematics, but there is an ohm meter around here.
but the chips are BGA, i can't just rip them off the board to read the 
pins :)
> c) i built an irq_tables.c using getpir, but it didn't actually
> helped much, as now i've got fewer devices working compared with
> the original bios :) (which i'm not that surprised at all)
> is getpir still the best method of detecting the original
> configuration?
>
>
>
> I used to depend on getpir, until I found out how many bioses have the 
> wrong PIRQ table, and then I found that after 2.4.18 Linux is parsing 
> the IRQ tables incorrectly for cs5530, due to the fact that about half 
> the GX1 tables in the world are wrong ... it is a terrible mess. So, 
> getpir is only as good as the tables in the fuctory bios, which 
> nowadays means ... maybe it will be good, but it is highly probable to 
> have errors.

I have also managed to mess around with the PIRQ table and now linux
does not complain about devices having IRQ0 assigned. But there are 
still problems.
It locks up under some irq sharing scenarios. it might take a long
while before i get the IRQ assignments right.
> d) any other input you might give for help is welcome
>
>
>
> nice work! how much did this board cost, and where do we get one?

Thanks!

This is a surplus board, that cost me 75€.
(Manufacturer's website:
http://www.ieiworld.com/en/product_IPC.asp?model=NOVA-4899)

It's an old not RoHS compliant,
and I don't even were supposed to have it here in Europe ;) but it is
obsolete industrial equipment parts, and I got it from my friend
Martin Hoehne at www.minipci.biz . These boards are sold out now,
but it has some similar ones, also using a Geode GX1.
(http://www.ieiworld.com/en/product_IPC.asp?model=ISS-102)
> Everyone, I think we can NOT delete the cs5530 support, or gx1 support 
> in general; we have a new motherboard!
>
> Luis, can you do an svn diff and post a patch to the list; or use the 
> tracker?

Let me get this into a better shape, and i'll post a patch diff here
(let me know which is the right way to present the patch).
> thanks
>
> ron
> p.s. your english is better than most US high school students :-)

well, that is maybe because i'm 41 and try a lot not to make a fool
out of myself :) (most of the time anyway...)

Luis

[Stefan Reinauer]

* Luis Correia  [061105 02:07]:
> I've managed to reduce the overall size of the bios and added the original
> VGA bios rom. But my guess (from reading the archives) that VSA is still
> not supported and such, my hopes of seeing any image on teh VGA screen are
> now even more reduced...

VSA is supported since the OLPC.

[Luis Correia]

Stefan Reinauer wrote:
> Luis Correia  [061105 02:07]:
> > I've managed to reduce the overall size of the bios and added the original
> > VGA bios rom. But my guess (from reading the archives) that VSA is still
> > not supported and such, my hopes of seeing any image on teh VGA screen are
> > now even more reduced...
>
> VSA is supported since the OLPC.

Ok, got it.

Managed to reduce Linuxbios and filo payload sizes to fit
into 96k and prepended the VGA and VSA bios code in order
to create a 256k rom.

It still boots as before but to change was made in relation
to the VGA activation.

From the OLPC code i can't figure out how to properly
activate VSA, any hints?

p.s. flashrom works fine in this motherboard

Luis Correia

[Luis Correia]

Stefan Reinauer wrote:
> Luis Correia  [061105 02:07]:
> > I've managed to reduce the overall size of the bios and added the original
> > VGA bios rom. But my guess (from reading the archives) that VSA is still
> > not supported and such, my hopes of seeing any image on teh VGA screen are
> > now even more reduced...
>
> VSA is supported since the OLPC.

I looked into OLPC configuration options and could not figure out how
to enable VSA for my board.

The factory BIOS has a 32k Elpin systems vga rom and a 128k block with
no visible strings that seems to be just code. I'm assuming this is
the VSA code block.

I have now reduced LinuxBIOS and FILO payload footprint in order to
fit inside the remaining 96k in the BIOS.

Attached you'll see a bootlog until FILO boots. This will give an idea
of how the devices were initialized.

We can see thatthe 32k vga bios is copied to the correct place, but
nothing is done to the VSA portion, it is true that this VSA code
does not have the standard BIOS start values (0x55aa).

p.s. today i'm not complaining about IRQ's :)
p.s.2. the actual console, ie keyboard and mouse appear to be working,
at least the keyboard reacts on ctrl-alt-del.

Luis Correia

[Stefan Reinauer]

* Luis Correia  [061107 10:39]:
> We can see thatthe 32k vga bios is copied to the correct place, but
> nothing is done to the VSA portion, it is true that this VSA code
> does not have the standard BIOS start values (0x55aa).

Yes, vsa is not an option rom, hence no 55aa.

VSA needs to be called in 16bit mode, GX2 and LX do that in
northbridge.c

Check out src/cpu/amd/model_gx2/vsmsetup.c

Stefan

[Luis Correia]

Stefan Reinauer wrote:
> Luis Correia  [061107 10:39]:
> > We can see thatthe 32k vga bios is copied to the correct place, but
> > nothing is done to the VSA portion, it is true that this VSA code
> > does not have the standard BIOS start values (0x55aa).
>
> Yes, vsa is not an option rom, hence no 55aa.
>
> VSA needs to be called in 16bit mode, GX2 and LX do that in
> northbridge.c
>
> Check out src/cpu/amd/model_gx2/vsmsetup.c

This is a very tricky business!

The VSM code hooks up in lots of places. If I manage to get this
going for my GX1 board, is is possible that it would break other
configurations. And i'm not too confortable with it.

I'm still very rough regarding the creation of a proper
CONFIG_VSA option, that seems to me to be the best way to provide
VSA services to future devices.

It seems that the VSA was made to work only for the OLPC gx2 powered
mainboard.
> Stefan

I will try to do my best with it :)

Luis

[Stefan Reinauer]

* Luis Correia  [061111 00:22]:
> The VSM code hooks up in lots of places. If I manage to get this
> going for my GX1 board, is is possible that it would break other
> configurations. And i'm not too confortable with it.

If you can just give it a try.
> It seems that the VSA was made to work only for the OLPC gx2 powered
> mainboard.

Its part of the CPU specific code for the GX2, yes. The Geode LX cpu
code has support for it, too. Only Geode CPU where LinuxBIOS does not
know about VSA is the GX1.
> I will try to do my best with it :)

Good Luck.

[ron minnich]

On 11/10/06, Luis Correia  wrote:
> It seems that the VSA was made to work only for the OLPC gx2 powered

it works on several gx2 boards, not just OLPC; and it works on LX.

I don't see a reason it would not work with gx1.

ron

[Luis Correia]

ron minnich wrote:
> On 11/10/06, Luis Correia  wrote:
> > It seems that the VSA was made to work only for the OLPC gx2 powered
>
> it works on several gx2 boards, not just OLPC; and it works on LX.
>
> I don't see a reason it would not work with gx1.

In that case, can I assume that my work on VSA for the GX1 will
benefit all other GX1 based boards (if any)?
> ron

Luis

[Stefan Reinauer]

* Luis Correia  [061111 11:29]:
> ron minnich wrote:
> > it works on several gx2 boards, not just OLPC; and it works on LX.
> >
> > I don't see a reason it would not work with gx1.
>
> In that case, can I assume that my work on VSA for the GX1 will
> benefit all other GX1 based boards (if any)?

yes.

[Tom Sylla]

ron minnich wrote:
> On 11/10/06, Luis Correia  wrote:
> > It seems that the VSA was made to work only for the OLPC gx2 powered
>
> it works on several gx2 boards, not just OLPC; and it works on LX.
>
> I don't see a reason it would not work with gx1.

Be wary here. GX1 VSA was very very different architecturally than GX/LX 
VSA. In GX1, it was much more insidious to the system. GX/LX was 
architected better to keep things divided and cleaner. There is no 
reason it should not work without enough effort, but just realize that 
GX1 VSA is a bit of a different beast than GX/LX VSA.
> ron

[Segher Boessenkool]

> b) is there any way to tell where the IRQ pins for each PCI device
> are connected to the IRQ router chip?
>
> schematics. Or a volt-ohm meter. In all too many cases, the IRQ  
> table in the fuctory bios is wrong. It can not be trusted.

[OT: Google reports 485 hits for "fuctory bios"].

Another way is to add some instrumentation code to either
the kernel or your firmware to report which IRQ triggered
(and as what all the way on your interrupt chain), and then
"manually" trigger an interrupt event on one of your devices,
and see what happens.  With something like Open Firmware,
this isn't all that hard, as the firmware typically runs
with interrupts disabled on the CPU, so you get no bad side
effects; when done on a running kernel, it's pretty easy to
hang the system.  But most often you'll at least see what IRQ
it was :-)

Doing this properly requires some in-depth knowledge of the
whole interrupt chain on your system -- you'll need that
to correctly program the interrupt subsystem anyway, though.

Segher

[Luis Correia]

ron minnich wrote:
> b) is there any way to tell where the IRQ pins for each PCI device
> are connected to the IRQ router chip?
>
>
>
> schematics. Or a volt-ohm meter.

I followed your advice :)

With the purchase of this nova board, Martin also gave me another one,
that was broken. I grabbed my mini torch and after the fumes from the
removal of the companion chip (cs5530) were gone, access to the pads
is now available.

Here is how things are connected:

CS5530  pins

INTA#   internal USB controller and INTC# on the PCI slot
INTB#   eth2 chip and INTD# on the PCI slot
INTC#   eth1 chip and INTA# on the PCI slot
INTD#   eth0 chip and INTB# on the PCI slot

Following this, i changed the irq_tables.c file to be like this:

/* bus,     dev|fn,   {link, bitmap}, {link, bitmap}, {link, bitmap}, 
{link, bitmap},  slot, rfu */
// USB
{0x00,(0x13<<3)|0x0, {{0x01, 0xdeb8}, {0x00, 0xdeb8}, {0x00, 0xdeb8}, 
{0x00, 0x0deb8}}, 0x0, 0x0},

// eth0
{0x00,(0x0a<<3)|0x0, {{0x04, 0xdeb8}, {0x00, 0xdeb8}, {0x00, 0xdeb8}, 
{0x00, 0x0deb8}}, 0x0, 0x0},

// eth1
{0x00,(0x0b<<3)|0x0, {{0x03, 0xdeb8}, {0x00, 0xdeb8}, {0x00, 0xdeb8}, 
{0x00, 0x0deb8}}, 0x0, 0x0},

// eth2
{0x00,(0x0c<<3)|0x0, {{0x02, 0xdeb8}, {0x00, 0xdeb8}, {0x00, 0xdeb8}, 
{0x00, 0x0deb8}}, 0x0, 0x0},

// PCI slot
{0x00,(0x0f<<3)|0x0, {{0x03, 0xdeb8}, {0x04, 0xdeb8}, {0x01, 0xdeb8}, 
{0x02, 0x0deb8}}, 0x0, 0x0},

Nonetheless, the kernel assumes some strange things, let's keep in mind that
the kernel i'm using is an old 2.4.20, which may or may not treat this IRQ
assignments correctly. Using pci=biosirq makes no change.

These are the IRQ's the kernel assigns:

USB    IRQ9 
eth0   IRQ10
eth1   IRQ11
eth2   IRQ9

any help ? anyone ? volunteers are being accepted... :)

Luis Correia

[ron minnich]

What I recommend is that you skip the PIRQ crap and just hardwire the IRQs
in linuxbios. OLPC is one example of a system which does this. PIRQ does not
work in many cases.

ron
p.s. heroic work there with the VOM, I am very impressed!

[Luis Correia]

ron minnich wrote:
> What I recommend is that you skip the PIRQ crap and just hardwire the 
> IRQs in linuxbios. OLPC is one example of a system which does this. 
> PIRQ does not work in many cases.
>
> ron
> p.s. heroic work there with the VOM, I am very impressed!

You will see the pictures of the board after being hit with the torch...

btw, please direct me with the exact OLPC board, rev_a or btest?

Luis Correia

[ron minnich]

either one will let you see the way we hard wire IRQs

ron

[Segher Boessenkool]

> Following this, i changed the irq_tables.c file to be like this:

Did you fix the table's headers too, to read the correct
number of entries, and the right checksum?  The table you
derived yours from had only two devices entries, and your
results are sort-of consistent with that.
> Nonetheless, the kernel assumes some strange things, let's keep in  
> mind that
> the kernel i'm using is an old 2.4.20, which may or may not treat  
> this IRQ
> assignments correctly. Using pci=biosirq makes no change.

A newer kernel might help for sure.
> These are the IRQ's the kernel assigns:
>
> USB    IRQ9
> eth0   IRQ10
> eth1   IRQ11
> eth2   IRQ9

Can you show us all kernel boot messages about IRQ routing?
Or just *all* boot messages ;-)

Segher

[Luis Correia]

Segher Boessenkool wrote:
> > Following this, i changed the irq_tables.c file to be like this:
>
> Did you fix the table's headers too, to read the correct
> number of entries, and the right checksum?  The table you
> derived yours from had only two devices entries, and your
> results are sort-of consistent with that.

Yes, see attached file.
> > Nonetheless, the kernel assumes some strange things, let's keep in  
> > mind that
> > the kernel i'm using is an old 2.4.20, which may or may not treat  
> > this IRQ
> > assignments correctly. Using pci=biosirq makes no change.
>
> A newer kernel might help for sure.

I tried to use a current Fedora or CentOS distro, but
both refused this processor. I don't have the stamina
to brew my own kernel right now.
> > These are the IRQ's the kernel assigns:
> >
> > USB    IRQ9
> > eth0   IRQ10
> > eth1   IRQ11
> > eth2   IRQ9
>
> Can you show us all kernel boot messages about IRQ routing?
> Or just *all* boot messages ;-)
>
> Segher

Your wish is my command :)

All boot messages and the current irq table are attached.

p.s. don't CC me, i'm on the list.

Luis Correia

[Al Boldi]

Luis Correia wrote:
> Segher Boessenkool wrote:
> > Can you show us all kernel boot messages about IRQ routing?
> > Or just *all* boot messages ;-)
>
> Your wish is my command :)
>
> All boot messages and the current irq table are attached.

From the log:

hm, page 00000000 reserved twice.

Can someone explain what this means?

I get this with Filo 0.5, even on a 16bit factory installed AwardBIOS.

Does Filo do something fishy?

Thanks!

[ron minnich]

On 11/6/06, Al Boldi  wrote:
>     hm, page 00000000 reserved twice.
>
> Can someone explain what this means?

it's been happening for years, I forget what it means, word is 'don't fret'.

ron

[Segher Boessenkool]

> Checking IRQ routing table consistency...
> Inconsistent IRQ routing table size (0x90/0x70)

That looks bad, not sure where it came from.

You didn't show us all boot messages, only the messages at your
default kernel log level.  Try "dmesg -s999999".

Anyway, this looks related:
>     0xe00,           /* IRQs devoted exclusively to PCI usage */

and sure enough, the interrupts that got assigned were
9, 10, 11, 9 (in the order of your irq_table).  Dunno why
no non-exclusively-PCI IRQs were used by Linux.

Segher