ARM: dts: AM35xx: fix system control module clocks
diff mbox

Message ID 1433172627-28052-1-git-send-email-t-kristo@ti.com
State New
Headers show

Commit Message

Tero Kristo June 1, 2015, 3:30 p.m. UTC
New system control module layout for omap3 overlooked parts of the am35xx
configuration. Basically the am35xx clocks were not converted to use the
changed offsets, which caused weird boot warnings. The errors were not
fatal so far, so they were not caught earlier. Fixed by applying the
proper offsets for the AM35xx scm clocks.

Fixes: b8845074cf ("ARM: dts: omap3: add minimal l4 bus layout with...")

Signed-off-by: Tero Kristo <t-kristo@ti.com>
Reported-by: Jeroen Hofstee <linux-arm@myspectrum.nl>
Cc: Paul Walmsley <paul@pwsan.com>
Cc: Tony Lindgren <tony@atomide.com>
---
 arch/arm/boot/dts/am35xx-clocks.dtsi |   14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

Comments

Jeroen Hofstee June 1, 2015, 4:56 p.m. UTC | #1
Hello Tero,

On 01-06-15 17:30, Tero Kristo wrote:
> New system control module layout for omap3 overlooked parts of the am35xx
> configuration. Basically the am35xx clocks were not converted to use the
> changed offsets, which caused weird boot warnings. The errors were not
> fatal so far, so they were not caught earlier. Fixed by applying the
> proper offsets for the AM35xx scm clocks.
>
> Fixes: b8845074cf ("ARM: dts: omap3: add minimal l4 bus layout with...")
>
> Signed-off-by: Tero Kristo <t-kristo@ti.com>
> Reported-by: Jeroen Hofstee <linux-arm@myspectrum.nl>
> Cc: Paul Walmsley <paul@pwsan.com>
> Cc: Tony Lindgren <tony@atomide.com>
> ---
>   arch/arm/boot/dts/am35xx-clocks.dtsi |   14 +++++++-------
>   1 file changed, 7 insertions(+), 7 deletions(-)
With this patch the error interrupt / stack dumps are no longer present.

Thanks,

Tested-by: Jeroen Hofstee <jeroen@myspectrum.nl>

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Tony Lindgren June 1, 2015, 5:31 p.m. UTC | #2
* Jeroen Hofstee <linux-arm@myspectrum.nl> [150601 09:58]:
> Hello Tero,
> 
> On 01-06-15 17:30, Tero Kristo wrote:
> >New system control module layout for omap3 overlooked parts of the am35xx
> >configuration. Basically the am35xx clocks were not converted to use the
> >changed offsets, which caused weird boot warnings. The errors were not
> >fatal so far, so they were not caught earlier. Fixed by applying the
> >proper offsets for the AM35xx scm clocks.
> >
> >Fixes: b8845074cf ("ARM: dts: omap3: add minimal l4 bus layout with...")
> >
> >Signed-off-by: Tero Kristo <t-kristo@ti.com>
> >Reported-by: Jeroen Hofstee <linux-arm@myspectrum.nl>
> >Cc: Paul Walmsley <paul@pwsan.com>
> >Cc: Tony Lindgren <tony@atomide.com>
> >---
> >  arch/arm/boot/dts/am35xx-clocks.dtsi |   14 +++++++-------
> >  1 file changed, 7 insertions(+), 7 deletions(-)
> With this patch the error interrupt / stack dumps are no longer present.
> 
> Thanks,
> 
> Tested-by: Jeroen Hofstee <jeroen@myspectrum.nl>

Thanks, I'm suprised this was not caught earlier with all the automated
boot testing going on?

Anyways, applying into omap-for-v4.1/fixes.

Regards,

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Paul Walmsley June 1, 2015, 5:44 p.m. UTC | #3
On Mon, 1 Jun 2015, Tony Lindgren wrote:

> * Jeroen Hofstee <linux-arm@myspectrum.nl> [150601 09:58]:
> > On 01-06-15 17:30, Tero Kristo wrote:
> > >New system control module layout for omap3 overlooked parts of the am35xx
> > >configuration. Basically the am35xx clocks were not converted to use the
> > >changed offsets, which caused weird boot warnings. The errors were not
> > >fatal so far, so they were not caught earlier. Fixed by applying the
> > >proper offsets for the AM35xx scm clocks.
> > >
> > >Fixes: b8845074cf ("ARM: dts: omap3: add minimal l4 bus layout with...")
> > >
> > >Signed-off-by: Tero Kristo <t-kristo@ti.com>
> > >Reported-by: Jeroen Hofstee <linux-arm@myspectrum.nl>
> > >Cc: Paul Walmsley <paul@pwsan.com>
> > >Cc: Tony Lindgren <tony@atomide.com>
> > >---
> > >  arch/arm/boot/dts/am35xx-clocks.dtsi |   14 +++++++-------
> > >  1 file changed, 7 insertions(+), 7 deletions(-)
> > With this patch the error interrupt / stack dumps are no longer present.
> > 
> > Thanks,
> > 
> > Tested-by: Jeroen Hofstee <jeroen@myspectrum.nl>
> 
> Thanks, I'm suprised this was not caught earlier with all the automated
> boot testing going on?

At least speaking in terms the testbed results that I post, the warnings 
get reported.  But not many people seem to act on them.  (Jeroen is a 
pleasant exception.)

See for example the "Build warnings from toolchain", "Kernel warnings 
during boot to userspace", "Kernel warnings during PM test", and "Obsolete 
Kconfig symbols" sections here:

http://www.pwsan.com/omap/testlogs/test_v4.1-rc6/20150601012139/README.txt


The best way to make this work IMHO would be for us not to accept any new 
feature addition patches as long as there are warnings reported in the 
test results.  The only real exception that I would foresee is if those 
warnings are due to something outside of our control, e.g., a crappy 
bootloader, as I suspect the USB_OTG initiator warnings are for the 
CM-T3517.


- Paul
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Tony Lindgren June 1, 2015, 6:04 p.m. UTC | #4
* Paul Walmsley <paul@pwsan.com> [150601 10:45]:
> On Mon, 1 Jun 2015, Tony Lindgren wrote:
> 
> > * Jeroen Hofstee <linux-arm@myspectrum.nl> [150601 09:58]:
> > > On 01-06-15 17:30, Tero Kristo wrote:
> > > >New system control module layout for omap3 overlooked parts of the am35xx
> > > >configuration. Basically the am35xx clocks were not converted to use the
> > > >changed offsets, which caused weird boot warnings. The errors were not
> > > >fatal so far, so they were not caught earlier. Fixed by applying the
> > > >proper offsets for the AM35xx scm clocks.
> > > >
> > > >Fixes: b8845074cf ("ARM: dts: omap3: add minimal l4 bus layout with...")
> > > >
> > > >Signed-off-by: Tero Kristo <t-kristo@ti.com>
> > > >Reported-by: Jeroen Hofstee <linux-arm@myspectrum.nl>
> > > >Cc: Paul Walmsley <paul@pwsan.com>
> > > >Cc: Tony Lindgren <tony@atomide.com>
> > > >---
> > > >  arch/arm/boot/dts/am35xx-clocks.dtsi |   14 +++++++-------
> > > >  1 file changed, 7 insertions(+), 7 deletions(-)
> > > With this patch the error interrupt / stack dumps are no longer present.
> > > 
> > > Thanks,
> > > 
> > > Tested-by: Jeroen Hofstee <jeroen@myspectrum.nl>
> > 
> > Thanks, I'm suprised this was not caught earlier with all the automated
> > boot testing going on?
> 
> At least speaking in terms the testbed results that I post, the warnings 
> get reported.  But not many people seem to act on them.  (Jeroen is a 
> pleasant exception.)
> 
> See for example the "Build warnings from toolchain", "Kernel warnings 
> during boot to userspace", "Kernel warnings during PM test", and "Obsolete 
> Kconfig symbols" sections here:
> 
> http://www.pwsan.com/omap/testlogs/test_v4.1-rc6/20150601012139/README.txt

OK somehow 3517evm is listed under "skip" there? 
 
> The best way to make this work IMHO would be for us not to accept any new 
> feature addition patches as long as there are warnings reported in the 
> test results.  The only real exception that I would foresee is if those 
> warnings are due to something outside of our control, e.g., a crappy 
> bootloader, as I suspect the USB_OTG initiator warnings are for the 
> CM-T3517.

Right. Also seems we should diff dmesg output too (after stripping out
the timestamps). Pretty much the only things that should change are
the sysfs paths for devices in the dmesg output unless some warnings
get fixed. That output probably still also needs to be manually looked
at though..

Regards,

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Tero Kristo June 1, 2015, 6:04 p.m. UTC | #5
On 06/01/2015 08:44 PM, Paul Walmsley wrote:
> On Mon, 1 Jun 2015, Tony Lindgren wrote:
>
>> * Jeroen Hofstee <linux-arm@myspectrum.nl> [150601 09:58]:
>>> On 01-06-15 17:30, Tero Kristo wrote:
>>>> New system control module layout for omap3 overlooked parts of the am35xx
>>>> configuration. Basically the am35xx clocks were not converted to use the
>>>> changed offsets, which caused weird boot warnings. The errors were not
>>>> fatal so far, so they were not caught earlier. Fixed by applying the
>>>> proper offsets for the AM35xx scm clocks.
>>>>
>>>> Fixes: b8845074cf ("ARM: dts: omap3: add minimal l4 bus layout with...")
>>>>
>>>> Signed-off-by: Tero Kristo <t-kristo@ti.com>
>>>> Reported-by: Jeroen Hofstee <linux-arm@myspectrum.nl>
>>>> Cc: Paul Walmsley <paul@pwsan.com>
>>>> Cc: Tony Lindgren <tony@atomide.com>
>>>> ---
>>>>   arch/arm/boot/dts/am35xx-clocks.dtsi |   14 +++++++-------
>>>>   1 file changed, 7 insertions(+), 7 deletions(-)
>>> With this patch the error interrupt / stack dumps are no longer present.
>>>
>>> Thanks,
>>>
>>> Tested-by: Jeroen Hofstee <jeroen@myspectrum.nl>
>>
>> Thanks, I'm suprised this was not caught earlier with all the automated
>> boot testing going on?
>
> At least speaking in terms the testbed results that I post, the warnings
> get reported.  But not many people seem to act on them.  (Jeroen is a
> pleasant exception.)
>
> See for example the "Build warnings from toolchain", "Kernel warnings
> during boot to userspace", "Kernel warnings during PM test", and "Obsolete
> Kconfig symbols" sections here:
>
> http://www.pwsan.com/omap/testlogs/test_v4.1-rc6/20150601012139/README.txt
>
>
> The best way to make this work IMHO would be for us not to accept any new
> feature addition patches as long as there are warnings reported in the
> test results.  The only real exception that I would foresee is if those
> warnings are due to something outside of our control, e.g., a crappy
> bootloader, as I suspect the USB_OTG initiator warnings are for the
> CM-T3517.

I added some extra logic into my test setup today for detecting this. 
Previously the dumps were pretty much hidden as there are existing dumps 
so I kind of ignored the new ones semi-blindly. >.<

-Tero

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Tony Lindgren June 1, 2015, 6:06 p.m. UTC | #6
* Tony Lindgren <tony@atomide.com> [150601 11:06]:
> * Paul Walmsley <paul@pwsan.com> [150601 10:45]:
> > 
> > See for example the "Build warnings from toolchain", "Kernel warnings 
> > during boot to userspace", "Kernel warnings during PM test", and "Obsolete 
> > Kconfig symbols" sections here:
> > 
> > http://www.pwsan.com/omap/testlogs/test_v4.1-rc6/20150601012139/README.txt
> 
> OK somehow 3517evm is listed under "skip" there? 

Oh I see you have two 3517 devices there, never mind.

Hmm now I'm wondering what the panda es warnings listed there are..

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Paul Walmsley June 1, 2015, 9:21 p.m. UTC | #7
On Mon, 1 Jun 2015, Tony Lindgren wrote:

> * Paul Walmsley <paul@pwsan.com> [150601 10:45]:
> 
> > http://www.pwsan.com/omap/testlogs/test_v4.1-rc6/20150601012139/README.txt
> 
> OK somehow 3517evm is listed under "skip" there? 

Yep that board is down right now; something's wrong with it and I haven't 
had the time to figure out whether it's fixable, or if it's fried.

> > The best way to make this work IMHO would be for us not to accept any new 
> > feature addition patches as long as there are warnings reported in the 
> > test results.  The only real exception that I would foresee is if those 
> > warnings are due to something outside of our control, e.g., a crappy 
> > bootloader, as I suspect the USB_OTG initiator warnings are for the 
> > CM-T3517.
> 
> Right. Also seems we should diff dmesg output too (after stripping out
> the timestamps). Pretty much the only things that should change are
> the sysfs paths for devices in the dmesg output unless some warnings
> get fixed. That output probably still also needs to be manually looked
> at though..

Yep, there are still some other minor loose ends to be tied up too that 
don't show up as full warnings, such as the broken UART4 idle protocol 
integration on AM35xx...

- Paul
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Paul Walmsley June 1, 2015, 9:26 p.m. UTC | #8
On Mon, 1 Jun 2015, Tony Lindgren wrote:

> * Tony Lindgren <tony@atomide.com> [150601 11:06]:
> > * Paul Walmsley <paul@pwsan.com> [150601 10:45]:
> > > 
> > > See for example the "Build warnings from toolchain", "Kernel warnings 
> > > during boot to userspace", "Kernel warnings during PM test", and "Obsolete 
> > > Kconfig symbols" sections here:
> > > 
> > > http://www.pwsan.com/omap/testlogs/test_v4.1-rc6/20150601012139/README.txt
> > 
> > OK somehow 3517evm is listed under "skip" there? 
> 
> Oh I see you have two 3517 devices there, never mind.
> 
> Hmm now I'm wondering what the panda es warnings listed there are..

http://www.pwsan.com/omap/testlogs/test_v4.1-rc6/20150601012139/boot/4430es2panda/4430es2panda_log.txt

Looked to me like an OMAP4430 ES2.2 bug.  I recall discussing it with 
someone with an ES2.3 Pandaboard and they said it didn't show up.  So I 
asked TI at the time if there was an erratum for it; apparently not.  So I 
think we may need to add in another hardware bug workaround flag to the 
OMAP integration code...

- Paul
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Tero Kristo June 2, 2015, 7:15 a.m. UTC | #9
On 06/02/2015 12:26 AM, Paul Walmsley wrote:
> On Mon, 1 Jun 2015, Tony Lindgren wrote:
>
>> * Tony Lindgren <tony@atomide.com> [150601 11:06]:
>>> * Paul Walmsley <paul@pwsan.com> [150601 10:45]:
>>>>
>>>> See for example the "Build warnings from toolchain", "Kernel warnings
>>>> during boot to userspace", "Kernel warnings during PM test", and "Obsolete
>>>> Kconfig symbols" sections here:
>>>>
>>>> http://www.pwsan.com/omap/testlogs/test_v4.1-rc6/20150601012139/README.txt
>>>
>>> OK somehow 3517evm is listed under "skip" there?
>>
>> Oh I see you have two 3517 devices there, never mind.
>>
>> Hmm now I'm wondering what the panda es warnings listed there are..
>
> http://www.pwsan.com/omap/testlogs/test_v4.1-rc6/20150601012139/boot/4430es2panda/4430es2panda_log.txt
>
> Looked to me like an OMAP4430 ES2.2 bug.  I recall discussing it with
> someone with an ES2.3 Pandaboard and they said it didn't show up.  So I
> asked TI at the time if there was an erratum for it; apparently not.  So I
> think we may need to add in another hardware bug workaround flag to the
> OMAP integration code...
>
> - Paul
>

Don't know about pandaboard ES2.2, but this doesn't show up on SDP4430 
es2.3 at least. Do you know which clockdomain is in question there? It 
could just be a race someplace in the usecounting system that shows up 
on that specific SoC.

-Tero

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Jeroen Hofstee June 5, 2015, 8:01 a.m. UTC | #10
Hello Paul,

On 01-06-15 19:44, Paul Walmsley wrote:
> The best way to make this work IMHO would be for us not to accept any new
> feature addition patches as long as there are warnings reported in the
> test results.  The only real exception that I would foresee is if those
> warnings are due to something outside of our control, e.g., a crappy
> bootloader, as I suspect the USB_OTG initiator warnings are for the
> CM-T3517.
>

I doubt this is related to the bootloader. I have the suspicion that is 
actually
a bug in linux but only triggered depending on whether the ROMcode setup
the USB OTG or not. Here is some data to backup my statement:

Linux booting without USB_OTG error trap
md 480022F0 1
480022f0: 0000032f                               /...
md 48002580 1
48002580: 0f00b7a2                               ....

bit USBOTG_PHY_RESET is 0 -> out of reset


USB_OTG sees memory hole
md 480022F0 1
480022f0: 0000030f    ....
md 48002580 1
48002580: 0f00c71e    ....

USBOTG_PHY_RESET is 1 -> still in reset when booting linux.

Does that match with how your am3517 boards boot?

Regards,
Jeroen


--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Jeroen Hofstee June 5, 2015, 8:04 a.m. UTC | #11
On 05-06-15 10:01, Jeroen Hofstee wrote:
> Hello Paul,
>
> On 01-06-15 19:44, Paul Walmsley wrote:
>> The best way to make this work IMHO would be for us not to accept any 
>> new
>> feature addition patches as long as there are warnings reported in the
>> test results.  The only real exception that I would foresee is if those
>> warnings are due to something outside of our control, e.g., a crappy
>> bootloader, as I suspect the USB_OTG initiator warnings are for the
>> CM-T3517.
>>
>
> I doubt this is related to the bootloader. I have the suspicion that 
> is actually
> a bug in linux but only triggered depending on whether the ROMcode setup
> the USB OTG or not. Here is some data to backup my statement:
>
> Linux booting without USB_OTG error trap
> md 480022F0 1
> 480022f0: 0000032f                               /...
> md 48002580 1
> 48002580: 0f00b7a2                               ....
>
> bit USBOTG_PHY_RESET is 0 -> out of reset
>
>
> USB_OTG sees memory hole
> md 480022F0 1
> 480022f0: 0000030f    ....
> md 48002580 1
> 48002580: 0f00c71e    ....
>
> USBOTG_PHY_RESET is 1 -> still in reset when booting linux.
>
> Does that match with how your am3517 boards boot?
>

ps. the dumped register are CONTROL.CONTROL_STATUS and 
CONTROL.CONTROL_DEVCONF2.

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Jeroen Hofstee June 7, 2015, 9:41 a.m. UTC | #12
Hello Paul,

On 05-06-15 10:04, Jeroen Hofstee wrote:
>
> On 05-06-15 10:01, Jeroen Hofstee wrote:
>>
>> On 01-06-15 19:44, Paul Walmsley wrote:
>>> The best way to make this work IMHO would be for us not to accept 
>>> any new
>>> feature addition patches as long as there are warnings reported in the
>>> test results.  The only real exception that I would foresee is if those
>>> warnings are due to something outside of our control, e.g., a crappy
>>> bootloader, as I suspect the USB_OTG initiator warnings are for the
>>> CM-T3517.
>>>
>>
>> I doubt this is related to the bootloader. I have the suspicion that 
>> is actually
>> a bug in linux but only triggered depending on whether the ROMcode setup
>> the USB OTG or not. Here is some data to backup my statement:
>>

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.

Regards,
Jeroen

U-Boot 2015.04-00098-g487ee34-dirty (Jun 05 2015 - 13:14:48)

AM35XX-GP ES2.0, CPU-OPP2, L3-165MHz, Max CPU Clock 600 Mhz
ccgx + LPDDR/NAND
I2C:   ready
DRAM:  256 MiB
NAND:  512 MiB
MMC:   OMAP SD/MMC: 0
In:    serial
Out:   serial
Err:   serial
Die ID #2276000100000000014e0fb21500b024
Net: DaVinci-EMAC
Hit any key to stop autoboot:  0
ccgx=> echo $clear_l3_int
mw 68004428 0x11000000; mw 6800442C 0x00000000; mw 68004458 0xFFFFFFFF; 
mw 6800445C 0xFFFFFFFF
ccgx=> md 0x68000510 2
68000510: 00000000 00000000                      ........
ccgx=> tftp ccgx/zImage; tftp 80000000 ccgx/am3517-ccgx.dtb;
Using DaVinci-EMAC device
TFTP from server 10.0.0.103; our IP address is 10.0.0.250
Filename 'ccgx/zImage'.
Load address: 0x80300000
Loading: #################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
          ##########
          863.3 KiB/s
done
Bytes transferred = 4040072 (3da588 hex)
Using DaVinci-EMAC device
TFTP from server 10.0.0.103; our IP address is 10.0.0.250
Filename 'ccgx/am3517-ccgx.dtb'.
Load address: 0x80000000
Loading: ###########
          825.2 KiB/s
done
Bytes transferred = 54112 (d360 hex)
ccgx=> md 0x68000510 2
68000510: 04000000 00000000                      ........
ccgx=> run clear_l3_int
ccgx=> md 0x68000510 2
68000510: 00000000 00000000                      ........
ccgx=> boot

# USB_OTG error is gone...

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Paul Walmsley June 7, 2015, 7:56 p.m. UTC | #13
Hi Jeroen,

On Sun, 7 Jun 2015, Jeroen Hofstee wrote:

> Hello Paul,
> 
> On 05-06-15 10:04, Jeroen Hofstee wrote:
> > 
> > On 05-06-15 10:01, Jeroen Hofstee wrote:
> > > 
> > > On 01-06-15 19:44, Paul Walmsley wrote:
> > > > The best way to make this work IMHO would be for us not to accept any
> > > > new
> > > > feature addition patches as long as there are warnings reported in the
> > > > test results.  The only real exception that I would foresee is if those
> > > > warnings are due to something outside of our control, e.g., a crappy
> > > > bootloader, as I suspect the USB_OTG initiator warnings are for the
> > > > CM-T3517.
> > > > 
> > > 
> > > I doubt this is related to the bootloader. I have the suspicion that is
> > > actually
> > > a bug in linux but only triggered depending on whether the ROMcode setup
> > > the USB OTG or not. Here is some data to backup my statement:
> > > 
> 
> 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'd like to solicit your opinion on what to do here.  I wonder if, in the 
L3 bus drivers, we should simply report, in a line or two, if any bus 
errors were logged before the kernel starts?  That would help discriminate 
between problems that the kernel is responsible for, vs. problems that 
occur earlier in the boot process.  Any thoughts?

Thanks for all your investigation, by the way, it's much appreciated.


regards,

- Paul


> 
> Regards,
> Jeroen
> 
> U-Boot 2015.04-00098-g487ee34-dirty (Jun 05 2015 - 13:14:48)
> 
> AM35XX-GP ES2.0, CPU-OPP2, L3-165MHz, Max CPU Clock 600 Mhz
> ccgx + LPDDR/NAND
> I2C:   ready
> DRAM:  256 MiB
> NAND:  512 MiB
> MMC:   OMAP SD/MMC: 0
> In:    serial
> Out:   serial
> Err:   serial
> Die ID #2276000100000000014e0fb21500b024
> Net: DaVinci-EMAC
> Hit any key to stop autoboot:  0
> ccgx=> echo $clear_l3_int
> mw 68004428 0x11000000; mw 6800442C 0x00000000; mw 68004458 0xFFFFFFFF; mw
> 6800445C 0xFFFFFFFF
> ccgx=> md 0x68000510 2
> 68000510: 00000000 00000000                      ........
> ccgx=> tftp ccgx/zImage; tftp 80000000 ccgx/am3517-ccgx.dtb;
> Using DaVinci-EMAC device
> TFTP from server 10.0.0.103; our IP address is 10.0.0.250
> Filename 'ccgx/zImage'.
> Load address: 0x80300000
> Loading: #################################################################
> #################################################################
> #################################################################
> #################################################################
> #################################################################
> #################################################################
> #################################################################
> #################################################################
> #################################################################
> #################################################################
> #################################################################
> #################################################################
>          ##########
>          863.3 KiB/s
> done
> Bytes transferred = 4040072 (3da588 hex)
> Using DaVinci-EMAC device
> TFTP from server 10.0.0.103; our IP address is 10.0.0.250
> Filename 'ccgx/am3517-ccgx.dtb'.
> Load address: 0x80000000
> Loading: ###########
>          825.2 KiB/s
> done
> Bytes transferred = 54112 (d360 hex)
> ccgx=> md 0x68000510 2
> 68000510: 04000000 00000000                      ........
> ccgx=> run clear_l3_int
> ccgx=> md 0x68000510 2
> 68000510: 00000000 00000000                      ........
> ccgx=> boot
> 
> # USB_OTG error is gone...
> 


--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Paul Walmsley June 8, 2015, 2:38 a.m. UTC | #14
Hi Jeroen,

On Sun, 7 Jun 2015, Paul Walmsley wrote:

> On Sun, 7 Jun 2015, Jeroen Hofstee wrote:
> 
> > On 05-06-15 10:04, Jeroen Hofstee wrote:
> > > 
> > > On 05-06-15 10:01, Jeroen Hofstee wrote:
> > > > 
> > > > On 01-06-15 19:44, Paul Walmsley wrote:
> > > > > The best way to make this work IMHO would be for us not to accept any
> > > > > new
> > > > > feature addition patches as long as there are warnings reported in the
> > > > > test results.  The only real exception that I would foresee is if those
> > > > > warnings are due to something outside of our control, e.g., a crappy
> > > > > bootloader, as I suspect the USB_OTG initiator warnings are for the
> > > > > CM-T3517.
> > > > > 
> > > > 
> > > > I doubt this is related to the bootloader. I have the suspicion that is
> > > > actually
> > > > a bug in linux but only triggered depending on whether the ROMcode setup
> > > > the USB OTG or not. Here is some data to backup my statement:
> > > > 
> > 
> > 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.


regards,

- Paul
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Jeroen Hofstee June 8, 2015, 9:43 p.m. UTC | #15
Hello Paul,

On 07-06-15 21:56, 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'd like to solicit your opinion on what to do here.  I wonder if, in the
> L3 bus drivers, we should simply report, in a line or two, if any bus
> errors were logged before the kernel starts?  That would help discriminate
> between problems that the kernel is responsible for, vs. problems that
> occur earlier in the boot process.  Any thoughts?
>

I am not sure this can be easily done in a general manner.  Since in general
linux doesn't know the bootloader, it can't rely on what peripherals are 
setup,
so I doubt it is in general possible to store a copy of the interrupt 
registers
really early. Besides that, when not hacking around, I guess during the 
really
early boot stage it is unknown what the interrupt registers are in the 
first place
and which clocks are needed. And even if it could be done, if there is a 
bug in
that code, it would lead to bigger problems than it is trying to solve 
(a bit weird
backlogs).

I guess it would be easier to check these flags in u-boot right before 
the jump
to linux  (there is a cleanup_before_linux() or something name like 
that). [ Or fake
the boot and run the check as a separate command]. Unfortunately u-boot does
not have a complete driver model, so a implementation of that in todays 
u-boot
will lead to a complete #ifdef CONFIG_foo mesh.

So, if you ask me, no don't add it to linux, but to u-boot instead. But 
likely as feature
for a later release which can query all drivers. (and doubt this should 
be limited to
interrupt flags, runtime_test() could be called on all of them e.g. when 
entering a
command like runtime_test).

Regards,
Jeroen

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Jeroen Hofstee June 8, 2015, 10 p.m. UTC | #16
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 majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Patch
diff mbox

diff --git a/arch/arm/boot/dts/am35xx-clocks.dtsi b/arch/arm/boot/dts/am35xx-clocks.dtsi
index 518b8fd..18cc826 100644
--- a/arch/arm/boot/dts/am35xx-clocks.dtsi
+++ b/arch/arm/boot/dts/am35xx-clocks.dtsi
@@ -12,7 +12,7 @@ 
 		#clock-cells = <0>;
 		compatible = "ti,am35xx-gate-clock";
 		clocks = <&ipss_ick>;
-		reg = <0x059c>;
+		reg = <0x032c>;
 		ti,bit-shift = <1>;
 	};
 
@@ -20,7 +20,7 @@ 
 		#clock-cells = <0>;
 		compatible = "ti,gate-clock";
 		clocks = <&rmii_ck>;
-		reg = <0x059c>;
+		reg = <0x032c>;
 		ti,bit-shift = <9>;
 	};
 
@@ -28,7 +28,7 @@ 
 		#clock-cells = <0>;
 		compatible = "ti,am35xx-gate-clock";
 		clocks = <&ipss_ick>;
-		reg = <0x059c>;
+		reg = <0x032c>;
 		ti,bit-shift = <2>;
 	};
 
@@ -36,7 +36,7 @@ 
 		#clock-cells = <0>;
 		compatible = "ti,gate-clock";
 		clocks = <&pclk_ck>;
-		reg = <0x059c>;
+		reg = <0x032c>;
 		ti,bit-shift = <10>;
 	};
 
@@ -44,7 +44,7 @@ 
 		#clock-cells = <0>;
 		compatible = "ti,am35xx-gate-clock";
 		clocks = <&ipss_ick>;
-		reg = <0x059c>;
+		reg = <0x032c>;
 		ti,bit-shift = <0>;
 	};
 
@@ -52,7 +52,7 @@ 
 		#clock-cells = <0>;
 		compatible = "ti,gate-clock";
 		clocks = <&sys_ck>;
-		reg = <0x059c>;
+		reg = <0x032c>;
 		ti,bit-shift = <8>;
 	};
 
@@ -60,7 +60,7 @@ 
 		#clock-cells = <0>;
 		compatible = "ti,am35xx-gate-clock";
 		clocks = <&sys_ck>;
-		reg = <0x059c>;
+		reg = <0x032c>;
 		ti,bit-shift = <3>;
 	};
 };