All of lore.kernel.org
 help / color / mirror / Atom feed
From: Scott Wood <scottwood@freescale.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH 2/4][v2] powerpc/85xx:Fix MSR[DE] bit in MSR to	support debugger
Date: Wed, 25 Apr 2012 13:59:22 -0500	[thread overview]
Message-ID: <4F98498A.3090903@freescale.com> (raw)
In-Reply-To: <OFABD734E5.4B7D70D2-ONC12579EB.00671C76-C12579EB.00680042@transmode.se>

On 04/25/2012 01:55 PM, Joakim Tjernlund wrote:
> 
> Scott Wood <scottwood@freescale.com> wrote on 2012/04/25 20:43:22:
>>
>> On 04/25/2012 05:57 AM, Joakim Tjernlund wrote:
>>>>
>>>> Debugging of e500 and e500v1 processer requires MSR[DE] bit to be set always.
>>>> Where MSR = Machine State register
>>>>
>>>> Make sure of MSR[DE] bit is set uniformaly across the different execution
>>>> address space i.e. AS0 and AS1.
>>>
>>> Hi
>>>
>>> We are trying to bring up our custom P2010 RDB based board. boot is NOR
>>> based and we cannot get past the rfi below.
>>>    lis   r6,MSR_IS|MSR_DS at h
>>>    ori   r6,r6,MSR_IS|MSR_DS at l
>>>    lis   r7,switch_as at h
>>>    ori   r7,r7,switch_as at l
>>>
>>>    mtspr   SPRN_SRR0,r7
>>>    mtspr   SPRN_SRR1,r6
>>>    rfi
>>>
>>> switch_as:
>>>
>>> We end up with a TLB exception no matter what we do, even after applying this patch.
>>
>> Did you apply the entire patchset, and define CONFIG_SYS_PPC_E500_DEBUG_TLB?
> 
> No, but this code is executed before any of the other parts of the patch. Anyhow, I just
> found the problem(really obvious once I found it).
> During bring up we had to load uboot in the middle of the flash instead of
> the end because we have a flash burn problem in the end of the flash that we do not
> understand yet. We think it may be related to DDR3 being misconfigured by the emulator(BDI3000).
> I do not understand why this emulator can not use the L2SRAM instead? Is there something
> magic behind the L2SRAM so it is impossible to use it as a work area for
> flash burning?

I don't know of any reason L2SRAM couldn't be used for this.  My guess
is they just don't want to have to support more than one way of creating
RAM.

-Scott

  reply	other threads:[~2012-04-25 18:59 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-04-25  8:25 [U-Boot] [PATCH 2/4][v2] powerpc/85xx:Fix MSR[DE] bit in MSR to support debugger Prabhakar Kushwaha
2012-04-25 10:57 ` Joakim Tjernlund
2012-04-25 18:43   ` Scott Wood
2012-04-25 18:55     ` Joakim Tjernlund
2012-04-25 18:59       ` Scott Wood [this message]
2012-04-26  7:01         ` Joakim Tjernlund
  -- strict thread matches above, loose matches on Subject: below --
2012-04-30  9:56 Prabhakar Kushwaha
2012-03-26  9:00 Prabhakar Kushwaha
2012-03-21  4:42 Prabhakar Kushwaha

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=4F98498A.3090903@freescale.com \
    --to=scottwood@freescale.com \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.