public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Peter Asemann <peter.asemann@web.de>
To: u-boot@lists.denx.de
Subject: [U-Boot-Users] My board doesn't boot - ram controller problem?
Date: Thu, 02 Jun 2005 16:56:38 +0200	[thread overview]
Message-ID: <429F1E26.1010508@web.de> (raw)

Hi there!

I've made tests to make sure my hardware boots before trying to run the 
u-boot. I found out it doesn't boot. So this question isn't that u-boot 
related; but it's close.

To test booting I wrote a very small assembler program (9 lines) which 
switches on a LED on my custom MPC875 powererd board and then loops forever.

I had the following assumptions:

1. The MPC875 will try to boot from 0xfff00100 due to my HRCW settings, 
which cause MSR[IP] to be "1".
2. The whole memory is tiled with the first 64K of the flash due to the 
fact that OR0 is 0x00000ff4 when the board boots, which should mask out 
the first 16 Bit of any address, so 0xffffxxxx addresses the same memory 
location as 0x0000xxxx.

I succeeded flashing my testprogram to 0x100 in the flash. The program 
run within flash by the telling the debugger to jump to 0x100. Switching 
off and on the board, nothing happened.

So I took a closer look on the memory in the debugger to make sure my 
assumptions were correct, and found out that assumption 2 seem not to 
fit the real world.
Though the OR0 should mask the whole first 16Bit of the address (so 
0xffff0100 should be the same as 0x00000100), it doesn't really do that.
Only the first 8 bit of the address are completely ignored, so 
0xff000100 is the same as 0x00000100. But 0xff800100 isn't, it seems to 
show empty flash (0xffffffff), I found out when looking into memory 
using the debugger.

Actually I have no idea what's wrong. I didn't find a hint in the MPC 
manual this could happen. I feel like maybe I'd understand that if I 
already had read the comment about relocating memory and the MPC manual 
often enough as I was told... but I didn't do that yet.

Maybe the fact that my flash is 16MB (0x1000000) big kind of disables 
the OR-masking-mechanism?

That could mean I need to put my "boot code" at 0xf00100 in my flash or 
change the board's setup so that IMMR is at 0xff000000 (instead of 0x0) 
and MSR[IP] is "0" instead of "1", so the board will really boot from 0x100.

Whatever. Any hints?

Best regards,

Peter Asemann

             reply	other threads:[~2005-06-02 14:56 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-06-02 14:56 Peter Asemann [this message]
2005-06-02 15:46 ` [U-Boot-Users] My board doesn't boot - ram controller problem? Wolfgang Denk
2005-06-02 17:16   ` Jerry Van Baren
2005-06-03 13:53   ` [U-Boot-Users] Board boots - minor memory controller operation understanding problem Peter Asemann
2005-06-03 15:26     ` Wolfgang Denk
2005-06-04 16:15       ` Peter Asemann
2005-06-04 18:45         ` [U-Boot-Users] PingSend richard at uclinux.net
2005-06-04 19:29           ` richard at uclinux.net
2005-06-04 19:59             ` Wolfgang Denk
2005-06-04 20:39               ` richard at uclinux.net

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=429F1E26.1010508@web.de \
    --to=peter.asemann@web.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