Re: [coreboot] .cb files
ali hagigat wrote: So devicetree.cb files are written by hand and the compilation process does not use them? They are just some information for the developers? Of course not, that would be redundant. As Kerry pointed out, they are very much part of the build process. You can also see this very clearly when watching the make output. #device pci 1e.2 off end # AC'97 Audio It means that AC'97 Audio is on Bus#=1 and Function#=2? I don't know about the bus number because you took the above line out of context, but device 0x1e function 2 yes. But all the devices of the south bridge, ICH7 are on Bus number 0, as far as I know. Why you have not written, Bus number, Function number, Device number, Register number clearly. Because it is not a list of registers. Device and function is there and bus is implicit, but the file encodes more complex knowledge about the board than simply a list of register/value pairs. device pci 1d.0 on end, What does it mean, 1d.0? Device 0x1d function 0. I would hope that this is obvious with a little knowledge about the respective chipset. If you have the lspci next to you I think that devicetree.cb is rather clear. The bus number is implicit because the file is structured rather than a simple list. The indentation and the end keywords try to make this obvious. Again, please say how you think the information can be structured in a better way. //Peter -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] sb800 code derived from sb700 implementation
She, Kerry wrote: I have made a little bit cleanup from the patches originally made by Bao Zheng, This sb800 code is derived from sb700 implementation. Release this patch is NOT to confusing people, but make other patches based on this implementation also works. So this patch don’t need to be checked into the tree. Thanks! I think this is a nice addition. Maybe we should add a Kconfig option to choose between cimx and non-cimx? //Peter -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Test SeaBIOS AHCI support
Hi Alec, Neo The User wrote: I have attached the somewhat working port as a patch (ma785gm-us2h.patch) Cool! I hope the patch format is correct! Well, I'd say no. It is impossible to review this patch because it duplicates (nearly) all code for another board. It would be very good if you could start with a patch that is simply a diff from the ma785gmt board. Finally, when copying files later, into the new ma785gm directory, please make sure to use svn to do copies, so that patches become much smaller, or at the very least that the history is kept. But please first start with a diff against an existing board. If the differences are small enough maybe the same code can handle both boards. //Peter -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Test SeaBIOS AHCI support
Hello! New patch :) Sorry about that, I have little to no experience with subversion. Also I found out that the rebooting loop wasn't caused by the AHCI SATA being off, but rather the console level for serial output was below 7 in the coreboot config file... I found it very strange. Anyway, the real result of having AHCI SATA off in SeaBIOS causes the payload to just hang, before it says to press F12. With it on, I can access GRUB but I get kernel panics in any Linux distro. NetBSD also fails. I attached a new patch, using svn copy and such from Tilapia, keeping almost everything the same in the diff. After creating the diff, I poked around a bit more, but I couldn't solve the kernel panics. This isn't really a big concern for me personally but I thought it would be cool to have a board with over 1,100 reviews on newegg that would be supported by Coreboot. Might spark some attention as well. -Alec --- On Tue, 1/4/11, Peter Stuge pe...@stuge.se wrote: From: Peter Stuge pe...@stuge.se Subject: Re: [coreboot] Test SeaBIOS AHCI support To: coreboot@coreboot.org Date: Tuesday, January 4, 2011, 11:45 AM Hi Alec, Neo The User wrote: I have attached the somewhat working port as a patch (ma785gm-us2h.patch) Cool! I hope the patch format is correct! Well, I'd say no. It is impossible to review this patch because it duplicates (nearly) all code for another board. It would be very good if you could start with a patch that is simply a diff from the ma785gmt board. Finally, when copying files later, into the new ma785gm directory, please make sure to use svn to do copies, so that patches become much smaller, or at the very least that the history is kept. But please first start with a diff against an existing board. If the differences are small enough maybe the same code can handle both boards. //Peter -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot ma785gm-us2h.diff Description: Binary data -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH 1/2] Geode GX2 cleanup again
On Fri, Dec 31, 2010 at 07:57:34AM +0100, Stefan Reinauer wrote:
On 12/30/10 10:48 PM, Nils wrote:
- {0x,{0x, 0x}},
+ {0x,{0x, 0x}},
I don't think we should capitalize hexadecimal numbers. We never did (on
purpose) anywhere else.
Bikeshed, anyone?
Yup, I also prefer non-capitalized, but that's probably a matter of
taste. I'm relatively sure the majority of our code-base uses lower-case
right now.
Uwe.
--
http://hermann-uwe.de | http://sigrok.org
http://randomprojects.org | http://unmaintained-free-software.org
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] [commit] r6240 - trunk/src/southbridge/nvidia/ck804
Author: uwe
Date: Tue Jan 4 18:36:55 2011
New Revision: 6240
URL: https://tracker.coreboot.org/trac/coreboot/changeset/6240
Log:
CK804: Cosmetic fixes, switch to u8 et al.
Signed-off-by: Uwe Hermann u...@hermann-uwe.de
Acked-by: Uwe Hermann u...@hermann-uwe.de
Modified:
trunk/src/southbridge/nvidia/ck804/Kconfig
trunk/src/southbridge/nvidia/ck804/chip.h
trunk/src/southbridge/nvidia/ck804/ck804.c
trunk/src/southbridge/nvidia/ck804/ck804.h
trunk/src/southbridge/nvidia/ck804/early_setup.c
trunk/src/southbridge/nvidia/ck804/early_setup_car.c
trunk/src/southbridge/nvidia/ck804/early_smbus.c
trunk/src/southbridge/nvidia/ck804/ide.c
trunk/src/southbridge/nvidia/ck804/lpc.c
trunk/src/southbridge/nvidia/ck804/nic.c
trunk/src/southbridge/nvidia/ck804/pci.c
trunk/src/southbridge/nvidia/ck804/pcie.c
trunk/src/southbridge/nvidia/ck804/sata.c
trunk/src/southbridge/nvidia/ck804/smbus.c
trunk/src/southbridge/nvidia/ck804/smbus.h
trunk/src/southbridge/nvidia/ck804/usb.c
trunk/src/southbridge/nvidia/ck804/usb2.c
Modified: trunk/src/southbridge/nvidia/ck804/Kconfig
==
--- trunk/src/southbridge/nvidia/ck804/Kconfig Tue Jan 4 07:39:29 2011
(r6239)
+++ trunk/src/southbridge/nvidia/ck804/Kconfig Tue Jan 4 18:36:55 2011
(r6240)
@@ -8,7 +8,7 @@
if SOUTHBRIDGE_NVIDIA_CK804
config BOOTBLOCK_SOUTHBRIDGE_INIT
- string
+ string
default southbridge/nvidia/ck804/bootblock.c
config ID_SECTION_OFFSET
Modified: trunk/src/southbridge/nvidia/ck804/chip.h
==
--- trunk/src/southbridge/nvidia/ck804/chip.h Tue Jan 4 07:39:29 2011
(r6239)
+++ trunk/src/southbridge/nvidia/ck804/chip.h Tue Jan 4 18:36:55 2011
(r6240)
@@ -18,8 +18,8 @@
* Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
*/
-#ifndef CK804_CHIP_H
-#define CK804_CHIP_H
+#ifndef SOUTHBRIDGE_NVIDIA_CK804_CHIP_H
+#define SOUTHBRIDGE_NVIDIA_CK804_CHIP_H
struct southbridge_nvidia_ck804_config {
unsigned int usb1_hc_reset : 1;
Modified: trunk/src/southbridge/nvidia/ck804/ck804.c
==
--- trunk/src/southbridge/nvidia/ck804/ck804.c Tue Jan 4 07:39:29 2011
(r6239)
+++ trunk/src/southbridge/nvidia/ck804/ck804.c Tue Jan 4 18:36:55 2011
(r6240)
@@ -26,7 +26,7 @@
#include device/pci_ops.h
#include ck804.h
-static uint32_t final_reg;
+static u32 final_reg;
static device_t find_lpc_dev(device_t dev, unsigned devfn)
{
@@ -41,7 +41,7 @@
(lpc_dev-device != PCI_DEVICE_ID_NVIDIA_CK804_PRO)
(lpc_dev-device != PCI_DEVICE_ID_NVIDIA_CK804_SLAVE)))
{
- uint32_t id;
+ u32 id;
id = pci_read_config32(lpc_dev, PCI_VENDOR_ID);
if ((id != (PCI_VENDOR_ID_NVIDIA |
(PCI_DEVICE_ID_NVIDIA_CK804_LPC 16)))
@@ -61,8 +61,8 @@
{
device_t lpc_dev;
unsigned index = 0, index2 = 0, deviceid, vendorid, devfn;
- uint32_t reg_old, reg;
- uint8_t byte;
+ u32 reg_old, reg;
+ u8 byte;
struct southbridge_nvidia_ck804_config *conf;
conf = dev-chip_info;
Modified: trunk/src/southbridge/nvidia/ck804/ck804.h
==
--- trunk/src/southbridge/nvidia/ck804/ck804.h Tue Jan 4 07:39:29 2011
(r6239)
+++ trunk/src/southbridge/nvidia/ck804/ck804.h Tue Jan 4 18:36:55 2011
(r6240)
@@ -18,8 +18,8 @@
* Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
*/
-#ifndef CK804_H
-#define CK804_H
+#ifndef SOUTHBRIDGE_NVIDIA_CK804_CK804_H
+#define SOUTHBRIDGE_NVIDIA_CK804_CK804_H
#include chip.h
Modified: trunk/src/southbridge/nvidia/ck804/early_setup.c
==
--- trunk/src/southbridge/nvidia/ck804/early_setup.cTue Jan 4 07:39:29
2011(r6239)
+++ trunk/src/southbridge/nvidia/ck804/early_setup.cTue Jan 4 18:36:55
2011(r6240)
@@ -20,7 +20,7 @@
#include reset.h
-static int set_ht_link_ck804(uint8_t ht_c_num)
+static int set_ht_link_ck804(u8 ht_c_num)
{
unsigned vendorid = 0x10de;
unsigned val = 0x01610169;
@@ -91,7 +91,7 @@
static void ck804_early_set_port(void)
{
static const unsigned int ctrl_devport_conf[] = {
- PCI_ADDR(0, (CK804_DEVN_BASE+0x1), 0, ANACTRL_REG_POS),
~(0xff00), ANACTRL_IO_BASE,
+ PCI_ADDR(0, (CK804_DEVN_BASE + 0x1), 0, ANACTRL_REG_POS),
~(0xff00), ANACTRL_IO_BASE,
#if CONFIG_CK804_NUM 1
PCI_ADDR(CK804B_BUSN, (CK804B_DEVN_BASE+0x1), 0,
ANACTRL_REG_POS), ~(0xff00), CK804B_ANACTRL_IO_BASE,
#endif
@@ -229,7 +229,7 @@
RES_PCI_IO,
Re: [coreboot] IDE interface support code for AMDLX800-CS5536
On Sat, Jan 1, 2011 at 1:38 PM, Darmawan Salihun darmawan.sali...@gmail.com wrote: On 1/2/11, Darmawan Salihun darmawan.sali...@gmail.com wrote: Hi guys, I'm looking for the support code for the IDE controller in CS5536 southbridge. I checked-out Coreboot source code but only saw Flash interface support in there. I saw the IDE controller is switched to Flash interface support with the DEADBEEF magic number. The board I'm working with right now use the primary IDE channel for both HDD connectors and a CF connectors. I need to know how to initialize the chipset correctly for this setup. The CF connector is the primary master and the HDD connector is primary slave. I've checked with lspci and cat /proc/ioports and I found that the legacy I/O ports for IDE controller is working just fine. Also, the I/O ports for IDE bus mastering (SFF-8038i) registers are allocated correctly. I mean with the current code that I tested the I/O ports allocation is just fine. Thanks, Darmawan Hi Darmawan, The IDE should get setup by default if the flash switch path is not selected. I assume you have already read the registers in the databook.. http://support.amd.com/us/Embedded_TechDocs/33238G_cs5536_db.pdf There may be more information on the embedded developer site. The embedded guys are coreboot friendly, so they should be able to point at the appropriate doc. http://wwwd.amd.com/amd/devsite.nsf/home/welcome.htm?opendocumentlogin Marc -- http://se-eng.com -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] [commit] r6241 - trunk/src/southbridge/nvidia/mcp55
Author: uwe
Date: Tue Jan 4 20:51:33 2011
New Revision: 6241
URL: https://tracker.coreboot.org/trac/coreboot/changeset/6241
Log:
MCP55: Cosmetic fixes, switch to u8 et al.
Signed-off-by: Uwe Hermann u...@hermann-uwe.de
Acked-by: Uwe Hermann u...@hermann-uwe.de
Modified:
trunk/src/southbridge/nvidia/mcp55/azalia.c
trunk/src/southbridge/nvidia/mcp55/bootblock.c
trunk/src/southbridge/nvidia/mcp55/chip.h
trunk/src/southbridge/nvidia/mcp55/early_ctrl.c
trunk/src/southbridge/nvidia/mcp55/early_setup_car.c
trunk/src/southbridge/nvidia/mcp55/early_setup_ss.h
trunk/src/southbridge/nvidia/mcp55/early_smbus.c
trunk/src/southbridge/nvidia/mcp55/ht.c
trunk/src/southbridge/nvidia/mcp55/ide.c
trunk/src/southbridge/nvidia/mcp55/lpc.c
trunk/src/southbridge/nvidia/mcp55/mcp55.c
trunk/src/southbridge/nvidia/mcp55/mcp55.h
trunk/src/southbridge/nvidia/mcp55/nic.c
trunk/src/southbridge/nvidia/mcp55/pci.c
trunk/src/southbridge/nvidia/mcp55/pcie.c
trunk/src/southbridge/nvidia/mcp55/sata.c
trunk/src/southbridge/nvidia/mcp55/smbus.c
trunk/src/southbridge/nvidia/mcp55/usb2.c
Modified: trunk/src/southbridge/nvidia/mcp55/azalia.c
==
--- trunk/src/southbridge/nvidia/mcp55/azalia.c Tue Jan 4 18:36:55 2011
(r6240)
+++ trunk/src/southbridge/nvidia/mcp55/azalia.c Tue Jan 4 20:51:33 2011
(r6241)
@@ -28,33 +28,31 @@
#include mcp55.h
#define HDA_ICII_REG 0x68
-#define HDA_ICII_BUSY (1 0)
-#define HDA_ICII_VALID (1 1)
+#define HDA_ICII_BUSY (1 0)
+#define HDA_ICII_VALID (1 1)
static int set_bits(u32 port, u32 mask, u32 val)
{
u32 reg32;
int count;
- /* Write (val mask) to port */
+ /* Write (val mask) to port. */
val = mask;
reg32 = read32(port);
reg32 = ~mask;
reg32 |= val;
write32(port, reg32);
- /* Wait for readback of register to
-* match what was just written to it
-*/
+ /* Wait for readback of register to match what was written to it. */
count = 50;
do {
- /* Wait 1ms based on BKDG wait time */
+ /* Wait 1ms based on BKDG wait time. */
mdelay(1);
reg32 = read32(port);
reg32 = mask;
} while ((reg32 != val) --count);
- /* Timeout occurred */
+ /* Timeout occurred. */
if (!count)
return -1;
return 0;
@@ -64,15 +62,15 @@
{
u32 reg32;
- /* Set Bit0 to 0 to enter reset state (BAR + 0x8)[0] */
+ /* Set bit 0 to 0 to enter reset state (BAR + 0x8)[0]. */
if (set_bits(base + 0x08, 1, 0) == -1)
goto no_codec;
- /* Set Bit 0 to 1 to exit reset state (BAR + 0x8)[0] */
+ /* Set bit 0 to 1 to exit reset state (BAR + 0x8)[0]. */
if (set_bits(base + 0x08, 1, 1) == -1)
goto no_codec;
- /* Read in Codec location (BAR + 0xe)[2..0]*/
+ /* Read in codec location (BAR + 0xe)[2..0]. */
reg32 = read32(base + 0xe);
reg32 = 0x0f;
if (!reg32)
@@ -81,48 +79,45 @@
return reg32;
no_codec:
- /* Codec Not found */
- /* Put HDA back in reset (BAR + 0x8) [0] */
+ /* Codec not found. */
+ /* Put HDA back in reset (BAR + 0x8)[0]. */
set_bits(base + 0x08, 1, 0);
printk(BIOS_DEBUG, Azalia: No codec!\n);
return 0;
}
-u32 * cim_verb_data = NULL;
+u32 *cim_verb_data = NULL;
u32 cim_verb_data_size = 0;
-static u32 find_verb(struct device *dev, u32 viddid, u32 ** verb)
+static u32 find_verb(struct device *dev, u32 viddid, u32 **verb)
{
- int idx=0;
+ int idx = 0;
while (idx (cim_verb_data_size / sizeof(u32))) {
- u32 verb_size = 4 * cim_verb_data[idx+2]; // in u32
+ u32 verb_size = 4 * cim_verb_data[idx + 2]; /* in u32 */
if (cim_verb_data[idx] != viddid) {
- idx += verb_size + 3; // skip verb + header
+ idx += verb_size + 3; /* Skip verb + header. */
continue;
}
- *verb = cim_verb_data[idx+3];
+ *verb = cim_verb_data[idx + 3];
return verb_size;
}
- /* Not all codecs need to load another verb */
+ /* Not all codecs need to load another verb. */
return 0;
}
/**
- * Wait 50usec for the codec to indicate it is ready
- * no response would imply that the codec is non-operative
+ * Wait 50usec for the codec to indicate it is ready.
+ * No response would imply that the codec is non-operative.
*/
-
static int wait_for_ready(u32 base)
{
- /* Use a 50 usec timeout - the Linux kernel uses the
-* same duration */
-
+ /* Use a 50 usec timeout - the Linux kernel uses the same duration. */
int timeout = 50;
- while(timeout--) {
Re: [coreboot] Support for Google CR-48/Atom N455
Thanks Crisit for getting back to me. I have indeed flashed it with flashrom in Ubuntu. I will see what I can do about details of the northbridge. On Mon, Jan 3, 2011 at 12:07 PM, Cristi Magherusan cristi.magheru...@net.utcluj.ro wrote: În Dum, Ianuarie 2, 2011 4:31, Brandon White a scris: Hello all. Someone was accidentally sent a CR-48 that had Windows 7 pre-installed and an actual BIOS instead of Google's EFI. Anways, he uploaded the BIOS, I was able to flash it and after that I installed Ubuntu as a dual boot with Chrome OS. I was wondering if Coreboot was possible on this machine? I have attached everything asked for in the wiki. Thanks, Brandon -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot Hello, Flashrom seems to support your flash, but writes weren't tested/confirmed to work yet on the flashrom wiki. Did you flash it using Frashrom? The ICH7 southbridge is supported, no idea about the northbridge, you might need doc from Intel, which is hard to get unless you have an NDA. If you are lucky, the SMSC SCH5317 SuperIO might be easy to support, by porting the code for SCH5307 which is already supported. I have no clue about the other superIO chip or what could it be used for. maybe we don't need it at all for system init. Also, thew board might have an Embedded Controller, which might make things even harder. Good luck! Cristi -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] IDE interface support code for AMDLX800-CS5536
Hi Mark, On 1/5/11, Marc Jones marcj...@gmail.com wrote: On Sat, Jan 1, 2011 at 1:38 PM, Darmawan Salihun darmawan.sali...@gmail.com wrote: On 1/2/11, Darmawan Salihun darmawan.sali...@gmail.com wrote: Hi guys, I'm looking for the support code for the IDE controller in CS5536 southbridge. I checked-out Coreboot source code but only saw Flash interface support in there. I saw the IDE controller is switched to Flash interface support with the DEADBEEF magic number. The board I'm working with right now use the primary IDE channel for both HDD connectors and a CF connectors. I need to know how to initialize the chipset correctly for this setup. The CF connector is the primary master and the HDD connector is primary slave. I've checked with lspci and cat /proc/ioports and I found that the legacy I/O ports for IDE controller is working just fine. Also, the I/O ports for IDE bus mastering (SFF-8038i) registers are allocated correctly. I mean with the current code that I tested the I/O ports allocation is just fine. Thanks, Darmawan Hi Darmawan, The IDE should get setup by default if the flash switch path is not selected. I assume you have already read the registers in the databook.. http://support.amd.com/us/Embedded_TechDocs/33238G_cs5536_db.pdf Yes, I've been reading it several times over ;-). I have pin point the problem to be in setting the appropriate ATA mode for the attached drives. The motherboard I'm working with has a CF interface in the primary master. While the primary slave is a 44-pin IDE connector (currently connected to an 80GB HDD). I booted FreeBSD 8.0 installation disk in full debug (via USB DVD), but it failed when it tried to set the drive controller mode via SET FEATURE (ATA command). This renders the CF _and_ the HDD unusable. I also booted to backtrack 3 i386 Linux, but it also failed even earlier (via USB DVD), when it tried to check for drive presence via IDENTIFY (ATA command). I'm confused as to: What are the acceptable values for the IDE_DTC, IDE_CAST and IDE_ETC registers? I mean values which would enable the OS to use mass storage device(s) on the IDE primary channel. There may be more information on the embedded developer site. The embedded guys are coreboot friendly, so they should be able to point at the appropriate doc. http://wwwd.amd.com/amd/devsite.nsf/home/welcome.htm?opendocumentlogin I see. On to the site. Thanks, Darmawan -- -= Human knowledge belongs to the world =- -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] sb800 code derived from sb700 implementation
* Peter Stuge pe...@stuge.se [110104 12:21]: She, Kerry wrote: Thanks! I think this is a nice addition. Maybe we should add a Kconfig option to choose between cimx and non-cimx? I think we should, once we actually hit a use case. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] sb800 code derived from sb700 implementation
Stefan Reinauer wrote: Maybe we should add a Kconfig option to choose between cimx and non-cimx? I think we should, once we actually hit a use case. Um? This is the case right here. I say add it now and get the patch commited, then can remove in future if not used. //Peter -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] sb800 code derived from sb700 implementation
* Peter Stuge pe...@stuge.se [110104 22:18]: Stefan Reinauer wrote: Maybe we should add a Kconfig option to choose between cimx and non-cimx? I think we should, once we actually hit a use case. Um? This is the case right here. Oh? Which board? I thought the patch said for reference only, not for checkin. Sorry if I missed something. Stefan -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] sb800 code derived from sb700 implementation
Auf 04.01.2011 22:21, Stefan Reinauer schrieb: * Peter Stuge pe...@stuge.se [110104 22:18]: Stefan Reinauer wrote: Maybe we should add a Kconfig option to choose between cimx and non-cimx? I think we should, once we actually hit a use case. Um? This is the case right here. Oh? Which board? I thought the patch said for reference only, not for checkin. Sorry if I missed something. Still, having the code checked in is IMHO better than having it on the list. If there are any CIMx integration issues later, we still have the alternative code (and as a nice benefit, we can actually touch that code whereas CIMx should be kept unchanged to allow easier updates). Regards, Carl-Daniel -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] sb800 code derived from sb700 implementation
* Carl-Daniel Hailfinger c-d.hailfinger.devel.2...@gmx.net [110105 00:05]: Still, having the code checked in is IMHO better than having it on the list. If there are any CIMx integration issues later, we still have the alternative code (and as a nice benefit, we can actually touch that code whereas CIMx should be kept unchanged to allow easier updates). I would prefer to see CIMx integration issues fixed rather than worked around with an in-tree fork for a non-existant user base that might experience problems in the unforseeable future. There is nothing that prevents us from reporting issues with the CIMx code back to AMD to have it fixed. Stefan -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] [commit] r6242 - trunk
Author: stepan Date: Wed Jan 5 02:37:48 2011 New Revision: 6242 URL: https://tracker.coreboot.org/trac/coreboot/changeset/6242 Log: fix make clean Signed-off-by: Stefan Reinauer ste...@coreboot.org Acked-by: Stefan Reinauer ste...@coreboot.org Modified: trunk/Makefile Modified: trunk/Makefile == --- trunk/Makefile Tue Jan 4 20:51:33 2011(r6241) +++ trunk/Makefile Wed Jan 5 02:37:48 2011(r6242) @@ -364,7 +364,7 @@ rm -f $(obj)/mainboard/$(MAINBOARDDIR)/bootblock.* $(obj)/mainboard/$(MAINBOARDDIR)/dsdt.* rm -f $(obj)/cpu/x86/smm/smm_bin.c $(obj)/cpu/x86/smm/smm.* $(obj)/cpu/x86/smm/smm rmdir -p $(alldirs) 2/dev/null /dev/null || true - $(MAKE) -C payloads/external/SeaBIOS clean + $(MAKE) -C payloads/external/SeaBIOS -f Makefile.inc clean clean: clean-for-update rm -f $(obj)/coreboot* .ccwrap -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] [commit] r6243 - trunk/util/kconfig
Author: stepan Date: Wed Jan 5 03:10:50 2011 New Revision: 6243 URL: https://tracker.coreboot.org/trac/coreboot/changeset/6243 Log: fix compilation of mconf on some systems. Signed-off-by: Stefan Reinauer ste...@coreboot.org Acked-by: Stefan Reinauer ste...@coreboot.org Modified: trunk/util/kconfig/Makefile Modified: trunk/util/kconfig/Makefile == --- trunk/util/kconfig/Makefile Wed Jan 5 02:37:48 2011(r6242) +++ trunk/util/kconfig/Makefile Wed Jan 5 03:10:50 2011(r6243) @@ -304,7 +304,7 @@ $(objk)/gconf: $(patsubst %,$(objk)/%,$(gconf-objs)) $(HOSTCC) $(HOSTCFLAGS) $(HOSTLOADLIBES_gconf) -o $@ $^ $(objk)/mconf: $(patsubst %,$(objk)/%,$(mconf-objs)) - $(HOSTCC) $(HOSTCFLAGS) $(HOST_EXTRACFLAGS) $(HOST_LOADLIBES) -o $@ $^ + $(HOSTCC) $(HOSTCFLAGS) $(HOST_EXTRACFLAGS) $^ $(HOST_LOADLIBES) -o $@ $(objk)/conf: $(patsubst %,$(objk)/%,$(conf-objs)) $(HOSTCC) $(HOSTCFLAGS) $(HOST_EXTRACFLAGS) -o $@ $^ -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] [commit] r6244 - in trunk/src: . arch/x86 console
Author: stepan Date: Wed Jan 5 03:27:53 2011 New Revision: 6244 URL: https://tracker.coreboot.org/trac/coreboot/changeset/6244 Log: move single options out of main menu and remove stray options Signed-off-by: Stefan Reinauer ste...@coreboot.org Acked-by: Stefan Reinauer ste...@coreboot.org Modified: trunk/src/Kconfig.deprecated_options trunk/src/arch/x86/Kconfig trunk/src/console/Kconfig Modified: trunk/src/Kconfig.deprecated_options == --- trunk/src/Kconfig.deprecated_optionsWed Jan 5 03:10:50 2011 (r6243) +++ trunk/src/Kconfig.deprecated_optionsWed Jan 5 03:27:53 2011 (r6244) @@ -2,6 +2,8 @@ # if possible, and if you find the time, or touch the general area # for other purposes, please consider removing their uses. +menu Deprecated + # It might be possible to consolidate hard_reset() to southbridges, # given that it (usually) uses its registers. # The long term goal would be to eliminate hard_reset() from boards. @@ -49,3 +51,4 @@ this option, then you can say N here to speed up boot time. Otherwise say Y. +endmenu Modified: trunk/src/arch/x86/Kconfig == --- trunk/src/arch/x86/Kconfig Wed Jan 5 03:10:50 2011(r6243) +++ trunk/src/arch/x86/Kconfig Wed Jan 5 03:27:53 2011(r6244) @@ -1,3 +1,5 @@ +menu Architecture (x86) + # This is an SMP option. It relates to starting up APs. # It is usually set in mainboard/*/Kconfig. # TODO: Improve description. @@ -91,3 +93,5 @@ config BOOTBLOCK_SOUTHBRIDGE_INIT string + +endmenu Modified: trunk/src/console/Kconfig == --- trunk/src/console/Kconfig Wed Jan 5 03:10:50 2011(r6243) +++ trunk/src/console/Kconfig Wed Jan 5 03:27:53 2011(r6244) @@ -1,4 +1,4 @@ -menu Console options +menu Console # TODO: Rename to SERIAL_CONSOLE once Kconfig transition is complete. config CONSOLE_SERIAL8250 bool Serial port console output -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] [commit] r6245 - trunk/src/lib
Author: stepan
Date: Wed Jan 5 03:40:53 2011
New Revision: 6245
URL: https://tracker.coreboot.org/trac/coreboot/changeset/6245
Log:
uart_init is only used in romstage.
Signed-off-by: Stefan Reinauer ste...@coreboot.org
Acked-by: Stefan Reinauer ste...@coreboot.org
Modified:
trunk/src/lib/uart8250.c
Modified: trunk/src/lib/uart8250.c
==
--- trunk/src/lib/uart8250.cWed Jan 5 03:27:53 2011(r6244)
+++ trunk/src/lib/uart8250.cWed Jan 5 03:40:53 2011(r6245)
@@ -103,6 +103,7 @@
}
#endif
+#ifdef __PRE_RAM__
void uart_init(void)
{
#if CONFIG_USE_OPTION_TABLE
@@ -117,4 +118,4 @@
uart8250_init(CONFIG_TTYS0_BASE, CONFIG_TTYS0_DIV);
#endif
}
-
+#endif
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] one super i/o
I am looking for the data sheet and programming reference manual of a super I/O chip by ITE, IT8703F. I will be much appreciated if anybody can email it for me. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] one super i/o
On Tue, Jan 4, 2011 at 10:43 PM, ali hagigat hagigat...@gmail.com wrote: I am looking for the data sheet and programming reference manual of a super I/O chip by ITE, IT8703F. I will be much appreciated if anybody can email it for me. Looks like google can't find it, you're going to have to contact ITE http://www.ite.com.tw/EN/company.aspx -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] one super i/o
You can run superiotool to find out the logical device number (LDN) of each device. That is the way if we don't have the datasheet. Zheng -Original Message- From: coreboot-boun...@coreboot.org [mailto:coreboot-boun...@coreboot.org] On Behalf Of ali hagigat Sent: Wednesday, January 05, 2011 11:44 AM To: coreboot@coreboot.org Subject: [coreboot] one super i/o I am looking for the data sheet and programming reference manual of a super I/O chip by ITE, IT8703F. I will be much appreciated if anybody can email it for me. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] Support for Asus M2N-SLI Deluxe
Hi, Answering the following questions from the FAQ, I have the following: Board Vendor: Asus Board Product Name: M2N-SLI Deluxe CPU Model: AMD Athlon 64FX, Socket AM2 Northbridge: Nvidia nForce 570 SLI Southbridge: Nvidia MCP55 Link to specifications: http://www.asus.com.au/product.aspx?P_ID=szSFtrap7crpBaQE Attached are the outputs of lspci, superiotool and flashrom. I noticed that a similar board (Asus M2N-E) is supported. I was hoping that porting to this board would not require major rework. Regards, Michael Cassaniti flashrom v0.9.3-r1205 on Linux 2.6.34-gentoo-r12 (x86_64), built with libpci 3.1.4, GCC 4.3.4, little endian flashrom is free software, get the source code at http://www.flashrom.org Calibrating delay loop... OS timer resolution is 1 usecs, 1156M loops per second, 10 myus = 11 us, 100 myus = 97 us, 1000 myus = 1082 us, 1 myus = 10023 us, 4 myus = 5 us, OK. Initializing internal programmer No coreboot table found. sh: dmidecode: command not found dmidecode execution unsucessfull - continuing without DMI info Found ITE Super I/O, ID 0x8716. Found chipset NVIDIA MCP55, enabling flash write... chipset PCI ID is 10de:0360, OK. This chipset supports the following protocols: Non-SPI. No IT87* serial flash segment enabled. Probing for AMD Am29F010A/B, 128 KB: probe_jedec_common: id1 0x00, id2 0xff, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for AMD Am29F002(N)BB, 256 KB: probe_jedec_common: id1 0x37, id2 0x82, id1 is normal flash content, id2 is normal flash content Probing for AMD Am29F002(N)BT, 256 KB: probe_jedec_common: id1 0x37, id2 0x82, id1 is normal flash content, id2 is normal flash content Probing for AMD Am29F016D, 2048 KB: Chip lacks correct probe timing information, using default 10mS/40uS. probe_jedec_common: id1 0xff, id2 0xff, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for AMD Am29F040B, 512 KB: Chip lacks correct probe timing information, using default 10mS/40uS. probe_jedec_common: id1 0x21, id2 0x7e, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for AMD Am29F080B, 1024 KB: probe_jedec_common: id1 0xff, id2 0xff, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for AMD Am29LV040B, 512 KB: Chip lacks correct probe timing information, using default 10mS/40uS. probe_jedec_common: id1 0x21, id2 0x7e, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for AMD Am29LV081B, 1024 KB: Chip lacks correct probe timing information, using default 10mS/40uS. probe_jedec_common: id1 0xff, id2 0xff, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for AMIC A25L05PT, 64 KB: skipped. Probing for AMIC A25L05PU, 64 KB: skipped. Probing for AMIC A25L10PT, 128 KB: skipped. Probing for AMIC A25L10PU, 128 KB: skipped. Probing for AMIC A25L20PT, 256 KB: skipped. Probing for AMIC A25L20PU, 256 KB: skipped. Probing for AMIC A25L40PT, 512 KB: skipped. Probing for AMIC A25L40PU, 512 KB: skipped. Probing for AMIC A25L80P, 1024 KB: skipped. Probing for AMIC A25L16PT, 2048 KB: skipped. Probing for AMIC A25L16PU, 2048 KB: skipped. Probing for AMIC A25L512, 64 KB: skipped. Probing for AMIC A25L010, 128 KB: skipped. Probing for AMIC A25L020, 256 KB: skipped. Probing for AMIC A25L040, 512 KB: skipped. Probing for AMIC A25L080, 1024 KB: skipped. Probing for AMIC A25L016, 2048 KB: skipped. Probing for AMIC A25L032, 4096 KB: skipped. Probing for AMIC A25LQ032, 4096 KB: skipped. Probing for AMIC A29002B, 256 KB: Chip lacks correct probe timing information, using default 10mS/40uS. probe_jedec_common: id1 0x37, id2 0x82, id1 is normal flash content, id2 is normal flash content Probing for AMIC A29002T, 256 KB: Chip lacks correct probe timing information, using default 10mS/40uS. probe_jedec_common: id1 0x37, id2 0x82, id1 is normal flash content, id2 is normal flash content Probing for AMIC A29040B, 512 KB: Chip lacks correct probe timing information, using default 10mS/40uS. probe_jedec_common: id1 0x21, id2 0x7e, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for AMIC A49LF040A, 512 KB: probe_jedec_common: id1 0x9d, id2 0x6e Probing for Atmel AT25DF021, 256 KB: skipped. Probing for Atmel AT25DF041A, 512 KB: skipped. Probing for Atmel AT25DF081, 1024 KB: skipped. Probing for Atmel AT25DF081A, 1024 KB: skipped. Probing for Atmel AT25DF161, 2048 KB: skipped. Probing for Atmel AT25DF321, 4096 KB: skipped. Probing for Atmel AT25DF321A, 4096 KB: skipped. Probing for Atmel AT25DF641, 8192 KB: skipped. Probing for Atmel AT25DQ161, 2048 KB: skipped. Probing for Atmel AT25F512B, 64 KB: skipped. Probing for Atmel AT25FS010, 128 KB: skipped. Probing for Atmel AT25FS040, 512 KB: skipped. Probing for Atmel AT26DF041, 512 KB: skipped. Probing for Atmel AT26DF081A, 1024 KB: skipped. Probing for Atmel AT26DF161, 2048 KB:
