* multiprocessor
From: keng_629 @ 2007-11-17 6:45 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 202 bytes --]
i am trying to make a exam about Multiprocessor on the Xilinx Virtex-4 with two PowerPc hard core.
please give me some advices about bootloader and os.
how can i start my work.
keng_629
2007-11-17
[-- Attachment #2: Type: text/html, Size: 855 bytes --]
^ permalink raw reply
* Re: [POWERPC] [RFC] Fix 8xx tlbie definition
From: Benjamin Herrenschmidt @ 2007-11-17 1:05 UTC (permalink / raw)
To: Vitaly Bordug; +Cc: linuxppc-dev
In-Reply-To: <20071117012837.4811d394@kernel.crashing.org>
On Sat, 2007-11-17 at 01:28 +0300, Vitaly Bordug wrote:
> On Sat, 17 Nov 2007 08:06:29 +1100
> Benjamin Herrenschmidt wrote:
>
> >
> > On Fri, 2007-11-16 at 11:28 -0600, Josh Boyer wrote:
> > > Git commit e701d269aa28996f3502780951fe1b12d5d66b49 introduced an
> > > incorrect definition for _tlbie on PowerPC 8xx platforms. Only the
> > > address should be passed to the function. This patch corrects the
> > > definition of _tlbie and the related tlb flushing functions for 8xx.
> > >
> > > Signed-off-by: Josh Boyer <jwboyer@linux.vnet.ibm.com>
> >
> > That conflicts with the patch I posted to fix it differently (I kept
> > the additional argument).
> >
>
> Where can I grab it to give a try? My linuxppc archive is silent for some reason..
Looks like I may have failed to post it ... weird, I was sure I posted
that days ago, when Olof first mentioned the breakage. I'll check &
resend.
> > Which one do we take ?
> >
>
> If your solution will work out, I'd agree with Kumar to have this thing consistent.
> If not - It might be cheapier just to fix it this gross way, to keep 8xx stuff running.
Ben.
^ permalink raw reply
* Re: [PATCH] powerpc: Fix 44x Machine Check handling
From: Benjamin Herrenschmidt @ 2007-11-16 22:21 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <6612E7C6-C570-4748-BCEE-AC6733C0BB14@kernel.crashing.org>
> > Index: linux-work/include/asm-powerpc/cputable.h
> > ===================================================================
> > --- linux-work.orig/include/asm-powerpc/cputable.h 2007-11-16
> > 16:14:29.000000000 +1100
> > +++ linux-work/include/asm-powerpc/cputable.h 2007-11-16
> > 16:19:35.000000000 +1100
> > @@ -138,6 +138,7 @@ extern void do_feature_fixups(unsigned l
> > #define CPU_FTR_FPU_UNAVAILABLE ASM_CONST(0x0000000000800000)
> > #define CPU_FTR_UNIFIED_ID_CACHE ASM_CONST(0x0000000001000000)
> > #define CPU_FTR_SPE ASM_CONST(0x0000000002000000)
> > +#define CPU_FTR_440A ASM_CONST(0x0000000004000000)
>
> Can we be more specific about what this feature really means.
>
> How about something like CPU_FTR_ENH_MCHCK or something like that.
Did that at first, then figured out that I indeed had 2 core manuals one
of them being labelled "A"... I'm trying to figure out what other
differences they may have to see whether I should stick to that CPU
feature or just remove it completely and do as Olof suggested.
Ben.
^ permalink raw reply
* Re: [POWERPC] [RFC] Fix 8xx tlbie definition
From: Vitaly Bordug @ 2007-11-16 22:28 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev
In-Reply-To: <1195247189.28865.174.camel@pasglop>
On Sat, 17 Nov 2007 08:06:29 +1100
Benjamin Herrenschmidt wrote:
>
> On Fri, 2007-11-16 at 11:28 -0600, Josh Boyer wrote:
> > Git commit e701d269aa28996f3502780951fe1b12d5d66b49 introduced an
> > incorrect definition for _tlbie on PowerPC 8xx platforms. Only the
> > address should be passed to the function. This patch corrects the
> > definition of _tlbie and the related tlb flushing functions for 8xx.
> >
> > Signed-off-by: Josh Boyer <jwboyer@linux.vnet.ibm.com>
>
> That conflicts with the patch I posted to fix it differently (I kept
> the additional argument).
>
Where can I grab it to give a try? My linuxppc archive is silent for some reason..
> Which one do we take ?
>
If your solution will work out, I'd agree with Kumar to have this thing consistent.
If not - It might be cheapier just to fix it this gross way, to keep 8xx stuff running.
--
Sincerely, Vitaly
^ permalink raw reply
* Re: [RFC/PATCH] powerpc: Fix powerpc 32 bits resource fixup for 64 bits resources
From: Vitaly Bordug @ 2007-11-16 22:36 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <20071116072916.ECE2FDDDFE@ozlabs.org>
On Fri, 16 Nov 2007 18:28:34 +1100
Benjamin Herrenschmidt wrote:
> The 32bits powerpc resource fixup code uses unsigned longs to do the
> offseting of resources which overflows on platforms such as 4xx where
> resources can be 64 bits.
>
> This fixes it by using resource_size_t instead.
>
> However, the IO stuff does rely on some 32 bits arithmetic, so we hack
> by cropping the result of the fixups for IO resources with a 32 bits
> mask.
>
> This isn't the prettiest but should work for now until we change the
> 32 bits PCI code to do IO mappings like 64 bits does, within a
> reserved are of the kernel address space.
>
> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> ---
>
> DO NOT MERGE YET ! This has only been tested with some preliminary PCI
> support code I have for Ebony, I haven't yet verified that the masking
> stuff works fine on 32 bits machines with multiple busses and negative
> offsets.
>
I can give it a try with some FSL boxes... This approach makes sense sense I think.
-V
> arch/powerpc/kernel/pci_32.c | 44
> +++++++++++++++++++++++-------------------- 1 file changed, 24
> insertions(+), 20 deletions(-)
>
> Index: linux-work/arch/powerpc/kernel/pci_32.c
> ===================================================================
> --- linux-work.orig/arch/powerpc/kernel/pci_32.c 2007-11-16
> 15:48:27.000000000 +1100 +++
> linux-work/arch/powerpc/kernel/pci_32.c 2007-11-16
> 15:55:54.000000000 +1100 @@ -104,7 +104,7 @@
> pcibios_fixup_resources(struct pci_dev * { struct pci_controller*
> hose = (struct pci_controller *)dev->sysdata; int i;
> - unsigned long offset;
> + resource_size_t offset, mask;
>
> if (!hose) {
> printk(KERN_ERR "No hose for PCI dev %s!\n",
> pci_name(dev)); @@ -123,15 +123,17 @@ pcibios_fixup_resources(struct
> pci_dev * continue;
> }
> offset = 0;
> + mask = (resource_size_t)-1;
> if (res->flags & IORESOURCE_MEM) {
> offset = hose->pci_mem_offset;
> } else if (res->flags & IORESOURCE_IO) {
> offset = (unsigned long) hose->io_base_virt
> - isa_io_base;
> + mask = 0xffffffffu;
> }
> if (offset != 0) {
> - res->start += offset;
> - res->end += offset;
> + res->start = (res->start + offset) & mask;
> + res->end = (res->end + offset) & mask;
> DBG("Fixup res %d (%lx) of dev %s: %llx ->
> %llx\n", i, res->flags, pci_name(dev),
> (u64)res->start - offset,
> (u64)res->start); @@ -147,30 +149,32 @@
> DECLARE_PCI_FIXUP_HEADER(PCI_ANY_ID, PC void
> pcibios_resource_to_bus(struct pci_dev *dev, struct pci_bus_region
> *region, struct resource *res) {
> - unsigned long offset = 0;
> + resource_size_t offset = 0, mask = (resource_size_t)-1;
> struct pci_controller *hose = dev->sysdata;
>
> - if (hose && res->flags & IORESOURCE_IO)
> + if (hose && res->flags & IORESOURCE_IO) {
> offset = (unsigned long)hose->io_base_virt -
> isa_io_base;
> - else if (hose && res->flags & IORESOURCE_MEM)
> + mask = 0xffffffffu;
> + } else if (hose && res->flags & IORESOURCE_MEM)
> offset = hose->pci_mem_offset;
> - region->start = res->start - offset;
> - region->end = res->end - offset;
> + region->start = (res->start - offset) & mask;
> + region->end = (res->end - offset) & mask;
> }
> EXPORT_SYMBOL(pcibios_resource_to_bus);
>
> void pcibios_bus_to_resource(struct pci_dev *dev, struct resource
> *res, struct pci_bus_region *region)
> {
> - unsigned long offset = 0;
> + resource_size_t offset = 0, mask = (resource_size_t)-1;
> struct pci_controller *hose = dev->sysdata;
>
> - if (hose && res->flags & IORESOURCE_IO)
> + if (hose && res->flags & IORESOURCE_IO) {
> offset = (unsigned long)hose->io_base_virt -
> isa_io_base;
> - else if (hose && res->flags & IORESOURCE_MEM)
> + mask = 0xffffffffu;
> + } else if (hose && res->flags & IORESOURCE_MEM)
> offset = hose->pci_mem_offset;
> - res->start = region->start + offset;
> - res->end = region->end + offset;
> + res->start = (region->start + offset) & mask;
> + res->end = (region->end + offset) & mask;
> }
> EXPORT_SYMBOL(pcibios_bus_to_resource);
>
> @@ -334,9 +338,9 @@ static int __init
> pci_relocate_bridge_resource(struct pci_bus *bus, int i)
> {
> struct resource *res, *pr, *conflict;
> - unsigned long try, size;
> - int j;
> + resource_size_t try, size;
> struct pci_bus *parent = bus->parent;
> + int j;
>
> if (parent == NULL) {
> /* shouldn't ever happen */
> @@ -438,7 +442,7 @@ update_bridge_resource(struct pci_dev *d
> u8 io_base_lo, io_limit_lo;
> u16 mem_base, mem_limit;
> u16 cmd;
> - unsigned long start, end, off;
> + resource_size_t start, end, off;
> struct pci_controller *hose = dev->sysdata;
>
> if (!hose) {
> @@ -1157,8 +1161,8 @@ void pcibios_fixup_bus(struct pci_bus *b
> res->end = IO_SPACE_LIMIT;
> res->flags = IORESOURCE_IO;
> }
> - res->start += io_offset;
> - res->end += io_offset;
> + res->start = (res->start + io_offset) & 0xffffffffu;
> + res->end = (res->end + io_offset) & 0xffffffffu;
>
> for (i = 0; i < 3; ++i) {
> res = &hose->mem_resources[i];
> @@ -1183,8 +1187,8 @@ void pcibios_fixup_bus(struct pci_bus *b
> if (!res->flags || bus->self->transparent)
> continue;
> if (io_offset && (res->flags &
> IORESOURCE_IO)) {
> - res->start += io_offset;
> - res->end += io_offset;
> + res->start = (res->start +
> io_offset) & 0xffffffffu;
> + res->end = (res->end + io_offset) &
> 0xffffffffu; } else if (hose->pci_mem_offset
> && (res->flags & IORESOURCE_MEM))
> { res->start += hose->pci_mem_offset;
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
--
Sincerely, Vitaly
^ permalink raw reply
* Re: 85xx software reset problems from paulus.git
From: robert lazarski @ 2007-11-16 22:01 UTC (permalink / raw)
Cc: linuxppc-embedded
In-Reply-To: <0B4C1069-9D89-44E8-89F7-9E7CE07B03DF@kernel.crashing.org>
On Nov 16, 2007 4:46 PM, Kumar Gala <galak@kernel.crashing.org> wrote:
>
>
> On Nov 16, 2007, at 3:28 PM, robert lazarski wrote:
>
> > On Nov 16, 2007 3:44 PM, robert lazarski <robertlazarski@gmail.com>
> > wrote:
> >> On Nov 16, 2007 10:27 AM, Clemens Koller
> >> <clemens.koller@anagramm.de> wrote:
> >>> The SRESET# (pin AF20) is the soft reset input, causes
> >>> an mcp assertion to the core.... (RTFM)
> >>>
> >>
> >> That's what we are doing. The 85xx docs say "Soft reset. Causes a
> >> machine check interrupt to the e500 core. Note that if the e500 core
> >> is not configured to process machine check interrupts, the assertion
> >> of SRESET causes a core checkstop. SRESET need not be asserted during
> >> a hard reset."
> >>
> >
> > Sorry for replying to myself, but thought I'd mention SRESET works
> > fine on 85xx 2.6.23 , ie, the board resets after kernel panic. It
> > doesn't work for me on 2.6.24rc2 .
>
> What actual 85xx are you using?
>
> - k
>
Custom 8548 board. I'm using the cds 85xx code for a reference and I
calling the same reset functions.
Robert
^ permalink raw reply
* Re: [PATCH] powerpc: Fix 44x Machine Check handling
From: Kumar Gala @ 2007-11-16 21:55 UTC (permalink / raw)
To: benh; +Cc: Olof Johansson, linuxppc-dev
In-Reply-To: <1195199141.28865.144.camel@pasglop>
On Nov 16, 2007, at 1:45 AM, Benjamin Herrenschmidt wrote:
>
> On Fri, 2007-11-16 at 18:41 +1100, Benjamin Herrenschmidt wrote:
>> On Fri, 2007-11-16 at 01:40 -0600, Olof Johansson wrote:
>>> I'm not sure I like this. It introduces another cpu feature flag,
>>> that we'll soon run out of if it's used to signify version info per
>>> implementation like this.
>>>
>>> 1) The SET_IVOR could be done from the cpu_setups for 440A instead
>>> (i.e. introduce one).
>>>
>>> 2) Please just move the machine check handlers out to individual
>>> ones
>>> instead of using the generic one. That way you don't need runtime
>>> checks
>>> between the two (they don't seem to share much of it as-is anyway).
>>>
>>> With the above two changes, you shouldn't need the feature bit any
>>> more.
>>
>> We can easily make the cpu features bigger ... But ok, I'll have a
>> look
>> at doing it the way you suggest.
>
> Note that first, I'd like to figure out if there are other relevant
> differences with 440A ... arch/ppc didn't list any and diff'ing PDFs
> is
> not fun but if people around here know, please speak up
I think it added isel support.
- k
^ permalink raw reply
* Re: [PATCH] powerpc: Fix 44x Machine Check handling
From: Kumar Gala @ 2007-11-16 21:54 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <20071116072149.350ADDDDF4@ozlabs.org>
On Nov 16, 2007, at 1:21 AM, Benjamin Herrenschmidt wrote:
> This removes the old CONFIG_440A which was a pain for multiplatform
> kernel and wasn't set properly by default and replaces it with a
> CPU feature. This makes Machine Check reporting work correctly on
> my Ebony (440GP) board.
>
> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> ---
>
> Note: I'm only setting it for 440GX and EPx as the old code did,
> I haven't checked whether other new 440 chips such as SPe also
> need that bit set.
>
> arch/powerpc/kernel/cputable.c | 10 +++++-----
> arch/powerpc/kernel/head_44x.S | 11 ++++++-----
> arch/powerpc/kernel/traps.c | 19 ++++++++-----------
> arch/powerpc/platforms/44x/Kconfig | 5 -----
> include/asm-powerpc/cputable.h | 3 ++-
> include/asm-powerpc/reg_booke.h | 2 +-
> 6 files changed, 22 insertions(+), 28 deletions(-)
>
[snip]
> Index: linux-work/include/asm-powerpc/cputable.h
> ===================================================================
> --- linux-work.orig/include/asm-powerpc/cputable.h 2007-11-16
> 16:14:29.000000000 +1100
> +++ linux-work/include/asm-powerpc/cputable.h 2007-11-16
> 16:19:35.000000000 +1100
> @@ -138,6 +138,7 @@ extern void do_feature_fixups(unsigned l
> #define CPU_FTR_FPU_UNAVAILABLE ASM_CONST(0x0000000000800000)
> #define CPU_FTR_UNIFIED_ID_CACHE ASM_CONST(0x0000000001000000)
> #define CPU_FTR_SPE ASM_CONST(0x0000000002000000)
> +#define CPU_FTR_440A ASM_CONST(0x0000000004000000)
Can we be more specific about what this feature really means.
How about something like CPU_FTR_ENH_MCHCK or something like that.
- k
^ permalink raw reply
* Re: 85xx software reset problems from paulus.git
From: Kumar Gala @ 2007-11-16 21:46 UTC (permalink / raw)
To: robert lazarski; +Cc: linuxppc-embedded
In-Reply-To: <f87675ee0711161328u3127de3bjdd6341cdf11cd626@mail.gmail.com>
On Nov 16, 2007, at 3:28 PM, robert lazarski wrote:
> On Nov 16, 2007 3:44 PM, robert lazarski <robertlazarski@gmail.com>
> wrote:
>> On Nov 16, 2007 10:27 AM, Clemens Koller
>> <clemens.koller@anagramm.de> wrote:
>>> The SRESET# (pin AF20) is the soft reset input, causes
>>> an mcp assertion to the core.... (RTFM)
>>>
>>
>> That's what we are doing. The 85xx docs say "Soft reset. Causes a
>> machine check interrupt to the e500 core. Note that if the e500 core
>> is not configured to process machine check interrupts, the assertion
>> of SRESET causes a core checkstop. SRESET need not be asserted during
>> a hard reset."
>>
>
> Sorry for replying to myself, but thought I'd mention SRESET works
> fine on 85xx 2.6.23 , ie, the board resets after kernel panic. It
> doesn't work for me on 2.6.24rc2 .
What actual 85xx are you using?
- k
^ permalink raw reply
* Re: Latest paulus.git PCI broken on mpc8540?
From: Kumar Gala @ 2007-11-16 21:45 UTC (permalink / raw)
To: benh; +Cc: linuxppc-embedded
In-Reply-To: <1195247357.28865.178.camel@pasglop>
On Nov 16, 2007, at 3:09 PM, Benjamin Herrenschmidt wrote:
>
> On Fri, 2007-11-16 at 13:18 -0600, Kumar Gala wrote:
>>
>>
>> Well, for one the generic pci code will complain if its not able to
>> allocate the resource which is the true failure.
>>
>> I'm thinking maybe we just make these pr_debug() instead of standard
>> printk?
>
> I was thinking about changing the message to "cannot allocate initial
> resource, will reallocate" or something like that. That is, make it
> clear it's non fatal.
Yeah, something that on those lines would be good, and maybe mark them
KERN_WARNING instead of KERN_ERR.
- k
^ permalink raw reply
* Re: [POWERPC] [RFC] Fix 8xx tlbie definition
From: Kumar Gala @ 2007-11-16 21:29 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev
In-Reply-To: <1195247189.28865.174.camel@pasglop>
On Nov 16, 2007, at 3:06 PM, Benjamin Herrenschmidt wrote:
>
> On Fri, 2007-11-16 at 11:28 -0600, Josh Boyer wrote:
>> Git commit e701d269aa28996f3502780951fe1b12d5d66b49 introduced an
>> incorrect
>> definition for _tlbie on PowerPC 8xx platforms. Only the address
>> should be
>> passed to the function. This patch corrects the definition of
>> _tlbie and the
>> related tlb flushing functions for 8xx.
>>
>> Signed-off-by: Josh Boyer <jwboyer@linux.vnet.ibm.com>
>
> That conflicts with the patch I posted to fix it differently (I kept
> the
> additional argument).
>
> Which one do we take ?
Let's make _tlbia/_tlbie consistent on all archs.
- k
^ permalink raw reply
* Re: 85xx software reset problems from paulus.git
From: robert lazarski @ 2007-11-16 21:28 UTC (permalink / raw)
Cc: linuxppc-embedded
In-Reply-To: <f87675ee0711161244h46c23d8byadaf1abb923b3971@mail.gmail.com>
On Nov 16, 2007 3:44 PM, robert lazarski <robertlazarski@gmail.com> wrote:
> On Nov 16, 2007 10:27 AM, Clemens Koller <clemens.koller@anagramm.de> wrote:
> > The SRESET# (pin AF20) is the soft reset input, causes
> > an mcp assertion to the core.... (RTFM)
> >
>
> That's what we are doing. The 85xx docs say "Soft reset. Causes a
> machine check interrupt to the e500 core. Note that if the e500 core
> is not configured to process machine check interrupts, the assertion
> of SRESET causes a core checkstop. SRESET need not be asserted during
> a hard reset."
>
Sorry for replying to myself, but thought I'd mention SRESET works
fine on 85xx 2.6.23 , ie, the board resets after kernel panic. It
doesn't work for me on 2.6.24rc2 .
Robert
^ permalink raw reply
* Re: Latest paulus.git PCI broken on mpc8540?
From: Benjamin Herrenschmidt @ 2007-11-16 21:20 UTC (permalink / raw)
To: Clemens Koller; +Cc: linuxppc-embedded
In-Reply-To: <473E084B.4080703@anagramm.de>
>
> I don't know much of the code, so, propably a stupid question:
> Can we avoid to do the initial resource allocation, when it's known to fail?
>
> It seems to me like things are done twice here:
> 1. try
> 2. reallocate
> 3. retry
Well, we don't know it's going to fail until we try :-)
Ben.
^ permalink raw reply
* Re: Latest paulus.git PCI broken on mpc8540?
From: Clemens Koller @ 2007-11-16 21:14 UTC (permalink / raw)
To: benh; +Cc: linuxppc-embedded
In-Reply-To: <1195247357.28865.178.camel@pasglop>
Hi, Ben!
Benjamin Herrenschmidt schrieb:
> On Fri, 2007-11-16 at 13:18 -0600, Kumar Gala wrote:
>>
>> Well, for one the generic pci code will complain if its not able to
>> allocate the resource which is the true failure.
>>
>> I'm thinking maybe we just make these pr_debug() instead of standard
>> printk?
>
> I was thinking about changing the message to "cannot allocate initial
> resource, will reallocate" or something like that. That is, make it
> clear it's non fatal.
I don't know much of the code, so, propably a stupid question:
Can we avoid to do the initial resource allocation, when it's known to fail?
It seems to me like things are done twice here:
1. try
2. reallocate
3. retry
Regards,
--
Clemens Koller
_______________________________
R&D Imaging Devices
Anagramm GmbH
Rupert-Mayer-Str. 45/1
81379 Muenchen
Germany
http://www.anagramm-technology.com
Phone: +49-89-741518-50
Fax: +49-89-741518-19
^ permalink raw reply
* Re: [POWERPC] [RFC] Fix 8xx tlbie definition
From: Benjamin Herrenschmidt @ 2007-11-16 21:06 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev
In-Reply-To: <20071116112822.37a238c0@weaponx>
On Fri, 2007-11-16 at 11:28 -0600, Josh Boyer wrote:
> Git commit e701d269aa28996f3502780951fe1b12d5d66b49 introduced an incorrect
> definition for _tlbie on PowerPC 8xx platforms. Only the address should be
> passed to the function. This patch corrects the definition of _tlbie and the
> related tlb flushing functions for 8xx.
>
> Signed-off-by: Josh Boyer <jwboyer@linux.vnet.ibm.com>
That conflicts with the patch I posted to fix it differently (I kept the
additional argument).
Which one do we take ?
Ben.
^ permalink raw reply
* Re: Latest paulus.git PCI broken on mpc8540?
From: Benjamin Herrenschmidt @ 2007-11-16 21:09 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-embedded
In-Reply-To: <A4E1A594-5A31-4EFE-B4F9-E4B24F9207F7@kernel.crashing.org>
On Fri, 2007-11-16 at 13:18 -0600, Kumar Gala wrote:
>
>
> Well, for one the generic pci code will complain if its not able to
> allocate the resource which is the true failure.
>
> I'm thinking maybe we just make these pr_debug() instead of standard
> printk?
I was thinking about changing the message to "cannot allocate initial
resource, will reallocate" or something like that. That is, make it
clear it's non fatal.
Ben.
^ permalink raw reply
* Re: [PATCH] powerpc: Fix 44x Machine Check handling
From: Benjamin Herrenschmidt @ 2007-11-16 21:03 UTC (permalink / raw)
To: Josh Boyer; +Cc: Olof Johansson, linuxppc-dev
In-Reply-To: <20071116085813.3cebed79@weaponx>
On Fri, 2007-11-16 at 08:58 -0600, Josh Boyer wrote:
> > 2) Please just move the machine check handlers out to individual
> ones
> > instead of using the generic one. That way you don't need runtime
> checks
> > between the two (they don't seem to share much of it as-is anyway).
>
> Anton pinged me about cleaning that up a couple months ago. I have a
> half-baked patch for it somewhere, but I agree having 4xx set a ppc_md
> specific handler would be a good idea.
No need. The 2 asm implementation can branch to 2 different C functions
and the IVOR will be set to the right one.
Ben.
^ permalink raw reply
* Re: [PATCH] powerpc: Add xmon function to dump 44x TLB
From: Benjamin Herrenschmidt @ 2007-11-16 21:04 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev
In-Reply-To: <5581b33006faf83955d35e9e9a091272@kernel.crashing.org>
On Fri, 2007-11-16 at 17:09 +0100, Segher Boessenkool wrote:
> >> +#ifdef CONFIG_44x
> >> +static void dump_tlb_44x(void);
> >> +#endif
> >
> > No need to #ifdef this...
> >
> >> +#ifdef CONFIG_44x
> >> +static void dump_tlb_44x(void)
> >> +{
> >
> > ...or this.
>
> Erm actually, that last one would give you a compiler warning ("function
> defined but not used"), unless you convert the point where it is used to
> a plain "if" too -- probably not worth it until we have 32-bit
> multiplatform
> support :-)
We do have multiplatform support but not accross CPU families :-)
Ben.
^ permalink raw reply
* Re: [PATCH] powerpc: Add xmon function to dump 44x TLB
From: Benjamin Herrenschmidt @ 2007-11-16 21:03 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev
In-Reply-To: <4ccc68f867a65d70f5d1e3ee946de4d1@kernel.crashing.org>
On Fri, 2007-11-16 at 16:54 +0100, Segher Boessenkool wrote:
> > +#ifdef CONFIG_44x
> > +static void dump_tlb_44x(void);
> > +#endif
>
> No need to #ifdef this...
>
> > +#ifdef CONFIG_44x
> > +static void dump_tlb_44x(void)
> > +{
>
> ...or this.
I don't want to require binutils to understand the 44x TLB ops
Ben.
^ permalink raw reply
* Re: 85xx software reset problems from paulus.git
From: robert lazarski @ 2007-11-16 20:44 UTC (permalink / raw)
Cc: linuxppc-embedded
In-Reply-To: <473DB6DF.9010804@anagramm.de>
On Nov 16, 2007 10:27 AM, Clemens Koller <clemens.koller@anagramm.de> wrote:
> Hello, Robert!
>
> robert lazarski schrieb:
> > Hi all, on my custom 85xx board I can't do a soft reset. I'm using
> > u-boot 1.3rc3 that has the latest cpu/mpc85xx/cpu.c patch to fix some
> > type of reset problem. When I press the software reset button on my
> > board after my nfs kernel panic, I get this:
>
> Please define "software reset button" in your case. :-)
> I consider a "button" clearly as hardware.
>
I mean a hardware button that calls SRESET , ie, Soft reset machine check.
<snip>
>
> The SRESET# (pin AF20) is the soft reset input, causes
> an mcp assertion to the core.... (RTFM)
>
That's what we are doing. The 85xx docs say "Soft reset. Causes a
machine check interrupt to the e500 core. Note that if the e500 core
is not configured to process machine check interrupts, the assertion
of SRESET causes a core checkstop. SRESET need not be asserted during
a hard reset."
Is the 85xx kernel "not configured to process machine check
interrupts" ? Do I need to do that myself in my boards restart
function via the special registers? Is there code already for this?
Robert
^ permalink raw reply
* Re: [PATCH] [POWERPC] Add SPRN for Embedded registers specified in PowerISA 2.04
From: Kumar Gala @ 2007-11-16 20:09 UTC (permalink / raw)
To: Olof Johansson; +Cc: linuxppc-dev
In-Reply-To: <20071116200510.GA18481@lixom.net>
On Nov 16, 2007, at 2:05 PM, Olof Johansson wrote:
> Hi,
>
>
> On Fri, Nov 16, 2007 at 01:59:03PM -0600, Kumar Gala wrote:
>> +#define SPRN_SPRG8 0x25C /* Special Purpose Register General 8 */
>> +#define SPRN_SPRG9 0x25D /* Special Purpose Register General 8 */
>
> Cut and paste error in comment :)
thanks, git-commit --amend fixed ;)
- k
^ permalink raw reply
* Re: [PATCH] [POWERPC] Add SPRN for Embedded registers specified in PowerISA 2.04
From: Olof Johansson @ 2007-11-16 20:05 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <Pine.LNX.4.64.0711161358280.24588@blarg.am.freescale.net>
Hi,
On Fri, Nov 16, 2007 at 01:59:03PM -0600, Kumar Gala wrote:
> +#define SPRN_SPRG8 0x25C /* Special Purpose Register General 8 */
> +#define SPRN_SPRG9 0x25D /* Special Purpose Register General 8 */
Cut and paste error in comment :)
-Olof
^ permalink raw reply
* [PATCH] [POWERPC] Add SPRN for Embedded registers specified in PowerISA 2.04
From: Kumar Gala @ 2007-11-16 19:59 UTC (permalink / raw)
To: linuxppc-dev
* Added SPRN for new architectural features added for embedded:
- Alternate Time Base (ATB, ATBL, ATBU)
- Doorbell Interrupts (IVOR36, IVOR37)
- SPRG8/9
- External Proxy (EPR)
- External PID load/store (EPLC, EPSC)
* Added BUCSR for Freescale Embedded Processors
* Moved around MAS7 so its in numeric order
---
as normal, this is my git tree for 2.6.25
include/asm-powerpc/reg_booke.h | 13 ++++++++++++-
1 files changed, 12 insertions(+), 1 deletions(-)
diff --git a/include/asm-powerpc/reg_booke.h b/include/asm-powerpc/reg_booke.h
index 8fdc2b4..d596439 100644
--- a/include/asm-powerpc/reg_booke.h
+++ b/include/asm-powerpc/reg_booke.h
@@ -123,16 +123,23 @@
#define SPRN_SPEFSCR 0x200 /* SPE & Embedded FP Status & Control */
#define SPRN_BBEAR 0x201 /* Branch Buffer Entry Address Register */
#define SPRN_BBTAR 0x202 /* Branch Buffer Target Address Register */
+#define SPRN_ATB 0x20E /* Alternate Time Base */
+#define SPRN_ATBL 0x20E /* Alternate Time Base Lower */
+#define SPRN_ATBU 0x20F /* Alternate Time Base Upper */
#define SPRN_IVOR32 0x210 /* Interrupt Vector Offset Register 32 */
#define SPRN_IVOR33 0x211 /* Interrupt Vector Offset Register 33 */
#define SPRN_IVOR34 0x212 /* Interrupt Vector Offset Register 34 */
#define SPRN_IVOR35 0x213 /* Interrupt Vector Offset Register 35 */
+#define SPRN_IVOR36 0x214 /* Interrupt Vector Offset Register 36 */
+#define SPRN_IVOR37 0x215 /* Interrupt Vector Offset Register 37 */
#define SPRN_MCSRR0 0x23A /* Machine Check Save and Restore Register 0 */
#define SPRN_MCSRR1 0x23B /* Machine Check Save and Restore Register 1 */
#define SPRN_MCSR 0x23C /* Machine Check Status Register */
#define SPRN_MCAR 0x23D /* Machine Check Address Register */
#define SPRN_DSRR0 0x23E /* Debug Save and Restore Register 0 */
#define SPRN_DSRR1 0x23F /* Debug Save and Restore Register 1 */
+#define SPRN_SPRG8 0x25C /* Special Purpose Register General 8 */
+#define SPRN_SPRG9 0x25D /* Special Purpose Register General 8 */
#define SPRN_MAS0 0x270 /* MMU Assist Register 0 */
#define SPRN_MAS1 0x271 /* MMU Assist Register 1 */
#define SPRN_MAS2 0x272 /* MMU Assist Register 2 */
@@ -140,15 +147,18 @@
#define SPRN_MAS4 0x274 /* MMU Assist Register 4 */
#define SPRN_MAS5 0x275 /* MMU Assist Register 5 */
#define SPRN_MAS6 0x276 /* MMU Assist Register 6 */
-#define SPRN_MAS7 0x3b0 /* MMU Assist Register 7 */
#define SPRN_PID1 0x279 /* Process ID Register 1 */
#define SPRN_PID2 0x27A /* Process ID Register 2 */
#define SPRN_TLB0CFG 0x2B0 /* TLB 0 Config Register */
#define SPRN_TLB1CFG 0x2B1 /* TLB 1 Config Register */
+#define SPRN_EPR 0x2BE /* External Proxy Register */
#define SPRN_CCR1 0x378 /* Core Configuration Register 1 */
#define SPRN_ZPR 0x3B0 /* Zone Protection Register (40x) */
+#define SPRN_MAS7 0x3B0 /* MMU Assist Register 7 */
#define SPRN_MMUCR 0x3B2 /* MMU Control Register */
#define SPRN_CCR0 0x3B3 /* Core Configuration Register 0 */
+#define SPRN_EPLC 0x3B3 /* External Process ID Load Context */
+#define SPRN_EPSC 0x3B4 /* External Process ID Store Context */
#define SPRN_SGR 0x3B9 /* Storage Guarded Register */
#define SPRN_DCWR 0x3BA /* Data Cache Write-thru Register */
#define SPRN_SLER 0x3BB /* Little-endian real mode */
@@ -159,6 +169,7 @@
#define SPRN_L1CSR0 0x3F2 /* L1 Cache Control and Status Register 0 */
#define SPRN_L1CSR1 0x3F3 /* L1 Cache Control and Status Register 1 */
#define SPRN_PIT 0x3DB /* Programmable Interval Timer */
+#define SPRN_BUCSR 0x3F5 /* Branch Unit Control and Status */
#define SPRN_DCCR 0x3FA /* Data Cache Cacheability Register */
#define SPRN_ICCR 0x3FB /* Instruction Cache Cacheability Register */
#define SPRN_SVR 0x3FF /* System Version Register */
--
1.5.3.4
^ permalink raw reply related
* Re: [PATCH] [POWERPC] 4xx: Use virtual PVR value to init FPU on arch/ppc 440EP
From: Josh Boyer @ 2007-11-16 19:23 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <96AAE1CB-3F7F-4231-AD52-01F358E01594@kernel.crashing.org>
On Fri, 16 Nov 2007 13:20:09 -0600
Kumar Gala <galak@kernel.crashing.org> wrote:
>
> On Nov 16, 2007, at 11:29 AM, Josh Boyer wrote:
>
> > This fixes arch/ppc 440EP platforms to setup the FPU correctly. A
> > virtual
> > PVR is used, as 440GR platforms share an identical hardware PVR
> > value and do
> > not have an FPU.
> >
> > Signed-off-by: Josh Boyer <jwboyer@linux.vnet.ibm.com>
> > Index: linux-2.6/arch/ppc/kernel/setup.c
> > ===================================================================
> > --- linux-2.6.orig/arch/ppc/kernel/setup.c
> > +++ linux-2.6/arch/ppc/kernel/setup.c
> > @@ -312,7 +312,14 @@ early_init(int r3, int r4, int r5)
> > * Identify the CPU type and fix up code sections
> > * that depend on which cpu we have.
> > */
> > +#if defined(CONFIG_440EP) && defined(CONFIG_PPC_FPU)
> > + /* We pass the virtual PVR here for 440EP as 440EP and 440GR have
> > + * identical PVRs and there is no reliable way to check for the FPU
> > + */
> > + spec = identify_cpu(offset, (mfspr(SPRN_PVR) | 0x8));
> > +#else
> > spec = identify_cpu(offset, mfspr(SPRN_PVR));
> > +#endif
> > do_feature_fixups(spec->cpu_features,
> > PTRRELOC(&__start___ftr_fixup),
> > PTRRELOC(&__stop___ftr_fixup));
>
> Are we really adding support for new processors to arch/ppc?
No. This is to continue to support 440EP FPU in arch/ppc. Commit
d1dfc35d3a62 switched the cputable around for EP(x)/GR(x) and arch/ppc wasn't fixed up. So without the above patch, 440EP gets detected as 440GR and the FPU isn't initialized properly.
josh
^ permalink raw reply
* Re: [PATCH] [POWERPC] 4xx: Use virtual PVR value to init FPU on arch/ppc 440EP
From: Kumar Gala @ 2007-11-16 19:20 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev
In-Reply-To: <20071116112956.0f1ca5b1@weaponx>
On Nov 16, 2007, at 11:29 AM, Josh Boyer wrote:
> This fixes arch/ppc 440EP platforms to setup the FPU correctly. A
> virtual
> PVR is used, as 440GR platforms share an identical hardware PVR
> value and do
> not have an FPU.
>
> Signed-off-by: Josh Boyer <jwboyer@linux.vnet.ibm.com>
> Index: linux-2.6/arch/ppc/kernel/setup.c
> ===================================================================
> --- linux-2.6.orig/arch/ppc/kernel/setup.c
> +++ linux-2.6/arch/ppc/kernel/setup.c
> @@ -312,7 +312,14 @@ early_init(int r3, int r4, int r5)
> * Identify the CPU type and fix up code sections
> * that depend on which cpu we have.
> */
> +#if defined(CONFIG_440EP) && defined(CONFIG_PPC_FPU)
> + /* We pass the virtual PVR here for 440EP as 440EP and 440GR have
> + * identical PVRs and there is no reliable way to check for the FPU
> + */
> + spec = identify_cpu(offset, (mfspr(SPRN_PVR) | 0x8));
> +#else
> spec = identify_cpu(offset, mfspr(SPRN_PVR));
> +#endif
> do_feature_fixups(spec->cpu_features,
> PTRRELOC(&__start___ftr_fixup),
> PTRRELOC(&__stop___ftr_fixup));
Are we really adding support for new processors to arch/ppc?
- k
^ 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