This is the mail archive of the 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 directly to flash

I forgot a couple of issues:

- if writing to flash takes a long time, will the ymodem protocol
be able to recover(i.e. resend the data)?

- I only added support for raw binaries. What about elf/srec?

- Does it make sense to try to push this feature to all 
device and software configurations? Surely it is much more 
useful on smaller devices such as the 2MB flash 256k RAM.

> > load -f 0x10000 -b 0x1100000 -r -m ymodem
> >
> > Erases 0x10000 bytes of flash starting at 0x1100000 and writes the 
> > uploaded file directly to 0x1100000
> >
> > Issues:
> >
> > - There is a bit of an impedance mismatch between Redboot and the 
> > io/flash API. My first step in dealing with this was to 
> create a flash 
> > programming function in io/flash that writes a single byte and does 
> > not produce debug output
> And what happens on hardware that can't write a single byte? 
> What if the FLASH happened to be NAND FLASH that has to write 
> in big chunks? (I know this is not currently supported, but I 
> expect it will be very soon)?

I'm not familiar with NAND flash.

Is it realistic to suggest changes to the io/flash API?

Pseudo outline of modified API:

prepareWrite(start, end) -> returns success/failure. Erases the
region. Can span multiple sectors.

write(data) -> writes data directly to flash or writes
to an interim buffer as required. This call could would
flush data to flash as required(i.e. it could potentially
take a "long" time). returns success/failure.

endWrite() -> flushes data in any caches and returns success/failure.
A CRC check is run upon data written to flash.

> You should try to use "common" option names.  For other 
> operations, "-l" is used to specify the maximum length.


Perhaps a seperate option to indicate that we're writing to flash as
to writing to ram?

Perhaps remove the option entirely?

Redboot could tell from the address range that I'm trying to write
to flash.

> > - I've purposly removed the flash memory range check in order to be 
> > able to flash new versions of redboot rom using redboot ram.
> What does this mean?

The flash writing routines have builtin checks to make sure that
fis write/erase does not erase Redboot. Not so with my more 
powerful code. :-)

> Don't forget that the downloaded data 
> could even come via a TELNET stream (TCP/IP) over ethernet, 
> which might also be troublesome.

Flow control might be easier with the above,
so "cpu outages" while flash is being written is less of a problem...

Perhaps the best way to support the feature for these sort of devices
is to keep the "load" syntax, but to download the entire image into
RAM first? Does a device with TCP/IP and ethernet generally have
more RAM than flash?

> I scanned your patches.  My first concern is that these 
> changes are not configurable (i.e. you didn't add CDL options 
> to control
> them) and invasive (e.g. "load.c" always assumes that 
> CYGPKG_FLASH is present).  Before we can consider integrating 
> your changes, this will have to be addressed.


This was something I hacked together to verify that it was
doable, and to get a discussion going.


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