* Re: [PATCH v4] powerpc: 64K page support for kexec
From: Luke Browning @ 2007-04-27 17:30 UTC (permalink / raw)
To: Milton Miller
Cc: Arnd Bergmann, linuxppc-dev, Paul Mackerras, Olof Johansson,
cbe-oss-dev
In-Reply-To: <c21def285f4ad2e13914af73f7610c0b@bga.com>
On Fri, 2007-04-27 at 11:59 -0500, Milton Miller wrote:
>
> I see I've achived my nefarious goal of making these bugs never happen.
>
> (panic is a function, so you are checking that the staticly linked
> non-weak function is available. If you want to check on when
> if its a panic kdump or not, you need to decode the flag and pass
> it to kexec_sequence, pass it back here, and update all platforms
> for the new parameter).
>
> But I still say the check while clearing the table is too late,
> it should be a debug scan before clearing any mappings.
How about the following as an alternative.
BUG_ON((hpte_v & 0x4000000000000000UL) && (crashing_cpus == -1));
BUG_ON((size == MMU_PAGE_16G) && (crashing_cpus == -1));
BUG_ON((size == MMU_PAGE_64K_AP) && (crashing_cpus == -1));
I don't have time to work on a multi-platform solution.
Regards,
Luke
^ permalink raw reply
* Re: [RFC] SystemACE driver - abstract register ops
From: Wolfgang Reissnegger @ 2007-04-27 17:30 UTC (permalink / raw)
To: Grant Likely
Cc: Andrei Konovalov, Stefan Roese, linuxppc-embedded, Rick Moleres
In-Reply-To: <528646bc0704270031w5c9966f8tc3a5e5292df10a35@mail.gmail.com>
Hi All,
I wanted to say that I am VERY excited about all the great work that is
happening here. As some of you know I am currently working on setting up
a Linux kernel git tree that contains a multitude of Xilinx drivers such
as IIC, SPI, GPIO, SYSACE, EMAC, EMACLITE, UARTLITE versions, FLASH as
well support for the MicroBlaze processor.
In addition I pulled Grant's virtex-dev branch (with TEMAC and SYSACE).
I will integrate those as soon as I'm done with the other work. I am
already eying the FrameBuffer driver from Andrei.
The end goal is to have a kernel tree that contains ALL Xilinx drivers
and the multitude of drivers that are being created/updated and
contributed here. Having such a kernel available will simplify the
process of bringing up a new system. The hope is that contributors will
adopt the idea of having a "Xilinx" kernel and will start using that
tree as a "base reference".
At this point the Xilinx kernel branch is based on version v2.6.20 with
the uc0 patch applied, as well as the various LynuxWorks patches that
support MicroBlaze and add the mentioned drivers. The LynuxWorks code
has been cleaned up to not contain the proprietary hardcoded sections to
make it more acceptable to the Open Source community. I'm sure there's
more work to be done, but it's a start.
Once the git server is up and running we will be adding new drivers they
become available and integrate patches and updates along the way.
Unfortunately, I spend a lot of my time now working the politics of
getting a git server up and running and convincing management that this
actually _is_ a good idea. It's slow going and there's a lot of meetings
and discussions going on. But I'm still hopeful. As a backup I'm trying
to get a kernel.org/git account so I can publish the tree there.
I will post news here as they unfold. In the meantime it would be very
interesting to hear ideas and suggestions from you. Concerns that people
have. Pitfalls to look out for etc.
Thanks,
Wolfgang
Grant Likely wrote:
> On 4/27/07, John Williams <jwilliams@itee.uq.edu.au> wrote:
>> Grant,
>>
>> Thanks for your work on the SystemACE driver - I'll be porting/merging
>> this across to MicroBlaze very shortly.
>
> Very cool; I hope it works well.
>
>> Given that SysACE can be hooked up in any number of ways, bit widths,
>> endians, PPC/Microblaze, can you please offer your comments on the
>> attached patch?
>
> Okay, after getting over my initial mirth about working on the *exact*
> same thing and finishing it at the *exact* time that you sent me your
> patch, I think I'm ready to make useful comments. :-)
>>
>> It introduce a private ace_reg_ops structure, with various member
>> functions for the different kinds of accesses to the HW.
>>
>> This patch should not change the functionality of your original driver
>> at all, it's just groundwork for what's to come.
>>
>> I recognise that it adds indirection into the various access paths, and
>> potentially a little bloat. Whether this is better than #if
>> 1...#else...#endif is debatable.
>
> I'm not to concerned with the added redirection. On my 405 designs, I
> find that bus overhead has a far greater impact than any of the
> processing paths in the driver, so this shouldn't be a problem.
> Besides, when we finally move to arch/powerpc, it will become very
> feasable to have a single kernel image that will boot on multiple
> ppc405 FPGA configurations; just change the device tree passed in.
>
>> Similar issues will arise for most (all?) of the Xilinx drivers that we
>> will share between PPC and MicroBlaze. Hopefully we can converge on a
>> nice consistent and clean way of handling these dual arch drivers.
>
> I agree 100%
>
> For your reading pleasure, I've attached the bus attachment changes
> that I've made in my tree. I hope to get this driver accepted into
> mainline during the 2.6.22 merge window; so please get any comments
> you have back to me ASAP.
>
> Cheers,
> g.
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* Re: MPC5200 ethernet communication stops unexpected
From: David Kanceruk @ 2007-04-27 17:22 UTC (permalink / raw)
To: Eberhard Stoll; +Cc: linuxppc-embedded
In-Reply-To: <46322E3F.8050508@berghof.com>
[-- Attachment #1: Type: text/plain, Size: 2953 bytes --]
Hi,
Do your boards use the MPC5200B or MPC5200? Also, do you ever see any
corrupted data? (I'm guessing you would have mentioned it if you did see
corrupted data)
Regards,
Dave
On 4/27/07, Eberhard Stoll <eberhard.stoll@berghof.com> wrote:
>
> Hi,
> > I've the same problem by running MPC5200B, but under MQX ...
> >
> Did you check/compare already some registers with mine?
> Maybe it could be a hint for a hardware problem in the (RevB) processor
> - or a hint for two different drivers which have the same problem :-)
> >> This situation is very rare - only a constellation with 6 Controllers
> >> and a special ethernet communication load leads to this fault - in
> about
> >> one day!
> >>
> No more! Now i can reproduce the fault in between 10 to 30 minutes in my
> office!
>
> Try this:
> 1) Use two mpc5200 boards and a pc which can telnet into the
> controllers. I use 100M
> FullDuplex settings for the link.
> 2) Now telnet into the controllers and start on all controllers a flood
> ping. E.g:
> # ping -f 10.255.226.70
> on 10.255.226.71 and a
> # ping -f 10.255.226.71
> on 10.255.226.70. So both controllers ping each others. You can
> watch the
> dots in your telnet session.
> 3) After some minutes (about 10 to 30 minutes) one of the two
> controllers doesn't
> respond any more. It shows a slow blinking rx led, the link is
> still ok, but the
> controller doesn't respond any more. In the telnet session you can see
> running points on the other controller mixed with some 'E's. In the
> telnet
> session on the other controller you see Ethernet is dead.
> =====================================================
> Congretulations, now you have reproduced the fault!
> =====================================================
>
> It seems that this fault only occurs if the ping is done thru a telnet
> session. Logging into the controller on the serial console and doing the
> pings won't trigger the fault (at least not so fast). This might be a
> timing issue or has to do with Ethernet utilisation. ping -f prints some
> points for transmitted ethernet frames. In case of a telnet session ping
> produces 2 packets at the same time. One for the ping and another for
> the dot in telnet!
> If i do a 'ping -f 10.255.226.71 > /dev/null', which suppresses the
> output now run for hours ...
>
> Eberhard
>
> ______________________________________________________________________
> This email has been scanned by the MessageLabs Email Security System.
> For more information please visit http://www.messagelabs.com/email
> ______________________________________________________________________
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
--
David Kanceruk
"The generation of random numbers is far too important to be left to
chance."
[-- Attachment #2: Type: text/html, Size: 4087 bytes --]
^ permalink raw reply
* Re: MPC5200 ethernet communication stops unexpected
From: Eberhard Stoll @ 2007-04-27 17:09 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <10220160.post@talk.nabble.com>
Hi,
> I've the same problem by running MPC5200B, but under MQX ...
>
Did you check/compare already some registers with mine?
Maybe it could be a hint for a hardware problem in the (RevB) processor
- or a hint for two different drivers which have the same problem :-)
>> This situation is very rare - only a constellation with 6 Controllers
>> and a special ethernet communication load leads to this fault - in about
>> one day!
>>
No more! Now i can reproduce the fault in between 10 to 30 minutes in my
office!
Try this:
1) Use two mpc5200 boards and a pc which can telnet into the
controllers. I use 100M
FullDuplex settings for the link.
2) Now telnet into the controllers and start on all controllers a flood
ping. E.g:
# ping -f 10.255.226.70
on 10.255.226.71 and a
# ping -f 10.255.226.71
on 10.255.226.70. So both controllers ping each others. You can
watch the
dots in your telnet session.
3) After some minutes (about 10 to 30 minutes) one of the two
controllers doesn't
respond any more. It shows a slow blinking rx led, the link is
still ok, but the
controller doesn't respond any more. In the telnet session you can see
running points on the other controller mixed with some 'E's. In the
telnet
session on the other controller you see Ethernet is dead.
=====================================================
Congretulations, now you have reproduced the fault!
=====================================================
It seems that this fault only occurs if the ping is done thru a telnet
session. Logging into the controller on the serial console and doing the
pings won't trigger the fault (at least not so fast). This might be a
timing issue or has to do with Ethernet utilisation. ping -f prints some
points for transmitted ethernet frames. In case of a telnet session ping
produces 2 packets at the same time. One for the ping and another for
the dot in telnet!
If i do a 'ping -f 10.255.226.71 > /dev/null', which suppresses the
output now run for hours ...
Eberhard
______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email
______________________________________________________________________
^ permalink raw reply
* Re: How do external irq's get mapped?
From: Sergei Shtylyov @ 2007-04-27 17:03 UTC (permalink / raw)
To: Charles Krinke; +Cc: Randy Brown, Chris Carlson, Kevin Smith, linuxppc-embedded
In-Reply-To: <9F3F0A752CAEBE4FA7E906CC2FBFF57C06A1EE@MERCURY.inside.istor.com>
Hello.
Charles Krinke wrote:
> Let me try a more simplified IRQ question a different way by only
> referring to the 8541.
> There are 12 external interrupt sources, irq[0..11] and as I understand
> it, they all go through one vector, ExternalInput set in
> head_fsl_booke.S and this vector resolves to "do_IRQ()", which I believe
> is in arch/powerpc/kernel/irq.c (not arch/ppc/kernel/...).
> I am striving to understand how mapping of these external pins
> irq[0..11] gets to IRQ numbers as shown with "cat /proc/interrupts".
IIUC, the external IRQ #'s should follow those occupied by 32 internal IRQs.
But those shown in that file are "virtual" numbers, i.e. they got re-mapped by the kernel as it sees fit (basically, it tries to assign the same # to IRQs above 15 and remaps those below)
> Could someone point me at some references I can read to understand this
> nuance of the 8541 in a linux-2.6.17.11 kernel, please.
I'm not sure arch/powerpc/ in 2.6.17 had the complete MPC8541 support...
WBR, Sergei
^ permalink raw reply
* Re: [PATCH v4] powerpc: 64K page support for kexec
From: Milton Miller @ 2007-04-27 16:59 UTC (permalink / raw)
To: Luke Browning
Cc: Arnd Bergmann, linuxppc-dev, Paul Mackerras, Olof Johansson,
cbe-oss-dev
In-Reply-To: <1177690940.24866.124.camel@luke-laptop>
On Apr 27, 2007, at 11:22 AM, Luke Browni+ /*
> + * FIXME, the code below works for 16M, 64K, and 4K pages as these
> + * fall under the p<=23 rules for calculating the virtual address.
> + * In the case of 16M pages, an extra bit is stolen from the AVPN
> + * field to achieve the requisite 24 bits.
> + *
> + * You can use kexec -l to debug new page support!
> + */
> + BUG_ON(hpte_v & 0x4000000000000000UL && !panic); /* 1T segment */
> + BUG_ON(size == MMU_PAGE_16G && !panic);
> + BUG_ON(size == MMU_PAGE_64K_AP && !panic);
> +
I see I've achived my nefarious goal of making these bugs never happen.
(panic is a function, so you are checking that the staticly linked
non-weak function is available. If you want to check on when
if its a panic kdump or not, you need to decode the flag and pass
it to kexec_sequence, pass it back here, and update all platforms
for the new parameter).
But I still say the check while clearing the table is too late,
it should be a debug scan before clearing any mappings.
milton
^ permalink raw reply
* Re: [PATCH] add reg and stack dump to booke WD handler
From: Dave Jiang @ 2007-04-27 17:01 UTC (permalink / raw)
To: Kumar Gala, paulus; +Cc: linuxppc-dev
In-Reply-To: <20070413221657.GA23624@blade.az.mvista.com>
Paul Mackerras wrote:
> Dave Jiang wrote:
> > Have the booke watchdog dump some useful information when triggered.
> > Hopefully that'll give the user some hint of what happened rather than just a
> > mysterious reboot.
>
> Why not call either die() or panic()? Won't they do what you want?
I think the main thing I'm worried about is kexec. Both panic and die handler
can potentially call kexec. The watchdog cannot be killed unless a hardware
reset happens. So it is possible that during the boot of the kexec'd kernel the
watchdog forces a hardware reset. In fact, the watchdog can actually make kdump
rather tricky since the current implementation makes it being kept alive via
userland.
I'm thinking that the only way to get around that is to ping the watchdog
consistently in something such as the timer interrupt. But then we probably
have to move the initialization of the driver into core kernel code and not a
char driver. Do we want to do that?
--
------------------------------------------------------
Dave Jiang
Software Engineer
MontaVista Software, Inc.
http://www.mvista.com
------------------------------------------------------
^ permalink raw reply
* How do external irq's get mapped?
From: Charles Krinke @ 2007-04-27 16:55 UTC (permalink / raw)
To: Jon Loeliger; +Cc: Randy Brown, Chris Carlson, Kevin Smith, linuxppc-embedded
In-Reply-To: <1177688490.8797.11.camel@ld0161-tx32>
Let me try a more simplified IRQ question a different way by only
referring to the 8541.
There are 12 external interrupt sources, irq[0..11] and as I understand
it, they all go through one vector, ExternalInput set in
head_fsl_booke.S and this vector resolves to "do_IRQ()", which I believe
is in arch/powerpc/kernel/irq.c (not arch/ppc/kernel/...).
I am striving to understand how mapping of these external pins
irq[0..11] gets to IRQ numbers as shown with "cat /proc/interrupts".
Could someone point me at some references I can read to understand this
nuance of the 8541 in a linux-2.6.17.11 kernel, please.
Charles
^ permalink raw reply
* Re: [PATCH v3] powerpc: 64K page support for kexec
From: Milton Miller @ 2007-04-27 16:51 UTC (permalink / raw)
To: Luke Browning
Cc: Arnd Bergmann, linuxppc-dev, Paul Mackerras, Olof Johansson,
cbe-oss-dev
In-Reply-To: <1177684950.24866.121.camel@luke-laptop>
On Apr 27, 2007, at 9:42 AM, Luke Browning wrote:
> On Thu, 2007-04-26 at 23:36 -0500, Milton Miller wrote:
>> It appears the distros want to use a similar kernel for
>> their dump kernel. The would prefer it be the same binary;
>> I'm trying to influence people that it is a softer requirement
>> than not slowing down the primary kernel.
>
> Here's anon-related question. What is the pSeries strategy for
> automating the capture of the dump image and rebooting to a usable
> kernel. Has anybody provided a customized initrd for this purpose that
> ultimately reboots the system to the default kernel. Seems like that is
> more important in terms of minimizing downtime than inlining a
> function.
I'm not involved directly, but my understanding is the distros are
planning to use kdump and makedumpfile or similar, save it to
disk or network, then call the platform reboot (for pSeries, that
would be RTAS). The platform would then be responsible for all
cleanup and reinitializing the new kernel.
So the page-table clear is part of the path to capture the dump.
>> I think a better way to debug this code is to call it from a
>> debugfs hook or xmon dump command to scan the table and do
>> the computation. That code would have the full debugger to
>> notice and print the assert.
>
> I am not familiar with debugfs but I suspect that wasn't an option,
> because the system hung immediately. xmon was not invoked either.
Referring to when you put the trap after the table? Yes I would
expect it to hang, the 700 program check will bounce to 400,
which will then bounce repeatedly against instruction miss.
The point was to check if you could take down the table before
actually taking it down. xmon uses the kernel virtual mappings.
>> Having a xmon function to dump the hash table or a slot
>> might be useful for other purposes.
>>
>
> agreed.
>
>> If you think you need the assert, then I ask it be put under
>> an ifdef or it not be triggered when kexec is called with
>> panic=1 (ie BUG_ON(x && !panic). Alternatively you could
>> run the table with dry-run sometime between cpu_down and the
>> kernel copy.
>
> That is a good idea. That way, people can use kexec -l to debug.
>
>>>> Appart from that,
>>>>
>>>> Acked-by: Benjamin Herrenschmidt <benh at kernel.crashing.org>
>>>>
>>
>> milton
>>
>
^ permalink raw reply
* Fwd: [PATCH] Avoid putting cpu node twice
From: John Rigby @ 2007-04-27 16:39 UTC (permalink / raw)
To: Paul Mackerras, linuxppc
In-Reply-To: <4617E176.6040607@246tNt.com>
This was originally sent to linuxppc-embedded.
---------- Forwarded message ----------
From: Sylvain Munaut <tnt@246tnt.com>
Date: Apr 7, 2007 12:22 PM
Subject: Re: [PATCH] Avoid putting cpu node twice
To: John Rigby <jcrigby@gmail.com>
Cc: Linuxppc-embedded <Linuxppc-embedded@ozlabs.org>, Grant Likely
<grant.likely@secretlab.ca>
John Rigby wrote:
> Call of_find_node_by_type with NULL instead of np
> so the cpu node does not get put twice.
> This was causing kref_put warnings.
>
> Signed-off-by: John Rigby <jrigby@freescale.com>
Acked-by: Sylvain Munaut <tnt@246tNt.com>
> ---
> arch/powerpc/platforms/52xx/lite5200.c | 6 ++++--
> 1 files changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/arch/powerpc/platforms/52xx/lite5200.c
> b/arch/powerpc/platforms/52xx/lite5200.c
> index cc3b40d..d2f90eb 100644
> --- a/arch/powerpc/platforms/52xx/lite5200.c
> +++ b/arch/powerpc/platforms/52xx/lite5200.c
> @@ -108,9 +108,11 @@ static void __init lite5200_setup_arch(void)
> lite5200_setup_cpu(); /* Platorm specific */
>
> #ifdef CONFIG_PCI
> - np = of_find_node_by_type(np, "pci");
> - if (np)
> + np = of_find_node_by_type(NULL, "pci");
> + if (np) {
> mpc52xx_add_bridge(np);
> + of_node_put(np);
> + }
> #endif
>
> #ifdef CONFIG_BLK_DEV_INITRD
> --
> 1.5.0.6
>
^ permalink raw reply
* Re: [PATCH] bootwrapper: cuboot-83xx: Exclude upper 1MB from heap.
From: Scott Wood @ 2007-04-27 16:38 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, paulus
In-Reply-To: <22D52AA1-3719-4532-B1CD-D45BB6834843@kernel.crashing.org>
Kumar Gala wrote:
>
> On Apr 26, 2007, at 12:19 PM, Scott Wood wrote:
>
>> The uppermost part of memory is where u-boot puts the stack, so don't
>> include that in the heap. It's not currently causing problems, as the
>> current code allocates from the bottom of the heap, but this will keep
>> things from potentially breaking if a future implementation were to
>> allocate from the top.
>
>
> Why does it matter where u-boot puts it stack? Once control is handed
> over I'd expect it not to matter.
The bootwrapper uses the stack provided by u-boot (unless the platform
requests otherwise).
-Scott
^ permalink raw reply
* [PATCH v4] powerpc: 64K page support for kexec
From: Luke Browning @ 2007-04-27 16:22 UTC (permalink / raw)
To: Milton Miller
Cc: Arnd Bergmann, linuxppc-dev, Paul Mackerras, Olof Johansson,
cbe-oss-dev
In-Reply-To: <772e4d4c76807769449cf1bf874d2ce1@bga.com>
This patch fixes a couple of kexec problems related to 64K page
support in the kernel. kexec issues a tlbie for each pte. The
parameters for the tlbie are the page size and the virtual address.
Support was missing for the computation of these two parameters
for 64K pages. This patch adds that support.
Signed-off-by: Luke Browning <lukebrowning@us.ibm.com>
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Index: linux-2.6.21-rc4/arch/powerpc/mm/hash_native_64.c
===================================================================
--- linux-2.6.21-rc4.orig/arch/powerpc/mm/hash_native_64.c
+++ linux-2.6.21-rc4/arch/powerpc/mm/hash_native_64.c
@@ -340,31 +340,74 @@ static void native_hpte_invalidate(unsig
local_irq_restore(flags);
}
-/*
- * XXX This need fixing based on page size. It's only used by
- * native_hpte_clear() for now which needs fixing too so they
- * make a good pair...
- */
-static unsigned long slot2va(unsigned long hpte_v, unsigned long slot)
-{
- unsigned long avpn = HPTE_V_AVPN_VAL(hpte_v);
- unsigned long va;
-
- va = avpn << 23;
-
- if (! (hpte_v & HPTE_V_LARGE)) {
- unsigned long vpi, pteg;
+#define LP_SHIFT 12
+#define LP_BITS 8
+#define LP_MASK(i) ((0xFF >> (i)) << LP_SHIFT)
+
+static void hpte_decode(hpte_t *hpte, unsigned long slot,
+ int *psize, unsigned long *va)
+{
+ unsigned long hpte_r = hpte->r;
+ unsigned long hpte_v = hpte->v;
+ unsigned long avpn;
+ int i, size, shift, penc, avpnm_bits;
+
+ if (!(hpte_v & HPTE_V_LARGE))
+ size = MMU_PAGE_4K;
+ else {
+ for (i = 0; i < LP_BITS; i++) {
+ if ((hpte_r & LP_MASK(i+1)) == LP_MASK(i+1))
+ break;
+ }
+ penc = LP_MASK(i+1) >> LP_SHIFT;
+ for (size = 0; size < MMU_PAGE_COUNT; size++) {
- pteg = slot / HPTES_PER_GROUP;
- if (hpte_v & HPTE_V_SECONDARY)
- pteg = ~pteg;
+ /* 4K pages are not represented by LP */
+ if (size == MMU_PAGE_4K)
+ continue;
+
+ /* valid entries have a shift value */
+ if (!mmu_psize_defs[size].shift)
+ continue;
- vpi = ((va >> 28) ^ pteg) & htab_hash_mask;
+ if (penc == mmu_psize_defs[size].penc)
+ break;
+ }
+ }
- va |= vpi << PAGE_SHIFT;
+ /*
+ * FIXME, the code below works for 16M, 64K, and 4K pages as these
+ * fall under the p<=23 rules for calculating the virtual address.
+ * In the case of 16M pages, an extra bit is stolen from the AVPN
+ * field to achieve the requisite 24 bits.
+ *
+ * You can use kexec -l to debug new page support!
+ */
+ BUG_ON(hpte_v & 0x4000000000000000UL && !panic); /* 1T segment */
+ BUG_ON(size == MMU_PAGE_16G && !panic);
+ BUG_ON(size == MMU_PAGE_64K_AP && !panic);
+
+ shift = mmu_psize_defs[size].shift;
+ if (mmu_psize_defs[size].avpnm)
+ avpnm_bits = __ilog2_u64(mmu_psize_defs[size].avpnm) + 1;
+ else
+ avpnm_bits = 0;
+ if (shift - avpnm_bits <= 23) {
+ avpn = HPTE_V_AVPN_VAL(hpte_v) << 23;
+
+ if (shift < 23) {
+ unsigned long vpi, pteg;
+
+ pteg = slot / HPTES_PER_GROUP;
+ if (hpte_v & HPTE_V_SECONDARY)
+ pteg = ~pteg;
+ vpi = ((avpn >> 28) ^ pteg) & htab_hash_mask;
+ avpn |= (vpi << mmu_psize_defs[size].shift);
+ }
}
- return va;
+ *va = avpn;
+ *psize = size;
}
/*
@@ -374,15 +417,14 @@ static unsigned long slot2va(unsigned lo
*
* TODO: add batching support when enabled. remember, no dynamic memory here,
* athough there is the control page available...
- *
- * XXX FIXME: 4k only for now !
*/
static void native_hpte_clear(void)
{
unsigned long slot, slots, flags;
hpte_t *hptep = htab_address;
- unsigned long hpte_v;
+ unsigned long hpte_v, va;
unsigned long pteg_count;
+ int psize;
pteg_count = htab_hash_mask + 1;
@@ -408,8 +450,9 @@ static void native_hpte_clear(void)
* already hold the native_tlbie_lock.
*/
if (hpte_v & HPTE_V_VALID) {
+ hpte_decode(hptep, slot, &psize, &va);
hptep->v = 0;
- __tlbie(slot2va(hpte_v, slot), MMU_PAGE_4K);
+ __tlbie(va, psize);
}
}
^ permalink raw reply
* RE: MPC5200 ethernet communication stops unexpected
From: Daniel Schnell @ 2007-04-27 15:42 UTC (permalink / raw)
To: tacitus, linuxppc-embedded
In-Reply-To: <10220160.post@talk.nabble.com>
Hi,
please post relevant topics on the mailing list in English. We are also =
interested in anything concerning MPC5200B ethernet problems.
Daniel.
-----Original Message-----
From: linuxppc-embedded-bounces+daniel.schnell=3Dmarel.com@ozlabs.org =
[mailto:linuxppc-embedded-bounces+daniel.schnell=3Dmarel.com@ozlabs.org] =
On Behalf Of tacitus
Sent: 27. apr=EDl 2007 14:36
To: linuxppc-embedded@ozlabs.org
Subject: Re: MPC5200 ethernet communication stops unexpected
Hallo Eberhard,=20
I've the same problem by running MPC5200B, but under MQX ...
But my first question, can we chat via german ?
ciao
mark=20
Eberhard Stoll wrote:
>=20
> Hello,
> can someone help me?
> I have some problem with our MPC5200 board running denx linux kernel
> 2.4.25 with ethernet communication.
>=20
> My problem is that our board stops receiving and transmitting any=20
> ethernet frames suddenly and unexpected. No pings - nothing is getting =
> thru the ethernet any more! The rest of the controller is running =
well.
> This situation is very rare - only a constellation with 6 Controllers=20
> and a special ethernet communication load leads to this fault - in=20
> about one day!
>=20
> When i check how many tx and rx buffers are used in the BestComm=20
> buffer descriptor ring (via TaskBDInUse() call) which hold pointers to =
> transmit and receive data, i see all tx and rx buffers are in use!=20
> When i look at the FEC Tx Fifo Status Register i get the value=20
> 0x00030000. This means FEC Tx Fifo empty!
> When i check fec Task Control register i see Tx and Rx Task are=20
> enabled, current Pointer register points to 0xF000828C which belongs=20
> to FEC Tx BestComm Microcode.
> When i now examine the status value of my currently active buffer=20
> descriptor for Tx task, it shows that this buffer belongs to BestComm.
> In my opinion BestComm shold tranfer this buffer to the empty FEC Tx=20
> Fifo - but it doesn't!
> Now the question for me is: WHY?
>=20
> Do i oversee some bits in the registers/ram locations which lead to=20
> this situation?
> I don't know much about BestComm/FEC, but my conclusion out of this is =
> BestComm is stuck somewhere out of some reason. Is this a hardware=20
> issue? Does someone know? Has someone similar problems?
>=20
> Can someone help me or check if i'm right with my conclusion (see=20
> registers and ram locations down)? Or give me a hint where to look=20
> further.
> Any help is very welcome!
>=20
> Many Thanks,
> Eberhard
>=20
> PS: I saw this problem only on MPC5200B processors until now. And we=20
> use BestComm Api 2.2 (the newest denx 2.4.x code for bestcomm)
>=20
> Here are some registers and ram addresses i collected in this =
situation:
>=20
> BTW: I saw BestComm Microcode changing in 16k SRAM after the first=20
> Ethernet frames were sent. This seems very strange to me - but maybe=20
> is correct behaviour - i don't know. Does someone of you?
> Its the address 0xf00082e8 (in FEC Tx BestComm microcode). After reset =
> (no frame sent) the ram at this address is 0x088AC398 after the=20
> first(?) ethernet frame it's 0x0C8AC398!
>=20
> =3D=3D=3D BestComm registers =3D=3D=3D
> taskBar 0xF0008000
> currentPointer 0xF000828C
> endPointer 0x00000000
> variablePointer 0xF0008800
> IntVect1 0x0000000F
> IntVect2 0x0000000F
> PtdCntrl 0x00000001
> IntPend 0x00000000
> IntMask 0xFFFFFFF3
> tcr_0 0x0000
> tcr_1 0x0000
> tcr_2 0xE082
> tcr_3 0xC383
> tcr_4 0x0000
> tcr_5 0x0000
> tcr_6 0x0000
> tcr_7 0x0000
> tcr_8 0x0000
> tcr_9 0x0000
> tcr_a 0x0000
> tcr_b 0x0000
> tcr_c 0x0000
> tcr_d 0x0000
> tcr_e 0x0000
> tcr_f 0x0000
> IPR0 0x07
> IPR1 0x00
> IPR2 0x00
> IPR3 0x04
> IPR4 0x03
> IPR5 0x06
> IPR6 0x05
> IPR7 0x00
> IPR8 0x00
> IPR9 0x00
> IPR10 0x00
> IPR11 0x00
> IPR12 0x00
> IPR13 0x00
> IPR14 0x00
> IPR15 0x00
> IPR16 0x00
> IPR17 0x00
> IPR18 0x00
> IPR19 0x00
> IPR20 0x00
> IPR21 0x00
> IPR22 0x00
> IPR23 0x00
> IPR24 0x00
> IPR25 0x00
> IPR26 0x00
> IPR27 0x00
> IPR28 0x00
> IPR29 0x00
> IPR30 0x00
> IPR31 0x00
> task_size0 0x00000000
> task_size1 0x00000000
> MDEDebug 0x01000008
> ADSDebug 0x00000000
> Value1 0x00000000
> Value2 0x00000000
> Control 0x00000000
> Status 0x00000000
> EU00 0x04155519
> EU01 0x00000000
> EU02 0x00000000
> EU03 0x00000000
> EU04 0x00000000
> EU05 0x00000000
> EU06 0x00000000
> EU07 0x00000000
> EU10 0x00000000
> EU11 0x00000000
> EU12 0x00000000
> EU13 0x00000000
> EU14 0x00000000
> EU15 0x00000000
> EU16 0x00000000
> EU17 0x00000000
> EU20 0x00000000
> EU21 0x00000000
> EU22 0x00000000
> EU23 0x00000000
> EU24 0x00000000
> EU25 0x00000000
> EU26 0x00000000
> EU27 0x00000000
> EU30 0x00000000
> EU31 0x00000000
> EU32 0x00000000
> EU33 0x00000000
> EU34 0x00000000
> EU35 0x00000000
> EU36 0x00000000
> EU37 0x00000000
>=20
> =3D=3D=3D Return values of BestComm Api Functions =3D=3D=3D
> t_tasknum =3D 2
> TaskBDInUse(tx) =3D 256
> TaskStatus(tx) =3D run (0x00008000)
> TaskIntPending(tx) =3D 0
> r_tasknum =3D 3
> TaskBDInUse(rx) =3D 256
> TaskStatus(rx) =3D run (0x00008000)
> TaskIntPending(rx) =3D 0
> TasksGetSramOffset =3D 0x00002500
> task 0: stop int: 0x00000000
> task 1: stop int: 0x00000000
> task 2: run int: 0x00000000
> task 3: run int: 0x00000000
> task 4: stop int: 0x00000000
> task 5: stop int: 0x00000000
> task 6: stop int: 0x00000000
> task 7: stop int: 0x00000000
> task 8: stop int: 0x00000000
> task 9: stop int: 0x00000000
> task 10: stop int: 0x00000000
> task 11: stop int: 0x00000000
> task 12: stop int: 0x00000000
> task 13: stop int: 0x00000000
> task 14: stop int: 0x00000000
> task 15: stop int: 0x00000000
>=20
> =3D=3D=3D FEC Registers =3D=3D=3D
> fec base addr f0003000
> fec_id 0x00000000
> ievent 0x08000000
> imask 0xF0FE0000
> r_des_active 0x00000000
> x_des_active 0x00000000
> ecntrl 0xF0000002
> mii_data 0x5F821200
> mii_speed 0x0000001C
> mib_control 0x40000000
> r_cntrl 0x05EE0024
> r_hash 0x8A000000
> x_cntrl 0x00000004
> paddr1 0x00E0BA90
> paddr2 0x07DC8808
> op_pause 0x00010020
> iaddr1 0x00000000
> iaddr2 0x00000000
> gaddr1 0x00400000
> gaddr2 0x00000000
> x_wmrk 0x00000000
> rfifo_status 0x214E0000
> rfifo_cntrl 0x0F240000
> rfifo_lrf_ptr 0x0000005D
> rfifo_lwf_ptr 0x0000038D
> rfifo_alarm 0x0000030C
> rfifo_rdptr 0x0000005D
> rfifo_wrptr 0x0000005D
> tfifo_status 0x00030000
> tfifo_cntrl 0x0F200000
> tfifo_lrf_ptr 0x0000023C
> tfifo_lwf_ptr 0x0000023C
> tfifo_alarm 0x00000100
> tfifo_rdptr 0x0000023C
> tfifo_wrptr 0x0000023C
> reset_cntrl 0x01000000
> xmit_fsm 0x03000000
>=20
> =3D=3D=3D FEC driver vars =3D=3D=3D
> MBAR 0xF0000000
> MBAR SIZE 0x10000000
> queue_stopped 1
> mpc5xxx_bdi_tx 73 (x49)
> mpc5xxx_bdi_rx 97 (x61)
> adr(tx_fifo_skb) c0233744
> adr(tx_fifo_skb[0]) c0233744
> adr(tx_fifo_skb[1]) c0233748
> tx_fifo_skb[0] c2474f20
> tx_fifo_skb[1] c24846e0
> sizeof(tx_fifo_skb) 1024
> sizeof(tx_fifo_skb[0]) 4
> MPC5xxx_FEC_TBD_NUM 256
> adr(rx_fifo_skb) c0233b44
> sizeof(rx_fifo_skb) 1024
> sizeof(rx_fifo_skb[0]) 4
> MPC5xxx_FEC_RBD_NUM 256
> full_duplex 1
> tx_full 1
> r_tasknum 3
> t_tasknum 2
> r_irq 24
> t_irq 23
> last_transmit_time 0
> last_receive_time 0
> phy_id 0x0015F442
> phy_id_done 1
> phy_status 0x00000000
> phy_speed 28
> sequence_done 0
> link 0
> duplex_change 0
> link_up 0
> old_status 0x00000000
>=20
> =3D=3D=3D BDHead Table =3D=3D=3D
> TASK #0
> [0xC0232D74] =3D 0x00
> [0xC0232D75] =3D 0x00
> [0xC0232D76] =3D 0x00
> [0xC0232D77] =3D 0x00
>=20
> TASK #1
> [0xC0232D78] =3D 0x00
> [0xC0232D79] =3D 0x00
> [0xC0232D7A] =3D 0x00
> [0xC0232D7B] =3D 0x00
>=20
> TASK #2 - tx task
> [0xC0232D7C] =3D 0x00
> [0xC0232D7D] =3D 0x00
> [0xC0232D7E] =3D 0x00
> [0xC0232D7F] =3D 0x49
> --> actual tx index: 0x49->73
>=20
> TASK #3 - rx task
> [0xC0232D80] =3D 0x00
> [0xC0232D81] =3D 0x00
> [0xC0232D82] =3D 0x00
> [0xC0232D83] =3D 0x61
> --> actual rx index: 0x61->97
>=20
> [0xC0232D84] =3D 0x00
> [0xC0232D85] =3D 0x00
> [0xC0232D86] =3D 0x00
> ...
>=20
> =3D=3D=3D TaskBDIdxTable =3D=3D=3D
> TASK#0
> numBD [0xC0232DF4] =3D 0x0000
> numPtr [0xC0232DF6] =3D 0x00
> apiConfig [0xC0232DF7] =3D 0x00
> BDTablePtr [0xC0232DF8] =3D 0x00000000
> BDStartPtr [0xC0232DFC] =3D 0x00000000
> currBDInUse[0xC0232E00] =3D 0x0000
> [0xC0232E02] =3D 0x00
> [0xC0232E03] =3D 0x00
>=20
> TASK#1
> [0xC0232E04] =3D 0x00
> [0xC0232E05] =3D 0x00
> [0xC0232E06] =3D 0x00
> [0xC0232E07] =3D 0x00
> [0xC0232E08] =3D 0x00
> [0xC0232E09] =3D 0x00
> [0xC0232E0A] =3D 0x00
> [0xC0232E0B] =3D 0x00
> [0xC0232E0C] =3D 0x00
> [0xC0232E0D] =3D 0x00
> [0xC0232E0E] =3D 0x00
> [0xC0232E0F] =3D 0x00
> [0xC0232E10] =3D 0x00
> [0xC0232E11] =3D 0x00
> [0xC0232E12] =3D 0x00
> [0xC0232E13] =3D 0x00
>=20
> TASK#2 - tx task
> numBD [0xC0232E14] =3D 0x0100
> numPtr [0xC0232E16] =3D 0x01
> apiConfig [0xC0232E17] =3D 0x01
> BDTablePtr [0xC0232E18] =3D 0xF0009D00
> BDStartPtr [0xC0232E1C] =3D 0xF0008814
> currBDInUse[0xC0232E20] =3D 0x0100
> [0xC0232E22] =3D 0x00
> [0xC0232E23] =3D 0x00
>=20
> TASK#3 - rx task
> numBD [0xC0232E24] =3D 0x0100
> numPtr [0xC0232E26] =3D 0x01
> apiConfig [0xC0232E27] =3D 0x00
> BDTablePtr [0xC0232E28] =3D 0xF0009500
> BDStartPtr [0xC0232E2C] =3D 0xF0008890
> currBDInUse[0xC0232E30] =3D 0x0100
> [0xC0232E32] =3D 0x00
> [0xC0232E33] =3D 0x00
>=20
> TASK#4
> [0xC0232E34] =3D 0x00
> [0xC0232E35] =3D 0x00
> ...
>=20
> =3D=3D=3D Tx Descriptor Ring =3D=3D=3D
> IDX 0x49-(73) is interesting, because active (see BDHeadTable).
> So our descriptor is as Addr 0xF0009D00 + (0x49 * 0x8) =3D 0xF0009F48
>=20
> IDX 0
> [0xF0009D00] =3D 0x4C00003C
> [0xF0009D04] =3D 0x02475922
>=20
> IDX 1
> [0xF0009D08] =3D 0x4C00003C
> [0xF0009D0C] =3D 0x02475CA2
> ...
> IDX 72
> [0xF0009F40] =3D 0x4C00003C
> [0xF0009F44] =3D 0x024665A2
>=20
> IDX 73 - active descriptor
> [0xF0009F48] =3D 0x4C00004E - owns BestComm, should transfer=20
> [0xF0009F4C] =3D 0x0243F05E
>=20
> IDX 74
> [0xF0009F50] =3D 0x4C00004E
> [0xF0009F54] =3D 0x0243F85E
>=20
> ______________________________________________________________________
> This email has been scanned by the MessageLabs Email Security System.
> For more information please visit http://www.messagelabs.com/email=20
> ______________________________________________________________________
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>=20
>=20
--
View this message in context: =
http://www.nabble.com/MPC5200-ethernet-communication-stops-unexpected-tf3=
620140.html#a10220160
Sent from the linuxppc-embedded mailing list archive at Nabble.com.
_______________________________________________
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* Re: IRQ questions & puzzles
From: Jon Loeliger @ 2007-04-27 15:41 UTC (permalink / raw)
To: Charles Krinke
Cc: Randy Brown, Chris Carlson, Kevin Smith,
linuxppc-embedded@ozlabs.org
In-Reply-To: <9F3F0A752CAEBE4FA7E906CC2FBFF57C06A1EB@MERCURY.inside.istor.com>
On Thu, 2007-04-26 at 13:36, Charles Krinke wrote:
> I have a linux-2.6.17.11 source tree that has configs for two boards.
> One has an 8241 and the other has an 8541. The kernel code works fine on
> the 8241, but appears to lock up in my custom driver in the 8541 when
> interrupts are enabled.
OK, let's back up a step. The 8241 and the 8541 are
two very different parts. Different PPC cores with very
different peripherals placed on two very likely different
boards as well. So I am at a bit of a loss to understand
how you are comparing these two parts in casual comparison
like this. You aren't suggesting that you are expecting
these to be the same in some way are you?
> What I see happening, based on using a BDI to go/halt after the apparent
> lockup is that the kernel is spinning around in routines like
> kernel/irq/handle.c:__do_IRQ and an associated
> arch/powerpc/kernel/irq.c.
>
> It looks like the interrupt, which should be level triggered and at this
> point, is probably continuously asserted is causing the kernel to spin
> in a tight loop and be incapable of doing printk's out the serial port
> at 115200.
>
> This leads to a few questions:
It certainly does! :-)
> 1. I can see most everything comes from arch/ppc, but do_IRQ comes from
> arch/powerpc. Is that OK?
"Most everything" for _which_ board? The 8241 or the 8541?
Specifically, the former would easily still be arch/ppc based
while the latter _should_ be arch/powerpc based by now.
When compling arch/powerpc, only legacy #include files should
be being used during the build.
> 2. What is the most straightforward way to slow down a tight loop like
> this slow enough so I can printk what is happening.
Your BDI-2000, likely. :-)
> 3. What might be the likely scenarios leading to such a despicable
> state.
Initial PEBCAK, perhaps? But yea, there may be a level difinition
problem on an line here. Dunno yet, because the scenario seems a
bit strained or ill-described yet...
Any chance for a bit more clarity on what your situation is?
It seems to me that it is quite possible that many of these
issues might vanish with a 2.6.21 build straight up too.
HTH,
jdl
^ permalink raw reply
* RE: IRQ questions & puzzles
From: Charles Krinke @ 2007-04-27 15:17 UTC (permalink / raw)
To: Charles Krinke, linuxppc-embedded
Cc: Randy Brown, Vahid Fereydounkolahi, Chris Carlson, Kevin Smith
In-Reply-To: <9F3F0A752CAEBE4FA7E906CC2FBFF57C06A1EB@MERCURY.inside.istor.com>
Maybe I need to answer part of my question and ask another.
I can see, by putting a printk into ../kernel/irq/handle.c:__do_IRQ that
I normally get 3 interrupts with this 8541 board based on a
linux-2.6.17.11 kernel. A cat /proc/interrupts shows enet_rx on
interrupt 93, enet_tx on interrupt 94 and the serial port in interrupt
106.=20
I have a peripheral that sets irq to 16 and does a request_irq and this
works in the 8541 board. But on the 8541 board, the printk from inside
__do_IRQ shows the irq variable is zero, not 16.
Can someone please help me understand the care and feeding of external
interrupts in the 8541 a bit more completely?
Charles
-----Original Message-----
From: linuxppc-embedded-bounces+ckrinke=3Distor.com@ozlabs.org
[mailto:linuxppc-embedded-bounces+ckrinke=3Distor.com@ozlabs.org] On
Behalf Of Charles Krinke
Sent: Thursday, April 26, 2007 11:36 AM
To: linuxppc-embedded@ozlabs.org
Cc: Randy Brown; Chris Carlson; Kevin Smith
Subject: IRQ questions & puzzles
I have a linux-2.6.17.11 source tree that has configs for two boards.
One has an 8241 and the other has an 8541. The kernel code works fine on
the 8241, but appears to lock up in my custom driver in the 8541 when
interrupts are enabled.
What I see happening, based on using a BDI to go/halt after the apparent
lockup is that the kernel is spinning around in routines like
kernel/irq/handle.c:__do_IRQ and an associated
arch/powerpc/kernel/irq.c.
It looks like the interrupt, which should be level triggered and at this
point, is probably continuously asserted is causing the kernel to spin
in a tight loop and be incapable of doing printk's out the serial port
at 115200.
This leads to a few questions:
1. I can see most everything comes from arch/ppc, but do_IRQ comes from
arch/powerpc. Is that OK?
2. What is the most straightforward way to slow down a tight loop like
this slow enough so I can printk what is happening.
3. What might be the likely scenarios leading to such a despicable
state.
Charles Krinke
_______________________________________________
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* Re: [PATCH v3] powerpc: 64K page support for kexec
From: Luke Browning @ 2007-04-27 14:42 UTC (permalink / raw)
To: Milton Miller
Cc: Arnd Bergmann, linuxppc-dev, Paul Mackerras, Olof Johansson,
cbe-oss-dev
In-Reply-To: <772e4d4c76807769449cf1bf874d2ce1@bga.com>
On Thu, 2007-04-26 at 23:36 -0500, Milton Miller wrote:
> Was your development testing going from 64k to 64k base
> kernel? Or 64k to 4k or 4k to 64k? Did your development
> break 4k pages along the way?
>
The test was from a 64K to 64K kernel. The primary fix was to 4K
mappings as the PAGE_SHIFT macro resolves to 16, so the 4K page hash was
incorrectly applied. The 16M and 64K pages were correctly cleared.
Presumably, this is the reason we had problems with I/O.
> The reason I ask is because when starting a similar kernel,
> I expect any failures of invalidating the kernel linear
> mapping to be mapped with the same mapping the next time.
> If you were going to a dissimilar kernel, or possibly a
> modular kernel with modules loaded in random order, I would
> expect incorrect io-mapping and vmalloc could also pose
> problems you mentioned.
>
> It appears the distros want to use a similar kernel for
> their dump kernel. The would prefer it be the same binary;
> I'm trying to influence people that it is a softer requirement
> than not slowing down the primary kernel.
Here's anon-related question. What is the pSeries strategy for
automating the capture of the dump image and rebooting to a usable
kernel. Has anybody provided a customized initrd for this purpose that
ultimately reboots the system to the default kernel. Seems like that is
more important in terms of minimizing downtime than inlining a function.
> I think a better way to debug this code is to call it from a
> debugfs hook or xmon dump command to scan the table and do
> the computation. That code would have the full debugger to
> notice and print the assert.
I am not familiar with debugfs but I suspect that wasn't an option,
because the system hung immediately. xmon was not invoked either.
>
> Having a xmon function to dump the hash table or a slot
> might be useful for other purposes.
>
agreed.
> If you think you need the assert, then I ask it be put under
> an ifdef or it not be triggered when kexec is called with
> panic=1 (ie BUG_ON(x && !panic). Alternatively you could
> run the table with dry-run sometime between cpu_down and the
> kernel copy.
That is a good idea. That way, people can use kexec -l to debug.
>
> > > Appart from that,
> > >
> > > Acked-by: Benjamin Herrenschmidt <benh at kernel.crashing.org>
> > >
>
> milton
>
^ permalink raw reply
* Re: MPC5200 ethernet communication stops unexpected
From: tacitus @ 2007-04-27 14:35 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <462912AC.8090102@berghof.com>
Hallo Eberhard,
I've the same problem by running MPC5200B, but under MQX ...
But my first question, can we chat via german ?
ciao
mark
Eberhard Stoll wrote:
>
> Hello,
> can someone help me?
> I have some problem with our MPC5200 board running denx linux kernel
> 2.4.25 with ethernet communication.
>
> My problem is that our board stops receiving and transmitting any
> ethernet frames suddenly and unexpected. No pings - nothing is getting
> thru the ethernet any more! The rest of the controller is running well.
> This situation is very rare - only a constellation with 6 Controllers
> and a special ethernet communication load leads to this fault - in about
> one day!
>
> When i check how many tx and rx buffers are used in the BestComm buffer
> descriptor ring (via TaskBDInUse() call) which hold pointers to transmit
> and receive data, i see all tx and rx buffers are in use! When i look at
> the FEC Tx Fifo Status Register i get the value 0x00030000. This means
> FEC Tx Fifo empty!
> When i check fec Task Control register i see Tx and Rx Task are enabled,
> current Pointer register points to 0xF000828C which belongs to FEC Tx
> BestComm Microcode.
> When i now examine the status value of my currently active buffer
> descriptor for Tx task, it shows that this buffer belongs to BestComm.
> In my opinion BestComm shold tranfer this buffer to the empty FEC Tx
> Fifo - but it doesn't!
> Now the question for me is: WHY?
>
> Do i oversee some bits in the registers/ram locations which lead to this
> situation?
> I don't know much about BestComm/FEC, but my conclusion out of this is
> BestComm is stuck somewhere out of some reason. Is this a hardware
> issue? Does someone know? Has someone similar problems?
>
> Can someone help me or check if i'm right with my conclusion (see
> registers and ram locations down)? Or give me a hint where to look
> further.
> Any help is very welcome!
>
> Many Thanks,
> Eberhard
>
> PS: I saw this problem only on MPC5200B processors until now. And we use
> BestComm Api 2.2 (the newest denx 2.4.x code for bestcomm)
>
> Here are some registers and ram addresses i collected in this situation:
>
> BTW: I saw BestComm Microcode changing in 16k SRAM after the first
> Ethernet frames were sent. This seems very strange to me - but maybe is
> correct behaviour - i don't know. Does someone of you?
> Its the address 0xf00082e8 (in FEC Tx BestComm microcode). After reset
> (no frame sent) the ram at this address is 0x088AC398 after the first(?)
> ethernet frame it's 0x0C8AC398!
>
> === BestComm registers ===
> taskBar 0xF0008000
> currentPointer 0xF000828C
> endPointer 0x00000000
> variablePointer 0xF0008800
> IntVect1 0x0000000F
> IntVect2 0x0000000F
> PtdCntrl 0x00000001
> IntPend 0x00000000
> IntMask 0xFFFFFFF3
> tcr_0 0x0000
> tcr_1 0x0000
> tcr_2 0xE082
> tcr_3 0xC383
> tcr_4 0x0000
> tcr_5 0x0000
> tcr_6 0x0000
> tcr_7 0x0000
> tcr_8 0x0000
> tcr_9 0x0000
> tcr_a 0x0000
> tcr_b 0x0000
> tcr_c 0x0000
> tcr_d 0x0000
> tcr_e 0x0000
> tcr_f 0x0000
> IPR0 0x07
> IPR1 0x00
> IPR2 0x00
> IPR3 0x04
> IPR4 0x03
> IPR5 0x06
> IPR6 0x05
> IPR7 0x00
> IPR8 0x00
> IPR9 0x00
> IPR10 0x00
> IPR11 0x00
> IPR12 0x00
> IPR13 0x00
> IPR14 0x00
> IPR15 0x00
> IPR16 0x00
> IPR17 0x00
> IPR18 0x00
> IPR19 0x00
> IPR20 0x00
> IPR21 0x00
> IPR22 0x00
> IPR23 0x00
> IPR24 0x00
> IPR25 0x00
> IPR26 0x00
> IPR27 0x00
> IPR28 0x00
> IPR29 0x00
> IPR30 0x00
> IPR31 0x00
> task_size0 0x00000000
> task_size1 0x00000000
> MDEDebug 0x01000008
> ADSDebug 0x00000000
> Value1 0x00000000
> Value2 0x00000000
> Control 0x00000000
> Status 0x00000000
> EU00 0x04155519
> EU01 0x00000000
> EU02 0x00000000
> EU03 0x00000000
> EU04 0x00000000
> EU05 0x00000000
> EU06 0x00000000
> EU07 0x00000000
> EU10 0x00000000
> EU11 0x00000000
> EU12 0x00000000
> EU13 0x00000000
> EU14 0x00000000
> EU15 0x00000000
> EU16 0x00000000
> EU17 0x00000000
> EU20 0x00000000
> EU21 0x00000000
> EU22 0x00000000
> EU23 0x00000000
> EU24 0x00000000
> EU25 0x00000000
> EU26 0x00000000
> EU27 0x00000000
> EU30 0x00000000
> EU31 0x00000000
> EU32 0x00000000
> EU33 0x00000000
> EU34 0x00000000
> EU35 0x00000000
> EU36 0x00000000
> EU37 0x00000000
>
> === Return values of BestComm Api Functions ===
> t_tasknum = 2
> TaskBDInUse(tx) = 256
> TaskStatus(tx) = run (0x00008000)
> TaskIntPending(tx) = 0
> r_tasknum = 3
> TaskBDInUse(rx) = 256
> TaskStatus(rx) = run (0x00008000)
> TaskIntPending(rx) = 0
> TasksGetSramOffset = 0x00002500
> task 0: stop int: 0x00000000
> task 1: stop int: 0x00000000
> task 2: run int: 0x00000000
> task 3: run int: 0x00000000
> task 4: stop int: 0x00000000
> task 5: stop int: 0x00000000
> task 6: stop int: 0x00000000
> task 7: stop int: 0x00000000
> task 8: stop int: 0x00000000
> task 9: stop int: 0x00000000
> task 10: stop int: 0x00000000
> task 11: stop int: 0x00000000
> task 12: stop int: 0x00000000
> task 13: stop int: 0x00000000
> task 14: stop int: 0x00000000
> task 15: stop int: 0x00000000
>
> === FEC Registers ===
> fec base addr f0003000
> fec_id 0x00000000
> ievent 0x08000000
> imask 0xF0FE0000
> r_des_active 0x00000000
> x_des_active 0x00000000
> ecntrl 0xF0000002
> mii_data 0x5F821200
> mii_speed 0x0000001C
> mib_control 0x40000000
> r_cntrl 0x05EE0024
> r_hash 0x8A000000
> x_cntrl 0x00000004
> paddr1 0x00E0BA90
> paddr2 0x07DC8808
> op_pause 0x00010020
> iaddr1 0x00000000
> iaddr2 0x00000000
> gaddr1 0x00400000
> gaddr2 0x00000000
> x_wmrk 0x00000000
> rfifo_status 0x214E0000
> rfifo_cntrl 0x0F240000
> rfifo_lrf_ptr 0x0000005D
> rfifo_lwf_ptr 0x0000038D
> rfifo_alarm 0x0000030C
> rfifo_rdptr 0x0000005D
> rfifo_wrptr 0x0000005D
> tfifo_status 0x00030000
> tfifo_cntrl 0x0F200000
> tfifo_lrf_ptr 0x0000023C
> tfifo_lwf_ptr 0x0000023C
> tfifo_alarm 0x00000100
> tfifo_rdptr 0x0000023C
> tfifo_wrptr 0x0000023C
> reset_cntrl 0x01000000
> xmit_fsm 0x03000000
>
> === FEC driver vars ===
> MBAR 0xF0000000
> MBAR SIZE 0x10000000
> queue_stopped 1
> mpc5xxx_bdi_tx 73 (x49)
> mpc5xxx_bdi_rx 97 (x61)
> adr(tx_fifo_skb) c0233744
> adr(tx_fifo_skb[0]) c0233744
> adr(tx_fifo_skb[1]) c0233748
> tx_fifo_skb[0] c2474f20
> tx_fifo_skb[1] c24846e0
> sizeof(tx_fifo_skb) 1024
> sizeof(tx_fifo_skb[0]) 4
> MPC5xxx_FEC_TBD_NUM 256
> adr(rx_fifo_skb) c0233b44
> sizeof(rx_fifo_skb) 1024
> sizeof(rx_fifo_skb[0]) 4
> MPC5xxx_FEC_RBD_NUM 256
> full_duplex 1
> tx_full 1
> r_tasknum 3
> t_tasknum 2
> r_irq 24
> t_irq 23
> last_transmit_time 0
> last_receive_time 0
> phy_id 0x0015F442
> phy_id_done 1
> phy_status 0x00000000
> phy_speed 28
> sequence_done 0
> link 0
> duplex_change 0
> link_up 0
> old_status 0x00000000
>
> === BDHead Table ===
> TASK #0
> [0xC0232D74] = 0x00
> [0xC0232D75] = 0x00
> [0xC0232D76] = 0x00
> [0xC0232D77] = 0x00
>
> TASK #1
> [0xC0232D78] = 0x00
> [0xC0232D79] = 0x00
> [0xC0232D7A] = 0x00
> [0xC0232D7B] = 0x00
>
> TASK #2 - tx task
> [0xC0232D7C] = 0x00
> [0xC0232D7D] = 0x00
> [0xC0232D7E] = 0x00
> [0xC0232D7F] = 0x49
> --> actual tx index: 0x49->73
>
> TASK #3 - rx task
> [0xC0232D80] = 0x00
> [0xC0232D81] = 0x00
> [0xC0232D82] = 0x00
> [0xC0232D83] = 0x61
> --> actual rx index: 0x61->97
>
> [0xC0232D84] = 0x00
> [0xC0232D85] = 0x00
> [0xC0232D86] = 0x00
> ...
>
> === TaskBDIdxTable ===
> TASK#0
> numBD [0xC0232DF4] = 0x0000
> numPtr [0xC0232DF6] = 0x00
> apiConfig [0xC0232DF7] = 0x00
> BDTablePtr [0xC0232DF8] = 0x00000000
> BDStartPtr [0xC0232DFC] = 0x00000000
> currBDInUse[0xC0232E00] = 0x0000
> [0xC0232E02] = 0x00
> [0xC0232E03] = 0x00
>
> TASK#1
> [0xC0232E04] = 0x00
> [0xC0232E05] = 0x00
> [0xC0232E06] = 0x00
> [0xC0232E07] = 0x00
> [0xC0232E08] = 0x00
> [0xC0232E09] = 0x00
> [0xC0232E0A] = 0x00
> [0xC0232E0B] = 0x00
> [0xC0232E0C] = 0x00
> [0xC0232E0D] = 0x00
> [0xC0232E0E] = 0x00
> [0xC0232E0F] = 0x00
> [0xC0232E10] = 0x00
> [0xC0232E11] = 0x00
> [0xC0232E12] = 0x00
> [0xC0232E13] = 0x00
>
> TASK#2 - tx task
> numBD [0xC0232E14] = 0x0100
> numPtr [0xC0232E16] = 0x01
> apiConfig [0xC0232E17] = 0x01
> BDTablePtr [0xC0232E18] = 0xF0009D00
> BDStartPtr [0xC0232E1C] = 0xF0008814
> currBDInUse[0xC0232E20] = 0x0100
> [0xC0232E22] = 0x00
> [0xC0232E23] = 0x00
>
> TASK#3 - rx task
> numBD [0xC0232E24] = 0x0100
> numPtr [0xC0232E26] = 0x01
> apiConfig [0xC0232E27] = 0x00
> BDTablePtr [0xC0232E28] = 0xF0009500
> BDStartPtr [0xC0232E2C] = 0xF0008890
> currBDInUse[0xC0232E30] = 0x0100
> [0xC0232E32] = 0x00
> [0xC0232E33] = 0x00
>
> TASK#4
> [0xC0232E34] = 0x00
> [0xC0232E35] = 0x00
> ...
>
> === Tx Descriptor Ring ===
> IDX 0x49-(73) is interesting, because active (see BDHeadTable).
> So our descriptor is as Addr 0xF0009D00 + (0x49 * 0x8) = 0xF0009F48
>
> IDX 0
> [0xF0009D00] = 0x4C00003C
> [0xF0009D04] = 0x02475922
>
> IDX 1
> [0xF0009D08] = 0x4C00003C
> [0xF0009D0C] = 0x02475CA2
> ...
> IDX 72
> [0xF0009F40] = 0x4C00003C
> [0xF0009F44] = 0x024665A2
>
> IDX 73 - active descriptor
> [0xF0009F48] = 0x4C00004E - owns BestComm, should transfer
> [0xF0009F4C] = 0x0243F05E
>
> IDX 74
> [0xF0009F50] = 0x4C00004E
> [0xF0009F54] = 0x0243F85E
>
> ______________________________________________________________________
> This email has been scanned by the MessageLabs Email Security System.
> For more information please visit http://www.messagelabs.com/email
> ______________________________________________________________________
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
>
--
View this message in context: http://www.nabble.com/MPC5200-ethernet-communication-stops-unexpected-tf3620140.html#a10220160
Sent from the linuxppc-embedded mailing list archive at Nabble.com.
^ permalink raw reply
* kref badness with snd-aoa, powerpc.git
From: Johannes Berg @ 2007-04-27 14:29 UTC (permalink / raw)
To: linuxppc-dev list
[-- Attachment #1: Type: text/plain, Size: 1800 bytes --]
Hi,
I'm not exactly sure what is causing this for aoa:
[ 149.604347] ------------[ cut here ]------------
[ 149.604363] Badness at lib/kref.c:32
[ 149.604368] Call Trace:
[ 149.604373] [e9211bc0] [c0008e24] show_stack+0x3c/0x194 (unreliable)
[ 149.604394] [e9211bf0] [c018afc4] report_bug+0x84/0xf4
[ 149.604412] [e9211c00] [c02f8674] __kprobes_text_start+0xd4/0x53c
[ 149.604431] [e9211c50] [c0011b10] ret_from_except_full+0x0/0x4c
[ 149.604445] --- Exception: 700 at kref_get+0xc/0x24
[ 149.604456] LR = of_node_get+0x20/0x38
[ 149.604462] [e9211d10] [c008c10c] kmem_cache_zalloc+0xac/0x114 (unreliable)
[ 149.604475] [e9211d20] [c000f764] of_get_next_child+0x3c/0x98
[ 149.604485] [e9211d40] [f265d20c] i2sbus_probe+0x54/0x664 [snd_aoa_i2sbus]
[ 149.604504] [e9211da0] [c01fe664] macio_device_probe+0x5c/0x84
[ 149.604518] [e9211dc0] [c01eed4c] really_probe+0x80/0x17c
[ 149.604530] [e9211de0] [c01ef124] __driver_attach+0xe8/0x118
[ 149.604541] [e9211e00] [c01ee000] bus_for_each_dev+0x58/0x94
[ 149.604551] [e9211e30] [c01eeb94] driver_attach+0x24/0x34
[ 149.604561] [e9211e40] [c01ee40c] bus_add_driver+0x88/0x1b4
[ 149.604571] [e9211e60] [c01ef464] driver_register+0x68/0xb0
[ 149.604581] [e9211e70] [c01fe528] macio_register_driver+0x28/0x38
[ 149.604592] [e9211e80] [f25e0018] soundbus_i2sbus_init+0x18/0x48 [snd_aoa_i2sbus]
[ 149.604604] [e9211e90] [c0051da0] sys_init_module+0x170/0x1578
[ 149.604615] [e9211f40] [c00114b4] ret_from_syscall+0x0/0x38
[ 149.604625] --- Exception: c01 at 0xff6e284
[ 149.604648] LR = 0x10003c50
It prints a few more of these coming from __pmf_find_function. May well
be a refcounting bug in aoa itself, but I can't seem to make out what it
would be. Does anybody have any ideas?
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 190 bytes --]
^ permalink raw reply
* Re: [PATCH] bootwrapper: cuboot-83xx: Exclude upper 1MB from heap.
From: Kumar Gala @ 2007-04-27 14:22 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, paulus
In-Reply-To: <20070426171931.GA13647@ld0162-tx32.am.freescale.net>
On Apr 26, 2007, at 12:19 PM, Scott Wood wrote:
> The uppermost part of memory is where u-boot puts the stack, so don't
> include that in the heap. It's not currently causing problems, as the
> current code allocates from the bottom of the heap, but this will keep
> things from potentially breaking if a future implementation were to
> allocate from the top.
Why does it matter where u-boot puts it stack? Once control is
handed over I'd expect it not to matter.
- k
>
> Signed-off-by: Scott Wood <scottwood@freescale.com>
> ---
> arch/powerpc/boot/cuboot-83xx.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/arch/powerpc/boot/cuboot-83xx.c b/arch/powerpc/boot/
> cuboot-83xx.c
> index 8f11d1e..6cbc20a 100644
> --- a/arch/powerpc/boot/cuboot-83xx.c
> +++ b/arch/powerpc/boot/cuboot-83xx.c
> @@ -61,7 +61,7 @@ void platform_init(unsigned long r3, unsigned
> long r4, unsigned long r5,
> loader_info.cmdline = (char *)r6;
> loader_info.cmdline_len = r7 - r6;
>
> - simple_alloc_init(_end, avail_ram, 32, 64);
> + simple_alloc_init(_end, avail_ram - 1024*1024, 32, 64);
> ft_init(_dtb_start, _dtb_end - _dtb_start, 32);
> serial_console_init();
> platform_ops.fixups = platform_fixups;
> --
> 1.5.0.3
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply
* Re: mpc5200 and spi bus
From: Txema Lopez @ 2007-04-27 12:41 UTC (permalink / raw)
To: Asier Llano Palacios; +Cc: linuxppc-embedded
In-Reply-To: <1177670193.9950.9.camel@a.llano.llano>
[-- Attachment #1: Type: text/plain, Size: 766 bytes --]
Asier Llano Palacios wrote:
>I'm working with the a linux 2.6.20.9 with patches from Sylvain's tree.
>I've been looking the Den'x 2.5.xx SPI support and it seems that it is
>done through GPIOs.
>
¿2.5.xx?. I talked about a 2.4.xx version.
>I'd like a native SPI implementation, using the
>hardware of the MPC5200, because of the performance issue of using a
>GPIO, because I'd like to use it at full speed.
>
>Is it done really with GPIOs? If so, is there any other implementation?
>
>
Yes, you can use the MPC5200's dedicated SPI (spi-algo-mpc5xxx.c) or use
a PSC in SPI codec mode (spi-algo-mpc5xxx-psc.c).
>If it is possible I'd like it to be for 2.6.x.
>
>
I don't know nothing about the MPC5200 SPI implementation in the 2.6.x
kernel.
Best regards,
[-- Attachment #2: tlopez.vcf --]
[-- Type: text/x-vcard, Size: 324 bytes --]
begin:vcard
fn:Jose Maria Lopez
n:Lopez;Jose Maria
org:Fagor Automation S. Coop.
adr:;;San Andres 19. Apdo. 144;Arrasate-Mondragon;;20500;Spain
email;internet:tlopez@aotek.es
title:Sotware engineer
tel;work:(34) 943719200
tel;fax:(34) 943791712
x-mozilla-html:FALSE
url:http://www.fagorautomation.es
version:2.1
end:vcard
^ permalink raw reply
* Re: [RFC] SystemACE driver - abstract register ops
From: Stefan Roese @ 2007-04-27 12:11 UTC (permalink / raw)
To: linuxppc-embedded; +Cc: Andrei Konovalov, Rick Moleres
In-Reply-To: <528646bc0704270031w5c9966f8tc3a5e5292df10a35@mail.gmail.com>
On Friday 27 April 2007 09:31, Grant Likely wrote:
> For your reading pleasure, I've attached the bus attachment changes
> that I've made in my tree. I hope to get this driver accepted into
> mainline during the 2.6.22 merge window; so please get any comments
> you have back to me ASAP.
Works fine on my Katmai 440SPe system with SysACE connected in 16bit
big-endian mode. Thanks.
Acked-by Stefan Roese <sr@denx.de>
Best regards,
Stefan
^ permalink raw reply
* Re: patches for 2.6.22
From: Johannes Berg @ 2007-04-27 12:00 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <17969.56735.644629.328360@cargo.ozlabs.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 625 bytes --]
On Fri, 2007-04-27 at 21:25 +1000, Paul Mackerras wrote:
> If anyone has patches that I haven't picked up yet which they think
> should go into 2.6.22, please send me either a pointer to the
> patches if previously posted to linuxppc-dev, or post them to
> linuxppc-dev.
I'd love to have a bunch of the suspend work in 2.6.22, and even if it's
not the suspend to disk implementation for my G5 but just the suspend to
ram with /sys/power/state for pmu-based machines. However, that depends
on some patches that are still in -mm, what's the way forward with that?
Should I poke akpm to send them out?
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 190 bytes --]
^ permalink raw reply
* patches for 2.6.22
From: Paul Mackerras @ 2007-04-27 11:25 UTC (permalink / raw)
To: linuxppc-dev
I have pushed out some more patches to the for-2.6.22 branch of the
powerpc.git repository. I intend in the next couple of days to ask
Linus to pull that branch.
If anyone has patches that I haven't picked up yet which they think
should go into 2.6.22, please send me either a pointer to the
patches if previously posted to linuxppc-dev, or post them to
linuxppc-dev. Note that I don't read linuxppc-embedded, and I rely on
platform maintainers to forward any patches that are ready for
inclusion to me and the linuxppc-dev list.
I'm willing to take arch/ppc patches that fix bugs or generally keep
the existing platforms there working. I don't want to put large lumps
of new code in there, though.
Due to a mistake on my part (I put in the pasemi RNG driver) I have
had to rebase some of the patches in for-2.6.22 branch, so if you have
done a pull of the for-2.6.22 or master branches in the last 5 hours,
please do a pull -f to get the new set.
Paul.
^ permalink raw reply
* [PATCH 2.6.22] pasemi: hardware rng driver
From: Michael Buesch @ 2007-04-27 10:54 UTC (permalink / raw)
To: Andrew Morton; +Cc: Olof Johansson, linuxppc-dev, egor, arnd
From: Olof Johansson <olof@lixom.net>
Driver for the on-chip hardware random number generator on PA Semi
PA6T-1682M.
Signed-off-by: Egor Martovetsky <egor@pasemi.com>
Signed-off-by: Olof Johansson <olof@lixom.net>
Signed-off-by: Michael Buesch <mb@bu3sch.de>
---
This is patch version 3.
v3:
* error return codes
* iounmap on register fail
* fix iounmap race on remove
v2:
* Moved register pointer to hwrng->priv
* Cleanups (__init/__exit, module_init/exit)
Index: powerpc/drivers/char/hw_random/Kconfig
===================================================================
--- powerpc.orig/drivers/char/hw_random/Kconfig
+++ powerpc/drivers/char/hw_random/Kconfig
@@ -91,3 +91,17 @@ config HW_RANDOM_OMAP
module will be called omap-rng.
If unsure, say Y.
+
+config HW_RANDOM_PASEMI
+ tristate "PA Semi HW Random Number Generator support"
+ depends on HW_RANDOM && PPC_PASEMI
+ default HW_RANDOM
+ ---help---
+ This driver provides kernel-side support for the Random Number
+ Generator hardware found on PA6T-1682M processor.
+
+ To compile this driver as a module, choose M here: the
+ module will be called pasemi-rng.
+
+ If unsure, say Y.
+
Index: powerpc/drivers/char/hw_random/Makefile
===================================================================
--- powerpc.orig/drivers/char/hw_random/Makefile
+++ powerpc/drivers/char/hw_random/Makefile
@@ -10,3 +10,4 @@ obj-$(CONFIG_HW_RANDOM_GEODE) += geode-r
obj-$(CONFIG_HW_RANDOM_VIA) += via-rng.o
obj-$(CONFIG_HW_RANDOM_IXP4XX) += ixp4xx-rng.o
obj-$(CONFIG_HW_RANDOM_OMAP) += omap-rng.o
+obj-$(CONFIG_HW_RANDOM_PASEMI) += pasemi-rng.o
Index: powerpc/drivers/char/hw_random/pasemi-rng.c
===================================================================
--- /dev/null
+++ powerpc/drivers/char/hw_random/pasemi-rng.c
@@ -0,0 +1,158 @@
+/*
+ * Copyright (C) 2006-2007 PA Semi, Inc
+ *
+ * Maintained by: Olof Johansson <olof@lixom.net>
+ *
+ * Driver for the PWRficient onchip rng
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+
+#include <linux/module.h>
+#include <linux/kernel.h>
+#include <linux/platform_device.h>
+#include <linux/hw_random.h>
+#include <asm/of_platform.h>
+#include <asm/io.h>
+
+#define SDCRNG_CTL_REG 0x00
+#define SDCRNG_CTL_FVLD_M 0x0000f000
+#define SDCRNG_CTL_FVLD_S 12
+#define SDCRNG_CTL_KSZ 0x00000800
+#define SDCRNG_CTL_RSRC_CRG 0x00000010
+#define SDCRNG_CTL_RSRC_RRG 0x00000000
+#define SDCRNG_CTL_CE 0x00000004
+#define SDCRNG_CTL_RE 0x00000002
+#define SDCRNG_CTL_DR 0x00000001
+#define SDCRNG_CTL_SELECT_RRG_RNG (SDCRNG_CTL_RE | SDCRNG_CTL_RSRC_RRG)
+#define SDCRNG_CTL_SELECT_CRG_RNG (SDCRNG_CTL_CE | SDCRNG_CTL_RSRC_CRG)
+#define SDCRNG_VAL_REG 0x20
+
+#define MODULE_NAME "pasemi_rng"
+
+static int pasemi_rng_data_present(struct hwrng *rng)
+{
+ void __iomem *rng_regs = (void __iomem *)rng->priv;
+
+ return (in_le32(rng_regs + SDCRNG_CTL_REG)
+ & SDCRNG_CTL_FVLD_M) ? 1 : 0;
+}
+
+static int pasemi_rng_data_read(struct hwrng *rng, u32 *data)
+{
+ void __iomem *rng_regs = (void __iomem *)rng->priv;
+ *data = in_le32(rng_regs + SDCRNG_VAL_REG);
+ return 4;
+}
+
+static int pasemi_rng_init(struct hwrng *rng)
+{
+ void __iomem *rng_regs = (void __iomem *)rng->priv;
+ u32 ctl;
+
+ ctl = SDCRNG_CTL_DR | SDCRNG_CTL_SELECT_RRG_RNG | SDCRNG_CTL_KSZ;
+ out_le32(rng_regs + SDCRNG_CTL_REG, ctl);
+ out_le32(rng_regs + SDCRNG_CTL_REG, ctl & ~SDCRNG_CTL_DR);
+
+ return 0;
+}
+
+static void pasemi_rng_cleanup(struct hwrng *rng)
+{
+ void __iomem *rng_regs = (void __iomem *)rng->priv;
+ u32 ctl;
+
+ ctl = SDCRNG_CTL_RE | SDCRNG_CTL_CE;
+ out_le32(rng_regs + SDCRNG_CTL_REG,
+ in_le32(rng_regs + SDCRNG_CTL_REG) & ~ctl);
+}
+
+static struct hwrng pasemi_rng = {
+ .name = MODULE_NAME,
+ .init = pasemi_rng_init,
+ .cleanup = pasemi_rng_cleanup,
+ .data_present = pasemi_rng_data_present,
+ .data_read = pasemi_rng_data_read,
+};
+
+static int __devinit rng_probe(struct of_device *ofdev,
+ const struct of_device_id *match)
+{
+ void __iomem *rng_regs;
+ struct device_node *rng_np = ofdev->node;
+ struct resource res;
+ int err = 0;
+
+ err = of_address_to_resource(rng_np, 0, &res);
+ if (err)
+ return -ENODEV;
+
+ rng_regs = ioremap(res.start, 0x100);
+
+ if (!rng_regs)
+ return -ENOMEM;
+
+ pasemi_rng.priv = (unsigned long)rng_regs;
+
+ printk(KERN_INFO "Registering PA Semi RNG\n");
+
+ err = hwrng_register(&pasemi_rng);
+
+ if (err)
+ iounmap(rng_regs);
+
+ return err;
+}
+
+static int __devexit rng_remove(struct of_device *dev)
+{
+ void __iomem *rng_regs = (void __iomem *)pasemi_rng.priv;
+
+ hwrng_unregister(&pasemi_rng);
+ iounmap(rng_regs);
+
+ return 0;
+}
+
+static struct of_device_id rng_match[] =
+{
+ {
+ .compatible = "1682m-rng",
+ },
+ {},
+};
+
+static struct of_platform_driver rng_driver =
+{
+ .name = "pasemi-rng",
+ .match_table = rng_match,
+ .probe = rng_probe,
+ .remove = rng_remove,
+};
+
+static int __init rng_init(void)
+{
+ return of_register_platform_driver(&rng_driver);
+}
+module_init(rng_init);
+
+static void __exit rng_exit(void)
+{
+ of_unregister_platform_driver(&rng_driver);
+}
+module_exit(rng_exit);
+
+MODULE_LICENSE("GPL");
+MODULE_AUTHOR("Egor Martovetsky <egor@pasemi.com>");
+MODULE_DESCRIPTION("H/W RNG driver for PA Semi processor");
--
Greetings Michael.
^ permalink raw reply
* Re: mpc5200 and spi bus
From: Asier Llano Palacios @ 2007-04-27 10:36 UTC (permalink / raw)
To: Txema Lopez; +Cc: linuxppc-embedded
In-Reply-To: <4630BBF9.7000305@aotek.es>
I'm working with the a linux 2.6.20.9 with patches from Sylvain's tree.
I've been looking the Den'x 2.5.xx SPI support and it seems that it is
done through GPIOs. I'd like a native SPI implementation, using the
hardware of the MPC5200, because of the performance issue of using a
GPIO, because I'd like to use it at full speed.
Is it done really with GPIOs? If so, is there any other implementation?
If it is possible I'd like it to be for 2.6.x.
Thank you,
Asier
El jue, 26-04-2007 a las 16:49 +0200, Txema Lopez escribi=F3:
> Asier Llano Palacios wrote:
>=20
> >I've seen some comments about drivers for SPI of the MPC5200. I'm not
> >sure about it, but is there anything functional about it?. I want to
> >know if there is anything already done, in order to use it or improve
> >it. I need a driver of the SPI bus, so if it is not implemented at =
all
> >we should contribute it.
> >
> > =20
> >
> The Denx's 2.4.xx top of tree kernel has MPC5200 SPI support. We are=20
> using the SPI dev interface from a user aplication and it works fine.
>=20
>=20
=20
----------------------------------------- PLEASE NOTE =
-------------------------------------------
This message, along with any attachments, may be confidential or legally =
privileged.=20
It is intended only for the named person(s), who is/are the only =
authorized recipients.
If this message has reached you in error, kindly destroy it without =
review and notify the sender immediately.
Thank you for your help.
=B5SysCom uses virus scanning software but excludes any liability for =
viruses contained in any attachment.
=20
------------------------------------ ROGAMOS LEA ESTE TEXTO =
-------------------------------
Este mensaje y sus anexos pueden contener informaci=F3n confidencial y/o =
con derecho legal.=20
Est=E1 dirigido =FAnicamente a la/s persona/s o entidad/es rese=F1adas =
como =FAnico destinatario autorizado.
Si este mensaje le hubiera llegado por error, por favor elim=EDnelo sin =
revisarlo ni reenviarlo y notif=EDquelo inmediatamente al remitente. =
Gracias por su colaboraci=F3n. =20
=B5SysCom utiliza software antivirus, pero no se hace responsable de los =
virus contenidos en los ficheros anexos.
^ 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