coreboot April 2008

coreboot@coreboot.org

75 participants
404 discussions

#93: Add a gcc wrapper script
by coreboot 15 Apr '08

15 Apr '08

#93: Add a gcc wrapper script ---------------------------------+------------------------------------------ Reporter: uwe | Owner: somebody Type: defect | Status: new Priority: major | Milestone: Component: libpayload | Version: Keywords: | Dependencies: Patchstatus: there is no patch | ---------------------------------+------------------------------------------ libpayload should have a gcc wrapper script which simplifies compilation of libpayload-based payloads a lot. From a user's (payload writer's) perspective compiling a payload should be as simple as replacing "CC=gcc" with "CC=lpgcc" in the Makefile, everything else should be handled by the script (include paths, linker options, etc). -- Ticket URL: <http://tracker.coreboot.org/trac/coreboot/ticket/93> coreboot <http://www.coreboot.org/>

1 1

Trac reminder: list of new ticket(s)
by LinuxBIOS tracker 15 Apr '08

15 Apr '08

1 0

unknown board - via chipset
by Antoine Martin 15 Apr '08

15 Apr '08

Hi, I've got this board I would like to get coreboot flashed on: *eBox-3850 **http://www.icoptech.com/ebox-pc/* 1) CPU is a via C3 Nemehia Northbridge is a VT8623 Southbridge is a VT82xxxxx? 2) # lspci 00:00.0 Host bridge: VIA Technologies, Inc. VT8623 [Apollo CLE266] 00:01.0 PCI bridge: VIA Technologies, Inc. VT8633 [Apollo Pro266 AGP] 00:10.0 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 80) 00:10.3 USB Controller: VIA Technologies, Inc. USB 2.0 (rev 82) 00:11.0 ISA bridge: VIA Technologies, Inc. VT8235 ISA Bridge 00:11.1 IDE interface: VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 06) 00:11.5 Multimedia audio controller: VIA Technologies, Inc. VT8233/A/8235/8237 AC97 Audio Controller (rev 50) 00:12.0 Ethernet controller: VIA Technologies, Inc. VT6102 [Rhine-II] (rev 74) 01:00.0 VGA compatible controller: VIA Technologies, Inc. VT8623 [Apollo CLE266] integrated CastleRock graphics (rev 03) 3) Super I/O: via VT1211 4) Type of BIOS: unknown. The box cannot be opened easily as the cpu is glued on to the case... Which is why I would rather make sure it is possible to flash before I start damaging the box. I've dumped the 256MB bios using the 'flashrom' utility. 5) URL: **http://www.icoptech.com/ebox-pc/files/1EBOXPS_s.pdf Many thanks Antoine

5 12

Re: [coreboot] ELF section compression
by Jeremy Jackson 14 Apr '08

14 Apr '08

It appears the Program Segment Flags is the latest point at which a chunk of a program could be marked as compressed (independent of other chunks) ELF Header gives offset/length of Program Segment header PHDR -Program Segment header[n] entries have struct member u32 p_flags p_flags has 0x0000_0001 exec 0x0000_0002 write 0x0000_0004 read 0xf000000 left for processor specific out of 32 bits, that leaves 25 bits for compression type. Programs are divided into Segments depending on the permissions (.text rx, .data rw), which might separate 1 compressor stream into 2 streams, but, if we're not setting page protection bits in MMU, we could concatenate 2 Segments/ into 1 compressor stream if there's some compressor gains. They are also divided into Segments based on vma/lma, but those could be contiguous for a firmware application. the existing semantics are, if size in memory (p_memsz) is specified bigger than size in file (p_filesz), pad with zeros. What i'm pointing out is there is a field which tells the size in-file... this would just change to being the compressed size. In order for zero-padding to be viable then, the compression algo needs to return the uncompressed size from the data blob. Failing that, p_memsz becomes the uncompressed size, and you loose the zero-padding feature. It would be "neat" for gnu binutils to support this directly. Failing that, we can do what Linux does, export Segments to binary file, run thru gzip, feed back to ld. I'll have to see if LD lets us fiddle with the p_flags, or do we start with a "mkelfimage" that just tweaks them in the output of ld. On Mon, 2008-04-14 at 14:27 -0700, ron minnich wrote: > yeah, but we're a BIOS, what do we care. :-) > > Let me ask the question differently. The implementation is easy, I > will grant that. But where in the segment headers are the flags that > indicate the type of compression used? > > ron -- Jeremy Jackson Coplanar Networks (519)489-4903 http://www.coplanar.net jerj(a)coplanar.net

1 0

Support for ASUS M2A-VM with AMD 690G chipset
by Paul Menzel 14 Apr '08

14 Apr '08

Dear readers, the online shop sent me an ASUS M2A-VM instead of an ASUS M2V-MX SE [1]. They said it is “better”. Anyway, since it has a VGA- and DVI-port and 4 S-ATA connectors, I was wondering to keep it this way. But I think the Flash-chip is *not* socketed. Any new news on when the AMD 690G will be supported [2]? Otherwise I will just send it back to the shop. Since the board is lying on the table. Are pictures of the board needed as Rudolf put some online for the ASUS M2V-MX SE? Could those pictures be licensed under the GPL and uploaded to the wiki? Thanks, Paul [1] http://www.coreboot.org/pipermail/coreboot/2008-April/033144.html [2] http://www.coreboot.org/pipermail/coreboot/2008-January/029599.html

4 3

nrv2b cleanup patch (again)
by Myles Watson 14 Apr '08

14 Apr '08

This very short patch fixes nrv2b compression in lar. It also fixes lzma compression in lar to fix the silent memory corruption that was possible when files didn't compress well. It adds some comments to both files and the file that calls them. Myles Signed-off-by: Myles Watson <mylesgw(a)gmail.com>

2 2

r658 - in coreboot-v3/util: lar lzma nrv2b
by svn＠coreboot.org 14 Apr '08

14 Apr '08

Author: myles Date: 2008-04-14 16:19:09 +0200 (Mon, 14 Apr 2008) New Revision: 658 Modified: coreboot-v3/util/lar/stream.c coreboot-v3/util/lzma/minilzma.cc coreboot-v3/util/nrv2b/nrv2b.c Log: This very short patch fixes nrv2b compression in lar. It also fixes lzma compression in lar to fix the silent memory corruption that was possible when files didn't compress well. It adds some comments to both files and the file that calls them. Signed-off-by: Myles Watson <mylesgw(a)gmail.com> Acked-by: Stefan Reinauer <stepan(a)coresystems.de> Modified: coreboot-v3/util/lar/stream.c =================================================================== --- coreboot-v3/util/lar/stream.c 2008-04-05 20:18:47 UTC (rev 657) +++ coreboot-v3/util/lar/stream.c 2008-04-14 14:19:09 UTC (rev 658) @@ -846,7 +846,7 @@ /** * Compress an area according to an algorithm. If the area grows, - * use no compression. + * use no compression. The size of temp should be at least size bytes. * @param ptr data to be compressed * @param size size of the data * @param temp destination of compressed data Modified: coreboot-v3/util/lzma/minilzma.cc =================================================================== --- coreboot-v3/util/lzma/minilzma.cc 2008-04-05 20:18:47 UTC (rev 657) +++ coreboot-v3/util/lzma/minilzma.cc 2008-04-14 14:19:09 UTC (rev 658) @@ -283,11 +283,21 @@ #else extern "C" { +/** + * Compress a buffer with lzma + * Don't copy the result back if it is too large. + * @param in a pointer to the buffer + * @param in_len the length in bytes + * @param out a pointer to a buffer of at least size in_len + * @param out_len a pointer to the compressed length of in + */ + void do_lzma_compress(char *in, int in_len, char *out, int *out_len) { std::vector<unsigned char> result; result = LZMACompress(std::vector<unsigned char>(in, in + in_len)); *out_len = result.size(); - std::memcpy(out, &result[0], *out_len); + if (*out_len < in_len) + std::memcpy(out, &result[0], *out_len); } void do_lzma_uncompress(char *dst, int dst_len, char *src, int src_len) { Modified: coreboot-v3/util/nrv2b/nrv2b.c =================================================================== --- coreboot-v3/util/nrv2b/nrv2b.c 2008-04-05 20:18:47 UTC (rev 657) +++ coreboot-v3/util/nrv2b/nrv2b.c 2008-04-14 14:19:09 UTC (rev 658) @@ -1304,11 +1304,28 @@ #endif #ifdef COMPACT + +/** + * Compress a buffer with nrv2b + * Don't copy the result back if it is too large + * @param in a pointer to the buffer + * @param in_len the length in bytes + * @param out a pointer to a buffer of at least size in_len + * @param out_len a pointer to the compressed length of in + */ + void do_nrv2b_compress(uint8_t *in, int in_len, uint8_t *out, int *out_len) { unsigned long new_out_len = in_len + (in_len/8) + 256; - out = malloc(new_out_len); - ucl_nrv2b_99_compress(in, in_len, out, &new_out_len, 0 ); + uint8_t *new_out = malloc(new_out_len); + if (new_out == NULL) { + printf("Not enough memory to allocate buffer.\n"); + exit(1); + } + ucl_nrv2b_99_compress(in, in_len, new_out, &new_out_len, 0 ); *out_len = (int) new_out_len; + if (*out_len < in_len) + memcpy(out, new_out, *out_len); + free(new_out); } #endif

1 0

Re: [coreboot] Time for a new project
by joe＠settoplinux.org 13 Apr '08

13 Apr '08

> I believe that the primary market for coreboot is x86, and will be for > a very long time (possibly for ever). I, on the other hand, believe the embedded market is a lot bigger. Pretty much every embedded board uses its own coreboot equivalent -- well, not equivalent, we really want coreboot to not be riddled with bugs, and it to be flexible and user-friendly, and packed with features and all that goodness. > You are welome to prove me wrong, Don't worry, I will. Ooh, a challenge! :-) Hello, We can't just lump the "embedded market" into non x86 arch's. There are pletty of x86 embedded machines out there. I know this first hand :-) **On a personal note** By the way everyone, I decided to scrap the home email/web server. I've been using it for years, but it was just not working out anymore (it seems to be getting more traffic these days, not to mention the email problems). So now I am out sourcing. My new domain is www.settoplinux.org , come and check it out if you have a free minute. And you may have noticed my new email is joe(a)settoplinux.org. I will update any links on the coreboot wiki as soon as I get a chance. Thanks - Joe

1 0

[PATCH] libpayload: isxdigit boundary
by Ulf Jordan 12 Apr '08

12 Apr '08

Attached patch fixes the upper boundary in isxdigit. /ulf

2 1

r3238 - trunk/payloads/libpayload/libc
by svn＠coreboot.org 12 Apr '08

12 Apr '08

Author: uwe Date: 2008-04-12 22:09:46 +0200 (Sat, 12 Apr 2008) New Revision: 3238 Modified: trunk/payloads/libpayload/libc/ctype.c Log: Correct upper boundary for isxdigit. Signed-off-by: Ulf Jordan <jordan(a)chalmers.se> Acked-by: Uwe Hermann <uwe(a)hermann-uwe.de> Modified: trunk/payloads/libpayload/libc/ctype.c =================================================================== --- trunk/payloads/libpayload/libc/ctype.c 2008-04-11 20:16:24 UTC (rev 3237) +++ trunk/payloads/libpayload/libc/ctype.c 2008-04-12 20:09:46 UTC (rev 3238) @@ -91,7 +91,7 @@ int isxdigit(int c) { - return isdigit(c) || (tolower(c) >= 'a' && tolower(c) <= 'z'); + return isdigit(c) || (tolower(c) >= 'a' && tolower(c) <= 'f'); } int tolower(int c)

1 0

← Newer
1
...
24
25
26
27
28
29
30
...
41
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 April 2008