Re: [coreboot] [PATCH]more kconfig
Patrick Georgi wrote: I was going to test boot my epia-cn with a kconfig build, but I noticed that auto.c got compiled with gcc instead of romcc. Oops, must have been an error when doing the mass conversion. Attached patch should fix that. Thanks for the report. 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
Re: [coreboot] [PATCH]kconfig and romcc
Patrick Georgi wrote: attached patches add support for tinybootblock to the generic Makefile.romccboard.inc, and move dell/s1850 (non-tinybootblock) and emulation/qemu-x86 (tinybootblock) to use that instead of their own set of rules. Why is s1850 not using TINY_BOOTBLOCK? Is it a technical problem or a matter of not-done-yet? emulation/qemu-x86 is boot tested. All romcc-boards use Makefile.romccboard.inc after these patches. 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
Re: [coreboot] [PATCH]kconfig and romcc
Am 08.01.2010 12:06, schrieb Peter Stuge: Why is s1850 not using TINY_BOOTBLOCK? Is it a technical problem or a matter of not-done-yet? not-done-yet. I don't know if it requires a rom enable sequence. If yes, it's not implemented yet (which might be considered a technical problem). Acked-by: Peter Stuge pe...@stuge.se Thanks, Patrick -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] [commit] r5005 - in trunk: src/arch/i386 src/mainboard src/mainboard/dell/s1850 src/mainboard/emulation/qemu-x86 src/mainboard/via/epia-cn util/compareboard
Author: oxygene Date: 2010-01-08 12:26:02 +0100 (Fri, 08 Jan 2010) New Revision: 5005 Modified: trunk/src/arch/i386/Kconfig trunk/src/mainboard/Makefile.romccboard.inc trunk/src/mainboard/dell/s1850/Makefile.inc trunk/src/mainboard/emulation/qemu-x86/Makefile.inc trunk/src/mainboard/via/epia-cn/Makefile.inc trunk/util/compareboard/compareboard Log: - Makefile.romccboard.inc supports tinybootblock romcc boards, too. - via/epia-cn is a romcc board, not a CAR board. (Thanks Kevin, for the report) - Make emulation/qemu-x86, dell/s1850, via/epia-cn use Makefile.romccboard.inc - New flag: BIG_BOOTBLOCK, which is always the inverse of tinybootblock Suitable for Makefile.inc rules (foo-$(CONFIG_BIG_BOOTBLOCK) += ...) Signed-off-by: Patrick Georgi patrick.geo...@coresystems.de Acked-by: Peter Stuge pe...@stuge.se Modified: trunk/src/arch/i386/Kconfig === --- trunk/src/arch/i386/Kconfig 2010-01-07 21:37:18 UTC (rev 5004) +++ trunk/src/arch/i386/Kconfig 2010-01-08 11:26:02 UTC (rev 5005) @@ -44,6 +44,11 @@ bool default n +config BIG_BOOTBLOCK + bool + default n if TINY_BOOTBLOCK + default y + config BOOTBLOCK_NORTHBRIDGE_INIT string Modified: trunk/src/mainboard/Makefile.romccboard.inc === --- trunk/src/mainboard/Makefile.romccboard.inc 2010-01-07 21:37:18 UTC (rev 5004) +++ trunk/src/mainboard/Makefile.romccboard.inc 2010-01-08 11:26:02 UTC (rev 5005) @@ -19,27 +19,27 @@ ## initobj-y += crt0.o -crt0-y += ../../../../src/cpu/x86/16bit/entry16.inc +crt0-$(CONFIG_BIG_BOOTBLOCK) += ../../../../src/cpu/x86/16bit/entry16.inc crt0-y += ../../../../src/cpu/x86/32bit/entry32.inc -crt0-y += ../../../../src/cpu/x86/16bit/reset16.inc -crt0-y += ../../../../src/arch/i386/lib/cpu_reset.inc -crt0-y += ../../../../src/arch/i386/lib/id.inc +crt0-$(CONFIG_BIG_BOOTBLOCK) += ../../../../src/cpu/x86/16bit/reset16.inc +crt0-$(CONFIG_BIG_BOOTBLOCK) += ../../../../src/arch/i386/lib/cpu_reset.inc +crt0-$(CONFIG_BIG_BOOTBLOCK) += ../../../../src/arch/i386/lib/id.inc crt0-y += ../../../../src/cpu/x86/fpu_enable.inc crt0-$(CONFIG_CPU_AMD_GX1) += ../../../../src/cpu/amd/model_gx1/cpu_setup.inc crt0-$(CONFIG_CPU_AMD_GX1) += ../../../../src/cpu/amd/model_gx1/gx_setup.inc crt0-$(CONFIG_SSE) += ../../../../src/cpu/x86/sse_enable.inc -crt0-y += failover.inc +crt0-$(CONFIG_BIG_BOOTBLOCK) += failover.inc crt0-y += auto.inc crt0-$(CONFIG_SSE) += ../../../../src/cpu/x86/sse_disable.inc crt0-$(CONFIG_MMX) += ../../../../src/cpu/x86/mmx_disable.inc ldscript-y += ../../../../src/arch/i386/init/ldscript_fallback_cbfs.lb -ldscript-y += ../../../../src/cpu/x86/16bit/entry16.lds +ldscript-$(CONFIG_BIG_BOOTBLOCK) += ../../../../src/cpu/x86/16bit/entry16.lds ldscript-y += ../../../../src/cpu/x86/32bit/entry32.lds -ldscript-y += ../../../../src/cpu/x86/16bit/reset16.lds -ldscript-y += ../../../../src/arch/i386/lib/id.lds -ldscript-y += ../../../../src/arch/i386/lib/failover.lds +ldscript-$(CONFIG_BIG_BOOTBLOCK) += ../../../../src/cpu/x86/16bit/reset16.lds +ldscript-$(CONFIG_BIG_BOOTBLOCK) += ../../../../src/arch/i386/lib/id.lds +ldscript-$(CONFIG_BIG_BOOTBLOCK) += ../../../../src/arch/i386/lib/failover.lds driver-y += mainboard.o Modified: trunk/src/mainboard/dell/s1850/Makefile.inc === --- trunk/src/mainboard/dell/s1850/Makefile.inc 2010-01-07 21:37:18 UTC (rev 5004) +++ trunk/src/mainboard/dell/s1850/Makefile.inc 2010-01-08 11:26:02 UTC (rev 5005) @@ -1,63 +1,3 @@ -## -## This file is part of the coreboot project. -## -## Copyright (C) 2009 Uwe Hermann u...@hermann-uwe.de -## -## This program is free software; you can redistribute it and/or modify -## it under the terms of the GNU General Public License as published by -## the Free Software Foundation; either version 2 of the License, or -## (at your option) any later version. -## -## 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 -## +ROMCCFLAGS := -mcpu=p4 -O2 +include $(src)/mainboard/Makefile.romccboard.inc -initobj-y += crt0.o -crt0-y += ../../../../src/cpu/x86/16bit/entry16.inc -crt0-y += ../../../../src/cpu/x86/32bit/entry32.inc -crt0-y += ../../../../src/cpu/x86/16bit/reset16.inc -crt0-y += ../../../../src/arch/i386/lib/cpu_reset.inc -crt0-y += ../../../../src/arch/i386/lib/id.inc -crt0-y += ../../../../src/cpu/x86/fpu_enable.inc -crt0-y += ../../../../src/cpu/x86/sse_enable.inc -crt0-y += failover.inc
Re: [coreboot] When should we retire newconfig?
On January 8, 2010 at 7:37 AM Patrick Georgi patr...@georgi-clan.de wrote: Am 08.01.2010 01:09, schrieb j...@settoplinux.org: Hello Patrick, Are there any boards that have completely crossed over that I can look at for an example? All boards still work on newconfig - once we drop that, there are several possibilities for cleaning up. Boards that were recently tested with kconfig and tinybootblock: emulation/qemu-x86 kontron/986lcd-m amd/serengeti_cheetah_fam10 asus/m2v-mx_se Is there some kind of guilde line or list of things that need to be done to cleanup/convert on each board? Thanks, Joseph Smith Set-Top-Linux www.settoplinux.org -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] FOSDEM2010 devroom needs speakers :)
On Fri, Jan 08, 2010 at 12:39:05AM +0100, Rudolf Marek wrote: Hi again, Btw what is the duration of the talk? Aim for 45 minutes. Slots are 1h, but people move in and out on the hourly edges anyway, and then there is some time to resync, and get stuff set up for the next talk, etc. So aim for 45 minutes, if it is a bit more, then no problem, you will get stopped at the hour. Rudolf Marek - ACPI and Suspend/Resume under coreboot Ever wanted to know more about ACPI? The aim of the talk is to introduce the software part of ACPI as well as provide the necessary hardware details to get the bigger picture. The tour through Coreboot ACPI implementation will be given. Suspend and resume procedure will be presented with all nifty parts explained. Thats it. I think I need like hour or hour and half for this. Do you like it? What sort of audience should I expect? Developers and advanced users, i think full house easily (in this case 50 people), everyone is very friendly and helpful on fosdem. Perhaps it could even start with a question - what OS needs to know about the hardware - and then show how it is connected to the ACPI (irq routing, PM, PCI buses). When done, one could show how this is implemented in Coreboot/what files and what does it do. Plus perhaps some hints how to port ACPI to some new board. At the end I would like to describe the suspend/resume with some details and pitfalls. Maybe some a or the is missing in the abstract. We don't use them in Czech language so I don't have big sense for them. Thanks, Rudolf I know, SUSE has a prague office :) All sounds good, but you will have to tone it down to ~45 minutes. Luc Verhaegen. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] coreboot and MSM800BEV
OK, I removed all references to DIMM1 memory (there is only DIMM0 on MSM800BEV board) and the SMBUS READ ERROR:03 device:a2 error doesn't occur - please see attached log. My booting process as previously hangs on Uncompressing coreboot to ram. I suppose this situation is related with copying data from cache into RAM memory in cpu/amd/car/cache_as_ram.inc file, the suitable part: - [ cpu/amd/car/cache_as_ram.inc ] - __main: CONSOLE_DEBUG_TX_STRING($str_copying_to_ram) /* * Copy data into RAM and clear the BSS. Since these segments * isn\'t really that big we just copy/clear using bytes, not * double words. */ intel_chip_post_macro(0x11) /* post 11 */ cld /* clear direction flag */ /* copy coreboot from it's initial load location to * the location it is compiled to run at. * Normally this is copying from FLASH ROM to RAM. */ movl%ebp, %esi /* FIXME: look for a proper place for the stack */ movl$0x400, %esp movl%esp, %ebp pushl %esi pushl $str_coreboot_ram_name call cbfs_and_run_core -- It prints $str_coreboot_ram_name (Uncompressing coreboot to ram) and hangs after calling cbfs_and_run_core function. I think that I should set a proper memory address for stack. As we can see the default address (0x400) is wrong but which one is correct? Can you give my any hints? Thanks in advance -- Piotr Piwko http://www.embedded-engineering.pl/ coreboot-2.0.0-r4949M.0Fallback pi�ą, 8 sty 2010, 13:26:09 CET starting... _MSR GLCP_SYS_RSTPLL (4c14) value is: 0392:180c Configuring PLL coreboot-2.0.0-r4949M.0Fallback pi�ą, 8 sty 2010, 13:26:09 CET starting... _MSR GLCP_SYS_RSTPLL (4c14) value is: 0392:07de000c Done pll_reset Castle 2.0 BTM periodic sync period. Enable Quack for fewer re-RAS on the MC GLIU port active enable Set the Delay Control in GLCP Try to write GLCP_DELAY_CONTROLS: hi 83f100aa and lo 56960004 SetDelayControl done Enable RSDC FPU imprecise exceptions bit Enable Suspend on HLT PAUSE instructions Enable SUSP and allow TSC to run in Suspend Setup throttling delays to proper mode Done cpuRegInit Ram1.00 Ram2.00 ===sdram_set_spd_register == ===Check DIMM 0== ===Check DDR MAX== ===AUTOSIZE DIMM 0== ===Check present== ===MODBANKS== ===FIELDBANKS== ===SPDNUMROWS== ===SPDBANKDENSITY== ===DIMMSIZE== ===BEFORT CTZ== ===TEST DIMM SIZE8= ===PAGESIZE== ===MAXCOLADDR== ===12address test== ===RDMSR CF07== ===WRMSR CF07== ===ALL DONE== ===set cas latency== ===set all latency== ===set emrs== ===set ref rate== Ram3 DRAM controller init done. RAM DLL lock Ram4 Testing DRAM : - 000a DRAM fill: 0x-0x000a 000a DRAM filled DRAM verify: 0x-0x000a 000a DRAM range verified. Done. POST 02 Past wbinvd Uncompressing coreboot to ram. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] coreboot and MSM800BEV
Am 08.01.2010 13:57, schrieb Piotr Piwko: It prints $str_coreboot_ram_name (Uncompressing coreboot to ram) and hangs after calling cbfs_and_run_core function. I think that I should set a proper memory address for stack. As we can see the default address (0x400) is wrong but which one is correct? Can you give my any hints? It's not wrong, it's just an issue once suspend-to-ram etc. come into play - that's why I added this remark to the arbitrary value I used there. This value will be an issue if you have 64MB RAM (and with 64MB it might be a problem, too) How long did you wait? it _might_ be that it merely takes a very long time. That must of course be fixed, but is not the same problem as a hanging system. Patrick -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] FOSDEM2010 devroom needs speakers :)
Am Freitag, den 08.01.2010, 13:44 +0100 schrieb Luc Verhaegen: On Fri, Jan 08, 2010 at 12:39:05AM +0100, Rudolf Marek wrote: Btw what is the duration of the talk? Aim for 45 minutes. Slots are 1h, but people move in and out on the hourly edges anyway, and then there is some time to resync, and get stuff set up for the next talk, etc. So aim for 45 minutes, if it is a bit more, then no problem, you will get stopped at the hour. […] All sounds good, but you will have to tone it down to ~45 minutes. Or Rudolf can split this up into two talks. Thanks, Paul signature.asc Description: Dies ist ein digital signierter Nachrichtenteil -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] FOSDEM2010 devroom needs speakers :)
On Fri, Jan 08, 2010 at 02:45:00PM +0100, Paul Menzel wrote: Am Freitag, den 08.01.2010, 13:44 +0100 schrieb Luc Verhaegen: On Fri, Jan 08, 2010 at 12:39:05AM +0100, Rudolf Marek wrote: Btw what is the duration of the talk? Aim for 45 minutes. Slots are 1h, but people move in and out on the hourly edges anyway, and then there is some time to resync, and get stuff set up for the next talk, etc. So aim for 45 minutes, if it is a bit more, then no problem, you will get stopped at the hour. […] All sounds good, but you will have to tone it down to ~45 minutes. Or Rudolf can split this up into two talks. Thanks, Paul a 45 minute talk is pretty enduring, not only for the speaker but also for the public :) But when not all slots are filled up, then nothing stops this, but we will pause for a bit on the hour. Luc Verhaegen. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] When should we retire newconfig?
All boards still work on newconfig - once we drop that, there are several possibilities for cleaning up. Boards that were recently tested with kconfig and tinybootblock: emulation/qemu-x86 kontron/986lcd-m amd/serengeti_cheetah_fam10 asus/m2v-mx_se with kconfig, but not with tiny bootblock: I've tested: tyan/s2895 tyan/s2892 Hugh's tested: arima/hdama Is there some kind of guilde line or list of things that need to be done to cleanup/convert on each board? I would say: 1. Run util/kbuildall/kbuildall vendor/board 2. Fix Kconfig mismatches in src/mainboard/vendor/board/Kconfig 3. Build and boot test (and report to the list) Soon we'll need to start only reporting Kconfig build errors on the mailing list. Then we can fix kbuildall to use an older version of newconfig for its comparisons, then we'll be able to phase it out. Thanks, Myles -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] coreboot and MSM800BEV
2010/1/8 Patrick Georgi patr...@georgi-clan.de:
How long did you wait? it _might_ be that it merely takes a very long
time. That must of course be fixed, but is not the same problem as a
hanging system.
I wait for about 15-20 min and nothing special. I put some 'postcode'
functions for debug capability and I've found out that it hangs on
'cbfs_load_stage' function when it calls cbfs_find_file:
-[ lib/cbfs.c ]
// ...
void * cbfs_load_stage(const char *name)
{
struct cbfs_stage *stage = (struct cbfs_stage *)
cbfs_find_file(name, CBFS_TYPE_STAGE);
/* this is a mess. There is no ntohll. */
/* for now, assume compatible byte order until we solve this. */
u32 entry;
outb(0xaa, 0x80);// --- It doesn't occur
if (stage == NULL)
return (void *) -1;
printk_info(Stage: loading %s @ 0x%x (%d bytes), entry @ 0x%llx\n,
name,
(u32) stage-load, stage-memlen,
stage-entry);
memset((void *) (u32) stage-load, 0, stage-memlen);
if (cbfs_decompress(stage-compression,
((unsigned char *) stage) +
sizeof(struct cbfs_stage),
(void *) (u32) stage-load,
stage-len))
return (void *) -1;
printk_debug(Stage: done loading.\n);
entry = stage-entry;
// entry = ntohl((u32) stage-entry);
return (void *) entry;
}
// ...
---
On Monday I will test the cbfs_find_file function. I hope I will found
something.
Have a good weekend!
--
Piotr Piwko
http://www.embedded-engineering.pl/
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] coreboot and MSM800BEV
Am 08.01.2010 18:32, schrieb Piotr Piwko:
2010/1/8 Patrick Georgi patr...@georgi-clan.de:
How long did you wait? it _might_ be that it merely takes a very long
time. That must of course be fixed, but is not the same problem as a
hanging system.
I wait for about 15-20 min and nothing special. I put some 'postcode'
functions for debug capability and I've found out that it hangs on
'cbfs_load_stage' function when it calls cbfs_find_file:
-[ lib/cbfs.c ]
// ...
void * cbfs_load_stage(const char *name)
{
struct cbfs_stage *stage = (struct cbfs_stage *)
cbfs_find_file(name, CBFS_TYPE_STAGE);
/* this is a mess. There is no ntohll. */
/* for now, assume compatible byte order until we solve this. */
u32 entry;
outb(0xaa, 0x80);// --- It doesn't occur
In that case, your ROM is probably not entirely mapped yet. That's an
issue that has to be fixed per chipset (southbridge mostly).
I see explicit support for it in cs5530 (even though that _might_
require some more changes), and somewhere in the code of cs5535. I don't
know if this is applicable to cs5536, too. If you want to try, this hack
might help you (untested, as I don't have the hardware). Maybe the call
must be moved around a bit.
Thanks for your effort,
Patrick
--- src/mainboard/digitallogic/msm800sev/auto.c (revision 5003)
+++ src/mainboard/digitallogic/msm800sev/auto.c (working copy)
@@ -14,6 +14,7 @@
#include cpu/x86/bist.h
#include cpu/x86/msr.h
#include cpu/amd/lxdef.h
+#include southbridge/amd/cs5530/cs5530_enable_rom.c
//#define SERIAL_DEV PNP_DEV(0x2e, W83627HF_SP1)
@@ -114,6 +115,7 @@
msr_init(); //GX3 OK
+ cs5530_enable_rom();
cs5536_early_setup(); //GX3 OK
/* NOTE: must do this AFTER the early_setup!
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH]kconfig and romcc
On Fri, Jan 08, 2010 at 09:15:05AM +0100, Patrick Georgi wrote: Hi, attached patches add support for tinybootblock to the generic Makefile.romccboard.inc, and move dell/s1850 (non-tinybootblock) and emulation/qemu-x86 (tinybootblock) to use that instead of their own set of rules. emulation/qemu-x86 is boot tested. All romcc-boards use Makefile.romccboard.inc after these patches. Thanks! I've boot tested epia-cn with a Kconfig build. I did need to add: select TSC_X86RDTSC_CALIBRATE_WITH_TIMER2 to src/mainboard/via/epia-cn/Kconfig. I also added: obj-$(CONFIG_GENERATE_ACPI_TABLES) += fadt.o obj-$(CONFIG_GENERATE_ACPI_TABLES) += dsdt.o obj-$(CONFIG_GENERATE_ACPI_TABLES) += acpi_tables.o to src/mainboard/Makefile.romccboard.inc. Also, I noted that epia-m is also not setup to use romcc. -Kevin -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH]kconfig and romcc
On Fri, Jan 08, 2010 at 07:52:57PM -0500, Kevin O'Connor wrote: On Fri, Jan 08, 2010 at 09:15:05AM +0100, Patrick Georgi wrote: attached patches add support for tinybootblock to the generic Makefile.romccboard.inc, and move dell/s1850 (non-tinybootblock) and emulation/qemu-x86 (tinybootblock) to use that instead of their own set of rules. I just booted my epia-cn with Kbuild and tinybootblock. I enabled tinybootblock by adding a select TINY_BOOTBLOCK to the epia-cn/Kconfig file. This did boot, but it took a very long time, because the romstage XIP code wasn't cached (running lzma uncompression without cache is crazy). I was able to fix it by adding: config XIP_ROM_BASE hex default 0xfff0 config XIP_ROM_SIZE hex default 0x10 to the Kbuild file to force code caching. (Though, I'm not sure how much of this is because of other changes in my tree to enable caching.) -Kevin -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
