All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jason Rush <jarush@gmail.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] SoCFPGA PL330 DMA driver and ECC scrubbing
Date: Wed, 11 Jul 2018 08:56:41 -0500	[thread overview]
Message-ID: <efa66d89-25b3-5109-3722-c74eea18a950@gmail.com> (raw)
In-Reply-To: <9ba3d878-7783-30a8-d1ac-1085b89da393@denx.de>

On 7/11/2018 8:48 AM, Marek Vasut wrote:
> On 07/11/2018 03:49 PM, Jason Rush wrote:
>> On 7/11/2018 3:55 AM, Marek Vasut wrote:
>>> On 07/11/2018 05:11 AM, Jason Rush wrote:
>>> [...]
>>>
>>>>>>>> However, if I press the HPS_RST push button on the SoCKit (which is connected
>>>>>>>> to power on reset), occasionally U-Boot will lock up while booting.  It always
>>>>>>>> boots and operates correctly from the initial power on, but it almost always
>>>>>>>> fails to boot after pressing the HPS_RST button.
>>>>>>>>
>>>>>>>> Usually after pressing the HPS_RST button, U-Boot makes it past the SPL, and
>>>>>>>> hangs somewhere after the call to setup_reloc() in ./common/board_f.c.  Once
>>>>>>>> it hangs there, pressing the HPS_RST button again usually causes the SPL to
>>>>>>>> hang while setting up the MMU (before my call to memset).  Eventually the
>>>>>>>> WDT kicks in, and it just keeps hanging up in the same place.  Once it gets in
>>>>>>>> this mode, the only way to recover it is by toggling power on the board.
>>>>>>>>
>>>>>>>> I spent a bunch of time today trying to track down where it was hanging, but
>>>>>>>> I couldn't pin point anything.  The MMU tables looked correct.  The MMU
>>>>>>>> registers looked good.  I'm not sure the best way to debug what's going on.
>>>>>>> Try triggering warm reset and cold reset via the reset register:
>>>>>>>
>>>>>>> mw 0xffd05004 1
>>>>>>> mw 0xffd05004 2
>>>>>>>
>>>>>>> Does it hang in one case and not in the other ?
>>>>>>>
>>>>>> It hangs in both cases.
>>>>>>
>>>>>> I did find that if I do not metset the last 1MiB of DRAM with the cache on,
>>>>>> both warm and cold resets work.
>>>>>>
>>>>>> I changed the ecc scrubbing to zero out the first 0x8000 bytes and the last
>>>>>> 0x10000 bytes before the MMU is setup and I enable dcache.  Then with
>>>>>> the dcache enabled, I zero out the rest of memory.  The resets work in this
>>>>>> case as well.  So there seems to be some side effect of clearing out the
>>>>>> relocate address space with the cache on.
>>>>> Can you investigate ?
>>>>>
>>>> I'd be happy to investigate more, but I'm not really sure what
>>>> my next step should be.
>>>>
>>>> Something appears to be happening differently when U-Boot
>>>> relocates if the dcache is on.  But don't know how to track it
>>>> down.
>>> IIRC I disabled cache after scrubbing.
>> My mistake.  I did disable the dcache after scrubbing too.  The
>> code is almost identical to the Arria10 code where after
>> scrubbing it flushes the dcache, then turns it off.
>>
>> The weird reset problems happens if I scrub the area where
>> u-boot relocates to with the dcache on, then turn dcache off.
>>
>> I tried to also tried turning the MMU off, but that didn't help.
> Maybe there are some data used by the SPL there ? I think the SPL has
> malloc area in RAM at some point.
>
I thought something similar, so I narrowed it down to clearing
just from where U-Boot relocates to the end of DRAM.  If I'm
correct, that includes where U-Boot relocates and where the
MMU tables are normally stored.

  reply	other threads:[~2018-07-11 13:56 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-06-29 14:31 [U-Boot] SoCFPGA PL330 DMA driver and ECC scrubbing Jason Rush
2018-06-29 14:34 ` Marek Vasut
2018-06-29 14:44   ` Jason Rush
2018-06-29 14:52     ` Marek Vasut
2018-06-29 15:06       ` Jason Rush
2018-06-29 15:17         ` Marek Vasut
2018-07-03 13:58           ` Jason Rush
2018-07-03 14:08             ` Marek Vasut
2018-07-03 23:45               ` Jason Rush
2018-07-04  7:23                 ` Marek Vasut
2018-07-05 23:11                   ` Jason Rush
2018-07-05 23:10                     ` Marek Vasut
2018-07-05 23:28                       ` Jason Rush
2018-07-06 22:56                       ` Jason Rush
2018-07-09  8:08                         ` Marek Vasut
2018-07-10 12:10                           ` Jason Rush
2018-07-10 16:11                             ` Marek Vasut
2018-07-11  3:11                               ` Jason Rush
2018-07-11  8:55                                 ` Marek Vasut
2018-07-11 13:49                                   ` Jason Rush
2018-07-11 13:48                                     ` Marek Vasut
2018-07-11 13:56                                       ` Jason Rush [this message]
2018-07-11 14:05                                         ` Marek Vasut
2018-07-11 17:30                                         ` Trent Piepho
2018-07-11 18:54                                           ` Marek Vasut
2018-07-13 12:50                                             ` Jason Rush
2018-07-13 14:54                                               ` Marek Vasut

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=efa66d89-25b3-5109-3722-c74eea18a950@gmail.com \
    --to=jarush@gmail.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.