[coreboot] FlashROM on VIA EPIA EN12000EG
Hi, this is just to report that I succeeded reading the BIOS using FlashROM 0.9.0 from my VIA EPIA EN12000EG motherboard. I haven't tried writing the BIOS yet. The only small issue I had was that my motherboard is reported to be from the CN rather than the EN series: Calibrating delay loop... OK. No coreboot table found. Found chipset VIA VT8237, enabling flash write... OK. Found board VIA EPIA-CN, enabling flash write... OK. Found chip SST SST49LF004A/B (512 KB) at physical address 0xfff8. Reading flash... done. I don't know if it's even technically possible to distinguish the CN and EN series, or if they are simply too close / almost identical from a chipset etc. view, but I'd be happy to help out improving this, if I can. -- Sebastian Schuberth -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] locking...
On 20.06.2009 2:46 Uhr, Carl-Daniel Hailfinger wrote: A quick test abuild with #error inserted in the lockless function shows we indeed use it for every freaking x86 target. That explains the supermicro/h8dme intertwined printk messages Ward is seeing. They're from ram init stage afaict ... If we need them instead of the generic variants, we should know a reason for such usage. Yes, the reasons are - no console drivers in the stage2/coreboot_ram style at this level - no spinlocking because we have no ram that is available to and shared by all cpus Besides that, do we know where static spinlock_t console_lock is placed? In RAM So we'd get uninitialied data for any pre-RAM spinlock access? The v3 global variable mechanism should solve this nicely. At least it was designed for that. But was it designed for safe IPC (Inter Processor Communication ;-) ? 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
Re: [coreboot] locking...
On 20.06.2009 2:50 Uhr, ron minnich wrote:
On Fri, Jun 19, 2009 at 5:17 PM, Stefan Reinauerste...@coresystems.de wrote:
Carl-Daniel Hailfinger wrote:
do_printk is defined in src/arch/i386/lib/printk_init.c as almost
identical function, but without console_tx_flush and without locking. If
only one CPU uses the lockless variant, we lose.
This is the version that was intended to be used when CONFIG_USE_INIT is
set.
reminder. do_printk is (or should be) used ONLY in the CAR code. It
does not use variables that are only available in the RAM code, such
as the console_drivers structure .
All versions of printk_debug() use a do_printk() implementation.
Then there's print_debug, being the weaker version of printk_debug. But
print_debug which can not do variables should not be used in CAR code.
Instead you should set the CONFIG_USE_PRINTK_IN_CAR (?) option and use
printk_debug instead.
printk_debug is a wrapper around do_printk() which calls do_printk with
BIOS_DEBUG as first parameter, that's it.
There is a do_printk for CAR in src/arch/i386/lib/printk_init.c however
and one for stage2 in src/console/printk.c
Don't assume you can just stop using it. It is that way for a reason,
as I found out very recently with the qemu CAR changes.
Note that printk calls console_tx_byte, which does this:
static void __console_tx_byte(unsigned char byte)
{
struct console_driver *driver;
for(driver = console_drivers; driver econsole_drivers; driver++) {
driver-tx_byte(byte);
}
}
do_printk calls its very own console_tx_byte, which is this:
void console_tx_byte(unsigned char byte)
{
if (byte == '\n')
uart8250_tx_byte(TTYS0_BASE, '\r');
uart8250_tx_byte(TTYS0_BASE, byte);
}
So it's a lot more than just not calling console_tx_flush. These are
not insignificant differences.
I am just trying to wave a caution flag here.
Absolutely agreed, and we shouldn't change anything on the struct
console_driver level. At all
You must take some care before you decide you can replace do_printk
with printk.
Nope... I started doing some replacements in our internal tree a few
weeks/months back and it works like a charme.
They're not even compiled into the same stage (or should
not be).
There does not even exist a printk in coreboot v2, right now. So they
are only compiled into different projects ;)
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
Re: [coreboot] locking...
On 20.06.2009 2:56 Uhr, ron minnich wrote: it's more than spinlock. you must also fix the use of the console_drivers struct. There are several things you need to get right to make this work. I am not sure I see the point. You're going to make lots of changes and in the end, using cpp magic, have a unified function which acts differently depending on how it's compiled. eek. The point is to have a single version of a printk like function. Two printk like functions would work nicely, too. But at the moment there's what, 6 implementations times 10 log levels? There's a lot of layers that we don't really need. It makes the most sense to me to have a RAM printk and a ROM printk which are for different purposes. They already share the most important common piece, which is vtxprintf. Yes. And a non-CAR printk, which is print, which works in romcc ;) But if you insist on unifying them you need to read the two parallel functions carefully and I guess do the #ifdef dance. that was never the discussion. at least from my side. The idea is to drop the macros that look like #define printk_debug(foo...) do_printk(BIOS_DEBUG, foo) and replace them by #define printk(x...) do_printk(x) and start using printk(BIOS_DEBUG, %x\n, var); in stage 2 code. That also works nicely for the CAR case. Just the ROMCC case needs to stay old, but that's fine. It's only there for old and broken architectures that can't do CAR, so it is allowed to look ugly. -- 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] locking...
On 20.06.2009 2:57 Uhr, Carl-Daniel Hailfinger wrote: On 20.06.2009 02:39, ron minnich wrote: On Fri, Jun 19, 2009 at 4:46 PM, Carl-Daniel Hailfinger wrote do_printk is defined in src/arch/i386/lib/printk_init.c as almost identical function, but without console_tx_flush and without locking. If only one CPU uses the lockless variant, we lose. it's very useful. It can be used in the rom/CAR code before consoles really work. Hm. AFAICS both versions have the same console requirements and just differ in locking (if you ignore the _flush no-op). This kind of thing is common. Just about all OSes have a printk before printk function. True, but our console requirements for both versions are pretty minimal and I think we showed in v3 that a one-size-fits-all printk can work fine. It didn't, that's the point.. No locking, and it destroyed output of i.e. a GDB interface by appending (CB) to each line. Plus, the ifdef mess is really not (much?) nicer to look at than the linker sets. One thing I think v3 does right is to not come with a VGA console. I still think that every line of coreboot output is always a debugging message. If your machine is so b0rked you can't get to the payload (but survive far enough to enable vga, which wis realistic in 0% of the cases, except you're a developer working on the table creation code) you shouldn't be bothered with text messages on vga but instead connect a serial console. 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
Re: [coreboot] New contact address of Philipp Degler?
On Monday 08 June 2009 16:22:45 Uwe Hermann wrote: Hi, I was asked if we have a working email address from Philipp Degler pdeg...@rumms.uni-mannheim.de who did some coreboot stuff in the past? His old address seems to be no longer valid, and I wasn't able to find a new and working one. Anyone who knows more? Thanks, Uwe. Hi Uwe, sorry for responding that late. Since I finished my studies at the university of Mannheim in 2007 I did not had the time to actively follow the list any longer. Also my former mail account was deleted. You can now reach me via degl...@googlemail.com. philipp -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] useful hardware - dip8 to soic8 adapter
Urja Rannikko wrote: The cards can also have rather complex voltage requirements. Complex = 3.3V? (depends on the card though) Right, it depends on the card. The card has a descriptor which should be read to find out which operating voltage to use. //Peter -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] useful hardware - dip8 to soic8 adapter
Warren Turkal wrote: Honestly, I was thinking of getting the adapter I linked to and getting the reverse adapter and soldering the exact serial flash chip that is currently on my motherboard onto the reverse adapter. Then I could have a few of those. Because that have the exact same chip, I'd hope that I could just plug it in and expect it to work. Yep, that would work just fine. //Peter -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] FlashROM on VIA EPIA EN12000EG
Sebastian Schuberth wrote: I don't know if it's even technically possible to distinguish the CN and EN series, or if they are simply too close / almost identical from a chipset etc. view, Yep, they are. but I'd be happy to help out improving this, if I can. I think the solution is to just change the string, since the code does what it should. //Peter -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] [PATCH] remove namestring trickery
Hello,
The namestring handling in ACPIgen was a big trickery. We were pasing the
strings as it was a bytestream already. This was a reason for instead of
_PR one had to write _PR_
Or \_SB.PCI0 was in fact \_SB_PCI0.
This patch adds a proper namestring generation to our ACPIgen generator.
Its used for Name and Scope and Processor now. As bonus, it allows to create a
multi name paths too. Like Scope(\ALL.YOUR.BASE).
Signed-off-by: Rudolf Marek r.ma...@assembler.cz
I have no board now, so I cannot test it on real HW. I did some tests which a
ACPIgen testbench which I'm attaching for future reference.
I dont know what happen to fam10 code, but I think it will need similar change.
Rudolf
Index: src/cpu/amd/model_fxx/powernow_acpi.c
===
--- src/cpu/amd/model_fxx/powernow_acpi.c (revision 4367)
+++ src/cpu/amd/model_fxx/powernow_acpi.c (working copy)
@@ -376,7 +376,7 @@
int amd_model_fxx_generate_powernow(u32 pcontrol_blk, u8 plen, u8 onlyBSP) {
int lens;
- char pscope[] = \\_PR_;
+ char pscope[] = \\_PR;
lens = acpigen_write_scope(pscope);
lens += pstates_algorithm(pcontrol_blk, plen, onlyBSP);
Index: src/northbridge/amd/amdk8/amdk8_acpi.c
===
--- src/northbridge/amd/amdk8/amdk8_acpi.c (revision 4367)
+++ src/northbridge/amd/amdk8/amdk8_acpi.c (working copy)
@@ -270,7 +270,7 @@
{
int lens;
msr_t msr;
- char pscope[] = \\._SB_PCI0;
+ char pscope[] = \\_SB.PCI0;
lens = acpigen_write_scope(pscope);
lens += k8acpi_write_pci_data(4, BUSN, 0xe0);
Index: src/arch/i386/boot/acpigen.c
===
--- src/arch/i386/boot/acpigen.c (revision 4367)
+++ src/arch/i386/boot/acpigen.c (working copy)
@@ -147,22 +147,111 @@
return size;
}
+/* The NameString are bit tricky, each element can be 4 chars, if
+ less its padded with underscore. Check 18.2.2 and 18.4
+ and 5.3 of ACPI specs 3.0 for details
+*/
+
+static int acpigen_emit_simple_namestring(char *name) {
+ int i, len = 0;
+ char ud[] = ;
+ for (i = 0; i 4; i++) {
+ if ((name[i] == '\0') || (name[i] == '.')) {
+ len += acpigen_emit_stream(ud, 4 - i);
+ break;
+ } else {
+ len += acpigen_emit_byte(name[i]);
+ }
+ }
+ return len;
+}
+
+static int acpigen_emit_double_namestring(char *name, int dotpos) {
+ int len = 0;
+ /* mark dual name prefix */
+ len += acpigen_emit_byte(0x2e);
+ len += acpigen_emit_simple_namestring(name);
+ len += acpigen_emit_simple_namestring(name[dotpos + 1]);
+ return len;
+}
+
+static int acpigen_emit_multi_namestring(char *name) {
+ int len = 0, count = 0;
+ unsigned char *pathlen;
+ /* mark multi name prefix */
+ len += acpigen_emit_byte(0x2f);
+ len += acpigen_emit_byte(0x0);
+ pathlen = ((unsigned char *) acpigen_get_current()) - 1;
+
+ while (name[0] != '\0') {
+ len += acpigen_emit_simple_namestring(name);
+ /* find end or next entity */
+ while ((name[0] != '.') (name[0] != '\0'))
+ name++;
+ /* forward to next */
+ if (name[0] == '.')
+ name++;
+ count++;
+ }
+
+ pathlen[0] = count;
+ return len;
+}
+
+
+int acpigen_emit_namestring(char *namepath) {
+ int dotcount = 0, i;
+ int dotpos;
+ int len = 0;
+
+ /* we can start with a \ */
+ if (namepath[0] == '\\') {
+ len += acpigen_emit_byte('\\');
+ namepath++;
+ }
+
+ /* and there can be any number of ^ */
+ while (namepath[0] == '^') {
+ len += acpigen_emit_byte('^');
+ namepath++;
+ }
+
+ ASSERT(namepath[0] != '\0');
+
+ i = 0;
+ while (namepath[i] != '\0') {
+ if (namepath[i] == '.') {
+ dotcount++;
+ dotpos = i;
+ }
+ i++;
+ }
+
+ if (dotcount == 0) {
+ len += acpigen_emit_simple_namestring(namepath);
+ } else if (dotcount == 1) {
+ len += acpigen_emit_double_namestring(namepath, dotpos);
+ } else {
+ len += acpigen_emit_multi_namestring(namepath);
+ }
+ return len;
+}
+
int acpigen_write_name(char *name)
{
- int len = strlen(name);
+ int len;
/* name op */
- acpigen_emit_byte(0x8);
- acpigen_emit_stream(name, len);
- return len + 1;
+ len = acpigen_emit_byte(0x8);
+ return len + acpigen_emit_namestring(name);
}
int acpigen_write_scope(char *name)
{
int len;
/* scope op */
- acpigen_emit_byte(0x10);
- len = acpigen_write_len_f();
- return len + acpigen_emit_stream(name, strlen(name)) + 1;
+ len = acpigen_emit_byte(0x10);
+ len += acpigen_write_len_f();
+ return len + acpigen_emit_namestring(name);
}
int acpigen_write_processor(u8 cpuindex, u32 pblock_addr, u8 pblock_len)
@@ -178,8 +267,8 @@
acpigen_emit_byte(0x83);
len = acpigen_write_len_f();
- sprintf(pscope, \\._PR_CPU%x, (unsigned int) cpuindex);
- len += acpigen_emit_stream(pscope, strlen(pscope));
+ sprintf(pscope, \\_PR.CPU%x, (unsigned int) cpuindex);
+ len += acpigen_emit_namestring(pscope);
acpigen_emit_byte(cpuindex);
acpigen_emit_byte(pblock_addr 0xff);
acpigen_emit_byte((pblock_addr 8) 0xff);
@@ -238,7 +327,7 @@
/* method
Re: [coreboot] locking...
On Sat, Jun 20, 2009 at 1:26 AM, Stefan Reinauerste...@coresystems.de wrote: #define printk_debug(foo...) do_printk(BIOS_DEBUG, foo) and replace them by #define printk(x...) do_printk(x) That is fine. That's a simple and straightforward change. How about we start with that. But let's not do THAT change until we fix ward's problem, and this has nothing to do with Ward's problem. thanks ron -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] locking...
It has become clear to me in this discussion that we are, each of us, talking about different things. Let's step back from the edge of the cliff and start over, please. I just got really, really confused. ron -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] locking...
On Sat, Jun 20, 2009 at 10:13:04AM -0700, ron minnich wrote: That is fine. That's a simple and straightforward change. How about we start with that. But let's not do THAT change until we fix ward's problem, and this has nothing to do with Ward's problem. Sorry for opening this can of worms ;) So, Stepan thinks that perhaps the stack is too small for the lzma decompression. I'm going to test next week with a 32KB stack (right now its at the default 8KB). This might solve booting, but I'll still have APs and BSP talking all at once, which I'm also seeing on K10. Thanks, Ward. -- Ward Vandewege w...@fsf.org Free Software Foundation - Senior Systems Administrator -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] useful hardware - dip8 to soic8 adapter
On Sat, Jun 20, 2009 at 5:53 AM, Peter Stugepe...@stuge.se wrote: Yep, that would work just fine. KISS rule wins again. :) wt -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] locking...
On Fri, Jun 19, 2009 at 9:02 AM, Carl-Daniel Hailfingerc-d.hailfinger.devel.2...@gmx.net wrote: However, this locking has to work when some CPUs are in CAR and others are in RAM. And that's the big problem. Let's go back to this original statement. I think it's not correct. We had decided, on opteron, that bsp does all memory setup -- i.e. sets up all memory controllers on all sockets. IIRC the opteron code starts APs up when all of memory is functional. I believe our Intel startup does this too: BSP sets up memory, and when APs start, memory is working and usable for stack etc. If what I am saying is true, that all APs run AFTER the BSP has set up memory, then there is no issue: all locking can be based in memory, since NO AP needs to run in CAR mode -- memory is working. IIRC this is how K8 actually works. So can we confirm my idea, that no AP need ever run in CAR? If they do need to run in CAR, why? thanks ron -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] ACPI support on M57SLI
Hello everyone, The last release works for me wonderfully almost out of the box. (still don't like HAVE_HIGH_TABLES :/) As a premium, the hvm virtualization works too. (kvm) Again, congratulation for all the work done by the coreboot team (and especialy Harald) for this board! I think we can now validate all of its features on the wiki.. Florentin Quoting Harald Gutmann harald.gutm...@gmx.net: On Thursday 18 June 2009 17:14:08 Myles Watson wrote: The dsdt.asl is now whitspace/indenting cleared. And got some further improvements to be able to install and boot windows 7 from coreboot with acpi support on m57sli. Great. I have already done a whitespace/indenting fix on Config.lb but attaching this to the acpi patch would just blow it up too much. Sure. I just meant the lines you were touching. Acked-by: Myles Watson myle...@gmail.com On Thursday 18 June 2009 22:20:24 Peter Stuge wrote: Harald Gutmann wrote: His explanation was quite easy: You'll need the _CRS symbols in your dsdt.asl. I had a look at his dsdt.asl from asus/m2v-mx_se, and saw that there are not much _CRS symbols in it. Keyboard, Mouse, Floppy, and the PCI root device has _CRS Symbols. And we already have the info for these, right, it would be awesome to generate that part of the DSDT automatically, as Rudolf has mentioned before. That was all, which has lead to success with coreboot and windows. :) Great! Has the patch been committed? If not, please do it. :) Acked-by: Peter Stuge pe...@stuge.se Thanks, r4364. Kind regards, Harald -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] locking...
On 20.06.2009 10:31, Stefan Reinauer wrote: On 20.06.2009 2:57 Uhr, Carl-Daniel Hailfinger wrote: True, but our console requirements for both versions are pretty minimal and I think we showed in v3 that a one-size-fits-all printk can work fine. It didn't, that's the point.. No locking, True. I worked a lot on printk and the biggest reasons I didn't add locking were: 1. I have no SMP hardware (and I don't know if we support SMP Qemu) 2. I simply didn't think of it and I can't remember anyone demanded locking for printk. and it destroyed output of i.e. a GDB interface by appending (CB) to each line. Plus, the ifdef mess is really not (much?) nicer to look at than the linker sets. Fortunately, (CB) is default off. Back then, I argued against this particular feature, but it was desired by some v3 developers (don't exactly remember who). If there is no such demand anymore, we can drop this piece of code. Regards, Carl-Daniel -- http://www.hailfinger.org/ -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] locking...
On 20.06.2009 19:14, ron minnich wrote: It has become clear to me in this discussion that we are, each of us, talking about different things. Yes, it seems so. Let's step back from the edge of the cliff and start over, please. I just got really, really confused. Agreed. I'll try to write down precisely what I propose to fix Ward's problem. Regards, Carl-Daniel -- http://www.hailfinger.org/ -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] locking...
On 20.06.2009 20:08, Ward Vandewege wrote: On Sat, Jun 20, 2009 at 10:13:04AM -0700, ron minnich wrote: That is fine. That's a simple and straightforward change. How about we start with that. But let's not do THAT change until we fix ward's problem, and this has nothing to do with Ward's problem. Sorry for opening this can of worms ;) So, Stepan thinks that perhaps the stack is too small for the lzma decompression. I'm going to test next week with a 32KB stack (right now its at the default 8KB). Wait a second. We have two different possible problems to consider. 1. Every core which uses LZMA decompression needs at least 24k stack. 2. AP stacks are a lot smaller than the BSP stack by design, so even if you have a 24k stack for the BSP, it is unlikely you have sufficient stack size for the APs. Can you test with 32k BSP stack size, but uncompressed AP code and default AP stack size? Unless CBFS code has some internal design/code limitations (and I didn't see any regarding the stack), the lzma stack requirements should not show up on APs for uncompressed AP code. This might solve booting, but I'll still have APs and BSP talking all at once, which I'm also seeing on K10. That's the locking problem which we can fix separately. Regards, Carl-Daniel -- http://www.hailfinger.org/ -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] ACPI support on M57SLI
On Saturday 20 June 2009 22:17:51 Florentin Demetrescu wrote: Hello everyone, The last release works for me wonderfully almost out of the box. (still don't like HAVE_HIGH_TABLES :/) Use a recent SeaBios version and get happy with HIGH_TABLES. ;) As a premium, the hvm virtualization works too. (kvm) Does that mean you have tested Hardware Visualization? If yes, please be so kindly and mark it in the wiki entry for m57sli as OK (if you have an account) otherwise please give some details on that, so I can add this as tested. Again, congratulation for all the work done by the coreboot team (and especialy Harald) for this board! I think we can now validate all of its features on the wiki.. The wiki should be up to date for this board, I changed all of the entries which I was able to test. Hopefully we can find/fix/verify the last outstanding problems on v1 with that board, so that it can be stated as fully supported. (And maybe, when I've too much time I'll have a look at the S3 ACPI mode, but this could get quite hard, as the MCP55 documentation is under NDA by nvidia.) If you have a floppy device and the possibility to test it, please do so and report if it works. (Otherwise I'll test that in a few weeks, as i don't have a floppy device here.) Great that this patches make you happy, and hopefully everything works like expected. If you run into problems please report it. Florentin Kind regards, Harald Quoting Harald Gutmann harald.gutm...@gmx.net: On Thursday 18 June 2009 17:14:08 Myles Watson wrote: The dsdt.asl is now whitspace/indenting cleared. And got some further improvements to be able to install and boot windows 7 from coreboot with acpi support on m57sli. Great. I have already done a whitespace/indenting fix on Config.lb but attaching this to the acpi patch would just blow it up too much. Sure. I just meant the lines you were touching. Acked-by: Myles Watson myle...@gmail.com On Thursday 18 June 2009 22:20:24 Peter Stuge wrote: Harald Gutmann wrote: His explanation was quite easy: You'll need the _CRS symbols in your dsdt.asl. I had a look at his dsdt.asl from asus/m2v-mx_se, and saw that there are not much _CRS symbols in it. Keyboard, Mouse, Floppy, and the PCI root device has _CRS Symbols. And we already have the info for these, right, it would be awesome to generate that part of the DSDT automatically, as Rudolf has mentioned before. That was all, which has lead to success with coreboot and windows. :) Great! Has the patch been committed? If not, please do it. :) Acked-by: Peter Stuge pe...@stuge.se Thanks, r4364. Kind regards, Harald signature.asc Description: This is a digitally signed message part. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] locking...
On 20.06.2009 21:38, ron minnich wrote: On Fri, Jun 19, 2009 at 9:02 AM, Carl-Daniel Hailfinger c-d.hailfinger.devel.2...@gmx.net wrote: However, this locking has to work when some CPUs are in CAR and others are in RAM. And that's the big problem. Let's go back to this original statement. I think it's not correct. We had decided, on opteron, that bsp does all memory setup -- i.e. sets up all memory controllers on all sockets. IIRC the opteron code starts APs up when all of memory is functional. I believe our Intel startup does this too: BSP sets up memory, and when APs start, memory is working and usable for stack etc. Unless I'm misreading the K8/Fam10 CAR code in v2, they are a bit peculiar. Please correct me if I'm wrong. 1. K8 code does not care at all if it runs on BSP or AP. Each core which enters v2/src/cpu/amd/car/cache_as_ram.inc locks the cache, clobbers the same area (all of CAR), then proceeds to call cache_as_ram_main() on each core which entered. This means if any AP ever enters v2/src/cpu/amd/car/cache_as_ram.inc, we either have each of them overwriting the stack of all other APs if they can access RAM, or they are indeed in CAR mode when the BSP is already in RAM mode (bad). 2. Fam10 code cares if it runs on BSP or AP. It takes care to give every core its own stack area (different locations), does not clobber the CAR area at all, then proceeds to call cache_as_ram_main() on each core which entered. So if there is some code which makes sure no AP ever enters v2/src/cpu/amd/car/cache_as_ram.inc, we can kill off all AP handling code in there. However, if APs can enter v2/src/cpu/amd/car/cache_as_ram.inc, we either have some real corruption race conditions on K8 or your statement above (regarding usable memory) contradicts the code. If what I am saying is true, that all APs run AFTER the BSP has set up memory, then there is no issue: all locking can be based in memory, since NO AP needs to run in CAR mode -- memory is working. IIRC this is how K8 actually works. Then the only issue for locking is to find out if we are in CAR (ignore locking) or in RAM (use locking). So can we confirm my idea, that no AP need ever run in CAR? If they do need to run in CAR, why? Please see above. I'm now thoroughly confused, but if the situation is better than I hoped, I'm the first to celebrate. It is really great that we talk about this, now I'm starting to understand multicore startup. Thanks! Regards, Carl-Daniel -- http://www.hailfinger.org/ -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] locking...
On 20.06.2009 20:08, Ward Vandewege wrote: [...] but I'll still have APs and BSP talking all at once, which I'm also seeing on K10. So mangled printk problem is visible on K8 and Fam10? I just read through the M57SLI early code path again and it seems we really have a race condition which causes stack corruption on SMP, possibly only visible if there is more than one AP. Or caches of each core are independent during early startup and the every AP can use RAM line of thought needs to be revised. v3 is not a that different in this regard, but I see an easier way out there. Anyway, I'll wait for someone else to show where I'm wrong before I proceed. Each of the situations above wants entirely different fixes for printk locking (or even booting). Regards, Carl-Daniel -- http://www.hailfinger.org/ -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] locking...
On Sun, Jun 21, 2009 at 02:39:31AM +0200, Carl-Daniel Hailfinger wrote: On 20.06.2009 20:08, Ward Vandewege wrote: [...] but I'll still have APs and BSP talking all at once, which I'm also seeing on K10. So mangled printk problem is visible on K8 and Fam10? Yes. Here's a K8 boot that works reliably on h8dme (r4314) but has some garbled output. Check right after it says Clearing initial memory region: Done. http://ward.vandewege.net/coreboot/h8dme/minicom-20090618q.cap And here's a K10 boot that does not boot because there's something going on with the latest microcode for this cpu (but that's another issue I think). It has the garbled output right after Start node 01 done. and eventually soft resets: http://ward.vandewege.net/coreboot/h8dmr/fam10/h8dmr-am.cap I just read through the M57SLI early code path again and it seems we really have a race condition which causes stack corruption on SMP, possibly only visible if there is more than one AP. Or caches of each core are independent during early startup and the every AP can use RAM line of thought needs to be revised. Interesting. The K8 machine above is a supermicro h8dme with 2x dual core, and the K10 machine is a supermicro h8dmr with 2x quad core. The m57sli only has one cpu socket of course but I use it regularly with dual core cpus, and I have never noticed garbled output. I could be overlooking it of course, it's relatively subtle in the K8 example. Thanks, Ward. -- Ward Vandewege w...@fsf.org Free Software Foundation - Senior Systems Administrator -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] locking...
On Sat, Jun 20, 2009 at 4:49 PM, Carl-Daniel Hailfingerc-d.hailfinger.devel.2...@gmx.net wrote: Unless I'm misreading the K8/Fam10 CAR code in v2, they are a bit peculiar. Please correct me if I'm wrong. 1. K8 code does not care at all if it runs on BSP or AP. Each core which enters v2/src/cpu/amd/car/cache_as_ram.inc locks the cache, clobbers the is your assumption that they all enter that code valid? You need to see what address the startup IPI from BSP to AP contains. IIRC it contains an address in DRAM. I did study that code but it was a few months ago. Take a look at how the BSP wakes up the AP and where the startup IPI address is. In fact each AP gets its own stack. in the code I wrote for v3, potentially, each AP could get its own code block for startup. Anyway you can double check me. I think you guys are on to something,but we need to study this code a bit more. thanks ron -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
