Patches (was Re: Problem with L4Linux accessing ethernet clocks)

[Paul Boddie]

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

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 
about itself.

[...]

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

[Accessing 1GB]

> 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?

Paul