coreboot January 2008

coreboot@coreboot.org

79 participants
347 discussions

filo and usb boot
by Masoud Fatollahy 18 Aug '10

18 Aug '10

Hi, Why is it problem to boot from an usb port when we are using linuxbios and filo. as I can see all usb code are there, what is missing? Thanks, /Masoud

4 8

[LinuxBIOS] Add initial support for intel i855gme northbridge
by Jon Dufresne 20 Jan '09

20 Jan '09

Add initial support for i855gme. This is a work in progress and I don't expect it to work on all boards, or even any besides mine. This is based heavily on i855pm. Signed off by Jon Dufresne <jon.dufresne(a)gmail.com>

4 4

[LinuxBIOS] A8N5X port
by Robert Millan 21 Nov '08

21 Nov '08

This patch includes config files for the asus/a8n5x port. It is the same as asus/a8n_e with a different pnp layout, so I used #include's whenever possible. System boots and is usable with usb keyboard. works: - serial port - vga (old pci card) - memtest86+ succeeds, but only with Rudolf's patch for unbuffered dimms in K8. Otherwise you get spurious memory corruption. - ide disk - usb doesn't: - ps/2 keyboard - onboard ethernet - vga pci-e card (??) - any other pci card I tried wasn't tested: - sata - game port - onboard audio (not supported by alsa anyway) - ps/2 mouse -- Robert Millan <GPLv2> I know my rights; I want my phone call! <DRM> What use is a phone call, if you are unable to speak? (as seen on /.)

8 27

LZMA magic number
by Myles Watson 30 Sep '08

30 Sep '08

Is there a magic number for LZMA? Should there be? I accidentally used an uncompressed payload with v2 when it expected a compressed payload, and it gave me the message: Decoder scratchpad too small!! Decoding error = 1 I think it would be nicer to have an error like: Payload not compressed with lzma! Myles

5 9

flashrom verify fails, CK804, MCP55
by Tiago Marques 21 Jun '08

21 Jun '08

On two boards, one MCP55 based and another CK804, if I flash the proprietary BIOS with: flasrom -wv bios.bin Verification fails and if I try to boot, it doesn't. Have to flash the BIOS in another board based on K8T890 that I have. In that one all works fine, with both BIOS chips I have - one winbond and a PMC. Haven't tried flashing coreboot due to lack of support. Since the chipsets are support, this isn't supposed to happen, right? Best regards, Tiago Marques On 1/27/08, Stefan Reinauer <stepan(a)coresystems.de> wrote: > * Tiago Marques <tiagomnm(a)gmail.com> [080127 16:21]: > > Hi. > > Both failed, tried with two different BIOS chips. > > Flashing with AWDFlash works fine though. > > Had to flash it again in a VIA K8T890 board, which works flawlessly. > > Any ideas, fix? > > What's the problem? > > -- > 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 >

4 13

[LinuxBIOS] flashrom support for AMD Geode CS5536
by Lane Brooks 16 May '08

16 May '08

Attached is a patch that enables AMD Geode CS5536 chipset support. I have tested it successfully on a MSM800 board from digital logic. It does, however, have a few issues that I would like some feedback on. In my discussions with Marc Jones, Geode systems write protect the BIOS via RCONFs (cache settings similar to MTRRs). Unlocking requires changing MSR 0x1808 top byte to 0x22. Reading and writing to the msr, however, requires instrucitons rdmsr/wrmsr, which are ring0 privileged instructions so only the kernel can do the read/write. So my patch uses the msr kernel module to access these instructions from user space using the /dev/cpu/0/msr device. My questions are: - I do not think this is portable beyond linux. Is that an issue? - My code assumes the msr kernel module is already loaded. Is there a way to force a kernel module to load from the C code? My code does die gracefully with a message reminding them to load the kernel module if things fail. - It seems like there should be a way to revert the msr back after flashing is completed to put the bios back in write protect mode. Is there a cleanup mechanism available? Something like disable_flash... Thanks, Lane Brooks

8 17

[LinuxBIOS] flashrom on ga 2761gxdk
by ron minnich 16 May '08

16 May '08

It now finds the part, and gets ready to program it, but exits instantly without doing anything. I think this is the culprit: void generic_spi_page_program(int block, uint8_t *buf, uint8_t *bios) { if (it8716f_flashport) it8716f_spi_page_program(block, buf, bios); } i.e. the flashport is not set. So, before I dig too far into this, is there some simple thing I should look at to get flashrom working on this board? Also, seems to me it's a pretty serious error if this can not be determined, ... anyone mind if I add an error message? right now it exits with no error, having done no work :-) thanks ron

5 28

Re: [coreboot] [LinuxBIOS] FILO with the USB
by Corey Osgood 01 Apr '08

01 Apr '08

Sorry to be a pain, but any progress with this? Thanks, Corey > OK, thank you. > My employer approved the submission. I"ll do it soon. > > On Nov 26, 2007 1:24 AM, Corey Osgood <[EMAIL PROTECTED]> wrote: > > > Fridel Fainshtein wrote: > > > OK, > > > > > > supposing FILO USB works > > > How do I submit the corrections? > > > > > > > http://www.linuxbios.org/Development_Guidelines#How_to_contribute > > > > In short form: > > 1) cd to the filo-0.5/ folder > > 2) svn add * -R (if you've created any new files, be sure to move files > > you don't want added first) > > 3) svn diff > clever_patchname.patch > > 4) edit the patch, add a short description of what the patch does (which > > goes into the svn commit log) and a Signed-off-by: line, per the > > guidelines linked to above. > > > > Thanks! > > -Corey > >

5 19

[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

Jump to page:

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot January 2008