Re: Anyone have a PrPmc 280/2800 handy?
On Sat, Jan 19, 2013 at 08:59:18PM -0500, Paul Gortmaker wrote: On Thu, Jan 17, 2013 at 5:33 PM, Mark A. Greer mgr...@animalcreek.com wrote: Hello. I want to make some fixups to the marvell hostbridge and mpsc code and would like to test them on a PrPmc280/2800. The problem is, I don't have one anymore. Hi Mark, Hi Paul. Is there another platform that uses mpsc that can be used for testing? I ask because I did spend a lot of time with PrPMC-280 and motload/powerboot; some standalone, some on ATCA-F101. And with that hindsight, I can't help thinking that the right thing to do some eight years later is to simply consider removing the support for these old platforms. Would that make your validation easier? If so, then I'd recommend it. This is of course, just my opinion. Hmm, yeah, the c2k platform uses that bridge too. I'll see if I can find someone with one of those handy. Since nobody seems to have a prmpc280/2800 anymore, it does seem prudent to remove it. It would make validation easier for me in that its one less platform to worry about breaking. If I don't hear anything in the next few days, I'll make a patches to remove prpmc280/2800 support. Thanks, Mark -- ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Anyone have a PrPmc 280/2800 handy?
Hello. I want to make some fixups to the marvell hostbridge and mpsc code and would like to test them on a PrPmc280/2800. The problem is, I don't have one anymore. If you have one handy and don't mind running a quick boot test for me, please let me know. Thanks, Mark -- ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Reminder: removal of arch/ppc
On Fri, Jan 25, 2008 at 10:55:25AM -0600, Kumar Gala wrote: Just a reminder that the plan is to remove arch/ppc this summer (June 2008). The following boards still existing over in arch/ppc. Some of them have been ported over to arch/powerpc. If you care about one of these boards and its not ported speak up (it helps if you have access to the board). Also, if you know a given board is free to die of bitrot let us know so we know not to worry about it: I guess I'm just not a nice guy but I say let them die. No need to worry. The code really isn't going anywhere -- git-checkout v2.6.pick your favorite version and its back. /me's $0.02. Mark ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 4/4 v2] powerpc: Katana750i - Add platform support
On Thu, Jan 17, 2008 at 10:27:02AM +1100, Stephen Rothwell wrote:
Hi Mark,
On Wed, 16 Jan 2008 15:12:10 -0700 Mark A. Greer [EMAIL PROTECTED] wrote:
+static void __init katana750i_setup_arch(void)
+{
+ struct device_node *np;
+ phys_addr_t paddr;
+ const unsigned int *reg;
+
+ np = of_find_compatible_node(NULL, NULL, katana750i,cpld);
+ if (!np)
+ printk(KERN_WARNING No CPLD DT node; functionality reduced\n);
+ else {
+ reg = of_get_property(np, reg, NULL);
+ if (!reg)
+ printk(KERN_WARNING No CPLD reg property;
+ functionality reduced\n);
+ else {
+ paddr = of_translate_address(np, reg);
+ of_node_put(np);
+ cpld_base = ioremap(paddr, reg[1]);
+ }
+ }
You need an of_node_put(np) for the !reg case above. Maybe you should
just put it after the else clause instead of in it.
Erg, yes...duh.
Thanks again, Stephen.
Mark
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/4] powerpc: mv64x60 - Use early_* PCI accessors for hotswap reg
On Thu, Jan 17, 2008 at 09:48:59AM +1100, Benjamin Herrenschmidt wrote: On Mon, 2008-01-14 at 15:51 -0700, Mark A. Greer wrote: From: Mark A. Greer [EMAIL PROTECTED] The mv64x60 Hotswap register is on the first hose of the mv64x60 hostbridge. To access it, manually find the hose structure and use the early_* PCI accessor routines because the hostbridge is normally hidden. Can't we unhide the NB instead ? Hi Ben. Possibly but it may cause issues since many hostbridge have BARs that don't comply with the PCI spec which may get hosed when scanning the PCI bus. Maybe fixups/quirks/whatever will help but I'm not sure that's any cleaner. TBH, I'm not familiar enough with the PCI subsystem to answer this intelligently. Mark ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 3/4] powerpc: Katana750i - Add DTS file
On Thu, Jan 17, 2008 at 12:06:34PM +1100, David Gibson wrote:
On Wed, Jan 16, 2008 at 01:48:09PM -0700, Mark A. Greer wrote:
On Wed, Jan 16, 2008 at 11:22:28AM +1100, David Gibson wrote:
On Tue, Jan 15, 2008 at 12:08:06PM -0700, Mark A. Greer wrote:
On Tue, Jan 15, 2008 at 10:34:06AM +1100, David Gibson wrote:
On Mon, Jan 14, 2008 at 03:59:26PM -0700, Mark A. Greer wrote:
From: Mark A. Greer [EMAIL PROTECTED]
Hi David. Thanks for the review.
Add DTS file for the Emerson Katana 750i 752i platforms.
[snip]
+/dts-v1/;
+
+/ {
+ #address-cells = 1;
+ #size-cells = 1;
+ model = Katana-75xi; /* Default */
+ compatible = emerson,katana-750i;
+ coherency-off;
Where is this flag used from?
Its used in the bootwrapper if when you use the mv64x60 code to setup
some of the windows to the I/O ctlrs. This port does use that code
(because firmware doesn't do it properly) so I need the flag.
Hrm.. ok. I'm just wondering if a new flag is really the right
approach for this, or whether you should be basing the setup off the
compatible property, either for the board or for the main bridge.
I'd prefer to keep the flag. Otherwise, the bootwrapper will need a
table to look up the compatible field to see if coherency is supposed
to be on or off. We'd have to add an entry to that table for any
compatible that need coherency off, etc. A flag seems cleaner.
Hrm. Except that you already have such a table in the cuboot file,
adding another flag to that wouldn't be hard.
What piece of hardware is it that actually determines whether
coherency works or not? The CPU? The bridge?
The bridge + the platform. There's a hw erratum that some boards have
worked around and other haven't.
Spoze I can just code it in the cuboot file as you say.
I'll have to remove the sanity check in the kernel that ensures
that coherency-off CONFIG_NOT_COHERENT_CACHE match.
[snip]
+ CUNIT: [EMAIL PROTECTED] {
What is this device? It needs some sort of compatible value.
Does it? Its a separate block of regs but its only used in the mpsc
node--its never looked up on its own by kernel code. Do all nodes need
compatible even when it'll never be used? (Just want to know.)
Hrm.. if it's really just extra mpsc registers, should it be a
seperate device, or just another range in the mpsc's reg property?
Okay, putting into the reg property makes sense. Its values will be
put into both [EMAIL PROTECTED] 'reg' properties since its share. That
doesn't
matter, correct?
Ah, sorry, I forgot there were multiple mpscs. Their reg properties
certainly shouldn't overlap, so you will need a separate node.
Okay.
However, you could combine your several nodes with MPSC common
registers into a single mpsc-common (or something) block. That
would also reduce the number of phandles you need in the mpsc nodes,
too.
True, that will help.
Or possibly this should be arranged as for the multiethernet.
Do you mean putting sdma/brg/... as subnodes of the mpsc node?
I remember debating this way back when. IIRC, leaving them out seemed
like the right thing to do (tm). If you think that's better, I can do
that.
Also, would you mind letting it go thru as it is now and I'll make a
separate patch to change this dts, the prpmc2800.dts, and related code
afterwards?
Well, that's not really up to me.
Yeah, but paulus is looing to you to monitor bootwrapper stuff so... :)
[snip]
Yes :(. I've looked at this before, though obviously I never got to
figuring out what to do about it.
IMHO we need a way to change the default cmdline in the field so
sysadmins can change it per board and not have to type it in every time
they boot. /chosen/bootargs and __builtin_cmdline can both do that.
We don't need both, though. And, since bootargs is specified by OF
and documented in booting-without-of.txt, can we finally get rid of
__builtin_cmdline? I'd sure like to.
We can probably get rid of CONFIG_CMDLINE too since everyone uses DTs
now and they can have a /chosen/bootargs. Anyone have a reason to keep
CONFIG_CMDLINE around?
Would you mind elaborating on why you are opposed to /chosen/bootargs?
Just because it's nasty for people to have to go in and change the dts
just to change their default command line - which they might well want
to do for things as simple as setting a default root device.
Yeah, but changing CONFIG_CMDLINE requires a kernel rebuild so
that's not great either. Modifying __builtin_cmdline is probably the
easiest way to change things in the field (assuming you have a zImage)
but its also the least standard way of the three. :(
But since the device tree is built into the zImage, changing it there
will also require a rebuild.
Nope
Re: [PATCH 1/4] powerpc: mv64x60 - Use early_* PCI accessors for hotswap reg
On Tue, Jan 15, 2008 at 10:19:36AM +1100, Stephen Rothwell wrote:
Hi Mark,
Hi Stephen. Thanks for taking the time to review these patches.
On Mon, 14 Jan 2008 15:51:50 -0700 Mark A. Greer [EMAIL PROTECTED] wrote:
+static inline struct pci_controller *mv64x60_find_hose(u32 idx)
+{
+ struct device_node *phb;
+ struct pci_controller *hose;
+ const u32 *prop;
+ int len;
+
+ for_each_compatible_node(phb, pci, marvell,mv64360-pci) {
+ prop = of_get_property(phb, cell-index, len);
+ if (prop (len == sizeof(prop)) (*prop == idx)) {
+ hose = pci_find_hose_for_OF_device(phb);
+ of_node_put(phb);
+ return hose;
+ }
+ }
+
+ return NULL;
+}
I would think that this is way to big to inline ...
Yeah, I suppose. I'm not sure why I made it an inline, TBH. I'll make
it a real routine.
Mark
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/4] powerpc: mv64x60 - Use early_* PCI accessors for hotswap reg
On Tue, Jan 15, 2008 at 10:21:29AM +1100, Stephen Rothwell wrote: Hi Mark, On Mon, 14 Jan 2008 15:51:50 -0700 Mark A. Greer [EMAIL PROTECTED] wrote: +++ b/arch/powerpc/sysdev/mv64x60.h @@ -3,10 +3,32 @@ #include linux/init.h +#include asm/prom.h You probably meant to include linux/of.h here Umm, apparently... :) Mark ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 1/4] powerpc: mv64x60 - Use early_* PCI accessors for hotswap reg
From: Mark A. Greer [EMAIL PROTECTED]
The mv64x60 Hotswap register is on the first hose of the mv64x60
hostbridge. To access it, manually find the hose structure and
use the early_* PCI accessor routines because the hostbridge is
normally hidden.
Signed-off-by: Mark A. Greer [EMAIL PROTECTED]
---
arch/powerpc/sysdev/mv64x60.h | 22 ++
arch/powerpc/sysdev/mv64x60_pci.c | 25 +++--
2 files changed, 37 insertions(+), 10 deletions(-)
diff --git a/arch/powerpc/sysdev/mv64x60.h b/arch/powerpc/sysdev/mv64x60.h
index 4f618fa..27e22f4 100644
--- a/arch/powerpc/sysdev/mv64x60.h
+++ b/arch/powerpc/sysdev/mv64x60.h
@@ -3,10 +3,32 @@
#include linux/init.h
+#include asm/prom.h
+#include asm/pci-bridge.h
+
extern void __init mv64x60_init_irq(void);
extern unsigned int mv64x60_get_irq(void);
extern void __init mv64x60_pci_init(void);
extern void __init mv64x60_init_early(void);
+static inline struct pci_controller *mv64x60_find_hose(u32 idx)
+{
+ struct device_node *phb;
+ struct pci_controller *hose;
+ const u32 *prop;
+ int len;
+
+ for_each_compatible_node(phb, pci, marvell,mv64360-pci) {
+ prop = of_get_property(phb, cell-index, len);
+ if (prop (len == sizeof(prop)) (*prop == idx)) {
+ hose = pci_find_hose_for_OF_device(phb);
+ of_node_put(phb);
+ return hose;
+ }
+ }
+
+ return NULL;
+}
+
#endif /* __MV64X60_H__ */
diff --git a/arch/powerpc/sysdev/mv64x60_pci.c
b/arch/powerpc/sysdev/mv64x60_pci.c
index 1456015..2115177 100644
--- a/arch/powerpc/sysdev/mv64x60_pci.c
+++ b/arch/powerpc/sysdev/mv64x60_pci.c
@@ -17,6 +17,8 @@
#include asm/prom.h
#include asm/pci-bridge.h
+#include sysdev/mv64x60.h
+
#define PCI_HEADER_TYPE_INVALID0x7f/* Invalid PCI header
type */
#ifdef CONFIG_SYSFS
@@ -24,11 +26,12 @@
#define MV64X60_VAL_LEN_MAX11
#define MV64X60_PCICFG_CPCI_HOTSWAP0x68
+/* cPCI Hotswap register only supported on PCI 0 interface */
static ssize_t mv64x60_hs_reg_read(struct kobject *kobj,
struct bin_attribute *attr, char *buf,
loff_t off, size_t count)
{
- struct pci_dev *phb;
+ struct pci_controller *hose;
u32 v;
if (off 0)
@@ -36,11 +39,12 @@ static ssize_t mv64x60_hs_reg_read(struct kobject *kobj,
if (count MV64X60_VAL_LEN_MAX)
return -EINVAL;
- phb = pci_get_bus_and_slot(0, PCI_DEVFN(0, 0));
- if (!phb)
+ hose = mv64x60_find_hose(0);
+ if (!hose)
return -ENODEV;
- pci_read_config_dword(phb, MV64X60_PCICFG_CPCI_HOTSWAP, v);
- pci_dev_put(phb);
+
+ early_read_config_dword(hose, 0, PCI_DEVFN(0, 0),
+ MV64X60_PCICFG_CPCI_HOTSWAP, v);
return sprintf(buf, 0x%08x\n, v);
}
@@ -49,7 +53,7 @@ static ssize_t mv64x60_hs_reg_write(struct kobject *kobj,
struct bin_attribute *attr, char *buf,
loff_t off, size_t count)
{
- struct pci_dev *phb;
+ struct pci_controller *hose;
u32 v;
if (off 0)
@@ -60,11 +64,12 @@ static ssize_t mv64x60_hs_reg_write(struct kobject *kobj,
if (sscanf(buf, %i, v) != 1)
return -EINVAL;
- phb = pci_get_bus_and_slot(0, PCI_DEVFN(0, 0));
- if (!phb)
+ hose = mv64x60_find_hose(0);
+ if (!hose)
return -ENODEV;
- pci_write_config_dword(phb, MV64X60_PCICFG_CPCI_HOTSWAP, v);
- pci_dev_put(phb);
+
+ early_write_config_dword(hose, 0, PCI_DEVFN(0, 0),
+ MV64X60_PCICFG_CPCI_HOTSWAP, v);
return count;
}
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 4/4] powerpc: Katana750i - Add platform support
From: Mark A. Greer [EMAIL PROTECTED]
Add support for the Emerson Katana 750i 752i platforms.
Signed-off-by: Mark A. Greer [EMAIL PROTECTED]
---
This patch depends on 2 other patch series. This is the list of all the
patches in the two series (not all of them are actually required):
http://patchwork.ozlabs.org/linuxppc/patch?id=14397
http://patchwork.ozlabs.org/linuxppc/patch?id=14396
http://patchwork.ozlabs.org/linuxppc/patch?id=14631
http://patchwork.ozlabs.org/linuxppc/patch?id=14632
http://patchwork.ozlabs.org/linuxppc/patch?id=14633
http://patchwork.ozlabs.org/linuxppc/patch?id=15007
http://patchwork.ozlabs.org/linuxppc/patch?id=15453
http://patchwork.ozlabs.org/linuxppc/patch?id=15454
http://patchwork.ozlabs.org/linuxppc/patch?id=15455
http://patchwork.ozlabs.org/linuxppc/patch?id=15456
http://patchwork.ozlabs.org/linuxppc/patch?id=15457
http://patchwork.ozlabs.org/linuxppc/patch?id=15458
http://patchwork.ozlabs.org/linuxppc/patch?id=15459
http://patchwork.ozlabs.org/linuxppc/patch?id=15460
arch/powerpc/boot/Makefile |3
arch/powerpc/boot/cuboot-katana750i.c | 248 ++
arch/powerpc/configs/katana750i_defconfig | 1315 ++
arch/powerpc/platforms/embedded6xx/Kconfig | 10
arch/powerpc/platforms/embedded6xx/Makefile |1
arch/powerpc/platforms/embedded6xx/katana750i.c | 314 +++
6 files changed, 1890 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile
index d1e625c..b04ecc0 100644
--- a/arch/powerpc/boot/Makefile
+++ b/arch/powerpc/boot/Makefile
@@ -62,7 +62,7 @@ src-plat := of.c cuboot-52xx.c cuboot-83xx.c cuboot-85xx.c
holly.c \
ps3-head.S ps3-hvcall.S ps3.c treeboot-bamboo.c cuboot-8xx.c \
cuboot-pq2.c cuboot-sequoia.c treeboot-walnut.c cuboot-bamboo.c
\
fixed-head.S ep88xc.c cuboot-hpc2.c ep405.c cuboot-taishan.c \
- cuboot-katmai.c cuboot-rainier.c
+ cuboot-katmai.c cuboot-rainier.c cuboot-katana750i.c
src-boot := $(src-wlib) $(src-plat) empty.c
src-boot := $(addprefix $(obj)/, $(src-boot))
@@ -206,6 +206,7 @@ image-$(CONFIG_RAINIER) +=
cuImage.rainier
image-$(CONFIG_WALNUT) += treeImage.walnut
image-$(CONFIG_TAISHAN)+= cuImage.taishan
image-$(CONFIG_KATMAI) += cuImage.katmai
+image-$(CONFIG_PPC_KATANA750I) += cuImage.katana750i
endif
# For 32-bit powermacs, build the COFF and miboot images
diff --git a/arch/powerpc/boot/cuboot-katana750i.c
b/arch/powerpc/boot/cuboot-katana750i.c
new file mode 100644
index 000..41d4105
--- /dev/null
+++ b/arch/powerpc/boot/cuboot-katana750i.c
@@ -0,0 +1,248 @@
+/*
+ * Emerson Katana-750i/752i
+ *
+ * Author: Mark A. Greer [EMAIL PROTECTED]
+ *
+ * 2007 (c) MontaVista, Software, Inc. This file is licensed under
+ * the terms of the GNU General Public License version 2. This program
+ * is licensed as is without any warranty of any kind, whether express
+ * or implied.
+ */
+
+#include stdio.h
+#include io.h
+#include ops.h
+#include cuboot.h
+#include ppcboot.h
+#include mv64x60.h
+
+static u8 *bridge_base;
+static u8 *cpld_base;
+static bd_t bd;
+
+#define KATANA750I_CPLD_RST_CMD0x1000
+#define KATANA750I_CPLD_RST_CMD_HR 0x01
+
+#define KATANA750I_CPLD_PRODUCT_ID 0x4000
+#defineKATANA750I_PRODUCT_ID_750I 0x02
+#defineKATANA750I_PRODUCT_ID_752I 0x04
+
+#define KATANA750I_CPLD_BD_CFG_0 0x9000
+#define KATANA750I_CPLD_BD_CFG_0_SYSCLK_MASK 0xc0
+#define KATANA750I_CPLD_BD_CFG_0_SYSCLK_2000x00
+#define KATANA750I_CPLD_BD_CFG_0_SYSCLK_1660x80
+#define KATANA750I_CPLD_BD_CFG_0_SYSCLK_1330xc0
+#define KATANA750I_CPLD_BD_CFG_0_SYSCLK_1000x40
+
+#define BOARD_MODEL_MAX32
+
+typedef enum {
+ BOARD_TYPE_750I,
+ BOARD_TYPE_752I,
+} katana750i_board_type;
+
+struct katana750i_board_info {
+ charcpld_prod_id;
+ char*model;
+ char*bridge_type;
+};
+
+static struct katana750i_board_info katana750i_board_info[] = {
+ [BOARD_TYPE_750I] = {
+ .cpld_prod_id = KATANA750I_PRODUCT_ID_750I,
+ .model = Katana-750i,
+ .bridge_type= mv64360,
+ },
+ [BOARD_TYPE_752I] = {
+ .cpld_prod_id = KATANA750I_PRODUCT_ID_752I,
+ .model = Katana-752i,
+ .bridge_type= mv64460,
+ },
+};
+
+static struct katana750i_board_info *katana750i_get_bip(void)
+{
+ struct katana750i_board_info *bip;
+ int i;
+ u8 id;
+
+ id = in_8(cpld_base + KATANA750I_CPLD_PRODUCT_ID);
+
+ for (i = 0, bip = katana750i_board_info;
+ i ARRAY_SIZE(katana750i_board_info); i++, bip++)
+ if (bip-cpld_prod_id == id)
+ return bip
[PATCH 3/4] powerpc: Katana750i - Add DTS file
From: Mark A. Greer [EMAIL PROTECTED]
Add DTS file for the Emerson Katana 750i 752i platforms.
Signed-off-by: Mark A. Greer [EMAIL PROTECTED]
---
arch/powerpc/boot/dts/katana750i.dts | 372 +
1 file changed, 372 insertions(+)
diff --git a/arch/powerpc/boot/dts/katana750i.dts
b/arch/powerpc/boot/dts/katana750i.dts
new file mode 100644
index 000..03d9fd1
--- /dev/null
+++ b/arch/powerpc/boot/dts/katana750i.dts
@@ -0,0 +1,372 @@
+/* Device Tree Source for Emerson Katana 750i/752i
+ *
+ * Author: Mark A. Greer [EMAIL PROTECTED]
+ *
+ * 2007 (c) MontaVista, Software, Inc. This file is licensed under
+ * the terms of the GNU General Public License version 2. This program
+ * is licensed as is without any warranty of any kind, whether express
+ * or implied.
+ *
+ * Property values that are labeled as Default will be updated by bootwrapper
+ * if it can determine the exact PrPMC type.
+ */
+
+/dts-v1/;
+
+/ {
+ #address-cells = 1;
+ #size-cells = 1;
+ model = Katana-75xi; /* Default */
+ compatible = emerson,katana-750i;
+ coherency-off;
+
+ cpus {
+ #address-cells = 1;
+ #size-cells = 0;
+
+ PowerPC,750 {
+ device_type = cpu;
+ reg = 0;
+ clock-frequency = 7; /* Default */
+ bus-frequency = 1;/* Default */
+ timebase-frequency = ;/* Default */
+ i-cache-line-size = 0x20;
+ d-cache-line-size = 0x20;
+ i-cache-size = 0x8000;
+ d-cache-size = 0x8000;
+ };
+ };
+
+ memory {
+ device_type = memory;
+ reg = 0x 0x0400; /* Default (64MB) */
+ };
+
+ [EMAIL PROTECTED] { /* Marvell Discovery */
+ #address-cells = 1;
+ #size-cells = 1;
+ model = mv64360; /* Default */
+ compatible = marvell,mv64360;
+ clock-frequency = 1;
+ hs_reg_valid;
+ reg = 0xf810 0x0001;
+ virtual-reg = 0xf810;
+ ranges = 0xb000 0xb000 0x0400 /* PCI 1 I/O Space */
+ 0x8000 0x8000 0x3000 /* PCI 1 MEM Space */
+ 0xe800 0xe800 0x1000 /* User FLASH */
+ 0x 0xf810 0x0001 /* Bridge's regs */
+ 0xf808 0xf808 0x0001 /* PCI 0 I/O Space */
+ 0xf809 0xf809 0x0001 /* PCI 0 MEM Space */
+ 0xf820 0xf820 0x0020 /* CPLD HSL Regs */
+ 0xf830 0xf830 0x0004;/* Integrated SRAM*/
+
+ [EMAIL PROTECTED] {
+ compatible = katana750i,cpld;
+ reg = 0xf820 0x0020;
+ virtual-reg = 0xf820;
+ };
+
+ [EMAIL PROTECTED] {
+ #address-cells = 1;
+ #size-cells = 1;
+ compatible = cfi-flash;
+ bank-width = 4;
+ device-width = 2;
+ reg = 0xe800 0x0400;
+ [EMAIL PROTECTED] {
+ label = Monitor;
+ reg = 0x 0x0010;
+ };
+ [EMAIL PROTECTED] {
+ label = Primary Kernel;
+ reg = 0x0010 0x0018;
+ };
+ [EMAIL PROTECTED] {
+ label = Primary Filesystem;
+ reg = 0x0028 0x01e0;
+ };
+ [EMAIL PROTECTED] {
+ label = Secondary Kernel;
+ reg = 0x0208 0x0018;
+ };
+ [EMAIL PROTECTED] {
+ label = Secondary Filesystem;
+ reg = 0x0220 0x01e0;
+ };
+ [EMAIL PROTECTED] { /* overlay all but monitor */
+ label = User FLASH;
+ reg = 0x0010 0x03f0;
+ };
+ };
+
+ mdio {
+ #address-cells = 1;
+ #size-cells = 0;
+ device_type = mdio;
+ compatible = marvell,mv64360-mdio;
+ PHY0: [EMAIL PROTECTED] {
+ device_type = ethernet-phy;
+ compatible = broadcom
[PATCH v2] powerpc: #address-cells #size-cells properties not inherited
From: Mark A. Greer [EMAIL PROTECTED] Fix error in booting-without-of.txt that indicates that a node can inherit its #address-cells and #size-cells definitions from its parent's parent. This is not correct. Signed-off-by: Mark A. Greer [EMAIL PROTECTED] --- Documentation/powerpc/booting-without-of.txt |8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/Documentation/powerpc/booting-without-of.txt b/Documentation/powerpc/booting-without-of.txt index ee0209a..58db5ea 100644 --- a/Documentation/powerpc/booting-without-of.txt +++ b/Documentation/powerpc/booting-without-of.txt @@ -671,10 +671,10 @@ device or bus to be described by the device tree. In general, the format of an address for a device is defined by the parent bus type, based on the #address-cells and #size-cells -property. In the absence of such a property, the parent's parent -values are used, etc... The kernel requires the root node to have -those properties defining addresses format for devices directly mapped -on the processor bus. +properties. Note that the parent's parent definitions of #address-cells +and #size-cells are not inhereted so every node with children must specify +them. The kernel requires the root node to have those properties defining +addresses format for devices directly mapped on the processor bus. Those 2 properties define 'cells' for representing an address and a size. A cell is a 32-bit number. For example, if both contain 2 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: #address-cells #size-cells properties not inherited
On Wed, Jan 02, 2008 at 07:46:40PM -0600, Josh Boyer wrote: On Wed, 2 Jan 2008 17:07:50 -0700 Mark A. Greer [EMAIL PROTECTED] wrote: From: Mark A. Greer [EMAIL PROTECTED] Fix error in booting-without-of.txt that indicates that a node can inherit its #address-cells and #size-cells definitions from its parent's parent. This is not correct and the latest dtc enforces it. I'm lazy so I haven't checked myself, but by latest dtc does that mean the DTC that's in the kernel now? Things are going to be fun when we start saying generic things like latest DTC. And when upstream DTC gets new features or enforcements, we'll have to have all the in-kernel DTS files patched up when that version of DTC gets merged in-kernel. Just something to keep in mind as we move along. Yeah, I thought about that last night, actually. I think I'll just change that sentence to This is not correct. Avoid the issue :) Mark ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] powerpc: #address-cells #size-cells properties not inherited
From: Mark A. Greer [EMAIL PROTECTED] Fix error in booting-without-of.txt that indicates that a node can inherit its #address-cells and #size-cells definitions from its parent's parent. This is not correct and the latest dtc enforces it. Signed-off-by: Mark A. Greer [EMAIL PROTECTED] --- Documentation/powerpc/booting-without-of.txt |8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/Documentation/powerpc/booting-without-of.txt b/Documentation/powerpc/booting-without-of.txt index ee0209a..58db5ea 100644 --- a/Documentation/powerpc/booting-without-of.txt +++ b/Documentation/powerpc/booting-without-of.txt @@ -671,10 +671,10 @@ device or bus to be described by the device tree. In general, the format of an address for a device is defined by the parent bus type, based on the #address-cells and #size-cells -property. In the absence of such a property, the parent's parent -values are used, etc... The kernel requires the root node to have -those properties defining addresses format for devices directly mapped -on the processor bus. +properties. Note that the parent's parent definitions of #address-cells +and #size-cells are not inhereted so every node with children must specify +them. The kernel requires the root node to have those properties defining +addresses format for devices directly mapped on the processor bus. Those 2 properties define 'cells' for representing an address and a size. A cell is a 32-bit number. For example, if both contain 2 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/8] powerpc: prpmc2800 - Convert dts file to v1
On Sat, Dec 15, 2007 at 09:03:35AM +1100, David Gibson wrote:
On Mon, Dec 10, 2007 at 05:37:38PM -0700, Mark A. Greer wrote:
From: Mark A. Greer [EMAIL PROTECTED]
Convert the prpmc2800.dts file to dts-v1. Basically, this means
converting the numeric constants to be 'C'-like (e.g., hexadecimal
numbers start with '0x').
[snip]
interrupt-parent = /mv64x60/pic;
If you're converting to dts-v1, you should also convert any path
references like this to {/mv64x60/pic} or else use a label. Yes,
some early dts-v1 supporting dtc versions supported these as is, but
the idea is to try to forget that they existed and always require the
{} quoting in dts-v1.
I did convert to use labels in a later patch but it uses label as
well. I can change them to {label} that it appears you are suggesting
(I haven't tested to see that they work yet though).
Mark
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/5] PowerPC 74xx: Minor updates to MV64x60 boot code
On Thu, Nov 29, 2007 at 06:35:55PM +0300, Andrei Dolnikov wrote:
Hi Andrei. I have a few comments below.
This patch adds new functionality to MV64x60 boot code. The changes are
required
to access DevCS windows registers and set PCI bus and devfn numbers for
MV644x60
PCI/PCI-X interfaces.
Signed-off-by: Andrei Dolnikov [EMAIL PROTECTED]
---
mv64x60.c | 74
++
mv64x60.h | 10
2 files changed, 84 insertions(+)
diff --git a/arch/powerpc/boot/mv64x60.c b/arch/powerpc/boot/mv64x60.c
index d207a0b..787a124 100644
--- a/arch/powerpc/boot/mv64x60.c
+++ b/arch/powerpc/boot/mv64x60.c
@@ -32,6 +32,16 @@
#define MV64x60_CPU2MEM_3_BASE 0x0218
#define MV64x60_CPU2MEM_3_SIZE 0x0220
+#define MV64x60_DEV2MEM_WINDOWS 4
+#define MV64x60_DEV2MEM_0_BASE 0x0028
+#define MV64x60_DEV2MEM_0_SIZE 0x0030
+#define MV64x60_DEV2MEM_1_BASE 0x0228
+#define MV64x60_DEV2MEM_1_SIZE 0x0230
+#define MV64x60_DEV2MEM_2_BASE 0x0248
+#define MV64x60_DEV2MEM_2_SIZE 0x0250
+#define MV64x60_DEV2MEM_3_BASE 0x0038
+#define MV64x60_DEV2MEM_3_SIZE 0x0040
+
These aren't device-memory windows, they're CPU-device windows so
they should be named MV64x60_CPU2DEV_xxx to be consistent with the
previously established naming convention.
#define MV64x60_ENET2MEM_BAR_ENABLE 0x2290
#define MV64x60_ENET2MEM_0_BASE 0x2200
#define MV64x60_ENET2MEM_0_SIZE 0x2204
@@ -219,6 +229,25 @@ static struct mv64x60_mem_win
mv64x60_cpu2mem[MV64x60_CPU2MEM_WINDOWS] = {
},
};
+static struct mv64x60_mem_win mv64x60_devcs[MV64x60_DEV2MEM_WINDOWS] = {
Why not call this mv64x60_cpu2dev[]?
snip
@@ -586,6 +645,21 @@ u32 mv64x60_get_mem_size(u8 *bridge_base)
return mem;
}
+/* Read a size of DEV_CS window */
+u32 mv64x60_get_devcs_size(u8 *bridge_base, u32 devcs)
u32 mv64x60_get_cpu2dev_size(...)
snip
diff --git a/arch/powerpc/boot/mv64x60.h b/arch/powerpc/boot/mv64x60.h
index d0b29a7..a633d2e 100644
--- a/arch/powerpc/boot/mv64x60.h
+++ b/arch/powerpc/boot/mv64x60.h
@@ -12,6 +12,14 @@
#define MV64x60_CPU_BAR_ENABLE 0x0278
+#define MV64x60_PCI0_MODE0x0d00
+#define MV64x60_PCI1_MODE0x0d80
+#define MV64x60_PCI0_P2P_CONF0x1d14
+#define MV64x60_PCI1_P2P_CONF0x1d94
+
+#define MV64x60_PCI_MODE_MASK0x0030
+#define MV64x60_PCI_CONVENTIONAL_MODE0x
+
AFAICS these macros are only used in mv64x60.c so just put them there.
They only need to go in mv64x60.h if they're used in more than one .c
file.
Mark
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 3/5] PowerPC 74xx: Katana Qp bootwrapper
On Thu, Nov 29, 2007 at 06:39:51PM +0300, Andrei Dolnikov wrote:
Bootwrapper sources for Emerson Katana Qp
Signed-off-by: Andrei Dolnikov [EMAIL PROTECTED]
---
Makefile |3
cuboot-katanaqp.c | 470
++
2 files changed, 472 insertions(+), 1 deletion(-)
snip
diff --git a/arch/powerpc/boot/cuboot-katanaqp.c
b/arch/powerpc/boot/cuboot-katanaqp.c
new file mode 100644
index 000..19ba901
--- /dev/null
+++ b/arch/powerpc/boot/cuboot-katanaqp.c
@@ -0,0 +1,470 @@
snip
+ /* Get the cpu - pci i/o mem mappings from the device tree */
+ devp = finddevice(/mv64x60);
+ if (devp == NULL)
+ fatal(Error: Missing /mv64x60 device tree node\n\r);
+
+
+ enables = in_le32((u32 *) (bridge_base + MV64x60_CPU_BAR_ENABLE));
+ enables |= 0x0007fe00; /* Disable all cpu-pci windows */
+ out_le32((u32 *) (bridge_base + MV64x60_CPU_BAR_ENABLE), enables);
+
+ for (i = 0; i 12; i += 6) {
+ switch (v[i] 0xff00) {
+ case 0x0100:/* PCI I/O Space */
+ tbl = mv64x60_cpu2pci_io;
+ break;
+ case 0x0200:/* PCI MEM Space */
+ tbl = mv64x60_cpu2pci_mem;
+ break;
+ default:
+ continue;
+ }
+
+ pci_base_hi = v[i + 1];
+ pci_base_lo = v[i + 2];
+ cpu_base = v[i + 3];
+ size = v[i + 5];
+
+ buf[0] = cpu_base;
+ buf[1] = size;
+
+ if (!dt_xlate_addr(devp, buf, sizeof(buf), cpu_base))
+ fatal(Error: Can't translate PCI address 0x%x\n\r,
+ (u32) cpu_base);
+
+ mv64x60_config_cpu2pci_window(bridge_base, 1, pci_base_hi,
+ pci_base_lo, cpu_base, size, tbl);
+ }
Looks like we could factor out some of this code that's the same here
and in prpmc2800.c. I can do that later, though.
snip
+void platform_init(unsigned long r3, unsigned long r4, unsigned long r5,
+unsigned long r6, unsigned long r7)
+{
+
+ CUBOOT_INIT();
+
+ if (ft_init(_dtb_start, _dtb_end - _dtb_start, 16))
+ exit();
This should be replaced by fdt_init(dtb) now.
snip
Mark
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 4/5] PowerPC 74xx: Katana Qp base support
On Thu, Nov 29, 2007 at 06:42:00PM +0300, Andrei Dolnikov wrote: Emerson Katana Qp platform specific code Signed-off-by: Andrei Dolnikov [EMAIL PROTECTED] Acked-by: Mark A. Greer [EMAIL PROTECTED] ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/5] PowerPC 74xx: Katana Qp device tree
On Sat, Dec 08, 2007 at 12:33:09PM +1100, David Gibson wrote: On Thu, Dec 06, 2007 at 04:27:56PM -0700, Mark A. Greer wrote: David, et. al., This is a big blob patch of what I've changed for the prpmc2800. It includes the necessary changes in the kernel which you can probably ignore but they're there for reference. If you like the dts, then I'll split the blob up into logical pieces and Andrei can make similar changes for the Katana Qp. Let me know what you think. Looks pretty reasonable. I would have preferred that labels be uppercase by convention, to make them easier to pick out by eyeball, but I think that's a lost cause at this stage. I can do that. Thanks for the feedback. I'll break the blob up into pieces and submit with the labels in uppercase. Thanks, Mark ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 0/8] powerpc: mv64x60/prpmc2800 - DTS updates, etc.
This is the broken out patch series that equates to the big blob patch (with minor modifications) that was sent here: http://patchwork.ozlabs.org/linuxppc/patch?id=15382 These patches depend on the following patches to apply cleanly: http://patchwork.ozlabs.org/linuxppc/patch?id=14397 http://patchwork.ozlabs.org/linuxppc/patch?id=14396 http://patchwork.ozlabs.org/linuxppc/patch?id=14631 http://patchwork.ozlabs.org/linuxppc/patch?id=14632 http://patchwork.ozlabs.org/linuxppc/patch?id=14633 http://patchwork.ozlabs.org/linuxppc/patch?id=15007 Please let me know if you have any issues with these patches. Thanks, Mark ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 1/8] powerpc: prpmc2800 - Convert dts file to v1
From: Mark A. Greer [EMAIL PROTECTED]
Convert the prpmc2800.dts file to dts-v1. Basically, this means
converting the numeric constants to be 'C'-like (e.g., hexadecimal
numbers start with '0x').
Signed-off-by: Mark A. Greer [EMAIL PROTECTED]
---
arch/powerpc/boot/dts/prpmc2800.dts | 188 +-
1 file changed, 96 insertions(+), 92 deletions(-)
diff --git a/arch/powerpc/boot/dts/prpmc2800.dts
b/arch/powerpc/boot/dts/prpmc2800.dts
index 24944ca..15247a4 100644
--- a/arch/powerpc/boot/dts/prpmc2800.dts
+++ b/arch/powerpc/boot/dts/prpmc2800.dts
@@ -11,6 +11,8 @@
* if it can determine the exact PrPMC type.
*/
+/dts-v1/;
+
/ {
#address-cells = 1;
#size-cells = 1;
@@ -25,64 +27,64 @@
PowerPC,7447 {
device_type = cpu;
reg = 0;
- clock-frequency = 2bb0b140; /* Default (733 MHz) */
- bus-frequency = 7f28155; /* 133.33 MHz */
- timebase-frequency = 1fca055; /* 33.33 MHz */
- i-cache-line-size = 20;
- d-cache-line-size = 20;
- i-cache-size = 8000;
- d-cache-size = 8000;
+ clock-frequency = 7; /* Default */
+ bus-frequency = 1;
+ timebase-frequency = ;
+ i-cache-line-size = 0x20;
+ d-cache-line-size = 0x20;
+ i-cache-size = 0x8000;
+ d-cache-size = 0x8000;
};
};
memory {
device_type = memory;
- reg = 2000; /* Default (512MB) */
+ reg = 0x 0x2000; /* Default (512MB) */
};
[EMAIL PROTECTED] { /* Marvell Discovery */
#address-cells = 1;
#size-cells = 1;
model = mv64360; /* Default */
- compatible = marvell,mv64x60;
- clock-frequency = 7f28155;/* 133.33 MHz */
- reg = f100 0001;
- virtual-reg = f100;
- ranges = 8800 8800 0100/* PCI 0 I/O Space */
- 8000 8000 0800/* PCI 0 MEM Space */
- a000 a000 0400/* User FLASH */
- f100 0001/* Bridge's regs */
- f200 f200 0004; /* Integrated SRAM */
+ compatible = marvell,mv64360;
+ clock-frequency = 1;
+ reg = 0xf100 0x0001;
+ virtual-reg = 0xf100;
+ ranges = 0x8800 0x8800 0x0100 /* PCI 0 I/O Space */
+ 0x8000 0x8000 0x0800 /* PCI 0 MEM Space */
+ 0xa000 0xa000 0x0400 /* User FLASH */
+ 0x 0xf100 0x0001 /* Bridge's regs */
+ 0xf200 0xf200 0x0004;/* Integrated SRAM*/
[EMAIL PROTECTED] {
compatible = cfi-flash;
- reg = a000 0400;
+ reg = 0xa000 0x0400;
bank-width = 4;
device-width = 2;
#address-cells = 1;
#size-cells = 1;
[EMAIL PROTECTED] {
label = FW Image A;
- reg = 0010;
+ reg = 0x 0x0010;
read-only;
};
[EMAIL PROTECTED] {
label = FW Config Data; /* RW */
- reg = 0010 0004;
+ reg = 0x0010 0x0004;
};
[EMAIL PROTECTED] {
label = Kernel Image;
- reg = 0014 0040;
+ reg = 0x0014 0x0040;
read-only;
};
[EMAIL PROTECTED] {
label = Filesystem;
- reg = 0054 039c;
+ reg = 0x0054 0x039c;
read-only;
};
[EMAIL PROTECTED] {
label = FW Image B;
- reg = 03f0 0010;
+ reg = 0x03f0 0x0010;
read-only;
};
};
@@ -95,26 +97,26
[PATCH 2/8] powerpc: prpmc2800 - Add labels to dts file
From: Mark A. Greer [EMAIL PROTECTED]
Add use labels for dts nodes that are referenced in the prpmc2800.dts
file to improve readability.
Signed-off-by: Mark A. Greer [EMAIL PROTECTED]
---
arch/powerpc/boot/dts/prpmc2800.dts | 104 +-
1 file changed, 52 insertions(+), 52 deletions(-)
diff --git a/arch/powerpc/boot/dts/prpmc2800.dts
b/arch/powerpc/boot/dts/prpmc2800.dts
index 15247a4..1657ee6 100644
--- a/arch/powerpc/boot/dts/prpmc2800.dts
+++ b/arch/powerpc/boot/dts/prpmc2800.dts
@@ -94,18 +94,18 @@
#size-cells = 0;
device_type = mdio;
compatible = marvell,mv64x60-mdio;
- [EMAIL PROTECTED] {
+ PHY0: [EMAIL PROTECTED] {
device_type = ethernet-phy;
compatible = broadcom,bcm5421;
interrupts = 76; /* GPP 12 */
- interrupt-parent = /mv64x60/pic;
+ interrupt-parent = PIC;
reg = 1;
};
- [EMAIL PROTECTED] {
+ PHY1: [EMAIL PROTECTED] {
device_type = ethernet-phy;
compatible = broadcom,bcm5421;
interrupts = 76; /* GPP 12 */
- interrupt-parent = /mv64x60/pic;
+ interrupt-parent = PIC;
reg = 3;
};
};
@@ -117,8 +117,8 @@
compatible = marvell,mv64x60-eth;
block-index = 0;
interrupts = 32;
- interrupt-parent = /mv64x60/pic;
- phy = /mv64x60/mdio/[EMAIL PROTECTED];
+ interrupt-parent = PIC;
+ phy = PHY0;
local-mac-address = [ 00 00 00 00 00 00 ];
};
eth1 {
@@ -126,33 +126,33 @@
compatible = marvell,mv64x60-eth;
block-index = 1;
interrupts = 33;
- interrupt-parent = /mv64x60/pic;
- phy = /mv64x60/mdio/[EMAIL PROTECTED];
+ interrupt-parent = PIC;
+ phy = PHY1;
local-mac-address = [ 00 00 00 00 00 00 ];
};
};
- [EMAIL PROTECTED] {
+ SDMA0: [EMAIL PROTECTED] {
device_type = dma;
compatible = marvell,mv64x60-sdma;
reg = 0x4000 0xc18;
virtual-reg = 0xf1004000;
interrupt-base = 0;
interrupts = 36;
- interrupt-parent = /mv64x60/pic;
+ interrupt-parent = PIC;
};
- [EMAIL PROTECTED] {
+ SDMA1: [EMAIL PROTECTED] {
device_type = dma;
compatible = marvell,mv64x60-sdma;
reg = 0x6000 0xc18;
virtual-reg = 0xf1006000;
interrupt-base = 0;
interrupts = 38;
- interrupt-parent = /mv64x60/pic;
+ interrupt-parent = PIC;
};
- [EMAIL PROTECTED] {
+ BRG0: [EMAIL PROTECTED] {
compatible = marvell,mv64x60-brg;
reg = 0xb200 0x8;
clock-src = 8;
@@ -161,7 +161,7 @@
bcr = 0;
};
- [EMAIL PROTECTED] {
+ BRG1: [EMAIL PROTECTED] {
compatible = marvell,mv64x60-brg;
reg = 0xb208 0x8;
clock-src = 8;
@@ -170,15 +170,15 @@
bcr = 0;
};
- [EMAIL PROTECTED] {
+ CUNIT: [EMAIL PROTECTED] {
reg = 0xf200 0x200;
};
- [EMAIL PROTECTED] {
+ MPSCROUTING: [EMAIL PROTECTED] {
reg = 0xb400 0xc;
};
- [EMAIL PROTECTED] {
+ MPSCINTR: [EMAIL PROTECTED] {
reg = 0xb800 0x100;
virtual-reg = 0xf100b800;
};
@@ -188,11 +188,11 @@
compatible = marvell,mpsc;
reg = 0x8000 0x38;
virtual-reg = 0xf1008000;
- sdma = /mv64x60/[EMAIL
[PATCH 3/8] powerpc: mv64x60 - Replace marvell, mv64x60 with marvell, mv64360
From: Mark A. Greer [EMAIL PROTECTED]
Compatible property names like marvell,mv64x60... are not acceptable
so replace them with name like marvell,mv64360...
Signed-off-by: Mark A. Greer [EMAIL PROTECTED]
---
arch/powerpc/boot/dts/prpmc2800.dts| 34 +++
arch/powerpc/platforms/embedded6xx/prpmc2800.c |4 -
arch/powerpc/sysdev/mv64x60_dev.c |6 +-
arch/powerpc/sysdev/mv64x60_pci.c |6 +-
arch/powerpc/sysdev/mv64x60_pic.c |4 -
5 files changed, 27 insertions(+), 27 deletions(-)
diff --git a/arch/powerpc/boot/dts/prpmc2800.dts
b/arch/powerpc/boot/dts/prpmc2800.dts
index 1657ee6..a4a3622 100644
--- a/arch/powerpc/boot/dts/prpmc2800.dts
+++ b/arch/powerpc/boot/dts/prpmc2800.dts
@@ -93,7 +93,7 @@
#address-cells = 1;
#size-cells = 0;
device_type = mdio;
- compatible = marvell,mv64x60-mdio;
+ compatible = marvell,mv64360-mdio;
PHY0: [EMAIL PROTECTED] {
device_type = ethernet-phy;
compatible = broadcom,bcm5421;
@@ -114,7 +114,7 @@
reg = 0x2000 0x2000;
eth0 {
device_type = network;
- compatible = marvell,mv64x60-eth;
+ compatible = marvell,mv64360-eth;
block-index = 0;
interrupts = 32;
interrupt-parent = PIC;
@@ -123,7 +123,7 @@
};
eth1 {
device_type = network;
- compatible = marvell,mv64x60-eth;
+ compatible = marvell,mv64360-eth;
block-index = 1;
interrupts = 33;
interrupt-parent = PIC;
@@ -134,7 +134,7 @@
SDMA0: [EMAIL PROTECTED] {
device_type = dma;
- compatible = marvell,mv64x60-sdma;
+ compatible = marvell,mv64360-sdma;
reg = 0x4000 0xc18;
virtual-reg = 0xf1004000;
interrupt-base = 0;
@@ -144,7 +144,7 @@
SDMA1: [EMAIL PROTECTED] {
device_type = dma;
- compatible = marvell,mv64x60-sdma;
+ compatible = marvell,mv64360-sdma;
reg = 0x6000 0xc18;
virtual-reg = 0xf1006000;
interrupt-base = 0;
@@ -153,7 +153,7 @@
};
BRG0: [EMAIL PROTECTED] {
- compatible = marvell,mv64x60-brg;
+ compatible = marvell,mv64360-brg;
reg = 0xb200 0x8;
clock-src = 8;
clock-frequency = 13300;
@@ -162,7 +162,7 @@
};
BRG1: [EMAIL PROTECTED] {
- compatible = marvell,mv64x60-brg;
+ compatible = marvell,mv64360-brg;
reg = 0xb208 0x8;
clock-src = 8;
clock-frequency = 13300;
@@ -224,14 +224,14 @@
};
[EMAIL PROTECTED] { /* watchdog timer */
- compatible = marvell,mv64x60-wdt;
+ compatible = marvell,mv64360-wdt;
reg = 0xb410 0x8;
timeout = 10; /* wdt timeout in seconds */
};
[EMAIL PROTECTED] {
device_type = i2c;
- compatible = marvell,mv64x60-i2c;
+ compatible = marvell,mv64360-i2c;
reg = 0xc000 0x20;
virtual-reg = 0xf100c000;
freq_m = 8;
@@ -245,18 +245,18 @@
PIC: pic {
#interrupt-cells = 1;
#address-cells = 0;
- compatible = marvell,mv64x60-pic;
+ compatible = marvell,mv64360-pic;
reg = 0x 0x88;
interrupt-controller;
};
[EMAIL PROTECTED] {
- compatible = marvell,mv64x60-mpp;
+ compatible = marvell,mv64360-mpp;
reg = 0xf000 0x10;
};
[EMAIL PROTECTED] {
- compatible = marvell,mv64x60-gpp;
+ compatible = marvell,mv64360-gpp;
reg = 0xf100 0x20;
};
@@ -265,7 +265,7 @@
#size
[PATCH 4/8] powerpc: mv64x60 - Update ethernet DTS nodes
From: Mark A. Greer [EMAIL PROTECTED]
DTS entries for mv64360 ethernet controllers should use 'reg' property
instead of the 'block-index' property. Also, use 'multiethernet'
instead of 'ethernet' for parent node and use '[EMAIL PROTECTED]' instead of
'eth?' for subnodes.
Signed-off-by: Mark A. Greer [EMAIL PROTECTED]
---
arch/powerpc/boot/dts/prpmc2800.dts | 10 +-
arch/powerpc/sysdev/mv64x60_dev.c |2 +-
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/arch/powerpc/boot/dts/prpmc2800.dts
b/arch/powerpc/boot/dts/prpmc2800.dts
index a4a3622..1447faa 100644
--- a/arch/powerpc/boot/dts/prpmc2800.dts
+++ b/arch/powerpc/boot/dts/prpmc2800.dts
@@ -110,21 +110,21 @@
};
};
- [EMAIL PROTECTED] {
+ [EMAIL PROTECTED] {
reg = 0x2000 0x2000;
- eth0 {
+ [EMAIL PROTECTED] {
device_type = network;
compatible = marvell,mv64360-eth;
- block-index = 0;
+ reg = 0;
interrupts = 32;
interrupt-parent = PIC;
phy = PHY0;
local-mac-address = [ 00 00 00 00 00 00 ];
};
- eth1 {
+ [EMAIL PROTECTED] {
device_type = network;
compatible = marvell,mv64360-eth;
- block-index = 1;
+ reg = 1;
interrupts = 33;
interrupt-parent = PIC;
phy = PHY1;
diff --git a/arch/powerpc/sysdev/mv64x60_dev.c
b/arch/powerpc/sysdev/mv64x60_dev.c
index dca205f..20cd5e3 100644
--- a/arch/powerpc/sysdev/mv64x60_dev.c
+++ b/arch/powerpc/sysdev/mv64x60_dev.c
@@ -248,7 +248,7 @@ static int __init mv64x60_eth_device_setup(struct
device_node *np, int id)
memset(pdata, 0, sizeof(pdata));
- prop = of_get_property(np, block-index, NULL);
+ prop = of_get_property(np, reg, NULL);
if (!prop)
return -ENODEV;
pdata.port_number = *prop;
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 5/8] powerpc: MPSC - Update DTS entries
From: Mark A. Greer [EMAIL PROTECTED]
MPSC DTS nodes should use 'cell-index' to distinguish between MPSC
controllers (just like all the other DTS files). Also, rename the
compatible property from 'marvell,mpsc' to 'marvell,mv64360-mpsc'
for consistency.
Signed-off-by: Mark A. Greer [EMAIL PROTECTED]
---
arch/powerpc/boot/dts/prpmc2800.dts |8
arch/powerpc/boot/mpsc.c|2 +-
arch/powerpc/boot/serial.c |2 +-
arch/powerpc/sysdev/mv64x60_dev.c |8
arch/powerpc/sysdev/mv64x60_udbg.c |4 ++--
5 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/arch/powerpc/boot/dts/prpmc2800.dts
b/arch/powerpc/boot/dts/prpmc2800.dts
index 1447faa..e670e3f 100644
--- a/arch/powerpc/boot/dts/prpmc2800.dts
+++ b/arch/powerpc/boot/dts/prpmc2800.dts
@@ -185,7 +185,7 @@
[EMAIL PROTECTED] {
device_type = serial;
- compatible = marvell,mpsc;
+ compatible = marvell,mv64360-mpsc;
reg = 0x8000 0x38;
virtual-reg = 0xf1008000;
sdma = SDMA0;
@@ -193,7 +193,7 @@
cunit = CUNIT;
mpscrouting = MPSCROUTING;
mpscintr = MPSCINTR;
- block-index = 0;
+ cell-index = 0;
max_idle = 40;
chr_1 = 0;
chr_2 = 0;
@@ -205,7 +205,7 @@
[EMAIL PROTECTED] {
device_type = serial;
- compatible = marvell,mpsc;
+ compatible = marvell,mv64360-mpsc;
reg = 0x9000 0x38;
virtual-reg = 0xf1009000;
sdma = SDMA1;
@@ -213,7 +213,7 @@
cunit = CUNIT;
mpscrouting = MPSCROUTING;
mpscintr = MPSCINTR;
- block-index = 1;
+ cell-index = 1;
max_idle = 40;
chr_1 = 0;
chr_2 = 0;
diff --git a/arch/powerpc/boot/mpsc.c b/arch/powerpc/boot/mpsc.c
index 802ea53..425ad88 100644
--- a/arch/powerpc/boot/mpsc.c
+++ b/arch/powerpc/boot/mpsc.c
@@ -141,7 +141,7 @@ int mpsc_console_init(void *devp, struct
serial_console_data *scdp)
if (mpscintr_base == NULL)
goto err_out;
- n = getprop(devp, block-index, v, sizeof(v));
+ n = getprop(devp, cell-index, v, sizeof(v));
if (n != sizeof(v))
goto err_out;
reg_set = (int)v;
diff --git a/arch/powerpc/boot/serial.c b/arch/powerpc/boot/serial.c
index cafeece..cbcbb20 100644
--- a/arch/powerpc/boot/serial.c
+++ b/arch/powerpc/boot/serial.c
@@ -119,7 +119,7 @@ int serial_console_init(void)
if (dt_is_compatible(devp, ns16550))
rc = ns16550_console_init(devp, serial_cd);
- else if (dt_is_compatible(devp, marvell,mpsc))
+ else if (dt_is_compatible(devp, marvell,mv64360-mpsc))
rc = mpsc_console_init(devp, serial_cd);
else if (dt_is_compatible(devp, fsl,cpm1-scc-uart) ||
dt_is_compatible(devp, fsl,cpm1-smc-uart) ||
diff --git a/arch/powerpc/sysdev/mv64x60_dev.c
b/arch/powerpc/sysdev/mv64x60_dev.c
index 20cd5e3..587c40f 100644
--- a/arch/powerpc/sysdev/mv64x60_dev.c
+++ b/arch/powerpc/sysdev/mv64x60_dev.c
@@ -127,7 +127,7 @@ static int __init mv64x60_mpsc_device_setup(struct
device_node *np, int id)
if (err)
return err;
- prop = of_get_property(np, block-index, NULL);
+ prop = of_get_property(np, cell-index, NULL);
if (!prop)
return -ENODEV;
port_number = *(int *)prop;
@@ -452,7 +452,7 @@ static int __init mv64x60_device_setup(void)
int err;
id = 0;
- for_each_compatible_node(np, serial, marvell,mpsc)
+ for_each_compatible_node(np, serial, marvell,mv64360-mpsc)
if ((err = mv64x60_mpsc_device_setup(np, id++)))
goto error;
@@ -495,10 +495,10 @@ static int __init mv64x60_add_mpsc_console(void)
if (!np)
goto not_mpsc;
- if (!of_device_is_compatible(np, marvell,mpsc))
+ if (!of_device_is_compatible(np, marvell,mv64360-mpsc))
goto not_mpsc;
- prop = of_get_property(np, block-index, NULL);
+ prop = of_get_property(np, cell-index, NULL);
if (!prop)
goto not_mpsc;
diff --git a/arch/powerpc/sysdev/mv64x60_udbg.c
b/arch/powerpc/sysdev/mv64x60_udbg.c
index 35c77c7..2792dc8 100644
--- a/arch/powerpc/sysdev/mv64x60_udbg.c
+++ b/arch/powerpc/sysdev/mv64x60_udbg.c
@@ -85,7 +85,7 @@ static void mv64x60_udbg_init(void)
if (!stdout)
return;
- for_each_compatible_node(np, serial, marvell,mpsc
[PATCH 6/8] powerpc: mv64x60 - Update i2c DTS properties
From: Mark A. Greer [EMAIL PROTECTED] DTS files should not specify the default timeout value for the mv64360 i2c controller. Also, remove deprecated 'retries' property. Signed-off-by: Mark A. Greer [EMAIL PROTECTED] --- FYI, the 'retries' property use and related platform_data will be removed in a patch that is working its way through the i2c community. arch/powerpc/boot/dts/prpmc2800.dts |2 -- arch/powerpc/sysdev/mv64x60_dev.c |6 +- 2 files changed, 1 insertion(+), 7 deletions(-) diff --git a/arch/powerpc/boot/dts/prpmc2800.dts b/arch/powerpc/boot/dts/prpmc2800.dts index e670e3f..b608e6c 100644 --- a/arch/powerpc/boot/dts/prpmc2800.dts +++ b/arch/powerpc/boot/dts/prpmc2800.dts @@ -236,8 +236,6 @@ virtual-reg = 0xf100c000; freq_m = 8; freq_n = 3; - timeout = 1000; /* 1000 = 1 second */ - retries = 1; interrupts = 37; interrupt-parent = PIC; }; diff --git a/arch/powerpc/sysdev/mv64x60_dev.c b/arch/powerpc/sysdev/mv64x60_dev.c index 587c40f..e0244d8 100644 --- a/arch/powerpc/sysdev/mv64x60_dev.c +++ b/arch/powerpc/sysdev/mv64x60_dev.c @@ -355,11 +355,7 @@ static int __init mv64x60_i2c_device_setup(struct device_node *np, int id) return -ENODEV; pdata.freq_n = *prop; - prop = of_get_property(np, timeout, NULL); - if (prop) - pdata.timeout = *prop; - else - pdata.timeout = 1000; /* 1 second */ + pdata.timeout = 1000; /* 1 second */ prop = of_get_property(np, retries, NULL); if (prop) ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 7/8] powerpc: mv64x60 - Remove timeout property for WDT
From: Mark A. Greer [EMAIL PROTECTED]
Remove support for the DTS timeout property that's currently there for
the watchdog timer on mv64x60 hostbridges. The platform_data remains
and can be modified by platform-specific code when necessary.
Signed-off-by: Mark A. Greer [EMAIL PROTECTED]
---
arch/powerpc/boot/dts/prpmc2800.dts |1 -
arch/powerpc/sysdev/mv64x60_dev.c |5 +
2 files changed, 1 insertion(+), 5 deletions(-)
diff --git a/arch/powerpc/boot/dts/prpmc2800.dts
b/arch/powerpc/boot/dts/prpmc2800.dts
index b608e6c..054f028 100644
--- a/arch/powerpc/boot/dts/prpmc2800.dts
+++ b/arch/powerpc/boot/dts/prpmc2800.dts
@@ -226,7 +226,6 @@
[EMAIL PROTECTED] { /* watchdog timer */
compatible = marvell,mv64360-wdt;
reg = 0xb410 0x8;
- timeout = 10; /* wdt timeout in seconds */
};
[EMAIL PROTECTED] {
diff --git a/arch/powerpc/sysdev/mv64x60_dev.c
b/arch/powerpc/sysdev/mv64x60_dev.c
index e0244d8..f998330 100644
--- a/arch/powerpc/sysdev/mv64x60_dev.c
+++ b/arch/powerpc/sysdev/mv64x60_dev.c
@@ -403,10 +403,7 @@ static int __init mv64x60_wdt_device_setup(struct
device_node *np, int id)
memset(pdata, 0, sizeof(pdata));
- prop = of_get_property(np, timeout, NULL);
- if (!prop)
- return -ENODEV;
- pdata.timeout = *prop;
+ pdata.timeout = 10; /* Default: 10 seconds */
np = of_get_parent(np);
if (!np)
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 8/8] powerpc: prpmc2800 - Miscellaneous DTS file fixups
From: Mark A. Greer [EMAIL PROTECTED]
Remove unnecessary device_type properties and leading zeroes in node names.
Signed-off-by: Mark A. Greer [EMAIL PROTECTED]
---
arch/powerpc/boot/dts/prpmc2800.dts |6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/boot/dts/prpmc2800.dts
b/arch/powerpc/boot/dts/prpmc2800.dts
index 054f028..6af5a3a 100644
--- a/arch/powerpc/boot/dts/prpmc2800.dts
+++ b/arch/powerpc/boot/dts/prpmc2800.dts
@@ -133,7 +133,6 @@
};
SDMA0: [EMAIL PROTECTED] {
- device_type = dma;
compatible = marvell,mv64360-sdma;
reg = 0x4000 0xc18;
virtual-reg = 0xf1004000;
@@ -143,7 +142,6 @@
};
SDMA1: [EMAIL PROTECTED] {
- device_type = dma;
compatible = marvell,mv64360-sdma;
reg = 0x6000 0xc18;
virtual-reg = 0xf1006000;
@@ -300,14 +298,14 @@
;
};
- [EMAIL PROTECTED] {
+ [EMAIL PROTECTED] {
compatible = marvell,mv64360-cpu-error;
reg = 0x0070 0x10 0x0128 0x28;
interrupts = 3;
interrupt-parent = PIC;
};
- [EMAIL PROTECTED] {
+ [EMAIL PROTECTED] {
compatible = marvell,mv64360-sram-ctrl;
reg = 0x0380 0x80;
interrupts = 13;
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/5] PowerPC 74xx: Katana Qp device tree
David, et. al.,
This is a big blob patch of what I've changed for the prpmc2800. It
includes the necessary changes in the kernel which you can probably
ignore but they're there for reference. If you like the dts, then I'll
split the blob up into logical pieces and Andrei can make similar
changes for the Katana Qp.
Let me know what you think.
Mark
---
This patch is based on the latest powerpc.git tree
(44032af0e7d5467b12f998dbf2f1cd23c5324fd5) with the following patches
applied:
http://patchwork.ozlabs.org/linuxppc/patch?id=14339
http://patchwork.ozlabs.org/linuxppc/patch?id=14397
http://patchwork.ozlabs.org/linuxppc/patch?id=14396
http://patchwork.ozlabs.org/linuxppc/patch?id=14631
http://patchwork.ozlabs.org/linuxppc/patch?id=14632
http://patchwork.ozlabs.org/linuxppc/patch?id=14633
http://patchwork.ozlabs.org/linuxppc/patch?id=15007
arch/powerpc/boot/dts/prpmc2800.dts| 320 +++
arch/powerpc/boot/mpsc.c |2
arch/powerpc/boot/serial.c |2
arch/powerpc/platforms/embedded6xx/prpmc2800.c |4
arch/powerpc/sysdev/mv64x60_dev.c | 29 -
arch/powerpc/sysdev/mv64x60_pci.c |6
arch/powerpc/sysdev/mv64x60_pic.c |4
arch/powerpc/sysdev/mv64x60_udbg.c |4
8 files changed, 181 insertions(+), 190 deletions(-)
diff --git a/arch/powerpc/boot/dts/prpmc2800.dts
b/arch/powerpc/boot/dts/prpmc2800.dts
index 24944ca..080130e 100644
--- a/arch/powerpc/boot/dts/prpmc2800.dts
+++ b/arch/powerpc/boot/dts/prpmc2800.dts
@@ -11,6 +11,8 @@
* if it can determine the exact PrPMC type.
*/
+/dts-v1/;
+
/ {
#address-cells = 1;
#size-cells = 1;
@@ -25,64 +27,64 @@
PowerPC,7447 {
device_type = cpu;
reg = 0;
- clock-frequency = 2bb0b140; /* Default (733 MHz) */
- bus-frequency = 7f28155; /* 133.33 MHz */
- timebase-frequency = 1fca055; /* 33.33 MHz */
- i-cache-line-size = 20;
- d-cache-line-size = 20;
- i-cache-size = 8000;
- d-cache-size = 8000;
+ clock-frequency = 7; /* Default */
+ bus-frequency = 1;
+ timebase-frequency = ;
+ i-cache-line-size = 0x20;
+ d-cache-line-size = 0x20;
+ i-cache-size = 0x8000;
+ d-cache-size = 0x8000;
};
};
memory {
device_type = memory;
- reg = 2000; /* Default (512MB) */
+ reg = 0x 0x2000; /* Default (512MB) */
};
[EMAIL PROTECTED] { /* Marvell Discovery */
#address-cells = 1;
#size-cells = 1;
model = mv64360; /* Default */
- compatible = marvell,mv64x60;
- clock-frequency = 7f28155;/* 133.33 MHz */
- reg = f100 0001;
- virtual-reg = f100;
- ranges = 8800 8800 0100/* PCI 0 I/O Space */
- 8000 8000 0800/* PCI 0 MEM Space */
- a000 a000 0400/* User FLASH */
- f100 0001/* Bridge's regs */
- f200 f200 0004; /* Integrated SRAM */
+ compatible = marvell,mv64360;
+ clock-frequency = 1;
+ reg = 0xf100 0x0001;
+ virtual-reg = 0xf100;
+ ranges = 0x8800 0x8800 0x0100 /* PCI 0 I/O Space */
+ 0x8000 0x8000 0x0800 /* PCI 0 MEM Space */
+ 0xa000 0xa000 0x0400 /* User FLASH */
+ 0x 0xf100 0x0001 /* Bridge's regs */
+ 0xf200 0xf200 0x0004;/* Integrated SRAM*/
[EMAIL PROTECTED] {
compatible = cfi-flash;
- reg = a000 0400;
+ reg = 0xa000 0x0400;
bank-width = 4;
device-width = 2;
#address-cells = 1;
#size-cells = 1;
[EMAIL PROTECTED] {
label = FW Image A;
- reg = 0010;
+ reg = 0x 0x0010;
read-only;
};
[EMAIL PROTECTED] {
label = FW Config Data; /* RW */
- reg
Re: [PATCH 1/5] PowerPC 74xx: Katana Qp device tree
On Tue, Dec 04, 2007 at 08:28:57PM +0300, Andrei Dolnikov wrote: Mark A. Greer wrote: On Tue, Dec 04, 2007 at 07:52:50AM +1100, Benjamin Herrenschmidt wrote: #address-cells = 1; + #size-cells = 1; + model = Katana-Qp; /* Default */ + compatible = emerson,Katana-Qp; + coherency-off; + What do that mean (coherency-off) ? Somebody is trying again to use a 74xx with non cache coherent DMA ? Hi Ben. I suspect Andrei got that from the prpmc2800 dts which I made so I'll jump in. (BTW, this is the same debate we have every year or two. :) By looking at the dts, that board has an mv64460 which has a couple issues when it comes to coherency (depending on the rev of the chip). One is about not being able to use DCBST instructions with coherency on and the other is about limiting the length of one of the traces (which at least one board manufacturer that I know of refuses to implement). The first one is supposed to be fixed by rev A1 of the part and the second is supposed to be fixed by rev B0 of the part. I don't know what rev(s) are on the board(s) Andrei is using. If its B0 or later, in theory, the part should work with coherency on. Andrei, have you tested with coherency on? Yes, I tested it with coherency on, but it didn't work. I checked chip revisions on all boards I have and they all are = mv64_4_60 B0. FWIW, this is consistent with what I see. Mark ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 5/7] powerpc: Replace ppc_md.power_off with pm_power_off
On Tue, Dec 04, 2007 at 06:23:09PM +1100, Benjamin Herrenschmidt wrote: On Mon, 2007-12-03 at 22:48 -0700, Mark A. Greer wrote: From: Mark A. Greer [EMAIL PROTECTED] The ppc_md.power_off hook performs the same function that the pm_power_off hook is supposed to. However, it is powerpc-specific and prevents kernel drivers (e.g., IPMI) from changing how a platform is powered off. So, get rid of ppc_md.power_off and replace it with pm_power_off. I'm less happy with that one... probably aesthetics :-) Can't we just have the generic code call pm_power_off and ppc_md and which ever powers the machine off wins ? Yes, that would be easy to do. Seems like duplication though. If you are sure you're okay with the duplication, I'll do that. Mark ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 5/7] powerpc: Replace ppc_md.power_off with pm_power_off
On Tue, Dec 04, 2007 at 01:05:46PM -0700, Grant Likely wrote: On 12/4/07, Benjamin Herrenschmidt [EMAIL PROTECTED] wrote: On Tue, 2007-12-04 at 11:01 -0700, Mark A. Greer wrote: On Tue, Dec 04, 2007 at 06:23:09PM +1100, Benjamin Herrenschmidt wrote: On Mon, 2007-12-03 at 22:48 -0700, Mark A. Greer wrote: From: Mark A. Greer [EMAIL PROTECTED] The ppc_md.power_off hook performs the same function that the pm_power_off hook is supposed to. However, it is powerpc-specific and prevents kernel drivers (e.g., IPMI) from changing how a platform is powered off. So, get rid of ppc_md.power_off and replace it with pm_power_off. I'm less happy with that one... probably aesthetics :-) Can't we just have the generic code call pm_power_off and ppc_md and which ever powers the machine off wins ? Yes, that would be easy to do. Seems like duplication though. If you are sure you're okay with the duplication, I'll do that. Let's ask Paulus what he thinks. We could simply have the setup code copy the ppc_md.power_off pointer into pm_power_off; that we retain the nice assignment in define_machine(), but eliminate the duplicated calls. Hmm, yeah, that would look nice--nicer than what I have. The only issue I have with it is that we still have duplication and potential for reassigning the wrong one (e.g., reassigning ppc_md.power_off instead of pm_power_off in maple/setup.c:maple_use_rtas_reboot_and_halt_if_present()). We could call both in machine_power_off but that's messy too (IMHO). Paul, do you have an opinion? Mark ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/5] PowerPC 74xx: Katana Qp device tree
On Tue, Dec 04, 2007 at 07:52:50AM +1100, Benjamin Herrenschmidt wrote: #address-cells = 1; + #size-cells = 1; + model = Katana-Qp; /* Default */ + compatible = emerson,Katana-Qp; + coherency-off; + What do that mean (coherency-off) ? Somebody is trying again to use a 74xx with non cache coherent DMA ? Hi Ben. I suspect Andrei got that from the prpmc2800 dts which I made so I'll jump in. (BTW, this is the same debate we have every year or two. :) By looking at the dts, that board has an mv64460 which has a couple issues when it comes to coherency (depending on the rev of the chip). One is about not being able to use DCBST instructions with coherency on and the other is about limiting the length of one of the traces (which at least one board manufacturer that I know of refuses to implement). The first one is supposed to be fixed by rev A1 of the part and the second is supposed to be fixed by rev B0 of the part. I don't know what rev(s) are on the board(s) Andrei is using. If its B0 or later, in theory, the part should work with coherency on. Andrei, have you tested with coherency on? -- As far as the prpmc2800 (mv64360)... [I don't know what an NDA let's me say or not so I'll just give summaries of the errata. If you or another reader has signed the NDA you/they can look them up.] I don't recall all of the details anymore but these are the errata I saw by quickly scanning the 64360's list. - FEr CPU-#1: Basically the CPU could read a stale cache line. Supposed to be fixed in rev A2 B0 but I haven't verified. - FEr MPSC-#1: The MPSC can't access a coherent memory region. This is pretty much a show stopper for the prpmc2800. There are no plans to fix that erratum. - FEr PCI-#4 (Detailed by Application Note AN-84): [This isn't strictly a coherency issue but having coherency enabled exacerbates the problem.] Basically, the bridge can let the cpu read a pci device's registers before all of the data the PCI devices has written has actually made it to memory. This and the fact that the device's write data may be stuck in the PCI Slave Write Buffer (which isn't checked for coherency), the cpu can get stale data. There are no plans to fix that erratum. - FEr PCI-#5 (Detailed by Application Note AN-85): With certain PCI devices and with coherency enabled, some combinations of PCI transactions can cause a deadlock. There is a workaround documented but I've tried it and it didn't work for me (but I can't be sure that was the erratum I was bumping into). There are no plans to fix that erratum. -- So, the answer depends on what part what rev of the part you have (e.g., the pegasos doesn't use the MPSC and apparently has the other issues worked around so it can turn on coherency but the prpmc2800 doesn't so it needs coherency off). BTW, I haven't forgotten the inherent bug you described when coherency is off (/me too lazy to find link to the email) but AFAIK I've never run into it. However, if I turn on coherency and stress the PCI bus, it hangs (I can't even look at memory thru a bdi). Mark ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 4/5] PowerPC 74xx: Katana Qp base support
On Tue, Dec 04, 2007 at 07:54:59AM +1100, Benjamin Herrenschmidt wrote: On Thu, 2007-11-29 at 18:42 +0300, Andrei Dolnikov wrote: +config PPC_KATANAQP + bool Emerson-Katana Qp + depends on EMBEDDED6xx + select MV64X60 + select NOT_COHERENT_CACHE ^^ Just one word: ARG ! Oh and another one: WHY ? I responded to your other email regarding this. Mark ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/5] PowerPC 74xx: Katana Qp device tree
On Mon, Dec 03, 2007 at 12:50:18PM +1100, David Gibson wrote:
On Thu, Nov 29, 2007 at 06:28:36PM +0300, Andrei Dolnikov wrote:
Device tree source file for the Emerson Katana Qp board
Signed-off-by: Andrei Dolnikov [EMAIL PROTECTED]
---
katanaqp.dts | 360
+++
1 files changed, 360 insertions(+)
diff --git a/arch/powerpc/boot/dts/katanaqp.dts
b/arch/powerpc/boot/dts/katanaqp.dts
new file mode 100644
index 000..98257a2
--- /dev/null
+++ b/arch/powerpc/boot/dts/katanaqp.dts
@@ -0,0 +1,360 @@
+/* Device Tree Source for Emerson Katana Qp
+ *
+ * Authors: Vladislav Buzov [EMAIL PROTECTED]
+ * Andrei Dolnikov [EMAIL PROTECTED]
+ *
+ * Based on prpmc8200.dts by Mark A. Greer [EMAIL PROTECTED]
+ *
+ * 2007 (c) MontaVista, Software, Inc. This file is licensed under
+ * the terms of the GNU General Public License version 2. This program
+ * is licensed as is without any warranty of any kind, whether express
+ * or implied.
+ *
+ */
+
+/ {
+ #address-cells = 1;
+ #size-cells = 1;
+ model = Katana-Qp; /* Default */
+ compatible = emerson,Katana-Qp;
+ coherency-off;
What is this property for?
Its needed to tell the bootwrapper that the platform does not have
coherency enabled (since our policy is that you can't use a CONFIG_ option).
The bootwrapper needs to know that if/when it sets up the windows for
its I/O devices (e.g., enet, mpsc) to system memory. I needed to do
this on the prpmc2800 because the firmware didn't set up those windows
correctly. I don't know if the Katana Qp's firmware sets the up
correctly or not.
+ [EMAIL PROTECTED] { /* Marvell Discovery */
+ #address-cells = 1;
+ #size-cells = 1;
+ model = mv64460; /* Default */
+ compatible = marvell,mv64x60;
Compatible properties should not have x asn in 64x60 here. If
there's a suitable name for the general register interface use that,
otherwise use the specific model number of the earliest device to
implement this register interface. Later models should have a
compatible property which lists their specific model, followed by the
earlier model number with which they're compatible.
This came from the prpmc2800's dts which has become out-of-date.
Both dts files need to be updated.
+ [EMAIL PROTECTED] {
+ reg = 2000 2000;
Are the registers for the 3 ethernets really all together? This bank
can't be subdivided into seperate register blocks for each MAC?
Unfortunately there are some registers that are shared so you can't
divide them up nicely.
+ eth0 {
+ device_type = network;
+ compatible = marvell,mv64x60-eth;
+ block-index = 0;
This block-index thing is crap. If you really need to subindex nodes
like this, use reg, with an appropriate #address-cells in the
parent, then the nodes will also get sensible unit addresses.
So how would that work for the PHY Address Register 0x2000, say,
where bits 0-4 set the device addr for PHY 0; bits 5-9 set the device
addr for PHY 1; bts 10-14 set the devce addr for PHY 2?
+ interrupts = 20;
+ interrupt-parent = /mv64x60/pic;
You should use a label for the PIC to make things more readable.
More that needs to be updated in prpmc2800. :(
+ [EMAIL PROTECTED] {
+ compatible = marvell,mv64x60-sdma;
+ reg = 4000 c18;
+ virtual-reg = f8104000;
Why does this node have virtual-reg?
virtual-reg is a special property that doesn't get translated thru
the parent mappings. It should never be used in the kernel. Its
purpose is to give code in the bootwrapper the exact address that it
should use to access a register or block of registers or ...
Its needed here because the MPSC (serial) driver uses the SDMA unit
to perform console I/O in the bootwrapper (e.g., cmdline editing, printf's).
Yes, this needs to be documented.
+ [EMAIL PROTECTED] {
+ device_type = serial;
+ compatible = marvell,mpsc;
+ reg = 8000 38;
+ virtual-reg = f8108000;
+ sdma = /mv64x60/[EMAIL PROTECTED];
+ brg = /mv64x60/[EMAIL PROTECTED];
+ cunit = /mv64x60/[EMAIL PROTECTED];
+ mpscrouting = /mv64x60/[EMAIL PROTECTED];
+ mpscintr = /mv64x60/[EMAIL PROTECTED];
+ block-index = 0;
What is this block-index thing about here? Since the devices are
disambiguated by their register address, why do you need it?
This particular one is needed to access the correct MPSC interrupt reg.
Maybe it would be better to make a new property
Re: [PATCH 1/5] PowerPC 74xx: Katana Qp device tree
On Tue, Dec 04, 2007 at 01:50:32PM +1100, David Gibson wrote:
On Mon, Dec 03, 2007 at 07:10:26PM -0700, Mark A. Greer wrote:
On Mon, Dec 03, 2007 at 12:50:18PM +1100, David Gibson wrote:
On Thu, Nov 29, 2007 at 06:28:36PM +0300, Andrei Dolnikov wrote:
+ eth0 {
+ device_type = network;
+ compatible = marvell,mv64x60-eth;
+ block-index = 0;
This block-index thing is crap. If you really need to subindex nodes
like this, use reg, with an appropriate #address-cells in the
parent, then the nodes will also get sensible unit addresses.
So how would that work for the PHY Address Register 0x2000, say,
where bits 0-4 set the device addr for PHY 0; bits 5-9 set the device
addr for PHY 1; bts 10-14 set the devce addr for PHY 2?
So use 'reg' to do the indexing. As long as you have no 'ranges'
property in the parent 'ethernet' node, which you don't, you can use
'reg' as a private index. That's basically what non-translatable reg
values are about.
Incidentally you should probably call the subnodes [EMAIL PROTECTED]
etc. and the parent one multiethernet or something. It's the
subnodes that represent an individual ethernet interface, so they
should take the ethernet name and not the parent, by generic names
conventions.
Okay, thanks for the advice. I'll fix the prpmc2800 dts file.
Presumably Andrei will fix his.
[snip]
+ [EMAIL PROTECTED] {
+ compatible = marvell,mv64x60-sdma;
+ reg = 4000 c18;
+ virtual-reg = f8104000;
Why does this node have virtual-reg?
virtual-reg is a special property that doesn't get translated thru
the parent mappings. It should never be used in the kernel. Its
purpose is to give code in the bootwrapper the exact address that it
should use to access a register or block of registers or ...
Its needed here because the MPSC (serial) driver uses the SDMA unit
to perform console I/O in the bootwrapper (e.g., cmdline editing, printf's).
Yes, this needs to be documented.
Ok. it's used for serial in the bootwrapper would have sufficed - I
questioned it because it wasn't obvious that this was needed to use
the mpsc.
Sorry :)
+ [EMAIL PROTECTED] {
+ device_type = serial;
+ compatible = marvell,mpsc;
+ reg = 8000 38;
+ virtual-reg = f8108000;
+ sdma = /mv64x60/[EMAIL PROTECTED];
+ brg = /mv64x60/[EMAIL PROTECTED];
+ cunit = /mv64x60/[EMAIL PROTECTED];
+ mpscrouting = /mv64x60/[EMAIL PROTECTED];
+ mpscintr = /mv64x60/[EMAIL PROTECTED];
+ block-index = 0;
What is this block-index thing about here? Since the devices are
disambiguated by their register address, why do you need it?
This particular one is needed to access the correct MPSC interrupt reg.
Maybe it would be better to make a new property for this but it was only
one reg and block-index was already there and basically served that
purpose so I used it. I'd be happy to use an alternative if you have
something you think is better.
No, that's an acceptable use for something like this, except that
cell-index seems to be the name we've standardised on for other
similar cases.
Yeah, I realize that but block-index was here first!
More seriously, I don't like cell because it isn't a cell, its a
block or an instance or an...I dunno but its not a cell IMHO.
Anyway, I'll think about changing it to cell but I already feel
dirty just thinking about it.
Mark
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/5] PowerPC 74xx: Katana Qp device tree
On Tue, Dec 04, 2007 at 01:14:43PM +1100, Benjamin Herrenschmidt wrote: .../... (snip scary bunch of errata) - FEr PCI-#4 (Detailed by Application Note AN-84): [This isn't strictly a coherency issue but having coherency enabled exacerbates the problem.] Basically, the bridge can let the cpu read a pci device's registers before all of the data the PCI devices has written has actually made it to memory. This and the fact that the device's write data may be stuck in the PCI Slave Write Buffer (which isn't checked for coherency), the cpu can get stale data. There are no plans to fix that erratum. So if I understand correctly, there's no plan to fix a major PCI spec violation which prevent any kind of reliable implementation whatsoever ? That's just for that particular part (e.g., 64360). Newer parts like the 64460 have it fixed. So, the answer depends on what part what rev of the part you have (e.g., the pegasos doesn't use the MPSC and apparently has the other issues worked around so it can turn on coherency but the prpmc2800 doesn't so it needs coherency off). BTW, I haven't forgotten the inherent bug you described when coherency is off (/me too lazy to find link to the email) but AFAIK I've never run into it. However, if I turn on coherency and stress the PCI bus, it hangs (I can't even look at memory thru a bdi). Well, as it is today, the classic MMU code cannot deal with !coherent. The entire linear mapping is always mapped cacheable with BATs, so stuff may be brought into the cache at any time, potentially polluting DMA data. Dealing with that would be hard. It might be possible by using G on the entire linear mapping like we do on 4xx (yuck), and/or by not using D-BATs (the kernel will blow up in various areas without I-BATs). Hrm, I didn't realize it was in such bad shape. I'll have to take a closer look. Mark ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[RFC 0/7] powerpc: Rework pm_power_off machine_[restart|power_off|halt]
We seem to have the pm_power_off hook wrong in arch/powerpc. From the other arches and from how its used by the rest of the kernel (e.g., ipmi), it should point to the lowest-level power off function not to machine_power_off(). Actually, machine_power_off() should call pm_power_off since AFAICT it is the one and only interface used by the rest of the kernel to power a machine off (with one exception which I believe to be a bug and have a patch in this series to fix). While looking at this, I found several bits of code that needed minor rework and/or cleaning up. These bits include: refactoring some common code used by the machine_xxx routines, having machine_power_off call ppc_md.halt if there ppc_md.power_off is NULL or returns, having machine_halt call ppc_md.power_off it ppc_md.halt is NULL or returns, and removing some useless xxx_halt and xxx_power_off routines in platform code. With the new usage of pm_power_off, the ppc_md.power_off hook is no longer needed and pm_power_off will be assigned in the platform probe routine. The end result of all of these patches should make the check of pm_power_off being NULL in kernel/sys.c:sys_reboot useful for powerpc, eliminate the need for platform halt routines to call the power off routine (and vice versa), allow things like IPMI to take over pm_power_off when they need to, and make the power off/halt related code a bit cleaner consistent. I still have to make sure I didn't miss anything and I haven't compiled all the files I've touched so these aren't submission candidates yet. I'd appreciate any feedback. Thanks, Mark ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 1/7] powerpc: Drivers should call machine_power_off not pm_power_off
From: Mark A. Greer [EMAIL PROTECTED]
Drivers should call machine_power_off() not pm_power_off to power off
a machine.
Signed-off-by: Mark A. Greer [EMAIL PROTECTED]
---
drivers/parisc/power.c |6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/parisc/power.c b/drivers/parisc/power.c
index 90cca5e..188a1ac 100644
--- a/drivers/parisc/power.c
+++ b/drivers/parisc/power.c
@@ -93,11 +93,9 @@ static void process_shutdown(void)
lcd_print(msg);
/* send kill signal */
- if (kill_cad_pid(SIGINT, 1)) {
+ if (kill_cad_pid(SIGINT, 1))
/* just in case killing init process failed */
- if (pm_power_off)
- pm_power_off();
- }
+ machine_power_off();
}
}
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 3/7] powerpc: ras.c should call machine_power_off()
From: Mark A. Greer [EMAIL PROTECTED]
machine_power_off() is the proper interface to use for powering
off a machine.
Signed-off-by: Mark A. Greer [EMAIL PROTECTED]
---
arch/powerpc/platforms/pseries/ras.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/platforms/pseries/ras.c
b/arch/powerpc/platforms/pseries/ras.c
index a1ab25c..64564b2 100644
--- a/arch/powerpc/platforms/pseries/ras.c
+++ b/arch/powerpc/platforms/pseries/ras.c
@@ -242,7 +242,7 @@ static irqreturn_t ras_error_interrupt(int irq, void
*dev_id)
* without actually failing while injecting errors.
* Error data will not be logged to syslog.
*/
- ppc_md.power_off();
+ machine_power_off();
#endif
} else {
udbg_printf(Recoverable HW Error 0x%lx 0x%x\n,
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 5/7] powerpc: Replace ppc_md.power_off with pm_power_off
From: Mark A. Greer [EMAIL PROTECTED]
The ppc_md.power_off hook performs the same function that the
pm_power_off hook is supposed to. However, it is powerpc-specific
and prevents kernel drivers (e.g., IPMI) from changing how a platform
is powered off. So, get rid of ppc_md.power_off and replace it with
pm_power_off.
Signed-off-by: Mark A. Greer [EMAIL PROTECTED]
---
arch/powerpc/kernel/setup-common.c | 14 +--
arch/powerpc/platforms/52xx/efika.c |2
arch/powerpc/platforms/cell/setup.c |2
arch/powerpc/platforms/celleb/setup.c|2
arch/powerpc/platforms/chrp/setup.c |2
arch/powerpc/platforms/embedded6xx/linkstation.c |3
arch/powerpc/platforms/iseries/setup.c |2
arch/powerpc/platforms/maple/setup.c |4
arch/powerpc/platforms/powermac/setup.c |2
arch/powerpc/platforms/ps3/setup.c |2
arch/powerpc/platforms/pseries/setup.c | 59 ++---
include/asm-powerpc/machdep.h|1
12 files changed, 48 insertions(+), 47 deletions(-)
diff --git a/arch/powerpc/kernel/setup-common.c
b/arch/powerpc/kernel/setup-common.c
index 1f8f9aa..d9f2e07 100644
--- a/arch/powerpc/kernel/setup-common.c
+++ b/arch/powerpc/kernel/setup-common.c
@@ -76,6 +76,9 @@ EXPORT_SYMBOL(ppc_md);
struct machdep_calls *machine_id;
EXPORT_SYMBOL(machine_id);
+void (*pm_power_off)(void);
+EXPORT_SYMBOL_GPL(pm_power_off);
+
unsigned long klimit = (unsigned long) _end;
char cmd_line[COMMAND_LINE_SIZE];
@@ -127,8 +130,8 @@ void machine_restart(char *cmd)
void machine_power_off(void)
{
machine_shutdown();
- if (ppc_md.power_off)
- ppc_md.power_off();
+ if (pm_power_off)
+ pm_power_off();
printk(KERN_EMERG System not powered off; halting instead.\n);
if (ppc_md.halt)
ppc_md.halt();
@@ -137,17 +140,14 @@ void machine_power_off(void)
/* Used by the G5 thermal driver */
EXPORT_SYMBOL_GPL(machine_power_off);
-void (*pm_power_off)(void) = machine_power_off;
-EXPORT_SYMBOL_GPL(pm_power_off);
-
void machine_halt(void)
{
machine_shutdown();
if (ppc_md.halt)
ppc_md.halt();
- if (ppc_md.power_off) {
+ if (pm_power_off) {
printk(KERN_EMERG System not halted; powering off instead.\n);
- ppc_md.power_off();
+ pm_power_off();
printk(KERN_EMERG Poweroff failed.\n);
}
default_halt(OK to turn off power\n);
diff --git a/arch/powerpc/platforms/52xx/efika.c
b/arch/powerpc/platforms/52xx/efika.c
index a0da70c..c2d5f06 100644
--- a/arch/powerpc/platforms/52xx/efika.c
+++ b/arch/powerpc/platforms/52xx/efika.c
@@ -205,6 +205,7 @@ static int __init efika_probe(void)
DMA_MODE_READ = 0x44;
DMA_MODE_WRITE = 0x48;
+ pm_power_off = rtas_power_off;
return 1;
}
@@ -218,7 +219,6 @@ define_machine(efika)
.init_IRQ = mpc52xx_init_irq,
.get_irq= mpc52xx_get_irq,
.restart= rtas_restart,
- .power_off = rtas_power_off,
.halt = rtas_halt,
.set_rtc_time = rtas_set_rtc_time,
.get_rtc_time = rtas_get_rtc_time,
diff --git a/arch/powerpc/platforms/cell/setup.c
b/arch/powerpc/platforms/cell/setup.c
index 98e7ef8..06f44f5 100644
--- a/arch/powerpc/platforms/cell/setup.c
+++ b/arch/powerpc/platforms/cell/setup.c
@@ -191,6 +191,7 @@ static int __init cell_probe(void)
return 0;
hpte_init_native();
+ pm_power_off = rtas_power_off;
return 1;
}
@@ -201,7 +202,6 @@ define_machine(cell) {
.setup_arch = cell_setup_arch,
.show_cpuinfo = cell_show_cpuinfo,
.restart= rtas_restart,
- .power_off = rtas_power_off,
.halt = rtas_halt,
.get_boot_time = rtas_get_boot_time,
.get_rtc_time = rtas_get_rtc_time,
diff --git a/arch/powerpc/platforms/celleb/setup.c
b/arch/powerpc/platforms/celleb/setup.c
index ddfb35a..450841a 100644
--- a/arch/powerpc/platforms/celleb/setup.c
+++ b/arch/powerpc/platforms/celleb/setup.c
@@ -116,6 +116,7 @@ static int __init celleb_probe(void)
powerpc_firmware_features |= FW_FEATURE_CELLEB_POSSIBLE;
hpte_init_beat_v3();
+ pm_power_off = beat_power_off;
return 1;
}
@@ -145,7 +146,6 @@ define_machine(celleb) {
.setup_arch = celleb_setup_arch,
.show_cpuinfo = celleb_show_cpuinfo,
.restart= beat_restart,
- .power_off = beat_power_off,
.halt = beat_halt,
.get_rtc_time = beat_get_rtc_time,
.set_rtc_time = beat_set_rtc_time,
diff --git a/arch
[PATCH 6/7] powerpc: Remove redundant power_off and halt routines
From: Mark A. Greer [EMAIL PROTECTED]
Remove platform-specific power_off and halt routines, and ppc_md
initializations that are not necessary.
Signed-off-by: Mark A. Greer [EMAIL PROTECTED]
---
arch/powerpc/platforms/embedded6xx/holly.c| 12
arch/powerpc/platforms/embedded6xx/linkstation.c |7 ---
arch/powerpc/platforms/embedded6xx/mpc7448_hpc2.c | 11 ---
arch/powerpc/platforms/iseries/setup.c|1 -
arch/powerpc/platforms/maple/setup.c |6 --
arch/powerpc/platforms/powermac/setup.c |7 ---
6 files changed, 44 deletions(-)
diff --git a/arch/powerpc/platforms/embedded6xx/holly.c
b/arch/powerpc/platforms/embedded6xx/holly.c
index b6de2b5..70cfd37 100644
--- a/arch/powerpc/platforms/embedded6xx/holly.c
+++ b/arch/powerpc/platforms/embedded6xx/holly.c
@@ -253,18 +253,6 @@ void holly_restart(char *cmd)
for (;;) ;
}
-void holly_power_off(void)
-{
- local_irq_disable();
- /* No way to shut power off with software */
- for (;;) ;
-}
-
-void holly_halt(void)
-{
- holly_power_off();
-}
-
/*
* Called very early, device-tree isn't unflattened
*/
diff --git a/arch/powerpc/platforms/embedded6xx/linkstation.c
b/arch/powerpc/platforms/embedded6xx/linkstation.c
index 8792840..3382eef 100644
--- a/arch/powerpc/platforms/embedded6xx/linkstation.c
+++ b/arch/powerpc/platforms/embedded6xx/linkstation.c
@@ -162,12 +162,6 @@ static void linkstation_power_off(void)
/* NOTREACHED */
}
-static void linkstation_halt(void)
-{
- linkstation_power_off();
- /* NOTREACHED */
-}
-
static void linkstation_show_cpuinfo(struct seq_file *m)
{
seq_printf(m, vendor\t\t: Buffalo Technology\n);
@@ -195,6 +189,5 @@ define_machine(linkstation){
.show_cpuinfo = linkstation_show_cpuinfo,
.get_irq= mpic_get_irq,
.restart= linkstation_restart,
- .halt = linkstation_halt,
.calibrate_decr = generic_calibrate_decr,
};
diff --git a/arch/powerpc/platforms/embedded6xx/mpc7448_hpc2.c
b/arch/powerpc/platforms/embedded6xx/mpc7448_hpc2.c
index a2c04b9..557a6fe 100644
--- a/arch/powerpc/platforms/embedded6xx/mpc7448_hpc2.c
+++ b/arch/powerpc/platforms/embedded6xx/mpc7448_hpc2.c
@@ -179,17 +179,6 @@ void mpc7448_hpc2_restart(char *cmd)
for (;;) ; /* Spin until reset happens */
}
-void mpc7448_hpc2_power_off(void)
-{
- local_irq_disable();
- for (;;) ; /* No way to shut power off with software */
-}
-
-void mpc7448_hpc2_halt(void)
-{
- mpc7448_hpc2_power_off();
-}
-
/*
* Called very early, device-tree isn't unflattened
*/
diff --git a/arch/powerpc/platforms/iseries/setup.c
b/arch/powerpc/platforms/iseries/setup.c
index 362084e..0eabbc3 100644
--- a/arch/powerpc/platforms/iseries/setup.c
+++ b/arch/powerpc/platforms/iseries/setup.c
@@ -650,7 +650,6 @@ define_machine(iseries) {
.init_early = iSeries_init_early,
.pcibios_fixup = iSeries_pci_final_fixup,
.restart= mf_reboot,
- .halt = mf_power_off,
.get_boot_time = iSeries_get_boot_time,
.set_rtc_time = iSeries_set_rtc_time,
.get_rtc_time = iSeries_get_rtc_time,
diff --git a/arch/powerpc/platforms/maple/setup.c
b/arch/powerpc/platforms/maple/setup.c
index d0eb901..ac5f99a 100644
--- a/arch/powerpc/platforms/maple/setup.c
+++ b/arch/powerpc/platforms/maple/setup.c
@@ -151,11 +151,6 @@ static void maple_power_off(void)
printk(KERN_EMERG Maple: Manual Power-Down Required\n);
}
-static void maple_halt(void)
-{
- maple_power_off();
-}
-
#ifdef CONFIG_SMP
struct smp_ops_t maple_smp_ops = {
.probe = smp_mpic_probe,
@@ -329,7 +324,6 @@ define_machine(maple_md) {
.pci_irq_fixup = maple_pci_irq_fixup,
.pci_get_legacy_ide_irq = maple_pci_get_legacy_ide_irq,
.restart= maple_restart,
- .halt = maple_halt,
.get_boot_time = maple_get_boot_time,
.set_rtc_time = maple_set_rtc_time,
.get_rtc_time = maple_get_rtc_time,
diff --git a/arch/powerpc/platforms/powermac/setup.c
b/arch/powerpc/platforms/powermac/setup.c
index 8429002..002b0b4 100644
--- a/arch/powerpc/platforms/powermac/setup.c
+++ b/arch/powerpc/platforms/powermac/setup.c
@@ -499,12 +499,6 @@ static void pmac_power_off(void)
}
}
-static void
-pmac_halt(void)
-{
- pmac_power_off();
-}
-
/*
* Early initialization.
*/
@@ -677,7 +671,6 @@ define_machine(powermac) {
.get_irq= NULL, /* changed later */
.pci_irq_fixup = pmac_pci_irq_fixup,
.restart= pmac_restart,
- .halt = pmac_halt,
.time_init = pmac_time_init,
.get_boot_time
[PATCH 7/7] powerpc: Remove incorrect panic() calls
From: Mark A. Greer [EMAIL PROTECTED] Platform-specific restart routines should not call panic() when they fail. Instead, they should return so the caller (machine_restart()) can halt the system more gracefully. Signed-off-by: Mark A. Greer [EMAIL PROTECTED] --- arch/powerpc/platforms/82xx/pq2.c |2 -- arch/powerpc/platforms/8xx/m8xx_setup.c|1 - arch/powerpc/platforms/embedded6xx/prpmc2800.c |1 - 3 files changed, 4 deletions(-) diff --git a/arch/powerpc/platforms/82xx/pq2.c b/arch/powerpc/platforms/82xx/pq2.c index a497cba..16cd460 100644 --- a/arch/powerpc/platforms/82xx/pq2.c +++ b/arch/powerpc/platforms/82xx/pq2.c @@ -31,8 +31,6 @@ void pq2_restart(char *cmd) /* Clear the ME,EE,IR DR bits in MSR to cause checkstop */ mtmsr(mfmsr() ~(MSR_ME | MSR_EE | MSR_IR | MSR_DR)); in_8(cpm2_immr-im_clkrst.res[0]); - - panic(Restart failed\n); } #ifdef CONFIG_PCI diff --git a/arch/powerpc/platforms/8xx/m8xx_setup.c b/arch/powerpc/platforms/8xx/m8xx_setup.c index d35eda8..1014310 100644 --- a/arch/powerpc/platforms/8xx/m8xx_setup.c +++ b/arch/powerpc/platforms/8xx/m8xx_setup.c @@ -221,7 +221,6 @@ void mpc8xx_restart(char *cmd) mtmsr(mfmsr() ~0x1000); in_8(clk_r-res[0]); - panic(Restart failed\n); } static void cpm_cascade(unsigned int irq, struct irq_desc *desc) diff --git a/arch/powerpc/platforms/embedded6xx/prpmc2800.c b/arch/powerpc/platforms/embedded6xx/prpmc2800.c index 653a5eb..fe5920c 100644 --- a/arch/powerpc/platforms/embedded6xx/prpmc2800.c +++ b/arch/powerpc/platforms/embedded6xx/prpmc2800.c @@ -108,7 +108,6 @@ static void prpmc2800_restart(char *cmd) prpmc2800_reset_board(); while (i-- 0); - panic(restart failed\n); } #ifdef CONFIG_NOT_COHERENT_CACHE ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 2/7] powerpc: xmon should call machine_xxx not ppc_md.xxx directly
From: Mark A. Greer [EMAIL PROTECTED] xmon should call machine_[restart|halt|power_off] instead of ppc_md.[restart|halt|power_off]. Signed-off-by: Mark A. Greer [EMAIL PROTECTED] --- I'm not sure about this one. Does anyone see a problem with this? arch/powerpc/xmon/xmon.c |6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/arch/powerpc/xmon/xmon.c b/arch/powerpc/xmon/xmon.c index 121b04d..56267e3 100644 --- a/arch/powerpc/xmon/xmon.c +++ b/arch/powerpc/xmon/xmon.c @@ -908,11 +908,11 @@ static void bootcmds(void) cmd = inchar(); if (cmd == 'r') - ppc_md.restart(NULL); + machine_restart(); else if (cmd == 'h') - ppc_md.halt(); + machine_halt(); else if (cmd == 'p') - ppc_md.power_off(); + machine_power_off(); } static int cpu_cmd(void) ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 4/7] powerpc: Rework the machine_[restart|power_off|halt] routines
From: Mark A. Greer [EMAIL PROTECTED]
Factor out common code from the machine_xxx routines and make them better
handle a ppc_md hook that doesn't exist or fails better. In particular,
have machine_power_off() try ppc_md.halt if ppc_md.power_off is NULL or fails,
and have machine_halt() try to power off when ppc_md.halt is NULL or fails.
Signed-off-by: Mark A. Greer [EMAIL PROTECTED]
---
arch/powerpc/kernel/setup-common.c | 40 ++-
1 file changed, 22 insertions(+), 18 deletions(-)
diff --git a/arch/powerpc/kernel/setup-common.c
b/arch/powerpc/kernel/setup-common.c
index 6adb5a1..1f8f9aa 100644
--- a/arch/powerpc/kernel/setup-common.c
+++ b/arch/powerpc/kernel/setup-common.c
@@ -105,17 +105,23 @@ void machine_shutdown(void)
ppc_md.machine_shutdown();
}
-void machine_restart(char *cmd)
+static void default_halt(const char *s)
{
- machine_shutdown();
- if (ppc_md.restart)
- ppc_md.restart(cmd);
#ifdef CONFIG_SMP
smp_send_stop();
#endif
- printk(KERN_EMERG System Halted, OK to turn off power\n);
+ printk(KERN_EMERG %s, s);
local_irq_disable();
- while (1) ;
+ while (1);
+}
+
+void machine_restart(char *cmd)
+{
+ machine_shutdown();
+ if (ppc_md.restart)
+ ppc_md.restart(cmd);
+ default_halt(System not restarted; halting instead.\n
+ OK to turn off power\n);
}
void machine_power_off(void)
@@ -123,12 +129,10 @@ void machine_power_off(void)
machine_shutdown();
if (ppc_md.power_off)
ppc_md.power_off();
-#ifdef CONFIG_SMP
- smp_send_stop();
-#endif
- printk(KERN_EMERG System Halted, OK to turn off power\n);
- local_irq_disable();
- while (1) ;
+ printk(KERN_EMERG System not powered off; halting instead.\n);
+ if (ppc_md.halt)
+ ppc_md.halt();
+ default_halt(OK to turn off power\n);
}
/* Used by the G5 thermal driver */
EXPORT_SYMBOL_GPL(machine_power_off);
@@ -141,12 +145,12 @@ void machine_halt(void)
machine_shutdown();
if (ppc_md.halt)
ppc_md.halt();
-#ifdef CONFIG_SMP
- smp_send_stop();
-#endif
- printk(KERN_EMERG System Halted, OK to turn off power\n);
- local_irq_disable();
- while (1) ;
+ if (ppc_md.power_off) {
+ printk(KERN_EMERG System not halted; powering off instead.\n);
+ ppc_md.power_off();
+ printk(KERN_EMERG Poweroff failed.\n);
+ }
+ default_halt(OK to turn off power\n);
}
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] powerpc: prpmc2800 - Enable L2 cache
From: Mark A. Greer [EMAIL PROTECTED] Turn on the L2 cache on the prpmc2800 platform. Signed-off-by: Mark A. Greer [EMAIL PROTECTED] --- arch/powerpc/platforms/embedded6xx/prpmc2800.c |1 + 1 file changed, 1 insertion(+) diff --git a/arch/powerpc/platforms/embedded6xx/prpmc2800.c b/arch/powerpc/platforms/embedded6xx/prpmc2800.c index e484cac..653a5eb 100644 --- a/arch/powerpc/platforms/embedded6xx/prpmc2800.c +++ b/arch/powerpc/platforms/embedded6xx/prpmc2800.c @@ -144,6 +144,7 @@ static int __init prpmc2800_probe(void) strncpy(prpmc2800_platform_name, m, min((int)len, PLATFORM_NAME_MAX - 1)); + _set_L2CR(_get_L2CR() | L2CR_L2E); return 1; } ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 1/3] powerpc: mv64x60 - Fix PCI MEM-System Mem window setup
From: Mark A. Greer [EMAIL PROTECTED]
The Marvell mv64x60 line of host bridges just don't like
PCI MEM-System Memory windows setups that don't match
the CPU-System Memory window setups. For example, if there
is 1GB of System Memory and 2 CPU-System Memory windows set up
for 512MB each, then there had better be 2 PCI-System Memory
windows set up for 512MB each as well.
This restriction was documented in early versions of the bridge
but isn't supposed to apply to recent versions. It seems as though
it still applies to recent versions as well.
mv64x60_config_pci_windows() is now changed to make the windows match
as described above.
Signed-off-by: Mark A. Greer [EMAIL PROTECTED]
---
arch/powerpc/boot/mv64x60.c | 133 --
arch/powerpc/boot/mv64x60.h |2
2 files changed, 96 insertions(+), 39 deletions(-)
diff --git a/arch/powerpc/boot/mv64x60.c b/arch/powerpc/boot/mv64x60.c
index b432594..c3f 100644
--- a/arch/powerpc/boot/mv64x60.c
+++ b/arch/powerpc/boot/mv64x60.c
@@ -92,6 +92,9 @@
#define MV64x60_PCI0_BAR_ENABLE0x0c3c
#define MV64x60_PCI02MEM_0_SIZE0x0c08
+#define MV64x60_PCI02MEM_1_SIZE0x0d08
+#define MV64x60_PCI02MEM_2_SIZE0x0c0c
+#define MV64x60_PCI02MEM_3_SIZE0x0d0c
#define MV64x60_PCI0_ACC_CNTL_0_BASE_LO0x1e00
#define MV64x60_PCI0_ACC_CNTL_0_BASE_HI0x1e04
#define MV64x60_PCI0_ACC_CNTL_0_SIZE 0x1e08
@@ -113,6 +116,9 @@
#define MV64x60_PCI1_BAR_ENABLE0x0cbc
#define MV64x60_PCI12MEM_0_SIZE0x0c88
+#define MV64x60_PCI12MEM_1_SIZE0x0d88
+#define MV64x60_PCI12MEM_2_SIZE0x0c8c
+#define MV64x60_PCI12MEM_3_SIZE0x0d8c
#define MV64x60_PCI1_ACC_CNTL_0_BASE_LO0x1e80
#define MV64x60_PCI1_ACC_CNTL_0_BASE_HI0x1e84
#define MV64x60_PCI1_ACC_CNTL_0_SIZE 0x1e88
@@ -331,18 +337,58 @@ void mv64x60_config_ctlr_windows(u8 *bridge_base, u8
*bridge_pbase,
}
/* PCI MEM - system memory, et. al. setup */
-static struct mv64x60_pci_win mv64x60_pci2mem[2] = {
+static struct mv64x60_pci_win mv64x60_pci2mem[2][MV64x60_CPU2MEM_WINDOWS] = {
{ /* hose 0 */
- .fcn= 0,
- .hi = 0x14,
- .lo = 0x10,
- .size = MV64x60_PCI02MEM_0_SIZE,
+ [0] = {
+ .fcn= 0,
+ .hi = 0x14,
+ .lo = 0x10,
+ .size = MV64x60_PCI02MEM_0_SIZE,
+ },
+ [1] = {
+ .fcn= 0,
+ .hi = 0x1c,
+ .lo = 0x18,
+ .size = MV64x60_PCI02MEM_1_SIZE,
+ },
+ [2] = {
+ .fcn= 1,
+ .hi = 0x14,
+ .lo = 0x10,
+ .size = MV64x60_PCI02MEM_2_SIZE,
+ },
+ [3] = {
+ .fcn= 1,
+ .hi = 0x1c,
+ .lo = 0x18,
+ .size = MV64x60_PCI02MEM_3_SIZE,
+ },
},
{ /* hose 1 */
- .fcn= 0,
- .hi = 0x94,
- .lo = 0x90,
- .size = MV64x60_PCI12MEM_0_SIZE,
+ [0] = {
+ .fcn= 0,
+ .hi = 0x94,
+ .lo = 0x90,
+ .size = MV64x60_PCI12MEM_0_SIZE,
+ },
+ [1] = {
+ .fcn= 0,
+ .hi = 0x9c,
+ .lo = 0x98,
+ .size = MV64x60_PCI12MEM_1_SIZE,
+ },
+ [2] = {
+ .fcn= 1,
+ .hi = 0x94,
+ .lo = 0x90,
+ .size = MV64x60_PCI12MEM_2_SIZE,
+ },
+ [3] = {
+ .fcn= 1,
+ .hi = 0x9c,
+ .lo = 0x98,
+ .size = MV64x60_PCI12MEM_3_SIZE,
+ },
},
};
@@ -394,70 +440,81 @@ mv64x60_mem_win
mv64x60_pci_acc[2][MV64x60_PCI_ACC_CNTL_WINDOWS] = {
},
};
-static struct mv64x60_mem_win mv64x60_pci2reg[2] = {
- {
+static struct mv64x60_pci_win mv64x60_pci2reg[2] = {
+ { /* hose 0 */
+ .fcn= 0,
.hi = 0x24,
.lo = 0x20,
.size = 0,
},
- {
+ { /* hose 1 */
+ .fcn= 0,
.hi = 0xa4,
.lo = 0xa0,
.size = 0
[PATCH 2/3] powerpc: prpmc2800 - Use new mv64x60_config_pci_windows() interface
From: Mark A. Greer [EMAIL PROTECTED]
Make the prpmc2800 bootwrapper code use the new interface to
mv64x60_config_pci_windows(). With that change, some minor code
rearrangement is possible to make things neater.
Signed-off-by: Mark A. Greer [EMAIL PROTECTED]
---
arch/powerpc/boot/prpmc2800.c | 20 +---
1 file changed, 9 insertions(+), 11 deletions(-)
diff --git a/arch/powerpc/boot/prpmc2800.c b/arch/powerpc/boot/prpmc2800.c
index 9614e1d..d72400d 100644
--- a/arch/powerpc/boot/prpmc2800.c
+++ b/arch/powerpc/boot/prpmc2800.c
@@ -315,7 +315,7 @@ static struct prpmc2800_board_info *prpmc2800_get_bip(void)
return bip;
}
-static void prpmc2800_bridge_setup(u32 mem_size)
+static void prpmc2800_bridge_setup(void)
{
u32 i, v[12], enables, acc_bits;
u32 pci_base_hi, pci_base_lo, size, buf[2];
@@ -340,8 +340,7 @@ static void prpmc2800_bridge_setup(u32 mem_size)
| MV64x60_PCI_ACC_CNTL_RDSIZE_256_BYTES;
mv64x60_config_ctlr_windows(bridge_base, bridge_pbase, is_coherent);
- mv64x60_config_pci_windows(bridge_base, bridge_pbase, 0, 0, mem_size,
- acc_bits);
+ mv64x60_config_pci_windows(bridge_base, bridge_pbase, 0, 0, acc_bits);
/* Get the cpu - pci i/o mem mappings from the device tree */
devp = finddevice(/mv64x60/[EMAIL PROTECTED]);
@@ -397,20 +396,19 @@ static void prpmc2800_bridge_setup(u32 mem_size)
static void prpmc2800_fixups(void)
{
- u32 v[2], l, mem_size;
+ u32 v[2], l;
int rc;
void *devp;
char model[BOARD_MODEL_MAX];
struct prpmc2800_board_info *bip;
- bip = prpmc2800_get_bip(); /* Get board info based on VPD */
-
- mem_size = (bip) ? bip-mem_size : mv64x60_get_mem_size(bridge_base);
- prpmc2800_bridge_setup(mem_size); /* Do necessary bridge setup */
+ prpmc2800_bridge_setup(); /* Do necessary bridge setup */
- /* If the VPD doesn't match what we know about, just use the
+ /*
+* If the VPD doesn't match what we know about, just use the
* defaults already in the device tree.
*/
+ bip = prpmc2800_get_bip(); /* Get board info based on VPD */
if (!bip)
return;
@@ -439,8 +437,8 @@ static void prpmc2800_fixups(void)
devp = finddevice(/memory);
if (devp == NULL)
fatal(Error: Missing /memory device tree node\n\r);
- v[0] = 0;
- v[1] = bip-mem_size;
+ v[0] = 0; /* Take min of DT's mem size and what mem ctlr is setup for */
+ v[1] = min(mv64x60_get_mem_size(bridge_base), bip-mem_size);
setprop(devp, reg, v, sizeof(v));
/* Update /mv64x60/model, if this is a mv64362 */
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 3/3] powerpc: mv64x60 - Aesthetic fixups for bootwrapper code
From: Mark A. Greer [EMAIL PROTECTED]
Specify locations when initializing arrays. This has already been done
for one array so may as well do it for them all.
Signed-off-by: Mark A. Greer [EMAIL PROTECTED]
---
I don't know if this one is worth the bother (it is a little anal)
but it keeps things consistent. I'm happy with or without it.
arch/powerpc/boot/mv64x60.c | 72 +-
1 file changed, 36 insertions(+), 36 deletions(-)
diff --git a/arch/powerpc/boot/mv64x60.c b/arch/powerpc/boot/mv64x60.c
index c3f..d207a0b 100644
--- a/arch/powerpc/boot/mv64x60.c
+++ b/arch/powerpc/boot/mv64x60.c
@@ -174,11 +174,11 @@ struct {
u32 addr;
u32 data;
} static mv64x60_pci_cfgio[2] = {
- { /* hose 0 */
+ [0] = { /* hose 0 */
.addr = 0xcf8,
.data = 0xcfc,
},
- { /* hose 1 */
+ [1] = { /* hose 1 */
.addr = 0xc78,
.data = 0xc7c,
}
@@ -201,76 +201,76 @@ void mv64x60_cfg_write(u8 *bridge_base, u8 hose, u8 bus,
u8 devfn, u8 offset,
/* I/O ctlr - system memory setup */
static struct mv64x60_mem_win mv64x60_cpu2mem[MV64x60_CPU2MEM_WINDOWS] = {
- {
+ [0] = {
.lo = MV64x60_CPU2MEM_0_BASE,
.size = MV64x60_CPU2MEM_0_SIZE,
},
- {
+ [1] = {
.lo = MV64x60_CPU2MEM_1_BASE,
.size = MV64x60_CPU2MEM_1_SIZE,
},
- {
+ [2] = {
.lo = MV64x60_CPU2MEM_2_BASE,
.size = MV64x60_CPU2MEM_2_SIZE,
},
- {
+ [3] = {
.lo = MV64x60_CPU2MEM_3_BASE,
.size = MV64x60_CPU2MEM_3_SIZE,
},
};
static struct mv64x60_mem_win mv64x60_enet2mem[MV64x60_CPU2MEM_WINDOWS] = {
- {
+ [0] = {
.lo = MV64x60_ENET2MEM_0_BASE,
.size = MV64x60_ENET2MEM_0_SIZE,
},
- {
+ [1] = {
.lo = MV64x60_ENET2MEM_1_BASE,
.size = MV64x60_ENET2MEM_1_SIZE,
},
- {
+ [2] = {
.lo = MV64x60_ENET2MEM_2_BASE,
.size = MV64x60_ENET2MEM_2_SIZE,
},
- {
+ [3] = {
.lo = MV64x60_ENET2MEM_3_BASE,
.size = MV64x60_ENET2MEM_3_SIZE,
},
};
static struct mv64x60_mem_win mv64x60_mpsc2mem[MV64x60_CPU2MEM_WINDOWS] = {
- {
+ [0] = {
.lo = MV64x60_MPSC2MEM_0_BASE,
.size = MV64x60_MPSC2MEM_0_SIZE,
},
- {
+ [1] = {
.lo = MV64x60_MPSC2MEM_1_BASE,
.size = MV64x60_MPSC2MEM_1_SIZE,
},
- {
+ [2] = {
.lo = MV64x60_MPSC2MEM_2_BASE,
.size = MV64x60_MPSC2MEM_2_SIZE,
},
- {
+ [3] = {
.lo = MV64x60_MPSC2MEM_3_BASE,
.size = MV64x60_MPSC2MEM_3_SIZE,
},
};
static struct mv64x60_mem_win mv64x60_idma2mem[MV64x60_CPU2MEM_WINDOWS] = {
- {
+ [0] = {
.lo = MV64x60_IDMA2MEM_0_BASE,
.size = MV64x60_IDMA2MEM_0_SIZE,
},
- {
+ [1] = {
.lo = MV64x60_IDMA2MEM_1_BASE,
.size = MV64x60_IDMA2MEM_1_SIZE,
},
- {
+ [2] = {
.lo = MV64x60_IDMA2MEM_2_BASE,
.size = MV64x60_IDMA2MEM_2_SIZE,
},
- {
+ [3] = {
.lo = MV64x60_IDMA2MEM_3_BASE,
.size = MV64x60_IDMA2MEM_3_SIZE,
},
@@ -338,7 +338,7 @@ void mv64x60_config_ctlr_windows(u8 *bridge_base, u8
*bridge_pbase,
/* PCI MEM - system memory, et. al. setup */
static struct mv64x60_pci_win mv64x60_pci2mem[2][MV64x60_CPU2MEM_WINDOWS] = {
- { /* hose 0 */
+ [0] = { /* hose 0 */
[0] = {
.fcn= 0,
.hi = 0x14,
@@ -364,7 +364,7 @@ static struct mv64x60_pci_win
mv64x60_pci2mem[2][MV64x60_CPU2MEM_WINDOWS] = {
.size = MV64x60_PCI02MEM_3_SIZE,
},
},
- { /* hose 1 */
+ [1] = { /* hose 1 */
[0] = {
.fcn= 0,
.hi = 0x94,
@@ -394,45 +394,45 @@ static struct mv64x60_pci_win
mv64x60_pci2mem[2][MV64x60_CPU2MEM_WINDOWS] = {
static struct
mv64x60_mem_win mv64x60_pci_acc[2][MV64x60_PCI_ACC_CNTL_WINDOWS] = {
- { /* hose 0 */
- {
+ [0] = { /* hose 0 */
+ [0] = {
.hi = MV64x60_PCI0_ACC_CNTL_0_BASE_HI,
.lo = MV64x60_PCI0_ACC_CNTL_0_BASE_LO,
.size = MV64x60_PCI0_ACC_CNTL_0_SIZE,
},
- {
+ [1] = {
.hi = MV64x60_PCI0_ACC_CNTL_1_BASE_HI
[PATCH] powerpc: prpmc2800 - Don't trust documented memory size
It turns out that the firmware on some PrPMC2800 processor modules initializes the memory controller for 512 MB even when there is more memory. As a simple work around, set the amount of memory in the device tree passed to the kernel to the lesser of what the memory controller is set up for and the actual amount of memory. Signed-off-by: Mark A. Greer [EMAIL PROTECTED] --- arch/powerpc/boot/prpmc2800.c |5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/arch/powerpc/boot/prpmc2800.c b/arch/powerpc/boot/prpmc2800.c index 9614e1d..559c45e 100644 --- a/arch/powerpc/boot/prpmc2800.c +++ b/arch/powerpc/boot/prpmc2800.c @@ -405,7 +405,10 @@ static void prpmc2800_fixups(void) bip = prpmc2800_get_bip(); /* Get board info based on VPD */ - mem_size = (bip) ? bip-mem_size : mv64x60_get_mem_size(bridge_base); + mem_size = mv64x60_get_mem_size(bridge_base); + if (bip) + mem_size = min(mem_size, bip-mem_size); + prpmc2800_bridge_setup(mem_size); /* Do necessary bridge setup */ /* If the VPD doesn't match what we know about, just use the ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: prpmc2800 - Don't trust documented memory size
On Mon, Nov 05, 2007 at 06:28:05PM -0700, Mark A. Greer wrote: It turns out that the firmware on some PrPMC2800 processor modules initializes the memory controller for 512 MB even when there is more memory. As a simple work around, set the amount of memory in the device tree passed to the kernel to the lesser of what the memory controller is set up for and the actual amount of memory. Signed-off-by: Mark A. Greer [EMAIL PROTECTED] --- Paul, please ignore this patch. There is still something wrong. Sorry for the noise. Mark ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 2/2] powerpc: prpmc2800 - Don't overwrite user FLASH size
From: Mark A. Greer [EMAIL PROTECTED]
The prpmc2800 bootwrapper code currently overwrites the DTS' user FLASH
size with a predetermined value. Intead make it use whatever is specified
in the DTS unless the prpmc2800 variant the bootwrapper is running on has
no user FLASH. In that case, set the user FLASH size to 0.
Signed-off-by: Mark A. Greer [EMAIL PROTECTED]
---
arch/powerpc/boot/prpmc2800.c | 54
1 file changed, 28 insertions(+), 26 deletions(-)
diff --git a/arch/powerpc/boot/prpmc2800.c b/arch/powerpc/boot/prpmc2800.c
index 9614e1d..a8b3213 100644
--- a/arch/powerpc/boot/prpmc2800.c
+++ b/arch/powerpc/boot/prpmc2800.c
@@ -58,7 +58,7 @@ struct prpmc2800_board_info {
u32 core_speed;
u32 mem_size;
u32 boot_flash;
- u32 user_flash;
+ u8 has_user_flash;
};
static struct prpmc2800_board_info prpmc2800_board_info[] = {
@@ -73,7 +73,7 @@ static struct prpmc2800_board_info prpmc2800_board_info[] = {
.core_speed = 1*GHz,
.mem_size = 512*MB,
.boot_flash = 1*MB,
- .user_flash = 64*MB,
+ .has_user_flash = 1,
},
{
.model = BOARD_MODEL_PRPMC280,
@@ -86,7 +86,7 @@ static struct prpmc2800_board_info prpmc2800_board_info[] = {
.core_speed = 1*GHz,
.mem_size = 512*MB,
.boot_flash = 0,
- .user_flash = 0,
+ .has_user_flash = 0,
},
{
.model = BOARD_MODEL_PRPMC280,
@@ -99,7 +99,7 @@ static struct prpmc2800_board_info prpmc2800_board_info[] = {
.core_speed = 733*MHz,
.mem_size = 512*MB,
.boot_flash = 1*MB,
- .user_flash = 64*MB,
+ .has_user_flash = 1,
},
{
.model = BOARD_MODEL_PRPMC280,
@@ -112,7 +112,7 @@ static struct prpmc2800_board_info prpmc2800_board_info[] =
{
.core_speed = 1*GHz,
.mem_size = 1*GB,
.boot_flash = 1*MB,
- .user_flash = 64*MB,
+ .has_user_flash = 1,
},
{
.model = BOARD_MODEL_PRPMC280,
@@ -125,7 +125,7 @@ static struct prpmc2800_board_info prpmc2800_board_info[] =
{
.core_speed = 1*GHz,
.mem_size = 512*MB,
.boot_flash = 1*MB,
- .user_flash = 64*MB,
+ .has_user_flash = 1,
},
{
.model = BOARD_MODEL_PRPMC280,
@@ -138,7 +138,7 @@ static struct prpmc2800_board_info prpmc2800_board_info[] =
{
.core_speed = 733*MHz,
.mem_size = 128*MB,
.boot_flash = 1*MB,
- .user_flash = 0,
+ .has_user_flash = 0,
},
{
.model = BOARD_MODEL_PRPMC280,
@@ -151,7 +151,7 @@ static struct prpmc2800_board_info prpmc2800_board_info[] =
{
.core_speed = 1*GHz,
.mem_size = 256*MB,
.boot_flash = 1*MB,
- .user_flash = 0,
+ .has_user_flash = 0,
},
{
.model = BOARD_MODEL_PRPMC280,
@@ -164,7 +164,7 @@ static struct prpmc2800_board_info prpmc2800_board_info[] =
{
.core_speed = 1*GHz,
.mem_size = 1*GB,
.boot_flash = 1*MB,
- .user_flash = 64*MB,
+ .has_user_flash = 1,
},
{
.model = BOARD_MODEL_PRPMC2800,
@@ -177,7 +177,7 @@ static struct prpmc2800_board_info prpmc2800_board_info[] =
{
.core_speed = 1*GHz,
.mem_size = 512*MB,
.boot_flash = 2*MB,
- .user_flash = 64*MB,
+ .has_user_flash = 1,
},
{
.model = BOARD_MODEL_PRPMC2800,
@@ -190,7 +190,7 @@ static struct prpmc2800_board_info prpmc2800_board_info[] =
{
.core_speed = 1*GHz,
.mem_size = 512*MB,
.boot_flash = 0,
- .user_flash = 0,
+ .has_user_flash = 0,
},
{
.model = BOARD_MODEL_PRPMC2800,
@@ -203,7 +203,7 @@ static struct prpmc2800_board_info prpmc2800_board_info[] =
{
.core_speed = 733*MHz,
.mem_size = 512*MB,
.boot_flash = 2*MB,
- .user_flash = 64*MB,
+ .has_user_flash = 1,
},
{
.model = BOARD_MODEL_PRPMC2800,
@@ -216,7 +216,7 @@ static struct prpmc2800_board_info prpmc2800_board_info[] =
{
.core_speed = 1*GHz
Re: [PATCH 1/2] powerpc: prpmc2800 - Add MTD support
On Fri, Oct 26, 2007 at 10:23:53AM +1000, Stephen Rothwell wrote:
Hi Mark,
On Thu, 25 Oct 2007 16:39:48 -0700 Mark A. Greer [EMAIL PROTECTED] wrote:
+static int __init prpmc2800_register_mtd(void)
+{
+ struct device_node *np = NULL;
^^^
Not needed if you use for_each_compatible_node().
+
+ while ((np = of_find_compatible_node(np, NULL, cfi-flash)) != NULL)
for_each_compatible_node(np, NULL, cfi-flash)
+ of_platform_device_create(np, NULL, NULL);
+
+ of_node_put(np);
Not needed as np must be NULL when you get here.
Ah, yes, true on all points. Thanks Stephen.
Update coming shortly...
Mark
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH v2 1/2] powerpc: prpmc2800 - Add MTD support
From: Mark A. Greer [EMAIL PROTECTED]
Create necessary device nodes so that the MTD subsystem recognizes
the MTD entries in the prpmc2800's DTS file. Also bring MTD section
of the prpmc2800's DTS file up to the current DTS specification.
Signed-off-by: Mark A. Greer [EMAIL PROTECTED]
---
With Stephen's comments addressed. Much nicer. Thanks again, Stephen.
arch/powerpc/boot/dts/prpmc2800.dts| 39 +++
arch/powerpc/platforms/embedded6xx/prpmc2800.c | 12
2 files changed, 41 insertions(+), 10 deletions(-)
diff --git a/arch/powerpc/boot/dts/prpmc2800.dts
b/arch/powerpc/boot/dts/prpmc2800.dts
index 297dfa5..24944ca 100644
--- a/arch/powerpc/boot/dts/prpmc2800.dts
+++ b/arch/powerpc/boot/dts/prpmc2800.dts
@@ -55,17 +55,36 @@
f200 f200 0004; /* Integrated SRAM */
[EMAIL PROTECTED] {
- device_type = rom;
- compatible = direct-mapped;
- reg = a000 400; /* Default (64MB) */
- probe-type = CFI;
+ compatible = cfi-flash;
+ reg = a000 0400;
bank-width = 4;
- partitions = 0010 /* RO */
- 0010 00040001 /* RW */
- 0014 0040 /* RO */
- 0054 039c /* RO */
- 03f0 0010; /* RO */
- partition-names = FW Image A, FW Config Data,
Kernel Image, Filesystem, FW Image B;
+ device-width = 2;
+ #address-cells = 1;
+ #size-cells = 1;
+ [EMAIL PROTECTED] {
+ label = FW Image A;
+ reg = 0010;
+ read-only;
+ };
+ [EMAIL PROTECTED] {
+ label = FW Config Data; /* RW */
+ reg = 0010 0004;
+ };
+ [EMAIL PROTECTED] {
+ label = Kernel Image;
+ reg = 0014 0040;
+ read-only;
+ };
+ [EMAIL PROTECTED] {
+ label = Filesystem;
+ reg = 0054 039c;
+ read-only;
+ };
+ [EMAIL PROTECTED] {
+ label = FW Image B;
+ reg = 03f0 0010;
+ read-only;
+ };
};
mdio {
diff --git a/arch/powerpc/platforms/embedded6xx/prpmc2800.c
b/arch/powerpc/platforms/embedded6xx/prpmc2800.c
index e484cac..2506f38 100644
--- a/arch/powerpc/platforms/embedded6xx/prpmc2800.c
+++ b/arch/powerpc/platforms/embedded6xx/prpmc2800.c
@@ -14,6 +14,7 @@
#include linux/delay.h
#include linux/interrupt.h
#include linux/seq_file.h
+#include linux/of_platform.h
#include asm/machdep.h
#include asm/prom.h
@@ -68,6 +69,17 @@ static void __init prpmc2800_setup_arch(void)
printk(Motorola %s\n, prpmc2800_platform_name);
}
+static int __init prpmc2800_register_mtd(void)
+{
+ struct device_node *np;
+
+ for_each_compatible_node(np, NULL, cfi-flash)
+ of_platform_device_create(np, NULL, NULL);
+
+ return 0;
+}
+device_initcall(prpmc2800_register_mtd);
+
static void prpmc2800_reset_board(void)
{
u32 temp;
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Override timer interrupt
On Fri, Oct 12, 2007 at 03:49:02PM -0500, Rune Torgersen wrote: Is there an easy way to use something other than the decrementer for the timer interrupt? Reason i'm asking is tha t on our board, the decrementer cannot be divided to 1khz evenly, so we have rounding errors for time, but we do have a 1KHz timer interrupt from an FPGA that is source of a T1 clock. Right now I let the decrementer interrupt do nothing, and made my own timer interrupt handler that calls the stuff the timer_interrupt usually does. This works, but there are some instability (ie unexplained hangs) that showed up when I did this. I just responded to you on -embedded with this: Check out the clocksource stuff. It let's you set up numerous clock sources and set the rating of each one. You can start looking in arch/powerpc/kernel/time.c for example code. Mark ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC] [PATCH] PowerPC: add more than 4MB kernel image size support to bootwarapper
On Sun, Oct 07, 2007 at 08:31:46PM -0500, Scott Wood wrote: Sorry for the delay, Scott. Mark A. Greer wrote: Why? Because its only safe to download a zImage to certain safe locations. Where those safe locations are vary by firmware, firmware version, and zImage size. This is the issue we're discussing. In theory, yes -- but in practice the odds of this particular heuristic choosing an unsuitable address seem slim. Yes, it probably will work fairly well for most powerpc 32-bit platforms since the default in arch/ppc was 8MB (but there was a manual override that was used by some platforms). That still doesn't make it safe for everyone 32-bit or 64-bit. I've already explained _why_ the link address matters WRT where its downloaded. Sorry, I was being a bit too pendantic with respect to the distinction between link and load address. And I was probably too impatient. Sorry. Also, being able to control the link address (that is, the download address with some firmwares) is not a u-boot specific issue and we shouldn't make a u-boot specific solution. How is this a u-boot specific solution? Because the hoops being jumped through in the patch(es) are to make u-boot happy and no other firmware. No, the hoops (which I don't think are sufficiently complicated to warrant such a name) Not yet maybe but as exceptions come along . = ALIGN((_kend - _kstart + 64*1024), (4*1024*1024)); will become more complicated. are to address a generic issue with the bootwrapper -- it wants to put the kernel at zero. It'd be really nice if, in the absense of a vmlinux_alloc method, the generic code would do an ordinary malloc() if there's not enough room at zero. Actually, that's a good idea but its only for safety sake. When you unpack the kernel at somewhere other than 0, there will be an additional copy very early during kernel boot to copy itself to address 0. So, if we add that feature we should print a warning so the user knows extra time was spent copying the kernel to 0. If we can come up with a simple way to control the link address we can avoid that copy. I'd much rather it be automatic than require the user to guess an appropriate value (and be aware in the first place that it needs to be set). Sure, automatic is nice; conjuring up the magic to make it work in all situations isn't. I think this heuristic would work in most situations, so if we do add a manual override it should be an override, and not something that everybody has to put up with. Okay, so how about we just leave the default at 4MB and come up with that manual override?? ;) Having the link address--and therefore the download address on some systems--mysteriously and uncontrollably jump around based on the zImage size is asking for trouble. It's a source of potential issues, but I think asking for trouble is exaggerating somewhat. Noted and disagreed with. :) Mark ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Override timer interrupt
On Fri, Oct 12, 2007 at 04:39:53PM -0500, Rune Torgersen wrote: From: Mark A. Greer Is there an easy way to use something other than the decrementer for the timer interrupt? Check out the clocksource stuff. It let's you set up numerous clock sources and set the rating of each one. You can start looking in arch/powerpc/kernel/time.c for example code. Thanks I will. Currently our board port lives in /arch/ppc (2.6.18) but I will take a look in powerpc. Okay. Just an FYI, arch/ppc will evaporate next summer. Mark ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC] [PATCH] PowerPC: add more than 4MB kernel image size support to bootwarapper
On Fri, Oct 05, 2007 at 12:30:54PM -0500, Scott Wood wrote: On Thu, Oct 04, 2007 at 06:58:49PM -0700, Mark A. Greer wrote: Having the link address jump around depending on the size of the kernel or zImage is wrong IMHO. It just screams weird can't boot issues. We need a way to specify exactly where we want the zImage linked no matter what the kernel or zImage size. Why? Why? Because its only safe to download a zImage to certain safe locations. Where those safe locations are vary by firmware, firmware version, and zImage size. This is the issue we're discussing. I've already explained _why_ the link address matters WRT where its downloaded. The zImage is relocatable. It doesn't matter where it's linked. We know...and a zImage running at an address it wasn't linked at is not the issue. Also, being able to control the link address (that is, the download address with some firmwares) is not a u-boot specific issue and we shouldn't make a u-boot specific solution. How is this a u-boot specific solution? Because the hoops being jumped through in the patch(es) are to make u-boot happy and no other firmware. The more general problem is that some firmwares examine the ELF header and download the zImage to address it was linked at. Some firmwares let you override this but some don't and those are the problem ones. That's not the more general problem; it's the same problem with a different file format. True, I misspoke. I'll restate it this way: The more general problem is that some firmwares will only download to the address the zImage is linked at. So, we need to control what that link address is. I still like my idea best. I haven't coded yet it so I don't have a patch but this is what I mean: 1) add a config option (default 4MB) for the link address 2) add a parameter to the wrapper script thru which we pass the value in the config option 3) the wrapper script changes the VMA/LMA to the address specified (objcopy --change-addresses=some math to get correct incr ?). I'd much rather it be automatic than require the user to guess an appropriate value (and be aware in the first place that it needs to be set). Sure, automatic is nice; conjuring up the magic to make it work in all situations isn't. Having the link address--and therefore the download address on some systems--mysteriously and uncontrollably jump around based on the zImage size is asking for trouble. Mark ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC] [PATCH] PowerPC: add more than 4MB kernel image size support to bootwarapper
On Wed, Oct 03, 2007 at 03:50:05PM +1000, David Gibson wrote: On Fri, Sep 28, 2007 at 06:23:09PM +0400, Valentine Barshak wrote: David Gibson wrote: On Mon, Sep 24, 2007 at 03:36:27PM +0400, Valentine Barshak wrote: Looking deeper at this I've found that currently u-boot thinks that memory space over 8MB is not reached by Linux kernel (CFG_BOOTMAPSZ defined as (8 20)), although all physical memory is identity mapped. That's why it puts command line and board info structure as high as possible within the first 8MB. This worked fine with uImage, since u-boot always unpacked it to 0. Now, cuImage has to be unpacked higher (we need space at the start of the memory to eventually put vmlinux image there). So, if unpacked kernel image crosses 8MB boundary, it gets damaged by u-boot when it prepares cmd_line and bdinfo. The possible workaround for that is to always link zImage at =8MB base or to have 4MB granularity like this: + . = ALIGN((_kend - _kstart + 64*1024), (4*1024*1024)); Reserve at least 64K for u-boot cmd_line and bdinfo. Ah. Right. That makes things a bit tricky. Even this 4MB granularity may not be enough (say, if the vmlinux is 4MB, but the zImage has a really big initrd and is 4MB). Except... it shouldn't really be the link address that matters. The zImage is relocatable, so it should only be the load address specified in the uImage header which matters. I think that's currently derived from the link address, but it doesn't have to be. Having the link address jump around depending on the size of the kernel or zImage is wrong IMHO. It just screams weird can't boot issues. We need a way to specify exactly where we want the zImage linked no matter what the kernel or zImage size. Also, being able to control the link address (that is, the download address with some firmwares) is not a u-boot specific issue and we shouldn't make a u-boot specific solution. The more general problem is that some firmwares examine the ELF header and download the zImage to address it was linked at. Some firmwares let you override this but some don't and those are the problem ones. We talked about this a bit back in February, http://ozlabs.org/pipermail/linuxppc-dev/2007-February/031532.html In that thread Geoff Levand suggested a config option and running it thru a preprocessor. David Gibson suggested making a replaceable linker script. I suggested passing the value of a config option to the wrapper script which would use objcopy/whatever to change the section addresses in the image (maybe this is what Geoff had in mind, I'm not sure). I still like my idea best. I haven't coded yet it so I don't have a patch but this is what I mean: 1) add a config option (default 4MB) for the link address 2) add a parameter to the wrapper script thru which we pass the value in the config option 3) the wrapper script changes the VMA/LMA to the address specified (objcopy --change-addresses=some math to get correct incr ?). I'll code it up in the next day or two unless someone doesn't like the idea. Mark ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC] [PATCH] PowerPC: add more than 4MB kernel image size support to bootwarapper
On Fri, Oct 05, 2007 at 12:25:54PM +1000, David Gibson wrote: On Thu, Oct 04, 2007 at 06:58:49PM -0700, Mark A. Greer wrote: On Wed, Oct 03, 2007 at 03:50:05PM +1000, David Gibson wrote: On Fri, Sep 28, 2007 at 06:23:09PM +0400, Valentine Barshak wrote: David Gibson wrote: On Mon, Sep 24, 2007 at 03:36:27PM +0400, Valentine Barshak wrote: Looking deeper at this I've found that currently u-boot thinks that memory space over 8MB is not reached by Linux kernel (CFG_BOOTMAPSZ defined as (8 20)), although all physical memory is identity mapped. That's why it puts command line and board info structure as high as possible within the first 8MB. This worked fine with uImage, since u-boot always unpacked it to 0. Now, cuImage has to be unpacked higher (we need space at the start of the memory to eventually put vmlinux image there). So, if unpacked kernel image crosses 8MB boundary, it gets damaged by u-boot when it prepares cmd_line and bdinfo. The possible workaround for that is to always link zImage at =8MB base or to have 4MB granularity like this: + . = ALIGN((_kend - _kstart + 64*1024), (4*1024*1024)); Reserve at least 64K for u-boot cmd_line and bdinfo. Ah. Right. That makes things a bit tricky. Even this 4MB granularity may not be enough (say, if the vmlinux is 4MB, but the zImage has a really big initrd and is 4MB). Except... it shouldn't really be the link address that matters. The zImage is relocatable, so it should only be the load address specified in the uImage header which matters. I think that's currently derived from the link address, but it doesn't have to be. Having the link address jump around depending on the size of the kernel or zImage is wrong IMHO. It just screams weird can't boot issues. Hrm. Except we already have that - the zImage is linked at a fixed location, and will just not work if the sizes are wrong. Yes, its an issue now (which is why we're having this discussion) but at least its predictable ATM. Having it jump around on you because you happened to set/clear a CONFIG option is worse. My point is that the address needs to be set manually--no fancy heuristics or whatever to guess. We need a way to specify exactly where we want the zImage linked no matter what the kernel or zImage size. Also, being able to control the link address (that is, the download address with some firmwares) is not a u-boot specific issue and we shouldn't make a u-boot specific solution. The more general problem is that some firmwares examine the ELF header and download the zImage to address it was linked at. Some firmwares let you override this but some don't and those are the problem ones. We talked about this a bit back in February, http://ozlabs.org/pipermail/linuxppc-dev/2007-February/031532.html In that thread Geoff Levand suggested a config option and running it thru a preprocessor. David Gibson suggested making a replaceable linker script. I suggested passing the value of a config option to the wrapper script which would use objcopy/whatever to change the section addresses in the image (maybe this is what Geoff had in mind, I'm not sure). I still like my idea best. I haven't coded yet it so I don't have a patch but this is what I mean: 1) add a config option (default 4MB) for the link address 2) add a parameter to the wrapper script thru which we pass the value in the config option 3) the wrapper script changes the VMA/LMA to the address specified (objcopy --change-addresses=some math to get correct incr ?). I'll code it up in the next day or two unless someone doesn't like the idea. A config option just doesn't seem right to me, except as a special-circumstances hack. Acutally, I started to hack up the patch and noticed that its already there. Its 'CONFIG_BOOT_LOAD' which is an Advanced setup option in arch/powerpc/Kconfig (probably migrated from arch/ppc/Kconfig). Several defconfig's have it set but its not used AFAICS. The zImage is already hardware and firmware specific; And [potentially] firmware version and zImage size specific. we should be able to figure out workable link and load addresses for a specific zImage I was going to argue with you here until... (which might need to be different for different zImages produced by the same config). Oh yeah, I forgot about multiple zImages from the same config. D*mn. Hmm, I guess I have to think about this more then. (and stop hacking up the patch I was talking about). Of course, the same objection would apply to CONFIG_DEVICE_TREE which we have already. Yep. Mark ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC] [PATCH] PowerPC: add more than 4MB kernel image size support to bootwarapper
On Thu, Oct 04, 2007 at 07:59:30PM -0700, Mark A. Greer wrote: On Fri, Oct 05, 2007 at 12:25:54PM +1000, David Gibson wrote: The zImage is already hardware and firmware specific; And [potentially] firmware version and zImage size specific. I meant to add, which is why it'll be difficult to come up with a heuristic that will work in all situations. Mark ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: Change MAINTAINER references linuxppc-embedded
On Mon, Oct 01, 2007 at 05:20:53PM -0700, Mark A. Greer wrote: Powerpc patches should be posted to linuxppc-dev@ozlabs.org so modify MAINTAINERS to no longer reference [EMAIL PROTECTED] Signed-off-by: Mark A. Greer [EMAIL PROTECTED] /me sighs. Disregard this. I send before I had the proper subject Mark ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: MAINTAINERS shouldn't reference linuxppc-embedded
Powerpc patches should be posted to linuxppc-dev@ozlabs.org so modify MAINTAINERS to no longer reference [EMAIL PROTECTED] Signed-off-by: Mark A. Greer [EMAIL PROTECTED] --- MAINTAINERS | 17 - 1 file changed, 8 insertions(+), 9 deletions(-) --- diff --git a/MAINTAINERS b/MAINTAINERS index 8f80068..06259b4 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -1543,7 +1543,7 @@ P:Pantelis Antoniou M: [EMAIL PROTECTED] P: Vitaly Bordug M: [EMAIL PROTECTED] -L: [EMAIL PROTECTED] +L: linuxppc-dev@ozlabs.org L: [EMAIL PROTECTED] S: Maintained @@ -1551,14 +1551,14 @@ FREESCALE HIGHSPEED USB DEVICE DRIVER P: Li Yang M: [EMAIL PROTECTED] L: [EMAIL PROTECTED] -L: [EMAIL PROTECTED] +L: linuxppc-dev@ozlabs.org S: Maintained FREESCALE QUICC ENGINE UCC ETHERNET DRIVER P: Li Yang M: [EMAIL PROTECTED] L: [EMAIL PROTECTED] -L: [EMAIL PROTECTED] +L: linuxppc-dev@ozlabs.org S: Maintained FILE LOCKING (flock() and fcntl()/lockf()) @@ -2291,7 +2291,6 @@ M:[EMAIL PROTECTED] W: http://www.246tNt.com/mpc52xx/ W: http://www.penguinppc.org/ L: linuxppc-dev@ozlabs.org -L: [EMAIL PROTECTED] S: Maintained LINUX FOR POWERPC EMBEDDED PPC4XX @@ -2300,7 +2299,7 @@ M:[EMAIL PROTECTED] P: Matt Porter M: [EMAIL PROTECTED] W: http://www.penguinppc.org/ -L: [EMAIL PROTECTED] +L: linuxppc-dev@ozlabs.org T: git kernel.org:/pub/scm/linux/kernel/git/jwboyer/powerpc.git S: Maintained @@ -2308,21 +2307,21 @@ LINUX FOR POWERPC BOOT CODE P: Tom Rini M: [EMAIL PROTECTED] W: http://www.penguinppc.org/ -L: [EMAIL PROTECTED] +L: linuxppc-dev@ozlabs.org S: Maintained LINUX FOR POWERPC EMBEDDED PPC8XX P: Marcelo Tosatti M: [EMAIL PROTECTED] W: http://www.penguinppc.org/ -L: [EMAIL PROTECTED] +L: linuxppc-dev@ozlabs.org S: Maintained LINUX FOR POWERPC EMBEDDED PPC83XX AND PPC85XX P: Kumar Gala M: [EMAIL PROTECTED] W: http://www.penguinppc.org/ -L: [EMAIL PROTECTED] +L: linuxppc-dev@ozlabs.org S: Maintained LINUX FOR POWERPC PA SEMI PWRFICIENT @@ -2978,7 +2977,7 @@ POWERPC 4xx EMAC DRIVER P: Eugene Surovegin M: [EMAIL PROTECTED] W: http://kernel.ebshome.net/emac/ -L: [EMAIL PROTECTED] +L: linuxppc-dev@ozlabs.org L: [EMAIL PROTECTED] S: Maintained ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 5/5] embedded6xx: Remove unnecessary loops_per_jiffy initialization code.
On Fri, Jul 27, 2007 at 01:25:09PM -0500, Jon Loeliger wrote: Signed-off-by: Jon Loeliger [EMAIL PROTECTED] FWIW for the prpmc2800 part... Acked-by: Mark A. Greer [EMAIL PROTECTED] ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Someone broke my allmodconfig build
On Mon, Jul 23, 2007 at 11:43:37AM +1000, David Gibson wrote: On Sat, Jul 21, 2007 at 09:04:13PM -0500, Josh Boyer wrote: On Sun, Jul 22, 2007 at 10:37:06AM +1000, Paul Mackerras wrote: Stephen Rothwell writes: WRAParch/powerpc/boot/zImage.ps3 /home/sfr/kernels/linus/arch/powerpc/boot/wrapper: line 113: dtc: command not found make[2]: *** [arch/powerpc/boot/zImage.ps3] Error 1 Hmmm, we should be shipping .dtb files with the tree, so people don't have to have dtc installed. Really? I don't think we're quite ready for that. Particularly for the embedded boards. Those DTS files still get lots of churn, and having to update both the .dts and .dtb at the same time seems a bit fragile. I sort of prefer this option in theory, but it's basically impossible. People updating dts files by patch would also have to update the dtb, which can't be done in a normal patch, since they're binary. I agree. Shipping a magic binary blob, especially ones that haven't really settled out, will be a real headache for poeple. I'm working with sfr now on importing dtc into the kernel tree. IIRC, this was discussed when dtc first came into existence but it was pooh-poohed. I forget why now. Mark ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Do we need to reset the master branch?
On Fri, Jul 20, 2007 at 01:27:08AM +1000, Stephen Rothwell wrote: Hi Mark, On Thu, 19 Jul 2007 08:17:46 -0700 Mark A. Greer [EMAIL PROTECTED] wrote: I did a git-pull this morning but it had a conflict. Should I have reset it to something? What did you pull it into? There were conflicts with Linus' tree in the last merge, so there may be conflicts with master as well. I am sure Paul will pull Linus's tree back into his master branch when he returns which should resolve the conflicts. I was in the master branch of powerpc.git and did a 'git-pull' Mark ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Do we need to reset the master branch?
On Fri, Jul 20, 2007 at 01:44:32AM +1000, Stephen Rothwell wrote: On Thu, 19 Jul 2007 08:32:17 -0700 Mark A. Greer [EMAIL PROTECTED] wrote: I was in the master branch of powerpc.git and did a 'git-pull' Sorry, I hadn't updated since this afternoon. Looks like Paul has reset his master tree to be the same as Linus', so you do need to do a reset. Or checkout a separate branch and use git fetch -f powerpc.git tree master:whatever branch tracks master Using recent git (after 1.5.something), you can track the whole powerpc tree like this: git remote add powerpc git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git git fetch powerpc This will track the tree in branches called powerpc/branch and do resets as necessary. Oh, that's cool Thanks Stephen. Mark ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 0/5] Kconfig cleanup revisited
On Fri, Jul 13, 2007 at 11:54:34AM +0200, Arnd Bergmann wrote: On Friday 13 July 2007, Mark A. Greer wrote: I really like what you've done here, thanks. The patches don't apply straight up so what other patches do these go on top of? They are meant to apply on top of powerpc.git. Yep, me too. I found now that the first patch has a trivial reject against the for-2.6.23 branch, but works fine for the master branch. Hrm, I'm on master and it doesn't apply but its minor so NBD. Should I resend? Not for me but Paul might appreciate it. :) Mark ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 0/5] Kconfig cleanup revisited
On Thu, Jul 12, 2007 at 11:01:56PM +0200, Arnd Bergmann wrote: Since this was brought up by Mark, here is a resend of the Kconfig cleanup patches that have not been merged so far, with updates for the comments I received. I stumbled over another bug in the process, and fear I have found a can of worms there (not opened yet): There are still many files under arch/powerpc that include headers from include/asm-ppc/. Most of these includes can simply be removed, but some are real bugs, where generic code still relies on board-specific macro definitions. Hi Arnd, I really like what you've done here, thanks. The patches don't apply straight up so what other patches do these go on top of? Mark ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [patch 1/9] move 82xx/83xx/86xx Kconfig options to platform selection
On Wed, Jul 11, 2007 at 10:33:51PM +0200, Arnd Bergmann wrote: On Wednesday 11 July 2007, Mark A. Greer wrote: +config CLASSIC32 + def_bool y + depends on 6xx PPC_MULTIPLATFORM Arnd, is this really what you wanted? With it, none of the embedded classics have CLASSIC32 defined which means they don't get TAU or ALTIVEC defined which isn't good. Sorry, this was the result of a wrong patch reordering. In my initial patch set I ended up with 6xx == CLASSIC32 and PPC_MULTIPLATFORM=y, but then I backed out a few patches in the middle. Ah, okay. I guess the best is to do another patch that moves PPC_EMBEDDED6xx into PPC_MULTIPLATFORM again and leaves this one as it is. Alternatively, we could kill CONFIG_CLASSIC32 entirely as it is used only in a few places. Especially after I resubmit my CPU type selection patch again, which allows you do it in a more fine grained way. Yes, it seems like getting rid of CLASSIC32 would be okay since it is hardly used. Which systems in particular should allow CONFIG_TAU? Is there a more specific dependency than (6xx !(82xx || 83xx || 86xx || 52xx))? I think Segher pretty much answered this. We definitely need to get ALTIVEC back soon for 74xx--currently SIGILL's my init when booting. Since it sounds like you're still tweaking things in Kconfig files, I'll leave it to you to take care of it. If not, just let me know. Mark ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
