[U-Boot] Problems with a P2020 board
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.
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 Iam 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 veryslow. 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 timerinterrupts 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
On 08/30/2012 03:12 PM, Joakim Tjernlund wrote:
Boot Count. We are keen to use the boot counter feature, but Iam 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
On Aug 30, 2012, at 2:56 AM, Mark Marshall wrote:
Timer Interrupts seem to stop. Once U-boot has started the timerinterrupts 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
participants (4)
-
Joakim Tjernlund -
Kumar Gala -
Mark Marshall -
Stefan Roese