[U-Boot] [RFC] ARM ISA/cpu/SoC code organization for cache and other functions

[Albert ARIBAUD]

(re-posting cleaned up and outside any other discussion)

This RFC is for discussing how cache operation functions should be 
managed in the ARM tree.

ARM boards are frequently based on a SoC, itseff based on a processor 
(or cpu), itself based on an (instruction set) architecture, 'isa' for 
short. For instance, board edminiv2 is based on SoC orion5x which has an 
ARM926EJ-S processor/cpu, based on an ARMv5 isa.

Cache operations are normally defined at the isa level and all 
processors, SoCs and boards based on an architecture should use this 
architecture's cache operations.

However, some processors or SoCs may provide specialized instructions or 
instruction sequences for some cache operations, or may have a broken 
implementation for some other cache op.

There is thus a need to be able to redefine some isa-defined cache ops 
with processor-specific ops, and also to redefine some isa- or 
processor-defined ops with SoC-specific ops.

For instance, say some armv5 based cpu badly implements full flush but 
correctly implements cache line flush. The cpu code should then provide 
its own version of the full cache flush op, based on looping through the 
cache lines instead of the armv5 single coprocessor instruction.

If, OTOH, a SoC has broken cache ops to the point that cache is 
unuseable, then it should have its cache disabled, which can be done 
through configuration options or by providing SoC-specific cache ops 
implementations that will emit appropriate messages instead of trying to 
exercize the faulty cache functionality.

The source code implementation for ARM cache ops would be:

- a header file declaring the ops as weak C functions for at least full 
cache flush, full cache invalidate, cache line flush and cache line 
invalidate;

- SoC-specific, cpu-specific, and isa-specific definitions for these 
functions, in the form of C files.

- a default implementation in a lib/ file.

The object files shall be linked in decreasing precedence order, i.e. 
SoC file first, then cpu file, then isa file, then lib last, so that for 
each cache op, the weak symbol mechanism uses the most specific one.

One possible organisation for files would be (switch to fixed size font)

         (isa)   (cpu)     SoC)
arch/arm
         /armv5t/
                 cache-ops.c
                 arm926ejs/
                           cache-ops.c
                           orion5x/
                                   cache-ops.c

Plus of course arch/arm/lib/cache-ops.c.

There was a proposal to put SoC families right below arch/arm, because 
members of such SoC families may have many common devices but different 
cpus. We already deal with the common devices by putting them in their 
correct location in U-Boot, e.g. the Ethernet controller of orion5x is 
in drivers/net/, but we don't deal with SoCs which exist in various CPU 
flavors.

Comments more than welcome.

Amicalement,
-- 
Albert.