* Re: how to debug the linux kernel with a BDI2000
From: Detlev Zundel @ 2007-08-30 9:52 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <479723497.472031188208291804.JavaMail.coremail@bj163app103.163.com>
Hi Denny,
> My kernel hanged in when passed the parameters to it, and I dump nothing from
> the log_buf, so I guss it is crashed at the very beginning.
>
> however I didn't know how to setup the KDB to load the kernel with the BDI2000
> ethernet? is there anyone has even loaded and debugged the kernel with the
> BDI2000 ethernet? if so pls show me how it goes?
You don't need KDB to use the BDI2000 to debug a linux kernel, in fact
you need nothing on the target side. Simply attach the BDI to your
hardware, and use a (cross-)gdb with the "target remote
<ipaddr>:<port>" command. Our DULG shows how to do that with
U-Boot[1]. Debugging (static) Linux is exactly the same...
Cheers
Detlev
[1] http://www.denx.de/wiki/view/DULG/DebuggingUBoot
--
debian is a prototype for a future version of emacs.
-- Thien-Thi Nguyen in <7eekubiffq.fsf@ada2.unipv.it>
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: dzu@denx.de
^ permalink raw reply
* Re: STK5200 pci_enable_device problem
From: Oliver Rutsch @ 2007-08-30 9:19 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <20070829233106.9766C24044@gemini.denx.de>
Hi again,
>
> As mentioned above, with arch/powerpc you always need a device tree
> blob.
>
> Best regards,
>
> Wolfgang Denk
>
Thanks, Wolfang, now it's booting fine!
I've updated u-boot to the newest git version, builded the device tree
file and now everything's working.
Bye,
--
Dipl. Ing. Oliver Rutsch
^ permalink raw reply
* Re: [PATCH] ppc32/8xx: Fix r3 trashing due to 8MB TLB page instantiation
From: Jochen Friedrich @ 2007-08-30 8:48 UTC (permalink / raw)
To: Kumar Gala; +Cc: linux-kernel, linuxppc-embedded
In-Reply-To: <611B8BA7-89B3-4DA0-A248-0FB57E4654ED@kernel.crashing.org>
Hi Kumar,
> do we need this in arch/powerpc as well?
No. At least not until these patches are applied to powerpc, as well:
8f069b1a90bd97bf6d59a02ecabf0173d9175609 [PATCH] powerpc/8xx: Use 8MB D-TLB's for kernel static mapping faults
3ea4807de7b2c5c903380ba2c2e7150bee942f42 [PATCH] powerpc/8xx: last two 8MB D-TLB entries are incorrectly set
c51e078f82096a7d35ac8ec2416272e843a0e1c4 [PATCH] ppc32/8xx: Fix r3 trashing due to 8MB TLB page instantiation
Thanks,
Jochen
^ permalink raw reply
* [POWERPC] PCI Bug fix for MRM failure in PPC 440EPx
From: Stefan Roese @ 2007-08-30 8:33 UTC (permalink / raw)
To: linuxppc-dev
Problem Description and Fix : Memory Read Multiples(MRM) do not work
correctly on PPC 440EPX based systems. A PCI driver determines whether
MRMs are supported by reading the PCI cache line size register. If this
value is zero then MRMs are not supported. However some PCI drivers
write to the PCI cache line size register on initialization. This
results in MRMs being sent to system memory on 440EPX based systems.
Since MRMs do not work correctly in 440EPX based systems this may cause
system hang. This patch solves this problem by modifying the PPC
platform specific PCI configuration register write function, by forcing
any value written to PCI_CACHE_LINE_SIZE register to be 0. This fix was
tested on different PCI cards : i.e. Silicon Image ATA card and Intel
E1000 GIGE card. On Silicon Image ATA card without this fix in place
creating a filesystem on IDE drive "mke2fs /dev/hda" was hanging the
system. MRMs issued by the PCI card were seen on the PCI analyzer since
the Silicon Image driver was setting the PCI_CACHE_LINE_SIZE register to
255. With this patch the PCI_CACHE_LINE_SIZE register was 0 and only
Memory Reads were seen on PCI analyzer.
Signed-off-by: Pravin M. Bathija <pbathija@amcc.com>
Signed-off-by: Stefan Roese <sr@denx.de>
---
I know this patch is a little "dirty", but perhaps somebody has a better
idea to fix this problem. Thanks.
commit bae603c964831f26d9816e85ffc923afc3275e44
tree 6fb93d22bcb56670a8e6f344afbe8a4a8438692c
parent b07d68b5ca4d55a16fab223d63d5fb36f89ff42f
author Stefan Roese <sr@denx.de> Thu, 30 Aug 2007 10:30:09 +0200
committer Stefan Roese <sr@denx.de> Thu, 30 Aug 2007 10:30:09 +0200
arch/powerpc/sysdev/indirect_pci.c | 7 +++++++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/sysdev/indirect_pci.c b/arch/powerpc/sysdev/indirect_pci.c
index 5294560..d694acc 100644
--- a/arch/powerpc/sysdev/indirect_pci.c
+++ b/arch/powerpc/sysdev/indirect_pci.c
@@ -128,6 +128,13 @@ indirect_write_config(struct pci_bus *bus, unsigned int devfn, int offset,
* suitably aligned and that len is 1, 2 or 4.
*/
cfg_data = hose->cfg_data + (offset & 3);
+
+#if defined(CONFIG_440EPX) || defined(CONFIG_440GRX)
+ /* Workaround for MRM failure in 440EPx/GRx */
+ if (offset == PCI_CACHE_LINE_SIZE)
+ val = 0;
+#endif
+
switch (len) {
case 1:
out_8(cfg_data, val);
^ permalink raw reply related
* Re: Linux doesn not boot from u-boot on ML403
From: Miroslaw Dach @ 2007-08-30 7:50 UTC (permalink / raw)
To: Grant Likely; +Cc: Leonid, linuxppc-embedded
In-Reply-To: <fa686aa40708290817k897f8c2y5fdf12e5a48cc0ac@mail.gmail.com>
Hi All,
I have modified the linux kernel to have it smaller than I have
tried once again with bootm and uImage. The result is as shown below:
1. First I have downloaded u-boot via jtag:
XMD% dow u-boot.elf
section, .text: 0x01300000-0x0131513c
section, .resetvec: 0x0131513c-0x01315140
section, .rodata: 0x01315140-0x01317d10
section, .reloc: 0x01317e00-0x0131877c
section, .data: 0x0131877c-0x01318c40
section, .data.rel: 0x01318c40-0x01318c6c
section, .data.rel.local: 0x01318c6c-0x013190a4
section, .u_boot_cmd: 0x013190a4-0x01319314
section, .bss: 0x01319400-0x0131df04
Downloaded Program u-boot13Debug.elf
Setting PC with program start addr = 0x01300100
PC reset to 0x01300100, Clearing MSR Register
XMD% run
2. The u-boot has started properly
3. Than I have loaded via tftp the uImage
=> tftp 0xf00000 uImage
TFTP from server 129.117.144.113; our IP address is 129.117.144.157
Filename 'uImage'.
Load address: 0xf00000
Loading: #################################################################
#################################################################
##############################################################
done
Bytes transferred = 981900 (efb8c hex)
=> bootm 0xf00000
## Booting image at 00f00000 ...
Image Name: Linux-2.6.21-rc6
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 981836 Bytes = 958.8 kB
Load Address: 00400000
Entry Point: 00400000
Uncompressing Kernel Image ... OK
Bad trap at PC: c0002218, SR: 21030, vector=1100
NIP: C0002218 XER: 00000000 LR: 00400018 REGS: 01fc0578 TRAP: 1100 DAR: 01FF71AC
MSR: 00021030 EE: 0 PR: 0 FP: 0 ME: 1 IR/DR: 11
GPR00: C0002218 01FC0668 B022C01B C00003C0 C0000000 00000000 007FFF00 007FFF7C
GPR08: C1FD9AC0 01FC0C0C 0000AE58 01FFEEC4 01FBFCA0 FFFFFFFF 02000E00 00000001
GPR16: 007FFF7C 00400000 00800000 FFFFFFFF 007FFF00 01FFA104 00000000 01FC0760
GPR24: 00000002 007FFE80 00000001 007FFF7C 007FFF00 00000000 00000000 007FFE80
Call backtrace:
Exception in kernel pc c0002218 signal 0
4. I have stopped the system and I have reloaded u-boot to see what is in
the RAM memory:
My __log_buf (of uImage) is under the address :
c02070c4 b __log_buf
So I have dumped the data from this memory location:
=> md 0x2070c4 100
002070c4: 20257320 69732043 6f727235 70746564 %s is Corr5pted
002070d4: 20615400 25720000 7265646d 72654154 aT.%r..redmreAT
002070e4: 00000000 6b65322a 656c0004 67617465 ....ke2*el..gate
002070f4: 64000000 72614000 6d727400 6a652232 d...ra@.mrt.je"2
00207104: 61000000 62697264 00000000 2f655463 a...bird..../eTc
00207114: 2f497060 6b652465 322f7256 5f7052c5 /Ip`ke$e2/rV_pR.
00207124: 746f7100 676c2a62 616c0000 6e6f7748 toq.gl*bal..nowH
00207134: 65726500 73693465 00000200 27657462 ere.si4e....'etb
00207144: 2f697070 6f752065 322eaa50 5f73436f /ippou e2..P_sCo
00207154: 70655100 2f657022 2f697062 6f757441 peQ./ep"/ipboutA
00207164: 32277274 5b722121 6c6d7380 2f657413 2'rt[r!!lms./et.
00207174: 2f697872 6f357060 322f3264 5f647364 /ixro5p`2/2d_dsd
00207184: 69656c64 00000000 30782520 32780000 ield....0x% 2x..
00207194: 64656640 756c2400 2f653422 2f697070 def@ul$./e4"/ipp
002071a4: 6f757445 322f7274 5f746162 6c654300 outE2/rt_tableC.
002071b4: 10099124 100ae0d4 100aa0e8 100b1838 ...$...........8
002071c4: 100aa3e4 00000000 00000000 00000000 ................
002071d4: 100a6070 100ae0f8 100aa0ec 100ae100 ..`p............
I do not understand what is going on with my kernel image.
When I try to start zImage.elf with bootelf command the system hangs during
uncompressing.
When I try to start uImage with bootm command the image is uncompressed
but it does not start properly.
Any idea
Best Regards
Mirek
On Wed, 29 Aug 2007, Grant Likely wrote:
> On 8/29/07, Miroslaw Dach <miroslaw.dach@psi.ch> wrote:
> > Hi Grant,
> >
> > My zImage.elf has 1.1 MB and uImage 968 KB.
> > Could you tell me please how to hook up GDB to debug u-boot?
>
> Ah-HA! You're using the wrong type of kernel image. When booting
> from u-boot, you should be using a 'uImage', not a 'zImage.elf'.
> (generated with 'make uImage' in the kernel tree). An you should use
> the 'bootm' command to boot the kernel.
>
> With bootm, u-boot can pass parameters to the kernel and it is u-boot
> that does the uncompression (instead of the zImage wrapper).
>
> Cheers,
> g.
>
>
--
=============================================================================
Miroslaw Dach (Miroslaw.Dach@psi.ch) - SLS/Controls Group
PSI - Paul Scherrer Institut CH-5232 Villigen
=============================================================================
^ permalink raw reply
* Re: spin_lock doesn't work?!?
From: melinda develey @ 2007-08-30 6:30 UTC (permalink / raw)
To: Wolfgang Reissnegger; +Cc: linuxppc-embedded
In-Reply-To: <20070829214050.8C47A1A2804D@mail19-sin.bigfish.com>
[-- Attachment #1: Type: text/plain, Size: 683 bytes --]
>You should still put the spin_lock calls into your code because >you
>never know if someone else will compile it and for another >target. If
>someone would, for example, compile the same code for a SMP >machine then
>the spin_lock will actually lock.
I used the spinlock both in an interrupt handler to protect a group of variables (because in an interrupt I can't use a semaphore) and the same spinlock in a ioctl handler where the same group of variables is accessed. Is this wrong? I have a 2.6.19.2 linux kernel.
Thank you,
Melinda.
---------------------------------
Ready for the edge of your seat? Check out tonight's top picks on Yahoo! TV.
[-- Attachment #2: Type: text/html, Size: 985 bytes --]
^ permalink raw reply
* RE: Network is blocked till ping is issued
From: DI BACCO ANTONIO - technolabs @ 2007-08-30 6:24 UTC (permalink / raw)
To: Florian A. Voegel, linuxppc-embedded
In-Reply-To: <20070830010752.0ca3d309.fvoegel@carangul.com>
> sounds to me like it could be a classical ARP problem. Have you
checked the ARP cache on the non-Linux
> machine?
But if Linux received the SYN packet of TCP connection, shouldn't the
Linux machine reply to the source mac address of SYN packet with a
SYN,ACK packet?
^ permalink raw reply
* Re: [PATCH 2/3] Introduce new CPM device bindings.
From: David Gibson @ 2007-08-30 5:58 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <20070830054854.GA21533@ld0162-tx32.am.freescale.net>
On Thu, Aug 30, 2007 at 12:48:54AM -0500, Scott Wood wrote:
> On Thu, Aug 30, 2007 at 10:55:59AM +1000, David Gibson wrote:
> > Am I correct in thinking that it's basically an arch/ppc versus
> > arch/powerpc thing. In which case couldn't you use CONFIG_PPC_MERGE
> > instead?
>
> The idea was to allow boards to be converted incrementally, as I don't
> have access to test 100% of the boards that use the CPM code.
Hrm. Right. This is still problematical, because what happens if you
have both old-binding and new-binding boards configured simultaneously?
> > > It has a phandle to the phy node... if you mean the mdio bus node, why?
> >
> > Well, I'm just working of the example of 4xx EMAC. The way it does
> > mdio, it wants a handle on the mdio bus to perform various operations
> > there as well on the phy to tell it how to address them. fsl-enet may
> > do things differently and have no particular need for such a handle.
>
> Even if it did need such a handle, couldn't it just look at the phy
> node's parent?
Well, yes, but it's just a bit more fiddling. For the purposes of
emac, it seemed simpler to supply pass the mdio phandle as well.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [PATCH 8/9] mpc82xx: Update mpc8272ads, and factor out PCI and reset.
From: Scott Wood @ 2007-08-30 5:56 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <66A3DBEB-412D-4229-88DA-B47F3256CEF6@kernel.crashing.org>
On Wed, Aug 29, 2007 at 05:41:17PM -0500, Kumar Gala wrote:
> NACK.
>
> I don't want pq2 to be the only platform that has the PCI bus
> separate from the PCI controller.
Could you articulate the reasons why you'd rather have a mishmash of crap
in the soc node's ranges property?
-Scott
^ permalink raw reply
* Re: [PATCH 2/3] Introduce new CPM device bindings.
From: Scott Wood @ 2007-08-30 5:48 UTC (permalink / raw)
To: galak, linuxppc-dev
In-Reply-To: <20070830005559.GB22844@localhost.localdomain>
On Thu, Aug 30, 2007 at 10:55:59AM +1000, David Gibson wrote:
> Am I correct in thinking that it's basically an arch/ppc versus
> arch/powerpc thing. In which case couldn't you use CONFIG_PPC_MERGE
> instead?
The idea was to allow boards to be converted incrementally, as I don't
have access to test 100% of the boards that use the CPM code.
> > It has a phandle to the phy node... if you mean the mdio bus node, why?
>
> Well, I'm just working of the example of 4xx EMAC. The way it does
> mdio, it wants a handle on the mdio bus to perform various operations
> there as well on the phy to tell it how to address them. fsl-enet may
> do things differently and have no particular need for such a handle.
Even if it did need such a handle, couldn't it just look at the phy
node's parent?
-Scott
^ permalink raw reply
* [PATCH 3/3] libfdt: Add fdt_parent_offset() and supporting functions
From: David Gibson @ 2007-08-30 4:54 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev
In-Reply-To: <20070830045253.GA32543@localhost.localdomain>
This patch adds an fdt_parent_offset() function which returns an
offset to the parent node of a given node. It also adds two helper
functions which are used to implement fdt_parent_offset() but are also
exported: fdt_supernode_atdepth_offset() which returns the ancestor of
a given node at a specified depth from the root of the tree, and
fdt_node_depth() which returns the depth of a given node.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
---
libfdt/fdt_ro.c | 68 ++++++++++++++++++
libfdt/libfdt.h | 10 ++
tests/Makefile.tests | 2
tests/parent_offset.c | 90 ++++++++++++++++++++++++
tests/run_tests.sh | 2
tests/supernode_atdepth_offset.c | 144 +++++++++++++++++++++++++++++++++++++++
6 files changed, 314 insertions(+), 2 deletions(-)
Index: dtc/libfdt/fdt_ro.c
===================================================================
--- dtc.orig/libfdt/fdt_ro.c 2007-08-29 14:28:32.000000000 +1000
+++ dtc/libfdt/fdt_ro.c 2007-08-30 14:28:35.000000000 +1000
@@ -349,3 +349,71 @@ int fdt_get_path(const void *fdt, int no
buf[p] = '\0';
return p;
}
+
+int fdt_supernode_atdepth_offset(const void *fdt, int nodeoffset,
+ int supernodedepth, int *nodedepth)
+{
+ int level = -1;
+ uint32_t tag;
+ int offset, nextoffset = 0;
+ int supernodeoffset = -FDT_ERR_INTERNAL;
+
+ CHECK_HEADER(fdt);
+
+ if (supernodedepth < 0)
+ return -FDT_ERR_NOTFOUND;
+
+ do {
+ offset = nextoffset;
+ tag = _fdt_next_tag(fdt, offset, &nextoffset);
+ switch (tag) {
+ case FDT_END:
+ return -FDT_ERR_BADOFFSET;
+
+ case FDT_BEGIN_NODE:
+ level++;
+ if (level == supernodedepth)
+ supernodeoffset = offset;
+ break;
+
+ case FDT_END_NODE:
+ level--;
+ break;
+
+ case FDT_PROP:
+ case FDT_NOP:
+ break;
+
+ default:
+ return -FDT_ERR_BADSTRUCTURE;
+ }
+ } while (offset < nodeoffset);
+
+ if (nodedepth)
+ *nodedepth = level;
+
+ if (supernodedepth > level)
+ return -FDT_ERR_NOTFOUND;
+ return supernodeoffset;
+}
+
+int fdt_node_depth(const void *fdt, int nodeoffset)
+{
+ int nodedepth;
+ int err;
+
+ err = fdt_supernode_atdepth_offset(fdt, nodeoffset, 0, &nodedepth);
+ if (err)
+ return (err < 0) ? err : -FDT_ERR_INTERNAL;
+ return nodedepth;
+}
+
+int fdt_parent_offset(const void *fdt, int nodeoffset)
+{
+ int nodedepth = fdt_node_depth(fdt, nodeoffset);
+
+ if (nodedepth < 0)
+ return nodedepth;
+ return fdt_supernode_atdepth_offset(fdt, nodeoffset,
+ nodedepth - 1, NULL);
+}
Index: dtc/libfdt/libfdt.h
===================================================================
--- dtc.orig/libfdt/libfdt.h 2007-08-30 13:26:56.000000000 +1000
+++ dtc/libfdt/libfdt.h 2007-08-30 14:26:40.000000000 +1000
@@ -74,7 +74,10 @@
#define FDT_ERR_BADSTRUCTURE 10
#define FDT_ERR_BADLAYOUT 11
-#define FDT_ERR_MAX 11
+/* "Can't happen" error indicating a bug in libfdt */
+#define FDT_ERR_INTERNAL 12
+
+#define FDT_ERR_MAX 12
#define fdt_get_header(fdt, field) \
(fdt32_to_cpu(((const struct fdt_header *)(fdt))->field))
@@ -138,6 +141,11 @@ static inline void *fdt_getprop_w(void *
int fdt_get_path(const void *fdt, int nodeoffset, char *buf, int buflen);
+int fdt_supernode_atdepth_offset(const void *fdt, int nodeoffset,
+ int supernodedepth, int *nodedepth);
+int fdt_node_depth(const void *fdt, int nodeoffset);
+int fdt_parent_offset(const void *fdt, int nodeoffset);
+
/* Write-in-place functions */
int fdt_setprop_inplace(void *fdt, int nodeoffset, const char *name,
const void *val, int len);
Index: dtc/tests/Makefile.tests
===================================================================
--- dtc.orig/tests/Makefile.tests 2007-08-30 13:43:53.000000000 +1000
+++ dtc/tests/Makefile.tests 2007-08-30 14:17:07.000000000 +1000
@@ -1,5 +1,5 @@
LIB_TESTS_L = root_node find_property subnode_offset path_offset \
- get_name getprop get_path \
+ get_name getprop get_path supernode_atdepth_offset parent_offset \
notfound \
setprop_inplace nop_property nop_node \
sw_tree1 \
Index: dtc/tests/run_tests.sh
===================================================================
--- dtc.orig/tests/run_tests.sh 2007-08-30 13:44:15.000000000 +1000
+++ dtc/tests/run_tests.sh 2007-08-30 14:17:14.000000000 +1000
@@ -38,6 +38,8 @@ tree1_tests () {
run_test get_name $TREE
run_test getprop $TREE
run_test get_path $TREE
+ run_test supernode_atdepth_offset $TREE
+ run_test parent_offset $TREE
run_test notfound $TREE
# Write-in-place tests
Index: dtc/tests/supernode_atdepth_offset.c
===================================================================
--- /dev/null 1970-01-01 00:00:00.000000000 +0000
+++ dtc/tests/supernode_atdepth_offset.c 2007-08-30 13:51:45.000000000 +1000
@@ -0,0 +1,144 @@
+/*
+ * libfdt - Flat Device Tree manipulation
+ * Testcase for fdt_supernode_atdepth_offset()
+ * Copyright (C) 2006 David Gibson, IBM Corporation.
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public License
+ * as published by the Free Software Foundation; either version 2.1 of
+ * the License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+#define _GNU_SOURCE
+
+#include <stdlib.h>
+#include <stdio.h>
+#include <string.h>
+#include <stdint.h>
+
+#include <fdt.h>
+#include <libfdt.h>
+
+#include "tests.h"
+#include "testdata.h"
+
+int path_depth(const char *path)
+{
+ const char *p;
+ int depth = 0;
+
+ if (path[0] != '/')
+ TEST_BUG();
+
+ if (strcmp(path, "/") == 0)
+ return 0;
+ for (p = path; *p; p++)
+ if (*p == '/')
+ depth++;
+
+ /* Special case for path == "/" */
+ if (p == (path + 1))
+ return 0;
+ else
+ return depth;
+}
+
+int path_prefix(const char *path, int depth)
+{
+ const char *p;
+ int i;
+
+ if (path[0] != '/')
+ TEST_BUG();
+
+ if (depth == 0)
+ return 1;
+
+ p = path;
+ for (i = 0; i < depth; i++)
+ p = strchrnul(p+1, '/');
+
+ return p - path;
+}
+
+void check_supernode_atdepth(struct fdt_header *fdt, const char *path,
+ int depth)
+{
+ int pdepth = path_depth(path);
+ char *superpath;
+ int nodeoffset, supernodeoffset, superpathoffset;
+ int nodedepth;
+
+ superpath = strndupa(path, path_prefix(path, depth));
+ verbose_printf("Path %s (%d), depth %d, supernode is %s\n",
+ path, pdepth, depth, superpath);
+
+ nodeoffset = fdt_path_offset(fdt, path);
+ if (nodeoffset < 0)
+ FAIL("fdt_path_offset(%s): %s", path, fdt_strerror(nodeoffset));
+ superpathoffset = fdt_path_offset(fdt, superpath);
+ if (superpathoffset < 0)
+ FAIL("fdt_path_offset(%s): %s", superpath,
+ fdt_strerror(superpathoffset));
+
+ supernodeoffset = fdt_supernode_atdepth_offset(fdt, nodeoffset,
+ depth, &nodedepth);
+ if (supernodeoffset < 0)
+ FAIL("fdt_supernode_atdepth_offset(): %s",
+ fdt_strerror(supernodeoffset));
+
+ if (supernodeoffset != superpathoffset)
+ FAIL("fdt_supernode_atdepth_offset() returns %d instead of %d",
+ supernodeoffset, superpathoffset);
+
+ if (nodedepth != pdepth)
+ FAIL("fdt_supernode_atdept_offset() returns node depth %d "
+ "instead of %d", nodedepth, pdepth);
+}
+
+void check_supernode_overdepth(struct fdt_header *fdt, const char *path)
+{
+ int pdepth = path_depth(path);
+ int nodeoffset, err;
+
+ nodeoffset = fdt_path_offset(fdt, path);
+ if (nodeoffset < 0)
+ FAIL("fdt_path_offset(%s): %s", path, fdt_strerror(nodeoffset));
+
+ err = fdt_supernode_atdepth_offset(fdt, nodeoffset, pdepth + 1, NULL);
+ if (err != -FDT_ERR_NOTFOUND)
+ FAIL("fdt_supernode_atdept_offset(%s, %d) returns %d instead "
+ "of FDT_ERR_NOTFOUND", path, pdepth+1, err);
+}
+
+void check_path(struct fdt_header *fdt, const char *path)
+{
+ int i;
+
+ for (i = 0; i <= path_depth(path); i++)
+ check_supernode_atdepth(fdt, path, i);
+ check_supernode_overdepth(fdt, path);
+}
+int main(int argc, char *argv[])
+{
+ void *fdt;
+
+ test_init(argc, argv);
+ fdt = load_blob_arg(argc, argv);
+
+ check_path(fdt, "/");
+ check_path(fdt, "/subnode1");
+ check_path(fdt, "/subnode2");
+ check_path(fdt, "/subnode1/subsubnode");
+ check_path(fdt, "/subnode2/subsubnode");
+
+ PASS();
+}
Index: dtc/tests/parent_offset.c
===================================================================
--- /dev/null 1970-01-01 00:00:00.000000000 +0000
+++ dtc/tests/parent_offset.c 2007-08-30 14:21:10.000000000 +1000
@@ -0,0 +1,90 @@
+/*
+ * libfdt - Flat Device Tree manipulation
+ * Testcase for fdt_parent_offset()
+ * Copyright (C) 2006 David Gibson, IBM Corporation.
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public License
+ * as published by the Free Software Foundation; either version 2.1 of
+ * the License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+#define _GNU_SOURCE
+
+#include <stdlib.h>
+#include <stdio.h>
+#include <string.h>
+#include <stdint.h>
+
+#include <fdt.h>
+#include <libfdt.h>
+
+#include "tests.h"
+#include "testdata.h"
+
+int path_parent_len(const char *path)
+{
+ const char *p = strrchr(path, '/');
+
+ if (!p)
+ TEST_BUG();
+ if (p == path)
+ return 1;
+ else
+ return p - path;
+}
+
+void check_path(struct fdt_header *fdt, const char *path)
+{
+ char *parentpath;
+ int nodeoffset, parentoffset, parentpathoffset;
+
+ parentpath = strndupa(path, path_parent_len(path));
+
+ verbose_printf("Path: \"%s\"\tParent: \"%s\"\n", path, parentpath);
+
+ nodeoffset = fdt_path_offset(fdt, path);
+ if (nodeoffset < 0)
+ FAIL("fdt_path_offset(%s): %s", path, fdt_strerror(nodeoffset));
+
+ parentpathoffset = fdt_path_offset(fdt, parentpath);
+ if (parentpathoffset < 0)
+ FAIL("fdt_path_offset(%s): %s", parentpath,
+ fdt_strerror(parentpathoffset));
+
+ parentoffset = fdt_parent_offset(fdt, nodeoffset);
+ if (parentoffset < 0)
+ FAIL("fdt_parent_offset(): %s", fdt_strerror(parentoffset));
+
+ if (parentoffset != parentpathoffset)
+ FAIL("fdt_parent_offset() returns %d instead of %d",
+ parentoffset, parentpathoffset);
+}
+
+int main(int argc, char *argv[])
+{
+ void *fdt;
+ int err;
+
+ test_init(argc, argv);
+ fdt = load_blob_arg(argc, argv);
+
+ check_path(fdt, "/subnode1");
+ check_path(fdt, "/subnode2");
+ check_path(fdt, "/subnode1/subsubnode");
+ check_path(fdt, "/subnode2/subsubnode");
+ err = fdt_parent_offset(fdt, 0);
+ if (err != -FDT_ERR_NOTFOUND)
+ FAIL("fdt_parent_offset(/) returns %d instead of "
+ "-FDT_ERR_NOTFOUND", err);
+
+ PASS();
+}
^ permalink raw reply
* [PATCH 2/3] libfdt: Add fdt_get_path() function
From: David Gibson @ 2007-08-30 4:54 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev
In-Reply-To: <20070830045253.GA32543@localhost.localdomain>
This patch adds an fdt_get_path() function to libfdt, which returns
the full path of a given node in a caller supplied buffer.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
---
libfdt/fdt_ro.c | 66 ++++++++++++++++++++++++++++++++++++
libfdt/libfdt.h | 2 +
tests/Makefile.tests | 2 -
tests/get_path.c | 91 +++++++++++++++++++++++++++++++++++++++++++++++++++
tests/run_tests.sh | 1
5 files changed, 161 insertions(+), 1 deletion(-)
Index: dtc/libfdt/fdt_ro.c
===================================================================
--- dtc.orig/libfdt/fdt_ro.c 2007-08-29 14:09:52.000000000 +1000
+++ dtc/libfdt/fdt_ro.c 2007-08-29 14:28:32.000000000 +1000
@@ -283,3 +283,69 @@
return prop->data;
}
+
+int fdt_get_path(const void *fdt, int nodeoffset, char *buf, int buflen)
+{
+ uint32_t tag;
+ int p = 0, overflow = 0;
+ int offset, nextoffset, namelen;
+ const char *name;
+
+ CHECK_HEADER(fdt);
+
+ tag = _fdt_next_tag(fdt, 0, &nextoffset);
+ if (tag != FDT_BEGIN_NODE)
+ return -FDT_ERR_BADSTRUCTURE;
+
+ if (buflen < 2)
+ return -FDT_ERR_NOSPACE;
+ buf[0] = '/';
+ p = 1;
+
+ while (offset < nodeoffset) {
+ offset = nextoffset;
+ tag = _fdt_next_tag(fdt, offset, &nextoffset);
+ switch (tag) {
+ case FDT_END:
+ return -FDT_ERR_BADOFFSET;
+
+ case FDT_BEGIN_NODE:
+ name = fdt_get_name(fdt, offset, &namelen);
+ if (!name)
+ return namelen;
+ if (overflow || ((p + namelen + 1) > buflen)) {
+ overflow++;
+ break;
+ }
+ memcpy(buf + p, name, namelen);
+ p += namelen;
+ buf[p++] = '/';
+ break;
+
+ case FDT_END_NODE:
+ if (overflow) {
+ overflow--;
+ break;
+ }
+ do {
+ p--;
+ } while (buf[p-1] != '/');
+ break;
+
+ case FDT_PROP:
+ case FDT_NOP:
+ break;
+
+ default:
+ return -FDT_ERR_BADSTRUCTURE;
+ }
+ }
+
+ if (overflow)
+ return -FDT_ERR_NOSPACE;
+
+ if (p > 1) /* special case so that root path is "/", not "" */
+ p--;
+ buf[p] = '\0';
+ return p;
+}
Index: dtc/tests/get_path.c
===================================================================
--- /dev/null 1970-01-01 00:00:00.000000000 +0000
+++ dtc/tests/get_path.c 2007-08-29 14:09:53.000000000 +1000
@@ -0,0 +1,91 @@
+/*
+ * libfdt - Flat Device Tree manipulation
+ * Testcase for fdt_get_path()
+ * Copyright (C) 2006 David Gibson, IBM Corporation.
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public License
+ * as published by the Free Software Foundation; either version 2.1 of
+ * the License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+#define _GNU_SOURCE
+
+#include <stdlib.h>
+#include <stdio.h>
+#include <string.h>
+#include <stdint.h>
+
+#include <fdt.h>
+#include <libfdt.h>
+
+#include "tests.h"
+#include "testdata.h"
+
+#define POISON ('\xff')
+
+void check_path_buf(void *fdt, const char *path, int pathlen, int buflen)
+{
+ int offset;
+ char buf[buflen+1];
+ int len;
+
+ offset = fdt_path_offset(fdt, path);
+ if (offset < 0)
+ FAIL("Couldn't find path \"%s\": %s", path, fdt_strerror(offset));
+
+ memset(buf, POISON, sizeof(buf)); /* poison the buffer */
+
+ len = fdt_get_path(fdt, offset, buf, buflen);
+ if (buflen <= pathlen) {
+ if (len != -FDT_ERR_NOSPACE)
+ FAIL("fdt_get_path([%d bytes]) returns %d with "
+ "insufficient buffer space", buflen, len);
+ } else {
+ if (len < 0)
+ FAIL("fdt_get_path([%d bytes]): %s", buflen,
+ fdt_strerror(len));
+ if (len != pathlen)
+ FAIL("fdt_get_path([%d bytes]) reports length %d "
+ "instead of %d", buflen, len, pathlen);
+ if (strcmp(buf, path) != 0)
+ FAIL("fdt_get_path([%d bytes]) returns \"%s\" "
+ "instead of \"%s\"", buflen, buf, path);
+ }
+
+ if (buf[buflen] != POISON)
+ FAIL("fdt_get_path([%d bytes]) overran buffer", buflen);
+}
+
+void check_path(void *fdt, const char *path)
+{
+ int pathlen = strlen(path);
+
+ check_path_buf(fdt, path, pathlen, 1024);
+ check_path_buf(fdt, path, pathlen, pathlen+1);
+ check_path_buf(fdt, path, pathlen, pathlen);
+}
+
+int main(int argc, char *argv[])
+{
+ void *fdt;
+
+ test_init(argc, argv);
+ fdt = load_blob_arg(argc, argv);
+
+ check_path(fdt, "/");
+ check_path(fdt, "/subnode1");
+ check_path(fdt, "/subnode2");
+ check_path(fdt, "/subnode1/subsubnode");
+ check_path(fdt, "/subnode2/subsubnode");
+
+ PASS();
+}
Index: dtc/tests/Makefile.tests
===================================================================
--- dtc.orig/tests/Makefile.tests 2007-08-29 14:09:52.000000000 +1000
+++ dtc/tests/Makefile.tests 2007-08-29 14:09:53.000000000 +1000
@@ -1,5 +1,5 @@
LIB_TESTS_L = root_node find_property subnode_offset path_offset \
- get_name getprop \
+ get_name getprop get_path \
notfound \
setprop_inplace nop_property nop_node \
sw_tree1 \
Index: dtc/tests/run_tests.sh
===================================================================
--- dtc.orig/tests/run_tests.sh 2007-08-29 14:09:52.000000000 +1000
+++ dtc/tests/run_tests.sh 2007-08-29 14:09:53.000000000 +1000
@@ -37,6 +37,7 @@
run_test path_offset $TREE
run_test get_name $TREE
run_test getprop $TREE
+ run_test get_path $TREE
run_test notfound $TREE
# Write-in-place tests
Index: dtc/libfdt/libfdt.h
===================================================================
--- dtc.orig/libfdt/libfdt.h 2007-08-29 14:09:52.000000000 +1000
+++ dtc/libfdt/libfdt.h 2007-08-29 14:10:28.000000000 +1000
@@ -136,6 +136,8 @@
return (void *)fdt_getprop(fdt, nodeoffset, name, lenp);
}
+int fdt_get_path(const void *fdt, int nodeoffset, char *buf, int buflen);
+
/* Write-in-place functions */
int fdt_setprop_inplace(void *fdt, int nodeoffset, const char *name,
const void *val, int len);
^ permalink raw reply
* [PATCH 1/3] libfdt: Add fdt_get_name() to retrieve a node's name
From: David Gibson @ 2007-08-30 4:54 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev
In-Reply-To: <20070830045253.GA32543@localhost.localdomain>
This patch adds a new fdt_get_name() function to libfdt which will
return a node's name string (including unit address, if any).
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
---
libfdt/fdt_ro.c | 24 ++++++++++++++
libfdt/libfdt.h | 2 +
tests/Makefile.tests | 3 +
tests/get_name.c | 83 +++++++++++++++++++++++++++++++++++++++++++++++++++
tests/run_tests.sh | 1
5 files changed, 112 insertions(+), 1 deletion(-)
Index: dtc/libfdt/fdt_ro.c
===================================================================
--- dtc.orig/libfdt/fdt_ro.c 2007-08-29 13:14:06.000000000 +1000
+++ dtc/libfdt/fdt_ro.c 2007-08-29 14:09:29.000000000 +1000
@@ -169,6 +169,30 @@
return offset;
}
+const char *fdt_get_name(const void *fdt, int nodeoffset, int *len)
+{
+ const struct fdt_node_header *nh;
+ int err;
+
+ if ((err = _fdt_check_header(fdt)) != 0)
+ goto fail;
+
+ err = -FDT_ERR_BADOFFSET;
+ nh = fdt_offset_ptr(fdt, nodeoffset, sizeof(*nh));
+ if (!nh || (fdt32_to_cpu(nh->tag) != FDT_BEGIN_NODE))
+ goto fail;
+
+ if (len)
+ *len = strlen(nh->name);
+
+ return nh->name;
+
+ fail:
+ if (len)
+ *len = err;
+ return NULL;
+}
+
const struct fdt_property *fdt_get_property(const void *fdt,
int nodeoffset,
const char *name, int *lenp)
Index: dtc/libfdt/libfdt.h
===================================================================
--- dtc.orig/libfdt/libfdt.h 2007-08-29 13:14:06.000000000 +1000
+++ dtc/libfdt/libfdt.h 2007-08-29 14:09:29.000000000 +1000
@@ -115,6 +115,8 @@
int fdt_path_offset(const void *fdt, const char *path);
+const char *fdt_get_name(const void *fdt, int nodeoffset, int *baselen);
+
const struct fdt_property *fdt_get_property(const void *fdt, int nodeoffset,
const char *name, int *lenp);
Index: dtc/tests/Makefile.tests
===================================================================
--- dtc.orig/tests/Makefile.tests 2007-08-29 13:14:06.000000000 +1000
+++ dtc/tests/Makefile.tests 2007-08-29 14:09:29.000000000 +1000
@@ -1,4 +1,5 @@
-LIB_TESTS_L = root_node find_property subnode_offset path_offset getprop \
+LIB_TESTS_L = root_node find_property subnode_offset path_offset \
+ get_name getprop \
notfound \
setprop_inplace nop_property nop_node \
sw_tree1 \
Index: dtc/tests/run_tests.sh
===================================================================
--- dtc.orig/tests/run_tests.sh 2007-08-29 13:14:06.000000000 +1000
+++ dtc/tests/run_tests.sh 2007-08-29 14:09:29.000000000 +1000
@@ -35,6 +35,7 @@
run_test find_property $TREE
run_test subnode_offset $TREE
run_test path_offset $TREE
+ run_test get_name $TREE
run_test getprop $TREE
run_test notfound $TREE
Index: dtc/tests/get_name.c
===================================================================
--- /dev/null 1970-01-01 00:00:00.000000000 +0000
+++ dtc/tests/get_name.c 2007-08-29 13:14:50.000000000 +1000
@@ -0,0 +1,83 @@
+/*
+ * libfdt - Flat Device Tree manipulation
+ * Testcase for fdt_get_name()
+ * Copyright (C) 2006 David Gibson, IBM Corporation.
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public License
+ * as published by the Free Software Foundation; either version 2.1 of
+ * the License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+#include <stdlib.h>
+#include <stdio.h>
+#include <string.h>
+#include <stdint.h>
+
+#include <fdt.h>
+#include <libfdt.h>
+
+#include "tests.h"
+#include "testdata.h"
+
+void check_name(void *fdt, const char *path)
+{
+ int offset;
+ const char *getname, *getname2, *checkname;
+ int len;
+
+ checkname = strrchr(path, '/');
+ if (!checkname)
+ TEST_BUG();
+ checkname += 1;
+
+ offset = fdt_path_offset(fdt, path);
+ if (offset < 0)
+ FAIL("Couldn't find %s", path);
+
+ getname = fdt_get_name(fdt, offset, &len);
+ verbose_printf("fdt_get_name(%d) returns \"%s\" (len=%d)\n",
+ offset, getname, len);
+ if (!getname)
+ FAIL("fdt_get_name(%d): %s", offset, fdt_strerror(len));
+
+ if (strcmp(getname, checkname) != 0)
+ FAIL("fdt_get_name(%s) returned \"%s\" instead of \"%s\"",
+ path, getname, checkname);
+
+ if (len != strlen(getname))
+ FAIL("fdt_get_name(%s) returned length %d instead of %d",
+ path, len, strlen(getname));
+
+ /* Now check that it doesn't break if we omit len */
+ getname2 = fdt_get_name(fdt, offset, NULL);
+ if (!getname2)
+ FAIL("fdt_get_name(%d, NULL) failed", offset);
+ if (strcmp(getname2, getname) != 0)
+ FAIL("fdt_get_name(%d, NULL) returned \"%s\" instead of \"%s\"",
+ offset, getname2, getname);
+}
+
+int main(int argc, char *argv[])
+{
+ void *fdt;
+
+ test_init(argc, argv);
+ fdt = load_blob_arg(argc, argv);
+
+ check_name(fdt, "/");
+ check_name(fdt, "/subnode1");
+ check_name(fdt, "/subnode2");
+ check_name(fdt, "/subnode1/subsubnode");
+ check_name(fdt, "/subnode2/subsubnode");
+
+ PASS();
+}
^ permalink raw reply
* libfdt: Several new functions
From: David Gibson @ 2007-08-30 4:52 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev
This series of patches adds several new functions to libfdt. These
are all read-only functions related to determining a given nodes node
and ancestry.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: wmb vs mmiowb
From: Nick Piggin @ 2007-08-30 3:36 UTC (permalink / raw)
To: Brent Casavant; +Cc: linuxppc-dev, linux-ia64
In-Reply-To: <20070829125651.L13320@pkunk.americas.sgi.com>
On Wed, Aug 29, 2007 at 01:53:53PM -0500, Brent Casavant wrote:
> On Wed, 29 Aug 2007, Nick Piggin wrote:
>
> > On Tue, Aug 28, 2007 at 03:56:28PM -0500, Brent Casavant wrote:
>
> > > The simplistic method to solve this is a lock around the section
> > > issuing IOs, thereby ensuring serialization of access to the IO
> > > device. However, as SN2 does not enforce an ordering between normal
> > > memory transactions and memory-mapped IO transactions, you cannot
> > > be sure that an IO transaction will arrive at the IO fabric "on the
> > > correct side" of the unlock memory transaction using this scheme.
> >
> > Hmm. So what if you had the following code executed by a single CPU:
> >
> > writel(data, ioaddr);
> > wmb();
> > *mem = 10;
> >
> > Will the device see the io write before the store to mem?
>
> Not necessarily. There is no guaranteed ordering between the IO write
> arriving at the device and the order of the normal memory reference,
> regardless of the intervening wmb(), at least on SN2. I believe the
> missing component in the mental model is the effect of the platform
> chipset.
>
> Perhaps this will help. Uncached writes (i.e. IO writes) are posted
> to the SN2 SHub ASIC and placed in their own queue which the SHub chip
> then routes to the appropriate target. This uncached write queue is
> independent of the NUMA cache-coherency maintained by the SHub ASIC
> for system memory; the relative order in which the uncached writes
> and the system memory traffic appear at their respective targets is
> undefined with respect to eachother.
>
> wmb() does not address this situation as it only guarantees that
> the writes issued from the CPU have been posted to the chipset,
> not that the chipset itself has posted the write to the final
> destination. mmiowb() guarantees that all outstanding IO writes
> have been issued to the IO fabric before proceeding.
>
> I like to think of it this way (probably not 100% accurate, but it
> helps me wrap my brain around this particular point):
>
> wmb(): Ensures preceding writes have issued from the CPU.
> mmiowb(): Ensures preceding IO writes have issued from the
> system chipset.
>
> mmiowb() on SN2 polls a register in SHub that reports the length
> of the outstanding uncached write queue. When the queue has emptied,
> it is known that all subsequent normal memory writes will therefore
> arrive at their destination after all preceding IO writes have arrived
> at the IO fabric.
>
> Thus, typical mmiowb() usage, for SN2's purpose, is to ensure that
> all IO traffic from a CPU has made it out to the IO fabric before
> issuing the normal memory transactions which release a RAM-based
> lock. The lock in this case is the one used to serialize access
> to a particular IO device.
OK, thanks for that. I think I have a rough idea of how they both
work... I was just thinking (hoping) that, although the writel may
not reach the device before the store reaches memory, it would
_appear_ that way from the POV of the device (ie. if the device
were to DMA from mem). But that's probably wishful thinking because
the memory might be on some completely different part of the system.
I don't know whether this is exactly a correct implementation of
Linux's barrier semantics. On one hand, wmb _is_ ordering the stores
as they come out of the CPU; on the other, it isn't ordering normal
stores with respect to writel from the POV of the device (which is
seems to be what is expected by the docs and device driver writers).
One argument says that the IO device or chipset is a seperate
agent and thus isn't subject to ordering... which is sort of valid,
but it is definitely not an agent equal to a CPU, because it can't
actively participate in the synchronisation protocol.
And on the other side, it just doesn't seem so useful just to know
that stores coming out of the CPU are ordered if they can be reordered
by an intermediate. Why even have wmb() at all, if it doesn't actually
order stores to IO and RAM? powerpc's wmb() could just as well be an
'eieio' if it were to follow your model; that instruction orders IO,
but not WRT cacheable stores.
So you could argue that the chipset is an extention of the CPU's IO/memory
subsystem and should follow the ordering specified by the CPU. I like this
idea because it could make things simpler and more regular for the Linux
barrier model.
I guess it is too expensive for you to have mmiowb() in every wmb(),
because _most_ of the time, all that's needed is ordering between IOs.
So why not have io_mb(), io_rmb(), io_wmb(), which order IOs but ignore
system memory. Then the non-prefixed primitives order everything (to the
point that wmb() is like mmiowb on sn2).
> > > mmiowb() causes SN2 to drain the pending IOs from the current CPU's
> > > node. Once the IOs are drained the CPU can safely unlock a normal
> > > memory based lock without fear of the unlock's memory write passing
> > > any outstanding IOs from that CPU.
> >
> > mmiowb needs to have the disclaimer that it's probably wrong if called
> > outside a lock, and it's probably wrong if called between two io writes
> > (need a regular wmb() in that case). I think some drivers are getting
> > this wrong.
>
> There are situations where mmiowb() can be pressed into service to
> some other end, but those are rather rare. The only instance I am
> personally familiar with is synchronizing a free-running counter on
> a PCI device as closely as possible to the execution of a particular
> line of driver code. A write of the new counter value to the device
> and subsequent mmiowb() synchronizes that execution point as closely
> as practical to the IO write arriving at the device. Not perfect, but
> good enough for my purposes. (This was a hack, by the way, pressing
> a bit of hardware into a purpose for which it wasn't really designed,
> ideally the hardware would have had a better mechanism to accomplish
> this goal.)
I guess that would be fine. You probably have a slightly better
understanding of the issues than the average device driver writer
so you could ignore the warnings ;)
> But in the normal case, I believe you are 100% correct -- wmb() would
> ensure that the memory-mapped IO writes arrive at the chipset in a
> particular order, and thus should arrive at the IO hardware in a particular
> order. mmiowb() would not necessarily accomplish this goal, and is
> incorrectly used wherever that is the intention. At least for SN2.
Now I guess it's strictly also needed if you want to ensure cacheable
stores and IO stores are visible to the device in the correct order
too. I think we'd normally hope wmb() does that for us too (hence all
my rambling above).
^ permalink raw reply
* Re: [Kgdb-bugreport] 2.6.23-rc3-mm1: kgdb build failure on powerpc
From: Randy Dunlap @ 2007-08-30 1:38 UTC (permalink / raw)
To: pete
Cc: kgdb-bugreport, amitkale, linux-kernel, linuxppc-dev,
Mariusz Kozlowski, Mackerras, Jason Wessel, Andrew Morton, Paul
In-Reply-To: <46D61B21.1010703@bluelane.com>
On Wed, 29 Aug 2007 18:19:29 -0700 Pete/Piet Delaney wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Pete/Piet Delaney wrote:
> > Jason Wessel wrote:
> >> Andrew Morton wrote:
> >>> On Wed, 22 Aug 2007 17:44:12 -0500
> >>> Jason Wessel <jason.wessel@windriver.com> wrote:
> >>>
> >>>
> >>>> + while (!atomic_read(&debugger_active));
> >>>>
> >>> eek. We're in the process of hunting down and eliminating exactly this
> >>> construct. There have been cases where the compiler cached the
> >>> atomic_read() result in a register, turning the above into an infinite
> >>> loop.
> >>>
> >>> Plus we should never add power-burners like that into the kernel
> >>> anyway. That loop should have a cpu_relax() in it. Which will also
> >>> fix the
> >>> compiler problem described above.
> >>>
> >>>
> >> Agreed, and fixed with a cpu_relax.
> >
> >>> Thirdly, please always add a newline when coding statements like that:
> >>>
> >>> while (expr())
> >>> ;
> >>>
> >> The other instances I found of the same problem in the kgdb core are
> >> fixed too.
> >
> >> I merged all the changes into the for_mm branch in the kgdb git tree.
> >
> > Where is the kgdb git tree?
>
> Why am I getting this when I do:
>
> git clone
> http://master.kernel.org/pub/scm/linux/kernel/git/jwessel/linux-2.6-kgdb.git
>
> -
> ----------------------------------------------------------------------------
> error: Couldn't get
> http://master.kernel.org/pub/scm/linux/kernel/git/jwessel/linux-2.6-kgdb.git/refs/tags/v2.6.11
> for tags/v2.6.11
> The requested URL returned error: 404
> error: Could not interpret tags/v2.6.11 as something to pull
> rm: cannot remove directory
> `/nethome/piet/Src/linux/git/jwessel/linux-2.6-kgdb/.git/clone-tmp':
> Directory not empty
> /nethome/piet/Src/linux/git/jwessel$
> -
> ----------------------------------------------------------------------------
See the URLs at the top of
http://git.kernel.org/?p=linux/kernel/git/jwessel/linux-2.6-kgdb.git;a=summary
and try one of those (the git one preferably).
> We are getting a problem with VMware where kernel text is the schedler
> is getting wacked with four null bytes into the code. Thought I'd use
> the current linux-2.6-kgdb.git tree and possible the CONFIG_DEBUG_RODATA
> patch to make kernel text readonly:
>
> https://www.x86-64.org/pipermail/patches/2007-March/003666.html
>
> I thought the kernel text was RO and gdb had to disable it to
> insert a breakpoint.
>
> - -piet
>
> >
> > -piet
> >
> >> Thanks,
> >> Jason.
> >> -
> >> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> >> the body of a message to majordomo@vger.kernel.org
> >> More majordomo info at http://vger.kernel.org/majordomo-info.html
> >> Please read the FAQ at http://www.tux.org/lkml/
> >
> >
> - -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.7 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iD8DBQFG1hshJICwm/rv3hoRAhTGAJ46pq69zYHqRmT+yTmRx+RVh8aBtgCfdyFM
> gl91xCFTy0NJxHalVXpd9Os=
> =c8FZ
> -----END PGP SIGNATURE-----
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
^ permalink raw reply
* ML403 AC97 ALSA Driver problem
From: Qin Lin @ 2007-08-30 2:19 UTC (permalink / raw)
To: linuxppc-embedded
hi all
when i use the ac97driver posted by Joachim F=C3=B6rster recently,there is=
a
kernel stack overflow while testing .
Does anybody kindly suggest me to take some step to find out the problem?
Thanks
Joachim F=C3=B6rster 's driver here:
http://www.nabble.com/Re%3A--PATCHv2-1-2--Xilinx-ML403-AC97-Controller-Refe=
rence-device-driver-p12106850.html
testing program is alsa-app aplay ,the output here:=20
# strace aplay /root/aq_ac97/yonggan.wav
execve("/usr/bin/aplay", ["aplay", "/root/aq_ac97/yonggan.wav"], [/* 7 vars
*/]) =3D 0
uname({sys=3D"Linux", node=3D"(none)", ...}) =3D 0
brk(0) =3D 0x10022000
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
=3D
0x30017000
access("/etc/ld.so.preload", R_OK) =3D -1 ENOENT (No such file or
directory)
open("/etc/ld.so.cache", O_RDONLY) =3D 3
fstat64(3, {st_mode=3DS_IFREG|0644, st_size=3D17602, ...}) =3D 0
mmap(NULL, 17602, PROT_READ, MAP_PRIVATE, 3, 0) =3D 0x30018000
close(3) =3D 0
open("/lib/tls/ppc405/libasound.so.2", O_RDONLY) =3D -1 ENOENT (No such fil=
e
or directory)
stat64("/lib/tls/ppc405", 0x7ffec288) =3D -1 ENOENT (No such file or
directory)
open("/lib/tls/libaso[ 30.843423] Kernel stack overflow in process
c02dcb90, r1=3Dc02d3f30
# aplay yonggan.wav
Playing WAVE 'yonggan.wav' : Signed 16 bit Little Endian, Rate 44100 Hz,
Stereo
[ 82.689668] Kernel stack overflow in process c02a6490, r1=3Dc02f7f30
[ 82.763235] Oops: kernel access of bad area, sig: 11 [#1]
[ 82.827330] NIP: C001327C LR: C001666C CTR: 00000000
[ 82.886699] REGS: c01931f0 TRAP: 0300 Not tainted (2.6.20)
[ 82.955428] MSR: 00021030 <ME,IR,DR> CR: 28000028 XER: 00000000
[ 83.028333] DAR: 00000005, DSISR: 00000000
[ 83.077290] TASK =3D c02a6490[134] 'xsysace' THREAD: c02f8000
[ 83.141855] GPR00: 00000001 C01932A0 C02A6490 00000000 C01B3770 00000012
00000300 00000010
[ 83.241838] GPR08: FFFFFFFA 00000020 00000000 00000005 00000000 FFFF87B8
03FD0700 00000000
[ 83.341823] GPR16: 00000001 00800000 03FCF588 00000000 FFFFFFFF 007FFF00
03FC9FFC 00000002
[ 83.441806] GPR24: 03E667C0 C01B0000 C010600C C01B3770 00000012 00000000
00000000 C0193470
[ 83.543874] NIP [C001327C] xmon_write+0x38/0xbc
[ 83.598032] LR [C001666C] xmon_vfprintf+0x34/0x48
[ 83.654272] Call Trace:
[ 83.683435] Instruction dump:
[ 83.718848] bf61000c 90010024 3d20c01b 8009f1bc 7c9b2378 2f800000
7cbc2b78 40be0008
[ 83.811540] 4bfffe2d 3ba00000 3bc00000 48000054 <880b0000> 7c0a4839
4182fff8 7ffbf0ae
[ 83.906354] Oops: kernel access of bad area, sig: 11 [#2]
[ 83.970893] NIP: C001327C LR: C001666C CTR: 00000000
[ 84.030263] REGS: c0192d30 TRAP: 0300 Not tainted (2.6.20)
[ 84.098992] MSR: 00021030 <ME,IR,DR> CR: 28000048 XER: 00000000
[ 84.171898] DAR: 00000005, DSISR: 00000000
[ 84.220854] TASK =3D c02a6490[134] 'xsysace' THREAD: c02f8000
[ 84.285419] GPR00: 00000001 C0192DE0 C02A6490 00000000 C01B3770 00000012
00000700 00000010
[ 84.385403] GPR08: FFFFFFFA 00000020 00000000 00000005 00000000 FFFF87B8
03FD0700 00000000
[ 84.485387] GPR16: 00000001 00800000 03FCF588 00000000 FFFFFFFF 007FFF00
03FC9FFC 00000002
[ 84.585371] GPR24: 03E667C0 C01B0000 C010600C C01B3770 00000012 00000000
00000000 C0193040
[ 84.687439] NIP [C001327C] xmon_write+0x38/0xbc
[ 84.741598] LR [C001666C] xmon_vfprintf+0x34/0x48
[ 84.797838] Call Trace:
[ 84.827000] Instruction dump:
[ 84.862412] bf61000c 90010024 3d20c01b 8009f1bc 7c9b2378 2f800000
7cbc2b78 40be0008
[ 84.955105] 4bfffe2d 3ba00000 3bc00000 48000054 <880b0000> 7c0a4839
4182fff8 7ffbf0ae
[ 85.049913] Oops: kernel access of bad area, sig: 11 [#3]
[ 85.114460] NIP: C001327C LR: C001666C CTR: 00000000
[ 85.173828] REGS: c0192870 TRAP: 0300 Not tainted (2.6.20)
[ 85.242559] MSR: 00021030 <ME,IR,DR> CR: 28000048 XER: 00000000
[ 85.315463] DAR: 00000005, DSISR: 00000000
[ 85.364419] TASK =3D c02a6490[134] 'xsysace' THREAD: c02f8000
[ 85.428985] GPR00: 00000001 C0192920 C02A6490 00000000 C01B3770 00000012
00000700 00000010
[ 85.528969] GPR08: FFFFFFFA 00000020 00000000 00000005 00000000 FFFF87B8
03FD0700 00000000
[ 85.628952] GPR16: 00000001 00800000 03FCF588 00000000 FFFFFFFF 007FFF00
03FC9FFC 00000002
[ 85.728936] GPR24: 03E667C0 C01B0000 C010600C C01B3770 00000012 00000000
00000000 C0192B80
[ 85.831004] NIP [C001327C] xmon_write+0x38/0xbc
[ 85.885163] LR [C001666C] xmon_vfprintf+0x34/0x48
[ 85.941404] Call Trace:
[ 85.970565] Instruction dump:
[ 86.005979] bf61000c 90010024 3d20c01b 8009f1bc 7c9b2378 2f800000
7cbc2b78 40be0008
[ 86.098670] 4bfffe2d 3ba00000 3bc00000 48000054 <880b0000> 7c0a4839
4182fff8 7ffbf0ae
[ 86.193480] Oops: kernel access of bad area, sig: 11 [#4]
[ 86.258024] NIP: C001327C LR: C001666C CTR: 00000000
[ 86.317392] REGS: c01923b0 TRAP: 0300 Not tainted (2.6.20)
[ 86.386123] MSR: 00021030 <ME,IR,DR> CR: 28000048 XER: 00000000
[ 86.459028] DAR: 00000005, DSISR: 00000000
[ 86.507985] TASK =3D c02a6490[134] 'xsysace' THREAD: c02f8000
[ 86.572551] GPR00: 00000001 C0192460 C02A6490 00000000 C01B3770 00000012
00000700 00000010
[ 86.672534] GPR08: FFFFFFFA 00000020 00000000 00000005 00000000 FFFF87B8
03FD0700 00000000
[ 86.772518] GPR16: 00000001 00800000 03FCF588 00000000 FFFFFFFF 007FFF00
03FC9FFC 00000002
[ 86.872502] GPR24: 03E667C0 C01B0000 C010600C C01B3770 00000012 00000000
00000000 C01926C0
[ 86.974570] NIP [C001327C] xmon_write+0x38/0xbc
[ 87.028727] LR [C001666C] xmon_vfprintf+0x34/0x48
[ 87.084967] Call Trace:
[ 87.114130] Instruction dump:
[ 87.149544] bf61000c 90010024 3d20c01b 8009f1bc 7c9b2378 2f800000
7cbc2b78 40be0008
[ 87.242236] 4bfffe2d 3ba00000 3bc00000 48000054 <880b0000> 7c0a4839
4182fff8 7ffbf0ae
[ 87.337041] Oops: kernel access of bad area, sig: 11 [#5]
[ 87.401589] NIP: C001327C LR: C001666C CTR: 00000000
[ 87.460958] REGS: c0191ef0 TRAP: 0300 Not tainted (2.6.20)
[ 87.529687] MSR: 00021030 <ME,IR,DR> CR: 28000048 XER: 00000000
[ 87.602593] DAR: 00000005, DSISR: 00000000
[ 87.651549] TASK =3D c02a6490[134] 'xsysace' THREAD: c02f8000
[ 87.716115] GPR00: 00000001 C0191FA0 C02A6490 00000000 C01B3770 00000012
00000700 00000010
[ 87.816099] GPR08: FFFFFFFA 00000020 00000000 00000005 00000000 FFFF87B8
03FD0700 00000000
[ 87.916083] GPR16: 00000001 00800000 03FCF588 00000000 FFFFFFFF 007FFF00
03FC9FFC 00000002
[ 88.016067] GPR24: 03E667C0 C01B0000 C010600C C01B3770 00000012 00000000
00000000 C0192200
[ 88.118134] NIP [C001327C] xmon_write+0x38/0xbc
[ 88.172293] LR [C001666C] xmon_vfprintf+0x34/0x48
[ 88.228531] Call Trace:
[ 88.257695] Instruction dump:
[ 88.293108] bf61000c 90010024 3d20c01b 8009f1bc 7c9b2378 2f800000
7cbc2b78 40be0008
[ 88.385801] 4bfffe2d 3ba00000 3bc00000 48000054 <880b0000> 7c0a4839
4182fff8 7ffbf0ae
[ 88.480614] Oops: kernel access of bad area, sig: 11 [#6]
[ 88.545155] NIP: C001327C LR: C001666C CTR: 00000000
[ 88.604522] REGS: c0191a30 TRAP: 0300 Not tainted (2.6.20)
[ 88.673253] MSR: 00021030 <ME,IR,DR> CR: 28000048 XER: 00000000
[ 88.746158] DAR: 00000005, DSISR: 00000000
[ 88.795114] TASK =3D c02a6490[134] 'xsysace' THREAD: c02f8000
[ 88.859680] GPR00: 00000001 C0191AE0 C02A6490 00000000 C01B3770 00000012
00000700 00000010
[ 88.959664] GPR08: FFFFFFFA 00000020 00000000 00000005 00000000 FFFF87B8
03FD0700 00000000
[ 89.059648] GPR16: 00000001 00800000 03FCF588 00000000 FFFFFFFF 007FFF00
03FC9FFC 00000002
[ 89.159632] GPR24: 03E667C0 C01B0000 C010600C C01B3770 00000012 00000000
00000000 C0191D40
[ 89.261699] NIP [C001327C] xmon_write+0x38/0xbc
[ 89.315858] LR [C001666C] xmon_vfprintf+0x34/0x48
[ 89.372097] Call Trace:
[ 89.401261] Instruction dump:
[ 89.436673] bf61000c 90010024 3d20c01b 8009f1bc 7c9b2378 2f800000
7cbc2b78 40be0008
[ 89.529366] 4bfffe2d 3ba00000 3bc00000 48000054 <880b0000> 7c0a4839
4182fff8 7ffbf0ae
[ 89.624178] Oops: kernel access of bad area, sig: 11 [#7]
[ 89.688719] NIP: C001327C LR: C001666C CTR: 00000000
[ 89.748087] REGS: c0191570 TRAP: 0300 Not tainted (2.6.20)
[ 89.816818] MSR: 00021030 <ME,IR,DR> CR: 28000048 XER: 00000000
[ 89.889724] DAR: 00000005, DSISR: 00000000
[ 89.938679] TASK =3D c02a6490[134] 'xsysace' THREAD: c02f8000
[ 90.003245] GPR00: 00000001 C0191620 C02A6490 00000000 C01B3770 00000012
00000700 00000010
[ 90.103229] GPR08: FFFFFFFA 00000020 00000000 00000005 00000000 FFFF87B8
03FD0700 00000000
[ 90.203213] GPR16: 00000001 00800000 03FCF588 00000000 FFFFFFFF 007FFF00
03FC9FFC 00000002
[ 90.303197] GPR24: 03E667C0 C01B0000 C010600C C01B3770 00000012 00000000
00000000 C0191880
[ 90.405265] NIP [C001327C] xmon_write+0x38/0xbc
[ 90.459422] LR [C001666C] xmon_vfprintf+0x34/0x48
[ 90.515662] Call Trace:
[ 90.544826] Instruction dump:
[ 90.580238] bf61000c 90010024 3d20c01b 8009f1bc 7c9b2378 2f800000
7cbc2b78 40be0008
[ 90.672930] 4bfffe2d 3ba00000 3bc00000 48000054 <880b0000> 7c0a4839
4182fff8 7ffbf0ae
[ 90.767743] Oops: kernel access of bad area, sig: 11 [#8]
[ 90.832285] NIP: C001327C LR: C001666C CTR: 00000000
[ 90.891654] REGS: c01910b0 TRAP: 0300 Not tainted (2.6.20)
[ 90.960383] MSR: 00021030 <ME,IR,DR> CR: 28000048 XER: 00000000
[ 91.033289] DAR: 00000005, DSISR: 00000000
[ 91.082245] TASK =3D c02a6490[134] 'xsysace' THREAD: c02f8000
[ 91.146811] GPR00: 00000001 C0191160 C02A6490 00000000 C01B3770 00000012
00000700 00000010
[ 91.246795] GPR08: FFFFFFFA 00000020 00000000 00000005 00000000 FFFF87B8
03FD0700 00000000
[ 91.346779] GPR16: 00000001 00800000 03FCF588 00000000 FFFFFFFF 007FFF00
03FC9FFC 00000002
[ 91.446762] GPR24: 03E667C0 C01B0000 C010600C C01B3770 00000012 00000000
00000000 C01913C0
[ 91.548831] NIP [C001327C] xmon_write+0x38/0xbc
[ 91.602989] LR [C001666C] xmon_vfprintf+0x34/0x48
[ 91.659227] Call Trace:
[ 91.688390] Instruction dump:
[ 91.723804] bf61000c 90010024 3d20c01b 8009f1bc 7c9b2378 2f800000
7cbc2b78 40be0008
[ 91.816495] 4bfffe2d 3ba00000 3bc00000 48000054 <880b0000> 7c0a4839
4182fff8 7ffbf0ae
Qin Lin
--=20
View this message in context: http://www.nabble.com/ML403-AC97-ALSA-Driver-=
problem-tf4351591.html#a12399427
Sent from the linuxppc-embedded mailing list archive at Nabble.com.
^ permalink raw reply
* Re: [Kgdb-bugreport] 2.6.23-rc3-mm1: kgdb build failure on powerpc
From: Jason Wessel @ 2007-08-30 2:13 UTC (permalink / raw)
To: pete
Cc: kgdb-bugreport, amitkale, linux-kernel, linuxppc-dev,
Mariusz Kozlowski, Paul Mackerras, Andrew Morton
In-Reply-To: <46D61B21.1010703@bluelane.com>
Pete/Piet Delaney wrote:
> We are getting a problem with VMware where kernel text is the schedler
> is getting wacked with four null bytes into the code. Thought I'd use
> the current linux-2.6-kgdb.git tree and possible the CONFIG_DEBUG_RODATA
> patch to make kernel text readonly:
>
> https://www.x86-64.org/pipermail/patches/2007-March/003666.html
>
> I thought the kernel text was RO and gdb had to disable it to
> insert a breakpoint.
>
>
If you are going to make all the kernel text RO, then you are going to
have to add some code to the kgdb write memory so as to unprotect a
given page or all the breakpoint writes are going to fail.
Alternatively you can use HW breakpoints. But, I have no idea if your
VM Ware simulated HW emulate HW breakpoint registers or not.
Jason.
^ permalink raw reply
* Re: [Kgdb-bugreport] 2.6.23-rc3-mm1: kgdb build failure on powerpc
From: Jason Wessel @ 2007-08-30 2:07 UTC (permalink / raw)
To: pete
Cc: kgdb-bugreport, amitkale, linux-kernel, linuxppc-dev,
Mariusz Kozlowski, Paul Mackerras, Andrew Morton
In-Reply-To: <46D61B21.1010703@bluelane.com>
Pete/Piet Delaney wrote:
> Why am I getting this when I do:
>
> git clone
> http://master.kernel.org/pub/scm/linux/kernel/git/jwessel/linux-2.6-kgdb.git
>
I have only ever used:
git clone
git://git.kernel.org/pub/scm/linux/kernel/git/jwessel/linux-2.6-kgdb.git
Jason.
^ permalink raw reply
* Document and implement an improved flash device binding for powerpc (v4)
From: David Gibson @ 2007-08-30 1:21 UTC (permalink / raw)
To: linuxppc-dev
This patch replaces the binding for flash chips in
booting-without-of.txt with an clarified and improved version. It
also makes drivers/mtd/maps/physmap_of.c recognize this new binding.
Finally it revises the Ebony device tree source to use the new binding
as an example.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Index: working-2.6/Documentation/powerpc/booting-without-of.txt
===================================================================
--- working-2.6.orig/Documentation/powerpc/booting-without-of.txt 2007-08-30 11:17:21.000000000 +1000
+++ working-2.6/Documentation/powerpc/booting-without-of.txt 2007-08-30 11:17:21.000000000 +1000
@@ -50,7 +50,7 @@ Table of Contents
g) Freescale SOC SEC Security Engines
h) Board Control and Status (BCSR)
i) Freescale QUICC Engine module (QE)
- j) Flash chip nodes
+ j) CFI or JEDEC memory-mapped NOR flash
k) Global Utilities Block
VII - Specifying interrupt information for devices
@@ -1757,45 +1757,61 @@ platforms are moved over to use the flat
};
};
- j) Flash chip nodes
+ j) CFI or JEDEC memory-mapped NOR flash
Flash chips (Memory Technology Devices) are often used for solid state
file systems on embedded devices.
- Required properties:
-
- - device_type : has to be "rom"
- - compatible : Should specify what this flash device is compatible with.
- Currently, this is most likely to be "direct-mapped" (which
- corresponds to the MTD physmap mapping driver).
- - reg : Offset and length of the register set (or memory mapping) for
- the device.
- - bank-width : Width of the flash data bus in bytes. Required
- for the NOR flashes (compatible == "direct-mapped" and others) ONLY.
-
- Recommended properties :
-
- - partitions : Several pairs of 32-bit values where the first value is
- partition's offset from the start of the device and the second one is
- partition size in bytes with LSB used to signify a read only
- partition (so, the partition size should always be an even number).
- - partition-names : The list of concatenated zero terminated strings
- representing the partition names.
- - probe-type : The type of probe which should be done for the chip
- (JEDEC vs CFI actually). Valid ONLY for NOR flashes.
+ - compatible : should contain the specific model of flash chip(s)
+ used, if known, followed by either "cfi-flash" or "jedec-flash"
+ - reg : Address range of the flash chip
+ - bank-width : Width (in bytes) of the flash bank. Equal to the
+ device width times the number of interleaved chips.
+ - device-width : (optional) Width of a single flash chip. If
+ omitted, assumed to be equal to 'bank-width'.
+ - #address-cells, #size-cells : Must be present if the flash has
+ sub-nodes representing partitions (see below). In this case
+ both #address-cells and #size-cells must be equal to 1.
+
+ For JEDEC compatible devices, the following additional properties
+ are defined:
+
+ - vendor-id : Contains the flash chip's vendor id (1 byte).
+ - device-id : Contains the flash chip's device id (1 byte).
+
+ In addition to the information on the flash bank itself, the
+ device tree may optionally contain additional information
+ describing partitions of the flash address space. This can be
+ used on platforms which have strong conventions about which
+ portions of the flash are used for what purposes, but which don't
+ use an on-flash partition table such as RedBoot.
+
+ Each partition is represented as a sub-node of the flash device.
+ Each node's name represents the name of the corresponding
+ partition of the flash device.
+
+ Flash partitions
+ - reg : The partition's offset and size within the flash bank.
+ - read-only : (optional) This parameter, if present, is a hint to
+ Linux that this flash partition should only be mounted
+ read-only. This is usually used for flash partitions
+ containing early-boot firmware images or data which should not
+ be clobbered.
- Example:
+ Example:
- flash@ff000000 {
- device_type = "rom";
- compatible = "direct-mapped";
- probe-type = "CFI";
- reg = <ff000000 01000000>;
- bank-width = <4>;
- partitions = <00000000 00f80000
- 00f80000 00080001>;
- partition-names = "fs\0firmware";
- };
+ flash@ff000000 {
+ compatible = "amd,am29lv128ml", "cfi-flash";
+ reg = <ff000000 01000000>;
+ bank-width = <4>;
+ fs@0 {
+ reg = <0 f80000>;
+ };
+ firmware@f80000 {
+ reg = <f80000 80000>;
+ read-only;
+ };
+ };
k) Global Utilities Block
Index: working-2.6/drivers/mtd/maps/physmap_of.c
===================================================================
--- working-2.6.orig/drivers/mtd/maps/physmap_of.c 2007-08-28 14:23:57.000000000 +1000
+++ working-2.6/drivers/mtd/maps/physmap_of.c 2007-08-30 11:17:21.000000000 +1000
@@ -4,6 +4,9 @@
* Copyright (C) 2006 MontaVista Software Inc.
* Author: Vitaly Wool <vwool@ru.mvista.com>
*
+ * Revised to handle newer style flash binding by:
+ * Copyright (C) 2007 David Gibson, IBM Corporation.
+ *
* This program is free software; you can redistribute it and/or modify it
* under the terms of the GNU General Public License as published by the
* Free Software Foundation; either version 2 of the License, or (at your
@@ -30,56 +33,132 @@ struct physmap_flash_info {
struct map_info map;
struct resource *res;
#ifdef CONFIG_MTD_PARTITIONS
- int nr_parts;
struct mtd_partition *parts;
#endif
};
-static const char *rom_probe_types[] = { "cfi_probe", "jedec_probe", "map_rom", NULL };
-#ifdef CONFIG_MTD_PARTITIONS
-static const char *part_probe_types[] = { "cmdlinepart", "RedBoot", NULL };
-#endif
-
#ifdef CONFIG_MTD_PARTITIONS
-static int parse_flash_partitions(struct device_node *node,
- struct mtd_partition **parts)
+static int parse_obsolete_partitions(struct of_device *dev,
+ struct physmap_flash_info *info,
+ struct device_node *dp)
{
- int i, plen, retval = -ENOMEM;
- const u32 *part;
- const char *name;
-
- part = of_get_property(node, "partitions", &plen);
- if (part == NULL)
- goto err;
-
- retval = plen / (2 * sizeof(u32));
- *parts = kzalloc(retval * sizeof(struct mtd_partition), GFP_KERNEL);
- if (*parts == NULL) {
+ int i, plen, nr_parts;
+ const struct {
+ u32 offset, len;
+ } *part;
+ const char *names;
+
+ part = of_get_property(dp, "partitions", &plen);
+ if (!part)
+ return -ENOENT;
+
+ dev_warn(&dev->dev, "Device tree uses obsolete partition map binding\n");
+
+ nr_parts = plen / sizeof(part[0]);
+
+ info->parts = kzalloc(nr_parts * sizeof(struct mtd_partition), GFP_KERNEL);
+ if (!info->parts) {
printk(KERN_ERR "Can't allocate the flash partition data!\n");
- goto err;
+ return -ENOMEM;
}
- name = of_get_property(node, "partition-names", &plen);
+ names = of_get_property(dp, "partition-names", &plen);
- for (i = 0; i < retval; i++) {
- (*parts)[i].offset = *part++;
- (*parts)[i].size = *part & ~1;
- if (*part++ & 1) /* bit 0 set signifies read only partition */
- (*parts)[i].mask_flags = MTD_WRITEABLE;
+ for (i = 0; i < nr_parts; i++) {
+ info->parts[i].offset = part->offset;
+ info->parts[i].size = part->len & ~1;
+ if (part->len & 1) /* bit 0 set signifies read only partition */
+ info->parts[i].mask_flags = MTD_WRITEABLE;
- if (name != NULL && plen > 0) {
- int len = strlen(name) + 1;
+ if (names && (plen > 0)) {
+ int len = strlen(names) + 1;
- (*parts)[i].name = (char *)name;
+ info->parts[i].name = (char *)names;
plen -= len;
- name += len;
- } else
- (*parts)[i].name = "unnamed";
+ names += len;
+ } else {
+ info->parts[i].name = "unnamed";
+ }
+
+ part++;
}
-err:
- return retval;
+
+ return nr_parts;
}
-#endif
+
+static int __devinit process_partitions(struct physmap_flash_info *info,
+ struct of_device *dev)
+{
+ static const char *part_probe_types[]
+ = { "cmdlinepart", "RedBoot", NULL };
+ struct device_node *dp = dev->node, *pp;
+ int nr_parts, i, err;
+
+ /* First look for RedBoot table or partitions on the command
+ * line, these take precedence over device tree information */
+ nr_parts = parse_mtd_partitions(info->mtd, part_probe_types,
+ &info->parts, 0);
+ if (nr_parts > 0) {
+ add_mtd_partitions(info->mtd, info->parts, err);
+ return 0;
+ }
+
+ /* First count the subnodes */
+ nr_parts = 0;
+ for (pp = dp->child; pp; pp = pp->sibling)
+ nr_parts++;
+
+ if (nr_parts) {
+ info->parts = kzalloc(nr_parts * sizeof(struct mtd_partition),
+ GFP_KERNEL);
+ if (!info->parts) {
+ printk(KERN_ERR "Can't allocate the flash partition data!\n");
+ return -ENOMEM;
+ }
+
+ for (pp = dp->child, i = 0 ; pp; pp = pp->sibling, i++) {
+ const u32 *reg;
+ int len;
+
+ reg = of_get_property(pp, "reg", &len);
+ if (!reg || (len != 2*sizeof(u32))) {
+ dev_err(&dev->dev, "Invalid 'reg' on %s\n",
+ dp->full_name);
+ kfree(info->parts);
+ info->parts = NULL;
+ return -EINVAL;
+ }
+ info->parts[i].offset = reg[0];
+ info->parts[i].size = reg[1];
+
+ info->parts[i].name =
+ (char *)of_get_property(pp, "name", &len);
+
+ if (of_get_property(pp, "read-only", &len))
+ info->parts[i].mask_flags = MTD_WRITEABLE;
+ }
+ } else {
+ nr_parts = parse_obsolete_partitions(dev, info, dp);
+ }
+
+ if (nr_parts < 0)
+ return nr_parts;
+
+ if (nr_parts > 0)
+ add_mtd_partitions(info->mtd, info->parts, nr_parts);
+ else
+ add_mtd_device(info->mtd);
+
+ return 0;
+}
+#else /* MTD_PARTITIONS */
+static int __devinit process_partitions(struct physmap_flash_info *info,
+ struct device_node *dev)
+{
+ add_mtd_device(info->mtd);
+ return 0;
+}
+#endif /* MTD_PARTITIONS */
static int of_physmap_remove(struct of_device *dev)
{
@@ -92,7 +171,7 @@ static int of_physmap_remove(struct of_d
if (info->mtd != NULL) {
#ifdef CONFIG_MTD_PARTITIONS
- if (info->nr_parts) {
+ if (info->parts) {
del_mtd_partitions(info->mtd);
kfree(info->parts);
} else {
@@ -115,17 +194,51 @@ static int of_physmap_remove(struct of_d
return 0;
}
+/* Helper function to handle probing of the obsolete "direct-mapped"
+ * compatible binding, which has an extra "probe-type" property
+ * describing the type of flash probe necessary. */
+static struct mtd_info * __devinit obsolete_probe(struct of_device *dev,
+ struct map_info *map)
+{
+ struct device_node *dp = dev->node;
+ const char *of_probe;
+ struct mtd_info *mtd;
+ static const char *rom_probe_types[]
+ = { "cfi_probe", "jedec_probe", "map_rom"};
+ int i;
+
+ dev_warn(&dev->dev, "Device tree uses obsolete \"direct-mapped\" "
+ "flash binding\n");
+
+ of_probe = of_get_property(dp, "probe-type", NULL);
+ if (!of_probe) {
+ for (i = 0; i < ARRAY_SIZE(rom_probe_types); i++) {
+ mtd = do_map_probe(rom_probe_types[i], map);
+ if (mtd)
+ return mtd;
+ }
+ return NULL;
+ } else if (strcmp(of_probe, "CFI") == 0) {
+ return do_map_probe("cfi_probe", map);
+ } else if (strcmp(of_probe, "JEDEC") == 0) {
+ return do_map_probe("jedec_probe", map);
+ } else {
+ if (strcmp(of_probe, "ROM") != 0)
+ dev_dbg(&dev->dev, "obsolete_probe: don't know probe type "
+ "'%s', mapping as rom\n", of_probe);
+ return do_map_probe("mtd_rom", map);
+ }
+}
+
static int __devinit of_physmap_probe(struct of_device *dev, const struct of_device_id *match)
{
struct device_node *dp = dev->node;
struct resource res;
struct physmap_flash_info *info;
- const char **probe_type;
- const char *of_probe;
+ const char *probe_type = (const char *)match->data;
const u32 *width;
int err;
-
if (of_address_to_resource(dp, 0, &res)) {
dev_err(&dev->dev, "Can't get the flash mapping!\n");
err = -EINVAL;
@@ -174,21 +287,11 @@ static int __devinit of_physmap_probe(st
simple_map_init(&info->map);
- of_probe = of_get_property(dp, "probe-type", NULL);
- if (of_probe == NULL) {
- probe_type = rom_probe_types;
- for (; info->mtd == NULL && *probe_type != NULL; probe_type++)
- info->mtd = do_map_probe(*probe_type, &info->map);
- } else if (!strcmp(of_probe, "CFI"))
- info->mtd = do_map_probe("cfi_probe", &info->map);
- else if (!strcmp(of_probe, "JEDEC"))
- info->mtd = do_map_probe("jedec_probe", &info->map);
- else {
- if (strcmp(of_probe, "ROM"))
- dev_dbg(&dev->dev, "map_probe: don't know probe type "
- "'%s', mapping as rom\n", of_probe);
- info->mtd = do_map_probe("mtd_rom", &info->map);
- }
+ if (probe_type)
+ info->mtd = do_map_probe(probe_type, &info->map);
+ else
+ info->mtd = obsolete_probe(dev, &info->map);
+
if (info->mtd == NULL) {
dev_err(&dev->dev, "map_probe failed\n");
err = -ENXIO;
@@ -196,19 +299,7 @@ static int __devinit of_physmap_probe(st
}
info->mtd->owner = THIS_MODULE;
-#ifdef CONFIG_MTD_PARTITIONS
- err = parse_mtd_partitions(info->mtd, part_probe_types, &info->parts, 0);
- if (err > 0) {
- add_mtd_partitions(info->mtd, info->parts, err);
- } else if ((err = parse_flash_partitions(dp, &info->parts)) > 0) {
- dev_info(&dev->dev, "Using OF partition information\n");
- add_mtd_partitions(info->mtd, info->parts, err);
- info->nr_parts = err;
- } else
-#endif
-
- add_mtd_device(info->mtd);
- return 0;
+ return process_partitions(info, dev);
err_out:
of_physmap_remove(dev);
@@ -221,6 +312,14 @@ err_out:
static struct of_device_id of_physmap_match[] = {
{
+ .compatible = "cfi-flash",
+ .data = (void *)"cfi_probe",
+ },
+ {
+ .compatible = "jedec-flash",
+ .data = (void *)"jedec_probe",
+ },
+ {
.type = "rom",
.compatible = "direct-mapped"
},
Index: working-2.6/arch/powerpc/boot/dts/ebony.dts
===================================================================
--- working-2.6.orig/arch/powerpc/boot/dts/ebony.dts 2007-08-28 14:23:56.000000000 +1000
+++ working-2.6/arch/powerpc/boot/dts/ebony.dts 2007-08-30 11:17:21.000000000 +1000
@@ -142,13 +142,15 @@
interrupt-parent = <&UIC1>;
small-flash@0,80000 {
- device_type = "rom";
- compatible = "direct-mapped";
- probe-type = "JEDEC";
+ compatible = "jedec-flash";
bank-width = <1>;
- partitions = <0 80000>;
- partition-names = "OpenBIOS";
reg = <0 80000 80000>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ OpenBIOS@0 {
+ reg = <0 80000>;
+ read-only;
+ };
};
ds1743@1,0 {
@@ -158,14 +160,17 @@
};
large-flash@2,0 {
- device_type = "rom";
- compatible = "direct-mapped";
- probe-type = "JEDEC";
+ compatible = "jedec-flash";
bank-width = <1>;
- partitions = <0 380000
- 380000 80000>;
- partition-names = "fs", "firmware";
reg = <2 0 400000>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ fs@0 {
+ reg = <0 380000>;
+ };
+ firmware@380000 {
+ reg = <380000 80000>;
+ };
};
ir@3,0 {
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [Kgdb-bugreport] 2.6.23-rc3-mm1: kgdb build failure on powerpc
From: Pete/Piet Delaney @ 2007-08-30 1:19 UTC (permalink / raw)
To: pete
Cc: kgdb-bugreport, amitkale, linux-kernel, linuxppc-dev,
Mariusz Kozlowski, Paul Mackerras, Jason Wessel, Andrew Morton
In-Reply-To: <46D604BF.7090905@bluelane.com>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Pete/Piet Delaney wrote:
> Jason Wessel wrote:
>> Andrew Morton wrote:
>>> On Wed, 22 Aug 2007 17:44:12 -0500
>>> Jason Wessel <jason.wessel@windriver.com> wrote:
>>>
>>>
>>>> + while (!atomic_read(&debugger_active));
>>>>
>>> eek. We're in the process of hunting down and eliminating exactly this
>>> construct. There have been cases where the compiler cached the
>>> atomic_read() result in a register, turning the above into an infinite
>>> loop.
>>>
>>> Plus we should never add power-burners like that into the kernel
>>> anyway. That loop should have a cpu_relax() in it. Which will also
>>> fix the
>>> compiler problem described above.
>>>
>>>
>> Agreed, and fixed with a cpu_relax.
>
>>> Thirdly, please always add a newline when coding statements like that:
>>>
>>> while (expr())
>>> ;
>>>
>> The other instances I found of the same problem in the kgdb core are
>> fixed too.
>
>> I merged all the changes into the for_mm branch in the kgdb git tree.
>
> Where is the kgdb git tree?
Why am I getting this when I do:
git clone
http://master.kernel.org/pub/scm/linux/kernel/git/jwessel/linux-2.6-kgdb.git
-
----------------------------------------------------------------------------
error: Couldn't get
http://master.kernel.org/pub/scm/linux/kernel/git/jwessel/linux-2.6-kgdb.git/refs/tags/v2.6.11
for tags/v2.6.11
The requested URL returned error: 404
error: Could not interpret tags/v2.6.11 as something to pull
rm: cannot remove directory
`/nethome/piet/Src/linux/git/jwessel/linux-2.6-kgdb/.git/clone-tmp':
Directory not empty
/nethome/piet/Src/linux/git/jwessel$
-
----------------------------------------------------------------------------
We are getting a problem with VMware where kernel text is the schedler
is getting wacked with four null bytes into the code. Thought I'd use
the current linux-2.6-kgdb.git tree and possible the CONFIG_DEBUG_RODATA
patch to make kernel text readonly:
https://www.x86-64.org/pipermail/patches/2007-March/003666.html
I thought the kernel text was RO and gdb had to disable it to
insert a breakpoint.
- -piet
>
> -piet
>
>> Thanks,
>> Jason.
>> -
>> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>> Please read the FAQ at http://www.tux.org/lkml/
>
>
- -
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFG1hshJICwm/rv3hoRAhTGAJ46pq69zYHqRmT+yTmRx+RVh8aBtgCfdyFM
gl91xCFTy0NJxHalVXpd9Os=
=c8FZ
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: Document and implement an improved flash device binding
From: David Gibson @ 2007-08-30 1:18 UTC (permalink / raw)
To: Domen Puncer; +Cc: linuxppc-dev
In-Reply-To: <20070829084341.GS13994@moe.telargo.com>
On Wed, Aug 29, 2007 at 10:43:41AM +0200, Domen Puncer wrote:
> On 29/08/07 16:13 +1000, David Gibson wrote:
>
> <snip>
> > static int __devinit of_physmap_probe(struct of_device *dev, const struct of_device_id *match)
> > {
> > struct device_node *dp = dev->node;
> > struct resource res;
> > struct physmap_flash_info *info;
> > - const char **probe_type;
> > - const char *of_probe;
> > + const char *probe_type = (const char *)match->data;
> > const u32 *width;
> > int err;
> >
> > + dev_warn(&dev->dev, "Device tree uses obsolete \"direct-mapped\" "
> > + "flash binding\n");
>
> This is printed for new binding too :-)
Duh, put that warning in completely the wrong place. I was awake,
obviously :-/
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [PATCH 0/4] PowerPC 440EPx: Initial Sequoia support
From: Josh Boyer @ 2007-08-30 0:28 UTC (permalink / raw)
To: Valentine Barshak; +Cc: linuxppc-dev
In-Reply-To: <20070829133520.GA19925@ru.mvista.com>
On Wed, 2007-08-29 at 17:35 +0400, Valentine Barshak wrote:
> The following patches add initial PowerPC 440EPx Sequoia board support.
> The code is based mainly on the Bamboo board support by Josh Boyer.
> These patches have been modified according the comments for the previous
> 440EPx Sequoia patch series.
I see David has beaten me to reviewing the individual patches, which of
course is always welcome. I just wanted add that I also think these
look good. Thanks!
josh
^ permalink raw reply
* Re: [PATCH 3/3] Add early debug console for CPM serial ports.
From: David Gibson @ 2007-08-30 0:58 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <20070829195837.GA6818@ld0162-tx32.am.freescale.net>
On Wed, Aug 29, 2007 at 02:58:37PM -0500, Scott Wood wrote:
> On Wed, Aug 29, 2007 at 09:02:39AM -0500, Scott Wood wrote:
> > > > # Temporary hack until we have migrated to asm-powerpc
> > > > ifeq ($(ARCH),powerpc)
> > > > +obj-$(CONFIG_CPM1)$(CONFIG_CPM2) += cpm_common.o
> > >
> > > Uh.. I don't think this will work properly. If CONFIG_CPM1 and
> > > CONFIG_CPM2 are both enabled, it will set obj-yy rather than obj-y.
> >
> > The assumption was that CPM1 and CPM2 are never going to both be enabled,
> > as CPM1 only exists on hardware with a unique MMU.
> >
> > I could add an obj-y += $(obj-yy) if you like, though.
>
> On second thought, I'll just add a CONFIG_CPM that CPM1 and CPM2 select;
> that'll make things easier for further consolidation.
Ah, yes, that's much nicer.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [PATCH 3/3] Add early debug console for CPM serial ports.
From: David Gibson @ 2007-08-30 0:57 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <20070829140239.GC30184@ld0162-tx32.am.freescale.net>
On Wed, Aug 29, 2007 at 09:02:39AM -0500, Scott Wood wrote:
> On Wed, Aug 29, 2007 at 03:45:40PM +1000, David Gibson wrote:
> > > diff --git a/arch/powerpc/Kconfig.debug b/arch/powerpc/Kconfig.debug
> > > index 22acece..d471154 100644
> > > --- a/arch/powerpc/Kconfig.debug
> > > +++ b/arch/powerpc/Kconfig.debug
> > > @@ -211,6 +211,15 @@ config PPC_EARLY_DEBUG_44x
> > > Select this to enable early debugging for IBM 44x chips via the
> > > inbuilt serial port.
> > >
> > > +config PPC_EARLY_DEBUG_CPM
> > > + bool "Early serial debugging for Freescale CPM-based serial ports"
> > > + depends on SERIAL_CPM
> > > + select PIN_TLB if PPC_8xx
> >
> > I see this Kconfig line, but I don't see any code below that would set
> > up a suitable TLB on 8xx for the CPM...?
>
> There's existing code that pins the IMMR when that option is enabled.
> It's a bit broken, but there's a patch in the 8xx series that fixes it.
>
> > > # Temporary hack until we have migrated to asm-powerpc
> > > ifeq ($(ARCH),powerpc)
> > > +obj-$(CONFIG_CPM1)$(CONFIG_CPM2) += cpm_common.o
> >
> > Uh.. I don't think this will work properly. If CONFIG_CPM1 and
> > CONFIG_CPM2 are both enabled, it will set obj-yy rather than obj-y.
>
> The assumption was that CPM1 and CPM2 are never going to both be enabled,
> as CPM1 only exists on hardware with a unique MMU.
Hrm. I guess it's ok in that case, although it's a non-obvious
constraint.
> I could add an obj-y += $(obj-yy) if you like, though.
Ouch, no, that would be even uglier.
> > Since this is all udbg related, it could go (within an ifdef) into
> > udbg.c rather than creating a new file for it.
>
> Well, I was hoping that more consolidation between cpm1 and cpm2 (and
> qe/cpm3, for that matter) would happen in the future, and this would be a
> place to put it.
>
> > Urg... this is ugly, because it looks like it can be muti-platform,
> > but actually isn't. I think a better approach is to set the magic
> > address as a Kconfig variable, as we do on 44x. This approach can
> > also be useful for hacking up early debug for new chips during the
> > process of creating platform code for them.
>
> OK.
>
> -Scott
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox