Hello Chris and Sebastian,
On Wednesday 18 of May 2016 02:23:43 Chris Johns wrote:
> > + /*
> > + * Current U-boot loader seems to start kernel image
> > + * with I and D caches on and MMU enabled.
> > + * If RTEMS application image finds that cache is on
> > + * during startup then disable caches.
>
> Is the cache and MMU configured and enabled at a later stage in the
> initialisation? On my first read of this comment I was left wondering if
> caches can be disabled on these targets.
The direct RPi boot start application image with cache disabled.
RTEMS setups pagetable later during initialization and enables
cache for these ARM targets.
It would worth to run initialization with cache enabled for speedup
reasons but problem that U-boot page table can clash with some
workspace initialization, I have not checked where U-boot
points the MMU yet. U-boot should set cache as write through
so the most of the possible problems should be eliminated.
But even in that case there could be problem with satale
instruction cache because (as I know/expect) ARMv6 I and D
cache are not coherent, so for example generic interrupt
vectors setup would require proper flush operations.
I try to map operations to already available CP15
ones provided by RTEMS and I try to add missing ones.
I would probably left over setup of Monitor Vector Base
Address Register, because that could make problems when
Jailhouse or other hypervisor is used which would probably
kill application attempting to set this register.
As for the open-coded stuff, I have been quite happy
when I have found all sources of troubles and misbehavior
during consultation of ARM manuals. But I agree that
for long term nice names for cryptic cX, cY worth the effort.
It would be helpfull if somebody check code with U-boot
on RPi2. Generally I think that there should not be problem.
But ...
Best wishes,
Pavel
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
