Patches (was Re: Problem with L4Linux accessing ethernet clocks)
adam at os.inf.tu-dresden.de
Wed Nov 1 00:38:23 CET 2017
On Mon Oct 30, 2017 at 18:38:40 +0100, Paul Boddie wrote:
> > > 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.
Yes, that's about TLS.
> 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
> about itself.
I just modified the code to have a fixed value and that worked for me as
a quick hack. I don't think the value will ever change for a particular
CPU. But it's still a hack and there's a smarter way definitely.
> > > 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.
Debian is building pie code per default nowadays, I think that's where
it's coming from, and we should handle this.
The MIPS vendor compiler is actually gcc but an older one:
> [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?
There's a hole, and it also looks like the first 256MB is mirrored at
512MB. However, using all the memory is just a matter actually making it
known, I've just tried it and it seems to work. All Ci20's have 1GB,
More information about the l4-hackers