Re: [coreboot] "How come it's so slow?"

[ron minnich]

OK, we found a keyboard that works. The BIOS is convinced there are
two keyboards and two mice attached. There is one keyboard and no mice
Just great.

ron

-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

[coreboot] coreboot on "acer aspire 1520"

[Paweł Stawicki]

Hi,
I want to try run coreboot on my "acer aspire 1520" laptop.
It has:
Northbridge: via k8n800
southbrige: vt8235
super i/o:   pc87392

Can I get some advise, where to start ?
which northbridge and super i/o are the nearest ?


Best Regards,
Paweł Stawicki
-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Hi...all

[Carl-Daniel Hailfinger]

On 05.03.2010 19:26, ron minnich wrote:
> What would coreboot need to do to "support" IPMI BMC?
>   

Depends on the IPMI BMC. If you're lucky, it works out of the box, and
if you're unlucky, you have to implement undocumented BIOS interfaces.
The easiest solution is to buy a card and try it, and if it doesn't
work, reverse engineer it or try another card.

Besides that, IPMI is a security nightmare (see the discussions on the
linux-kernel mailing list about IPMI bypassing host network security).

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]: Disable ExtINT in ioapic.c

[Marc Jones]

On Tue, Feb 2, 2010 at 6:40 PM, Stefan Reinauer  wrote:
> On 2/2/10 4:25 AM, Bao, Zheng wrote:
>> Index: src/arch/i386/smp/ioapic.c
>> ===
>> --- src/arch/i386/smp/ioapic.c        (revision 5073)
>> +++ src/arch/i386/smp/ioapic.c        (working copy)
>> @@ -110,7 +110,7 @@
>>  #endif
>>
>>       /* Enable Virtual Wire Mode */
>> -     low = ENABLED | TRIGGER_EDGE | POLARITY_HIGH | PHYSICAL_DEST |
>> ExtINT;
>> +     low = DISABLED;
>>       high = bsp_lapicid << (56 - 32);
>>
>>       io_apic_write(ioapic_base, 0x10, low);
>>
>
> Hm.. This will break quite some other boards...
>
> Is there any particular reason why the dbm690t will not work in virtual
> wire mode?
>
> I think either the sb600 code should call clear_ioapic() instead of
> setup_ioapic() or (maybe better) the setup_ioapic() function should get
> an additional parameter virtual_wire
>
> Anyways, maybe we should try to unify clear_ioapic and setup_ioapic
>
> (also, the function should create a device node and append it to the
> bridge it is called from)

Sefan,

You are right. The sb600 was really doing a clear_ioapic() previously.
I don't yet understand why the virtual wire mode causes problems. It
is either an additional sb600 setup issue or a mainboard problem with
how EXTINT is connected. The setup_ioapic() should probably have more
options as EXTINT doesn't have to be connected to the APIC.

Signed-off-by: Marc Jones 

Marc


-- 
http://se-eng.com


sb600_apic.patch
Description: Binary data
-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

[coreboot] build service results for r5192

[coreboot information]

Dear coreboot readers!

This is the automatic build system of coreboot.

The developer "myles" checked in revision 5192 to
the coreboot repository. This caused the following 
changes:

Change Log:
Remove redundant run_bios prototype.  Trivial.

Signed-off-by: Myles Watson 
Acked-by: Myles Watson 


Build Log:
Compilation of emulation:qemu-x86 has been fixed


If something broke during this checkin please be a pain 
in myles's neck until the issue is fixed.

If this issue is not fixed within 24h the revision should 
be backed out.

   Best regards,
 coreboot automatic build system



-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] [commit] r5185 - in trunk: src src/console src/cpu/x86/smm src/devices src/mainboard/amd/dbm690t src/mainboard/amd/pistachio src/mainboard/amd/serengeti_cheetah_fam10 src/mainboard/asus

[Stefan Reinauer]

On 3/5/10 8:16 PM, Peter Stuge wrote:
> repository service wrote:
>   
>> +config X86EMU_DEBUG
>> +bool "Output verbose x86emu debug messages"
>> +default n
>> +depends on PCI_OPTION_ROM_RUN_YABEL
>> +help
>> +  This option enables additional x86emu related debug messages.
>> 
> So is it x86emu or YABEL? It would be great to have just one name.
>   
It's both. YABEL is the BIOS emulation, x86emu is the CPU emulation.

Stefan


-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] [commit] r5185 - in trunk: src src/console src/cpu/x86/smm src/devices src/mainboard/amd/dbm690t src/mainboard/amd/pistachio src/mainboard/amd/serengeti_cheetah_fam10 src/mainboard/asus

[Peter Stuge]

repository service wrote:
> +config X86EMU_DEBUG
> + bool "Output verbose x86emu debug messages"
> + default n
> + depends on PCI_OPTION_ROM_RUN_YABEL
> + help
> +   This option enables additional x86emu related debug messages.

So is it x86emu or YABEL? It would be great to have just one name.


//Peter

-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

[coreboot] [commit] r5192 - trunk/util/x86emu

[repository service]

Author: myles
Date: Fri Mar  5 20:12:34 2010
New Revision: 5192
URL: http://tracker.coreboot.org/trac/coreboot/changeset/5192

Log:
Remove redundant run_bios prototype.  Trivial.

Signed-off-by: Myles Watson 
Acked-by: Myles Watson 

Modified:
   trunk/util/x86emu/x86.c

Modified: trunk/util/x86emu/x86.c
==
--- trunk/util/x86emu/x86.c Fri Mar  5 19:27:19 2010(r5191)
+++ trunk/util/x86emu/x86.c Fri Mar  5 20:12:34 2010(r5192)
@@ -32,7 +32,6 @@
 };
 
 void x86_exception(struct eregs *info);
-void run_bios(struct device *dev, unsigned long addr);
 
 extern unsigned char __idt_handler, __idt_handler_size;
 extern unsigned char __realmode_code, __realmode_code_size;

-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] [PATCH] ASUS P2B-LS support, RAM detection for 440BX, add Slot 1 CPU, Microcode for Intel Tualatin CPUs

[Andrew Goodbody]

Joseph Smith wrote:

Also, one could always use serialice on a 4 slot system with factory bios
to see how they deterime it


The factory BIOS does not have to determine it. It knows the 
configuration of the board it is running on. It can use a build time 
setting.


Andrew

--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

[coreboot] build service results for r5191

[coreboot information]

Dear coreboot readers!

This is the automatic build system of coreboot.

The developer "myles" checked in revision 5191 to
the coreboot repository. This caused the following 
changes:

Change Log:
1. Move run_bios prototype to device.h
2. Use time.h for get_time() and move tb_freq into functions.c
3. Move read_io and write_io to io.c and make them static
4. Make a couple of functions static in interrupt.c
5. Refactor a cast from char[] to u64 to get rid of potential alignment 
problems and a warning

Signed-off-by: Myles Watson 
Acked-by: Stefan Reinauer 


Build Log:
Compilation of emulation:qemu-x86 has been broken
See the error log at 
http://qa.coreboot.org/log_buildbrd.php?revision=5191&device=qemu-x86&vendor=emulation&num=2


If something broke during this checkin please be a pain 
in myles's neck until the issue is fixed.

If this issue is not fixed within 24h the revision should 
be backed out.

   Best regards,
 coreboot automatic build system



-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] [PATCH] YABEL compilation warnings

[Myles Watson]

On Fri, Mar 5, 2010 at 10:28 AM, Stefan Reinauer wrote:

>  On 3/5/10 4:13 PM, Myles Watson wrote:
>
>  I think we should get rid of that warning, since we conditionally call
>> functions based on debugging and various config variables.
>
>  I think we should instead just drop CONFIG_WARNINGS_ARE_ERRORS for Qemu
> rather than dropping warnings.
>
I think that setting for Qemu has reduced the number of warnings in our code
by a lot.  It's easier for the original developer to deal with warnings when
the code is written.


> Or maybe only add -Wno-unused-function if
>
CONFIG_WARNINGS_ARE_ERRORS is active, at least.  Or maybe add an Option
> "Warnings good for Developers"?
>
I can see your point.  I'd rather not have to special case warnings either.
What would you suggest for the two emulator functions in yabel that are
unused right now?  Should we comment them out until they are used?


>  Is there a case where it helps enough to justify all the warnings?
>>
>   Yes, they indicate that there is dead code. This is, not only but
> especially useful to recognize if / how code should / could be restructured.
>
>
I worry that having too many warnings makes it so that "important" ones
(ones that cause bugs) get missed.

>   Signed-off-by: Myles Watson 
>
> With the -Wno-unused-functions taken care of:
>

I wasn't sure how you wanted it taken care of.  I left it for another patch.


> Acked-by: Stefan Reinauer  
>

Rev 5191.

Thanks,
Myles
-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

[coreboot] [commit] r5191 - in trunk: src/devices src/include/device util/x86emu/yabel util/x86emu/yabel/compat

[repository service]

Author: myles
Date: Fri Mar  5 19:27:19 2010
New Revision: 5191
URL: http://tracker.coreboot.org/trac/coreboot/changeset/5191

Log:
1. Move run_bios prototype to device.h
2. Use time.h for get_time() and move tb_freq into functions.c
3. Move read_io and write_io to io.c and make them static
4. Make a couple of functions static in interrupt.c
5. Refactor a cast from char[] to u64 to get rid of potential alignment 
problems and a warning

Signed-off-by: Myles Watson 
Acked-by: Stefan Reinauer 

Modified:
   trunk/src/devices/pci_device.c
   trunk/src/include/device/device.h
   trunk/util/x86emu/yabel/compat/functions.c
   trunk/util/x86emu/yabel/compat/time.h
   trunk/util/x86emu/yabel/interrupt.c
   trunk/util/x86emu/yabel/io.c
   trunk/util/x86emu/yabel/mem.c
   trunk/util/x86emu/yabel/vbe.c

Modified: trunk/src/devices/pci_device.c
==
--- trunk/src/devices/pci_device.c  Fri Mar  5 19:25:19 2010(r5190)
+++ trunk/src/devices/pci_device.c  Fri Mar  5 19:27:19 2010(r5191)
@@ -652,7 +652,6 @@
 void pci_dev_init(struct device *dev)
 {
 #if CONFIG_PCI_ROM_RUN == 1 || CONFIG_VGA_ROM_RUN == 1
-   void run_bios(struct device *dev, unsigned long addr);
struct rom_header *rom, *ram;
 
if (CONFIG_PCI_ROM_RUN != 1 && /* Only execute VGA ROMs. */

Modified: trunk/src/include/device/device.h
==
--- trunk/src/include/device/device.h   Fri Mar  5 19:25:19 2010(r5190)
+++ trunk/src/include/device/device.h   Fri Mar  5 19:27:19 2010(r5191)
@@ -117,6 +117,9 @@
 void dev_set_enabled(device_t dev, int enable);
 void disable_children(struct bus *bus);
 
+/* Option ROM helper functions */
+void run_bios(struct device *dev, unsigned long addr);
+
 /* Helper functions */
 device_t find_dev_path(struct bus *parent, struct device_path *path);
 device_t alloc_find_dev(struct bus *parent, struct device_path *path);

Modified: trunk/util/x86emu/yabel/compat/functions.c
==
--- trunk/util/x86emu/yabel/compat/functions.c  Fri Mar  5 19:25:19 2010
(r5190)
+++ trunk/util/x86emu/yabel/compat/functions.c  Fri Mar  5 19:27:19 2010
(r5191)
@@ -18,6 +18,7 @@
 #include 
 #include "../debug.h"
 #include "../biosemu.h"
+#include "../compat/time.h"
 
 #define VMEM_SIZE (1024 * 1024) /* 1 MB */
 
@@ -52,6 +53,8 @@
}
 }
 
+unsigned long tb_freq = 0;
+
 u64 get_time(void)
 {
 u64 act;
@@ -64,50 +67,3 @@
 act = ((u64) edx << 32) | eax; 
 return act;
 }
-
-unsigned int
-read_io(void *addr, size_t sz)
-{
-unsigned int ret;
-   /* since we are using inb instructions, we need the port number as 
16bit value */
-   u16 port = (u16)(u32) addr;
-
-switch (sz) {
-case 1:
-   asm volatile ("inb %1, %b0" : "=a"(ret) : "d" (port));
-break;
-case 2:
-   asm volatile ("inw %1, %w0" : "=a"(ret) : "d" (port));
-break;
-case 4:
-   asm volatile ("inl %1, %0" : "=a"(ret) : "d" (port));
-break;
-default:
-ret = 0;
-}
-
-return ret;
-}
-
-int
-write_io(void *addr, unsigned int value, size_t sz)
-{
-   u16 port = (u16)(u32) addr;
-switch (sz) {
-   /* since we are using inb instructions, we need the port number as 
16bit value */
-case 1:
-   asm volatile ("outb %b0, %1" : : "a"(value), "d" (port));
-break;
-case 2:
-   asm volatile ("outw %w0, %1" : : "a"(value), "d" (port));
-break;
-case 4:
-   asm volatile ("outl %0, %1" : : "a"(value), "d" (port));
-break;
-default:
-return -1;
-}
-
-return 0;
-}
-

Modified: trunk/util/x86emu/yabel/compat/time.h
==
--- trunk/util/x86emu/yabel/compat/time.h   Fri Mar  5 19:25:19 2010
(r5190)
+++ trunk/util/x86emu/yabel/compat/time.h   Fri Mar  5 19:27:19 2010
(r5191)
@@ -13,5 +13,6 @@
 #define _BIOSEMU_COMPAT_TIME_H
 
 /* TODO: check how this works in x86 */
-static unsigned long tb_freq = 0;
+extern unsigned long tb_freq;
+u64 get_time(void);
 #endif 

Modified: trunk/util/x86emu/yabel/interrupt.c
==
--- trunk/util/x86emu/yabel/interrupt.c Fri Mar  5 19:25:19 2010(r5190)
+++ trunk/util/x86emu/yabel/interrupt.c Fri Mar  5 19:27:19 2010(r5191)
@@ -31,7 +31,7 @@
 
 
 //setup to run the code at the address, that the Interrupt Vector points to...
-void
+static void
 setupInt(int intNum)
 {
DEBUG_PRINTF_INTR("%s(%x): executing interrupt handler @%08x\n",
@@ -50,7 +50,7 @@
 }
 
 // handle int10 (VG

Re: [coreboot] Hi...all

[ron minnich]

What would coreboot need to do to "support" IPMI BMC?

ron

-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

[coreboot] [commit] r5190 - trunk/src/northbridge/intel/i945

[repository service]

Author: stepan
Date: Fri Mar  5 19:25:19 2010
New Revision: 5190
URL: http://tracker.coreboot.org/trac/coreboot/changeset/5190

Log:
i945 mini patch:
- don't skip the reset on S4 violations. Specs ask us to do this so we do it
- hlt on waiting for reset instead of hot looping.

Signed-off-by: Stefan Reinauer 
Acked-by: Stefan Reinauer 

Modified:
   trunk/src/northbridge/intel/i945/raminit.c

Modified: trunk/src/northbridge/intel/i945/raminit.c
==
--- trunk/src/northbridge/intel/i945/raminit.c  Fri Mar  5 19:03:49 2010
(r5189)
+++ trunk/src/northbridge/intel/i945/raminit.c  Fri Mar  5 19:25:19 2010
(r5190)
@@ -236,8 +236,9 @@
if (reg8 & ((1<<7)|(1<<2))) {
if (reg8 & (1<<2)) {
printk_debug("SLP S4# Assertion Width Violation.\n");
-
+   /* Write back clears bit 2 */
pci_write_config8(PCI_DEV(0, 0x1f, 0), 0xa2, reg8);
+   do_reset = 1;
 
}
 
@@ -257,7 +258,7 @@
printk_debug("Reset required.\n");
outb(0x00, 0xcf9);
outb(0x0e, 0xcf9);
-   for (;;) ; /* Wait for reset! */
+   for (;;) asm("hlt"); /* Wait for reset! */
}
}
 

-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] "How come it's so slow?"

[Thomas Gstädtner]

Imho it's just a sad sign for our industry.
There is a great, fast, cheap and very easy to implement solution for
x86 bootfirmwares. coreboot, but somehow the industry doesn't seem
interested.
Instead every company invents the wheel over and over again and they
never do it good or even right.
One would think that coreboot could give a company a real advantage in
the market, but still - nobody even tries (some exceptions in special
market segments excluded).

I hope that changes soon, not only "this decade", and I hope that AMD
stays on course and tries harder.

Anyway, you're doing a great job, keep up the good work!

On 2010-03-05, ron minnich  wrote:
> Just got a new nehalem box in for test yesterday. Experiences so far:
>
> 1. POST from power-on takes 45 seconds. *45 SECONDS*. Now, I had it
> said to me at SCALE7x last year from someone from Intel that all new
> BIOSes on Intel chips are really EFI underneath -- is this indicative
> of what we are to expect? If so, it's awful. It's 15 times slower than
> what we had ten years ago, and 50 times slower than what we can do
> today on coreboot.
> 2. POST from reset took infinity, sometimes, and 60 seconds others.
> 3. With no keyboard attached, we got the 'Hit any key to continue'
> message. I can't this problem still occurs.
> 4. No PS/2 connectors, which might be ok, except:
> 5. USB keyboard doesn't work well enough to get to the config screen.
> Oh, it works, just not right away. We can't get to the BIOS setup.
> 6. It's too dumb to realize that if there really are no storage
> devices attached, it really ought to try the network. And we can't
> force the 'boot from net' setting yet. See (5).
>
> Experiences on a MAC with EFI
> 1. "How come it's so long to be responsive?"
> 2. The only way to make it bearable is to load REFIt.
> 3. there's a file on the "EFI FLASH partition". It defines the
> partition tables. Yep, you might think that it could just read the
> drive, and no, that's not good enough: it can't boot an installed
> linux unless you rebuild this file too.
>
> So, the score so far: we've had a superior open source solution for 10
> years, and there are lots of sectors starting to listen (I hear from
> more each week), but we're still stuck with Old Fashioned BIOS on our
> desktops and servers. :-)
>
> I expect this problem to change this decade, just not sure when :-)
>
> ron
>
> --
> coreboot mailing list: coreboot@coreboot.org
> http://www.coreboot.org/mailman/listinfo/coreboot
>

-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Supermicro H8QME-2+ mct_d fatal exit.

[ron minnich]

Just FYI:

on our first system with Arima boards in 2002, everything worked well
until we started booting 64-bit kernels. I'm not kidding. We did not
find the SMBUS MUX on the boards until we had unreliable coreboot
boots of 64-bit kernels. For quite some time the boards worked fine.
Ollie found the SMBUS MUX by examining schematics.

So the SMBUS mux can appear in strange ways, at strange times. This
sounds like one of those times. SMBUS muxes are more common than you
might think and the default power-on state is not always very well
determined.

ron

-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

[coreboot] [commit] r5189 - trunk/src/arch/i386/init

[repository service]

Author: stepan
Date: Fri Mar  5 19:03:49 2010
New Revision: 5189
URL: http://tracker.coreboot.org/trac/coreboot/changeset/5189

Log:
Fix creation of coreboot.bootblock when -O2 is specified instead of -Os (4GB 
image issue).

According to some GCC folks -Os should be considered a buggy and unreliable
code path, so at least keep -O2 working. coreboot_ram is only 4KB bigger.

Signed-off-by: Stefan Reinauer 
Acked-by: Stefan Reinauer 

Modified:
   trunk/src/arch/i386/init/ldscript_fallback_cbfs.lb

Modified: trunk/src/arch/i386/init/ldscript_fallback_cbfs.lb
==
--- trunk/src/arch/i386/init/ldscript_fallback_cbfs.lb  Fri Mar  5 17:31:41 
2010(r5188)
+++ trunk/src/arch/i386/init/ldscript_fallback_cbfs.lb  Fri Mar  5 19:03:49 
2010(r5189)
@@ -47,6 +47,7 @@
*(.rom.data);
*(.init.rodata.*);
*(.init.text);
+   *(.rodata);
*(.rodata.*);
*(.rom.data.*);
. = ALIGN(16);

-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] [PATCH] ASUS P2B-LS support, RAM detection for 440BX, add Slot 1 CPU, Microcode for Intel Tualatin CPUs

[Joseph Smith]

On Fri, 05 Mar 2010 15:24:25 +0100, Stefan Reinauer 
wrote:
> On 3/5/10 3:15 PM, Joseph Smith wrote:
>>
>>
>> On Fri, 05 Mar 2010 13:04:27 +, Mark Marshall

>> wrote:
>>
>>> Joseph Smith wrote:
>>>
 On 03/05/2010 03:03 AM, Mark Marshall wrote:

> On 04/03/10 13:10, Joseph Smith wrote:
>
>> On 03/04/2010 07:38 AM, Joseph Smith wrote:
>>
>>> On 03/04/2010 07:30 AM, Uwe Hermann wrote:
>>>
 On Thu, Mar 04, 2010 at 10:05:57AM +, Mark Marshall wrote:

> On 03/03/10 04:19, Keith Hui wrote:
> The first problem is that this motherboard only has three DIMM
> slots. This means you have to set SDRAMC to something different;
> 0x0103 works for me.
>
>
 Hm, seems to be determined by SDRAMPWR + MMCONFIG, and MMCONFIG
 seems to
 be a hardware-strap (so we can check it), but not sure about

>>> SDRAMPWR.
>>>

>
>> I think a simple SPD probe would work, if the correct value is
>>
>> returned
>>
>> you know you have memory in that slot, otherwise if 0xff is returned
>> then no memory is present. Do this probe for as many slots as the
440
>> supports. Then set your registers based on that.
>>
> The issue here is the number of DIMM slots on the motherboard, not
the
> number of sticks in the slots. Some 440BX boards have four slots,
> while
> others only have three.
>
> MM
>
>
 That is fine. Then if 440bx datasheet says it supports 4 slots, then
 that should be the standard.


>>> Please check this section of the 440BX data sheet.
>>>
>>>3.3.24 SDRAMC—SDRAM Control Register (Device 0)
>>>
>>> We are interested in bit 4.
>>>
>>>   SDRAMPWR. The SDRAMPWR bit controls how the CKE signals are driven
>>>   for different DRAM configurations. For a 3 DIMM configuration,
>>>   SDRAMPWR should be set to ‘0’. For a 4 DIMM configuration,
>>>   SDRAMPWR should be set to ‘1’. In this case the 82443BX drives a
>>>   single CKE signal (GCKE). The combination of SDRAMPWR and MMCONFIG
>>>   (DRAMC register) determine the functioning of the CKE signals.
>>>   Refer to the DRAMC register (Section 3.3.15, “DRAMC—DRAM
>>>   Control Register (Device 0)” on page 3-19) for more details.
>>>
>>>   Note: When PCIRST# assertion occurs during POS/STR, these bits
>>>   are not reset to 0.
>>>
>>> As far as I can tell we cannot auto-detect this.  Some (many)
>>> 440BX boards only have three DIMM slots, and in these cases the
>>> clocks are routed differently to the boards with four DIMM slots.
>>>
>>>
>> That's easy... so you do something like this:
>>
>> slot4_detect = (spd_read_byte((DIMM_SPD_BASE + 3), SPD_MEMORY_TYPE);
>>
>> if (slot4_detect != 0xff) {
>>
>>  /* We have 4 slots */
>>  Set bit 4 in SDRAMPWR
>>  #define DIMM_SOCKETS 4
>> } else {
>>
>>  /* We have 3 slots */
>>  Set bit 4 in SDRAMPWR
>>  #define DIMM_SOCKETS 3
>> }
>>
>> Hope that helps.
>>
> 
> Will a mainboard with three modules but 4 slots work like this? Can
> someone try? If we can autodetect it, we should. If we can't I think
> encoding the number of slots in Kconfig is fine.
> 
I think so, from what I understand the clocks are routed in a daisy chain
so to speak. So if there is 4 physical slots and the system is only
configured for three it should work ok. Also this routine will be
determined at every start up so if you put a sdram module in the fourth
slot it will be re-configured for 4 slots.

Anyways the only way to know if this will work is to test it so can someone
please test?

Also, one could always use serialice on a 4 slot system with factory bios
to see how they deterime it

One could try a dump with three DIMMS and then a dump with four DIMMS and
compare the results.


-- 
Thanks,
Joseph Smith
Set-Top-Linux
www.settoplinux.org


-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] [PATCH] YABEL compilation warnings

[Stefan Reinauer]

On 3/5/10 4:13 PM, Myles Watson wrote:
>
> I think we should get rid of that warning, since we conditionally
> call functions based on debugging and various config variables.  
>
I think we should instead just drop CONFIG_WARNINGS_ARE_ERRORS for Qemu
rather than dropping warnings. Or maybe only add -Wno-unused-function if
CONFIG_WARNINGS_ARE_ERRORS is active, at least.  Or maybe add an Option
"Warnings good for Developers"?

> Is there a case where it helps enough to justify all the warnings?
>

Yes, they indicate that there is dead code. This is, not only but
especially useful to recognize if / how code should / could be restructured.

>  Signed-off-by: Myles Watson  >
With the -Wno-unused-functions taken care of:

Acked-by: Stefan Reinauer 
-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

[coreboot] "How come it's so slow?"

[ron minnich]

Just got a new nehalem box in for test yesterday. Experiences so far:

1. POST from power-on takes 45 seconds. *45 SECONDS*. Now, I had it
said to me at SCALE7x last year from someone from Intel that all new
BIOSes on Intel chips are really EFI underneath -- is this indicative
of what we are to expect? If so, it's awful. It's 15 times slower than
what we had ten years ago, and 50 times slower than what we can do
today on coreboot.
2. POST from reset took infinity, sometimes, and 60 seconds others.
3. With no keyboard attached, we got the 'Hit any key to continue'
message. I can't this problem still occurs.
4. No PS/2 connectors, which might be ok, except:
5. USB keyboard doesn't work well enough to get to the config screen.
Oh, it works, just not right away. We can't get to the BIOS setup.
6. It's too dumb to realize that if there really are no storage
devices attached, it really ought to try the network. And we can't
force the 'boot from net' setting yet. See (5).

Experiences on a MAC with EFI
1. "How come it's so long to be responsive?"
2. The only way to make it bearable is to load REFIt.
3. there's a file on the "EFI FLASH partition". It defines the
partition tables. Yep, you might think that it could just read the
drive, and no, that's not good enough: it can't boot an installed
linux unless you rebuild this file too.

So, the score so far: we've had a superior open source solution for 10
years, and there are lots of sectors starting to listen (I hear from
more each week), but we're still stuck with Old Fashioned BIOS on our
desktops and servers. :-)

I expect this problem to change this decade, just not sure when :-)

ron

-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Supermicro H8QME-2+ mct_d fatal exit.

[Rudolf Marek]

Two more suggestions:
- compare coreboot and vendor bios with SerialICE
- try disabling all cores / cpus except the BSP to make sure the problem
is not caused by the PCI access race conditions in the Fam8 and K10 ports...


Yes good one also.

Rudolf



Stefan



--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Supermicro H8QME-2+ mct_d fatal exit.

[Rudolf Marek]

Hi,

I did a output on status form status = mctRead_SPD(smbaddr, Index); in
mct_d.c and it only spits -1 out while on the working coreboot machine
it gives me several numbers until index = 64 on those dimms where ram is
installed. Is this a possible SPD EPROMS missing error you pointed out?



Yes this points to some I2C multiplexer device. You need to find out how to 
control the multiplexer. It might be some GPIO setup or even some i2c device. 
Try to superiotool in verbose mode to see how the GPIO is setup. You will need 
either to load the GPIO settings (of superio tool) in coreboot before ram init 
or just dump it and check for the differences in first place.


in linux, i2cdetect 0
output would also help maybe...

try running sensors-detect it might detect the bus multiplexers.

Rudolf



What would be my next steps if so?

Thanks for your effort,
Knut Kujat.



--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Supermicro H8QME-2+ mct_d fatal exit.

[Stefan Reinauer]

On 3/5/10 2:33 PM, Andrew Goodbody wrote:
> Sorry, neglected to send original reply to list.
>
> Knut Kujat wrote:
>> Andrew Goodbody escribió:
>>> Knut Kujat wrote:
 Any suggestions ?
>>> The vendor BIOS is doing some initialisation that coreboot is not.
>>> This init survives a short shutdown but is lost after a longer period
>>> without power.
>> Yes, vendor BIOS must be doing something different when initializing
>> ram. But why is coreboot working just fine up here in the lab even if I
>> let it unplugged the whole night next morning I plug it back on and it
>> works!
>
> Don't focus on that too much. It's probably to do with the
> environment, or even just coincidence.
I think so too.

Two more suggestions:
- compare coreboot and vendor bios with SerialICE
- try disabling all cores / cpus except the BSP to make sure the problem
is not caused by the PCI access race conditions in the Fam8 and K10 ports...

Stefan

-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

[coreboot] [PATCH] Tyan S2912 Fam10

[Arne Georg Gleditsch]

Hi all,

I've just recently brought my development environment up to speed with
the latest coreboot version -- which is very nice! -- and caught a
couple of minor issues.  I'm not sure I fully understand the underlying
logic behind the different CAR setup routines in
src/cpu/amd/car/cache_as_ram.inc, but the attached patch is required to
make the S2912 board choose the correct code path.  I've also upped the
MAX_CPUS setting to 12 to accommodate 6-core Istanbul CPUs.  This might
make sense for other fam10 boards as well.

Signed-off-by: Arne Georg Gleditsch 

-- 
Arne.
diff --git a/src/mainboard/tyan/s2912_fam10/Kconfig b/src/mainboard/tyan/s2912_fam10/Kconfig
index 91f8f45..b3c4c4f 100644
--- a/src/mainboard/tyan/s2912_fam10/Kconfig
+++ b/src/mainboard/tyan/s2912_fam10/Kconfig
@@ -38,6 +38,26 @@ config DCACHE_RAM_GLOBAL_VAR_SIZE
 	default 0x04000
 	depends on BOARD_TYAN_S2912_FAM10
 
+config USE_FALLBACK_IMAGE
+	bool
+	default y
+	depends on BOARD_TYAN_S2912_FAM10
+
+config HAVE_FALLBACK_BOOT
+	bool
+	default y
+	depends on BOARD_TYAN_S2912_FAM10
+
+config CONFIG_USE_FAILOVER_IMAGE
+	bool
+	default y
+	depends on BOARD_TYAN_S2912_FAM10
+
+config CONFIG_HAVE_FAILOVER_BOOT
+	bool
+	default y
+	depends on BOARD_TYAN_S2912_FAM10
+
 config APIC_ID_OFFSET
 	hex
 	default 0
@@ -95,7 +115,7 @@ config HW_MEM_HOLE_SIZEK
 
 config MAX_CPUS
 	int
-	default 8
+	default 12
 	depends on BOARD_TYAN_S2912_FAM10
 
 config MAX_PHYSICAL_CPUS
-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

[coreboot] [PATCH] Tyan S2912 Fam10

[Arne Georg Gleditsch]

(Hm, this message seems to not have made it through.  Resending...)

Hi all,

I've just recently brought my development environment up to speed with
the latest coreboot version -- which is very nice! -- and caught a
couple of minor issues.  I'm not sure I fully understand the underlying
logic behind the different CAR setup routines in
src/cpu/amd/car/cache_as_ram.inc, but the attached patch is required to
make the S2912 board choose the correct code path.  I've also upped the
MAX_CPUS setting to 12 to accommodate 6-core Istanbul CPUs.  This might
make sense for other fam10 boards as well.

Signed-off-by: Arne Georg Gleditsch 

--
Arne.

diff --git a/src/mainboard/tyan/s2912_fam10/Kconfig b/src/mainboard/tyan/s2912_fam10/Kconfig
index 91f8f45..b3c4c4f 100644
--- a/src/mainboard/tyan/s2912_fam10/Kconfig
+++ b/src/mainboard/tyan/s2912_fam10/Kconfig
@@ -38,6 +38,26 @@ config DCACHE_RAM_GLOBAL_VAR_SIZE
 	default 0x04000
 	depends on BOARD_TYAN_S2912_FAM10
 
+config USE_FALLBACK_IMAGE
+	bool
+	default y
+	depends on BOARD_TYAN_S2912_FAM10
+
+config HAVE_FALLBACK_BOOT
+	bool
+	default y
+	depends on BOARD_TYAN_S2912_FAM10
+
+config CONFIG_USE_FAILOVER_IMAGE
+	bool
+	default y
+	depends on BOARD_TYAN_S2912_FAM10
+
+config CONFIG_HAVE_FAILOVER_BOOT
+	bool
+	default y
+	depends on BOARD_TYAN_S2912_FAM10
+
 config APIC_ID_OFFSET
 	hex
 	default 0
@@ -95,7 +115,7 @@ config HW_MEM_HOLE_SIZEK
 
 config MAX_CPUS
 	int
-	default 8
+	default 12
 	depends on BOARD_TYAN_S2912_FAM10
 
 config MAX_PHYSICAL_CPUS

-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

[coreboot] [commit] r5188 - in trunk/src/mainboard/asus: . p2b-ls

[repository service]

Author: uwe
Date: Fri Mar  5 17:31:41 2010
New Revision: 5188
URL: http://tracker.coreboot.org/trac/coreboot/changeset/5188

Log:
Add support for the ASUS P2B-LS mainboard.

Signed-off-by: Keith Hui 
Acked-by: Uwe Hermann 

Added:
   trunk/src/mainboard/asus/p2b-ls/
   trunk/src/mainboard/asus/p2b-ls/Kconfig
   trunk/src/mainboard/asus/p2b-ls/chip.h
   trunk/src/mainboard/asus/p2b-ls/devicetree.cb
   trunk/src/mainboard/asus/p2b-ls/irq_tables.c
   trunk/src/mainboard/asus/p2b-ls/mainboard.c
   trunk/src/mainboard/asus/p2b-ls/romstage.c
Modified:
   trunk/src/mainboard/asus/Kconfig

Modified: trunk/src/mainboard/asus/Kconfig
==
--- trunk/src/mainboard/asus/KconfigFri Mar  5 17:18:38 2010(r5187)
+++ trunk/src/mainboard/asus/KconfigFri Mar  5 17:31:41 2010(r5188)
@@ -27,6 +27,7 @@
 source "src/mainboard/asus/p2b/Kconfig"
 source "src/mainboard/asus/p2b-d/Kconfig"
 source "src/mainboard/asus/p2b-ds/Kconfig"
+source "src/mainboard/asus/p2b-ls/Kconfig"
 source "src/mainboard/asus/p2b-f/Kconfig"
 source "src/mainboard/asus/p3b-f/Kconfig"
 source "src/mainboard/asus/m2v-mx_se/Kconfig"

Added: trunk/src/mainboard/asus/p2b-ls/Kconfig
==
--- /dev/null   00:00:00 1970   (empty, because file is newly added)
+++ trunk/src/mainboard/asus/p2b-ls/Kconfig Fri Mar  5 17:31:41 2010
(r5188)
@@ -0,0 +1,52 @@
+##
+## This file is part of the coreboot project.
+##
+## Copyright (C) 2010 Keith Hui 
+##
+## 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
+##
+
+config BOARD_ASUS_P2B_LS
+   bool "P2B-LS"
+   select ARCH_X86
+   select CPU_INTEL_SLOT_1
+   select NORTHBRIDGE_INTEL_I440BX
+   select SOUTHBRIDGE_INTEL_I82371EB
+   select SUPERIO_WINBOND_W83977TF
+   select ROMCC
+   select HAVE_PIRQ_TABLE
+   select UDELAY_TSC
+   select BOARD_ROMSIZE_KB_256
+
+config MAINBOARD_DIR
+   string
+   default asus/p2b-ls
+   depends on BOARD_ASUS_P2B_LS
+
+config MAINBOARD_PART_NUMBER
+   string
+   default "P2B-LS"
+   depends on BOARD_ASUS_P2B_LS
+
+config HAVE_OPTION_TABLE
+   bool
+   default n
+   depends on BOARD_ASUS_P2B_LS
+
+config IRQ_SLOT_COUNT
+   int
+   default 8
+   depends on BOARD_ASUS_P2B_LS
+

Added: trunk/src/mainboard/asus/p2b-ls/chip.h
==
--- /dev/null   00:00:00 1970   (empty, because file is newly added)
+++ trunk/src/mainboard/asus/p2b-ls/chip.h  Fri Mar  5 17:31:41 2010
(r5188)
@@ -0,0 +1,22 @@
+/*
+ * This file is part of the coreboot project.
+ *
+ * Copyright (C) 2007 Uwe Hermann 
+ *
+ * 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
+ */
+
+extern struct chip_operations mainboard_ops;
+struct mainboard_config {};

Added: trunk/src/mainboard/asus/p2b-ls/devicetree.cb
==
--- /dev/null   00:00:00 1970   (empty, because file is newly added)
+++ trunk/src/mainboard/asus/p2b-ls/devicetree.cb   Fri Mar  5 17:31:41 
2010(r5188)
@@ -0,0 +1,59 @@
+chip northbridge/intel/i440bx  # Northbridge
+  device apic_cluster 0 on # APIC cluster
+chip cpu/intel/slot_1  # CPU
+  device apic 0 on end # APIC
+end
+  end
+  device pci_domain 0 on   # PCI domain
+device pci 0.0 on end  # Host bridge
+device pci 1.0 on end  # PCI/AGP bridge
+chip southbridge/intel/i8237

Re: [coreboot] Supermicro H8QME-2+ mct_d fatal exit.

[Knut Kujat]

Rudolf Marek escribió:
> Hi,
>
> This is pointing to something which is powered from 5VSB voltage. It
> could be some GPIO settings which sets voltage for ram through some
> other chip. It could be some powersequencing pin connected as GPIO
> too, it could be a i2c bus multiplexer operated by some GPIO pin too ;)
>
> I would suggest to dump the superio chip with "isadump" (all logical
> devices) and all registers powered from the 5VSB well if known. Check
> for changes on GPIO pins or SuperIO global config.
>
> Check if the fail is caused by missing SPD EPROMS (error SMBus reads)
> or just by ram itself.
>
> It could be also something from the SB itself, but try with superio
> first.
>
> Then compare the dumps with that you obtained from coreboot (you will
> need to program that) You can check from linux with legacy bios, then
> boot with coreboot and then boot with power unplugged.
>
> Good luck,
>
> Rudolf
>
Hi,

I did a output on status form status = mctRead_SPD(smbaddr, Index); in
mct_d.c and it only spits -1 out while on the working coreboot machine
it gives me several numbers until index = 64 on those dimms where ram is
installed. Is this a possible SPD EPROMS missing error you pointed out?
What would be my next steps if so?

Thanks for your effort,
Knut Kujat.

-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

[coreboot] [commit] r5187 - in trunk/src/cpu/intel: . slot_1

[repository service]

Author: uwe
Date: Fri Mar  5 17:18:38 2010
New Revision: 5187
URL: http://tracker.coreboot.org/trac/coreboot/changeset/5187

Log:
Add proper Slot 1 CPU support code/infrastructure.

Signed-off-by: Keith Hui 
Acked-by: Uwe Hermann 

Added:
   trunk/src/cpu/intel/slot_1/
   trunk/src/cpu/intel/slot_1/Kconfig
   trunk/src/cpu/intel/slot_1/Makefile.inc
   trunk/src/cpu/intel/slot_1/chip.h
   trunk/src/cpu/intel/slot_1/slot_1.c
Modified:
   trunk/src/cpu/intel/Kconfig
   trunk/src/cpu/intel/Makefile.inc

Modified: trunk/src/cpu/intel/Kconfig
==
--- trunk/src/cpu/intel/Kconfig Fri Mar  5 11:20:28 2010(r5186)
+++ trunk/src/cpu/intel/Kconfig Fri Mar  5 17:18:38 2010(r5187)
@@ -8,6 +8,7 @@
 source src/cpu/intel/bga956/Kconfig
 source src/cpu/intel/ep80579/Kconfig
 source src/cpu/intel/slot_2/Kconfig
+source src/cpu/intel/slot_1/Kconfig
 source src/cpu/intel/socket_mFCPGA478/Kconfig
 source src/cpu/intel/socket_mPGA478/Kconfig
 source src/cpu/intel/socket_mPGA479M/Kconfig

Modified: trunk/src/cpu/intel/Makefile.inc
==
--- trunk/src/cpu/intel/Makefile.incFri Mar  5 11:20:28 2010(r5186)
+++ trunk/src/cpu/intel/Makefile.incFri Mar  5 17:18:38 2010(r5187)
@@ -13,6 +13,7 @@
 subdirs-$(CONFIG_CPU_INTEL_SOCKET_MPGA604) += socket_mPGA604
 subdirs-$(CONFIG_CPU_INTEL_SOCKET_PGA370) += socket_PGA370
 subdirs-$(CONFIG_CPU_INTEL_SLOT_2) += slot_2
+subdirs-$(CONFIG_CPU_INTEL_SLOT_1) += slot_1
 
 #socket_mPGA604_533Mhz
 #socket_mPGA604_800Mhz

Added: trunk/src/cpu/intel/slot_1/Kconfig
==
--- /dev/null   00:00:00 1970   (empty, because file is newly added)
+++ trunk/src/cpu/intel/slot_1/Kconfig  Fri Mar  5 17:18:38 2010(r5187)
@@ -0,0 +1,33 @@
+##
+## This file is part of the coreboot project.
+##
+## Copyright (C) 2010 Keith Hui 
+##
+## 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
+##
+
+config CPU_INTEL_SLOT_1
+   bool
+
+config DCACHE_RAM_BASE
+   hex
+   default 0xc
+   depends on CPU_INTEL_SLOT_1
+
+config DCACHE_RAM_SIZE
+   hex
+   default 0x01000
+   depends on CPU_INTEL_SLOT_1
+

Added: trunk/src/cpu/intel/slot_1/Makefile.inc
==
--- /dev/null   00:00:00 1970   (empty, because file is newly added)
+++ trunk/src/cpu/intel/slot_1/Makefile.inc Fri Mar  5 17:18:38 2010
(r5187)
@@ -0,0 +1,29 @@
+##
+## This file is part of the coreboot project.
+##
+## Copyright (C) 2009 Uwe Hermann 
+##
+## 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
+##
+
+obj-y += slot_1.o
+subdirs-y += ../model_6xx
+subdirs-y += ../../x86/tsc
+subdirs-y += ../../x86/mtrr
+subdirs-y += ../../x86/lapic
+subdirs-y += ../../x86/cache
+subdirs-y += ../../x86/smm
+subdirs-y += ../microcode
+

Added: trunk/src/cpu/intel/slot_1/chip.h
==
--- /dev/null   00:00:00 1970   (empty, because file is newly added)
+++ trunk/src/cpu/intel/slot_1/chip.h   Fri Mar  5 17:18:38 2010(r5187)
@@ -0,0 +1,24 @@
+/*
+ * This file is part of the coreboot project.
+ *
+ * Copyright (C) 2010 Keith Hui 
+ *
+ * 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 distrib

Re: [coreboot] Supermicro H8QME-2+ mct_d fatal exit.

[Rudolf Marek]

Hi,

This is pointing to something which is powered from 5VSB voltage. It could be 
some GPIO settings which sets voltage for ram through some other chip. It could 
be some powersequencing pin connected as GPIO too, it could be a i2c bus 
multiplexer operated by some GPIO pin too ;)


I would suggest to dump the superio chip with "isadump" (all logical devices) 
and all registers powered from the 5VSB well if known. Check for changes on GPIO 
pins or SuperIO global config.


Check if the fail is caused by missing SPD EPROMS (error SMBus reads) or just by 
ram itself.


It could be also something from the SB itself, but try with superio first.

Then compare the dumps with that you obtained from coreboot (you will need to 
program that) You can check from linux with legacy bios, then boot with coreboot 
and then boot with power unplugged.


Good luck,

Rudolf

--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

[coreboot] [PATCH] YABEL compilation warnings

[Myles Watson]

This patch removes most of the rest of the compilation warnings for me.

1. Move run_bios prototype to device.h
2. Use time.h for get_time()
3. Move read_io and write_io to io.c and make them static
4. Make a couple of functions static in interrupt.c
5. Refactor a cast from char[] to u64 to get rid of potential alignment
problems and a warning

The only ones left are "unused" warnings.

I think we should get rid of that warning, since we conditionally call
functions based on debugging and various config variables.  Is there a case
where it helps enough to justify all the warnings?

This next part isn't part of the patch, but applying it makes qemu compile
with yabel (with and without debugging).

Index: Makefile
===
--- Makefile(revision 5186)
+++ Makefile(working copy)
@@ -239,7 +239,7 @@
 CFLAGS = $(INCLUDES) -Os -nostdinc
 CFLAGS += -nostdlib -Wall -Wundef -Wstrict-prototypes -Wmissing-prototypes
 CFLAGS += -Wwrite-strings -Wredundant-decls -Wno-trigraphs
-CFLAGS += -Wstrict-aliasing -Wshadow
+CFLAGS += -Wstrict-aliasing -Wshadow -Wno-unused
 ifeq ($(CONFIG_WARNINGS_ARE_ERRORS),y)
 CFLAGS += -Werror
 endif

Signed-off-by: Myles Watson 

Thanks,
Myles
Index: svn/src/devices/pci_device.c
===
--- svn.orig/src/devices/pci_device.c
+++ svn/src/devices/pci_device.c
@@ -652,7 +652,6 @@ void pci_dev_set_subsystem(struct device
 void pci_dev_init(struct device *dev)
 {
 #if CONFIG_PCI_ROM_RUN == 1 || CONFIG_VGA_ROM_RUN == 1
-	void run_bios(struct device *dev, unsigned long addr);
 	struct rom_header *rom, *ram;
 
 	if (CONFIG_PCI_ROM_RUN != 1 && /* Only execute VGA ROMs. */
Index: svn/src/include/device/device.h
===
--- svn.orig/src/include/device/device.h
+++ svn/src/include/device/device.h
@@ -117,6 +117,9 @@ const char *bus_path(struct bus *bus);
 void dev_set_enabled(device_t dev, int enable);
 void disable_children(struct bus *bus);
 
+/* Option ROM helper functions */
+void run_bios(struct device *dev, unsigned long addr);
+
 /* Helper functions */
 device_t find_dev_path(struct bus *parent, struct device_path *path);
 device_t alloc_find_dev(struct bus *parent, struct device_path *path);
Index: svn/util/x86emu/yabel/compat/functions.c
===
--- svn.orig/util/x86emu/yabel/compat/functions.c
+++ svn/util/x86emu/yabel/compat/functions.c
@@ -18,6 +18,7 @@
 #include 
 #include "../debug.h"
 #include "../biosemu.h"
+#include "../compat/time.h"
 
 #define VMEM_SIZE (1024 * 1024) /* 1 MB */
 
@@ -64,50 +65,3 @@ u64 get_time(void)
 act = ((u64) edx << 32) | eax; 
 return act;
 }
-
-unsigned int
-read_io(void *addr, size_t sz)
-{
-unsigned int ret;
-	/* since we are using inb instructions, we need the port number as 16bit value */
-	u16 port = (u16)(u32) addr;
-
-switch (sz) {
-case 1:
-		asm volatile ("inb %1, %b0" : "=a"(ret) : "d" (port));
-break;
-case 2:
-		asm volatile ("inw %1, %w0" : "=a"(ret) : "d" (port));
-break;
-case 4:
-		asm volatile ("inl %1, %0" : "=a"(ret) : "d" (port));
-break;
-default:
-ret = 0;
-}
-
-return ret;
-}
-
-int
-write_io(void *addr, unsigned int value, size_t sz)
-{
-	u16 port = (u16)(u32) addr;
-switch (sz) {
-	/* since we are using inb instructions, we need the port number as 16bit value */
-case 1:
-		asm volatile ("outb %b0, %1" : : "a"(value), "d" (port));
-break;
-case 2:
-		asm volatile ("outw %w0, %1" : : "a"(value), "d" (port));
-break;
-case 4:
-		asm volatile ("outl %0, %1" : : "a"(value), "d" (port));
-break;
-default:
-return -1;
-}
-
-return 0;
-}
-
Index: svn/util/x86emu/yabel/compat/time.h
===
--- svn.orig/util/x86emu/yabel/compat/time.h
+++ svn/util/x86emu/yabel/compat/time.h
@@ -14,4 +14,5 @@
 
 /* TODO: check how this works in x86 */
 static unsigned long tb_freq = 0;
+u64 get_time(void);
 #endif 
Index: svn/util/x86emu/yabel/io.c
===
--- svn.orig/util/x86emu/yabel/io.c
+++ svn/util/x86emu/yabel/io.c
@@ -24,12 +24,51 @@
 #include 
 #endif
 
-// those are defined in net-snk/oflib/pci.c
-extern unsigned int read_io(void *, size_t);
-extern int write_io(void *, unsigned int, size_t);
+static unsigned int
+read_io(void *addr, size_t sz)
+{
+unsigned int ret;
+	/* since we are using inb instructions, we need the port number as 16bit value */
+	u16 port = (u16)(u32) addr;
+
+switch (sz) {
+case 1:
+		asm volatile ("inb %1, %b0" : "=a"(ret) : "d" (port));
+break;
+case 2:
+		asm volatile ("

Re: [coreboot] [PATCH] YABEL compilation warnings

[Myles Watson]

On Fri, Mar 5, 2010 at 8:04 AM, Myles Watson  wrote:

> This patch removes most of the rest of the compilation warnings for me.
>
> 1. Move run_bios prototype to device.h
> 2. Use time.h for get_time()
>
2b. Move tb_freq into functions.c instead of the time.h

> 3. Move read_io and write_io to io.c and make them static
> 4. Make a couple of functions static in interrupt.c
> 5. Refactor a cast from char[] to u64 to get rid of potential alignment
> problems and a warning
>
> The only ones left are "unused function" warnings.
>
> I think we should get rid of that warning, since we conditionally call
> functions based on debugging and various config variables.  Is there a case
> where it helps enough to justify all the warnings?
>
> This next part isn't part of the patch, but applying it makes qemu compile
> with yabel (with and without debugging).
>
> Index: Makefile
> ===
> --- Makefile(revision 5186)
> +++ Makefile(working copy)
> @@ -239,7 +239,7 @@
>  CFLAGS = $(INCLUDES) -Os -nostdinc
>  CFLAGS += -nostdlib -Wall -Wundef -Wstrict-prototypes -Wmissing-prototypes
>  CFLAGS += -Wwrite-strings -Wredundant-decls -Wno-trigraphs
> -CFLAGS += -Wstrict-aliasing -Wshadow
>

I meant no-unused-function:

> +CFLAGS += -Wstrict-aliasing -Wshadow -Wno-unused-function
>


>  ifeq ($(CONFIG_WARNINGS_ARE_ERRORS),y)
>  CFLAGS += -Werror
>  endif
>

 Signed-off-by: Myles Watson 

Thanks,
Myles
Index: svn/src/devices/pci_device.c
===
--- svn.orig/src/devices/pci_device.c
+++ svn/src/devices/pci_device.c
@@ -652,7 +652,6 @@ void pci_dev_set_subsystem(struct device
 void pci_dev_init(struct device *dev)
 {
 #if CONFIG_PCI_ROM_RUN == 1 || CONFIG_VGA_ROM_RUN == 1
-	void run_bios(struct device *dev, unsigned long addr);
 	struct rom_header *rom, *ram;
 
 	if (CONFIG_PCI_ROM_RUN != 1 && /* Only execute VGA ROMs. */
Index: svn/src/include/device/device.h
===
--- svn.orig/src/include/device/device.h
+++ svn/src/include/device/device.h
@@ -117,6 +117,9 @@ const char *bus_path(struct bus *bus);
 void dev_set_enabled(device_t dev, int enable);
 void disable_children(struct bus *bus);
 
+/* Option ROM helper functions */
+void run_bios(struct device *dev, unsigned long addr);
+
 /* Helper functions */
 device_t find_dev_path(struct bus *parent, struct device_path *path);
 device_t alloc_find_dev(struct bus *parent, struct device_path *path);
Index: svn/util/x86emu/yabel/compat/functions.c
===
--- svn.orig/util/x86emu/yabel/compat/functions.c
+++ svn/util/x86emu/yabel/compat/functions.c
@@ -18,6 +18,7 @@
 #include 
 #include "../debug.h"
 #include "../biosemu.h"
+#include "../compat/time.h"
 
 #define VMEM_SIZE (1024 * 1024) /* 1 MB */
 
@@ -52,6 +53,8 @@ void run_bios(struct device * dev, unsig
 	}
 }
 
+unsigned long tb_freq = 0;
+
 u64 get_time(void)
 {
 u64 act;
@@ -64,50 +67,3 @@ u64 get_time(void)
 act = ((u64) edx << 32) | eax; 
 return act;
 }
-
-unsigned int
-read_io(void *addr, size_t sz)
-{
-unsigned int ret;
-	/* since we are using inb instructions, we need the port number as 16bit value */
-	u16 port = (u16)(u32) addr;
-
-switch (sz) {
-case 1:
-		asm volatile ("inb %1, %b0" : "=a"(ret) : "d" (port));
-break;
-case 2:
-		asm volatile ("inw %1, %w0" : "=a"(ret) : "d" (port));
-break;
-case 4:
-		asm volatile ("inl %1, %0" : "=a"(ret) : "d" (port));
-break;
-default:
-ret = 0;
-}
-
-return ret;
-}
-
-int
-write_io(void *addr, unsigned int value, size_t sz)
-{
-	u16 port = (u16)(u32) addr;
-switch (sz) {
-	/* since we are using inb instructions, we need the port number as 16bit value */
-case 1:
-		asm volatile ("outb %b0, %1" : : "a"(value), "d" (port));
-break;
-case 2:
-		asm volatile ("outw %w0, %1" : : "a"(value), "d" (port));
-break;
-case 4:
-		asm volatile ("outl %0, %1" : : "a"(value), "d" (port));
-break;
-default:
-return -1;
-}
-
-return 0;
-}
-
Index: svn/util/x86emu/yabel/compat/time.h
===
--- svn.orig/util/x86emu/yabel/compat/time.h
+++ svn/util/x86emu/yabel/compat/time.h
@@ -13,5 +13,6 @@
 #define _BIOSEMU_COMPAT_TIME_H
 
 /* TODO: check how this works in x86 */
-static unsigned long tb_freq = 0;
+extern unsigned long tb_freq;
+u64 get_time(void);
 #endif 
Index: svn/util/x86emu/yabel/io.c
===
--- svn.orig/util/x86emu/yabel/io.c
+++ svn/util/x86emu/yabel/io.c
@@ -24,12 +24,51 @@
 #include 
 #endif
 
-// those are defined in net-snk/oflib/pci.c
-extern unsigned int read_io(

Re: [coreboot] [PATCH] ASUS P2B-LS support, RAM detection for 440BX, add Slot 1 CPU, Microcode for Intel Tualatin CPUs

[Andrew Goodbody]

Joseph Smith wrote:

That's easy... so you do something like this:


As I understand it that only works if there is a DIMM in the 4th slot. 
Otherwise you'll set a four slot system with the 3 slot configuration 
leading to incorrect routing of clocks.


Andrew

--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Supermicro H8QME-2+ mct_d fatal exit.

[Andrew Goodbody]

Sorry, neglected to send original reply to list.

Knut Kujat wrote:

Andrew Goodbody escribió:

Knut Kujat wrote:

Any suggestions ?

The vendor BIOS is doing some initialisation that coreboot is not.
This init survives a short shutdown but is lost after a longer period
without power.

Yes, vendor BIOS must be doing something different when initializing
ram. But why is coreboot working just fine up here in the lab even if I
let it unplugged the whole night next morning I plug it back on and it
works!


Don't focus on that too much. It's probably to do with the environment, 
or even just coincidence.



Is there a multiplexer on the SMBUS?

I honestly don't know, I have:


A multiplexer on the SMBUS was just something that occurred to me. To 
find it you would need to actually use the SMBUS controller to scan the 
SMBUS for devices. This is not a trivial task but I think there may be 
tools out there to help you.


A better approach would be to start by actually debugging what is going 
wrong in RAM init. That will tell you the area to investigate for 
differences.


Andrew

--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

[coreboot] [PATCH] Istanbul support

[Arne Georg Gleditsch]

Hi,

The following patch implements Opteron Fam 10 rev D (aka Istanbul)
support for coreboot.  I have not updated MAX_CPUS for all fam10
mainboards, but it might make sense to multiply those by 1.5.

Signed-off-by: Arne Georg Gleditsch 

-- 
Arne.
diff --git a/src/cpu/amd/model_10xxx/defaults.h b/src/cpu/amd/model_10xxx/defaults.h
index 6529008..b1b245a 100644
--- a/src/cpu/amd/model_10xxx/defaults.h
+++ b/src/cpu/amd/model_10xxx/defaults.h
@@ -315,44 +315,44 @@ static const struct {
 	u32 mask;
 } fam10_htphy_default[] = {
 
-	/* Errata 344 - Fam10 C2
+	/* Errata 344 - Fam10 C2/D0
 	 * System software should set bit 6 of F4x1[9C, 94, 8C, 84]_x[78:70, 68:60]. */
-	{ 0x60, AMD_RB_C2 | AMD_DA_C2, AMD_PTYPE_ALL, HTPHY_LINKTYPE_ALL,
+	{ 0x60, AMD_RB_C2 | AMD_DA_C2 | AMD_HY_D0, AMD_PTYPE_ALL, HTPHY_LINKTYPE_ALL,
 	  0x0040, 0x0040 },
-	{ 0x61, AMD_RB_C2 | AMD_DA_C2, AMD_PTYPE_ALL, HTPHY_LINKTYPE_ALL,
+	{ 0x61, AMD_RB_C2 | AMD_DA_C2 | AMD_HY_D0, AMD_PTYPE_ALL, HTPHY_LINKTYPE_ALL,
 	  0x0040, 0x0040 },
-	{ 0x62, AMD_RB_C2 | AMD_DA_C2, AMD_PTYPE_ALL, HTPHY_LINKTYPE_ALL,
+	{ 0x62, AMD_RB_C2 | AMD_DA_C2 | AMD_HY_D0, AMD_PTYPE_ALL, HTPHY_LINKTYPE_ALL,
 	  0x0040, 0x0040 },
-	{ 0x63, AMD_RB_C2 | AMD_DA_C2, AMD_PTYPE_ALL, HTPHY_LINKTYPE_ALL,
+	{ 0x63, AMD_RB_C2 | AMD_DA_C2 | AMD_HY_D0, AMD_PTYPE_ALL, HTPHY_LINKTYPE_ALL,
 	  0x0040, 0x0040 },
-	{ 0x64, AMD_RB_C2 | AMD_DA_C2, AMD_PTYPE_ALL, HTPHY_LINKTYPE_ALL,
+	{ 0x64, AMD_RB_C2 | AMD_DA_C2 | AMD_HY_D0, AMD_PTYPE_ALL, HTPHY_LINKTYPE_ALL,
 	  0x0040, 0x0040 },
-	{ 0x65, AMD_RB_C2 | AMD_DA_C2, AMD_PTYPE_ALL, HTPHY_LINKTYPE_ALL,
+	{ 0x65, AMD_RB_C2 | AMD_DA_C2 | AMD_HY_D0, AMD_PTYPE_ALL, HTPHY_LINKTYPE_ALL,
 	  0x0040, 0x0040 },
-	{ 0x66, AMD_RB_C2 | AMD_DA_C2, AMD_PTYPE_ALL, HTPHY_LINKTYPE_ALL,
+	{ 0x66, AMD_RB_C2 | AMD_DA_C2 | AMD_HY_D0, AMD_PTYPE_ALL, HTPHY_LINKTYPE_ALL,
 	  0x0040, 0x0040 },
-	{ 0x67, AMD_RB_C2 | AMD_DA_C2, AMD_PTYPE_ALL, HTPHY_LINKTYPE_ALL,
+	{ 0x67, AMD_RB_C2 | AMD_DA_C2 | AMD_HY_D0, AMD_PTYPE_ALL, HTPHY_LINKTYPE_ALL,
 	  0x0040, 0x0040 },
-	{ 0x68, AMD_RB_C2 | AMD_DA_C2, AMD_PTYPE_ALL, HTPHY_LINKTYPE_ALL,
+	{ 0x68, AMD_RB_C2 | AMD_DA_C2 | AMD_HY_D0, AMD_PTYPE_ALL, HTPHY_LINKTYPE_ALL,
 	  0x0040, 0x0040 },
 
-	{ 0x70, AMD_RB_C2 | AMD_DA_C2, AMD_PTYPE_ALL, HTPHY_LINKTYPE_ALL,
+	{ 0x70, AMD_RB_C2 | AMD_DA_C2 | AMD_HY_D0, AMD_PTYPE_ALL, HTPHY_LINKTYPE_ALL,
 	  0x0040, 0x0040 },
-	{ 0x71, AMD_RB_C2 | AMD_DA_C2, AMD_PTYPE_ALL, HTPHY_LINKTYPE_ALL,
+	{ 0x71, AMD_RB_C2 | AMD_DA_C2 | AMD_HY_D0, AMD_PTYPE_ALL, HTPHY_LINKTYPE_ALL,
 	  0x0040, 0x0040 },
-	{ 0x72, AMD_RB_C2 | AMD_DA_C2, AMD_PTYPE_ALL, HTPHY_LINKTYPE_ALL,
+	{ 0x72, AMD_RB_C2 | AMD_DA_C2 | AMD_HY_D0, AMD_PTYPE_ALL, HTPHY_LINKTYPE_ALL,
 	  0x0040, 0x0040 },
-	{ 0x73, AMD_RB_C2 | AMD_DA_C2, AMD_PTYPE_ALL, HTPHY_LINKTYPE_ALL,
+	{ 0x73, AMD_RB_C2 | AMD_DA_C2 | AMD_HY_D0, AMD_PTYPE_ALL, HTPHY_LINKTYPE_ALL,
 	  0x0040, 0x0040 },
-	{ 0x74, AMD_RB_C2 | AMD_DA_C2, AMD_PTYPE_ALL, HTPHY_LINKTYPE_ALL,
+	{ 0x74, AMD_RB_C2 | AMD_DA_C2 | AMD_HY_D0, AMD_PTYPE_ALL, HTPHY_LINKTYPE_ALL,
 	  0x0040, 0x0040 },
-	{ 0x75, AMD_RB_C2 | AMD_DA_C2, AMD_PTYPE_ALL, HTPHY_LINKTYPE_ALL,
+	{ 0x75, AMD_RB_C2 | AMD_DA_C2 | AMD_HY_D0, AMD_PTYPE_ALL, HTPHY_LINKTYPE_ALL,
 	  0x0040, 0x0040 },
-	{ 0x76, AMD_RB_C2 | AMD_DA_C2, AMD_PTYPE_ALL, HTPHY_LINKTYPE_ALL,
+	{ 0x76, AMD_RB_C2 | AMD_DA_C2 | AMD_HY_D0, AMD_PTYPE_ALL, HTPHY_LINKTYPE_ALL,
 	  0x0040, 0x0040 },
-	{ 0x77, AMD_RB_C2 | AMD_DA_C2, AMD_PTYPE_ALL, HTPHY_LINKTYPE_ALL,
+	{ 0x77, AMD_RB_C2 | AMD_DA_C2 | AMD_HY_D0, AMD_PTYPE_ALL, HTPHY_LINKTYPE_ALL,
 	  0x0040, 0x0040 },
-	{ 0x78, AMD_RB_C2 | AMD_DA_C2, AMD_PTYPE_ALL, HTPHY_LINKTYPE_ALL,
+	{ 0x78, AMD_RB_C2 | AMD_DA_C2 | AMD_HY_D0, AMD_PTYPE_ALL, HTPHY_LINKTYPE_ALL,
 	  0x0040, 0x0040 },
 
 	/* Errata 354 - Fam10 C2
@@ -395,20 +395,20 @@ static const struct {
 	{ 0x58, AMD_RB_C2 | AMD_DA_C2, AMD_PTYPE_ALL, HTPHY_LINKTYPE_ALL,
 	  0x0040, 0x0040 },
 
-	/* Errata 327 - Fam10 C2
+	/* Errata 327 - Fam10 C2/D0
 	 * BIOS should set the Link Phy Impedance Register[RttCtl]
 	 * (F4x1[9C, 94, 8C, 84]_x[D0, C0][31:29]) to 010b and
 	 * Link Phy Impedance Register[RttIndex]
 	 * (F4x1[9C, 94, 8C, 84]_x[D0, C0][20:16]) to 00100b */
-	{ 0xC0, AMD_RB_C2 | AMD_DA_C2, AMD_PTYPE_ALL, HTPHY_LINKTYPE_ALL,
+	{ 0xC0, AMD_RB_C2 | AMD_DA_C2 | AMD_HY_D0, AMD_PTYPE_ALL, HTPHY_LINKTYPE_ALL,
 	  0x4004, 0xe01F },
-	{ 0xD0, AMD_RB_C2 | AMD_DA_C2, AMD_PTYPE_ALL, HTPHY_LINKTYPE_ALL,
+	{ 0xD0, AMD_RB_C2 | AMD_DA_C2 | AMD_HY_D0, AMD_PTYPE_ALL, HTPHY_LINKTYPE_ALL,
 	  0x4004, 0xe01F },
 
-	{ 0x520A, AMD_RB_C2 | AMD_DA_C2, AMD_PTYPE_ALL, HTPHY_LINKTYPE_ALL,
+	{ 0x520A, AMD_RB_C2 | AMD_DA_C2 | AMD_HY_D0, AMD_PTYPE_ALL, HTPHY_LINKTYPE_ALL,
 	  0x4000, 0x6000 },	/* HT_PHY_DLL_REG */
 
-	{ 0x530A, AMD_RB_C2 | AMD_DA_C2, AMD_PTYPE_A

[coreboot] [PATCH] ulzma delay

[Arne Georg Gleditsch]

Hi,

In the same way as unrv2b used to, ulzma exhibits very bad instruction
fetch behavior on my Opteron CPUs/Tyan S2912 board.  I'm not entirely
sure what causes this, and despite having spent significant time digging
through it I'm not able to mend this by adjusting MTRRs or other cache
settings.  So I've taken the easy route, and patched ulzma to copy
LzmaDecode to the stack before executing.  This brings running time for
fallback stage uncompress from nearly two minutes to 50ms here.

I'm also seeing weird performance behavior from memset -- this is not
consistent, and just started appearing at some point in my development
here.  I assume this has something to do with alignment, but I was
frankly not in the mood to start debugging this as well.  I've included
a patch that reduces memset to "rep stosb" under x86, which eliminates
the worst-case behavior (in the order of minutes spent in
cbfs_load_stage) I was seeing here.

Signed-off-by: Arne Georg Gleditsch 

-- 
Arne.
diff --git a/src/lib/lzma.c b/src/lib/lzma.c
index fc533c0..245fece 100644
--- a/src/lib/lzma.c
+++ b/src/lib/lzma.c
@@ -25,6 +25,9 @@ unsigned long ulzma(unsigned char * src, unsigned char * dst)
 	CLzmaDecoderState state;
 	SizeT mallocneeds;
 	unsigned char scratchpad[15980];
+	unsigned char LzmaDecode_buf[4096] __attribute__ ((aligned(64)));
+	int (*LzmaDecode_rel)(CLzmaDecoderState *, const unsigned char *, SizeT, SizeT *,
+			  unsigned char *, SizeT, SizeT *);
 
 	memcpy(properties, src, LZMA_PROPERTIES_SIZE);
 	outSize = *(UInt32 *)(src + LZMA_PROPERTIES_SIZE);
@@ -38,7 +41,9 @@ unsigned long ulzma(unsigned char * src, unsigned char * dst)
 		return 0;
 	}
 	state.Probs = (CProb *)scratchpad;
-	res = LzmaDecode(&state, src + LZMA_PROPERTIES_SIZE + 8, (SizeT)0x, &inProcessed,
+	memcpy(LzmaDecode_buf, LzmaDecode, sizeof(LzmaDecode_buf));
+	LzmaDecode_rel = (void *)LzmaDecode_buf;
+	res = LzmaDecode_rel(&state, src + LZMA_PROPERTIES_SIZE + 8, (SizeT)0x, &inProcessed,
 		dst, outSize, &outProcessed);
 	if (res != 0) {
 		printk_warning("lzma: Decoding error = %d\n", res);
diff --git a/src/lib/lzmadecode.h b/src/lib/lzmadecode.h
index dedde0d..91160f5 100644
--- a/src/lib/lzmadecode.h
+++ b/src/lib/lzmadecode.h
@@ -62,6 +62,7 @@ typedef struct _CLzmaDecoderState
 
 int LzmaDecode(CLzmaDecoderState *vs,
 const unsigned char *inStream, SizeT inSize, SizeT *inSizeProcessed,
-unsigned char *outStream, SizeT outSize, SizeT *outSizeProcessed);
+unsigned char *outStream, SizeT outSize, SizeT *outSizeProcessed)
+__attribute__ ((aligned(64)));
 
 #endif
diff --git a/src/lib/memset.c b/src/lib/memset.c
index bac3305..1167178 100644
--- a/src/lib/memset.c
+++ b/src/lib/memset.c
@@ -2,11 +2,15 @@
 
 void *memset(void *s, int c, size_t n)
 {
+#if CONFIG_ARCH_X86
+	asm volatile("rep stosb" :: "D"(s), "a"(c), "c"(n));
+#else
 	int i;
 	char *ss = (char *) s;
 
 	for (i = 0; i < (int)n; i++)
 		ss[i] = c;
+#endif
 
 	return s;
 }
diff --git a/src/mainboard/tyan/s2912_fam10/romstage.c b/src/mainboard/tyan/s2912_fam10/romstage.c
index 45d0d94..c319735 100644
--- a/src/mainboard/tyan/s2912_fam10/romstage.c
+++ b/src/mainboard/tyan/s2912_fam10/romstage.c
@@ -371,7 +371,6 @@ void real_main(unsigned long bist, unsigned long cpu_init_detectedx)
 	raminit_amdmct(sysinfo);
 	post_code(0x41);
 
-	printk_debug("\n*** Yes, the copy/decompress is taking a while, FIXME!\n");
 	post_cache_as_ram();	// BSP switch stack to ram, copy then execute LB.
 	post_code(0x43);	// Should never see this post code.
 }
-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] [PATCH] ASUS P2B-LS support, RAM detection for 440BX, add Slot 1 CPU, Microcode for Intel Tualatin CPUs

[Joseph Smith]

On Fri, 05 Mar 2010 13:04:27 +, Mark Marshall 
wrote:
> Joseph Smith wrote:
>> On 03/05/2010 03:03 AM, Mark Marshall wrote:
>>> On 04/03/10 13:10, Joseph Smith wrote:
 On 03/04/2010 07:38 AM, Joseph Smith wrote:
> On 03/04/2010 07:30 AM, Uwe Hermann wrote:
>> On Thu, Mar 04, 2010 at 10:05:57AM +, Mark Marshall wrote:
>>> On 03/03/10 04:19, Keith Hui wrote:
>>> The first problem is that this motherboard only has three DIMM
>>> slots. This means you have to set SDRAMC to something different;
>>> 0x0103 works for me.
>>>
>> Hm, seems to be determined by SDRAMPWR + MMCONFIG, and MMCONFIG
>> seems to
>> be a hardware-strap (so we can check it), but not sure about
> SDRAMPWR.
>>
 >>>
 I think a simple SPD probe would work, if the correct value is
returned
 you know you have memory in that slot, otherwise if 0xff is returned
 then no memory is present. Do this probe for as many slots as the 440
 supports. Then set your registers based on that.
>>>
>>> The issue here is the number of DIMM slots on the motherboard, not the
>>> number of sticks in the slots. Some 440BX boards have four slots, while
>>> others only have three.
>>>
>>> MM
>>>
>> That is fine. Then if 440bx datasheet says it supports 4 slots, then 
>> that should be the standard.
>> 
> 
> Please check this section of the 440BX data sheet.
> 
>3.3.24 SDRAMC—SDRAM Control Register (Device 0)
> 
> We are interested in bit 4.
> 
>   SDRAMPWR. The SDRAMPWR bit controls how the CKE signals are driven
>   for different DRAM configurations. For a 3 DIMM configuration,
>   SDRAMPWR should be set to ‘0’. For a 4 DIMM configuration,
>   SDRAMPWR should be set to ‘1’. In this case the 82443BX drives a
>   single CKE signal (GCKE). The combination of SDRAMPWR and MMCONFIG
>   (DRAMC register) determine the functioning of the CKE signals.
>   Refer to the DRAMC register (Section 3.3.15, “DRAMC—DRAM
>   Control Register (Device 0)” on page 3-19) for more details.
> 
>   Note: When PCIRST# assertion occurs during POS/STR, these bits
>   are not reset to 0.
> 
> As far as I can tell we cannot auto-detect this.  Some (many)
> 440BX boards only have three DIMM slots, and in these cases the
> clocks are routed differently to the boards with four DIMM slots.
> 
That's easy... so you do something like this:

slot4_detect = (spd_read_byte((DIMM_SPD_BASE + 3), SPD_MEMORY_TYPE);

if (slot4_detect != 0xff) {

 /* We have 4 slots */
 Set bit 4 in SDRAMPWR
 #define DIMM_SOCKETS 4
} else {

 /* We have 3 slots */
 Set bit 4 in SDRAMPWR
 #define DIMM_SOCKETS 3
}

Hope that helps.

-- 
Thanks,
Joseph Smith
Set-Top-Linux
www.settoplinux.org


-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] [PATCH] sb600: don't load verb for codec

[Carl-Daniel Hailfinger]

On 05.03.2010 11:13, Stefan Reinauer wrote:
> On 3/5/10 10:29 AM, Bao, Zheng wrote:
>   
>> Don't load verb in BIOS stage. It is not BIOS's responsibility.
>>   
>> 
> Who is responsible for that, then?
>  
> On i945 I definitely don't get sound on most systems if I don't load the
> verb in coreboot. I also don't think the Linux drivers do it.
>   
>> And we can not have verb for every single codec.
>>   
>> 
> Have a look at the i82801gx southbridge; I think it was based on the
> sb600 code, but I changed it so I can have a per mainboard verb table.
>   

I think we should try to mirror the behaviour of the vendor BIOS. The
Linux kernel source has some interesting info about HD Audio:
http://www.mjmwired.net/kernel/Documentation/sound/alsa/HD-Audio.txt

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] sb600: don't load verb for codec

[Andrew Goodbody]

Stefan Reinauer wrote:

On 3/5/10 10:29 AM, Bao, Zheng wrote:

Don't load verb in BIOS stage. It is not BIOS's responsibility.
  

Who is responsible for that, then?


Those verbs are motherboard specific as they describe the actual 
external connections so they should not be in southbridge code. They 
cannot be inferred by the driver so they absolutely should be done by 
coreboot. So they should be moved to motherboard specific code not 
dropped entirely.


Andrew

--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] [PATCH] ASUS P2B-LS support, RAM detection for 440BX, add Slot 1 CPU, Microcode for Intel Tualatin CPUs

[Mark Marshall]

Joseph Smith wrote:

On 03/05/2010 03:03 AM, Mark Marshall wrote:

On 04/03/10 13:10, Joseph Smith wrote:

On 03/04/2010 07:38 AM, Joseph Smith wrote:

On 03/04/2010 07:30 AM, Uwe Hermann wrote:

On Thu, Mar 04, 2010 at 10:05:57AM +, Mark Marshall wrote:

On 03/03/10 04:19, Keith Hui wrote:
The first problem is that this motherboard only has three DIMM
slots. This means you have to set SDRAMC to something different;
0x0103 works for me.


Hm, seems to be determined by SDRAMPWR + MMCONFIG, and MMCONFIG
seems to
be a hardware-strap (so we can check it), but not sure about SDRAMPWR.


>>>
I think a simple SPD probe would work, if the correct value is returned
you know you have memory in that slot, otherwise if 0xff is returned
then no memory is present. Do this probe for as many slots as the 440
supports. Then set your registers based on that.


The issue here is the number of DIMM slots on the motherboard, not the
number of sticks in the slots. Some 440BX boards have four slots, while
others only have three.

MM

That is fine. Then if 440bx datasheet says it supports 4 slots, then 
that should be the standard.




Please check this section of the 440BX data sheet.

  3.3.24 SDRAMC—SDRAM Control Register (Device 0)

We are interested in bit 4.

 SDRAMPWR. The SDRAMPWR bit controls how the CKE signals are driven
 for different DRAM configurations. For a 3 DIMM configuration,
 SDRAMPWR should be set to ‘0’. For a 4 DIMM configuration,
 SDRAMPWR should be set to ‘1’. In this case the 82443BX drives a
 single CKE signal (GCKE). The combination of SDRAMPWR and MMCONFIG
 (DRAMC register) determine the functioning of the CKE signals.
 Refer to the DRAMC register (Section 3.3.15, “DRAMC—DRAM
 Control Register (Device 0)” on page 3-19) for more details.

 Note: When PCIRST# assertion occurs during POS/STR, these bits
 are not reset to 0.

As far as I can tell we cannot auto-detect this.  Some (many)
440BX boards only have three DIMM slots, and in these cases the
clocks are routed differently to the boards with four DIMM slots.

MM


--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] YABEL debug broken again

[Stefan Reinauer]

On 3/5/10 1:11 PM, Joseph Smith wrote:
>>> You'd still get some information from the debugging statements that
>>> work,
>>> but the statements referencing undefined variables are not likely to
>>> give
>>> you any good information.
>>>
>
> Hello Pattrick.
> We made the CONFIG_DEBUG automatic.
The code that was causing the errors in vbe.c was not being called, so
no gain, just pain ;-) But it compiles anyways, now.

-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] YABEL debug broken again

[Joseph Smith]

On 03/05/2010 05:21 AM, Stefan Reinauer wrote:

On 3/5/10 11:20 AM, Pattrick Hueper wrote:

Ah... very cool...

so Josephs issue with VBE debugging is resolved as well?

Patty


Worked for me... The X86EMU_DEBUG code may want some more tweaking to
make it more silent / verbose with some of the flags, though

Ah, cool. I will try it out and let you know. I think a debugging menu 
is a great idea.


--
Thanks,
Joseph Smith
Set-Top-Linux
www.settoplinux.org

--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] YABEL debug broken again

[Joseph Smith]

On 03/05/2010 04:42 AM, Pattrick Hueper wrote:

Hi,

i am trying to get a setup to fix this... but i cant even compile...
in menuconfig for qemu i cant seem to set CONFIG_DEBUG and thus
enabling YABEL_DEBUG breaks the build.
If i manually set CONFIG_DEBUG=y in .config and then run make
oldconfig, CONFIG_DEBUG is unset again.

Help?

Regards, Pattrick



On Wed, Mar 3, 2010 at 4:05 PM, Myles Watson  wrote:



It compiles for me with 5132, but not 5135.  You could look at the

changes:

http://tracker.coreboot.org/trac/coreboot/changeset/5135


Yes.  It compiles without debug, right?


Yes.


If I were you I'd comment out the debugging statements that are breaking
for
you, unless you are trying to debug the vbe code.  It looks like
framebuffer_address and friends were commented out in 5135.


Well I was kind of looking forward to the vbe debug. Hmm.


You'd still get some information from the debugging statements that work,
but the statements referencing undefined variables are not likely to give
you any good information.


Hello Pattrick.
We made the CONFIG_DEBUG automatic.

-
Author: myles
Date: Fri Feb 19 20:08:11 2010
New Revision: 5131
URL: http://tracker.coreboot.org/trac/coreboot/changeset/5131

Log:
1. Change CONFIG_DEBUG to DEBUG in util/x86emu/*
2. Make DEBUG depend on CONFIG_YABEL_DEBUG_FLAGS being nonzero



Attached is a copy of my config.h for reference.


--
Thanks,
Joseph Smith
Set-Top-Linux
www.settoplinux.org
/*
 * Automatically generated C config: don't edit
 * coreboot version: 4.0
 * Tue Mar  2 17:13:53 2010
 */
#define AUTOCONF_INCLUDED
#define CONFIG_CONSOLE_SERIAL8250 1
#define CONFIG_VENDOR_JETWAY 0
#define CONFIG_VENDOR_WINENT 0
#define CONFIG_COREBOOT_ROMSIZE_KB_4096 0
#define CONFIG_BOARD_HAS_HARD_RESET 0
#define CONFIG_VENDOR_RCA 0
#define CONFIG_VENDOR_NEC 0
#define CONFIG_VENDOR_IEI 0
#define CONFIG_VENDOR_IBM 0
#define CONFIG_ROMBASE 0x
#define CONFIG_VENDOR_ASI 0
#define CONFIG_LB_CKS_LOC 126
#define CONFIG_UDELAY_TSC 1
#define CONFIG_VENDOR_VIA 0
#define CONFIG_GENERATE_MP_TABLE 0
#define CONFIG_MAINBOARD_PCI_SUBSYSTEM_VENDOR_ID 0x0
#define CONFIG_STACK_SIZE 0x8000
#define CONFIG_K8_REV_F_SUPPORT 0
#define CONFIG_VAR_MTRR_HOLE 1
#define CONFIG_VENDOR_MSI 0
#define CONFIG_ARCH "i386"
#define CONFIG_HYPERTRANSPORT_PLUGIN_SUPPORT 0
#define CONFIG_BOARD_HAS_FADT 0
#define CONFIG_TSC_X86RDTSC_CALIBRATE_WITH_TIMER2 0
#define CONFIG_VENDOR_TECHNEXION 0
#define CONFIG_USE_DCACHE_RAM 0
#define CONFIG_HAVE_OPTION_TABLE 0
#define CONFIG_WRITE_HIGH_TABLES 1
#define CONFIG_YABEL_DIRECTHW 0
#define CONFIG_COMPRESSED_PAYLOAD_NRV2B 0
#define CONFIG_ID_SECTION_OFFSET 0x10
#define CONFIG_VENDOR_PC_ENGINES 0
#define CONFIG_HAVE_MAINBOARD_RESOURCES 0
#define CONFIG_PIRQ_ROUTE 0
#define CONFIG_I830_VIDEO_MB_512KB 0
#define CONFIG_USE_WATCHDOG_ON_BOOT 0
#define CONFIG_DEFAULT_CONSOLE_LOGLEVEL 8
#define CONFIG_CONSOLE_LOGBUF 0
#define CONFIG_AP_CODE_IN_CAR 0
#define CONFIG_VENDOR_SUPERMICRO 0
#define CONFIG_CONSOLE_VGA_MULTI 0
#define CONFIG_MAX_PHYSICAL_CPUS 1
#define CONFIG_USE_FALLBACK_IMAGE 1
#define CONFIG_PAYLOAD_ELF 0
#define CONFIG_VENDOR_BIOSTAR 0
#define CONFIG_PCI_BUS_SEGN_BITS 0
#define CONFIG_TINY_BOOTBLOCK 0
#define CONFIG_ARCH_X86 1
#define CONFIG_HAVE_FALLBACK_BOOT 1
#define CONFIG_MAXIMUM_CONSOLE_LOGLEVEL 8
#define CONFIG_ROM_IMAGE_SIZE 0x1
#define CONFIG_VENDOR_A_TREND 0
#define CONFIG_MAINBOARD_PART_NUMBER "IP1000"
#define CONFIG_CBFS_PREFIX "fallback"
#define CONFIG_VENDOR_LIPPERT 0
#define CONFIG_VENDOR_ABIT 0
#define CONFIG_PCI_64BIT_PREF_MEM 0
#define CONFIG_VENDOR_DELL 0
#define CONFIG_VENDOR_BCOM 0
#define CONFIG_USE_PRINTK_IN_CAR 0
#define CONFIG_CONSOLE_VGA 1
#define CONFIG_PCI_IO_CFG_EXT 0
#define CONFIG_VENDOR_RODA 0
#define CONFIG_MAX_REBOOT_CNT 3
#define CONFIG_VENDOR_THOMSON 1
#define CONFIG_VENDOR_KONTRON 0
#define CONFIG_VENDOR_OLPC 0
#define CONFIG_MMCONF_SUPPORT 0
#define CONFIG_VENDOR_TECHNOLOGIC 0
#define CONFIG_PCI_OPTION_ROM_RUN_REALMODE 0
#define CONFIG_ENABLE_APIC_EXT_ID 0
#define CONFIG_VENDOR_NEWISYS 0
#define CONFIG_CONSOLE_SERIAL_9600 0
#define CONFIG_ACPI_SSDTX_NUM 0
#define CONFIG_SOUTHBRIDGE_INTEL_I82801DX 1
#define CONFIG_VENDOR_AZZA 0
#define CONFIG_SERIAL_POST 0
#define CONFIG_VIDEO_MB 8
#define CONFIG_USE_FAILOVER_IMAGE 0
#define CONFIG_DEBUG 0
#define CONFIG_VENDOR_TYAN 0
#define CONFIG_VENDOR_ASUS 0
#define CONFIG_GDB_STUB 1
#define CONFIG_VGA_BIOS 1
#define CONFIG_USBDEBUG_DIRECT 0
#define CONFIG_HAVE_FAILOVER_BOOT 0
#define CONFIG_VENDOR_AXUS 0
#define CONFIG_WAIT_BEFORE_CPUS_INIT 0
#define CONFIG_ROMCC 1
#define CONFIG_VENDOR_BROADCOM 0
#define CONFIG_IRQ_SLOT_COUNT 7
#define CONFIG_VENDOR_SOYO 0
#define CONFIG_FALLBACK_VGA_BIOS_FILE "alm_2756.bin"
#define CONFIG_SUPERIO_SMSC_SMSCSUPERIO 1
#define CONFIG_VENDOR_GIGABYTE 0
#define CONFIG_VENDOR_SUNW 0
#define CONFIG_PCI_ROM_RUN 1
#define CONFIG_VGA_ROM_RUN 1
#define CONFIG_USE_INIT 0
#define CONFIG_MAX_CPUS 1
#define CONFIG

Re: [coreboot] [PATCH] ASUS P2B-LS support, RAM detection for 440BX, add Slot 1 CPU, Microcode for Intel Tualatin CPUs

[Joseph Smith]

On 03/05/2010 03:03 AM, Mark Marshall wrote:

On 04/03/10 13:10, Joseph Smith wrote:

On 03/04/2010 07:38 AM, Joseph Smith wrote:

On 03/04/2010 07:30 AM, Uwe Hermann wrote:

On Thu, Mar 04, 2010 at 10:05:57AM +, Mark Marshall wrote:

On 03/03/10 04:19, Keith Hui wrote:
The first problem is that this motherboard only has three DIMM
slots. This means you have to set SDRAMC to something different;
0x0103 works for me.


Hm, seems to be determined by SDRAMPWR + MMCONFIG, and MMCONFIG
seems to
be a hardware-strap (so we can check it), but not sure about SDRAMPWR.


>>>
I think a simple SPD probe would work, if the correct value is returned
you know you have memory in that slot, otherwise if 0xff is returned
then no memory is present. Do this probe for as many slots as the 440
supports. Then set your registers based on that.


The issue here is the number of DIMM slots on the motherboard, not the
number of sticks in the slots. Some 440BX boards have four slots, while
others only have three.

MM

That is fine. Then if 440bx datasheet says it supports 4 slots, then 
that should be the standard.


--
Thanks,
Joseph Smith
Set-Top-Linux
www.settoplinux.org

--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] [PATCH] ASUS P2B-LS support, RAM detection for 440BX, add Slot 1 CPU, Microcode for Intel Tualatin CPUs

[Joseph Smith]

On 03/05/2010 12:53 AM, Keith Hui wrote:



On Thu, Mar 4, 2010 at 8:26 AM, Joseph Smith mailto:j...@settoplinux.org>> wrote:

I would not worry about the microcode updates right now. CAR for
Intel 6bx is coming real soon and the microcode updates will be
included :-)

CAN'T WAIT! :D Then I can say goodbye to the messiness that is romcc, lol.


**You are setting alot more than just dra here, I would
rename this function something like sdram_setup_registers().

Good point. Eventually I wanted to name it sdram_initalize() just like
i830, but there are a couple other references to the current names
elsewhere. One step at a time I guess.



I also noticed you did not use the memory initialize
each row/side code from the i830. That code is extremely important
for multiple memory sticks. Besides that everything else looks
really good, great work!

There were some code that send RAM commands to the modules in the BX
code. I just kept them around, thinking that this code in i830 may be
specific to i830.

The only code that may be specific to the i830 is the DRC regs. Also you 
may have to tweek:


dimm_end = pci_read_config8(NORTHBRIDGE, DRB + row);

for the 440bx. This basicly reading the sdram size to set as the start 
of the next row.


The rest of the routine (and I have researched it extensively) is pretty 
much the standard for sdram initialization.



Mark, the problem you saw might be MBFS and MBSC not being set properly.
I have reversed how the factory BIOS programmed them and have the code
in my working copy. I'll see if that makes a difference. We are still
hardcoded to CAS3 latency. One step at a time again I guess.

On another front, with the board running factory BIOS, I dumped the BX's
config space (lspci -s 0:0:0.0 -xxx) with various DIMM configurations,
especially with two sticks in DIMM0&1, DIMM2&3, and 3 sticks. These
three scenarios are where most of the logics are. I can post them if
anyone wants to look at them. All my RAMs are double sided, one 128MB
and the others are 256MB.

To figure out how this gets coded for the 3-slot P2B, Someone would need
to reverse the vendor bios for that board or do same as above.


FYI, serialice is awesome at dumping raminit routines :-)


--
Thanks,
Joseph Smith
Set-Top-Linux
www.settoplinux.org

--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] YABEL debug broken again

[Stefan Reinauer]

On 3/5/10 11:20 AM, Pattrick Hueper wrote:
> Ah... very cool...
>
> so Josephs issue with VBE debugging is resolved as well?
>
> Patty
>   
Worked for me... The X86EMU_DEBUG code may want some more tweaking to
make it more silent / verbose with some of the flags, though

-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

[coreboot] [commit] r5186 - trunk

[repository service]

Author: stepan
Date: Fri Mar  5 11:20:28 2010
New Revision: 5186
URL: http://tracker.coreboot.org/trac/coreboot/changeset/5186

Log:
This patch fixes two things:

- -m32 is already defined by xcompile if the compiler is a 64bit compiler so
  drop it from the Makefile.
- allow "obj-.. += foo.o" for util/, too. Otherwise the source files in
  util/x86emu/ put their objects in util/ instead of $(obj)/util

Signed-off-by: Stefan Reinauer 
Acked-by: Stefan Reinauer 

Modified:
   trunk/Makefile

Modified: trunk/Makefile
==
--- trunk/Makefile  Fri Mar  5 11:03:50 2010(r5185)
+++ trunk/Makefile  Fri Mar  5 11:20:28 2010(r5186)
@@ -119,7 +119,7 @@
 crt0s:=
 ldscripts:=
 types:=obj initobj driver smmobj
-includemakefiles=$(foreach type,$(2), $(eval $(type)-y:=)) $(eval subdirs-y:=) 
$(eval -include $(1)) $(if $(strip $(3)),$(foreach type,$(2),$(eval 
$(type)s+=$$(patsubst src/%,$(obj)/%,$$(addprefix $(dir 
$(1)),$$($(type)-y)) $(eval subdirs+=$$(subst $(PWD)/,,$$(abspath 
$$(addprefix $(dir $(1)),$$(subdirs-y)
+includemakefiles=$(foreach type,$(2), $(eval $(type)-y:=)) $(eval subdirs-y:=) 
$(eval -include $(1)) $(if $(strip $(3)),$(foreach type,$(2),$(eval 
$(type)s+=$$(patsubst util/%,$(obj)/util/%,$$(patsubst 
src/%,$(obj)/%,$$(addprefix $(dir $(1)),$$($(type)-y))) $(eval 
subdirs+=$$(subst $(PWD)/,,$$(abspath $$(addprefix $(dir $(1)),$$(subdirs-y)
 evaluate_subdirs=$(eval cursubdirs:=$(subdirs)) $(eval subdirs:=) $(foreach 
dir,$(cursubdirs),$(eval $(call 
includemakefiles,$(dir)/Makefile.inc,$(types),$(1 $(if $(subdirs),$(eval 
$(call evaluate_subdirs, $(1
 
 # collect all object files eligible for building
@@ -148,55 +148,63 @@
$(CPP) -D__ACPI__ -P $(CPPFLAGS) -include $(obj)/config.h -I$(src) 
-I$(src)/mainboard/$(MAINBOARDDIR) $$< -o $$(basename $$@).asl
iasl -p $$(basename $$@) -tc $$(basename $$@).asl
mv $$(basename $$@).hex $$(basename $$@).c
-   $(CC) -m32 $$(CFLAGS) $$(if $$(subst dsdt,,$$(basename $$(notdir 
$$@))), -DAmlCode=AmlCode_$$(basename $$(notdir $$@))) -c -o $$@ $$(basename 
$$@).c
+   $(CC) $$(CFLAGS) $$(if $$(subst dsdt,,$$(basename $$(notdir $$@))), 
-DAmlCode=AmlCode_$$(basename $$(notdir $$@))) -c -o $$@ $$(basename $$@).c
 endef
 
 define objs_c_template
+$(obj)/$(1)%.o: $(1)%.c $(obj)/config.h
+   @printf "CC $$(subst $$(obj)/,,$$(@))\n"
+   $(CC) $$(CFLAGS) -c -o $$@ $$<
+
 $(obj)/$(1)%.o: src/$(1)%.c $(obj)/config.h
@printf "CC $$(subst $$(obj)/,,$$(@))\n"
-   $(CC) -m32 $$(CFLAGS) -c -o $$@ $$<
+   $(CC) $$(CFLAGS) -c -o $$@ $$<
 endef
 
 define objs_S_template
+$(obj)/$(1)%.o: $(1)%.S $(obj)/config.h
+   @printf "CC $$(subst $$(obj)/,,$$(@))\n"
+   $(CC) -DASSEMBLY $$(CFLAGS) -c -o $$@ $$<
+
 $(obj)/$(1)%.o: src/$(1)%.S $(obj)/config.h
@printf "CC $$(subst $$(obj)/,,$$(@))\n"
-   $(CC) -m32 -DASSEMBLY $$(CFLAGS) -c -o $$@ $$<
+   $(CC) -DASSEMBLY $$(CFLAGS) -c -o $$@ $$<
 endef
 
 define initobjs_c_template
 $(obj)/$(1)%.initobj.o: src/$(1)%.c $(obj)/config.h
@printf "CC $$(subst $$(obj)/,,$$(@))\n"
-   $(CC) -m32 $$(CFLAGS) -c -o $$@ $$<
+   $(CC) $$(CFLAGS) -c -o $$@ $$<
 endef
 
 define initobjs_S_template
 $(obj)/$(1)%.initobj.o: src/$(1)%.S $(obj)/config.h
@printf "CC $$(subst $$(obj)/,,$$(@))\n"
-   $(CC) -m32 -DASSEMBLY $$(CFLAGS) -c -o $$@ $$<
+   $(CC) -DASSEMBLY $$(CFLAGS) -c -o $$@ $$<
 endef
 
 define drivers_c_template
 $(obj)/$(1)%.driver.o: src/$(1)%.c $(obj)/config.h
@printf "CC $$(subst $$(obj)/,,$$(@))\n"
-   $(CC) -m32 $$(CFLAGS) -c -o $$@ $$<
+   $(CC) $$(CFLAGS) -c -o $$@ $$<
 endef
 
 define drivers_S_template
 $(obj)/$(1)%.driver.o: src/$(1)%.S
@printf "CC $$(subst $$(obj)/,,$$(@))\n"
-   $(CC) -m32 -DASSEMBLY $$(CFLAGS) -c -o $$@ $$<
+   $(CC) -DASSEMBLY $$(CFLAGS) -c -o $$@ $$<
 endef
 
 define smmobjs_c_template
 $(obj)/$(1)%.smmobj.o: src/$(1)%.c
@printf "CC $$(subst $$(obj)/,,$$(@))\n"
-   $(CC) -m32 $$(CFLAGS) -c -o $$@ $$<
+   $(CC) $$(CFLAGS) -c -o $$@ $$<
 endef
 
 define smmobjs_S_template
 $(obj)/$(1)%.smmobj.o: src/$(1)%.S
@printf "CC $$(subst $$(obj)/,,$$(@))\n"
-   $(CC) -m32 $$(CFLAGS) -c -o $$@ $$<
+   $(CC) $$(CFLAGS) -c -o $$@ $$<
 endef
 
 usetemplate=$(foreach d,$(sort $(dir $($(1,$(eval $(call 
$(1)_$(2)_template,$(subst $(obj)/,,$(d)

-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] YABEL debug broken again

[Pattrick Hueper]

Ah... very cool...

so Josephs issue with VBE debugging is resolved as well?

Patty

On Fri, Mar 5, 2010 at 11:05 AM, Stefan Reinauer  wrote:
> On 3/5/10 10:42 AM, Pattrick Hueper wrote:
>> Hi,
>>
>> i am trying to get a setup to fix this... but i cant even compile...
>> in menuconfig for qemu i cant seem to set CONFIG_DEBUG and thus
>> enabling YABEL_DEBUG breaks the build.
>> If i manually set CONFIG_DEBUG=y in .config and then run make
>> oldconfig, CONFIG_DEBUG is unset again.
>>
>> Help?
>>
>> Regards, Pattrick
> Do svn up, r5185 should fix X86EMU/YABEL debugging and makes it
> separately user selectable in "make menuconfig" under the "Debugging" menu.
>
> Stefan
>
>
> --
> coreboot mailing list: coreboot@coreboot.org
> http://www.coreboot.org/mailman/listinfo/coreboot
>

-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] [PATCH] sb600: don't load verb for codec

[Stefan Reinauer]

On 3/5/10 10:29 AM, Bao, Zheng wrote:
> Don't load verb in BIOS stage. It is not BIOS's responsibility.
>   
Who is responsible for that, then?
 
On i945 I definitely don't get sound on most systems if I don't load the
verb in coreboot. I also don't think the Linux drivers do it.
> And we can not have verb for every single codec.
>   
Have a look at the i82801gx southbridge; I think it was based on the
sb600 code, but I changed it so I can have a per mainboard verb table.
In mainboard_enable() in mainboard.c, call verb_setup() which does:

#include "hda_verb.h"

static void verb_setup(void)
{
cim_verb_data = mainboard_cim_verb_data;
cim_verb_data_size = sizeof(mainboard_cim_verb_data);
}

and hda_verb.c looks like this:

static u32 mainboard_cim_verb_data[] = {
/* coreboot specific header */
0x10ec0262, // Codec Vendor ID / Device ID
0x10714700, // Subsystem ID
0x000d, // Number of jacks

/* HDA Codec Subsystem ID Verb Table: 0x10ec */
0x00172000,
0x00172100,
0x001722EC,
0x00172310,

/* Pin Widget Verb Table */

/* Pin Complex (NID 0x12) */
0x01271CF0,
0x01271D11,
0x01271E11,
...
};

extern u32 * cim_verb_data;
extern u32 cim_verb_data_size;



-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] YABEL debug broken again

[Stefan Reinauer]

On 3/5/10 10:42 AM, Pattrick Hueper wrote:
> Hi,
>
> i am trying to get a setup to fix this... but i cant even compile...
> in menuconfig for qemu i cant seem to set CONFIG_DEBUG and thus
> enabling YABEL_DEBUG breaks the build.
> If i manually set CONFIG_DEBUG=y in .config and then run make
> oldconfig, CONFIG_DEBUG is unset again.
>
> Help?
>
> Regards, Pattrick
Do svn up, r5185 should fix X86EMU/YABEL debugging and makes it
separately user selectable in "make menuconfig" under the "Debugging" menu.

Stefan


-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

[coreboot] [PATCH] sb600: don't load verb for codec

[Bao, Zheng]

Don't load verb in BIOS stage. It is not BIOS's responsibility.
And we can not have verb for every single codec.

Signed-off-by: Zheng Bao 

Index: src/southbridge/amd/sb600/sb600_hda.c
===
--- src/southbridge/amd/sb600/sb600_hda.c   (revision 5184)
+++ src/southbridge/amd/sb600/sb600_hda.c   (working copy)
@@ -90,88 +90,10 @@
return 0;
 }
 
-static u32 cim_verb_data[] = {
-   0x01471c10,
-   0x01471d40,
-   0x01471e01,
-   0x01471f01,
-/* 1 */
-   0x01571c12,
-   0x01571d10,
-   0x01571e01,
-   0x01571f01,
-/* 2 */
-   0x01671c11,
-   0x01671d60,
-   0x01671e01,
-   0x01671f01,
-/* 3 */
-   0x01771c14,
-   0x01771d20,
-   0x01771e01,
-   0x01771f01,
-/* 4 */
-   0x01871c30,
-   0x01871d90,
-   0x01871ea1,
-   0x01871f01,
-/* 5 */
-   0x01971cf0,
-   0x01971d11,
-   0x01971e11,
-   0x01971f41,
-/* 6 */
-   0x01a71c80,
-   0x01a71d30,
-   0x01a71e81,
-   0x01a71f01,
-/* 7 */
-   0x01b71cf0,
-   0x01b71d11,
-   0x01b71e11,
-   0x01b71f41,
-/* 8 */
-   0x01c71cf0,
-   0x01c71d11,
-   0x01c71e11,
-   0x01c71f41,
-/* 9 */
-   0x01d71cf0,
-   0x01d71d11,
-   0x01d71e11,
-   0x01d71f41,
-/* 10 */
-   0x01e71c50,
-   0x01e71d11,
-   0x01e71e44,
-   0x01e71f01,
-/* 11 */
-   0x01f71c60,
-   0x01f71d61,
-   0x01f71ec4,
-   0x01f71f01,
-};
-static u32 find_verb(u32 viddid, u32 ** verb)
-{
-   device_t azalia_dev = dev_find_slot(0, PCI_DEVFN(0x14, 2));
-   struct southbridge_amd_sb600_config *cfg =
-   (struct southbridge_amd_sb600_config
*)azalia_dev->chip_info;
-   printk_debug("Dev=%s\n", dev_path(azalia_dev));
-   printk_debug("Default viddid=%x\n", cfg->hda_viddid);
-   printk_debug("Reading viddid=%x\n", viddid);
-   if (!cfg)
-   return 0;
-   if (viddid != cfg->hda_viddid)
-   return 0;
-   *verb = (u32 *) cim_verb_data;
-   return sizeof(cim_verb_data) / sizeof(u32);
-}
-
 /**
  *  Wait 50usec for for the codec to indicate it is ready
  *  no response would imply that the codec is non-operative
  */
-
 static int wait_for_ready(u8 *base)
 {
/* Use a 50 usec timeout - the Linux kernel uses the
@@ -194,7 +116,6 @@
  *  the previous command.  No response would imply that the code
  *  is non-operative
  */
-
 static int wait_for_valid(u8 *base)
 {
/* Use a 50 usec timeout - the Linux kernel uses the
@@ -215,9 +136,6 @@
 static void codec_init(u8 * base, int addr)
 {
u32 dword;
-   u32 *verb;
-   u32 verb_size;
-   int i;
 
/* 1 */
if (wait_for_ready(base) == -1)
@@ -232,26 +150,7 @@
dword = read32(base + 0x64);
 
/* 2 */
-   printk_debug("codec viddid: %08x\n", dword);
-   verb_size = find_verb(dword, &verb);
-
-   if (!verb_size) {
-   printk_debug("No verb!\n");
-   return;
-   }
-
-   printk_debug("verb_size: %d\n", verb_size);
-   /* 3 */
-   for (i = 0; i < verb_size; i++) {
-   if (wait_for_ready(base) == -1)
-   return;
-
-   write32(base + 0x60, verb[i]);
-
-   if (wait_for_valid(base) == -1)
-   return;
-   }
-   printk_debug("verb loaded!\n");
+   printk_debug("%x(th) codec viddid: %08x\n", addr, dword);
 }
 
 static void codecs_init(u8 * base, u32 codec_mask)


sb600_dont_load_verb.patch
Description: sb600_dont_load_verb.patch
-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] YABEL debug broken again

[Pattrick Hueper]

Hi,

i am trying to get a setup to fix this... but i cant even compile...
in menuconfig for qemu i cant seem to set CONFIG_DEBUG and thus
enabling YABEL_DEBUG breaks the build.
If i manually set CONFIG_DEBUG=y in .config and then run make
oldconfig, CONFIG_DEBUG is unset again.

Help?

Regards, Pattrick



On Wed, Mar 3, 2010 at 4:05 PM, Myles Watson  wrote:
>
>> >> > It compiles for me with 5132, but not 5135.  You could look at the
>> >> changes:
>> >> > http://tracker.coreboot.org/trac/coreboot/changeset/5135
>> >> >
>> > Yes.  It compiles without debug, right?
>> >
>> Yes.
>>
>> > If I were you I'd comment out the debugging statements that are breaking
>> > for
>> > you, unless you are trying to debug the vbe code.  It looks like
>> > framebuffer_address and friends were commented out in 5135.
>> >
>> Well I was kind of looking forward to the vbe debug. Hmm.
>
> You'd still get some information from the debugging statements that work,
> but the statements referencing undefined variables are not likely to give
> you any good information.
>
> Patrick and Stefan:
> Any hints for Joe?
>
> Thanks,
> Myles
>
> --
> coreboot mailing list: coreboot@coreboot.org
> http://www.coreboot.org/mailman/listinfo/coreboot
>

-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] [PATCH] ASUS P2B-LS support, RAM detection for 440BX, add Slot 1 CPU, Microcode for Intel Tualatin CPUs

[Mark Marshall]

On 04/03/10 13:10, Joseph Smith wrote:

On 03/04/2010 07:38 AM, Joseph Smith wrote:

On 03/04/2010 07:30 AM, Uwe Hermann wrote:

On Thu, Mar 04, 2010 at 10:05:57AM +, Mark Marshall wrote:

On 03/03/10 04:19, Keith Hui wrote:
The first problem is that this motherboard only has three DIMM
slots. This means you have to set SDRAMC to something different;
0x0103 works for me.


Hm, seems to be determined by SDRAMPWR + MMCONFIG, and MMCONFIG seems to
be a hardware-strap (so we can check it), but not sure about SDRAMPWR.


 >>>
I think a simple SPD probe would work, if the correct value is returned
you know you have memory in that slot, otherwise if 0xff is returned
then no memory is present. Do this probe for as many slots as the 440
supports. Then set your registers based on that.


The issue here is the number of DIMM slots on the motherboard, not the 
number of sticks in the slots.  Some 440BX boards have four slots, while 
others only have three.


MM

--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot