coreboot August 2007

coreboot@coreboot.org

78 participants
202 discussions

[LinuxBIOS] r2752 - trunk/util/flashrom
by svn＠openbios.org 30 Aug '07

30 Aug '07

Author: uwe Date: 2007-08-30 12:11:08 +0200 (Thu, 30 Aug 2007) New Revision: 2752 Modified: trunk/util/flashrom/README trunk/util/flashrom/flash.h trunk/util/flashrom/flashchips.c Log: Add support for the Winbond W29C040P. Signed-off-by: Markus Boas <ryven(a)ryven.de> Acked-by: Uwe Hermann <uwe(a)hermann-uwe.de> Modified: trunk/util/flashrom/README =================================================================== --- trunk/util/flashrom/README 2007-08-29 17:52:32 UTC (rev 2751) +++ trunk/util/flashrom/README 2007-08-30 10:11:08 UTC (rev 2752) @@ -149,6 +149,7 @@ SyncMOS S29C31004T Winbond W29C011 Winbond W29C020C +Winbond W29C040P Winbond W49F002U Winbond W49V002A Winbond W49V002FA Modified: trunk/util/flashrom/flash.h =================================================================== --- trunk/util/flashrom/flash.h 2007-08-29 17:52:32 UTC (rev 2751) +++ trunk/util/flashrom/flash.h 2007-08-30 10:11:08 UTC (rev 2752) @@ -101,6 +101,7 @@ #define WINBOND_ID 0xDA /* Winbond */ #define W_29C011 0xC1 #define W_29C020C 0x45 +#define W_29C040P 0x46 #define W_39V040FA 0x34 #define W_39V040A 0x3D #define W_39V040B 0x54 Modified: trunk/util/flashrom/flashchips.c =================================================================== --- trunk/util/flashrom/flashchips.c 2007-08-29 17:52:32 UTC (rev 2751) +++ trunk/util/flashrom/flashchips.c 2007-08-30 10:11:08 UTC (rev 2752) @@ -82,6 +82,8 @@ probe_jedec, erase_chip_jedec, write_49fl004}, {"W29C011", WINBOND_ID, W_29C011, 128, 128, probe_jedec, erase_chip_jedec, write_jedec}, + {"W29C040P", WINBOND_ID, W_29C040P, 512, 256, + probe_jedec, erase_chip_jedec, write_jedec}, {"W29C020C", WINBOND_ID, W_29C020C, 256, 128, probe_jedec, erase_chip_jedec, write_jedec}, {"W49F002U", WINBOND_ID, W_49F002U, 256, 128,

1 0

[LinuxBIOS] support PIC and prototypes
by ron minnich 30 Aug '07

30 Aug '07

Here is a proposal for supporting pic etc. without too much hardship. we create a file, include/lib.h, and move all prototypes to that file. That file is included by non-pic code, and has declarations like this: int printk(int level, char *format, ...); We create another file, call libpic.h, and it looks like this: int (*printk)(int level, char *format, ...) = stage0printk; PIC programs include libpic.h. non-PIC programs include lib.h. At build time, for PIC programs, we use that little trick I showed earlier to create a stag0_pic.o with symbols renamed, e.g. printk becomes stage0printk. non-PIC programs (e.g. stage2) link against stage0.o as they do now. PIC programs link against stage0_pic.o. This will work; is it acceptable? ron

3 5

[LinuxBIOS] difference between uint16_t and u16
by matt 30 Aug '07

30 Aug '07

i have noticed several patches signed off on the list that change data types from uint16_t to u16 and the like (8 .. 32 bit signed and unsigned) and was wondering why ? i thought uint16_t was c99 standard ? i asked the same thing on sdl's mailing list and was told that not all compilers support it. with sdl that seems right since its a platform independent lib. with linuxbios it seems that is not the case, i assume most or all would be using gcc. only reason i ask is that a standard header was added years ago and i still see custom data types. just trying to understand that better. thanks matt

2 1

Re: [LinuxBIOS] [RFC] Call for Action: LinuxBIOS foundations
by Robert Vogel 30 Aug '07

30 Aug '07

----- Original Message ----- From: "Joseph Smith" <joe(a)smittys.pointclark.net> To: <linuxbios(a)linuxbios.org> Sent: Wednesday, August 29, 2007 5:08 PM Subject: Re: [LinuxBIOS] [RFC] Call for Action: LinuxBIOS foundations > Quoting Corey Osgood <corey.osgood(a)gmail.com>: >> >> But I don't really see why there's a concern about Tivoization, >> perhaps I'm just ignorant of how it could be implemented. >> > Yeh, maybe I'm ignorant also?? What do you mean by Tivoization?? > LinuxBios on set-top-boxes?? Hardware hacking?? Fill me in.... > > Thanks - Joe > > -- > linuxbios mailing list > linuxbios(a)linuxbios.org > http://www.linuxbios.org/mailman/listinfo/linuxbios > > If you buy a Tivo, you have a right to get a copy of the software and you can. But, I'm told, if you modify it in any way...it will not run. That's Tivoization. It is not so different than a motherboard which might be 'bricked' if you modify the BIOS. GPLV3 prevents this kind of practice.

1 0

[LinuxBIOS] patch: extending LAR, and removing elf from linuxbios (it is not needed)
by ron minnich 30 Aug '07

30 Aug '07

don't get too scared about the subject line. LAR is a very capable format. With two simple extensions, we can use LAR to replace all that we are using ELF for now. This change can really make life better: 1. we can use streaming decompress instead of the current "uncompress elf to memory and then copy segments" approach. So we can get rid of THIS hardcode: #define UNCOMPRESS_AREA (0x400000) 2. A simple lar l can show ALL segments, including payload segments 3. It's really easy to see where things will go in memory, and catch problems 4. We can figure out an ELF input file is bogus BEFORE we flash, not AFTER we flash and try to boot it 5. did I mention streaming decompress? 6. We no longer have to worry about where we decompress the elf in memory (this problem was causing trouble when the payload was a linux kernel -- it was so big) 7. Since we have a load address, we can create this lar entry: normal/cmdline and specify that it be loaded at a place where linux will find it as the cmdline. 8. The decision on whether to XIP can be made in the LAR entry, not in hardcode. For example, if initram needs to be XIP, set the load address to 0xffffffff. Done. The change is simple. Add a load address and entry point to the lar header. Extend the lar tool to parse the elf file and create multiple lar segments. It looks like this: normal/payload0 (33192 bytes, lzma compressed to 18088 bytes @0x38 load @0x100000, entry 0x105258) normal/payload1 (72 bytes, lzma compressed to 47 bytes @0x4718 load @0x1225a0, entry 0x105258) normal/option_table (932 bytes @0x4798 load @0, entry 0) normal/stage2 (33308 bytes, lzma compressed to 15474 bytes @0x4b78 load @0, entry 0) normal/initram (4208 bytes @0x8828 load @0, entry 0) linuxbios.bootblock (16384 bytes @0xfc000 load @0, entry 0) note that the payload is now payload0, payload1, etc. I've extended linuxbios to look for these. Note that you can now see all the things that get loaded ;they're no longer hidden in an ELF header somewhere. Elf failures are gone! Note that I've left legacy elf support in, for now, but recommend we get rid of it as soon as possible. patch attached. This is a first pass. lar.c needs some refactoring but I want to get the comments going. You can now have a linux payload and it will uncompress with no problems. This has been tested with filo and BOCHS. ron

6 62

[LinuxBIOS] r485 - in LinuxBIOSv3: arch/x86 include lib util/lar
by svn＠openbios.org 30 Aug '07

30 Aug '07

Author: rminnich Date: 2007-08-30 00:27:31 +0200 (Thu, 30 Aug 2007) New Revision: 485 Modified: LinuxBIOSv3/arch/x86/stage1.c LinuxBIOSv3/include/lar.h LinuxBIOSv3/lib/lar.c LinuxBIOSv3/util/lar/lar.h Log: Make the load address and entry 64 bits. Remove a broken proto from a c file. Fix protos etc. per uwe's request for const where it made sense. Signed-off-by: Ronald G. Minnich <rminnich(a)gmail.com> Acked-by: Peter Stuge <peter(a)stuge.se> Modified: LinuxBIOSv3/arch/x86/stage1.c =================================================================== --- LinuxBIOSv3/arch/x86/stage1.c 2007-08-29 16:42:58 UTC (rev 484) +++ LinuxBIOSv3/arch/x86/stage1.c 2007-08-29 22:27:31 UTC (rev 485) @@ -36,7 +36,6 @@ /* these prototypes should go into headers */ void uart_init(void); void die(const char *msg); -int find_file(struct mem_file *archive, char *filename, struct mem_file *result); void hardware_stage1(void); void disable_car(void); Modified: LinuxBIOSv3/include/lar.h =================================================================== --- LinuxBIOSv3/include/lar.h 2007-08-29 16:42:58 UTC (rev 484) +++ LinuxBIOSv3/include/lar.h 2007-08-29 22:27:31 UTC (rev 485) @@ -69,8 +69,8 @@ * 2 = nrv2b */ u32 compression; - u32 entry; /* we might need to make this u64 */ - u32 loadaddress; /* ditto */ + u64 entry; + u64 loadaddress; }; struct mem_file { @@ -83,10 +83,10 @@ }; /* Prototypes. */ -int find_file(struct mem_file *archive, char *filename, struct mem_file *result); -int copy_file(struct mem_file *archive, char *filename, void *where); -int run_file(struct mem_file *archive, char *filename, void *where); -int execute_in_place(struct mem_file *archive, char *filename); +int find_file(struct mem_file *archive, const char *filename, struct mem_file *result); +int copy_file(struct mem_file *archive, const char *filename, void *where); +int run_file(struct mem_file *archive, const char *filename, void *where); +int execute_in_place(struct mem_file *archive, const char *filename); int run_address(void *f); -void *load_file(struct mem_file *archive, char *filename); +void *load_file(struct mem_file *archive, const char *filename); #endif /* LAR_H */ Modified: LinuxBIOSv3/lib/lar.c =================================================================== --- LinuxBIOSv3/lib/lar.c 2007-08-29 16:42:58 UTC (rev 484) +++ LinuxBIOSv3/lib/lar.c 2007-08-29 22:27:31 UTC (rev 485) @@ -31,6 +31,13 @@ #define ntohl(x) (x) #endif +/** + * run_address is passed the address of a function taking no parameters and + * jumps to it, returning the result. + * @param v the address to call as a function. + * returns value returned by the function. + */ + int run_address(void *f) { int (*v) (void); @@ -38,7 +45,18 @@ return v(); } -int find_file(struct mem_file *archive, char *filename, struct mem_file *result) +/** + * 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, + * 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 + * returns 0 on success, -1 otherwise + */ + +int find_file(struct mem_file *archive, const char *filename, struct mem_file *result) { char *walk, *fullname; struct lar_header *header; @@ -105,8 +123,15 @@ return 1; } +/** + * Given a file name in the LAR , search for it, and load it into memory, using + * 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 + */ -void *load_file(struct mem_file *archive, char *filename) +void *load_file(struct mem_file *archive, const char *filename) { int ret; struct mem_file result; @@ -149,7 +174,15 @@ } /* FIXME -- most of copy_file should be replaced by load_file */ -int copy_file(struct mem_file *archive, char *filename, void *where) +/** + * Given a file name in the LAR , search for it, and load it into memory, + * using the passed-in pointer as the address + * @param archive A descriptor for current archive. + * @param filename filename to find + * @param where pointer to where to load the data + * returns 0 on success, -1 otherwise + */ +int copy_file(struct mem_file *archive, const char *filename, void *where) { int ret; struct mem_file result; @@ -190,10 +223,15 @@ /** - * Find the file in the LAR header, copy it to the desired location, - * and execute it. A location of 0xFFFFFFFF means execute in place (XIP). + * Given a file name in the LAR , search for it, and load it into memory, + * using the passed-in pointer as the address; jump to the file. + * If the passed-in pointer is (void *)-1, then execute the file in place. + * @param archive A descriptor for current archive. + * @param filename filename to find + * @param where pointer to where to load the data + * returns 0 on success, -1 otherwise */ -int run_file(struct mem_file *archive, char *filename, void *where) +int run_file(struct mem_file *archive, const char *filename, void *where) { int (*v) (void); struct mem_file result; @@ -217,15 +255,18 @@ } printk(BIOS_SPEW, "where is %p\n", where); v = where; - ret = v(); + ret = v(); printk(BIOS_SPEW, "run_file returns with %d\n", ret); return ret; } /** - * Call run_file() to execute in place. + * Given a file name in the LAR , search for it, and execute it in place. + * @param archive A descriptor for current archive. + * @param filename filename to find + * returns 0 on success, -1 otherwise */ -int execute_in_place(struct mem_file *archive, char *filename) +int execute_in_place(struct mem_file *archive, const char *filename) { return run_file(archive, filename, (void *) 0xFFFFFFFF); } Modified: LinuxBIOSv3/util/lar/lar.h =================================================================== --- LinuxBIOSv3/util/lar/lar.h 2007-08-29 16:42:58 UTC (rev 484) +++ LinuxBIOSv3/util/lar/lar.h 2007-08-29 22:27:31 UTC (rev 485) @@ -57,6 +57,7 @@ #define BOOTBLOCK_NAME "bootblock" #define BOOTBLOCK_NAME_LEN 16 +typedef uint64_t u64; typedef uint32_t u32; typedef uint8_t u8; @@ -74,8 +75,8 @@ * 2 = nrv2b */ u32 compression; - u32 entry; /* we might need to make this u64 */ - u32 loadaddress; /* ditto */ + u64 entry; + u64 loadaddress; }; /**\struct

1 0

[LinuxBIOS] resend: [5/5] Open Firmware on LinuxBIOS on M57SLI
by Torsten Duwe 29 Aug '07

29 Aug '07

This may look right, but it is a bad kludge. Open Firmware, when "biosload"ed, expects a top-of-RAM at physical address 0x1004 ( mem-info-pa 4 + ) , as a little endian pointer. LinuxBIOS however only provides its tables. There's currently code in the queue from Jens Freimann to parse the LB tables, and OFW should ideally get its info from that, but the stuff is not yet stable (right, Jens?) and providing the table info to the /memory device init is still to be written. Until openfirmware/cpu/x86/pc/biosload/probemem.fth is changed or maybe even an openfirmware/cpu/x86/pc/linuxbiosload is created, use this evil hack. The memory map is parsed anyway to find a RAM buffer for the payload, so I just hook in here to find a 32-bit pointer to the top of RAM, clipped to 3GB, to not confuse the payload :) Signed-off-by: Torsten Duwe <duwe(a)lst.de> Recommendation: do _NOT_ apply! I admit that I wrote this, but only as an interim solution.

1 0

[LinuxBIOS] resend: [4/5] Open Firmware on LinuxBIOS on M57SLI
by Torsten Duwe 29 Aug '07

29 Aug '07

Open Firmware is a little larger than 256k, so building a LBv2 with normal and fallback is out of the question with 512k ROMs. This config just builds one big image. The patch is less useful, the result is much more readable. Signed-off-by: Torsten Duwe <duwe(a)lst.de> Recommendation: supply as alternative config

1 0

[LinuxBIOS] resend: [3/5] Open Firmware on LinuxBIOS on M57SLI
by Torsten Duwe 29 Aug '07

29 Aug '07

I found qemu to be tremendously accurate and thus time-saving. This patch adds the add-on/VGA ROM options and increases the image size. A real VGA is not yet working, no mode is set after power-on but qemu shows exactly the same behaviour. Requires qemu patches like on http://www.openbios.org/Open_Firmware Signed-off-by: Torsten Duwe <duwe(a)lst.de> Recommendation: maybe apply after some testing.

1 0

[LinuxBIOS] pre-bricking an A8N-E !
by Quux 29 Aug '07

29 Aug '07

I am glad you're asking this question (please also refer to MIT's "The Hacker's dictionary / jargon file) "*to brick*" a router (for example) can be done by flashing non-working firmware into it rendering it useless without chance for reversal. It is an expensive door-stop, a brick, or a letter weight or sth. low-tec after that. a "de-bricking" utility is one ( notorious is the debricking tool by a guy who likes to call himself *"hairy dairy maid"* and used in the openWRT router project, employing a JPEG hardware interface) pre-bricking thus might refer to a process where a mainboard is flashed with a disfunctional BIOS image, thus bricking it - but where it is done with a chance of reversal with further expenditure on additional hard-soft/w it is only in a pre-brick state even though delivering the final blow to it would not be much harder ! --Q Robert Vogel schrieb: > This is probably a dumb question. > > What is "pre-bricking" ? > > > ----- Original Message ----- From: "Quux" <pawn2be.wild(a)yahoo.de> > To: "LinuxBIOS" <linuxbios(a)linuxbios.org> > Sent: Thursday, August 23, 2007 6:00 PM > Subject: [LinuxBIOS] yo, pre-bricking an A8N-E ! > > > wow, it only took me only 3 hrs to pre-brick the Asus A8N-E I got at > ebay for €22. > > I would have been faster, but the ROM / IMAGE SIZE of the current > revision ist stated as 7F00 instead of 20000hex as in the M57SLI > target. Once I fixed that I could flash the current revision - and the > POST card gives me a steady 80. > > I keep you guys informed but the ASUS A8N target is not even flashable > currently (Also the wiki - downloadable ROM image is bad size (20000hex > required)). > I plan to put together a CDROM .ISO file (a remastered dream linux) with > the LB tree and ready-to-flash working filo-ROM-image. should be a > quickie. --Q >

3 2

← Newer
1
2
3
4
5
6
7
8
...
21
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 August 2007