Segher Boessenkool wrote: >> So what's your proposal then? Placing it within a fake func? >> That asm snippet is the entry point. I took as an example how >> prpmc2800.c deals with that, providing an own version of the (weak) >> _zImage_start. > > Use an assembler source file. You'll get much nicer syntax as well > (none of that \n stuff). >
I found it cleaner to embed the entry point code in the .c file and avoid touching the wrapper script. But I'm fine with that if it is the way to go (and I already finally touched the wrapper to increase the link address...). >>> WIMG=0000, are you sure? Not M=1? >> >> To be honest, I don't recall the details now. >> But it was tested in the very early days, the result was not the >> expected one and, in the end, manual cache coherency management was >> still needed. > > Sure, the memory controllers don't do coherency. I'm slightly worried > about two things: > 1) Will the generic code use M=0 as well? Is it a problem if it doesn't? > 2) Do lwarx. etc. work in M=0? > > And a question: does M=0 actually give better performance (lower bus > utilisation, and maybe saves a few cycles)? > I think that the generic code uses M=0 _except_ for SMP and some platforms (see comment in cputable.h). And yes, the generic code works with these processors :) M=0 should have a lower bus utilization, yes. Also M=0 is a requirement if you use some Gekko/Broadway features like the locked (half-)cache. Thanks, Albert _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
