[coreboot] [updated PATCH] Re: [cbv2]Add serial port information to lbtable

[Patrick Georgi]

Am Donnerstag, den 17.01.2008, 12:55 +0100 schrieb Torsten Duwe:
> On Wednesday 16 January 2008, Stefan Reinauer wrote:
> > * Uwe Hermann <[EMAIL PROTECTED]> [080116 16:03]:
> > > This doesn't look generic enough(?) Where does TTYS0_BASE come from?
> 
> Agreed.
TTYS0_BASE seems to be the standard name used across the code base.
The attached patch provides a no-op in case the configuration doesn't
provide a serial port.

> > > I think not all of the boards define it, and even if they did,
> > > TTYS0_BASE implies COM1, which is not always what you want.
> > > We need a mechanism to allow other ports here (COM2, COM3, COM4).
> 
> This goes off into the wrong direction, IMO.
The codebase doesn't seem to be prepared for multiple serial ports in
the first place (I only find TTYS0_*). I'd say, we add a port number to
the record once we actually support >1 ports.

> Both not appropriate, strictly. There is only one serial port, for the 
> console 
> at best that everyone needs to care about until an OS is loaded.
As my initial query
(http://www.coreboot.org/pipermail/coreboot/2008-January/029192.html)
got no response, I decided to just work on the problem at hand, which is
- in my case - a hand over of information about the serial port (which
we don't do at all currently).

As you can see, my patch doesn't pretend that the serial port is the console, 
so a "you can find the console $here" record can be added without conflicts. 
That new record could then refer to the serial port as specified here, in case 
the console is on serial.

> The questions are:
> 1. of what type is the active console?
> a) VGA-compatible
> b) 8250-compatible
> c) ...
Different issue (see above)

> 3. Is there additional information? A smarter payload might want to use e.g. 
> the interrupt that we assigned to the port ;-)
Once we do that, the serial record could be extended by that
information. Given that we have a size field in the record, that can
even be done in a compatible way, or not?

I'll do patches for lxbios and v3 once this patch (and more importantly,
the record format) is accepted.
This patch is updated against latest svn, and provides an alternative in
case TTYS0_BASE isn't defined (see the #ifdef).


Regards,
Patrick Georgi
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]>

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_SERIAL  0x000e
+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 our console */
+   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

Re: [coreboot] [Patch] winbond w83627DHG superio support in superiotool

[Uwe Hermann]

On Mon, Jan 21, 2008 at 10:07:02AM +0800, bxshi wrote:
> OK, here is the output file .
> 
> bxshi

> superiotool r
> Found Winbond W83627DHG (id=0xa0, rev=0x23) at 0x4e
> Register dump:
> idx 02 20 21 22 23 24 25 26  27 28 29 2a 2b 2c 2d 2e  2f
> val ff a0 23 ff 00 40 00 40  ff 50 80 02 00 03 21 00  ff
> def 00 a0 NA ff 00 MM 00 MM  RR 50 00 00 RR e2 21 00  00

Thanks, I added a link to the wiki.


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] r3067 - trunk/util/flashrom

[svn]

Author: uwe
Date: 2008-01-21 16:24:22 +0100 (Mon, 21 Jan 2008)
New Revision: 3067

Modified:
   trunk/util/flashrom/Makefile
   trunk/util/flashrom/flashrom.8
   trunk/util/flashrom/flashrom.c
Log:
This patch adds version information to flashrom. Because 'v' and 'V'
are already in use, the patch uses 'R' (for release) and, of course,
'--version'.

Signed-off-by: Bernhard Walle <[EMAIL PROTECTED]>
Acked-by: Ulf Jordan <[EMAIL PROTECTED]>
Acked-by: Uwe Hermann <[EMAIL PROTECTED]>



Modified: trunk/util/flashrom/Makefile
===
--- trunk/util/flashrom/Makefile2008-01-20 01:59:43 UTC (rev 3066)
+++ trunk/util/flashrom/Makefile2008-01-21 15:24:22 UTC (rev 3067)
@@ -28,6 +28,12 @@
 
 all: pciutils dep $(PROGRAM)
 
+# Set the flashrom version string from the highest revision number
+# of the checked out flashrom files.
+SVNDEF := -D'FLASHROM_VERSION="$(shell svnversion -cn . \
+  | sed -e "s/.*://" -e "s/\([0-9]*\).*/\1/")"'
+CFLAGS += $(SVNDEF)
+
 $(PROGRAM): $(OBJS)
$(CC) -o $(PROGRAM) $(OBJS) $(LDFLAGS)
$(STRIP) $(STRIP_ARGS) $(PROGRAM)

Modified: trunk/util/flashrom/flashrom.8
===
--- trunk/util/flashrom/flashrom.8  2008-01-20 01:59:43 UTC (rev 3066)
+++ trunk/util/flashrom/flashrom.8  2008-01-21 15:24:22 UTC (rev 3067)
@@ -2,7 +2,7 @@
 .SH NAME
 flashrom \- a universal BIOS/ROM/flash programming utility
 .SH SYNOPSIS
-.B flashrom \fR[\fB\-rwvEVfh\fR] [\fB\-c\fR chipname] [\fB\-s\fR 
exclude_start] [\fB\-e\fR exclude_end]
+.B flashrom \fR[\fB\-rwvEVfhR\fR] [\fB\-c\fR chipname] [\fB\-s\fR 
exclude_start] [\fB\-e\fR exclude_end]
  [\fB-m\fR vendor:part] [\fB-l\fR file.layout] [\fB-i\fR image_name] 
[file]
 .SH DESCRIPTION
 .B flashrom
@@ -63,9 +63,9 @@
 .TP
 .B "\-h, \-\-help"
 Show a help text and exit.
-.\".TP
-.\".B "\-\-version"
-.\"Show version information and exit.
+.TP
+.B "\-R, \-\-version"
+Show version information and exit.
 .SH BUGS
 Please report any bugs at
 .BR http://tracker.coreboot.org/trac/coreboot/newticket ","

Modified: trunk/util/flashrom/flashrom.c
===
--- trunk/util/flashrom/flashrom.c  2008-01-20 01:59:43 UTC (rev 3066)
+++ trunk/util/flashrom/flashrom.c  2008-01-21 15:24:22 UTC (rev 3067)
@@ -191,7 +191,7 @@
 
 void usage(const char *name)
 {
-   printf("usage: %s [-rwvEVfh] [-c chipname] [-s exclude_start]\n", name);
+   printf("usage: %s [-rwvEVfhR] [-c chipname] [-s exclude_start]\n", 
name);
printf("   [-e exclude_end] [-m vendor:part] [-l file.layout] [-i 
imagename] [file]\n");
printf
("   -r | --read:read flash and save into 
file\n"
@@ -206,11 +206,17 @@
 "   -f | --force:   force write without checking 
image\n"
 "   -l | --layout :read rom layout from file\n"
 "   -i | --image :only flash image name from 
flash layout\n"
+"   -R | --version: print the version (release)\n"
 "\n" " If no file is specified, then all that happens"
 " is that flash info is dumped.\n\n");
exit(1);
 }
 
+void print_version(void)
+{
+   printf("flashrom r%s\n", FLASHROM_VERSION);
+}
+
 int main(int argc, char *argv[])
 {
uint8_t *buf;
@@ -236,6 +242,7 @@
{"layout", 1, 0, 'l'},
{"image", 1, 0, 'i'},
{"help", 0, 0, 'h'},
+   {"version", 0, 0, 'R'},
{0, 0, 0, 0}
};
 
@@ -253,7 +260,7 @@
}
 
setbuf(stdout, NULL);
-   while ((opt = getopt_long(argc, argv, "rwvVEfc:s:e:m:l:i:h",
+   while ((opt = getopt_long(argc, argv, "rRwvVEfc:s:e:m:l:i:h",
  long_options, &option_index)) != EOF) {
switch (opt) {
case 'r':
@@ -306,6 +313,10 @@
tempstr = strdup(optarg);
find_romentry(tempstr);
break;
+   case 'R':
+   print_version();
+   exit(0);
+   break;
case 'h':
default:
usage(argv[0]);


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

[coreboot] r3067 - trunk/util/flashrom

[svn]

Author: uwe
Date: 2008-01-21 16:24:22 +0100 (Mon, 21 Jan 2008)
New Revision: 3067

Modified:
   trunk/util/flashrom/Makefile
   trunk/util/flashrom/flashrom.8
   trunk/util/flashrom/flashrom.c
Log:
This patch adds version information to flashrom. Because 'v' and 'V'
are already in use, the patch uses 'R' (for release) and, of course,
'--version'.

Signed-off-by: Bernhard Walle <[EMAIL PROTECTED]>
Acked-by: Ulf Jordan <[EMAIL PROTECTED]>
Acked-by: Uwe Hermann <[EMAIL PROTECTED]>



Modified: trunk/util/flashrom/Makefile
===
--- trunk/util/flashrom/Makefile2008-01-20 01:59:43 UTC (rev 3066)
+++ trunk/util/flashrom/Makefile2008-01-21 15:24:22 UTC (rev 3067)
@@ -28,6 +28,12 @@
 
 all: pciutils dep $(PROGRAM)
 
+# Set the flashrom version string from the highest revision number
+# of the checked out flashrom files.
+SVNDEF := -D'FLASHROM_VERSION="$(shell svnversion -cn . \
+  | sed -e "s/.*://" -e "s/\([0-9]*\).*/\1/")"'
+CFLAGS += $(SVNDEF)
+
 $(PROGRAM): $(OBJS)
$(CC) -o $(PROGRAM) $(OBJS) $(LDFLAGS)
$(STRIP) $(STRIP_ARGS) $(PROGRAM)

Modified: trunk/util/flashrom/flashrom.8
===
--- trunk/util/flashrom/flashrom.8  2008-01-20 01:59:43 UTC (rev 3066)
+++ trunk/util/flashrom/flashrom.8  2008-01-21 15:24:22 UTC (rev 3067)
@@ -2,7 +2,7 @@
 .SH NAME
 flashrom \- a universal BIOS/ROM/flash programming utility
 .SH SYNOPSIS
-.B flashrom \fR[\fB\-rwvEVfh\fR] [\fB\-c\fR chipname] [\fB\-s\fR 
exclude_start] [\fB\-e\fR exclude_end]
+.B flashrom \fR[\fB\-rwvEVfhR\fR] [\fB\-c\fR chipname] [\fB\-s\fR 
exclude_start] [\fB\-e\fR exclude_end]
  [\fB-m\fR vendor:part] [\fB-l\fR file.layout] [\fB-i\fR image_name] 
[file]
 .SH DESCRIPTION
 .B flashrom
@@ -63,9 +63,9 @@
 .TP
 .B "\-h, \-\-help"
 Show a help text and exit.
-.\".TP
-.\".B "\-\-version"
-.\"Show version information and exit.
+.TP
+.B "\-R, \-\-version"
+Show version information and exit.
 .SH BUGS
 Please report any bugs at
 .BR http://tracker.coreboot.org/trac/coreboot/newticket ","

Modified: trunk/util/flashrom/flashrom.c
===
--- trunk/util/flashrom/flashrom.c  2008-01-20 01:59:43 UTC (rev 3066)
+++ trunk/util/flashrom/flashrom.c  2008-01-21 15:24:22 UTC (rev 3067)
@@ -191,7 +191,7 @@
 
 void usage(const char *name)
 {
-   printf("usage: %s [-rwvEVfh] [-c chipname] [-s exclude_start]\n", name);
+   printf("usage: %s [-rwvEVfhR] [-c chipname] [-s exclude_start]\n", 
name);
printf("   [-e exclude_end] [-m vendor:part] [-l file.layout] [-i 
imagename] [file]\n");
printf
("   -r | --read:read flash and save into 
file\n"
@@ -206,11 +206,17 @@
 "   -f | --force:   force write without checking 
image\n"
 "   -l | --layout :read rom layout from file\n"
 "   -i | --image :only flash image name from 
flash layout\n"
+"   -R | --version: print the version (release)\n"
 "\n" " If no file is specified, then all that happens"
 " is that flash info is dumped.\n\n");
exit(1);
 }
 
+void print_version(void)
+{
+   printf("flashrom r%s\n", FLASHROM_VERSION);
+}
+
 int main(int argc, char *argv[])
 {
uint8_t *buf;
@@ -236,6 +242,7 @@
{"layout", 1, 0, 'l'},
{"image", 1, 0, 'i'},
{"help", 0, 0, 'h'},
+   {"version", 0, 0, 'R'},
{0, 0, 0, 0}
};
 
@@ -253,7 +260,7 @@
}
 
setbuf(stdout, NULL);
-   while ((opt = getopt_long(argc, argv, "rwvVEfc:s:e:m:l:i:h",
+   while ((opt = getopt_long(argc, argv, "rRwvVEfc:s:e:m:l:i:h",
  long_options, &option_index)) != EOF) {
switch (opt) {
case 'r':
@@ -306,6 +313,10 @@
tempstr = strdup(optarg);
find_romentry(tempstr);
break;
+   case 'R':
+   print_version();
+   exit(0);
+   break;
case 'h':
default:
usage(argv[0]);


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

Re: [coreboot] #92: Add --version option

[Uwe Hermann]

On Mon, Jan 21, 2008 at 08:32:24AM +0100, Ulf Jordan wrote:
> > This patch adds version information to flashrom. Because 'v' and 'V'
> > are already in use, the patch uses 'R' (for release) and, of course,
> > '--version'.
> > 
> > Signed-off-by: Bernhard Walle <[EMAIL PROTECTED]>
> 
> Acked-by: Ulf Jordan <[EMAIL PROTECTED]>

Thanks, committed in r3067. I also updated the manpage with the new option.


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] #92: Add --version option

[coreboot]

#92: Add --version option
-+--
Reporter:  uwe   | Owner:  somebody
Type:  defect|Status:  closed  
Priority:  major | Milestone:  Enhance the flashrom utility
   Component:  flashrom  |   Version:  
  Resolution:  fixed |  Keywords:  
Dependencies:|   Patchstatus:  patch has been committed
-+--
Changes (by uwe):

  * status:  new => closed
  * patchstatus:  there is no patch => patch has been committed
  * resolution:  => fixed

Comment:

 Fixed in r3067.

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

[coreboot] [PATCH] flashrom: less documentation duplication

[Uwe Hermann]

See patch.

We keep forgetting to update all the sources of information, let's drop
some and only use one location where we document stuff (mostly wiki).


Uwe.
-- 
http://www.hermann-uwe.de  | http://www.holsham-traders.de
http://www.crazy-hacks.org | http://www.unmaintained-free-software.org
Do not duplicate that much information in various different places
such as the README, manpage, --help output, and the wiki.
This should (partly) prevent incorrect and incomplete documentation.

Signed-off-by: Uwe Hermann <[EMAIL PROTECTED]>

Index: flashrom.8
===
--- flashrom.8	(Revision 3067)
+++ flashrom.8	(Arbeitskopie)
@@ -1,4 +1,4 @@
-.TH FLASHROM 8 "January 18, 2008"
+.TH FLASHROM 8 "January 21, 2008"
 .SH NAME
 flashrom \- a universal BIOS/ROM/flash programming utility
 .SH SYNOPSIS
@@ -7,11 +7,15 @@
 .SH DESCRIPTION
 .B flashrom
 is a universal flash programming utility for DIP, PLCC, or SPI flash ROM
-chips. It can be used to flash BIOS/coreboot/firmware images, for example.
-
-(see
+chips. It can be used to flash BIOS/coreboot/firmware images, for example (see
 .B http://coreboot.org
-for details on coreboot)
+for details on coreboot).
+.PP
+The list of supported southbridges and ROM chips is available at
+.BR http://coreboot.org/Flashrom#Supported_devices "."
+.PP
+The list of known-working and known-broken mainboards is available at
+.BR http://coreboot.org/Flashrom#Supported_mainboards "."
 .SH OPTIONS
 If no file is specified, then all that happens
 is that flash info is dumped and the flash chip is set to writable.
@@ -74,22 +78,8 @@
 .SH LICENCE
 .B flashrom
 is covered by the GNU General Public License (GPL), version 2 or later.
-.SH COPYRIGHT
-2000 Silicon Integrated System Corporation
-.br
-2003 Niki W. Waibel
-.br
-2004 Tyan Corp
-.br
-2005-2007 coresystems GmbH
 .SH AUTHORS
-Yinghai Lu <[EMAIL PROTECTED]>
-.br
-Stefan Reinauer <[EMAIL PROTECTED]>
-.br
-Niki W. Waibel <[EMAIL PROTECTED]>
-.br
-some others 
+Please see the individual source code files for a list of flashrom authors.
 .PP
 This manual page was written by Uwe Hermann <[EMAIL PROTECTED]>.
 It is licensed under the terms of the GNU GPL (version 2 or later).
Index: README
===
--- README	(Revision 3066)
+++ README	(Arbeitskopie)
@@ -22,26 +22,17 @@
 Usage
 -
 
- $ flashrom [-rwvEVfh] [-c chipname] [-s exclude_start] [-e exclude_end]
-[-m vendor:part] [-l file.layout] [-i imagename] [file]
-   -r | --read:read flash and save into file
-   -w | --write:   write file into flash (default when
-   file is specified)
-   -v | --verify:  verify flash against file
-   -E | --erase:   erase flash device
-   -V | --verbose: more verbose output
-   -c | --chip : probe only for specified flash chip
-   -s | --estart :   exclude start position
-   -e | --eend : exclude end postion
-   -m | --mainboard : override mainboard settings
-   -f | --force:   force write without checking image
-   -l | --layout :read rom layout from file
-   -i | --image :only flash image name from flash layout
+Please read the manpage or run 'flashrom --help'.
 
- If no file is specified, then all that happens
- is that flash info is dumped and the flash chip is set to writable.
 
+Supported Flash Chips and Southbridges
+--
 
+Please see
+
+  http://coreboot.org/Flashrom#Supported_devices
+
+
 coreboot Table and Mainboard Identification
 
 
@@ -51,18 +42,9 @@
 
   flashrom -w --mainboard AGAMI:ARUMA agami_aruma.rom
 
-The following boards require the specification of the board name, if
-no coreboot table is found:
+The full list of boards which need such a --mainboard switch is at
 
-* IWILL DK8-HTX: use -m iwill:dk8_htx
-* Agami Aruma: use -m AGAMI:ARUMA
-* ASUS P5A: use -m asus:p5a
-* IBM x3455: use -m ibm:x3455
-* EPoX EP-BX3: use -m epox:ep-bx3
-* GIGABYTE GA-M57SLI-S4 v2.0: use -m gigabyte:m57sli
-* GIGABYTE GA-M61P-S3: use -m gigabyte:m61p
-* MSI K8N Neo3: use -m msi:k8n-neo3
-* Acorp 6A815EPD: use -m acorp:6a815epd
+  http://coreboot.org/Flashrom#Supported_mainboards
 
 
 ROM Layout Support
@@ -101,91 +83,3 @@
 Disk on Chip support is currently disabled since it is considered unstable.
 Change CFLAGS in the Makefile to enable it: Remove -DDISABLE_DOC from CFLAGS.
 
-
-Supported Flash Chips
--
-
-AMD AM-29F040B
-AMD AM-29F016D
-ASD AE49F2008
-Atmel AT-29C040A
-Atmel AT-29C020
-EMST F49B002UA
-Intel 82802AB (Firmware Hub) 
-Intel 82802AC (Firmware Hub) 
-M-Systems MD-2802 (unsupported, disabled by default)
-MX MX-29F002
-PMC PMC-49FL002
-PMC PMC-49FL004
-Sharp LHF-00L04
-SST SST-29EE020A
-SST SST-28SF040A
-SST SST-39SF010A
-SST SST-39SF020A
-SST SST-39SF040

Re: [coreboot] [LinuxBIOS] Please add support for MX25L8005 and MX25L3205D

[Harald Gutmann]

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.
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

I also wondered if the mx25l4005.c file is needed any more, because the 
functions in there aren't called anywhere.

kind regards,
Harald

-- 
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]

[bari]

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
>
>
>
>   


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

Re: [coreboot] [LinuxBIOS] Intel 3100 chipset, version 2

[Ed Swierk]

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.

--Ed

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

Re: [coreboot] [PATCH] flashrom: less documentation duplication

[Peter Stuge]

On Mon, Jan 21, 2008 at 04:42:04PM +0100, Uwe Hermann wrote:
> See patch.
> 
> We keep forgetting to update all the sources of information, let's
> drop some and only use one location where we document stuff

Ack.


> (mostly wiki).

Not so sure.

I would prefer to have these docs in the tarball as well. But maybe
either of them can be automatically generated? (That would be the
wiki, right?)


//Peter

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

Re: [coreboot] v3 compilation failures

[Marc Jones]

Carl-Daniel Hailfinger wrote:
> 3 of 5 targets in v3 fail to compile:
> - adl/msm800sev
> - amd/norwich
> - artecgroup/dbe61
> 
> While none of these targets worked on real hardware, we were at least
> able to compile them and could keep the code mostly warning-free to give
> later porters a good start. Right now the accumulated mess is rather
> difficult to clean up.
> 
> One of the contributing factors is the variety of smbus_read_byte
> prototypes. Same problem for spd_read_byte. Which one is the "right"
> prototype?
> 
> ./include/device/smbus.h:int smbus_read_byte(struct device *dev, u8 addr);
> ./device/smbus_ops.c:int smbus_read_byte(struct device *dev, u8 addr)
> (introduced in r307)
> 
> ./include/lib.h:int smbus_read_byte(unsigned device, unsigned address);
> ./mainboard/artecgroup/dbe61/initram.c:int smbus_read_byte(unsigned
> device, unsigned address)
> (introduced in r349)
> 
> ./southbridge/amd/cs5536/smbus_initram.c:int smbus_read_byte(u16 device,
> u8 address)
> (introduced in r344)
> 
> Patches appreciated.
> Hints:
> - artecgroup/dbe61 first failed in r527 with "undefined reference to
> 'spd_read_byte'"
> - adl/msm800sev and amd/norwich first failed in r537 with "conflicting
> types for 'spd_read_byte'", which was uncovered by the new combined
> compilation, but the root cause (conflicting types) had been there for
> dozens of revisions.
> 
> 
> Regards,
> Carl-Daniel
> 


I have patches for norwich give me a few more hours.
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] [Fwd: Re: AMD 690G chipset support in LinuxBIOS v2]

[Marc Jones]

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.

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
>>
>>
>>
>>   
> 
> 

-- 
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] AMD Geode Porting Guide

[Marc Jones]

Uwe Hermann wrote:
> On Fri, Jan 18, 2008 at 10:14:54PM -0700, Marc Jones wrote:
>> I added a porting guide to the wiki.
>> http://www.coreboot.org/AMD_Geode_Porting_Guide
> 
> Great write-up Marc, thanks!
> 
>  
>> Please let me know what is missing or how it can be better.
> 
> I've fixed some small cosmetic stuff and converted a few things to
> wiki syntax. Please also add a license tag at the bottom of the page
> using a wiki template, e.g. add {{GPL}} or {{PD-self}}.
> 
> 
> Thanks, Uwe.


Uwe,

Thanks for the edits.
I GPL'd the page and added some more content.

Thanks,
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] [PATCH] flashrom: less documentation duplication

[Uwe Hermann]

On Mon, Jan 21, 2008 at 05:45:40PM +0100, Peter Stuge wrote:
> > We keep forgetting to update all the sources of information, let's
> > drop some and only use one location where we document stuff
> 
> Ack.
> 
> 
> > (mostly wiki).
> 
> Not so sure.
> 
> I would prefer to have these docs in the tarball as well. But maybe

Yeah, it'll be after we added a --list-supported option similar to
superiotool. That one will always be correct. It's only the wiki
which we have to update then, and you cannot easily automate that
(and I don't think we should even try). The wiki page has some more
information which we add manually, e.g. footnotes/comments etc.

It's easy to compare --list-supported output to the wiki
though, which we should do from time to time...


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] v3 compilation failures

[ron minnich]

On Jan 21, 2008 10:12 AM, Marc Jones <[EMAIL PROTECTED]> wrote:

> > ./include/device/smbus.h:int smbus_read_byte(struct device *dev, u8 addr);
> > ./device/smbus_ops.c:int smbus_read_byte(struct device *dev, u8 addr)
> > (introduced in r307)
> >
> > ./include/lib.h:int smbus_read_byte(unsigned device, unsigned address);
> > ./mainboard/artecgroup/dbe61/initram.c:int smbus_read_byte(unsigned
> > device, unsigned address)
> > (introduced in r349)
> >
> > ./southbridge/amd/cs5536/smbus_initram.c:int smbus_read_byte(u16 device,
> > u8 address)
> > (introduced in r344)
> >

I recommend u16 device, u16 address. The address can be up to 10 bits
as I understand it
on some versions of smbus. Am I wrong on this however?


> > Patches appreciated.
> > Hints:
> > - artecgroup/dbe61 first failed in r527 with "undefined reference to
> > 'spd_read_byte'"
> > - adl/msm800sev and amd/norwich first failed in r537 with "conflicting
> > types for 'spd_read_byte'", which was uncovered by the new combined
> > compilation, but the root cause (conflicting types) had been there for
> > dozens of revisions.

This is probably mostly my fault, I will try to fix.

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

Re: [coreboot] [LinuxBIOS] Intel refactoring and microcode updates

[Uwe Hermann]

On Mon, Jan 14, 2008 at 03:29:51PM +0100, Uwe Hermann wrote:
> On Mon, Jan 14, 2008 at 05:46:29AM -0500, Corey Osgood wrote:
> > I know ;) Uwe, do you have a 440bx board you can try this on? Mine has
> 
> Yep, will do.

OK, here's my status report, there seem to be some issues.

I tried the current svn on my ASUS P2B-F, works fine. Then I applied the
microcode patches and tried to rebuild.

First issue is that I cannot rebuild anymore, linker errors because the
code became bigger.

The default in Options.lb is 
  default ROM_IMAGE_SIZE = 64 * 1024
and I had to change the size (in targets/.../Config.lb) to '74 * 1024'
in order to fit the increased size. Maybe some smaller value will
also work, but '70 * 1024' didn't, so you need something between
70 KB and 74 KB. Before the patches, 64 KB was enough.

The image finally built fine with 74 KB, but didn't boot anymore. It
hangs upon the 'Jumping to coreboot' message. Not sure why.

I noticed that the slot_1 directory now includes some HT stuff, in
  src/cpu/intel/intel_shared/Config.lb:
there's now
  dir /cpu/intel/hyperthreading
which wasn't there in the old slot_1 code (slot_2 actually), I think.

But that doesn't seem to be the (only) problem, commenting the
  # dir /cpu/intel/hyperthreading
doesn't help. I tried setting
  NO_MICROCODE_UPDATES = 1
in the Options.lb and it _seems_ that helped, it's booting again.
But of course it doesn't apply the microcode updates in that case.

My test CPU was
  CPU: family 06, model 07, stepping 03


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] v3 compilation failures

[Stefan Reinauer]

ron minnich wrote:

On Jan 21, 2008 10:12 AM, Marc Jones <[EMAIL PROTECTED]> wrote:

  

./include/device/smbus.h:int smbus_read_byte(struct device *dev, u8 addr);
./device/smbus_ops.c:int smbus_read_byte(struct device *dev, u8 addr)
(introduced in r307)

./include/lib.h:int smbus_read_byte(unsigned device, unsigned address);
./mainboard/artecgroup/dbe61/initram.c:int smbus_read_byte(unsigned
device, unsigned address)
(introduced in r349)

./southbridge/amd/cs5536/smbus_initram.c:int smbus_read_byte(u16 device,
u8 address)
(introduced in r344)

  


I recommend u16 device, u16 address. The address can be up to 10 bits
as I understand it
on some versions of smbus. Am I wrong on this however?
  


I thought a device always has to be struct device? No?

Stefan

--
coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br.
 Tel.: +49 761 7668825 • Fax: +49 761 7664613
Email: [EMAIL PROTECTED]  • http://www.coresystems.de/
Registergericht: Amtsgericht Freiburg • HRB 7656
Geschäftsführer: Stefan Reinauer • Ust-IdNr.: DE245674866




signature.asc
Description: OpenPGP digital signature
-- 
coreboot mailing list
coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] v3 compilation failures

[ron minnich]

On Jan 21, 2008 12:34 PM, Stefan Reinauer <[EMAIL PROTECTED]> wrote:

> > I recommend u16 device, u16 address. The address can be up to 10 bits
> > as I understand it
> > on some versions of smbus. Am I wrong on this however?
> >
>
> I thought a device always has to be struct device? No?

I'm having a slow day. Sorry. yes you are right. But the addr should
probably be u16

ron

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

Re: [coreboot] v3 compilation failures

[Marc Jones]

ron minnich wrote:
> On Jan 21, 2008 12:34 PM, Stefan Reinauer <[EMAIL PROTECTED]> wrote:
> 
>>> I recommend u16 device, u16 address. The address can be up to 10 bits
>>> as I understand it
>>> on some versions of smbus. Am I wrong on this however?
>>>
>> I thought a device always has to be struct device? No?
> 
> I'm having a slow day. Sorry. yes you are right. But the addr should
> probably be u16
> 
> ron
> 

I looked at the smbus spec (it is public) and didn't see anything about 
10bit address.
http://smbus.org/specs/

"SMBus addresses are 7 binary
bits long and are conventionally expressed as 4 bits followed by 3 bits 
followed by the letter ‘b’, for
example, 0001 110b. These addresses occupy the high seven bits of an 
eight-bit field on the bus. The low
bit of this field, however, has other semantic meaning that is not part 
of an SMBus address"

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] v3 compilation failures

[ron minnich]

On Jan 21, 2008 12:42 PM, Marc Jones <[EMAIL PROTECTED]> wrote:

> I looked at the smbus spec (it is public) and didn't see anything about
> 10bit address.
> http://smbus.org/specs/
>
> "SMBus addresses are 7 binary
> bits long and are conventionally expressed as 4 bits followed by 3 bits
> followed by the letter 'b', for
> example, 0001 110b. These addresses occupy the high seven bits of an
> eight-bit field on the bus. The low
> bit of this field, however, has other semantic meaning that is not part
> of an SMBus address"

http://www.robot-electronics.co.uk/htm/using_the_i2c_bus.htm

"All I2C addresses are either 7 bits or 10 bits. The use of 10 bit
addresses is rare and is not covered here. "

Maybe we should not worry about it, but there was at one point the
possibility of 10 bit addresses. I'm fine either way.

thanks

ron

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

Re: [coreboot] Resend: SST25VF016B (2MB) flash on m57sli (IT8716F).

[Ronald Hoogenboom]

On Mon, 2008-01-21 at 00:24 +0100, Ronald Hoogenboom wrote:
> (LPC is the only datapath to the SB and CPU, so it has to!). We could
> optimize by omitting the wait for SPI ready when there is no data to be
> read, eg. readcnt==0. I'll have a look at what can be gained by that.
> 
Omitting it saves 10 seconds with the unconditional 10us delay, reducing
to 40~45 secs. So I think it is worth putting it in. With the
conditional delay, it is not so easily measurable, because of the
natural variance much larger than 10 us...
Patch follows...

Signed-off-by: Ronald Hoogenboom <[EMAIL PROTECTED]>

---

Index: spi.c
===
--- spi.c	(revision 3066)
+++ spi.c	(working copy)
@@ -227,12 +227,14 @@
 	 * We can't use writecnt directly, but have to use a strange encoding.
 	 */ 
 	outb(((0x4 + (fast_spi ? 1 : 0)) << 4) | ((readcnt & 0x3) << 2) | (writeenc), port);
-	do {
-		busy = inb(port) & 0x80;
-	} while (busy);
-
-	for (i = 0; i < readcnt; i++) {
-		readarr[i] = inb(port + 5 + i);
+	if (readcnt > 0) {
+		do {
+			busy = inb(port) & 0x80;
+		} while (busy);
+		i=0;
+		do {
+			readarr[i] = inb(port + 5 + i);
+		} while (++i < readcnt);
 	}
 
 	return 0;
-- 
coreboot mailing list
coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] v3 compilation failures

[Marc Jones]

ron minnich wrote:

On Jan 21, 2008 10:12 AM, Marc Jones <[EMAIL PROTECTED]> wrote:




Patches appreciated.
Hints:
- artecgroup/dbe61 first failed in r527 with "undefined reference to
'spd_read_byte'"
- adl/msm800sev and amd/norwich first failed in r537 with "conflicting
types for 'spd_read_byte'", which was uncovered by the new combined
compilation, but the root cause (conflicting types) had been there for
dozens of revisions.


This is probably mostly my fault, I will try to fix.





Here is what I had done to get norwich building.

Marc

--
Marc Jones
Senior Firmware Engineer
(970) 226-9684 Office
mailto:[EMAIL PROTECTED]
http://www.amd.com/embeddedprocessors
Signed-off-by: Marc Jones <[EMAIL PROTECTED]>

Index: LinuxBIOSv3/southbridge/amd/cs5536/smbus_initram.c
===
--- LinuxBIOSv3.orig/southbridge/amd/cs5536/smbus_initram.c 2008-01-11 
15:35:37.0 -0700
+++ LinuxBIOSv3/southbridge/amd/cs5536/smbus_initram.c  2008-01-11 
15:57:06.0 -0700
@@ -343,7 +343,7 @@
  * @param address The address.
  * @return The data from the SMBus packet area or an error of 0xff (i.e. -1).
  */
-int spd_read_byte(u16 device, u8 address)
+u8 spd_read_byte(u16 device, u8 address)
 {
return smbus_read_byte(device, address);
 }

Signed-off-by: Marc Jones <[EMAIL PROTECTED]>

Index: LinuxBIOSv3/include/lib.h
===
--- LinuxBIOSv3.orig/include/lib.h  2008-01-11 15:52:52.0 -0700
+++ LinuxBIOSv3/include/lib.h   2008-01-11 16:04:12.0 -0700
@@ -36,11 +36,4 @@
 void beep_short(void);
 void beep_long(void);
 
-/* smbus functions */
-int smbus_read_byte(unsigned device, unsigned address);
-
-/* dram functions */
-void ram_failure(const char *why);
-void ram_initialize(int controllers, void *ctrl);
-
 #endif /* LIB_H */
-- 
coreboot mailing list
coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] [updated PATCH] Re: [cbv2]Add serial port information to lbtable

[Torsten Duwe]

On Monday 21 January 2008, you wrote:

> The codebase doesn't seem to be prepared for multiple serial ports in
> the first place (I only find TTYS0_*).

OK.

> As my initial query
> (http://www.coreboot.org/pipermail/coreboot/2008-January/029192.html)

Right. That would have been the thread. Sorry.

> As you can see, my patch doesn't pretend that the serial port is the
> console, so a "you can find the console $here" record can be added without
> conflicts. That new record could then refer to the serial port as specified
> here, in case the console is on serial.
>
> > The questions are:
> > 1. of what type is the active console?
> > a) VGA-compatible
> > b) 8250-compatible
> > c) ...

> Once we do that, the serial record could be extended by that
> information. Given that we have a size field in the record, that can
> even be done in a compatible way, or not?

Absolutely. This is what I propose. Rename the record LB_TAG_CONSOLE, add a 
type field that is currently always 1, meaning 8250-compatible, I/O-mapped 
serial. Also an interrupt field would be nice, with a default "none" value.

> This patch is updated against latest svn, and provides an alternative in
> case TTYS0_BASE isn't defined (see the #ifdef).

No more mocking about TTYS0 from my side. Do you want to make the other 
changes or shall I?

Torsten

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

Re: [coreboot] [PATCH] Abit BE6-II V2.0 support (repost)

[Sergei Antonov]

On Jan 14, 2008 5:14 PM, Uwe Hermann <[EMAIL PROTECTED]> wrote:
> Hi,
>
> here's a repost of a patch from last year which has not yet been
> comitted. See discussion starting at
> http://www.coreboot.org/pipermail/coreboot/2007-December/028076.html
> for details.
>
> The code works well enough to be committed IMO, some issue remain to be
> fixed though.

I tested it with recent coreboot + filo-0.5 and I confirm that it
works. BUT I had to change 'linuxbios' -> 'coreboot' everywhere. The
fixed patch is attached.
Please, commit it. And big thanks to those who was taking time to help
me with my old motherboard, especially Uwe!

The following issues have been found. Regardless of which, I think,
the patch should be committed.

0. filo-0.5 can't find hda HDD: 'No drive detected on IDE channel 0'.
That is, I believe, because of bug in filo-0.5. The patch is attached
which fixes the problem for me. I've already posted it, and it got
some critique. Please reconsider it. If it may cause problems, explain
them to me.

1. PS/2 keyboard doesn't work. (USB keyboard does.) I'll try to
investigate it myself.

2. flashrom outputs: 'No EEPROM/flash device found'. It is probably
because of a locked flash device. People on IRC gave me some tips, so
I'll try to investigate it myself.

3. I have a PCI card which is a host controller for IEEE 1394 and USB.
When I boot with the standard BIOS, USB devices attached to it work.
When I boot with coreboot, and plug in a USB device, it doesn't work
and these messages appear:
usb 1-4: new high speed USB device using ehci_hcd and address 3
usb 1-4: device descriptor read/64, error -110
usb 1-4: device descriptor read/64, error -110
usb 1-4: new high speed USB device using ehci_hcd and address 4
usb 1-4: device descriptor read/64, error -110
usb 1-4: device descriptor read/64, error -110
usb 1-4: new high speed USB device using ehci_hcd and address 5
usb 1-4: device not accepting address 5, error -110
usb 1-4: new high speed USB device using ehci_hcd and address 6
usb 1-4: device not accepting address 6, error -110
Googling on it suggests that it is a PCI IRQ-related problem.

4. coreboot works with 'NVIDIA GeForce2 MX 400' video card (64 MB),
but hangs with older 'NVIDIA Riva TNT' (16 MB). With the latter
nothing is displayed and the computer hangs after 'entering emulator'.
With the standard BIOS both cards work. Here are pieces of logs
related to VGA:

NVIDIA GeForce2 MX 400 (64 MB):
rom address for PCI: 01:00.0 = f900
PCI Expansion ROM, signature 0xaa55, INIT size 0xcc00, data ptr 0x00f4
PCI ROM Image, Vendor 10de, Device 0110,
PCI ROM Image,  Class Code 03, Code Type 00
copying VGA ROM Image from 0xf900 to 0xc, 0xcc00 bytes
entering emulator

NVIDIA Riva TNT (16 MB):
rom address for PCI: 01:00.0 = f100
PCI Expansion ROM, signature 0xaa55, INIT size 0x8000, data ptr 0x7623
PCI ROM Image, Vendor 10de, Device 0020,
PCI ROM Image,  Class Code 03, Code Type 00
copying VGA ROM Image from 0xf100 to 0xc, 0x8000 bytes
entering emulator

-- 
Sergei


v2_abit_be6-ii_v2_0_coreboot.patch
Description: Binary data


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

Re: [coreboot] v3 compilation failures

[Uwe Hermann]

On Mon, Jan 21, 2008 at 01:42:21PM -0700, Marc Jones wrote:
> I looked at the smbus spec (it is public) and didn't see anything about 
> 10bit address.
> http://smbus.org/specs/
> 
> "SMBus addresses are 7 binary
> bits long and are conventionally expressed as 4 bits followed by 3 bits 
> followed by the letter ‘b’, for
> example, 0001 110b. These addresses occupy the high seven bits of an 
> eight-bit field on the bus. The low
> bit of this field, however, has other semantic meaning that is not part 
> of an SMBus address"

The I2C spec has an optional 10bit addresing feature. I2C is similar
(and mostly compatible) but not identical to SMBus; I'm not sure if the
10 bit addressing is available in SMBus.


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] v3 compilation failures

[ron minnich]

On Jan 21, 2008 1:14 PM, Marc Jones <[EMAIL PROTECTED]> wrote:
===
> --- LinuxBIOSv3.orig/include/lib.h  2008-01-11 15:52:52.0 -0700
> +++ LinuxBIOSv3/include/lib.h   2008-01-11 16:04:12.0 -0700
> @@ -36,11 +36,4 @@
>  void beep_short(void);
>  void beep_long(void);
>
> -/* smbus functions */
> -int smbus_read_byte(unsigned device, unsigned address);

hmm. So where does the prototype live then?
> -
> -/* 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?

ron

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

Re: [coreboot] [cbv2]Add serial port information to lbtable

[Patrick Georgi]

Am Montag, den 21.01.2008, 22:39 +0100 schrieb Torsten Duwe:
> On Monday 21 January 2008, you wrote:
> 
> > The codebase doesn't seem to be prepared for multiple serial ports in
> > the first place (I only find TTYS0_*).
> 
> OK.
Actually, in v3 it's called TTYSx_* (with a literal 'x'), probably to
avoid this issue in case a different serial device is used.

> > Once we do that, the serial record could be extended by that
> > information. Given that we have a size field in the record, that can
> > even be done in a compatible way, or not?
> 
> Absolutely. This is what I propose. Rename the record LB_TAG_CONSOLE, add a 
> type field that is currently always 1, meaning 8250-compatible, I/O-mapped 
> serial. Also an interrupt field would be nice, with a default "none" value.
This record is intended to tell the payload about the existence and
where-abouts of a serial port. A console would be a separate record with
that number you propose (or something like that)

If and where a serial port is to be found is an information that should
be provided even if (say) vga is being used for the console, in my
opinion.

As for the layout of the LB_TAG_CONSOLE (which has to come, eventually),
there was some discussion on IRC already, but I think it quickly became
over-engineered.

> No more mocking about TTYS0 from my side. Do you want to make the other 
> changes or shall I?
The tag number is already taken in v3, so 0xe must be changed (just for
reference).

I'll post another patch, with a new ID (a v3 patch exists and works
already, that'll come, too) and work on a proposal for LB_TAG_CONSOLE -
tomorrow.


Regards,
Patrick Georgi



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

Re: [coreboot] v3 compilation failures

[Marc Jones]

ron minnich wrote:
> On Jan 21, 2008 1:14 PM, Marc Jones <[EMAIL PROTECTED]> wrote:
> ===
>> --- LinuxBIOSv3.orig/include/lib.h  2008-01-11 15:52:52.0 -0700
>> +++ LinuxBIOSv3/include/lib.h   2008-01-11 16:04:12.0 -0700
>> @@ -36,11 +36,4 @@
>>  void beep_short(void);
>>  void beep_long(void);
>>
>> -/* smbus functions */
>> -int smbus_read_byte(unsigned device, unsigned address);
> 
> hmm. So where does the prototype live then?
>> -
>> -/* 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.


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] Please add support for MX25L8005 and MX25L3205D

[Carl-Daniel Hailfinger]

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 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.


Regards,
Carl-Daniel

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

[coreboot] r3068 - trunk/util/flashrom

[svn]

Author: hailfinger
Date: 2008-01-22 00:55:08 +0100 (Tue, 22 Jan 2008)
New Revision: 3068

Modified:
   trunk/util/flashrom/spi.c
Log:
Omitting the wait for SPI ready when there is no data to be read, e.g.
readcnt==0 saves 10 seconds with the unconditional 10us delay, reducing
programming time for SST25VF016B to 40-45 secs.

Signed-off-by: Ronald Hoogenboom <[EMAIL PROTECTED]>
Acked-by: Carl-Daniel Hailfinger <[EMAIL PROTECTED]>


Modified: trunk/util/flashrom/spi.c
===
--- trunk/util/flashrom/spi.c   2008-01-21 15:24:22 UTC (rev 3067)
+++ trunk/util/flashrom/spi.c   2008-01-21 23:55:08 UTC (rev 3068)
@@ -227,12 +227,15 @@
 * We can't use writecnt directly, but have to use a strange encoding.
 */ 
outb(((0x4 + (fast_spi ? 1 : 0)) << 4) | ((readcnt & 0x3) << 2) | 
(writeenc), port);
-   do {
-   busy = inb(port) & 0x80;
-   } while (busy);
 
-   for (i = 0; i < readcnt; i++) {
-   readarr[i] = inb(port + 5 + i);
+   if (readcnt > 0) {
+   do {
+   busy = inb(port) & 0x80;
+   } while (busy);
+
+   for (i = 0; i < readcnt; i++) {
+   readarr[i] = inb(port + 5 + i);
+   }
}
 
return 0;


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

[coreboot] r3068 - trunk/util/flashrom

[svn]

Author: hailfinger
Date: 2008-01-22 00:55:08 +0100 (Tue, 22 Jan 2008)
New Revision: 3068

Modified:
   trunk/util/flashrom/spi.c
Log:
Omitting the wait for SPI ready when there is no data to be read, e.g.
readcnt==0 saves 10 seconds with the unconditional 10us delay, reducing
programming time for SST25VF016B to 40-45 secs.

Signed-off-by: Ronald Hoogenboom <[EMAIL PROTECTED]>
Acked-by: Carl-Daniel Hailfinger <[EMAIL PROTECTED]>


Modified: trunk/util/flashrom/spi.c
===
--- trunk/util/flashrom/spi.c   2008-01-21 15:24:22 UTC (rev 3067)
+++ trunk/util/flashrom/spi.c   2008-01-21 23:55:08 UTC (rev 3068)
@@ -227,12 +227,15 @@
 * We can't use writecnt directly, but have to use a strange encoding.
 */ 
outb(((0x4 + (fast_spi ? 1 : 0)) << 4) | ((readcnt & 0x3) << 2) | 
(writeenc), port);
-   do {
-   busy = inb(port) & 0x80;
-   } while (busy);
 
-   for (i = 0; i < readcnt; i++) {
-   readarr[i] = inb(port + 5 + i);
+   if (readcnt > 0) {
+   do {
+   busy = inb(port) & 0x80;
+   } while (busy);
+
+   for (i = 0; i < readcnt; i++) {
+   readarr[i] = inb(port + 5 + i);
+   }
}
 
return 0;


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

Re: [coreboot] SST25VF016B (2MB) flash on m57sli (IT8716F).

[Carl-Daniel Hailfinger]

On 21.01.2008 00:47, Ronald Hoogenboom wrote:
> On Mon, 2008-01-21 at 00:24 +0100, Ronald Hoogenboom wrote:
>   
>> (LPC is the only datapath to the SB and CPU, so it has to!). We could
>> optimize by omitting the wait for SPI ready when there is no data to be
>> read, eg. readcnt==0. I'll have a look at what can be gained by that.
>>
>> 
> Omitting it saves 10 seconds with the unconditional 10us delay, reducing
> to 40~45 secs. So I think it is worth putting it in. With the
> conditional delay, it is not so easily measurable, because of the
> natural variance much larger than 10 us...
> Patch follows...
>
> Signed-off-by: Ronald Hoogenboom <[EMAIL PROTECTED]>
>   

Acked-by: Carl-Daniel Hailfinger <[EMAIL PROTECTED]>

Committed in r3068.

Regards,
Carl-Daniel

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

Re: [coreboot] SST25VF016B (2MB) flash on m57sli (IT8716F).

[Carl-Daniel Hailfinger]

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]>


Index: spi.c
===
--- spi.c   (Revision 3068)
+++ spi.c   (Arbeitskopie)
@@ -519,12 +519,8 @@
for (i=0; ihttp://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] [LinuxBIOS] Intel refactoring and microcode updates

[Corey Osgood]

Uwe Hermann wrote:
> On Mon, Jan 14, 2008 at 03:29:51PM +0100, Uwe Hermann wrote:
>   
>> On Mon, Jan 14, 2008 at 05:46:29AM -0500, Corey Osgood wrote:
>> 
>>> I know ;) Uwe, do you have a 440bx board you can try this on? Mine has
>>>   
>> Yep, will do.
>> 
>
> OK, here's my status report, there seem to be some issues.
>
> I tried the current svn on my ASUS P2B-F, works fine. Then I applied the
> microcode patches and tried to rebuild.
>
> First issue is that I cannot rebuild anymore, linker errors because the
> code became bigger.
>
> The default in Options.lb is 
>   default ROM_IMAGE_SIZE = 64 * 1024
> and I had to change the size (in targets/.../Config.lb) to '74 * 1024'
> in order to fit the increased size. Maybe some smaller value will
> also work, but '70 * 1024' didn't, so you need something between
> 70 KB and 74 KB. Before the patches, 64 KB was enough.
>   

Thanks for testing this out! This is to be expected, unfortunately. I 
don't like eating another 10K that could be used by FILO for some 
feature, but it seems necessary. BTW, for some reason, this works fine 
with abuild, so abuild must set some larger size.

> The image finally built fine with 74 KB, but didn't boot anymore. It
> hangs upon the 'Jumping to coreboot' message. Not sure why.
>   

This sounds like it may be related to the extra wrmsr, whereever that 
email went, since this sounds like the same issue. There weren't any 
updates for your CPU before, so it makes sense that the patch would 
bring the issue up. I put a message out to the list to try and fix it, 
but never got any response, and I can't seem to reproduce the issue.

> I noticed that the slot_1 directory now includes some HT stuff, in
>   src/cpu/intel/intel_shared/Config.lb:
> there's now
>   dir /cpu/intel/hyperthreading
> which wasn't there in the old slot_1 code (slot_2 actually), I think.
>   

I looked through the hyperthreading code, and it shouldn't affect CPUs 
that don't have hyperthreading. IIRC, there's also some sort of block in 
there that prevents it from doing anything if CONFIG_SMP isn't set.

> But that doesn't seem to be the (only) problem, commenting the
>   # dir /cpu/intel/hyperthreading
> doesn't help. I tried setting
>   NO_MICROCODE_UPDATES = 1
> in the Options.lb and it _seems_ that helped, it's booting again.
> But of course it doesn't apply the microcode updates in that case.
>
> My test CPU was
>   CPU: family 06, model 07, stepping 03
>   

NO_MICROCODE_UPDATES cuts out everything microcode-related, so that's 
expected, too.

> Uwe.
>   

Thanks,
Corey

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

Re: [coreboot] SST25VF016B (2MB) flash on m57sli (IT8716F).

[ron minnich]

Just FYI, some luck writing this chip on the sis board ...

The write had no errors. The -v failed. But on using the -r to read to
a file, I find
no differences between the file used for -w and the file used for -v!

Next is to try to actually put the vga bios onto the image and see if,
this time, I get something.

I brought a post card home so I'm hoping to see something.

ron

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