[U-Boot] Problems with a P2020 board

[U-Boot] Problems with a P2020 board

[Mark Marshall]

Hi.

We have a new board which we are suing with U-boot.  The CPU is a P2020.
I am having a  few minor problems, and I was hoping to get some help.

-       Boot Count.  We are keen to use the boot counter feature, but I
am struggling to find a suitable register in the P2020.  The file
arch/powerpc/lib/bootcount.c list a few locations that work with
other PowerPC chips, but I can't find any of those registers in the
P2020 documentation.

-       SPI Flash seems very slow.  The SPI flash accesses all seem to be very
slow.  I can increase the SPI clock (to 40 MHz) and this helps, but the
real problem is the code in drivers/spi/fsl_espi.c.  Here there is an 80us
delay after each 32-bit value is written to the TX FIFO.  I don't understand
why this delay is there?  If I reduce it to 2 usec everything still works, and
SPI Flash accesses are much faster.  I can easily produce a patch to
remove or reduce this delay, but I'd rather know why it was there in the
first place?

-       Timer Interrupts seem to stop.  Once U-boot has started the timer
interrupts seem to stop.  I have added a test command that prints out
the timestamp variable (from arch/powerpc/lib/interrupts.c).  I can
see that when we enter the interactive loop this variable stops
incrementing.  I can add boot scripts that output this value, and it
is incrementing until the console becomes interactive.  Has anyone
else seen a problem like this?

Many thanks for any help you can offer us.

Mark Marshall.

[U-Boot] Problems with a P2020 board

[Joakim Tjernlund]

>
> Hi.
>
> We have a new board which we are suing with U-boot.  The CPU is a P2020.
> I am having a  few minor problems, and I was hoping to get some help.
>
> -       Boot Count.  We are keen to use the boot counter feature, but I
> am struggling to find a suitable register in the P2020.  The file
> arch/powerpc/lib/bootcount.c list a few locations that work with
> other PowerPC chips, but I can't find any of those registers in the
> P2020 documentation.

Me too on finding such a register.

>
> -       SPI Flash seems very slow.  The SPI flash accesses all seem to be very
> slow.  I can increase the SPI clock (to 40 MHz) and this helps, but the
> real problem is the code in drivers/spi/fsl_espi.c.  Here there is an 80us
> delay after each 32-bit value is written to the TX FIFO.  I don't understand
> why this delay is there?  If I reduce it to 2 usec everything still works, and
> SPI Flash accesses are much faster.  I can easily produce a patch to
> remove or reduce this delay, but I'd rather know why it was there in the
> first place?
>
> -       Timer Interrupts seem to stop.  Once U-boot has started the timer
> interrupts seem to stop.  I have added a test command that prints out
> the timestamp variable (from arch/powerpc/lib/interrupts.c).  I can
> see that when we enter the interactive loop this variable stops
> incrementing.  I can add boot scripts that output this value, and it
> is incrementing until the console becomes interactive.  Has anyone
> else seen a problem like this?

I have but only when running from our BDI2000/BDI3000 emulator. We figured
it was something with the emulator settings but I was never convinced.
If you find out why, please let me know.
Oh, we have a P2010 though.

 Jocke

[U-Boot] Problems with a P2020 board

[Stefan Roese]

On 08/30/2012 03:12 PM, Joakim Tjernlund wrote:
>> -       Boot Count.  We are keen to use the boot counter feature, but I
>> am struggling to find a suitable register in the P2020.  The file
>> arch/powerpc/lib/bootcount.c list a few locations that work with
>> other PowerPC chips, but I can't find any of those registers in the
>> P2020 documentation.
> 
> Me too on finding such a register.

If you don't have such registers, a bit of reserved SDRAM might be a
solution. That already implemented for some boards. See
bootcount_store() and bootcount_load() in:

board/keymile/km_arm/km_arm.c

This "RAM bootcount driver" will be moved to a common location by the
bootcount consolidation patches that are pending.

Thanks,
Stefan

[U-Boot] Problems with a P2020 board

[Joakim Tjernlund]

Joakim Tjernlund/Transmode wrote on 2012/08/30 15:12:08:
>
> >
> > Hi.
> >
> > We have a new board which we are suing with U-boot.  The CPU is a P2020.
> > I am having a  few minor problems, and I was hoping to get some help.
> >
> > -       Boot Count.  We are keen to use the boot counter feature, but I
> > am struggling to find a suitable register in the P2020.  The file
> > arch/powerpc/lib/bootcount.c list a few locations that work with
> > other PowerPC chips, but I can't find any of those registers in the
> > P2020 documentation.
>
> Me too on finding such a register

Did you find a register?

>
> >
> > -       SPI Flash seems very slow.  The SPI flash accesses all seem to be very
> > slow.  I can increase the SPI clock (to 40 MHz) and this helps, but the
> > real problem is the code in drivers/spi/fsl_espi.c.  Here there is an 80us
> > delay after each 32-bit value is written to the TX FIFO.  I don't understand
> > why this delay is there?  If I reduce it to 2 usec everything still works, and
> > SPI Flash accesses are much faster.  I can easily produce a patch to
> > remove or reduce this delay, but I'd rather know why it was there in the
> > first place?
> >
> > -       Timer Interrupts seem to stop.  Once U-boot has started the timer
> > interrupts seem to stop.  I have added a test command that prints out
> > the timestamp variable (from arch/powerpc/lib/interrupts.c).  I can
> > see that when we enter the interactive loop this variable stops
> > incrementing.  I can add boot scripts that output this value, and it
> > is incrementing until the console becomes interactive.  Has anyone
> > else seen a problem like this?

I wonder if you found out the cause? We have recently seen that running
LocalBus with 150MHz sometimes makes out board instable(complete freeze)
So far we have no clue as it is hard to reproduce.
37,5 MHz works fine tough.

> I have but only when running from our BDI2000/BDI3000 emulator. We figured
> it was something with the emulator settings but I was never convinced.
> If you find out why, please let me know.
> Oh, we have a P2010 though.

 Jocke

[U-Boot] Problems with a P2020 board

[Kumar Gala]

On Sep 26, 2012, at 7:09 AM, Joakim Tjernlund wrote:

> Joakim Tjernlund/Transmode wrote on 2012/08/30 15:12:08:
>> 
>>> 
>>> Hi.
>>> 
>>> We have a new board which we are suing with U-boot.  The CPU is a P2020.
>>> I am having a  few minor problems, and I was hoping to get some help.
>>> 
>>> -       Boot Count.  We are keen to use the boot counter feature, but I
>>> am struggling to find a suitable register in the P2020.  The file
>>> arch/powerpc/lib/bootcount.c list a few locations that work with
>>> other PowerPC chips, but I can't find any of those registers in the
>>> P2020 documentation.
>> 
>> Me too on finding such a register
> 
> Did you find a register?

What are the requirements of the bootcount register?  If it needs to persist value across hard resets of the SoC than nothing exists.

If you need a scratch register than you could possibly use one of the MPIC msg registers.

- k

[U-Boot] Problems with a P2020 board

[Kumar Gala]

On Aug 30, 2012, at 2:56 AM, Mark Marshall wrote:

> -       Timer Interrupts seem to stop.  Once U-boot has started the timer
> interrupts seem to stop.  I have added a test command that prints out
> the timestamp variable (from arch/powerpc/lib/interrupts.c).  I can
> see that when we enter the interactive loop this variable stops
> incrementing.  I can add boot scripts that output this value, and it
> is incrementing until the console becomes interactive.  Has anyone
> else seen a problem like this?

Which kinda of timer interrupts - those generated by core decrementer or something via MPIC timer?

can you see if MSR[EE] is still set?  If core decrementer, also take a look at TSR & TCR sprs.

- k

[U-Boot] Problems with a P2020 board

[Joakim Tjernlund]

Kumar Gala <galak@kernel.crashing.org> wrote on 2012/09/26 15:39:48:
>
>
> On Sep 26, 2012, at 7:09 AM, Joakim Tjernlund wrote:
>
> > Joakim Tjernlund/Transmode wrote on 2012/08/30 15:12:08:
> >>
> >>>
> >>> Hi.
> >>>
> >>> We have a new board which we are suing with U-boot.  The CPU is a P2020.
> >>> I am having a  few minor problems, and I was hoping to get some help.
> >>>
> >>> -       Boot Count.  We are keen to use the boot counter feature, but I
> >>> am struggling to find a suitable register in the P2020.  The file
> >>> arch/powerpc/lib/bootcount.c list a few locations that work with
> >>> other PowerPC chips, but I can't find any of those registers in the
> >>> P2020 documentation.
> >>
> >> Me too on finding such a register
> >
> > Did you find a register?
>
> What are the requirements of the bootcount register?  If it needs to persist value across hard resets of the SoC than nothing exists.

yes, that the one. Every now and then I want to be able to tell the difference between cold start and warm start but
I cannot find anything in P2010 that can do that for me.

 Jocke

[U-Boot] Problems with a P2020 board

[Mark Marshall]

Hi.

For the bootcount register, we wanted something that was only reset 
at power on (or never reset).  We didn't find a suitable register in the 
P2020, and freescale support seemed to agree that there was no such 
register.  (I'm now using a couple of alarm registers fromthe I2C RTC, 
a hack...).

I discovered what was wrong with the timer interrupts.  I had switched 
on the watchdog, and it turns out that the code to reset the watchdog
was wrong.  It was doing a  read-modify-write of the TSR register 
(OR-ing in the WOS flag), where it should have just been writing the WIS
flag to the register.  There is a patch in patchwork for this.

Thanks for your help (and sorry, I should have posted this a while ago, 
but I've been out of the office).

Mark Marshall.

PS.
I have also made progress with the third issue, eSPI acces.  I think that
I will submit a complete re-write of the fsl_espi code, it seems to be 
wrong.  The RNE and TNF bit's only indicate that you can read or write
and single 8-bit quantity, not a full 32-bits, which is assumed by the code.

________________________________________
From: Joakim Tjernlund [joakim.tjernlund at transmode.se]
Sent: 26 September 2012 14:09
Cc: Mark Marshall; mingkai.hu at freescale.com; u-boot at lists.denx.de
Subject: Re: [U-Boot] Problems with a P2020 board

Joakim Tjernlund/Transmode wrote on 2012/08/30 15:12:08:
>
> >
> > Hi.
> >
> > We have a new board which we are suing with U-boot.  The CPU is a P2020.
> > I am having a  few minor problems, and I was hoping to get some help.
> >
> > -       Boot Count.  We are keen to use the boot counter feature, but I
> > am struggling to find a suitable register in the P2020.  The file
> > arch/powerpc/lib/bootcount.c list a few locations that work with
> > other PowerPC chips, but I can't find any of those registers in the
> > P2020 documentation.
>
> Me too on finding such a register

Did you find a register?

>
> >
> > -       SPI Flash seems very slow.  The SPI flash accesses all seem to be very
> > slow.  I can increase the SPI clock (to 40 MHz) and this helps, but the
> > real problem is the code in drivers/spi/fsl_espi.c.  Here there is an 80us
> > delay after each 32-bit value is written to the TX FIFO.  I don't understand
> > why this delay is there?  If I reduce it to 2 usec everything still works, and
> > SPI Flash accesses are much faster.  I can easily produce a patch to
> > remove or reduce this delay, but I'd rather know why it was there in the
> > first place?
> >
> > -       Timer Interrupts seem to stop.  Once U-boot has started the timer
> > interrupts seem to stop.  I have added a test command that prints out
> > the timestamp variable (from arch/powerpc/lib/interrupts.c).  I can
> > see that when we enter the interactive loop this variable stops
> > incrementing.  I can add boot scripts that output this value, and it
> > is incrementing until the console becomes interactive.  Has anyone
> > else seen a problem like this?

I wonder if you found out the cause? We have recently seen that running
LocalBus with 150MHz sometimes makes out board instable(complete freeze)
So far we have no clue as it is hard to reproduce.
37,5 MHz works fine tough.

> I have but only when running from our BDI2000/BDI3000 emulator. We figured
> it was something with the emulator settings but I was never convinced.
> If you find out why, please let me know.
> Oh, we have a P2010 though.

 Jocke