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 _______________________________________________ l4-hackers mailing list l4-hackers@os.inf.tu-dresden.de http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers