LinuxBIOS and Vxworks

[Felix Radensky]

Hi, folks

We have a custom board based on 440LX chipset and
successfully use LinuxBIOS to boot linux kernel.

In the near future we'll have VxWorks on the same
hardware platform. It would be very nice to have LinuxBIOS
booting this OS as well. Do you think this is possible ? Any hints or
pointers would be very much appreciated.

TIA.

Felix.

[Kevin Hester]

Hi,

It has been a couple of years since I was futzing with the ugly beast that is 
vxWorks ;-).  However, I don't think the Intel BSPs are 'plug-and-play'.  
I.e. vxWorks counts on the BIOS setting up the IRQ bindings for all PCI 
devices.

It seems to me that most of the current linuxbios ROMs don't setup the PCI 
IRQs - they rely on the fact that linux is able to use the pirq table and do 
it's own PCI IRQ assignment.  If you are using vxWorks you may need to make 
sure your mainboard.c is assigning IRQs to all PCI devices.

I just sent Andrew a patch which does this for the Via Epia motherboard.  
After this is checked in you should search the source for pci_assign_irqs for 
example usage.

Kevin

On Tuesday 10 December 2002 08:59, Felix Radensky wrote:
> Hi, folks
>
> We have a custom board based on 440LX chipset and
> successfully use LinuxBIOS to boot linux kernel.
>
> In the near future we'll have VxWorks on the same
> hardware platform. It would be very nice to have LinuxBIOS
> booting this OS as well. Do you think this is possible ? Any hints or
> pointers would be very much appreciated.
>
> TIA.
>
> Felix.
>
> Linuxbios mailing list
> [e-mail]
> http://www.clustermatic.org/mailman/listinfo/linuxbios

Kevin Hester  writes:
> Hi,
>
> It has been a couple of years since I was futzing with the ugly beast that is 
> vxWorks ;-).  However, I don't think the Intel BSPs are 'plug-and-play'.  
> I.e. vxWorks counts on the BIOS setting up the IRQ bindings for all PCI 
> devices.
>
> It seems to me that most of the current linuxbios ROMs don't setup the PCI 
> IRQs - they rely on the fact that linux is able to use the pirq table and do 
> it's own PCI IRQ assignment.  If you are using vxWorks you may need to make 
> sure your mainboard.c is assigning IRQs to all PCI devices.
>
> I just sent Andrew a patch which does this for the Via Epia motherboard.  
> After this is checked in you should search the source for pci_assign_irqs for 
> example usage.

Does this use the pirq tables or does it do something else?
As much as possible I would like to have a single source table so we
don't run into strange maintenance issues.

Assigning initial irqs, and reporting them in pci space is something
very much in the scope of LinuxBIOS.  It just hasn't come up much before
now so the code is not there yet...

Eric

[Kevin Hester]

Alas, it doesn't read the pirq table.  That would be damn smart and such a 
feature could be built with a function that uses pci_assign_irqs and the pirq 
table.

The reason I decided to not use the PIRQ table was it seemed like some 
important information may be missing.  For instance, this is the pirq table I 
created for the Epia:

const struct irq_routing_table intel_irq_routing_table = {
    PIRQ_SIGNATURE, /* u32 signature */
    PIRQ_VERSION,   /* u16 version   */
    32+16*5,        /* there can be total 5 devices on the bus */
    0,           /* Where the interrupt router lies (bus) */
    0x88,           /* Where the interrupt router lies (dev) */
    0x1c20,         /* IRQs devoted exclusively to PCI usage */
    0x1106,      /* Vendor Via */
    0x8231,      /* Device 8231 southbridge */
    0,         /* Crap (miniport) */
    { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, /* u8 rfu[11] */
    0x5e,         /*  u8 checksum , this hase to set to some value that would 
give 0 after the sum of all bytes for this structure (including checksum) */
    {
    	/* PCI slot */
    	{0,0xa0, {{0x2, 0xdeb8}, {0x3, 0xdeb8}, {0x4, 0xdeb8}, {0x1, 0xdeb8}}, 0x1, 
0},

/* Unused */
    	{0,0x98, {{0x1, 0xdeb8}, {0x2, 0xdeb8}, {0x3, 0xdeb8}, {0x4, 0xdeb8}}, 0x2, 
0},

/* Unknown */
    	{0,0x50, {{0x3, 0xdeb8}, {0x4, 0xdeb8}, {0x1, 0xdeb8}, {0x2, 0xdeb8}}, 0x3, 
0},

/* Southbridge internal */
    	{0,0x88, {{0x1, 0xdeb8}, {0x2, 0xdeb8}, {0x3, 0xdeb8}, {0x4, 0xdeb8}}, 0x4, 
0},

/* 8231 Ethernet */
    	{0,0x90, {{0x1, 0xdeb8}, {0x2, 0xdeb8}, {0x3, 0xdeb8}, {0x4, 0xdeb8}}, 0, 
0},
    }
};

Most of these values were captured from the standard Award bios that came 
with the board - the remaining fields were fixed/added by me.  The troubling 
thing is the IRQ bitmaps that were passed in for each of the slots, notice 
that all of the IRQ bitmaps are 0xdeb8.  The standard BIOS is apparently 
using this to indicate that a large number of options are available for 
assigning IRQs to each of these slots.

The thing that seems to be missing in the PIRQ table is information about how 
these various IRQs are connected on the backplane and within the southbridge. 
 i.e. within the via vt8601 southbridge there is only four PINTA-D mappings 
to IRQs  .  Each one of these PINTx signals can be mapped to any IRQ, but by 
definition all of the signals on PINTx are sharing the same IRQ.  The OS that 
is using the pirq table is not free to manipulate these independently.

It seems like this sharing of IRQs can be described by the link value fields 
in the pirq table.  For instance, the 8231 Ethernet in the table above shows 
a 0x1 for its PINTA link value.  The fact that the southbridge internal entry 
also shows 0x1 for PINTA link value means that both of those PINTAs must be 
bound to the same IRQ.

So, where does this leave us?

We could make a function that uses the pirq table and pci_assign_irqs, but it 
would require us assigning a particular meaning to the link value fields in 
the pirq table.   If we can use the link value fields as 
we wish, then we can use the PIRQ pci_exclusive_irq bitmask followed by the 
remaining slot specific irq bitmaps.

Unfortunately, reading my "pci system architecture" book says that these link 
value fields must be interpreted as specified by the manufacturer of the 
interrupt router (the southbridge?).

How do you think we should handle this?  I looked at a few PCs/chipsets 
around the office, and they all seem to use similar mappings of this link 
value field.

I was reluctant to get into the realm of mapping arbitrary pirq tables to 
IRQs and I was lazy, so I only added pci_assign_irqs.  For a particular 
mainboard it is pretty painless to use, for instance the Epia uses:

// Our default IRQ bindings for each of the four devices
static const unsigned char southbridgeIrqs[4] = { 11, 5, 10, 12 };
static const unsigned char enetIrqs[4] = { 11, 5, 10, 12 };
static const unsigned char slotIrqs[4] = { 5, 10, 12, 11 };

/*
  Our IDSEL mappings are as follows

PCI slot is AD31          (device 15) (00:14.0)
    Southbridge is AD28       (device 12) (00:11.0)
*/
static void pci_routing_fixup(void)
{
    struct pci_dev *dev;

dev = pci_find_device(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_8231, 0);
    if (dev != NULL) 
    {
    	/* initialize PCI interupts - these assignments depend
    	   on the PCB routing of PINTA-D

PINTA = IRQ11
    	   PINTB = IRQ5
    	   PINTC = IRQ10
    	   PINTD = IRQ12
    	*/
    	pci_write_config_byte(dev, 0x55, 0xb0);
    	pci_write_config_byte(dev, 0x56, 0xa5);
    	pci_write_config_byte(dev, 0x57, 0xc0);
    }

// Standard southbridge components
    pci_assign_irqs(0, 0x11, southbridgeIrqs);

// Ethernet built into southbridge
    pci_assign_irqs(0, 0x12, enetIrqs);
    pci_assign_irqs(0, 0x14, slotIrqs);
}

If folks think we can trust the link value fields to show interrupt sharing, 
then all is well.  I'm happy to make a new function that given an arbitrary 
pirq table will make default IRQ assignments.

Kevin

On Tuesday 10 December 2002 17:36, Eric W. Biederman wrote:
> Kevin Hester  writes:
> > Hi,
> >
> > It has been a couple of years since I was futzing with the ugly beast
> > that is vxWorks ;-).  However, I don't think the Intel BSPs are
> > 'plug-and-play'. I.e. vxWorks counts on the BIOS setting up the IRQ
> > bindings for all PCI devices.
> >
> > It seems to me that most of the current linuxbios ROMs don't setup the
> > PCI IRQs - they rely on the fact that linux is able to use the pirq table
> > and do it's own PCI IRQ assignment.  If you are using vxWorks you may
> > need to make sure your mainboard.c is assigning IRQs to all PCI devices.
> >
> > I just sent Andrew a patch which does this for the Via Epia motherboard.
> > After this is checked in you should search the source for pci_assign_irqs
> > for example usage.
>
> Does this use the pirq tables or does it do something else?
> As much as possible I would like to have a single source table so we
> don't run into strange maintenance issues.
>
> Assigning initial irqs, and reporting them in pci space is something
> very much in the scope of LinuxBIOS.  It just hasn't come up much before
> now so the code is not there yet...
>
> Eric

[Ronald G. Minnich]

On Tue, 10 Dec 2002, Kevin Hester wrote:
> If folks think we can trust the link value fields to show interrupt sharing, 
> then all is well.  I'm happy to make a new function that given an arbitrary 
> pirq table will make default IRQ assignments.

Well, it does seem to work. This is another area I've only looked at a 
bit, to fix IRQ setup in Plan 9 and such.

I've been looking at the Linux arch/i386/kernel/pci-irq.c file and it
seems to be able to manage using PIRQ tables to set up IRQs, even handling
the weirdnesses of some chipsets. Have you checked this out? It's 
educational. This is the file I was hoping to start with for IRQ 
assignment in linuxbios. If there is a problem with my idea let me know.

Eric I don't get your comment about the "kernel PCI code not assigning
IRQs" in light of all the kernel code that does this. I think I 
misunderstood you, can you explain.

thanks

ron

"Ronald G. Minnich"  writes:
> On Tue, 10 Dec 2002, Kevin Hester wrote:
> > If folks think we can trust the link value fields to show interrupt sharing, 
> > then all is well.  I'm happy to make a new function that given an arbitrary 
> > pirq table will make default IRQ assignments.
>
> Well, it does seem to work. This is another area I've only looked at a 
> bit, to fix IRQ setup in Plan 9 and such.
>
> I've been looking at the Linux arch/i386/kernel/pci-irq.c file and it
> seems to be able to manage using PIRQ tables to set up IRQs, even handling
> the weirdnesses of some chipsets. Have you checked this out? It's 
> educational. This is the file I was hoping to start with for IRQ 
> assignment in linuxbios. If there is a problem with my idea let me know.
>
> Eric I don't get your comment about the "kernel PCI code not assigning
> IRQs" in light of all the kernel code that does this. I think I 
> misunderstood you, can you explain.

There is an pci irq scratch register, that reports the BIOS's irq
assignments.  The kernel does not and should not populate that
register in pci configuration space.  But LinuxBIOS needs to populate
that register, so OS's that don't know about the pirq table can find
the irq assignments.

Eric

[BIOS Support]

Kevin,

I'm looking forward to duplicating the success you had with the VIA Epia
motherboard code.

Are all the patches for VIA Epia in Andrew's hands now?

Anybody: What's the recommended approach/reference/magic to getting video
going for LinuxBIOS. I'd like to get the on-chip video going on the VIA Epia
board - Hints appreciated.

Thanks.
Andy
----- Original Message -----
From: "Kevin Hester" 
To: "Felix Radensky" ; 
Sent: Tuesday, December 10, 2002 7:52 PM
Subject: Re: LinuxBIOS and Vxworks
> I just sent Andrew a patch which does this for the Via Epia motherboard.
> After this is checked in you should search the source for pci_assign_irqs

for
> example usage.
>
> Kevin

[Steve M. Gehlbach]

> Anybody: What's the recommended approach/reference/magic to getting video
> going for LinuxBIOS. I'd like to get the on-chip video going on
> the VIA Epia
> board - Hints appreciated.
>
> Thanks.
> Andy

Do you mean a linuxbios vga text console?

I have the code to set the legacy registers to start VGA for a vga console,
integrated into linuxbios, working on two different integrated chips, the
stpc cpu/chipset, and the sis 630 chipset.  It sets the registers for
640x400 std text vga, and also 640x480x4 graphics.  I was working on the
display of a .pcx graphics file when I had to get onto something else, but
it was all working the last time I tried it.

You are welcome to the code if it would help.  AFAIR the EPIA is the
PLE133/vt8601a, which has legacy VGA registers.  All you need usually is
legacy plus a "few other settings" to get text and/or simple legacy graphics
going.  The "few other settings" can be bitch, though.

-Steve

[BIOS Support]

> Do you mean a linuxbios vga text console?

Yes, that's a start. I'd be looking for how quick I can put something on the
screen to pacify users - it could even be character graphics for a simple
logo.
> I have the code to set the legacy registers to start VGA for a vga

console,
> integrated into linuxbios, working on two different integrated chips, the
> stpc cpu/chipset, and the sis 630 chipset.  It sets the registers for
> 640x400 std text vga, and also 640x480x4 graphics.  I was working on the
> display of a .pcx graphics file when I had to get onto something else, but
> it was all working the last time I tried it.

Graphics through the frame buffer would be nice but I'm willing to look into
that. I've heard of some code that already works with the vt8601 that I'm
looking to use.
> You are welcome to the code if it would help.  AFAIR the EPIA is the
> PLE133/vt8601a, which has legacy VGA registers.  All you need usually is
> legacy plus a "few other settings" to get text and/or simple legacy

graphics
> going.  The "few other settings" can be bitch, though.

Yep, the "few other settings" is like the saying in engineering that goes
something along the lines of "the final 10% of the work takes 90% of the
time." That's in the category of "magic" that I was referring too earlier
(it goes by other names such as "company confidential", "proprietary", "NDA
required", etc.).

Andy

VGA and LinuxBios

[Steve M. Gehlbach]

> I've heard of some code that already works with the vt8601 that I'm
> looking to use.
>
> Andy

There should be a way to put the 8601a specific stuff in
northbridge/via/8601a, and try and keep vga generic (legacy) register code
in a central place (eg, pc80/). This worked well for stpc and sis630; most
of the code is common even though the chips are radically different, they
both match well to legacy VGA.  There are also changes to lib/video_subr.c
since it currently doesn't move the cursor or use the correct memory address
for text.

The only reason this hasn't been integrated into linuxbios codebase at this
point is partly lack of interest (I think) in this group, since most use the
serial console, and partly that I have been off on other things lately.

All of my projects use the vga console, so as I use various integrated
chipsets, I will be adding vga for each.  Until this gets into the linuxbios
base, anyone that wants the code just send me an email.  It's all gpl of
course.

-Steve

VGA and LinuxBios

"Steve M. Gehlbach"  writes:
> > I've heard of some code that already works with the vt8601 that I'm
> > looking to use.
> >
> > Andy
>
> There should be a way to put the 8601a specific stuff in
> northbridge/via/8601a, and try and keep vga generic (legacy) register code
> in a central place (eg, pc80/). This worked well for stpc and sis630; most
> of the code is common even though the chips are radically different, they
> both match well to legacy VGA.  There are also changes to lib/video_subr.c
> since it currently doesn't move the cursor or use the correct memory address
> for text.

Not a big surprise on the latter as the code was written but never really
tested.
> The only reason this hasn't been integrated into linuxbios codebase at this
> point is partly lack of interest (I think) in this group, since most use the
> serial console, and partly that I have been off on other things lately.

Video is a minor part of things, but it is starting to get annoying
to be able to do an entire cluster with LinuxBIOS all except a management
node, which needs video and a keyboard.
> All of my projects use the vga console, so as I use various integrated
> chipsets, I will be adding vga for each.  Until this gets into the linuxbios
> base, anyone that wants the code just send me an email.  It's all gpl of
> course.

I would certainly be interested.  I don't know if I could find the time
to do anything with it but I can at least collect up some code until
I have time to pursue it further.

Eric

VGA and LinuxBios

[Nathanael Noblet]

On Tuesday, December 10, 2002, at 09:30  PM, Steve M. Gehlbach wrote:
> > I've heard of some code that already works with the vt8601 that I'm
> > looking to use.
> >
> > Andy
>
> There should be a way to put the 8601a specific stuff in
> northbridge/via/8601a, and try and keep vga generic (legacy) register 
> code
> in a central place (eg, pc80/). This worked well for stpc and sis630; 
> most
> of the code is common even though the chips are radically different, 
> they
> both match well to legacy VGA.  There are also changes to 
> lib/video_subr.c
> since it currently doesn't move the cursor or use the correct memory 
> address
> for text.
>
> The only reason this hasn't been integrated into linuxbios codebase at 
> this
> point is partly lack of interest (I think) in this group, since most 
> use the
> serial console, and partly that I have been off on other things lately.
>
> All of my projects use the vga console, so as I use various integrated
> chipsets, I will be adding vga for each.  Until this gets into the 
> linuxbios
> base, anyone that wants the code just send me an email.  It's all gpl 
> of
> course.

I am working on getting the sis 530 working which on my Arbor PIA-671 
board has a 630 3D AGP card I would mainly like to use for my project. 
So if you can send me the code to enable the VGA stuff that would be 
great. I do have the datasheet for the board and its video controller 
so I may be able to find the "special chip specific" stuff from looking 
at your code.

Thanks in advance,

[Ronald G. Minnich]

On Tue, 10 Dec 2002, BIOS Support wrote:
> Anybody: What's the recommended approach/reference/magic to getting video
> going for LinuxBIOS. I'd like to get the on-chip video going on the VIA Epia
> board - Hints appreciated.

it depends. If you can get the chipset to init by knowing what to do, then 
do it in the northbridge code (if integrated) or in the mainboard code (if 
not integrated).

If it is a Mystery Chip but you have a VGABIOS for it, try enabling 
linuxbios VGABIOS support and see if that turns it on.

Otherwise you'll have to see if linux framebuffer support will do it, or 
the user-mode program we also have in freebios/utils.

It's still a hard problem, made harder by vendor non-cooperation.

ron

[Ronald G. Minnich]

On Tue, 10 Dec 2002, Kevin Hester wrote:
> It seems to me that most of the current linuxbios ROMs don't setup the PCI 
> IRQs - they rely on the fact that linux is able to use the pirq table and do 
> it's own PCI IRQ assignment.  If you are using vxWorks you may need to make 
> sure your mainboard.c is assigning IRQs to all PCI devices.

we're going to have to fix that. I hoped not to do this but too many OSes 
either can't do it or get it wrong.

I want to see if we can use that patch of yours.

thanks

ron

[Adam Agnew]

> we're going to have to fix that. I hoped not to do this but too many OSes
> either can't do it or get it wrong.

I know we'd like it for the Bochs stuff. FreeBSD and Windows 9x series
certainly throw fits about it.

[Ronald G. Minnich]

On Wed, 11 Dec 2002, Adam Agnew wrote:
> > we're going to have to fix that. I hoped not to do this but too many OSes
> > either can't do it or get it wrong.
>
> I know we'd like it for the Bochs stuff. FreeBSD and Windows 9x series
> certainly throw fits about it.

I'm working on sucking in the linux PIRQ code now. It took me some time to 
figure out an approach but I think I know what to do.

Linux PCI code has diverged significantly from what we started with, which 
is part of the fun.

ron

"Ronald G. Minnich"  writes:
> On Wed, 11 Dec 2002, Adam Agnew wrote:
> > > we're going to have to fix that. I hoped not to do this but too many OSes
> > > either can't do it or get it wrong.
> >
> > I know we'd like it for the Bochs stuff. FreeBSD and Windows 9x series
> > certainly throw fits about it.
>
> I'm working on sucking in the linux PIRQ code now. It took me some time to 
> figure out an approach but I think I know what to do.
>
> Linux PCI code has diverged significantly from what we started with, which 
> is part of the fun.

And the Linux PCI code never sets the IRQ registers in PCI space
at any point.  (Which is a good thing or we might have problems
with kexec).  In any event per chipset part of the code is
only about 10 lines of code per vendor, so it should not be
to hard to handle.

Eric