Hi, all, The new auto-generated acpi table doesn't seem to be correct on dbm690t. Dose anybody have any idea?
Joe
Please check the dmesg:
Booting 'Ubuntu 8.04, kernel 2.6.24-amd2-generic-serial'
root (hd0,0) kernel /boot/vmlinuz-2.6.24-amd2-generic root=UUID=7bb9e8a5-cbc0-4104-92a3-628 f56924494 ro console=ttyS0,115200 initrd /boot/initrd.img-2.6.24-amd2-generic
Booting 'hda1:/boot/vmlinuz-2.6.24-amd2-generic root=UUID=7bb9e8a5-cbc0-4104-92 a3-628f56924494 ro console=ttyS0,115200 initrd=/boot/initrd.img-2.6.24-amd2-gen eric' Mounted EXT2 filesystem Mounted EXT2 filesystem Found Linux version 2.6.24-amd2-generic (root@forsteri) #1 SMP Tue Jul 15 22:02:29 UTC 2008 bzI mage. Loading kernel... ok Loading initrd... ok Jumping to entry point... [ 0.000000] Linux version 2.6.24-amd2-generic (root@forsteri) (gcc version 4.2.3 (Ubuntu 4.2 .3-2ubuntu7)) #1 SMP Tue Jul 15 22:02:29 UTC 2008 (Ubuntu 2.6.24-amd2.2-generic) [ 0.000000] Command line: root=UUID=7bb9e8a5-cbc0-4104-92a3-628f56924494 ro console=ttyS0,11 5200 [ 0.000000] BIOS-provided physical RAM map: [ 0.000000] BIOS-e820: 0000000000000000 - 00000000000a0000 (usable) [ 0.000000] BIOS-e820: 0000000000100000 - 0000000004000000 (usable) [ 0.000000] end_pfn_map = 16384 [ 0.000000] DMI not present or invalid. [ 0.000000] ACPI: RSDP signature @ 0xFFFF8100000F0400 checksum 0 [ 0.000000] ACPI: RSDP 000F0400, 0024 (r2 CORE ) [ 0.000000] Scanning NUMA topology in Northbridge 24 [ 0.000000] CPU has 2 num_cores [ 0.000000] No NUMA configuration found [ 0.000000] Faking a node at 0000000000000000-0000000004000000 [ 0.000000] Bootmem setup node 0 0000000000000000-0000000004000000 [ 0.000000] Zone PFN ranges: [ 0.000000] DMA 0 -> 4096 [ 0.000000] DMA32 4096 -> 1048576 [ 0.000000] Normal 1048576 -> 1048576 [ 0.000000] Movable zone start PFN for each node [ 0.000000] early_node_map[2] active PFN ranges [ 0.000000] 0: 0 -> 160 [ 0.000000] 0: 256 -> 16384 [ 0.000000] ATI board detected. Disabling timer routing over 8254. [ 0.000000] Intel MultiProcessor Specification v1.4 [ 0.000000] MPTABLE: OEM ID: ATI MPTABLE: Product ID: DBM690T MPTABLE: APIC at: 0x FEE00000 [ 0.000000] Processor #0 (Bootup-CPU) [ 0.000000] Processor #1 [ 0.000000] I/O APIC #2 at 0xFEC00000. [ 0.000000] Setting APIC routing to flat [ 0.000000] Processors: 2 [ 0.000000] swsusp: Registered nosave memory region: 00000000000a0000 - 0000000000100000 [ 0.000000] Allocating PCI resources starting at 10000000 (gap: 4000000:fc000000) [ 0.000000] SMP: Allowing 2 CPUs, 0 hotplug CPUs [ 0.000000] PERCPU: Allocating 34656 bytes of per cpu data [ 0.000000] Built 1 zonelists in Node order, mobility grouping on. Total pages: 14857 [ 0.000000] Policy zone: DMA32 [ 0.000000] Kernel command line: root=UUID=7bb9e8a5-cbc0-4104-92a3-628f56924494 ro console=t tyS0,115200 [ 0.000000] Initializing CPU#0 [ 0.000000] PID hash table entries: 256 (order: 8, 2048 bytes) [ 0.000000] TSC calibrated against PIT [ 0.000000] Marking TSC unstable due to TSCs unsynchronized [ 0.000000] time.c: Detected 2100.115 MHz processor. [ 0.000000] Console: colour VGA+ 80x25 [ 0.000000] console [ttyS0] enabled [ 0.000000] Checking aperture... [ 0.000000] CPU 0: aperture @ f8000000 size 64 MB [ 0.000000] Memory: 51848k/65536k available (2466k kernel code, 13304k reserved, 1313k data, 316k init) [ 0.000000] SLUB: Genslabs=12, HWalign=64, Order=0-1, MinObjects=4, CPUs=2, Nodes=1 [ 0.000000] Calibrating delay using timer specific routine.. 4203.67 BogoMIPS (lpj=8407353) [ 0.000000] Security Framework initialized [ 0.000000] SELinux: Disabled at boot. [ 0.000000] AppArmor: AppArmor initialized [ 0.000000] Failure registering capabilities with primary security module. [ 0.000000] Dentry cache hash table entries: 8192 (order: 4, 65536 bytes) [ 0.000000] Inode-cache hash table entries: 4096 (order: 3, 32768 bytes) [ 0.000000] Mount-cache hash table entries: 256 [ 0.000000] CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line) [ 0.000000] CPU: L2 Cache: 512K (64 bytes/line) [ 0.000000] CPU 0/0 -> Node 0 [ 0.000000] CPU: Physical Processor ID: 0 [ 0.000000] CPU: Processor Core ID: 0 [ 0.000000] SMP alternatives: switching to UP code [ 0.000000] Early unpacking initramfs... done [ 0.000000] ACPI: Core revision 20070126 [ 0.000000] ACPI Exception (tbxface-0629): AE_NO_ACPI_TABLES, While loading namespace from A CPI tables [20070126] [ 0.000000] ACPI: Unable to load the System Description Tables [ 0.000000] ExtINT not setup in hardware but reported by MP table [ 0.000000] Using local APIC timer interrupts. [ 0.000000] Detected 12.500 MHz APIC timer. [ 0.000000] SMP alternatives: switching to SMP code [ 0.000000] Booting processor 1/2 APIC 0x1 [ 0.000000] Initializing CPU#1 [ 0.000000] Calibrating delay using timer specific routine.. 4200.24 BogoMIPS (lpj=8400480) [ 0.000000] CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line) [ 0.000000] CPU: L2 Cache: 512K (64 bytes/line) [ 0.000000] CPU 1/1 -> Node 0 [ 0.000000] CPU: Physical Processor ID: 0 [ 0.000000] CPU: Processor Core ID: 1 [ 0.000000] AMD Turion(tm) 64 X2 Mobile Technology TL-62 stepping 02 [ 0.000000] Brought up 2 CPUs [ 0.000000] net_namespace: 120 bytes [ 0.000000] Time: 4:46:48 Date: 04/13/09 [ 0.000000] NET: Registered protocol family 16 [ 0.000000] PCI: Using configuration type 1 [ 0.000000] ACPI: Interpreter disabled. [ 0.000000] Linux Plug and Play Support v0.97 (c) Adam Belay [ 0.000000] pnp: PnP ACPI: disabled [ 0.000000] PCI: Probing PCI hardware [ 0.000000] pci 0000:00:12.0: set SATA to AHCI mode [ 0.000000] PCI: Transparent bridge - 0000:00:14.4 [ 0.000000] PCI: Using IRQ router default [1002/4384] at 0000:00:14.4 [ 0.000000] PCI: Cannot allocate resource region 0 of device 0000:05:00.0 [ 0.000000] NET: Registered protocol family 8 [ 0.000000] NET: Registered protocol family 20 [ 0.000000] AppArmor: AppArmor Filesystem Enabled [ 0.000000] PCI: Bridge: 0000:00:01.0 [ 0.000000] IO window: 1000-1fff [ 0.000000] MEM window: fc000000-fc1fffff [ 0.000000] PREFETCH window: f0000000-f7ffffff [ 0.000000] PCI: Bridge: 0000:00:04.0 [ 0.000000] IO window: disabled. [ 0.000000] MEM window: disabled. [ 0.000000] PREFETCH window: disabled. [ 0.000000] PCI: Bridge: 0000:00:05.0 [ 0.000000] IO window: disabled. [ 0.000000] MEM window: disabled. [ 0.000000] PREFETCH window: disabled. [ 0.000000] PCI: Bridge: 0000:00:06.0 [ 0.000000] IO window: disabled. [ 0.000000] MEM window: disabled. [ 0.000000] PREFETCH window: disabled. [ 0.000000] PCI: Bridge: 0000:00:07.0 [ 0.000000] IO window: disabled. [ 0.000000] MEM window: 10000000-100fffff [ 0.000000] PREFETCH window: disabled. [ 0.000000] PCI: Bridge: 0000:00:14.4 [ 0.000000] IO window: disabled. [ 0.000000] MEM window: disabled. [ 0.000000] PREFETCH window: disabled. [ 0.000000] PCI: Enabling device 0000:00:07.0 (0000 -> 0002) [ 0.000000] NET: Registered protocol family 2 [ 0.000000] IP route cache hash table entries: 512 (order: 0, 4096 bytes) [ 0.000000] TCP established hash table entries: 2048 (order: 3, 32768 bytes) [ 0.000000] TCP bind hash table entries: 2048 (order: 3, 32768 bytes) [ 0.000000] TCP: Hash tables configured (established 2048 bind 2048) [ 0.000000] TCP reno registered [ 0.000000] checking if image is initramfs... it is [ 0.000000] Freeing initrd memory: 7452k freed [ 0.000000] audit: initializing netlink socket (disabled) [ 0.000000] audit(1239598008.456:1): initialized [ 0.000000] VFS: Disk quotas dquot_6.5.1 [ 0.000000] Dquot-cache hash table entries: 512 (order 0, 4096 bytes) [ 0.000000] io scheduler noop registered [ 0.000000] io scheduler anticipatory registered [ 0.000000] io scheduler deadline registered [ 0.000000] io scheduler cfq registered (default) [ 0.000000] assign_interrupt_mode Found MSI capability [ 0.000000] assign_interrupt_mode Found MSI capability [ 0.000000] assign_interrupt_mode Found MSI capability [ 0.000000] assign_interrupt_mode Found MSI capability [ 0.000000] Real Time Clock Driver v1.12ac [ 0.000000] Linux agpgart interface v0.102 [ 0.000000] Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing enabled [ 0.000000] serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A [ 0.000000] RAMDISK driver initialized: 16 RAM disks of 65536K size 1024 blocksize [ 0.000000] input: Macintosh mouse button emulation as /devices/virtual/input/input0 [ 0.000000] PNP: No PS/2 controller found. Probing ports directly. [ 0.000000] serio: i8042 KBD port at 0x60,0x64 irq 1 [ 0.000000] serio: i8042 AUX port at 0x60,0x64 irq 12 [ 0.000000] mice: PS/2 mouse device common for all mice [ 0.000000] cpuidle: using governor ladder [ 0.000000] cpuidle: using governor menu [ 0.000000] NET: Registered protocol family 1 [ 0.000000] registered taskstats version 1 [ 0.000000] Magic number: 5:620:767 [ 0.000000] hash matches device ptyp3 [ 0.000000] /root/build/ubuntu/linux-source/linux-source/drivers/rtc/hctosys.c: unable to op en rtc device (rtc0) [ 0.000000] BIOS EDD facility v0.16 2004-Jun-25, 0 devices found [ 0.000000] EDD information not available. [ 0.000000] Freeing unused kernel memory: 316k freed Loading, please wait... Begin: Loading essential drivers... ... [ 0.000000] thermal: Unknown symbol acpi_processor_set_thermal_limit Done. Begin: Running /scripts/init-premount ... Done. Begin: Mounting root file system... ... Begin: Running /scripts/local-top ... Done. [ 0.000000] tg3.c:v3.86 (November 9, 2007) Begin: Waiting f[ 0.000000] PCI: Enabling device 0000:05:00.0 (0000 -> 0002) or root file sys[ 0.000000] PCI: No IRQ known for interrupt pin A of device 0000:05:00.0. Pr obably buggy MP table. tem... ... [ 0.000000] SCSI subsystem initialized [ 0.000000] tg3: eth%d: Cannot get nvarm lock, tg3_nvram_init failed. [ 0.000000] tg3: (0000:05:00.0) phy probe failed, err -19 [ 0.000000] tg3: Problem fetching invariants of chip, aborting. [ 0.000000] usbcore: registered new interface driver usbfs [ 0.000000] usbcore: registered new interface driver hub [ 0.000000] usbcore: registered new device driver usb [ 0.000000] scsi0 : pata_atiixp [ 0.000000] scsi1 : pata_atiixp [ 0.000000] ata1: PATA max UDMA/100 cmd 0x1f0 ctl 0x3f6 bmdma 0x2010 irq 14 [ 0.000000] ata2: PATA max UDMA/100 cmd 0x170 ctl 0x376 bmdma 0x2018 irq 15 [ 0.000000] PCI: No IRQ known for interrupt pin A of device 0000:00:12.0. Probably buggy MP table. [ 0.000000] ahci 0000:00:12.0: controller can't do 64bit DMA, forcing 32bit [ 0.000000] ahci 0000:00:12.0: controller can't do PMP, turning off CAP_PMP [ 0.000000] ahci 0000:00:12.0: AHCI 0001.0100 32 slots 4 ports 3 Gbps 0xf impl SATA mode [ 0.000000] ahci 0000:00:12.0: flags: ncq sntf ilck pm led clo pio slum part [ 0.000000] WARNING: at /root/build/ubuntu/linux-source/linux-source/drivers/ata/libata-core .c:7238 ata_host_activate() [ 0.000000] Pid: 1291, comm: modprobe Not tainted 2.6.24-amd2-generic #1 [ 0.000000] [ 0.000000] Call Trace: [ 0.000000] [<ffffffff8807135e>] :libata:ata_host_activate+0x13e/0x140 [ 0.000000] [<ffffffff880cabc8>] :ahci:ahci_init_one+0x988/0xb80 [ 0.000000] [<ffffffff803588b8>] pci_device_probe+0xf8/0x170 [ 0.000000] [<ffffffff803b9fcc>] driver_probe_device+0x9c/0x1b0 [ 0.000000] [<ffffffff803ba299>] __driver_attach+0xc9/0xd0 [ 0.000000] [<ffffffff803ba1d0>] __driver_attach+0x0/0xd0 [ 0.000000] [<ffffffff803b920d>] bus_for_each_dev+0x4d/0x80 [ 0.000000] [<ffffffff803b961c>] bus_add_driver+0xac/0x220 [ 0.000000] [<ffffffff80358b39>] __pci_register_driver+0x69/0xb0 [ 0.000000] [<ffffffff80263b6e>] sys_init_module+0x18e/0x1a90 [ 0.000000] [<ffffffff8020c37e>] system_call+0x7e/0x83 [ 0.000000] [ 0.000000] scsi2 : ahci [ 0.000000] scsi3 : ahci [ 0.000000] scsi4 : ahci [ 0.000000] scsi5 : ahci [ 0.000000] ata3: SATA max UDMA/133 abar m1024@0xfc209000 port 0xfc209100 [ 0.000000] ata4: SATA max UDMA/133 abar m1024@0xfc209000 port 0xfc209180 [ 0.000000] ata5: SATA max UDMA/133 abar m1024@0xfc209000 port 0xfc209200 [ 0.000000] ata6: SATA max UDMA/133 abar m1024@0xfc209000 port 0xfc209280 [ 0.000000] ata3: SATA link up 1.5 Gbps (SStatus 113 SControl 300) [ 0.000000] ata3.00: qc timeout (cmd 0xec) [ 0.000000] ata3.00: failed to IDENTIFY (I/O error, err_mask=0x4) [ 0.000000] ata3: failed to recover some devices, retrying in 5 secs [ 0.000000] ata3: SATA link up 1.5 Gbps (SStatus 113 SControl 300) [ 0.000000] ata3.00: qc timeout (cmd 0xec) [ 0.000000] ata3.00: failed to IDENTIFY (I/O error, err_mask=0x4) [ 0.000000] ata3: failed to recover some devices, retrying in 5 secs [ 0.000000] ata3: SATA link up 1.5 Gbps (SStatus 113 SControl 300) [ 0.000000] ata3.00: qc timeout (cmd 0xec) [ 0.000000] ata3.00: failed to IDENTIFY (I/O error, err_mask=0x4) [ 0.000000] ata3: failed to recover some devices, retrying in 5 secs [ 0.000000] ata3: SATA link up 1.5 Gbps (SStatus 113 SControl 300) [ 0.000000] ata4: SATA link down (SStatus 0 SControl 300) [ 0.000000] ata5: SATA link down (SStatus 0 SControl 300) [ 0.000000] ata6: SATA link down (SStatus 0 SControl 300) [ 0.000000] PCI: No IRQ known for interrupt pin A of device 0000:00:13.0. Probably buggy MP table. [ 0.000000] ohci_hcd 0000:00:13.0: Found HC with no IRQ. Check BIOS/PCI 0000:00:13.0 setup! [ 0.000000] ohci_hcd 0000:00:13.0: init 0000:00:13.0 fail, -19 [ 0.000000] PCI: No IRQ known for interrupt pin B of device 0000:00:13.1. Probably buggy MP table. [ 0.000000] ohci_hcd 0000:00:13.1: Found HC with no IRQ. Check BIOS/PCI 0000:00:13.1 setup! [ 0.000000] ohci_hcd 0000:00:13.1: init 0000:00:13.1 fail, -19 [ 0.000000] PCI: No IRQ known for interrupt pin C of device 0000:00:13.2. Probably buggy MP table. [ 0.000000] ohci_hcd 0000:00:13.2: Found HC with no IRQ. Check BIOS/PCI 0000:00:13.2 setup! [ 0.000000] ohci_hcd 0000:00:13.2: init 0000:00:13.2 fail, -19 [ 0.000000] PCI: No IRQ known for interrupt pin B of device 0000:00:13.3. Probably buggy MP table. [ 0.000000] ohci_hcd 0000:00:13.3: Found HC with no IRQ. Check BIOS/PCI 0000:00:13.3 setup! [ 0.000000] ohci_hcd 0000:00:13.3: init 0000:00:13.3 fail, -19 [ 0.000000] PCI: No IRQ known for interrupt pin C of device 0000:00:13.4. Probably buggy MP table. [ 0.000000] ohci_hcd 0000:00:13.4: Found HC with no IRQ. Check BIOS/PCI 0000:00:13.4 setup! [ 0.000000] ohci_hcd 0000:00:13.4: init 0000:00:13.4 fail, -19 [ 0.000000] PCI: No IRQ known for interrupt pin D of device 0000:00:13.5. Probably buggy MP table. [ 0.000000] ehci_hcd 0000:00:13.5: Found HC with no IRQ. Check BIOS/PCI 0000:00:13.5 setup! [ 0.000000] ehci_hcd 0000:00:13.5: init 0000:00:13.5 fail, -19 [ 0.000000] Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2 [ 0.000000] ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx Done. Check root= bootarg cat /proc/cmdline or missing modules, devices: cat /proc/modules ls /dev ALERT! /dev/disk/by-uuid/7bb9e8a5-cbc0-4104-92a3-628f56924494 does not exist. Dropping to a she ll!
Hi Zheng,
On 12.05.2009 10:38, Bao, Zheng wrote:
The new auto-generated acpi table doesn't seem to be correct on dbm690t.
Thanks for testing this. That problem is very unfortunate.
Dose anybody have any idea?
Is there a way to dump an ACPI table from coreboot in hex after it is generated? That would be very useful. We could examine that dump and compare it to the old static ACPI table.
Regards, Carl-Daniel
Hi,
It seemes like no table is found. Maybe it is problem of Seabios/Hightables?
Does seabios find the acpi tables?
Rudolf
It seems that you are right. This error comes up when we add HAVE_HIGH_TABLES in k8/Config.lb
The payload I use is filo which is somehow old. Do I have to use the SeaBios?
Zheng
-----Original Message----- From: Rudolf Marek [mailto:r.marek@assembler.cz] Sent: Tuesday, May 12, 2009 5:13 PM To: Bao, Zheng Cc: coreboot@coreboot.org Subject: Re: [coreboot] [dbm690t] The new acpi table doesn't seem to be correct.
Hi,
It seemes like no table is found. Maybe it is problem of Seabios/Hightables?
Does seabios find the acpi tables?
Rudolf
Bao, Zheng wrote:
It seems that you are right. This error comes up when we add HAVE_HIGH_TABLES in k8/Config.lb
The payload I use is filo which is somehow old. Do I have to use the SeaBios?
Not have to. It should work like this too. Maybe you can try with some debug level - Seabios will maybe complain about acpi too. (it relocates just the RSDP, but in your case you have some there) Maybe it is wrong...
To me it seems that the RSDP which is orginal from Coreboot, points to some bogus place. Maybe using SeaBIOS will fix that, because SeaBIOS rewrites the RSDP pointer.
Check/compare the table addresses in the serial debug messages and from Linux/Seabios.
Rudolf
Zheng
-----Original Message----- From: Rudolf Marek [mailto:r.marek@assembler.cz] Sent: Tuesday, May 12, 2009 5:13 PM To: Bao, Zheng Cc: coreboot@coreboot.org Subject: Re: [coreboot] [dbm690t] The new acpi table doesn't seem to be correct.
Hi,
It seemes like no table is found. Maybe it is problem of Seabios/Hightables?
Does seabios find the acpi tables?
Rudolf
I found the HIGH_TABLES bug on the DBM690T.
The K8 HIGH_TABLES code places these tables in UMA video memory. Of course that memory is cleared by some payloads and operating systems.
However, if I fix that, Linux still crashes during boot because it only sees 32 MB instead of 2 MB RAM.
If I disable high tables completely, Linux complains about corrupt ACPI tables and other stuff.
Has the tables code been tested recently if it works even in the case where we don't want high tables?
Regards, Carl-Daniel
Based on my test, if I set HIVE_HIGH_TABLES=1 in northbridge/amd/amdk8/Config.lb, Linux will not crash and ACPI works well.
Note. I use the old version filo without libpayload.
Zheng
-----Original Message----- From: Carl-Daniel Hailfinger [mailto:c-d.hailfinger.devel.2006@gmx.net] Sent: Thursday, June 04, 2009 10:42 AM To: Bao, Zheng Cc: coreboot@coreboot.org Subject: Re: [coreboot] [dbm690t] The new acpi table doesn't seem to be correct.
I found the HIGH_TABLES bug on the DBM690T.
The K8 HIGH_TABLES code places these tables in UMA video memory. Of course that memory is cleared by some payloads and operating systems.
However, if I fix that, Linux still crashes during boot because it only sees 32 MB instead of 2 MB RAM.
If I disable high tables completely, Linux complains about corrupt ACPI tables and other stuff.
Has the tables code been tested recently if it works even in the case where we don't want high tables?
Regards, Carl-Daniel
Am 04.06.2009 04:41, schrieb Carl-Daniel Hailfinger:
I found the HIGH_TABLES bug on the DBM690T.
The K8 HIGH_TABLES code places these tables in UMA video memory. Of course that memory is cleared by some payloads and operating systems.
However, if I fix that, Linux still crashes during boot because it only sees 32 MB instead of 2 MB RAM.
Unless you're using SeaBIOS, you have to use both HAVE_HIGH_TABLES and HAVE_LOW_TABLES to have things work, otherwise the high tables aren't found. 32 MB is a good sign that the tables weren't found, so FILO (I think) defaults to "safe" 32MB.
On 04.06.2009 08:59, Patrick Georgi wrote:
Am 04.06.2009 04:41, schrieb Carl-Daniel Hailfinger:
I found the HIGH_TABLES bug on the DBM690T.
The K8 HIGH_TABLES code places these tables in UMA video memory. Of course that memory is cleared by some payloads and operating systems.
However, if I fix that, Linux still crashes during boot because it only sees 32 MB instead of 2 MB RAM.
Unless you're using SeaBIOS, you have to use both HAVE_HIGH_TABLES and HAVE_LOW_TABLES to have things work, otherwise the high tables aren't found. 32 MB is a good sign that the tables weren't found, so FILO (I think) defaults to "safe" 32MB.
I'm running an old version of FILO. Could you please take a look at the amd/dbm690t target and tell me what I have to enable there (HAVE_LOW_TABLES etc.) to have things work? I can probably get access to the hardware later today.
Thanks!
Regards, Carl-Daniel
On Thu, 04 Jun 2009 11:58:42 +0200, Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net wrote:
On 04.06.2009 08:59, Patrick Georgi wrote:
Am 04.06.2009 04:41, schrieb Carl-Daniel Hailfinger:
I found the HIGH_TABLES bug on the DBM690T.
The K8 HIGH_TABLES code places these tables in UMA video memory. Of course that memory is cleared by some payloads and operating systems.
However, if I fix that, Linux still crashes during boot because it only sees 32 MB instead of 2 MB RAM.
Unless you're using SeaBIOS, you have to use both HAVE_HIGH_TABLES and HAVE_LOW_TABLES to have things work, otherwise the high tables aren't found. 32 MB is a good sign that the tables weren't found, so FILO (I think) defaults to "safe" 32MB.
I'm running an old version of FILO. Could you please take a look at the amd/dbm690t target and tell me what I have to enable there (HAVE_LOW_TABLES etc.) to have things work? I can probably get access to the hardware later today.
I have seen the 32mb problem before, if you update FILO it fixes the problem.
Am 04.06.2009 11:58, schrieb Carl-Daniel Hailfinger:
I'm running an old version of FILO. Could you please take a look at the amd/dbm690t target and tell me what I have to enable there (HAVE_LOW_TABLES etc.) to have things work? I can probably get access to the hardware later today.
It might be that your old FILO has no idea of the (relatively new) forwarding pointer field in the cbtable, so it doesn't find all the data.
Patrick
On 04.06.2009 14:37, Patrick Georgi wrote:
Am 04.06.2009 11:58, schrieb Carl-Daniel Hailfinger:
I'm running an old version of FILO. Could you please take a look at the amd/dbm690t target and tell me what I have to enable there (HAVE_LOW_TABLES etc.) to have things work? I can probably get access to the hardware later today.
It might be that your old FILO has no idea of the (relatively new) forwarding pointer field in the cbtable, so it doesn't find all the data.
Thanks, I'll retry with a new FILO once I have access to the hardware again.
Regards, Carl-Daniel
Am 12.05.2009 10:38, schrieb Bao, Zheng:
Hi, all, The new auto-generated acpi table doesn't seem to be correct on dbm690t. Dose anybody have any idea?
[ 0.000000] ACPI: RSDP signature @ 0xFFFF8100000F0400 checksum 0 [ 0.000000] ACPI: RSDP 000F0400, 0024 (r2 CORE )
With both HAVE_HIGH_TABLES and HAVE_LOW_TABLES, the code writes the ACPI tables to high memory (64kb somewhere in top memory), and merely writes the RSDP to low memory. With only HAVE_HIGH_TABLES, the low memory RSDP is not written. With only HAVE_LOW_TABLES, the entire ACPI block is written to low memory.
At least that's the plan.
A coreboot log with high log level (debug or spew, so 8 or 9) should give some hints what coreboot does.
Regards, Patrick
Please check the coreboot log. Based on the dmesg, The kernel can find the RSD PTR in 0xf0400. But who knows what happens next?
Zheng
----------------- Devices initialized High Tables Base is 3fff0000. Writing IRQ routing tables to 0xf0000...write_pirq_routing_table done. Writing IRQ routing tables to 0x3fff0000...write_pirq_routing_table done. ACPI: Writing ACPI tables at 3fff0400... ACPI: * HPET ACPI: added table 1/9 Length now 40 ACPI: * MADT ACPI: added table 2/9 Length now 44 ACPI: * SSDT processor_brand=AMD Athlon(tm) 64 X2 Dual Core Processor 3400+ Pstates Algorithm ... Pstate_freq[0] = 1800MHz Pstate_vid[0] = 18 Pstate_volt[0] = 1100mv Pstate_power[0] = 35000mw Pstate_freq[1] = 1000MHz Pstate_vid[1] = 22 Pstate_volt[1] = 1000mv Pstate_power[1] = 16069mw ACPI: added table 3/9 Length now 48 ACPI: * FACS ACPI: * DSDT ACPI: * DSDT @ 3fff07ee Length 27c8 ACPI: * FADT pm_base: 0x0800 ACPI: added table 4/9 Length now 52 ACPI: done. rom_table_end=f0400, rsdt_location=3fff0424 rom_table_end=f0430, rsdt_location=3fff0424 Wrote the mp table end at: 00000020 - 00000134 Wrote the mp table end at: 3fff3410 - 3fff3524 Moving GDT to 0x3fff3800...ok Multiboot Information structure has been written. Writing high table forward entry at 0x00000500 Wrote coreboot table at: 00000500 - 00000518 checksum 83df New low_table_end: 0x00000500 Now going to write high coreboot table at 0x3fff3c00 rom_table_end = 0x3fff3c00 Adjust low_table_end from 0x00000500 to 0x00001000 Adjust rom_table_end from 0x3fff3c00 to 0x40000000 Adding high table area uma_memory_start=0x38000000, uma_memory_size=0x0 Wrote coreboot table at: 3fff3c00 - 3fff3df4 checksum 1bc3
elfboot: Attempting to load payload. rom_stream: 0xfffc0000 - 0xfffdffff Found ELF candidate at offset 0 header_offset is 0
-----------------------
-----Original Message----- From: Patrick Georgi [mailto:patrick@georgi-clan.de] Sent: Tuesday, May 12, 2009 7:23 PM To: Bao, Zheng Cc: coreboot@coreboot.org Subject: Re: [coreboot] [dbm690t] The new acpi table doesn't seem to be correct.
Am 12.05.2009 10:38, schrieb Bao, Zheng:
Hi, all, The new auto-generated acpi table doesn't seem to be correct on
dbm690t.
Dose anybody have any idea?
[ 0.000000] ACPI: RSDP signature @ 0xFFFF8100000F0400 checksum 0 [ 0.000000] ACPI: RSDP 000F0400, 0024 (r2 CORE )
With both HAVE_HIGH_TABLES and HAVE_LOW_TABLES, the code writes the ACPI
tables to high memory (64kb somewhere in top memory), and merely writes the RSDP to low memory. With only HAVE_HIGH_TABLES, the low memory RSDP is not written. With only HAVE_LOW_TABLES, the entire ACPI block is written to low memory.
At least that's the plan.
A coreboot log with high log level (debug or spew, so 8 or 9) should give some hints what coreboot does.
Regards, Patrick
-
Bao, Zheng -
Carl-Daniel Hailfinger -
Joseph Smith -
Patrick Georgi -
Rudolf Marek