usrMmuInit on MPC8260 with vxWorks 5.4 and watchdog
Karen Musgrove & Stephane Couture
We have an external watchdog which can only be disabled, once
enabled, by powering off the card. The period of the watchdog is 0.5
sec. On our old MPC860 card, we were adding calls to kick the watchdog
at a few place during initialization and then spawning a task to take
care of it afterward. We were going to go for the same strategy but
we've realized that the usrMmuInit routine takes 1.36 sec to execute on
our target, which is too long.
We are now thinking about kicking the external watchdog in the
decrementer or in the NMI (which we would make recoverable) of the
internal watchdog. The decrementer solution will not work if WRS are
locking the interrupt for a long period into the usrMmuInit, which they
don't seem to do.
1- Does somebody have a better solution to take care of the watchdog?
2- Does anybody know why it would take 1.36 seconds to initialize the
BAT and page table (PTE) on this processor (MPC8260). It seems rather
long too me... We are running at 200 MHz, bus speed 33 MHz. The SDRAM
(32Mbytes, 64 bits wide) is marked as cacheable copy back for the data
using the PTE, cacheable for the instruction using the IBAT and all
other memory are mapped as non-cacheable with the DBAT/IBAT registers.
Stephane
Doug Gibbons
>
> Hi,
>
> We have an external watchdog which can only be disabled, once
> enabled, by powering off the card. The period of the watchdog is 0.5
> sec. On our old MPC860 card, we were adding calls to kick the watchdog
> at a few place during initialization and then spawning a task to take
> care of it afterward. We were going to go for the same strategy but
> we've realized that the usrMmuInit routine takes 1.36 sec to execute on
> our target, which is too long.
>
> We are now thinking about kicking the external watchdog in the
> decrementer or in the NMI (which we would make recoverable) of the
> internal watchdog. The decrementer solution will not work if WRS are
> locking the interrupt for a long period into the usrMmuInit, which they
> don't seem to do.
>
> 1- Does somebody have a better solution to take care of the watchdog?
1) Obviously you've thought of delaying watchdog enable until after
usrMmuInit() has executed...
2) increase the watchdog timeout period?
3) use your own mmu/cache initialization routines?
>
> 2- Does anybody know why it would take 1.36 seconds to initialize the
> BAT and page table (PTE) on this processor (MPC8260). It seems rather
> long too me... We are running at 200 MHz, bus speed 33 MHz. The SDRAM
> (32Mbytes, 64 bits wide) is marked as cacheable copy back for the data
> using the PTE, cacheable for the instruction using the IBAT and all
> other memory are mapped as non-cacheable with the DBAT/IBAT registers.
I got hip deep into usrMmuInit yesterday but am at a loss as to why
it takes 1.36 seconds. usrMmuInit()->mmuPpcLibInit() does the following on the
8260:
initializes your BATs according to your sysBatDesc[]
invalidates the TLB
installs I/D miss exception handlers
initializes all 16 segment registers
parses your sysPhysMemDesc[] to determine gross memory size
(don't describe memory here that you're covering with BATs anyway)
uses gross memory size to memAlign() a page table (128K-2MB)
memsets the page table
You page table has to be initialized next and this is probably what
is costing you, though 1.36 sec is excessive. For INCLUDE_MMU_BASIC
the steps are
loop, creating PTEs describing your memory
enable MMU/cache, MMU/cache
You didn't mention if you were using RMW parity or
ECC which could slow SDRAM accesses down.
--
Lee Douglas Gibbons L u c e n t T e c h n o l o g i e s
ldgi...@lucent.com Bell Labs Innovations
Karen Musgrove & Stephane Couture
through the code also but I don't see what could take so long, at 32Mb, I have
only 512Kb of PTE.
The watchdog is an external one and can only be disabled by a power-on reset, if
we don't find a solution, we might modify the H/W to be able to disable it or look
for a different external watchdog, but that is a solution we would like to avoid.
We might also map the SDRAM through a BAT instead of through the PTE and modify
the drivers that rely on cacheDmaMalloc so that they use instead a non-cacheable
portion of memory for their buffers. It might cut down the usrMmuInit
initialization time, if not, writing our own MMU init would be much easier (I
think) if there is no PTE entry.
We have also raised a TSR with WRS to see if they can explain why would that
routine is taking so long to execute, they might find something. I have also
asked them to verify the time it takes to execute the usrMmuInit routine on an
ads8260 board, just to see if they arrive with the same kind of number.
The SDRAM is not using any Parity/ECC. I still have to verify the actual
performance of the SDRAM before any mmu initialisation, it might be slower than
what I think.
As soon as I have any informations, I'l post it here.
Thanks for your help
Doug Gibbons wrote:
Stephane
johan.b...@peektraffic.nl
: 2- Does anybody know why it would take 1.36 seconds to initialize the
: BAT and page table (PTE) on this processor (MPC8260). It seems rather
: long too me... We are running at 200 MHz, bus speed 33 MHz. The SDRAM
: (32Mbytes, 64 bits wide) is marked as cacheable copy back for the data
: using the PTE, cacheable for the instruction using the IBAT and all
: other memory are mapped as non-cacheable with the DBAT/IBAT registers.
Check out the value of PCI_MSTR_IO_SIZE. In our case (MBX860) this was set
to 512 Mb, but changing this to a more "normal" value might improve things
a bit.
: Stephane
Groeten,
Johan
--
o o o o o o o . . . ___________________________________
o _____ || Johan Borkhuis |
.][__n_n_|DD[ ====_____ | jo...@borksoft.xs4all.nl |
>(________|__|_[_________]_|________________________________|
_/oo OOOOO oo` ooo ooo 'o!o!o o!o!o`
=== VxWorks page: http://www.xs4all.nl/~borkhuis/vxworks/vxworks.html ===
Jeff David
Regarding the watchdog, here's a technique that can be used to solve the
problem when one piece of code causes the watchdog to expire. In a previous
company, we used a '2-tier' watchdog. The problem was that we had one piece
of hardware that would take too long under certain circumstances and cause
the watchdog to expire.
The watchdog must be turned on within the first few seconds after the
processor boots. It must be refreshed periodically based on the speed of
your processor. We had an 860 running at 40MHz, so we had about 3 seconds
maximum to refresh the watchdog timer. The piece of hardware that was
causing the watchdog to expire was a flash disk.
The solution was to create a high and a low priority watchdog refresh task.
The high priority task was the highest priority task in the system other
than the OS's network and system tasks (it was pSOS), so it would always get
a chance to run. The high priority watchdog task would be called every
second and refresh the watchdog. The low priority task (just higher than
the IDLE task) would be called every N seconds. (For our implementation is
was actually 120 seconds!)
The two tasks worked together by sharing one variable, a so-called
'interlock counter'. This variable would be set to the maximum by the low
priority task, and decremented by the high priority task. The high priority
task would NOT refresh the watchdog if this counter ever got to 0. So, if
the low priority watchdog task did not get a chance to run in N seconds,
then the watchdog would expire.
Regards,
Jeff
Karen Musgrove & Stephane Couture
Thank you everyone for providing your ideas about this issue. I was not
able to reduce the initialization time of the routine usrMmuInit by reorganizing
the PTE/BAT. I have solved the problem by kicking both watchdogs in the
decrementer which I start at the early stage of usrInit. Before jumping into
the application, I then let a normal task kick the watchdog by attaching an
empty interrupt to the decrementer (we use the PIT for system clock). I am still
puzled as to why it would take so long to initialize the PTE/BAT...
Also, I like the idea of having a '2-tier' watchdog as described in the previous
e-mail, we're thinking about it...
I like the idea of controlling the watchdog timeout with a second task