coreboot June 2008

coreboot@coreboot.org

75 participants
230 discussions

Thomson IP1000's for sale
by joe＠settoplinux.org 20 Jun '08

20 Jun '08

Hello, In case anyone wanted to play with coreboot and the Thomson IP1000, and possibly help me with some development, there are a few for sale on eBay fairly cheap. Just an FYI in case your interested: http://search.ebay.com/search/search.dll?from=R40&_trksid=m37&satitle=TELUS+ TV+ Thanks - Joe

1 0

Re: [coreboot] GSoC project(SCSI boot)__status report
by Stefan Reinauer 20 Jun '08

20 Jun '08

Kevin O'Connor wrote: > On Mon, Jun 16, 2008 Stefan Reinauer wrote: > >> Zhang Rui is working for Google Summer of Code on booting off >> SCSI using option roms with coreboot; He will be cleaning up the legacy >> bios infrastructure parts in coreboot and make sure LegacyBIOS can >> easily be used. It would be great if you could help him in case we are >> in need of someone who knows Legacy BIOS really well! >> > > Sure. I'd prefer to cc a mailing list though - it increases overall > awareness. Either coreboot or bochs lists would be fine. > Ok, let's CC coreboot.org on this one. >>>> The code in util/x86emu/ should then be modified to >>>> * look for that file in the "lar" >>>> * copy it to 0xf0000 >>>> * use it instead of the current handlers >>>> >>>> >>> I have a question, what is the exact address of each handler function >>> in the legacybios of Qemu/Bochs? Does the legacybios bin begin with >>> the int0 call so the address of intXX call can be calculated from the >>> beginning of legacybios bin? >>> > > Look for the ".org" strings in rombios.c of bochs bios. Or, with > LegacyBIOS, look for all the "entry_xxx" functions in > src/romlayout.S. See: > > http://git.linuxtogo.org/?p=kevin/legacybios.git;a=blob;f=src/romlayout.S;h… > > These define the entry points of the bios. You definitely do _not_ > want to use the fixed addresses. The one exception is f000:fff0 - > which is the standard 16bit entry point for the "post" code of the > bios. > Ok, this is good. >> Here's the first question to Kevin: How can we install the LegacyBIOS >> interrupt handlers in order to call a single option rom and return back >> to coreboot scope? >> > > I'm slightly confused by your use of "legacy bios" and "LegacyBIOS". > :-) sorry, i will try to be more clear .. > The latest code I've written (I'll call in LegacyBIOS) produces an elf > file with a 32bit entry point. It works as a standard payload with > coreboot. > How will this work? Is there a piece of 32bit code that will copy the rest of LegacyBIOS to 0xf0000? Is there a way to produce a "bios.bin" image that can be copied to 0xe0000 or 0xf0000 and still has all the coreboot stuff in it? > In the general case, to use the 16bit handlers you need to run the > code contained in the "post" section. See: > > http://git.linuxtogo.org/?p=kevin/legacybios.git;a=blob;f=src/post.c;h=766e… > > This code initializes the BDA and EBDA memory areas - including the > idt table. However, the last part of "post" will attempt to boot the > system (by calling int19). If you want to "post" without booting, > you'd need to extend LegacyBIOS to return to coreboot somehow. > Ok. what would be the best way to do this? create a well known entry point, similar to the reset vector? > Is there a particular reason you'd want to return to coreboot? > Yes: Currently VGA initialization in coreboot is done with a mix of [vm86|x86emu] and half a intXX callback layer good enough to cope with most graphics cards. To make this really good, we'd need to heavily extend that intXX callback code in coreboot. Which means it has to grow and grow and it will eventually become a reduced version of LegacyBIOS. That is bad. If we know LegacyBIOS does a pretty good job and it is reasonably small (even qemu's current bios.bin is under 30k with , I would really prefer using it for that task instead of yet another half-baked solution. But when LegacyBIOS is supposed to replace the current intXX layer, it has to return after doing its initialization, possibly it has to do everything in _start() up and including the call to post(). The current option rom handling in post() may not be sufficient to initialize all option roms in a system, as the current coreboot v3 code is able to load an option rom for a given device from the "lar" archive, copy it to the option rom area and execute it from there. This way we can easily support an arbitrary number of onboard devices with option roms. But when jumping into LegacyBIOS, not all option roms may be visible in the address space at the same time. I guess what I am suggesting is to split the bootmenu + OS loader (int19) part from the init part. This way we can still provide the option rom initialization via LegacyBIOS' intXX callbacks but do not force the user to also use its int19 boot code, but can instead jump into another payload - for example UEFI or GRUB2 in flash. >>>> What we have to find out is: Do we have to preserve much at all? Maybe >>>> it is enough to install legacybios to 0xf0000 and let it live there, >>>> then the payloads could just use intXX calls, as they can with a >>>> non-free bios installed. But maybe it is not that trivial. >>>> > > As above, some of the interrupt handlers may run okay without "post" > running. However, several of them want to access the Bios Data Area > (BDA) and Extended Bios Data Area (EBDA). Basically, these are the > working storage areas of the bios. The "post" code is what > initializes these memory areas. > > [...] > Ok, I think this is much clearer now. >>> Could we preserve 0xf0000 for the legacybios? If we can put coreboot >>> table and ACPI tables and something else in the low 1M of RAM, it will >>> be a good job. How much space will these tables take? I mean coreboot >>> table and ACPI tables. >>> > > What I'm currently doing is having coreboot build the tables somewhere > high in memory, and then having LegacyBIOS move the tables that need > to be in 0xf0000 down to that area. > Do you have a list of tables that need to live at 0xf0000? I know at least a lot of ACPI can live pretty high up. coreboot table currently resides at 0x530 or 0x500 but it is not very well placed there. Stefan -- coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br. Tel.: +49 761 7668825 • Fax: +49 761 7664613 Email: info(a)coresystems.de • http://www.coresystems.de/ Registergericht: Amtsgericht Freiburg • HRB 7656 Geschäftsführer: Stefan Reinauer • Ust-IdNr.: DE245674866

6 16

r3372 - trunk/util/flashrom
by svn＠coreboot.org 20 Jun '08

20 Jun '08

Author: stuge Date: 2008-06-20 04:58:42 +0200 (Fri, 20 Jun 2008) New Revision: 3372 Modified: trunk/util/flashrom/flashrom.c Log: flashrom: Show expected and read byte on verify failure. Trivial. Signed-off-by: Peter Stuge <peter(a)stuge.se> Acked-by: Peter Stuge <peter(a)stuge.se> Modified: trunk/util/flashrom/flashrom.c =================================================================== --- trunk/util/flashrom/flashrom.c 2008-06-20 00:02:52 UTC (rev 3371) +++ trunk/util/flashrom/flashrom.c 2008-06-20 02:58:42 UTC (rev 3372) @@ -187,7 +187,8 @@ if (verbose) { printf("0x%08x ", idx); } - printf("FAILED!\n"); + printf("FAILED! Expected=0x%02x, Read=0x%02x\n", + *(buf + idx), *(buf2 + idx)); return 1; }

1 0

r3371 - trunk/payloads/coreinfo
by svn＠coreboot.org 20 Jun '08

20 Jun '08

Author: jcrouse Date: 2008-06-20 02:02:52 +0200 (Fri, 20 Jun 2008) New Revision: 3371 Modified: trunk/payloads/coreinfo/coreinfo.c Log: coreinfo: Enable serial support Remove the lines preventing serial + curses thanks to r3370. Trivial. Signed-off-by: Jordan Crouse <jordan.crouse(a)amd.com> Acked-by: Jordan Crouse <jordan.crouse(a)amd.com> Modified: trunk/payloads/coreinfo/coreinfo.c =================================================================== --- trunk/payloads/coreinfo/coreinfo.c 2008-06-20 00:01:42 UTC (rev 3370) +++ trunk/payloads/coreinfo/coreinfo.c 2008-06-20 00:02:52 UTC (rev 3371) @@ -269,9 +269,6 @@ { int i, j; - curses_enable_serial(0); - curses_enable_vga(1); - initscr(); init_pair(1, COLOR_WHITE, COLOR_GREEN);

1 0

Patch to extend ROM decode range to 1MB for vt8237r
by bari 20 Jun '08

20 Jun '08

This patch extends the VIA vt8237r southbridge decode range for the ROM to 1MB. Signed-off-by: Bari Ari <bari(a)onelabs.com> Acked-by: Peter Stuge <peter(a)stuge.se>

2 1

r3370 - in trunk/payloads/libpayload: curses drivers include
by svn＠coreboot.org 20 Jun '08

20 Jun '08

Author: jcrouse Date: 2008-06-20 02:01:42 +0200 (Fri, 20 Jun 2008) New Revision: 3370 Modified: trunk/payloads/libpayload/curses/keyboard.c trunk/payloads/libpayload/curses/tinycurses.c trunk/payloads/libpayload/drivers/serial.c trunk/payloads/libpayload/include/libpayload.h Log: libpayload: Support curses for serial Support the curses interface over serial by supporting a minimal vt100 terminal. Signed-off-by: Jordan Crouse <jordan.crouse(a)amd.com> Acked-by: Ronald G. Minnich <rminnich(a)gmail.com> Modified: trunk/payloads/libpayload/curses/keyboard.c =================================================================== --- trunk/payloads/libpayload/curses/keyboard.c 2008-06-20 00:01:14 UTC (rev 3369) +++ trunk/payloads/libpayload/curses/keyboard.c 2008-06-20 00:01:42 UTC (rev 3370) @@ -43,11 +43,89 @@ /* ============== Serial ==================== */ -/* FIXME: Cook the serial correctly */ +/* We treat serial like a vt100 terminal. For now we + do the cooking in here, but we should probably eventually + pass it to dedicated vt100 code */ +static int getkeyseq(char *buffer, int len) +{ + int i; + + for(i = 0; i < 75; i++) { + if (serial_havechar()) + break; + mdelay(1); + } + + if (i == 75) + return len; + + buffer[len++] = serial_getchar(); + return getkeyseq(buffer, len); +} + +static struct { + char *seq; + int key; +} escape_codes[] = { + { "[A", KEY_UP }, + { "[B", KEY_DOWN }, + { "[C", KEY_RIGHT }, + { "[D", KEY_LEFT }, + { "OP", KEY_F(1) }, + { "OQ", KEY_F(2) }, + { "OR", KEY_F(3) }, + { "OS", KEY_F(4) }, + { "[15~", KEY_F(5) }, + { "[17~", KEY_F(6) }, + { "[18~", KEY_F(7) }, + { "[19~", KEY_F(8) }, + { "[20~", KEY_F(9) }, + { "[21~", KEY_F(10) }, + { "[24~", KEY_F(12) }, + { NULL }, +}; + +static int handle_escape(void) +{ + char buffer[5]; + int len = getkeyseq(buffer, 0); + int i, t; + + if (len == 0) + return 27; + + for(i = 0; escape_codes[i].seq != NULL; i++) { + char *p = escape_codes[i].seq; + + for(t = 0; t < len; t++) { + if (!*p || *p != buffer[t]) + break; + p++; + } + + if (t == len) + return escape_codes[i].key; + } + + return 0; +} + static int cook_serial(unsigned char ch) { - return (int) ch; + switch(ch) { + case 8: + return KEY_BACKSPACE; + + case 13: + return KEY_ENTER; + + case 27: + return handle_escape(); + + default: + return ch; + } } /* ================ Keyboard ================ */ Modified: trunk/payloads/libpayload/curses/tinycurses.c =================================================================== --- trunk/payloads/libpayload/curses/tinycurses.c 2008-06-20 00:01:14 UTC (rev 3369) +++ trunk/payloads/libpayload/curses/tinycurses.c 2008-06-20 00:01:42 UTC (rev 3370) @@ -218,6 +218,10 @@ // newterm(name, stdout, stdin); // def_prog_mode(); + if (curses_flags & F_ENABLE_SERIAL) { + serial_clear(); + } + if (curses_flags & F_ENABLE_CONSOLE) { /* Clear the screen and kill the cursor */ @@ -586,20 +590,48 @@ win->_flags |= _HASMOVED; return OK; } + int wnoutrefresh(WINDOW *win) { // FIXME. + int serial_is_bold = 0; + int x, y; + serial_end_bold(); + for (y = 0; y <= win->_maxy; y++) { + + /* Position the serial cursor */ + + if (curses_flags & F_ENABLE_SERIAL) + serial_set_cursor(win->_begy + y, win->_begx); + for (x = 0; x <= win->_maxx; x++) { - if (curses_flags & F_ENABLE_SERIAL) + attr_t attr = win->_line[y].text[x].attr; + + unsigned int c = + ((int)color_pairs[PAIR_NUMBER(attr)]) << 8; + + if (curses_flags & F_ENABLE_SERIAL) { + + if (attr & A_BOLD) { + if (!serial_is_bold) { + serial_start_bold(); + serial_is_bold = 1; + } + } + else { + if (serial_is_bold) { + serial_end_bold(); + serial_is_bold = 0; + } + } + serial_putchar(win->_line[y].text[x].chars[0]); + } if (curses_flags & F_ENABLE_CONSOLE) { - attr_t attr = win->_line[y].text[x].attr; - unsigned int c = - ((int)color_pairs[PAIR_NUMBER(attr)]) << 8; /* Handle some of the attributes. */ if (attr & A_BOLD) Modified: trunk/payloads/libpayload/drivers/serial.c =================================================================== --- trunk/payloads/libpayload/drivers/serial.c 2008-06-20 00:01:14 UTC (rev 3369) +++ trunk/payloads/libpayload/drivers/serial.c 2008-06-20 00:01:42 UTC (rev 3370) @@ -35,6 +35,25 @@ #define DIVISOR (115200 / CONFIG_SERIAL_BAUD_RATE) #endif +/* This is a hack - we convert the drawing characters to ASCII */ + +static unsigned char translate_special_chars(unsigned char c) +{ + switch(c) { + case 196: + return '-'; + case 179: + return '|'; + case 218: + case 191: + case 192: + case 217: + return '+'; + default: + return ' '; + } +} + void serial_init(void) { #ifdef CONFIG_SERIAL_SET_SPEED @@ -61,6 +80,9 @@ void serial_putchar(unsigned char c) { + if (c > 127) + c = translate_special_chars(c); + while ((inb(IOBASE + 0x05) & 0x20) == 0) ; outb(c, IOBASE); } @@ -75,3 +97,38 @@ while (!serial_havechar()) ; return (int)inb(IOBASE); } + +/* These are thinly veiled vt100 functions used by curses */ + +#define VT100_CLEAR "\e[H\e[J" +#define VT100_SBOLD "\e[7m" +#define VT100_EBOLD "\e[m" +#define VT100_CURSOR_ADDR "\e[%d;%dH" + +static void serial_putcmd(char *str) +{ + while(*str) + serial_putchar(*(str++)); +} + +void serial_clear(void) +{ + serial_putcmd(VT100_CLEAR); +} + +void serial_start_bold(void) +{ + serial_putcmd(VT100_SBOLD); +} + +void serial_end_bold(void) +{ + serial_putcmd(VT100_EBOLD); +} + +void serial_set_cursor(int y, int x) +{ + char buffer[32]; + snprintf(buffer, sizeof(buffer), VT100_CURSOR_ADDR, y, x); + serial_putcmd(buffer); +} Modified: trunk/payloads/libpayload/include/libpayload.h =================================================================== --- trunk/payloads/libpayload/include/libpayload.h 2008-06-20 00:01:14 UTC (rev 3369) +++ trunk/payloads/libpayload/include/libpayload.h 2008-06-20 00:01:42 UTC (rev 3370) @@ -107,6 +107,11 @@ int serial_havechar(void); int serial_getchar(void); +void serial_clear(void); +void serial_start_bold(void); +void serial_end_bold(void); +void serial_set_cursor(int y, int x); + /* drivers/speaker.c */ void speaker_enable(u16 freq); void speaker_disable(void);

1 0

r3369 - trunk/coreboot-v2/src/southbridge/via/vt8237r
by svn＠coreboot.org 20 Jun '08

20 Jun '08

Author: stuge Date: 2008-06-20 02:01:14 +0200 (Fri, 20 Jun 2008) New Revision: 3369 Modified: trunk/coreboot-v2/src/southbridge/via/vt8237r/vt8237r.c Log: Extend the VIA vt8237r southbridge decode range for the ROM to 1MB. Signed-off-by: Bari Ari <bari(a)onelabs.com> Acked-by: Peter Stuge <peter(a)stuge.se> Modified: trunk/coreboot-v2/src/southbridge/via/vt8237r/vt8237r.c =================================================================== --- trunk/coreboot-v2/src/southbridge/via/vt8237r/vt8237r.c 2008-06-18 13:36:34 UTC (rev 3368) +++ trunk/coreboot-v2/src/southbridge/via/vt8237r/vt8237r.c 2008-06-20 00:01:14 UTC (rev 3369) @@ -79,6 +79,8 @@ pci_write_config8(dev, 0x51, sb->fn_ctrl_hi); /* TODO: If SATA is disabled, move IDE to fn0 to conform PCI specs. */ + /* Extend ROM decode to 1MB FFC00000 - FFFFFFFF */ + pci_write_config8(dev, 0x41, 0x7f); } struct chip_operations southbridge_via_vt8237r_ops = {

1 0

Buildrom breaks with 2.6.25.4 or 2.6.24.7 kernel source
by bari 19 Jun '08

19 Jun '08

I tried building LAB for the Tyan s-2891 using buildrom and 2.6.25.4 kernel source. debug output: /home/ly/buildrom/buildrom-devel/work/busybox/busybox-1.1.3/libbb/procps.c:15:22: error: asm/page.h: No such file or directory make[2]: *** [/home/ly/buildrom/buildrom-devel/work/busybox/busybox-1.1.3/libbb/procps.o] Error 1 make[1]: *** [all] Error 2 The kernel was built just fine. It just breaks during the build of busybox. Also breaks with 2.6.24.7 kernel, 2.6.22.2 or 2.6.22.5 kernel is fine. Any ideas why? -Bari

2 1

Patch to extend ROM decode range to 1MB for vt8237r
by bari 19 Jun '08

19 Jun '08

This patch extends the VIA vt8237r southbridge decode range for the ROM to 1MB. Rudolf had use this for a board specific patch in the past. We also already do this for all vt8237r in flashrom. Signed-off-by: Bari Ari <bari(a)onelabs.com> -Bari

2 3

coreboot table and i82801xx GPIO conflicts
by Joseph Smith 19 Jun '08

19 Jun '08

Hello, I was just reading Stefan's API wiki page and something dawned on me. For the i82801xx, the LPC GPIO Base address is set to 0x500. According to Stefan's API wiki page the coreboot table is also at 0x500. The output from the kernel indicates a conflict at 0x500? Could this be causing a conflict??? Kernel: PCI quirk: region 0400-047f claimed by ICH4 ACPI/GPIO/TCO PCI quirk: region 0500-053f claimed by ICH4 GPIO -- Thanks, Joseph Smith Set-Top-Linux www.settoplinux.org

3 5

← Newer
1
...
10
11
12
13
14
15
16
...
23
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot June 2008