Actually, we buy them formatted. But they can of course be reformatted easily.
But the microZed board comes with a boot loader, in a soldered-down flash chip, and it looks at the SD card to see if there's a ARM program and a FPGA file; and it loads both if they are there. It works with FAT32.
YOU can
There aren't a lot of microZed equivalents. None that I know of. When we picked it, Altera wasn't yet shipping their arm+fpga SOC, much less shipping a board like this. We'd have preferred Altera.
The standard one only boots from a FAT32 formatted SD card.
My launch customer isn't concerned about the 4 GByte file size limit, so there's no incentive to go to another file structure and re-engineer the boot loader.
--
John Larkin Highland Technology, Inc
picosecond timing precision measurement
jlarkin att highlandtechnology dott com
http://www.highlandtechnology.com
Den fredag den 27. februar 2015 kl. 21.09.28 UTC+1 skrev John Larkin:
you don't even need the flash chip, we make our own Zynq board. even with an empty flash chip it'll boot of an SD card
and you only need a few megabytes for the first stage bootloader and uboot of the fat partition, the linux root file system is usually on a different partition and in EXT4 format
OK. I couldn't quite tell which side of the transfer (*from* SD card or
*to* FPGA) you were working on.
Apropos discussion later in the thread, I think FAT32 is the right answer for that SD card, especially if you think the user is going to take it out of your box and plug it into a Windows machine at some point.
If somebody told me I couldn't use FAT32, but I still had to support using it on Windows, my next choice, believe it or not, would be NTFS. This would probably suck for reading the files fast, though... or you'd get the situation where most files would read just fine but one file would randomly involve going off and playing with NTFS for several milliseconds.
If I were outside the US, I might think about exFAT, but in the US, I'd rather not pay the protection money to Microsoft.
The "official" Linux kernel has built on ARM for quite a while now. (In other words, it's part of the source that anybody can get from kernel.org, not from one specific vendor.) There will probably always be some hardware-specific changes to get the kernel to run on a particular CPU. But I suspect most of the Linux kernel is stock, even if it's an older version.
There are even some distributions (Debian is one, probably others) that provide as much of the "full" software stack as they can for ARM. If you have a display, you can run X, Firefox, etc. Probably not interesting for the products you make, but it exists in the world.
This is the part I was originally thinking of. As far as I know, stock Linux doesn't know about FPGAs, so you get to write your own driver for them.
...probably including settling debates about doing something on the ARM side or the FPGA side, and other fun stuff like that.
As a customer (in general), I want as much as I can get in the manual, even if not all of it has to do with getting the thing to run. But I can see someone making the argument that putting all of that in the manual is giving away the secret sauce. I bet the final answer ends up somewhere between "plug it in, green LED comes on" and what you have now.
Sometimes it depends on how smart you think the customer is, and how much you think they will want to push the hardware to do something outside of the original design. Sometimes it depends on who's gonna answer the support phone.
Hell, the one I posted is an order of magnitude faster, has a bigger base memory, newer kernel support, full circuit disclosure... cheaper... I am sure that integrating an fpga with it would be trivial.
End up costing the same or more, but be far more locally controlled and manageable. Likely cost less, now that I give it a thought...
1GB and ~4x the DMIPS of a raspberrypi should go along way, lastest kernel in the xilinx git is 3.18, which one do you want? you can download schematic and gerbers.
trivial? what interface would you use to get a high bandwidth, low latency, dma capable interface to/from an FPGA?
buy a board and an FPGA, you'll have spend money and still not have something that can do the same
uZed is open source, schematic and Gerbers and BOM and everything. It has a ZYNQ SOC with FPGA fabric and dual-core 600 MHz ARMs, and the software tools to connect them. Having the ARMs and the FPGA on the same chip saves a lot of wires and nanoseconds. They bring out about
100 FPGA pins, on the bottomside connectors, for us to use on our application boards.
It's convenient to have the Ethernet, flash, DRAM, USB, and power supplies all worked out, booting Linux right out of the box. Especially nice for products that won't be built in the thousands.
--
John Larkin Highland Technology, Inc
picosecond timing precision measurement
jlarkin att highlandtechnology dott com
http://www.highlandtechnology.com
They could do that, but we don't expect it unless the file system got trashed somehow. Most file transfers will be over Ethernet. They can even upgrade our application code, or the FPGA config, that way.
We don't have a driver. We just make a system call to map the FPGA address space into our application space. Then we can r/w registers, or request file reads directly into the FPGA buffers. Easy.
Certainly.
I doubt that anyone would want to clone these products. There's way too much paranoia in this business.
--
John Larkin Highland Technology, Inc
picosecond timing precision measurement
jlarkin att highlandtechnology dott com
http://www.highlandtechnology.com
Den fredag den 27. februar 2015 kl. 23.13.43 UTC+1 skrev John Larkin:
No we only looked at them to get an idea of what was needed, our board is bigger (160x160) with ADCs, DACs, USB hub, eMMC, supercap USP, and different isolated interfaces
the "proper" way is to use the UIO driver, it is already included all you need to do is add a few lines to the devicetree with baseaddres, size and interrupt number, then open and mmap uio instead of mem. you don't have to be root to open uio, and it also adds interrupt to userland code, you just do a read() and it returns when there's an interrupt
We have 8 channels of signal processing: DDS clock generators, FIFOs waveform memories, phase shifters, FIR digital filters, summing, serial DAC drivers, PLLs. The main clocks are 64 and 256 MHz. No software, not even in a DSP processor, is going to do that. The two
600 MHz ARMs won't be working very hard; the FPGA does all the good stuff, massively parallel.
--
John Larkin Highland Technology, Inc
picosecond timing precision measurement
jlarkin att highlandtechnology dott com
http://www.highlandtechnology.com
Hey, I'm just the circuit designer. Whatever my guys are doing, it seems to work. I don't think we wrote a driver as such. We're not using interrupts in the FPGA interface.
I can design hardware forever, but I get depressed if I write code for more than a week or so.
--
John Larkin Highland Technology, Inc
picosecond timing precision measurement
jlarkin att highlandtechnology dott com
http://www.highlandtechnology.com
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.