: linux-2.6.21-uc0 (MMU-less updates)

PATCH In review Greg Ungerer 5 participants 13 messages May 2, 2007 – May 7, 2007

lore

Share & tools

lore

Greg Ungerer

author

2007-05-02 05:23 UTC #0 lore raw

PATCH 1/1 : linux-2.6.21-uc0 (MMU-less updates)

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:     [email protected]
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

Robin Getz

2007-05-02 08:55 UTC #1 lore raw

On Wed 2 May 2007 01:23, Greg Ungerer pondered:

Quoted 10 lines

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):

Quoted 8 lines

diff -Naur linux-2.6.21/fs/namei.c linux-2.6.21-uc0/fs/namei.c
fs/namei.c 2007-05-01 17:16:18.000000000 +1000 renamed from fs/namei.c 2007-05-01 17:12:53.000000000 +1000 +1 -0
@@ -120,12 +120,14 @@
        int retval;
        unsigned long len = PATH_MAX;
 
+#ifdef CONFIG_MMU

fs/namei.c 2007-05-01 17:16:18.000000000 +1000 line 133

Quoted 10 lines

fs/namei.c 2007-05-01 17:16:18.000000000 +1000 renamed from fs/namei.c 2007-05-01 17:12:53.000000000 +1000 +1 -0

        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

Greg Ungerer

author

2007-05-02 11:32 UTC #2 lore raw

Hi Robin,

Quoted 10 lines · Robin Getz

On Wed 2 May 2007 01:23, Greg Ungerer pondered:
Quoted 9 lines
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.

Quoted 5 lines

Quoted 1 line
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.

Quoted 1 line

(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.

Quoted 1 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.

Quoted 66 lines

 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):

Quoted 16 lines

diff -Naur linux-2.6.21/fs/namei.c linux-2.6.21-uc0/fs/namei.c

fs/namei.c 2007-05-01 17:16:18.000000000 +1000 renamed from fs/namei.c 2007-05-01 17:12:53.000000000 +1000 +2 -0

@@ -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

Quoted 4 lines

fs/namei.c 2007-05-01 17:16:18.000000000 +1000 line 133
Quoted 2 lines
fs/namei.c 2007-05-01 17:16:18.000000000 +1000 renamed from fs/namei.c 2007-05-01 17:12:53.000000000 +1000 +0 -0
        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:     [email protected]
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

Robin Getz

2007-05-03 10:53 UTC #3 lore raw

On Wed 2 May 2007 07:32, Greg Ungerer pondered:

Quoted 24 lines

Quoted 17 lines · Robin Getz
On Wed 2 May 2007 01:23, Greg Ungerer pondered:
Quoted 16 lines
diff -Naur linux-2.6.21/fs/namei.c linux-2.6.21-uc0/fs/namei.c
fs/namei.c 2007-05-01 17:16:18.000000000 +1000 renamed from fs/namei.c 2007-05-01 17:12:53.000000000 +1000 +2 -0
@@ -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
 
Quoted 5 lines
fs/namei.c 2007-05-01 17:16:18.000000000 +1000 line 133
Quoted 2 lines
fs/namei.c 2007-05-01 17:16:18.000000000 +1000 renamed from fs/namei.c 2007-05-01 17:12:53.000000000 +1000 +0 -0
        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?

Quoted 4 lines

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

Greg Ungerer

author

2007-05-03 11:03 UTC #4 lore raw

Quoted 23 lines · Robin Getz

On Wed 2 May 2007 07:32, Greg Ungerer pondered:
Quoted 22 lines
Quoted 21 lines · Robin Getz
On Wed 2 May 2007 01:23, Greg Ungerer pondered:
Quoted 8 lines
diff -Naur linux-2.6.21/fs/namei.c linux-2.6.21-uc0/fs/namei.c
fs/namei.c 2007-05-01 17:16:18.000000000 +1000 renamed from fs/namei.c 2007-05-01 17:12:53.000000000 +1000 +1 -0
@@ -120,12 +120,14 @@
        int retval;
        unsigned long len = PATH_MAX;
 
+#ifdef CONFIG_MMU
fs/namei.c 2007-05-01 17:16:18.000000000 +1000 line 133
Quoted 10 lines
fs/namei.c 2007-05-01 17:16:18.000000000 +1000 renamed from fs/namei.c 2007-05-01 17:12:53.000000000 +1000 +1 -0
        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?

Quoted 6 lines

Quoted 4 lines
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:     [email protected]
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

Robin Getz

2007-05-03 11:33 UTC #5 lore raw

On Thu 3 May 2007 07:03, Greg Ungerer pondered:

Quoted 11 lines

Quoted 10 lines · Robin Getz
On Wed 2 May 2007 07:32, Greg Ungerer pondered:
Quoted 8 lines
Quoted 2 lines · Robin Getz
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.

Quoted 6 lines

Quoted 2 lines
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

Greg Ungerer

author

2007-05-03 13:30 UTC #6 lore raw

Quoted 18 lines · Robin Getz

On Thu 3 May 2007 07:03, Greg Ungerer pondered:
Quoted 9 lines
Quoted 8 lines · Robin Getz
On Wed 2 May 2007 07:32, Greg Ungerer pondered:
Quoted 7 lines
Quoted 2 lines · Robin Getz
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.
Quoted 5 lines
Quoted 2 lines
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].

Quoted 8 lines

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.

Quoted 1 line

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:     [email protected]
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

Robin Getz

2007-05-04 16:10 UTC #7 lore raw

On Thu 3 May 2007 09:30, Greg Ungerer pondered:

Quoted 4 lines

Quoted 3 lines · Robin Getz
On Thu 3 May 2007 07:03, Greg Ungerer pondered:
Quoted 2 lines
Quoted 1 line · Robin Getz
On Wed 2 May 2007 07:32, Greg Ungerer pondered:

Quoted 8 lines

Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 2 lines · Robin Getz
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'

Quoted 47 lines

diff -Naur linux-2.6.21/fs/namei.c linux-2.6.21-uc0/fs/namei.c
fs/namei.c 2007-05-01 17:16:18.000000000 +1000 renamed from fs/namei.c 2007-05-01 17:12:53.000000000 +1000 +2 -0
@@ -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) {
Quoted 18 lines
Quoted 9 lines
Quoted 5 lines
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)
Quoted 4 lines
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.

Quoted 7 lines

There have been others out of tree that have it like this to.
Quoted 2 lines
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

Russell King

2007-05-06 11:45 UTC #8 lore raw

Quoted 10 lines · Robin Getz

Quoted 7 lines
Quoted 4 lines
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.

Signature · 3 lines

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

Greg Ungerer

author

2007-05-07 12:00 UTC #9 lore raw

Quoted 7 lines · Russell King

Quoted 6 lines · Robin Getz
Quoted 6 lines
Quoted 4 lines
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?

Quoted 7 lines

Quoted 1 line
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:     [email protected]
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

Paul Mundt

2007-05-07 01:24 UTC #10 lore raw

In reply to Greg Ungerer

Quoted 17 lines · Greg Ungerer

Quoted 7 lines · Robin Getz
Quoted 3 lines
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].
Quoted 8 lines
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)

Quoted 8 lines

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..

Christoph Hellwig

2007-05-02 09:06 UTC #11 lore raw

In reply to Greg Ungerer

Quoted 4 lines · 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.

Any chance you could split this into a few patches and send upstream? m68knommu has gone quite badly out of sync once again.

Greg Ungerer

author

2007-05-02 10:37 UTC #12 lore raw

Hi Christoph,

Quoted 8 lines · Christoph Hellwig

Quoted 4 lines · 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.
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

Signature · 5 lines

------------------------------------------------------------------------
Greg Ungerer  --  Chief Software Dude       EMAIL:     [email protected]
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