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

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

[Peter Asemann]

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

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

[Wolfgang Denk]

In message <429F1E26.1010508@web.de> you wrote:
> 
> 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 

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 at denx.de
There are three things I always forget. Names, faces -  the  third  I
can't remember.                                         - Italo Svevo

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

[Jerry Van Baren]

Wolfgang Denk wrote:
> In message <429F1E26.1010508@web.de> you wrote:
> 
>>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 
> 
> 
> 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

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

[Peter Asemann]

Hi there!

>>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 
> 
> 
> 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

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

[Wolfgang Denk]

In message <42A060DE.4010000@web.de> you wrote:
> 
> 2. 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 at denx.de
People with narrow minds usually have broad tongues.

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

[Peter Asemann]

> 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

[U-Boot-Users] PingSend

[richard at uclinux.net]

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

[U-Boot-Users] PingSend

[richard at uclinux.net]

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 at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/u-boot-users
> 

[U-Boot-Users] PingSend

[Wolfgang Denk]

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 at 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 ...

[U-Boot-Users] PingSend

[richard at uclinux.net]

> 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