Re: [coreboot] Hardware damaged?

[mark]

> Is there any output on the serial console with Coreboot?  There should
> have been a lot of it the first time when you got to VGA init.

The problem is, not even the monitor turns on, which indicates that there is 
no VGA init or VGA signal, using both chips.
I'll check with a multimeter if there is any current on the pins.

> has a pin of the socket or the flash been bent?

some pins of the original chip have been slightly bent, but I fixed them with a 
pliers before inserting. Unfortunately my plcc32 extractor is too big for that 
board, so the first time I used a screwdriver to extract the chip and after 
that I used some filament underneath the chip to plug it out.

I did not check the serial output yet; the only lifesign is the onboard 
network chip which establishes a link to my switch. But my guess is, that 
board is beyond repair, as the original bios doesn't work anymore, there is no 
beep signal, and no VGA signal.
If there is anything new, I'll let you know. Thanks for your help so far.

Mark


signature.asc
Description: This is a digitally signed message part.
-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Hardware damaged?

[Peter Stuge]

mark wrote:
> the first time I used a screwdriver to extract the chip and after
> that I used some filament underneath the chip to plug it out.

How thick? Are you 100% sure that the chip actually has good contact
in the socket? Maybe try the factory BIOS without that filament once.


> the only lifesign is the onboard network chip which establishes a
> link to my switch.

That's completely independent of coreboot or BIOS.


//Peter


pgpUyfOFmn2d4.pgp
Description: PGP signature
-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] H8QME-2+ boot problems on different machines.

[Knut Kujat]

Hi,
I finally got it working, but I don't like my solution!

I noticed that after setup_mb_resource_map();  the board hang at outb
and inl instructions. So I commented it out to see how far this will
bring me. For my surprise the board booted right into Linux without
further problems. Now my questions are:

- I now know that my resource map must be some kind of faulty. But why
does it work on one CPU and doesn't on another, complete identical, one?
- How do i manage to correct my resource map? Or how do I create a good
resource map?
- Since it seems to boot fine without resource map. Do I really need one?
- And the last one, If I don't setup the res. map, who does it?

Thanks and sorry for the whole bunch of questions,
Knut Kujat.


Knut Kujat escribió:
> Marc Jones escribió:
>   
>> On Sun, May 2, 2010 at 4:59 PM, Rudolf Marek  wrote:
>>   
>> 
>>> -BEGIN PGP SIGNED MESSAGE-
>>> Hash: SHA1
>>>
>>> Hi,
>>>
>>> There is a plenty of bugs as in all modern CPUs ;)
>>>
>>> http://support.amd.com/us/Processor_TechDocs/41322.pdf
>>>
>>> Quick look to coreboot shows they are not handled?
>>>
>>> Some are easy to fix just to set some MSR, some are microcode fixes.
>>>
>>> 
>>>   
>> That Fam10 bugs should be handled in cpuSetAMDMSR as well as the microcode.
>>
>> If it is a race condition, it should pass CONFIG_LOGICAL_CPUS = 0.
>>
>> Marc
>>
>>   
>> 
> Hi,
>
> thx for your comments.
>
> I already set Config_Logical_CPUS = 0 and set physical and logical CPUs
> to 1. This gets me a little further but still hangs before warm reset.
> As I already set I have the exact same problem as Ward reported some
> time ago.
>
> Thanks,
> Knut Kujat.
>
>   


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

[coreboot] Filo and ext4

[Joop Boonen]

All,

I have a question.
Will FILO support ext4 in the future?

Regards,

Joop.


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

[coreboot] #160: Build system: There's no convincing CFLAGS management for util/*

[coreboot]

#160: Build system: There's no convincing CFLAGS management for util/*
-+--
Reporter:  oxygene   | Owner:  oxygene  
Type:  task  |Status:  new  
Priority:  major | Milestone:   
   Component:  coreboot  |  Keywords:   
Dependencies:|   Patchstatus:  there is no patch
-+--
 Right now, all utils build with -Iutil/kconfig. We're only lucky that
 there's no file name overlap.

 This should be cleaned up.

-- 
Ticket URL: 
coreboot 

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

Re: [coreboot] [PATCH]Refactor sconfig

[Peter Stuge]

Patrick Georgi wrote:
> Signed-off-by: Patrick Georgi 

Acked-by: Peter Stuge 

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

[coreboot] [PATCH]Make parser state local to parser

[Patrick Georgi]

Hi,

attached patch makes cur_parent and cur_bus, two variables that track
internal parser state, local to the parser. Before, the device tree
handling had to use them, too - their values are now passed as arguments
instead.

Tested to give identical results for all boards.

Signed-off-by: Patrick Georgi 
Index: sconfig.y
===
--- sconfig.y   (Revision 5523)
+++ sconfig.y   (Arbeitskopie)
@@ -21,7 +21,7 @@
 
 #include "sconfig.h"
 
-struct device *cur_parent, *cur_bus;
+static struct device *cur_parent, *cur_bus;
 
 %}
 %union {
@@ -31,7 +31,7 @@
 }
 %token CHIP DEVICE REGISTER BOOL BUS RESOURCE END EQUALS HEX STRING PCI PNP 
I2C APIC APIC_CLUSTER PCI_DOMAIN IRQ DRQ IO NUMBER
 %%
-devtree: devchip { postprocess_devtree(); } ;
+devtree: { cur_parent = cur_bus = head; } devchip { postprocess_devtree(); } ;
 
 devchip: chip | device ;
 
@@ -40,7 +40,7 @@
 devicesorresources: devicesorresources devchip | devicesorresources resource | 
;
 
 chip: CHIP STRING /* == path */ {
-   $$ = new_chip($2);
+   $$ = new_chip(cur_parent, cur_bus, $2);
cur_parent = $$;
 }
devices END {
@@ -50,7 +50,7 @@
 };
 
 device: DEVICE BUS NUMBER /* == devnum */ BOOL {
-   $$ = new_device($2, $3, $4);
+   $$ = new_device(cur_parent, cur_bus, $2, $3, 
$4);
cur_parent = $$;
cur_bus = $$;
 }
@@ -62,9 +62,9 @@
 };
 
 resource: RESOURCE NUMBER /* == resnum */ EQUALS NUMBER /* == resval */
-   { add_resource($1, strtol($2, NULL, 0), 
strtol($4, NULL, 0)); } ;
+   { add_resource(cur_parent, $1, strtol($2, NULL, 0), 
strtol($4, NULL, 0)); } ;
 
 registers: REGISTER STRING /* == regname */ EQUALS STRING /* == regval */
-   { add_register($2, $4); } ;
+   { add_register(cur_parent, $2, $4); } ;
 
 %%
Index: main.c
===
--- main.c  (Revision 5523)
+++ main.c  (Arbeitskopie)
@@ -51,12 +51,12 @@
.enabled = 1
 };
 
-static struct device *new_dev() {
+static struct device *new_dev(struct device *parent, struct device *bus) {
struct device *dev = malloc(sizeof(struct device));
memset(dev, 0, sizeof(struct device));
dev->id = ++devcount;
-   dev->parent = cur_parent;
-   dev->bus = cur_bus;
+   dev->parent = parent;
+   dev->bus = bus;
head->next = dev;
head = dev;
return dev;
@@ -110,8 +110,8 @@
}
 }
 
-struct device *new_chip(char *path) {
-   struct device *new_chip = new_dev();
+struct device *new_chip(struct device *parent, struct device *bus, char *path) 
{
+   struct device *new_chip = new_dev(parent, bus);
new_chip->chiph_exists = 1;
new_chip->name = path;
new_chip->name_underscore = strdup(new_chip->name);
@@ -129,13 +129,13 @@
if ((stat(chip_h, &st) == -1) && (errno == ENOENT))
new_chip->chiph_exists = 0;
 
-   if (cur_parent->latestchild) {
-   cur_parent->latestchild->next_sibling = new_chip;
-   cur_parent->latestchild->sibling = new_chip;
+   if (parent->latestchild) {
+   parent->latestchild->next_sibling = new_chip;
+   parent->latestchild->sibling = new_chip;
}
-   cur_parent->latestchild = new_chip;
-   if (!cur_parent->children)
-   cur_parent->children = new_chip;
+   parent->latestchild = new_chip;
+   if (!parent->children)
+   parent->children = new_chip;
return new_chip;
 }
 
@@ -162,8 +162,8 @@
}
 }
 
-struct device *new_device(const int bus, const char *devnum, int enabled) {
-   struct device *new_d = new_dev();
+struct device *new_device(struct device *parent, struct device *busdev, const 
int bus, const char *devnum, int enabled) {
+   struct device *new_d = new_dev(parent, busdev);
new_d->bustype = bus;
 
char *tmp;
@@ -181,13 +181,13 @@
new_d->enabled = enabled;
new_d->chip = new_d->parent->chip;
 
-   if (cur_parent->latestchild) {
-   cur_parent->latestchild->next_sibling = new_d;
-   cur_parent->latestchild->sibling = new_d;
+   if (parent->latestchild) {
+   parent->latestchild->next_sibling = new_d;
+   parent->latestchild->sibling = new_d;
}
-   cur_parent->latestchild = new_d;
-   if (!cur_parent->children)
-   cur_parent->children = new_d;
+   parent->latestchild = new_d;
+   if (!parent->children)
+   parent->children = new_d;
 
lastdev->nextdev = new_d;
lastdev = new_d;
@@ -235,29 +235,29 @@
}
 }
 
-void add_resource(int type, int index, int base) {
+void add_resource(struct device *dev, int type, int index, int base) {
struct resource *r = malloc(sizeof(struct resource));
memset (r, 0, sizeof(struct resource));
r->type = type;
r->index = index;
r->base = base;

Re: [coreboot] [PATCH]Make parser state local to parser

[Stefan Reinauer]

On 5/5/10 1:40 PM, Patrick Georgi wrote:
> Hi,
>
> attached patch makes cur_parent and cur_bus, two variables that track
> internal parser state, local to the parser. Before, the device tree
> handling had to use them, too - their values are now passed as arguments
> instead.
>
> Tested to give identical results for all boards.
>
> Signed-off-by: Patrick Georgi 
>   
Acked-by: Stefan Reinauer 

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

[coreboot] [commit] r5524 - trunk/util/sconfig

[repository service]

Author: oxygene
Date: Wed May  5 14:05:25 2010
New Revision: 5524
URL: https://tracker.coreboot.org/trac/coreboot/changeset/5524

Log:
sconfig: Make cur_bus and cur_parent local to the parser.
Instead of accessing them globally, pass them as arguments where necessary.

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

Modified:
   trunk/util/sconfig/main.c
   trunk/util/sconfig/sconfig.h
   trunk/util/sconfig/sconfig.tab.c_shipped
   trunk/util/sconfig/sconfig.y

Modified: trunk/util/sconfig/main.c
==
--- trunk/util/sconfig/main.c   Wed May  5 13:19:50 2010(r5523)
+++ trunk/util/sconfig/main.c   Wed May  5 14:05:25 2010(r5524)
@@ -51,12 +51,12 @@
.enabled = 1
 };
 
-static struct device *new_dev() {
+static struct device *new_dev(struct device *parent, struct device *bus) {
struct device *dev = malloc(sizeof(struct device));
memset(dev, 0, sizeof(struct device));
dev->id = ++devcount;
-   dev->parent = cur_parent;
-   dev->bus = cur_bus;
+   dev->parent = parent;
+   dev->bus = bus;
head->next = dev;
head = dev;
return dev;
@@ -110,8 +110,8 @@
}
 }
 
-struct device *new_chip(char *path) {
-   struct device *new_chip = new_dev();
+struct device *new_chip(struct device *parent, struct device *bus, char *path) 
{
+   struct device *new_chip = new_dev(parent, bus);
new_chip->chiph_exists = 1;
new_chip->name = path;
new_chip->name_underscore = strdup(new_chip->name);
@@ -129,13 +129,13 @@
if ((stat(chip_h, &st) == -1) && (errno == ENOENT))
new_chip->chiph_exists = 0;
 
-   if (cur_parent->latestchild) {
-   cur_parent->latestchild->next_sibling = new_chip;
-   cur_parent->latestchild->sibling = new_chip;
-   }
-   cur_parent->latestchild = new_chip;
-   if (!cur_parent->children)
-   cur_parent->children = new_chip;
+   if (parent->latestchild) {
+   parent->latestchild->next_sibling = new_chip;
+   parent->latestchild->sibling = new_chip;
+   }
+   parent->latestchild = new_chip;
+   if (!parent->children)
+   parent->children = new_chip;
return new_chip;
 }
 
@@ -162,8 +162,8 @@
}
 }
 
-struct device *new_device(const int bus, const char *devnum, int enabled) {
-   struct device *new_d = new_dev();
+struct device *new_device(struct device *parent, struct device *busdev, const 
int bus, const char *devnum, int enabled) {
+   struct device *new_d = new_dev(parent, busdev);
new_d->bustype = bus;
 
char *tmp;
@@ -181,13 +181,13 @@
new_d->enabled = enabled;
new_d->chip = new_d->parent->chip;
 
-   if (cur_parent->latestchild) {
-   cur_parent->latestchild->next_sibling = new_d;
-   cur_parent->latestchild->sibling = new_d;
-   }
-   cur_parent->latestchild = new_d;
-   if (!cur_parent->children)
-   cur_parent->children = new_d;
+   if (parent->latestchild) {
+   parent->latestchild->next_sibling = new_d;
+   parent->latestchild->sibling = new_d;
+   }
+   parent->latestchild = new_d;
+   if (!parent->children)
+   parent->children = new_d;
 
lastdev->nextdev = new_d;
lastdev = new_d;
@@ -235,29 +235,29 @@
}
 }
 
-void add_resource(int type, int index, int base) {
+void add_resource(struct device *dev, int type, int index, int base) {
struct resource *r = malloc(sizeof(struct resource));
memset (r, 0, sizeof(struct resource));
r->type = type;
r->index = index;
r->base = base;
-   if (cur_parent->res) {
-   struct resource *head = cur_parent->res;
+   if (dev->res) {
+   struct resource *head = dev->res;
while (head->next) head = head->next;
head->next = r;
} else {
-   cur_parent->res = r;
+   dev->res = r;
}
-   cur_parent->rescnt++;
+   dev->rescnt++;
 }
 
-void add_register(char *name, char *val) {
+void add_register(struct device *dev, char *name, char *val) {
struct reg *r = malloc(sizeof(struct reg));
memset (r, 0, sizeof(struct reg));
r->key = name;
r->value = val;
-   if (cur_parent->reg) {
-   struct reg *head = cur_parent->reg;
+   if (dev->reg) {
+   struct reg *head = dev->reg;
// sorting to be equal to sconfig's behaviour
int sort = strcmp(r->key, head->key);
if (sort == 0) {
@@ -266,14 +266,14 @@
}
if (sort<0) {
r->next = head;
-   cur_parent->reg = r;
+   dev->reg = r;
} else {
while ((head->

Re: [coreboot] #18: autoprobe apic cluster and application processors on K8 systems

[coreboot]

#18: autoprobe apic cluster and application processors on K8 systems
-+--
Reporter:  stepan| Owner:  oxygene  
Type:  defect|Status:  new  
Priority:  major | Milestone:   
   Component:  coreboot  |  Keywords:  K8, cleanup  
Dependencies:|   Patchstatus:  there is no patch
-+--
Changes (by oxygene):

  * owner:  somebody => oxygene
  * patchstatus:  => there is no patch


-- 
Ticket URL: 
coreboot 

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

[coreboot] [PATCH]Improve sconfig parser

[Patrick Georgi]

Hi,

attached patch improves the sconfig parser:
- The device tree must start with a chip (not a device)
- It's more clearly visible at which places chip, device, register and
resource can be used.

Again, this gives byte-identical results to older sconfig.

Signed-off-by: Patrick Georgi 
Index: util/sconfig/sconfig.y
===
--- util/sconfig/sconfig.y  (Revision 5524)
+++ util/sconfig/sconfig.y  (Arbeitskopie)
@@ -31,19 +31,17 @@
 }
 %token CHIP DEVICE REGISTER BOOL BUS RESOURCE END EQUALS HEX STRING PCI PNP 
I2C APIC APIC_CLUSTER PCI_DOMAIN IRQ DRQ IO NUMBER
 %%
-devtree: { cur_parent = cur_bus = head; } devchip { postprocess_devtree(); } ;
+devtree: { cur_parent = cur_bus = head; } chip { postprocess_devtree(); } ;
 
-devchip: chip | device ;
+chipchildren: chipchildren device | chipchildren chip | chipchildren registers 
| /* empty */ ;
 
-devices: devices devchip | devices registers | ;
+devicechildren: devicechildren device | devicechildren chip | devicechildren 
resource | /* empty */ ;
 
-devicesorresources: devicesorresources devchip | devicesorresources resource | 
;
-
 chip: CHIP STRING /* == path */ {
$$ = new_chip(cur_parent, cur_bus, $2);
cur_parent = $$;
 }
-   devices END {
+   chipchildren END {
cur_parent = $3->parent;
fold_in($3);
add_header($3);
@@ -54,7 +52,7 @@
cur_parent = $$;
cur_bus = $$;
 }
-   devicesorresources END {
+   devicechildren END {
cur_parent = $5->parent;
cur_bus = $5->bus;
fold_in($5);
Index: util/sconfig/sconfig.tab.c_shipped
===
--- util/sconfig/sconfig.tab.c_shipped  (Revision 5524)
+++ util/sconfig/sconfig.tab.c_shipped  (Arbeitskopie)
@@ -380,12 +380,12 @@
 /* YYFINAL -- State number of the termination state.  */
 #define YYFINAL  3
 /* YYLAST -- Last index in YYTABLE.  */
-#define YYLAST   22
+#define YYLAST   24
 
 /* YYNTOKENS -- Number of terminals.  */
 #define YYNTOKENS  23
 /* YYNNTS -- Number of nonterminals.  */
-#define YYNNTS  12
+#define YYNNTS  11
 /* YYNRULES -- Number of rules.  */
 #define YYNRULES  17
 /* YYNRULES -- Number of states.  */
@@ -436,26 +436,26 @@
YYRHS.  */
 static const yytype_uint8 yyprhs[] =
 {
-   0, 0, 3, 4, 7, 9,11,14,17,18,
-  21,24,25,26,32,33,41,46
+   0, 0, 3, 4, 7,10,13,16,17,20,
+  23,26,27,28,34,35,43,48
 };
 
 /* YYRHS -- A `-1'-separated list of the rules' RHS.  */
 static const yytype_int8 yyrhs[] =
 {
-  24, 0,-1,-1,25,26,-1,29,-1,31,
-  -1,27,26,-1,27,34,-1,-1,28,26,
-  -1,28,33,-1,-1,-1, 3,12,30,27,
-   9,-1,-1, 4, 7,22, 6,32,28, 9,
-  -1, 8,22,10,22,-1, 5,12,10,12,
-  -1
+  24, 0,-1,-1,25,28,-1,26,30,-1,
+  26,28,-1,26,33,-1,-1,27,30,-1,
+  27,28,-1,27,32,-1,-1,-1, 3,12,
+  29,26, 9,-1,-1, 4, 7,22, 6,31,
+  27, 9,-1, 8,22,10,22,-1, 5,12,
+  10,12,-1
 };
 
 /* YYRLINE[YYN] -- source line where rule number YYN was defined.  */
 static const yytype_uint8 yyrline[] =
 {
-   0,34,34,34,36,36,38,38,38,40,
-  40,40,42,42,52,52,64,67
+   0,34,34,34,36,36,36,36,38,38,
+  38,38,40,40,50,50,62,65
 };
 #endif
 
@@ -467,8 +467,8 @@
   "$end", "error", "$undefined", "CHIP", "DEVICE", "REGISTER", "BOOL",
   "BUS", "RESOURCE", "END", "EQUALS", "HEX", "STRING", "PCI", "PNP", "I2C",
   "APIC", "APIC_CLUSTER", "PCI_DOMAIN", "IRQ", "DRQ", "IO", "NUMBER",
-  "$accept", "devtree", "$...@1", "devchip", "devices", "devicesorresources",
-  "chip", "@2", "device", "@3", "resource", "registers", 0
+  "$accept", "devtree", "$...@1", "chipchildren", "devicechildren", "chip",
+  "@2", "device", "@3", "resource", "registers", 0
 };
 #endif
 
@@ -486,14 +486,14 @@
 /* YYR1[YYN] -- Symbol number of symbol that rule YYN derives.  */
 static const yytype_uint8 yyr1[] =
 {
-   0,23,25,24,26,26,27,27,27,28,
-  28,28,30,29,32,31,33,34
+   0,23,25,24,26,26,26,26,27,27,
+  27,27,29,28,31,30,32,33
 };
 
 /* YYR2[YYN] -- Number of symbols composing right hand side of rule YYN.  */
 static const yytype_uint8 yyr2[] =
 {
-   0, 2, 0, 2, 1, 1, 2, 2, 0, 2,
+ 

Re: [coreboot] [PATCH]Improve sconfig parser

[Stefan Reinauer]

On 5/5/10 2:28 PM, Patrick Georgi wrote:
> Hi,
>
> attached patch improves the sconfig parser:
> - The device tree must start with a chip (not a device)
> - It's more clearly visible at which places chip, device, register and
> resource can be used.
>
> Again, this gives byte-identical results to older sconfig.
>
> Signed-off-by: Patrick Georgi 
>   

Acked-by: Stefan Reinauer 


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

Re: [coreboot] [PATCH]rename apic to lapic in device trees

[Stefan Reinauer]

On 5/5/10 2:50 PM, Patrick Georgi wrote:
> Hi,
>
> attached patch renames "apic" and "apic_cluster" to "lapic" and
> "lapic_cluster". This is in preparation of adding ioapics to device
> trees, and it also makes clearer what is covered by those devices.
>
>
> Signed-off-by: Patrick Georgi 
>   

Acked-by: Stefan Reinauer 


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

Re: [coreboot] [PATCH]Improve sconfig parser

[Peter Stuge]

Patrick Georgi wrote:
> Again, this gives byte-identical results to older sconfig.
> 
> Signed-off-by: Patrick Georgi 

Acked-by: Peter Stuge 

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

Re: [coreboot] [PATCH]rename apic to lapic in device trees

[Peter Stuge]

Patrick Georgi wrote:
> attached patch renames "apic" and "apic_cluster" to "lapic" and
> "lapic_cluster". This is in preparation of adding ioapics to device
> trees, and it also makes clearer what is covered by those devices.

Nice!


> Signed-off-by: Patrick Georgi 

Acked-by: Peter Stuge 

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

[coreboot] [commit] r5526 - trunk/util/sconfig

[repository service]

Author: oxygene
Date: Wed May  5 15:13:47 2010
New Revision: 5526
URL: https://tracker.coreboot.org/trac/coreboot/changeset/5526

Log:
Improve the sconfig parser:
- The device tree must start with a chip (not a device)
- It's more clearly visible at which places chip, device, register and resource 
can be used.

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

Modified:
   trunk/util/sconfig/sconfig.tab.c_shipped
   trunk/util/sconfig/sconfig.y

Modified: trunk/util/sconfig/sconfig.tab.c_shipped
==
--- trunk/util/sconfig/sconfig.tab.c_shippedWed May  5 15:12:42 2010
(r5525)
+++ trunk/util/sconfig/sconfig.tab.c_shippedWed May  5 15:13:47 2010
(r5526)
@@ -380,12 +380,12 @@
 /* YYFINAL -- State number of the termination state.  */
 #define YYFINAL  3
 /* YYLAST -- Last index in YYTABLE.  */
-#define YYLAST   22
+#define YYLAST   24
 
 /* YYNTOKENS -- Number of terminals.  */
 #define YYNTOKENS  23
 /* YYNNTS -- Number of nonterminals.  */
-#define YYNNTS  12
+#define YYNNTS  11
 /* YYNRULES -- Number of rules.  */
 #define YYNRULES  17
 /* YYNRULES -- Number of states.  */
@@ -436,26 +436,26 @@
YYRHS.  */
 static const yytype_uint8 yyprhs[] =
 {
-   0, 0, 3, 4, 7, 9,11,14,17,18,
-  21,24,25,26,32,33,41,46
+   0, 0, 3, 4, 7,10,13,16,17,20,
+  23,26,27,28,34,35,43,48
 };
 
 /* YYRHS -- A `-1'-separated list of the rules' RHS.  */
 static const yytype_int8 yyrhs[] =
 {
-  24, 0,-1,-1,25,26,-1,29,-1,31,
-  -1,27,26,-1,27,34,-1,-1,28,26,
-  -1,28,33,-1,-1,-1, 3,12,30,27,
-   9,-1,-1, 4, 7,22, 6,32,28, 9,
-  -1, 8,22,10,22,-1, 5,12,10,12,
-  -1
+  24, 0,-1,-1,25,28,-1,26,30,-1,
+  26,28,-1,26,33,-1,-1,27,30,-1,
+  27,28,-1,27,32,-1,-1,-1, 3,12,
+  29,26, 9,-1,-1, 4, 7,22, 6,31,
+  27, 9,-1, 8,22,10,22,-1, 5,12,
+  10,12,-1
 };
 
 /* YYRLINE[YYN] -- source line where rule number YYN was defined.  */
 static const yytype_uint8 yyrline[] =
 {
-   0,34,34,34,36,36,38,38,38,40,
-  40,40,42,42,52,52,64,67
+   0,34,34,34,36,36,36,36,38,38,
+  38,38,40,40,50,50,62,65
 };
 #endif
 
@@ -467,8 +467,8 @@
   "$end", "error", "$undefined", "CHIP", "DEVICE", "REGISTER", "BOOL",
   "BUS", "RESOURCE", "END", "EQUALS", "HEX", "STRING", "PCI", "PNP", "I2C",
   "APIC", "APIC_CLUSTER", "PCI_DOMAIN", "IRQ", "DRQ", "IO", "NUMBER",
-  "$accept", "devtree", "$...@1", "devchip", "devices", "devicesorresources",
-  "chip", "@2", "device", "@3", "resource", "registers", 0
+  "$accept", "devtree", "$...@1", "chipchildren", "devicechildren", "chip",
+  "@2", "device", "@3", "resource", "registers", 0
 };
 #endif
 
@@ -486,14 +486,14 @@
 /* YYR1[YYN] -- Symbol number of symbol that rule YYN derives.  */
 static const yytype_uint8 yyr1[] =
 {
-   0,23,25,24,26,26,27,27,27,28,
-  28,28,30,29,32,31,33,34
+   0,23,25,24,26,26,26,26,27,27,
+  27,27,29,28,31,30,32,33
 };
 
 /* YYR2[YYN] -- Number of symbols composing right hand side of rule YYN.  */
 static const yytype_uint8 yyr2[] =
 {
-   0, 2, 0, 2, 1, 1, 2, 2, 0, 2,
+   0, 2, 0, 2, 2, 2, 2, 0, 2, 2,
2, 0, 0, 5, 0, 7, 4, 4
 };
 
@@ -502,35 +502,35 @@
means the default is an error.  */
 static const yytype_uint8 yydefact[] =
 {
-   2, 0, 0, 1, 0, 0, 3, 4, 5,12,
-   0, 8, 0, 0,14, 0,13, 6, 7,11,
-   0, 0, 0, 0,15, 9,10,17, 0, 0,
+   2, 0, 0, 1, 0, 3,12, 7, 0, 0,
+   0,13, 5, 4, 6, 0, 0, 0, 0,14,
+  17,11, 0, 0,15, 9, 8,10, 0, 0,
   16
 };
 
 /* YYDEFGOTO[NTERM-NUM].  */
 static const yytype_int8 yydefgoto[] =
 {
-  -1, 1, 2, 6,13,21, 7,11, 8,19,
-  26,18
+  -1, 1, 2, 8,22, 5, 7,13,21,27,
+  14
 };
 
 /* YYPACT[STATE-NUM] -- Index in YYTABLE of the portion describing
STATE-NUM.  */
-

Re: [coreboot] #146: memalign requests huge amounts of memory for large alignments (was: memalign faild with 4k boundary)

[coreboot]

#146: memalign requests huge amounts of memory for large alignments
-+--
   Reporter:  wangqing...@…  |  Owner:  oxygene
   Type:  defect | Status:  closed 
   Priority:  blocker|  Milestone: 
  Component:  libpayload | Resolution:  fixed  
   Keywords: |   Dependencies: 
Patchstatus:  there is no patch  |  
-+--
Changes (by oxygene):

  * keywords:  memalign crashed =>
  * status:  assigned => closed
  * resolution:  => fixed


Comment:

 Fixed in r5298, which included the attached patch.

 memalign doesn't try to allocate at least 100 units of memory (which meant
 400kb for 4kb of 4kb-aligned memory.
 It only allocates at least a kilobyte of data, which should match most use
 cases: For more common 16byte requests, 1kb is allocated and pooled for
 16byte requests, for relatively rare 4kb requests, 4kb is allocated (as
 it's already >1kb)

-- 
Ticket URL: 
coreboot 

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

Re: [coreboot] Porting to RS780/SB700 board

[Myles Watson]

> > Why are we setting anything in the 0-0x8 range ( msr 0x250) or the
> > 0x8-0x9 range (msr 0x258)?
> 
> addr = 0x250;
> <-->lo = 0x1E1E1E1E;
> <-->hi = lo;
> <-->_WRMSR(addr, lo, hi);<-><-->/* 0 - 512K = WB Mem */
> <-->addr = 0x258;
> <-->_WRMSR(addr, lo, hi);<-><-->/* 512K - 640K = WB Mem */
> 
> In mctmtr_d.c

Thanks for pointing out where it's done.  I'm surprised that fam10 sets this
up so early.  K8 doesn't set any of that up until much later.

Thanks,
Myles


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

Re: [coreboot] Hardware damaged?

[Myles Watson]

On Wed, May 5, 2010 at 1:02 AM, mark  wrote:
>> Is there any output on the serial console with Coreboot?  There should
>> have been a lot of it the first time when you got to VGA init.
>
> The problem is, not even the monitor turns on, which indicates that there is
> no VGA init or VGA signal, using both chips.
That's not surprising.  VGA init is pretty late in the process.

> I'll check with a multimeter if there is any current on the pins.
>
>> has a pin of the socket or the flash been bent?
>
> some pins of the original chip have been slightly bent, but I fixed them with 
> a
> pliers before inserting. Unfortunately my plcc32 extractor is too big for that
> board, so the first time I used a screwdriver to extract the chip and after
> that I used some filament underneath the chip to plug it out.

I like the pushpin method.  Cheap, easy, reversible.

http://www.coreboot.org/Developer_Manual/Tools#Chip_removal_tools

Thanks,
Myles

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

Re: [coreboot] H8QME-2+ boot problems on different machines.

[ron minnich]

On Wed, May 5, 2010 at 12:39 AM, Knut Kujat  wrote:

> - I now know that my resource map must be some kind of faulty. But why
> does it work on one CPU and doesn't on another, complete identical, one?

It's not about the CPU, it is more about how the mainboard is wired
up. And, it is not surprising that it might be wired differently
on two mainboards with identical part #s. Supermicro does this type of
change frequently. You would really need to boot the factory
bios and dump the config registers on all cpus to see if they
mainboard has changed somehow.

> - How do i manage to correct my resource map? Or how do I create a good
> resource map?

dump the factory bios.

> - Since it seems to boot fine without resource map. Do I really need one?

you really need one.

> - And the last one, If I don't setup the res. map, who does it?

nobody.

ron

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

Re: [coreboot] H8QME-2+ boot problems on different machines.

[Myles Watson]

I've had questions about resource maps too.

> > - I now know that my resource map must be some kind of faulty. But why
> > does it work on one CPU and doesn't on another, complete identical, one?
> 
> It's not about the CPU, it is more about how the mainboard is wired
> up. And, it is not surprising that it might be wired differently
> on two mainboards with identical part #s. Supermicro does this type of
> change frequently. You would really need to boot the factory
> bios and dump the config registers on all cpus to see if they
> mainboard has changed somehow.

The reason he got to that conclusion was that the same motherboard boots
differently with a different CPU and the identical BIOS.  I don't understand
how it could be a wiring issue.

If the failure is consistent, can you use showallroutes(BIOS_INFO,
PCI_DEV(0, 0x18, 1)); right before your resource map gets set.  I think that
might help us figure it out.
 
> > - How do i manage to correct my resource map? Or how do I create a good
> > resource map?
> 
> dump the factory bios.

I think this can be problematic, since by the time you can dump the factory
BIOS resource allocation has already occurred.  The resource map is only
good for early initialization, before resource allocation, right?

> > - Since it seems to boot fine without resource map. Do I really need
> one?
I think the problem comes if values happen to be left over from a previous
boot.  I guess it could happen with different "default" values for different
processors, too.  Then devices that should be reachable won't respond.
 
> you really need one.
> 
> > - And the last one, If I don't setup the res. map, who does it?
> 
> nobody.

At least until resource allocation.

Thanks,
Myles


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

Re: [coreboot] H8QME-2+ boot problems on different machines.

[ron minnich]

On Wed, May 5, 2010 at 7:44 AM, Myles Watson  wrote:

> The reason he got to that conclusion was that the same motherboard boots
> differently with a different CPU and the identical BIOS.  I don't understand
> how it could be a wiring issue.

I went back and managed to misunderstand the post, I thought it was
same motherboard type but two different boards.

Sorry.


> I think this can be problematic, since by the time you can dump the factory
> BIOS resource allocation has already occurred.  The resource map is only
> good for early initialization, before resource allocation, right?

hmm. I had always used the bios map as a starting point and it had
worked well for me.
But maybe things are much harder now. It is true that you need to do a bit of
interpretation of the map once the factory BIOS has set it up.

Does resource allocation get all the bits, even legacy ones? Are there
not some resource map values that
a resource allocator can not figure out?

ron

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

Re: [coreboot] H8QME-2+ boot problems on different machines.

[Myles Watson]

 
> > I think this can be problematic, since by the time you can dump the
> factory
> > BIOS resource allocation has already occurred.  The resource map is only
> > good for early initialization, before resource allocation, right?
> 
> hmm. I had always used the bios map as a starting point and it had
> worked well for me.

I think most of the time it should work fine, but we have some hard-coded
addresses where the chipset is expected to live in early setup routines, and
they might break.

My resource map sets:
DRAM mappings for each node
MMIO mappings for each HT chain
PCI IO mappings for each HT chain
PCI Bus numbers for each HT chain

I think they should only be needed for things like ck804_early_setup_car.c,
where I/O is being used and set up.  If the mappings aren't configured the
reads and writes don't reach the chipset.

> But maybe things are much harder now. It is true that you need to do a bit
> of
> interpretation of the map once the factory BIOS has set it up.
> 
> Does resource allocation get all the bits, even legacy ones? Are there
> not some resource map values that
> a resource allocator can not figure out?

I don't know.  Once resource allocation is done you should know where your
VGA card is, and where your Southbridge is.  I'm probably missing something,
but I think once resource allocation is done all of the registers that are
touched in the resource map have been rewritten.

Thanks,
Myles


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

Re: [coreboot] #18: autoprobe apic cluster and application processors on K8 systems

[coreboot]

#18: autoprobe apic cluster and application processors on K8 systems
-+--
Reporter:  stepan| Owner:  oxygene   
Type:  defect|Status:  new   
Priority:  major | Milestone:
   Component:  coreboot  |  Keywords:  K8, cleanup   
Dependencies:|   Patchstatus:  patch needs review
-+--
Changes (by stepan):

  * patchstatus:  there is no patch => patch needs review


-- 
Ticket URL: 
coreboot 

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

Re: [coreboot] [PATCH] Add AES to devicetree.cb for AMD LX boards

[Myles Watson]

On Tue, May 4, 2010 at 5:40 PM, Nathan Williams  wrote:
> On 5/05/2010 12:15 AM, Stefan Reinauer wrote:
>> On 5/4/10 10:07 AM, Nathan Williams wrote:
>>> Signed-off-by: Nathan Williams 
>>>
>>> -                    device pci 1.0 on end
>>> -            device pci 1.1 on end
>>> +                    device pci 1.0 on end # Northbridge
>>> +            device pci 1.1 on end # Graphics
>>> +            device pci 1.2 on end # AES
>> What's the impact of that change?
>>
>> Stefan
>>
>
> I don't think it makes any difference.  I just added it for 
> completeness/documentation.

In general we try to only specify the devices that must be specified
because they have special driver needs.  It keeps the device trees
cleaner.  Things that can be probed for and initialized by the generic
code are better left alone.  Maybe a comment in the lx code would be a
good way to document other functions.

Thanks,
Myles

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

[coreboot] H8DME-2 woes, hints?

[Joe Korty]

As a first time coreboot user, I thought that I should first try it out
on a supported board.  That way I would learn the ropes a bit before even
thinking about doing something more challenging.

Naturally I am having troubles.  I suspect that as a newbie I am probably
doing something stupid.  But then I've heard that mb manufacturers like
to change things around without notice, so maybe I'm doing things right
and what was once a supported mb, no longer is.

The hardware:
   SuperMicro H8DME-2.
   Four 1Gbyte DDR2-667/533/400 Registered ECC SDRAM sticks from Crucial.
   Two Quad-Core AMD 2378 2.4 GHz Processors.
   Onboard video.
   One SATA disk.
   One PATA DVD-ROM reader.
   NULL modem serial cable from COM1 to COM1 on another PC.

The details:
   When booting coreboot, nothing happens for about 45 seconds.
   Then the fans speed up to high and some messages start appearing
   on the serial line.  These messages print rather slowly (maybe
   1 second/message).  They are:

coreboot-4.0-r5521M Wed May  5 10:53:42 EDT 2010 starting...
*sysinfo range: [000cf000,000cf730]
bsp_apicid=00
Enabling routing table for node 00 done.
Enabling SMP settings
(0,1) link=00

   At this point coreboot ceases to make forward progress.  The
   fans remain spinning at their highest settings.  The VGA screen
   is blank throughout.

   I put some printk's in setup_smb2, the crashing routine.  They show
   that setup_temp_row is called by setup_smb2 but never returns.

Anyways, I've attached the entire build procedure I used to achieve
these results.  Perhaps there is something in this sequence that I am
doing wrong???  And, what kind of luck have others had with recent
H8DME-2 boards?

Regards,
Joe


   # install RHEL5 32-bit on H8DME-2 test stand
   # log in as myself


   # --- make flashrom(1) tool

   cd
   svn co svn://coreboot.org/flashrom/trunk flashrom
   cd flashrom
   make
   sudo make install

   # --- get latest coreboot sources

   cd ..
   svn co svn://coreboot.org/coreboot/trunk coreboot
   cd coreboot

   # --- get pre-built SeaBIOS coreboot payload

   wget -O payload.elf http://linuxtogo.org/~kevin/SeaBIOS/bios.bin.elf-0.6.0

   # --- extract H8DME-2's onboard Video ROM

   fgrep 'Video ROM' /proc/iomem
   # displays "000c-000cafff : Video ROM"
   sudo dd if=/dev/mem of=/tmp/vgabios.bin bs=4k skip=$((0xc0)) count=$((0xb))

   # --- figure out the Video ROM's PCI Vendor,Device ID
   # --- I _think_ the numbers I want are the second set shown, ie "15d9:1611".

   lspci -v | fgrep VGA
   # displays "01:05.0 VGA compatible controller: ATI Technologies Inc ES1000 
..."

   lspci -vn | fgrep -A1 01:05.0
   # displays "01:05.0 0300: 1002:515e (rev 02)
   Subsystem: 15d9:1611"

   # --- build-n-burn coreboot

   make menuconfig
   # select Mainboard -> SuperMicro -> H8DME-2
   # select Payload -> Add A Payload -> ELF
   # select VGA Bios -> Add A VGA BIOS -> VGA Device PCI IDS -> "15d9,1611"
   make
   /usr/local/sbin/flashrom -w build/coreboot.rom

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

Re: [coreboot] Coreboot doesn't boot on Arima HDAMA rev.G mainboard

[Rudolf Marek]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi,

I used the Sillicon Image PCI card with onboard BIOS. It works well in SeaBIOS.
I would say here would be enough to extract the optionrom from orig BIOS. And
SeaBIOS will assign/use it.

By the bizarre coincidence I had this board @home and booting from IDE worked
well (under SeaBIOS).

Attached patch enables bios_extract to extract the BIOS ;)

oprom_4.rom is for SATA
oprom_3.rom is FastTRAK

I think you can http://www.coreboot.org/SeaBIOS go same as for Adding the VGA
rom here.

As a side note one could program an GPL rombios for this controller - any 
takers?

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

iEYEARECAAYFAkvh0FgACgkQ3J9wPJqZRNWS9ACfX/zKWvtO+WV/wwHkDxPdq6P9
qZgAoIrO8y4BaYJBV2e/Lx//gsbpy6I/
=vBZM
-END PGP SIGNATURE-
diff --git a/bios_extract.c b/bios_extract.c
index cd87ee8..bbd2d17 100644
--- a/bios_extract.c
+++ b/bios_extract.c
@@ -90,6 +90,7 @@ static struct {
 {"AMIEBBLK", "AMIBIOSC", AMI95Extract},
 {"Award BootBlock", "= Award Decompression Bios =", AwardExtract},
 {"Phoenix FirstBIOS", "BCPSEGMENT", PhoenixExtract},
+{"Phoenix ServerBIOS 3", "BCPSEGMENT", PhoenixExtract},
 {"PhoenixBIOS 4.0", "BCPSEGMENT", PhoenixExtract},
 {"Phoenix TrustedCore", "BCPSEGMENT", PhoenixTrustedExtract},
 {NULL, NULL, NULL},


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

Re: [coreboot] H8DME-2 woes, hints?

[Myles Watson]

On Wed, May 5, 2010 at 2:06 PM, Joe Korty  wrote:
> As a first time coreboot user, I thought that I should first try it out
> on a supported board.  That way I would learn the ropes a bit before even
> thinking about doing something more challenging.
>
> Naturally I am having troubles.  I suspect that as a newbie I am probably
> doing something stupid.  But then I've heard that mb manufacturers like
> to change things around without notice, so maybe I'm doing things right
> and what was once a supported mb, no longer is.
It looks like you're doing things right.  It's dying really early, though.

> The details:
>   When booting coreboot, nothing happens for about 45 seconds.
>   Then the fans speed up to high and some messages start appearing
>   on the serial line.  These messages print rather slowly (maybe
>   1 second/message).  They are:
>
>        coreboot-4.0-r5521M Wed May  5 10:53:42 EDT 2010 starting...
>        *sysinfo range: [000cf000,000cf730]
>        bsp_apicid=00
>        Enabling routing table for node 00 done.
>        Enabling SMP settings
>        (0,1) link=00
You could try an earlier revision.  I can't think of what would slow
it down that much.

>   At this point coreboot ceases to make forward progress.  The
>   fans remain spinning at their highest settings.  The VGA screen
>   is blank throughout.
>
>   I put some printk's in setup_smb2, the crashing routine.  They show
>   that setup_temp_row is called by setup_smb2 but never returns.
Since it takes so long to get there, I think you'll have better luck
trying to figure out what's wrong before that.

>   # --- extract H8DME-2's onboard Video ROM
>
>   fgrep 'Video ROM' /proc/iomem
>   # displays "000c-000cafff : Video ROM"
>   sudo dd if=/dev/mem of=/tmp/vgabios.bin bs=4k skip=$((0xc0)) count=$((0xb))
>
>   # --- figure out the Video ROM's PCI Vendor,Device ID
>   # --- I _think_ the numbers I want are the second set shown, ie "15d9:1611".

You want the first set.  The second set is Supermicro's board ID.

>   lspci -v | fgrep VGA
>   # displays "01:05.0 VGA compatible controller: ATI Technologies Inc ES1000 
> ..."
>
>   lspci -vn | fgrep -A1 01:05.0
>   # displays "01:05.0 0300: 1002:515e (rev 02)
>               Subsystem: 15d9:1611"
>

Good luck,
Myles

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

Re: [coreboot] Coreboot doesn't boot on Arima HDAMA rev.G mainboard

[Joop Boonen]

On Wed, May 5, 2010 12:35 am, Myles Watson wrote:
>>> I think the most likely culprit is SB_HT_CHAIN_ON_BUS0.  Could you
>>> change it to 1 in src/mainboard/arima/hdama/Kconfig, make oldconfig,
>>> and test?
>>
>> I've tested it. I get the filo screen now.
> Great.  I checked that in Rev 5522.
>
>> When I do a probe I don't see any IDE device yet. Neither IDE nor SATA
>> SIL3114 drive. This also didn't work for version 4920.
>
> Have you tried SeaBIOS?  I haven't used FILO much.  In your log it
> looks like FILO is expecting to find something in your CMOS that it
> doesn't find.
>
> ERROR: No such CMOS option (boot_devices)
> menu: hda3:/boot/filo/menu.lst

I've just used SeaBIOS. With SeaBIOS LInux boots without a problem (except
for ACPI, I understood this is not (fully) supported yet.

I have a feeling that FILO has an issue?
>
> You could look into that.
>
> 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] FILO issue?

[Joop Boonen]

On Wed, May 5, 2010 9:21 pm, Joop Boonen wrote:
> All,
>
> I have an issue that might be related to FILO. I don't seem to be able to
> read the filesystem.
>
> I've attached the serial session log.
> I've compiled filo with all debug flags.
>
I've just used SeaBIOS. With SeaBIOS LInux boots without a problem (except
for ACPI, I understood this is not (fully) supported yet.

I have a feeling that FILO has an issue?

I booted off an ATA disk.

> Regards,
>
> Joop.--
> 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] Coreboot doesn't boot on Arima HDAMA rev.G mainboard

[Joop Boonen]

On Wed, May 5, 2010 12:35 am, Myles Watson wrote:
>>> I think the most likely culprit is SB_HT_CHAIN_ON_BUS0.  Could you
>>> change it to 1 in src/mainboard/arima/hdama/Kconfig, make oldconfig,
>>> and test?
>>
>> I've tested it. I get the filo screen now.
> Great.  I checked that in Rev 5522.
>
>> When I do a probe I don't see any IDE device yet. Neither IDE nor SATA
>> SIL3114 drive. This also didn't work for version 4920.
>
> Have you tried SeaBIOS?  I haven't used FILO much.  In your log it
> looks like FILO is expecting to find something in your CMOS that it
> doesn't find.
>
> ERROR: No such CMOS option (boot_devices)
> menu: hda3:/boot/filo/menu.lst

I've just used SeaBIOS. With SeaBIOS LInux boots without a problem (except
for ACPI, I understood this is not (fully) supported yet.

I have a feeling that FILO has an issue?

I booted off an ATA disk.
>
> You could look into that.
>
> 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] Coreboot doesn't boot on Arima HDAMA rev.G mainboard

[Rudolf Marek]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

I think we miss ACPI support for this board and PowerNow. The documentation is
available and I think it could be added easily.

I'm willing to help give/hints if somebody takes that.

Rudolf


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

iEYEARECAAYFAkvh6LQACgkQ3J9wPJqZRNWCmQCdGESsx0CQN5ynhzSMyKcGsuwQ
tPkAn0xt4wTbmcKDka03rciPSSAv4vzf
=+yhi
-END PGP SIGNATURE-

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

[coreboot] [CoreBoot][Patch] Support for Gigabyte GA-6BXE

[Anders Jenbo]

Adds initial support for Gigabyte GA-6BXE.
Known issues: The serial port runs at 2x the baud.

Signed-off-by: Anders Jenbo 
---

Anders Jenbo
Index: src/mainboard/gigabyte/Kconfig
===
--- src/mainboard/gigabyte/Kconfig	(revision 5526)
+++ src/mainboard/gigabyte/Kconfig	(working copy)
@@ -24,6 +24,7 @@
 
 source "src/mainboard/gigabyte/ga_2761gxdk/Kconfig"
 source "src/mainboard/gigabyte/ga-6bxc/Kconfig"
+source "src/mainboard/gigabyte/ga-6bxe/Kconfig"
 source "src/mainboard/gigabyte/m57sli/Kconfig"
 
 endchoice
Index: src/mainboard/gigabyte/ga-6bxe/Kconfig
===
--- src/mainboard/gigabyte/ga-6bxe/Kconfig	(revision 0)
+++ src/mainboard/gigabyte/ga-6bxe/Kconfig	(revision 0)
@@ -0,0 +1,53 @@
+##
+## 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
+##
+
+config BOARD_GIGABYTE_GA_6BXE
+	bool "GA-6BXE"
+	select ARCH_X86
+	select CPU_INTEL_SLOT_1
+	select NORTHBRIDGE_INTEL_I440BX
+	select SOUTHBRIDGE_INTEL_I82371EB
+	select SUPERIO_ITE_IT8671F
+	select ROMCC
+	select HAVE_PIRQ_TABLE
+	select UDELAY_TSC
+	select BOARD_ROMSIZE_KB_256
+	select SDRAMPWR_4DIMM
+
+config MAINBOARD_DIR
+	string
+	default gigabyte/ga-6bxe
+	depends on BOARD_GIGABYTE_GA_6BXE
+
+config MAINBOARD_PART_NUMBER
+	string
+	default "GA-6BXE"
+	depends on BOARD_GIGABYTE_GA_6BXE
+
+config HAVE_OPTION_TABLE
+	bool
+	default n
+	depends on BOARD_GIGABYTE_GA_6BXE
+
+config IRQ_SLOT_COUNT
+	int
+	default 7
+	depends on BOARD_GIGABYTE_GA_6BXE
+
Index: src/mainboard/gigabyte/ga-6bxe/romstage.c
===
--- src/mainboard/gigabyte/ga-6bxe/romstage.c	(revision 0)
+++ src/mainboard/gigabyte/ga-6bxe/romstage.c	(revision 0)
@@ -0,0 +1,71 @@
+/*
+ * 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
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "pc80/serial.c"
+#include "console/console.c"
+#include "lib/ramtest.c"
+#include "southbridge/intel/i82371eb/i82371eb_enable_rom.c"
+#include "southbridge/intel/i82371eb/i82371eb_early_smbus.c"
+#include "northbridge/intel/i440bx/raminit.h"
+#include "lib/debug.c"
+#include "pc80/udelay_io.c"
+#include "lib/delay.c"
+#include "cpu/x86/mtrr/earlymtrr.c"
+#include "cpu/x86/bist.h"
+#include "superio/ite/it8671f/it8671f_early_serial.c"
+
+#define SERIAL_DEV PNP_DEV(0x3f0, IT8671F_SP1)
+
+static inline int spd_read_byte(unsigned int device, unsigned int address)
+{
+	return smbus_read_byte(device, address);
+}
+
+#include "northbridge/intel/i440bx/raminit.c"
+#include "northbridge/intel/i440bx/debug.c"
+
+static void main(unsigned long bist)
+{
+	if (bist == 0)
+		early_mtrr_init();
+
+	it8671f_enable_serial(SERIAL_DEV, CONFIG_TTYS0_BASE);
+	uart_init();
+	console_init();
+	report_bist_failure(bist);
+
+	/* Enable access to the full ROM chip, needed very early by CBFS. */
+	i82371eb_enable_rom(PCI_DEV(0, 7, 0)); /* ISA bridge is 00:07.0. */
+
+	enable_smbus();
+	/* dump_spd_registers(); */
+	sdram_set_registers();
+	sdram_set_spd_registers();
+	sdram_enable();
+	/* ram_check(0, 640 * 1024); */
+}
+
Index: src/mainboard/gigabyte/ga-6bxe/devicetree.cb
===
--- src/mainboard/gigabyte/ga-6bxe/devicetree.cb	(revision 0)
+++ src/mainboard/gigabyte/ga-6bxe/devicetree.cb	(revision 0)
@@ -0,0 +1,57 @@
+chip northbridge/intel/i440bx		# Northbrid