|
(See, below, in-line.) David Banas From: owner- Hello Dave, Just got through watching the videos, and thank you again
for doing this. Definitely pulled a lot of ideas and issues together for
us. I have a couple of follow-on questions that arose during the
videos: 1. When you are copying the uClinux kernal image from
the RAM to the FLASH, what format is it in and where is it actually going? Straight binary and into that section of
the FLASH designated for kernel storage in the “FLASH map”, which,
by the way, is completely user-definable. I happen to be using the default
unmodified, which gives me 2 Mb in the 5th FLASH partition, I
believe, for kernel storage. I thot that the FLASH was used under the JFFS2 file system
to be a mountable drive under uClinux, while the .BIT file loaded to RAM was
raw binary. What am I missing here? Is the FLASH somehow
partitioned? Is so, where is that defined? Yes, it is partitioned (as explained,
above). The file that defines the partitioning is dependent upon how you’ve
configured the kernel build (using ‘make menuconfig’ or
equivalent), but, for the default case (i.e. – if you haven’t
modified the ‘MTD->Mapping…’ setting) the following file
is used: linux-2.4.x/drivers/mtd/maps/mbvanilla-flash.c Note that this file is “hard-wired”
and does NOT incorporate the new “auto-config” features. Therefore,
if you’re using this file to define FLASH partition mappings (as I am,
incidentally), you MUST edit it to reflect your particular FLASH memory base
address, as well as your desired kernel storage allotment, making sure to
allocate enough space in the “Kernel” partition for the actual “image.bin”
file you’ve created. Note also that you must, at the very
least, enter the configuration menu mentioned, above, in order to set the size
of your FLASH memory correctly, before building your kernel. This information
is used to select among several available partition maps in “*-flash.c”,
based upon the total amount of FLASH memory available. 2. You mention that for IP protection, you can encrypt
the bitstream and use a matching DES key set in battery-backed storage in the
FPGA. Does the Spartan-3 support this? If not, what experiences
have you had in protecting IP on that platform? I misspoke in my presentation. The Spartan
family does not support configuration bit stream encryption. This feature is
only supported in the Virtex family (2, 2P, and 4). The Spartan-3 offers 2
options for configuration bit stream security: prevention of read back and of
partial reconfiguration. Sorry about that. Thanks, Jim Law Iris Power Engineering
|