Re: [microblaze-uclinux] [patch test] syscall interface cleanup

[Yasushi SHOJI <yashi@xxxxxxxxxxxxxxxxx>]

At Sun, 17 Oct 2004 15:33:01 +1000,
John Williams wrote:
> 
> Hi Yashi,
> 
> Yasushi SHOJI wrote:
> 
> > John Williams wrote:
> > 
> >>Microblaze has a dedicated "break" instruction - brki - which is much 
> >>preferred over branch, because it is the closest thing we have to a real 
> >>"kernel trap" instruction.  In particular, it sets a bit in the flags 
> >>register (BIP - break in progress) that masks interrupts.  This supports 
> >>a cleaner approach in the kernel system call entry point.
> > 
> > 
> > I thought "break" inst. is for debugger.  I haven't look at you patch
> > just yet, but does it work for both trap _and_ break?
> 
> Sorry I should have explained better.
> 
> Yes, both syscall and debug trap are now invoked with brki instruction.
> 
> syscall:   brki	r14, 0x08
> db_trap:   brki r14, 0x30 (brki instruction written into program code by 
> debugger, then removed after the debug trap handler.
> 
> In a new version of the patch (coming soon) I'm changing over to use r14 
> as the link register for syscalls, instead of r17 as it is currently. 
> r17 is used by the hardware exceptions, so there is a chance of 
> corruption if a non-maskable HW exception occurs after syscall 
> invokation but before state save completes...
> 
> r14 is safe because the BRKI sets BIP bit in flags, which masks 
> interrupts.  No interrupt can occur until after state save, and the 
> syscall/db_trap return address is safely saved.

ok, thanks for the clarification.

> Also following some discussions with Goran I'll change the debug trap to 
> use vector 0x30, rather than 0x18 as currently used.  0x18 is 
> auto-vectored from an NMI or ext_brk hardware break, and so should not 
> be doubled up with the debug trap.  0x20 is used by the new microblaze 
> exceptions (unaligned access, divide by zero, page fault... ;-) , and 
> I'll leave 0x28 free in case Goran decides to add any more HW exception 
>   vectors :)

I noticed "page fault" and

At Sun, 17 Oct 2004 16:10:18 +1000,
John Williams wrote:
[...]
> +	.org	0x28
> +	//brai	C_SYMBOL_NAME(mmu_ex);	// MMU exception

any comments on this? ;)  there is a comment in Answer database
#12421, which is dated 10/16/01 saying that:

> In the future, we will implement full memory management (libraries
> and hardware MMU) that will make this option available.

So, "the future" might be very near. :)

regards,
--
               yashi
___________________________
microblaze-uclinux mailing list
microblaze-uclinux@itee.uq.edu.au
Project Home Page : http://www.itee.uq.edu.au/~jwilliams/mblaze-uclinux
Mailing List Archive : http://www.itee.uq.edu.au/~listarch/microblaze-uclinux/