Re: [coreboot] [LinuxBIOS] Please add support for MX25L8005 and MX25L3205D
Am Dienstag, 22. Januar 2008 00:48:30 schrieben Sie: On 21.01.2008 17:15, Harald Gutmann wrote: Hello! As in the thread Re: [coreboot] SST25VF016B (2MB) flash on m57sli (IT8716F) there was added support for writing/reading lager SPI chips than 512kB i had a look on the current flashrom code, in svn revision 3067. I recogniced that the MX25L8005 calls the same function than the SST25VF016B in the flashchips.c file. The function called there are generic_spi_chip_erase_c7, generic_spi_chip_write and generic_spi_chip_read. The write function is in spi.c, and checks if the total_size is bigger than 512kB, as result of that check the it8716f_over512k_spi_chip_write should be called to write the chip. The SST25VF016B can be programmed/verified/erased but not the MX25L8005. Probably either the chip does not support BYTE-PROGRAM or we have a timing issue. I checked the datasheet and the MX25L8005 indeed has a PAGE-PROGRAM mode, but it can be abused for BYTE-PROGRAM. Writing random data to the chip results in a failed verify. Erasing the chip seems to work. Here is the file which i wrote to the chip, and the file which i get as result when trying to read the chip. (looks quite strange in hexdump, there are many FF lines in the read file.) http://rapidshare.com/files/85450682/read_write_diff-r3067.tar.gz.html This is a timing issue with ~95% probability. Simply look at the readback result. Will send a patch. I got the patch, and tested it. It seems to work like ron said! More in the SST thread. I also wondered if the mx25l4005.c file is needed any more, because the functions in there aren't called anywhere. Hm. Are you sure this file exists in the official tree? I can't find it. Oh, seems that you're right, i trusted in svn diff/revert, and svn diff didn't mention any differenceses between my version and the actual repository, but it's like you said, that this file isn't existing in the official tree. Regards, Carl-Daniel regards, Harald -- coreboot mailing list coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] SST25VF016B (2MB) flash on m57sli (IT8716F).
Am Dienstag, 22. Januar 2008 01:09:09 schrieben Sie:
Harald: This patch should fix your problems writing to the chip. Use
either patch -l or remove the // before
//while (generic_spi_read_status_register() JEDEC_RDSR_BIT_WIP)
I've updated my flashrom tree to revision 3068 and commented that line out.
Now i can flash the chip, like Ronald says. I wrote the chip, and read the
file again, and compared the start and the end of the file with
hexdump/head/tail and diff. On the first/last 5 lines there is no
difference between the file which was written to the chip, and the file i've
read with flashrom from the chip.
Any idea why verifying fails?
Ronald: I need an ack to commit this.
On 20.01.2008 11:59, Ronald Hoogenboom wrote:
Carl-Daniel Hailfinger wrote:
Did you have time to test with the while
(generic_spi_read_status_register() .._WIP) enabled? It would be more
correct to have it enabled.
I had that in initially (that's why it was there, but commented out) but
all it got me was slower programming times and the datasheet also
suggests it is ok to just do a timed wait. But in the face of
genericness for other chips, it is indeed more correct to do the check
for the busy bit.
Ronald/Harald, can you please ack the change? It is reproduced below
(whichspace-damaged).
Regards,
Carl-Daniel
Make sure we delay writing the next byte long enough in SPI byte
programming.
Minor formatting changes.
Signed-off-by: Carl-Daniel Hailfinger [EMAIL PROTECTED]
Acked-by: Harald Gutmann [EMAIL PROTECTED]
Index: spi.c
===
--- spi.c (Revision 3068)
+++ spi.c (Arbeitskopie)
@@ -519,12 +519,8 @@
for (i=0; itotal_size; i++) {
generic_spi_write_enable();
spi_byte_program(i,buf[i]);
- /* FIXME: We really should read the status register and delay
- * accordingly.
- */
- //while (generic_spi_read_status_register()
JEDEC_RDSR_BIT_WIP)
+ while (generic_spi_read_status_register() JEDEC_RDSR_BIT_WIP)
myusec_delay(10);
//if (i%1024==0) fputc('b',stderr);
}
Regards,
Carl-Daniel
Regards, Harald
--
coreboot mailing list
coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] v3 compilation failures
On Mon, Jan 21, 2008 at 04:01:57PM -0700, Marc Jones wrote: -/* smbus functions */ -int smbus_read_byte(unsigned device, unsigned address); hmm. So where does the prototype live then? There's include/device/smbus.h with int smbus_read_byte(struct device *dev, u8 addr); and also include/lib.h with int smbus_read_byte(unsigned device, unsigned address); at the moment. The latter should be dropped IMO, include/device/smbus.h sounds like the correct place to have the prototype. -/* dram functions */ -void ram_failure(const char *why); -void ram_initialize(int controllers, void *ctrl); These are in lib/ram.c and even defined in the documentation ;-) What should we do about that? You have a point. There should be a standard prototype but lib.h seemed to be a random place for them. I think that's ok, IIRC we did this in order to not have yet another almost-empty header file (ram.h). We should try to keep the number of files (especially useless *.h files) down as much as possible/reasonable. 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] [LinuxBIOS] [Fwd: Re: AMD 690G chipset support in LinuxBIOS v2]
Hi Marc, On Jan 22, 2008 1:21 AM, Marc Jones [EMAIL PROTECTED] wrote: The 690/600 support should be available in the first half of this year. We moved it out a few months to bring in the Barcelona support. I don't have specific dates but we will announce the code to the list as soon as it is available. The support would be on coreboot v2?linuxbios v2 right? Marc bari wrote: Any news on AMD M690 Coreboot support now that it is part of the AMD Embedded Solutions group? -Bari Marc Jones wrote: Currently there is no support in LinuxBIOS for any ATI(now AMD) chipsets. We do plan to work on this in the next six months but I don't have a specific release date. == Marc Jones Senior Firmware Engineer (970) 226-9684 Office mailto:[EMAIL PROTECTED] http://www.amd.com/embeddedprocessors Marc Regards, Darmawan --- -= Human knowledge belongs to the world =- -- coreboot mailing list coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] SST25VF016B (2MB) flash on m57sli (IT8716F).
On 22.01.2008 12:08, Harald Gutmann wrote: Am Dienstag, 22. Januar 2008 01:09:09 schrieben Sie: Harald: This patch should fix your problems writing to the chip. Use either patch -l or remove the // before //while (generic_spi_read_status_register() JEDEC_RDSR_BIT_WIP) I've updated my flashrom tree to revision 3068 and commented that line out. Now i can flash the chip, like Ronald says. I wrote the chip, and read the file again, and compared the start and the end of the file with hexdump/head/tail and diff. On the first/last 5 lines there is no difference between the file which was written to the chip, and the file i've read with flashrom from the chip. Any idea why verifying fails? Yes. Will send a patch. Ronald: I need an ack to commit this. On 20.01.2008 11:59, Ronald Hoogenboom wrote: Carl-Daniel Hailfinger wrote: Did you have time to test with the while (generic_spi_read_status_register() .._WIP) enabled? It would be more correct to have it enabled. I had that in initially (that's why it was there, but commented out) but all it got me was slower programming times and the datasheet also suggests it is ok to just do a timed wait. But in the face of genericness for other chips, it is indeed more correct to do the check for the busy bit. Ronald/Harald, can you please ack the change? It is reproduced below (whichspace-damaged). Regards, Carl-Daniel Make sure we delay writing the next byte long enough in SPI byte programming. Minor formatting changes. Signed-off-by: Carl-Daniel Hailfinger [EMAIL PROTECTED] Acked-by: Harald Gutmann [EMAIL PROTECTED] Thanks, r3069. Regards, Carl-Daniel -- coreboot mailing list coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH] flashrom: use the read function for verifying
Am Dienstag, 22. Januar 2008 15:59:28 schrieb Carl-Daniel Hailfinger:
Flashrom did not use the read function for verifying, it used direct memory
access instead. That fails if the flash chip is not mapped completely.
If the read function is set in struct flashchip, use it for verification
as well.
This fixes verification of all SPI flash chips 512 kByte behind an
IT8716F flash translation chip.
Signed-off-by: Carl-Daniel Hailfinger [EMAIL PROTECTED]
Acked-by: Harald Gutmann [EMAIL PROTECTED]
MX25L8005 found at physical address 0xfff0.
Flash part is MX25L8005 (1024 KB).
Flash image seems to be a legacy BIOS. Disabling checks.
Verifying flash... VERIFIED.
regards, harald
Index: flashrom-big/flashrom.c
===
--- flashrom-big/flashrom.c (Revision 3069)
+++ flashrom-big/flashrom.c (Arbeitskopie)
@@ -159,7 +159,11 @@
{
int idx;
int total_size = flash-total_size * 1024;
- volatile uint8_t *bios = flash-virtual_memory;
+ uint8_t *buf2 = (uint8_t *) calloc(total_size, sizeof(char));
+ if (flash-read == NULL)
+ memcpy(buf2, (const char *)flash-virtual_memory, total_size);
+ else
+ flash-read(flash, buf2);
printf(Verifying flash... );
@@ -170,7 +174,7 @@
if (verbose ((idx 0xfff) == 0xfff))
printf(0x%08x, idx);
- if (*(bios + idx) != *(buf + idx)) {
+ if (*(buf2 + idx) != *(buf + idx)) {
if (verbose) {
printf(0x%08x , idx);
}
--
coreboot mailing list
coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] progress on lx
On 19.01.2008 07:35, ron minnich wrote: On Jan 18, 2008 4:27 PM, Carl-Daniel Hailfinger [EMAIL PROTECTED] wrote: Is this same situation as before or is it worse? If it is worse, please try to fix before you commit. The fix is going to be a bit harder, so I am committing this now. Committed revision 557. One thing to add. I am probably going to make one more change to the id property in the dts. Right now we have stuff like: pciid = somevendorname, somedevicename; I am thinking of something like this: id=pci,somevendorname,somedevicename; Makes sense if the coreboot code itself does not have to perform any string parsing. Further, in the dtc makefile I would like to preprocess pci_ids.h to produce arrays of char * with a list of vendor and device names. Then the dtc tool can do the following: check the path type (pci). Check that it has the proper arguments (device, path). Then check the vendor name and device name to make sure they are valid for that path type. I'm undecided about this one. It adds complexity, but the complexity helps verification of the code. In this way, the dtc can do some parsing of the id's and tell the user immediately if there is a problem with the names, rather than having to wait for a full compile step and a hard-to-trace gcc diagnostic. Easier debugging and porting was always one of my goals for v3, but I fear the code may become unreadable by the added parsing. Post a patch and we'll see. Regards, Carl-Daniel -- coreboot mailing list coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] r3070 - trunk/util/flashrom
Author: hailfinger
Date: 2008-01-22 16:19:01 +0100 (Tue, 22 Jan 2008)
New Revision: 3070
Modified:
trunk/util/flashrom/flashrom.c
Log:
Flashrom did not use the read function for verifying, it used direct memory
access instead. That fails if the flash chip is not mapped completely.
If the read function is set in struct flashchip, use it for verification
as well.
This fixes verification of all SPI flash chips 512 kByte behind an
IT8716F flash translation chip.
MX25L8005 found at physical address 0xfff0.
Flash part is MX25L8005 (1024 KB).
Flash image seems to be a legacy BIOS. Disabling checks.
Verifying flash... VERIFIED.
Signed-off-by: Carl-Daniel Hailfinger [EMAIL PROTECTED]
Acked-by: Harald Gutmann [EMAIL PROTECTED]
Modified: trunk/util/flashrom/flashrom.c
===
--- trunk/util/flashrom/flashrom.c 2008-01-22 14:37:31 UTC (rev 3069)
+++ trunk/util/flashrom/flashrom.c 2008-01-22 15:19:01 UTC (rev 3070)
@@ -159,7 +159,11 @@
{
int idx;
int total_size = flash-total_size * 1024;
- volatile uint8_t *bios = flash-virtual_memory;
+ uint8_t *buf2 = (uint8_t *) calloc(total_size, sizeof(char));
+ if (flash-read == NULL)
+ memcpy(buf2, (const char *)flash-virtual_memory, total_size);
+ else
+ flash-read(flash, buf2);
printf(Verifying flash... );
@@ -170,7 +174,7 @@
if (verbose ((idx 0xfff) == 0xfff))
printf(0x%08x, idx);
- if (*(bios + idx) != *(buf + idx)) {
+ if (*(buf2 + idx) != *(buf + idx)) {
if (verbose) {
printf(0x%08x , idx);
}
--
coreboot mailing list
coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] r3070 - trunk/util/flashrom
Author: hailfinger
Date: 2008-01-22 16:19:01 +0100 (Tue, 22 Jan 2008)
New Revision: 3070
Modified:
trunk/util/flashrom/flashrom.c
Log:
Flashrom did not use the read function for verifying, it used direct memory
access instead. That fails if the flash chip is not mapped completely.
If the read function is set in struct flashchip, use it for verification
as well.
This fixes verification of all SPI flash chips 512 kByte behind an
IT8716F flash translation chip.
MX25L8005 found at physical address 0xfff0.
Flash part is MX25L8005 (1024 KB).
Flash image seems to be a legacy BIOS. Disabling checks.
Verifying flash... VERIFIED.
Signed-off-by: Carl-Daniel Hailfinger [EMAIL PROTECTED]
Acked-by: Harald Gutmann [EMAIL PROTECTED]
Modified: trunk/util/flashrom/flashrom.c
===
--- trunk/util/flashrom/flashrom.c 2008-01-22 14:37:31 UTC (rev 3069)
+++ trunk/util/flashrom/flashrom.c 2008-01-22 15:19:01 UTC (rev 3070)
@@ -159,7 +159,11 @@
{
int idx;
int total_size = flash-total_size * 1024;
- volatile uint8_t *bios = flash-virtual_memory;
+ uint8_t *buf2 = (uint8_t *) calloc(total_size, sizeof(char));
+ if (flash-read == NULL)
+ memcpy(buf2, (const char *)flash-virtual_memory, total_size);
+ else
+ flash-read(flash, buf2);
printf(Verifying flash... );
@@ -170,7 +174,7 @@
if (verbose ((idx 0xfff) == 0xfff))
printf(0x%08x, idx);
- if (*(bios + idx) != *(buf + idx)) {
+ if (*(buf2 + idx) != *(buf + idx)) {
if (verbose) {
printf(0x%08x , idx);
}
--
coreboot mailing list
coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [LinuxBIOS] Please add support for MX25L8005 and MX25L3205D
Here is just a little and simple patch to get the MX25L3205D working.
I've tested and verified the chip myself, and it seems to work everything like
supposted, since Carl has patched flashrom to use the read funktion on
verifying.
benchvice flashrom # ./flashrom -m gigabyte:m57sli -v test.4mb
Calibrating delay loop... OK.
No coreboot table found.
Found chipset NVIDIA MCP55, enabling flash write... OK.
Found board GIGABYTE GA-M57SLI-S4: enabling flash write... Serial flash
segment 0xfffe-0x enabled
Serial flash segment 0x000e-0x000f enabled
Serial flash segment 0xffee-0xffef disabled
Serial flash segment 0xfff8-0xfffe enabled
LPC write to serial flash enabled
serial flash pin 29
OK.
MX25L3205 found at physical address 0xffc0.
Flash part is MX25L3205 (4096 KB).
Flash image seems to be a legacy BIOS. Disabling checks.
Verifying flash... VERIFIED.
benchvice flashrom # ls -lh test.4mb
-rw-r--r-- 1 root root 4,0M 22. Jan 16:27 test.4mb
benchvice flashrom # ls -l test.4mb
-rw-r--r-- 1 root root 4194304 22. Jan 16:27 test.4mb
benchvice flashrom #
Signed-off-by: Harald Gutmann [EMAIL PROTECTED]
Index: flashchips.c
===
--- flashchips.c(Revision 3070)
+++ flashchips.c(Arbeitskopie)
@@ -54,6 +54,8 @@
probe_spi, generic_spi_chip_erase_c7,
generic_spi_chip_write, generic_spi_chip_read},
{MX25L8005, MX_ID, MX_25L8005, 1024, 256,
probe_spi, generic_spi_chip_erase_c7,
generic_spi_chip_write, generic_spi_chip_read},
+ {MX25L3205, MX_ID, MX_25L3205, 4096, 256,
+probe_spi, generic_spi_chip_erase_c7,
generic_spi_chip_write, generic_spi_chip_read},
{SST25VF040B, SST_ID, SST_25VF040B, 512,256,
probe_spi, generic_spi_chip_erase_c7,
generic_spi_chip_write, generic_spi_chip_read},
{SST25VF016B, SST_ID, SST_25VF016B, 2048, 256,
--
coreboot mailing list
coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH] flashrom: use the read function for verifying
On 22.01.2008 16:10, Harald Gutmann wrote: Am Dienstag, 22. Januar 2008 15:59:28 schrieb Carl-Daniel Hailfinger: Flashrom did not use the read function for verifying, it used direct memory access instead. That fails if the flash chip is not mapped completely. If the read function is set in struct flashchip, use it for verification as well. This fixes verification of all SPI flash chips 512 kByte behind an IT8716F flash translation chip. Signed-off-by: Carl-Daniel Hailfinger [EMAIL PROTECTED] Acked-by: Harald Gutmann [EMAIL PROTECTED] MX25L8005 found at physical address 0xfff0. Flash part is MX25L8005 (1024 KB). Flash image seems to be a legacy BIOS. Disabling checks. Verifying flash... VERIFIED. Thanks, r3070. Regards, Carl-Daniel -- coreboot mailing list coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH] flashrom: use the read function for verifying
On Tue, Jan 22, 2008 at 03:59:28PM +0100, Carl-Daniel Hailfinger wrote:
Flashrom did not use the read function for verifying, it used direct memory
access instead. That fails if the flash chip is not mapped completely.
If the read function is set in struct flashchip, use it for verification
as well.
This fixes verification of all SPI flash chips 512 kByte behind an
IT8716F flash translation chip.
Signed-off-by: Carl-Daniel Hailfinger [EMAIL PROTECTED]
Index: flashrom-big/flashrom.c
===
--- flashrom-big/flashrom.c (Revision 3069)
+++ flashrom-big/flashrom.c (Arbeitskopie)
@@ -159,7 +159,11 @@
{
int idx;
int total_size = flash-total_size * 1024;
- volatile uint8_t *bios = flash-virtual_memory;
+ uint8_t *buf2 = (uint8_t *) calloc(total_size, sizeof(char));
sizeof(char) is 1 per definition in ANSI C, no need for sizeof here.
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] [LinuxBIOS] Please add support for MX25L8005 and MX25L3205D
On 22.01.2008 16:34, Harald Gutmann wrote: Here is just a little and simple patch to get the MX25L3205D working. I've tested and verified the chip myself, and it seems to work everything like supposted, since Carl has patched flashrom to use the read funktion on verifying. benchvice flashrom # ./flashrom -m gigabyte:m57sli -v test.4mb Calibrating delay loop... OK. No coreboot table found. Found chipset NVIDIA MCP55, enabling flash write... OK. Found board GIGABYTE GA-M57SLI-S4: enabling flash write... Serial flash segment 0xfffe-0x enabled Serial flash segment 0x000e-0x000f enabled Serial flash segment 0xffee-0xffef disabled Serial flash segment 0xfff8-0xfffe enabled LPC write to serial flash enabled serial flash pin 29 OK. MX25L3205 found at physical address 0xffc0. Flash part is MX25L3205 (4096 KB). Flash image seems to be a legacy BIOS. Disabling checks. Verifying flash... VERIFIED. benchvice flashrom # ls -lh test.4mb -rw-r--r-- 1 root root 4,0M 22. Jan 16:27 test.4mb benchvice flashrom # ls -l test.4mb -rw-r--r-- 1 root root 4194304 22. Jan 16:27 test.4mb benchvice flashrom # Signed-off-by: Harald Gutmann [EMAIL PROTECTED] Acked-by: Carl-Daniel Hailfinger [EMAIL PROTECTED] Thanks, r3072. Regards, Carl-Daniel -- coreboot mailing list coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH] flashrom: use the read function for verifying
On 22.01.2008 16:59, Uwe Hermann wrote:
On Tue, Jan 22, 2008 at 03:59:28PM +0100, Carl-Daniel Hailfinger wrote:
Flashrom did not use the read function for verifying, it used direct memory
access instead. That fails if the flash chip is not mapped completely.
If the read function is set in struct flashchip, use it for verification
as well.
This fixes verification of all SPI flash chips 512 kByte behind an
IT8716F flash translation chip.
Signed-off-by: Carl-Daniel Hailfinger [EMAIL PROTECTED]
Index: flashrom-big/flashrom.c
===
--- flashrom-big/flashrom.c (Revision 3069)
+++ flashrom-big/flashrom.c (Arbeitskopie)
@@ -159,7 +159,11 @@
{
int idx;
int total_size = flash-total_size * 1024;
-volatile uint8_t *bios = flash-virtual_memory;
+uint8_t *buf2 = (uint8_t *) calloc(total_size, sizeof(char));
sizeof(char) is 1 per definition in ANSI C, no need for sizeof here.
This was a cut-and-paste from the read function in flashrom. You can
post a cleaunp patch if you want.
Regards,
Carl-Daniel
--
coreboot mailing list
coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [LinuxBIOS] flashrom on ga 2761gxdk
Ron?
On 10.01.2008 13:32, Carl-Daniel Hailfinger wrote:
Btw, the block lock bits are all set, so even if you manage to convince
the SPI translation to map more than 512 KByte and even if you use
enable LPC-to-SPI writes, you will still flash nothing. Try this for
better lock bit printing:
Enable LPC write cycle to SPI write cycle translation for IT8716F.
Print detailed status register information for SST25VF series flash.
Signed-off-by: Carl-Daniel Hailfinger [EMAIL PROTECTED]
Index: flashrom-ron/spi.c
===
--- flashrom-ron/spi.c(Revision 3036)
+++ flashrom-ron/spi.c(Arbeitskopie)
@@ -136,6 +136,11 @@
0xFFF8, 0xFFFE, (tmp 1 3) ? en : dis);
printf(LPC write to serial flash %sabled\n,
(tmp 1 4) ? en : dis);
+ if (!(tmp 1 4)) {
+ printf(Force enabling LPC write to serial flash\n);
+ tmp |= 1 4;
+ regwrite(port, 0x24, tmp);
+ }
printf(serial flash pin %i\n, (tmp 1 5) ? 87 : 29);
/* LDN 0x7, reg 0x64/0x65 */
regwrite(port, 0x07, 0x7);
@@ -323,7 +328,8 @@
switch (flash-manufacture_id) {
case ST_ID:
case MX_ID:
- if ((flash-model_id 0xff00) == 0x2000)
+ if (((flash-model_id 0xff00) == 0x2000) ||
+ ((flash-model_id 0xff00) == 0x2500))
generic_spi_prettyprint_status_register_st_m25p(status);
break;
}
--
http://www.hailfinger.org/
--
coreboot mailing list
coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [LinuxBIOS] Patch file for ld/fedora 8 issue as promised...
On 22.01.2008 16:47, Marc Karasek wrote: Been away for the weekend. Sun was closed on Monday. Signed of by Marc Karasek [EMAIL PROTECTED] Carl-Daniel Hailfinger wrote: On 09.01.2008 16:13, Marc Karasek wrote: Attached is the latest. It uses -ge instead of == or . This will take care of any time that there are more than 1 build-id in the ld -help output. Myles Watson wrote: I like the idea of using grep. It seems much cleaner, and avoids that issue. Myles Watson wrote: Sorry to be picky, but it seems like this breaks if they mention build-id more than once in the help in the future. I think 0 would be better than ==1. With that fixed, or if no one thinks that will ever happen: Acked-by: Myles Watson [EMAIL PROTECTED] If we used grep, the buildtarget snippet could probably be made a bit smaller: ld --help | grep -q build-id EXTRA_LFLAGS+= -Wl,--build-id=none Next try (does not (yet?) use grep): Marc, I could not find your Signed-off-by: in the thread. If that patch is OK for you, please sign off on it. Signed-off-by: Carl-Daniel Hailfinger [EMAIL PROTECTED] Thanks, r3073. Regards, Carl-Daniel -- coreboot mailing list coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] r3073 - in trunk/coreboot-v2: src/config targets
Author: hailfinger
Date: 2008-01-22 17:09:36 +0100 (Tue, 22 Jan 2008)
New Revision: 3073
Modified:
trunk/coreboot-v2/src/config/Config.lb
trunk/coreboot-v2/targets/buildtarget
Log:
Use --build-id=none as linker flags if build-id is supported.
That fixes a compilation failure.
Signed-off-by: Marc Karasek [EMAIL PROTECTED]
Signed-off-by: Carl-Daniel Hailfinger [EMAIL PROTECTED]
Acked-by: Joseph Smith [EMAIL PROTECTED]
Acked-by: Myles Watson [EMAIL PROTECTED]
Modified: trunk/coreboot-v2/src/config/Config.lb
===
--- trunk/coreboot-v2/src/config/Config.lb 2008-01-22 16:03:19 UTC (rev
3072)
+++ trunk/coreboot-v2/src/config/Config.lb 2008-01-22 16:09:36 UTC (rev
3073)
@@ -8,7 +8,7 @@
makedefine GCC_INC_DIR := $(shell LC_ALL=C $(CC) -print-search-dirs | sed -ne
s/install: \(.*\)/\1include/gp)
makedefine CPPFLAGS := -I$(TOP)/src/include -I$(TOP)/src/arch/$(ARCH)/include
-I$(GCC_INC_DIR) $(CPUFLAGS)
-makedefine CFLAGS := $(CPU_OPT) $(CPPFLAGS) -Os -nostdinc -nostdlib
-fno-builtin -Wall
+makedefine CFLAGS := $(CPU_OPT) $(DISTRO_CFLAGS) $(CPPFLAGS) -Os -nostdinc
-nostdlib -fno-builtin -Wall
makedefine HOSTCFLAGS:= -Os -Wall
@@ -38,14 +38,15 @@
action ar cr coreboot.a $(OBJECTS)
end
+
makerule coreboot_ram.o
depends $(DRIVER) coreboot.a $(LIBGCC_FILE_NAME)
- action $(CC) -nostdlib -r -o $@ c_start.o $(DRIVER) coreboot.a
$(LIBGCC_FILE_NAME)
+ action $(CC) $(DISTRO_LFLAGS) -nostdlib -r -o $@ c_start.o $(DRIVER)
coreboot.a $(LIBGCC_FILE_NAME)
end
makerule coreboot_ram
depends coreboot_ram.o $(TOP)/src/config/coreboot_ram.ld ldoptions
- action $(CC) -nostdlib -nostartfiles -static -o $@ -T
$(TOP)/src/config/coreboot_ram.ld coreboot_ram.o
+ action $(CC) $(DISTRO_LFLAGS) -nostdlib -nostartfiles -static -o $@
-T $(TOP)/src/config/coreboot_ram.ld coreboot_ram.o
action $(CROSS_COMPILE)nm -n coreboot_ram | sort coreboot_ram.map
end
@@ -83,12 +84,12 @@
makerule coreboot_apc.o
depends coreboot_apc.a c_start.o $(LIBGCC_FILE_NAME)
-action $(CC) -nostdlib -r -o $@ c_start.o coreboot_apc.a
$(LIBGCC_FILE_NAME)
+action $(CC) $(DISTRO_LFLAGS) -nostdlib -r -o $@ c_start.o
coreboot_apc.a $(LIBGCC_FILE_NAME)
end
makerule coreboot_apc
depends coreboot_apc.o $(TOP)/src/config/coreboot_apc.ld
ldoptions
- action $(CC) -nostdlib -nostartfiles -static -o $@ -T
$(TOP)/src/config/coreboot_apc.ld coreboot_apc.o
+ action $(CC) $(DISTRO_LFLAGS) -nostdlib -nostartfiles -static
-o $@ -T $(TOP)/src/config/coreboot_apc.ld coreboot_apc.o
action $(CROSS_COMPILE)nm -n coreboot_apc | sort
coreboot_apc.map
end
@@ -121,7 +122,7 @@
makerule coreboot
depends crt0.o $(INIT-OBJECTS) $(COREBOOT_APC) $(COREBOOT_RAM_ROM)
ldscript.ld
- action $(CC) -nostdlib -nostartfiles -static -o $@ -T ldscript.ld
crt0.o $(INIT-OBJECTS)
+ action $(CC) $(DISTRO_LFLAGS) -nostdlib -nostartfiles -static -o $@
-T ldscript.ld crt0.o $(INIT-OBJECTS)
action $(CROSS_COMPILE)nm -n coreboot | sort coreboot.map
end
Modified: trunk/coreboot-v2/targets/buildtarget
===
--- trunk/coreboot-v2/targets/buildtarget 2008-01-22 16:03:19 UTC (rev
3072)
+++ trunk/coreboot-v2/targets/buildtarget 2008-01-22 16:09:36 UTC (rev
3073)
@@ -69,9 +69,16 @@
rm -rf .$$.tmp
+ld --help | awk '{for (i=1;i=NF;i++) if ($i ~ /build-id/){n++} }; END {exit
n}'
+build_id=$?
+if [ $build_id -ge 1 ] ; then
+ EXTRA_LFLAGS+= -Wl,--build-id=none
+fi
+
for i in $build_dir/Makefile.settings $build_dir/*/Makefile.settings
do
- echo CFLAGS+=$EXTRA_CFLAGS $i
+ echo DISTRO_CFLAGS+=$EXTRA_CFLAGS $i
+ echo DISTRO_LFLAGS+=$EXTRA_LFLAGS $i
done
exit $?
--
coreboot mailing list
coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] problems using svn co https://coreboot.org/svn/trunk/coreboot-v2
On Tue, Jan 22, 2008 at 10:17:23PM +0800, bxshi wrote: when I check out the code by : svn co https://coreboot.org/svn/trunk/coreboot-v2 it begin to download, .. Acoreboot-v2/util/resetcf Acoreboot-v2/util/resetcf/resetcf.c Acoreboot-v2/util/buildrom Acoreboot-v2/util/buildrom/buildrom.c U coreboot-v2 Fetching external item into 'coreboot-v2/util/flashrom' svn: Unknown hostname 'linuxbios.org' I changed the svn:externals to use coreboot.org in v2 now, but I'm not sure this will fix all your problems. The externals use svn:// (not https://) so the firewalling problems will probably remain. As a workaround you can checkout the util/* directories (such as flashrom, superiotool, etc) manually using https, if you need them: svn co https://coreboot.org/svn/trunk/util/flashrom svn co https://coreboot.org/svn/trunk/util/superiotool etc. HTH, 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] r3072 - trunk/util/flashrom
Author: hailfinger
Date: 2008-01-22 17:03:19 +0100 (Tue, 22 Jan 2008)
New Revision: 3072
Modified:
trunk/util/flashrom/flashchips.c
Log:
Here is just a little and simple patch to get the MX25L3205D working.
I've tested and verified the chip myself, and it seems to work
everything like supposted, since Carl-Daniel has patched flashrom to
use the read funktion on verifying.
benchvice flashrom # ./flashrom -m gigabyte:m57sli -v test.4mb
Calibrating delay loop... OK.
No coreboot table found.
Found chipset NVIDIA MCP55, enabling flash write... OK.
Found board GIGABYTE GA-M57SLI-S4: enabling flash write...
Serial flash segment 0xfffe-0x enabled
Serial flash segment 0x000e-0x000f enabled
Serial flash segment 0xffee-0xffef disabled
Serial flash segment 0xfff8-0xfffe enabled
LPC write to serial flash enabled
serial flash pin 29
OK.
MX25L3205 found at physical address 0xffc0.
Flash part is MX25L3205 (4096 KB).
Flash image seems to be a legacy BIOS. Disabling checks.
Verifying flash... VERIFIED.
benchvice flashrom # ls -l test.4mb
-rw-r--r-- 1 root root 4194304 22. Jan 16:27 test.4mb
Signed-off-by: Harald Gutmann [EMAIL PROTECTED]
Acked-by: Carl-Daniel Hailfinger [EMAIL PROTECTED]
Modified: trunk/util/flashrom/flashchips.c
===
--- trunk/util/flashrom/flashchips.c2008-01-22 16:00:46 UTC (rev 3071)
+++ trunk/util/flashrom/flashchips.c2008-01-22 16:03:19 UTC (rev 3072)
@@ -54,6 +54,8 @@
probe_spi, generic_spi_chip_erase_c7, generic_spi_chip_write,
generic_spi_chip_read},
{MX25L8005, MX_ID, MX_25L8005, 1024, 256,
probe_spi, generic_spi_chip_erase_c7, generic_spi_chip_write,
generic_spi_chip_read},
+ {MX25L3205, MX_ID, MX_25L3205, 4096, 256,
+probe_spi, generic_spi_chip_erase_c7, generic_spi_chip_write,
generic_spi_chip_read},
{SST25VF040B, SST_ID, SST_25VF040B, 512,256,
probe_spi, generic_spi_chip_erase_c7, generic_spi_chip_write,
generic_spi_chip_read},
{SST25VF016B, SST_ID, SST_25VF016B, 2048, 256,
--
coreboot mailing list
coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [LinuxBIOS] Intel 3100 chipset, version 2
On 21.01.2008 17:42, Ed Swierk wrote: On Dec 27, 2007 4:25 PM, Carl-Daniel Hailfinger [EMAIL PROTECTED] wrote: I'm currently reviewing the rest of the patch. Looks nice so far. There's no urgency, but I'm wondering if there's anything I can do to help. I'm sorry, but I'm swamped with thesis work right now and will not have time to review until end of February at the earliest? Can you find someone else for the review? Regards, Carl-Daniel -- coreboot mailing list coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [LinuxBIOS] [Fwd: Re: AMD 690G chipset support in LinuxBIOS v2]
Darmawan Salihun wrote: Hi Marc, On Jan 22, 2008 1:21 AM, Marc Jones [EMAIL PROTECTED] wrote: The 690/600 support should be available in the first half of this year. We moved it out a few months to bring in the Barcelona support. I don't have specific dates but we will announce the code to the list as soon as it is available. The support would be on coreboot v2?linuxbios v2 right? Yes Marc -- Marc Jones Senior Firmware Engineer (970) 226-9684 Office mailto:[EMAIL PROTECTED] http://www.amd.com/embeddedprocessors -- coreboot mailing list coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [LinuxBIOS] flashrom on ga 2761gxdk
On Jan 22, 2008 8:27 AM, Carl-Daniel Hailfinger [EMAIL PROTECTED] wrote: Ron? See my other note, this works but verify did not, which I think you also just fixed. The board still does not boot or even POST for me. I am wishing I had some 512kB parts. ron -- coreboot mailing list coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] SST25VF016B (2MB) flash on m57sli (IT8716F).
Carl-Daniel Hailfinger wrote: Harald: This patch should fix your problems writing to the chip. Use either patch -l or remove the // before //while (generic_spi_read_status_register() JEDEC_RDSR_BIT_WIP) Ronald: I need an ack to commit this. On 20.01.2008 11:59, Ronald Hoogenboom wrote: Carl-Daniel Hailfinger wrote: Did you have time to test with the while (generic_spi_read_status_register() .._WIP) enabled? It would be more correct to have it enabled. I had that in initially (that's why it was there, but commented out) but all it got me was slower programming times and the datasheet also suggests it is ok to just do a timed wait. But in the face of genericness for other chips, it is indeed more correct to do the check for the busy bit. Ronald/Harald, can you please ack the change? It is reproduced below (whichspace-damaged). Regards, Carl-Daniel Make sure we delay writing the next byte long enough in SPI byte programming. Minor formatting changes. Signed-off-by: Carl-Daniel Hailfinger [EMAIL PROTECTED] Acked-by: Ronald Hoogenboom [EMAIL PROTECTED] -- coreboot mailing list coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] PCI BIOS Extension ROM in v3
Coreboot v3 refuses to initialize the VGA in QEMU because the PCI device ID's are mismatched. It turns out that the header has been overwritten by a copyright string, so that v3 is following a bad pointer into the ROM looking for the PCI device IDs and not finding it. Coreboot v2 still successfully initializes the VGA because it skips the vendor check. The question is if we should make the vendor check a warning instead of failing. I realize that the right thing to do is fix the ROM, but there may be other broken ROMs as well. Another thing we could do is only fail on a mismatched ID if we find a correct PCIR signature on the data section. Myles -- coreboot mailing list coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] progress on lx
On Tue, Jan 22, 2008 at 04:19:11PM +0100, Carl-Daniel Hailfinger wrote: I am thinking of something like this: id=pci,somevendorname,somedevicename; Makes sense if the coreboot code itself does not have to perform any string parsing. Small thing; I would prefer something else than a comma after the type, so that it is separated from the real information. Maybe: id=pci:vendor,device; I think that would make the syntax much more clear. Further, in the dtc makefile I would like to preprocess pci_ids.h to produce arrays of char * with a list of vendor and device names. Then the dtc tool can do the following: check the path type (pci). Check that it has the proper arguments (device, path). Then check the vendor name and device name to make sure they are valid for that path type. I'm undecided about this one. It adds complexity, but the complexity helps verification of the code. But it's buildtime complexity which must be better than runtime complexity, and definately better than runtime failure. //Peter -- coreboot mailing list coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] PCI BIOS Extension ROM in v3
On Jan 22, 2008 10:20 AM, Carl-Daniel Hailfinger [EMAIL PROTECTED] wrote: I'd say we refuse to execute the ROM in v3. If the ROM is broken, we have no way to determine how broken it is. Unconditional execution may prevent booting the machine, thereby forcing an out-of-system flash of coreboot with ROM execution disabled. I agree. I have yet to see a real ROM broken in this way. Print the warning message and refuse to run it. And get QEMU to fix both their broken VGA rom and their broken BIOS :-) ron -- coreboot mailing list coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] progress on lx
On Jan 22, 2008 10:46 AM, Peter Stuge [EMAIL PROTECTED] wrote: Small thing; I would prefer something else than a comma after the type, so that it is separated from the real information. Maybe: id=pci:vendor,device; I think that would make the syntax much more clear. Thats fine with me, it is not really the standard for the dts but I think we'd be better off making it clear. Further, in the dtc makefile I would like to preprocess pci_ids.h to produce arrays of char * with a list of vendor and device names. Then the dtc tool can do the following: check the path type (pci). Check that it has the proper arguments (device, path). Then check the vendor name and device name to make sure they are valid for that path type. I'm undecided about this one. It adds complexity, but the complexity helps verification of the code. But it's buildtime complexity which must be better than runtime complexity, and definately better than runtime failure. That's my hope. I'm happy to make the buildtime more complex, as long as it is more work for US, not the USERS :-) I think we're going to benefit from increased error checking in the dts. thanks ron -- coreboot mailing list coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] I just can't believe it
brand new shuttle box phoenix-award bios keyboard error or no keyboard present Press F1 to continue It's just too funny. Imagine a beowulf of these! ron -- coreboot mailing list coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] LinuxBIOS on VIA EPIA EN15000
On Tue, Jan 22, 2008 at 10:29:17AM +0100, [EMAIL PROTECTED] wrote: I own a VIA EPIA EN15000 Motherboard .. Is there a chance to get my board working ? Some, if you have time to hack a bit. Can anybody tell me what to do ? Corey Osgood has posted a C7/CN700 patch to the list. It has been tested by at least one other person but I believe it still has some caveats. Dig it out and try to make a coreboot port for your board. Please feel free to ask questions on this list or on irc.freenode.net #coreboot and we'll try to help. //Peter -- coreboot mailing list coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [cbv2]Add serial port information to lbtable
On Tue, Jan 22, 2008 at 09:43:35PM +0100, Patrick Georgi wrote:
This patch adds a new record type for lbtable to provide information
about a serial port. If a port is defined in the board configuration,
add it to lbtable.
Signed-off-by: Patrick Georgi [EMAIL PROTECTED]
Acked-by: Peter Stuge [EMAIL PROTECTED]
Index: src/include/boot/coreboot_tables.h
===
--- src/include/boot/coreboot_tables.h(Revision 3066)
+++ src/include/boot/coreboot_tables.h(Arbeitskopie)
@@ -138,6 +138,13 @@
uint8_t string[0];
};
+#define LB_TAG_SERIAL0x000f
+struct lb_serial {
+ uint32_t tag;
+ uint32_t size;
+ uint16_t ioport;
+};
+
/* The following structures are for the cmos definitions table */
#define LB_TAG_CMOS_OPTION_TABLE 200
/* cmos header record */
Index: src/arch/i386/boot/coreboot_table.c
===
--- src/arch/i386/boot/coreboot_table.c (Revision 3066)
+++ src/arch/i386/boot/coreboot_table.c (Arbeitskopie)
@@ -74,6 +74,22 @@
return mem;
}
+struct lb_serial *lb_serial(struct lb_header *header)
+{
+#if defined(TTYS0_BASE)
+ struct lb_record *rec;
+ struct lb_serial *serial;
+ rec = lb_new_record(header);
+ serial = (struct lb_serial *)rec;
+ serial-tag = LB_TAG_SERIAL;
+ serial-size = sizeof(*serial);
+ serial-ioport = TTYS0_BASE;
+ return serial;
+#else
+ return header;
+#endif
+}
+
struct lb_mainboard *lb_mainboard(struct lb_header *header)
{
struct lb_record *rec;
@@ -406,8 +422,10 @@
* size of the coreboot table.
*/
- /* Record our motheboard */
+ /* Record our motherboard */
lb_mainboard(head);
+ /* Record the serial port, if present */
+ lb_serial(head);
/* Record our various random string information */
lb_strings(head);
--
coreboot mailing list
coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] linuxbios/coreboot summit in denver, CO
Don't try to register for the hotel just yet, as we are getting the conf. rate extended to april 6. But if people could start registering it would help us a great deal with arrangements. Also, potential sponsors, please contact me if you can help support this meeting. If you can buy a six-pack of soda, we'll put your logo on it! No amount too small :-) http://www.hpcsw.org/index.shtml Thanks ron -- coreboot mailing list coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [LinuxBIOS] flashrom on ga 2761gxdk
OK, with 3073, something went worse.
Last night, I was flashing just fine. As of today, it's not id'ing it
and it is reading 0xff back for that pass. I am attaching a failed
(first) and successfull on the 4mbit part (second half) of the file.
I'm trying to get to the point of trying to figure out if this 2M part
will ever work on this board. I am beginning to have my doubts.
My only remaining differences are this:
Index: spi.c
===
--- spi.c (revision 3073)
+++ spi.c (working copy)
@@ -155,6 +155,12 @@
0xFFF8, 0xFFFE, (tmp 1 3) ? en : dis);
printf(LPC write to serial flash %sabled\n,
(tmp 1 4) ? en : dis);
+ if (!(tmp 1 4)) {
+ printf(Force enabling LPC write to serial flash\n);
+ tmp |= 1 4;
+ regwrite(port, 0x24, tmp);
+ }
+ printf(serial flash pin %i\n, (tmp 1 5) ? 87 : 29);
printf(serial flash pin %i\n, (tmp 1 5) ? 87 : 29);
/* LDN 0x7, reg 0x64/0x65 */
regwrite(port, 0x07, 0x7);
@@ -375,7 +381,8 @@
switch (flash-manufacture_id) {
case ST_ID:
case MX_ID:
- if ((flash-model_id 0xff00) == 0x2000)
+ if (((flash-model_id 0xff00) == 0x2000) ||
+ ((flash-model_id 0xff00) == 0x2500))
spi_prettyprint_status_register_st_m25p(status);
break;
case SST_ID:
flashout
Description: Binary data
--
coreboot mailing list
coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
