On Wed Nov 01, 2017 at 01:03:36 +0100, Paul Boddie wrote:
On Wednesday 1. November 2017 00.38.23 Adam Lackorzynski wrote:
[Cache detail querying]
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.
In a lot of systems, I guess people would use a configuration setting for this kind of thing (U-Boot seems to have a lot of this going on). I'd have to look at the code to see how this instruction got included, though.
It's the MIPS-related cache handling in l4sys.
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-mi ps-sdk-essentials/
I'm guessing that there might have been different defaults and therefore corresponding assumptions that don't hold true for vanilla gcc.
Yes, that might actually be, but Debian/Ubuntu is pretty widespread so it should work too.
[Accessing 1GB]
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?
Yes. My interpretation was also that the first 256MB resides at zero for compatibility with earlier SoCs in the family, and that they "started again" at a higher location (at 512MB, I guess, if you've looked it up!) when their products needed more address space.
Thanks for taking a look at this! I doubt that the CI20 is so high priority now, but who knows what its corporate parents will do after their separation?
The Ci20 has a somewhat special CPU which needs some special treatment. For that reason I was mentioning the Ci40 which is better in this regard.
Adam