[ECOS] MPC8xx and MPC8xxx Startup sequence and locking key registers

[<ecos-dev at bcsw dot net>]

There is a potential 'restart' bug in the _start routine for the MPC8xx and
possibly other PowerPC architectures.

One of the first things that _start does (after calling the variant routine
hal_cpu_init) is to set the 64-bit timebase register to zero.   If the user
has locked the timebase and decrementer via the TBK register, then a reset
other than power-on (such as watchdog) will result in a machine check at
this instruction.

Shouldn't the _start (or most of the PowerPC 'hal_cpu_init') routine unlock
these keys during startup?   I believe they should.  All it would take is
the following set of instructions (or something similar):

        lwi     r3, CYGARC_REG_IMM_BASE
        stw     r4, (CYGARC_REG_IMM_TBK-CYGARC_REG_IMM_BASE)(r3)	

--
On a similar topic, why set these the timebase to zero anyway?   They are
set by default at power-on reset to zero and then never used anywhere else
in eCos from what I can tell.   This would allow an application to use the
timebase any way the wanted to without having to touch Vectors.s.  Note that
if you do remove the setting of the timebase to zero, you will still need to
make sure that the TBK register is unlocked since eCos will want to set the
decrementer register later on since it is used by the scheduler.

--
Finally, I'm curious what everyone thinks about keeping keys for other
registers locked anyway.  It would seem that it is better to protect against
accidental writes to the protected registers, but also if your accidentally
writing to SPR's and areas in the SIU randomly, you have bigger troubles.
My vote is to lock at least the timebase/decrementer (TBK) key to help
insure that the decrementer value is never corrupted.   All others keys
should be left up the application or module that uses them to decide what is
best.

	Chip Boling
	BCSW


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss