On 20.06.2009 02:56, ron minnich wrote:
On Fri, Jun 19, 2009 at 5:46 PM, Carl-Daniel Hailfingerc-d.hailfinger.devel.2006@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