Re: [coreboot] Is PI-AM2RS780G supported ?
On Tue, Jun 23, 2009 at 2:28 AM, Alois Schlögl alois.schlo...@tugraz.atwrote: The reason for asking is the bug as described here: http://bugzilla.kernel.org/show_bug.cgi?id=13573 The bug is affecting my research at the university. It was suggested that a Bios-update could solve the problem. IIRC you can disable thermal throttling, but it's usually not a good idea if you expect to keep your machine running with reasonable performance under load. If the vendor BIOS had the proper tables (See section 2.4.2 on P-States in the AMD BIOS and Kernel Developer's Guide for Fam10 processors), your CPU would slow itself down to avoid generating too much heat. If you disable thermal throttling and continue to run your workload, your CPU will hit Tjunction at around 116 degrees C and shut itself off abruptly, possibly after physical damage has been done to the CPU or the socket. I would suggest starting with something much simpler, like making sure you have quality thermal transfer compound applied in the proper quantity for your CPUs. I know it sounds stupid, but I have seen many machines from many datacenters with very powerful rack cooling overheat under heavy loads due to improperly applied thermal grease. There are many tutorials and videos on how to do this. Make sure you clean off the old thermal grease first with a high-concentration isopropyl alcohol (90%) first. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Is PI-AM2RS780G supported ?
On Wed, Jun 24, 2009 at 12:30 AM, David Hendricks dhend...@google.comwrote: On Tue, Jun 23, 2009 at 2:28 AM, Alois Schlögl alois.schlo...@tugraz.atwrote: The reason for asking is the bug as described here: http://bugzilla.kernel.org/show_bug.cgi?id=13573 The bug is affecting my research at the university. It was suggested that a Bios-update could solve the problem. IIRC you can disable thermal throttling, but it's usually not a good idea if you expect to keep your machine running with reasonable performance under load. If the vendor BIOS had the proper tables (See section 2.4.2 on P-States in the AMD BIOS and Kernel Developer's Guide for Fam10 processors), your CPU would slow itself down to avoid generating too much heat. If you disable thermal throttling and continue to run your workload, your CPU will hit Tjunction at around 116 degrees C and shut itself off abruptly, possibly after physical damage has been done to the CPU or the socket. I would suggest starting with something much simpler, like making sure you have quality thermal transfer compound applied in the proper quantity for your CPUs. I know it sounds stupid, but I have seen many machines from many datacenters with very powerful rack cooling overheat under heavy loads due to improperly applied thermal grease. There are many tutorials and videos on how to do this. Make sure you clean off the old thermal grease first with a high-concentration isopropyl alcohol (90%) first. Oh, and while you're at it make sure the heatsinks are securely fastened. After you re-apply thermal grease, tighten the screws such that they will not turn any more. The mounting points on the motherboard will ensure the maximum threshold is not exceeded, though I suggest tightening one about 80-90%, then the second one 100%, then finish the first one to apply the pressure more evenly. Just another very silly thing that can cause unexpected behavior under heavy workloads... -- David Hendricks (dhendrix) Systems Software Engineer, Google Inc. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] [flashrom] r628 - trunk
Author: hailfinger
Date: 2009-06-24 10:18:38 +0200 (Wed, 24 Jun 2009)
New Revision: 628
Modified:
trunk/flashrom.8
trunk/flashrom.c
Log:
Remove duplicated [file] from usage help. A file is already specified
directly in conjunction for -r/-w/-v.
Signed-off-by: Carl-Daniel Hailfinger c-d.hailfinger.devel.2...@gmx.net
Acked-by: Uwe Hermann u...@hermann-uwe.de
Modified: trunk/flashrom.8
===
--- trunk/flashrom.82009-06-23 20:27:33 UTC (rev 627)
+++ trunk/flashrom.82009-06-24 08:18:38 UTC (rev 628)
@@ -4,7 +4,7 @@
.SH SYNOPSIS
.B flashrom \fR[\fB\-VfLzhR\fR] [\fB\-E\fR|\fB\-r\fR file|\fB\-w\fR
file|\fB\-v\fR file]
[\fB\-c\fR chipname] [\fB\-m\fR [vendor:]part]
- [\fB\-l\fR file] [\fB\-i\fR image] [\fB\-p\fR programmer] [file]
+ [\fB\-l\fR file] [\fB\-i\fR image] [\fB\-p\fR programmer]
.SH DESCRIPTION
.B flashrom
is a utility for detecting, reading, writing, verifying and erasing flash
Modified: trunk/flashrom.c
===
--- trunk/flashrom.c2009-06-23 20:27:33 UTC (rev 627)
+++ trunk/flashrom.c2009-06-24 08:18:38 UTC (rev 628)
@@ -493,7 +493,7 @@
void usage(const char *name)
{
printf(usage: %s [-VfLzhR] [-E|-r file|-w file|-v file] [-c
chipname]\n
- [-m [vendor:]part] [-l file] [-i image] [-p programmer]
[file]\n\n, name);
+ [-m [vendor:]part] [-l file] [-i image] [-p
programmer]\n\n, name);
printf(Please note that the command line interface for flashrom will
change before\nflashrom 1.0. Do not use flashrom in scripts
@@ -518,9 +518,8 @@
it87spi, ft2232spi,
serprog)\n
-h | --help: print this help text\n
-R | --version: print the version
(release)\n
-\nYou can specify one of -E, -r, -w, -v or no operation.
-If no operation is\nspecified, then all that happens
- is that flash info is dumped.\n\n);
+\nYou can specify one of -E, -r, -w, -v or no operation. If no
operation is\n
+specified, then all that happens is that flash info is
dumped.\n\n);
exit(1);
}
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH] flashrom: Remove duplicated [file] from usage help
On 24.06.2009 00:19, Uwe Hermann wrote: On Fri, Jun 19, 2009 at 12:54:24PM +0200, Carl-Daniel Hailfinger wrote: Remove duplicated [file] from usage help. A file is already specified directly in conjunction for -r/-w/-v. Signed-off-by: Carl-Daniel Hailfinger c-d.hailfinger.devel.2...@gmx.net Acked-by: Uwe Hermann u...@hermann-uwe.de Thanks, committed in r628. Regards, Carl-Daniel -- http://www.hailfinger.org/ -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] [flashrom] r629 - trunk
Author: hailfinger
Date: 2009-06-24 10:20:45 +0200 (Wed, 24 Jun 2009)
New Revision: 629
Modified:
trunk/flashrom.c
Log:
Use correct abstraction for verify_range(). The new abstraction can
handle out-of-band chip communication protocols as well.
The old abstraction caused spurious false positives for erase on SPI and
spurious false negatives for verify on SPI.
Make verify_flash() use verify_range().
Tested by Uwe on SB600.
Signed-off-by: Carl-Daniel Hailfinger c-d.hailfinger.devel.2...@gmx.net
Acked-by: Uwe Hermann u...@hermann-uwe.de
Modified: trunk/flashrom.c
===
--- trunk/flashrom.c2009-06-24 08:18:38 UTC (rev 628)
+++ trunk/flashrom.c2009-06-24 08:20:45 UTC (rev 629)
@@ -276,13 +276,16 @@
int verify_range(struct flashchip *flash, uint8_t *cmpbuf, int start, int len,
char *message)
{
int i, j, starthere, lenhere, ret = 0;
- chipaddr bios = flash-virtual_memory;
int page_size = flash-page_size;
uint8_t *readbuf = malloc(page_size);
if (!len)
goto out_free;
+ if (!flash-read) {
+ fprintf(stderr, ERROR: flashrom has no read function for this
flash chip.\n);
+ return 1;
+ }
if (!readbuf) {
fprintf(stderr, Could not allocate memory!\n);
exit(1);
@@ -312,7 +315,7 @@
starthere = max(start, i * page_size);
/* Length of bytes in the range in this page. */
lenhere = min(start + len, (i + 1) * page_size) - starthere;
- chip_readn(readbuf, bios + starthere, lenhere);
+ flash-read(flash, readbuf, starthere, lenhere);
for (j = 0; j lenhere; j++) {
if (cmpbuf[starthere - start + j] != readbuf[j]) {
fprintf(stderr, %s FAILED at 0x%08x!
@@ -384,44 +387,17 @@
int verify_flash(struct flashchip *flash, uint8_t *buf)
{
- int idx;
+ int ret;
int total_size = flash-total_size * 1024;
- uint8_t *buf2 = (uint8_t *) calloc(total_size, sizeof(char));
- if (!flash-read) {
- printf(FAILED!\n);
- fprintf(stderr, ERROR: flashrom has no read function for this
flash chip.\n);
- return 1;
- } else
- flash-read(flash, buf2, 0, total_size);
printf(Verifying flash... );
- if (verbose)
- printf(address: 0x\b\b\b\b\b\b\b\b\b\b);
+ ret = verify_range(flash, buf, 0, total_size, NULL);
- for (idx = 0; idx total_size; idx++) {
- if (verbose ((idx 0xfff) == 0xfff))
- printf(0x%08x, idx);
+ if (!ret)
+ printf(VERIFIED. \n);
- if (*(buf2 + idx) != *(buf + idx)) {
- if (verbose)
- printf(0x%08x FAILED!, idx);
- else
- printf(FAILED at 0x%08x!, idx);
- printf( Expected=0x%02x, Read=0x%02x\n,
- *(buf + idx), *(buf2 + idx));
- return 1;
- }
-
- if (verbose ((idx 0xfff) == 0xfff))
- printf(\b\b\b\b\b\b\b\b\b\b);
- }
- if (verbose)
- printf(\b\b\b\b\b\b\b\b\b\b );
-
- printf(VERIFIED. \n);
-
- return 0;
+ return ret;
}
int read_flash(struct flashchip *flash, char *filename)
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH] flashrom: Use improved abstraction for verify_range
On 24.06.2009 00:17, Uwe Hermann wrote: On Mon, Jun 22, 2009 at 11:26:54AM +0200, Carl-Daniel Hailfinger wrote: Use correct abstraction for verify_range(). The new abstraction can handle out-of-band chip communication protocols as well. The old abstraction caused spurious false positives for erase on SPI and spurious false negatives for verify on SPI. Make verify_flash() use verify_range(). Signed-off-by: Carl-Daniel Hailfinger c-d.hailfinger.devel.2...@gmx.net Acked-by: Uwe Hermann u...@hermann-uwe.de Looks good, tested on sb600. Thanks, committed in r629. Regards, Carl-Daniel -- http://www.hailfinger.org/ -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH] flashrom: Check result of all SPI erase functions
On 24.06.2009 00:00, Uwe Hermann wrote: On Mon, Jun 22, 2009 at 11:57:03AM +0200, Carl-Daniel Hailfinger wrote: Check result of all SPI erase functions. Since block erase functions do not know the block length (it's not specified in any standard), block erase functions now get an additional parameter blocklen. This enables flashrom to verify the erase result for block erase functions at correct boundaries. Unchecked erase is bad and can lead to problems nobody can understand. Signed-off-by: Carl-Daniel Hailfinger c-d.hailfinger.devel.2...@gmx.net Acked-by: Uwe Hermann u...@hermann-uwe.de Tested OK on an sb600 board. Thanks, committed in r. Index: flashrom-spi_verify_erase/spi.c === - * Copyright (C) 2007, 2008 Carl-Daniel Hailfinger + * Copyright (C) 2007, 2008, 2009 Carl-Daniel Hailfinger Maybe 2007-2009 for brevity and shorter lines (on the long term). I think I once read a comment which said that year ranges have no legal significance, they are like (C) convenient hints without meaning. Since copyright law is a strange beast and I'm not a lawyer, I prefer to be cautious. Regards, Carl-Daniel -- http://www.hailfinger.org/ -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] [flashrom] r630 - trunk
Author: hailfinger
Date: 2009-06-24 10:28:39 +0200 (Wed, 24 Jun 2009)
New Revision: 630
Modified:
trunk/flash.h
trunk/ichspi.c
trunk/spi.c
Log:
Check result of all SPI erase functions.
Since block erase functions do not know the block length (it's not
specified in any standard), block erase functions now get an additional
parameter blocklen. This enables flashrom to verify the erase result for
block erase functions at correct boundaries.
Tested by Uwe on SB600.
Signed-off-by: Carl-Daniel Hailfinger c-d.hailfinger.devel.2...@gmx.net
Acked-by: Uwe Hermann u...@hermann-uwe.de
Modified: trunk/flash.h
===
--- trunk/flash.h 2009-06-24 08:20:45 UTC (rev 629)
+++ trunk/flash.h 2009-06-24 08:28:39 UTC (rev 630)
@@ -425,8 +425,11 @@
int spi_chip_erase_c7(struct flashchip *flash);
int spi_chip_erase_60_c7(struct flashchip *flash);
int spi_chip_erase_d8(struct flashchip *flash);
-int spi_block_erase_52(const struct flashchip *flash, unsigned long addr);
-int spi_block_erase_d8(const struct flashchip *flash, unsigned long addr);
+int spi_block_erase_20(struct flashchip *flash, unsigned int addr, unsigned
int blocklen);
+int spi_block_erase_52(struct flashchip *flash, unsigned int addr, unsigned
int blocklen);
+int spi_block_erase_d8(struct flashchip *flash, unsigned int addr, unsigned
int blocklen);
+int spi_block_erase_60(struct flashchip *flash, unsigned int addr, unsigned
int blocklen);
+int spi_block_erase_c7(struct flashchip *flash, unsigned int addr, unsigned
int blocklen);
int spi_chip_write_1(struct flashchip *flash, uint8_t *buf);
int spi_chip_write_256(struct flashchip *flash, uint8_t *buf);
int spi_chip_read(struct flashchip *flash, uint8_t *buf, int start, int len);
Modified: trunk/ichspi.c
===
--- trunk/ichspi.c 2009-06-24 08:20:45 UTC (rev 629)
+++ trunk/ichspi.c 2009-06-24 08:28:39 UTC (rev 630)
@@ -661,7 +661,7 @@
* For this, we need to add a block erase function to
* struct flashchip.
*/
- rc = spi_block_erase_d8(flash, i * erase_size);
+ rc = spi_block_erase_d8(flash, i * erase_size, erase_size);
if (rc) {
printf(Error erasing block at 0x%x\n, i);
break;
Modified: trunk/spi.c
===
--- trunk/spi.c 2009-06-24 08:20:45 UTC (rev 629)
+++ trunk/spi.c 2009-06-24 08:28:39 UTC (rev 630)
@@ -1,7 +1,7 @@
/*
* This file is part of the flashrom project.
*
- * Copyright (C) 2007, 2008 Carl-Daniel Hailfinger
+ * Copyright (C) 2007, 2008, 2009 Carl-Daniel Hailfinger
* Copyright (C) 2008 coresystems GmbH
*
* This program is free software; you can redistribute it and/or modify
@@ -430,6 +430,10 @@
/* FIXME: We assume spi_read_status_register will never fail. */
while (spi_read_status_register() JEDEC_RDSR_BIT_WIP)
programmer_delay(1000 * 1000);
+ if (check_erased_range(flash, 0, flash-total_size * 1024)) {
+ fprintf(stderr, ERASE FAILED!\n);
+ return -1;
+ }
return 0;
}
@@ -458,6 +462,10 @@
/* FIXME: We assume spi_read_status_register will never fail. */
while (spi_read_status_register() JEDEC_RDSR_BIT_WIP)
programmer_delay(1000 * 1000);
+ if (check_erased_range(flash, 0, flash-total_size * 1024)) {
+ fprintf(stderr, ERASE FAILED!\n);
+ return -1;
+ }
return 0;
}
@@ -472,9 +480,9 @@
return result;
}
-int spi_block_erase_52(const struct flashchip *flash, unsigned long addr)
+int spi_block_erase_52(struct flashchip *flash, unsigned int addr, unsigned
int blocklen)
{
- unsigned char cmd[JEDEC_BE_52_OUTSIZE] = {JEDEC_BE_52};
+ unsigned char cmd[JEDEC_BE_52_OUTSIZE] = {JEDEC_BE_52, };
int result;
cmd[1] = (addr 0x00ff) 16;
@@ -490,6 +498,10 @@
*/
while (spi_read_status_register() JEDEC_RDSR_BIT_WIP)
programmer_delay(100 * 1000);
+ if (check_erased_range(flash, addr, blocklen)) {
+ fprintf(stderr, ERASE FAILED!\n);
+ return -1;
+ }
return 0;
}
@@ -498,9 +510,9 @@
* 32k for SST
* 4-32k non-uniform for EON
*/
-int spi_block_erase_d8(const struct flashchip *flash, unsigned long addr)
+int spi_block_erase_d8(struct flashchip *flash, unsigned int addr, unsigned
int blocklen)
{
- unsigned char cmd[JEDEC_BE_D8_OUTSIZE] = { JEDEC_BE_D8 };
+ unsigned char cmd[JEDEC_BE_D8_OUTSIZE] = { JEDEC_BE_D8, };
int result;
cmd[1] = (addr 0x00ff) 16;
@@ -516,6 +528,10 @@
*/
while (spi_read_status_register() JEDEC_RDSR_BIT_WIP)
programmer_delay(100 * 1000);
+ if
Re: [coreboot] [PATCH] flashrom: Check result of all SPI erase functions
On 24.06.2009 10:26, Carl-Daniel Hailfinger wrote: On 24.06.2009 00:00, Uwe Hermann wrote: On Mon, Jun 22, 2009 at 11:57:03AM +0200, Carl-Daniel Hailfinger wrote: Check result of all SPI erase functions. Since block erase functions do not know the block length (it's not specified in any standard), block erase functions now get an additional parameter blocklen. This enables flashrom to verify the erase result for block erase functions at correct boundaries. Unchecked erase is bad and can lead to problems nobody can understand. Signed-off-by: Carl-Daniel Hailfinger c-d.hailfinger.devel.2...@gmx.net Acked-by: Uwe Hermann u...@hermann-uwe.de This was r630. Regards, Carl-Daniel -- http://www.hailfinger.org/ -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Which file should I burn?
I can't find EEPROM chip while running flashrom from the systemrescue LiveCD... it said No EEPROM/Flash device foundis it depend on the motherboard? what is the similar chip to force ? my chip is 49LF004 and chipset is north=intel 82810 and south = intel 82801 Thanks --- On Tue, 6/23/09, ron minnich rminn...@gmail.com wrote: From: ron minnich rminn...@gmail.com Subject: Re: [coreboot] Which file should I burn? To: Rick Ant rick_...@yahoo.com Cc: coreboot@coreboot.org Date: Tuesday, June 23, 2009, 10:51 PM don't forget the wonderfulness of earlyprintk when booting a linux kernel and you are not sure if it is right. you just append it to the command line. Here is one example. I use 'keep' when I'm really being paranoid. earlyprintk=ttyS0,115200,keep ron -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Which file should I burn?
I certainly hope you have a backup flash part. Do you? You really need to have three parts, and two of them need to be a copy of the factory bios. ron -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] coreboot for C3/CN400 (Luke)
Hi Guys, I've made a bit of progress, now getting beyond the basic RAM init. Uncompresses and starts to run the coreboot core. Not worth posting a patch unless anyone really wants to see it. Let me know. Jon -Original Message- From: Peter Stuge [mailto:pe...@stuge.se] Sent: 23 June 2009 12:52 To: Harrison, Jon (SELEX GALILEO, UK) Subject: Re: [coreboot] coreboot for VX800+Nano *** WARNING *** This message has originated outside your organisation, either from an external partner or the Global Internet. Keep this in mind if you answer this message. Harrison, Jon (SELEX GALILEO, UK) wrote: Thx, Peter. I understand that there are not very many resources available for Luke, it might simply be too old. Hope something can come out of it though. //Peter SELEX Sensors and Airborne Systems Limited Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14 3EL A company registered in England Wales. Company no. 02426132 This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] coreboot for C3/CN400 (Luke)
On 24.06.2009 12:17, Harrison, Jon (SELEX GALILEO, UK) wrote: I've made a bit of progress, now getting beyond the basic RAM init. RAM init is one of the big obstacles in finishing a port. If RAM works reliably for you, please send your code to the list. Regards, Carl-Daniel -- http://www.hailfinger.org/ -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] [RFC] Mailing list and IRC split
Hi, AFAICS the time has come to give flashrom its own mailing list (maybe flash...@coreboot.org) and IRC channel (irc.freenode.net/#flashrom). I do realize this has been brought up in the past, but while I was sceptical back then, I realized that the times have changed in the last few months. The release of flashrom 0.9.0 has increased both visiblity and user base, resulting in a sizable portion of list and chat traffic to be related to flashrom. Some of us are only interested in coreboot, while others are only interested in flashrom. Since filtering mails according to subject can introduce lots of errors, having two separate lists would make watching one one of flashrom/coreboot easier. List traffic over the last few years: 2007: 29 mails/day 2008: 41 mails/day 2009: 36 mails/day Although the list traffic has not yet reached linux-kernel levels, it is already too much to read in full. I hope splitting the lists will allow people to concentrate on their personal area of interest and also encourage more reviews. After all, if you have to read less mails, you can respond to more of them. One issue to solve is how we want to handle flashrom success/failure reports sent to flash...@coreboot.org. Right now they end up on an unmoderated private list. After the change, they'd get a message that the list is moderated. This might discourage users, so we have to think of a nice moderation message, possibly mentioning that emergency help for broken flash is available on IRC. The suggested way forward is outlined below: 1. Register #flashrom on irc.freenode.net (done) 2. Invite parties interested in flashrom to join #flashrom besides #coreboot. 3. Pre-Announce the mailing list split with the following text: coreboot@coreboot.org will be split in two lists. flash...@coreboot.org is where flashrom development and usage will be discussed. coreboot@coreboot.org will carry all traffic not related to flashrom. coreboot@coreboot.org list members will be subscribed automatically to flash...@coreboot.org. If you are only interested in either coreboot or flashrom, feel free to unsubscribe from either list once the split is done. 4. Wait a week for protests etc. 5. Create a new mailing list flash...@coreboot.org with the same subscribers as coreb...@coreboot.org. 6. Announce the mailing list split with the following text: coreboot@coreboot.org has been split in two lists. flash...@coreboot.org is where flashrom development and usage are discussed from now own. coreboot@coreboot.org carries all traffic not related to flashrom. coreboot@coreboot.org list members have been subscribed automatically to flash...@coreboot.org. If you are only interested in either coreboot or flashrom, feel free to unsubscribe from either list. Thoughts? Flames? Regards, Carl-Daniel -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Intel Eagle Height evaluation board support
Hi, On Tue, Jun 23, 2009 at 8:42 PM, Thomas JOURDANthomas.jour...@gmail.com wrote: * vga rom - The evaluation board comes with a PCIe 1x Matrox G550 graphics card. Coreboot fails to execute the vga rom (either x86emu, yabel or real mode). There is an exception 0x06 and everything will freeze. It could be the loadall instruction i would be interested in a log with CONFIG_YABEL_DEBUG_FLAGS=0x9 to see whats happening in yabel... Regards, Patty -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Is PI-AM2RS780G supported ?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 David Hendricks wrote: On Wed, Jun 24, 2009 at 12:30 AM, David Hendricks dhend...@google.comwrote: On Tue, Jun 23, 2009 at 2:28 AM, Alois Schlögl alois.schlo...@tugraz.atwrote: The reason for asking is the bug as described here: http://bugzilla.kernel.org/show_bug.cgi?id=13573 The bug is affecting my research at the university. It was suggested that a Bios-update could solve the problem. IIRC you can disable thermal throttling, but it's usually not a good idea if you expect to keep your machine running with reasonable performance under load. If the vendor BIOS had the proper tables (See section 2.4.2 on P-States in the AMD BIOS and Kernel Developer's Guide for Fam10 processors), your CPU would slow itself down to avoid generating too much heat. If you disable thermal throttling and continue to run your workload, your CPU will hit Tjunction at around 116 degrees C and shut itself off abruptly, possibly after physical damage has been done to the CPU or the socket. I would suggest starting with something much simpler, like making sure you have quality thermal transfer compound applied in the proper quantity for your CPUs. I know it sounds stupid, but I have seen many machines from many datacenters with very powerful rack cooling overheat under heavy loads due to improperly applied thermal grease. There are many tutorials and videos on how to do this. Make sure you clean off the old thermal grease first with a high-concentration isopropyl alcohol (90%) first. Oh, and while you're at it make sure the heatsinks are securely fastened. After you re-apply thermal grease, tighten the screws such that they will not turn any more. The mounting points on the motherboard will ensure the maximum threshold is not exceeded, though I suggest tightening one about 80-90%, then the second one 100%, then finish the first one to apply the pressure more evenly. Just another very silly thing that can cause unexpected behavior under heavy workloads... Thanks for these hints. That sound very reasonable to me. If understood you correctly, the shutdown occurs because the current bios is missing the _PSS table. Update the bios would resolve this, and re-apply thermal grease, would throttle the CPU later or not at all. In order to update the bios, I tried followed also this approach http://ubuntuforums.org/showthread.php?p=2195208 as well as this http://manual.sidux.com/en/bios-freedos-en.htm The final test showed that my USB-stick is bootable. Unfortunately, the system never boots from USB. I changed 1st, 2nd and 3rd boot device to USB-floppy, USB-ZIP, USB-CDROM and turned off HDD, no boot device was found. I guess this is another problem of the current bios. Therefore, coreboot would be really appreciated. Carl-Daniel Hailfinger wrote: Judging from experience, the legal review happens faster if we can show more (or more interesting) reference customers, so if you plan to use coreboot on 780G/SB700 as part of university research, we'd tell AMD about this immediately. Carl, you can tell AMD, that I'm working on some numerical methods that can efficiently handle missing values (encoded as NaN) http://hci.tugraz.at/schloegl/matlab/NaN/ http://hci.tugraz.at/schloegl/matlab/tsa/ These methods are quite useful in various applications of biomedical signal processing (like electroencephalography) http://biosig.sourceforge.net/ http://hci.tugraz.at/schloegl/ These methods could be useful for Brain-Computer interface research, and for a better understanding of the human brain. Perhaps, the methods will be also useful in other application areas. Best regards, Alois -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkpCGuAACgkQzSlbmAlvEIjr/gCgk/7ovF3c2PGAvvbBiot5rkOV E7oAoMBkIfExZAZ51QgOkqzxDdXmAXlI =C2g+ -END PGP SIGNATURE- -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Intel Eagle Height evaluation board support
Hi Thanks. As I glanced through I didn't see any copyright lines from you. It would speed the reviewing process if you sent the patch as a patch against an existing board so we could see what you're changing. I realize that's more work for you. I'm not sure to understand what form you expect the patch to have ? You could try having SeaBIOS enable your ROM. There have been several cases where SeaBIOS was less picky than the others. http://www.coreboot.org/SeaBIOS I forgot to mention that also tried seabios without success. I attached a log file for seabios. Thomas coreboot-2.0.0-r7:27M 2009-06-24 starting... Ram1.00 Ram2.00 Ram3 Starting SDRAM Enable DIMM 00 DIMM 02 DIMM 04 DIMM 06 ODT Value = 3132 Receive enable A = 05050506, Receive enable B = Clearing memory Waiting for mem complete Done Ram4 Jumping to image. Check CBFS header at fffeffd0 magic is 4f524243 Found CBFS header at fffeffd0 Check fallback/payload Check fallback/coreboot_ram Stage: load @ 1048576/262144 bytes, enter @ 10 Stage: done loading. Jumping to image. coreboot-2.0.0-r7:27M 2009-06-24 booting... clocks_per_usec: 1801 Enumerating buses... Show all devs...Before Phase 3. Root Device: enabled 1, 0 resources PCI_DOMAIN: : enabled 1, 0 resources PCI: 00:00.0: enabled 1, 0 resources PCI: 00:00.1: enabled 1, 0 resources PCI: 00:01.0: enabled 1, 0 resources PCI: 00:02.0: enabled 1, 0 resources PCI: 00:03.0: enabled 1, 0 resources PCI: 00:1c.0: enabled 1, 0 resources PCI: 00:1c.1: enabled 0, 0 resources PCI: 00:1c.2: enabled 0, 0 resources PCI: 00:1c.3: enabled 0, 0 resources PCI: 00:1d.0: enabled 1, 0 resources PCI: 00:1d.1: enabled 1, 0 resources PCI: 00:1d.7: enabled 1, 0 resources PCI: 00:1e.0: enabled 1, 0 resources PCI: 00:1e.2: enabled 0, 0 resources PCI: 00:1e.3: enabled 0, 0 resources PCI: 00:1f.0: enabled 1, 0 resources PNP: 004e.4: enabled 1, 2 resources PNP: 004e.5: enabled 1, 2 resources PNP: 002e.0: enabled 0, 3 resources PNP: 002e.2: enabled 0, 2 resources PNP: 002e.3: enabled 0, 3 resources PNP: 002e.4: enabled 0, 2 resources PNP: 002e.7: enabled 1, 4 resources PNP: 002e.a: enabled 0, 1 resources PCI: 00:1f.2: enabled 1, 0 resources PCI: 00:1f.3: enabled 1, 0 resources PCI: 00:1f.4: enabled 1, 0 resources APIC_CLUSTER: 0: enabled 1, 0 resources APIC: 00: enabled 1, 0 resources Compare with tree... Root Device: enabled 1, 0 resources PCI_DOMAIN: : enabled 1, 0 resources PCI: 00:00.0: enabled 1, 0 resources PCI: 00:00.1: enabled 1, 0 resources PCI: 00:01.0: enabled 1, 0 resources PCI: 00:02.0: enabled 1, 0 resources PCI: 00:03.0: enabled 1, 0 resources PCI: 00:1c.0: enabled 1, 0 resources PCI: 00:1c.1: enabled 0, 0 resources PCI: 00:1c.2: enabled 0, 0 resources PCI: 00:1c.3: enabled 0, 0 resources PCI: 00:1d.0: enabled 1, 0 resources PCI: 00:1d.1: enabled 1, 0 resources PCI: 00:1d.7: enabled 1, 0 resources PCI: 00:1e.0: enabled 1, 0 resources PCI: 00:1e.2: enabled 0, 0 resources PCI: 00:1e.3: enabled 0, 0 resources PCI: 00:1f.0: enabled 1, 0 resources PNP: 004e.4: enabled 1, 2 resources PNP: 004e.5: enabled 1, 2 resources PNP: 002e.0: enabled 0, 3 resources PNP: 002e.2: enabled 0, 2 resources PNP: 002e.3: enabled 0, 3 resources PNP: 002e.4: enabled 0, 2 resources PNP: 002e.7: enabled 1, 4 resources PNP: 002e.a: enabled 0, 1 resources PCI: 00:1f.2: enabled 1, 0 resources PCI: 00:1f.3: enabled 1, 0 resources PCI: 00:1f.4: enabled 1, 0 resources APIC_CLUSTER: 0: enabled 1, 0 resources APIC: 00: enabled 1, 0 resources PCI_DOMAIN: enabled APIC_CLUSTER: 0 enabled PCI: pci_scan_bus for bus 00 PCI: 00:00.0 [8086/35b0] enabled PCI: 00:00.1 [8086/35b1] enabled PCI: 00:00.2 [8086/35b4] enabled PCI: 00:01.0 [8086/35b5] enabled PCI: 00:02.0 [8086/35b6] enabled PCI: 00:03.0 [8086/35b7] enabled PCI: 00:08.0 [8086/35c8] enabled PCI: 00:1c.0 subbordinate bus PCI Express PCI: 00:1c.0 [8086/2690] enabled PCI: 00:1d.0 [8086/2688] enabled PCI: 00:1d.1 [8086/2689] enabled PCI: 00:1d.7 [8086/268c] enabled PCI: 00:1e.0 [8086/244e] enabled PCI: 00:1f.0 [8086/2670] enabled PCI: 00:1f.2 [8086/2681] enabled PCI: 00:1f.3 [8086/269b] enabled PCI: 00:1f.4 [8086/269d] enabled PCI: 00:1e.2 PCI: 00:1e.3 PCI: Left over static devices. Check your mainboard Config.lb pcie porta 0x76: 1001 PCI: pci_scan_bus for bus 01 PCI: pci_scan_bus returning with max=001 pcie porta 0x76: 1011 PCI: pci_scan_bus for bus 02 PCI: 02:00.0 subbordinate PCI PCI: 02:00.0 [104c/8231] enabled PCI: pci_scan_bus for bus 03 PCI: 03:00.0 [102b/2527] enabled PCI: pci_scan_bus returning with max=003 PCI: pci_scan_bus returning with max=003 PCIe: tuning PCI: 02:00.0 PCI: pci_scan_bus for bus 04 PCI: pci_scan_bus returning with max=004 PCI: pci_scan_bus for bus 05 PCI: pci_scan_bus returning with max=005 PNP: 004e.4 enabled PNP: 004e.5 enabled Found SMSC Super I/O (ID=0x14, rev=0x04) PNP: 002e.0 disabled PNP: 002e.2 disabled PNP: 002e.3 disabled PNP: 002e.4 disabled PNP: 002e.7
Re: [coreboot] coreboot for C3/CN400 (Luke)
Spew ::: coreboot-2.0.0-r1M-epia_n-fallback Wed Jun 24 12:06:55 BST 2009 starting... In auto.c:main() Enabling mainboard devices Enable F-ROM Shadow RAM Setup CPU Interface CN400 RAM init starting Low Bond 50 High Bond 79 Setting DQS delay6b CN400 Init done doing early_mtrr Leaving auto.c:main() Uncompressing coreboot to RAM. src=fffef400 dst=4000 Uncompressing image to RAM. image length = 00015318 Jumping to image. coreboot-2.0.0-r1M-epia_n-fallback Wed Jun 24 12:06:55 BST 2009 booting... Calibrating delay loop... end 9469c158, start 270bc472 32-bit delta 1749 calibrate_tsc 32-bit result is 1749 clocks_per_usec: 1749 Enumerating buses... Show all devs...Before Phase 3. Root Device: enabled 1, 0 resources APIC_CLUSTER: 0: enabled 1, 0 resources APIC: 00: enabled 1, 0 resources PCI_DOMAIN: : enabled 1, 0 resources PCI: 00:00.0: enabled 1, 0 resources PCI: 00:00.1: enabled 1, 0 resources PCI: 00:00.2: enabled 1, 0 resources PCI: 00:00.3: enabled 1, 0 resources PCI: 00:00.4: enabled 1, 0 resources PCI: 00:00.7: enabled 1, 0 resources PCI: 00:01.0: enabled 1, 0 resources PCI: 00:0f.0: enabled 1, 0 resources PCI: 00:10.0: enabled 1, 0 resources PCI: 00:10.1: enabled 1, 0 resources PCI: 00:10.2: enabled 1, 0 resources PCI: 00:10.3: enabled 1, 0 resources PCI: 00:10.4: enabled 1, 0 resources PCI: 00:11.0: enabled 1, 0 resources PNP: 002e.0: enabled 0, 3 resources PNP: 002e.1: enabled 0, 3 resources PNP: 002e.2: enabled 1, 2 resources PNP: 002e.3: enabled 0, 2 resources PNP: 002e.6: enabled 0, 1 resources PNP: 002e.7: enabled 0, 1 resources PNP: 002e.8: enabled 0, 1 resources PNP: 002e.9: enabled 0, 1 resources PNP: 002e.a: enabled 0, 1 resources PNP: 002e.b: enabled 1, 1 resources PCI: 00:11.5: enabled 0, 0 resources PCI: 00:12.0: enabled 1, 0 resources Compare with tree... Root Device: enabled 1, 0 resources APIC_CLUSTER: 0: enabled 1, 0 resources APIC: 00: enabled 1, 0 resources PCI_DOMAIN: : enabled 1, 0 resources PCI: 00:00.0: enabled 1, 0 resources PCI: 00:00.1: enabled 1, 0 resources PCI: 00:00.2: enabled 1, 0 resources PCI: 00:00.3: enabled 1, 0 resources PCI: 00:00.4: enabled 1, 0 resources PCI: 00:00.7: enabled 1, 0 resources PCI: 00:01.0: enabled 1, 0 resources PCI: 00:0f.0: enabled 1, 0 resources PCI: 00:10.0: enabled 1, 0 resources PCI: 00:10.1: enabled 1, 0 resources PCI: 00:10.2: enabled 1, 0 resources PCI: 00:10.3: enabled 1, 0 resources PCI: 00:10.4: enabled 1, 0 resources PCI: 00:11.0: enabled 1, 0 resources PNP: 002e.0: enabled 0, 3 resources PNP: 002e.1: enabled 0, 3 resources PNP: 002e.2: enabled 1, 2 resources PNP: 002e.3: enabled 0, 2 resources PNP: 002e.6: enabled 0, 1 resources PNP: 002e.7: enabled 0, 1 resources PNP: 002e.8: enabled 0, 1 resources PNP: 002e.9: enabled 0, 1 resources PNP: 002e.a: enabled 0, 1 resources PNP: 002e.b: enabled 1, 1 resources PCI: 00:11.5: enabled 0, 0 resources PCI: 00:12.0: enabled 1, 0 resources scan_static_bus for Root Device In cn400 enable_dev for device APIC_CLUSTER: 0. APIC_CLUSTER: 0 enabled In cn400 enable_dev for device PCI_DOMAIN: . Finding PCI configuration type. PCI: Using configuration type 1 PCI_DOMAIN: enabled PCI_DOMAIN: scanning... Entering cn400 pci_domain_scan_bus. PCI: pci_scan_bus for bus 00 In cn400 enable_dev for device PCI: 00:00.0. PCI: 00:00.0 [1106/0259] ops PCI: 00:00.0 [1106/0259] enabled In cn400 enable_dev for device PCI: 00:00.1. PCI: 00:00.1 [1106/1259] enabled In cn400 enable_dev for device PCI: 00:00.2. PCI: 00:00.2 [1106/2259] enabled In cn400 enable_dev for device PCI: 00:00.3. PCI: 00:00.3 [1106/3259] ops PCI: 00:00.3 [1106/3259] enabled In cn400 enable_dev for device PCI: 00:00.4. PCI: 00:00.4 [1106/4259] enabled PCI: 00:00.5, bad id 0x PCI: 00:00.6, bad id 0x In cn400 enable_dev for device PCI: 00:00.7. PCI: 00:00.7 [1106/7259] enabled In cn400 enable_dev for device PCI: 00:01.0. PCI: 00:01.0 [1106/b198] bus ops PCI: 00:01.0 [1106/b198] enabled PCI: 00:02.0, bad id 0x PCI: 00:03.0, bad id 0x PCI: 00:04.0, bad id 0x PCI: 00:05.0, bad id 0x PCI: 00:06.0, bad id 0x PCI: 00:07.0, bad id 0x PCI: 00:08.0, bad id 0x PCI: 00:09.0, bad id 0x PCI: 00:0a.0, bad id 0x PCI: 00:0b.0, bad id 0x PCI: 00:0c.0, bad id 0x PCI: 00:0d.0, bad id 0x PCI: 00:0e.0, bad id 0x PCI: 00:0f.0 [1106/3149] ops PCI: 00:0f.0 [1106/3149] enabled malloc Enter, size 1100, free_mem_ptr 0001e000 malloc 0001e000 PCI: 00:0f.1 [1106/0571] ops PCI: 00:0f.1 [1106/0571] enabled PCI: 00:0f.2, bad id 0x PCI: 00:0f.3, bad id 0x PCI: 00:0f.4, bad id 0x PCI: 00:0f.5, bad id 0x PCI: 00:0f.6, bad id 0x PCI: 00:0f.7, bad id 0x PCI: 00:10.0 [1106/3038] enabled PCI: 00:10.1 [1106/3038] enabled PCI: 00:10.2 [1106/3038] enabled PCI: 00:10.3 [1106/3038] enabled PCI: 00:10.4 [1106/3104] enabled malloc Enter, size
Re: [coreboot] Intel Eagle Height evaluation board support
Hi Pattrick With Yabel I have the following error : CBFS: Could not find file pci102b,2527.rom In cbfs, rom address for PCI: 03:00.0 = On card, rom address for PCI: 03:00.0 = fe80 copying VGA ROM Image from fe80 to 0xc, 0x9000 bytes Unexpected Exception: 0 @ 10:0011bfa1 - Halting Code: 0 eflags: 00010046 eax: 0001 ebx: 0061 ecx: edx: edi: 0003 esi: ebp: 00155abc esp: 00155a98 Setting CONFIG_YABEL_DEBUG_FLAGS to 0x9 (or 0x31FF) won't print more traces. Regards, Thomas 2009/6/24 Pattrick Hueper phue...@hueper.net: Hi, On Tue, Jun 23, 2009 at 8:42 PM, Thomas JOURDANthomas.jour...@gmail.com wrote: * vga rom - The evaluation board comes with a PCIe 1x Matrox G550 graphics card. Coreboot fails to execute the vga rom (either x86emu, yabel or real mode). There is an exception 0x06 and everything will freeze. It could be the loadall instruction i would be interested in a log with CONFIG_YABEL_DEBUG_FLAGS=0x9 to see whats happening in yabel... Regards, Patty -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Intel Eagle Height evaluation board support
I forgot to mention that on the IRC, someone suspected a missing timer setup leading to a division by zero. This might help. Thomas 2009/6/24 Thomas JOURDAN thomas.jour...@gmail.com: Hi Pattrick With Yabel I have the following error : CBFS: Could not find file pci102b,2527.rom In cbfs, rom address for PCI: 03:00.0 = On card, rom address for PCI: 03:00.0 = fe80 copying VGA ROM Image from fe80 to 0xc, 0x9000 bytes Unexpected Exception: 0 @ 10:0011bfa1 - Halting Code: 0 eflags: 00010046 eax: 0001 ebx: 0061 ecx: edx: edi: 0003 esi: ebp: 00155abc esp: 00155a98 Setting CONFIG_YABEL_DEBUG_FLAGS to 0x9 (or 0x31FF) won't print more traces. Regards, Thomas 2009/6/24 Pattrick Hueper phue...@hueper.net: Hi, On Tue, Jun 23, 2009 at 8:42 PM, Thomas JOURDANthomas.jour...@gmail.com wrote: * vga rom - The evaluation board comes with a PCIe 1x Matrox G550 graphics card. Coreboot fails to execute the vga rom (either x86emu, yabel or real mode). There is an exception 0x06 and everything will freeze. It could be the loadall instruction i would be interested in a log with CONFIG_YABEL_DEBUG_FLAGS=0x9 to see whats happening in yabel... Regards, Patty -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [RFC] Mailing list and IRC split
On Wed, Jun 24, 2009 at 12:50:01PM +0200, Carl-Daniel Hailfinger wrote: Although the list traffic has not yet reached linux-kernel levels, it is already too much to read in full. I hope splitting the lists will allow people to concentrate on their personal area of interest and also encourage more reviews. After all, if you have to read less mails, you can respond to more of them. ACK, several other developers have expressed they'd like to split off flashrom into an extra list. One issue to solve is how we want to handle flashrom success/failure reports sent to flash...@coreboot.org. Right now they end up on an unmoderated private list. After the change, they'd get a message that the list is moderated. Fine with me. As discussed in the past I think it's crucial that this stuff is public (and no, I don't give a shit about spam. I also don't think any users who are willing to send reports will refrain from doing so just because their email may become public that way). Maybe there could be a filter like the mail has to start with [flashrom] otherwise it'll be moderated or so? Can this be done with stock mailman? Those mails would go in unmoderated, all others be moderated. Anyway, this is no requirement, we can go ahead and make a new list even without the above setup. a nice moderation message, possibly mentioning that emergency help for broken flash is available on IRC. Yes, definately. The suggested way forward is outlined below: 1. Register #flashrom on irc.freenode.net (done) 1.5: Document it on the flashrom page and on coreboot.org/IRC. 2. Invite parties interested in flashrom to join #flashrom besides #coreboot. 3. Pre-Announce the mailing list split with the following text: coreboot@coreboot.org will be split in two lists. flash...@coreboot.org is where flashrom development and usage will be discussed. coreboot@coreboot.org will carry all traffic not related to flashrom. coreboot@coreboot.org list members will be subscribed automatically to flash...@coreboot.org. If you are only interested in either coreboot or flashrom, feel free to unsubscribe from either list once the split is done. Looks good. Moving over all current subscribers is very important IMO. Everyone is of course free to unsubscribe if wanted. Uwe. -- http://www.hermann-uwe.de | http://www.holsham-traders.de http://www.crazy-hacks.org | http://www.unmaintained-free-software.org -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Intel Eagle Height evaluation board support
On Wed, Jun 24, 2009 at 6:34 AM, Thomas JOURDAN thomas.jour...@gmail.comwrote: Hi Thanks. As I glanced through I didn't see any copyright lines from you. It would speed the reviewing process if you sent the patch as a patch against an existing board so we could see what you're changing. I realize that's more work for you. I'm not sure to understand what form you expect the patch to have ? It's not an expectation, just a suggestion to speed the review process. I haven't looked which board you based your port on, but lets pretend it was the Kontron board. You could supply a patch for review that turned the Kontron board into your board. That patch should be _much_ smaller and easier to review. Then we could do something like mkdir src/mainboard/intel/eagleheights svn cp src/mainboard/kontron/986lcd-m/* src/mainboard/intel/eagleheights apply your patch commit Thanks, Myles -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [RFC] Mailing list and IRC split
On 24.06.2009 15:03, Uwe Hermann wrote: On Wed, Jun 24, 2009 at 12:50:01PM +0200, Carl-Daniel Hailfinger wrote: One issue to solve is how we want to handle flashrom success/failure reports sent to flash...@coreboot.org. Right now they end up on an unmoderated private list. After the change, they'd get a message that the list is moderated. Fine with me. As discussed in the past I think it's crucial that this stuff is public (and no, I don't give a shit about spam. I also don't think any users who are willing to send reports will refrain from doing so just because their email may become public that way). Agreed. Maybe there could be a filter like the mail has to start with [flashrom] otherwise it'll be moderated or so? Can this be done with stock mailman? Those mails would go in unmoderated, all others be moderated. No idea. If the mailman moderation messages could be changed to include a confirm link besides the cancel link, that should already combat most of the spam and still allow fast posting. The suggested way forward is outlined below: 1. Register #flashrom on irc.freenode.net (done) 1.5: Document it on the flashrom page and on coreboot.org/IRC. Done. What do you think? Regards, Carl-Daniel -- http://www.hailfinger.org/ -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Intel Eagle Height evaluation board support
You could try having SeaBIOS enable your ROM. There have been several cases where SeaBIOS was less picky than the others. http://www.coreboot.org/SeaBIOS I forgot to mention that also tried seabios without success. I attached a log file for seabios. I don't see the lines setting the VGA bridge bits. It should say something like Allocating VGA resource PCI 3:00.0 and then list the bridges. Is your log level debug? Do you have CONFIG_CONSOLE_VGA set? Thanks, Myles -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [RFC] Mailing list and IRC split
Selon Uwe Hermann u...@hermann-uwe.de: On Wed, Jun 24, 2009 at 12:50:01PM +0200, Carl-Daniel Hailfinger wrote: Although the list traffic has not yet reached linux-kernel levels, it is already too much to read in full. I hope splitting the lists will allow people to concentrate on their personal area of interest and also encourage more reviews. After all, if you have to read less mails, you can respond to more of them. ACK, several other developers have expressed they'd like to split off flashrom into an extra list. One issue to solve is how we want to handle flashrom success/failure reports sent to flash...@coreboot.org. Right now they end up on an unmoderated private list. After the change, they'd get a message that the list is moderated. Fine with me. As discussed in the past I think it's crucial that this stuff is public (and no, I don't give a shit about spam. I also don't think any users who are willing to send reports will refrain from doing so just because their email may become public that way). I'm one of flashrom reader, but less interested with coreboot (sorry for the team), so, fine for me too. Maybe there could be a filter like the mail has to start with [flashrom] otherwise it'll be moderated or so? Can this be done with stock mailman? Those mails would go in unmoderated, all others be moderated. Anyway, this is no requirement, we can go ahead and make a new list even without the above setup. a nice moderation message, possibly mentioning that emergency help for broken flash is available on IRC. Yes, definately. The suggested way forward is outlined below: 1. Register #flashrom on irc.freenode.net (done) 1.5: Document it on the flashrom page and on coreboot.org/IRC. 2. Invite parties interested in flashrom to join #flashrom besides #coreboot. 3. Pre-Announce the mailing list split with the following text: coreboot@coreboot.org will be split in two lists. flash...@coreboot.org is where flashrom development and usage will be discussed. coreboot@coreboot.org will carry all traffic not related to flashrom. coreboot@coreboot.org list members will be subscribed automatically to flash...@coreboot.org. If you are only interested in either coreboot or flashrom, feel free to unsubscribe from either list once the split is done. Looks good. Moving over all current subscribers is very important IMO. Everyone is of course free to unsubscribe if wanted. Agreed too ;-) Stephan. Uwe. -- http://www.hermann-uwe.de | http://www.holsham-traders.de http://www.crazy-hacks.org | http://www.unmaintained-free-software.org -- 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] EP80579 Mainboard support
Good afternoon gents, The ECC enable code has been fixed. It does enable the ECC when the DIMM has ECC. I did enable the RAM check and indeed this showed miserable results. I've been trying to figure out the correct settings but so far they are not there! Trying a few BSEL/VSEL jumper settings with a couple of different DIMM we have here showed some decent results, the value I read back starts to look as the value I send. I've tried a reverse engineer approach. Plug a DIMM into the system and launch Linux with the legacy BIOS. lspci -xxx then shows me the IMCH BAR and implicitly the settings doctored by the legacy BIOS. The first try I've done was to try the r-e DRT0/DRT1 in the coreboot RAM init code. Not much differences so far. But anyway I've seen quite a lot of difference around the ODT register and such. So there is still some hope. I will keep you guys updated as soon it is moving forward. One thing I cannot figure out so far, is what the peripheral 0.8.0 is. This seems to be an non existing peripheral, this is the assumption I make so far. It is not documented in the EP80579 documentation. I am referring to raminit_ep80579.c function spd_set_drt_attributes(). val = (magic[index]); print_debug(magic = ); print_debug_hex32(val); print_debug(\r\n); pci_write_config32(PCI_DEV(0, 0x08, 0), 0xcc, val); So what is this magic value about and what the devnbr8 on bus0 is are the thing I would love to hear from you guys. It is clear that the magic value is different for given DDR memory frequency. Thank you, Arnaud Ed Swierk wrote: On Mon, Jun 22, 2009 at 5:06 AM, Arnaud Mayearnaud.m...@4dsp.com wrote: I've narrowed down the problem to the mtrr.c file in src/cpu/x86/mtrr/ in the function set_fixed_mtrrs(). The first time disable_cache() is called, the CPU gets lost. It either hang or jump back to some code to hang a bit after. Am not 100% sure but I would say that as soon we disable the cache, the processor is forced to execute from RAM and not from the cache itself, having this strange behavior here can still mean the memory controller settings are not correct, right? That does seems like symptom of memory controller misconfiguration. I'd recommend you proceed by disabling ECC (comment out the Set the ECC mode line in raminit_ep80579.c) and enabling the ram_fill() and ram_verify() steps in auto.c. Adjust the parameters to fill and verify the entire memory range. This is a very simple test that should pass reliably before you try anything fancy like booting a payload. --Ed * * -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] #142: remove #warnings in the code
#142: remove #warnings in the code -+-- Reporter: myles | Owner: somebody Type: defect | Status: new Priority: major | Milestone: Component: coreboot |Version: v2 Keywords: | Dependencies: Patchstatus: there is no patch | -+-- #warnings in the code should be converted to tickets in trac, or fixed. Compiler warnings don't seem to be useful to get things fixed. They also obscure real warnings. The medium-term goal would be to have warning-free compilation. After that -Werror would be nice. It seems like a small thing to ask that code compile without warnings. -- Ticket URL: http://tracker.coreboot.org/trac/coreboot/ticket/142 coreboot http://www.coreboot.org/ -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] flashrom licensing
Hi, I wanted to add support for the TotalPhase Cheetah to flashrom, but I have to use the proprietary driver library for that. I'm not aware of any free alternative to that driver, so there may be a conflict with the GPL. If the Cheetah driver library is considered to be a system library, the GPL allows linking against that library. If the Cheetah driver library is not considered to be a system library, I need to add an exception for that library to my Cheetah external flasher driver. However, since my driver would be part of flashrom, I have no idea if I would have to get permission from all flashrom authors for that exception. The GPL FAQ of the FSF mentions that simply adding a free software wrapper above the proprietary library is not sufficient, but having process separation (calling another program via the command line) would be OK. Since external flasher drivers have to maintain state, this essentially means I'd have to add shared memory or socket trickery, resulting in slow, buggy and unreadable code. One of the possible solutions would be to say that driver libraries for external hardware which are already installed before installing flashrom are considered to be system libraries. (The problem is that the Cheetah driver library has internally conflicting licenses, some of which suggest linking GPL code against it is not allowed. I (or maybe someone with more leverage) will try to address this with TotalPhase.) Regards, Carl-Daniel -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Intel Eagle Height evaluation board support
Hm... thats strange... yabel should print some output before it even touches the copied ROM... did you try a clean rebuild after changing the CONFIG values ? Pattrick On Wed, Jun 24, 2009 at 2:40 PM, Thomas JOURDANthomas.jour...@gmail.com wrote: Hi Pattrick With Yabel I have the following error : CBFS: Could not find file pci102b,2527.rom In cbfs, rom address for PCI: 03:00.0 = On card, rom address for PCI: 03:00.0 = fe80 copying VGA ROM Image from fe80 to 0xc, 0x9000 bytes Unexpected Exception: 0 @ 10:0011bfa1 - Halting Code: 0 eflags: 00010046 eax: 0001 ebx: 0061 ecx: edx: edi: 0003 esi: ebp: 00155abc esp: 00155a98 Setting CONFIG_YABEL_DEBUG_FLAGS to 0x9 (or 0x31FF) won't print more traces. Regards, Thomas 2009/6/24 Pattrick Hueper phue...@hueper.net: Hi, On Tue, Jun 23, 2009 at 8:42 PM, Thomas JOURDANthomas.jour...@gmail.com wrote: * vga rom - The evaluation board comes with a PCIe 1x Matrox G550 graphics card. Coreboot fails to execute the vga rom (either x86emu, yabel or real mode). There is an exception 0x06 and everything will freeze. It could be the loadall instruction i would be interested in a log with CONFIG_YABEL_DEBUG_FLAGS=0x9 to see whats happening in yabel... Regards, Patty -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] flashrom licensing
Carl-Daniel Hailfinger wrote: I wanted to add support for the TotalPhase Cheetah to flashrom, but I have to use the proprietary driver library for that. I'm not aware of any free alternative to that driver, so there may be a conflict with the GPL. There would be no issue, if flasher drivers were not linked with flashrom, but rather separate processes implementing a well-defined interface. Maybe you remember the discussion about flashrom plugins. If the Cheetah driver library is considered to be a system library, the GPL allows linking against that library. Cheetah is not essential for the system where flashrom is running so I do not think that can be argumented successfully. //Peter -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Intel Eagle Height evaluation board support
On Wed, Jun 24, 2009 at 8:43 AM, Thomas JOURDANthomas.jour...@gmail.com wrote: I forgot to mention that on the IRC, someone suspected a missing timer setup leading to a division by zero. This might help. In the past, when trying to figure out a VGA ROM execution hang or errors, it has been very helpful to watch full IO tracing in the emulator to see what IOs were being accessed just before the hang. It would be interesting if you could do the same, especially if you are suspecting that some legacy part is not set up properly. I don't know the exact mechanism to do that in the emulators you are trying (or if it is possible any more), but it may be helpful to try. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] [PATCH] flashrom: Autoverify all writes, unless --noverify is used
See patch.
Tested on one board, other tests are welcome.
Uwe.
--
http://www.hermann-uwe.de | http://www.holsham-traders.de
http://www.crazy-hacks.org | http://www.unmaintained-free-software.org
Always verify write operations automatically.
Should this be undesireable because of speed reasons, --noverify can be
used to suppress an auto-verify.
Signed-off-by: Uwe Hermann u...@hermann-uwe.de
Index: flashrom.c
===
--- flashrom.c (revision 630)
+++ flashrom.c (working copy)
@@ -480,6 +480,7 @@
( -r | --read: read flash and save into file\n
-w | --write: write file into flash\n
-v | --verify:verify flash against file\n
+ -n | --noverify: don't verify flash against file\n
-E | --erase: erase flash device\n
-V | --verbose: more verbose output\n
-c | --chip chipname: probe only for specified flash chip\n
@@ -515,7 +516,7 @@
int option_index = 0;
int force = 0;
int read_it = 0, write_it = 0, erase_it = 0, verify_it = 0;
- int list_supported = 0, list_supported_wiki = 0;
+ int dont_verify_it = 0, list_supported = 0, list_supported_wiki = 0;
int operation_specified = 0;
int ret = 0, i;
@@ -524,6 +525,7 @@
{write, 0, 0, 'w'},
{erase, 0, 0, 'E'},
{verify, 0, 0, 'v'},
+ {noverify, 0, 0, 'n'},
{chip, 1, 0, 'c'},
{mainboard, 1, 0, 'm'},
{verbose, 0, 0, 'V'},
@@ -553,7 +555,7 @@
}
setbuf(stdout, NULL);
- while ((opt = getopt_long(argc, argv, rRwvVEfc:m:l:i:p:Lzh,
+ while ((opt = getopt_long(argc, argv, rRwvnVEfc:m:l:i:p:Lzh,
long_options, option_index)) != EOF) {
switch (opt) {
case 'r':
@@ -580,6 +582,9 @@
}
verify_it = 1;
break;
+ case 'n':
+ dont_verify_it = 1;
+ break;
case 'c':
chip_to_probe = strdup(optarg);
break;
@@ -779,6 +784,10 @@
exit(1);
}
+ /* Always verify write operations unless -n is used. */
+ if (write_it !dont_verify_it)
+ verify_it = 1;
+
size = flash-total_size * 1024;
buf = (uint8_t *) calloc(size, sizeof(char));
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH] flashrom: Autoverify all writes, unless --noverify is used
On Wed, Jun 24, 2009 at 17:00, Uwe Hermannu...@hermann-uwe.de wrote: See patch. Tested on one board, other tests are welcome. Uwe. -- http://www.hermann-uwe.de | http://www.holsham-traders.de http://www.crazy-hacks.org | http://www.unmaintained-free-software.org -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot I would like the noverify flag to instead disable (eg, report success without doing anything) verify_range - eg disable all verifies the code does (incl verify for erase, verify single page write's in jedec.c, etc). It would be nice if flashrom would give some sort of You have been warned-message when this is used. -- urjaman -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] flashrom licensing
On 24.06.2009 15:54, Peter Stuge wrote: Carl-Daniel Hailfinger wrote: I wanted to add support for the TotalPhase Cheetah to flashrom, but I have to use the proprietary driver library for that. I'm not aware of any free alternative to that driver, so there may be a conflict with the GPL. There would be no issue, if flasher drivers were not linked with flashrom, but rather separate processes implementing a well-defined interface. Maybe. Each driver would have to be a separate process with no common code or the same problem would just be moved to the common code of the drivers. Maybe you remember the discussion about flashrom plugins. Sorry, I can't remember that discussion and a search turned up empty. If you have a subject line or date, I'll gladly reread that discussion. If the Cheetah driver library is considered to be a system library, the GPL allows linking against that library. Cheetah is not essential for the system where flashrom is running so I do not think that can be argumented successfully. True. Now if the Cheetah drivers were shipped by default on some Linux distributions, they'd fit the FSF definition of system libraries. Oh well. Anyway, since we have FT4232H flasher support, the Cheetah is non-essential anyway. Regards, Carl-Daniel -- http://www.hailfinger.org/ -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] flashrom licensing
you might want to restart this discussion on the new list :-) Sorry, could not resist, licensing issues are the bane of my life :-) ron -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] EP80579 Mainboard support
On Wed, Jun 24, 2009 at 6:36 AM, Arnaud Mayearnaud.m...@4dsp.com wrote: I've tried a reverse engineer approach. Plug a DIMM into the system and launch Linux with the legacy BIOS. lspci -xxx then shows me the IMCH BAR and implicitly the settings doctored by the legacy BIOS. The first try I've done was to try the r-e DRT0/DRT1 in the coreboot RAM init code. Not much differences so far. But anyway I've seen quite a lot of difference around the ODT register and such. So there is still some hope. Have you tried 2T timing? This causes the memory controller to wait an extra cycle before sending a command. The delay can compensate for slight misconfiguration of other signal timing settings so it's a good place to start. Also try different RCOMP values. I have no idea what RCOMP is but I remember having to tweak it to get the memory to behave. --Ed -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH] flashrom: Autoverify all writes, unless --noverify is used
On 24.06.2009 16:00, Uwe Hermann wrote: Always verify write operations automatically. Should this be undesireable because of speed reasons, --noverify can be used to suppress an auto-verify. Signed-off-by: Uwe Hermann u...@hermann-uwe.de Tested on one board, other tests are welcome. Thanks for the patch. Acked-by: Carl-Daniel Hailfinger c-d.hailfinger.devel.2...@gmx.net I think Urja's comments make sense, but they can be addressed later. Regards, Carl-Daniel -- http://www.hailfinger.org/ -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] flashrom licensing
Carl-Daniel Hailfinger wrote: Each driver would have to be a separate process with no common code or the same problem would just be moved to the common code of the drivers. That common code could have a different license than flashrom itself. Maybe you remember the discussion about flashrom plugins. Sorry, I can't remember that discussion and a search turned up empty. If you have a subject line or date, I'll gladly reread that discussion. No single thread, my comments were late last year. Message-ID: 20081120222440.5072.qm...@stuge.se Subject: Re: [coreboot] LPCflasher Wiki Page Message-ID: 20081206221757.5445.qm...@stuge.se Subject: Re: [coreboot] Dynamic detection of Parallel Port Message-ID: 20081223182716.6256.qm...@stuge.se Subject: Re: [coreboot] Yet another idea of an SPI flash chip programmer Anyway, since we have FT4232H flasher support, the Cheetah is non-essential anyway. I assume it's a tool someone uses. It would be nice to support it. This will not be the last time this problem comes up. Finally it allows flashrom to not care about libusb or libftdi. //Peter -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Flash ROM and payload (All in the Flash ROM chip) ?
On Wednesday 24 June 2009 06:46:58 Rick Ant wrote: I try to install Flash ROM, but need zlib-devel and pciutils-devel, Install the according -dev packages. I don't know how they're called in SuSe. I'm using Suse 10.1, Can I install Coreboot + payload Linux without any Compact flash? All in the Flash ROM chip ? Yes you can, depends on how big your flashchip is. Flash parts are available with sizes up to 8Mb, and this would be enough space to put a whole kernel image busybox into it. (Maybe even a tiny x server should be possible in 8Mb.) Anyone knows where to download those files ? I don't think that there are pre-compiled images from coreboot available, which means that you need to compile your coreboot image yourself, which is pretty easy using buildrom-devel. Thanks No problem, regards Harald -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] coreboot for C3/CN400 (Luke)
Hello Jon, I'm really interested in your work on CN400 as i own an EPIA-SP, but right now I don't have the possibilities to test something on that board. Can you please be so kindly and attach the patch you posted as a file, because this would make life more easyier for testing/reviewing your patch. Hopefully I can get my hardware setup from my EPIA board working in the next days, and do some tests of your patch. (And maybe help to get it working fine.) Kind regards, Harald -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] EP80579 Mainboard support
On Wed, 24 Jun 2009 07:29:02 -0700, Ed Swierk eswi...@aristanetworks.com wrote: On Wed, Jun 24, 2009 at 6:36 AM, Arnaud Mayearnaud.m...@4dsp.com wrote: I've tried a reverse engineer approach. Plug a DIMM into the system and launch Linux with the legacy BIOS. lspci -xxx then shows me the IMCH BAR and implicitly the settings doctored by the legacy BIOS. The first try I've done was to try the r-e DRT0/DRT1 in the coreboot RAM init code. Not much differences so far. But anyway I've seen quite a lot of difference around the ODT register and such. So there is still some hope. Have you tried 2T timing? This causes the memory controller to wait an extra cycle before sending a command. The delay can compensate for slight misconfiguration of other signal timing settings so it's a good place to start. Also try different RCOMP values. I have no idea what RCOMP is but I remember having to tweak it to get the memory to behave. FYI, RCOMP (resistive compensation) is part of the Buffer Strength calculation. I far as I know there are no public docs explaining RCOMP but (hint:-)) there may possibly be patents that explain it. -- Thanks, Joseph Smith Set-Top-Linux www.settoplinux.org -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] flashrom licensing
On 24.06.2009 16:36, Peter Stuge wrote: That common code could have a different license than flashrom itself. True. However, if we reuse common code, we still have to get permission from all copyright holders. The less code it is, the better. No single thread, my comments were late last year. [...] Thanks, will read them. Carl-Daniel Hailfinger wrote Anyway, since we have FT4232H flasher support, the Cheetah is non-essential anyway. I assume it's a tool someone uses. It would be nice to support it. True. Regards, Carl-Daniel -- http://www.hailfinger.org/ -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH] flashrom: Autoverify all writes, unless --noverify is used
On Wednesday 24 June 2009 16:00:12 Uwe Hermann wrote: See patch. Tested on one board, other tests are welcome. Tested on M57SLI v2 (spi). Works fine! Acked-by: Harald Gutmann harald.gutm...@gmx.net Uwe. Harald signature.asc Description: This is a digitally signed message part. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] LInux kernel in Flash
Hello, to get a fast boot time on my mainboard I want to stick a whole kernel-image into my flashchip. The idea I want to realize is to have a kernel image in the Flash which has all drivers for my hardware compiled in. I don't want to have a busybox environment or an X-server in the flash, but just the kernel image. Booting should look as follows: * Coreboot initialization * Payload Kernel Image (64bit) * (sysv)init or upstart from harddrive Advantage: * Fast Disadvantage: * needs to reflash/rebuild the bios every kernel update What do I need except a kernel image which has all drivers compilled in? What needs to be done to get this setup working? Kind regards, Harald signature.asc Description: This is a digitally signed message part. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] LInux kernel in Flash
Harald Gutmann wrote: What do I need except a kernel image which has all drivers compilled in? What needs to be done to get this setup working? Two ways: 1. Use mkelfImage to get a payload from vmlinux See http://www.coreboot.org/Mkelfimage for download info. mkelfImage -t vmlinux-i386 --kernel=~/linux-version/vmlinux --output=~/linux.elf ~/linux.elf is your payload. Add ramdisk if you like. 2. Try using vmlinux as payload directly, it might work, we don't know It would be interesting to know if vmlinux+initramfs works: http://www.coreboot.org/Initramfs Note that you always want to use the uncompressed vmlinux to start with, and enable payload LZMA compression. LZMA compresses better than the in-kernel compression used for bzImage. //Peter pgprKavPqnmII.pgp Description: PGP signature -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] LInux kernel in Flash
On Wednesday 24 June 2009 17:54:51 Peter Stuge wrote: Harald Gutmann wrote: What do I need except a kernel image which has all drivers compilled in? What needs to be done to get this setup working? Two ways: 1. Use mkelfImage to get a payload from vmlinux See http://www.coreboot.org/Mkelfimage for download info. mkelfImage -t vmlinux-i386 --kernel=~/linux-version/vmlinux --output=~/linux.elf ~/linux.elf is your payload. Add ramdisk if you like. Good starting point, thanks! 2. Try using vmlinux as payload directly, it might work, we don't know It would be interesting to know if vmlinux+initramfs works: http://www.coreboot.org/Initramfs Note that you always want to use the uncompressed vmlinux to start with, and enable payload LZMA compression. LZMA compresses better than the in-kernel compression used for bzImage. Thanks, I think I would have missed that. One open question: How do I pass the kernel cmd-line? Is it possible to set that on kernel compile time? //Peter Regards, Harald signature.asc Description: This is a digitally signed message part. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] LInux kernel in Flash
On Wednesday 24 June 2009 18:12:33 Harald Gutmann wrote: On Wednesday 24 June 2009 17:54:51 Peter Stuge wrote: Harald Gutmann wrote: What do I need except a kernel image which has all drivers compilled in? What needs to be done to get this setup working? Two ways: 1. Use mkelfImage to get a payload from vmlinux See http://www.coreboot.org/Mkelfimage for download info. mkelfImage -t vmlinux-i386 --kernel=~/linux-version/vmlinux --output=~/linux.elf ~/linux.elf is your payload. Add ramdisk if you like. Good starting point, thanks! 2. Try using vmlinux as payload directly, it might work, we don't know It would be interesting to know if vmlinux+initramfs works: http://www.coreboot.org/Initramfs Note that you always want to use the uncompressed vmlinux to start with, and enable payload LZMA compression. LZMA compresses better than the in-kernel compression used for bzImage. Thanks, I think I would have missed that. One open question: How do I pass the kernel cmd-line? Is it possible to set that on kernel compile time? CONFIG_CMDLINE_BOOL, Built-in kernel command line in Processor type and features (Sometimes it would be better to do a quick research before asking. ;)) //Peter Regards, Harald signature.asc Description: This is a digitally signed message part. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] locking...
On Sat, Jun 20, 2009 at 02:08:08PM -0400, Ward Vandewege wrote: On Sat, Jun 20, 2009 at 10:13:04AM -0700, ron minnich wrote: That is fine. That's a simple and straightforward change. How about we start with that. But let's not do THAT change until we fix ward's problem, and this has nothing to do with Ward's problem. Sorry for opening this can of worms ;) So, Stepan thinks that perhaps the stack is too small for the lzma decompression. I'm going to test next week with a 32KB stack (right now its at the default 8KB). This might solve booting, but I'll still have APs and BSP talking all at once, which I'm also seeing on K10. I tried with a 32KB stack and a 64KB stack, no change, the machine still resets itself: http://ward.vandewege.net/coreboot/h8dme/minicom-20090624e.cap So, something else is going on. Thanks, Ward. -- Ward Vandewege w...@fsf.org Free Software Foundation - Senior Systems Administrator -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Is PI-AM2RS780G supported ?
Hi Alois, I first want to say that I agree with kernel people that this is a BIOS issue. Alois Schlögl wrote: I'm wondering whether coreboot will work in my machine. Not coreboot, but flashrom looks good. Found chip Winbond W25x80 (1024 KB) at physical address 0xfff0. The BIOS update you linked to in kernel bugzilla, http://us.sapphiretech.com/drivers/78SAPV09_20090522_4854.zip, contains a BIOS from May, with upgrades from AGESA (this is a BIOS library from AMD) 3.3.2.0 to 3.3.2.3. I don't know if this will fix the problem you are seeing. You could update your BIOS using flashrom and the 78SAPV09.BIN file in that zip. Run flashrom -E to erase your flash chip and then flashrom -wv 78SAPV09.BIN to program and verify the new BIOS. Ideally you should have a restore method before trying this. flashrom -E if it works will erase the flash chip completely. If you have a power outage at that point the system will not start again and the flash chip must be reprogrammed somewhere/somehow else, or the mainboard replaced. //Peter -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] LInux kernel in Flash
Harald Gutmann wrote: How do I pass the kernel cmd-line? Is it possible to set that on kernel compile time? CONFIG_CMDLINE_BOOL, Built-in kernel command line in Processor type and features Or --append to mkelfImage //Peter pgpa7fmuTI6VB.pgp Description: PGP signature -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] locking...
at the default 8KB). This might solve booting, but I'll still have APs and BSP talking all at once, which I'm also seeing on K10. I tried with a 32KB stack and a 64KB stack, no change, the machine still resets itself: http://ward.vandewege.net/coreboot/h8dme/minicom-20090624e.cap Maybe this is a silly suggestion, but how hard would it be to write a script that unscrambled the output? If I only knew how to find it on Google (I tried briefly), I'm sure something similar has already been written. It seems like it is a simpler problem because we know the maximum number of processors and the possible format strings. I wish I had the time to play with it because I think it would be fun to write. It seems like the priorities are: 1. Stop the APs from executing when they shouldn't. 2. Fix locking if it's still a problem. I think the garbled output provides a good hint (although it is annoying) at what's wrong. Thanks, Myles -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] locking...
Ward, At the point where it starts to get garbled, can you insert an endless loop for a processor that isn't the BSP? Or insert a loop that prints the processor's number in a loop. Just a sanity check. Thanks, Myles -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] locking...
On Wed, Jun 24, 2009 at 10:46 AM, Myles Watson myle...@gmail.com wrote: Ward, At the point where it starts to get garbled, can you insert an endless loop for a processor that isn't the BSP? Or insert a loop that prints the processor's number in a loop. Just a sanity check. Thanks, Myles Found CBFS 4f524243 Check normal/payload CBFS: follow chain: fff0 + 28 + 10076 + align - fff100a6 Check normal/coreboot_ram CBFS: follow chain: fff100a0 + 38 + 4a01c + align - fff5a100 Check normal/coreboot_apc CBFS: follow chain: fff5a100 + 38 + 2be8 + align - fff5cd20 Check fallback/payload CBFS: follow chain: fff5cd20 + 38 + 10076 + align - fff6cdd0 Check fallback/corebot_ram Stage: load @ 1048576/696320 bytes, enter @ 10 4a01c + : after memset 0on -stack variables at 001fedf8 and 001fee04 cbfs_decompress: algo: 0c8000 : uncompressed I'm done doing that by hand for a while :) So one processor loads coreboot_ram and jumps there, then another does memset on the same area so that it can load it? Thanks, Myles -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] locking...
I did it by hand. Not pleasant, but see below. Too bad we both did it. [...] Copying data from cache to RAM -- switching to use RAM as stack... Done testx = 5a5a5a5a Disabling cache as ram now Clearing initial memory region: Done I think it's interesting that this is the first duplicated message: Jumping to image. Jumping to image. Have you looked at what happens there that might be releasing an AP? Also, didn't you say it was dual node, dual core? I wonder why there are only two copies of the messages. Do you think they're both on the same node, or both the first processor per node? Thanks, Myles -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] [flashrom] r631 - trunk
Author: uwe
Date: 2009-06-24 19:31:08 +0200 (Wed, 24 Jun 2009)
New Revision: 631
Modified:
trunk/flashrom.8
trunk/flashrom.c
Log:
Always verify write operations automatically.
Should this be undesireable because of speed reasons, --noverify can be
used to suppress an auto-verify.
Signed-off-by: Uwe Hermann u...@hermann-uwe.de
Acked-by: Carl-Daniel Hailfinger c-d.hailfinger.devel.2...@gmx.net
Acked-by: Harald Gutmann harald.gutm...@gmx.net
Modified: trunk/flashrom.8
===
--- trunk/flashrom.82009-06-24 08:28:39 UTC (rev 630)
+++ trunk/flashrom.82009-06-24 17:31:08 UTC (rev 631)
@@ -2,9 +2,8 @@
.SH NAME
flashrom \- detect, read, write, verify and erase flash chips
.SH SYNOPSIS
-.B flashrom \fR[\fB\-VfLzhR\fR] [\fB\-E\fR|\fB\-r\fR file|\fB\-w\fR
file|\fB\-v\fR file]
- [\fB\-c\fR chipname] [\fB\-m\fR [vendor:]part]
- [\fB\-l\fR file] [\fB\-i\fR image] [\fB\-p\fR programmer]
+.B flashrom \fR[\fB\-VfLzhRn\fR] [\fB\-E\fR|\fB\-r\fR file|\fB\-w\fR
file|\fB\-v\fR file] [\fB\-c\fR chipname]
+ [\fB\-m\fR [vendor:]part] [\fB\-l\fR file] [\fB\-i\fR image]
[\fB\-p\fR programmer]
.SH DESCRIPTION
.B flashrom
is a utility for detecting, reading, writing, verifying and erasing flash
@@ -38,6 +37,21 @@
.B file
is specified).
.TP
+.B \-n, \-\-noverify
+Do
+.B not
+verify the flash ROM contents after writing them to the chip. Using this
+option is
+.B not
+recommended, you should only use it if you know what you are doing and you
+feel that the time for verification takes too long.
+.sp
+Typical usage is:
+.B flashrom -wn file
+.sp
+This option is only useful in combination with
+.BR \-\-write .
+.TP
.B \-v, \-\-verify file
Verify the flash ROM contents against the given
.BR file .
Modified: trunk/flashrom.c
===
--- trunk/flashrom.c2009-06-24 08:28:39 UTC (rev 630)
+++ trunk/flashrom.c2009-06-24 17:31:08 UTC (rev 631)
@@ -480,6 +480,7 @@
( -r | --read: read flash and save into
file\n
-w | --write: write file into flash\n
-v | --verify:verify flash against file\n
+ -n | --noverify: don't verify flash against
file\n
-E | --erase: erase flash device\n
-V | --verbose: more verbose output\n
-c | --chip chipname: probe only for specified
flash chip\n
@@ -515,7 +516,7 @@
int option_index = 0;
int force = 0;
int read_it = 0, write_it = 0, erase_it = 0, verify_it = 0;
- int list_supported = 0, list_supported_wiki = 0;
+ int dont_verify_it = 0, list_supported = 0, list_supported_wiki = 0;
int operation_specified = 0;
int ret = 0, i;
@@ -524,6 +525,7 @@
{write, 0, 0, 'w'},
{erase, 0, 0, 'E'},
{verify, 0, 0, 'v'},
+ {noverify, 0, 0, 'n'},
{chip, 1, 0, 'c'},
{mainboard, 1, 0, 'm'},
{verbose, 0, 0, 'V'},
@@ -553,7 +555,7 @@
}
setbuf(stdout, NULL);
- while ((opt = getopt_long(argc, argv, rRwvVEfc:m:l:i:p:Lzh,
+ while ((opt = getopt_long(argc, argv, rRwvnVEfc:m:l:i:p:Lzh,
long_options, option_index)) != EOF) {
switch (opt) {
case 'r':
@@ -580,6 +582,9 @@
}
verify_it = 1;
break;
+ case 'n':
+ dont_verify_it = 1;
+ break;
case 'c':
chip_to_probe = strdup(optarg);
break;
@@ -779,6 +784,10 @@
exit(1);
}
+ /* Always verify write operations unless -n is used. */
+ if (write_it !dont_verify_it)
+ verify_it = 1;
+
size = flash-total_size * 1024;
buf = (uint8_t *) calloc(size, sizeof(char));
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH] flashrom: Autoverify all writes, unless --noverify is used
On Wed, Jun 24, 2009 at 05:07:51PM +0200, Harald Gutmann wrote: On Wednesday 24 June 2009 16:00:12 Uwe Hermann wrote: See patch. Tested on one board, other tests are welcome. Tested on M57SLI v2 (spi). Works fine! Great, thanks! Acked-by: Harald Gutmann harald.gutm...@gmx.net r631, with some manpage updates. Uwe. -- http://www.hermann-uwe.de | http://www.holsham-traders.de http://www.crazy-hacks.org | http://www.unmaintained-free-software.org -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Which file should I burn?
On Wed, Jun 24, 2009 at 01:48:49AM -0700, Rick Ant wrote: I can't find EEPROM chip while running flashrom from the systemrescue LiveCD... Please try the latest svn version of flashrom and post 'flashrom -V' output if it still doesn't detect the chip. Also, please let us know which mainboard this is. it said No EEPROM/Flash device foundis it depend on the motherboard? Yes. See http://www.coreboot.org/Flashrom#Supported_mainboards Uwe. -- http://www.hermann-uwe.de | http://www.holsham-traders.de http://www.crazy-hacks.org | http://www.unmaintained-free-software.org -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] Failover and Fallback
Hello, I know how the coreboot image is scaled with Failover/Fallback/Normal. http://www.coreboot.org/Anatomy_of_a_Failover_coreboot_v2_Image But my question is when does coreboot access Failover or Fallback? I wasn't able to determine that, but it would be good to know. Kind regards, Harald -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] locking...
On Wed, Jun 24, 2009 at 11:24:10AM -0600, Myles Watson wrote: I did it by hand. Not pleasant, but see below. Too bad we both did it. Yeah, sorry guys :/ I had written a little script to print every other character but it didn't come out as clean as you both did it. [...] Copying data from cache to RAM -- switching to use RAM as stack... Done testx = 5a5a5a5a Disabling cache as ram now Clearing initial memory region: Done I think it's interesting that this is the first duplicated message: Jumping to image. Jumping to image. Have you looked at what happens there that might be releasing an AP? Also, didn't you say it was dual node, dual core? I wonder why there are only two copies of the messages. Do you think they're both on the same node, or both the first processor per node? Correct, this is a dual node, dual core system, so 4 cores in total, two per cpu. Thanks, Ward. -- Ward Vandewege w...@fsf.org Free Software Foundation - Senior Systems Administrator -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Patch RE: coreboot for C3/CN400 (Luke) - Long Lines Fixed
On Wed, Jun 24, 2009 at 01:44:30PM +0100, Harrison, Jon (SELEX GALILEO, UK) wrote: Sorry Long lines were wrapped in last post Please add a Signed-off-by line to every patch you post, see http://www.coreboot.org/Development_Guidelines#Sign-off_Procedure Thanks, Uwe. -- http://www.hermann-uwe.de | http://www.holsham-traders.de http://www.crazy-hacks.org | http://www.unmaintained-free-software.org -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Failover and Fallback
But my question is when does coreboot access Failover or Fallback? I wasn't able to determine that, but it would be good to know. Only some boards have Failover. Failover chooses whether to boot Normal or Fallback, based on whether the last boot was successful. Look in cache_as_ram_auto.c or auto.c for your board. Thanks, Myles -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [workaround found] locking...
So, I got it to boot by setting CONFIG_AP_CODE_IN_CAR to off. That way the APs don't stumble over one another, and the machine boots just fine. Here's the boot log: http://ward.vandewege.net/coreboot/h8dme/minicom-20090624g.cap You'll see a couple garbled lines, but I think that's just each of the APs saying they are ready. I'm glad it works, but it still looks broken to me. Those lines look like ... TrainDQS RdWrPos1: ... in there. Myles -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [workaround found] locking...
On Wed, Jun 24, 2009 at 12:51:29PM -0600, Myles Watson wrote: So, I got it to boot by setting CONFIG_AP_CODE_IN_CAR to off. That way the APs don't stumble over one another, and the machine boots just fine. Here's the boot log: http://ward.vandewege.net/coreboot/h8dme/minicom-20090624g.cap You'll see a couple garbled lines, but I think that's just each of the APs saying they are ready. I'm glad it works, but it still looks broken to me. Those lines look like ... TrainDQS RdWrPos1: ... in there. I think you are right. So, we really need to get some sort of printk locking in there so that we can diagnose what's going on with less guesswork. There's this comment in src/mainboard/tyan/s2912_fam10/cache_as_ram_auto.c: /* wait for all the APs core0 started by finalize_node_setup. */ /* FIXME: A bunch of cores are going to start output to serial at once. * It would be nice to fixup prink spinlocks for ROM XIP mode. * I think it could be done by putting the spinlock flag in the cache * of the BSP located right after sysinfo. */ wait_all_core0_started(); I got a little lost in the whole locking discussion; is the above a way to ungarble the output in this particular case? Thanks, Ward. -- Ward Vandewege w...@fsf.org Free Software Foundation - Senior Systems Administrator -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [workaround found] locking...
On Wed, Jun 24, 2009 at 12:51:29PM -0600, Myles Watson wrote: So, I got it to boot by setting CONFIG_AP_CODE_IN_CAR to off. That way the APs don't stumble over one another, and the machine boots just fine. Here's the boot log: http://ward.vandewege.net/coreboot/h8dme/minicom-20090624g.cap You'll see a couple garbled lines, but I think that's just each of the APs saying they are ready. I'm glad it works, but it still looks broken to me. Those lines look like ... TrainDQS RdWrPos1: ... in there. Ugh, I spoke too soon. Booting with CONFIG_AP_CODE_IN_CAR off reduced me to 1 core. Sigh. Patrick, I'm really interested in figuring out why you are seeing none of these problems with the K8 boards you tested 4315 on. Thanks, Ward. -- Ward Vandewege w...@fsf.org Free Software Foundation - Senior Systems Administrator -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [workaround found] locking...
On Wed, Jun 24, 2009 at 03:05:26PM -0400, Ward Vandewege wrote: On Wed, Jun 24, 2009 at 12:51:29PM -0600, Myles Watson wrote: So, I got it to boot by setting CONFIG_AP_CODE_IN_CAR to off. That way the APs don't stumble over one another, and the machine boots just fine. Here's the boot log: http://ward.vandewege.net/coreboot/h8dme/minicom-20090624g.cap You'll see a couple garbled lines, but I think that's just each of the APs saying they are ready. I'm glad it works, but it still looks broken to me. Those lines look like ... TrainDQS RdWrPos1: ... in there. Ugh, I spoke too soon. Booting with CONFIG_AP_CODE_IN_CAR off reduced me to 1 core. Sigh. Disregard that - caused by something else. All cores are visible. Thanks, Ward. -- Ward Vandewege w...@fsf.org Free Software Foundation - Senior Systems Administrator -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Intel Eagle Height evaluation board support
Hi all I created a new thread for the vga rom execution issues, because it does not seem related to the mainboard. It's here : http://www.coreboot.org/pipermail/coreboot/2009-June/050176.html Regards, Thomas 2009/6/24 Tom Sylla tsy...@gmail.com: On Wed, Jun 24, 2009 at 8:43 AM, Thomas JOURDANthomas.jour...@gmail.com wrote: I forgot to mention that on the IRC, someone suspected a missing timer setup leading to a division by zero. This might help. In the past, when trying to figure out a VGA ROM execution hang or errors, it has been very helpful to watch full IO tracing in the emulator to see what IOs were being accessed just before the hang. It would be interesting if you could do the same, especially if you are suspecting that some legacy part is not set up properly. I don't know the exact mechanism to do that in the emulators you are trying (or if it is possible any more), but it may be helpful to try. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [workaround found] locking...
On Wed, Jun 24, 2009 at 1:05 PM, Ward Vandewege w...@gnu.org wrote: Patrick, I'm really interested in figuring out why you are seeing none of these problems with the K8 boards you tested 4315 on. Has anyone else seen these garbled messages? Your 4314 logs had them too. This looks like an unrelated problem that got exposed by the change to me. Thanks, Myles -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [flashrom] [PATCH] external serial flasher protocol support
Hi all, Here comes a new version, i added some stuff too. Oh and btw, could we add A/A mux bit (on LPC/FWH chips) to the supported bustypes variable? This version should be binary compatible with the previous spec version, only clarifications and added commands, i will need to add support for read-n maximum length to flashrom though. I have 6 mins of battery on this laptop so here goes, have to go. duh here my battery monitor failed me, but luckily gmail saved the message just in time (opera mini sending again then). -- urjaman Serial Flasher Protocol Specification - version 1 (0x01 return value == 1) Command And Answer Sequence - all commands give an answer. PC: COMMAND(8bit) parameters determined by opcode DEV: ACK/NAK(8bit) OPTIONAL RETURN BYTES (only if ACK) / nothing Command 0x10 (SYNCNOP) has a special return of NAK+ACK for synchronization. ACK = 0x06 NAK = 0x15 All multibyte values are little-endian. Addresses and lengths are 24-bit. COMMAND Description Parameters Return Value 0x00NOP noneACK 0x01Query programmer iface version noneACK + 16bit version (nonzero) 0x02Query supported commands bitmap noneACK + 32 bytes (256 bits) of supported cmds flags 0x03Query programmer name noneACK + 16 bytes string (null padding) / NAK 0x04Query serial buffer sizenoneACK + 16bit size / NAK 0x05Query supported bustypesnoneACK + 8-bit flags (as per flashrom) / NAK 0x06Query connected address lines noneACK + 8bit line count / NAK 0x07Query operation buffer size noneACK + 16bit size / NAK 0x08Query write-n maximum data len noneACK + 24bit maximum length / NAK 0x09Read byte 24-bit addr ACK + BYTE / NAK 0x0ARead n bytes24-bit addr + 24-bit length ACK + length bytes / NAK 0x0BInitialize operation buffer noneACK / NAK 0x0CWrite to opbuf: Write byte 24-bit addr + 8-bit byteACK / NAK (NOTE: takes 5 bytes in opbuf) 0x0DWrite to opbuf: Write n 24-bit length + 24-bit addr + ACK / NAK (NOTE: takes 7+n bytes in opbuf) + length bytes of data 0x0EWrite to opbuf: delay 32-bit usecsACK / NAK (NOTE: takes 5 bytes in opbuf) 0x0FExecute operation buffernoneACK / NAK 0x10Sync NOPnoneNAK + ACK (for synchronization) 0x11Query maximum read-n length noneACK + 24-bit length (0==2^24) / NAK 0x12Set used bustype8-bit flags (as with 0x05) ACK / NAK 0x??unimplemented command - invalid. Additional information of the above commands: About unimplemented commands / startup sequence: Only commands allowed to be used without checking anything are 0x00,0x10 and 0x01 (NOP,SYNCNOP,Q_IFACE). If 0x01 doesn't return 1, dont do anything if you dont support a newer protocol. Then, check support for any other opcode (except 0x02) by using 0x02 (Q_CMDMAP). 0x02 (Q_CMDMAP): The map's bits are mapped as follows: cmd 0 support: byte 0 bit 0 cmd 1 support: byte 0 bit 1 cmd 7 support: byte 0 bit 7 cmd 8 support: byte 1 bit 0, and so on. 0x04 (Q_SERBUF): If the programmer has guaranteedly working flow control, it should return a big bogus value - eg 0x. 0x05 (Q_BUSTYPE): The bit's are defined as follows: bit 0: PARALLEL, bit 1: LPC, bit 2: FWH, bit 3: SPI (if ever supported). 0x06 (Q_CHIPSIZE): Only applicable to parallel programmers. An LPC/FHW/SPI-programmer can report this as not supported in the command bitmap. 0x08 (Q_WRNMAXLEN): If a programmer reports a bigger maximum write-n length than the serial buffer size, it is assumed that the programmer can process the data fast enough to take in the reported maximum write-n without problems. 0x0F (O_EXEC): Execute operation buffer will also clear it, regardless of the return value. 0x11 (Q_RDNMAXLEN): If this command is not supported, assume return of 0 (2^24). 0x12 (S_BUSTYPE): Set's the used bustype if the programmer can support more than one flash protocol. Sending a byte with more than 1 bit set will make the
[coreboot] Fun ugliness
Does this make sense? Since CAR isn't backed by actual RAM, if I do a ram test of any reasonable size it evicts my stack and I can't continue. So, when I'm comfortable with my RAM setup I have to go blind. Is there a way around that? Anything I can think of would be very implementation specific. Thanks, Myles -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] [PATCH] flashrom: Add support for Hyundai HY29F002T
Add support to flashrom for Hyundai HY29F002T on the assumption it is
the same as other *29F002T chips. Running 'flashrom -r' finds the chip
and reads what looks like a BIOS image, other than that it is un-tested.
Signed-off-by: Andrew Morgan zil...@ziltro.com
---
Once I de-solder these chips and get some sockets fitted I can do some
proper testing! Gigabyte GA-7ZXR has two of them for its DualBIOS™.
Switching between chips seems to be done in software... Very useful.
--
Andrew.
Index: flashchips.c
===
--- flashchips.c (revision 631)
+++ flashchips.c (working copy)
@@ -1146,6 +1146,22 @@
},
{
+ .vendor = HYUNDAI,
+ .name = HY29F002T,
+ .bustype = CHIP_BUSTYPE_NONSPI,
+ .manufacture_id = HYUNDAI_ID,
+ .model_id = HY_29F002T,
+ .total_size = 256,
+ .page_size = 256,
+ .tested = TEST_UNTESTED,
+ .probe = probe_jedec,
+ .probe_timing = TIMING_FIXME,
+ .erase = erase_chip_jedec,
+ .write = write_en29f002a,
+ .read = read_memmapped,
+ },
+
+ {
.vendor = Intel,
.name = 28F001BX-B,
.bustype = CHIP_BUSTYPE_PARALLEL,
Index: flashchips.h
===
--- flashchips.h (revision 631)
+++ flashchips.h (working copy)
@@ -160,6 +160,7 @@
#define MBM29F004TC 0x77
#define HYUNDAI_ID 0xAD /* Hyundai */
+#define HY_29F002T 0xB0
#define IMT_ID 0x7F1F /* Integrated Memory Technologies */
#define IM_29F004B 0xAE
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] Integrate the kernel into 49LF004...
Hello, Is it possible for me to integrate the Linux Kernel Into the Flash ROM 49LF004 and starting the X-server ? Thanks -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH] flashrom: SB600 SPI: Kill unused variable
Originally I defined the struct and access the controller by the member of the struct. But the code couldn't work at first. Then I changed every a-b to a[XX]. Obviously it doesn't make any sense. Now the code has been working so far, but I haven't got passion to change them back. Maybe later I will do it. Zheng -Original Message- From: coreboot-boun...@coreboot.org [mailto:coreboot-boun...@coreboot.org] On Behalf Of Carl-Daniel Hailfinger Sent: Tuesday, June 23, 2009 8:49 AM To: Luc Verhaegen Cc: Coreboot Subject: Re: [coreboot] [PATCH] flashrom: SB600 SPI: Kill unused variable On 23.06.2009 00:09, Luc Verhaegen wrote: On Mon, Jun 22, 2009 at 04:31:44PM +0200, Carl-Daniel Hailfinger wrote: SB600 SPI: Kill unused variable. Signed-off-by: Carl-Daniel Hailfinger c-d.hailfinger.devel.2...@gmx.net If this builds, then what can be wrong with this :) I guess you are keeping this struct because publically available documentation is perhaps not as clear as it should be? Well, the documentation is pretty readable, but the struct is a handy compressed reference and useful if you want to avoid reading dozens of datasheet pages. Why not comment it completely so that no-one else will complain about it in future? Done. Please also make reset_internal_fifo_pointer and execute_command static so thatthese symbols, when unused, will turn up in the build as well. Done. Apart from that, of course: Acked-by: Luc Verhaegen l...@skynet.be Thanks, committed in r623. Regards, Carl-Daniel -- http://www.hailfinger.org/ -- 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
[coreboot] Current version of buildrom works
Hello! I just used buildrom to create a Qemu image for trying out the coreinfo payload. It worked perfectly with the prebuilt and unpatched version of Qemu that I collected from a repository for my distribution of Linux. I would hazard a guess that I can now use buildrom to create my images for an appropriate board, which presupposes that the board name (to be named later) is a known working one with Coreboot. -- Gregg C Levine hansolofal...@worldnet.att.net The Force will be with you always. Obi-Wan Kenobi -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH] flashrom: Add support for Hyundai HY29F002T
Andrew Morgan wrote: Gigabyte GA-7ZXR has two of them for its DualBIOS™. Switching between chips seems to be done in software... Very useful. Gigabyte owns a patent involving a timer and a software handshake. //Peter -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] Corrupt rom -- found no header at 458720
I try to use $ mkelfImage --append=console=ttyS0 --initrd=initrd vmlinuz linux.elf When : telebit:~/Project/Kantor/Thin_client/coreboot-v2-4360/targets # ./buildtarget emulation/qemu-x86/Config.lb and do make.. I get coreboot.rom on 512Kbyte My initrd is 1Mbyte and vmlinuz 16Mbyte..is it ok? The make result is situated below... Is it ok ? if I want to change the chipset, what should i do? My chipset is 82810 North and 82801 South.. ... Payload: 0 coreboot: 65536 ROM size: 65536 Left space: 0 if [ 0 -eq 1 -a 1 -eq 1 ]; then echo l cbfs-support; fi make[1]: Leaving directory `/root/Project/Kantor/Thin_client/coreboot-v2-4360/targets/emulation/qemu-x86/qemu-x86/normal' rm -f ./coreboot.rom cat normal/coreboot.rom ./coreboot.rom.bootblock ./cbfstool ./coreboot.rom create 524288 65536 ./coreboot.rom.bootblock ./cbfstool ./coreboot.rom add-payload /root/Project/Kantor/mkelfImage-2.7/linux.elf normal/payload Corrupt rom -- found no header at 458720 make: *** [coreboot.rom] Error 1 telebit:~/Project/Kantor/Thin_client/coreboot-v2-4360/targets/emulation/qemu-x86/qemu-x86 # -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Fun ugliness
On 24.06.2009 23:46, Myles Watson wrote: Does this make sense? Since CAR isn't backed by actual RAM, if I do a ram test of any reasonable size it evicts my stack and I can't continue. Correct if the RAM you're testing is marked as cacheable. If that RAM area is not marked as cacheable, there should be no problem. Then again, cache aliasing may ruin this approach. Yes. Because I was accessing my FPGA I marked it as cacheable to change the size of the reads. I didn't think about the side effects enough. I'll just have to be careful. movnti is the right idea for writes. Thanks, Myles -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH] flashrom: Add support for Hyundai HY29F002T
Peter Stuge wrote: Andrew Morgan wrote: Gigabyte GA-7ZXR has two of them for its DualBIOS™. Switching between chips seems to be done in software... Very useful. Gigabyte owns a patent involving a timer and a software handshake. Interesting... That software has to be stored somewhere though, right? Unless there is a third ROM, it'll have to be within both BIOSes... -- Andrew. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] which mainboard is the best reference for s3
Hi Rudolf , I want to update my vx855 code using the newest version of coreboot-v2, to take advantage of new functions(such as smi,AML-auto-generator) that appear on coreboot in the last months. And, since I also want to use as much of coreboot's existing code as possible(and to maintain a source that is not on coreboot's svn as easy as possible...), I wonder which mainboard is the best reference for S3 function for now? It seems that amdk8 now has good support of S3, but I didn't found S3 code on asus/m2v-mx_se. Many thanks. -jasonzhao -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] LInux kernel in Flash
On K, 2009-06-24 at 17:54 +0200, Peter Stuge wrote: Harald Gutmann wrote: What do I need except a kernel image which has all drivers compilled in? What needs to be done to get this setup working? Two ways: 1. Use mkelfImage to get a payload from vmlinux See http://www.coreboot.org/Mkelfimage for download info. mkelfImage -t vmlinux-i386 --kernel=~/linux-version/vmlinux --output=~/linux.elf ~/linux.elf is your payload. Add ramdisk if you like. 2. Try using vmlinux as payload directly, it might work, we don't know It would be interesting to know if vmlinux+initramfs works: http://www.coreboot.org/Initramfs Note that you always want to use the uncompressed vmlinux to start with, and enable payload LZMA compression. LZMA compresses better than the in-kernel compression used for bzImage. I suppose packing twice with LZMA would make no sense either? Having in mind that linux-2.6.30 supports LZMA for bzImage. So kernel code would be packed twice, and the highmem kernel loader in bzImage once for payload. Waste of decompression time I bet myself without testing. And thanks - good point about using vmlinux, I hadn't thought of that before reading this thread. Regards, Mart Raudsepp -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] I've got this message...
I try to run the bios.bin that i've created and getting these message : Is it ok ? I want to try it on my 49LF004 Anyone opinion will be helped... Thanks === telebit:~/Project/Kantor/Thin_client/qemu-0.10.5/i386-softmmu # ./qemu -L ~ -hda /root/Project/Kantor/Thin_client/qemu-0.10.5/disk.img -nographic Could not open '/dev/kqemu' - QEMU acceleration layer not activated: No such file or directory coreboot-2.0.0-r-GRUB2 Thu Jun 25 10:03:17 WIT 2009 starting... Uncompressing coreboot to RAM. Jumping to image. Check CBFS header at fffeffd0 magic is 4f524243 Found CBFS header at fffeffd0 Check CBFS: follow chain: fff8 + 28 + 6ffb8 + align - fffeffe0 CBFS: Could not find file normal/coreboot_ram Jumping to image. qemu: fatal: Trying to execute code outside RAM or ROM at 0x000a EAX= EBX=01d7 ECX=03f8 EDX=03dc ESI= EDI= EBP= ESP=03d4 EIP=0009ff81 EFL=0002 [---] CPL=0 II=0 A20=1 SMM=0 HLT=0 ES =0010 00cf9300 CS =0008 00cf9b00 SS =0010 00cf9300 DS =0010 00cf9300 FS =0010 00cf9300 GS =0010 00cf9300 LDT= 8200 TR = 8b00 GDT= 0044 0017 IDT= CR0=6011 CR2= CR3= CR4= DR0= DR1= DR2= DR3= DR6=0ff0 DR7=0400 CCS= CCD=0001 CCO=ADDB FCW=037f FSW= [ST=0] FTW=00 MXCSR=1f80 FPR0= FPR1= FPR2= FPR3= FPR4= FPR5= FPR6= FPR7= XMM00= XMM01= XMM02= XMM03= XMM04= XMM05= XMM06= XMM07= Aborted -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] I've got this message...
there is a problem, you are missing a vga bios maybe. You can NOT use a qemu bios on hardware. I hope that is not what you are trying to do. It won't work. ron -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] I've got this message...
where can i find the VGA BIOS ? == You can NOT use a qemu bios on hardware. I hope that is not what you are trying to do. It won't work. == Then which BIOS that should I use so I can embed linux in FLASH ROM chip? Thanks --- On Wed, 6/24/09, ron minnich rminn...@gmail.com wrote: From: ron minnich rminn...@gmail.com Subject: Re: [coreboot] I've got this message... To: Rick Ant rick_...@yahoo.com Cc: coreboot@coreboot.org Date: Wednesday, June 24, 2009, 10:32 PM there is a problem, you are missing a vga bios maybe. You can NOT use a qemu bios on hardware. I hope that is not what you are trying to do. It won't work. ron -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] I've got this message...
The qemu one is broken. I will send you a working one off-list. ron -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] I've got this message...
tell me how to use it? My system configuration is Intel PIII 82810 Northbridge and 82801 Southbridge 128 Mb Ram and 49LF004 Flash ROM I want to embed coreboot and Linux into 49LF004, so it will become thin client which will connect to the server... My development configuration is VIA Ester 1.8GHz, 512 Mb..witch Suse 10.1 on it Thanks --- On Wed, 6/24/09, ron minnich rminn...@gmail.com wrote: From: ron minnich rminn...@gmail.com Subject: Re: [coreboot] I've got this message... To: Rick Ant rick_...@yahoo.com Cc: coreboot@coreboot.org Date: Wednesday, June 24, 2009, 10:39 PM The qemu one is broken. I will send you a working one off-list. ron -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] Anyone know how to use emulation-qemu-x86.rom
Anyone know how to use emulation-qemu-x86.rom ron minnich send me one... Thanks -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
