On 08/06/11 14:56, Patrick Doyle wrote:
> On Wed, Jun 8, 2011 at 9:31 AM, Chris Jones<chris@martin-jones.com>  wrote:
>    
>> On 08/06/2011 14:43, Patrick Doyle wrote:
>>      
>>> I think I'll go down the path of enabling access to the FPGA partition
>>> of the NOR flash... at least until the "too hard" LED turns on.  Then
>>> I'll start looking at the bbl path recommended by Wookey.  I'm
>>> avoiding the bbl path right now because my USB<->RS232 converter only
>>> works natively on my MacBook, and I deemed it more difficult (and less
>>> fun) to figure out how to make bbl run on the MacBook, than it would
>>> be to go hack kernel code.
>>>        
>> Don't worry too much about bbl. Clever and useful though it is, it's a
>> wrapper round existing procedures using the serial port and JTAG ports
>> mostly. My world suffers from sufficient dependency rot that I often
>> find it easier to work with the bare metal - see below.
>>
>> My favourite ways of programming the NOR Flash:
>> - serial into the bootldr with 'load flash 0x.....' and an XMODEM
>> transfer. Pretty slow at 115kbaud but simple and reliable.
>> - if the wind's blowing in the right direction, OpenOCD to talk to the
>> JTAG port on the Balloon and program the NOR Flash that way. Quicker,
>> capable of 20kbytes/sec or more, but requires more complex hardware and
>> software.
>>
>> Both of these should work without too much grief on the Mac. I've used
>> them both, though I've found USB-serial adapters on my Mac to be less
>> than perfect.
>>
>>      
> I have been using ZMODEM fine.  But now that I have my spiffy PPP
> network connection set up, I think I'll try NOR mtdblock thing.
>
> I do have a USB based JTAG pod, but I feel kinda funny programming a
> Xilinx part with an Altera Byte Blaster :-)
>
> Plus, I don't have the breakout board with the JTAG header anyway.
>
> --wpd
>
>    
The history of this goes back to Balloon2. There were two NOR flavors. 
The standard version was a moderately large CFI compliant chip. The 
largest Balloon2 customer (TCL) used a tiny non-CFI NOR (and a CPLD 
instead of FPGA) that had a fake CFI shim welded into bootldr to support 
it. This made exposing the NOR in the linux kernel a nuisance and also 
was a brick-your-balloon option for users. It was decided on balance to 
not expose the NOR as a flock of mtd partitions and keep it in the 
bootldr domain.

Balloon3 is of course much simpler but the "dont-expose-your-NOR" 
principle was sort of carried over.

My preferred solution would be to upload replacement FPGA images from a 
booted Balloon3 using a firmware loader. This means you could have 
multiple FPGA images to test/compare.

We didn't explore this on Balloon2 as it didn't have firmware upload 
infrastructure.

Nick Bane

> _______________________________________________
> Balloon mailing list
> Balloon@balloonboard.org
> http://balloonboard.org/mailman/listinfo/balloon
>