From: Albert ARIBAUD <albert.aribaud@free.fr>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH] at91rm9200: fix lowlevel_init() SMRDATA size
Date: Sat, 04 Dec 2010 19:18:21 +0100 [thread overview]
Message-ID: <4CFA85ED.3090009@free.fr> (raw)
In-Reply-To: <CEE4B2D5-D8E9-4C8F-ACA1-0D120FE135C0@googlemail.com>
Hi Andreas,
Le 04/12/2010 14:14, Andreas Bie?mann a ?crit :
>>> 1. In start.s the vector table is relocated from _start to 0x00. But at this time 0x00 is remaped to nor flash.
>>
>> Hmm... This copy (not a relocation) should be done after cpu_init_crit /
>> lowlevel_init, which should have at least configured some RAM; but you
>> are right that mapping to 0 is somewhat arbitrary, since the reset
>> vectors could be some other places (0xffff0000, for instance).
>
> I think this is historic. I remind of the same sequence in an old atmel provided pre-loader code.
> I think we can omit this and let the linker do the location of vector table, are we? Will have a look for that tomorrow evening.
Just a note: the linker will place the reset vector and some others at
the location where reset actually occurs (hopefully), but the system,
once started, may well redefine the *exception* vectors, for instance to
get interrupts working (some boards use IRQs). On targets that boot from
NOR, the system cannot overwrite the exception vectors at the link-time
NOR location: it must move the vectors location to RAM. So no, the
linker cannot always do the location of the vector table.
> regards
>
> Andreas Bie?mann
Amicalement,
--
Albert.
next prev parent reply other threads:[~2010-12-04 18:18 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-12-03 7:26 [U-Boot] [PATCH] at91rm9200: fix lowlevel_init() SMRDATA size Andreas Bießmann
2010-12-03 17:09 ` Jens Scharsig
2010-12-03 21:22 ` Andreas Bießmann
2010-12-04 11:37 ` Jens Scharsig
2010-12-04 12:04 ` Albert ARIBAUD
2010-12-04 13:14 ` Andreas Bießmann
2010-12-04 18:18 ` Albert ARIBAUD [this message]
2010-12-04 10:53 ` [U-Boot] [PATCH alternate version] " Jens Scharsig
2010-12-04 13:12 ` Andreas Bießmann
2010-12-04 13:19 ` Andreas Bießmann
2010-12-05 8:12 ` [U-Boot] [PATCH alternate version V2] " Jens Scharsig
2010-12-05 10:16 ` Reinhard Meyer
2010-12-06 17:36 ` Jens Scharsig
2010-12-06 21:03 ` Andreas Bießmann
2010-12-12 19:12 ` Jens Scharsig
2010-12-17 7:55 ` Reinhard Meyer
2010-12-23 11:37 ` Andreas Bießmann
2010-12-18 12:30 ` [U-Boot] [PATCH alternate V3] " Jens Scharsig
2010-12-23 11:39 ` Andreas Bießmann
2010-12-23 12:13 ` Reinhard Meyer
2010-12-23 13:05 ` Jens Scharsig
2011-04-11 9:58 ` Reinhard Meyer
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=4CFA85ED.3090009@free.fr \
--to=albert.aribaud@free.fr \
--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