public inbox for ecos-discuss@sourceware.org
 help / color / mirror / Atom feed
From: Jesper Skov <jskov@redhat.com>
To: Andrew Lunn <andrew.lunn@ascom.ch>
Cc: Grant Edwards <grante@visi.com>, ecos-discuss@sources.redhat.com
Subject: Re: [ECOS] RedBoot porting
Date: Mon, 08 Jan 2001 01:09:00 -0000	[thread overview]
Message-ID: <oty9wmwgtj.fsf@thinktwice.zoftcorp.dk> (raw)
In-Reply-To: <20010108092928.I10158@biferten.ma.tech.ascom.ch>

>>>>> "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

  reply	other threads:[~2001-01-08  1:09 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-01-05  9:49 Grant Edwards
2001-01-05 15:41 ` Jonathan Larmour
2001-01-08  0:08 ` Jesper Skov
2001-01-08  0:29 ` Andrew Lunn
2001-01-08  1:09   ` Jesper Skov [this message]
2001-01-08  2:36     ` Andrew Lunn
2001-01-08  3:04       ` Jesper Skov
2001-01-08  7:31   ` Grant Edwards
2001-01-08  7:40     ` Lewin A.R.W. Edwards
2001-01-08  8:24       ` Grant Edwards
2001-01-08  7:42     ` Gary Thomas
2001-01-08  7:57       ` Grant Edwards
2001-01-08  7:59       ` Andrew Lunn
2001-01-08  8:07         ` Gary Thomas
2001-01-08 14:42 ` Grant Edwards
2001-01-08 16:26   ` Gary Thomas
2001-01-09  7:33     ` Grant Edwards
2001-01-08  4:36 Doug Fraser
2001-01-08  4:54 ` Jesper Skov
2001-01-08  7:34 ` Grant Edwards
2001-01-08  5:32 Doug Fraser
     [not found] <20010108171508.U10158@biferten.ma.tech.ascom.ch>
     [not found] ` <XFMail.20010108095423.gthomas@redhat.com>
2001-01-09  0:50   ` Andrew Lunn
2001-01-09  8:57     ` Grant Edwards
2001-01-09  9:05       ` Andrew Lunn
2001-01-09  9:12         ` Grant Edwards
2001-01-09  9:09       ` Gary Thomas
2001-01-09  9:24         ` Grant Edwards
2001-01-09  9:47         ` Andrew Lunn
2001-01-09 10:08           ` Lewin A.R.W. Edwards
2001-01-09 10:30             ` Grant Edwards
2001-01-09 10:39             ` Andrew Lunn
2001-01-09 11:24               ` Grant Edwards
2003-09-16  2:55 [ECOS] redboot porting yu weiping

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=oty9wmwgtj.fsf@thinktwice.zoftcorp.dk \
    --to=jskov@redhat.com \
    --cc=andrew.lunn@ascom.ch \
    --cc=ecos-discuss@sources.redhat.com \
    --cc=grante@visi.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).