c-d.hailfinger.devel.2006 at gmx.net
Sat Jun 20 03:15:11 CEST 2009
On 20.06.2009 02:56, ron minnich wrote:
> On Fri, Jun 19, 2009 at 5:46 PM, Carl-Daniel
> Hailfinger<c-d.hailfinger.devel.2006 at gmx.net> wrote:
>>> Other than that, we could unify those versions by just defining an empty
>>> (for now) version of the spinlock functions in raminit stage. Then think
>>> about where we can place our locking for those platforms that need it
>>> this early...?
>> Sounds like a plan.
> it's more than spinlock.
> you must also fix the use of the console_drivers struct. There are
> several things you need to get right to make this work.
v3 uses a hack which does not depend on the device tree at all.
Basically, if you add a console driver to the output list in Kconfig, it
will be called always. I need to dig up my patches to postpone/discard
output before driver init.
coreboot-v3/lib/console.c:console_tx_byte() is the code I'm talking
about. Maybe not the greatest code in the world, but without any RAM
> I am not sure I see the point. You're going to make lots of changes
> and in the end, using cpp magic, have a unified function which acts
> differently depending on how it's compiled.
That's the nature of #if/#ifdef. I'm not advocating advanced cpp
trickery because down that road lies madness and frustration.
> It makes the most sense to me to have a RAM printk and a ROM printk
> which are for different purposes. They already share the most
> important common piece, which is vtxprintf.
> But if you insist on unifying them you need to read the two parallel
> functions carefully and I guess do the #ifdef dance.
I advocate the compile once, use everywhere stance of v3.
>> So we'd get uninitialied data for any pre-RAM spinlock access? The v3
>> global variable mechanism should solve this nicely. At least it was
>> designed for that.
> Again, please look at this code and make sure you know all the
> differences before you tear the wall open :-)
Will do so tomorrow.
More information about the coreboot