Re: [PATCH v2 00/21] FDT clean-ups and libfdt support
From: Rob Herring robherri...@gmail.com To: Grant Likely grant.lik...@linaro.org, linux- ker...@vger.kernel.org, devicet...@vger.kernel.org Cc: Rob Herring r...@kernel.org, Aurelien Jacquiot a- jacqu...@ti.com, Benjamin Herrenschmidt b...@kernel.crashing.org, Chris Zankel ch...@zankel.net, H. Peter Anvin h...@zytor.com, Ingo Molnar mi...@redhat.com, James Hogan james.ho...@imgtec.co Date: 04/30/2014 09:45 AM Subject: [PATCH v2 00/21] FDT clean-ups and libfdt support Sent by: linux-kernel-ow...@vger.kernel.org From: Rob Herring r...@kernel.org This is a series of clean-ups of architecture FDT code and converts the core FDT code over to using libfdt functions. This is in preparation to add FDT based address translation parsing functions for early console support. This series removes direct access to FDT data from all arches except powerpc. The current MIPS lantiq and xlp DT code is buggy as built-in DTBs need to be copied out of init section. Patches 2 and 3 should be applied to 3.15. Changes in v2 are relatively minor. There was a bug in the unflattening code where walking up the tree was not being handled correctly (thanks to Michal Simek). I re-worked things a bit to avoid globally adding libfdt include paths. A branch is available here[1], and I plan to put into linux-next in a few days. Please test! I've compiled on arm, arm64, mips, microblaze, xtensa, and powerpc and booted on arm and arm64. I have tested this for PowerPC using a snapshot of libfdt[1] collected from the today (30/04/2014). The computers used were 32 bit, Freescale and IBM/AMCC CPUs: MVME5100 - Motorola/Fresscale CPU - PPCBug firmware SAM440EP - IBM/AMCC - U-Boot firmware Tested-by: Stephen Chivers schiv...@csc.com Stephen Chivers, CSC Australia Pty. Ltd. [1] git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git libfdt ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
GDB diagnostic for System-supplied DSO.
Using GDB to debug a trivial PowerPC test program using a kernel derived from yesterdays Linux-next I get: Can't read symbols from system-supplied DSO at 0x10: File truncated when the program is run. There is no apparent ill effect from this. It happens for both natively and cross compiled programs. Stephen Chivers, CSC Australia Pty. Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] of: give priority to the compatible match in __of_match_node()
Grant Likely glik...@secretlab.ca wrote on 02/20/2014 07:41:34 AM: From: Grant Likely grant.lik...@linaro.org To: Paul Gortmaker paul.gortma...@windriver.com, Rob Herring robherri...@gmail.com Cc: Kevin Hao haoke...@gmail.com, devicet...@vger.kernel.org devicet...@vger.kernel.org, Arnd Bergmann a...@arndb.de, Chris Proctor cproc...@csc.com.au, Stephen N Chivers schiv...@csc.com.au, Rob Herring robh...@kernel.org, Scott Wood scottw...@freescale.com, linuxppc-dev linuxppc- d...@lists.ozlabs.org, Sebastian Hesselbarth sebastian.hesselba...@gmail.com Date: 02/20/2014 07:41 AM Subject: Re: [PATCH] of: give priority to the compatible match in __of_match_node() Sent by: Grant Likely glik...@secretlab.ca On Wed, 19 Feb 2014 13:25:54 -0500, Paul Gortmaker paul.gortma...@windriver.com wrote: On Thu, Feb 13, 2014 at 2:01 PM, Rob Herring robherri...@gmail.com wrote: On Wed, Feb 12, 2014 at 5:38 AM, Kevin Hao haoke...@gmail.com wrote: When the device node do have a compatible property, we definitely prefer the compatible match besides the type and name. Only if there is no such a match, we then consider the candidate which doesn't have compatible entry but do match the type or name with the device node. This is based on a patch from Sebastian Hesselbarth. http://patchwork.ozlabs.org/patch/319434/ I did some code refactoring and also fixed a bug in the original patch. I'm inclined to just revert this once again and avoid possibly breaking yet another platform. Well, for what it is worth, today's (Feb19th) linux-next tree fails to boot on my sbc8548. It fails with: I think I've got it fixed now with the latest series. Please try the devicetree/merge branch on git://git.secretlab.ca/git/linux I have tested this with the following platforms: MVME5100, MVME4100, SAM440EP and MPC8349MITXGP. All boot and reach the login state on the serial console. The MVME4100 is a MPC8548 platform like the SBC8548 and suffered from the same PHY address is too large problem when used with todays linux-next. Tested-by: Stephen Chivers schiv...@csc.com g. --- libphy: Freescale PowerQUICC MII Bus: probed mdio_bus ethernet@e002400: /soc8548@e000/ethernet@24000/mdio@520 PHY address 1312 is too large libphy: Freescale PowerQUICC MII Bus: probed libphy: Freescale PowerQUICC MII Bus: probed mdio_bus ethernet@e002500: /soc8548@e000/ethernet@25000/mdio@520 PHY address 1312 is too large libphy: Freescale PowerQUICC MII Bus: probed TCP: cubic registered Initializing XFRM netlink socket NET: Registered protocol family 17 fail nfs mount --- On a normal boot, we should see this: --- libphy: Freescale PowerQUICC MII Bus: probed libphy: Freescale PowerQUICC MII Bus: probed fsl-gianfar e0024000.ethernet: enabled errata workarounds, flags: 0x4 fsl-gianfar e0024000.ethernet eth0: mac: 02:e0:0c:00:05:fd fsl-gianfar e0024000.ethernet eth0: Running with NAPI enabled fsl-gianfar e0024000.ethernet eth0: RX BD ring size for Q[0]: 256 fsl-gianfar e0024000.ethernet eth0: TX BD ring size for Q[0]: 256 fsl-gianfar e0025000.ethernet: enabled errata workarounds, flags: 0x4 fsl-gianfar e0025000.ethernet eth1: mac: 02:e0:0c:00:06:fd fsl-gianfar e0025000.ethernet eth1: Running with NAPI enabled fsl-gianfar e0025000.ethernet eth1: RX BD ring size for Q[0]: 256 fsl-gianfar e0025000.ethernet eth1: TX BD ring size for Q[0]: 256 TCP: cubic registered Initializing XFRM netlink socket NET: Registered protocol family 17 --- Git bisect says: ee8b26ad943aa34acc03ae6cde2b81d8d3d483d4 is the first bad commit commit ee8b26ad943aa34acc03ae6cde2b81d8d3d483d4 Author: Kevin Hao haoke...@gmail.com Date: Tue Feb 18 15:57:30 2014 +0800 of: reimplement the matching method for __of_match_node() In the current implementation of __of_match_node(), it will compare each given match entry against all the node's compatible strings with of_device_is_compatible(). To achieve multiple compatible strings per node with ordering from specific to generic, this requires given matches to be ordered from specific to generic. For most of the drivers this is not true and also an alphabetical ordering is more sane there. Therefore, we define a following priority order for the match, and then scan all the entries to find the best match. 1. specific compatible type name 2. specific compatible type 3. specific compatible name 4. specific compatible 5. general compatible type name 6. general compatible type 7. general compatible name 8. general compatible 9. type name 10. type 11. name
Re: [PATCH 2/2] of: search the best compatible match first in __of_match_node()
Rob Herring robherri...@gmail.com wrote on 02/15/2014 02:53:40 AM:
From: Rob Herring robherri...@gmail.com
To: Kevin Hao haoke...@gmail.com
Cc: devicet...@vger.kernel.org devicet...@vger.kernel.org,
linuxppc-dev linuxppc-dev@lists.ozlabs.org, Sebastian Hesselbarth
sebastian.hesselba...@gmail.com, Stephen N Chivers
schiv...@csc.com.au, Grant Likely grant.lik...@linaro.org, Rob
Herring robh...@kernel.org, Kumar Gala ga...@codeaurora.org
Date: 02/15/2014 02:53 AM
Subject: Re: [PATCH 2/2] of: search the best compatible match first
in __of_match_node()
On Thu, Feb 13, 2014 at 11:22 PM, Kevin Hao haoke...@gmail.com wrote:
Currently, of_match_node compares each given match against all node's
compatible strings with of_device_is_compatible.
To achieve multiple compatible strings per node with ordering from
specific to generic, this requires given matches to be ordered from
specific to generic. For most of the drivers this is not true and also
an alphabetical ordering is more sane there.
Therefore, this patch introduces a function to match each of the
node's
compatible strings against all given compatible matches without type
and
name first, before checking the next compatible string. This implies
that node's compatibles are ordered from specific to generic while
given matches can be in any order. If we fail to find such a match
entry, then fall-back to the old method in order to keep
compatibility.
Cc: Sebastian Hesselbarth sebastian.hesselba...@gmail.com
Signed-off-by: Kevin Hao haoke...@gmail.com
Looks good to me. I'll put this in next for a few days. I'd really
like to see some acks and tested-by's before sending to Linus.
Tested-by: Stephen Chivers schiv...@csc.com
I have tested the patch for the four PowerPC platforms
available to me.
They are:
MPC8349_MITXGP - Works.
MVME5100- Works.
MVME4100 - Works.
SAM440EP - Works.
The MPC8349_MITXGP platform is present in Linux-3.13 and previous
releases.
The MVME5100 is a revived platform that is in Linux-3.14-rc2.
The MVME4100 is a work in progress and is the 85xx platform that the
original failure report was for.
The SAM440EP is present in Linux-3.13 and previous releases.
The MPC8349_MITXGP is one of the 49 DTS files with the serial compatible:
compatible = fsl,ns16550, ns16550;
For the SAM440EP, the patch improves things from Linux-3.13. In that
release the same sort of problem as reported in:
Linux-3.14-rc2: Order of serial node compatibles in DTS files.
occurs with slightly different symptoms:
of_serial ef600300.serial: Port found
of_serial ef600300.serial: Port found
of_serial ef600300.serial: Unknown serial port found, ignored
of_serial ef600400.serial: Port found
of_serial ef600400.serial: Port found
of_serial ef600400.serial: Unknown serial port found, ignored
of_serial ef600500.serial: Port found
of_serial ef600500.serial: Port found
of_serial ef600500.serial: Unknown serial port found, ignored
of_serial ef600600.serial: Port found
of_serial ef600600.serial: Port found
of_serial ef600600.serial: Unknown serial port found, ignored
The SAM440EP has a IBM/AMCC 440EP PowerPC CPU and so simply has
ns16550 as its serial compatible.
We could be a bit more strict here and fallback to the old matching if
the match table has any entries with name or type. I don't think that
should be necessary though.
Rob
Stephen Chivers,
CSC Australia Pty. Ltd.
---
drivers/of/base.c | 43 ++-
1 file changed, 42 insertions(+), 1 deletion(-)
diff --git a/drivers/of/base.c b/drivers/of/base.c
index ba195fbce4c6..10b51106c854 100644
--- a/drivers/of/base.c
+++ b/drivers/of/base.c
@@ -730,13 +730,49 @@ out:
}
EXPORT_SYMBOL(of_find_node_with_property);
+static const struct of_device_id *
+of_match_compatible(const struct of_device_id *matches,
+ const struct device_node *node)
+{
+ const char *cp;
+ int cplen, l;
+ const struct of_device_id *m;
+
+ cp = __of_get_property(node, compatible, cplen);
+ while (cp (cplen 0)) {
+ m = matches;
+ while (m-name[0] || m-type[0] || m-compatible[0]) {
+ /* Only match for the entries without type
and name */
+ if (m-name[0] || m-type[0] ||
+ of_compat_cmp(m-compatible, cp,
+strlen(m-compatible)))
+ m++;
+ else
+ return m;
+ }
+
+ /* Get node's next compatible string */
+ l = strlen(cp) + 1;
+ cp += l;
+ cplen -= l;
+ }
+
+ return NULL;
+}
+
static
const struct of_device_id *__of_match_node(const struct
of_device_id *matches,
const
Re: [PATCH] of: give priority to the compatible match in __of_match_node()
Kevin Hao haoke...@gmail.com wrote on 02/12/2014 10:38:04 PM:
From: Kevin Hao haoke...@gmail.com
To: devicet...@vger.kernel.org, linuxppc-dev@lists.ozlabs.org
Cc: Sebastian Hesselbarth sebastian.hesselba...@gmail.com, Stephen
N Chivers schiv...@csc.com.au, Chris Proctor
cproc...@csc.com.au, Arnd Bergmann a...@arndb.de, Scott Wood
scottw...@freescale.com, Grant Likely grant.lik...@linaro.org,
Rob Herring robh...@kernel.org
Date: 02/12/2014 10:38 PM
Subject: [PATCH] of: give priority to the compatible match in
__of_match_node()
When the device node do have a compatible property, we definitely
prefer the compatible match besides the type and name. Only if
there is no such a match, we then consider the candidate which
doesn't have compatible entry but do match the type or name with
the device node.
This is based on a patch from Sebastian Hesselbarth.
http://patchwork.ozlabs.org/patch/319434/
I did some code refactoring and also fixed a bug in the original patch.
Cc: Sebastian Hesselbarth sebastian.hesselba...@gmail.com
Signed-off-by: Kevin Hao haoke...@gmail.com
Tested-by: Stephen Chivers schiv...@csc.com
Patch works for both orderings. Platform boots without problems and
I get the normal serial console.
---
drivers/of/base.c | 55
+--
1 file changed, 37 insertions(+), 18 deletions(-)
diff --git a/drivers/of/base.c b/drivers/of/base.c
index ff85450d5683..9d655df458bd 100644
--- a/drivers/of/base.c
+++ b/drivers/of/base.c
@@ -730,32 +730,45 @@ out:
}
EXPORT_SYMBOL(of_find_node_with_property);
+static int of_match_type_or_name(const struct device_node *node,
+const struct of_device_id *m)
+{
+ int match = 1;
+
+ if (m-name[0])
+ match = node-name !strcmp(m-name, node-name);
+
+ if (m-type[0])
+ match = node-type !strcmp(m-type, node-type);
+
+ return match;
+}
+
static
const struct of_device_id *__of_match_node(const struct
of_device_id *matches,
const struct device_node *node)
{
const char *cp;
int cplen, l;
+ const struct of_device_id *m;
+ int match;
if (!matches)
return NULL;
cp = __of_get_property(node, compatible, cplen);
- do {
- const struct of_device_id *m = matches;
+ while (cp (cplen 0)) {
+ m = matches;
/* Check against matches with current compatible string */
while (m-name[0] || m-type[0] || m-compatible[0]) {
- int match = 1;
- if (m-name[0])
-match = node-name
-!strcmp(m-name, node-name);
- if (m-type[0])
-match = node-type
-!strcmp(m-type, node-type);
- if (m-compatible[0])
-match = cp
-!of_compat_cmp(m-compatible, cp,
+ if (!m-compatible[0]) {
+m++;
+continue;
+ }
+
+ match = of_match_type_or_name(node, m);
+ match = cp !of_compat_cmp(m-compatible, cp,
strlen(m-compatible));
if (match)
return m;
@@ -763,12 +776,18 @@ const struct of_device_id *__of_match_node
(const struct of_device_id *matches,
}
/* Get node's next compatible string */
- if (cp) {
- l = strlen(cp) + 1;
- cp += l;
- cplen -= l;
- }
- } while (cp (cplen 0));
+ l = strlen(cp) + 1;
+ cp += l;
+ cplen -= l;
+ }
+
+ m = matches;
+ /* Check against matches without compatible string */
+ while (m-name[0] || m-type[0] || m-compatible[0]) {
+ if (!m-compatible[0] of_match_type_or_name(node, m))
+ return m;
+ m++;
+ }
return NULL;
}
--
1.8.5.3
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Linux-3.14-rc2: Order of serial node compatibles in DTS files.
I have been trial booting a 3.14-rc2 kernel for a 85xx platform
(dtbImage).
After mounting the root filesystem there are no messages from the init
scripts
and the serial console is not available for login.
In the kernel log messages there is:
of_serial f1004500.serial: Unknown serial port found, ignored.
The serial nodes in boards dts file are specified as:
serial0: serial@4500 {
cell-index = 0;
device_type = serial;
compatible = fsl,ns16550, ns16550;
reg = 0x4500 0x100;
clock-frequency = 0;
interrupts = 0x2a 0x2;
interrupt-parent = mpic;
};
Reversing the order of the compatible:
compatible = ns16550, fsl,ns16550;
restores the serial console.
Linux-3.13 does not have this behaviour.
There are 49 dts files in Linux-3.14-rc2 that have the fsl,ns16550
compatible first.
Stephen Chivers,
CSC Australia Pty. Ltd.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Linux-3.14-rc2: Order of serial node compatibles in DTS files.
Sebastian Hesselbarth sebastian.hesselba...@gmail.com wrote on
02/12/2014 09:51:43 AM:
From: Sebastian Hesselbarth sebastian.hesselba...@gmail.com
To: Kumar Gala ga...@kernel.crashing.org, Stephen N Chivers
schiv...@csc.com.au
Cc: linuxppc-dev@lists.ozlabs.org, Chris Proctor
cproc...@csc.com.au, devicetree devicet...@vger.kernel.org, Arnd
Bergmann a...@arndb.de
Date: 02/12/2014 09:51 AM
Subject: Re: Linux-3.14-rc2: Order of serial node compatibles in DTS
files.
On 02/11/2014 11:33 PM, Kumar Gala wrote:
On Feb 11, 2014, at 2:57 PM, Stephen N Chivers schiv...@csc.com.au
wrote:
I have been trial booting a 3.14-rc2 kernel for a 85xx platform
(dtbImage).
After mounting the root filesystem there are no messages from the
init
scripts
and the serial console is not available for login.
In the kernel log messages there is:
of_serial f1004500.serial: Unknown serial port found, ignored.
The serial nodes in boards dts file are specified as:
serial0: serial@4500 {
cell-index = 0;
device_type = serial;
compatible = fsl,ns16550, ns16550;
reg = 0x4500 0x100;
clock-frequency = 0;
interrupts = 0x2a 0x2;
interrupt-parent = mpic;
};
Reversing the order of the compatible:
compatible = ns16550, fsl,ns16550;
restores the serial console.
Linux-3.13 does not have this behaviour.
There are 49 dts files in Linux-3.14-rc2 that have the fsl,ns16550
compatible first.
Hmm,
Wondering if this caused the issue:
commit 105353145eafb3ea919f5cdeb652a9d8f270228e
Author: Sebastian Hesselbarth sebastian.hesselba...@gmail.com
Date: Tue Dec 3 14:52:00 2013 +0100
OF: base: match each node compatible against all given matches
first
[adding Arnd on Cc]
Could be. I checked tty/serial/of_serial.c and it does not provide a
compatible for fsl,ns16550. Does reverting the patch fix the issue
observed?
I don't think the missing compatible is causing it, but of_serial
provides a DT match for .type = serial just to fail later on
with the error seen above.
The commit in question reorders of_match_device in a way that match
table order is not relevant anymore. This can cause it to match
.type = serial first here.
Rather than touching the commit, I suggest to remove the problematic
.type = serial from the match table. It is of no use anyway.
Deleting the serial line from the match table fixes the problem.
I tested it for both orderings of compatible.
Sebastian
Thanks,
Stephen Chivers,
CSC Australia Pty. Ltd.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Linux-3.14-rc2: Order of serial node compatibles in DTS files.
Sebastian Hesselbarth sebastian.hesselba...@gmail.com wrote on
02/12/2014 10:46:36 AM:
From: Sebastian Hesselbarth sebastian.hesselba...@gmail.com
To: Scott Wood scottw...@freescale.com
Cc: Kumar Gala ga...@kernel.crashing.org, Stephen N Chivers
schiv...@csc.com.au, Chris Proctor cproc...@csc.com.au,
linuxppc-dev@lists.ozlabs.org, Arnd Bergmann a...@arndb.de,
devicetree devicet...@vger.kernel.org
Date: 02/12/2014 11:04 AM
Subject: Re: Linux-3.14-rc2: Order of serial node compatibles in DTS
files.
On 02/12/2014 12:41 AM, Scott Wood wrote:
On Tue, 2014-02-11 at 23:51 +0100, Sebastian Hesselbarth wrote:
On 02/11/2014 11:33 PM, Kumar Gala wrote:
Hmm,
Wondering if this caused the issue:
commit 105353145eafb3ea919f5cdeb652a9d8f270228e
Author: Sebastian Hesselbarth sebastian.hesselba...@gmail.com
Date: Tue Dec 3 14:52:00 2013 +0100
OF: base: match each node compatible against all given matches
first
[adding Arnd on Cc]
Could be. I checked tty/serial/of_serial.c and it does not provide a
compatible for fsl,ns16550. Does reverting the patch fix the issue
observed?
I don't think the missing compatible is causing it, but of_serial
provides a DT match for .type = serial just to fail later on
with the error seen above.
The commit in question reorders of_match_device in a way that match
table order is not relevant anymore. This can cause it to match
.type = serial first here.
Rather than touching the commit, I suggest to remove the problematic
.type = serial from the match table. It is of no use anyway.
Regardless of whether .type = serial gets removed, it seems wrong
for
of_match_node() to accept a .type-only match (or .name, or anything
else
that doesn't involve .compatible) before it accepts a compatible match
other than the first in the compatible property.
Right, I thought about it and came to the same conclusion. I sent a
patch a second ago to prefer .compatible != NULL matches over those
with .compatible == NULL.
Would be great if Stephen can re-test that. If it solves the issue, I
can send a patch tomorrow.
Done.
But, the Interrupt Controller (MPIC)
goes AWOL and it is down hill from there.
The MPIC is specified in the DTS as:
mpic: pic@4 {
interrupt-controller;
#address-cells = 0;
#interrupt-cells = 2;
reg = 0x4 0x4;
compatible = chrp,open-pic;
device_type = open-pic;
big-endian;
};
The board support file has the standard mechanism for allocating
the PIC:
struct mpic *mpic;
mpic = mpic_alloc(NULL, 0, 0, 0, 256, OpenPIC );
BUG_ON(mpic == NULL);
mpic_init(mpic);
I checked for damage in applying the patch and it has applied
correctly.
Stephen Chivers,
CSC Australia Pty. Ltd.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: arch/powerpc/math-emu/mtfsf.c - incorrect mask?
James Yang james.y...@freescale.com wrote on 02/08/2014 07:49:40 AM: From: James Yang james.y...@freescale.com To: Gabriel Paubert paub...@iram.es Cc: Stephen N Chivers schiv...@csc.com.au, Chris Proctor cproc...@csc.com.au, linuxppc-dev@lists.ozlabs.org Date: 02/08/2014 07:49 AM Subject: Re: arch/powerpc/math-emu/mtfsf.c - incorrect mask? On Fri, 7 Feb 2014, Gabriel Paubert wrote: Hi Stephen, On Fri, Feb 07, 2014 at 11:27:57AM +1000, Stephen N Chivers wrote: Gabriel Paubert paub...@iram.es wrote on 02/06/2014 07:26:37 PM: From: Gabriel Paubert paub...@iram.es To: Stephen N Chivers schiv...@csc.com.au Cc: linuxppc-dev@lists.ozlabs.org, Chris Proctor cproc...@csc.com.au Date: 02/06/2014 07:26 PM Subject: Re: arch/powerpc/math-emu/mtfsf.c - incorrect mask? On Thu, Feb 06, 2014 at 12:09:00PM +1000, Stephen N Chivers wrote: mask = 0; if (FM (1 0)) mask |= 0x000f; if (FM (1 1)) mask |= 0x00f0; if (FM (1 2)) mask |= 0x0f00; if (FM (1 3)) mask |= 0xf000; if (FM (1 4)) mask |= 0x000f; if (FM (1 5)) mask |= 0x00f0; if (FM (1 6)) mask |= 0x0f00; if (FM (1 7)) mask |= 0x9000; With the above mask computation I get consistent results for both the MPC8548 and MPC7410 boards. Am I missing something subtle? No I think you are correct. This said, this code may probably be optimized to eliminate a lot of the conditional branches. I think that: If the compiler is enabled to generate isel instructions, it would not use a conditional branch for this code. (ignore the andi's values, this is an old compile) From limited research, the 440GP is a processor that doesn't implement the isel instruction and it does not implement floating point. The kernel emulates isel and so using that instruction for the 440GP would have a double trap penalty. Correct me if I am wrong, the isel instruction first appears in PowerPC ISA v2.04 around mid 2007. Stephen Chivers, CSC Australia Pty. Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: arch/powerpc/math-emu/mtfsf.c - incorrect mask?
Gabriel Paubert paub...@iram.es wrote on 02/06/2014 07:26:37 PM: From: Gabriel Paubert paub...@iram.es To: Stephen N Chivers schiv...@csc.com.au Cc: linuxppc-dev@lists.ozlabs.org, Chris Proctor cproc...@csc.com.au Date: 02/06/2014 07:26 PM Subject: Re: arch/powerpc/math-emu/mtfsf.c - incorrect mask? On Thu, Feb 06, 2014 at 12:09:00PM +1000, Stephen N Chivers wrote: I have a MPC8548e based board and an application that makes extensive use of floating point including numerous calls to cos. In the same program there is the use of an sqlite database. The kernel is derived from 2.6.31 and is compiled with math emulation. At some point after the reading of the SQLITE database, the return result from cos goes from an in range value to an out of range value. This is as a result of the FP rounding mode mutating from round to nearest to round toward zero. The cos in the glibc version being used is known to be sensitive to rounding direction and Joseph Myers has previously fixed glibc. The failure does not occur on a machine that has a hardware floating point unit (a MPC7410 processor). I have traced the mutation to the following series of instructions: mffsf0 mtfsb1 4*cr7+so mtfsb0 4*cr7+eq faddf13,f1,f2 mtfsf 1, f0 The instructions are part of the stream emitted by gcc for the conversion of a 128 bit floating point value into an integer in the sqlite database read. Immediately before the execution of the mffs instruction the rounding mode is round to nearest. On the MPC8548 board, the execution of the mtfsf instruction does not restore the rounding mode to round to nearest. I believe that the mask computation in mtfsf.c is incorrect and is reversed. In the latest version of the file (linux-3.14-rc1), the mask is computed by: mask = 0; if (FM (1 0)) mask |= 0x9000; if (FM (1 1)) mask |= 0x0f00; if (FM (1 2)) mask |= 0x00f0; if (FM (1 3)) mask |= 0x000f; if (FM (1 4)) mask |= 0xf000; if (FM (1 5)) mask |= 0x0f00; if (FM (1 6)) mask |= 0x00f0; if (FM (1 7)) mask |= 0x000f; I think it should be: mask = 0; if (FM (1 0)) mask |= 0x000f; if (FM (1 1)) mask |= 0x00f0; if (FM (1 2)) mask |= 0x0f00; if (FM (1 3)) mask |= 0xf000; if (FM (1 4)) mask |= 0x000f; if (FM (1 5)) mask |= 0x00f0; if (FM (1 6)) mask |= 0x0f00; if (FM (1 7)) mask |= 0x9000; With the above mask computation I get consistent results for both the MPC8548 and MPC7410 boards. Am I missing something subtle? No I think you are correct. This said, this code may probably be optimized to eliminate a lot of the conditional branches. I think that: mask = (FM 1); mask |= (FM 3) 0x10; mask |= (FM 6) 0x100; mask |= (FM 9) 0x1000; mask |= (FM 12) 0x1; mask |= (FM 15) 0x10; mask |= (FM 18) 0x100; mask |= (FM 21) 0x1000; mask *= 15; should do the job, in less code space and without a single branch. Each one of the mask |= lines should be translated into an rlwinm instruction followed by an or. Actually it should be possible to transform each of these lines into a single rlwimi instruction but I don't know how to coerce gcc to reach this level of optimization. Another way of optomizing this could be: mask = (FM 0x0f) | ((FM 12) 0x000f); mask = (mask 0x00030003) | ((mask 6) 0x03030303); mask = (mask 0x01010101) | ((mask 3) 0x10101010); mask *= 15; It's not easy to see which of the solutions is faster, the second one needs to create quite a few constants, but its dependency length is lower. It is very likely that the first solution is faster in cache-cold case and the second in cache-hot. Regardless, the original code is rather naïve, larger and slower in all cases, with timing variation depending on branch mispredictions. Thanks for the response, it is appreciated. I have tried simple test versions of the two suggestions above, both produce the same results as the original formulation. My toolchain is gcc-4.1.2
arch/powerpc/math-emu/mtfsf.c - incorrect mask?
I have a MPC8548e based board and an application that makes extensive use of floating point including numerous calls to cos. In the same program there is the use of an sqlite database. The kernel is derived from 2.6.31 and is compiled with math emulation. At some point after the reading of the SQLITE database, the return result from cos goes from an in range value to an out of range value. This is as a result of the FP rounding mode mutating from round to nearest to round toward zero. The cos in the glibc version being used is known to be sensitive to rounding direction and Joseph Myers has previously fixed glibc. The failure does not occur on a machine that has a hardware floating point unit (a MPC7410 processor). I have traced the mutation to the following series of instructions: mffsf0 mtfsb1 4*cr7+so mtfsb0 4*cr7+eq faddf13,f1,f2 mtfsf 1, f0 The instructions are part of the stream emitted by gcc for the conversion of a 128 bit floating point value into an integer in the sqlite database read. Immediately before the execution of the mffs instruction the rounding mode is round to nearest. On the MPC8548 board, the execution of the mtfsf instruction does not restore the rounding mode to round to nearest. I believe that the mask computation in mtfsf.c is incorrect and is reversed. In the latest version of the file (linux-3.14-rc1), the mask is computed by: mask = 0; if (FM (1 0)) mask |= 0x9000; if (FM (1 1)) mask |= 0x0f00; if (FM (1 2)) mask |= 0x00f0; if (FM (1 3)) mask |= 0x000f; if (FM (1 4)) mask |= 0xf000; if (FM (1 5)) mask |= 0x0f00; if (FM (1 6)) mask |= 0x00f0; if (FM (1 7)) mask |= 0x000f; I think it should be: mask = 0; if (FM (1 0)) mask |= 0x000f; if (FM (1 1)) mask |= 0x00f0; if (FM (1 2)) mask |= 0x0f00; if (FM (1 3)) mask |= 0xf000; if (FM (1 4)) mask |= 0x000f; if (FM (1 5)) mask |= 0x00f0; if (FM (1 6)) mask |= 0x0f00; if (FM (1 7)) mask |= 0x9000; With the above mask computation I get consistent results for both the MPC8548 and MPC7410 boards. Am I missing something subtle? Stephen Chivers, CSC Australia Pty. Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v5 1/1] powerpc/embedded6xx: Add support for Motorola/Emerson MVME5100
Scott Wood scottw...@freescale.com wrote on 01/08/2014 10:51:10 AM: From: Scott Wood scottw...@freescale.com To: Stephen N Chivers/AUS/CSC@CSC Cc: b...@kernel.crashing.org, linuxppc-dev@lists.ozlabs.org Date: 01/08/2014 10:51 AM Subject: Re: [PATCH v5 1/1] powerpc/embedded6xx: Add support for Motorola/Emerson MVME5100 On Mon, 2014-01-06 at 12:23 +1100, Stephen Chivers wrote: Add support for the Motorola/Emerson MVME5100 Single Board Computer. The MVME5100 is a 6U form factor VME64 computer with: - A single MPC7410 or MPC750 CPU - A HAWK Processor Host Bridge (CPU to PCI) and MultiProcessor Interrupt Controller (MPIC) - Up to 500Mb of onboard memory - A M48T37 Real Time Clock (RTC) and Non-Volatile Memory chip - Two 16550 compatible UARTS - Two Intel E100 Fast Ethernets - Two PCI Mezzanine Card (PMC) Slots - PPCBug Firmware The HAWK PHB/MPIC is compatible with the MPC10x devices. There is no onboard disk support. This is usually provided by installing a PMC in first PMC slot. This patch revives the board support, it was present in early 2.6 series kernels. The board support in those days was by Matt Porter of MontaVista Software. CSC Australia has around 31 of these boards in service. The kernel in use for the boards is based on 2.6.31. The boards are operated without disks from a file server. This patch is based on linux-3.13-rc2 and has been boot tested. Only boards with 512 Mb of memory are known to work. V1-V2: Address comments by Kumar Gala and Scott Wood. Minor adjustment to platforms/embedded6xx/Kconfig to ensure correct indentation where possible. V2-V3: Address comments by Scott Wood and Ben Herrenschmidt. Address errors reported by checkpatch. V3-V4: Address comment by Geert Uytterhoeven Add tested by Alessio Bogani. V4-V5: Correct horrible typo in patch history. Kular Gama is Kumar Gala. The patch history should go below the --- line, as it's for reviewers who have seen previous versions rather than for the git history. Ok. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v3 1/1] powerpc/embedded6xx: Add support for Motorola/Emerson MVME5100
geert.uytterhoe...@gmail.com wrote on 11/04/2013 06:59:21 PM:
From: Geert Uytterhoeven ge...@linux-m68k.org
To: Stephen N Chivers/AUS/CSC@CSC
Cc: linuxppc-dev@lists.ozlabs.org linuxppc-dev@lists.ozlabs.org
Date: 11/04/2013 06:59 PM
Subject: Re: [PATCH v3 1/1] powerpc/embedded6xx: Add support for
Motorola/Emerson MVME5100
Sent by: geert.uytterhoe...@gmail.com
On Sun, Nov 3, 2013 at 10:07 PM, Stephen Chivers schiv...@csc.com
wrote:
+++ b/arch/powerpc/boot/dts/mvme5100.dts
@@ -0,0 +1,185 @@
+/*
+ * Device Tree Souce for Motorola/Emerson MVME5100.
Source
Ok. Thanks, will be fixed.
(unless this expresses your personal appreciation for device trees ;-)
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 --
ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker.
But
when I'm talking to journalists I just say programmer or somethinglike
that.
-- Linus Torvalds
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH v2 1/1] powerpc/embedded6xx: Add support for Motorola/Emerson MVME5100.
Scott Wood scottw...@freescale.com wrote on 09/11/2013 09:47:27 AM:
From: Scott Wood scottw...@freescale.com
To: Stephen N Chivers/AUS/CSC@CSC
Cc: Chris Proctor/AUS/CSC@CSC, linuxppc-dev@lists.ozlabs.org,
pau...@samba.org, b...@kernel.crashing.org
Date: 09/11/2013 09:47 AM
Subject: Re: [RFC PATCH v2 1/1] powerpc/embedded6xx: Add support for
Motorola/Emerson MVME5100.
On Thu, 2013-09-05 at 15:51 +1000, Stephen Chivers wrote:
Add support for the Motorola/Emerson MVME5100 Single Board Computer.
The MVME5100 is a 6U form factor VME64 computer with:
- A single MPC7410 or MPC750 CPU
- A HAWK Processor Host Bridge (CPU to PCI) and
MultiProcessor Interrupt Controller (MPIC)
- Up to 500Mb of onboard memory
- A M48T37 Real Time Clock (RTC) and Non-Volatile Memory chip
- Two 16550 compatible UARTS
- Two Intel E100 Fast Ethernets
- Two PCI Mezzanine Card (PMC) Slots
- PPCBug Firmware
The HAWK PHB/MPIC is compatible with the MPC10x devices.
There is no onboard disk support. This is usually provided by
installing a PMC in the first PMC slot.
This patch revives the board support, it was present in early 2.6
series kernels. The board support in those days was by Matt Porter of
MontaVista Software.
CSC Australia has around 31 of these boards in service. The kernel in
use
for the boards is based on 2.6.31. The boards are operated without
disks
from a file server.
This patch is based on linux-3.11-rc7 and has been boot tested.
V1-V2:
Address comments by Kular Gama and Scott Wood.
Minor adjustment to platforms/embedded6xx/Kconfig to ensure
correct indentation where possible.
Signed-off-by: Stephen Chivers schiv...@csc.com
---
Some comments below, and please run checkpatch.pl, but the next version
can probably be non-RFC if you're happy with it.
Ok.
+ PowerPC,7410 {
+ device_type = cpu;
+ reg = 0x0;
+ /* Following required by dtc but not used */
+ d-cache-line-size = 32;
+ i-cache-line-size = 32;
+ i-cache-size = 32768;
+ d-cache-size = 32768;
+ timebase-frequency = 2500;
+ clock-frequency = 5;
+bus-frequency = 1;
+ };
Whitespace on bus-frequency
Ok. Will fix.
+ mpic: interrupt-controller@f3f8 {
+ #interrupt-cells = 2;
+ #address-cells = 0;
+ device_type = open-pic;
+ compatible = chrp,open-pic;
+ interrupt-controller;
+ reg = 0xf3f8 0x4;
+ };
+
+ };
No blank line before }
Ok. Will be fixed.
+CONFIG_CMDLINE_BOOL=y
+CONFIG_CMDLINE=console=ttyS0,9600 ip=dhcp root=/dev/nfs
I take it there's no way to pass a command line in from whatever loader
this board uses... but you could put it in the dts instead.
It can be done by reading the NVRAM/RTC (M48T37) and overriding the
DTS specification. But I wanted to keep things simple to start
with.
Putting the default command line in the DTS is required to support
a combined defconfig (pp6xx_defconfig) and I know it does work.
So I will do that.
Did you ever figure out the problem with the combined defconfig?
Not really. But I have been forced to think about that as a new
project will be using some PMCs with 8250 UARTS (PCI) and they are
another way that the console moves from the debug port on the front
panel to somewhere else.
It is very likely that the HAWK UARTS will have to be registered as
platform devices by the board support file itself.
+ help
+ This option enables support for the Motorola (now
Emerson) MVME5100
+ board.
Whitespace
Ok.
+/* Board register addresses. */
+#define BOARD_STATUS_REG 0xfef88080
+#define BOARD_MODFAIL_REG 0xfef88090
+#define BOARD_MODRST_REG 0xfef880a0
+#define BOARD_TBEN_REG 0xfef880c0
+#define BOARD_SW_READ_REG 0xfef880e0
+#define BOARD_GEO_ADDR_REG 0xfef880e8
+#define BOARD_EXT_FEATURE1_REG 0xfef880f0
+#define BOARD_EXT_FEATURE2_REG 0xfef88100
Use a space rather than a tab after #define.
Ok.
+static unsigned int pci_membase;
phys_addr_t
Ok.
+static void mvme5100_restart(char *cmd)
+{
+ u_char *restart;
Is all that tabbing before *restart really necessary?
Will fix.
+ restart = ioremap(BOARD_MODRST_REG, 4);
+ local_irq_disable();
+ mtmsr(mfmsr() | MSR_IP);
+
+ out_8((u_char *) restart, 0x01);
If ioremap() fails you'll panic here.
Ok. Will do in mvme5100_setup_arch.
In any case, you should map things at boot time.
-Scott
Thanks,
Stephen.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH 1/1] powerpc/embedded6xx: Add support for Motorola/Emerson MVME5100.
Stephen N Chivers/AUS/CSC wrote on 08/22/2013 10:58:10 AM:
From: Stephen N Chivers/AUS/CSC
To: Scott Wood scottw...@freescale.com
Cc: b...@kernel.crashing.org, Chris Proctor cproc...@csc.com.au,
linuxppc-dev@lists.ozlabs.org, pau...@samba.org, Stephen N Chivers
schiv...@csc.com.au
Date: 08/22/2013 10:58 AM
Subject: Re: [RFC PATCH 1/1] powerpc/embedded6xx: Add support for
Motorola/Emerson MVME5100.
Scott Wood scottw...@freescale.com wrote on 08/21/2013 09:20:03 AM:
From: Scott Wood scottw...@freescale.com
To: Stephen N Chivers schiv...@csc.com.au
Cc: b...@kernel.crashing.org, Chris Proctor cproc...@csc.com.au,
linuxppc-dev@lists.ozlabs.org, pau...@samba.org
Date: 08/21/2013 09:20 AM
Subject: Re: [RFC PATCH 1/1] powerpc/embedded6xx: Add support for
Motorola/Emerson MVME5100.
On Tue, 2013-08-20 at 13:28 +1100, Stephen N Chivers wrote:
Scott Wood scottw...@freescale.com wrote on 08/09/2013 11:35:20
AM:
From: Scott Wood scottw...@freescale.com
To: Stephen N Chivers schiv...@csc.com.au
Cc: b...@kernel.crashing.org, pau...@samba.org, Chris Proctor
cproc...@csc.com.au, linuxppc-dev@lists.ozlabs.org
Date: 08/09/2013 11:36 AM
Subject: Re: [RFC PATCH 1/1] powerpc/embedded6xx: Add support for
Motorola/Emerson MVME5100.
simple-bus may be applicable here (in addition to a specific
compatible).
The HAWK ASIC is a difficult beast. I still cannot get a positive
identification as to what it is (Motorola/Freescale part number
unknown, not even the part number on the chip on the board
helps).
The best I can come up with is that it is a tsi108 without
the ethenets.
So device_type will be tsi-bridge and compatible will be
tsi108-bridge.
Don't use device_type. compatible should include hawk in the name
(especially if you're not sure what's really in it), and/or the part
number on the chip. If you're convinced it's fully compatible with
tsi108-bridge you can add that as a second compatible value, though
given the uncertainty it's probably better to just teach Linux to look
for the new compatible.
If devices on the bus can be used without any special bus setup or
knowledge, then you can add a compatible of simple-bus to the end.
Why not just look for a chrp,iic node directly?
I was following the model used in other places, like chrp/setup.c.
Not all examples are good examples. :-)
+ if ((np = of_find_compatible_node(NULL, pci,
mpc10x-pci)))
{
Why insist on the device_type?
Following the model in the linkstation (kurobox) platform support.
Drop the device_type check.
+static void
+mvme5100_restart(char *cmd)
+{
+ volatile ulong i = 1000;
+
+
+ local_irq_disable();
+ _nmask_and_or_msr(0, MSR_IP);
Does mtmsr(mfmsr() | MSR_IP) not work?
Don't know. Is from the original code by Matt Porter.
It actually appears that there are no callers remaining that use the
and portion of the functionality. In fact there are no callers that
use it for anything other than setting MSR_IP. :-P
+ out_8((u_char *) BOARD_MODRST_REG, 0x01);
+
+ while (i-- 0);
Do not use a loop to implement a delay.
Taken from the original code. But at this point the board
is going to reset and reboot via firmware, as /sbin/reboot
or /sbin/halt has been invoked.
Still, it's just a bad idea. What's wrong with udelay()?
Or just use an infinite loop. How much value is there really in
timing
out here?
+static void __init
+mvme5100_set_bat(void)
+{
+
+
+ mb();
+ mtspr(SPRN_DBAT1U, 0xf0001ffe);
+ mtspr(SPRN_DBAT1L, 0xf02a);
+ mb();
+ setbat(1, 0xfe00, 0xfe00, 0x0200,
PAGE_KERNEL_NCG);
+}
It is no longer allowed to squat on random virtual address space
like
this. If you really need a BAT you'll have to allocate the
virtual
address properly.
Yes. I found that this was an anathema when researching the port in
2010 but I couldn't find any practical solution at the time.
The code is called early to ensure that the hawk registers are
available.
sysdev/cpm_common.c does the same thing.
What is the correct solution?
ioremap() has special code to function early (using ioremap_bot).
If you still need to use a BAT that early, reserve the space with
asm/fixmap.h or by adding a function to the early ioremap code to just
reserve the space. Or better, improve the ioremap code to be capable
of
creating a BAT (or equivalent) when requested.
It is really interesting. Given that the UART implementation on the
HAWK is such that legacy_serial will not set up an early console it
is very likely that the address translation set up by the bat is not
required.
I can
Re: [RFC PATCH 1/1] powerpc/embedded6xx: Add support for Motorola/Emerson MVME5100.
Scott Wood scottw...@freescale.com wrote on 08/21/2013 09:20:03 AM:
From: Scott Wood scottw...@freescale.com
To: Stephen N Chivers schiv...@csc.com.au
Cc: b...@kernel.crashing.org, Chris Proctor cproc...@csc.com.au,
linuxppc-dev@lists.ozlabs.org, pau...@samba.org
Date: 08/21/2013 09:20 AM
Subject: Re: [RFC PATCH 1/1] powerpc/embedded6xx: Add support for
Motorola/Emerson MVME5100.
On Tue, 2013-08-20 at 13:28 +1100, Stephen N Chivers wrote:
Scott Wood scottw...@freescale.com wrote on 08/09/2013 11:35:20 AM:
From: Scott Wood scottw...@freescale.com
To: Stephen N Chivers schiv...@csc.com.au
Cc: b...@kernel.crashing.org, pau...@samba.org, Chris Proctor
cproc...@csc.com.au, linuxppc-dev@lists.ozlabs.org
Date: 08/09/2013 11:36 AM
Subject: Re: [RFC PATCH 1/1] powerpc/embedded6xx: Add support for
Motorola/Emerson MVME5100.
simple-bus may be applicable here (in addition to a specific
compatible).
The HAWK ASIC is a difficult beast. I still cannot get a positive
identification as to what it is (Motorola/Freescale part number
unknown, not even the part number on the chip on the board helps).
The best I can come up with is that it is a tsi108 without
the ethenets.
So device_type will be tsi-bridge and compatible will be
tsi108-bridge.
Don't use device_type. compatible should include hawk in the name
(especially if you're not sure what's really in it), and/or the part
number on the chip. If you're convinced it's fully compatible with
tsi108-bridge you can add that as a second compatible value, though
given the uncertainty it's probably better to just teach Linux to look
for the new compatible.
If devices on the bus can be used without any special bus setup or
knowledge, then you can add a compatible of simple-bus to the end.
Why not just look for a chrp,iic node directly?
I was following the model used in other places, like chrp/setup.c.
Not all examples are good examples. :-)
+ if ((np = of_find_compatible_node(NULL, pci,
mpc10x-pci)))
{
Why insist on the device_type?
Following the model in the linkstation (kurobox) platform support.
Drop the device_type check.
+static void
+mvme5100_restart(char *cmd)
+{
+ volatile ulong i = 1000;
+
+
+ local_irq_disable();
+ _nmask_and_or_msr(0, MSR_IP);
Does mtmsr(mfmsr() | MSR_IP) not work?
Don't know. Is from the original code by Matt Porter.
It actually appears that there are no callers remaining that use the
and portion of the functionality. In fact there are no callers that
use it for anything other than setting MSR_IP. :-P
+ out_8((u_char *) BOARD_MODRST_REG, 0x01);
+
+ while (i-- 0);
Do not use a loop to implement a delay.
Taken from the original code. But at this point the board
is going to reset and reboot via firmware, as /sbin/reboot
or /sbin/halt has been invoked.
Still, it's just a bad idea. What's wrong with udelay()?
Or just use an infinite loop. How much value is there really in timing
out here?
+static void __init
+mvme5100_set_bat(void)
+{
+
+
+ mb();
+ mtspr(SPRN_DBAT1U, 0xf0001ffe);
+ mtspr(SPRN_DBAT1L, 0xf02a);
+ mb();
+ setbat(1, 0xfe00, 0xfe00, 0x0200,
PAGE_KERNEL_NCG);
+}
It is no longer allowed to squat on random virtual address space
like
this. If you really need a BAT you'll have to allocate the virtual
address properly.
Yes. I found that this was an anathema when researching the port in
2010 but I couldn't find any practical solution at the time.
The code is called early to ensure that the hawk registers are
available.
sysdev/cpm_common.c does the same thing.
What is the correct solution?
ioremap() has special code to function early (using ioremap_bot).
If you still need to use a BAT that early, reserve the space with
asm/fixmap.h or by adding a function to the early ioremap code to just
reserve the space. Or better, improve the ioremap code to be capable of
creating a BAT (or equivalent) when requested.
It is really interesting. Given that the UART implementation on the
HAWK is such that legacy_serial will not set up an early console it
is very likely that the address translation set up by the bat is not
required.
I can probably replace the physical addresses used in:
setup_indirec_pci(hose, 0, 0xfe000cf8, 0xfe000cfc, 0);
with remapped equivalents. But, with the setbat eliminated, the
line:
pcibios_alloc_controller(dev);
silently (remember no early console, due to UART reg-shift) panics.
It is happening at the point where the newly allocated PHB
structure is being added to the hose_list in pci-common.c.
So, I think there is some side effect due to the call to the setbat with
the
PAGE_KERNEL_NCG parameter that I do not yet understand
Re: [RFC PATCH 1/1] powerpc/embedded6xx: Add support for Motorola/Emerson MVME5100.
Scott Wood scottw...@freescale.com wrote on 08/09/2013 11:35:20 AM:
From: Scott Wood scottw...@freescale.com
To: Stephen N Chivers schiv...@csc.com.au
Cc: b...@kernel.crashing.org, pau...@samba.org, Chris Proctor
cproc...@csc.com.au, linuxppc-dev@lists.ozlabs.org
Date: 08/09/2013 11:36 AM
Subject: Re: [RFC PATCH 1/1] powerpc/embedded6xx: Add support for
Motorola/Emerson MVME5100.
On Thu, 2013-08-08 at 11:03 +1100, Stephen N Chivers wrote:
Add support for the Motorola/Emerson MVME5100 Single Board Computer.
The MVME5100 is a 6U form factor VME64 computer with:
- A single MPC7410 or MPC750 CPU
- A HAWK Processor Host Bridge (CPU to PCI) and
MultiProcessor Interrupt Controller (MPIC)
- Up to 500Mb of onboard memory
- A M48T37 Real Time Clock (RTC) and Non-Volatile Memory chip
- Two 16550 compatible UARTS
- Two Intel E100 Fast Ethernets
- Two PCI Mezzanine Card (PMC) Slots
- PPCBug Firmware
The HAWK PHB/MPIC is compatible with the MPC10x devices.
There is no onboard disk support. This is usually provided by
installing a
PMC
in first PMC slot.
This patch revives the board support, it was present in early 2.6
series kernels. The board support in those days was by Matt Porter of
MontaVista Software.
CSC Australia has around 31 of these boards in service. The kernel in
use
for the boards is based on 2.6.31. The boards are operated without
disks
from a file server.
This patch is based on linux-3.11-rc4 and has been boot tested.
Signed-off-by: Stephen Chivers schiv...@csc.com
---
arch/powerpc/boot/dts/mvme5100.dts| 195 ++
arch/powerpc/boot/mvme5100.c | 28 +
arch/powerpc/configs/mvme5100_defconfig | 2597
+
arch/powerpc/platforms/embedded6xx/mvme5100.c | 288 +++
4 files changed, 3108 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/boot/dts/mvme5100.dts
b/arch/powerpc/boot/dts/mvme5100.dts
new file mode 100644
index 000..17fdbc7
--- /dev/null
+++ b/arch/powerpc/boot/dts/mvme5100.dts
@@ -0,0 +1,195 @@
+/*
+ * Device Tree Souce for Motorola/Emerson MVME5100.
+ *
+ * Copyright 2013 CSC Australia Pty. Ltd.
+ *
+ * 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.
+ */
+
+/dts-v1/;
+
+/ {
+ model = MVME5100;
+ compatible = MVME5100;
+ #address-cells = 1;
+ #size-cells = 1;
+
+ aliases {
+ serial0 = serial0;
+ pci0 = pci0;
+ };
+
+ cpus {
+ #address-cells = 1;
+ #size-cells = 0;
+
+ PowerPC,7410 {
+ device_type = cpu;
+ reg = 0x0;
+ /* Following required by dtc but not used */
+ d-cache-line-size = 32;
+ i-cache-line-size = 32;
+ i-cache-size = 32768;
+ d-cache-size = 32768;
+ timebase-frequency = 2500;
+ clock-frequency = 5;
+bus-frequency = 1;
What does following mean? certainly some of those are used, such as
timebase-frequency. In any case, it's not the device tree's job to
document which properties are used by Linux.
Agreed. Will remove.
The words were/are in the KuroboxHG.dts I modelled this dts on.
+ };
+ };
+
+ memory {
+ device_type = memory;
+ reg = 0x0 0x2000;
+ };
+
+ hawk@fef8 {
Unit address does not match reg.
Will make it hawk@fef8.
+ #address-cells = 1;
+ #size-cells = 1;
+ device_type = soc;
Is this really an SoC? In any case, this use of device_type is
deprecated.
That was part of my early attempts to get legacy_serial to set up
the UARTS.
+ compatible = mpc10x;
Don't use wildcards in compatible strings.
simple-bus may be applicable here (in addition to a specific
compatible).
The HAWK ASIC is a difficult beast. I still cannot get a positive
identification as to what it is (Motorola/Freescale part number
unknown, not even the part number on the chip on the board helps).
The best I can come up with is that it is a tsi108 without
the ethenets.
So device_type will be tsi-bridge and compatible will be
tsi108-bridge.
+ store-gathering = 0;
+ ranges = 0x0 0xfef8 0x1;
+ reg = 0xfef8 0x1;
Where is store-gathering documented?
Good question. Again copied from the KuroboxHG dts (which
still has it).
+ serial0: serial@8000
Re: [RFC PATCH 1/1] powerpc/embedded6xx: Add support for Motorola/Emerson MVME5100.
Scott Wood scottw...@freescale.com wrote on 08/20/2013 10:44:31 AM: From: Scott Wood scottw...@freescale.com To: Stephen N Chivers schiv...@csc.com.au Cc: Chris Proctor cproc...@csc.com.au, Kumar Gala ga...@kernel.crashing.org, linuxppc-dev@lists.ozlabs.org, pau...@samba.org Date: 08/20/2013 10:44 AM Subject: Re: [RFC PATCH 1/1] powerpc/embedded6xx: Add support for Motorola/Emerson MVME5100. On Mon, 2013-08-19 at 07:58 +1100, Stephen N Chivers wrote: The serial console setup in 'legacy_serial' does not support reg-shift or reg-offset properties and so a preferred_console is not added by it. The DTS file for the board does specify the register shift so that 'of_serial' will correctly setup the UARTS. But that is too late, the preferred console will be tty0 as the .config derived from ppc6xx_defconfig has CONF_VT_CONSOLE set. In the test kernels I have built 'con_init' in the VT support is always called before serial8250_console_init. Are you setting console=ttyS0,baud on the kernel command line? Yes, most certainly. During the testing was specifying the command line in the dts as doing so in the .config would be wrong. When booting got: Linux/PowerPC Load: console=ttyS0,9600 ip=dhcp root=/dev/nfs So no problem there. I did try modifying legacy_serial to correctly support the tsi-bridge UARTS and add the preferred console but encountered even more problems in 8250_core when registering the serial console (to the point of having a silently panic'ing kernel). So I think for the moment, the board will need its own default config. Which config symbol is relevant here? On reflection, maybe it wasn't panicing as in the configuration I was using the boot times were quite protracted, something to do with the network setup and e100 PHY initialisation. (Embedding the e100 firmware in the kernel appears to fix that). But at the point at which I gave up chasing the problem, the machine was not showing any sign of life within what would be regarded as normal times. As to config symbol I don't know. This may be the first attempt to combine PPC6xx configurations with their embedded brethren. What is certain that there is an incompatibility between what is required for the quirks of the MVME-5100 onboard UARTS and the configuration required for the non-embedded PPC6xx platforms. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH 1/1] powerpc/embedded6xx: Add support for Motorola/Emerson MVME5100.
Scott Wood scottw...@freescale.com wrote on 08/13/2013 08:04:30 AM: From: Scott Wood scottw...@freescale.com To: Stephen N Chivers schiv...@csc.com.au Cc: Chris Proctor cproc...@csc.com.au, Kumar Gala ga...@kernel.crashing.org, linuxppc-dev@lists.ozlabs.org, pau...@samba.org Date: 08/13/2013 08:04 AM Subject: Re: [RFC PATCH 1/1] powerpc/embedded6xx: Add support for Motorola/Emerson MVME5100. On Tue, 2013-08-13 at 08:57 +1100, Stephen N Chivers wrote: Scott Wood scottw...@freescale.com wrote on 08/09/2013 04:07:24 AM: From: Scott Wood scottw...@freescale.com To: Kumar Gala ga...@kernel.crashing.org Cc: Stephen N Chivers schiv...@csc.com.au, pau...@samba.org, linuxppc-dev@lists.ozlabs.org, Chris Proctor cproc...@csc.com.au Date: 08/09/2013 04:08 AM Subject: Re: [RFC PATCH 1/1] powerpc/embedded6xx: Add support for Motorola/Emerson MVME5100. On Thu, 2013-08-08 at 10:30 -0500, Kumar Gala wrote: Also, we don't take full defconfigs in the tree, look at 'make savedefconfig' Why does this board need its own defconfig at all? Just add it to ppc6xx_defconfig. The boards firmware as stated above is PPCBug. PPCBug is not Open Firmware compatible. There is no U-Boot support for the board. I'm not sure why that precludes the use of ppc6xx_defconfig... In ppc6xx_defconfig the e100 network device and NFS support is modular and that forces the use of an initrd. OK, then let's enable those in ppc6xx_defconfig. We do in a lot of the other defconfigs (such as 85xx and derivatives). PPCBugs network boot command takes only one file argument and so makes it difficult to use an initrd. So the choices are: - Providing a defconfig for the board, - Building the kernel with the initrd embedded in it, - Finding an alternative boot loader, - Doing the board support for U-Boot. The first choice is simple and documents the configuration of the board without mixing it into ppc6xx_defconfig. The first choice means your board would get much less build-testing, and would increase maintenance costs of defconfig changes (and/or lead to divergence from other defconfigs that doesn't actually have anything to do with this board or its use cases). The fifth choice is add what you need to ppc6xx_defconfig. Within reason of course, but I think a common PCI network device and NFS root support is reasonable. Thanks for the suggestion. I have tried it and ppc6xx_defconfig does generate a viable kernel for the MVME5100 but there is a total lack of serial console messages. The reason is due to the requirement for a register shift to access the UART register(s) on (via) the HAWK ASIC. The HAWK ASIC is very likely to be a MPC107/TSI107, making it compatible with tsi-bridge. The TSI bridges also require register shifts to access their built-in UARTS. I will check the MPC107 data sheet against the TSI107 datasheet and the MVME5100 programmers manual later today. The serial console setup in 'legacy_serial' does not support reg-shift or reg-offset properties and so a preferred_console is not added by it. The DTS file for the board does specify the register shift so that 'of_serial' will correctly setup the UARTS. But that is too late, the preferred console will be tty0 as the .config derived from ppc6xx_defconfig has CONF_VT_CONSOLE set. In the test kernels I have built 'con_init' in the VT support is always called before serial8250_console_init. I did try modifying legacy_serial to correctly support the tsi-bridge UARTS and add the preferred console but encountered even more problems in 8250_core when registering the serial console (to the point of having a silently panic'ing kernel). So I think for the moment, the board will need its own default config. I think similar problems would occur for the Holly and MPC7448_HPC2 boards as these also have tsi-bridges, but their dts files do not specify the reg-shift properties. This begs the question do the serial consoles for Holly and MPC7448_HPC2 actually work? -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH 1/1] powerpc/embedded6xx: Add support for Motorola/Emerson MVME5100.
Kumar Gala ga...@kernel.crashing.org wrote on 08/09/2013 01:30:53 AM: From: Kumar Gala ga...@kernel.crashing.org To: Stephen N Chivers schiv...@csc.com.au Cc: b...@kernel.crashing.org, pau...@samba.org, Chris Proctor cproc...@csc.com.au, linuxppc-dev@lists.ozlabs.org Date: 08/09/2013 01:31 AM Subject: Re: [RFC PATCH 1/1] powerpc/embedded6xx: Add support for Motorola/Emerson MVME5100. On Aug 7, 2013, at 7:03 PM, Stephen N Chivers wrote: Add support for the Motorola/Emerson MVME5100 Single Board Computer. The MVME5100 is a 6U form factor VME64 computer with: - A single MPC7410 or MPC750 CPU - A HAWK Processor Host Bridge (CPU to PCI) and MultiProcessor Interrupt Controller (MPIC) - Up to 500Mb of onboard memory - A M48T37 Real Time Clock (RTC) and Non-Volatile Memory chip - Two 16550 compatible UARTS - Two Intel E100 Fast Ethernets - Two PCI Mezzanine Card (PMC) Slots - PPCBug Firmware The HAWK PHB/MPIC is compatible with the MPC10x devices. There is no onboard disk support. This is usually provided by installing a PMC in first PMC slot. This patch revives the board support, it was present in early 2.6 series kernels. The board support in those days was by Matt Porter of MontaVista Software. CSC Australia has around 31 of these boards in service. The kernel in use for the boards is based on 2.6.31. The boards are operated without disks from a file server. This patch is based on linux-3.11-rc4 and has been boot tested. Signed-off-by: Stephen Chivers schiv...@csc.com --- arch/powerpc/boot/dts/mvme5100.dts| 195 ++ arch/powerpc/boot/mvme5100.c | 28 + arch/powerpc/configs/mvme5100_defconfig | 2597 + arch/powerpc/platforms/embedded6xx/mvme5100.c | 288 +++ 4 files changed, 3108 insertions(+), 0 deletions(-) Please look at fixing the white space issues you seem to have throughout this patch. The mailing agent is Lotus Notes. It is pathologically against tabs. I did make best effort to ensure that tabs would not get crunched but sadly this has failed. Also, we don't take full defconfigs in the tree, look at 'make savedefconfig' Ok. - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH 1/1] powerpc/embedded6xx: Add support for Motorola/Emerson MVME5100.
Scott Wood scottw...@freescale.com wrote on 08/09/2013 04:07:24 AM: From: Scott Wood scottw...@freescale.com To: Kumar Gala ga...@kernel.crashing.org Cc: Stephen N Chivers schiv...@csc.com.au, pau...@samba.org, linuxppc-dev@lists.ozlabs.org, Chris Proctor cproc...@csc.com.au Date: 08/09/2013 04:08 AM Subject: Re: [RFC PATCH 1/1] powerpc/embedded6xx: Add support for Motorola/Emerson MVME5100. On Thu, 2013-08-08 at 10:30 -0500, Kumar Gala wrote: On Aug 7, 2013, at 7:03 PM, Stephen N Chivers wrote: Add support for the Motorola/Emerson MVME5100 Single Board Computer. The MVME5100 is a 6U form factor VME64 computer with: - A single MPC7410 or MPC750 CPU - A HAWK Processor Host Bridge (CPU to PCI) and MultiProcessor Interrupt Controller (MPIC) - Up to 500Mb of onboard memory - A M48T37 Real Time Clock (RTC) and Non-Volatile Memory chip - Two 16550 compatible UARTS - Two Intel E100 Fast Ethernets - Two PCI Mezzanine Card (PMC) Slots - PPCBug Firmware The HAWK PHB/MPIC is compatible with the MPC10x devices. There is no onboard disk support. This is usually provided by installing a PMC in first PMC slot. This patch revives the board support, it was present in early 2.6 series kernels. The board support in those days was by Matt Porter of MontaVista Software. CSC Australia has around 31 of these boards in service. The kernel in use for the boards is based on 2.6.31. The boards are operated without disks from a file server. This patch is based on linux-3.11-rc4 and has been boot tested. Signed-off-by: Stephen Chivers schiv...@csc.com --- arch/powerpc/boot/dts/mvme5100.dts| 195 ++ arch/powerpc/boot/mvme5100.c | 28 + arch/powerpc/configs/mvme5100_defconfig | 2597 + arch/powerpc/platforms/embedded6xx/mvme5100.c | 288 +++ 4 files changed, 3108 insertions(+), 0 deletions(-) Please look at fixing the white space issues you seem to have throughout this patch. Also, we don't take full defconfigs in the tree, look at 'make savedefconfig' Why does this board need its own defconfig at all? Just add it to ppc6xx_defconfig. The boards firmware as stated above is PPCBug. PPCBug is not Open Firmware compatible. There is no U-Boot support for the board. In ppc6xx_defconfig the e100 network device and NFS support is modular and that forces the use of an initrd. PPCBugs network boot command takes only one file argument and so makes it difficult to use an initrd. So the choices are: - Providing a defconfig for the board, - Building the kernel with the initrd embedded in it, - Finding an alternative boot loader, - Doing the board support for U-Boot. The first choice is simple and documents the configuration of the board without mixing it into ppc6xx_defconfig. The second choice would, I believe, fail for ppc6xx_defconfig when built by the automaton at kisskb. The failure would be caused by the lack of a ramdisk in the vanilla kernel source. For the third, I spent a lot of time over the weekend looking for an alternative boot loader to no avail. The last choice is possibly difficult and would take considerable time. Other possibilities include: - a boot script for PPCBug that loads the initrd first and then executes the network boot command. I believe that the initrd start and size can be specified in the dts file. - porting the tftplilo program used with the ancient MVME-167 68k SBCs. This is probably feasible as PPCBug is a descendant of the older 167Bug. tftplilo uses the network routines in 167Bug to do its work and similar things exist in PPCBug. Suggestions please. -Scott Stephen Chivers. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
