Am Samstag, den 03.10.2009, 20:03 +0200 schrieb Peter Stuge: > > Because you either introduce a dependency on ROMCC or you need > > additional assembler code. > > I love Patrick's idea about generating macros from cmos.layout. With > that, the additional assembler code would amount to maybe 15 > instructions. Far from painful to me. The thing is, there's code that isn't that pretty in assembly. K8 HT init comes to mind (necessary for rom mapping), so there is a use case for romcc in that model anyway.
But that isn't all that bad in my opinion: 1. we had much more trouble with gcc than with romcc.. If anything, gcc has to go ;-) 2. We're talking about a tiny piece of code here. The smaller, the better, so that even good, slow, unscalable romcc won't be too much of a burden. 3. We'll be using romcc for various projects anyway (eg. serialICE) - it's far from that, so we can use it where appropriate. We have issues with romcc currently because we use it on a large set of files from many separate parts of the tree (the various bridges etc), and suffer from its constraints. What I don't know is, do we require any chipset setup to _reach_ CMOS? Accessing it will be trivial, no matter if assembly or romcc. Patrick -- coreboot mailing list: [email protected] http://www.coreboot.org/mailman/listinfo/coreboot
