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.
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.
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
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
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. Have you
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 is defined -
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
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
on noMMU?
The
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
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
+++
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 2007-05-01
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
+++
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
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
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
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
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
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
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 irq
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 again.
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
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
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 irq code.
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 irq code.
26 matches
Mail list logo
