[LinuxBIOS] [PATCH] Fix i82810 to boot!

[Corey Osgood]

See attached patch and boot log.

-Corey

[Peter Stuge]

On Mon, Jun 18, 2007 at 01:52:35PM -0400, Corey Osgood wrote:
> This patch fixes up a couple mistakes I made with the i82810 and
> mew-vw to make the system boot to a command line.

Please describe the fixes even if just briefly.

Thanks.

//Peter

[Joseph Smith]

Quoting Peter Stuge :
> On Mon, Jun 18, 2007 at 01:52:35PM -0400, Corey Osgood wrote:
> > This patch fixes up a couple mistakes I made with the i82810 and
> > mew-vw to make the system boot to a command line.
>
> Please describe the fixes even if just briefly.
>
> Thanks.
>
> //Peter

What were the mistakes?

Thanks - Joe

[Uwe Hermann]

On Mon, Jun 18, 2007 at 01:52:35PM -0400, Corey Osgood wrote:
> This patch fixes up a couple mistakes I made with the i82810 and mew-vw to make
> the system boot to a command line.
>
> Signed-off-by: Corey Osgood

Looks commitable, but as Peter said, please describe what was fixed why,
and how. What was the settings which prevented a successful boot?
The IRQ Table thing (IRQ_SLOT_COUNT) or the AGP settings, or both?
> Index: src/mainboard/asus/mew-vm/Options.lb
>
> --- src/mainboard/asus/mew-vm/Options.lb	(revision 2724)
> +++ src/mainboard/asus/mew-vm/Options.lb	(working copy)
> @@ -67,7 +67,7 @@
>  ## Build code to export a programmable irq routing table
>  ##
>  default HAVE_PIRQ_TABLE = 1
> -default IRQ_SLOT_COUNT = 4
> +default IRQ_SLOT_COUNT = 11

Is this value correct? Did you copy the irq_tables.c file from some
other target or was it generated by getpir or did you create it
manually?
> pci_write_config8(ctrl->d0, PAM, 0x00);
> pci_write_config8(ctrl->d0, PAM, 0xff);

If you do this (i.e. make all those regions "normal" RAM), I think you
can also change northbridge.c to report the now "freed" RAM:

/* Report the memory regions. */
                idx = 10;
                ram_resource(dev, idx++, 0, 640);
                ram_resource(dev, idx++, 768, tolmk - 768);

General question: is there some reason to configure the PAM-controlled areas
to something other than "read/write" in any case? Do any modern OSes or
payloads which we might want to support _need_ the PAM regions to be
something other than read/write?
> Uhhuh. NMI received for unknown reason 31 on CPU 0.
> Do you have a strange power saving mode enabled?
> Dazed and confused, but trying to continue

Oh yeah, kernel messages are really funny sometimes :-)

Uwe.

[Stefan Reinauer]

* Uwe Hermann  [070619 02:24]:
> General question: is there some reason to configure the PAM-controlled areas
> to something other than "read/write" in any case? Do any modern OSes or
> payloads which we might want to support _need_ the PAM regions to be
> something other than read/write?

Yes. ADLO.

[Uwe Hermann]

On Tue, Jun 19, 2007 at 02:29:20AM +0200, Stefan Reinauer wrote:
> Uwe Hermann  [070619 02:24]:
> > General question: is there some reason to configure the PAM-controlled areas
> > to something other than "read/write" in any case? Do any modern OSes or
> > payloads which we might want to support _need_ the PAM regions to be
> > something other than read/write?
>
> Yes. ADLO.

OK, so we'll have to take care about that.

Which settings does ADLO require/expect?

Here's a list of the PAM registers and which regions they enable (on 440BX):

PAM Reg   Attribute Bits       Memory Segment      Comments    Offset
PAM0[3:0]     Reserved                                            59h
PAM0[7:4] R  R     WE      RE 0F0000h ­ 0FFFFFh BIOS Area         59h
PAM1[3:0] R  R     WE      RE 0C0000h ­ 0C3FFFh ISA Add-on BIOS¹  5Ah
PAM1[7:4] R  R     WE      RE 0C4000h ­ 0C7FFFh ISA Add-on BIOS¹  5Ah
PAM2[3:0] R  R     WE      RE 0C8000h ­ 0CBFFFh ISA Add-on BIOS¹  5Bh
PAM2[7:4] R  R     WE      RE 0CC000h ­ 0CFFFFh ISA Add-on BIOS¹  5Bh
PAM3[3:0] R  R     WE      RE 0D0000h ­ 0D3FFFh ISA Add-on BIOS   5Ch
PAM3[7:4] R  R     WE      RE 0D4000h ­ 0D7FFFh ISA Add-on BIOS   5Ch
PAM4[3:0] R  R     WE      RE 0D8000h ­ 0DBFFFh ISA Add-on BIOS   5Dh
PAM4[7:4] R  R     WE      RE 0DC000h ­ 0DFFFFh ISA Add-on BIOS   5Dh
PAM5[3:0] R  R     WE      RE 0E0000h ­ 0E3FFFh BIOS Extension    5Eh
PAM5[7:4] R  R     WE      RE 0E4000h ­ 0E7FFFh BIOS Extension    5Eh
PAM6[3:0] R  R     WE      RE 0E8000h ­ 0EBFFFh BIOS Extension    5Fh
PAM6[7:4] R  R     WE      RE 0EC000h ­ 0EFFFFh BIOS Extension    5Fh

Do we have or want a general LinuxBIOS-wide policy as to how to set the
PAM registers? Or is this chipset-/mainboard-specific?

IMO we should make sure that ADLO can be used on _all_ boards. It's no
problem to have a config option and a reasonable default, but there
should definately be a possibility for the "end user" to easily use ADLO
without having to touch the source code.

Uwe.

[Stefan Reinauer]

* Uwe Hermann  [070619 10:36]:
> > Yes. ADLO.
>
> OK, so we'll have to take care about that.
>
> Which settings does ADLO require/expect?

so far ADLO has to do it all on its own, since it has to change those
settings during its runtime.
> Do we have or want a general LinuxBIOS-wide policy as to how to set the
> PAM registers? Or is this chipset-/mainboard-specific?

We need an interface to ADLO, preferably an LB table entry describing
how ADLO can change the settings.

Or we make 0xf0000-0xfffff writable and hope nobody will mess with it.
No idea whether that works reliably
> IMO we should make sure that ADLO can be used on _all_ boards. It's no
> problem to have a config option and a reasonable default, but there
> should definately be a possibility for the "end user" to easily use ADLO
> without having to touch the source code.

Yes. The problem with ADLO seems to be it is not even capable of booting
Windows 2000 in Qemu+LBv2 yet. So progress is sneaking

[Corey Osgood]

Patch description, long version:
This patch comments out the code to set up the vga framebuffer to allow
the system to boot, without this fix the system hangs during elfboot.
The only line that is absolutely necessary to change is the SMRAM setup,
however I've commented out all vga setup to make it very obvious to both
the kernel/payload and anyone looking at the code that vga isn't
currently working. This setup might also be better handled in
northbridge.c, if it doesn't need to be done before ram init, yet
another reason to comment it all. In the future, LinuxBIOS needs to be
told that the graphics memory area, 1mb or 512kb (at the user or
developer's option), is reserved for the onchip vga, but I'm not sure if
it's taken at the top or bottom of the memory, yet. LB may also need to
set a base address for the AGP aperture and/or be told that range is
reserved as well, whether this was originally the job of the system bios
or vga bios is still a mystery. It also corrects the number of entries
in irq_tables.c, without this fix the kernel would probably complain and
hang due to unmapped IRQs.

Uwe Hermann wrote:
> On Mon, Jun 18, 2007 at 01:52:35PM -0400, Corey Osgood wrote:
> > This patch fixes up a couple mistakes I made with the i82810 and mew-vw to make
> > the system boot to a command line.
> >
> > Signed-off-by: Corey Osgood
>
> Looks commitable, but as Peter said, please describe what was fixed why,
> and how. What was the settings which prevented a successful boot?
> The IRQ Table thing (IRQ_SLOT_COUNT) or the AGP settings, or both?

See above. I'm not quite sure if the IRQ_SLOT_COUNT thing would have
caused drastic system failure, but I'm 90% sure that it's right now and
have no desire to test the effects of a wrong value, especially with the
hassle it takes to flash this board ;) Which reminds me, as usual with
an Asus board, flashrom doesn't work, uniflash does though. This might
want to be noted in the wiki, and the note on the LPC47B272 can be
removed. I tested the keyboard last night and it works, I'm just going
to assume the rest does as well.
> > Index: src/mainboard/asus/mew-vm/Options.lb
> >
> > --- src/mainboard/asus/mew-vm/Options.lb	(revision 2724)
> > +++ src/mainboard/asus/mew-vm/Options.lb	(working copy)
> > @@ -67,7 +67,7 @@
> >  ## Build code to export a programmable irq routing table
> >  ##
> >  default HAVE_PIRQ_TABLE = 1
> > -default IRQ_SLOT_COUNT = 4
> > +default IRQ_SLOT_COUNT = 11
>
> Is this value correct? Did you copy the irq_tables.c file from some
> other target or was it generated by getpir or did you create it
> manually?

The IRQ tables were generated with get_pir.c on this board, and don't
work exactly correctly (see boot log) but do get it to boot. The number
4 was thrown in as an arbitrary number (before I'd even generated the
tables), 11 should be correct, but I only assume this from looking at
other supported boards.

BTW, booting with irqpoll hangs the system, booting without it works
(with the Core Linux 2.6.21.1 kernel). The dma kernel options were only
to attempt to work around my stupid CF adapter, and thankfully work,
which they don't with the stock debian kernel. OTOH, Core uses grub2,
which FILO apparently doesn't understand. I created a grub-style
menu.lst, but FILO seems to (I haven't looked at the source) rely on
some part of the installed grub that isn't compatible with grub2. FILO's
autoboot function works fine though, which surprised me because I
couldn't get it to compile on this machine a month ago (??)
</rambling>
> > pci_write_config8(ctrl->d0, PAM, 0x00);
> > pci_write_config8(ctrl->d0, PAM, 0xff);
>
> If you do this (i.e. make all those regions "normal" RAM), I think you
> can also change northbridge.c to report the now "freed" RAM:
>             /* Report the memory regions. */
>             idx = 10;
>             ram_resource(dev, idx++, 0, 640);
>             ram_resource(dev, idx++, 768, tolmk - 768);

True, but I figure it'd be better to read that register and then figure
out at runtime if those regions are usable as normal memory, in case
they do get changed in the future for someone using ADLO, etc. It's on
my todo list, but not yet the top of it, there's a lot of other things
to worry about first. For the moment, I see no reason to worry about a
couple hundred kb of memory on a base development system with 128mb,
this just basically says that that memory doesn't need to be reserved
for a FILO/Linux payload.
> > Uhhuh. NMI received for unknown reason 31 on CPU 0.
> > Do you have a strange power saving mode enabled?
> > Dazed and confused, but trying to continue
>
> Oh yeah, kernel messages are really funny sometimes :-)

Yeah, I had a chuckle at that too. I'm wondering why it's showing up,
possibly (IO)APIC on a uniprocessor system, but I'm very tempted not to
go messing with things, since it does seem to work okay and doesn't
create a hang or anything.

So, have you mooed today?

-Corey

[Joseph Smith]

Quoting Corey Osgood :
> Patch description, long version:
> This patch comments out the code to set up the vga framebuffer to allow
> the system to boot, without this fix the system hangs during elfboot.
> The only line that is absolutely necessary to change is the SMRAM setup,
> however I've commented out all vga setup to make it very obvious to both
> the kernel/payload and anyone looking at the code that vga isn't
> currently working. This setup might also be better handled in
> northbridge.c, if it doesn't need to be done before ram init, yet
> another reason to comment it all. In the future, LinuxBIOS needs to be
> told that the graphics memory area, 1mb or 512kb (at the user or
> developer's option), is reserved for the onchip vga, but I'm not sure if
> it's taken at the top or bottom of the memory, yet. LB may also need to
> set a base address for the AGP aperture and/or be told that range is
> reserved as well, whether this was originally the job of the system bios
> or vga bios is still a mystery. It also corrects the number of entries
> in irq_tables.c, without this fix the kernel would probably complain and
> hang due to unmapped IRQs.

Corey,
As far as I understand you don't need to define any of the vga  
registers in the northbridge code. Intel's video bios will do all of  
this when initialized, that is if you are using onboard vga. I believe  
it may cause clocking issues if you use both. Some of the registers  
would probibly need to be set if you are using external graphics via  
PCI or AGP. Hope that helps.

Thanks - Joe

[Uwe Hermann]

On Tue, Jun 19, 2007 at 01:12:32AM -0400, Corey Osgood wrote:
> Patch description, long version:

OK, thanks, committed in r2724.
> See above. I'm not quite sure if the IRQ_SLOT_COUNT thing would have
> caused drastic system failure, but I'm 90% sure that it's right now and
> have no desire to test the effects of a wrong value, especially with the
> hassle it takes to flash this board ;) Which reminds me, as usual with
> an Asus board, flashrom doesn't work, uniflash does though. This might
> want to be noted in the wiki, and the note on the LPC47B272 can be
> removed. I tested the keyboard last night and it works, I'm just going
> to assume the rest does as well.

If you find the time, please also test the other devices managed by the
Super I/O in a running Linux system. But I agree that they'll quite
likely work...
> The IRQ tables were generated with get_pir.c on this board, and don't
> work exactly correctly (see boot log) but do get it to boot. The number
> 4 was thrown in as an arbitrary number (before I'd even generated the
> tables), 11 should be correct, but I only assume this from looking at
> other supported boards.

This number is board-specific, so looking at other boards is not
necessarily the correct thing. You can try to follow the steps in
Jürgen's HOWTO to improve/correct the table:

http://linuxbios.org/Creating_Valid_IRQ_Tables
> True, but I figure it'd be better to read that register and then figure
> out at runtime if those regions are usable as normal memory, in case
> they do get changed in the future for someone using ADLO, etc. It's on

Yep.

Uwe.