On 01/02/14 20:54, Olivier Danet wrote:
romvec.pvtime is a pointer to a millisecond rate uptime counter. NextSTEP uses this counter for timing the 10 seconds timeout during boot, when asking for boot options.
For now, let's just set this to a constant, there is no timeout, but we avoid null pointer dereferencing.
Signed-off-by: Olivier Danet email@example.com
--- arch/sparc32/romvec.c (révision 1257) +++ arch/sparc32/romvec.c (copie de travail) @@ -26,7 +26,7 @@
char obp_stdin, obp_stdout; const char *obp_stdin_path, *obp_stdout_path;
+int32_t obp_ticks; struct linux_arguments_v0 obp_arg; const char *bootpath; static const struct linux_arguments_v0 * const obp_argp = &obp_arg; @@ -456,6 +456,8 @@ via their handler (see call-romvec.S) which acts as a proxy to save the globals and setup the stack correctly */
- obp_ticks = 10000; /* Dummy. Ticks should be the uptime, in
// Linux wants a R/W romvec table romvec0.pv_magic_cookie = LINUX_OPPROM_MAGIC; romvec0.pv_romvers = 3; @@ -479,6 +481,7 @@ romvec0.pv_reboot = obp_reboot_handler; romvec0.pv_printf = obp_printf_handler; romvec0.pv_abort = obp_abort_handler;
- romvec0.pv_ticks = &obp_ticks;
romvec0.pv_halt = obp_halt_handler; romvec0.pv_synchook = &sync_hook; romvec0.pv_v0bootargs = &obp_argp; ===================================================================
This patch looks basically good, however do we know how the timer is implemented with OBP? I don't think SPARCv8 has a tick instruction so my guess would be that one of the level 10/level 14 timer is being used - if this is the case then we can probably come up with something fairly easily.