[coreboot] news about coreboot llano Fudzilla.com
Hi everyone, FYI: http://www.fudzilla.com/processors/item/22677-amd-to-use-coreboot-in-llano-other-upcoming-parts Bye, Knut Kujat. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] HTX (FPGA) device needs more time for initialization but HOW?
Hi, my version of coreboot (on Supermicro H8QME-2+) is working just fabulous but now I have a little issue. I have a HTX board with a FPGA on it which needs to boot with coreboot on the motherboard. The problem is that it fails to boot most of the time because it doesn't had time to initialize itself properly. I know that because at HT non coherent device initialization it marks bit 1(InitComplete) in the link type register of the device as 0. What I tried to do is to hard_reset() every time it fails but with no luck. I did that because after a power cycle the card seems to have enough time to initialize and the boot process completes successfully. I read in the maillist (http://www.mail-archive.com/coreboot@coreboot.org/msg01089.html) of a similar problem but with no solution published at the end :(. So is there any way how I could delay the whole initialization process to give the card more time? Thanks in advanced, Knut Kujat. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] HTX (FPGA) device needs more time for initialization butHOW?
Myles Watson escribió: my version of coreboot (on Supermicro H8QME-2+) is working just fabulous but now I have a little issue. I have a HTX board with a FPGA on it which needs to boot with coreboot on the motherboard. The problem is that it fails to boot most of the time because it doesn't had time to initialize itself properly. I know that because at HT non coherent device initialization it marks bit 1(InitComplete) in the link type register of the device as 0. What I tried to do is to hard_reset() every time it fails but with no luck. I did that because after a power cycle the card seems to have enough time to initialize and the boot process completes successfully. Doing a hard reset works for me here. I'm surprised that power cycling the machine works. That doesn't work for me. I always figured that it was because on a warm hard reset the power and clocks were already stable. By power cycling I mean one of those where you plug the cable in again and the board becomes alive immediately without any need of pushing the power button. After cycling you need to push the button it fails also. So is there any way how I could delay the whole initialization process to give the card more time? By the time software gets control, it's too late. The HT links are already initialized. That was kind of I thought it would work without being completely sure. But now my question is if it is possible to reset the initialization by software and try to delay it then? From your FPGA, you should be able to delay it if your clock is stable and you can have CAD driven high and CTL driven low. Initialization shouldn't start until you raise CTL. Don't know much about that FPGA because I'm not working on/with it. But the main idea is to modify coreboot to not to modify the FPGA. Thanks, Myles Kind regards, Knut Kujat. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [h8dme-fam10] acquiring coreboot skills from scratch somewhat daunting
Myles Watson escribió: On Thu, Jun 10, 2010 at 7:38 AM, Joe Korty joe.ko...@ccur.com wrote: Hi, As a learning experience, I've been trying to port coreboot to the supermicro h8dme-2 w/ AMD K10. Ward and others have tried this board in the past. There seems to be something wrong with multi-core setup for K10. I think that why Ward had problems with this CPU family is for the same reason why I had problems with it on different boards, the resource map! I started using the one from the h8dme fam 10 board. So maybe you should try another resource map from another fam 10 board. bye! If you search the mailing list for h8dme fam10, it might give you some help. I would disable all the other processors until you get the board working. CONFIG_LOGICAL_CPUS 0 CONFIG_SMP 0 CONFIG_MAX_PHYSICAL_CPUS 1 I started with the h8dmr_fam10 port since the h8dmr is identical, spec-wise, to the h8dme except that it has half the number of dimm slots. Also there is both K8 and K10 versions of coreboot for the h8dmr which in principle makes the study of the differences a good way to learn coreboot internals. I agree that's a good approach. K8 and fam10 code are pretty similar, though they could be made even more similar. In any case I have not been able to find where the info in spd_addr.h comes from, so I have not been able to make it correct for my board. How does one construct this table? In general, how does one construct devicetree.cb and the other tables from scratch? I don't know that anyone does it from scratch. The idea is to make the devicetree as minimal as possible. That usually means including the processor and configuring the southbridge buses. The rest can usually be found. Is there an apprenticeship program somewhere, perhaps at some conference? I don't know. There have been some talks and short tutorials, but I haven't heard of an official training program. How do people in general get their coreboot skill-set jump-started? IRC and the mailing list is what I've heard most. I've used the mailing list. Qemu and SimNOW are both helpful, too. SimNOW exhibits the same problems for fam10 as hardware (super slow initialization and problems with logical CPUs), so fixing it there would probably help. Thanks, Myles -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] gPXE not found?!
Hi, using genroms/gpxe.rom makes gPXE start but then gPXE isn't able to find the network devices. When I'm using the vendor and device id (pci8086,1079.rom) Seabios doesn't map that option rom to the NICs because Seabios doesn't see them! (please see attached log) What can I do? to scan also 0a:03.0 and 0a:03.1, which would be my NICs? Thanks, Knut Kujat. Knut Kujat escribió: Hi and thanks everyone gPXE finally starts changing the 8086 1076 to a 8086 1079 (Monday you know :S) and using genroms/gpxe.rom Thanks again, Knut Kujat. Kevin O'Connor escribió: On Mon, May 17, 2010 at 06:29:33PM +0200, Knut Kujat wrote: Hi, I was asked to add PXE support to the BIOS so I'm trying Seabios in combination with gPXE, I add a gPXE rom (build from the rom-o-matic page) and add it via cbfstool to the coreboot.rom file: [...] Start bios (version pre-0.5.1-20100517_180539-pcq.gap.upv.es) You've got an old version of SeaBIOS. Please grab the latest - see: http://www.coreboot.org/SeaBIOS [...] Scan for VGA option rom Running option rom at c000:0003 [...] Scan for option roms Press F12 for boot menu. SeaBIOS found and loaded your VGA option rom, but didn't load any other option roms. Please make sure the id in the CBFS filename matches the device (or, use a filename like genroms/gpxe.rom instead). -Kevin Timeout waiting for keyboard after reset. Start bios (version 0.6.0-20100518_183559-pcq.gap.upv.es) init ivt init bda Find memory size Attempting to find coreboot table Found coreboot table forwarder. Now attempting to find coreboot memory map Found mainboard Supermicro H8QME-2+ (Fam10) Found CBFS header at 0xf8da Ram Size=0xe000 (0x00012000 high) malloc setup init pic init timer tsc calibrate start=2619949234 end=2623382628 diff=3433394 CPU Mhz=2000 math cp init Found 16 cpu(s) max supported 16 cpu(s) init bios32 init PMM init PNPBIOS table init keyboard init mouse Relocating coreboot bios tables Copying PIR from 0x7fff0400 to 0x000f7290 Copying MPTABLE from 0x7fff1400/7fff1410 to 0x000f6f10 init SMBIOS tables SMBIOS ptr=0x000f6ef0 table=0xdc50 Scan for VGA option rom Attempting to init PCI bdf 01:01.0 (dev/ven 515e1002) Searching CBFS for prefix pci1002,515e.rom Found CBFS file fallback/romstage Found CBFS file fallback/coreboot_ram Found CBFS file fallback/payload Found CBFS file pci1002,515e.rom Copying data 45...@0xfff347b8 to 172...@0x000c Checking rom 0x000c (sig aa55 size 88) Running option rom at c000:0003 handle_hwpic1 irq=1 handle_hwpic1 irq=1 handle_hwpic1 irq=1 Searching CBFS for prefix vgaroms/ Found CBFS file fallback/romstage Found CBFS file fallback/coreboot_ram Found CBFS file fallback/payload Found CBFS file pci1002,515e.rom Found CBFS file pci8086,1079.rom Found CBFS file Turning on vga console handle_hwpic1 irq=1 Starting SeaBIOS (version 0.6.0-20100518_183559-pcq.gap.upv.es) init usb EHCI init on dev 00:03.1 (regs=0xfc145020) /dffe6000\ Start thread /dffe4000\ Start thread init ps2port /dffe2000\ Start thread |dffe2000| i8042 ctr old=30 new=30 /dffe\ Start thread \dffe4000/ End thread init lpt Found 0 lpt ports init serial Found 1 serial ports init boot device ordering init floppy drives init hard drives ATA controller 0 at 1f0/3f4/0 (irq 14 dev 28) /dffde000\ Start thread |dffde000| powerup iobase=1f0 st=7f |dffde000| powerup iobase=1f0 st=20 |dffde000| ata_detect ata0-0: sc=2a sn=2a dh=20 |dffde000| powerup iobase=1f0 st=2a |dffde000| powerup iobase=1f0 st=0 |dffde000| ata_detect ata0-1: sc=55 sn=aa dh=b0 |dffde000| ata_reset drive=0xdffdef94 /dffdc000\ Start thread \dffe/ End thread ATA controller 1 at 170/374/0 (irq 15 dev 28) /dffda000\ Start thread |dffda000| powerup IDE floating |dffda000| powerup IDE floating |dffda000| ata_detect ata1-0: sc=ff sn=ff dh=ff |dffda000| powerup IDE floating |dffda000| powerup IDE floating |dffda000| ata_detect ata1-1: sc=ff sn=ff dh=ff \dffda000/ End thread |dffde000| ata_reset exit status=0 /dffda000\ Start thread \dffdc000/ End thread ATA controller 2 at 2cc0/2cf0/0 (irq 0 dev 30) /dffd8000\ Start thread |dffd8000| powerup iobase=2cc0 st=50 |dffd8000| powerup iobase=2cc0 st=50 |dffd8000| ata_detect ata2-0: sc=55 sn=aa dh=a0 |dffd8000| ata_reset drive=0xdffd8f94 /dffd6000\ Start thread \dffda000/ End thread ATA controller 3 at 2cc8/2cf4/0 (irq 0 dev 30) /dffd4000\ Start thread |dffd4000| powerup iobase=2cc8 st=7f |dffd4000| powerup iobase=2cc8 st=7f |dffd4000| ata_detect ata3-0: sc=ff sn=ff dh=ff |dffd4000| powerup iobase=2cc8 st=7f |dffd4000| powerup iobase=2cc8 st=7f |dffd4000| ata_detect ata3-1: sc=ff sn=ff dh=ff \dffd4000/ End thread |dffd8000| ata_reset exit status=50 |dffde000| ata0-1: MATSHITADVD-ROM SR-8178 ATAPI-5 CD-Rom/DVD-Rom |dffde000| Mapping cd drive 0x000f6e50 |dffde000| ata_detect resetresult=4f00 \dffde000/ End thread |dffe2000| i8042 ctr old=30 new
Re: [coreboot] gPXE not found?!
Hello, #define CONFIG_PCI_ROOT1 0x0a worked just fine, perfect you could say :). Everything working now like it should! Thanks again and again Bye, Knut Kujat Myles Watson escribió: On Wed, May 19, 2010 at 7:20 AM, Stefan Reinauer stefan.reina...@coresystems.de wrote: Knut, try putting the southbridge on bus 0 I think it is already there, but there is also an 8132 at bus 8. using genroms/gpxe.rom makes gPXE start but then gPXE isn't able to find the network devices. When I'm using the vendor and device id (pci8086,1079.rom) Seabios doesn't map that option rom to the NICs because Seabios doesn't see them! (please see attached log) What can I do? to scan also 0a:03.0 and 0a:03.1, which would be my NICs? Have you tried adding the root bus 0x0a to config.h? I should have said bus 8. From your lspci: -+-[:08]-+-01.0-[09]-- | +-01.1 Advanced Micro Devices [AMD] AMD-8132 PCI-X IOAPIC [1022:7459] | +-02.0-[0a]--+-03.0 Intel Corporation 82546GB Gigabit Ethernet Controller [8086:1079] | |\-03.1 Intel Corporation 82546GB Gigabit Ethernet Controller [8086:1079] | \-02.1 Advanced Micro Devices [AMD] AMD-8132 PCI-X IOAPIC [1022:7459] If that lspci doesn't match the enumeration that Coreboot gives it, use the one that matches your boot logs. Thanks, Myles -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] gPXE not found?!
Hi and thanks everyone gPXE finally starts changing the 8086 1076 to a 8086 1079 (Monday you know :S) and using genroms/gpxe.rom Thanks again, Knut Kujat. Kevin O'Connor escribió: On Mon, May 17, 2010 at 06:29:33PM +0200, Knut Kujat wrote: Hi, I was asked to add PXE support to the BIOS so I'm trying Seabios in combination with gPXE, I add a gPXE rom (build from the rom-o-matic page) and add it via cbfstool to the coreboot.rom file: [...] Start bios (version pre-0.5.1-20100517_180539-pcq.gap.upv.es) You've got an old version of SeaBIOS. Please grab the latest - see: http://www.coreboot.org/SeaBIOS [...] Scan for VGA option rom Running option rom at c000:0003 [...] Scan for option roms Press F12 for boot menu. SeaBIOS found and loaded your VGA option rom, but didn't load any other option roms. Please make sure the id in the CBFS filename matches the device (or, use a filename like genroms/gpxe.rom instead). -Kevin -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] H8QME 128GB RAM not Booting
Myles Watson escribió: I steal one of the 8GB dimms and put it on one of my test machines I configured coreboot to only initialize one CPU/CORE and therefore only the 8GB. Booting with this configuration leads to the same result as on the 128GB machine it hangs at the first memcopy it finds so the problem seem to be the dimm itself but it is still DDR 2. I'm glad you could narrow it down. I would expect that no one had tested the code with 8GB dimms, so maybe you should be looking for a math/logic error (or just missing code) in the sizing or initialization? I attached the showroutes and dumpmem outputs. raminit_amdmct() 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(a8)00-00, -(0,0), , , CPU disable 0, Lock 0, Non posted 0 MMIO(b8)00fc00-00, -(0,0), , , CPU disable 0, Lock 0, Non posted 0 This is wrong, but shouldn't affect this problem. Your buses and I/O are on node 0 link 2, but your MMIO is on node 0 link 0. 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-ff -(0,2),R W (bus numbers) raminit_amdmct begin: DCTInit_D: mct_DIMMPresence Done DCTInit_D: mct_SPDCalcWidth Done DCTInit_D: mct_DIMMPresence Done DCTInit_D: mct_SPDCalcWidth Done DCTInit_D: AutoCycTiming_D Done DCTInit_D: AutoConfig_D Done DCTInit_D: PlatformSpec_D Done DCTInit_D: StartupDCT_D Node: 00 base: 00 limit: 7f BottomIO: e0 limit 7f = 2 GB of RAM. raminit_amdmct end: *** Yes, the copy/decompress is taking a while, FIXME! v_esp=000cbf18 testx = 5a5a5a5a dump_mem: 000c8000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 I think the other end of the stack would be more interesting. Something like 0xcbf00-0xcc000 (CAR). Then you could dump the RAM for the stack too. I guess since you know it's not working, seeing the values wouldn't really help. I'd try looking at the values you see in raminit, and why the dimm isn't getting initialized correctly. Thanks, Myles Hello, I tested the ram and got: aminit_amdmct end: Testing DRAM : 0010 - 07ff DRAM fill: 0x0010-0x07ff 0010 0020 0030 0040 0050 0060 0070 0080 0090 00a0 00b0 00c0 00d0 00e0 00f0 0100 0110 0120 0130 0140 0150 0160 0170 0180 0190 01a0 01b0 01c0 01d0 01e0 01f0 0200 0210 0220 0230 0240 0250 0260 0270 0280 0290 02a0 02b0 02c0 02d0 02e0 02f0 0300 0310 0320 0330 0340 0350 0360 0370 0380 0390 03a0 03b0 03c0 03d0 03e0 03f0 0400 0410 0420 0430 0440 0450 0460 0470 0480 0490 04a0 04b0 04c0 04d0 04e0 04f0 0500 0510 0520 0530 0540 0550 0560 0570 0580 0590 05a0 05b0 05c0 05d0 05e0 05f0 0600 0610 0620 0630 0640 0650 0660 0670 0680 0690 06a0 06b0 06c0 06d0 06e0 06f0 0700 0710 0720 0730 0740 0750 0760 0770 0780 0790 07a0 07b0 07c0 07d0 07e0 07f0 0800 DRAM filled DRAM verify: 0x0010-0x07ff 0010 Fail: @0x00100040 Read value=0x00114040 Fail: @0x00100044 Read value=0x00114044 Fail: @0x00100048 Read value=0x00114048 Fail: @0x0010004c Read value=0x0011404c Fail: @0x00100050 Read value=0x00114050 ... Fail: @0x00100434 Read value=0x00114434 Fail: @0x00100438 Read value=0x00114438 Fail: @0x0010043c Read value=0x0011443c Fail: @0x00100440 Read value=0x00114440 Aborting. 00100440 DRAM did _NOT_ verify! DRAM ERROR is anyone able to interpret something out of this which could help me :P because I can't except for the fact that it's failing. Thanks and bye, Knut Kujat. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] gPXE not found?!
Hi, I was asked to add PXE support to the BIOS so I'm trying Seabios in combination with gPXE, I add a gPXE rom (build from the rom-o-matic page) and add it via cbfstool to the coreboot.rom file: Name Offset Type Size fallback/romstage 0x0 stage81096 fallback/coreboot_ram 0x13d00stage43730 fallback/payload0x1e840payload 34069 pci1002,515e.rom 0x26dc0optionrom45056 pci8086,1076.rom 0x31e00unknown 72704 0x43a40 null 769650 where 1002,515e is the VGA rom and 8086,1076 is the gPXE rom. Now I'm not quite sure what I should expect when booting but to me it seems that gPXE is not executing (see log), it starts directly to boot from the disk. Shouldn't gPXE try to get a IP from the DHCP server etc...? Could someone please tell me what I'm missing? Thanks, Knut Kujat. set power on after power fail RTC Init Invalid CMOS LB checksum enabling HPET @0xfed0 PNP: 002e.2 init PNP: 002e.5 init Keyboard init... Keyboard controller output buffer result timeout Timeout waiting for keyboard after reset. PNP: 002e.b init PCI: 00:02.1 init PCI: 00:03.1 init PCI: 00:05.0 init IDE0 Check CBFS header at f8da magic is 4f524243 Found CBFS header at f8da Check fallback/romstage CBFS: follow chain: fff0 + 38 + 13cc8 + align - fff13d00 Check fallback/coreboot_ram CBFS: follow chain: fff13d00 + 38 + aad2 + align - fff1e840 Check fallback/payload CBFS: follow chain: fff1e840 + 38 + 8515 + align - fff26dc0 Check pci1002,515e.rom CBFS: follow chain: fff26dc0 + 38 + b000 + align - fff31e00 Check pci8086,1076.rom CBFS: follow chain: fff31e00 + 38 + 11c00 + align - fff43a40 Check CBFS: follow chain: fff43a40 + 28 + bbe72 + align - f900 CBFS: Could not find file pci10de,036e.rom PCI: 00:06.0 init SATA S SATA P PCI: 00:06.1 init SATA S SATA P PCI: 00:06.2 init SATA S SATA P PCI: 00:0b.0 init PCI: 00:0c.0 init PCI: 00:0d.0 init PCI: 00:0e.0 init PCI: 00:0f.0 init PCI: 00:10.0 init PCI: 00:18.1 init Check CBFS header at f8da magic is 4f524243 Found CBFS header at f8da Check fallback/romstage CBFS: follow chain: fff0 + 38 + 13cc8 + align - fff13d00 Check fallback/coreboot_ram CBFS: follow chain: fff13d00 + 38 + aad2 + align - fff1e840 Check fallback/payload CBFS: follow chain: fff1e840 + 38 + 8515 + align - fff26dc0 Check pci1002,515e.rom CBFS: follow chain: fff26dc0 + 38 + b000 + align - fff31e00 Check pci8086,1076.rom CBFS: follow chain: fff31e00 + 38 + 11c00 + align - fff43a40 Check CBFS: follow chain: fff43a40 + 28 + bbe72 + align - f900 CBFS: Could not find file pci1022,1201.rom PCI: 00:18.2 init Check CBFS header at f8da magic is 4f524243 Found CBFS header at f8da Check fallback/romstage CBFS: follow chain: fff0 + 38 + 13cc8 + align - fff13d00 Check fallback/coreboot_ram CBFS: follow chain: fff13d00 + 38 + aad2 + align - fff1e840 Check fallback/payload CBFS: follow chain: fff1e840 + 38 + 8515 + align - fff26dc0 Check pci1002,515e.rom CBFS: follow chain: fff26dc0 + 38 + b000 + align - fff31e00 Check pci8086,1076.rom CBFS: follow chain: fff31e00 + 38 + 11c00 + align - fff43a40 Check CBFS: follow chain: fff43a40 + 28 + bbe72 + align - f900 CBFS: Could not find file pci1022,1202.rom PCI: 00:18.3 init NB: Function 3 Misc Control.. done. PCI: 00:18.4 init Check CBFS header at f8da magic is 4f524243 Found CBFS header at f8da Check fallback/romstage CBFS: follow chain: fff0 + 38 + 13cc8 + align - fff13d00 Check fallback/coreboot_ram CBFS: follow chain: fff13d00 + 38 + aad2 + align - fff1e840 Check fallback/payload CBFS: follow chain: fff1e840 + 38 + 8515 + align - fff26dc0 Check pci1002,515e.rom CBFS: follow chain: fff26dc0 + 38 + b000 + align - fff31e00 Check pci8086,1076.rom CBFS: follow chain: fff31e00 + 38 + 11c00 + align - fff43a40 Check CBFS: follow chain: fff43a40 + 28 + bbe72 + align - f900 CBFS: Could not find file pci1022,1204.rom PCI: 00:19.0 init PCI: 08:01.1 init Check CBFS header at f8da magic is 4f524243 Found CBFS header at f8da Check fallback/romstage CBFS: follow chain: fff0 + 38 + 13cc8 + align - fff13d00 Check fallback/coreboot_ram CBFS: follow chain: fff13d00 + 38 + aad2 + align - fff1e840 Check fallback/payload CBFS: follow chain: fff1e840 + 38 + 8515 + align - fff26dc0 Check pci1002,515e.rom CBFS: follow chain: fff26dc0 + 38 + b000 + align - fff31e00 Check pci8086,1076.rom CBFS: follow chain: fff31e00 + 38 + 11c00 + align - fff43a40 Check CBFS: follow chain: fff43a40 + 28 + bbe72 + align - f900 CBFS: Could not find file pci1022,7459.rom PCI: 0a:03.0 init Check CBFS header at f8da magic is 4f524243 Found CBFS header at f8da Check fallback/romstage CBFS: follow chain: fff0 + 38 + 13cc8 + align - fff13d00 Check fallback/coreboot_ram CBFS
Re: [coreboot] H8QME 128GB RAM not Booting
00 00 00 00 00 00 00 00 00 000c8360: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 000c8370: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 000c8380: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 000c8390: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 000c83a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 000c83b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 000c83c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 000c83d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 000c83e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 000c83f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Copying data from cache to RAM -- switching to use RAM as stack... Thanks, Knut Kujat. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] H8QME 128GB RAM not Booting
Hi, I have a board here with 128GB Ram (16*8GB) and it won't boot. It hangs at Copying data from cache to RAM -- switching to use RAM as stack So at least ram initialization is done, but why does it stop booting? Some values I have to increment in order to use more RAM? Thanks, 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 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.
for this capture. thanks and bye, Knut Kujat. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] H8QME-2+ boot problems on different machines.
Hi, I finally got it working, but I don't like my solution! I noticed that after setup_mb_resource_map(); the board hang at outb and inl instructions. So I commented it out to see how far this will bring me. For my surprise the board booted right into Linux without further problems. Now my questions are: - I now know that my resource map must be some kind of faulty. But why does it work on one CPU and doesn't on another, complete identical, one? - How do i manage to correct my resource map? Or how do I create a good resource map? - Since it seems to boot fine without resource map. Do I really need one? - And the last one, If I don't setup the res. map, who does it? Thanks and sorry for the whole bunch of questions, Knut Kujat. Knut Kujat escribió: Marc Jones escribió: On Sun, May 2, 2010 at 4:59 PM, Rudolf Marek r.ma...@assembler.cz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, There is a plenty of bugs as in all modern CPUs ;) http://support.amd.com/us/Processor_TechDocs/41322.pdf Quick look to coreboot shows they are not handled? Some are easy to fix just to set some MSR, some are microcode fixes. That Fam10 bugs should be handled in cpuSetAMDMSR as well as the microcode. If it is a race condition, it should pass CONFIG_LOGICAL_CPUS = 0. Marc Hi, thx for your comments. I already set Config_Logical_CPUS = 0 and set physical and logical CPUs to 1. This gets me a little further but still hangs before warm reset. As I already set I have the exact same problem as Ward reported some time ago. Thanks, Knut Kujat. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] H8QME-2+ boot problems on different machines.
Marc Jones escribió: On Sun, May 2, 2010 at 4:59 PM, Rudolf Marek r.ma...@assembler.cz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, There is a plenty of bugs as in all modern CPUs ;) http://support.amd.com/us/Processor_TechDocs/41322.pdf Quick look to coreboot shows they are not handled? Some are easy to fix just to set some MSR, some are microcode fixes. That Fam10 bugs should be handled in cpuSetAMDMSR as well as the microcode. If it is a race condition, it should pass CONFIG_LOGICAL_CPUS = 0. Marc Hi, thx for your comments. I already set Config_Logical_CPUS = 0 and set physical and logical CPUs to 1. This gets me a little further but still hangs before warm reset. As I already set I have the exact same problem as Ward reported some time ago. Thanks, Knut Kujat. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] H8QME-2+ boot problems on different machines.
Hi, I now know that I'm having the same trouble Ward had with his h8dme board: http://www.mail-archive.com/coreboot@coreboot.org/msg20923.html Could anyone tell if and how he solved his problem? Thanks, Knut Kujat. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] H8QME-2+ boot problems on different machines.
Hi, We 64 identical machines here for now I only tried to boot coreboot on 11 of them where 4 of them got this early hang. I switched the bootstrap processor from a machine that fails and put it into one that always boots with coreboot, now the machine which was failing before now boots perfectly and the other fails. Conclusion: Its the CPU!! All machines here came with the B2 revision of the Opteron 8350 which has this weird TLB failure but we also have B3 revision processors here, so I installed a newer one and coreboot refuses to boot as well! :( So the question is what could possibly be the difference between an Opteron 8350 B2 and another Opteron 8350 B2? I started to dump registers, and I'm not done yet, but so far they are all identical. Ward Vandewege escribió: Hi Knut, On Fri, Apr 30, 2010 at 10:29:59AM +0200, Knut Kujat wrote: I now know that I'm having the same trouble Ward had with his h8dme board: http://www.mail-archive.com/coreboot@coreboot.org/msg20923.html Could anyone tell if and how he solved his problem? I have not. Unfortunately, I have had very little time for coreboot in the past few months, but I do still need fam10 support for h8dme - we have bunch of those machines that I need to upgrade to coreboot. It's odd that you are seeing this only on some machines. I only have one h8dme test box; the others are in production. I have this problem 100% of the time on my test box. Perhaps figuring out why the problem occurs on only some of your machines would give a clue as to what could be going wrong? Does it consistently happen on the machines where you see the hangs? And never on the others? And the hardware is identical? I have machines which boot with coreboot but after 4-5 tries (and when not booting they hang at the same spot), then I have machines that boots without any problem and directly and others which don't even after 20 and more restarts (switching machine off and on again). Thanks, Ward. Btw, thanks to your work on the h8dmr-fam10 I was able to even boot my machines, thanks for that! :) Bye! -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] H8QME-2+ boot problems on different machines.
Hi,
I have a strange problem trying to install/flash my Coreboot to several
machines in the cluster some worked just fine and other hang at a really
early moment.
The machines are identical: H8QME-2+ with 16 GB RAM and 4 quadcore AMD
Opterons 8350.
I guess that from the point where it hangs that it must be some kind of
CPU issue (I haven't switched CPUs yet).
here the serial output:
coreboot-4.0-r5224M Wed Apr 28 12:50:59 CEST 2010 starting...
BSP Family_Model: 00100f22
*sysinfo range: [000cc000,000cdfa0]
bsp_apicid = 00
cpu_init_detectedx =
After Set_sysinfo_in_ram
microcode: equivalent rev id = 0x1022, current patch id = 0x
microcode: patch id to apply = 0x0195
microcode: updated to patch id = 0x0195 success
After update_microcode
cpuSetAMDMSR done
After cpuSetAMDMSR
Enter amd_ht_init()
AMD_CB_EventNotify()
event class: 05
event: 1004
data: 04 00 00 01
AMD_CB_EventNotify()
event class: 05
event: 1004
data: 04 00 01 02
AMD_CB_EventNotify()
event class: 05
event: 1004
data: 04 01 01 03
AMD_CB_ManualBUIDSwapList()
AMD_CB_EventNotify()
event class: 05
event: 2006
data: 04 00 02 ff
AMD_CB_ManualBUIDSwapList()
AMD_CB_EventNotify()
event class: 05
event: 2006
data: 04 01 02 00
Exit amd_ht_init()
After amd_ht_init
cpuSetAMDPCI 00 done
cpuSetAMDPCI 01 done
cpuSetAMDPCI 02 done
cpuSetAMDPCI 03 done
Prep FID/VID Node:00
F3x80: e600a681
F3x84: a0e641e6
F3xD4: c3310f24
F3xD8: 03001815
F3xDC: 5428
Prep FID/VID Node:01
F3x80: e600a681
F3x84: a0e641e6
F3xD4: c3310f24
F3xD8: 03001815
F3xDC: 5428
Prep FID/VID Node:02
F3x80: e600a681
F3x84: a0e641e6
F3xD4: c3310f24
F3xD8: 03001815
F3xDC: 5428
Prep FID/VID Node:03
F3x80: e600a681
F3x84: a0e641e6
F3xD4: c3310f24
F3xD8: 03001815
F3xDC: 5428
setup_remote_node: 01 done
Start node 01 done.
se tucpor_ere0:mo t e--_-no {de: A 0PI2C IdoDn =e
0S4 tNarODt EnIDod =e 0012 dCOoRnEeI. Dc
or=see 00t0u: }p _ -r---e-m- o{t
emi _cnAProIdocCeo:IDd 0e =3: ed08oqu nieNOvD
alESetIDna rt =tr 0en2ov d iCed OR 0E3 =I Dd o0=nx1 e c.0020o2
}re,A -0 fct-: ue- rrr
--efmi-nicn t{ ralpoc iatzoAPcedeIh_:nC Ii oDddeq e u_== is
e0v0ctxal u00peNO0ntD0
0 EArIF00eDT0Ev =R i
d 0m si3 ecrtC= ouOR0cpo_Ex1dmID0eb _2:2 =r,ep 0 sato0cucu} rhr-cr
ei-end-t
tM
poema sicstaprcapgoh leco iy dAd =e=
:0 Mxee0x0squs010ia000vg0e0a0l0 90e0052nt0
rMmeeimiscvcsr oiracgdo coe ode=0de: 30: ux
pp1M0eada2stct2shae,d g ecidt ur0 o r4tope
anttaMce pphspasl itay dcg=e h=0i0x04d b0x0=101
0M000x0e0s0090s00a5950g
0e 0m0is004curccoc
c
emioMsscdesreo:
sca
ogupdece dpu:0atS 4edeptadA
t tMMcheoDM s psSidaaR tgcet d oh o0a5inepd p
Can someone please give me an advice on even how to start to narrow down
the problem? I already started to put a 0 in Config Logical CPUs but no
changes. :(
Thx,
Knut Kujat.
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] brick avoidance
Joe Korty escribió: Hi and good morning, I am new to this coreboot thing. I would like to know what techniques people are using to avoid bricking their motherboard the first time they use coreboot (ie, at the point when a person is completely ignorant about what they are doing). I've looked into the IOSS RD1-LPC8 Bios Savior but haven't been able to get a response from the company. I suspect that the product is no longer available. Too bad, that looked like it was exactly what I needed. My motherboard is the H8DME-2 with an 8 MB LPC flash. Regards, Joe Hi, I'm using extra flash chips and a second motherboard with the same socket to write them (Hotflashing). And to better handle the chips, I glued a pin head (without the needle, of course ;)) on top of them. http://www.coreboot.org/Developer_Manual/Tools bye, Knut Kujat -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] h8qme-2+ won't compile anymore
Morning, I downloaded the latest revision and tried to compile it for my board (supermicro h8qme-2+) but it fails compiling with: /home/knut/Documents/Coreboot/NewBuildSystem/5coreboot/build/mainboard/supermicro/h8qme_fam10/crt0.initobj.o: In function `console_init': romstage.c:(.rom.text+0xcd23): undefined reference to `printk_info' /home/knut/Documents/Coreboot/NewBuildSystem/5coreboot/build/mainboard/supermicro/h8qme_fam10/crt0.initobj.o: In function `mctAutoInitMCT_D': romstage.c:(.rom.text+0xcf19): undefined reference to `printk_debug' /home/knut/Documents/Coreboot/NewBuildSystem/5coreboot/build/mainboard/supermicro/h8qme_fam10/crt0.initobj.o: In function `raminit_amdmct': romstage.c:(.rom.text+0xd58d): undefined reference to `printk_debug' romstage.c:(.rom.text+0xd5b3): undefined reference to `printk_debug' /home/knut/Documents/Coreboot/NewBuildSystem/5coreboot/build/mainboard/supermicro/h8qme_fam10/crt0.initobj.o: In function `cache_as_ram_main': romstage.c:(.rom.text+0xdae4): undefined reference to `printk_debug' romstage.c:(.rom.text+0xddd2): undefined reference to `printk_info' romstage.c:(.rom.text+0xe0e6): undefined reference to `printk_debug' romstage.c:(.rom.text+0xe10f): undefined reference to `printk_debug' romstage.c:(.rom.text+0xe4de): undefined reference to `printk_debug' romstage.c:(.rom.text+0xe4f0): undefined reference to `printk_debug' romstage.c:(.rom.text+0xe501): undefined reference to `printk_debug' romstage.c:(.rom.text+0xe7ba): undefined reference to `printk_info' romstage.c:(.rom.text+0xe8fc): undefined reference to `printk_debug' romstage.c:(.rom.text+0xe93e): undefined reference to `printk_debug' romstage.c:(.rom.text+0xe966): undefined reference to `printk_debug' romstage.c:(.rom.text+0xe9c0): undefined reference to `printk_debug' romstage.c:(.rom.text+0xe9e7): undefined reference to `printk_debug' /home/knut/Documents/Coreboot/NewBuildSystem/5coreboot/build/mainboard/supermicro/h8qme_fam10/crt0.initobj.o:romstage.c:(.rom.text+0xea2b): more undefined references to `printk_debug' follow collect2: ld returned 1 exit status make: *** [/home/knut/Documents/Coreboot/NewBuildSystem/5coreboot/build/coreboot.romstage] Error 1 thx, Knut Kujat. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] h8qme-2+ won't compile anymore
Patrick Georgi escribio': Am 23.03.2010 09:24, schrieb Knut Kujat: Morning, I downloaded the latest revision and tried to compile it for my board (supermicro h8qme-2+) but it fails compiling with: Builds fine for me - you might have to remove the build directory before rebuilding. Patrick h, I haven't had a build directory because it was a fresh copy of coreboot. I'll try to compile on a different machine. thx, Knut Kujat. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] VGA rom can not be loaded by SEABIOS
Wang, Qingpei escribió: Hi, With the latest version of seabios, the vgarom can not be loaded correctly. I find that in the code seabios/src/optionrom.c vga_setup Can to load the vga rom from cbfs. The detail log is attached. Jason Wang BeiJing Technology Development Center Advanced Micro Devices (AMD) Hi, I had a similar problem some time ago. I mistakenly set CONFIG_OPTIONROMS_DEPLOYED 1 and it should be 0. Bye, Knut Kujat. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] [PATCH] spd_rom FIX H8QME-2+
Hello,
this patch fixes the issue where the board wasn't able to start after
getting unplugged. I also added some GPIOs so now the power on led is
working.
Signed-off-by: Knut Kujat kn...@gap.upv.es
---
Index: src/mainboard/supermicro/h8qme_fam10/romstage.c
===
--- src/mainboard/supermicro/h8qme_fam10/romstage.c (revisión: 5202)
+++ src/mainboard/supermicro/h8qme_fam10/romstage.c (copia de trabajo)
@@ -97,7 +97,11 @@
static inline void activate_spd_rom(const struct mem_controller *ctrl)
{
- /* nothing to do */
+#define SMBUS_SWITCH1 0x70
+#define SMBUS_SWITCH2 0x72
+// unsigned device=(ctrl-spd_addr[0])8;
+smbus_send_byte(SMBUS_SWITCH1, 5 0x0f);
+smbus_send_byte(SMBUS_SWITCH2, (5 4) 0x0f);
}
static inline int spd_read_byte(unsigned device, unsigned address)
@@ -239,6 +243,47 @@
#include cpu/amd/microcode/microcode.c
#include cpu/amd/model_10xxx/update_microcode.c
+#define GPIO1_DEV PNP_DEV(0x2e, W83627HF_GAME_MIDI_GPIO1)
+#define GPIO2_DEV PNP_DEV(0x2e, W83627HF_GPIO2)
+#define GPIO3_DEV PNP_DEV(0x2e, W83627HF_GPIO3)
+void write_GPIO(void)
+{
+ pnp_enter_ext_func_mode(GPIO1_DEV);
+ pnp_set_logical_device(GPIO1_DEV);
+ pnp_write_config(GPIO1_DEV, 0x30, 0x01);
+ pnp_write_config(GPIO1_DEV, 0x60, 0x00);
+ pnp_write_config(GPIO1_DEV, 0x61, 0x00);
+ pnp_write_config(GPIO1_DEV, 0x62, 0x00);
+ pnp_write_config(GPIO1_DEV, 0x63, 0x00);
+ pnp_write_config(GPIO1_DEV, 0x70, 0x00);
+ pnp_write_config(GPIO1_DEV, 0xf0, 0xff);
+ pnp_write_config(GPIO1_DEV, 0xf1, 0xff);
+ pnp_write_config(GPIO1_DEV, 0xf2, 0x00);
+ pnp_exit_ext_func_mode(GPIO1_DEV);
+
+ pnp_enter_ext_func_mode(GPIO2_DEV);
+ pnp_set_logical_device(GPIO2_DEV);
+ pnp_write_config(GPIO2_DEV, 0x30, 0x01);
+ pnp_write_config(GPIO2_DEV, 0xf0, 0xef);
+ pnp_write_config(GPIO2_DEV, 0xf1, 0xff);
+ pnp_write_config(GPIO2_DEV, 0xf2, 0x00);
+ pnp_write_config(GPIO2_DEV, 0xf3, 0x00);
+ pnp_write_config(GPIO2_DEV, 0xf5, 0x48);
+ pnp_write_config(GPIO2_DEV, 0xf6, 0x00);
+ pnp_write_config(GPIO2_DEV, 0xf7, 0xc0);
+ pnp_exit_ext_func_mode(GPIO2_DEV);
+
+ pnp_enter_ext_func_mode(GPIO3_DEV);
+ pnp_set_logical_device(GPIO3_DEV);
+ pnp_write_config(GPIO3_DEV, 0x30, 0x00);
+ pnp_write_config(GPIO3_DEV, 0xf0, 0xff);
+ pnp_write_config(GPIO3_DEV, 0xf1, 0xff);
+ pnp_write_config(GPIO3_DEV, 0xf2, 0xff);
+ pnp_write_config(GPIO3_DEV, 0xf3, 0x40);
+ pnp_exit_ext_func_mode(GPIO3_DEV);
+}
+
+
void real_main(unsigned long bist, unsigned long cpu_init_detectedx)
{
struct sys_info *sysinfo = (struct sys_info *)(CONFIG_DCACHE_RAM_BASE + CONFIG_DCACHE_RAM_SIZE - CONFIG_DCACHE_RAM_GLOBAL_VAR_SIZE);
@@ -261,8 +306,9 @@
w83627hf_enable_dev(SERIAL_DEV, CONFIG_TTYS0_BASE);
pnp_exit_ext_func_mode(SERIAL_DEV);
-uart_init();
-console_init();
+ uart_init();
+ console_init();
+ write_GPIO();
printk_debug(\n);
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Supermicro H8QME-2+ mct_d fatal exit.
Rudolf Marek escribió: I finally know that my issue must be related with the smbus registers because on a vendor bios running machine and using i2cdetect and i2cdump I get several values for different i2c devices detected, I get the same values when I successfully start with coreboot. But when I start with coreboot and fail with mcr_d fatal exit those registers are blank, I know that because I found a nice piece of code dumping smbus registers on the h8dme board :D thx to the autor!! I also know that reading these registers out may cause them to get lost! I'm not sure why?! There is a multiplexer on SMBus, this confirms my theory. Please check the GPIO. Imagine the multiplexer acts as some kind of rail switch. The transactions on smbus never reach thhe memory chips (the SPD eeprom). You need to find a pin to control the multiplexer. Rudolf Thanks, because of your hints I was able to figure out that I needed to set up the spd_rom in romstage.c I also added the GPIOs settings as read from vendor BIOS and now the power on led works :). thx, Knut Kujat. Now my question is how do I initialize these registers with the values known from the vendor BIOS? smb_write_byte doesn't seems to work or maybe I'm using it wrong. THX, Knut Kujat. Knut Kujat escribió: Hello, thx all of you for your comments. Here a little update :) I now know why the boards worked just fine up here in my lab. To know if the board would work after being unplugged I always only unplugged the electrical cable but never the monitor attached to the board I figured out that the monitor is providing enough juice to maintain whatever alive in the board so after plugging the electrical cable on again coreboot started fine. Another thing I figured out is that it seems that the front leds of the board a managed by GPIO as well, is this right? If so it seems that something is wrong with GPIO because the power on led never works with coreboot. thx, Knut Kujat. ron minnich escribió: Just FYI: on our first system with Arima boards in 2002, everything worked well until we started booting 64-bit kernels. I'm not kidding. We did not find the SMBUS MUX on the boards until we had unreliable coreboot boots of 64-bit kernels. For quite some time the boards worked fine. Ollie found the SMBUS MUX by examining schematics. So the SMBUS mux can appear in strange ways, at strange times. This sounds like one of those times. SMBUS muxes are more common than you might think and the default power-on state is not always very well determined. ron -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH] spd_rom FIX H8QME-2+
Myles Watson escribió:
On Fri, Mar 12, 2010 at 4:00 AM, Knut Kujat kn...@gap.upv.es
mailto:kn...@gap.upv.es wrote:
Hello,
this patch fixes the issue where the board wasn't able to start after
getting unplugged. I also added some GPIOs so now the power on led is
working.
The spacing doesn't look like it follows these guidelines:
http://www.coreboot.org/Development_Guidelines#Coding_Style
Sorry, Patrick tells me so, too! I'll take a look at that article this
weekend.
static inline void activate_spd_rom(const struct mem_controller *ctrl)
{
-/* nothing to do */
+#define SMBUS_SWITCH1 0x70
+#define SMBUS_SWITCH2 0x72
+// unsigned device=(ctrl-spd_addr[0])8;
It's unclear what this comment is for. Maybe just drop it?
Yes, that one can go, since I was testing multiple options because I
wasn't really sure what to do.
Signed-off-by: Knut Kujat kn...@gap.upv.es mailto:kn...@gap.upv.es
With the formatting and comment addressed:
Acked-by: Myles Watson myle...@gmail.com mailto:myle...@gmail.com
Thanks,
Myles
thx and have a nice weekend,
Knut Kujat.
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Supermicro H8QME-2+: Dumping smbus registers
Paul Menzel escribió: Dear Knut, Am Mittwoch, den 10.03.2010, 17:26 +0100 schrieb Knut Kujat: […] I know that because I found a nice piece of code dumping smbus registers on the h8dme board :D thx to the autor!! is it possible to share that piece of code? […] Anyway, nice to hear you ar making some progress and good luck with the next steps! Thanks, Paul Hi, you can find the function at src/mainboard/supermicro/h8dme/romstage.c line 101: static void dump_smbus_registers(void). bye! Knut Kujat -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Supermicro H8QME-2+ mct_d fatal exit.
Hi, I finally know that my issue must be related with the smbus registers because on a vendor bios running machine and using i2cdetect and i2cdump I get several values for different i2c devices detected, I get the same values when I successfully start with coreboot. But when I start with coreboot and fail with mcr_d fatal exit those registers are blank, I know that because I found a nice piece of code dumping smbus registers on the h8dme board :D thx to the autor!! I also know that reading these registers out may cause them to get lost! I'm not sure why?! Now my question is how do I initialize these registers with the values known from the vendor BIOS? smb_write_byte doesn't seems to work or maybe I'm using it wrong. THX, Knut Kujat. Knut Kujat escribió: Hello, thx all of you for your comments. Here a little update :) I now know why the boards worked just fine up here in my lab. To know if the board would work after being unplugged I always only unplugged the electrical cable but never the monitor attached to the board I figured out that the monitor is providing enough juice to maintain whatever alive in the board so after plugging the electrical cable on again coreboot started fine. Another thing I figured out is that it seems that the front leds of the board a managed by GPIO as well, is this right? If so it seems that something is wrong with GPIO because the power on led never works with coreboot. thx, Knut Kujat. ron minnich escribió: Just FYI: on our first system with Arima boards in 2002, everything worked well until we started booting 64-bit kernels. I'm not kidding. We did not find the SMBUS MUX on the boards until we had unreliable coreboot boots of 64-bit kernels. For quite some time the boards worked fine. Ollie found the SMBUS MUX by examining schematics. So the SMBUS mux can appear in strange ways, at strange times. This sounds like one of those times. SMBUS muxes are more common than you might think and the default power-on state is not always very well determined. ron -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Supermicro H8QME-2+ mct_d fatal exit.
Hello, thx all of you for your comments. Here a little update :) I now know why the boards worked just fine up here in my lab. To know if the board would work after being unplugged I always only unplugged the electrical cable but never the monitor attached to the board I figured out that the monitor is providing enough juice to maintain whatever alive in the board so after plugging the electrical cable on again coreboot started fine. Another thing I figured out is that it seems that the front leds of the board a managed by GPIO as well, is this right? If so it seems that something is wrong with GPIO because the power on led never works with coreboot. thx, Knut Kujat. ron minnich escribió: Just FYI: on our first system with Arima boards in 2002, everything worked well until we started booting 64-bit kernels. I'm not kidding. We did not find the SMBUS MUX on the boards until we had unreliable coreboot boots of 64-bit kernels. For quite some time the boards worked fine. Ollie found the SMBUS MUX by examining schematics. So the SMBUS mux can appear in strange ways, at strange times. This sounds like one of those times. SMBUS muxes are more common than you might think and the default power-on state is not always very well determined. ron -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Supermicro H8QME-2+ mct_d fatal exit.
Rudolf Marek escribió: Hi, This is pointing to something which is powered from 5VSB voltage. It could be some GPIO settings which sets voltage for ram through some other chip. It could be some powersequencing pin connected as GPIO too, it could be a i2c bus multiplexer operated by some GPIO pin too ;) I would suggest to dump the superio chip with isadump (all logical devices) and all registers powered from the 5VSB well if known. Check for changes on GPIO pins or SuperIO global config. Check if the fail is caused by missing SPD EPROMS (error SMBus reads) or just by ram itself. It could be also something from the SB itself, but try with superio first. Then compare the dumps with that you obtained from coreboot (you will need to program that) You can check from linux with legacy bios, then boot with coreboot and then boot with power unplugged. Good luck, Rudolf Hi, I did a output on status form status = mctRead_SPD(smbaddr, Index); in mct_d.c and it only spits -1 out while on the working coreboot machine it gives me several numbers until index = 64 on those dimms where ram is installed. Is this a possible SPD EPROMS missing error you pointed out? What would be my next steps if so? Thanks for your effort, Knut Kujat. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Supermicro H8QME-2+ mct_d fatal exit.
Hello, I still having trouble with fatal exit but now I can reproduce the error: Let's say I have a board running with vendor BIOS and flashing coreboot.rom into it with flashrom, so far everything good. Now I shut the whole system down and turn it on again, and voila coreboot booting without having problems. And I can shut the system down like 100 times and boot again with no trouble. Now I unplugging the board for more than a minute plug it back on and coreboot is unable to find my installed memory and dies with No Nodes?! mct_d: fatal exit. In order to make it boot again with coreboot I have to first flash the vendor BIOS on it and boot it than I can flash and boot coreboot again. That won't be much trouble with 1 or 2 boards but with more than 10... I'm thinking that there may be some kind of electrical issue because I have a board that used to fatal exit down in the cluster but up here in the lab it works fine without any unplugging and than not working issues. Is there any way to solve this problem? Maybe ram needs more time to stabilize itself before initializing ?! Any suggestions ? Thanks, Knut Kujat. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Re unsuported Motherboard
Myles Watson escribió: For programmer it would probably be simplest to use another mainboard which is compatible with flashrom. Can we remove BIOS with the machine turned on? Meaning: We boot with the good one, we remove it, we insert the second machine chip and flash it. Does it work? Yes. This link has pictures of the pushpin method. It works very well for PLCC, which are pictured. http://www.coreboot.org/Developer_Manual/Tools#Chip_removal_tools The downside is that it will take a long time to try a new design, since you will have to boot the machine to Linux, flash the new design, and reboot. Having another machine that is already up will save a lot of time. I'm using pushpins and a separate machine for reprogramming the chips (PLCC) works awesome no problem so far and I'm sure I did reprogram chips on this board for like 100 times. About the compatibility, I have a motherboard with a socket that has a award BIOS, is the chip/socket the same for AMI? Are they compatible? Any BIOS vendor could use any type of chip. Unfortunately, that won't help you figure it out. Thanks, Myles Have you tried flashrom to see which chip is installed? Bye, Knut Kujat. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Supermicro H8QME-2+ mct_d fatal exit.
Peter Stuge escribió: Knut Kujat wrote: I haven't tried swapping CPUs or RAM. But this errors appears on memory initialization, right? So its most likely a ram issue? The memory controller is built-in to the CPU. Try swapping components around and see if the problem follows some particular parts. //Peter Hello, switching memory from a working board to the failing board worked partially because now it boots and even starts seabios but seabios can't find the hard drive!! It's like there isn't one installed I already switched HD with the working board and no result, of course everything works fine with vendor bios. That's odd! thx, Knut Kujat. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Supermicro H8QME-2+ mct_d fatal exit.
Knut Kujat escribió: Peter Stuge escribió: Knut Kujat wrote: I haven't tried swapping CPUs or RAM. But this errors appears on memory initialization, right? So its most likely a ram issue? The memory controller is built-in to the CPU. Try swapping components around and see if the problem follows some particular parts. //Peter Hello, switching memory from a working board to the failing board worked partially because now it boots and even starts seabios but seabios can't find the hard drive!! It's like there isn't one installed I already switched HD with the working board and no result, of course everything works fine with vendor bios. That's odd! thx, Knut Kujat. I solved it. There are 3 sata cables connected to the board only 1 actually has a hard drive connected to it. Seems like this cable has to be connected to sata 1 and before all others. Is this right? Can someone confirm that pleas? Bye and THX, Knut Kujat. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] Supermicro H8QME-2+ mct_d fatal exit.
Hi, I've got this ugly mct_d fatal exit error again on one of my H8QME-2+ boards. Even every single board is absolutely identical 4 Opterons 16G Ram, etc... there are several boards booting and working without any problem with coreboot and others don't even start and mct_d fatal exit :(. Has someone an idea what the problem could be ? Thanks any comment would be appreciated. Knut Kujat -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Supermicro H8QME-2+ mct_d fatal exit.
Christian Leber escribió: On Friday 26 February 2010 14:41:49 you wrote: Hi Knut I've got this ugly mct_d fatal exit error again on one of my H8QME-2+ boards. Even every single board is absolutely identical 4 Opterons 16G Ram, etc... there are several boards booting and working without any problem with coreboot and others don't even start and mct_d fatal exit :(. Has someone an idea what the problem could be ? AFAIK the boxes are using engineering samples, so who knows, have you tried swapping CPUs? Have you tried swapping the RAM? Does that happen with or without HTX board? Regards Christian Hi, it happens with and without board :(. No I haven't tried swapping CPUs or RAM. But this errors appears on memory initialization, right? So its most likely a ram issue? thx, Knut Kujat. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] Kconfig Fix for H8QME-2+.
The attached patch does several fixes so the H8QME-2+ boards builds and boots successfully with Kconfig. I also corrected some issues regarding mptables. /Signed-off-by: Knut Kujat kn...@gap.upv.es --- /Thats all :) thx, Knut Kujat Index: src/mainboard/supermicro/h8qme_fam10/Kconfig === --- src/mainboard/supermicro/h8qme_fam10/Kconfig (revisión: 5149) +++ src/mainboard/supermicro/h8qme_fam10/Kconfig (copia de trabajo) @@ -4,6 +4,7 @@ select CPU_AMD_SOCKET_F_1207 select NORTHBRIDGE_AMD_AMDFAM10 select NORTHBRIDGE_AMD_AMDFAM10_ROOT_COMPLEX + select SOUTHBRIDGE_AMD_AMD8132 select SOUTHBRIDGE_NVIDIA_MCP55 select SUPERIO_WINBOND_W83627HF select HAVE_PIRQ_TABLE @@ -49,7 +50,7 @@ config HEAP_SIZE hex - default 0xc + default 0xff000 depends on BOARD_SUPERMICRO_H8QME_FAM10 config APIC_ID_OFFSET @@ -134,10 +135,14 @@ config SERIAL_CPU_INIT bool - default n + default y depends on BOARD_SUPERMICRO_H8QME_FAM10 config MAINBOARD_PCI_SUBSYSTEM_DEVICE_ID hex default 0x1511 depends on BOARD_SUPERMICRO_H8QME_FAM10 +config STACK_SIZE + hex + default 0x1 + depends on BOARD_SUPERMICRO_H8QME_FAM10 Index: src/mainboard/supermicro/h8qme_fam10/devicetree.cb === --- src/mainboard/supermicro/h8qme_fam10/devicetree.cb (revisión: 5149) +++ src/mainboard/supermicro/h8qme_fam10/devicetree.cb (copia de trabajo) @@ -19,87 +19,45 @@ irq 0x70 = 6 drq 0x74 = 2 end - device pnp 2e.1 off # Parallel Port - io 0x60 = 0x378 - irq 0x70 = 7 + device pnp 2e.1 off # Parallel Port + io 0x60 = 0x378 + irq 0x70 = 7 end - device pnp 2e.2 on # Com1 - io 0x60 = 0x3f8 - irq 0x70 = 4 + device pnp 2e.2 on # Com1 + io 0x60 = 0x3f8 + irq 0x70 = 4 end - device pnp 2e.3 on # Com2 - io 0x60 = 0x2f8 - irq 0x70 = 3 + device pnp 2e.3 off # Com2 + io 0x60 = 0x2f8 + irq 0x70 = 3 end - device pnp 2e.5 on # Keyboard - io 0x60 = 0x60 - io 0x62 = 0x64 - irq 0x70 = 1 -irq 0x72 = 12 + device pnp 2e.5 on # Keyboard + io 0x60 = 0x60 + io 0x62 = 0x64 + irq 0x70 = 1 + irq 0x72 = 12 end - device pnp 2e.6 off # SFI - io 0x62 = 0x100 + device pnp 2e.6 off # SFI + io 0x62 = 0x100 end - device pnp 2e.7 off # GPIO_GAME_MIDI -io 0x60 = 0x220 -io 0x62 = 0x300 -irq 0x70 = 9 + device pnp 2e.7 off # GPIO_GAME_MIDI + io 0x60 = 0x220 +io 0x62 = 0x300 +irq 0x70 = 9 end - device pnp 2e.8 off end # WDTO_PLED - device pnp 2e.9 off end # GPIO_SUSLED - device pnp 2e.a off end # ACPI - device pnp 2e.b on # HW Monitor - io 0x60 = 0x290 -irq 0x70 = 5 - end + device pnp 2e.8 off end # WDTO_PLED + device pnp 2e.9 off end # GPIO_SUSLED + device pnp 2e.a off end # ACPI + device pnp 2e.b on # HW Monitor + io 0x60 = 0x290 + irq 0x70 = 5 + end end end - device pci 1.1 on # SM 0 -chip drivers/generic/generic #dimm 0-0-0 -device i2c 50 on end -end -chip drivers/generic/generic #dimm 0-0-1 -device i2c 51 on end -end -chip drivers/generic/generic #dimm 0-1-0 -device i2c 52 on end -end -chip drivers/generic/generic #dimm 0-1-1 -device i2c 53 on end -end
Re: [coreboot] Kconfig Fix for H8QME-2+.
Stefan Reinauer escribió: On 2/24/10 9:35 AM, Knut Kujat wrote: The attached patch does several fixes so the H8QME-2+ boards builds and boots successfully with Kconfig. I also corrected some issues regarding mptables. /Signed-off-by: Knut Kujat kn...@gap.upv.es Wow... about a Megabyte of heap and 64kb stack? That's quite a lot... It will definitely break S3 as it's currently implemented (assumes that all of coreboot fits in 1MB, code, heap, stack) Stefan Hi, the big heap is because of some experiments I was doing with some htx cards on one it told me at a certain point of the boot process that malloc failed so I started increasing the heap size until I was so annoyed about none of the values were working so I aimed high but without card I got it booting with heap size = 0xc000. So which value should go into the Kconfig file ? I guess 0xc000?! Thx, Knut Kujat. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [commit] r5154 - trunk/src/mainboard/supermicro/h8qme_fam10
Stefan Reinauer escribió: On 2/24/10 1:59 PM, Peter Stuge wrote: repository service wrote: +++ trunk/src/mainboard/supermicro/h8qme_fam10/devicetree.cbWed Feb 24 09:48:35 2010(r5154) @@ -142,6 +93,18 @@ device pci 18.3 on end device pci 18.4 on end device pci 19.0 on end + device pci 19.0 on end + device pci 19.0 on + chip southbridge/amd/amd8132 Why so many 19.0? Because an opteron CPU has three hypertransport links. Each device reflects one of the links. BUT: This is an overspecification in the device tree and it will likely fail, print errors or otherwise do the wrong thing if you only put 2 CPUs on that board. The selection of the driver in Kconfig should be enough for coreboot to do the right thing. Is it not? + select SOUTHBRIDGE_AMD_AMD8132 Stefan Hi, I read in earlier mailing list entries that it is not necessary to put all 4 cpu in the device tree since coreboot detects them automatically. So I only go with 18 because it got the MCP 55 and 19 because thats where the amd 8132 is. If you thing it is better to put all 4 cpu in the device tree to avoid trouble I will do that. THX, Knut Kujat. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] mct_d fatal exit, Coreboot won't restart anymore.
Hi, after almost 2 weeks coreboot working without a problem on my h8qme, it froze and refused to restart complaining on the serial a mct_d fatal exit Since my colleagues, here at the lab, were doing some sort of memory messages traffic tests and it happens that sometimes the machines involved in these tests just quite there job (even with factory BIOS) I wasn't really concerned when they told me that the coreboot machine stopped working but the weird thing is that it refused to start again even after plugging out the cable and plugging it in after a few minutes and even a night. It was still complaining of mct_d fatal exit so I sorted out that it has something to do with memory initialization, right? Thats a problem because I had to change the chip to vendor BIOS booting and later switching again to coreboot. Now here is my question is there some way to boot with coreboot every time like its the first time? Would dumping everything in nvram help and if yes how do I manage to do that? Thanks in advance, Knut Kujat. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Patch Supermicro H8QME
Patrick Georgi escribió: Am 03.02.2010 14:53, schrieb Knut Kujat: Hi, hope thats how it works for adding a patch to the list so if something is wrong let me know. The procedure is fine. I copied a newer version of h8dmr_fam10's Makefile.inc to the h8qme_fam10 tree, otherwise it's fine. Acked-by: Patrick Georgi patrick.geo...@coresystems.de and committed as r5075 May I assume that crossgcc fixed your build issues? Yes! Patrick -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] arima irq issues
Hi, I used to have the same problems with mptable but because my entrance in mptable for my network devices weren't correct so they never got an irq assigned. Could you send in a lspci -vvv (with vendor bios) and the lines from mptable where you assign irq to your network device(s?)? Thanks, Knut Kujat. Hugh Greenberg escribió: They look correct to me, but I don't know exactly what to look for. I checked the irq tables and they were correct. I checked the mptable and tried change things, but nothing helped. Linux ernels = 2.6.30 do not permit my pci devices to work correctly. Kernels older than that seem to work. Attached is the output from coreboot and from Linux. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] CB won't boot with changed folder name.
Patrick Georgi escribió: Am 01.02.2010 13:28, schrieb Patrick Georgi: So there really is some difference at least in the ram stages of fallback and normal. For closer analysis, I'd need the files' content. Knut, thank you for sending me the files off-list. I hope thats really ok with you since the list refused my attachment for understandable reasons. For some reason, there are differences in the memory map for those two builds. h8dmr: Program Header: LOAD off0x1000 vaddr 0x0020 paddr 0x0020 align 2**12 filesz 0x0002e130 memsz 0x00030b3c flags rwx LOAD off0x0003 vaddr 0x0024 paddr 0x0024 align 2**12 filesz 0x memsz 0x00018000 flags rw- STACK off0x vaddr 0x paddr 0x align 2**2 filesz 0x memsz 0x flags rwx h8qme: Program Header: LOAD off0x1000 vaddr 0x0020 paddr 0x0020 align 2**12 filesz 0x0002d560 memsz 0x00048000 flags rwx STACK off0x vaddr 0x paddr 0x align 2**2 filesz 0x memsz 0x flags rwx So h8dmr zeroes out a larger chunk of memory - up to 0x258000, while the h8qme build only loads data up to 0x248000. I have absolutely no idea what makes the compiler behave that way on two practically identical builds, but I have seen that you use the distribution's compiler - we have no control over the changes they add, so we created crossgcc at some point. Maybe it helps to try to build with crossgcc (you can find that in util/crossgcc in your coreboot tree) Regards, Patrick thx, for the tip, now installing crossgcc. Thanks, Knut Kujat. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] CB won't boot with changed folder name.
Hi, I'm still trying to get a working copy for the coreboot tree of my H8QME supermicro board. The board still got some issues to be resolved but not preventing it form booting and from working quiet stable (15 hours mPrime (Prime 95) no failures or warnings). But as I commented earlier when I was working to get the board booting I was always in the folder of the board I was porting from (/supermicro/h8dmr_fam10). Now to be able to send in a valid patch I need to create a new folder and copy all the files in it. So here is what I did: at /src/supermicro/ mkdir h8qme_fam10 cp h8dmr_fam10/* h8qme_fam10/ at /targets/supermicro( mkdir h8qme_fam10 cp h8dmr_fam10/* h8qme_fam10/ changed Config.lb in targets/supermicro/h8qme_fam10 I compiled it without any problems I flashed it and then started the machine, so now two things usually happen; it reboots or it halts. I'm so sorry to bother you guys with such a thing but I'm not able to make it work and I'm now really curious about what could probably cause such a strange behavior. Thanks, Knut Kujat -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH] Update LinuxBIOS/coreboot support in memtest86+ 4.0
Stefan Reinauer escribió: On 1/27/10 10:35 AM, Knut Kujat wrote: Knut Kujat escribió: I haven't tried with a unpatched version of memtest86+ 4.0 and it works typo!! I meant I HAVE tried memtest86+ 4.0 with a non patched version and vendor BIOS and it worked. Are you saying that the patch breaks Vendor BIOS, too? Stefan Unfortunately yes. With the patched memtest86+ 4.0 the only difference between coreboot and vendor bios is that coreboot freezes the screen completely and vendor bios reboots. And both actions happen at, as far as I can tell, the same point or time. thx, Knut Kujat. with vendor BIOS. Now with the patched version it halts with coreboot without error messages (the output you see below is what I see until I press reset button) and with vendor BIOS its reboots at the same point (after 2 sec). bye and thx, Knut Kujat. Stefan Reinauer escribió: Knut, are the values the same as with the vendor bios? Do you get any errors at all, or does it just hang? Stefan On 1/26/10 5:48 PM, Knut Kujat wrote: I tried it with and without the little patch below ( and of course with the big patch) and it freezes after 2 seconds: Memtest86+ v4.00 | Pass 0% AMD K10 (65nm) @ 2000 MHz | Test 3% # L1 Cache: 64K 30303 MB/s | Test #0 [Address test, walking ones] L2 Cache: 512K 10050 MB/s | Testing: 4096M - 6144M 16G L3 Cache: 2048K 5649 MB/s | Pattern: Memory : 16G 1122 MB/s |- Chipset : AMD K10 IMC (ECC : Detect / Correct - Chipkill : Off) Settings: RAM : 333 MHz (DDR667) / CAS : 5-5-5-15 / DDR2 (64 bits) WallTime Cached RsvdMem MemMap Cache ECC Test Pass Errors ECC Errs - -- --- - --- -- 0:00:0216G 0Kcoreboot on off Std 0 0 - If you need some more output of whatever just ask me. bye and thx, Knut Kujat -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH] Update LinuxBIOS/coreboot support in memtest86+ 4.0
Knut Kujat escribió: I haven't tried with a unpatched version of memtest86+ 4.0 and it works typo!! I meant I HAVE tried memtest86+ 4.0 with a non patched version and vendor BIOS and it worked. with vendor BIOS. Now with the patched version it halts with coreboot without error messages (the output you see below is what I see until I press reset button) and with vendor BIOS its reboots at the same point (after 2 sec). bye and thx, Knut Kujat. Stefan Reinauer escribió: Knut, are the values the same as with the vendor bios? Do you get any errors at all, or does it just hang? Stefan On 1/26/10 5:48 PM, Knut Kujat wrote: I tried it with and without the little patch below ( and of course with the big patch) and it freezes after 2 seconds: Memtest86+ v4.00 | Pass 0% AMD K10 (65nm) @ 2000 MHz | Test 3% # L1 Cache: 64K 30303 MB/s | Test #0 [Address test, walking ones] L2 Cache: 512K 10050 MB/s | Testing: 4096M - 6144M 16G L3 Cache: 2048K 5649 MB/s | Pattern: Memory : 16G 1122 MB/s |- Chipset : AMD K10 IMC (ECC : Detect / Correct - Chipkill : Off) Settings: RAM : 333 MHz (DDR667) / CAS : 5-5-5-15 / DDR2 (64 bits) WallTime Cached RsvdMem MemMap Cache ECC Test Pass Errors ECC Errs - -- --- - --- -- 0:00:0216G 0Kcoreboot on off Std 0 0 - If you need some more output of whatever just ask me. bye and thx, Knut Kujat -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Memtest86+ failing on coreboot system.
Patrick Georgi escribió: Am 25.01.2010 17:13, schrieb Knut Kujat: - booting interrupts for about 4 minutes on Stage: loading fallback/coreboot_ram @ 0x20 (360448 bytes), entry @ 0x20 For this issue, the following change might help: --- src/cpu/amd/mtrr/amd_earlymtrr.c(revision 5054) +++ src/cpu/amd/mtrr/amd_earlymtrr.c(working copy) @@ -45,8 +45,13 @@ /* enable write through caching so we can do execute in place * on the flash rom. */ -set_var_mtrr(1, CONFIG_XIP_ROM_BASE, CONFIG_XIP_ROM_SIZE, MTRR_TYPE_WRBACK); +#if defined(CONFIG_TINY_BOOTBLOCK) CONFIG_TINY_BOOTBLOCK +#define REAL_XIP_ROM_BASE AUTO_XIP_ROM_BASE +#else +#define REAL_XIP_ROM_BASE CONFIG_XIP_ROM_BASE #endif +set_var_mtrr(1, REAL_XIP_ROM_BASE, CONFIG_XIP_ROM_SIZE, MTRR_TYPE_WRBACK); +#endif /* Set the default memory type and enable fixed and variable MTRRs */ If it does, please let us know, so we can add it to the tree. Regards, Patrick Hello, #if defined(CONFIG_XIP_ROM_SIZE) /* enable write through caching so we can do execute in place * on the flash rom. */ #if defined(CONFIG_TINY_BOOTBLOCK) CONFIG_TINY_BOOTBLOCK #define REAL_XIP_ROM_BASE AUTO_XIP_ROM_BASE #else #define REAL_XIP_ROM_BASE CONFIG_XIP_ROM_BASE #endif set_var_mtrr(1, REAL_XIP_ROM_BASE, CONFIG_XIP_ROM_SIZE,MTRR_TYPE_WRBACK); #endif It still hangs at Stage: loading fallback/coreboot_ram @ 0x20 (360448 bytes), entry @ 0x20 for exactly 2min 28sec so I think it speed up a little :). Thanks I really appreciate your help. Knut Kujat. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH] Update LinuxBIOS/coreboot support in memtest86+ 4.0
I tried it with and without the little patch below ( and of course with
the big patch) and it freezes after 2 seconds:
Memtest86+ v4.00 | Pass 0%
AMD K10 (65nm) @ 2000 MHz | Test 3% #
L1 Cache: 64K 30303 MB/s | Test #0 [Address test, walking ones]
L2 Cache: 512K 10050 MB/s | Testing: 4096M - 6144M 16G
L3 Cache: 2048K 5649 MB/s | Pattern:
Memory : 16G 1122 MB/s
|-
Chipset : AMD K10 IMC (ECC : Detect / Correct - Chipkill : Off)
Settings: RAM : 333 MHz (DDR667) / CAS : 5-5-5-15 / DDR2 (64 bits)
WallTime Cached RsvdMem MemMap Cache ECC Test Pass Errors
ECC Errs
- -- --- - --- --
0:00:0216G 0Kcoreboot on
off Std 0 0
-
If you need some more output of whatever just ask me.
bye and thx,
Knut Kujat
Stefan Reinauer escribió:
On 1/23/10 5:43 PM, Samuel D. wrote:
I don't have any way to test this patch right now, so I'll just add
it in upcoming 4.01.
Thanks for your work.
Sam.
Dear Sam,
there was an additional bug I introduced. On top of the other patch,
you need to apply this:
*
Index: coreboot.c
===
--- coreboot.c(revision 2775)
+++ coreboot.c(working copy)
@@ -123,7 +123,8 @@
/* if there is, all valid information is in the
* referenced coreboot table
*/
-head = __find_cb_table(forward-forward, 0x1000);
+head = __find_cb_table(forward-forward,
+forward-forward + 0x1000);
}
return head;
*
In addition I suggest to add the following patch:
*Index: memsize.c
===
--- memsize.c(revision 2775)
+++ memsize.c(working copy)
@@ -125,7 +125,7 @@
n++;
}
v-msegs = n;
-cprint(LINE_INFO, COL_MMAP, corebt);
+cprint(LINE_INFO, COL_MMAP, coreboot);
}
static void memsize_820()
{*
The other memory table types only output 6 characters here, but the
field is 8 characters, so no need to abbreviate.
Sorry I didn't notice this earlier.
Best regards,
Stefan
--
coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br.
Tel.: +49 761 7668825 • Fax: +49 761 7664613
Email: i...@coresystems.de • http://www.coresystems.de/
Registergericht: Amtsgericht Freiburg • HRB 7656
Geschäftsführer: Stefan Reinauer • Ust-IdNr.: DE245674866
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH] Update LinuxBIOS/coreboot support in memtest86+ 4.0
I haven't tried with a unpatched version of memtest86+ 4.0 and it works with vendor BIOS. Now with the patched version it halts with coreboot without error messages (the output you see below is what I see until I press reset button) and with vendor BIOS its reboots at the same point (after 2 sec). bye and thx, Knut Kujat. Stefan Reinauer escribió: Knut, are the values the same as with the vendor bios? Do you get any errors at all, or does it just hang? Stefan On 1/26/10 5:48 PM, Knut Kujat wrote: I tried it with and without the little patch below ( and of course with the big patch) and it freezes after 2 seconds: Memtest86+ v4.00 | Pass 0% AMD K10 (65nm) @ 2000 MHz | Test 3% # L1 Cache: 64K 30303 MB/s | Test #0 [Address test, walking ones] L2 Cache: 512K 10050 MB/s | Testing: 4096M - 6144M 16G L3 Cache: 2048K 5649 MB/s | Pattern: Memory : 16G 1122 MB/s |- Chipset : AMD K10 IMC (ECC : Detect / Correct - Chipkill : Off) Settings: RAM : 333 MHz (DDR667) / CAS : 5-5-5-15 / DDR2 (64 bits) WallTime Cached RsvdMem MemMap Cache ECC Test Pass Errors ECC Errs - -- --- - --- -- 0:00:0216G 0Kcoreboot on off Std 0 0 - If you need some more output of whatever just ask me. bye and thx, Knut Kujat -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Memtest86+ failing on coreboot system.
Hi, I would love to send the new board to the list but there are several issues still remaining like: - SMBus gets irq 0 instead of 5 - ACPI not working - booting interrupts for about 4 minutes on Stage: loading fallback/coreboot_ram @ 0x20 (360448 bytes), entry @ 0x20 and the strangest thing: I created a new folder h8qme_fam10 (I was working in h8dmr_fam10 all the time) made the different changes to be able to compile everything correctly and now it refuses to boot. It just halts somewhere or does several soft resets at different places. bye! PS: Ward, if you are still interested I can send it to you. Ward Vandewege escribió: On Fri, Jan 22, 2010 at 12:09:59AM +0100, Knut Kujat wrote: sorry, of course. I did the necessary changes on the alrady existing supermicro h8dmr_fam10 board to make it work on a h8qme_fam10. I'm interested in your port. It should go into the tree. Do you want to send a patch to the list? Thanks, Ward. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Memtest86+ failing on coreboot system.
Patrick Georgi escribió: Am 25.01.2010 17:13, schrieb Knut Kujat: Hi, I would love to send the new board to the list but there are several issues still remaining like: - SMBus gets irq 0 instead of 5 - ACPI not working We have lots of boards with (at best) incomplete ACPI support. That shouldn't stop you from releasing :-) - booting interrupts for about 4 minutes on Stage: loading fallback/coreboot_ram @ 0x20 (360448 bytes), entry @ 0x20 You could try to dump the MTRRs right before loading the ramstage. 4 minutes sounds like there's some problem with caching. and the strangest thing: I created a new folder h8qme_fam10 (I was working in h8dmr_fam10 all the time) made the different changes to be able to compile everything correctly and now it refuses to boot. It just halts somewhere or does several soft resets at different places. Did you check that there is no h8dmr_fam10 or H8DMR_FAM10 in the new directory? Is that directory hooked up in kconfig (if you're using kconfig, that is)? If you mix up the names, it might just build a mix of code for your board and another supermicro board. Patrick I was very careful with not mixing names. I tried to just rename the existing folder as well with the same result, it's just so annoying because I know I must be forgetting something really stupid. thx, Knut Kujat. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] Memtest86+ failing on coreboot system.
Hello, I've finally got my board working with Coreboot now I started to stress test the whole system to know if it is stable. Now, when I'm trying to test my memory with Memtest86+ it doesn't starts! instead it shows correct information about my cpus and caches but at Memory there is just a 0K and in the middle of the screen a 0K LxBIOS what is that mean? After waiting a few minutes I'm getting the whole screen full of rubbish symbols and than the monitors goes off. I already tried several versions of memtest86+ without luck. I know there is a payload with Memtest86+ I haven't tried yet but I just don't think it will make any difference, won't it? THX, Knut Kujat -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Memtest86+ failing on coreboot system.
Hi, sorry, of course. I did the necessary changes on the alrady existing supermicro h8dmr_fam10 board to make it work on a h8qme_fam10. Supermicro H8QME-2+ 4 CPUs (Opterons) 16 GB ram MCP55 PRO AMD 8132 I used the memtest that comes with the OPENSuse 11.2 installation CD I also installed memtest to my grub boot menu. Seems like memtest doesn't find any memory at all?! But linux boots fine and recognized the whole memory amount. I already did some benchmarks and they finished without any problems. thx. can you remind us what hardware this is? ron -- Knut Kujat -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Memtest86+ failing on coreboot system.
OK, thx anyway. I found another one memtester 4.1 usable from linux so it won't test the whole amount but memtest86 doesn't either :P. bye! memtest in many ways is not my favorite program. I would rather have a simple non-GUI tester, because in the past I've had trouble with it (it can fail) when it did not like the device it was trying to do its GUI on. Also, the way memtest finds top of memory can fail on some chipsets. Have not seen that for a while but I did see it. No idea if any of this is your problem but ... ron -- Knut Kujat -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Memtest86+ failing on coreboot system.
Ah, ok! I'll try this. At least now I know from you and ron that it isn't necessary my ram thats failing. thx a lot! Knut. I used the memtest that comes with the OPENSuse 11.2 installation CD I also installed memtest to my grub boot menu. Seems like memtest doesn't find any memory at all?! But linux boots fine and recognized the whole memory amount. I already did some benchmarks and they finished without any problems. Your problem sounds very similar to the one I had. Memtest looks to see if you have LinuxBIOS tables, but doesn't support tables in high memory, so it fails. Since you are using SeaBIOS, you'd prefer that it used the BIOS tables. I modified SeaBIOS to destroy the marker for the LinuxBIOS tables after reading them (since they are no longer useful.) It's a hack, but it's quick and easy. Suggestions: Use a similar hack to destroy the signature so Memtest doesn't get confused Use a version of Memtest that already supports high tables. Thanks, Myles -- Knut Kujat -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] NIC working, IP assigned but not connected.
Hi, I already managed to get IRQs assigned for my two NICs. As happy as I was about that I asked for a IP to test if the board works correctly so I booted with coreboot into my suse 11.2 made a ifconfig and saw that i've got a valid IP, Mask everthing set up fine through DHCP. But I'm unable to connect to whatever I can't do pings, navigation just nothing. I of course did pings with ip addresses to see if it maybe only a DNS issue but its not, the weird part is that the DNS servers get well configured by the DHCP server. I did test with the factory BIOS and I get the exact same network configuration and it actually works. The only difference I could see are shown below: _Factory BIOS: _ Setting up (localfs) network interfaces: lo loIP address: 127.0.0.1/8 IP address: 127.0.0.2/8 lo doneok eth0 device: Intel Corporation 82546GB Gigabit Ethernet Controller (rev 03) [ 14.435358] e1000: eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX/TX This line doesn't show up when booting with coreboot [ 14.435981] ADDRCONF(NETDEV_UP): eth0: link is not ready [ 14.441734] ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready - This line doesn't show up when booting with coreboot eth0 Starting DHCP4 client[ 14.968730] NET: Registered protocol family 17 - Start immediately not so with coreboot . eth0 IP address: ###.##.##.###/## (.gap.upv.es) - I scrambled the IP eth0 doneeth1 device: Intel Corporation 82546GB Gigabit Ethernet Controller (rev 03) No configuration found for eth1 eth1 unusedSetting up service (localfs) network . . . . . . . . . .done _Coreboot:_ eth0 device: Intel Corporation 82546GB Gigabit Ethernet Controller (rev 03) [ 16.448334] ADDRCONF(NETDEV_UP): eth0: link is not ready eth0 Starting DHCP4 client[ 17.260820] NET: Registered protocol family 17 [ 17.351033] pci :01:01.0: using bridge :00:07.0 INT B to get IRQ 19 [ 17.393206] pci :01:01.0: PCI-APIC IRQ transform: INT B - IRQ 19 ok . . . . . . . . eth0 DHCP4 client NOT running eth0 failedeth1 device: Intel Corporation 82546GB Gigabit Ethernet Controller (rev 03) No configuration found for eth1 eth1 unusedWaiting for mandatory devices: eth0 __NSC__ 3 2 0 eth0 device: Intel Corporation 82546GB Gigabit Ethernet Controller (rev 03) eth0 DHCP4 client (dhcpcd) is running eth0 . . . but is still waiting for data eth0 IP address: 1##.##.##.###/## --- Finally it gets the IP assign eth0 waiting eth0 interface could not be set up until now failedSetting up service (localfs) network . . . . . . . . . .failed I already added the network option rom obtained from the original BIOS rom to the Coreboot rom but no changes. Please find attached the whole coreboot log for more info. I have no idea what possibly could be wrong so I'm open and grateful for every comment. THX in advanced, Knut Kujat. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] Problem: 8254 timer not connected to IO-APIC.
Hi, I'm still having trouble getting the IRQs for my on board NICs working probably. I think I set everything right in get_bus_conf.c, mptables.c and irq_table.c but in my linux bootup I get this message: MP-BIOS bug: 8254 timer not connected to IO-APIC. I based my changes on the tyan s2891 that got a amd 8131 and a nvidia CK804 hanging on the same cpu but on different links. My board got a AMD 8132 and a MCP55 hanging on two different CPUs. Am I'm missing some setup for the IO-APIC? some kind of routing maybe? Some hints or a complete solution ;) would be appreciated. THX, Knut Kujat. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] coreboot and MSM800BEV
Piotr Piwko escribió: Hello, I had removed the the 'wbinvd' cache invalidation function, and then a boot process moved on. Now it hangs on 'FATAL: NO VSA found!' error'. In order to fix it I've added VSA to my coreboot image by following command: build/util/lar/lar -C lzma -a build/bios.bin ./build/gpl_vsa_lx_102.bin:blob/vsa After that, the boot process hangs on 'Done printk() buffer move'. It seems like the VSA is not placed in a proper place in the whole bios image. Do you know any other possibilities to include the VSA in coreboot image? Thanks in advance for interest. Hi, I use: ./cbfstool coreboot.rom add vga.bin pci1002,515e.rom 99 and where 1002 is the vendor id (ATI) and 515e the device id (ES1000) obtain from a lspci -tvnn (+-06.0-[01]01.0 ATI Technologies Inc ES1000 [1002:515e]) not sure what 99 is :P. ciao. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] H8QME-2+ IRQ assignment and AMD 8132
Knut Kujat escribió: Hello, over this week I've tried to do a proper IRQ assignment on the H8QME-2+ I've got here. So opened mp_tables.c and started changing the irq routing values with those I got form the board booting with a factory bios. Then I started giving the devices the irq they have when boot with factory bios and it booted without any problems except for two things first of all the two NICs still have irq 0 and thats because they are not pending on the mcp55 as they are on the donator board but on a AMD 8132 tunnel devices that is hanging on a different node: socketF(node3) --- socketF(node2) || socketF(node1) --- socketF(node0) || |ht |ht || AMD8132MCP55 |-- LAN| |-- SCSI |-- SATA |-- ATI ES 1000 |-- USB |-- PCI | lpc SIO I started adding the AMD8132 to the get_bus_conf.c code, by adding I mean stealing code from other boards pasting it to get_bus_conf and trying to make it work ;). So the problem there is that coreboot won't boot with the new code but not because the code is incorrect because it wasn't even executed, I know that because coreboot soft resets in middle of cpu initialization. I already increased Stack size up to 0x1 more makes the boot sequence fail. My second problem is the, irq_tables.c code I tried to customize for this board. I first tried the handy tool that comes with coreboot that auto-generates the irq_tables.c file but it doesn't compile with my board but I at least was able to use the information to modify the already existing irq_tables.c. So before doing changes the dump_irq output look like that: Interrupt routing table found at address 0xf55bb: Version 106.117, size 0x8366 Interrupt router is device 3d:17.4 PCI exclusive interrupt mask: 0x0fde [1,2,3,4,6,7,8,9,10,11] Compatible router: vendor 0x device 0x6075 Device d2:00.2 (slot 106): INTA: link 0x54, irq mask 0x0005 [0,2] INTB: link 0x40, irq mask 0xc839 [0,3,4,5,11,14,15] INTC: link 0x72, irq mask 0x84f7 [0,1,2,4,5,6,7,10,15] INTD: link 0xd2, irq mask 0x4275 [0,2,4,5,6,9,14] Device 83:19.2 (slot 195): INTA: link 0xff, irq mask 0x74b8 [3,4,5,7,10,12,13,14] INTB: link 0x74, irq mask 0x000f [0,1,2,3] INTC: link 0xe8, irq mask 0x9f77 [0,1,2,4,5,6,8,9,10,11,12,15] INTD: link 0xff, irq mask 0x89ff [0,1,2,3,4,5,6,7,8,11,15] Interrupt router at 3d:17.4: Could not read router info from /proc/bus/pci/3d/17.4. and after compiling with the new irq_tables.c I've got the exact same output! So no changes were applied, I cleaned everything before compiling so no doubt I compiled the correct file. So why is it still the same? (I attached a dump_irq output from the board with factory bios). And last but not least, at linux bootup it complains to find only 2 cpus but 16 cores later doing a lspci I can see all 4 cpus (18.0, 19,0 1a.0, 1b.0) and Linux only recognizes 8GB of ram but there are 16GB installed! Thanks in advanced and have a nice weekend, Knut Kujat. Hello, I fixed the 2 cpu and just 8 GB ram issues, now linux finds all 4 cpus and 16 GB. But I'm still having trouble adding AMD 8132 for giving the NICs IRQ. THX, Knut Kujat. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Problems porting H8dmr_fam10 to H8qme-2+
Myles Watson escribió:
Unfortunately, it's undocumented, so you have a couple of options:
1. Look at http://www.coreboot.org/Nvidia_MCP55_Porting_Notes
2. Decode the ACPI interrrupt assignments
Either way you may need to look at the interrupt assignments in Linux
when booted with the factory BIOS.
I'm wondering if it isn't possible to just read those registers out once
booted with a factory BIOS?
You can. You still have to make the mptable and irq table match, which
requires you to know what the values mean.
at irq table you mean this values:
write_pirq_info(pirq_info, m-bus_mcp55[0], ((sbdn+6)3)|0, 0x1,
0xdef8, 0x2, 0xdef8, 0x3, 0xdef8, 0x4, 0xdef8, 0, 0); this
pirq_info++; slot_num++;
for(i=1; i sysconf.hc_possible_num; i++) {
if(!(sysconf.pci1234[i] 0x1) ) continue;
unsigned busn = (sysconf.pci1234[i] 12) 0xff;
unsigned devn = sysconf.hcdn[i] 0xff;
write_pirq_info(pirq_info, busn, (devn3)|0, 0x1, 0xdef8, 0x2,
0xdef8, 0x3, 0xdef8, 0x4, 0xdef8, 0, 0); and this.
pirq_info++; slot_num++;
}
Sorry for those noob questions but this is getting much deeper i thought
it would go. ;)
Using SeaBios 5.0 it accepts level 8 for debugging, but still no luck
with the vga initialization. It doesn't even seem to be SeaBios fault
because Coreboot complains exactly the same story:
PCI: 01:01.0 init
CBFS: Could not find file pci1002,515e.rom
You could read the ROM, correct the signature, and put it in CBFS as
pci1002,515e.rom
On card, rom address for PCI: 01:01.0 = fc00
PCI Expansion ROM, signature 0x7373, INIT size 0xe600, data ptr 0x7373
Incorrect Expansion ROM Header Signature 7373
You're right. It looks like the signature in your ROM is not coming out
correctly. You need to figure out why, or just try to ignore the bad
signature and see if you can get past it. In Linux with the factory BIOS
you could see if the signature is still broken.
OK I'll will first try to make my irqs work after. Because I think most
of the trouble is coming from there.
One difference I noticed between my lspci -tvnn output and coreboot is
that the ati es 1000 is at bus 6 on the lspci output and on bus 7 at
coreboot.
+-05.0 nVidia Corporation MCP55 SATA Controller [10de:037f]
+-05.1 nVidia Corporation MCP55 SATA Controller [10de:037f]
+-05.2 nVidia Corporation MCP55 SATA Controller [10de:037f]
+-06.0-[01]01.0 ATI Technologies Inc ES1000 [1002:515e]
+-0a.0-[02]--
+-0b.0-[03]--
+-0c.0-[04]--
and
PCI: 00:07.0 resource base 0 size 0 align 20 gran 20 limit
flags 80202 index 20
PCI: 01:01.0 links 0 child on link 0 NULL
PCI: 01:01.0 resource base 0 size 800 align 27 gran 27 limit
flags 1200 index 10
PCI: 01:01.0 resource base 0 size 100 align 8 gran 8 limit
flags 100 index 14
PCI: 01:01.0 resource base 0 size 1 align 16 gran 16 limit
flags 200 index 18
PCI: 01:01.0 resource base 0 size 2 align 17 gran 17 limit
flags 2200 index 30
Is this just a different kind of enumeration or an error?
thx again, again and again,
Knut Kujat.
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Problems porting H8dmr_fam10 to H8qme-2+
Myles Watson escribió:
On Mon, Dec 28, 2009 at 3:26 AM, Knut Kujat kn...@gap.upv.es
mailto:kn...@gap.upv.es wrote:
Myles Watson escribió:
Scan for VGA option rom
Got ps2 nak (status=51); continuing
ps2_recvbyte timeout
I can't see your VGA ROM getting run anywhere. Did I just
miss it?
Nop, not working anywhere seems like Seabios doesn't find any
vga rom.
You could try a more verbose setting for SeaBIOS and send the
output to
Kevin. I'm surprised it doesn't just work.
So I tried setting up CONFIG_SB_HT_CHAIN_ON_BUS0 to different
values, no
luck!
Yeah. It doesn't seem like an enumeration problem. The device
tree seems
like it's getting set up pretty well.
You could try having Coreboot run it with vm86 and with
CONFIG_CONSOLE_VGA set to see if that works. I'm wondering why
SeaBIOS isn't finding it.
CONFIG_CONSOLE_VGA was already set to 1. How do I run coreboot
with vm86?
CONFIG_VGA_ROM_RUN =1
In Kconfig there's a VM86 option, but I don't see it in newconfig.
At least now at linux boot up my NICs are found but trying to
initialize
they got to a Unable to allocate interrupt :( I attach my
latest log.
Did you change the mptable and irqtables to match the factory
assignments?
I thought they got set up by code and I don't have to touch
anything. Am
I wrong? If so what and where do I have to do changes since mptable.c
and irq_table.c is all code.
in mptable.c:
dev = dev_find_slot(m-bus_mcp55[0], PCI_DEVFN(sbdn+ 0x1,0));
if (dev) {
res = find_resource(dev, PCI_BASE_ADDRESS_1);
if (res) {
smp_write_ioapic(mc, m-apicid_mcp55, 0x11, res-base);
}
/* These three values are interrupt routing values. */
dword = 0x43c6c643;
pci_write_config32(dev, 0x7c, dword);
dword = 0x81001a00;
pci_write_config32(dev, 0x80, dword);
dword = 0xd00012d2;
pci_write_config32(dev, 0x84, dword);
}
Unfortunately, it's undocumented, so you have a couple of options:
1. Look at http://www.coreboot.org/Nvidia_MCP55_Porting_Notes
2. Decode the ACPI interrrupt assignments
Either way you may need to look at the interrupt assignments in Linux
when booted with the factory BIOS.
I'm wondering if it isn't possible to just read those registers out once
booted with a factory BIOS?
I attached a log with seabios set up on debug level 6,
That was high enough. You can also change the debugging level of any
component in config.h
From your log:
Attempting to map option rom on dev 01:01.0
Option rom sizing returned fc01 fffe
Inspecting possible rom at 0xfc00 (dv=515e1002 bdf=108)
No option rom signature (got 7373)
This looks like the right device, so I don't know why the signature
isn't valid. You could try reading the ROM in Linux and seeing if you
don't get a valid signature. You could put the ROM into CBFS with a
valid signature and try again. Some extra debugging output might help
here. I guess you could ignore the signature too, just to see.
is this the
highest one? because 7 and 8 made compilation fail.
That's not good. You could send the log of the failing build to the
list, or play around to see what component is having trouble.
Using SeaBios 5.0 it accepts level 8 for debugging, but still no luck
with the vga initialization. It doesn't even seem to be SeaBios fault
because Coreboot complains exactly the same story:
PCI: 01:01.0 init
Check CBFS header at fffc1fe0
magic is 4f524243
Found CBFS header at fffc1fe0
Check normal/payload
CBFS: follow chain: fff0 + 28 + 13038 + align - fff13080
Check normal/coreboot_ram
CBFS: follow chain: fff13080 + 38 + e481 + align - fff21540
Check fallback/payload
CBFS: follow chain: fff21540 + 38 + 13038 + align - fff345c0
Check fallback/coreboot_ram
CBFS: follow chain: fff345c0 + 38 + e296 + align - fff428c0
Check
CBFS: follow chain: fff428c0 + 28 + 7f6f8 + align - fffc2000
CBFS: Could not find file pci1002,515e.rom
On card, rom address for PCI: 01:01.0 = fc00
PCI Expansion ROM, signature 0x7373, INIT size 0xe600, data ptr 0x7373
Incorrect Expansion ROM Header Signature 7373
Another thing is a line from the booting linux:
Found 2 Quad-Core AMD Opteron(tm) Processor 8350 processors (16 cpu
cores) (version 2.20.00)
But there are 4 and I thing that coreboot finds them. So here my
question could these problems be related to my bad IRQ handling ?
THX,
Knut Kujat.
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Problems porting H8dmr_fam10 to H8qme-2+
Myles Watson escribió: On Mon, Dec 21, 2009 at 9:15 AM, Knut Kujat kn...@gap.upv.es mailto:kn...@gap.upv.es wrote: Myles Watson escribió: On Mon, Dec 21, 2009 at 3:27 AM, Knut Kujat kn...@gap.upv.es mailto:kn...@gap.upv.es wrote: but I haven't changed anything but inserting some printk_spew into void dev_initialize(void) to see where exactly jumps the exception out. Did you try increasing the stack size? When you inserted the printk statements, were there any warnings about format strings not matching the number of arguments? Have you tried disabling the siblings yet? Thanks, Myles Hello, yes increasing stack size helped with the printks. How big did you make it? Try making it bigger until it doesn't make a difference any more. And yes I tried to disable siblings by adding uses CONFIG_LOGICAL_PROCESSORS and default CONFIG_LOGICAL_PROCESSORS=0 to the Options.lb file but it complains at building time that this options is unkown so I uses LOGICAL_CPUS instead (is it the same?) without results. You found the right one. Sorry I steered you wrong. All the processors get initialized even with CONFIG_LOGICAL_CPUS=0? That's not good. Now I know that the the exception comes up in the corresponding init(dev) for the PCI: 00:02.0 device. So I disabled PCI 2.0 in the device tree and it just doesn't has any effect even it tells me that PCI 2.0 enabled 0 at boot times, it stucks at the same place. I don't think the init function is the problem. It's more likely that something is going wrong much earlier, and just catches up to you there. I would leave the device enabled. Thanks, Myles Morning, stack_size = 0x4000 and seems to work fine. Sorry, I didn't explain myself, changing CONFIG_LOGICAL_CPUS to 0 made the compile process fail in northbridge.c so I had to change it back. Yes disabling devices didn't make any difference so I leave them enabled. h what else could I do?? THX, Knut Kujat. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Problems porting H8dmr_fam10 to H8qme-2+
Myles Watson escribió: On Tue, Dec 22, 2009 at 9:22 AM, Knut Kujat kn...@gap.upv.es mailto:kn...@gap.upv.es wrote: Hello, as Myles suggested to disable siblings to see if I can pass through this weird exception and the impossibility to do so because of the compile error I changed the physical cpu option to 1 and it worked! But increasing it back to 2 or 4 made the exception come back again. I told you, Myles, I increased stack size to 4000 that was a filthy lie because I thought I'm increasing it to 4000 what I didn't see was that the same option was repeated at the end of the Options.lb file with STACK_SIZE=8000 It's always good to check targets/vendor/board/build/fallback/ldoptions to see what's really being used. (So I don't know why the printks started working). Now fooling around with stack size and setting it up to 1 all 4 cpus started working and I got a grub menu :) in text mode :( so I have a graphics Initializing faild and Linux doesn't boot up completly. Great. I think we're getting to where we should add your board to the tree. Then we can see the device tree too. I attached it. I attached a complete log file, it is not so complete because the first lines of linux boot up are missing because I had to change serial speed on minicom. Thats because I'm having trouble of setting a speed and getting a total different one. Now I thing that my device tree is not completely working and thats why linux got some collusion at the beginning ?? It device 0:02.3 isn't getting a driver. 1:06.0 is not found. PCI: 08:01.0 Hypertransport link capability not foundPCI: pci_scan_bus for bus 08 That doesn't look good. PCI: Left over static devices: PCI: 08:01.0 PCI: 08:01.1 PCI: 08:02.0 And I have no idea why graphic mode doesn't work since it looks like it finds vga without any problem. VGA: PCI: 00:18.0 (aka node 0) link 2 has VGA device That doesn't look right. I would think it's on link 0. I don't know why that's set wrong, but it would explain why it's not working. Thanks, Myles ## ## This file is part of the coreboot project. ## ## Copyright (C) 2007 AMD ## Written by Yinghai Lu yingha...@amd.com for AMD. ## ## This program is free software; you can redistribute it and/or modify ## it under the terms of the GNU General Public License as published by ## the Free Software Foundation; either version 2 of the License, or ## (at your option) any later version. ## ## This program is distributed in the hope that it will be useful, ## but WITHOUT ANY WARRANTY; without even the implied warranty of ## MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the ## GNU General Public License for more details. ## ## You should have received a copy of the GNU General Public License ## along with this program; if not, write to the Free Software ## Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA ## ## CONFIG_XIP_ROM_SIZE must be a power of 2. # for testing with -O != s. FIXME #default CONFIG_XIP_ROM_SIZE = 128 * 1024 default CONFIG_XIP_ROM_SIZE = 128 * 1024 include /config/failovercalculation.lb arch i386 end ## ## Build the objects we have code for in this directory. ## driver mainboard.o #needed by irq_tables and mptable and acpi_tables object get_bus_conf.o if CONFIG_GENERATE_MP_TABLE object mptable.o end if CONFIG_GENERATE_PIRQ_TABLE object irq_tables.o end if CONFIG_USE_INIT makerule ./auto.o depends $(CONFIG_MAINBOARD)/cache_as_ram_auto.c option_table.h action $(CC) $(DISTRO_CFLAGS) $(CFLAGS) $(CPPFLAGS) -I$(TOP)/src -I. -c $(CONFIG_MAINBOARD)/cache_as_ram_auto.c -o $@ end else makerule ./auto.inc depends $(CONFIG_MAINBOARD)/cache_as_ram_auto.c option_table.h action $(CC) $(DISTRO_CFLAGS) $(CFLAGS) $(CPPFLAGS) $(DEBUG_CFLAGS) -I$(TOP)/src -I. -c -S $(CONFIG_MAINBOARD)/cache_as_ram_auto.c -o $@ action perl -e 's/\.rodata/.rom.data/g' -pi $@ action perl -e 's/\.text/.section .rom.text/g' -pi $@ end end if CONFIG_USE_FAILOVER_IMAGE else if CONFIG_AP_CODE_IN_CAR makerule ./apc_auto.o depends $(CONFIG_MAINBOARD)/apc_auto.c option_table.h action $(CC) $(DISTRO_CFLAGS) $(CFLAGS) $(CPPFLAGS) -I$(TOP)/src -I. -c $(CONFIG_MAINBOARD)/apc_auto.c -o $@ end end end ## ## Build our 16 bit and 32 bit coreboot entry code ## if CONFIG_HAVE_FAILOVER_BOOT if CONFIG_USE_FAILOVER_IMAGE mainboardinit cpu/x86/16bit/entry16.inc ldscript /cpu/x86/16bit/entry16.lds end else if CONFIG_USE_FALLBACK_IMAGE mainboardinit cpu/x86/16bit/entry16.inc ldscript /cpu/x86/16bit/entry16.lds end end
Re: [coreboot] Problems porting H8dmr_fam10 to H8qme-2+
Myles Watson escribió:
On Fri, Dec 18, 2009 at 8:41 AM, Knut Kujat kn...@gap.upv.es
mailto:kn...@gap.upv.es wrote:
Never mind about the memory corruption. PNP: 002e.3 has some
resources that aren't fixed, so the allocator is trying to
allocate them. In the SuperIO code where those resources are
declared, set the flags to match the other resources.
Problem solved I killed it :) means I disabled it in the device
tree. The H9DMR board has two serials and my board H8QME has only
one.
Great.
Now, I've got till the MTRR initialization and here is my reward:
POST: 0x93
Setting up local apic... apic_id: 0x0a done.
POST: 0x9b
CPU model: Quad-Core AMD Opteron(tm) Processor 8350
siblings = 03, CPU #10 initialized
All AP CPUs stopped
PCI: 00:18.0 init
PCI: 00:02.0 init
Unexpected Exception: 6 @ 10:00207ff1 - Halting
Code: 0 eflags: 00010046
eax: ebx: 00226358 ecx: 0021ea74 edx: 0001
edi: 0021ea74 esi: 0001 ebp: 0023fff4 esp: 0023ff50
POST: 0xff
the strange thing is that it seems to work for like 11 other
cores. And this log is from my last try but before it always
starts rebooting with SOFT RESET after:
Somebody else will probably know how to help you better. The first
thing I would do is disable siblings (LOGICAL_PROCESSORS=0) and see if
you can get past it or not.
Thanks,
Myles
Hello,
I now getting this:
Setting fixed MTRRs(0-88) type: UC
After Startup.
Initializing CPU #0
DONE fixed MTRRs
C
INIT detected from --- { APICID = 00 NODEID = 00 COREID = 00} ---
Issuing SOFT_RESET...
coreboot-2.0.0-r_Fallback lun dic 21 11:02:38 CET 2009 starting...
BSP Family_Model: 00100f22
*sysinfo range: [000cc000,000cdfa0]
bsp_apicid = 00
cpu_init_detectedx =
microcode: equivalent rev id = 0x1022, current patch id = 0x
microcode: rev id (1062) does not match this patch.
microcode: Not updated! Fix microcode_updates[]
cpuSetAMDMSR done
...blablabla
but I haven't changed anything but inserting some printk_spew into void
dev_initialize(void) to see where exactly jumps the exception out.
I'm confused :(.
THX,
Knut Kujat.
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Problems porting H8dmr_fam10 to H8qme-2+
Myles Watson escribió: On Mon, Dec 21, 2009 at 3:27 AM, Knut Kujat kn...@gap.upv.es mailto:kn...@gap.upv.es wrote: but I haven't changed anything but inserting some printk_spew into void dev_initialize(void) to see where exactly jumps the exception out. Did you try increasing the stack size? When you inserted the printk statements, were there any warnings about format strings not matching the number of arguments? Have you tried disabling the siblings yet? Thanks, Myles Hello, yes increasing stack size helped with the printks. And yes I tried to disable siblings by adding uses CONFIG_LOGICAL_PROCESSORS and default CONFIG_LOGICAL_PROCESSORS=0 to the Options.lb file but it complains at building time that this options is unkown so I uses LOGICAL_CPUS instead (is it the same?) without results. CPU model: Quad-Core AMD Opteron(tm) Processor 8350 Setting up local apic...siblings = 03, apic_id: 0x09 done. CPU #14 initialized CPU model: Quad-Core AMD Opteron(tm) Processor 8350 Waiting for 1 CPUS to stop siblings = 03, CPU #9 initialized All AP CPUs stopped *** Debug: After init(dev); PCI: 00:18.0 init *** Debug: After init(dev); PCI: 00:02.0 init Unexpected Exception: 6 @ 10:00207fbd - Halting Code: 0 eflags: 00010013 eax: 00226358 ebx: 00226358 ecx: 0021ea74 edx: 0001 edi: 0021ea74 esi: 0001 ebp: 0023fff4 esp: 0023ff50 Now I know that the the exception comes up in the corresponding init(dev) for the PCI: 00:02.0 device. So I disabled PCI 2.0 in the device tree and it just doesn't has any effect even it tells me that PCI 2.0 enabled 0 at boot times, it stucks at the same place. Thanks, Knut Kujat -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Problems compiling H8DMR_FAM10 because of section overlaps.
Marc Jones escribió: On Wed, Dec 16, 2009 at 10:04 AM, Peter Stuge pe...@stuge.se wrote: Knut Kujat wrote: I'm only getting rubbish from the serial using standard settings 115200 8n1. Some suggestions? Try all other speeds. It's not uncommon for a clock multiplier to be off, causing double or half the expected speed. As Peter said, it is probably the SIO clock setting. Check the setup in cach_as_ram_auto.c. Marc thanks for your replies. And yep I had to use a different speed to start seeing things and now it's working ok. Not at a 100% but I can see enough to see where it's failing ;). thanks, Knut Kujat. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] Problems compiling H8DMR_FAM10 because of section overlaps.
Hello, I'm now trying to get coreboot working on a Supermicro H8QME-2+ board. This board is really similar to the H8DMR/H8DMR_FAM10 boards already supported by coreboot. Since my board is populated with 4 Opteron family 10 processors I thought of trying to compile the H8DMR_FAM10 to get a rom and flash it to board to see what happens. But compiling I got the section overlaps error since its recommended to increase the ROM_IMAGE_SIZE I added the following lines to Kconfig: config ROM_IMAGE_SIZE hex default 0x15800 depends on BOARD_SUPERMICRO_H8DMR_FAM10 than a made a make distclean, make config, make and got following message: /usr/lib64/gcc/x86_64-suse-linux/4.3/../../../../x86_64-suse-linux/bin/ld: section .reset [fff0 - ] overlaps section .rom [5800 - 0001929f] /usr/lib64/gcc/x86_64-suse-linux/4.3/../../../../x86_64-suse-linux/bin/ld: /home/knut/Documents/Supertrunk4978/build/coreboot: section .reset vma 0xfff0 overlaps previous sections Taking a good look at the ranges I increased ROM_SIZE to 0x1 and it worked but not at all because: /usr/lib64/gcc/x86_64-suse-linux/4.3/../../../../x86_64-suse-linux/bin/ld: section .id [0001fffeff58 - 0001fffeff7f] overlaps section .rom [0001fffe - 00013a9f] /usr/lib64/gcc/x86_64-suse-linux/4.3/../../../../x86_64-suse-linux/bin/ld: /home/knut/Documents/Supertrunk4978/build/coreboot: section .id vma 0x1fffeff58 overlaps previous sections /usr/lib64/gcc/x86_64-suse-linux/4.3/../../../../x86_64-suse-linux/bin/ld: /home/knut/Documents/Supertrunk4978/build/coreboot: section .romstrap vma 0x1fffeffa0 overlaps previous sections now it's .id that overlaps section .rom and not .reset :( Now I followed the instructions on the coreboot side about section overlaps and I did this: 00013a9f-0001fffeff58= 3b47 = 3b48 config ROM_IMAGE_SIZE hex default 0x13b48 depends on BOARD_SUPERMICRO_H8DMR_FAM10 make distclean, make config, make and got /usr/lib64/gcc/x86_64-suse-linux/4.3/../../../../x86_64-suse-linux/bin/ld: section .id [00013aa0 - 00013ac7] overlaps section .rom [0001fffe3b48 - 000175ef] /usr/lib64/gcc/x86_64-suse-linux/4.3/../../../../x86_64-suse-linux/bin/ld: /home/knut/Documents/Supertrunk4978/build/coreboot: section .id vma 0x13aa0 overlaps previous sections /usr/lib64/gcc/x86_64-suse-linux/4.3/../../../../x86_64-suse-linux/bin/ld: /home/knut/Documents/Supertrunk4978/build/coreboot: section .romstrap vma 0x13ae8 overlaps previous sections I can see that no only the .rom range changed but also the .id range should it do that?? So what can I do to make it work? A little frustrated I successfully compiled the H8DMR rom and flashed it into the bios chip thinking that at least some debug messages should appear since on both boards the way to the winbond chip is the same but I only got some ·$·)?· rubbish. I of course tested the serial before and it worked fine. thanks, Knut Kujat. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Problems compiling H8DMR_FAM10 because of section overlaps.
Patrick Georgi escribió: Am 16.12.2009 15:30, schrieb Knut Kujat: Hello, I'm now trying to get coreboot working on a Supermicro H8QME-2+ board. This board is really similar to the H8DMR/H8DMR_FAM10 boards already supported by coreboot. Since my board is populated with 4 Opteron family 10 processors I thought of trying to compile the H8DMR_FAM10 to get a rom and flash it to board to see what happens. But compiling I got the section overlaps error since its recommended to increase the ROM_IMAGE_SIZE I added the following lines to Kconfig: Fam10 is not supported with kconfig yet. Regards, Patrick Georgi Aham, thx for the hint. Now it worked building it with ./builtarget but I'm only getting rubbish from the serial using standard settings 115200 8n1. Some suggestions? thx, Knut Kujat. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Coreboot fails to initialize on ASUS A8V-E SE
Rudolf Marek escribió: Thank you. I tried to make it work here too. I can confirm now both versions actually boots. I had to disable the ROM execution inside coreboot - the VGA BIOS did something bad. The only remaining issue is normal/fallback stuff. I had to disable the normal execution. It does not even work with buildtarget. Otherwise the board boots fine. It looks once I had some troubles with PCI resource allocation inside linux but I was not able to reproduce that. Knut please juts save the .config and do make distclean restore the .config make eventually there can be one more hidden file .xcompile or something which did smth wrong to the build too. Knut, if you like to have CPU powersafe working please let me know. We dont have automatic generation code for the old family which is hardwired anyway. You will need to copy the setup from orig bios DSDT/SSDT. No, not necessary but thank you! Myles, Acking your patch here. Acked-by: Rudolf Marek r.ma...@assembler.cz Commited with: +config HEAP_SIZE +hex +default 0x4 +depends on BOARD_ASUS_A8V_E_SE + Committed revision 4978. Rudolf Hello everyone, yes I can confirm that the Kconfig build method work for me too. As Rudolf said I had to disable VGA ROM as well otherwise it will came up with a exception error. It's necessary to have Serial port console output set to yes or it won't compile. Now I will start the next Board a Supermicro H8QME-2+ :) see how this works... bye and thank you all!! -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Coreboot fails to initialize on ASUS A8V-E SE
Myles Watson escribió:
I tried pushing the stuck to 2000 4000 and even 2 but nothing
it still stucks at the same place: setting up some printk I found
out that it hangs :
void pci_write_config16(device_t dev, unsigned where, uint16_t val)
{
struct bus *pbus = get_pbus(dev);
ops_pci_bus(pbus)-write16(pbus, dev-bus-secondary,
dev-path.pci.devfn, where, val); HERE!!
}
I think your problem is earlier. This just happens to be where it
catches up with you.
aha, ok!
btw, what do you mean by memory problem because as I said before I
already switched my dimms whithout any results.
I meant that it's possible that RAM is not initialized correctly.
Sometimes cache will get you a long ways.
I attached the whole boot sequence.
Thanks. The device enumeration looks wrong. There are a lot of
devices that are found, and there are a lot of sequences like this:
Capability: type 0x10 @ 0x58
Capability: type 0x01 @ 0x50
Capability: type 0x10 @ 0x58
Capability: type 0x01 @ 0x50
Capability: type 0x10 @ 0x58
Capability: type 0x01 @ 0x50
Could you send an lspci -tvnn of your board?
Of course, please find it attached.
I really appreciate your help, thx!
No problem.
Myles
THX,
Knut Kujat
-[:00]-+-00.0 VIA Technologies, Inc. K8T890 Host Bridge [1106:0238]
+-00.1 VIA Technologies, Inc. K8T890 Host Bridge [1106:1238]
+-00.2 VIA Technologies, Inc. K8T890 Host Bridge [1106:2238]
+-00.3 VIA Technologies, Inc. K8T890 Host Bridge [1106:3238]
+-00.4 VIA Technologies, Inc. K8T890 Host Bridge [1106:4238]
+-00.5 VIA Technologies, Inc. K8T890 I/O APIC Interrupt Controller
[1106:5238]
+-00.7 VIA Technologies, Inc. K8T890 Host Bridge [1106:7238]
+-01.0-[:01]--
+-02.0-[:02]--+-00.0 ATI Technologies Inc RV370 [Sapphire X550
Silent] [1002:5b63]
| \-00.1 ATI Technologies Inc RV370 secondary
[Sapphire X550 Silent] [1002:5b73]
+-03.0-[:03]--
+-03.1-[:04]--
+-03.2-[:05]00.0 Marvell Technology Group Ltd. 88E8053
PCI-E Gigabit Ethernet Controller [11ab:4362]
+-03.3-[:06]--
+-0c.0 3Com Corporation 3c905B 100BaseTX [Cyclone] [10b7:9055]
+-0f.0 VIA Technologies, Inc. VIA VT6420 SATA RAID Controller
[1106:3149]
+-0f.1 VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT823x/A/C
PIPC Bus Master IDE [1106:0571]
+-10.0 VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller
[1106:3038]
+-10.1 VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller
[1106:3038]
+-10.2 VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller
[1106:3038]
+-10.3 VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller
[1106:3038]
+-10.4 VIA Technologies, Inc. USB 2.0 [1106:3104]
+-11.0 VIA Technologies, Inc. VT8237 ISA bridge
[KT600/K8T800/K8T890 South] [1106:3227]
+-11.5 VIA Technologies, Inc. VT8233/A/8235/8237 AC97 Audio
Controller [1106:3059]
+-11.6 VIA Technologies, Inc. AC'97 Modem Controller [1106:3068]
+-18.0 Advanced Micro Devices [AMD] K8 [Athlon64/Opteron]
HyperTransport Technology Configuration [1022:1100]
+-18.1 Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Address
Map [1022:1101]
+-18.2 Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] DRAM
Controller [1022:1102]
\-18.3 Advanced Micro Devices [AMD] K8 [Athlon64/Opteron]
Miscellaneous Control [1022:1103]
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Coreboot fails to initialize on ASUS A8V-E SE
Rudolf Marek escribió: Hi, Sorry I did not find time to test on mine board (if it still boots). Your PCI stuff looks normal. Can you try with just one DDR module? Rudolf Hello, I already tried switching DDR modules in different positions and of course with only one to test if one of them is broken. But no changes! :( Thanks, Knut Kujat -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Coreboot fails to initialize on ASUS A8V-E SE
Rudolf Marek escribió: Hi, Can you test with revision 3593? OK, I'll try it ! I think you will need to do - buildtarget stuff ;) Rudolf Thx -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Coreboot fails to initialize on ASUS A8V-E SE
Rudolf Marek escribió: Hi, Can you test with revision 3593? I think you will need to do - buildtarget stuff ;) Rudolf Hi, It fails compiling and don't know exactly why: gcc -m32 -nostdlib -nostartfiles -static -o coreboot -T ldscript.ld crt0.o nm -n coreboot | sort coreboot.map objcopy --gap-fill 0xff -O binary coreboot coreboot.strip gcc -o buildrom /home/knuku/Documents/OldCor/coreboot/coreboot-v2/util/buildrom/buildrom.c cp /home/knuku/bios.bin.elf payload ./buildrom coreboot.strip coreboot.rom payload 0x2 0x4 coreboot.strip: Value too large for defined data type make[1]: *** [coreboot.rom] Error 2 make[1]: se sale del directorio `/home/knuku/Documents/OldCor/coreboot/coreboot-v2/targets/asus/a8v-e_se/asus_a8v-e_se/normal' make: *** [normal/coreboot.rom] Error 1 I did: ./buildtarget asus/a8v-e_se cd asus/a8v-e_se (set the right path to the payload in Config.lb) cd asus_a8v-e_se make I tried with the same payload I did with the newer revisions filo.elf and then I tried a already compiled seabios elf. thx, Knut Kujat -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Using coreboot
Michael Lustfield escribió: I guess I missed part of this.. Here's lspci run as root. The system is a Sony Vaio VGN-FZ240E. I hope this help more. Wow, a Vaio. Would like to know how do you manage a BIOS recovery once you flashed the chip with a not working .rom? Do you actually have to put it into pieces to reach the socket or the soldered chip? thx, Knut Kujat -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Coreboot fails to initialize on ASUS A8V-E SE
Rudolf Marek escribió: Hi, Good news! Please can you try the newer once? Also, I would recommend to use seabios and ./buildtarget build method for this board because I think kconfig was not tested. I would suggest to go up to revision like 4096 ;) or go like binary search to find out where it broke. So if 4096 works go to 4500 etc else go to 3600... etc OK, will try it! You could try to run Seabios as payload. I will try to test the board next week. Will be back Sunday night. Folks are often on IRC but you need to be more patient. Yes I know! not my strength ;) Rudolf Thx, Knut Kujat -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Coreboot fails to initialize on ASUS A8V-E SE
Myles Watson escribió: do_pci_scan_bridge returns max 1 do_pci_scan_bridge for PCI: 00:02.0 PCI: pci_scan_bus for bus 02 POST: 0x24 malloc Enter, size 1092, free_mem_ptr 0014bffc Error! malloc: Out of memory (free_mem_ptr = free_mem_end_ptr)POST: 0xff Try increasing the heap size in Kconfig. Thanks, Myles Morning :) Yip pushing the heap size to 0x4 made the difference. But it still not booting :( Now it stucks at: POST: 0x88 Enabling resources... PCI: 00:18.0 cmd - 00 PCI: 00:00.0 subsystem - 00/00 PCI: 00:00.0 cmd - 06 PCI: 00:00.1 cmd - 06 PCI: 00:00.2 cmd - 06 PCI: 00:00.3 cmd - 06 PCI: 00:00.4 cmd - 06 PCI: 00:00.5 cmd - 06 PCI: 00:00.7 cmd - 06 PCI: 00:01.0 bridge ctrl - 0003 PCI: 00:01.0 cmd - 07 PCI: 00:02.0 bridge ctrl - 000b PCI: 00:02.0 cmd - 07 Here it just stops and does nothing! according to lspci PCI: 00:02.0 is the K8T890 PCI to PCI Bridge Controller. Any hints? btw, I'm getting some errors like: PCI: 02:19.0 10 * [0xc800 - 0xcfff] prefmem PCI: 02:19.0 10 * [0xc800 - 0xcfff] prefmem !! Resource didn't fit !! aligned base e000 size 800 limit febf e7ff needs to be = febf (limit) or like: ERROR: PCI: 00:11.5 10 io size: 0x000100 not assigned Do I have to be worried about them?? -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Coreboot fails to initialize on ASUS A8V-E SE
Knut Kujat escribió: Myles Watson escribió: do_pci_scan_bridge returns max 1 do_pci_scan_bridge for PCI: 00:02.0 PCI: pci_scan_bus for bus 02 POST: 0x24 malloc Enter, size 1092, free_mem_ptr 0014bffc Error! malloc: Out of memory (free_mem_ptr = free_mem_end_ptr)POST: 0xff Try increasing the heap size in Kconfig. Thanks, Myles Morning :) Yip pushing the heap size to 0x4 made the difference. But it still not booting :( Now it stucks at: POST: 0x88 Enabling resources... PCI: 00:18.0 cmd - 00 PCI: 00:00.0 subsystem - 00/00 PCI: 00:00.0 cmd - 06 PCI: 00:00.1 cmd - 06 PCI: 00:00.2 cmd - 06 PCI: 00:00.3 cmd - 06 PCI: 00:00.4 cmd - 06 PCI: 00:00.5 cmd - 06 PCI: 00:00.7 cmd - 06 PCI: 00:01.0 bridge ctrl - 0003 PCI: 00:01.0 cmd - 07 PCI: 00:02.0 bridge ctrl - 000b PCI: 00:02.0 cmd - 07 Here it just stops and does nothing! according to lspci PCI: 00:02.0 is the K8T890 PCI to PCI Bridge Controller. Any hints? Hi again, It solves itself don't know how?! I just cleaned up some printfs recompiled and it started working till: POST: 0x89 Initializing CBMEM area to 0x7fff (65536 bytes) Adding CBMEM entry as no. 1 Moving GDT to 7fff0200...ok High Tables Base is 7fff. POST: 0x9c Adding CBMEM entry as no. 2 ACPI: Writing ACPI tables at 7fff0400... ACPI: * FACS ACPI: * DSDT @ 7fff0508 Length 44e ACPI: * FADT ACPI: added table 1/32 Length now 40 ACPI:* MADT ACPI: added table 2/32 Length now 44 ACPI:* MCFG PCI: 00:00.5 missing resource: 61 POST: 0xff POST: 0xff is a bad thing right? So how do I fix this? THX, Knut Kujat -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Coreboot fails to initialize on ASUS A8V-E SE
Sorry for spamming the maillist!!! but it stops again at: PCI: 00:02.0 cmd - 07 I haven't changed anything! whats wrong? :( bye! Knut Kujat escribió: Knut Kujat escribió: Myles Watson escribió: do_pci_scan_bridge returns max 1 do_pci_scan_bridge for PCI: 00:02.0 PCI: pci_scan_bus for bus 02 POST: 0x24 malloc Enter, size 1092, free_mem_ptr 0014bffc Error! malloc: Out of memory (free_mem_ptr = free_mem_end_ptr)POST: 0xff Try increasing the heap size in Kconfig. Thanks, Myles Morning :) Yip pushing the heap size to 0x4 made the difference. But it still not booting :( Now it stucks at: POST: 0x88 Enabling resources... PCI: 00:18.0 cmd - 00 PCI: 00:00.0 subsystem - 00/00 PCI: 00:00.0 cmd - 06 PCI: 00:00.1 cmd - 06 PCI: 00:00.2 cmd - 06 PCI: 00:00.3 cmd - 06 PCI: 00:00.4 cmd - 06 PCI: 00:00.5 cmd - 06 PCI: 00:00.7 cmd - 06 PCI: 00:01.0 bridge ctrl - 0003 PCI: 00:01.0 cmd - 07 PCI: 00:02.0 bridge ctrl - 000b PCI: 00:02.0 cmd - 07 Here it just stops and does nothing! according to lspci PCI: 00:02.0 is the K8T890 PCI to PCI Bridge Controller. Any hints? Hi again, It solves itself don't know how?! I just cleaned up some printfs recompiled and it started working till: POST: 0x89 Initializing CBMEM area to 0x7fff (65536 bytes) Adding CBMEM entry as no. 1 Moving GDT to 7fff0200...ok High Tables Base is 7fff. POST: 0x9c Adding CBMEM entry as no. 2 ACPI: Writing ACPI tables at 7fff0400... ACPI: * FACS ACPI: * DSDT @ 7fff0508 Length 44e ACPI: * FADT ACPI: added table 1/32 Length now 40 ACPI:* MADT ACPI: added table 2/32 Length now 44 ACPI:* MCFG PCI: 00:00.5 missing resource: 61 POST: 0xff POST: 0xff is a bad thing right? So how do I fix this? THX, Knut Kujat -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Coreboot fails to initialize on ASUS A8V-E SE
ron minnich escribió: On Thu, Dec 10, 2009 at 2:33 AM, Knut Kujat kn...@gap.upv.es wrote: Sorry for spamming the maillist!!! but it stops again at: PCI: 00:02.0 cmd - 07 I haven't changed anything! whats wrong? :( random halts and errors -- I think myles is right grow stack but maybe it is memory. ron no, I don't use crossgcc I tried to install it with ./buildgcc but it fails on downloading the second tar ball. The weird thing is that it exactly once passed this point and it got to build the apci table. But as I said that only occurred once and trust me I tried it a whole bunch of times. I switched my dimms several times in different slots I tried with only one to see if the other is broken or something but nothing. So I guess next thing will be stack size. Thanks, Knut Kujat -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Coreboot fails to initialize on ASUS A8V-E SE
Rudolf Marek escribió: Hi, Try experimenting with the position of used memory slots. Maybe you just need to put DIMMS into right places ;) I think I used the slot closest to CPU then one empty and then the second DIM and then the closest to edge empty. Rudolf Hello, yes switching memory slots to CPU yes no yes no worked perfectly. Now I'm stucked with dev_enumeration more precisely scan_bus fails with a malloc error. I already had this error with PCI: 00:10.1 - 00:10.4 (the USB) I disabled them in the device tree with /device pci 10.1 off end /but now it fails again and i can't just disable the whole PCI bus 2 since the VGA is on it. PCI: 01:1d.0, bad id 0x PCI: 01:1e.0, bad id 0x PCI: 01:1f.0, bad id 0x POST: 0x25 PCI: pci_scan_bus returning with max=001 POST: 0x55 do_pci_scan_bridge returns max 1 do_pci_scan_bridge for PCI: 00:02.0 PCI: pci_scan_bus for bus 02 POST: 0x24 malloc Enter, size 1092, free_mem_ptr 0014bffc Error! malloc: Out of memory (free_mem_ptr = free_mem_end_ptr)POST: 0xff Thanks again, without the maillist i would be lost! :) -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Coreboot fails to initialize on ASUS A8V-E SE
Myles Watson escribió:
-Original Message-
From: Knut Kujat [mailto:kn...@gap.upv.es]
Sent: Saturday, December 05, 2009 5:57 AM
To: Myles Watson
Cc: 'Jonathan Rogers'; coreboot@coreboot.org
Subject: Re: [coreboot] Coreboot fails to initialize on ASUS A8V-E SE
Hi,
I'm trying to build coreboot for the exact same board and getting to
the same point as Jonathan Rogers. I also tried with the patch and same
result it hangs at now booting... fallback. I inserted some prints
and get till
else if (do_normal_boot()) {
printf_info(debug6);
goto normal_image;
Great.
any suggestions?
There is no normal_image with Kconfig yet. The quick way to test would be
to change all normal_image to fallback_image, or any other way to make sure
it never jumps to normal_image.
Hello,
worked fine now I'm getting a little further ;) :
coreboot-2.3 Fri Dec 4 20:15:37 CET 2009
starting...
now booting...
real_main
core0 started:
now booting... Core0 started
started ap apicid:
SBLink=00
NC node|link=00
K8T890 found at LDT 00 Agreed on width: 01 CPU programmed to HT freq: 06
VIA HT caps: 0075
ht reset -
soft reset
coreboot-2. normal_image replaced with fallback_imageWelcome to the
real_main!
coreboot-2.3 Fri Dec 4 20:15:37 CET 2009 starting...
now booting... real_main
core0 started:
now booting... Core0 started
started ap apicid:
SBLink=00
NC node|link=00
K8T890 found at LDT 00 Agreed on width: 01 CPU programmed to HT freq: 06
VIA HT caps: 0075
Current fid_cur: 0x10, fid_max: 0x10
Requested fid_new: 0x10
Debug: after init_fidvid_bsp
Debug: after allow_all_aps_stop
Debug: after fill_mem_ctrl
Debug: after enable_smbus
Debug: after memreset_setup
Ram1.00
Ram2.00
Device error
Device error
No memory for this cpu
Ram3
No memory
but now it seems that coreboot doesn't find any ram. I already tried
with patched Kconfig and without same result.
thx,
Knut Kujat
Thanks,
Myles
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Coreboot fails to initialize on ASUS A8V-E SE
Myles Watson escribió: worked fine now I'm getting a little further ;) : Good. coreboot-2.3 Fri Dec 4 20:15:37 CET 2009 starting... now booting... real_main core0 started: now booting... Core0 started started ap apicid: SBLink=00 NC node|link=00 K8T890 found at LDT 00 Agreed on width: 01 CPU programmed to HT freq: 06 VIA HT caps: 0075 ht reset - soft reset coreboot-2. normal_image replaced with fallback_imageWelcome to the real_main! coreboot-2.3 Fri Dec 4 20:15:37 CET 2009 starting... now booting... real_main core0 started: now booting... Core0 started started ap apicid: SBLink=00 NC node|link=00 K8T890 found at LDT 00 Agreed on width: 01 CPU programmed to HT freq: 06 VIA HT caps: 0075 Current fid_cur: 0x10, fid_max: 0x10 Requested fid_new: 0x10 Debug: after init_fidvid_bsp Debug: after allow_all_aps_stop Debug: after fill_mem_ctrl Debug: after enable_smbus Debug: after memreset_setup Ram1.00 Ram2.00 Device error Device error No memory for this cpu Ram3 No memory but now it seems that coreboot doesn't find any ram. I already tried with patched Kconfig and without same result. I haven't played with RAM initialization much. The Device error message is coming from the smbus, so I would try to see how that is configured and put more debugging statements in there. I see that enable_smbus ran, so I don't know what's missing. Hopefully someone who knows more will chime in. Is there a cmos option that could be causing trouble? I'd check that too since the board was choosing to do a normal boot. Thanks, Myles Hi, thanks for your help so far. I cleared the CMOS before restart but nothing. Ram1.00 setting up CPU00 northbridge registers done. Ram2.00 Debug: in smbus_read_byte Debug: after smbus_reset Debug: after SMBUS_DELAY (first) Debug: after smbus_wait-until_ready (first) Debug: after SMBUS_DELAY (second) Device error Debug: smbus_wait-until_ready (second) Debug: out smbus_read_byte Debug: in smbus_read_byte Debug: after smbus_reset Debug: after SMBUS_DELAY (first) Debug: after smbus_wait-until_ready (first) Debug: after SMBUS_DELAY (second) Debug: smbus_wait-until_ready (second) Debug: out smbus_read_byte Debug: in smbus_read_byte Debug: after smbus_reset Debug: after SMBUS_DELAY (first) Debug: after smbus_wait-until_ready (first) Debug: after SMBUS_DELAY (second) Device error Debug: smbus_wait-until_ready (second) Debug: out smbus_read_byte Debug: in smbus_read_byte Debug: after smbus_reset Debug: after SMBUS_DELAY (first) Debug: after smbus_wait-until_ready (first) Debug: after SMBUS_DELAY (second) Debug: smbus_wait-until_ready (second) Debug: out smbus_read_byte No memory for this cpu Ram3 No memory This board has 4 sockets but only 2 are populated with 1GB dimms each. Could the other empty two sockets be the device error, which is generated by the smbus_wait_until_ready function? But why would it say that there is no memory at all? Yet another question, I can see PRINT_DEBUG in vt8237r_early_smbus.c but i can't see them on the serial although I have the highest message level. Why? thx, Knut Kujat -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Coreboot fails to initialize on ASUS A8V-E SE
Hi,
I'm trying to build coreboot for the exact same board and getting to
the same point as Jonathan Rogers. I also tried with the patch and same
result it hangs at now booting... fallback. I inserted some prints
and get till
else if (do_normal_boot()) {
printf_info(debug6);
goto normal_image;
any suggestions?
thx and have a nice weekend.
I applied the patch, but unfortunately, it still hangs in the same
place.
Did you check with hexdump to make sure it was effective?
Does it hang in the same place with a cold boot, or only on warm reset?
hexdump -C build/coreboot.rom | tail
*
0007ff80 aa 00 44 50 c2 0f 97 61 aa 00 44 50 c2 0f 97 61
|..DP...a..DP...a|
*
0007ffa0 aa 00 44 50 c2 0f 97 61 00 00 00 00 00 00 00 00
|..DP...a|
0007ffb0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
||
*
0007ffd0 80 ff 0f 00 00 00 41 53 55 53 00 41 38 56 2d 45
|..ASUS.A8V-E|
0007ffe0 20 53 45 00 2a 00 00 00 25 00 00 00 00 00 08 00 |
SE.*...%...|
0007fff0 e9 11 00 ff ff 00 00 00 e9 5f 00 ff e0 ff fe ff
|._..|
0008
Thanks,
Myles
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
--
Knut Kujat
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] Qemu and SeaBios.
Hi, since I want to use SeaBios on my real MoBo I wanted to try it out first using Qemu so I compiled coreboot v2 with the emulation MoBo and using the latest seabios-0.4.2. Now the problem is that qemu is booting all the time without getting seabios fully loaded: Got a payload Loading segment from rom address 0xfffc6878 data (compression=1) malloc Enter, size 36, free_mem_ptr 00119130 malloc 00119130 New segment dstaddr 0xef000 memsize 0x11000 srcaddr 0xfffc68b0 filesize 0x8612 (cleaned up) New segment addr 0xef000 size 0x11000 offset 0xfffc68b0 filesize 0x8612 Loading segment from rom address 0xfffc6894 Entry Point 0x000fc1ec Loading Segment: addr: 0x000ef000 memsz: 0x00011000 filesz: 0x8612 lb: [0x0010, 0x0011c000) Post relocation: addr: 0x000ef000 memsz: 0x00011000 filesz: 0x8612 using LZMA lzma: Decoding error = 1 [ 0x000ef000, 000ef000, 0x0010) - fffc68b0 Clearing Segment: addr: 0x000ef000 memsz: 0x00011000 dest 000ef000, end 0010, bouncebuffer 3fc8000 Loaded segments Jumping to boot code at fc1ec entry= 0x000fc1ec lb_start = 0x0010 lb_size = 0x0001c000 adjust = 0x03ee4000 buffer = 0x03fc8000 elf_boot_notes = 0x0010c25c adjusted_boot_notes = 0x03ff025c -- reboots Now I'm concerned that this could be happening on the real board,too. I already tried to compile seabios from the source same result. I tried to use it with a linux.img to see if it boots but nothing! I'm having the same problem with the ready to use coreboot v2 + SeaBios from the coreboot wiki. any suggestions? I have a coreboot + seabios compiled and ready to flash it to the real board but I'm now scared like hell it just will boot and boot. thx, Knut Kujat -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] Payload for ASUS A8V-E SE
Hi, what should I use as a payload for ASUS A8V-E SE tried to build one with buildrom but it no matter what I do it keeps saying that I have no .mk file for this board. I tried to build a payload with mkelfImage but it creates .elf to big to fit on the chip (4Mb). What should I do? Would a elf from a bootloader like grub be a solution? Does anyone has a payload for this board I could use? thx in advanced. Knut Kujat -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] building coreboot for A8V-E SE compiling errors
Hi,
I'm trying to get coreboot running on a A8V-E SE MOBO with a Athlon64
3800+ on it, I have Suse 11.0 running on it and tried to compile
coreboot. The first make worked fine I set up all the option I think
necessary. But at the second time I execute make it stops with multiple
errors:
GEN build.h
CC lib/version.o
AR coreboot.a
CC coreboot_ram.o
CC coreboot_ram
/usr/lib64/gcc/x86_64-suse-linux/4.3/../../../../x86_64-suse-linux/bin/ld:
warning: .note.gnu.build-id section discarded, --build-id ignored.
HOSTCXX util/cbfstool/minilzma.o
/home/knut/Documents/trunk1/util/cbfstool/lzma/minilzma.cc:25:33: error:
C/Common/MyInitGuid.h: No existe el fichero o el directorio
/home/knut/Documents/trunk1/util/cbfstool/lzma/minilzma.cc:26:46: error:
C/7zip/Compress/LZMA/LZMAEncoder.h: No existe el fichero o el directorio
/home/knut/Documents/trunk1/util/cbfstool/lzma/minilzma.cc:212:42:
error: C/7zip/Decompress/LzmaDecode.h: No existe el fichero o el directorio
/home/knut/Documents/trunk1/util/cbfstool/lzma/minilzma.cc:213:42:
error: C/7zip/Decompress/LzmaDecode.c: No existe el fichero o el directorio
/home/knut/Documents/trunk1/util/cbfstool/lzma/minilzma.cc:68: error:
‘UInt32’ does not name a type
/home/knut/Documents/trunk1/util/cbfstool/lzma/minilzma.cc:102: error:
expected class-name before ‘,’ token
/home/knut/Documents/trunk1/util/cbfstool/lzma/minilzma.cc:103: error:
expected class-name before ‘{’ token
/home/knut/Documents/trunk1/util/cbfstool/lzma/minilzma.cc:107: error:
‘MY_UNKNOWN_IMP’ does not name a type
/home/knut/Documents/trunk1/util/cbfstool/lzma/minilzma.cc:114: error:
‘Read’ has not been declared
/home/knut/Documents/trunk1/util/cbfstool/lzma/minilzma.cc:114: error:
‘UInt32’ has not been declared
/home/knut/Documents/trunk1/util/cbfstool/lzma/minilzma.cc:114: error:
‘UInt32’ has not been declared
/home/knut/Documents/trunk1/util/cbfstool/lzma/minilzma.cc:114: error:
ISO C++ forbids declaration of ‘STDMETHOD’ with no type
/home/knut/Documents/trunk1/util/cbfstool/lzma/minilzma.cc:114: error:
‘STDMETHOD’ declared as function returning a function
/home/knut/Documents/trunk1/util/cbfstool/lzma/minilzma.cc:117: error:
‘STDMETHODIMP’ does not name a type
/home/knut/Documents/trunk1/util/cbfstool/lzma/minilzma.cc:130: error:
expected class-name before ‘,’ token
/home/knut/Documents/trunk1/util/cbfstool/lzma/minilzma.cc:131: error:
expected class-name before ‘{’ token
/home/knut/Documents/trunk1/util/cbfstool/lzma/minilzma.cc:132: error:
‘Byte’ was not declared in this scope
/home/knut/Documents/trunk1/util/cbfstool/lzma/minilzma.cc:132: error:
template argument 1 is invalid
/home/knut/Documents/trunk1/util/cbfstool/lzma/minilzma.cc:132: error:
template argument 2 is invalid
/home/knut/Documents/trunk1/util/cbfstool/lzma/minilzma.cc:135: error:
‘MY_UNKNOWN_IMP’ does not name a type
/home/knut/Documents/trunk1/util/cbfstool/lzma/minilzma.cc:141: error:
‘Byte’ was not declared in this scope
/home/knut/Documents/trunk1/util/cbfstool/lzma/minilzma.cc:141: error:
template argument 1 is invalid
/home/knut/Documents/trunk1/util/cbfstool/lzma/minilzma.cc:141: error:
template argument 2 is invalid
/home/knut/Documents/trunk1/util/cbfstool/lzma/minilzma.cc:143: error:
‘HRESULT’ does not name a type
/home/knut/Documents/trunk1/util/cbfstool/lzma/minilzma.cc:150: error:
‘Write’ has not been declared
/home/knut/Documents/trunk1/util/cbfstool/lzma/minilzma.cc:150: error:
‘UInt32’ has not been declared
/home/knut/Documents/trunk1/util/cbfstool/lzma/minilzma.cc:150: error:
‘UInt32’ has not been declared
/home/knut/Documents/trunk1/util/cbfstool/lzma/minilzma.cc:150: error:
ISO C++ forbids declaration of ‘STDMETHOD’ with no type
/home/knut/Documents/trunk1/util/cbfstool/lzma/minilzma.cc:150: error:
‘STDMETHOD’ declared as function returning a function
/home/knut/Documents/trunk1/util/cbfstool/lzma/minilzma.cc: In member
function ‘void COutStreamRam::Reserve(unsigned int)’:
/home/knut/Documents/trunk1/util/cbfstool/lzma/minilzma.cc:140: error:
request for member ‘reserve’ in
‘((COutStreamRam*)this)-COutStreamRam::result’, which is of non-class
type ‘int’
/home/knut/Documents/trunk1/util/cbfstool/lzma/minilzma.cc: At global
scope:
/home/knut/Documents/trunk1/util/cbfstool/lzma/minilzma.cc:153: error:
‘STDMETHODIMP’ does not name a type
/home/knut/Documents/trunk1/util/cbfstool/lzma/minilzma.cc: In function
‘const std::vectorunsigned char, std::allocatorunsigned char
LZMACompress(const std::vectorunsigned char, std::allocatorunsigned
char )’:
/home/knut/Documents/trunk1/util/cbfstool/lzma/minilzma.cc:167: error:
‘UInt32’ does not name a type
/home/knut/Documents/trunk1/util/cbfstool/lzma/minilzma.cc:169: error:
‘NCompress’ has not been declared
/home/knut/Documents/trunk1/util/cbfstool/lzma/minilzma.cc:169: error:
‘encoderSpec’ was not declared in this scope
/home/knut/Documents/trunk1/util/cbfstool/lzma/minilzma.cc:169: error:
expected type-specifier before ‘NCompress’
[coreboot] Not supported mobo, compile for a similar one?
Hi, first of all I'm new to the coreboot project and just wanted to say Hello! :) Now here my question: I have the supermicro mobo *H8QME-2+ http://www.supermicro.com/Aplus/motherboard/Opteron8000/MCP55/H8QME-2+.cfm *that is not supported by coreboot but there is a similar one at the coreboot v2 list: H8dmr http://www.supermicro.com/Aplus/motherboard/Opteron2000/MCP55/H8DMR-i2.cfm. What would happen if i compile a coreboot.rom for the H8dmr and flash into the H8QME-2+? What kind of changes do i have to do? THX and ciao. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
