On Tuesday, August 24, 2010 18:06:14 Steve Longerbeam wrote: > On 08/23/2010 01:18 PM, Mike Frysinger wrote: > > On Monday, August 23, 2010 14:16:30 Steve Longerbeam wrote: > >> sorry, I see CONFIG_MPU under blackfin in the 888 release. > >> > >> I'm not familiar with the blackfin arch, but my patches of course are > >> specific to ARM MPU's. > > > > i dont see how the processor matters. you're running Linux without > > virtual memory support (CONFIG_MMU=n) and you want to do memory > > protection (CONFIG_MPU=y). there is no need to stick a specific cpu > > name in there. after all, the option is CONFIG_MPU and not > > CONFIG_BFIN_MPU because all the changes we made (which were few) to > > common code were processor independent (exactly like all changes to > > common code should be). we specifically left the door open for other > > processors to support MMU=n MPU=y without an ifdef mess. -mike > > Hi Mike, I don't disagree with what you're saying, but I was a bit > confused because in the 888 kernel I was looking at, the common MPU code > didn't exist yet.
i focus on the mainline kernels, so my comments might be more up-to-date than some of the uclinux patchsets. cant say ive ever used any of them. > Apparently the ARM MPU's are not nearly as capable as the blackfin MPU. > The ARM MPU deals with whole regions, and typically only up to 8 memory > regions can be controlled by the MPU at any one time, each region having > one protection setting (r/w/x for kernel mode, r/w/x for user mode). Not > nearly as fine grained as per-page. i dont quite understand what you mean by "whole region". if you define a "region" as 4KiB, dont you get the granularity expected ? could you describe the flexibility/restrictions of this a little more (i'm not an ARM core guy) ? the Blackfin MPU has separate insn/data TLBs, and each TLB has 16 entries (PTEs i believe is the common naming). each PTE has supervisor rwx and usermode rwx permissions. further, each PTE has a size field which may be 1KiB, 4KiB, 1MiB, or 4MiB. i guess we cheat a little and we lock a PTE for the kernel itself so that it'll always be covered so we can process PTE misses without triggering a miss (nested exceptions). i'm not entirely familiar with the exact gory details of other arches, so i cant say how unique we are in this regard. > So ARM could use something higher-level than protect_page(), something > like protect_region(start, end, flags), or just all of protect_vma() > could be moved to include/asm/mmu_context.h. That way ARM can operate on > the whole region, while blackfin would add protection for every page in > the VMA as it is doing now. i think you could use the existing framework, and perhaps optionally extend it. maybe if i knew a little more about your "regions", i could suggest something else. > I'll work on another patch that better merges my original ARM MPU work > into the blackfin work, and resubmit. great, thanks > Btw, I probably should be working in whatever git tree people are > submitting patches against, rather than the 20100628 release. Which git > tree should I submit against? that's hard to say. if current mainline (2.6.36-rc2) has everything you need to boot a working system, then that is probably the place to base your work. i understand though that the arm/nommu work is taking a while to get into mainline, so that might not be feasible. in which case, you should find the very latest uclinux tree and use that. i know people like to base their work off a release, but in order to get merged, the focus has to be on the latest development tree. -mike
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
