* Re: [PATCH] I2C: Add support for 64bit system.
From: xulei @ 2010-12-21 7:32 UTC (permalink / raw)
To: Ben Dooks; +Cc: linuxppc-dev, linux-i2c
In-Reply-To: <20101220145954.GA1126@trinity.fluff.org>
yes, it has been built and could access the RTC well.
On =E4=B8=80, 2010-12-20 at 14:59 +0000, Ben Dooks wrote:
> On Mon, Dec 20, 2010 at 03:37:34PM +0800, Xulei wrote:
> > Currently I2C_MPC supports 32bit system only, then this
> > modification makes it support 32bit and 64bit system both.
> >=20
> > Signed-off-by: Xulei <B33228@freescale.com>
>=20
> This been build or run tested?
>=20
> > ---
> > drivers/i2c/busses/Kconfig | 2 +-
> > 1 files changed, 1 insertions(+), 1 deletions(-)
> >=20
> > diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
> > index 9c6170c..3392f4b 100644
> > --- a/drivers/i2c/busses/Kconfig
> > +++ b/drivers/i2c/busses/Kconfig
> > @@ -422,7 +422,7 @@ config I2C_IXP2000
> > =20
> > config I2C_MPC
> > tristate "MPC107/824x/85xx/512x/52xx/83xx/86xx"
> > - depends on PPC32
> > + depends on PPC32 || PPC64
> > help
> > If you say yes to this option, support will be included for the
> > built-in I2C interface on the MPC107, Tsi107, MPC512x, MPC52xx,
> > --=20
> > 1.7.0.4
> >=20
> >=20
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-i2c" =
in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
>=20
^ permalink raw reply
* Re: [PATCH 2/4] x86/of: Add building device tree blob(s) into image.
From: Michal Marek @ 2010-12-21 14:19 UTC (permalink / raw)
To: dirk.brandewie
Cc: linux-arch, microblaze-uclinux, devicetree-discuss, linux-kernel,
sodaville, linuxppc-dev
In-Reply-To: <abe67e5689fef1d94e57be68ec5ef47a8f13bf8e.1291820034.git.dirk.brandewie@gmail.com>
On 8.12.2010 16:01, dirk.brandewie@gmail.com wrote:
> From: Dirk Brandewie <dirk.brandewie@gmail.com>
>
> This patch adds linking device tree blob into vmlinux. DTB's are
> added by adding the blob object name to list of objects to be linked
> into the image.
>
> Signed-off-by: Dirk Brandewie <dirk.brandewie@gmail.com>
> ---
> arch/x86/platform/ce4100/Makefile | 10 ++++++++++
> 1 files changed, 10 insertions(+), 0 deletions(-)
>
> diff --git a/arch/x86/platform/ce4100/Makefile b/arch/x86/platform/ce4100/Makefile
> index 91fc929..e5f3b7b 100644
> --- a/arch/x86/platform/ce4100/Makefile
> +++ b/arch/x86/platform/ce4100/Makefile
> @@ -1 +1,11 @@
> obj-$(CONFIG_X86_INTEL_CE) += ce4100.o
> +clean-files := *dtb.S
> +
> +ifdef CONFIG_X86_OF
> +###
> +# device tree blob
> +obj-$(CONFIG_X86_INTEL_CE) += ce4100.dtb.o
> +
> +$(obj)/%.dtb: $(src)/%.dts
> + $(call cmd,dtc)
> +endif
Hi,
CONFIG_X86_OF should be defined in some Kconfig file and there is no
ce4100.dts??
Michal
^ permalink raw reply
* Re: [PATCH 1/4] of: Add support for linking device tree blobs into vmlinux
From: Michal Marek @ 2010-12-21 14:24 UTC (permalink / raw)
To: dirk.brandewie
Cc: linux-arch, microblaze-uclinux, devicetree-discuss, linux-kernel,
sodaville, linuxppc-dev
In-Reply-To: <99ff131ecbee621f0d3178d6d3896d6f39207d6f.1291820034.git.dirk.brandewie@gmail.com>
On 8.12.2010 16:01, dirk.brandewie@gmail.com wrote:
> +quiet_cmd_dt_S_dtb= DTB $@
> +quiet_cmd_dtc = DTC $@
Hi,
just an aesthetic remark: The target name should start at the 9th
column, so there should be 5 spaces after both "DTB" and "DTC".
Michal
^ permalink raw reply
* Re: [PATCH 1/4] of: Add support for linking device tree blobs into vmlinux
From: Dirk Brandewie @ 2010-12-21 17:52 UTC (permalink / raw)
To: Michal Marek
Cc: linux-arch, microblaze-uclinux, devicetree-discuss, linux-kernel,
sodaville, linuxppc-dev
In-Reply-To: <4D10B8AA.3070500@suse.cz>
On 12/21/2010 06:24 AM, Michal Marek wrote:
> On 8.12.2010 16:01, dirk.brandewie@gmail.com wrote:
>> +quiet_cmd_dt_S_dtb= DTB $@
>
>> +quiet_cmd_dtc = DTC $@
>
> Hi,
>
> just an aesthetic remark: The target name should start at the 9th
> column, so there should be 5 spaces after both "DTB" and "DTC".
>
> Michal
Thanks I will fix this.
--Dirk
^ permalink raw reply
* [PATCH RESEND 2] mpc52xx: gpt: include fs.h
From: Wolfram Sang @ 2010-12-22 15:42 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Andrew Morton
Fix build errors like these (from a randconfig and my defconfig for a custom board):
src/arch/powerpc/platforms/52xx/mpc52xx_gpt.c:549: error: dereferencing pointer to incomplete type: 1 errors in 1 logs
src/arch/powerpc/platforms/52xx/mpc52xx_gpt.c:636: error: implicit declaration of function 'nonseekable_open': 1 errors in 1 logs
src/arch/powerpc/platforms/52xx/mpc52xx_gpt.c:657: error: variable 'mpc52xx_wdt_fops' has initializer but incomplete type: 1 errors in 1 logs
src/arch/powerpc/platforms/52xx/mpc52xx_gpt.c:658: error: excess elements in struct initializer: 1 errors in 1 logs
src/arch/powerpc/platforms/52xx/mpc52xx_gpt.c:658: error: unknown field 'owner' specified in initializer: 1 errors in 1 logs
...
Reported-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
Cc: Grant Likely <grant.likely@secretlab.ca>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
---
rc7 is out and we still have this build-failure. Please apply.
arch/powerpc/platforms/52xx/mpc52xx_gpt.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/platforms/52xx/mpc52xx_gpt.c b/arch/powerpc/platforms/52xx/mpc52xx_gpt.c
index fea833e..e0d703c 100644
--- a/arch/powerpc/platforms/52xx/mpc52xx_gpt.c
+++ b/arch/powerpc/platforms/52xx/mpc52xx_gpt.c
@@ -63,6 +63,7 @@
#include <linux/of_gpio.h>
#include <linux/kernel.h>
#include <linux/slab.h>
+#include <linux/fs.h>
#include <linux/watchdog.h>
#include <linux/miscdevice.h>
#include <linux/uaccess.h>
--
1.7.2.3
^ permalink raw reply related
* [PATCH RESEND] pata_mpc52xx: driver needs BMDMA
From: Wolfram Sang @ 2010-12-22 15:50 UTC (permalink / raw)
To: linuxppc-dev; +Cc: linux-ide, Andrew Morton, Jeff Garzik, linux-kernel
Found by this build-error if BMDMA is disabled:
drivers/ata/pata_mpc52xx.c: In function 'mpc52xx_ata_init_one':
drivers/ata/pata_mpc52xx.c:662: error: 'ata_bmdma_interrupt' undeclared (first use in this function)
...
Move the Kconfig entry to the proper location as needed since
9a7780c9acb821fe1c2b6fc53f74cc2556ff5364 (libata-sff: make BMDMA optional)
Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
---
This is a build-failure, so fixing it before 2.6.37 would be great.
drivers/ata/Kconfig | 20 ++++++++++----------
drivers/ata/Makefile | 2 +-
2 files changed, 11 insertions(+), 11 deletions(-)
diff --git a/drivers/ata/Kconfig b/drivers/ata/Kconfig
index 11ec911..85756b8 100644
--- a/drivers/ata/Kconfig
+++ b/drivers/ata/Kconfig
@@ -128,16 +128,6 @@ config PDC_ADMA
If unsure, say N.
-config PATA_MPC52xx
- tristate "Freescale MPC52xx SoC internal IDE"
- depends on PPC_MPC52xx && PPC_BESTCOMM
- select PPC_BESTCOMM_ATA
- help
- This option enables support for integrated IDE controller
- of the Freescale MPC52xx SoC.
-
- If unsure, say N.
-
config PATA_OCTEON_CF
tristate "OCTEON Boot Bus Compact Flash support"
depends on CPU_CAVIUM_OCTEON
@@ -491,6 +481,16 @@ config PATA_MARVELL
If unsure, say N.
+config PATA_MPC52xx
+ tristate "Freescale MPC52xx SoC internal IDE"
+ depends on PPC_MPC52xx && PPC_BESTCOMM
+ select PPC_BESTCOMM_ATA
+ help
+ This option enables support for integrated IDE controller
+ of the Freescale MPC52xx SoC.
+
+ If unsure, say N.
+
config PATA_NETCELL
tristate "NETCELL Revolution RAID support"
depends on PCI
diff --git a/drivers/ata/Makefile b/drivers/ata/Makefile
index c501af5..2b67c90 100644
--- a/drivers/ata/Makefile
+++ b/drivers/ata/Makefile
@@ -11,7 +11,6 @@ obj-$(CONFIG_SATA_DWC) += sata_dwc_460ex.o
# SFF w/ custom DMA
obj-$(CONFIG_PDC_ADMA) += pdc_adma.o
-obj-$(CONFIG_PATA_MPC52xx) += pata_mpc52xx.o
obj-$(CONFIG_PATA_OCTEON_CF) += pata_octeon_cf.o
obj-$(CONFIG_SATA_QSTOR) += sata_qstor.o
obj-$(CONFIG_SATA_SX4) += sata_sx4.o
@@ -52,6 +51,7 @@ obj-$(CONFIG_PATA_IT821X) += pata_it821x.o
obj-$(CONFIG_PATA_JMICRON) += pata_jmicron.o
obj-$(CONFIG_PATA_MACIO) += pata_macio.o
obj-$(CONFIG_PATA_MARVELL) += pata_marvell.o
+obj-$(CONFIG_PATA_MPC52xx) += pata_mpc52xx.o
obj-$(CONFIG_PATA_NETCELL) += pata_netcell.o
obj-$(CONFIG_PATA_NINJA32) += pata_ninja32.o
obj-$(CONFIG_PATA_NS87415) += pata_ns87415.o
--
1.7.2.3
^ permalink raw reply related
* [PATCH 0/4] V3 Add ability to link device blob(s) into vmlinux
From: dirk.brandewie @ 2010-12-22 19:57 UTC (permalink / raw)
To: linux-kernel
Cc: linux-arch, mmarek, linux-kbuild, microblaze-uclinux,
devicetree-discuss, dirk.brandewie, linuxppc-dev
From: Dirk Brandewie <dirk.brandewie@gmail.com>
This patch set adds the ability to link device tree blobs into
vmlinux.
Patch 1 implements the changes to include/asm-generic/vmlinux.lds.h and
adds a generic rule for generating DTB objects to be linked vmlinux.
Patch 2 implements linking a DTB into an x86 image.
Patch 3-4 move {powerpc,microblaze}/boot/Makefile to use the dtc rule
in patch 1.
This patch set has been tested on x86.
Powerpc and Microblaze have been compile tested with and without patch
3 and 4 applied.
Changes from V1:
Documentation added for dtc command in Makefile.lib to
Documentation/kbuild/makefiles.txt
Separate DTB_ALIGNMENT define removed.
FORCE removed from dtc rule.
Removed hardcoded path to dts files from dtc command.
Moved %.dtb: %.dts rule to arch specific makefiles.
Patch for adding kernel command line option to pass in dtb_compat
string dropped from this set will be submitted seperately.
Changes from V2:
Rule to create assembly wrapper for blob changed to use Sam Ravnborgs
suggested implementation.
Rules in architecture specific Makefiles changed to use the cmd
function instead of the if_changed function.
Changes from V3:
Cosmetic fix of DTC quiet command
Dirk Brandewie (4):
of: Add support for linking device tree blobs into vmlinux
x86/of: Add building device tree blob(s) into image.
of/powerpc: Use generic rule to build dtb's
microblaze/of: Use generic rule to build dtb's
Documentation/kbuild/makefiles.txt | 15 +++++++++++++++
arch/microblaze/boot/Makefile | 12 +++---------
arch/powerpc/boot/Makefile | 8 +++-----
arch/x86/platform/ce4100/Makefile | 10 ++++++++++
include/asm-generic/vmlinux.lds.h | 13 +++++++++++--
scripts/Makefile.lib | 23 +++++++++++++++++++++++
6 files changed, 65 insertions(+), 16 deletions(-)
--
1.7.2.3
^ permalink raw reply
* [PATCH 1/4] of: Add support for linking device tree blobs into vmlinux
From: dirk.brandewie @ 2010-12-22 19:57 UTC (permalink / raw)
To: linux-kernel
Cc: linux-arch, mmarek, linux-kbuild, microblaze-uclinux,
devicetree-discuss, dirk.brandewie, linuxppc-dev
In-Reply-To: <1293047849-26078-1-git-send-email-dirk.brandewie@gmail.com>
From: Dirk Brandewie <dirk.brandewie@gmail.com>
This patch adds support for linking device tree blob(s) into
vmlinux. Modifies asm-generic/vmlinux.lds.h to add linking
.dtb sections into vmlinux. To maintain compatiblity with the of/fdt
driver code platforms MUST copy the blob to a non-init memory location
before the kernel frees the .init.* sections in the image.
Modifies scripts/Makefile.lib to add a kbuild command to
compile DTS files to device tree blobs and a rule to create objects to
wrap the blobs for linking.
STRUCT_ALIGNMENT is defined in vmlinux.lds.h for use in the rule to
create wrapper objects for the dtb in Makefile.lib. The
STRUCT_ALIGN() macro in vmlinux.lds.h is modified to use the
STRUCT_ALIGNMENT definition.
The DTB's are placed on 32 byte boundries to allow parsing the blob
with driver/of/fdt.c during early boot without having to copy the blob
to get the structure alignment GCC expects.
A DTB is linked in by adding the DTB object to the list of objects to
be linked into vmlinux in the archtecture specific Makefile using
obj-y += foo.dtb.o
Signed-off-by: Dirk Brandewie <dirk.brandewie@gmail.com>
---
Documentation/kbuild/makefiles.txt | 15 +++++++++++++++
include/asm-generic/vmlinux.lds.h | 13 +++++++++++--
scripts/Makefile.lib | 23 +++++++++++++++++++++++
3 files changed, 49 insertions(+), 2 deletions(-)
diff --git a/Documentation/kbuild/makefiles.txt b/Documentation/kbuild/makefiles.txt
index 0ef00bd..86e3cd0 100644
--- a/Documentation/kbuild/makefiles.txt
+++ b/Documentation/kbuild/makefiles.txt
@@ -1136,6 +1136,21 @@ When kbuild executes, the following steps are followed (roughly):
resulting in the target file being recompiled for no
obvious reason.
+ dtc
+ Create flattend device tree blob object suitable for linking
+ into vmlinux. Device tree blobs linked into vmlinux are placed
+ in an init section in the image. Platform code *must* copy the
+ blob to non-init memory prior to calling unflatten_device_tree().
+
+ Example:
+ #arch/x86/platform/ce4100/Makefile
+ clean-files := *dtb.S
+
+ DTC_FLAGS := -p 1024
+ obj-y += foo.dtb.o
+
+ $(obj)/%.dtb: $(src)/%.dts
+ $(call cmd,dtc)
--- 6.7 Custom kbuild commands
diff --git a/include/asm-generic/vmlinux.lds.h b/include/asm-generic/vmlinux.lds.h
index bd69d79..05cbad0 100644
--- a/include/asm-generic/vmlinux.lds.h
+++ b/include/asm-generic/vmlinux.lds.h
@@ -67,7 +67,8 @@
* Align to a 32 byte boundary equal to the
* alignment gcc 4.5 uses for a struct
*/
-#define STRUCT_ALIGN() . = ALIGN(32)
+#define STRUCT_ALIGNMENT 32
+#define STRUCT_ALIGN() . = ALIGN(STRUCT_ALIGNMENT)
/* The actual configuration determine if the init/exit sections
* are handled as text/data or they can be discarded (which
@@ -146,6 +147,13 @@
#define TRACE_SYSCALLS()
#endif
+
+#define KERNEL_DTB() \
+ STRUCT_ALIGN(); \
+ VMLINUX_SYMBOL(__dtb_start) = .; \
+ *(.dtb.init.rodata) \
+ VMLINUX_SYMBOL(__dtb_end) = .;
+
/* .data section */
#define DATA_DATA \
*(.data) \
@@ -468,7 +476,8 @@
MCOUNT_REC() \
DEV_DISCARD(init.rodata) \
CPU_DISCARD(init.rodata) \
- MEM_DISCARD(init.rodata)
+ MEM_DISCARD(init.rodata) \
+ KERNEL_DTB()
#define INIT_TEXT \
*(.init.text) \
diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib
index 4c72c11..7df8eb5 100644
--- a/scripts/Makefile.lib
+++ b/scripts/Makefile.lib
@@ -200,6 +200,29 @@ quiet_cmd_gzip = GZIP $@
cmd_gzip = (cat $(filter-out FORCE,$^) | gzip -f -9 > $@) || \
(rm -f $@ ; false)
+# DTC
+# ---------------------------------------------------------------------------
+
+# Generate an assembly file to wrap the output of the device tree compiler
+quiet_cmd_dt_S_dtb= DTB $@
+cmd_dt_S_dtb= \
+( \
+ echo '\#include <asm-generic/vmlinux.lds.h>'; \
+ echo '.section .dtb.init.rodata,"a"'; \
+ echo '.balign STRUCT_ALIGNMENT'; \
+ echo '.global __dtb_$(*F)_begin'; \
+ echo '__dtb_$(*F)_begin:'; \
+ echo '.incbin "$<" '; \
+ echo '__dtb_$(*F)_end:'; \
+ echo '.global __dtb_$(*F)_end'; \
+ echo '.balign STRUCT_ALIGNMENT'; \
+) > $@
+
+$(obj)/%.dtb.S: $(obj)/%.dtb
+ $(call cmd,dt_S_dtb)
+
+quiet_cmd_dtc = DTC $@
+ cmd_dtc = $(objtree)/scripts/dtc/dtc -O dtb -o $@ -b 0 $(DTC_FLAGS) $<
# Bzip2
# ---------------------------------------------------------------------------
--
1.7.2.3
^ permalink raw reply related
* [PATCH 2/4] x86/of: Add building device tree blob(s) into image.
From: dirk.brandewie @ 2010-12-22 19:57 UTC (permalink / raw)
To: linux-kernel
Cc: linux-arch, mmarek, linux-kbuild, microblaze-uclinux,
devicetree-discuss, dirk.brandewie, linuxppc-dev
In-Reply-To: <1293047849-26078-1-git-send-email-dirk.brandewie@gmail.com>
From: Dirk Brandewie <dirk.brandewie@gmail.com>
This patch adds linking device tree blob into vmlinux. DTB's are
added by adding the blob object name to list of objects to be linked
into the image.
Signed-off-by: Dirk Brandewie <dirk.brandewie@gmail.com>
---
arch/x86/platform/ce4100/Makefile | 10 ++++++++++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/arch/x86/platform/ce4100/Makefile b/arch/x86/platform/ce4100/Makefile
index 91fc929..e5f3b7b 100644
--- a/arch/x86/platform/ce4100/Makefile
+++ b/arch/x86/platform/ce4100/Makefile
@@ -1 +1,11 @@
obj-$(CONFIG_X86_INTEL_CE) += ce4100.o
+clean-files := *dtb.S
+
+ifdef CONFIG_X86_OF
+###
+# device tree blob
+obj-$(CONFIG_X86_INTEL_CE) += ce4100.dtb.o
+
+$(obj)/%.dtb: $(src)/%.dts
+ $(call cmd,dtc)
+endif
--
1.7.2.3
^ permalink raw reply related
* [PATCH 3/4] of/powerpc: Use generic rule to build dtb's
From: dirk.brandewie @ 2010-12-22 19:57 UTC (permalink / raw)
To: linux-kernel
Cc: linux-arch, mmarek, linux-kbuild, microblaze-uclinux,
devicetree-discuss, dirk.brandewie, linuxppc-dev
In-Reply-To: <1293047849-26078-1-git-send-email-dirk.brandewie@gmail.com>
From: Dirk Brandewie <dirk.brandewie@gmail.com>
Modify arch/powerpc/boot/Makefile to use dtc command in
scripts/Makefile.lib
Signed-off-by: Dirk Brandewie <dirk.brandewie@gmail.com>
---
arch/powerpc/boot/Makefile | 8 +++-----
1 files changed, 3 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile
index fae8192..96deec6 100644
--- a/arch/powerpc/boot/Makefile
+++ b/arch/powerpc/boot/Makefile
@@ -35,7 +35,7 @@ endif
BOOTCFLAGS += -I$(obj) -I$(srctree)/$(obj)
-DTS_FLAGS ?= -p 1024
+DTC_FLAGS ?= -p 1024
$(obj)/4xx.o: BOOTCFLAGS += -mcpu=405
$(obj)/ebony.o: BOOTCFLAGS += -mcpu=405
@@ -332,10 +332,8 @@ $(obj)/treeImage.%: vmlinux $(obj)/%.dtb $(wrapperbits)
$(call if_changed,wrap,treeboot-$*,,$(obj)/$*.dtb)
# Rule to build device tree blobs
-DTC = $(objtree)/scripts/dtc/dtc
-
-$(obj)/%.dtb: $(dtstree)/%.dts
- $(DTC) -O dtb -o $(obj)/$*.dtb -b 0 $(DTS_FLAGS) $(dtstree)/$*.dts
+$(obj)/%.dtb: $(src)/dts/%.dts
+ $(call cmd,dtc)
# If there isn't a platform selected then just strip the vmlinux.
ifeq (,$(image-y))
--
1.7.2.3
^ permalink raw reply related
* [PATCH 4/4] microblaze/of: Use generic rule to build dtb's
From: dirk.brandewie @ 2010-12-22 19:57 UTC (permalink / raw)
To: linux-kernel
Cc: linux-arch, mmarek, linux-kbuild, microblaze-uclinux,
devicetree-discuss, dirk.brandewie, linuxppc-dev
In-Reply-To: <1293047849-26078-1-git-send-email-dirk.brandewie@gmail.com>
From: Dirk Brandewie <dirk.brandewie@gmail.com>
Modify arch/powerpc/boot/Makefile to use dtc command in
scripts/Makefile.lib
Signed-off-by: Dirk Brandewie <dirk.brandewie@gmail.com>
---
arch/microblaze/boot/Makefile | 12 +++---------
1 files changed, 3 insertions(+), 9 deletions(-)
diff --git a/arch/microblaze/boot/Makefile b/arch/microblaze/boot/Makefile
index be01d78..4c4e58e 100644
--- a/arch/microblaze/boot/Makefile
+++ b/arch/microblaze/boot/Makefile
@@ -10,9 +10,6 @@ targets := linux.bin linux.bin.gz simpleImage.%
OBJCOPYFLAGS := -O binary
-# Where the DTS files live
-dtstree := $(srctree)/$(src)/dts
-
# Ensure system.dtb exists
$(obj)/linked_dtb.o: $(obj)/system.dtb
@@ -51,14 +48,11 @@ $(obj)/simpleImage.%: vmlinux FORCE
$(call if_changed,strip)
@echo 'Kernel: $@ is ready' ' (#'`cat .version`')'
-# Rule to build device tree blobs
-DTC = $(objtree)/scripts/dtc/dtc
# Rule to build device tree blobs
-quiet_cmd_dtc = DTC $@
- cmd_dtc = $(DTC) -O dtb -o $(obj)/$*.dtb -b 0 -p 1024 $(dtstree)/$*.dts
+DTC_FLAGS := -p 1024
-$(obj)/%.dtb: $(dtstree)/%.dts FORCE
- $(call if_changed,dtc)
+$(obj)/%.dtb: $(src)/dts/%.dts FORCE
+ $(call cmd,dtc)
clean-files += *.dtb simpleImage.*.unstrip linux.bin.ub
--
1.7.2.3
^ permalink raw reply related
* Re: [PATCH 1/4] of: Add support for linking device tree blobs into vmlinux
From: Michal Marek @ 2010-12-22 22:36 UTC (permalink / raw)
To: dirk.brandewie
Cc: linux-arch, linux-kbuild, microblaze-uclinux, devicetree-discuss,
linux-kernel, linuxppc-dev
In-Reply-To: <1293047849-26078-2-git-send-email-dirk.brandewie@gmail.com>
On 22.12.2010 20:57, dirk.brandewie@gmail.com wrote:
> From: Dirk Brandewie<dirk.brandewie@gmail.com>
>
> This patch adds support for linking device tree blob(s) into
> vmlinux. Modifies asm-generic/vmlinux.lds.h to add linking
> .dtb sections into vmlinux. To maintain compatiblity with the of/fdt
> driver code platforms MUST copy the blob to a non-init memory location
> before the kernel frees the .init.* sections in the image.
>
> Modifies scripts/Makefile.lib to add a kbuild command to
> compile DTS files to device tree blobs and a rule to create objects to
> wrap the blobs for linking.
>
> STRUCT_ALIGNMENT is defined in vmlinux.lds.h for use in the rule to
> create wrapper objects for the dtb in Makefile.lib. The
> STRUCT_ALIGN() macro in vmlinux.lds.h is modified to use the
> STRUCT_ALIGNMENT definition.
>
> The DTB's are placed on 32 byte boundries to allow parsing the blob
> with driver/of/fdt.c during early boot without having to copy the blob
> to get the structure alignment GCC expects.
>
> A DTB is linked in by adding the DTB object to the list of objects to
> be linked into vmlinux in the archtecture specific Makefile using
> obj-y += foo.dtb.o
>
> Signed-off-by: Dirk Brandewie<dirk.brandewie@gmail.com>
Hi,
you can add
Acked-by: Michal Marek <mmarek@suse.cz>
but I thing this series should go through the tip tree, as your primary
target seems to be x86 and patch 2/4 depends on the ce4100 code that is
only in tip.
Michal
> ---
> Documentation/kbuild/makefiles.txt | 15 +++++++++++++++
> include/asm-generic/vmlinux.lds.h | 13 +++++++++++--
> scripts/Makefile.lib | 23 +++++++++++++++++++++++
> 3 files changed, 49 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/kbuild/makefiles.txt b/Documentation/kbuild/makefiles.txt
> index 0ef00bd..86e3cd0 100644
> --- a/Documentation/kbuild/makefiles.txt
> +++ b/Documentation/kbuild/makefiles.txt
> @@ -1136,6 +1136,21 @@ When kbuild executes, the following steps are followed (roughly):
> resulting in the target file being recompiled for no
> obvious reason.
>
> + dtc
> + Create flattend device tree blob object suitable for linking
> + into vmlinux. Device tree blobs linked into vmlinux are placed
> + in an init section in the image. Platform code *must* copy the
> + blob to non-init memory prior to calling unflatten_device_tree().
> +
> + Example:
> + #arch/x86/platform/ce4100/Makefile
> + clean-files := *dtb.S
> +
> + DTC_FLAGS := -p 1024
> + obj-y += foo.dtb.o
> +
> + $(obj)/%.dtb: $(src)/%.dts
> + $(call cmd,dtc)
>
> --- 6.7 Custom kbuild commands
>
> diff --git a/include/asm-generic/vmlinux.lds.h b/include/asm-generic/vmlinux.lds.h
> index bd69d79..05cbad0 100644
> --- a/include/asm-generic/vmlinux.lds.h
> +++ b/include/asm-generic/vmlinux.lds.h
> @@ -67,7 +67,8 @@
> * Align to a 32 byte boundary equal to the
> * alignment gcc 4.5 uses for a struct
> */
> -#define STRUCT_ALIGN() . = ALIGN(32)
> +#define STRUCT_ALIGNMENT 32
> +#define STRUCT_ALIGN() . = ALIGN(STRUCT_ALIGNMENT)
>
> /* The actual configuration determine if the init/exit sections
> * are handled as text/data or they can be discarded (which
> @@ -146,6 +147,13 @@
> #define TRACE_SYSCALLS()
> #endif
>
> +
> +#define KERNEL_DTB() \
> + STRUCT_ALIGN(); \
> + VMLINUX_SYMBOL(__dtb_start) = .; \
> + *(.dtb.init.rodata) \
> + VMLINUX_SYMBOL(__dtb_end) = .;
> +
> /* .data section */
> #define DATA_DATA \
> *(.data) \
> @@ -468,7 +476,8 @@
> MCOUNT_REC() \
> DEV_DISCARD(init.rodata) \
> CPU_DISCARD(init.rodata) \
> - MEM_DISCARD(init.rodata)
> + MEM_DISCARD(init.rodata) \
> + KERNEL_DTB()
>
> #define INIT_TEXT \
> *(.init.text) \
> diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib
> index 4c72c11..7df8eb5 100644
> --- a/scripts/Makefile.lib
> +++ b/scripts/Makefile.lib
> @@ -200,6 +200,29 @@ quiet_cmd_gzip = GZIP $@
> cmd_gzip = (cat $(filter-out FORCE,$^) | gzip -f -9> $@) || \
> (rm -f $@ ; false)
>
> +# DTC
> +# ---------------------------------------------------------------------------
> +
> +# Generate an assembly file to wrap the output of the device tree compiler
> +quiet_cmd_dt_S_dtb= DTB $@
> +cmd_dt_S_dtb= \
> +( \
> + echo '\#include<asm-generic/vmlinux.lds.h>'; \
> + echo '.section .dtb.init.rodata,"a"'; \
> + echo '.balign STRUCT_ALIGNMENT'; \
> + echo '.global __dtb_$(*F)_begin'; \
> + echo '__dtb_$(*F)_begin:'; \
> + echo '.incbin "$<" '; \
> + echo '__dtb_$(*F)_end:'; \
> + echo '.global __dtb_$(*F)_end'; \
> + echo '.balign STRUCT_ALIGNMENT'; \
> +)> $@
> +
> +$(obj)/%.dtb.S: $(obj)/%.dtb
> + $(call cmd,dt_S_dtb)
> +
> +quiet_cmd_dtc = DTC $@
> + cmd_dtc = $(objtree)/scripts/dtc/dtc -O dtb -o $@ -b 0 $(DTC_FLAGS) $<
>
> # Bzip2
> # ---------------------------------------------------------------------------
^ permalink raw reply
* Re: Oops in trace_hardirqs_on (powerpc)
From: Steven Rostedt @ 2010-12-23 2:42 UTC (permalink / raw)
To: Jörg Sommer
Cc: Frederic Weisbecker, Ingo Molnar, linux-kernel, linuxppc-dev
In-Reply-To: <20101219132705.GE6615@alea.gnuu.de>
On Sun, 2010-12-19 at 14:27 +0100, Jörg Sommer wrote:
> Hi Steven,
>
> Did you've fixed this problem? The bug report is still marked as open.
> https://bugzilla.kernel.org/show_bug.cgi?id=16573
>
I just posted a patch to that BZ. I have it here below too. Could you
see if it fixes you problem. I only fixed the one place that you
reported, it may need more fixes (and in that case a macro to do the
work).
I hit the same bug on my ppc64 box, and have a fix for that, that I'll
post to LKML tomorrow.
-- Steve
diff --git a/arch/powerpc/kernel/entry_32.S b/arch/powerpc/kernel/entry_32.S
index ed4aeb9..915cc03 100644
--- a/arch/powerpc/kernel/entry_32.S
+++ b/arch/powerpc/kernel/entry_32.S
@@ -879,7 +879,18 @@ END_MMU_FTR_SECTION_IFSET(MMU_FTR_TYPE_47x)
*/
andi. r10,r9,MSR_EE
beq 1f
+ /*
+ * Since the ftrace irqsoff latency trace checks CALLER_ADDR1,
+ * which is the stack frame here, we need to force a stack frame
+ * in case we came from user space.
+ */
+ stwu r1,-32(r1)
+ mflr r0
+ stw r0,4(r1)
+ stwu r1,-32(r1)
bl trace_hardirqs_on
+ lwz r1,0(r1)
+ lwz r1,0(r1)
lwz r9,_MSR(r1)
1:
#endif /* CONFIG_TRACE_IRQFLAGS */
^ permalink raw reply related
* AUTO: Michael Barry is out of the office (returning 04/01/2011)
From: Michael Barry @ 2010-12-23 4:02 UTC (permalink / raw)
To: linuxppc-dev
I am out of the office until 04/01/2011.
Note: This is an automated response to your message "Linuxppc-dev Digest,
Vol 76, Issue 67" sent on 22/12/10 19:57:54.
This is the only notification you will receive while this person is away.
^ permalink raw reply
* [RFC] MPIC Bindings and Bindings for AMP Systems
From: Meador Inge @ 2010-12-23 5:58 UTC (permalink / raw)
To: devicetree-discuss; +Cc: Blanchard, Hollis, linuxppc-dev
Hi All,
I am currently doing some work on Linux PPC AMP systems (with Hollis,
CC'd). We are using device trees to partition resources between the
different OSes. To help with this effort, we would like to introduce
some new bindings to the MPIC.
Currently, there are no bindings for the MPIC under
'.../Documentation/powerpc/dts-bindings/'. I think most folks are
following the IEEE 1275 bindings for Open PIC.
It would be nice to check-in a binding for the MPIC that is a superset
of the 1275 bindings as a place to document extensions. The already in
use property 'protected-sources', for example, could be placed there.
I have included a draft proposal of what this would like. It includes
some properties ('no-reset') and a node (for message registers) that we
are currently using for our AMP implementation and we would really
like to push upstream. If the general idea seems sound, then I will
clean up the proposal and submit a patch for the bindings.
Thoughts?
============================
* MPIC Binding
This binding specifies what properties and child nodes must be available
on the device tree representation of the MPIC interrupt
controller. This binding is a superset of the binding defined for Open
PIC in [1].
** Required properties:
- All of the required properties mentioned in [1].
** Optional properties:
- no-reset : the presence of this property indicates that the
interrupt controller should not be reset during OS
initialization.
- protected-sources : a list of interrupt sources that are not
available for use.
** Example:
mpic: pic@40000 {
interrupt-controller;
#address-cells = <0>;
#interrupt-cells = <2>;
reg = <0x40000 0x40000>;
compatible = "chrp,open-pic";
device_type = "open-pic";
protected-sources = <0xb1 0xb2>;
no-reset;
};
* MPIC Message Registers
This binding specifies how the MPIC message registers implemented on
some Freescale platforms for interprocessor communication should be
represented.
** Required parent:
- Message register nodes should always been nested under a MPIC
node.
** Required properties:
- compatible : compatible list, contains 2 entries, first is
"fsl,CHIP-msgr", where CHIP is the processor
(p2020, mpc8572, etc ...) and the second is
"fsl,mpic-msgr".
- reg : should contain the address and the length of the
message register block.
- cell-index : the index of the message register block.
- interrupts : each one of the interrupts here represents the
interrupt line for one message register. These
interrupts are routed internally to the MPIC.
NOTE: The 'interrupt-parent' is implicit since message register nodes
are always children of interrupt controller nodes.
** Example:
mpic: pic@40000 {
interrupt-controller;
#address-cells = <0>;
#interrupt-cells = <2>;
reg = <0x40000 0x40000>;
compatible = "chrp,open-pic";
device_type = "open-pic";
protected-sources = <0xb1>;
msgr@1400 {
compatible = "fsl,p2020-msgr", "fsl,mpic-msgr";
reg = <0x1400 0x200>;
cell-index = <0>;
interrupts = <0xb0 0x2 0xb1 0x2
0xb2 0x2 0xb3 0x2>;
};
msgr@2400 {
compatible = "fsl,p2020-msgr", "fsl,mpic-msgr";
reg = <0x2400 0x200>;
cell-index = <1>;
interrupts = <0xb4 0x2 0xb5 0x2
0xb6 0x2 0xb7 0x2>;
};
};
* References
[1] PowerPC Microprocessor Common Hardware Reference Platform (CHRP)
Binding, Version 1.8, 1998. Published by the Open Firmware Working
Group. (http://playground.sun.com/1275/bindings/chrp/chrp1_8a.ps)
--
Meador Inge | meador_inge AT mentor.com
Mentor Embedded | http://www.mentor.com/embedded-software
^ permalink raw reply
* Re: [PATCH 1/4] of: Add support for linking device tree blobs into vmlinux
From: Geert Uytterhoeven @ 2010-12-23 6:14 UTC (permalink / raw)
To: Michal Marek
Cc: linux-arch, linux-kbuild, microblaze-uclinux, devicetree-discuss,
linux-kernel, dirk.brandewie, linuxppc-dev
In-Reply-To: <4D127D72.8050303@suse.cz>
2010/12/22 Michal Marek <mmarek@suse.cz>:
> On 22.12.2010 20:57, dirk.brandewie@gmail.com wrote:
>>
>> From: Dirk Brandewie<dirk.brandewie@gmail.com>
>>
>> This patch adds support for linking device tree blob(s) into
>> vmlinux. Modifies asm-generic/vmlinux.lds.h to add linking
>> .dtb sections into vmlinux. To maintain compatiblity with the of/fdt
>> driver code platforms MUST copy the blob to a non-init memory location
>> before the kernel frees the .init.* sections in the image.
>>
>> Modifies scripts/Makefile.lib to add a kbuild command to
>> compile DTS files to device tree blobs and a rule to create objects to
>> wrap the blobs for linking.
>>
>> STRUCT_ALIGNMENT is defined in vmlinux.lds.h for use in the rule to
>> create wrapper objects for the dtb in Makefile.lib. =C2=A0The
>> STRUCT_ALIGN() macro in vmlinux.lds.h is modified to use the
>> STRUCT_ALIGNMENT definition.
>>
>> The DTB's are placed on 32 byte boundries to allow parsing the blob
>> with driver/of/fdt.c during early boot without having to copy the blob
>> to get the structure alignment GCC expects.
>>
>> A DTB is linked in by adding the DTB object to the list of objects to
>> be linked into vmlinux in the archtecture specific Makefile using
>> =C2=A0 =C2=A0obj-y +=3D foo.dtb.o
>>
>> Signed-off-by: Dirk Brandewie<dirk.brandewie@gmail.com>
>
> Hi,
>
> you can add
> Acked-by: Michal Marek <mmarek@suse.cz>
> but I thing this series should go through the tip tree, as your primary
> target seems to be x86 and patch 2/4 depends on the ce4100 code that is o=
nly
> in tip.
If the two lines
+# device tree blob
+obj-$(CONFIG_X86_INTEL_CE) +=3D ce4100.dtb.o
are removed, patch 2/4 no longer depends on the ce4100 code.
The summary and description for that patch don't mention anything
about ce4100 anyway.
Gr{oetje,eeting}s,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k=
.org
In personal conversations with technical people, I call myself a hacker. Bu=
t
when I'm talking to journalists I just say "programmer" or something like t=
hat.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0=C2=A0 -- Linus Torvalds
^ permalink raw reply
* [RFC] MPIC Bindings and Bindings for AMP Systems
From: Meador Inge @ 2010-12-23 6:51 UTC (permalink / raw)
To: devicetree-discuss; +Cc: Blanchard, Hollis, linuxppc-dev
Hi All,
I am currently doing some work on Linux PPC AMP systems (with Hollis,
CC'd). We are using device trees to partition resources between the
different OSes. To help with this effort, we would like to introduce
some new bindings to the MPIC.
Currently, there are no bindings for the MPIC under
'.../Documentation/powerpc/dts-bindings/'. I think most folks are
following the IEEE 1275 bindings for Open PIC.
It would be nice to check-in a binding for the MPIC that is a superset
of the 1275 bindings as a place to document extensions. The already in
use property 'protected-sources', for example, could be placed there.
I have included a draft proposal of what this would like. It includes
some properties ('no-reset') and a node (for message registers) that we
are currently using for our AMP implementation and we would really
like to push upstream. If the general idea seems sound, then I will
clean up the proposal and submit a patch for the bindings.
Thoughts?
===============
* MPIC Binding
This binding specifies what properties and child nodes must be available
on the device tree representation of the MPIC interrupt
controller. This binding is a superset of the binding defined for Open
PIC in [1].
** Required properties:
- All of the required properties mentioned in [1].
** Optional properties:
- no-reset : the presence of this property indicates that the
interrupt controller should not be reset during OS
initialization.
- protected-sources : a list of interrupt sources that are not
available for use.
** Example:
mpic: pic@40000 {
interrupt-controller;
#address-cells = <0>;
#interrupt-cells = <2>;
reg = <0x40000 0x40000>;
compatible = "chrp,open-pic";
device_type = "open-pic";
protected-sources = <0xb1 0xb2>;
no-reset;
};
* MPIC Message Registers
This binding specifies how the MPIC message registers implemented on
some Freescale platforms for interprocessor communication should be
represented.
** Required parent:
- Message register nodes should always been nested under a MPIC
node.
** Required properties:
- compatible : compatible list, contains 2 entries, first is
"fsl,CHIP-msgr", where CHIP is the processor
(p2020, mpc8572, etc ...) and the second is
"fsl,mpic-msgr".
- reg : should contain the address and the length of the
message register block.
- cell-index : the index of the message register block.
- interrupts : each one of the interrupts here represents the
interrupt line for one message register. These
interrupts are routed internally to the MPIC.
NOTE: The 'interrupt-parent' is implicit since message register nodes
are always children of interrupt controller nodes.
** Example:
mpic: pic@40000 {
interrupt-controller;
#address-cells = <0>;
#interrupt-cells = <2>;
reg = <0x40000 0x40000>;
compatible = "chrp,open-pic";
device_type = "open-pic";
protected-sources = <0xb1>;
msgr@1400 {
compatible = "fsl,p2020-msgr", "fsl,mpic-msgr";
reg = <0x1400 0x200>;
cell-index = <0>;
interrupts = <0xb0 0x2 0xb1 0x2
0xb2 0x2 0xb3 0x2>;
};
msgr@2400 {
compatible = "fsl,p2020-msgr", "fsl,mpic-msgr";
reg = <0x2400 0x200>;
cell-index = <1>;
interrupts = <0xb4 0x2 0xb5 0x2
0xb6 0x2 0xb7 0x2>;
};
};
* References
[1] PowerPC Microprocessor Common Hardware Reference Platform (CHRP)
Binding, Version 1.8, 1998. Published by the Open Firmware Working
Group. (http://playground.sun.com/1275/bindings/chrp/chrp1_8a.ps)
--
Meador Inge | meador_inge AT mentor.com
Mentor Embedded | http://www.mentor.com/embedded-software
^ permalink raw reply
* Re: [Cbe-oss-dev] [RFC 0/3] powerpc: memory copy routines tweaked for Cell
From: syokazuliao @ 2010-12-23 7:49 UTC (permalink / raw)
To: Gunnar von Boehn
Cc: linuxppc-dev, Michael Ellerman, cbe-oss-dev, Arnd Bergmann
[-- Attachment #1.1: Type: text/plain, Size: 74 bytes --]
Sorry, I was send wrong files.
I send my three files again.
[-- Attachment #1.2: Type: text/html, Size: 312 bytes --]
[-- Attachment #2: main1.C --]
[-- Type: text/plain, Size: 1204 bytes --]
#include <stdlib.h>
#include <stdio.h>
#include <ppu_intrinsics.h>
extern void *memcpy(void *, const void *, size_t);
int main() {
unsigned char *s, *d;
register unsigned long long start, finish, i;
if(posix_memalign((void *)&s, 128, 16384)) {
printf("failed\n");
goto end;
}
for(i = 128, j = 0; i > 0; i--, j += 128) { /* clear s from cache */
__dcbf(s+j);
}
if(posix_memalign((void *)&d, 128, 16384)) {
printf("failed\n");
goto end;
}
for(i = 128, j = 0; i > 0; i--, j += 128) { /* clear d from cache */
__dcbf(s+j);
}
__dcbt(memcpy); /* prefetch memcpy */
__dcbt(memcpy+128);
__dcbt(memcpy+256);
__dcbt(memcpy+384);
__dcbt(memcpy+512);
__dcbt(memcpy+640);
__dcbt(memcpy+768);
__dcbt(memcpy+896);
__dcbt(memcpy+1024);
__dcbt(memcpy+1152);
__dcbt(memcpy+1280);
__dcbt(memcpy+1408);
__dcbt(memcpy+1536);
__dcbt(memcpy+1664);
__dcbt(memcpy+1792);
__dcbt(memcpy+1920);
__dcbt(memcpy+2048);
__dcbt(memcpy+2176);
__dcbt(memcpy+2304);
__dcbt(memcpy+2432);
__sync();
start = __mftb();
memcpy(d, s, 4096);
finish = __mftb();
printf("%lld\n", finish - start);
free(s);
free(d);
end:
return 0;
}
[-- Attachment #3: main2.C --]
[-- Type: text/plain, Size: 1200 bytes --]
#include <stdlib.h>
#include <stdio.h>
#include <ppu_intrinsics.h>
extern void *memcpy(void *, const void *, size_t);
int main() {
unsigned char *s, *d;
register unsigned long long start, finish, i;
if(posix_memalign((void *)&s, 128, 4096)) {
printf("failed\n");
goto end;
}
for(i = 32, j = 0; i > 0; i--, j += 128) { /* clear s from cache */
__dcbf(s+j);
}
if(posix_memalign((void *)&d, 128, 4096)) {
printf("failed\n");
goto end;
}
for(i = 32, j = 0; i > 0; i--, j += 128) { /* clear d from cache */
__dcbf(s+j);
}
__dcbt(cpymem); /* prefetch memcpy */
__dcbt(cpymem+128);
__dcbt(cpymem+256);
__dcbt(cpymem+384);
__dcbt(cpymem+512);
__dcbt(cpymem+640);
__dcbt(cpymem+768);
__dcbt(cpymem+896);
__dcbt(cpymem+1024);
__dcbt(cpymem+1152);
__dcbt(cpymem+1280);
__dcbt(cpymem+1408);
__dcbt(cpymem+1536);
__dcbt(cpymem+1664);
__dcbt(cpymem+1792);
__dcbt(cpymem+1920);
__dcbt(cpymem+2048);
__dcbt(cpymem+2176);
__dcbt(cpymem+2304);
__dcbt(cpymem+2432);
__sync();
start = __mftb();
memcpy(d, s, 4096);
finish = __mftb();
printf("%lld\n", finish - start);
free(s);
free(d);
end:
return 0;
}
[-- Attachment #4: test_result.TXT --]
[-- Type: text/plain, Size: 449 bytes --]
Copy Memory-to-Memory, results are in ticks.
16KB 4KB 2KB 1KB 512B 256B 128B 64B 32B 16B
-----------------------------------------------------------------------------------------------------------------------------------
main1.C 2063~2466 669~879 60~63 33~36 22~24 19~21 17~21 17~19 15~17 15~16
main2.C 110~114 60~62 33~36 21~24 19~21 17~18 17~18 15~16 15~16
^ permalink raw reply
* Re: [Cbe-oss-dev] [RFC 0/3] powerpc: memory copy routines tweaked for Cell
From: syokazuliao @ 2010-12-23 7:38 UTC (permalink / raw)
To: Gunnar von Boehn
Cc: linuxppc-dev, Michael Ellerman, cbe-oss-dev, Arnd Bergmann
[-- Attachment #1.1: Type: text/plain, Size: 727 bytes --]
Hi everyone,
I'm a new Cell BE user, and my debug platform is YDL6.2 run on PS3.
I wrote two simple test programs that tests Mark Nelson's memcpy routines under
a number of conditions, and the test arrays are aligned on 128-byte boundaries.
Following explains my three files.
1. The main1.C is my first test program, it assigns two 16KB arrays.
2. The main2.C is my second test program, it assigns two 4KB arrays.
3. The test_result.TXT is my test result.
Therefore, I have three questions.
1. How to calculate the bandwidth (MB/s)?
2. Is my result or test way correct?
3. Why is the 4KB result different between main1.C and main2.C?
PS: Please use UltraEdit open my three flies.
[-- Attachment #1.2: Type: text/html, Size: 1565 bytes --]
[-- Attachment #2: main2.C --]
[-- Type: text/plain, Size: 1200 bytes --]
#include <stdlib.h>
#include <stdio.h>
#include <ppu_intrinsics.h>
extern void *memcpy(void *, const void *, size_t);
int main() {
unsigned char *s, *d;
register unsigned long long start, finish, i;
if(posix_memalign((void *)&s, 128, 4096)) {
printf("failed\n");
goto end;
}
for(i = 32, j = 0; i > 0; i--, j += 128) { /* clear s from cache */
__dcbf(s+j);
}
if(posix_memalign((void *)&d, 128, 4096)) {
printf("failed\n");
goto end;
}
for(i = 32, j = 0; i > 0; i--, j += 128) { /* clear d from cache */
__dcbf(s+j);
}
__dcbt(cpymem); /* prefetch memcpy */
__dcbt(cpymem+128);
__dcbt(cpymem+256);
__dcbt(cpymem+384);
__dcbt(cpymem+512);
__dcbt(cpymem+640);
__dcbt(cpymem+768);
__dcbt(cpymem+896);
__dcbt(cpymem+1024);
__dcbt(cpymem+1152);
__dcbt(cpymem+1280);
__dcbt(cpymem+1408);
__dcbt(cpymem+1536);
__dcbt(cpymem+1664);
__dcbt(cpymem+1792);
__dcbt(cpymem+1920);
__dcbt(cpymem+2048);
__dcbt(cpymem+2176);
__dcbt(cpymem+2304);
__dcbt(cpymem+2432);
__sync();
start = __mftb();
memcpy(d, s, 4096);
finish = __mftb();
printf("%lld\n", finish - start);
free(s);
free(d);
end:
return 0;
}
[-- Attachment #3: test_result.TXT --]
[-- Type: text/plain, Size: 442 bytes --]
Copy Memory-to-Memory, results are in ticks.
16KB 4KB 2KB 1KB 512B 256B 128B 64B 32B 16B
-----------------------------------------------------------------------------------------------------------------------------------
main1.C 2063~2466 669~879 60~63 33~36 22~24 19~21 17~21 17~19 15~17 15~16
main2.C 110~114 60~62 33~36 21~24 19~21 17~18 17~18 15~16 15~16
[-- Attachment #4: test_result.TXT --]
[-- Type: text/plain, Size: 442 bytes --]
Copy Memory-to-Memory, results are in ticks.
16KB 4KB 2KB 1KB 512B 256B 128B 64B 32B 16B
-----------------------------------------------------------------------------------------------------------------------------------
main1.C 2063~2466 669~879 60~63 33~36 22~24 19~21 17~21 17~19 15~17 15~16
main2.C 110~114 60~62 33~36 21~24 19~21 17~18 17~18 15~16 15~16
^ permalink raw reply
* Re: [RFC] MPIC Bindings and Bindings for AMP Systems
From: Grant Likely @ 2010-12-23 18:56 UTC (permalink / raw)
To: Meador Inge; +Cc: linuxppc-dev, devicetree-discuss, Blanchard, Hollis
In-Reply-To: <4D12F171.7010103@mentor.com>
On Thu, Dec 23, 2010 at 12:51:29AM -0600, Meador Inge wrote:
> Hi All,
>
> I am currently doing some work on Linux PPC AMP systems (with Hollis,
> CC'd). We are using device trees to partition resources between the
> different OSes. To help with this effort, we would like to introduce
> some new bindings to the MPIC.
>
> Currently, there are no bindings for the MPIC under
> '.../Documentation/powerpc/dts-bindings/'. I think most folks are
> following the IEEE 1275 bindings for Open PIC.
>
> It would be nice to check-in a binding for the MPIC that is a superset
> of the 1275 bindings as a place to document extensions. The already in
> use property 'protected-sources', for example, could be placed there.
>
> I have included a draft proposal of what this would like. It includes
> some properties ('no-reset') and a node (for message registers) that we
> are currently using for our AMP implementation and we would really
> like to push upstream. If the general idea seems sound, then I will
> clean up the proposal and submit a patch for the bindings.
>
> Thoughts?
Hi Meador. Comments below.
g.
>
> ===============
>
> * MPIC Binding
>
> This binding specifies what properties and child nodes must be
> available on the device tree representation of the MPIC interrupt
> controller. This binding is a superset of the binding defined for
> Open PIC in [1].
>
> ** Required properties:
>
> - All of the required properties mentioned in [1].
You should probably list them here anyway to aid the reader.
>
> ** Optional properties:
>
> - no-reset : the presence of this property indicates that the
> interrupt controller should not be reset during OS
> initialization.
> - protected-sources : a list of interrupt sources that are not
> available for use.
What is the use case for the protected-sources property? Wouldn't the
irqs simply not be referenced by any device nodes? Documenting the
reason for this property would be useful here.
>
> ** Example:
>
> mpic: pic@40000 {
> interrupt-controller;
> #address-cells = <0>;
> #interrupt-cells = <2>;
> reg = <0x40000 0x40000>;
> compatible = "chrp,open-pic";
> device_type = "open-pic";
> protected-sources = <0xb1 0xb2>;
> no-reset;
> };
>
> * MPIC Message Registers
>
> This binding specifies how the MPIC message registers implemented on
> some Freescale platforms for interprocessor communication should be
> represented.
>
> ** Required parent:
>
> - Message register nodes should always been nested under a MPIC
> node.
>
> ** Required properties:
>
> - compatible : compatible list, contains 2 entries, first is
> "fsl,CHIP-msgr", where CHIP is the processor
> (p2020, mpc8572, etc ...) and the second is
> "fsl,mpic-msgr".
I'd rather see the 'generic' value of mpic-msgr omitted and instead
allow new parts to claim compatibility with an older chip. Generic
or wildcard compatible values can be troublesome because the meaning
has a tendency to change over time.
> - reg : should contain the address and the length of the
> message register block.
> - cell-index : the index of the message register block.
? This needs some more explanation. cell-index often gets abused as
a way to enumerate devices. Typically, the address of the device
itself is sufficient to identify the device.
> - interrupts : each one of the interrupts here represents the
> interrupt line for one message register. These
> interrupts are routed internally to the MPIC.
>
> NOTE: The 'interrupt-parent' is implicit since message register nodes
> are always children of interrupt controller nodes.
>
> ** Example:
>
> mpic: pic@40000 {
> interrupt-controller;
> #address-cells = <0>;
> #interrupt-cells = <2>;
> reg = <0x40000 0x40000>;
> compatible = "chrp,open-pic";
> device_type = "open-pic";
> protected-sources = <0xb1>;
>
> msgr@1400 {
> compatible = "fsl,p2020-msgr", "fsl,mpic-msgr";
> reg = <0x1400 0x200>;
Are these registers memory mapped? If so, then the parent node
needs to have a 'ranges' property.
> cell-index = <0>;
> interrupts = <0xb0 0x2 0xb1 0x2
> 0xb2 0x2 0xb3 0x2>;
> };
>
> msgr@2400 {
> compatible = "fsl,p2020-msgr", "fsl,mpic-msgr";
> reg = <0x2400 0x200>;
> cell-index = <1>;
> interrupts = <0xb4 0x2 0xb5 0x2
> 0xb6 0x2 0xb7 0x2>;
> };
> };
>
> * References
>
> [1] PowerPC Microprocessor Common Hardware Reference Platform (CHRP)
> Binding, Version 1.8, 1998. Published by the Open Firmware Working
> Group. (http://playground.sun.com/1275/bindings/chrp/chrp1_8a.ps)
>
>
> --
> Meador Inge | meador_inge AT mentor.com
> Mentor Embedded | http://www.mentor.com/embedded-software
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
^ permalink raw reply
* Re: [PATCH RESEND 2] mpc52xx: gpt: include fs.h
From: Grant Likely @ 2010-12-23 19:08 UTC (permalink / raw)
To: Wolfram Sang; +Cc: linuxppc-dev, Andrew Morton
In-Reply-To: <1293032575-16241-1-git-send-email-w.sang@pengutronix.de>
On Wed, Dec 22, 2010 at 04:42:55PM +0100, Wolfram Sang wrote:
> Fix build errors like these (from a randconfig and my defconfig for a custom board):
>
> src/arch/powerpc/platforms/52xx/mpc52xx_gpt.c:549: error: dereferencing pointer to incomplete type: 1 errors in 1 logs
> src/arch/powerpc/platforms/52xx/mpc52xx_gpt.c:636: error: implicit declaration of function 'nonseekable_open': 1 errors in 1 logs
> src/arch/powerpc/platforms/52xx/mpc52xx_gpt.c:657: error: variable 'mpc52xx_wdt_fops' has initializer but incomplete type: 1 errors in 1 logs
> src/arch/powerpc/platforms/52xx/mpc52xx_gpt.c:658: error: excess elements in struct initializer: 1 errors in 1 logs
> src/arch/powerpc/platforms/52xx/mpc52xx_gpt.c:658: error: unknown field 'owner' specified in initializer: 1 errors in 1 logs
> ...
>
> Reported-by: Geert Uytterhoeven <geert@linux-m68k.org>
> Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
> Cc: Grant Likely <grant.likely@secretlab.ca>
> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Cc: Andrew Morton <akpm@linux-foundation.org>
Applied, thanks.
Sorry for the delay. I got severely snowed under this fall and have
only come up for air now.
g.
> ---
>
> rc7 is out and we still have this build-failure. Please apply.
>
> arch/powerpc/platforms/52xx/mpc52xx_gpt.c | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/arch/powerpc/platforms/52xx/mpc52xx_gpt.c b/arch/powerpc/platforms/52xx/mpc52xx_gpt.c
> index fea833e..e0d703c 100644
> --- a/arch/powerpc/platforms/52xx/mpc52xx_gpt.c
> +++ b/arch/powerpc/platforms/52xx/mpc52xx_gpt.c
> @@ -63,6 +63,7 @@
> #include <linux/of_gpio.h>
> #include <linux/kernel.h>
> #include <linux/slab.h>
> +#include <linux/fs.h>
> #include <linux/watchdog.h>
> #include <linux/miscdevice.h>
> #include <linux/uaccess.h>
> --
> 1.7.2.3
>
^ permalink raw reply
* Re: [PATCH 1/4] of: Add support for linking device tree blobs into vmlinux
From: Grant Likely @ 2010-12-23 21:42 UTC (permalink / raw)
To: dirk.brandewie
Cc: linux-arch, mmarek, linux-kbuild, microblaze-uclinux,
devicetree-discuss, linux-kernel, linuxppc-dev
In-Reply-To: <1293047849-26078-2-git-send-email-dirk.brandewie@gmail.com>
On Wed, Dec 22, 2010 at 11:57:26AM -0800, dirk.brandewie@gmail.com wrote:
> From: Dirk Brandewie <dirk.brandewie@gmail.com>
>
> This patch adds support for linking device tree blob(s) into
> vmlinux. Modifies asm-generic/vmlinux.lds.h to add linking
> .dtb sections into vmlinux. To maintain compatiblity with the of/fdt
> driver code platforms MUST copy the blob to a non-init memory location
> before the kernel frees the .init.* sections in the image.
>
> Modifies scripts/Makefile.lib to add a kbuild command to
> compile DTS files to device tree blobs and a rule to create objects to
> wrap the blobs for linking.
>
> STRUCT_ALIGNMENT is defined in vmlinux.lds.h for use in the rule to
> create wrapper objects for the dtb in Makefile.lib. The
> STRUCT_ALIGN() macro in vmlinux.lds.h is modified to use the
> STRUCT_ALIGNMENT definition.
>
> The DTB's are placed on 32 byte boundries to allow parsing the blob
> with driver/of/fdt.c during early boot without having to copy the blob
> to get the structure alignment GCC expects.
>
> A DTB is linked in by adding the DTB object to the list of objects to
> be linked into vmlinux in the archtecture specific Makefile using
> obj-y += foo.dtb.o
>
> Signed-off-by: Dirk Brandewie <dirk.brandewie@gmail.com>
merged, thanks.
g.
> ---
> Documentation/kbuild/makefiles.txt | 15 +++++++++++++++
> include/asm-generic/vmlinux.lds.h | 13 +++++++++++--
> scripts/Makefile.lib | 23 +++++++++++++++++++++++
> 3 files changed, 49 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/kbuild/makefiles.txt b/Documentation/kbuild/makefiles.txt
> index 0ef00bd..86e3cd0 100644
> --- a/Documentation/kbuild/makefiles.txt
> +++ b/Documentation/kbuild/makefiles.txt
> @@ -1136,6 +1136,21 @@ When kbuild executes, the following steps are followed (roughly):
> resulting in the target file being recompiled for no
> obvious reason.
>
> + dtc
> + Create flattend device tree blob object suitable for linking
> + into vmlinux. Device tree blobs linked into vmlinux are placed
> + in an init section in the image. Platform code *must* copy the
> + blob to non-init memory prior to calling unflatten_device_tree().
> +
> + Example:
> + #arch/x86/platform/ce4100/Makefile
> + clean-files := *dtb.S
> +
> + DTC_FLAGS := -p 1024
> + obj-y += foo.dtb.o
> +
> + $(obj)/%.dtb: $(src)/%.dts
> + $(call cmd,dtc)
>
> --- 6.7 Custom kbuild commands
>
> diff --git a/include/asm-generic/vmlinux.lds.h b/include/asm-generic/vmlinux.lds.h
> index bd69d79..05cbad0 100644
> --- a/include/asm-generic/vmlinux.lds.h
> +++ b/include/asm-generic/vmlinux.lds.h
> @@ -67,7 +67,8 @@
> * Align to a 32 byte boundary equal to the
> * alignment gcc 4.5 uses for a struct
> */
> -#define STRUCT_ALIGN() . = ALIGN(32)
> +#define STRUCT_ALIGNMENT 32
> +#define STRUCT_ALIGN() . = ALIGN(STRUCT_ALIGNMENT)
>
> /* The actual configuration determine if the init/exit sections
> * are handled as text/data or they can be discarded (which
> @@ -146,6 +147,13 @@
> #define TRACE_SYSCALLS()
> #endif
>
> +
> +#define KERNEL_DTB() \
> + STRUCT_ALIGN(); \
> + VMLINUX_SYMBOL(__dtb_start) = .; \
> + *(.dtb.init.rodata) \
> + VMLINUX_SYMBOL(__dtb_end) = .;
> +
> /* .data section */
> #define DATA_DATA \
> *(.data) \
> @@ -468,7 +476,8 @@
> MCOUNT_REC() \
> DEV_DISCARD(init.rodata) \
> CPU_DISCARD(init.rodata) \
> - MEM_DISCARD(init.rodata)
> + MEM_DISCARD(init.rodata) \
> + KERNEL_DTB()
>
> #define INIT_TEXT \
> *(.init.text) \
> diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib
> index 4c72c11..7df8eb5 100644
> --- a/scripts/Makefile.lib
> +++ b/scripts/Makefile.lib
> @@ -200,6 +200,29 @@ quiet_cmd_gzip = GZIP $@
> cmd_gzip = (cat $(filter-out FORCE,$^) | gzip -f -9 > $@) || \
> (rm -f $@ ; false)
>
> +# DTC
> +# ---------------------------------------------------------------------------
> +
> +# Generate an assembly file to wrap the output of the device tree compiler
> +quiet_cmd_dt_S_dtb= DTB $@
> +cmd_dt_S_dtb= \
> +( \
> + echo '\#include <asm-generic/vmlinux.lds.h>'; \
> + echo '.section .dtb.init.rodata,"a"'; \
> + echo '.balign STRUCT_ALIGNMENT'; \
> + echo '.global __dtb_$(*F)_begin'; \
> + echo '__dtb_$(*F)_begin:'; \
> + echo '.incbin "$<" '; \
> + echo '__dtb_$(*F)_end:'; \
> + echo '.global __dtb_$(*F)_end'; \
> + echo '.balign STRUCT_ALIGNMENT'; \
> +) > $@
> +
> +$(obj)/%.dtb.S: $(obj)/%.dtb
> + $(call cmd,dt_S_dtb)
> +
> +quiet_cmd_dtc = DTC $@
> + cmd_dtc = $(objtree)/scripts/dtc/dtc -O dtb -o $@ -b 0 $(DTC_FLAGS) $<
>
> # Bzip2
> # ---------------------------------------------------------------------------
> --
> 1.7.2.3
>
> _______________________________________________
> devicetree-discuss mailing list
> devicetree-discuss@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/devicetree-discuss
^ permalink raw reply
* Re: [PATCH 1/4] of: Add support for linking device tree blobs into vmlinux
From: Grant Likely @ 2010-12-23 21:44 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Michal Marek, linux-arch, linux-kbuild, microblaze-uclinux,
devicetree-discuss, linux-kernel, dirk.brandewie, linuxppc-dev
In-Reply-To: <AANLkTik-yqs2Dy+MBAcQ5Gpb9Vcvd80BS=C=fuDe7z-A@mail.gmail.com>
On Thu, Dec 23, 2010 at 07:14:20AM +0100, Geert Uytterhoeven wrote:
> 2010/12/22 Michal Marek <mmarek@suse.cz>:
> > On 22.12.2010 20:57, dirk.brandewie@gmail.com wrote:
> >>
> >> From: Dirk Brandewie<dirk.brandewie@gmail.com>
> >>
> >> This patch adds support for linking device tree blob(s) into
> >> vmlinux. Modifies asm-generic/vmlinux.lds.h to add linking
> >> .dtb sections into vmlinux. To maintain compatiblity with the of/fdt
> >> driver code platforms MUST copy the blob to a non-init memory location
> >> before the kernel frees the .init.* sections in the image.
> >>
> >> Modifies scripts/Makefile.lib to add a kbuild command to
> >> compile DTS files to device tree blobs and a rule to create objects to
> >> wrap the blobs for linking.
> >>
> >> STRUCT_ALIGNMENT is defined in vmlinux.lds.h for use in the rule to
> >> create wrapper objects for the dtb in Makefile.lib. The
> >> STRUCT_ALIGN() macro in vmlinux.lds.h is modified to use the
> >> STRUCT_ALIGNMENT definition.
> >>
> >> The DTB's are placed on 32 byte boundries to allow parsing the blob
> >> with driver/of/fdt.c during early boot without having to copy the blob
> >> to get the structure alignment GCC expects.
> >>
> >> A DTB is linked in by adding the DTB object to the list of objects to
> >> be linked into vmlinux in the archtecture specific Makefile using
> >> obj-y += foo.dtb.o
> >>
> >> Signed-off-by: Dirk Brandewie<dirk.brandewie@gmail.com>
> >
> > Hi,
> >
> > you can add
> > Acked-by: Michal Marek <mmarek@suse.cz>
> > but I thing this series should go through the tip tree, as your primary
> > target seems to be x86 and patch 2/4 depends on the ce4100 code that is only
> > in tip.
>
> If the two lines
>
> +# device tree blob
> +obj-$(CONFIG_X86_INTEL_CE) += ce4100.dtb.o
>
> are removed, patch 2/4 no longer depends on the ce4100 code.
> The summary and description for that patch don't mention anything
> about ce4100 anyway.
I'd like to take this through the dt tree. I'll drop the ce4100 hunk
when I merge it.
g.
>
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
> -- Linus Torvalds
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
^ permalink raw reply
* Re: [RFC] MPIC Bindings and Bindings for AMP Systems
From: Meador Inge @ 2010-12-23 21:49 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, devicetree-discuss, Blanchard, Hollis
In-Reply-To: <20101223185623.GA20384@angua.secretlab.ca>
On 12/23/2010 12:56 PM, Grant Likely wrote:
> Hi Meador. Comments below.
>
> g.
Thanks a lot for the feedback Grant.
> You should probably list them here anyway to aid the reader.
Will do.
> What is the use case for the protected-sources property? Wouldn't the
> irqs simply not be referenced by any device nodes? Documenting the
> reason for this property would be useful here.
One use case is the original [1]:
Some HW platforms, such as the new cell blades, requires some
MPIC sources to be left alone by the operating system. This
implements support for a "protected-sources" property in the
mpic controller node containing a list of source numbers to be
protected against operating system interference.
Our use case is to reserve certain IRQs for certain OSes in an AMP
system. As an example, consider that OS 1 has (simplified for discussion):
mpic: pic@40000 {
...
protected-sources = <0xb1>;
msgr@41400 {
interrupts = <0xb0 2 0xb1 2 0xb2 2 0xb3 2>;
};
};
and OS 2 has:
mpic: pic@40000 {
...
protected-sources = <0xb0>;
msgr@41400 {
interrupts = <0xb0 2 0xb1 2 0xb2 2 0xb3 2>;
};
};
where OS 1 is sent messages through the message register tied to 0xb0
and OS 2 is sent messages through the message register tied to 0xb1.
We can't just remove the IRQ of the _other_ OS from the 'interrupts'
property in the message node because we need to know the IRQ in order to
talk to the other OS. So, we use protected sources to tell the OS that
an IRQ is not available for its own use, while at the same time keeping
complete information on all the IRQ mappings for the message registers.
I will update the documentation.
> I'd rather see the 'generic' value of mpic-msgr omitted and instead
> allow new parts to claim compatibility with an older chip. Generic
> or wildcard compatible values can be troublesome because the meaning
> has a tendency to change over time.
I don't completely see the issue here. Do you have a specific example
of how generic values like this cause problems? How do you see this
working in terms of processing the data? It seems like we are going to
have to be aware of N values instead of 1, which seems worse.
> ? This needs some more explanation. cell-index often gets abused as
> a way to enumerate devices. Typically, the address of the device
> itself is sufficient to identify the device.
The message registers typically come in blocks of four memory mapped
registers and may not be in contiguous memory (example [3]). The intent
of 'cell-index' is to put an ordering on the blocks (so, yes,
enumeration). We could order them by address as well I suppose. One
less property to worry about :)
> Are these registers memory mapped? If so, then the parent node
> needs to have a 'ranges' property.
Yes, they are. I will look into adding that.
[1] commit 7fd7218610600b16f6f0af3f9d9353ba0265c09f,
http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.36.y.git;a=commit;h=7fd7218610600b16f6f0af3f9d9353ba0265c09f
[2] Documentation/powerpc/dts-bindings/fsl/msi-pic.txt
[3]
http://cache.freescale.com/files/32bit/doc/ref_manual/MPC8572ERM.pdf?fr=g
--
Meador Inge | meador_inge AT mentor.com
Mentor Embedded | http://www.mentor.com/embedded-software
^ permalink raw reply
* Re: [PATCH 2/4] x86/of: Add building device tree blob(s) into image.
From: Grant Likely @ 2010-12-23 21:58 UTC (permalink / raw)
To: dirk.brandewie
Cc: linux-arch, mmarek, linux-kbuild, microblaze-uclinux,
devicetree-discuss, linux-kernel, linuxppc-dev
In-Reply-To: <1293047849-26078-3-git-send-email-dirk.brandewie@gmail.com>
On Wed, Dec 22, 2010 at 11:57:27AM -0800, dirk.brandewie@gmail.com wrote:
> From: Dirk Brandewie <dirk.brandewie@gmail.com>
>
> This patch adds linking device tree blob into vmlinux. DTB's are
> added by adding the blob object name to list of objects to be linked
> into the image.
>
> Signed-off-by: Dirk Brandewie <dirk.brandewie@gmail.com>
> ---
> arch/x86/platform/ce4100/Makefile | 10 ++++++++++
> 1 files changed, 10 insertions(+), 0 deletions(-)
>
> diff --git a/arch/x86/platform/ce4100/Makefile b/arch/x86/platform/ce4100/Makefile
> index 91fc929..e5f3b7b 100644
> --- a/arch/x86/platform/ce4100/Makefile
> +++ b/arch/x86/platform/ce4100/Makefile
> @@ -1 +1,11 @@
> obj-$(CONFIG_X86_INTEL_CE) += ce4100.o
> +clean-files := *dtb.S
> +
> +ifdef CONFIG_X86_OF
> +###
> +# device tree blob
> +obj-$(CONFIG_X86_INTEL_CE) += ce4100.dtb.o
> +
> +$(obj)/%.dtb: $(src)/%.dts
> + $(call cmd,dtc)
> +endif
Skipped for now; will pick up after ce4100 is in mainline since this
is a pretty low-risk change.
g.
> --
> 1.7.2.3
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox