[LinuxBIOS] [PATCH] Fix i82810 to boot!

[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 <corey.osgood at gmail.com> 
>>     
>
> 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