public inbox for ecos-discuss@sourceware.org
 help / color / mirror / Atom feed
From: Jonathan Larmour <jlarmour@redhat.com>
To: Gary Thomas <gthomas@redhat.com>
Cc: Dave Airlie <airlied@parthus.com>,
	ecos-discuss@sources.redhat.com, Grant Edwards <grante@visi.com>
Subject: Re: [ECOS] PID ROM and eCos
Date: Wed, 24 Jan 2001 11:39:00 -0000	[thread overview]
Message-ID: <3A6F2F81.9DDB2A5E@redhat.com> (raw)
In-Reply-To: <XFMail.20010124122020.gthomas@cambridge.redhat.com>

Gary Thomas wrote:
> 
> On 24-Jan-2001 Jonathan Larmour wrote:
> > Gary Thomas wrote:
> >>
> >> Look at the startup code for the Cirrus Logic EDB7xxx boards.  They
> >> support this configuration where the image in ROM (FLASH or whatever)
> >> is linked at an address different from where they are stored.  If
> >> this case is detected, the ROM code simply gets copied to RAM at
> >> startup time.  Look in the file:
> >>   hal/arm/edb7xxx/current/include/hal_platform_setup.h
> >
> > Why was it done this way, and not with a more explicit ROMRAM startup type?
> > If you have a separate startup type it is more under user control.
> >
> 
> It has been this way for more than 18 months - long before the new CDL and
> the tools to make adding new/different startup types simple.  Also, I only
> did it in a moment since running some code on that platform did not perform
> adequately from FLASH, but would from RAM.

Good answer :-).
 
> > Anyway, you can also refer to the way the mips vrc4373 or sh edk7708 do it,
> > which use an explicit ROMRAM startup.
> 
> And all the trappings [read details and troubles] that go with it.

Firstly, it should be down to the user on whether they want to copy to RAM.
But also I've done other work (Gary can probably guess what) this way and
it was no real trouble. The only problem is determining real addresses
before relocation, but that's easy too. With the ARM you could even use MMU
tricks, but I wouldn't recommend it :).

Jifl
-- 
Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 (1223) 271062
Un cheval, pas du glue. Pas du cheval, beaucoup du glue. || Opinions==mine

  reply	other threads:[~2001-01-24 11:39 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-01-24  7:12 Dave Airlie
2001-01-24  7:27 ` Andrew Lunn
2001-01-24  7:42 ` Grant Edwards
2001-01-24  8:02   ` Gary Thomas
2001-01-24 11:08     ` Jonathan Larmour
2001-01-24 11:15       ` Dave Airlie
2001-01-24 11:20       ` Gary Thomas
2001-01-24 11:39         ` Jonathan Larmour [this message]
2001-01-25  9:53           ` Dave Airlie

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=3A6F2F81.9DDB2A5E@redhat.com \
    --to=jlarmour@redhat.com \
    --cc=airlied@parthus.com \
    --cc=ecos-discuss@sources.redhat.com \
    --cc=grante@visi.com \
    --cc=gthomas@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).