[PATCH]: linux-2.6.21-uc0 (MMU-less updates)

[PATCH]: linux-2.6.21-uc0 (MMU-less updates)

[Greg Ungerer]

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.

http://www.uclinux.org/pub/uClinux/uClinux-2.6.x/linux-2.6.21-uc0.patch.gz


Change log:

. Arctururs UC5272 and UC5282 board support        David Wu
. use THREAD_SIZE for stack manipulation           Philippe De Muyter
. remove dead code from setup.c                    Greg Ungerer
. remove dead cache code from mm                   Greg Ungerer
. remove useless is_in_rom()                       Greg Ungerer
. consolidate fixed bootparam code                 Greg Ungerer
. no need to preserve THREAD_SR in resume          Philippe De Muyter
. implement irq_regs in interrupt service          Greg Ungerer
. remove machine specific irq code                 Greg Ungerer
. fix timer step count for ColdFire                Philippe De Muyter
. add chip select mappings for cobra5329           Thomas Brinker
. remove old machine specific clock defines        Greg Ungerer
. improve readability of fec driver code           Philippe De Muyter
. do not read ICR before writing in fec driver     Philippe De Muyter
. fix INIT_WORK usage in fec driver                Greg Ungerer
. remove legacy PM code in 68328 serial driver     Greg Ungerer
. fix errno reporting in binfmt_flat loader        Philippe De Muyter
. create hw_irq.h for m68knommu                    Greg Ungerer
. fix CLOCK_TICK_RATE for m68knommu                Philippe De Muyter
. add expand_stack() funtcion to nommu             Greg Ungerer
. move to platform device setup for 520x           Greg Ungerer
. move to platform device setup for 5249           Greg Ungerer
. new style serial driver for ColdFire UART        Greg Ungerer
. add QSPI defines for 528x ColdFire parts         David Wu
. improve SoC device defines for 523x ColdFire     Thomas Brinker


Regards
Greg


------------------------------------------------------------------------
Greg Ungerer  --  Chief Software Dude       EMAIL:     gerg@snapgear.com
SnapGear -- a division of Secure Computing  PHONE:       +61 7 3435 2888
825 Stanley St,                             FAX:         +61 7 3891 3630
Woolloongabba, QLD, 4102, Australia         WEB: http://www.SnapGear.com

Re: [PATCH]: linux-2.6.21-uc0 (MMU-less updates)

[Robin Getz]

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 code.
>
> http://www.uclinux.org/pub/uClinux/uClinux-2.6.x/linux-2.6.21-uc0.patch.gz

Greg:

Is is possible to split out the m68k stuff from the generic nommu stuff? (or 
maybe I am missing the point of this patch? - it is for review/inclusion into 
the -mm tree, or just for end users wanting to use 2.6.21?)

The patch is labeled uClinux (MMU-less), which I read as generic, but the 
majority has to do with only m68knommu.

 arch/m68knommu/Kconfig                   |   12
 arch/m68knommu/Makefile                  |    4
 arch/m68knommu/kernel/process.c          |    2
 arch/m68knommu/kernel/setup.c            |  116 +---
 arch/m68knommu/kernel/time.c             |    9
 arch/m68knommu/mm/memory.c               |  100 ---
 arch/m68knommu/platform/5206/config.c    |    8
 arch/m68knommu/platform/5206e/config.c   |    7
 arch/m68knommu/platform/520x/config.c    |  122 ++++
 arch/m68knommu/platform/523x/config.c    |    8
 arch/m68knommu/platform/5249/config.c    |   51 +
 arch/m68knommu/platform/5272/config.c    |    7
 arch/m68knommu/platform/527x/config.c    |    7
 arch/m68knommu/platform/528x/config.c    |    7
 arch/m68knommu/platform/5307/config.c    |    5
 arch/m68knommu/platform/5307/entry.S     |   20
 arch/m68knommu/platform/5307/ints.c      |   23
 arch/m68knommu/platform/5307/timers.c    |   10
 arch/m68knommu/platform/532x/config.c    |   46 +
 arch/m68knommu/platform/5407/config.c    |    7
 arch/m68knommu/platform/68328/config.c   |    3
 arch/m68knommu/platform/68360/config.c   |    2
 arch/m68knommu/platform/68EZ328/config.c |    2
 arch/m68knommu/platform/68VZ328/config.c |    7
 include/asm-m68knommu/dma.h              |    2
 include/asm-m68knommu/hw_irq.h           |    4
 include/asm-m68knommu/m528xsim.h         |    3
 include/asm-m68knommu/m532xsim.h         |   85 ++-
 include/asm-m68knommu/machdep.h          |   50 -
 include/asm-m68knommu/mcfuart.h          |   11
 include/asm-m68knommu/pgtable.h          |    7
 include/asm-m68knommu/timex.h            |   24
 include/asm-m68knommu/uaccess.h          |   11
 drivers/net/fec.c                        |   71 +-
 drivers/serial/68328serial.c             |   59 --
 drivers/serial/mcf.c                     |  826 +++++++++++++++++++++++++++++

The only generic stuff is:

 Makefile                                 |    2
 drivers/pci/pci.c                        |    2
 fs/binfmt_flat.c                         |    2
 fs/namei.c                               |    2
 mm/nommu.c                               |   15
 mm/page_alloc.c                          |    8

I looked at those, and had a question:

(copy and paste screws up the formatting, sorry):

> 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.000000000 +1000
> +++ linux-2.6.21-uc0/fs/namei.c 2007-05-01 17:16:18.000000000 +1000
> @@ -120,12 +120,14 @@
>         int retval;
>         unsigned long len = PATH_MAX;
>
> +#ifdef CONFIG_MMU
>         if (!segment_eq(get_fs(), KERNEL_DS)) {
>                 if ((unsigned long) filename >= TASK_SIZE)
>                         return -EFAULT;
>                 if (TASK_SIZE - (unsigned long) filename < PATH_MAX)
>                         len = TASK_SIZE - (unsigned long) filename;
>         }
> +#endif
>
>         retval = strncpy_from_user(page, filename, len);
>         if (retval > 0) {

I was trying to understand why we don't want to do the same checking on noMMU?

Thanks
-Robin

Re: [PATCH]: linux-2.6.21-uc0 (MMU-less updates)

[Christoph Hellwig]

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.

Re: [PATCH]: linux-2.6.21-uc0 (MMU-less updates)

[Greg Ungerer]

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 gone quite badly out of sync once again.

Yes, I have already started the process. I have sent quite
a few of these to Linus in the last few hours.

Regards
Greg


-- 
------------------------------------------------------------------------
Greg Ungerer  --  Chief Software Dude       EMAIL:     gerg@snapgear.com
SnapGear -- a Secure Computing Company      PHONE:       +61 7 3435 2888
825 Stanley St,                             FAX:         +61 7 3891 3630
Woolloongabba, QLD, 4102, Australia         WEB: http://www.SnapGear.com

Re: [PATCH]: linux-2.6.21-uc0 (MMU-less updates)

[Greg Ungerer]

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 switching to
>> the generic irq code.
>>
>> http://www.uclinux.org/pub/uClinux/uClinux-2.6.x/linux-2.6.21-uc0.patch.gz
> 
> Greg:
> 
> Is is possible to split out the m68k stuff from the generic nommu stuff?

I could do that. Usually the actual mm changes have been
a pretty small set of this. Often only 1 or 2 patches.


> (or 
> maybe I am missing the point of this patch? - it is for review/inclusion into 
> the -mm tree, or just for end users wanting to use 2.6.21?)

This is specifically for review and inclusion in main line.


> The patch is labeled uClinux (MMU-less), which I read as generic, but the 
> majority has to do with only m68knommu.

Well, if any non-mmu architecture people sent me patches that
made sense for me to push upstream I would include them here.
But that doesn't happen very often. They generally do it
themselves.

Historically the first -uc patches had m68knommu, h8300 and v850
as well as the non-mmu changes in it.


>  arch/m68knommu/Kconfig                   |   12
>  arch/m68knommu/Makefile                  |    4
>  arch/m68knommu/kernel/process.c          |    2
>  arch/m68knommu/kernel/setup.c            |  116 +---
>  arch/m68knommu/kernel/time.c             |    9
>  arch/m68knommu/mm/memory.c               |  100 ---
>  arch/m68knommu/platform/5206/config.c    |    8
>  arch/m68knommu/platform/5206e/config.c   |    7
>  arch/m68knommu/platform/520x/config.c    |  122 ++++
>  arch/m68knommu/platform/523x/config.c    |    8
>  arch/m68knommu/platform/5249/config.c    |   51 +
>  arch/m68knommu/platform/5272/config.c    |    7
>  arch/m68knommu/platform/527x/config.c    |    7
>  arch/m68knommu/platform/528x/config.c    |    7
>  arch/m68knommu/platform/5307/config.c    |    5
>  arch/m68knommu/platform/5307/entry.S     |   20
>  arch/m68knommu/platform/5307/ints.c      |   23
>  arch/m68knommu/platform/5307/timers.c    |   10
>  arch/m68knommu/platform/532x/config.c    |   46 +
>  arch/m68knommu/platform/5407/config.c    |    7
>  arch/m68knommu/platform/68328/config.c   |    3
>  arch/m68knommu/platform/68360/config.c   |    2
>  arch/m68knommu/platform/68EZ328/config.c |    2
>  arch/m68knommu/platform/68VZ328/config.c |    7
>  include/asm-m68knommu/dma.h              |    2
>  include/asm-m68knommu/hw_irq.h           |    4
>  include/asm-m68knommu/m528xsim.h         |    3
>  include/asm-m68knommu/m532xsim.h         |   85 ++-
>  include/asm-m68knommu/machdep.h          |   50 -
>  include/asm-m68knommu/mcfuart.h          |   11
>  include/asm-m68knommu/pgtable.h          |    7
>  include/asm-m68knommu/timex.h            |   24
>  include/asm-m68knommu/uaccess.h          |   11
>  drivers/net/fec.c                        |   71 +-
>  drivers/serial/68328serial.c             |   59 --
>  drivers/serial/mcf.c                     |  826 +++++++++++++++++++++++++++++
> 
> The only generic stuff is:
> 
>  Makefile                                 |    2
>  drivers/pci/pci.c                        |    2
>  fs/binfmt_flat.c                         |    2
>  fs/namei.c                               |    2
>  mm/nommu.c                               |   15
>  mm/page_alloc.c                          |    8
> 
> I looked at those, and had a question:
> 
> (copy and paste screws up the formatting, sorry):
> 
>> 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.000000000 +1000
>> +++ linux-2.6.21-uc0/fs/namei.c 2007-05-01 17:16:18.000000000 +1000
>> @@ -120,12 +120,14 @@
>>         int retval;
>>         unsigned long len = PATH_MAX;
>>
>> +#ifdef CONFIG_MMU
>>         if (!segment_eq(get_fs(), KERNEL_DS)) {
>>                 if ((unsigned long) filename >= TASK_SIZE)
>>                         return -EFAULT;
>>                 if (TASK_SIZE - (unsigned long) filename < PATH_MAX)
>>                         len = TASK_SIZE - (unsigned long) filename;
>>         }
>> +#endif
>>
>>         retval = strncpy_from_user(page, filename, len);
>>         if (retval > 0) {
> 
> 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
addresses. TASK_SIZE may well be a numerically smaller number
than the address range that RAM sits in. So this test fails when
it shouldn't.

Regards
Greg


------------------------------------------------------------------------
Greg Ungerer  --  Chief Software Dude       EMAIL:     gerg@snapgear.com
SnapGear -- a Secure Computing Company      PHONE:       +61 7 3435 2888
825 Stanley St,                             FAX:         +61 7 3891 3630
Woolloongabba, QLD, 4102, Australia         WEB: http://www.SnapGear.com

Re: [PATCH]: linux-2.6.21-uc0 (MMU-less updates)

[Robin Getz]

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.000000000 +1000
> >> +++ linux-2.6.21-uc0/fs/namei.c 2007-05-01 17:16:18.000000000 +1000
> >> @@ -120,12 +120,14 @@
> >>         int retval;
> >>         unsigned long len = PATH_MAX;
> >>
> >> +#ifdef CONFIG_MMU
> >>         if (!segment_eq(get_fs(), KERNEL_DS)) {
> >>                 if ((unsigned long) filename >= TASK_SIZE)
> >>                         return -EFAULT;
> >>                 if (TASK_SIZE - (unsigned long) filename < PATH_MAX)
> >>                         len = TASK_SIZE - (unsigned long) filename;
> >>         }
> >> +#endif
> >>
> >>         retval = strncpy_from_user(page, filename, len);
> >>         if (retval > 0) {
> >
> > 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
> addresses. TASK_SIZE may well be a numerically smaller number
> than the address range that RAM sits in. So this test fails when
> it shouldn't.

So, then this is a problem only on one or two architectures, not all noMMU 
platforms?

-Robin

Re: [PATCH]: linux-2.6.21-uc0 (MMU-less updates)

[Greg Ungerer]

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.000000000 +1000
>>>> +++ linux-2.6.21-uc0/fs/namei.c 2007-05-01 17:16:18.000000000 +1000
>>>> @@ -120,12 +120,14 @@
>>>>         int retval;
>>>>         unsigned long len = PATH_MAX;
>>>>
>>>> +#ifdef CONFIG_MMU
>>>>         if (!segment_eq(get_fs(), KERNEL_DS)) {
>>>>                 if ((unsigned long) filename >= TASK_SIZE)
>>>>                         return -EFAULT;
>>>>                 if (TASK_SIZE - (unsigned long) filename < PATH_MAX)
>>>>                         len = TASK_SIZE - (unsigned long) filename;
>>>>         }
>>>> +#endif
>>>>
>>>>         retval = strncpy_from_user(page, filename, len);
>>>>         if (retval > 0) {
>>> 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
>> addresses. TASK_SIZE may well be a numerically smaller number
>> than the address range that RAM sits in. So this test fails when
>> it shouldn't.
> 
> So, then this is a problem only on one or two architectures, not all noMMU 
> platforms?

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.

Regards
Greg



------------------------------------------------------------------------
Greg Ungerer  --  Chief Software Dude       EMAIL:     gerg@snapgear.com
SnapGear -- a Secure Computing Company      PHONE:       +61 7 3435 2888
825 Stanley St,                             FAX:         +61 7 3891 3630
Woolloongabba, QLD, 4102, Australia         WEB: http://www.SnapGear.com

Re: [PATCH]: linux-2.6.21-uc0 (MMU-less updates)

[Robin Getz]

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
> >> addresses. TASK_SIZE may well be a numerically smaller number
> >> than the address range that RAM sits in. So this test fails when
> >> it shouldn't.
> >
> > So, then this is a problem only on one or two architectures, not all
> > noMMU platforms?
>
> 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 - it looks like everyone else forces it 
to end of memory, except 68k[nommu].

asm-arm/memory.h:#define TASK_SIZE              (CONFIG_DRAM_SIZE)
asm-blackfin/processor.h:#define TASK_SIZE      (memory_end)
asm-frv/mem-layout.h:#define TASK_SIZE                  __UL(0xFFFFFFFFUL)

asm-m68k/processor.h:#define TASK_SIZE  (0xF0000000UL)
asm-m68k/processor.h:#define TASK_SIZE  (0x0E000000)
asm-m68k/processor.h:#define TASK_SIZE  (0x0E000000UL)
asm-m68knommu/processor.h:#define TASK_SIZE     (0xF0000000UL)

I'm happy to learn we are doing something wrong, but I think that we just 
copied the arm/frv setup.

-Robin

Re: [PATCH]: linux-2.6.21-uc0 (MMU-less updates)

[Greg Ungerer]

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
>>>> addresses. TASK_SIZE may well be a numerically smaller number
>>>> than the address range that RAM sits in. So this test fails when
>>>> it shouldn't.
>>> So, then this is a problem only on one or two architectures, not all
>>> noMMU platforms?
>> 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 - it looks like everyone else forces it 
> to end of memory, except 68k[nommu].
> 
> asm-arm/memory.h:#define TASK_SIZE              (CONFIG_DRAM_SIZE)
> asm-blackfin/processor.h:#define TASK_SIZE      (memory_end)
> asm-frv/mem-layout.h:#define TASK_SIZE                  __UL(0xFFFFFFFFUL)
> 
> asm-m68k/processor.h:#define TASK_SIZE  (0xF0000000UL)
> asm-m68k/processor.h:#define TASK_SIZE  (0x0E000000)
> asm-m68k/processor.h:#define TASK_SIZE  (0x0E000000UL)
> asm-m68knommu/processor.h:#define TASK_SIZE     (0xF0000000UL)

Probably too:

asm-sh/processor.h:#define TASK_SIZE    0x7c000000UL

which has some parts with MMU.

There have been others out of tree that have it like this to.


> I'm happy to learn we are doing something wrong, but I think that we just 
> copied the arm/frv setup.

That is one way to handle it. Have you followed all the other
uses of TASK_SIZE and verified it is not a problem?

Regards
Greg



------------------------------------------------------------------------
Greg Ungerer  --  Chief Software Dude       EMAIL:     gerg@snapgear.com
SnapGear -- a Secure Computing Company      PHONE:       +61 7 3435 2888
825 Stanley St,                             FAX:         +61 7 3891 3630
Woolloongabba, QLD, 4102, Australia         WEB: http://www.SnapGear.com

Re: [PATCH]: linux-2.6.21-uc0 (MMU-less updates)

[Robin Getz]

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 problem is on systems that have RAM mapped at high physical
> >>>> addresses. TASK_SIZE may well be a numerically smaller number
> >>>> than the address range that RAM sits in. So this test fails when
> >>>> it shouldn't.

Put the patch back, since I added some new cc'

 > 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.000000000 +1000
 > +++ linux-2.6.21-uc0/fs/namei.c 2007-05-01 17:16:18.000000000 +1000
 > @@ -120,12 +120,14 @@
 >         int retval;
 >         unsigned long len = PATH_MAX;
 >
 > +#ifdef CONFIG_MMU
 >         if (!segment_eq(get_fs(), KERNEL_DS)) {
 >                 if ((unsigned long) filename >= TASK_SIZE)
 >                         return -EFAULT;
 >                 if (TASK_SIZE - (unsigned long) filename < PATH_MAX)
 >                         len = TASK_SIZE - (unsigned long) filename;
 >         }
 > +#endif
 >
 >         retval = strncpy_from_user(page, filename, len);
 >         if (retval > 0) {


> >>>
> >>> So, then this is a problem only on one or two architectures, not all
> >>> noMMU platforms?
> >>
> >> 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 - it looks like everyone else
> > forces it to end of memory, except 68k[nommu].
> >
> > asm-arm/memory.h:#define TASK_SIZE              (CONFIG_DRAM_SIZE)
> > asm-blackfin/processor.h:#define TASK_SIZE      (memory_end)
> > asm-frv/mem-layout.h:#define TASK_SIZE                 
> > __UL(0xFFFFFFFFUL)
> >
> > asm-m68k/processor.h:#define TASK_SIZE  (0xF0000000UL)
> > asm-m68k/processor.h:#define TASK_SIZE  (0x0E000000)
> > asm-m68k/processor.h:#define TASK_SIZE  (0x0E000000UL)
> > asm-m68knommu/processor.h:#define TASK_SIZE     (0xF0000000UL)
>
> Probably too:
>
> asm-sh/processor.h:#define TASK_SIZE    0x7c000000UL
>
> which has some parts with MMU.
>
> There have been others out of tree that have it like this to.
>
> > I'm happy to learn we are doing something wrong, but I think that we just
> > copied the arm/frv setup.
>
> That is one way to handle it. Have you followed all the other
> uses of TASK_SIZE and verified it is not a problem?

No, I assumed that Russell/David were smarter than we were, and that doing so 
would not be a problem :)

Not looking at ./arch or ./include TASK_SIZE looks like it is only used in 

fs/hugetlbfs/inode.c
fs/binfmt_elf.c
fs/namespace.c
fs/binfmt_aout.c
fs/namei.c
kernel/kexec.c
mm/mremap.c
mm/mempolicy.c
mm/memory.c 
mm/nommu.c 
mm/mmap.c

I poked through some, and from first glance, it mostly looked OK with setting 
TASK_SIZE to CONFIG_DRAM_SIZE or memory_end.

-Robin

Re: [PATCH]: linux-2.6.21-uc0 (MMU-less updates)

[Russell King]

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 followed all the other
> > uses of TASK_SIZE and verified it is not a problem?
> 
> No, I assumed that Russell/David were smarter than we were, and that doing so 
> would not be a problem :)

Don't look at me - the above came from Hyok, and I just assumed that it
was correct without really understanding it.

I've noticed though that Hyok's gone rather quiet, so I'm not sure
whether we'll ever get ARM uclinux integration complete.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:

Re: [PATCH]: linux-2.6.21-uc0 (MMU-less updates)

[Paul Mundt]

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 - it looks like everyone else forces 
> >it to end of memory, except 68k[nommu].
> >
> >asm-arm/memory.h:#define TASK_SIZE              (CONFIG_DRAM_SIZE)
> >asm-blackfin/processor.h:#define TASK_SIZE      (memory_end)
> >asm-frv/mem-layout.h:#define TASK_SIZE                  __UL(0xFFFFFFFFUL)
> >
> >asm-m68k/processor.h:#define TASK_SIZE  (0xF0000000UL)
> >asm-m68k/processor.h:#define TASK_SIZE  (0x0E000000)
> >asm-m68k/processor.h:#define TASK_SIZE  (0x0E000000UL)
> >asm-m68knommu/processor.h:#define TASK_SIZE     (0xF0000000UL)
> 
> Probably too:
> 
> asm-sh/processor.h:#define TASK_SIZE    0x7c000000UL
> 
> which has some parts with MMU.
> 
> There have been others out of tree that have it like this to.
> 
It would be at 0x80000000UL on SH if it weren't for address space area
limitations. The 0x7c000000 - 0x7fffffff space is used for shadowing P4
registers in the virtual address space (area 7) with the MMU and it's a
reserved area without the MMU, so TASK_SIZE is trimmed right before this.

However, I'm not sure that the patch Greg has in this set is sufficient
for the problem described. do_mmap_pgoff() won't allow a > TASK_SIZE
mapping anyways. In the SH case we certainly have address spaces that
can be given user permissions well above TASK_SIZE, area 7 space is used
as a bit of a hack for some of this in the MMU case..

Re: [PATCH]: linux-2.6.21-uc0 (MMU-less updates)

[Greg Ungerer]

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. Have you followed all the other
>>> uses of TASK_SIZE and verified it is not a problem?
>> No, I assumed that Russell/David were smarter than we were, and that doing so 
>> would not be a problem :)
> 
> Don't look at me - the above came from Hyok, and I just assumed that it
> was correct without really understanding it.
> 
> I've noticed though that Hyok's gone rather quiet, so I'm not sure
> whether we'll ever get ARM uclinux integration complete.

We can do this without Hyok.

The patches I sent to arm-linux-kernel last week fill all the gaps
that I see. I'll be reworking that over the coming weeks to try and
get something that is acceptable to all, so we can get this done.

Regards
Greg



------------------------------------------------------------------------
Greg Ungerer  --  Chief Software Dude       EMAIL:     gerg@snapgear.com
SnapGear -- a Secure Computing Company      PHONE:       +61 7 3435 2888
825 Stanley St,                             FAX:         +61 7 3891 3630
Woolloongabba, QLD, 4102, Australia         WEB: http://www.SnapGear.com