> Yes, that's the point of uCLinux, to support machines
> that have a flat address space.
>> I had to deal with this kind of problems in vxWorks days, it was
>> a nightmare.
>
>Me too, man.
I don't think the problem is the shape of the address space, it's
the read/write protection and a user/system mode bit.
I've written a lot of code that ran without memory protection
and we didn't have any serious problems. The trick is to use
a compiler with (very) strong type checking and that excludes
pointer arithmetic. That catches almost all the memory smashing
type bugs at compile time. Much easier to find/fix them that way.
I remember my early days with type checking. I was writing code
without really understanding what was going on. One night the
compiler slapped my wrist because I had forgotten a layer of
indirection and I (finally) figured out what was going on.
"Thank you, thank you, thank you" oh compiler. That would
have been a real pain to debug.
--
The suespammers.org mail server is located in California. So are all my
other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited
commercial e-mail to my suespammers.org address or any of my other addresses.
These are my opinions, not necessarily my employer's. I hate spam.
Reply by John Williams●January 17, 20062006-01-17
Kees,
Kees Bakker wrote:
> John Williams wrote:
>
>
>>tony.p.lee@gmail.com wrote:
>>
>>> Is it true that uCLinux does not have protected kernel memory?
>>>A simple programming loop index comparision error can wipe out the
>>>system memory including kernel.
>>
>>Yes, that's true. The "uC" in uClinux implies no MMU, so no memory
>>mapping or protection.
>
> That's not true for uClinux in general. If your target has MMU uClinux
> can/will use it.
> Take a look at the uClinux source tree and you'll find all kinds of
> targets with or without MMU.
I'm afraid that's not correct. The uClinux source tree has all those
arches in it because it is a direct import of the most recent 2.4 kernel
(current 2.4.31).
The only real difference between a vanilla linux kernel tree, and a
uclinux kernel tree is the directory linux-2.4.x/mmnommu. For uClinux
builds (when NOMMU is defined), this subdir is built, rather than
linux-2.4.x/mm. Simple as that, the rest is essentially arch-specific
details.
uClinux only giveth - it taketh not away from the regular kernel :)
For 2.6, uClinux no-MMU support is in the mainline kernel -
linux-2.6.x/mm/nommu.c
It is possible to run uClinux on MMU hardware, such as i386 and ARM -
the MMU is just not enabled, and everything runs in a flat address space.
The ARM noMMU maintainer has done some interesting work comparing
uClinux vs regular Linux on an MMU-enabled ARM CPU - he found that
context switch time was an order of magnitude better using uClinux than
regular Linux:
http://opensrc.sec.samsung.com/document/uc-linux-04_sait.pdf
Anyway this is all going way OT for c.a.fpga
Regards,
John
Reply by Anonymous●January 17, 20062006-01-17
Just to be clear: The PPC in Virtex-4 DOES have the MMU, right?
"Larry Doolittle" <ldoolitt@localhost.localdomain> wrote in message
news:slrndso1rb.d3k.ldoolitt@localhost.localdomain...
> On 2006-01-16, tony.p.lee@gmail.com <tony.p.lee@gmail.com> wrote:
> > John,
> >
> > Is it true that uCLinux does not have protected kernel memory?
> > A simple programming loop index comparision error can wipe out the
> > system memory including kernel.
>
> Yes, that's the point of uCLinux, to support machines
> that have a flat address space.
>
> > I had to deal with this kind of problems in vxWorks days, it was
> > a nightmare.
>
> Me too, man.
>
> > I am using PPC with Linux and it has been a joy to use. There
> > were one bugs shows up in test group that crash one program - first
> > crash in 6 months. It is solved in 5 mintues after looking a the
> > core dump.
>
> So choose a processor supported by (non-uC) Linux.
> There are a dozen architectures to choose from.
> Leon Sparc can target an FPGA, I'm pretty sure it
> has virtual memory. Presumably slower and bigger
> than microBlaze for FPGA work, but it should be more
> reliable from your perspective.
>
> - Larry
Reply by Kees Bakker●January 17, 20062006-01-17
John Williams wrote:
> Hi Tony,
>
> tony.p.lee@gmail.com wrote:
>
>> Is it true that uCLinux does not have protected kernel memory?
>> A simple programming loop index comparision error can wipe out the
>> system memory including kernel.
>
> Yes, that's true. The "uC" in uClinux implies no MMU, so no memory
> mapping or protection.
That's not true for uClinux in general. If your target has MMU uClinux
can/will use it.
Take a look at the uClinux source tree and you'll find all kinds of
targets with or without MMU.
Reply by tony...@gmail.com●January 17, 20062006-01-17
Sounds good.
Thanks a lot for the info, John.
-Tony
Reply by John Williams●January 16, 20062006-01-16
Hi Tony,
tony.p.lee@gmail.com wrote:
> Is it true that uCLinux does not have protected kernel memory?
> A simple programming loop index comparision error can wipe out the
> system memory including kernel.
Yes, that's true. The "uC" in uClinux implies no MMU, so no memory
mapping or protection.
> If this is the case, have you seen this kind of problem with
> uCLinux.?
> Do you think this is a real issues for uCLinux + microbraze
> environment?
It is no more of an issue for uClinux + MicroBlaze than for any of the
other uClinux targets out there. You could argue that the millions of
deployed uClinux devices out there say it's not a major issue.
More helpfully, however, because it's all Linux, you can debug your app
code on a desktop machine, where coredumps etc will be able to help find
these kinds of errors. You might need stub device drivers for embedded
peripherals, but this is not a major task.
Bugs in kernel drivers are always going to hurt. Even with MMU a driver
bug can bring down the kernel.
> I had to deal with this kind of problems in vxWorks days, it was
> a nightmare. A few bugs that is trivial (gdb the core dump) for the
> protected kernel environment took a team of sw engineers 2 months
> to reproduce and solved.
The use of a desktop linux environment as a prototyping / development /
simulation environment can really help here.
> I am using PPC with Linux and it has been a joy to use. There
> were one bugs shows up in test group that crash one program - first
> crash in 6 months. It is solved in 5 mintues after looking a the
> core dump.
No doubt. There are many factors to consider when choosing a CPU, and
operating system. If board costs are tight, PPC simply may not be an
option. You can put a MicroBlaze Linux system + app-specific logic in a
Spartan3-400 + DRAM - that can be pretty compelling.
Regards,
John
Reply by Larry Doolittle●January 16, 20062006-01-16
On 2006-01-16, tony.p.lee@gmail.com <tony.p.lee@gmail.com> wrote:
> John,
>
> Is it true that uCLinux does not have protected kernel memory?
> A simple programming loop index comparision error can wipe out the
> system memory including kernel.
Yes, that's the point of uCLinux, to support machines
that have a flat address space.
> I had to deal with this kind of problems in vxWorks days, it was
> a nightmare.
Me too, man.
> I am using PPC with Linux and it has been a joy to use. There
> were one bugs shows up in test group that crash one program - first
> crash in 6 months. It is solved in 5 mintues after looking a the
> core dump.
So choose a processor supported by (non-uC) Linux.
There are a dozen architectures to choose from.
Leon Sparc can target an FPGA, I'm pretty sure it
has virtual memory. Presumably slower and bigger
than microBlaze for FPGA work, but it should be more
reliable from your perspective.
- Larry
Reply by tony...@gmail.com●January 16, 20062006-01-16
John,
Is it true that uCLinux does not have protected kernel memory?
A simple programming loop index comparision error can wipe out the
system memory including kernel.
If this is the case, have you seen this kind of problem with
uCLinux.?
Do you think this is a real issues for uCLinux + microbraze
environment?
I had to deal with this kind of problems in vxWorks days, it was
a nightmare. A few bugs that is trivial (gdb the core dump) for the
protected kernel environment took a team of sw engineers 2 months
to reproduce and solved.
I am using PPC with Linux and it has been a joy to use. There
were one bugs shows up in test group that crash one program - first
crash in 6 months. It is solved in 5 mintues after looking a the
core
dump.
-Tony
Reply by John Williams●January 15, 20062006-01-15
Hi Clark,
Anonymous wrote:
> That's interesting. So if I have an FX12 part, for example, your suggestion
> is that I run uclinux in a soft core and implement my DSP code in the PPC
> core? This is the opposite of what I had expected.
As Antti says, you could invert your expectation and do the Linux on
MicroBlaze, and an ultra-controller type design on the PPC. Or better
still, nothing beats FPGA logic for DSP performance. Why not do your
DSP in hardware, make use of those lovely programmable gates, and do the
control/interface logic in SW on a MicroBlaze. V4-LX parts are (will
be?) cheaper than FX, for equivalent gate counts. The PPC does not come
for free.
> What do I give up for ucLinux versus PPC Linux? Speed? Device driver
> support?
MicroBlaze uClinux is slower than PPC Linux, but as the MicroBlaze bus
and memory architecture evolves, we are catching up.
> Also, what's your suggestion for unit control? I imagined a webserver
interfaced to some type of CGI. Maybe perl scripts or php?
Sure, the default mb-uclinux bulid has a webserver in it, adding CGI
apps is simple. Someone's ported PHP to uClinux before, but it might be
overkill. I haven't tried Perl, but I did port a recent Python
interpreter to mb-uclinux - performance was pretty ordinary. Better off
in C, I think.
Feel free to contact me in "commercial mode" to discuss in more detail -
john.williams@petalogix.com
Regards,
John
Reply by Antti Lukats●January 13, 20062006-01-13
"Anonymous" <someone@microsoft.com> schrieb im Newsbeitrag
news:wuOxf.10419$Kp.2204@southeast.rr.com...
>
> "Antti Lukats" <antti@openchip.org> wrote in message
> news:dq7m71$s50$03$1@news.t-online.com...
>> "Anonymous" <someone@microsoft.com> schrieb im Newsbeitrag
>> news:rRFxf.9618$Kp.656@southeast.rr.com...
>> > This is a commercial project. I was under the impression Xilinx
>> > provides
> a
>> > working Linux build for the V4? I don't expect to be doing much Linux
>> > hacking per se, maybe just a custom device driver to interface to my
>> > DSP
>> > circuit/code.
>> >
>> > "John Williams" <jwilliams@itee.uq.edu.au> wrote in message
>> > news:newscache$6670ti$oeg$1@lbox.itee.uq.edu.au...
>> >> Anonymous wrote:
>> >> > Thanks. But that brings up another question: Is it better to go with
>> > ucLinux
>> >> > or use the PPC version of linux? I suspect the latter if I have the
> FX
>> > part,
>> >> > right?
>> >>
>> >> Being the maintainer of the MicroBlaze uClinux port, and offering
>> >> commercial services for the platform, I'm obviously biased :), however
> I
>> >> think the decision is not as automatic as you suggest.
>> >>
>> >> Unless you are prepared to shell out a reasonable number of dollars to
>> >> MontaVista, developing for uClinux with the free tools is a lot easier
>> >> than PPC. There are some guides out there on DIY Linux for Xilinx
>> >> PPC,
>> >> but they aren't for the faint-hearted.
>> >>
>> >> The board port/bringup procedure for uClinux on MicroBlaze is also a
> lot
>> >> faster than PPC Linux, with the free auto-config tools.
>> >>
>> >> It depends on what you are trying to do, and how much you value your
>> >> time.
>> >>
>> >> Is this a hobbyist, study or commercial project?
>> >>
>> >> Regards,
>> >>
>> >> John
>> >>
>>
>> I stand here with John - the Xilinx PPC linux setup is not for
>> faint-hearted.
>>
>> That is because of Xilinx politics - everybody who is not MontaVista
>> gets just ignored - DENX was doing lots of work towards PPC linux
>> support but as Xilinx did not talk to them so Denx dropped any further
>> work on Xilinx support for PPC linux. Thats too bad.
>>
>> Setting up a new MicroBlaze uCLinux systems is just a piece of cake
>> So if you need some DSP code setup uClinux/Microblaze, connect
>> your DSP functions to FSL links and you are all set
>>
>> --
>> Antti Lukats
>> http://www.xilant.com
>>
>>
>
> That's interesting. So if I have an FX12 part, for example, your
> suggestion
> is that I run uclinux in a soft core and implement my DSP code in the PPC
> core? This is the opposite of what I had expected.
>
> What do I give up for ucLinux versus PPC Linux? Speed? Device driver
> support?
>
> Also, what's your suggestion for unit control? I imagined a webserver
> interfaced to some type of CGI. Maybe perl scripts or php?
>
> Thanks,
> Clark
>
>
Hi Clark,
you dont have to give up PPC, but it is WAY easier to use
uClinux/Microblaze,
as of using PPC for DSP, well I did not suggest that, you did - and that is
defenetly
a good idea, so could end up
MicroBlaze/uClinux for network and management
PPC "ultracontroller" and dedicated DSP for DSP functions
and yes, you can use the Xilinx Webserver demo as control
application for first demo testing later is up to you if you
run uClinux also or not
http://www.eubus.net
the HCU units there use Spartan3 in DIP40 as the network engine
MicroBlaze/uClinux
control of those is over telnet and custom protocols
--
Antti Lukats
http://www.xilant.com