> On Tue, Jun 14, 2011 at 9:12 AM, David Bisset
> <david_bisset@btconnect.com>  wrote:
>> I feel sure I must be missing the point given the complexity of the discussion to date.
>> But my approach would be to punt the MMU page out of the way since it maps 0 into RAM from early in the Bootloader process.
>> Then just talk directly to the NOR chip. There are a number of code blocks out there you could copy the NOR writing code from.
>> Why try and make it a real NOR partition when it isn't formatted as a FS, its just a fixed sequence of blocks in a memory device holding a fixed sequence of binary data.
> I hadn't thought of that...I just started down the mtd path and never
> thought to look left or right.
>
That was why I was suggesting a kernel firmware loader specific to the 
fpga. The trick here is how to stop and start NAND access while the fpga is 
being reprogrammed.

>>   You're only going to do this for Balloon 3 so there is no pressure to be generic.
> And it would appear that I'm only doing this for myself (i.e. nobody
> else has a desire/need to reprogram the FPGA from user space), so I'm
> most likely to go down the path of option 1 (and just adjust linuxargs
> to deal with the change in partition numbering).
>
>> The tough bit would be trying to program the FPGA live from user space...
> I figured that once I exposed the FPGA partition as /dev/mtdblockN, I
> would just dd my FPGA image into that block.
>
Just writing data to NOR requires a reboot for bootldr to put the data in 
the fpga of course.
One might even have more than one firmware loader - one that writes the 
data to NOR and one that writes to the fpga.
> If my latest idea doesn't work, I'll start thinking along these lines.
>
> Thanks for the tip.
>
> --wpd
>
> _______________________________________________
> Balloon mailing list
> Balloon@balloonboard.org
> http://balloonboard.org/mailman/listinfo/balloon