On Wed, May 19, 2010 at 12:50 AM, David Gibson <[email protected]> wrote: > On Tue, May 18, 2010 at 09:28:38PM -0400, Nicolas Pitre wrote: >> On Wed, 19 May 2010, David Gibson wrote: >> >> > On Tue, May 18, 2010 at 08:24:06AM -0400, Nicolas Pitre wrote: >> > > On Tue, 18 May 2010, David Gibson wrote: >> > > > On Tue, May 18, 2010 at 01:24:43PM +0800, Jeremy Kerr wrote: >> > > > > Nicolas Pitre wrote: >> > [snip] >> > > > The only reason you'd need a subarchitecture number or equivalent is >> > > > if you need to do things differently in the very, very early asm boot >> > > > code. We may need a minimal form of this on PowerPC if we ever >> > > > support multiple MMU families in the same kernel binary. >> > > >> > > Exact. For example, on ARM the machine ID is also used to figure out >> > > the MMU mapping needed to be able to simply be able to debug the very >> > > early assembly boot stage when there isn't even a stack available. While >> > > this info is stored in the machine record, it is actually >> > > subarchitecture specific and already half-digested for easy usage by >> > > that initial MMU setup. I just don't want to imagine what the >> > > equivalent functionality with DT would look like. >> > >> > Well, it wouldn't be *that* bad - you'd need a minimal asm-only tree >> > walker to find and look up the compatible property. Quite possible >> > but, yes, fairly awkward. >> > >> > Yeah, if you have to make really early MMU decisions based on >> > subarchitecture it probbaly makes sense to have a simple ID for >> > those. So one thing to consider here is that we've contemplated >> > adding an "MMU family" ID to the device tree blob header for this >> > purpose on PowerPC. If we did such a thing, it could also be used on >> > ARM for a similar purpose. Then all the relevant machine information >> > is in one block, and it's just a simple fixed dereference to extract >> > the MMU type from the early asm. >> > >> > I'd have to talk to Ben et al, but I think we'd be happy enough to >> > create a new dtb v18 which included that field, as well as a couple of >> > other small improvements to the header and blob internals. ARM could >> > standardize on that as the minimum acceptable dtb version. >> >> I still don't get it. Why on earth would you insist on replacing the >> already existing ID value that is _already_ passed to the kernel by all >> ARM bootloaders with something evidently far more complex? > > Um.. no. It's not more complex at all. We're talking about this ID > in the dt blob's header, not in the device tree itself. As I said, > it's one dereference to get to the ID, from the DT address which is > being passed in. i.e. *one* more instruction than having it passed in > register. > > There are two advantages, both small, but contrary to your assertion > it's not significantly more complex, so they don't need to be big. > 1) It means the DT blob contains *all* the information you > need about the machine. If you have multi-stage bootloaders, you can > copy that blob and know you've got everything. > 2) It means we could have information with a similar purpose > in the same place for both PowerPC and ARM (and maybe others in > future).
Regardless, I think Nicolas is right. While there is value in common methods between architectures, I don't think this case warrants it when the existing method works fine and changing it is non-backwards-compatible. g. _______________________________________________ devicetree-discuss mailing list [email protected] https://lists.ozlabs.org/listinfo/devicetree-discuss
