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

[Adam Lackorzynski]

Hi,

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

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:
https://www.mips.com/develop/tools/codescape-mips-sdk/download-codescape-mips-sdk-essentials/

> [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,
right?



Adam