* Re: [PATCH 1/5] [POWERPC] Add AMCC 460EX/460GT support to cputable.c & cpu_setup_44x.S
From: Benjamin Herrenschmidt @ 2008-02-22 6:23 UTC (permalink / raw)
To: Stefan Roese; +Cc: linuxppc-dev
In-Reply-To: <1203602435-11302-1-git-send-email-sr@denx.de>
On Thu, 2008-02-21 at 15:00 +0100, Stefan Roese wrote:
> Signed-off-by: Stefan Roese <sr@denx.de>
Ack.
> ---
> arch/powerpc/kernel/cpu_setup_44x.S | 5 ++++-
> arch/powerpc/kernel/cputable.c | 28 +++++++++++++++++++++++++++-
> 2 files changed, 31 insertions(+), 2 deletions(-)
>
> diff --git a/arch/powerpc/kernel/cpu_setup_44x.S b/arch/powerpc/kernel/cpu_setup_44x.S
> index 6250443..5465e8d 100644
> --- a/arch/powerpc/kernel/cpu_setup_44x.S
> +++ b/arch/powerpc/kernel/cpu_setup_44x.S
> @@ -3,7 +3,7 @@
> * Valentine Barshak <vbarshak@ru.mvista.com>
> * MontaVista Software, Inc (c) 2007
> *
> - * Based on cpu_setup_6xx code by
> + * Based on cpu_setup_6xx code by
> * Benjamin Herrenschmidt <benh@kernel.crashing.org>
> *
> * This program is free software; you can redistribute it and/or
> @@ -32,6 +32,9 @@ _GLOBAL(__setup_cpu_440grx)
> bl __fixup_440A_mcheck
> mtlr r4
> blr
> +_GLOBAL(__setup_cpu_460ex)
> +_GLOBAL(__setup_cpu_460gt)
> + b __init_fpu_44x
> _GLOBAL(__setup_cpu_440gx)
> _GLOBAL(__setup_cpu_440spe)
> b __fixup_440A_mcheck
> diff --git a/arch/powerpc/kernel/cputable.c b/arch/powerpc/kernel/cputable.c
> index 2a8f5cc..26ffb44 100644
> --- a/arch/powerpc/kernel/cputable.c
> +++ b/arch/powerpc/kernel/cputable.c
> @@ -36,6 +36,8 @@ extern void __setup_cpu_440epx(unsigned long offset, struct cpu_spec* spec);
> extern void __setup_cpu_440gx(unsigned long offset, struct cpu_spec* spec);
> extern void __setup_cpu_440grx(unsigned long offset, struct cpu_spec* spec);
> extern void __setup_cpu_440spe(unsigned long offset, struct cpu_spec* spec);
> +extern void __setup_cpu_460ex(unsigned long offset, struct cpu_spec* spec);
> +extern void __setup_cpu_460gt(unsigned long offset, struct cpu_spec* spec);
> extern void __setup_cpu_603(unsigned long offset, struct cpu_spec* spec);
> extern void __setup_cpu_604(unsigned long offset, struct cpu_spec* spec);
> extern void __setup_cpu_750(unsigned long offset, struct cpu_spec* spec);
> @@ -1397,6 +1399,30 @@ static struct cpu_spec __initdata cpu_specs[] = {
> .machine_check = machine_check_440A,
> .platform = "ppc440",
> },
> + { /* 460EX */
> + .pvr_mask = 0xffff0002,
> + .pvr_value = 0x13020002,
> + .cpu_name = "460EX",
> + .cpu_features = CPU_FTRS_44X,
> + .cpu_user_features = COMMON_USER_BOOKE | PPC_FEATURE_HAS_FPU,
> + .icache_bsize = 32,
> + .dcache_bsize = 32,
> + .cpu_setup = __setup_cpu_460ex,
> + .machine_check = machine_check_440A,
> + .platform = "ppc440",
> + },
> + { /* 460GT */
> + .pvr_mask = 0xffff0002,
> + .pvr_value = 0x13020000,
> + .cpu_name = "460GT",
> + .cpu_features = CPU_FTRS_44X,
> + .cpu_user_features = COMMON_USER_BOOKE | PPC_FEATURE_HAS_FPU,
> + .icache_bsize = 32,
> + .dcache_bsize = 32,
> + .cpu_setup = __setup_cpu_460gt,
> + .machine_check = machine_check_440A,
> + .platform = "ppc440",
> + },
> #endif /* CONFIG_44x */
> #ifdef CONFIG_FSL_BOOKE
> #ifdef CONFIG_E200
> @@ -1512,7 +1538,7 @@ struct cpu_spec * __init identify_cpu(unsigned long offset, unsigned int pvr)
> *t = *s;
> *PTRRELOC(&cur_cpu_spec) = &the_cpu_spec;
> #if defined(CONFIG_PPC64) || defined(CONFIG_BOOKE)
> - /* ppc64 and booke expect identify_cpu to also call
> + /* ppc64 and booke expect identify_cpu to also call
> * setup_cpu for that processor. I will consolidate
> * that at a later time, for now, just use #ifdef.
> * we also don't need to PTRRELOC the function pointer
^ permalink raw reply
* Re: [PATCH 2/5] [POWERPC] Add AMCC Canyonlands 460EX eval board support to platforms/44x
From: Benjamin Herrenschmidt @ 2008-02-22 6:23 UTC (permalink / raw)
To: Stefan Roese; +Cc: linuxppc-dev
In-Reply-To: <1203602446-11330-1-git-send-email-sr@denx.de>
On Thu, 2008-02-21 at 15:00 +0100, Stefan Roese wrote:
> Signed-off-by: Stefan Roese <sr@denx.de>
Ack.
> ---
> arch/powerpc/platforms/44x/Kconfig | 18 ++++++++
> arch/powerpc/platforms/44x/Makefile | 1 +
> arch/powerpc/platforms/44x/canyonlands.c | 64 ++++++++++++++++++++++++++++++
> 3 files changed, 83 insertions(+), 0 deletions(-)
> create mode 100644 arch/powerpc/platforms/44x/canyonlands.c
>
> diff --git a/arch/powerpc/platforms/44x/Kconfig b/arch/powerpc/platforms/44x/Kconfig
> index c062c4c..b56690c 100644
> --- a/arch/powerpc/platforms/44x/Kconfig
> +++ b/arch/powerpc/platforms/44x/Kconfig
> @@ -67,6 +67,16 @@ config WARP
> See http://www.pikatechnologies.com/ and follow the "PIKA for Computer
> Telephony Developers" link for more information.
>
> +config CANYONLANDS
> + bool "Canyonlands"
> + depends on 44x
> + default n
> + select 460EX
> + select PCI
> + select PPC4xx_PCI_EXPRESS
> + help
> + This option enables support for the AMCC PPC460EX evaluation board.
> +
> #config LUAN
> # bool "Luan"
> # depends on 44x
> @@ -122,6 +132,14 @@ config 440SPe
> select IBM_NEW_EMAC_EMAC4
> bool
>
> +config 460EX
> + bool
> + select PPC_FPU
> + select IBM_NEW_EMAC_EMAC4
> + select IBM_NEW_EMAC_RGMII
> + select IBM_NEW_EMAC_ZMII
> + select IBM_NEW_EMAC_TAH
> +
> # 44x errata/workaround config symbols, selected by the CPU models above
> config IBM440EP_ERR42
> bool
> diff --git a/arch/powerpc/platforms/44x/Makefile b/arch/powerpc/platforms/44x/Makefile
> index 0864d4f..d70eb03 100644
> --- a/arch/powerpc/platforms/44x/Makefile
> +++ b/arch/powerpc/platforms/44x/Makefile
> @@ -7,3 +7,4 @@ obj-$(CONFIG_KATMAI) += katmai.o
> obj-$(CONFIG_RAINIER) += rainier.o
> obj-$(CONFIG_WARP) += warp.o
> obj-$(CONFIG_WARP) += warp-nand.o
> +obj-$(CONFIG_CANYONLANDS) += canyonlands.o
> diff --git a/arch/powerpc/platforms/44x/canyonlands.c b/arch/powerpc/platforms/44x/canyonlands.c
> new file mode 100644
> index 0000000..dac5b32
> --- /dev/null
> +++ b/arch/powerpc/platforms/44x/canyonlands.c
> @@ -0,0 +1,64 @@
> +/*
> + * Canyonlands board specific routines
> + *
> + * Copyright 2008 DENX Software Engineering, Stefan Roese <sr@denx.de>
> + *
> + * Based on the Katmai code by
> + * Benjamin Herrenschmidt <benh@kernel.crashing.org>
> + * Copyright 2007 IBM Corp.
> + * Josh Boyer <jwboyer@linux.vnet.ibm.com>
> + * Copyright 2007 IBM Corporation
> + *
> + * 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/of_platform.h>
> +
> +#include <asm/machdep.h>
> +#include <asm/prom.h>
> +#include <asm/udbg.h>
> +#include <asm/time.h>
> +#include <asm/uic.h>
> +#include <asm/pci-bridge.h>
> +
> +#include "44x.h"
> +
> +static __initdata struct of_device_id canyonlands_of_bus[] = {
> + { .compatible = "ibm,plb4", },
> + { .compatible = "ibm,opb", },
> + { .compatible = "ibm,ebc", },
> + {},
> +};
> +
> +static int __init canyonlands_device_probe(void)
> +{
> + of_platform_bus_probe(NULL, canyonlands_of_bus, NULL);
> +
> + return 0;
> +}
> +machine_device_initcall(canyonlands, canyonlands_device_probe);
> +
> +static int __init canyonlands_probe(void)
> +{
> + unsigned long root = of_get_flat_dt_root();
> +
> + if (!of_flat_dt_is_compatible(root, "amcc,canyonlands"))
> + return 0;
> +
> + ppc_pci_flags = PPC_PCI_REASSIGN_ALL_RSRC;
> +
> + return 1;
> +}
> +
> +define_machine(canyonlands) {
> + .name = "Canyonlands",
> + .probe = canyonlands_probe,
> + .progress = udbg_progress,
> + .init_IRQ = uic_init_tree,
> + .get_irq = uic_get_irq,
> + .restart = ppc44x_reset_system,
> + .calibrate_decr = generic_calibrate_decr,
> +};
^ permalink raw reply
* Re: [PATCH] [POWERPC] Fix L1 cache size in katmai DTS
From: Benjamin Herrenschmidt @ 2008-02-22 6:24 UTC (permalink / raw)
To: Stefan Roese; +Cc: linuxppc-dev
In-Reply-To: <1203607297-15732-1-git-send-email-sr@denx.de>
On Thu, 2008-02-21 at 16:21 +0100, Stefan Roese wrote:
> This patch changes the katmai (440SPe) L1 cache size to 32k. Some
> whitespace issues are cleaned up too.
>
> Signed-off-by: Stefan Roese <sr@denx.de>
Ack.
> ---
> arch/powerpc/boot/dts/katmai.dts | 58 +++++++++++++++++++-------------------
> 1 files changed, 29 insertions(+), 29 deletions(-)
>
> diff --git a/arch/powerpc/boot/dts/katmai.dts b/arch/powerpc/boot/dts/katmai.dts
> index 9bdfc0f..abf7f3e 100644
> --- a/arch/powerpc/boot/dts/katmai.dts
> +++ b/arch/powerpc/boot/dts/katmai.dts
> @@ -38,8 +38,8 @@
> timebase-frequency = <0>; /* Filled in by zImage */
> i-cache-line-size = <20>;
> d-cache-line-size = <20>;
> - i-cache-size = <20000>;
> - d-cache-size = <20000>;
> + i-cache-size = <8000>;
> + d-cache-size = <8000>;
> dcr-controller;
> dcr-access-method = "native";
> };
> @@ -136,11 +136,11 @@
> };
>
> POB0: opb {
> - compatible = "ibm,opb-440spe", "ibm,opb-440gp", "ibm,opb";
> + compatible = "ibm,opb-440spe", "ibm,opb-440gp", "ibm,opb";
> #address-cells = <1>;
> #size-cells = <1>;
> - ranges = <00000000 4 e0000000 20000000>;
> - clock-frequency = <0>; /* Filled in by zImage */
> + ranges = <00000000 4 e0000000 20000000>;
> + clock-frequency = <0>; /* Filled in by zImage */
>
> EBC0: ebc {
> compatible = "ibm,ebc-440spe", "ibm,ebc-440gp", "ibm,ebc";
> @@ -153,38 +153,38 @@
> };
>
> UART0: serial@10000200 {
> - device_type = "serial";
> - compatible = "ns16550";
> - reg = <10000200 8>;
> + device_type = "serial";
> + compatible = "ns16550";
> + reg = <10000200 8>;
> virtual-reg = <a0000200>;
> - clock-frequency = <0>; /* Filled in by zImage */
> - current-speed = <1c200>;
> - interrupt-parent = <&UIC0>;
> - interrupts = <0 4>;
> - };
> + clock-frequency = <0>; /* Filled in by zImage */
> + current-speed = <1c200>;
> + interrupt-parent = <&UIC0>;
> + interrupts = <0 4>;
> + };
>
> UART1: serial@10000300 {
> - device_type = "serial";
> - compatible = "ns16550";
> - reg = <10000300 8>;
> + device_type = "serial";
> + compatible = "ns16550";
> + reg = <10000300 8>;
> virtual-reg = <a0000300>;
> - clock-frequency = <0>;
> - current-speed = <0>;
> - interrupt-parent = <&UIC0>;
> - interrupts = <1 4>;
> - };
> + clock-frequency = <0>;
> + current-speed = <0>;
> + interrupt-parent = <&UIC0>;
> + interrupts = <1 4>;
> + };
>
>
> UART2: serial@10000600 {
> - device_type = "serial";
> - compatible = "ns16550";
> - reg = <10000600 8>;
> + device_type = "serial";
> + compatible = "ns16550";
> + reg = <10000600 8>;
> virtual-reg = <a0000600>;
> - clock-frequency = <0>;
> - current-speed = <0>;
> - interrupt-parent = <&UIC1>;
> - interrupts = <5 4>;
> - };
> + clock-frequency = <0>;
> + current-speed = <0>;
> + interrupt-parent = <&UIC1>;
> + interrupts = <5 4>;
> + };
>
> IIC0: i2c@10000400 {
> device_type = "i2c";
^ permalink raw reply
* [PATCH] Fix typos on Kconfig for PowerPC 4xx on-chip ethernet driver
From: Satoru Takeuchi @ 2008-02-22 7:10 UTC (permalink / raw)
To: ebs, linuxppc-dev, netdev
Fix typos on Kconfig for PowerPC 4xx on-chip ethernet driver.
Signed-off-by: Satoru Takeuchi <takeuchi_satoru@jp.fujitsu.com>
---
Index: 2.6.25-rc2/drivers/net/ibm_newemac/Kconfig
===================================================================
--- 2.6.25-rc2.orig/drivers/net/ibm_newemac/Kconfig 2008-02-22 15:13:35.000000000 +0900
+++ 2.6.25-rc2/drivers/net/ibm_newemac/Kconfig 2008-02-22 15:13:54.000000000 +0900
@@ -43,7 +43,7 @@ config IBM_NEW_EMAC_DEBUG
depends on IBM_NEW_EMAC
default n
-# The options below has to be select'ed by the respective
+# The options below has to be selected by the respective
# processor types or platforms
config IBM_NEW_EMAC_ZMII
^ permalink raw reply
* Re: [BUG] Linux 2.6.25-rc2 - Regression from 2.6.24-rc1-git1 softlockup while bootup on powerpc
From: Andrew Morton @ 2008-02-22 7:24 UTC (permalink / raw)
To: Jens Axboe
Cc: Giani, Srivatsa Vaddagiri, Linux Kernel Mailing List,
linuxppc-dev, Ingo Molnar, Kamalesh Babulal, Dhaval,
KAMEZAWA Hiroyuki, Balbir Singh
In-Reply-To: <20080219083633.GN23197@kernel.dk>
On Tue, 19 Feb 2008 09:36:34 +0100 Jens Axboe <jens.axboe@oracle.com> wrote:
> But I think the radix 'scan over entire tree' is a bit fragile.
eek, it had better not be. Was this an error in the caller? Hope so.
> This
> patch adds a parallel hlist for ease of properly browsing the members,
Even though io_contexts are fairly uncommon, adding more stuff to a data
structure was a pretty sad alternative to fixing a bug in
radix_tree_gang_lookup(), or to fixing a bug in a caller of it.
IOW: what exactly went wrong here??
^ permalink raw reply
* Re: [BUG] Linux 2.6.25-rc2 - Regression from 2.6.24-rc1-git1 softlockup while bootup on powerpc
From: Jens Axboe @ 2008-02-22 7:40 UTC (permalink / raw)
To: Andrew Morton
Cc: Dhaval Giani, Srivatsa Vaddagiri, Linux Kernel Mailing List,
linuxppc-dev, Ingo Molnar, Kamalesh Babulal, KAMEZAWA Hiroyuki,
Balbir Singh
In-Reply-To: <20080221232418.b93db8d9.akpm@linux-foundation.org>
On Thu, Feb 21 2008, Andrew Morton wrote:
> On Tue, 19 Feb 2008 09:36:34 +0100 Jens Axboe <jens.axboe@oracle.com> wrote:
>
> > But I think the radix 'scan over entire tree' is a bit fragile.
>
> eek, it had better not be. Was this an error in the caller? Hope so.
The cfq use of it, not the radix tree code! It juggled the keys and
wants to make sure that we see all users, modulo raced added ones (ok if
we see them, doesn't matter if we don't).
> > This
> > patch adds a parallel hlist for ease of properly browsing the members,
>
> Even though io_contexts are fairly uncommon, adding more stuff to a data
> structure was a pretty sad alternative to fixing a bug in
> radix_tree_gang_lookup(), or to fixing a bug in a caller of it.
>
> IOW: what exactly went wrong here??
I could not convince myself that the current code would always do the
right thing. We should not have been seeing ->key == NULL entries in
there, it implied a double exit of that process. So I decided to fix it
by making the code a lot more readable (the patch in question deleted a
lot more than it added), at the cost of that hlist head + node.
--
Jens Axboe
^ permalink raw reply
* [PATCH] [POWERPC] AMCC Kilauea (405EX): Disable EMAC loopback mode
From: Stefan Roese @ 2008-02-22 8:32 UTC (permalink / raw)
To: linuxppc-dev
405EX(r) has SDR0_MFR[E0CS/E1CS] set after reset. This selects
the internal loopback mode. Clear these bits so that both EMACs
don't use loopback mode as default.
Signed-off-by: Stefan Roese <sr@denx.de>
---
I'm not sure if this should be done here in the board platform code,
or in the newemac driver or perhaps in some code common for 405EX.
Any thoughts on this welcome.
Thanks.
arch/powerpc/platforms/40x/kilauea.c | 11 ++++++++++-
1 files changed, 10 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/platforms/40x/kilauea.c b/arch/powerpc/platforms/40x/kilauea.c
index f9206a7..b5456cc 100644
--- a/arch/powerpc/platforms/40x/kilauea.c
+++ b/arch/powerpc/platforms/40x/kilauea.c
@@ -1,7 +1,7 @@
/*
* Kilauea board specific routines
*
- * Copyright 2007 DENX Software Engineering, Stefan Roese <sr@denx.de>
+ * Copyright 2007-2008 DENX Software Engineering, Stefan Roese <sr@denx.de>
*
* Based on the Walnut code by
* Josh Boyer <jwboyer@linux.vnet.ibm.com>
@@ -20,6 +20,8 @@
#include <asm/time.h>
#include <asm/uic.h>
#include <asm/pci-bridge.h>
+#include <asm/dcr.h>
+#include <asm/dcr-regs.h>
static __initdata struct of_device_id kilauea_of_bus[] = {
{ .compatible = "ibm,plb4", },
@@ -45,6 +47,13 @@ static int __init kilauea_probe(void)
ppc_pci_flags = PPC_PCI_REASSIGN_ALL_RSRC;
+ /*
+ * 405EX(r) has SDR0_MFR[E0CS/E1CS] set after reset. This selects
+ * the internal loopback mode. Clear these bits so that both EMACs
+ * don't use loopback mode as deafult.
+ */
+ mtdcri(SDR0, SDR0_MFR, mfdcri(SDR0, SDR0_MFR) & ~0x0c000000);
+
return 1;
}
--
1.5.4.2
^ permalink raw reply related
* Re: [PATCH] Add support for binary includes.
From: David Woodhouse @ 2008-02-22 9:02 UTC (permalink / raw)
To: Grant Likely; +Cc: Scott Wood, linuxppc-dev, jdl
In-Reply-To: <fa686aa40802212205p38c3793bg8793740955b1e91@mail.gmail.com>
On Thu, 2008-02-21 at 23:05 -0700, Grant Likely wrote:
> Can I ask; what is the intended usage of such a thing? How large
> would a typical binary blob be?
Device firmware?
--
dwmw2
^ permalink raw reply
* Re: [PATCH] Add support for binary includes.
From: Bartlomiej Sieka @ 2008-02-22 8:34 UTC (permalink / raw)
To: Grant Likely; +Cc: Scott Wood, linuxppc-dev, jdl
In-Reply-To: <fa686aa40802212205p38c3793bg8793740955b1e91@mail.gmail.com>
Grant Likely wrote:
> On Wed, Feb 20, 2008 at 12:19 PM, Scott Wood <scottwood@freescale.com> wrote:
>> A property's data can be populated with a file's contents
>> as follows:
>>
>> node {
>> prop = /incbin/("path/to/data");
>> };
>>
>> A subset of a file can be included by passing start and size parameters.
>> For example, to include bytes 8 through 23:
>>
>> node {
>> prop = /incbin/("path/to/data", 8, 16);
>> };
>
>
> Can I ask; what is the intended usage of such a thing? How large
> would a typical binary blob be?
Binary includes are a critical feature of the new image format for
U-Boot. In short: we're describing image's content and other data
(architecture, os, image type, etc) in dts format, and then use dtc to
generate the file that is transferred to the target and booted by
U-Boot. Excerpt from an actual file describing an image:
/{
images {
kernel@1 {
data = /incbin/("./vmlinux.bin.gz");
type = "kernel";
arch = "ppc";
os = "linux";
compression = "gzip";
load = <00000000>;
entry = <00000000>;
};
};
};
As to the size of the final blob in our case, it depends. It seems that
in case of a powerpc Linux booting scenario, most of the times the size
will be roughly the size of a compressed kernel + the size of the FDT
blob, eventually plus the size of a ramdisk. Note however, that the new
image format has provisions for handling multiple components of the same
type in one image, so for example you could have three kernels, two
ramdisks and a couple of fdt blobs in one image, and the actual booting
configuration could be selected in U-Boot. In such a case, the final
blob can be arbitrarily large.
Regards,
Bartlomiej
^ permalink raw reply
* MPC8540 : What's "SPE used in kernel" ?
From: Philippe De Muyter @ 2008-02-22 9:50 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20080221123534.GA17716@ingate.macqel>
Dear list,
I have just compiled linux-2.6.24 for a MPC8540 target using a MPC8540
specific gcc.
I then got tan infinity of "SPE used in kernel" messages. Looking at the
sources I ifdeffed out the printk call in KernelSPE, and I now have a
silent kernel, that seems to work fine.
Is there something wrong in my setting and should I look further to
debug this problem or is this perfectly normal ?
I wonder why a kernel configured for E500 and compiled by a E500-specific gcc
triggers this message. Is it invalid to use SPE instructions in the kernel
or do I misunderstand the message ?
Philippe
^ permalink raw reply
* Re: [PATCHv4 2.6.25] i2c: adds support for i2c bus on Freescale CPM1/CPM2 controllers
From: Jochen Friedrich @ 2008-02-22 11:16 UTC (permalink / raw)
To: Jean Delvare; +Cc: linux-kernel, linuxppc-dev list, i2c, Scott Wood
In-Reply-To: <20080221130520.12b01553@hyperion.delvare>
Hi Jean,
>> +/*
>> + * Wait for patch from Jon Smirl
>> + * #include "powerpc-common.h"
>> + */
>
> It doesn't make sense to merge this comment upstream.
I know you don't like the patch from Jon Smirl and you also explained your reasons.
Fortunately, I2c no longer uses numeric device IDs but names. So what are the alternatives?
1. modify the I2c subsystem to accept OF names additionally to I2c names (proposed by Jon smirl).
2. record the I2c name in the dts tree, either as seperate tag (like linux,i2c-name="<i2c-name>")
or as additional compatible entry (like compatible="...", "linux,<i2c-name>").
3. use a glue layer with a translation map.
What is the preferred way to do this?
Thanks,
Jochen
^ permalink raw reply
* TQM5200 2.6-denx SM501 voyager enabling problem.
From: Pedro Luis D. L. @ 2008-02-22 11:29 UTC (permalink / raw)
To: linuxppc-embedded
Hello,
I'm working right now with a TQM5200 microcontroller on a STX5200 board.
I'm having problems to enable SM501 video output using 2.6-denx kernel. The=
system is working properly using 2.4 kernel and I can have graphical outpu=
t, so I can be sure that there's no hardware problem.
With 2.6 I have used the tqm5200_defconfig configuration file and then I ha=
ve enabled the following features in the kernel:
- Device Drivers -> Multifunction Device Drivers -> Support forSilicon Mot=
ion SM501.
- Device Drivers -> Graphic Support -> Support for frame buffer devices.
- Device Drivers -> Graphic Support -> Support for frame buffer devices -=
> Silicon Motion SM501 framebuffer support.
- Device Drivers -> Character devices -> Virtual Terminal.
- Device Drivers -> Character devices -> Support for console on virtual te=
rminal.
But I still can't make the SM501 driver initialized at booting time and the=
re's no framebuffer video device available. /dev/fb and /dev/fb0 nodes are =
already created.
I'm using 1.3.1 u-boot from denx repository compiled with CONFIG_STK52XX=
=3Dy and CONFIG_MINIFAP=3Dy options, and video=3Dvoyager:fp options is pass=
ed to the kernel at booting.
I'm sure there's something I'm missing to enable in the kernel. Maybe someo=
ne can sent me a hint. I would appreciate any!
Pedro L.
_________________________________________________________________
MSN Noticias
http://noticias.msn.es/comunidad.aspx=
^ permalink raw reply
* Re: [PATCH] [POWERPC] 8xx: timebase frequency should not depend on bus-frequency
From: Bryan O'Donoghue @ 2008-02-22 13:01 UTC (permalink / raw)
To: cbouatmailru; +Cc: Scott Wood, linuxppc-dev
In-Reply-To: <20080221234136.GA3545@zarina>
On Fri, 22 Feb 2008 02:41:36 +0300
Anton Vorontsov <cbouatmailru@gmail.com> wrote:
> On Thu, Feb 21, 2008 at 03:20:10PM -0600, Scott Wood wrote:
> > Anton Vorontsov wrote:
> > > On Thu, Feb 21, 2008 at 02:06:58PM -0600, Scott Wood wrote:
> > >> Current u-boots don't support device trees at all on 8xx.
> > >
> > > Yes, vanilla u-boots. I assume many of us use some u-boot hacks to
> > > actually boot with the device tree (no, not cuboots)... ;-)
> >
> > Fine, but don't expect misbehavior from out-of-tree u-boots to be used
> > as justification for the kernel ignoring device tree content. :-)
>
> You got me wrong, maybe I wasn't clear enough: it wasn't justification of
> any kind. It's was just a remark regarding u-boot still not supporting
> fdt for 8xx (20 lines of code we're lazy to cleanup, write annotation
> to the patch and send it ;-).
Hey Anton.
I won't make any comment on what Linux should do with an older version of
u-boot.
However, just to let you know, there are a couple of patches to do a more modern
fdt on 8xx- sent to the u-boot list in the last <= ~ 10 days.
Using those patches - which incorporate the changes suggested by Scott re:
get_tbclk()- the timebase-frequency field is indeed stuffed with u-boot's
get_tbclk(); - see below.
u-boot/cpu/mpc8xx/fdt.c
void ft_cpu_setup(void *blob, bd_t *bd)
{
do_fixup_by_prop_u32(blob, "device_type", "cpu", 4,
"timebase-frequency", get_tbclk(), 1);
do_fixup_by_prop_u32(blob, "device_type", "cpu", 4,
"bus-frequency", bd->bi_busfreq, 1);
do_fixup_by_prop_u32(blob, "device_type", "cpu", 4,
"clock-frequency", bd->bi_intfreq, 1);
do_fixup_by_compat_u32(blob, "fsl,cpm-brg", "clock-frequency",
gd->brg_clk, 1);
/* Fixup ethernet MAC addresses */
fdt_fixup_ethernet(blob, bd);
fdt_fixup_memory(blob, (u64)bd->bi_memstart, (u64)bd->bi_memsize);
}
Adding fdt support to an 8xx board is then as simple as defining
/* pass open firmware flat tree */
#define CONFIG_OF_LIBFDT 1
#define CONFIG_OF_BOARD_SETUP 1
In your u-boot/include/configs/MySuperBoard.h
Best,
Bryan
^ permalink raw reply
* Doubt in Device tree entry for USB on Powerpc based board
From: mahendra varman @ 2008-02-22 13:33 UTC (permalink / raw)
To: linuxppc-embedded, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 6986 bytes --]
Hello All
Iam using Powerpc 7448 processor along with TSI 109 system controller.
On PCI interface of TSI 109 a PCI to PCI bridge(6520) is connected in which
an usb controller(Philips ISP1562) and PMC site is connected.
Iam following the Open Firmware Powerpc architecture and using Linux 2.6.23.
I have framed the device tree for the above architecture with usb entry. But
even though i enable the ohci ppc of in menuconfig the the functions
probe,etc inside ohci ppc of.c are not called when i insert the device in
usb port and hence it is not detecting ohci low/full speed devices.
Please help me in the device tree where to give the device type
compatibility address_cells size cells for the USB (since usb controller is
in pci bridge i have some confusion in where to give the entry for usb)
I have attached the device tree below
-----------------------------------------------------------------------------------------------------------------------------------------------------------------
{ model = "CTP7448";
compatible = "mpc74xx";
#address-cells = <1>;
#size-cells = <1>;
cpus {
#address-cells = <1>;
#size-cells =<0>;
PowerPC,7448@0 {
device_type = "cpu";
reg = <0>;
d-cache-line-size = <20>; // 32 bytes
i-cache-line-size = <20>; // 32 bytes
d-cache-size = <8000>; // L1, 32K bytes
i-cache-size = <8000>; // L1, 32K bytes
timebase-frequency = <0>; // 33 MHz, from uboot
clock-frequency = <0>; // From U-Boot
bus-frequency = <0>; // From U-Boot
32-bit;
};
};
memory{
device_type = "memory";
reg = <00000000 10000000>; // DDR2 512M at 0
};
tsi108@c0000000 {
#address-cells = <1>;
#size-cells = <1>;
#interrupt-cells = <2>;
device_type = "tsi-bridge";
ranges = <00000000 c0000000 00010000
00000000 f0000000 00008000
00000000 f1000000 01000000
00000000 f8000000 01000000>;
reg = <c0000000 00010000>;
bus-frequency = <0>;
rtc@f0000000 {
device_type = "rtc";
compatible = "st,m48t59";
reg = <f0000000 8000>;
};
i2c@7000 {
interrupt-parent = <&mpic>;
interrupts = <E 0>;
reg = <7000 400>;
device_type = "i2c";
compatible = "tsi108-i2c";
};
MDIO: mdio@6000 {
device_type = "mdio";
compatible = "tsi108-mdio";
reg = <6000 50>;
#address-cells = <1>;
#size-cells = <0>;
phy1: ethernet-phy@1 {
interrupt-parent = <&mpic>;
interrupts = <0 0>;
reg = <1>;
device_type = "ethernet-phy";
};
phy8: ethernet-phy@8 {
interrupt-parent = <&mpic>;
interrupts = <1 0>;
reg = <8>;
device_type = "ethernet-phy";
};
};
ethernet@6200 {
#size-cells = <0>;
device_type = "network";
compatible = "tsi108-ethernet";
reg = <6000 200>;
address = [ 00 03 23 00 00 01 ];
interrupts = <10 0>;
interrupt-parent = <&mpic>;
mdio-handle = <&MDIO>;
phy-handle = <&phy1>;
};
ethernet@6600 {
#address-cells = <1>;
#size-cells = <0>;
device_type = "network";
compatible = "tsi108-ethernet";
reg = <6400 200>;
address = [ 00 03 23 00 00 02 ];
interrupts = <11 2>;
interrupt-parent = <&mpic>;
mdio-handle = <&MDIO>;
phy-handle = <&phy8>;
};
serial@7808 {
device_type = "serial";
compatible = "ns16550";
reg = <7808 200>;
clock-frequency = <3f6b5a00>;
interrupts = <c 0>;
interrupt-parent = <&mpic>;
};
serial@7c08 {
device_type = "serial";
compatible = "ns16550";
reg = <7c08 200>;
clock-frequency = <3f6b5a00>;
interrupts = <d 0>;
interrupt-parent = <&mpic>;
};
mpic: pic@7400 {
clock-frequency = <0>;
interrupt-controller;
#address-cells = <0>;
#interrupt-cells = <2>;
reg = <7400 400>;
built-in;
compatible = "chrp,open-pic";
device_type = "open-pic";
big-endian;
};
pci@1000 {
compatible = "tsi108-pci";
device_type = "pci";
#interrupt-cells = <1>;
#size-cells = <2>;
#address-cells = <3>;
reg = <1000 1000>;
bus-range = <0 0>;
ranges = <02000000 0 e0000000 e0000000 0 10000000
01000000 0 00000000 f2000000 0 01000000>;
clock-frequency = <3ef1480>;
interrupt-parent = <&mpic>;
interrupts = <17 2>;
interrupt-map-mask = <f800 0 0 7>;
interrupt-map = <
/* IDSEL 0x10 */
00000 0 0 1 &RT0 24 0
/* IDSEL 0x11 */
00800 0 0 1 &RT0 25 0
/* IDSEL 0x12 */
1000 0 0 1 &RT0 24 0
1000 0 0 2 &RT0 25 0
1000 0 0 3 &RT0 26 0
1000 0 0 4 &RT0 27 0 >;
pci_bridge@12 {
interrupt-map-mask = <f800 0 0 7>;
interrupt-map = <
/* IDSEL 0x13 (PMC Site) */
1800 0 0 1 &RT0 24 0
1800 0 0 2 &RT0 25 0
1800 0 0 3 &RT0 26 0
1800 0 0 4 &RT0 27 0
/* IDSEL 0x14 (USB chip) */
2000 0 0 1 &RT0 27 0
2000 0 0 2 &RT0 27 0
2000 0 0 3 &RT0 27 0
2000 0 0 4 &RT0 27 0
>;
reg = <1000 0 0 0 0>;
#interrupt-cells = <1>;
#size-cells = <2>;
#address-cells = <3>;
ranges = <02000000 0 e0000000 e0000000 0 10000000 01000000 0
00000000 fa000000 0 00010000>;
clock-frequency = <1f78a40>;
RT0: router@1180 {
clock-frequency = <0>;
interrupt-controller;
device_type = "pic-router";
#address-cells = <0>;
#interrupt-cells = <2>;
built-in;
big-endian;
interrupts = <17 2>;
interrupt-parent = <&mpic>;
};
};
};
};
};
[-- Attachment #2: Type: text/html, Size: 17996 bytes --]
^ permalink raw reply
* Re: MPC8641D PCI-Express error
From: Marco Stornelli @ 2008-02-22 13:52 UTC (permalink / raw)
To: LinuxPPC-Embedded; +Cc: s.balamurugan
In-Reply-To: <47BD9FA9.1000904@freescale.com>
Jon Loeliger ha scritto:
> Marco Stornelli wrote:
>> When I try to read some register from my FPGA (virtex5) I have this bus
>> error:
>
>
> Hmmm.... OK, so if we've eliminated PCI-E as a source
> for this issue, it really must be in the Virtex support
> somewhere then. Unfortunately, I know nothing about those,
> and am not going to be much direct help there.
>
> Sorry.
>
> jdl
>
>
>> Machine check in kernel mode.
>> Caused by (from SRR1=149030): Transfer error ack signal
>> Oops: Machine check, sig: 7 [#1]
>> PREEMPT SMP NR_CPUS=2
>> Modules linked in: virtex5
>> LTT NESTING LEVEL : 0
>> NIP: F108019C LR: F1080198 CTR: 00000001
>> REGS: c044dd60 TRAP: 0200 Not tainted (2.6.18-mpc8641d_hpcn)
>> MSR: 00149030 <EE,ME,IR,DR> CR: 22000222 XER: 00000000
>> TASK = c20e9990[568] 'insmod' THREAD: c044c000 CPU: 0
>> GPR00: F1080198 C044DE10 C20E9990 0000002E 80000000 FFFFFFFF 00008000
>> 00002EA3
>> GPR08: C20E9990 00000000 C04C0220 C044C000 22000222 1001956C 00000000
>> 00000000
>> GPR16: 00000000 00000000 00000000 00000000 00000000 00000000 00000000
>> 00000000
>> GPR24: 3000EAA0 7FD6FDC0 00000000 C045FCC0 F107E594 F10A0000 00000000
>> C2036000
>> NIP [F108019C] virtex5_probe+0x130/0x1c4 [virtex5]
>> LR [F1080198] virtex5_probe+0x12c/0x1c4 [virtex5]
>> Call Trace:
>> [C044DE10] [F1080198] virtex5_probe+0x12c/0x1c4 [virtex5] (unreliable)
>> [C044DE30] [C01D2A58] pci_device_probe+0x84/0xbc
>> [C044DE50] [C0213754] driver_probe_device+0x60/0x118
>> [C044DE70] [C0213890] __driver_attach+0x84/0x88
>> [C044DE90] [C02130F4] bus_for_each_dev+0x58/0x94
>> [C044DEC0] [C02135D4] driver_attach+0x24/0x34
>> [C044DED0] [C0212AC8] bus_add_driver+0x88/0x164
>> [C044DEF0] [C021397C] driver_register+0x70/0xb8
>> [C044DF00] [C01D284C] __pci_register_driver+0x64/0x98
>> [C044DF10] [F1080030] init_module+0x30/0x6c [virtex5]
>> [C044DF20] [C004CBFC] sys_init_module+0xc8/0x25c
>> [C044DF40] [C0011358] ret_from_syscall+0x0/0x38
>> --- Exception: c00 at 0xff6de0c
>> LR = 0x10000de4
>> Instruction dump:
>> 40820060 3c60f108 3863cea0 48000311 807f0238 3c800001 48000395 7c7d1b78
>> 3c60f108 3863ced4 480002f5 809d0000 <3c60f108> 3863cf04 480002e5 3c60f108
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
I tried to use 2.6.24 but I have the same error. It looks like this
problem happens when I try to read something in my ML555 board (Virtex5
evaluation board), but if try to write everything works fine. I tried to
change the settings about inbound/outbound PCI-E windows but I have the
same problem. Have you got any suggestions?
Thanks.
Marco
^ permalink raw reply
* Re: compile quirk linux-2.6.24 (with workaround)
From: Bernhard Reiter @ 2008-02-22 14:50 UTC (permalink / raw)
To: debian-powerpc; +Cc: linuxppc-dev, paulus
In-Reply-To: <20080218205248.1af469d4@zod.rchland.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 1231 bytes --]
On Tuesday 19 February 2008 03:52, Josh Boyer wrote:
> My apologies for taking so long on this. Digging through gcc history
> isn't exactly fun :)
No problem. Thanks for tackling the issue.
> Ok, so it seems -mcpu=440 was added in gcc 3.4. The -mcpu=405 option
> has been around since 2001. Seeing as how there really isn't anything
> 440 specific in the files effected, we should be able to pass -mcpu=405
> for everything and have it still work.
>
> Bernhard, can you try the patch below?
I will test it in the next days.
The short test for my sarge compiler makes me optimistic:
dpkg -l gcc | grep gcc
ii gcc 3.3.5-3 The GNU C compiler
bernhard@burn:~/tmp$ gcc -mcpu=440 x.c
cc1: error: bad value (440) for -mcpu= switch
bernhard@burn:~/tmp$ gcc -mcpu=405 x.c
bernhard@burn:~/tmp$
> -$(obj)/cuboot-katmai.o: BOOTCFLAGS += -mcpu=440
> +$(obj)/4xx.o: BOOTCFLAGS += -mcpu=405
--
Managing Director - Owner: www.intevation.net (Free Software Company)
Germany Coordinator: fsfeurope.org. Coordinator: www.Kolab-Konsortium.com.
Intevation GmbH, Osnabrück, DE; Amtsgericht Osnabrück, HRB 18998
Geschäftsführer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: MPC8540 : What's "SPE used in kernel" ?
From: Johannes Berg @ 2008-02-22 15:29 UTC (permalink / raw)
To: Philippe De Muyter; +Cc: linuxppc-dev
In-Reply-To: <20080222095022.GA635@ingate.macqel>
[-- Attachment #1: Type: text/plain, Size: 502 bytes --]
> I wonder why a kernel configured for E500 and compiled by a E500-specific gcc
> triggers this message. Is it invalid to use SPE instructions in the kernel
> or do I misunderstand the message ?
I think it's like floating point/altivec, we don't always save the FP
registers on kernel/userspace transitions and so have to explicitly save
them to use them in the kernel, otherwise we'd clobber the userspace
register state.
I guess there's something like kernel_enter_spe()?
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
^ permalink raw reply
* Marvell PHY driver fix
From: Alexandr Smirnov @ 2008-02-22 14:34 UTC (permalink / raw)
To: netdev; +Cc: linuxppc-dev, vbordug
Marvell PHY m88e1111 (not sure about other models, but think they too) works in
two modes: fiber and copper. In Marvell PHY driver (that we have in current
community kernels) code supported only copper mode, and this is not configurable,
bits for copper mode are simply written in registers during PHY
initialization. This patch adds support for both modes.
Signed-off-by: Alexandr Smirnov <asmirnov@ru.mvista.com>
diff -pruN powerpc.orig/drivers/net/phy/marvell.c powerpc/drivers/net/phy/marvell.c
--- powerpc.orig/drivers/net/phy/marvell.c 2008-02-07 14:59:32.000000000 +0300
+++ powerpc/drivers/net/phy/marvell.c 2008-02-19 21:47:34.000000000 +0300
@@ -58,9 +58,28 @@
#define MII_M1111_RX_DELAY 0x80
#define MII_M1111_TX_DELAY 0x2
#define MII_M1111_PHY_EXT_SR 0x1b
-#define MII_M1111_HWCFG_MODE_MASK 0xf
-#define MII_M1111_HWCFG_MODE_RGMII 0xb
+
+#define MII_M1111_HWCFG_MODE_MASK 0xf
+#define MII_M1111_HWCFG_MODE_COPPER_RGMII 0xb
+#define MII_M1111_HWCFG_MODE_FIBER_RGMII 0x3
#define MII_M1111_HWCFG_MODE_SGMII_NO_CLK 0x4
+#define MII_M1111_HWCFG_FIBER_COPPER_AUTO 0x8000
+#define MII_M1111_HWCFG_FIBER_COPPER_RES 0x2000
+
+#define MII_M1111_PHY_CR 0
+#define MII_M1111_SOFTWARE_RESET 0x8000
+
+#define MII_M1111_COPPER 0
+#define MII_M1111_FIBER 1
+
+#define MII_M1011_PHY_STATUS 0x11
+#define MII_M1011_PHY_STATUS_1000 0x8000
+#define MII_M1011_PHY_STATUS_100 0x4000
+#define MII_M1011_PHY_STATUS_SPD_MASK 0xc000
+#define MII_M1011_PHY_STATUS_FULLDUPLEX 0x2000
+#define MII_M1011_PHY_STATUS_RESOLVED 0x0800
+#define MII_M1011_PHY_STATUS_LINK 0x0400
+
MODULE_DESCRIPTION("Marvell PHY driver");
MODULE_AUTHOR("Andy Fleming");
@@ -141,12 +160,22 @@ static int marvell_config_aneg(struct ph
static int m88e1111_config_init(struct phy_device *phydev)
{
int err;
+ int temp;
+ int mode;
+
+ /* Enable Fiber/Copper auto selection */
+ temp = phy_read(phydev, MII_M1111_PHY_EXT_SR);
+ temp |= MII_M1111_HWCFG_FIBER_COPPER_AUTO;
+ phy_write(phydev, MII_M1111_PHY_EXT_SR, temp);
+
+ temp = phy_read(phydev, MII_M1111_PHY_CR);
+ temp |= MII_M1111_SOFTWARE_RESET;
+ phy_write(phydev, MII_M1111_PHY_CR, temp);
if ((phydev->interface == PHY_INTERFACE_MODE_RGMII) ||
(phydev->interface == PHY_INTERFACE_MODE_RGMII_ID) ||
(phydev->interface == PHY_INTERFACE_MODE_RGMII_RXID) ||
(phydev->interface == PHY_INTERFACE_MODE_RGMII_TXID)) {
- int temp;
temp = phy_read(phydev, MII_M1111_PHY_EXT_CR);
if (temp < 0)
@@ -171,7 +200,17 @@ static int m88e1111_config_init(struct p
return temp;
temp &= ~(MII_M1111_HWCFG_MODE_MASK);
- temp |= MII_M1111_HWCFG_MODE_RGMII;
+
+ mode = phy_read(phydev, MII_M1111_PHY_EXT_CR);
+ mode = (mode & MII_M1111_HWCFG_FIBER_COPPER_RES) >> 13;
+
+ switch (mode) {
+ case MII_M1111_COPPER:
+ temp |= MII_M1111_HWCFG_MODE_COPPER_RGMII;
+ break;
+ case MII_M1111_FIBER:
+ temp |= MII_M1111_HWCFG_MODE_FIBER_RGMII;
+ }
err = phy_write(phydev, MII_M1111_PHY_EXT_SR, temp);
if (err < 0)
@@ -262,6 +301,93 @@ static int m88e1145_config_init(struct p
return 0;
}
+/* marvell_read_status
+ *
+ * Generic status code does not detect Fiber correctly!
+ * Description:
+ * Check the link, then figure out the current state
+ * by comparing what we advertise with what the link partner
+ * advertises. Start by checking the gigabit possibilities,
+ * then move on to 10/100.
+ */
+static int marvell_read_status(struct phy_device *phydev)
+{
+ int adv;
+ int err;
+ int lpa;
+ int status = 0;
+
+ /* Update the link, but return if there
+ * was an error */
+ err = genphy_update_link(phydev);
+ if (err)
+ return err;
+
+ if (AUTONEG_ENABLE == phydev->autoneg) {
+ status = phy_read(phydev, MII_M1011_PHY_STATUS);
+ if (status < 0)
+ return status;
+
+ lpa = phy_read(phydev, MII_LPA);
+ if (lpa < 0)
+ return lpa;
+
+ adv = phy_read(phydev, MII_ADVERTISE);
+ if (adv < 0)
+ return adv;
+
+ lpa &= adv;
+
+ if (status & MII_M1011_PHY_STATUS_FULLDUPLEX)
+ phydev->duplex = DUPLEX_FULL;
+ else
+ phydev->duplex = DUPLEX_HALF;
+
+ status = status & MII_M1011_PHY_STATUS_SPD_MASK;
+ phydev->pause = phydev->asym_pause = 0;
+
+ switch (status) {
+ case MII_M1011_PHY_STATUS_1000:
+ phydev->speed = SPEED_1000;
+ break;
+
+ case MII_M1011_PHY_STATUS_100:
+ phydev->speed = SPEED_100;
+ break;
+
+ default:
+ phydev->speed = SPEED_10;
+ break;
+ }
+
+ if (phydev->duplex == DUPLEX_FULL) {
+ phydev->pause = lpa & LPA_PAUSE_CAP ? 1 : 0;
+ phydev->asym_pause = lpa & LPA_PAUSE_ASYM ? 1 : 0;
+ }
+ } else {
+ int bmcr = phy_read(phydev, MII_BMCR);
+
+ if (bmcr < 0)
+ return bmcr;
+
+ if (bmcr & BMCR_FULLDPLX)
+ phydev->duplex = DUPLEX_FULL;
+ else
+ phydev->duplex = DUPLEX_HALF;
+
+ if (bmcr & BMCR_SPEED1000)
+ phydev->speed = SPEED_1000;
+ else if (bmcr & BMCR_SPEED100)
+ phydev->speed = SPEED_100;
+ else
+ phydev->speed = SPEED_10;
+
+ phydev->pause = phydev->asym_pause = 0;
+ }
+
+ return 0;
+}
+
static struct phy_driver marvell_drivers[] = {
{
.phy_id = 0x01410c60,
@@ -296,7 +422,7 @@ static struct phy_driver marvell_drivers
.flags = PHY_HAS_INTERRUPT,
.config_init = &m88e1111_config_init,
.config_aneg = &marvell_config_aneg,
- .read_status = &genphy_read_status,
+ .read_status = &marvell_read_status,
.ack_interrupt = &marvell_ack_interrupt,
.config_intr = &marvell_config_intr,
.driver = { .owner = THIS_MODULE },
^ permalink raw reply
* Re: [PATCH] Add support for binary includes.
From: Grant Likely @ 2008-02-22 15:50 UTC (permalink / raw)
To: David Woodhouse; +Cc: Scott Wood, linuxppc-dev, jdl
In-Reply-To: <1203670971.5771.41.camel@shinybook.infradead.org>
On Fri, Feb 22, 2008 at 2:02 AM, David Woodhouse <dwmw2@infradead.org> wrote:
>
> On Thu, 2008-02-21 at 23:05 -0700, Grant Likely wrote:
> > Can I ask; what is the intended usage of such a thing? How large
> > would a typical binary blob be?
>
> Device firmware?
That's what I was wondering about. Is this really a good idea?
Effectively, in the Linux kernel the device tree is being used as a
big blob of initdata, except that it cannot free the memory allocated
by the device tree when it is complete. As it is right now, device
trees seem to weigh in between 4-8kB, a pretty insignificant size for
memory that cannot be reclaimed. However, if firmware blobs start
getting added to the tree that size could balloon pretty quickly.
I'm not actually opposed to the feature, and I understand that it is
needed for the new u-boot image format, but I think we need some usage
guidelines in place when this feature is merged. As much as possible
I think we should be directing developers to use the existing firmware
loading facilities in the Linux kernel.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH] Add support for binary includes.
From: Scott Wood @ 2008-02-22 16:08 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, jdl
In-Reply-To: <fa686aa40802212205p38c3793bg8793740955b1e91@mail.gmail.com>
On Thu, Feb 21, 2008 at 11:05:58PM -0700, Grant Likely wrote:
> On Wed, Feb 20, 2008 at 12:19 PM, Scott Wood <scottwood@freescale.com> wrote:
> > A property's data can be populated with a file's contents
> > as follows:
> >
> > node {
> > prop = /incbin/("path/to/data");
> > };
> >
> > A subset of a file can be included by passing start and size parameters.
> > For example, to include bytes 8 through 23:
> >
> > node {
> > prop = /incbin/("path/to/data", 8, 16);
> > };
>
>
> Can I ask; what is the intended usage of such a thing? How large
> would a typical binary blob be?
I use it for embedding guest device trees in a hypervisor's device tree.
-Scott
^ permalink raw reply
* Re: [PATCH] Add support for binary includes.
From: Scott Wood @ 2008-02-22 16:28 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev
In-Reply-To: <E1JSahk-0003ub-Eh@jdl.com>
On Fri, Feb 22, 2008 at 10:24:56AM -0600, Jon Loeliger wrote:
> So, like, the other day Scott Wood mumbled:
> > >
> > > Can I ask; what is the intended usage of such a thing? How large
> > > would a typical binary blob be?
> >
> > I use it for embedding guest device trees in a hypervisor's device tree.
>
> Why wouldn't we instead, say, extend the source sytax
> to allow a sub-tree or an embedded tree, rather than
> obscuring an opaque form of that guest device tree?
That was what I tried initially, but the implementation was much more
complicated, and path references are problematic.
-Scott
^ permalink raw reply
* Re: MODPOST section mismatches
From: Steve Heflin @ 2008-02-22 16:12 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <20080221213313.97814DDF55@ozlabs.org>
To reproduce the problem and see the details on section mismatches:
make ARCH=powerpc sequoia_defconfig
make ARCH=powerpc CONFIG_DEBUG_SECTION_MISMATCH=y
At 04:33 PM 2/21/2008, Steve Heflin wrote:
>while building vmlinux.o the MODPOST warns about 8 section mismatches.
>WARNING: modpost: Found 8 section mismatch(es).
>To see full details build your kernel with:
>'make CONFIG_DEBUG_SECTION_MISMATCH=y'
>
>After modifying the make launch to include the recommended option
>shown above, I see that the section mismatch warning is due to data
>structures containing the address of initialization modules which
>have the __init attribute. Since the memory model is FLAT, is this a problem?
>
>thanks,
>Steve
>
>
>
>_______________________________________________
>Linuxppc-embedded mailing list
>Linuxppc-embedded@ozlabs.org
>https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* Re: Doubt in Device tree entry for USB on Powerpc based board
From: Scott Wood @ 2008-02-22 16:50 UTC (permalink / raw)
To: mahendra varman; +Cc: linux-kernel, linuxppc-embedded
In-Reply-To: <4ac2955e0802220533o3eba0e58ybb72326ab0e1a376@mail.gmail.com>
On Fri, Feb 22, 2008 at 07:03:07PM +0530, mahendra varman wrote:
> Please help me in the device tree where to give the device type
> compatibility address_cells size cells for the USB (since usb controller is
> in pci bridge i have some confusion in where to give the entry for usb)
You don't need to describe PCI devices in the device tree; they are
probed at runtime.
-Scott
^ permalink raw reply
* [PATCH] sata_fsl: fix build with ATA_VERBOSE_DEBUG
From: Anton Vorontsov @ 2008-02-22 16:54 UTC (permalink / raw)
To: Jeff Garzik; +Cc: linux-ide, linuxppc-dev
This patch fixes build and few warnings when ATA_VERBOSE_DEBUG
is defined:
CC drivers/ata/sata_fsl.o
drivers/ata/sata_fsl.c: In function ‘sata_fsl_fill_sg’:
drivers/ata/sata_fsl.c:338: warning: format ‘%x’ expects type ‘unsigned int’, but argument 3 has type ‘void *’
drivers/ata/sata_fsl.c:338: warning: format ‘%x’ expects type ‘unsigned int’, but argument 4 has type ‘struct prde *’
drivers/ata/sata_fsl.c: In function ‘sata_fsl_qc_issue’:
drivers/ata/sata_fsl.c:459: error: ‘csr_base’ undeclared (first use in this function)
drivers/ata/sata_fsl.c:459: error: (Each undeclared identifier is reported only once
drivers/ata/sata_fsl.c:459: error: for each function it appears in.)
drivers/ata/sata_fsl.c: In function ‘sata_fsl_freeze’:
drivers/ata/sata_fsl.c:525: error: ‘csr_base’ undeclared (first use in this function)
make[2]: *** [drivers/ata/sata_fsl.o] Error 1
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
drivers/ata/sata_fsl.c | 8 +++++---
1 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/ata/sata_fsl.c b/drivers/ata/sata_fsl.c
index 9ac36df..93789bf 100644
--- a/drivers/ata/sata_fsl.c
+++ b/drivers/ata/sata_fsl.c
@@ -335,7 +335,7 @@ static unsigned int sata_fsl_fill_sg(struct ata_queued_cmd *qc, void *cmd_desc,
dma_addr_t indirect_ext_segment_paddr;
unsigned int si;
- VPRINTK("SATA FSL : cd = 0x%x, prd = 0x%x\n", cmd_desc, prd);
+ VPRINTK("SATA FSL : cd = 0x%p, prd = 0x%p\n", cmd_desc, prd);
indirect_ext_segment_paddr = cmd_desc_paddr +
SATA_FSL_CMD_DESC_OFFSET_TO_PRDT + SATA_FSL_MAX_PRD_DIRECT * 16;
@@ -459,7 +459,8 @@ static unsigned int sata_fsl_qc_issue(struct ata_queued_cmd *qc)
VPRINTK("CE=0x%x, DE=0x%x, CC=0x%x, CmdStat = 0x%x\n",
ioread32(CE + hcr_base),
ioread32(DE + hcr_base),
- ioread32(CC + hcr_base), ioread32(COMMANDSTAT + csr_base));
+ ioread32(CC + hcr_base),
+ ioread32(COMMANDSTAT + host_priv->csr_base));
return 0;
}
@@ -522,7 +523,8 @@ static void sata_fsl_freeze(struct ata_port *ap)
ioread32(CQ + hcr_base),
ioread32(CA + hcr_base),
ioread32(CE + hcr_base), ioread32(DE + hcr_base));
- VPRINTK("CmdStat = 0x%x\n", ioread32(csr_base + COMMANDSTAT));
+ VPRINTK("CmdStat = 0x%x\n",
+ ioread32(host_priv->csr_base + COMMANDSTAT));
/* disable interrupts on the controller/port */
temp = ioread32(hcr_base + HCONTROL);
--
1.5.2.2
^ permalink raw reply related
* Re: [PATCH] Add support for binary includes.
From: Jon Loeliger @ 2008-02-22 16:24 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <20080222160820.GA19571@ld0162-tx32.am.freescale.net>
So, like, the other day Scott Wood mumbled:
> >
> > Can I ask; what is the intended usage of such a thing? How large
> > would a typical binary blob be?
>
> I use it for embedding guest device trees in a hypervisor's device tree.
Why wouldn't we instead, say, extend the source sytax
to allow a sub-tree or an embedded tree, rather than
obscuring an opaque form of that guest device tree?
Thanks,
jdl
^ 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