On Wed, 2014-07-02 at 19:59 +0200, Alexander Graf wrote: > On 02.07.14 19:52, Scott Wood wrote: > > On Wed, 2014-07-02 at 19:30 +0200, Alexander Graf wrote: > >> On 02.07.14 19:26, Scott Wood wrote: > >>> On Wed, 2014-07-02 at 19:12 +0200, Alexander Graf wrote: > >>>> On 02.07.14 00:50, Scott Wood wrote: > >>>>> Plus, let's please not hardcode any more addresses that are going to be > >>>>> a problem for giving guests a large amount of RAM (yes, CCSRBAR is also > >>>>> blocking that, but that has a TODO to parameterize). How about > >>>>> 0xf00000000ULL? Unless of course we're emulating an e500v1, which > >>>>> doesn't support 36-bit physical addressing. Parameterization would help > >>>>> there as well. > >>>> I don't think we have to worry about e500v1. I'll change it :). > >>> We theoretically support it elsewhere... Once parameterized, it > >>> shouldn't be hard to base the address for this, CCSRBAR, and similar > >>> things on whether MAS7 is supported. > >> It gets parametrized in the machine file, CPU selection comes after > >> machine selection. So parameterizing it doesn't really solve it. > > Why can't e500plat_init() look at args->cpu_model? Or the > > parameterization could take two sets of addresses, one for a 32-bit > > layout and one for a 36-bit layout. It might make sense to make this a > > user-settable parameter; some OSes might not be able to handle a 36-bit > > layout (or might not be as efficient at handling it) even on e500v2. > > Many of the e500v2 boards can be built for either a 32 or 36 bit address > > layout in U-Boot. > > > >> However, again, I don't think we have to worry about it. > > It's not a huge worry, but it'd be nice to not break it gratuitously. > > If we do break it we should explicitly disallow e500v1 with e500plat. > > I'd prefer if we don't overparameterize - it'll just become a headache > further down.
"We shouldn't overparameterize" is a tautology. The question is what constitutes "over". I don't think this is excessive. Again, it's parameterization that U-Boot already does, even disregarding e500v1, and QEMU plays the role of U-Boot to a certain degree (even in the new mode of actually running U-Boot, the address map is fixed). Perhaps it could be simplified by just saying that, in 36-bit mode, all physical addresses other than RAM have 0xf prepended. This is similar to what U-Boot does. > Today we don't explicitly disallow anything anywhere - you > could theoretically stick a G3 into e500plat. I don't see why we should > start with heavy sanity checks now :). Ugh. It should at least be documented, since unlike a G3, e500v1 isn't an unrealistic expectation on a platform called e500plat. > Plus, the machine works just fine today if you don't pass in -device > eTSEC. It's not like we're moving all devices to the new "platform bus". We have a TODO to move CCSR as well. -Scott
