public inbox for ecos-discuss@sourceware.org
 help / color / mirror / Atom feed
From: Gary Thomas <gary@mlbassoc.com>
To: "Snider, Marc" <Marc.Snider@icn.siemens.com>
Cc: "'ecos-discuss@sources.redhat.com'" <ecos-discuss@sources.redhat.com>
Subject: RE: [ECOS] Redboot image load via PCI bus?
Date: Thu, 06 Nov 2003 17:41:00 -0000	[thread overview]
Message-ID: <1068140515.13745.6878.camel@hermes> (raw)
In-Reply-To: <DC26B4448BEC824C8C4E58845FF9F04CD6A385@Email2.west.icn.siemens.com>

On Thu, 2003-11-06 at 10:37, Snider, Marc wrote:
> My thought was to provide the standard I/O device driver routines (open,
> close, read...) on top of the PCI accesses and thus shield the higher layer
> loader code.  I'd make it look like the image data was coming from somewhere
> else like the flash.  It looks like do_load doesn't care where the image
> data comes from as long as the native format (in my case likely SREC) is
> maintained...
> 
> Yes, the host does have access to the memory on the target system, but it
> would be preferable to pull the data from the host as opposed to pushing it
> from there to the target...
> 

Understood.  If you look carefully at how the "load" command works,
you won't need to make *any* changes directly to it, but just add a
new I/O method.  Also, I'd suggest that you put your new PCI method
in your platform HAL - there is no need to mess about with the core
of RedBoot.

note: a lot of care has been taken (by me) to allow such extensions
without any [direct] changes to the RedBoot tree.  

... Ah, the joy of tables.

> Marc
> 
> 
> -----Original Message-----
> From: Gary Thomas [mailto:gary@mlbassoc.com]
> Sent: Thursday, November 06, 2003 11:46 AM
> To: Snider, Marc
> Cc: 'ecos-discuss@sources.redhat.com'
> Subject: Re: [ECOS] Redboot image load via PCI bus?
> 
> 
> On Thu, 2003-11-06 at 09:45, Snider, Marc wrote:
> > Is there a canned method implemented somewhere for loading an image via
> the
> > PCI bus (from another host), as opposed to using the network or loading
> from
> > flash?   I'd like to load an image from a control host across the PCI bus
> > and then burn it to flash...   I'm assuming that if there isn't then I'll
> > need to modify the do_load command and provide a set of I/O routines that
> > map PCI accesses into standard I/O convention...
> > 
> > I'm on a PowerPC440 platform, if the platform matters.
> 
> What method would you use to access the image via the PCI?
> Can your host access the memory on the board?
> 
> -- 
> Gary Thomas <gary@mlbassoc.com>
> MLB Associates
-- 
Gary Thomas <gary@mlbassoc.com>
MLB Associates


-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss

  reply	other threads:[~2003-11-06 17:41 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-11-06 17:33 Snider, Marc
2003-11-06 17:41 ` Gary Thomas [this message]
  -- strict thread matches above, loose matches on Subject: below --
2003-11-06 18:10 Snider, Marc
2003-11-06 18:13 ` Gary Thomas
2003-11-06 16:41 Snider, Marc
2003-11-06 16:45 ` Gary Thomas

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=1068140515.13745.6878.camel@hermes \
    --to=gary@mlbassoc.com \
    --cc=Marc.Snider@icn.siemens.com \
    --cc=ecos-discuss@sources.redhat.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).