public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Michael Schwingen <rincewind@discworld.dascon.de>
To: u-boot@lists.denx.de
Subject: [U-Boot] Fixing IXP42x boards - some general questions
Date: Thu, 23 Dec 2010 12:57:22 +0100	[thread overview]
Message-ID: <4D133922.2070201@discworld.dascon.de> (raw)
In-Reply-To: <4D133263.4020402@free.fr>

Am 12/23/2010 12:28 PM, schrieb Albert ARIBAUD:
>> Thanks. That means the code in the IXP startup code that copies flash to
>> RAM (before calling board_init_f, and long before relocation code does a
>> second copy) is really not needed, and can be removed if the branch to
>> the reset code is replaced by an absolute jump to the real
>> (not-aliased-to zero) flash location.
> As for the additional copy, yes, it is uneeded -- look at some 
> ARM-based archs or boards which support ELF relocation (such as arm926ejs).
>
> As for the jump, 'b' instruction is relative, and there is no need to 
> make an absolute jump -- unless you boot in a weird mode where FLASH 
> mirrors all over the memory space (and over RAM) and you need to jump to 
> the 'real', not 'mirrored', FLASH?
This is the case on IXP: the boot flash is located at 0x50000000 on the
expansion bus.
At reset, the flash is mirrored to 0x00000000, and the code starts
there. Later, the startup code removes that mirror so that the SDRAM is
at 0x00000000.

Currently, this works because the code copies u-boot from flash to
0x00000000 before disabling the mirror. However, a simple jump to
0x50000000 + offset works just as well (and is easier, because debug
symbols match execution).


>>>> What about interrupts? Use them or avoid them?
>>> I say in any case don't use them before running from RAM; and if you can
>>> avoid them in u-boot without incurring a huge performance penalty, I
>>> would suggest avoiding them altogether.
>> Fine with me. I got the non-interrupt code running, and will simply
>> leave the (broken) interrupt code as is if that is OK.
> Maybe it would be better to remove it. If someone really feels the need 
> to revive it, they can copy back it from a previous commit where it 
> still exists.
Fine with me. I don't really see why interrupts should be needed inside
u-boot on IXP425.

cu
Michael

  reply	other threads:[~2010-12-23 11:57 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-12-23  9:33 [U-Boot] Fixing IXP42x boards - some general questions Michael Schwingen
2010-12-23 10:10 ` Wolfgang Denk
2010-12-23 10:55   ` Marek Vasut
2010-12-23 15:13     ` Michael Schwingen
2010-12-23 12:23   ` Michael Schwingen
2010-12-23 10:20 ` Albert ARIBAUD
2010-12-23 10:39   ` Michael Schwingen
2010-12-23 11:28     ` Albert ARIBAUD
2010-12-23 11:57       ` Michael Schwingen [this message]
2010-12-23 18:25       ` Michael Schwingen
2010-12-23 18:47         ` Albert ARIBAUD
2010-12-23 20:17           ` Michael Schwingen

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=4D133922.2070201@discworld.dascon.de \
    --to=rincewind@discworld.dascon.de \
    --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