From: Graeme Russ <graeme.russ@gmail.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] 'Relocation' for sc520 (i386) based boards
Date: Sun, 21 Sep 2008 18:08:24 +1000 [thread overview]
Message-ID: <48D600F8.9080801@gmail.com> (raw)
Hi All,
I've been thinking about where U-Boot runs in memory on my sc520
based board and it appears that it is always executing from ROM and
I started pondering if I should attempt to relocate U-Boot into RAM.
Note: Please correct me if I am mistaken and U-Boot does indeed run
from RAM on i386 / sc520
This, of course, would give me the benefit of having unfettered access
to the flash that U-Boot is located on for things like environment
storage, upgrade in place etc.
My thought is to not actually 'Relocate' U-Boot but to use a very
handy feature of the sc520 - The ability to map the BOOTCS (Boot ROM
Chip Select) to anywhere in memory using a PAR (Programmable Address
Region).
Currently, BOOTCS is mapped from 0x38000000. My board has 512k Boot
Flash, so the BOOTCS PAR is 0x38000000 - 0x3807ffff. With U-Boot in
the upper 256k (puts the reset vector at fff0 for cpu startup), this
puts u-boot code at 0x38040000 (TEXT_BASE in config.mk).
The SDRAM for my board is 128MB starting at 0x00000000 (ending at
0x08000000)
My thought is to change TEXT_BASE to 0x08040000, keep BOOTCS at
0x38000000, copy 0x38040000 - 0x3807ffff to 0x08040000 - 0x0807ffff
as soon as I enter protected mode (and have access to all memory) and
have set up the SDRAM controller etc, then jump directly to the copy
in RAM. I would then have two copies of u-boot in memory - One in RAM
at 0x08040000 and one in ROM at 0x38040000.
One problem I can think of is that the linker will point all the jump
labels into RAM - not an issue for the 16-bit code which uses relative
jumps, but I think I may run into issues during the real to protected
mode transition (far jump) which, by definition, has to happen before
I get access to the full memory space. How do I tell the linker that
these jumps should target 0x38040000+ and not 0x08040000+ ?
Does all this sound logical? viable? sensible? practical?
Regards,
Graeme
next reply other threads:[~2008-09-21 8:08 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-09-21 8:08 Graeme Russ [this message]
2008-09-21 17:29 ` [U-Boot] 'Relocation' for sc520 (i386) based boards Jerry Van Baren
2008-09-21 23:18 ` Graeme Russ
2008-09-22 12:51 ` Graeme Russ
2008-09-22 12:52 ` Graeme Russ
2008-09-22 12:57 ` Graeme Russ
-- strict thread matches above, loose matches on Subject: below --
2008-09-23 6:58 yusuf khan
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=48D600F8.9080801@gmail.com \
--to=graeme.russ@gmail.com \
--cc=u-boot@lists.denx.de \
/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