coreboot January 2008

coreboot@coreboot.org

79 participants
347 discussions

by Masoud Fatollahy

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

10 years, 5 months

[LinuxBIOS] Add initial support for intel i855gme northbridge

by Jon Dufresne

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>

12 years

[LinuxBIOS] A8N5X port

by Robert Millan

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

12 years, 2 months

LZMA magic number

by Myles Watson

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

12 years, 3 months

flashrom verify fails, CK804, MCP55

by Tiago Marques

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 >

12 years, 7 months

[LinuxBIOS] flashrom support for AMD Geode CS5536

by Lane Brooks

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

12 years, 8 months

[LinuxBIOS] flashrom on ga 2761gxdk

by ron minnich

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

12 years, 8 months

Re: [coreboot] [LinuxBIOS] FILO with the USB

by Corey Osgood

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

12 years, 9 months

[LinuxBIOS] [PATCH] TeleVideo TC7020 support (2nd try)

by Kenji Noguchi

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

12 years, 10 months

[LinuxBIOS] [RFC][PATCH] v3: lar header after member support

by Carl-Daniel Hailfinger

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

12 years, 10 months

Jump to page:

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot January 2008