| Message ID | 20160925180532.19800-3-daniel.schwierzeck@gmail.com |
|---|---|
| State | Superseded |
| Delegated to: | Daniel Schwierzeck |
| Headers | show |
Daniel Schwierzeck <daniel.schwierzeck@gmail.com> writes: > When booting from ROM, early exceptions can't be handled > properly. Instead of busy-looping give the developer the > possibilty to examine the situation. Thus issue a SDBBP > instruction to transfer control to hardware debugger if one > is attached. You could make the SDBBP into a UHI operation that can be read by a debugger as an unhandled exception rather than an unexpected breakpoint (assuming said debugger knows about UHI). The fragment I use in lightweight boot code is: move k0, t9 # Preserve t9 move k1, a0 # Preserve a0 li $25, 15 # UHI exception operation li $4, 0 # Use hard register context sdbbp 1 # Invoke UHI operation You lose k0/k1 in this which may be undesirable but it might be a reasonable trade off. This shouldn't go in the debug vector of course! Matthew
2016-09-26 9:58 GMT+02:00 Matthew Fortune <Matthew.Fortune@imgtec.com>: > Daniel Schwierzeck <daniel.schwierzeck@gmail.com> writes: >> When booting from ROM, early exceptions can't be handled >> properly. Instead of busy-looping give the developer the >> possibilty to examine the situation. Thus issue a SDBBP >> instruction to transfer control to hardware debugger if one >> is attached. > > You could make the SDBBP into a UHI operation that can be read by > a debugger as an unhandled exception rather than an unexpected > breakpoint (assuming said debugger knows about UHI). The fragment > I use in lightweight boot code is: > > move k0, t9 # Preserve t9 > move k1, a0 # Preserve a0 > li $25, 15 # UHI exception operation > li $4, 0 # Use hard register context > sdbbp 1 # Invoke UHI operation > > You lose k0/k1 in this which may be undesirable but it might > be a reasonable trade off. This shouldn't go in the debug vector > of course! > sounds interesting. I'll have a look into that. Can I test this with OpenOCD and GDB?
Daniel Schwierzeck <daniel.schwierzeck@gmail.com> writes: > 2016-09-26 9:58 GMT+02:00 Matthew Fortune <Matthew.Fortune@imgtec.com>: > > Daniel Schwierzeck <daniel.schwierzeck@gmail.com> writes: > >> When booting from ROM, early exceptions can't be handled > >> properly. Instead of busy-looping give the developer the > >> possibilty to examine the situation. Thus issue a SDBBP > >> instruction to transfer control to hardware debugger if one > >> is attached. > > > > You could make the SDBBP into a UHI operation that can be read by > > a debugger as an unhandled exception rather than an unexpected > > breakpoint (assuming said debugger knows about UHI). The fragment > > I use in lightweight boot code is: > > > > move k0, t9 # Preserve t9 > > move k1, a0 # Preserve a0 > > li $25, 15 # UHI exception operation > > li $4, 0 # Use hard register context > > sdbbp 1 # Invoke UHI operation > > > > You lose k0/k1 in this which may be undesirable but it might > > be a reasonable trade off. This shouldn't go in the debug vector > > of course! > > > > sounds interesting. I'll have a look into that. Can I test this with > OpenOCD and GDB? I'm sorry to say progress with getting UHI into OpenOCD is rather slow. The main effort for OpenOCD has been part of the MIPSfpga project which I am not directly involved with. To my knowledge they have the basic 'write' call implemented but are not handling all the operations and the implementation is out of tree. I'll try and check on this and let you know. I had an idea of using a special UHI operation to indicate a boot failure with a simple enumerated 'reason' code so you could get a quick hint at what blew up in low level boot code without the source. I.e. any errors that can be detected without ending up raising an exception. I put two quickly thought up errors into the UHI spec as an example but I only have some simplistic boot code to play with. If you think U-boot could have a range of errors to report like this (and want to use it) then we can add to the list. Matthew
diff --git a/arch/mips/cpu/start.S b/arch/mips/cpu/start.S index 108d2df..6886036 100644 --- a/arch/mips/cpu/start.S +++ b/arch/mips/cpu/start.S @@ -79,30 +79,30 @@ ENTRY(_start) #endif #if defined(CONFIG_ROM_EXCEPTION_VECTORS) + /* + * Exception vector entry points. When running from ROM, an exception + * cannot be handled. Halt execution and transfer control to debugger, + * if one is attached. + */ .org 0x200 /* TLB refill, 32 bit task */ -1: b 1b - nop + sdbbp .org 0x280 /* XTLB refill, 64 bit task */ -1: b 1b - nop + sdbbp .org 0x300 /* Cache error exception */ -1: b 1b - nop + sdbbp .org 0x380 /* General exception */ -1: b 1b - nop + sdbbp .org 0x400 /* Catch interrupt exceptions */ -1: b 1b - nop + sdbbp .org 0x480 /* EJTAG debug exception */ @@ -222,6 +222,7 @@ reset: move a0, zero # a0 <-- boot_flags = 0 PTR_LA t9, board_init_f + jr t9 move ra, zero
When booting from ROM, early exceptions can't be handled properly. Instead of busy-looping give the developer the possibilty to examine the situation. Thus issue a SDBBP instruction to transfer control to hardware debugger if one is attached. Signed-off-by: Daniel Schwierzeck <daniel.schwierzeck@gmail.com> --- arch/mips/cpu/start.S | 21 +++++++++++---------- 1 file changed, 11 insertions(+), 10 deletions(-)