* Re: [PATCH] Fake NUMA emulation for PowerPC
From: David Rientjes @ 2007-12-07 23:06 UTC (permalink / raw)
To: Olof Johansson; +Cc: linuxppc-dev, LKML, Balbir Singh
In-Reply-To: <20071207212817.GA391@lixom.net>
On Fri, 7 Dec 2007, Olof Johansson wrote:
> > Comments are as always welcome!
>
> Care to explain what this is useful for? (Not saying it's a stupid idea,
> just wondering what the reason for doing it is).
>
Fake NUMA has always been useful for testing NUMA code without having to
have a wide range of hardware available to you. It's a clever tool on
x86_64 intended for kernel developers that simply makes it easier to test
code and adds an increased level of robustness to the kernel. I think
it's a valuable addition.
^ permalink raw reply
* Re: [PATCH] Fake NUMA emulation for PowerPC
From: David Rientjes @ 2007-12-07 23:10 UTC (permalink / raw)
To: Balbir Singh; +Cc: Olof Johansson, linuxppc-dev, LKML
In-Reply-To: <4759C548.6030304@linux.vnet.ibm.com>
On Sat, 8 Dec 2007, Balbir Singh wrote:
> To be able to test the memory controller under NUMA, I use fake NUMA
> nodes. x86-64 has a similar feature, the code I have here is the
> simplest I could come up with for PowerPC.
>
Magnus Damm had patches from over a year ago that, I believe, made much of
the x86_64 fake NUMA code generic so that it could be extended for
architectures such as i386. Perhaps he could resurrect those patches if
there is wider interest in such a tool.
^ permalink raw reply
* Re: [PATCH] Fake NUMA emulation for PowerPC
From: David Rientjes @ 2007-12-07 23:11 UTC (permalink / raw)
To: Balbir Singh; +Cc: linuxppc-dev, Nathan Lynch, LKML
In-Reply-To: <4759C89B.9000709@linux.vnet.ibm.com>
On Sat, 8 Dec 2007, Balbir Singh wrote:
> Yes, they all appear on node 0. We could have tweaks to distribute CPU's
> as well.
>
You're going to want to distribute the cpu's based on how they match up
physically with the actual platform that you're running on. x86_64 does
this already and it makes fake NUMA more useful because it matches the
real-life case more often.
^ permalink raw reply
* Re: dtc: Convert #address-cells and #size-cells related checks
From: David Gibson @ 2007-12-07 23:22 UTC (permalink / raw)
To: Jon Loeliger, linuxppc-dev
In-Reply-To: <20071207030555.GB26412@localhost.localdomain>
On Fri, Dec 07, 2007 at 02:05:55PM +1100, David Gibson wrote:
> This patch converts checks related to #address-cells and #size-cells
> to the new framework. Specifically, it reimplements the check that
> "reg" properties have a valid size based on the relevant
> #address-cells and #size-cells values. The new implementation uses
> the correct default value, unlike the old-style check which assumed
> the values were inherited by default.
>
> It also implements a new, similar test for "ranges" properties.
>
> Finally, since relying on the default values of these variables is
> considered not-good-practice these days, it implements a "style" check
> which will give a warning if the tree ever relies on the default
> values (that is if any node with either "reg" or "ranges" appears
> under a parent which has no #address-cells or #size-cells property).
Oops, that should, of course, be:
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
--
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: [DTC][PATCH] Fix cross-compile building
From: David Gibson @ 2007-12-08 0:36 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, Jon Loeliger, stuarth
In-Reply-To: <Pine.LNX.4.64.0712071227280.1788@blarg.am.freescale.net>
On Fri, Dec 07, 2007 at 12:28:20PM -0600, Kumar Gala wrote:
> From: Stuart Hughes <stuarth@freescale.com>
>
> This patch allows you to build the DTC source without making the
> tests directory. This is necessary when cross compiling as the
> dumptest (and other) files cannot be run/used on the host system.
> To use this use: 'make TESTS='
I think this is a silly way of doing this. Instead create a new
target which builds everything but the tests.
Say,
all: cross tests
cross: dtc ftdump libfdt
--
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: Xilinx EDK BSP generation of device trees for microblaze and PowerPC
From: Stephen Neuendorffer @ 2007-12-08 0:58 UTC (permalink / raw)
To: Grant Likely; +Cc: microblaze-uclinux, git, linuxppc-dev
In-Reply-To: <fa686aa40712021847k21a9a360u9fc2b887c9db49c7@mail.gmail.com>
=20
> > > -----Original Message-----
> > > From: glikely@secretlab.ca [mailto:glikely@secretlab.ca] On
> > > Behalf Of Grant Likely
> > > Sent: Sunday, November 25, 2007 2:47 PM
> > > To: Stephen Neuendorffer; Segher Boessenkool; David Gibson;
> > > Jon Loeliger
> > > Cc: microblaze-uclinux@itee.uq.edu.au;
> > > linuxppc-dev@ozlabs.org; Michal Simek; git
> > > Subject: Re: Xilinx EDK BSP generation of device trees for
> > > microblaze and PowerPC
> > >
> > > On 11/24/07, Stephen Neuendorffer
> > > <stephen.neuendorffer@xilinx.com> wrote:
> > > >
> > >
> > > Thanks for all this work; comments below.
> > >
> > > >
> > > > Here's what I've gotten so far:
> > > >
> > > > Hard_Ethernet_MAC: xps-ll-temac@81c00000 {
> > > > #address-cells =3D <1>;
> > > > #size-cells =3D <1>;
> > > > network@81c00000 {
> > > > compatible =3D
> > > "xlnx,xps-ll-temac-1.00.a",
> > > > "xlnx,xps-ll-temac";
> > >
> > > Drop "xlnx,xps-ll-temac"; it's 100% made up. This should=20
> be simply:
> > > compatible =3D "xlnx,xps-ll-temac-1.00.a" for version=20
> 1.00.a and
> > > compatible =3D
> > > "xlnx,xps-ll-temac-<version>","xlnx,xps-ll-temac-1.00.a"=20
> for a future
> > > version if it maintains register level compatibility.
> > >
> > > "xlnx,xps-ll-temac" is far to ambiguous.
> >
> > What if it was: compatible =3D "xlnx,xps-ll-temac-1.00.a",
> > "xlnx,xps-ll-temac-1"?
>=20
> Here's what I've learned: There is no such thing as a perfect device
> tree. Either hardware bugs will be discovered at a later date which
> make compatible inaccurate, or a better understanding of the device
> will come along which will change the understood best practices for
> describing the device.
>=20
> My opinion is the best strategy against claiming something that's not
> true, or won't be true in the fucture, is to strive for uniqueness and
> describe only what you are certain of. Be conservative instead of
> liberal in the compatible case; ie. it's easier to teach the driver
> about other versions it can bind against than it is to teach it about
> exceptions to certain versions of the hardware (when binding).
>=20
> In this particular case the problem still stands that the VHDL
> engineer may make a non backward compatible change in version
> xlnx,xps-ll-temac-1.00.c or -1.03.c. You just don't know until it
> happens. Stick with what is known and don't try to extrapolate to a
> 'generic' version when there is no guarantee that it will remain
> generic.
>=20
> When sticking with real version numbers, it is quite safe to claim
> compatibility with an older version number because you've probably
> tested it; something which isn't so safe when you attempt to make up
> generic versions.
I think you've convinced me... :) I think the only reason to ever put
more than one thing in the compatible list, is if you want to declare
that you are compatible with an established, standard driver and you
don't have control over the driver. ns16550 is a great example of this,
where it is so ubiquitous that the driver is likely to be much more
stable over time than any particular hardware.
I did some quick scripting around in various versions of EDK. For the
record, Xilinx shipped about 369 distinct versions of processor IP with
the EDK, since EDK 6.3:
369 /home/stephenn/iplist_combined
And there's obviously alot of overlap between the different versions:
202 EDK 6.3
227 EDK 7.1
268 EDK 8.2
297 EDK 9.2
But the total number of drivers is much smaller:
87 EDK 6.3
91 EDK 7.1
86 EDK 8.2
112 EDK 9.2
And it appears that there are a relatively small number of changes which
the drivers claim are not forwards compatible (not to say that there
aren't other incompatibilities, but this is the compatibility that we
can infer based on what the drivers claim).
opb_ethernet_v1_01_a -> opb_ethernet_v1_02_a -> opb_ethernet_v1_04_[a-z]
opb_ethernetlite_v1_00_a -> opb_ethernetlite_v1_01_a
opb_pci_v1_00_c -> opb_pci_v1_01_a
plb_temac_v2_00_a -> plb_temac_v3_00_a
opb_deltasigma_dac_v1_00_a -> opb_deltasigma_dac_v1_01_a
opb_deltasigma_adc_v1_01_a -> opb_deltasigma_dac_v1_01_a
opb_hwicap_v1_00_b -> opb_hwicap_v1_10_a
In any event, my plan is to put only the exact version name in the
device tree and list all the compatible versions in the driver match.
Steve
^ permalink raw reply
* Re: Uboot and ML410
From: Wolfgang Denk @ 2007-12-08 1:02 UTC (permalink / raw)
To: khollan; +Cc: linuxppc-embedded
In-Reply-To: <14198812.post@talk.nabble.com>
In message <14198812.post@talk.nabble.com> you wrote:
>
> When I try compiling with my tools I get the message
> No rule to make target `hello_world.srec', needed by `all'
> Any way to work around this. I have compiled everything else I use on my
Yes - just use a current version of the code (i. e. U-Boot 1.3.1).
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
Misquotation is, in fact, the pride and privilege of the learned. A
widely-read man never quotes accurately, for the rather obvious
reason that he has read too widely.
- Hesketh Pearson _Common Misquotations_ introduction
^ permalink raw reply
* dtc: Remove header information dumping
From: David Gibson @ 2007-12-08 1:19 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev
Currently, when used in -Idtb mode, dtc will dump information about
the input blob's header fields to stderr. This is kind of ugly, and
can get in the way of dtc's real output.
This patch, therefore, removes this. So that there's still a way of
getting this information for debugging purposes, it places something
similar to the removed code into ftdump, replacing the couple of
header fields it currently prints with a complete header dump.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Index: dtc/flattree.c
===================================================================
--- dtc.orig/flattree.c 2007-12-08 12:06:11.000000000 +1100
+++ dtc/flattree.c 2007-12-08 12:13:15.000000000 +1100
@@ -898,15 +898,6 @@
off_mem_rsvmap = be32_to_cpu(fdt->off_mem_rsvmap);
version = be32_to_cpu(fdt->version);
- fprintf(stderr, "\tmagic:\t\t\t0x%x\n", magic);
- fprintf(stderr, "\ttotalsize:\t\t%d\n", totalsize);
- fprintf(stderr, "\toff_dt_struct:\t\t0x%x\n", off_dt);
- fprintf(stderr, "\toff_dt_strings:\t\t0x%x\n", off_str);
- fprintf(stderr, "\toff_mem_rsvmap:\t\t0x%x\n", off_mem_rsvmap);
- fprintf(stderr, "\tversion:\t\t0x%x\n", version );
- fprintf(stderr, "\tlast_comp_version:\t0x%x\n",
- be32_to_cpu(fdt->last_comp_version));
-
if (off_mem_rsvmap >= totalsize)
die("Mem Reserve structure offset exceeds total size\n");
@@ -916,21 +907,15 @@
if (off_str > totalsize)
die("String table offset exceeds total size\n");
- if (version >= 2)
- fprintf(stderr, "\tboot_cpuid_phys:\t0x%x\n",
- be32_to_cpu(fdt->boot_cpuid_phys));
-
size_str = -1;
if (version >= 3) {
size_str = be32_to_cpu(fdt->size_dt_strings);
- fprintf(stderr, "\tsize_dt_strings:\t%d\n", size_str);
if (off_str+size_str > totalsize)
die("String table extends past total size\n");
}
if (version >= 17) {
size_dt = be32_to_cpu(fdt->size_dt_struct);
- fprintf(stderr, "\tsize_dt_struct:\t\t%d\n", size_dt);
if (off_dt+size_dt > totalsize)
die("Structure block extends past total size\n");
}
Index: dtc/ftdump.c
===================================================================
--- dtc.orig/ftdump.c 2007-12-08 12:06:23.000000000 +1100
+++ dtc/ftdump.c 2007-12-08 12:15:09.000000000 +1100
@@ -81,11 +81,13 @@
static void dump_blob(void *blob)
{
struct fdt_header *bph = blob;
+ uint32_t off_mem_rsvmap = be32_to_cpu(bph->off_mem_rsvmap);
+ uint32_t off_dt = be32_to_cpu(bph->off_dt_struct);
+ uint32_t off_str = be32_to_cpu(bph->off_dt_strings);
struct fdt_reserve_entry *p_rsvmap =
- (struct fdt_reserve_entry *)(blob
- + be32_to_cpu(bph->off_mem_rsvmap));
- char *p_struct = blob + be32_to_cpu(bph->off_dt_struct);
- char *p_strings = blob + be32_to_cpu(bph->off_dt_strings);
+ (struct fdt_reserve_entry *)(blob + off_mem_rsvmap);
+ char *p_struct = blob + off_dt;
+ char *p_strings = blob + off_str;
uint32_t version = be32_to_cpu(bph->version);
uint32_t totalsize = be32_to_cpu(bph->totalsize);
uint32_t tag;
@@ -98,8 +100,26 @@
depth = 0;
shift = 4;
- printf("// Version 0x%x tree\n", version);
- printf("// Totalsize 0x%x(%d)\n", totalsize, totalsize);
+ printf("// magic:\t\t0x%x\n", be32_to_cpu(bph->magic));
+ printf("// totalsize:\t\t0x%x (%d)\n", totalsize, totalsize);
+ printf("// off_dt_struct:\t0x%x\n", off_dt);
+ printf("// off_dt_strings:\t0x%x\n", off_str);
+ printf("// off_mem_rsvmap:\t0x%x\n", off_mem_rsvmap);
+ printf("// version:\t\t%d\n", version);
+ printf("// last_comp_version:\t%d\n",
+ be32_to_cpu(bph->last_comp_version));
+ if (version >= 2)
+ printf("// boot_cpuid_phys:\t0x%x\n",
+ be32_to_cpu(bph->boot_cpuid_phys));
+
+ if (version >= 3)
+ printf("// size_dt_strings:\t0x%x\n",
+ be32_to_cpu(bph->size_dt_strings));
+ if (version >= 17)
+ printf("// size_dt_struct:\t0x%x\n",
+ be32_to_cpu(bph->size_dt_struct));
+ printf("\n");
+
for (i = 0; ; i++) {
addr = be64_to_cpu(p_rsvmap[i].address);
size = be64_to_cpu(p_rsvmap[i].size);
--
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 1/5] PowerPC 74xx: Katana Qp device tree
From: David Gibson @ 2007-12-08 1:33 UTC (permalink / raw)
To: Mark A. Greer; +Cc: linuxppc-dev, David Gibson
In-Reply-To: <20071206232756.GB4719@mag.az.mvista.com>
On Thu, Dec 06, 2007 at 04:27:56PM -0700, Mark A. Greer wrote:
> David, et. al.,
>
> This is a big blob patch of what I've changed for the prpmc2800. It
> includes the necessary changes in the kernel which you can probably
> ignore but they're there for reference. If you like the dts, then I'll
> split the blob up into logical pieces and Andrei can make similar
> changes for the Katana Qp.
>
> Let me know what you think.
Looks pretty reasonable. I would have preferred that labels be
uppercase by convention, to make them easier to pick out by eyeball,
but I think that's a lost cause at this stage.
--
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] Fake NUMA emulation for PowerPC
From: Balbir Singh @ 2007-12-08 4:22 UTC (permalink / raw)
To: David Rientjes; +Cc: Olof Johansson, linuxppc-dev, LKML
In-Reply-To: <alpine.DEB.0.9999.0712071508460.27689@chino.kir.corp.google.com>
David Rientjes wrote:
> On Sat, 8 Dec 2007, Balbir Singh wrote:
>
>> To be able to test the memory controller under NUMA, I use fake NUMA
>> nodes. x86-64 has a similar feature, the code I have here is the
>> simplest I could come up with for PowerPC.
>>
>
> Magnus Damm had patches from over a year ago that, I believe, made much of
> the x86_64 fake NUMA code generic so that it could be extended for
> architectures such as i386. Perhaps he could resurrect those patches if
> there is wider interest in such a tool.
That would be a very interesting patch, but what I have here is the
simplest patch and we could build on it incrementally. The interface is
non-standard but it does amazing things for 59 lines of code change.
--
Warm Regards,
Balbir Singh
Linux Technology Center
IBM, ISTL
^ permalink raw reply
* Re: [PATCH] Fake NUMA emulation for PowerPC
From: Balbir Singh @ 2007-12-08 4:32 UTC (permalink / raw)
To: David Rientjes; +Cc: linuxppc-dev, Nathan Lynch, LKML
In-Reply-To: <alpine.DEB.0.9999.0712071510370.27689@chino.kir.corp.google.com>
David Rientjes wrote:
> On Sat, 8 Dec 2007, Balbir Singh wrote:
>
>> Yes, they all appear on node 0. We could have tweaks to distribute CPU's
>> as well.
>>
>
> You're going to want to distribute the cpu's based on how they match up
> physically with the actual platform that you're running on. x86_64 does
Could you explain this better, how does it match up CPU's with fake NUMA
memory? Is there some smartness there? I'll try and look at the code and
also see what I can do for PowerPC
> this already and it makes fake NUMA more useful because it matches the
> real-life case more often.
Yes, I agree, but I don't want that to be the first step for fake NUMA
nodes on PowerPC. I think we can incrementally add features.
--
Warm Regards,
Balbir Singh
Linux Technology Center
IBM, ISTL
^ permalink raw reply
* Re: [PATCH] Fake NUMA emulation for PowerPC
From: David Rientjes @ 2007-12-08 4:45 UTC (permalink / raw)
To: Balbir Singh; +Cc: linuxppc-dev, Nathan Lynch, LKML
In-Reply-To: <475A1E6E.3010303@linux.vnet.ibm.com>
On Sat, 8 Dec 2007, Balbir Singh wrote:
> > You're going to want to distribute the cpu's based on how they match up
> > physically with the actual platform that you're running on. x86_64 does
>
> Could you explain this better, how does it match up CPU's with fake NUMA
> memory? Is there some smartness there? I'll try and look at the code and
> also see what I can do for PowerPC
>
numa_cpumask_lookup_table[] would return the correct cpumask for the fake
node index. Then all the code that uses node_to_cpumask() in generic
kernel code like the scheduler and VM still preserve their true NUMA
affinity that matches the underlying hardware. I tried to make x86_64
fake NUMA as close to the real thing as possible.
You also probably want to make all you changes dependent on
CONFIG_NUMA_EMU like the x86_64 case. That'll probably be helpful as you
extend this tool more and more.
David
^ permalink raw reply
* Please pull linux-2.6-8xx.git for-paulus branch
From: Vitaly Bordug @ 2007-12-08 10:00 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev@ozlabs.org
Paul,
please do
git-pull git://git.kernel.org/pub/scm/linux/kernel/git/vitb/linux-2.6-8xx.git for-paulus
to receive the following updates:
Jochen Friedrich (4):
powerpc: fix typo #ifdef -> #ifndef
powerpc: kill non-existent symbols from ksyms and commproc.h
powerpc: Add support for PORTA and PORTB odr registers
powerpc: Move CPM command handling into the cpm drivers
Scott Wood (1):
8xx: Convert mpc866ads to the new device binding.
arch/powerpc/boot/dts/mpc866ads.dts | 156 +++++++++------
arch/powerpc/kernel/ppc_ksyms.c | 12 -
arch/powerpc/platforms/8xx/Kconfig | 1 +
arch/powerpc/platforms/8xx/mpc86xads.h | 44 ----
arch/powerpc/platforms/8xx/mpc86xads_setup.c | 289 +++++++-------------------
arch/powerpc/sysdev/commproc.c | 47 ++++-
arch/powerpc/sysdev/cpm2_common.c | 25 +++
drivers/net/fs_enet/mac-fcc.c | 10 +-
drivers/net/fs_enet/mac-scc.c | 13 +-
drivers/serial/cpm_uart/cpm_uart_cpm1.c | 6 +-
drivers/serial/cpm_uart/cpm_uart_cpm2.c | 8 +-
include/asm-powerpc/commproc.h | 3 -
include/asm-powerpc/cpm.h | 1 +
13 files changed, 250 insertions(+), 365 deletions(-)
--
Sincerely, Vitaly
^ permalink raw reply
* Re: Please pull linux-2.6-8xx.git for-paulus branch
From: Vitaly Bordug @ 2007-12-08 10:09 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Paul Mackerras
In-Reply-To: <20071208130025.09021cb0@kernel.crashing.org>
On Sat, 8 Dec 2007 13:00:25 +0300
Vitaly Bordug wrote:
> Paul,
>
> please do
> git-pull
> git://git.kernel.org/pub/scm/linux/kernel/git/vitb/linux-2.6-8xx.git
> for-paulus
>
> to receive the following updates:
>
Forgot to tell that this is .25 material...
--
Sincerely, Vitaly
^ permalink raw reply
* Re: [DTC][PATCH] Fix cross-compile building
From: Stuart Hughes @ 2007-12-08 12:53 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev, Jon Loeliger
In-Reply-To: <20071208003604.GH566@localhost.localdomain>
On Sat, 2007-12-08 at 11:36 +1100, David Gibson wrote:
> On Fri, Dec 07, 2007 at 12:28:20PM -0600, Kumar Gala wrote:
> > From: Stuart Hughes <stuarth@freescale.com>
> >
> > This patch allows you to build the DTC source without making the
> > tests directory. This is necessary when cross compiling as the
> > dumptest (and other) files cannot be run/used on the host system.
> > To use this use: 'make TESTS='
>
> I think this is a silly way of doing this. Instead create a new
> target which builds everything but the tests.
>
> Say,
>
> all: cross tests
>
> cross: dtc ftdump libfdt
>
Works for me.
Regards, Stuart
^ permalink raw reply
* Re: Please pull linux-2.6-8xx.git for-paulus branch
From: Kumar Gala @ 2007-12-08 15:17 UTC (permalink / raw)
To: Vitaly Bordug; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <20071208130934.093d80f9@kernel.crashing.org>
On Dec 8, 2007, at 4:09 AM, Vitaly Bordug wrote:
> On Sat, 8 Dec 2007 13:00:25 +0300
> Vitaly Bordug wrote:
>
>> Paul,
>>
>> please do
>> git-pull
>> git://git.kernel.org/pub/scm/linux/kernel/git/vitb/linux-2.6-8xx.git
>> for-paulus
>>
>> to receive the following updates:
>>
> Forgot to tell that this is .25 material...
Vitaly, if you don't mind I'll pull these into my tree for Paul to
collect all the FSL stuff in one place.
- k
^ permalink raw reply
* mmap + segfaults on MPC8349E
From: R. Ebersole (VTI - new) @ 2007-12-09 2:44 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 1462 bytes --]
Hi.
We've run into an .... interesting (and frustrating) occurance recently
while testing
out a new board (and BSP). We were wondering if anybody has seen anything
like this.
A description follows:
We wrote some simple drivers/modules to mmap() FPGA registers to user space.
At the moment, for testing, we reserve the upper x-MB of RAM, and mmap()
there, instead.
We open 4 such devices, and mmap() 64KB of space (memory, in this case)
for each.
Accessing the first device opened & mmapped was fine. But accesssing
the 2nd device
yielded some odd behavior. We could read and write the first and 3rd 4K
regions fine, but
if we read from the 2nd one (at offset 0x1000) before we wrote to it, we
get a segmentation
fault. If, however, we wrote first (to the 2nd region), then things
were OK.
Addendum: With the real device, this same behavior happens at the 10th
4-KB region of the device.
Without any of the others mmap()-ed. If we mmap() just that 4-KB
region, things are fine. We
can access the region with ioremap() in the driver w/o issues.
We are running on an MPC8349-E.
Any thoughts or ideas?
vti
--
This message contains confidential information and is intended only for the
individual named. If you are not the intended recipient you should not
disseminate, distribute or copy this e-mail. Please notify the sender
immediately by e-mail if you have received this e-mail by mistake and delete
this e-mail from your system.
[-- Attachment #2: Type: text/html, Size: 1987 bytes --]
^ permalink raw reply
* Re: mmap + segfaults on MPC8349E
From: David Hawkins @ 2007-12-09 4:01 UTC (permalink / raw)
To: R. Ebersole (VTI - new); +Cc: linuxppc-embedded
In-Reply-To: <475B5680.30303@valleytech.com>
Hi,
You haven't really provided enough information.
> We wrote some simple drivers/modules to mmap() FPGA registers to user space.
> At the moment, for testing, we reserve the upper x-MB of RAM, and mmap()
> there, instead.
1. The FPGA is located where? The local bus, or the PCI bus?
What frequency are you trying to operate at?
2. If its on the local bus, do you access it using GPCM or UPM?
Have you setup either correctly?
Have you confirmed the bus timing with a logic analyzer?
3. Have you created a bus functional model of the processor bus
that you have then run with your FPGA bus in ModelSim to
confirm that your FPGA performs correctly.
4. Have you tried burst and non-burst access by either using
DMA, or treating the memory area as cacheable or non-cacheable?
Have you checked those cases with simulation and then
with a scope or logic analyzer?
5. Did you try running stand-alone tests in U-Boot, to go for a
more bare-metal debug approach?
No point in debugging software if you have no idea whether the
hardware behaves. So confirm that you have tested your hardware
first.
My board design uses the MPC8349EA, I have an Altera Stratix II
FPGA on the local bus. I use GPCM to access flash on the local
bus via the FPGA, and UPM to access FPGA registers. I don't
have boards yet, but I've got a pretty good handle on how the
interface should work.
Cheers,
Dave
^ permalink raw reply
* Stupid git question: adding acked-by
From: Jerry Van Baren @ 2007-12-09 5:21 UTC (permalink / raw)
To: linuxppc-dev@ozlabs.org
OK git gurus, this is something I have not figured out: the best way to
add acked-by (or additional signed-off-by) lines to git patches.
What I'm talking about is when I've applied a patch to my repo and
published the change on the list and get an "acked-by" back. By the
time I get the ack, the acked patch may be several patches deep. My
current technique is to reset the repo, edit the patch(es) to add the
"acked-by" lines, and then re-apply the patches. PITA and probably the
stupidest way.
Stacked git should work (effectively does the same thing but more
gracefully), but I have not gone that route yet.
There must be a better way, if only I could find the right (of 137)
git-* command...
Hints, please?
Thanks,
gvb
^ permalink raw reply
* Xilinx ML310 Linux 2.6 PCI bridge
From: Jean-Samuel Chenard @ 2007-12-09 5:51 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 2639 bytes --]
Hi,
Thanks to the valuable information provided by this discussion group and
particularly by Grant Likely from Secret Lab Technologies, I was able to
setup and run Linux 2.6 on my ML-310 development platform.
On the ML-310, if I want to use the Ethernet port and some other
peripherals, I need to go through the PCI bus via the opb_pci core on the
FPGA.
However, when I enable PCI support in the kernel, I get the following error
messages:
arch/ppc/syslib/ppc4xx_setup.c: In function `ppc4xx_map_io':
arch/ppc/syslib/ppc4xx_setup.c:118: error: `PPC4xx_PCI_IO_VADDR' undeclared
(first use in this function)
arch/ppc/syslib/ppc4xx_setup.c:118: error: (Each undeclared identifier is
reported only once
arch/ppc/syslib/ppc4xx_setup.c:118: error: for each function it appears in.)
arch/ppc/syslib/ppc4xx_setup.c:119: error: `PPC4xx_PCI_IO_PADDR' undeclared
(first use in this function)
arch/ppc/syslib/ppc4xx_setup.c:119: error: `PPC4xx_PCI_IO_SIZE' undeclared
(first use in this function)
arch/ppc/syslib/ppc4xx_setup.c:120: error: `PPC4xx_PCI_CFG_VADDR' undeclared
(first use in this function)
arch/ppc/syslib/ppc4xx_setup.c:121: error: `PPC4xx_PCI_CFG_PADDR' undeclared
(first use in this function)
arch/ppc/syslib/ppc4xx_setup.c:121: error: `PPC4xx_PCI_CFG_SIZE' undeclared
(first use in this function)
arch/ppc/syslib/ppc4xx_setup.c:122: error: `PPC4xx_PCI_LCFG_VADDR'
undeclared (first use in this function)
arch/ppc/syslib/ppc4xx_setup.c:123: error: `PPC4xx_PCI_LCFG_PADDR'
undeclared (first use in this function)
arch/ppc/syslib/ppc4xx_setup.c:123: error: `PPC4xx_PCI_LCFG_SIZE' undeclared
(first use in this function)
make[1]: *** [arch/ppc/syslib/ppc4xx_setup.o] Error 1
My Xilinx Platform Studio has the proper PCI bridge component, but the
exported constants in xparameters_ml300.h are not helping me figure out the
mapping that I should give to those PPC4xx values (the parameters contain a
lot of XPAR_PCI32_BRIDGE_* constants). I'm guessing that the address
mappings must be set from some of those for the PCI range to appear in the
PowerPC address space. Please correct me if I'm misunderstanding something
here...
I only saw one mention of this error related to the ML-310 in a discussion
dating in 2005 and the answer was that the 2.6 kernel was not supporting the
Virtex-II Pro too well at the time. Has this changed and does anyone have
had success using the PCI bridge in Linux 2.6 on an ML-310 development
platform ?
Thanks,
Jean-Samuel
--
Integrated Microsystems Laboratory
McGill University, Montréal, QC, CANADA
Web Page: http://chaos.ece.mcgill.ca
[-- Attachment #2: Type: text/html, Size: 2814 bytes --]
^ permalink raw reply
* Re: Stupid git question: adding acked-by
From: Geoff Levand @ 2007-12-09 6:04 UTC (permalink / raw)
To: Jerry Van Baren; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <475B7B41.4000505@gmail.com>
On 12/08/2007 09:21 PM, Jerry Van Baren wrote:
> OK git gurus, this is something I have not figured out: the best way to
> add acked-by (or additional signed-off-by) lines to git patches.
>
> What I'm talking about is when I've applied a patch to my repo and
> published the change on the list and get an "acked-by" back. By the
> time I get the ack, the acked patch may be several patches deep. My
> current technique is to reset the repo, edit the patch(es) to add the
> "acked-by" lines, and then re-apply the patches. PITA and probably the
> stupidest way.
>
> Stacked git should work (effectively does the same thing but more
> gracefully), but I have not gone that route yet.
>
> There must be a better way, if only I could find the right (of 137)
> git-* command...
I keep patches in a repo. I just update the patch header and commit.
-Geoff
^ permalink raw reply
* Re: Xilinx ML310 Linux 2.6 PCI bridge
From: Grant Likely @ 2007-12-09 6:18 UTC (permalink / raw)
To: Jean-Samuel Chenard; +Cc: linuxppc-embedded
In-Reply-To: <169c03cb0712082151k74e504bvc6e21bb57534ef28@mail.gmail.com>
On 12/8/07, Jean-Samuel Chenard <jsamch@macs.ece.mcgill.ca> wrote:
> Hi,
>
> Thanks to the valuable information provided by this discussion group and
> particularly by Grant Likely from Secret Lab Technologies, I was able to
> setup and run Linux 2.6 on my ML-310 development platform.
Congratulations. If you had to make any changes to get it to work
then please send me your patches.
>
> On the ML-310, if I want to use the Ethernet port and some other
> peripherals, I need to go through the PCI bus via the opb_pci core on the
> FPGA.
>
> However, when I enable PCI support in the kernel, I get the following error
> messages:
You'll have to go back into the mailing list archives to find a patch
for adding PCI support for a Virtex platform. I don't have any of
that in my tree. It probably only exists for the 2.4 kernel. You'll
need to port forward to use it on 2.6 (I'm more than willing to help
you with this)
However, word of warning. The Xilinx PCI bridge is badly broken.
Xilinx is not supporting the PCI core and it is missing the ability to
do certain types of transfers. Last I heard, Xilinx has no plans to
fix their PCI core either.
Best of luck,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: Stupid git question: adding acked-by
From: Grant Likely @ 2007-12-09 6:22 UTC (permalink / raw)
To: Jerry Van Baren; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <475B7B41.4000505@gmail.com>
On 12/8/07, Jerry Van Baren <gvb.linuxppc.dev@gmail.com> wrote:
> Stacked git should work (effectively does the same thing but more
> gracefully), but I have not gone that route yet.
This is my preferred solution, but you don't have to do it this way.
>
> There must be a better way, if only I could find the right (of 137)
> git-* command...
Try git-cherry-pick. Get a list of the SHA-1 patch ids and reset your
branch. Then cherry pick each patch with the -e flag. Git will pull
up an editor and let you edit the commit message before applying so
you can add the Acked-by line.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: Stupid git question: adding acked-by
From: Stephen Rothwell @ 2007-12-09 6:43 UTC (permalink / raw)
To: Jerry Van Baren; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <475B7B41.4000505@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 378 bytes --]
On Sun, 09 Dec 2007 00:21:05 -0500 Jerry Van Baren <gvb.linuxppc.dev@gmail.com> wrote:
>
> OK git gurus, this is something I have not figured out: the best way to
> add acked-by (or additional signed-off-by) lines to git patches.
Have a look at "git rebase -i"
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH 16/25] powerpc: EP405 boards support for arch/powerpc
From: Benjamin Herrenschmidt @ 2007-12-09 6:57 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev
In-Reply-To: <20071206210550.520e5131@zod.rchland.ibm.com>
On Thu, 2007-12-06 at 21:05 -0600, Josh Boyer wrote:
> On Thu, 06 Dec 2007 19:00:15 +1100
> Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
>
> >
> > Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> > ---
> > Index: linux-work/arch/powerpc/boot/dts/ep405.dts
> > ===================================================================
> > --- /dev/null 1970-01-01 00:00:00.000000000 +0000
> > +++ linux-work/arch/powerpc/boot/dts/ep405.dts 2007-12-03 12:58:45.000000000 +1100
> > @@ -0,0 +1,221 @@
> > +/*
> > + * Device Tree Source for EP405
> > + *
> > + * Copyright 2007 IBM Corp.
> > + * Josh Boyer <jwboyer@linux.vnet.ibm.com>
>
> I still don't think I wrote this ;)
Yeah, right, I'll fix that, easy enough.
.../...
> > + if (!machine_is(ep405))
> > + return 0;
> > +
> > + /* FIXME: do bus probe here */
>
> I should really remove this stupid FIXME from my files so people stop
> copying it into theirs ;)
Yup :-) Your fault ;-)
.../...
> > + /* Find the bloody thing & map it */
> > + bcsr_node = of_find_compatible_node(NULL, NULL, "ep405-bcsr");
> > + if (bcsr_node == NULL) {
> > + printk(KERN_ERR "EP405 BCSR not found !\n");
> > + return;
> > + }
> > + bcsr_regs = of_iomap(bcsr_node, 0);
> > + if (bcsr_regs == NULL) {
> > + printk(KERN_ERR "EP405 BCSR failed to map !\n");
> > + return;
> > + }
>
> Is there a reason you have bcsr_node and bcsr_regs as static globals
> and leave the mapping present? I can't see another use of them outside
> of this function, which only gets called once.
For future use mostly. There's truckloads of things on this board going
trough this FPGA and It's likely that a more complete port will need to
use this things. In fact, the CPLD can more/less be used as a cascaded
IRQ on the PCI interrupts on that thing.
Ben.
^ 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