* Re: [PATCH v3 0/3] cpu: pseries: Cpu offline states framework
From: Peter Zijlstra @ 2009-09-25 14:48 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Gautham R Shenoy, linux-kernel, Venkatesh Pallipadi,
Arun R Bharadwaj, linuxppc-dev, Darrick J. Wong
In-Reply-To: <1253753501.7103.358.camel@pasglop>
On Thu, 2009-09-24 at 10:51 +1000, Benjamin Herrenschmidt wrote:
> On Tue, 2009-09-15 at 14:11 +0200, Peter Zijlstra wrote:
> > I still think its a layering violation... its the hypervisor manager
> > that should be bothered in what state an off-lined cpu is in.
> >
> That's not how our hypervisor works.
Then fix it?
> If you ask through the management interface, to remove a CPU from a
> partition, the HV will communicate with a daemon inside the partition
> that will then unplug the CPU via the right call.
>
> I don't really understand your objections to be honest. And I fail to
> see why it would be a layering violation to have the ability for the OS
> to indicate in what state it wishes to relinguish a CPU to the
> hypervisor, which more or less defines what is the expected latency for
> getting it back later on.
OK, so the main objection is the abuse of CPU hotplug as resource
management feature.
CPU hotplug is terribly invasive and expensive to the kernel, doing
hotplug on a minute basis is just plain crazy.
If you want a CPU in a keep it near and don't hand it back to the HV
state, why not use cpusets to isolate it and simply not run tasks on it?
cpusets don't use stopmachine and are much nicer to the rest of the
kernel over-all.
^ permalink raw reply
* Re: e300 (MPC5121) dlmzb
From: Kumar Gala @ 2009-09-25 16:34 UTC (permalink / raw)
To: Fortini Matteo; +Cc: linux-ppc list
In-Reply-To: <4ABCA454.5030807@mta.it>
On Sep 25, 2009, at 4:07 AM, Fortini Matteo wrote:
> I was trying to insert an optimized strlen() function using the
> following code taken from the ibm site on an MPC5121, but it crashes
> the kernel.
> Is it because it's an unsupported op, or because I'm missing some
> needed steps?
>
> Thank you,
> Matteo
>
> _GLOBAL(strlen)
> addi r4,0,8 // Load byte count of 8
> mtxer r4 // Set byte count for load string
> xor r4,r4,r4 // r4 = 0, r4 == accumulator
> 1:
> lswx r5,r3,r4 // load string into r5 & r6
> dlmzb. r12,r5,r6 // find NULL byte and record in r7.
> add r4,r4,r12 // Update accumulator.
> beq 1b // Loop if NULL not found.
> addi r3,r4,-1 // Subtract 1 for NULL byte.
> blr // Return length
dlmzb. isn't supported on e300. I believe only 4xx supports it.
- k
^ permalink raw reply
* Re: [v6 PATCH 0/7]: cpuidle/x86/POWER: Cleanup idle power management code in x86, cleanup drivers/cpuidle/cpuidle.c and introduce cpuidle to POWER.
From: Arun R Bharadwaj @ 2009-09-25 17:08 UTC (permalink / raw)
To: Peter Zijlstra, Joel Schopp, Benjamin Herrenschmidt,
Paul Mackerras, Ingo Molnar, Vaidyanathan Srinivasan,
Dipankar Sarma, Balbir Singh, Gautham R Shenoy, Shaohua Li,
Venkatesh Pallipadi, Arun Bharadwaj
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <20090922112526.GA7788@linux.vnet.ibm.com>
* Arun R Bharadwaj <arun@linux.vnet.ibm.com> [2009-09-22 16:55:27]:
Hi,
I have done the following experiments and have posted the results
below.
Average of 5 iterations:
------------------------------------------------------------------------------
------------------------------------------------------------------------------
Kernbench make -j16 results on a
16 core x86 machine _with_deep_sleep_ support (C1,C2,C3)
Without the patches applied With the patches applied
31.8s 30.4s
------------------------------------------------------------------------------
------------------------------------------------------------------------------
Kernbench make -j8 results on a
8 core x86 machine _without_deep_sleep_ support (only mwait)
Without the patches applied With the patches applied
20.2s 20.4s
------------------------------------------------------------------------------
------------------------------------------------------------------------------
Kernbench make -j8 results on a 8 core _dedicated_lpar_pSeries_ machine
Without the patches applied With the patches applied
4m, 37s 4m, 36s
------------------------------------------------------------------------------
------------------------------------------------------------------------------
Please let me know if any other kind of testing is necessary.
Based on the feedback, I will post out the next iteration with a few
minor bug fixes.
thanks,
arun
^ permalink raw reply
* Re: [patch] powerpc: build modules outside the kernel tree fails, if it was built using O=
From: Sam Ravnborg @ 2009-09-25 19:45 UTC (permalink / raw)
To: Yuri Frolov; +Cc: rep.dot.nop, linuxppc-dev, linux-kbuild
In-Reply-To: <4ABB57CB.3000409@ru.mvista.com>
On Thu, Sep 24, 2009 at 03:28:11PM +0400, Yuri Frolov wrote:
> Hello,
>
> here is a corresponding bug: http://bugzilla.kernel.org/show_bug.cgi?id=11143
> This patch should correctly export crtsavres.o in order to make O= option working.
> Please, consider to apply.
Hi Yuri.
I like the way you do the extra link in Makefile.modpost.
But you need to redo some parts as per comments below.
>
>
> Fix linking modules against crtsavres.o
Please elaborate more on what this commit does.
>
> Previously we got
> CC drivers/char/hw_random/rng-core.mod.o
> LD [M] drivers/char/hw_random/rng-core.ko
> /there/src/buildroot.git.ppc/build_powerpc_nofpu/staging_dir/usr/bin/powerpc-linux-uclibc-ld: arch/powerpc/lib/crtsavres.o: No such file: No such file or directory
Always good to include error messages.
> * Makefile (LDFLAGS_MODULE_PREREQ): New variable to hold prerequisite
> files for modules.
> * arch/powerpc/Makefile: add crtsavres.o to LDFLAGS_MODULE_PREREQ.
> * scripts/Makefile.modpost (cmd_as_o_S): Copy from Makefile.build.
> (cmd_ld_ko_o): Also link LDFLAGS_MODULE_PREREQ.
> Provide rule to build objects from assembler.
But this GNUism can go - we do not use it in the kernel.
>
> Signed-off-by: Bernhard Reutner-Fischer <rep.dot.nop@gmail.com>
> Signed-off by: Yuri Frolov <yfrolov@ru.mvista.com>
>
> Makefile | 2 ++
> arch/powerpc/Makefile | 2 +-
> scripts/Makefile.modpost | 12 ++++++++++--
> 3 files changed, 13 insertions(+), 3 deletions(-)
>
> diff -urpN -X linux-2.6/Documentation/dontdiff linux-2.6/arch/powerpc/Makefile linux-2.6-powerpc-crtsavres/arch/powerpc/Makefile
> --- linux-2.6/arch/powerpc/Makefile 2009-09-17 20:04:31.000000000 +0400
> +++ linux-2.6-powerpc-crtsavres/arch/powerpc/Makefile 2009-09-23 22:08:03.000000000 +0400
> @@ -93,7 +93,7 @@ else
> KBUILD_CFLAGS += $(call cc-option,-mtune=power4)
> endif
> else
> -LDFLAGS_MODULE += arch/powerpc/lib/crtsavres.o
> +LDFLAGS_MODULE_PREREQ += arch/powerpc/lib/crtsavres.o
> endif
The naming sucks.
How about:
KBUILD_MODULE_LINK_SOURCE
This would tell the reader that this is source to be linked on a module.
And this is an arch specific thing so no need to preset it in top-level
Makefile.
But it is mandatory to include a description in Documentation/kbuild/kbuild.txt
> --- linux-2.6/scripts/Makefile.modpost 2009-09-17 20:04:42.000000000 +0400
> +++ linux-2.6-powerpc-crtsavres/scripts/Makefile.modpost 2009-09-23 22:15:00.000000000 +0400
> @@ -122,14 +122,22 @@ quiet_cmd_cc_o_c = CC $@
> cmd_cc_o_c = $(CC) $(c_flags) $(CFLAGS_MODULE) \
> -c -o $@ $<
>
> -$(modules:.ko=.mod.o): %.mod.o: %.mod.c FORCE
> +quiet_cmd_as_o_S = AS $(quiet_modtag) $@
> +cmd_as_o_S = $(CC) $(a_flags) $(AFLAGS_MODULE) -c -o $@ $<
Align this so cmd_as_o_S is under each other - as we do for cmd_cc_o_c
> +
> +$(LDFLAGS_MODULE_PREREQ): %.o: %.S FORCE
> + $(Q)mkdir -p $(dir $@)
> + $(call if_changed_dep,as_o_S)
Good catch with the mkdir - needed for O= builds.
I think we shall wrap this in
ifdef KBUILD_MODULE_LINK_SOURCE
...
endif
So we do not have an empty rule when it is not defined.
Please fix up these things and resubmit.
Thanks,
Sam
^ permalink raw reply
* RE: PCI HotPlug and Adding Resources after Linux Boots
From: Morrison, Tom @ 2009-09-25 20:26 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <1253698927.7103.312.camel@pasglop>
Ben/all,
I have had some luck reserving some memory (via in this autoscan
(which reserves the resources)) which in this hack code - I reserve
an appropriate amount of resources for the bridge (by detecting=20
this special type of port).
The problem comes later on - when the Hotplug event comes - and it
still can't allocate the resources...
A member of this group (who is away from the office right now) had=20
the following comments:
>> In your case, if the only problem that you are running into is=20
>> that the resources cannot be assigned to the FPGA, it may be=20
>> sufficient to hardcode the forwarding addresses and subordinate=20
>> bridge number for port 6 of your 8616. The reason you are seeing=20
>> that error message is because the parent bridge device for the=20
>> detected FPGA (port 6 of the 8616) does not have forwarded=20
>> resource regions that match what the FPGA is trying to claim.
I guess the question I am asking is my friend's statement possibly
true. And, if he is correct - I am a little confused as to exactly=20
where/how do I determine and configure this forwarding=20
addresses/subordinate bridge number (I'm really a newbie at this
level of PCI configuration).
Thank you in advance to any/all who can help me figure this out!
Tom
>> -----Original Message-----
[Morrison, Tom]=20
>>=20
>> There's a few things you can do, though I don't have time just right now
>> to give you a detailed answer. I'll try again later.
>>=20
>> In the meantime, some of the answers could be around not using full
>> automatic resource assignment, but instead, pre-initializing the top
>> bridge with some resources that are going to be enough for the device.
>>=20
>> You can also try to get the bridge to re-allocate. There's various funky
>> locking issues with doing that though as long as it's during boot time,
>> it's not too much of a problem.
>>=20
>> There are other more or less hackish ways to do it, but I'll have to
>> give it more thought.
>>=20
>> I'm quite stretched at the moment so if you don't hear back from me in
>> the upcoming few days, don't hesitate to ping me again.
>>=20
>> Cheers,
>> Ben.
>>=20
>> >
>> > I am running Linux (2.6.23x (and 2.6.27.x)) on a MPC8572 based system.
>> >
>> >
>> >
>> > I have an 8616 switch that has a Port (6) connected to a FPGA that is
>> >
>> > NOT loaded at before Linux boots (note: this port is configured for
>> > HOTPLUG
>> >
>> > events - which we do get after FPGA is loaded). We are NOT using a
>> >
>> > static device tree map (because the devices in the system are very
>> > dynamic).
>> >
>> >
>> > We use instead the pci auto scan mechanism(s) to scan/assign
>> > resources
>> >
>> > (including into the BAR registers) at bootup to all of the devices
>> > that are
>> >
>> > attached to this MPC8572...
>> >
>> >
>> >
>> > Here is the port that is attached to the device (note: there are NO
>> >
>> > resources assigned at this point this port):
>> >
>> >
>> >
>> > ----------------------------------------------------------------------=
-
>> --------------------------
>> >
>> > 02:06.0 PCI bridge: PLX Technology, Inc.: Unknown device 8616 (rev bb)
>> > (prog-if 00 [Normal decode])
>> >
>> > Flags: bus master, fast devsel, latency 0
>> >
>> > Bus: primary=3D02, secondary=3D05, subordinate=3D05, sec-laten=
cy=3D0
>> >
>> > Capabilities: [40] Power Management version 3
>> >
>> > Capabilities: [48] Message Signalled Interrupts: 64bit+
>> > Queue=3D0/2 Enable+
>> >
>> > Capabilities: [68] #10 [0162]
>> >
>> > Capabilities: [a4] #0d [0000]
>> >
>> >
>> >
>> > root@slave7 ~ # lspci -t
>> >
>> > -+-[01]---00.0-[02-05]--+-01.0
>> >
>> > | +-04.0-[03]--
>> >
>> > | +-05.0-[04]--
>> >
>> > | \-06.0-[05]-
>> >
>> >
>> >
>> > ----------------------------------------------------------------------=
-
>> --------------------------
>> >
>> >
>> >
>> > Later, after I detect there is an FPGA to load - I load it. At
>> > completion of the
>> >
>> > loading of the FPGA - the 8616 detects the FPGA - and creates a
>> > HotPlug
>> >
>> > event that the PCI Express HotPlug Driver handles:
>> >
>> > ----------------------------------------------------------------------=
-
>> --------------------------
>> >
>> >
>> >
>> > root@slave7 ~ # pciehp: pcie_isr: intr_loc 8
>> >
>> > pciehp: pciehp: Presence/Notify input change.
>> >
>> > pciehp: Card present on Slot(0005_0070)
>> >
>> > pciehp: Surprise Removal
>> >
>> > pciehp: hpc_get_power_status: SLOTCTRL 80 value read 8
>> >
>> > pciehp: hpc_get_attention_status: SLOTCTRL 80, value read 8
>> >
>> > pciehp: board_added: slot device, slot offset, hp slot =3D 0, 0 ,0
>> >
>> > pciehp: hpc_check_lnk_status: lnk_status =3D 2021
>> >
>> > PCI: Found 0000:05:00.0 [1172/0004] 00ff00 00
>> >
>> > PCI: Calling quirk c0012d3c for 0000:05:00.0
>> >
>> > program_fw_provided_values: Could not get hotplug parameters
>> >
>> > entering assign resources (size: 2000000)
>> >
>> > PCI: Failed to allocate mem resource #0:2000000@0 for 0000:05:00.0
>> >
>> > bus pci: add device 0000:05:00.0
>> >
>> > entering uevent
>> >
>> > pci: Trying to Match Device 0000:05:00.0 with Driver pcieport-driver
>> >
>> > pci: Trying to Match Device 0000:05:00.0 with Driver serial
>> >
>> > pci: Trying to Match Device 0000:05:00.0 with Driver pexntb
>> >
>> > pciehp: hpc_get_power_status: SLOTCTRL 80 value read 8
>> >
>> > pciehp: hpc_get_attention_status: SLOTCTRL 80, value read 8
>> >
>> >
>> >
>> > 02:06.0 PCI bridge: PLX Technology, Inc.: Unknown device 8616 (rev bb)
>> > (prog-if 00 [Normal decode])
>> >
>> > Flags: bus master, fast devsel, latency 0
>> >
>> > Bus: primary=3D02, secondary=3D05, subordinate=3D05, sec-laten=
cy=3D0
>> >
>> > Capabilities: [40] Power Management version 3
>> >
>> > Capabilities: [48] Message Signalled Interrupts: 64bit+
>> > Queue=3D0/2 Enable+
>> >
>> > Capabilities: [68] #10 [0162]
>> >
>> > Capabilities: [a4] #0d [0000]
>> >
>> >
>> >
>> > 05:00.0 Class ff00: Altera Corporation: Unknown device 0004 (rev 01)
>> >
>> > Subsystem: Altera Corporation: Unknown device 0004
>> >
>> > Flags: fast devsel
>> >
>> > Capabilities: [50] Message Signalled Interrupts: 64bit+
>> > Queue=3D0/5 Enable-
>> >
>> > Capabilities: [78] Power Management version 3
>> >
>> > Capabilities: [80] #10 [0001]
>> >
>> >
>> >
>> > root@slave7 ~ # lspci -t
>> >
>> > -+-[01]---00.0-[02-05]--+-01.0
>> >
>> > | +-04.0-[03]--
>> >
>> > | +-05.0-[04]--
>> >
>> > | \-06.0-[05]----00.0
>> >
>> > \-[00]---00.0
>> >
>> >
>> >
>> > ----------------------------------------------------------------------=
-
>> --------------------------
>> >
>> >
>> >
>> > So, as you can see - the device has been read - and it requires 32M of
>> > resources, but
>> >
>> > because its parent doesn't have any resources allocated - it seemingly
>> > can't allocate and
>> >
>> > use any additional resources.
>> >
>> >
>> >
>> > How do I 'customize' and/or add resources at this point for this
>> > device (using semi-standard mechanisms)?
>> >
>> >
>> >
>> > Thanks in advance for any/all ideas...
>> >
>> >
>> >
>> >
>> >
>> > I
>> >
>> >
>> >
>> > Tom Morrison
>> > Principal Software Engineer
>> >
>> > EMPIRIX
>> > 20 Crosby Drive - Bedford, MA 01730
>> > p: 781.266.3567 f: 781.266.3670
>> > email: tmorrison@empirix.com
>> > www.empirix.com
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> > _______________________________________________
>> > Linuxppc-dev mailing list
>> > Linuxppc-dev@lists.ozlabs.org
>> > https://lists.ozlabs.org/listinfo/linuxppc-dev
>>=20
^ permalink raw reply
* warning: allocated section `.data_nosave' not in segment
From: Sean MacLennan @ 2009-09-25 20:54 UTC (permalink / raw)
To: linuxppc-dev
Anybody else getting these? They just started popping up with the
recent changes for 2.6.32.
ppc_4xxFP-ld: .tmp_vmlinux1: warning: allocated section `.data_nosave'
not in segment KSYM .tmp_kallsyms1.S
AS .tmp_kallsyms1.o
LD .tmp_vmlinux2
ppc_4xxFP-ld: .tmp_vmlinux2: warning: allocated section `.data_nosave' not in segment
KSYM .tmp_kallsyms2.S
AS .tmp_kallsyms2.o
LD vmlinux
ppc_4xxFP-ld: vmlinux: warning: allocated section `.data_nosave' not in segment
Cheers,
Sean
^ permalink raw reply
* Re: [PATCH v3 0/3] cpu: pseries: Cpu offline states framework
From: Benjamin Herrenschmidt @ 2009-09-25 21:12 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Gautham R Shenoy, linux-kernel, Venkatesh Pallipadi,
Arun R Bharadwaj, linuxppc-dev, Darrick J. Wong
In-Reply-To: <1253890120.18939.189.camel@laptop>
On Fri, 2009-09-25 at 16:48 +0200, Peter Zijlstra wrote:
> On Thu, 2009-09-24 at 10:51 +1000, Benjamin Herrenschmidt wrote:
> > On Tue, 2009-09-15 at 14:11 +0200, Peter Zijlstra wrote:
> > > I still think its a layering violation... its the hypervisor manager
> > > that should be bothered in what state an off-lined cpu is in.
> > >
> > That's not how our hypervisor works.
>
> Then fix it?
Are you serious ? :-)
> CPU hotplug is terribly invasive and expensive to the kernel, doing
> hotplug on a minute basis is just plain crazy.
>
> If you want a CPU in a keep it near and don't hand it back to the HV
> state, why not use cpusets to isolate it and simply not run tasks on it?
>
> cpusets don't use stopmachine and are much nicer to the rest of the
> kernel over-all.
Gautham, what is the different in term of power saving between having
it idle for long periods of time (which could do H_CEDE and with NO_HZ,
probably wouln't need to wake up that often) and having it unplugged in
a H_CEDE loop ?
Ben.
^ permalink raw reply
* Re: [PATCH] powerpc/8xx: fix regression introduced by cache coherency rewrite
From: Rex Feany @ 2009-09-25 21:18 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <1253847827.7103.504.camel@pasglop>
Thus spake Benjamin Herrenschmidt (benh@kernel.crashing.org):
>
> > I think there's more finishyness to 8xx than we thought. IE. That
> > tlbil_va might have more reasons to be there than what the comment
> > seems to advertize. Can you try to move it even higher up ? IE.
> > Unconditionally at the beginning of set_pte_filter ?
> >
> > Also, if that doesn't help, can you try putting one in
> > set_access_flags_filter() just below ?
>
> Ok, I got a refresher on the whole concept of "unpopulated TLB entries"
> on 8xx, and that's damn scary. I think what mislead me initially is that
> the comment around the workaround is simply not properly describing the
> extent of the problem :-)
Oh boy, that sounds bad. Where is a good place to read about this?
> So I'm not going to make the 8xx TLB miss code sane, that's beyond what
> I'm prepare to do with it, but I suspect that this should fix it (on top
> of upstream). Let me know if that's enough or if we also need to put
> one of these in ptep_set_access_flags().
>
> Please let me know if that works for you.
Putting the tlbil_va() in the top of set_pte_filter() doesn't work - it
hangs on boot before it even prints any messages to the console.
However, adding tlbil_va() to ptep_set_access_flags() as you suggested
makes everything happy. I need to test it some more, but it looks good
so far. Below is what I am testing now.
thanks!
/rex.
diff --git a/arch/powerpc/mm/pgtable.c b/arch/powerpc/mm/pgtable.c
index 5304093..aef552a 100644
--- a/arch/powerpc/mm/pgtable.c
+++ b/arch/powerpc/mm/pgtable.c
@@ -176,18 +176,19 @@ static pte_t set_pte_filter(pte_t pte, unsigned long addr)
struct page *pg = maybe_pte_to_page(pte);
if (!pg)
return pte;
- if (!test_bit(PG_arch_1, &pg->flags)) {
#ifdef CONFIG_8xx
- /* On 8xx, cache control instructions (particularly
- * "dcbst" from flush_dcache_icache) fault as write
- * operation if there is an unpopulated TLB entry
- * for the address in question. To workaround that,
- * we invalidate the TLB here, thus avoiding dcbst
- * misbehaviour.
- */
- /* 8xx doesn't care about PID, size or ind args */
- _tlbil_va(addr, 0, 0, 0);
+ /* On 8xx, cache control instructions (particularly
+ * "dcbst" from flush_dcache_icache) fault as write
+ * operation if there is an unpopulated TLB entry
+ * for the address in question. To workaround that,
+ * we invalidate the TLB here, thus avoiding dcbst
+ * misbehaviour.
+ */
+ /* 8xx doesn't care about PID, size or ind args */
+ _tlbil_va(addr, 0, 0, 0);
#endif /* CONFIG_8xx */
+
+ if (!test_bit(PG_arch_1, &pg->flags)) {
flush_dcache_icache_page(pg);
set_bit(PG_arch_1, &pg->flags);
}
@@ -308,6 +309,12 @@ int ptep_set_access_flags(struct vm_area_struct *vma, unsigned long address,
int changed;
entry = set_access_flags_filter(entry, vma, dirty);
changed = !pte_same(*(ptep), entry);
+
+#ifdef CONFIG_8xx
+ /* 8xx doesn't care about PID, size or ind args */
+ _tlbil_va(address, 0, 0, 0);
+#endif /* CONFIG_8xx */
+
if (changed) {
if (!(vma->vm_flags & VM_HUGETLB))
assert_pte_locked(vma->vm_mm, address);
^ permalink raw reply related
* Re: [patch] powerpc: build modules outside the kernel tree fails, if it was built using O=
From: Benjamin Herrenschmidt @ 2009-09-25 21:57 UTC (permalink / raw)
To: Sam Ravnborg; +Cc: rep.dot.nop, Yuri Frolov, linuxppc-dev, linux-kbuild
In-Reply-To: <20090925194557.GA3323@merkur.ravnborg.org>
On Fri, 2009-09-25 at 21:45 +0200, Sam Ravnborg wrote:
> On Thu, Sep 24, 2009 at 03:28:11PM +0400, Yuri Frolov wrote:
> > Hello,
> >
> > here is a corresponding bug: http://bugzilla.kernel.org/show_bug.cgi?id=11143
> > This patch should correctly export crtsavres.o in order to make O= option working.
> > Please, consider to apply.
>
> Hi Yuri.
>
> I like the way you do the extra link in Makefile.modpost.
> But you need to redo some parts as per comments below.
> >
> > Fix linking modules against crtsavres.o
>
> Please elaborate more on what this commit does.
It's a support file that needs to be linked against every module
(aka libgcc like) and thus needs to be built before any module.
Cheers,
Ben.
^ permalink raw reply
* Re: [patch] powerpc: build modules outside the kernel tree fails, if it was built using O=
From: Sam Ravnborg @ 2009-09-25 22:01 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: rep.dot.nop, Yuri Frolov, linuxppc-dev, linux-kbuild
In-Reply-To: <1253915852.7103.531.camel@pasglop>
On Sat, Sep 26, 2009 at 07:57:32AM +1000, Benjamin Herrenschmidt wrote:
> On Fri, 2009-09-25 at 21:45 +0200, Sam Ravnborg wrote:
> > On Thu, Sep 24, 2009 at 03:28:11PM +0400, Yuri Frolov wrote:
> > > Hello,
> > >
> > > here is a corresponding bug: http://bugzilla.kernel.org/show_bug.cgi?id=11143
> > > This patch should correctly export crtsavres.o in order to make O= option working.
> > > Please, consider to apply.
> >
> > Hi Yuri.
> >
> > I like the way you do the extra link in Makefile.modpost.
> > But you need to redo some parts as per comments below.
>
> > >
> > > Fix linking modules against crtsavres.o
> >
> > Please elaborate more on what this commit does.
>
> It's a support file that needs to be linked against every module
> (aka libgcc like) and thus needs to be built before any module.
Yes.
My point was that the next version of the changelog should
include this information - as well as kbuild.txt.
Sam
^ permalink raw reply
* Re: [PATCH v3 0/3] cpu: pseries: Cpu offline states framework
From: Pavel Machek @ 2009-09-26 9:55 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Gautham R Shenoy, Venkatesh Pallipadi, linux-kernel,
Arun R Bharadwaj, linuxppc-dev, Darrick J. Wong
In-Reply-To: <1253016701.5506.73.camel@laptop>
On Tue 2009-09-15 14:11:41, Peter Zijlstra wrote:
> On Tue, 2009-09-15 at 17:36 +0530, Gautham R Shenoy wrote:
> > This patchset contains the offline state driver implemented for
> > pSeries. For pSeries, we define three available_hotplug_states. They are:
> >
> > online: The processor is online.
> >
> > offline: This is the the default behaviour when the cpu is offlined
> > even in the absense of this driver. The CPU would call make an
> > rtas_stop_self() call and hand over the CPU back to the resource pool,
> > thereby effectively deallocating that vCPU from the LPAR.
> > NOTE: This would result in a configuration change to the LPAR
> > which is visible to the outside world.
> >
> > inactive: This cedes the vCPU to the hypervisor with a cede latency
> > specifier value 2.
> > NOTE: This option does not result in a configuration change
> > and the vCPU would be still entitled to the LPAR to which it earlier
> > belong to.
> >
> > Any feedback on the patchset will be immensely valuable.
>
> I still think its a layering violation... its the hypervisor manager
> that should be bothered in what state an off-lined cpu is in.
Agreed. Proposed interface is ugly.
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
^ permalink raw reply
* Market research for new PowerPC system
From: Konstantinos Margaritis @ 2009-09-26 11:38 UTC (permalink / raw)
To: linuxppc-dev, debian-powerpc, opensuse-ppc; +Cc: Konstantinos Margaritis
(Sorry for the cross-posting, please ignore if you are not interested
in this, CC me as I'm not subscribed)
Hi,
First some introductions. I'm Konstantinos Margaritis, a long time
Amiga/BeOS/Linux user/developer and a PowerPC fan, former Debian
Developer, also a SIMD/AltiVec fanatic and the author of libfreevec.
I've posted this on the following sites:
http://amigaworld.net/modules/newbb/viewtopic.php?mode=viewtopic&topic_id=29594&forum=33&start=0&viewmode=flat&order=0
http://www.amiga.org/forums/showthread.php?t=49424
http://www.morphzone.org/modules/newbb_plus/viewtopic.php?topic_id=6465&forum=11
http://aros-exec.org/modules/newbb/viewtopic.php?viewmode=flat&topic_id=3768&forum=4
http://www.haiku-os.org/community/forum/market_research_new_powerpc_system#comment-12604
To anyone who is not a PowerPC user, it might seem like crazy, but
here it goes:
I'm considering funding the design & production of a new PowerPC
system (well, the motherboard, the rest are typical pc stuff and a
case). No this is not a joke, I've been wanting to do this for a long
time, and perhaps the chance will be given to me now. But before I
spend any money on this, I want to do a little market research first.
I know the market is literally "dying" for a new powerpc motherboard,
but exactly how many are there that want to buy one?
Ok, let's give some rough specs first. I'm considering 3 choices -not
in order of probability/importance:
1. MPC8640D-based. It will be dual core at 1Ghz -most likely, higher
frequencies are much more expensive and the cost of the final board
would be prohibitive.
2. MPC8610-based. Single core at 1Ghz, slightly less expensive, and
includes a 2D DIU display unit -quite fast, but no 3D unfortunately.
3. QorIQ P1022-based. Again dual core at 1Ghz (1055Mhz to be precise).
Apart from the much lower chip price, this one includes dual gigabit
ethernet, dual SATA, USB 2.0 and a 2D DIU display unit (same as the
MPC8610). So this one would lower the cost of the board quite much.
Disadvantages: No AltiVec unit (it sucks I know), though it includes
an SPE unit which is not that bad, and availability will be in Q3/Q4
2010, so that's a long wait.
Now, the end motherboard will probably be MicroATX (in the 8640D/8610
case) or PicoITX (in the P1022 case), and it will definitely include:
* SATA connectors
* USB (possibly 2 back and 2 front, but that's discussable)
* Dual gigabit (at least one will be there, in the case of the
MPC8640D we might even have 4!!!)
* Sound (of course, SPDIF support will definitely be there)
* 1 PCI-e slot 1x
* 1 PCI-e slot (4x in the P1022 case, 8x in the MPC86xx cases)
Ok, what I want to know is if people would really really buy one of
these. End price is estimated to be ~around~ 350EUR for the P1022
board or ~500EUR (definitely more in the case of 8640D) in the case of
the other boards. Besides being more expensive, the MPC86xx chips,
don't include SATA, USB and only one of ethernet/sound (quad-gige in
MPC8640D case, or sound in the case of MPC8610). I know this sounds a
lot, but it's the reality, there is not enough funding to build
enormous amounts of units and bring the prices down substantially, we
have to start low and build up from there. In case you are wondering,
yes, the boards will be designed/produced by bPlan and funded by my
company (Codex).
Support for OSes: Linux definitely, Haiku most probably and there is a
possibility of supporting AmigaOS/MorphOS, which will depend on the
actual feedback I get from those users.
I would like to make a list of everyone that is really interested in
such a system, so it would really help me make a decision sooner
rather than later if you would send me a few personal details to markos@codex.gr
with subject "PowerPC board":
* Name
* Country
* email (definitely, I'd have to reach you back!)
* Phone/Skype (optional, please include international prefix)
* Forum you saw this post (ok, Morphzone in this case)
* OS of preference
* board you would be most interested in (MPC8610/MPC8640D/P1022)
* preferred price (please have in mind the estimated price quotes I
mentioned, it might be lower but that's not very probable)
* Other notes/comments
Also, I found out that I had to state my case on many forums to prove
that this is not vapourware. Well, it will not be vapourware, if I get
feedback. So far the feedback I got can be summarized here:
http://www.codex.gr/index.php?pageID=&blogItem=60
Thanks a lot for your time and I hope this system becomes a reality.
Konstantinos Margaritis
Codex
^ permalink raw reply
* Problem with futex call on 8xx
From: Frank Svendsbøe @ 2009-09-26 12:00 UTC (permalink / raw)
To: linuxppc-dev
Hi
I'm having a problem with ~100% CPU load on MPC8xx when calling
pthread_cond_wait.
Running strace, I get:
futex(0x10040d5c, FUTEX_WAIT, 1, NULL) = -1 ENOSYS (Function not implemented)
.. and this call is inifinitely repeating, which explains the high load.
I'm running Linux 2.6.26-rc2 (not newer due to the slowdown problem
introduced by commit
8d30c14cab30d405a05f2aaceda1e9ad57800f36, as pointed out by Rex Feany
this week), and
glibc v2.6 (part of ELDK 4.2).
Is this a problem due to an error in the futex implementation in
glibc, or a kernel problem?
Best regards,
Frank
^ permalink raw reply
* Re: Market research for new PowerPC system
From: Stephen Rothwell @ 2009-09-26 12:18 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <0046254A-432D-4AE3-9B9F-C0D30311B7D7@codex.gr>
[-- Attachment #1: Type: text/plain, Size: 568 bytes --]
Just in case anyone feels like flaming about this post, I allowed it
because I thought some of you may feel inclined to provide some technical
advise, enthusiasm for someone else building PowerPC systems. If you
object, then just ignore the post ...
On Sat, 26 Sep 2009 14:38:38 +0300 Konstantinos Margaritis <markos@codex.gr> wrote:
>
> (Sorry for the cross-posting, please ignore if you are not interested
> in this, CC me as I'm not subscribed)
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: [patch] powerpc: build modules outside the kernel tree fails, if it was built using O=
From: Yuri Frolov @ 2009-09-26 12:45 UTC (permalink / raw)
To: Sam Ravnborg; +Cc: rep.dot.nop, linuxppc-dev, linux-kbuild
In-Reply-To: <20090925194557.GA3323@merkur.ravnborg.org>
Hello, here is a fixed version.
Compile and export arch/powerpc/lib/crtsavres.o in order to fix the
"arch/powerpc/lib/crtsavres.o not found" error when "O=" option
is employed for external module compilation.
crtsavres.o is a support file, containing save/restore code from gcc,
simplified down for powerpc architecture needs.
This file needs to be linked against every module and thus to be built
before any module.
Documentation/kbuild/kbuild.txt | 8 ++++++++
Makefile | 2 +-
arch/powerpc/Makefile | 2 +-
scripts/Makefile.modpost | 14 ++++++++++++--
4 files changed, 22 insertions(+), 4 deletions(-)
diff -urpN -X linux-2.6/Documentation/dontdiff linux-2.6/arch/powerpc/Makefile linux-2.6-powerpc-crtsavres/arch/powerpc/Makefile
--- linux-2.6/arch/powerpc/Makefile 2009-09-17 20:04:31.000000000 +0400
+++ linux-2.6-powerpc-crtsavres/arch/powerpc/Makefile 2009-09-26 13:35:32.000000000 +0400
@@ -93,7 +93,7 @@ else
KBUILD_CFLAGS += $(call cc-option,-mtune=power4)
endif
else
-LDFLAGS_MODULE += arch/powerpc/lib/crtsavres.o
+KBUILD_MODULE_LINK_SOURCE += arch/powerpc/lib/crtsavres.o
endif
ifeq ($(CONFIG_TUNE_CELL),y)
diff -urpN -X linux-2.6/Documentation/dontdiff linux-2.6/Documentation/kbuild/kbuild.txt linux-2.6-powerpc-crtsavres/Documentation/kbuild/kbuild.txt
--- linux-2.6/Documentation/kbuild/kbuild.txt 2009-09-17 20:04:30.000000000 +0400
+++ linux-2.6-powerpc-crtsavres/Documentation/kbuild/kbuild.txt 2009-09-26 16:03:50.000000000 +0400
@@ -132,3 +132,11 @@ For tags/TAGS/cscope targets, you can sp
to be included in the databases, separated by blank space. E.g.:
$ make ALLSOURCE_ARCHS="x86 mips arm" tags
+
+KBUILD_MODULE_LINK_SOURCE
+--------------------------------------------------
+Compile and export arch/powerpc/lib/crtsavres.o
+when "O=" option is employed for powerpc external module compilation.
+This file needs to be linked against every module and thus to be built
+before any module.
+
diff -urpN -X linux-2.6/Documentation/dontdiff linux-2.6/Makefile linux-2.6-powerpc-crtsavres/Makefile
--- linux-2.6/Makefile 2009-09-17 20:04:30.000000000 +0400
+++ linux-2.6-powerpc-crtsavres/Makefile 2009-09-26 14:23:27.000000000 +0400
@@ -354,7 +354,7 @@ KERNELVERSION = $(VERSION).$(PATCHLEVEL)
export VERSION PATCHLEVEL SUBLEVEL KERNELRELEASE KERNELVERSION
export ARCH SRCARCH CONFIG_SHELL HOSTCC HOSTCFLAGS CROSS_COMPILE AS LD CC
export CPP AR NM STRIP OBJCOPY OBJDUMP MAKE AWK GENKSYMS PERL UTS_MACHINE
-export HOSTCXX HOSTCXXFLAGS LDFLAGS_MODULE CHECK CHECKFLAGS
+export HOSTCXX HOSTCXXFLAGS LDFLAGS_MODULE CHECK CHECKFLAGS KBUILD_MODULE_LINK_SOURCE
export KBUILD_CPPFLAGS NOSTDINC_FLAGS LINUXINCLUDE OBJCOPYFLAGS LDFLAGS
export KBUILD_CFLAGS CFLAGS_KERNEL CFLAGS_MODULE CFLAGS_GCOV
diff -urpN -X linux-2.6/Documentation/dontdiff linux-2.6/scripts/Makefile.modpost linux-2.6-powerpc-crtsavres/scripts/Makefile.modpost
--- linux-2.6/scripts/Makefile.modpost 2009-09-17 20:04:42.000000000 +0400
+++ linux-2.6-powerpc-crtsavres/scripts/Makefile.modpost 2009-09-26 14:34:28.000000000 +0400
@@ -122,14 +122,24 @@ quiet_cmd_cc_o_c = CC $@
cmd_cc_o_c = $(CC) $(c_flags) $(CFLAGS_MODULE) \
-c -o $@ $<
-$(modules:.ko=.mod.o): %.mod.o: %.mod.c FORCE
+quiet_cmd_as_o_S = AS $(quiet_modtag) $@
+ cmd_as_o_S = $(CC) $(a_flags) $(AFLAGS_MODULE) -c -o $@ $<
+
+ifdef KBUILD_MODULE_LINK_SOURCE
+$(KBUILD_MODULE_LINK_SOURCE): %.o: %.S FORCE
+ $(Q)mkdir -p $(dir $@)
+ $(call if_changed_dep,as_o_S)
+endif
+
+$(modules:.ko=.mod.o): %.mod.o: %.mod.c $(KBUILD_MODULE_LINK_SOURCE) FORCE
$(call if_changed_dep,cc_o_c)
targets += $(modules:.ko=.mod.o)
# Step 6), final link of the modules
quiet_cmd_ld_ko_o = LD [M] $@
- cmd_ld_ko_o = $(LD) -r $(LDFLAGS) $(LDFLAGS_MODULE) -o $@ \
+ cmd_ld_ko_o = $(LD) -r $(LDFLAGS) $(KBUILD_MODULE_LINK_SOURCE) \
+ $(LDFLAGS_MODULE) -o $@ \
$(filter-out FORCE,$^)
$(modules): %.ko :%.o %.mod.o FORCE
On 09/25/2009 11:45 PM, Sam Ravnborg wrote:
> On Thu, Sep 24, 2009 at 03:28:11PM +0400, Yuri Frolov wrote:
>> Hello,
>>
>> here is a corresponding bug: http://bugzilla.kernel.org/show_bug.cgi?id=11143
>> This patch should correctly export crtsavres.o in order to make O= option working.
>> Please, consider to apply.
>
> Hi Yuri.
>
> I like the way you do the extra link in Makefile.modpost.
> But you need to redo some parts as per comments below.
>
>>
>> Fix linking modules against crtsavres.o
>
> Please elaborate more on what this commit does.
>
>> Previously we got
>> CC drivers/char/hw_random/rng-core.mod.o
>> LD [M] drivers/char/hw_random/rng-core.ko
>> /there/src/buildroot.git.ppc/build_powerpc_nofpu/staging_dir/usr/bin/powerpc-linux-uclibc-ld: arch/powerpc/lib/crtsavres.o: No such file: No such file or directory
>
> Always good to include error messages.
>
>> * Makefile (LDFLAGS_MODULE_PREREQ): New variable to hold prerequisite
>> files for modules.
>> * arch/powerpc/Makefile: add crtsavres.o to LDFLAGS_MODULE_PREREQ.
>> * scripts/Makefile.modpost (cmd_as_o_S): Copy from Makefile.build.
>> (cmd_ld_ko_o): Also link LDFLAGS_MODULE_PREREQ.
>> Provide rule to build objects from assembler.
> But this GNUism can go - we do not use it in the kernel.
>
>> Signed-off-by: Bernhard Reutner-Fischer <rep.dot.nop@gmail.com>
>> Signed-off by: Yuri Frolov <yfrolov@ru.mvista.com>
>>
>> Makefile | 2 ++
>> arch/powerpc/Makefile | 2 +-
>> scripts/Makefile.modpost | 12 ++++++++++--
>> 3 files changed, 13 insertions(+), 3 deletions(-)
>>
>> diff -urpN -X linux-2.6/Documentation/dontdiff linux-2.6/arch/powerpc/Makefile linux-2.6-powerpc-crtsavres/arch/powerpc/Makefile
>> --- linux-2.6/arch/powerpc/Makefile 2009-09-17 20:04:31.000000000 +0400
>> +++ linux-2.6-powerpc-crtsavres/arch/powerpc/Makefile 2009-09-23 22:08:03.000000000 +0400
>> @@ -93,7 +93,7 @@ else
>> KBUILD_CFLAGS += $(call cc-option,-mtune=power4)
>> endif
>> else
>> -LDFLAGS_MODULE += arch/powerpc/lib/crtsavres.o
>> +LDFLAGS_MODULE_PREREQ += arch/powerpc/lib/crtsavres.o
>> endif
>
> The naming sucks.
> How about:
>
> KBUILD_MODULE_LINK_SOURCE
>
> This would tell the reader that this is source to be linked on a module.
>
> And this is an arch specific thing so no need to preset it in top-level
> Makefile.
> But it is mandatory to include a description in Documentation/kbuild/kbuild.txt
>
>
>> --- linux-2.6/scripts/Makefile.modpost 2009-09-17 20:04:42.000000000 +0400
>> +++ linux-2.6-powerpc-crtsavres/scripts/Makefile.modpost 2009-09-23 22:15:00.000000000 +0400
>> @@ -122,14 +122,22 @@ quiet_cmd_cc_o_c = CC $@
>> cmd_cc_o_c = $(CC) $(c_flags) $(CFLAGS_MODULE) \
>> -c -o $@ $<
>>
>> -$(modules:.ko=.mod.o): %.mod.o: %.mod.c FORCE
>> +quiet_cmd_as_o_S = AS $(quiet_modtag) $@
>> +cmd_as_o_S = $(CC) $(a_flags) $(AFLAGS_MODULE) -c -o $@ $<
>
> Align this so cmd_as_o_S is under each other - as we do for cmd_cc_o_c
>
>
>> +
>> +$(LDFLAGS_MODULE_PREREQ): %.o: %.S FORCE
>> + $(Q)mkdir -p $(dir $@)
>> + $(call if_changed_dep,as_o_S)
> Good catch with the mkdir - needed for O= builds.
> I think we shall wrap this in
> ifdef KBUILD_MODULE_LINK_SOURCE
> ...
> endif
>
> So we do not have an empty rule when it is not defined.
>
> Please fix up these things and resubmit.
>
> Thanks,
> Sam
^ permalink raw reply
* Re: Problem with futex call on 8xx
From: Frank Svendsbøe @ 2009-09-26 12:52 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Scott Wood, Detlev Zundel
In-Reply-To: <1ba63b520909260500k3b7a0ed1l2d75116053ae5522@mail.gmail.com>
I'll answer myself, since I just found the solution to the problem -
with help from 'kos_tom'
at #uclibc on freenode.
The problem is caused by a missing 'CONFIG_FUTEX=3Dy' in the defconfig
for our target.
The system we're developing is based on the Adder port by Scott Wood, which=
is
also missing this, so a patch should be committed for this and
possible other 8xx targets
as well.
Best regards,
Frank
On Sat, Sep 26, 2009 at 2:00 PM, Frank Svendsb=F8e
<frank.svendsboe@gmail.com> wrote:
> Hi
> I'm having a problem with ~100% CPU load on MPC8xx when calling
> pthread_cond_wait.
> Running strace, I get:
>
> futex(0x10040d5c, FUTEX_WAIT, 1, NULL) =A0=3D -1 ENOSYS (Function not imp=
lemented)
>
> .. and this call is inifinitely repeating, which explains the high load.
>
> I'm running Linux 2.6.26-rc2 (not newer due to the slowdown problem
> introduced by commit
> 8d30c14cab30d405a05f2aaceda1e9ad57800f36, as pointed out by Rex Feany
> this week), and
> glibc v2.6 (part of ELDK 4.2).
>
> Is this a problem due to an error in the futex implementation in
> glibc, or a kernel problem?
>
> Best regards,
> Frank
>
^ permalink raw reply
* Re: Market research for new PowerPC system
From: Guennadi Liakhovetski @ 2009-09-26 17:58 UTC (permalink / raw)
To: Konstantinos Margaritis; +Cc: debian-powerpc, linuxppc-dev, opensuse-ppc
In-Reply-To: <0046254A-432D-4AE3-9B9F-C0D30311B7D7@codex.gr>
On Sat, 26 Sep 2009, Konstantinos Margaritis wrote:
> (Sorry for the cross-posting, please ignore if you are not interested in this,
> CC me as I'm not subscribed)
> Hi,
>
> First some introductions. I'm Konstantinos Margaritis, a long time
> Amiga/BeOS/Linux user/developer and a PowerPC fan, former Debian Developer,
> also a SIMD/AltiVec fanatic and the author of libfreevec. I've posted this on
> the following sites:
>
> http://amigaworld.net/modules/newbb/viewtopic.php?mode=viewtopic&topic_id=29594&forum=33&start=0&viewmode=flat&order=0
>
> http://www.amiga.org/forums/showthread.php?t=49424
>
> http://www.morphzone.org/modules/newbb_plus/viewtopic.php?topic_id=6465&forum=11
>
> http://aros-exec.org/modules/newbb/viewtopic.php?viewmode=flat&topic_id=3768&forum=4
>
> http://www.haiku-os.org/community/forum/market_research_new_powerpc_system#comment-12604
>
> To anyone who is not a PowerPC user, it might seem like crazy, but here it
> goes:
>
> I'm considering funding the design & production of a new PowerPC system (well,
> the motherboard, the rest are typical pc stuff and a case). No this is not a
> joke, I've been wanting to do this for a long time, and perhaps the chance
> will be given to me now. But before I spend any money on this, I want to do a
> little market research first. I know the market is literally "dying" for a new
> powerpc motherboard, but exactly how many are there that want to buy one?
Ok, just a short comment. In principle I like diversity, competition, etc.
And it was somewhat sad when Apple abandoned ppc. But honestly - why
should I be buying a ppc desktop system? If we restrict our comparison to
Linux, because that's what I'm using, what advantages would a ppc system
give me over a comparable in price ix86 system? This is not meant
negatively, I just have not followed recent ppc CPUs from the "desktop"
range, so, this is a real honest question. Would such a system provide
more MIPS per Watt at the same price? Or more periferals? Or some specific
hardware blocks unavailable or unsupported om ix86?
Thanks
Guennadi
>
> Ok, let's give some rough specs first. I'm considering 3 choices -not in order
> of probability/importance:
>
> 1. MPC8640D-based. It will be dual core at 1Ghz -most likely, higher
> frequencies are much more expensive and the cost of the final board would be
> prohibitive.
> 2. MPC8610-based. Single core at 1Ghz, slightly less expensive, and includes a
> 2D DIU display unit -quite fast, but no 3D unfortunately.
> 3. QorIQ P1022-based. Again dual core at 1Ghz (1055Mhz to be precise). Apart
> from the much lower chip price, this one includes dual gigabit ethernet, dual
> SATA, USB 2.0 and a 2D DIU display unit (same as the MPC8610). So this one
> would lower the cost of the board quite much. Disadvantages: No AltiVec unit
> (it sucks I know), though it includes an SPE unit which is not that bad, and
> availability will be in Q3/Q4 2010, so that's a long wait.
>
> Now, the end motherboard will probably be MicroATX (in the 8640D/8610 case) or
> PicoITX (in the P1022 case), and it will definitely include:
>
> * SATA connectors
> * USB (possibly 2 back and 2 front, but that's discussable)
> * Dual gigabit (at least one will be there, in the case of the MPC8640D we
> might even have 4!!!)
> * Sound (of course, SPDIF support will definitely be there)
> * 1 PCI-e slot 1x
> * 1 PCI-e slot (4x in the P1022 case, 8x in the MPC86xx cases)
>
> Ok, what I want to know is if people would really really buy one of these. End
> price is estimated to be ~around~ 350EUR for the P1022 board or ~500EUR
> (definitely more in the case of 8640D) in the case of the other boards.
> Besides being more expensive, the MPC86xx chips, don't include SATA, USB and
> only one of ethernet/sound (quad-gige in MPC8640D case, or sound in the case
> of MPC8610). I know this sounds a lot, but it's the reality, there is not
> enough funding to build enormous amounts of units and bring the prices down
> substantially, we have to start low and build up from there. In case you are
> wondering, yes, the boards will be designed/produced by bPlan and funded by my
> company (Codex).
>
> Support for OSes: Linux definitely, Haiku most probably and there is a
> possibility of supporting AmigaOS/MorphOS, which will depend on the actual
> feedback I get from those users.
>
> I would like to make a list of everyone that is really interested in such a
> system, so it would really help me make a decision sooner rather than later if
> you would send me a few personal details to markos@codex.gr with subject
> "PowerPC board":
>
> * Name
> * Country
> * email (definitely, I'd have to reach you back!)
> * Phone/Skype (optional, please include international prefix)
> * Forum you saw this post (ok, Morphzone in this case)
> * OS of preference
> * board you would be most interested in (MPC8610/MPC8640D/P1022)
> * preferred price (please have in mind the estimated price quotes I mentioned,
> it might be lower but that's not very probable)
> * Other notes/comments
>
> Also, I found out that I had to state my case on many forums to prove that
> this is not vapourware. Well, it will not be vapourware, if I get feedback. So
> far the feedback I got can be summarized here:
>
> http://www.codex.gr/index.php?pageID=&blogItem=60
>
> Thanks a lot for your time and I hope this system becomes a reality.
>
> Konstantinos Margaritis
>
> Codex
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
^ permalink raw reply
* Re: Market research for new PowerPC system
From: Leon Woestenberg @ 2009-09-26 18:15 UTC (permalink / raw)
To: Konstantinos Margaritis; +Cc: debian-powerpc, linuxppc-dev, opensuse-ppc
In-Reply-To: <0046254A-432D-4AE3-9B9F-C0D30311B7D7@codex.gr>
Hello,
first off, I like your idea. This is my public reply, I'll give a
personal reply later.
On Sat, Sep 26, 2009 at 1:38 PM, Konstantinos Margaritis
<markos@codex.gr> wrote:
> I'm considering funding the design & production of a new PowerPC system
> (well, the motherboard, the rest are typical pc stuff and a case). No this
>
What makes the system stand out, from say a Atom based PC?
(I know, playing devil's advocate here)
> 1. MPC8640D-based. It will be dual core at 1Ghz -most likely, higher
> frequencies are much more expensive and the cost of the final board would be
> prohibitive.
> 2. MPC8610-based. Single core at 1Ghz, slightly less expensive, and includes
> a 2D DIU display unit -quite fast, but no 3D unfortunately.
> 3. QorIQ P1022-based. Again dual core at 1Ghz (1055Mhz to be precise). Apart
> from the much lower chip price, this one includes dual gigabit ethernet,
> dual SATA, USB 2.0 and a 2D DIU display unit (same as the MPC8610). So this
>
Go for QorIQ P1022, it's the ideal SoC for many applications.
Alternatively, it's predecessor MPC8536E available now, ~same specs,
but higher power. But not the two you mention please.
> End price is estimated to be ~around~ 350EUR for the P1022 board or ~500EUR
>
Pico P1022 or Pico MPC8536E pls.
and throw PCI Express (x4) in the party!
(hint: I haven't seen an Intel board with Atom and PCI Express yet).
Will the board be open hardware? I.e. an open sourced design?
Regards,
--
Leon
^ permalink raw reply
* Re: Market research for new PowerPC system
From: Konstantinos Margaritis @ 2009-09-26 19:08 UTC (permalink / raw)
To: Leon Woestenberg; +Cc: debian-powerpc, linuxppc-dev
In-Reply-To: <c384c5ea0909261115t361e019auadf3b76a312ff2d1@mail.gmail.com>
> What makes the system stand out, from say a Atom based PC?
As you said, PCI Express, *actual* low power and probably higher speed
-all cpus mention are faster than the Atom at least in relative terms.
The SoC design means less components on the board, so smaller sizes
might be achieved.
> Go for QorIQ P1022, it's the ideal SoC for many applications.
>
I know, I like the chip very much, the thing is that it won't be
available till Q4/2010, so it will take quite a bit more thinking.
> Alternatively, it's predecessor MPC8536E available now, ~same specs,
> but higher power. But not the two you mention please.
Why not? I mean seriously, why would you dislike them?
>> End price is estimated to be ~around~ 350EUR for the P1022 board or
>> ~500EUR
>>
> Pico P1022 or Pico MPC8536E pls.
> and throw PCI Express (x4) in the party!
definetely PCI Express for all CPUs anyway.
> (hint: I haven't seen an Intel board with Atom and PCI Express yet).
>
> Will the board be open hardware? I.e. an open sourced design?
I don't know yet, to be frank, I haven't thought about it, though I've
worked with open source software for years, I have no experience
whatsoever with open source hardware, I don't know the dangers,
pitfalls, advantages, etc.
Konstantinos
^ permalink raw reply
* Re: Market research for new PowerPC system
From: Konstantinos Margaritis @ 2009-09-26 19:15 UTC (permalink / raw)
To: Guennadi Liakhovetski; +Cc: debian-powerpc, linuxppc-dev
In-Reply-To: <Pine.LNX.4.64.0909261949240.4273@axis700.grange>
On Sep 26, 2009, at 8:58 PM, Guennadi Liakhovetski wrote:
>
> Ok, just a short comment. In principle I like diversity,
> competition, etc.
> And it was somewhat sad when Apple abandoned ppc. But honestly - why
> should I be buying a ppc desktop system? If we restrict our
> comparison to
> Linux, because that's what I'm using, what advantages would a ppc
> system
> give me over a comparable in price ix86 system? This is not meant
> negatively, I just have not followed recent ppc CPUs from the
> "desktop"
> range, so, this is a real honest question. Would such a system provide
> more MIPS per Watt at the same price? Or more periferals? Or some
> specific
> hardware blocks unavailable or unsupported om ix86?
Ok, I remember a few years back when we had Alpha, MIPS, x86, SPARC,
PowerPC, etc all viable platforms to use and work on. Now it's only
x86. I'm sorry,
I just don't like it. I cannot answer your question, no more than I
can answer why
a car lover buys an old Jaguar antique for the price he could buy a
new Audi S8
for example. Well, ok the analogy is not exactly the same, but you get
the point.
If not, well, the ppc board would just lessen the current gap between
x86/ppc in
favour of the -admittedly very small- ppc desktop/hobbyist market.
Nevertheless,
I'm pretty sure the system would find itself in many ppc developers'
desks, just
because they can't really buy something *new* with those specs, at
this price range.
Ok, perhaps I will fail and just add my name to the list of failed
hardware projects.
Perhaps not. I really don't know if I can convince you if you don't
want to be convinced.
Deliver a super ppc system that beats all x86 systems at the same or
better price? No,
I'm sorry I cannot do that, and I never implied I could. Only IBM/
Freescale could do that
and even then the game would not be in their favour.
Regards
Konstantinos
^ permalink raw reply
* Re: Market research for new PowerPC system
From: Guennadi Liakhovetski @ 2009-09-26 20:49 UTC (permalink / raw)
To: Konstantinos Margaritis; +Cc: debian-powerpc, linuxppc-dev
In-Reply-To: <95FC0E0B-F6FE-45FD-A84E-AC4AF477F786@codex.gr>
On Sat, 26 Sep 2009, Konstantinos Margaritis wrote:
>
> On Sep 26, 2009, at 8:58 PM, Guennadi Liakhovetski wrote:
> >
> > Ok, just a short comment. In principle I like diversity, competition, etc.
> > And it was somewhat sad when Apple abandoned ppc. But honestly - why
> > should I be buying a ppc desktop system? If we restrict our comparison to
> > Linux, because that's what I'm using, what advantages would a ppc system
> > give me over a comparable in price ix86 system? This is not meant
> > negatively, I just have not followed recent ppc CPUs from the "desktop"
> > range, so, this is a real honest question. Would such a system provide
> > more MIPS per Watt at the same price? Or more periferals? Or some specific
> > hardware blocks unavailable or unsupported om ix86?
>
> Ok, I remember a few years back when we had Alpha, MIPS, x86, SPARC,
> PowerPC, etc all viable platforms to use and work on. Now it's only x86. I'm sorry,
> I just don't like it. I cannot answer your question, no more than I can answer why
> a car lover buys an old Jaguar antique for the price he could buy a new Audi S8
> for example. Well, ok the analogy is not exactly the same, but you get the point.
> If not, well, the ppc board would just lessen the current gap between x86/ppc in
> favour of the -admittedly very small- ppc desktop/hobbyist market. Nevertheless,
> I'm pretty sure the system would find itself in many ppc developers' desks, just
> because they can't really buy something *new* with those specs, at this price range.
> Ok, perhaps I will fail and just add my name to the list of failed hardware projects.
> Perhaps not. I really don't know if I can convince you if you don't want to be convinced.
> Deliver a super ppc system that beats all x86 systems at the same or better price? No,
> I'm sorry I cannot do that, and I never implied I could. Only IBM/Freescale could do that
> and even then the game would not be in their favour.
Ok, fair enough, as I said, that wasn't meant as a pun. I'd really love to
see non-x86 desktops _successful_ on the market, and I don't mean just
ARM-based netbooks, nettops, tablets, etc.:-) So, good luck to you, and I
really mean it! Interestingly, ppc competes on embedded, competes on
servers, but practically absent on desktops (apart from a couple of
hackintosh manufacturers:-)), so, maybe indeed there's still something
that ppc can offer us that x86 cannot - as a self-contained system, and
not just a development platform for ppc professionals?
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
^ permalink raw reply
* Re: lite5200b kernel not booting
From: Albrecht Dreß @ 2009-09-27 12:22 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <9e4733910909250515p60e0b0e0v8c10063326fe882c@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1298 bytes --]
Am 25.09.09 14:15 schrieb(en) Jon Smirl:
> No one has tried the Macraigor USB wiggler on the mpc5200 and
> reported back if it works.
I'm working on a self-designed, roughly Lite5200B based board, and
first thought about buying this device. However, I tried to contact
their support several times (as to get a confirmation that it will work
with our flash and board-specific design), but never got a reply. So
we ended up with the Abatron BDI3000, which is rather expensive, but
works really flawlessly, and Abatron's (and their German distributor's)
support is just *excellent* (fast and professional).
> uboot 1.2 is very old. That may be the cause of your problems. For
> example old u-boots don't initialize the PCI hardware correctly on
> systems that don't have PCI implemented.
U-Boot 2009.03 together with ELDK 4.2 work flawlessly on both the
Lite5200B and on our design.
> In general the current powerpc kernel works fine on the mpc5200b. We
> are running it on four different CPU boards but I don't have a
> lite5200b.
I can only confirm that the stock (from kernel.org) kernels run
flawlessly on our boards (the latest I tried was 2.6.30.3, though, but
I don't expect any issues with 2.6.31.1).
Hope this helps,
Albrecht.
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] powerpc/8xx: fix regression introduced by cache coherency rewrite
From: Joakim Tjernlund @ 2009-09-27 13:22 UTC (permalink / raw)
To: Rex Feany; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <20090925211848.GA3371@compile2.chatsunix.int.mrv.com>
>
> Thus spake Benjamin Herrenschmidt (benh@kernel.crashing.org):
>
> >
> > > I think there's more finishyness to 8xx than we thought. IE. That
> > > tlbil_va might have more reasons to be there than what the comment
> > > seems to advertize. Can you try to move it even higher up ? IE.
> > > Unconditionally at the beginning of set_pte_filter ?
> > >
> > > Also, if that doesn't help, can you try putting one in
> > > set_access_flags_filter() just below ?
> >
> > Ok, I got a refresher on the whole concept of "unpopulated TLB entries"
> > on 8xx, and that's damn scary. I think what mislead me initially is that
> > the comment around the workaround is simply not properly describing the
> > extent of the problem :-)
>
> Oh boy, that sounds bad. Where is a good place to read about this?
>
> > So I'm not going to make the 8xx TLB miss code sane, that's beyond what
> > I'm prepare to do with it, but I suspect that this should fix it (on top
> > of upstream). Let me know if that's enough or if we also need to put
> > one of these in ptep_set_access_flags().
> >
> > Please let me know if that works for you.
>
> Putting the tlbil_va() in the top of set_pte_filter() doesn't work - it
> hangs on boot before it even prints any messages to the console.
>
> However, adding tlbil_va() to ptep_set_access_flags() as you suggested
> makes everything happy. I need to test it some more, but it looks good
> so far. Below is what I am testing now.
8xx, is getting very hacky and I suspect that the only long term fix is
add code to trap the cache instructions in TLB error/miss and fixup the
exception in page fault handler. This will also have the added benefit on being able
to use the cache instructions in both kernel and user space like any other
ppc arch.
Jocke
^ permalink raw reply
* Re: [PATCH] i2c-mpc: Do not generate STOP after read.
From: Joakim Tjernlund @ 2009-09-27 22:26 UTC (permalink / raw)
To: Jean Delvare; +Cc: linuxppc-dev, linux-i2c, Esben Haabendal
In-Reply-To: <4ABC94ED.6070508@grandegger.com>
Jean, I just noticed you pull request for i2c on LKML but I didn't see this
patch nor have I got any feedback from you. What is your view?
Jocke
Wolfgang Grandegger <wg@grandegger.com> wrote on 25/09/2009 12:01:17:
>
> Joakim Tjernlund wrote:
> > The driver always ends a read with a STOP condition which
> > breaks subsequent I2C reads/writes in the same transaction as
> > these expect to do a repeated START(ReSTART).
> >
> > This will also help I2C multimaster as the bus will not be released
> > after the first read, but when the whole transaction ends.
> >
> > Signed-off-by: Joakim Tjernlund <Joakim.Tjernlund@transmode.se>
> Tested-by: Wolfgang Grandegger <wg@grandegger.com>
>
> on a MPC8548 board with an up-to-date kernel. I did not realize any
> problems.
>
> Wolfgang.
>
^ permalink raw reply
* Re: GPIO driver for MPC8313.
From: Johnny Hung @ 2009-09-28 2:43 UTC (permalink / raw)
To: Peter Korsgaard; +Cc: linuxppc-dev, linux-embedded
In-Reply-To: <cb9ecdfa0909230820k6ebbd589o409e58e2d9b6740c@mail.gmail.com>
The kerne source I used now is 2.6.23 with MPC8313-erdb pached. I
think I should port 2.6.28 gpio function back to 2.6.23. Is it a
common way to implement it in the kernel I used or I should port
MPC8313-erdb pached to 2.6.28 opposite?
BRs, H. Johnny
2009/9/23 Johnny Hung <johnny.hacking@gmail.com>:
> Many thanks for your help. I will try it.
>
> 2009/9/23 Peter Korsgaard <jacmet@sunsite.dk>:
>>>>>>> "Johnny" =3D=3D Johnny Hung <johnny.hacking@gmail.com> writes:
>>
>> =A0Johnny> Thanks, got it. BTW, how to trigger GPIO level in user space
>> =A0Johnny> application? I also found
>> =A0Johnny> arch/powerpc/platforms/52xx/mpc52xx_gpio.c is a good
>> =A0Johnny> example. Any reply is appreciate.
>>
>> Through sysfs. See 'Sysfs Interface for Userspace' section of
>> Documentation/gpio.txt
>>
>> --
>> Bye, Peter Korsgaard
>>
>
^ 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