[U-Boot-Users] My board doesn't boot - ram controller problem? - U-Boot

[U-Boot-Users] My board doesn't boot - ram controller problem?

Peter Asemann

2 Jun 2005 2 Jun '05

4:56 p.m.

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

Show replies by date

Wolfgang Denk

2 Jun 2 Jun

5:46 p.m.

In message 429F1E26.1010508@web.de you wrote:

...

I had the following assumptions:

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

Did you read the MPC8xx User's Manual about how the processor comes up from reset? Read it again, please.

Best regards,

Wolfgang Denk

-- Software Engineering: Embedded and Realtime Systems, Embedded Linux Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de There are three things I always forget. Names, faces - the third I can't remember. - Italo Svevo

Jerry Van Baren

7:16 p.m.

Wolfgang Denk wrote:

...

In message 429F1E26.1010508@web.de you wrote:

...
I had the following assumptions:

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

Did you read the MPC8xx User's Manual about how the processor comes up from reset? Read it again, please.

Best regards,

Wolfgang Denk

And, just to add my 2 cents, you should look at your debugger configuration. Your debugger most likely is writing to registers to set your processor up so it can load and run programs. This includes writing to the BR and OR registers. Look at what it is doing for initialization, compare that to what you are doing, read the processor manual, and understand it all. That is the path to enlightenment (or at least blinkin' LEDs).

gvb

Peter Asemann

3 Jun 3 Jun

3:53 p.m.

New subject: [U-Boot-Users] Board boots - minor memory controller operation understanding problem

Hi there!

...

...
I had the following assumptions:

The MPC875 will try to boot from 0xfff00100 due to my HRCW settings,

which cause MSR[IP] to be "1".

...

...

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

Did you read the MPC8xx User's Manual about how the processor comes up from reset? Read it again, please.

1. I re-read the sections about how the processor comes up from reset. I still believe that the MPC tries to boot from 0xfff00100 for my board is configured that way (plus, it boots my 7-line-assembler-boot-test program which is at offset 0xf00100 in my boot flash).

2. I also re-read the section about the memory controller; I didn't read anything new, but had an idea that maybe I misinterpreted the way BR[BA] and OR[AM] work. My new theory is that the address mask OR[AM] doesn't influence the address on the bus (which I thought it could be able to before) but only the perception of the memory controller, that means, the decision of the memory controller to which memory bank an address belongs. Am I right?

Best regards, thanks again for your patience,

Peter Asemann

Wolfgang Denk

5:26 p.m.

New subject: [U-Boot-Users] Board boots - minor memory controller operation understanding problem

In message 42A060DE.4010000@web.de you wrote:

...

I also re-read the section about the memory controller; I didn't read

Widen your scope. Read the section about how the CPU comes out of reset.

...

anything new, but had an idea that maybe I misinterpreted the way BR[BA] and OR[AM] work. My new theory is that the address mask OR[AM] doesn't

The question is not how they work in general, but how BR0 / OR0 are acting after a reset until they first get written to. [Which is problaby what your BDM4GDB init script does, which in turn is probably why you don't see the things you expect.]

Best regards,

Wolfgang Denk

-- Software Engineering: Embedded and Realtime Systems, Embedded Linux Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de People with narrow minds usually have broad tongues.

Peter Asemann

4 Jun 4 Jun

6:15 p.m.

New subject: [U-Boot-Users] Board boots - minor memory controller operation understanding problem

...

The question is not how they work in general, but how BR0 / OR0 are acting after a reset until they first get written to. [Which is problaby what your BDM4GDB init script does, which in turn is probably why you don't see the things you expect.]

You "misunderestimate" me. I've of course a minimal init script that does nothing but disable the watchdog reset. I've also already found out that the address put on the address bus (0xfff00100) is not influenced by the memory controller, that the flash is visible multiple times in the address space is only due to the fact that the most significant 8 bit of the address are not connected with the flash chips.

Whatever, with your rather cryptic hint you're probable referring to the MPC manual subsubsection "Boot Chip-Select Operation", which states that upon reset. "CS0 ist asserted for every address, unless an internal register is accessed." Single sentences are hard to find in 1.5K pages manuals, btw..

So this most probably means the memory controller doesn't care the least bit for the address mask in OR0 before OR0 is re-written, as CS0 is asserted anyway, no matter what OR0[AM] is.

It'd be a lie if I alleged I had been very happy with your hint, but with hindsight: Thanks again.

Best regards,

Peter Asemann

richard＠uclinux.net

8:45 p.m.

New subject: [U-Boot-Users] PingSend

Evening (o;

Something puzzed me today...(and still is ;o)

In "net/net.c" in function PingSend we fill out the ping packet to be sent later on after ARP reply, which is pointed to by "NetArpWaitTxPacket"..right?

When I place a call to print out the packet just before starting with ARP like:

/* and do the ARP request */ NetArpWaitTry = 1; NetArpWaitTimerStart = get_timer(0); printf ("Ping packet filled...\n"); print_packet (NetArpWaitTxPacket, NetArpWaitTxPacketSize); ArpRequest(); return 1; /* waiting */

I get as a result (as also captured with ethereal):

Ping packet filled... Packet of length 42 0000 0000 0000 0280 ad20 31b8 0800 0000 0000 0000 0000 0000 0000 0a00 0404 0a00 0105 0000 0000 0000 0000

So only source MAC and PROT_IP as well as source/dest IP addresses are filled out correctly..rest is blank...

thanx in advance for hints (o; rick

richard＠uclinux.net

9:29 p.m.

New subject: [U-Boot-Users] PingSend

Strange...

Changing from:

int PingSend(void) { static uchar mac[6]; volatile IP_t *ip; volatile ushort *s; uchar *pkt;

to:

int PingSend(void) { static uchar mac[6]; IP_t *ip; ushort *s; uchar *pkt;

Solved the ping problem (o;

nice evening rick

...

Evening (o;

Something puzzed me today...(and still is ;o)

In "net/net.c" in function PingSend we fill out the ping packet to be sent later on after ARP reply, which is pointed to by "NetArpWaitTxPacket"..right?

When I place a call to print out the packet just before starting with ARP like:
/* and do the ARP request */
NetArpWaitTry = 1;
NetArpWaitTimerStart = get_timer(0);
printf ("Ping packet filled...\n");
print_packet (NetArpWaitTxPacket, NetArpWaitTxPacketSize);
ArpRequest();
return 1;   /* waiting */
I get as a result (as also captured with ethereal):

Ping packet filled... Packet of length 42 0000 0000 0000 0280 ad20 31b8 0800 0000 0000 0000 0000 0000 0000 0a00 0404 0a00 0105 0000 0000 0000 0000

So only source MAC and PROT_IP as well as source/dest IP addresses are filled out correctly..rest is blank...

thanx in advance for hints (o; rick

This SF.Net email is sponsored by: NEC IT Guy Games. How far can you shotput a projector? How fast can you ride your desk chair down the office luge track? If you want to score the big prize, get to know the little guy. Play to win an NEC 61" plasma display: http://www.necitguy.com/?r _______________________________________________ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users

Wolfgang Denk

9:59 p.m.

New subject: [U-Boot-Users] PingSend

In message <r02010500-1041-E8859113D52E11D9ABA900039387ACB6@[10.0.1.1]> you wrote:

...

Changing from:

...

volatile IP_t *ip;
volatile ushort *s;

...

to:

...

IP_t *ip;
ushort *s;

...

Solved the ping problem (o;

Masked, not solved. Broken toolchain ?

Best regards,

Wolfgang Denk

-- Software Engineering: Embedded and Realtime Systems, Embedded Linux Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de G's Third Law: In spite of all evidence to the contra- ry, the entire universe is composed of only two basic substances: magic and bullshit. H's Dictum: There is no magic ...

richard＠uclinux.net

10:39 p.m.

New subject: [U-Boot-Users] PingSend

...

In message <r02010500-1041-E8859113D52E11D9ABA900039387ACB6@[10.0.1.1]> you wrote:

...
Changing from:

....

...
volatile IP_t *ip;
volatile ushort *s;
....

...
to:

....

...
IP_t *ip;
ushort *s;
....

...
Solved the ping problem (o;

Masked, not solved. Broken toolchain ?

What I thought as well...think it is the ARCtangent A4 CPU which behaves abnormal when using load/store instruction bypassing cache on SDRAM...

It generates correctly stb.di/stw.di instruction with "volatile" keyword...which are needed and work for periphals like on-chip UART...

best regards rick

7277

Age (days ago)

7279

Last active (days ago)

List overview

Download

9 comments

4 participants

tags (0)

participants (4)

Jerry Van Baren
Peter Asemann
richard＠uclinux.net
Wolfgang Denk