Linux on Microblaze

I'm interested to hear from anyone who has experience implementing
Linux on Microblaze.  How "smooth" is it?  What are the pitfalls?
Limitations/issues?

I am not talking about uClinux but rather the MMU version/s.

I hear conflicting reports.  Hard processor vendors bash the heck out
of it and tell us that it is an absolute nightmare (gee, I wonder
why?).  Xilinx and the disti are telling us that all will be fine.

Which is it?

-Martin

Hi,

From the experience we have at OpenPattern, the code is good enough
but we are having lots of problems with broken build scripts and
outdated toolchains. We are preparing an OpenWRT-based distribution
that should address those issues. We are using the uClinux version for
now, but we plan developments with the MMU-enabled one as well. Stay
tuned :)

Sebastien

"m" <martin.usenet@gmail.com> wrote in message 
news:3b479dc1-ac2d-41a0-8a44-9e8a51511309@a29g2000pra.googlegroups.com...
> I'm interested to hear from anyone who has experience implementing
> Linux on Microblaze.  How "smooth" is it?  What are the pitfalls?
> Limitations/issues?
>
> I am not talking about uClinux but rather the MMU version/s.
>
> I hear conflicting reports.  Hard processor vendors bash the heck out
> of it and tell us that it is an absolute nightmare (gee, I wonder
> why?).  Xilinx and the disti are telling us that all will be fine.

*ANY* softcore FPGA embedded CPU (Microblaze, Nios-II)  is so slow,
why would you even try to run a full Linux (MMU) kernel on it?

It may be academically interesting, but a far more practical setup
would use a Virtex4/FX (PowerPC-405) or a
Virtex5/FXT (PowerPC-440) 

On Nov 8, 2:21 am, "guestuser1" <guestus...@nowhere.net> wrote:

> *ANY* softcore FPGA embedded CPU (Microblaze, Nios-II)  is so slow,
> why would you even try to run a full Linux (MMU) kernel on it?

I would think that a system with an MMU would quite likely be more
efficient than one without, both in overhead for many operations
(which have to be done a bit oddly / emulated in uClinux without MMU)
and also in memory allocation efficiency.

As for why someone might run linux on an embedded system in general -
quite possibly because features and portability are more important
than raw speed.  Especially with FPGA fabric sitting right next door,
there's an implication that what has to be fast is done in logic,
while the processor and O/S are concerned with the complexities of
talking protocols to other computers, talking to humans, and quite
possibly running a fair amount of legacy code.

Yes, the hybrid powerPC/FPGAs would be an option there too, but as a
more specific part that may imply some undesired lock-in or at least
restriction on choices.   Anybody put a hard core processor in a
spartan/cyclone class part yet?   Wheras those are mainstays for
smaller soft-core systems.

cs_posting@hotmail.com wrote:
> On Nov 8, 2:21 am, "guestuser1" <guestus...@nowhere.net> wrote:
> 
>> *ANY* softcore FPGA embedded CPU (Microblaze, Nios-II)  is so slow,
>> why would you even try to run a full Linux (MMU) kernel on it?
> 
> I would think that a system with an MMU would quite likely be more
> efficient than one without, both in overhead for many operations
> (which have to be done a bit oddly / emulated in uClinux without MMU)
> and also in memory allocation efficiency.
> 

Generally speaking, running *without* an MMU is more efficient - people 
have been known to specifically choose no-MMU on devices such as large 
ARMs that have an MMU, because they want to avoid the overhead it needs. 
  In particular, an MMU will increase the latency for memory accesses 
(how significant this is depends on whether the MMU translation is 
before or after the cache, and on the rest of the memory access path), 
it will increase task switching time (since MMU setup needs to be 
swapped), and it means that all data sharing between processes needs to 
use "proper" channels - without an MMU, processes can cheat and directly 
access each others memory spaces.

For the particular case of memory allocation, however, an MMU will let 
the system use memory more efficiently.  It will also save space (and 
possibly time) if there are sections of code and data that are shared 
between processes but must appear as private.

> As for why someone might run linux on an embedded system in general -
> quite possibly because features and portability are more important
> than raw speed.  Especially with FPGA fabric sitting right next door,
> there's an implication that what has to be fast is done in logic,
> while the processor and O/S are concerned with the complexities of
> talking protocols to other computers, talking to humans, and quite
> possibly running a fair amount of legacy code.
> 
> Yes, the hybrid powerPC/FPGAs would be an option there too, but as a
> more specific part that may imply some undesired lock-in or at least
> restriction on choices.   Anybody put a hard core processor in a
> spartan/cyclone class part yet?   Wheras those are mainstays for
> smaller soft-core systems.

My understanding of Altera's FPGAs is that they have pretty much given 
up on using ARM hard-core processors, because the Nios / Nios II was 
actually faster for real use - the flexibility of memory bus 
arrangements, custom instructions, etc., meant that the space taken by 
the ARM core was simply not worth it.

David Brown wrote:
> 
> My understanding of Altera's FPGAs is that they have pretty much given
> up on using ARM hard-core processors, because the Nios / Nios II was
> actually faster for real use - the flexibility of memory bus
> arrangements, custom instructions, etc., meant that the space taken by
> the ARM core was simply not worth it.

It would still be nice to have more chips with combination
microcontroller and small FPGA at the low end, as that is often a useful
mix as opposed to having to have a much bigger FPGA.  Aiming this at the
high-end CPLD markets (with features such as onboard flash, 5V
tolerance, etc.) would be especially nice.

	-hpa

H. Peter Anvin wrote:
> David Brown wrote:
>> My understanding of Altera's FPGAs is that they have pretty much given
>> up on using ARM hard-core processors, because the Nios / Nios II was
>> actually faster for real use - the flexibility of memory bus
>> arrangements, custom instructions, etc., meant that the space taken by
>> the ARM core was simply not worth it.
> 
> It would still be nice to have more chips with combination
> microcontroller and small FPGA at the low end, as that is often a useful
> mix as opposed to having to have a much bigger FPGA.  Aiming this at the
> high-end CPLD markets (with features such as onboard flash, 5V
> tolerance, etc.) would be especially nice.
> 
> 	-hpa

I'd like to see something like that too.  The only one I can think of is 
Atmel's FPSLIC's, which are an FPGA with an AVR core.  But they don't 
really do the same thing - the AVR core is like an add-on hard-core in a 
small FPGA.  I'd prefer something that had the convenience and easy of 
use of a normal AVR device (or similar small micro), but with some 
programmable logic built-in to off-load the processor for fast I/O or 
calculation acceleration.  A hundred or so CPLD macrocells would be 
enough for many situations.

On Nov 10, 12:55 am, "H. Peter Anvin" <h...@zytor.com> wrote:

> It would still be nice to have more chips with combination
> microcontroller and small FPGA at the low end, as that is often a useful
> mix as opposed to having to have a much bigger FPGA.  Aiming this at the
> high-end CPLD markets (with features such as onboard flash, 5V
> tolerance, etc.) would be especially nice.

My feeling is that when talking about low cost FPGA's, it's not the
logic fabric required to implement a decent microcontroller-class soft
core that's the problem, it's the ram to store the program that is
mostly missing and thus pushes you either into a larger FPGA than
logic demands require, or into using an external memory.

And flash cells would be nice too, but if doing that might as well
include storage for the FPGA bit file too.  Otherwise you can just
append the program code in a serial config flash and load that into
ram to execute from.  Or you could if the ram problem were solved...

"guestuser1" <guestuser1@nowhere.net> writes:
> *ANY* softcore FPGA embedded CPU (Microblaze, Nios-II)  is so slow,
> why would you even try to run a full Linux (MMU) kernel on it?

Sometimes you need the MMU more than you need the performance.  Otherwise
we'd all be running uCLinux on our x86 boxes.

> It may be academically interesting, but a far more practical setup
> would use a Virtex4/FX (PowerPC-405) or a
> Virtex5/FXT (PowerPC-440) 

More practical for what?

For some applications cost is more of a concern than maximum CPU performance.
The Virtex 4 or Virtex 5 are somewhat expensive; for some applications that's
OK and for others it isn't.

cs_posting@hotmail.com wrote:
> On Nov 10, 12:55 am, "H. Peter Anvin" <h...@zytor.com> wrote:
> 
>> It would still be nice to have more chips with combination
>> microcontroller and small FPGA at the low end, as that is often a useful
>> mix as opposed to having to have a much bigger FPGA.  Aiming this at the
>> high-end CPLD markets (with features such as onboard flash, 5V
>> tolerance, etc.) would be especially nice.
> 
> My feeling is that when talking about low cost FPGA's, it's not the
> logic fabric required to implement a decent microcontroller-class soft
> core that's the problem, it's the ram to store the program that is
> mostly missing and thus pushes you either into a larger FPGA than
> logic demands require, or into using an external memory.
> 
> And flash cells would be nice too, but if doing that might as well
> include storage for the FPGA bit file too.  Otherwise you can just
> append the program code in a serial config flash and load that into
> ram to execute from.  Or you could if the ram problem were solved...

Of course you want to have storage for the FPGA bit file.  Additionally,
I think you'd really want single voltage, as is pretty much the norm in
flash microcontrollers.

That's the problem with going to "full" FPGAs like Spartan or Cyclone:
the power supply and storage requires some reasonable degree of
technical sophistication in the design, whereas most CPLDs and flash
microcontrollers can be wired up by a complete board design newbie like
myself and expect it to work.

	-hpa