public inbox for ecos-discuss@sourceware.org
 help / color / mirror / Atom feed
From: Nick Garnett <nickg@ecoscentric.com>
To: kevin_lemay@agilent.com
Cc: ecos-discuss@sources.redhat.com
Subject: Re: [ECOS] i386 Memory Size Problem
Date: Wed, 26 Nov 2003 11:45:00 -0000	[thread overview]
Message-ID: <m3fzgb8kxm.fsf@miso.calivar.com> (raw)
In-Reply-To: <1BEBA5E8600DD4119A50009027AF54A010FAE483@axcs04.cos.agilent.com>

kevin_lemay@agilent.com writes:

> It appears to not be that easy.....
> 
> The BIOS calls may only be made in real mode. Redboot initializes
> the CPU, makes the required BIOS calls and switches to protected
> mode. Then thru TFTP, GDB, etc, loads an application and executes
> it.
> 
> So I would be able to perform the operations in RedBoot.
>

Good point, I hadn't realized that this is what you wanted to do.


> How do redboot and the loaded application work together? I know that
> portions of redboot continue to run. It appears that redboot owns
> the lower 640K of space and applications are always loaded starting
> at the 1MB boundary. I know that the pcmb_misc.c file is run, at
> least, by the application.
> 
> I do not know where to look for a way to pass data between them, but
> it must already been done for them to share CPU for debugging.

The ususal mechanism is via the virtual vectors. The application can
make calls back into RedBoot to do things like serial IO and fetch
things from the flash.

The virtual vector interface is implemented in the hal/common files:
hal_if.h and hal_if.c. 

> 
> I modified pcmb_misc to poke values at the 1Mb boundaries and read
> it back that appear to work correctly. I am having trouble
> envisioning what the proper solution looks like.
> 

The proper solution is probably to add a new virtual vector entry that
allows an eCos app to call the HAL_MEM_REAL_REGION_TOP() macro in
RedBoot.


-- 
Nick Garnett                    eCos Kernel Architect
http://www.ecoscentric.com      The eCos and RedBoot experts


-- 
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-26 11:45 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-11-25 22:24 kevin_lemay
2003-11-26 11:45 ` Nick Garnett [this message]
  -- strict thread matches above, loose matches on Subject: below --
2003-12-02 20:13 kevin_lemay
2003-12-03 10:29 ` Nick Garnett
2003-11-25 16:30 kevin_lemay
2003-11-25 17:29 ` Nick Garnett
2003-11-24 22:53 kevin_lemay
2003-11-25 10:57 ` Nick Garnett

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=m3fzgb8kxm.fsf@miso.calivar.com \
    --to=nickg@ecoscentric.com \
    --cc=ecos-discuss@sources.redhat.com \
    --cc=kevin_lemay@agilent.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).