> Date: Thu, 7 Apr 2016 18:31:22 +0200 > From: Patrick Wildt <[email protected]> > > On Thu, Apr 07, 2016 at 06:00:25PM +0200, Mark Kettenis wrote: > > > > just be the enumeration mechanism for "mainbus". And I think armv7 > > should be the same. > > That sounds more like implementing the fdtbus functionality, but just > call it mainbus.
Yes. That's how OpenFirmware platforms (macppc, sparc64) adn the existing FDT platform (socppc) work. > Goal was: > > mainbus0 at root > cpu0 at mainbus0 > ampintc0 at fdt0 > imxuart0 at fdt0 You'll almost certainly need the FDT to attach your CPUs as well when you go MP. I looked at an example DTS for the vexpress platform yesterday and it seems to contain essential information to spin up the secondoary CPUs. > So the idea was to replace imx0, exynos0, vexpress0, etc. on ARMv7 with > an fdt0 that does all that what e. g. imx0 used to do, just with FDT > only. > > Attaching controllers from FDT is not just going through the tree and > attaching all nodes that are there. You have to take care of interrupt- > controller hierarchy and clocks. Those need to be attached first. This > adds a bit of complexity and should probably not be duplicated for a new > arch (arm64 for instance). Which is why we thought it would be nice to > have that in sys/dev/ofw/. Yes, there is that complexity. On macppc, interrupt establishment is delayed until the interrupt controller attaches. On sparc64 we look for certain devices up front before traversing the tree. I don't really like the complexity of the macppc solution, so I recommend going the sparc64 way here. Unfortunately I think it will be hard to come up with completely generic code for this. So I have my doubts sys/dev/ofw is the appropriate place for this. But we'll see. > I could though completely replace mainbus.c with the fdtbus, call it > mainbus, implement it for armv7 only, and fall back to the old version > for the legacy platforms armish, zaurus and non-fdt armv7. Is that the > way to go? I think so.
