[U-Boot-Users] Wind River SBC8560 saga continues

[U-Boot-Users] Wind River SBC8560 saga continues

[Mark Pilant]

The more I dig into my problem, the more confused I get.

Here is the latest plot twist...

Looking at the sources for the memory configuration:

  /opt/eldk/ppc_85xx/usr/src/u-boot-1.2.0/board/sbc8560/init.S
  /opt/eldk/ppc_85xx/usr/src/u-boot-1.2.0/cpu/mpc85xx/start.S
  /opt/eldk/ppc_85xx/usr/src/u-boot-1.2.0/include/configs/sbc8560.h

I notice the TLB entries seem to be set up to do a simple straight
mapping from the effective address to the real address.  No problem
so far.

Looking further, I notice the addresses used for the chip select
values do not match the addresses specified in the SBC8560 board
engineering specifications.  Now it is getting a little confusing.

Finally, I notice there is one area of memory, defined at 0x70000000,
which has a TLB but does not appear to have any real memory to back
it up.  (This address is associated with the CFG_INIT_RAM_ADDR
defined symbol.)

I am hoping someone might be able to point out if I am missing
something (subtle or obvious :-).

I had thought this might be the source of the CPM SCC problem I
am having, but so far it does not seem to be the case.

Thanks in advance.

- Mark (the confused :-)

This email message and any attachments are confidential and may contain information which is proprietary to Mintera Corporation. If you are not the intended recipient, please notify Mintera Corporation immediately -- by replying to this message or by sending an email to postmaster at mintera.com -- and destroy all copies of this message and any attachments. Thank you.

[U-Boot-Users] Wind River SBC8560 saga continues

[Mark Pilant]

Hi Andy.

>>
>> Finally, I notice there is one area of memory, defined at 0x70000000,
>> which has a TLB but does not appear to have any real memory to back
>> it up.  (This address is associated with the CFG_INIT_RAM_ADDR
>> defined symbol.)
>
>This is just the initial area to store stuff before RAM is actually
>set up.  It has to be somewhere with nothing behind it so it will just
>stay in the cache.  Most 85xx systems use 0xe4010000.  However, once
>RAM is set up, this address loses its meaning

OK.  That sounds reasonable, although I haven't run across this before.

>>
>> I am hoping someone might be able to point out if I am missing
>> something (subtle or obvious :-).
>>
>> I had thought this might be the source of the CPM SCC problem I
>> am having, but so far it does not seem to be the case.
>
>I don't recall seeing the email about  your problem.  Could you
>redescribe it?

Simply put, I'm trying to get U-Boot 1.2.0 compiled and running on
a Wind River SBC8560 board we have.  From what I saw of the '8560
support in general and the SBC8560 in particular, I thought it would
be relatively simple.

After setting up the ELDK on a Fedora Core 6 system I have, I was able
to make a couple of changes to sbc8560.h (mostly to use SCC1 for the
console) and build an image.

Loading the image into flash (using WR visionCLICK) everything goes
along fine until the code attempts to initialize the CPM SCC Tx & Tx.
After writing the appropriate value to the proper location, the code
hangs waiting for the command to complete.

In reality, what appears to be happening is the code is reading one
value (0x00810000) from the CPM CPCR (0xff7919c0) and if I dump that
location using visionCLICK I see a different value (0x00800000).  The
difference being the code sees the busy FLG and dumping the location
has it clear; indicating it is no longer busy.

This feels a lot like a caching issue, but from everything I can see,
the TLB is set up with the cache inhibited, so everything should be
read/written through to memory.


I have been trying for about the past two weeks to sort this out and
get U-Boot up.  I'm not worried about the Linux kernel right now :-)

- Mark

This email message and any attachments are confidential and may contain information which is proprietary to Mintera Corporation. If you are not the intended recipient, please notify Mintera Corporation immediately -- by replying to this message or by sending an email to postmaster at mintera.com -- and destroy all copies of this message and any attachments. Thank you.

[U-Boot-Users] Wind River SBC8560 saga continues

[Jerry Van Baren]

Mark Pilant wrote:
> Hi Andy.
> 
>>> Finally, I notice there is one area of memory, defined at 0x70000000,
>>> which has a TLB but does not appear to have any real memory to back
>>> it up.  (This address is associated with the CFG_INIT_RAM_ADDR
>>> defined symbol.)
>> This is just the initial area to store stuff before RAM is actually
>> set up.  It has to be somewhere with nothing behind it so it will just
>> stay in the cache.  Most 85xx systems use 0xe4010000.  However, once
>> RAM is set up, this address loses its meaning
> 
> OK.  That sounds reasonable, although I haven't run across this before.
> 
>>> I am hoping someone might be able to point out if I am missing
>>> something (subtle or obvious :-).
>>>
>>> I had thought this might be the source of the CPM SCC problem I
>>> am having, but so far it does not seem to be the case.
>> I don't recall seeing the email about  your problem.  Could you
>> redescribe it?
> 
> Simply put, I'm trying to get U-Boot 1.2.0 compiled and running on
> a Wind River SBC8560 board we have.  From what I saw of the '8560
> support in general and the SBC8560 in particular, I thought it would
> be relatively simple.
> 
> After setting up the ELDK on a Fedora Core 6 system I have, I was able
> to make a couple of changes to sbc8560.h (mostly to use SCC1 for the
> console) and build an image.
> 
> Loading the image into flash (using WR visionCLICK) everything goes
> along fine until the code attempts to initialize the CPM SCC Tx & Tx.
> After writing the appropriate value to the proper location, the code
> hangs waiting for the command to complete.
> 
> In reality, what appears to be happening is the code is reading one
> value (0x00810000) from the CPM CPCR (0xff7919c0) and if I dump that
> location using visionCLICK I see a different value (0x00800000).  The
> difference being the code sees the busy FLG and dumping the location
> has it clear; indicating it is no longer busy.
> 
> This feels a lot like a caching issue, but from everything I can see,
> the TLB is set up with the cache inhibited, so everything should be
> read/written through to memory.

Another possibility is that the register is missing the "volatile" 
qualifier and thus the compiler is not re-reading the register every 
time around the loop.  If this is a possiblility, disassemble the 
routine and see what the compiler actually produced.

> I have been trying for about the past two weeks to sort this out and
> get U-Boot up.  I'm not worried about the Linux kernel right now :-)
> 
> - Mark

Good luck,
gvb

Due to idiotic lawyer wanabes, in one second this email will self-destr%^*-.

[U-Boot-Users] Wind River SBC8560 saga continues

[Mark Pilant]

>> Simply put, I'm trying to get U-Boot 1.2.0 compiled and running on
>> a Wind River SBC8560 board we have.  From what I saw of the '8560
>> support in general and the SBC8560 in particular, I thought it would
>> be relatively simple.
>> 
>> After setting up the ELDK on a Fedora Core 6 system I have, I was able
>> to make a couple of changes to sbc8560.h (mostly to use SCC1 for the
>> console) and build an image.
>> 
>> Loading the image into flash (using WR visionCLICK) everything goes
>> along fine until the code attempts to initialize the CPM SCC Tx & Tx.
>> After writing the appropriate value to the proper location, the code
>> hangs waiting for the command to complete.
>> 
>> In reality, what appears to be happening is the code is reading one
>> value (0x00810000) from the CPM CPCR (0xff7919c0) and if I dump that
>> location using visionCLICK I see a different value (0x00800000).  The
>> difference being the code sees the busy FLG and dumping the location
>> has it clear; indicating it is no longer busy.
>> 
>> This feels a lot like a caching issue, but from everything I can see,
>> the TLB is set up with the cache inhibited, so everything should be
>> read/written through to memory.
>
>Another possibility is that the register is missing the "volatile" 
>qualifier and thus the compiler is not re-reading the register every 
>time around the loop.  If this is a possiblility, disassemble the 
>routine and see what the compiler actually produced.

The code is stock U-Boot 1.2.0.  In serial_init() from the module
.../cpu/mpc85xx/serial_scc.c, the code reads:

    volatile immap_t *im = (immap_t *)CFG_IMMR;
    ...
    volatile ccsr_cpm_cp_t *cp = &(im->im_cpm.im_cpm_cp);

    ...

    while (cp->cpcr & CPM_CR_FLG)  /* wait if cp is busy */

It is this second "while" that is "hanging".  The generated code for
the while is:

    lis     R9,0xff79
x:  lwz     R0,0x19c0(R9)
    andis.  R11,r0,0x1
    bne     x

R9 correctly contains the CPM base, and the offset 0x19c0 is correct
for the CPCR.  So it would appear the code should be picking up the
contents of location 0xff7919c0.  Here is where the fun begins.  The
value retrieved by the code (into R0) is 0x00810000 but the value
retrieved by the visionCLICK dm command is 00800000.  (This is also
the value displayed by the CPCR field of the "COMM" register list.

I have verified the TLBs, and they correctly have cache inhibit set,
so I can't see why this "wrong" value is being retrieved.

BTW, this same board works fine running V6.3 of VxWorks; which I also
compiled and flashed.

- Mark

This email message and any attachments are confidential and may contain information which is proprietary to Mintera Corporation. If you are not the intended recipient, please notify Mintera Corporation immediately -- by replying to this message or by sending an email to postmaster at mintera.com -- and destroy all copies of this message and any attachments. Thank you.

[U-Boot-Users] Wind River SBC8560 saga continues

[Jerry Van Baren]

Mark Pilant wrote:
>>> Simply put, I'm trying to get U-Boot 1.2.0 compiled and running on
>>> a Wind River SBC8560 board we have.  From what I saw of the '8560
>>> support in general and the SBC8560 in particular, I thought it would
>>> be relatively simple.
>>>
>>> After setting up the ELDK on a Fedora Core 6 system I have, I was able
>>> to make a couple of changes to sbc8560.h (mostly to use SCC1 for the
>>> console) and build an image.
>>>
>>> Loading the image into flash (using WR visionCLICK) everything goes
>>> along fine until the code attempts to initialize the CPM SCC Tx & Tx.
>>> After writing the appropriate value to the proper location, the code
>>> hangs waiting for the command to complete.
>>>
>>> In reality, what appears to be happening is the code is reading one
>>> value (0x00810000) from the CPM CPCR (0xff7919c0) and if I dump that
>>> location using visionCLICK I see a different value (0x00800000).  The
>>> difference being the code sees the busy FLG and dumping the location
>>> has it clear; indicating it is no longer busy.
>>>
>>> This feels a lot like a caching issue, but from everything I can see,
>>> the TLB is set up with the cache inhibited, so everything should be
>>> read/written through to memory.
>> Another possibility is that the register is missing the "volatile" 
>> qualifier and thus the compiler is not re-reading the register every 
>> time around the loop.  If this is a possiblility, disassemble the 
>> routine and see what the compiler actually produced.
> 
> The code is stock U-Boot 1.2.0.  In serial_init() from the module
> .../cpu/mpc85xx/serial_scc.c, the code reads:
> 
>     volatile immap_t *im = (immap_t *)CFG_IMMR;
>     ...
>     volatile ccsr_cpm_cp_t *cp = &(im->im_cpm.im_cpm_cp);
> 
>     ...
> 
>     while (cp->cpcr & CPM_CR_FLG)  /* wait if cp is busy */
> 
> It is this second "while" that is "hanging".  The generated code for
> the while is:
> 
>     lis     R9,0xff79
> x:  lwz     R0,0x19c0(R9)
>     andis.  R11,r0,0x1
>     bne     x
> 
> R9 correctly contains the CPM base, and the offset 0x19c0 is correct
> for the CPCR.  So it would appear the code should be picking up the
> contents of location 0xff7919c0.  Here is where the fun begins.  The
> value retrieved by the code (into R0) is 0x00810000 but the value
> retrieved by the visionCLICK dm command is 00800000.  (This is also
> the value displayed by the CPCR field of the "COMM" register list.
> 
> I have verified the TLBs, and they correctly have cache inhibit set,
> so I can't see why this "wrong" value is being retrieved.
> 
> BTW, this same board works fine running V6.3 of VxWorks; which I also
> compiled and flashed.
> 
> - Mark

Ok, the good news is that eliminates one of the failure modes.  We 
eliminate enough of them and the real one will be obvious. ;-)  That was 
somewhat of a long shot, so it isn't too surprising that it wasn't the 
fault.

I'm not familiar with the 85xx processors, I presume they have BAT 
registers like most 8xxx family.  Is it possible the memory is mapped 
via a BAT and _that_ is set up wrong (cached and/or doesn't have the "G" 
bit set)?  BATs override the TLBs.

Does the TLB have the "G" (Guarded) bit set?  That prevents out-of-order 
loading (probably not an issue, but something to check).

How about hitting it with da big hammer: put a sync;isync pair in the 
loop.  If that makes it better, remove the isync (should not be 
necessary).  If that still works, try using a eieio instead of the sync 
(I'm not sure if eieio is useful for the 85xx, on the 603e core, it is a 
NOP).

Good luck,
gvb

[U-Boot-Users] Wind River SBC8560 saga continues

[Mark Pilant]

Hi Jerry.

> Ok, the good news is that eliminates one of the failure modes.  We 
> eliminate enough of them and the real one will be obvious. ;-)  That was 
> somewhat of a long shot, so it isn't too surprising that it wasn't the 
> fault.

:-)

> I'm not familiar with the 85xx processors, I presume they have BAT 
> registers like most 8xxx family.  Is it possible the memory is mapped 
> via a BAT and _that_ is set up wrong (cached and/or doesn't have the "G" 
> bit set)?  BATs override the TLBs.

I just checked, because I wasn't sure, and according to the Reference
Manual, the e500 core (e.g, the 8560) does not implement the BAT registers.

> Does the TLB have the "G" (Guarded) bit set?  That prevents out-of-order 
> loading (probably not an issue, but something to check).

Yes, the guarded bit is set in .../board/sbc8560/init.S.

> How about hitting it with da big hammer: put a sync;isync pair in the 
> loop.  If that makes it better, remove the isync (should not be 
> necessary).  If that still works, try using a eieio instead of the sync 
> (I'm not sure if eieio is useful for the 85xx, on the 603e core, it is a 
> NOP).

I thought I had tried this earlier, but couldn't remember.  So I tried
it again.  No Luck.  (The generated code does the sync/isync before the
register fetch.  If the FLG bit is still set, the sync/isync is done
again and the fetch repeated.)

According to the RM, the e500 replaces eieio with mbar.  Since I had not
tried that one, I just did.  You guessed it... no luck.


I'm probably doing something really stupid; and probably really simple
which is why I haven't spotted *my* problem.

It is also possible the WR SBC8560 we have is broken.  Although I think
that is not a really likely because it runs the VxWorks bootloader fine.

- Mark

This email message and any attachments are confidential and may contain information which is proprietary to Mintera Corporation. If you are not the intended recipient, please notify Mintera Corporation immediately -- by replying to this message or by sending an email to postmaster at mintera.com -- and destroy all copies of this message and any attachments. Thank you.

[U-Boot-Users] Wind River SBC8560 saga continues

[Jerry Van Baren]

Mark Pilant wrote:
> Hi Jerry.

[snip]

>> Does the TLB have the "G" (Guarded) bit set?  That prevents out-of-order 
>> loading (probably not an issue, but something to check).
> 
> Yes, the guarded bit is set in .../board/sbc8560/init.S.
> 
>> How about hitting it with da big hammer: put a sync;isync pair in the 
>> loop.  If that makes it better, remove the isync (should not be 
>> necessary).  If that still works, try using a eieio instead of the sync 
>> (I'm not sure if eieio is useful for the 85xx, on the 603e core, it is a 
>> NOP).
> 
> I thought I had tried this earlier, but couldn't remember.  So I tried
> it again.  No Luck.  (The generated code does the sync/isync before the
> register fetch.  If the FLG bit is still set, the sync/isync is done
> again and the fetch repeated.)
> 
> According to the RM, the e500 replaces eieio with mbar.  Since I had not
> tried that one, I just did.  You guessed it... no luck.
> 
> I'm probably doing something really stupid; and probably really simple
> which is why I haven't spotted *my* problem.
> 
> It is also possible the WR SBC8560 we have is broken.  Although I think
> that is not a really likely because it runs the VxWorks bootloader fine.

VERY unlikely since this is just dealing with the scc which is all 
internal to the 85xx.

> - Mark

OK at the risk of insulting you, create the sync;isync version and load 
it into flash.  Now figure out the start address of the the routine and 
disassemble it with the visionICE.  Is the right stuff loaded?  Set a 
hardware breakpoint: is it being executed?

Trivia: the visionICE is using the fsl background debug mode which, I am 
sure, is not exactly the same method and path as the execution of code 
in the processor.  Having it work for the vICE doesn't say much other 
than the actual scc bit is working.  Somebody is feeding you stale data 
in the path the vICE /isn't/ using.

Grasping at straws (been burned before),
gvb

[U-Boot-Users] Wind River SBC8560 saga continues

[Mark Pilant]

>> I'm probably doing something really stupid; and probably really simple
>> which is why I haven't spotted *my* problem.
>> 
>> It is also possible the WR SBC8560 we have is broken.  Although I think
>> that is not a really likely because it runs the VxWorks bootloader fine.
>
> VERY unlikely since this is just dealing with the scc which is all 
> internal to the 85xx.

I have to agree it is unlikely.  But I am willing to consider just about
anything :-)

One thing I am  trying to do is locate a (binary or otherwise) version of
U-Boot already built for the WR SBC8560.  If I can locate a version I can
get to boot on our board, then it should be a simply matter to compare
what I'm doing with the one that works and find out what I've been doing
wrong.  So far, I haven't had any success with this approach.

> OK at the risk of insulting you, create the sync;isync version and load 
> it into flash.  Now figure out the start address of the the routine and 
> disassemble it with the visionICE.  Is the right stuff loaded?  Set a 
> hardware breakpoint: is it being executed?

Not to worry.  I've done my share of missing the obvious. :-) :-)

The assembly code fragments I gave were from the visionCLICK disassembler.
So I would tend to believe it is correct.

I have also set the HW breakpoint to verify the sync/isync/mbar were being
executed before the CPCR register fetch.

> Trivia: the visionICE is using the fsl background debug mode which, I am 
> sure, is not exactly the same method and path as the execution of code 
> in the processor.  Having it work for the vICE doesn't say much other 
> than the actual scc bit is working.  Somebody is feeding you stale data 
> in the path the vICE /isn't/ using.

Good to know.

> Grasping at straws (been burned before),

I'm glad to have the company.  I'm running out of straws :-)


BTW, I have a query into Freescale to see if they have any ideas as to
what might be going on.  No response as yet.

- Mark

This email message and any attachments are confidential and may contain information which is proprietary to Mintera Corporation. If you are not the intended recipient, please notify Mintera Corporation immediately -- by replying to this message or by sending an email to postmaster at mintera.com -- and destroy all copies of this message and any attachments. Thank you.

[U-Boot-Users] Wind River SBC8560 saga continues

[Andy Fleming]

On 5/4/07, Mark Pilant <Mark.Pilant@mintera.com> wrote:
>     while (cp->cpcr & CPM_CR_FLG)  /* wait if cp is busy */
>
> It is this second "while" that is "hanging".  The generated code for
> the while is:
>
>     lis     R9,0xff79
> x:  lwz     R0,0x19c0(R9)
>     andis.  R11,r0,0x1
>     bne     x
>
> R9 correctly contains the CPM base, and the offset 0x19c0 is correct
> for the CPCR.  So it would appear the code should be picking up the
> contents of location 0xff7919c0.  Here is where the fun begins.  The
> value retrieved by the code (into R0) is 0x00810000 but the value
> retrieved by the visionCLICK dm command is 00800000.  (This is also
> the value displayed by the CPCR field of the "COMM" register list.


Very strange.  Have you double-checked the LAWs to make sure the CCSR
space is properly configured?  And checked CCSRBAR to make sure that
it's still *at* 0xff700000?

Also, is it possible the difference is due to a time delay between the
CPU reading the memory and visionCLICK reading it?

Andy

[U-Boot-Users] Wind River SBC8560 saga continues

[Mark Pilant]

Hi Andy.

>> It is this second "while" that is "hanging".  The generated code for
>> the while is:
>>
>>     lis     R9,0xff79
>> x:  lwz     R0,0x19c0(R9)
>>     andis.  R11,r0,0x1
>>     bne     x
>>
>> R9 correctly contains the CPM base, and the offset 0x19c0 is correct
>> for the CPCR.  So it would appear the code should be picking up the
>> contents of location 0xff7919c0.  Here is where the fun begins.  The
>> value retrieved by the code (into R0) is 0x00810000 but the value
>> retrieved by the visionCLICK dm command is 00800000.  (This is also
>> the value displayed by the CPCR field of the "COMM" register list.
>
>Very strange.  Have you double-checked the LAWs to make sure the CCSR
>space is properly configured?  And checked CCSRBAR to make sure that
>it's still *at* 0xff700000?

I have not.  One reason for using the stock U-Boot code with our SBC8560
is I was making the assumption it would be relatively easy to get it up
and running, because it had already been done.

It is always possible something got broken between the time it was
working and now, but I would not put it real high on my list of possible
suspects.

The one thing which I have tried it to do a simple CPM reset.  This, by
looking at the registers, does seem to work find.  So it would seem the
CPM is working and being addressed correctly.

>Also, is it possible the difference is due to a time delay between the
>CPU reading the memory and visionCLICK reading it?

Possible.  Although I would expect time timing to be similar having
visionCLICK display the contents and single stepping through the code
with visionCLICK.


All of this is very strange; and frustrating.

- Mark

This email message and any attachments are confidential and may contain information which is proprietary to Mintera Corporation. If you are not the intended recipient, please notify Mintera Corporation immediately -- by replying to this message or by sending an email to postmaster at mintera.com -- and destroy all copies of this message and any attachments. Thank you.