Forum Discussion

Altera_Forum's avatar
Altera_Forum
Icon for Honored Contributor rankHonored Contributor
17 years ago

Linux with MMU on NEEK

Hi, all. I'm testing Linux MMU version, on my NEEK. http://www.nioswiki.com/linux It works fine and I can use "bash" shell. This is the evident proof that we are using the true 'fo...
Altera_Forum's avatar
Altera_Forum
Icon for Honored Contributor rankHonored Contributor
17 years ago

--- Quote Start ---

Or rather, I have much interest for 'futex' or 'SMP', though we have many problems for atomic codes and cache coherency. But is it possible?Kazu

--- Quote End ---

I'm very interested in threaded applications and thus in Futex and thus in atomic user land code.

I do know that Hippo is working on this for the MMU based Linux.

As NIOS does not have atomic operations, we need support by the OS for user-land atomic operations. Hippo is planing to do this by defining an "atomic area" to hold the appropriate supported atomic functions within the RAM page that is used for the MMU-cache and that is located within the FPGA as a TCM (and thus fast and not cacheable). You may want to take a look at the appropriate thread in the NIOS uClinux mailing list, where Hippo and I discussed that issue.

I do intend to help on that area, but right now I'm too busy with other (no-NIOS) stuff. At least I already did create a testing program that can be used to verify and to do some timing tests with atomic code and the various possible variants of doing a MUTETX / FUTEX.

I'm sure Hippo (and I) will be very happy to have you in the boat to make FUTEX work for NIOS / MMU.

SMP is a quite different beast. Hippo decided (IMHO wisely) do delay this issue and first provide a single CPU FUTEX.

I already did discuss (with Hippo and with an Altera FEA) doing SMP-save user-land atomic operations by introducing a "Hardware-FUTEX" by doing a multi-CPU-atomic "compare and xchange" custom instruction. One problem is that a custom instruction can't access memory through the cache and thus it only can decently handle a limited dedicated internal memory area for the "FUTEX"es and thus it only can be used a means to protect the user-code sequences handling the normal memory based Linux-FUTEXes. This two stage method of course asks for some "interesting" code ;).

Supposedly something like that is needed for SMP-Kernel-code, as well, but I did not take a look into that, yet.

At best, Altera would add some decent atomic support for NIOS (e.g. "load locked / store conditional" as introduced with the modern ARM CPUs). But I doubt that this will happen some day soon. Maybe Hippo has or can get some information on Altera's plans on this.

Maybe we should discuss all this on the (IMHO more appropriate) mailng list. Where I'm sure Hippo and others will jump in.

-Michael