On Sat, Sep 27, 2008 at 3:15 PM, Robert Millan <[EMAIL PROTECTED]> wrote:
> On Sat, Sep 27, 2008 at 04:36:13PM +0200, Carl-Daniel Hailfinger wrote:
>>
>> This patch removes the ability of stage2 to return a specific error
>> code. Please fix that regression. Thanks.
>
> I need some way for stage2 t
On Thu, Sep 25, 2008 at 07:12:46AM -0700, ron minnich wrote:
> On Thu, Sep 25, 2008 at 5:10 AM, Robert Millan <[EMAIL PROTECTED]> wrote:
> > On Wed, Sep 24, 2008 at 12:14:15PM -0700, ron minnich wrote:
> >> yes, it is not being used. ELF parsing is not a default in v3 and will
> >> I hope someday b
On Sat, Sep 27, 2008 at 04:36:13PM +0200, Carl-Daniel Hailfinger wrote:
>
> This patch removes the ability of stage2 to return a specific error
> code. Please fix that regression. Thanks.
I need some way for stage2 to pass information to stage1. Other than this
or a hardcoded address (which is a
Hi,
I noticed that free regions provided by search_global_resources() don't have
the reserved regions substracted from them. This patch introduces a check
to weed them out, splitting when necessary.
--
Robert Millan
The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
On 27.09.2008 12:14, Robert Millan wrote:
> I noticed a problem in the multiboot memory map in v3. Instead of the
> reserved region:
>
> addr=0x0, len=0x500
>
> we get:
>
> addr=0x0, len=0x10
>
> the reason being that the multiboot map is generated too early in
> arch_write_tables(), before a
Hi,
I noticed a problem in the multiboot memory map in v3. Instead of the
reserved region:
addr=0x0, len=0x500
we get:
addr=0x0, len=0x10
the reason being that the multiboot map is generated too early in
arch_write_tables(), before a number of routines that write/reserve
stuff are execut
On Fri, Sep 19, 2008 at 07:11:11PM +0200, Robert Millan wrote:
> On Fri, Sep 19, 2008 at 09:08:47AM -0700, ron minnich wrote:
> > On Fri, Sep 19, 2008 at 6:33 AM, Robert Millan <[EMAIL PROTECTED]> wrote:
> >
> > > Note the stage1/stage2 separation. It would require either:
> > >
> > > - multiboo
On Fri, Sep 19, 2008 at 09:08:47AM -0700, ron minnich wrote:
> On Fri, Sep 19, 2008 at 6:33 AM, Robert Millan <[EMAIL PROTECTED]> wrote:
>
> > Note the stage1/stage2 separation. It would require either:
> >
> > - multiboot.c to be linked in twice, once for stage1 and once for stage2
> >
> > - m
On Fri, Sep 19, 2008 at 6:33 AM, Robert Millan <[EMAIL PROTECTED]> wrote:
> Note the stage1/stage2 separation. It would require either:
>
> - multiboot.c to be linked in twice, once for stage1 and once for stage2
>
> - multiboot.c to be split in two files, one for stage1 and one for stage2
bu
On Thu, Sep 18, 2008 at 11:59:13PM +0200, Carl-Daniel Hailfinger wrote:
> I thought Ron and Stefan asked for unconditional lbtable
They did, and I changed that in my last patch. The rationale being:
- lbtable is useful in some situations (Stefan)
- size is not that important (Ron)
> and co
On 18.09.2008 23:59, Carl-Daniel Hailfinger wrote:
> On 18.09.2008 22:09, Robert Millan wrote:
>
>> --- arch/x86/stage1.c(revision 867)
>> +++ arch/x86/stage1.c(working copy)
>> @@ -139,6 +140,14 @@
>> }
>> #endif /* CONFIG_PAYLOAD_ELF_LOADER */
>>
>> +
>> +int run_address_mu
On Thu, Sep 18, 2008 at 2:59 PM, Carl-Daniel Hailfinger
<[EMAIL PROTECTED]> wrote:
> Thanks. I'm surprised by the unconditional usage of multiboot, though. I
> thought Ron and Stefan asked for unconditional lbtable and conditional
> multiboot. Especially the unconditional inline asm instead of the
On 18.09.2008 22:09, Robert Millan wrote:
> Here's a new patch.
>
> - Leaves native coreboot tables untouched, as requested by Stefan and
> Ron.
>
> - Misc other changes requested by Carl-Daniel.
>
Thanks. I'm surprised by the unconditional usage of multiboot, though. I
thought Ron and
Here's a new patch.
- Leaves native coreboot tables untouched, as requested by Stefan and
Ron.
- Misc other changes requested by Carl-Daniel.
--
Robert Millan
The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
how) you may access your data; but nobody's thr
On Wed, Sep 17, 2008 at 11:46:19AM -0700, ron minnich wrote:
> I would rather leave in support for both,
You mean both enabled unconditionally?
> and have a cmos bit enable
> one or the other.
Runtime selection wouldn't be necessary. The two protocols don't collide
with each other in case both
I would rather leave in support for both, and have a cmos bit enable
one or the other. 4k at this point is not worth saving. The flash
sizes are getting to be very large.
ron
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Hi,
On Wed, Sep 17, 2008 at 05:05:03PM +0200, Stefan Reinauer wrote:
>
> I have a bit of a hick-up with removing the coreboot table, as this
> renders utility like flashrom (in some cases) and nvramtool (in all
> cases) pretty much unusable.
I don't propose removing the coreboot table. In most
Robert Millan wrote:
> On Wed, Sep 17, 2008 at 11:50:07AM +0200, Peter Stuge wrote:
>
>> Robert Millan wrote:
>>
>>> Void-ify a few return types that assume presence of a native
>>> coreboot table (and weren't actually used for anything).
>>>
>>> Signed-off-by: Robert Millan <[EMAIL PROTECT
On Wed, Sep 17, 2008 at 11:50:07AM +0200, Peter Stuge wrote:
> Robert Millan wrote:
> > Void-ify a few return types that assume presence of a native
> > coreboot table (and weren't actually used for anything).
> >
> > Signed-off-by: Robert Millan <[EMAIL PROTECTED]>
>
> Sorry, but I still don't u
Robert Millan wrote:
> Void-ify a few return types that assume presence of a native
> coreboot table (and weren't actually used for anything).
>
> Signed-off-by: Robert Millan <[EMAIL PROTECTED]>
Sorry, but I still don't understand the motivation for this. Tell me
why it's needed and I'll probabl
On Mon, Sep 15, 2008 at 10:54:20PM +0200, Carl-Daniel Hailfinger wrote:
> On 15.09.2008 21:49, Robert Millan wrote:
> > The attached patch adds a build option so that one can choose between
> > native coreboot tables and multiboot information (or both, or neither).
> >
>
> Have you tested it wi
21 matches
Mail list logo
