This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
Re: ROMRAM redboot
- To: Robin Farine <acnrf at dial dot eunet dot ch>
- Subject: Re: [ECOS] ROMRAM redboot
- From: Gary Thomas <gthomas at cambridge dot redhat dot com>
- Date: Thu, 07 Jun 2001 09:48:18 -0600 (MDT)
- Cc: eCos Disuss <ecos-discuss at sourceware dot cygnus dot com>,
- Cc: eCos Disuss <ecos-discuss at sourceware dot cygnus dot com>,Andrew Lunn <andrew dot lunn at ascom dot ch>
- Organization: Red Hat, Inc.
On 07-Jun-2001 Robin Farine wrote:
> Andrew Lunn <andrew.lunn@ascom.ch> writes:
>
>> > I've never tried ROMRAM start but to avoid the case where the
>> > application jumps into RedBoot in FLASH, I'm using these config
>> > options to build the eCos kernel:
>> >
>> > cdl_option CYGDBG_HAL_DEBUG_GDB_INCLUDE_STUBS {
>> > user_value 1
>> > };
>>
>> [..]
>>
>> > so that mostly every virtual vectors point to code in RAM.
>>
>> Yes, that makes the app include its own stub, and so stops ethernet
>> based debugging? The final application for the product could use your
>> setup. I want to keep ethernet debugging working if i can.
>
> In this case you could add a CPP define that conditionally includes code that
> disables interrupts during execution of FLASH algorithms in the application (I
> have tried this and I know, it's awful, but it works).
Something else which might be just as useful would be to disable the 'printf()'s
in the Flash code which is what I think Andrew is concerned with. These could
be conditional #ifdef CYGPKG_REDBOOT
Note: we've thought about extending the flash functions to not do the prints
directly, but rather through call backs. (Maybe Andrew even suggested that).
It's not been done yet, but still under consideration.