LinuxPPC-Dev Archive on lore.kernel.org
 help / color / mirror / Atom feed
* MPC5200 mmap, ioremap
From: Kunkel, Ulrich @ 2005-08-22  8:47 UTC (permalink / raw)
  To: 'linuxppc-embedded@ozlabs.org'

[-- Attachment #1: Type: text/plain, Size: 2753 bytes --]

Hello,

  

I am using a Motorola PPC Hardware (MPC5200) with linux kernel 2.4.25 and 32
MB RAM.

 

I  would like to map a large contiguous kernel memory buffer (6 MB) into
user space with mmap and remap_page_range. For this action I reserved memory
at the end of the phyiscal memory at boot time. (Kernel boot option mem =12
M) Now, the kernel only knows about 20 MB of memory. The high_memory border
is at 0x1400000 (physical address).

I have to do a ioremap() on the high_memory (0x1400000) to map the high
physical memory into a virtual kernel memory.

 

ioremap_ptr = ioremap_nocache (__pa(high_memory), 6*1024*1024);  //6 MB

 

ioremap_ptr is a virtual kernel address.

 

Now I do a mem_map_reserve () on every page in this memory block.

 

On the ioremap ptr I do a memset to check the data in user space later.

 

memset(ioremap_ptr, 0xAB, 6*1024*1024);

 

With bdi2000 I looked to the memory values at 0x1400000 and everything is
ok, I see 0xABABABAB.

 

If I do a virt_to_phys() on ioremap_ptr, I get a really strange address. I
expected to get the physical address 0x1400000.

 

Example:

 

__pa(high_memory): 0x1400000

ioremap_ptr: 0xc22a4000

virt_to_phys(ioremap_ptr): 0x22a4000

virt_to_bus(ioremap_ptr): 0x22a4000

 

 

Now I want to map the buffer into to user space with mmap and
remap_page_range.

 

 

static int mmmap (struct file *file, struct vm_area_struct *vma)

{

      unsigned long offset = vma->vm_pgoff << PAGE_SHIFT;

      int error;

      unsigned long start = (unsigned long)vma->vm_start;

      unsigned long size = (unsigned long)(vma->vm_end - vma->vm_start);

 

 

 

      if (offset != 0)

      {

        printk ("rt_iso1394_mmap: invalid offset: must be 0\n");

        return -ENXIO;

      }

      

 

if(size == PAGE_ALIGN(6*1024*1024)

{

  start,virt_to_phys(shared_buffer_ptr), size, protect);

  error = remap_page_range (vma->vm_start, 0x1400000 , size, PAGE_SHARED);

          

  if (error)

   {

     printk ("rt_iso1394_mmap: remap_page_range failed\n");

     return -EAGAIN;

   }

 }

 

 else

 {

 

  printk ("rt_iso1394_mmap: invalid mmap size, size is: %d\n", (int) size);

  return -EAGAIN;

  }

 

 

      return 0;

}

 

 

The function returned with no errors. 

 

If I call mmap () in user space, the function returnes a virtual user
address. But if do a read on this memory, I don't see the data I have
written in the kernel data block in kernel space. I only get zeros. It seems
that remap_page_range maps a completely different data block.

 

Are the any ideas to solve the problem? What I am doing wrong? What is
missing? Where ist the problem with the addresses???

 

Thanks for your help 

 

 

 

Ulrich Kunkel

Hottinger Baldwin Messtechnik GmbH



[-- Attachment #2: Type: text/html, Size: 13418 bytes --]

^ permalink raw reply

* Re: Linux Kernel MTD question
From: Wolfgang Denk @ 2005-08-22  8:17 UTC (permalink / raw)
  To: JohnsonCheng; +Cc: linuxppc-embedded
In-Reply-To: <20050822030032.4917442C7E@denx.de>

In message <20050822030032.4917442C7E@denx.de> you wrote:
>
> Actually, the range of my flash is from 0xFF000000 to 0xFFFFFFFF. My
> starting address of Kernel is 0xFF000000, and the starting address of
> ramdisk image is FF200000, so the partitions is as following:
> 0xFF000000 - 0xFF1FFFFF		Kernel
> 0xFF200000 - 0xFF9FFFFF		RamDisk Image ( also my Root File System )
> 
> And I found my RootFS image is so big that waste many time while write it to
> flash.

Then avoid writing it that often. Use  a  more  efficient  setup  for
developoment and test, like root file system mounted over NFS.

> I hope I can use MTD to distribute it into two parts, Simple RootFS and
> libraries, but I don't know how to implement it?

You can use MTD to provide an additional file system which  can  then
be mounted by one of your startup scripts. MTD configuration and file
system building is documented in the DULG, please see
http://www.denx.de/twiki/bin/view/DULG/Manual

It is not possible to  give  good  advice  how  to  split  data  into
separate  file  systems,  or  how  exactly  you  can mount it without
precise knowledge of your system and it's requirements. For  example,
do you use a SysV init with several run levels, or a simple setup for
example based on busybox? In the end this is something which you have
to design yourself.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
Let the programmers be many and the managers few -- then all will  be
productive.               -- Geoffrey James, "The Tao of Programming"

^ permalink raw reply

* [PATCH 3/3] Move all the very similar files
From: Stephen Rothwell @ 2005-08-22  6:10 UTC (permalink / raw)
  To: ppc64-dev
In-Reply-To: <20050822160519.51d065fe.sfr@canb.auug.org.au>

This moves all the very similar files - either the ppc64 file included
the ppc file or they differed in simple comments.

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>

---

This patch is too large for the list, so it is available at
http://ozlabs.org/~sfr/0003-This-moves-all-the-very-similar-files-either-the-ppc64-file-included.txt

 include/asm-powerpc/dbdma.h        |  102 ++++++++++
 include/asm-powerpc/errno.h        |   11 +
 include/asm-powerpc/ioctl.h        |   69 +++++++
 include/asm-powerpc/ioctls.h       |  107 ++++++++++
 include/asm-powerpc/keylargo.h     |  248 ++++++++++++++++++++++++
 include/asm-powerpc/local.h        |    1
 include/asm-powerpc/macio.h        |  141 +++++++++++++
 include/asm-powerpc/namei.h        |   20 ++
 include/asm-powerpc/of_device.h    |   62 ++++++
 include/asm-powerpc/parport.h      |   18 ++
 include/asm-powerpc/percpu.h       |    1
 include/asm-powerpc/pmac_feature.h |  379 ++++++++++++++++++++++++++++++++++++
 include/asm-powerpc/pmac_low_i2c.h |   43 ++++
 include/asm-powerpc/poll.h         |   23 ++
 include/asm-powerpc/resource.h     |    1
 include/asm-powerpc/shmparam.h     |    6 +
 include/asm-powerpc/string.h       |   32 +++
 include/asm-powerpc/unaligned.h    |   18 ++
 include/asm-powerpc/uninorth.h     |  229 ++++++++++++++++++++++
 include/asm-ppc/dbdma.h            |  102 ----------
 include/asm-ppc/errno.h            |   11 -
 include/asm-ppc/ioctl.h            |   69 -------
 include/asm-ppc/ioctls.h           |  107 ----------
 include/asm-ppc/keylargo.h         |  248 ------------------------
 include/asm-ppc/local.h            |    6 -
 include/asm-ppc/macio.h            |  141 -------------
 include/asm-ppc/namei.h            |   20 --
 include/asm-ppc/of_device.h        |   62 ------
 include/asm-ppc/parport.h          |   18 --
 include/asm-ppc/percpu.h           |    6 -
 include/asm-ppc/pmac_feature.h     |  379 ------------------------------------
 include/asm-ppc/pmac_low_i2c.h     |   43 ----
 include/asm-ppc/poll.h             |   23 --
 include/asm-ppc/resource.h         |    6 -
 include/asm-ppc/shmparam.h         |    6 -
 include/asm-ppc/string.h           |   32 ---
 include/asm-ppc/unaligned.h        |   18 --
 include/asm-ppc/uninorth.h         |  229 ----------------------
 include/asm-ppc64/dbdma.h          |    2
 include/asm-ppc64/errno.h          |   18 --
 include/asm-ppc64/ioctl.h          |   74 -------
 include/asm-ppc64/ioctls.h         |  114 -----------
 include/asm-ppc64/keylargo.h       |    2
 include/asm-ppc64/local.h          |    1
 include/asm-ppc64/macio.h          |    2
 include/asm-ppc64/namei.h          |   23 --
 include/asm-ppc64/of_device.h      |    2
 include/asm-ppc64/parport.h        |   18 --
 include/asm-ppc64/percpu.h         |    6 -
 include/asm-ppc64/pmac_feature.h   |    2
 include/asm-ppc64/pmac_low_i2c.h   |    2
 include/asm-ppc64/poll.h           |   32 ---
 include/asm-ppc64/resource.h       |    6 -
 include/asm-ppc64/shmparam.h       |   13 -
 include/asm-ppc64/string.h         |   35 ---
 include/asm-ppc64/unaligned.h      |   21 --
 include/asm-ppc64/uninorth.h       |    2
 57 files changed, 1511 insertions(+), 1901 deletions(-)

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

^ permalink raw reply

* [PATCH 2/3] Move the identical files from include/asm-ppc{,64}
From: Stephen Rothwell @ 2005-08-22  6:05 UTC (permalink / raw)
  To: ppc64-dev
In-Reply-To: <20050822160254.2dc59b25.sfr@canb.auug.org.au>

Move the identical files from include/asm-ppc{,64}/ to
include/asm-powerpc/.  Remove hdreg.h completely as it is unused in
the tree.

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>

---

 include/asm-powerpc/8253pit.h           |   10 ++++++++++
 include/asm-powerpc/agp.h               |   23 +++++++++++++++++++++++
 include/asm-powerpc/cputime.h           |    1 +
 include/asm-powerpc/div64.h             |    1 +
 include/asm-powerpc/emergency-restart.h |    1 +
 include/asm-powerpc/ipc.h               |    1 +
 include/asm-powerpc/xor.h               |    1 +
 include/asm-ppc/8253pit.h               |   10 ----------
 include/asm-ppc/agp.h                   |   23 -----------------------
 include/asm-ppc/cputime.h               |    6 ------
 include/asm-ppc/div64.h                 |    1 -
 include/asm-ppc/emergency-restart.h     |    6 ------
 include/asm-ppc/hdreg.h                 |    1 -
 include/asm-ppc/ipc.h                   |    1 -
 include/asm-ppc/xor.h                   |    1 -
 include/asm-ppc64/8253pit.h             |   10 ----------
 include/asm-ppc64/agp.h                 |   23 -----------------------
 include/asm-ppc64/cputime.h             |    6 ------
 include/asm-ppc64/div64.h               |    1 -
 include/asm-ppc64/emergency-restart.h   |    6 ------
 include/asm-ppc64/hdreg.h               |    1 -
 include/asm-ppc64/ipc.h                 |    1 -
 include/asm-ppc64/xor.h                 |    1 -
 23 files changed, 38 insertions(+), 98 deletions(-)

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

diff --git a/include/asm-powerpc/8253pit.h b/include/asm-powerpc/8253pit.h
new file mode 100644
--- /dev/null
+++ b/include/asm-powerpc/8253pit.h
@@ -0,0 +1,10 @@
+/*
+ * 8253/8254 Programmable Interval Timer
+ */
+
+#ifndef _8253PIT_H
+#define _8253PIT_H
+
+#define PIT_TICK_RATE	1193182UL
+
+#endif
diff --git a/include/asm-powerpc/agp.h b/include/asm-powerpc/agp.h
new file mode 100644
--- /dev/null
+++ b/include/asm-powerpc/agp.h
@@ -0,0 +1,23 @@
+#ifndef AGP_H
+#define AGP_H 1
+
+#include <asm/io.h>
+
+/* nothing much needed here */
+
+#define map_page_into_agp(page)
+#define unmap_page_from_agp(page)
+#define flush_agp_mappings()
+#define flush_agp_cache() mb()
+
+/* Convert a physical address to an address suitable for the GART. */
+#define phys_to_gart(x) (x)
+#define gart_to_phys(x) (x)
+
+/* GATT allocation. Returns/accepts GATT kernel virtual address. */
+#define alloc_gatt_pages(order)		\
+	((char *)__get_free_pages(GFP_KERNEL, (order)))
+#define free_gatt_pages(table, order)	\
+	free_pages((unsigned long)(table), (order))
+
+#endif
diff --git a/include/asm-powerpc/cputime.h b/include/asm-powerpc/cputime.h
new file mode 100644
--- /dev/null
+++ b/include/asm-powerpc/cputime.h
@@ -0,0 +1 @@
+#include <asm-generic/cputime.h>
diff --git a/include/asm-powerpc/div64.h b/include/asm-powerpc/div64.h
new file mode 100644
--- /dev/null
+++ b/include/asm-powerpc/div64.h
@@ -0,0 +1 @@
+#include <asm-generic/div64.h>
diff --git a/include/asm-powerpc/emergency-restart.h b/include/asm-powerpc/emergency-restart.h
new file mode 100644
--- /dev/null
+++ b/include/asm-powerpc/emergency-restart.h
@@ -0,0 +1 @@
+#include <asm-generic/emergency-restart.h>
diff --git a/include/asm-powerpc/ipc.h b/include/asm-powerpc/ipc.h
new file mode 100644
--- /dev/null
+++ b/include/asm-powerpc/ipc.h
@@ -0,0 +1 @@
+#include <asm-generic/ipc.h>
diff --git a/include/asm-powerpc/xor.h b/include/asm-powerpc/xor.h
new file mode 100644
--- /dev/null
+++ b/include/asm-powerpc/xor.h
@@ -0,0 +1 @@
+#include <asm-generic/xor.h>
diff --git a/include/asm-ppc/8253pit.h b/include/asm-ppc/8253pit.h
deleted file mode 100644
--- a/include/asm-ppc/8253pit.h
+++ /dev/null
@@ -1,10 +0,0 @@
-/*
- * 8253/8254 Programmable Interval Timer
- */
-
-#ifndef _8253PIT_H
-#define _8253PIT_H
-
-#define PIT_TICK_RATE 	1193182UL
-
-#endif
diff --git a/include/asm-ppc/agp.h b/include/asm-ppc/agp.h
deleted file mode 100644
--- a/include/asm-ppc/agp.h
+++ /dev/null
@@ -1,23 +0,0 @@
-#ifndef AGP_H
-#define AGP_H 1
-
-#include <asm/io.h>
-
-/* nothing much needed here */
-
-#define map_page_into_agp(page)
-#define unmap_page_from_agp(page)
-#define flush_agp_mappings()
-#define flush_agp_cache() mb()
-
-/* Convert a physical address to an address suitable for the GART. */
-#define phys_to_gart(x) (x)
-#define gart_to_phys(x) (x)
-
-/* GATT allocation. Returns/accepts GATT kernel virtual address. */
-#define alloc_gatt_pages(order)		\
-	((char *)__get_free_pages(GFP_KERNEL, (order)))
-#define free_gatt_pages(table, order)	\
-	free_pages((unsigned long)(table), (order))
-
-#endif
diff --git a/include/asm-ppc/cputime.h b/include/asm-ppc/cputime.h
deleted file mode 100644
--- a/include/asm-ppc/cputime.h
+++ /dev/null
@@ -1,6 +0,0 @@
-#ifndef __PPC_CPUTIME_H
-#define __PPC_CPUTIME_H
-
-#include <asm-generic/cputime.h>
-
-#endif /* __PPC_CPUTIME_H */
diff --git a/include/asm-ppc/div64.h b/include/asm-ppc/div64.h
deleted file mode 100644
--- a/include/asm-ppc/div64.h
+++ /dev/null
@@ -1 +0,0 @@
-#include <asm-generic/div64.h>
diff --git a/include/asm-ppc/emergency-restart.h b/include/asm-ppc/emergency-restart.h
deleted file mode 100644
--- a/include/asm-ppc/emergency-restart.h
+++ /dev/null
@@ -1,6 +0,0 @@
-#ifndef _ASM_EMERGENCY_RESTART_H
-#define _ASM_EMERGENCY_RESTART_H
-
-#include <asm-generic/emergency-restart.h>
-
-#endif /* _ASM_EMERGENCY_RESTART_H */
diff --git a/include/asm-ppc/hdreg.h b/include/asm-ppc/hdreg.h
deleted file mode 100644
--- a/include/asm-ppc/hdreg.h
+++ /dev/null
@@ -1 +0,0 @@
-#include <asm-generic/hdreg.h>
diff --git a/include/asm-ppc/ipc.h b/include/asm-ppc/ipc.h
deleted file mode 100644
--- a/include/asm-ppc/ipc.h
+++ /dev/null
@@ -1 +0,0 @@
-#include <asm-generic/ipc.h>
diff --git a/include/asm-ppc/xor.h b/include/asm-ppc/xor.h
deleted file mode 100644
--- a/include/asm-ppc/xor.h
+++ /dev/null
@@ -1 +0,0 @@
-#include <asm-generic/xor.h>
diff --git a/include/asm-ppc64/8253pit.h b/include/asm-ppc64/8253pit.h
deleted file mode 100644
--- a/include/asm-ppc64/8253pit.h
+++ /dev/null
@@ -1,10 +0,0 @@
-/*
- * 8253/8254 Programmable Interval Timer
- */
-
-#ifndef _8253PIT_H
-#define _8253PIT_H
-
-#define PIT_TICK_RATE 	1193182UL
-
-#endif
diff --git a/include/asm-ppc64/agp.h b/include/asm-ppc64/agp.h
deleted file mode 100644
--- a/include/asm-ppc64/agp.h
+++ /dev/null
@@ -1,23 +0,0 @@
-#ifndef AGP_H
-#define AGP_H 1
-
-#include <asm/io.h>
-
-/* nothing much needed here */
-
-#define map_page_into_agp(page)
-#define unmap_page_from_agp(page)
-#define flush_agp_mappings()
-#define flush_agp_cache() mb()
-
-/* Convert a physical address to an address suitable for the GART. */
-#define phys_to_gart(x) (x)
-#define gart_to_phys(x) (x)
-
-/* GATT allocation. Returns/accepts GATT kernel virtual address. */
-#define alloc_gatt_pages(order)		\
-	((char *)__get_free_pages(GFP_KERNEL, (order)))
-#define free_gatt_pages(table, order)	\
-	free_pages((unsigned long)(table), (order))
-
-#endif
diff --git a/include/asm-ppc64/cputime.h b/include/asm-ppc64/cputime.h
deleted file mode 100644
--- a/include/asm-ppc64/cputime.h
+++ /dev/null
@@ -1,6 +0,0 @@
-#ifndef __PPC_CPUTIME_H
-#define __PPC_CPUTIME_H
-
-#include <asm-generic/cputime.h>
-
-#endif /* __PPC_CPUTIME_H */
diff --git a/include/asm-ppc64/div64.h b/include/asm-ppc64/div64.h
deleted file mode 100644
--- a/include/asm-ppc64/div64.h
+++ /dev/null
@@ -1 +0,0 @@
-#include <asm-generic/div64.h>
diff --git a/include/asm-ppc64/emergency-restart.h b/include/asm-ppc64/emergency-restart.h
deleted file mode 100644
--- a/include/asm-ppc64/emergency-restart.h
+++ /dev/null
@@ -1,6 +0,0 @@
-#ifndef _ASM_EMERGENCY_RESTART_H
-#define _ASM_EMERGENCY_RESTART_H
-
-#include <asm-generic/emergency-restart.h>
-
-#endif /* _ASM_EMERGENCY_RESTART_H */
diff --git a/include/asm-ppc64/hdreg.h b/include/asm-ppc64/hdreg.h
deleted file mode 100644
--- a/include/asm-ppc64/hdreg.h
+++ /dev/null
@@ -1 +0,0 @@
-#include <asm-generic/hdreg.h>
diff --git a/include/asm-ppc64/ipc.h b/include/asm-ppc64/ipc.h
deleted file mode 100644
--- a/include/asm-ppc64/ipc.h
+++ /dev/null
@@ -1 +0,0 @@
-#include <asm-generic/ipc.h>
diff --git a/include/asm-ppc64/xor.h b/include/asm-ppc64/xor.h
deleted file mode 100644
--- a/include/asm-ppc64/xor.h
+++ /dev/null
@@ -1 +0,0 @@
-#include <asm-generic/xor.h>

^ permalink raw reply

* [PATCH 1/3] Create include/asm-powerpc
From: Stephen Rothwell @ 2005-08-22  6:02 UTC (permalink / raw)
  To: ppc64-dev

Hopefully, we can gree to start like this ...

Create include/asm-powerpc (and move linkage.h into it since we don't
like empty directories).  Modify the Makefiles to cope.

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>

---

 arch/ppc/Makefile             |   11 ++++++++++-
 arch/ppc64/Makefile           |    9 +++++++++
 include/asm-powerpc/linkage.h |    6 ++++++
 include/asm-ppc/linkage.h     |    6 ------
 include/asm-ppc64/linkage.h   |    6 ------
 5 files changed, 25 insertions(+), 13 deletions(-)
 create mode 100644 include/asm-powerpc/linkage.h
 delete mode 100644 include/asm-ppc/linkage.h
 delete mode 100644 include/asm-ppc64/linkage.h


-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

diff --git a/arch/ppc/Makefile b/arch/ppc/Makefile
--- a/arch/ppc/Makefile
+++ b/arch/ppc/Makefile
@@ -21,11 +21,13 @@ CC		:= $(CC) -m32
 endif
 
 LDFLAGS_vmlinux	:= -Ttext $(KERNELLOAD) -Bstatic
-CPPFLAGS	+= -Iarch/$(ARCH)
+CPPFLAGS	+= -Iarch/$(ARCH) -Iinclude3
 AFLAGS		+= -Iarch/$(ARCH)
 CFLAGS		+= -Iarch/$(ARCH) -msoft-float -pipe \
 		-ffixed-r2 -mmultiple
 CPP		= $(CC) -E $(CFLAGS)
+# Temporary hack until we have migrated to asm-powerpc
+LINUXINCLUDE    += -Iinclude3
 
 CHECKFLAGS	+= -D__powerpc__
 
@@ -101,6 +103,7 @@ endef
 
 archclean:
 	$(Q)$(MAKE) $(clean)=arch/ppc/boot
+	$(Q)rm -rf include3
 
 prepare: include/asm-$(ARCH)/offsets.h checkbin
 
@@ -110,6 +113,12 @@ arch/$(ARCH)/kernel/asm-offsets.s: inclu
 include/asm-$(ARCH)/offsets.h: arch/$(ARCH)/kernel/asm-offsets.s
 	$(call filechk,gen-asm-offsets)
 
+# Temporary hack until we have migrated to asm-powerpc
+include/asm: include3/asm
+include3/asm:
+	$(Q)if [ ! -d include3 ]; then mkdir -p include3; fi
+	$(Q)ln -fsn $(srctree)/include/asm-powerpc include3/asm
+
 # Use the file '.tmp_gas_check' for binutils tests, as gas won't output
 # to stdout and these checks are run even on install targets.
 TOUT	:= .tmp_gas_check
diff --git a/arch/ppc64/Makefile b/arch/ppc64/Makefile
--- a/arch/ppc64/Makefile
+++ b/arch/ppc64/Makefile
@@ -55,6 +55,8 @@ LDFLAGS		:= -m elf64ppc
 LDFLAGS_vmlinux	:= -Bstatic -e $(KERNELLOAD) -Ttext $(KERNELLOAD)
 CFLAGS		+= -msoft-float -pipe -mminimal-toc -mtraceback=none \
 		   -mcall-aixdesc
+# Temporary hack until we have migrated to asm-powerpc
+CPPFLAGS	+= -Iinclude3
 
 GCC_VERSION     := $(call cc-version)
 GCC_BROKEN_VEC	:= $(shell if [ $(GCC_VERSION) -lt 0400 ] ; then echo "y"; fi ;)
@@ -112,6 +114,7 @@ all: $(KBUILD_IMAGE)
 
 archclean:
 	$(Q)$(MAKE) $(clean)=$(boot)
+	$(Q)rm -rf include3
 
 prepare: include/asm-ppc64/offsets.h
 
@@ -121,6 +124,12 @@ arch/ppc64/kernel/asm-offsets.s: include
 include/asm-ppc64/offsets.h: arch/ppc64/kernel/asm-offsets.s
 	$(call filechk,gen-asm-offsets)
 
+# Temporary hack until we have migrated to asm-powerpc
+include/asm: include3/asm
+include3/asm:
+	$(Q)if [ ! -d include3 ]; then mkdir -p include3; fi;
+	$(Q)ln -fsn $(srctree)/include/asm-powerpc include3/asm
+
 define archhelp
   echo  '* zImage       - Compressed kernel image (arch/$(ARCH)/boot/zImage)'
   echo  '  zImage.initrd- Compressed kernel image with initrd attached,'
diff --git a/include/asm-powerpc/linkage.h b/include/asm-powerpc/linkage.h
new file mode 100644
--- /dev/null
+++ b/include/asm-powerpc/linkage.h
@@ -0,0 +1,6 @@
+#ifndef __ASM_LINKAGE_H
+#define __ASM_LINKAGE_H
+
+/* Nothing to see here... */
+
+#endif
diff --git a/include/asm-ppc/linkage.h b/include/asm-ppc/linkage.h
deleted file mode 100644
--- a/include/asm-ppc/linkage.h
+++ /dev/null
@@ -1,6 +0,0 @@
-#ifndef __ASM_LINKAGE_H
-#define __ASM_LINKAGE_H
-
-/* Nothing to see here... */
-
-#endif
diff --git a/include/asm-ppc64/linkage.h b/include/asm-ppc64/linkage.h
deleted file mode 100644
--- a/include/asm-ppc64/linkage.h
+++ /dev/null
@@ -1,6 +0,0 @@
-#ifndef __ASM_LINKAGE_H
-#define __ASM_LINKAGE_H
-
-/* Nothing to see here... */
-
-#endif

^ permalink raw reply

* Re: [PATCH] cpm_uart: Fix dpram allocation and non-console uarts
From: Nishanth Aravamudan @ 2005-08-22  4:14 UTC (permalink / raw)
  To: Marcelo Tosatti
  Cc: Andrew Morton, Kumar Gala, Nish Aravamudan, linux-kernel,
	linuxppc-embedded
In-Reply-To: <20050821211235.GD6746@dmt.cnet>

On 21.08.2005 [18:12:35 -0300], Marcelo Tosatti wrote:
> Hi,
> 
> On Wed, Aug 17, 2005 at 10:42:36PM -0700, Nish Aravamudan wrote:
> > On 8/8/05, Kumar Gala <galak@freescale.com> wrote:
> > > (A believe Marcelo would like to see this in 2.6.13, but I'll let him
> > > fight over that ;)
> > > 
> > > * Makes dpram allocations work
> > > * Makes non-console UART work on both 8xx and 82xx
> > > * Fixed whitespace in files that were touched
> > > 
> > > Signed-off-by: Vitaly Bordug <vbordug@ru.mvista.com>
> > > Signed-off-by: Pantelis Antoniou <panto@intracom.gr>
> > > Signed-off-by: Kumar Gala <kumar.gala@freescale.com>
> > > 
> > > ---
> > > commit 1de80554bcae877dce3b6d878053eb092ef65c72
> > > tree aba124824607fea1070e86501ddccc9decce362d
> > > parent ad81111fd554c9d3c14c0a50885e076af2f9ac9b
> > > author Kumar K. Gala <kumar.gala@freescale.com> Mon, 08 Aug 2005 22:35:39 -0500
> > > committer Kumar K. Gala <kumar.gala@freescale.com> Mon, 08 Aug 2005 22:35:39 -0500
> > 
> > <snip>
> > 
> > > diff --git a/drivers/serial/cpm_uart/cpm_uart_core.c b/drivers/serial/cpm_uart/cpm_uart_core.c
> > > --- a/drivers/serial/cpm_uart/cpm_uart_core.c
> > > +++ b/drivers/serial/cpm_uart/cpm_uart_core.c
> > 
> > <snip>
> > 
> > > @@ -376,9 +396,19 @@ static int cpm_uart_startup(struct uart_
> > >                 pinfo->sccp->scc_sccm |= UART_SCCM_RX;
> > >         }
> > > 
> > > +       if (!(pinfo->flags & FLAG_CONSOLE))
> > > +               cpm_line_cr_cmd(line,CPM_CR_INIT_TRX);
> > >         return 0;
> > >  }
> > > 
> > > +inline void cpm_uart_wait_until_send(struct uart_cpm_port *pinfo)
> > > +{
> > > +       unsigned long target_jiffies = jiffies + pinfo->wait_closing;
> > > +
> > > +       while (!time_after(jiffies, target_jiffies))
> > > +               schedule();
> > > +}
> > 
> > Not sure about that call here. Does the state need to be set so that
> > you won't be run again immediately? In any case, I think direct
> > schedule() callers are discouraged? Do you want to call a yield() or
> > schedule_timeout({0,1}) instead maybe?
> 
> Yep, schedule_timeout(pinfo->wait_closing) looks much better.
> 
> > >  /*
> > >   * Shutdown the uart
> > >   */
> > > @@ -394,6 +424,12 @@ static void cpm_uart_shutdown(struct uar
> > > 
> > >         /* If the port is not the console, disable Rx and Tx. */
> > >         if (!(pinfo->flags & FLAG_CONSOLE)) {
> > > +               /* Wait for all the BDs marked sent */
> > > +               while(!cpm_uart_tx_empty(port))
> > > +                       schedule_timeout(2);
> > 
> > <snip>
> > 
> > I think you are using 2 jiffies to guarantee that at least one jiffy
> > elapses, which is fine. But, if you do not set the state beforehand,
> > schedule_timeout() returns immediately, so you have a busy-wait here.
> 
> Right, what about the following untested patch.
> 
> diff --git a/drivers/serial/cpm_uart/cpm_uart_core.c b/drivers/serial/cpm_uart/cpm_uart_core.c
> --- a/drivers/serial/cpm_uart/cpm_uart_core.c
> +++ b/drivers/serial/cpm_uart/cpm_uart_core.c
> @@ -403,10 +403,9 @@ static int cpm_uart_startup(struct uart_
>  
>  inline void cpm_uart_wait_until_send(struct uart_cpm_port *pinfo)
>  {
> -	unsigned long target_jiffies = jiffies + pinfo->wait_closing;
> -
> -	while (!time_after(jiffies, target_jiffies))
> -   		schedule();
> +	set_current_state(TASK_UNINTERRUPTIBLE);
> +	schedule_timeout(pinfo->wait_closing);
> +	set_current_state(TASK_RUNNING);
>  }

Both changes look correct/better. Except you shouldn't need to set the
state back to TASK_RUNNING in either case, as schedule_timeout()
guarantees the task will return in that state.

Thanks,
Nish

^ permalink raw reply

* RE: Linux Kernel MTD question
From: JohnsonCheng @ 2005-08-22  2:56 UTC (permalink / raw)
  To: 'Wolfgang Denk'; +Cc: linuxppc-embedded
In-Reply-To: <20050821205851.66E52353D18@atlas.denx.de>

Very Thanks for your reply.
I am sorry that this data is copied from Building Embedded Linux Systems
book.
Actually, the range of my flash is from 0xFF000000 to 0xFFFFFFFF. My
starting address of Kernel is 0xFF000000, and the starting address of
ramdisk image is FF200000, so the partitions is as following:
0xFF000000 - 0xFF1FFFFF		Kernel
0xFF200000 - 0xFF9FFFFF		RamDisk Image ( also my Root File System )

And I found my RootFS image is so big that waste many time while write it to
flash.
I hope I can use MTD to distribute it into two parts, Simple RootFS and
libraries, but I don't know how to implement it?

My CPU is MPC8241, and my kernel configure is base on Sandpoint_defconfig.

Thanks,
Johnson Cheng  

-----Original Message-----
From: linuxppc-embedded-bounces@ozlabs.org
[mailto:linuxppc-embedded-bounces@ozlabs.org] On Behalf Of Wolfgang Denk
Sent: Monday, August 22, 2005 4:59 AM
To: JohnsonCheng
Cc: linuxppc-embedded@ozlabs.org
Subject: Re: Linux Kernel MTD question 

In message <20050821080936.DA55167F92@ozlabs.org> you wrote:
> 
> Just as I know, we can have many partitions for our flash if we turn on
MTD
> in Kernel. For example:

Right.

> How could I distribute my RootFS into initrd1 and initrd2?

You cannot. The *root* filesystem is always just a single file system.

You can mount  additional  file  systems  on  top  of  the  directory
hierarchy  provided  by  your root file system, but this is something
completely different.

> In U-Boot command, bootcmd, I set it to "bootm 40000 100000". 40000 is
> Kernel address, and 100000 is RootFS1 address. But where to set RootRS2
> address?

There are several errors in this text.

First, the kernel download address 0x40000 = 256kB is  much  too  low
and can never work.

Second, the "100000" parameter is not a "RootFS1 address". It  is  the
start  address  of  a ramdisk image. This may or may not be your root
file system, and it is usually NOT the address as seen by the kernel.
And, 100000 = 1 MB is a much too low address and can never work.


And finally: all this has absolutely NOTHING to do with MTD partitions.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
Documentation is like sex: when it is good, it is  very,  very  good;
and when it is bad, it is better than nothing.         - Dick Brandon
_______________________________________________
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded

^ permalink raw reply

* Re: [PATCH] ppc32: 8xx pq platform system descriptions
From: Dan Malek @ 2005-08-22  1:28 UTC (permalink / raw)
  To: Marcelo Tosatti; +Cc: Kumar Gala, linuxppc-embedded list
In-Reply-To: <20050821235524.GE6746@dmt.cnet>


On Aug 21, 2005, at 7:55 PM, Marcelo Tosatti wrote:

> - Do you have any plans on actually using device model information by
> drivers (as was done in the mpc8xxx/gianfar) on m8xx? Its not very 
> clear
> to me what are the the practical advantages of that?

It may be nice if we can do that.  We have to be careful about sharing
CPM drivers between the 8xx and CPM2 (82xx/83xx/85xx).  It's tempting,
but I still believe the differences outweigh the similarities.  The 
overhead
of trying to use common drivers would be quite costly on the 8xx.

> - I don't know whether its possible to retrieve 8xx CPUID information
> (if there is any). Can't find anything in the manual.

We really can't.  The PVR only represents the processor core 
information,
and for the most part they are all the same.  It used to be we could use
the CPM microcode version, but these are now nearly the same.  Some
attempts have been made to probe for CPM peripherals that don't exist,
but it seems on some parts the CPM is the same and the signals just 
aren't
bonded out of the chip.

For the most part, the person doing the kernel configuration just simply
has to know what part they are using.  You have to select the proper
peripherals, and you need the board support for the IO pin routing.
In an embedded environment where resources still need to be
carefully managed, I don't think this is unrealistic.

Thanks.

	-- Dan

^ permalink raw reply

* Re: [PATCH] ppc32: 8xx pq platform system descriptions
From: Marcelo Tosatti @ 2005-08-21 23:55 UTC (permalink / raw)
  To: Vitaly Bordug; +Cc: Kumar Gala, linuxppc-embedded list
In-Reply-To: <43062C9D.5060703@ru.mvista.com>

On Fri, Aug 19, 2005 at 11:01:49PM +0400, Vitaly Bordug wrote:
> Added ppc_sys device and system definitions for PowerQUICC I devices.
> 
> Signed-off-by: Vitaly Bordug <vbordug@ru.mvista.com>
> -- 
> Sincerely,
> Vitaly

Vitaly, Kumar,

Have a few questions:

- Do you have any plans on actually using device model information by
drivers (as was done in the mpc8xxx/gianfar) on m8xx? Its not very clear
to me what are the the practical advantages of that?

- I don't know whether its possible to retrieve 8xx CPUID information
(if there is any). Can't find anything in the manual.

^ permalink raw reply

* Re: [PATCH] cpm_uart: Fix dpram allocation and non-console uarts
From: Marcelo Tosatti @ 2005-08-21 21:12 UTC (permalink / raw)
  To: Nish Aravamudan
  Cc: Andrew Morton, Kumar Gala, linux-kernel, linuxppc-embedded
In-Reply-To: <29495f1d0508172242734e1c99@mail.gmail.com>

Hi,

On Wed, Aug 17, 2005 at 10:42:36PM -0700, Nish Aravamudan wrote:
> On 8/8/05, Kumar Gala <galak@freescale.com> wrote:
> > (A believe Marcelo would like to see this in 2.6.13, but I'll let him
> > fight over that ;)
> > 
> > * Makes dpram allocations work
> > * Makes non-console UART work on both 8xx and 82xx
> > * Fixed whitespace in files that were touched
> > 
> > Signed-off-by: Vitaly Bordug <vbordug@ru.mvista.com>
> > Signed-off-by: Pantelis Antoniou <panto@intracom.gr>
> > Signed-off-by: Kumar Gala <kumar.gala@freescale.com>
> > 
> > ---
> > commit 1de80554bcae877dce3b6d878053eb092ef65c72
> > tree aba124824607fea1070e86501ddccc9decce362d
> > parent ad81111fd554c9d3c14c0a50885e076af2f9ac9b
> > author Kumar K. Gala <kumar.gala@freescale.com> Mon, 08 Aug 2005 22:35:39 -0500
> > committer Kumar K. Gala <kumar.gala@freescale.com> Mon, 08 Aug 2005 22:35:39 -0500
> 
> <snip>
> 
> > diff --git a/drivers/serial/cpm_uart/cpm_uart_core.c b/drivers/serial/cpm_uart/cpm_uart_core.c
> > --- a/drivers/serial/cpm_uart/cpm_uart_core.c
> > +++ b/drivers/serial/cpm_uart/cpm_uart_core.c
> 
> <snip>
> 
> > @@ -376,9 +396,19 @@ static int cpm_uart_startup(struct uart_
> >                 pinfo->sccp->scc_sccm |= UART_SCCM_RX;
> >         }
> > 
> > +       if (!(pinfo->flags & FLAG_CONSOLE))
> > +               cpm_line_cr_cmd(line,CPM_CR_INIT_TRX);
> >         return 0;
> >  }
> > 
> > +inline void cpm_uart_wait_until_send(struct uart_cpm_port *pinfo)
> > +{
> > +       unsigned long target_jiffies = jiffies + pinfo->wait_closing;
> > +
> > +       while (!time_after(jiffies, target_jiffies))
> > +               schedule();
> > +}
> 
> Not sure about that call here. Does the state need to be set so that
> you won't be run again immediately? In any case, I think direct
> schedule() callers are discouraged? Do you want to call a yield() or
> schedule_timeout({0,1}) instead maybe?

Yep, schedule_timeout(pinfo->wait_closing) looks much better.

> >  /*
> >   * Shutdown the uart
> >   */
> > @@ -394,6 +424,12 @@ static void cpm_uart_shutdown(struct uar
> > 
> >         /* If the port is not the console, disable Rx and Tx. */
> >         if (!(pinfo->flags & FLAG_CONSOLE)) {
> > +               /* Wait for all the BDs marked sent */
> > +               while(!cpm_uart_tx_empty(port))
> > +                       schedule_timeout(2);
> 
> <snip>
> 
> I think you are using 2 jiffies to guarantee that at least one jiffy
> elapses, which is fine. But, if you do not set the state beforehand,
> schedule_timeout() returns immediately, so you have a busy-wait here.

Right, what about the following untested patch.

diff --git a/drivers/serial/cpm_uart/cpm_uart_core.c b/drivers/serial/cpm_uart/cpm_uart_core.c
--- a/drivers/serial/cpm_uart/cpm_uart_core.c
+++ b/drivers/serial/cpm_uart/cpm_uart_core.c
@@ -403,10 +403,9 @@ static int cpm_uart_startup(struct uart_
 
 inline void cpm_uart_wait_until_send(struct uart_cpm_port *pinfo)
 {
-	unsigned long target_jiffies = jiffies + pinfo->wait_closing;
-
-	while (!time_after(jiffies, target_jiffies))
-   		schedule();
+	set_current_state(TASK_UNINTERRUPTIBLE);
+	schedule_timeout(pinfo->wait_closing);
+	set_current_state(TASK_RUNNING);
 }
 
 /*
@@ -425,9 +424,13 @@ static void cpm_uart_shutdown(struct uar
 	/* If the port is not the console, disable Rx and Tx. */
 	if (!(pinfo->flags & FLAG_CONSOLE)) {
 		/* Wait for all the BDs marked sent */
-		while(!cpm_uart_tx_empty(port))
+		while(!cpm_uart_tx_empty(port)) {
+			set_current_state(TASK_UNINTERRUPTIBLE);
 			schedule_timeout(2);
-		if(pinfo->wait_closing)
+		}
+		set_current_state(TASK_RUNNING);
+
+		if (pinfo->wait_closing)
 			cpm_uart_wait_until_send(pinfo);
 
 		/* Stop uarts */

^ permalink raw reply

* Re: [PATCH] ppc32: Big-endian I/O memory accessors.
From: Benjamin Herrenschmidt @ 2005-08-21 21:22 UTC (permalink / raw)
  To: Arthur Othieno; +Cc: linuxppc-dev
In-Reply-To: <20050821011649.GA31839@mars>

On Sat, 2005-08-20 at 21:16 -0400, Arthur Othieno wrote:
> I/O memory accessors. Big-endian version. For those busses/devices
> that do export big-endian I/O memory.
> 
> Of notable relevance/reference:
> 
>    http://lwn.net/Articles/132804/
>    http://ozlabs.org/pipermail/linuxppc-embedded/2005-August/019798.html
>    http://ozlabs.org/pipermail/linuxppc-embedded/2005-August/019752.html
> 
> Signed-Off-By: Arthur Othieno <a.othieno@bluewin.ch>
> 

No, that's not correct. You need to use the in_be/out_be variants which
provide proper memory barriers.

Ben.

^ permalink raw reply

* Re: Linux Kernel MTD question
From: Wolfgang Denk @ 2005-08-21 20:58 UTC (permalink / raw)
  To: JohnsonCheng; +Cc: linuxppc-embedded
In-Reply-To: <20050821080936.DA55167F92@ozlabs.org>

In message <20050821080936.DA55167F92@ozlabs.org> you wrote:
> 
> Just as I know, we can have many partitions for our flash if we turn on MTD
> in Kernel. For example:

Right.

> How could I distribute my RootFS into initrd1 and initrd2?

You cannot. The *root* filesystem is always just a single file system.

You can mount  additional  file  systems  on  top  of  the  directory
hierarchy  provided  by  your root file system, but this is something
completely different.

> In U-Boot command, bootcmd, I set it to "bootm 40000 100000". 40000 is
> Kernel address, and 100000 is RootFS1 address. But where to set RootRS2
> address?

There are several errors in this text.

First, the kernel download address 0x40000 = 256kB is  much  too  low
and can never work.

Second, the "100000" parameter is not a "RootFS1 address". It  is  the
start  address  of  a ramdisk image. This may or may not be your root
file system, and it is usually NOT the address as seen by the kernel.
And, 100000 = 1 MB is a much too low address and can never work.


And finally: all this has absolutely NOTHING to do with MTD partitions.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
Documentation is like sex: when it is good, it is  very,  very  good;
and when it is bad, it is better than nothing.         - Dick Brandon

^ permalink raw reply

* Re: segmentaion fault with array[4096]'
From: Marcelo Tosatti @ 2005-08-21 19:28 UTC (permalink / raw)
  To: Studencki Pawel; +Cc: 'linuxppc-embedded@ozlabs.org'
In-Reply-To: <291992F9ECD9AB4F995C7E96B9A30DC008E088@nbgh103a.nbg6.siemens.de>

On Fri, Aug 19, 2005 at 09:17:07AM +0200, Studencki Pawel wrote:
> hello,
> 
> it is very strange, I found that SIGSEGV is generated in function
> do_page_fault() in arch/ppc/mm/fault.c
> 
> ------------------------------------------------------------------
> int do_page_fault(struct pt_regs *regs, unsigned long address,
>                   unsigned long error_code)
> {
>         struct vm_area_struct * vma;
>         struct mm_struct *mm = current->mm;
>         siginfo_t info;
>         int code = SEGV_MAPERR;
> #if defined(CONFIG_4xx) || defined (CONFIG_BOOKE)
>         int is_write = error_code & ESR_DST;
> #else
>         int is_write = 0;
> 
>         /*
>          * Fortunately the bit assignments in SRR1 for an instruction
>          * fault and DSISR for a data fault are mostly the same for the
>          * bits we are interested in.  But there are some bits which
>          * indicate errors in DSISR but can validly be set in SRR1.
>          */
> //      printk("fault bad_area is_write is NULL %x\n", regs->dsisr);
>         if (TRAP(regs) == 0x400)
>                 error_code &= 0x48200000;
>         else
>         {
> //              printk("fault bad_area is_write err = %x %x\n", error_code,
> TRAP(regs));
>                 is_write = error_code & 0x02000000;
>         }
> #endif /* CONFIG_4xx || CONFIG_BOOKE */
> ---------------------------------------------------------------
> 
> 
> It is in DSI Exception, so it goes to "else" and sets is_write to value
> error_code & 0x02000000, where error_code is DSISR.
> it is better, when is_write != 0, because if it's NULL, a few lines below
> there
> is an "goto" to bad_area:
> 
>         if (!is_write)
>         {
>                goto bad_area;
>         } 
> 
> 
> and I get exception.

Sometimes is_write is set and sometimes it is not? Can you please be more 
precise? 

> At exception error_code is 0x4821, but in User Manual MPC866 in chapter
> 6.1.2.3
> in table 6-7, they write that bits 0-14 in DSISR are NULL. I'm confused and
> I don't know how should I interpret this. 

You're looking at the wrong table, thats alignment exception. You should look
at data tlb error exception.

> Where does value 0x4821 come
> from??? most of the time it is 0x82000000...

It probably comes from

	if (TRAP(regs) == 0x400)
                error_code &= 0x48200000;

No?

I think you're just doing something wrong in your app.

Check what instruction resides where the invalid access is done (in your 
application), which vma its trying to access, and you will figure out 
what is going on.

^ permalink raw reply

* Re: How to map memory uncached on PPC.
From: Stephen Williams @ 2005-08-21 15:06 UTC (permalink / raw)
  To: John W. Linville; +Cc: linuxppc-dev
In-Reply-To: <20050820180825.GG2736@tuxdriver.com>

John W. Linville wrote:
> On Sat, Aug 20, 2005 at 08:59:42AM -0700, Stephen Williams wrote:

>>I did an even simpler experiment: I commented out the pci_map_single,
>>which on a PPC only has the effect of calling invalidate_dcache_range
>>and returning the virt_to_bus of the address. Obviously, the cache
>>is still enabled for the processor, and the image data may get
>>corrupted, but this was a performance test, not a solution.
> 
> 
> If your purpose is to evaluate performance, doesn't having the cache
> enabled limit the usefulness of your test?  For example if your cache
> uses a write-back policy then your test will probably outperform the
> actual uncached accesses.  YMMV, I suppose...

No, it shouldn't. The setup is a driver for a PCI device that masters
its output to the buffer in question. What I'm measuring is not the
time to write the buffer (which is being done by the hardware, so
bypasses the cache anyhow) but the time it takes to *prepare the
buffer for the device*. The buffer is not written to or read from
by device or processor during this time, but it is mapped and DMA
pointers are collected. Also, the pci_map_single invalidates the cache
by walking through the entire buffer (many megabytes) with this loop
from invalidate_dcache_range:

1:	dcbi	0,r3
	addi	r3,r3,L1_CACHE_LINE_SIZE
	bdnz	1b
	sync				/* wait for dcbi's to get to ram */

This is what I believe is taking a long time.

Since nothing is touching that buffer during my test, and I'm mostly
dropping that code, I believe my test is valid.

-- 
Steve Williams                "The woods are lovely, dark and deep.
steve at icarus.com           But I have promises to keep,
http://www.icarus.com         and lines to code before I sleep,
http://www.picturel.com       And lines to code before I sleep."

^ permalink raw reply

* Linux Kernel MTD question
From: JohnsonCheng @ 2005-08-21  8:02 UTC (permalink / raw)
  To: linuxppc-embedded

[-- Attachment #1: Type: text/plain, Size: 507 bytes --]

Dear All,

 

Just as I know, we can have many partitions for our flash if we turn on MTD
in Kernel. For example:

0x00000000-0x00040000:      u-boot

0x00040000-0x00100000:      kernel

0x00100000-0x00200000:      inirid1

0x00200000-0x00400000:      initrd2

 

How could I distribute my RootFS into initrd1 and initrd2?

In U-Boot command, bootcmd, I set it to "bootm 40000 100000". 40000 is
Kernel address, and 100000 is RootFS1 address. But where to set RootRS2
address?

 

Thanks,

Johnson Cheng

 


[-- Attachment #2: Type: text/html, Size: 4224 bytes --]

^ permalink raw reply

* [PATCH] ppc32: Big-endian I/O memory accessors.
From: Arthur Othieno @ 2005-08-21  1:16 UTC (permalink / raw)
  To: linuxppc-dev


I/O memory accessors. Big-endian version. For those busses/devices
that do export big-endian I/O memory.

Of notable relevance/reference:

   http://lwn.net/Articles/132804/
   http://ozlabs.org/pipermail/linuxppc-embedded/2005-August/019798.html
   http://ozlabs.org/pipermail/linuxppc-embedded/2005-August/019752.html

Signed-Off-By: Arthur Othieno <a.othieno@bluewin.ch>


  io.h |   20 ++++++++++++++++++++
  1 files changed, 20 insertions(+)


--- a/include/asm-ppc/io.h	2005-08-20 19:24:40.000000000 -0400
+++ b/include/asm-ppc/io.h	2005-08-20 20:18:03.000000000 -0400
@@ -487,11 +487,21 @@
 	return readw(addr);
 }
 
+static inline unsigned int ioread16be(void __iomem *addr)
+{
+	return __raw_readw(addr);
+}
+
 static inline unsigned int ioread32(void __iomem *addr)
 {
 	return readl(addr);
 }
 
+static inline unsigned int ioread32be(void __iomem *addr)
+{
+	return __raw_readl(addr);
+}
+
 static inline void iowrite8(u8 val, void __iomem *addr)
 {
 	writeb(val, addr);
@@ -502,11 +512,21 @@
 	writew(val, addr);
 }
 
+static inline void iowrite16be(u16 val, void __iomem *addr)
+{
+	__raw_writew(val, addr);
+}
+
 static inline void iowrite32(u32 val, void __iomem *addr)
 {
 	writel(val, addr);
 }
 
+static inline void iowrite32be(u32 val, void __iomem *addr)
+{
+	__raw_writel(val, addr);
+}
+
 static inline void ioread8_rep(void __iomem *addr, void *dst, unsigned long count)
 {
 	_insb(addr, dst, count);

^ permalink raw reply

* Re: How to map memory uncached on PPC.
From: John W. Linville @ 2005-08-20 18:08 UTC (permalink / raw)
  To: Stephen Williams; +Cc: linuxppc-dev
In-Reply-To: <4307536E.4070800@icarus.com>

On Sat, Aug 20, 2005 at 08:59:42AM -0700, Stephen Williams wrote:
> Benjamin Herrenschmidt wrote:

> >A simple experiment you can do is limit the memory used by the kernel
> >(booting with mem=xxxx) and then use mmap of /dev/mem to map the
> >remaining memory like if it was an IO device, uncached. With that, you
> >get a quick hack solution to validate the performance benefit at least.
> 
> I did an even simpler experiment: I commented out the pci_map_single,
> which on a PPC only has the effect of calling invalidate_dcache_range
> and returning the virt_to_bus of the address. Obviously, the cache
> is still enabled for the processor, and the image data may get
> corrupted, but this was a performance test, not a solution.

If your purpose is to evaluate performance, doesn't having the cache
enabled limit the usefulness of your test?  For example if your cache
uses a write-back policy then your test will probably outperform the
actual uncached accesses.  YMMV, I suppose...

John
-- 
John W. Linville
linville@tuxdriver.com

^ permalink raw reply

* Re: How to map memory uncached on PPC.
From: Stephen Williams @ 2005-08-20 15:59 UTC (permalink / raw)
  To: linuxppc-dev
In-Reply-To: <1124499963.5197.99.camel@gaston>

Benjamin Herrenschmidt wrote:

> On Fri, 2005-08-19 at 08:17 -0700, Stephen Williams wrote:
>>I did some measurements, at it seems that the vast amount of
>>the time is spent in pci_map_single, which calls only the
>>consistent_sync function, which for FROMDEVICE calls only
>>invalidate_dcache_range. So I'm convinced that invalidating
>>the cache for the output buffer (which is large, in case the
>>image that arrives is large) is taking most of the time. So
>>I want to eliminate it.

> A simple experiment you can do is limit the memory used by the kernel
> (booting with mem=xxxx) and then use mmap of /dev/mem to map the
> remaining memory like if it was an IO device, uncached. With that, you
> get a quick hack solution to validate the performance benefit at least.

I did an even simpler experiment: I commented out the pci_map_single,
which on a PPC only has the effect of calling invalidate_dcache_range
and returning the virt_to_bus of the address. Obviously, the cache
is still enabled for the processor, and the image data may get
corrupted, but this was a performance test, not a solution.

Your "test" is a not implausible solution, although it has for me
some administrative problems.

-- 
Steve Williams                "The woods are lovely, dark and deep.
steve at icarus.com           But I have promises to keep,
http://www.icarus.com         and lines to code before I sleep,
http://www.picturel.com       And lines to code before I sleep."

^ permalink raw reply

* [PATCH] ppc32: fix Bamboo and Luan build warnings
From: Eugene Surovegin @ 2005-08-20  7:36 UTC (permalink / raw)
  To: Andrew Morton; +Cc: linuxppc-embedded

Fix STD_UART_OP definitions in Bamboo and Luan board ports which 
were causing "initialization makes pointer from integer without a 
cast" warnings.

Signed-off-by: Eugene Surovegin <ebs@ebshome.net>

diff --git a/arch/ppc/platforms/4xx/bamboo.h b/arch/ppc/platforms/4xx/bamboo.h
--- a/arch/ppc/platforms/4xx/bamboo.h
+++ b/arch/ppc/platforms/4xx/bamboo.h
@@ -88,7 +88,7 @@
 #define STD_UART_OP(num)					\
 	{ 0, BASE_BAUD, 0, UART##num##_INT,			\
 		(ASYNC_BOOT_AUTOCONF | ASYNC_SKIP_TEST),	\
-		iomem_base: UART##num##_IO_BASE,		\
+		iomem_base: (void*)UART##num##_IO_BASE,		\
 		io_type: SERIAL_IO_MEM},
 
 #define SERIAL_PORT_DFNS	\
diff --git a/arch/ppc/platforms/4xx/luan.h b/arch/ppc/platforms/4xx/luan.h
--- a/arch/ppc/platforms/4xx/luan.h
+++ b/arch/ppc/platforms/4xx/luan.h
@@ -55,7 +55,7 @@
 #define STD_UART_OP(num)					\
 	{ 0, BASE_BAUD, 0, UART##num##_INT,			\
 		(ASYNC_BOOT_AUTOCONF | ASYNC_SKIP_TEST),	\
-		iomem_base: UART##num##_IO_BASE,		\
+		iomem_base: (void*)UART##num##_IO_BASE,		\
 		io_type: SERIAL_IO_MEM},
 
 #define SERIAL_PORT_DFNS	\

^ permalink raw reply

* [PATCH] ppc32: fix EMAC Tx channel assignments for NPe405H
From: Eugene Surovegin @ 2005-08-20  2:32 UTC (permalink / raw)
  To: Andrew Morton; +Cc: linuxppc-embedded

Fix PowerPC NPe405H EMAC Tx channel assignments. EMAC unit in this 
chip uses common for 4xx "two Tx / one Rx" configuration.

Signed-off-by: Eugene Surovegin <ebs@ebshome.net>

diff --git a/arch/ppc/platforms/4xx/ibmnp405h.c b/arch/ppc/platforms/4xx/ibmnp405h.c
--- a/arch/ppc/platforms/4xx/ibmnp405h.c
+++ b/arch/ppc/platforms/4xx/ibmnp405h.c
@@ -34,7 +34,7 @@ static struct ocp_func_emac_data ibmnp40
 	.zmii_mux	= 1,		/* ZMII input of this EMAC */
 	.mal_idx	= 0,		/* MAL device index */
 	.mal_rx_chan	= 1,		/* MAL rx channel number */
-	.mal_tx_chan	= 1,		/* MAL tx channel number */
+	.mal_tx_chan	= 2,		/* MAL tx channel number */
 	.wol_irq	= 41,		/* WOL interrupt number */
 	.mdio_idx	= -1,		/* No shared MDIO */
 	.tah_idx	= -1,		/* No TAH */
@@ -46,7 +46,7 @@ static struct ocp_func_emac_data ibmnp40
 	.zmii_mux	= 2,		/* ZMII input of this EMAC */
 	.mal_idx	= 0,		/* MAL device index */
 	.mal_rx_chan	= 2,		/* MAL rx channel number */
-	.mal_tx_chan	= 2,		/* MAL tx channel number */
+	.mal_tx_chan	= 4,		/* MAL tx channel number */
 	.wol_irq	= 41,		/* WOL interrupt number */
 	.mdio_idx	= -1,		/* No shared MDIO */
 	.tah_idx	= -1,		/* No TAH */
@@ -58,7 +58,7 @@ static struct ocp_func_emac_data ibmnp40
 	.zmii_mux	= 3,		/* ZMII input of this EMAC */
 	.mal_idx	= 0,		/* MAL device index */
 	.mal_rx_chan	= 3,		/* MAL rx channel number */
-	.mal_tx_chan	= 3,		/* MAL tx channel number */
+	.mal_tx_chan	= 6,		/* MAL tx channel number */
 	.wol_irq	= 41,		/* WOL interrupt number */
 	.mdio_idx	= -1,		/* No shared MDIO */
 	.tah_idx	= -1,		/* No TAH */

^ permalink raw reply

* Re: How to map memory uncached on PPC.
From: Benjamin Herrenschmidt @ 2005-08-20  1:06 UTC (permalink / raw)
  To: Stephen Williams; +Cc: linuxppc-dev
In-Reply-To: <4305F7FE.7040709@icarus.com>

On Fri, 2005-08-19 at 08:17 -0700, Stephen Williams wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> 
> My setup is Linux PPC kernel 2.4.30 on an embedded PPC405BPr.
> The board has some image processing devices including compressors.
> I'm working with high image rates so performance is a issue.
> 
> The drivers for the pci based compressor chips support readv
> and use map_user_kiobuf and pci_map_single to map the output
> buffers for the read. (The devices do scatter DMA.) This is
> too slow, though. More time is spent mapping then compressing!
> 
> I did some measurements, at it seems that the vast amount of
> the time is spent in pci_map_single, which calls only the
> consistent_sync function, which for FROMDEVICE calls only
> invalidate_dcache_range. So I'm convinced that invalidating
> the cache for the output buffer (which is large, in case the
> image that arrives is large) is taking most of the time. So
> I want to eliminate it.
> 
> And the way I want to do that is to have a heap of memory in
> the user-mode process mapped uncached. The hope is that I can
> pass that through the readv to the driver, which sets up the
> DMA. Then I can skip the pci_map_single (and the thus the
> invalidate_dcache_range) thus saving lots of time.
> 
> Plan-B would be to have a driver allocate the heap of memory,
> but I really need the mapping into user mode to be uncached,
> as the processor does some final touch up (header et al) before
> sending it to the next device.

A simple experiment you can do is limit the memory used by the kernel
(booting with mem=xxxx) and then use mmap of /dev/mem to map the
remaining memory like if it was an IO device, uncached. With that, you
get a quick hack solution to validate the performance benefit at least.

Ben.

^ permalink raw reply

* Re: [PATCH] ppc32: 8xx pq platform system descriptions
From: Kumar Gala @ 2005-08-19 20:14 UTC (permalink / raw)
  To: Vitaly Bordug; +Cc: linuxppc-embedded list
In-Reply-To: <43062C9D.5060703@ru.mvista.com>

+/* access ports */
+#define setbits32(_addr, _v) out_be32(&(_addr), in_be32(&(_addr)) |   
(_v))
+#define clrbits32(_addr, _v) out_be32(&(_addr), in_be32(&(_addr)) & ~ 
(_v))
+
+#define setbits16(_addr, _v) out_be16(&(_addr), in_be16(&(_addr)) |   
(_v))
+#define clrbits16(_addr, _v) out_be16(&(_addr), in_be16(&(_addr)) & ~ 
(_v))
+

Needs to go.

+#define MPC8xx_INT_FEC1        SIU_LEVEL1
+#define MPC8xx_INT_FEC2        SIU_LEVEL3
+
+#define MPC8xx_INT_SCC1        (CPM_IRQ_OFFSET + CPMVEC_SCC1)
+#define MPC8xx_INT_SCC2        (CPM_IRQ_OFFSET + CPMVEC_SCC2)
+#define MPC8xx_INT_SCC3        (CPM_IRQ_OFFSET + CPMVEC_SCC3)
+#define MPC8xx_INT_SCC4        (CPM_IRQ_OFFSET + CPMVEC_SCC4)
+#define MPC8xx_INT_SMC1        (CPM_IRQ_OFFSET + CPMVEC_SMC1)
+#define MPC8xx_INT_SMC2        (CPM_IRQ_OFFSET + CPMVEC_SMC2)

Marcelo, we should look at what effect moving CPMVEC_* out of  
commproc.h into irq.h and cleaning things up has on the world.

- kumar

On Aug 19, 2005, at 2:01 PM, Vitaly Bordug wrote:

> Added ppc_sys device and system definitions for PowerQUICC I devices.
>
> Signed-off-by: Vitaly Bordug <vbordug@ru.mvista.com>
> -- 
> Sincerely,
> Vitaly
>
> <8xx_plats.diff>
> <ATT292304.txt>
>

^ permalink raw reply

* Re: How to build more than 16M ramdisk for u-boot
From: Grant Likely @ 2005-08-19 20:06 UTC (permalink / raw)
  To: ???, linuxppc-embedded
In-Reply-To: <001401c5a494$ffd659c0$1a0e000a@RoberHsu>

On Fri, Aug 19, 2005 at 04:07:04PM +0800, ??? wrote:
> Hi Grant:
> 
>    I'm already try it.But it still fail.Why i used so large ramdisk, is
> because net-snmp 5.x.x
> are too big, snmpd + snmptrapd almost 10M byte.
I think you're missunderstanding me.

"/sbin/mke2fs -F m0 ramdisk" means:
    create ext2 filesystem on file 'm0' of size 'ramdisk'
"/sbin/mke2fs -F -m0 ramdisk" means:
    create ext2 filesystem on file 'ramdisk' with 0% reserved

It looks like your missing a dash (-) for the 'm' option

g.

^ permalink raw reply

* SIGFPE on 8245
From: Andy G. @ 2005-08-19 19:40 UTC (permalink / raw)
  To: linuxppc-embedded

I'm working with a rather large multi-threaded application that after
a several hour run will often produce a floating point exception
(specifically a divide by zero exception).  I've manged to catch the
signal and use some home grown code to examine the current state of
the running thread as well as all of the others, but sadly this debug
information never provides any valuable information.  It appears as
though the crash is happening in the pthread library when trying to
execute a floating point store instruction (0x8114 listed below).

00008108 <__pthread_timedsuspend_new>:
8108:       7d 80 00 26     mfcr    r12
810c:       94 21 fc 90     stwu    r1,-880(r1)
8110:       7c 08 02 a6     mflr    r0                                     =
    =20
8114:       d9 c1 02 e0     stfd    f14,736(r1)  <--- SIGFPE happens here  =
=20

After looking over the 32-bit PPC Programming Env Manual it seems to
me that the floating point operations that result in +/- infinity will
disable the FPU and write the FPECR with the cause.  Next time a
floating point instruction is attempted we will get an exception since
the FPU is disabled and then we will throw the exception.

This information unfortunately tells me that I have to start digging
through the source code to find the programming error, but I'm hoping
I'm wrong about this.  Any advice or tips?

Thanks in advance,

-andy

^ permalink raw reply

* [PATCH] ppc32: 8xx pq platform system descriptions
From: Vitaly Bordug @ 2005-08-19 19:01 UTC (permalink / raw)
  To: Marcelo Tosatti; +Cc: Kumar Gala, linuxppc-embedded list

[-- Attachment #1: Type: text/plain, Size: 146 bytes --]

Added ppc_sys device and system definitions for PowerQUICC I devices.

Signed-off-by: Vitaly Bordug <vbordug@ru.mvista.com>
-- 
Sincerely,
Vitaly

[-- Attachment #2: 8xx_plats.diff --]
[-- Type: text/x-patch, Size: 8911 bytes --]

diff --git a/arch/ppc/syslib/Makefile b/arch/ppc/syslib/Makefile
--- a/arch/ppc/syslib/Makefile
+++ b/arch/ppc/syslib/Makefile
@@ -34,7 +34,8 @@ ifeq ($(CONFIG_40x),y)
 obj-$(CONFIG_PCI)		+= indirect_pci.o pci_auto.o ppc405_pci.o
 endif
 endif
-obj-$(CONFIG_8xx)		+= m8xx_setup.o ppc8xx_pic.o $(wdt-mpc8xx-y)
+obj-$(CONFIG_8xx)		+= m8xx_setup.o ppc8xx_pic.o $(wdt-mpc8xx-y) \
+				   ppc_sys.o mpc8xx_devices.o mpc8xx_sys.o
 ifeq ($(CONFIG_8xx),y)
 obj-$(CONFIG_PCI)		+= qspan_pci.o i8259.o
 endif
diff --git a/arch/ppc/syslib/mpc8xx_devices.c b/arch/ppc/syslib/mpc8xx_devices.c
new file mode 100644
--- /dev/null
+++ b/arch/ppc/syslib/mpc8xx_devices.c
@@ -0,0 +1,231 @@
+/*
+ * arch/ppc/syslib/mpc8xx_devices.c
+ *
+ * MPC8xx Device descriptions
+ *
+ * Maintainer: Kumar Gala <kumar.gala@freescale.com>
+ *
+ * Copyright 2005 MontaVista Software, Inc. by Vitaly Bordug<vbordug@ru.mvista.com>
+ *
+ * This program is free software; you can redistribute  it and/or modify it
+ * under  the terms of  the GNU General  Public License as published by the
+ * Free Software Foundation;  either version 2 of the  License, or (at your
+ * option) any later version.
+ */
+
+#include <linux/init.h>
+#include <linux/module.h>
+#include <linux/device.h>
+#include <linux/serial_8250.h>
+#include <linux/mii.h>
+#include <asm/commproc.h>
+#include <asm/mpc8xx.h>
+#include <asm/irq.h>
+#include <asm/ppc_sys.h>
+
+/* access ports */
+#define setbits32(_addr, _v) out_be32(&(_addr), in_be32(&(_addr)) |  (_v))
+#define clrbits32(_addr, _v) out_be32(&(_addr), in_be32(&(_addr)) & ~(_v))
+
+#define setbits16(_addr, _v) out_be16(&(_addr), in_be16(&(_addr)) |  (_v))
+#define clrbits16(_addr, _v) out_be16(&(_addr), in_be16(&(_addr)) & ~(_v))
+
+/* We use offsets for IORESOURCE_MEM to do not set dependences at compile time.
+ * They will get fixed up by mach_mpc8xx_fixup
+ */
+
+struct platform_device ppc_sys_platform_devices[] = {
+	[MPC8xx_CPM_FEC1] =	{
+		.name = "fsl-cpm-fec",
+		.id	= 1,
+		.num_resources = 2,
+		.resource = (struct resource[])	{
+			{
+				.name 	= "regs",
+				.start	= 0xe00,
+				.end	= 0xe88,
+				.flags	= IORESOURCE_MEM,
+			},
+			{
+				.name	= "interrupt",
+				.start	= MPC8xx_INT_FEC1,
+				.end	= MPC8xx_INT_FEC1,
+				.flags	= IORESOURCE_IRQ,
+			},
+		},
+	},
+	[MPC8xx_CPM_FEC2] =	{
+		.name = "fsl-cpm-fec",
+		.id	= 2,
+		.num_resources = 2,
+		.resource = (struct resource[])	{
+			{
+				.name	= "regs",
+				.start	= 0x1e00,
+				.end	= 0x1e88,
+				.flags	= IORESOURCE_MEM,
+			},
+			{
+				.name	= "interrupt",
+				.start	= MPC8xx_INT_FEC2,
+				.end	= MPC8xx_INT_FEC2,
+				.flags	= IORESOURCE_IRQ,
+			},
+		},
+	},
+	[MPC8xx_CPM_SCC1] = {
+		.name = "fsl-cpm-scc",
+		.id	= 1,
+		.num_resources = 3,
+		.resource = (struct resource[]) {
+			{
+				.name	= "regs",
+				.start	= 0xa00,
+				.end	= 0xa18,
+				.flags	= IORESOURCE_MEM,
+			},
+			{
+				.name 	= "pram",
+				.start 	= 0x3c00,
+				.end 	= 0x3c80,
+				.flags 	= IORESOURCE_MEM,
+			},
+			{
+				.name	= "interrupt",
+				.start	= MPC8xx_INT_SCC1,
+				.end	= MPC8xx_INT_SCC1,
+				.flags	= IORESOURCE_IRQ,
+			},
+		},
+	},
+	[MPC8xx_CPM_SCC2] = {
+		.name = "fsl-cpm-scc",
+		.id	= 2,
+		.num_resources	= 3,
+		.resource = (struct resource[]) {
+			{
+				.name	= "regs",
+				.start	= 0xa20,
+				.end	= 0xa38,
+				.flags	= IORESOURCE_MEM,
+			},
+			{
+				.name 	= "pram",
+				.start 	= 0x3d00,
+				.end 	= 0x3d80,
+				.flags 	= IORESOURCE_MEM,
+			},
+
+			{
+				.name	= "interrupt",
+				.start	= MPC8xx_INT_SCC2,
+				.end	= MPC8xx_INT_SCC2,
+				.flags	= IORESOURCE_IRQ,
+			},
+		},
+	},
+	[MPC8xx_CPM_SCC3] = {
+		.name = "fsl-cpm-scc",
+		.id	= 3,
+		.num_resources	= 3,
+		.resource = (struct resource[]) {
+			{
+				.name	= "regs",
+				.start	= 0xa40,
+				.end	= 0xa58,
+				.flags	= IORESOURCE_MEM,
+			},
+			{
+				.name 	= "pram",
+				.start 	= 0x3e00,
+				.end 	= 0x3e80,
+				.flags 	= IORESOURCE_MEM,
+			},
+
+			{
+				.name	= "interrupt",
+				.start	= MPC8xx_INT_SCC3,
+				.end	= MPC8xx_INT_SCC3,
+				.flags	= IORESOURCE_IRQ,
+			},
+		},
+	},
+	[MPC8xx_CPM_SCC4] = {
+		.name = "fsl-cpm-scc",
+		.id	= 4,
+		.num_resources	= 3,
+		.resource = (struct resource[]) {
+			{
+				.name	= "regs",
+				.start	= 0xa60,
+				.end	= 0xa78,
+				.flags	= IORESOURCE_MEM,
+			},
+			{
+				.name 	= "pram",
+				.start 	= 0x3f00,
+				.end 	= 0x3f80,
+				.flags 	= IORESOURCE_MEM,
+			},
+
+			{
+				.name	= "interrupt",
+				.start	= MPC8xx_INT_SCC4,
+				.end	= MPC8xx_INT_SCC4,
+				.flags	= IORESOURCE_IRQ,
+			},
+		},
+	},
+	[MPC8xx_CPM_SMC1] = {
+		.name = "fsl-cpm-smc",
+		.id	= 1,
+		.num_resources	= 2,
+		.resource = (struct resource[]) {
+			{
+				.name	= "regs",
+				.start	= 0xa82,
+				.end	= 0xa91,
+				.flags	= IORESOURCE_MEM,
+			},
+			{
+				.name	= "interrupt",
+				.start	= MPC8xx_INT_SMC1,
+				.end	= MPC8xx_INT_SMC1,
+				.flags	= IORESOURCE_IRQ,
+			},
+		},
+	},
+	[MPC8xx_CPM_SMC2] = {
+		.name = "fsl-cpm-smc",
+		.id	= 2,
+		.num_resources	= 2,
+		.resource = (struct resource[]) {
+			{
+				.name	= "regs",
+				.start	= 0xa92,
+				.end	= 0xaa1,
+				.flags	= IORESOURCE_MEM,
+			},
+			{
+				.name	= "interrupt",
+				.start	= MPC8xx_INT_SMC2,
+				.end	= MPC8xx_INT_SMC2,
+				.flags	= IORESOURCE_IRQ,
+			},
+		},
+	},
+};
+
+static int __init mach_mpc8xx_fixup(struct platform_device *pdev)
+{
+	ppc_sys_fixup_mem_resource (pdev, IMAP_ADDR);
+	return 0;
+}
+
+static int __init mach_mpc8xx_init(void)
+{
+	ppc_sys_device_fixup = mach_mpc8xx_fixup;
+	return 0;
+}
+
+postcore_initcall(mach_mpc8xx_init);
diff --git a/arch/ppc/syslib/mpc8xx_sys.c b/arch/ppc/syslib/mpc8xx_sys.c
new file mode 100644
--- /dev/null
+++ b/arch/ppc/syslib/mpc8xx_sys.c
@@ -0,0 +1,61 @@
+/*
+ * arch/ppc/platforms/mpc8xx_sys.c
+ *
+ * MPC8xx System descriptions
+ *
+ * Maintainer: Kumar Gala <kumar.gala@freescale.com>
+ *
+ * Copyright 2005 MontaVista Software, Inc. by Vitaly Bordug <vbordug@ru.mvista.com>
+ *
+ * This program is free software; you can redistribute  it and/or modify it
+ * under  the terms of  the GNU General  Public License as published by the
+ * Free Software Foundation;  either version 2 of the  License, or (at your
+ * option) any later version.
+ */
+
+#include <linux/init.h>
+#include <linux/module.h>
+#include <linux/device.h>
+#include <asm/ppc_sys.h>
+
+struct ppc_sys_spec *cur_ppc_sys_spec; 
+struct ppc_sys_spec ppc_sys_specs[] = {
+	{
+		.ppc_sys_name	= "MPC86X",
+		.mask 		= 0xFFFFFFFF,
+		.value 		= 0x00000000,
+		.num_devices	= 2,
+		.device_list	= (enum ppc_sys_devices[])
+		{
+			MPC8xx_CPM_FEC1,
+			MPC8xx_CPM_SCC1,
+			MPC8xx_CPM_SCC2,
+			MPC8xx_CPM_SCC3,
+			MPC8xx_CPM_SCC4,
+			MPC8xx_CPM_SMC1,
+			MPC8xx_CPM_SMC2,
+		},
+	},
+	{
+		.ppc_sys_name	= "MPC885",
+		.mask 		= 0xFFFFFFFF,
+		.value 		= 0x00000000,
+		.num_devices	= 3,
+		.device_list	= (enum ppc_sys_devices[])
+		{
+			MPC8xx_CPM_FEC1,
+			MPC8xx_CPM_FEC2,
+			MPC8xx_CPM_SCC1,
+			MPC8xx_CPM_SCC2,
+			MPC8xx_CPM_SCC3,
+			MPC8xx_CPM_SCC4,
+			MPC8xx_CPM_SMC1,
+			MPC8xx_CPM_SMC2,
+		},
+	},
+	{	/* default match */
+		.ppc_sys_name	= "",
+		.mask 		= 0x00000000,
+		.value 		= 0x00000000,
+	},
+};
diff --git a/include/asm-ppc/irq.h b/include/asm-ppc/irq.h
--- a/include/asm-ppc/irq.h
+++ b/include/asm-ppc/irq.h
@@ -133,6 +133,16 @@ irq_canonicalize(int irq)
 #define	SIU_IRQ7	(14)
 #define	SIU_LEVEL7	(15)
 
+#define MPC8xx_INT_FEC1		SIU_LEVEL1
+#define MPC8xx_INT_FEC2		SIU_LEVEL3
+
+#define MPC8xx_INT_SCC1		(CPM_IRQ_OFFSET + CPMVEC_SCC1)
+#define MPC8xx_INT_SCC2		(CPM_IRQ_OFFSET + CPMVEC_SCC2)
+#define MPC8xx_INT_SCC3		(CPM_IRQ_OFFSET + CPMVEC_SCC3)
+#define MPC8xx_INT_SCC4		(CPM_IRQ_OFFSET + CPMVEC_SCC4)
+#define MPC8xx_INT_SMC1		(CPM_IRQ_OFFSET + CPMVEC_SMC1)
+#define MPC8xx_INT_SMC2		(CPM_IRQ_OFFSET + CPMVEC_SMC2)
+
 /* The internal interrupts we can configure as we see fit.
  * My personal preference is CPM at level 2, which puts it above the
  * MBX PCI/ISA/IDE interrupts.
diff --git a/include/asm-ppc/mpc8xx.h b/include/asm-ppc/mpc8xx.h
--- a/include/asm-ppc/mpc8xx.h
+++ b/include/asm-ppc/mpc8xx.h
@@ -101,6 +101,22 @@ extern unsigned char __res[];
 
 struct pt_regs;
 
+enum ppc_sys_devices {
+	MPC8xx_CPM_FEC1,
+	MPC8xx_CPM_FEC2,
+	MPC8xx_CPM_I2C,
+	MPC8xx_CPM_SCC1,
+	MPC8xx_CPM_SCC2,
+	MPC8xx_CPM_SCC3,
+	MPC8xx_CPM_SCC4,
+	MPC8xx_CPM_SPI,
+	MPC8xx_CPM_MCC1,
+	MPC8xx_CPM_MCC2,
+	MPC8xx_CPM_SMC1,
+	MPC8xx_CPM_SMC2,
+	MPC8xx_CPM_USB,
+};
+
 #endif /* !__ASSEMBLY__ */
 #endif /* CONFIG_8xx */
 #endif /* __CONFIG_8xx_DEFS */
diff --git a/include/asm-ppc/ppc_sys.h b/include/asm-ppc/ppc_sys.h
--- a/include/asm-ppc/ppc_sys.h
+++ b/include/asm-ppc/ppc_sys.h
@@ -25,6 +25,8 @@
 #include <asm/mpc83xx.h>
 #elif defined(CONFIG_85xx)
 #include <asm/mpc85xx.h>
+#elif defined(CONFIG_8xx)
+#include <asm/mpc8xx.h>
 #elif defined(CONFIG_PPC_MPC52xx)
 #include <asm/mpc52xx.h>
 #elif defined(CONFIG_MPC10X_BRIDGE)

^ permalink raw reply


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox