On Fri, Feb 13, 2009 at 03:45:45AM +0100, Carl-Daniel Hailfinger wrote:
[Adding the coreboot mailing list to CC. It's moderated for non-subscribers, but it won't take long for legitimate mails to be approved.]
On 13.02.2009 03:17, David Gibson wrote:
On Fri, Feb 13, 2009 at 03:11:20AM +0100, Carl-Daniel Hailfinger wrote:
On 13.02.2009 01:43, David Gibson wrote:
On Thu, Feb 12, 2009 at 11:26:46AM +0100, Markus Armbruster wrote:
I didn't mean to say they are a bad idea for FDTs, just that they're on an awkward level of abstraction for QEMU configuration. There, I'd rather express a PCI address as "02:01.0" than as <0x00000220>. Translating text to binary is the machine's job, not the user's.
Ah, I see what you mean. Hrm, there are several possibilities here, we'll have to see which works out best for your purposes.
Using the DTC version included in the coreboot v3 sources would solve that problem and give you a readable PCI address representation.
Hrm.. it would be nice if you'd co-ordinated with Jon and I about this. Then we could have at least the bits which make sense in upstream dtc...
Probably the biggest obstacle for a full merge right now is that the coreboot v3 DTC is rather old and has been extended not only for a more readable DTS syntax variant, but also for additional output modes (C header and C code).
If the C output mode is what I'm guessing, it should be pretty easy to add (we already have an asm output mode upstream).
The syntax changes will be trickier. I want to review any new syntax for dts very carefully, because I really, really don't want to have to break backwards compatibility in future (I'm unhappy enough about the dts-v0 to dts-v1 transition we've already have).
Can you summarise what the syntax changes are? Maybe start a new thread with just devicetree-discuss not the other lists for that.
We (coreboot developers) are interested in reducing our diff with upstream DTC in order to improve maintainability of our DTC code.
Good :)