* Re: mpc8248 SEC -- interrupt handler not invoked
From: Kim Phillips @ 2005-07-29 20:33 UTC (permalink / raw)
To: Vikas Aggarwal; +Cc: linuxppc-embedded
In-Reply-To: <32704.198.22.236.230.1122651627.squirrel@198.22.236.230>
On Fri, 29 Jul 2005 11:40:27 -0400 (EDT)
"Vikas Aggarwal" <va824363@albany.edu> wrote:
> Hi All,
> Will appreciate if someone can guide me how to debug this inside SEC
> (security co-processor) core.
>
> The linux driver is writing descriptor into the FETCH-Register(0x2048)
> for Random Number generation execution unit(RNG-EU). The request came
> through a test program from user space. The RNG generation request never
> seems to complete as my ISR is not invoked.
> I checked the CCPSR(Crypto Channel Pointer Status register = 0x2010) and
> it has value=0:7(0-31 : 32-63 bits). 7 means "channel_error". But its
> always there even before I write the RNG descriptor to Fetch-register.
a value of 7 in bits 56-63 (PAIR_PTR) can suggest processing has not begun.
can you verify you are writing the upper bits of the FR (i.e. 0x204c)?
Kim
^ permalink raw reply
* Re: [PATCH RFC]: PHY Abstraction Layer III
From: Jeff Garzik @ 2005-07-29 21:46 UTC (permalink / raw)
To: Andy Fleming; +Cc: netdev, Embedded PPC Linux list
In-Reply-To: <23F9076F-9FBB-43C8-83CD-F630E694203D@freescale.com>
Andy Fleming wrote:
> Here's the latest version of the patch, done against a cogito linux-2.6
> branch. It has a handful of small changes, which I hope will speed
> acceptance:
>
> * Interrupts are no longer requested at interrupt time
> * There is a function to print out PHY status
> * The PHY drivers' probe function now serves only to initialize driver
> state
> * A new config_init functor has been created to configure PHY state
> just after reset (so that the PHYs will be returned to a sane state if
> they don't start up that way)
> * Stephen Hemminger's patch to allow better module support in the
> drivers has been included
OK, DaveM and I are OK with merging this.
Send me a single One Big Patch which adds all the new files and such,
I'll give it a final review, and queue it for 2.6.14.
Jeff
^ permalink raw reply
* PPC440EP (405GPr) (2.4, 2.6) scatter/gather DMA - now works
From: Roger Larsson @ 2005-07-29 21:47 UTC (permalink / raw)
To: Matt Porter; +Cc: linux-ppc-embedded
We are actually still using the 2.4 tree with our own patches
to make SGDMA work.
Using a different approach...
1. We need more than one page of descriptors, so we allocate one
at a time. [Doing DMA transfers of hires images directly to user space]
2. Interrupt is handled in a simpler way:
If interrupts are enabled:
* always enable error
* always enable end of transfer interrupts
* only enable terminal count interrupt on last descriptor
Anyway we have ported our patch from using 405 GPr to 440 EP,
during that we run into one major roadblock, now solved.
[ppc4xx_dma.h]
504 #ifdef PPC4xx_DMA_64BIT
505 typedef struct {
506 uint32_t control;
507 uint32_t control_count;
508 phys_addr_t src_addr;
509 phys_addr_t dst_addr;
510 phys_addr_t next;
511 } ppc_sgl_t;
512 #else
513 typedef struct {
514 uint32_t control;
515 phys_addr_t src_addr;
516 phys_addr_t dst_addr;
517 uint32_t control_count;
518 uint32_t next;
519 } ppc_sgl_t;
520 #endif
440EP is a strange...
It has 36 bit address, four 64 bit DMA and four 32 bit DMA...
Since we do not, yet, use any 64 bit DMA we turned that off...
[mmu.h]
/*
* Define physical address type. Machines using split size
* virtual/physical addressing like 32-bit virtual / 36-bit
* physical need a larger than native word size type. -Matt
*/
#ifdef CONFIG_PTE_64BIT
typedef unsigned long long phys_addr_t;
extern phys_addr_t fixup_bigphys_addr(phys_addr_t, phys_addr_t);
#else
typedef unsigned long phys_addr_t;
#endif
Since phys_addr_t is 64 bits... the discriptor layout gets wrong...
In this case I think it is better to use uint32_t for those addresses.
What is worse is how to support BOTH 32 and 64 bits DMA at
the same time. Possibly ppc_sgl_t could be private for ppc4xx_sgdma?
Is there other processors in the ppc family that have both 64
and 32 bits DMA?
I have forgot to send our patch for several days now, but this
is the most important part. This message is also to make me
remember to prepare those patches!!!
/RogerL
^ permalink raw reply
* [PATCH] ppc32: fix 44x early serial debug for configurations with more than 512M of RAM
From: Eugene Surovegin @ 2005-07-29 23:02 UTC (permalink / raw)
To: Andrew Morton; +Cc: linuxppc-embedded
Fix 44x early serial debugging for big RAM configurations (more than
512M). We cannot use default OpenBIOS virtual mapping, because it
interferes with pinned TLB entry.
While we are at it, move early UART mapping to TLB slot 0, so it can
survive longer during boot process (slot 1 is used by the first
ioremap call, effectively killing UART mapping if it occupies this
slot). Also, change UART TLB entry size to 4K (256M is too much for a
bunch of registers :). Squash some warnings on the way.
Tested on Ebony and Ocotea with 1G of RAM.
Thanks to Scott Coulter <scott.coulter@cyclone.com> for diagnosing
this problem.
Signed-off-by: Eugene Surovegin <ebs@ebshome.net>
diff --git a/arch/ppc/kernel/head_44x.S b/arch/ppc/kernel/head_44x.S
--- a/arch/ppc/kernel/head_44x.S
+++ b/arch/ppc/kernel/head_44x.S
@@ -179,14 +179,14 @@ skpinv: addi r4,r4,1 /* Increment */
4:
#ifdef CONFIG_SERIAL_TEXT_DEBUG
/*
- * Add temporary UART mapping for early debug. This
- * mapping must be identical to that used by the early
- * bootloader code since the same asm/serial.h parameters
- * are used for polled operation.
+ * Add temporary UART mapping for early debug.
+ * We can map UART registers wherever we want as long as they don't
+ * interfere with other system mappings (e.g. with pinned entries).
+ * For an example of how we handle this - see ocotea.h. --ebs
*/
/* pageid fields */
lis r3,UART0_IO_BASE@h
- ori r3,r3,PPC44x_TLB_VALID | PPC44x_TLB_256M
+ ori r3,r3,PPC44x_TLB_VALID | PPC44x_TLB_4K
/* xlat fields */
lis r4,UART0_PHYS_IO_BASE@h /* RPN depends on SoC */
@@ -196,7 +196,7 @@ skpinv: addi r4,r4,1 /* Increment */
li r5,0
ori r5,r5,(PPC44x_TLB_SW | PPC44x_TLB_SR | PPC44x_TLB_I | PPC44x_TLB_G)
- li r0,1 /* TLB slot 1 */
+ li r0,0 /* TLB slot 0 */
tlbwe r3,r0,PPC44x_TLB_PAGEID /* Load the pageid fields */
tlbwe r4,r0,PPC44x_TLB_XLAT /* Load the translation fields */
diff --git a/arch/ppc/platforms/4xx/ebony.c b/arch/ppc/platforms/4xx/ebony.c
--- a/arch/ppc/platforms/4xx/ebony.c
+++ b/arch/ppc/platforms/4xx/ebony.c
@@ -7,7 +7,7 @@
* Copyright 2002-2005 MontaVista Software Inc.
*
* Eugene Surovegin <eugene.surovegin@zultys.com> or <ebs@ebshome.net>
- * Copyright (c) 2003, 2004 Zultys Technologies
+ * Copyright (c) 2003-2005 Zultys Technologies
*
* This program is free software; you can redistribute it and/or modify it
* under the terms of the GNU General Public License as published by the
@@ -50,6 +50,7 @@
#include <asm/bootinfo.h>
#include <asm/ppc4xx_pic.h>
#include <asm/ppcboot.h>
+#include <asm/tlbflush.h>
#include <syslib/gen550.h>
#include <syslib/ibm440gp_common.h>
@@ -248,6 +249,9 @@ ebony_early_serial_map(void)
#if defined(CONFIG_SERIAL_TEXT_DEBUG) || defined(CONFIG_KGDB)
/* Configure debug serial access */
gen550_init(0, &port);
+
+ /* Purge TLB entry added in head_44x.S for early serial access */
+ _tlbie(UART0_IO_BASE);
#endif
port.membase = ioremap64(PPC440GP_UART1_ADDR, 8);
diff --git a/arch/ppc/platforms/4xx/ebony.h b/arch/ppc/platforms/4xx/ebony.h
--- a/arch/ppc/platforms/4xx/ebony.h
+++ b/arch/ppc/platforms/4xx/ebony.h
@@ -56,9 +56,18 @@
* Serial port defines
*/
-/* OpenBIOS defined UART mappings, used before early_serial_setup */
+#if defined(__BOOTER__)
+/* OpenBIOS defined UART mappings, used by bootloader shim */
#define UART0_IO_BASE 0xE0000200
#define UART1_IO_BASE 0xE0000300
+#else
+/* head_44x.S created UART mapping, used before early_serial_setup.
+ * We cannot use default OpenBIOS UART mappings because they
+ * don't work for configurations with more than 512M RAM. --ebs
+ */
+#define UART0_IO_BASE 0xF0000200
+#define UART1_IO_BASE 0xF0000300
+#endif
/* external Epson SG-615P */
#define BASE_BAUD 691200
@@ -66,7 +75,7 @@
#define STD_UART_OP(num) \
{ 0, BASE_BAUD, 0, UART##num##_INT, \
(ASYNC_BOOT_AUTOCONF | ASYNC_SKIP_TEST), \
- iomem_base: UART##num##_IO_BASE, \
+ iomem_base: (void*)UART##num##_IO_BASE, \
io_type: SERIAL_IO_MEM},
#define SERIAL_PORT_DFNS \
diff --git a/arch/ppc/platforms/4xx/ocotea.c b/arch/ppc/platforms/4xx/ocotea.c
--- a/arch/ppc/platforms/4xx/ocotea.c
+++ b/arch/ppc/platforms/4xx/ocotea.c
@@ -48,6 +48,7 @@
#include <asm/bootinfo.h>
#include <asm/ppc4xx_pic.h>
#include <asm/ppcboot.h>
+#include <asm/tlbflush.h>
#include <syslib/gen550.h>
#include <syslib/ibm440gx_common.h>
@@ -266,6 +267,9 @@ ocotea_early_serial_map(void)
#if defined(CONFIG_SERIAL_TEXT_DEBUG) || defined(CONFIG_KGDB)
/* Configure debug serial access */
gen550_init(0, &port);
+
+ /* Purge TLB entry added in head_44x.S for early serial access */
+ _tlbie(UART0_IO_BASE);
#endif
port.membase = ioremap64(PPC440GX_UART1_ADDR, 8);
diff --git a/arch/ppc/platforms/4xx/ocotea.h b/arch/ppc/platforms/4xx/ocotea.h
--- a/arch/ppc/platforms/4xx/ocotea.h
+++ b/arch/ppc/platforms/4xx/ocotea.h
@@ -55,15 +55,24 @@
*/
#define RS_TABLE_SIZE 2
-/* OpenBIOS defined UART mappings, used before early_serial_setup */
+#if defined(__BOOTER__)
+/* OpenBIOS defined UART mappings, used by bootloader shim */
#define UART0_IO_BASE 0xE0000200
#define UART1_IO_BASE 0xE0000300
+#else
+/* head_44x.S created UART mapping, used before early_serial_setup.
+ * We cannot use default OpenBIOS UART mappings because they
+ * don't work for configurations with more than 512M RAM. --ebs
+ */
+#define UART0_IO_BASE 0xF0000200
+#define UART1_IO_BASE 0xF0000300
+#endif
#define BASE_BAUD 11059200/16
#define STD_UART_OP(num) \
{ 0, BASE_BAUD, 0, UART##num##_INT, \
(ASYNC_BOOT_AUTOCONF | ASYNC_SKIP_TEST), \
- iomem_base: UART##num##_IO_BASE, \
+ iomem_base: (void*)UART##num##_IO_BASE, \
io_type: SERIAL_IO_MEM},
#define SERIAL_PORT_DFNS \
^ permalink raw reply
* Serial console
From: Daniel Ann @ 2005-07-30 1:06 UTC (permalink / raw)
To: linuxppc-embedded
Hi folks,
Just wondering if anyone could lend a hand with this problem I have
with serial console. I'm trying to boot up my board (very similar to
sandpoint using MPC8245) with kernel 2.6.12.3, and most of it is
working but console will display up to,
[snip]
RAMDISK: Compressed image found at block 0
VFS: Mounted root (ext2 filesystem) readonly.
Freeing unused kernel memory: 112k init =
=20
I've done series of printk in sys_execve() to see if /sbin/init is
working, and found out it went thru the whole rcS file okay. Mind you,
printk is successfully displaying the output on the console while I'm
still not getting anything from the user processes.
Having all the kernel boot up log on console means that I've done some
part right. But why am I not getting anything from the user processes
on the console screen ?
Is there anything I need to do on the kernel config ?
--=20
Daniel
^ permalink raw reply
* Re: Serial console
From: Josh Boyer @ 2005-07-30 1:19 UTC (permalink / raw)
To: Daniel Ann; +Cc: linuxppc-embedded
In-Reply-To: <9b7ca65705072918062249e41f@mail.gmail.com>
On Sat, 2005-07-30 at 10:06 +0900, Daniel Ann wrote:
> Hi folks,
>
> Just wondering if anyone could lend a hand with this problem I have
> with serial console. I'm trying to boot up my board (very similar to
> sandpoint using MPC8245) with kernel 2.6.12.3, and most of it is
> working but console will display up to,
> [snip]
> RAMDISK: Compressed image found at block 0
> VFS: Mounted root (ext2 filesystem) readonly.
> Freeing unused kernel memory: 112k init
>
> I've done series of printk in sys_execve() to see if /sbin/init is
> working, and found out it went thru the whole rcS file okay. Mind you,
> printk is successfully displaying the output on the console while I'm
> still not getting anything from the user processes.
>
> Having all the kernel boot up log on console means that I've done some
> part right. But why am I not getting anything from the user processes
> on the console screen ?
>
> Is there anything I need to do on the kernel config ?
Do you have a /dev/console device node in your initrd? If not, that is
one of the reasons you could be seeing that problem. Make
sure /dev/null is there too.
josh
^ permalink raw reply
* Re: Serial console
From: Ricardo Scop @ 2005-07-30 1:27 UTC (permalink / raw)
To: Daniel Ann, linuxppc-embedded
In-Reply-To: <9b7ca65705072918062249e41f@mail.gmail.com>
Hi Daniel,
On Friday 29 July 2005 22:06, Daniel Ann wrote:
> Hi folks,
>
> Just wondering if anyone could lend a hand with this problem I have
> with serial console. I'm trying to boot up my board (very similar to
> sandpoint using MPC8245) with kernel 2.6.12.3, and most of it is
> working but console will display up to,
> [snip]
> RAMDISK: Compressed image found at block 0
> VFS: Mounted root (ext2 filesystem) readonly.
> Freeing unused kernel memory: 112k init
>
> I've done series of printk in sys_execve() to see if /sbin/init is
> working, and found out it went thru the whole rcS file okay. Mind you,
> printk is successfully displaying the output on the console while I'm
> still not getting anything from the user processes.
>
> Having all the kernel boot up log on console means that I've done some
> part right. But why am I not getting anything from the user processes
> on the console screen ?
>
Please verify that you have a /dev/console in your rootfs, and that it's =
being=20
correctly acessed by the init process.
HTH,
--=20
Ricardo Scop.
\|/
___ -*-
(@ @)/|\
/ V \| R SCOP Consult.
/( )\ Linux-based communications
--^^---^^+------------------------------
rscop@matrix.com.br
+55 51 999-36-777
Porto Alegre, RS - BRazil
^ permalink raw reply
* Re: Serial console
From: Daniel Ann @ 2005-07-30 1:34 UTC (permalink / raw)
To: Ricardo Scop; +Cc: linuxppc-embedded
In-Reply-To: <200507292227.45626.scop@digitel.com.br>
Looks like I have /dev/console
0 crw------- 1 root root 5, 1 Sep 26 2002 console
0 crw-rw-rw- 1 root root 4, 64 Jun 17 2004 ttyS0
I havent yet figured out how I should go about seeing if init is
correctly accessing it tho. Let me take a look at busybox init part.
BTW, any more reasons why this problem might exist ?
On 7/30/05, Ricardo Scop <scop@digitel.com.br> wrote:
> Hi Daniel,
>=20
> On Friday 29 July 2005 22:06, Daniel Ann wrote:
> > Hi folks,
> >
> > Just wondering if anyone could lend a hand with this problem I have
> > with serial console. I'm trying to boot up my board (very similar to
> > sandpoint using MPC8245) with kernel 2.6.12.3, and most of it is
> > working but console will display up to,
> > [snip]
> > RAMDISK: Compressed image found at block 0
> > VFS: Mounted root (ext2 filesystem) readonly.
> > Freeing unused kernel memory: 112k init
> >
> > I've done series of printk in sys_execve() to see if /sbin/init is
> > working, and found out it went thru the whole rcS file okay. Mind you,
> > printk is successfully displaying the output on the console while I'm
> > still not getting anything from the user processes.
> >
> > Having all the kernel boot up log on console means that I've done some
> > part right. But why am I not getting anything from the user processes
> > on the console screen ?
> >
> Please verify that you have a /dev/console in your rootfs, and that it's =
being
> correctly acessed by the init process.
>=20
> HTH,
>=20
> --
> Ricardo Scop.
>=20
> \|/
> ___ -*-
> (@ @)/|\
> / V \| R SCOP Consult.
> /( )\ Linux-based communications
> --^^---^^+------------------------------
> rscop@matrix.com.br
> +55 51 999-36-777
> Porto Alegre, RS - BRazil
>=20
>=20
--=20
Daniel
^ permalink raw reply
* Re: Serial console
From: Daniel Ann @ 2005-07-30 1:36 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-embedded
In-Reply-To: <1122686376.4755.2.camel@yoda.jdub.homelinux.org>
I too have /dev/null
0 crw-rw-rw- 1 root root 1, 3 Aug 31 2001 null
However, Im not using initrd. null, and console devices are in my RAMDISK t=
ho.
On 7/30/05, Josh Boyer <jwboyer@jdub.homelinux.org> wrote:
> On Sat, 2005-07-30 at 10:06 +0900, Daniel Ann wrote:
> > Hi folks,
> >
> > Just wondering if anyone could lend a hand with this problem I have
> > with serial console. I'm trying to boot up my board (very similar to
> > sandpoint using MPC8245) with kernel 2.6.12.3, and most of it is
> > working but console will display up to,
> > [snip]
> > RAMDISK: Compressed image found at block 0
> > VFS: Mounted root (ext2 filesystem) readonly.
> > Freeing unused kernel memory: 112k init
> >
> > I've done series of printk in sys_execve() to see if /sbin/init is
> > working, and found out it went thru the whole rcS file okay. Mind you,
> > printk is successfully displaying the output on the console while I'm
> > still not getting anything from the user processes.
> >
> > Having all the kernel boot up log on console means that I've done some
> > part right. But why am I not getting anything from the user processes
> > on the console screen ?
> >
> > Is there anything I need to do on the kernel config ?
>=20
> Do you have a /dev/console device node in your initrd? If not, that is
> one of the reasons you could be seeing that problem. Make
> sure /dev/null is there too.
>=20
> josh
>=20
>=20
--=20
Daniel
^ permalink raw reply
* Re: mpc8248 SEC -- interrupt handler not invoked
From: Vikas Aggarwal @ 2005-07-30 3:39 UTC (permalink / raw)
To: Kim Phillips; +Cc: linuxppc-embedded
In-Reply-To: <20050729153323.3f2c62ad.kim.phillips@freescale.com>
Hi Kim,
Thanks for helping out.
Yes i verified , i am writing to upper bits of FR.
Now my ISR does get invoked and InterruptStatus(0x1010) has 4 in upper
bits. That means TEA (Transfer Error Acknowledge). Next thing i did is i
dumped the lower bits of master-error-address-register MEAR(0x1038) and
it has 0x011af4d0. As per definition of this register my data phase was
terminated . Was it due to bad address being written into FR.
I am using virt_to_phys() to convert the DPD's address and then writing
this into FR.
Also u may be thinking what did i change that ISR gets invoked now.
Earlier i was using __vpa instead of virt_to_phys(). __vpa came from the
original SEC driver(for mpc8555 and kernel 2.4) which i downloaded from
freescale. After i replaced __vpa with kernel's virt_to_phys() gets
invoked.
#define __vpa(va) ((pte_val(*(unsigned long
*)pte_offset_kernel(pmd_offset(pgd_offset_k(va), (va)), (va))) &
PAGE_MASK) + (va & ~PAGE_MASK))
But i still think that may be virt_to_phys() is not doing what FR expects.
Thanks for your patience with detailed mail.
Please help
-vikas aggarwal
> On Fri, 29 Jul 2005 11:40:27 -0400 (EDT)
> "Vikas Aggarwal" <va824363@albany.edu> wrote:
>
>> Hi All,
>> Will appreciate if someone can guide me how to debug this inside SEC
>> (security co-processor) core.
>>
>> The linux driver is writing descriptor into the FETCH-Register(0x2048)
>> for Random Number generation execution unit(RNG-EU). The request came
>> through a test program from user space. The RNG generation request never
>> seems to complete as my ISR is not invoked.
>> I checked the CCPSR(Crypto Channel Pointer Status register = 0x2010)
>> and
>> it has value=0:7(0-31 : 32-63 bits). 7 means "channel_error". But its
>> always there even before I write the RNG descriptor to Fetch-register.
>
> a value of 7 in bits 56-63 (PAIR_PTR) can suggest processing has not
> begun.
>
> can you verify you are writing the upper bits of the FR (i.e. 0x204c)?
>
> Kim
>
^ permalink raw reply
* Re: Serial console
From: Daniel Ann @ 2005-07-30 5:46 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <9b7ca6570507291836ac62600@mail.gmail.com>
I've got a feeling that this has alot to do with IRQ.
Would I be correct to assume printk doesnt require interrupt to work
but printf does ?
After doing some testing, I've found my network interface ping-able
when I got printf working in 2.4.31. But if I alter the openpic source
to not initialize the interrupt, it also stop displaying at the same
point and network interface isnt pingable.
I guess my next problem would be then, why isnt my openpic working. :(
I've done exactly the same as what I did with 2.4.31 and that works.
Hmmm. Something must have changed in 2.6.12.3.
I dont think this is has anything to do with serial console, so I'm
gonna end the thread here.
Thanks.
On 7/30/05, Daniel Ann <ktdann@gmail.com> wrote:
> I too have /dev/null
> 0 crw-rw-rw- 1 root root 1, 3 Aug 31 2001 null
>=20
> However, Im not using initrd. null, and console devices are in my RAMDISK=
tho.
>=20
> On 7/30/05, Josh Boyer <jwboyer@jdub.homelinux.org> wrote:
> > On Sat, 2005-07-30 at 10:06 +0900, Daniel Ann wrote:
> > > Hi folks,
> > >
> > > Just wondering if anyone could lend a hand with this problem I have
> > > with serial console. I'm trying to boot up my board (very similar to
> > > sandpoint using MPC8245) with kernel 2.6.12.3, and most of it is
> > > working but console will display up to,
> > > [snip]
> > > RAMDISK: Compressed image found at block 0
> > > VFS: Mounted root (ext2 filesystem) readonly.
> > > Freeing unused kernel memory: 112k init
> > >
> > > I've done series of printk in sys_execve() to see if /sbin/init is
> > > working, and found out it went thru the whole rcS file okay. Mind you=
,
> > > printk is successfully displaying the output on the console while I'm
> > > still not getting anything from the user processes.
> > >
> > > Having all the kernel boot up log on console means that I've done som=
e
> > > part right. But why am I not getting anything from the user processes
> > > on the console screen ?
> > >
> > > Is there anything I need to do on the kernel config ?
> >
> > Do you have a /dev/console device node in your initrd? If not, that is
> > one of the reasons you could be seeing that problem. Make
> > sure /dev/null is there too.
> >
> > josh
> >
> >
>=20
>=20
> --
> Daniel
>=20
--=20
Daniel
^ permalink raw reply
* Re: Serial console
From: Anton Wöllert @ 2005-07-30 10:37 UTC (permalink / raw)
To: Daniel Ann, linuxppc-embedded
In-Reply-To: <9b7ca65705072918062249e41f@mail.gmail.com>
Daniel Ann wrote:
> Hi folks,
>
> Having all the kernel boot up log on console means that I've done some
> part right. But why am I not getting anything from the user processes
> on the console screen ?
>
> Is there anything I need to do on the kernel config ?
>
Hi, we've had the same problem some time ago on a tqm850l (mpc850). Our
problem was, that we had registered two serial consoles in the kernel
config or something like that. we had to disable all serial-driver stuff
and enable just the platform-specific serial-console driver. we tracked
this down with inserting a printk(buf) into the tty_write fs-op of the
serial-port driver in drivers/char/tty_io.c. the ttyS0 was used but has
taken another serial-driver than the platform specific.
may this help you :)
anton
^ permalink raw reply
* Re: cpufreq on powerbook lombard
From: Benjamin Herrenschmidt @ 2005-07-30 16:16 UTC (permalink / raw)
To: Sergey Kolosov; +Cc: linuxppc-dev
In-Reply-To: <d39e2e70507261510edd0e8@mail.gmail.com>
On Wed, 2005-07-27 at 02:10 +0400, Sergey Kolosov wrote:
> How i can enabled cpufreq on my powerbook lombard? In kernel(2.6.11) source:
>
> file /usr/src/kernel-source-2.6.11/arch/ppc/platforms/pmac_cpufreq.c
>
> <...>
> /* Currently, we support the following machines:
> *
> * - Titanium PowerBook 1Ghz (PMU based, 667Mhz & 1Ghz)
> * - Titanium PowerBook 800 (PMU based, 667Mhz & 800Mhz)
> * - Titanium PowerBook 400 (PMU based, 300Mhz & 400Mhz)
> * - Titanium PowerBook 500 (PMU based, 300Mhz & 500Mhz)
> * - iBook2 500/600 (PMU based, 400Mhz & 500/600Mhz)
> * - iBook2 700 (CPU based, 400Mhz & 700Mhz, support low voltage)
> * - Recent MacRISC3 laptops
> * - iBook G4s and PowerBook G4s with 7447A CPUs
> */
> static int __init pmac_cpufreq_setup(void)
> <...>
>
> But can be there is a way for addition of support cpufreq for
> powerbook lombard ?
Note sure the PMU supports it...
Ben.
^ permalink raw reply
* Re: preliminary 750GX PLL control patch
From: Benjamin Herrenschmidt @ 2005-07-30 16:18 UTC (permalink / raw)
To: Kevin Diggs; +Cc: linuxppc-dev
In-Reply-To: <42E672B1.7050709@hypersurf.com>
On Tue, 2005-07-26 at 10:28 -0700, Kevin Diggs wrote:
> Hi,
>
> I've attached a patch that adds preliminary access to the HID1
> register in the 750GX (aka the PLL config register). The patch is
> against 2.4.30. It has been lightly tested on a PowerMac 8600 with a
> PowerLogix PowerForce 750GX cpu card.
>
> Depending on the values for the pllx_cfg field, this should
> work on the 750FX as well ... except for the stuff in idle_6xx.S. Since
> there are plenty of people on this list way more smarterer than me I was
> hoping someone could answer a question about the powersave modes that
> some of the PowerPC processors have:
>
> Since, as I understand it, the clock is shut off to much of the
> chip when a powersave mode is engaged does it really buy you that much
> to switch to a lower clock speed? Wouldn't you be better off shutting
> off the unused PLL?
>
> Also, please note that I am not very experienced creating
> patches so please use a backup of your source tree.
Well... I replicated what darwin does here. I don't remember completely
but it's possible that there is some kind of CPU errata related to nap
and clock speed... or maybe it still makes a difference :)
You want to wakeup fast from nap too, so switching off/on the unused PLL
might not be that a good idea. But heh, you are welcome to try &
measure.
Ben.
^ permalink raw reply
* [PATCH] PPC440EP (405GPr) 2.4.20 (2.6) scatter/gather DMA
From: Roger Larsson @ 2005-07-30 16:46 UTC (permalink / raw)
To: Matt Porter; +Cc: linux-ppc-embedded
This patch has been tested on PPC440EP,
an earlier, almost identical, version was used on 405GPr
(on a later Linux release).
Both should work.
I now see that some of these changes maybe should not be
done... (removal of inline, export of ppc4xx_set_sg_addr)
/RogerL
--- linux-2.4.20_mvl31_AR2/arch/ppc/kernel/ppc4xx_sgdma.c.org 2005-07-01
13:10:27.000000000 +0200
+++ linux-2.4.20_mvl31_AR2/arch/ppc/kernel/ppc4xx_sgdma.c 2005-07-12
11:11:16.000000000 +0200
@@ -4,11 +4,17 @@
* IBM PPC4xx DMA engine scatter/gather library
*
* Copyright 2002-2003 MontaVista Software Inc.
+ * Copyright 2005 Optronic dp AB
*
* Cleaned by Matt Porter <mporter@mvista.com>
*
* Original code by Armin Kuster <akuster@mvista.com>
* and Pete Popov <ppopov@mvista.com>
+ *
+ * Use of kmalloc, good for short and very long lists
+ * End of Transfer termination and residue
+ * Roger Larsson <roger.larsson@optronic.se> and
+ * Ronnie Hedlund, DataDuctus AB
*
* This program is free software; you can redistribute it and/or modify it
* under the terms of the GNU General Public License as published by the
@@ -19,7 +25,7 @@
* with this program; if not, write to the Free Software Foundation, Inc.,
* 675 Mass Ave, Cambridge, MA 02139, USA.
*/
-
+
#include <linux/config.h>
#include <linux/kernel.h>
#include <linux/mm.h>
@@ -31,7 +37,7 @@
#include <asm/io.h>
#include <asm/ppc4xx_dma.h>
-static __inline__ void
+void
ppc4xx_set_sg_addr(int dmanr, phys_addr_t sg_addr)
{
switch (dmanr) {
@@ -73,7 +79,7 @@
* memory to peripheral: set dst_addr to NULL,
* peripheral to memory: set src_addr to NULL.
*/
-static __inline__ int
+int
ppc4xx_add_dma_sgl(sgl_handle_t handle, phys_addr_t src_addr, phys_addr_t
dst_addr,
unsigned int count)
{
@@ -125,18 +131,19 @@
}
#endif
- if ((unsigned) (psgl->ptail + 1) >= ((unsigned) psgl + SGL_LIST_SIZE)) {
- printk("sgl handle out of memory \n");
- return DMA_STATUS_OUT_OF_MEMORY;
- }
-
- if (!psgl->ptail) {
- psgl->phead = (ppc_sgl_t *)
- ((unsigned) psgl + sizeof (sgl_list_info_t));
- psgl->ptail = psgl->phead;
- } else {
- psgl->ptail->next = virt_to_bus(psgl->ptail + 1);
- psgl->ptail++;
+ /* dynamic alloc each list element */
+ {
+ ppc_sgl_t *sgl_el = kmalloc(sizeof(ppc_sgl_t), GFP_KERNEL|GFP_DMA);
+ if (!sgl_el)
+ return DMA_STATUS_OUT_OF_MEMORY;
+
+ if (!psgl->phead) { /* list was empty */
+ psgl->phead = sgl_el;
+ } else { /* not empty, tail exists */
+ psgl->ptail->next = virt_to_phys(sgl_el);
+ dma_cache_wback((unsigned long)psgl->ptail, sizeof(ppc_sgl_t));
+ }
+ psgl->ptail = sgl_el;
}
psgl->ptail->control = psgl->control;
@@ -144,7 +151,8 @@
psgl->ptail->dst_addr = dst_addr;
psgl->ptail->control_count = (count >> p_dma_ch->shift) |
psgl->sgl_control;
- psgl->ptail->next = (uint32_t) NULL;
+ psgl->ptail->next = virt_to_phys(NULL);
+ dma_cache_wback((unsigned long)psgl->ptail, sizeof(ppc_sgl_t)); /* handled
later, skip this one? */
return DMA_STATUS_GOOD;
}
@@ -152,7 +160,8 @@
/*
* Enable (start) the DMA described by the sgl handle.
*/
-static __inline__ void
+
+void
ppc4xx_enable_dma_sgl(sgl_handle_t handle)
{
sgl_list_info_t *psgl = (sgl_list_info_t *) handle;
@@ -173,9 +182,18 @@
p_dma_ch = &dma_channels[psgl->dmanr];
psgl->ptail->control_count &= ~SG_LINK; /* make this the last dscrptr */
+ if (p_dma_ch->int_enable)
+ {
+ /* Require Terminal Count interrupt on last */
+ psgl->ptail->control_count |= SG_TCI_ENABLE;
+ }
+
+ /* No more changes to tail object allowed */
+ dma_cache_wback((unsigned long)psgl->ptail, sizeof(ppc_sgl_t));
+
sg_command = mfdcr(DCRN_ASGC);
- ppc4xx_set_sg_addr(psgl->dmanr, virt_to_bus(psgl->phead));
+ ppc4xx_set_sg_addr(psgl->dmanr, virt_to_phys(psgl->phead));
switch (psgl->dmanr) {
case 0:
@@ -193,37 +211,14 @@
default:
printk("ppc4xx_enable_dma_sgl: bad channel: %d\n", psgl->dmanr);
}
-
-#if 0 /* debug */
- printk("\n\nppc4xx_enable_dma_sgl at dma_addr 0x%x\n",
- virt_to_bus(psgl->phead));
- {
- ppc_sgl_t *pnext, *sgl_addr;
-
- pnext = psgl->phead;
- while (pnext) {
- printk("dma descriptor at 0x%x, dma addr 0x%x\n",
- (unsigned) pnext, (unsigned) virt_to_bus(pnext));
- printk
- ("control 0x%x src 0x%x dst 0x%x c_count 0x%x, next 0x%x\n",
- (unsigned) pnext->control,
- (unsigned) pnext->src_addr,
- (unsigned) pnext->dst_addr,
- (unsigned) pnext->control_count,
- (unsigned) pnext->next);
-
- (unsigned) pnext = bus_to_virt(pnext->next);
- }
- printk("sg_command 0x%x\n", sg_command);
- }
-#endif
+
mtdcr(DCRN_ASGC, sg_command); /* start transfer */
}
/*
* Halt an active scatter/gather DMA operation.
*/
-static __inline__ void
+void
ppc4xx_disable_dma_sgl(sgl_handle_t handle)
{
sgl_list_info_t *psgl = (sgl_list_info_t *) handle;
@@ -265,8 +260,10 @@
* the sgl descriptor where the DMA stopped.
*
* An sgl transfer must NOT be active when this function is called.
+ * Note: Make sure ppc4xx_disable_dma_sgl was called before returning from
+ * interrupt handler (TSn, CSn will not disable the sgl)!
*/
-static __inline__ int
+int
ppc4xx_get_dma_sgl_residue(sgl_handle_t handle, phys_addr_t * src_addr,
phys_addr_t * dst_addr)
{
@@ -286,19 +283,19 @@
switch (psgl->dmanr) {
case 0:
- sgl_addr = (ppc_sgl_t *) bus_to_virt(mfdcr(DCRN_ASG0));
+ sgl_addr = (ppc_sgl_t *) phys_to_virt(mfdcr(DCRN_ASG0));
count_left = mfdcr(DCRN_DMACT0);
break;
case 1:
- sgl_addr = (ppc_sgl_t *) bus_to_virt(mfdcr(DCRN_ASG1));
+ sgl_addr = (ppc_sgl_t *) phys_to_virt(mfdcr(DCRN_ASG1));
count_left = mfdcr(DCRN_DMACT1);
break;
case 2:
- sgl_addr = (ppc_sgl_t *) bus_to_virt(mfdcr(DCRN_ASG2));
+ sgl_addr = (ppc_sgl_t *) phys_to_virt(mfdcr(DCRN_ASG2));
count_left = mfdcr(DCRN_DMACT2);
break;
case 3:
- sgl_addr = (ppc_sgl_t *) bus_to_virt(mfdcr(DCRN_ASG3));
+ sgl_addr = (ppc_sgl_t *) phys_to_virt(mfdcr(DCRN_ASG3));
count_left = mfdcr(DCRN_DMACT3);
break;
default:
@@ -307,54 +304,34 @@
}
if (!sgl_addr) {
- printk("ppc4xx_get_dma_sgl_residue: sgl addr register is null\n");
- goto error;
+ /* Last in list */
+ return count_left;
}
- pnext = psgl->phead;
- while (pnext &&
- ((unsigned) pnext < ((unsigned) psgl + SGL_LIST_SIZE) &&
- (pnext != sgl_addr))
- ) {
- pnext++;
- }
-
- if (pnext == sgl_addr) { /* found the sgl descriptor */
-
- *src_addr = pnext->src_addr;
- *dst_addr = pnext->dst_addr;
-
- /*
- * Now search the remaining descriptors and add their count.
- * We already have the remaining count from this descriptor in
- * count_left.
- */
- pnext++;
-
- while ((pnext != psgl->ptail) &&
- ((unsigned) pnext < ((unsigned) psgl + SGL_LIST_SIZE))
- ) {
- count_left += pnext->control_count & SG_COUNT_MASK;
- }
+ pnext = sgl_addr; /* sgl_addr is next to be loaded */
- if (pnext != psgl->ptail) { /* should never happen */
- printk
- ("ppc4xx_get_dma_sgl_residue error (1) psgl->ptail 0x%x handle
0x%x\n",
- (unsigned int) psgl->ptail, (unsigned int) handle);
- goto error;
- }
+ /*
+ * Why this strange interface? return nothing or sgl_addr instead...
+ * (please check for null pointers)
+ */
+ *src_addr = pnext->src_addr;
+ *dst_addr = pnext->dst_addr;
- /* success */
- p_dma_ch = &dma_channels[psgl->dmanr];
- return (count_left << p_dma_ch->shift); /* count in bytes */
+ /*
+ * Now search the remaining descriptors and add their count.
+ * We already have the remaining count from this descriptor in
+ * count_left.
+ */
+
+ while (pnext) {
+ count_left += pnext->control_count & SG_COUNT_MASK;
+ pnext = phys_to_virt(pnext->next);
+ }
- } else {
- /* this shouldn't happen */
- printk
- ("get_dma_sgl_residue, unable to match current address 0x%x, handle
0x%x\n",
- (unsigned int) sgl_addr, (unsigned int) handle);
- }
+ /* success */
+ p_dma_ch = &dma_channels[psgl->dmanr];
+ return (count_left << p_dma_ch->shift); /* count in bytes */
error:
*src_addr = (phys_addr_t) NULL;
@@ -369,7 +346,7 @@
*
* This function should only be called when the DMA is not active.
*/
-static __inline__ int
+int
ppc4xx_delete_dma_sgl_element(sgl_handle_t handle, phys_addr_t *
src_dma_addr,
phys_addr_t * dst_dma_addr)
{
@@ -385,7 +362,7 @@
}
if (!psgl->phead) {
- printk("ppc4xx_delete_sgl_element: sgl list empty\n");
+ /* printk("ppc4xx_delete_sgl_element: sgl list empty\n"); - not an error */
*src_dma_addr = (phys_addr_t) NULL;
*dst_dma_addr = (phys_addr_t) NULL;
return DMA_STATUS_SGL_LIST_EMPTY;
@@ -396,10 +373,13 @@
if (psgl->phead == psgl->ptail) {
/* last descriptor on the list */
+ kfree(psgl->phead);
psgl->phead = NULL;
psgl->ptail = NULL;
} else {
- psgl->phead++;
+ ppc_sgl_t *next = phys_to_virt(psgl->phead->next);
+ kfree(psgl->phead);
+ psgl->phead = next;
}
return DMA_STATUS_GOOD;
@@ -411,12 +391,7 @@
* describes a scatter/gather list.
*
* A handle is returned in "handle" which the driver should save in order
to
- * be able to access this list later. A chunk of memory will be allocated
- * to be used by the API for internal management purposes, including
managing
- * the sg list and allocating memory for the sgl descriptors. One page
should
- * be more than enough for that purpose. Perhaps it's a bit wasteful to
use
- * a whole page for a single sg list, but most likely there will be only
one
- * sg list per channel.
+ * be able to access this list later.
*
* Interrupt notes:
* Each sgl descriptor has a copy of the DMA control word which the DMA
engine
@@ -433,15 +408,15 @@
* however, only the last descriptor will be setup to interrupt. Thus, an
* interrupt will occur (if interrupts are enabled) only after the complete
* sgl transfer is done.
+ * End of Transfer Interrupt needs to be enabled in all descriptors, since
it
+ * is impossible to know which one will be the last...
*/
int
ppc4xx_alloc_dma_handle(sgl_handle_t * phandle, unsigned int mode, unsigned
int dmanr)
{
- sgl_list_info_t *psgl;
- dma_addr_t dma_addr;
+ sgl_list_info_t *psgl = NULL;
ppc_dma_ch_t *p_dma_ch = &dma_channels[dmanr];
uint32_t sg_command;
- void *ret;
if (dmanr >= MAX_PPC4xx_DMA_CHANNELS) {
printk("ppc4xx_alloc_dma_handle: invalid channel 0x%x\n", dmanr);
@@ -453,19 +428,15 @@
return DMA_STATUS_NULL_POINTER;
}
- /* Get a page of memory, which is zeroed out by consistent_alloc() */
- ret = consistent_alloc(GFP_KERNEL, DMA_PPC4xx_SIZE, &dma_addr);
- if (ret != NULL) {
- memset(ret, 0, DMA_PPC4xx_SIZE);
- psgl = (sgl_list_info_t *) ret;
- }
-
+ /* Get memory for the listinfo struct */
+ psgl = kmalloc(sizeof(sgl_list_info_t), GFP_KERNEL);
if (psgl == NULL) {
*phandle = (sgl_handle_t) NULL;
return DMA_STATUS_OUT_OF_MEMORY;
}
-
- psgl->dma_addr = dma_addr;
+ memset(psgl, 0, sizeof(sgl_list_info_t));
+
+ /* dma_addr is unused now */
psgl->dmanr = dmanr;
/*
@@ -479,7 +450,9 @@
psgl->control &= ~(DMA_TM_MASK | DMA_TD);
/* Save control word and mode */
psgl->control |= (mode | DMA_CE_ENABLE);
-
+ /* PPC Errata? DMA else ignore count on first in list */
+ psgl->control |= SET_DMA_TCE(1);
+
/* In MM mode, we must set ETD/TCE */
if (mode == DMA_MODE_MM)
psgl->control |= DMA_ETD_OUTPUT | DMA_TCE_ENABLE;
@@ -514,13 +487,15 @@
/* Enable SGL control access */
mtdcr(DCRN_ASGC, sg_command);
- psgl->sgl_control = SG_ERI_ENABLE | SG_LINK;
+ psgl->sgl_control = SG_LINK;
if (p_dma_ch->int_enable) {
if (p_dma_ch->tce_enable)
+ {
+ /* reuse as Terminal Count Interrupt Enable on all descr. */
psgl->sgl_control |= SG_TCI_ENABLE;
- else
- psgl->sgl_control |= SG_ETI_ENABLE;
+ }
+ psgl->sgl_control |= SG_ERI_ENABLE | SG_ETI_ENABLE;
}
*phandle = (sgl_handle_t) psgl;
@@ -539,19 +514,19 @@
if (!handle) {
printk("ppc4xx_free_dma_handle: got NULL\n");
return;
- } else if (psgl->phead) {
- printk("ppc4xx_free_dma_handle: list not empty\n");
- return;
- } else if (!psgl->dma_addr) { /* should never happen */
- printk("ppc4xx_free_dma_handle: no dma address\n");
- return;
+ } else if (psgl->phead) { /* free list here, why do it externaly? */
+ phys_addr_t dummy;
+ while (ppc4xx_delete_dma_sgl_element(handle, &dummy, &dummy) ==
DMA_STATUS_GOOD)
+ /* NOOP */;
+ /* printk("ppc4xx_free_dma_handle: list not empty\n"); */
}
- consistent_free((void *) psgl);
+ kfree((void *) psgl);
}
EXPORT_SYMBOL(ppc4xx_alloc_dma_handle);
EXPORT_SYMBOL(ppc4xx_free_dma_handle);
+EXPORT_SYMBOL(ppc4xx_set_sg_addr);
EXPORT_SYMBOL(ppc4xx_add_dma_sgl);
EXPORT_SYMBOL(ppc4xx_delete_dma_sgl_element);
EXPORT_SYMBOL(ppc4xx_enable_dma_sgl);
--- linux-2.4.20_mvl31_AR2/include/asm-ppc/ppc4xx_dma.h.org 2005-07-12
14:08:18.000000000 +0200
+++ linux-2.4.20_mvl31_AR2/include/asm-ppc/ppc4xx_dma.h 2005-07-27
13:09:39.000000000 +0200
@@ -67,7 +67,7 @@
* DMA Channel Control Registers
*/
-#ifdef CONFIG_44x
+#if defined(CONFIG_44x) && !defined(CONFIG_440EP)
#define PPC4xx_DMA_64BIT
#define DMA_CR_OFFSET 1
#else
@@ -183,9 +183,6 @@
#ifdef CONFIG_PPC4xx_EDMA
-#define SGL_LIST_SIZE 4096
-#define DMA_PPC4xx_SIZE SGL_LIST_SIZE
-
#define SET_DMA_PRIORITY(x) (((x)&0x3)<<(6-DMA_CR_OFFSET)) /* DMA Channel
Priority */
#define DMA_PRIORITY_MASK SET_DMA_PRIORITY(3)
#define PRIORITY_LOW 0
@@ -531,8 +528,8 @@
#else
typedef struct {
uint32_t control;
- phys_addr_t src_addr;
- phys_addr_t dst_addr;
+ uint32_t src_addr;
+ uint32_t dst_addr;
uint32_t control_count;
uint32_t next;
} ppc_sgl_t;
@@ -567,6 +564,12 @@
extern unsigned int ppc4xx_get_peripheral_width(unsigned int);
extern int ppc4xx_alloc_dma_handle(sgl_handle_t *, unsigned int, unsigned
int);
extern void ppc4xx_free_dma_handle(sgl_handle_t);
+extern void ppc4xx_set_sg_addr(int dmanr, phys_addr_t sg_addr);
+extern int ppc4xx_add_dma_sgl(sgl_handle_t handle, phys_addr_t src_addr,
phys_addr_t dst_addr, unsigned int count);
+extern void ppc4xx_enable_dma_sgl(sgl_handle_t handle);
+extern void ppc4xx_disable_dma_sgl(sgl_handle_t handle);
+extern int ppc4xx_get_dma_sgl_residue(sgl_handle_t handle, phys_addr_t *
src_addr, phys_addr_t * dst_addr);
+extern int ppc4xx_delete_dma_sgl_element(sgl_handle_t handle, phys_addr_t *
src_dma_addr, phys_addr_t * dst_dma_addr);
extern int ppc4xx_get_dma_status(void);
extern void ppc4xx_set_src_addr(int dmanr, phys_addr_t src_addr);
extern void ppc4xx_set_dst_addr(int dmanr, phys_addr_t dst_addr);
^ permalink raw reply
* Re: mpc8248 SEC -- interrupt handler not invoked
From: Kim Phillips @ 2005-07-30 23:32 UTC (permalink / raw)
To: Vikas Aggarwal; +Cc: linuxppc-embedded
In-Reply-To: <32798.24.92.61.26.1122694772.squirrel@24.92.61.26>
On Fri, 29 Jul 2005 23:39:32 -0400 (EDT)
"Vikas Aggarwal" <va824363@albany.edu> wrote:
>
> But i still think that may be virt_to_phys() is not doing what FR expects.
>
try dma_map_single(). See drivers/net/gianfar.c
Kim
^ permalink raw reply
* Re: [PATCH 00/14] ppc32: Remove board ports that are no longer maintained
From: Kumar Gala @ 2005-07-31 16:39 UTC (permalink / raw)
To: Andrew Morton
Cc: linux-kernel list, Gala Kumar K.-galak,
linuxppc-embedded Linux list
In-Reply-To: <20050727125746.54329281.akpm@osdl.org>
Andrew,
Can you drop the ep405 removal patch. We've got someone to take
ownership.
- kumar
On Jul 27, 2005, at 2:57 PM, Andrew Morton wrote:
> Kumar Gala <galak@freescale.com> wrote:
>
>>
>> The following board ports are no longer maintained or have become
>> obsolete:
>>
>> adir
>> ash
>> beech
>> cedar
>> ep405
>> k2
>> mcpn765
>> menf1
>> oak
>> pcore
>> rainier
>> redwood
>> sm850
>> spd823ts
>>
>> We are there for removing support for them.
>>
>
> I'll merge all these into -mm for now, but will hold off sending
> any of
> them upstream pending confirmation of which patches we really want to
> proceed with.
>
^ permalink raw reply
* Re: mpc8248 SEC -- interrupt handler "is" invoked
From: Vikas Aggarwal @ 2005-08-01 0:48 UTC (permalink / raw)
To: Kim Phillips; +Cc: linuxppc-embedded
In-Reply-To: <20050730183217.3310585b.kim.phillips@freescale.com>
Tried it as u said . No luck :(
But something more i noted now in CPSR(channel pointer status
register=0x2040) that before ISR invoked it has 0x0:0x7.
After ISR invoked it has 0x7:0x2007 . The 7 in low bits means
channel_error and 2 is at "reserved" bits as per documentation, don't know
what that means.
I also tried kmalloc with GFP_DMA, for the memory where i create the
Descriptor.
Please keep giving ideas for debugging this as this is what driving me
right now.
regards
-vikas
> On Fri, 29 Jul 2005 23:39:32 -0400 (EDT)
> "Vikas Aggarwal" <va824363@albany.edu> wrote:
>
>>
>> But i still think that may be virt_to_phys() is not doing what FR
>> expects.
>>
> try dma_map_single(). See drivers/net/gianfar.c
>
> Kim
>
^ permalink raw reply
* Re: Serial console
From: Daniel Ann @ 2005-08-01 1:27 UTC (permalink / raw)
To: Anton Wöllert; +Cc: linuxppc-embedded
In-Reply-To: <42EB587D.80403@gmail.com>
Thanks for your input Anton.
I'm not all that certain about sandpoint platform has its own serial
driver so I've worked with 8250.c. Anyway, I've got it working now. It
was problem with interrupt. As soon as I changed interrupt from EGDE
to LEVEL it began working. Altho I'm faced with yet another problem
with openpic but I'm digging thru it at the moment.
BTW, I have no idea why EDGE didnt work and LEVEL does.
Cheers,
Daniel
On 7/30/05, Anton W=F6llert <a.woellert@gmail.com> wrote:
> Daniel Ann wrote:
> > Hi folks,
> >
> > Having all the kernel boot up log on console means that I've done some
> > part right. But why am I not getting anything from the user processes
> > on the console screen ?
> >
> > Is there anything I need to do on the kernel config ?
> >
>=20
> Hi, we've had the same problem some time ago on a tqm850l (mpc850). Our
> problem was, that we had registered two serial consoles in the kernel
> config or something like that. we had to disable all serial-driver stuff
> and enable just the platform-specific serial-console driver. we tracked
> this down with inserting a printk(buf) into the tty_write fs-op of the
> serial-port driver in drivers/char/tty_io.c. the ttyS0 was used but has
> taken another serial-driver than the platform specific.
>=20
> may this help you :)
>=20
>=20
> anton
>=20
--=20
Daniel
^ permalink raw reply
* openpic_init() functionality
From: Daniel Ann @ 2005-08-01 2:00 UTC (permalink / raw)
To: linuxppc-embedded
Hi folks,
Just been reading openpic_init() function and found something weird,
so I thought I might turn to pro.
It's a part where it initialises all external sources. Code goes
something like this,
[begin]
/* Init all external sources, including possibly the cascade. */
for (i =3D 0; i < NumSources; i++) {
int sense;
if (ISR[i] =3D=3D 0)
continue;
[snip]
openpic_initirq(i, 8, i+offset, (sense & IRQ_POLARITY_MASK),
(sense & IRQ_SENSE_MASK));
[end]
I can see what openpic_initirq does. But what I dont see is enable
part. openpic_initirq only configures interrupt but does not enable
it. And going thru the rest of the code, nothing calls
openpic_enable_irq().
Can somebody tell me how should these interrupts get enabled ?
Reason is, if I dont force openpic_enable_irq() after
openpic_initirq(), then at the end of booting, I see none of my
interrupts enabled. Im sure somewhere down the line it should get
enabled, but where ?
I'd appreciate your thoughts on this.
--=20
Daniel
^ permalink raw reply
* Re: openpic_init() functionality
From: Eugene Surovegin @ 2005-08-01 3:44 UTC (permalink / raw)
To: Daniel Ann; +Cc: linuxppc-embedded
In-Reply-To: <9b7ca6570507311900212f0179@mail.gmail.com>
On Mon, Aug 01, 2005 at 11:00:29AM +0900, Daniel Ann wrote:
> Hi folks,
>
> Just been reading openpic_init() function and found something weird,
> so I thought I might turn to pro.
> It's a part where it initialises all external sources. Code goes
> something like this,
> [begin]
> /* Init all external sources, including possibly the cascade. */
> for (i = 0; i < NumSources; i++) {
> int sense;
>
> if (ISR[i] == 0)
> continue;
> [snip]
> openpic_initirq(i, 8, i+offset, (sense & IRQ_POLARITY_MASK),
> (sense & IRQ_SENSE_MASK));
> [end]
>
> I can see what openpic_initirq does. But what I dont see is enable
> part. openpic_initirq only configures interrupt but does not enable
> it. And going thru the rest of the code, nothing calls
> openpic_enable_irq().
> Can somebody tell me how should these interrupts get enabled ?
>
> Reason is, if I dont force openpic_enable_irq() after
> openpic_initirq(), then at the end of booting, I see none of my
> interrupts enabled. Im sure somewhere down the line it should get
> enabled, but where ?
It's enabled when somebody calls request_irq, for example.
Generic IRQ code is linked to OpenPIC implementation through
'struct hw_interrupt_type open_pic'.
Next time, try adding printk to a function at question and you'll
easily see that it's being called.
--
Eugene
^ permalink raw reply
* How to config the linux kernel under PPC860 board
From: FCG WANG Baohua @ 2005-08-01 4:53 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 538 bytes --]
Dear All
When I load the kernel 2.4.25 in PPC860 board's RAM , the emulator display A "software error at 0x100 ", I think the "reset" function error
when booting. So how to config the kernel to avoid the problem ?
I use VisionClICK to emulate the PPC860 board, if direct download to RAM with TFTP, there is nothing on serial port after printing
"starting at 0x10000" and the serial port is no input or output after serval seconds. But during the few seconds, I can input any characters on it.
How to slove it? thanks !
[-- Attachment #2: Type: text/html, Size: 1355 bytes --]
^ permalink raw reply
* Re: request_8xxirq
From: Tiago Dall'Agnol @ 2005-08-01 12:55 UTC (permalink / raw)
To: Dan Malek; +Cc: linuxppc-embedded
In-Reply-To: <b50c9dbfb13d8e2f5a82c2a299e46240@embeddededge.com>
Hi Dan
Thanks for your attention. I believe that I'm doing some confusion about
what is "request_8xxirq". I have this function (or some alias?) in my
system, and I guess that there isn't any problem with it. But the
problem I had was a pretty strange, and I decided to take a look at that
function. And I hadn't find its implementation. I tried to grep
request_8xxirq in the whole code, but I just found a
EXPORT_SYMBOL(request_8xxirq).
Anyway, my problem was related to the SEC Lite module. In my Linux, what
I had in source files originally was the use of SEC Lite interruption as
a LEVEL4 (number 9). In some boards (I mean, the same models, just other
boards), the interrupt handler was not called when it should be, i.e.,
when the SEC Lite module ends its processing and signals that the packed
is ready for me. That's the way my system works, with interruption to
signal that the packet was already processed.
So, after identifying that problem, I tried to change interrupt to
LEVEL3 (number 7), and for my surprise... now it works, for all boards.
But why?
Isn't it strange?
Best Regards,
Tiago
Dan Malek wrote:
>
> On Jul 29, 2005, at 1:01 PM, Tiago Dall'Agnol wrote:
>
>> Am I wrong? I didn't understand when that function request_irq is used.
>
>
> At some point I don't remember and against all of my wishes, the code
> was changed from using request_8xxirq to using request_irq using
> an ugly hack to add some offset to the 8xx interrupt vector number.
> I didn't see any bug that needed fixing, but people with the power to
> ignore my maintainer status decided to change it anyway. So, now you
> have to modify your drivers to call request_irq() with some nonsensical
> interrupt number. No value added, just confusion.
>
> Thanks.
>
> -- Dan
>
^ permalink raw reply
* Re: request_8xxirq
From: Alex Zeffertt @ 2005-08-01 13:04 UTC (permalink / raw)
To: Tiago Dall'Agnol; +Cc: linuxppc-embedded
In-Reply-To: <42EA60E1.7040804@parks.com.br>
On Fri, 29 Jul 2005 14:01:21 -0300
"Tiago Dall'Agnol" <tdallagnol@parks.com.br> wrote:
> But this code doesn't help to find request_8xxirq. It just do the
> opposite. This code defines request_irq to be request_8xxirq when
> CONFIG_8xx is defined. But where is located the implementation of
> request_8xxirq?
>
See the code snippet in my last email. The C preprocessor replaces 'int request_irq(...' with 'int
request_8xxirq(...' prior to compilation.
> Alex Zeffertt wrote:
>
> >Maybe you're using a really old kernel. In linux-2.4.4 it's in
> >arch/ppc/kernel/irq.c:
> >
> >-- snip --
> >#if (defined(CONFIG_8xx) || defined(CONFIG_8260))
> >/* Name change so we can catch standard drivers that potentially mess up
> > * the internal interrupt controller on 8xx and 8260. Just bear with me,
> > * I don't like this either and I am searching a better solution. For
> > * now, this is what I need. -- Dan
> > */
> >#define request_irq request_8xxirq
> >
> >...
> >...
> >...
> >
> >int request_irq(unsigned int irq, void (*handler)(int, void *, struct pt_regs *),
> > unsigned long irqflags, const char * devname, void *dev_id)
> >{
> >--/snip --
> >
> >
> >I don't know why it was done like this....
> >
> >Alex
> >
> >
> >On Fri, 29 Jul 2005 10:52:33 -0300
> >"Tiago Dall'Agnol" <tdallagnol@parks.com.br> wrote:
> >
> >
> >
> >>Thank you Alex.
> >>
> >>But in my linux, this is different.
> >>What I have in that file is just
> >>
> >>extern int request_8xxirq(unsigned int irq,
> >> void (*handler)(int, void *, struct pt_regs *),
> >> unsigned long flags,
> >> const char *device,
> >> void *dev_id);
> >>
> >>And the request_8xxirq is declared as a
> >>
> >>EXPORT_SYMBOL(request_8xxirq);
> >>
> >>in arch/ppc/kernel/ppc_ksyms.c.
> >>
> >>I already tried to find out where the code that implements the function
> >>is located, but it seems that it doesn't exist in my distribuction.
> >>Maybe is it a "binary version"?
> >>
> >>Any other information will be apreciated ;-)
> >>
> >>Best Regards,
> >>Tiago
> >>
> >>Alex Zeffertt wrote:
> >>
> >>
> >>
> >>>In linux-2.4 it's in
> >>>
> >>> include/asm-ppc/mpc8xx.h
> >>>
> >>>-- snip --
> >>>#define request_8xxirq request_irq
> >>>--/snip --
> >>>
> >>>And request_irq is in arch/ppc/kernel/irq.c
> >>>
> >>>Alex
> >>>
> >>>On Fri, 29 Jul 2005 10:07:58 -0300
> >>>"Tiago Dall'Agnol" <tdallagnol@parks.com.br> wrote:
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>>Hi,
> >>>>
> >>>>I had some problems with irq in my embedded system. I'm interested in
> >>>>this function source code, but I didn't find it in my linux distribuction?
> >>>>
> >>>>Does anyone know where I can find it?
> >>>>
> >>>>Thanks a lot
> >>>>Tiago
> >>>>
> >>>>Manish Joshi wrote:
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>>Hi,
> >>>>>
> >>>>>I am working on an old code which uses request_8xxirq() call which I
> >>>>>can't find in latest kernel.
> >>>>>Has this been replaced by something else ?
> >>>>>
> >>>>>I see the references on net about replacing request_8xxirq() with
> >>>>>request_irq(). Can I do it ?
> >>>>>
> >>>>>TIA,
> >>>>>Manish
> >>>>>
> >>>>>
> >>>>>------------------------------------------------------------------------
> >>>>>Start your day with Yahoo! - make it your home page
> >>>>><http://us.rd.yahoo.com/evt=34442/*http://www.yahoo.com/r/hs>
> >>>>>
> >>>>>------------------------------------------------------------------------
> >>>>>
> >>>>>_______________________________________________
> >>>>>Linuxppc-embedded mailing list
> >>>>>Linuxppc-embedded@ozlabs.org
> >>>>>https://ozlabs.org/mailman/listinfo/linuxppc-embedded
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>--
> >>>>Tiago Dall'Agnol
> >>>>Pesquisa e Desenvolvimento
> >>>>Tel.: +55.51.470.05.64
> >>>>Fax.: +55.51.470.05.70
> >>>>e-mail: tdallagnol@parks.com.br
> >>>>www.parks.com.br
> >>>>
> >>>>_______________________________________________
> >>>>Linuxppc-embedded mailing list
> >>>>Linuxppc-embedded@ozlabs.org
> >>>>https://ozlabs.org/mailman/listinfo/linuxppc-embedded
> >>>>
> >>>>
> >>>>
> >>>>
> >>>
> >>>
> >>>
> >>>
> >>--
> >>
> >>
> >
> >
> >
>
> --
> Tiago Dall'Agnol
> Pesquisa e Desenvolvimento
> Tel.: +55.51.470.05.64
> Fax.: +55.51.470.05.70
> e-mail: tdallagnol@parks.com.br
> www.parks.com.br
^ permalink raw reply
* Re: request_8xxirq
From: Tiago Dall'Agnol @ 2005-08-01 13:25 UTC (permalink / raw)
To: Alex Zeffertt; +Cc: linuxppc-embedded
In-Reply-To: <20050801140407.5b6e4d36.ajz@cambridgebroadband.com>
Hi Alex
All right. But where are request_8xxirq? That's my doubt.
Thank you,
Tiago
Alex Zeffertt wrote:
>On Fri, 29 Jul 2005 14:01:21 -0300
>"Tiago Dall'Agnol" <tdallagnol@parks.com.br> wrote:
>
>
>>But this code doesn't help to find request_8xxirq. It just do the
>>opposite. This code defines request_irq to be request_8xxirq when
>>CONFIG_8xx is defined. But where is located the implementation of
>>request_8xxirq?
>>
>>
>>
>
>See the code snippet in my last email. The C preprocessor replaces 'int request_irq(...' with 'int
>request_8xxirq(...' prior to compilation.
>
>
>
>
>>Alex Zeffertt wrote:
>>
>>
>>
>>>Maybe you're using a really old kernel. In linux-2.4.4 it's in
>>>arch/ppc/kernel/irq.c:
>>>
>>>-- snip --
>>>#if (defined(CONFIG_8xx) || defined(CONFIG_8260))
>>>/* Name change so we can catch standard drivers that potentially mess up
>>>* the internal interrupt controller on 8xx and 8260. Just bear with me,
>>>* I don't like this either and I am searching a better solution. For
>>>* now, this is what I need. -- Dan
>>>*/
>>>#define request_irq request_8xxirq
>>>
>>>...
>>>...
>>>...
>>>
>>>int request_irq(unsigned int irq, void (*handler)(int, void *, struct pt_regs *),
>>> unsigned long irqflags, const char * devname, void *dev_id)
>>>{
>>>--/snip --
>>>
>>>
>>>I don't know why it was done like this....
>>>
>>>Alex
>>>
>>>
>>>On Fri, 29 Jul 2005 10:52:33 -0300
>>>"Tiago Dall'Agnol" <tdallagnol@parks.com.br> wrote:
>>>
>>>
>>>
>>>
>>>
>>>>Thank you Alex.
>>>>
>>>>But in my linux, this is different.
>>>>What I have in that file is just
>>>>
>>>>extern int request_8xxirq(unsigned int irq,
>>>> void (*handler)(int, void *, struct pt_regs *),
>>>> unsigned long flags,
>>>> const char *device,
>>>> void *dev_id);
>>>>
>>>>And the request_8xxirq is declared as a
>>>>
>>>>EXPORT_SYMBOL(request_8xxirq);
>>>>
>>>>in arch/ppc/kernel/ppc_ksyms.c.
>>>>
>>>>I already tried to find out where the code that implements the function
>>>>is located, but it seems that it doesn't exist in my distribuction.
>>>>Maybe is it a "binary version"?
>>>>
>>>>Any other information will be apreciated ;-)
>>>>
>>>>Best Regards,
>>>>Tiago
>>>>
>>>>Alex Zeffertt wrote:
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>>In linux-2.4 it's in
>>>>>
>>>>> include/asm-ppc/mpc8xx.h
>>>>>
>>>>>-- snip --
>>>>>#define request_8xxirq request_irq
>>>>>--/snip --
>>>>>
>>>>>And request_irq is in arch/ppc/kernel/irq.c
>>>>>
>>>>>Alex
>>>>>
>>>>>On Fri, 29 Jul 2005 10:07:58 -0300
>>>>>"Tiago Dall'Agnol" <tdallagnol@parks.com.br> wrote:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>Hi,
>>>>>>
>>>>>>I had some problems with irq in my embedded system. I'm interested in
>>>>>>this function source code, but I didn't find it in my linux distribuction?
>>>>>>
>>>>>>Does anyone know where I can find it?
>>>>>>
>>>>>>Thanks a lot
>>>>>>Tiago
>>>>>>
>>>>>>Manish Joshi wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>Hi,
>>>>>>>
>>>>>>>I am working on an old code which uses request_8xxirq() call which I
>>>>>>>can't find in latest kernel.
>>>>>>>Has this been replaced by something else ?
>>>>>>>
>>>>>>>I see the references on net about replacing request_8xxirq() with
>>>>>>>request_irq(). Can I do it ?
>>>>>>>
>>>>>>>TIA,
>>>>>>>Manish
>>>>>>>
>>>>>>>
>>>>>>>------------------------------------------------------------------------
>>>>>>>Start your day with Yahoo! - make it your home page
>>>>>>><http://us.rd.yahoo.com/evt=34442/*http://www.yahoo.com/r/hs>
>>>>>>>
>>>>>>>------------------------------------------------------------------------
>>>>>>>
>>>>>>>_______________________________________________
>>>>>>>Linuxppc-embedded mailing list
>>>>>>>Linuxppc-embedded@ozlabs.org
>>>>>>>https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>--
>>>>>>Tiago Dall'Agnol
>>>>>>Pesquisa e Desenvolvimento
>>>>>>Tel.: +55.51.470.05.64
>>>>>>Fax.: +55.51.470.05.70
>>>>>>e-mail: tdallagnol@parks.com.br
>>>>>>www.parks.com.br
>>>>>>
>>>>>>_______________________________________________
>>>>>>Linuxppc-embedded mailing list
>>>>>>Linuxppc-embedded@ozlabs.org
>>>>>>https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>--
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>>
>>--
>>Tiago Dall'Agnol
>>Pesquisa e Desenvolvimento
>>Tel.: +55.51.470.05.64
>>Fax.: +55.51.470.05.70
>>e-mail: tdallagnol@parks.com.br
>>www.parks.com.br
>>
>>
>
>
>
^ 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