Re: [coreboot] [PATCH] The function int15 working on the Technexion's tim5690.

[Libra Li]

Hi Marc Jones,

1.
+typedef struct {
+int mask[256];
+int (*intXX_handler[256])(struct eregs *regs);
+}interrupt_handlers;

The mainboard_interrupt_handlers need modification if the structure
is not needed.

2.
+   if(!(*intXX_handler))
+   {
+   /* Set up C interrupt handlers */
+   setup_interrupt_handlers();
+   }

Yes, this is because mainboard_interrupt_handlers gets called first.


2009/12/22 Marc Jones 

> On Mon, Dec 21, 2009 at 6:15 PM, Libra Li  wrote:
> > Hi,
> >
> > The VGA BIOS is through int15 getting LCD panel ID. Then the VBIOS
> call
> > int15's "Get LCD panel ID".
> > The panel ID is selection by switch.
> > This function is reference "AMD RS690 ASIC Family BIOS Developer's
> > Guide".
> >
> > Thanks.
> >
> > Signed-off-by: Libra Li 
>
> Hi Libra Li,
>
> Thanks for making these changes. I like the idea of the mainboard
> interrupt function. I have a few comments.
>
> +typedef struct {
> +int mask[256];
> +int (*intXX_handler[256])(struct eregs *regs);
> +}interrupt_handlers;
>
> This is a really big structure and probably not needed. I don't think
> anyone would override every interrupt vector, just one or two like you
> are doing. Maybe just use a table that has the interrupt and function
> pointer.
>
>
> +   if(!(*intXX_handler))
> +   {
> +   /* Set up C interrupt handlers */
> +   setup_interrupt_handlers();
> +   }
> +
>
> Is this because mainboard_interrupt_handlers gets called first and the
> interrupts are over written? It would be better if the defaults could
> always be loaded and then the main board interrupts get fixed up.
>
> Thanks,
> Marc
>
>
> --
> http://marcjonesconsulting.com
>
-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] More SeaBIOS timings

[Rudolf Marek]

It's a vt8237r thing - basically I need to add:



It is PSON gating. RTC Power Well registers must be avoided to access until the 
gating is complete. SMBus happen to be power well register ;)


Kevin, I think we need some fix with the timeout maybe? Definetely for the AT 
PSU. They need to manually finish some power sequencing.


Rudolf

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

Re: [coreboot] [PATCH] The function int15 working on the Technexion's tim5690.

[Marc Jones]

On Mon, Dec 21, 2009 at 6:15 PM, Libra Li  wrote:
> Hi,
>
>     The VGA BIOS is through int15 getting LCD panel ID. Then the VBIOS call
> int15's "Get LCD panel ID".
>     The panel ID is selection by switch.
>     This function is reference "AMD RS690 ASIC Family BIOS Developer's
> Guide".
>
>     Thanks.
>
>     Signed-off-by: Libra Li 

Hi Libra Li,

Thanks for making these changes. I like the idea of the mainboard
interrupt function. I have a few comments.

+typedef struct {
+int mask[256];
+int (*intXX_handler[256])(struct eregs *regs);
+}interrupt_handlers;

This is a really big structure and probably not needed. I don't think
anyone would override every interrupt vector, just one or two like you
are doing. Maybe just use a table that has the interrupt and function
pointer.


+   if(!(*intXX_handler))
+   {
+   /* Set up C interrupt handlers */
+   setup_interrupt_handlers();
+   }
+

Is this because mainboard_interrupt_handlers gets called first and the
interrupts are over written? It would be better if the defaults could
always be loaded and then the main board interrupts get fixed up.

Thanks,
Marc


-- 
http://marcjonesconsulting.com

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

[coreboot] Coreboot Support for MSI Board MS-6702E

[freeman2411]

Hi Guys!

Can someone help me to get coreboot support for my board MS-6702E?

Thank you very much!

Greetings

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

Re: [coreboot] More SeaBIOS timings

[Kevin O'Connor]

On Mon, Dec 21, 2009 at 10:29:54AM -0500, Tom Sylla wrote:
> This looks like it was an interesting task. I had some questions and
> comments from previous fast-POST exercises:
> 
> On Mon, Dec 21, 2009 at 12:44 AM, Kevin O'Connor  wrote:
> > * cpu appears to start running around 350ms
> 
> Do you have a scope at all?. The only way to know this number for sure
> would be to put a scope on the reset wire and the rs-232 to see how
> long the power sequence takes.

I don't have a scope.  The boot doesn't start until I release the
power button, and when I do that this machine seems to write a null
byte to the serial port.  All my timing reports are deltas from this
furst null byte.  I can't perceive any timing difference between my
releasing the button and the null showing up on the screen.

In any case, my main emphasis is on the software, so if the actual
hardware init is a few ms more, it doesn't really matter that much to
me.

> > * smbus power stabilizes around 400ms
> 
> I don't understand this. SMBus power is 3.3V, and I don't know why a
> platform would be executing code before 3.3V is stable. The ATX is
> turning on 3.3, 5, and 12 *first*, then the various regulators,
> including the core regulator, come on after that. There should be
> various hardware voltage monitors keeping things in reset until all
> the voltages are up. Am I not understanding something? What exactly do
> you mean by "smbus power stabilizes"?

It's a vt8237r thing - basically I need to add:

--- src/southbridge/via/vt8237r/vt8237r_early_smbus.c   (revision 4967)
+++ src/southbridge/via/vt8237r/vt8237r_early_smbus.c   (working copy)
@@ -147,6 +147,9 @@
die("Power management controller not found\r\n");
}
 
+while (!(pci_read_config8(dev, 0x82) & (1<<6)))
+;
+
/*
 * 7 = SMBus Clock from RTC 32.768KHz
 * 5 = Internal PLL reset from susp

or the smbus access is unreliable.  Rudolf pointed this out to me.  I
believe the smbus_fixup() code later in the same file is an attempt to
workaround this same issue.

> > * I've commented out the calls to wbinvd() in coreboot's mtrr
> >  cache_disable logic - those calls are expensive and the code seems
> >  to work without it.
> 
> You removed *all* of them? You might just be getting lucky, that is a
> bit dangerous.

I removed the ones around the mtrr loading.  I'm not sure why adding
mtrrs requires a cache flush - I need to research this further.  If
anyone does know, let me know.

> Just a note: PCI has a specified time called Trhfa which is the time
> from reset going high to the first allowable configuration access. It
> is specified as 2^25 clocks, which is 1 second for 33MHz PCI and 500ms
> for 66MHz PCI. You have to heed that if you want to generically
> support random PCI plugin cards. If you are making fixed-configuration
> concessions, then you can do it as fast as your particular hardware
> allows.

Interesting.  This machine didn't have anything in its pci slot.

-Kevin

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

[coreboot] [PATCH] The function int15 working on the Technexion's tim5690.

[Libra Li]

Hi,

The VGA BIOS is through int15 getting LCD panel ID. Then the VBIOS call
int15's "Get LCD panel ID".
The panel ID is selection by switch.
This function is reference "AMD RS690 ASIC Family BIOS Developer's
Guide".

Thanks.

Signed-off-by: Libra Li 
Index: src/mainboard/technexion/tim5690/vgabios.h
===
--- src/mainboard/technexion/tim5690/vgabios.h	(revision 0)
+++ src/mainboard/technexion/tim5690/vgabios.h	(revision 0)
@@ -0,0 +1,37 @@
+/*
+ * This file is part of the coreboot project.
+ *
+ * Copyright (C) 2009 coresystems GmbH
+ * Copyright (C) 2009 Libra Li 
+ *
+ * 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
+ */
+
+/* AMD Chipset */
+#define AMD_RS690_INT15 0x4E08
+
+typedef struct __rs690_int15_regs__
+{
+u8 fun00_panel_id;  // Callback Sub-Function 00h - Get LCD Panel ID
+u8 fun05_tv_standard;   // Callback Sub-Function 05h - Select Boot-up TV Standard
+}rs690_int15_regs;
+
+typedef struct __rs690_vbios_regs__
+{
+rs690_int15_regsint15_regs;
+}rs690_vbios_regs;
+
+/* Initialization VBIOS function */
+extern void vgabios_init(rs690_vbios_regs *vbios_regs);
Index: src/mainboard/technexion/tim5690/Makefile.inc
===
--- src/mainboard/technexion/tim5690/Makefile.inc	(revision 4981)
+++ src/mainboard/technexion/tim5690/Makefile.inc	(working copy)
@@ -33,6 +33,7 @@
 obj-y += tn_post_code.o
 
 obj-y += speaker.o
+obj-y += vgabios.o
 
 # This is part of the conversion to init-obj and away from included code.
 
Index: src/mainboard/technexion/tim5690/cache_as_ram_auto.c
===
--- src/mainboard/technexion/tim5690/cache_as_ram_auto.c	(revision 4981)
+++ src/mainboard/technexion/tim5690/cache_as_ram_auto.c	(working copy)
@@ -145,20 +145,6 @@
 }
 #endif/* CONFIG_USE_FALLBACK_IMAGE == 1 */
 
-/* Early mainboard specific GPIO setup. */
-static void mb_gpio_init(void)
-{
-	/* Init Super I/O GPIOs. Done early. */
-	it8712f_enter_conf();
-	outb(IT8712F_CONFIG_REG_LDN, SIO_INDEX);
-	outb(IT8712F_GPIO, SIO_DATA);
-	outb(0x62, SIO_INDEX); // set Simple I/O Base Address 0x200
-	outb(0x02, SIO_DATA);
-	outb(0x63, SIO_INDEX);
-	outb(0x00, SIO_DATA);
-	it8712f_exit_conf();
-}
-
 void real_main(unsigned long bist, unsigned long cpu_init_detectedx);
 
 void cache_as_ram_main(unsigned long bist, unsigned long cpu_init_detectedx)
@@ -191,7 +177,6 @@
 
 	/* it8712f_enable_serial does not use its 1st parameter. */
 	it8712f_enable_serial(0, CONFIG_TTYS0_BASE);
-	mb_gpio_init();
 	it8712f_kill_watchdog();
 	uart_init();
 	console_init();
Index: src/mainboard/technexion/tim5690/vgabios.c
===
--- src/mainboard/technexion/tim5690/vgabios.c	(revision 0)
+++ src/mainboard/technexion/tim5690/vgabios.c	(revision 0)
@@ -0,0 +1,83 @@
+/*
+ * This file is part of the coreboot project.
+ *
+ * Copyright (C) 2009 coresystems GmbH
+ * Copyright (C) 2009 Libra Li 
+ *
+ * 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
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include "vgabios.h"
+
+
+int tim5690_int15_handler(struct eregs *regs);
+
+static rs690_vbios_regs vbios_regs_local;
+
+/* Initialization interrupt function */
+static void vbios_fun_init(rs690_vbios_regs *vbios_regs)
+{
+vbios_regs_local.int15_regs.fun00_panel_id = vbios_regs->int15_regs.fun00_panel_id;
+vbios_regs_local.int15_regs.fun05_tv_standard = vbios_regs->int15_regs.fun05_tv_standard;
+}
+/* BIOS int15 function */
+int

[coreboot] [PATCH] Superiotool: Add VT82C686

[Carl-Daniel Hailfinger]

Add VIA VT82C686A/VT82C686B support to superiotool.
The patch as-is will likely not detect the Super I/O due to missing PCI
functionality in superiotool, but you might get lucky.

This adds an additional requirement to superiotool: libpci. I have made
the PCI code conditional on PCI_SUPPORT for now.

Signed-off-by: Carl-Daniel Hailfinger 

Index: superiotool-vt82c686/via.c
===
--- superiotool-vt82c686/via.c  (Revision 0)
+++ superiotool-vt82c686/via.c  (Revision 0)
@@ -0,0 +1,112 @@
+/*
+ * This file is part of the superiotool project.
+ *
+ * Copyright (C) 2009 Carl-Daniel Hailfinger
+ *
+ * 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
+ */
+
+#include "superiotool.h"
+#ifdef PCI_SUPPORT
+#include 
+#endif
+
+#define DEVICE_ID_VT82C686_REG 0xe0
+
+#define DEVICE_REV_VT82C686_REG0xe1
+
+static const struct superio_registers reg_table[] = {
+   {0x3c, "VT82C686A/VT82C686B", {
+   {EOT}}},
+   {EOT}
+};
+
+#ifdef PCI_SUPPORT
+static uint8_t vt82c686_conf = 0;
+#endif
+
+static int enter_conf_mode_via_vt82c686(void)
+{
+#ifdef PCI_SUPPORT
+   struct pci_dev *dev;
+
+   dev = pci_dev_find(0x1106, 0x0686);
+   if (!dev) {
+   if (verbose)
+   printf("Associated PCI device not found.\n");
+   return 1;
+   }
+   vt82c686_conf = pci_read_byte(dev, 0x85);
+   if (verbose)
+   printf("Super I/O %sabled, Super I/O configuration %sabled",
+  (vt82c686_conf & (1 << 0)) ? "en" : "dis",
+  (vt82c686_conf & (1 << 1)) ? "en" : "dis");
+   /* If Super I/O is not enabled, skip it. */
+   if (!(vt82c686_conf & (1 << 0)))
+   return 1;
+   /* Enable Super I/O configuration mode. */
+   pci_write_byte(dev, 0x85, vt82c686_conf | (1 << 1));
+#endif
+   return 0;
+}
+
+static void exit_conf_mode_via_vt82c686(void)
+{
+#ifdef PCI_SUPPORT
+   struct pci_dev *dev;
+
+   dev = pci_dev_find(0x1106, 0x0686);
+   if (!dev) {
+   printf("Bug: PCI device 0x%04x:0x%04x not found during "
+  "shutdown. Please report to coreb...@coreboot.org\n");
+   return;
+   }
+   /* Restore (disable?) Super I/O configuration mode setting. */
+   pci_write_byte(dev, 0x85, vt82c686_conf);
+#endif
+}
+
+void probe_idregs_via(uint16_t port)
+{
+   uint16_t id;
+   uint8_t rev;
+
+   probing_for("VIA", "", port);
+
+   if (enter_conf_mode_via_vt82c686())
+   return;
+
+   id = regval(port, DEVICE_ID_VT82C686_REG);
+
+   rev = regval(port, DEVICE_REV_VT82C686_REG);
+
+   if (superio_unknown(reg_table, id)) {
+   if (verbose)
+   printf(NOTFOUND "id=0x%04x, rev=0x%02x\n", id, rev);
+   exit_conf_mode_via_vt82c686();
+   return;
+   }
+
+   printf("Found VIA %s (id=0x%04x, rev=0x%02x) at 0x%x\n",
+  get_superio_name(reg_table, id), id, rev, port);
+   chip_found = 1;
+
+   exit_conf_mode_via_vt82c686();
+}
+
+void print_via_chips(void)
+{
+   print_vendor_chips("VIA", reg_table);
+}
Index: superiotool-vt82c686/superiotool.h
===
--- superiotool-vt82c686/superiotool.h  (Revision 4988)
+++ superiotool-vt82c686/superiotool.h  (Arbeitskopie)
@@ -141,6 +141,10 @@
 void probe_idregs_winbond(uint16_t port);
 void print_winbond_chips(void);
 
+/* via.c */
+void probe_idregs_via(uint16_t port);
+void print_via_chips(void);
+
 /** Table of which config ports to probe for each Super I/O family. */
 static const struct {
void (*probe_idregs) (uint16_t port);
@@ -153,6 +157,7 @@
{probe_idregs_nsc,  {0x2e, 0x4e, 0x15c, EOT}},
{probe_idregs_smsc, {0x2e, 0x4e, 0x162e, 0x164e, 0x3f0, 0x370, 
EOT}},
{probe_idregs_winbond,  {0x2e, 0x4e, 0x3f0, 0x370, 0x250, EOT}},
+   {probe_idregs_via,  {0x3f0, EOT}},
 };
 
 /** Table of functions to print out supported Super I/O chips. */
@@ -165,6 +170,7 @@
{print_nsc_chips},
{print_smsc_chips},
{print_winbond_chips},
+   {print_via_chips},
 };
 
 #endif
Index: superiotool-vt82c686/Makefile
=

Re: [coreboot] [PATCH] bios_extract

[Rudolf Marek]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

> 1) there is a flag for uncompressed module 0x90 instead of 0x80 dunno why
> 2) if the module size in rom > 0x some bytes before the structure are used
> as size, the second number looks like crc maybe.

It turns out the extra header is there for all modules.

The unknown value is a simple 32bit sum over HEADER and BODY to sum up to 0 ;)

Dont know how it works for compressed modules nor how it works for modules with
not multiple of 4. It should be easy to get.

Rudolf



-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkswCrkACgkQ3J9wPJqZRNXA7QCePP/LvJYyhL/wDOlxdraOB8OU
GrMAoNfwNV3Tgp4Z2wja16q4YcVJHV1g
=svpM
-END PGP SIGNATURE-

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

Re: [coreboot] Problems porting H8dmr_fam10 to H8qme-2+

[Myles Watson]

On Mon, Dec 21, 2009 at 9:15 AM, Knut Kujat  wrote:

>  Myles Watson escribió:
>
>
>
> On Mon, Dec 21, 2009 at 3:27 AM, Knut Kujat  wrote:
>
>>
>> but I haven't changed anything but inserting some printk_spew into "void
>> dev_initialize(void)" to see where exactly jumps the exception out.
>>
> Did you try increasing the stack size?  When you inserted the printk
> statements, were there any warnings about format strings not matching the
> number of arguments?  Have you tried disabling the siblings yet?
>
> Thanks,
> Myles
>
>
> Hello,
>
> yes increasing stack size helped with the printks.
>
How big did you make it?  Try making it bigger until it doesn't make a
difference any more.


> And yes I tried to disable siblings by adding uses
> CONFIG_LOGICAL_PROCESSORS and default CONFIG_LOGICAL_PROCESSORS=0 to the
> Options.lb file but it complains at building time that this options is
> unkown so I uses LOGICAL_CPUS instead (is it the same?) without results.
>
You found the right one.  Sorry I steered you wrong.  All the processors get
initialized even with CONFIG_LOGICAL_CPUS=0?  That's not good.


> Now I know that the the exception comes up in the corresponding init(dev)
> for the PCI: 00:02.0 device. So I disabled PCI 2.0 in the device tree and it
> just doesn't has any effect even it tells me that PCI 2.0 enabled 0 at boot
> times, it stucks at the same place.
>
I don't think the init function is the problem.  It's more likely that
something is going wrong much earlier, and just catches up to you there.  I
would leave the device enabled.

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

Re: [coreboot] Problems porting H8dmr_fam10 to H8qme-2+

[Knut Kujat]

Myles Watson escribió:
>
>
> On Mon, Dec 21, 2009 at 3:27 AM, Knut Kujat  > wrote:
>
>
> but I haven't changed anything but inserting some printk_spew into
> "void dev_initialize(void)" to see where exactly jumps the
> exception out.
>
> Did you try increasing the stack size?  When you inserted the printk
> statements, were there any warnings about format strings not matching
> the number of arguments?  Have you tried disabling the siblings yet?
>
> Thanks,
> Myles  
>

Hello,

yes increasing stack size helped with the printks. And yes I tried to
disable siblings by adding uses CONFIG_LOGICAL_PROCESSORS and default
CONFIG_LOGICAL_PROCESSORS=0 to the Options.lb file but it complains at
building time that this options is unkown so I uses LOGICAL_CPUS instead
(is it the same?) without results.



CPU model: Quad-Core AMD Opteron(tm) Processor 8350
Setting up local apic...siblings = 03,  apic_id: 0x09 done.
CPU #14 initialized
CPU model: Quad-Core AMD Opteron(tm) Processor 8350
Waiting for 1 CPUS to stop
siblings = 03, CPU #9 initialized
All AP CPUs stopped
*** Debug: After init(dev);
PCI: 00:18.0 init
*** Debug: After init(dev);
PCI: 00:02.0 init
Unexpected Exception: 6 @ 10:00207fbd - Halting
Code: 0 eflags: 00010013
eax: 00226358 ebx: 00226358 ecx: 0021ea74 edx: 0001
edi: 0021ea74 esi: 0001 ebp: 0023fff4 esp: 0023ff50

Now I know that the the exception comes up in the corresponding
init(dev) for the PCI: 00:02.0 device. So I disabled PCI 2.0 in the
device tree and it just doesn't has any effect even it tells me that PCI
2.0 enabled 0 at boot times, it stucks at the same place.

Thanks,
Knut Kujat


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

Re: [coreboot] More SeaBIOS timings

[Tom Sylla]

This looks like it was an interesting task. I had some questions and
comments from previous fast-POST exercises:

On Mon, Dec 21, 2009 at 12:44 AM, Kevin O'Connor  wrote:
> * cpu appears to start running around 350ms

Do you have a scope at all?. The only way to know this number for sure
would be to put a scope on the reset wire and the rs-232 to see how
long the power sequence takes.

> * smbus power stabilizes around 400ms

I don't understand this. SMBus power is 3.3V, and I don't know why a
platform would be executing code before 3.3V is stable. The ATX is
turning on 3.3, 5, and 12 *first*, then the various regulators,
including the core regulator, come on after that. There should be
various hardware voltage monitors keeping things in reset until all
the voltages are up. Am I not understanding something? What exactly do
you mean by "smbus power stabilizes"?

> * I've commented out the calls to wbinvd() in coreboot's mtrr
>  cache_disable logic - those calls are expensive and the code seems
>  to work without it.

You removed *all* of them? You might just be getting lucky, that is a
bit dangerous.



Just a note: PCI has a specified time called Trhfa which is the time
from reset going high to the first allowable configuration access. It
is specified as 2^25 clocks, which is 1 second for 33MHz PCI and 500ms
for 66MHz PCI. You have to heed that if you want to generically
support random PCI plugin cards. If you are making fixed-configuration
concessions, then you can do it as fast as your particular hardware
allows.

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

Re: [coreboot] Problems porting H8dmr_fam10 to H8qme-2+

[Myles Watson]

On Mon, Dec 21, 2009 at 3:27 AM, Knut Kujat  wrote:

>
> but I haven't changed anything but inserting some printk_spew into "void
> dev_initialize(void)" to see where exactly jumps the exception out.
>
Did you try increasing the stack size?  When you inserted the printk
statements, were there any warnings about format strings not matching the
number of arguments?  Have you tried disabling the siblings yet?

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

[coreboot] [commit] r4988 - trunk/util/cbfstool

[svn]

Author: stepan
Date: 2009-12-21 16:09:01 +0100 (Mon, 21 Dec 2009)
New Revision: 4988

Modified:
   trunk/util/cbfstool/cbfstool.c
Log:
make strcmp happy by including string.h (trivial)

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



Modified: trunk/util/cbfstool/cbfstool.c
===
--- trunk/util/cbfstool/cbfstool.c  2009-12-21 13:50:37 UTC (rev 4987)
+++ trunk/util/cbfstool/cbfstool.c  2009-12-21 15:09:01 UTC (rev 4988)
@@ -20,6 +20,7 @@
 
 #include 
 #include 
+#include 
 #include "common.h"
 #include "cbfs.h"
 


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

Re: [coreboot] [PATCH]some more kconfig

[Myles Watson]

> Am 18.12.2009 19:50, schrieb Myles Watson:
> > As long as the user doesn't touch it, GENERATE_ was set by default as
> > long as the board has HAVE_* set.  What this patch did was make it so
> > that the user can't build without ACPI tables.  I don't think that is
> > what's wanted.  Now to remove the MP_TABLE, the user would have to
> > edit the Kconfig file.
> What's the right approach to them now? I somewhat missed the
> introduction of GENERATE and thus its rules, and just went with what
> gave me a pretty result in compareboard.

All the HAVE_* were supposed to be the same as newconfig, and the GENERATE_*
were supposed to default to the same as HAVE_*, but be ignored by the
comparison script, since they are not in newconfig.

Thanks,
Myles 


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

[coreboot] cloudbook done right

[ron minnich]

seems to me we could use the great work of kevin to do a boot-in-one-second
cloudbook: http://en.wikipedia.org/wiki/CloudBook to work with these guys:
http://www.zoho.com/

Of course, I'm still not so sure I want my stuff "in the cloud", but it's
certainly all the rage ...

Wouldn't it be neat if your notebook was like a cellphone: just open it and
it's there. Close it and it's off. And unlike a cell there's nothing to lose
if you get mad at it and throw it under the bus.

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

Re: [coreboot] #154: Flashing BIOSes from Fujitsu/Siemens is not supported

[coreboot]

#154: Flashing BIOSes from Fujitsu/Siemens is not supported
---+
   Reporter:  johannesoberm...@…   |  Owner:  carldani
   Type:  enhancement  | Status:  new 
   Priority:  trivial  |  Milestone:  
  Component:  flashrom |Version:  
   Keywords:   |   Dependencies:  
Patchstatus:  there is no patch|  
---+
Changes (by stepan):

  * priority:  major => trivial


Comment:

 They seem to deliver changesets rather than a complete image. I don't
 think we can do much about that unless Fujitsu opens up their data format.
 I suggest that you flash one machine with the DOS program, then read the
 image from flash with coreboot and flash the resulting image on the other
 machines of the same type.

-- 
Ticket URL: 
coreboot 

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

Re: [coreboot] More SeaBIOS timings

[ron minnich]

What's interesting about your 750ms is that it meets the requirement I saw
at a FOSDEM talk that the boot time needed for an auto computer was 800ms,
so that users could see blinky lights in less than one second. You're
showing very impressive performance here for an x86.

You've also raised the bar again for proprietary bios -- they've been pretty
boastful lately of hitting the 5 second or so mark, and you're showing we're
still way faster. Plus, most of the time, we've found the proprietary BIOS
vendors are being very creative in their timing claims :-)

Really great work!

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

[coreboot] [commit] r4987 - in trunk: src/arch/i386 util/cbfstool

[svn]

Author: oxygene
Date: 2009-12-21 14:50:37 +0100 (Mon, 21 Dec 2009)
New Revision: 4987

Modified:
   trunk/src/arch/i386/Makefile.inc
   trunk/util/cbfstool/cbfstool.c
Log:
Allow user to specify the size of a newly created cbfs image
to be stated in kilobytes or megabytes. Usage is
cbfstool coreboot.rom create 1048576 coreboot.bootblock
cbfstool coreboot.rom create 1024k coreboot.bootblock
cbfstool coreboot.rom create 1m coreboot.bootblock
to get an 1048576 bytes = 1024kb = 1mb image.

Kconfig also uses this instead of calculating bytes from kilobytes itself.

Signed-off-by: Patrick Georgi 
Acked-by: Peter Stuge 


Modified: trunk/src/arch/i386/Makefile.inc
===
--- trunk/src/arch/i386/Makefile.inc2009-12-21 12:32:29 UTC (rev 4986)
+++ trunk/src/arch/i386/Makefile.inc2009-12-21 13:50:37 UTC (rev 4987)
@@ -14,7 +14,7 @@
 
 $(obj)/coreboot.rom: $(obj)/coreboot.bootblock $(obj)/coreboot_ram $(CBFSTOOL)
rm -f $@
-   $(CBFSTOOL) $@ create $(shell expr 1024 \* 
$(CONFIG_COREBOOT_ROMSIZE_KB)) $(obj)/coreboot.bootblock
+   $(CBFSTOOL) $@ create $(CONFIG_COREBOOT_ROMSIZE_KB)K 
$(obj)/coreboot.bootblock
if [ -f fallback/coreboot_apc ]; \
then \
$(CBFSTOOL) $@ add-stage fallback/coreboot_apc 
fallback/coreboot_apc $(CBFS_COMPRESS_FLAG); \

Modified: trunk/util/cbfstool/cbfstool.c
===
--- trunk/util/cbfstool/cbfstool.c  2009-12-21 12:32:29 UTC (rev 4986)
+++ trunk/util/cbfstool/cbfstool.c  2009-12-21 13:50:37 UTC (rev 4987)
@@ -192,7 +192,14 @@
return 1;
}
 
-   uint32_t size = strtoul(argv[3], NULL, 0);
+   char* suffix;
+   uint32_t size = strtoul(argv[3], &suffix, 0);
+   if (tolower(suffix[0])=='k') {
+   size *= 1024;
+   }
+   if (tolower(suffix[0])=='m') {
+   size *= 1024 * 1024;
+   }
char *bootblock = argv[4];
uint32_t align = 0;
 


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

Re: [coreboot] [PATCH]Enable suffixes for cbfstool create size argument

[Peter Stuge]

Patrick Georgi wrote:
> attached patch allows to specify the size of a newly created cbfs image
> to be stated in kilobytes or megabytes. Usage is
> cbfstool coreboot.rom create 1048576 coreboot.bootblock
> cbfstool coreboot.rom create 1024k coreboot.bootblock
> cbfstool coreboot.rom create 1m coreboot.bootblock
> to get an 1048576 bytes = 1024kb = 1mb image.
> 
> Kconfig also uses this instead of calculating bytes from kilobytes itself.
> 
> Signed-off-by: Patrick Georgi 

Acked-by: Peter Stuge 

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

[coreboot] [PATCH]Enable suffixes for cbfstool create size argument

[Patrick Georgi]

Hi,

attached patch allows to specify the size of a newly created cbfs image
to be stated in kilobytes or megabytes. Usage is
cbfstool coreboot.rom create 1048576 coreboot.bootblock
cbfstool coreboot.rom create 1024k coreboot.bootblock
cbfstool coreboot.rom create 1m coreboot.bootblock
to get an 1048576 bytes = 1024kb = 1mb image.

Kconfig also uses this instead of calculating bytes from kilobytes itself.

Signed-off-by: Patrick Georgi 
Index: src/arch/i386/Makefile.inc
===
--- src/arch/i386/Makefile.inc  (revision 4985)
+++ src/arch/i386/Makefile.inc  (working copy)
@@ -14,7 +14,7 @@
 
 $(obj)/coreboot.rom: $(obj)/coreboot.bootblock $(obj)/coreboot_ram $(CBFSTOOL)
rm -f $@
-   $(CBFSTOOL) $@ create $(shell expr 1024 \* 
$(CONFIG_COREBOOT_ROMSIZE_KB)) $(obj)/coreboot.bootblock
+   $(CBFSTOOL) $@ create $(CONFIG_COREBOOT_ROMSIZE_KB)K 
$(obj)/coreboot.bootblock
if [ -f fallback/coreboot_apc ]; \
then \
$(CBFSTOOL) $@ add-stage fallback/coreboot_apc 
fallback/coreboot_apc $(CBFS_COMPRESS_FLAG); \
Index: util/cbfstool/cbfstool.c
===
--- util/cbfstool/cbfstool.c(revision 4985)
+++ util/cbfstool/cbfstool.c(working copy)
@@ -192,7 +192,14 @@
return 1;
}
 
-   uint32_t size = strtoul(argv[3], NULL, 0);
+   char* suffix;
+   uint32_t size = strtoul(argv[3], &suffix, 0);
+   if (tolower(suffix[0])=='k') {
+   size *= 1024;
+   }
+   if (tolower(suffix[0])=='m') {
+   size *= 1024 * 1024;
+   }
char *bootblock = argv[4];
uint32_t align = 0;
 
-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

[coreboot] [commit] r4986 - trunk/src/cpu/amd/model_gx2

[svn]

Author: oxygene
Date: 2009-12-21 13:32:29 +0100 (Mon, 21 Dec 2009)
New Revision: 4986

Modified:
   trunk/src/cpu/amd/model_gx2/vsmsetup.c
Log:
Make coreboot load VSA from CBFS on amd/gx2.

You have to convert the VSA bios image to ELF using the following
commands (assuming i386/32bit binutils, if in doubt, use crossgcc's
i386-elf-* tools):

objcopy --set-start 0x20 --adjust-vma 0x6 -I binary -O elf32-i386 -B i386 
vsa.binary vsa.o
ld -e 0x60020 --section-start .data=0x6 vsa.o -o vsa.elf

Then, after build, use
cbfstool coreboot.rom add-stage vsa.elf vsa l
to add it to the image.


Signed-off-by: Patrick Georgi 
Acked-by: Peter Stuge 


Modified: trunk/src/cpu/amd/model_gx2/vsmsetup.c
===
--- trunk/src/cpu/amd/model_gx2/vsmsetup.c  2009-12-18 16:43:30 UTC (rev 
4985)
+++ trunk/src/cpu/amd/model_gx2/vsmsetup.c  2009-12-21 12:32:29 UTC (rev 
4986)
@@ -33,6 +33,7 @@
 #include 
 #include 
 #include 
+#include 
 
 u32 VSA_vrRead(u16 classIndex);
 void do_vsmbios(void);
@@ -190,18 +191,11 @@
/* Clear VSM BIOS data area. */
for (i = 0x400; i < 0x500; i++)
*(volatile unsigned char *)i = 0;
-   /* set up cbfs and find the vsa file -- later */
-/*
-   init_archive(&archive);
+   if ((unsigned int)cbfs_load_stage("vsa") != VSA2_ENTRY_POINT) {
+   printk_err("do_vsmbios: Failed to load VSA.\n");
+   }
+   buf = VSA2_BUFFER;
 
-   if (find_file(&archive, "blob/vsa", &file))
-   die("FATAL: NO VSA found!\n");
-
-   if (process_file(&file, (void *)VSA2_BUFFER))
-   die("FATAL: Processing /blob/vsa failed\n");
- */
-
-   buf = (unsigned char *)VSA2_BUFFER;
printk_debug("buf[0x20] signature is %x:%x:%x:%x\n",
   buf[0x20], buf[0x21], buf[0x22], buf[0x23]);
/* Check for POST code at start of vsainit.bin. If you don't see it,


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

Re: [coreboot] [PATCH]Load VSA from CBFS on amd/gx2

[Peter Stuge]

Patrick Georgi wrote:
> attached patch makes coreboot load VSA from CBFS on amd/gx2.
> 
> Signed-off-by: Patrick Georgi 

Acked-by: Peter Stuge 

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

[coreboot] [PATCH]Load VSA from CBFS on amd/gx2

[Patrick Georgi]

Hi,

attached patch makes coreboot load VSA from CBFS on amd/gx2. It's very
similar to the recent change to amd/lx (3 weeks ago), in fact, it's a
copy&paste from there.
Build tested, but I don't have the hardware around to test operation,
but the lx variant was tested.

Most notably, the gx2 code was definitely broken before with some
commented out coreboot-v3 code to load the image to the right place, so
no loading took place at all.

Signed-off-by: Patrick Georgi 

Regards,
Patrick Georgi
Index: src/cpu/amd/model_gx2/vsmsetup.c
===
--- src/cpu/amd/model_gx2/vsmsetup.c(revision 4985)
+++ src/cpu/amd/model_gx2/vsmsetup.c(working copy)
@@ -33,6 +33,7 @@
 #include 
 #include 
 #include 
+#include 
 
 u32 VSA_vrRead(u16 classIndex);
 void do_vsmbios(void);
@@ -190,18 +191,11 @@
/* Clear VSM BIOS data area. */
for (i = 0x400; i < 0x500; i++)
*(volatile unsigned char *)i = 0;
-   /* set up cbfs and find the vsa file -- later */
-/*
-   init_archive(&archive);
+   if ((unsigned int)cbfs_load_stage("vsa") != VSA2_ENTRY_POINT) {
+   printk_err("do_vsmbios: Failed to load VSA.\n");
+   }
+   buf = VSA2_BUFFER;
 
-   if (find_file(&archive, "blob/vsa", &file))
-   die("FATAL: NO VSA found!\n");
-
-   if (process_file(&file, (void *)VSA2_BUFFER))
-   die("FATAL: Processing /blob/vsa failed\n");
- */
-
-   buf = (unsigned char *)VSA2_BUFFER;
printk_debug("buf[0x20] signature is %x:%x:%x:%x\n",
   buf[0x20], buf[0x21], buf[0x22], buf[0x23]);
/* Check for POST code at start of vsainit.bin. If you don't see it,
-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Problems porting H8dmr_fam10 to H8qme-2+

[Knut Kujat]

Myles Watson escribió:
>
>
> On Fri, Dec 18, 2009 at 8:41 AM, Knut Kujat  > wrote:
>
>> Never mind about the memory corruption.  PNP: 002e.3 has some
>> resources that aren't "fixed", so the allocator is trying to
>> allocate them.  In the SuperIO code where those resources are
>> declared, set the flags to match the other resources.
> Problem solved I killed it :) means I disabled it in the device
> tree. The H9DMR board has two serials and my board H8QME has only
> one.
>
> Great.
>  
>
> Now, I've got till the MTRR initialization and here is my reward:
>
> POST: 0x93
> Setting up local apic... apic_id: 0x0a done.
> POST: 0x9b
> CPU model: Quad-Core AMD Opteron(tm) Processor 8350
> siblings = 03, CPU #10 initialized
> All AP CPUs stopped
> PCI: 00:18.0 init
> PCI: 00:02.0 init
> Unexpected Exception: 6 @ 10:00207ff1 - Halting
> Code: 0 eflags: 00010046
> eax:  ebx: 00226358 ecx: 0021ea74 edx: 0001
> edi: 0021ea74 esi: 0001 ebp: 0023fff4 esp: 0023ff50
> POST: 0xff
>
> the strange thing is that it seems to work for like 11 other
> cores. And this log is from my last try but before it always
> starts rebooting with SOFT RESET after:
>
>
> Somebody else will probably know how to help you better.  The first
> thing I would do is disable siblings (LOGICAL_PROCESSORS=0) and see if
> you can get past it or not.
>
> Thanks,
> Myles
>
Hello,

I now getting this:
Setting fixed MTRRs(0-88) type: UC
After Startup.
Initializing CPU #0
DONE fixed MTRRs
C


INIT detected from  --- { APICID = 00 NODEID = 00 COREID = 00} ---

Issuing SOFT_RESET...


coreboot-2.0.0-r_Fallback lun dic 21 11:02:38 CET 2009 starting...

BSP Family_Model: 00100f22
*sysinfo range: [000cc000,000cdfa0]
bsp_apicid = 00
cpu_init_detectedx = 
microcode: equivalent rev id  = 0x1022, current patch id = 0x
microcode: rev id (1062) does not match this patch.
microcode: Not updated! Fix microcode_updates[]
cpuSetAMDMSR  done
...blablabla

but I haven't changed anything but inserting some printk_spew into "void
dev_initialize(void)" to see where exactly jumps the exception out.

I'm confused :(.

THX,
Knut Kujat.
-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot