Hi to All again,
I want to thank everyone who tried to help me to solve my problem.
I've found solution with using phram (rewritten and improved slram) MTD
driver.
(located in drivers/mtd/devices)
This driver makes of FPGA's SDRAM block device, in mu case /dev/mtdblock/6,
which I can give to g_fil
On Mon, 14 Feb 2005, Nemanja Popov wrote:
> File system is not necessary, actually it is not necessary for user programs
> to access contents of SDRAM directly. Now the question is, how to access
> contents of FPGA's SDRAM from host machine, or how the target board will be
> visible on host, th
Nemanja Popov wrote:
If you want the host to see a filesystem, then yes, you would need to
have
a filesystem stored in the SDRAM. But if you don't mind making the user
programs access the contents of SDRAM directly then you don't need a
filesystem.
Notice that you would face this same problem i
On Monday 14 February 2005 7:08 am, Nemanja Popov wrote:
>
> Also, is using g_ether good idea for this purpose? What transfer rate I can
> get when using USB2.0 NET2272 device (not on board yet) in both variants,
> with g_file_storage or g_ether.
The NET2272 is a high speed device, so you might
If you want the host to see a filesystem, then yes, you would need to have
a filesystem stored in the SDRAM. But if you don't mind making the user
programs access the contents of SDRAM directly then you don't need a
filesystem.
Notice that you would face this same problem if you adopt the suggest
On Mon, 14 Feb 2005, Nemanja Popov wrote:
>
> > Now I understand. You say that the SRAM address space is made available
> > to the pxa user through your FPGA driver. Can you change that driver to
> > make it export the SDRAM contents as a block device file (call it
> > /dev/fpga-sdram)? If you
Nemanja Popov wrote:
Now I understand. You say that the SRAM address space is made available
to the pxa user through your FPGA driver. Can you change that driver to
make it export the SDRAM contents as a block device file (call it
/dev/fpga-sdram)? If you can do that, then g-file-storage will b
Now I understand. You say that the SRAM address space is made available
to the pxa user through your FPGA driver. Can you change that driver to
make it export the SDRAM contents as a block device file (call it
/dev/fpga-sdram)? If you can do that, then g-file-storage will be able to
use the fil
On Fri, 11 Feb 2005, Nemanja Popov wrote:
> Sorry about unclear question. I'll try to clear out the problem .
> I'm using XScale pxa255 based board with 64 MB RAM running Linux 2.6.7. The
> device I was talking about is consisted of FPGA, CMOS senzor and 256 MB
> SDRAM memory. FPGA's role is to
Hi again,
Is there a possibility to force g_file_storage to transfer captured data
directly from device's RAM instead of using file as a backing storage?
This should be used only for downloading data to host (but writing to id
will be good). Data in the device's RAM is stored in raw format (no file
On Thu, 10 Feb 2005, Nemanja Popov wrote:
> Hi,
>
> Is there a possibility to force g_file_storage to transfer captured data
> directly from device's RAM instead of using file as a backing storage?
> This should be used only for downloading data to host (but writing to id
> will be good). Data
On Thursday 10 February 2005 8:07 am, Nemanja Popov wrote:
>
> Is there a possibility to force g_file_storage to transfer captured data
> directly from device's RAM instead of using file as a backing storage?
Have you looked at using a ramdisk as the backing store?
Hi again,
I didn't finished my e-mail (pressed send accidentaly).
Is there a way to map that dumy file to device's memory, and when getting is
requested on the host side, whole memory is copied instead of that dummy
file.
Maybe my idea is crazy but I don't know how to approach to this problem.
At
13 matches
Mail list logo
