* Re: ARCH=ppc or ARCH=powerpc
From: Erik Christiansen @ 2007-06-28 8:36 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <20070628074430.GC8794@dd.nec.com.au>
On Thu, Jun 28, 2007 at 05:44:30PM +1000, Erik Christiansen wrote:
> Encountering a kernel build error with ARCH=ppc, after configuring as much as
> possible for MPC8248, I've just tried ARCH=powerpc on linux-2.6.21.5, with this
> slightly scary result:
Oh dear. Please excuse the noise. That was clearly acute lack of
familiarity with menuconfig. <blush>
Minus fingerfumbling, ARCH=powerpc starts to build, before coughing up a
bunch of compiler errors:
cpm2_common.c:63: error: 'CPM_MAP_ADDR' undeclared
Is that due to this patch not being accepted?:
http://patchwork.ozlabs.org/linuxppc/patch?id=8891
If the patch's "State Superseded" means something else fixes the build
failure, then how could I lay my grubby paws on that little gem?
Erik
^ permalink raw reply
* Re: [RFC/PATCH] powerpc: MPC7450 L2 HW cache flush feature utilization
From: Segher Boessenkool @ 2007-06-28 8:24 UTC (permalink / raw)
To: Vladislav Buzov; +Cc: linuxppc-dev list
In-Reply-To: <467FCC9D.6010904@ru.mvista.com>
>>> Note that 745x processors have L3 cache installed and may have the
>>> same
>>> problem requiring similar code modifications to use L3 hardware
>>> flushing
>>> mechanism.
>>
>> What does the erratum say?
>
> The erratum says nothing about any HW bugs with L3 cache flush. I just
> mentioned that the L3 cache flush operation described in MPC7450
> Reference manual is similar to the L2 using the L3 cache hardware
> flushing mechanism. For instance, it requires a complete L3 locking
> before flushing.
Then I think we should use that mechanism in the Linux kernel.
Anything else is waiting for bugs to bite.
>> The L3 is a very different beast from the L2, IIRC it is
>> a pure victim cache so it cannot have this problem at all?
>
> I'm not sure if it is a pure victim cache. I read the MPC7450
> reference manual and see that the L3 cache operates similarly to the
> L2. The main difference between those caches is that L3 uses an
> external SRAM memory while L2 is a pure on-chip cache.
Yeah but it isn't involved in any prefetching AFAIK. Anyway,
moot point, since we really should do the recommended flush
algorithm (esp. since we clearly do not sufficiently understand
the details of the L3 operation!)
Segher
^ permalink raw reply
* Re: ARCH=ppc or ARCH=powerpc
From: Erik Christiansen @ 2007-06-28 7:44 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <2DD9CF30-5127-4EC1-8D8E-BC6552A832AE@kernel.crashing.org>
On Wed, Jun 27, 2007 at 08:20:28PM -0500, Kumar Gala wrote:
> On Jun 27, 2007, at 4:41 PM, Bizhan Gholikhamseh ((bgholikh)) wrote:
> > Here are my questions:
> > 1- Should I use ARCH=ppc or ARCH=powerpc to build the kernel?
>
> Move to ARCH=powerpc.
Would that advice be specific to the MPC8541E?
Encountering a kernel build error with ARCH=ppc, after configuring as much as
possible for MPC8248, I've just tried ARCH=powerpc on linux-2.6.21.5, with this
slightly scary result:
>>>
There is no help available for this kernel option.
Symbol: EMBEDDED6xx [=n]
Prompt: Embedded 6xx/7xx/7xxx-based board
Defined at arch/powerpc/Kconfig:384
Depends on: <choice> && PPC32 && (BROKEN || BROKEN_ON_SMP)
Location:
-> Platform support
-> Machine type (<choice> [=y])
<<<
(Note: MPC8248 fits in the 6xx group, architecturally, AFAICT.)
At least I can apply a patch (missing from current kernels), to
fix the immediate MPC8248 problem in ARCH=ppc.
For my case then, ARCH=ppc seems to offer more promise.
Erik
(At this early stage, trying to figure which way is up. :-)
^ permalink raw reply
* Re: for-2.6.23 branch in powerpc.git created
From: Zang Roy-r61911 @ 2007-06-28 6:55 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev list
In-Reply-To: <18034.6787.951861.623265@cargo.ozlabs.ibm.com>
On Fri, 2007-06-15 at 12:50, Paul Mackerras wrote:
> I have created a for-2.6.23 branch in the powerpc.git repository
> (git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git)
> where I have started queueing up patches to go in once the 2.6.23
> merge window opens. For now at least it's the same as the master
> branch.
>
> The patches I put in are listed below. If you have a patch that
> should go in but isn't listed, remind me about it.
>
Paul,
These patches should go in 2.6.23.
1 add cuboot for 7448hpc2 board
http://ozlabs.org/pipermail/linuxppc-dev/2007-May/036834.html
2. Remove redundant pci_read_irq_line() function for 85xx platform
Acked by Ben
http://ozlabs.org/pipermail/linuxppc-dev/2007-June/037117.html
3. Fix e500 v2 core reboot bug
http://ozlabs.org/pipermail/linuxppc-dev/2007-June/037799.html
4. Document the global utilities node define and example
http://ozlabs.org/pipermail/linuxppc-dev/2007-June/038136.html
http://ozlabs.org/pipermail/linuxppc-dev/2007-June/038137.html
Roy
^ permalink raw reply
* RE: [PATCH 3/5 v2] Add the platform device support with RapidIO to MPC8641HPCN platform.
From: Zhang Wei-r63237 @ 2007-06-28 6:42 UTC (permalink / raw)
To: Arnd Bergmann, linuxppc-dev; +Cc: paulus, linux-kernel
In-Reply-To: <200706272256.16418.arnd@arndb.de>
Hi, Arnd,
>=20
> On Wednesday 27 June 2007, Zhang Wei wrote:
> > +static struct of_device_id mpc86xx_of_ids[] =3D {
> > +=A0=A0=A0=A0=A0=A0=A0{ .type =3D "soc", },
> > +=A0=A0=A0=A0=A0=A0=A0{ .compatible =3D "fsl,rapidio-delta", },
> > +=A0=A0=A0=A0=A0=A0=A0{},
> > +};
> > +
> > +static __init int mpc86xx_of_device_init(void)
> > +{
> > +=A0=A0=A0=A0=A0=A0=A0return of_platform_bus_probe(NULL, =
mpc86xx_of_ids, NULL);
> > +}
>=20
> This will add any devices below the "fsl,rapidio-delta" device
> as an of_device. Is that what you actually want? I would guess that
> you want to add the bridge itself, not the devices below it.
>=20
> Is the rapidio device at the root of the device tree, and if so, why
> not under the soc bus?
>=20
RapidIO is rather a bus that a device although these is no other nodes =
defined in its sector now.
Thanks!
Wei.
^ permalink raw reply
* Re: for-2.6.23 branch in powerpc.git created
From: Paul Mackerras @ 2007-06-28 6:35 UTC (permalink / raw)
To: Guennadi Liakhovetski; +Cc: linuxppc-dev
In-Reply-To: <Pine.LNX.4.60.0706151915580.5979@poirot.grange>
Guennadi Liakhovetski writes:
> These two i2c patches:
>
> http://ozlabs.org/pipermail/linuxppc-dev/2007-June/037327.html
> http://ozlabs.org/pipermail/linuxppc-dev/2007-June/037328.html
>
> also would be nice to get in, although, they only make sense with an ack
> from Scott Wood and another patch from him, as explained in links above...
Looks OK, but the first of those two patches doesn't have a
Signed-off-by: line, and the description is not suitable.
Please repost that patch with a nice description that describes what
the patch does and why, without references to other web pages. You
don't need to describe what is different from previous patches or who
suggested those changes.
Paul.
^ permalink raw reply
* In booting-without-of.txt, clarify that properties must precede subnodes
From: David Gibson @ 2007-06-28 5:56 UTC (permalink / raw)
To: Paul Mackerras, Benjamin Herrenschmidt; +Cc: linuxppc-dev
A strict reading of the flattened device tree format defined in
booting-without-of.txt does in fact require that all the tags defining
properties for a node go before any definitions of subnodes, however
it's not particularly emphasised. Although allowing intermingled
properties and subnodes would not be ambiguous in meaning, the kernel
parser does currently require that properties precede subnodes.
Furthermore, keeping this constraint makes life easier for various
device tree scanning tools.
Therefore, re-emphasise in booting-without-of.txt that this is a
strict requirement of the flattened device tree format.
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-06-28 15:47:47.000000000 +1000
+++ working-2.6/Documentation/powerpc/booting-without-of.txt 2007-06-28 15:51:56.000000000 +1000
@@ -626,6 +626,14 @@
a list of properties, a list of child nodes, and an end token. Every
child node is a full node structure itself as defined above.
+NOTE: The above definition requires that all property definitions for
+a particular node MUST precede any subnode definitions for that node.
+Although the structure would not be ambiguous if properties and
+subnodes were intermingled, the kernel parser requires that the
+properties come first (up until at least 2.6.22). Any tools
+manipulating a flattened tree must take care to preserve this
+constraint.
+
4) Device tree "strings" block
In order to save space, property names, which are generally redundant,
--
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
* Problem in configuring interrupt in PPC 8272 processor using montavista linux 2.6 kernel
From: Misbah khan @ 2007-06-28 5:52 UTC (permalink / raw)
To: linuxppc-embedded
Hi All
I am facing problem in configuring PPC 8272 processor for interrupt . The
zeroth bit of SIUMCR register when set with 1 will be configured for IRQ3
else will be configured with BBD. Even though i am writing 1 to this bit
while inserting the driver and its actually writing 1 to that location
either , but the IRQ3 is not been configured for that and hence is
configured for BBD (BBD and IRQ3 are multiplexed) the result is that the bus
is toggling . As a consiguence of this my driver is getting infinite
interrupt and it is going to deadlock .
If you have an experience of such problem ,i wish you could suggest me .
Hoping for a reply , for that i shall rema in thankful to you .
regard
Misbah
--
View this message in context: http://www.nabble.com/Problem-in-configuring-interrupt-in-PPC-8272-processor-using-montavista-linux-2.6-kernel-tf3992552.html#a11337419
Sent from the linuxppc-embedded mailing list archive at Nabble.com.
^ permalink raw reply
* Re: ARCH=ppc or ARCH=powerpc
From: Bhupender Saharan @ 2007-06-28 2:30 UTC (permalink / raw)
To: Bizhan Gholikhamseh (bgholikh); +Cc: linuxppc-embedded
In-Reply-To: <F795765B112E7344AF36AA911279641502D1A42C@xmb-sjc-212.amer.cisco.com>
[-- Attachment #1: Type: text/plain, Size: 1301 bytes --]
Hi,
All the new development is happening in arch/powerpc architecure. So it is
good to use this architecure if you are upgrading the kernel. But it might
not work with kernel 1.1.2, As arch/powerpc need a structure like open
firmware for the parameters.
If you want to stick to 1.1.2 u-boot version then you shall use arch/ppc
architecure.
Regards
Bhupi
On 6/27/07, Bizhan Gholikhamseh (bgholikh) <bgholikh@cisco.com> wrote:
>
> Hi All,
> Sorry for asking this question again, I am still not clear on some of the
> issues.
> Background:
> We have developed a custom board based on Freescale reference board:
> MPC8555_CDS with MPC8541E processor running Linux 2.6.11 and uboot 1.1.2version.
>
> I would like to update the Linux kernel to the latest available kernel
> 2.6.21.
> Here are my questions:
> 1- Should I use ARCH=ppc or ARCH=powerpc to build the kernel?
> 2- I have seen similar filenames under arch/ppc and arch/powerpc, which
> one applies to MPC8541E?
> 3- Once I build the kernel, could I load the kernel with uboot version
> 1.1.2 or not? if not what I should do?
>
> Many thanks in advance,
> Bizhan
>
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
[-- Attachment #2: Type: text/html, Size: 2712 bytes --]
^ permalink raw reply
* Re: [PATCH 4/8] [POWERPC] Use global_number in ppc32 pci_controller
From: David Gibson @ 2007-06-28 2:13 UTC (permalink / raw)
To: Kumar Gala; +Cc: Stephen Rothwell, linuxppc-dev
In-Reply-To: <A5AD5E4E-BDDD-4B23-A70E-60F7891502A0@kernel.crashing.org>
On Wed, Jun 27, 2007 at 09:09:36PM -0500, Kumar Gala wrote:
>
> On Jun 27, 2007, at 7:14 PM, Stephen Rothwell wrote:
>
> > Hi Kumar,
> >
> > All this stuff looks good, thanks.
> >
> > On Wed, 27 Jun 2007 13:19:14 -0500 Kumar Gala
> > <galak@kernel.crashing.org> wrote:
> >>
> >> diff --git a/arch/powerpc/kernel/pci-common.c b/arch/powerpc/
> >> kernel/pci-common.c
> >> new file mode 100644
> >> index 0000000..3ca8cfb
> >> --- /dev/null
> >> +++ b/arch/powerpc/kernel/pci-common.c
> >> @@ -0,0 +1,53 @@
> >> +/*
> >> + * Contains common pci routines for ALL ppc platform
> >> + *
> >> + * This program is free software; you can redistribute it and/or
> >> + * modify it under the terms of the GNU General Public License
> >> + * as published by the Free Software Foundation; either version
> >> + * 2 of the License, or (at your option) any later version.
> >> + */
> >
> > This needs some copyright notice presumably based on the code you are
> > moving to here.
>
> Will do. The ppc32 doesn't have anything. The only copyright is on
> the ppc64 code for Anton. Not really sure how to deal with 'Port for
> PPC64 David Engebretsen, IBM Corp.' Suggestions?
I tend to just copy such copyrights-that-aren't-copyrights verbatim.
--
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 4/8] [POWERPC] Use global_number in ppc32 pci_controller
From: Kumar Gala @ 2007-06-28 2:09 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linuxppc-dev
In-Reply-To: <20070628101401.6790aafd.sfr@canb.auug.org.au>
On Jun 27, 2007, at 7:14 PM, Stephen Rothwell wrote:
> Hi Kumar,
>
> All this stuff looks good, thanks.
>
> On Wed, 27 Jun 2007 13:19:14 -0500 Kumar Gala
> <galak@kernel.crashing.org> wrote:
>>
>> diff --git a/arch/powerpc/kernel/pci-common.c b/arch/powerpc/
>> kernel/pci-common.c
>> new file mode 100644
>> index 0000000..3ca8cfb
>> --- /dev/null
>> +++ b/arch/powerpc/kernel/pci-common.c
>> @@ -0,0 +1,53 @@
>> +/*
>> + * Contains common pci routines for ALL ppc platform
>> + *
>> + * This program is free software; you can redistribute it and/or
>> + * modify it under the terms of the GNU General Public License
>> + * as published by the Free Software Foundation; either version
>> + * 2 of the License, or (at your option) any later version.
>> + */
>
> This needs some copyright notice presumably based on the code you are
> moving to here.
Will do. The ppc32 doesn't have anything. The only copyright is on
the ppc64 code for Anton. Not really sure how to deal with 'Port for
PPC64 David Engebretsen, IBM Corp.' Suggestions?
- k
^ permalink raw reply
* dtc: Remove bogus break statement
From: David Gibson @ 2007-06-28 1:32 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev, 5B
Commit 0738774fcc34b78a708a127fb4b2f193d08c94ba introduced some
incorrect indentation / bracketing in unflatten_tree(). By luck, the
extra break statement intended to be within an if block, but actually
afterwards has no semantic effect. Still, this patch gets rid of it
for cleanliness.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Index: dtc/flattree.c
===================================================================
--- dtc.orig/flattree.c 2007-06-26 15:28:34.000000000 +1000
+++ dtc/flattree.c 2007-06-26 15:28:52.000000000 +1000
@@ -779,7 +779,6 @@ static struct node *unflatten_tree(struc
if (!(flags & FTF_NOPS))
fprintf(stderr, "Warning: NOP tag found in flat tree"
" version <16\n");
- break;
/* Ignore */
break;
--
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
* Disable old EMAC driver in arch/powerpc
From: David Gibson @ 2007-06-28 1:27 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
The EMAC driver, in drivers/net/ibm_emac, for the embedded Ethernet
MAC found in PowerPC 4xx embedded chips is not suitable for
arch/powerpc. It will not build because it relies on the old arch/ppc
OCP mechanism. BenH has a new, device-tree aware version of the
driver which will work in arch/powerpc, but until it's merged, this
patch will disable the old, non-building version.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Index: working-2.6/drivers/net/Kconfig
===================================================================
--- working-2.6.orig/drivers/net/Kconfig 2007-06-28 11:16:31.000000000 +1000
+++ working-2.6/drivers/net/Kconfig 2007-06-28 11:16:37.000000000 +1000
@@ -1187,7 +1187,7 @@
config IBM_EMAC
tristate "PowerPC 4xx on-chip Ethernet support"
- depends on 4xx
+ depends on 4xx && !PPC_MERGE
help
This driver supports the PowerPC 4xx EMAC family of on-chip
Ethernet controllers.
--
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: ARCH=ppc or ARCH=powerpc
From: Kumar Gala @ 2007-06-28 1:20 UTC (permalink / raw)
To: Bizhan Gholikhamseh; +Cc: linuxppc-embedded
In-Reply-To: <F795765B112E7344AF36AA911279641502D1A42C@xmb-sjc-212.amer.cisco.com>
On Jun 27, 2007, at 4:41 PM, Bizhan Gholikhamseh ((bgholikh)) wrote:
> Hi All,
> Sorry for asking this question again, I am still not clear on some
> of the issues.
> Background:
> We have developed a custom board based on Freescale reference
> board: MPC8555_CDS with MPC8541E processor running Linux 2.6.11 and
> uboot 1.1.2 version.
>
> I would like to update the Linux kernel to the latest available
> kernel 2.6.21.
> Here are my questions:
> 1- Should I use ARCH=ppc or ARCH=powerpc to build the kernel?
Move to ARCH=powerpc.
> 2- I have seen similar filenames under arch/ppc and arch/powerpc,
> which one applies to MPC8541E?
There is support for MPC8541e in both arch/ppc & arch/powerpc.
> 3- Once I build the kernel, could I load the kernel with uboot
> version 1.1.2 or not? if not what I should do?
I can't remember if u-boot 1.1.2 had support for the device tree or
not. If not you can use the cuImage target in arch/powerpc and use
your existing u-boot. (or upgrade u-boot)
- k
^ permalink raw reply
* Re: ARCH=ppc or ARCH=powerpc
From: Kumar Gala @ 2007-06-28 1:14 UTC (permalink / raw)
To: Josh Boyer; +Cc: Matt Porter, linuxppc-embedded
In-Reply-To: <1158362585.2622.27.camel@vader.jdub.homelinux.org>
On Sep 15, 2006, at 6:23 PM, Josh Boyer wrote:
> On Fri, 2006-09-15 at 16:06 -0700, Shawn Jin wrote:
>> Hi Matt,
>>
>>> The goal is to have the new 4xx arch/powerpc support not break 4xx
>>> arch/ppc support. So as boards are merged and verified working,
>>> we'll remove the equivalent support from arch/ppc...
>>>
>>> Some boards/chips may just die if no maintainer step up to port
>>> them over...but all the important stuff should get an interested
>>> party once we get the initial 4xx support in arch/powerpc working.
>>
>> When can we expect this done? I have a 440 based SoC project ongoing
>> and am thinking when I should start moving to arch/powerpc.
>
> There is no set date or kernel release where this will be done. In
> other words "when it gets done, it gets done". :)
There is some push for putting a date one year from now as when arch/
ppc will go away.
- k
^ permalink raw reply
* Re: [PATCH 3/3] First cut at PReP support for arch/powerpc
From: David Gibson @ 2007-06-28 0:38 UTC (permalink / raw)
To: Milton Miller; +Cc: ppcdev
In-Reply-To: <d8960a6c86859c19b84dc9fd41446fbd@bga.com>
On Wed, Jun 27, 2007 at 06:22:27AM -0500, Milton Miller wrote:
> On Wed Jun 27 17:10:08 EST 2007, David Gibson wrote:
> > Here is an implementation to allow PReP systems to boot under the
> > arch/powerpc codebase, one of the few remaining platforms supported in
> > arch/ppc but not so far in arch/powerpc.
> >
> > This support is still fairly incomplete - it needs to obtain a lot
> > more device information from the residual data and put it into the
> > device tree, rather than relying on hardcoded values (both in the code
> > and in prep.dts). Likewise many peripherals will not be supported -
> > in particular the RTC is not yet supported, so the time will generally
> > be wrong.
>
>
> Hi David.
>
> A few things I noticed:
>
> (1) Your cleaned up mkprep.c seems to always put on a floppy header,
> where as before that was optional with the -php flag. Is that header
> right for a hard disk partition? Or would that just have the 1-sector
> header?
Well, the arch/ppc code always invokes mkprep with the -php option to
make the zImage.prep. That's what I was basing my change on..
> The comments in the old mkprep impiled the raw elf contents
> are used for netboot. What if the zImage does't fit on the 1.44MB disk
> given in the header?
Um... dunno.
> (2) Uour wrapper rule can leave behind zImage.dts.prep.elf, but there
> is no clean rule for that
Hrm, yes. And this is true for a number of intermediares that the
wrapper can make. Fix later...
> (3) Is this the right platform to create the device tree from scratch
> by traversing fw data? A significiant number of the properties are to
> be filled in or say IBM, which is incorrect.
Maybe, I'm certainly considering it. For a first cut tweaking a fixed
tree was easier, but by the time we read all the information from the
residual data that we ought to, we may well be more-or-less making a
tree from scratch.
I'm hoping to merge libfdt into the kernel tree before attempting this
path, though.
> (4) Adding a 5th udbg_putc method that calls a byte read to
> udbg_comport->lsr masked with THRE until 0 and performs a byte write to
> ->thr shows we have the wrong abstraction. Please make the inb/outb a
> method with the comport. It would seem the actual init_xx could be in
> the platforms, passing inb, outb, and comport to a helper in
> udbg_16550.c. I'm fine with declaring all the early inits in udbg.h
Hrm.. I'm not entirely convinced. The duplication of the serial
polling stuff is duplication, certainly, but it's not that complex a
bit of code: I'm not sure it's worth inventing a second level of
indirection in the udbg stuff to get rid of it. We'd still need the
putc/getc callbacks, to deal with non-8250 like debug methods
(e.g. OF, HV).
> (5) the printk PReP architecture is in the middle of prep_find_bridges?
Huh..? I have no idea what you mean.
> (6) #if 0 prep_request_io will need platform check
If it stays. I'm pretty unconvinced we need it at all - if we
actually need to use those devices, they can have their own entries in
the device tree and of_platform drivers which can do the
OF_request_ranges thing.
> (7) do you expect both the kernel and the boot code will continue to
> need residual.h? If so, can we have the boot dir make a copy like the
> zlib headers? Or is this only temporary, the kernel only needs a copy
> of the raw blob to export to userspace in the same spot and the
> include/asm-powerpc copy will go away?
For now, only the boot code needs it, and I'm hoping it can be kept
that way. Anything the kernel proper needs from the residual should
probably be copied to a relevant place in the device tree.
--
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 v2] Add the explanation and a sample of RapidIO DTS sector to the document of booting-without-of.txt file.
From: David Gibson @ 2007-06-28 0:24 UTC (permalink / raw)
To: Zhang Wei; +Cc: linuxppc-dev, paulus, linux-kernel
In-Reply-To: <11829333481977-git-send-email-wei.zhang@freescale.com>
On Wed, Jun 27, 2007 at 04:35:44PM +0800, Zhang Wei wrote:
> Add the explanation and a sample of RapidIO DTS sector to the document of booting-without-of.txt file.
>
> Signed-off-by: Zhang Wei <wei.zhang@freescale.com>
> ---
> Documentation/powerpc/booting-without-of.txt | 34 ++++++++++++++++++++++++++
> 1 files changed, 34 insertions(+), 0 deletions(-)
>
> diff --git a/Documentation/powerpc/booting-without-of.txt b/Documentation/powerpc/booting-without-of.txt
> index b49ce16..98692ca 100644
> --- a/Documentation/powerpc/booting-without-of.txt
> +++ b/Documentation/powerpc/booting-without-of.txt
> @@ -1727,6 +1727,40 @@ platforms are moved over to use the flattened-device-tree model.
> partition-names = "fs\0firmware";
> };
>
> + k) RapidIO
> +
> + Required properties:
> +
Should probably recommend a name for the node here, as well. "srio" I
guess, from the example below.
> + - compatible : Should be "fsl,rapidio-delta" for Freescale
> + PowerPC RapidIO controller.
> + - #address-cells : Address representation for "rapidio" devices.
> + This field represents the number of cells needed to represent
> + the RapidIO address of the registers. For supporting more than
> + 32-bits RapidIO address, this field should be <2>.
> + See 1) above for more details on defining #address-cells.
> + - reg : Offset and length of the register set for the device
> + - ranges : Should be defined as specified in 1) to describe the
> + translation of addresses for memory mapped RapidIO memory
> + space.
> + - interrupts : binding interrupts for this device sector,
> + please follow below orders:
> + <err_irq bell_outb_irq bell_inb_irq msg1_tx_irq msg1_rx_irq
> + msg2_tx_irq msg2_rx_irq ... msgN_tx_irq msgN_rx_irq>.
> +
> + Example:
> +
> + srio@c0000{
> + compatible = "fsl,rapidio-delta";
> + #address-cells = <2>;
> + #size-cells = <2>;
> + reg = <c0000 20000>;
> + ranges = <0 0 c0000000 20000000>;
> + interrupt-parent = <&mpic>;
> + /* err_irq bell_outb_irq bell_inb_irq msg1_tx_irq msg1_rx_irq
> + msg2_tx_irq msg2_rx_irq */
> + interrupts = <30 2 31 2 32 2 35 2 36 2 37 2 38 2>;
> + };
> +
> More devices will be defined as this spec matures.
>
> VII - Specifying interrupt information for devices
--
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 09/15] [POWERPC] 86xx: Add uli1575 pci-bridge sector to MPC8641HPCN dts file.
From: David Gibson @ 2007-06-28 0:23 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev
In-Reply-To: <8fa84ed4810eb9aca18739bf709e71d9@kernel.crashing.org>
On Wed, Jun 27, 2007 at 10:39:14PM +0200, Segher Boessenkool wrote:
> >> - ranges = <0 f8000000 00100000>;
> >> - reg = <f8000000 00100000>; // CCSRBAR 1M
> >> + ranges = <00001000 f8001000 000ff000
> > [...]
> >> + reg = <f8000000 00001000>; // CCSRBAR
> >
> > This can't be right, and I suspect it will break any kernel access to
> > the first 0x1000 bytes of the CCSR_BAR space. reg should actually
> > describe the register space of the SOC. If ranges needs to specify
> > that, too, they should be able to be redundant. But this looks like
> > a big hack, to me. Am I missing something?
>
> "reg" and "ranges" can never overlap really.
Is this really true, always?
What about something like a PReP PCI bridge, which has the registers
for indirect config-space access in the same range as the ISA IO
space?
--
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 4/8] [POWERPC] Use global_number in ppc32 pci_controller
From: Stephen Rothwell @ 2007-06-28 0:14 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <11829683663762-git-send-email-galak@kernel.crashing.org>
Hi Kumar,
All this stuff looks good, thanks.
On Wed, 27 Jun 2007 13:19:14 -0500 Kumar Gala <galak@kernel.crashing.org> wrote:
>
> diff --git a/arch/powerpc/kernel/pci-common.c b/arch/powerpc/kernel/pci-common.c
> new file mode 100644
> index 0000000..3ca8cfb
> --- /dev/null
> +++ b/arch/powerpc/kernel/pci-common.c
> @@ -0,0 +1,53 @@
> +/*
> + * Contains common pci routines for ALL ppc platform
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License
> + * as published by the Free Software Foundation; either version
> + * 2 of the License, or (at your option) any later version.
> + */
This needs some copyright notice presumably based on the code you are
moving to here.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
^ permalink raw reply
* Re: mm snapshot broken-out-2007-06-27-03-28.tar.gz uploaded
From: Andrew Morton @ 2007-06-27 23:09 UTC (permalink / raw)
To: Mariusz Kozlowski; +Cc: linuxppc-dev, paulus, linux-kernel, Adrian Bunk
In-Reply-To: <200706280057.07481.m.kozlowski@tuxland.pl>
On Thu, 28 Jun 2007 00:57:07 +0200
Mariusz Kozlowski <m.kozlowski@tuxland.pl> wrote:
> Hello,
>
> Build problems on iMac G3.
>
> 1) allnoconfig results in this:
>
> CC arch/powerpc/mm/tlb_32.o
> In file included from include/asm/tlb.h:60,
> from arch/powerpc/mm/tlb_32.c:30:
> include/asm-generic/tlb.h: In function 'tlb_flush_mmu':
> include/asm-generic/tlb.h:76: error: implicit declaration of function 'release_pages'
> include/asm-generic/tlb.h: In function 'tlb_remove_page':
> include/asm-generic/tlb.h:105: error: implicit declaration of function 'page_cache_release'
> make[1]: *** [arch/powerpc/mm/tlb_32.o] Blad 1
> make: *** [arch/powerpc/mm] Blad 2
>
>
> The patch below fixes that for me.
>
> Signed-off-by: Mariusz Kozlowski <m.kozlowski@tuxland.pl>
>
> arch/powerpc/mm/tlb_32.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> --- linux-2.6.22-rc6-bo-a/arch/powerpc/mm/tlb_32.c 2007-06-27 23:38:49.000000000 +0200
> +++ linux-2.6.22-rc6-bo-b/arch/powerpc/mm/tlb_32.c 2007-06-27 23:18:05.000000000 +0200
> @@ -26,6 +26,8 @@
> #include <linux/mm.h>
> #include <linux/init.h>
> #include <linux/highmem.h>
> +#include <linux/pagemap.h>
> +
> #include <asm/tlbflush.h>
> #include <asm/tlb.h>
OK.
>
>
> 2) These are conflicts introduced by kernel-sys_nic-should-include-linux-syscallsh.patch
>
> CC kernel/sys_ni.o
> kernel/sys_ni.c:16: error: conflicting types for 'sys_nfsservctl'
> include/linux/syscalls.h:497: error: previous declaration of 'sys_nfsservctl' was here
> kernel/sys_ni.c:17: error: conflicting types for 'sys_quotactl'
erk, I suspect that's unfixable, or not worth fixing.
^ permalink raw reply
* Re: mm snapshot broken-out-2007-06-27-03-28.tar.gz uploaded
From: Mariusz Kozlowski @ 2007-06-27 22:57 UTC (permalink / raw)
To: akpm, Adrian Bunk; +Cc: linuxppc-dev, paulus, linux-kernel
In-Reply-To: <200706271030.l5RAUgKE015163@imap1.linux-foundation.org>
Hello,
Build problems on iMac G3.
1) allnoconfig results in this:
CC arch/powerpc/mm/tlb_32.o
In file included from include/asm/tlb.h:60,
from arch/powerpc/mm/tlb_32.c:30:
include/asm-generic/tlb.h: In function 'tlb_flush_mmu':
include/asm-generic/tlb.h:76: error: implicit declaration of function 'release_pages'
include/asm-generic/tlb.h: In function 'tlb_remove_page':
include/asm-generic/tlb.h:105: error: implicit declaration of function 'page_cache_release'
make[1]: *** [arch/powerpc/mm/tlb_32.o] Blad 1
make: *** [arch/powerpc/mm] Blad 2
The patch below fixes that for me.
Signed-off-by: Mariusz Kozlowski <m.kozlowski@tuxland.pl>
arch/powerpc/mm/tlb_32.c | 2 ++
1 file changed, 2 insertions(+)
--- linux-2.6.22-rc6-bo-a/arch/powerpc/mm/tlb_32.c 2007-06-27 23:38:49.000000000 +0200
+++ linux-2.6.22-rc6-bo-b/arch/powerpc/mm/tlb_32.c 2007-06-27 23:18:05.000000000 +0200
@@ -26,6 +26,8 @@
#include <linux/mm.h>
#include <linux/init.h>
#include <linux/highmem.h>
+#include <linux/pagemap.h>
+
#include <asm/tlbflush.h>
#include <asm/tlb.h>
2) These are conflicts introduced by kernel-sys_nic-should-include-linux-syscallsh.patch
CC kernel/sys_ni.o
kernel/sys_ni.c:16: error: conflicting types for 'sys_nfsservctl'
include/linux/syscalls.h:497: error: previous declaration of 'sys_nfsservctl' was here
kernel/sys_ni.c:17: error: conflicting types for 'sys_quotactl'
include/linux/syscalls.h:396: error: previous declaration of 'sys_quotactl' was here
kernel/sys_ni.c:18: error: conflicting types for 'sys_acct'
include/linux/syscalls.h:107: error: previous declaration of 'sys_acct' was here
kernel/sys_ni.c:19: error: conflicting types for 'sys_lookup_dcookie'
include/linux/syscalls.h:394: error: previous declaration of 'sys_lookup_dcookie' was here
kernel/sys_ni.c:20: error: conflicting types for 'sys_swapon'
include/linux/syscalls.h:489: error: previous declaration of 'sys_swapon' was here
kernel/sys_ni.c:21: error: conflicting types for 'sys_swapoff'
include/linux/syscalls.h:490: error: previous declaration of 'sys_swapoff' was here
kernel/sys_ni.c:22: error: conflicting types for 'sys_kexec_load'
include/linux/syscalls.h:167: error: previous declaration of 'sys_kexec_load' was here
kernel/sys_ni.c:24: error: conflicting types for 'sys_init_module'
include/linux/syscalls.h:183: error: previous declaration of 'sys_init_module' was here
kernel/sys_ni.c:25: error: conflicting types for 'sys_delete_module'
include/linux/syscalls.h:185: error: previous declaration of 'sys_delete_module' was here
kernel/sys_ni.c:26: error: conflicting types for 'sys_socketpair'
include/linux/syscalls.h:422: error: previous declaration of 'sys_socketpair' was here
kernel/sys_ni.c:27: error: conflicting types for 'sys_bind'
include/linux/syscalls.h:408: error: previous declaration of 'sys_bind' was here
kernel/sys_ni.c:28: error: conflicting types for 'sys_listen'
include/linux/syscalls.h:424: error: previous declaration of 'sys_listen' was here
kernel/sys_ni.c:29: error: conflicting types for 'sys_accept'
include/linux/syscalls.h:410: error: previous declaration of 'sys_accept' was here
kernel/sys_ni.c:30: error: conflicting types for 'sys_connect'
include/linux/syscalls.h:409: error: previous declaration of 'sys_connect' was here
kernel/sys_ni.c:31: error: conflicting types for 'sys_getsockname'
include/linux/syscalls.h:411: error: previous declaration of 'sys_getsockname' was here
kernel/sys_ni.c:32: error: conflicting types for 'sys_getpeername'
include/linux/syscalls.h:412: error: previous declaration of 'sys_getpeername' was here
kernel/sys_ni.c:33: error: conflicting types for 'sys_sendto'
include/linux/syscalls.h:415: error: previous declaration of 'sys_sendto' was here
kernel/sys_ni.c:34: error: conflicting types for 'sys_send'
include/linux/syscalls.h:413: error: previous declaration of 'sys_send' was here
kernel/sys_ni.c:35: error: conflicting types for 'sys_recvfrom'
include/linux/syscalls.h:419: error: previous declaration of 'sys_recvfrom' was here
kernel/sys_ni.c:36: error: conflicting types for 'sys_recv'
include/linux/syscalls.h:417: error: previous declaration of 'sys_recv' was here
kernel/sys_ni.c:37: error: conflicting types for 'sys_socket'
include/linux/syscalls.h:421: error: previous declaration of 'sys_socket' was here
kernel/sys_ni.c:38: error: conflicting types for 'sys_setsockopt'
include/linux/syscalls.h:405: error: previous declaration of 'sys_setsockopt' was here
kernel/sys_ni.c:39: error: conflicting types for 'sys_getsockopt'
include/linux/syscalls.h:407: error: previous declaration of 'sys_getsockopt' was here
kernel/sys_ni.c:40: error: conflicting types for 'sys_shutdown'
include/linux/syscalls.h:161: error: previous declaration of 'sys_shutdown' was here
kernel/sys_ni.c:41: error: conflicting types for 'sys_sendmsg'
include/linux/syscalls.h:416: error: previous declaration of 'sys_sendmsg' was here
kernel/sys_ni.c:42: error: conflicting types for 'sys_recvmsg'
include/linux/syscalls.h:420: error: previous declaration of 'sys_recvmsg' was here
kernel/sys_ni.c:43: error: conflicting types for 'sys_socketcall'
include/linux/syscalls.h:423: error: previous declaration of 'sys_socketcall' was here
kernel/sys_ni.c:44: error: conflicting types for 'sys_futex'
include/linux/syscalls.h:180: error: previous declaration of 'sys_futex' was here
kernel/sys_ni.c:46: error: conflicting types for 'sys_set_robust_list'
include/linux/syscalls.h:607: error: previous declaration of 'sys_set_robust_list' was here
kernel/sys_ni.c:48: error: conflicting types for 'sys_get_robust_list'
include/linux/syscalls.h:605: error: previous declaration of 'sys_get_robust_list' was here
kernel/sys_ni.c:50: error: conflicting types for 'sys_epoll_create'
include/linux/syscalls.h:429: error: previous declaration of 'sys_epoll_create' was here
kernel/sys_ni.c:51: error: conflicting types for 'sys_epoll_ctl'
include/linux/syscalls.h:431: error: previous declaration of 'sys_epoll_ctl' was here
kernel/sys_ni.c:52: error: conflicting types for 'sys_epoll_wait'
include/linux/syscalls.h:433: error: previous declaration of 'sys_epoll_wait' was here
kernel/sys_ni.c:53: error: conflicting types for 'sys_epoll_pwait'
include/linux/syscalls.h:437: error: previous declaration of 'sys_epoll_pwait' was here
kernel/sys_ni.c:54: error: conflicting types for 'sys_semget'
include/linux/syscalls.h:460: error: previous declaration of 'sys_semget' was here
kernel/sys_ni.c:55: error: conflicting types for 'sys_semop'
include/linux/syscalls.h:462: error: previous declaration of 'sys_semop' was here
kernel/sys_ni.c:56: error: conflicting types for 'sys_semtimedop'
include/linux/syscalls.h:466: error: previous declaration of 'sys_semtimedop' was here
kernel/sys_ni.c:57: error: conflicting types for 'sys_semctl'
include/linux/syscalls.h:463: error: previous declaration of 'sys_semctl' was here
kernel/sys_ni.c:58: error: conflicting types for 'sys_msgget'
include/linux/syscalls.h:453: error: previous declaration of 'sys_msgget' was here
kernel/sys_ni.c:59: error: conflicting types for 'sys_msgsnd'
include/linux/syscalls.h:455: error: previous declaration of 'sys_msgsnd' was here
kernel/sys_ni.c:60: error: conflicting types for 'sys_msgrcv'
include/linux/syscalls.h:457: error: previous declaration of 'sys_msgrcv' was here
kernel/sys_ni.c:61: error: conflicting types for 'sys_msgctl'
include/linux/syscalls.h:458: error: previous declaration of 'sys_msgctl' was here
kernel/sys_ni.c:62: error: conflicting types for 'sys_shmget'
include/linux/syscalls.h:468: error: previous declaration of 'sys_shmget' was here
kernel/sys_ni.c:63: error: conflicting types for 'sys_shmat'
include/linux/syscalls.h:467: error: previous declaration of 'sys_shmat' was here
kernel/sys_ni.c:64: error: conflicting types for 'sys_shmdt'
include/linux/syscalls.h:469: error: previous declaration of 'sys_shmdt' was here
kernel/sys_ni.c:65: error: conflicting types for 'sys_shmctl'
include/linux/syscalls.h:470: error: previous declaration of 'sys_shmctl' was here
kernel/sys_ni.c:66: error: conflicting types for 'sys_mq_open'
include/linux/syscalls.h:472: error: previous declaration of 'sys_mq_open' was here
kernel/sys_ni.c:67: error: conflicting types for 'sys_mq_unlink'
include/linux/syscalls.h:473: error: previous declaration of 'sys_mq_unlink' was here
kernel/sys_ni.c:68: error: conflicting types for 'sys_mq_timedsend'
include/linux/syscalls.h:474: error: previous declaration of 'sys_mq_timedsend' was here
kernel/sys_ni.c:69: error: conflicting types for 'sys_mq_timedreceive'
include/linux/syscalls.h:475: error: previous declaration of 'sys_mq_timedreceive' was here
kernel/sys_ni.c:70: error: conflicting types for 'sys_mq_notify'
include/linux/syscalls.h:476: error: previous declaration of 'sys_mq_notify' was here
kernel/sys_ni.c:71: error: conflicting types for 'sys_mq_getsetattr'
include/linux/syscalls.h:477: error: previous declaration of 'sys_mq_getsetattr' was here
kernel/sys_ni.c:77: error: conflicting types for 'sys_mbind'
include/linux/syscalls.h:538: error: previous declaration of 'sys_mbind' was here
kernel/sys_ni.c:78: error: conflicting types for 'sys_get_mempolicy'
include/linux/syscalls.h:542: error: previous declaration of 'sys_get_mempolicy' was here
kernel/sys_ni.c:79: error: conflicting types for 'sys_set_mempolicy'
include/linux/syscalls.h:520: error: previous declaration of 'sys_set_mempolicy' was here
kernel/sys_ni.c:83: error: conflicting types for 'sys_add_key'
include/linux/syscalls.h:507: error: previous declaration of 'sys_add_key' was here
kernel/sys_ni.c:84: error: conflicting types for 'sys_request_key'
include/linux/syscalls.h:512: error: previous declaration of 'sys_request_key' was here
kernel/sys_ni.c:85: error: conflicting types for 'sys_keyctl'
include/linux/syscalls.h:515: error: previous declaration of 'sys_keyctl' was here
kernel/sys_ni.c:89: error: conflicting types for 'sys_inotify_add_watch'
include/linux/syscalls.h:546: error: previous declaration of 'sys_inotify_add_watch' was here
kernel/sys_ni.c:90: error: conflicting types for 'sys_inotify_rm_watch'
include/linux/syscalls.h:547: error: previous declaration of 'sys_inotify_rm_watch' was here
kernel/sys_ni.c:91: error: conflicting types for 'sys_migrate_pages'
include/linux/syscalls.h:523: error: previous declaration of 'sys_migrate_pages' was here
kernel/sys_ni.c:92: error: conflicting types for 'sys_move_pages'
include/linux/syscalls.h:528: error: previous declaration of 'sys_move_pages' was here
kernel/sys_ni.c:118: error: conflicting types for 'sys_pciconfig_read'
include/linux/syscalls.h:482: error: previous declaration of 'sys_pciconfig_read' was here
kernel/sys_ni.c:119: error: conflicting types for 'sys_pciconfig_write'
include/linux/syscalls.h:485: error: previous declaration of 'sys_pciconfig_write' was here
kernel/sys_ni.c:120: error: conflicting types for 'sys_pciconfig_iobase'
include/linux/syscalls.h:479: error: previous declaration of 'sys_pciconfig_iobase' was here
kernel/sys_ni.c:124: error: conflicting types for 'sys_spu_run'
include/linux/syscalls.h:550: error: previous declaration of 'sys_spu_run' was here
kernel/sys_ni.c:125: error: conflicting types for 'sys_spu_create'
include/linux/syscalls.h:552: error: previous declaration of 'sys_spu_create' was here
kernel/sys_ni.c:128: error: conflicting types for 'sys_mprotect'
include/linux/syscalls.h:267: error: previous declaration of 'sys_mprotect' was here
kernel/sys_ni.c:129: error: conflicting types for 'sys_msync'
include/linux/syscalls.h:274: error: previous declaration of 'sys_msync' was here
kernel/sys_ni.c:130: error: conflicting types for 'sys_mlock'
include/linux/syscalls.h:278: error: previous declaration of 'sys_mlock' was here
kernel/sys_ni.c:131: error: conflicting types for 'sys_munlock'
include/linux/syscalls.h:279: error: previous declaration of 'sys_munlock' was here
kernel/sys_ni.c:132: error: conflicting types for 'sys_mlockall'
include/linux/syscalls.h:280: error: previous declaration of 'sys_mlockall' was here
kernel/sys_ni.c:134: error: conflicting types for 'sys_mincore'
include/linux/syscalls.h:284: error: previous declaration of 'sys_mincore' was here
kernel/sys_ni.c:135: error: conflicting types for 'sys_madvise'
include/linux/syscalls.h:282: error: previous declaration of 'sys_madvise' was here
kernel/sys_ni.c:136: error: conflicting types for 'sys_mremap'
include/linux/syscalls.h:270: error: previous declaration of 'sys_mremap' was here
kernel/sys_ni.c:137: error: conflicting types for 'sys_remap_file_pages'
include/linux/syscalls.h:273: error: previous declaration of 'sys_remap_file_pages' was here
kernel/sys_ni.c:138: error: conflicting types for 'compat_sys_move_pages'
include/linux/syscalls.h:533: error: previous declaration of 'compat_sys_move_pages' was here
kernel/sys_ni.c:142: error: conflicting types for 'sys_bdflush'
include/linux/syscalls.h:206: error: previous declaration of 'sys_bdflush' was here
kernel/sys_ni.c:143: error: conflicting types for 'sys_ioprio_set'
include/linux/syscalls.h:517: error: previous declaration of 'sys_ioprio_set' was here
kernel/sys_ni.c:144: error: conflicting types for 'sys_ioprio_get'
include/linux/syscalls.h:518: error: previous declaration of 'sys_ioprio_get' was here
kernel/sys_ni.c:147: error: conflicting types for 'sys_signalfd'
include/linux/syscalls.h:609: error: previous declaration of 'sys_signalfd' was here
kernel/sys_ni.c:148: error: conflicting types for 'sys_timerfd'
include/linux/syscalls.h:611: error: previous declaration of 'sys_timerfd' was here
kernel/sys_ni.c:151: error: conflicting types for 'sys_eventfd'
include/linux/syscalls.h:612: error: previous declaration of 'sys_eventfd' was here
make[1]: *** [kernel/sys_ni.o] Blad 1
make: *** [kernel] Blad 2
^ permalink raw reply
* Re: [PATCH 09/15] [POWERPC] 86xx: Add uli1575 pci-bridge sector to MPC8641HPCN dts file.
From: Kumar Gala @ 2007-06-27 22:51 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev list
In-Reply-To: <17094a76430d6dd0df7aa07560b4e204@kernel.crashing.org>
On Jun 27, 2007, at 4:21 PM, Segher Boessenkool wrote:
>>>>>>> - ranges = <0 f8000000 00100000>;
>>>>>>> - reg = <f8000000 00100000>; // CCSRBAR 1M
>>>>>>> + ranges = <00001000 f8001000 000ff000
>>>>>>> + reg = <f8000000 00001000>; // CCSRBAR
>
>>> There is "BAR" in the name, so it is a movable range? Where
>>> is the base address set?
>>
>> in a MMIO register in the space itself.
>
> Oh, *great* design.</sarcasm>
its not that bad ;)
>>> What is the relationship between (in the example) the address
>>> ranges x'f800_0000+1000 and x'f800_1000+ff000?
>>
>> uugh, not sure what that's all about.
>
> Reading back I see that the CCSR region is 1MB, and only the
> first 4kB are for this PHB. What is the rest of this range
> used for -- devices on this PCI bus, other SoC devices, ...?
No, the first 4kB are SOC/platform level config registers (high level
window setup, CCSR location, etc).
The PHB registers are somewhere in the middle (0x8000, I think). All
the children devices (enet, PHBs, etc) live in the 1M block.
I think my original idea was the reg property on the SOC node was for
the first 4k block that held the SOC config registers. I think what
Wade did is correct since the reg property on the SOC node isnt going
to get translated through the ranges property and that they should be
mutually exclusive.
- k
^ permalink raw reply
* ARCH=ppc or ARCH=powerpc
From: Bizhan Gholikhamseh (bgholikh) @ 2007-06-27 21:41 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 681 bytes --]
Hi All,
Sorry for asking this question again, I am still not clear on some of
the issues.
Background:
We have developed a custom board based on Freescale reference board:
MPC8555_CDS with MPC8541E processor running Linux 2.6.11 and uboot 1.1.2
version.
I would like to update the Linux kernel to the latest available kernel
2.6.21.
Here are my questions:
1- Should I use ARCH=ppc or ARCH=powerpc to build the kernel?
2- I have seen similar filenames under arch/ppc and arch/powerpc, which
one applies to MPC8541E?
3- Once I build the kernel, could I load the kernel with uboot version
1.1.2 or not? if not what I should do?
Many thanks in advance,
Bizhan
[-- Attachment #2: Type: text/html, Size: 2092 bytes --]
^ permalink raw reply
* Re: [PATCH 09/15] [POWERPC] 86xx: Add uli1575 pci-bridge sector to MPC8641HPCN dts file.
From: Segher Boessenkool @ 2007-06-27 21:21 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev list
In-Reply-To: <EEF07F54-B6C2-4F27-A3F5-0824DD4826A0@kernel.crashing.org>
>>>>>> - ranges = <0 f8000000 00100000>;
>>>>>> - reg = <f8000000 00100000>; // CCSRBAR 1M
>>>>>> + ranges = <00001000 f8001000 000ff000
>>>>>> + reg = <f8000000 00001000>; // CCSRBAR
>> There is "BAR" in the name, so it is a movable range? Where
>> is the base address set?
>
> in a MMIO register in the space itself.
Oh, *great* design.</sarcasm>
>> What is the relationship between (in the example) the address
>> ranges x'f800_0000+1000 and x'f800_1000+ff000?
>
> uugh, not sure what that's all about.
Reading back I see that the CCSR region is 1MB, and only the
first 4kB are for this PHB. What is the rest of this range
used for -- devices on this PCI bus, other SoC devices, ...?
Segher
^ permalink raw reply
* Re: Porting Linux to Xilinx ML410
From: Thomas Glanzmann @ 2007-06-27 21:18 UTC (permalink / raw)
To: khollan; +Cc: linuxppc-embedded
In-Reply-To: <11328063.post@talk.nabble.com>
Hello,
> Linux/PPC load: console=ttyUL0,9600 root=/dev/xsysace/disc0/part3 rw
> Uncompressing Linux...done.
> Now booting the kernel
> It always stall on the Now booting the kernel. Im new to linux
> building and any help or suggestions are greatly appreciated.
I have the same problem on a Avnet Memev Virtex-4 FX12 LC Board. I typed
"stop" in the xmd and got an Instruction pointer. I took this
instruction pointer and called:
(thinkpad) [/scratch/tg/linux-2.6-ppc] powerpc-405-linux-gnu-objdump -dS vmlinux | less
/^c00045ac
c00045a0 <__delay>:
c00045a0: 2c 03 00 00 cmpwi r3,0
c00045a4: 7c 69 03 a6 mtctr r3
c00045a8: 4d 82 00 20 beqlr
c00045ac: 42 00 00 00 bdnz- c00045ac <__delay+0xc> <<<< HERE
c00045b0: 4e 80 00 20 blr
which is called from the calibrating delay loop. The calibrating delay
loop is an endless loop if the jiffies do not get incremented. Which is
the case if there are no timer ticks for whatever reason. Reasons could
be:
- PIT or FIT don't get initialized
- Interrupts are disabled
- No interrupt handler registerd or registered for the wrong iq.
However the calibrating delay loop is before the serial console
initialization code. The "Now booting the kernel" line comes from the in
kernel embedded bootloader just before it initalizes the MMU and jumps
to "start_kernel".
If you do any progress on that, please let me know. I am currently
extremly busy, so I don't have time at the moment to debug that any
further.
Thomas
^ 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