This is the mail archive of the ecos-patches@sources.redhat.com mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: Request for comments - Redboot load command writing directlyto flash


I have some concerns about serial FIFOs and the 
"CPU outages" issues touched on earlier:

- The modifications I did to implement support for 
"load" to write directly to flash, can not work without a FIFO.
I don't excactly know where this FIFO comes from in my EB40a scenario, 
though I suspect that the code is preconfigured somehow to have 
a reasonably large FIFO running. The EB40a effectively supports 
a HW FIFO of up to 64kbyte, as far as I can see from the datasheets.

- If "load" is to be able to write directly to flash, then there
must be some more general FIFO scheme in place. One way I can see
this done is to enable interrupts and use the eCos serial FIFO
code. This runs a bit counter to one of the
stated design goals of Redboot not to use interrupts. I presume
the motivation behind not using interrupts is to keep Redboot
as simple as possible. Perhaps there are other reasons? Can the
GDB interface work if Redboot used interrupts?

- Are interrupts enabled during flash writes/erases? It seems
like the at49xxxx code is disabling interrupts for the duration of
flash program/erase. Most applications probably have some maximum
time duration where interrupts can be disabled before they start
to malfunction. I haven't timed the duration for programming a
at49xxxx sector.

This whole project is starting to look a bit messy. Perhaps 
a better solution would be to leave Redboot alone and create
a custom bootloader? 

My "Greenboot" to replace Redboot would roughly:

- be an eCos app with multithreading(?) and interrupts enabled
- wait 1 sec for ctrl-c to arrive on the serial port after reset. 
If no ctrl-c arrives, it would launch my real app from flash.
- erase previous app from flash
- start ymodem download
- write the app directly to flash
- wait for reset

In this scenario all the facilities of eCos would be available to 
me. I could have one thread downloading via ymodem, and a second
thread writing to flash as the data became available. 

The Redboot code nicely seperates out the ymodem code
from the rest, so this shouldn't be very hard.

Perhaps I'd loose GDB support, but that isn't too big a loss in
for the shipping product as the eCos GDB suppport is only 
complementing our JTAG debugger.

Øyvind


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]