Reply by Hal Murray January 19, 20062006-01-19
> 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