Michael Schnell wrote:
You can use EPCS MTD chip driver, which accesses SPI flash through
FPGA configuration port.
That is what I hoped. I'm not sure whether the "data" chip should be
attached to the same SPI bus as well, or if a second SPI interface
should be provided for same.
Before you decide to use another data chip, you should search some
vendors on the write life to see if you can find one chip solution.
If you have to use two chip, you can either modify the epcs interface to
add another eecs option or use another SPI bus to attach the data chip.
There is a SPI flash MTD chip driver in mainline kernel.
We prefer initramfs instead of cramfs or romfs, as it is easier and
used widely on latest Linux desktop. It is used by default in
uClinux-dist nios2 arch.
I understand that the initramfs method is more complicated but offers
some advantages. Of course I'll use it if it's the default in the
distribution I hopefully once will obtain.
Not exactly. The initramfs is more simplified. It is like a tarball of
your rootfs, but uses cpio instead of tar. It is actually easier than
romfs or cramfs. But I don't think Microtronix will use it in their
releases. Not all embedded developers realize the advantages of
initramfs. Perhaps, we are the few very first.
I suppose after starting the Kernel the root file system is copied
from a partition of the program Flash into RAM. I suppose this can be
done using the initramfs method.
I want to have (at least) one more partition in the flash that should
contain a real file system (jjfs2 ?). The initial user mode stuff
should create an file system in RAM and copy the content of that
partition in the flash there. But the files in the flash should be
writable by normal user land programming (for upgrade purposes).
EPCS is alter'a name of SPI flash, they are the same inside. You can
divide the flash to partitions. The first partition contain fpga
configuration data and a boot loader from altera, followed by the
compressed kernel image. The initramfs is incldued in kernel image.
After power on, the fpag gets configured, then the boot loader load
kernel into sdram, and kernel populates initramfs to a ramfs. We use
this ramfs as rootfs. It works seamlessly.
You can use another partition on the same chip for jffs2 to store user
data. You can even setup multiple partitions for additional fpga
configuration and programs, for recovering (in case of upgrading
failed), like that of remote configuration, called by Altera.
You can find all the details in nios wiki.
I think you could borrow a Nios dev board from your FAE. You can use
Cyclone I or Cyclone II to get some hand on experiments. They are almost
the same as Cyclone III. This can save you some time, as it looks like
your projects will start soon.
I didn't have any dev boards myself, as I developed on my custom boards
right from the start. I did borrow some dev boards from time to time to
help resolving problems on the forum.
BTW, I have work out the way to debug apps on uClinux. Eclipse CDT
should not be far.
That is exactly what I want. I suppose you did meet Ben somewhere
around here. Maybe you can help him find something decent to offer us,
so that we can avoid Microtronix. We really want to (buy development
hardware and) start working on that in January.
OTOH, Microtronix did provide some Eclipse plugins that I did see
working with Quartus 7.x (which I need to use as we intend to go with
the Cyclone III). Can these be used or will someone provide similar
plugins ?
Eclipse is not magic. I don't use Eclipse myself. I think many people on
the list don't use Eclipse, either. Most of our tools are command line
based. They are much faster and more reliable than an IDE.
Linux on FPGA is very different from other hard chips. As you got the
ability to define custom hardware, you got more chances to write
drivers. You should spend your time on FPGA and Linux internal. Rather
than believe that Eclipse can save you.
Cheer,
Thomas
_______________________________________________
uClinux-dev mailing list
[email protected]
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by [email protected]
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev
