[coreboot] locking...

[Carl-Daniel Hailfinger]

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
dependencies.


> 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.
> eek.
>   

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.

Regards,
Carl-Daniel

-- 
http://www.hailfinger.org/