* Re: Yosemite board ala, PPC405EP
From: Jeff.Fellin @ 2006-03-08 21:18 UTC (permalink / raw)
To: dwh; +Cc: linuxppc-embedded
Sorry, I was confused. I have a PPC405EP. not a Yosemite board.
Jeff Fellin
RFL Electronics
Jeff.Fellin@rflelect.com
973 334-3100, x 327
David Hawkins
<dwh@ovro.caltech To: Jeff.Fellin@rflelect.com
.edu> cc: linuxppc-embedded@ozlabs.org
Subject: Re: Yosemite board ala, PPC405EP
03/08/2006 15:27
Jeff.Fellin@rflelect.com wrote:
> I have been using an Albatron BDI for a PPC405GP board in a project.
> According to the documentation I've read the Yosemite board is identical
> register wise to the 405GP, except for two sets of EMAC registers.
>
> My problem is when I use the Albatron BDI using the register definitions
> for the 405GP, the BDI cannot communicate with the 405EP.
>
> Anyone have experience with usingg the BDI for the PPC 405EP?
Hey Jeff,
Can you please clarify;
Are you using a Yosemite board (440EP) or are you using a 405EP board
(which is *not* the Yosemite board)?
If you are using the Yosemite board, then I have one here,
and my BDI2000 just arrived. I haven't had a chance to test
the BDI2000, but I can let you know the results when I do.
Dave
^ permalink raw reply
* Re: Yosemite board ala, PPC405EP
From: David Hawkins @ 2006-03-08 20:27 UTC (permalink / raw)
To: Jeff.Fellin; +Cc: linuxppc-embedded
In-Reply-To: <OFFBE09E88.DB8A5C68-ON8525712B.006C3D78@teal.com>
Jeff.Fellin@rflelect.com wrote:
> I have been using an Albatron BDI for a PPC405GP board in a project.
> According to the documentation I've read the Yosemite board is identical
> register wise to the 405GP, except for two sets of EMAC registers.
>
> My problem is when I use the Albatron BDI using the register definitions
> for the 405GP, the BDI cannot communicate with the 405EP.
>
> Anyone have experience with usingg the BDI for the PPC 405EP?
Hey Jeff,
Can you please clarify;
Are you using a Yosemite board (440EP) or are you using a 405EP board
(which is *not* the Yosemite board)?
If you are using the Yosemite board, then I have one here,
and my BDI2000 just arrived. I haven't had a chance to test
the BDI2000, but I can let you know the results when I do.
Dave
^ permalink raw reply
* Re: Yosemite board ala, PPC405EP
From: Eugene Surovegin @ 2006-03-08 20:21 UTC (permalink / raw)
To: Jeff.Fellin; +Cc: linuxppc-embedded
In-Reply-To: <OFFBE09E88.DB8A5C68-ON8525712B.006C3D78@teal.com>
On Wed, Mar 08, 2006 at 02:45:54PM -0500, Jeff.Fellin@rflelect.com wrote:
>
> I have been using an Albatron BDI for a PPC405GP board in a project.
> According to the documentation I've read the Yosemite board is identical
> register wise to the 405GP, except for two sets of EMAC registers.
>
> My problem is when I use the Albatron BDI using the register definitions
> for the 405GP, the BDI cannot communicate with the 405EP.
>
> Anyone have experience with usingg the BDI for the PPC 405EP?
AFAIK, Yosemite is 440EP, not 405EP. And 440EP is quite different from
405GP.
--
Eugene
^ permalink raw reply
* Yosemite board ala, PPC405EP
From: Jeff.Fellin @ 2006-03-08 19:45 UTC (permalink / raw)
To: linuxppc-embedded
I have been using an Albatron BDI for a PPC405GP board in a project.
According to the documentation I've read the Yosemite board is identical
register wise to the 405GP, except for two sets of EMAC registers.
My problem is when I use the Albatron BDI using the register definitions
for the 405GP, the BDI cannot communicate with the 405EP.
Anyone have experience with usingg the BDI for the PPC 405EP?
Thank you in advance for you help.
Jeff Fellin
RFL Electronics
Jeff.Fellin@rflelect.com
973 334-3100, x 327
^ permalink raw reply
* [PATCH] add a raw dump command to xmon
From: Olaf Hering @ 2006-03-08 19:40 UTC (permalink / raw)
To: Paul Mackeras, linuxppc-dev
Dump a stream of rawbytes with a new 'dr' command.
Produces less output and it is simpler to feed the output to scripts.
Also, dr has no dumpsize limits.
Signed-off-by: Olaf Hering <olh@suse.de>
arch/powerpc/xmon/xmon.c | 30 ++++++++++++++++++++++++++++++
1 files changed, 30 insertions(+)
Index: linux-2.6.16-rc5-olh/arch/powerpc/xmon/xmon.c
===================================================================
--- linux-2.6.16-rc5-olh.orig/arch/powerpc/xmon/xmon.c
+++ linux-2.6.16-rc5-olh/arch/powerpc/xmon/xmon.c
@@ -191,6 +191,7 @@ Commands:\n\
di dump instructions\n\
df dump float values\n\
dd dump double values\n\
+ dr dump stream of raw bytes\n\
e print exception information\n\
f flush cache\n\
la lookup symbol+offset of specified address\n\
@@ -1938,6 +1939,28 @@ bsesc(void)
return c;
}
+static void xmon_rawdump (unsigned long adrs, long ndump)
+{
+ long n, m, r, nr;
+ unsigned char temp[16];
+
+ for (n = ndump; n > 0;) {
+ r = n < 16? n: 16;
+ nr = mread(adrs, temp, r);
+ adrs += nr;
+ for (m = 0; m < r; ++m) {
+ if (m < nr)
+ printf("%.2x", temp[m]);
+ else
+ printf("%s", fault_chars[fault_type]);
+ }
+ n -= r;
+ if (nr < r)
+ break;
+ }
+ printf("\n");
+}
+
#define isxdigit(c) (('0' <= (c) && (c) <= '9') \
|| ('a' <= (c) && (c) <= 'f') \
|| ('A' <= (c) && (c) <= 'F'))
@@ -1960,6 +1983,13 @@ dump(void)
nidump = MAX_DUMP;
adrs += ppc_inst_dump(adrs, nidump, 1);
last_cmd = "di\n";
+ } else if (c == 'r') {
+ scanhex(&ndump);
+ if (ndump == 0)
+ ndump = 64;
+ xmon_rawdump(adrs, ndump);
+ adrs += ndump;
+ last_cmd = "dr\n";
} else {
scanhex(&ndump);
if (ndump == 0)
^ permalink raw reply
* RE: [PATCH] Fix MPC8548CDS rebooting procedure
From: Haruki Dai-r35557 @ 2006-03-08 19:24 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
> -----Original Message-----
> From: Kumar Gala [mailto:galak@kernel.crashing.org]=20
> Sent: Wednesday, March 08, 2006 12:33 PM
> To: Haruki Dai-r35557
> Cc: linuxppc-dev@ozlabs.org
> Subject: Re: [PATCH] Fix MPC8548CDS rebooting procedure
>=20
>=20
> On Mar 8, 2006, at 11:22 AM, Haruki Dai-r35557 wrote:
>=20
> > This patch fixes the MPC8548 CDS rebooting procedure.
> > Without this patche, issuing reboot from shell doesn't reboot the=20
> > machine.
> >
> > Signed-off-by: Dai Haruki <dai.haruki@freescale.com>
>=20
> Dai, I'm avoid taking patches for 85xx that effect new=20
> functionality. If you want change this to work with=20
> arch/powerpc and make it a run time check for 8548.
Hi Kumar, what kind of new feature is affected by this bug fix? 8548
requires reboot to set the hardware reset bits. The mpc85xx_restart() is
not ported to arch/powerpc yet. Which portion of the arch/powerpc code
should be modified in order to restart the machine correctly?=20
And how do you want me to do run time check? Check SVR?=20
Dai=20
>=20
> - kumar
>=20
> > ---
> >
> > arch/ppc/syslib/ppc85xx_setup.c | 5 +++++
> > 1 files changed, 5 insertions(+), 0 deletions(-)
> >
> > 8f095006923385c3546165b0e10d73d3e057c120
> > diff --git a/arch/ppc/syslib/ppc85xx_setup.c=20
> > b/arch/ppc/syslib/ppc85xx_setup.c index e4dda43..45b1b2b 100644
> > --- a/arch/ppc/syslib/ppc85xx_setup.c
> > +++ b/arch/ppc/syslib/ppc85xx_setup.c
> > @@ -115,6 +115,11 @@ mpc85xx_early_serial_map(void) void =20
> > mpc85xx_restart(char *cmd) {
> > +#ifdef CONFIG_MPC8548
> > + volatile unsigned int *rstcr;
> > + u32 *pMem =3D (u32*) ioremap((BOARD_CCSRBAR + 0xe00b0),0x100);
> > + *pMem =3D 0x2; /* Set HRESET_REQ flag */ #endif
> > local_irq_disable();
> > abort();
> > }
> > --
> > 1.2.4
> > _______________________________________________
> > Linuxppc-dev mailing list
> > Linuxppc-dev@ozlabs.org
> > https://ozlabs.org/mailman/listinfo/linuxppc-dev
>=20
>=20
^ permalink raw reply
* Re: [PATCH] Fix MPC8548CDS rebooting procedure
From: Kumar Gala @ 2006-03-08 18:33 UTC (permalink / raw)
To: Haruki Dai-r35557; +Cc: linuxppc-dev
In-Reply-To: <18AEF66AFDF06F4CAAA1D419D000FD332ECDA6@az33exm24.fsl.freescale.net>
On Mar 8, 2006, at 11:22 AM, Haruki Dai-r35557 wrote:
> This patch fixes the MPC8548 CDS rebooting procedure.
> Without this patche, issuing reboot from shell doesn't reboot the
> machine.
>
> Signed-off-by: Dai Haruki <dai.haruki@freescale.com>
Dai, I'm avoid taking patches for 85xx that effect new
functionality. If you want change this to work with arch/powerpc and
make it a run time check for 8548.
- kumar
> ---
>
> arch/ppc/syslib/ppc85xx_setup.c | 5 +++++
> 1 files changed, 5 insertions(+), 0 deletions(-)
>
> 8f095006923385c3546165b0e10d73d3e057c120
> diff --git a/arch/ppc/syslib/ppc85xx_setup.c
> b/arch/ppc/syslib/ppc85xx_setup.c
> index e4dda43..45b1b2b 100644
> --- a/arch/ppc/syslib/ppc85xx_setup.c
> +++ b/arch/ppc/syslib/ppc85xx_setup.c
> @@ -115,6 +115,11 @@ mpc85xx_early_serial_map(void)
> void
> mpc85xx_restart(char *cmd)
> {
> +#ifdef CONFIG_MPC8548
> + volatile unsigned int *rstcr;
> + u32 *pMem = (u32*) ioremap((BOARD_CCSRBAR + 0xe00b0),0x100);
> + *pMem = 0x2; /* Set HRESET_REQ flag */
> +#endif
> local_irq_disable();
> abort();
> }
> --
> 1.2.4
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply
* [PATCH] Fix MPC8548CDS rebooting procedure
From: Haruki Dai-r35557 @ 2006-03-08 17:22 UTC (permalink / raw)
To: linuxppc-dev
This patch fixes the MPC8548 CDS rebooting procedure.
Without this patche, issuing reboot from shell doesn't reboot the
machine.=20
Signed-off-by: Dai Haruki <dai.haruki@freescale.com>
---
arch/ppc/syslib/ppc85xx_setup.c | 5 +++++
1 files changed, 5 insertions(+), 0 deletions(-)
8f095006923385c3546165b0e10d73d3e057c120
diff --git a/arch/ppc/syslib/ppc85xx_setup.c
b/arch/ppc/syslib/ppc85xx_setup.c
index e4dda43..45b1b2b 100644
--- a/arch/ppc/syslib/ppc85xx_setup.c
+++ b/arch/ppc/syslib/ppc85xx_setup.c
@@ -115,6 +115,11 @@ mpc85xx_early_serial_map(void)
void
mpc85xx_restart(char *cmd)
{
+#ifdef CONFIG_MPC8548
+ volatile unsigned int *rstcr;
+ u32 *pMem =3D (u32*) ioremap((BOARD_CCSRBAR + 0xe00b0),0x100);
+ *pMem =3D 0x2; /* Set HRESET_REQ flag */
+#endif
local_irq_disable();
abort();
}
--=20
1.2.4
^ permalink raw reply related
* RE: Stable Linux kernel 2.6 for MPC8XX
From: Fillod Stephane @ 2006-03-08 14:29 UTC (permalink / raw)
To: Laurent Lagrange, linuxppc-embedded
>I would want to use a linux kernel 2.6 on a custom MPC8xx board.
>Which stable kernel release must or can I use ?
http://www.denx.de/wiki/bin/view/Know/Linux24vs26
--=20
SF
^ permalink raw reply
* Stable Linux kernel 2.6 for MPC8XX
From: Laurent Lagrange @ 2006-03-08 14:32 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <000201c63c44$14a9c1b0$5201a8c0@GEG2400>
Hello,
I would want to use a linux kernel 2.6 on a custom MPC8xx board.
Which stable kernel release must or can I use ?
Thanks
Laurent
^ permalink raw reply
* Re: linux DMA capabilities in MV64460
From: Phil Nitschke @ 2006-03-08 14:02 UTC (permalink / raw)
To: linuxppc-embedded; +Cc: Brian Waite
In-Reply-To: <200603060821.29220.brian@waitefamily.us>
>>>>> "BW" == Brian Waite <brian@waitefamily.us> writes:
>> I'm now looking seriously (and reluctantly!) at writing a DMA
>> Controller Driver to supplement these functions, and I've started
>> the process of getting an NDA from Marvell, so I can get their
>> User Manual (and errata!).
BW> You won't get very far without the user manual, then I think you
BW> will find it pretty easy to write the driver with the frameworks
BW> already in the kernel.
>> Can someone point me in the right direction to get me started? I
>> need to come up the learning curve to find out where to start.
>>
>> How is a DMA controlled (from a device driver writer's
>> perspective) when a third-party (i.e. in the bridge) DMA
>> controller needs to do the work to get the data from a PCI Target
>> into main memory?
>>
>> What kernel API should be provided by the DMA Controller Driver?
BW> My first guess would be to follow something like
BW> Documentation/DMA-API.txt and Documentation/DMA-mapping.txt
I can't see how trying to match those DMA functions would work.
The dma_map_xxx() functions and friends appear to be invoked from
driver interrupt handlers, which are either responding to an interrupt
from a PCI Target which wants to commence a bus-mastered DMA to/from
main memory, or responding to a second interrupt to say the interrupt
is complete.
In my case, my driver receives one interrupt from a PCI Target which
cannot perform a DMA, and I presumably have to use an alternative API
(i.e. my "new" set of ("DMA Controller") driver functions) to get the
platform DMA controller to fetch the data and wake (interrupt) me once
complete. Right?
>> Any documentation, examples, similar device drivers, etc, would
>> be appreciated. TIA,
BW> You could look to followup that by groking
BW> arch/ppc/kernel/dma-mapping.c
OK.
BW> Finally, arch/ppc/syslib ppc4xx_dma.c seems to show an example
BW> of a low level driver.
OK, so suppose I write a bunch of functions, like this:
mv64x60_disable_dma();
mv64x60_disable_dma_interrupt();
mv64x60_enable_dma();
mv64x60_enable_dma_interrupt();
mv64x60_get_dma_status();
mv64x60_init_dma_channel();
... etc,
then how do these get called; directly from my other driver?
(I could not see any place that the ppc4xx_ dma functions were being
called, i.e. they don't seem to dovetail into some higher level kernel
API...?)
BW> I didn't notice any platform dma controllers like MAG
BW> reccommended, but that should be a better way to go.
Perhaps Mark was talking about ppc4xx_dma.c and ppc4xx_sgdma.c ?
Sorry if I'm too slow on the uptake. Thanks for your input,
--
Phil
^ permalink raw reply
* bdi2000 config file
From: Mustafa Çayır @ 2006-03-08 10:09 UTC (permalink / raw)
To: linuxppc-embedded
Hi,
Are thare any guide about generating bdi2000 config file ?
I'm working on board MVME6100. are there bdi2000 config file of this =
board? Or, anyone has a bdi2000 config file of a board that has marvell =
64360 bridge?
thanks .
^ permalink raw reply
* Re: How to quickly write cleanmarkers to jffs2 partitions?
From: David Jander @ 2006-03-08 8:38 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <1141647684.23522.7.camel@linpc041.aimsys.nl>
On Monday 06 March 2006 13:21, Jaap-Jan Boor wrote:
> On Fri, 2006-03-03 at 10:08 +0100, Mathieu Deschamps wrote:
> > Hi,
> >
> > "When preparing a flash partition for JFFS2, it is recommended to put
> > cleanmarkers to the erased blocks.
> > This might be done my means of "-j" option of the "flash_eraseall" MTD
> > utility. Otherwise, JFFS2 will re-erase the blocks
> > which contain all 0xFF and have no cleanmarker. This is an unneeded
> > wasting of time."
> >
> > Source : http://www.linux-mtd.infradead.org/faq/jffs2.html
> >
> > does this may be relevant ?
>
> This is correct, however flash_eraseall does also (as it's
> name suggests, erase all flash blocks, which takes
> some time on NOR flash. If you 'know' the flash is erased,
> it's not needed.
> I used flash_eraseall to write the cleanmarkers, but without
> erasing blocks (and called that utility cleanmark)
Thanks to all for the suggestions.
Is "cleanmark" an open-source tool? Would you share it?
Greetings,
--
David Jander
^ permalink raw reply
* Re: please pull powerpc-merge.git
From: Olaf Hering @ 2006-03-08 8:08 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, torvalds
In-Reply-To: <17422.16982.705624.256207@cargo.ozlabs.ibm.com>
On Wed, Mar 08, Paul Mackeras wrote:
> powerpc: incorrect rmo_top handling in prom_init
I would leave this one out. It gives the false impression that ibook1
works ok, while later it will likely eat your filesystem. Its not a
regression in that sense because 2.6.15 was also broken and noone
complained.
^ permalink raw reply
* please pull powerpc-merge.git
From: Paul Mackerras @ 2006-03-08 2:32 UTC (permalink / raw)
To: torvalds; +Cc: linuxppc-dev
Linus,
Please do a pull from
git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc-merge.git
There is just one new commit - the one from me fixing some problems in
the syscall entry/exit path. There are 8 commits still there from the
last pull request.
Thanks,
Paul.
Benjamin Herrenschmidt:
powerpc: Fix old g5 issues with windfarm
powerpc: Fix windfarm_pm112 not starting all control loops
powerpc: Expose SMT and L1 icache snoop userland features
powerpc: incorrect rmo_top handling in prom_init
David Gibson:
powerpc: Fix incorrect pud_ERROR() message
Paul Mackerras:
powerpc: Fix might-sleep warning in program check exception handler
powerpc: Turn off verbose debug output in powermac platform functions
powerpc32: Fix timebase synchronization on 32-bit powermacs
powerpc: Fix various syscall/signal/swapcontext bugs
arch/powerpc/kernel/asm-offsets.c | 1
arch/powerpc/kernel/cputable.c | 9 ++
arch/powerpc/kernel/entry_32.S | 95 +++++++-------------------
arch/powerpc/kernel/entry_64.S | 94 ++++++--------------------
arch/powerpc/kernel/prom_init.c | 2 -
arch/powerpc/kernel/ptrace.c | 5 -
arch/powerpc/kernel/signal_32.c | 19 +----
arch/powerpc/kernel/signal_64.c | 9 --
arch/powerpc/kernel/systbl.S | 2 -
arch/powerpc/kernel/traps.c | 2 +
arch/powerpc/platforms/powermac/pfunc_base.c | 5 +
arch/powerpc/platforms/powermac/pfunc_core.c | 6 ++
arch/powerpc/platforms/powermac/smp.c | 2 -
arch/ppc/kernel/asm-offsets.c | 1
arch/ppc/kernel/entry.S | 95 +++++++-------------------
drivers/macintosh/windfarm_core.c | 7 ++
drivers/macintosh/windfarm_cpufreq_clamp.c | 8 ++
drivers/macintosh/windfarm_lm75_sensor.c | 32 ++++++---
drivers/macintosh/windfarm_max6690_sensor.c | 25 +++++--
drivers/macintosh/windfarm_pm112.c | 8 +-
include/asm-powerpc/cputable.h | 2 +
include/asm-powerpc/pgtable-4k.h | 2 -
include/asm-powerpc/thread_info.h | 8 +-
23 files changed, 163 insertions(+), 276 deletions(-)
^ permalink raw reply
* Re: signal/syscall/swapcontext fixes
From: David Woodhouse @ 2006-03-07 23:36 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <17421.62535.805543.661898@cargo.ozlabs.ibm.com>
On Wed, 2006-03-08 at 07:59 +1100, Paul Mackerras wrote:
> David Woodhouse writes:
>
> > The 64-bit version (bl .save_nvgprs) is prettier than the 32-bit version
> > (doing it longhand), and they're still gratuitously different. We should
> > probably fix that.
>
> There's also the difference where ret_from_except in 32-bit does what
> ret_from_except_lite does in 64-bit, and the 32-bit
> ret_from_except_full is approximately the same as the 64-bit
> ret_from_except. :)
Oh yeah -- I remember that now :)
> > On a similar note, we should also do a ptrace stop when we deliver
> > signals, to ensure that the debugger gets a stop _on_ the first
> > instruction of the handler. Once upon a time there was a stop in
> > handle_rt_signal() and handle_signal(), but doing it that way gave a
> > _double_ stop when we ended up in a signal handler from sigsuspend(),
> > because the syscall stop you just fixed for ppc32 happened too.
>
> Do we have a fix for this for 2.6.16, or will we leave it until
> 2.6.17?
It's hardly a showstopper -- I suspect we can happily leave it for now.
Adding the stops back where they were isn't perfect, and I thought I had
a better plan when I removed them. Buggered if I can remember it now
though.
> > On a purely cosmetic note I'm not sure about this though -- it was
> > slightly easier to follow when it was more explicit:
> > - andi. r0,r9,(_TIF_SYSCALL_T_OR_A|_TIF_SINGLESTEP|_TIF_SIGPENDING|_TIF_NEED_RESCHED|_TIF_RESTOREALL|_TIF_SAVE_NVGPRS|_TIF_NOERROR|_TIF_RESTORE_SIGMASK)
> > + andi. r0,r9,(_TIF_SYSCALL_T_OR_A|_TIF_SINGLESTEP|_TIF_USER_WORK_MASK|_TIF_PERSYSCALL_MASK)
>
> I did it that way because we are clearing _TIF_PERSYSCALL_MASK further
> down. If we expand one we should expand both.
Yeah, I suppose you're right.
--
dwmw2
^ permalink raw reply
* double fec on adder875
From: Antonio Di Bacco @ 2006-03-07 22:59 UTC (permalink / raw)
To: linuxppc-embedded
I found a patch to "fec.c" in 2.4 on http://patchwork.ozlabs.org/linuxppc/ to
make work both the fecs on mpc875.
Anyone used it? The patch is from Jan Damborsky.
The patch is in state "REJECTED"!!
What is http://patchwork.ozlabs.org/linuxppc/? Something you can post patches
that will be part of the official kernel?
Bye,
Antonio.
^ permalink raw reply
* 440gx dma transfer with no data change at dest
From: Kevin Kleinosowski @ 2006-03-07 21:16 UTC (permalink / raw)
To: linuxppc-embedded
I am running a simple test with a software initiated DMA transfer from one
bigphysarea allocated buffer to another bigphysarea allocated buffer.
The destination buffer shows no data changes once the transfer is done.
However, I perform the same simple test using __get_dma_pages() rather
then the bigphysarea_alloc_pages() and the destination does get the
data transfer.
Is there a reason this should fail for bigphysarea? I understand the low
memory addresses needed for the DMA controller on some platforms, but I
didnt think that limitation existed on the PPC. Besides that, the
bigphysarea returns low memory address anyway. Anyone have an idea why?
An old archive email had someone with a similar problem, but there were no
follow-ups to the message.
I have linux 2.4.27-pre3 patched, ppc-linux-gcc (GCC) 3.3.3 (DENX ELDK
3.1.1 3.3.3-9), U-Boot 1.1.2, and GMS 440gx board.
thanks,
Kevin
^ permalink raw reply
* Hints on hard hang
From: Bizhan Gholikhamseh (bgholikh) @ 2006-03-07 21:19 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 394 bytes --]
Hi All,
Our custom board based on 8541 processor running Linux 2.6.11 gets hard
hang during run time. We can't soft reset (SRESET, Pin#AF20) and get a
machine check interrupt when the hang happens, and JTAG can not
communicate with the processor. We do not know how to go to debug this
issue. If you have any idea or hints, we greatly appreciate.
Many thanks in advance,
Bizhan
[-- Attachment #2: Type: text/html, Size: 1275 bytes --]
^ permalink raw reply
* Re: signal/syscall/swapcontext fixes
From: Paul Mackerras @ 2006-03-07 20:59 UTC (permalink / raw)
To: David Woodhouse; +Cc: linuxppc-dev
In-Reply-To: <1141736951.4110.167.camel@pmac.infradead.org>
David Woodhouse writes:
> The 64-bit version (bl .save_nvgprs) is prettier than the 32-bit version
> (doing it longhand), and they're still gratuitously different. We should
> probably fix that.
There's also the difference where ret_from_except in 32-bit does what
ret_from_except_lite does in 64-bit, and the 32-bit
ret_from_except_full is approximately the same as the 64-bit
ret_from_except. :)
> On a similar note, we should also do a ptrace stop when we deliver
> signals, to ensure that the debugger gets a stop _on_ the first
> instruction of the handler. Once upon a time there was a stop in
> handle_rt_signal() and handle_signal(), but doing it that way gave a
> _double_ stop when we ended up in a signal handler from sigsuspend(),
> because the syscall stop you just fixed for ppc32 happened too.
Do we have a fix for this for 2.6.16, or will we leave it until
2.6.17?
> On a purely cosmetic note I'm not sure about this though -- it was
> slightly easier to follow when it was more explicit:
> - andi. r0,r9,(_TIF_SYSCALL_T_OR_A|_TIF_SINGLESTEP|_TIF_SIGPENDING|_TIF_NEED_RESCHED|_TIF_RESTOREALL|_TIF_SAVE_NVGPRS|_TIF_NOERROR|_TIF_RESTORE_SIGMASK)
> + andi. r0,r9,(_TIF_SYSCALL_T_OR_A|_TIF_SINGLESTEP|_TIF_USER_WORK_MASK|_TIF_PERSYSCALL_MASK)
I did it that way because we are clearing _TIF_PERSYSCALL_MASK further
down. If we expand one we should expand both.
Paul.
^ permalink raw reply
* Re: Calling PCI Autoconfig again
From: Michael Richardson @ 2006-03-07 15:48 UTC (permalink / raw)
To: Wyse, Chris; +Cc: linuxppc-embedded
In-Reply-To: <927594BA71733F4BAA815162B79A3F513B27FD@ala-mail04.corp.ad.wrs.com>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
You need some kind of hotplug PCI interface to make this work.
When I last tried this -- for the same reason --- it was hard because we
couldn't get the physical memory map from the (PC) BIOS. (This was
before ACPI 2.0...)
Since you have complete control over the board, you should have this
information already.
- --
] ON HUMILITY: to err is human. To moo, bovine. | firewalls [
] Michael Richardson, Xelerance Corporation, Ottawa, ON |net architect[
] mcr@xelerance.com http://www.sandelman.ottawa.on.ca/mcr/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Finger me for keys
iQEVAwUBRA2rNICLcPvd0N1lAQLchQf9E6B6ISMnpam5rgCXe67RQz3IWseOMtAb
8m65WKBDwTUxwKIwiOygY0AnLudL4+dSKp8QaswXsjl4g7BvjVBwjWH0itmIvWew
1V0BUVJUNMpzYH7I9fEtbJXjQvN/8VyJRX+7HIndvH1CWpeDzHgQTAVu+CIVfyGI
SEEZsgwzgq8mzbopawxPORd+rKv9F6tlnbqAU8P1eHB8wcUEu+WZQ+oA3WGS+Zhn
5ZjK3dX+QXI2JykicyS7VVUT5D6vaZFon4Ikk4Ao0JKfNHmAD7fN4BHhORrpGYyR
+dHlRZlZiRfw3AEoqg6XZZrcGWfciBK8mD6utPnSHomMsaTk80jbtQ==
=o2Wv
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: Calling PCI Autoconfig again
From: Kumar Gala @ 2006-03-07 19:57 UTC (permalink / raw)
To: Wyse, Chris; +Cc: linuxppc-embedded, McComb, Michael, Touron, Emmanuel
In-Reply-To: <927594BA71733F4BAA815162B79A3F513B2B03@ala-mail04.corp.ad.wrs.com>
On Mar 7, 2006, at 1:25 PM, Wyse, Chris wrote:
> Hi Kumar,
>
> Thanks for the response. Also, I apologize to the group - I didn't
> mean
> to CC: the list with the last note. However, I am glad that it got a
> response from you.
>
> Regarding the FPGA address assignment - it doesn't matter at all to
> me,
> I just need to be able to access it on the PCI once the load is
> complete.
>
> As for the FPGA loader, the intent is that it will make the call to
> rescan the PCI after the load is complete. In fact, I intend to
> use it
> as a way of determining if the load completed successfully, since we
> don't have access to the DONE signal from the FPGA (we ran out of GPIO
> pins).
>
> If you missed this link from a previous post, please check it out. It
> implements a rescan of the PCI.
>
> http://marc.theaimsgroup.com/?l=linux-hotplug-
> devel&m=101318310111131&w=
> 2
I saw this link and felt that the code was doing alot of work that
was already handled by the PCI subsystem for you. For example, there
isn't a need for you to kmalloc your own dev and go through all the
effort.
For your case it should be as simple as the following:
bus = pci_find_bus(0, bus_of_dev);
dev = pci_scan_single_device(bus, devfn);
pci_bus_alloc_resource(...);
pci_bus_add_devices(bus);
You could also look at using the pci_scan_slot() / pci_find_slot()
instead of pci_scan_single_device().
- kumar
^ permalink raw reply
* RE: Calling PCI Autoconfig again
From: Wyse, Chris @ 2006-03-07 19:25 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-embedded, McComb, Michael, Touron, Emmanuel
Hi Kumar,
Thanks for the response. Also, I apologize to the group - I didn't mean
to CC: the list with the last note. However, I am glad that it got a
response from you.
Regarding the FPGA address assignment - it doesn't matter at all to me,
I just need to be able to access it on the PCI once the load is
complete.
As for the FPGA loader, the intent is that it will make the call to
rescan the PCI after the load is complete. In fact, I intend to use it
as a way of determining if the load completed successfully, since we
don't have access to the DONE signal from the FPGA (we ran out of GPIO
pins). =20
If you missed this link from a previous post, please check it out. It
implements a rescan of the PCI.
http://marc.theaimsgroup.com/?l=3Dlinux-hotplug-devel&m=3D101318310111131=
&w=3D
2=20
I see that you have a requirement for a fixed BAR address. I think you
could modify the code from the above link to load a new BAR address
after the PCI has been rescanned. You could probably add a routine to
register a BAR address for a device, and change the check_hw() routine
to see if a BAR address is registered. If so, it would free the
allocated space for the device, allocate space at the desired address,
then write the new address to the BAR.
Hope this helps. I'll be monitoring your thread for future
developments.
Chris Wyse
Member of Technical Staff
Embedded Technologies
860-749-1556 office
860-978-0849 cell
413-778-9101 fax
http://www.windriver.com
=20
-----Original Message-----
From: Kumar Gala [mailto:galak@kernel.crashing.org]=20
Sent: Tuesday, March 07, 2006 11:27 AM
To: Wyse, Chris
Cc: Touron, Emmanuel; McComb, Michael; linuxppc-embedded@ozlabs.org
Subject: Re: Calling PCI Autoconfig again
On Mar 7, 2006, at 8:17 AM, Wyse, Chris wrote:
> Hi,
>
> This code will do the rescan of the PCI that we need for the FPGA.
> However, it currently only supports a single execution after the FPGA=20
> gets loaded. Additional calls will continue to add FPGA devices to=20
> the PCI device list data structure. I'm going to make some changes to
> it to handle multiple calls and to support multiple device ids. I'm=20
> expecting it to take a day or two, but I'll make an initial cut at it=20
> today that will let us load the Spartan FPGA (only once). This driver
> will be loaded when the kernel boots, so I believe that we'll just=20
> need to make a call into it (we won't have to dynamically load it like
> the phob driver).
I'm dealing with this exact same situation and having a discussion on
lkml regarding the proper way to do this. In your case, do you care
what addresses the FPGA is assigned at?
http://marc.theaimsgroup.com/?l=3Dlinux-kernel&m=3D114140791428032&w=3D2
> Michael,
>
> For the FPGA loader, you should load the FPGA, then make a call to
> pci_rescan_bus0() (I'm renaming check_hw() to pci_rescan_bus0()). =20
> Next,
> you need to do a pci_find_device() to detect the newly loaded FPGA. =20
> If the pci_find_device() fails, assume that the FPGA load has not=20
> completed, so delay for some time frame (100 ms??), then rescan again.
> If still not found, rescan up to MAX_PCI_RESCANS (probably set it to=20
> 3) times, then return an error that the FPGA load failed.
Do you not know when the FPGA load is done? I assume its under software
control so the "fpga loader" should just call the PCI setup code once it
has completed successfully.
- kumar
^ permalink raw reply
* RE: help reqd
From: atul.sabharwal @ 2006-03-07 18:27 UTC (permalink / raw)
To: achim.machura, prabha.j; +Cc: linuxppc-embedded
> insmod: unresolved symbol copy_to_user=20
> insmod: unresolved symbol down=20
> insmod: unresolved symbol up=20
> insmod: unresolved symbol copy_from_user=20
>>you have to include <asm/uacces.h>
Including a header file is only needed for compilation. This is a
dynamic link/load error. Unless the header file is putting some
information about the kernel link/load method. Without module
versioning, you should be able=20
To load any driver binary compiled for a given kernel version. Any
exceptions to this concept ?
--
Atul
^ permalink raw reply
* RE: help reqd
From: atul.sabharwal @ 2006-03-07 18:23 UTC (permalink / raw)
To: prabha.j, linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 1796 bytes --]
Possible answers: Module versioning turned on in kernel? insmod module
format not compatible with kernel ? Try modprobe which
checks the dependencies. These calls are kernel space to user space
copy operations. Top 3GB to below 3GB on most systems
unless it's a 2GB/2GB split between user/kernel space.
--
Atul
________________________________
From: linuxppc-embedded-bounces+atul.sabharwal=tek.com@ozlabs.org
[mailto:linuxppc-embedded-bounces+atul.sabharwal=tek.com@ozlabs.org] On
Behalf Of prabha.j@tcs.com
Sent: Tuesday, March 07, 2006 3:17 AM
To: linuxppc-embedded@ozlabs.org
Subject: help reqd
Hi all ,
I have a driver and when i am doing insmod the driver its giving
unresolved symbol.
insmod: unresolved symbol copy_to_user
insmod: unresolved symbol down
insmod: unresolved symbol up
insmod: unresolved symbol copy_from_user
Can anyone suggest me where i am doing wrong.
I am using linux-2.4.25 kernel from denx and my board is a
customboard(mpc8260 processor).
This is a upm driver and built as a loadable module.
Please help me in this regard
Thanks in advance.
Regards
Prabha J.
Tata Consultancy Services Limited
Mailto: prabha.j@tcs.com
Website: http://www.tcs.com
Notice: The information contained in this e-mail message and/or
attachments to it may contain confidential or privileged information. If
you are not the intended recipient, any dissemination, use, review,
distribution, printing or copying of the information contained in this
e-mail message and/or attachments to it are strictly prohibited. If you
have received this communication in error, please notify us by reply
e-mail or telephone and immediately and permanently delete the message
and any attachments. Thank you
[-- Attachment #2: Type: text/html, Size: 7131 bytes --]
^ 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