Dear Wolfgang, On 12/15/2012 11:07 AM, Wolfgang Denk wrote: > Dear Valentin, > > In message <[email protected]> you wrote: >> >> We are now starting a new design which targets the p2041 CPU from Freescale >> (QorIQ family) and we want to continue with ELDK for this CPU as well. There >> has >> been earlier last year a prestudy for this new development. During this >> process, >> there was a request from us to add a powerpc-e500v2 target architecture for >> ELDK >> that has now been available since release 5.1 IIRC. Unfortunately, we made a >> mistake for that request, and the correct target architecture for the QorIQ >> family would be powerpc-e500mc. >> >> The straightforward solution would be to add this target architecture again. >> But >> I would like to know, what you think is the best approach in this case ? >> Because >> of course the generic "powerpc" target architecture produces code that works >> perfectly fine on a P2041 CPU as well (I have already tested it on the >> P2041RDB >> dev board). The drawback is that this code does not really takes advantage of >> the e500mc cores present in the p2041 cpu. This could however be corrected by >> adding the "-mcpu=e500mc -mtune=e500mc" (or only one of them) flags in our >> compile flags. > > Could you please be a bit more specific which "advantage of the > e500mc cores" you have in mind that would not be supportedby the > generic-powerpc target of configuration of the ELDK?
I was mostly thinking about all the mechanisms introduced by the PowerISA 2.06 Instruction set. I was thinking that even if the e500mc core is compatible with the PowerISA 2.03, it would be better to produce code with PowerISA 2.06. I have mostly ARM experience and there every new core brings a new ISA that requires a new target architecture to really take advantage of it. Maybe this influenced a lot my expectations with this e500mc core and how to take advantage of it. > >> I'm asking because I do not see a lot of variations of PPC cores in the >> target >> architecture lists and that's maybe because the above approach is preferred. >> The >> advantage of the above approach is that you have less binary ELDKs to manage >> and >> maintain. The drawback is that the ELDK binaries in the minimal rootfs then >> are >> not really optimized four our target architecture (by the way, do you have >> any >> idea of the performance improvement that this would give us ?). > > Do you have any indications that, in this specific case, any such > additional optimizations exist at all? If you look at section "1.6 > Summary of Differences Between Previous e500 Cores", and especially > section "1.6.1 Changes from e500v2 to e500mc" of the "e500mc Core > Reference Manual" [1] then you will notice that from a software > development point of view the major difference between the e500v2 and > the e500mc is the fact that the SPEv2 of the e500v2 has been replaced > by a standard FPU on the e500mc. And this exactly what makes the > difference between generic-powerpc-e500v2 and generic-powerpc. > > I do not see any hints that any other, additional "optimizations" > were possible software-wise, but I may be missing something. If you > have any such additional information, please be so kind to share it > with us. > Even though most of them are managed by the SMP support of the OS (which hopefully takes advantage of them), I was (naively ?) thinking that it would be good (necessary ?) to produce some code that is aware of all the multicore synchronization mechanisms (some sync/messaging instructions) and HW (CoreNet, Unified L2 cache, ...) that are all in the list of differences from the e500mc Core Reference Manual you referred to above. Best Regards Valentin _______________________________________________ eldk mailing list [email protected] http://lists.denx.de/mailman/listinfo/eldk
