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.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
