This is the mail archive of the
ecos-patches@sources.redhat.com
mailing list for the eCos project.
Re: Request for comments - Redboot load command writing directly to flash
- From: "Gary D. Thomas" <gary at mind dot be>
- To: Øyvind Harboe <oyvind dot harboe at zylin dot com>
- Cc: ecos-patches at sources dot redhat dot com
- Date: Sat, 12 Jul 2003 05:44:56 -0600 (MDT)
- Subject: Re: Request for comments - Redboot load command writing directly to flash
- References: <000801c34783$67f12290$73dea8c0@lair>
Øyvind Harboe said:
> This patch is not complete, hence the RFC.
>
> I've made some changes to allow the "load" command in Redboot
> to write directly to flash. Although I've only tested it on EB40a,
> it may well work on other boards.
>
> Rationale:
>
> I'm working on a where the hardware is based upon the Atmel EB40a.
> The production board is as the EB40a, except with an additional
> FPGA and no possibility of expanding RAM. This leaves me
> with 256kb of ram and 2mb of flash, hence loading data into
> ram before flashing isn't terribly convenient.
>
Understood. However, I have some reservations (as previously noted).
>
> Example:
>
> 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)?
>
> - Should the argument to the -f option should be removed? Changed
> to maximum length?
You should try to use "common" option names. For other operations,
"-l" is used to specify the maximum length.
>
> - 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?
>
> - Is there a sufficent ymodem CRC check good enough...?
It should be good enough, yes.
>
> - Flashed image should be verified
There's the rub :-) Since you explicitly don't have a copy in
memory, how can you do this?
>
> - I tried to modify the serial port rate on my EB40a to >38400,
> but it didn't work. There may be trouble with any
> baudrate != 38400 on EB40a, but I haven't checked.
>
> - I'm not quite sure why it works as well as it does :-)
> AFAIK, Redboot does not run with interrupts enabled and if
> Redboot is off flashing a byte, whos servicing the serial port?
> As is, I assume that there is a fairly big HW fifo on my EB40a
> board, and thats why it works as well as it does.
This is indeed a problem. Since RedBoot always uses the serial
port in the simplest fashion - no interrupts and sometimes even
no FIFO or buffers - a serial overrun is a very real possibility.
Don't forget that the downloaded data could even come via a
TELNET stream (TCP/IP) over ethernet, which might also be
troublesome.
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.
Note: We do want to be flexible in our patch/change policies, but
at the same time, we have to worry about the consequences of changes,
thus the care taken on each one proposed/submitted.
I look forward to further discussion - as you said, this is an RFC :-)