* Please pull from 'for-2.6.25' (updated)
From: Kumar Gala @ 2008-02-06 6:01 UTC (permalink / raw)
To: linuxppc-dev
Please pull from 'for-2.6.25' branch of
master.kernel.org:/pub/scm/linux/kernel/git/galak/powerpc.git for-2.6.25
to receive the following updates:
(Found a few patches I missed.)
arch/powerpc/boot/dts/adder875-redboot.dts | 1
arch/powerpc/boot/dts/adder875-uboot.dts | 1
arch/powerpc/boot/dts/mpc8313erdb.dts | 4
arch/powerpc/boot/dts/mpc8315erdb.dts | 2
arch/powerpc/boot/dts/mpc834x_mds.dts | 2
arch/powerpc/boot/dts/mpc8572ds.dts | 12
arch/powerpc/boot/dts/mpc885ads.dts | 1
arch/powerpc/boot/dts/storcenter.dts | 12
arch/powerpc/configs/mpc83xx_defconfig | 10
arch/powerpc/kernel/cputable.c | 10
arch/powerpc/kernel/pmc.c | 2
arch/powerpc/oprofile/Makefile | 2
arch/powerpc/oprofile/common.c | 6
arch/powerpc/oprofile/op_model_fsl_booke.c | 371 ------------------------
arch/powerpc/oprofile/op_model_fsl_emb.c | 369 +++++++++++++++++++++++
arch/powerpc/platforms/83xx/mpc832x_rdb.c | 2
arch/powerpc/platforms/83xx/mpc83xx.h | 2
arch/powerpc/platforms/83xx/usb.c | 17 -
arch/powerpc/platforms/8xx/adder875.c | 6
arch/powerpc/platforms/8xx/ep88xc.c | 1
arch/powerpc/platforms/Kconfig | 1
arch/powerpc/platforms/Kconfig.cputype | 4
arch/powerpc/platforms/embedded6xx/storcenter.c | 25 -
arch/powerpc/sysdev/fsl_soc.c | 2
arch/powerpc/sysdev/qe_lib/qe.c | 10
drivers/net/Kconfig | 4
drivers/net/cpmac.c | 55 +--
include/asm-powerpc/cputable.h | 2
include/asm-powerpc/oprofile_impl.h | 2
include/asm-powerpc/reg.h | 4
include/asm-powerpc/reg_booke.h | 62 ----
include/asm-powerpc/reg_fsl_emb.h | 72 ++++
32 files changed, 546 insertions(+), 530 deletions(-)
Andy Fleming (2):
[POWERPC] Made FSL Book-E PMC support more generic
[POWERPC} Add oprofile support for e300
Anton Vorontsov (2):
cpmac: convert to new Fixed PHY infrastructure
[POWERPC] qe_lib: fix few fluffy negligences
Bryan O'Donoghue (1):
[POWERPC] 8xx: Add clock-frequency to adder875 and mpc885ads dts
Jon Loeliger (1):
[POWERPC] Fix storcenter DTS typos, feedback, IRQs.
Kim Phillips (6):
[POWERPC] 83xx: configure USB clock for MPC8315E
[POWERPC] 83xx: Correct 2nd PCI controller interrupt value in mpc834x_mds dts
[POWERPC] 83xx: Add rtc node to mpc8313erdb dts
[POWERPC] 83xx: mpc832x_rdb: fix compiler warning
[POWERPC] FSL: fix mpc83xx_spi device registration
[POWERPC] 83xx: Update mpc83xx_defconfig
Kumar Gala (1):
[POWERPC] 85xx: Add second cpu to 8572 dts
Scott Wood (1):
[POWERPC] 8xx: adder875, ep88xc: fix to match recent 8xx cleanups.
^ permalink raw reply
* Re: [PATCH] [POWERPC] qe_lib: fix few fluffy negligences (was: Re: [PATCH 1/5] [POWERPC] qe_lib and users: get rid of most device_types and model)
From: Kumar Gala @ 2008-02-06 6:04 UTC (permalink / raw)
To: avorontsov; +Cc: Stephen Rothwell, linuxppc-dev
In-Reply-To: <20080204134617.GA10377@localhost.localdomain>
>
> From: Anton Vorontsov <avorontsov@ru.mvista.com>
> Subject: [POWERPC] qe_lib: fix few fluffy negligences
>
> One is intoduced by me (of_node_put() absence) and another was
> present already (not checking for NULL).
>
> Found by Stephen Rothwell.
>
> Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
> ---
> arch/powerpc/sysdev/qe_lib/qe.c | 10 +++++-----
> 1 files changed, 5 insertions(+), 5 deletions(-)
applied.
- k
^ permalink raw reply
* Re: compile quirk linux-2.6.24 (with workaround)
From: Bernhard Reiter @ 2008-02-06 10:07 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev, debian-powerpc, paulus
In-Reply-To: <20080205093820.5918a216@zod.rchland.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 983 bytes --]
On Tuesday 05 February 2008 16:38, Josh Boyer wrote:
> > That would mean we're dropping support for compilers which can't build
> > 405/440 specific wrapper bits (or other core specific quirks that need
> > to go in the wrapper) That doesn't sound appropriate to me.
I agree.
Note that dropping support for these compilers will raise the hurdle to
compile kernels, which might lead to less testing of the whole kernel. This
effect would probably eat up the advantages of better testing by always
building the whole source. So I do not recommend it. :)
> No it doesn't. At least not yet. I said I'd try to come up with a
> patch soon-ish.
Thanks in advance!
--
Managing Director - Owner: www.intevation.net (Free Software Company)
Germany Coordinator: fsfeurope.org. Coordinator: www.Kolab-Konsortium.com.
Intevation GmbH, Osnabrück, DE; Amtsgericht Osnabrück, HRB 18998
Geschäftsführer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Problems booting in ML403
From: A. Nolson @ 2008-02-06 12:04 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <fa686aa40802050824y2a650231j3889b749d3553701@mail.gmail.com>
It seems that the multiple "console=" parameters in the kernel were the
problem. I have substituted for only
console=ttyS0,9600
Now I have managed to boot it completely.
Thank you!
Grant Likely wrote:
> On 2/5/08, A. Nolson <alohanono@gmail.com> wrote:
>
>> Hello,
>>
>> I am having problems while trying to boot my linux kernel 2.6.24-rc3 (
>> secretlab git). After some days studying this list and other related
>> documents/wikis about how to make work a linux kernel in my ML403, I
>> managed to make it work partially.
>>
>>
> <snip>
>
>> Linux/PPC load: console=ttyS0,9600 console=tty0,9600 console=ttyUL0,9600
>> root=/d
>> ev/xsa2 rw
>> init=/sbin/init
>>
>
> What happens if you try init=/bin/sh?
>
> What does your /etc/inittab look like?
>
> It looks like the system is booting, but inittab might not be starting
> any processes attached to the serial console.
>
> Cheers,
> g.
>
>
^ permalink raw reply
* Re: [PATCH] [POWERPC] iSeries: fix section mismatch in iseries_veth
From: Stephen Rothwell @ 2008-02-06 12:11 UTC (permalink / raw)
To: Jeff Garzik; +Cc: ppc-dev, paulus, netdev
In-Reply-To: <47A8ABC1.9080008@pobox.com>
[-- Attachment #1: Type: text/plain, Size: 305 bytes --]
On Tue, 05 Feb 2008 13:32:33 -0500 Jeff Garzik <jgarzik@pobox.com> wrote:
>
> it's trivial enough to not matter, and faster to just... applied
> (if you'll pardon the bad grammar)
Thanks.
--
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] net: NEWEMAC: Remove "rgmii-interface" from rgmii matching table
From: Jeff Garzik @ 2008-02-06 12:12 UTC (permalink / raw)
To: Josh Boyer; +Cc: Stefan Roese, netdev, linuxppc-dev
In-Reply-To: <20080205151216.4ff3c32a@weaponx>
Josh Boyer wrote:
> On Thu, 31 Jan 2008 10:14:58 +1100
> Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
>
>> On Wed, 2008-01-30 at 07:16 +0100, Stefan Roese wrote:
>>> On Wednesday 16 January 2008, Josh Boyer wrote:
>>>> On Wed, 16 Jan 2008 20:53:59 +1100
>>>>
>>>> Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
>>>>> On Wed, 2008-01-16 at 10:37 +0100, Stefan Roese wrote:
>>>>>> With the removal the the "rgmii-interface" device_type property from
>>>>>> the dts files, the newemac driver needs an update to only rely on
>>>>>> compatible property.
>>>>>>
>>>>>> Signed-off-by: Stefan Roese <sr@denx.de>
>>>>> I need to test if it works on CAB, can't change the DT on those. I'll
>>>>> let you know tomorrow.
>>>> This should be fine on CAB. The rgmii node has:
>>>>
>>>> compatible = "ibm,rgmii-axon", "ibm,rgmii"
>>>>
>>>> so the match should still catch on the latter.
>>> How about this patch? Ben, if you think this is ok then we should make sure
>>> that it goes in in this merge-window, since the other dts patch relies on it.
>> It's fine.
>
> Jeff, any chance this can get into .25 soon? I have another patch
> queued up behind this one that requires it, and I don't see it in any
> of your trees or branches.
>
> Or, if you aren't opposed, I can take it through Paul's tree with your
> Ack.
can you resend? I don't see it in the pile
^ permalink raw reply
* Re: [PATCH] e1000: Fix for 32 bits platforms with 64 bits resources
From: Jeff Garzik @ 2008-02-06 12:13 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: netdev, auke-jan.h.kok, jgarzik, linuxppc-dev
In-Reply-To: <20071116073821.548CCDDDF4@ozlabs.org>
Benjamin Herrenschmidt wrote:
> The e1000 driver stores the content of the PCI resources into
> unsigned long's before ioremapping. This breaks on 32 bits
> platforms that support 64 bits MMIO resources such as ppc 44x.
>
> This fixes it by removing those temporary variables and passing
> directly the result of pci_resource_start/len to ioremap.
>
> The side effect is that I removed the assignments to the netdev
> fields mem_start, mem_end and base_addr, which are totally useless
> for PCI devices.
>
> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> --
>
> drivers/net/e1000/e1000_main.c | 18 +++++-------------
> 1 file changed, 5 insertions(+), 13 deletions(-)
applied
^ permalink raw reply
* [PATCH] net: NEWEMAC: Remove "rgmii-interface" from rgmii matching table
From: Stefan Roese @ 2008-02-06 12:21 UTC (permalink / raw)
To: jeff; +Cc: linuxppc-dev, netdev
With the removal the the "rgmii-interface" device_type property from the
dts files, the newemac driver needs an update to only rely on compatible
property.
Signed-off-by: Stefan Roese <sr@denx.de>
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
drivers/net/ibm_newemac/rgmii.c | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/drivers/net/ibm_newemac/rgmii.c b/drivers/net/ibm_newemac/rgmii.c
index 9bc1132..5757788 100644
--- a/drivers/net/ibm_newemac/rgmii.c
+++ b/drivers/net/ibm_newemac/rgmii.c
@@ -302,7 +302,6 @@ static int __devexit rgmii_remove(struct of_device *ofdev)
static struct of_device_id rgmii_match[] =
{
{
- .type = "rgmii-interface",
.compatible = "ibm,rgmii",
},
{
--
1.5.4.rc3
^ permalink raw reply related
* Re: [PATCH] net: NEWEMAC: Remove "rgmii-interface" from rgmii matching table
From: Stefan Roese @ 2008-02-06 12:16 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Jeff Garzik, netdev
In-Reply-To: <47A9A443.2020109@pobox.com>
On Wednesday 06 February 2008, Jeff Garzik wrote:
> > Jeff, any chance this can get into .25 soon? I have another patch
> > queued up behind this one that requires it, and I don't see it in any
> > of your trees or branches.
> >
> > Or, if you aren't opposed, I can take it through Paul's tree with your
> > Ack.
>
> can you resend? I don't see it in the pile
Will do.
Best regards,
Stefan
^ permalink raw reply
* Re: [PATCH] net: NEWEMAC: Remove "rgmii-interface" from rgmii matching table
From: Josh Boyer @ 2008-02-06 12:49 UTC (permalink / raw)
To: Stefan Roese; +Cc: linuxppc-dev, netdev, jeff
In-Reply-To: <1202300519-7294-1-git-send-email-sr@denx.de>
On Wed, 6 Feb 2008 13:21:59 +0100
Stefan Roese <sr@denx.de> wrote:
> With the removal the the "rgmii-interface" device_type property from the
> dts files, the newemac driver needs an update to only rely on compatible
> property.
>
> Signed-off-by: Stefan Roese <sr@denx.de>
> Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Acked-by: Josh Boyer <jwboyer@linux.vnet.ibm.com>
josh
^ permalink raw reply
* Re: V4L2: __ucmpdi2 undefined on ppc
From: Stephane Marchesin @ 2008-02-06 14:39 UTC (permalink / raw)
To: linuxppc-dev; +Cc: henrik.sorensen, David Woodhouse, paulus
In-Reply-To: <1166362145.6714.53.camel@pmac.infradead.org>
On 12/17/06, David Woodhouse <dwmw2@infradead.org> wrote:
>
> You still get to 'accidentally' do 64-bit arithmetic in-kernel that way
> though. Might be better just to provide __ucmpdi2, just as we have for
> the other functions which are required from libgcc
>
> It'd be better just to fix the compiler though -- which is in fact what
> they've done: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25724
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21237
>
> I've applied this as a temporary hack to the Fedora kernel until the
> compiler is updated there...
>
Hello,
We're hitting this i nouveau as well (http://nouveau.freedesktop.org),
since we make extensive use ot 64 bit ints. Over time, we've had a
number of reports on this issue, and at one point I read that it
should be fixed in gcc. But recently, a nouveau user on PPC32 (Henrik
in CC:) reported the issue again with gcc 4.2.3. Others have it on gcc
4.2.2 too:
http://bugs.freedesktop.org/show_bug.cgi?id=10547
So, the point of this email is to ask about the possibility of merging
in one of the __ucmpdi2 patches, like David's which is kept below for
reference. Most distros seem to ship with such a patch already, and it
seems that other drivers hit this as well.
Thanks,
Stephane
> --- linux-2.6.19.ppc/arch/powerpc/kernel/misc_32.S~ 2006-11-29 21:57:37.000000000 +0000
> +++ linux-2.6.19.ppc/arch/powerpc/kernel/misc_32.S 2006-12-17 12:19:48.000000000 +0000
> @@ -728,6 +728,27 @@ _GLOBAL(__lshrdi3)
> or r4,r4,r7 # LSW |= t2
> blr
>
> +/*
> + * __ucmpdi2: 64-bit comparison
> + *
> + * R3/R4 has 64 bit value A
> + * R5/R6 has 64 bit value B
> + * result in R3: 0 for A < B
> + * 1 for A == B
> + * 2 for A > B
> + */
> +_GLOBAL(__ucmpdi2)
> + cmplw r7,r3,r5 # compare high words
> + li r3,0
> + blt r7,2f # a < b ... return 0
> + bgt r7,1f # a > b ... return 2
> + cmplw r6,r4,r6 # compare low words
> + blt r6,2f # a < b ... return 0
> + li r3,1
> + ble r6,2f # a = b ... return 1
> +1: li r3,2
> +2: blr
> +
> _GLOBAL(abs)
> srawi r4,r3,31
> xor r3,r3,r4
> --- linux-2.6.19.ppc/arch/powerpc/kernel/ppc_ksyms.c~ 2006-12-15 17:19:56.000000000 +0000
> +++ linux-2.6.19.ppc/arch/powerpc/kernel/ppc_ksyms.c 2006-12-17 12:16:54.000000000 +0000
> @@ -161,9 +161,11 @@ EXPORT_SYMBOL(to_tm);
> long long __ashrdi3(long long, int);
> long long __ashldi3(long long, int);
> long long __lshrdi3(long long, int);
> +int __ucmpdi2(uint64_t, uint64_t);
> EXPORT_SYMBOL(__ashrdi3);
> EXPORT_SYMBOL(__ashldi3);
> EXPORT_SYMBOL(__lshrdi3);
> +EXPORT_SYMBOL(__ucmpdi2);
> #endif
>
> EXPORT_SYMBOL(memcpy);
>
> --
> dwmw2
>
^ permalink raw reply
* Re: [Virtex 4 PPC] Which Linux?
From: IngoM @ 2008-02-06 14:51 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <20080205145834.GQ13945@pengutronix.de>
Hello!
Thanks for all answers!
Robert Schwebel wrote:
>
> On Mon, Feb 04, 2008 at 05:54:55AM -0800, IngoM wrote:
>> 2) Linux
>> I'd like to build my kernel and filesystem myself. But which way to go?
>> Using OE, buildroot, ELDK...
>> Can you please provide some starting points for me?
>
> ptxdist would be another alternative.
>
In the meantime, I get crosstool to compile my toolchain.
With that toolchain I get a xilinx kernel from their git-repo compiling and
booting up.
ptxdist compiles my userland, but I have some more probs:
I use the xmd from EDK to download and run the kernel.
I try to setup a rootfs via NFS but the kernel didn't get an address, maybe
there is a problem with the network-setup.
It's not clear to me how put the kernel-image and the userland to one
elf-binary that is downloadable by xmd, because to work around the above
network issue to get things started.
Best Regards,
Ingo
--
View this message in context: http://www.nabble.com/-Virtex-4-PPC--Which-Linux--tp15268468p15306699.html
Sent from the linuxppc-embedded mailing list archive at Nabble.com.
^ permalink raw reply
* Re: [PATCH] net: NEWEMAC: Remove "rgmii-interface" from rgmii matching table
From: Olof Johansson @ 2008-02-06 16:01 UTC (permalink / raw)
To: Stefan Roese; +Cc: linuxppc-dev, jeff, netdev
In-Reply-To: <1202300519-7294-1-git-send-email-sr@denx.de>
On Wed, Feb 06, 2008 at 01:21:59PM +0100, Stefan Roese wrote:
> With the removal the the "rgmii-interface" device_type property from the
> dts files, the newemac driver needs an update to only rely on compatible
> property.
What about systems using an older dts, such as one kexec:ing from an
older kernel?
Just because the device tree source is distributed in the kernel tree
doesn't mean it can give up backwards compatibility.
-Olof
^ permalink raw reply
* Re: [PATCH] net: NEWEMAC: Remove "rgmii-interface" from rgmii matching table
From: Josh Boyer @ 2008-02-06 16:23 UTC (permalink / raw)
To: Olof Johansson; +Cc: linuxppc-dev, Stefan Roese, jeff, netdev
In-Reply-To: <20080206160157.GA18228@lixom.net>
On Wed, 6 Feb 2008 10:01:57 -0600
Olof Johansson <olof@lixom.net> wrote:
> On Wed, Feb 06, 2008 at 01:21:59PM +0100, Stefan Roese wrote:
> > With the removal the the "rgmii-interface" device_type property from the
> > dts files, the newemac driver needs an update to only rely on compatible
> > property.
>
> What about systems using an older dts, such as one kexec:ing from an
> older kernel?
Like what? Kexec doesn't work on 4xx yet.
> Just because the device tree source is distributed in the kernel tree
> doesn't mean it can give up backwards compatibility.
We checked Axon, which is the only non-DTS machine that uses EMAC and
it will work fine with this change.
josh
^ permalink raw reply
* Re: [PATCH] net: NEWEMAC: Remove "rgmii-interface" from rgmii matching table
From: Olof Johansson @ 2008-02-06 16:35 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev, Stefan Roese, jeff, netdev
In-Reply-To: <20080206102340.1cdf7f8d@zod.rchland.ibm.com>
On Wed, Feb 06, 2008 at 10:23:40AM -0600, Josh Boyer wrote:
> On Wed, 6 Feb 2008 10:01:57 -0600
> Olof Johansson <olof@lixom.net> wrote:
>
> > On Wed, Feb 06, 2008 at 01:21:59PM +0100, Stefan Roese wrote:
> > > With the removal the the "rgmii-interface" device_type property from the
> > > dts files, the newemac driver needs an update to only rely on compatible
> > > property.
> >
> > What about systems using an older dts, such as one kexec:ing from an
> > older kernel?
>
> Like what? Kexec doesn't work on 4xx yet.
Sure, but similar restrictions would apply for customers who have a
flashed device tree that want to boot a newer kernel. Deprecating old
device tree support is something that should be done very carefully.
> > Just because the device tree source is distributed in the kernel tree
> > doesn't mean it can give up backwards compatibility.
>
> We checked Axon, which is the only non-DTS machine that uses EMAC and
> it will work fine with this change.
Ah, ok. I remember discussions about this patch before then, sounds like
it's safe. I just triggered on the dts-centric patch description.
Objections withdrawn. :)
-Olof
^ permalink raw reply
* [PATCH v3] [POWERPC] bootwrapper: build multiple cuImages
From: Grant Likely @ 2008-02-06 16:48 UTC (permalink / raw)
To: paulus, jwboyer, linuxppc-dev, scottwood, galak, geoffrey.levand,
arnd
From: Grant Likely <grant.likely@secretlab.ca>
Currently, the kernel uses CONFIG_DEVICE_TREE to wrap a kernel image
with a fdt blob which means for any given configuration only one dts
file can be selected and so support for only one board can be built
This patch moves the selection of the default .dts file out of the kernel
config and into the bootwrapper makefile. The makefile chooses which
images to build based on the kernel config and the dts source file
name is taken directly from the image name. For example "cuImage.ebony"
will use "ebony.dts" as the device tree source file.
In addition, this patch allows a specific image to be requested from the
command line by adding "cuImage.%" and "treeImage.%" targets to the list
of valid built targets in arch/powerpc/Makefile. This allows the default
dts selection to be overridden.
Another advantage to this change is it allows a single defconfig to be
supplied for all boards using the same chip family and only differing in
the device tree.
Important note: This patch adds two new zImage targets; zImage.dtb.% and
zImage.dtb.initrd.% for zImages with embedded dtb files. Currently
there are 5 platforms which require this: ps3, ep405, mpc885ads, ep88xc,
adder875-redboot and ep8248e. This patch *changes the zImage filenames*
for those platforms. ie. 'zImage.ps3' is now 'zImage.dtb.ps3'.
This new zImage.dtb targets were added so that the .dts file could be
part of the dependancies list for building them.
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
---
v3: I think this patch is complete. Renamed zImage.dtb.% targets to
zImage-dtb.% to avoid make choosing the wrong rule if the dts file is missing.
Please test to make sure nothing is broken. I'd like to see this one get
picked up for .25
v2: This version fixes some bugs and adds new zImage.dtb and
zImage.initrd.dtb targets.
v1: Please review and comment. I have not exhaustively tested this patch
and I'm sure to have missed some boards. However, I think the concept
is sound and will be a good change.
---
arch/powerpc/Kconfig | 19 -----
arch/powerpc/Makefile | 9 +-
arch/powerpc/boot/Makefile | 130 ++++++++++++++++++++------------
arch/powerpc/boot/cuboot-hpc2.c | 48 ------------
arch/powerpc/boot/cuboot-mpc7448hpc2.c | 48 ++++++++++++
arch/powerpc/boot/wrapper | 23 ++++++
6 files changed, 155 insertions(+), 122 deletions(-)
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 2bf2f3f..4903796 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -415,25 +415,6 @@ config WANT_DEVICE_TREE
bool
default n
-config DEVICE_TREE
- string "Static device tree source file"
- depends on WANT_DEVICE_TREE
- help
- This specifies the device tree source (.dts) file to be
- compiled and included when building the bootwrapper. If a
- relative filename is given, then it will be relative to
- arch/powerpc/boot/dts. If you are not using the bootwrapper,
- or do not need to build a dts into the bootwrapper, this
- field is ignored.
-
- For example, this is required when building a cuImage target
- for an older U-Boot, which cannot pass a device tree itself.
- Such a kernel will not work with a newer U-Boot that tries to
- pass a device tree (unless you tell it not to). If your U-Boot
- does not mention a device tree in "help bootm", then use the
- cuImage target and specify a device tree here. Otherwise, use
- the uImage target and leave this field blank.
-
endmenu
config ISA_DMA_API
diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile
index f70df9b..6845482 100644
--- a/arch/powerpc/Makefile
+++ b/arch/powerpc/Makefile
@@ -151,14 +151,11 @@ core-$(CONFIG_XMON) += arch/powerpc/xmon/
drivers-$(CONFIG_OPROFILE) += arch/powerpc/oprofile/
# Default to zImage, override when needed
-defaultimage-y := zImage
-defaultimage-$(CONFIG_DEFAULT_UIMAGE) := uImage
-KBUILD_IMAGE := $(defaultimage-y)
-all: $(KBUILD_IMAGE)
+all: zImage
CPPFLAGS_vmlinux.lds := -Upowerpc
-BOOT_TARGETS = zImage zImage.initrd uImage
+BOOT_TARGETS = zImage zImage.initrd uImage treeImage.% cuImage.%
PHONY += $(BOOT_TARGETS)
@@ -180,7 +177,7 @@ define archhelp
endef
install: vdso_install
- $(Q)$(MAKE) $(build)=$(boot) BOOTIMAGE=$(KBUILD_IMAGE) install
+ $(Q)$(MAKE) $(build)=$(boot) install
vdso_install:
ifeq ($(CONFIG_PPC64),y)
diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile
index 122a270..dc9952a 100644
--- a/arch/powerpc/boot/Makefile
+++ b/arch/powerpc/boot/Makefile
@@ -60,8 +60,9 @@ src-wlib := string.S crt0.S stdio.c main.c \
src-plat := of.c cuboot-52xx.c cuboot-824x.c cuboot-83xx.c cuboot-85xx.c holly.c \
cuboot-ebony.c treeboot-ebony.c prpmc2800.c \
ps3-head.S ps3-hvcall.S ps3.c treeboot-bamboo.c cuboot-8xx.c \
- cuboot-pq2.c cuboot-sequoia.c treeboot-walnut.c cuboot-bamboo.c \
- fixed-head.S ep88xc.c cuboot-hpc2.c ep405.c cuboot-taishan.c \
+ cuboot-pq2.c cuboot-sequoia.c treeboot-walnut.c \
+ cuboot-bamboo.c cuboot-mpc7448hpc2.c cuboot-taishan.c \
+ fixed-head.S ep88xc.c ep405.c \
cuboot-katmai.c cuboot-rainier.c redboot-8xx.c ep8248e.c \
cuboot-warp.c cuboot-85xx-cpm2.c
src-boot := $(src-wlib) $(src-plat) empty.c
@@ -123,6 +124,8 @@ targets += $(patsubst $(obj)/%,%,$(obj-boot) wrapper.a)
extra-y := $(obj)/wrapper.a $(obj-plat) $(obj)/empty.o \
$(obj)/zImage.lds $(obj)/zImage.coff.lds $(obj)/zImage.ps3.lds
+dtstree := $(srctree)/$(src)/dts
+
wrapper :=$(srctree)/$(src)/wrapper
wrapperbits := $(extra-y) $(addprefix $(obj)/,addnote hack-coff mktree dtc) \
$(wrapper) FORCE
@@ -181,7 +184,7 @@ quiet_cmd_wrap = WRAP $@
image-$(CONFIG_PPC_PSERIES) += zImage.pseries
image-$(CONFIG_PPC_MAPLE) += zImage.pseries
image-$(CONFIG_PPC_IBM_CELL_BLADE) += zImage.pseries
-image-$(CONFIG_PPC_PS3) += zImage.ps3
+image-$(CONFIG_PPC_PS3) += zImage-dtb.ps3
image-$(CONFIG_PPC_CELLEB) += zImage.pseries
image-$(CONFIG_PPC_CHRP) += zImage.chrp
image-$(CONFIG_PPC_EFIKA) += zImage.chrp
@@ -191,33 +194,73 @@ image-$(CONFIG_PPC_PRPMC2800) += zImage.prpmc2800
image-$(CONFIG_PPC_ISERIES) += zImage.iseries
image-$(CONFIG_DEFAULT_UIMAGE) += uImage
-ifneq ($(CONFIG_DEVICE_TREE),"")
-image-$(CONFIG_PPC_8xx) += cuImage.8xx
-image-$(CONFIG_PPC_EP88XC) += zImage.ep88xc
-image-$(CONFIG_EP405) += zImage.ep405
-image-$(CONFIG_8260) += cuImage.pq2
-image-$(CONFIG_EP8248E) += zImage.ep8248e
-image-$(CONFIG_PPC_MPC52xx) += cuImage.52xx
-image-$(CONFIG_STORCENTER) += cuImage.824x
-image-$(CONFIG_PPC_83xx) += cuImage.83xx
-image-$(CONFIG_PPC_85xx) += cuImage.85xx
-ifeq ($(CONFIG_CPM2),y)
-image-$(CONFIG_PPC_85xx) += cuImage.85xx-cpm2
-endif
-image-$(CONFIG_MPC7448HPC2) += cuImage.hpc2
+#
+# Targets which embed a device tree blob
+#
+# Theses are default targets to build images which embed device tree blobs.
+# They are only required on boards which do not have FDT support in firmware.
+# Boards with newish u-boot firmare can use the uImage target above
+#
+
+# Board ports in arch/powerpc/platform/40x/Kconfig
+image-$(CONFIG_EP405) += zImage-dtb.ep405
+image-$(CONFIG_WALNUT) += treeImage.walnut
+
+# Board ports in arch/powerpc/platform/44x/Kconfig
image-$(CONFIG_EBONY) += treeImage.ebony cuImage.ebony
image-$(CONFIG_BAMBOO) += treeImage.bamboo cuImage.bamboo
image-$(CONFIG_SEQUOIA) += cuImage.sequoia
image-$(CONFIG_RAINIER) += cuImage.rainier
-image-$(CONFIG_WALNUT) += treeImage.walnut
image-$(CONFIG_TAISHAN) += cuImage.taishan
image-$(CONFIG_KATMAI) += cuImage.katmai
image-$(CONFIG_WARP) += cuImage.warp
-endif
-ifneq ($(CONFIG_REDBOOT),"")
-image-$(CONFIG_PPC_8xx) += zImage.redboot-8xx
-endif
+# Board ports in arch/powerpc/platform/8xx/Kconfig
+image-$(CONFIG_PPC_MPC86XADS) += cuImage.mpc866ads
+image-$(CONFIG_PPC_MPC885ADS) += zImage-dtb.mpc885ads
+image-$(CONFIG_PPC_EP88XC) += zImage-dtb.ep88xc
+image-$(CONFIG_PPC_ADDER875) += cuImage.adder875-uboot \
+ zImage-dtb.adder875-redboot
+
+# Board ports in arch/powerpc/platform/52xx/Kconfig
+image-$(CONFIG_PPC_LITE5200) += cuImage.lite5200 cuImage.lite5200b
+
+# Board ports in arch/powerpc/platform/82xx/Kconfig
+image-$(CONFIG_MPC8272_ADS) += cuImage.mpc8272ads
+image-$(CONFIG_PQ2FADS) += cuImage.pq2fads
+image-$(CONFIG_EP8248E) += zImage-dtb.ep8248e
+
+# Board ports in arch/powerpc/platform/83xx/Kconfig
+image-$(CONFIG_MPC8313_RDB) += cuImage.mpc8313erdb
+image-$(CONFIG_MPC832x_MDS) += cuImage.mpc832x_mds
+image-$(CONFIG_MPC832x_RDB) += cuImage.mpc832x_rdb
+image-$(CONFIG_MPC834x_ITX) += cuImage.mpc8349emitx \
+ cuImage.mpc8349emitxgp
+image-$(CONFIG_MPC834x_MDS) += cuImage.mpc834x_mds
+image-$(CONFIG_MPC836x_MDS) += cuImage.mpc836x_mds
+image-$(CONFIG_MPC837x_MDS) += cuImage.mpc8377_mds \
+ cuImage.mpc8378_mds \
+ cuImage.mpc8379_mds
+
+# Board ports in arch/powerpc/platform/85xx/Kconfig
+image-$(CONFIG_MPC8540_ADS) += cuImage.mpc8540ads
+image-$(CONFIG_MPC8560_ADS) += cuImage.mpc8560ads
+image-$(CONFIG_MPC85xx_CDS) += cuImage.mpc8541cds \
+ cuImage.mpc8548cds \
+ cuImage.mpc8555cds
+image-$(CONFIG_MPC85xx_MDS) += cuImage.mpc8568mds
+image-$(CONFIG_MPC85xx_DS) += cuImage.mpc8544ds \
+ cuImage.mpc8572ds
+image-$(CONFIG_TQM8540) += cuImage.tqm8540
+image-$(CONFIG_TQM8541) += cuImage.tqm8541
+image-$(CONFIG_TQM8555) += cuImage.tqm8555
+image-$(CONFIG_TQM8560) += cuImage.tqm8560
+image-$(CONFIG_SBC8548) += cuImage.tqm8548
+image-$(CONFIG_SBC8560) += cuImage.tqm8560
+
+# Board ports in arch/powerpc/platform/embedded6xx/Kconfig
+image-$(CONFIG_STORCENTER) += cuImage.storcenter
+image-$(CONFIG_MPC7448HPC2) += cuImage.mpc7448hpc2
# For 32-bit powermacs, build the COFF and miboot images
# as well as the ELF images.
@@ -233,24 +276,20 @@ targets += $(image-y) $(initrd-y)
$(addprefix $(obj)/, $(initrd-y)): $(obj)/ramdisk.image.gz
-# If CONFIG_WANT_DEVICE_TREE is set and CONFIG_DEVICE_TREE isn't an
-# empty string, define 'dts' to be path to the dts
-# CONFIG_DEVICE_TREE will have "" around it, make sure to strip them
-ifeq ($(CONFIG_WANT_DEVICE_TREE),y)
-ifneq ($(CONFIG_DEVICE_TREE),"")
-dts = $(if $(shell echo $(CONFIG_DEVICE_TREE) | grep '^/'),\
- ,$(srctree)/$(src)/dts/)$(CONFIG_DEVICE_TREE:"%"=%)
-endif
-endif
-
# Don't put the ramdisk on the pattern rule; when its missing make will try
# the pattern rule with less dependencies that also matches (even with the
# hard dependency listed).
-$(obj)/zImage.initrd.%: vmlinux $(wrapperbits) $(dts)
- $(call if_changed,wrap,$*,$(dts),,$(obj)/ramdisk.image.gz)
+$(obj)/zImage.initrd.%: vmlinux $(wrapperbits)
+ $(call if_changed,wrap,$*,,,$(obj)/ramdisk.image.gz)
-$(obj)/zImage.%: vmlinux $(wrapperbits) $(dts)
- $(call if_changed,wrap,$*,$(dts))
+$(obj)/zImage.%: vmlinux $(wrapperbits)
+ $(call if_changed,wrap,$*)
+
+$(obj)/zImage-dtb.initrd.%: vmlinux $(wrapperbits) $(dtstree)/%.dts
+ $(call if_changed,wrap,$*,$(dtstree)/$*.dts,,$(obj)/ramdisk.image.gz)
+
+$(obj)/zImage-dtb.%: vmlinux $(wrapperbits) $(dtstree)/%.dts
+ $(call if_changed,wrap,$*,$(dtstree)/$*.dts)
# This cannot be in the root of $(src) as the zImage rule always adds a $(obj)
# prefix
@@ -260,24 +299,17 @@ $(obj)/vmlinux.strip: vmlinux
$(obj)/zImage.iseries: vmlinux
$(STRIP) -s -R .comment $< -o $@
-$(obj)/zImage.ps3: vmlinux $(wrapper) $(wrapperbits) $(srctree)/$(src)/dts/ps3.dts
- $(STRIP) -s -R .comment $< -o vmlinux.strip
- $(call cmd,wrap,ps3,$(srctree)/$(src)/dts/ps3.dts,,)
-
-$(obj)/zImage.initrd.ps3: vmlinux $(wrapper) $(wrapperbits) $(srctree)/$(src)/dts/ps3.dts $(obj)/ramdisk.image.gz
- $(call cmd,wrap,ps3,$(srctree)/$(src)/dts/ps3.dts,,$(obj)/ramdisk.image.gz)
-
$(obj)/uImage: vmlinux $(wrapperbits)
$(call if_changed,wrap,uboot)
-$(obj)/cuImage.%: vmlinux $(dts) $(wrapperbits)
- $(call if_changed,wrap,cuboot-$*,$(dts))
+$(obj)/cuImage.%: vmlinux $(dtstree)/%.dts $(wrapperbits)
+ $(call if_changed,wrap,cuboot-$*,$(dtstree)/$*.dts)
-$(obj)/treeImage.initrd.%: vmlinux $(dts) $(wrapperbits)
- $(call if_changed,wrap,treeboot-$*,$(dts),,$(obj)/ramdisk.image.gz)
+$(obj)/treeImage.initrd.%: vmlinux $(dtstree)/%.dts $(wrapperbits)
+ $(call if_changed,wrap,treeboot-$*,$(dtstree)/$*.dts,,$(obj)/ramdisk.image.gz)
-$(obj)/treeImage.%: vmlinux $(dts) $(wrapperbits)
- $(call if_changed,wrap,treeboot-$*,$(dts))
+$(obj)/treeImage.%: vmlinux $(dtstree)/%.dts $(wrapperbits)
+ $(call if_changed,wrap,treeboot-$*,$(dtstree)/$*.dts)
# If there isn't a platform selected then just strip the vmlinux.
ifeq (,$(image-y))
diff --git a/arch/powerpc/boot/cuboot-hpc2.c b/arch/powerpc/boot/cuboot-mpc7448hpc2.c
similarity index 100%
rename from arch/powerpc/boot/cuboot-hpc2.c
rename to arch/powerpc/boot/cuboot-mpc7448hpc2.c
diff --git a/arch/powerpc/boot/wrapper b/arch/powerpc/boot/wrapper
index 763a0c4..c317815 100755
--- a/arch/powerpc/boot/wrapper
+++ b/arch/powerpc/boot/wrapper
@@ -158,6 +158,29 @@ miboot|uboot)
cuboot*)
binary=y
gzip=
+ case "$platform" in
+ *-mpc885ads|*-adder875*|*-ep88xc)
+ platformo=$object/cuboot-8xx.o
+ ;;
+ *5200*|*-motionpro)
+ platformo=$object/cuboot-52xx.o
+ ;;
+ *-pq2fads|*-ep8248e|*-mpc8272*|*-storcenter)
+ platformo=$object/cuboot-pq2.o
+ ;;
+ *-mpc824*)
+ platformo=$object/cuboot-824x.o
+ ;;
+ *-mpc83*)
+ platformo=$object/cuboot-83xx.o
+ ;;
+ *-tqm8541|*-mpc8560*|*-tqm8560|*-tqm8555*)
+ platformo=$object/cuboot-85xx-cpm2.o
+ ;;
+ *-mpc85*)
+ platformo=$object/cuboot-85xx.o
+ ;;
+ esac
;;
ps3)
platformo="$object/ps3-head.o $object/ps3-hvcall.o $object/ps3.o"
^ permalink raw reply related
* Re: [PATCH v3] [POWERPC] bootwrapper: build multiple cuImages
From: Scott Wood @ 2008-02-06 17:04 UTC (permalink / raw)
To: Grant Likely; +Cc: arnd, linuxppc-dev, paulus
In-Reply-To: <20080206164656.10079.15210.stgit@trillian.secretlab.ca>
Grant Likely wrote:
> -ifneq ($(CONFIG_DEVICE_TREE),"")
> -image-$(CONFIG_PPC_8xx) += cuImage.8xx
> -image-$(CONFIG_PPC_EP88XC) += zImage.ep88xc
> -image-$(CONFIG_EP405) += zImage.ep405
> -image-$(CONFIG_8260) += cuImage.pq2
> -image-$(CONFIG_EP8248E) += zImage.ep8248e
> -image-$(CONFIG_PPC_MPC52xx) += cuImage.52xx
> -image-$(CONFIG_STORCENTER) += cuImage.824x
> -image-$(CONFIG_PPC_83xx) += cuImage.83xx
> -image-$(CONFIG_PPC_85xx) += cuImage.85xx
> -ifeq ($(CONFIG_CPM2),y)
> -image-$(CONFIG_PPC_85xx) += cuImage.85xx-cpm2
> -endif
> -image-$(CONFIG_MPC7448HPC2) += cuImage.hpc2
> +#
> +# Targets which embed a device tree blob
> +#
> +# Theses are default targets to build images which embed device tree blobs.
> +# They are only required on boards which do not have FDT support in firmware.
> +# Boards with newish u-boot firmare can use the uImage target above
> +#
> +
> +# Board ports in arch/powerpc/platform/40x/Kconfig
> +image-$(CONFIG_EP405) += zImage-dtb.ep405
> +image-$(CONFIG_WALNUT) += treeImage.walnut
> +
> +# Board ports in arch/powerpc/platform/44x/Kconfig
> image-$(CONFIG_EBONY) += treeImage.ebony cuImage.ebony
> image-$(CONFIG_BAMBOO) += treeImage.bamboo cuImage.bamboo
> image-$(CONFIG_SEQUOIA) += cuImage.sequoia
> image-$(CONFIG_RAINIER) += cuImage.rainier
> -image-$(CONFIG_WALNUT) += treeImage.walnut
> image-$(CONFIG_TAISHAN) += cuImage.taishan
> image-$(CONFIG_KATMAI) += cuImage.katmai
> image-$(CONFIG_WARP) += cuImage.warp
> -endif
>
> -ifneq ($(CONFIG_REDBOOT),"")
> -image-$(CONFIG_PPC_8xx) += zImage.redboot-8xx
> -endif
> +# Board ports in arch/powerpc/platform/8xx/Kconfig
> +image-$(CONFIG_PPC_MPC86XADS) += cuImage.mpc866ads
> +image-$(CONFIG_PPC_MPC885ADS) += zImage-dtb.mpc885ads
mpc885ads is cuImage.
> +# Board ports in arch/powerpc/platform/83xx/Kconfig
> +image-$(CONFIG_MPC8313_RDB) += cuImage.mpc8313erdb
I don't think we need cuImage for this board (no pre-device-tree u-boot).
> +image-$(CONFIG_MPC837x_MDS) += cuImage.mpc8377_mds \
> + cuImage.mpc8378_mds \
> + cuImage.mpc8379_mds
I really hope we don't need cuImage for these. :-)
I wish CONFIG_BOARD_FOO could be annotated with properties such as image
name and bootwrapper platform, rather than having to maintain
separate lists... Oh well.
-Scott
^ permalink raw reply
* Re: [PATCH v3] [POWERPC] bootwrapper: build multiple cuImages
From: Grant Likely @ 2008-02-06 17:17 UTC (permalink / raw)
To: Scott Wood; +Cc: arnd, linuxppc-dev, paulus
In-Reply-To: <47A9E8AB.1050804@freescale.com>
On 2/6/08, Scott Wood <scottwood@freescale.com> wrote:
> > -ifneq ($(CONFIG_REDBOOT),"")
> > -image-$(CONFIG_PPC_8xx) += zImage.redboot-8xx
> > -endif
> > +# Board ports in arch/powerpc/platform/8xx/Kconfig
> > +image-$(CONFIG_PPC_MPC86XADS) += cuImage.mpc866ads
> > +image-$(CONFIG_PPC_MPC885ADS) += zImage-dtb.mpc885ads
>
> mpc885ads is cuImage.
Fixed
>
> > +# Board ports in arch/powerpc/platform/83xx/Kconfig
> > +image-$(CONFIG_MPC8313_RDB) += cuImage.mpc8313erdb
>
> I don't think we need cuImage for this board (no pre-device-tree u-boot).
removed
>
> > +image-$(CONFIG_MPC837x_MDS) += cuImage.mpc8377_mds \
> > + cuImage.mpc8378_mds \
> > + cuImage.mpc8379_mds
>
> I really hope we don't need cuImage for these. :-)
removed
>
> I wish CONFIG_BOARD_FOO could be annotated with properties such as image
> name and bootwrapper platform, rather than having to maintain
> separate lists... Oh well.
Me too. Fortunately this is probably only an issue for images which
require an embedded dtb. Images that get their device trees from
elsewhere can follow the lead of CONFIG_DEFAULT_UIMAGE. Over time
this issue will diminish.
Thanks for the feedback
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH v3] [POWERPC] bootwrapper: build multiple cuImages
From: Geoff Levand @ 2008-02-06 18:06 UTC (permalink / raw)
To: Grant Likely; +Cc: arnd, linuxppc-dev, paulus, scottwood
In-Reply-To: <20080206164656.10079.15210.stgit@trillian.secretlab.ca>
Grant Likely wrote:
> diff --git a/arch/powerpc/boot/cuboot-hpc2.c b/arch/powerpc/boot/cuboot-mpc7448hpc2.c
> similarity index 100%
> rename from arch/powerpc/boot/cuboot-hpc2.c
> rename to arch/powerpc/boot/cuboot-mpc7448hpc2.c
This is not a proper patch.
No rule to make target `arch/powerpc/boot/cuboot-mpc7448hpc2.c
^ permalink raw reply
* Re: [PATCH v3] [POWERPC] bootwrapper: build multiple cuImages
From: Grant Likely @ 2008-02-06 18:21 UTC (permalink / raw)
To: Geoff Levand; +Cc: arnd, linuxppc-dev, paulus, scottwood
In-Reply-To: <47A9F734.9050005@am.sony.com>
On 2/6/08, Geoff Levand <geoffrey.levand@am.sony.com> wrote:
> Grant Likely wrote:
> > diff --git a/arch/powerpc/boot/cuboot-hpc2.c b/arch/powerpc/boot/cuboot-mpc7448hpc2.c
> > similarity index 100%
> > rename from arch/powerpc/boot/cuboot-hpc2.c
> > rename to arch/powerpc/boot/cuboot-mpc7448hpc2.c
>
>
> This is not a proper patch.
>
> No rule to make target `arch/powerpc/boot/cuboot-mpc7448hpc2.c
I've dropped the -M flag from git-format-patch for v4 of the patch.
You should have it any moment now.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* [PATCH v4] [POWERPC] bootwrapper: build multiple cuImages
From: Grant Likely @ 2008-02-06 18:18 UTC (permalink / raw)
To: paulus, jwboyer, linuxppc-dev, scottwood, galak, geoffrey.levand,
arnd
From: Grant Likely <grant.likely@secretlab.ca>
Currently, the kernel uses CONFIG_DEVICE_TREE to wrap a kernel image
with a fdt blob which means for any given configuration only one dts
file can be selected and so support for only one board can be built
This patch moves the selection of the default .dts file out of the kernel
config and into the bootwrapper makefile. The makefile chooses which
images to build based on the kernel config and the dts source file
name is taken directly from the image name. For example "cuImage.ebony"
will use "ebony.dts" as the device tree source file.
In addition, this patch allows a specific image to be requested from the
command line by adding "cuImage.%" and "treeImage.%" targets to the list
of valid built targets in arch/powerpc/Makefile. This allows the default
dts selection to be overridden.
Another advantage to this change is it allows a single defconfig to be
supplied for all boards using the same chip family and only differing in
the device tree.
Important note: This patch adds two new zImage targets; zImage.dtb.% and
zImage.dtb.initrd.% for zImages with embedded dtb files. Currently
there are 5 platforms which require this: ps3, ep405, mpc885ads, ep88xc,
adder875-redboot and ep8248e. This patch *changes the zImage filenames*
for those platforms. ie. 'zImage.ps3' is now 'zImage.dtb.ps3'.
This new zImage.dtb targets were added so that the .dts file could be
part of the dependancies list for building them.
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
---
v4: removed mpc837x_mds and mpc8313erdb cuimages and changed mpc885ads to
a cuImage
v3: I think this patch is complete. Renamed zImage.dtb.% targets to
zImage-dtb.% to avoid make choosing the wrong rule if the dts file is missing.
v2: This version fixes some bugs and adds new zImage.dtb and
zImage.initrd.dtb targets.
v1: Please review and comment. I have not exhaustively tested this patch
and I'm sure to have missed some boards. However, I think the concept
is sound and will be a good change.
---
arch/powerpc/Kconfig | 19 -----
arch/powerpc/Makefile | 9 +-
arch/powerpc/boot/Makefile | 126 ++++++++++++++++++++------------
arch/powerpc/boot/cuboot-hpc2.c | 48 ------------
arch/powerpc/boot/cuboot-mpc7448hpc2.c | 48 ++++++++++++
arch/powerpc/boot/wrapper | 23 ++++++
6 files changed, 151 insertions(+), 122 deletions(-)
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 2bf2f3f..4903796 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -415,25 +415,6 @@ config WANT_DEVICE_TREE
bool
default n
-config DEVICE_TREE
- string "Static device tree source file"
- depends on WANT_DEVICE_TREE
- help
- This specifies the device tree source (.dts) file to be
- compiled and included when building the bootwrapper. If a
- relative filename is given, then it will be relative to
- arch/powerpc/boot/dts. If you are not using the bootwrapper,
- or do not need to build a dts into the bootwrapper, this
- field is ignored.
-
- For example, this is required when building a cuImage target
- for an older U-Boot, which cannot pass a device tree itself.
- Such a kernel will not work with a newer U-Boot that tries to
- pass a device tree (unless you tell it not to). If your U-Boot
- does not mention a device tree in "help bootm", then use the
- cuImage target and specify a device tree here. Otherwise, use
- the uImage target and leave this field blank.
-
endmenu
config ISA_DMA_API
diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile
index f70df9b..6845482 100644
--- a/arch/powerpc/Makefile
+++ b/arch/powerpc/Makefile
@@ -151,14 +151,11 @@ core-$(CONFIG_XMON) += arch/powerpc/xmon/
drivers-$(CONFIG_OPROFILE) += arch/powerpc/oprofile/
# Default to zImage, override when needed
-defaultimage-y := zImage
-defaultimage-$(CONFIG_DEFAULT_UIMAGE) := uImage
-KBUILD_IMAGE := $(defaultimage-y)
-all: $(KBUILD_IMAGE)
+all: zImage
CPPFLAGS_vmlinux.lds := -Upowerpc
-BOOT_TARGETS = zImage zImage.initrd uImage
+BOOT_TARGETS = zImage zImage.initrd uImage treeImage.% cuImage.%
PHONY += $(BOOT_TARGETS)
@@ -180,7 +177,7 @@ define archhelp
endef
install: vdso_install
- $(Q)$(MAKE) $(build)=$(boot) BOOTIMAGE=$(KBUILD_IMAGE) install
+ $(Q)$(MAKE) $(build)=$(boot) install
vdso_install:
ifeq ($(CONFIG_PPC64),y)
diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile
index 122a270..49797a4 100644
--- a/arch/powerpc/boot/Makefile
+++ b/arch/powerpc/boot/Makefile
@@ -60,8 +60,9 @@ src-wlib := string.S crt0.S stdio.c main.c \
src-plat := of.c cuboot-52xx.c cuboot-824x.c cuboot-83xx.c cuboot-85xx.c holly.c \
cuboot-ebony.c treeboot-ebony.c prpmc2800.c \
ps3-head.S ps3-hvcall.S ps3.c treeboot-bamboo.c cuboot-8xx.c \
- cuboot-pq2.c cuboot-sequoia.c treeboot-walnut.c cuboot-bamboo.c \
- fixed-head.S ep88xc.c cuboot-hpc2.c ep405.c cuboot-taishan.c \
+ cuboot-pq2.c cuboot-sequoia.c treeboot-walnut.c \
+ cuboot-bamboo.c cuboot-mpc7448hpc2.c cuboot-taishan.c \
+ fixed-head.S ep88xc.c ep405.c \
cuboot-katmai.c cuboot-rainier.c redboot-8xx.c ep8248e.c \
cuboot-warp.c cuboot-85xx-cpm2.c
src-boot := $(src-wlib) $(src-plat) empty.c
@@ -123,6 +124,8 @@ targets += $(patsubst $(obj)/%,%,$(obj-boot) wrapper.a)
extra-y := $(obj)/wrapper.a $(obj-plat) $(obj)/empty.o \
$(obj)/zImage.lds $(obj)/zImage.coff.lds $(obj)/zImage.ps3.lds
+dtstree := $(srctree)/$(src)/dts
+
wrapper :=$(srctree)/$(src)/wrapper
wrapperbits := $(extra-y) $(addprefix $(obj)/,addnote hack-coff mktree dtc) \
$(wrapper) FORCE
@@ -181,7 +184,7 @@ quiet_cmd_wrap = WRAP $@
image-$(CONFIG_PPC_PSERIES) += zImage.pseries
image-$(CONFIG_PPC_MAPLE) += zImage.pseries
image-$(CONFIG_PPC_IBM_CELL_BLADE) += zImage.pseries
-image-$(CONFIG_PPC_PS3) += zImage.ps3
+image-$(CONFIG_PPC_PS3) += zImage-dtb.ps3
image-$(CONFIG_PPC_CELLEB) += zImage.pseries
image-$(CONFIG_PPC_CHRP) += zImage.chrp
image-$(CONFIG_PPC_EFIKA) += zImage.chrp
@@ -191,33 +194,69 @@ image-$(CONFIG_PPC_PRPMC2800) += zImage.prpmc2800
image-$(CONFIG_PPC_ISERIES) += zImage.iseries
image-$(CONFIG_DEFAULT_UIMAGE) += uImage
-ifneq ($(CONFIG_DEVICE_TREE),"")
-image-$(CONFIG_PPC_8xx) += cuImage.8xx
-image-$(CONFIG_PPC_EP88XC) += zImage.ep88xc
-image-$(CONFIG_EP405) += zImage.ep405
-image-$(CONFIG_8260) += cuImage.pq2
-image-$(CONFIG_EP8248E) += zImage.ep8248e
-image-$(CONFIG_PPC_MPC52xx) += cuImage.52xx
-image-$(CONFIG_STORCENTER) += cuImage.824x
-image-$(CONFIG_PPC_83xx) += cuImage.83xx
-image-$(CONFIG_PPC_85xx) += cuImage.85xx
-ifeq ($(CONFIG_CPM2),y)
-image-$(CONFIG_PPC_85xx) += cuImage.85xx-cpm2
-endif
-image-$(CONFIG_MPC7448HPC2) += cuImage.hpc2
+#
+# Targets which embed a device tree blob
+#
+# Theses are default targets to build images which embed device tree blobs.
+# They are only required on boards which do not have FDT support in firmware.
+# Boards with newish u-boot firmare can use the uImage target above
+#
+
+# Board ports in arch/powerpc/platform/40x/Kconfig
+image-$(CONFIG_EP405) += zImage-dtb.ep405
+image-$(CONFIG_WALNUT) += treeImage.walnut
+
+# Board ports in arch/powerpc/platform/44x/Kconfig
image-$(CONFIG_EBONY) += treeImage.ebony cuImage.ebony
image-$(CONFIG_BAMBOO) += treeImage.bamboo cuImage.bamboo
image-$(CONFIG_SEQUOIA) += cuImage.sequoia
image-$(CONFIG_RAINIER) += cuImage.rainier
-image-$(CONFIG_WALNUT) += treeImage.walnut
image-$(CONFIG_TAISHAN) += cuImage.taishan
image-$(CONFIG_KATMAI) += cuImage.katmai
image-$(CONFIG_WARP) += cuImage.warp
-endif
-ifneq ($(CONFIG_REDBOOT),"")
-image-$(CONFIG_PPC_8xx) += zImage.redboot-8xx
-endif
+# Board ports in arch/powerpc/platform/8xx/Kconfig
+image-$(CONFIG_PPC_MPC86XADS) += cuImage.mpc866ads
+image-$(CONFIG_PPC_MPC885ADS) += cuImage.mpc885ads
+image-$(CONFIG_PPC_EP88XC) += zImage-dtb.ep88xc
+image-$(CONFIG_PPC_ADDER875) += cuImage.adder875-uboot \
+ zImage-dtb.adder875-redboot
+
+# Board ports in arch/powerpc/platform/52xx/Kconfig
+image-$(CONFIG_PPC_LITE5200) += cuImage.lite5200 cuImage.lite5200b
+
+# Board ports in arch/powerpc/platform/82xx/Kconfig
+image-$(CONFIG_MPC8272_ADS) += cuImage.mpc8272ads
+image-$(CONFIG_PQ2FADS) += cuImage.pq2fads
+image-$(CONFIG_EP8248E) += zImage-dtb.ep8248e
+
+# Board ports in arch/powerpc/platform/83xx/Kconfig
+image-$(CONFIG_MPC832x_MDS) += cuImage.mpc832x_mds
+image-$(CONFIG_MPC832x_RDB) += cuImage.mpc832x_rdb
+image-$(CONFIG_MPC834x_ITX) += cuImage.mpc8349emitx \
+ cuImage.mpc8349emitxgp
+image-$(CONFIG_MPC834x_MDS) += cuImage.mpc834x_mds
+image-$(CONFIG_MPC836x_MDS) += cuImage.mpc836x_mds
+
+# Board ports in arch/powerpc/platform/85xx/Kconfig
+image-$(CONFIG_MPC8540_ADS) += cuImage.mpc8540ads
+image-$(CONFIG_MPC8560_ADS) += cuImage.mpc8560ads
+image-$(CONFIG_MPC85xx_CDS) += cuImage.mpc8541cds \
+ cuImage.mpc8548cds \
+ cuImage.mpc8555cds
+image-$(CONFIG_MPC85xx_MDS) += cuImage.mpc8568mds
+image-$(CONFIG_MPC85xx_DS) += cuImage.mpc8544ds \
+ cuImage.mpc8572ds
+image-$(CONFIG_TQM8540) += cuImage.tqm8540
+image-$(CONFIG_TQM8541) += cuImage.tqm8541
+image-$(CONFIG_TQM8555) += cuImage.tqm8555
+image-$(CONFIG_TQM8560) += cuImage.tqm8560
+image-$(CONFIG_SBC8548) += cuImage.tqm8548
+image-$(CONFIG_SBC8560) += cuImage.tqm8560
+
+# Board ports in arch/powerpc/platform/embedded6xx/Kconfig
+image-$(CONFIG_STORCENTER) += cuImage.storcenter
+image-$(CONFIG_MPC7448HPC2) += cuImage.mpc7448hpc2
# For 32-bit powermacs, build the COFF and miboot images
# as well as the ELF images.
@@ -233,24 +272,20 @@ targets += $(image-y) $(initrd-y)
$(addprefix $(obj)/, $(initrd-y)): $(obj)/ramdisk.image.gz
-# If CONFIG_WANT_DEVICE_TREE is set and CONFIG_DEVICE_TREE isn't an
-# empty string, define 'dts' to be path to the dts
-# CONFIG_DEVICE_TREE will have "" around it, make sure to strip them
-ifeq ($(CONFIG_WANT_DEVICE_TREE),y)
-ifneq ($(CONFIG_DEVICE_TREE),"")
-dts = $(if $(shell echo $(CONFIG_DEVICE_TREE) | grep '^/'),\
- ,$(srctree)/$(src)/dts/)$(CONFIG_DEVICE_TREE:"%"=%)
-endif
-endif
-
# Don't put the ramdisk on the pattern rule; when its missing make will try
# the pattern rule with less dependencies that also matches (even with the
# hard dependency listed).
-$(obj)/zImage.initrd.%: vmlinux $(wrapperbits) $(dts)
- $(call if_changed,wrap,$*,$(dts),,$(obj)/ramdisk.image.gz)
+$(obj)/zImage.initrd.%: vmlinux $(wrapperbits)
+ $(call if_changed,wrap,$*,,,$(obj)/ramdisk.image.gz)
-$(obj)/zImage.%: vmlinux $(wrapperbits) $(dts)
- $(call if_changed,wrap,$*,$(dts))
+$(obj)/zImage.%: vmlinux $(wrapperbits)
+ $(call if_changed,wrap,$*)
+
+$(obj)/zImage-dtb.initrd.%: vmlinux $(wrapperbits) $(dtstree)/%.dts
+ $(call if_changed,wrap,$*,$(dtstree)/$*.dts,,$(obj)/ramdisk.image.gz)
+
+$(obj)/zImage-dtb.%: vmlinux $(wrapperbits) $(dtstree)/%.dts
+ $(call if_changed,wrap,$*,$(dtstree)/$*.dts)
# This cannot be in the root of $(src) as the zImage rule always adds a $(obj)
# prefix
@@ -260,24 +295,17 @@ $(obj)/vmlinux.strip: vmlinux
$(obj)/zImage.iseries: vmlinux
$(STRIP) -s -R .comment $< -o $@
-$(obj)/zImage.ps3: vmlinux $(wrapper) $(wrapperbits) $(srctree)/$(src)/dts/ps3.dts
- $(STRIP) -s -R .comment $< -o vmlinux.strip
- $(call cmd,wrap,ps3,$(srctree)/$(src)/dts/ps3.dts,,)
-
-$(obj)/zImage.initrd.ps3: vmlinux $(wrapper) $(wrapperbits) $(srctree)/$(src)/dts/ps3.dts $(obj)/ramdisk.image.gz
- $(call cmd,wrap,ps3,$(srctree)/$(src)/dts/ps3.dts,,$(obj)/ramdisk.image.gz)
-
$(obj)/uImage: vmlinux $(wrapperbits)
$(call if_changed,wrap,uboot)
-$(obj)/cuImage.%: vmlinux $(dts) $(wrapperbits)
- $(call if_changed,wrap,cuboot-$*,$(dts))
+$(obj)/cuImage.%: vmlinux $(dtstree)/%.dts $(wrapperbits)
+ $(call if_changed,wrap,cuboot-$*,$(dtstree)/$*.dts)
-$(obj)/treeImage.initrd.%: vmlinux $(dts) $(wrapperbits)
- $(call if_changed,wrap,treeboot-$*,$(dts),,$(obj)/ramdisk.image.gz)
+$(obj)/treeImage.initrd.%: vmlinux $(dtstree)/%.dts $(wrapperbits)
+ $(call if_changed,wrap,treeboot-$*,$(dtstree)/$*.dts,,$(obj)/ramdisk.image.gz)
-$(obj)/treeImage.%: vmlinux $(dts) $(wrapperbits)
- $(call if_changed,wrap,treeboot-$*,$(dts))
+$(obj)/treeImage.%: vmlinux $(dtstree)/%.dts $(wrapperbits)
+ $(call if_changed,wrap,treeboot-$*,$(dtstree)/$*.dts)
# If there isn't a platform selected then just strip the vmlinux.
ifeq (,$(image-y))
diff --git a/arch/powerpc/boot/cuboot-hpc2.c b/arch/powerpc/boot/cuboot-hpc2.c
deleted file mode 100644
index 1b89532..0000000
--- a/arch/powerpc/boot/cuboot-hpc2.c
+++ /dev/null
@@ -1,48 +0,0 @@
-/*
- * Copyright (C) 2007 Freescale Semiconductor, Inc. All rights reserved.
- *
- * Author: Roy Zang <tie-fei.zang@freescale.com>
- *
- * Description:
- * Old U-boot compatibility for mpc7448hpc2 board
- * Based on the code of Scott Wood <scottwood@freescale.com>
- * for 83xx and 85xx.
- *
- * This 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.
- *
- */
-
-#include "ops.h"
-#include "stdio.h"
-#include "cuboot.h"
-
-#define TARGET_HAS_ETH1
-#include "ppcboot.h"
-
-static bd_t bd;
-extern char _dtb_start[], _dtb_end[];
-
-static void platform_fixups(void)
-{
- void *tsi;
-
- dt_fixup_memory(bd.bi_memstart, bd.bi_memsize);
- dt_fixup_mac_addresses(bd.bi_enetaddr, bd.bi_enet1addr);
- dt_fixup_cpu_clocks(bd.bi_intfreq, bd.bi_busfreq / 4, bd.bi_busfreq);
- tsi = find_node_by_devtype(NULL, "tsi-bridge");
- if (tsi)
- setprop(tsi, "bus-frequency", &bd.bi_busfreq,
- sizeof(bd.bi_busfreq));
-}
-
-void platform_init(unsigned long r3, unsigned long r4, unsigned long r5,
- unsigned long r6, unsigned long r7)
-{
- CUBOOT_INIT();
- fdt_init(_dtb_start);
- serial_console_init();
- platform_ops.fixups = platform_fixups;
-}
diff --git a/arch/powerpc/boot/cuboot-mpc7448hpc2.c b/arch/powerpc/boot/cuboot-mpc7448hpc2.c
new file mode 100644
index 0000000..1b89532
--- /dev/null
+++ b/arch/powerpc/boot/cuboot-mpc7448hpc2.c
@@ -0,0 +1,48 @@
+/*
+ * Copyright (C) 2007 Freescale Semiconductor, Inc. All rights reserved.
+ *
+ * Author: Roy Zang <tie-fei.zang@freescale.com>
+ *
+ * Description:
+ * Old U-boot compatibility for mpc7448hpc2 board
+ * Based on the code of Scott Wood <scottwood@freescale.com>
+ * for 83xx and 85xx.
+ *
+ * This 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.
+ *
+ */
+
+#include "ops.h"
+#include "stdio.h"
+#include "cuboot.h"
+
+#define TARGET_HAS_ETH1
+#include "ppcboot.h"
+
+static bd_t bd;
+extern char _dtb_start[], _dtb_end[];
+
+static void platform_fixups(void)
+{
+ void *tsi;
+
+ dt_fixup_memory(bd.bi_memstart, bd.bi_memsize);
+ dt_fixup_mac_addresses(bd.bi_enetaddr, bd.bi_enet1addr);
+ dt_fixup_cpu_clocks(bd.bi_intfreq, bd.bi_busfreq / 4, bd.bi_busfreq);
+ tsi = find_node_by_devtype(NULL, "tsi-bridge");
+ if (tsi)
+ setprop(tsi, "bus-frequency", &bd.bi_busfreq,
+ sizeof(bd.bi_busfreq));
+}
+
+void platform_init(unsigned long r3, unsigned long r4, unsigned long r5,
+ unsigned long r6, unsigned long r7)
+{
+ CUBOOT_INIT();
+ fdt_init(_dtb_start);
+ serial_console_init();
+ platform_ops.fixups = platform_fixups;
+}
diff --git a/arch/powerpc/boot/wrapper b/arch/powerpc/boot/wrapper
index 763a0c4..c317815 100755
--- a/arch/powerpc/boot/wrapper
+++ b/arch/powerpc/boot/wrapper
@@ -158,6 +158,29 @@ miboot|uboot)
cuboot*)
binary=y
gzip=
+ case "$platform" in
+ *-mpc885ads|*-adder875*|*-ep88xc)
+ platformo=$object/cuboot-8xx.o
+ ;;
+ *5200*|*-motionpro)
+ platformo=$object/cuboot-52xx.o
+ ;;
+ *-pq2fads|*-ep8248e|*-mpc8272*|*-storcenter)
+ platformo=$object/cuboot-pq2.o
+ ;;
+ *-mpc824*)
+ platformo=$object/cuboot-824x.o
+ ;;
+ *-mpc83*)
+ platformo=$object/cuboot-83xx.o
+ ;;
+ *-tqm8541|*-mpc8560*|*-tqm8560|*-tqm8555*)
+ platformo=$object/cuboot-85xx-cpm2.o
+ ;;
+ *-mpc85*)
+ platformo=$object/cuboot-85xx.o
+ ;;
+ esac
;;
ps3)
platformo="$object/ps3-head.o $object/ps3-hvcall.o $object/ps3.o"
^ permalink raw reply related
* RE: [Virtex4] kernel2.6 or distribution
From: Stephen Neuendorffer @ 2008-02-06 19:06 UTC (permalink / raw)
To: Desroches L., linuxppc-embedded
In-Reply-To: <15291528.post@talk.nabble.com>
> -----Original Message-----
> From: linuxppc-embedded-bounces+stephen=3Dneuendorffer.name@ozlabs.org =
[mailto:linuxppc-embedded-
> bounces+stephen=3Dneuendorffer.name@ozlabs.org] On Behalf Of Desroches =
L.
> Sent: Tuesday, February 05, 2008 7:49 AM
> To: linuxppc-embedded@ozlabs.org
> Subject: [Virtex4] kernel2.6 or distribution
>=20
>=20
> Hi,
>=20
> Sorry for my English, I am a French student. For my internship, I have =
to
> implement Linux on a Virtex4.
>=20
> I know a few things about the Virtex4 because I am specialized in =
digital
> electronic (VHDL). I have to choose a solution for the Linux to =
implement.
> At this stage, I have some problems to determine the best solution =
probably
> because things are not clear for me whereas I have read a book about =
Linux
> embedded and seen a lot of websites.
>=20
> I have seen several distributions (maybe my vocable is false) from
> MontaVista, LynuxWorks and others. I have seen also kernel2.6 for =
Virtex4
> =
(http://git.xilinx.com/cgi-bin/gitweb.cgi?p=3Dlinux-2.6-xlnx.git;a=3Dsumm=
ary). I
> would like to understand the difference between these two things.
The distributions contain kernel code that is heavily tested and stable, =
in addition to a toolchain, debuggers, rootfilesystem, etc. =
git.xilinx.com is just the kernel code, without anything else. =
git.xilinx.com also contains new code that is under development, rather =
than primarily stable code.
> If I have understood MontaVista for example offers a solution with a C
> library and drivers, isn't it ? So is it a better solution than =
kernel2.6 ?
'better' for what?
development of new code? yes, most distributions use older kernels.
building a sytem? Maybe... it depends on what features you need.
learning? Maybe... It depends on what you already know and what you want =
to learn.
> I prefer to start with the kernel given by xilinx, it is an internship =
so
> the aim is to learn the more I can but I have to convince my tutor =
that it
> is a better solution than MontaVista, BlueCat or =B5C/OSII. Do you =
have some
> arguments ?
>=20
> Thanks for your help
>=20
> Best Regards
>=20
> ---
>=20
> Desroches Ludovic
> ESIEE engineer : http://www.esiee.fr
>=20
>=20
> --
> View this message in context: =
http://www.nabble.com/-Virtex4--kernel2.6-or-distribution-
> tp15291528p15291528.html
> Sent from the linuxppc-embedded mailing list archive at Nabble.com.
>=20
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* RE: [Virtex 4 PPC] Which Linux?
From: Stephen Neuendorffer @ 2008-02-06 19:29 UTC (permalink / raw)
To: IngoM, linuxppc-embedded
In-Reply-To: <15268468.post@talk.nabble.com>
> -----Original Message-----
> From: linuxppc-embedded-bounces+stephen=3Dneuendorffer.name@ozlabs.org
[mailto:linuxppc-embedded-
> bounces+stephen=3Dneuendorffer.name@ozlabs.org] On Behalf Of IngoM
> Sent: Monday, February 04, 2008 5:55 AM
> To: linuxppc-embedded@ozlabs.org
> Subject: [Virtex 4 PPC] Which Linux?
>=20
>=20
> Hello,
>=20
> we develop a new laser-ranging-system and our hardware freaks have
choosen
> the Virtex 4 FX 12 on the "AVNET FX12 Mini-Module". The system had to
> deliver the raw data via UDP (12 Mbyte/sec) and on TCP the processed
data
> (about 6 Mbyte/sec). When you get the processed data via TCP then no
data
> send by UDP.
>=20
> I'm confused by the following:
>=20
> 1) Hard-TEMAC vs. Soft-TEMAC.
> Avnet provide a demo for the module which using Soft-TEMAC. If I get
it
> right this core has to be licenced. But when ther is a hard-TEMAC why
pay
> for it?
Generally speaking, if you have the hard temac, you should use it. The
new EDK cores do this transparently. (see
http://www.xilinx.com/bvdocs/ipcenter/data_sheet/xps_ll_temac.pdf) Note
that the emaclite license has recently been made free, although this
core doesn't support gigabit rates, which it looks like youll need.
Steve
^ permalink raw reply
* System Clock runaway on Xilinx platform
From: khollan @ 2008-02-06 19:41 UTC (permalink / raw)
To: linuxppc-embedded
Hi all,
Thanks for the help so far!
I'm now running linux 2.6.21 on my custom virtex 4 board modeled after the
ml410. The cpu clock is 300MHz and the PLB bus is 175MHz.
My question is which clock is the linux system clock that keeps track of the
date derived from? I set my date with rdate -s time.mit.edu at boot and
then compare with the date command and rdate -p time.mit.edu and they are
off by 20 or so seconds even just after a few minutes, this trend continues
and it will be off by a day after a few hours. I think I just don't have
something defined correctly but I can't figure out which.
Thanks
Kevin
--
View this message in context: http://www.nabble.com/System-Clock-runaway-on-Xilinx-platform-tp15312437p15312437.html
Sent from the linuxppc-embedded mailing list archive at Nabble.com.
^ permalink raw reply
* Re: System Clock runaway on Xilinx platform
From: Grant Likely @ 2008-02-06 20:29 UTC (permalink / raw)
To: khollan; +Cc: linuxppc-embedded
In-Reply-To: <15312437.post@talk.nabble.com>
On 2/6/08, khollan <khollan@daktronics.com> wrote:
>
> Hi all,
>
> Thanks for the help so far!
> I'm now running linux 2.6.21 on my custom virtex 4 board modeled after the
> ml410. The cpu clock is 300MHz and the PLB bus is 175MHz.
>
> My question is which clock is the linux system clock that keeps track of the
> date derived from? I set my date with rdate -s time.mit.edu at boot and
> then compare with the date command and rdate -p time.mit.edu and they are
> off by 20 or so seconds even just after a few minutes, this trend continues
> and it will be off by a day after a few hours. I think I just don't have
> something defined correctly but I can't figure out which.
The clock is maintained off of the PowerPC time base register (TBL,
TBU). On Virtex ppc platforms, the time base frequency is supposed to
be the same as the CPU clock. Can you figure out *exactly* how
quickly the clock is drifting?
How are you booting your Virtex platform? u-boot or a zImage.elf? If
it's a zImage, the CPU clock frequency is set in
arch/ppc/boot/simple/embed_config.c (search for CONFIG_XILINX and look
for the line that sets bd->bi_intfreq). Make XPAR_CORE_CLOCK_FREQ_HZ
in xparameters matches you CPU clock speed.
Side note: you may notice that bd->bi_tbfreq is also used but not set;
that's because bd->bi_intfreq and bd->tbfreq point to the same memory
location. (It's kind of messed up that way, don't worry too much
about it)
If you're using u-boot, then u-boot will set the cpu frequency in the
board info structure.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ 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