* 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
* Re: mpc8248 SEC -- interrupt handler "is" invoked
From: Kim Phillips @ 2005-08-01 17:37 UTC (permalink / raw)
To: Vikas Aggarwal; +Cc: linuxppc-embedded
In-Reply-To: <33216.24.92.61.26.1122857296.squirrel@24.92.61.26>
On Sun, 31 Jul 2005 20:48:16 -0400 (EDT)
"Vikas Aggarwal" <va824363@albany.edu> wrote:
> 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
So you reset the master, then the channel, allocate the RNG descriptor, allocate the random data buffer, fill the descriptor with values for an RNG request the size of your buffer (filling with the physical address of your random data buffer), and submit the descriptor's physical address to the FR..
btw, I'm finding it hard to help without seeing sec register transaction data, descriptor data, virtual and physical addresses, etc.
Kim
^ permalink raw reply
* endianness of Linux kernel RAID
From: Gregory Seidman @ 2005-08-01 17:42 UTC (permalink / raw)
To: LinuxPPC dev list
It turns out that if one uses the kernel (2.4.x-2.6.x) RAID support (RAID5,
anyway, since that's all I've tested), the RAID'd disks cannot be moved to
another system with a different endianness. I don't know how hard that
would be to fix, but it did mean that when my ancient Mac clone I was using
as a server died I couldn't bring the RAID over to my spare x86 Linux box;
I had to dedicate other hardware (my dual G4 that I had been happily using
with OS X) to the task instead.
Unfortunately, I haven't gotten into kernel development and, therefore, do
not have the necessary expertise to fix it. Is anyone here interested in
this issue?
--Greg
^ permalink raw reply
* Re: endianness of Linux kernel RAID
From: Eugene Surovegin @ 2005-08-01 18:18 UTC (permalink / raw)
To: LinuxPPC dev list
In-Reply-To: <20050801174238.GA31016@anthropohedron.net>
On Mon, Aug 01, 2005 at 01:42:39PM -0400, Gregory Seidman wrote:
> It turns out that if one uses the kernel (2.4.x-2.6.x) RAID support (RAID5,
> anyway, since that's all I've tested), the RAID'd disks cannot be moved to
> another system with a different endianness. I don't know how hard that
> would be to fix, but it did mean that when my ancient Mac clone I was using
> as a server died I couldn't bring the RAID over to my spare x86 Linux box;
> I had to dedicate other hardware (my dual G4 that I had been happily using
> with OS X) to the task instead.
>
> Unfortunately, I haven't gotten into kernel development and, therefore, do
> not have the necessary expertise to fix it. Is anyone here interested in
> this issue?
It's a known Linux sw RAID problem. Please, bug RAID maintainers, not
PPC people, as it's not a Linux PPC problem - RAID code is completely
generic one.
--
Eugene
^ permalink raw reply
* Re: mpc8248 SEC -- interrupt handler 'is' invoked
From: Vikas Aggarwal @ 2005-08-01 18:50 UTC (permalink / raw)
To: Kim Phillips; +Cc: linuxppc-embedded
In-Reply-To: <20050801123728.62764c7e.kim.phillips@freescale.com>
Hi Kim,
Yes, i checked to my knowledge that i am doing all these steps and also
checked the
bit positions.
I will send you the code excerpts. The code was written for 2.4 kernel and
8555E(downloaded from freescale) and i ported it to 8248/kernel 2.6.
thanks for your help
-vikas
> On Sun, 31 Jul 2005 20:48:16 -0400 (EDT)
> "Vikas Aggarwal" <va824363@albany.edu> wrote:
>
>> 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
>
>
> So you reset the master, then the channel, allocate the RNG descriptor,
> allocate the random data buffer, fill the descriptor with values for an
> RNG request the size of your buffer (filling with the physical address of
> your random data buffer), and submit the descriptor's physical address to
> the FR..
>
> btw, I'm finding it hard to help without seeing sec register transaction
> data, descriptor data, virtual and physical addresses, etc.
>
> Kim
>
^ permalink raw reply
* Bad Magic Number when boot linux kernel with ppcboot (PPC860 board)
From: FCG WANG Baohua @ 2005-08-02 2:08 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 351 bytes --]
Dear All:
I use a PPC860 board and ELDK 3.1.1 (kernel 2.4.25) to boot the linux kernel, after I loaded it print the following messages:
=> bootm 0x180000
## Booting image at 00000000 ...
Bad Magic Number
=>
How to slove it, thanks a lot!
I use: zImage,
vmlinux.UBoot,
vmlinux
it all print the same messages, How can I do?
[-- Attachment #2: Type: text/html, Size: 1504 bytes --]
^ permalink raw reply
* Reply: Bad Magic Number when boot linux kernel with ppcboot (PPC860 board)
From: FCG WANG Baohua @ 2005-08-02 2:31 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 453 bytes --]
Dear All:
I use a PPC860 board and ELDK 3.1.1 (kernel 2.4.25) to boot the linux kernel, after I loaded it print the following messages:
=> bootm 0x180000
## Booting image at 00000000 ...
Bad Magic Number
=>
How to slove it, thanks a lot!
I use: zImage,
vmlinux.UBoot,
vmlinux
it all print the same messages,
I use "imi 0x180000"
is also print the
"
Checking Image at 00000000 ...
Bad Magic Number"
How can I do?
[-- Attachment #2: Type: text/html, Size: 2054 bytes --]
^ permalink raw reply
* Re: Bad Magic Number when boot linux kernel with ppcboot (PPC860 board)
From: Debora Liu @ 2005-08-02 3:17 UTC (permalink / raw)
To: FCG WANG Baohua; +Cc: Linuxppc-embedded
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 463 bytes --]
Hello, FCG WANG Baohua
In message <2005-08-02 10:08:35 Baohua.WANG@alcatel-sbell.com.cn> you wrote:
>Dear All:
> I use a PPC860 board and ELDK 3.1.1 (kernel 2.4.25) to boot the linux kernel, after I loaded it print the following messages:
>
>=> bootm 0x180000
>## Booting image at 00000000 ...
>Bad Magic Number
>=>
Please check your boot load image address.
¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡Debora Liu
¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡deboralh@fel.com.cn
¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡2005-08-02
^ 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