coreboot November 2007

coreboot@coreboot.org

75 participants
397 discussions

[LinuxBIOS] [PATH] irq routing on cs5530a/cs5536
by Nikolay Petukhov 26 Nov '07

26 Nov '07

Here patch to support IRQ routing by LinuxBios. This is necessary for the right setup on the unsupported Linux's chips. This functionality is include through macro PIRQ_ROUTE in Config.lb. Tested on iei/juki-511p(cs5530a) and iei/pcisa-lx(cs5536). Signed-off-by: Nikolay Petukhov <nikolay.petukhov(a)gmail.com> -- Nikolay

1 0

[LinuxBIOS] It's always fun to watch the very first boot on real hardware :-) (This is on alix 1c)
by ron minnich 26 Nov '07

26 Nov '07

LinuxBIOS-3.0.0 Sun Nov 25 19:26:24 PST 2007 starting... Choosing fallback boot. LAR: Attempting to open 'fallback/initram'. LAR: Start 0xfff80000 len 0x80000 LAR: seen member normal/payload/segment0 LAR: seen member normal/payload/segment1 LAR: seen member normal/option_table LAR: seen member normal/stage2 LAR: seen member normal/initram LAR: seen member bootblock LAR: NO FILE FOUND! LAR: Run file fallback/initram failed: No such file. Fallback failed. Try normal boot LAR: Attempting to open '… [View More]

1 0

[LinuxBIOS] r2986 build service
by LinuxBIOS information 25 Nov '07

25 Nov '07

Dear LinuxBIOS readers! This is the automated build check service of LinuxBIOS. The developer "uwe" checked in revision 2986 to the LinuxBIOS source repository and caused the following changes: Change Log: Dump support for SMSC FDC37C67x. Signed-off-by: Robinson P. Tryon <bishop.robinson(a)gmail.com> Acked-by: Uwe Hermann <uwe(a)hermann-uwe.de> Build Log: Compilation of msi:ms9185 is still broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2986… [View More]

1 0

[LinuxBIOS] superiotool - dump support for fdc37c672
by Robinson Tryon 25 Nov '07

25 Nov '07

Signed-off-by: Robinson P. Tryon <bishop.robinson(a)gmail.com> I also looked at the FDC37M707, which appears to have a chip id of 0x42, but in the table there is already {0x42, "FDC37B80x" ...}. Are these the same chip, or?

2 1

[LinuxBIOS] r2986 - trunk/util/superiotool
by svn＠openbios.org 25 Nov '07

25 Nov '07

Author: uwe Date: 2007-11-25 22:43:29 +0100 (Sun, 25 Nov 2007) New Revision: 2986 Modified: trunk/util/superiotool/smsc.c Log: Dump support for SMSC FDC37C67x. Signed-off-by: Robinson P. Tryon <bishop.robinson(a)gmail.com> Acked-by: Uwe Hermann <uwe(a)hermann-uwe.de> Modified: trunk/util/superiotool/smsc.c =================================================================== --- trunk/util/superiotool/smsc.c 2007-11-25 03:49:43 UTC (rev 2985) +++ trunk/util/superiotool/smsc.c … [View More]

1 0

[LinuxBIOS] [PATCH] v3: improve LAR comments, fix possible access to uninitialized memory
by Carl-Daniel Hailfinger 25 Nov '07

25 Nov '07

Fix a corner case access to uninitialized memory (NULL pointer dereference or worse) in case the archive length is exactly sizeof(struct lar_header). Such an archive is invalid because the filename directly after the LAR header is always dereferenced and has to be at least 1 byte in the "empty filename" case (only terminating \0). Improve LAR code documentation and reorder variables in one assignment to make the code more obvious and readable. This will help people understand what the code does … [View More]when they look at it half a year from now. Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006(a)gmx.net> --- Index: LinuxBIOSv3/include/lar.h =================================================================== --- LinuxBIOSv3/include/lar.h (Revision 505) +++ LinuxBIOSv3/include/lar.h (Arbeitskopie) @@ -52,10 +52,9 @@ #include <types.h> -/* see note in lib/lar.c as to why this is ARCHIVE and not LARCHIVE */ #define MAGIC "LARCHIVE" #define MAX_PATHLEN 1024 -/* NOTE -- This and the user-mode lar.h are NOT IN SYNC. Be careful. */ +/* NOTE -- This and the user-mode lar.h may NOT be IN SYNC. Be careful. */ struct lar_header { char magic[8]; u32 len; Index: LinuxBIOSv3/lib/lar.c =================================================================== --- LinuxBIOSv3/lib/lar.c (Revision 505) +++ LinuxBIOSv3/lib/lar.c (Arbeitskopie) @@ -49,7 +49,7 @@ * Given a file name in the LAR , search for it, and fill out a return struct with the * result. * @param archive A descriptor for current archive. This is actually a mem_file type, - * which is a machine-dependent representation of hte actual archive. In particular, + * which is a machine-dependent representation of the actual archive. In particular, * things like u32 are void * in the mem_file struct. * @param filename filename to find * @param result pointer to mem_file struct which is filled in if the file is found @@ -65,30 +65,43 @@ printk(BIOS_SPEW, "LAR: Start %p len 0x%x\n", archive->start, archive->len); - if (archive->len < sizeof(struct lar_header)) - printk(BIOS_ERR, "Error: truncated archive (%d bytes); minimum possible size is %d bytes\n", - archive->len, sizeof(struct lar_header)); + /* Why check for sizeof(struct lar_header) + 1? The code below expects + * a filename to follow directly after the LAR header and will + * dereference the address directly after the header. However, if + * archive->len == sizeof(struct lar_header), printing the filename + * will dereference memory outside the archive. Without looking at the + * filename, the only thing we can check is that there is at least room + * for an empty filename (only the terminating \0). + */ + if (archive->len < sizeof(struct lar_header) + 1) + printk(BIOS_ERR, "Error: truncated archive (%d bytes); minimum" + " possible size is %d bytes\n", + archive->len, sizeof(struct lar_header) + 1); - /* Getting this for loop right is harder than it looks. All quantities are - * unsigned. The LAR stretches from (e.g.) 0xfff0000 for 0x100000 - * bytes, i.e. to address ZERO. - * As a result, 'walk', can wrap to zero and keep going (this has been - * seen in practice). Recall that these are unsigned; walk can - * wrap to zero; so, question, when is walk less than any of these: - * archive->start - * Answer: once walk wraps to zero, it is < archive->start - * archive->start + archive->len - * archive->start + archive->len - 1 - * Answer: In the case that archive->start + archive->len == 0, ALWAYS! - * A lot of expressions have been tried and all have been wrong. - * So what would work? Simple: - * test for walk < archive->start + archive->len - 1 to cover the case - * that the archive does NOT occupy ALL of the top of memory and - * wrap to zero; - * and test for walk >= archive->start, - * to cover the case that you wrapped to zero. - * Unsigned pointer arithmetic that wraps to zero can be messy. - */ + /* Getting this for loop right is harder than it looks. All quantities + * are unsigned. The LAR stretches from (e.g.) 0xfff0000 for 0x100000 + * bytes, i.e. to address ZERO. + * As a result, 'walk', can wrap to zero and keep going (this has been + * seen in practice). Recall that these are unsigned; walk can + * wrap to zero; so, question, when is walk less than any of these: + * archive->start + * Answer: once walk wraps to zero, it is < archive->start + * archive->start + archive->len + * archive->start + archive->len - 1 + * Answer: In the case that archive->start + archive->len == 0, ALWAYS! + * A lot of expressions have been tried and all have been wrong. + * So what would work? Simple: + * test for walk < archive->start + archive->len - sizeof(lar_header) + * to cover the case that the archive does NOT occupy ALL of the + * top of memory and wrap to zero; RESIST the temptation to change + * that comparison to <= because if a header did terminate the + * archive, the filename (stored directly after the header) would + * be outside the archive and you'd get a nice NULL pointer for + * the filename + * and test for walk >= archive->start, + * to cover the case that you wrapped to zero. + * Unsigned pointer arithmetic that wraps to zero can be messy. + */ for (walk = archive->start; (walk < (char *)(archive->start + archive->len - sizeof(struct lar_header))) && (walk >= (char *)archive->start); walk += 16) { @@ -98,7 +111,7 @@ header = (struct lar_header *)walk; fullname = walk + sizeof(struct lar_header); - printk(BIOS_SPEW, "LAR: search for %s\n", fullname); + printk(BIOS_SPEW, "LAR: seen member %s\n", fullname); // FIXME: check checksum if (strcmp(fullname, filename) == 0) { @@ -115,11 +128,20 @@ result->compression, result->entry, result->loadaddress); return 0; } - // skip file - walk += (ntohl(header->len) + ntohl(header->offset) - - 1) & 0xfffffff0; + /* skip file: + * The next iteration of the for loop will add 16 to walk, so + * we now add offset (from header start to data start) and len + * (member length), subtract 1 (to get the address of the last + * byte of the member) and round this down to the next 16 byte + * boundary. + * 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. + */ + walk += (ntohl(header->offset) + ntohl(header->len) - 1) + & 0xfffffff0; } - printk(BIOS_SPEW, "NO FILE FOUND\n"); + printk(BIOS_SPEW, "LAR: NO FILE FOUND\n"); return 1; } @@ -157,7 +179,7 @@ * the loadaddress pointer in the mem_file struct. * @param archive A descriptor for current archive. * @param filename filename to find - * returns 0 on success, -1 otherwise + * returns entry on success, (void*)-1 otherwise */ void *load_file(struct mem_file *archive, const char *filename) Index: LinuxBIOSv3/util/lar/lar.h =================================================================== --- LinuxBIOSv3/util/lar/lar.h (Revision 505) +++ LinuxBIOSv3/util/lar/lar.h (Arbeitskopie) @@ -61,13 +61,15 @@ typedef uint32_t u32; typedef uint8_t u8; -/* NOTE -- This and the linuxbios lar.h are NOT IN SYNC. Be careful. */ +/* NOTE -- This and the user-mode lar.h may NOT be IN SYNC. Be careful. */ struct lar_header { char magic[8]; u32 len; u32 reallen; u32 checksum; u32 compchecksum; + /* Filenames are limited to 2^31-1-sizeof(lar_header)-1 bytes. + * "Nobody will ever need more than 640k" */ u32 offset; /* Compression: * 0 = no compression Index: LinuxBIOSv3/arch/x86/stage1.c =================================================================== --- LinuxBIOSv3/arch/x86/stage1.c (Revision 505) +++ LinuxBIOSv3/arch/x86/stage1.c (Arbeitskopie) @@ -69,7 +69,7 @@ } /* - * This function is called from assembler code whith its argument on the + * This function is called from assembler code with its argument on the * stack. Force the compiler to generate always correct code for this case. */ void __attribute__((stdcall)) stage1_main(u32 bist) @@ -140,7 +140,7 @@ } else { printk(BIOS_DEBUG, "Choosing fallback boot.\n"); ret = execute_in_place(&archive, "fallback/initram"); - /* Try a normal boot if fallback doesn't exists in the lar. + /* Try a normal boot if fallback doesn't exist in the lar. * TODO: There are other ways to do this. * It could be ifdef or the boot flag could be forced. */ [View Less]

2 3

[LinuxBIOS] [PATCH] superiotool: Use 'static const' instead of 'const static'
by Uwe Hermann 25 Nov '07

25 Nov '07

See patch. Uwe. -- http://www.hermann-uwe.de | http://www.holsham-traders.de http://www.crazy-hacks.org | http://www.unmaintained-free-software.org

2 3

[LinuxBIOS] "Trivial" patches
by Carl-Daniel Hailfinger 25 Nov '07

25 Nov '07

Hi, various big code changes/additions have been committed as trivial by others in the past, so I am considering to follow the same policy and declare all of my future patches as trivial and commit them instantly if I feel like it. That would surely speed up development for me. Comments/Flames/Applause welcome. Regards, Carl-Daniel

8 14

[LinuxBIOS] [ADMIN] Mail headers: random variations?
by Carl-Daniel Hailfinger 25 Nov '07

25 Nov '07

Hi, (yes, I read mail headers.) I have noticed that mails I receive via the list can have two differing Return-Paths, depending on some random circumstances. Both of the following header lines have been seen for mails sent 3 seconds after each other, differing in amost nothing except the Return-Path: Return-Path: <linuxbios-bounces+c-d.hailfinger.devel.2006=gmx.net(a)linuxbios.org> Return-Path: <linuxbios-bounces(a)linuxbios.org> The Return-Path variation is independent of the … [View More]

4 3

[LinuxBIOS] r2985 build service
by LinuxBIOS information 25 Nov '07

25 Nov '07

Dear LinuxBIOS readers! This is the automated build check service of LinuxBIOS. The developer "cozzie" checked in revision 2985 to the LinuxBIOS source repository and caused the following changes: Change Log: More abuild fixes, the previous ones weren't enough. Hopefully this covers everything. Signed-off-by: Corey Osgood <corey.osgood(a)gmail.com> Acked-by: Corey Osgood <corey.osgood(a)gmail.com> Build Log: Compilation of amd:serengeti_cheetah has been fixed Compilation of … [View More]

1 0

← Newer
1
...
11
12
13
14
15
16
17
...
40
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot November 2007