On 07/02/2014 19:31, Mark Cave-Ayland wrote:
On 06/02/14 00:11, Olivier Danet wrote:
Timers are initialized in QEMU : hw/timer/slavio_timer.c : static void slavio_timer_reset(DeviceState *d)
According to the document "Sun-4M System Architecture" (which was once on Sun's website) "Upon power–on reset all four sets are configured as counter–timers. " = 0 "Upon reset all limit registers are set to 0x00000000. ". The zeroing made by QEMU seems correct.
There are many parts where the initialisation is incertain between QEMU and OpenBIOS.
For example, I have found two days ago that the Sun4m keyboard/mouse UART is never initialised by OpenBIOS, QEMU does not really care about the initialisation, and the specification says nothing about the default power-on state.
That wouldn't surprise me at all; there are some printenv variables somewhere which control the default serial port configuration but I can easily believe they are not used.
In terms of the the timer, I see the following comment in sun4m_irq.c from Linux:
/* For SMP we use the level 14 ticker, however the bootup code
- has copied the firmware's level 14 vector into the boot cpu's
- trap table, we must fix this now or we get squashed.
*/
This implies that OBP uses the level 14 timer itself (presumably part of this would increment the value of the get-msecs word) which should be fairly easy to emulate. Is anyone good enough with OBP/QEMU in order to tell if the level 14 timer is actually being programmed for the romvec ticks register?
For the other CPU timers, for now should we just explicitly set their control register to zero just to make sure they are disabled?
ATB,
Mark.
Yes indeed, the CPU timer is used for the tick counter, tracing timers registers accesses shows it.
I have a patch for the tick timer. It was much simpler than what I feared when writing the "dummy counter" stuff.
I need to look at that "get-msecs" command though...
Olivier.