* Re: Gdb with MPC85xx
From: Kumar Gala @ 2006-02-03 18:40 UTC (permalink / raw)
To: Fahd Abidi; +Cc: linuxppc-embedded
In-Reply-To: <81C69D96BDD30640952C7A404004AA2501954E@ultsol01.tewks.ultsol.local>
On Fri, 3 Feb 2006, Fahd Abidi wrote:
> Hello,
>
> I am wondering if someone here is using GDB to debug code on an 85xx
> platform with the BDI. I have been running into several issues with GDB
> 5.x and 6.x where the E500 core does not seem to either step properly to
> the next line of code in the kernel or uboot or gets lost altogether.
> Each version of GDB seems to have its own set of bugs. If someone has
> been using a version of GDB that works pretty well then let me know what
> version it is and I can try and download it and build it and see if it
> behaves better.
Are you able to get the registers in GDB properly? The e500 introduces a
different GDB register protocol than standard PPC. This either requires
the latest GDB and possibly BDI firmware. I forget how BDI handles the
different protocol layouts. I'm pretty sure they added support for "full
e500 GDB" recently.
You also, have to build u-boot and your kernel to handle the quicky debug
support on 85xx.
- kumar
^ permalink raw reply
* Gdb with MPC85xx
From: Fahd Abidi @ 2006-02-03 18:41 UTC (permalink / raw)
To: linuxppc-embedded
Hello,
I am wondering if someone here is using GDB to debug code on an 85xx
platform with the BDI. I have been running into several issues with GDB
5.x and 6.x where the E500 core does not seem to either step properly to
the next line of code in the kernel or uboot or gets lost altogether.
Each version of GDB seems to have its own set of bugs. If someone has
been using a version of GDB that works pretty well then let me know what
version it is and I can try and download it and build it and see if it
behaves better.
This is probably more of a tools question then a Linux question, I'm
hoping I can get an answer anyway.
Thanks,
Fahd
=20
^ permalink raw reply
* Re: CPM2 USB driver & MPC8248
From: Alex BASTOS @ 2006-02-03 15:53 UTC (permalink / raw)
To: Laurent Pinchart; +Cc: linuxppc-embedded
In-Reply-To: <200602031346.52937.laurent.pinchart@tbox.biz>
All of them were labelled as USB 2.0, and where also recognized as
USB 2.0 devices in other systems, as x86 workstation with Fedora Core
Best regards
Alex
> > I don't know if it could be of interest for you.
> > I experienced same problem, but only with a subset of the USB storage
> > devices I have tested. There are same which worked fine.
>
> I tried with two USB Mass Storage devices. Both fail but at different stages.
> Do you know if the devices you were able to access were USB 1.1 or USB 2.0
> devices ?
>
> Laurent Pinchart
>
^ permalink raw reply
* AW: How to cross-build OpenSSL shared library
From: Marc.Bodmer @ 2006-02-03 13:59 UTC (permalink / raw)
To: linuxppc-embedded
Thanks Wolfgang, I will check it.
I guess I will need to "spy" there for many other packages.
kind regards
Marc
-----Urspr=FCngliche Nachricht-----
Von: wd@denx.de [mailto:wd@denx.de]
Gesendet: Freitag, 3. Februar 2006 14:44
An: Bodmer Marc, Securiton, ESS
Cc: linuxppc-embedded@ozlabs.org
Betreff: Re: How to cross-build OpenSSL shared library=0D
In message=
<5DDC68DD3569BB4D92D660326A9C095301728952@stnzolex1.securiton.int> you=
wrote:
>=0D
> I am using ELDK (3.1.1) and there is a built OpenSSL as shared library
> available.
> Does anybody know about how they managed to build this shared library?
The DULG describes in detail how to rebuild all ELDK RPMs from the
sources. Just download and install the Source RPM and check the
commands in the spec file.
Best regards,
Wolfgang Denk
--=0D
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
Perl already has an IDE. It's called Unix.
-- Tom Christiansen in 375bd509@cs.colorado.edu
<html>
<body>
<font face =3D "arial" size =3D "1">
---------------------------------------------------------------------------=
------------------------------
This e-mail is confidential and may contain privileged information.
It is intended only for the addressees. If you have received this
e-mail in error, kindly notify us immediately by telephone or e-mail
and delete the message from your system.
---------------------------------------------------------------------------=
------------------------------
</font>
</body>
</html>
^ permalink raw reply
* Re: How to cross-build OpenSSL shared library
From: Wolfgang Denk @ 2006-02-03 13:43 UTC (permalink / raw)
To: Marc.Bodmer; +Cc: linuxppc-embedded
In-Reply-To: <5DDC68DD3569BB4D92D660326A9C095301728952@stnzolex1.securiton.int>
In message <5DDC68DD3569BB4D92D660326A9C095301728952@stnzolex1.securiton.int> you wrote:
>
> I am using ELDK (3.1.1) and there is a built OpenSSL as shared library
> available.
> Does anybody know about how they managed to build this shared library?
The DULG describes in detail how to rebuild all ELDK RPMs from the
sources. Just download and install the Source RPM and check the
commands in the spec file.
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
Perl already has an IDE. It's called Unix.
-- Tom Christiansen in 375bd509@cs.colorado.edu
^ permalink raw reply
* AW: How to cross-build OpenSSL shared library
From: Marc.Bodmer @ 2006-02-03 12:56 UTC (permalink / raw)
To: guilherme.mazzela, linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 3064 bytes --]
Hi, thanks for your answer.
Thats almost what I actually did. Here is my ./Configure call:
./Configure linux-ppc shared zlib-dynamic compiler:${CROSS_COMPILE}gcc --openssldir=$openssl_distdir --prefix=$openssl_bindir
I've tried what you proposed here and it works :-)
I made the mistake to give the compiler to the Configure script instead just at make time...
I did not use the "no-asm" option. Is this needed for PPC or is there mpc8xx asm available?
regards
Marc
-----Ursprüngliche Nachricht-----
Von: Guilherme Mazzela [mailto:guilherme.mazzela@asga.com.br]
Gesendet: Freitag, 3. Februar 2006 12:19
An: Bodmer Marc, Securiton, ESS
Betreff: RE: How to cross-build OpenSSL shared library
try this
./Configure
./Configure linux-ppc --prefix=/usr --openssldir=/etc shared no-asm
make clean
make CC=ppc-linux-gcc
after that you have to strip the libcrypto.so.X.X.X
-----Original Message-----
From: Marc.Bodmer@securiton.ch [ mailto:Marc.Bodmer@securiton.ch]
Sent: Fri 2/3/2006 7:45 AM
To: linuxppc-embedded@ozlabs.org
Cc:
Subject: How to cross-build OpenSSL shared library
Hello
I have a problem with cross compiling the OpenSSL library for PPC (mpc885) as a
shared library (Host x86, Linux).
I give the option "shared" to the "Configure" script delivered with OpenSSL. But it
always only builds me static libraries. After Configuration it shows me the text:
>You gave the option 'shared'. Normally, that would give you shared libraries.
>Unfortunately, the OpenSSL configuration doesn't include shared library support
>for this platform yet, so it will pretend you gave the option 'no-shared'
I am using ELDK (3.1.1) and there is a built OpenSSL as shared library
available.
Does anybody know about how they managed to build this shared library?
Thanks for any help
Marc
<html>
<body>
<font face = "arial" size = "1">
---------------------------------------------------------------------------------------------------------
This e-mail is confidential and may contain privileged information.
It is intended only for the addressees. If you have received this
e-mail in error, kindly notify us immediately by telephone or e-mail
and delete the message from your system.
---------------------------------------------------------------------------------------------------------
</font>
</body>
</html>
<html>
<body>
<font face = "arial" size = "1">
---------------------------------------------------------------------------------------------------------
This e-mail is confidential and may contain privileged information.
It is intended only for the addressees. If you have received this
e-mail in error, kindly notify us immediately by telephone or e-mail
and delete the message from your system.
---------------------------------------------------------------------------------------------------------
</font>
</body>
</html>
[-- Attachment #2: Type: text/html, Size: 5639 bytes --]
^ permalink raw reply
* Re: CPM2 USB driver & MPC8248
From: Laurent Pinchart @ 2006-02-03 12:46 UTC (permalink / raw)
To: Alexandre BASTOS; +Cc: linuxppc-embedded
In-Reply-To: <1138972275.43e356730f889@webmail.televes.com:443>
> I don't know if it could be of interest for you.
> I experienced same problem, but only with a subset of the USB storage
> devices I have tested. There are same which worked fine.
I tried with two USB Mass Storage devices. Both fail but at different stages.
Do you know if the devices you were able to access were USB 1.1 or USB 2.0
devices ?
Laurent Pinchart
^ permalink raw reply
* Re: CPM2 USB driver & MPC8248
From: Alexandre BASTOS @ 2006-02-03 13:11 UTC (permalink / raw)
To: Laurent Pinchart; +Cc: linuxppc-embedded
In-Reply-To: <200602031234.58813.laurent.pinchart@tbox.biz>
I don't know if it could be of interest for you.
I experienced same problem, but only with a subset of the USB storage
devices I have tested. There are same which worked fine.
Best regards,
Alex
> Hi,
>
> after more testing, I found out that only the first 3 control URBs complete
> successfully. I tried to duplicate the first GET_DESCRIPTOR(CONFIG) request,
> and the second one which worked before now fails. If I unplug/replug the
> device, the first GET_DESCRIPTOR(DEVICE) request sent to device 0 from
> hub_port_init fails:
>
> c0450260 133702068 S Ci:000:00 s 80 06 0100 0000 0040 64 <
> c0450260 134700018 C Ci:000:00 -104 0
> c0450260 134700053 S Ci:000:00 s 80 06 0100 0000 0040 64 <
> c0450260 135700016 C Ci:000:00 -104 0
> c0450260 135700049 S Ci:000:00 s 80 06 0100 0000 0040 64 <
> c0450260 136700018 C Ci:000:00 -104 0
>
> Hope this helps to diagnose the problem,
>
> Laurent Pinchart
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
^ permalink raw reply
* Re: CPM2 USB driver & MPC8248
From: Laurent Pinchart @ 2006-02-03 11:34 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <200602031210.12603.laurent.pinchart@tbox.biz>
Hi,
after more testing, I found out that only the first 3 control URBs complete
successfully. I tried to duplicate the first GET_DESCRIPTOR(CONFIG) request,
and the second one which worked before now fails. If I unplug/replug the
device, the first GET_DESCRIPTOR(DEVICE) request sent to device 0 from
hub_port_init fails:
c0450260 133702068 S Ci:000:00 s 80 06 0100 0000 0040 64 <
c0450260 134700018 C Ci:000:00 -104 0
c0450260 134700053 S Ci:000:00 s 80 06 0100 0000 0040 64 <
c0450260 135700016 C Ci:000:00 -104 0
c0450260 135700049 S Ci:000:00 s 80 06 0100 0000 0040 64 <
c0450260 136700018 C Ci:000:00 -104 0
Hope this helps to diagnose the problem,
Laurent Pinchart
^ permalink raw reply
* CPM2 USB driver & MPC8248
From: Laurent Pinchart @ 2006-02-03 11:10 UTC (permalink / raw)
To: mike; +Cc: linuxppc-embedded
Hi Mike,
I'm having trouble using your CPM2 USB host controller driver on an Embedded
Planet EP8248 board with Linux 2.6.15.
The driver didn't compiler with 2.6.15 but the required changes were minor
(the root hub doesn't have to be registered by the host controller driver
anymore, and a few functions have been renamed). I modified the board setup
function according to my hardware (different BCSR registers) and the driver
loads properly.
When I connect a USB 2.0 Mass Storage device, initialization fails when trying
to fetch the string descriptors. Here's what USBMon produces (I decoded the
USB transactions with the device).
/* Initialization */
c054a860 62948014 C Ii:001:01 0 1 D
c054a860 62948089 S Ii:001:01 -115 2 D
c04500e0 62948126 S Ci:001:00 s a3 00 0000 0001 0004 4 <
c04500e0 62948134 C Ci:001:00 0 4 = 01010100
c04500e0 62948146 S Co:001:00 s 23 01 0010 0001 0000 0
c04500e0 62948151 C Co:001:00 0 0
c04500e0 62948158 S Ci:001:00 s a3 00 0000 0001 0004 4 <
c04500e0 62948163 C Ci:001:00 0 4 = 01010000
c04500e0 62980027 S Ci:001:00 s a3 00 0000 0001 0004 4 <
c04500e0 62980045 C Ci:001:00 0 4 = 01010000
c04500e0 63012025 S Ci:001:00 s a3 00 0000 0001 0004 4 <
c04500e0 63012042 C Ci:001:00 0 4 = 01010000
c04500e0 63044025 S Ci:001:00 s a3 00 0000 0001 0004 4 <
c04500e0 63044042 C Ci:001:00 0 4 = 01010000
c04500e0 63076025 S Ci:001:00 s a3 00 0000 0001 0004 4 <
c04500e0 63076043 C Ci:001:00 0 4 = 01010000
c04500e0 63076088 S Co:001:00 s 23 03 0004 0001 0000 0
c04500e0 63172013 C Co:001:00 0 0
c04500e0 63228024 S Ci:001:00 s a3 00 0000 0001 0004 4 <
c04500e0 63228042 C Ci:001:00 0 4 = 03010000
c04500e0 63284035 S Co:001:00 s 23 01 0014 0001 0000 0
c04500e0 63284052 C Co:001:00 0 0
c04500e0 63456779 S Ci:000:00 s 80 06 0100 0000 0040 64 <
c04500e0 63457301 C Ci:000:00 0 18 = 12010002 00000040 81075051 20000102 0301
c04500e0 63457338 S Co:001:00 s 23 03 0004 0001 0000 0
c04500e0 63552013 C Co:001:00 0 0
c04500e0 63608025 S Ci:001:00 s a3 00 0000 0001 0004 4 <
c04500e0 63608043 C Ci:001:00 0 4 = 03010000
c04500e0 63664025 S Co:001:00 s 23 01 0014 0001 0000 0
c04500e0 63664042 C Co:001:00 0 0
c04500e0 63664055 S Co:000:00 s 00 05 0002 0000 0000 0
c04500e0 63664590 C Co:000:00 0 0
/* GET_DESCRIPTOR DEVICE 0x12 bytes */
c04500e0 63680039 S Ci:002:00 s 80 06 0100 0000 0012 18 <
c04500e0 63680781 C Ci:002:00 0 18 = 12010002 00000040 81075051 20000102 0301
/* GET_DESCRIPTOR CONFIGURATION 0x09 bytes */
c04500e0 63680825 S Ci:002:00 s 80 06 0200 0000 0009 9 <
c04500e0 63681795 C Ci:002:00 0 9 = 09022000 01010080 32
/* GET_DESCRIPTOR CONFIGURATION 0x20 bytes */
c04500e0 63681832 S Ci:002:00 s 80 06 0200 0000 0020 32 <
c04500e0 63682820 C Ci:002:00 0 32 = 09022000 01010080 32090400 00020806
50000705 81024000 00070501 02400000
/* GET_DESCRIPTOR STRING 0xff bytes */
c0450140 63682877 S Ci:002:00 s 80 06 0300 0000 00ff 255 <
c0450140 68680032 C Ci:002:00 -104 0
/* GET_DESCRIPTOR STRING 0x02 bytes */
c0450140 68680075 S Ci:002:00 s 80 06 0300 0000 0002 2 <
c0450140 73680032 C Ci:002:00 -104 0
/* GET_DESCRIPTOR STRING 0xff bytes */
c0450140 73725213 S Ci:002:00 s 80 06 0300 0000 00ff 255 <
c0450140 78724036 C Ci:002:00 -104 0
/* GET_DESCRIPTOR STRING 0x02 bytes */
c0450140 78724141 S Ci:002:00 s 80 06 0300 0000 0002 2 <
c0450140 83724019 C Ci:002:00 -104 0
/* GET_DESCRIPTOR STRING 0xff bytes */
c0450140 83769592 S Ci:002:00 s 80 06 0300 0000 00ff 255 <
c0450140 88768017 C Ci:002:00 -104 0
/* GET_DESCRIPTOR STRING 0x02 bytes */
c0450140 88768053 S Ci:002:00 s 80 06 0300 0000 0002 2 <
c0450140 93768016 C Ci:002:00 -104 0
/* SET_CONFIGURATION 1 */
c0450140 93814145 S Co:002:00 s 00 09 0001 0000 0000 0
c0450140 98812017 C Co:002:00 -104 0
As you can see, the devices sends its device and configuration descriptors,
but something goes wrong with the string descriptors. I modified the core USB
code to request 0x40 bytes (which is the value of bMaxPacketSize0) or even
0x20 bytes, but the same problem occurs (same USBMon traces with 0xff
replaced by 0x40).
Could you help me ? Kernel coding is not a problem, so I can make experiments
if you point me to some direction. I'm also quite familiar with the USB specs
down to the various types of transfers (control, interrupt, bulk and
isochronous) but not with the lower-level protocol (frames, tokens, ...). I
can learn if needed.
Laurent Pinchart
^ permalink raw reply
* How to cross-build OpenSSL shared library
From: Marc.Bodmer @ 2006-02-03 9:45 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 1336 bytes --]
Hello
I have a problem with cross compiling the OpenSSL library for PPC (mpc885) as a
shared library (Host x86, Linux).
I give the option "shared" to the "Configure" script delivered with OpenSSL. But it
always only builds me static libraries. After Configuration it shows me the text:
>You gave the option 'shared'. Normally, that would give you shared libraries.
>Unfortunately, the OpenSSL configuration doesn't include shared library support
>for this platform yet, so it will pretend you gave the option 'no-shared'
I am using ELDK (3.1.1) and there is a built OpenSSL as shared library
available.
Does anybody know about how they managed to build this shared library?
Thanks for any help
Marc
<html>
<body>
<font face = "arial" size = "1">
---------------------------------------------------------------------------------------------------------
This e-mail is confidential and may contain privileged information.
It is intended only for the addressees. If you have received this
e-mail in error, kindly notify us immediately by telephone or e-mail
and delete the message from your system.
---------------------------------------------------------------------------------------------------------
</font>
</body>
</html>
[-- Attachment #2: Type: text/html, Size: 5156 bytes --]
^ permalink raw reply
* Re: [patch 14/44] generic hweight{64,32,16,8}()
From: Ulrich Eckhardt @ 2006-02-03 8:31 UTC (permalink / raw)
To: Akinobu Mita
Cc: linux-mips, linux-ia64, Ian Molton, Andi Kleen, David Howells,
linuxppc-dev, Greg Ungerer, sparclinux, Miles Bader,
Yoshinori Sato, Hirokazu Takata, linuxsh-dev, Linus Torvalds,
Ivan Kokshaysky, Richard Henderson, Chris Zankel, dev-etrax,
ultralinux, linux-m68k, linux-kernel, linuxsh-shmedia-dev,
linux390, Russell King, parisc-linux
In-Reply-To: <20060201090325.905071000@localhost.localdomain>
On Wednesday 01 February 2006 10:02, Akinobu Mita wrote:
> unsigned int hweight32(unsigned int w);
> unsigned int hweight16(unsigned int w);
> unsigned int hweight8(unsigned int w);
> unsigned long hweight64(__u64 w);
IMHO, this should use explicitly sized integers like __u8, __u16 etc, unless
there are stringent reasons like better register use - which is hard to tell
for generic C code. Also, why on earth is the returntype for hweight64 a
long?
> +static inline unsigned int hweight32(unsigned int w)
> +{
> + unsigned int res = (w & 0x55555555) + ((w >> 1) & 0x55555555);
> + res = (res & 0x33333333) + ((res >> 2) & 0x33333333);
[...]
Why not use unsigned constants here?
> +static inline unsigned long hweight64(__u64 w)
> +{
[..]
> + u64 res;
> + res = (w & 0x5555555555555555ul) + ((w >> 1) & 0x5555555555555555ul);
Why not use initialisation here, too?
just my 2c
Uli
^ permalink raw reply
* Re: spinlockup detection on POWER3
From: Olaf Hering @ 2006-02-03 8:04 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20060122083826.GA5292@suse.de>
On Sun, Jan 22, Olaf Hering wrote:
> Does the CONFIG_DEBUG_SPINLOCK code somehow depend on the cpu type?
> It triggers alot on a p270 POWER3 box, even during early boot. I dont
> see it on POWE4/5.
> BUG: spinlock lockup on CPU#3, hotplug/1384, c000000000456900
...
this was cause by per_cpu data corruption.
--
short story of a lazy sysadmin:
alias appserv=wotan
^ permalink raw reply
* Re: [parisc-linux] [patch 12/44] generic sched_find_first_bit()
From: Grant Grundler @ 2006-02-03 3:58 UTC (permalink / raw)
To: Akinobu Mita
Cc: linux-mips, linux-ia64, Ian Molton, Andi Kleen, David Howells,
linuxppc-dev, Greg Ungerer, sparclinux, Miles Bader,
Yoshinori Sato, Hirokazu Takata, linuxsh-shmedia-dev,
Linus Torvalds, Chris Zankel, dev-etrax, ultralinux, linux-m68k,
linux-kernel, linuxsh-dev, linux390, Russell King, parisc-linux
In-Reply-To: <20060201090325.497639000@localhost.localdomain>
On Wed, Feb 01, 2006 at 06:02:36PM +0900, Akinobu Mita wrote:
> This patch introduces the C-language equivalent of the function:
> int sched_find_first_bit(const unsigned long *b);
Akinobu, would you prefer this is a slightly cleaner way?
(Not compile tested)
static inline int sched_find_first_bit(const unsigned long *b)
{
if (unlikely(b[0]))
return __ffs(b[0]);
if (unlikely(b[1]))
return __ffs(b[1]) + BITS_PER_LONG;
#if BITS_PER_LONG == 32
if (unlikely(b[2]))
return __ffs(b[2]) + 64;
if (b[3])
return __ffs(b[3]) + 96;
#endif
return __ffs(b[128/BITS_PER_LONG]) + 128;
}
If BITS_PER_LONG isn't defined, the link step will fail and point
at a some unknown .o as the offender. But it's the responsibility
of the header file to make sure it's including the BITS_PER_LONG
definition, not the code that calls sched_find_first_bit().
hth,
grant
^ permalink raw reply
* test
From: Stephen Rothwell @ 2006-02-03 3:31 UTC (permalink / raw)
To: linuxppc-embedded
Please ignore
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
^ permalink raw reply
* [PATCH] powerpc: Add missing vmlinux.bin target
From: Geoff Levand @ 2006-02-02 23:41 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Kumar Gala, linuxppc-dev
In-Reply-To: <Pine.LNX.4.44.0511231242510.4183-100000@gate.crashing.org>
With this patch 'make vmlinux.bin' works. This is needed by
some embedded platforms. Kumar already added the routines
to actually build the image in arch/powerpc/boot/Makefile.
Signed-off-by: Geoff Levand <geoffrey.levand@am.sony.com>
--
Index: powerpc-merge.git/arch/powerpc/Makefile
===================================================================
--- powerpc-merge.git.orig/arch/powerpc/Makefile 2006-02-02 15:23:03.000000000 -0800
+++ powerpc-merge.git/arch/powerpc/Makefile 2006-02-02 15:23:53.000000000 -0800
@@ -147,7 +147,7 @@
CPPFLAGS_vmlinux.lds := -Upowerpc
-BOOT_TARGETS = zImage zImage.initrd znetboot znetboot.initrd vmlinux.sm uImage
+BOOT_TARGETS = zImage zImage.initrd znetboot znetboot.initrd vmlinux.sm uImage vmlinux.bin
.PHONY: $(BOOT_TARGETS)
^ permalink raw reply
* [PATCH] fix generic_fls64()
From: Akinobu Mita @ 2006-02-03 1:27 UTC (permalink / raw)
To: Rune Torgersen
Cc: akpm, linux-mips, linux-ia64, Stephen Hemminger, Ian Molton,
Andi Kleen, David Howells, linuxppc-dev, Greg Ungerer, sparclinux,
Miles Bader, Yoshinori Sato, Hirokazu Takata, linuxsh-dev,
Linus Torvalds, Ivan Kokshaysky, Richard Henderson, Chris Zankel,
dev-etrax, ultralinux, linux-m68k, linux-kernel,
linuxsh-shmedia-dev, linux390, Russell King, parisc-linux
In-Reply-To: <DCEAAC0833DD314AB0B58112AD99B93B859547@ismail.innsys.innovsys.com>
Noticed by Rune Torgersen.
fix generic_fls64().
tcp_cubic is using fls64().
Signed-off-by: Akinobu Mita <mita@miraclelinux.com>
include/linux/bitops.h | 2 +-
1 files changed, 1 insertion(+), 1 deletion(-)
Index: 2.6-git/include/linux/bitops.h
===================================================================
--- 2.6-git.orig/include/linux/bitops.h
+++ 2.6-git/include/linux/bitops.h
@@ -81,7 +81,7 @@ static inline int generic_fls64(__u64 x)
{
__u32 h = x >> 32;
if (h)
- return fls(x) + 32;
+ return fls(h) + 32;
return fls(x);
}
^ permalink raw reply
* Re: [PATCH] Add fec support for mpc52xx
From: Sylvain Munaut @ 2006-02-03 0:19 UTC (permalink / raw)
To: Dale Farnsworth, linuxppc-embedded, jrigby
In-Reply-To: <20060202193734.22145.qmail@farnsworth.org>
Dale Farnsworth wrote:
> In article <43E24DA6.9@freescale.com> John Rigby wrote:
>
>>Adds fec support, requires bestcom patch. Applies to Sylvains git tree.
>
>
> Hmm, I thought that fec support was already in Sylvain's git tree.
>
> I'm sure Sylvain intended it to be there.
Yup, after the recent updates that went upstream, I re-created more
cleanly my git tree. To keep it clean, I took my time to try out several
git feature and stuff before publishing result. For now the bcomm is
available as a patch and I posted the URL recently.
The splitted vesion should be uploaded tomorrow, I'll make sure I use
the latest microcode (compare with the one sent by John) but It's
getting late here.
If you don't get up too early, it should be done by the time you get up ;)
Sylvain
>
> From http://ozlabs.org/pipermail/linuxppc-embedded/2005-June/018887.html:
>
>>Date: Sun, 19 Jun 2005 00:15:32 +0200
>>From: Sylvain Munaut <tnt@246tNt.com>
>>
>>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, ...
>
>
> I hope Sylvain can resurrect the 2.6 FEC code that he, I and others
> worked on.
>
> -Dale
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
^ permalink raw reply
* Re: SPI flash kernel 2.4 driver
From: Ron Kellam @ 2006-02-02 22:26 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <20060131211155.BF9193535E8@atlas.denx.de>
On Tue, 31 Jan 2006 22:11:55 +0100, Wolfgang Denk <wd@denx.de> wrote:
>The Katix SPI framework is integrated with our 2.4 kernel; see
>drivers/spi
It might be integrated, but it's seriously broken. IIRC, the whole
chip select mechanism is not working, and the code still has a lot of
I2Cisms about it.
Regards,
Ron
^ permalink raw reply
* Re: opening the serial port from userspace application
From: Wolfgang Denk @ 2006-02-02 20:13 UTC (permalink / raw)
To: Vitaly Bordug; +Cc: bharathi kandimalla, linuxppc-embedded
In-Reply-To: <20060202144520.3422129b@vitb.ru.mvista.com>
In message <20060202144520.3422129b@vitb.ru.mvista.com> you wrote:
>
> >From what I can see, you have misconfigured something. Dunno for certain, but 860T
> might have 2 UARTs, when you have at least 4 enabled. Please enable in the kernel configuration only those which exist on your board.
You can have up to 6 UART ports on a 860 (2 x SMC + 4 x SCC).
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
Don't tell me how hard you work. Tell me how much you get done.
-- James J. Ling
^ permalink raw reply
* [PATCH] powerpc: Lindent platforms/83xx
From: Kumar Gala @ 2006-02-02 19:51 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
Ran arch/powerpc/platforms/83xx through Lindent
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
---
commit 07128b4c47be22093a6c4a1972bae78994e2d11c
tree 0f81fd48006d8b92598cd23d89ab07910756711a
parent 3a37a9fa1aa28844651449eda0c31485ad202b01
author Kumar Gala <galak@kernel.crashing.org> Thu, 02 Feb 2006 13:48:35 -0600
committer Kumar Gala <galak@kernel.crashing.org> Thu, 02 Feb 2006 13:48:35 -0600
arch/powerpc/platforms/83xx/mpc834x_sys.c | 31 +++++++++++++----------------
arch/powerpc/platforms/83xx/mpc834x_sys.h | 2 +-
arch/powerpc/platforms/83xx/mpc83xx.h | 2 +-
arch/powerpc/platforms/83xx/pci.c | 8 ++++---
4 files changed, 20 insertions(+), 23 deletions(-)
diff --git a/arch/powerpc/platforms/83xx/mpc834x_sys.c b/arch/powerpc/platforms/83xx/mpc834x_sys.c
index 7d5a278..7c18b4c 100644
--- a/arch/powerpc/platforms/83xx/mpc834x_sys.c
+++ b/arch/powerpc/platforms/83xx/mpc834x_sys.c
@@ -69,15 +69,14 @@ mpc83xx_map_irq(struct pci_dev *dev, uns
const long min_idsel = 0x11, max_idsel = 0x20, irqs_per_slot = 4;
return PCI_IRQ_TABLE_LOOKUP;
}
-#endif /* CONFIG_PCI */
+#endif /* CONFIG_PCI */
/* ************************************************************************
*
* Setup the architecture
*
*/
-static void __init
-mpc834x_sys_setup_arch(void)
+static void __init mpc834x_sys_setup_arch(void)
{
struct device_node *np;
@@ -86,14 +85,14 @@ mpc834x_sys_setup_arch(void)
np = of_find_node_by_type(NULL, "cpu");
if (np != 0) {
- unsigned int *fp = (int *) get_property(np, "clock-frequency", NULL);
+ unsigned int *fp =
+ (int *)get_property(np, "clock-frequency", NULL);
if (fp != 0)
loops_per_jiffy = *fp / HZ;
else
loops_per_jiffy = 50000000 / HZ;
of_node_put(np);
}
-
#ifdef CONFIG_PCI
for (np = NULL; (np = of_find_node_by_type(np, "pci")) != NULL;)
add_bridge(np);
@@ -104,14 +103,13 @@ mpc834x_sys_setup_arch(void)
#endif
#ifdef CONFIG_ROOT_NFS
- ROOT_DEV = Root_NFS;
+ ROOT_DEV = Root_NFS;
#else
- ROOT_DEV = Root_HDA1;
+ ROOT_DEV = Root_HDA1;
#endif
}
-void __init
-mpc834x_sys_init_IRQ(void)
+void __init mpc834x_sys_init_IRQ(void)
{
u8 senses[8] = {
0, /* EXT 0 */
@@ -140,28 +138,27 @@ mpc834x_sys_init_IRQ(void)
}
#if defined(CONFIG_I2C_MPC) && defined(CONFIG_SENSORS_DS1374)
-extern ulong ds1374_get_rtc_time(void);
-extern int ds1374_set_rtc_time(ulong);
+extern ulong ds1374_get_rtc_time(void);
+extern int ds1374_set_rtc_time(ulong);
-static int __init
-mpc834x_rtc_hookup(void)
+static int __init mpc834x_rtc_hookup(void)
{
- struct timespec tv;
+ struct timespec tv;
ppc_md.get_rtc_time = ds1374_get_rtc_time;
ppc_md.set_rtc_time = ds1374_set_rtc_time;
tv.tv_nsec = 0;
- tv.tv_sec = (ppc_md.get_rtc_time)();
+ tv.tv_sec = (ppc_md.get_rtc_time) ();
do_settimeofday(&tv);
return 0;
}
+
late_initcall(mpc834x_rtc_hookup);
#endif
-void __init
-platform_init(void)
+void __init platform_init(void)
{
/* setup the PowerPC module struct */
ppc_md.setup_arch = mpc834x_sys_setup_arch;
diff --git a/arch/powerpc/platforms/83xx/mpc834x_sys.h b/arch/powerpc/platforms/83xx/mpc834x_sys.h
index e4ca39f..fedecb7 100644
--- a/arch/powerpc/platforms/83xx/mpc834x_sys.h
+++ b/arch/powerpc/platforms/83xx/mpc834x_sys.h
@@ -20,4 +20,4 @@
#define PIRQC MPC83xx_IRQ_EXT6
#define PIRQD MPC83xx_IRQ_EXT7
-#endif /* __MACH_MPC83XX_SYS_H__ */
+#endif /* __MACH_MPC83XX_SYS_H__ */
diff --git a/arch/powerpc/platforms/83xx/mpc83xx.h b/arch/powerpc/platforms/83xx/mpc83xx.h
index 228d5c4..01cae10 100644
--- a/arch/powerpc/platforms/83xx/mpc83xx.h
+++ b/arch/powerpc/platforms/83xx/mpc83xx.h
@@ -14,4 +14,4 @@ extern int mpc83xx_exclude_device(u_char
extern void mpc83xx_restart(char *cmd);
extern long mpc83xx_time_init(void);
-#endif /* __MPC83XX_H__ */
+#endif /* __MPC83XX_H__ */
diff --git a/arch/powerpc/platforms/83xx/pci.c b/arch/powerpc/platforms/83xx/pci.c
index 70e28fc..16f7d3b 100644
--- a/arch/powerpc/platforms/83xx/pci.c
+++ b/arch/powerpc/platforms/83xx/pci.c
@@ -61,7 +61,7 @@ int __init add_bridge(struct device_node
has_address = (of_address_to_resource(dev, 0, &rsrc) == 0);
/* Get bus range if any */
- bus_range = (int *) get_property(dev, "bus-range", &len);
+ bus_range = (int *)get_property(dev, "bus-range", &len);
if (bus_range == NULL || len < 2 * sizeof(int)) {
printk(KERN_WARNING "Can't get bus-range for %s, assume"
" bus 0\n", dev->full_name);
@@ -83,7 +83,7 @@ int __init add_bridge(struct device_node
if ((rsrc.start & 0xfffff) == 0x8500) {
setup_indirect_pci(hose, immr + 0x8300, immr + 0x8304);
}
- /* PCI 2*/
+ /* PCI 2 */
if ((rsrc.start & 0xfffff) == 0x8600) {
setup_indirect_pci(hose, immr + 0x8380, immr + 0x8384);
primary = 0;
@@ -93,10 +93,10 @@ int __init add_bridge(struct device_node
printk(KERN_INFO "Found MPC83xx PCI host bridge at 0x%08lx. "
"Firmware bus number: %d->%d\n",
- rsrc.start, hose->first_busno, hose->last_busno);
+ rsrc.start, hose->first_busno, hose->last_busno);
DBG(" ->Hose at 0x%p, cfg_addr=0x%p,cfg_data=0x%p\n",
- hose, hose->cfg_addr, hose->cfg_data);
+ hose, hose->cfg_addr, hose->cfg_data);
/* Interpret the "ranges" property */
/* This also maps the I/O region and sets isa_io/mem_base */
^ permalink raw reply related
* [PATCH] powerpc: Cleanup MPC83xx platform support
From: Kumar Gala @ 2006-02-02 19:50 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
Moved some code around so its usable by more systems than just
the MPC834x SYS.
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
---
commit 3a37a9fa1aa28844651449eda0c31485ad202b01
tree 30998d96fa22fbab7517be304fc004ba02377181
parent 7ddda6a6630d95f800fbf848b00bd1d685c9bba4
author Kumar Gala <galak@kernel.crashing.org> Thu, 02 Feb 2006 13:16:20 -0600
committer Kumar Gala <galak@kernel.crashing.org> Thu, 02 Feb 2006 13:16:20 -0600
arch/powerpc/platforms/83xx/Makefile | 4 ++
arch/powerpc/platforms/83xx/misc.c | 55 ++++++++++++++++++++++++++++
arch/powerpc/platforms/83xx/mpc834x_sys.c | 58 -----------------------------
arch/powerpc/platforms/83xx/mpc83xx.h | 3 ++
arch/powerpc/platforms/83xx/pci.c | 13 +++++--
5 files changed, 71 insertions(+), 62 deletions(-)
diff --git a/arch/powerpc/platforms/83xx/Makefile b/arch/powerpc/platforms/83xx/Makefile
index 9d8b28e..5c72367 100644
--- a/arch/powerpc/platforms/83xx/Makefile
+++ b/arch/powerpc/platforms/83xx/Makefile
@@ -1,4 +1,6 @@
#
# Makefile for the PowerPC 83xx linux kernel.
#
-obj-$(CONFIG_MPC834x_SYS) += mpc834x_sys.o pci.o
+obj-y := misc.o
+obj-$(CONFIG_PCI) += pci.o
+obj-$(CONFIG_MPC834x_SYS) += mpc834x_sys.o
diff --git a/arch/powerpc/platforms/83xx/misc.c b/arch/powerpc/platforms/83xx/misc.c
new file mode 100644
index 0000000..0eb3d99
--- /dev/null
+++ b/arch/powerpc/platforms/83xx/misc.c
@@ -0,0 +1,55 @@
+/*
+ * misc setup functions for MPC83xx
+ *
+ * Maintainer: Kumar Gala <galak@kernel.crashing.org>
+ *
+ * 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.
+ */
+
+#include <linux/config.h>
+#include <linux/stddef.h>
+#include <linux/kernel.h>
+
+#include <asm/io.h>
+#include <asm/hw_irq.h>
+#include <sysdev/fsl_soc.h>
+
+#include "mpc83xx.h"
+
+void mpc83xx_restart(char *cmd)
+{
+#define RST_OFFSET 0x00000900
+#define RST_PROT_REG 0x00000018
+#define RST_CTRL_REG 0x0000001c
+ __be32 __iomem *reg;
+
+ /* map reset register space */
+ reg = ioremap(get_immrbase() + 0x900, 0xff);
+
+ local_irq_disable();
+
+ /* enable software reset "RSTE" */
+ out_be32(reg + (RST_PROT_REG >> 2), 0x52535445);
+
+ /* set software hard reset */
+ out_be32(reg + (RST_CTRL_REG >> 2), 0x52535445);
+ for (;;) ;
+}
+
+long __init mpc83xx_time_init(void)
+{
+#define SPCR_OFFSET 0x00000110
+#define SPCR_TBEN 0x00400000
+ __be32 __iomem *spcr = ioremap(get_immrbase() + SPCR_OFFSET, 4);
+ __be32 tmp;
+
+ tmp = in_be32(spcr);
+ out_be32(spcr, tmp | SPCR_TBEN);
+
+ iounmap(spcr);
+
+ return 0;
+}
diff --git a/arch/powerpc/platforms/83xx/mpc834x_sys.c b/arch/powerpc/platforms/83xx/mpc834x_sys.c
index 2098dd0..7d5a278 100644
--- a/arch/powerpc/platforms/83xx/mpc834x_sys.c
+++ b/arch/powerpc/platforms/83xx/mpc834x_sys.c
@@ -24,22 +24,15 @@
#include <linux/delay.h>
#include <linux/seq_file.h>
#include <linux/root_dev.h>
-#include <linux/module.h>
-#include <linux/fsl_devices.h>
#include <asm/system.h>
-#include <asm/pgtable.h>
-#include <asm/page.h>
#include <asm/atomic.h>
#include <asm/time.h>
#include <asm/io.h>
#include <asm/machdep.h>
#include <asm/ipic.h>
#include <asm/bootinfo.h>
-#include <asm/pci-bridge.h>
-#include <asm/mpc83xx.h>
#include <asm/irq.h>
-#include <mm/mmu_decl.h>
#include <asm/prom.h>
#include <asm/udbg.h>
#include <sysdev/fsl_soc.h>
@@ -52,8 +45,6 @@ unsigned long isa_mem_base = 0;
#endif
#ifdef CONFIG_PCI
-extern int mpc83xx_pci2_busno;
-
static int
mpc83xx_map_irq(struct pci_dev *dev, unsigned char idsel, unsigned char pin)
{
@@ -78,17 +69,6 @@ mpc83xx_map_irq(struct pci_dev *dev, uns
const long min_idsel = 0x11, max_idsel = 0x20, irqs_per_slot = 4;
return PCI_IRQ_TABLE_LOOKUP;
}
-
-static int
-mpc83xx_exclude_device(u_char bus, u_char devfn)
-{
- if (bus == 0 && PCI_SLOT(devfn) == 0)
- return PCIBIOS_DEVICE_NOT_FOUND;
- if (mpc83xx_pci2_busno)
- if (bus == (mpc83xx_pci2_busno) && PCI_SLOT(devfn) == 0)
- return PCIBIOS_DEVICE_NOT_FOUND;
- return PCIBIOS_SUCCESSFUL;
-}
#endif /* CONFIG_PCI */
/* ************************************************************************
@@ -180,42 +160,6 @@ mpc834x_rtc_hookup(void)
late_initcall(mpc834x_rtc_hookup);
#endif
-static void
-mpc83xx_restart(char *cmd)
-{
-#define RST_OFFSET 0x00000900
-#define RST_PROT_REG 0x00000018
-#define RST_CTRL_REG 0x0000001c
- __be32 __iomem *reg;
-
- // map reset register space
- reg = ioremap(get_immrbase() + 0x900, 0xff);
-
- local_irq_disable();
-
- /* enable software reset "RSTE" */
- out_be32(reg + (RST_PROT_REG >> 2), 0x52535445);
-
- /* set software hard reset */
- out_be32(reg + (RST_CTRL_REG >> 2), 0x52535445);
- for(;;);
-}
-
-static long __init
-mpc83xx_time_init(void)
-{
-#define SPCR_OFFSET 0x00000110
-#define SPCR_TBEN 0x00400000
- __be32 __iomem *spcr = ioremap(get_immrbase() + SPCR_OFFSET, 4);
- __be32 tmp;
-
- tmp = in_be32(spcr);
- out_be32(spcr, tmp|SPCR_TBEN);
-
- iounmap(spcr);
-
- return 0;
-}
void __init
platform_init(void)
{
@@ -239,5 +183,3 @@ platform_init(void)
return;
}
-
-
diff --git a/arch/powerpc/platforms/83xx/mpc83xx.h b/arch/powerpc/platforms/83xx/mpc83xx.h
index ce9e66a..228d5c4 100644
--- a/arch/powerpc/platforms/83xx/mpc83xx.h
+++ b/arch/powerpc/platforms/83xx/mpc83xx.h
@@ -10,5 +10,8 @@
*/
extern int add_bridge(struct device_node *dev);
+extern int mpc83xx_exclude_device(u_char bus, u_char devfn);
+extern void mpc83xx_restart(char *cmd);
+extern long mpc83xx_time_init(void);
#endif /* __MPC83XX_H__ */
diff --git a/arch/powerpc/platforms/83xx/pci.c b/arch/powerpc/platforms/83xx/pci.c
index 469cdac..70e28fc 100644
--- a/arch/powerpc/platforms/83xx/pci.c
+++ b/arch/powerpc/platforms/83xx/pci.c
@@ -36,7 +36,16 @@
int mpc83xx_pci2_busno;
-#ifdef CONFIG_PCI
+int mpc83xx_exclude_device(u_char bus, u_char devfn)
+{
+ if (bus == 0 && PCI_SLOT(devfn) == 0)
+ return PCIBIOS_DEVICE_NOT_FOUND;
+ if (mpc83xx_pci2_busno)
+ if (bus == (mpc83xx_pci2_busno) && PCI_SLOT(devfn) == 0)
+ return PCIBIOS_DEVICE_NOT_FOUND;
+ return PCIBIOS_SUCCESSFUL;
+}
+
int __init add_bridge(struct device_node *dev)
{
int len;
@@ -95,5 +104,3 @@ int __init add_bridge(struct device_node
return 0;
}
-
-#endif
^ permalink raw reply related
* Re: [PATCH] Add fec support for mpc52xx
From: John Rigby @ 2006-02-02 19:54 UTC (permalink / raw)
To: Dale Farnsworth; +Cc: Linuxppc-embedded
In-Reply-To: <20060202193734.22145.qmail@farnsworth.org>
Sylvain has not added bestcomm/fec to his latest tree yet:
http://gitbits.246tNt.com/gitbits/linux-2.6-mpc52xx
you need to apply this patch:
http://gitbits.246tNt.com/patches/bcomm-to-split.diff
The patches I sent to the list are just newer bestcomm code from
freescale and an fec driver that works with it. I don't make
any claims about it being better just newer and different.
(I haven't cleanly splitted it up yet and right now I must go, so it's
probably gonna be in the git tree this week, under the 'bestcomm' head ;)
On 2 Feb 2006 19:37:34 -0000, Dale Farnsworth <dale@farnsworth.org> wrote:
> In article <43E24DA6.9@freescale.com> John Rigby wrote:
> > Adds fec support, requires bestcom patch. Applies to Sylvains git tree=
.
>
> Hmm, I thought that fec support was already in Sylvain's git tree.
>
> I'm sure Sylvain intended it to be there.
>
> From http://ozlabs.org/pipermail/linuxppc-embedded/2005-June/018887.html:
> > Date: Sun, 19 Jun 2005 00:15:32 +0200
> > From: Sylvain Munaut <tnt@246tNt.com>
> >
> > Following the obvious demand for it :
> >
> > rsync://gitbits.246tNt.com/gitbits/linux-2.6-mpc52xx.git
> > http://gitbits.246tNt.com/gitweb.cgi?p=3Dlinux-2.6-mpc52xx.git;a=3Dsumm=
ary
> >
> > 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, ...
>
> I hope Sylvain can resurrect the 2.6 FEC code that he, I and others
> worked on.
>
> -Dale
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
^ permalink raw reply
* Re: [PATCH] Add fec support for mpc52xx
From: Dale Farnsworth @ 2006-02-02 19:37 UTC (permalink / raw)
To: linuxppc-embedded; +Cc: Sylvain Munaut, John Rigby
In-Reply-To: <43E24DA6.9@freescale.com>
In article <43E24DA6.9@freescale.com> John Rigby wrote:
> Adds fec support, requires bestcom patch. Applies to Sylvains git tree.
Hmm, I thought that fec support was already in Sylvain's git tree.
I'm sure Sylvain intended it to be there.
>From http://ozlabs.org/pipermail/linuxppc-embedded/2005-June/018887.html:
> Date: Sun, 19 Jun 2005 00:15:32 +0200
> From: Sylvain Munaut <tnt@246tNt.com>
>
> 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, ...
I hope Sylvain can resurrect the 2.6 FEC code that he, I and others
worked on.
-Dale
^ permalink raw reply
* Re: Accessing the CPM2 on an MPC82xx : CPM_MAP_ADDR or cpm2_immr ?
From: Dan Malek @ 2006-02-02 18:55 UTC (permalink / raw)
To: Laurent Pinchart; +Cc: linuxppc-embedded
In-Reply-To: <200602021642.49282.laurent.pinchart@tbox.biz>
On Feb 2, 2006, at 10:42 AM, Laurent Pinchart wrote:
> The new fs_enet driver internally maps CPM_MAP_ADDR. Should every
> driver
> create an internal CPM mapping ?
Yes, they should. All drivers should do the ioremap() and stash the
pointer internally.
> .... Why was the old fec_enet driver able to
> access the CPM through CPM_MAP_ADDR without ioremap()ing it first ?
Because that's a long left over "performance hack" from many
years ago when I first implemented the 8xx software. The IMMR used
to be mapped to a well known virtual address, the board initialization
did this early, and everyone (ab)used it. This was way back in the
2.0/2.1
days when it was acceptable to do such things :-) Due to the CPM2 now
being used on may different Freescale parts, and mapped in various
ways, the internal mapping should be done by every driver.
Thanks.
-- Dan
^ 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