This is the mail archive of the ecos-discuss@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]

Re: RedBoot porting


>>>>> "Andrew" == Andrew Lunn <andrew.lunn@ascom.ch> writes:

>> If I do not want RedBoot to provide any services to user
>> applications, do I still need to implement virtual vector support
>> in my HAL?  [Having application code depend on services available
>> in the boot loader is way too high-risk, since there isn't going to
>> be any way to upgrade the boot loader in the field.]

Andrew> Even if you could try to upgrade the boot loader in the field,
Andrew> its hard to do. In my case the boot loader is in FLASH. My
Andrew> code has a TFTP server running that allows me to download new
Andrew> images into the FLASH. The problem with redboot is that you
Andrew> have no control when it tries to jump into the ROM. A typical
Andrew> sinario is that i erase a block and start writing bytes to
Andrew> it. The app then decides to jump into Redboot, typical for ^C
Andrew> support reasons. The FLASH is currently in write mode so the
Andrew> first instruction read in ROM returns the status code of the
Andrew> current write, which the CPU tries to execute and its RIP, you
Andrew> dead.

Andrew> What would be nice is being able to tell the app, don't jump
Andrew> into ROM for a while, i need exclusive access to the FLASH.

Interesting - presumably you cannot disable interrupts for the
duration of the flash update process?

One way this could be accomplished is by providing a function (in RAM
application) that saves the virtual vector table, fills it with
pointers to NOP functions (in RAM) which count usage.  

Then update the flash [you could still be hit by interrupts that do
rogue access to flash and spoil the programming btw, but nothing short
of disabling interrupts is going to fix bugs of that nature]

Afterward call another function which restores the virtual vector
content. Possibly use usage counts to make some follow up actions (for
instance, instead of NOP functions for the HAL IO routines, one could
put in a function that does limited buffering, and output the buffered
data when the vectors are restored).


Jesper

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