* Re: [PATCH 3/6] 8xx: get rid of _PAGE_HWWRITE dependency in MMU.
From: Benjamin Herrenschmidt @ 2009-10-05 20:17 UTC (permalink / raw)
To: Joakim Tjernlund; +Cc: Scott Wood, linuxppc-dev@ozlabs.org, Rex Feany
In-Reply-To: <1254744999-3158-4-git-send-email-Joakim.Tjernlund@transmode.se>
On Mon, 2009-10-05 at 14:16 +0200, Joakim Tjernlund wrote:
> Update the TLB asm to make proper use of _PAGE_DIRY and _PAGE_ACCESSED.
> Pros:
> - I/D TLB Miss never needs to write to the linux pte.
> - _PAGE_ACCESSED is only set on I/D TLB Error fixing accounting
> - _PAGE_DIRTY is mapped to 0x100, the changed bit, and is set directly
> when a page has been made dirty.
Not sure here. You seem to still set those from asm. Is that necessary ?
The approach I take on BookE is to simply not set these from asm, -and-
(this is important) not set write permission if dirty is not set in
the TLB miss and set no access permission at all when accessed is not
set. This is important or we'll miss dirty updates which can
be fatal.
The C code in handle_pte_fault() will fixup missing access and dirty
if necessary and flush.
Also look at the 440 code, I think you could simplify your
implementation using similar techniques, such as andc of PTE against
requested bits etc... and thus maybe save a couple of insns.
Cheers,
Ben.
> - Proper RO/RW mapping of user space.
> - Free up 2 SW TLB bits in the linux pte(add back _PAGE_WRITETHRU ?)
> Cons:
> - 4 more instructions in I/D TLB Miss, but the since the linux pte is
> not written anymore, it should still be a win.
> ---
> arch/powerpc/include/asm/pte-8xx.h | 9 +-
> arch/powerpc/kernel/head_8xx.S | 163 ++++++++++++++++++++++++++----------
> 2 files changed, 122 insertions(+), 50 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/pte-8xx.h b/arch/powerpc/include/asm/pte-8xx.h
> index 8c6e312..af541a2 100644
> --- a/arch/powerpc/include/asm/pte-8xx.h
> +++ b/arch/powerpc/include/asm/pte-8xx.h
> @@ -32,22 +32,21 @@
> #define _PAGE_FILE 0x0002 /* when !present: nonlinear file mapping */
> #define _PAGE_NO_CACHE 0x0002 /* I: cache inhibit */
> #define _PAGE_SHARED 0x0004 /* No ASID (context) compare */
> +#define _PAGE_DIRTY 0x0100 /* C: page changed */
>
> /* These five software bits must be masked out when the entry is loaded
> * into the TLB.
> */
> #define _PAGE_EXEC 0x0008 /* software: i-cache coherency required */
> #define _PAGE_GUARDED 0x0010 /* software: guarded access */
> -#define _PAGE_DIRTY 0x0020 /* software: page changed */
> -#define _PAGE_RW 0x0040 /* software: user write access allowed */
> -#define _PAGE_ACCESSED 0x0080 /* software: page referenced */
> +#define _PAGE_USER 0x0020 /* software: User space access */
>
> /* Setting any bits in the nibble with the follow two controls will
> * require a TLB exception handler change. It is assumed unused bits
> * are always zero.
> */
> -#define _PAGE_HWWRITE 0x0100 /* h/w write enable: never set in Linux PTE */
> -#define _PAGE_USER 0x0800 /* One of the PP bits, the other is USER&~RW */
> +#define _PAGE_RW 0x0400 /* lsb PP bits */
> +#define _PAGE_ACCESSED 0x0800 /* msb PP bits */
>
> #define _PMD_PRESENT 0x0001
> #define _PMD_BAD 0x0ff0
> diff --git a/arch/powerpc/kernel/head_8xx.S b/arch/powerpc/kernel/head_8xx.S
> index 118bb05..b1f72d9 100644
> --- a/arch/powerpc/kernel/head_8xx.S
> +++ b/arch/powerpc/kernel/head_8xx.S
> @@ -333,21 +333,15 @@ InstructionTLBMiss:
> mfspr r11, SPRN_MD_TWC /* ....and get the pte address */
> lwz r10, 0(r11) /* Get the pte */
>
> -#ifdef CONFIG_SWAP
> - /* do not set the _PAGE_ACCESSED bit of a non-present page */
> - andi. r11, r10, _PAGE_PRESENT
> - beq 4f
> - ori r10, r10, _PAGE_ACCESSED
> - mfspr r11, SPRN_MD_TWC /* get the pte address again */
> - stw r10, 0(r11)
> -4:
> -#else
> - ori r10, r10, _PAGE_ACCESSED
> - stw r10, 0(r11)
> -#endif
> -
> + andi. r11, r10, _PAGE_USER | _PAGE_ACCESSED
> + cmpwi cr0, r11, _PAGE_USER | _PAGE_ACCESSED
> + beq+ cr0, 5f /* branch if access allowed */
> + rlwinm r10, r10, 0, 22, 19 /* r10 &= ~(_PAGE_ACCESSED | _PAGE_RW) */
> + b 6f
> +5: xori r10, r10, _PAGE_RW /* invert RW bit */
> +6:
> /* The Linux PTE won't go exactly into the MMU TLB.
> - * Software indicator bits 21, 22 and 28 must be clear.
> + * Software indicator bit 28 must be clear.
> * Software indicator bits 24, 25, 26, and 27 must be
> * set. All other Linux PTE bits control the behavior
> * of the MMU.
> @@ -409,21 +403,15 @@ DataStoreTLBMiss:
> DO_8xx_CPU6(0x3b80, r3)
> mtspr SPRN_MD_TWC, r11
>
> -#ifdef CONFIG_SWAP
> - /* do not set the _PAGE_ACCESSED bit of a non-present page */
> - andi. r11, r10, _PAGE_PRESENT
> - beq 4f
> - ori r10, r10, _PAGE_ACCESSED
> -4:
> - /* and update pte in table */
> -#else
> - ori r10, r10, _PAGE_ACCESSED
> -#endif
> - mfspr r11, SPRN_MD_TWC /* get the pte address again */
> - stw r10, 0(r11)
> -
> + andi. r11, r10, _PAGE_USER | _PAGE_ACCESSED
> + cmpwi cr0, r11, _PAGE_USER | _PAGE_ACCESSED
> + beq+ cr0, 5f /* branch if access allowed */
> + rlwinm r10, r10, 0, 22, 19 /* r10 &= ~(_PAGE_ACCESSED | _PAGE_RW) */
> + b 6f
> +5: xori r10, r10, _PAGE_RW /* invert RW bit */
> +6:
> /* The Linux PTE won't go exactly into the MMU TLB.
> - * Software indicator bits 21, 22 and 28 must be clear.
> + * Software indicator bit 28 must be clear.
> * Software indicator bits 24, 25, 26, and 27 must be
> * set. All other Linux PTE bits control the behavior
> * of the MMU.
> @@ -448,6 +436,91 @@ DataStoreTLBMiss:
> */
> . = 0x1300
> InstructionTLBError:
> +#ifdef CONFIG_8xx_CPU6
> + stw r3, 8(r0)
> +#endif
> + DO_8xx_CPU6(0x3f80, r3)
> + mtspr SPRN_M_TW, r10 /* Save a couple of working registers */
> + mfcr r10
> + stw r10, 0(r0)
> + stw r11, 4(r0)
> +
> + mfspr r11, SPRN_SRR1
> + andis. r11, r11, 0x5000 /* no translation, guarded */
> + bne 2f
> +
> + mfspr r10, SPRN_SRR0 /* Get effective address of fault */
> +#ifdef CONFIG_8xx_CPU15
> + addi r11, r10, 0x1000
> + tlbie r11
> + addi r11, r10, -0x1000
> + tlbie r11
> +#endif
> + DO_8xx_CPU6(0x3780, r3)
> + mtspr SPRN_MD_EPN, r10 /* Have to use MD_EPN for walk, MI_EPN can't */
> + mfspr r10, SPRN_M_TWB /* Get level 1 table entry address */
> +
> + /* If we are faulting a kernel address, we have to use the
> + * kernel page tables.
> + */
> + andi. r11, r10, 0x0800 /* Address >= 0x80000000 */
> + beq 3f
> + lis r11, swapper_pg_dir@h
> + ori r11, r11, swapper_pg_dir@l
> + rlwimi r10, r11, 0, 2, 19
> +3:
> + lwz r11, 0(r10) /* Get the level 1 entry */
> + rlwinm. r10, r11,0,0,19 /* Extract page descriptor page address */
> + beq 2f /* If zero, don't try to find a pte */
> +
> + /* We have a pte table, so load the MI_TWC with the attributes
> + * for this "segment."
> + */
> + ori r11,r11,1 /* Set valid bit */
> + DO_8xx_CPU6(0x2b80, r3)
> + mtspr SPRN_MI_TWC, r11 /* Set segment attributes */
> + DO_8xx_CPU6(0x3b80, r3)
> + mtspr SPRN_MD_TWC, r11 /* Load pte table base address */
> +
> + mfspr r11, SPRN_SRR1
> + andi. r11, r11, 0x4000 /* MSR[PR] */
> + mfspr r11, SPRN_MD_TWC /* ....and get the pte address */
> + lwz r10, 0(r11) /* Get the pte */
> + beq 5f /* Kernel access always OK */
> + andi. r11,r10, _PAGE_USER
> + beq 2f
> +5: ori r10, r10, _PAGE_ACCESSED
> + mfspr r21, SPRN_MD_TWC /* ....and get the pte address */
> + stw r10, 0(r11)
> + xori r10, r10, _PAGE_RW /* invert RW bit */
> +
> + /* The Linux PTE won't go exactly into the MMU TLB.
> + * Software indicator bit 28 must be clear.
> + * Software indicator bits 24, 25, 26, and 27 must be
> + * set. All other Linux PTE bits control the behavior
> + * of the MMU.
> + */
> + li r11, 0x00f0
> + rlwimi r10, r11, 0, 24, 28 /* Set 24-27, clear 28 */
> + DO_8xx_CPU6(0x2d80, r3)
> + mtspr SPRN_MI_RPN, r10 /* Update TLB entry */
> +
> + mfspr r10, SPRN_M_TW /* Restore registers */
> + lwz r11, 0(r0)
> + mtcr r11
> + lwz r11, 4(r0)
> +#ifdef CONFIG_8xx_CPU6
> + lwz r3, 8(r0)
> +#endif
> + rfi
> +
> +2: mfspr r10, SPRN_M_TW /* Restore registers */
> + lwz r11, 0(r0)
> + mtcr r11
> + lwz r11, 4(r0)
> +#ifdef CONFIG_8xx_CPU6
> + lwz r3, 8(r0)
> +#endif
> b InstructionAccess
>
> /* This is the data TLB error on the MPC8xx. This could be due to
> @@ -472,8 +545,8 @@ DataTLBError:
> /* First, make sure this was a store operation.
> */
> mfspr r10, SPRN_DSISR
> - andis. r11, r10, 0x4800 /* no translation, no permission. */
> - bne 2f /* branch if either is set */
> + andis. r11, r10, 0x4000 /* no translation */
> + bne 2f /* branch if set */
>
> /* The EA of a data TLB miss is automatically stored in the MD_EPN
> * register. The EA of a data TLB error is automatically stored in
> @@ -522,26 +595,26 @@ DataTLBError:
> mfspr r11, SPRN_MD_TWC /* ....and get the pte address */
> lwz r10, 0(r11) /* Get the pte */
>
> - andi. r11, r10, _PAGE_RW /* Is it writeable? */
> - beq 2f /* Bail out if not */
> + mfspr r11, SPRN_SRR1
> + andi. r11, r11, 0x4000 /* MSR[PR] */
> + beq 5f /* Kernel access always OK */
> + andi. r11,r10, _PAGE_USER
> + beq 2f
> +5: mfspr r11, SPRN_DSISR
> + andis. r11, r11, 0x0200 /* store */
> + beq 6f
> + andi. r11, r10, _PAGE_RW /* writeable? */
> + beq 2f /* branch if not */
> + ori r10, r10, _PAGE_DIRTY | _PAGE_HWWRITE
> +6: ori r10, r10, _PAGE_ACCESSED
>
> - /* Update 'changed', among others.
> - */
> -#ifdef CONFIG_SWAP
> - ori r10, r10, _PAGE_DIRTY|_PAGE_HWWRITE
> - /* do not set the _PAGE_ACCESSED bit of a non-present page */
> - andi. r11, r10, _PAGE_PRESENT
> - beq 4f
> - ori r10, r10, _PAGE_ACCESSED
> -4:
> -#else
> - ori r10, r10, _PAGE_DIRTY|_PAGE_ACCESSED|_PAGE_HWWRITE
> -#endif
> mfspr r11, SPRN_MD_TWC /* Get pte address again */
> stw r10, 0(r11) /* and update pte in table */
>
> + xori r10, r10, _PAGE_RW /* Invert RW bit */
> +
> /* The Linux PTE won't go exactly into the MMU TLB.
> - * Software indicator bits 21, 22 and 28 must be clear.
> + * Software indicator bit 28 must be clear.
> * Software indicator bits 24, 25, 26, and 27 must be
> * set. All other Linux PTE bits control the behavior
> * of the MMU.
^ permalink raw reply
* Re: [PATCH 0/6] PowerPc 8xx TLB/MMU fixes
From: Scott Wood @ 2009-10-05 20:09 UTC (permalink / raw)
To: Joakim Tjernlund; +Cc: Rex Feany, linuxppc-dev@ozlabs.org
In-Reply-To: <OF44D5E829.2889B774-ONC1257646.00645628-C1257646.006568EE@transmode.se>
On Mon, Oct 05, 2009 at 08:27:39PM +0200, Joakim Tjernlund wrote:
> > After resolving the conflict, without adding tlbil_va in do_page_fault(), I
> > get the same stuck behavior as before.
>
> Expected, I havn't not tried to fix the missing tlbil_va(). That is
> different problem that you and Ben needs to sort out.
Right, I just wanted to be clear about which results were from which
modifications.
> > With tlbil_va, I get this (not sure
> > if it's related to using the wrong base tree):
>
> Could be the debug code doing something bad or the
> "Fixup DAR from buggy dcbX instructions". Could you back that one out?
That gets rid of the segfaults. The bootup gets stuck running udev, though
-- the system is either idle, or it's stuck doing some syscall.
I see it sometimes (but less reliably) without this patchset, so it may just
be changing the circumstances to expose the issue more consistently. Or
maybe I'm seeing the dcbX bug? There do seem to be dcbX instructions in the
dynamic linker I'm using (including a disturbing section that appears to be
assuming 32 byte cache lines, even though this is supposed to be an 8xx
RFS).
I'll look into it.
> and if that does not help, backout:
> "start using dcbX instructions in various copy routines" too.
No difference.
-Scott
^ permalink raw reply
* Re: [PATCH/v2] powerpc/5200: make BestComm gen_bd microcode exchangeable
From: Albrecht Dreß @ 2009-10-05 19:42 UTC (permalink / raw)
To: Grant Likely, Linux PPC Development
In-Reply-To: <fa686aa40910051116l6439eef7xc9f75c6ac4368094@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2385 bytes --]
Am 05.10.09 20:16 schrieb(en) Grant Likely:
> Hmmm. I've not been comfortable with this change, but it took me a while to put my finger on exactly why. In principle, I think it is a good idea. However, I don't want to merge it without any in-tree users.
I could provide my modified microcode (which differs in two words only), for the "standard" task, just with byte swapping for the LPB, but I wonder if it is of much use. No progress with crc32 calculation in BestComm so far... :-(
> The other concern is that I don't like that the patch is only applicable to gen_bd tasks.
IMHO the big difference between gen_bd on one hand and ATA and FEC on the other is that (afaik) we have *no* other choice than using the implemented tasks for the latter two, obviously using the Freescale's example microcode. Gen_bd can apparently be used for a plenty of purposes, including LPB (as shown in your driver), maybe PCI (there are examples in Freescale's code), PSC, etc. Thus, the FEC and ATA drivers should not have an option as to change the microcode, whereas it is just convenient for gen_bd.
> I've been thinking about this for a while, and I'm not exactly thrilled with the bestcomm layout which keeps the bestcomm firmware separate from the only driver that actually uses it (ie FEC firmware & support code is separate from the FEC driver. Same for ATA). I don't like the fact that code which is only ever used by the ATA driver is maintained completely separate from it.
That's a good point! The separate microcode files for ATA and FEC are somewhat confusing. I guess it's a result of simply copying the Freescale examples into separate files (and that might be a good reason for keeping the microcode separated). Maybe create new sub-folders below arch/powerpc/sysdev/bestcomm for fec, ata, and gen_bd? At least some documentation would be great.
> But I may be splitting hairs here and maybe I shouldn't be too concerned about it. Regardless, I'd think I'd rather see something that isn't totally gen_bd specific. Perhaps *microcode should be part of the bcom_task structure?
See above - I believe FEC and ATA are somewhat special as they need *exactly* the provided microcode. And if something cannot be changed without breaking the functionality, there should not be a chance to do so... ;-)
Just my €0.01, though...
Cheers, 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: Scott Wood @ 2009-10-05 19:28 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev@ozlabs.org, Rex Feany
In-Reply-To: <1254521073.7122.5.camel@pasglop>
On Sat, Oct 03, 2009 at 08:04:33AM +1000, Benjamin Herrenschmidt wrote:
> On Fri, 2009-10-02 at 16:49 -0500, Scott Wood wrote:
> > Adding a tlbil_va to do_page_fault makes the problem go away for me (on
> > top of your "merge" branch) -- none of the other changes in this thread
> > do (assuming I didn't miss any). FWIW, when it gets stuck on a fault,
> > DSISR is 0xc0000000, and handle_mm_fault returns zero.
>
> But in that case, it should hit ptep_set_access_flags() (via
> handle_mm_fault) and from there call tlbil_va (provided we add a call to
> it in the relevant filter function which I proposed initially), no ?
Yes, it hits ptep_set_access_flags() and adding _tlbil_va there helps (I
didn't put it in the filter function, because that doesn't take address as a
parameter). I'd misread your suggestion as referring to the various changes
to set_pte_filter() that were posted.
As for unconditionally invalidating in set_pte_filter(), that doesn't boot
for me unless I check for kernel addresses -- I guess we populate page
tables that overlap the pinned large page region?
-Scott
^ permalink raw reply
* Re: [PATCH] powerpc/8xx: fix regression introduced by cache coherency rewrite
From: Joakim Tjernlund @ 2009-10-05 19:16 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Scott Wood, linuxppc-dev@ozlabs.org, Rex Feany
In-Reply-To: <1254688118.7122.30.camel@pasglop>
Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote on 04/10/2009 22:28:38:
>
>
> > I have managed to update the TLB code to make proper use of dirty and accessed states.
> > Advantages are:
> > - I/D TLB Miss never needs to write to the linux pte, saving a few cycles
>
> That's good, that leaves us with only 40x to fix now. Also we can remove
> atomic updates of PTEs for all non-hash. It's pointless on those CPUs
> anyway.
>
> > - Accessed is only set by I/D TLB Error, should be a plus when SWAP is used.
>
> No need for that neither.
>
> ISI/DSI shouldn't touch the PTE. They should just fall back to C code
> which takes care of it all.l
Ben, for my understanding: It seems to that the TLB Miss routines in
head_32.S are less than optimal as it too touches the pte every time
it hits. Would it not be better to test if ACCESSED and friends are already set
and skip storing the same pte over and over again?
Jocke
^ permalink raw reply
* Re: [PATCH] powerpc/8xx: fix regression introduced by cache coherency rewrite
From: Joakim Tjernlund @ 2009-10-05 18:50 UTC (permalink / raw)
To: Scott Wood; +Cc: Rex Feany, linuxppc-dev@ozlabs.org
In-Reply-To: <20091005182429.GB3576@loki.buserror.net>
Scott Wood <scottwood@freescale.com> wrote on 05/10/2009 20:24:29:
>
> On Sat, Oct 03, 2009 at 10:05:46AM +0200, Joakim Tjernlund wrote:
> > Scott Wood <scottwood@freescale.com> wrote on 02/10/2009 23:49:49:
> > > Adding a tlbil_va to do_page_fault makes the problem go away for me (on
> > > top of your "merge" branch) -- none of the other changes in this thread
> > > do (assuming I didn't miss any). FWIW, when it gets stuck on a fault,
> > > DSISR is 0xc0000000, and handle_mm_fault returns zero.
> >
> > OK, that is a no translation error for a load (assuming trap is 0x400)
>
> Yes, 0x400.
>
> > Do you know what insn this is?
>
> Various lbz and lwz.
OK, this rules out any dcbX problem. Perhaps you can try any of Bens
ideas? Not sure what they were but hopefully you and Ben do :)
Preferably after you have tested my new patches :)
Jocke
^ permalink raw reply
* Re: [PATCH 0/6] PowerPc 8xx TLB/MMU fixes
From: Joakim Tjernlund @ 2009-10-05 18:27 UTC (permalink / raw)
To: Scott Wood; +Cc: Rex Feany, linuxppc-dev@ozlabs.org
In-Reply-To: <20091005181233.GA3576@loki.buserror.net>
Scott Wood <scottwood@freescale.com> wrote on 05/10/2009 20:12:34:
>
> On Mon, Oct 05, 2009 at 02:16:33PM +0200, Joakim Tjernlund wrote:
> > Here are my latest code to fixup 8xx's TLB code.
> > This code needs some serious testing before it
> > can be commited.
> > The "8xx, fault: Add some debug code to do_page_fault()" is
> > purely a debug check and will be removed/disabled when
> > this series appear stable.
> >
> > Scott and Rex, please disregard other patches from me and
> > try these out instead.
>
> I'm not sure which tree you based this on, but I got some conflicts
> in pte-8xx.h using Ben's merge branch.
It is a somewhat older tree, didn't think it would clash, sorry
>
> After resolving the conflict, without adding tlbil_va in do_page_fault(), I
> get the same stuck behavior as before.
Expected, I havn't not tried to fix the missing tlbil_va(). That is
different problem that you and Ben needs to sort out.
> With tlbil_va, I get this (not sure
> if it's related to using the wrong base tree):
Could be the debug code doing something bad or the
"Fixup DAR from buggy dcbX instructions". Could you back that one out?
and if that does not help, backout:
"start using dcbX instructions in various copy routines" too.
>
> INIT: version 2.85 booting
> Mounting /proc and /sys
> dcbz: address:1, dar:30020000!
> /etc/rc.d/rcS: line 24: 173 Segmentation fault /etc/rc.d/init.d/$i $mode
> dcbz: address:1, dar:30020000!
> /etc/rc.d/rcS: line 24: 174 Segmentation fault /etc/rc.d/init.d/$i $mode
> dcbz: address:1, dar:30020000!
> /etc/rc.d/rcS: line 24: 175 Segmentation fault /etc/rc.d/init.d/$i $mode
> dcbz: address:1, dar:30020000!
> /etc/rc.d/rcS: line 24: 176 Segmentation fault /etc/rc.d/init.d/$i $mode
> dcbz: address:1, dar:30020000!
> /etc/rc.d/rcS: line 24: 177 Segmentation fault /etc/rc.d/init.d/$i $mode
> dcbz: address:1, dar:30020000!
> /etc/rc.d/rcS: line 24: 178 Segmentation fault /etc/rc.d/init.d/$i $mode
> dcbz: address:1, dar:30020000!
> /etc/rc.d/rcS: line 24: 179 Segmentation fault /etc/rc.d/init.d/$i $mode
> dcbz: address:1, dar:30020000!
> /etc/rc.d/rcS: line 24: 180 Segmentation fault /etc/rc.d/init.d/$i $mode
> dcbz: address:1, dar:30020000!
> /etc/rc.d/rcS: line 24: 181 Segmentation fault /etc/rc.d/init.d/$i $mode
> dcbz: address:1, dar:30020000!
> /etc/rc.d/rcS: line 24: 182 Segmentation fault /etc/rc.d/init.d/$i $mode
> dcbz: address:1, dar:30020000!
> /etc/rc.d/rcS: line 37: 183 Segmentation fault /etc/rc.d/rc.local $mode
> INIT: Entering runlevel: 1
> dcbz: address:1, dar:30020000!
> dcbz: address:1, dar:30020000!
> dcbz: address:1, dar:30020000!
> dcbz: address:1, dar:30020000!
> dcbz: address:1, dar:30020000!
> dcbz: address:1, dar:30020000!
> dcbz: address:1, dar:30020000!
> dcbz: address:1, dar:30020000!
> dcbz: address:1, dar:30020000!
> dcbz: address:1, dar:30020000!
> INIT: Id "l1" respawning too fast: disabled for 5 minutes
> INIT: no more processes left in this runlevel
>
> -Scott
>
>
^ permalink raw reply
* Re: [PATCH] powerpc/8xx: fix regression introduced by cache coherency rewrite
From: Scott Wood @ 2009-10-05 18:24 UTC (permalink / raw)
To: Joakim Tjernlund; +Cc: Rex Feany, linuxppc-dev@ozlabs.org
In-Reply-To: <OF4175DD8E.796930EB-ONC1257644.002A7135-C1257644.002C7929@transmode.se>
On Sat, Oct 03, 2009 at 10:05:46AM +0200, Joakim Tjernlund wrote:
> Scott Wood <scottwood@freescale.com> wrote on 02/10/2009 23:49:49:
> > Adding a tlbil_va to do_page_fault makes the problem go away for me (on
> > top of your "merge" branch) -- none of the other changes in this thread
> > do (assuming I didn't miss any). FWIW, when it gets stuck on a fault,
> > DSISR is 0xc0000000, and handle_mm_fault returns zero.
>
> OK, that is a no translation error for a load (assuming trap is 0x400)
Yes, 0x400.
> Do you know what insn this is?
Various lbz and lwz.
-Scott
^ permalink raw reply
* Re: [PATCH/v2] powerpc/5200: make BestComm gen_bd microcode exchangeable
From: Grant Likely @ 2009-10-05 18:16 UTC (permalink / raw)
To: Albrecht Dreß; +Cc: Linux PPC Development
In-Reply-To: <1254764467.5503.1@antares>
On Mon, Oct 5, 2009 at 11:41 AM, Albrecht Dre=DF <albrecht.dress@arcor.de> =
wrote:
> This patch adds a method for defining different microcodes than the pe-de=
fined ones for the MPC52xx's BestComm General Buffer Descriptor (gen_db) ta=
sks. =A0The default microcode is still the one from bcom_gen_bd_[rt]x_task,=
but it can be replaced by calling bcom_gen_bd_set_microcode() which is mor=
e efficient than explicitly loading it via bcom_load_image() after each bco=
m_gen_bd_[rt]x_reset().
>
> Except for a fixed tab vs. space formatting and the transfer format, ther=
e are no diffierences to the initial attempt.
Hmmm. I've not been comfortable with this change, but it took me a
while to put my finger on exactly why. In principle, I think it is a
good idea. However, I don't want to merge it without any in-tree
users.
The other concern is that I don't like that the patch is only
applicable to gen_bd tasks. I've been thinking about this for a
while, and I'm not exactly thrilled with the bestcomm layout which
keeps the bestcomm firmware separate from the only driver that
actually uses it (ie FEC firmware & support code is separate from the
FEC driver. Same for ATA). I don't like the fact that code which is
only ever used by the ATA driver is maintained completely separate
from it. But I may be splitting hairs here and maybe I shouldn't be
too concerned about it. Regardless, I'd think I'd rather see
something that isn't totally gen_bd specific. Perhaps *microcode
should be part of the bcom_task structure?
Thoughts?
g.
>
> Signed-off-by: Albrecht Dre=DF <albrecht.dress@arcor.de>
>
>
> ---
>
>
> diff -uprN -X linux-2.6.32-rc3/Documentation/dontdiff linux-2.6.32-rc3-or=
ig/arch/powerpc/sysdev/bestcomm/gen_bd.c linux-2.6.32-rc3/arch/powerpc/sysd=
ev/bestcomm/gen_bd.c
> --- linux-2.6.32-rc3-orig/arch/powerpc/sysdev/bestcomm/gen_bd.c 2009-10-0=
5 02:12:30.000000000 +0200
> +++ linux-2.6.32-rc3/arch/powerpc/sysdev/bestcomm/gen_bd.c =A0 =A0 =A0200=
9-10-05 14:52:31.000000000 +0200
> @@ -78,6 +78,7 @@ struct bcom_gen_bd_priv {
> =A0 =A0 =A0 =A0int =A0 =A0 =A0 =A0 =A0 =A0 initiator;
> =A0 =A0 =A0 =A0int =A0 =A0 =A0 =A0 =A0 =A0 ipr;
> =A0 =A0 =A0 =A0int =A0 =A0 =A0 =A0 =A0 =A0 maxbufsize;
> + =A0 =A0 =A0 u32 =A0 =A0 =A0 =A0 =A0 =A0 *microcode;
> =A0};
>
>
> @@ -104,6 +105,7 @@ bcom_gen_bd_rx_init(int queue_len, phys_
> =A0 =A0 =A0 =A0priv->initiator =3D initiator;
> =A0 =A0 =A0 =A0priv->ipr =A0 =A0 =A0 =3D ipr;
> =A0 =A0 =A0 =A0priv->maxbufsize =3D maxbufsize;
> + =A0 =A0 =A0 priv->microcode =3D bcom_gen_bd_rx_task;
>
> =A0 =A0 =A0 =A0if (bcom_gen_bd_rx_reset(tsk)) {
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0bcom_task_free(tsk);
> @@ -128,7 +130,7 @@ bcom_gen_bd_rx_reset(struct bcom_task *t
> =A0 =A0 =A0 =A0var =3D (struct bcom_gen_bd_rx_var *) bcom_task_var(tsk->t=
asknum);
> =A0 =A0 =A0 =A0inc =3D (struct bcom_gen_bd_rx_inc *) bcom_task_inc(tsk->t=
asknum);
>
> - =A0 =A0 =A0 if (bcom_load_image(tsk->tasknum, bcom_gen_bd_rx_task))
> + =A0 =A0 =A0 if (bcom_load_image(tsk->tasknum, priv->microcode))
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0return -1;
>
> =A0 =A0 =A0 =A0var->enable =A0 =A0 =3D bcom_eng->regs_base +
> @@ -188,6 +190,7 @@ bcom_gen_bd_tx_init(int queue_len, phys_
> =A0 =A0 =A0 =A0priv->fifo =A0 =A0 =A0=3D fifo;
> =A0 =A0 =A0 =A0priv->initiator =3D initiator;
> =A0 =A0 =A0 =A0priv->ipr =A0 =A0 =A0 =3D ipr;
> + =A0 =A0 =A0 priv->microcode =3D bcom_gen_bd_tx_task;
>
> =A0 =A0 =A0 =A0if (bcom_gen_bd_tx_reset(tsk)) {
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0bcom_task_free(tsk);
> @@ -212,7 +215,7 @@ bcom_gen_bd_tx_reset(struct bcom_task *t
> =A0 =A0 =A0 =A0var =3D (struct bcom_gen_bd_tx_var *) bcom_task_var(tsk->t=
asknum);
> =A0 =A0 =A0 =A0inc =3D (struct bcom_gen_bd_tx_inc *) bcom_task_inc(tsk->t=
asknum);
>
> - =A0 =A0 =A0 if (bcom_load_image(tsk->tasknum, bcom_gen_bd_tx_task))
> + =A0 =A0 =A0 if (bcom_load_image(tsk->tasknum, priv->microcode))
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0return -1;
>
> =A0 =A0 =A0 =A0var->enable =A0 =A0 =3D bcom_eng->regs_base +
> @@ -253,6 +256,15 @@ bcom_gen_bd_tx_release(struct bcom_task
> =A0}
> =A0EXPORT_SYMBOL_GPL(bcom_gen_bd_tx_release);
>
> +void
> +bcom_gen_bd_set_microcode(struct bcom_task *tsk, u32 *microcode)
> +{
> + =A0 =A0 =A0 struct bcom_gen_bd_priv *priv =3D tsk->priv;
> +
> + =A0 =A0 =A0 priv->microcode =3D microcode;
> +}
> +EXPORT_SYMBOL_GPL(bcom_gen_bd_set_microcode);
> +
> =A0/* -------------------------------------------------------------------=
--
> =A0* PSC support code
> =A0*/
> diff -uprN -X linux-2.6.32-rc3/Documentation/dontdiff linux-2.6.32-rc3-or=
ig/arch/powerpc/sysdev/bestcomm/gen_bd.h linux-2.6.32-rc3/arch/powerpc/sysd=
ev/bestcomm/gen_bd.h
> --- linux-2.6.32-rc3-orig/arch/powerpc/sysdev/bestcomm/gen_bd.h 2009-10-0=
5 02:12:30.000000000 +0200
> +++ linux-2.6.32-rc3/arch/powerpc/sysdev/bestcomm/gen_bd.h =A0 =A0 =A0200=
9-10-05 14:52:31.000000000 +0200
> @@ -43,6 +43,9 @@ bcom_gen_bd_tx_reset(struct bcom_task *t
> =A0extern void
> =A0bcom_gen_bd_tx_release(struct bcom_task *tsk);
>
> +extern void
> +bcom_gen_bd_set_microcode(struct bcom_task *tsk, u32 *microcode);
> +
>
> =A0/* PSC support utility wrappers */
> =A0struct bcom_task * bcom_psc_gen_bd_rx_init(unsigned psc_num, int queue=
_len,
>
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH 0/6] PowerPc 8xx TLB/MMU fixes
From: Scott Wood @ 2009-10-05 18:12 UTC (permalink / raw)
To: Joakim Tjernlund; +Cc: linuxppc-dev@ozlabs.org, Rex Feany
In-Reply-To: <1254744999-3158-1-git-send-email-Joakim.Tjernlund@transmode.se>
On Mon, Oct 05, 2009 at 02:16:33PM +0200, Joakim Tjernlund wrote:
> Here are my latest code to fixup 8xx's TLB code.
> This code needs some serious testing before it
> can be commited.
> The "8xx, fault: Add some debug code to do_page_fault()" is
> purely a debug check and will be removed/disabled when
> this series appear stable.
>
> Scott and Rex, please disregard other patches from me and
> try these out instead.
I'm not sure which tree you based this on, but I got some conflicts
in pte-8xx.h using Ben's merge branch.
After resolving the conflict, without adding tlbil_va in do_page_fault(), I
get the same stuck behavior as before. With tlbil_va, I get this (not sure
if it's related to using the wrong base tree):
INIT: version 2.85 booting
Mounting /proc and /sys
dcbz: address:1, dar:30020000!
/etc/rc.d/rcS: line 24: 173 Segmentation fault /etc/rc.d/init.d/$i $mode
dcbz: address:1, dar:30020000!
/etc/rc.d/rcS: line 24: 174 Segmentation fault /etc/rc.d/init.d/$i $mode
dcbz: address:1, dar:30020000!
/etc/rc.d/rcS: line 24: 175 Segmentation fault /etc/rc.d/init.d/$i $mode
dcbz: address:1, dar:30020000!
/etc/rc.d/rcS: line 24: 176 Segmentation fault /etc/rc.d/init.d/$i $mode
dcbz: address:1, dar:30020000!
/etc/rc.d/rcS: line 24: 177 Segmentation fault /etc/rc.d/init.d/$i $mode
dcbz: address:1, dar:30020000!
/etc/rc.d/rcS: line 24: 178 Segmentation fault /etc/rc.d/init.d/$i $mode
dcbz: address:1, dar:30020000!
/etc/rc.d/rcS: line 24: 179 Segmentation fault /etc/rc.d/init.d/$i $mode
dcbz: address:1, dar:30020000!
/etc/rc.d/rcS: line 24: 180 Segmentation fault /etc/rc.d/init.d/$i $mode
dcbz: address:1, dar:30020000!
/etc/rc.d/rcS: line 24: 181 Segmentation fault /etc/rc.d/init.d/$i $mode
dcbz: address:1, dar:30020000!
/etc/rc.d/rcS: line 24: 182 Segmentation fault /etc/rc.d/init.d/$i $mode
dcbz: address:1, dar:30020000!
/etc/rc.d/rcS: line 37: 183 Segmentation fault /etc/rc.d/rc.local $mode
INIT: Entering runlevel: 1
dcbz: address:1, dar:30020000!
dcbz: address:1, dar:30020000!
dcbz: address:1, dar:30020000!
dcbz: address:1, dar:30020000!
dcbz: address:1, dar:30020000!
dcbz: address:1, dar:30020000!
dcbz: address:1, dar:30020000!
dcbz: address:1, dar:30020000!
dcbz: address:1, dar:30020000!
dcbz: address:1, dar:30020000!
INIT: Id "l1" respawning too fast: disabled for 5 minutes
INIT: no more processes left in this runlevel
-Scott
^ permalink raw reply
* [PATCH] powerpc: Make it possible to select hibernation on all PowerPCs
From: Anton Vorontsov @ 2009-10-05 17:44 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
Just as with kexec, hibernation may fail even on well-tested platforms:
some PCI device, a driver of which doesn't play well with hibernation,
is enough to break resuming.
Hibernation code is not much platform dependent, and hiding features only
because these were not verified on a particular hardware is
counterproductive: we just prevent the features from being widely tested.
For example, with this patch I just tested hibernation on a MPC83xx
board, and it works quite well, modulo a few drivers that need some
fixing.
So, let's make it possible to select hibernation support for all
PowerPCs, then let's wait for any possible bug reports, and actually fix
(or just collect ;-) the bugs instead of hiding them. If some platforms
really can't stand hibernation, we can make a blacklist, with proper
comments why exactly hibernation doesn't work, whether it is possible to
fix, and what needs to be done to fix it.
CONFIG_HIBERNATION is still =n by default, so the commit doesn't change
anything apart from ability to set it to =y.
I'm not sure if EXPERIMENTAL dependency is needed, I'd rather not add it
for a few reasons:
1) It doesn't matter much, for distro kernels user has no clue that some
feature is experimental. Majority of defconfigs enable EXPERIMENTAL
anyway (90 vs. 4, which, btw, means that EXPERIMENTAL is overused
in Kconfigs);
2) EXPERIMENTAL is a good thing for features that change default
behaviour of a kernel, while for hibernation user has to explicitly
issue 'echo disk > /sys/power/state' to trigger any hibernation bugs;
3) Per init/Kconfig, EXPERIMENTAL is a good thing to scare and discourage
users from 'widespread use of a feature', while we want to encourage
that use.
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
Build-tested on 8xx, 83xx and 85xx with CONFIG_HIBERNATION=y.
arch/powerpc/Kconfig | 11 -----------
1 files changed, 0 insertions(+), 11 deletions(-)
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index a2f66ed..85f140d 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -199,19 +199,8 @@ config DEFAULT_UIMAGE
config REDBOOT
bool
-config HIBERNATE_32
- bool
- depends on (PPC_PMAC && !SMP) || BROKEN
- default y
-
-config HIBERNATE_64
- bool
- depends on BROKEN || (PPC_PMAC64 && EXPERIMENTAL)
- default y
-
config ARCH_HIBERNATION_POSSIBLE
bool
- depends on (PPC64 && HIBERNATE_64) || (PPC32 && HIBERNATE_32)
default y
config ARCH_SUSPEND_POSSIBLE
--
1.6.3.3
^ permalink raw reply related
* [PATCH/v2] powerpc/5200: make BestComm gen_bd microcode exchangeable
From: Albrecht Dreß @ 2009-10-05 17:41 UTC (permalink / raw)
To: Linux PPC Development, grant.likely
This patch adds a method for defining different microcodes than the pe-defi=
ned ones for the MPC52xx's BestComm General Buffer Descriptor (gen_db) task=
s. The default microcode is still the one from bcom_gen_bd_[rt]x_task, but=
it can be replaced by calling bcom_gen_bd_set_microcode() which is more ef=
ficient than explicitly loading it via bcom_load_image() after each bcom_ge=
n_bd_[rt]x_reset().
Except for a fixed tab vs. space formatting and the transfer format, there =
are no diffierences to the initial attempt.
Signed-off-by: Albrecht Dre=DF <albrecht.dress@arcor.de>
---
diff -uprN -X linux-2.6.32-rc3/Documentation/dontdiff linux-2.6.32-rc3-orig=
/arch/powerpc/sysdev/bestcomm/gen_bd.c linux-2.6.32-rc3/arch/powerpc/sysdev=
/bestcomm/gen_bd.c
--- linux-2.6.32-rc3-orig/arch/powerpc/sysdev/bestcomm/gen_bd.c 2009-10-05 =
02:12:30.000000000 +0200
+++ linux-2.6.32-rc3/arch/powerpc/sysdev/bestcomm/gen_bd.c 2009-10-05 14:52=
:31.000000000 +0200
@@ -78,6 +78,7 @@ struct bcom_gen_bd_priv {
int initiator;
int ipr;
int maxbufsize;
+ u32 *microcode;
};
=20
=20
@@ -104,6 +105,7 @@ bcom_gen_bd_rx_init(int queue_len, phys_
priv->initiator =3D initiator;
priv->ipr =3D ipr;
priv->maxbufsize =3D maxbufsize;
+ priv->microcode =3D bcom_gen_bd_rx_task;
=20
if (bcom_gen_bd_rx_reset(tsk)) {
bcom_task_free(tsk);
@@ -128,7 +130,7 @@ bcom_gen_bd_rx_reset(struct bcom_task *t
var =3D (struct bcom_gen_bd_rx_var *) bcom_task_var(tsk->tasknum);
inc =3D (struct bcom_gen_bd_rx_inc *) bcom_task_inc(tsk->tasknum);
=20
- if (bcom_load_image(tsk->tasknum, bcom_gen_bd_rx_task))
+ if (bcom_load_image(tsk->tasknum, priv->microcode))
return -1;
=20
var->enable =3D bcom_eng->regs_base +
@@ -188,6 +190,7 @@ bcom_gen_bd_tx_init(int queue_len, phys_
priv->fifo =3D fifo;
priv->initiator =3D initiator;
priv->ipr =3D ipr;
+ priv->microcode =3D bcom_gen_bd_tx_task;
=20
if (bcom_gen_bd_tx_reset(tsk)) {
bcom_task_free(tsk);
@@ -212,7 +215,7 @@ bcom_gen_bd_tx_reset(struct bcom_task *t
var =3D (struct bcom_gen_bd_tx_var *) bcom_task_var(tsk->tasknum);
inc =3D (struct bcom_gen_bd_tx_inc *) bcom_task_inc(tsk->tasknum);
=20
- if (bcom_load_image(tsk->tasknum, bcom_gen_bd_tx_task))
+ if (bcom_load_image(tsk->tasknum, priv->microcode))
return -1;
=20
var->enable =3D bcom_eng->regs_base +
@@ -253,6 +256,15 @@ bcom_gen_bd_tx_release(struct bcom_task=20
}
EXPORT_SYMBOL_GPL(bcom_gen_bd_tx_release);
=20
+void
+bcom_gen_bd_set_microcode(struct bcom_task *tsk, u32 *microcode)
+{
+ struct bcom_gen_bd_priv *priv =3D tsk->priv;
+
+ priv->microcode =3D microcode;
+}
+EXPORT_SYMBOL_GPL(bcom_gen_bd_set_microcode);
+
/* ---------------------------------------------------------------------
* PSC support code
*/
diff -uprN -X linux-2.6.32-rc3/Documentation/dontdiff linux-2.6.32-rc3-orig=
/arch/powerpc/sysdev/bestcomm/gen_bd.h linux-2.6.32-rc3/arch/powerpc/sysdev=
/bestcomm/gen_bd.h
--- linux-2.6.32-rc3-orig/arch/powerpc/sysdev/bestcomm/gen_bd.h 2009-10-05 =
02:12:30.000000000 +0200
+++ linux-2.6.32-rc3/arch/powerpc/sysdev/bestcomm/gen_bd.h 2009-10-05 14:52=
:31.000000000 +0200
@@ -43,6 +43,9 @@ bcom_gen_bd_tx_reset(struct bcom_task *t
extern void
bcom_gen_bd_tx_release(struct bcom_task *tsk);
=20
+extern void
+bcom_gen_bd_set_microcode(struct bcom_task *tsk, u32 *microcode);
+
=20
/* PSC support utility wrappers */
struct bcom_task * bcom_psc_gen_bd_rx_init(unsigned psc_num, int queue_len=
,
^ permalink raw reply
* Re: problem with PCI network card on MPC8323E but works on MPC8313E
From: Scott Wood @ 2009-10-05 17:06 UTC (permalink / raw)
To: Grzegorz Jakubowski; +Cc: linuxppc-dev
In-Reply-To: <4AC99CE4.40600@platan.pl>
On Mon, Oct 05, 2009 at 09:14:44AM +0200, Grzegorz Jakubowski wrote:
> maybe problem is with I/O ports (failed instruction was ioread8) because
> on one board I/O ports are not assigned, but on MPC8323E they are
> invalid assigned.
> I have no idea how to solve my problem, thanks for any help. What should
> I try to do?
Check your U-Boot and device tree, and make sure they agree on PCI
configuration. If you're running an old U-Boot, upgrade.
-Scott
^ permalink raw reply
* ramdisk decompression error
From: Yixuan Qin @ 2009-10-05 16:51 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 795 bytes --]
Dear all,
I'm new to this list. I'm installing the Embedded Linux on a Xilinx FPGA
PPC405. The first question is that I have 1GB memory, and passed the
standalone memory test. But when installing linux, I have to setup only to
use 512MB memory in the device tree in order to boot the linux successfully,
otherwise it gave an error of stack overflow. The second question is when I
use a small size ramdisk, i.e. 4MB, the linux boots successfully, but when I
use bigger one, i.e. 16MB, it fails most of the time, but in rare case, it
succeeds. It either complains ramdisk decompression error, or cannot find
init. It looks my system is very unstable, I recon it's the problem of
memory, but it already passed with the whole memory test. Could you expert
give any suggestion?
Many thanks,
Simon
[-- Attachment #2: Type: text/html, Size: 832 bytes --]
^ permalink raw reply
* RE: Regression detecting memory size on PPC440EPx
From: Mike Nuss @ 2009-10-05 16:23 UTC (permalink / raw)
To: Mikhail Zolotaryov; +Cc: linuxppc-dev
In-Reply-To: <4ACA194A.6070907@lebon.org.ua>
Mikhail Zolotaryov wrote:
> Hi Mike,
>=20
> you wrote:
> "Row address bits : 13
> DDR0_02 =3D 0x020C0E01
> DDR0_42 =3D 0x00000006"
>=20
> Register values above define that memory has 14 row address bits. The
> correct setting is (for CAS Latency =3D 3):
> DDR0_42 =3D 0x01000006
>=20
> Best regards,
> Mikhail Zolotaryov
>=20
Thank you! It was a bug in U-Boot (they were encoding that register
incorrectly). I'll submit a patch to them.
Mike
^ permalink raw reply
* Re: Regression detecting memory size on PPC440EPx
From: Mikhail Zolotaryov @ 2009-10-05 16:05 UTC (permalink / raw)
To: Mike Nuss; +Cc: linuxppc-dev
In-Reply-To: <2C7DE72B9BD00F44BAECA5B0CBB873955CADF3@hermes.terascala.com>
Hi Mike,
you wrote:
"Row address bits : 13
DDR0_02 = 0x020C0E01
DDR0_42 = 0x00000006"
Register values above define that memory has 14 row address bits. The
correct setting is (for CAS Latency = 3):
DDR0_42 = 0x01000006
Best regards,
Mikhail Zolotaryov
Mike Nuss wrote:
> (top-posting corrected)
>
> Mikhail Zolotaryov wrote:
>
>> Mike Nuss wrote:
>>
>>> There was a fix a while back called "Correct memory size calculation
>>> for Denali based boards" that corrected the data width detection in
>>> the 4xx bootwrapper.
>>>
>>> This seems to have had the unintended consequence of exposing another
>>> bug in the same code. I have a board very similar to Sequoia, except
>>> that it uses a DDR2 DIMM module. It uses a single 256MB DIMM. After
>>> upgrading to the latest kernel, which includes the previously
>>> mentioned fix, U-Boot works fine, but the kernel detects 512MB
>>> instead, and of course, the kernel panics.
>>>
>>> The error seems to be in the calculation of row bits. U-Boot's SPD
>>> detection says that the DIMM uses 13 bits, but I added some
>>> printf()s to the bootwrapper, and it is setting row to 14 instead.
>>> I'm not too clear on how this code works; it calculates the row bits
>>> by subtracting the row from max_row, and maybe max_row is wrong?
>>>
>> Hi Mike,
>>
>> Address width calculation is based on the DDR-controller configuration
>> set by the bootloader. It would be helpful for further discussion if
>> you could send DDR0_00..DDR0_44 register values and memory
>> configuration used (no of banks, bank size, I/O width) to check
>> calculations. Thanks.
>>
>> P.S. Sequoia board also has DDR2 SDRAM from Micron.
>>
>> Best regards,
>> Mikhail Zolotaryov
>>
>
> Thanks for your reply.
>
> Here is the dump from U-Boot during intialization with DEBUG turned on
> in the denali code:
>
> Register Dump:
> DDR0_00 = 0x0000190A DDR0_01 = 0x010000FF
> DDR0_02 = 0x020C0E00 DDR0_03 = 0x02030602
> DDR0_04 = 0x0A020200 DDR0_05 = 0x02020308
> DDR0_06 = 0x0102C812 DDR0_07 = 0x000D0100
> DDR0_08 = 0x02C80001 DDR0_09 = 0x00011D5F
> DDR0_10 = 0x00000100 DDR0_11 = 0x0022C800
> DDR0_12 = 0x00000003 DDR0_14 = 0x00000000
> DDR0_17 = 0x19000000 DDR0_18 = 0x19191919
> DDR0_19 = 0x19191919 DDR0_20 = 0x0B0B0B0B
> DDR0_21 = 0x0B0B0B0B DDR0_22 = 0x00267F0B
> DDR0_23 = 0x00000000 DDR0_24 = 0x01020001
> DDR0_25 = 0x20410000 DDR0_26 = 0x2DB40514
> DDR0_27 = 0x00008236 DDR0_28 = 0x00000000
> DDR0_31 = 0x00000000 DDR0_32 = 0x00000000
> DDR0_33 = 0x00000000 DDR0_34 = 0x00000000
> DDR0_35 = 0x00000000 DDR0_36 = 0x00000000
> DDR0_37 = 0x00000000 DDR0_38 = 0x00000000
> DDR0_39 = 0x00000000 DDR0_40 = 0x00000000
> DDR0_41 = 0x00000000 DDR0_42 = 0x00000006
> DDR0_43 = 0x030A0200 DDR0_44 = 0x00000003
> dram_size = 268435456
>
> Register Dump:
> DDR0_00 = 0x00C0190A DDR0_01 = 0x010000FF
> DDR0_02 = 0x020C0E01 DDR0_03 = 0x02030602
> DDR0_04 = 0x0A020200 DDR0_05 = 0x02020308
> DDR0_06 = 0x0102C812 DDR0_07 = 0x000D0100
> DDR0_08 = 0x02C80001 DDR0_09 = 0x00011D5E
> DDR0_10 = 0x00000100 DDR0_11 = 0x0022C800
> DDR0_12 = 0x00000003 DDR0_14 = 0x00000000
> DDR0_17 = 0x1E014800 DDR0_18 = 0x1E1E1E1E
> DDR0_19 = 0x1E1E1E1E DDR0_20 = 0x0B0B0B0B
> DDR0_21 = 0x0B0B0B0B DDR0_22 = 0x00267E0B
> DDR0_23 = 0x00000000 DDR0_24 = 0x01020001
> DDR0_25 = 0x20410000 DDR0_26 = 0x2DB40514
> DDR0_27 = 0x00008236 DDR0_28 = 0x00000000
> DDR0_31 = 0x00000000 DDR0_32 = 0x00000000
> DDR0_33 = 0x00000000 DDR0_34 = 0x00000000
> DDR0_35 = 0x00000000 DDR0_36 = 0x00000000
> DDR0_37 = 0x00000000 DDR0_38 = 0x00000000
> DDR0_39 = 0x00000000 DDR0_40 = 0x00000000
> DDR0_41 = 0x00000000 DDR0_42 = 0x00000006
> DDR0_43 = 0x030A0200 DDR0_44 = 0x00000003
> Zeroing SDRAM...Completed
> 256 MB (ECC not enabled, 333 MHz, CL3)
>
>
> Here is the memory configuration:
> SPD data revision 1.2
> Bytes used 0x80
> Serial memory size 0x100
> Memory type DDR2
> Row address bits 13
> Column address bits 10
> Number of ranks 1
> Module data width 64 bits
> Interface signal levels SSTL 1.8 V
> SDRAM cycle time 3.0 ns
> SDRAM access time 0.45 ns
> EDC configuration None
> Self refresh, rate 7.8 us
> SDRAM width (primary) 16
> Burst length(s) 8 4
> Number of banks 4
> CAS latency(s) 5 4 3
> Module attributes:
> 0 PLLs on DIMM
> Supports 50 ohm ODT
> Supports weak driver
> SDRAM cycle time (2nd highest CAS latency) 3.75 ns
> SDRAM access from clock (2nd highest CAS latency) 0.45 ns
> SDRAM cycle time (3rd highest CAS latency) 5.0 ns
> SDRAM access from clock (3rd highest CAS latency) 0.45 ns
> Minimum row precharge 15.00 ns
> Row active to row active min 10.00 ns
> RAS to CAS delay min 15.00 ns
> Minimum RAS pulse width 45 ns
> Density of each row 256 MiB
> Command and Address setup 0.20 ns
> Command and Address hold 0.27 ns
> Data signal input setup 0.10 ns
> Data signal input hold 0.17 ns
> Manufacturer's JEDEC ID 2C 00 00 00 00 00 00 00
> Manufacturing Location 08
> Manufacturer's Part Number 34 48 54 46 33 32 36 34 48 59 2D 36 36 37
> 44 33 20 20
> Revision Code 03 00
> Manufacturing Date 07 32
> Assembly Serial Number D3 23 09 9E
>
>
> Here is the bootwrapper output on startup (everything except the last
> line is from printf()s added by me):
>
> real_cs:1
> cs:1
> dpath bytes:8
> row:14
> col:10
> banks:4
> memsize:536870912
> memsize (errata):536866816
> Memory <- <0x0 0x0 0x1ffff000> (511MB)
>
> Note 511MB is obviously wrong. "row" differs from "Row address bits"
> from U-Boot, which is where I guess the problem lies.
>
> Thanks,
> Mike
>
^ permalink raw reply
* Re: Regression detecting memory size on PPC440EPx
From: Valentine @ 2009-10-05 15:44 UTC (permalink / raw)
To: Mikhail Zolotaryov; +Cc: linuxppc-dev, Mike Nuss
In-Reply-To: <4ACA1300.6040105@lebon.org.ua>
AFAIK, u-boot just writes pre-defined values to the memory controller
registers. It doesn't do any chiptype/memsize detection. These values
are set for Sequoia and may not suite your board. So you probably need
to adjust the u-boot to make linux detect the memory size correctly.
Thanks,
Val.
Mikhail Zolotaryov wrote:
> Hi Mike,
>
> Address width calculation is based on the DDR-controller configuration
> set by the bootloader. It would be helpful for further discussion if you
> could send DDR0_00..DDR0_44 register values and memory configuration
> used (no of banks, bank size, I/O width) to check calculations. Thanks.
>
> P.S. Sequoia board also has DDR2 SDRAM from Micron.
>
> Best regards,
> Mikhail Zolotaryov
>
>
> Mike Nuss wrote:
>> There was a fix a while back called "Correct memory size calculation for
>> Denali based boards" that corrected the data width detection in the 4xx
>> bootwrapper.
>>
>> This seems to have had the unintended consequence of exposing another
>> bug in the same code. I have a board very similar to Sequoia, except
>> that it uses a DDR2 DIMM module. It uses a single 256MB DIMM. After
>> upgrading to the latest kernel, which includes the previously mentioned
>> fix, U-Boot works fine, but the kernel detects 512MB instead, and of
>> course, the kernel panics.
>>
>> The error seems to be in the calculation of row bits. U-Boot's SPD
>> detection says that the DIMM uses 13 bits, but I added some printf()s to
>> the bootwrapper, and it is setting row to 14 instead. I'm not too clear
>> on how this code works; it calculates the row bits by subtracting the
>> row from max_row, and maybe max_row is wrong?
>>
>> It looks like the data width bug canceled out this bug before, since
>> these values end up changing the memory size by a factor of 2 (in
>> opposite directions).
>>
>> Could someone with a better understanding of this code take a look?
>>
>> Thanks,
>> Mike
>> _______________________________________________
>> Linuxppc-dev mailing list
>> Linuxppc-dev@lists.ozlabs.org
>> https://lists.ozlabs.org/listinfo/linuxppc-dev
>>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
^ permalink raw reply
* RE: Regression detecting memory size on PPC440EPx
From: Mike Nuss @ 2009-10-05 15:49 UTC (permalink / raw)
To: Valentine, Mikhail Zolotaryov; +Cc: linuxppc-dev
In-Reply-To: <4ACA1475.1000101@ru.mvista.com>
Valentine wrote:
> AFAIK, u-boot just writes pre-defined values to the memory controller
> registers. It doesn't do any chiptype/memsize detection. These values
> are set for Sequoia and may not suite your board. So you probably need
> to adjust the u-boot to make linux detect the memory size correctly.
>=20
> Thanks,
> Val.
In old versions of U-Boot that was true. Now there is definitely code
that reads the SPD EEPROM and sets up the Denali controller
appropriately.
There could be some hardcoded value being written to the registers that
is incorrect for the kernel - in fact that is my suspicion - but the
values U-Boot itself is using for the size calculation must be correct.
Mike
PS: Is top posting customary on this list? I'm used to bottom posting;
let me know if I'm doing it wrong.
^ permalink raw reply
* RE: Regression detecting memory size on PPC440EPx
From: Mike Nuss @ 2009-10-05 15:44 UTC (permalink / raw)
To: Mikhail Zolotaryov; +Cc: linuxppc-dev
In-Reply-To: <4ACA1300.6040105@lebon.org.ua>
(top-posting corrected)
Mikhail Zolotaryov wrote:
> Mike Nuss wrote:
>> There was a fix a while back called "Correct memory size calculation
>> for Denali based boards" that corrected the data width detection in
>> the 4xx bootwrapper.=20
>>=20
>> This seems to have had the unintended consequence of exposing another
>> bug in the same code. I have a board very similar to Sequoia, except
>> that it uses a DDR2 DIMM module. It uses a single 256MB DIMM. After
>> upgrading to the latest kernel, which includes the previously
>> mentioned fix, U-Boot works fine, but the kernel detects 512MB
>> instead, and of course, the kernel panics.=20
>>=20
>> The error seems to be in the calculation of row bits. U-Boot's SPD
>> detection says that the DIMM uses 13 bits, but I added some
>> printf()s to the bootwrapper, and it is setting row to 14 instead.=20
>> I'm not too clear on how this code works; it calculates the row bits
>> by subtracting the row from max_row, and maybe max_row is wrong?
>
> Hi Mike,
>=20
> Address width calculation is based on the DDR-controller configuration
> set by the bootloader. It would be helpful for further discussion if
> you could send DDR0_00..DDR0_44 register values and memory
> configuration used (no of banks, bank size, I/O width) to check
> calculations. Thanks.=20
>=20
> P.S. Sequoia board also has DDR2 SDRAM from Micron.
>=20
> Best regards,
> Mikhail Zolotaryov
Thanks for your reply.
Here is the dump from U-Boot during intialization with DEBUG turned on
in the denali code:
Register Dump:
DDR0_00 =3D 0x0000190A DDR0_01 =3D 0x010000FF
DDR0_02 =3D 0x020C0E00 DDR0_03 =3D 0x02030602
DDR0_04 =3D 0x0A020200 DDR0_05 =3D 0x02020308
DDR0_06 =3D 0x0102C812 DDR0_07 =3D 0x000D0100
DDR0_08 =3D 0x02C80001 DDR0_09 =3D 0x00011D5F
DDR0_10 =3D 0x00000100 DDR0_11 =3D 0x0022C800
DDR0_12 =3D 0x00000003 DDR0_14 =3D 0x00000000
DDR0_17 =3D 0x19000000 DDR0_18 =3D 0x19191919
DDR0_19 =3D 0x19191919 DDR0_20 =3D 0x0B0B0B0B
DDR0_21 =3D 0x0B0B0B0B DDR0_22 =3D 0x00267F0B
DDR0_23 =3D 0x00000000 DDR0_24 =3D 0x01020001
DDR0_25 =3D 0x20410000 DDR0_26 =3D 0x2DB40514
DDR0_27 =3D 0x00008236 DDR0_28 =3D 0x00000000
DDR0_31 =3D 0x00000000 DDR0_32 =3D 0x00000000
DDR0_33 =3D 0x00000000 DDR0_34 =3D 0x00000000
DDR0_35 =3D 0x00000000 DDR0_36 =3D 0x00000000
DDR0_37 =3D 0x00000000 DDR0_38 =3D 0x00000000
DDR0_39 =3D 0x00000000 DDR0_40 =3D 0x00000000
DDR0_41 =3D 0x00000000 DDR0_42 =3D 0x00000006
DDR0_43 =3D 0x030A0200 DDR0_44 =3D 0x00000003
dram_size =3D 268435456
Register Dump:
DDR0_00 =3D 0x00C0190A DDR0_01 =3D 0x010000FF
DDR0_02 =3D 0x020C0E01 DDR0_03 =3D 0x02030602
DDR0_04 =3D 0x0A020200 DDR0_05 =3D 0x02020308
DDR0_06 =3D 0x0102C812 DDR0_07 =3D 0x000D0100
DDR0_08 =3D 0x02C80001 DDR0_09 =3D 0x00011D5E
DDR0_10 =3D 0x00000100 DDR0_11 =3D 0x0022C800
DDR0_12 =3D 0x00000003 DDR0_14 =3D 0x00000000
DDR0_17 =3D 0x1E014800 DDR0_18 =3D 0x1E1E1E1E
DDR0_19 =3D 0x1E1E1E1E DDR0_20 =3D 0x0B0B0B0B
DDR0_21 =3D 0x0B0B0B0B DDR0_22 =3D 0x00267E0B
DDR0_23 =3D 0x00000000 DDR0_24 =3D 0x01020001
DDR0_25 =3D 0x20410000 DDR0_26 =3D 0x2DB40514
DDR0_27 =3D 0x00008236 DDR0_28 =3D 0x00000000
DDR0_31 =3D 0x00000000 DDR0_32 =3D 0x00000000
DDR0_33 =3D 0x00000000 DDR0_34 =3D 0x00000000
DDR0_35 =3D 0x00000000 DDR0_36 =3D 0x00000000
DDR0_37 =3D 0x00000000 DDR0_38 =3D 0x00000000
DDR0_39 =3D 0x00000000 DDR0_40 =3D 0x00000000
DDR0_41 =3D 0x00000000 DDR0_42 =3D 0x00000006
DDR0_43 =3D 0x030A0200 DDR0_44 =3D 0x00000003
Zeroing SDRAM...Completed
256 MB (ECC not enabled, 333 MHz, CL3)
Here is the memory configuration:
SPD data revision 1.2
Bytes used 0x80
Serial memory size 0x100
Memory type DDR2
Row address bits 13
Column address bits 10
Number of ranks 1
Module data width 64 bits
Interface signal levels SSTL 1.8 V
SDRAM cycle time 3.0 ns
SDRAM access time 0.45 ns
EDC configuration None
Self refresh, rate 7.8 us
SDRAM width (primary) 16
Burst length(s) 8 4
Number of banks 4
CAS latency(s) 5 4 3
Module attributes:
0 PLLs on DIMM
Supports 50 ohm ODT
Supports weak driver
SDRAM cycle time (2nd highest CAS latency) 3.75 ns
SDRAM access from clock (2nd highest CAS latency) 0.45 ns
SDRAM cycle time (3rd highest CAS latency) 5.0 ns
SDRAM access from clock (3rd highest CAS latency) 0.45 ns
Minimum row precharge 15.00 ns
Row active to row active min 10.00 ns
RAS to CAS delay min 15.00 ns
Minimum RAS pulse width 45 ns
Density of each row 256 MiB
Command and Address setup 0.20 ns
Command and Address hold 0.27 ns
Data signal input setup 0.10 ns
Data signal input hold 0.17 ns
Manufacturer's JEDEC ID 2C 00 00 00 00 00 00 00
Manufacturing Location 08
Manufacturer's Part Number 34 48 54 46 33 32 36 34 48 59 2D 36 36 37
44 33 20 20
Revision Code 03 00
Manufacturing Date 07 32
Assembly Serial Number D3 23 09 9E
Here is the bootwrapper output on startup (everything except the last
line is from printf()s added by me):
real_cs:1
cs:1
dpath bytes:8
row:14
col:10
banks:4
memsize:536870912
memsize (errata):536866816
Memory <- <0x0 0x0 0x1ffff000> (511MB)
Note 511MB is obviously wrong. "row" differs from "Row address bits"
from U-Boot, which is where I guess the problem lies.
Thanks,
Mike
^ permalink raw reply
* Re: Regression detecting memory size on PPC440EPx
From: Mikhail Zolotaryov @ 2009-10-05 15:38 UTC (permalink / raw)
To: Mike Nuss; +Cc: linuxppc-dev
In-Reply-To: <2C7DE72B9BD00F44BAECA5B0CBB873955CADF2@hermes.terascala.com>
Hi Mike,
Address width calculation is based on the DDR-controller configuration
set by the bootloader. It would be helpful for further discussion if you
could send DDR0_00..DDR0_44 register values and memory configuration
used (no of banks, bank size, I/O width) to check calculations. Thanks.
P.S. Sequoia board also has DDR2 SDRAM from Micron.
Best regards,
Mikhail Zolotaryov
Mike Nuss wrote:
> There was a fix a while back called "Correct memory size calculation for
> Denali based boards" that corrected the data width detection in the 4xx
> bootwrapper.
>
> This seems to have had the unintended consequence of exposing another
> bug in the same code. I have a board very similar to Sequoia, except
> that it uses a DDR2 DIMM module. It uses a single 256MB DIMM. After
> upgrading to the latest kernel, which includes the previously mentioned
> fix, U-Boot works fine, but the kernel detects 512MB instead, and of
> course, the kernel panics.
>
> The error seems to be in the calculation of row bits. U-Boot's SPD
> detection says that the DIMM uses 13 bits, but I added some printf()s to
> the bootwrapper, and it is setting row to 14 instead. I'm not too clear
> on how this code works; it calculates the row bits by subtracting the
> row from max_row, and maybe max_row is wrong?
>
> It looks like the data width bug canceled out this bug before, since
> these values end up changing the memory size by a factor of 2 (in
> opposite directions).
>
> Could someone with a better understanding of this code take a look?
>
> Thanks,
> Mike
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
>
^ permalink raw reply
* Regression detecting memory size on PPC440EPx
From: Mike Nuss @ 2009-10-05 14:57 UTC (permalink / raw)
To: linuxppc-dev
There was a fix a while back called "Correct memory size calculation for
Denali based boards" that corrected the data width detection in the 4xx
bootwrapper.
This seems to have had the unintended consequence of exposing another
bug in the same code. I have a board very similar to Sequoia, except
that it uses a DDR2 DIMM module. It uses a single 256MB DIMM. After
upgrading to the latest kernel, which includes the previously mentioned
fix, U-Boot works fine, but the kernel detects 512MB instead, and of
course, the kernel panics.
The error seems to be in the calculation of row bits. U-Boot's SPD
detection says that the DIMM uses 13 bits, but I added some printf()s to
the bootwrapper, and it is setting row to 14 instead. I'm not too clear
on how this code works; it calculates the row bits by subtracting the
row from max_row, and maybe max_row is wrong?
It looks like the data width bug canceled out this bug before, since
these values end up changing the memory size by a factor of 2 (in
opposite directions).
Could someone with a better understanding of this code take a look?
Thanks,
Mike
^ permalink raw reply
* Re: [PATCH 4/4] powerpc/fsl: 85xx: add cache-sram support
From: Kumar Gala @ 2009-10-05 14:47 UTC (permalink / raw)
To: Mahajan Vivek-B08308; +Cc: linuxppc-dev
In-Reply-To: <F2F605B667B24B489C904986E0D60A08FF6268@zin33exm23.fsl.freescale.net>
On Oct 5, 2009, at 2:15 AM, Mahajan Vivek-B08308 wrote:
>> From: Gala Kumar-B11780
>> Sent: Friday, September 25, 2009 12:08 AM
>>> + mbar(1);
>>
>> why isn't eieio() sufficient here?
>
> When I initially added / tested cache SRAM for P2020RDB, its RM talked
> about using mbar() though mbar(1) is identical to eieio() opcode-wise.
> Also as cache-sram works only for 85xx derivatives, so I picked mbar()
> instead of eieio.
Let use eieio since there is no reason to special case the usage here
for mbar(1)
- k
^ permalink raw reply
* [PATCH v2] powerpc/booke: Fix xmon single step on PowerPC Book-E
From: Josh Boyer @ 2009-10-05 14:46 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev
Prior to the arch/ppc -> arch/powerpc transition, xmon had support for single
stepping on 4xx boards. The functionality was lost when arch/ppc was removed.
This patch restores single step support for 44x boards, and Book-E in general.
Signed-off-by: Josh Boyer <jwboyer@linux.vnet.ibm.com>
---
arch/powerpc/xmon/xmon.c | 20 +++++++++++++++++++-
1 files changed, 19 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/xmon/xmon.c b/arch/powerpc/xmon/xmon.c
index c6f0a71..bdbe96c 100644
--- a/arch/powerpc/xmon/xmon.c
+++ b/arch/powerpc/xmon/xmon.c
@@ -517,6 +517,15 @@ static int xmon_core(struct pt_regs *regs, int fromipi)
in_xmon = 0;
#endif
+#ifdef CONFIG_BOOKE
+ if (regs->msr & MSR_DE) {
+ bp = at_breakpoint(regs->nip);
+ if (bp != NULL) {
+ regs->nip = (unsigned long) &bp->instr[0];
+ atomic_inc(&bp->ref_count);
+ }
+ }
+#else
if ((regs->msr & (MSR_IR|MSR_PR|MSR_SF)) == (MSR_IR|MSR_SF)) {
bp = at_breakpoint(regs->nip);
if (bp != NULL) {
@@ -530,7 +539,7 @@ static int xmon_core(struct pt_regs *regs, int fromipi)
}
}
}
-
+#endif
insert_cpu_bpts();
local_irq_restore(flags);
@@ -894,6 +903,14 @@ cmds(struct pt_regs *excp)
}
}
+#ifdef CONFIG_BOOKE
+static int do_step(struct pt_regs *regs)
+{
+ regs->msr |= MSR_DE;
+ mtspr(SPRN_DBCR0, mfspr(SPRN_DBCR0) | DBCR0_IC | DBCR0_IDM);
+ return 1;
+}
+#else
/*
* Step a single instruction.
* Some instructions we emulate, others we execute with MSR_SE set.
@@ -924,6 +941,7 @@ static int do_step(struct pt_regs *regs)
regs->msr |= MSR_SE;
return 1;
}
+#endif
static void bootcmds(void)
{
--
1.5.5.6
^ permalink raw reply related
* Re: Help with SPI node
From: Grant Likely @ 2009-10-05 14:30 UTC (permalink / raw)
To: Joe Shmo; +Cc: devicetree-discuss, linuxppc-dev
In-Reply-To: <132676.44242.qm@web30102.mail.mud.yahoo.com>
On Thu, Oct 1, 2009 at 10:19 AM, Joe Shmo <spamreceptor@yahoo.com> wrote:
>
> =A0I'm attempting to get SPI to work on my embedded design
> =A0that is based on the mpc8313erbd reference board wiht a
> =A02.6.27 kernel.=A0 I cannot open the SPI device.
> =A0Tracing through the kernel code, it looks like the device is
> =A0not being found in the DTB file.=A0 However there is a
> =A0SPI node in there already described.=A0 Our boards is a
> =A0SPI master, and the device we will attach is a SPI
> =A0slave.=A0 Could someone elaborate on what is needed in
> =A0the DTS file to have our SPI driver work and respond to an
> =A0open() call?
Some notes:
- you should also cc: the linuxppc-dev@lists.ozlabs.org when asking
questions about powerpc platforms.
- Please post in plain text only, not HTML. Yahoo should have an
option for posting in plain text instead of formated.
- "Joe Shmo"? It's not against the rules to use a pseudoname, but
it's not very polite.
Things to check:
- Once the system is booted, look in /sys/bus/of_platform/devices to
see if the SPI bus device is registered. If it isn't there then it
means that the 8xxx platform code (arch/powerpc/platforms/) isn't
registering the device.
- Look in /sys/bus/of_platform/drivers/ to see if the mpc8xxx_spi
driver is loaded into the kernel. If it isn't there, then you need to
load the driver into the kernel.
- If both are present, then look in
/sys/bus/of_platform/devices/e0007000.spi (I think; the name might be
slightly different) for a 'driver' symlink. If the symlink is there,
then it means that the driver is bound to the device. Most likely it
means that the "compatible" value in the node doesn't match what the
driver is looking for.
Look at those things and report back.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [FTRACE] Enabling function_graph causes OOPS
From: Steven Rostedt @ 2009-10-05 13:25 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <1252915227.8375.118.camel@pasglop>
On Mon, 2009-09-14 at 18:00 +1000, Benjamin Herrenschmidt wrote:
> On Mon, 2009-09-14 at 06:25 +1000, Benjamin Herrenschmidt wrote:
> > > > .../...
> > > >
> > > > > Something is totally messed up here.
> > > >
> > > > Could it be that we don't handle R_PPC64_ADDR16_* relocs in
> > > > arch/powerpc/kernel/modules/module_64.c ?
> > > >
> > > > Sachin, do you see a bunch of "Unknown ADD relocation" in your dmesg ?
> > >
> > > Ben,
> > >
> > > The thing is, this is kernel proper. This code is in entry_64.S not in
> > > the module code.
> >
> > Argh... indeed.
> >
> > Sachin, can you give me more details on how you built that kernel ? (or
> > give them again in case I missed them the first time around :-), ie,
> > what toolchain, options, etc... or even better, give me remote access to
> > the build host ?
>
> Ok, got access and had a quick look... seems to be a toolchain problem
> to me. I'll investigate more tomorrow.
Hi Ben,
Any more word on this issue?
-- Steve
^ 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