public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
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.

  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