Hi Steve,
On 25/08/10 08:43, Mike Frysinger wrote:
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.
What would be useful for people who don't use the dist is if you
list the linux-2.6 kernel version as well. Although there is some
patches on top, the base kernel version is usefull.
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.
Linus main line tree is really the only one that matters here.
For anything to go into mainline that is the most useful base.
A simple way to still build using the uClinux-dist build framework is
to just put you git tree clone in place of the linux-2.6.x directory
in it. You don't need to change anything else. I just take a linus
git tree clone and build my complete systems, and that is who I
build test the m68knommu git tree for example.
(As a side note, the core non-MMU for ARM is pretty much in. But there
is very little sub-architecture support - so you probably will have to
patch that into a mainline clone).
Regards
Greg
_______________________________________________
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
