Re: [coreboot] r5511 broke my compile
On 4/30/10 6:25 AM, Keith Hui wrote: $ make GENbuild.h ROMCC romstage.inc GENcrt0.S CC mainboard/asus/p2b-ls/crt0.s CC mainboard/asus/p2b-ls/crt0.initobj.o LINK coreboot OBJCOPYcoreboot.bootblock make: *** No rule to make target `src/arch/i386/include/arch/asm.h', needed by `build/arch/i386/lib/c_start.o'. Stop. The define ASSEMBLY is now passed by the Makefile for assembler files. Hence the asm.h construct is no longer needed. Just drop asm.h includes from your code. If you use the post_code() macro, you can now #include cpu/x86/post_code.h instead. -- 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
[coreboot] Linux booting hangs when booted by FILO
Hi all, I have loaded coreboot with FILO on a Kontron 986LCD-M board and when I am trying to boot Linux from FILO, it freezes at the Jumping to entry point... bit. Found Linux version 2.6.31.6 (l...@ubuntu) #50 Wed Feb 3 15:04:41 GMT 2010 bzIm age. Loading kernel... ok Loading initrd... ok Jumping to entry point... Does anyone have any idea on how to resolve that? Thank you in advance. P.S. please CC me. Regards, limp -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Linux booting hangs when booted by FILO
On Fri, 30 Apr 2010 03:34:43 +0100, limp johnky...@hotmail.com wrote: Hi all, I have loaded coreboot with FILO on a Kontron 986LCD-M board and when I am trying to boot Linux from FILO, it freezes at the Jumping to entry point... bit. Found Linux version 2.6.31.6 (l...@ubuntu) #50 Wed Feb 3 15:04:41 GMT 2010 bzIm age. Loading kernel... ok Loading initrd... ok Jumping to entry point... Does anyone have any idea on how to resolve that? Thank you in advance. P.S. please CC me. Hello, I helped John(limp) get his USB flash drive formatted to ext3 and all setup for FILO on irc yesterday. FILO sees the drive ok but no matter what he put in for kernel command line or initrd command line it still hangs on Jumping to entry point... I asked him to send an email to the list because I was stumped at that point. Is there a way in FILO to debug this better? Oh, FYI this is UHCI. -- Thanks, Joseph Smith Set-Top-Linux www.settoplinux.org -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Patch: Update Geode LX code to avoid FILO/Kernel problems
Hi Edwin, I know it's a while back but it looks like this patch is not really doing what it says because c - f were ram_resource'd before, too. Just with a separate call. Did this not work? I think we do this in many places. Stefan On 1/27/10 6:17 PM, Edwin Beasant wrote: This patch adds e- and f-segment as an available RAM area on the AMD lx-northbridge platforms and fixes FILO compatibility - Allows SeaBios to become resident correctly - Prevents Linux kernel resource problems when booted with FILO and VGA MSR's written - Allows use of the Geode VGA patches Signed-off-by: Edwin Beasant edwin_beas...@virtensys.com Index: src/northbridge/amd/lx/northbridge.c === --- src/northbridge/amd/lx/northbridge.c(revision 5057) +++ src/northbridge/amd/lx/northbridge.c(working copy) @@ -414,8 +414,8 @@ /* Report the memory regions */ idx = 10; ram_resource(dev, idx++, 0, 640); - ram_resource(dev, idx++, 768, 1024); // c-f are usable - ram_resource(dev, idx++, 1024, tomk - 1024);// Systop - 1 MB - KB + //ram_resource(dev, idx++, 768, 1024); // c-f are usable + ram_resource(dev, idx++, 768, tomk - 768); // Systop - 1 MB - KB #if CONFIG_WRITE_HIGH_TABLES==1 /* Leave some space for ACPI, PIRQ and MP tables */ -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] suport for AMD 770 (RX781) ? SATA III ?
Hello. I know I said I'd pick one of the GSoC motherboards, but after that coreboot got DDR3 support, and since I want to have a computer for a long time, and it may help compiling quicker, and so... I'd like to go for AM3 for the DDR3 support (I'm thinking Phenom II X4 910e or 905e) . I've seen this motherboard but I'm not sure the chipset is supported in coreboot. M4A77TD PRO/U3S6 http://www.asus.com/product.aspx?P_ID=bjOkrdsFHkTzz4Q6 (it has a serial port and, from the picture, socketed BIOS ROM) It lists AMD 770/SB710 I think AMD 770 is an alias for RX781, and I think this is an RS780 without IGP . Is it included in the RS780 support contributed by AMD ? It's not listed in http://www.coreboot.org/Supported_Chipsets_and_Devices Maybe because it's not yet tested ? I imagine it is implemented (maybe not tested on bare metal) because I saw this message: Vadim Girlin , on Fri Apr 9 07:12:05 CEST 2010, wrote: I'm going to try coreboot on Gigabyte GA-MA770-UD3. It's AMD 770 (RX780 / SB700). I've prepared the image for it based on code for mahogany fam10 with some modifications. I've tried it with simnow using the configuration close to mine as much as possible - it even boots with my native BIOS. And it boots with coreboot image. But I'd like confirmation of the status before buying the board just in case I'm doing something really silly. Another question is about the U3S6 sold with this card. It's a PCIe 2.0 (x1 ?) card with 2 USB3 ports and 2 SATA III (6Gb ) ports. I think it has a Marvell 88SE9123 SATA III controller. I don't find it in the supported chipset list. Yet it appears to have some linux driver (I still haven't foudn if there is some blob issue, Mavell calls it open source linux driver). Does it mean coreboot (payloads?) can't boot an OS from a disk connected to it,so I should have a disk connected to the 3Gb SATA in the motherboard ? I can buy the same card without the SATA III (6Gb) add on card, and I could at any time buy another add on card, so I'll probably do that if I can't use SATA III with coreboot anyway. I'll buy two 4Gb 1333MHz DDR3 SODIMMs if I can find them, and leave two more sockets for the future ,and a second hand Nvidia PCIe x16 fanless card for graphics. Sorry not to be able to send the required information since I still don't have these components and can't run diagnostics tools. I'm just asking if at first sight there's somethign weird with this. Thank you. I copy the specifications page from the motherboard vendor, since the link seems not to lead to it directly. Specifications CPU AMD Socket AM3 ;PhenomII /AthlonII /Sempron 100 Series Processors AMD 140W CPU Support AMD Cool 'n' Quiet 2.0 Technology (by CPU type) Support 45nm CPU *Refer to www.asus.com for the AMD CPU support list Chipset AMD 770/SB710 System Bus Up to 5200 MT/s HyperTransport 3.0 interface Memory 4 x DIMM, Max. 16 GB, DDR3 1800(O.C.)/1600(O.C.)/1333/1066 ECC,Non-ECC,Un-buffered Memory Dual Channel memory architecture *AMD AM3 100 and 200 series CPU support up to DDR3 1066MHz **Due to OS limitation, when installing total memory of 4GB capacity or more, Windows® 32-bit operation system may only recognize less than 3GB. Install a 64-bit WindowsWindows® OS when you want to install 4GB or more memory on the motherboard. ***Refer to www.asus.com or user manual for Memory QVL (Qualify Vendor List) Expansion Slots 2 x PCIe 2.0 x16 (*blue@ x16 mode, black@ x4 mode) 1 x PCIe x1 3 x PCI Storage SB710 Chipset 1 xUltraDMA 133/100 5 x Serial ATA 3Gb/s Support RAID 0,1,10 1 x eSATA 3Gb/s ports U3S6 card: - 2 x SATA 6Gb/s ports LAN Realtek 8112L PCIe Gb LAN Audio VT1708S High Definition Audio 8-Channel CODEC - Supports Jack-detect and Multistreaming teconologies, and Front Panel Jack-Retasking - Optical S/PDIF Out ports at back I/O USB 2 x USB 3.0 ports at U3S6 card 12 USB2.0/1.1 ports (6 ports at mid-board, 6 ports at back panel) ASUS Unique FeaturesASUS EPU-4 Engine ASUS Express Gate ASUS Turbo Key ASUS Q-Fan ASUS CrashFree BIOS 3 ASUS EZ Flash 2 ASUS MyLogo 2 ASUS AI NET 2 Overclocking Features Intelligent overclocking tools - Turbo Key SFS (Stepless Frequency Selection) - FSB tuning from 200MHz up to 550MHz at 1MHz increment - PCI Express frequency tuning from 100MHz up to 150MHz at 1MHz increment Overclocking Protection - ASUS C.P.R.(CPU Parameter Recall) Special FeaturesTrue SATA 6Gb/s USB 3.0 support 100% All High-quality Conductive Polymer Capacitors Back Panel I/O Ports1 x PS/2 Keyboard/Mouse Combo port 1 x Parallel port 1 x S/PDIF Out (Optical) 1 x LAN(RJ45) port 1 x COM port 8 -Channel Audio I/O 2 x USB 3.0 ports(@ U3S6 card ) / 6 x USB 2.0ports 1 x ESATA 3Gb/s Internal I/O Connectors 3 x USB connectors supports additional 6 USB 2.0 ports 1 x IDE connector 1 x CPU / 1 x Power / 1 x Chassis Fan connectors 1 x S/PDIF Out connector 1 x System Panel connector 1 x CD audio-in connector 1 x High Definition Front panel audio connector 1 x
[coreboot] computers with Coreboot BIOS
Recently I inquired with Inatux Computers, which sells pre-installed systems that include gNewSense and Trisquel, among others, about plans for offering coreboot BIOS as an option. After a few emails back and forth, they quickly added some information on their website on the following page: http://inatux.com/?gnu (text is below) Free BIOS (Coreboot, etc.): --- Our computers are not yet available with a Free BIOS, but we are very interested in offering that option in the future. We can build systems with Coreboot as the BIOS, but there will be some limitations as to certain video cards (ATI for 3D), processors, motherboards, memory, WiFi, and other areas as well. Please write us if you are interested. I think that this is good news, and I hope it gets around. --pete link-- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Linux booting hangs when booted by FILO
set kernel flags for earlyprintk earlyprintk=ttyS0,115200,keep very useful. ron -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] H8QME-2+ boot problems on different machines.
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? Thanks, Ward. -- Ward Vandewege w...@fsf.org Free Software Foundation - Senior Systems Administrator -- 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
Re: [coreboot] H8QME-2+ boot problems on different machines.
On 4/30/10 6:26 PM, Knut Kujat wrote: 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!! Is this the PCI access race condition? How are the CPUs different? 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
[coreboot] [commit] r5512 - in trunk/src: mainboard/arima/hdama mainboard/pcengines/alix1c northbridge/amd/amdfam10 northbridge/amd/amdk8 northbridge/amd/amdmct/mct northbridge/intel/i3100 northbridge
Author: myles
Date: Fri Apr 30 19:11:03 2010
New Revision: 5512
URL: https://tracker.coreboot.org/trac/coreboot/changeset/5512
Log:
Get rid of a few more warnings.
Signed-off-by: Myles Watson myle...@gmail.com
Acked-by: Myles Watson myle...@gmail.com
Modified:
trunk/src/mainboard/arima/hdama/romstage.c
trunk/src/mainboard/pcengines/alix1c/romstage.c
trunk/src/northbridge/amd/amdfam10/Makefile.inc
trunk/src/northbridge/amd/amdfam10/debug.c
trunk/src/northbridge/amd/amdfam10/get_pci1234.c
trunk/src/northbridge/amd/amdfam10/northbridge.h
trunk/src/northbridge/amd/amdk8/raminit_f.c
trunk/src/northbridge/amd/amdk8/raminit_f_dqs.c
trunk/src/northbridge/amd/amdmct/mct/mct_d.c
trunk/src/northbridge/intel/i3100/raminit.c
trunk/src/northbridge/via/vx800/vga.c
trunk/src/southbridge/intel/esb6300/esb6300_smbus.h
trunk/src/southbridge/nvidia/mcp55/mcp55_early_setup_car.c
Modified: trunk/src/mainboard/arima/hdama/romstage.c
==
--- trunk/src/mainboard/arima/hdama/romstage.c Tue Apr 27 17:00:18 2010
(r5511)
+++ trunk/src/mainboard/arima/hdama/romstage.c Fri Apr 30 19:11:03 2010
(r5512)
@@ -1,10 +1,10 @@
#include stdint.h
+#include string.h
#include device/pci_def.h
#include arch/io.h
#include device/pnp_def.h
#include arch/romcc_io.h
#include cpu/x86/lapic.h
-#include stdlib.h
#include option_table.h
#include pc80/mc146818rtc_early.c
#include pc80/serial.c
Modified: trunk/src/mainboard/pcengines/alix1c/romstage.c
==
--- trunk/src/mainboard/pcengines/alix1c/romstage.c Tue Apr 27 17:00:18
2010(r5511)
+++ trunk/src/mainboard/pcengines/alix1c/romstage.c Fri Apr 30 19:11:03
2010(r5512)
@@ -36,7 +36,7 @@
#define SERIAL_DEV PNP_DEV(0x2e, W83627HF_SP1)
/* The ALIX1.C has no SMBus; the setup is hard-wired. */
-void cs5536_enable_smbus(void)
+static void cs5536_enable_smbus(void)
{
}
Modified: trunk/src/northbridge/amd/amdfam10/Makefile.inc
==
--- trunk/src/northbridge/amd/amdfam10/Makefile.inc Tue Apr 27 17:00:18
2010(r5511)
+++ trunk/src/northbridge/amd/amdfam10/Makefile.inc Fri Apr 30 19:11:03
2010(r5512)
@@ -10,4 +10,3 @@
obj-$(CONFIG_GENERATE_ACPI_TABLES) += sspr5.o
obj-y += get_pci1234.o
-
Modified: trunk/src/northbridge/amd/amdfam10/debug.c
==
--- trunk/src/northbridge/amd/amdfam10/debug.c Tue Apr 27 17:00:18 2010
(r5511)
+++ trunk/src/northbridge/amd/amdfam10/debug.c Fri Apr 30 19:11:03 2010
(r5512)
@@ -26,7 +26,7 @@
static inline void print_debug_addr(const char *str, void *val)
{
-#if CACHE_AS_RAM_ADDRESS_DEBUG == 1
+#if defined(CACHE_AS_RAM_ADDRESS_DEBUG) CACHE_AS_RAM_ADDRESS_DEBUG == 1
printk(BIOS_DEBUG, --Address debug: %s%p--\n, str,
val);
#endif
}
Modified: trunk/src/northbridge/amd/amdfam10/get_pci1234.c
==
--- trunk/src/northbridge/amd/amdfam10/get_pci1234.cTue Apr 27 17:00:18
2010(r5511)
+++ trunk/src/northbridge/amd/amdfam10/get_pci1234.cFri Apr 30 19:11:03
2010(r5512)
@@ -55,6 +55,7 @@
*
*/
+#include northbridge.h
void get_pci1234(void)
{
Modified: trunk/src/northbridge/amd/amdfam10/northbridge.h
==
--- trunk/src/northbridge/amd/amdfam10/northbridge.hTue Apr 27 17:00:18
2010(r5511)
+++ trunk/src/northbridge/amd/amdfam10/northbridge.hFri Apr 30 19:11:03
2010(r5512)
@@ -21,5 +21,6 @@
#define NORTHBRIDGE_AMD_AMDFAM10_H
u32 amdfam10_scan_root_bus(device_t root, u32 max);
+void get_pci1234(void);
#endif /* NORTHBRIDGE_AMD_AMDFAM10_H */
Modified: trunk/src/northbridge/amd/amdk8/raminit_f.c
==
--- trunk/src/northbridge/amd/amdk8/raminit_f.c Tue Apr 27 17:00:18 2010
(r5511)
+++ trunk/src/northbridge/amd/amdk8/raminit_f.c Fri Apr 30 19:11:03 2010
(r5512)
@@ -2511,9 +2511,8 @@
unsigned SlowAccessMode = 0;
#endif
- long dimm_mask = meminfo-dimm_mask 0x0f;
-
#if CONFIG_DIMM_SUPPORT==0x0104 /* DDR2 and REG */
+ long dimm_mask = meminfo-dimm_mask 0x0f;
/* for REG DIMM */
dword = 0x00111222;
dwordx = 0x002f;
@@ -2578,6 +2577,7 @@
#endif
#if CONFIG_DIMM_SUPPORT==0x0004 /* DDR2 and unbuffered */
+ long dimm_mask = meminfo-dimm_mask 0x0f;
/* for UNBUF DIMM */
dword = 0x00111222;
dwordx = 0x002f2f00;
Modified: trunk/src/northbridge/amd/amdk8/raminit_f_dqs.c
==
---
[coreboot] Warnings
As of 5512, these are the last four warnings that are not defined but not used warnings. src/northbridge/amd/gx2/chipsetinit.c:271: warning: suggest parentheses around '-' inside '' src/northbridge/amd/lx/raminit.c:334: warning: array subscript is above array bounds src/northbridge/via/vx800/pci_rawops.h:43:2: warning: #warning FIXME: get rid of this extra copy of pci access functions. src/southbridge/intel/pxhd/pxhd_bridge.c:70:2: warning: #warning Please review lots of dead code here. Thanks, Myles -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] build service results for r5512
Dear coreboot readers! This is the automatic build system of coreboot. The developer myles checked in revision 5512 to the coreboot repository. This caused the following changes: Change Log: Get rid of a few more warnings. Signed-off-by: Myles Watson myle...@gmail.com Acked-by: Myles Watson myle...@gmail.com Build Log: Compilation of intel:mtarvon has been broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=5512device=mtarvonvendor=intelnum=2 If something broke during this checkin please be a pain in myles's neck until the issue is fixed. If this issue is not fixed within 24h the revision should be backed out. Best regards, coreboot automatic build system -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] [commit] r5513 - trunk/src/northbridge/via/vx800
Author: stepan
Date: Fri Apr 30 19:44:39 2010
New Revision: 5513
URL: https://tracker.coreboot.org/trac/coreboot/changeset/5513
Log:
drop extra pci access functions. these are exact copies of romcc_io.h.
Signed-off-by: Stefan Reinauer ste...@coresystems.de
Acked-by: Stefan Reinauer ste...@coresystems.de
Modified:
trunk/src/northbridge/via/vx800/pci_rawops.h
trunk/src/northbridge/via/vx800/uma_ram_setting.c
Modified: trunk/src/northbridge/via/vx800/pci_rawops.h
==
--- trunk/src/northbridge/via/vx800/pci_rawops.hFri Apr 30 19:11:03
2010(r5512)
+++ trunk/src/northbridge/via/vx800/pci_rawops.hFri Apr 30 19:44:39
2010(r5513)
@@ -2,11 +2,11 @@
* This file is part of the coreboot project.
*
* Copyright (C) 2009 One Laptop per Child, Association, Inc.
+ * Copyright (C) 2010 coresystems GmbH
*
* 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.
+ * the Free Software Foundation; version 2 of the License.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
@@ -18,14 +18,11 @@
* Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
*/
-#ifndef ARCH_I386_PCI_RAWOPS_H
-# define ARCH_I386_PCI_RAWOPS_H 1
-#include stdint.h
+#ifndef NORTHBRIDGE_VIA_VX800_PCI_RAWOPS_H
+#define NORTHBRIDGE_VIA_VX800_PCI_RAWOPS_H
-#define PCI_RAWDEV(SEGBUS, DEV, FN) ( \
-(((SEGBUS) 0xFFF) 20) | \
-(((DEV) 0x1F) 15) | \
-(((FN) 0x07) 12))
+#include stdint.h
+#include arch/romcc_io.h
struct VIA_PCI_REG_INIT_TABLE {
u8 ChipRevisionStart;
@@ -38,219 +35,31 @@
u8 Value;
};
-typedef unsigned device_t_raw; /* pci and pci_mmio need to have different ways
to have dev */
-
-#warning FIXME: get rid of this extra copy of pci access functions.
-
-/* FIXME: We need to make the coreboot to run at 64bit mode, So when
read/write memory above 4G,
- * We don't need to set %fs, and %gs anymore
- * Before that We need to use %gs, and leave %fs to other RAM access
- */
-static u8 pci_io_rawread_config8(device_t_raw dev, unsigned where)
-{
- unsigned addr;
-#if CONFIG_PCI_IO_CFG_EXT == 0
- addr = (dev 4) | where;
-#else
- addr = (dev 4) | (where 0xff) | ((where 0xf00) 16); //seg
== 0
-#endif
- outl(0x8000 | (addr ~3), 0xCF8);
- return inb(0xCFC + (addr 3));
-}
-
-#if CONFIG_MMCONF_SUPPORT
-static u8 pci_mmio_rawread_config8(device_t_raw dev, unsigned where)
-{
- unsigned addr;
- addr = dev | where;
- return read8x(addr);
-}
-#endif
-static u8 pci_rawread_config8(device_t_raw dev, unsigned where)
-{
-#if CONFIG_MMCONF_SUPPORT
- return pci_mmio_rawread_config8(dev, where);
-#else
- return pci_io_rawread_config8(dev, where);
-#endif
-}
-
-static u16 pci_io_rawread_config16(device_t_raw dev, unsigned where)
-{
- unsigned addr;
-#if CONFIG_PCI_IO_CFG_EXT == 0
- addr = (dev 4) | where;
-#else
- addr = (dev 4) | (where 0xff) | ((where 0xf00) 16);
-#endif
- outl(0x8000 | (addr ~3), 0xCF8);
- return inw(0xCFC + (addr 2));
-}
-
-#if CONFIG_MMCONF_SUPPORT
-static u16 pci_mmio_rawread_config16(device_t_raw dev, unsigned where)
-{
- unsigned addr;
- addr = dev | where;
- return read16x(addr);
-}
-#endif
-
-static u16 pci_rawread_config16(device_t_raw dev, unsigned where)
-{
-#if CONFIG_MMCONF_SUPPORT
- return pci_mmio_rawread_config16(dev, where);
-#else
- return pci_io_rawread_config16(dev, where);
-#endif
-}
-
-static u32 pci_io_rawread_config32(device_t_raw dev, unsigned where)
-{
- unsigned addr;
-#if CONFIG_PCI_IO_CFG_EXT == 0
- addr = (dev 4) | where;
-#else
- addr = (dev 4) | (where 0xff) | ((where 0xf00) 16);
-#endif
- outl(0x8000 | (addr ~3), 0xCF8);
- return inl(0xCFC);
-}
-
-#if CONFIG_MMCONF_SUPPORT
-static u32 pci_mmio_rawread_config32(device_t_raw dev, unsigned where)
-{
- unsigned addr;
- addr = dev | where;
- return read32x(addr);
-}
-#endif
-
-static u32 pci_rawread_config32(device_t_raw dev, unsigned where)
-{
-#if CONFIG_MMCONF_SUPPORT
- return pci_mmio_rawread_config32(dev, where);
-#else
- return pci_io_rawread_config32(dev, where);
-#endif
-}
-
-static void pci_io_rawwrite_config8(device_t_raw dev, unsigned where, u8 value)
-{
- unsigned addr;
-#if CONFIG_PCI_IO_CFG_EXT == 0
- addr = (dev 4) | where;
-#else
- addr = (dev 4) | (where 0xff) | ((where 0xf00) 16);
-#endif
- outl(0x8000 | (addr ~3), 0xCF8);
- outb(value, 0xCFC + (addr 3));
-}
-
-#if CONFIG_MMCONF_SUPPORT
-static void
[coreboot] [commit] r5514 - trunk/src/southbridge/intel/pxhd
Author: stepan Date: Fri Apr 30 19:46:16 2010 New Revision: 5514 URL: https://tracker.coreboot.org/trac/coreboot/changeset/5514 Log: Doesn't need to be a warning. Signed-off-by: Stefan Reinauer ste...@coresystems.de Acked-by: Stefan Reinauer ste...@coresystems.de Modified: trunk/src/southbridge/intel/pxhd/pxhd_bridge.c Modified: trunk/src/southbridge/intel/pxhd/pxhd_bridge.c == --- trunk/src/southbridge/intel/pxhd/pxhd_bridge.c Fri Apr 30 19:44:39 2010(r5513) +++ trunk/src/southbridge/intel/pxhd/pxhd_bridge.c Fri Apr 30 19:46:16 2010(r5514) @@ -67,7 +67,7 @@ /* Bridge control ISA enable */ pci_write_config8(dev, 0x3e, 0x07); -#warning Please review lots of dead code here. + // FIXME Please review lots of dead code here. #if 0 int nmi_option; uint32_t dword; -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] [commit] r5515 - trunk/src/northbridge/intel/i3100
Author: stepan
Date: Fri Apr 30 19:50:53 2010
New Revision: 5515
URL: https://tracker.coreboot.org/trac/coreboot/changeset/5515
Log:
fix compilation of mtarvon
Signed-off-by: Stefan Reinauer ste...@coresystems.de
Acked-by: Stefan Reinauer ste...@coresystems.de
Modified:
trunk/src/northbridge/intel/i3100/raminit.c
Modified: trunk/src/northbridge/intel/i3100/raminit.c
==
--- trunk/src/northbridge/intel/i3100/raminit.c Fri Apr 30 19:46:16 2010
(r5514)
+++ trunk/src/northbridge/intel/i3100/raminit.c Fri Apr 30 19:50:53 2010
(r5515)
@@ -944,7 +944,7 @@
u32 drc;
u32 data32;
u32 mode_reg;
- u32 const *iptr;
+ const u32 *iptr;
u16 data16;
static const struct {
u32 clkgr[4];
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Warnings
On 4/30/10 7:13 PM, Myles Watson wrote: As of 5512, these are the last four warnings that are not defined but not used warnings. What's your impression... should we activate -Wno-unused ? or should we attempt to fix them? I'd like to go drop all / most of the #ifdef UNUSED_CODE segments from coreboot over time, making it easier to follow the code that is actually there. Most of the existing warnings are amd k8 / fam10 warnings... and it's kind of tricky to understand why one board does init different than another one. Why don't all boards use wait_all_aps_started and / or wait_all_core0_started and / or allow_all_aps_stop? I think the unused messages show that we have too much unnecessary diversity here (aka rank growth) src/northbridge/amd/gx2/chipsetinit.c:271: warning: suggest parentheses around '-' inside '' This would need help from someone with a GX2 (or willing to check out the data sheets ;-) src/northbridge/amd/lx/raminit.c:334: warning: array subscript is above array bounds Marc indicated, this could be a compiler problem. We could maybe add an explicit check for the array index. src/northbridge/via/vx800/pci_rawops.h:43:2: warning: #warning FIXME: get rid of this extra copy of pci access functions. Gone with 5513 src/southbridge/intel/pxhd/pxhd_bridge.c:70:2: warning: #warning Please review lots of dead code here. Gone with 5514 -- 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
[coreboot] build service results for r5513
Dear coreboot readers! This is the automatic build system of coreboot. The developer stepan checked in revision 5513 to the coreboot repository. This caused the following changes: Change Log: drop extra pci access functions. these are exact copies of romcc_io.h. Signed-off-by: Stefan Reinauer ste...@coresystems.de Acked-by: Stefan Reinauer ste...@coresystems.de Build Log: Compilation of intel:mtarvon is still broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=5513device=mtarvonvendor=intelnum=2 If something broke during this checkin please be a pain in stepan's neck until the issue is fixed. If this issue is not fixed within 24h the revision should be backed out. Best regards, coreboot automatic build system -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] build service results for r5514
Dear coreboot readers! This is the automatic build system of coreboot. The developer stepan checked in revision 5514 to the coreboot repository. This caused the following changes: Change Log: Doesn't need to be a warning. Signed-off-by: Stefan Reinauer ste...@coresystems.de Acked-by: Stefan Reinauer ste...@coresystems.de Build Log: Compilation of intel:mtarvon is still broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=5514device=mtarvonvendor=intelnum=2 If something broke during this checkin please be a pain in stepan's neck until the issue is fixed. If this issue is not fixed within 24h the revision should be backed out. Best regards, coreboot automatic build system -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] build service results for r5515
Dear coreboot readers! This is the automatic build system of coreboot. The developer stepan checked in revision 5515 to the coreboot repository. This caused the following changes: Change Log: fix compilation of mtarvon Signed-off-by: Stefan Reinauer ste...@coresystems.de Acked-by: Stefan Reinauer ste...@coresystems.de Build Log: Compilation of intel:mtarvon has been fixed If something broke during this checkin please be a pain in stepan's neck until the issue is fixed. If this issue is not fixed within 24h the revision should be backed out. Best regards, coreboot automatic build system -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] [commit] r5516 - in trunk/src: northbridge/via/vx800 southbridge/amd/sb600
Author: stepan
Date: Fri Apr 30 21:21:01 2010
New Revision: 5516
URL: https://tracker.coreboot.org/trac/coreboot/changeset/5516
Log:
get rid of some more warnings..
Signed-off-by: Stefan Reinauer ste...@coresystems.de
Acked-by: Stefan Reinauer ste...@coresystems.de
Modified:
trunk/src/northbridge/via/vx800/vx800_lpc.c
trunk/src/southbridge/amd/sb600/sb600.h
trunk/src/southbridge/amd/sb600/sb600_early_setup.c
Modified: trunk/src/northbridge/via/vx800/vx800_lpc.c
==
--- trunk/src/northbridge/via/vx800/vx800_lpc.c Fri Apr 30 19:50:53 2010
(r5515)
+++ trunk/src/northbridge/via/vx800/vx800_lpc.c Fri Apr 30 21:21:01 2010
(r5516)
@@ -342,9 +342,11 @@
/* turn on keyboard and RTC, no need to visit this reg twice */
pc_keyboard_init(0);
+
printk(BIOS_DEBUG, ps2 usb lid, you set who can wakeup system from s3
sleep\n);
S3_ps2_kb_ms_wakeup(dev);
S3_usb_wakeup(dev);
+ S3_lid_wakeup(dev);
/* enable acpi cpu c3 state. (c2 state need not do anything.)
#1
Modified: trunk/src/southbridge/amd/sb600/sb600.h
==
--- trunk/src/southbridge/amd/sb600/sb600.h Fri Apr 30 19:50:53 2010
(r5515)
+++ trunk/src/southbridge/amd/sb600/sb600.h Fri Apr 30 21:21:01 2010
(r5516)
@@ -37,4 +37,7 @@
void sb600_enable(device_t dev);
+void sb600_lpc_port80(void);
+void sb600_pci_port80(void);
+
#endif /* SB600_H */
Modified: trunk/src/southbridge/amd/sb600/sb600_early_setup.c
==
--- trunk/src/southbridge/amd/sb600/sb600_early_setup.c Fri Apr 30 19:50:53
2010(r5515)
+++ trunk/src/southbridge/amd/sb600/sb600_early_setup.c Fri Apr 30 21:21:01
2010(r5516)
@@ -213,7 +213,7 @@
outb(0x06, 0x0cf9);
}
-static void sb600_pci_port80(void)
+void sb600_pci_port80(void)
{
u8 byte;
device_t dev;
@@ -258,7 +258,7 @@
pci_write_config8(dev, 0x4A, byte);
}
-static void sb600_lpc_port80(void)
+void sb600_lpc_port80(void)
{
u8 byte;
device_t dev;
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Warnings
src/northbridge/amd/lx/raminit.c:334: warning: array subscript is
above array bounds
Marc indicated, this could be a compiler problem. We could maybe add an
explicit check for the array index.
It looks like it's being indexed by a function that's built into the
compiler that returns bit positions. Since the return value could be
up to 31, I think it's a correct warning (the array's only got 8
elements.)
This patch fixes the warnings. All I did was factor out the identical
code into a function, and remove some unnecessary casts. So I guess I
was wrong.
Signed-off-by: Myles Watson myle...@gmail.com
Thanks,
Myles
Index: src/northbridge/amd/lx/raminit.c
===
--- src/northbridge/amd/lx/raminit.c (revision 5516)
+++ src/northbridge/amd/lx/raminit.c (working copy)
@@ -238,46 +238,23 @@
const uint8_t CASDDR[] = { 5, 5, 2, 6, 3, 7, 4, 0 }; /* 1(1.5), 1.5, 2, 2.5, 3, 3.5, 4, 0 */
-static void setCAS(void)
+static u8 getcasmap(u32 dimm, u16 glspeed)
{
-/*;*
-;*
-;* setCAS
-;* EEPROM byte usage: (18) SDRAM device attributes - CAS latency
-;* EEPROM byte usage: (23) SDRAM Minimum Clock Cycle Time @ CLX -.5
-;* EEPROM byte usage: (25) SDRAM Minimum Clock Cycle Time @ CLX -1
-;*
-;* The CAS setting is based on the information provided in each DIMMs SPD.
-;* The speed at which a DIMM can run is described relative to the slowest
-;* CAS the DIMM supports. Each speed for the relative CAS settings is
-;* checked that it is within the GeodeLink speed. If it isn't within the GeodeLink
-;* speed, the CAS setting is removed from the list of good settings for
-;* the DIMM. This is done for both DIMMs and the lists are compared to
-;* find the lowest common CAS latency setting. If there are no CAS settings
-;* in common we out a ERROR_DIFF_DIMMS (78h) to port 80h and halt.
-;*
-;* Entry:
-;* Exit: Set fastest CAS Latency based on GeodeLink speed and SPD information.
-;* Destroys: We really use everything !
-;*/
- uint16_t glspeed, dimm_speed;
- uint8_t spd_byte, casmap0, casmap1, casmap_shift;
- msr_t msr;
+ u16 dimm_speed;
+ u8 spd_byte, casmap, casmap_shift=0;
- glspeed = GeodeLinkSpeed();
-
/** DIMM0 **/
- casmap0 = spd_read_byte(DIMM0, SPD_ACCEPTABLE_CAS_LATENCIES);
- if (casmap0 != 0xFF) {
+ casmap = spd_read_byte(dimm, SPD_ACCEPTABLE_CAS_LATENCIES);
+ if (casmap != 0xFF) {
/* IF -.5 timing is supported, check -.5 timing GeodeLink */
- spd_byte = spd_read_byte(DIMM0, SPD_SDRAM_CYCLE_TIME_2ND);
+ spd_byte = spd_read_byte(dimm, SPD_SDRAM_CYCLE_TIME_2ND);
if (spd_byte != 0) {
/* Turn SPD ns time into MHZ. Check what the asm does to this math. */
dimm_speed = 2 / (((spd_byte 4) * 10) + (spd_byte 0x0F));
if (dimm_speed = glspeed) {
casmap_shift = 1; /* -.5 is a shift of 1 */
/* IF -1 timing is supported, check -1 timing GeodeLink */
-spd_byte = spd_read_byte(DIMM0, SPD_SDRAM_CYCLE_TIME_3RD);
+spd_byte = spd_read_byte(dimm, SPD_SDRAM_CYCLE_TIME_3RD);
if (spd_byte != 0) {
/* Turn SPD ns time into MHZ. Check what the asm does to this math. */
dimm_speed = 2 / (((spd_byte 4) * 10) + (spd_byte 0x0F));
@@ -290,52 +267,53 @@
}
} /* SPD_SDRAM_CYCLE_TIME_2ND (-.5) !=0 */
/* set the casmap based on the shift to limit possible CAS settings */
- spd_byte = 31 - __builtin_clz((uint32_t) casmap0);
+ spd_byte = 31 - __builtin_clz((uint32_t) casmap);
/* just want bits in the lower byte since we have to cast to a 32 */
- casmap0 = 0xFF (spd_byte - casmap_shift);
+ casmap = 0xFF (spd_byte - casmap_shift);
} else { /* No DIMM */
- casmap0 = 0;
+ casmap = 0;
}
+ return casmap;
+}
- /** DIMM1 **/
- casmap1 = spd_read_byte(DIMM1, SPD_ACCEPTABLE_CAS_LATENCIES);
- if (casmap1 != 0xFF) {
- /* IF -.5 timing is supported, check -.5 timing GeodeLink */
- spd_byte = spd_read_byte(DIMM1, SPD_SDRAM_CYCLE_TIME_2ND);
- if (spd_byte != 0) {
- /* Turn SPD ns time into MHZ. Check what the asm does to this math. */
- dimm_speed = 2 / (((spd_byte 4) * 10) + (spd_byte 0x0F));
- if (dimm_speed = glspeed) {
-casmap_shift = 1; /* -.5 is a shift of 1 */
-/* IF -1 timing is supported, check -1 timing GeodeLink */
-spd_byte = spd_read_byte(DIMM1, SPD_SDRAM_CYCLE_TIME_3RD);
-if (spd_byte != 0) {
- /* Turn SPD ns time into MHZ. Check what the asm does to this math. */
- dimm_speed = 2 / (((spd_byte 4) * 10) + (spd_byte 0x0F));
- if (dimm_speed = glspeed) {
- casmap_shift = 2; /* -1 is a shift of 2 */
- }
- /* note that the -1 result doesn't need to change the available CAS map */
-} /* SPD_SDRAM_CYCLE_TIME_3RD (-1) !=0 */
- } else {
-casmap_shift = 0;
Re: [coreboot] Warnings
On 4/30/10 10:17 PM, Myles Watson wrote: src/northbridge/amd/lx/raminit.c:334: warning: array subscript is above array bounds Marc indicated, this could be a compiler problem. We could maybe add an explicit check for the array index. It looks like it's being indexed by a function that's built into the compiler that returns bit positions. Since the return value could be up to 31, I think it's a correct warning (the array's only got 8 elements.) This patch fixes the warnings. All I did was factor out the identical code into a function, and remove some unnecessary casts. So I guess I was wrong. Signed-off-by: Myles Watson myle...@gmail.com Acked-by: Stefan Reinauer ste...@coresystems.de -- 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
[coreboot] [commit] r5517 - trunk/src/northbridge/amd/amdfam10
Author: stepan
Date: Fri Apr 30 22:28:35 2010
New Revision: 5517
URL: https://tracker.coreboot.org/trac/coreboot/changeset/5517
Log:
Remove some more warnings. The code is only used by functions protected by the
same preprocessor check
Signed-off-by: Stefan Reinauer ste...@coresystems.de
Acked-by: Stefan Reinauer ste...@coresystems.de
Modified:
trunk/src/northbridge/amd/amdfam10/amdfam10_conf.c
Modified: trunk/src/northbridge/amd/amdfam10/amdfam10_conf.c
==
--- trunk/src/northbridge/amd/amdfam10/amdfam10_conf.c Fri Apr 30 21:21:01
2010(r5516)
+++ trunk/src/northbridge/amd/amdfam10/amdfam10_conf.c Fri Apr 30 22:28:35
2010(r5517)
@@ -152,6 +152,7 @@
return sel_m;
}
+#if CONFIG_AMDMCT == 0
#ifdef UNUSED_CODE
static void set_DctSelHiEn(u32 i, u32 val)
{
@@ -219,8 +220,6 @@
}
#endif
-#if CONFIG_AMDMCT == 0
-
static u32 get_one_DCT(struct mem_info *meminfo)
{
u32 one_DCT = 1;
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] [commit] r5519 - trunk/src/northbridge/amd/lx
Author: myles
Date: Fri Apr 30 22:36:02 2010
New Revision: 5519
URL: https://tracker.coreboot.org/trac/coreboot/changeset/5519
Log:
Factor out casmap calculation. Gets rid of a warning.
Signed-off-by: Myles Watson myle...@gmail.com
Acked-by: Stefan Reinauer ste...@coresystems.de
Modified:
trunk/src/northbridge/amd/lx/raminit.c
Modified: trunk/src/northbridge/amd/lx/raminit.c
==
--- trunk/src/northbridge/amd/lx/raminit.c Fri Apr 30 22:30:47 2010
(r5518)
+++ trunk/src/northbridge/amd/lx/raminit.c Fri Apr 30 22:36:02 2010
(r5519)
@@ -238,46 +238,23 @@
const uint8_t CASDDR[] = { 5, 5, 2, 6, 3, 7, 4, 0 }; /* 1(1.5), 1.5, 2, 2.5,
3, 3.5, 4, 0 */
-static void setCAS(void)
+static u8 getcasmap(u32 dimm, u16 glspeed)
{
-/*;*
-;*
-;* setCAS
-;* EEPROM byte usage: (18) SDRAM device attributes - CAS latency
-;* EEPROM byte usage: (23) SDRAM Minimum Clock Cycle Time @ CLX -.5
-;* EEPROM byte usage: (25) SDRAM Minimum Clock Cycle Time @ CLX -1
-;*
-;* The CAS setting is based on the information provided in each DIMMs SPD.
-;* The speed at which a DIMM can run is described relative to the slowest
-;* CAS the DIMM supports. Each speed for the relative CAS settings is
-;* checked that it is within the GeodeLink speed. If it isn't within the
GeodeLink
-;* speed, the CAS setting is removed from the list of good settings for
-;* the DIMM. This is done for both DIMMs and the lists are compared to
-;* find the lowest common CAS latency setting. If there are no CAS
settings
-;* in common we out a ERROR_DIFF_DIMMS (78h) to port 80h and halt.
-;*
-;* Entry:
-;* Exit: Set fastest CAS Latency based on GeodeLink speed and SPD
information.
-;* Destroys: We really use everything !
-;*/
- uint16_t glspeed, dimm_speed;
- uint8_t spd_byte, casmap0, casmap1, casmap_shift;
- msr_t msr;
-
- glspeed = GeodeLinkSpeed();
+ u16 dimm_speed;
+ u8 spd_byte, casmap, casmap_shift=0;
/** DIMM0
**/
- casmap0 = spd_read_byte(DIMM0, SPD_ACCEPTABLE_CAS_LATENCIES);
- if (casmap0 != 0xFF) {
+ casmap = spd_read_byte(dimm, SPD_ACCEPTABLE_CAS_LATENCIES);
+ if (casmap != 0xFF) {
/* IF -.5 timing is supported, check -.5 timing GeodeLink */
- spd_byte = spd_read_byte(DIMM0, SPD_SDRAM_CYCLE_TIME_2ND);
+ spd_byte = spd_read_byte(dimm, SPD_SDRAM_CYCLE_TIME_2ND);
if (spd_byte != 0) {
/* Turn SPD ns time into MHZ. Check what the asm does
to this math. */
dimm_speed = 2 / (((spd_byte 4) * 10) +
(spd_byte 0x0F));
if (dimm_speed = glspeed) {
casmap_shift = 1; /* -.5 is a shift of 1 */
/* IF -1 timing is supported, check -1 timing
GeodeLink */
- spd_byte = spd_read_byte(DIMM0,
SPD_SDRAM_CYCLE_TIME_3RD);
+ spd_byte = spd_read_byte(dimm,
SPD_SDRAM_CYCLE_TIME_3RD);
if (spd_byte != 0) {
/* Turn SPD ns time into MHZ. Check
what the asm does to this math. */
dimm_speed = 2 / (((spd_byte 4)
* 10) + (spd_byte 0x0F));
@@ -290,52 +267,53 @@
}
} /* SPD_SDRAM_CYCLE_TIME_2ND (-.5) !=0 */
/* set the casmap based on the shift to limit possible CAS
settings */
- spd_byte = 31 - __builtin_clz((uint32_t) casmap0);
+ spd_byte = 31 - __builtin_clz((uint32_t) casmap);
/* just want bits in the lower byte since we have to cast to a
32 */
- casmap0 = 0xFF (spd_byte - casmap_shift);
+ casmap = 0xFF (spd_byte - casmap_shift);
} else {/* No DIMM */
- casmap0 = 0;
+ casmap = 0;
}
+ return casmap;
+}
- /** DIMM1
**/
- casmap1 = spd_read_byte(DIMM1, SPD_ACCEPTABLE_CAS_LATENCIES);
- if (casmap1 != 0xFF) {
- /* IF -.5 timing is supported, check -.5 timing GeodeLink */
- spd_byte = spd_read_byte(DIMM1, SPD_SDRAM_CYCLE_TIME_2ND);
- if (spd_byte != 0) {
- /* Turn SPD ns time into MHZ. Check what the asm does
to this math. */
- dimm_speed = 2 / (((spd_byte 4) * 10) +
(spd_byte 0x0F));
- if (dimm_speed = glspeed) {
- casmap_shift = 1;
Re: [coreboot] Warnings
On Fri, Apr 30, 2010 at 11:50 AM, Stefan Reinauer ste...@coresystems.de wrote: On 4/30/10 7:13 PM, Myles Watson wrote: As of 5512, these are the last four warnings that are not defined but not used warnings. What's your impression... should we activate -Wno-unused ? or should we attempt to fix them? I don't think it's worth activating -Wno-unused-functions untill we activate -Werror, but I think we should do that soon so that we don't reintroduce a lot of warnings. I'd like to go drop all / most of the #ifdef UNUSED_CODE segments from coreboot over time, making it easier to follow the code that is actually there. I agree. Most of the existing warnings are amd k8 / fam10 warnings... and it's kind of tricky to understand why one board does init different than another one. Why don't all boards use wait_all_aps_started and / or wait_all_core0_started and / or allow_all_aps_stop? I think the unused messages show that we have too much unnecessary diversity here (aka rank growth) Yes. There are definitely some things that need to be standardized, and the warnings are good at pointing that out, as you've said. src/northbridge/amd/gx2/chipsetinit.c:271: warning: suggest parentheses around '-' inside '' This would need help from someone with a GX2 (or willing to check out the data sheets ;-) src/northbridge/amd/lx/raminit.c:334: warning: array subscript is above array bounds Marc indicated, this could be a compiler problem. We could maybe add an explicit check for the array index. It looks like it's being indexed by a function that's built into the compiler that returns bit positions. Since the return value could be up to 31, I think it's a correct warning (the array's only got 8 elements.) src/northbridge/via/vx800/pci_rawops.h:43:2: warning: #warning FIXME: get rid of this extra copy of pci access functions. Gone with 5513 src/southbridge/intel/pxhd/pxhd_bridge.c:70:2: warning: #warning Please review lots of dead code here. Gone with 5514 It's much nicer to have so many fewer warnings! Thanks, Myles -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] run away pci scan
I'm working with amd/mahogany_fam10 mainboard and having problems in ramstage. It is going through pci device scanning when it starts finding the same devices again and malloc memory until it dies. It also looks like it never goes down a bridge, always staying on bus0. The problem starts at CPU: APIC: 03, it starts scanning bus0 again. Enumerating buses... Show all devs...Before Device Enumeration. Root Device: enabled 1, 0 resources APIC_CLUSTER: 0: enabled 1, 0 resources APIC: 00: enabled 1, 0 resources PCI_DOMAIN: : enabled 1, 0 resources ... normal device init happens. CPU: APIC: 00 enabled malloc Enter, size 1092, free_mem_ptr 0027 malloc 0027 CPU: APIC: 01 enabled malloc Enter, size 1092, free_mem_ptr 00270444 malloc 00270444 CPU: APIC: 02 enabled malloc Enter, size 1092, free_mem_ptr 00270888 malloc 00270888 CPU: APIC: 03 enabled PCI_DOMAIN: scanning... Anyone have thoughts on what is happening here? Attached complete serial log. Thanks! Marc -- http://se-eng.com -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] run away pci scan
I'm working with amd/mahogany_fam10 mainboard and having problems in ramstage. It is going through pci device scanning when it starts finding the same devices again and malloc memory until it dies. It also looks like it never goes down a bridge, always staying on bus0. The problem starts at CPU: APIC: 03, it starts scanning bus0 again. Anyone have thoughts on what is happening here? Have you tried increasing the stack size? That's been a problem in the past with this type of failure. Attached complete serial log. I didn't get it. Thanks, Myles -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Warnings
Hi Stefan, First of all thanks for the great improvements in Geode (GX2). On 4/30/10 7:50 PM, Stefan Reinauer wrote: src/northbridge/amd/gx2/chipsetinit.c:271: warning: suggest parentheses around '-' inside '' This would need help from someone with a GX2 (or willing to check out the data sheets ;-) I would be happy if i could be of any help with this, I have a GX2 board i can test on. I saw your discussion about the warning before and it inspired me to dedicate my spare free time to again update my working rev5446 patches to current trunk. But unfortunately i can`t get it to work anymore on rev5120 and some other rev`s i tried. (Linux errors out with: hda: lost interrupt) I will send the details in a separate mail. Thanks,Nils -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Warnings
On 04/30/2010 07:34 PM, Nils wrote: Hi Stefan, First of all thanks for the great improvements in Geode (GX2). On 4/30/10 7:50 PM, Stefan Reinauer wrote: src/northbridge/amd/gx2/chipsetinit.c:271: warning: suggest parentheses around '-' inside '' This would need help from someone with a GX2 (or willing to check out the data sheets ;-) I would be happy if i could be of any help with this, I have a GX2 board i can test on. I saw your discussion about the warning before and it inspired me to dedicate my spare free time to again update my working rev5446 patches to current trunk. But unfortunately i can`t get it to work anymore on rev5120 and some other rev`s i tried. (Linux errors out with: hda: lost interrupt) I will send the details in a separate mail. Thanks,Nils I have a GX2 also (AMD PIC) that is not supported by coreboot yet, but could test if needed. -- Thanks, Joseph Smith Set-Top-Linux www.settoplinux.org -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] run away pci scan
On Fri, Apr 30, 2010 at 4:21 PM, Myles Watson myle...@gmail.com wrote: Anyone have thoughts on what is happening here? Have you tried increasing the stack size? That's been a problem in the past with this type of failure. Thanks, I tried increasing the stack size from 0x8000 to 0x1, but that didn't seem to help. -- http://se-eng.com -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Porting to RS780/SB700 board
On Wed, Apr 28, 2010 at 6:26 AM, Myles Watson myle...@gmail.com wrote: Have you tried changing it to pci_locate_device_on_bus()? That will constrain the search to a single bus. That doesn't help; config space accesses to the PCIe bridge devices themselves are hanging. I worked around the problem by replacing pci_locate_device() with hardcoded PCI_DEV values, which should be okay for this chipset as long as the northbridge and southbridge are always at the normal addresses. I managed to set up SerialICE on my board and get a few thousand lines of tracing from the factory BIOS. I notice that it doesn't touch those PCIe bridge devices at all early on. Is it possible that some HyperTransport magic needs to happen to get them to behave? I don't know. It's surprising to hang. I think there must be some MTRR setup problem. Maybe you could print out the MTRRs just before the slow parts? Here's a dump of various MSRs right after the call to raminit_amdmct() in romstage.c: /* variable MTRRs */ msr 0200= msr 0201= msr 0202=fff6 msr 0203=fff80800 This looks wrong to me. I'm not an expert, but Since 202 is the base, and 203 is the mask, It looks like the area from 0xfff0 - 0xfff7 is cached. I would think the correct setting would be: msr 0202=fff6 msr 0203=fff00800 To cache the last MB of mem. msr 0204=0006 msr 0205=8800 Then this one caches 0 - 2GB msr 0206=8006 msr 0207=c800 This one caches 2GB-3GB msr 0208=c006 msr 0209=e800 This one caches 3GB-3.5GB Something to keep in mind is that caching should be disabled then enabled when setting the var MTRRs. Since you don't want to disable caches when you're using cache-as-RAM, I think it's best to make sure that the MTRRs are set correctly from the beginning and not touch them again until you've copied the RAM stage to the RAM and moved your stack. msr 020a= msr 020b= msr 020c= msr 020d= msr 020e= msr 020f= /* fixed MTRRs */ msr 0250=1e1e1e1e1e1e1e1e msr 0258=1e1e1e1e1e1e1e1e msr 0259= msr 0268=1e1e1e1e msr 0269=1e1e1e1e1e1e1e1e msr 026a= msr 026b= msr 026c=0404040404040404 msr 026d=0404040404040404 msr 026e=0404040404040404 msr 026f=0404040404040404 /* variable fixed MTRRs enabled */ msr 02ff=0c00 /* IORRs */ msr c0010016=8021 msr c0010017= msr c0010018= msr c0010019= /* top of memory registers */ msr c001001a=e000 msr c001001d=00012000 Another experiment I tried was to replace memset() with the original assembler version of clear_memory(). With this change, the Clearing initial memory region: step takes a fraction of a second vs. minutes with memset(). Then things grind to a halt after Stage: loading fallback/coreboot_ram @ My theory is that since clear_memory was a single rep instruction, the fact that it wasn't being cached wasn't a big deal. With the caches set correctly, memset was faster on my board. Good luck, Myles -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] computers with Coreboot BIOS
On Fri, 30 Apr 2010 04:36:36 -0700 (PDT), Peter Link peteli...@yahoo.com wrote: Recently I inquired with Inatux Computers, which sells pre-installed systems that include gNewSense and Trisquel, among others, about plans for offering coreboot BIOS as an option. After a few emails back and forth, they quickly added some information on their website on the following page: http://inatux.com/?gnu (text is below) Free BIOS (Coreboot, etc.): --- Our computers are not yet available with a Free BIOS, but we are very interested in offering that option in the future. We can build systems with Coreboot as the BIOS, but there will be some limitations as to certain video cards (ATI for 3D), processors, motherboards, memory, WiFi, and other areas as well. Please write us if you are interested. Yes that is good news Pete. I don't really get the part about limitations though, why would those items have limitations? -- Thanks, Joseph Smith Set-Top-Linux www.settoplinux.org -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
