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