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

[John Williams <jwilliams@xxxxxxxxxxxxxx>]

Hi Yashi,

Yasushi SHOJI wrote:
> At Sun, 17 Oct 2004 15:33:01 +1000,
> John Williams wrote:
>>
>>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? ;)  

Umm, wishful thinking on my part maybe? ;-)

OK I confess - I've been looking at the uClinux kernel to see what would 
be required to implement basic memory protection - happily the answer is 
"not too much, apart from the hardware support".  All the data 
structures are there, inherited from VM linux.  It even makes sense to 
add memory protection back in to uClinux, rather than "re-port" full VM 
linux down to microblaze.  Of course in 2.6 this is irrelevent, it's all 
the same kernel tree.

Unsurprisingly, life is much simpler (in HW and SW) if you say "OK, I 
don't need full virtual memory, just physical memory protection"..

We have thought about ways of adding memory protection support outside 
the microblaze (as a 3rd party core), but of course it is much more 
efficiently and effectively done inside the processor.

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. :)

As you see, the MMU concept has occurred to Xilinx long ago, if we can 
demonstrate that uClinux support would quickly follow, then that might 
be added encouragement!

Quite honestly I'll be surprised if both Xilinx and Altera don't come 
out with some form of MMU for their respective soft-processors in the 
next 12 months, it's just such an obvious thing to do.

Cheers,

John
___________________________
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/