(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.
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
