* [PATCH] alsa/soc: add locking to mpc5200-psc-ac97 driver
From: Grant Likely @ 2009-06-29 23:42 UTC (permalink / raw)
To: jonsmirl, linuxppc-dev, alsa-devel, broonie
From: Grant Likely <grant.likely@secretlab.ca>
AC97 bus register read/write hooks need to provide locking, but the
mpc5200-psc-ac97 driver does not. This patch adds a mutex around
the register access routines.
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
---
sound/soc/fsl/mpc5200_dma.c | 1 +
sound/soc/fsl/mpc5200_dma.h | 1 +
sound/soc/fsl/mpc5200_psc_ac97.c | 17 ++++++++++++++++-
3 files changed, 18 insertions(+), 1 deletions(-)
diff --git a/sound/soc/fsl/mpc5200_dma.c b/sound/soc/fsl/mpc5200_dma.c
index efec33a..f0a2d40 100644
--- a/sound/soc/fsl/mpc5200_dma.c
+++ b/sound/soc/fsl/mpc5200_dma.c
@@ -456,6 +456,7 @@ int mpc5200_audio_dma_create(struct of_device *op)
return -ENODEV;
spin_lock_init(&psc_dma->lock);
+ mutex_init(&psc_dma->mutex);
psc_dma->id = be32_to_cpu(*prop);
psc_dma->irq = irq;
psc_dma->psc_regs = regs;
diff --git a/sound/soc/fsl/mpc5200_dma.h b/sound/soc/fsl/mpc5200_dma.h
index 2000803..8d396bb 100644
--- a/sound/soc/fsl/mpc5200_dma.h
+++ b/sound/soc/fsl/mpc5200_dma.h
@@ -55,6 +55,7 @@ struct psc_dma {
unsigned int irq;
struct device *dev;
spinlock_t lock;
+ struct mutex mutex;
u32 sicr;
uint sysclk;
int imr;
diff --git a/sound/soc/fsl/mpc5200_psc_ac97.c b/sound/soc/fsl/mpc5200_psc_ac97.c
index 794a247..7eb5499 100644
--- a/sound/soc/fsl/mpc5200_psc_ac97.c
+++ b/sound/soc/fsl/mpc5200_psc_ac97.c
@@ -34,13 +34,20 @@ static unsigned short psc_ac97_read(struct snd_ac97 *ac97, unsigned short reg)
int status;
unsigned int val;
+ mutex_lock(&psc_dma->mutex);
+
/* Wait for command send status zero = ready */
status = spin_event_timeout(!(in_be16(&psc_dma->psc_regs->sr_csr.status) &
MPC52xx_PSC_SR_CMDSEND), 100, 0);
if (status == 0) {
pr_err("timeout on ac97 bus (rdy)\n");
+ mutex_unlock(&psc_dma->mutex);
return -ENODEV;
}
+
+ /* Force clear the data valid bit */
+ in_be32(&psc_dma->psc_regs->ac97_data);
+
/* Send the read */
out_be32(&psc_dma->psc_regs->ac97_cmd, (1<<31) | ((reg & 0x7f) << 24));
@@ -50,16 +57,19 @@ static unsigned short psc_ac97_read(struct snd_ac97 *ac97, unsigned short reg)
if (status == 0) {
pr_err("timeout on ac97 read (val) %x\n",
in_be16(&psc_dma->psc_regs->sr_csr.status));
+ mutex_unlock(&psc_dma->mutex);
return -ENODEV;
}
/* Get the data */
val = in_be32(&psc_dma->psc_regs->ac97_data);
if (((val >> 24) & 0x7f) != reg) {
pr_err("reg echo error on ac97 read\n");
+ mutex_unlock(&psc_dma->mutex);
return -ENODEV;
}
val = (val >> 8) & 0xffff;
+ mutex_unlock(&psc_dma->mutex);
return (unsigned short) val;
}
@@ -68,16 +78,21 @@ static void psc_ac97_write(struct snd_ac97 *ac97,
{
int status;
+ mutex_lock(&psc_dma->mutex);
+
/* Wait for command status zero = ready */
status = spin_event_timeout(!(in_be16(&psc_dma->psc_regs->sr_csr.status) &
MPC52xx_PSC_SR_CMDSEND), 100, 0);
if (status == 0) {
pr_err("timeout on ac97 bus (write)\n");
- return;
+ goto out;
}
/* Write data */
out_be32(&psc_dma->psc_regs->ac97_cmd,
((reg & 0x7f) << 24) | (val << 8));
+
+ out:
+ mutex_unlock(&psc_dma->mutex);
}
static void psc_ac97_warm_reset(struct snd_ac97 *ac97)
^ permalink raw reply related
* Re: Can't boot 2.6.30 powerpc kernel under qemu.
From: Rob Landley @ 2009-06-29 23:34 UTC (permalink / raw)
To: Jeremy Kerr, linuxppc-dev; +Cc: linux-kernel
In-Reply-To: <200906281033.09842.jk@ozlabs.org>
On Saturday 27 June 2009 21:33:09 Jeremy Kerr wrote:
> Hi Rob,
>
> > I bisected the problem in the linux kernel repository, and wound up
> > here:
> >
> > 60ee031940c1b09c137b617a8829e2f081961fe0 is first bad commit
> > commit 60ee031940c1b09c137b617a8829e2f081961fe0
> > Author: Jeremy Kerr <jk@ozlabs.org>
> > Date: Tue Feb 17 11:44:14 2009 +1100
> >
> > powerpc/spufs: Use correct return value for spu_handle_mm_fault
>
> I think it's very unlikely that this commit would be causing the
> problem, as qemu doesn't have any SPEs (they're specific to the Cell
> architecture), which would be required to hit this code. Also, you're
> not compiling with CONFIG_SPU_BASE, so the file that this changed
> shouldn't even be built.
Yeah, it seemed odd. That's why I needed help. :)
> Perhaps try the bisect again?
Sorry about that. I suck at git.
Part of the reason is that git bisect assumes that "good" always comes before
"bad" in the repository, so if you're looking for the patch that _fixed_ a bug
(I.E. good == new and bad == old), you have to reverse 'em to humor git
bisect. I had to do that this time to patch an intermediate version that
build breaks, which "git bisect run" called "skip" on over a dozen times
without noticeable progress. If good and bad then mean the opposite on the
_next_ bisect, I tend to get 'em confused occasionally. (Especially when I've
hit three or more unrelated bugs in the same bisect run. In this case the
build break in kmap_atomic_prot, whatever memory glitch is corrupting the
squashfs root filesystem image and spamming the console about it, and this bug.
Oh, and the really _fun_ part is that the squashfs bug only reproduces about
half the time. If you run the same binary twice, sometimes it'll work and
sometimes it'll spam squashfs errors to the console. Wheee...)
Anyway, on something like my fifth attempt I managed to bisect it to:
28794d34ecb6815a3fa0a4256027c9b081a17c5f is first bad commit
commit 28794d34ecb6815a3fa0a4256027c9b081a17c5f
Author: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Date: Tue Mar 10 17:53:27 2009 +0000
powerpc/kconfig: Kill PPC_MULTIPLATFORM
CONFIG_PPC_MULTIPLATFORM is a remain of the pre-powerpc days and isn't
really meaningful anymore. It was basically equivalent to PPC64 || 6xx.
This removes it along with the following changes:
- 32-bit platforms that relied on PPC32 && PPC_MULTIPLATFORM now rely
on 6xx which is what they want anyway.
- A new symbol, PPC_BOOK3S, is defined that represent compliance with
the "Server" variant of the architecture. This is set when either 6xx
or PPC64 is set and open the door for future BOOK3E 64-bit.
- 64-bit platforms that relied on PPC64 && PPC_MULTIPLATFORM now use
PPC64 && PPC_BOOK3S
- A separate and selectable CONFIG_PPC_OF_BOOT_TRAMPOLINE option is now
used to control the use of prom_init.c
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Which suggested that the problem was the new CONFIG_PPC_OF_BOOT_TRAMPOLINE
symbol wasn't set, and once I switched that on it started working again.
> linuxppc-dev@lists.ozlabs.org is the one you want for this:
>
> https://lists.ozlabs.org/listinfo/linuxppc-dev
Cool! Is there a reason it's hidden? (Or at least not listed in either
vger.kernel.org's list info page or in the "Maling lists" page linked from
ozlabs.org's top level web page.) Just curious, I couldn't find it when I
looked in the obvious (to me) places.
Rob
P.S. Yes I tried google: top hit for "linux powerpc list" is penguinppc.org,
which links to mailing lists on the right which is the ozlabs.org page that
doesn't list linuxppc-dev. In fact the entire first page of google hits for
that search doesn't give a hint of the existence of that list, although some
of the later ones might if I clicked through more of them...
--
Latency is more important than throughput. It's that simple. - Linus Torvalds
^ permalink raw reply
* [PATCH] powerpc: Fix spin_event_timeout() to be robust over context switches
From: Grant Likely @ 2009-06-29 23:40 UTC (permalink / raw)
To: linuxppc-dev, linux-kernel, timur, jonsmirl
From: Grant Likely <grant.likely@secretlab.ca>
Current implementation of spin_event_timeout can be interrupted by an
IRQ or context switch after testing the condition, but before checking
the timeout. This can cause the loop to report a timeout when the
condition actually became true in the middle.
This patch adds one final check of the condition upon exit of the loop
if the last test of the condition was still false.
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
---
arch/powerpc/include/asm/delay.h | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/include/asm/delay.h b/arch/powerpc/include/asm/delay.h
index 1e2eb41..52e4d54 100644
--- a/arch/powerpc/include/asm/delay.h
+++ b/arch/powerpc/include/asm/delay.h
@@ -63,6 +63,8 @@ extern void udelay(unsigned long usecs);
udelay(delay); \
else \
cpu_relax(); \
+ if (!__ret) \
+ __ret = (condition); \
__ret; \
})
^ permalink raw reply related
* Re: Inline Assembly queries
From: Ian Lance Taylor @ 2009-06-29 21:29 UTC (permalink / raw)
To: kernel mailz; +Cc: gcc-help, linuxppc-dev
In-Reply-To: <abe8a1fd0906290849w1ba6bd33of60a9c2e110c10fd@mail.gmail.com>
kernel mailz <kernelmailz@googlemail.com> writes:
> I tried a small example
>
> int *p = 0x1000;
> int a = *p;
> asm("sync":::"memory");
> a = *p;
>
> and
>
> volatile int *p = 0x1000;
> int a = *p;
> asm("sync");
> a = *p
>
> Got the same assembly.
> Which is right.
>
> So does it mean, if proper use of volatile is done, there is no need
> of "memory" ?
You have to consider the effects of inlining, which may bring in other
memory loads and stores through non-volatile pointers.
Ian
^ permalink raw reply
* Re: Inline Assembly queries
From: Ian Lance Taylor @ 2009-06-29 21:27 UTC (permalink / raw)
To: David Howells; +Cc: gcc-help, linuxppc-dev, kernel mailz
In-Reply-To: <30098.1246291036@redhat.com>
David Howells <dhowells@redhat.com> writes:
> kernel mailz <kernelmailz@googlemail.com> wrote:
>
>> asm("sync");
>
> Isn't gcc free to discard this as it has no dependencies, no indicated side
> effects, and isn't required to be kept? I think this should probably be:
>
> asm volatile("sync");
An asm with no outputs is considered to be volatile.
Ian
^ permalink raw reply
* Re: Trouble "Transferring control to Linux (at address 00000000)"
From: Scott Wood @ 2009-06-29 21:03 UTC (permalink / raw)
To: Mikhail Zaturenskiy; +Cc: Frank Svendsbøe, linuxppc-dev, Gary Thomas
In-Reply-To: <97dd5fd20906291346s3ee60edbr1863c27280ae373c@mail.gmail.com>
Mikhail Zaturenskiy wrote:
>
> Seems like at that point it begins to redirect output to ttyCPM0 but
> still nothing showing on the console...
Check the clock-frequency of the CPM BRG node. If u-boot isn't setting
the memory, it's probably not setting this either.
If you're not up to the task of fixing u-boot to fill in the device
tree, you may want to try cuImage.
-Scott
^ permalink raw reply
* Re: Trouble "Transferring control to Linux (at address 00000000)"
From: Mikhail Zaturenskiy @ 2009-06-29 20:46 UTC (permalink / raw)
To: Scott Wood; +Cc: Frank Svendsbøe, linuxppc-dev, Gary Thomas
In-Reply-To: <4A49249C.5080101@freescale.com>
> Change "root=" to "console=".
Thank you for clarifying.
I tried this but I get the following in my memory dump:
<6>Using Embedded Planet EP88xC ??achine description?
<5>Linux ver??ion 2.6.30-rc2-01402-gd4e2f68-d??rty
(devone@localhost.localdoma??n) (gcc version 4.2.2) #1 Mon J??n 29
11:35:28 CDT 2009?
<7>Top o?? RAM: 0x4000000' Total RAM: 0x4??00000?
<7>Memory hole size: 0MB???
>4>Zone PFN ranges:?
<4> DMA ?? 0x00000000 -> 0x00004000?
<4> ??ormal 0x00004000 -> 0x0000400???
<4>Movable zone start PFN for ??ach node?
<4>early_node_map[1] a??tive PFN ranges?
<4> 0: 0x000??0000 -> 0x00004000?
<7>On node 0??totalpages: 16384?
<7>free_area_??nit_node: node 0' pgdat c021bf7??' node_mem_map c023f000?
<7> DM?? zone: 128 pages used for memma???
<7> DMA zone: 0 pages reserve???
<7> DMA zone: 16256 pages' LI??O batch:3?
<6>MMU: Allocated 72 ??ytes of context maps for 16 con??exts?
<4>Built 1 zonelists in Zo??e order' mobility grouping on. ??Total pages: 16256?
<5>Kernel co??mand line: console=ttyCPM0'9600??8 loglevel=7?
<6>NR_IRQS:512?
<7>??rq: irq 5 on host /soc@f0000000??interrupt-controller@0 mapped
t?? virtual irq 16?
<7>irq: irq 0 o?? host /soc@f0000000/cpm@9c0/int??rrupt-controller@930
mapped to ??irtual irq 17?
<4>PID hash table??entries: 256 (order: 8' 1024 by??es)?
<4>Decrementer Frequency = ??x7bfa48?
<7>irq: irq 15 on host ??soc@f0000000/interrupt-controll??r@0 mapped
to virtual irq 18?
<7??time_init: decrementer frequenc?? = 8.125000 MHz?
<7>time_init: p??ocessor frequency = 130.00000?? MHz?
<6>clocksource: timebase m??lt[1ec4ec4f] shift[22] register??d?
<7>clockevent: decrementer mu??t[214] shift[16] cpu[0]?
<7>irq:??irq 4 on host /soc@f0000000/cpm??9c0/interrupt-controller@930
ma??ped to virtual irq 19?
<6>consol?? [ttyCPM0] enabled
Seems like at that point it begins to redirect output to ttyCPM0 but
still nothing showing on the console...
^ permalink raw reply
* Re: Trouble "Transferring control to Linux (at address 00000000)"
From: Scott Wood @ 2009-06-29 20:31 UTC (permalink / raw)
To: Mikhail Zaturenskiy; +Cc: Frank Svendsbøe, linuxppc-dev, Gary Thomas
In-Reply-To: <97dd5fd20906291324jf085addjaa61ff48dfca3d04@mail.gmail.com>
Mikhail Zaturenskiy wrote:
> Hi Scott,
>
>> s/root=/console=/
> I'm not quite sure what you mean by this.
Change "root=" to "console=".
-Scott
^ permalink raw reply
* Re: Trouble "Transferring control to Linux (at address 00000000)"
From: Mikhail Zaturenskiy @ 2009-06-29 20:24 UTC (permalink / raw)
To: Scott Wood; +Cc: Frank Svendsbøe, linuxppc-dev, Gary Thomas
In-Reply-To: <4A490AE4.7000509@freescale.com>
Hi Scott,
> s/root=/console=/
I'm not quite sure what you mean by this.
> Alternatively, you can set /chosen/linux,stdout-path to poin to the serial
> node you want to use for the console.
If you look at the bottom of ep88xc.dts that I attached with my
previous post, I added the following:
chosen {
linux,stdout-path = "/soc@f0000000/cpm@9c0/serial@a80"; // MZ -
added this 'chosen' section
};
However it did not seem to help, unless I did this wrong... still no
console output.
Thanks,
Mikhail
^ permalink raw reply
* Re: Inline Assembly queries
From: Scott Wood @ 2009-06-29 19:27 UTC (permalink / raw)
To: kernel mailz; +Cc: gcc-help, linuxppc-dev
In-Reply-To: <abe8a1fd0906290849w1ba6bd33of60a9c2e110c10fd@mail.gmail.com>
On Mon, Jun 29, 2009 at 09:19:57PM +0530, kernel mailz wrote:
> I tried a small example
>
> int *p = 0x1000;
> int a = *p;
> asm("sync":::"memory");
> a = *p;
>
> and
>
> volatile int *p = 0x1000;
> int a = *p;
> asm("sync");
> a = *p
>
> Got the same assembly.
> Which is right.
>
> So does it mean, if proper use of volatile is done, there is no need
> of "memory" ?
No. As I understand it, volatile concerns deletion of the asm statement
(if no outputs are used) and reordering with respect to other asm
statements (not sure whether GCC will actually do this), while the memory
clobber concerns optimization of non-asm loads/stores around the asm
statement.
> static inline unsigned long
> __xchg_u32(volatile void *p, unsigned long val)
> {
> unsigned long prev;
>
> __asm__ __volatile__(
>
> "1: lwarx %0,0,%2 \n"
>
> " stwcx. %3,0,%2 \n\
> bne- 1b"
>
> : "=&r" (prev), "+m" (*(volatile unsigned int *)p)
> : "r" (p), "r" (val)
> // :"memory","cc");
>
> return prev;
> }
> #define ADDR 0x1000
> int main()
> {
> __xchg_u32((void*)ADDR, 0x2000);
> __xchg_u32((void*)ADDR, 0x3000);
>
> return 0;
>
> }
>
> Got the same asm, when compiled with O1 , with / without "memory" clobber
This isn't a good test case, because there's nothing other than inline
asm going on in that function for GCC to optimize. Plus, it's generally
not a good idea, when talking about what the compiler is or isn't allowed
to do, to point to a single test case (or even several) and say that it
isn't required because you don't notice a difference. Even if there were
no code at all with which it made a difference with GCC version X, it
could make a difference with GCC version X+1.
-Scott
^ permalink raw reply
* Re: Device tree for c67x00
From: Peter Korsgaard @ 2009-06-29 19:10 UTC (permalink / raw)
To: Jorge Sánchez de Nova; +Cc: Linuxppc-dev
In-Reply-To: <621779fd0906290825i6bdc1e99tf6be68e3de56e9a6@mail.gmail.com>
>>>>> "Jorge" =3D=3D Jorge S=C3=A1nchez de Nova <j.s.denova@gmail.com> writ=
es:
Jorge> Hi,
Jorge> It doesn't work at all since it doesn't load anything. I have
Jorge> looked at the driver and there is apparently no openfirmware
Jorge> support for it, so maybe the dts info won't work without
Jorge> it. Am I wrong? Does this means that the c67x00 needs OF
Jorge> support to work in this configuration? How can I make it
Jorge> otherwise?
Yes, the c67x00 driver doesn't currently have any OF bindings. Either
you can add it, or simply manually create the struct platform_device
in your board file (or scan the DT in your board file and fill in the
correct base address / interrupt number from it).
Remember that arch/powerpc uses virtual interrupt numbers if you're
going to fill in the platform_device by hand.
--=20
Bye, Peter Korsgaard
^ permalink raw reply
* Re: Trouble "Transferring control to Linux (at address 00000000)"
From: Scott Wood @ 2009-06-29 18:41 UTC (permalink / raw)
To: Mikhail Zaturenskiy; +Cc: Frank Svendsbøe, linuxppc-dev, Gary Thomas
In-Reply-To: <97dd5fd20906291113t5ea98285h2db6379ff1a940c@mail.gmail.com>
Mikhail Zaturenskiy wrote:
> Hi Gary
>
>> Did you try 'root=ttyCPM0,9600'?
>
> Gave that a shot just now, doesn't seem to have changed anything other
> than that it now says "VFS: Cannot open root device ttyCMP0,9600" or
> unknown-block(2,0)." But thanks for the suggestion though.
>
> What exactly was this supposed to do? I thought that the "root=" boot
> argument did not play a role in console output of the boot
> information.
s/root=/console=/
Alternatively, you can set /chosen/linux,stdout-path to poin to the
serial node you want to use for the console.
-Scott
^ permalink raw reply
* Re: Trouble "Transferring control to Linux (at address 00000000)"
From: Mikhail Zaturenskiy @ 2009-06-29 18:13 UTC (permalink / raw)
To: Gary Thomas; +Cc: Scott Wood, Frank Svendsbøe, linuxppc-dev
In-Reply-To: <4A4901A8.5010402@mlbassoc.com>
Hi Gary
> Did you try 'root=ttyCPM0,9600'?
Gave that a shot just now, doesn't seem to have changed anything other
than that it now says "VFS: Cannot open root device ttyCMP0,9600" or
unknown-block(2,0)." But thanks for the suggestion though.
What exactly was this supposed to do? I thought that the "root=" boot
argument did not play a role in console output of the boot
information.
^ permalink raw reply
* Re: Trouble "Transferring control to Linux (at address 00000000)"
From: Gary Thomas @ 2009-06-29 18:02 UTC (permalink / raw)
To: Mikhail Zaturenskiy; +Cc: Scott Wood, Frank Svendsbøe, linuxppc-dev
In-Reply-To: <97dd5fd20906291053u1a07c3afla1c2ea0590d01f1e@mail.gmail.com>
Mikhail Zaturenskiy wrote:
> Hi guys, I've been working off your suggestions and here's my update
> on where I'm at now.
>
> For reference, attached are my current
> "linux-2.6-denx/arch/powerpc/boot/dts/ep88xc.dts" and
> "u-boot-2009.03/include/configs/EP88x.h".
>
>> I might be able to help out. Scott's right. According to U-Boots
>> include/configs/EP88x.h,
>> CONFIG_SYS_IMMR is 0xf0000000, but the Linux the ep88xc.dts is
>> referring to an IMMR set
>> to 0xfa200000. Replace every instance of 0xfa20 with 0xf000, and it may work.
> I did notice the IMMR discrepancy and as Frank suggested adjusted the
> 0xfa20xxxx values to 0xf000xxxx in my DTS, though I'm wondering if it
> would be better to have just set my CONFIG_SYS_IMMR to 0xfa200000? Not
> sure if that would break more than it would fix. Anyways, I have not
> noticed any difference in output after changing this in the DTS, but
> I'll leave it this way as it seems more correct.
>
>>>> Also, make sure u-boot is properly updating the memory size in the device
>>>> tree. Can you dump the post-fixup device tree in u-boot?
>>> Not sure, but I'll try to find out if that's possible. It'd certainly
>>> answer a lot of questions...
> While I have not yet figured out how to dump the post-fixup tree... I
> can see that U-Boot doesn't seem to be doing proper fixup because
> after manually setting all the DTS fields that U-Boot was supposed to
> fill in (clock frequency, RAM start/end, etc.), the kernel seems to be
> going through a fairly normal boot sequence. Without me manually
> setting those fields, they remain initialized to 0. The only issue is
> that no output goes to the console.
>
> Here is my current output.
>>From U-Boot:
>
> U-Boot 2009.03-svn8591 (Jun 29 2009 - 11:25:23)
>
> CPU: MPC885ZPnn at 100 MHz [40.0...133.0 MHz]
> 8 kB I-Cache 8 kB D-Cache FEC present
> Board: EP88xC 1.1 CPLD revision 2
> DRAM: 64 MB
> FLASH: 32 MB
> In: serial
> Out: serial
> Err: serial
> Net: FEC ETHERNET, FEC2 ETHERNET
> Hit any key to stop autoboot: 0
> => tftp ep88x_uimage2
> Using FEC ETHERNET device
> TFTP from server 10.0.54.129; our IP address is 10.0.54.150
> Filename 'ep88x_uimage2'.
> Load address: 0x400000
> Loading: #################################################################
> ########
> done
> Bytes transferred = 1057419 (10228b hex)
> => tftp 750000 ep88x_dtb2
> Using FEC ETHERNET device
> TFTP from server 10.0.54.129; our IP address is 10.0.54.150
> Filename 'ep88x_dtb2'.
> Load address: 0x750000
> Loading: #
> done
> Bytes transferred = 7725 (1e2d hex)
> => bootm 400000 - 750000
> ## Booting kernel from Legacy Image at 00400000 ...
> Image Name: Linux-2.6.30-rc2-01402-gd4e2f68-
> Image Type: PowerPC Linux Kernel Image (gzip compressed)
> Data Size: 1057355 Bytes = 1 MB
> Load Address: 00000000
> Entry Point: 00000000
> Verifying Checksum ... OK
> ## Flattened Device Tree blob at 00750000
> Booting using the fdt blob at 0x750000
> Uncompressing Kernel Image ... OK
>
>
>>From Kernel via postmortem analysis - sorry it's a little messy, my
> debugger ICDPPCZ is not that great at producing memory dumps so I had
> to do some cleanup/conversion to make the results at least somewhat
> legible:
>
> <6>Using Embedded Planet EP88xC machine description?
> <5>Linux version 2.6.30-rc2-??1402-gd4e2f68-dirty
> (devone@localhost.localdomain) (gcc version 4.2.2) #1 Mon J??n 29
> 11:35:28 CDT 2009?
> <7>Top of RAM: 0x4000000' Total RAM: 0x4000000?
> <7>Memory??hole size: 0MB?
> <4>Zone PFN ranges:?
> <4> DMA 0x00000000 -> 0x00004000?
> <4> ??ormal 0x00004000 -> 0x00004000?
> <4>Movable zone start PFN for each node?
> <4>ear??y_node_map[1] active PFN ranges?
> <4> 0: 0x00000000 -> 0x00004000?
> <7>On node 0??totalpages: 16384?
> <7>free_area_init_node: node 0' pgdat c021bf7c' node_mem_map ??023f000?
> <7> DMA zone: 128 pages used for memmap?
> <7> DMA zone: 0 pages reserve???
> <7> DMA zone: 16256 pages' LIFO batch:3?
> <6>MMU: Allocated 72 bytes of context??maps for 16 contexts?
> <4>Built 1 zonelists in Zone order' mobility grouping on. ??Total pages: 16256?
> <5>Kernel command line: console=ttyS0'9600n8 loglevel=7?
> <6>N??_IRQS:512?
> <7>irq: irq 5 on host /soc@f0000000/interrupt-controller@0 mapped to
> ??irtual irq 16?
> <7>irq: irq 0 on host /soc@f0000000/cpm@9c0/interrupt-controller@??30
> mapped to virtual irq 17?
> <4>PID hash table entries: 256 (order: 8' 1024 byte??)?
> <4>Decrementer Frequency = 0x7bfa48?
> <7>irq: irq 15 on host /soc@f0000000/inte??rupt-controller@0 mapped to
> virtual irq 18?
> <7>time_init: decrementer frequency ?? 8.125000 MHz?
> <7>time_init: processor frequency = 130.000000 MHz?
> <6>clocksour??e: timebase mult[1ec4ec4f] shift[22] registered?
> <7>clockevent: decrementer mult??214] shift[16] cpu[0]?
> <6>Dentry cache hash table entries: 8192 (order: 3' 32768??bytes)?
> <6>Inode-cache hash table entries: 4096 (order: 2' 16384 bytes)?
> <6>Memor??: 62532k/65536k available (2064k kernel code' 2940k
> reserved' 100k data' 99k bs??' 96k init)?
> <6>SLUB: Genslabs=12' HWalign=16' Order=0-3' MinObjects=0' CPUs=1' ??odes=1?
> <6>Calibrating delay loop... 16.12 BogoMIPS (lpj=80640)?
> <4>Mount-cache h??sh table entries: 512?
> <6>net_namespace: 296 bytes?
> <6>NET: Registered protocol f??mily 16?
> <4>bio: create slab <bio-0> at 0?
> <7>Switched to high resolution mode on??CPU 0?
> <6>NET: Registered protocol family 2?
> <6>IP route cache hash table entries?? 1024 (order: 0' 4096 bytes)?
> <6>TCP established hash table entries: 2048 (order?? 2' 16384 bytes)?
> <6>TCP bind hash table entries: 2048 (order: 1' 8192 bytes)?
> <6??TCP: Hash tables configured (established 2048 bind 2048)?
> <6>TCP reno registered??
> <6>NET: Registered protocol family 1?
> <6>msgmni has been set to 122?
> <6>io schedu??er noop registered?
> <6>io scheduler deadline registered (default)?
> <6>Generic RTC??Driver v1.07?
> <7>irq: irq 4 on host /soc@f0000000/cpm@9c0/interrupt-controller@9??0
> mapped to virtual irq 19?
> <6>f0000a80.serial: ttyCPM0 at MMIO 0xc500ea80 (irq ?? 19) is a CPM UART?
> <7>irq: irq 29 on host /soc@f0000000/cpm@9c0/interrupt-contr??ller@930
> mapped to virtual irq 29?
> <6>f0000a20.serial: ttyCPM1 at MMIO 0xc501aa2?? (irq = 29) is a CPM UART?
> <7>irq: irq 3 on host /soc@f0000000/interrupt-control??er@0 mapped to
> virtual irq 20?
> <6>eth0: fs_enet: 00:00:00:00:00:00?
> <7>irq: irq 7??on host /soc@f0000000/interrupt-controller@0 mapped to
> virtual irq 21?
> <6>eth1: ??s_enet: 00:00:00:00:00:00?
> <6>FEC MII Bus: probed?
> <6>fe000000.flash: Found 2 x16??devices at 0x0 in 32-bit bank?
> <4> Amd/Fujitsu Extended Query Table at 0x0040?
> <4??fe000000.flash: CFI does not contain boot bank location. Assuming top.?
> <5>numbe?? of CFI chips: 1?
> <5>cfi_cmdset_0002: Disabling erase-suspend-program due to cod?? brokenness.?
> <6>TCP cubic registered?
> <6>NET: Registered protocol family 17?
> <6>R??C: Registered udp transport module.?
> <6>RPC: Registered tcp transport module.?
> <3??Root-NFS: No NFS server available' giving up.?
> <3>VFS: Unable to mount root fs v??a NFS' trying floppy.?
> <4>VFS: Cannot open root device "<NULL>" or unknown-block??2'0)?
> <4>Please append a correct "root=" boot option; here are the available
> par??itions:?
> <4>1f00 32768 mtdblock0 driver: of-flash?
> <0>Kernel panic - no?? syncing: VFS: Unable to mount root fs on
> unknown-block(2'0)?
> <4>Call Trace:?
> <4>??c381fed0] [c00069e0] show_stack+0x44/0x16c (unreliable)?
> <4>[c381ff10] [c001bc6c?? panic+0x8c/0x168?
> <4>[c381ff60] [c01ecb80] mount_block_root+0x12c/0x244?
> <4>[c38??ffb0] [c01ecdf4] prepare_namespace+0x4c/0x1c4?
> <4>[c381ffd0] [c01ec1b0] kernel_i??it+0xd0/0xfc?
> <4>[c381fff0] [c000da60] kernel_thread+0x4c/0x68?
> <0>Rebooting in 1??0 seconds..?????????????????????????????????
>
> At this point, my primary goal is to get console output working before
> I do anything else. I've tried different "console=x" boot arguments
> and I've added the "chosen" section to my DTS, but still no output.
> Anyone have suggestions about this? Is something else messed up in my
> DTS?
Did you try 'root=ttyCPM0,9600'?
--
------------------------------------------------------------
Gary Thomas | Consulting for the
MLB Associates | Embedded world
------------------------------------------------------------
^ permalink raw reply
* Re: Trouble "Transferring control to Linux (at address 00000000)"
From: Mikhail Zaturenskiy @ 2009-06-29 17:53 UTC (permalink / raw)
To: Frank Svendsbøe, Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <1ba63b520906271401u5d012b0ex87a48820b616ae48@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 8010 bytes --]
Hi guys, I've been working off your suggestions and here's my update
on where I'm at now.
For reference, attached are my current
"linux-2.6-denx/arch/powerpc/boot/dts/ep88xc.dts" and
"u-boot-2009.03/include/configs/EP88x.h".
> I might be able to help out. Scott's right. According to U-Boots
> include/configs/EP88x.h,
> CONFIG_SYS_IMMR is 0xf0000000, but the Linux the ep88xc.dts is
> referring to an IMMR set
> to 0xfa200000. Replace every instance of 0xfa20 with 0xf000, and it may work.
I did notice the IMMR discrepancy and as Frank suggested adjusted the
0xfa20xxxx values to 0xf000xxxx in my DTS, though I'm wondering if it
would be better to have just set my CONFIG_SYS_IMMR to 0xfa200000? Not
sure if that would break more than it would fix. Anyways, I have not
noticed any difference in output after changing this in the DTS, but
I'll leave it this way as it seems more correct.
>>> Also, make sure u-boot is properly updating the memory size in the device
>>> tree. Can you dump the post-fixup device tree in u-boot?
>> Not sure, but I'll try to find out if that's possible. It'd certainly
>> answer a lot of questions...
While I have not yet figured out how to dump the post-fixup tree... I
can see that U-Boot doesn't seem to be doing proper fixup because
after manually setting all the DTS fields that U-Boot was supposed to
fill in (clock frequency, RAM start/end, etc.), the kernel seems to be
going through a fairly normal boot sequence. Without me manually
setting those fields, they remain initialized to 0. The only issue is
that no output goes to the console.
Here is my current output.
>From U-Boot:
U-Boot 2009.03-svn8591 (Jun 29 2009 - 11:25:23)
CPU: MPC885ZPnn at 100 MHz [40.0...133.0 MHz]
8 kB I-Cache 8 kB D-Cache FEC present
Board: EP88xC 1.1 CPLD revision 2
DRAM: 64 MB
FLASH: 32 MB
In: serial
Out: serial
Err: serial
Net: FEC ETHERNET, FEC2 ETHERNET
Hit any key to stop autoboot: 0
=> tftp ep88x_uimage2
Using FEC ETHERNET device
TFTP from server 10.0.54.129; our IP address is 10.0.54.150
Filename 'ep88x_uimage2'.
Load address: 0x400000
Loading: #################################################################
########
done
Bytes transferred = 1057419 (10228b hex)
=> tftp 750000 ep88x_dtb2
Using FEC ETHERNET device
TFTP from server 10.0.54.129; our IP address is 10.0.54.150
Filename 'ep88x_dtb2'.
Load address: 0x750000
Loading: #
done
Bytes transferred = 7725 (1e2d hex)
=> bootm 400000 - 750000
## Booting kernel from Legacy Image at 00400000 ...
Image Name: Linux-2.6.30-rc2-01402-gd4e2f68-
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 1057355 Bytes = 1 MB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
## Flattened Device Tree blob at 00750000
Booting using the fdt blob at 0x750000
Uncompressing Kernel Image ... OK
>From Kernel via postmortem analysis - sorry it's a little messy, my
debugger ICDPPCZ is not that great at producing memory dumps so I had
to do some cleanup/conversion to make the results at least somewhat
legible:
<6>Using Embedded Planet EP88xC machine description?
<5>Linux version 2.6.30-rc2-??1402-gd4e2f68-dirty
(devone@localhost.localdomain) (gcc version 4.2.2) #1 Mon J??n 29
11:35:28 CDT 2009?
<7>Top of RAM: 0x4000000' Total RAM: 0x4000000?
<7>Memory??hole size: 0MB?
<4>Zone PFN ranges:?
<4> DMA 0x00000000 -> 0x00004000?
<4> ??ormal 0x00004000 -> 0x00004000?
<4>Movable zone start PFN for each node?
<4>ear??y_node_map[1] active PFN ranges?
<4> 0: 0x00000000 -> 0x00004000?
<7>On node 0??totalpages: 16384?
<7>free_area_init_node: node 0' pgdat c021bf7c' node_mem_map ??023f000?
<7> DMA zone: 128 pages used for memmap?
<7> DMA zone: 0 pages reserve???
<7> DMA zone: 16256 pages' LIFO batch:3?
<6>MMU: Allocated 72 bytes of context??maps for 16 contexts?
<4>Built 1 zonelists in Zone order' mobility grouping on. ??Total pages: 16256?
<5>Kernel command line: console=ttyS0'9600n8 loglevel=7?
<6>N??_IRQS:512?
<7>irq: irq 5 on host /soc@f0000000/interrupt-controller@0 mapped to
??irtual irq 16?
<7>irq: irq 0 on host /soc@f0000000/cpm@9c0/interrupt-controller@??30
mapped to virtual irq 17?
<4>PID hash table entries: 256 (order: 8' 1024 byte??)?
<4>Decrementer Frequency = 0x7bfa48?
<7>irq: irq 15 on host /soc@f0000000/inte??rupt-controller@0 mapped to
virtual irq 18?
<7>time_init: decrementer frequency ?? 8.125000 MHz?
<7>time_init: processor frequency = 130.000000 MHz?
<6>clocksour??e: timebase mult[1ec4ec4f] shift[22] registered?
<7>clockevent: decrementer mult??214] shift[16] cpu[0]?
<6>Dentry cache hash table entries: 8192 (order: 3' 32768??bytes)?
<6>Inode-cache hash table entries: 4096 (order: 2' 16384 bytes)?
<6>Memor??: 62532k/65536k available (2064k kernel code' 2940k
reserved' 100k data' 99k bs??' 96k init)?
<6>SLUB: Genslabs=12' HWalign=16' Order=0-3' MinObjects=0' CPUs=1' ??odes=1?
<6>Calibrating delay loop... 16.12 BogoMIPS (lpj=80640)?
<4>Mount-cache h??sh table entries: 512?
<6>net_namespace: 296 bytes?
<6>NET: Registered protocol f??mily 16?
<4>bio: create slab <bio-0> at 0?
<7>Switched to high resolution mode on??CPU 0?
<6>NET: Registered protocol family 2?
<6>IP route cache hash table entries?? 1024 (order: 0' 4096 bytes)?
<6>TCP established hash table entries: 2048 (order?? 2' 16384 bytes)?
<6>TCP bind hash table entries: 2048 (order: 1' 8192 bytes)?
<6??TCP: Hash tables configured (established 2048 bind 2048)?
<6>TCP reno registered??
<6>NET: Registered protocol family 1?
<6>msgmni has been set to 122?
<6>io schedu??er noop registered?
<6>io scheduler deadline registered (default)?
<6>Generic RTC??Driver v1.07?
<7>irq: irq 4 on host /soc@f0000000/cpm@9c0/interrupt-controller@9??0
mapped to virtual irq 19?
<6>f0000a80.serial: ttyCPM0 at MMIO 0xc500ea80 (irq ?? 19) is a CPM UART?
<7>irq: irq 29 on host /soc@f0000000/cpm@9c0/interrupt-contr??ller@930
mapped to virtual irq 29?
<6>f0000a20.serial: ttyCPM1 at MMIO 0xc501aa2?? (irq = 29) is a CPM UART?
<7>irq: irq 3 on host /soc@f0000000/interrupt-control??er@0 mapped to
virtual irq 20?
<6>eth0: fs_enet: 00:00:00:00:00:00?
<7>irq: irq 7??on host /soc@f0000000/interrupt-controller@0 mapped to
virtual irq 21?
<6>eth1: ??s_enet: 00:00:00:00:00:00?
<6>FEC MII Bus: probed?
<6>fe000000.flash: Found 2 x16??devices at 0x0 in 32-bit bank?
<4> Amd/Fujitsu Extended Query Table at 0x0040?
<4??fe000000.flash: CFI does not contain boot bank location. Assuming top.?
<5>numbe?? of CFI chips: 1?
<5>cfi_cmdset_0002: Disabling erase-suspend-program due to cod?? brokenness.?
<6>TCP cubic registered?
<6>NET: Registered protocol family 17?
<6>R??C: Registered udp transport module.?
<6>RPC: Registered tcp transport module.?
<3??Root-NFS: No NFS server available' giving up.?
<3>VFS: Unable to mount root fs v??a NFS' trying floppy.?
<4>VFS: Cannot open root device "<NULL>" or unknown-block??2'0)?
<4>Please append a correct "root=" boot option; here are the available
par??itions:?
<4>1f00 32768 mtdblock0 driver: of-flash?
<0>Kernel panic - no?? syncing: VFS: Unable to mount root fs on
unknown-block(2'0)?
<4>Call Trace:?
<4>??c381fed0] [c00069e0] show_stack+0x44/0x16c (unreliable)?
<4>[c381ff10] [c001bc6c?? panic+0x8c/0x168?
<4>[c381ff60] [c01ecb80] mount_block_root+0x12c/0x244?
<4>[c38??ffb0] [c01ecdf4] prepare_namespace+0x4c/0x1c4?
<4>[c381ffd0] [c01ec1b0] kernel_i??it+0xd0/0xfc?
<4>[c381fff0] [c000da60] kernel_thread+0x4c/0x68?
<0>Rebooting in 1??0 seconds..?????????????????????????????????
At this point, my primary goal is to get console output working before
I do anything else. I've tried different "console=x" boot arguments
and I've added the "chosen" section to my DTS, but still no output.
Anyone have suggestions about this? Is something else messed up in my
DTS?
Thanks,
Mikhail Zaturenskiy
[-- Attachment #2: ep88xc.dts --]
[-- Type: application/octet-stream, Size: 5101 bytes --]
/*
* EP88xC Device Tree Source
*
* Copyright 2006 MontaVista Software, Inc.
* Copyright 2007,2008 Freescale Semiconductor, Inc.
*
* 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
* Free Software Foundation; either version 2 of the License, or (at your
* option) any later version.
*/
/dts-v1/;
/ {
model = "EP88xC";
compatible = "fsl,ep88xc";
#address-cells = <1>;
#size-cells = <1>;
cpus {
#address-cells = <1>;
#size-cells = <0>;
PowerPC,885@0 {
device_type = "cpu";
reg = <0x0>;
d-cache-line-size = <16>;
i-cache-line-size = <16>;
d-cache-size = <8192>;
i-cache-size = <8192>;
timebase-frequency = <8000000>; // MZ - was 0
bus-frequency = <50000000>; // MZ - was 0
clock-frequency = <130000000>; // MZ - was 0,
interrupts = <15 2>; // decrementer interrupt
interrupt-parent = <&PIC>;
};
};
memory {
device_type = "memory";
reg = <0x0 0x04000000>; // MZ - was <0x0 0x0>
};
localbus@f0000100 { // MZ - was fa20xxxx
compatible = "fsl,mpc885-localbus", "fsl,pq1-localbus";
#address-cells = <2>;
#size-cells = <1>;
reg = <0xf0000100 0x40>; // MZ - was fa20xxxx
ranges = <
0x0 0x0 0xfc000000 0x4000000
0x3 0x0 0xfa000000 0x1000000
>;
flash@0,2000000 {
compatible = "cfi-flash";
reg = <0x0 0x2000000 0x2000000>;
bank-width = <4>;
device-width = <2>;
};
board-control@3,400000 {
reg = <0x3 0x400000 0x10>;
compatible = "fsl,ep88xc-bcsr";
};
};
soc@f0000000 { // MZ - was fa20xxxx
compatible = "fsl,mpc885", "fsl,pq1-soc";
#address-cells = <1>;
#size-cells = <1>;
device_type = "soc";
ranges = <0x0 0xf0000000 0x4000>; // MZ - was fa20xxxx
bus-frequency = <0>;
// Temporary -- will go away once kernel uses ranges for get_immrbase().
reg = <0xf0000000 0x4000>; // MZ - was fa20xxxx
mdio@e00 {
compatible = "fsl,mpc885-fec-mdio", "fsl,pq1-fec-mdio";
reg = <0xe00 0x188>;
#address-cells = <1>;
#size-cells = <0>;
PHY0: ethernet-phy@0 {
reg = <0x0>;
device_type = "ethernet-phy";
};
PHY1: ethernet-phy@1 {
reg = <0x1>;
device_type = "ethernet-phy";
};
};
ethernet@e00 {
device_type = "network";
compatible = "fsl,mpc885-fec-enet",
"fsl,pq1-fec-enet";
reg = <0xe00 0x188>;
local-mac-address = [ 00 00 00 00 00 00 ];
interrupts = <3 1>;
interrupt-parent = <&PIC>;
phy-handle = <&PHY0>;
linux,network-index = <0>;
};
ethernet@1e00 {
device_type = "network";
compatible = "fsl,mpc885-fec-enet",
"fsl,pq1-fec-enet";
reg = <0x1e00 0x188>;
local-mac-address = [ 00 00 00 00 00 00 ];
interrupts = <7 1>;
interrupt-parent = <&PIC>;
phy-handle = <&PHY1>;
linux,network-index = <1>;
};
PIC: interrupt-controller@0 {
interrupt-controller;
#interrupt-cells = <2>;
reg = <0x0 0x24>;
compatible = "fsl,mpc885-pic", "fsl,pq1-pic";
};
pcmcia@80 {
#address-cells = <3>;
#interrupt-cells = <1>;
#size-cells = <2>;
compatible = "fsl,pq-pcmcia";
device_type = "pcmcia";
reg = <0x80 0x80>;
interrupt-parent = <&PIC>;
interrupts = <13 1>;
};
cpm@9c0 {
#address-cells = <1>;
#size-cells = <1>;
compatible = "fsl,mpc885-cpm", "fsl,cpm1";
command-proc = <0x9c0>;
interrupts = <0>; // cpm error interrupt
interrupt-parent = <&CPM_PIC>;
reg = <0x9c0 0x40>;
ranges;
muram@2000 {
#address-cells = <1>;
#size-cells = <1>;
ranges = <0x0 0x2000 0x2000>;
data@0 {
compatible = "fsl,cpm-muram-data";
reg = <0x0 0x1c00>;
};
};
brg@9f0 {
compatible = "fsl,mpc885-brg",
"fsl,cpm1-brg",
"fsl,cpm-brg";
reg = <0x9f0 0x10>;
};
CPM_PIC: interrupt-controller@930 {
interrupt-controller;
#interrupt-cells = <1>;
interrupts = <5 2 0 2>;
interrupt-parent = <&PIC>;
reg = <0x930 0x20>;
compatible = "fsl,mpc885-cpm-pic",
"fsl,cpm1-pic";
};
// MON-1
serial@a80 {
device_type = "serial";
compatible = "fsl,mpc885-smc-uart",
"fsl,cpm1-smc-uart";
reg = <0xa80 0x10 0x3e80 0x40>;
interrupts = <4>;
interrupt-parent = <&CPM_PIC>;
fsl,cpm-brg = <1>;
fsl,cpm-command = <0x90>;
linux,planetcore-label = "SMC1";
};
// SER-1
serial@a20 {
device_type = "serial";
compatible = "fsl,mpc885-scc-uart",
"fsl,cpm1-scc-uart";
reg = <0xa20 0x20 0x3d00 0x80>;
interrupts = <29>;
interrupt-parent = <&CPM_PIC>;
fsl,cpm-brg = <2>;
fsl,cpm-command = <0x40>;
linux,planetcore-label = "SCC2";
};
usb@a00 {
#address-cells = <1>;
#size-cells = <0>;
compatible = "fsl,mpc885-usb",
"fsl,cpm1-usb";
reg = <0xa00 0x18 0x1c00 0x80>;
interrupt-parent = <&CPM_PIC>;
interrupts = <30>;
fsl,cpm-command = <0000>;
};
};
};
chosen {
linux,stdout-path = "/soc@f0000000/cpm@9c0/serial@a80"; // MZ - added this 'chosen' section
};
};
[-- Attachment #3: EP88x.h --]
[-- Type: application/octet-stream, Size: 8237 bytes --]
/*
* Copyright (C) 2005 Arabella Software Ltd.
* Yuli Barcohen <yuli@arabellasw.com>
*
* Support for Embedded Planet EP88x boards.
* Tested on EP88xC with MPC885 CPU, 64MB SDRAM and 16MB flash.
*
* See file CREDITS for list of people who contributed to this
* project.
*
* 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 Free Software Foundation; either version 2 of
* the License, or (at your option) any later version.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License
* along with this program; if not, write to the Free Software
* Foundation, Inc., 59 Temple Place, Suite 330, Boston,
* MA 02111-1307 USA
*/
#ifndef __CONFIG_H
#define __CONFIG_H
//#define DEBUG // MZ
#define CONFIG_OF_LIBFDT // MZ - added to support FDT, suggested by Detlev
#define CONFIG_MPC885
#define CONFIG_EP88X /* Embedded Planet EP88x board */
#define CONFIG_BOARD_EARLY_INIT_F /* Call board_early_init_f */
/* Allow serial number (serial#) and MAC address (ethaddr) to be overwritten */
#define CONFIG_ENV_OVERWRITE
#define CONFIG_8xx_CONS_SMC1 1 /* Console is on SMC1 */
#define CONFIG_BAUDRATE 9600
#define CONFIG_ETHER_ON_FEC1 /* Enable Ethernet on FEC1 */
#define CONFIG_ETHER_ON_FEC2 /* Enable Ethernet on FEC2 */
#if defined(CONFIG_ETHER_ON_FEC1) || defined(CONFIG_ETHER_ON_FEC2)
#define CONFIG_SYS_DISCOVER_PHY
#define CONFIG_MII_INIT 1
#define FEC_ENET
#endif /* CONFIG_FEC_ENET */
#define CONFIG_8xx_OSCLK 10000000 /* 10 MHz oscillator on EXTCLK */
#define CONFIG_8xx_CPUCLK_DEFAULT 100000000
#define CONFIG_SYS_8xx_CPUCLK_MIN 40000000
#define CONFIG_SYS_8xx_CPUCLK_MAX 133000000
/*
* BOOTP options
*/
#define CONFIG_BOOTP_BOOTFILESIZE
#define CONFIG_BOOTP_BOOTPATH
#define CONFIG_BOOTP_GATEWAY
#define CONFIG_BOOTP_HOSTNAME
/*
* Command line configuration.
*/
#include <config_cmd_default.h>
#define CONFIG_CMD_DHCP
#define CONFIG_CMD_IMMAP
#define CONFIG_CMD_MII
#define CONFIG_CMD_PING
//#define CONFIG_BOOTDELAY 5 /* Autoboot after 5 seconds */
#define CONFIG_BOOTDELAY 15 /* MZ - Autoboot after 15 seconds */
//#define CONFIG_BOOTCOMMAND "bootm fe060000" /* Autoboot command */
#define CONFIG_BOOTCOMMAND "bootm fc080000" /* MZ - Autoboot command */
//#define CONFIG_BOOTARGS "root=/dev/mtdblock1 rw mtdparts=phys:2M(ROM)ro,-(root)"
#define CONFIG_BOOTARGS "console=ttyS0,9600n8 loglevel=7" // MZ
#define CONFIG_BZIP2 /* Include support for bzip2 compressed images */
#undef CONFIG_WATCHDOG /* Disable platform specific watchdog */
/*-----------------------------------------------------------------------
* Miscellaneous configurable options
*/
#define CONFIG_SYS_PROMPT "=> " /* Monitor Command Prompt */
#define CONFIG_SYS_HUSH_PARSER
#define CONFIG_SYS_PROMPT_HUSH_PS2 "> "
#define CONFIG_SYS_LONGHELP /* #undef to save memory */
#define CONFIG_SYS_CBSIZE 256 /* Console I/O Buffer Size */
#define CONFIG_SYS_PBSIZE (CONFIG_SYS_CBSIZE + sizeof(CONFIG_SYS_PROMPT) + 16) /* Print Buffer Size */
#define CONFIG_SYS_MAXARGS 16 /* Max number of command args */
#define CONFIG_SYS_BARGSIZE CONFIG_SYS_CBSIZE /* Boot Argument Buffer Size */
#define CONFIG_SYS_LOAD_ADDR 0x400000 /* Default load address */
#define CONFIG_SYS_HZ 1000 /* Decrementer freq: 1 ms ticks */
#define CONFIG_SYS_BAUDRATE_TABLE { 9600, 19200, 38400, 57600, 115200 }
/*-----------------------------------------------------------------------
* RAM configuration (note that CONFIG_SYS_SDRAM_BASE must be zero)
*/
#define CONFIG_SYS_SDRAM_BASE 0x00000000
//#define CONFIG_SYS_SDRAM_MAX_SIZE 0x08000000 /* Up to 128 Mbyte */
#define CONFIG_SYS_SDRAM_MAX_SIZE 0x04000000 /* MZ - Up to 64 Mbyte */
#define CONFIG_SYS_MAMR 0x00805000
/*
* 4096 Up to 4096 SDRAM rows
* 1000 factor s -> ms
* 32 PTP (pre-divider from MPTPR)
* 4 Number of refresh cycles per period
* 64 Refresh cycle in ms per number of rows
*/
#define CONFIG_SYS_PTA_PER_CLK ((4096 * 32 * 1000) / (4 * 64))
#define CONFIG_SYS_MEMTEST_START 0x00100000 /* memtest works on */
#define CONFIG_SYS_MEMTEST_END 0x00500000 /* 1 ... 5 MB in SDRAM */
#define CONFIG_SYS_RESET_ADDRESS 0x09900000
/*-----------------------------------------------------------------------
* For booting Linux, the board info and command line data
* have to be in the first 8 MB of memory, since this is
* the maximum mapped by the Linux kernel during initialization.
*/
#define CONFIG_SYS_BOOTMAPSZ (8 << 20) /* Initial Memory map for Linux */
#define CONFIG_SYS_MONITOR_BASE TEXT_BASE
#define CONFIG_SYS_MONITOR_LEN (256 << 10) /* Reserve 256 KB for Monitor */
#undef CONFIG_BZIP2 // MZ
#ifdef CONFIG_BZIP2
#define CONFIG_SYS_MALLOC_LEN (4096 << 10) /* Reserve ~4 MB for malloc() */
#else
#define CONFIG_SYS_MALLOC_LEN (128 << 10) /* Reserve 128 KB for malloc() */
#endif /* CONFIG_BZIP2 */
/*-----------------------------------------------------------------------
* Flash organisation
*/
#define CONFIG_SYS_FLASH_BASE 0xFC000000
#define CONFIG_SYS_FLASH_CFI /* The flash is CFI compatible */
#define CONFIG_FLASH_CFI_DRIVER /* Use common CFI driver */
#define CONFIG_SYS_MAX_FLASH_BANKS 1 /* Max number of flash banks */
//#define CONFIG_SYS_MAX_FLASH_SECT 512 /* Max num of sects on one chip */
#define CONFIG_SYS_MAX_FLASH_SECT 128 /* MZ - Max num of sects on one chip */
/* Environment is in flash */
#define CONFIG_ENV_IS_IN_FLASH
//#define CONFIG_ENV_SECT_SIZE 0x20000 /* We use one complete sector */
#define CONFIG_ENV_SECT_SIZE 0x40000 /* MZ - We use one complete sector */
#define CONFIG_ENV_ADDR (CONFIG_SYS_MONITOR_BASE + CONFIG_SYS_MONITOR_LEN)
#define CONFIG_SYS_OR0_PRELIM 0xFC000160
#define CONFIG_SYS_BR0_PRELIM (CONFIG_SYS_FLASH_BASE | BR_PS_32 | BR_MS_GPCM | BR_V)
#define CONFIG_SYS_DIRECT_FLASH_TFTP
/*-----------------------------------------------------------------------
* BCSR
*/
#define CONFIG_SYS_OR3_PRELIM 0xFF0005B0
#define CONFIG_SYS_BR3_PRELIM (0xFA000000 |BR_PS_16 | BR_MS_GPCM | BR_V)
#define CONFIG_SYS_BCSR 0xFA400000
/*-----------------------------------------------------------------------
* Internal Memory Map Register
*/
#define CONFIG_SYS_IMMR 0xF0000000
/*-----------------------------------------------------------------------
* Definitions for initial stack pointer and data area (in DPRAM)
*/
#define CONFIG_SYS_INIT_RAM_ADDR CONFIG_SYS_IMMR
#define CONFIG_SYS_INIT_RAM_END 0x2F00 /* End of used area in DPRAM */
#define CONFIG_SYS_GBL_DATA_SIZE 128 /* Size in bytes reserved for initial data */
#define CONFIG_SYS_GBL_DATA_OFFSET (CONFIG_SYS_INIT_RAM_END - CONFIG_SYS_GBL_DATA_SIZE)
#define CONFIG_SYS_INIT_SP_OFFSET CONFIG_SYS_GBL_DATA_OFFSET
/*-----------------------------------------------------------------------
* Configuration registers
*/
#ifdef CONFIG_WATCHDOG
#define CONFIG_SYS_SYPCR (SYPCR_SWTC | SYPCR_BMT | SYPCR_BME | \
SYPCR_SWF | SYPCR_SWE | SYPCR_SWRI | \
SYPCR_SWP)
#else
#define CONFIG_SYS_SYPCR (SYPCR_SWTC | SYPCR_BMT | SYPCR_BME | \
SYPCR_SWF | SYPCR_SWP)
#endif /* CONFIG_WATCHDOG */
#define CONFIG_SYS_SIUMCR (SIUMCR_MLRC01 | SIUMCR_DBGC11)
/* TBSCR - Time Base Status and Control Register */
#define CONFIG_SYS_TBSCR (TBSCR_TBF | TBSCR_TBE)
/* PISCR - Periodic Interrupt Status and Control */
#define CONFIG_SYS_PISCR PISCR_PS
/* SCCR - System Clock and reset Control Register */
#define SCCR_MASK SCCR_EBDF11
#define CONFIG_SYS_SCCR SCCR_RTSEL
#define CONFIG_SYS_DER 0
/*-----------------------------------------------------------------------
* Cache Configuration
*/
#define CONFIG_SYS_CACHELINE_SIZE 16 /* For all MPC8xx chips */
/*-----------------------------------------------------------------------
* Internal Definitions
*
* Boot Flags
*/
#define BOOTFLAG_COLD 0x01 /* Normal Power-On: Boot from flash */
#define BOOTFLAG_WARM 0x02 /* Software reboot */
#endif /* __CONFIG_H */
^ permalink raw reply
* Re: PCI device support in Open Firmware (device tree syntax)
From: Scott Wood @ 2009-06-29 16:51 UTC (permalink / raw)
To: Johnny Hung; +Cc: kernelnewbies, linuxppc-dev, linux-embedded
In-Reply-To: <cb9ecdfa0906290858x125b8149na037f33258c21426@mail.gmail.com>
On Mon, Jun 29, 2009 at 11:58:22PM +0800, Johnny Hung wrote:
> Hi all,
> I am working in customized Freescale MPC8313 board. There are two
> PCI devices (Broadcom Switch) in PCI bus.
> Each PCI device has its configuration space. It contains
> vendor/product ID (RO)..., and important information, likes BARs
> (Base Address), INT line and IRQ(RW). These resources (BAR, INT, IRQ)
> is assigned from BIOS in x86 arch.
> My problem is how to assign PCI device resources in device tree. I
> can't find exist dts file as an example. I have read the
> http://www.power.org/resources/downloads/Power_ePAPR_APPROVED_v1.0.pdf
> file. It's described detailed about device tree
> except PCI device. So, anyone give me a hint or sany tuff is appreciated.
> I think Linux Kernel parses device tree and get the PCI device
> resources information then write into PCI configuration space.
> So PCI device driver do pci_register_driver (get resource) and do
> itself probe for PCI device. Is it right? CMIIAW
With flat device trees, PCI devices are not typically included as they
can be probed instead. Interrupt mapping is conveyed by the
interrupt-map property in the PCI controller node.
-Scott
^ permalink raw reply
* Re: [PATCH] Add EDAC support for P2020DS
From: Dave Jiang @ 2009-06-29 15:47 UTC (permalink / raw)
To: Yang Shi; +Cc: linuxppc-dev, bluesmoke-devel
In-Reply-To: <1245893976-32678-1-git-send-email-yang.shi@windriver.com>
Acked-by: Dave Jiang <djiang@mvista.com>
Yang Shi wrote:
> Based on Kumar's new compatible types patch, add P2020 into
> MPC85xx EDAC compatible lists so that EDAC can recognize
> P2020 meomry controller and L2 cache controller and export
> the relevant fields to sysfs.
>
> EDAC MPC85xx DDR3 support is needed if DDR3 memory stick is
> installed on a P2020DS board so that EDAC core can recognize
> DDR3 memory type.
>
> Signed-off-by: Yang Shi <yang.shi@windriver.com>
> ---
> (85xx DDR3 EDAC patch is currently in akpm's mm tree)
>
> drivers/edac/mpc85xx_edac.c | 2 ++
> 1 files changed, 2 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/edac/mpc85xx_edac.c b/drivers/edac/mpc85xx_edac.c
> index 7c8c2d7..85575fb 100644
> --- a/drivers/edac/mpc85xx_edac.c
> +++ b/drivers/edac/mpc85xx_edac.c
> @@ -646,6 +646,7 @@ static struct of_device_id mpc85xx_l2_err_of_match[] = {
> { .compatible = "fsl,mpc8560-l2-cache-controller", },
> { .compatible = "fsl,mpc8568-l2-cache-controller", },
> { .compatible = "fsl,mpc8572-l2-cache-controller", },
> + { .compatible = "fsl,p2020-l2-cache-controller", },
> {},
> };
>
> @@ -978,6 +979,7 @@ static struct of_device_id mpc85xx_mc_err_of_match[] = {
> { .compatible = "fsl,mpc8560-memory-controller", },
> { .compatible = "fsl,mpc8568-memory-controller", },
> { .compatible = "fsl,mpc8572-memory-controller", },
> + { .compatible = "fsl,p2020-memory-controller", },
> {},
> };
>
--
------------------------------------------------------
Dave Jiang
Software Engineer
MontaVista Software, Inc.
http://www.mvista.com
------------------------------------------------------
^ permalink raw reply
* Re: [Bugme-new] [Bug 13304] New: ehci_hcd module causing problems in using usb head phone
From: Geoff Levand @ 2009-06-29 16:07 UTC (permalink / raw)
To: Alan Stern; +Cc: linuxppc-dev, USB list, abhishekkumar, bugme-daemon
In-Reply-To: <Pine.LNX.4.44L0.0906262132120.2995-100000@netrider.rowland.org>
On 06/26/2009 06:33 PM, Alan Stern wrote:
> On Fri, 26 Jun 2009, Geoff Levand wrote:
>
>> > Where is the information about the hardware errata you mentioned?
>>
>> Sorry, I should have mentioned it. Unfortunately, that info is not
>> in the public as far as I know. I think only someone with access
>> to those will be able to work on this fix.
>
> Okay, then I guess there's nothing more I can do regarding Bug #13304.
> Can you take it over?
Yes, as I mentioned, it is on my to-do list. I'll bump up the priority
now that there are two users reporting the problem.
-Geoff
^ permalink raw reply
* Re: [PATCH 05/62] arch/powerpc: Remove unnecessary semicolons
From: Geoff Levand @ 2009-06-29 16:01 UTC (permalink / raw)
To: Joe Perches
Cc: trivial, Robert Richter, linux-kernel, linuxppc-dev,
oprofile-list, Andrew Morton, cbe-oss-dev
In-Reply-To: <a55afa18f8b7ba8343072a14d36a2e340e61e816.1246173680.git.joe@perches.com>
On 06/28/2009 09:26 AM, Joe Perches wrote:
> Signed-off-by: Joe Perches <joe@perches.com>
> ---
> arch/powerpc/mm/tlb_hash64.c | 2 +-
> arch/powerpc/oprofile/cell/vma_map.c | 2 +-
> arch/powerpc/platforms/powermac/cpufreq_64.c | 2 +-
> arch/powerpc/platforms/powermac/pic.c | 2 +-
> arch/powerpc/platforms/ps3/system-bus.c | 1 -
> arch/powerpc/sysdev/fsl_rio.c | 2 +-
> arch/powerpc/sysdev/ppc4xx_pci.c | 4 ++--
> 7 files changed, 7 insertions(+), 8 deletions(-)
For ps3/system-bus.c only.
Acked-by: Geoff Levand <geoffrey.levand@am.sony.com>
^ permalink raw reply
* Re: How to implement kexec on e500 ?
From: kernel mailz @ 2009-06-29 16:01 UTC (permalink / raw)
To: wilbur.chan; +Cc: linuxppc-dev
In-Reply-To: <e997b7420906290836u72bd6abbw553df5e77f097349@mail.gmail.com>
Did some searching on the archieve
Looks like this is a old patch
[PATCH 03/10] powerpc: Add kexec support for PPC_85xx platforms
Dale Farnsworth
Thu, 22 Nov 2007 07:51:52 -0800
Is this the patch you were referring to kumar
-TZ
On Mon, Jun 29, 2009 at 9:06 PM, wilbur.chan<wilbur512@gmail.com> wrote:
> Excuse me ,
>
> btw,how to search these patches on this maillist?
>
> through Linuxppc-dev Archives one by one?
>
> Cheers,
>
> wilbur
>
> 2009/6/29, Kumar Gala <galak@kernel.crashing.org>:
>>
>> On Jun 29, 2009, at 8:47 AM, wilbur.chan wrote:
>>
>>> kernel 2.6.21.7
>>>
>>> As we know , kexec stores =A0data =A0for new kernel image , =A0in the f=
orm
>>> of =A0 a page list.
>>>
>>> And kexec uses the physical address of the another =A0page for a
>>> "next-page" pointer.
>>>
>>> However, PowerPC e500 =A0does not allow users to turn off the MMU, so w=
e
>>> can not used physical address directly in our code.
>>>
>>>
>>> Someone suggested that changing =A0relocate_kernel.S to add a TLB 1-to-=
1
>>> mapping of DRAM .
>>>
>>> What does "mapping" mean ?
>>>
>>> Any suggestion to implement kexec on e500 ?
>>
>> Wilbur, kexec has been implemented on e500. =A0There are some patches on
>> the list for this and they just need to be respun and reviewed again.
>>
>> - k
>>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
>
^ permalink raw reply
* PCI device support in Open Firmware (device tree syntax)
From: Johnny Hung @ 2009-06-29 15:58 UTC (permalink / raw)
To: linux-embedded, linuxppc-dev, kernelnewbies, scottwood
Hi all,
I am working in customized Freescale MPC8313 board. There are two
PCI devices (Broadcom Switch) in PCI bus.
Each PCI device has its configuration space. It contains
vendor/product ID (RO)..., and important information, likes BARs
(Base Address), INT line and IRQ(RW). These resources (BAR, INT, IRQ)
is assigned from BIOS in x86 arch.
My problem is how to assign PCI device resources in device tree. I
can't find exist dts file as an example. I have read the
http://www.power.org/resources/downloads/Power_ePAPR_APPROVED_v1.0.pdf
file. It's described detailed about device tree
except PCI device. So, anyone give me a hint or sany tuff is appreciated.
I think Linux Kernel parses device tree and get the PCI device
resources information then write into PCI configuration space.
So PCI device driver do pci_register_driver (get resource) and do
itself probe for PCI device. Is it right? CMIIAW
BRs, H. Johnny
^ permalink raw reply
* Re: Inline Assembly queries
From: David Howells @ 2009-06-29 15:57 UTC (permalink / raw)
To: kernel mailz; +Cc: gcc-help, linuxppc-dev
In-Reply-To: <abe8a1fd0906290849w1ba6bd33of60a9c2e110c10fd@mail.gmail.com>
kernel mailz <kernelmailz@googlemail.com> wrote:
> asm("sync");
Isn't gcc free to discard this as it has no dependencies, no indicated side
effects, and isn't required to be kept? I think this should probably be:
asm volatile("sync");
David
^ permalink raw reply
* Inline Assembly queries
From: kernel mailz @ 2009-06-29 15:49 UTC (permalink / raw)
To: gcc-help, linuxppc-dev
In-Reply-To: <abe8a1fd0906272157j4246e9d3hec2e374535a22c89@mail.gmail.com>
I tried a small example
int *p =3D 0x1000;
int a =3D *p;
asm("sync":::"memory");
a =3D *p;
and
volatile int *p =3D 0x1000;
int a =3D *p;
asm("sync");
a =3D *p
Got the same assembly.
Which is right.
So does it mean, if proper use of volatile is done, there is no need
of "memory" ?
But then why below example of __xchg uses both ?
I am confused!
Anyone has a clue?
-TZ
---------- Forwarded message ----------
From: kernel mailz <kernelmailz@googlemail.com>
Date: Sun, Jun 28, 2009 at 10:27 AM
Subject: Re: Inline Assembly queries
To: Ian Lance Taylor <iant@google.com>
Cc: gcc-help@gcc.gnu.org, linuxppc-dev@ozlabs.org
Thanks Ian,
For the "memory" clobber
I tried with the a function in linux kernel
--
/*
=A0* Atomic exchange
=A0*
=A0* Changes the memory location '*ptr' to be val and returns
=A0* the previous value stored there.
=A0*/
static inline unsigned long
__xchg_u32(volatile void *p, unsigned long val)
{
=A0 =A0 =A0 =A0unsigned long prev;
=A0 =A0 =A0 =A0__asm__ __volatile__(
"1: =A0 =A0 lwarx =A0 %0,0,%2 \n"
" =A0 =A0 =A0 stwcx. =A0%3,0,%2 \n\
=A0 =A0 =A0 =A0bne- =A0 =A01b"
=A0 =A0 =A0 =A0: "=3D&r" (prev), "+m" (*(volatile unsigned int *)p)
=A0 =A0 =A0 =A0: "r" (p), "r" (val)
// =A0 =A0 =A0 =A0:"memory","cc");
=A0 =A0 =A0 =A0return prev;
}
#define ADDR 0x1000
int main()
{
=A0 =A0 =A0 =A0__xchg_u32((void*)ADDR, 0x2000);
=A0 =A0 =A0 =A0__xchg_u32((void*)ADDR, 0x3000);
=A0 =A0 =A0 =A0return 0;
}
Got the same asm, when compiled with O1 , with / without "memory" clobber
100003fc <main>:
100003fc: =A0 =A0 =A0 39 20 10 00 =A0 =A0 li =A0 =A0 =A0r9,4096
10000400: =A0 =A0 =A0 38 00 20 00 =A0 =A0 li =A0 =A0 =A0r0,8192
10000404: =A0 =A0 =A0 7d 60 48 28 =A0 =A0 lwarx =A0 r11,0,r9
10000408: =A0 =A0 =A0 7c 00 49 2d =A0 =A0 stwcx. =A0r0,0,r9
1000040c: =A0 =A0 =A0 40 a2 ff f8 =A0 =A0 bne- =A0 =A010000404 <main+0x8>
10000410: =A0 =A0 =A0 38 00 30 00 =A0 =A0 li =A0 =A0 =A0r0,12288
10000414: =A0 =A0 =A0 7d 60 48 28 =A0 =A0 lwarx =A0 r11,0,r9
10000418: =A0 =A0 =A0 7c 00 49 2d =A0 =A0 stwcx. =A0r0,0,r9
1000041c: =A0 =A0 =A0 40 a2 ff f8 =A0 =A0 bne- =A0 =A010000414 <main+0x18>
10000420: =A0 =A0 =A0 38 60 00 00 =A0 =A0 li =A0 =A0 =A0r3,0
10000424: =A0 =A0 =A0 4e 80 00 20 =A0 =A0 blr
No diff ?
am I choosing the right example ?
-TZ
On Sun, Jun 28, 2009 at 4:50 AM, Ian Lance Taylor<iant@google.com> wrote:
> kernel mailz <kernelmailz@googlemail.com> writes:
>
>> I've been fiddling my luck with gcc 4.3.2 inline assembly on powerpc
>> There are a few queries
>>
>> 1. asm volatile or simply asm produce the same assembly code.
>> Tried with a few examples but didnt find any difference by adding
>> volatile with asm
>>
>> 2. Use of "memory" and clobbered registers.
>>
>> "memory" -
>> a. announce to the compiler that the memory has been modified
>> b. this instruction writes to some memory (other than a listed output)
>> and GCC shouldn=92t cache memory values in registers across this asm.
>>
>> I tried with stw and stwcx instruction, adding "memory" has no effect.
>>
>> Is there any example scenerio where gcc would generate different
>> assembly by adding / removing "memory" ?
>
> Please never send a message to both gcc@gcc.gnu.org and
> gcc-help@gcc.gnu.org. =A0This message is appropriate for
> gcc-help@gcc.gnu.org, not for gcc@gcc.gnu.org. =A0Thanks.
>
> An asm with no outputs is always considered to be volatile. =A0To see the
> affect of volatile, just try something like
> =A0 =A0asm ("# modify %0" : "=3Dr" (i) : /* no inputs */ : /* no clobbers=
*/);
> Try it with and without optimization.
>
> As the documentation says, the effect of adding a "memory" clobber is
> that gcc does not cache values in registers across the asm. =A0So the
> effect will be shown in something like
> =A0int i =3D *p;
> =A0asm volatile ("# read %0" : : "r" (i));
> =A0return *p;
> The memory clobber will only make a different when optimizing.
>
> Ian
>
^ permalink raw reply
* Re: RapidIO - general questions
From: david.hagood @ 2009-06-29 15:44 UTC (permalink / raw)
To: Jan Neskudla; +Cc: linuxppc-dev, ext Li Yang, linux-kernel, IDT - Kim, Chul
In-Reply-To: <1246285193.10035.245.camel@demux9hc>
Do you know (and if you know, can you comment) if IDT is planning on
offering RIO (and more importantly to me sRIO) chipsets that can be used
on other architectures besides the various PPC chips with embedded sRIO
controllers?
^ permalink raw reply
* Re: Direct MII connection between MPC8313 and VIRTEX FPGA
From: Grant Likely @ 2009-06-29 15:40 UTC (permalink / raw)
To: Frank Prepelica; +Cc: linuxppc-dev
In-Reply-To: <29DC34A6B43468409F5A371CFE34E849D7EE1A@ex01.ads.ubidyne.de>
On Mon, Jun 29, 2009 at 2:23 AM, Frank
Prepelica<Frank.Prepelica@ubidyne.com> wrote:
> Hi Grant
>
> Thanks for your response!
>
> I have searched for "current-speed" in drivers/net/fec_mpc52xx.c but I cannot find anything. However we are using the gianfar.c Ethernet driver.
> Do you know whether this driver supports fixed MII links without PHY?
What kernel version are you using?
> I've got another question regarding MII connection between and MPC and a Virtex FPGA. Whats about the PHY address which has to be set in the DTB file? Do I have to modify the DTB at all?
Yes, you need to modify the DTB. You have a back to back MII
connection, not a phy, so you do *not* want to have a PHY node in the
device tree.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ 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