Hello, this is our custom board's u-boot:
U-Boot 2009.08 (Apr 19 2010 - 05:35:19)
CPU: MPC5200B v2.2, Core v1.4 at 132 MHz
Bus 132 MHz, IPB 132 MHz, PCI 66 MHz
Board: Ran Controller Board
I2C: 85 kHz, ready
DRAM: 128 MB
FLASH: 64 MB
We have 1:1 CP
Hello, we're using a custom board based on mpc5200b
We are using kernel 2.6.33 and when we using ethernet, we get 80% packet loss
with ping.
Where could i find the solutions?
U-boot information:
CPU: MPC5200B v2.2, Core v1.4 at 132 MHz
Bus 132 MHz, IPB 132 MHz, PCI 66 MHz
Board
Hello, i'm developing an embedded linux system on a custom mpc5200b board, at
University.
We have a problem with a custom version of kernel: 2.6.23 and 2.6.33. We can't
use newer version at the moment.
We are able to compile and load the kernel on Freescale Lite5200b and on Custom
Hello, i'm developing an embedded linux system on a custom mpc5200b board, at
University.
We have a problem with a custom version of kernel: 2.6.23 and 2.6.33. We can't
use newer version at the moment.
We are able to compile and load the kernel on Freescale Lite5200b and on Custom
ok at master branch in linux-next
tree
http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git
> Yes, I am a kernel newbie, but I am learning! I have an inherited
> project based on version 2.6.28 that is compiled for an MPC5200b
> and there are some issues I am interested in fixing
Hello all,
I have been following this list for a while now and am interested in getting a
version of the latest work in progress Linux kernel with fixes for powerpc.
Yes, I am a kernel newbie, but I am learning! I have an inherited project based
on version 2.6.28 that is compiled for an MPC5200b
Hi!
This problem has been discussed several times [1], [2], but wasn't
resolved yet. The clean solution suggested was to implement a custom
mapping driver [3].
Then I'll do that. It doesn't look terribly complicated.
It would be helpful if someone can test the first version if it's available.
Hi Stephan,
On Sun, 01 Jul 2012 08:47:01 +0200
Stephan Gatzka wrote:
> Hi Albrecht,
>
> > I don't recall who proposed this patch, but exactly this solution is
> > around for a longer time (mayby you search archives...). On my board, I
> > have a flash chip attached to the LocalBus in 16-bit
(SPAM)
Em 01-07-2012 03:47, Stephan Gatzka escreveu:
Hi Albrecht,
> I don't recall who proposed this patch, but exactly this solution is
> around for a longer time (mayby you search archives...). On my
board, I
> have a flash chip attached to the LocalBus in 16-bit mode. Based on
> 3.2.16,
Hi Albrecht,
> I don't recall who proposed this patch, but exactly this solution is
> around for a longer time (mayby you search archives...). On my board, I
> have a flash chip attached to the LocalBus in 16-bit mode. Based on
> 3.2.16, the patch is:
Thanks for your answer and yes, this patch
Hi Stephan:
Am 30.06.12 21:16 schrieb(en) Stephan Gatzka:
I have a problem running jffs2 on an MPC5200b board. I run kernel 3.4, but
older kernels like 3.1.5 are also affected. Every time I mount jffs2,
previously written content gets garbled.
The problem was nailed down to memcpy(&fd-&
Hello!
First of all, please apologize my cross posting.
I have a problem running jffs2 on an MPC5200b board. I run kernel 3.4,
but older kernels like 3.1.5 are also affected. Every time I mount
jffs2, previously written content gets garbled.
The problem was nailed down to memcpy(&fd-&
Hi,
I've just tried to boot 2.6.32, 3.0 and mainline kernel on my mpc5200b
based board, on 3.0 and mainline resulting in
mpc52xx_irqhost_map: invalid irq: virq=16, l1=0, l2=3
The device tree is based on mpc5200b.dtsi, hence the invalid irq comes from
gpio_wkup: gpi
I've revisited my testing, and found I was wrong about the packets
getting stuck in the FEC queue. The packets are getting stuck in the
bestcomm.
I generate a timestamp for each skb's ip_hdr->id at the beginning of
mpc52xx_fec_start_xmit, and for each skb retrieved from the bestcomm.
Typically t
On Fri, Feb 3, 2012 at 8:02 PM, acrux wrote:
> as i said [1] it seems to be fixed only in 3.x instead the last working one
> is the obsolete 2.6.36.x .
> Anyway, alog the sound/soc/fsl/mpc5200_dma.c now builds the sound is still
> broken.
Ok, I missed that part in your email.
The Efika sound
On Thu, 2 Feb 2012 21:50:02 +
Tabi Timur-B04825 wrote:
> On Thu, Feb 2, 2012 at 10:57 AM, acrux wrote:
>
>
> > well, i got the same error with also linux-2.6.37. Btw, this was already
> > reported about a year ago:
> > http://lists.ozlabs.org/pipermail/linuxppc-dev/2011-February/088415.ht
On Thu, Feb 2, 2012 at 10:57 AM, acrux wrote:
> well, i got the same error with also linux-2.6.37. Btw, this was already
> reported about a year ago:
> http://lists.ozlabs.org/pipermail/linuxppc-dev/2011-February/088415.html
I think this was fixed already. You're using an obsolete kernel.
--
n
it. But BestComm starts adding another packet, it the FEC starts to
transmit the "stuck" packet.
This testing has been on Kernel 3.1.6 (but I've seen the same problem
on a kernel based on the OLEAS pcm030 2.6.23 kernel). The hardware is
a custom board with 16 bit wide DDR SDRAM.
C
On Thu, 2 Feb 2012 03:48:03 +0100
acrux wrote:
> board: Genesi Efika (MPC5200B)
> problem: unable to use sound subsystem instead it works fine with
> linux-2.6.36.4 (+ device tree supplement, attached) .
>
> With linux-2.6.38.8 and linux-2.6.39.4 it doesn't build.
> T
board: Genesi Efika (MPC5200B)
problem: unable to use sound subsystem instead it works fine with
linux-2.6.36.4 (+ device tree supplement, attached) .
With linux-2.6.38.8 and linux-2.6.39.4 it doesn't build.
That's from my build log:
[...]
LD sound/soc/blackfin/built-in.o
LD
Joey Nelson
On Fri, Jan 27, 2012 at 12:14 PM, Joey Nelson wrote:
>
>
> In my application, I have a PC connected through TCP to a MPC5200B based
> system. The PC sends a short request, the MPC5200B receives the request and
> sends the data back. It is doing this about 300 ti
In my application, I have a PC connected through TCP to a MPC5200B based
system. The PC sends a short request, the MPC5200B receives the request
and sends the data back. It is doing this about 300 times per second.
Normally exchange happens in just handful of milliseconds. But randomly
every 2
Hello,
We have two problems when using the fec of the MPC5200b.
The occurence of both problems is very seldom.
1.
Sometimes the first two octets of the MAC-Adress are wrong.
Removing/inserting the driver does not help.
2.
Sometimes the communication stops.
When Removing the driver following
> After some discussions with Freescale's and FTDI's support, the reason seems
> to be that the FTDI chips continues to send zero up to 4 chars *after* the
> RTSn line has been deactivated by the '5200B (actually, this is the behaviour
> of many uart's).
Russell described this behaviour nicely her
Hi Henk:
Am 01.03.11 23:28 schrieb(en) Henk Stegeman:
Today I noticed corrupted and missing chunks of data on the 5200 with the
2.6.37 uart driver in 2.6.37.
I don't have these problems when I use the driver from 2.6.33 (with minor
changes to make it fit in 2.6.37).
Hmm, I hope it's not rela
Dear All,
Today I run mpc5200b for freescale, When I download the "rootfs.jffs2", I
found some errors:
run flash_jffs2
Error: "flash_jffs2" not defined
Would you please help me about the error
With Best Regards
Joshua
--
hi,
i've this error trying to compile my linux-2.6.37 for Genesi Efika
(MPC5200B) with sound enabled.
[...]
LD sound/pci/built-in.o
LD sound/pcmcia/pdaudiocf/built-in.o
LD sound/pcmcia/vx/built-in.o
LD sound/pcmcia/built-in.o
LD sound/ppc/built-in.o
Hi all,
sorry for a slightly off-topic question, but I hope someone here on the list
may be able to help me...
I have a strange problem with the psc uart of the mpc5200b, running 2.6.32.26
(still), with my baud rate divisor selection patch [1].
The uart runs at 115.2 kBaud with rtc/cts
Hello.
On 03-01-2011 18:27, Sergei Shtylyov wrote:
The commit you bisected to contains all those conversions too. Take a
look at a similar driver and look at how it has been converted
recently. Even better, just send the driver upstream. :-)
It's already there...
Ouch, did I forget to con
Hello.
On 03-01-2011 17:33, Tejun Heo wrote:
The commit you bisected to contains all those conversions too. Take a
look at a similar driver and look at how it has been converted
recently. Even better, just send the driver upstream. :-)
It's already there...
Ouch, did I forget to con
Hallo Tejun,
On Monday, 03.January.2011 14:59:29 Tejun Heo wrote:
> Which driver is it?
drivers/ata/pata_mpc52xx.c from the standard tree, 100% unchanged. As
I said, for the bisect I was using the original, unchanged
torvalds/master tree from git.kernel.org.
> You probably now want to use ata_b
On Mon, Jan 3, 2011 at 3:29 PM, Sergei Shtylyov wrote:
>> The commit you bisected to contains all those conversions too. Take a
>> look at a similar driver and look at how it has been converted
>> recently. Even better, just send the driver upstream. :-)
>
> It's already there...
Ouch, did I
Hello.
On 03-01-2011 16:59, Tejun Heo wrote:
When merging more recent kernel versions, tried that using v2.6.35 and
v2.6.36, into our tree (branched at v2.6.34), I detected, that MWDMA2
on the HW listed in the subject does no longer work.
So I bisected that using the original, standard kerne
hi,
my MPC5200B (Genesi EFIKA PowerPC) works fine with linux-2.6.36.2 and these two
patches:
http://lists.ozlabs.org/pipermail/linuxppc-dev/2010-December/087632.html
http://lists.ozlabs.org/pipermail/linuxppc-dev/2010-December/087633.html
i hope this helps,
cheers
--acrux
--
GNU/Linux on
On Mon, Jan 03, 2011 at 02:45:47PM +0100, Roman Fietze wrote:
> Hello,
>
> When merging more recent kernel versions, tried that using v2.6.35 and
> v2.6.36, into our tree (branched at v2.6.34), I detected, that MWDMA2
> on the HW listed in the subject does no longer work.
>
> So I bisected that u
Hello,
When merging more recent kernel versions, tried that using v2.6.35 and
v2.6.36, into our tree (branched at v2.6.34), I detected, that MWDMA2
on the HW listed in the subject does no longer work.
So I bisected that using the original, standard kernel tree using a
minimum config using
git
I belive I've fixed the problems with the messed up [PATCH 1/5]. I've also
incorporated changes per comments.
The following series implements a set of changes to refactor dts (device tree
source) files for systems using the mpc5200b SoC.
The dtc changes allow a base dts to be defined i
Hi all,
I'm not sure if this is the right list, so please excuse me if I'm totally
wrong here, or if my question is really dumb...
My platform is a MPC5200B (roughly Icecube) based board with kernel 2.6.32.
>From a PC I try to send data through the MPC5200B's serial port,
Hello,
I recently tried to switch to 2.6.36 (torvalds/master) using a
Lite5200B compatible board.
Using 2.6.34 we were running ATA in MWDMA 2 to avoid MPC5200B HW
problems with UDMA.
But with 2.6.36 I get only ATA errors (PIO4 is working fine):
...
ata: MPC52xx IDE/ATA libata driver
scsi0
From: Albrecht Dress
On the MPC5200B, make very high baud rates (e.g. 3 MBaud) accessible and
achieve a higher precision for high baud rates in general. This is done by
selecting the appropriate prescaler (/4 or /32). As to keep the code clean,
the getuartclk method has been dropped, and all
Hi Sylvain:
> Humm I see, here is the node I'm creating in the initial ramdisk, so
> they are there before mdev is launched in one of my init scripts.
[snip]
I additionally have "tty0 c 4 0" which might be important here, plus a lot of
other crap (should clean up there...;-). I don't use a ramd
[snip]
> Can you halt the processor with JTAG and look at the contents of __log_buf?
Ok I'll try that as soon as I can get CodeWarrior to work again...
> > 1. Is it possible ?
>
> Yes, I believe so, but I haven't tried.
Ok
>
> > 2. Do you have any idea how it can be achieve ?
>
> You should b
Hi Albrecht,
> > 1. Is it possible ?
>
> Yes! I tried this with several kernel versions (currently 2.6.33), using the
> option 'console=tty0'. Works just fine...
>
Happy to know that it can be done !
> > 2. Do you have any idea how it can be achieve ?
>
> Hmmm, iirc, I also saw the effect y
Hi Sylvain:
Am 22.04.10 20:58 schrieb(en) Sylvain Lamontagne:
[snip]
1. Is it possible ?
Yes! I tried this with several kernel versions (currently 2.6.33), using the
option 'console=tty0'. Works just fine...
2. Do you have any idea how it can be achieve ?
Hmmm, iirc, I also saw the effe
On Thu, Apr 22, 2010 at 12:58 PM, Sylvain Lamontagne
wrote:
> Hi everybody,
>
> I'm trying to remove the console from a custom board based on a
> MPC5200B. During development we used console=ttyS1,115200 in our bootcmd
> for the kernel, but now that the product is ready to be
Hi everybody,
I'm trying to remove the console from a custom board based on a
MPC5200B. During development we used console=ttyS1,115200 in our bootcmd
for the kernel, but now that the product is ready to be shipped we want
to use ttyS1 for something else and would like to deactivate compl
On Thu, Apr 15, 2010 at 03:53:53PM +0200, Roman Fietze wrote:
> Hello Bill,
>
> On Thursday 15 April 2010 15:01:59 Bill Gatliff wrote:
>
> > Are you talking about this code here?
> >
> > void
> > shadowUpdatePacked (ScreenPtr pScreen,
> > shadowBufPtr pBuf)
> >
On Fre, 2010-04-16 at 08:14 +0200, Roman Fietze wrote:
>
> On Thursday 15 April 2010 18:07:03 Bill Gatliff wrote:
>
> > I would love it if you posted your code! Thanks!!
>
> In this source file I just added my own routines:
>
> Index: programs/Xserver/hw/xfree86/drivers/fbdev/fbdev.c
> ===
Hello Bill,
On Friday 16 April 2010 04:51:38 Bill Gatliff wrote:
> Apparently, there are several similar modifications that need to be
> made, ...
I'm SW-Engineer, so I assume HW, that's always a good bet. ;)
Please take care, that I forgot to tell you that my X server runs well
on a Futjitsu 8
Hello Bill,
On Thursday 15 April 2010 18:07:03 Bill Gatliff wrote:
> I would love it if you posted your code! Thanks!!
In this source file I just added my own routines:
Index: programs/Xserver/hw/xfree86/drivers/fbdev/fbdev.c
===
-
Hello Bill,
On Thursday 15 April 2010 22:14:09 Bill Gatliff wrote:
> I'm not sure what the *Weak stuff is doing. Can I just hack
> shadowUpdatePacked() itself?
I think so. But take care if you want to use that code on other
systems or without shadowfb. If I search for shadowUpdatePacked, then
I'
Roman Fietze wrote:
> Yes. I added a routine like
>
> /* Swap frame buffer bytes in 32 bit value. */
> static __inline unsigned int
> fbbits_swap32(unsigned int __bsx)
> {
> return __bsx) & 0xff00) >> 8) | (((__bsx) & 0x00ff) << 8) |
> (((__bsx) & 0xff00) >> 8) | (((_
Roman Fietze wrote:
> Then I added void shadowUpdatePackedSwapped16() and
> shadowUpdatePackedSwapped32() which I was using instead of the
> original *Weak functions, which in turn uses the above swap routine
> when copying from shadow to the device.
>
I'm not sure what the *Weak stuff is doing
I would love it if you posted your code! Thanks!!
b.g.
On Apr 15, 2010 8:53 AM, "Roman Fietze" wrote:
Hello Bill,
On Thursday 15 April 2010 15:01:59 Bill Gatliff wrote:
> Are you talking about this code here?
>
...
Yes. I added a routine like
/* Swap frame buffer bytes in 32 bit value. */
Hello Bill,
On Thursday 15 April 2010 15:01:59 Bill Gatliff wrote:
> Are you talking about this code here?
>
> void
> shadowUpdatePacked (ScreenPtr pScreen,
> shadowBufPtr pBuf)
> {
> ...
> while (i--)
> *win++ =
Roman Fietze wrote:
> Hallo Bill,
>
> On Thursday 15 April 2010 05:07:08 Bill Gatliff wrote:
>
>
>> Actually, I *have* Debian squeeze's xorg running on the platform just
>> fine, with a 2.6.34-rc1 kernel (kernel.org). Problem is, every single
>> diagonal line is very blocky--- not smooth at all
On Wed, 14 Apr 2010 22:07:08 -0500
Bill Gatliff wrote:
> Put simply, I have an MPC5200b platform with a Fujitsu "Lime" GDC, and
> I'm trying to run Debian squeeze's xorg on it.
>
> Actually, I *have* Debian squeeze's xorg running on the platform just
> fi
Hallo Bill,
On Thursday 15 April 2010 05:07:08 Bill Gatliff wrote:
> Actually, I *have* Debian squeeze's xorg running on the platform just
> fine, with a 2.6.34-rc1 kernel (kernel.org). Problem is, every single
> diagonal line is very blocky--- not smooth at all.
I'm 95% sure it's an endianess
On Wed, 2010-04-14 at 22:07 -0500, Bill Gatliff wrote:
>
> Anyone have any suggestions on where to start with this one? Anyone
> else running a similar configuration with any success? I'm completely
> lost, and running out of hair *fast*...
Most probably endian bugs in the Lime driver ...
Chee
Guys:
I'm not quite sure where to ask this question, but all my attempts
elsewhere have come up short, so...
Put simply, I have an MPC5200b platform with a Fujitsu "Lime" GDC, and
I'm trying to run Debian squeeze's xorg on it.
Actually, I *have* Debian squeeze'
ome feedback.
>
> I tested the patches with the following setup:
>
> - DENX 2.6.33 plus NAPI patch, kernel config with and w/o NAPI enabled
>
> - Own Icecube based board using MPC5200B
>
> - Two different hard drives (because the Toshiba gave my headaches),
> ext3 defau
API patch, kernel config with and w/o NAPI enabled
- Own Icecube based board using MPC5200B
- Two different hard drives (because the Toshiba gave my headaches),
ext3 default settings of mkfs.ext3, MWDMA2
- FPGA on LPC receiving high bandwidth MOST150 data in PIO mode (for
the test: genera
Hi Roman,
Wolfgang Grandegger wrote:
> Roman Fietze wrote:
>> Hello,
>>
>> I think this is a never ending story. This error still happens under
>> higher load every few seconds, until I get a "PHY: f0003000:00 - Link
>> is Down", on my box easiliy reproducable after maybe 15 to 30 seconds.
>> I ca
Roman Fietze wrote:
> Hello,
>
> I think this is a never ending story. This error still happens under
> higher load every few seconds, until I get a "PHY: f0003000:00 - Link
> is Down", on my box easiliy reproducable after maybe 15 to 30 seconds.
> I can recover using "ip link set down/up dev eth0
Hello,
I think this is a never ending story. This error still happens under
higher load every few seconds, until I get a "PHY: f0003000:00 - Link
is Down", on my box easiliy reproducable after maybe 15 to 30 seconds.
I can recover using "ip link set down/up dev eth0".
I double checked that I'm us
On the MPC5200B, make very high baud rates (e.g. 3 MBaud) accessible and
achieve a higher precision for high baud rates in general. This is done by
selecting the appropriate prescaler (/4 or /32). As to keep the code clean,
the getuartclk method has been dropped, and all calculations are done in
On the MPC5200B, make very high baud rates (e.g. 3 MBaud) accessible and
achieve a higher precision for high baud rates in general. This is done by
selecting the appropriate prescaler (/4 or /32). As to keep the code clean,
the getuartclk method has been dropped, and all calculations are done in
On Thu, Mar 4, 2010 at 2:56 AM, Albrecht Dreà wrote:
>> That way each set_divisor() can do whatever makes the most sense for
>> the divisors available to it. Â The 5121 for example has both a /10 and
>> a /32 divisor, plus it can use an external clock.
>
> Ouch. Â I don't have a 512x, but isn't t
Hi Grant:
Thanks a lot for your input!
[snip]
> Save yourself some duplicated code here. The above 14 lines can be
> shared between the 512x, 52xx and 5200b versions. Create yourself an
> internal __mpc5xxx_psc_set_divisor() function that is passed the *psc,
> the divisor, and the clock select
Hi Albrecht,
I like this version much better. Comments below...
On Wed, Mar 3, 2010 at 11:23 AM, Albrecht Dreà wrote:
> On the MPC5200B, make very high baud rates (e.g. 3 MBaud) accessible and
> achieve a higher precision for high baud rates in general. Â This is done by
> sele
On the MPC5200B, make very high baud rates (e.g. 3 MBaud) accessible and
achieve a higher precision for high baud rates in general. This is done by
selecting the appropriate prescaler (/4 or /32). As to keep the code clean,
the getuartclk method has been dropped, and all calculations are done
Hi Albrecht,
Thanks for this work, comment below...
On Mon, Mar 1, 2010 at 11:11 AM, Albrecht Dreß wrote:
> On the MPC5200B, select the baud rate prescaler as /4 by default to make very
> high baud rates (e.g. 3 MBaud) accessible and to achieve a higher precision
> for high baud
divisor function?)
>
> O.k., I will add that comment...
>
Yes, please document your calculation approach thoroughly.
>> > > This should be handled using a new compatible-entry
>> > > "fsl,mpc5200b-psc-uart".
>> >
>>
>> > I agree th
On Tue, Mar 2, 2010 at 1:09 AM, Albrecht Dreà wrote:
>> > + Â /* Check only once if we are running on a mpc5200b or not */
>> > + Â if (is_mpc5200b == -1) {
>> > + Â Â Â Â Â struct device_node *np;
>> > +
>> > + Â Â Â Â Â np = of_find_c
> > > > This should be handled using a new compatible-entry
> > > > "fsl,mpc5200b-psc-uart".
> > >
> >
> > > I agree that this would be a lot cleaner, but it's also a lot more
> > intrusive.
> > > CC'ing the dev
/32 prescaler) is
> > probably the exceptional case - with an IPB frequency of 132 MHz this
> will
> > happen only for standard baud rates B300 and slower.
>
> Even the rare cases have to be correct ;)
I agree - will make the debug output and comments clearer...
[snip]
>
appen only for standard baud rates B300 and slower.
Even the rare cases have to be correct ;)
> [snip]
> > > + /* Check only once if we are running on a mpc5200b or not */
> > > + if (is_mpc5200b == -1) {
> > > + struct device_node *np;
> > > +
for the counter reg.
Remember also that using the higher 16 bits (/32 prescaler) is probably the
exceptional case - with an IPB frequency of 132 MHz this will happen only for
standard baud rates B300 and slower.
[snip]
> > + /* Check only once if we are running on a mpc5200b or n
Hi Albrecht,
On Mon, Mar 01, 2010 at 07:11:54PM +0100, Albrecht Dreß wrote:
> On the MPC5200B, select the baud rate prescaler as /4 by default to make very
> high baud rates (e.g. 3 MBaud) accessible and to achieve a higher precision
> for high baud rates in general. For baud rates b
On the MPC5200B, select the baud rate prescaler as /4 by default to make very
high baud rates (e.g. 3 MBaud) accessible and to achieve a higher precision
for high baud rates in general. For baud rates below ~500 Baud, the code will
automatically fall back to the /32 prescaler. The original
Hi Roman:
Sorry for the long delay, I had to fix some other stuff first, before I could
launch the test... Here is just a short intermediate result.
Am 04.02.10 20:35 schrieb(en) Albrecht Dreß:
Actually, I forgot that I have to explicitly enable libata dma on the 5200b,
due to the known sili
Hi Roman:
Am 03.02.10 07:16 schrieb(en) Roman Fietze:
Sorry for the delay ... your mail got stuck in a Notes "spam filter".
Never mind. I didn't know yet that I'm *such* a nasty guy... ;-)
Are you using MWDMA2 with the compact flash cards? What is the load on the
different (DMA) channels?
serve any issues
The filesystem crashes are seldom, but happen often enough to be able
to reproduce them once every 1 or 2 days under heavy load, and to
produce failures in the field, what's even worse. And they
statistically increased a lot wen we ran out of GPIO on the MPC5200B
and then use
Hi Roman:
Am 16.12.09 12:37 schrieb(en) Roman Fietze:
The board is using the MPC5200B on a board derived from the old lite5200, but with the fixes for the MPC5200B. All tests are run using an ST940813AM hard drive with an ext2 and an ext3 of 10GB each, default mkfs options. The OS is Debian 4.0
ould use the
> prescaler of 4. See MPC5200B user manual page 15-46 for the calculation
> formula and page 15-12 for the CSR description.
> Currently the code for the kernel we are using here, (2.6.29.2) seams not to
> take a prescaler of 4 into account.
> Line 249 of
> mpc52xx_ua
to all" and make comments on the code.
Ok, I'll do so. I hope I've understood what
http://www.kernel.org/pub/linux/docs/lkml/ says about creating
suitable patches for mailing lists.
Patch description:
This is a series of patches on top of the benh next branch modifying
the plat
Hello Wolfgang,
On Friday 18 December 2009 09:24:29 Wolfgang Grandegger wrote:
> What disc access modes, (pio, mwdma or udma) did you use for these tests.
MWDMA2.
On our hardware Linux 2.6 UDMA2 only works with very few disks. And on
top of that, UDMA seems to have problems on the MPC52
marks ever seen, but thet'll be a good starting point to get a
> feeling what stability might cost.
>
> The board is using the MPC5200B on a board derived from the old
> lite5200, but with the fixes for the MPC5200B. All tests are run using
> an ST940813AM hard drive with an ext
Hi all,
I would like to be able to set a baud rate of 460800 for modem that we are
testing. With the actual prescaler of 32 and a IPB frequency of 84MHz
I got a 5.1% error (437500) vs a 0.9% error (456522) if I could use the
prescaler of 4. See MPC5200B user manual page 15-46 for the calculation
feeling what stability might cost.
The board is using the MPC5200B on a board derived from the old
lite5200, but with the fixes for the MPC5200B. All tests are run using
an ST940813AM hard drive with an ext2 and an ext3 of 10GB each,
default mkfs options. The OS is Debian 4.0. The network connection
Hello Wolfram,
On Wednesday 09 December 2009 15:57:48 Wolfram Sang wrote:
> Do you have a way to measure performance penalties?
Yes, I do. I am using an SCLPC test driver derived from a driver
written or posted by Grant Likely named mpc5200-localplus-test. This
gives me some useful output about
Hello Roman,
> I would be interested in your opinion, maybe Wolfgang could make some
> comments, because he is involved in the U-Boot a lot as well.
Do you have a way to measure performance penalties? I know that stability comes
before performance, still I am wondering as it looks to me that the
latest recommendation from Freescale was to set BSDIS and PLDIS
and to clear SE, resulting in a XLB config register value of
0x80012006, at least for my MPC5200B PVR/SVR of
0x80822014/0x80110022. If I am correct, the current XLB config setting
using the current U-Boot and kernel is 0xa006.
In
Hello list,
In our old, modified 2.4.25 I had a statement that sets the bit BSDIS
(real world bit 16, Freescale bit 15) in the XLB config register for
the MPC5200B.
Checking the XLB config of "my" 2.6.32-rc7 doesn't show this bit set
(XLB config reads 0xa006).
But this gives
On Wed, Nov 11, 2009 at 11:33 PM, Roman Fietze
wrote:
> As Grant mentioned as well, the key was and is a correct DTS. (At
> least) one statement was missing:
>
> interrupt-parent = <&mpc5200_pic>;
>
> This statement seemed to move all the way up from the devices to the
> root of the tree, and som
Hello Suvidh,
On Wednesday 28 October 2009 16:19:04 suvidh kankariya wrote:
> I am sorry for the misguided statement.
No problem, help is always welcome.
> I indeed had patched it.
Allthough Grant's mail got stuck in our beloved Notes spam filter, we
found out how to use that KSZ8001 on our bo
Hello,
When having high traffic on the MPC5200B ATA (MWDMA2), FEC (100MBit)
and LPC (MTD FLASH read) I will get the typical
FEC_IEVENT_RFIFO_ERROR's.
Without the FLASH reads, that we use to stress the probably existing
LPC arbiter or MPC5200B silicon bug when running UDMA2+LPC, and which
s
;
+module_exit(micrel_exit);
Suvidh
--
Message: 6
Date: Tue, 27 Oct 2009 20:54:47 +0100
From: Roman Fietze
To: linuxppc-dev@lists.ozlabs.org
Subject: Re: Micrel PHY KSZ8001 on MPC5200B FEC
Message-ID: <200910272054.47398.roman.fie...@telemotive.de>
Conten
On Tue, Oct 27, 2009 at 1:54 PM, Roman Fietze
wrote:
> Hello Suvidh,
>
> On Tuesday 27 October 2009 17:47:51 suvidh kankariya wrote:
>
>> A driver for micrel phy exists in /drivers/net/phy/micrel.c. in
>> 2.6.30.
>
> Am I somewhat blind, or do you have access to other 2.6.30's than I
> have?
>
> I
Hello Suvidh,
On Tuesday 27 October 2009 17:47:51 suvidh kankariya wrote:
> A driver for micrel phy exists in /drivers/net/phy/micrel.c. in
> 2.6.30.
Am I somewhat blind, or do you have access to other 2.6.30's than I
have?
I searched git.kernel.org, git.denx.de and git.secretlab.ca, but could
1 - 100 of 234 matches
Mail list logo
