[coreboot] [commit] r5147 - trunk/src/mainboard/msi/ms7135
Author: oxygene Date: Tue Feb 23 11:18:43 2010 New Revision: 5147 URL: http://tracker.coreboot.org/trac/coreboot/changeset/5147 Log: Adjust msi/ms7135 DCACHE_RAM_* config to previous 32KiB values, 4KiB is not enough to work. Additionally, modify the device tree so that the undocumented LDN 6 is ignored by the resource allocator, and while here, assign the parallel port DRQ, hardware monitor IRQ and drop NIC MAC address on SMBus EEPROM hint, the ms7135 doesn't have such hardware. Signed-off-by: Jonathan A. Kollasch jakll...@kollasch.net Acked-by: Patrick Georgi patrick.geo...@coresystems.de Modified: trunk/src/mainboard/msi/ms7135/Kconfig trunk/src/mainboard/msi/ms7135/devicetree.cb Modified: trunk/src/mainboard/msi/ms7135/Kconfig == --- trunk/src/mainboard/msi/ms7135/Kconfig Mon Feb 22 17:41:49 2010 (r5146) +++ trunk/src/mainboard/msi/ms7135/Kconfig Tue Feb 23 11:18:43 2010 (r5147) @@ -109,10 +109,10 @@ config DCACHE_RAM_BASE hex - default 0xcf000 + default 0xc8000 depends on BOARD_MSI_MS7135 config DCACHE_RAM_SIZE hex - default 0x1000 + default 0x8000 depends on BOARD_MSI_MS7135 Modified: trunk/src/mainboard/msi/ms7135/devicetree.cb == --- trunk/src/mainboard/msi/ms7135/devicetree.cbMon Feb 22 17:41:49 2010(r5146) +++ trunk/src/mainboard/msi/ms7135/devicetree.cbTue Feb 23 11:18:43 2010(r5147) @@ -21,6 +21,7 @@ device pnp 4e.1 on # Parallel port io 0x60 = 0x378 irq 0x70 = 7 +drq 0x74 = 3 end device pnp 4e.2 on # Com1 io 0x60 = 0x3f8 @@ -36,13 +37,14 @@ irq 0x70 = 1 irq 0x72 = 12 end + device pnp 4e.6 off end # XXX keep allocator happy device pnp 4e.7 off end # Game, MIDI, GPIO 1, GPIO 5 device pnp 4e.8 off end # GPIO 2 device pnp 4e.9 off end # GPIO 3, GPIO 4 device pnp 4e.a off end # ACPI device pnp 4e.b on # Hardware monitor io 0x60 = 0x290 -irq 0x70 = 0 +irq 0x70 = 5 end end end @@ -64,8 +66,6 @@ register ide1_enable = 1 register sata0_enable = 1 register sata1_enable = 1 - # register mac_eeprom_smbus = 3 - # register mac_eeprom_addr = 0x51 end end device pci 18.1 on end -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [patch] ms7135 fixes, updates
Am 13.02.2010 01:07, schrieb Jonathan A. Kollasch: Signed-off-by: Jonathan A. Kollasch jakll...@kollasch.net Acked-by: Patrick Georgi patrick.geo...@coresystems.de and committed as r5147 Thanks, Patrick -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] [commit] r5148 - trunk/src/mainboard/asus/m2v-mx_se
Author: oxygene Date: Tue Feb 23 11:22:37 2010 New Revision: 5148 URL: http://tracker.coreboot.org/trac/coreboot/changeset/5148 Log: Disable ACPI Resume on asus/m2v-mx_se, it's broken since cbmem Signed-off-by: Rudolf Marek r.ma...@assembler.cz Acked-by: Stefan Reinauer ste...@coresystems.de Modified: trunk/src/mainboard/asus/m2v-mx_se/Kconfig Modified: trunk/src/mainboard/asus/m2v-mx_se/Kconfig == --- trunk/src/mainboard/asus/m2v-mx_se/Kconfig Tue Feb 23 11:18:43 2010 (r5147) +++ trunk/src/mainboard/asus/m2v-mx_se/Kconfig Tue Feb 23 11:22:37 2010 (r5148) @@ -32,7 +32,6 @@ select HAVE_HARD_RESET select HAVE_OPTION_TABLE select HAVE_ACPI_TABLES - select HAVE_ACPI_RESUME select BOARD_ROMSIZE_KB_512 select VGA select TINY_BOOTBLOCK -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH] remove support for the S3 on M2V-MX SE
Am 21.02.2010 23:08, schrieb Rudolf Marek: Anyway, disabling the suspend/resume now. Its broken. Either cbmem stuff needs to be fixed, or old functionality for suspend/resume with hole must be restored, Could you go to some detail as how cbmem must be fixed for your board? I'd prefer that over special solutions for single boards. Signed-off-by: Rudolf Marek r.ma...@assembler.cz Committed in r5148. Thanks, Patrick -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] [commit] r5149 - trunk
Author: oxygene Date: Tue Feb 23 11:33:25 2010 New Revision: 5149 URL: http://tracker.coreboot.org/trac/coreboot/changeset/5149 Log: Find out the svnversion we are working on is quite important. The whole command (which also parses git data, if it's a git-svn tree) is copied from original newconfig. Signed-off-by: Zheng Bao zheng@amd.com Acked-by: Patrick Georgi patrick.geo...@coresystems.de Modified: trunk/Makefile Modified: trunk/Makefile == --- trunk/Makefile Tue Feb 23 11:22:37 2010(r5148) +++ trunk/Makefile Tue Feb 23 11:33:25 2010(r5149) @@ -253,7 +253,7 @@ printf /* build system definitions (autogenerated) */\n $(obj)/build.ht printf #ifndef __BUILD_H\n $(obj)/build.ht printf #define __BUILD_H\n\n $(obj)/build.ht - printf #define COREBOOT_VERSION \$(KERNELVERSION)\\n $(obj)/build.ht + printf #define COREBOOT_VERSION \$(KERNELVERSION)-r$(shell if [ -d $(top)/.svn -a -f `which svnversion` ]; then svnversion $(top); else if [ -d $(top)/.git -a -f `which git` ]; then git --git-dir=/$(top)/.git log|grep git-svn-id|cut -f 2 -d@|cut -f 1 -d' '|sort -g|tail -1; fi; fi)\\n $(obj)/build.ht printf #define COREBOOT_EXTRA_VERSION \$(COREBOOT_EXTRA_VERSION)\\n $(obj)/build.ht printf #define COREBOOT_BUILD \`LANG= date`\\n $(obj)/build.ht printf \n $(obj)/build.ht -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH]: Report svnversion in Kconfig mode
Am 21.02.2010 03:32, schrieb Bao, Zheng: Finding out the svnversion we are working on is quite important, I think. The whole string is copied from original newconfig. It is important. There are a couple of GNUisms in it that I'll look into cleaning out eventually, but for now it's good, especially as it's just a copy. Worst case, the version string is incomplete, which is something we can live with (just like before this commit). Signed-off-by: Zheng Bao zheng@amd.com Acked-by: Patrick Georgi patrick.geo...@coresystems.de Committed as r5149 Thanks, Patrick -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] Adopt a patch
Hi, I'm currently working on the backlog we have with patches and wanted to point out a nice tool we have for that. On http://patchwork.coreboot.org/project/coreboot/list/ you can find a patchwork installation which tracks our mailing list, keeping watch over submitted patches and the discussions related to them. Please feel encourage to look there for patches that seem to be forgotten, and review them, bring them alive again, and make sure, they can get in (or get improved on, if they need more work). Patches that are sufficiently processed (accepted/committed, rejected, superseded, etc) disappear from view, so as long as the default view on that page lists patches, there's still a patch that waits for someone to take care of it. It's also a good place to keep track of the patches you submitted over time, to see if they're in already. The patch list should be quite recent about which patches are in and which aren't. If you require additional privileges on patchwork, please tell me, and I'll set things up appropriately. Patrick -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH] simplify keyboard API
Am 25.10.2009 00:50, schrieb Stefan Reinauer: Not sure if this is such a good idea.. Opinions? Given that PS/2 is always at 0x60/0x64 and that the code has no sensible behaviour in any other case, this seems like a good idea. Acked-by: Patrick Georgi patrick.geo...@coresystems.de Not committing, as your Signed-off is missing ;-) Patrick -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Adopt a patch
On 23.02.2010 11:43, Patrick Georgi wrote: On http://patchwork.coreboot.org/project/coreboot/list/ you can find a patchwork installation which tracks our mailing list, keeping watch over submitted patches and the discussions related to them. Please feel encourage to look there for patches that seem to be forgotten, and review them, bring them alive again, and make sure, they can get in (or get improved on, if they need more work). Thanks for starting this effort, Patrick. I am going through the flashrom patches from time to time, and there the overview is pretty current (and yes, we have a massive backlog of board enable patches because testers usually disappear after the code works for them). Regards, Carl-Daniel -- I do consider assignment statements and pointer variables to be among computer science's most valuable treasures. -- Donald E. Knuth -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH] (somewhat) clean up intel southbridge drivers
On Mon, 22 Feb 2010 17:53:59 +0100, Stefan Reinauer ste...@coresystems.de wrote: On 2/22/10 3:57 PM, Uwe Hermann wrote: So folks, if you agree that we should clean up coreboot and make it easier for people, send me an Acked-by: for the above idea. Signed-off-by: Stefan Reinauer ste...@coresystems.de Acked-by: Uwe Hermann u...@hermann-uwe.de Awesome, thanks a lot! However, there are some follow-up TODOs. All of those SBs have missing license headers and partly inconsistent coding-style (which is to be expected though, as the coding guidelines were not in place back then). I might be able to take care of that sooner or later, but any help is welcome. I would be glad to help out, as soon as Stefan starts the orgy :-) -- Thanks, Joseph Smith Set-Top-Linux www.settoplinux.org -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] [PATCH]another attempt at minimizing bootblock size
Hi,
attached patch is another attempt at minimizing bootblock size.
It also removes the obsolete ldscript_cbfs.lb, and removes any mention
of _lrom and _elrom, which were set but never used (and broke the
minimization approach used)
With the patch, the bootblock for kontron/986lcd-m is just 978 bytes,
the bootblock for amd/serengeti_cheetah_fam10 is 2390 bytes (more
complex setup), and asus/m2v-mx_se features a bootblock of 674 bytes.
I only did that for the tinybootblock variant of building images, as
it's much easier and thus safer to handle.
I also added a memory region constraint, so ld fails once the bootblock
is more than 64k, which will be most effective to guards against the
close-to-4GB images we've seen every once in a while.
However, this might require some tweaking of the list of discarded
sections, as ld complains about the various default sections, even if
those are empty and would be discarded in any case.
Those files should also be renamed at some point (no need to mention
that the file is for CBFS, and .lb should be called .cb), but I'd
prefer to do that after I moved away the ldscripts variable in the build
system, so there are fewer files to touch for that.
Signed-off-by: Patrick Georgi patrick.geo...@coresystems.de
Index: src/arch/i386/init/ldscript_failover.lb
===
--- src/arch/i386/init/ldscript_failover.lb (revision 5130)
+++ src/arch/i386/init/ldscript_failover.lb (working copy)
@@ -27,33 +27,34 @@
OUTPUT_FORMAT(elf32-i386, elf32-i386, elf32-i386)
OUTPUT_ARCH(i386)
-/*
-ENTRY(_start)
-*/
+MEMORY {
+ rom : ORIGIN = 0x, LENGTH = 64K
+}
TARGET(binary)
SECTIONS
{
- . = CONFIG_ROMBASE;
+ . = 0;
/* This section might be better named .setup */
- .rom . : {
+ .rom ROMLOC : {
_rom = .;
*(.rom.text);
*(.rom.data);
*(.rom.data.*);
*(.rodata.*);
- . = ALIGN(16);
_erom = .;
- }
+ } rom =0xff
- _lrom = LOADADDR(.rom);
- _elrom = LOADADDR(.rom) + SIZEOF(.rom);
+ ROMLOC = 0xff00 - (_erom - _rom) + 1;
/DISCARD/ : {
*(.comment)
*(.note)
*(.comment.*)
*(.note.*)
+ *(.iplt)
+ *(.rel.*)
+ *(.igot.*)
}
}
Index: src/arch/i386/init/ldscript_fallback_cbfs.lb
===
--- src/arch/i386/init/ldscript_fallback_cbfs.lb(revision 5130)
+++ src/arch/i386/init/ldscript_fallback_cbfs.lb(working copy)
@@ -53,9 +53,6 @@
_erom = .;
}
- _lrom = LOADADDR(.rom);
- _elrom = LOADADDR(.rom) + SIZEOF(.rom);
-
/DISCARD/ : {
*(.comment)
*(.note)
Index: src/arch/i386/init/ldscript_cbfs.lb
===
--- src/arch/i386/init/ldscript_cbfs.lb (revision 5130)
+++ src/arch/i386/init/ldscript_cbfs.lb (working copy)
@@ -1,59 +0,0 @@
-/*
- * Memory map:
- *
- * CONFIG_RAMBASE
- * : data segment
- * : bss segment
- * : heap
- * : stack
- * CONFIG_ROMBASE
- * : coreboot text
- * : readonly text
- */
-/*
- * 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.
- */
-OUTPUT_FORMAT(elf32-i386, elf32-i386, elf32-i386)
-OUTPUT_ARCH(i386)
-
-/*
-ENTRY(_start)
-*/
-
-TARGET(binary)
-SECTIONS
-{
- . = CONFIG_ROMBASE;
-
- /* This section might be better named .setup */
- .rom . : {
- _rom = .;
- *(.rom.text);
- *(.rom.data);
- *(.rodata.*);
- *(.rom.data.*);
- . = ALIGN(16);
- _erom = .;
- }
-
- _lrom = LOADADDR(.rom);
- _elrom = LOADADDR(.rom) + SIZEOF(.rom);
-
- /DISCARD/ : {
- *(.comment)
- *(.comment.*)
- *(.note)
- *(.note.*)
- }
-}
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] Executing bootstrap from MBR in coreboot
Hello, Does coreboot support executing of boostrap which is contained in MBR? Maybe you have any hints about writing payload which can do that? Thanks in advance, -- Piotr Piwko http://www.embedded-engineering.pl/ -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH] e7501 register pressure
On Mon, Feb 22, 2010 at 04:30:20PM -0800, ron minnich wrote: On Mon, Feb 22, 2010 at 4:03 PM, Stefan Reinauer ste...@coresystems.de wrote: Does anyone have the hardware? I doubt anyone does. The question here is, if no one can test it, are we better off making a change we can not test, Yes. or removing the support. No. We have to live with the fact that we will never be able to test _all_ changes on hardware all the time. That doesn't mean we should stop working on the code. We've been doing tree-wide changes in recent weeks and months on a regular basis (high tables, cbfs, kconfig, tinybootblock, and many many more) which have a _lot_ higher potential for breaking (lots of!) boards than this patch. That doesn't mean we should not have done those changes. At most we should try to carefully review more of our patches and encourage more users to test on their boards more often. Yes, bugs may slip in, but they will be noticed next time someone tests on hardware (or a user reports a bug on IRC or the list), and then we can bisect and fix the bug. No big deal. Acked-by: Ronald G. Minnich rminn...@gmail.com Acked-by: Uwe Hermann u...@hermann-uwe.de Uwe. -- http://www.hermann-uwe.de | http://www.randomprojects.org http://www.crazy-hacks.org | http://www.unmaintained-free-software.org -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Executing bootstrap from MBR in coreboot
On Tue, 23 Feb 2010 13:58:30 +0100, Piotr Piwko piotr.pi...@embedded-engineering.pl wrote: Hello, Does coreboot support executing of boostrap which is contained in MBR? Maybe you have any hints about writing payload which can do that? SeaBIOS -- Thanks, Joseph Smith Set-Top-Linux www.settoplinux.org -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] More lists
Hi, The debate about e7501 (dropping or risking broken code in the tree) reminded me of an idea I had a while ago: Do we want to establish a list of boards and their latest successfully tested revision, and all maintainers/testers for each board that agree to test changes regularily or on demand (and have the hardware around, of course)? That way, we'd know who to ask if we make sweeping changes that affect the entire tree. The other list I'd like to start is a document (on the wiki) that explains tree wide changes with the revision in which they happened, what happened, and how to replay those changes on a locally modified tree - esp. those with new boards. This would help people keeping their local development up to date, and it helps with finding the cause of problems. Basically, everything that affects the whole tree should be documented with: - Rev in which this change appeared - Short explanation what happened (maybe just the URL to the mailing list archive) - Explanation what to change to keep up (incl. scripts, if used) - Developer responsible for it Both of these are only useful if they're generally maintained. Maybe that's too much effort for the gain, so what do you think? Regards, Patrick -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Executing bootstrap from MBR in coreboot
Piotr Piwko wrote: Does coreboot support executing of boostrap which is contained in MBR? No. coreboot itself doesn't really do operating system bootstrapping. Maybe you have any hints about writing payload which can do that? As Joseph pointed out you could look at SeaBIOS, which has quickly become a very complete BIOS implementation. SeaBIOS runs well as a coreboot payload, and if you combine coreboot and SeaBIOS you will indeed have a legacy compatible open source firmware. //Peter -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] [PATCH]minor Kconfig cleanup: WAIT_BEFORE_CPUS_INIT
Hi, attached patch removes Kconfig entries that disable WAIT_BEFORE_CPUS_INIT. It's disabled by default (see src/cpu/x86/Kconfig) Signed-off-by: Patrick Georgi patrick.geo...@coresystems.de Index: src/mainboard/gigabyte/m57sli/Kconfig === --- src/mainboard/gigabyte/m57sli/Kconfig (revision 5149) +++ src/mainboard/gigabyte/m57sli/Kconfig (working copy) @@ -127,11 +127,6 @@ default n depends on BOARD_GIGABYTE_M57SLI -config WAIT_BEFORE_CPUS_INIT - bool - default n - depends on BOARD_GIGABYTE_M57SLI - config MAINBOARD_PCI_SUBSYSTEM_VENDOR_ID hex default 0x1022 Index: src/mainboard/gigabyte/ga_2761gxdk/Kconfig === --- src/mainboard/gigabyte/ga_2761gxdk/Kconfig (revision 5149) +++ src/mainboard/gigabyte/ga_2761gxdk/Kconfig (working copy) @@ -124,11 +124,6 @@ default n depends on BOARD_GIGABYTE_GA_2761GXDK -config WAIT_BEFORE_CPUS_INIT - bool - default n - depends on BOARD_GIGABYTE_GA_2761GXDK - config MAINBOARD_PCI_SUBSYSTEM_VENDOR_ID hex default 0x1039 Index: src/mainboard/tyan/s2912/Kconfig === --- src/mainboard/tyan/s2912/Kconfig(revision 5149) +++ src/mainboard/tyan/s2912/Kconfig(working copy) @@ -125,11 +125,6 @@ default n depends on BOARD_TYAN_S2912 -config WAIT_BEFORE_CPUS_INIT - bool - default n - depends on BOARD_TYAN_S2912 - config MAINBOARD_PCI_SUBSYSTEM_DEVICE_ID hex default 0x2912 Index: src/mainboard/tyan/s2880/Kconfig === --- src/mainboard/tyan/s2880/Kconfig(revision 5149) +++ src/mainboard/tyan/s2880/Kconfig(working copy) @@ -82,11 +82,6 @@ default n depends on BOARD_TYAN_S2880 -config WAIT_BEFORE_CPUS_INIT - bool - default n - depends on BOARD_TYAN_S2880 - config IRQ_SLOT_COUNT int default 13 Index: src/mainboard/tyan/s2881/Kconfig === --- src/mainboard/tyan/s2881/Kconfig(revision 5149) +++ src/mainboard/tyan/s2881/Kconfig(working copy) @@ -82,11 +82,6 @@ default n depends on BOARD_TYAN_S2881 -config WAIT_BEFORE_CPUS_INIT - bool - default n - depends on BOARD_TYAN_S2881 - config IRQ_SLOT_COUNT int default 9 Index: src/mainboard/tyan/s2882/Kconfig === --- src/mainboard/tyan/s2882/Kconfig(revision 5149) +++ src/mainboard/tyan/s2882/Kconfig(working copy) @@ -82,11 +82,6 @@ default n depends on BOARD_TYAN_S2882 -config WAIT_BEFORE_CPUS_INIT - bool - default n - depends on BOARD_TYAN_S2882 - config IRQ_SLOT_COUNT int default 15 Index: src/mainboard/tyan/s2891/Kconfig === --- src/mainboard/tyan/s2891/Kconfig(revision 5149) +++ src/mainboard/tyan/s2891/Kconfig(working copy) @@ -84,11 +84,6 @@ default n depends on BOARD_TYAN_S2891 -config WAIT_BEFORE_CPUS_INIT - bool - default n - depends on BOARD_TYAN_S2891 - config IRQ_SLOT_COUNT int default 11 Index: src/mainboard/tyan/s2892/Kconfig === --- src/mainboard/tyan/s2892/Kconfig(revision 5149) +++ src/mainboard/tyan/s2892/Kconfig(working copy) @@ -83,11 +83,6 @@ default n depends on BOARD_TYAN_S2892 -config WAIT_BEFORE_CPUS_INIT - bool - default n - depends on BOARD_TYAN_S2892 - config SB_HT_CHAIN_ON_BUS0 int default 2 Index: src/mainboard/tyan/s2885/Kconfig === --- src/mainboard/tyan/s2885/Kconfig(revision 5149) +++ src/mainboard/tyan/s2885/Kconfig(working copy) @@ -82,11 +82,6 @@ default n depends on BOARD_TYAN_S2885 -config WAIT_BEFORE_CPUS_INIT - bool - default n - depends on BOARD_TYAN_S2885 - config IRQ_SLOT_COUNT int default 11 Index: src/mainboard/tyan/s2895/Kconfig === --- src/mainboard/tyan/s2895/Kconfig(revision 5149) +++ src/mainboard/tyan/s2895/Kconfig(working copy) @@ -83,11 +83,6 @@ default n depends on BOARD_TYAN_S2895 -config WAIT_BEFORE_CPUS_INIT - bool - default n - depends on BOARD_TYAN_S2895 - config SB_HT_CHAIN_ON_BUS0 int default 2 Index: src/mainboard/tyan/s2912_fam10/Kconfig === --- src/mainboard/tyan/s2912_fam10/Kconfig
Re: [coreboot] [PATCH] drivers vs. obj
Am 24.09.2009 22:59, schrieb Myles Watson: Based on that, here's a patch that changes drivers that aren't console, pci, or cpu, to obj. The most common one was mainboard.c as a driver. Boot tested with Tyan s2895. Signed-off-by: Myles Watson myle...@gmail.com I updated the patch, with all the boards converted that appeared in Kconfig after this patch was made, too. There's not a single driver in src/mainboard left. Signed-off-by: Patrick Georgi patrick.geo...@coresystems.de Index: src/mainboard/Makefile.k8_ck804.inc === --- src/mainboard/Makefile.k8_ck804.inc (revision 5149) +++ src/mainboard/Makefile.k8_ck804.inc (working copy) @@ -23,7 +23,7 @@ ## This mainboard requires DCACHE_AS_RAM enabled. It won't work without. ## -driver-y += mainboard.o +obj-y += mainboard.o #needed by irq_tables and mptable and acpi_tables obj-y += get_bus_conf.o Index: src/mainboard/iwill/dk8_htx/Makefile.inc === --- src/mainboard/iwill/dk8_htx/Makefile.inc(revision 5149) +++ src/mainboard/iwill/dk8_htx/Makefile.inc(working copy) @@ -17,7 +17,7 @@ ## Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA ## -driver-y += mainboard.o +obj-y += mainboard.o # Needed by irq_tables and mptable and acpi_tables. obj-y += get_bus_conf.o Index: src/mainboard/broadcom/blast/Makefile.inc === --- src/mainboard/broadcom/blast/Makefile.inc (revision 5149) +++ src/mainboard/broadcom/blast/Makefile.inc (working copy) @@ -3,5 +3,5 @@ # Needed by irq_tables and mptable and acpi_tables. obj-y += get_bus_conf.o -driver-y += ../../../drivers/i2c/i2cmux2/i2cmux2.o +obj-y += ../../../drivers/i2c/i2cmux2/i2cmux2.o Index: src/mainboard/supermicro/h8dmr/Makefile.inc === --- src/mainboard/supermicro/h8dmr/Makefile.inc (revision 5149) +++ src/mainboard/supermicro/h8dmr/Makefile.inc (working copy) @@ -17,7 +17,7 @@ ## Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA ## -driver-y += mainboard.o +obj-y += mainboard.o # Needed by irq_tables and mptable and acpi_tables. obj-y += get_bus_conf.o Index: src/mainboard/supermicro/x6dhe_g/Makefile.inc === --- src/mainboard/supermicro/x6dhe_g/Makefile.inc (revision 5149) +++ src/mainboard/supermicro/x6dhe_g/Makefile.inc (working copy) @@ -21,5 +21,5 @@ ROMCCFLAGS=-mcpu=p4 -O2 obj-$(CONFIG_HAVE_HARD_RESET) += reset.o include $(src)/mainboard/Makefile.romccboard.inc -driver-y += ../../../drivers/generic/debug/debug_dev.o +obj-y += ../../../drivers/generic/debug/debug_dev.o Index: src/mainboard/supermicro/h8dme/Makefile.inc === --- src/mainboard/supermicro/h8dme/Makefile.inc (revision 5149) +++ src/mainboard/supermicro/h8dme/Makefile.inc (working copy) @@ -17,8 +17,8 @@ ## Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA ## -driver-y += mainboard.o -driver-y += ../../../drivers/i2c/i2cmux2/i2cmux2.o +obj-y += mainboard.o +obj-y += ../../../drivers/i2c/i2cmux2/i2cmux2.o # Needed by irq_tables and mptable and acpi_tables. obj-y += get_bus_conf.o Index: src/mainboard/supermicro/h8dmr_fam10/Makefile.inc === --- src/mainboard/supermicro/h8dmr_fam10/Makefile.inc (revision 5149) +++ src/mainboard/supermicro/h8dmr_fam10/Makefile.inc (working copy) @@ -17,7 +17,7 @@ ## Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA ## -driver-y += mainboard.o +obj-y += mainboard.o # Needed by irq_tables and mptable and acpi_tables. obj-y += get_bus_conf.o Index: src/mainboard/supermicro/h8qme_fam10/Makefile.inc === --- src/mainboard/supermicro/h8qme_fam10/Makefile.inc (revision 5149) +++ src/mainboard/supermicro/h8qme_fam10/Makefile.inc (working copy) @@ -17,7 +17,7 @@ ## Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA ## -driver-y += mainboard.o +obj-y += mainboard.o # Needed by irq_tables and mptable and acpi_tables. obj-y += get_bus_conf.o Index: src/mainboard/supermicro/x6dhe_g2/Makefile.inc === --- src/mainboard/supermicro/x6dhe_g2/Makefile.inc (revision 5149) +++ src/mainboard/supermicro/x6dhe_g2/Makefile.inc (working copy) @@ -21,5 +21,5 @@ ROMCCFLAGS=-mcpu=p4 -O2 obj-$(CONFIG_HAVE_HARD_RESET) += reset.o include $(src)/mainboard/Makefile.romccboard.inc -driver-y += ../../../drivers/generic/debug/debug_dev.o +obj-y += ../../../drivers/generic/debug/debug_dev.o Index: src/mainboard/kontron/986lcd-m/Makefile.inc
Re: [coreboot] More lists
On Tue, Feb 23, 2010 at 03:54:41PM +0100, Patrick Georgi wrote: The debate about e7501 (dropping or risking broken code in the tree) reminded me of an idea I had a while ago: Do we want to establish a list of boards and their latest successfully tested revision, and all maintainers/testers for each board that agree to test changes regularily or on demand (and have the hardware around, of course)? That way, we'd know who to ask if we make sweeping changes that affect the entire tree. In theory nice to have, but experience has shown that this list will be ignored and outdated very very soon: http://www.coreboot.org/Confirmed_working_svn_revisions I personally also don't think such a list is _that_ important to have. In theory _every_ revision should work and as soon as someone finds a bug / nonworking revision we quickly bisect and make trunk working again, so not much point in such a list IMHO. The other list I'd like to start is a document (on the wiki) that explains tree wide changes with the revision in which they happened, what happened, and how to replay those changes on a locally modified tree - esp. those with new boards. Yep, this idea I like very much! This would help people keeping their local development up to date, and it helps with finding the cause of problems. Basically, everything that affects the whole tree should be documented with: - Rev in which this change appeared Yes. - Short explanation what happened (maybe just the URL to the mailing list archive) Yes. - Explanation what to change to keep up (incl. scripts, if used) This one is the most important. It should be a migration guide-like HOWTO a la change variable name FOO to BAR, remove all BAZ occurences in your code etc. etc. - Developer responsible for it Not sure if this makes sense. And/or it's visible from the Signed-off-by anyway in most cases. Uwe. -- http://www.hermann-uwe.de | http://www.randomprojects.org http://www.crazy-hacks.org | http://www.unmaintained-free-software.org -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH] drivers vs. obj
Am 23.02.2010 17:28, schrieb Myles Watson: -driver-y += mainboard.o -driver-y += m3885.o -driver-y += ec.o -driver-y += rtl8168.o +obj-y += mainboard.o +obj-y += m3885.o +obj-y += ec.o +obj-y += rtl8168.o It looks like rtl8168 should stay a driver, since it's a PCI device. I don't know about m3885.o and ec.o. I'm also not sure about the debug devices. Are they considered PCI? It's been a long time since I thought about this. As I understand it, the main criterion was if they're using the linker magic. I couldn't find any of that in there, but maybe that's just too hidden for my (short, I admit) glance? Patrick -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH] drivers vs. obj
On 2/23/10 4:37 PM, Patrick Georgi wrote: Am 24.09.2009 22:59, schrieb Myles Watson: Based on that, here's a patch that changes drivers that aren't console, pci, or cpu, to obj. The most common one was mainboard.c as a driver. Boot tested with Tyan s2895. Signed-off-by: Myles Watson myle...@gmail.com I updated the patch, with all the boards converted that appeared in Kconfig after this patch was made, too. There's not a single driver in src/mainboard left. Signed-off-by: Patrick Georgi patrick.geo...@coresystems.de 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] drivers vs. obj
On 2/23/10 5:29 PM, Patrick Georgi wrote: Am 23.02.2010 17:28, schrieb Myles Watson: -driver-y += mainboard.o -driver-y += m3885.o -driver-y += ec.o -driver-y += rtl8168.o +obj-y += mainboard.o +obj-y += m3885.o +obj-y += ec.o +obj-y += rtl8168.o It looks like rtl8168 should stay a driver, since it's a PCI device. I don't know about m3885.o and ec.o. I'm also not sure about the debug devices. Are they considered PCI? It's been a long time since I thought about this. As I understand it, the main criterion was if they're using the linker magic. I couldn't find any of that in there, but maybe that's just too hidden for my (short, I admit) glance? No, that's right.. the EC code is only called from mainboard.c and the SMM handler -- 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] Adopt a patch
Am 23.02.2010 17:32, schrieb Myles Watson: It seems like it would be a lot more useful if it tracked commits. Since it finds patches automatically, can it also find commits automatically? Limited, yes. There's a script that matches commit diffs with diffs in the database. Unfortunately, they don't always match up, as the order of files within the patch isn't normalized. But nearly all of the committed patches should be marked accepted by that script and manual work already. Patrick -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Adopt a patch
On Tue, Feb 23, 2010 at 3:43 AM, Patrick Georgi patr...@georgi-clan.dewrote: Hi, I'm currently working on the backlog we have with patches and wanted to point out a nice tool we have for that. On http://patchwork.coreboot.org/project/coreboot/list/ you can find a patchwork installation which tracks our mailing list, keeping watch over submitted patches and the discussions related to them. It seems like it would be a lot more useful if it tracked commits. Since it finds patches automatically, can it also find commits automatically? Thanks, Myles -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH]minor Kconfig cleanup: WAIT_BEFORE_CPUS_INIT
On Tue, Feb 23, 2010 at 8:14 AM, Patrick Georgi patr...@georgi-clan.dewrote: Hi, attached patch removes Kconfig entries that disable WAIT_BEFORE_CPUS_INIT. It's disabled by default (see src/cpu/x86/Kconfig) Signed-off-by: Patrick Georgi patrick.geo...@coresystems.de Acked-by: Myles Watson myle...@gmail.com Thanks, Myles -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Adopt a patch
On Tue, Feb 23, 2010 at 9:34 AM, Patrick Georgi patr...@georgi-clan.dewrote: Am 23.02.2010 17:32, schrieb Myles Watson: It seems like it would be a lot more useful if it tracked commits. Since it finds patches automatically, can it also find commits automatically? Limited, yes. There's a script that matches commit diffs with diffs in the database. Unfortunately, they don't always match up, as the order of files within the patch isn't normalized. Maybe it should match the Rev 5217 messages in replies to the Acked-by messages. But nearly all of the committed patches should be marked accepted by that script and manual work already. Is this based on Acked-by? I asked because there's a patch submitted by Stefan and Acked-by Ron that shows up. Thanks, Myles -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH] drivers vs. obj
On Tue, Feb 23, 2010 at 8:37 AM, Patrick Georgi patr...@georgi-clan.dewrote: Am 24.09.2009 22:59, schrieb Myles Watson: Based on that, here's a patch that changes drivers that aren't console, pci, or cpu, to obj. The most common one was mainboard.c as a driver. Boot tested with Tyan s2895. Signed-off-by: Myles Watson myle...@gmail.com I updated the patch, with all the boards converted that appeared in Kconfig after this patch was made, too. There's not a single driver in src/mainboard left. Signed-off-by: Patrick Georgi patrick.geo...@coresystems.de Index: src/mainboard/roda/rk886ex/Makefile.inc === --- src/mainboard/roda/rk886ex/Makefile.inc(revision 5149) +++ src/mainboard/roda/rk886ex/Makefile.inc(working copy) @@ -21,10 +21,10 @@ ## This mainboard requires DCACHE_AS_RAM enabled. It won't work without. ## -driver-y += mainboard.o -driver-y += m3885.o -driver-y += ec.o -driver-y += rtl8168.o +obj-y += mainboard.o +obj-y += m3885.o +obj-y += ec.o +obj-y += rtl8168.o It looks like rtl8168 should stay a driver, since it's a PCI device. I don't know about m3885.o and ec.o. I'm also not sure about the debug devices. Are they considered PCI? It's been a long time since I thought about this. Thanks, Myles -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Adopt a patch
Am 23.02.2010 17:37, schrieb Myles Watson: But nearly all of the committed patches should be marked accepted by that script and manual work already. Is this based on Acked-by? I asked because there's a patch submitted by Stefan and Acked-by Ron that shows up. No, by fetching diffs from the repository, normalizing them in some way and creating a hash on that. Each patch in the database has such a hash, too. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] [commit] r5150 - in trunk/src/mainboard: . amd/db800 amd/dbm690t amd/norwich amd/pistachio amd/serengeti_cheetah amd/serengeti_cheetah_fam10 artecgroup/dbe61 asus/a8n_e asus/a8v-e_se asus/m
Author: oxygene Date: Tue Feb 23 17:54:20 2010 New Revision: 5150 URL: http://tracker.coreboot.org/trac/coreboot/changeset/5150 Log: Only handle code as driver that actually uses our driver infrastructure (special linking, data structures, etc) Signed-off-by: Patrick Georgi patrick.geo...@coresystems.de Acked-by: Stefan Reinauer ste...@coresystems.de Modified: trunk/src/mainboard/Makefile.k8_CAR.inc trunk/src/mainboard/Makefile.k8_ck804.inc trunk/src/mainboard/Makefile.romccboard.inc trunk/src/mainboard/amd/db800/Makefile.inc trunk/src/mainboard/amd/dbm690t/Makefile.inc trunk/src/mainboard/amd/norwich/Makefile.inc trunk/src/mainboard/amd/pistachio/Makefile.inc trunk/src/mainboard/amd/serengeti_cheetah/Makefile.inc trunk/src/mainboard/amd/serengeti_cheetah_fam10/Makefile.inc trunk/src/mainboard/artecgroup/dbe61/Makefile.inc trunk/src/mainboard/asus/a8n_e/Makefile.inc trunk/src/mainboard/asus/a8v-e_se/Makefile.inc trunk/src/mainboard/asus/m2v-mx_se/Makefile.inc trunk/src/mainboard/broadcom/blast/Makefile.inc trunk/src/mainboard/digitallogic/msm800sev/Makefile.inc trunk/src/mainboard/gigabyte/ga_2761gxdk/Makefile.inc trunk/src/mainboard/gigabyte/m57sli/Makefile.inc trunk/src/mainboard/iei/pcisa-lx-800-r10/Makefile.inc trunk/src/mainboard/intel/d945gclf/Makefile.inc trunk/src/mainboard/intel/eagleheights/Makefile.inc trunk/src/mainboard/iwill/dk8_htx/Makefile.inc trunk/src/mainboard/kontron/986lcd-m/Makefile.inc trunk/src/mainboard/kontron/kt690/Makefile.inc trunk/src/mainboard/lippert/roadrunner-lx/Makefile.inc trunk/src/mainboard/lippert/spacerunner-lx/Makefile.inc trunk/src/mainboard/msi/ms7260/Makefile.inc trunk/src/mainboard/msi/ms9282/Makefile.inc trunk/src/mainboard/nvidia/l1_2pvv/Makefile.inc trunk/src/mainboard/pcengines/alix1c/Makefile.inc trunk/src/mainboard/roda/rk886ex/Makefile.inc trunk/src/mainboard/supermicro/h8dme/Makefile.inc trunk/src/mainboard/supermicro/h8dmr/Makefile.inc trunk/src/mainboard/supermicro/h8dmr_fam10/Makefile.inc trunk/src/mainboard/supermicro/h8qme_fam10/Makefile.inc trunk/src/mainboard/supermicro/x6dhe_g/Makefile.inc trunk/src/mainboard/supermicro/x6dhe_g2/Makefile.inc trunk/src/mainboard/technexion/tim5690/Makefile.inc trunk/src/mainboard/technexion/tim8690/Makefile.inc trunk/src/mainboard/tyan/s2735/Makefile.inc trunk/src/mainboard/tyan/s2881/Makefile.inc trunk/src/mainboard/tyan/s2892/Makefile.inc trunk/src/mainboard/tyan/s2912/Makefile.inc trunk/src/mainboard/tyan/s2912_fam10/Makefile.inc trunk/src/mainboard/via/vt8454c/Makefile.inc Modified: trunk/src/mainboard/Makefile.k8_CAR.inc == --- trunk/src/mainboard/Makefile.k8_CAR.inc Tue Feb 23 11:33:25 2010 (r5149) +++ trunk/src/mainboard/Makefile.k8_CAR.inc Tue Feb 23 17:54:20 2010 (r5150) @@ -23,7 +23,7 @@ ## This mainboard requires DCACHE_AS_RAM enabled. It won't work without. ## -driver-y += mainboard.o +obj-y += mainboard.o obj-$(CONFIG_GENERATE_MP_TABLE) += mptable.o obj-$(CONFIG_GENERATE_PIRQ_TABLE) += irq_tables.o Modified: trunk/src/mainboard/Makefile.k8_ck804.inc == --- trunk/src/mainboard/Makefile.k8_ck804.inc Tue Feb 23 11:33:25 2010 (r5149) +++ trunk/src/mainboard/Makefile.k8_ck804.inc Tue Feb 23 17:54:20 2010 (r5150) @@ -23,7 +23,7 @@ ## This mainboard requires DCACHE_AS_RAM enabled. It won't work without. ## -driver-y += mainboard.o +obj-y += mainboard.o #needed by irq_tables and mptable and acpi_tables obj-y += get_bus_conf.o Modified: trunk/src/mainboard/Makefile.romccboard.inc == --- trunk/src/mainboard/Makefile.romccboard.inc Tue Feb 23 11:33:25 2010 (r5149) +++ trunk/src/mainboard/Makefile.romccboard.inc Tue Feb 23 17:54:20 2010 (r5150) @@ -61,7 +61,7 @@ ldscripts += $(src)/arch/i386/lib/failover.lds endif -driver-y += mainboard.o +obj-y += mainboard.o obj-$(CONFIG_GENERATE_MP_TABLE) += mptable.o obj-$(CONFIG_GENERATE_PIRQ_TABLE) += irq_tables.o Modified: trunk/src/mainboard/amd/db800/Makefile.inc == --- trunk/src/mainboard/amd/db800/Makefile.inc Tue Feb 23 11:33:25 2010 (r5149) +++ trunk/src/mainboard/amd/db800/Makefile.inc Tue Feb 23 17:54:20 2010 (r5150) @@ -1,4 +1,4 @@ -driver-y += mainboard.o +obj-y += mainboard.o # Needed by irq_tables and mptable and acpi_tables. obj-$(CONFIG_GENERATE_PIRQ_TABLE) += irq_tables.o Modified: trunk/src/mainboard/amd/dbm690t/Makefile.inc == --- trunk/src/mainboard/amd/dbm690t/Makefile.incTue Feb 23 11:33:25 2010(r5149) +++
Re: [coreboot] More lists
Hi, Could we have some tag to svn commit like: Signed-off-by... Acked-by: ... And then add: current-works Tag ;) and then make some script which will extract this and place it on wiki... Maybe we can have also current-works_tweaks That something is changed but otherwise it works pretty fine... Rudolf -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] More lists
Could we have some tag to svn commit like: And then add: current-works And also the haha this is broken tag and maybe the will fry your mainboard tag. :) One problem is that commits that are board-specific hopefully result in a working board. The problem is that they break other boards that weren't tested (or other payloads on the same board). I don't think there's a way around that basic problem. Thanks, Myles -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] More lists
On Tue, Feb 23, 2010 at 10:47:21AM -0700, Myles Watson wrote: Could we have some tag to svn commit like: And then add: current-works And also the haha this is broken tag and maybe the will fry your mainboard tag. :) One problem is that commits that are board-specific hopefully result in a working board. The problem is that they break other boards that weren't tested (or other payloads on the same board). I don't think there's a way around that basic problem. Boot testing would. The automatic testing framework Stepan built a few years ago - I'd love to get a few boards set up for that. I have some boards lying around that could be used for that. My main problem is cost: dedicating an artec dongle + plcc adapter runs about $350 per board... And then you still need a remote power toggle device (can be had for cheap-ish if you look around a bit) and some sort of serial capture device (or just another computer if it's one or a few boards). If I didn't have to sacrifice a dongle for each board, I'd set up a tyan S2881 and probably one or two alix boards for automated testing. Thanks, Ward. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [commit] r5149 - trunk
repository service wrote: git --git-dir=/$(top)/.git log | grep git-svn-id | cut -f 2 -d@ | cut -f 1 -d' ' | sort -g | tail -1 Maybe git log -1 | sed -e '/git-svn-id/!d' -e 's,@\([^ ]*\).*,\1,' if sed is available. //Peter -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] More lists
Am 23.02.2010 20:07, schrieb Ward Vandewege: If I didn't have to sacrifice a dongle for each board, I'd set up a tyan S2881 and probably one or two alix boards for automated testing. How about using serialice? It's not quite the real thing, but... Patrick -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH]another attempt at minimizing bootblock size
Signed-off-by: Patrick Georgi patrick.geo...@coresystems.de Acked-by: Peter Stuge pe...@stuge.se -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] [commit] r5151 - trunk/src/arch/i386/init
Author: oxygene
Date: Tue Feb 23 20:38:44 2010
New Revision: 5151
URL: http://tracker.coreboot.org/trac/coreboot/changeset/5151
Log:
- Remove src/arch/i386/init/ldscript_cbfs.lb as it's not used anymore
- Remove _lrom and _elrom, as they're only set but never used
- Make bootblock size dynamic in the tiny bootblock case.
It's 0.5-3K instead of 64K now.
Signed-off-by: Patrick Georgi patrick.geo...@coresystems.de
Acked-by: Peter Stuge pe...@stuge.se
Deleted:
trunk/src/arch/i386/init/ldscript_cbfs.lb
Modified:
trunk/src/arch/i386/init/ldscript_failover.lb
trunk/src/arch/i386/init/ldscript_fallback_cbfs.lb
Modified: trunk/src/arch/i386/init/ldscript_failover.lb
==
--- trunk/src/arch/i386/init/ldscript_failover.lb Tue Feb 23 17:54:20
2010(r5150)
+++ trunk/src/arch/i386/init/ldscript_failover.lb Tue Feb 23 20:38:44
2010(r5151)
@@ -27,33 +27,34 @@
OUTPUT_FORMAT(elf32-i386, elf32-i386, elf32-i386)
OUTPUT_ARCH(i386)
-/*
-ENTRY(_start)
-*/
+MEMORY {
+ rom : ORIGIN = 0x, LENGTH = 64K
+}
TARGET(binary)
SECTIONS
{
- . = CONFIG_ROMBASE;
+ . = 0;
/* This section might be better named .setup */
- .rom . : {
+ .rom ROMLOC : {
_rom = .;
*(.rom.text);
*(.rom.data);
*(.rom.data.*);
*(.rodata.*);
- . = ALIGN(16);
_erom = .;
- }
+ } rom =0xff
- _lrom = LOADADDR(.rom);
- _elrom = LOADADDR(.rom) + SIZEOF(.rom);
+ ROMLOC = 0xff00 - (_erom - _rom) + 1;
/DISCARD/ : {
*(.comment)
*(.note)
*(.comment.*)
*(.note.*)
+ *(.iplt)
+ *(.rel.*)
+ *(.igot.*)
}
}
Modified: trunk/src/arch/i386/init/ldscript_fallback_cbfs.lb
==
--- trunk/src/arch/i386/init/ldscript_fallback_cbfs.lb Tue Feb 23 17:54:20
2010(r5150)
+++ trunk/src/arch/i386/init/ldscript_fallback_cbfs.lb Tue Feb 23 20:38:44
2010(r5151)
@@ -53,9 +53,6 @@
_erom = .;
}
- _lrom = LOADADDR(.rom);
- _elrom = LOADADDR(.rom) + SIZEOF(.rom);
-
/DISCARD/ : {
*(.comment)
*(.note)
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Tester hardware
Ward Vandewege wrote: The automatic testing framework Stepan built a few years ago - I'd love to get a few boards set up for that. I have some boards lying around that could be used for that. My main problem is cost: You're not alone. I've wanted to create affordable tester hardware for quite some time now. I think it's the only way we'll get more boot testing. These are the features I had in mind; . LPC/FWH/SPI bootable . Serial port for logging BUT (board under test) output . Ideally USB host for USB debug device console . LAN connection . A few GPO pins for power button/reset button/PWROK signalling An ALIX has most of this at a cost that can't be beat. Only booting is missing. Though an FPGA rocks I think a small microcontroller and actual flash chips may be the simplest and cheapest way to do it. The microcontroller is for flashing from ALIX, maybe also GPO pins and serial port. Thoughts? Did I overlook a cricical feature? Preorders? //Peter -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] [commit] r5152 - in trunk/src: include/pc80 mainboard/emulation/qemu-x86 northbridge/via/cx700 northbridge/via/vx800 pc80 southbridge/sis/sis966 southbridge/via/vt8231 southbridge/via/vt823
Author: oxygene
Date: Tue Feb 23 21:31:37 2010
New Revision: 5152
URL: http://tracker.coreboot.org/trac/coreboot/changeset/5152
Log:
Remove nonsensical wrapper for function in
PS/2 keyboard API.
Signed-off-by: Stefan Reinauer ste...@coresystems.de
Acked-by: Patrick Georgi patrick.geo...@coresystems.de
Modified:
trunk/src/include/pc80/keyboard.h
trunk/src/mainboard/emulation/qemu-x86/mainboard.c
trunk/src/northbridge/via/cx700/cx700_lpc.c
trunk/src/northbridge/via/vx800/vx800_lpc.c
trunk/src/pc80/keyboard.c
trunk/src/southbridge/sis/sis966/sis966_lpc.c
trunk/src/southbridge/via/vt8231/vt8231.c
trunk/src/southbridge/via/vt8235/vt8235.c
trunk/src/southbridge/via/vt8237r/vt8237r_lpc.c
trunk/src/superio/ite/it8671f/superio.c
trunk/src/superio/ite/it8673f/superio.c
trunk/src/superio/ite/it8712f/superio.c
trunk/src/superio/ite/it8716f/superio.c
trunk/src/superio/ite/it8718f/superio.c
trunk/src/superio/nsc/pc8374/superio.c
trunk/src/superio/nsc/pc87309/superio.c
trunk/src/superio/nsc/pc87351/superio.c
trunk/src/superio/nsc/pc87360/superio.c
trunk/src/superio/nsc/pc87366/superio.c
trunk/src/superio/nsc/pc87417/superio.c
trunk/src/superio/nsc/pc87427/superio.c
trunk/src/superio/nsc/pc97307/superio.c
trunk/src/superio/nsc/pc97317/superio.c
trunk/src/superio/renesas/m3885x/superio.c
trunk/src/superio/smsc/fdc37m60x/superio.c
trunk/src/superio/smsc/lpc47b272/superio.c
trunk/src/superio/smsc/lpc47b397/superio.c
trunk/src/superio/smsc/lpc47m10x/superio.c
trunk/src/superio/smsc/lpc47m15x/superio.c
trunk/src/superio/smsc/lpc47n227/superio.c
trunk/src/superio/smsc/smscsuperio/superio.c
trunk/src/superio/winbond/w83627dhg/superio.c
trunk/src/superio/winbond/w83627ehg/superio.c
trunk/src/superio/winbond/w83627hf/superio.c
trunk/src/superio/winbond/w83627thf/superio.c
trunk/src/superio/winbond/w83627thg/superio.c
trunk/src/superio/winbond/w83627uhg/superio.c
trunk/src/superio/winbond/w83977f/superio.c
trunk/src/superio/winbond/w83977tf/superio.c
Modified: trunk/src/include/pc80/keyboard.h
==
--- trunk/src/include/pc80/keyboard.h Tue Feb 23 20:38:44 2010(r5151)
+++ trunk/src/include/pc80/keyboard.h Tue Feb 23 21:31:37 2010(r5152)
@@ -5,7 +5,7 @@
/* No initialization parameters for now */
};
-void init_pc_keyboard(unsigned port0, unsigned port1, struct pc_keyboard *kbd);
+void pc_keyboard_init(struct pc_keyboard *keyboard);
void set_kbc_ps2_mode(void);
#endif /* PC80_KEYBOARD_H */
Modified: trunk/src/mainboard/emulation/qemu-x86/mainboard.c
==
--- trunk/src/mainboard/emulation/qemu-x86/mainboard.c Tue Feb 23 20:38:44
2010(r5151)
+++ trunk/src/mainboard/emulation/qemu-x86/mainboard.c Tue Feb 23 21:31:37
2010(r5152)
@@ -23,7 +23,7 @@
/* This sneaked in here, because Qemu does not
* emulate a SuperIO chip
*/
- init_pc_keyboard(0x60, 0x64, 0);
+ pc_keyboard_init(0);
/* The PIRQ table is not working well for interrupt routing purposes.
* so we'll just set the IRQ directly.
Modified: trunk/src/northbridge/via/cx700/cx700_lpc.c
==
--- trunk/src/northbridge/via/cx700/cx700_lpc.c Tue Feb 23 20:38:44 2010
(r5151)
+++ trunk/src/northbridge/via/cx700/cx700_lpc.c Tue Feb 23 21:31:37 2010
(r5152)
@@ -294,7 +294,7 @@
isa_dma_init();
/* Initialize keyboard controller */
- init_pc_keyboard(0x60, 0x64, 0);
+ pc_keyboard_init(0);
}
static struct device_operations cx700_lpc_ops = {
Modified: trunk/src/northbridge/via/vx800/vx800_lpc.c
==
--- trunk/src/northbridge/via/vx800/vx800_lpc.c Tue Feb 23 20:38:44 2010
(r5151)
+++ trunk/src/northbridge/via/vx800/vx800_lpc.c Tue Feb 23 21:31:37 2010
(r5152)
@@ -342,7 +342,7 @@
setup_i8259(); // make sure interupt controller is configured
before keyboard init
/* turn on keyboard and RTC, no need to visit this reg twice */
- init_pc_keyboard(0x60, 0x64, 0);
+ pc_keyboard_init(0);
printk_debug
(ps2 usb lid, you set who can wakeup system from s3 sleep\n);
S3_ps2_kb_ms_wakeup(dev);
Modified: trunk/src/pc80/keyboard.c
==
--- trunk/src/pc80/keyboard.c Tue Feb 23 20:38:44 2010(r5151)
+++ trunk/src/pc80/keyboard.c Tue Feb 23 21:31:37 2010(r5152)
@@ -159,7 +159,7 @@
return regval;
}
-static void pc_keyboard_init(struct pc_keyboard *keyboard)
+void pc_keyboard_init(struct pc_keyboard *keyboard)
{
u8 regval;
printk_debug(Keyboard
Re: [coreboot] More lists
Am 23.02.2010 16:43, schrieb Uwe Hermann: The other list I'd like to start is a document (on the wiki) that explains tree wide changes with the revision in which they happened, what happened, and how to replay those changes on a locally modified tree - esp. those with new boards. Yep, this idea I like very much! I started an attempt here: http://www.coreboot.org/Flag_Days The name is taken from OpenSolaris, where flag days are events that break compatibility in some way. See http://hub.opensolaris.org/bin/view/Community+Group+on/flag-days Both layout and name can be changed if something better comes across. Consider this a work in progress. Patrick -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] [commit] r5153 - trunk/src/cpu/amd/car
Author: oxygene
Date: Tue Feb 23 22:43:42 2010
New Revision: 5153
URL: http://tracker.coreboot.org/trac/coreboot/changeset/5153
Log:
Clobber registers as appropriate in AMD CAR code, and
build a better barrier for gcc to reflush all registers
when moving the stack. memcpy was taken from Linux.
Signed-off-by: Rudolf Marek r.ma...@assembler.cz
Acked-by: Patrick Georgi patrick.geo...@coresystems.de
Modified:
trunk/src/cpu/amd/car/disable_cache_as_ram.c
trunk/src/cpu/amd/car/post_cache_as_ram.c
Modified: trunk/src/cpu/amd/car/disable_cache_as_ram.c
==
--- trunk/src/cpu/amd/car/disable_cache_as_ram.cTue Feb 23 21:31:37
2010(r5152)
+++ trunk/src/cpu/amd/car/disable_cache_as_ram.cTue Feb 23 22:43:42
2010(r5153)
@@ -2,62 +2,49 @@
/* be warned, this file will be used other cores and core 0 / node 0 */
static inline __attribute__((always_inline)) void disable_cache_as_ram(void)
{
-
-__asm__ volatile (
-
+__asm__ __volatile__ (
/* We don't need cache as ram for now on */
/* disable cache */
-movl%cr0, %eax\n\t
-orl$(0x130),%eax\n\t
-movl%eax, %cr0\n\t
+movl%%cr0, %%eax\n\t
+orl$(0x130),%%eax\n\t
+movl%%eax, %%cr0\n\t
/* clear sth */
-movl$0x269, %ecx\n\t /* fix4k_c8000*/
-xorl%edx, %edx\n\t
-xorl%eax, %eax\n\t
+movl$0x269, %%ecx\n\t /* fix4k_c8000*/
+xorl%%edx, %%edx\n\t
+xorl%%eax, %%eax\n\t
wrmsr\n\t
#if CONFIG_DCACHE_RAM_SIZE 0x8000
- movl$0x268, %ecx\n\t /* fix4k_c*/
+ movl$0x268, %%ecx\n\t /* fix4k_c*/
wrmsr\n\t
#endif
/* disable fixed mtrr from now on, it will be enabled by coreboot_ram
again*/
-movl$0xC0010010, %ecx\n\t
+movl$0xC0010010, %%ecx\n\t
//movl$SYSCFG_MSR, %ecx\n\t
rdmsr\n\t
-andl$(~(318)), %eax\n\t
+andl$(~(318)), %%eax\n\t
//andl$(~(SYSCFG_MSR_MtrrFixDramModEn |
SYSCFG_MSR_MtrrFixDramEn)), %eax\n\t
wrmsr\n\t
/* Set the default memory type and disable fixed and enable variable
MTRRs */
-movl$0x2ff, %ecx\n\t
+movl$0x2ff, %%ecx\n\t
//movl$MTRRdefType_MSR, %ecx\n\t
-xorl%edx, %edx\n\t
+xorl%%edx, %%edx\n\t
/* Enable Variable and Disable Fixed MTRRs */
-movl$0x0800, %eax\n\t
+movl$0x0800, %%eax\n\t
wrmsr\n\t
/* enable cache */
-movl%cr0, %eax\n\t
-andl$0x9fff,%eax\n\t
-movl%eax, %cr0\n\t
-
+movl%%cr0, %%eax\n\t
+andl$0x9fff,%%eax\n\t
+movl%%eax, %%cr0\n\t
+::: memory, eax, ecx, edx
);
}
static void disable_cache_as_ram_bsp(void)
{
- __asm__ volatile (
-// pushl %eax\n\t
- pushl %edx\n\t
- pushl %ecx\n\t
- );
-
disable_cache_as_ram();
-__asm__ volatile (
-popl %ecx\n\t
-popl %edx\n\t
-//popl %eax\n\t
-);
}
Modified: trunk/src/cpu/amd/car/post_cache_as_ram.c
==
--- trunk/src/cpu/amd/car/post_cache_as_ram.c Tue Feb 23 21:31:37 2010
(r5152)
+++ trunk/src/cpu/amd/car/post_cache_as_ram.c Tue Feb 23 22:43:42 2010
(r5153)
@@ -10,14 +10,20 @@
printk_debug(%s%08x\r\n, strval, val);
}
+/* from linux kernel 2.6.32 asm/string_32.h */
+
static void inline __attribute__((always_inline)) memcopy(void *dest, const
void *src, unsigned long bytes)
{
-__asm__ volatile(
-cld\n\t
-rep; movsl\n\t
-: /* No outputs */
-: S (src), D (dest), c ((bytes)2)
-);
+ int d0, d1, d2;
+ asm volatile(cld ; rep ; movsl\n\t
+ movl %4,%%ecx\n\t
+ andl $3,%%ecx\n\t
+ jz 1f\n\t
+ rep ; movsb\n\t
+ 1:
+ : =c (d0), =D (d1), =S (d2)
+ : 0 (bytes / 4), g (bytes), 1 ((long)dest), 2
((long)src)
+ : memory, cc);
}
/* Disable Erratum 343 Workaround, see RevGuide for Fam10h, Pub#41322 Rev 3.33
*/
@@ -66,27 +72,17 @@
/* from here don't store more data in CAR */
vErrata343();
-#if 0
-__asm__ volatile (
- pushl %eax\n\t
-);
-#endif
-
memcopy((void *)((CONFIG_RAMTOP)-CONFIG_DCACHE_RAM_SIZE), (void
*)CONFIG_DCACHE_RAM_BASE, CONFIG_DCACHE_RAM_SIZE); //inline
//dump_mem((CONFIG_RAMTOP) - 0x8000, (CONFIG_RAMTOP) - 0x7c00);
__asm__ volatile (
/* set new esp */ /*
Re: [coreboot] [PATCH] fix clobbers in the K8 CAR
Am 21.02.2010 23:42, schrieb Rudolf Marek: Hello, This patch adds clobber regs into the play as assembly trashes random registers. I was bitten by this while doing MSR I/O because ECX got corrupted. I attempted to create nice barrier for GCC while changing the stack location too. The memcpy code was taken from Linux kernel, dont know to whom attribute the copyright on it. If it is OK with the note, otherwise: Signed-off-by: Rudolf Marek r.ma...@assembler.cz Acked-by: Patrick Georgi patrick.geo...@coresystems.de and committed as r5153 -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] VIA-ME6000-LVDS coreboot capable?
Hi! I've got a VIA ME6000-LVDS (Board only says: EPIA-M rev B) Where i can't really confirm the north- and southbridge, as they're glued to a large passive cooler. Is that board compatible? I can supply photos but nothing software related (i'm trying to debrick the board using coreboot ;) cheers, riot -- Förderverein euregionale Digitalkultur e.V.! Für mehr Kultur in Aachen und der Euregio. https://fedev.eu | | https://fedev.eu/blog -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] VIA-ME6000-LVDS coreboot capable?
On 2/23/10 11:13 PM, Riot wrote: Hi! I've got a VIA ME6000-LVDS (Board only says: EPIA-M rev B) Where i can't really confirm the north- and southbridge, as they're glued to a large passive cooler. Is that board compatible? It looks very similar to the via epia-m in the tree. But we will never know unless someone tries it. I can supply photos but nothing software related (i'm trying to debrick the board using coreboot ;) How is it bricked? Stefan -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Tester hardware
On 23.02.2010 21:14, Peter Stuge wrote: Ward Vandewege wrote: The automatic testing framework Stepan built a few years ago - I'd love to get a few boards set up for that. I have some boards lying around that could be used for that. My main problem is cost: You're not alone. I've wanted to create affordable tester hardware for quite some time now. I think it's the only way we'll get more boot testing. [...] I think a small microcontroller and actual flash chips may be the simplest and cheapest way to do it. The microcontroller is for flashing from ALIX, maybe also GPO pins and serial port. Speaking with y flashrom hat on, I'd like to point out that you can use the FT2232H Mini Module (~$30) to perform in-system-programming (well, as long as the machine is powered of) of SPI flash chips right now and of LPC/FWH chips in the near future. Parallel flash chips need some small additional circuitry because the FT2232H doesn't have enough pins for output and can only deliver 3.3V, but that's it. Regards, Carl-Daniel -- I do consider assignment statements and pointer variables to be among computer science's most valuable treasures. -- Donald E. Knuth -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Tester hardware
On Wed, Feb 24, 2010 at 12:14:30AM +0100, Carl-Daniel Hailfinger wrote: On 23.02.2010 21:14, Peter Stuge wrote: Ward Vandewege wrote: The automatic testing framework Stepan built a few years ago - I'd love to get a few boards set up for that. I have some boards lying around that could be used for that. My main problem is cost: You're not alone. I've wanted to create affordable tester hardware for quite some time now. I think it's the only way we'll get more boot testing. [...] I think a small microcontroller and actual flash chips may be the simplest and cheapest way to do it. The microcontroller is for flashing from ALIX, maybe also GPO pins and serial port. Speaking with y flashrom hat on, I'd like to point out that you can use the FT2232H Mini Module (~$30) to perform in-system-programming (well, as long as the machine is powered of) of SPI flash chips right now and Oh. That sounds like a much more affordable solution! What kind of hardware would one use to hook the spi chip to the mini module? Some sort of top hat? of LPC/FWH chips in the near future. I guess for lpc/fwh (plcc), one of the plcc adapters Peter and Stepan make would do. Thanks, Ward. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Tester hardware
Ward Vandewege wrote: I think a small microcontroller and actual flash chips may be the simplest and cheapest way to do it. The microcontroller is for flashing from ALIX, maybe also GPO pins and serial port. Speaking with y flashrom hat on, I'd like to point out that you can use the FT2232H Mini Module (~$30) to perform in-system-programming (well, as long as the machine is powered of) In-system-programming is worth considering, but for boards with sockets it actually just creates extra work. In any case $30 for flash programming in the tester hardware is way unacceptable. I'm thinking that $10 is already nearly too high cost, but on the other hand it buys a very nice ARM7 with USB, which could be reused also independently of the tester. What kind of hardware would one use to hook the spi chip to the mini module? This is the question. Anything socketed is easy, but soldered down chips make it more difficult. For SO-8 I've only seen the IC-CLIP by Pomona, which doesn't attach with a very sturdy connection to chips. :\ //Peter -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [patch]: memcpy/memset inline asm config_compress disabled when needed
A couple of thoughts. Can we move the data as dwords instead of bytes
for uncompressed data? As for the cache, can you check the MTRRs and
CR0 before the copy? We should cache the cbfs instructions and data
being moved. Does the cbfs code need a call to setup the cache with
the source or should it be setup prior to calling cbfs?
Marc
On Mon, Feb 22, 2010 at 6:45 PM, Bao, Zheng zheng@amd.com wrote:
I think the memcpy/memset and decompressing are slow because of the Icache.
Only one instruction executes repeatedly in the asm code. It doesn't have to
access the instructions in the ROM every time. The memcpy/memset are easy to
narrow down to a single instruction. But ulzma() can not. So I don't like my
patch either. Does anybody have the idea to finally solve this problem?
Zheng
-Original Message-
From: ron minnich [mailto:rminn...@gmail.com]
Sent: Tuesday, February 23, 2010 12:29 AM
To: Bao, Zheng
Cc: coreboot@coreboot.org
Subject: Re: [coreboot] [patch]: memcpy/memset inline asm config_compress
disabled when needed
On Sun, Feb 21, 2010 at 8:48 PM, Bao, Zheng zheng@amd.com wrote:
Index: src/lib/memcpy.c
===
--- src/lib/memcpy.c (revision 5133)
+++ src/lib/memcpy.c (working copy)
@@ -3,10 +3,14 @@
{
const char *src = vsrc;
char *dest = vdest;
- int i;
- for (i = 0; i (int)bytes; i++)
- dest[i] = src[i];
+ __asm__ __volatile__ ( \
+ cld \n\t \
+ rep \n\t \
+ movsb \
+ : /* No output */ \
+ : S(src), D(dest), c(bytes) \
+ );
return vdest;
}
Index: src/lib/memset.c
===
--- src/lib/memset.c (revision 5133)
+++ src/lib/memset.c (working copy)
@@ -2,11 +2,15 @@
void *memset(void *s, int c, size_t n)
{
- int i;
char *ss = (char *) s;
- for (i = 0; i (int)n; i++)
- ss[i] = c;
+ __asm__ __volatile__ ( \
+ cld\n\t \
+ rep\n\t \
+ stosb \
+ : \
+ : a(c), D(ss), c(n) \
+ );
return s;
}
I'm glad this works, but I am afraid I have a concern about it.
I've become opposed to inline assembly on several principles in the
last few years:
- we've seen one problem after another as the manner in which __asm__
is supposed to be used has varied as gcc changes.
we've also had code that had errors in __asm__ which nobody noticed.
- I'd like to understand why the C code is so much worse. I can't see
a good reason for C to be so bad at this simple task.
For example, with the memset, what if we just created a memzero
function instead, which used a constant '0' instead of a parameter:
does the code improve?
- I now feel a .c file should contain C. If we need a .s, let's create a .s.
So, first, can we please have a look at the .s produced by the C code
and see if we can understand why it is so slow?
Thanks
Ron
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
--
http://se-eng.com
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] Partial 440BX RAM init by SPD - for the adventurous only!
Hello, This patch reads SPD data and sets the DRB registers so it no longer hard code for 64MB in bank 0. Theoretically I can stick three 256MB sticks and it'll read 768MB. I referred to both the SPD spec and 440BX datasheet when I wrote this, but it's too late at night in Toronto so testing will have to wait :-). As such this is for the highly adventurous to see and I don't expect this to be committed just yet. Also a question related to this: How can I get romcc to provide me an assembly listing of a C file compiled? I want to see the assembly code that compiling this generates. Anyway, I got tired of trying to trace the vendor BIOS I have and just coded this up from spec from scratch, so this should legally be safe, and thus... Signed-off-by: Keith Hui buu...@gmail.com 440bxraminit.patch Description: Binary data -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] More lists
On Tue, 23 Feb 2010, Patrick Georgi wrote: Am 23.02.2010 16:43, schrieb Uwe Hermann: The other list I'd like to start is a document (on the wiki) that explains tree wide changes with the revision in which they happened, what happened, and how to replay those changes on a locally modified tree - esp. those with new boards. Yep, this idea I like very much! I started an attempt here: http://www.coreboot.org/Flag_Days I'd like this idea too, at least could make live everyone who rarely svn up his unfinished targets a lot easier. And this problem hit me few times already. Patrick Maciej -- Maciej Pijanka I don't fear computers, I fear lack of them -- Isaac Asimov -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] AMD HT link frequency limit configuration patch
This patch allows the user to select a maximum HyperTransport link frequency.
Speed capping is required for maximum stability when attempting to use new
HT3 CPUs on older HT1 mainboards, as the physical inter-CPU traces on the
mainboard may not be able to reliably handle the faster HT3 link
frequency.
---
Signed-off-by: Timothy Pearson tpear...@raptorengineeringinc.com
Timothy Pearson
Raptor EngineeringIndex: h3finit.c
===
--- src/northbridge/amd/amdht/h3finit.c (revision 5119)
+++ src/northbridge/amd/amdht/h3finit.c (working copy)
@@ -1327,7 +1327,25 @@
for (i = 0; i pDat-TotalLinks*2; i += 2)
{
- cbPCBFreqLimit = 0x;
+#if CONFIG_LIMIT_HT_SPEED_200
+ cbPCBFreqLimit = 0x0001; // 200MHz
+#elif CONFIG_LIMIT_HT_SPEED_400
+ cbPCBFreqLimit = 0x0003; // 400MHz
+#elif CONFIG_LIMIT_HT_SPEED_600
+ cbPCBFreqLimit = 0x0007; // 600MHz
+#elif CONFIG_LIMIT_HT_SPEED_800
+ cbPCBFreqLimit = 0x000F; // 800MHz
+#elif CONFIG_LIMIT_HT_SPEED_1000
+ cbPCBFreqLimit = 0x001F; // 1.0GHz
+#elif CONFIG_LIMIT_HT_SPEED_1200
+ cbPCBFreqLimit = 0x003F; // 1.2GHz
+#elif CONFIG_LIMIT_HT_SPEED_1400
+ cbPCBFreqLimit = 0x007F; // 1.4GHz
+#elif CONFIG_LIMIT_HT_SPEED_1600
+ cbPCBFreqLimit = 0x00FF; // 1.6GHz
+#else
+ cbPCBFreqLimit = 0x; // Maximum allowed by autoconfiguration
+#endif
cbPCBABDownstreamWidth = 16;
cbPCBBAUpstreamWidth = 16;
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] MP table multicore patch
So two more steps are necessary: - check all the downwards links of a device instead of just walking devices and checking their type. - run recursively in a special case on APIC clusters. This sounds a whole lot like something changed in the way all_devices works. And if all_devices does not mean all devices I am sure there are more places in our code that need similar fixes. This is the crux of the issue. all_devices does NOT mean all devices, it means all devices attached to the root node, which is all_devices. As the root node, usually the PCI bus and the APICs are visible. On my board, the APICs are all under an APIC cluster, so they are not immediately visible from the root node. Incidentally, there is code already in Coreboot (to generate the PCI device lists) that takes all_devices and simply probes the PCI downward link. It (sanely, IMHO) does not expect to see PCI devices on the all_devices root node. I don't have access to a board that I can generate before/after tables with at this time. This behavior is very simple to see though; if you turn on printk spew and look closely at the printed detected device tables on any amdfam10 board, you will see the root node only connects to the APIC cluster and the PCI root bus(es). If you have any more questions feel free to ask! Hopefully the root cause of the problem can be located and solved. Timothy Pearson Raptor Engineering -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Executing bootstrap from MBR in coreboot
2010/2/23 Peter Stuge pe...@stuge.se: As Joseph pointed out you could look at SeaBIOS, which has quickly become a very complete BIOS implementation. SeaBIOS runs well as a coreboot payload, and if you combine coreboot and SeaBIOS you will indeed have a legacy compatible open source firmware. I'm afraid that I will have to write my own part of code which will be responsible to execute a boostrap. At this moment I use the old version of coreboot project (practically LinuxBIOS 2.0.0), because only in this release my target board (MSM800BEV) is fully supported out of the box. Unfortunately, it doesn't contain the uint64_t high_tables_base = 0; uint64_t high_tables_size; variables which are necessary to proper SeaBIOS work (according with http://www.coreboot.org/SeaBIOS document). Maybe do you have any documents or advices about using SeaBIOS with this coreboot version? Thanks for your interest. -- Piotr Piwko http://www.embedded-engineering.pl/ -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
