[LinuxBIOS] trying to boot gigabyte m57sli-s4

[Ward Vandewege]

Hi YH and list,

I've been trying to get the the gigabyte m57sli-s4 to boot, using the code
that YH sent to the list on January 19th (the code in the v2 tree does not
compile yet), but I'm having some IRQ problems it seems.

I see things like this in the boot log:

[   81.290497] PCI: Probing PCI hardware
[   81.295506] PCI: Unable to handle 64-bit address space for bridge
0000:00:0b.0
[   81.303828] PCI: Unable to handle 64-bit address space for bridge
0000:00:0c.0
[   81.312150] PCI: Unable to handle 64-bit address space for bridge
0000:00:0d.0
[   81.320479] PCI: Unable to handle 64-bit address space for bridge
0000:00:0e.0
[   81.328817] PCI: Unable to handle 64-bit address space for bridge
0000:00:0f.0
[   81.337596] PCI: Using IRQ router default [10de/0370] at 0000:00:06.0
[   81.345008] PCI: IRQ 0 for device 0000:00:06.1 doesn't match PIRQ mask -
try pci=usepirqmask

And a bit further:

[   81.526599] pcie_portdrv_probe->Dev[0376:10de] has invalid IRQ. Check
vendor BIOS
[   81.535189] assign_interrupt_mode Found MSI capability
[   81.541136] pcie_portdrv_probe->Dev[0374:10de] has invalid IRQ. Check
vendor BIOS
[   81.549747] assign_interrupt_mode Found MSI capability
[   81.555689] pcie_portdrv_probe->Dev[0374:10de] has invalid IRQ. Check
vendor BIOS
[   81.564285] assign_interrupt_mode Found MSI capability
[   81.570227] pcie_portdrv_probe->Dev[0378:10de] has invalid IRQ. Check
vendor BIOS
[   81.578857] assign_interrupt_mode Found MSI capability
[   81.584806] pcie_portdrv_probe->Dev[0375:10de] has invalid IRQ. Check
vendor BIOS
[   81.593409] assign_interrupt_mode Found MSI capability
[   81.599350] pcie_portdrv_probe->Dev[0377:10de] has invalid IRQ. Check
vendor BIOS
[   81.607949] assign_interrupt_mode Found MSI capability

The interesting thing is that those pci ids don't exist on the board.

The boot fails with a kernel panic:

[   82.619607] SCSI subsystem initialized
[   82.625477] PCI: No IRQ known for interrupt pin A of device 0000:00:05.0.
Please try using pci=biosirq.
[   82.636355] ata1: SATA max UDMA/133 cmd 0x3000 ctl 0x3072 bmdma 0x2CD0 irq
0
[   82.644455] ata2: SATA max UDMA/133 cmd 0x3010 ctl 0x3082 bmdma 0x2CD8 irq
0
[   82.652544] Unable to handle kernel NULL pointer dereference at virtual
address 00000000

I've tried 2 different (32 bit) kernels: the 2.6.15 one that comes with
Gnewsense, and a stock 2.6.20.1 from kernel.org.

I've attached both boot logs - the 2.6.15 one is called
minicom-gb-20070306-04.cap, and the 2.6.20.1 is called
minicom-gb-20070306-07.cap.

I have not tried a 64 bit kernel yet.

Any suggestions as to what is going on here?

Thanks,
Ward.

[Ward Vandewege]

I should have attached the lspci output(s) - here they are.

Thanks,
Ward.

[Lu, Yinghai]

Please try 64bit latest kernel.

YH

[Ward Vandewege]

On Tue, Mar 06, 2007 at 04:17:32PM -0800, Lu, Yinghai wrote:
> Please try 64bit latest kernel.

OK, I'll do that on Thursday.

Thanks,
Ward.

[Ward Vandewege]

On Tue, Mar 06, 2007 at 04:17:32PM -0800, Lu, Yinghai wrote:
> Please try 64bit latest kernel.

Please find the boot log for 2.6.15-amd64 (standard Ubuntu Dapper kernel)
attached. Same problem it seems.

I'll try a stock 2.6.20.1 after lunch and send in the boot log.

Thanks,
Ward.

[Ward Vandewege]

On Tue, Mar 06, 2007 at 04:17:32PM -0800, Lu, Yinghai wrote:
> Please try 64bit latest kernel.

OK, I tried a stock 2.6.20.1 kernel. This kernel boots fine with the
proprietary BIOS (see attached file minicom-gb-20070308-07-with-noapic.cap).
With LinuxBIOS, it doesn't even get to the kernel panic - it simply fails to
find its sata drives (sata_nv says it can't do anything with the SATA
controller devices because there's no IRQ assigned). The boot fails
consequently because it can't find its root filesystem. See the attached file
minicom-gb-20070308-04.cap.

Thanks,
Ward.

[Ward Vandewege]

Yinghai, any thoughts on this?

Thanks,
Ward.

On Thu, Mar 08, 2007 at 02:33:12PM -0500, Ward Vandewege wrote:
> On Tue, Mar 06, 2007 at 04:17:32PM -0800, Lu, Yinghai wrote:
> > Please try 64bit latest kernel.
>
> OK, I tried a stock 2.6.20.1 kernel. This kernel boots fine with the
> proprietary BIOS (see attached file minicom-gb-20070308-07-with-noapic.cap).
> With LinuxBIOS, it doesn't even get to the kernel panic - it simply fails to
> find its sata drives (sata_nv says it can't do anything with the SATA
> controller devices because there's no IRQ assigned). The boot fails
> consequently because it can't find its root filesystem. See the attached file
> minicom-gb-20070308-04.cap.

[Lu, Yinghai]

-----Original Message-----
From: [e-mail]
[mailto:[e-mail]] On Behalf Of Ward Vandewege
Sent: Monday, March 12, 2007 6:17 AM
To: yhlu
Cc: [e-mail]
Subject: Re: [LinuxBIOS] trying to boot gigabyte m57sli-s4
> Yinghai, any thoughts on this?

I double check that, it works well.

Please check the boot log.

Thanks

Yinghai Lu

[ST]

> Please check the boot log.

The bootlog looks fine. I am still having problems here getting a kernel 
booted without the "noapic" option (stock bios updated to f7). 
2.6.20.2 gives me:
ENABLING IO-APIC IRQs
..TIMER: vector=0x31 apic1=0 pin1=0 apic2=-1 pin2=-1
..MP-BIOS bug: 8254 timer not connected to IO-APIC
...trying to set up timer (IRQ0) through the 8259A ... failed.
...trying to set up timer as Virtual Wire IRQ... failed.
...trying to set up timer as ExtINT IRQ... failed :(.
Kernel panic - not syncing: IO-APIC + timer doesn't work!

Do i need a kernel right out of the git repository?
I think without having a normal clean boot i don't need to start with 
linuxbios :-(.

Besides does anybody know if the second free place on the PCB is still 
connected in a proper way to enable diy dual boot bios. Does anybody know 
which spi flash type is placed on the m57sli-s4.

There is an inner and outer ring of contacts for the second free bios chip. 
Does anybody know if these are for different chips or are these for one chip. 
The latter would make soldering with my tools impossible.

Thanks
ST

[Ward Vandewege]

On Mon, Mar 12, 2007 at 09:11:43PM +0100, ST wrote:
> > Please check the boot log.
>
> The bootlog looks fine. I am still having problems here getting a kernel 
> booted without the "noapic" option (stock bios updated to f7). 
> 2.6.20.2 gives me:
> ENABLING IO-APIC IRQs
> ..TIMER: vector=0x31 apic1=0 pin1=0 apic2=-1 pin2=-1
> ..MP-BIOS bug: 8254 timer not connected to IO-APIC
> ...trying to set up timer (IRQ0) through the 8259A ... failed.
> ...trying to set up timer as Virtual Wire IRQ... failed.
> ...trying to set up timer as ExtINT IRQ... failed :(.
> Kernel panic - not syncing: IO-APIC + timer doesn't work!
>
> Do i need a kernel right out of the git repository?

Booting 2.6.20.1 with noapic works for me:

title   Ubuntu, kernel 2.6.20.1
root    (hd0,0)
kernel    /boot/vmlinuz-2.6.20.1 root=/dev/sda1 ro console=tty0 console=ttyS0,115200 noapic
savedefault
boot
> I think without having a normal clean boot i don't need to start with 
> linuxbios :-(.

Yeah, normal boot first :)
> Besides does anybody know if the second free place on the PCB is still 
> connected in a proper way to enable diy dual boot bios. Does anybody know 
> which spi flash type is placed on the m57sli-s4.

Uhm - none I think. If you look closely at the second (free) place, you'll
see paths for a plcc socket, and within that, paths for an spi flash part (I
think).
> There is an inner and outer ring of contacts for the second free bios chip. 
> Does anybody know if these are for different chips or are these for one chip. 
> The latter would make soldering with my tools impossible.

You only need the outer ring for the plcc. That's what the first chip is -
when ours came off, there was nothing underneath.

Thanks,
Ward.

[ST]

Thanks for your quick answer.
> Booting 2.6.20.1 with noapic works for me:

yah, but i'd really like to use both processors of this X2 ...
So am i right that you can't boot without the "noapic" line?

I am going to trying the rc kernels.
> Yeah, normal boot first :)

Yeah.
> > Besides does anybody know if the second free place on the PCB is still
> > connected in a proper way to enable diy dual boot bios. Does anybody know
> > which spi flash type is placed on the m57sli-s4.
>
> Uhm - none I think. If you look closely at the second (free) place, you'll
> see paths for a plcc socket, and within that, paths for an spi flash part
> (I think).

Ok, so placing a plcc socket would probably work out for a diy dual socket 
board.
> You only need the outer ring for the plcc. That's what the first chip is -
> when ours came off, there was nothing underneath.

I would prefer not to remove the first part but solder something on the free 
space. I think i have to search my multimeter.

Thanks
ST

[Ward Vandewege]

On Mon, Mar 12, 2007 at 09:42:59PM +0100, ST wrote:
> Thanks for your quick answer.
> > Booting 2.6.20.1 with noapic works for me:
>
> yah, but i'd really like to use both processors of this X2 ...
> So am i right that you can't boot without the "noapic" line?

Uhm - no?

ward@neuromancer:~$ cat /proc/cpuinfo 
processor       : 0
vendor_id       : AuthenticAMD
cpu family      : 15
model           : 75
model name      : AMD Athlon(tm) 64 X2 Dual Core Processor 3800+
stepping        : 2
cpu MHz         : 1000.000
cache size      : 512 KB
physical id     : 0
siblings        : 2
core id         : 0
cpu cores       : 2
fpu             : yes
fpu_exception   : yes
cpuid level     : 1
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca
cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt rdtscp
lm 3dnowext 3dnow pni cx16 lahf_lm cmp_legacy svm extapic cr8_legacy
bogomips        : 2011.97
TLB size        : 1024 4K pages
clflush size    : 64
cache_alignment : 64
address sizes   : 40 bits physical, 48 bits virtual
power management: ts fid vid ttp tm stc

processor       : 1
vendor_id       : AuthenticAMD
cpu family      : 15
model           : 75
model name      : AMD Athlon(tm) 64 X2 Dual Core Processor 3800+
stepping        : 2
cpu MHz         : 1000.000
cache size      : 512 KB
physical id     : 0
siblings        : 2
core id         : 1
cpu cores       : 2
fpu             : yes
fpu_exception   : yes
cpuid level     : 1
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca
cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt rdtscp
lm 3dnowext 3dnow pni cx16 lahf_lm cmp_legacy svm extapic cr8_legacy
bogomips        : 2011.97
TLB size        : 1024 4K pages
clflush size    : 64
cache_alignment : 64
address sizes   : 40 bits physical, 48 bits virtual
power management: ts fid vid ttp tm stc

(this is 2.6.21-rc3, but it should be the same for 2.6.20.x)
> I am going to trying the rc kernels.
> > Yeah, normal boot first :)
>
> Yeah.
> > > Besides does anybody know if the second free place on the PCB is still
> > > connected in a proper way to enable diy dual boot bios. Does anybody know
> > > which spi flash type is placed on the m57sli-s4.
> >
> > Uhm - none I think. If you look closely at the second (free) place, you'll
> > see paths for a plcc socket, and within that, paths for an spi flash part
> > (I think).
>
> Ok, so placing a plcc socket would probably work out for a diy dual socket 
> board.
> > You only need the outer ring for the plcc. That's what the first chip is -
> > when ours came off, there was nothing underneath.
>
> I would prefer not to remove the first part but solder something on the free 
> space. I think i have to search my multimeter.

I don't know how that second chip is wired up, or how the fallback mechanism
works...

Thanks,
Ward.

[Ward Vandewege]

On Mon, Mar 12, 2007 at 04:47:19PM -0400, Ward Vandewege wrote:
> On Mon, Mar 12, 2007 at 09:42:59PM +0100, ST wrote:
> > Thanks for your quick answer.
> > > Booting 2.6.20.1 with noapic works for me:
> >
> > yah, but i'd really like to use both processors of this X2 ...
> > So am i right that you can't boot without the "noapic" line?
>
> Uhm - no?

Sorry, I meant 'no' to the 'use both processors' bit.

As for booting without the noapic option, that seems to work with
2.6.21-rc3 but not 2.6.20.1.

Thanks,
Ward.

[Quux]

Ward Vandewege schrieb:
> > > > Besides does anybody know if the second free place on the PCB is still
> > > > connected in a proper way to enable diy dual boot bios. Does anybody know
> > > > which spi flash type is placed on the m57sli-s4.
> > >
> > > Uhm - none I think. If you look closely at the second (free) place, you'll
> > > see paths for a plcc socket, and within that, paths for an spi flash part
> > > You only need the outer ring for the plcc. That's what the first chip is -
> > > when ours came off, there was nothing underneath.
> >
> > I would prefer not to remove the first part but solder something on the free 
> > space. I think i have to search my multimeter.
>
> I don't know how that second chip is wired up, or how the fallback mechanism
> works...

I wonder whether the inner spi flash part is indeed a fallback for the 
outer plcc flash memory. This is not necessarily so. Like on NICs, spi 
is for config data (MAC@,  PHY speed and such) while plcc is for BOOT 
ROM.   -- Q

[Ward Vandewege]

Hi Yinghai,

It works! Seems like your kernel options make all the difference.

The machine boots with these extra parameters:

apic=debug acpi_dbg_level=0xffffffff pci=noacpi,routeirq
snd-hda-intel.enable_msi=1

This works in 2.6.20.1 and 2.6.21-rc3.

There's one problem: the intergrated network controller does not work.

Here's a snippet from a boot with the proprietary bios:

[   29.675453] forcedeth.c: Reverse Engineered nForce ethernet driver.
Version 0.60.
[   29.683267] ACPI: PCI Interrupt Link [LMAC] enabled at IRQ 5
[   29.688967] ACPI: PCI Interrupt 0000:00:08.0[A] -> Link [LMAC] -> GSI 5
(level, low) -> IRQ 5
[   29.697623] forcedeth: using HIGHDMA
[   30.224777] eth0: forcedeth.c: subsystem: 01458:e000 bound to 0000:00:08.0
[   30.231693] Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
[   30.238082] ide: Assuming 33MHz system bus speed for PIO modes; override
with idebus=xx

Here's the equivalent booting with LinuxBIOS:

[   66.416122] forcedeth.c: Reverse Engineered nForce ethernet driver.
Version 0.60.
[   66.423682] forcedeth: using HIGHDMA
[   66.948233] eth0: forcedeth.c: subsystem: 01022:2b80 bound to 0000:00:08.0
[   66.955144] Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
[   66.961528] ide: Assuming 33MHz system bus speed for PIO modes; override
with idebus=xx

Booted under LinuxBIOS, there is simply no network device available. Ideas to
get the nic to work?

Also, the LinuxBIOS code does not support ACPI; would it be hard to add that?
That's quite important in this case - it's a desktop board.

I've attached the boot log with LinuxBIOS
(minicom-gb-20070312-03-lb-2.6.21-rc3-64.cap) and a boot with a proprietary
BIOS (minicom-gb-20070312-04-prop-2.6.21-rc3-64.cap).

Thanks,
Ward.

[yhlu]

you may need to reconfig your eth0. because the MAC address or pci
device id change.

acpi support may need dsdt..., and that copyright doesn't belong to Nvidia ...

we may need one cleaning room implementation...

YH

On 3/12/07, Ward Vandewege  wrote:
> Hi Yinghai,
>
> It works! Seems like your kernel options make all the difference.
>
> The machine boots with these extra parameters:
>
> apic=debug acpi_dbg_level=0xffffffff pci=noacpi,routeirq
> snd-hda-intel.enable_msi=1
>
> This works in 2.6.20.1 and 2.6.21-rc3.
>
> There's one problem: the intergrated network controller does not work.
>
> Here's a snippet from a boot with the proprietary bios:
>
> [   29.675453] forcedeth.c: Reverse Engineered nForce ethernet driver.
> Version 0.60.
> [   29.683267] ACPI: PCI Interrupt Link [LMAC] enabled at IRQ 5
> [   29.688967] ACPI: PCI Interrupt 0000:00:08.0[A] -> Link [LMAC] -> GSI 5
> (level, low) -> IRQ 5
> [   29.697623] forcedeth: using HIGHDMA
> [   30.224777] eth0: forcedeth.c: subsystem: 01458:e000 bound to 0000:00:08.0
> [   30.231693] Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
> [   30.238082] ide: Assuming 33MHz system bus speed for PIO modes; override
> with idebus=xx
>
> Here's the equivalent booting with LinuxBIOS:
>
> [   66.416122] forcedeth.c: Reverse Engineered nForce ethernet driver.
> Version 0.60.
> [   66.423682] forcedeth: using HIGHDMA
> [   66.948233] eth0: forcedeth.c: subsystem: 01022:2b80 bound to 0000:00:08.0
> [   66.955144] Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
> [   66.961528] ide: Assuming 33MHz system bus speed for PIO modes; override
> with idebus=xx
>
> Booted under LinuxBIOS, there is simply no network device available. Ideas to
> get the nic to work?
>
> Also, the LinuxBIOS code does not support ACPI; would it be hard to add that?
> That's quite important in this case - it's a desktop board.
>
> I've attached the boot log with LinuxBIOS
> (minicom-gb-20070312-03-lb-2.6.21-rc3-64.cap) and a boot with a proprietary
> BIOS (minicom-gb-20070312-04-prop-2.6.21-rc3-64.cap).
>
> Thanks,
> Ward.

[Ward Vandewege]

Hi Yinghai,

Finally got some more time to play with LB.

On Mon, Mar 12, 2007 at 03:36:01PM -0700, yhlu wrote:
> you may need to reconfig your eth0. because the MAC address or pci
> device id change.

You're quite right. The mac address changes when switching to LinuxBIOS.

Why exactly is this? Is there a way to avoid it? Ideally, I'd like LinuxBIOS
to be a drop-in replacement for the proprietary BIOS, with as few system
configuration changes required as possible.
> acpi support may need dsdt..., and that copyright doesn't belong to Nvidia 
> ...

So - what needs to happen to get ACPI support, and how can we make that
happen?

I assume that some code changes are needed first of all - and then
negotiations with the mainboard vendors to acquire any required dsdt's? Or
can we extract those from a running proprietary bios somehow?
> we may need one cleaning room implementation...

Can you please elaborate a bit on what would be necessary? Maybe this could
be a summer of code project?

Thanks for all your help!
Ward.

[Lu, Yinghai]

For MAC address:

1. make the flashrom util to take MAC address and GUUID as command
parameter.
2. use flashrom with excluding range to keep MAC address in the flash.

YH

[Stefan Reinauer]

* Lu, Yinghai  [070319 21:04]:
> For MAC address:
> make the flashrom util to take MAC address and GUUID as command
>
> parameter.
> 2. use flashrom with excluding range to keep MAC address in the flash.

where is it stored? Which area must stay untouched? I can add a .layout
file for that.

[Lu, Yinghai]

I'm not sure on Legacy bios, ward could check that for you. But for LinuxBIOS, I put them at last 16x3 bytes. 
0xffffffd0

YH

-----Original Message-----
From: Stefan Reinauer [mailto:[e-mail]] 
Sent: Monday, March 19, 2007 1:51 PM
To: Lu, Yinghai
Cc: Ward Vandewege; yhlu; [e-mail]
Subject: Re: [LinuxBIOS] trying to boot gigabyte m57sli-s4

* Lu, Yinghai  [070319 21:04]:
> For MAC address:
> make the flashrom util to take MAC address and GUUID as command
>
> parameter.
> 2. use flashrom with excluding range to keep MAC address in the flash.

where is it stored? Which area must stay untouched? I can add a .layout
file for that.

[Stefan Reinauer]

* Lu, Yinghai  [070319 21:57]:
> I'm not sure on Legacy bios, ward could check that for you. But for LinuxBIOS, I put them at last 16x3 bytes. 
> 0xffffffd0

that would be 32 bytes, no? if it is 48 bytes, any changes to the reset
vector are not found. How big is the actual information linuxbios
expects there?

[Lu, Yinghai]

16 bytes.

-----Original Message-----
From: Stefan Reinauer [mailto:[e-mail]] 
Sent: Monday, March 19, 2007 2:08 PM
To: Lu, Yinghai
Cc: Ward Vandewege; yhlu; [e-mail]
Subject: Re: [LinuxBIOS] trying to boot gigabyte m57sli-s4

* Lu, Yinghai  [070319 21:57]:
> I'm not sure on Legacy bios, ward could check that for you. But for LinuxBIOS, I put them at last 16x3 bytes. 
> 0xffffffd0

that would be 32 bytes, no? if it is 48 bytes, any changes to the reset
vector are not found. How big is the actual information linuxbios
expects there?

[Ward Vandewege]

On Mon, Mar 19, 2007 at 01:57:08PM -0700, Lu, Yinghai wrote:
> I'm not sure on Legacy bios, ward could check that for you.

It's at 00074e30:

00074e30  00 16 e6 8d a2 fb ff ff  03 80 80 80 4b 04 00 00

The mac address of my machine was 00:16:e6:8d:a2:fb.

Thanks,
Ward.

[Peter Stuge]

On Tue, Mar 06, 2007 at 07:13:02PM -0500, Ward Vandewege wrote:
> [   81.526599] pcie_portdrv_probe->Dev[0376:10de] has invalid IRQ. Check

[..]
> The interesting thing is that those pci ids don't exist on the board.

[..]
> PCI: 00:0a.0 [10de/0376] enabled

Seems the first code has vendor/device swapped.

//Peter