Hi,
Michael Schnell wrote:
Yep, Mico32 is a quite simple soft-core based upon RISC architecture.
For the most part of it it resembles both NiosII and, using a lot of
fantasy, MIPS (it has a lot of registers, compared to ARM). Of course,
it currently lacks MMU support.
My impression is that it could be viable to create a common "arch" for
several similar ip-core processors (namely NIOS II, MicroBlaze and
Micro32), in a way that the sub-archs are different only in some
preprocessor variables. By this, there would be much more impact to the
effort to bring these processors into the main µCLinux tree.
Apart from the M1 (which looks like an ARM :), the vendor-specific RISC
cores all tend to look pretty much the same in terms of orthogonal
register sets and so on.
However, they do differ in the parts that matter down in
arch/XXXX/kernel - exception handling, interrupt handling and so on.
Try to unify these different arches down at that level would be a pretty
tough job. 2.6 is a lot better than 2.4, but there is still a
reasonable amount of code duplication between arches down at the
arch/XXX level - and as Thomas points out, it seems that this is
preferred over big #ifdef cascades.
- no support for atomic operation used in semaphore handling
I suppose the same is true for NIOS.
How is this handled ? Is multiprocessor possible/planned with your port
? I do know that the Altera SDK comes with HDL code for a hardware
semaphore, so that could be usable with multiple processors. It should
be quite easy to create a custom instruction from the semaphore HDL
code, instead of using it as a kind of I/O port, if that seems to be
viable.
The challenge is trying to keep the kernel port as generic as possible -
you must strive to minimise the restroctions and requirements that you
place on the target HW system, yet still be able to support the more
sophisticated features (e.g. HW semaphors) if users want to include them.
In my opinion
ARM has a strong support for multi-processor, multi-platform
configuration and since a soft-core can be potentially used on a wide
variety of appliance, it seems to me that starting from ARM was the
right choice.
While I cant comment on your conclusion, I feel that multiprocessor
support is really critical with a port for the said processors, as it's
easily possible to configure an FPGA to contain lots of CPU cores.
The Blackfin group are doing some interesting things with faked SMP on
the dual-core Blackfin devices. The problem is that none of the
FPGA-based PCU architectures support coherent caches, and this is almost
a showstopper for true SMP. The Blackfin people have done some
interesting work to try and get past that.
Personally I'm more interestings in assymmetric multiprocessor systems -
MicroBlazes in this case, with one CPU running linux, and the other(s)
running dedicated firmware or microkernel code. The tricky (and
interesting) part is mapping these other CPUs into Linux so you can
control them.
Re-implementing SMP on FPGA-based multiCPU systems is, to me, not
necessariyl the right way to go.
Any comments about the way to distribute the patch, since it's still
in a very early stage? Perhaps someone wants to join the journey...
Set up a git tree - commit early and commit often. Expect to do most of
the work yourself, until it's sufficiently complete that other people
want to use it for their own projects. Then, still expect to do most of
the work yourself!
Contact Lattice, ask them for a dev board, and push them for info on
their own efforts re: uClinux. Google Rick Klingler's posts over the
last few months, he's been talking about this for a while, and has been
speculating that they had an internal project to do the port.
John
_______________________________________________
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev
