Re: [coreboot] [commit] r5330 - in trunk: . src/arch/i386
Stefan Reinauer ste...@coresystems.de writes: I always do. :) This is reproducible as follows: $ svn co svn://coreboot.org/coreboot/trunk coreboot [..] Checked out revision 5396. $ cd coreboot $ perl -npi -e 's/(?=select TINY)/#/' src/mainboard/tyan/s2912_fam10/Kconfig add .config $ make oldconfig $ make Aaah! The Fam10 code is too big to work without tiny bootblock. Sorry I didn't recognize this earlier. Which code is missing in the final binary, do you say? The s2912_fam10 is missing the romstrap parts. When I try to enable the romstrap linker scripts for TINY_BOOTBLOCK (instead of disabling TINY) I get a different set of linker overlap errors. -- Arne. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] [PATCH] Get rid of unaligned 32-bit config space read in mcd_d.c
Hi,
This patch removes a non-32-bit aligned Get_NB32 from
src/northbridge/amd/amdmct/mct/mct_d.c. The actual behavior should be
unchanged for I/O-based config space reads, but previous behavior was
wrong for MMCFG-based config space reads.
Perhaps we want pci_mmio_*_config* to enforce natural alignment as well?
Signed-off-by: Arne Georg Gleditsch arne.gledit...@numascale.com
--
Arne.
diff --git a/src/northbridge/amd/amdmct/mct/mct_d.c b/src/northbridge/amd/amdmct/mct/mct_d.c
index 22e9902..1779938 100644
--- a/src/northbridge/amd/amdmct/mct/mct_d.c
+++ b/src/northbridge/amd/amdmct/mct/mct_d.c
@@ -1970,7 +1970,7 @@ static void StitchMemory_D(struct MCTStatStruc *pMCTstat,
reg = 0x40 + (q 2) + reg_off; /* Base[q] reg.*/
val = Get_NB32(dev, reg);
if (!(val 3)) { /* (CSEnable|Spare==1)bank is enabled already? */
- reg = 0x60 + (q 1) + reg_off; /*Mask[q] reg.*/
+ reg = 0x60 + ((q 1) 0xc) + reg_off; /*Mask[q] reg.*/
val = Get_NB32(dev, reg);
val = 19;
val++;
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Asus M2V-TVM....
I didn't see such struct in my image,so maybe it's related to IRQ routing?? It is the ROMSTRAP for HT setup. I think this is the reason why it does not work. If you build image for M2V-MX SE you should see it at the end of the image (same counts for A8V-E SE). Rudolf -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] (no subject)
Can someone answer my question?http://www.coreboot.org/pipermail/coreboot/2010-April/057236.html-- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] another patch for FILO building error
Hi, attached patch does: - add extern declaration of UNIQUE_BUF Signed-off-by: Cai Bai Yin caibaiyin@gmail.com a.patch Description: Binary data -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] [commit] r5409 - in trunk/src: . cpu/via/car cpu/x86 mainboard/via/vt8454c
Author: oxygene Date: Mon Apr 12 11:50:53 2010 New Revision: 5409 URL: https://tracker.coreboot.org/trac/coreboot/changeset/5409 Log: - move the XIP_ROM_* flags to src/cpu/x86/Kconfig exclusively - set them to span the last 64k, instead of the last 128k by default - fixes via CAR for tiny bootblock - enabled tiny bootblock for via/vt8454c Signed-off-by: Patrick Georgi patrick.geo...@coresystems.de Acked-by: Stefan Reinauer ste...@coresystems.de Modified: trunk/src/Kconfig trunk/src/cpu/via/car/cache_as_ram.inc trunk/src/cpu/x86/Kconfig trunk/src/mainboard/via/vt8454c/Kconfig Modified: trunk/src/Kconfig == --- trunk/src/Kconfig Sun Apr 11 22:04:50 2010(r5408) +++ trunk/src/Kconfig Mon Apr 12 11:50:53 2010(r5409) @@ -116,14 +116,6 @@ int default 36 -config XIP_ROM_BASE - hex - default 0xfffe - -config XIP_ROM_SIZE - hex - default 0x2 - config LOGICAL_CPUS bool default y Modified: trunk/src/cpu/via/car/cache_as_ram.inc == --- trunk/src/cpu/via/car/cache_as_ram.inc Sun Apr 11 22:04:50 2010 (r5408) +++ trunk/src/cpu/via/car/cache_as_ram.inc Mon Apr 12 11:50:53 2010 (r5409) @@ -139,7 +139,7 @@ xorl$0x5c5c5c5c,%eax rep stosl - movlCONFIG_XIP_ROM_BASE, %esi + movlREAL_XIP_ROM_BASE, %esi movl%esi, %edi movl$(CONFIG_XIP_ROM_SIZE2), %ecx rep lodsl @@ -241,10 +241,10 @@ movl$((~(( 0 + 0x4) - 1)) | 0x800), %eax wrmsr - /* cache CONFIG_XIP_ROM_BASE-SIZE to speedup coreboot code */ + /* cache XIP_ROM_BASE-SIZE to speedup coreboot code */ movl$0x206, %ecx xorl%edx, %edx - movl $CONFIG_XIP_ROM_BASE,%eax + movl $REAL_XIP_ROM_BASE,%eax orl $(0 | 6), %eax wrmsr Modified: trunk/src/cpu/x86/Kconfig == --- trunk/src/cpu/x86/Kconfig Sun Apr 11 22:04:50 2010(r5408) +++ trunk/src/cpu/x86/Kconfig Mon Apr 12 11:50:53 2010(r5409) @@ -25,8 +25,8 @@ config XIP_ROM_BASE hex - default 0xfffe + default 0x config XIP_ROM_SIZE hex - default 0x2 + default 0x1 Modified: trunk/src/mainboard/via/vt8454c/Kconfig == --- trunk/src/mainboard/via/vt8454c/Kconfig Sun Apr 11 22:04:50 2010 (r5408) +++ trunk/src/mainboard/via/vt8454c/Kconfig Mon Apr 12 11:50:53 2010 (r5409) @@ -12,6 +12,7 @@ select HAVE_ACPI_TABLES select BOARD_ROMSIZE_KB_512 select USE_DCACHE_RAM + select TINY_BOOTBLOCK config MAINBOARD_DIR string -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH] VIA C7 CAR fixes / cleanup
Am 12.04.2010 06:41, schrieb Kevin O'Connor: 00.412: *post ddr_ram_setup() 00.415: Stage: loading fallback/coreboot_ram @ 0x4000 (163840 bytes), entry @ 0x4000 01.369: coreboot-4.0-r5408M Mon Apr 12 00:19:03 EDT 2010 booting... Indeed, the time to Stage:... is faster than romcc now. Just need to fix that delay after Stage:.. Your other mail seems to indicate that this is because of the stack at 64MB. How about this: While building the romstage, the location and size of the ramstage area is already known. If we: - Move the intermediate stack to wherever the ramstage stack resides (somewhere close to RAMTOP), - change the stage loaders (copy and ulzma) to leave out %esp..RAMTOP (with some safety margin below %esp), which should always be 0 anyway, and - enable caching for RAMBASE..RAMTOP (already done, I think) we should use a harmless memory area for stack (esp. in light of wakeup from suspend) and have caching enabled for all relevant memory regions, right? Patrick -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] [commit] r5410 - trunk/src/arch/i386
Author: oxygene Date: Mon Apr 12 12:22:20 2010 New Revision: 5410 URL: https://tracker.coreboot.org/trac/coreboot/changeset/5410 Log: Enable lazy evaluation of incs/lds for tiny bootblock, too. Necessary for romstraps Signed-off-by: Patrick Georgi patrick.geo...@coresystems.de Acked-by: Patrick Georgi patrick.geo...@coresystems.de Modified: trunk/src/arch/i386/Makefile.bootblock.inc Modified: trunk/src/arch/i386/Makefile.bootblock.inc == --- trunk/src/arch/i386/Makefile.bootblock.inc Mon Apr 12 11:50:53 2010 (r5409) +++ trunk/src/arch/i386/Makefile.bootblock.inc Mon Apr 12 12:22:20 2010 (r5410) @@ -23,13 +23,13 @@ @printf OBJCOPY$(subst $(obj)/,,$(@))\n $(OBJCOPY) -O binary $ $@ -bootblock_lds := $(src)/arch/i386/init/ldscript_failover.lb +bootblock_lds = $(src)/arch/i386/init/ldscript_failover.lb bootblock_lds += $(src)/cpu/x86/16bit/entry16.lds bootblock_lds += $(src)/cpu/x86/16bit/reset16.lds bootblock_lds += $(src)/arch/i386/lib/id.lds bootblock_lds += $(chipset_bootblock_lds) -bootblock_inc := $(src)/arch/i386/init/bootblock_prologue.c +bootblock_inc = $(src)/arch/i386/init/bootblock_prologue.c bootblock_inc += $(src)/cpu/x86/16bit/entry16.inc bootblock_inc += $(src)/cpu/x86/16bit/reset16.inc bootblock_inc += $(src)/cpu/x86/32bit/entry32.inc -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH] Istanbul support
Arne Georg Gleditsch arne.gledit...@numascale.com writes:
Regarding hangs, I suspect this might be a PCI config race condition
between the cores. I tried to adjust my configuration to use MMCONFIG
to address this. It didn't seem to be supported out of the box, and I
didn't have the time to look into it further at the moment. I still
intend to do so, but it would be nice to know if anyone is using
MMCONFIG with fam10 configurations. Is it supposed to work?
Having looked at it some more, it is hard to see how mmconf support can
possibly be functional at the moment. I've made some progress on
getting it to work on my s2912 test rig; I'm appending the patch I'm
currently running. (This is against r5200.)
My only remaining real issue is that parts of the nvidia mcp55 init code
will not run properly using mmconf. The offending line is
RES_PCI_IO, PCI_ADDR(0, 1, 0, 0x78), 0xC0FF, 0x1900,
which causes the operations
pci_read_config32: 0001:0078: 2004
pci_write_config32: 0001:0078: 1904
the second of which never returns when executed using mmconf. I'm
speculating that this might be related to missing HT responses or
something due to bus reconfiguration. As far as I can tell the device
being targeted here is 10de:0364 (ISA bridge: nVidia Corporation MCP55
LPC Bridge).
Anoyone familiar with the mcp55 who can shed some light on what this
write is supposed to accomplish and perhaps also on why it succeeds
using the IO config mechanism when mmconf fails?
--
Arne.
diff --git a/src/arch/i386/include/arch/mmio_conf.h b/src/arch/i386/include/arch/mmio_conf.h
index df91cb5..79f8373 100644
--- a/src/arch/i386/include/arch/mmio_conf.h
+++ b/src/arch/i386/include/arch/mmio_conf.h
@@ -8,7 +8,7 @@ static inline __attribute__((always_inline)) uint8_t read8x(uint32_t addr)
{
uint8_t value;
__asm__ volatile (
-movb %%gs:(%1), %0\n\t
+movb %%gs:(%1), %%al\n\t
:=a(value): b (addr)
);
return value;
@@ -18,7 +18,7 @@ static inline __attribute__((always_inline)) uint16_t read16x(uint32_t addr)
{
uint16_t value;
__asm__ volatile (
-movw %%gs:(%1), %0\n\t
+movw %%gs:(%1), %%ax\n\t
:=a(value): b (addr)
);
@@ -30,7 +30,7 @@ static inline __attribute__((always_inline)) uint32_t read32x(uint32_t addr)
{
uint32_t value;
__asm__ volatile (
-movl %%gs:(%1), %0\n\t
+movl %%gs:(%1), %%eax\n\t
:=a(value): b (addr)
);
@@ -41,7 +41,7 @@ static inline __attribute__((always_inline)) uint32_t read32x(uint32_t addr)
static inline __attribute__((always_inline)) void write8x(uint32_t addr, uint8_t value)
{
__asm__ volatile (
-movb %1, %%gs:(%0)\n\t
+movb %%al, %%gs:(%0)\n\t
:: b (addr), a (value)
);
@@ -50,7 +50,7 @@ static inline __attribute__((always_inline)) void write8x(uint32_t addr, uint8_t
static inline __attribute__((always_inline)) void write16x(uint32_t addr, uint16_t value)
{
__asm__ volatile (
-movw %1, %%gs:(%0)\n\t
+movw %%ax, %%gs:(%0)\n\t
:: b (addr), a (value)
);
@@ -59,7 +59,7 @@ static inline __attribute__((always_inline)) void write16x(uint32_t addr, uint16
static inline __attribute__((always_inline)) void write32x(uint32_t addr, uint32_t value)
{
__asm__ volatile (
-movl %1, %%gs:(%0)\n\t
+movl %%eax, %%gs:(%0)\n\t
:: b (addr), a (value)
);
}
diff --git a/src/arch/i386/include/arch/romcc_io.h b/src/arch/i386/include/arch/romcc_io.h
index 738af66..f20fdf7 100644
--- a/src/arch/i386/include/arch/romcc_io.h
+++ b/src/arch/i386/include/arch/romcc_io.h
@@ -106,7 +106,7 @@ static inline __attribute__((always_inline)) uint8_t pci_io_read_config8(device_
static inline __attribute__((always_inline)) uint8_t pci_mmio_read_config8(device_t dev, unsigned where)
{
unsigned addr;
-addr = CONFIG_MMCONF_BASE_ADDRESS | dev | where;
+addr = dev | where;
return read8x(addr);
}
#endif
@@ -135,7 +135,7 @@ static inline __attribute__((always_inline)) uint16_t pci_io_read_config16(devic
static inline __attribute__((always_inline)) uint16_t pci_mmio_read_config16(device_t dev, unsigned where)
{
unsigned addr;
-addr = CONFIG_MMCONF_BASE_ADDRESS | dev | where;
+addr = dev | where;
return read16x(addr);
}
#endif
@@ -166,7 +166,7 @@ static inline __attribute__((always_inline)) uint32_t pci_io_read_config32(devic
static inline __attribute__((always_inline)) uint32_t pci_mmio_read_config32(device_t dev, unsigned where)
{
unsigned addr;
-addr = CONFIG_MMCONF_BASE_ADDRESS | dev | where;
+addr = dev | where;
Re: [coreboot] [commit] r5330 - in trunk: . src/arch/i386
Am 12.04.2010 08:28, schrieb Arne Georg Gleditsch: The s2912_fam10 is missing the romstrap parts. When I try to enable the romstrap linker scripts for TINY_BOOTBLOCK (instead of disabling TINY) I get a different set of linker overlap errors. r5410 fixes this issue here. Patrick -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [commit] r5330 - in trunk: . src/arch/i386
Patrick Georgi patrick.geo...@coresystems.de writes: r5410 fixes this issue here. Confirmed, boots here. Thanks. -- Arne. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [commit] r5330 - in trunk: . src/arch/i386
Am 12.04.2010 08:28, schrieb Arne Georg Gleditsch: The s2912_fam10 is missing the romstrap parts. When I try to enable the romstrap linker scripts for TINY_BOOTBLOCK (instead of disabling TINY) I get a different set of linker overlap errors. r5410 fixes this issue here. Patrick -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Dualbios on GA-MA770-UD3
on 09/04/2010 19:52 Vadim Girlin said the following: Here is code fragment I mentioned - some bit is set then reset: (Not sure now that this code runs at all) Vadim, cool work! BTW: http://www.rom.by/forum/Gigabyte_DualBIOS :-) -- Andriy Gapon -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH] Istanbul support
Arne Georg Gleditsch arne.gledit...@numascale.com writes: Regarding hangs, I suspect this might be a PCI config race condition between the cores. I tried to adjust my configuration to use MMCONFIG to address this. It didn't seem to be supported out of the box, and I didn't have the time to look into it further at the moment. I still intend to do so, but it would be nice to know if anyone is using MMCONFIG with fam10 configurations. Is it supposed to work? Having looked at it some more, it is hard to see how mmconf support can possibly be functional at the moment. I've made some progress on getting it to work on my s2912 test rig; I'm appending the patch I'm currently running. (This is against r5200.) Nice... ! I've been wondering before... why this odd approach with read8x and gs:... instead of just doing normal read8/16/32 ? Where's %gs set up for romcc_io usage? 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] [PATCH]Move cpu includes to cpus
Hi, attached patch moves the CPU specific includes from src/arch/i386/Makefile.inc to the respective CPU directories. One exception is the tyan/s2735 rule, as this is a weird situation: CAR code for exactly one board. As soon as sibling boards are identified and CAR enabled, it would make sense to move that include out as well. For now, for the increased visibility (and because I'm a bit puzzled where a good location for that file would be), I left it there. The cpu/x86/car/cache_as_ram.lds is useless, so deleting it is also part of this change (not tracked in this patch) Signed-off-by: Patrick Georgi patrick.geo...@coresystems.de Index: src/cpu/via/model_c7/Makefile.inc === --- src/cpu/via/model_c7/Makefile.inc (revision 5408) +++ src/cpu/via/model_c7/Makefile.inc (working copy) @@ -6,3 +6,5 @@ subdirs-y += ../../intel/microcode driver-y += model_c7_init.o + +cpu_incs += $(src)/cpu/via/car/cache_as_ram.inc Index: src/cpu/amd/model_gx1/Makefile.inc === --- src/cpu/amd/model_gx1/Makefile.inc (revision 5408) +++ src/cpu/amd/model_gx1/Makefile.inc (working copy) @@ -23,3 +23,6 @@ subdirs-y += ../../x86/cache subdirs-y += ../../x86/smm driver-y += model_gx1_init.o + +cpu_incs += $(src)/cpu/amd/model_gx1/cpu_setup.inc +cpu_incs += $(src)/cpu/amd/model_gx1/gx_setup.inc Index: src/cpu/amd/socket_S1G1/Makefile.inc === --- src/cpu/amd/socket_S1G1/Makefile.inc(revision 5408) +++ src/cpu/amd/socket_S1G1/Makefile.inc(working copy) @@ -10,3 +10,4 @@ subdirs-y += ../../x86/smm subdirs-y += ../../x86/mtrr +cpu_incs += $(src)/cpu/amd/car/cache_as_ram.inc Index: src/cpu/amd/socket_940/Makefile.inc === --- src/cpu/amd/socket_940/Makefile.inc (revision 5408) +++ src/cpu/amd/socket_940/Makefile.inc (working copy) @@ -8,3 +8,5 @@ subdirs-y += ../../x86/cache subdirs-y += ../../x86/mtrr subdirs-y += ../../x86/pae + +cpu_incs += $(src)/cpu/amd/car/cache_as_ram.inc Index: src/cpu/amd/socket_AM2/Makefile.inc === --- src/cpu/amd/socket_AM2/Makefile.inc (revision 5408) +++ src/cpu/amd/socket_AM2/Makefile.inc (working copy) @@ -9,3 +9,5 @@ subdirs-y += ../../x86/mtrr subdirs-y += ../../x86/pae subdirs-y += ../../x86/smm + +cpu_incs += $(src)/cpu/amd/car/cache_as_ram.inc Index: src/cpu/amd/socket_754/Makefile.inc === --- src/cpu/amd/socket_754/Makefile.inc (revision 5408) +++ src/cpu/amd/socket_754/Makefile.inc (working copy) @@ -8,3 +8,5 @@ subdirs-y += ../../x86/cache subdirs-y += ../../x86/mtrr subdirs-y += ../../x86/pae + +cpu_incs += $(src)/cpu/amd/car/cache_as_ram.inc Index: src/cpu/amd/socket_AM2r2/Makefile.inc === --- src/cpu/amd/socket_AM2r2/Makefile.inc (revision 5408) +++ src/cpu/amd/socket_AM2r2/Makefile.inc (working copy) @@ -9,3 +9,5 @@ subdirs-y += ../../x86/pae subdirs-y += ../../x86/smm subdirs-y += ../../x86/mtrr + +cpu_incs += $(src)/cpu/amd/car/cache_as_ram.inc Index: src/cpu/amd/socket_939/Makefile.inc === --- src/cpu/amd/socket_939/Makefile.inc (revision 5408) +++ src/cpu/amd/socket_939/Makefile.inc (working copy) @@ -8,3 +8,5 @@ subdirs-y += ../../x86/cache subdirs-y += ../../x86/mtrr subdirs-y += ../../x86/pae + +cpu_incs += $(src)/cpu/amd/car/cache_as_ram.inc Index: src/cpu/amd/socket_F/Makefile.inc === --- src/cpu/amd/socket_F/Makefile.inc (revision 5408) +++ src/cpu/amd/socket_F/Makefile.inc (working copy) @@ -9,3 +9,5 @@ subdirs-y += ../../x86/mtrr subdirs-y += ../../x86/pae subdirs-y += ../../x86/smm + +cpu_incs += $(src)/cpu/amd/car/cache_as_ram.inc Index: src/cpu/amd/model_lx/Makefile.inc === --- src/cpu/amd/model_lx/Makefile.inc (revision 5408) +++ src/cpu/amd/model_lx/Makefile.inc (working copy) @@ -6,3 +6,5 @@ driver-y += model_lx_init.o obj-y += cpubug.o obj-y += vsmsetup.o + +cpu_incs += $(src)/cpu/amd/model_lx/cache_as_ram.inc Index: src/cpu/amd/socket_F_1207/Makefile.inc === --- src/cpu/amd/socket_F_1207/Makefile.inc (revision 5408) +++ src/cpu/amd/socket_F_1207/Makefile.inc (working copy) @@ -9,3 +9,5 @@ subdirs-y += ../../x86/mtrr subdirs-y += ../../x86/pae subdirs-y += ../../x86/smm + +cpu_incs += $(src)/cpu/amd/car/cache_as_ram.inc Index: src/cpu/intel/model_6ex/Makefile.inc === --- src/cpu/intel/model_6ex/Makefile.inc(revision 5408) +++
Re: [coreboot] [PATCH] VIA C7 CAR fixes / cleanup
Am 12.04.2010 15:39, schrieb Kevin O'Connor: On Mon, Apr 12, 2010 at 11:56:45AM +0200, Patrick Georgi wrote: Am 12.04.2010 06:41, schrieb Kevin O'Connor: Indeed, the time to Stage:... is faster than romcc now. Just need to fix that delay after Stage:.. Your other mail seems to indicate that this is because of the stack at 64MB. That's my guess - I'll try and confirm tonight. If we: - Move the intermediate stack to wherever the ramstage stack resides (somewhere close to RAMTOP), - change the stage loaders (copy and ulzma) to leave out %esp..RAMTOP (with some safety margin below %esp), which should always be 0 anyway, and - enable caching for RAMBASE..RAMTOP (already done, I think) I didn't understand the first two points. The third point makes sense It seems that the stack is usually close to RAMTOP. We'd have to make sure that it's at a deterministic position (ie. == RAMTOP) and avoid overwriting that stack on decompression, then we could reuse the ramstage stack location for uncompression. - right now on my board RAMBASE is 0x4000 Most boards have RAMBASE at 1MB (or 2MB in some cases). RAMBASE at 16K is only left for a couple of boards that rely on their own vgabios handling. Two things should happen (if someone with the board finds the time): 1. removal of the custom vgabios handling, using oprom instead 2. moving RAMBASE to 1MB if we make sure to cache everything up to RAMTOP and then place the ulzma stack somewhere in that memory range I think it should work. That somewhere could be the stack location of the ramstage. Right now, the code in src/cpu/via/car/cache_as_ram.inc isn't setting up the cache using RAMBASE or RAMTOP - it just does it's own range (which I think is the first 1Meg and a small part of flash) - it's the Might be good to change this at some point. Patrick -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH] VIA C7 CAR fixes / cleanup
On Mon, Apr 12, 2010 at 11:56:45AM +0200, Patrick Georgi wrote: Am 12.04.2010 06:41, schrieb Kevin O'Connor: Indeed, the time to Stage:... is faster than romcc now. Just need to fix that delay after Stage:.. Your other mail seems to indicate that this is because of the stack at 64MB. That's my guess - I'll try and confirm tonight. If we: - Move the intermediate stack to wherever the ramstage stack resides (somewhere close to RAMTOP), - change the stage loaders (copy and ulzma) to leave out %esp..RAMTOP (with some safety margin below %esp), which should always be 0 anyway, and - enable caching for RAMBASE..RAMTOP (already done, I think) I didn't understand the first two points. The third point makes sense - right now on my board RAMBASE is 0x4000 and RAMTOP is 0x20. So, if we make sure to cache everything up to RAMTOP and then place the ulzma stack somewhere in that memory range I think it should work. Right now, the code in src/cpu/via/car/cache_as_ram.inc isn't setting up the cache using RAMBASE or RAMTOP - it just does it's own range (which I think is the first 1Meg and a small part of flash) - it's the code between call main and call copy_and_run. (BTW, having this all in one assembler file is much nicer than the old code.) we should use a harmless memory area for stack (esp. in light of wakeup from suspend) and have caching enabled for all relevant memory regions, right? As a side note, for suspend, I wonder if it would be better to not enable CAR - just unsuspend ram and place the stack in an area of high memory that was reserved during the initial boot. -Kevin -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH] VIA C7 CAR fixes / cleanup
Am 12.04.2010 15:39, schrieb Kevin O'Connor: On Mon, Apr 12, 2010 at 11:56:45AM +0200, Patrick Georgi wrote: Am 12.04.2010 06:41, schrieb Kevin O'Connor: Indeed, the time to Stage:... is faster than romcc now. Just need to fix that delay after Stage:.. Your other mail seems to indicate that this is because of the stack at 64MB. That's my guess - I'll try and confirm tonight. If we: - Move the intermediate stack to wherever the ramstage stack resides (somewhere close to RAMTOP), - change the stage loaders (copy and ulzma) to leave out %esp..RAMTOP (with some safety margin below %esp), which should always be 0 anyway, and - enable caching for RAMBASE..RAMTOP (already done, I think) I didn't understand the first two points. The third point makes sense It seems that the stack is usually close to RAMTOP. We'd have to make sure that it's at a deterministic position (ie. == RAMTOP) and avoid overwriting that stack on decompression, then we could reuse the ramstage stack location for uncompression. Are we caching CONFIG_RAMBASE - CONFIG_RAMTOP ? Most boards have RAMBASE at 1MB (or 2MB in some cases). RAMBASE at 16K is only left for a couple of boards that rely on their own vgabios handling. Two things should happen (if someone with the board finds the time): 1. removal of the custom vgabios handling, using oprom instead 1.5. do the same thing for vsmsetup.c 2. moving RAMBASE to 1MB Stefan -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] [PATCH] stack location
see patch. Not sure if this area is cached, but I think it should be, none the less. -- 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 move stack location to RAMBASE + HIGH_MEMORY_SAVE Signed-off-by: Stefan Reinauer ste...@coresystems.de Index: src/cpu/via/car/cache_as_ram.inc === --- src/cpu/via/car/cache_as_ram.inc(revision 5410) +++ src/cpu/via/car/cache_as_ram.inc(working copy) @@ -270,14 +270,16 @@ movl%ebp, %esi - /* FIXME: These values might have to change for suspend-to-ram. -* the 0x0040 was chosen as this is a place in memory that -* should exist in all contemporary configurations (ie. large -* enough RAM), but doesn't collide with anything coreboot does. -* Other than that, it's arbitrary. + /* For now: use CONFIG_RAMBASE + 1MB - 64K (counting downwards) as stack. This +* makes sure that we stay completely within the 1M-64K of memory that we +* preserve for suspend/resume. */ - movl$0x400, %esp +#ifndef HIGH_MEMORY_SAVE +#warning Need a central place for HIGH_MEMORY_SAVE +#define HIGH_MEMORY_SAVE ( (1024 - 64) * 1024 ) +#endif + movl $(CONFIG_RAMBASE + HIGH_MEMORY_SAVE), %esp movl%esp, %ebp pushl %esi call copy_and_run Index: src/arch/i386/init/crt0_romcc_epilogue.inc === --- src/arch/i386/init/crt0_romcc_epilogue.inc (revision 5410) +++ src/arch/i386/init/crt0_romcc_epilogue.inc (working copy) @@ -14,8 +14,16 @@ movl%ebp, %esi - /* FIXME: look for a proper place for the stack */ - movl$0x400, %esp + /* For now: use CONFIG_RAMBASE + 1MB - 64K (counting downwards) as stack. This +* makes sure that we stay completely within the 1M-64K of memory that we +* preserve for suspend/resume. +*/ + +#ifndef HIGH_MEMORY_SAVE +#warning Need a central place for HIGH_MEMORY_SAVE +#define HIGH_MEMORY_SAVE ( (1024 - 64) * 1024 ) +#endif + movl $(CONFIG_RAMBASE + HIGH_MEMORY_SAVE), %esp movl%esp, %ebp pushl %esi call copy_and_run -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] [PATCH] clean up some ld files.
See patch
--
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
Drop some unused stuff from the various ld scripts.
Signed-off-by: Stefan Reinauer ste...@coresystems.de
Index: src/arch/i386/init/ldscript_apc.lb
===
--- src/arch/i386/init/ldscript_apc.lb (revision 5410)
+++ src/arch/i386/init/ldscript_apc.lb (working copy)
@@ -1,4 +1,3 @@
-/* INPUT(coreboot_ap.rom)*/
INCLUDE ldoptions
SECTIONS
{
@@ -9,8 +8,4 @@
*(.rodata.*)
_eapcrom = .;
}
-_iseg_apc = CONFIG_DCACHE_RAM_BASE;
-_eiseg_apc = _iseg_apc + SIZEOF(.apcrom);
-_liseg_apc = _apcrom;
-_eliseg_apc = _eapcrom;
}
Index: src/arch/i386/init/ldscript_failover.lb
===
--- src/arch/i386/init/ldscript_failover.lb (revision 5410)
+++ src/arch/i386/init/ldscript_failover.lb (working copy)
@@ -1,29 +1,8 @@
-/*
- * Memory map:
- *
- * CONFIG_RAMBASE
- * : data segment
- * : bss segment
- * : heap
- * : stack
- * CONFIG_ROMBASE
- * : coreboot text
- * : readonly text
+/* Copyright (C) 2006 Yinghai Lu
+ * Copyright (C) 2008-2010 coresystems GmbH
*/
-/*
- * Bootstrap code for the STPC Consumer
- * Copyright (c) 1999 by Net Insight AB. All Rights Reserved.
- *
- */
-/*
- * Written by Johan Rydberg, based on work by Daniel Kahlin.
- * Rewritten by Eric Biederman
- */
-/*
- * We use ELF as output format. So that we can
- * debug the code in some form.
- */
+/* We use ELF as output format. So that we can debug the code in some form. */
OUTPUT_FORMAT(elf32-i386, elf32-i386, elf32-i386)
OUTPUT_ARCH(i386)
@@ -34,8 +13,6 @@
TARGET(binary)
SECTIONS
{
- . = 0;
-
/* This section might be better named .setup */
.rom ROMLOC : {
_rom = .;
@@ -44,7 +21,7 @@
*(.rom.data.*);
*(.rodata.*);
_erom = .;
- } rom =0xff
+ } rom = 0xff
ROMLOC = 0xff00 - (_erom - _rom) + 1;
Index: src/arch/i386/init/ldscript_fallback_cbfs.lb
===
--- src/arch/i386/init/ldscript_fallback_cbfs.lb(revision 5410)
+++ src/arch/i386/init/ldscript_fallback_cbfs.lb(working copy)
@@ -27,10 +27,6 @@
OUTPUT_FORMAT(elf32-i386, elf32-i386, elf32-i386)
OUTPUT_ARCH(i386)
-/*
-ENTRY(_start)
-*/
-
TARGET(binary)
SECTIONS
{
@@ -45,8 +41,6 @@
_rom = .;
*(.rom.text);
*(.rom.data);
- *(.init.rodata.*);
- *(.init.text);
*(.rodata);
*(.rodata.*);
*(.rom.data.*);
Index: src/arch/i386/coreboot_ram.ld
===
--- src/arch/i386/coreboot_ram.ld (revision 5410)
+++ src/arch/i386/coreboot_ram.ld (working copy)
@@ -39,6 +39,7 @@
. = ALIGN(16);
_etext = .;
}
+
.rodata : {
_rodata = .;
. = ALIGN(4);
@@ -57,7 +58,6 @@
/*
* kevinh/Ispiri - Added an align, because the objcopy tool
* incorrectly converts sections that are not long word aligned.
-* This breaks the coreboot.rom target.
*/
. = ALIGN(4);
@@ -76,16 +76,6 @@
_edata = .;
}
- .sdata : {
- _SDA_BASE_ = .;
- *(.sdata)
- }
-
- .sdata2 : {
- _SDA2_BASE_ = .;
- *(.sdata2)
- }
-
/*
* bss does not contain data, it is just a space that should be zero
* initialized on startup. (typically uninitialized global variables)
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH]Move cpu includes to cpus
Am 12.04.2010 17:18, schrieb Stefan Reinauer: These boards have the same CPU socket, thus should be able to use CAR: ./src/mainboard/dell/s1850/Kconfig: select CPU_INTEL_SOCKET_MPGA604 ./src/mainboard/intel/jarrell/Kconfig: select CPU_INTEL_SOCKET_MPGA604 ./src/mainboard/intel/xe7501devkit/Kconfig: select CPU_INTEL_SOCKET_MPGA604 ./src/mainboard/supermicro/x6dai_g/Kconfig: select CPU_INTEL_SOCKET_MPGA604 ./src/mainboard/supermicro/x6dhe_g/Kconfig: select CPU_INTEL_SOCKET_MPGA604 ./src/mainboard/supermicro/x6dhe_g2/Kconfig: select CPU_INTEL_SOCKET_MPGA604 ./src/mainboard/supermicro/x6dhr_ig/Kconfig: select CPU_INTEL_SOCKET_MPGA604 ./src/mainboard/supermicro/x6dhr_ig2/Kconfig: select CPU_INTEL_SOCKET_MPGA604 ./src/mainboard/tyan/s2735/Kconfig: select CPU_INTEL_SOCKET_MPGA604 I'm glad to provide a patch to convert these boards to CAE, if it can be tested on at least one of them. So if you have a board in this list, speak up! Having 9 more boards use CAR would be really nice to have. If/When you do, please also move src/cpu/x86/car to something more reasonable. It is _not_ generic x86 CAR. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] [commit] r5411 - in trunk/src: arch/i386 cpu/amd/model_gx1 cpu/amd/model_lx cpu/amd/socket_754 cpu/amd/socket_939 cpu/amd/socket_940 cpu/amd/socket_AM2 cpu/amd/socket_AM2r2 cpu/amd/socket_F
Author: oxygene Date: Mon Apr 12 17:28:34 2010 New Revision: 5411 URL: https://tracker.coreboot.org/trac/coreboot/changeset/5411 Log: Move the CPU specific includes from src/arch/i386/Makefile.inc to the respective CPU directories. Signed-off-by: Patrick Georgi patrick.geo...@coresystems.de Acked-by: Stefan Reinauer ste...@coresystems.de Deleted: trunk/src/cpu/x86/car/cache_as_ram.lds Modified: trunk/src/arch/i386/Makefile.inc trunk/src/cpu/amd/model_gx1/Makefile.inc trunk/src/cpu/amd/model_lx/Makefile.inc trunk/src/cpu/amd/socket_754/Makefile.inc trunk/src/cpu/amd/socket_939/Makefile.inc trunk/src/cpu/amd/socket_940/Makefile.inc trunk/src/cpu/amd/socket_AM2/Makefile.inc trunk/src/cpu/amd/socket_AM2r2/Makefile.inc trunk/src/cpu/amd/socket_F/Makefile.inc trunk/src/cpu/amd/socket_F_1207/Makefile.inc trunk/src/cpu/amd/socket_S1G1/Makefile.inc trunk/src/cpu/intel/bga956/Makefile.inc trunk/src/cpu/intel/model_106cx/Makefile.inc trunk/src/cpu/intel/model_6ex/Makefile.inc trunk/src/cpu/intel/socket_mFCBGA479/Makefile.inc trunk/src/cpu/via/model_c7/Makefile.inc Modified: trunk/src/arch/i386/Makefile.inc == --- trunk/src/arch/i386/Makefile.incMon Apr 12 12:22:20 2010(r5410) +++ trunk/src/arch/i386/Makefile.incMon Apr 12 17:28:34 2010(r5411) @@ -117,61 +117,17 @@ endif crt0s += $(src)/cpu/x86/fpu_enable.inc -ifeq ($(CONFIG_CPU_AMD_GX1),y) -crt0s += $(src)/cpu/amd/model_gx1/cpu_setup.inc -crt0s += $(src)/cpu/amd/model_gx1/gx_setup.inc -endif ifeq ($(CONFIG_SSE),y) crt0s += $(src)/cpu/x86/sse_enable.inc endif -ifeq ($(CONFIG_CPU_AMD_LX),y) -crt0s += $(src)/cpu/amd/model_lx/cache_as_ram.inc -endif -ifeq ($(CONFIG_CPU_AMD_SOCKET_F),y) -crt0s += $(src)/cpu/amd/car/cache_as_ram.inc -endif -ifeq ($(CONFIG_CPU_AMD_SOCKET_F_1207),y) -crt0s += $(src)/cpu/amd/car/cache_as_ram.inc -endif -ifeq ($(CONFIG_CPU_AMD_SOCKET_AM2R2),y) -crt0s += $(src)/cpu/amd/car/cache_as_ram.inc -endif -ifeq ($(CONFIG_CPU_AMD_SOCKET_AM2),y) -crt0s += $(src)/cpu/amd/car/cache_as_ram.inc -endif -ifeq ($(CONFIG_CPU_AMD_SOCKET_S1G1),y) -crt0s += $(src)/cpu/amd/car/cache_as_ram.inc -endif -ifeq ($(CONFIG_CPU_AMD_SOCKET_754),y) -crt0s += $(src)/cpu/amd/car/cache_as_ram.inc -endif -ifeq ($(CONFIG_CPU_AMD_SOCKET_939),y) -crt0s += $(src)/cpu/amd/car/cache_as_ram.inc -endif -ifeq ($(CONFIG_CPU_AMD_SOCKET_940),y) -crt0s += $(src)/cpu/amd/car/cache_as_ram.inc -endif -ifeq ($(CONFIG_CPU_INTEL_ATOM_230),y) -crt0s += $(src)/cpu/intel/model_106cx/cache_as_ram.inc -endif -ifeq ($(CONFIG_CPU_INTEL_CORE),y) -crt0s += $(src)/cpu/intel/model_6ex/cache_as_ram.inc -endif -# Use Intel Core (not Core 2) code for CAR init, any CPU might be used. -ifeq ($(CONFIG_CPU_INTEL_SOCKET_BGA956),y) -crt0s += $(src)/cpu/intel/model_6ex/cache_as_ram.inc -endif -ifeq ($(CONFIG_CPU_INTEL_SOCKET_MFCBGA479),y) -crt0s += $(src)/cpu/x86/car/cache_as_ram.inc -endif -ifeq ($(CONFIG_CPU_VIA_C7),y) -crt0s += $(src)/cpu/via/car/cache_as_ram.inc -endif -# who else could use this? +crt0s += $(cpu_incs) + +# +# FIXME move to CPU_INTEL_SOCKET_MPGA604 +# ifeq ($(CONFIG_BOARD_TYAN_S2735),y) crt0s += $(src)/cpu/x86/car/cache_as_ram.inc -ldscripts += $(src)/cpu/x86/car/cache_as_ram.lds endif ifeq ($(CONFIG_LLSHELL),y) Modified: trunk/src/cpu/amd/model_gx1/Makefile.inc == --- trunk/src/cpu/amd/model_gx1/Makefile.incMon Apr 12 12:22:20 2010 (r5410) +++ trunk/src/cpu/amd/model_gx1/Makefile.incMon Apr 12 17:28:34 2010 (r5411) @@ -23,3 +23,6 @@ subdirs-y += ../../x86/cache subdirs-y += ../../x86/smm driver-y += model_gx1_init.o + +cpu_incs += $(src)/cpu/amd/model_gx1/cpu_setup.inc +cpu_incs += $(src)/cpu/amd/model_gx1/gx_setup.inc Modified: trunk/src/cpu/amd/model_lx/Makefile.inc == --- trunk/src/cpu/amd/model_lx/Makefile.inc Mon Apr 12 12:22:20 2010 (r5410) +++ trunk/src/cpu/amd/model_lx/Makefile.inc Mon Apr 12 17:28:34 2010 (r5411) @@ -6,3 +6,5 @@ driver-y += model_lx_init.o obj-y += cpubug.o obj-y += vsmsetup.o + +cpu_incs += $(src)/cpu/amd/model_lx/cache_as_ram.inc Modified: trunk/src/cpu/amd/socket_754/Makefile.inc == --- trunk/src/cpu/amd/socket_754/Makefile.inc Mon Apr 12 12:22:20 2010 (r5410) +++ trunk/src/cpu/amd/socket_754/Makefile.inc Mon Apr 12 17:28:34 2010 (r5411) @@ -8,3 +8,5 @@ subdirs-y += ../../x86/cache subdirs-y += ../../x86/mtrr subdirs-y += ../../x86/pae + +cpu_incs += $(src)/cpu/amd/car/cache_as_ram.inc Modified: trunk/src/cpu/amd/socket_939/Makefile.inc == --- trunk/src/cpu/amd/socket_939/Makefile.inc Mon Apr 12 12:22:20 2010
[coreboot] [PATCH] cleanup model 6ex CAR
See patch
cpu/intel/model_6ex/cache_as_ram.inc | 83 ++-
cpu/intel/model_6ex/cache_as_ram_disable.c | 89
cpu/intel/model_6ex/cache_as_ram_post.c | 125 -
mainboard/kontron/986lcd-m/romstage.c | 4
mainboard/roda/rk886ex/romstage.c | 3
5 files changed, 82 insertions(+), 222 deletions(-)
--
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
move model_6ex car to a single file. No more .c files that only consist of a
single several pages long asm statement
Could use some renumbering of post codes, but that's good for another time.
Signed-off-by: Stefan Reinauer ste...@coresystems.de
Index: src/cpu/intel/model_6ex/cache_as_ram_disable.c
===
--- src/cpu/intel/model_6ex/cache_as_ram_disable.c (revision 5410)
+++ src/cpu/intel/model_6ex/cache_as_ram_disable.c (working copy)
@@ -1,89 +0,0 @@
-/*
- * This file is part of the coreboot project.
- *
- * Copyright (C) 2007-2009 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; 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
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- * GNU General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston,
- * MA 02110-1301 USA
- */
-
-#include arch/stages.h
-
-/* called from assembler code */
-void stage1_main(unsigned long bist);
-
-/* from romstage.c */
-void real_main(unsigned long bist);
-
-void stage1_main(unsigned long bist)
-{
- unsigned int cpu_reset = 0;
-
- real_main(bist);
-
- /* No servicable parts below this line .. */
-#ifdef CAR_DEBUG
-/* Check value of esp to verify if we have enough rom for stack in
Cache as RAM */
- unsigned v_esp;
- __asm__ volatile (
- movl %%esp, %0\n
- : =a (v_esp)
- );
- printk(BIOS_SPEW, v_esp=%08x\n, v_esp);
-#endif
-
-printk(BIOS_SPEW, cpu_reset = %08x\n, cpu_reset);
- printk(BIOS_SPEW, No cache as ram now - );
-
- /* store cpu_reset to ebx */
-__asm__ volatile (
-movl %0, %%ebx\n\t
-::a (cpu_reset)
-);
-
-#undef CLEAR_FIRST_1M_RAM
-#include cache_as_ram_post.c
-
- /* For now: use rambase + 1MB - 64K (counting downwards) as stack. This
-* makes sure that we stay completely within the 1M of memory we
-* preserve with the memcpy above.
-*/
-
-#ifndef HIGH_MEMORY_SAVE
-#define HIGH_MEMORY_SAVE ( (1024 - 64) * 1024 )
-#endif
-
- __asm__ volatile (
- movl %0, %%ebp\n
- movl %0, %%esp\n
- :: a (CONFIG_RAMBASE + HIGH_MEMORY_SAVE)
- );
-
- {
- unsigned new_cpu_reset;
-
- /* get back cpu_reset from ebx */
- __asm__ volatile (
- movl %%ebx, %0\n
- :=a (new_cpu_reset)
- );
-
- /* Copy and execute coreboot_ram */
- copy_and_run(new_cpu_reset);
- }
-
- /* We will not return */
- printk(BIOS_DEBUG, sorry. parachute did not open.\n);
-}
Index: src/cpu/intel/model_6ex/cache_as_ram_post.c
===
--- src/cpu/intel/model_6ex/cache_as_ram_post.c (revision 5410)
+++ src/cpu/intel/model_6ex/cache_as_ram_post.c (working copy)
@@ -1,125 +0,0 @@
-/*
- * This file is part of the coreboot project.
- *
- * Copyright (C) 2007-2008 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; 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
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- * GNU General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston,
- * MA 02110-1301 USA
- */
-
-__asm__ volatile (
-
- movb $0x30, %al\noutb %al, $0x80\n
-
- /* Disable Cache */
- movl %cr0, %eax\n
-
Re: [coreboot] [PATCH]Move cpu includes to cpus
Am 12.04.2010 17:18, schrieb Stefan Reinauer: These boards have the same CPU socket, thus should be able to use CAR: ./src/mainboard/dell/s1850/Kconfig: select CPU_INTEL_SOCKET_MPGA604 ./src/mainboard/intel/jarrell/Kconfig: select CPU_INTEL_SOCKET_MPGA604 ./src/mainboard/intel/xe7501devkit/Kconfig: select CPU_INTEL_SOCKET_MPGA604 ./src/mainboard/supermicro/x6dai_g/Kconfig: select CPU_INTEL_SOCKET_MPGA604 ./src/mainboard/supermicro/x6dhe_g/Kconfig: select CPU_INTEL_SOCKET_MPGA604 ./src/mainboard/supermicro/x6dhe_g2/Kconfig: select CPU_INTEL_SOCKET_MPGA604 ./src/mainboard/supermicro/x6dhr_ig/Kconfig: select CPU_INTEL_SOCKET_MPGA604 ./src/mainboard/supermicro/x6dhr_ig2/Kconfig: select CPU_INTEL_SOCKET_MPGA604 ./src/mainboard/tyan/s2735/Kconfig: select CPU_INTEL_SOCKET_MPGA604 I'm glad to provide a patch to convert these boards to CAE, if it can be tested on at least one of them. So if you have a board in this list, speak up! Having 9 more boards use CAR would be really nice to have. If/When you do, please also move src/cpu/x86/car to something more reasonable. It is _not_ generic x86 CAR. since we have amd/car and via/car (both not being amd generic, or via generic), would intel/car be a reasonable place (for now?) Stefan -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH]Move cpu includes to cpus
On 04/12/2010 10:16 AM, Patrick Georgi wrote: Hi, attached patch moves the CPU specific includes from src/arch/i386/Makefile.inc to the respective CPU directories. One exception is the tyan/s2735 rule, as this is a weird situation: Yes it is. I think it was just coverted over from v1 this way. I also think most of the CAR code embedded in it's romstage.c could be moved to a cache_as_ram_disable.c thus eliminating the weirdness. But we would need someone with the board to test it. I would be glad to whip up a patch if there is anyone out there willing to test? By the way Nice job Patrick, moving all this to cpu, makes life easier :-) -- 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]Move cpu includes to cpus
On 04/12/2010 11:42 AM, Stefan Reinauer wrote: Am 12.04.2010 17:18, schrieb Stefan Reinauer: These boards have the same CPU socket, thus should be able to use CAR: ./src/mainboard/dell/s1850/Kconfig: select CPU_INTEL_SOCKET_MPGA604 ./src/mainboard/intel/jarrell/Kconfig: select CPU_INTEL_SOCKET_MPGA604 ./src/mainboard/intel/xe7501devkit/Kconfig: select CPU_INTEL_SOCKET_MPGA604 ./src/mainboard/supermicro/x6dai_g/Kconfig: select CPU_INTEL_SOCKET_MPGA604 ./src/mainboard/supermicro/x6dhe_g/Kconfig: select CPU_INTEL_SOCKET_MPGA604 ./src/mainboard/supermicro/x6dhe_g2/Kconfig: select CPU_INTEL_SOCKET_MPGA604 ./src/mainboard/supermicro/x6dhr_ig/Kconfig: select CPU_INTEL_SOCKET_MPGA604 ./src/mainboard/supermicro/x6dhr_ig2/Kconfig: select CPU_INTEL_SOCKET_MPGA604 ./src/mainboard/tyan/s2735/Kconfig: select CPU_INTEL_SOCKET_MPGA604 I'm glad to provide a patch to convert these boards to CAE, if it can be tested on at least one of them. So if you have a board in this list, speak up! Having 9 more boards use CAR would be really nice to have. If/When you do, please also move src/cpu/x86/car to something more reasonable. It is _not_ generic x86 CAR. since we have amd/car and via/car (both not being amd generic, or via generic), would intel/car be a reasonable place (for now?) Is there any other brands that use src/cpu/x86/car or just intel? If just intel then I say yes to intel/car. -- 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] clean up some ld files.
Am 12.04.2010 17:25, schrieb Stefan Reinauer: See patch Acked-by: Patrick Georgi patrick.geo...@coresystems.de -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] #119: Winbond W39V040FBPZ is not written correctly by flashrom
#119: Winbond W39V040FBPZ is not written correctly by flashrom --+- Reporter: charles.hern...@… | Owner: somebody Type: enhancement | Status: closed Priority: minor | Milestone: flashrom v1.1 Component: flashrom (please use trac on flashrom.org) | Resolution: worksforme Keywords: W39V040FBPZ | Dependencies: Patchstatus: there is no patch | --+- Changes (by hailfinger): * status: new = closed * resolution: = worksforme Comment: We fixed a few bugs: - Erase is now an auto-verified operation (it wasn't in your flashrom version) - W39* toggle timings were fixed (those resulted in too early false completion reports) - More paranoia and better diagnostics in all steps of flashrom operation Charles, I will close this bug for now. Feel free to reopen it if you still own the hardware and are willing to test. -- Ticket URL: https://tracker.coreboot.org/trac/coreboot/ticket/119#comment:7 coreboot http://www.coreboot.org/ -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] #103: flashrom: Add -T to test all operations in one invocation
#103: flashrom: Add -T to test all operations in one invocation ---+ Reporter: stuge | Owner: hailfinger Type: enhancement |Status: assigned Priority: major | Milestone: flashrom v1.0 Component: flashrom (please use trac on flashrom.org) | Keywords: testing Dependencies: #117| Patchstatus: there is no patch ---+ Changes (by hailfinger): * status: new = assigned Comment: I have a patch for this, but it needs partial write support, and that will be added post 0.9.2. -- Ticket URL: https://tracker.coreboot.org/trac/coreboot/ticket/103#comment:13 coreboot http://www.coreboot.org/ -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] Doubts about necessity of propietary parts in the firmware
Hello. First things first: thank you all for working in coreboot, yet another free software project I wouldn't think possible if you hadn't made it real. I've been reading the archives and browsing coreboot.org, but I have little clue about firmware so I still have doubts I would like to clear beforing buying/building my next computer VGA BIOS . Is it necessary ?. I've seen some reports of using coreboot with a propietary VGA BIOS, either run from the graphics card ROM or reaped from the motherboard propietary BIOS. Is this an intermediate state in development and it is eventually replaced with free code ? or we're not there (yet?). Can one live without any VGA BIOS ? Leaving it out means coreboot boots blindly but then (a deblobed) linux/X initializes the graphics hardware all right and you have display just like with VGA BIOS, only later in the boot process ? Or the GPU can't be used without the propietary VGA BIOS ? Can GRUB display a menu without VGA BIOS ? (SGA BIOS doesn't seem useful here, since I don't want to use a serial link forever) Btw, can GRUB show background images without VGA BIOS ? Do these answers depend on the GPU or northbridge ? Double graphics is a problem ? As far as I know the only modern desktop class chipsets supported by the manufacturer, are AMD RS780/SB700 , am I wrong ? (thanks, AMD!). I think all come with an ATI IGP , which requires blobs in the linux/X driver (AtomBIOS). I may be misinformed on AtomBIOS, but I think I don't want to use it. I've heard nouveau has just deblobed its driver, so I might add an Nvidia graphics card to it (at least while Open Graphics Project isn't ready for consumers). I'll try to buy one second hand, as lesser evil, since I dislike buying directly from vendors not supporting free software. Does having both the ATI IGP and the Nvidia card give any additional complication ? (besides it's going to be less tested than more usual setups). I wish Intel supported coreboot or radeonhd didn't use AtomBIOS (like it once was). Any AMD RS780/SB700 boards roadmap ? Any hints which AMD RS780/SB700 boards are going to be supported first ? (I'm using the suggestions I see on the mailing list, but I've heard of GSoC potential effort and I don't know if there're priorities already set for it) DDR3 coming soon ? I've heard optimism on DDR3 but I believe it's not yet supported by coreboot. Do you have any estimation on how long can it take or how much would it cost if someone was to pay for it ? (I don't think I can pay, it's just to quantify the effort). For now I'm planning to avoid DDR3 just in case. I'm not sure it's a huge performance benefit. How to choose socketed boards ? How can one know whether a card has socketed or soldered BIOS ROMs besides looking at it or some photos ? Should it be in the specs or manual ? (I don't trust myself with a soldering iron). TPM I don't like Treacherous Computing and the like so I would prefer to buy a motherboard without TPM. If I can get coreboot to run then the TPM may become harmless, but I still don't want to encourage vendors to put TPM in. The question is, are there security benefits if you control the firmware, like you would eventually increase security by using your own keys, or are the keys hardwired and unreplaceable so that the best you can hope for is to disable them? I don't really know how many boards without TPM are in the market, anyway. Thanks for reading so far and sorry for abusing this list thus. I'm going to include a little background now, but your answers can help me even without you reading further. I'm a professional programmer, and I studied Enginyeria Tècnica de Sistemes Informàtics before completing it to Enginyeria Informàtica (that's a 3 years degree in computer systems engineering, followed with the courses to turn it into a 5 years degree in computing). But I wasn't really interested in electronics and we didn't see anything about firmware. I did some exercises in 8086 and M68000 assembler, some C for operating systems and so on, but I don't have professional experience on it. Never wrote drivers or so on. I've worked more on web apps, web services and business applications. So I hope I can learn enough to test things without bricking my board, but not really to help develop anything. I used to buy laptops with intel IGP, because they had free drivers but now that my current laptop is getting older I looked for current hardware and found out about Intel Active Management Technology and DASH by AMD et al, and from that I discovered SMM. I used to think the BIOS was a small piece of code that was only used for booting and I could then forget it, but now I'm a bit more afraid of remote control with propietary BIOSes. I would like a computer with as little propietary software as possible, but yet powerful enough to compile quick enough, and ideally able to run a couple of distributions virtualized to test stuff. Something like 4-8 Gb of RAM (8 -16
[coreboot] [PATCH] warning days - m57sli/mcp55
If there are better ways to kill the warnings, please let me know!
Thanks,
Ward.
--
Ward Vandewege w...@fsf.org
Free Software Foundation - Senior Systems Administrator
This fixes a number of warnings when building m57sli (and other boards with mcp55).
This patch is boot tested on m57sli.
What appears to be a shortening of the delay in
src/southbridge/nvidia/mcp55/mcp55_early_setup_car.c
is functionally exactly the same as before; the delayx function takes a uint8_t
argument, so the old value (1000 - 0x3E8) was truncated to 232 (0xE8).
Signed-off-by: Ward Vandewege w...@gnu.org
Index: src/southbridge/nvidia/mcp55/mcp55_fadt.c
===
--- src/southbridge/nvidia/mcp55/mcp55_fadt.c (revision 5411)
+++ src/southbridge/nvidia/mcp55/mcp55_fadt.c (working copy)
@@ -51,8 +51,8 @@
printk(BIOS_INFO, ACPI: pm_base: %u...\n, pm_base);
- fadt-firmware_ctrl = facs;
- fadt-dsdt = dsdt;
+ fadt-firmware_ctrl = (u32) facs;
+ fadt-dsdt = (u32) dsdt;
fadt-preferred_pm_profile = 1; //check
fadt-sci_int = 9;
/* disable system management mode by setting to 0 */
@@ -108,9 +108,9 @@
fadt-reset_reg.addrh = 0x0;
fadt-reset_value = 0;
- fadt-x_firmware_ctl_l = facs;
+ fadt-x_firmware_ctl_l = (u32) facs;
fadt-x_firmware_ctl_h = 0;
- fadt-x_dsdt_l = dsdt;
+ fadt-x_dsdt_l = (u32) dsdt;
fadt-x_dsdt_h = 0;
fadt-x_pm1a_evt_blk.space_id = 1;
Index: src/southbridge/nvidia/mcp55/mcp55_early_setup_car.c
===
--- src/southbridge/nvidia/mcp55/mcp55_early_setup_car.c (revision 5411)
+++ src/southbridge/nvidia/mcp55/mcp55_early_setup_car.c (working copy)
@@ -177,7 +177,7 @@
pci_write_config32(dev, 0xe4, dword);
// need to wait 100ms
- delayx(1000);
+ delayx(232);
}
static void mcp55_early_setup(unsigned mcp55_num, unsigned *busn, unsigned *devn, unsigned *io_base, unsigned *pci_e_x)
@@ -388,7 +388,7 @@
int mcp55_num = 0;
unsigned busnx;
unsigned devnx;
- int ht_c_index,j;
+ int ht_c_index;
/* FIXME: multi pci segment handling */
Index: src/mainboard/gigabyte/m57sli/fanctl.c
===
--- src/mainboard/gigabyte/m57sli/fanctl.c (revision 5411)
+++ src/mainboard/gigabyte/m57sli/fanctl.c (working copy)
@@ -71,6 +71,7 @@
/*
* Called from superio.c
*/
+extern void init_ec(uint16_t base);
void init_ec(uint16_t base)
{
int i;
Index: src/mainboard/gigabyte/m57sli/romstage.c
===
--- src/mainboard/gigabyte/m57sli/romstage.c (revision 5411)
+++ src/mainboard/gigabyte/m57sli/romstage.c (working copy)
@@ -146,7 +146,6 @@
static void sio_setup(void)
{
-unsigned value;
uint32_t dword;
uint8_t byte;
Index: src/northbridge/amd/amdk8/exit_from_self.c
===
--- src/northbridge/amd/amdk8/exit_from_self.c (revision 5411)
+++ src/northbridge/amd/amdk8/exit_from_self.c (working copy)
@@ -17,6 +17,8 @@
* Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
*/
+extern void exit_from_self(int controllers, const struct mem_controller *ctrl,
+struct sys_info *sysinfo);
void exit_from_self(int controllers, const struct mem_controller *ctrl,
struct sys_info *sysinfo)
{
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] ASUS M2V-TVM....
00K8T890 found at LDT 00 Agreed on width: 01 CPU programmed to HT freq: 05 VIA HT caps: 0075 00after enable_fid_change No other messages after this? What was wrong last time? Thanks, Rudolf -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH] Get rid of unaligned 32-bit config space read in mcd_d.c
On Mon, Apr 12, 2010 at 12:52 AM, Arne Georg Gleditsch arne.gledit...@numascale.com wrote: Hi, This patch removes a non-32-bit aligned Get_NB32 from src/northbridge/amd/amdmct/mct/mct_d.c. The actual behavior should be unchanged for I/O-based config space reads, but previous behavior was wrong for MMCFG-based config space reads. Perhaps we want pci_mmio_*_config* to enforce natural alignment as well? Signed-off-by: Arne Georg Gleditsch arne.gledit...@numascale.com -- Arne. Hi Arne, That code is doing something a little ugly to make the two cs registers use the one mask register. It was ported from a routine that assumed that GET_NB32() fixed the alignment. Maybe add a comment about why that is happening. Acked-by: Marc Jones marcj...@gmail.com I would also ack a change to: u32 Get_NB32(u32 dev, u32 reg) u32 Get_NB32(u32 dev, u32 reg) or to the pci_mmio_*_config* to do it since the pci_io* versions do. Marc -- http://se-eng.com -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH] warning days - m57sli/mcp55
This fixes a number of warnings when building m57sli (and other boards with
mcp55).
This patch is boot tested on m57sli.
What appears to be a shortening of the delay in
src/southbridge/nvidia/mcp55/mcp55_early_setup_car.c
is functionally exactly the same as before; the delayx function takes a
uint8_t
argument, so the old value (1000 - 0x3E8) was truncated to 232 (0xE8).
Signed-off-by: Ward Vandewege w...@gnu.org
Index: src/southbridge/nvidia/mcp55/mcp55_early_setup_car.c
===
--- src/southbridge/nvidia/mcp55/mcp55_early_setup_car.c (revision 5411)
+++ src/southbridge/nvidia/mcp55/mcp55_early_setup_car.c (working copy)
@@ -177,7 +177,7 @@
pci_write_config32(dev, 0xe4, dword);
// need to wait 100ms
- delayx(1000);
+ delayx(232);
}
it sounds a lot to do 0x8000 outb to wait 100us, but who knows...
I think it would be better to change the input type to something else
than uint8_t, supposedly unsigned as most other udelay functions.
Alternatively you could try if this works:
Index: src/southbridge/nvidia/mcp55/mcp55_early_setup_car.c
===
--- src/southbridge/nvidia/mcp55/mcp55_early_setup_car.c (revision 5411)
+++ src/southbridge/nvidia/mcp55/mcp55_early_setup_car.c (working copy)
@@ -131,15 +131,9 @@
}
-static void delayx(uint8_t value) {
-#if 1
- int i;
- for(i=0;i0x8000;i++) {
- outb(value, 0x80);
- }
-#endif
-}
+#include pc80/udelay_io.c
+
static void mcp55_early_pcie_setup(unsigned busnx, unsigned devnx,
unsigned anactrl_io_base, unsigned pci_e_x)
{
uint32_t tgio_ctrl;
@@ -170,14 +164,14 @@
outl(tgio_ctrl, anactrl_io_base + 0xcc);
// wait 100us
- delayx(1);
+ udelay(100);
dword = pci_read_config32(dev, 0xe4);
dword = ~(0x3f0); // enable
pci_write_config32(dev, 0xe4, dword);
// need to wait 100ms
- delayx(1000);
+ udelay(100 * 1000);
}
static void mcp55_early_setup(unsigned mcp55_num, unsigned *busn,
unsigned *devn, unsigned *io_base, unsigned *pci_e_x)
Index: src/mainboard/gigabyte/m57sli/fanctl.c
===
--- src/mainboard/gigabyte/m57sli/fanctl.c(revision 5411)
+++ src/mainboard/gigabyte/m57sli/fanctl.c(working copy)
@@ -71,6 +71,7 @@
/*
* Called from superio.c
*/
+extern void init_ec(uint16_t base);
void init_ec(uint16_t base)
{
int i;
init_ec() is the API between the superio drivers and the mainboard
drivers...
If this is a single hack, it's fine as it is.. If we're going to have an
API here, we should create a src/include/superio.h or some such
Index: src/northbridge/amd/amdk8/exit_from_self.c
===
--- src/northbridge/amd/amdk8/exit_from_self.c(revision 5411)
+++ src/northbridge/amd/amdk8/exit_from_self.c(working copy)
@@ -17,6 +17,8 @@
* Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
*/
+extern void exit_from_self(int controllers, const struct mem_controller
*ctrl,
+struct sys_info *sysinfo);
void exit_from_self(int controllers, const struct mem_controller *ctrl,
struct sys_info *sysinfo)
{
since this is a C file that is included in exactly one file,
raminit_f.c you could as well just mark the function static.
btw, for function prototypes the extern in not really needed. I keep
removing them from the tree, but if people think we should have them,
I'll try to be consistent and stop deleting them :-)
Stefan
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
Re: [coreboot] [PATCH] warning days - m57sli/mcp55
If there are better ways to kill the warnings, please let me know!
Index: src/mainboard/gigabyte/m57sli/fanctl.c
===
--- src/mainboard/gigabyte/m57sli/fanctl.c(revision 5411)
+++ src/mainboard/gigabyte/m57sli/fanctl.c(working copy)
@@ -71,6 +71,7 @@
/*
* Called from superio.c
*/
+extern void init_ec(uint16_t base);
void init_ec(uint16_t base)
{
int i;
I would ack the patch except for the added extern statements. I thought
extern was for functions and variables that are declared in another file.
I've been fixing the no previous prototype warnings in two ways:
1. declare the function static if it is only used in that file
2. Add a prototype in a header that is included in the file where the
function is defined and the file where it's used.
Thanks,
Myles
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] [commit] r5412 - in trunk/src: cpu/intel/model_6ex mainboard/kontron/986lcd-m mainboard/roda/rk886ex
Author: stepan Date: Tue Apr 13 01:04:29 2010 New Revision: 5412 URL: https://tracker.coreboot.org/trac/coreboot/changeset/5412 Log: move model_6ex car to a single file. No more .c files that only consist of a single several pages long asm statement Could use some renumbering of post codes, but that's good for another time. Signed-off-by: Stefan Reinauer ste...@coresystems.de Acked-by: Patrick Georgi patrick.geo...@coresystems.de Deleted: trunk/src/cpu/intel/model_6ex/cache_as_ram_disable.c trunk/src/cpu/intel/model_6ex/cache_as_ram_post.c Modified: trunk/src/cpu/intel/model_6ex/cache_as_ram.inc trunk/src/mainboard/kontron/986lcd-m/romstage.c trunk/src/mainboard/roda/rk886ex/romstage.c Modified: trunk/src/cpu/intel/model_6ex/cache_as_ram.inc == --- trunk/src/cpu/intel/model_6ex/cache_as_ram.inc Mon Apr 12 17:28:34 2010(r5411) +++ trunk/src/cpu/intel/model_6ex/cache_as_ram.inc Tue Apr 13 01:04:29 2010(r5412) @@ -137,12 +137,142 @@ post_code(0x23) - callstage1_main + /* Call romstage.c main function */ + callmain post_code(0x2f) -error: + + post_code(0x30) + + /* Disable Cache */ + movl%cr0, %eax + orl$(1 30), %eax + movl%eax, %cr0 + + post_code(0x31) + + /* Disable MTRR */ + movl$MTRRdefType_MSR, %ecx + rdmsr + andl$(~(1 11)), %eax + wrmsr + + post_code(0x31) + + invd +#if 0 + xorl%eax, %eax + xorl%edx, %edx + movl$MTRRphysBase_MSR(0), %ecx + wrmsr + movl$MTRRphysMask_MSR(0), %ecx + wrmsr + movl$MTRRphysBase_MSR(1), %ecx + wrmsr + movl$MTRRphysMask_MSR(1), %ecx + wrmsr +#endif + + post_code(0x33) + +#undef CLEAR_FIRST_1M_RAM +#ifdef CLEAR_FIRST_1M_RAM + post_code(0x34) + /* Enable Write Combining and Speculative Reads for the first 1MB */ + movl$MTRRphysBase_MSR(0), %ecx + movl$(0x | MTRR_TYPE_WRCOMB), %eax + xorl%edx, %edx + wrmsr + movl$MTRRphysMask_MSR(0), %ecx + movl$(~(1024*1024 -1) | (1 11)), %eax + movl$0x000f, %edx // 36bit address space + wrmsr + post_code(0x35) +#endif + + /* Enable Cache */ + movl%cr0, %eax + andl$~( (1 30) | (1 29) ), %eax + movl%eax, %cr0 + + + post_code(0x36) +#ifdef CLEAR_FIRST_1M_RAM + + /* Clear first 1MB of RAM */ + movl$0x, %edi + cld + xorl%eax, %eax + movl$((1024*1024) / 4), %ecx + rep stosl + + post_code(0x37) +#endif + + /* Disable Cache */ + movl%cr0, %eax + orl$(1 30), %eax + movl%eax, %cr0 + + post_code(0x38) + + /* Enable Write Back and Speculative Reads for the first 1MB */ + movl$MTRRphysBase_MSR(0), %ecx + movl$(0x | MTRR_TYPE_WRBACK), %eax + xorl%edx, %edx + wrmsr + movl$MTRRphysMask_MSR(0), %ecx + movl$(~(1024*1024 -1) | (1 11)), %eax + movl$0x000f, %edx // 36bit address space + wrmsr + + post_code(0x39) + + /* And Enable Cache again after setting MTRRs */ + movl%cr0, %eax + andl$~( (1 30) | (1 29) ), %eax + movl%eax, %cr0 + + post_code(0x3a) + + /* Enable MTRR */ + movl$MTRRdefType_MSR, %ecx + rdmsr + orl $(1 11), %eax + wrmsr + + post_code(0x3b) + + /* Invalidate the cache again */ + invd + + + /* clear boot_complete flag */ + xorl%ebp, %ebp +__main: + post_code(0x11) + cld /* clear direction flag */ + + movl%ebp, %esi + + /* For now: use CONFIG_RAMBASE + 1MB - 64K (counting downwards) as stack. This +* makes sure that we stay completely within the 1M-64K of memory that we +* preserve for suspend/resume. +*/ + +#ifndef HIGH_MEMORY_SAVE +#warning Need a central place for HIGH_MEMORY_SAVE +#define HIGH_MEMORY_SAVE ( (1024 - 64) * 1024 ) +#endif + movl $(CONFIG_RAMBASE + HIGH_MEMORY_SAVE), %esp + movl%esp, %ebp + pushl %esi + call copy_and_run + +.Lhlt: + post_code(0xee) hlt - jmp error + jmp .Lhlt mtrr_table: /* Fixed MTRRs */ Modified: trunk/src/mainboard/kontron/986lcd-m/romstage.c == --- trunk/src/mainboard/kontron/986lcd-m/romstage.c Mon Apr 12 17:28:34 2010(r5411) +++ trunk/src/mainboard/kontron/986lcd-m/romstage.c Tue Apr 13 01:04:29 2010(r5412) @@ -359,9 +359,7 @@ // #include lib/cbmem.c -#include cpu/intel/model_6ex/cache_as_ram_disable.c - -void
[coreboot] [commit] r5413 - in trunk/src/cpu/intel: model_6ex model_6fx
Author: stepan Date: Tue Apr 13 01:12:15 2010 New Revision: 5413 URL: https://tracker.coreboot.org/trac/coreboot/changeset/5413 Log: port latest model 6ex car changes to 6fx car, which is almost identical and currently unused. Just keep it in sync, we might need it some day. Signed-off-by: Stefan Reinauer ste...@coresystems.de Acked-by: Stefan Reinauer ste...@coresystems.de Deleted: trunk/src/cpu/intel/model_6fx/cache_as_ram_disable.c trunk/src/cpu/intel/model_6fx/cache_as_ram_post.c Modified: trunk/src/cpu/intel/model_6ex/cache_as_ram.inc trunk/src/cpu/intel/model_6fx/cache_as_ram.inc Modified: trunk/src/cpu/intel/model_6ex/cache_as_ram.inc == --- trunk/src/cpu/intel/model_6ex/cache_as_ram.inc Tue Apr 13 01:04:29 2010(r5412) +++ trunk/src/cpu/intel/model_6ex/cache_as_ram.inc Tue Apr 13 01:12:15 2010(r5413) @@ -246,6 +246,7 @@ /* Invalidate the cache again */ invd + post_code(0x3c) /* clear boot_complete flag */ xorl%ebp, %ebp Modified: trunk/src/cpu/intel/model_6fx/cache_as_ram.inc == --- trunk/src/cpu/intel/model_6fx/cache_as_ram.inc Tue Apr 13 01:04:29 2010(r5412) +++ trunk/src/cpu/intel/model_6fx/cache_as_ram.inc Tue Apr 13 01:12:15 2010(r5413) @@ -144,12 +144,150 @@ post_code(0x23) - callstage1_main + /* Call romstage.c main function */ + callmain post_code(0x2f) -error: + + post_code(0x30) + + /* Disable Cache */ + movl%cr0, %eax + orl$(1 30), %eax + movl%eax, %cr0 + + post_code(0x31) + + /* Disable MTRR */ + movl$MTRRdefType_MSR, %ecx + rdmsr + andl$(~(1 11)), %eax + wrmsr + + post_code(0x31) + + invd +#if 0 + xorl%eax, %eax + xorl%edx, %edx + movl$MTRRphysBase_MSR(0), %ecx + wrmsr + movl$MTRRphysMask_MSR(0), %ecx + wrmsr + movl$MTRRphysBase_MSR(1), %ecx + wrmsr + movl$MTRRphysMask_MSR(1), %ecx + wrmsr +#endif + + post_code(0x33) + +#undef CLEAR_FIRST_1M_RAM +#ifdef CLEAR_FIRST_1M_RAM + post_code(0x34) + /* Enable Write Combining and Speculative Reads for the first 1MB */ + movl$MTRRphysBase_MSR(0), %ecx + movl$(0x | MTRR_TYPE_WRCOMB), %eax + xorl%edx, %edx + wrmsr + movl$MTRRphysMask_MSR(0), %ecx + movl$(~(1024*1024 -1) | (1 11)), %eax + movl$0x000f, %edx // 36bit address space + wrmsr + post_code(0x35) +#endif + + /* Enable Cache */ + movl%cr0, %eax + andl$~( (1 30) | (1 29) ), %eax + movl%eax, %cr0 + + + post_code(0x36) +#ifdef CLEAR_FIRST_1M_RAM + + /* Clear first 1MB of RAM */ + movl$0x, %edi + cld + xorl%eax, %eax + movl$((1024*1024) / 4), %ecx + rep stosl + + post_code(0x37) +#endif + + /* Disable Cache */ + movl%cr0, %eax + orl$(1 30), %eax + movl%eax, %cr0 + + post_code(0x38) + + /* Enable Write Back and Speculative Reads for the first 1MB */ + movl$MTRRphysBase_MSR(0), %ecx + movl$(0x | MTRR_TYPE_WRBACK), %eax + xorl%edx, %edx + wrmsr + movl$MTRRphysMask_MSR(0), %ecx + movl$(~(1024*1024 -1) | (1 11)), %eax + movl$0x000f, %edx // 36bit address space + wrmsr + + post_code(0x39) + + /* And Enable Cache again after setting MTRRs */ + movl%cr0, %eax + andl$~( (1 30) | (1 29) ), %eax + movl%eax, %cr0 + + post_code(0x3a) + + /* Enable MTRR */ + movl$MTRRdefType_MSR, %ecx + rdmsr + orl $(1 11), %eax + wrmsr + + post_code(0x3b) + + /* Enable prefetchers */ + movl$0x01a0, %ecx + rdmsr + andl$~((1 9) | (1 19)), %eax + andl$~((1 5) | (1 7)), %edx + wrmsr + + /* Invalidate the cache again */ + invd + + post_code(0x3c) + + /* clear boot_complete flag */ + xorl%ebp, %ebp +__main: + post_code(0x11) + cld /* clear direction flag */ + + movl%ebp, %esi + + /* For now: use CONFIG_RAMBASE + 1MB - 64K (counting downwards) as stack. This +* makes sure that we stay completely within the 1M-64K of memory that we +* preserve for suspend/resume. +*/ + +#ifndef HIGH_MEMORY_SAVE +#warning Need a central place for HIGH_MEMORY_SAVE +#define HIGH_MEMORY_SAVE ( (1024 - 64) * 1024 ) +#endif + movl $(CONFIG_RAMBASE + HIGH_MEMORY_SAVE), %esp + movl%esp, %ebp + pushl %esi + call
[coreboot] build service results for r5412
Dear coreboot readers! This is the automatic build system of coreboot. The developer stepan checked in revision 5412 to the coreboot repository. This caused the following changes: Change Log: move model_6ex car to a single file. No more .c files that only consist of a single several pages long asm statement Could use some renumbering of post codes, but that's good for another time. Signed-off-by: Stefan Reinauer ste...@coresystems.de Acked-by: Patrick Georgi patrick.geo...@coresystems.de Build Log: Compilation of intel:eagleheights has been broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=5412device=eagleheightsvendor=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
Re: [coreboot] [PATCH] Istanbul support
On Mon, Apr 12, 2010 at 3:28 AM, Arne Georg Gleditsch arne.gledit...@numascale.com wrote: My only remaining real issue is that parts of the nvidia mcp55 init code will not run properly using mmconf. The offending line is RES_PCI_IO, PCI_ADDR(0, 1, 0, 0x78), 0xC0FF, 0x1900, which causes the operations pci_read_config32: 0001:0078: 2004 pci_write_config32: 0001:0078: 1904 the second of which never returns when executed using mmconf. I'm speculating that this might be related to missing HT responses or something due to bus reconfiguration. As far as I can tell the device being targeted here is 10de:0364 (ISA bridge: nVidia Corporation MCP55 LPC Bridge). Anoyone familiar with the mcp55 who can shed some light on what this write is supposed to accomplish and perhaps also on why it succeeds using the IO config mechanism when mmconf fails? That write has always caused a hang on Arista boards, even using plain IO accesses. I have no idea what it's supposed to do, but we've left it commented out with no apparent ill effects. (Which reminds me that I need to port our patches to a modern version of Coreboot one of these days...) --Ed -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] build service results for r5413
Dear coreboot readers! This is the automatic build system of coreboot. The developer stepan checked in revision 5413 to the coreboot repository. This caused the following changes: Change Log: port latest model 6ex car changes to 6fx car, which is almost identical and currently unused. Just keep it in sync, we might need it some day. Signed-off-by: Stefan Reinauer ste...@coresystems.de Acked-by: Stefan Reinauer ste...@coresystems.de Build Log: Compilation of intel:eagleheights is still broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=5413device=eagleheightsvendor=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
Re: [coreboot] [PATCH] Istanbul support
(Which reminds me that I need to port our patches to a modern version of Coreboot one of these days...) --Ed Yes, Ed alot has changed, it would be great to see. -- Thanks, Joseph Smith Set-Top-Linux www.settoplinux.org -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] [commit] r5415 - in trunk/src: cpu/intel/model_106cx mainboard/intel/d945gclf
Author: stepan Date: Tue Apr 13 02:11:59 2010 New Revision: 5415 URL: https://tracker.coreboot.org/trac/coreboot/changeset/5415 Log: update atom car code in the same way that 6ex/6fx was updated. Signed-off-by: Stefan Reinauer ste...@coresystems.de Acked-by: Stefan Reinauer ste...@coresystems.de Deleted: trunk/src/cpu/intel/model_106cx/cache_as_ram_disable.c trunk/src/cpu/intel/model_106cx/cache_as_ram_post.c Modified: trunk/src/cpu/intel/model_106cx/cache_as_ram.inc trunk/src/mainboard/intel/d945gclf/romstage.c Modified: trunk/src/cpu/intel/model_106cx/cache_as_ram.inc == --- trunk/src/cpu/intel/model_106cx/cache_as_ram.incTue Apr 13 02:02:20 2010(r5414) +++ trunk/src/cpu/intel/model_106cx/cache_as_ram.incTue Apr 13 02:11:59 2010(r5415) @@ -35,8 +35,6 @@ movl $0xFEE00300, %esi movl %eax, (%esi) - post_code(0x21) - /* Zero out all Fixed Range and Variable Range MTRRs */ movl$mtrr_table, %esi movl$( (mtrr_table_end - mtrr_table) / 2), %edi @@ -49,7 +47,6 @@ add $2, %esi dec %edi jnz clear_mtrrs - post_code(0x22) /* Configure the default memory type to uncacheable */ movl$MTRRdefType_MSR, %ecx @@ -57,42 +54,36 @@ andl$(~0x0cff), %eax wrmsr - post_code(0x23) /* Set cache as ram base address */ movl$(MTRRphysBase_MSR(0)), %ecx movl$(CACHE_AS_RAM_BASE | MTRR_TYPE_WRBACK), %eax xorl%edx, %edx wrmsr - post_code(0x24) /* Set cache as ram mask */ movl$(MTRRphysMask_MSR(0)), %ecx movl$(~((CACHE_AS_RAM_SIZE-1)) | (1 11)), %eax xorl%edx, %edx wrmsr - post_code(0x25) /* Enable MTRR */ movl$MTRRdefType_MSR, %ecx rdmsr orl $(1 11), %eax wrmsr - post_code(0x26) /* Enable L2 Cache */ movl$0x11e, %ecx rdmsr orl $(1 8), %eax wrmsr - post_code(0x27) /* CR0.CD = 0, CR0.NW = 0 */ movl %cr0, %eax andl$( ~( (1 30) | (1 29) ) ), %eax invd movl%eax, %cr0 - post_code(0x28) /* Clear the cache memory reagion */ movl$CACHE_AS_RAM_BASE, %esi movl%esi, %edi @@ -101,7 +92,6 @@ xorl%eax, %eax rep stosl - post_code(0x29) /* Enable Cache As RAM mode by disabling cache */ movl%cr0, %eax orl $(1 30), %eax @@ -110,7 +100,7 @@ #if defined(CONFIG_XIP_ROM_SIZE) defined(CONFIG_XIP_ROM_BASE) /* Enable cache for our code in Flash because we do XIP here */ movl$MTRRphysBase_MSR(1), %ecx - xorl%edx, %edx +xorl%edx, %edx #if defined(CONFIG_TINY_BOOTBLOCK) CONFIG_TINY_BOOTBLOCK #define REAL_XIP_ROM_BASE AUTO_XIP_ROM_BASE #else @@ -126,7 +116,6 @@ wrmsr #endif /* CONFIG_XIP_ROM_SIZE CONFIG_XIP_ROM_BASE */ - post_code(0x2a) /* enable cache */ movl %cr0, %eax andl$( ~( (1 30) | (1 29) ) ), %eax @@ -148,12 +137,143 @@ post_code(0x23) - callstage1_main + /* Call romstage.c main function */ + callmain post_code(0x2f) -error: + + post_code(0x30) + + /* Disable Cache */ + movl%cr0, %eax + orl$(1 30), %eax + movl%eax, %cr0 + + post_code(0x31) + + /* Disable MTRR */ + movl$MTRRdefType_MSR, %ecx + rdmsr + andl$(~(1 11)), %eax + wrmsr + + post_code(0x31) + + invd +#if 0 + xorl%eax, %eax + xorl%edx, %edx + movl$MTRRphysBase_MSR(0), %ecx + wrmsr + movl$MTRRphysMask_MSR(0), %ecx + wrmsr + movl$MTRRphysBase_MSR(1), %ecx + wrmsr + movl$MTRRphysMask_MSR(1), %ecx + wrmsr +#endif + + post_code(0x33) + +#undef CLEAR_FIRST_1M_RAM +#ifdef CLEAR_FIRST_1M_RAM + post_code(0x34) + /* Enable Write Combining and Speculative Reads for the first 1MB */ + movl$MTRRphysBase_MSR(0), %ecx + movl$(0x | MTRR_TYPE_WRCOMB), %eax + xorl%edx, %edx + wrmsr + movl$MTRRphysMask_MSR(0), %ecx + movl$(~(1024*1024 -1) | (1 11)), %eax + xorl%edx, %edx + wrmsr + post_code(0x35) +#endif + + /* Enable Cache */ + movl%cr0, %eax + andl$~( (1 30) | (1 29) ), %eax + movl%eax, %cr0 + + + post_code(0x36) +#ifdef CLEAR_FIRST_1M_RAM + + /* Clear first 1MB of RAM */ + movl$0x, %edi + cld + xorl%eax, %eax + movl$((1024*1024) / 4), %ecx + rep stosl + + post_code(0x37) +#endif + + /* Disable Cache */ + movl
[coreboot] build service results for r5414
Dear coreboot readers! This is the automatic build system of coreboot. The developer stepan checked in revision 5414 to the coreboot repository. This caused the following changes: Change Log: Fix eagleheights not a 6ex board, but using the same CAR code. Signed-off-by: Stefan Reinauer ste...@coresystems.de Acked-by: Stefan Reinauer ste...@coresystems.de Build Log: Compilation of intel:eagleheights 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] Console ports and Coreboot versions
Hello! Here's the issue: Dating over a period of about two to three weeks, and averaging about three messages per time period about two years ago September to October, happen to be a serial about just that. The group was discussing the issue concerning the impending (by that time) disappearance of the serial port from the selected boards. And they were looking into a series of interesting hacks, one was applying the technology behind the PS/2 port, one other concerned a floppy drive connector. And even the parallel port was considered. Even the SMBUS was looked at. As of this past week the links in the messages have died so there isn't a reference for the gizmo described that enables a PS/2 keyboard style connector to be connected to a USB style port. Or perhaps the reverse is true. Using it someone could plug a USB key or flash drive into a PS/2 keyboard connector. As I understand it, it looks something like the USB Debug device described sometime ago, except for the fact that one end contained the PS/2 connection. This concerned the V3 port or build or release of Coreboot. Since the reasons why I initially got involved with the entire product from its early days as LinuxBIOS to right now with everyone working with different ideas for Coreboot moving towards a reality are summed up in that serial I decided to label it. Basically folks I have an interest in strange things like that, and of course regular computer electronics as such I decided today to ask about it. - Gregg C Levine gregg.drw...@gmail.com This signature fought the Time Wars, time and again. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH] stack location
On Mon, Apr 12, 2010 at 05:23:34PM +0200, Stefan Reinauer wrote: see patch. Not sure if this area is cached, but I think it should be, none the less. Thanks! That brings the early timings on epia-cn to: 00.000: 00 00.005: 00 00.382: 0 00.382: 00.382: coreboot-4.0-r5415M Mon Apr 12 20:37:07 EDT 2010 starting... 00.383: *pre enable_smbus() 00.405: *post enable_smbus() 00.409: *pre ddr_ram_setup() 00.420: *post ddr_ram_setup() 00.423: Stage: loading fallback/coreboot_ram @ 0x4000 (163840 bytes), entry @ 0x4000 00.469: coreboot-4.0-r5415M Mon Apr 12 20:37:07 EDT 2010 rebooting... The romcc code is a little faster (~16ms), but that's only because I hacked it to read the coreboot_ram file into cache while waiting for the smbus power well to stabilize. (With car it isn't possible to seed the cache, but that's not a big deal.) -Kevin -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH] VIA C7 CAR fixes / cleanup
On Mon, Apr 12, 2010 at 04:21:34PM +0200, Patrick Georgi wrote: Am 12.04.2010 15:39, schrieb Kevin O'Connor: On Mon, Apr 12, 2010 at 11:56:45AM +0200, Patrick Georgi wrote: If we: - Move the intermediate stack to wherever the ramstage stack resides (somewhere close to RAMTOP), - change the stage loaders (copy and ulzma) to leave out %esp..RAMTOP (with some safety margin below %esp), which should always be 0 anyway, and - enable caching for RAMBASE..RAMTOP (already done, I think) I didn't understand the first two points. The third point makes sense It seems that the stack is usually close to RAMTOP. We'd have to make sure that it's at a deterministic position (ie. == RAMTOP) and avoid overwriting that stack on decompression, then we could reuse the ramstage stack location for uncompression. Ahh - okay. I was getting the ramstage confused with romstage. - right now on my board RAMBASE is 0x4000 Most boards have RAMBASE at 1MB (or 2MB in some cases). RAMBASE at 16K is only left for a couple of boards that rely on their own vgabios handling. Two things should happen (if someone with the board finds the time): 1. removal of the custom vgabios handling, using oprom instead 2. moving RAMBASE to 1MB Agreed. if we make sure to cache everything up to RAMTOP and then place the ulzma stack somewhere in that memory range I think it should work. That somewhere could be the stack location of the ramstage. Makes sense. Right now, the code in src/cpu/via/car/cache_as_ram.inc isn't setting up the cache using RAMBASE or RAMTOP - it just does it's own range (which I think is the first 1Meg and a small part of flash) - it's the Might be good to change this at some point. Agreed. -Kevin -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] [commit] r5416 - trunk/util/superiotool
Author: uwe
Date: Tue Apr 13 03:22:20 2010
New Revision: 5416
URL: https://tracker.coreboot.org/trac/coreboot/changeset/5416
Log:
Add support for the SMSC FDC37C932 Super I/O.
This chip is found e.g. in the Nokia IP330 (firewall hardware).
Signed-off-by: Marc Bertens mbert...@xs4all.nl
Acked-by: Uwe Hermann u...@hermann-uwe.de
Modified:
trunk/util/superiotool/smsc.c
Modified: trunk/util/superiotool/smsc.c
==
--- trunk/util/superiotool/smsc.c Tue Apr 13 02:11:59 2010(r5415)
+++ trunk/util/superiotool/smsc.c Tue Apr 13 03:22:20 2010(r5416)
@@ -29,6 +29,46 @@
static const struct superio_registers reg_table[] = {
/* The following Super I/Os use the 0x20/0x21 ID registers. */
+ {0x02, FDC37C932, {
+ {NOLDN, NULL,
+ {0x02,0x03,0x20,0x21,0x22,0x23,0x24,0x2d,0x2e,
+0x2f,EOT},
+ {0x00,0x03,0x02,0x01,0x00,0x00,0x04,NANA,NANA,
+0x00,EOT}},
+ {0x0, Floppy,
+ {0x30,0x60,0x61,0x70,0x74,0xf0,0xf1,0xf2,0xf4,
+0xf5,EOT},
+ {0x00,0x03,0xf0,0x06,0x02,0x0e,0x00,0xff,0x00,
+0x00,EOT}},
+ {0x1, IDE 1,
+ {0x30,0x60,0x61,0x62,0x63,0x70,EOT},
+ {0x00,0x01,0xf0,0x03,0xf6,0x0e,EOT}},
+ {0x2, IDE 2,
+ {0x30,0x60,0x61,0x62,0x63,0x70,0xf0,EOT},
+ {0x00,0x00,0x00,0x00,0x00,0x00,0x00,EOT}},
+ {0x3, Parallel port,
+ {0x30,0x60,0x61,0x70,0x74,0xf0,EOT},
+ {0x00,0x00,0x00,0x00,0x04,0x3c,EOT}},
+ {0x4, COM1,
+ {0x30,0x60,0x61,0x70,0xf0,EOT},
+ {0x00,0x00,0x00,0x00,0x00,EOT}},
+ {0x5, COM2,
+ {0x30,0x60,0x61,0x70,0xf0,0xf1,EOT},
+ {0x00,0x00,0x00,0x00,0x00,0x00,EOT}},
+ {0x6, Real-time clock (RTC),
+ {0x30,0x70,0xf0,0xf1,0xf2,0xf3,0xf4,0xf5,0xf6,EOT},
+ {0x00,0x00,0x00,0x00,0x00,NANA,MISC,NANA,NANA,EOT}},
+ {0x7, Keyboard,
+ {0x30,0x70,0x72,EOT},
+ {0x00,0x00,0x00,EOT}},
+ {0x8, Aux I/O,
+ {0x30,0x60,0x61,0x62,0x63,0xe0,0xe1,0xe2,0xe3,0xe4,
+0xe5,0xe6,0xe7,0xe8,0xe9,0xea,0xeb,0xec,0xed,0xf0,
+0xf1,0xf2,0xf3,0xf4,EOT},
+ {0x00,0x00,0x00,0x00,0x00,0x01,0x01,0x01,0x01,0x01,
+0x01,0x01,0x01,0x01,0x01,0x01,0x01,0x01,0x01,0x00,
+0x00,0x00,0x00,MISC,EOT}},
+ {EOT}}},
{0x03, FDC37C93xFR, {
/* FIXME: There's another 0x03 but found on port 0x0d/0x0e! */
{EOT}}},
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
