Re: [coreboot] H8QME-2+ boot problems on different machines.
Myles Watson escribió: > > >>> I think this can be problematic, since by the time you can dump the >>> >> factory >> >>> BIOS resource allocation has already occurred. The resource map is only >>> good for early initialization, before resource allocation, right? >>> >> hmm. I had always used the bios map as a starting point and it had >> worked well for me. >> > > I think most of the time it should work fine, but we have some hard-coded > addresses where the chipset is expected to live in early setup routines, and > they might break. > > My resource map sets: > DRAM mappings for each node > MMIO mappings for each HT chain > PCI IO mappings for each HT chain > PCI Bus numbers for each HT chain > > I think they should only be needed for things like ck804_early_setup_car.c, > where I/O is being used and set up. If the mappings aren't configured the > reads and writes don't reach the chipset. > > >> But maybe things are much harder now. It is true that you need to do a bit >> of >> interpretation of the map once the factory BIOS has set it up. >> >> Does resource allocation get all the bits, even legacy ones? Are there >> not some resource map values that >> a resource allocator can not figure out? >> > > I don't know. Once resource allocation is done you should know where your > VGA card is, and where your Southbridge is. I'm probably missing something, > but I think once resource allocation is done all of the registers that are > touched in the resource map have been rewritten. > > Thanks, > Myles > > > Hi, and thx for your replies so far. For what I understand now is that the resource map is needed for early initialization work and if I'm booting my boards without one it is just luck when they work?! Furthermore I understand that I can't use setpci to dump the vendor BIOS registers once booted into Linux. Then, unfortunately, my question still remains about how to set up a correct resource map for my board? Could anyone who has done one explain how he/she did it? In the meantime I tried a different resource map from a fam10 board and it seems to work, but just because sun were shinning ?? Thanks and again sorry for all the question marks, Knut Kujat. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] H8QME-2+ boot problems on different machines.
Myles Watson escribió: > > >>> I think this can be problematic, since by the time you can dump the >>> >> factory >> >>> BIOS resource allocation has already occurred. The resource map is only >>> good for early initialization, before resource allocation, right? >>> >> hmm. I had always used the bios map as a starting point and it had >> worked well for me. >> > > I think most of the time it should work fine, but we have some hard-coded > addresses where the chipset is expected to live in early setup routines, and > they might break. > > My resource map sets: > DRAM mappings for each node > MMIO mappings for each HT chain > PCI IO mappings for each HT chain > PCI Bus numbers for each HT chain > > I think they should only be needed for things like ck804_early_setup_car.c, > where I/O is being used and set up. If the mappings aren't configured the > reads and writes don't reach the chipset. > > >> But maybe things are much harder now. It is true that you need to do a bit >> of >> interpretation of the map once the factory BIOS has set it up. >> >> Does resource allocation get all the bits, even legacy ones? Are there >> not some resource map values that >> a resource allocator can not figure out? >> > > I don't know. Once resource allocation is done you should know where your > VGA card is, and where your Southbridge is. I'm probably missing something, > but I think once resource allocation is done all of the registers that are > touched in the resource map have been rewritten. > > Thanks, > Myles > > > Sorry I forgot to add the showroutes output: For the good working CPU and the resource map adopted from H8DMR it this: After finalize_node_setup DRAM(40)00-ff, ->(0), R, W, No interleave, 0 MMIO(90)00-00, ->(0,0), , , CPU disable 0, Lock 0, Non posted 0 MMIO(98)00-00, ->(0,0), , , CPU disable 0, Lock 0, Non posted 0 MMIO(a8)00-00, ->(0,0), , , CPU disable 0, Lock 0, Non posted 0 MMIO(b8)00-033e26, ->(5,1), , , CPU disable 0, Lock 0, Non posted 1 PCIIO(c0)000-1ff, ->(0,2), , ,VGA 0 ISA 0 PCIIO(c8)000-fff, ->(0,0), , ,VGA 0 ISA 0 PCIIO(d0)000-fff, ->(0,0), , ,VGA 0 ISA 0 CONFIG(e0)00-05 ->(0,2),R W (bus numbers) AFTER setup_mb_resource DRAM(40)00-ff, ->(0), R, W, No interleave, 0 MMIO(90)00-00, ->(0,0), , , CPU disable 0, Lock 0, Non posted 0 MMIO(98)00-00, ->(0,0), , , CPU disable 0, Lock 0, Non posted 0 MMIO(a8)00-00, ->(0,0), , , CPU disable 0, Lock 0, Non posted 0 MMIO(b8)00-033e26, ->(5,1), , , CPU disable 0, Lock 0, Non posted 1 PCIIO(c0)000-1ff, ->(0,2), R, W,VGA 1 ISA 1 PCIIO(c8)000-fff, ->(0,0), , ,VGA 0 ISA 0 PCIIO(d0)000-fff, ->(0,0), , ,VGA 0 ISA 0 CONFIG(e0)00-3f ->(0,2),R W (bus numbers) And for the Not so good working CPU: After finalize_node_setup DRAM(40)00-ff, ->(0), R, W, No interleave, 0 DRAM(48)00-f800ff, ->(2), , , No interleave, 0 DRAM(50)00-26acff, ->(0), , , No interleave, 0 DRAM(58)00-a725ff, ->(4), , , No interleave, 0 DRAM(60)00-c520ff, ->(0), , , No interleave, 1 DRAM(68)00-7861ff, ->(3), , , No interleave, 3 DRAM(70)00-0c84ff, ->(1), , , No interleave, 2 DRAM(78)00-4992ff, ->(3), , , No interleave, 1 MMIO(80)00-0bf611, ->(6,0), , , CPU disable 0, Lock 0, Non posted 0 MMIO(88)00-05d30c, ->(7,1), , , CPU disable 0, Lock 0, Non posted 1 MMIO(90)00-1100b9, ->(5,2), , , CPU disable 0, Lock 0, Non posted 1 MMIO(98)00-a0d18e, ->(1,1), , , CPU disable 0, Lock 0, Non posted 0 MMIO(a0)00-584dd4, ->(2,0), , , CPU disable 0, Lock 0, Non posted 1 MMIO(a8)00-3a9903, ->(3,3), , , CPU disable 0, Lock 0, Non posted 1 MMIO(b0)00-1f36f0, ->(5,1), , , CPU disable 0, Lock 0, Non posted 0 MMIO(b8)00-9686b0, ->(1,0), , , CPU disable 0, Lock 0, Non posted 1 PCIIO(c0)000-0e20fff, ->(6,0), , ,VGA 0 ISA 0 PCIIO(c8)000-1e65fff, ->(2,2), , ,VGA 0 ISA 0 PCIIO(d0)000-0782fff, ->(4,3), , ,VGA 0 ISA 0 PCIIO(d8)000-0819fff, ->(1,1), , ,VGA 0 ISA 0 CONFIG(e0)00-05 ->(0,2),R W (bus numbers) AFTER setup_mb_resource DRAM(40)00-ff, ->(0), R, W, No interleave, 0 MMIO(80)00-00, ->(0,0), , , CPU disable 0, Lock 0, Non posted 0 MMIO(90)00-00, ->(0,0), , , CPU disable 0, Lock 0, Non posted 0 MMIO(98)00-00, ->(0,0), , , CPU disable 0, Lock 0, Non posted 0 MMIO(a0)00-00, ->(0,0), , , CPU disable 0, Lock 0, Non posted 0 MMIO(a8)00-00, ->(0,0), , , CPU disable 0, Lock 0, Non posted 0 MMIO(b0)00-00, ->(0,0), , , CPU disable 0, Lock 0, Non posted 0 MMIO(b8)00-9686b0, ->(1,0), , , CPU disable 0, Lock 0, Non posted 1 PCIIO(c0)000-1ff, ->(0,2), R, W,VGA
Re: [coreboot] H8QME-2+ boot problems on different machines.
> > My resource map sets: > > DRAM mappings for each node > > MMIO mappings for each HT chain > > PCI IO mappings for each HT chain > > PCI Bus numbers for each HT chain Since all of your devices are on the same HT chain in your devicetree.cb, a resourcemap should be pretty easy to do. DRAM - All 0, but make sure to include the correct node numbers. MMIO - All (0xc000-0x) down link 2 of node 0. PCI-IO - All (0x-0x) on link 2 of node 0 PCI Bus numbers - All on link 2 of node 0 > Hi, > and thx for your replies so far. For what I understand now is that the > resource map is needed for early initialization work and if I'm booting > my boards without one it is just luck when they work?! > Furthermore I understand that I can't use setpci to dump the vendor BIOS > registers once booted into Linux. In your case you can get most of it from Linux, just enable the whole ranges, and don't touch the DRAM registers unless you know how they interact with CAR. > Then, unfortunately, my question still > remains about how to set up a correct resource map for my board? > Could anyone who has done one explain how he/she did it? I think the process should be: 1. Look at the register values from Linux 2. Set up the registers so that there is some MMIO, PCI I/O, bus resources for each link you want to touch before device enumeration (anything named early, especially). For ck804_early... It assumes that you allocate PCI I/O resources to each link in 16K blocks. Again, since you only have one non-coherent HT link, allocating the whole range there should work fine. > In the meantime I tried a different resource map from a fam10 board and > it seems to work, but just because sun were shinning ?? Have you done showallroutes() before and after setting up your resource map? It will make it obvious why you need it on cold boot, and it could help you figure out what's missing. Try it on a working board and one that doesn't. I'd like to see the differences. It would also help to know what address range is failing on inb and outb. That would tell you which register you need to play with. Thanks, Myles -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] H8QME-2+ boot problems on different machines.
> -Original Message- > From: Knut Kujat [mailto:kn...@gap.upv.es] > Sent: Thursday, May 06, 2010 2:20 AM > To: Myles Watson > Cc: 'ron minnich'; 'coreboot' > Subject: Re: [coreboot] H8QME-2+ boot problems on different machines. > > Myles Watson escribió: > > > > > >>> I think this can be problematic, since by the time you can dump the > >>> > >> factory > >> > >>> BIOS resource allocation has already occurred. The resource map is > only > >>> good for early initialization, before resource allocation, right? > >>> > >> hmm. I had always used the bios map as a starting point and it had > >> worked well for me. > >> > > > > I think most of the time it should work fine, but we have some hard- > coded > > addresses where the chipset is expected to live in early setup routines, > and > > they might break. > > > > My resource map sets: > > DRAM mappings for each node > > MMIO mappings for each HT chain > > PCI IO mappings for each HT chain > > PCI Bus numbers for each HT chain > > > > I think they should only be needed for things like > ck804_early_setup_car.c, > > where I/O is being used and set up. If the mappings aren't configured > the > > reads and writes don't reach the chipset. > > > > > >> But maybe things are much harder now. It is true that you need to do a > bit > >> of > >> interpretation of the map once the factory BIOS has set it up. > >> > >> Does resource allocation get all the bits, even legacy ones? Are there > >> not some resource map values that > >> a resource allocator can not figure out? > >> > > > > I don't know. Once resource allocation is done you should know where > your > > VGA card is, and where your Southbridge is. I'm probably missing > something, > > but I think once resource allocation is done all of the registers that > are > > touched in the resource map have been rewritten. > > > > Thanks, > > Myles > > > > > > > Sorry I forgot to add the showroutes output: Thanks for sending it. > For the good working CPU and the resource map adopted from H8DMR it this: > AFTER setup_mb_resource > DRAM(40)00-ff, ->(0), R, W, No interleave, 0 > MMIO(90)00-00, ->(0,0), , , CPU disable 0, Lock 0, Non > posted 0 > MMIO(98)00-00, ->(0,0), , , CPU disable 0, Lock 0, Non > posted 0 > MMIO(a8)00-00, ->(0,0), , , CPU disable 0, Lock 0, Non > posted 0 > MMIO(b8)00-033e26, ->(5,1), , , CPU disable 0, Lock 0, Non > posted 1 > PCIIO(c0)000-1ff, ->(0,2), R, W,VGA 1 ISA 1 > PCIIO(c8)000-fff, ->(0,0), , ,VGA 0 ISA 0 > PCIIO(d0)000-fff, ->(0,0), , ,VGA 0 ISA 0 > CONFIG(e0)00-3f ->(0,2),R W (bus numbers) > > And for the Not so good working CPU: > AFTER setup_mb_resource > DRAM(40)00-ff, ->(0), R, W, No interleave, 0 > MMIO(80)00-00, ->(0,0), , , CPU disable 0, Lock 0, Non > posted 0 > MMIO(90)00-00, ->(0,0), , , CPU disable 0, Lock 0, Non > posted 0 > MMIO(98)00-00, ->(0,0), , , CPU disable 0, Lock 0, Non > posted 0 > MMIO(a0)00-00, ->(0,0), , , CPU disable 0, Lock 0, Non > posted 0 > MMIO(a8)00-00, ->(0,0), , , CPU disable 0, Lock 0, Non > posted 0 > MMIO(b0)00-00, ->(0,0), , , CPU disable 0, Lock 0, Non > posted 0 I wonder why all those registers show up. They shouldn't print if they're zeroed. Maybe you could print the raw register values, too. The docs are available, and most of the meanings are copied into resourcemap.c. > MMIO(b8)00-9686b0, ->(1,0), , , CPU disable 0, Lock 0, Non > posted 1 > PCIIO(c0)000-1ff, ->(0,2), R, W,VGA 1 ISA 1 > CONFIG(e0)00-3f ->(0,2),R W (bus numbers) > > Notice that I haven't switched CPU but used 2 different boards for this > capture. Were these both for a cold boot? The first one looks like a lot fewer registers changed. You could compare what happens with the other resource map that works for you. Good luck, Myles -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] H8DME-2 woes, hints?
On Wed, May 05, 2010 at 04:26:15PM -0400, Myles Watson wrote: > On Wed, May 5, 2010 at 2:06 PM, Joe Korty wrote: >> Naturally I am having troubles. I suspect that as a newbie I am probably >> doing something stupid. But then I've heard that mb manufacturers like >> to change things around without notice, so maybe I'm doing things right >> and what was once a supported mb, no longer is. > It looks like you're doing things right. It's dying really early, though. >> When booting coreboot, nothing happens for about 45 seconds. >> Then the fans speed up to high and some messages start appearing >> on the serial line. These messages print rather slowly (maybe >> 1 second/message). They are: >> >>coreboot-4.0-r5521M Wed May 5 10:53:42 EDT 2010 starting... >>*sysinfo range: [000cf000,000cf730] >>bsp_apicid=00 >>Enabling routing table for node 00 done. >>Enabling SMP settings >>(0,1) link=00 > You could try an earlier revision. I can't think of what would slow > it down that much. >> I put some printk's in setup_smb2, the crashing routine. They show >> that setup_temp_row is called by setup_smb2 but never returns. > Since it takes so long to get there, I think you'll have better luck > trying to figure out what's wrong before that. >> fgrep 'Video ROM' /proc/iomem >> # displays "000c-000cafff : Video ROM" >> sudo dd if=/dev/mem of=/tmp/vgabios.bin bs=4k skip=$((0xc0)) count=$((0xb)) >> >> # --- figure out the Video ROM's PCI Vendor,Device ID >> # --- I _think_ the numbers I want are the second set shown, ie "15d9:1611". > > You want the first set. The second set is Supermicro's board ID. Hi Myles, Thanks for the pointers. I'm going to try some earlier releases of coreboot and if I can find one that lacks the slowdown. If that fails I am going to have to figure out how to debug the earliest stages of coreboot, when nothing is visible and little can be saved. Joe -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] Dell Optiplex GX1 support
By looking at all the supported hardware, it looks like it should work at a minimum amount. It has an Intel 440BX, an Intel PIIX4e and a NSC (formerly National) PC87309. Will I be able to boot Debian and if not, how soon until whoever is working on it estimates they will have it at a working status? I am just wondering as I think it would be cool to have it on my computer. -- Cooper -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] Indtast Bcc Dell Optiplex GX1 support
Hi As you are the only one who has this board you will have to do a bit of the work your self. But I would be glad to help you, I recently ported coreboot to a 440bx board, Ubuntu boots on it so Debians should work fine. There is still a few limitations in the support for this chip. No L2 cache no ecc memory, only sdram and no ACPI. Also it looks like you won't have support for any legacy I/O (ps2 keyboard pc speaker) You could of ofcourse fix all this by reading the docs an coding a bit of C :) -Anders - Reply message - Fra: "Cooper Harrison" Dato: tor., maj 6, 2010 14:04 Emne: [coreboot] Dell Optiplex GX1 support Til: -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] [commit] r5527 - trunk/src/mainboard/tyan/s2912_fam10
Author: oxygene Date: Thu May 6 21:32:12 2010 New Revision: 5527 URL: https://tracker.coreboot.org/trac/coreboot/changeset/5527 Log: Remove duplicate Kconfig entry. Trivial. Signed-off-by: Patrick Georgi Acked-by: Patrick Georgi Modified: trunk/src/mainboard/tyan/s2912_fam10/Kconfig Modified: trunk/src/mainboard/tyan/s2912_fam10/Kconfig == --- trunk/src/mainboard/tyan/s2912_fam10/KconfigWed May 5 15:13:47 2010(r5526) +++ trunk/src/mainboard/tyan/s2912_fam10/KconfigThu May 6 21:32:12 2010(r5527) @@ -112,11 +112,6 @@ default "mc_patch_0195.h" depends on BOARD_TYAN_S2912_FAM10 -config SERIAL_CPU_INIT - bool - default n - depends on BOARD_TYAN_S2912_FAM10 - config RAMBASE hex default 0x20 -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] H8QME-2+ boot problems on different machines.
>> And for the Not so good working CPU: >> AFTER setup_mb_resource >> DRAM(40)00-ff, ->(0), R, W, No interleave, 0 >> MMIO(80)00-00, ->(0,0), , , CPU disable 0, Lock 0, Non >> posted 0 >> MMIO(90)00-00, ->(0,0), , , CPU disable 0, Lock 0, Non >> posted 0 >> MMIO(98)00-00, ->(0,0), , , CPU disable 0, Lock 0, Non >> posted 0 >> MMIO(a0)00-00, ->(0,0), , , CPU disable 0, Lock 0, Non >> posted 0 >> MMIO(a8)00-00, ->(0,0), , , CPU disable 0, Lock 0, Non >> posted 0 >> MMIO(b0)00-00, ->(0,0), , , CPU disable 0, Lock 0, Non >> posted 0 > I wonder why all those registers show up. They shouldn't print if they're > zeroed. Maybe you could print the raw register values, too. The docs are > available, and most of the meanings are copied into resourcemap.c. It looks like your resourcemap.c is for k8, not fam10. There's an extra bit in fam10 that controls ganged links. Since it's listed as reserved in your resource map, it should never get cleared, which could cause you problems, but only sporadically (depending on how that bit floats). That's probably the reason all the 0 registers show up. Thanks, Myles -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] PATCH: model_6bx CPUs can go in a lot of places
Hi all, Intel model 6bx CPUs (specifically 6B1 and 6B4) can end up in a lot of places, specifically Slot 1 and Socket 370. Ever since references to them were removed from cpu/intel/model_6xx my coreboot would die when initializing CPU with a "Unknown cpu" error. This patch fixes it by adding references to model_6bx to cpu/intel/slot_1 and cpu/intel/socket_PGA370. Also included are before and after boot logs with relevant sections highlighted. Before boot log: http://coreboot.pastebin.com/CGWgihaG After boot log: http://coreboot.pastebin.com/GLgnpZT6 Signed-off-by: Keith Hui - Begin patch - Index: src/cpu/intel/slot_1/Makefile.inc === --- src/cpu/intel/slot_1/Makefile.inc (revision 5527) +++ src/cpu/intel/slot_1/Makefile.inc (working copy) @@ -20,6 +20,7 @@ obj-y += slot_1.o subdirs-y += ../model_6xx +subdirs-y += ../model_6bx subdirs-y += ../../x86/tsc subdirs-y += ../../x86/mtrr subdirs-y += ../../x86/lapic Index: src/cpu/intel/socket_PGA370/Makefile.inc === --- src/cpu/intel/socket_PGA370/Makefile.inc(revision 5527) +++ src/cpu/intel/socket_PGA370/Makefile.inc(working copy) @@ -20,6 +20,7 @@ obj-y += socket_PGA370.o subdirs-y += ../model_6xx +subdirs-y += ../model_6bx subdirs-y += ../../x86/tsc subdirs-y += ../../x86/mtrr subdirs-y += ../../x86/lapic - End patch - -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
