coreboot February 2008

coreboot@coreboot.org

77 participants
422 discussions

[LinuxBIOS] [PATCH] TeleVideo TC7020 support (2nd try)
by Kenji Noguchi 29 Mar '08

29 Mar '08

Hi Uwe, Thanks for the review. I have updated the patch based on your review. The new patch needs Nikolay's CS5530/CS5536 PIRQ patch. I cannot run superiotool with the factory BIOS because the BIOS is WinCE. WakeOnLan doesn't work out of the box. The original thin-clients manager is able to on/off WOL feature as far as I remember. It's a PC97317 board. Strange, the superiotool r2992 says "No Super I/O found" NIC is soldered on the motherboard, and it resides on pci 15.0. Fixed the config entry. Floppy connector may be available in one of the pin headers but I can't confirm. I leave it off to be conservative. COM2 is a regular DB9 serial. Fixed the comment. irq_tables.c in the previous patch was re-generated by getpir tool, and manually edited. However I had no way of testing it. Linux kernel won't read it unless patched, you know. Anyway I reworked on this file using Nikolay's irq patch. As for MiniPCI slot there are INTA and INTB by definition of the MiniPCI. lspci output had no 14.0 because it's a slot. I installd a WiFi card to the MiniPCI slot(PCI 14.0) for testing. It got IRQ9 and worked great! Regards, Kenji Noguchi

2 2

[LinuxBIOS] [RFC][PATCH] v3: lar header after member support
by Carl-Daniel Hailfinger 28 Mar '08

28 Mar '08

We had that patch in a larger package about 7 weeks ago, but most parts of the package have been merged since then, reducing the clutter in the patch to zero. For your reference: Message-ID: <470EA5CF.2020409(a)gmx.net> Date: Fri, 12 Oct 2007 00:38:07 +0200 AFAIK not all architectures start executing code at the top of ROM, some start at the bottom (low address). In that case, we can't start the archive with a LAR header, but we can end it with one or postfix the first archive member with a LAR header. To achieve that, the patch redefines offset as signed instead of unsigned and allows the lar header after the boot block to point to the boot block at the beginning. That way, even bottom boot architectures can use the existing header format unless the first LAR member is bigger than 2 GB. This patch also introduces a 2 GB limit for file names in LARchives and a 2 GB limit for unused space between header and data. There is no new restriction for member lengths or archive length. Current LAR archives look like this: Hn=header n -=padding Dn=data n H0D0D0D0H1D1----H2D2D2 where the last bytes of D2 are executed after poweron. The patch (together with signed offset) makes archives like the below one possible: D0D0D0H0H1D1----H2D2D2 (header after boot block points to boot block) The new archive format possibility allows placing a boot block at the beginning without sacrificing the goal of one common archive format. However, there are two potential problems: - Endless loops if we aren't careful when walking the LAR. I think I got all corner cases right. - "Nobody will need more than 640kB", in our case it would be 2GB boot blocks. Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006(a)gmx.net> Index: LinuxBIOSv3-larheaderaftermember/include/lar.h =================================================================== --- LinuxBIOSv3-larheaderaftermember/include/lar.h (Revision 539) +++ LinuxBIOSv3-larheaderaftermember/include/lar.h (Arbeitskopie) @@ -61,7 +61,15 @@ u32 reallen; u32 checksum; u32 compchecksum; - u32 offset; + /* The offset is signed to allow header after data for the first member + * of the LAR. This is needed if code execution starts at bottom of + * flash instead of at top of flash (x86). Please note that a + * header-after-data LAR member can't be larger than 2^31 bytes. + * Right now, we are about five orders of magnitude away from such a + * beast. + * Filenames are limited to 2^31-1-sizeof(lar_header)-1 bytes. + * "Nobody will ever need more than 640k" */ + s32 offset; /* Compression: * 0 = no compression * 1 = lzma Index: LinuxBIOSv3-larheaderaftermember/lib/lar.c =================================================================== --- LinuxBIOSv3-larheaderaftermember/lib/lar.c (Revision 539) +++ LinuxBIOSv3-larheaderaftermember/lib/lar.c (Arbeitskopie) @@ -116,7 +116,9 @@ if (strcmp(fullname, filename) == 0) { printk(BIOS_SPEW, "LAR: CHECK %s @ %p\n", fullname, header); - result->start = walk + ntohl(header->offset); + /* In the header-before-member case offset is at least + * sizeof(header) + strlen(filename) + 1 */ + result->start = walk + (s32)ntohl(header->offset); result->len = ntohl(header->len); result->reallen = ntohl(header->reallen); result->compression = ntohl(header->compression); @@ -137,9 +139,30 @@ * In the case of consecutive archive members with header- * before-member structure, the next iteration of the loop will * start exactly at the beginning of the next header. - */ + * In the case of header-after-member (e.g. for bottom boot + * architectures) the calculation below will effectively cause + * walk < header. To elaborate a bit more, in this case + * (header->offset + header->len - 1) will evaluate to a value + * between -1 (header directly after file), -16 (file, 15 bytes + * pad, header), and even smaller values if there is 16 bytes + * or more of padding between member and header. The outer + * expression will usually evaluate to 0xfffffff0, cause the + * expected overflow with unsigned arithmetic and result in a + * decrease of walk. That condition can be checked. */ +#warning FIXME: This loop will explode if this code is ever compiled in 64bit mode +#warning because of the hardcoded 0xfffffff0. walk += (ntohl(header->offset) + ntohl(header->len) - 1) & 0xfffffff0; + /* If we have header-after-member, walk < header is true. + * Go forward instead by starting at header, adding header size + * and strlen(fullname). The result of this calculation is the + * position of the terminating \0 of fullname. Round that + * address down to the next 16 byte boundary. */ + if (walk < (char *)header) { + walk = (char *)header; + walk += (sizeof(struct lar_header) + strlen(fullname)) + & 0xfffffff0; + } } printk(BIOS_SPEW, "LAR: File not found!\n"); return 1; Index: LinuxBIOSv3-larheaderaftermember/util/lar/lar.h =================================================================== --- LinuxBIOSv3-larheaderaftermember/util/lar/lar.h (Revision 539) +++ LinuxBIOSv3-larheaderaftermember/util/lar/lar.h (Arbeitskopie) @@ -60,6 +60,7 @@ typedef uint64_t u64; typedef uint32_t u32; typedef uint8_t u8; +typedef int32_t s32; /* NOTE -- This and the user-mode lar.h may NOT be in sync. Be careful. */ struct lar_header { @@ -68,9 +69,15 @@ u32 reallen; u32 checksum; u32 compchecksum; - /* Filenames are limited to 2^31-1-sizeof(lar_header)-1 bytes. + /* The offset is signed to allow header after data for the first member + * of the LAR. This is needed if code execution starts at bottom of + * flash instead of at top of flash (x86). Please note that a + * header-after-data LAR member can't be larger than 2^31 bytes. + * Right now, we are about five orders of magnitude away from such a + * beast. + * Filenames are limited to 2^31-1-sizeof(lar_header)-1 bytes. * "Nobody will ever need more than 640k" */ - u32 offset; + s32 offset; /* Compression: * 0 = no compression * 1 = lzma

2 3

SST25VF016B (2MB) flash on m57sli (IT8716F).
by Ronald Hoogenboom 20 Mar '08

20 Mar '08

I mounted a SST25VF016B 2MByte flash chip on the second SPI bios landpattern on the m57sli mobo (as per the m57sli tutorial). There as some problems with that, on the one side from the point of the LPC memory mapping options of the IT8716F (max. 512KB contiguous) and on the other side with the programming method(s) supported by the SST flash chip (only the byte-mode programming is compatible with the IT8716). Lets call them problem1 and problem2. The reason why I want the 2MB is that I would like to try direct Linux kernel as the payload. Problem1 and Problem2 have impact on the useability of flashrom, which I have sort-of solved (patch below). Problem1 also has impact on the elfboot.c and rom-stream.c in coreboot (linuxbios), which I'm still investigating (suggestions welcome!). Problem1 (for reading) is solved by NOT using the mmap method for reading the flash contents, but using outb() for sending the flash read commands (using a specific 25vf016 read function). Also the normal read command is only supported up to 25MHz by this chip, so I cannot use the 33MHz speed as used normally by spi.c. There is also a 'high speed' read command (0x0b), which inserts an extra dummy byte between address and data, but as the 8716 only allows max. 3 bytes read per io transfer, the gain (3 bytes per io transfer @ 16MHz versus 2 bytes per io transfer @ 33MHz) is negligible. Problem2 (for writing) is solved similarly: The mmap write method cannot be used effectively, because the flash chip needs a Write-enable command for each Byte-program (no block program concept in byte-program mode). The chip has a so-called AAI (auto address increment) programming mode instead, but that cannot be used with the 8716 chip, because it needs 6 byte and 3 byte io transfers, which it doesn't support (bah!). Not using the mmap writes also solves the limited LPC memory address window. So, there is also a 25vf016 specific write function. NOTE: there may be some offset because of other changes... Index: flash.h =================================================================== --- flash.h (revision 3051) +++ flash.h (working copy) @@ -297,6 +303,8 @@ void generic_spi_write_disable(); int generic_spi_chip_erase_c7(struct flashchip *flash); int generic_spi_chip_write(struct flashchip *flash, uint8_t *buf); +int sst25vf016_spi_chip_write(struct flashchip *flash, uint8_t *buf); +int sst25vf016_spi_chip_read(struct flashchip *flash, uint8_t *buf); /* 82802ab.c */ int probe_82802ab(struct flashchip *flash); Index: flashchips.c =================================================================== --- flashchips.c (revision 3051) +++ flashchips.c (working copy) @@ -57,7 +57,7 @@ {"SST25VF040B", SST_ID, SST_25VF040B, 512, 256, probe_spi, generic_spi_chip_erase_c7, generic_spi_chip_write}, {"SST25VF016B", SST_ID, SST_25VF016B, 2048, 256, - probe_spi, generic_spi_chip_erase_c7, generic_spi_chip_write}, + probe_spi, generic_spi_chip_erase_c7, sst25vf016_spi_chip_write, sst25vf016_spi_chip_read}, {"SST29EE020A", SST_ID, SST_29EE020A, 256, 128, probe_jedec, erase_chip_jedec, write_jedec}, {"SST28SF040A", SST_ID, SST_28SF040, 512, 256, Index: spi.c =================================================================== --- spi.c (revision 3051) +++ spi.c (working copy) @@ -77,6 +77,8 @@ #define JEDEC_RDSR_BIT_WIP (0x01 << 0) uint16_t it8716f_flashport = 0; +/* use fast 33MHz SPI (<>0) or slow 16MHz (0) */ +int fast_spi=1; void generic_spi_prettyprint_status_register(struct flashchip *flash); @@ -203,10 +205,10 @@ __FUNCTION__, writecnt); return 1; } - /* Start IO, 33MHz, readcnt input bytes, writecnt output bytes. Note: + /* Start IO, 33MHz (or 16), readcnt input bytes, writecnt output bytes. Note: * We can't use writecnt directly, but have to use a strange encoding. */ - outb((0x5 << 4) | ((readcnt & 0x3) << 2) | (writeenc), port); + outb(((0x4+(fast_spi?1:0)) << 4) | ((readcnt & 0x3) << 2) | (writeenc), port); do { busy = inb(port) & 0x80; } while (busy); @@ -314,6 +316,39 @@ "%sset\n", (status & (1 << 0)) ? "" : "not "); } +/* Prettyprint the status register. Works for + * SST 25VF016 + */ +void generic_spi_prettyprint_status_register_sst25vf016(uint8_t status) +{ + const char *bpt[]={ + "none", + "1F0000H-1FFFFFH", + "1E0000H-1FFFFFH", + "1C0000H-1FFFFFH", + "180000H-1FFFFFH", + "100000H-1FFFFFH", + "all","all" + }; + printf_debug("Chip status register: Block Protect Write Disable " + "(BPL) is %sset\n", (status & (1 << 7)) ? "" : "not "); + printf_debug("Chip status register: Auto Address Increment Programming " + "(AAI) is %sset\n", (status & (1 << 6)) ? "" : "not "); + printf_debug("Chip status register: Bit 5 (BP3) is " + "%sset\n", (status & (1 << 5)) ? "" : "not "); + printf_debug("Chip status register: Bit 4 (BP2) is " + "%sset\n", (status & (1 << 4)) ? "" : "not "); + printf_debug("Chip status register: Bit 3 (BP1) is " + "%sset\n", (status & (1 << 3)) ? "" : "not "); + printf_debug("Chip status register: Bit 2 (BP0) is " + "%sset\n", (status & (1 << 2)) ? "" : "not "); + printf_debug("Resulting block protection : %s\n", bpt[(status&0x1c)>>2]); + printf_debug("Chip status register: Write Enable Latch (WEL) is " + "%sset\n", (status & (1 << 1)) ? "" : "not "); + printf_debug("Chip status register: Write In Progress (BUSY) is " + "%sset\n", (status & (1 << 0)) ? "" : "not "); +} + void generic_spi_prettyprint_status_register(struct flashchip *flash) { uint8_t status; @@ -326,6 +361,10 @@ if ((flash->model_id & 0xff00) == 0x2000) generic_spi_prettyprint_status_register_st_m25p(status); break; + case SST_ID: + if (flash->model_id == SST_25VF016B) + generic_spi_prettyprint_status_register_sst25vf016(status); + break; } } @@ -392,7 +431,7 @@ generic_spi_write_enable(); outb(0x06 , it8716f_flashport + 1); - outb((3 << 4), it8716f_flashport); + outb(((2+(fast_spi?1:0)) << 4), it8716f_flashport); for (i = 0; i < 256; i++) { bios[256 * block + i] = buf[256 * block + i]; } @@ -410,6 +449,94 @@ it8716f_spi_page_program(block, buf, bios); } +/* + * This is according the SST25VF016 datasheet, who knows it is more + * generic that this... + */ +void sst25vf016_spi_write_status_register(int status) +{ + const unsigned char cmd[] = {0x01,(unsigned char)status}; + + /* Send WRSR (Write Status Register) */ + generic_spi_command(2, 0, cmd, NULL); + +} + +void sst25vf016_spi_byte_program(int address, uint8_t byte) +{ + const unsigned char cmd[5] = {0x02, + (address>>16)&0xff, + (address>>8)&0xff, + (address>>0)&0xff, + byte + }; + + /* Send Byte-Program */ + generic_spi_command(5, 0, cmd, NULL); + +} + +/* + * IT8716F only allows maximum of 512 kb SPI mapped to LPC memory cycles + * Program chip using firmware cycle byte programming. (SLOW!) + */ +int sst25vf016_spi_chip_write(struct flashchip *flash, uint8_t *buf) +{ + int total_size = 1024 * flash->total_size; + uint8_t status; + int i; + fast_spi=0; + + status = generic_spi_read_status_register(); + /* If there is block protection in effect, unprotect it first. */ + if ((status&0x3c)!=0) { + printf_debug("Some block protection in effect, disabling\n"); + generic_spi_write_enable(); + sst25vf016_spi_write_status_register(status&~0x3c); + } + for (i=0; i<total_size; i++) { + generic_spi_write_enable(); + sst25vf016_spi_byte_program(i,buf[i]); + //while (generic_spi_read_status_register() & JEDEC_RDSR_BIT_WIP) + usleep(10); + if (i%1024==0) fputc('b',stderr); + } + /* resume normal ops... */ + outb(0x20, it8716f_flashport); + return 0; +} + +void sst25vf016_spi_3byte_read(int address, uint8_t *bytes, int len) +{ + const unsigned char cmd[5] = {0x03, + (address>>16)&0xff, + (address>>8)&0xff, + (address>>0)&0xff, + }; + + /* Send Read */ + generic_spi_command(4, len, cmd, bytes); + +} + +/* + * IT8716F only allows maximum of 512 kb SPI mapped to LPC memory cycles + * Need to read this big flash using firmware cycles 3 byte at a time. + */ +int sst25vf016_spi_chip_read(struct flashchip *flash, uint8_t *buf) +{ + int total_size = 1024 * flash->total_size; + int i; + fast_spi=0; + + for (i = 0; i < total_size; i+=3) { + int toread=3; + if (total_size-i < toread) toread=total_size-i; + sst25vf016_spi_3byte_read(i, buf+i, toread); + } + return 0; +} + int generic_spi_chip_write(struct flashchip *flash, uint8_t *buf) { int total_size = 1024 * flash->total_size; int i;

9 80

LinuxTag 2008 in Berlin, May 28-31
by Peter Stuge 19 Mar '08

19 Mar '08

The Call for Projects has been released. http://www.linuxtag.org/2008/de/community/projects/cfpro.html http://www.linuxtag.org/2008/en/community/projects/cfpro/call-for-projects.… Applications must be in before February 21st. I think we did OK last year, but if we do a bit more careful planning and preparations I think this year can be much better. The organizers expressed interest in a much larger and better advertised workshop-type event where we would help people get coreboot working on their systems. I am certainly interested in exhibiting coreboot. Anyone else? //Peter

6 16

flashrom issues??
by joe＠smittys.pointclark.net 14 Mar '08

14 Mar '08

Hello, I am having issues with flashrom. It can read the bios ok and even verify it but when I try to write it I get this: [root@localhost util]# flashrom -w test Calibrating delay loop... OK. Found coreboot table at 0x00000530. Vendor ID: rca, part ID: rm4100 Found chipset "ICH4/ICH4-L", enabling flash write... OK. NOT FOUND rca:rm4100 M50FW080 found at physical address 0xfff00000. Flash part is M50FW080 (1024 KB). ERASE FAILED @0, val 92! After this I tried the -E option (worked good) to erase it and than tried again with no luck, same message, any ideas?? Thanks - Joe

6 48

LAR TODO
by Carl-Daniel Hailfinger 13 Mar '08

13 Mar '08

I'd like to use this thread to collect TODO items for LAR. My current list is rather short, but that does not mean it is easy to complete these tasks. - "Unparse" parsed ELF so you get an ELF back when unpacking a LAR containing parsed ELF file. Reason: See mails on the list for the last few days. - "List holes" mode. Reason: To be able to "zerofill" the LAR, we must know where to fill. - Ability to specify where files should end up in the LAR (beginning of free space, end of free space, fixed address). Reason: Some machines can only access part of the flash directly, so shadowing/copying is needed for the inaccessible parts. That can only be done after RAM init, thereby requiring normal/initram and fallback/initram to end up in the directly accessible window. Regards, Carl-Daniel -- http://www.hailfinger.org/

5 26

[PATCH]ich_gpio_dump util
by joe＠smittys.pointclark.net 10 Mar '08

10 Mar '08

Here you go, this work great, thanks again Stefan. Signed-off-by: Joseph Smith <joe(a)smittys.pointclark.net> Thanks - Joe

6 23

[LinuxBIOS] Request for superiotool dump support: SMSC LPC47M192
by Corey Osgood 10 Mar '08

10 Mar '08

Hey guys, I've been looking through the datasheet on this chip, and I've got no idea where the values you use come from. I know some of you have been adding dump support to various chips just for the sake of having them (which is a good thing, and I'm glad you're doing it), so I was hoping you might be able to do this one while you're at it. Thanks, Corey

4 10

Re: [coreboot] v2[PATCH]RCA RM4100 i82830 support
by joe＠smittys.pointclark.net 09 Mar '08

09 Mar '08

Hello, I would like to submit my code for the RCA RM4100. Also code for the Intel i82830 Nothbridge, that works great. Everything works great except the ethernet and tv-out. By submitting the code maybe someone could help me figure out the ethernet problem? Anyways here it is: Oops I forgot this: Signed-off-by: Joseph Smith <joe(a)smittys.pointclark.net> Thanks - Joe

4 25

Geode GX / CS5535 / PIC
by Martin Trautmann 07 Mar '08

07 Mar '08

Hi all, I'm lost how to build a new BIOS for a Geode GX / CS5535 board. http://www.coreboot.org/AMD_Geode_Porting_Guide is focused on the Geode LX and a db800 reference board. I've found the CS5535 sources at http://tracker.coreboot.org/trac/coreboot/browser/trunk/coreboot-v2/src/sou… but don't know how to use them. The CPU is a Geode GX 500 http://tracker.coreboot.org/trac/coreboot/browser/trunk/coreboot-v2/src/cpu… The board is an AMD Personal Internet Communicator (PIC, now DecTOP): http://50x15.amd.com/en-us/sol_tech_dectop.aspx http://www.amd.com/us-en/ConnectivitySolutions/ProductInformation/0,,50_233… Unfortunately I do not know any access to the board's schematics. AMD has cancelled this project. I'm afraid that its docu is lost. coreboot v3 does not include the GX/CS5535 yet. I don't know whether I should learn how to use v2 or whether v3 will include those soon. Thanks for any help, Martin

5 13

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