* Re: MPC5200/Lite5200 and ethernet
From: Dale Farnsworth @ 2005-06-17 3:37 UTC (permalink / raw)
To: Andrey Volkov; +Cc: linuxppc-embedded
In-Reply-To: <42B1CB13.3060107@varma-el.com>
On Thu, Jun 16, 2005 at 10:55:15PM +0400, Andrey Volkov wrote:
> Grant Likely wrote:
> > On 6/16/05, Andrey Volkov <avolkov@varma-el.com> wrote:
> >
> >>AFAIK almost all patches from http://www.246tnt.com/mpc52xx/ now in
> >>vanilla kernel. Except, bestcomm, certainly :(.
> >
> > FEC is missing too.
> >
> > Is anybody even working on bestcomm at the moment?
> It may be Dale Farnsworth or smb. quietly in Freescale.
I sent patches to Sylvain in August 2004 with 5200 FEC support,
including my rewrite of the bestcomm FEC code. I've bugged him
about it a few times, and I don't know why he hasn't made it available.
I haven't done much with the 5200 since then. I'm traveling now and
have some other pressing issues, but I'll try to post what
I have in the next couple of weeks.
-Dale
^ permalink raw reply
* Re: mmap on 440gx
From: Ed Goforth @ 2005-06-17 3:47 UTC (permalink / raw)
To: Matt Porter; +Cc: linuxppc-embedded
In-Reply-To: <20050616155525.A4541@cox.net>
On 6/16/05, Matt Porter <mporter@kernel.crashing.org> wrote:
> On Thu, Jun 16, 2005 at 05:33:44PM -0400, Ed Goforth wrote:
Thanks for taking the time to reply.
> > I've been struggling with implementing mmap on a 440gx-based custom
> > board. I have been able to use ioremap(), but we really need a mmap()
> > for our software. The kernel is 2.4.18 (TimeSys 4.0).
>=20
> There are some special things done for handling [io]_remap_page/pfn_range
> on other vendor kernels and the current mainline kernel. I'm not sure
> if your vendor kernel addressed them since it would be a vendor-specific
> patch in that timeframe. The special things are due to 36-bit
> addressing.
>=20
> > I'm trying to access one of our FPGA's located at 0x50000000. Offsets
>=20
> Let's start at the beginning. How do you have FPGA's at 0x50000000?
> that address falls with the fix DDR SDRAM area on the 440GX memory
> map. All peripheral and EBC space is mapped by 4GB. You lost me
> right here. Oh wait, are you referring to the least significant 32-bits
> of the physical mapping. It's not really at 0x50000000.
Of course, you're correct. The 36-bit base address is 0x1_0000_0000.=20
It is mapped to the 32-bit address 0x5000_0000.
Should I pass the 36-bit address to remap_page_range()?
For what it's worth, __pa(0x5000_0000) returns 0x9000_0000.
>=20
> You need something like the bigphys_remap patch for 2.4 that can be
> found at ftp://source.mvista.com/pub/linuxppc/
I just checked the source, and that patch has indeed been applied.
>=20
> It does the same fixup for remap_page_range() that happens for
> ioremap(). In 2.6 this stuff is all in the mainline kernel but
> you use io_rename_[page|pfn]_range() there.
>=20
> -Matt
>=20
Thanks,
Ed
^ permalink raw reply
* Re: mmap on 440gx
From: Matt Porter @ 2005-06-17 4:41 UTC (permalink / raw)
To: Ed Goforth; +Cc: linuxppc-embedded
In-Reply-To: <75b39f010506162047236fec19@mail.gmail.com>
On Thu, Jun 16, 2005 at 11:47:22PM -0400, Ed Goforth wrote:
> On 6/16/05, Matt Porter <mporter@kernel.crashing.org> wrote:
> > On Thu, Jun 16, 2005 at 05:33:44PM -0400, Ed Goforth wrote:
>
> Thanks for taking the time to reply.
>
> > > I've been struggling with implementing mmap on a 440gx-based custom
> > > board. I have been able to use ioremap(), but we really need a mmap()
> > > for our software. The kernel is 2.4.18 (TimeSys 4.0).
> >
> > There are some special things done for handling [io]_remap_page/pfn_range
> > on other vendor kernels and the current mainline kernel. I'm not sure
> > if your vendor kernel addressed them since it would be a vendor-specific
> > patch in that timeframe. The special things are due to 36-bit
> > addressing.
> >
> > > I'm trying to access one of our FPGA's located at 0x50000000. Offsets
> >
> > Let's start at the beginning. How do you have FPGA's at 0x50000000?
> > that address falls with the fix DDR SDRAM area on the 440GX memory
> > map. All peripheral and EBC space is mapped by 4GB. You lost me
> > right here. Oh wait, are you referring to the least significant 32-bits
> > of the physical mapping. It's not really at 0x50000000.
>
> Of course, you're correct. The 36-bit base address is 0x1_0000_0000.
> It is mapped to the 32-bit address 0x5000_0000.
That's an interesting way to look at it but there isn't really a
"mapping". You have configured a EBC chip selects to decode at
1_5000_0000.
> Should I pass the 36-bit address to remap_page_range()?
No, it takes a 32-bit physical address and "fixes it up" using
the fixup_bigphys_addr() method. Double check that the trap ranges
are correct for you board port. They need to be modified to add
the appropriate MS 4-bit. Since ioremap() also uses
fixup_bigphys_addr() to "fixup" 32-bit addresses to 36-bit,
it should just work.
> For what it's worth, __pa(0x5000_0000) returns 0x9000_0000.
Sure, you just asked it to subtract KERNELBASE from a physical address.
Don't use __pa() in drivers. That's expected behavior. Why are
you doing that?
> > You need something like the bigphys_remap patch for 2.4 that can be
> > found at ftp://source.mvista.com/pub/linuxppc/
>
> I just checked the source, and that patch has indeed been applied.
Ok, assuming it's all correct then I don't know why it does work
for you in your vendor tree. Have you asked Timesys for help?
Put some debug statements throughout fixup_bigphys_addr() to see
what's going on.
-Matt
^ permalink raw reply
* Re: mmap on 440gx
From: Ed Goforth @ 2005-06-17 5:42 UTC (permalink / raw)
To: Matt Porter; +Cc: linuxppc-embedded
In-Reply-To: <20050616214155.A7062@cox.net>
On 6/17/05, Matt Porter <mporter@kernel.crashing.org> wrote:
> On Thu, Jun 16, 2005 at 11:47:22PM -0400, Ed Goforth wrote:
> > On 6/16/05, Matt Porter <mporter@kernel.crashing.org> wrote:
> > > On Thu, Jun 16, 2005 at 05:33:44PM -0400, Ed Goforth wrote:
> >
> > Thanks for taking the time to reply.
> >
> > > > I've been struggling with implementing mmap on a 440gx-based custom
> > > > board. I have been able to use ioremap(), but we really need a mma=
p()
> > > > for our software. The kernel is 2.4.18 (TimeSys 4.0).
> > >
>=20
>=20
> > For what it's worth, __pa(0x5000_0000) returns 0x9000_0000.
>=20
> Sure, you just asked it to subtract KERNELBASE from a physical address.
> Don't use __pa() in drivers. That's expected behavior. Why are
> you doing that?
Desperation.
>=20
> > > You need something like the bigphys_remap patch for 2.4 that can be
> > > found at ftp://source.mvista.com/pub/linuxppc/
> >
> > I just checked the source, and that patch has indeed been applied.
>=20
> Ok, assuming it's all correct then I don't know why it does work
> for you in your vendor tree. Have you asked Timesys for help?
Not yet. I wanted to get some confidence that I was using the correct
APIs appropriately.
>=20
> Put some debug statements throughout fixup_bigphys_addr() to see
> what's going on.
My include/asm/mmu.h has it defined as:
#ifndef CONFIG_440
#include <asm-generic/mmu.h>
#else
typedef unsigned long long phys_addr_t;
#define fixup_bigphys_addr(addr, size) (addr)
#endif
I see that in later 2.4 kernels and in mainline 2.6 it is implemented
as an actual working routine. Perhaps that explains it all. The
ioremap() in my tree implements the fixup code inline, which would
explain why it works, right?
>=20
> -Matt
>=20
Thanks again.
Ed
^ permalink raw reply
* Re: RFC cpm2_devices DPRAM resource
From: Pantelis Antoniou @ 2005-06-17 6:48 UTC (permalink / raw)
To: Allen Curtis; +Cc: Ppc Embedded
In-Reply-To: <b2f31907a6e9a9180a96318ceeacb468@onz.com>
Allen Curtis wrote:
>>> Should the DPRAM appear as it's own platform_device?
>>
>>
>> No.
>>
>>> Option 1) Specify the portion of the DPRAM used by each device with
>>> that platform_device definition. (current)
>>
>>
>> You mean the parameter space? That's different from DPRAM.
>>
>>> Option 2) Define the whole DPRAM region as its own platform_device
>>> entry. Move the device DPRAM information to the device specific
>>> platform structure.
>>
>>
>> How is this any different from using the dpalloc() as it is today?
>>
>> The problem is that for the few standard devices we publicly support in
>> Linux it is easy to think of DPRAM as a "general" resource. However, for
>> more challenging devices and implementation, there are sometimes specific
>> regions of DPRAM that must be used with various additional restrictions.
>> For many of the "real world" devices I have done, drivers would manage
>> their own, well known, DPRAM areas. It isn't something that is easy
>> to generalize or configure in advance.
>>
> Time for code.
>
> - Allen
>
FWIW the current dpalloc implementation supports "carving out" the usable
dpram out of the whole. I mean you could conceivably not "give" the driver
specific dpram areas to the generic allocator. This should be a per platform
configuration item.
The current code just doesn't bother...
Regards
Pantelis
^ permalink raw reply
* Re: mmap on 440gx
From: Matt Porter @ 2005-06-17 7:24 UTC (permalink / raw)
To: Ed Goforth; +Cc: linuxppc-embedded
In-Reply-To: <75b39f0105061622421d81bc92@mail.gmail.com>
On Fri, Jun 17, 2005 at 01:42:07AM -0400, Ed Goforth wrote:
> On 6/17/05, Matt Porter <mporter@kernel.crashing.org> wrote:
> > On Thu, Jun 16, 2005 at 11:47:22PM -0400, Ed Goforth wrote:
> > > On 6/16/05, Matt Porter <mporter@kernel.crashing.org> wrote:
> > > > On Thu, Jun 16, 2005 at 05:33:44PM -0400, Ed Goforth wrote:
> > >
> > > Thanks for taking the time to reply.
> > >
> > > > > I've been struggling with implementing mmap on a 440gx-based custom
> > > > > board. I have been able to use ioremap(), but we really need a mmap()
> > > > > for our software. The kernel is 2.4.18 (TimeSys 4.0).
> > > >
> >
> >
> > > For what it's worth, __pa(0x5000_0000) returns 0x9000_0000.
> >
> > Sure, you just asked it to subtract KERNELBASE from a physical address.
> > Don't use __pa() in drivers. That's expected behavior. Why are
> > you doing that?
>
> Desperation.
Heh, I like that. :)
<snip>
> > Put some debug statements throughout fixup_bigphys_addr() to see
> > what's going on.
>
> My include/asm/mmu.h has it defined as:
> #ifndef CONFIG_440
> #include <asm-generic/mmu.h>
> #else
> typedef unsigned long long phys_addr_t;
> #define fixup_bigphys_addr(addr, size) (addr)
> #endif
>
> I see that in later 2.4 kernels and in mainline 2.6 it is implemented
> as an actual working routine. Perhaps that explains it all. The
> ioremap() in my tree implements the fixup code inline, which would
> explain why it works, right?
It sure does. That code is 100% wrong. Just merge in mainline 2.4
stuff and you should be golden.
-Matt
^ permalink raw reply
* Does any body have HYNIX or AMIC 32M SDRAM reference cdoe?
From: 徐勝威 @ 2005-06-17 8:07 UTC (permalink / raw)
To: linuxppc-embedded; +Cc: R64382, HHPPC Support
[-- Attachment #1: Type: text/plain, Size: 2943 bytes --]
Hi All:
I used HY57641620 * 2 total all 16M SDRAM at my MPC852T board, now i want to
used HY57V281620ET-H * 2 or AMIC A43L3616-6 * 2 total all 32M SDRAM, but i don't know
how to setting UPM to control it, i need help.If you used another 32M SDRAM solution,
please tell me, thanks.
#define _NOT_USED_ 0xFFFFFFFF
const uint sdram_table[] = /* for HY57641620 * 2 16M SDRAM */
{
/* Single Read. (offset 0x0-0x4 in UPM RAM) */
/* Precharge and MRS(offset 0x5-0x7 in UPM RAM) */
0x1F07FC04, 0xEEAEFC04, 0x11ADFC04, 0xEFBBBC00,
0x1FF77C47, 0x1FF77C35, 0xEFEABC34, 0x1FB57C35,
/* Burst Read. (offset 0x8-0xf in UPM RAM) */
0x1F07FC04, 0xEEAEFC04, 0x10ADFC04, 0xF0AFFC00,
0xF0AFFC00, 0xF1AFFC00, 0xEFBBBC00, 0x1FF77C47,
_NOT_USED_, _NOT_USED_, _NOT_USED_, _NOT_USED_,
_NOT_USED_, _NOT_USED_, _NOT_USED_, _NOT_USED_,
/* Single Write. (offset 0x18-0x1F in UPM RAM) */
0x1F27FC04, 0xEEAEBC00, 0x01B93C04, 0x1FF77C47,
_NOT_USED_, _NOT_USED_, _NOT_USED_, _NOT_USED_,
/* Burst Write. (offset 20-2F in UPM RAM) */
0x1F07FC04, 0xEEAEBC00, 0x10AD7C00, 0xF0AFFC00,
0xF0AFFC00, 0xE1BBBC04, 0x1FF77C47, _NOT_USED_,
_NOT_USED_, _NOT_USED_, _NOT_USED_, _NOT_USED_,
_NOT_USED_, _NOT_USED_, _NOT_USED_, _NOT_USED_,
/* Refresh timer expired (offset 30-3B in UPM RAM) */
0x1FF5FC84, 0xFFFFFC04, 0xFFFFFC04, 0xFFFFFC04,
0xFFFFFC84, 0xFFFFFC07, 0xffffffff, _NOT_USED_,
_NOT_USED_, _NOT_USED_, _NOT_USED_, _NOT_USED_,
/* Exception. (offset 3c-3f in UPM RAM) */
0x7FFFFC07, _NOT_USED_, _NOT_USED_, _NOT_USED_
};
long int initdram(int board_type)
{
volatile immap_t *immap = (immap_t *)CFG_IMMR;
volatile memctl8xx_t *memctl = &immap->im_memctl;
upmconfig(UPMA, (uint *)sdram_table, sizeof(sdram_table)/sizeof(uint));
memctl->memc_mptpr = 0x0400;
/*
* Configure the refresh (mostly). This needs to be
* based upon processor clock speed and optimized to provide
* the highest level of performance. For multiple banks,
* this time has to be divided by the number of banks.
* Although it is not clear anywhere, it appears the
* refresh steps through the chip selects for this UPM
* on each refresh cycle.
* We have to be careful changing
* UPM registers after we ask it to run these commands.
*/
memctl->memc_mamr = 0xD0904114;
memctl->memc_mar = 0x00000088;
udelay(200);
memctl->memc_mcr = 0x80004105; /* precharge */
udelay(200);
memctl->memc_mamr = 0xD0904114;
memctl->memc_mcr = 0x80004830; /* refresh */
udelay(200);
memctl->memc_mamr = 0xD0904114;
memctl->memc_mcr = 0x80004106;
udelay(200);
memctl->memc_or2 = 0xFE000A00;
memctl->memc_br2 = 0x00000081;
return (32 * 1024 *1024);
} /* end of initdram */
[-- Attachment #2: Type: text/html, Size: 5289 bytes --]
^ permalink raw reply
* Re: MPC5200/Lite5200 and ethernet
From: Andrey Volkov @ 2005-06-17 10:28 UTC (permalink / raw)
To: Dale Farnsworth; +Cc: linuxppc-embedded
In-Reply-To: <20050617033711.GA1362@xyzzy.farnsworth.org>
Dale Farnsworth wrote:
> On Thu, Jun 16, 2005 at 10:55:15PM +0400, Andrey Volkov wrote:
>
>>Grant Likely wrote:
>>
>>>On 6/16/05, Andrey Volkov <avolkov@varma-el.com> wrote:
>>>
>>>
>>>>AFAIK almost all patches from http://www.246tnt.com/mpc52xx/ now in
>>>>vanilla kernel. Except, bestcomm, certainly :(.
>>>
>>>FEC is missing too.
>>>
>>>Is anybody even working on bestcomm at the moment?
>>
>>It may be Dale Farnsworth or smb. quietly in Freescale.
>
>
> I sent patches to Sylvain in August 2004 with 5200 FEC support,
> including my rewrite of the bestcomm FEC code. I've bugged him
> about it a few times, and I don't know why he hasn't made it available.
> I haven't done much with the 5200 since then. I'm traveling now and
> have some other pressing issues, but I'll try to post what
> I have in the next couple of weeks.
>
> -Dale
Dale, don't worry, Sylvain public your patches in himself src tree
(http://www.246tnt.com/mpc52xx/) at August/September,2004.
But, after that, OCP infra was dropped in kernel, and, hence, this
driver was not sent to Andrew Morton (Bestcomm stuff, until now, OCP
depended). And no one find time to convert Bestcomm to platform bus
model :(.
I planned start this job at July/August, so if someone wish to do it NOW
(June) - welcome.
--
Regards
Andrey Volkov
^ permalink raw reply
* Re: MPC5200/Lite5200 and ethernet
From: Dale Farnsworth @ 2005-06-17 14:00 UTC (permalink / raw)
To: Andrey Volkov; +Cc: linuxppc-embedded
In-Reply-To: <42B2A5C7.1040909@varma-el.com>
On Fri, Jun 17, 2005 at 02:28:23PM +0400, Andrey Volkov wrote:
> > I sent patches to Sylvain in August 2004 with 5200 FEC support,
> > including my rewrite of the bestcomm FEC code. I've bugged him
> > about it a few times, and I don't know why he hasn't made it available.
> > I haven't done much with the 5200 since then. I'm traveling now and
> > have some other pressing issues, but I'll try to post what
> > I have in the next couple of weeks.
> >
> > -Dale
>
> Dale, don't worry, Sylvain public your patches in himself src tree
> (http://www.246tnt.com/mpc52xx/) at August/September,2004.
> But, after that, OCP infra was dropped in kernel, and, hence, this
> driver was not sent to Andrew Morton (Bestcomm stuff, until now, OCP
> depended). And no one find time to convert Bestcomm to platform bus
> model :(.
>
> I planned start this job at July/August, so if someone wish to do it NOW
> (June) - welcome.
Thank you Andrey, and my apologies to Sylvain. I didn't realize that
they were available. I'll take a look at converting to the platform bus
model, but it will be at least a week before I start.
-Dale
^ permalink raw reply
* Problems on Philips ISP1362 Driver
From: Jianliang Lu @ 2005-06-17 14:03 UTC (permalink / raw)
To: linuxppc-embedded
Hi all,
We are using ISP1362 usb host controller in our PPC-linux embedded
system and we have had following problems:
1) ATL Interrupt doesn't work correctly. We have to use
ATL_THRESHOLD_TIMEOUT, that has the minimun resolution 1 msec, to
bypass it.
2) The latency from PTD completion. From a usb frame analyzer we
have seen that the controller has gaps between every 4 64-bytes
frames for 265 bytes PTD configured in bulk transmission. The
limit of 265 byte for PTD is due to the end-point number.
3) The isochronous mode doesn' t work. That we've seen was we were
loop on frame number, so the machine went to hang!
The driver is ported from those of philips (last updated was
2002), I don't know if there is any updated driver.
I've seen on the list that Wolfgang Denk has test it on many
devices and works fine. I'd like to know from Wolfgang which
driver did you use? Is the driver is open source?
Thanks in advance!
Jianliang Lu
^ permalink raw reply
* Re: multicast disabled on 8260_io/fcc_enet.c
From: Samuel Osorio Calvo @ 2005-06-17 15:29 UTC (permalink / raw)
To: dan; +Cc: linuxppc-embedded
Sorry for asking things that were solved, but I was not able to find =
them, and I am a newbie in this world.
Anyhow, just thank you for the comment on the CRC, it looks like it is =
properly done in the new DENX release (3.1.1).
Samuel.
Unclassified.
>>> Dan Malek <dan@embeddededge.com> 06/16/05 03:03AM >>>
On Jun 15, 2005, at 9:14 AM, Samuel Osorio Calvo wrote:
> Currently I have multicast working just be moving the return=20
> statement. It seems to work but I guess I did not face yet the=20
> problems that caused the code to be commented.
> Let's say it works in an unreliable way....
When I wrote the original code I copied the old SCC driver and didn't=20
have
a function for computing CRCs, so I just placed the return early in the=20
function.
I believe there is a patch floating around that wrote a CRC function=20
(or used some
existing one), to compute the filter mask. If the code has a CRC=20
function call,
then it will likely work. If it doesn't have one, then you are running=20
on luck. Either
the proper filter bit is set by some random reset bits, or you somehow=20
get the
right one set. By default, the multicast filter may just catch=20
everything, forcing
the Linux IP stack to do the filtering at a higher level, not exactly=20
what you want. :-)
This has been discussed many times in the past.
Thanks.
-- Dan
^ permalink raw reply
* problems on isp1362 driver
From: lu @ 2005-06-17 14:15 UTC (permalink / raw)
To: linuxppc-embedded
Hi all,
We are using Philips ISP1362 usb controller on our ppc-embedded system. We
have ported the phlips's driver, PHCI, to ppc. The Philips linux driver is
that of 2002.
Following are problems tha we've found in our test:
1) ATL Interrupt doesn't work correctly. We have to use
ATL_THRESHOLD_TIMEOUT, that has the minimun resolution 1 msec, to bypass it.
2) The latency from PTD completion. From a usb frame analyzer we have seen
that the controller has gaps between every 4 64-bytes frames for 265 bytes
PTD configured in bulk transmission. The limit of 265 byte for PTD is due to
the end-point number.
3) The isochronous mode doesn' t work. That we've seen was we were loop on
frame number, so the machine went to hang!
>From the list I've seen that Wolfgang Denk has worked for that driver and
test is for a lot of devices. I'd like to know from Wolfgang which driver is
used? Is the driver that you are using is open source? Where can we get it?
Thanks in advance!
Jianliang Lu
^ permalink raw reply
* Active 2.4 kernel repositories
From: Stephen Williams @ 2005-06-17 17:46 UTC (permalink / raw)
To: linuxppc-embedded
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I have a 405GPr based custom board that is running Linux 2.4,
and we want to stay there for the while. I've been keeping up
to date (more or less) with the linuxppc-2.4 BitKeeper tree
but that tree is done now and I would like to point at a managed
tree (CVS, git, whatever) that I can use to keep my board support
patches up to date against.
I can of course go to kernel.org and get the latest kernel
trees from there, but I really would rather follow an actively
maintained tree.
So what's the story? Maybe there is a community managed tree
where I can submit my board support patches?
- --
Steve Williams "The woods are lovely, dark and deep.
steve at icarus.com But I have promises to keep,
http://www.icarus.com and lines to code before I sleep,
http://www.picturel.com And lines to code before I sleep."
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFCswx9rPt1Sc2b3ikRApGwAJ9W+t/cPY1mGuy3qses8e0QuLV4NACcDYlI
KUwD6QsYb1N40vqH8WhdhDQ=
=VWMT
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: problems on isp1362 driver
From: Wolfgang Denk @ 2005-06-17 19:12 UTC (permalink / raw)
To: j.lu; +Cc: linuxppc-embedded
In-Reply-To: <000001c57347$04a45d00$07070a0a@luj>
Dear Jianliang Lu,
in message <000001c57347$04a45d00$07070a0a@luj> you wrote:
>
> We are using Philips ISP1362 usb controller on our ppc-embedded system. We
> have ported the phlips's driver, PHCI, to ppc. The Philips linux driver is
> that of 2002.
You cannot do that. The Philips driver comes uner a proprietary
license which is incompatible with the GPL. You must not use their
driver in the context of a Linux kernel or any other GPLed software.
You are either violating the GPL, or the Philips license. Be
careful!!!
> >From the list I've seen that Wolfgang Denk has worked for that driver and
No!!! We never had any access to the Philips drivers. We are proud of
using Free Software exclusively and will not accepts such a license.
> test is for a lot of devices. I'd like to know from Wolfgang which driver is
> used? Is the driver that you are using is open source? Where can we get it?
Our version of the driver is Free Software under GPL. It is included
in the linuxppc_2_4_devel module on our CVS server, see
http://www.denx.de/re/linux.html
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
There is enough for the need of everyone in this world,
but not for the greed of everyone. - Mahatma Gandhi
^ permalink raw reply
* MPC8247 Linux boot problem.
From: LEO @ 2005-06-18 11:09 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <20050617080829.D6E1067B29@ozlabs.org>
RGVhciBhbGwsDQpJIGFtIHVzaW5nIEVMREstMy4wLCBhbmQgcG9ydGluZyB0aGUgbGludXgtMi40
LjI0IHRvIG15IE1QQzgyNDcgYm9hcmQsIFUtQm9vdC0xLjAuMiByYW4gb2suIEN1cnJlbnQgcHJv
YmxlbXMgYXMgZm9sbG93czoNCg0KMS4gSWYgdHVybiBvbiB0aGUgZGF0YSBjYWNoZSwgdGhlIGxp
bnV4IGtlcm5lbCBjYW4ndCBzdGFydCB1cCwgaXQgIGhhbmcgd2hlbiBleGVjdXRpbmcgZm9sbG93
cyBpbnN0cnVjdGlvbjoNCgkvKiBzdGFjayAqLw0KCWFkZGkJcjEscjIsVEFTS19VTklPTl9TSVpF
DQoJbGkJcjAsMA0KCXN0d3UJcjAsLVNUQUNLX0ZSQU1FX09WRVJIRUFEKHIxKQ0KaW4gZmlsZSBh
cmNoL3BwYy9rZXJuZWwvaGVhZC5TLgkJDQogIA0KMi4gSWYgdHVybiBvZmYgdGhlIGRhdGEgY2Fj
aGUsIGtlcm5lbCBjYW4gcnVuIHVudGlsIGRlY29tcHJlc3MgdGhlIHJhbWRpc2ssIHRoZW4gZGVj
b21wcmVzcyByYW1kaXNrIGZhaWxlZC4NCjMuIFRoZSBzYW1lIGtlcm5lbCBydW5uaW5nIG9rIG9u
IG15IG9sZCBNUEM4MjUwIGJvYXJkLg0KDQpFeHBlY3RpbmcgeW91ciBhbnN3ZXIgYW5kIGFkdmlj
ZSwgdGhhbmtzIGluIGFkdmFuY2UhDQoNCkJlc3QgUmVnYXJkcyENCg0K
^ permalink raw reply
* Re: MPC5200/Lite5200 and ethernet
From: Sylvain Munaut @ 2005-06-18 22:15 UTC (permalink / raw)
To: Dale Farnsworth; +Cc: linuxppc-embedded
In-Reply-To: <20050617140022.GA15877@xyzzy.farnsworth.org>
Hi everyone
Following the obvious demand for it :
rsync://gitbits.246tNt.com/gitbits/linux-2.6-mpc52xx.git
http://gitbits.246tNt.com/gitweb.cgi?p=linux-2.6-mpc52xx.git;a=summary
Hopefully the server is setup correctly ...
It's not _heavily_ tested but it seems to works fine in the few test I made.
What in there :
- I2C patches that are already sent upstream but not yet in Linus tree
- Change of the mpc52xx uart device name and device ids to a range in
the low density serial port major. Also it's now named ttyPSC? so
you need to update you kernel command line (else you won't see any
console). Note that the ids and names choosed are NOT YET OFFICIAL,
I just included it in this release because some people were seeing
conflict with the other ids. So the name and ids may change ...
- Some other patches that will soon be sent upstream, just waiting
for you to test see if it has any negative impact.
- FEC and BestComm rewrite from Dale, with some improvement. For eg,
the FEC task now handle misaligment so the manual alignment code
has been removed, ...
Why is not bestcomm upstream already :
There are a lot of minor stuff I don't like currently about it. The
most big part are : it mixes phys and virt address without any care, and
the fec driver needs improvement for the phy handling and for the dma
activity handling. I started working on some of this issues but I got
reassigned to more pressing matters ... The result was never published
because for now the only thing it does well is break everything ;)
If someone wish to clean all that before I come to it, he's welcome
to contact me for info/ideas I had while working on it.
What is gonna be added "soon" :
I'd say PIO IDE. But several people sent me a different version, so
I'll look into them and test them but probably not before next week.
Sylvain
PS: Does any one knows how to change the commit text in git/cg when
committed ? I realized I put "ppc:" at someplaces and "ppc32:" at others
and it's not coherent ...
^ permalink raw reply
* Re: MPC5200/Lite5200 and ethernet
From: Grant Likely @ 2005-06-19 0:40 UTC (permalink / raw)
To: Sylvain Munaut; +Cc: linuxppc-embedded
In-Reply-To: <42B49D04.7050303@246tNt.com>
On 6/18/05, Sylvain Munaut <tnt@246tnt.com> wrote:
> Hi everyone
>=20
> Following the obvious demand for it :
>=20
> rsync://gitbits.246tNt.com/gitbits/linux-2.6-mpc52xx.git
> http://gitbits.246tNt.com/gitweb.cgi?p=3Dlinux-2.6-mpc52xx.git;a=3Dsummar=
y
And there was much rejoicing... (hooraaaay)
Thanks Sylvain, I'll give it a try on Monday.
g.
^ permalink raw reply
* Re: Does any body have HYNIX or AMIC 32M SDRAM reference cdoe?
From: HHPPC Support @ 2005-06-19 1:33 UTC (permalink / raw)
To: �}秤�, linuxppc-embedded; +Cc: R64382
[-- Attachment #1: Type: text/plain, Size: 3344 bytes --]
hi,
This is out of reach of our support , and we have to turn to our R&D for help.
and thus, you may post this to our BBS: bbs.hhcn.com
BR
HHPPC support
======== 2005-06-17 16:07:00 您在来信中写道： ========
Hi All:
I used HY57641620 * 2 total all 16M SDRAM at my MPC852T board, now i want to
used HY57V281620ET-H * 2 or AMIC A43L3616-6 * 2 total all 32M SDRAM, but i don't know
how to setting UPM to control it, i need help.If you used another 32M SDRAM solution,
please tell me, thanks.
#define _NOT_USED_ 0xFFFFFFFF
const uint sdram_table[] = /* for HY57641620 * 2 16M SDRAM */
{
/* Single Read. (offset 0x0-0x4 in UPM RAM) */
/* Precharge and MRS(offset 0x5-0x7 in UPM RAM) */
0x1F07FC04, 0xEEAEFC04, 0x11ADFC04, 0xEFBBBC00,
0x1FF77C47, 0x1FF77C35, 0xEFEABC34, 0x1FB57C35,
/* Burst Read. (offset 0x8-0xf in UPM RAM) */
0x1F07FC04, 0xEEAEFC04, 0x10ADFC04, 0xF0AFFC00,
0xF0AFFC00, 0xF1AFFC00, 0xEFBBBC00, 0x1FF77C47,
_NOT_USED_, _NOT_USED_, _NOT_USED_, _NOT_USED_,
_NOT_USED_, _NOT_USED_, _NOT_USED_, _NOT_USED_,
/* Single Write. (offset 0x18-0x1F in UPM RAM) */
0x1F27FC04, 0xEEAEBC00, 0x01B93C04, 0x1FF77C47,
_NOT_USED_, _NOT_USED_, _NOT_USED_, _NOT_USED_,
/* Burst Write. (offset 20-2F in UPM RAM) */
0x1F07FC04, 0xEEAEBC00, 0x10AD7C00, 0xF0AFFC00,
0xF0AFFC00, 0xE1BBBC04, 0x1FF77C47, _NOT_USED_,
_NOT_USED_, _NOT_USED_, _NOT_USED_, _NOT_USED_,
_NOT_USED_, _NOT_USED_, _NOT_USED_, _NOT_USED_,
/* Refresh timer expired (offset 30-3B in UPM RAM) */
0x1FF5FC84, 0xFFFFFC04, 0xFFFFFC04, 0xFFFFFC04,
0xFFFFFC84, 0xFFFFFC07, 0xffffffff, _NOT_USED_,
_NOT_USED_, _NOT_USED_, _NOT_USED_, _NOT_USED_,
/* Exception. (offset 3c-3f in UPM RAM) */
0x7FFFFC07, _NOT_USED_, _NOT_USED_, _NOT_USED_
};
long int initdram(int board_type)
{
volatile immap_t *immap = (immap_t *)CFG_IMMR;
volatile memctl8xx_t *memctl = &immap->im_memctl;
upmconfig(UPMA, (uint *)sdram_table, sizeof(sdram_table)/sizeof(uint));
memctl->memc_mptpr = 0x0400;
/*
* Configure the refresh (mostly). This needs to be
* based upon processor clock speed and optimized to provide
* the highest level of performance. For multiple banks,
* this time has to be divided by the number of banks.
* Although it is not clear anywhere, it appears the
* refresh steps through the chip selects for this UPM
* on each refresh cycle.
* We have to be careful changing
* UPM registers after we ask it to run these commands.
*/
memctl->memc_mamr = 0xD0904114;
memctl->memc_mar = 0x00000088;
udelay(200);
memctl->memc_mcr = 0x80004105; /* precharge */
udelay(200);
memctl->memc_mamr = 0xD0904114;
memctl->memc_mcr = 0x80004830; /* refresh */
udelay(200);
memctl->memc_mamr = 0xD0904114;
memctl->memc_mcr = 0x80004106;
udelay(200);
memctl->memc_or2 = 0xFE000A00;
memctl->memc_br2 = 0x00000081;
return (32 * 1024 *1024);
} /* end of initdram */
= = = = = = = = = = = = = = = = = = = = = =
HHPPC Support
hhppc-support@hhcn.com
[-- Attachment #2: Type: text/html, Size: 7130 bytes --]
^ permalink raw reply
* MPC8247 Boot Problem.
From: LEO @ 2005-06-19 1:41 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <20050617020003.D221167B28@ozlabs.org>
RGVhciBhbGwsDQpJIGFtIHVzaW5nIEVMREstMy4wLCBhbmQgcG9ydGluZyB0aGUgbGludXgtMi40
LjI0IHRvIG15IE1QQzgyNDcgYm9hcmQsIFUtQm9vdC0xLjAuMiByYW4gb2suIEN1cnJlbnQgcHJv
YmxlbXMgYXMgZm9sbG93czoNCg0KMS4gSWYgdHVybiBvbiB0aGUgZGF0YSBjYWNoZSwgdGhlIGxp
bnV4IGtlcm5lbCBjYW4ndCBzdGFydCB1cCwgaXQgIGhhbmcgd2hlbiBleGVjdXRpbmcgZm9sbG93
cyBpbnN0cnVjdGlvbjoNCgkvKiBzdGFjayAqLw0KCWFkZGkJcjEscjIsVEFTS19VTklPTl9TSVpF
DQoJbGkJcjAsMA0KCXN0d3UJcjAsLVNUQUNLX0ZSQU1FX09WRVJIRUFEKHIxKQ0KaW4gZmlsZSBh
cmNoL3BwYy9rZXJuZWwvaGVhZC5TLgkJDQogIA0KMi4gSWYgdHVybiBvZmYgdGhlIGRhdGEgY2Fj
aGUsIGtlcm5lbCBjYW4gcnVuIHVudGlsIGRlY29tcHJlc3MgdGhlIHJhbWRpc2ssIHRoZW4gZGVj
b21wcmVzcyByYW1kaXNrIGZhaWxlZC4NCjMuIFRoZSBzYW1lIGtlcm5lbCBydW5uaW5nIG9rIG9u
IG15IG9sZCBNUEM4MjUwIGJvYXJkLg0KDQpFeHBlY3RpbmcgeW91ciBhbnN3ZXIgYW5kIGFkdmlj
ZSwgdGhhbmtzIGluIGFkdmFuY2UhDQoNCkJlc3QgUmVnYXJkcyENCg0K
^ permalink raw reply
* Re: problems on isp1362 driver
From: David Jander @ 2005-06-20 10:38 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <20050617191231.B23C0C1510@atlas.denx.de>
On Friday 17 June 2005 21:12, Wolfgang Denk wrote:
> in message <000001c57347$04a45d00$07070a0a@luj> you wrote:
> > We are using Philips ISP1362 usb controller on our ppc-embedded system.
> > We have ported the phlips's driver, PHCI, to ppc. The Philips linux
> > driver is that of 2002.
>
> You cannot do that. The Philips driver comes uner a proprietary
> license which is incompatible with the GPL. You must not use their
> driver in the context of a Linux kernel or any other GPLed software.
> You are either violating the GPL, or the Philips license. Be
> careful!!!
IANAL, but I think theoretically at least, it should be possible, if you
manage to craft sort of a "GPL abstraction layer" around the philips driver,
to shield it from "GPL influence" in the kernel, just like Nvidia and others
do. To the letter of the GPL that is not possible, but AFAIK the linux kernel
license grants an exception that permits binary-only drivers for instance.
Anyway, it probably is a bad and dangerous idea to try to pull this off. As
for me, I decided it is much safer to stay as far away as possible from the
philips source. Looking at it could be fatal for an OSS-coder like me (my
eyes could get poisoned).
Here goes a big "BOOOO" to Philips for doing this in the first place :-(
Greetings,
--
David Jander
^ permalink raw reply
* Disable task rescheduling
From: Garcia Jérémie @ 2005-06-20 13:12 UTC (permalink / raw)
To: linuxppc-dev
Hi everybody, as teh object of this mail tells, I'd like to know if =
there is an easy way
to disable task rescheduling in the kernel.
I explain: I'm writing a device driver and so, I use the ioctl.
In one of my ioctl's, I'd like to have a non-interruptible part =
processed.
int Hscx_ioctl( struct inode *inode,
struct file *file,
unsigned int ioctl_num, /* Number of the =
ioctl to call */
unsigned long argP) /* Paramater to pass =
to the ioctl */
{
[...]
switch(ioctl_num)
{
case GET_LIST:
=20
disable_task_rescheduling(); // what to use???
disable_interrupt(); // spin_lock_irqsave should =
be enough isn't it?
execute_critical_code();
enable_task_rescheduling(); // what to use???
enable_interrupt(); // spin_unlock_irqrestore =
should be enough isn't it?
break;
}
}
Could you give me a tip cause I've browsed the web and technical books =
and I can't find a solution.
Tks a lot
^ permalink raw reply
* Re: Disable task rescheduling
From: Eugene Surovegin @ 2005-06-20 18:22 UTC (permalink / raw)
To: Garcia J?r?mie; +Cc: linuxppc-dev
In-Reply-To: <D4FDDD1349B5AC46B68FC26AD8AF42D6226B3B@exnet.3il.fr>
On Mon, Jun 20, 2005 at 03:12:03PM +0200, Garcia J?r?mie wrote:
> Hi everybody, as teh object of this mail tells, I'd like to know if there is an easy way
> to disable task rescheduling in the kernel.
> I explain: I'm writing a device driver and so, I use the ioctl.
> In one of my ioctl's, I'd like to have a non-interruptible part processed.
>
> int Hscx_ioctl( struct inode *inode,
> struct file *file,
> unsigned int ioctl_num, /* Number of the ioctl to call */
> unsigned long argP) /* Paramater to pass to the ioctl */
> {
> [...]
> switch(ioctl_num)
> {
> case GET_LIST:
>
> disable_task_rescheduling(); // what to use???
> disable_interrupt(); // spin_lock_irqsave should be enough isn't it?
>
> execute_critical_code();
>
> enable_task_rescheduling(); // what to use???
> enable_interrupt(); // spin_unlock_irqrestore should be enough isn't it?
> break;
> }
> }
Disabling interrupts (with spin_lock_irq) also disables kernel
preemption (if enabled, if not - kernel won't preempt current task
anyway when in the driver), so explicitly disable
(disable_task_rescheduling) isn't needed.
--
Eugene
^ permalink raw reply
* Re: problems on isp1362 driver
From: Wolfgang Denk @ 2005-06-20 19:25 UTC (permalink / raw)
To: David Jander; +Cc: linuxppc-embedded
In-Reply-To: <200506201238.19121.david.jander@protonic.nl>
In message <200506201238.19121.david.jander@protonic.nl> you wrote:
>
> IANAL, but I think theoretically at least, it should be possible, if you
> manage to craft sort of a "GPL abstraction layer" around the philips driver,
No, you cannot even do that. The Philips license explicitely forbids
to "combine Open Source Software with the Software or any derivative
work thereof". This effectively prevents any use of the driver in a
Linux environment. Of course you can now ask which sense it makes to
release a Linux driver under such a license, but please don't ask me.
Ask the id^H^Hlawyers at Philips.
> do. To the letter of the GPL that is not possible, but AFAIK the linux kernel
> license grants an exception that permits binary-only drivers for instance.
Please read again. This is allowed only for pre-existing code that
was not written for Linux. And even then it's not really clean. BUt I
seriously doubt that the Philips Linux driver can claim to fall under
this exception.
My interpretation is that an anal-restrictive lawyer came up with a
license once, and some other people applied this license to Linux
drivers without any thinking. If you want to complain, complain at
Philips. Alternatively, just don't use their code. If necessary,
don't use their hardware either. There are other solutions with
better software support.
> for me, I decided it is much safer to stay as far away as possible from the
> philips source. Looking at it could be fatal for an OSS-coder like me (my
> eyes could get poisoned).
> Here goes a big "BOOOO" to Philips for doing this in the first place :-(
100% ACK from me.
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
All your people must learn before you can reach for the stars.
-- Kirk, "The Gamesters of Triskelion", stardate 3259.2
^ permalink raw reply
* [PATCH] GCC4 compile fixes for mpc52xx
From: roger blofeld @ 2005-06-20 19:32 UTC (permalink / raw)
To: Sylvain Munaut; +Cc: linuxppc-embedded
Sylvain,
A quick patch to fix your tree for gcc4
-rb
drivers/net/fec_mpc52xx/fec.c: In function 'fec_reinit':
drivers/net/fec_mpc52xx/fec.c:525: error: invalid storage class for
function 'fec_update_stat'
drivers/serial/mpc52xx_uart.c:707: error: static declaration of
'mpc52xx_uart_driver' follows non-static declaration
drivers/serial/mpc52xx_uart.c:675: error: previous declaration of
'mpc52xx_uart_driver' was here
Signed off by Roger Blofeld <blofeldus@yahoo.com>
diff --git a/drivers/net/fec_mpc52xx/fec.c
b/drivers/net/fec_mpc52xx/fec.c
--- a/drivers/net/fec_mpc52xx/fec.c
+++ b/drivers/net/fec_mpc52xx/fec.c
@@ -522,7 +522,7 @@ static void fec_reinit(struct net_device
{
struct fec_priv *priv = (struct fec_priv *)dev->priv;
struct mpc52xx_fec *fec = priv->fec;
- static void fec_update_stat(struct net_device *);
+ void fec_update_stat(struct net_device *);
netif_stop_queue(dev);
out_be32(&fec->imask, 0x0);
diff --git a/drivers/serial/mpc52xx_uart.c
b/drivers/serial/mpc52xx_uart.c
--- a/drivers/serial/mpc52xx_uart.c
+++ b/drivers/serial/mpc52xx_uart.c
@@ -672,7 +672,7 @@ mpc52xx_console_setup(struct console *co
}
-extern struct uart_driver mpc52xx_uart_driver;
+static struct uart_driver mpc52xx_uart_driver;
static struct console mpc52xx_console = {
.name = "ttyPSC",
no microsoft products were used in the production of this email
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
^ permalink raw reply
* [patch 1/1] [Fwd: [patch 1/3] list_for_each_entry: drivers-macintosh-via-pmu.c]
From: domen @ 2005-06-20 21:52 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev, domen
From: Domen Puncer <domen@coderock.org>
Replace for loops with nice list_for_each* macros.
Signed-off-by: Domen Puncer <domen@coderock.org>
---
via-pmu.c | 16 ++++------------
1 files changed, 4 insertions(+), 12 deletions(-)
Index: quilt/drivers/macintosh/via-pmu.c
===================================================================
--- quilt.orig/drivers/macintosh/via-pmu.c
+++ quilt/drivers/macintosh/via-pmu.c
@@ -2062,8 +2062,7 @@ pmu_register_sleep_notifier(struct pmu_s
struct list_head *list;
struct pmu_sleep_notifier *notifier;
- for (list = sleep_notifiers.next; list != &sleep_notifiers;
- list = list->next) {
+ list_for_each(list, &sleep_notifiers) {
notifier = list_entry(list, struct pmu_sleep_notifier, list);
if (n->priority > notifier->priority)
break;
@@ -2090,8 +2089,7 @@ broadcast_sleep(int when, int fallback)
struct list_head *list;
struct pmu_sleep_notifier *notifier;
- for (list = sleep_notifiers.prev; list != &sleep_notifiers;
- list = list->prev) {
+ list_for_each_prev(list, &sleep_notifiers) {
notifier = list_entry(list, struct pmu_sleep_notifier, list);
ret = notifier->notifier_call(notifier, when);
if (ret != PBOOK_SLEEP_OK) {
@@ -2112,14 +2110,10 @@ static int __pmac
broadcast_wake(void)
{
int ret = PBOOK_SLEEP_OK;
- struct list_head *list;
struct pmu_sleep_notifier *notifier;
- for (list = sleep_notifiers.next; list != &sleep_notifiers;
- list = list->next) {
- notifier = list_entry(list, struct pmu_sleep_notifier, list);
+ list_for_each_entry(notifier, &sleep_notifiers, list)
notifier->notifier_call(notifier, PBOOK_WAKE);
- }
return ret;
}
@@ -2731,15 +2725,13 @@ static void __pmac
pmu_pass_intr(unsigned char *data, int len)
{
struct pmu_private *pp;
- struct list_head *list;
int i;
unsigned long flags;
if (len > sizeof(pp->rb_buf[0].data))
len = sizeof(pp->rb_buf[0].data);
spin_lock_irqsave(&all_pvt_lock, flags);
- for (list = &all_pmu_pvt; (list = list->next) != &all_pmu_pvt; ) {
- pp = list_entry(list, struct pmu_private, list);
+ list_for_each_entry(pp, &all_pmu_pvt, list) {
spin_lock(&pp->lock);
i = pp->rb_put + 1;
if (i >= RB_SIZE)
--
^ 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