* Re: [PATCH]: [MPC5200] (v2) Add ATA DMA support
From: Grant Likely @ 2008-07-04 3:26 UTC (permalink / raw)
To: Tim Yamin; +Cc: linuxppc-dev
In-Reply-To: <792f5f410807030835q4589a27eh4b7d13e93e922a5e@mail.gmail.com>
On Thu, Jul 03, 2008 at 04:35:27PM +0100, Tim Yamin wrote:
> There's also what I believe to be a hardware bug if you have high levels
> of BestComm ATA DMA activity along with heavy LocalPlus Bus activity;
> the address bus seems to sometimes get corrupted with ATA commands while
> the LocalPlus Bus operation is still active (i.e. Chip Select is asserted).
>
> I've asked Freescale about this but have not received a reply yet -- if
> anybody from Freescale has any ideas please contact me; I can supply some
> analyzer traces if needed. Therefore, for now, do not enable DMA if you
> need reliable LocalPlus Bus unless you do a fixup in your driver as
> follows:
>
> Locking example:
>
> while (test_and_set_bit(0, &pata_mpc52xx_ata_dma_lock) != 0)
> {
> struct bcom_task_2 *tsk = pata_mpc52xx_ata_dma_task;
>
> if(bcom_buffer_done_2(tsk))
> return 1;
> }
>
> return 0;
>
> (Save the return value to `flags`)
>
> Unlocking example:
>
> if(flags == 0)
> clear_bit(0, &pata_mpc52xx_ata_dma_lock);
>
One more thing. For this description to be of any use, it needs to be
documented where somebody will actually see it. The commit message is
great for describing *why* a change is needed, but it's not seen
so much after the change is merged.
This description should probably be added to the header comment block of
the ATA driver, and it should be talked about in the Kconfig help text
too.
g.
^ permalink raw reply
* Re: [PATCH]: [MPC5200] (v2) Add ATA DMA support
From: Grant Likely @ 2008-07-04 3:20 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Tim Yamin, linuxppc-dev
In-Reply-To: <1215128823.7960.12.camel@pasglop>
On Fri, Jul 04, 2008 at 09:47:03AM +1000, Benjamin Herrenschmidt wrote:
> On Thu, 2008-07-03 at 16:35 +0100, Tim Yamin wrote:
> > >> +static void
> > >> +mpc52xx_bmdma_start(struct ata_queued_cmd *qc)
> > >> +{
> > >> + struct ata_port *ap = qc->ap;
> > >> + struct mpc52xx_ata_priv *priv = ap->host->private_data;
> > >> +
> > >> + /* LocalBus lock */
> > >> + while (test_and_set_bit(0, &pata_mpc52xx_ata_dma_lock) != 0)
> > >> + ;
> > >
> > > Need to be able to bail on timeout.
> >
> > A deadlock can't occur within the PATA driver because you won't have
> > two DMA requests happening at once, so there is no point in adding a
> > timeout. And even if you do have a timeout, you'd have to drop the I/O
> > request somehow, so it's not really a good idea. If anything else
> > needs to touch the DMA lock, it should do so in a sensible fashion...
>
> But why a hand-coded lock with bitops ? Why not a real spinlock then ?
> The later is more efficient anyway.
Umm, yeah.... (don't know why I didn't clue into that). This definitely
should be a spinlock.
g.
^ permalink raw reply
* Re: [PATCH v2] Change the default link address for pSeries zImage kernels.
From: Tony Breeds @ 2008-07-04 3:14 UTC (permalink / raw)
To: Olaf Hering; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <20080702150432.GA5910@aepfle.de>
On Wed, Jul 02, 2008 at 05:04:32PM +0200, Olaf Hering wrote:
> Setting real-base to what?
32Mb, or any other value big enough to allow the tftp to fit in
${real-base} - ${load-base}. I admitt it's far from ideal.
> What currently happens with a large boot file is:
> Firmware loads the zImage at load-base, finds that the ELF file is too
> large to fit into the memory window and stops.
>
> With your patch, firmware loads 12566528 bytes, and starts the zImage.
> The result is a truncated file, the initrd will be corrupted, kernel
> panic in populate_rootfs().
Okay that's not the behaviour I see here on the POWER4 machines, they
grab the firt n bytes (probabbly 12566528), and then abort with a
message about image being too large and it cannot be split.
(something akin to https://bugzilla.novell.com/show_bug.cgi?id=350212 )
> The only system where firmware relocates itself from 12MB to 32MB is a
> p640 with firmware version NAN04194.
> All other systems seem to ignore the NOTE section, real-base remains at
> 0xc00000
Add I thought /all/ POWER4 systems were unable to relocate OF
(regardless of whether the request is from the NOTE or from set-env
real-base).
> So I do not think your patch is a real improvement,
> clear error vs. silent corruption.
>
> Do you happen to know how to automate the changing the value of
> real-base? The addnote change has appearently no effect on recent
> systems.
It's there for POWER5 and on. I was sure that no POWER4 machines could
be reloacted, but you say that your p640 can.
Yours Tony
linux.conf.au http://www.marchsouth.org/
Jan 19 - 24 2009 The Australian Linux Technical Conference!
^ permalink raw reply
* Re: [PATCH 1/2] elf loader support for auxvec base platform string
From: Mikael Pettersson @ 2008-07-04 2:35 UTC (permalink / raw)
To: Nathan Lynch; +Cc: linuxppc-dev, Paul Mackerras, linux-kernel, Roland McGrath
In-Reply-To: <20080703234140.GC9594@localdomain>
Nathan Lynch writes:
> Some IBM POWER-based platforms have the ability to run in a
> mode which mostly appears to the OS as a different processor from the
> actual hardware. For example, a Power6 system may appear to be a
> Power5+, which makes the AT_PLATFORM value "power5+".
>
> However, some applications (virtual machines, optimized libraries) can
> benefit from knowledge of the underlying CPU model. A new aux vector
> entry, AT_BASE_PLATFORM, will denote the actual hardware. For
> example, on a Power6 system in Power5+ compatibility mode, AT_PLATFORM
> will be "power5+" and AT_BASE_PLATFORM will be "power6".
Why on earth would you ever want AT_PLATFORM to differ from AT_BASE_PLATFORM?
In cases that matter you admit that AT_BASE_PLATFORM takes precedence,
so why involve a fake lame not-quite-the-platform in the first place?
Workaround for buggy software?
^ permalink raw reply
* Re: [PATCH 1/2] elf loader support for auxvec base platform string
From: Roland McGrath @ 2008-07-04 2:19 UTC (permalink / raw)
To: Nathan Lynch; +Cc: linuxppc-dev, Paul Mackerras, linux-kernel
In-Reply-To: <20080703234140.GC9594@localdomain>
Why not just use ELF_HWCAP for this? It looks like powerpc only has 3 bits
left there (keeping it to 32), but 3 is not 0. If not that, why not use
dsocaps? That is, some magic in the vDSO, which glibc already supports on
all machines where it uses the vDSO. (For how it works, see the use in
arch/x86/vdso/vdso32/note.S for CONFIG_XEN.)
Thanks,
Roland
^ permalink raw reply
* Re: [Bugme-new] [Bug 11027] New: random forward time jumps
From: Andrew Morton @ 2008-07-04 2:02 UTC (permalink / raw)
To: Tony Breeds; +Cc: linuxppc-dev, Bligh, anton, Martin
In-Reply-To: <20080704015022.GV20457@bakeyournoodle.com>
On Fri, 4 Jul 2008 11:50:22 +1000 Tony Breeds <tony@bakeyournoodle.com> wrote:
> On Thu, Jul 03, 2008 at 05:59:32PM -0700, Andrew Morton wrote:
>
> > Nope, the only account matching .*ppc.* and .*power.* is
> > platform_ppc-32@kernel-bugs.osdl.org. (I have elevated bugzilla perms
> > so I can can query the users list) (everyone should have this - it's
> > handy).
> >
> > There is a category "Platform Specific/Hardware"/PPC-64. Those go to
> > anton@samba.org.
>
> Can you get this changed to platform_ppc-64@kernel-bugs.osdl.org
> (obvisouly this'll need to be created)?
>
> > There is a category "Platform Specific/Hardware"/PPC-62. Those go to
> > platform_ppc-32@kernel-bugs.osdl.org.
> >
> > So setting a watch on both those accounts would suit.
>
> Then the linuxppc-dev "person" can watch both of them. Seems slightly
> more "offical".
>
> > Or you can just ignore it all. I screen all bugzilla reports and will
> > ensure that suitable people know about them.
>
> Yeah we could but it'd be easier for you if we didn't :)
>
umm, Martin, can you please advise?
^ permalink raw reply
* Re: booting an ML405
From: David Baird @ 2008-07-04 2:02 UTC (permalink / raw)
To: Lorenzo T. Flores; +Cc: linuxppc-embedded
In-Reply-To: <486D774A.7000102@alphagolf.com>
On Thu, Jul 3, 2008 at 7:05 PM, Lorenzo T. Flores <lorenzo@alphagolf.com> wrote:
> I'm trying to compile the Xilinx patched kernel tree (v2.6.25-rc9) and run
> it on an ML405
>
> So far, I get to the following point in the boot sequence:
>
> loaded at: 00400000 005AF5A0
> board data at: 005AD524 005AD5A0
> relocated to: 00405058 004050D4
> zimage at: 00405E90 0051D6CC
> initrd at: 0051E000 005ACC0D
> avail ram: 005B0000 80000000
>
> Linux/PPC load: console=ttyS0,9600 ip=on root=/dev/ram rw
> Uncompressing Linux...done.
> Now booting the kernel
>
> The system hangs after it says "Now booting the kernel."
This seems to come up a lot, so I'm surprised you didn't find it in
the archives ;-)
Are you using uartlite? You'll need to change the "console" option if you are.
-David
^ permalink raw reply
* Re: [Bugme-new] [Bug 11027] New: random forward time jumps
From: Michael Ellerman @ 2008-07-04 1:54 UTC (permalink / raw)
To: Tony Breeds; +Cc: linuxppc-dev, Andrew Morton, anton
In-Reply-To: <20080704015022.GV20457@bakeyournoodle.com>
[-- Attachment #1: Type: text/plain, Size: 949 bytes --]
On Fri, 2008-07-04 at 11:50 +1000, Tony Breeds wrote:
> On Thu, Jul 03, 2008 at 05:59:32PM -0700, Andrew Morton wrote:
>
> > Nope, the only account matching .*ppc.* and .*power.* is
> > platform_ppc-32@kernel-bugs.osdl.org. (I have elevated bugzilla perms
> > so I can can query the users list) (everyone should have this - it's
> > handy).
> >
> > There is a category "Platform Specific/Hardware"/PPC-64. Those go to
> > anton@samba.org.
>
> Can you get this changed to platform_ppc-64@kernel-bugs.osdl.org
> (obvisouly this'll need to be created)?
Just to be clear, Anton will still fix all the bugs single-handedly in
his sleep .. we'll just be able to watch :)
cheers
--
Michael Ellerman
OzLabs, IBM Australia Development Lab
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [Bugme-new] [Bug 11027] New: random forward time jumps
From: Tony Breeds @ 2008-07-04 1:50 UTC (permalink / raw)
To: Andrew Morton; +Cc: linuxppc-dev, anton
In-Reply-To: <20080703175932.53ec7151.akpm@linux-foundation.org>
On Thu, Jul 03, 2008 at 05:59:32PM -0700, Andrew Morton wrote:
> Nope, the only account matching .*ppc.* and .*power.* is
> platform_ppc-32@kernel-bugs.osdl.org. (I have elevated bugzilla perms
> so I can can query the users list) (everyone should have this - it's
> handy).
>
> There is a category "Platform Specific/Hardware"/PPC-64. Those go to
> anton@samba.org.
Can you get this changed to platform_ppc-64@kernel-bugs.osdl.org
(obvisouly this'll need to be created)?
> There is a category "Platform Specific/Hardware"/PPC-62. Those go to
> platform_ppc-32@kernel-bugs.osdl.org.
>
> So setting a watch on both those accounts would suit.
Then the linuxppc-dev "person" can watch both of them. Seems slightly
more "offical".
> Or you can just ignore it all. I screen all bugzilla reports and will
> ensure that suitable people know about them.
Yeah we could but it'd be easier for you if we didn't :)
Yours Tony
linux.conf.au http://www.marchsouth.org/
Jan 19 - 24 2009 The Australian Linux Technical Conference!
^ permalink raw reply
* booting an ML405
From: Lorenzo T. Flores @ 2008-07-04 1:05 UTC (permalink / raw)
To: linuxppc-embedded
Hey all,
I did a little preliminary poking through the thread archives, but
didn't turn anything up. I anyone could just point me in the right
direction as far as troubleshooting, that would be great!
I'm trying to compile the Xilinx patched kernel tree (v2.6.25-rc9) and
run it on an ML405
So far, I get to the following point in the boot sequence:
loaded at: 00400000 005AF5A0
board data at: 005AD524 005AD5A0
relocated to: 00405058 004050D4
zimage at: 00405E90 0051D6CC
initrd at: 0051E000 005ACC0D
avail ram: 005B0000 80000000
Linux/PPC load: console=ttyS0,9600 ip=on root=/dev/ram rw
Uncompressing Linux...done.
Now booting the kernel
The system hangs after it says "Now booting the kernel."
Once again, any input would be appreciated.
thank you,
Lorenzo
^ permalink raw reply
* Re: Need stable 2.6 kernel for TQM823L
From: Thomas Maenner @ 2008-07-04 1:39 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-embedded
In-Reply-To: <20080703190440.GA3098@secretlab.ca>
On Thursday 03 July 2008 12:04:40 Grant Likely wrote:
> On Thu, Jul 03, 2008 at 11:59:29AM -0700, Thomas Maenner wrote:
> > > $ ls arch/powerpc/boot/dts/tqm*
> > > arch/powerpc/boot/dts/tqm5200.dts arch/powerpc/boot/dts/tqm8555.dts
> > > arch/powerpc/boot/dts/tqm8540.dts arch/powerpc/boot/dts/tqm8560.dts
> > > arch/powerpc/boot/dts/tqm8541.dts
> >
> > however, I found config files in the ppc tree:
> > ls arch/ppc/configs/TQM8*
> > arch/ppc/configs/TQM823L_defconfig
> > arch/ppc/configs/TQM850L_defconfig
> > arch/ppc/configs/TQM8260_defconfig
> > arch/ppc/configs/TQM860L_defconfig
> >
> > Is this stuff still working?
> > Do I still need to create a device tree?
>
> arch/ppc is depreciated and will disappear in 2.6.27. I don't know if
> anyone is actively keeping 8xx support working in arch/ppc so you may
> experience significant breakage.
>
> g.
Not exactly what I was hoping to hear...
What are the reasons to not port these TQs to 2.6?
Lack of resources? Not enough interest?
Thanks again
Tom
--
Linux hackers are funny people: They count the time in patchlevels
--
Thomas Maenner
E-Mail: mailto:tmaenner@aehr.com
^ permalink raw reply
* Re: [Bugme-new] [Bug 11027] New: random forward time jumps
From: Andrew Morton @ 2008-07-04 0:59 UTC (permalink / raw)
To: michael; +Cc: linuxppc-dev
In-Reply-To: <1215132417.7849.2.camel@localhost>
On Fri, 04 Jul 2008 10:46:57 +1000 Michael Ellerman <michael@ellerman.id.au> wrote:
> On Wed, 2008-07-02 at 11:06 -0700, Andrew Morton wrote:
> > On Wed, 2 Jul 2008 10:49:59 -0700 (PDT) bugme-daemon@bugzilla.kernel.org wrote:
> >
> > > http://bugzilla.kernel.org/show_bug.cgi?id=11027
> >
> > Hopefully someone in ppc land has set a watch on
> > platform_ppc-32@kernel-bugs.osdl.org?
> >
> > If not, please go to http://bugzilla.kernel.org/userprefs.cgi?tab=email
> > and enter platform_ppc-32@kernel-bugs.osdl.org into the "Users to watch:"
> > box.
>
> Is there a 64-bit equivalent? The obvious address didn't work.
Nope, the only account matching .*ppc.* and .*power.* is
platform_ppc-32@kernel-bugs.osdl.org. (I have elevated bugzilla perms
so I can can query the users list) (everyone should have this - it's
handy).
There is a category "Platform Specific/Hardware"/PPC-64. Those go to
anton@samba.org.
There is a category "Platform Specific/Hardware"/PPC-62. Those go to
platform_ppc-32@kernel-bugs.osdl.org.
So setting a watch on both those accounts would suit.
Or you can just ignore it all. I screen all bugzilla reports and will
ensure that suitable people know about them.
^ permalink raw reply
* Re: [Bugme-new] [Bug 11027] New: random forward time jumps
From: Michael Ellerman @ 2008-07-04 0:46 UTC (permalink / raw)
To: Andrew Morton; +Cc: linuxppc-dev
In-Reply-To: <20080702110614.4bd45cce.akpm@linux-foundation.org>
[-- Attachment #1: Type: text/plain, Size: 787 bytes --]
On Wed, 2008-07-02 at 11:06 -0700, Andrew Morton wrote:
> On Wed, 2 Jul 2008 10:49:59 -0700 (PDT) bugme-daemon@bugzilla.kernel.org wrote:
>
> > http://bugzilla.kernel.org/show_bug.cgi?id=11027
>
> Hopefully someone in ppc land has set a watch on
> platform_ppc-32@kernel-bugs.osdl.org?
>
> If not, please go to http://bugzilla.kernel.org/userprefs.cgi?tab=email
> and enter platform_ppc-32@kernel-bugs.osdl.org into the "Users to watch:"
> box.
Is there a 64-bit equivalent? The obvious address didn't work.
cheers
--
Michael Ellerman
OzLabs, IBM Australia Development Lab
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: More commits added to powerpc.git master and powerpc-next branches
From: Michael Neuling @ 2008-07-04 0:17 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, sonnyrao
In-Reply-To: <18540.41013.722932.726273@cargo.ozlabs.ibm.com>
> Paul.
>
> Kumar Gala (2):
> powerpc: Fix building of feature-fixup tests on ppc32
> powerpc: Fixup lwsync at runtime
>
> Michael Neuling (3):
> powerpc: Fix compile warning in init_thread
> powerpc: Clean up copy_to/from_user for vsx and fpr
> powerpc: Remove old dump_task_* functions
>
> Nathan Fontenot (5):
> powerpc/pseries: Allow phandle to be specified in formats other than de
cimal
> powerpc/pseries: Use base address to derive starting page frame number
> powerpc/pseries: Update the device tree correctly for drconf memory add
/remove
> powerpc/pseries: Split code into helper routines for drconf memory
> powerpc/pseries: Update numa association of hotplug memory add for drco
nf memory
>
> Tony Breeds (1):
> powerpc: Fix building of arch/powerpc/mm/mem.o when MEMORY_HOTPLUG=y an
d SPARSEMEM=n
Paulus,
Can you apply Sonny's BSR patch?
http://patchwork.ozlabs.org/linuxppc/patch?q=sonny&id=19036
Mikey
^ permalink raw reply
* Re: Full Linux distributions
From: Daniel Stonier @ 2008-07-03 23:59 UTC (permalink / raw)
To: Brian Silverman; +Cc: linuxppc-embedded
In-Reply-To: <486D32A7.7080007@conceptxdesign.com>
On 04/07/2008, Brian Silverman <bsilverman@conceptxdesign.com> wrote:
>
> Thanks for your response...
>
> Leon Woestenberg wrote:
>
> - is binary compatible with the PPC405. 440, and Freescale 85xx cores.
>
> binary compatible? You mean it can build binaries for those cores?
>
> What I meant (but said poorly) was that it has pre-compiled binaries. But
> its fine if I can build it under cygwin. And I am thinking that I may drop
> the cygwin requirement, because its painful to do linux builds under it.
>
> My preference is to use OpenEmbedded and do so under a Linux host
> system (any will do).
> As I don't want to be tied to a certain host OS, Emdebian or
> Gentoo-Embedded are no-go for me.
>
> I have used tools and rootfs systems like crosstool, buildroot, LFS before.
>
> There is also LTIB by Freescale, tried that?
>
> I need to look closer at LITB - but I was guessing it didn't have PPC4xx
> support.
>
> Thanks!
> --
> Brian Silverman
> Concept X, LLC
I've been using the ELDK for an amcc440EP ppc board. It's turned out
to be rather convenient, especially when running a networked
environment. The guy who primarily maintains it is very helpful also.
^ permalink raw reply
* Re: [PATCH]: [MPC5200] (v2) Add ATA DMA support
From: Benjamin Herrenschmidt @ 2008-07-03 23:47 UTC (permalink / raw)
To: Tim Yamin; +Cc: linuxppc-dev
In-Reply-To: <792f5f410807030835q4589a27eh4b7d13e93e922a5e@mail.gmail.com>
On Thu, 2008-07-03 at 16:35 +0100, Tim Yamin wrote:
> >> +static void
> >> +mpc52xx_bmdma_start(struct ata_queued_cmd *qc)
> >> +{
> >> + struct ata_port *ap = qc->ap;
> >> + struct mpc52xx_ata_priv *priv = ap->host->private_data;
> >> +
> >> + /* LocalBus lock */
> >> + while (test_and_set_bit(0, &pata_mpc52xx_ata_dma_lock) != 0)
> >> + ;
> >
> > Need to be able to bail on timeout.
>
> A deadlock can't occur within the PATA driver because you won't have
> two DMA requests happening at once, so there is no point in adding a
> timeout. And even if you do have a timeout, you'd have to drop the I/O
> request somehow, so it's not really a good idea. If anything else
> needs to touch the DMA lock, it should do so in a sensible fashion...
But why a hand-coded lock with bitops ? Why not a real spinlock then ?
The later is more efficient anyway.
Ben.
^ permalink raw reply
* Re: Support for low power mode for powerpc processors
From: Benjamin Herrenschmidt @ 2008-07-03 23:42 UTC (permalink / raw)
To: prodyut hazarika; +Cc: linuxppc-dev
In-Reply-To: <49c0ff980807031252w2c01406dk63bd7d932db37720@mail.gmail.com>
On Thu, 2008-07-03 at 12:52 -0700, prodyut hazarika wrote:
> But a lot of SoC like 440GT/EX support two modes of power save -
> - Cut off power to other cores like PCIExpress/USB/MAC/UART etc
> - Lower the CPU frequency
>
> Is it possible to scale down CPU freq or cut off power to unused cores
> while the CPU is idle? The ideal way would be that the SoC registers a
> set of handlers to the Kernel that can power off/up the SoC components
> or reduce/restore CPU frequency. Does any such framework exist for
> PowerPC processors, because most PowerPC based SoC (FreeScale/AMCC
> etc) support the above two modes of power save.
Cutting off power to individual cores should be done by the drivers for
those cores (let's call the devices). For example, the USB driver could
cut of power when nothing is connected, though I'm not sure if it can do
that without losing the ability to detect new connections, but then, USB
has a suspend state that should make it mostly unnecessary. For the
UART, you may lose the ability to receive.
At the end of the day, if you don't use at all a core, disable it from
your firmware and set it as unused in the device-tree.
Ben.
^ permalink raw reply
* [PATCH 2/2] enable AT_BASE_PLATFORM aux vector for powerpc
From: Nathan Lynch @ 2008-07-03 23:42 UTC (permalink / raw)
To: linux-kernel; +Cc: linuxppc-dev, Paul Mackerras, McGrath, Roland
Stash the first platform string matched by identify_cpu() in
powerpc_base_platform, and supply that to the ELF loader for the value
of AT_BASE_PLATFORM.
Signed-off-by: Nathan Lynch <ntl@pobox.com>
---
Note: I wasn't sure how to pick the index value for AT_BASE_PLATFORM;
I simply searched include/ for all AT_ values and added 1 to the
highest value found.
arch/powerpc/kernel/cputable.c | 11 +++++++++++
include/asm-powerpc/auxvec.h | 3 +++
include/asm-powerpc/cputable.h | 2 ++
include/asm-powerpc/elf.h | 8 ++++++++
4 files changed, 24 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/kernel/cputable.c b/arch/powerpc/kernel/cputable.c
index a9c90be..f1eb632 100644
--- a/arch/powerpc/kernel/cputable.c
+++ b/arch/powerpc/kernel/cputable.c
@@ -23,6 +23,9 @@
struct cpu_spec* cur_cpu_spec = NULL;
EXPORT_SYMBOL(cur_cpu_spec);
+/* The platform string corresponding to the real PVR */
+const char *powerpc_base_platform;
+
/* NOTE:
* Unlike ppc32, ppc64 will only call this once for the boot CPU, it's
* the responsibility of the appropriate CPU save/restore functions to
@@ -1620,6 +1623,14 @@ struct cpu_spec * __init identify_cpu(unsigned long offset, unsigned int pvr)
} else
*t = *s;
*PTRRELOC(&cur_cpu_spec) = &the_cpu_spec;
+
+ /*
+ * Set the base platform string once; assumes
+ * we're called with real pvr first.
+ */
+ if (powerpc_base_platform == NULL)
+ powerpc_base_platform = t->platform;
+
#if defined(CONFIG_PPC64) || defined(CONFIG_BOOKE)
/* ppc64 and booke expect identify_cpu to also call
* setup_cpu for that processor. I will consolidate
diff --git a/include/asm-powerpc/auxvec.h b/include/asm-powerpc/auxvec.h
index 19a099b..507f081 100644
--- a/include/asm-powerpc/auxvec.h
+++ b/include/asm-powerpc/auxvec.h
@@ -16,4 +16,7 @@
*/
#define AT_SYSINFO_EHDR 33
+/* The actual hardware platform; may differ from AT_PLATFORM */
+#define AT_BASE_PLATFORM 38
+
#endif
diff --git a/include/asm-powerpc/cputable.h b/include/asm-powerpc/cputable.h
index a9c1de3..527152f 100644
--- a/include/asm-powerpc/cputable.h
+++ b/include/asm-powerpc/cputable.h
@@ -125,6 +125,8 @@ extern struct cpu_spec *identify_cpu(unsigned long offset, unsigned int pvr);
extern void do_feature_fixups(unsigned long value, void *fixup_start,
void *fixup_end);
+extern const char *powerpc_base_platform;
+
#endif /* __ASSEMBLY__ */
/* CPU kernel features */
diff --git a/include/asm-powerpc/elf.h b/include/asm-powerpc/elf.h
index 38a5172..ff0c947 100644
--- a/include/asm-powerpc/elf.h
+++ b/include/asm-powerpc/elf.h
@@ -237,6 +237,14 @@ extern int dump_task_altivec(struct task_struct *, elf_vrregset_t *vrregs);
#define ELF_PLATFORM (cur_cpu_spec->platform)
+/* While ELF_PLATFORM indicates the ISA supported by the platform, it
+ * may not accurately reflect the underlying behavior of the hardware
+ * (as in the case of running in Power5+ compatibility mode on a
+ * Power6 machine). ELF_BASE_PLATFORM allows ld.so to load libraries
+ * that are tuned for the real hardware.
+ */
+#define ELF_BASE_PLATFORM (powerpc_base_platform)
+
#ifdef __powerpc64__
# define ELF_PLAT_INIT(_r, load_addr) do { \
_r->gpr[2] = load_addr; \
--
1.5.5.1
^ permalink raw reply related
* [PATCH 1/2] elf loader support for auxvec base platform string
From: Nathan Lynch @ 2008-07-03 23:41 UTC (permalink / raw)
To: linux-kernel; +Cc: linuxppc-dev, Paul Mackerras, McGrath, Roland
Some IBM POWER-based platforms have the ability to run in a
mode which mostly appears to the OS as a different processor from the
actual hardware. For example, a Power6 system may appear to be a
Power5+, which makes the AT_PLATFORM value "power5+".
However, some applications (virtual machines, optimized libraries) can
benefit from knowledge of the underlying CPU model. A new aux vector
entry, AT_BASE_PLATFORM, will denote the actual hardware. For
example, on a Power6 system in Power5+ compatibility mode, AT_PLATFORM
will be "power5+" and AT_BASE_PLATFORM will be "power6".
If the architecture has defined ELF_BASE_PLATFORM, copy that value to
the user stack in the same manner as ELF_PLATFORM.
Signed-off-by: Nathan Lynch <ntl@pobox.com>
---
Next patch implements ELF/AT_BASE_PLATFORM for powerpc.
fs/binfmt_elf.c | 23 +++++++++++++++++++++++
1 files changed, 23 insertions(+), 0 deletions(-)
diff --git a/fs/binfmt_elf.c b/fs/binfmt_elf.c
index d48ff5f..834c2c4 100644
--- a/fs/binfmt_elf.c
+++ b/fs/binfmt_elf.c
@@ -131,6 +131,10 @@ static int padzero(unsigned long elf_bss)
#define STACK_ALLOC(sp, len) ({ sp -= len ; sp; })
#endif
+#ifndef ELF_BASE_PLATFORM
+#define ELF_BASE_PLATFORM NULL
+#endif
+
static int
create_elf_tables(struct linux_binprm *bprm, struct elfhdr *exec,
unsigned long load_addr, unsigned long interp_load_addr)
@@ -142,7 +146,9 @@ create_elf_tables(struct linux_binprm *bprm, struct elfhdr *exec,
elf_addr_t __user *envp;
elf_addr_t __user *sp;
elf_addr_t __user *u_platform;
+ elf_addr_t __user *u_base_platform;
const char *k_platform = ELF_PLATFORM;
+ const char *k_base_platform = ELF_BASE_PLATFORM;
int items;
elf_addr_t *elf_info;
int ei_index = 0;
@@ -172,6 +178,19 @@ create_elf_tables(struct linux_binprm *bprm, struct elfhdr *exec,
return -EFAULT;
}
+ /*
+ * If this architecture has a "base" platform capability
+ * string, copy it to userspace.
+ */
+ u_base_platform = NULL;
+ if (k_base_platform) {
+ size_t len = strlen(k_base_platform) + 1;
+
+ u_base_platform = (elf_addr_t __user *)STACK_ALLOC(p, len);
+ if (__copy_to_user(u_base_platform, k_base_platform, len))
+ return -EFAULT;
+ }
+
/* Create the ELF interpreter info */
elf_info = (elf_addr_t *)current->mm->saved_auxv;
/* update AT_VECTOR_SIZE_BASE if the number of NEW_AUX_ENT() changes */
@@ -208,6 +227,10 @@ create_elf_tables(struct linux_binprm *bprm, struct elfhdr *exec,
NEW_AUX_ENT(AT_PLATFORM,
(elf_addr_t)(unsigned long)u_platform);
}
+ if (k_base_platform) {
+ NEW_AUX_ENT(AT_BASE_PLATFORM,
+ (elf_addr_t)(unsigned long)u_base_platform);
+ }
if (bprm->interp_flags & BINPRM_FLAGS_EXECFD) {
NEW_AUX_ENT(AT_EXECFD, bprm->interp_data);
}
--
1.5.5.1
^ permalink raw reply related
* Re: [patch 0/6] Strong Access Ordering page attributes for POWER7
From: Benjamin Herrenschmidt @ 2008-07-03 23:39 UTC (permalink / raw)
To: shaggy; +Cc: linux-mm, Andrew Morton, Paul Mackerras, Linuxppc-dev
In-Reply-To: <20080618223254.966080905@linux.vnet.ibm.com>
On Wed, 2008-06-18 at 17:32 -0500, shaggy@linux.vnet.ibm.com wrote:
> Andrew,
>
> The first patch in this series hits architecture independent code, but the
> rest is contained in the powerpc subtree. Could you pick up the first
> patch into -mm? I can send the rest of them through the powerpc git tree.
> The first patch and the rest of the set are independent and can be merged
> in either order.
../..
I was wondering... how do we inform userspace that this is available ?
Same question with adding the endian bit on 4xx which I plan to do using
your infrastructure...
We haven't defined a user-visible feature bit (and besides, we're really
getting short on these...). This is becoming a bit of concern btw (the
running out of bits). Maybe we should start defining an AT_HWCAP2 for
powerpc and get libc updated to pick it up ?
Ben.
^ permalink raw reply
* Re: New fsl device bindings file
From: Paul Mackerras @ 2008-07-03 23:36 UTC (permalink / raw)
To: avorontsov; +Cc: linuxppc-dev list
In-Reply-To: <20080703185312.GA6043@polina.dev.rtsoft.ru>
Anton Vorontsov writes:
> Just curious... why we're maintaining documentation in the .txt file?
> We could just create Documentation/powerpc/fsl-device-tree-bindings.dts
> file, that will be:
>
> 1. True device tree source file;
> 2. With a lots of comments for documentation purposes;
> 3. Could be compiled (via imaginable dts-doxygen) into .txt or nice .pdf
> file and printed :-), exactly as we do with kerneldoc.
I suspect that will be harder to follow for people that are unfamiliar
with device trees...
Paul.
^ permalink raw reply
* [PATCH] Add PPC_FEATURE_PMU_COMPAT
From: Nathan Lynch @ 2008-07-03 23:20 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Paul Mackerras
Beginning with Power6, there is a set of 32 PMU events which is
compatible across POWER processor lines. PPC_FEATURE_PMU_COMPAT
indicates support for this subset.
Signed-off-by: Nathan Lynch <ntl@pobox.com>
---
arch/powerpc/kernel/cputable.c | 4 ++--
include/asm-powerpc/cputable.h | 1 +
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/kernel/cputable.c b/arch/powerpc/kernel/cputable.c
index 817cea1..a9c90be 100644
--- a/arch/powerpc/kernel/cputable.c
+++ b/arch/powerpc/kernel/cputable.c
@@ -70,10 +70,10 @@ extern void __restore_cpu_power7(void);
PPC_FEATURE_SMT | PPC_FEATURE_ICACHE_SNOOP)
#define COMMON_USER_POWER6 (COMMON_USER_PPC64 | PPC_FEATURE_ARCH_2_05 |\
PPC_FEATURE_SMT | PPC_FEATURE_ICACHE_SNOOP | \
- PPC_FEATURE_TRUE_LE)
+ PPC_FEATURE_TRUE_LE | PPC_FEATURE_PMU_COMPAT)
#define COMMON_USER_POWER7 (COMMON_USER_PPC64 | PPC_FEATURE_ARCH_2_06 |\
PPC_FEATURE_SMT | PPC_FEATURE_ICACHE_SNOOP | \
- PPC_FEATURE_TRUE_LE)
+ PPC_FEATURE_TRUE_LE | PPC_FEATURE_PMU_COMPAT)
#define COMMON_USER_PA6T (COMMON_USER_PPC64 | PPC_FEATURE_PA6T |\
PPC_FEATURE_TRUE_LE | \
PPC_FEATURE_HAS_ALTIVEC_COMP)
diff --git a/include/asm-powerpc/cputable.h b/include/asm-powerpc/cputable.h
index 4e4491c..a9c1de3 100644
--- a/include/asm-powerpc/cputable.h
+++ b/include/asm-powerpc/cputable.h
@@ -26,6 +26,7 @@
#define PPC_FEATURE_POWER6_EXT 0x00000200
#define PPC_FEATURE_ARCH_2_06 0x00000100
#define PPC_FEATURE_HAS_VSX 0x00000080
+#define PPC_FEATURE_PMU_COMPAT 0x00000040
#define PPC_FEATURE_TRUE_LE 0x00000002
#define PPC_FEATURE_PPC_LE 0x00000001
--
1.5.5.1
^ permalink raw reply related
* Re: gianfar in SGMII mode
From: Andy Fleming @ 2008-07-03 23:14 UTC (permalink / raw)
To: Nate Case; +Cc: linuxppc-dev
In-Reply-To: <1215098611.7559.551.camel@localhost.localdomain>
On Jul 3, 2008, at 10:23, Nate Case wrote:
> On Wed, 2008-07-02 at 17:53 -0500, Nate Case wrote:
>> I'm looking at gfar_configure_serdes() and I'm at a loss as to why
>> this
>> is always called when the MAC is in SGMII mode. It looks like it
>> assumes the use of TBI for some reason. On my board it's just a
>> regular
>> SGMII interface to a bcm5482 PHY in SGMII mode, so there is no TBI
>> involved.
>>
>> I'm guessing this is a case of the driver making incorrect
>> assumptions
>> based on the existing Freescale boards. Or am I missing something
>> here?
>
> Answering my own question: I see now that TBI is used internally on
> the
> chip for the SerDes interface which implements SGMII.. so maybe
> there's
> no problem with what the driver is doing after all.
Yeah, it's screwy, but that's how the chip works.
Andy
^ permalink raw reply
* Re: Linux on ML403 serial console problem
From: Grant Likely @ 2008-07-03 21:58 UTC (permalink / raw)
To: Anand Kumar S; +Cc: linuxppc-embedded
In-Reply-To: <66E8AEE9980BB44CA5FCAD39EBA56AC604A5F1DF@CHN-HCLT-EVS02.HCLT.CORP.HCL.IN>
On Thu, Jul 03, 2008 at 03:42:21PM +0530, Anand Kumar S wrote:
> Any help is greatly appreciated as I am really struggling with this
> problem for the past 3 days. Given below is the output from serial port.
> I do not have FB support or VT or VT console
>
> Support enabled. Only SERIAL console support is enabled i.e
> SERIAL_CORE_CONSOLE/SERIAL_8250_CONSOLE support is enabled
>
You kernel output log is incomplete. Please repost the entire output
from the serial port. (I'm expecting to see the kernel command line).
g.
>
>
> ......
>
> ......
>
> Serial: 8250/16550 driver $Revision: 1.90 $ 5 ports, IRQ sharing
> disabled
>
> Registering platform device 'serial8250'. Parent at platform
>
> ttyS0 at MMIO 0x0 (irq = 9) is a 16550A
>
> io scheduler noop registered
>
> io scheduler anticipatory registered
>
> io scheduler deadline registered
>
> io scheduler cfq registered
>
> RAMDISK driver initialized: 16 RAM disks of 8192K size 1024 blocksize
>
> loop: loaded (max 8 devices)
>
> PPP generic driver version 2.4.2
>
> PPP Deflate Compression module registered
>
> NET: Registered protocol family 24
>
> xemac 0: using fifo mode.
>
> eth0: Xilinx EMAC #0 at 81000000 mapped to 0xC30C0000, irq=0
>
> i2c /dev entries driver
>
> xilinx_iic.0 #0 at 0x81600000 mapped to 0xC30E0000, irq=6
>
> mice: PS/2 mouse device common for all mice
>
> NET: Registered protocol family 2
>
> IP: routing cache hash table of 512 buckets, 4Kbytes
>
> TCP: Hash tables configured (established 2048 bind 4096)
>
> NET: Registered protocol family 1
>
> NET: Registered protocol family 17
>
> interrupts enabled
>
> TX interrupts enabled. register baseaddr c30c0000 offset 7fc is 8
>
> TX interrupts enabled. register baseaddr c30c0000 offset ffc is 0
>
> RX interrupts enabled. register baseaddr c30c0000 offset 17fc is 9
>
> RX interrupts enabled. register baseaddr c30c0000 offset 1ffc is 0
>
> GIER interrupts enabled. register baseaddr c30c0000 offset 7f8 is
> 80000000
>
> Sending DHCP requests .,... OK
>
> IP-Config: Got DHCP answer from 0.0.0.0, my address is 10.100.12.132
>
> IP-Config: Complete:
>
> device=eth0, addr=10.100.12.132, mask=255.255.255.0,
> gw=10.100.12.1,
>
> host=10.100.12.132, domain=hclt.corp.hcl.in, nis-domain=(none),
>
> bootserver=0.0.0.0, rootserver=0.0.0.0, rootpath=
>
> RAMDISK: Compressed image found at block 0
>
> VFS: Mounted root (ext2 filesystem).
>
> Freeing unused kernel memory: 124k init
>
> done freeing memory. creating console
>
> console created
>
> running process /bin/test
>
> in tty_write
>
> before calling write. buf contents h e l
>
> core write
>
> core write
>
> core write
>
> Kernel panic - not syncing: Attempted to kill init!
>
> <0>Rebooting in 180 seconds..<NULL>
>
>
>
>
>
> DISCLAIMER:
> -----------------------------------------------------------------------------------------------------------------------
>
> The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only.
> It shall not attach any liability on the originator or HCL or its affiliates. Any views or opinions presented in
> this email are solely those of the author and may not necessarily reflect the opinions of HCL or its affiliates.
> Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of
> this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have
> received this email in error please delete it and notify the sender immediately. Before opening any mail and
> attachments please check them for viruses and defect.
>
> -----------------------------------------------------------------------------------------------------------------------
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* Re: Linux on ML403 serial console problem
From: John Bonesio @ 2008-07-03 21:43 UTC (permalink / raw)
To: Anand Kumar S; +Cc: linuxppc-embedded
In-Reply-To: <66E8AEE9980BB44CA5FCAD39EBA56AC604A5F1DF@CHN-HCLT-EVS02.HCLT.CORP.HCL.IN>
[-- Attachment #1: Type: text/plain, Size: 6228 bytes --]
Hi,
I don't have a clear idea about this, but it seems to me that there's
probably something in your root filesystem that is causing output to be
directed to a different console that the serial console. Maybe it's
using the wrong getty program.
- John
On Thu, 2008-07-03 at 15:42 +0530, Anand Kumar S wrote:
> Hi,
>
>
>
> I am using MVL 4.0.1 to boot on ML403 board. I have created the
> xparameters.h file using EDK 10.1 and I was able to boot the kernel
> with 32 MB of memory and UART set as std 16550 uart.
>
> Since this board came without sysace flash card I am using ramdisk
> technique to boot linux. I created a small ramdisk with my test
> program which sleeps for 10 seconds and prints a hello
>
> world using printf. I modified kernel init/main.c to execute /bin/test
> (my test program) from the RAMDISK. I created the ramdisk and appended
> with zImage using make zImage.initrd command
>
>
>
> I used dow method from xmd to download the zImage.initrd.elf on the
> board and I was able to boot the board till the point of executing
> my /bin/test. However I see that the print statements
>
> from my test program are not coming on the serial port. I see that the
> printf calls tty_io write and it goes to uart_write routine in
> serial_core.c, however I am not able to see my prints on
>
> the hyperterminal. I can see all the kernel printks except for this
> printf statement from my user program. Also all the kernel printks
> seem to call serial_8250_console write routine but the
>
> user application seems to call the uart_write routine. Does someone
> have any idea about what might be going wrong here? Is it something to
> do with serial console settings ?
>
>
>
> Any help is greatly appreciated as I am really struggling with this
> problem for the past 3 days. Given below is the output from serial
> port. I do not have FB support or VT or VT console
>
> Support enabled. Only SERIAL console support is enabled i.e
> SERIAL_CORE_CONSOLE/SERIAL_8250_CONSOLE support is enabled
>
>
>
> …..
>
> …..
>
> Serial: 8250/16550 driver $Revision: 1.90 $ 5 ports, IRQ sharing
> disabled
>
> Registering platform device 'serial8250'. Parent at platform
>
> ttyS0 at MMIO 0x0 (irq = 9) is a 16550A
>
> io scheduler noop registered
>
> io scheduler anticipatory registered
>
> io scheduler deadline registered
>
> io scheduler cfq registered
>
> RAMDISK driver initialized: 16 RAM disks of 8192K size 1024 blocksize
>
> loop: loaded (max 8 devices)
>
> PPP generic driver version 2.4.2
>
> PPP Deflate Compression module registered
>
> NET: Registered protocol family 24
>
> xemac 0: using fifo mode.
>
> eth0: Xilinx EMAC #0 at 81000000 mapped to 0xC30C0000, irq=0
>
> i2c /dev entries driver
>
> xilinx_iic.0 #0 at 0x81600000 mapped to 0xC30E0000, irq=6
>
> mice: PS/2 mouse device common for all mice
>
> NET: Registered protocol family 2
>
> IP: routing cache hash table of 512 buckets, 4Kbytes
>
> TCP: Hash tables configured (established 2048 bind 4096)
>
> NET: Registered protocol family 1
>
> NET: Registered protocol family 17
>
> interrupts enabled
>
> TX interrupts enabled. register baseaddr c30c0000 offset 7fc is 8
>
> TX interrupts enabled. register baseaddr c30c0000 offset ffc is 0
>
> RX interrupts enabled. register baseaddr c30c0000 offset 17fc is 9
>
> RX interrupts enabled. register baseaddr c30c0000 offset 1ffc is 0
>
> GIER interrupts enabled. register baseaddr c30c0000 offset 7f8 is
> 80000000
>
> Sending DHCP requests .,... OK
>
> IP-Config: Got DHCP answer from 0.0.0.0, my address is 10.100.12.132
>
> IP-Config: Complete:
>
> device=eth0, addr=10.100.12.132, mask=255.255.255.0,
> gw=10.100.12.1,
>
> host=10.100.12.132, domain=hclt.corp.hcl.in, nis-domain=(none),
>
> bootserver=0.0.0.0, rootserver=0.0.0.0, rootpath=
>
> RAMDISK: Compressed image found at block 0
>
> VFS: Mounted root (ext2 filesystem).
>
> Freeing unused kernel memory: 124k init
>
> done freeing memory. creating console
>
> console created
>
> running process /bin/test
>
> in tty_write
>
> before calling write. buf contents h e l
>
> core write
>
> core write
>
> core write
>
> Kernel panic - not syncing: Attempted to kill init!
>
> <0>Rebooting in 180 seconds..<NULL>
>
>
>
>
>
> DISCLAIMER:
> -----------------------------------------------------------------------------------------------------------------------
>
> The contents of this e-mail and any attachment(s) are confidential and
> intended for the named recipient(s) only.
> It shall not attach any liability on the originator or HCL or its
> affiliates. Any views or opinions presented in
> this email are solely those of the author and may not necessarily
> reflect the opinions of HCL or its affiliates.
> Any form of reproduction, dissemination, copying, disclosure,
> modification, distribution and / or publication of
> this message without the prior written consent of the author of this
> e-mail is strictly prohibited. If you have
> received this email in error please delete it and notify the sender
> immediately. Before opening any mail and
> attachments please check them for viruses and defect.
>
> -----------------------------------------------------------------------------------------------------------------------
>
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
________________________________________________________________________
John Bonesio
Commercial Linux Solutions
john.bonesio@xilinx.com
(408) 879-5569
This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately.
[-- Attachment #2: Type: text/html, Size: 11144 bytes --]
^ 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