* [Patch ] Kexec/Kdump support - POWER6
From: Sachin P. Sant @ 2007-05-28 11:40 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Milton Miller II, kexec, linuxppc-dev
In-Reply-To: <1180132987.19517.9.camel@localhost.localdomain>
[-- Attachment #1: Type: text/plain, Size: 807 bytes --]
Benjamin Herrenschmidt wrote:
> If you're going to use the B (1T segment) bit instead of the bolted bit,
> at least define a proper constant in line with the existing naming of
> the hash table constants in mmu-hash64.h. I would suggest doing the same
> with the VRMA_MASK/VALUE thing and calling it HPTE_V_VRMA_MASK or
> something similar.
>
Well i had used them properly in my previous patches. Don't know why
i changed it in this patch :-(
Here is the updated patch.
>> + }
>> }
>>
> In addition, I would recommend following Michael's advice and using
> using the bulk remove Hcall whenever possible.
>
Yes will send out a separate patch to use bulk remove Hcall.
Thanks
-Sachin
Signed-off-by : Sachin Sant <sachinp@in.ibm.com>
Signed-off-by : Mohan Kumar M <mohan@in.ibm.com>
---
[-- Attachment #2: kexec-kdump-support-on-POWER6 --]
[-- Type: text/plain, Size: 2541 bytes --]
* On Power machines supporting VRMA, Kexec/Kdump does not work.
* Hypervisor stores VRMA mapping used by the OS, in the hpte hash tables.
* Make sure these hpte entries are left untouched.
*
* This patch also adds plpar_pte_read_raw() on the lines of
* plpar_pte_remove_raw().
Signed-off-by : Sachin Sant <sachinp@in.ibm.com>
Signed-off-by : Mohan Kumar M <mohan@in.ibm.com>
---
diff -Naurp a/arch/powerpc/platforms/pseries/lpar.c b/arch/powerpc/platforms/pseries/lpar.c
--- a/arch/powerpc/platforms/pseries/lpar.c 2007-05-19 09:36:17.000000000 +0530
+++ b/arch/powerpc/platforms/pseries/lpar.c 2007-05-28 16:49:46.000000000 +0530
@@ -369,16 +369,30 @@ static long pSeries_lpar_hpte_remove(uns
return -1;
}
+#define HPTE_V_1TB_SEG ASM_CONST(0x4000000000000000)
+#define HPTE_V_VRMA_MASK ASM_CONST(0x4001ffffff)
+
static void pSeries_lpar_hptab_clear(void)
{
unsigned long size_bytes = 1UL << ppc64_pft_size;
unsigned long hpte_count = size_bytes >> 4;
- unsigned long dummy1, dummy2;
+ unsigned long dummy1, dummy2, dword0;
+ long lpar_rc;
int i;
/* TODO: Use bulk call */
- for (i = 0; i < hpte_count; i++)
- plpar_pte_remove_raw(0, i, 0, &dummy1, &dummy2);
+ for (i = 0; i < hpte_count; i++) {
+ /* dont remove HPTEs with VRMA mappings */
+ lpar_rc = plpar_pte_remove_raw(H_ANDCOND, i, HPTE_V_1TB_SEG,
+ &dummy1, &dummy2);
+ if (lpar_rc == H_NOT_FOUND) {
+ lpar_rc = plpar_pte_read_raw(0, i, &dword0, &dummy1);
+ if (!lpar_rc && (((dword0 >> 24) & HPTE_V_VRMA_MASK)
+ != HPTE_V_VRMA_MASK))
+ /* Can be hpte for 1TB Seg. So remove it */
+ plpar_pte_remove_raw(0, i, 0, &dummy1, &dummy2);
+ }
+ }
}
/*
diff -Naurp a/arch/powerpc/platforms/pseries/plpar_wrappers.h b/arch/powerpc/platforms/pseries/plpar_wrappers.h
--- a/arch/powerpc/platforms/pseries/plpar_wrappers.h 2007-05-19 09:36:17.000000000 +0530
+++ b/arch/powerpc/platforms/pseries/plpar_wrappers.h 2007-05-25 12:20:38.000000000 +0530
@@ -108,6 +108,21 @@ static inline long plpar_pte_read(unsign
return rc;
}
+/* plpar_pte_read_raw can be called in real mode. It calls plpar_hcall_raw */
+static inline long plpar_pte_read_raw(unsigned long flags, unsigned long ptex,
+ unsigned long *old_pteh_ret, unsigned long *old_ptel_ret)
+{
+ long rc;
+ unsigned long retbuf[PLPAR_HCALL_BUFSIZE];
+
+ rc = plpar_hcall_raw(H_READ, retbuf, flags, ptex);
+
+ *old_pteh_ret = retbuf[0];
+ *old_ptel_ret = retbuf[1];
+
+ return rc;
+}
+
static inline long plpar_pte_protect(unsigned long flags, unsigned long ptex,
unsigned long avpn)
{
^ permalink raw reply
* Re: Please pull powerpc.git for_paulus branch (fwd)
From: Segher Boessenkool @ 2007-05-28 11:36 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, Linus Torvalds
In-Reply-To: <18010.13762.461066.706793@cargo.ozlabs.ibm.com>
> although I still don't understand
> why using .comm in assembler code is suddenly verboten...
If a kernel module refers to a common symbol things go boom.
modpost complains about it, it isn't smart enough to see
that there is no problem here.
Segher
^ permalink raw reply
* Re: Please pull powerpc.git for_paulus branch (fwd)
From: Segher Boessenkool @ 2007-05-28 11:34 UTC (permalink / raw)
To: Andreas Schwab; +Cc: linuxppc-dev, Linus Torvalds, Paul Mackerras
In-Reply-To: <jesl9hgql9.fsf@sykes.suse.de>
>> - .comm fee_restarts,4
>> + .section .bss
>> + .align 2
>> +fee_restarts:
>> + .space 4
>> + .previous
>
> This is equivalent to .lcomm.
Oh nice! So this should become
.lcomm fee_restarts,4,4
for the local symbols, and
.globl fee_restarts
.lcomm fee_restarts,4,4
for the global ones. Kumar: the parameters here are size,align;
and it takes an alignment in bytes, not in power-of-two like
.align does on powerpc. Which is a good thing, considering that
you messed up the log-alignment for global_dcbr0 in the original
patch ;-)
Segher
^ permalink raw reply
* Re: Is it possible to call a C function in transfer_to_handler(arch/ppc/kernel/entry.S)?
From: Paul Mackerras @ 2007-05-28 11:28 UTC (permalink / raw)
To: Wang, Baojun; +Cc: ppc-dev, Nicholas McGuire
In-Reply-To: <380406375.32007@eyou.net>
Wang, Baojun writes:
> I'm sorry to ask this topic in this mailling list. I've spend more than 2
> days try to add a C function call in transfer_to_handler(in
> arch/ppc/kernel/entry.S) like this:
It's not going to work, because the MMU is off at this point. It will
explode as soon as the C code tries to touch any external variable.
Paul.
^ permalink raw reply
* Re: Fix problems with Holly's DT representation of ethernet PHYs
From: Benjamin Herrenschmidt @ 2007-05-28 11:15 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: Alexandre Bounine, David Gibson, linuxppc-dev list
In-Reply-To: <707c0e95390db3244bf6ebc0cbe95454@kernel.crashing.org>
On Mon, 2007-05-28 at 13:07 +0200, Segher Boessenkool wrote:
> > In that case however, the 54xx are fairly different from each other, so
> > please use something more specific.
>
> _Never_ use the "xx" stuff, it's meaningless.
Pretty much yeah... either you are compatible with a precise version
(the first one of the serie, like an hypothetical 5400) or you are not
in which case you have your precise model name in there.
Ben.
^ permalink raw reply
* Re: Fix problems with Holly's DT representation of ethernet PHYs
From: Segher Boessenkool @ 2007-05-28 11:07 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Alexandre Bounine, David Gibson, linuxppc-dev list
In-Reply-To: <1180316317.19517.51.camel@localhost.localdomain>
> In that case however, the 54xx are fairly different from each other, so
> please use something more specific.
_Never_ use the "xx" stuff, it's meaningless.
Segher
^ permalink raw reply
* Re: Fix problems with Holly's DT representation of ethernet PHYs
From: Segher Boessenkool @ 2007-05-28 11:06 UTC (permalink / raw)
To: David Gibson; +Cc: Alexandre Bounine, linuxppc-dev list
In-Reply-To: <20070527233031.GB23768@localhost.localdomain>
>>> - Second, the PHYs give only "bcm54xx" as a compatible
>>> property. This is unfortunate, because there are many bcm54xx PHY
>>> models, and they have differences which can matter. We add a more
>>> precise compatible string, giving the precise PHY model (bcm5461A in
>>> this case).
>>
>> You completely removed the "compatible" properties instead.
>> Bad idea.
>
> Um... weren't you the one that was just saying compatible properties
> aren't necessary if you can distinguish the hardware in other ways?
The OS device driver doesn't need "compatible" if it
can probe the device some other way; it doesn't need
the device node at all, even. You still should have
a "compatible" property (or, old style, a specific
"name" property) if you want the OS to be able to use
the device node to recognise the device (i.e., if a
device node for the device exists at all: always).
Segher
^ permalink raw reply
* Re: Please pull powerpc.git for_paulus branch (fwd)
From: Andreas Schwab @ 2007-05-28 11:00 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, Linus Torvalds, Paul Mackerras
In-Reply-To: <Pine.LNX.4.64.0705270856560.4113@gate.crashing.org>
Kumar Gala <galak@kernel.crashing.org> writes:
> diff --git a/arch/ppc/kernel/entry.S b/arch/ppc/kernel/entry.S
> index ab64256..fba7ca1 100644
> --- a/arch/ppc/kernel/entry.S
> +++ b/arch/ppc/kernel/entry.S
> @@ -596,7 +596,11 @@ fast_exception_return:
> mr r12,r4 /* restart at exc_exit_restart */
> b 2b
>
> - .comm fee_restarts,4
> + .section .bss
> + .align 2
> +fee_restarts:
> + .space 4
> + .previous
This is equivalent to .lcomm.
Andreas.
--
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* [PATCH] qe_lib: export symbols for QE driver to compile as module
From: Li Yang @ 2007-05-28 10:48 UTC (permalink / raw)
To: Paul; +Cc: linuxppc-dev
Export symbols of qe_lib to be used by QE driver.
Signed-off-by: Li Yang <leoli@freescale.com>
Signed-off-by: Selvamuthukumar V <vsmkumar.84@gmail.com>
---
Remove symbols for off-tree drivers
arch/powerpc/sysdev/qe_lib/ucc.c | 2 ++
arch/powerpc/sysdev/qe_lib/ucc_fast.c | 8 ++++++++
2 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/sysdev/qe_lib/ucc.c b/arch/powerpc/sysdev/qe_lib/ucc.c
index ac12a44..f970e54 100644
--- a/arch/powerpc/sysdev/qe_lib/ucc.c
+++ b/arch/powerpc/sysdev/qe_lib/ucc.c
@@ -18,6 +18,7 @@
#include <linux/errno.h>
#include <linux/slab.h>
#include <linux/stddef.h>
+#include <linux/module.h>
#include <asm/irq.h>
#include <asm/io.h>
@@ -40,6 +41,7 @@ int ucc_set_qe_mux_mii_mng(int ucc_num)
return 0;
}
+EXPORT_SYMBOL(ucc_set_qe_mux_mii_mng);
int ucc_set_type(int ucc_num, struct ucc_common *regs,
enum ucc_speed_type speed)
diff --git a/arch/powerpc/sysdev/qe_lib/ucc_fast.c b/arch/powerpc/sysdev/qe_lib/ucc_fast.c
index 9143236..3df202e 100644
--- a/arch/powerpc/sysdev/qe_lib/ucc_fast.c
+++ b/arch/powerpc/sysdev/qe_lib/ucc_fast.c
@@ -19,6 +19,7 @@
#include <linux/stddef.h>
#include <linux/interrupt.h>
#include <linux/err.h>
+#include <linux/module.h>
#include <asm/io.h>
#include <asm/immap_qe.h>
@@ -70,6 +71,7 @@ void ucc_fast_dump_regs(struct ucc_fast_private * uccf)
printk(KERN_INFO "guemr : addr - 0x%08x, val - 0x%02x",
(u32) & uccf->uf_regs->guemr, uccf->uf_regs->guemr);
}
+EXPORT_SYMBOL(ucc_fast_dump_regs);
u32 ucc_fast_get_qe_cr_subblock(int uccf_num)
{
@@ -85,11 +87,13 @@ u32 ucc_fast_get_qe_cr_subblock(int uccf_num)
default: return QE_CR_SUBBLOCK_INVALID;
}
}
+EXPORT_SYMBOL(ucc_fast_get_qe_cr_subblock);
void ucc_fast_transmit_on_demand(struct ucc_fast_private * uccf)
{
out_be16(&uccf->uf_regs->utodr, UCC_FAST_TOD);
}
+EXPORT_SYMBOL(ucc_fast_transmit_on_demand);
void ucc_fast_enable(struct ucc_fast_private * uccf, enum comm_dir mode)
{
@@ -110,6 +114,7 @@ void ucc_fast_enable(struct ucc_fast_private * uccf, enum comm_dir mode)
}
out_be32(&uf_regs->gumr, gumr);
}
+EXPORT_SYMBOL(ucc_fast_enable);
void ucc_fast_disable(struct ucc_fast_private * uccf, enum comm_dir mode)
{
@@ -130,6 +135,7 @@ void ucc_fast_disable(struct ucc_fast_private * uccf, enum comm_dir mode)
}
out_be32(&uf_regs->gumr, gumr);
}
+EXPORT_SYMBOL(ucc_fast_disable);
int ucc_fast_init(struct ucc_fast_info * uf_info, struct ucc_fast_private ** uccf_ret)
{
@@ -341,6 +347,7 @@ int ucc_fast_init(struct ucc_fast_info * uf_info, struct ucc_fast_private ** ucc
*uccf_ret = uccf;
return 0;
}
+EXPORT_SYMBOL(ucc_fast_init);
void ucc_fast_free(struct ucc_fast_private * uccf)
{
@@ -355,3 +362,4 @@ void ucc_fast_free(struct ucc_fast_private * uccf)
kfree(uccf);
}
+EXPORT_SYMBOL(ucc_fast_free);
^ permalink raw reply related
* Re: fsl booke MM vs. SMP questions
From: Benjamin Herrenschmidt @ 2007-05-28 10:28 UTC (permalink / raw)
To: Gabriel Paubert; +Cc: ppc-dev, Liu Dave-r63238, Paul Mackerras, Kumar Gala
In-Reply-To: <20070528102327.GA9675@iram.es>
On Mon, 2007-05-28 at 12:23 +0200, Gabriel Paubert wrote:
> On SMP with single die and integrated memory controllers (PASemi),
> I'd bet that tlb invalidation broadcast is typically much cheaper
> since no external signals are involved (from a hardware point of view
> it's not very different from a store to a shared cache line that has
> to be invalidated in the cache of the other processors).
Except that is often has strong locking requirements along with a race
or two to deal with when not having a HW reload on the TLB. So in the
case of Freescale BookE, it is really something that should be measured.
Ben.
^ permalink raw reply
* Re: fsl booke MM vs. SMP questions
From: Gabriel Paubert @ 2007-05-28 10:23 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: ppc-dev, Liu Dave-r63238, Paul Mackerras, Kumar Gala
In-Reply-To: <1180346421.19517.79.camel@localhost.localdomain>
On Mon, May 28, 2007 at 08:00:21PM +1000, Benjamin Herrenschmidt wrote:
> On Mon, 2007-05-28 at 17:37 +0800, Liu Dave-r63238 wrote:
> >
> > BTW, if the x86 processor support the broadcast tlb operation to
> > system?
> > If it can, why we adopt the IPI mechanism for x86? what is the
> > concern?
>
> I don't think it supports them but then, I don't know for sure.
>
It does not. However IA64 (aka Itanic) does. Of course on x86 until
recently, the TLB were completely flushed (at least the entries mapping to
user space) on task switches to a different mm, which automatically
avoids races for single threaded apps.
> Part of the problem is what your workload is. if you have a lot of small
> and short lived processes, such as CGI's on a web server, they are
> fairly unlikely to exist on more than one processor, maybe two, during
> their lifetime (there is a strong optimisation to only do a local
> invalidate when the process only ever existed on one processor).
>
> If you have a massively threaded workload, that is, a given process is
> likely to exist on all processors, then it's also fairly unlikely that
> you start doing a lot of fork()'s or to have that processes be short
> lived... so it's less of an issue unless you start abusing mmap/munmap
> or mprotect.
>
> Also, when you have a large number of processors, having broadcast tlb
> invalidations on the bus might become a bottleneck if, at the end of the
> day, you really only want to invalidate one or two siblings. In that
> case, targetted IPIs are probably a better option.
On SMP with single die and integrated memory controllers (PASemi),
I'd bet that tlb invalidation broadcast is typically much cheaper
since no external signals are involved (from a hardware point of view
it's not very different from a store to a shared cache line that has
to be invalidated in the cache of the other processors).
Gabriel
^ permalink raw reply
* RE: fsl booke MM vs. SMP questions
From: Benjamin Herrenschmidt @ 2007-05-28 10:00 UTC (permalink / raw)
To: Liu Dave-r63238; +Cc: ppc-dev, Paul Mackerras, Kumar Gala
In-Reply-To: <995B09A8299C2C44B59866F6391D263595EF6C@zch01exm21.fsl.freescale.net>
On Mon, 2007-05-28 at 17:37 +0800, Liu Dave-r63238 wrote:
>
> BTW, if the x86 processor support the broadcast tlb operation to
> system?
> If it can, why we adopt the IPI mechanism for x86? what is the
> concern?
I don't think it supports them but then, I don't know for sure.
Part of the problem is what your workload is. if you have a lot of small
and short lived processes, such as CGI's on a web server, they are
fairly unlikely to exist on more than one processor, maybe two, during
their lifetime (there is a strong optimisation to only do a local
invalidate when the process only ever existed on one processor).
If you have a massively threaded workload, that is, a given process is
likely to exist on all processors, then it's also fairly unlikely that
you start doing a lot of fork()'s or to have that processes be short
lived... so it's less of an issue unless you start abusing mmap/munmap
or mprotect.
Also, when you have a large number of processors, having broadcast tlb
invalidations on the bus might become a bottleneck if, at the end of the
day, you really only want to invalidate one or two siblings. In that
case, targetted IPIs are probably a better option.
In the end, it's very difficult to "guess" what is better. If you add
all the above, plus the race between tlb invalidations and SW TLB
reload, it makes sense to start with IPIs and try to optimize that code
path as much as you can to avoid hitting more CPUs than necessary for
example).
Ben.
^ permalink raw reply
* RE: fsl booke MM vs. SMP questions
From: Liu Dave-r63238 @ 2007-05-28 9:37 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: ppc-dev, Paul Mackerras, Kumar Gala
In-Reply-To: <1180344249.19517.74.camel@localhost.localdomain>
> > I also noticed that tlb invalidation on the PowerPC 750 SMP system
> > is using the IPI mechanism, that is because the 750 can not=20
> > broadcast tlb invalidation ops.
>=20
> Do we support that in linux ?
Yes, it support in ppc, but not in powerpc arch. It may miss in the
powerpc when porting.
> Not really... it depends on bus traffic, plus the need to spinlock the
> broadcast tlbivax as well, etc..
>=20
> I'm not working on real HW at the moment. I don't know what the exact
> characteristics of your target HW are...
BTW, if the x86 processor support the broadcast tlb operation to system?
If it can, why we adopt the IPI mechanism for x86? what is the concern?
-d
^ permalink raw reply
* Is it possible to call a C function in transfer_to_handler(arch/ppc/kernel/entry.S)?
From: Wang, Baojun @ 2007-05-28 9:30 UTC (permalink / raw)
To: ppc-dev; +Cc: Nicholas McGuire
[-- Attachment #1: Type: text/plain, Size: 1885 bytes --]
hi, list
I'm sorry to ask this topic in this mailling list. I've spend more than 2
days try to add a C function call in transfer_to_handler(in
arch/ppc/kernel/entry.S) like this:
/* cut from arch/ppc/kernel/entry.S */
transfer_to_handler:
stw r2,GPR2(r11)
stw r12,_NIP(r11)
stw r9,_MSR(r11)
andi. r2,r9,MSR_PR
mfctr r12
mfspr r2,SPRN_XER
stw r12,_CTR(r11)
stw r2,_XER(r11)
mfspr r12,SPRN_SPRG3
addi r2,r12,-THREAD
tovirt(r2,r2) /* set r2 to current */
beq 2f /* if from user, fix up THREAD.regs */
#if 1 /* this is add by me */
stwu r1, -16(r1)
mflr r0
stw r0, 20(r1)
bl emulate_iret
lwz r0, 20(r1)
mtlr r0
addi r1, r1, 16
#endif
addi r11,r1,STACK_FRAME_OVERHEAD
stw r11,PT_REGS(r12)
The function prolog is taken from a userspace program. this code freeze the
system after prints out `emulate_iret' (The only thing function emulate_iret
do is print that message).
I read the source code from head_44x.S to entry.S, sounds like all registers
(r0-r32, and even more such as _LINK, _CTR, etc..) are being saved, does that
mean I shouldn't call any C function in transfer_to_handler()? Is there
something tricky (or is it possible) to add a C function call?
Thanks in advance!
regards
--
Wang, Baojun Lanzhou University
Distributed & Embedded System Lab http://dslab.lzu.edu.cn
School of Information Science and Engeneering wangbj@lzu.edu.cn
Tianshui South Road 222. Lanzhou 730000 .P.R.China
Tel:+86-931-8912025 Fax:+86-931-8912022
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* RE: fsl booke MM vs. SMP questions
From: Benjamin Herrenschmidt @ 2007-05-28 9:24 UTC (permalink / raw)
To: Liu Dave-r63238; +Cc: ppc-dev, Paul Mackerras, Kumar Gala
In-Reply-To: <995B09A8299C2C44B59866F6391D263595EF5F@zch01exm21.fsl.freescale.net>
On Mon, 2007-05-28 at 17:05 +0800, Liu Dave-r63238 wrote:
> Ben,
>
> > You never "loose" IPIs in the sense that you always get at least 1
> > interrupt for N IPIs and it's up to software to make sure not to lose
> > any event. The linux kernel arch code usually handles that with a
> > synchronous IPI mecanism.
>
> Due to the synchronous IPI mechanism for TLB invalidatation, it is
> very time exhausting, there are interrupt overhead and wait time for
> sync.
Yup, there is, though you can try to optimize it such that you only sync
the CPUs involved with the IPIs, which often are only few.
> I also noticed that tlb invalidation on the PowerPC 750 SMP system
> is using the IPI mechanism, that is because the 750 can not broadcast
> tlb invalidation ops.
Do we support that in linux ?
> If the broadcast tlbivax instruction is more effective than the IPI
> mechanism?
>
> Did you evaluate the performance with the two different ways?
Not really... it depends on bus traffic, plus the need to spinlock the
broadcast tlbivax as well, etc..
I'm not working on real HW at the moment. I don't know what the exact
characteristics of your target HW are...
Ben.
^ permalink raw reply
* Re: Virtex-4 FX12 Mini-Module support
From: Ales Gorkic @ 2007-05-28 9:26 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 602 bytes --]
Hi Aidan,
After I searched the web I found out that you have sucesfully run the
uClinux 2.4 on Virtex-4 MiniModule. I have developed a GSRD2 design on which
I would like to run uClinux. There are two problems:
I am new to linux
I don't know where to start
I would appreciate if you could share your design with me and give me help
with running it on my design.
Cheers,
Ales Gorkic
University of Ljubljana
Faculty of Mechanical Engineering
COLA - Chair of Optodynamics and Laser Applications Askerceva cesta 6
SI-1000 Ljubljana Slovenija
www: http://www.fs.uni-lj.si/kolt/
[-- Attachment #2: Type: text/html, Size: 4123 bytes --]
^ permalink raw reply
* Re: Porting "prep" from ppc to powerpc.
From: Benjamin Herrenschmidt @ 2007-05-28 9:22 UTC (permalink / raw)
To: Gabriel Paubert; +Cc: linuxppc-dev, Rob Landley
In-Reply-To: <20070528084652.GA7686@iram.es>
On Mon, 2007-05-28 at 10:46 +0200, Gabriel Paubert wrote:
> On Mon, May 28, 2007 at 06:23:34PM +1000, Benjamin Herrenschmidt wrote:
> > On Mon, 2007-05-28 at 09:55 +0200, Gabriel Paubert wrote:
> > > I was thinking of writing a bootwrapper that would
> > > convert residual data to flat device tree. There
> > > is a lot of valuable information in the residual data,
> > > like the interrupt routing (which is correct if you
> > > can read the spec, which is not what the code in
> > > arch/ppc did).
> >
> > We were wondering the other day how reliable the residual data are...
> >
>
> On the boards I use, they are very good. And there is some information
> (memory size, tb and cpu freq, etc...) that I'd rather take from the
> residual data than trying to guess.
>
> > David Gibson's been toying with that too already, you should sync with
> > him.
>
> I've not yet started to write anything (finishing a hardware project).
Ok, well, anyway, that's good to know that they are good.
Ben.
^ permalink raw reply
* RE: fsl booke MM vs. SMP questions
From: Liu Dave-r63238 @ 2007-05-28 9:05 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: ppc-dev, Paul Mackerras, Kumar Gala
In-Reply-To: <1179889736.32247.893.camel@localhost.localdomain>
Ben,
> You never "loose" IPIs in the sense that you always get at least 1
> interrupt for N IPIs and it's up to software to make sure not to lose
> any event. The linux kernel arch code usually handles that with a
> synchronous IPI mecanism.
Due to the synchronous IPI mechanism for TLB invalidatation, it is
very time exhausting, there are interrupt overhead and wait time for
sync.
I also noticed that tlb invalidation on the PowerPC 750 SMP system
is using the IPI mechanism, that is because the 750 can not broadcast
tlb invalidation ops.
=20
If the broadcast tlbivax instruction is more effective than the IPI
mechanism?
Did you evaluate the performance with the two different ways?
-d
^ permalink raw reply
* Re: Porting "prep" from ppc to powerpc.
From: Gabriel Paubert @ 2007-05-28 8:46 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, Rob Landley
In-Reply-To: <1180340614.19517.68.camel@localhost.localdomain>
On Mon, May 28, 2007 at 06:23:34PM +1000, Benjamin Herrenschmidt wrote:
> On Mon, 2007-05-28 at 09:55 +0200, Gabriel Paubert wrote:
> > I was thinking of writing a bootwrapper that would
> > convert residual data to flat device tree. There
> > is a lot of valuable information in the residual data,
> > like the interrupt routing (which is correct if you
> > can read the spec, which is not what the code in
> > arch/ppc did).
>
> We were wondering the other day how reliable the residual data are...
>
On the boards I use, they are very good. And there is some information
(memory size, tb and cpu freq, etc...) that I'd rather take from the
residual data than trying to guess.
> David Gibson's been toying with that too already, you should sync with
> him.
I've not yet started to write anything (finishing a hardware project).
Regards,
Gabriel
^ permalink raw reply
* Re: Porting "prep" from ppc to powerpc.
From: Benjamin Herrenschmidt @ 2007-05-28 8:23 UTC (permalink / raw)
To: Gabriel Paubert; +Cc: linuxppc-dev, Rob Landley
In-Reply-To: <20070528075507.GA6633@iram.es>
On Mon, 2007-05-28 at 09:55 +0200, Gabriel Paubert wrote:
> I was thinking of writing a bootwrapper that would
> convert residual data to flat device tree. There
> is a lot of valuable information in the residual data,
> like the interrupt routing (which is correct if you
> can read the spec, which is not what the code in
> arch/ppc did).
We were wondering the other day how reliable the residual data are...
David Gibson's been toying with that too already, you should sync with
him.
Cheers,
Ben.
^ permalink raw reply
* Re: Porting "prep" from ppc to powerpc.
From: Gabriel Paubert @ 2007-05-28 7:55 UTC (permalink / raw)
To: Rob Landley; +Cc: linuxppc-dev
In-Reply-To: <200705252238.39819.rob@landley.net>
On Fri, May 25, 2007 at 10:38:39PM -0400, Rob Landley wrote:
> Is anyone already doing this?
I'm interested but I don't have the time right now.
> I asked around here a few weeks ago and got the
> advice:
>
> > In theory.. copy the files from ppc/platforms/prep.* to
> > powerpc/platforms/prep/
> > and make some Kconfigs and see what breaks :)
>
> Unfortunately, there isn't a ppc/platforms/prep. Under arch/ppc there's:
>
> ./boot/simple/misc-prep.c
> ./boot/simple/prepmap.c
> ./boot/utils/mkprep.c
> ./configs/prep_defconfig
> ./platforms/prep_pci.c
> ./platforms/prep_setup.c
> ./syslib/prep_nvram.c
>
> And I'm not sure which are relevant. Any hints?
I was thinking of writing a bootwrapper that would
convert residual data to flat device tree. There
is a lot of valuable information in the residual data,
like the interrupt routing (which is correct if you
can read the spec, which is not what the code in
arch/ppc did).
Gabriel
^ permalink raw reply
* [PATCH] [POWERPC] create a zImage for legacy iSeries
From: Stephen Rothwell @ 2007-05-28 6:12 UTC (permalink / raw)
To: paulus; +Cc: ppc-dev
This zImage is really just the stripped vmlinux, but it means that there
is one less special case for iSeries and also that the zImages will be
built for a combined kernel build that happens to include iSeries.
This zImage boots fine on legacy iSeries.
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
arch/powerpc/Makefile | 1 -
arch/powerpc/boot/Makefile | 4 ++++
2 files changed, 4 insertions(+), 1 deletions(-)
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile
index 6238b58..fbafd96 100644
--- a/arch/powerpc/Makefile
+++ b/arch/powerpc/Makefile
@@ -142,7 +142,6 @@ drivers-$(CONFIG_OPROFILE) += arch/powerpc/oprofile/
# Default to zImage, override when needed
defaultimage-y := zImage
-defaultimage-$(CONFIG_PPC_ISERIES) := vmlinux
defaultimage-$(CONFIG_DEFAULT_UIMAGE) := uImage
KBUILD_IMAGE := $(defaultimage-y)
all: $(KBUILD_IMAGE)
diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile
index 8378898..da58d1f 100644
--- a/arch/powerpc/boot/Makefile
+++ b/arch/powerpc/boot/Makefile
@@ -136,6 +136,7 @@ image-$(CONFIG_PPC_EFIKA) += zImage.chrp
image-$(CONFIG_PPC_PMAC) += zImage.pmac
image-$(CONFIG_PPC_HOLLY) += zImage.holly-elf
image-$(CONFIG_PPC_PRPMC2800) += zImage.prpmc2800
+image-$(CONFIG_PPC_ISERIES) += zImage.iseries
image-$(CONFIG_DEFAULT_UIMAGE) += uImage
ifneq ($(CONFIG_DEVICE_TREE),"")
@@ -185,6 +186,9 @@ $(obj)/zImage.initrd.%: vmlinux $(wrapperbits)
$(obj)/zImage.%: vmlinux $(wrapperbits)
$(call if_changed,wrap,$*)
+$(obj)/zImage.iseries: vmlinux
+ $(STRIP) -s -R .comment $< -o $@
+
$(obj)/zImage.ps3: vmlinux
$(STRIP) -s -R .comment $< -o $@
--
1.5.1.4
^ permalink raw reply related
* Re: [PATCH 1/13] powerpc: Add Makefile rules to wrap dts file in zImage
From: David Gibson @ 2007-05-28 4:43 UTC (permalink / raw)
To: Mark A. Greer; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <20070525205014.GC20831@mag.az.mvista.com>
On Fri, May 25, 2007 at 01:50:14PM -0700, Mark A. Greer wrote:
> On Fri, May 25, 2007 at 11:33:59AM +1000, David Gibson wrote:
> > On Fri, May 25, 2007 at 11:32:42AM +1000, David Gibson wrote:
> > > On Thu, May 24, 2007 at 02:28:32PM -0700, Mark A. Greer wrote:
> > > > On Tue, May 22, 2007 at 10:23:49AM +1000, David Gibson wrote:
>
> > > > > Just leave them out. As long as you add the correct specific
> > > > > zImage.dts.% and zImage.dts_initrd.% targets to image-y and initrd-y,
> > > > > then a "make zImage" from the top-level Makefile will get them built.
> > > >
> > > > That defeats the whole purpose of the patch--to allow the selection of
> > > > wrapping a dtb or not at build time. Its just like initrd, you choose
> > > > whether to "do it" at build time.
> > >
> > > Ah, right. Remind me why that's useful again?
> >
> > Sorry, to be more precise, why is that more useful than having "make
> > zImage" at the top level build both the dts and non-dts versions.
>
> Well, that is a good question. This is my reasoning which I put in the
> patch description:
>
> "Having separate rules allows the user to choose whether to include
> a device tree--and which device tree--at build time. This is
> useful when one Makefile target builds a zImage that runs on several
> platforms except for differing device trees. By just setting
> CONFIG_DEVICE_TREE and running "make zImage.dts" the exact zImage
> you want is built without Makefile bloat or manually running the
> wrapper script."
>
> Making both seems like a waste but its such a small waste that it
> doesn't really matter. If you still object to this feature, I'll
> take it out since I (read: prpmc2800) doesn't really need this
> feature anyway.
Go with building both; that's consistent with the various other
platforms that build multiple images for different boot variants
(e.g. ppc64 builds powermac and pseries compatible images, Ebony
builds both cuImage and treeboot image).
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [PATCH] powerpc timer sysdev: use mktime
From: Paul Mackerras @ 2007-05-28 4:33 UTC (permalink / raw)
To: Johannes Berg; +Cc: linuxppc-dev
In-Reply-To: <1179934081.14317.29.camel@johannes.berg>
Johannes Berg writes:
> I think you asked for this, any reason you then didn't take it? Just
> missed? Or is something wrong with it?
Sorry, just missed. It doesn't look essential for 2.6.22, so I'll
queue it for 2.6.23.
Paul.
^ permalink raw reply
* [PATCH] bootwrapper: adds cuboot for MPC7448HPC2 platform
From: Zang Roy-r61911 @ 2007-05-28 2:30 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev list
This patch adds cuboot support for MPC7448HPC2 platform.
The cuImage can be used with legacy u-boot without FDT support.
Signed-off-by: Roy Zang <tie-fei.zang@freescale.com>
---
arch/powerpc/boot/Makefile | 4 +-
arch/powerpc/boot/cuboot-hpc2.c | 57 ++++++++++++++++++++++++++++
arch/powerpc/boot/dts/mpc7448hpc2.dts | 5 ++
arch/powerpc/boot/ppcboot.h | 2 +-
arch/powerpc/platforms/embedded6xx/Kconfig | 1 +
include/asm-ppc/ppcboot.h | 2 +-
6 files changed, 68 insertions(+), 3 deletions(-)
create mode 100644 arch/powerpc/boot/cuboot-hpc2.c
diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile
index 8378898..5fa515d 100644
--- a/arch/powerpc/boot/Makefile
+++ b/arch/powerpc/boot/Makefile
@@ -48,7 +48,8 @@ src-wlib := string.S crt0.S stdio.c main.c flatdevtree.c flatdevtree_misc.c \
gunzip_util.c elf_util.c $(zlib) devtree.c \
44x.c ebony.c mv64x60.c mpsc.c mv64x60_i2c.c
src-plat := of.c cuboot-83xx.c cuboot-85xx.c holly.c \
- cuboot-ebony.c treeboot-ebony.c prpmc2800.c
+ cuboot-ebony.c treeboot-ebony.c prpmc2800.c \
+ cuboot-hpc2.c
src-boot := $(src-wlib) $(src-plat) empty.c
src-boot := $(addprefix $(obj)/, $(src-boot))
@@ -142,6 +143,7 @@ ifneq ($(CONFIG_DEVICE_TREE),"")
image-$(CONFIG_PPC_83xx) += cuImage.83xx
image-$(CONFIG_PPC_85xx) += cuImage.85xx
image-$(CONFIG_EBONY) += treeImage.ebony cuImage.ebony
+image-$(CONFIG_MPC7448HPC2) += cuImage.hpc2
endif
# For 32-bit powermacs, build the COFF and miboot images
diff --git a/arch/powerpc/boot/cuboot-hpc2.c b/arch/powerpc/boot/cuboot-hpc2.c
new file mode 100644
index 0000000..d8f01c4
--- /dev/null
+++ b/arch/powerpc/boot/cuboot-hpc2.c
@@ -0,0 +1,57 @@
+/*
+ * Copyright (C) 2007 Freescale Semiconductor, Inc. All rights reserved.
+ *
+ * Author: Roy Zang <tie-fei.zang@freescale.com>
+ *
+ * Description:
+ * Old U-boot compatibility for mpc7448hpc2 board
+ * Based on the code of Scott Wood <scottwood@freescale.com>
+ * for 83xx and 85xx.
+ *
+ * This is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ */
+
+#include "ops.h"
+#include "stdio.h"
+
+#define TARGET_TSI108_BRIDGE
+#include "ppcboot.h"
+
+static bd_t bd;
+extern char _end[];
+extern char _dtb_start[], _dtb_end[];
+
+static void platform_fixups(void)
+{
+ void *tsi;
+
+ dt_fixup_memory(bd.bi_memstart, bd.bi_memsize);
+ dt_fixup_mac_addresses(bd.bi_enetaddr, bd.bi_enet1addr);
+ dt_fixup_cpu_clocks(bd.bi_intfreq, bd.bi_busfreq / 4, bd.bi_busfreq);
+ tsi = find_node_by_devtype(NULL, "tsi-bridge");
+ if (tsi)
+ setprop(tsi, "bus-frequency", &bd.bi_busfreq,
+ sizeof(bd.bi_busfreq));
+}
+
+void platform_init(unsigned long r3, unsigned long r4, unsigned long r5,
+ unsigned long r6, unsigned long r7)
+{
+ unsigned long end_of_ram = bd.bi_memstart + bd.bi_memsize;
+ unsigned long avail_ram = end_of_ram - (unsigned long)_end;
+
+ memcpy(&bd, (bd_t *)r3, sizeof(bd));
+ loader_info.initrd_addr = r4;
+ loader_info.initrd_size = r4 ? r5 - r4 : 0;
+ loader_info.cmdline = (char *)r6;
+ loader_info.cmdline_len = r7 - r6;
+
+ simple_alloc_init(_end, avail_ram - 1024*1024, 32, 64);
+ ft_init(_dtb_start, _dtb_end - _dtb_start, 32);
+ serial_console_init();
+ platform_ops.fixups = platform_fixups;
+}
diff --git a/arch/powerpc/boot/dts/mpc7448hpc2.dts b/arch/powerpc/boot/dts/mpc7448hpc2.dts
index 765c306..a2ee94f 100644
--- a/arch/powerpc/boot/dts/mpc7448hpc2.dts
+++ b/arch/powerpc/boot/dts/mpc7448hpc2.dts
@@ -81,6 +81,7 @@
};
ethernet@6200 {
+ linux,network-index = <0>;
#size-cells = <0>;
device_type = "network";
model = "TSI-ETH";
@@ -93,6 +94,7 @@
};
ethernet@6600 {
+ linux,network-index = <1>;
#address-cells = <1>;
#size-cells = <0>;
device_type = "network";
@@ -188,5 +190,8 @@
};
};
};
+ chosen {
+ linux,stdout-path = "/tsi108@c0000000/serial@7808";
+ };
};
diff --git a/arch/powerpc/boot/ppcboot.h b/arch/powerpc/boot/ppcboot.h
index 5290ff2..f7ef004 100644
--- a/arch/powerpc/boot/ppcboot.h
+++ b/arch/powerpc/boot/ppcboot.h
@@ -78,7 +78,7 @@ typedef struct bd_info {
hymod_conf_t bi_hymod_conf; /* hymod configuration information */
#endif
#if defined(TARGET_EVB64260) || defined(TARGET_405EP) || defined(TARGET_44x) || \
- defined(TARGET_85xx) || defined(TARGET_83xx)
+ defined(TARGET_85xx) || defined(TARGET_83xx) || defined(TARGET_TSI108_BRIDGE)
/* second onboard ethernet port */
unsigned char bi_enet1addr[6];
#define HAVE_ENET1ADDR
diff --git a/arch/powerpc/platforms/embedded6xx/Kconfig b/arch/powerpc/platforms/embedded6xx/Kconfig
index f2d2626..9a6c6c2 100644
--- a/arch/powerpc/platforms/embedded6xx/Kconfig
+++ b/arch/powerpc/platforms/embedded6xx/Kconfig
@@ -20,6 +20,7 @@ config MPC7448HPC2
select TSI108_BRIDGE
select DEFAULT_UIMAGE
select PPC_UDBG_16550
+ select WANT_DEVICE_TREE
help
Select MPC7448HPC2 if configuring for Freescale MPC7448HPC2 (Taiga)
platform
diff --git a/include/asm-ppc/ppcboot.h b/include/asm-ppc/ppcboot.h
index 6b7b63f..eb6e18d 100644
--- a/include/asm-ppc/ppcboot.h
+++ b/include/asm-ppc/ppcboot.h
@@ -74,7 +74,7 @@ typedef struct bd_info {
hymod_conf_t bi_hymod_conf; /* hymod configuration information */
#endif
#if defined(CONFIG_EVB64260) || defined(CONFIG_405EP) || defined(CONFIG_44x) || \
- defined(CONFIG_85xx) || defined(CONFIG_83xx)
+ defined(CONFIG_85xx) || defined(CONFIG_83xx) || defined(CONFIG_TSI108_BRIDGE)
/* second onboard ethernet port */
unsigned char bi_enet1addr[6];
#endif
--
1.5.1
^ permalink raw reply related
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