Author: agraf
Date: Fri May 30 14:11:44 2014
New Revision: 1306
URL: http://tracker.coreboot.org/trac/openbios/changeset/1306
Log:
PPC: Pass real tbfreq to udelay
The IDE code waits for some operations to finish within a certain amount of
time. That waiting code delays based on the timebase, but doesn't know about
the frequency of the timebase.
In cases where we know the frequency - like via QEMU's fwcfg interface - base
the calculation on that frequency value.
This fixes issues where OpenBIOS thought it ran into IDE timeouts.
Signed-off-by: Alexander Graf <agraf(a)suse.de>
Modified:
trunk/openbios-devel/arch/ppc/qemu/init.c
trunk/openbios-devel/drivers/timer.c
Modified: trunk/openbios-devel/arch/ppc/qemu/init.c
==============================================================================
--- trunk/openbios-devel/arch/ppc/qemu/init.c Thu May 29 00:15:33 2014 (r1305)
+++ trunk/openbios-devel/arch/ppc/qemu/init.c Fri May 30 14:11:44 2014 (r1306)
@@ -220,6 +220,9 @@
#endif
}
+/* From drivers/timer.c */
+extern unsigned long timer_freq;
+
static void
cpu_generic_init(const struct cpudef *cpu)
{
@@ -279,7 +282,8 @@
push_str("tlb-size");
fword("property");
- PUSH(fw_cfg_read_i32(FW_CFG_PPC_TBFREQ));
+ timer_freq = fw_cfg_read_i32(FW_CFG_PPC_TBFREQ);
+ PUSH(timer_freq);
fword("encode-int");
push_str("timebase-frequency");
fword("property");
Modified: trunk/openbios-devel/drivers/timer.c
==============================================================================
--- trunk/openbios-devel/drivers/timer.c Thu May 29 00:15:33 2014 (r1305)
+++ trunk/openbios-devel/drivers/timer.c Fri May 30 14:11:44 2014 (r1306)
@@ -79,15 +79,11 @@
/*
* TODO: pass via lb table
*/
-
-unsigned long get_timer_freq(void)
-{
- return 10000000 / 4;
-}
+unsigned long timer_freq = 10000000 / 4;
void udelay(unsigned int usecs)
{
- unsigned long ticksperusec = get_timer_freq() / 1000000;
+ unsigned long ticksperusec = timer_freq / 1000000;
_wait_ticks(ticksperusec * usecs);
}
Do not put exception handler routines between 0x00-0xff as some OSes
use this area for their own purposes and can corrupt them. (In
particular MorphOS writes to 0x80 during boot). This patch frees up
this area by moving the routines that were there higher.
Signed-off-by: BALATON Zoltan <balaton(a)eik.bme.hu>
---
This replaces my previous attempt (Use exception vectors from ROM
instead of copying them to page zero) as that relied on the MSR[IP]
bit that was found not to be generally available.
Index: openbios-devel/arch/ppc/qemu/start.S
===================================================================
--- openbios-devel/arch/ppc/qemu/start.S (revision 1304)
+++ openbios-devel/arch/ppc/qemu/start.S (working copy)
@@ -280,21 +280,9 @@ GLOBL(__vectors):
1: nop //
b 1b
-call_dsi_exception:
- LOAD_REG_FUNC(r3, dsi_exception)
- mtctr r3
- bctrl
- b exception_return
+VECTOR( 0x100, "SRE" ):
+ b _entry
-call_isi_exception:
- LOAD_REG_FUNC(r3, isi_exception)
- mtctr r3
- bctrl
- b exception_return
-
-exception_return:
- EXCEPTION_EPILOGUE
-
trap_error:
lis r1, 0x8000 /* r1=0x80000000 */
add. r1,r1,r1 /* r1=r1+r1 (high 32bit !0) */
@@ -309,9 +297,6 @@ trap_error:
mtctr r4
bctr
-VECTOR( 0x100, "SRE" ):
- b _entry
-
ILLEGAL_VECTOR( 0x200 )
VECTOR( 0x300, "DSI" ):
@@ -373,11 +358,16 @@ VECTOR( 0x2200, "ISI_64" ):
real_dsi:
EXCEPTION_PREAMBLE
- b call_dsi_exception
+ LOAD_REG_FUNC(r3, dsi_exception)
+ b call_exception_handler
real_isi:
EXCEPTION_PREAMBLE
- b call_isi_exception
+ LOAD_REG_FUNC(r3, isi_exception)
+call_exception_handler:
+ mtctr r3
+ bctrl
+ EXCEPTION_EPILOGUE
GLOBL(__vectors_end):
On Mon, 26 May 2014, Mark Cave-Ayland wrote:
> Just as a general comment: I know that some OSs using Sun's PROM expect
> to be able to write to the trap table (which is why it is copied to RAM)
> so you'd need to check this thoroughly. Or, if MSR_IP uses virtual
> addresses you could do some MMU twiddling so that the virtual address
> actually points into a safe area of RAM rather than ROM.
As far as I understand MSR_IP just selects between exception vectors at
0x0 or 0xfff00000. Clients normaly use the vectors at page zero while the
latter is typically used for ROM based boot code. Also I think the ROM is
already copied to RAM anyway so it can be overwritten by the clients
(MorophOS does this later after finished calling OF client interface
functions or maybe it maps some RAM over it I'm not sure). In any case,
clients should not modify the firmware code and I think they use vectors
at 0x0.
> As a starting point, have you tried booting any other OS with this
> change?
Yes but not very throughly. The Darwin images boot as far as before and
Finnix has a different issue due to the change in cuda to via pmu where
the IRQ is handled differently. I intend to fix that later by adding a USB
driver to OpenBIOS and use that as the real hardware has USB instead of
ADB anyway. This would also fix qemu-system-ppc64 with -M mac99. I already
have a version here:
http://www.openfirmware.info/pipermail/openbios/2014-May/008244.html
but I'll need to fix it to work on big endian systems.
> For my OpenBIOS tests I have a collection of various NetBSD,
> FreeBSD, Linux, Darwin and HelenOS that I use to check for regressions.
It would be appreciated if you could do some tests with these.
Regards,
BALATON Zoltan
On 28.05.14 21:07, BALATON Zoltan wrote:
> Remove duplicated code from the handlers for DSI and ISI exceptions.
>
> Signed-off-by: BALATON Zoltan <balaton(a)eik.bme.hu>
I can't say I'm a big fan of this patch. Jumping from one handler into
another is a big red flag to me. If you really think it's worth to
consolidate these 3 instructions, please create a separate
call_exception_handler function that you call from the DSI and ISI handler.
Alex
> ---
> openbios-devel/arch/ppc/qemu/start.S | 8 ++------
> 1 file changed, 2 insertions(+), 6 deletions(-)
>
> diff --git a/openbios-devel/arch/ppc/qemu/start.S b/openbios-devel/arch/ppc/qemu/start.S
> index ae2fd53..5aa8c62 100644
> --- a/openbios-devel/arch/ppc/qemu/start.S
> +++ b/openbios-devel/arch/ppc/qemu/start.S
> @@ -359,18 +359,14 @@ VECTOR( 0x2200, "ISI_64" ):
> real_dsi:
> EXCEPTION_PREAMBLE
> LOAD_REG_FUNC(r3, dsi_exception)
> - mtctr r3
> - bctrl
> - b exception_return
> + b call_exception_handler
>
> real_isi:
> EXCEPTION_PREAMBLE
> LOAD_REG_FUNC(r3, isi_exception)
> +call_exception_handler:
> mtctr r3
> bctrl
> - b exception_return
> -
> -exception_return:
> EXCEPTION_EPILOGUE
>
> GLOBL(__vectors_end):
Author: agraf
Date: Thu May 29 00:15:33 2014
New Revision: 1305
URL: http://tracker.coreboot.org/trac/openbios/changeset/1305
Log:
arch/ppc/qemu: Moved exception handlers from beginning of RAM
Do not put exception handler routines between 0x00-0xff as some OSes
use this area for their own purposes and can corrupt them. (In
particular MorphOS writes to 0x80 during boot). This patch frees up
this area by moving the routines that were there higher.
Signed-off-by: BALATON Zoltan <balaton(a)eik.bme.hu>
Signed-off-by: Alexander Graf <agraf(a)suse.de>
Modified:
trunk/openbios-devel/arch/ppc/qemu/start.S
Modified: trunk/openbios-devel/arch/ppc/qemu/start.S
==============================================================================
--- trunk/openbios-devel/arch/ppc/qemu/start.S Sun May 25 11:50:05 2014 (r1304)
+++ trunk/openbios-devel/arch/ppc/qemu/start.S Thu May 29 00:15:33 2014 (r1305)
@@ -280,20 +280,8 @@
1: nop //
b 1b
-call_dsi_exception:
- LOAD_REG_FUNC(r3, dsi_exception)
- mtctr r3
- bctrl
- b exception_return
-
-call_isi_exception:
- LOAD_REG_FUNC(r3, isi_exception)
- mtctr r3
- bctrl
- b exception_return
-
-exception_return:
- EXCEPTION_EPILOGUE
+VECTOR( 0x100, "SRE" ):
+ b _entry
trap_error:
lis r1, 0x8000 /* r1=0x80000000 */
@@ -309,9 +297,6 @@
mtctr r4
bctr
-VECTOR( 0x100, "SRE" ):
- b _entry
-
ILLEGAL_VECTOR( 0x200 )
VECTOR( 0x300, "DSI" ):
@@ -373,11 +358,20 @@
real_dsi:
EXCEPTION_PREAMBLE
- b call_dsi_exception
+ LOAD_REG_FUNC(r3, dsi_exception)
+ mtctr r3
+ bctrl
+ b exception_return
real_isi:
EXCEPTION_PREAMBLE
- b call_isi_exception
+ LOAD_REG_FUNC(r3, isi_exception)
+ mtctr r3
+ bctrl
+ b exception_return
+
+exception_return:
+ EXCEPTION_EPILOGUE
GLOBL(__vectors_end):
On 28.05.14 21:03, BALATON Zoltan wrote:
> Do not put exception handler routines between 0x00-0xff as some OSes
> use this area for their own purposes and can corrupt them. (In
> particular MorphOS writes to 0x80 during boot). This patch frees up
> this area by moving the routines that were there higher.
>
> Signed-off-by: BALATON Zoltan <balaton(a)eik.bme.hu>
Thanks, applied to OpenBIOS.
Alex