Segher Boessenkool wrote:

quoted

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...).

quoted

quoted

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