[coreboot] [PATCH]: Entry key of fintek superio is 8787 instead of 87
According to the description in datasheet of f71889,
To enable configuration, the entry key 0x87 must be written to
the index port
-o 4e 87
-o 4e 87 (enable configuration)
-o 4e aa (disable configuration)
This piece of text appears in most of the datasheet of fintek superio.
It doesnt say it quite clear, but it seems that the 0x87 should
be written twice. I tried on f81865, which is not in the coreboot tree
yet. If the 0x87 is only written once, you can only R/W the index/data
port once. All the subsequent RW will fail. Writing twice will be ok.
Plus, in the superiotool, the function
enter_conf_mode_winbond_fintek_ite_8787
also write 8787.
The fintek superio chips seem to enable the UART automatically when the
power is on. So I didnt find it failed to access.
Signed-off-by: Zheng Bao zheng@amd.com
Index: src/superio/fintek/f71805f/f71805f_early_serial.c
===
--- src/superio/fintek/f71805f/f71805f_early_serial.c (revision 6024)
+++ src/superio/fintek/f71805f/f71805f_early_serial.c (working copy)
@@ -27,6 +27,7 @@
{
u16 port = dev 8;
outb(0x87, port);
+ outb(0x87, port);
}
static void pnp_exit_conf_state(device_t dev)
Index: src/superio/fintek/f71859/f71859_early_serial.c
===
--- src/superio/fintek/f71859/f71859_early_serial.c (revision 6024)
+++ src/superio/fintek/f71859/f71859_early_serial.c (working copy)
@@ -27,6 +27,7 @@
{
u16 port = dev 8;
outb(0x87, port);
+ outb(0x87, port);
}
static void pnp_exit_conf_state(device_t dev)
Index: src/superio/fintek/f71889/f71889_early_serial.c
===
--- src/superio/fintek/f71889/f71889_early_serial.c (revision 6024)
+++ src/superio/fintek/f71889/f71889_early_serial.c (working copy)
@@ -26,6 +26,7 @@
{
u16 port = dev 8;
outb(0x87, port);
+ outb(0x87, port);
}
static void pnp_exit_conf_state(device_t dev)
Index: src/superio/fintek/f71863fg/f71863fg_early_serial.c
===
--- src/superio/fintek/f71863fg/f71863fg_early_serial.c (revision 6024)
+++ src/superio/fintek/f71863fg/f71863fg_early_serial.c (working copy)
@@ -27,6 +27,7 @@
{
u16 port = dev 8;
outb(0x87, port);
+ outb(0x87, port);
}
static void pnp_exit_conf_state(device_t dev)
superio_fintek_pnp_8787.patch
Description: superio_fintek_pnp_8787.patch
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH]: Entry key of fintek superio is 8787 instead of 87
On 11/5/10 12:19 AM, Bao, Zheng wrote: According to the description in datasheet of f71889, To enable configuration, the entry key 0x87 must be written to the index port -o 4e 87 -o 4e 87 (enable configuration) -o 4e aa (disable configuration) This piece of text appears in most of the datasheet of fintek superio. It doesnt say it quite clear, but it seems that the 0x87 should be written twice. I tried on f81865, which is not in the coreboot tree yet. If the 0x87 is only written once, you can only R/W the index/data port once. All the subsequent RW will fail. Writing twice will be ok. Plus, in the superiotool, the function enter_conf_mode_winbond_fintek_ite_8787 also write 8787. The fintek superio chips seem to enable the UART automatically when the power is on. So I didnt find it failed to access. Signed-off-by: Zheng Bao zheng@amd.com Acked-by: Stefan Reinauer ste...@coreboot.org Stefan -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] [commit] r6025 - in trunk/src/superio/fintek: f71805f f71859 f71863fg f71889
Author: zbao
Date: Fri Nov 5 08:59:06 2010
New Revision: 6025
URL: https://tracker.coreboot.org/trac/coreboot/changeset/6025
Log:
According to the description in datasheet of f71889,
To enable configuration, the entry key 0x87 must be written to
the index port
-o 4e 87
-o 4e 87 (enable configuration)
-o 4e aa (disable configuration)
This piece of text appears in most of the datasheet of fintek superio.
It doesnt say it quite clear, but it seems that the 0x87 should
be written twice. I tried on f81865, which is not in the coreboot tree
yet. If the 0x87 is only written once, you can only R/W the index/data
port once. All the subsequent RW will fail. Writing twice will be ok.
Plus, in the superiotool, the function enter_conf_mode_winbond_fintek_ite_8787
also write 8787.
The fintek superio chips seem to enable the UART automatically when the
power is on. So I didnt find it failed to access.
Signed-off-by: Zheng Bao zheng@amd.com
Acked-by: Stefan Reinauer ste...@coresystems.de
Modified:
trunk/src/superio/fintek/f71805f/f71805f_early_serial.c
trunk/src/superio/fintek/f71859/f71859_early_serial.c
trunk/src/superio/fintek/f71863fg/f71863fg_early_serial.c
trunk/src/superio/fintek/f71889/f71889_early_serial.c
Modified: trunk/src/superio/fintek/f71805f/f71805f_early_serial.c
==
--- trunk/src/superio/fintek/f71805f/f71805f_early_serial.c Fri Nov 5
01:34:12 2010(r6024)
+++ trunk/src/superio/fintek/f71805f/f71805f_early_serial.c Fri Nov 5
08:59:06 2010(r6025)
@@ -27,6 +27,7 @@
{
u16 port = dev 8;
outb(0x87, port);
+ outb(0x87, port);
}
static void pnp_exit_conf_state(device_t dev)
Modified: trunk/src/superio/fintek/f71859/f71859_early_serial.c
==
--- trunk/src/superio/fintek/f71859/f71859_early_serial.c Fri Nov 5
01:34:12 2010(r6024)
+++ trunk/src/superio/fintek/f71859/f71859_early_serial.c Fri Nov 5
08:59:06 2010(r6025)
@@ -27,6 +27,7 @@
{
u16 port = dev 8;
outb(0x87, port);
+ outb(0x87, port);
}
static void pnp_exit_conf_state(device_t dev)
Modified: trunk/src/superio/fintek/f71863fg/f71863fg_early_serial.c
==
--- trunk/src/superio/fintek/f71863fg/f71863fg_early_serial.c Fri Nov 5
01:34:12 2010(r6024)
+++ trunk/src/superio/fintek/f71863fg/f71863fg_early_serial.c Fri Nov 5
08:59:06 2010(r6025)
@@ -27,6 +27,7 @@
{
u16 port = dev 8;
outb(0x87, port);
+ outb(0x87, port);
}
static void pnp_exit_conf_state(device_t dev)
Modified: trunk/src/superio/fintek/f71889/f71889_early_serial.c
==
--- trunk/src/superio/fintek/f71889/f71889_early_serial.c Fri Nov 5
01:34:12 2010(r6024)
+++ trunk/src/superio/fintek/f71889/f71889_early_serial.c Fri Nov 5
08:59:06 2010(r6025)
@@ -26,6 +26,7 @@
{
u16 port = dev 8;
outb(0x87, port);
+ outb(0x87, port);
}
static void pnp_exit_conf_state(device_t dev)
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] questions on coreboot bootlog w/ EP80579(Truxton platform)
Hi there, I am currently testing coreboot for the Intel EP80579 w/ the Truxton platform w/ DDR2 (not ECC) on the DIMM0 slot of the platform. I am having the following bootlog but don't understand what is the output meaning ? Thanks, Xavier. coreboot-4.0-r5689 coreboot-4.0-r5689 50AI 00 01 51AI 00 01 52AI 00 01 53AI 0080 08 08 0e 0a 00 40 00 05 3d 50 00 82 08 00 00 AI 100c 08 38 01 02 00 03 3d 50 50 60 3c 1e 3c 2d 01 AI 2025 37 10 220 01 55AI 00 01 56AI 00 01 57AI 00ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff AI 10ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff AI 20ff ff ff ff 00 00 MHz DDR Sc cd` - 25c cd` - 0201` - c cd` - DR DRB = TOM = TOLM = cl = 00 trc = 7e trfc = 00 tras = 00 trtp = 40 twtr = 00 drt0 = ffea drt1 = fc70 magic = 009a62b1 mrs = 6902 T @Q0010T @Q0020T @Q0030T @0 ``c` CS01 q0010DDR R 00T @QR 01T @QT @Q00100010T @Q0020T @Q00 T @Q00100010T @Q0020T @Q0030T @S 00:00.: 86 80 20 50 06 00 10 00 01 00 00 06 00 00 80 00 10: 00 00 00 00 00 00 00 90 00 00 00 00 00 00 00 00 20: 00 00 00 00 -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] [commit] r6026 - in trunk/src/superio/fintek: f71805f f71859 f71863fg f71889
Author: uwe
Date: Fri Nov 5 13:44:25 2010
New Revision: 6026
URL: https://tracker.coreboot.org/trac/coreboot/changeset/6026
Log:
Follow-up for r6025, do 0x87 twice in superio.c, too.
Signed-off-by: Uwe Hermann u...@hermann-uwe.de
Acked-by: Uwe Hermann u...@hermann-uwe.de
Modified:
trunk/src/superio/fintek/f71805f/superio.c
trunk/src/superio/fintek/f71859/superio.c
trunk/src/superio/fintek/f71863fg/superio.c
trunk/src/superio/fintek/f71889/superio.c
Modified: trunk/src/superio/fintek/f71805f/superio.c
==
--- trunk/src/superio/fintek/f71805f/superio.c Fri Nov 5 08:59:06 2010
(r6025)
+++ trunk/src/superio/fintek/f71805f/superio.c Fri Nov 5 13:44:25 2010
(r6026)
@@ -30,6 +30,7 @@
static void pnp_enter_conf_state(device_t dev)
{
outb(0x87, dev-path.pnp.port);
+ outb(0x87, dev-path.pnp.port);
}
static void pnp_exit_conf_state(device_t dev)
Modified: trunk/src/superio/fintek/f71859/superio.c
==
--- trunk/src/superio/fintek/f71859/superio.c Fri Nov 5 08:59:06 2010
(r6025)
+++ trunk/src/superio/fintek/f71859/superio.c Fri Nov 5 13:44:25 2010
(r6026)
@@ -31,6 +31,7 @@
static void pnp_enter_conf_state(device_t dev)
{
outb(0x87, dev-path.pnp.port);
+ outb(0x87, dev-path.pnp.port);
}
static void pnp_exit_conf_state(device_t dev)
Modified: trunk/src/superio/fintek/f71863fg/superio.c
==
--- trunk/src/superio/fintek/f71863fg/superio.c Fri Nov 5 08:59:06 2010
(r6025)
+++ trunk/src/superio/fintek/f71863fg/superio.c Fri Nov 5 13:44:25 2010
(r6026)
@@ -30,6 +30,7 @@
static void pnp_enter_conf_state(device_t dev)
{
outb(0x87, dev-path.pnp.port);
+ outb(0x87, dev-path.pnp.port);
}
static void pnp_exit_conf_state(device_t dev)
Modified: trunk/src/superio/fintek/f71889/superio.c
==
--- trunk/src/superio/fintek/f71889/superio.c Fri Nov 5 08:59:06 2010
(r6025)
+++ trunk/src/superio/fintek/f71889/superio.c Fri Nov 5 13:44:25 2010
(r6026)
@@ -30,6 +30,7 @@
static void pnp_enter_conf_state(device_t dev)
{
outb(0x87, dev-path.pnp.port);
+ outb(0x87, dev-path.pnp.port);
}
static void pnp_exit_conf_state(device_t dev)
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] [commit] r6027 - in trunk/src/mainboard: amd/dbm690t amd/mahogany amd/mahogany_fam10 amd/tilapia_fam10 asrock/939a785gmh asus/m4a785-m getac/p470 gigabyte/ga_2761gxdk gigabyte/ma785gmt giga
Author: oxygene Date: Fri Nov 5 17:17:46 2010 New Revision: 6027 URL: https://tracker.coreboot.org/trac/coreboot/changeset/6027 Log: Various PIRQ/MPTABLE/ACPI Kconfig fixes. - Use HAVE_ACPI_TABLES, HAVE_MP_TABLE, and HAVE_PIRQ_TABLE (instead of GENERATE_*) in the board's Kconfig file, as all other boards do. - Add missing HAVE_ACPI_TABLES/HAVE_MP_TABLE/HAVE_PIRQ_TABLE to boards which have the respective files. The only exception: EPIA-M700 doesn't select ACPI, as it doesn't have dsdt.asl. Added a comment that the user is supposed to run the 'get_dsdt' script and edit Kconfig afterwards. - Fix minor warning/error in src/mainboard/msi/ms9652_fam10/acpi_tables.c, now that the file is actually used. - msi/ms9652_fam10: use #include instead of Include() as we usually do now. Signed-off-by: Uwe Hermann u...@hermann-uwe.de Acked-by: Patrick Georgi patr...@georgi-clan.de Modified: trunk/src/mainboard/amd/dbm690t/Kconfig trunk/src/mainboard/amd/mahogany/Kconfig trunk/src/mainboard/amd/mahogany_fam10/Kconfig trunk/src/mainboard/amd/tilapia_fam10/Kconfig trunk/src/mainboard/asrock/939a785gmh/Kconfig trunk/src/mainboard/asus/m4a785-m/Kconfig trunk/src/mainboard/getac/p470/Kconfig trunk/src/mainboard/gigabyte/ga_2761gxdk/Kconfig trunk/src/mainboard/gigabyte/ma785gmt/Kconfig trunk/src/mainboard/gigabyte/ma78gm/Kconfig trunk/src/mainboard/ibase/mb899/Kconfig trunk/src/mainboard/iei/juki-511p/Kconfig trunk/src/mainboard/iei/kino-780am2-fam10/Kconfig trunk/src/mainboard/jetway/pa78vm5/Kconfig trunk/src/mainboard/kontron/986lcd-m/Kconfig trunk/src/mainboard/msi/ms9652_fam10/Kconfig trunk/src/mainboard/msi/ms9652_fam10/acpi_tables.c trunk/src/mainboard/msi/ms9652_fam10/dsdt.asl trunk/src/mainboard/via/epia-m700/Kconfig Modified: trunk/src/mainboard/amd/dbm690t/Kconfig == --- trunk/src/mainboard/amd/dbm690t/Kconfig Fri Nov 5 13:44:25 2010 (r6026) +++ trunk/src/mainboard/amd/dbm690t/Kconfig Fri Nov 5 17:17:46 2010 (r6027) @@ -10,9 +10,9 @@ select SOUTHBRIDGE_AMD_SB600 select SUPERIO_ITE_IT8712F select BOARD_HAS_FADT - select GENERATE_ACPI_TABLES - select GENERATE_MP_TABLE - select GENERATE_PIRQ_TABLE + select HAVE_ACPI_TABLES + select HAVE_MP_TABLE + select HAVE_PIRQ_TABLE select HAVE_OPTION_TABLE select HAVE_MAINBOARD_RESOURCES select HAVE_BUS_CONFIG Modified: trunk/src/mainboard/amd/mahogany/Kconfig == --- trunk/src/mainboard/amd/mahogany/KconfigFri Nov 5 13:44:25 2010 (r6026) +++ trunk/src/mainboard/amd/mahogany/KconfigFri Nov 5 17:17:46 2010 (r6027) @@ -11,9 +11,9 @@ select SOUTHBRIDGE_AMD_SB700 select SUPERIO_ITE_IT8718F select BOARD_HAS_FADT - select GENERATE_ACPI_TABLES - select GENERATE_MP_TABLE - select GENERATE_PIRQ_TABLE + select HAVE_ACPI_TABLES + select HAVE_MP_TABLE + select HAVE_PIRQ_TABLE select HAVE_OPTION_TABLE select HAVE_MAINBOARD_RESOURCES select HAVE_BUS_CONFIG Modified: trunk/src/mainboard/amd/mahogany_fam10/Kconfig == --- trunk/src/mainboard/amd/mahogany_fam10/Kconfig Fri Nov 5 13:44:25 2010(r6026) +++ trunk/src/mainboard/amd/mahogany_fam10/Kconfig Fri Nov 5 17:17:46 2010(r6027) @@ -13,8 +13,8 @@ select BOARD_HAS_FADT select HAVE_BUS_CONFIG select HAVE_OPTION_TABLE - select GENERATE_PIRQ_TABLE - select GENERATE_MP_TABLE + select HAVE_PIRQ_TABLE + select HAVE_MP_TABLE select HAVE_MAINBOARD_RESOURCES select CACHE_AS_RAM select HAVE_HARD_RESET @@ -22,7 +22,7 @@ select LIFT_BSP_APIC_ID select SERIAL_CPU_INIT select AMDMCT - select GENERATE_ACPI_TABLES + select HAVE_ACPI_TABLES select BOARD_ROMSIZE_KB_1024 select RAMINIT_SYSINFO select ENABLE_APIC_EXT_ID Modified: trunk/src/mainboard/amd/tilapia_fam10/Kconfig == --- trunk/src/mainboard/amd/tilapia_fam10/Kconfig Fri Nov 5 13:44:25 2010(r6026) +++ trunk/src/mainboard/amd/tilapia_fam10/Kconfig Fri Nov 5 17:17:46 2010(r6027) @@ -13,8 +13,8 @@ select BOARD_HAS_FADT select HAVE_BUS_CONFIG select HAVE_OPTION_TABLE - select GENERATE_PIRQ_TABLE - select GENERATE_MP_TABLE + select HAVE_PIRQ_TABLE + select HAVE_MP_TABLE select HAVE_MAINBOARD_RESOURCES select CACHE_AS_RAM select HAVE_HARD_RESET @@ -22,7 +22,7 @@ select LIFT_BSP_APIC_ID select SERIAL_CPU_INIT select AMDMCT -
Re: [coreboot] build questions
On Sun, Oct 31, 2010 at 3:04 PM, Flemming Richter Mikkelsen quat...@member.fsf.org wrote: Hello. Today I tried to build coreboot for the very first time. I discovered that the debug configs caused some harmless warnings of the type referenced but not used. Also, I tried scan-build. I never tried this before, and therefore I don't know it limitations. A make generated a list of 60 bugs. Not all of them are real bugs though. It looks like it found that we use math operation on a uninitialized value: File: northbridge/amd/amdfam10/../amdmct/mct/mctndi_d.c Location: line 98, column 6 Description: The left expression of the compound assignment is an uninitialized value. The computed value will also be garbage DctSelBaseOffset -= Base; Anyway, the computed value is never used. Would it make sense to remove unused variables? If so, I can try to create a few patches. I think scan-build is almost useless when it generate a list of 60 bugs. Hi and welcome to coreboot! We are always interested in getting more people submitting patches. Please send yours. We will do our best to review and commit them. Regard, Marc -- http://se-eng.com -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] MCP55 Mac Address copying/change
On Thu, Nov 4, 2010 at 11:55 AM, Harald Gutmann harald.gutm...@gmx.net wrote: Hello! Yesterday I tried coreboot again, and it worked fine so far. But I faced a nasty problem, like the last time I tried it with the MAC address on MCP55. This is nothing serious as you can change it by editing the romcache.inc from the southbridge, but it's nasty. I was thinking about fixing this in a decent way. I'd love to see a KConfig value to enter in the configure process to get this done, or even to copy the mac address of the board. As of now the MAC is stored in the romcache.inc file of the southbridge, and as far as I guess, this value is read in the mcp55_nic.c and used. There is as of now in the bugtracker a script to apply the new mac after compiling the image, but I think this is not a really good solution. If my guess is right, readout from romcache.inc and usage in mcp55_nic.c it should be possible to solve this via KConfig, and not read the value from the romcache.inc, but store it a config value and take this value. Possibly with a fallback on the romcache.inc value. My questions on this suggestion are: Would there be any good reason not to do it that way? Is my guess right? (Until now I didn't look that careful into the code of mcp55_nic.c.) If my guess is right, and there is no problem to do as suggested, I'd prepare a patch for it. Any comments are welcome. Hi Harald, It seems like a Kconfig option would be a good idea. It can alway default to a reasonable value. Another idea I have seen floating around is to have the value stored in cbfs. Then it could be updated post coreboot build. Marc -- http://se-eng.com -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] MCP55 Mac Address copying/change
Am 05.11.2010 17:27, schrieb Marc Jones: It seems like a Kconfig option would be a good idea. It can alway default to a reasonable value. Another idea I have seen floating around is to have the value stored in cbfs. Then it could be updated post coreboot build. Not sure, but don't some chipsets handle MAC addresses via the romstrap area? If so, kconfig might be a better place (for all boards), so the MAC can be compiled into the romstrap as part of the build process. The only question is the format the MAC should be in. The Makefile could rewrite 1:23:45:67:89:ab to a set of #defines (MAC1, .., MAC6 with a byte each?), so whatever the romstrap format for MAC addresses is could be modelled in code. Patrick -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] MCP55 Mac Address copying/change
On Thu, Nov 04, 2010 at 06:55:28PM +0100, Harald Gutmann wrote:
Hello!
Yesterday I tried coreboot again, and it worked fine so far.
But I faced a nasty problem, like the last time I tried it with the MAC
address on MCP55. This is nothing serious as you can change it by editing the
romcache.inc from the southbridge, but it's nasty.
I was thinking about fixing this in a decent way. I'd love to see a KConfig
value to enter in the configure process to get this done, or even to copy the
mac address of the board.
Look at the romstrap of the vendor-provided firmware update image for
a nvidia board. You'll find it doesn't contain your board's address.
IMO this issue would be best solved in the vicinity of flashrom.
It's trivial to follow the romstrap pointers and copy over
the address.
Attached is a utility to do just that.
Jonathan Kollasch
/*
* Copyright (c) 2010 Jonathan A. Kollasch
* All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
* 1. Redistributions of source code must retain the above copyright
*notice, this list of conditions and the following disclaimer.
* 2. Redistributions in binary form must reproduce the above copyright
*notice, this list of conditions and the following disclaimer in the
*documentation and/or other materials provided with the distribution.
*
* THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
* AS IS AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED
* TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
* PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR
* CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
* EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
* PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS;
* OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY,
* WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
* OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF
* ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
*/
/*
* transfer UUID/MAC address in nvidia romstrap
*/
#include stdint.h
#include stdio.h
#ifdef __NetBSD__
#include sys/endian.h
#else
#warning assuming LE host
#define le32toh(x) (x)
#endif
FILE *srcrom;
FILE *dstrom;
uint32_t srcbase;
uint32_t dstbase;
uint32_t srcrsp;
uint32_t dstrsp;
uint8_t uuid[16];
int
get_rom(FILE *f, uint32_t *v)
{
uint32_t tmp;
size_t ret;
ret = fread(tmp, sizeof(tmp), 1, f) != 1;
if (ret == 0 v != NULL)
*v = tmp;
return ret;
}
int
main(int argc, char *argv[])
{
uint32_t srctmp;
uint32_t dsttmp;
if (argc 3)
return 1;
srcrom = fopen(argv[1], r);
if (srcrom == NULL)
return 1;
dstrom = fopen(argv[2], r+);
if (dstrom == NULL)
return 1;
/* seek to the romstrap pointer, find offset of ROM image */
fseek(srcrom, -0x20, SEEK_END);
srcbase = 0x1ULL - (ftell(srcrom) + 0x20);
//printf(%x\n, srcbase);
fseek(dstrom, -0x20, SEEK_END);
dstbase = 0x1ULL - (ftell(dstrom) + 0x20);
//printf(%x\n, dstbase);
/* read romstrap pointer */
if (get_rom(srcrom, srcrsp))
return 1;
srcrsp = le32toh(srcrsp);
//printf(srcrsp %x\n, srcrsp);
if (get_rom(dstrom, dstrsp))
return 1;
dstrsp = le32toh(dstrsp);
//printf(dstrsp %x\n, dstrsp);
/* move to romstrap table */
fseek(srcrom, srcrsp - srcbase, SEEK_SET);
fseek(dstrom, dstrsp - dstbase, SEEK_SET);
/* check for romstrap signature */
if (get_rom(srcrom, srctmp))
return 1;
srctmp = le32toh(srctmp);
if (srctmp != 0x2b16d065)
return 1;
if (get_rom(dstrom, dsttmp))
return 1;
dsttmp = le32toh(dsttmp);
if (dsttmp != 0x2b16d065)
return 1;
/* move to next pointer */
fseek(srcrom, srcrsp - srcbase + 0x0c, SEEK_SET);
fseek(dstrom, dstrsp - dstbase + 0x0c, SEEK_SET);
/* read pointer */
if (get_rom(srcrom, srctmp))
return 1;
srctmp = le32toh(srctmp);
if (srctmp != (srcrsp + 0x10)) {
//printf(source list not at usual location\n);
}
if (get_rom(dstrom, dsttmp))
return 1;
dsttmp = le32toh(dsttmp);
if (dsttmp != (dstrsp + 0x10)) {
//printf(dest list not at usual location\n);
}
// /* follow pointer */
//fseek(srcrom, srctmp - srcbase, SEEK_SET);
//fseek(dstrom, dsttmp - dstbase, SEEK_SET);
Re: [coreboot] questions on coreboot bootlog w/ EP80579(Truxton platform)
Hi Xavier, I have never seen that kind of output when using Truxton. All I can suggest is to make sure your serial settings are correct and double check any modifications you may have made to the coreboot source. Note though, trunk does not support non-ECC RAM. The raminit_ep80579.c code will refuse to boot if it detects non-ECC RAM. Dustin On 05/11/2010 3:00 AM, Xavier Carcelle wrote: Hi there, I am currently testing coreboot for the Intel EP80579 w/ the Truxton platform w/ DDR2 (not ECC) on the DIMM0 slot of the platform. I am having the following bootlog but don't understand what is the output meaning ? Thanks, Xavier. coreboot-4.0-r5689 coreboot-4.0-r5689 50AI 00 01 51AI 00 01 52AI 00 01 53AI 0080 08 08 0e 0a 00 40 00 05 3d 50 00 82 08 00 00 AI 100c 08 38 01 02 00 03 3d 50 50 60 3c 1e 3c 2d 01 AI 2025 37 10 220 01 55AI 00 01 56AI 00 01 57AI 00ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff AI 10ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff AI 20ff ff ff ff 00 00 MHz DDR Sc cd` - 25c cd` - 0201` - c cd` - DR DRB = TOM = TOLM = cl = 00 trc = 7e trfc = 00 tras = 00 trtp = 40 twtr = 00 drt0 = ffea drt1 = fc70 magic = 009a62b1 mrs = 6902 T @Q0010T @Q0020T @Q0030T @0 ``c` CS01 q0010DDR R 00T @QR 01T @QT @Q00100010T @Q0020T @Q00 T @Q00100010T @Q0020T @Q0030T @S 00:00.: 86 80 20 50 06 00 10 00 01 00 00 06 00 00 80 00 10: 00 00 00 00 00 00 00 90 00 00 00 00 00 00 00 00 20: 00 00 00 00 -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH]Move QRANK_DIMM_SUPPORT to Kconfig
Patrick Georgi wrote: (are qrank dimms really a per-board thing?) Which boards do not have the variable set? //Peter -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH]Move QRANK_DIMM_SUPPORT to Kconfig
Am 05.11.2010 19:20, schrieb Peter Stuge: Patrick Georgi wrote: (are qrank dimms really a per-board thing?) Which boards do not have the variable set? About 30, I think. I only did a grep .. | wc -l comparison: $ grep NORTHBRIDGE_AMD_AMDK8 src/mainboard/*/*/Kconfig |wc -l 86 So 86 boards are eligible for that option. $ svn st |grep romstage.c |wc -l 63 63 boards have that option dropped (the patch is the only change in that tree). So there are 23 boards that do not set it. Patrick -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH]Move QRANK_DIMM_SUPPORT to Kconfig
-Original Message- From: coreboot-boun...@coreboot.org [mailto:coreboot-boun...@coreboot.org] On Behalf Of Peter Stuge Sent: Friday, November 05, 2010 01:21 PM To: coreboot@coreboot.org Subject: Re: [coreboot] [PATCH]Move QRANK_DIMM_SUPPORT to Kconfig ]Patrick Georgi wrote: ] (are qrank dimms really a per-board thing?) ] ]Which boards do not have the variable set? I am no quad rank dimm expert, but I think few boards support them. One is Serengeti Cheetah. I remember asking why one processor socket has 4 dimm slots and another 8. I was told it was for quad rank dimm testing. The chip selects for two normal dimm sockets are combined and routed to a quad rank socket, if I remember correctly. I don't even have any quad ranked dimms to test with. I think they are rare. Thanks, Scott ]//Peter -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH]Move QRANK_DIMM_SUPPORT to Kconfig
On Fri, Nov 05, 2010 at 01:28:59PM -0500, Scott Duplichan wrote: I am no quad rank dimm expert, but I think few boards support them. One is Serengeti Cheetah. I remember asking why one processor socket has 4 dimm slots and another 8. I was told it was for quad rank dimm testing. The chip selects for two normal dimm sockets are combined and routed to a quad rank socket, if I remember correctly. I don't even have any quad ranked dimms to test with. I think they are rare. Actually, they are not *that* rare, since they are readily available: http://www.newegg.com/Product/ProductList.aspx?Submit=ENEDEPA=0Order=BESTMATCHDescription=ddr3+quad+rankx=0y=0 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] [PATCH]Move QRANK_DIMM_SUPPORT to Kconfig
-Original Message- From: Ward Vandewege [mailto:w...@gnu.org] Sent: Friday, November 05, 2010 01:42 PM To: Scott Duplichan Cc: 'Peter Stuge'; coreboot@coreboot.org Subject: Re: [coreboot] [PATCH]Move QRANK_DIMM_SUPPORT to Kconfig ]On Fri, Nov 05, 2010 at 01:28:59PM -0500, Scott Duplichan wrote: ] I am no quad rank dimm expert, but I think few boards support them. One is Serengeti ] Cheetah. I remember asking why one processor socket has 4 dimm slots and another 8. ] I was told it was for quad rank dimm testing. The chip selects for two normal dimm sockets ] are combined and routed to a quad rank socket, if I remember correctly. I don't even ] have any quad ranked dimms to test with. I think they are rare. ] ]Actually, they are not *that* rare, since they are readily available: ] ] ]http://www.newegg.com/Product/ProductList.aspx?Submit=ENEDEPA=0Order=BESTMATCHDescription=ddr3]+quad+rankx=0y=0 Sure enough. And not a bad price (per MB), either. Thanks for pointing them out. Though I would question the maturity of coreboot support for registered DDR3 in general, and specifically for 1333 speed or quad rank. I believe these were perfected internally at AMD only recently. How well has coreboot been tested with various speeds of registered DDR3? There is a lot more complexity in the memory init code when registered DIMMs of any rank count are used. And there is still the question of what boards supported by coreboot really have hardware support for quadrank. I would hate to mislead someone into buying a system loaded with registered memory with the idea of running coreboot, unless it is known to work. Thanks, Scott ]-- ]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] [PATCH]Move QRANK_DIMM_SUPPORT to Kconfig
Am 05.11.2010 19:58, schrieb Scott Duplichan: really have hardware support for quadrank. I would hate to mislead someone into buying a system loaded with registered memory with the idea of running coreboot, unless it is known to work. I think (and hope) that I didn't mark any board as quad rank capable that wasn't marked that way before, but I can't tell if the original options are set correctly. In this regard, the tree with this patch is as good as without. Patrick -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] Questions about more AMD related flags
Hi, while I opened that can of worms over with QRANK_DIMM_SUPPORT, and people are listening ;-), let me widen the debate some more: SET_NB_CFG_54: 1. It's used in two places (dualcore and quadcore AMD code) 2. There, it's set active if undeclared before 3. All other declarations set this active Any reason to keep this variable at all? If yes, I'll move it to Kconfig, otherwise I'll just drop it. and SET_FIDVID*: These have _very_ weird behaviour, being set to some defaults in the two init_cpus.c (and fidvid.c seems to expect to be included after that one?), and some other settings somewhere else. I tried to untangle that while moving to Kconfig, but didn't quite succeed, so is here anyone who knows which defaults (or dependencies) are correct for each of the following? So far I have: For K8: +config SET_FIDVID + bool + default y if K8_REV_F_SUPPORT + default n + +config SET_FIDVID_CORE0_ONLY + bool + default y + depends on SET_FIDVID + +config SET_FIDVID_CORE_RANGE + bool + default n + depends on SET_FIDVID + +config SET_FIDVID_ONE_BY_ONE + bool + default y + depends on SET_FIDVID + +config SET_FIDVID_DEBUG + bool + default n + depends on SET_FIDVID + +config SET_FIDVID_STORE_AP_APICID_AT_FIRST + bool + default y + depends on SET_FIDVID For Fam10h: +config SET_FIDVID + bool + default y + +config SET_FIDVID_CORE0_ONLY + bool + default n + depends on SET_FIDVID + +config SET_FIDVID_CORE_RANGE + bool + default n + depends on SET_FIDVID + +config SET_FIDVID_DEBUG + bool + default y + depends on SET_FIDVID + +config SET_FIDVID_STORE_AP_APICID_AT_FIRST + bool + default y + depends on SET_FIDVID Corrections welcome Thanks, Patrick -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH]Move QRANK_DIMM_SUPPORT to Kconfig
Am 05.11.2010 19:58, schrieb Scott Duplichan: really have hardware support for quadrank. I would hate to mislead someone into buying a system loaded with registered memory with the idea of running coreboot, unless it is known to work. I think (and hope) that I didn't mark any board as quad rank capable that wasn't marked that way before, but I can't tell if the original options are set correctly. In this regard, the tree with this patch is as good as without. Agreed. Acked-by: Myles Watson myle...@gmail.com Thanks, Myles -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH] Geode GX2 print(k) V2
Op vrijdag 5 november 2010 01:14:03 schreef u: On Thu, Nov 04, 2010 at 11:35:56PM +0100, Nils wrote: Remove banner wrapper function and unify print(k). Signed-off-by: Nils Jacobs njaco...@hetnet.nl Thanks, 6021. Uwe. Thanks for the review and commit. Nils. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH] Add cpu speed selection to Geode GX2 boards
Op vrijdag 5 november 2010 01:23:48 schreef u: On Tue, Nov 02, 2010 at 10:33:44PM +0100, Nils wrote: This patch adds Kconfig cpu speed selection to Geode GX2 boards as requested by Uwe. Signed-off-by: Nils Jacobs njaco...@hetnet.nl Thanks, r6023. Uwe. Thanks for the review and commit. Nils. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH] Define unused DIMM1 to 0xFF on Geode GX2 boards
Op vrijdag 5 november 2010 01:20:03 schreef u: On Tue, Nov 02, 2010 at 10:33:22PM +0100, Nils wrote: This patch defines the unused DIMM1 to 0xFF to make it obvious it is a bogus value. Signed-off-by: Nils Jacobs njaco...@hetnet.nl Thanks, r6022. I added some comments too to make it clearer why it's 0xFF, I hope the comments are correct and make sense. Uwe. Thanks for the review and commit. Your comments look great. Nils. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH 0/4] Geode GX2 auto DRAM detect patch V2
Op vrijdag 5 november 2010 01:29:52 schreef u: On Mon, Nov 01, 2010 at 08:28:27PM +0100, Nils wrote: Shouldn't there be a while (1) around the hlt instruction? ?? i don't know should it? The code seems to work, but if it is preferred/needed i will add it. As far as I know the hlt instruction on x86 does not really terminally halt the processor, it can be woken up again by certain events (NMI, debug exceptions, whatever). So usually you only see the hlt instruction in a while(1) loop if you want the code to not ever continue execution after the hlt instruction. But someone please correct me if I'm wrong. Uwe. Ok thanks for the explanation. It sounds plausible. I copied it from the LX code. I will study this a bit more when i find some time and try to make a patch. Thanks, Nils. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] [commit] r6029 - in trunk/src/mainboard: amd/mahogany_fam10 amd/serengeti_cheetah amd/serengeti_cheetah_fam10 amd/tilapia_fam10 asus/a8n_e asus/a8v-e_se asus/m2v-mx_se asus/m4a785-m gigabyt
Author: uwe Date: Sat Nov 6 01:57:19 2010 New Revision: 6029 URL: https://tracker.coreboot.org/trac/coreboot/changeset/6029 Log: Remove comments that are obsolete since r6028. Signed-off-by: Uwe Hermann u...@hermann-uwe.de Acked-by: Uwe Hermann u...@hermann-uwe.de Modified: trunk/src/mainboard/amd/mahogany_fam10/romstage.c trunk/src/mainboard/amd/serengeti_cheetah/ap_romstage.c trunk/src/mainboard/amd/serengeti_cheetah/romstage.c trunk/src/mainboard/amd/serengeti_cheetah_fam10/romstage.c trunk/src/mainboard/amd/tilapia_fam10/romstage.c trunk/src/mainboard/asus/a8n_e/romstage.c trunk/src/mainboard/asus/a8v-e_se/romstage.c trunk/src/mainboard/asus/m2v-mx_se/romstage.c trunk/src/mainboard/asus/m4a785-m/romstage.c trunk/src/mainboard/gigabyte/ga_2761gxdk/ap_romstage.c trunk/src/mainboard/gigabyte/m57sli/ap_romstage.c trunk/src/mainboard/gigabyte/ma785gmt/romstage.c trunk/src/mainboard/gigabyte/ma78gm/romstage.c trunk/src/mainboard/iwill/dk8_htx/romstage.c trunk/src/mainboard/iwill/dk8s2/romstage.c trunk/src/mainboard/iwill/dk8x/romstage.c trunk/src/mainboard/jetway/pa78vm5/romstage.c trunk/src/mainboard/msi/ms7135/romstage.c trunk/src/mainboard/msi/ms9185/romstage.c trunk/src/mainboard/msi/ms9282/romstage.c trunk/src/mainboard/nvidia/l1_2pvv/ap_romstage.c trunk/src/mainboard/supermicro/h8dme/ap_romstage.c trunk/src/mainboard/supermicro/h8dmr/ap_romstage.c trunk/src/mainboard/tyan/s2891/romstage.c trunk/src/mainboard/tyan/s2912/ap_romstage.c Modified: trunk/src/mainboard/amd/mahogany_fam10/romstage.c == --- trunk/src/mainboard/amd/mahogany_fam10/romstage.c Fri Nov 5 23:59:49 2010(r6028) +++ trunk/src/mainboard/amd/mahogany_fam10/romstage.c Sat Nov 6 01:57:19 2010(r6029) @@ -23,8 +23,6 @@ #define SET_NB_CFG_54 1 -//used by raminit - //used by incoherent_ht #define FAM10_SCAN_PCI_BUS 0 #define FAM10_ALLOCATE_IO_RANGE 0 Modified: trunk/src/mainboard/amd/serengeti_cheetah/ap_romstage.c == --- trunk/src/mainboard/amd/serengeti_cheetah/ap_romstage.c Fri Nov 5 23:59:49 2010(r6028) +++ trunk/src/mainboard/amd/serengeti_cheetah/ap_romstage.c Sat Nov 6 01:57:19 2010(r6029) @@ -3,8 +3,6 @@ #define SET_NB_CFG_54 1 -//used by raminit - #define K8_REV_F_SUPPORT_F0_F1_WORKAROUND 0 #include stdint.h Modified: trunk/src/mainboard/amd/serengeti_cheetah/romstage.c == --- trunk/src/mainboard/amd/serengeti_cheetah/romstage.cFri Nov 5 23:59:49 2010(r6028) +++ trunk/src/mainboard/amd/serengeti_cheetah/romstage.cSat Nov 6 01:57:19 2010(r6029) @@ -1,7 +1,5 @@ #define SET_NB_CFG_54 1 -//used by raminit - //used by incoherent_ht //#define K8_ALLOCATE_IO_RANGE 1 Modified: trunk/src/mainboard/amd/serengeti_cheetah_fam10/romstage.c == --- trunk/src/mainboard/amd/serengeti_cheetah_fam10/romstage.c Fri Nov 5 23:59:49 2010(r6028) +++ trunk/src/mainboard/amd/serengeti_cheetah_fam10/romstage.c Sat Nov 6 01:57:19 2010(r6029) @@ -23,8 +23,6 @@ #define SET_NB_CFG_54 1 -//used by raminit - //used by incoherent_ht #define FAM10_SCAN_PCI_BUS 0 #define FAM10_ALLOCATE_IO_RANGE 0 Modified: trunk/src/mainboard/amd/tilapia_fam10/romstage.c == --- trunk/src/mainboard/amd/tilapia_fam10/romstage.cFri Nov 5 23:59:49 2010(r6028) +++ trunk/src/mainboard/amd/tilapia_fam10/romstage.cSat Nov 6 01:57:19 2010(r6029) @@ -23,8 +23,6 @@ #define SET_NB_CFG_54 1 -//used by raminit - //used by incoherent_ht #define FAM10_SCAN_PCI_BUS 0 #define FAM10_ALLOCATE_IO_RANGE 0 Modified: trunk/src/mainboard/asus/a8n_e/romstage.c == --- trunk/src/mainboard/asus/a8n_e/romstage.c Fri Nov 5 23:59:49 2010 (r6028) +++ trunk/src/mainboard/asus/a8n_e/romstage.c Sat Nov 6 01:57:19 2010 (r6029) @@ -24,8 +24,6 @@ /* Used by it8712f_enable_serial(). */ #define SERIAL_DEV PNP_DEV(0x2e, IT8712F_SP1) -/* Used by raminit. */ - #if CONFIG_LOGICAL_CPUS == 1 #define SET_NB_CFG_54 1 #endif Modified: trunk/src/mainboard/asus/a8v-e_se/romstage.c == --- trunk/src/mainboard/asus/a8v-e_se/romstage.cFri Nov 5 23:59:49 2010(r6028) +++ trunk/src/mainboard/asus/a8v-e_se/romstage.cSat Nov 6 01:57:19 2010(r6029) @@ -24,8 +24,6 @@ unsigned int get_sbdn(unsigned bus); -/* Used by raminit. */ - /* Used by init_cpus and fidvid */ #define SET_FIDVID 1 Modified:
Re: [coreboot] Questions about more AMD related flags
-Original Message- From: coreboot-boun...@coreboot.org [mailto:coreboot-boun...@coreboot.org] On Behalf Of Patrick Georgi Sent: Friday, November 05, 2010 02:11 PM To: coreboot@coreboot.org Subject: [coreboot] Questions about more AMD related flags ]Hi, ] ]while I opened that can of worms over with QRANK_DIMM_SUPPORT, and ]people are listening ;-), let me widen the debate some more: ] ]SET_NB_CFG_54: ]1. It's used in two places (dualcore and quadcore AMD code) ]2. There, it's set active if undeclared before ]3. All other declarations set this active ] ]Any reason to keep this variable at all? If yes, I'll move it to ]Kconfig, otherwise I'll just drop it. I am familiar with the recent history of this bit. It defaults to zero, resulting in the 'weird' local apic id numbering. BIOS is supposed to set it early to get the normal apic id numbering. While I do not know the origin of this strange bit, I do know it was scheduled for removal in future AMD processors. Unfortunately the removal plan was rejected. I would certainly get rid of SET_NB_CFG_54. Just let coreboot set this bit early so that there is no need to deal with two different local apic id formats. Thanks, Scott ]Thanks, ]Patrick -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
