Le 06/11/2011 20:29, Simon Glass a écrit :
It's actually a lot more than cache ops. SOCs have there own clock stuff, pinmux things, power mgmt, timers and the like. While it might be desirable to provide this feature it is a fair bit of work and we need to be careful not to make things more complex.
Agreed.
I would settle for an initial step of getting some sort of unified but simple clock/pinmux support in across all ARM. Anyone interested in that? I mean an API that covers the lot, not an implementation. Also it would be nice to avoid the heavy-weight data structures and strings that Linux has. If we got that far then we could make the interface virtual as Marek has done for caches.
On a general note, if we set our goal is to have in U-Boot what Linux has, U-Boot will end up being... Linux, which I don't think is a good thing unless we consider that U-Boot is redundant.
Besides, I don't think 'virtual' interfaces are necessarily the way to go either, not for the sole sake of it anyway. We might well get there with a driver model, and then we might want to see how things are done in Linux, but certainly not import the Linux model without thinking of what makes sense rather than what would be nice. U-Boot's basic principles are fundamentally different from those of an OS like Linux.
We can start, within the "single-SoC binary" model for now, by simply adding relevant SoC-specific or board-specific mechanisms, and using those already in place.
On this particular patch, I feel it should be more explicit about L1 cache, which is what I think it deals with. We may want to support L2 also through a similar API. And a CONFIG option is a good idea.
Finally, even the CP15/cache/MMU code is duplicated in different arch/arm/cpu subdirs. Can we unify this a bit?
I think our recent discussion opens the way for this unification in that cp15 code should be able to go away from start.S and into the (fewer) cache lib(s).
Regards, Simon
Amicalement,