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@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