From mboxrd@z Thu Jan 1 00:00:00 1970 From: Matthew Fortune Date: Mon, 26 Sep 2016 19:03:27 +0000 Subject: [U-Boot] [PATCH 2/9] MIPS: fix ROM exception vectors In-Reply-To: References: <20160925180532.19800-1-daniel.schwierzeck@gmail.com> <20160925180532.19800-3-daniel.schwierzeck@gmail.com> <6D39441BF12EF246A7ABCE6654B023537E511886@HHMAIL01.hh.imgtec.org> Message-ID: <6D39441BF12EF246A7ABCE6654B023537E512B52@HHMAIL01.hh.imgtec.org> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Daniel Schwierzeck writes: > 2016-09-26 9:58 GMT+02:00 Matthew Fortune : > > Daniel Schwierzeck 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