Re: [coreboot] [patch] ck804 mmconf

"Jonathan A. Kollasch" writes: > Optionally treat ck804 memory-mapped PCI configuration space window as a > resource. Not enabled by default because the resource should be > non-posted and there's no way to express that to the resource allocator. > > Signed-off-by: Jonathan Kollasch Can you ex

Re: [coreboot] [PATCH] Add option 'compress ramstage'

Stefan Reinauer writes: > * Eric W. Biederman [110502 22:00]: >> Sven Schnelle writes: >> >> > Add an option to make compression of ramstage configurable. Right now >> > it is always compressed. On my Thinkpad, the complete boot to grub takes >> > 4s,

Re: [coreboot] [PATCH] Add option 'compress ramstage'

Sven Schnelle writes: > Add an option to make compression of ramstage configurable. Right now > it is always compressed. On my Thinkpad, the complete boot to grub takes > 4s, with around 1s required for decompressing ramstage. This is probably > caused by the fact the decompression does a lot of

Re: [coreboot] .cb files

Peter Stuge writes: > Of course not, that would be redundant. As Kerry pointed out, they > are very much part of the build process. You can also see this very > clearly when watching the make output. > > >> #device pci 1e.2 off end # AC'97 Audio >> It means that AC'97 Audio is on Bus#=1 and Funct

Re: [coreboot] [PATCH] Convert all Intel 440BX boards to Cache-as-RAM (CAR)

Idwer Vollering writes: > 2010/10/7 Stefan Reinauer > > On 10/6/10 2:27 PM, Idwer Vollering wrote: > > 2010/10/6 Uwe Hermann > > See patch. > > > Here is a fix for building on 32-bit platforms: > > Index: src/northbridge/intel/i440bx/raminit.c > =

Re: [coreboot] [PATCH] mkelfImage: set kernel_alignment so 2.6.31+work

Peter Stuge writes: > Eric W. Biederman wrote: >> >> At the moment I want to mandate a bzImage for x86, but I'm not >> >> certain if that is practical the way we build images for coreboot. > .. >> I think I need to ensure that linux builds a bImage. So t

Re: [coreboot] Ed Swierk mail address

Myles Watson writes: > On Mon, Aug 16, 2010 at 10:27 AM, Carl-Daniel Hailfinger > wrote: >> Hi, >> >> does anyone have a non-bouncing email address for Ed Swierk? >> Direct replies welcome. > > As of July 14th, the address here worked: > http://www.coreboot.org/pipermail/coreboot/2010-July/05927

Re: [coreboot] ROMCC help

Cristi Magherusan writes: > Hi, > > I have the following piece of code, and it seems ROMCC can't handle it > (offcourse, gcc works): > > struct bla{ > struct bla* next_bla; > }; > int main(void){return 0;} > > This is the error message I get while trying to compile

Re: [coreboot] romcc.c

ali hagigat writes: > What util/romcc/romcc.c does? > It is over 25000 lines of code! It is a C compiler. At 25000 lines of code it pretty small for a C compiler ;) Eric -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] 3 questions about coreboot

ali hagigat writes: > Ok, thank you all for the replies, links and diagrams. But there are > still some ambiguities in memory read/write after reset which is done > by BIOS chip and then the memory controller !! > > Immediately after reset all memory read/write cycles are claimed by > BIOS chip u

Re: [coreboot] Strange ROMCC failure with Rev 5623

Myles Watson writes: > On Wed, Jun 16, 2010 at 4:34 PM, Myles Watson wrote: >> On Wed, Jun 16, 2010 at 12:06 PM, Myles Watson wrote: >>> On Wed, Jun 16, 2010 at 12:00 PM, Myles Watson wrote: When compiling asus/p2b (and several others), Rev 5622 succeeds, but 5623 fails. m

Re: [coreboot] rommcc bugs

Myles Watson writes: > On Tue, Jun 15, 2010 at 4:27 PM, Rudolf Marek wrote: >> Hi all, >> >> While working on netconsole for ROMCC I noticed following: >> >> int main(void) >> { >>        /* volatile */ >>        union { >>                unsigned char  byte[2]; >>                unsigned short

Re: [coreboot] [PATCH] mkelfImage: set kernel_alignment so 2.6.31+work

ron minnich writes: > On Fri, May 21, 2010 at 1:22 PM, Eric W. Biederman > wrote: >> "Myles Watson" writes: > >> At the moment I want to mandate a bzImage for x86, but I'm not certain >> if that is practical the way we build images for coreboot.

Re: [coreboot] [PATCH] mkelfImage: set kernel_alignment so 2.6.31+work

"Myles Watson" writes: >> >> 20M is indeed to small. >> > My understanding is that 20M is a location, not a size. >> >> Yes. >> >> >> The ramdisk (incl. kernel modules) is on the >> >> order of 26M; I've tried setting it to 32M - this setting is what >> allows >> >> the kernel to actually star

Re: [coreboot] [PATCH] mkelfImage: set kernel_alignment so 2.6.31+work

"Myles Watson" writes: >> > ramdisk-base is just where in ram to load the ramdisk. mkelfImage >> defaults >> > to 8M. You are setting it to 20M. With the change to kernels to >> default >> > them to running at 16M that only leaves 4M for the kernel which I expect >> is >> > to little. Because

Re: [coreboot] [PATCH] mkelfImage: set kernel_alignment so 2.6.31+ work

Troy Telford writes: > On Thursday, May 20, 2010 03:32:36 pm you wrote: >> >> Ugh. >> >> I can think of two things that might be useful. >> >> 1) Add a print statement into mkelfImage that prints the value of >>kernel_alignment Most of the fields are already printed so this >>just requ

Re: [coreboot] [PATCH] mkelfImage: set kernel_alignment so 2.6.31+ work

Troy Telford writes: > On Thursday, May 20, 2010 12:56:48 pm Eric W. Biederman wrote: >> Troy Telford writes: >> > On Wednesday, May 19, 2010 05:42:36 am Eric W. Biederman wrote: >> >> The kernel initialization code as of boot protocol 2.10 is now reading >>

Re: [coreboot] [PATCH] mkelfImage: set kernel_alignment so 2.6.31+ work

Troy Telford writes: > On Wednesday, May 19, 2010 05:42:36 am Eric W. Biederman wrote: >> The kernel initialization code as of boot protocol 2.10 is now reading the >> kernel_alignment field. With the field left the kernel attempts to align >> things to 4GB which is unlike

[coreboot] [PATCH] mkelfImage: set kernel_alignment so 2.6.31+ work

boot. Signed-off-by: "Eric W. Biederman" Index: mkelfImage-2.7/linux-i386/convert_params.c === --- mkelfImage-2.7.orig/linux-i386/convert_params.c +++ mkelfImage-2.7/linux-i386/convert_params.c @@ -178,7 +178,10 @@ struct

Re: [coreboot] Ouch: romcc "x[0] |= something" patch causes another crash

Stefan Reinauer writes: > Seems to do the job... Please send a Signed-off-by: for the books: > http://www.coreboot.org/Development_Guidelines#Sign-off_Procedure Signed-off-by: "Eric W. Biederman" > and this will make it into the tree. > > You can of course check it in

Re: [coreboot] Ouch: romcc "x[0] |= something" patch causes another crash

Stefan Reinauer writes: > On 3/15/10 10:59 AM, Patrick Georgi wrote: > > Am 15.03.2010 03:32, schrieb Keith Hui: > > > > Hi all, > > > > I regret to report that the romcc patch circulated earlier to fix > the > > segfault I reported, is now causing another seg

Re: [coreboot] Ouch: romcc "x[0] |= something" patch causes another crash

Patrick Georgi writes: > Am 15.03.2010 20:48, schrieb Stefan Reinauer: >> The changes were merely trying to fix the segfaults, not implement or >> change anything big. I think we do want fixes for segfaults. Always. > To be fair, the original issue wasn't a segfault, but an internal > compiler er

Re: [coreboot] Ouch: romcc "x[0] |= something" patch causes another crash

Stefan Reinauer writes: > On 3/15/10 8:28 PM, ron minnich wrote: >> On Mon, Mar 15, 2010 at 10:27 AM, Eric W. Biederman >> wrote: >> >> >>> My practical concern is that there is no support for the general case where >>> you do: >>> char

Re: [coreboot] Ouch: romcc "x[0] |= something" patch causes another crash

Stefan Reinauer writes: > On 3/15/10 10:59 AM, Patrick Georgi wrote: > > Am 15.03.2010 03:32, schrieb Keith Hui: > > > > Hi all, > > > > I regret to report that the romcc patch circulated earlier to fix > the > > segfault I reported, is now causing another seg

Re: [coreboot] Ouch: romcc "x[0] |= something" patch causes another crash

Stefan Reinauer writes: > On 3/15/10 10:59 AM, Patrick Georgi wrote: > > Am 15.03.2010 03:32, schrieb Keith Hui: > > > > Hi all, > > > > I regret to report that the romcc patch circulated earlier to fix > the > > segfault I reported, is now causing another seg

Re: [coreboot] unstable AMD Fam10h boot

ron minnich writes: > The way I see it the memory setup and SMP support in CAR are two very > different issues. > > BSP can do its own memory. Once that memory is set up the APs can use > it. Thus, the APs can have working memory when they do their RAM > setup. In other words, > BSP does RAM setu

Re: [coreboot] [PATCH]More consistent behaviour for printk_*

Stefan Reinauer writes: > On 27.04.2009 20:16 Uhr, Myles Watson wrote: > > > section, but then a lot of strings that never surface would be > compiled in > (and I doubt the compiler is clever enough to figure that out) > > > We discussed this recently for v3. Do you have a g

Re: [coreboot] CoreBoot and Payloads

ron minnich writes: > On Tue, Feb 3, 2009 at 7:55 AM, Peter Stuge wrote: >> Piotr Brostovski wrote: >>> I'm asking myself if it is possible that mkelfImage simply isn't >>> compatible with current gPXE releases? >> >> mkelfImage is strictly for Linux. >> >> Upstream gPXE can not be built for cor

Re: [coreboot] MTRR setup strategy

Carl-Daniel Hailfinger writes: > I looked at all changes since r2006 in src/cpu/x86/mtrr/ and > src/cpu/amd/mtrr/ > r3014 introduced CONFIG_VAR_MTRR_HOLE which needs to be enabled to use > subtractive MTRR code for x86. Before that revision, that code was > always enabled. > > However, I get the

Re: [coreboot] MTRR setup strategy

Corey Osgood writes: > ??? > I'm not seeing any code in v2 capable of calculating subtractive mtrrs, is it > possibly in v1? Am I missing something? I'm only looking in mtrr.c. I haven't looked recently so it may be that someone took it for some bizarre reason. But the code was there and it wo

Re: [coreboot] MTRR setup strategy

Carl-Daniel Hailfinger writes: > Assuming you don't have anything you want to cache near 4 GB (like flash): > Both strategies are equally efficient if the contiguous cacheable area > has a size of 2^n+2^(n-1). > The additive strategy is more efficient if the size is 2^n+2^(n-k) and k>1. > The sub

Re: [coreboot] [PATCH] v1: Add license headers to AMD AMD-768 code

Uwe Hermann writes: > Yay, my first v1 patch :) > > Eric, any other code chunks which were mostly/entirely written by you > where we can slap a GPLv2 header on? AMD-766, others? > > Btw, was this code from 2003 (C) Eric W. Biederman or rather (C) LNXI? Always a fuzzy line tha

Re: [coreboot] [PATCH] flashrom: add SST49LF020 support

Uwe Hermann writes: > On Wed, Jan 07, 2009 at 01:55:26PM +0100, Sven Schnelle wrote: >> Hi Uwe, >> >> Uwe Hermann writes: >> >> > Btw, can we mark all the new stuff from your patches as supported in >> > the wiki, i.e. is all of it tested on hardware? >> >> Yes, they are tested on hardware -

Re: [coreboot] [PATCH] v2: Enable -O2 / -mcpu=p2 for all 440BX romcc boards

Carl-Daniel Hailfinger <[EMAIL PROTECTED]> writes: > Hi Eric, > > are there any reasons (bugs) to avoid using -O2 for ROMCC? > > On 10.12.2008 11:19, Uwe Hermann wrote: >> See patch. >> >> Build-tested and tested on hardware using an ASUS P2B-F, I didn't notice >> any problems. However, if there a

Re: [coreboot] unrv2b delay (v2)

Carl-Daniel Hailfinger <[EMAIL PROTECTED]> writes: > On 30.10.2008 23:33, Marc Jones wrote: >> Stefan Reinauer wrote: >>> On 30.10.2008, at 15:03, Marc Jones <[EMAIL PROTECTED]> wrote: > I think that this is in all K8 and fam10 disable_car code. The copy to memory is probably good. R

Re: [coreboot] [PATCH] workaround v2 VIA ROMCC breakage

Carl-Daniel Hailfinger <[EMAIL PROTECTED]> writes: > On 17.10.2008 02:50, Eric W. Biederman wrote: >> Carl-Daniel Hailfinger <[EMAIL PROTECTED]> writes: >> >> >>> I added a special case for ROMCC in the 0x...ULL constants in vt8237r.h. >>> Pl

Re: [coreboot] [PATCH] workaround v2 VIA ROMCC breakage

Carl-Daniel Hailfinger <[EMAIL PROTECTED]> writes: > I added a special case for ROMCC in the 0x...ULL constants in vt8237r.h. > Please see r3664. > The remaining segfault is being investigated by Eric. It is reproducible, and it happens as the intermediate expression is being translated into inte

Re: [coreboot] [PATCH] workaround v2 VIA ROMCC breakage

Carl-Daniel Hailfinger <[EMAIL PROTECTED]> writes: > On 17.10.2008 01:14, Eric W. Biederman wrote: >> Carl-Daniel Hailfinger <[EMAIL PROTECTED]> writes: >> >> >>> Hi Eric, >>> >>> I'm copying you on this mail because we managed

Re: [coreboot] [PATCH] workaround v2 VIA ROMCC breakage

Carl-Daniel Hailfinger <[EMAIL PROTECTED]> writes: > Hi Eric, > > I'm copying you on this mail because we managed to have ROMCC segfault > reliably and choke on another piece of code. > > > On 16.10.2008 18:36, Rudolf Marek wrote: >> >>> +#if 0 >>> /* Set SPI clock to 33MHz. */ >>> spire

Re: [coreboot] [PATCH] workaround v2 VIA ROMCC breakage

Carl-Daniel Hailfinger <[EMAIL PROTECTED]> writes: > Hi Eric, > > I'm copying you on this mail because we managed to have ROMCC segfault > reliably and choke on another piece of code. Thanks. > On 16.10.2008 18:36, Rudolf Marek wrote: >> >>> +#if 0 >>> /* Set SPI clock to 33MHz. */ >>>

Re: [coreboot] v2: is this a bug ? (in device_util.c)

Stefan Reinauer <[EMAIL PROTECTED]> writes: > [EMAIL PROTECTED] wrote: >> >> Hardwaremain()-> dev_configure();-> void >> root_dev_read_resources(device_t root) -> >> >> void compact_resources(device_t dev)-> >> >> memmove(resource, resource + 1, dev->resources - i); >> >> The third parameter shou

Re: [coreboot] SMM handling and resident coreboot

"ron minnich" <[EMAIL PROTECTED]> writes: > There is lots of virtual hardware in our PCs nowadays, and the OSes > depend on it. My early hope was that we would free Linux from this > model. But Linux now depends on the "Steenkin' BIOS" more than it ever > did -- you can't boot a K8 in Linux withou

Re: [coreboot] VIA picks up the pace

Carl-Daniel Hailfinger <[EMAIL PROTECTED]> writes: > Hi, > > I just read that VIA has hired Harald Welte of gpl-violations.org. The > results will probably be pretty interesting and hopefully beneficial for us. > http://lwn.net/Articles/291517/?format=printable I talked to him earlier this week a

Re: [coreboot] SeaBIOS debug output

Carl-Daniel Hailfinger <[EMAIL PROTECTED]> writes: > On 20.07.2008 22:57, ron minnich wrote: >> On Wed, Jul 16, 2008 at 6:47 PM, Kevin O'Connor <[EMAIL PROTECTED]> wrote: >> >>> Hi Myles, >>> >>> On Wed, Jul 16, 2008 at 07:29:29PM -0600, Myles Watson wrote: >>> > Finding the option rom

Re: [coreboot] Trac reminder: list of new ticket(s)

Carl-Daniel Hailfinger <[EMAIL PROTECTED]> writes: > On 16.07.2008 20:12, Eric W. Biederman wrote: >> Segher Boessenkool <[EMAIL PROTECTED]> writes: >> >> >>>> I just figure the default should be the current behavior. >>>&

Re: [coreboot] Trac reminder: list of new ticket(s)

Carl-Daniel Hailfinger <[EMAIL PROTECTED]> writes: >> -- Every chip is programmed differently, so we need a driver for every >>chip, even if coreboot doesn't care about any other chip specifics; > > Hm. I don't understand that. Why can't a generic PCI device handle the > setting of the subsyst

Re: [coreboot] Trac reminder: list of new ticket(s)

Segher Boessenkool <[EMAIL PROTECTED]> writes: >>> In any case, I hope we can all agree that certainly nothing in the PCI >>> spec requires all devices on a mainboard to have the same subsystem >>> (vendor) ID (some might not even have that register implmented!) >> >> Yes it is an optional field.

Re: [coreboot] Trac reminder: list of new ticket(s)

Segher Boessenkool <[EMAIL PROTECTED]> writes: In practice the subsystem vendor IDs are quite arbitrary and definitely not the same for all PCI devices per mainboard >>> >>> They aren't even allowed to be the same for all devices on a mainboard: >>> the subsystem IDs should uniquely iden

Re: [coreboot] Trac reminder: list of new ticket(s)

Stefan Reinauer <[EMAIL PROTECTED]> writes: > Segher Boessenkool wrote: >>> In practice the subsystem vendor IDs are quite arbitrary and definitely not >>> the same for all PCI devices per mainboard >> >> They aren't even allowed to be the same for all devices on a mainboard: >> the subsystem IDs

Re: [coreboot] Trac reminder: list of new ticket(s)

Segher Boessenkool <[EMAIL PROTECTED]> writes: >> In practice the subsystem vendor IDs are quite arbitrary and definitely not >> the same for all PCI devices per mainboard > > They aren't even allowed to be the same for all devices on a mainboard: > the subsystem IDs should uniquely identify the d

Re: [coreboot] Trac reminder: list of new ticket(s)

Stefan Reinauer <[EMAIL PROTECTED]> writes: > Eric W. Biederman wrote: >> coreboot tracker <[EMAIL PROTECTED]> writes: >> >> >>> #110 Allow for per-device subsystem IDs >> >> What is the proper procedure for saying per-device subsystem

Re: [coreboot] Trac reminder: list of new ticket(s)

coreboot tracker <[EMAIL PROTECTED]> writes: > #110 Allow for per-device subsystem IDs What is the proper procedure for saying per-device subsystem IDs is a dumb idea. The subsystem IDs roughly identify the PCB a component sits on. So unless you have multiple pluggable boards in a system th

Re: [coreboot] C Programming

> thank you, i think there is something wrong with the gcc or > strcasestr, but it doesn't matter, i can manually convert it by > (char*)((long)strcasestr(a,b)) I doubt it. I expect rather you need to do what the manpage for strcasestr recommends and do: #define _GNU_SOURCE #inclu