best evm for virtex-4 and linux

"Anonymous" schrieb im Newsbeitrag news:MM9xf.5246$ snipped-for-privacy@southeast.rr.com...

I may be mistaken but I think there are no Virtex4 linux ready currently shipping with both device and host support drivers for USB

Virtex-4 based modules from

eg LX15, LX25 and FX12 based units are currently all shipping, but the included ucLinux reference design does not include USB drivers, this will be supplied later on, currently only some standalone USB firmware samples are included.

There are possible other boards or modules with partial USB support, but with device and host (OTG) support already included I doubt that you find anything at the moment, you can possible find something with host support only

Antti

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?

os

be

Interesting board! Do you know other "mini" modules?

Many Thanks Marco

"Marco T." schrieb im Newsbeitrag news:dq3nck$v19$ snipped-for-privacy@nnrp.ngi.it...

there are, but not with so complete set of features on board.

• memec mini-modules

• suzaku

• and one v4 module comes in CF card format

• with Altera there one small format thing

on the hydraxc webpage isnt much online, but there are also 2 different evaluation base boards available for easy getting started

the low cost only has the connectors mainly, the high end base board has Virtex4+DDR2 and DVI out and header for camera

Antti

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

ucLinux

part,

will

are

find

support

"Anonymous" schrieb im Newsbeitrag news:rRFxf.9618$ snipped-for-privacy@southeast.rr.com...

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

FX

lot

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

"Anonymous" schrieb im Newsbeitrag news:wuOxf.10419$ snipped-for-privacy@southeast.rr.com...

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

the HCU units there use Spartan3 in DIP40 as the network engine MicroBlaze/uClinux

control of those is over telnet and custom protocols

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.

MicroBlaze uClinux is slower than PPC Linux, but as the MicroBlaze bus and memory architecture evolves, we are catching up.

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 - snipped-for-privacy@petalogix.com

Regards,

John

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

Yes, that's the point of uCLinux, to support machines that have a flat address space.

Me too, man.

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

Yes, that's true. The "uC" in uClinux implies no MMU, so no memory mapping or protection.

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.

The use of a desktop linux environment as a prototyping / development / simulation environment can really help here.

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

Sounds good.

Thanks a lot for the info, John.

-Tony

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:

Anyway this is all going way OT for c.a.fpga

Regards,

John

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.