On 11-08-10 12:01 PM, Scott Wood wrote: > On 08/10/2011 10:39 AM, Paul Gortmaker wrote: >> On Wed, Aug 10, 2011 at 1:21 AM, Baruch Siach <bar...@tkos.co.il> wrote: >>> CONFIG_E500MC breaks e500/e500v2 systems. It defines L1_CACHE_SHIFT to 6, >>> thus >>> breaking clear_pages(), probably others too. >>> >>> This patch adds a new "Processor Type" entry for e500mc, and makes e500 >>> systems >>> depend on PPC_E500_V1_V2. >> >> Isn't the original invalid configuration still possible, i.e. I can >> choose E500_V1_V2 >> and also E500MC at the same time, unless you add something like a >> "depends !E500MC" to your new V1_V2 option? > > They're members of a "choice", not standalone bools -- so they're > mutually exclusive.
OK, I missed that. > >> Alternatively, you could treat it like using i386 kernel on a modern >> core by taking >> the LCD for the L1_CACHE_SHIFT of the configured in platforms. > > For alignment you want to err on the high side, but for invalidation you > want to err on the low side. For dcbz you can't err at all. > > And there are other issues than cache size with combining e500v2 and e500mc. > > Could it be done with sufficient hoop-jumping? Probably. Is it worth > it? No. These chips don't even have compatible userspace, unless you > use soft-float. Yeah, if there are lots of other issues and the value return is low, then I can't argue with that. And yes I did use soft float in the thing I was meddling with. > >> I have booted >> a kernel built for an mpc8548 core on a P4080 CPU, so that does work (with >> only >> minimal dts fiddling). > > The opposite direction does not work, and simply booting doesn't mean > there wouldn't be issues in running that kernel on a p4080 (floating > point? bad cache size information being given to userspace? emulation > of non-cacheable dcbz? performance?). > > What dts fiddling? Just making sure that the 8548 dts had the right address to find the uart on the actual p4080 platform. > >> And it keeps the ability to boot one kernel on several >> platforms open (one of the reasons for the ppc --> powerpc shuffle a couple >> of years ago...) > > It's much better than the arch/ppc way of a separate kernel build for > every board. Beyond a certain point there are diminishing returns on > the effort. Given the extra info you list above, I agree. I just thought it worth a mention since I had happened to boot the 8548 kernel on a p4080 as part of something else I was experimenting with, and it didn't totally catch fire (which somewhat surprised me). P. > > -Scott > _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev