Re: [U-Boot-Users] Wind River SBC8560 saga continues
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@mintera.com -- and destroy all copies of this message and any attachments. Thank you.
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%^*-.
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@mintera.com -- and destroy all copies of this message and any attachments. Thank you.
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,0xff79x: 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
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@mintera.com -- and destroy all copies of this message and any attachments. Thank you.
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
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@mintera.com -- and destroy all copies of this message and any attachments. Thank you.
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,0xff79x: 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
Hi Andy.
It is this second "while" that is "hanging". The generated code for the while is:
lis R9,0xff79x: 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@mintera.com -- and destroy all copies of this message and any attachments. Thank you.
participants (4)
-
Andy Fleming -
Jerry Van Baren -
Jerry Van Baren -
Mark Pilant