From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jesper Skov To: Andrew Lunn Cc: Grant Edwards , ecos-discuss@sources.redhat.com Subject: Re: [ECOS] RedBoot porting Date: Mon, 08 Jan 2001 01:09:00 -0000 Message-id: References: <20010105115220.A2486@visi.com> <20010108092928.I10158@biferten.ma.tech.ascom.ch> X-SW-Source: 2001-01/msg00064.html >>>>> "Andrew" == Andrew Lunn 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