Russell King wrote:
On Fri, May 04, 2007 at 12:12:03PM -0400, Robin Getz wrote:
Depending on how TASK_SIZE is defined - it looks like everyone else
forces it to end of memory, except 68k[nommu].
asm-arm/memory.h:#define TASK_SIZE (CONFIG_DRAM_SIZE)
That is one way to handle it. Ha
On Thu, May 03, 2007 at 11:30:53PM +1000, Greg Ungerer wrote:
> Robin Getz wrote:
> >>Its not an architecture problem. It can effect any board that
> >>has RAM mapped at a large numerical addresses (larger than TASK_SIZE).
> >>So it can effect any non-MMU platform.
> >
> >Depending on how TASK_SIZE
On Fri, May 04, 2007 at 12:12:03PM -0400, Robin Getz wrote:
> > > Depending on how TASK_SIZE is defined - it looks like everyone else
> > > forces it to end of memory, except 68k[nommu].
> > >
> > > asm-arm/memory.h:#define TASK_SIZE (CONFIG_DRAM_SIZE)
> >
> > That is one way to handle
On Thu 3 May 2007 09:30, Greg Ungerer pondered:
> Robin Getz wrote:
> > On Thu 3 May 2007 07:03, Greg Ungerer pondered:
> >> Robin Getz wrote:
> >>> On Wed 2 May 2007 07:32, Greg Ungerer pondered:
> Robin Getz wrote:
> > I was trying to understand why we don't want to do the same checking
Robin Getz wrote:
On Thu 3 May 2007 07:03, Greg Ungerer pondered:
Robin Getz wrote:
On Wed 2 May 2007 07:32, Greg Ungerer pondered:
Robin Getz wrote:
I was trying to understand why we don't want to do the same checking on
noMMU?
The problem is on systems that have RAM mapped at high physical
On Thu 3 May 2007 07:03, Greg Ungerer pondered:
> Robin Getz wrote:
> > On Wed 2 May 2007 07:32, Greg Ungerer pondered:
> >> Robin Getz wrote:
> >>> I was trying to understand why we don't want to do the same checking on
> >>> noMMU?
> >>
> >> The problem is on systems that have RAM mapped at high
Robin Getz wrote:
On Wed 2 May 2007 07:32, Greg Ungerer pondered:
Robin Getz wrote:
On Wed 2 May 2007 01:23, Greg Ungerer pondered:
diff -Naur linux-2.6.21/fs/namei.c linux-2.6.21-uc0/fs/namei.c
--- linux-2.6.21/fs/namei.c 2007-05-01 17:12:53.0 +1000
+++ linux-2.6.21-uc0/fs/namei.c
On Wed 2 May 2007 07:32, Greg Ungerer pondered:
> Robin Getz wrote:
> > On Wed 2 May 2007 01:23, Greg Ungerer pondered:
> >> diff -Naur linux-2.6.21/fs/namei.c linux-2.6.21-uc0/fs/namei.c
> >> --- linux-2.6.21/fs/namei.c 2007-05-01 17:12:53.0 +1000
> >> +++ linux-2.6.21-uc0/fs/namei.c 2
Hi Robin,
Robin Getz wrote:
On Wed 2 May 2007 01:23, Greg Ungerer pondered:
Hi All,
An update of the uClinux (MMU-less) code against 2.6.21.
A lot of cleanups, and a few bug fixes.
Ahead is more changes to finalize platform device support
for the new style ColdFire serial driver, and switchi
Hi Christoph,
Christoph Hellwig wrote:
On Wed, May 02, 2007 at 03:23:33PM +1000, Greg Ungerer wrote:
Hi All,
An update of the uClinux (MMU-less) code against 2.6.21.
A lot of cleanups, and a few bug fixes.
Any chance you could split this into a few patches and send
upstream? m68knommu has g
On Wed, May 02, 2007 at 03:23:33PM +1000, Greg Ungerer wrote:
> Hi All,
>
> An update of the uClinux (MMU-less) code against 2.6.21.
> A lot of cleanups, and a few bug fixes.
Any chance you could split this into a few patches and send
upstream? m68knommu has gone quite badly out of sync once agai
On Wed 2 May 2007 01:23, Greg Ungerer pondered:
> Hi All,
>
> An update of the uClinux (MMU-less) code against 2.6.21.
> A lot of cleanups, and a few bug fixes.
>
> Ahead is more changes to finalize platform device support
> for the new style ColdFire serial driver, and switching to
> the generic i
12 matches
Mail list logo