tnx Joseph,
i've fixed the following (to match my 256kb bios) :
device pci_domain 0 on
device pci 0.0 on end # Host bridge chip drivers/pci/onboard device pci 1.0 on end # Onboard video register "rom_address" = "0xfffc0000" end ... end
and now the rom_address is set AND i see the device in lspci : lspci: 00:01.0 VGA compatible controller: Intel Corporation 82810E DC-133 (CGC) Chipset Graphics Controller (rev 03) lspci -n: 00:01.0 0300: 8086:7125 (rev 03)
but still no vga-output! i found the following to might suggest another problem :
PCI Expansion ROM, signature 0xaa55, INIT size 0xa000, data ptr 0x0110 PCI ROM Image, Vendor 8086, Device 0000, Device or Vendor ID mismatch Vendor 8086, Device 0000
and no "copying VGA ROM Image"... any idea where the device_id needs to be set? (the weird thing is that the device_id is shown fine on lspci -n output)
i'm attaching the complete boot log at the end of the message.
Regards, Elia Yehuda.
On Fri, Nov 7, 2008 at 3:35 AM, Joseph Smith joe@settoplinux.org wrote:
On Fri, 7 Nov 2008 03:19:35 +0200, "Elia Yehuda" z4ziggy@gmail.com wrote:
many thanks Joseph!
you sure have found the problem in the code (without even looking... remarkable).
i sure had the "CONFIG_VIDEO_MB=8" to my targets' Config.lb which was being ignored... so i've added the following (elementary) patch to coreboot-v2/src/northbridge/intel/i82810/northbridge.c :
Index: northbridge.c
--- northbridge.c (revision 3698) +++ northbridge.c (working copy) @@ -149,6 +149,16 @@ drp_value = drp_value >> 4; // >>= 4; //? mess with later tomk += (unsigned long)(translate_i82810_to_mb[drp_value]);
+#ifdef CONFIG_VIDEO_MB
/* check for VGA reserved memory */if (CONFIG_VIDEO_MB == 512) {/* FIXME: we round up the 1/2mb to 1 */tomk -= 1;} else {tomk -= CONFIG_VIDEO_MB;}+#endif
printk_debug("Setting RAM size to %d MB\n", tomk); /* Convert tomk from MB to KB. */the boot now works,
Great, that is a start :-)
but still no onboard-vga. ive noticed in pci_rom_probe() the dev->rom_address of the vga pci card is 0 (zero)! although i have the following in the mainboard/manu/type/Config.lb : ... device pci 1.0 on # Onboard video chip drivers/pci/onboard device pci 1.0 on end register "rom_address" = "0xfffc0000" end end ...
This should be:
device pci_domain 0 on device pci 0.0 on end # Host bridge chip drivers/pci/onboard device pci 1.0 on end # Onboard video register "rom_address" = "0xfff80000" end end
Hope that helps.
-- Thanks, Joseph Smith Set-Top-Linux www.settoplinux.org
complete boot log :
coreboot-2.0.0.0Fallback Fri Nov 7 04:00:16 IST 2008 starting... Ram1.00 i810 Initial registers have been set. Ram2.00 Ram3 Found DIMM in slot 00 DIMM is 0x80MB After translation, dimm_size is 0x0d No DIMM found in slot 01 DRP calculated to 0x0d RAM Enable 1: Apply NOP Sending RAM command 0x88 to 0x00000000 RAM Enable 2: Precharge all Sending RAM command 0xa8 to 0x00000000 RAM Enable 3: CBR Sending RAM command 0xe8 to 0x00000000 RAM Enable 4: Mode register set Sending RAM command 0xc8 to 0x000001d0 RAM Enable 5: Normal operation Sending RAM command 0x28 to 0x00000000 RAM Enable 6: Enable Refresh Northbridge following SDRAM init: Ram4 coreboot-2.0.0.0Fallback Fri Nov 7 04:00:16 IST 2008 booting... end c9788c81, start 12 32-bit delta 1543 calibrate_tsc 32-bit result is 1543 clocks_per_usec: 1543 Enumerating buses... scan_static_bus for Root Device APIC_CLUSTER: 0 enabled Finding PCI configuration type. PCI: Using configuration type 1 PCI_DOMAIN: 0000 enabled PCI_DOMAIN: 0000 scanning... PCI: pci_scan_bus for bus 00 PCI: 00:00.0 [8086/7124] enabled PCI: 00:01.0 [8086/7125] enabled PCI: 00:02.0, bad id 0xffffffff PCI: 00:03.0, bad id 0xffffffff PCI: 00:04.0, bad id 0xffffffff PCI: 00:05.0, bad id 0xffffffff PCI: 00:06.0, bad id 0xffffffff PCI: 00:07.0, bad id 0xffffffff PCI: 00:08.0, bad id 0xffffffff PCI: 00:09.0, bad id 0xffffffff PCI: 00:0a.0, bad id 0xffffffff PCI: 00:0b.0, bad id 0xffffffff PCI: 00:0c.0, bad id 0xffffffff PCI: 00:0d.0, bad id 0xffffffff PCI: 00:0e.0, bad id 0xffffffff PCI: 00:0f.0, bad id 0xffffffff PCI: 00:10.0, bad id 0xffffffff PCI: 00:11.0, bad id 0xffffffff PCI: 00:12.0, bad id 0xffffffff PCI: 00:13.0, bad id 0xffffffff PCI: 00:14.0, bad id 0xffffffff PCI: 00:15.0, bad id 0xffffffff PCI: 00:16.0, bad id 0xffffffff PCI: 00:17.0, bad id 0xffffffff PCI: 00:18.0, bad id 0xffffffff PCI: 00:19.0, bad id 0xffffffff PCI: 00:1a.0, bad id 0xffffffff PCI: 00:1b.0, bad id 0xffffffff PCI: 00:1c.0, bad id 0xffffffff PCI: 00:1d.0, bad id 0xffffffff PCI: 00:1e.0 [8086/2418] bus ops PCI: 00:1e.0 [8086/2418] enabled PCI: 00:1f.0 [8086/2410] bus ops PCI: 00:1f.0 [8086/2410] enabled PCI: 00:1f.1 [8086/2411] ops PCI: 00:1f.1 [8086/2411] enabled PCI: 00:1f.2 [8086/2412] ops PCI: 00:1f.2 [8086/2412] enabled PCI: 00:1f.3 [8086/2413] enabled PCI: 00:1f.4, bad id 0xffffffff PCI: 00:1f.5 [8086/2415] ops PCI: 00:1f.5 [8086/2415] enabled malloc Enter, size 1100, free_mem_ptr 00026000 malloc 0x00026000 PCI: 00:1f.6 [8086/2416] ops PCI: 00:1f.6 [8086/2416] enabled PCI: 00:1f.7, bad id 0xffffffff do_pci_scan_bridge for PCI: 00:1e.0 PCI: pci_scan_bus for bus 01 PCI: 01:00.0, bad id 0xffffffff PCI: 01:01.0, bad id 0xffffffff PCI: 01:02.0, bad id 0xffffffff PCI: 01:03.0, bad id 0xffffffff PCI: 01:04.0, bad id 0xffffffff malloc Enter, size 1100, free_mem_ptr 0002644c malloc 0x0002644c PCI: 01:05.0 [10ec/8139] enabled PCI: 01:06.0, bad id 0xffffffff PCI: 01:07.0, bad id 0xffffffff PCI: 01:08.0, bad id 0xffffffff PCI: 01:09.0, bad id 0xffffffff PCI: 01:0a.0, bad id 0xffffffff PCI: 01:0b.0, bad id 0xffffffff PCI: 01:0c.0, bad id 0xffffffff PCI: 01:0d.0, bad id 0xffffffff PCI: 01:0e.0, bad id 0xffffffff PCI: 01:0f.0, bad id 0xffffffff PCI: 01:10.0, bad id 0xffffffff PCI: 01:11.0, bad id 0xffffffff PCI: 01:12.0, bad id 0xffffffff PCI: 01:13.0, bad id 0xffffffff PCI: 01:14.0, bad id 0xffffffff PCI: 01:15.0, bad id 0xffffffff PCI: 01:16.0, bad id 0xffffffff PCI: 01:17.0, bad id 0xffffffff PCI: 01:18.0, bad id 0xffffffff PCI: 01:19.0, bad id 0xffffffff PCI: 01:1a.0, bad id 0xffffffff PCI: 01:1b.0, bad id 0xffffffff PCI: 01:1c.0, bad id 0xffffffff PCI: 01:1d.0, bad id 0xffffffff PCI: 01:1e.0, bad id 0xffffffff PCI: 01:1f.0, bad id 0xffffffff PCI: pci_scan_bus returning with max=001 do_pci_scan_bridge returns max 1 scan_static_bus for PCI: 00:1f.0 malloc Enter, size 1100, free_mem_ptr 00026898 malloc 0x00026898 malloc Enter, size 1100, free_mem_ptr 00026ce4 malloc 0x00026ce4 malloc Enter, size 1100, free_mem_ptr 00027130 malloc 0x00027130 malloc Enter, size 1100, free_mem_ptr 0002757c malloc 0x0002757c malloc Enter, size 1100, free_mem_ptr 000279c8 malloc 0x000279c8 PNP: 002e.1 enabled PNP: 002e.2 enabled PNP: 002e.5 enabled PNP: 002e.8 enabled PNP: 002e.9 enabled PNP: 002e.a enabled PNP: 002e.0 enabled PNP: 002e.3 enabled PNP: 002e.6 enabled PNP: 002e.7 enabled PNP: 002e.b enabled scan_static_bus for PCI: 00:1f.0 done PCI: pci_scan_bus returning with max=001 scan_static_bus for Root Device done done Allocating resources... Reading resources... Root Device compute_allocate_resource io: base: 00000400 size: 00000000 align: 0 gran: 0 Root Device read_resources bus 0 link: 0 PCI_DOMAIN: 0000 read_resources bus 0 link: 0 PCI: 00:1e.0 compute_allocate_resource io: base: 00000000 size: 00000000 align: 12 gran: 12 PCI: 00:1e.0 read_resources bus 1 link: 0 PCI: 00:1e.0 read_resources bus 1 link: 0 done PCI: 01:05.0 10 * [0x00000000 - 0x000000ff] io PCI: 00:1e.0 compute_allocate_resource io: base: 00000100 size: 00001000 align: 12 gran: 12 done PCI: 00:1e.0 compute_allocate_resource prefmem: base: 00000000 size: 00000000 align: 20 gran: 20 PCI: 00:1e.0 read_resources bus 1 link: 0 PCI: 00:1e.0 read_resources bus 1 link: 0 done PCI: 00:1e.0 compute_allocate_resource prefmem: base: 00000000 size: 00000000 align: 20 gran: 20 done PCI: 00:1e.0 compute_allocate_resource prefmem: base: fff00000 size: 00000000 align: 20 gran: 20 PCI: 00:1e.0 read_resources bus 1 link: 0 PCI: 00:1e.0 read_resources bus 1 link: 0 done PCI: 00:1e.0 compute_allocate_resource prefmem: base: fff00000 size: 00000000 align: 20 gran: 20 done PCI: 00:1e.0 24 <- [0x00fff00000 - 0x00ffefffff] size 0x00000000 gran 0x14 bus 01 prefmem PCI: 00:1e.0 compute_allocate_resource mem: base: 00000000 size: 00000000 align: 20 gran: 20 PCI: 00:1e.0 read_resources bus 1 link: 0 PCI: 00:1e.0 read_resources bus 1 link: 0 done PCI: 01:05.0 14 * [0x00000000 - 0x000000ff] mem PCI: 00:1e.0 compute_allocate_resource mem: base: 00000100 size: 00100000 align: 20 gran: 20 done PCI: 00:1f.0 read_resources bus 0 link: 0 PCI: 00:1f.0 read_resources bus 0 link: 0 done PCI_DOMAIN: 0000 read_resources bus 0 link: 0 done Root Device read_resources bus 0 link: 0 done PCI: 00:1e.0 1c * [0x00001000 - 0x00001fff] io PCI: 00:1f.5 10 * [0x00002000 - 0x000020ff] io PCI: 00:1f.6 10 * [0x00002400 - 0x000024ff] io PCI: 00:1f.6 14 * [0x00002800 - 0x0000287f] io PCI: 00:1f.5 14 * [0x00002880 - 0x000028bf] io PCI: 00:1f.2 20 * [0x000028c0 - 0x000028df] io PCI: 00:1f.1 20 * [0x000028e0 - 0x000028ef] io PCI: 00:1f.3 20 * [0x000028f0 - 0x000028ff] io PNP: 002e.7 60 * [0x00002c00 - 0x00002c00] io Root Device compute_allocate_resource io: base: 00002c01 size: 00002801 align: 12 gran: 0 done Root Device compute_allocate_resource mem: base: 00000000 size: 00000000 align: 0 gran: 0 Root Device read_resources bus 0 link: 0 Root Device read_resources bus 0 link: 0 done PCI: 00:01.0 10 * [0x00000000 - 0x01ffffff] prefmem PCI: 00:1e.0 20 * [0x02000000 - 0x020fffff] mem PCI: 00:01.0 14 * [0x02100000 - 0x0217ffff] mem Root Device compute_allocate_resource mem: base: 02180000 size: 02180000 align: 25 gran: 0 done Done reading resources. Allocating VGA resource PCI: 00:01.0 Setting PCI_BRIDGE_CTL_VGA for bridge PCI_DOMAIN: 0000 Setting PCI_BRIDGE_CTL_VGA for bridge Root Device Setting resources... Root Device compute_allocate_resource io: base: 00001000 size: 00002801 align: 12 gran: 0 Root Device read_resources bus 0 link: 0 Root Device read_resources bus 0 link: 0 done PCI: 00:1e.0 1c * [0x00001000 - 0x00001fff] io PCI: 00:1f.5 10 * [0x00002000 - 0x000020ff] io PCI: 00:1f.6 10 * [0x00002400 - 0x000024ff] io PCI: 00:1f.6 14 * [0x00002800 - 0x0000287f] io PCI: 00:1f.5 14 * [0x00002880 - 0x000028bf] io PCI: 00:1f.2 20 * [0x000028c0 - 0x000028df] io PCI: 00:1f.1 20 * [0x000028e0 - 0x000028ef] io PCI: 00:1f.3 20 * [0x000028f0 - 0x000028ff] io PNP: 002e.7 60 * [0x00002c00 - 0x00002c00] io Root Device compute_allocate_resource io: base: 00002c01 size: 00001c01 align: 12 gran: 0 done Root Device compute_allocate_resource mem: base: fc000000 size: 02180000 align: 25 gran: 0 Root Device read_resources bus 0 link: 0 Root Device read_resources bus 0 link: 0 done PCI: 00:01.0 10 * [0xfc000000 - 0xfdffffff] prefmem PCI: 00:1e.0 20 * [0xfe000000 - 0xfe0fffff] mem PCI: 00:01.0 14 * [0xfe100000 - 0xfe17ffff] mem Root Device compute_allocate_resource mem: base: fe180000 size: 02180000 align: 25 gran: 0 done Root Device assign_resources, bus 0 link: 0 Setting RAM size to 120 MB PCI_DOMAIN: 0000 assign_resources, bus 0 link: 0 PCI: 00:01.0 10 <- [0x00fc000000 - 0x00fdffffff] size 0x02000000 gran 0x19 prefmem PCI: 00:01.0 14 <- [0x00fe100000 - 0x00fe17ffff] size 0x00080000 gran 0x13 mem PCI: 00:01.0 30 <- [0x00fffc0000 - 0x00fffbffff] size 0x00000000 gran 0x00 romem PCI: 00:1e.0 compute_allocate_resource io: base: 00001000 size: 00001000 align: 12 gran: 12 PCI: 00:1e.0 read_resources bus 1 link: 0 PCI: 00:1e.0 read_resources bus 1 link: 0 done PCI: 01:05.0 10 * [0x00001000 - 0x000010ff] io PCI: 00:1e.0 compute_allocate_resource io: base: 00001100 size: 00001000 align: 12 gran: 12 done PCI: 00:1e.0 1c <- [0x0000001000 - 0x0000001fff] size 0x00001000 gran 0x0c bus 01 io PCI: 00:1e.0 compute_allocate_resource mem: base: fe000000 size: 00100000 align: 20 gran: 20 PCI: 00:1e.0 read_resources bus 1 link: 0 PCI: 00:1e.0 read_resources bus 1 link: 0 done PCI: 01:05.0 14 * [0xfe000000 - 0xfe0000ff] mem PCI: 00:1e.0 compute_allocate_resource mem: base: fe000100 size: 00100000 align: 20 gran: 20 done PCI: 00:1e.0 20 <- [0x00fe000000 - 0x00fe0fffff] size 0x00100000 gran 0x14 bus 01 mem PCI: 00:1e.0 assign_resources, bus 1 link: 0 PCI: 01:05.0 10 <- [0x0000001000 - 0x00000010ff] size 0x00000100 gran 0x08 io PCI: 01:05.0 14 <- [0x00fe000000 - 0x00fe0000ff] size 0x00000100 gran 0x08 mem PCI: 00:1e.0 assign_resources, bus 1 link: 0 PCI: 00:1f.0 assign_resources, bus 0 link: 0 PNP: 002e.1 60 <- [0x0000000378 - 0x000000037f] size 0x00000008 gran 0x03 io PNP: 002e.1 70 <- [0x0000000007 - 0x0000000007] size 0x00000001 gran 0x00 irq PNP: 002e.1 74 <- [0x0000000003 - 0x0000000003] size 0x00000001 gran 0x00 drq PNP: 002e.2 60 <- [0x00000003f8 - 0x00000003ff] size 0x00000008 gran 0x03 io PNP: 002e.2 70 <- [0x0000000004 - 0x0000000004] size 0x00000001 gran 0x00 irq PNP: 002e.5 60 <- [0x0000000060 - 0x0000000060] size 0x00000001 gran 0x00 io PNP: 002e.5 62 <- [0x0000000064 - 0x0000000064] size 0x00000001 gran 0x00 io PNP: 002e.5 70 <- [0x0000000001 - 0x0000000001] size 0x00000001 gran 0x00 irq PNP: 002e.5 72 <- [0x000000000c - 0x000000000c] size 0x00000001 gran 0x00 irq ERROR: PNP: 002e.0 60 io size: 0x0000000008 not assigned ERROR: PNP: 002e.0 70 irq size: 0x0000000001 not assigned ERROR: PNP: 002e.0 74 drq size: 0x0000000001 not assigned ERROR: PNP: 002e.3 60 io size: 0x0000000008 not assigned ERROR: PNP: 002e.3 70 irq size: 0x0000000001 not assigned ERROR: PNP: 002e.6 60 io size: 0x0000000008 not assigned ERROR: PNP: 002e.6 70 irq size: 0x0000000001 not assigned PNP: 002e.7 60 <- [0x0000002c00 - 0x0000002c00] size 0x00000001 gran 0x00 io ERROR: PNP: 002e.7 62 io size: 0x0000000002 not assigned ERROR: PNP: 002e.7 70 irq size: 0x0000000001 not assigned ERROR: PNP: 002e.b 60 io size: 0x0000000008 not assigned ERROR: PNP: 002e.b 70 irq size: 0x0000000001 not assigned PCI: 00:1f.0 assign_resources, bus 0 link: 0 PCI: 00:1f.1 20 <- [0x00000028e0 - 0x00000028ef] size 0x00000010 gran 0x04 io PCI: 00:1f.2 20 <- [0x00000028c0 - 0x00000028df] size 0x00000020 gran 0x05 io PCI: 00:1f.3 20 <- [0x00000028f0 - 0x00000028ff] size 0x00000010 gran 0x04 io PCI: 00:1f.5 10 <- [0x0000002000 - 0x00000020ff] size 0x00000100 gran 0x08 io PCI: 00:1f.5 14 <- [0x0000002880 - 0x00000028bf] size 0x00000040 gran 0x06 io PCI: 00:1f.6 10 <- [0x0000002400 - 0x00000024ff] size 0x00000100 gran 0x08 io PCI: 00:1f.6 14 <- [0x0000002800 - 0x000000287f] size 0x00000080 gran 0x07 io PCI_DOMAIN: 0000 assign_resources, bus 0 link: 0 Root Device assign_resources, bus 0 link: 0 Done setting resources. Done allocating resources. Enabling resources... PCI: 00:00.0 subsystem <- 00/00 PCI: 00:00.0 cmd <- 06 PCI: 00:01.0 subsystem <- 00/00 PCI: 00:01.0 cmd <- 07 PCI: 00:1e.0 bridge ctrl <- 0003 PCI: 00:1e.0 cmd <- 07 PCI: 01:05.0 cmd <- 03 PCI: 00:1f.0 cmd <- 0f w83627hf hwm smbus enabled PCI: 00:1f.1 cmd <- 01 PCI: 00:1f.2 cmd <- 01 PCI: 00:1f.3 subsystem <- 00/00 PCI: 00:1f.3 cmd <- 01 PCI: 00:1f.5 cmd <- 01 PCI: 00:1f.6 cmd <- 01 done. Initializing devices... Root Device init APIC_CLUSTER: 0 init malloc Enter, size 1100, free_mem_ptr 00027e14 malloc 0x00027e14 Initializing CPU #0 CPU: vendor Intel device 683 CPU: family 06, model 08, stepping 03 Enabling cache
Setting fixed MTRRs(0-88) Type: UC Setting fixed MTRRs(0-16) Type: WB DONE fixed MTRRs call enable_fixed_mtrr() Setting variable MTRR 0, base: 0MB, range: 64MB, type WB ADDRESS_MASK_HIGH=0xf Setting variable MTRR 1, base: 64MB, range: 32MB, type WB ADDRESS_MASK_HIGH=0xf Setting variable MTRR 2, base: 96MB, range: 16MB, type WB ADDRESS_MASK_HIGH=0xf Setting variable MTRR 3, base: 112MB, range: 8MB, type WB ADDRESS_MASK_HIGH=0xf DONE variable MTRRs Clear out the extra MTRR's call enable_var_mtrr() Leave x86_setup_var_mtrrs
MTRR check Fixed MTRRs : Enabled Variable MTRRs: Enabled
microcode_info: sig = 0x00000683 pf=0x00000010 rev = 0x00000000 Disabling local apic...done. CPU #0 Initialized PCI: 00:00.0 init pci_rom_probe() : dev->on_mainboard pci_rom_probe(): skipping for PCI: 00:00.0 = 0 PCI: 00:01.0 init pci_rom_probe() : dev->on_mainboard rom address for PCI: 00:01.0 = fffc0000 PCI Expansion ROM, signature 0xaa55, INIT size 0xa000, data ptr 0x0110 PCI ROM Image, Vendor 8086, Device 0000, Device or Vendor ID mismatch Vendor 8086, Device 0000 PCI: 00:1e.0 init PCI: 00:1f.0 init IOAPIC Southbridge enabled 2186 Southbridge APIC ID = 2000000 Set power on if power fails RTC Init PNP: 002e.1 init PNP: 002e.2 init PNP: 002e.5 init Keyboard init... PNP: 002e.8 init PNP: 002e.9 init PNP: 002e.a init PCI: 00:1f.1 init IDE0 IDE1 PCI: 00:1f.2 init PCI: 00:1f.3 init pci_rom_probe() : dev->on_mainboard pci_rom_probe(): skipping for PCI: 00:1f.3 = 0 PCI: 01:05.0 init pci_rom_probe() : !dev->on_mainboard (0/0) pci_rom_probe(): skipping for PCI: 01:05.0 = 0 PNP: 002e.0 init PNP: 002e.3 init PNP: 002e.6 init PNP: 002e.7 init PNP: 002e.b init Devices initialized Copying IRQ routing tables to 0xf0000...done. Verifing copy of IRQ routing tables at 0xf0000...done Checking IRQ routing table consistency... check_pirq_routing_table() - irq_routing_table located at: 0x000f0000 done. Moving GDT to 0x500...ok Adjust low_table_end from 0x00000530 to 0x00001000 Adjust rom_table_end from 0x000f0400 to 0x00100000
Booting 'hda1:/boot/vmlinuz-2.6.27-7-server root=/dev/sda1 ro console=ttyS0,115 200n8 console=tty0 initrd=hda1:/boot/initrd.img-2.6.27-7-server' Found Linux version 2.6.27-7-server (buildd@rothera) #1 SMP Fri Oct 24 07:37:55 UTC 2008 bzImage. Loading kernel... ok Loading initrd... ok Jumping to entry point...
On Fri, 7 Nov 2008 04:24:38 +0200, "Elia Yehuda" z4ziggy@gmail.com wrote:
tnx Joseph,
i've fixed the following (to match my 256kb bios) :
device pci_domain 0 on
device pci 0.0 on end # Host bridge chip drivers/pci/onboard device pci 1.0 on end # Onboard video register "rom_address" = "0xfffc0000" end... end
and now the rom_address is set AND i see the device in lspci : lspci: 00:01.0 VGA compatible controller: Intel Corporation 82810E DC-133 (CGC) Chipset Graphics Controller (rev 03) lspci -n: 00:01.0 0300: 8086:7125 (rev 03)
but still no vga-output! i found the following to might suggest another problem :
PCI Expansion ROM, signature 0xaa55, INIT size 0xa000, data ptr 0x0110 PCI ROM Image, Vendor 8086, Device 0000, Device or Vendor ID mismatch Vendor 8086, Device 0000
and no "copying VGA ROM Image"...
Yep that is your problem. Is there something wrong with your vga bios. It is reading the vendor id ok but the device id should be 7125. Have you checked this out? It may help you to get a valid vga bios. http://www.coreboot.org/VGA_support
yep, ive extraced my vga using awardeco which should be fine (and it does seems fine on the lspci -n, which is very frustrating)
On Fri, Nov 7, 2008 at 4:48 AM, Joseph Smith joe@settoplinux.org wrote:
On Fri, 7 Nov 2008 04:24:38 +0200, "Elia Yehuda" z4ziggy@gmail.com wrote:
tnx Joseph,
i've fixed the following (to match my 256kb bios) :
device pci_domain 0 on
device pci 0.0 on end # Host bridge chip drivers/pci/onboard device pci 1.0 on end # Onboard video register "rom_address" = "0xfffc0000" end... end
and now the rom_address is set AND i see the device in lspci : lspci: 00:01.0 VGA compatible controller: Intel Corporation 82810E DC-133 (CGC) Chipset Graphics Controller (rev 03) lspci -n: 00:01.0 0300: 8086:7125 (rev 03)
but still no vga-output! i found the following to might suggest another problem :
PCI Expansion ROM, signature 0xaa55, INIT size 0xa000, data ptr 0x0110 PCI ROM Image, Vendor 8086, Device 0000, Device or Vendor ID mismatch Vendor 8086, Device 0000
and no "copying VGA ROM Image"...
Yep that is your problem. Is there something wrong with your vga bios. It is reading the vendor id ok but the device id should be 7125. Have you checked this out? It may help you to get a valid vga bios. http://www.coreboot.org/VGA_support
-- Thanks, Joseph Smith Set-Top-Linux www.settoplinux.org
On Fri, 7 Nov 2008 04:55:41 +0200, "Elia Yehuda" z4ziggy@gmail.com wrote:
yep, ive extraced my vga using awardeco which should be fine (and it does seems fine on the lspci -n, which is very frustrating)
On Fri, Nov 7, 2008 at 4:48 AM, Joseph Smith joe@settoplinux.org wrote:
On Fri, 7 Nov 2008 04:24:38 +0200, "Elia Yehuda" z4ziggy@gmail.com wrote:
tnx Joseph,
i've fixed the following (to match my 256kb bios) :
device pci_domain 0 on
device pci 0.0 on end # Host bridge chip drivers/pci/onboard device pci 1.0 on end # Onboard video register "rom_address" = "0xfffc0000" end... end
and now the rom_address is set AND i see the device in lspci : lspci: 00:01.0 VGA compatible controller: Intel Corporation 82810E DC-133
(CGC)
Chipset Graphics Controller (rev 03) lspci -n: 00:01.0 0300: 8086:7125 (rev 03)
but still no vga-output! i found the following to might suggest another problem :
PCI Expansion ROM, signature 0xaa55, INIT size 0xa000, data ptr 0x0110 PCI ROM Image, Vendor 8086, Device 0000, Device or Vendor ID mismatch Vendor 8086, Device 0000
and no "copying VGA ROM Image"...
Yep that is your problem. Is there something wrong with your vga bios.
It
is reading the vendor id ok but the device id should be 7125. Have you checked this out? It may help you to get a valid vga bios. http://www.coreboot.org/VGA_support
coreboot uses a different pci.ids file than Linux. That's why Linux can find it but coreboot can't? Check and see if the coreboot pci.ids file includes 8086 / 7125. It may be missing and just needs to be added?
thanks for the suggestion - ive added #define PCI_DEVICE_ID_INTEL_82810E_IG 0x7125
to src/include/device/pci_ids.h but still no luck :
rom address for PCI: 00:01.0 = fffc0000 PCI Expansion ROM, signature 0xaa55, INIT size 0xa000, data ptr 0x0110 PCI ROM Image, Vendor 8086, Device 0000, Device or Vendor ID mismatch Vendor 8086, Device 0000 (Expected Vendor 8086, Device 7125)
im guessing the device_id needs to be declated somewhere in the code or maybe in the Config.lb?
Regards, Elia.
On Fri, Nov 7, 2008 at 5:06 AM, Joseph Smith joe@settoplinux.org wrote:
On Fri, 7 Nov 2008 04:55:41 +0200, "Elia Yehuda" z4ziggy@gmail.com wrote:
yep, ive extraced my vga using awardeco which should be fine (and it does seems fine on the lspci -n, which is very frustrating)
On Fri, Nov 7, 2008 at 4:48 AM, Joseph Smith joe@settoplinux.org
wrote:
On Fri, 7 Nov 2008 04:24:38 +0200, "Elia Yehuda" z4ziggy@gmail.com wrote:
tnx Joseph,
i've fixed the following (to match my 256kb bios) :
device pci_domain 0 on
device pci 0.0 on end # Host bridge chip drivers/pci/onboard device pci 1.0 on end # Onboard video register "rom_address" = "0xfffc0000" end... end
and now the rom_address is set AND i see the device in lspci : lspci: 00:01.0 VGA compatible controller: Intel Corporation 82810E DC-133
(CGC)
Chipset Graphics Controller (rev 03) lspci -n: 00:01.0 0300: 8086:7125 (rev 03)
but still no vga-output! i found the following to might suggest another problem :
PCI Expansion ROM, signature 0xaa55, INIT size 0xa000, data ptr 0x0110 PCI ROM Image, Vendor 8086, Device 0000, Device or Vendor ID mismatch Vendor 8086, Device 0000
and no "copying VGA ROM Image"...
Yep that is your problem. Is there something wrong with your vga bios.
It
is reading the vendor id ok but the device id should be 7125. Have you checked this out? It may help you to get a valid vga bios. http://www.coreboot.org/VGA_support
coreboot uses a different pci.ids file than Linux. That's why Linux can find it but coreboot can't? Check and see if the coreboot pci.ids file includes 8086 / 7125. It may be missing and just needs to be added?
-- Thanks, Joseph Smith Set-Top-Linux www.settoplinux.org
On Thu, Nov 6, 2008 at 10:27 PM, Elia Yehuda z4ziggy@gmail.com wrote:
thanks for the suggestion - ive added #define PCI_DEVICE_ID_INTEL_82810E_IG 0x7125
to src/include/device/pci_ids.h but still no luck :
rom address for PCI: 00:01.0 = fffc0000 PCI Expansion ROM, signature 0xaa55, INIT size 0xa000, data ptr 0x0110 PCI ROM Image, Vendor 8086, Device 0000, Device or Vendor ID mismatch Vendor 8086, Device 0000 (Expected Vendor 8086, Device 7125)
im guessing the device_id needs to be declated somewhere in the code or maybe in the Config.lb?
Huh? Where is the device ID of 0000 coming from? It's been a while since I've been in that part of v2, but it looks like it's coming from the rom itself. If that's the case, can you hack pci_rom.c to ignore the device ID and run the rom anyway?
-Corey
Regards, Elia.
On Fri, Nov 7, 2008 at 5:06 AM, Joseph Smith joe@settoplinux.org wrote:
On Fri, 7 Nov 2008 04:55:41 +0200, "Elia Yehuda" z4ziggy@gmail.com wrote:
yep, ive extraced my vga using awardeco which should be fine (and it
does
seems fine on the lspci -n, which is very frustrating)
On Fri, Nov 7, 2008 at 4:48 AM, Joseph Smith joe@settoplinux.org
wrote:
On Fri, 7 Nov 2008 04:24:38 +0200, "Elia Yehuda" z4ziggy@gmail.com wrote:
tnx Joseph,
i've fixed the following (to match my 256kb bios) :
device pci_domain 0 on
device pci 0.0 on end # Host bridge chip drivers/pci/onboard device pci 1.0 on end # Onboard video register "rom_address" = "0xfffc0000" end... end
and now the rom_address is set AND i see the device in lspci : lspci: 00:01.0 VGA compatible controller: Intel Corporation 82810E DC-133
(CGC)
Chipset Graphics Controller (rev 03) lspci -n: 00:01.0 0300: 8086:7125 (rev 03)
but still no vga-output! i found the following to might suggest another problem :
PCI Expansion ROM, signature 0xaa55, INIT size 0xa000, data ptr
0x0110
PCI ROM Image, Vendor 8086, Device 0000, Device or Vendor ID mismatch Vendor 8086, Device 0000
and no "copying VGA ROM Image"...
Yep that is your problem. Is there something wrong with your vga bios.
It
is reading the vendor id ok but the device id should be 7125. Have you checked this out? It may help you to get a valid vga bios. http://www.coreboot.org/VGA_support
coreboot uses a different pci.ids file than Linux. That's why Linux can find it but coreboot can't? Check and see if the coreboot pci.ids file includes 8086 / 7125. It may be missing and just needs to be added?
-- Thanks, Joseph Smith Set-Top-Linux www.settoplinux.org
-- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
found the problem - its my buggy vga.rom!!! it's missing the damn device_id!
ive patched it, and now the screen turns on upon boot, but no messages. however.... once i "modprobe i810fb" from the serial console, look and be-hold - we've got onboard-vga working!
many thanks, now if we can figure out why it wont display upon bootup it will be great.
also, another thing which troubles me - BEFORE booting begins, there are 0x00 sent to the serial for about 2 minutes (i've counted about 80 o those 0x00 being sent) and only then the coreboot messages starts to appear and the boot continues. i would appreciate eliminating this 2 minutes delay... any relevant information would be appreciated.
Regards, Elia.
On Fri, Nov 7, 2008 at 5:37 AM, Corey Osgood corey.osgood@gmail.com wrote:
On Thu, Nov 6, 2008 at 10:27 PM, Elia Yehuda z4ziggy@gmail.com wrote:
thanks for the suggestion - ive added #define PCI_DEVICE_ID_INTEL_82810E_IG 0x7125
to src/include/device/pci_ids.h but still no luck :
rom address for PCI: 00:01.0 = fffc0000 PCI Expansion ROM, signature 0xaa55, INIT size 0xa000, data ptr 0x0110 PCI ROM Image, Vendor 8086, Device 0000, Device or Vendor ID mismatch Vendor 8086, Device 0000 (Expected Vendor 8086, Device 7125)
im guessing the device_id needs to be declated somewhere in the code or maybe in the Config.lb?
Huh? Where is the device ID of 0000 coming from? It's been a while since I've been in that part of v2, but it looks like it's coming from the rom itself. If that's the case, can you hack pci_rom.c to ignore the device ID and run the rom anyway?
-Corey
Regards, Elia.
On Fri, Nov 7, 2008 at 5:06 AM, Joseph Smith joe@settoplinux.org wrote:
On Fri, 7 Nov 2008 04:55:41 +0200, "Elia Yehuda" z4ziggy@gmail.com wrote:
yep, ive extraced my vga using awardeco which should be fine (and it
does
seems fine on the lspci -n, which is very frustrating)
On Fri, Nov 7, 2008 at 4:48 AM, Joseph Smith joe@settoplinux.org
wrote:
On Fri, 7 Nov 2008 04:24:38 +0200, "Elia Yehuda" z4ziggy@gmail.com wrote:
tnx Joseph,
i've fixed the following (to match my 256kb bios) :
device pci_domain 0 on
device pci 0.0 on end # Host bridge chip drivers/pci/onboard device pci 1.0 on end # Onboard video register "rom_address" = "0xfffc0000" end... end
and now the rom_address is set AND i see the device in lspci : lspci: 00:01.0 VGA compatible controller: Intel Corporation 82810E DC-133
(CGC)
Chipset Graphics Controller (rev 03) lspci -n: 00:01.0 0300: 8086:7125 (rev 03)
but still no vga-output! i found the following to might suggest another problem :
PCI Expansion ROM, signature 0xaa55, INIT size 0xa000, data ptr
0x0110
PCI ROM Image, Vendor 8086, Device 0000, Device or Vendor ID mismatch Vendor 8086, Device 0000
and no "copying VGA ROM Image"...
Yep that is your problem. Is there something wrong with your vga bios.
It
is reading the vendor id ok but the device id should be 7125. Have you checked this out? It may help you to get a valid vga bios. http://www.coreboot.org/VGA_support
coreboot uses a different pci.ids file than Linux. That's why Linux can find it but coreboot can't? Check and see if the coreboot pci.ids file includes 8086 / 7125. It may be missing and just needs to be added?
-- Thanks, Joseph Smith Set-Top-Linux www.settoplinux.org
-- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
When exactly do those 0x0s get sent? Before ram initialization starts? Before the initial banner is sent? Before the payload is executed? "before booting" can mean a lot of things ;)
-Corey
On Thu, Nov 6, 2008 at 10:46 PM, Elia Yehuda z4ziggy@gmail.com wrote:
found the problem - its my buggy vga.rom!!! it's missing the damn device_id!
ive patched it, and now the screen turns on upon boot, but no messages. however.... once i "modprobe i810fb" from the serial console, look and be-hold - we've got onboard-vga working!
many thanks, now if we can figure out why it wont display upon bootup it will be great.
also, another thing which troubles me - BEFORE booting begins, there are 0x00 sent to the serial for about 2 minutes (i've counted about 80 o those 0x00 being sent) and only then the coreboot messages starts to appear and the boot continues. i would appreciate eliminating this 2 minutes delay... any relevant information would be appreciated.
Regards, Elia.
On Fri, Nov 7, 2008 at 5:37 AM, Corey Osgood corey.osgood@gmail.comwrote:
On Thu, Nov 6, 2008 at 10:27 PM, Elia Yehuda z4ziggy@gmail.com wrote:
thanks for the suggestion - ive added #define PCI_DEVICE_ID_INTEL_82810E_IG 0x7125
to src/include/device/pci_ids.h but still no luck :
rom address for PCI: 00:01.0 = fffc0000 PCI Expansion ROM, signature 0xaa55, INIT size 0xa000, data ptr 0x0110 PCI ROM Image, Vendor 8086, Device 0000, Device or Vendor ID mismatch Vendor 8086, Device 0000 (Expected Vendor 8086, Device 7125)
im guessing the device_id needs to be declated somewhere in the code or maybe in the Config.lb?
Huh? Where is the device ID of 0000 coming from? It's been a while since I've been in that part of v2, but it looks like it's coming from the rom itself. If that's the case, can you hack pci_rom.c to ignore the device ID and run the rom anyway?
-Corey
Regards, Elia.
On Fri, Nov 7, 2008 at 5:06 AM, Joseph Smith joe@settoplinux.orgwrote:
On Fri, 7 Nov 2008 04:55:41 +0200, "Elia Yehuda" z4ziggy@gmail.com wrote:
yep, ive extraced my vga using awardeco which should be fine (and it
does
seems fine on the lspci -n, which is very frustrating)
On Fri, Nov 7, 2008 at 4:48 AM, Joseph Smith joe@settoplinux.org
wrote:
On Fri, 7 Nov 2008 04:24:38 +0200, "Elia Yehuda" z4ziggy@gmail.com wrote: > tnx Joseph, > > i've fixed the following (to match my 256kb bios) : > > device pci_domain 0 on > > device pci 0.0 on end # Host bridge > chip drivers/pci/onboard > device pci 1.0 on end # Onboard video > register "rom_address" = "0xfffc0000" > end > ... > end > > and now the rom_address is set AND i see the device in lspci : > lspci: > 00:01.0 VGA compatible controller: Intel Corporation 82810E DC-133
(CGC)
> Chipset Graphics Controller (rev 03) > lspci -n: > 00:01.0 0300: 8086:7125 (rev 03) > > but still no vga-output! > i found the following to might suggest another problem : > > PCI Expansion ROM, signature 0xaa55, INIT size 0xa000, data ptr
0x0110
> PCI ROM Image, Vendor 8086, Device 0000, > Device or Vendor ID mismatch Vendor 8086, Device 0000 > > and no "copying VGA ROM Image"... Yep that is your problem. Is there something wrong with your vga
bios.
It
is reading the vendor id ok but the device id should be 7125. Have you checked this out? It may help you to get a valid vga bios. http://www.coreboot.org/VGA_support
coreboot uses a different pci.ids file than Linux. That's why Linux can find it but coreboot can't? Check and see if the coreboot pci.ids file includes 8086 / 7125. It may be missing and just needs to be added?
-- Thanks, Joseph Smith Set-Top-Linux www.settoplinux.org
-- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
before anything else :-) right when i turn on the pc, those zeros (0x00) starts to show on the screen (i use gtkterm in hexmode since minicom wont show me those hexed zeros), fill the screen slowly for 2 minutes, and only then the following coreboot messages shows up and the boot starts :
coreboot-2.0.0.0Fallback Fri Nov 7 04:00:16 IST 2008 starting... Ram1.00 i810 Initial registers have been set. Ram2.00 ...
so, to sum it up - turn on computer zeors on the screen for 2 minutes coreboot starts
hope this clears matters up ;)
Regards, Elia.
On Fri, Nov 7, 2008 at 7:51 AM, Corey Osgood corey.osgood@gmail.com wrote:
When exactly do those 0x0s get sent? Before ram initialization starts? Before the initial banner is sent? Before the payload is executed? "before booting" can mean a lot of things ;)
-Corey
On Thu, Nov 6, 2008 at 10:46 PM, Elia Yehuda z4ziggy@gmail.com wrote:
found the problem - its my buggy vga.rom!!! it's missing the damn device_id!
ive patched it, and now the screen turns on upon boot, but no messages. however.... once i "modprobe i810fb" from the serial console, look and be-hold - we've got onboard-vga working!
many thanks, now if we can figure out why it wont display upon bootup it will be great.
also, another thing which troubles me - BEFORE booting begins, there are 0x00 sent to the serial for about 2 minutes (i've counted about 80 o those 0x00 being sent) and only then the coreboot messages starts to appear and the boot continues. i would appreciate eliminating this 2 minutes delay... any relevant information would be appreciated.
Regards, Elia.
On Fri, Nov 7, 2008 at 5:37 AM, Corey Osgood corey.osgood@gmail.comwrote:
On Thu, Nov 6, 2008 at 10:27 PM, Elia Yehuda z4ziggy@gmail.com wrote:
thanks for the suggestion - ive added #define PCI_DEVICE_ID_INTEL_82810E_IG 0x7125
to src/include/device/pci_ids.h but still no luck :
rom address for PCI: 00:01.0 = fffc0000 PCI Expansion ROM, signature 0xaa55, INIT size 0xa000, data ptr 0x0110 PCI ROM Image, Vendor 8086, Device 0000, Device or Vendor ID mismatch Vendor 8086, Device 0000 (Expected Vendor 8086, Device 7125)
im guessing the device_id needs to be declated somewhere in the code or maybe in the Config.lb?
Huh? Where is the device ID of 0000 coming from? It's been a while since I've been in that part of v2, but it looks like it's coming from the rom itself. If that's the case, can you hack pci_rom.c to ignore the device ID and run the rom anyway?
-Corey
Regards, Elia.
On Fri, Nov 7, 2008 at 5:06 AM, Joseph Smith joe@settoplinux.orgwrote:
On Fri, 7 Nov 2008 04:55:41 +0200, "Elia Yehuda" z4ziggy@gmail.com wrote:
yep, ive extraced my vga using awardeco which should be fine (and it
does
seems fine on the lspci -n, which is very frustrating)
On Fri, Nov 7, 2008 at 4:48 AM, Joseph Smith joe@settoplinux.org
wrote:
> > > > On Fri, 7 Nov 2008 04:24:38 +0200, "Elia Yehuda" <z4ziggy@gmail.com
> wrote: > > tnx Joseph, > > > > i've fixed the following (to match my 256kb bios) : > > > > device pci_domain 0 on > > > > device pci 0.0 on end # Host bridge > > chip drivers/pci/onboard > > device pci 1.0 on end # Onboard video > > register "rom_address" = "0xfffc0000" > > end > > ... > > end > > > > and now the rom_address is set AND i see the device in lspci : > > lspci: > > 00:01.0 VGA compatible controller: Intel Corporation 82810E DC-133 (CGC) > > Chipset Graphics Controller (rev 03) > > lspci -n: > > 00:01.0 0300: 8086:7125 (rev 03) > > > > but still no vga-output! > > i found the following to might suggest another problem : > > > > PCI Expansion ROM, signature 0xaa55, INIT size 0xa000, data ptr
0x0110
> > PCI ROM Image, Vendor 8086, Device 0000, > > Device or Vendor ID mismatch Vendor 8086, Device 0000 > > > > and no "copying VGA ROM Image"... > Yep that is your problem. Is there something wrong with your vga
bios.
It > is reading the vendor id ok but the device id should be 7125. > Have you checked this out? It may help you to get a valid vga bios. > http://www.coreboot.org/VGA_support >
coreboot uses a different pci.ids file than Linux. That's why Linux can find it but coreboot can't? Check and see if the coreboot pci.ids file includes 8086 / 7125. It may be missing and just needs to be added?
-- Thanks, Joseph Smith Set-Top-Linux www.settoplinux.org
-- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
On 07.11.2008 07:00, Elia Yehuda wrote:
before anything else :-) right when i turn on the pc, those zeros (0x00) starts to show on the screen (i use gtkterm in hexmode since minicom wont show me those hexed zeros), fill the screen slowly for 2 minutes, and only then the following coreboot messages shows up and the boot starts :
coreboot-2.0.0.0Fallback Fri Nov 7 04:00:16 IST 2008 starting... Ram1.00 i810 Initial registers have been set. Ram2.00 ...
so, to sum it up - turn on computer zeors on the screen for 2 minutes coreboot starts
hope this clears matters up ;)
That's a known bug with quite a few boards. Nobody has tracked it down yet. You're probably the first person to notice these zeros.
Can you sprinkle POST codes liberally all over the map and note down when the zero sending starts? Since the delay is so long, observing POST codes on a POST card should work fine.
By the way, such a bug is much less likely to ever happen in v3.
Regards, Carl-Daniel
On Fri, Nov 7, 2008 at 9:46 AM, Carl-Daniel Hailfinger < c-d.hailfinger.devel.2006@gmx.net> wrote:
On 07.11.2008 07:00, Elia Yehuda wrote:
before anything else :-) right when i turn on the pc, those zeros (0x00) starts to show on the
screen
(i use gtkterm in hexmode since minicom wont show me those hexed zeros), fill the screen slowly for 2 minutes, and only then the following
coreboot
messages shows up and the boot starts :
coreboot-2.0.0.0Fallback Fri Nov 7 04:00:16 IST 2008 starting... Ram1.00 i810 Initial registers have been set. Ram2.00 ...
so, to sum it up - turn on computer zeors on the screen for 2 minutes coreboot starts
hope this clears matters up ;)
That's a known bug with quite a few boards. Nobody has tracked it down yet. You're probably the first person to notice these zeros.
Can you sprinkle POST codes liberally all over the map and note down when the zero sending starts? Since the delay is so long, observing POST codes on a POST card should work fine.
if you could just say it again in a way i can understand what you are talking about, it would be great :)
By the way, such a bug is much less likely to ever happen in v3.
Regards, Carl-Daniel
and since this thread had been hijacked already, i'd like to add my 2 cents on the "fixing bad vendor/device id" issue -
as a new coreboot user, i would expect coreboot (plus its payload) to perform at least as good as my current bios (although it exceeds it imo...). having coreboot to fail on bad vendor/device id, is a bad practice just like having those bad vendor/device id in the first place - if there is a known bug, instead of ignoring it and saying "oh yes, its THEIR bug, we're not going to fix it, but the user can run this xxx tool which might" is only making matters worse. the best thing is having a warning on coreboot signaling that it uses fallback vendor/device id due to (...) and still having a tool to fix those roms, which is always a good thing to have.
Regards, Elia Yehuda.
On 08.11.2008 02:09, Elia Yehuda wrote:
On Fri, Nov 7, 2008 at 9:46 AM, Carl-Daniel Hailfinger < c-d.hailfinger.devel.2006@gmx.net> wrote:
On 07.11.2008 07:00, Elia Yehuda wrote:
before anything else :-) right when i turn on the pc, those zeros (0x00) starts to show on the
screen
(i use gtkterm in hexmode since minicom wont show me those hexed zeros), fill the screen slowly for 2 minutes, and only then the following
coreboot
messages shows up and the boot starts :
coreboot-2.0.0.0Fallback Fri Nov 7 04:00:16 IST 2008 starting... Ram1.00 i810 Initial registers have been set. Ram2.00 ...
so, to sum it up - turn on computer zeors on the screen for 2 minutes coreboot starts
hope this clears matters up ;)
That's a known bug with quite a few boards. Nobody has tracked it down yet. You're probably the first person to notice these zeros.
Can you sprinkle POST codes liberally all over the map and note down when the zero sending starts? Since the delay is so long, observing POST codes on a POST card should work fine.
if you could just say it again in a way i can understand what you are talking about, it would be great :)
Try to find the code paths which are executed between powerup and the first boot message. Insert instructions like post_code(0x01); post_code(0x02); or outb(0x01, 0x80); outb(0x02, 0x80); and check with a POST card after which POST code the delays happen.
and since this thread had been hijacked already, i'd like to add my 2 cents on the "fixing bad vendor/device id" issue -
as a new coreboot user, i would expect coreboot (plus its payload) to perform at least as good as my current bios (although it exceeds it imo...). having coreboot to fail on bad vendor/device id, is a bad practice just like having those bad vendor/device id in the first place - if there is a known bug, instead of ignoring it and saying "oh yes, its THEIR bug, we're not going to fix it, but the user can run this xxx tool which might" is only making matters worse. the best thing is having a warning on coreboot signaling that it uses fallback vendor/device id due to (...) and still having a tool to fix those roms, which is always a good thing to have.
You see, the decision about which ROM to execute for a given PCI device is partially derived from that vendor and device ID. Separate cards with their own on-card ROM chips don't have that bug. (They would fail with a normal BIOS as well.) And PCI devices where the ROM lives inside the normal mainboard flash can be checked at coreboot build time once my tool is done. If anyone wants to ignore warnings/errors from that tool, it's his fault if stuff doesn't work.
Regards, Carl-Daniel
On Fri, 7 Nov 2008 05:46:09 +0200, "Elia Yehuda" z4ziggy@gmail.com wrote:
found the problem - its my buggy vga.rom!!! it's missing the damn device_id!
That's what I thought...
On Thu, Nov 6, 2008 at 7:27 PM, Elia Yehuda z4ziggy@gmail.com wrote:
thanks for the suggestion - ive added #define PCI_DEVICE_ID_INTEL_82810E_IG 0x7125
to src/include/device/pci_ids.h but still no luck :
rom address for PCI: 00:01.0 = fffc0000 PCI Expansion ROM, signature 0xaa55, INIT size 0xa000, data ptr 0x0110 PCI ROM Image, Vendor 8086, Device 0000, Device or Vendor ID mismatch Vendor 8086, Device 0000 (Expected Vendor 8086, Device 7125)
im guessing the device_id needs to be declated somewhere in the code or maybe in the Config.lb?
Defintely, that is the wrong answer :-)
All that is going on here is that the coreboot rom BIOS code is making sure that the device id in the ROM matches the hardware. This is to ensure that you don't run the wrong vga bios on the hardware. This is part of the PCI spec. This is a pure runtime check.
Adding that define will have no effect, as you have seen.
The real problem: the ROM is wrong. This is not uncommon. Doubtless the vendor created a broken rom (Even the QEMU VGA ROM is wrong) and doubtless the vendor bios doesn't bother checking (this sloppiness is not unsual in production BIOS code). Coreboot actually is more strict and it is showing that there is an error
PCI ROM Image, Vendor 8086, Device 0000,
(who ever has a device id of zero?)
It is quite amazing how sloppy "production" bios code is. That's what happens when you can hide behind closed source. Nobody gets hurt but the customer.
The fix? Modify the BIOS image and put the device ID in the image.
Can someone put this Device or Vendor ID mismatch Vendor 8086, Device 0000 (Expected Vendor 8086,
Device 7125)
on the FAQ with a note about what it means?
thanks
ron
On Fri, Nov 7, 2008 at 5:46 PM, ron minnich rminnich@gmail.com wrote:
It is quite amazing how sloppy "production" bios code is. That's what happens when you can hide behind closed source. Nobody gets hurt but the customer.
The fix? Modify the BIOS image and put the device ID in the image.
Why not Having a config option turning the "error and not running the rom" into "warning and run the rom anyways". Would that be risky ? CONFIG_RUN_SLOPPY_EXPANSION_ROMS
As this will bite more people, and I'm wondering if my own personal lack of working VGA would be related to that same kind of thing...
On Fri, Nov 7, 2008 at 9:06 AM, Vincent Legoll vincent.legoll@gmail.com wrote:
Why not Having a config option turning the "error and not running the rom" into "warning and run the rom anyways". Would that be risky ? CONFIG_RUN_SLOPPY_EXPANSION_ROMS
I think a linux tool to validate -- and fix -- the rom in some way makes the most sense.
In your case the fix is easy. It does not hurt, also, to get people to realize just how broken the proprietary bios code is. Hiding that brokenness seems a bad idea.
ron
On Fri, Nov 7, 2008 at 6:20 PM, ron minnich rminnich@gmail.com wrote:
On Fri, Nov 7, 2008 at 9:06 AM, Vincent Legoll vincent.legoll@gmail.com wrote:
Why not Having a config option turning the "error and not running the rom" into "warning and run the rom anyways". Would that be risky ? CONFIG_RUN_SLOPPY_EXPANSION_ROMS
I think a linux tool to validate -- and fix -- the rom in some way makes the most sense.
Yes that would be good to have indeed. What is to be validated ? Where would I find documentation about a BIOS specification to validate option ROMs against ?
In your case the fix is easy. It does not hurt, also, to get people to realize just how broken the proprietary bios code is. Hiding that brokenness seems a bad idea.
I'd see that more as coping with reality than hiding the brokenness, tho
On Fri, Nov 7, 2008 at 9:25 AM, Vincent Legoll vincent.legoll@gmail.com wrote:
What is to be validated ?
The tool can verify that the vendor/devid info in the room is even there (it is not in QEMU VGA BIOS) and then print the vendor/dev id, look it up, and print out what hardware that is.
Obvious errors such as devid of 0 could be flagged.
Where would I find documentation about a BIOS specification to validate option ROMs against ?
It's in the PCI spec. BUT: the PCI SIG STILL SUCKS: this stuff is not avalable to non-members even now. I just checked.
Any PCI spec will show it. But you have to get one.
Or you can cruise the pci rom bios code in coreboot -- it's pretty obvious what's going on there.
In your case the fix is easy. It does not hurt, also, to get people to realize just how broken the proprietary bios code is. Hiding that brokenness seems a bad idea.
I'd see that more as coping with reality than hiding the brokenness,
I can not agree. How do you know that the firmware you are running really matches the card? You don't. The vendor/devid is in the ROM for a reason.
Perpetuating bad practice is just a bad idea.
ron
On 07.11.2008 18:33, ron minnich wrote:
On Fri, Nov 7, 2008 at 9:25 AM, Vincent Legoll vincent.legoll@gmail.com wrote:
What is to be validated ?
The tool can verify that the vendor/devid info in the room is even there (it is not in QEMU VGA BIOS) and then print the vendor/dev id, look it up, and print out what hardware that is.
Obvious errors such as devid of 0 could be flagged.
Where would I find documentation about a BIOS specification to validate option ROMs against ?
It's in the PCI spec. BUT: the PCI SIG STILL SUCKS: this stuff is not avalable to non-members even now. I just checked.
Older drafts may be available on the internet for free.
Any PCI spec will show it. But you have to get one.
Or you can cruise the pci rom bios code in coreboot -- it's pretty obvious what's going on there.
What about the following doc? http://www.msc-ge.com/download/pc-system/ipc-produkte/pisa/VGA%20BIOS%20CT%2...
Regards, Carl-Daniel
Yes that would be good to have indeed. What is to be validated ? Where would I find documentation about a BIOS specification to validate option ROMs against ?
I use the PCI (Actually PCIe but same information) book from Mindshare.
Thanks, Myles
On 07.11.2008 18:20, ron minnich wrote:
On Fri, Nov 7, 2008 at 9:06 AM, Vincent Legoll vincent.legoll@gmail.com wrote:
Why not Having a config option turning the "error and not running the rom" into "warning and run the rom anyways". Would that be risky ? CONFIG_RUN_SLOPPY_EXPANSION_ROMS
I think a linux tool to validate -- and fix -- the rom in some way makes the most sense.
I'll write one if you'll review it.
In your case the fix is easy. It does not hurt, also, to get people to realize just how broken the proprietary bios code is. Hiding that brokenness seems a bad idea.
What's the preferred name for such a tool? - validate_option_rom - fix_option_rom - fix_broken_rom - vga_rom_tool - etc.
Regards, Carl-Daniel
Here was my thought.
checkrom -- check a rom. Apply all the tests to the rom that coreboot/seabios would apply before running it. User is required to provide (symbolic or numeric) vendor and deviceid for the device. If there is a problem, ask the user what to do, e.g. if we have: no valid vendor info are (a la QEMU VGA BIOS) no valid vendor id no valid device id The program can talk to the user about what is going wrong. Also, the tool can output commands to be used for:
fixrom -- fix a rom. takes switches such as --vendorid --deviceid --create-info-area and others as needed.
mailrom -- given a broken rom, send mail to the author(s) about what is wrong and how to fix it :-) options: --mailbomb mail the users every day until it is fixed. Might actually get QEMU VGA BIOS repaired :-)
Thanks
ron
Bottom line is a tool would be great. Any Intel VGA pre- i845 there is no way to build a new good working VGA Bios (vbios as Intel calls it) unless you are God and posses Intel's "Bios Modification Utility". Trust me I have tried many times and many ways to get it. So, you basically are stuck with the binary blob you extract from your old bios, which half the time only works to it's bare minimum. So, if we could come up with a tool to improve binary blobs, I say go for it :-)
IIRC, there's some bit in the i810 that changes the device ID, for whatever nefarious purpose. The datasheet is freely available on intel.com (search for "82810 datasheet"), I'd check for you but there's a storm here and my internet connection keeps cutting out.
-Corey
On Thu, Nov 6, 2008 at 10:06 PM, Joseph Smith joe@settoplinux.org wrote:
On Fri, 7 Nov 2008 04:55:41 +0200, "Elia Yehuda" z4ziggy@gmail.com wrote:
yep, ive extraced my vga using awardeco which should be fine (and it does seems fine on the lspci -n, which is very frustrating)
On Fri, Nov 7, 2008 at 4:48 AM, Joseph Smith joe@settoplinux.org
wrote:
On Fri, 7 Nov 2008 04:24:38 +0200, "Elia Yehuda" z4ziggy@gmail.com wrote:
tnx Joseph,
i've fixed the following (to match my 256kb bios) :
device pci_domain 0 on
device pci 0.0 on end # Host bridge chip drivers/pci/onboard device pci 1.0 on end # Onboard video register "rom_address" = "0xfffc0000" end... end
and now the rom_address is set AND i see the device in lspci : lspci: 00:01.0 VGA compatible controller: Intel Corporation 82810E DC-133
(CGC)
Chipset Graphics Controller (rev 03) lspci -n: 00:01.0 0300: 8086:7125 (rev 03)
but still no vga-output! i found the following to might suggest another problem :
PCI Expansion ROM, signature 0xaa55, INIT size 0xa000, data ptr 0x0110 PCI ROM Image, Vendor 8086, Device 0000, Device or Vendor ID mismatch Vendor 8086, Device 0000
and no "copying VGA ROM Image"...
Yep that is your problem. Is there something wrong with your vga bios.
It
is reading the vendor id ok but the device id should be 7125. Have you checked this out? It may help you to get a valid vga bios. http://www.coreboot.org/VGA_support
coreboot uses a different pci.ids file than Linux. That's why Linux can find it but coreboot can't? Check and see if the coreboot pci.ids file includes 8086 / 7125. It may be missing and just needs to be added?
-- Thanks, Joseph Smith Set-Top-Linux www.settoplinux.org
-- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
-
Carl-Daniel Hailfinger -
Corey Osgood -
Elia Yehuda -
Joseph Smith -
Myles Watson -
ron minnich -
Vincent Legoll