All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jeroen Hofstee <jeroen@myspectrum.nl>
To: Paul Walmsley <paul@pwsan.com>,
	Jeroen Hofstee <linux-arm@myspectrum.nl>,
	"menon.nishanth@gmail.com" <menon.nishanth@gmail.com>
Cc: Tony Lindgren <tony@atomide.com>, Tero Kristo <t-kristo@ti.com>,
	linux-omap@vger.kernel.org, linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH] ARM: dts: AM35xx: fix system control module clocks
Date: Tue, 09 Jun 2015 00:00:20 +0200	[thread overview]
Message-ID: <55761074.2080109@myspectrum.nl> (raw)
In-Reply-To: <alpine.DEB.2.02.1506080234271.15153@utopia.booyaka.com>

Hello Paul, +Menon (since you asked about the USB_OTG trap),

On 08-06-15 04:38, Paul Walmsley wrote:
> Hi Jeroen,
>
> On Sun, 7 Jun 2015, Paul Walmsley wrote:
>
>> On Sun, 7 Jun 2015, Jeroen Hofstee wrote:
>>
>>>
>>> Turns out my suspicion was wrong. This is what I know at the moment,
>>> depending on the bootpins, u-boot will trigger a bad access when loading
>>> a file over ethernet, but only the first time. Clearing the pending interrupt
>>> before booting linux make the "USB_OTG address hole seen" go away.
>> Oh, too bad.  I had been hoping that you were right and that I was wrong
>> ;-)  I'll try this on the CM-T3517 here.
> I used your debugging technique here and was able to reproduce your
> results - with one difference:
>
> http://www.pwsan.com/omap/testlogs/test_v4.1-rc6/20150607194102/boot/cmt3517/cmt3517_log.txt
>
> The interconnect error was logged upon the first interaction with the
> network.  In my case this was with the U-boot 'dhcp' command.  The pending
> interrupt bit was cleared before loading the kernel via tftp, and the
> interrupt bit was not set again, even after a tftp load.
>

I sent a patch to u-boot to disable the offending line, see [1]. It would be
interesting to know if it can also result in valid, accidental memory 
adjustments,
before the invalid one, but I haven't checked that yet.

Regards,
Jeroen

[1] https://patchwork.ozlabs.org/patch/481751/

p.s. the USB_OTG trap is actually a musb / emac / camera trap on an am3517.

WARNING: multiple messages have this Message-ID (diff)
From: jeroen@myspectrum.nl (Jeroen Hofstee)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] ARM: dts: AM35xx: fix system control module clocks
Date: Tue, 09 Jun 2015 00:00:20 +0200	[thread overview]
Message-ID: <55761074.2080109@myspectrum.nl> (raw)
In-Reply-To: <alpine.DEB.2.02.1506080234271.15153@utopia.booyaka.com>

Hello Paul, +Menon (since you asked about the USB_OTG trap),

On 08-06-15 04:38, Paul Walmsley wrote:
> Hi Jeroen,
>
> On Sun, 7 Jun 2015, Paul Walmsley wrote:
>
>> On Sun, 7 Jun 2015, Jeroen Hofstee wrote:
>>
>>>
>>> Turns out my suspicion was wrong. This is what I know at the moment,
>>> depending on the bootpins, u-boot will trigger a bad access when loading
>>> a file over ethernet, but only the first time. Clearing the pending interrupt
>>> before booting linux make the "USB_OTG address hole seen" go away.
>> Oh, too bad.  I had been hoping that you were right and that I was wrong
>> ;-)  I'll try this on the CM-T3517 here.
> I used your debugging technique here and was able to reproduce your
> results - with one difference:
>
> http://www.pwsan.com/omap/testlogs/test_v4.1-rc6/20150607194102/boot/cmt3517/cmt3517_log.txt
>
> The interconnect error was logged upon the first interaction with the
> network.  In my case this was with the U-boot 'dhcp' command.  The pending
> interrupt bit was cleared before loading the kernel via tftp, and the
> interrupt bit was not set again, even after a tftp load.
>

I sent a patch to u-boot to disable the offending line, see [1]. It would be
interesting to know if it can also result in valid, accidental memory 
adjustments,
before the invalid one, but I haven't checked that yet.

Regards,
Jeroen

[1] https://patchwork.ozlabs.org/patch/481751/

p.s. the USB_OTG trap is actually a musb / emac / camera trap on an am3517.

  reply	other threads:[~2015-06-08 22:00 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-05-30 15:50 OMAP baseline test results for v4.1-rc5 Paul Walmsley
2015-05-30 15:50 ` Paul Walmsley
2015-05-30 15:56 ` Jeroen Hofstee
2015-05-30 15:56   ` Jeroen Hofstee
2015-05-31 22:15   ` Jeroen Hofstee
2015-05-31 22:15     ` Jeroen Hofstee
2015-06-01  5:49     ` Paul Walmsley
2015-06-01  5:49       ` Paul Walmsley
2015-06-01 15:29       ` Tero Kristo
2015-06-01 15:29         ` Tero Kristo
2015-06-01 15:30       ` [PATCH] ARM: dts: AM35xx: fix system control module clocks Tero Kristo
2015-06-01 15:30         ` Tero Kristo
2015-06-01 16:56         ` Jeroen Hofstee
2015-06-01 16:56           ` Jeroen Hofstee
2015-06-01 17:31           ` Tony Lindgren
2015-06-01 17:31             ` Tony Lindgren
2015-06-01 17:44             ` Paul Walmsley
2015-06-01 17:44               ` Paul Walmsley
2015-06-01 18:04               ` Tony Lindgren
2015-06-01 18:04                 ` Tony Lindgren
2015-06-01 18:06                 ` Tony Lindgren
2015-06-01 18:06                   ` Tony Lindgren
2015-06-01 21:26                   ` Paul Walmsley
2015-06-01 21:26                     ` Paul Walmsley
2015-06-02  7:15                     ` Tero Kristo
2015-06-02  7:15                       ` Tero Kristo
2015-06-01 21:21                 ` Paul Walmsley
2015-06-01 21:21                   ` Paul Walmsley
2015-06-01 18:04               ` Tero Kristo
2015-06-01 18:04                 ` Tero Kristo
2015-06-05  8:01               ` Jeroen Hofstee
2015-06-05  8:01                 ` Jeroen Hofstee
2015-06-05  8:04                 ` Jeroen Hofstee
2015-06-05  8:04                   ` Jeroen Hofstee
2015-06-07  9:41                   ` Jeroen Hofstee
2015-06-07  9:41                     ` Jeroen Hofstee
2015-06-07 19:56                     ` Paul Walmsley
2015-06-07 19:56                       ` Paul Walmsley
2015-06-08  2:38                       ` Paul Walmsley
2015-06-08  2:38                         ` Paul Walmsley
2015-06-08 22:00                         ` Jeroen Hofstee [this message]
2015-06-08 22:00                           ` Jeroen Hofstee
2015-06-08 21:43                       ` Jeroen Hofstee
2015-06-08 21:43                         ` Jeroen Hofstee

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=55761074.2080109@myspectrum.nl \
    --to=jeroen@myspectrum.nl \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-arm@myspectrum.nl \
    --cc=linux-omap@vger.kernel.org \
    --cc=menon.nishanth@gmail.com \
    --cc=paul@pwsan.com \
    --cc=t-kristo@ti.com \
    --cc=tony@atomide.com \
    /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.