[2.6 patch] powerpc: proper defconfig for crosscompiles
The trick for finding the right defconfig is neat, but you forgot to provide an i686_defconfig. ;-) More seriously, cross compiling the defconfig is often useful, e.g. for testing the compilation of patches that touch multiple architectures, and this patch therefore chooses g5_defconfig if $(CROSS_COMPILE) is non-empty. Signed-off-by: Adrian Bunk [EMAIL PROTECTED] --- 0b0e6e0e3a16f48348cb9c40ef1bb55ef42f92eb diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile index 2065138..a39bac4 100644 --- a/arch/powerpc/Makefile +++ b/arch/powerpc/Makefile @@ -35,7 +35,11 @@ endif export CROSS32CC CROSS32AS CROSS32LD CROSS32AR CROSS32OBJCOPY +ifeq ($(CROSS_COMPILE),) KBUILD_DEFCONFIG := $(shell uname -m)_defconfig +else +KBUILD_DEFCONFIG := g5_defconfig +endif ifeq ($(CONFIG_PPC64),y) OLDARCH:= ppc64 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [2.6 patch] powerpc: proper defconfig for crosscompiles
On Sun, Sep 09, 2007 at 08:21:17PM +0200, Adrian Bunk wrote: The trick for finding the right defconfig is neat, but you forgot to provide an i686_defconfig. ;-) More seriously, cross compiling the defconfig is often useful, e.g. for testing the compilation of patches that touch multiple architectures, and this patch therefore chooses g5_defconfig if $(CROSS_COMPILE) is non-empty. You should probably use ppc64_defconfig instead, since it's the superset config that will compile a multiplatform kernel. -Olof ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC/PATCH 1/2] Basic generic time/clocksource code for PowerPC
Gabriel Paubert writes: The solution now used by i386/x86-64/sparc64 is CONFIG_GENERIC_CMOS_UPDATE. Maybe powerpc should be switched to use something similar, but the generic code has some Yes. I'll turn on CONFIG_GENERIC_CMOS_UPDATE. Do you think it needs to be a config option that can be turned on and off in the kernel config, or should it just be always on as on x86[-64]? problems (it assumes that you have to set the clock on a half-second, which is not the case of the RTC on my boards to start with). Let's get the generic code fixed to do what we need then. Care to send a patch? Paul. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 5/5] Add DMA engine driver for Freescale MPC85xx processors.
Dan Williams wrote:
This routine implies that there is a piece of code somewhere that
wants to select which channels it can use. A similar effect can be
achieved by registering a dma_client with the dmaengine interface
('dma_async_client_register'). Then when the client code makes a call
to 'dma_async_client_chan_request' it receives a 'dma_event_callback'
for each channel in the system. It will also be asynchronously
notified of channels entering and leaving the system. The goal is to
share a common infrastructure for channel management.
Are you familiar with the flat device tree used for PowerPC systems? The
piece of code somewhere is the device tree subsystem that parses the device
tree, which is compiled from the .dts files in arch/powerpc/boot/dts.
The FDT is how PowerPC systems specify hardware configuration. In the case of
85xx, the FDT contains entries for each DMA device (typically 2), and the
entries contain sub-entries for each DMA channel as well as the address of the
register sets for each channel.
--
Timur Tabi
Linux Kernel Developer @ Freescale
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 5/5] Add DMA engine driver for Freescale MPC85xx processors.
On 9/9/07, Timur Tabi [EMAIL PROTECTED] wrote:
Dan Williams wrote:
This routine implies that there is a piece of code somewhere that
wants to select which channels it can use. A similar effect can be
achieved by registering a dma_client with the dmaengine interface
('dma_async_client_register'). Then when the client code makes a call
to 'dma_async_client_chan_request' it receives a 'dma_event_callback'
for each channel in the system. It will also be asynchronously
notified of channels entering and leaving the system. The goal is to
share a common infrastructure for channel management.
Are you familiar with the flat device tree used for PowerPC systems? The
piece of code somewhere is the device tree subsystem that parses the device
tree, which is compiled from the .dts files in arch/powerpc/boot/dts.
The FDT is how PowerPC systems specify hardware configuration. In the case of
85xx, the FDT contains entries for each DMA device (typically 2), and the
entries contain sub-entries for each DMA channel as well as the address of the
register sets for each channel.
Ahh, ok then this code is replacing what would normally be handled by
the PCI bus enumeration code, or the platform device registrations for
iop-adma in arch/arm/mach-iop13xx. Sorry for the noise with this
comment.
--
Timur Tabi
Linux Kernel Developer @ Freescale
-
Thanks,
Dan
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Document and implement an improved flash device binding for powerpc (v5)
On Fri, Sep 07, 2007 at 04:25:10PM +0200, Segher Boessenkool wrote: This patch replaces the binding for flash chips in booting-without-of.txt with an clarified and improved version. It also makes drivers/mtd/maps/physmap_of.c recognize this new binding. Finally it revises the Ebony device tree source to use the new binding as an example. Signed-off-by: David Gibson [EMAIL PROTECTED] Acked-by: Segher Boessenkool [EMAIL PROTECTED] Thanks for doing this work David! + /* First look for RedBoot table or partitions on the command +* line, these take precedence over device tree information */ Any specific reason you chose this order? Just curious... Well, RedBoot on the grounds that an on-device partition table, if present, should take precedence over platform defaults. And that overriding partition information on the command line should, well, override... + .data = (void *)jedec_probe, Hrm, this cast is only getting rid of the const-ness of the string literal -- maybe .data should be declared const, or does the majority of users want it writable? Not sure. But this is defined in the core anyway, and I didn't really want to bother with delving into that at this time. -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/5] Add Freescale DMA and DMA channel to Documentation/powerpc/booting-without-of.txt file.
On Fri, Sep 07, 2007 at 04:43:35PM +0200, Segher Boessenkool wrote: + l) Freescale DMA +- compatible : Should be fsl,dma. Please choose some more specific name. fsl,mpc8540-dma would be a reasonable choice perhaps. More precisely, the compatible property should always have an specific entry based on the exact chip the DMA engine resides in, as well as a more general entry for any fsl dma engine of this type. -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/5] Add Freescale DMA engine driver maintainer.
On Fri, Sep 07, 2007 at 06:53:53PM +0800, Zhang Wei wrote: This patch adds Freescale DMA engine driver maintainer. This is meaningless without the actual driver, so it shouldn't be a separate patch. Fold it into the patch that actually adds the driver support. -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 08/10] bootwrapper: Add a firmware-independent raw target.
On Fri Sep 7 10:58:03 EST 2007, David Gibson wrote:
On Wed, Sep 05, 2007 at 02:21:16PM -0500, Scott Wood wrote:
This target produces a flat binary rather than an ELF file,
fixes the entry point at the beginning of the image, and takes
a complete device tree with no fixups needed.
The device tree must have labels on /#address-cells, the timebase
frequency, and the memory size.
Hrm... the actual contents of this patch are less about producing an
unheadered binary image than they are about introducing the raw
platform. I don't mind the idea of a raw platform (although I'm not
sure I like that name for it), but the patch comment needs work.
Plus, its not quite as generic as you think.
Signed-off-by: Scott Wood scottwood at freescale.com
---
arch/powerpc/Kconfig | 12 +++
arch/powerpc/boot/Makefile |4 ++-
arch/powerpc/boot/fixed-head.S |4 +++
arch/powerpc/boot/io.h |7 ++
arch/powerpc/boot/raw-platform.c | 41
++
arch/powerpc/boot/wrapper| 21 ++
6 files changed, 83 insertions(+), 6 deletions(-)
create mode 100644 arch/powerpc/boot/fixed-head.S
create mode 100644 arch/powerpc/boot/raw-platform.c
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 00099ef..251d0c3 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -358,6 +358,18 @@ config WANT_DEVICE_TREE
bool
default n
+config BUILD_RAW_IMAGE
+ bool Build firmware-independent image
+ select WANT_DEVICE_TREE
+ help
+ If this is enabled, a firmware independent raw image will
be
+ built, as zImage.raw. This requires a completely filled-in
+ device tree, with the following labels:
+
+ mem_size_cells: on /#address-cells
+ memsize: on the size portion of /memory/reg
+ timebase: on the boot CPU's timebase property
You need these labels on (in) the data not on the property struct ...
(one can label either today, but only properties in the not to distant
past).
+
config DEVICE_TREE
string Static device tree source file
depends on WANT_DEVICE_TREE
diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile
index 02f0fe0..2a6a4c6 100644
--- a/arch/powerpc/boot/Makefile
+++ b/arch/powerpc/boot/Makefile
@@ -48,7 +48,8 @@ src-wlib := string.S crt0.S stdio.c main.c
flatdevtree.c flatdevtree_misc.c \
cpm-serial.c stdlib.c planetcore.c
src-plat := of.c cuboot-83xx.c cuboot-85xx.c holly.c \
cuboot-ebony.c treeboot-ebony.c prpmc2800.c \
- ps3-head.S ps3-hvcall.S ps3.c treeboot-bamboo.c
cuboot-8xx.c cuboot-pq2.c
+ ps3-head.S ps3-hvcall.S ps3.c treeboot-bamboo.c \
+ cuboot-8xx.c cuboot-pq2.c fixed-head.S raw-platform.c
src-boot := $(src-wlib) $(src-plat) empty.c
src-boot := $(addprefix $(obj)/, $(src-boot))
@@ -146,6 +147,7 @@ image-$(CONFIG_PPC_83xx)+=
cuImage.83xx
image-$(CONFIG_PPC_85xx) += cuImage.85xx
image-$(CONFIG_EBONY) += treeImage.ebony
cuImage.ebony
image-$(CONFIG_BAMBOO) += treeImage.bamboo
+image-$(CONFIG_BUILD_RAW_IMAGE)+= zImage.raw
endif
# For 32-bit powermacs, build the COFF and miboot images
diff --git a/arch/powerpc/boot/fixed-head.S
b/arch/powerpc/boot/fixed-head.S
new file mode 100644
index 000..8e14cd9
--- /dev/null
+++ b/arch/powerpc/boot/fixed-head.S
@@ -0,0 +1,4 @@
+ .text
+ .global _zimage_start
+_zimage_start:
+ b _zimage_start_lib
diff --git a/arch/powerpc/boot/io.h b/arch/powerpc/boot/io.h
index ccaedae..ec57ec9 100644
--- a/arch/powerpc/boot/io.h
+++ b/arch/powerpc/boot/io.h
@@ -99,4 +99,11 @@ static inline void barrier(void)
asm volatile( : : : memory);
}
+static inline void disable_irq(void)
+{
+ int dummy;
+ asm volatile(mfmsr %0; rlwinm %0, %0, 0, ~(115); mtmsr %0
:
+=r (dummy) : : memory);
+}
This will fail (mtmsr illegal instruction) on 64 bit processors that do
not implement the bridge facility (POWER4, 5, 6, PPC970, ...)
+
#endif /* _IO_H */
diff --git a/arch/powerpc/boot/raw-platform.c
b/arch/powerpc/boot/raw-platform.c
new file mode 100644
index 000..b9caeee
--- /dev/null
+++ b/arch/powerpc/boot/raw-platform.c
@@ -0,0 +1,41 @@
+/*
+ * The raw platform -- for booting from a complete dtb without
+ * any fixups.
+ *
+ * Author: Scott Wood scottwood at freescale.com
+ *
+ * Copyright (c) 2007 Freescale Semiconductor, Inc.
+ *
+ * This program is free software; you can redistribute it and/or
modify it
+ * under the terms of the GNU General Public License version 2 as
published
+ * by the Free Software Foundation.
+ */
+
+#include ops.h
+#include types.h
+#include io.h
+
+BSS_STACK(4096);
+
+/* These are labels in
