Patches (was Re: Problem with L4Linux accessing ethernet clocks)
paul at boddie.org.uk
Mon Oct 30 18:38:40 CET 2017
Sorry for the delayed reply! Other things have been getting in the way, and
some mild illness certainly hasn't helped matters.
On Wednesday 25. October 2017 00.42.59 Adam Lackorzynski wrote:
> On Mon Oct 23, 2017 at 01:50:47 +0200, Paul Boddie wrote:
> > I haven't looked at how the floating point emulation is done in the Linux
> > kernel, as another example of this kind of thing, but I imagine that you
> > have
> Linux has FP emulators to support applications with FPU code on
> processors that don't have an FPU. It does the obvious, catching the
> traps and handling them. Whether it's a good idea to do that in a
> microkernel is another thing. Technically it could be done of course but
> building the code with softfloat has always been a good alternative.
I'll most likely take the soft-float route for other SoCs when I get round to
looking at them.
> > to do some assembly language programming here just to recover from the
> > exception. In this case, however, the emulated instruction is very
> > simple, although I did take the liberty of rearranging the emulation
> > mechanism slightly.
> Yes, it is probably simple but that does not necessarily mean it would
> need to be done in asm. Exceptions are caught and handled of course, the
> actual processing can be done in C.
The instruction being emulated is rdhwr with argument $1 (SYNCI_Step). Other
arguments of this instruction were already implemented in
src/kernel/fiasco/src/kern/mips/exception.S, and so it was natural to add
support for this argument there as well. For example, the existing support
covered argument $29 (ULR) which seems to be concerned with accessing
task/thread-local storage, if I interpret "TLS" correctly.
Meanwhile, argument $1 (SYNCI_Step) is concerned with accessing data from a
configuration register that would normally only be accessible in kernel mode,
with the purpose of this instruction variant being to expose the cache details
to user mode. So the only way to actually implement the instruction as
intended would be in kernel mode by doing the necessary read from the CONFIG1
A hack that I did consider was to just replace the instruction with code that
just loads a constant that is set up according to the SoC parameters. A user
space handler could certainly do such work and be invoked by the exception
handler, but the resulting functionality would not exactly be equivalent to
that provided by the patch because it would not dynamically ask the hardware
> > Yes. Various L4Re components do not work when compiled with gcc unless I
> > introduce these changes. It was suggested that I do not compile such
> > things as position-independent code, but I don't remember any further
> > explanation.
> Hmm, does that mean that with Debian's gcc (6? 7?) there might be issues?
Here's my version information:
mipsel-linux-gnu-gcc (Debian 6.3.0-18) 6.3.0 20170516
However, I was told that gcc typically compiles position-independent code as
the default for mipsel. My guess is that any version would be a problem, and I
think it was already noted that development was done with the MIPS vendor
compilers, not gcc, so this is why this issue wasn't noticed before.
> Ok, I see, there's a background. And obviously the available memory can
> make a big difference.
If the entire 1GB appears at a different physical address than zero, which is
my understanding of the situation, is it possible to set some kind of
configuration variable to let Fiasco know about this, while still preserving
the addresses used for things like peripherals in the usual zero-based region?
More information about the l4-hackers