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 directly to flash


Ø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 :-)




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