* [PATCH] restore clock speed in /proc/cpuinfo
From: Olaf Hering @ 2006-02-04 10:05 UTC (permalink / raw)
To: Paul Mackeras, linuxppc-dev
Use generic_calibrate_decr to restore missing clock: speed in /proc/cpuinfo
Signed-off-by: Olaf Hering <olh@suse.de>
arch/powerpc/platforms/chrp/chrp.h | 1 -
arch/powerpc/platforms/chrp/setup.c | 2 +-
arch/powerpc/platforms/chrp/time.c | 21 ---------------------
3 files changed, 1 insertion(+), 23 deletions(-)
Index: linux-2.6.16-rc2-olh/arch/powerpc/platforms/chrp/setup.c
===================================================================
--- linux-2.6.16-rc2-olh.orig/arch/powerpc/platforms/chrp/setup.c
+++ linux-2.6.16-rc2-olh/arch/powerpc/platforms/chrp/setup.c
@@ -506,7 +506,7 @@ void __init chrp_init(void)
ppc_md.halt = rtas_halt;
ppc_md.time_init = chrp_time_init;
- ppc_md.calibrate_decr = chrp_calibrate_decr;
+ ppc_md.calibrate_decr = generic_calibrate_decr;
/* this may get overridden with rtas routines later... */
ppc_md.set_rtc_time = chrp_set_rtc_time;
Index: linux-2.6.16-rc2-olh/arch/powerpc/platforms/chrp/time.c
===================================================================
--- linux-2.6.16-rc2-olh.orig/arch/powerpc/platforms/chrp/time.c
+++ linux-2.6.16-rc2-olh/arch/powerpc/platforms/chrp/time.c
@@ -167,24 +167,3 @@ void chrp_get_rtc_time(struct rtc_time *
tm->tm_mon = mon;
tm->tm_year = year;
}
-
-
-void __init chrp_calibrate_decr(void)
-{
- struct device_node *cpu;
- unsigned int freq, *fp;
-
- /*
- * The cpu node should have a timebase-frequency property
- * to tell us the rate at which the decrementer counts.
- */
- freq = 16666000; /* hardcoded default */
- cpu = find_type_devices("cpu");
- if (cpu != 0) {
- fp = (unsigned int *)
- get_property(cpu, "timebase-frequency", NULL);
- if (fp != 0)
- freq = *fp;
- }
- ppc_tb_freq = freq;
-}
Index: linux-2.6.16-rc2-olh/arch/powerpc/platforms/chrp/chrp.h
===================================================================
--- linux-2.6.16-rc2-olh.orig/arch/powerpc/platforms/chrp/chrp.h
+++ linux-2.6.16-rc2-olh/arch/powerpc/platforms/chrp/chrp.h
@@ -5,7 +5,6 @@
extern void chrp_nvram_init(void);
extern void chrp_get_rtc_time(struct rtc_time *);
extern int chrp_set_rtc_time(struct rtc_time *);
-extern void chrp_calibrate_decr(void);
extern long chrp_time_init(void);
extern void chrp_find_bridges(void);
--
short story of a lazy sysadmin:
alias appserv=wotan
^ permalink raw reply
* [PATCH] remove pointer/integer confusion in generic_calibrate_decr
From: Olaf Hering @ 2006-02-04 9:34 UTC (permalink / raw)
To: Paul Mackeras, linuxppc-dev
remove pointer/integer confusion
Signed-off-by: Olaf Hering <olh@suse.de>
arch/powerpc/kernel/time.c | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)
Index: linux-2.6.16-rc2-olh/arch/powerpc/kernel/time.c
===================================================================
--- linux-2.6.16-rc2-olh.orig/arch/powerpc/kernel/time.c
+++ linux-2.6.16-rc2-olh/arch/powerpc/kernel/time.c
@@ -612,10 +612,10 @@ void __init generic_calibrate_decr(void)
ppc_tb_freq = DEFAULT_TB_FREQ; /* hardcoded default */
node_found = 0;
- if (cpu != 0) {
+ if (cpu) {
fp = (unsigned int *)get_property(cpu, "timebase-frequency",
NULL);
- if (fp != 0) {
+ if (fp) {
node_found = 1;
ppc_tb_freq = *fp;
}
@@ -626,10 +626,10 @@ void __init generic_calibrate_decr(void)
ppc_proc_freq = DEFAULT_PROC_FREQ;
node_found = 0;
- if (cpu != 0) {
+ if (cpu) {
fp = (unsigned int *)get_property(cpu, "clock-frequency",
NULL);
- if (fp != 0) {
+ if (fp) {
node_found = 1;
ppc_proc_freq = *fp;
}
--
short story of a lazy sysadmin:
alias appserv=wotan
^ permalink raw reply
* RE: Gdb with MPC85xx
From: atul.sabharwal @ 2006-02-03 21:28 UTC (permalink / raw)
To: dan, jcampos; +Cc: linuxppc-embedded
Thanks Dan. It helps clarify some debug problems. I was having similar
problem with BDI2000 to program the AM29F flash part on a 885 reference
board. Finally gave up. It's probably not supported or the config file
was
wrong. My actual board uses different flash, so BDI & the board work
well.
There is a bug in ddd (at least debugging u-boot) when code relocates
from flash to RAM (in_ram routine). The command add-symbol-file u-boot
<text address> to reload symbols did not work due to some ddd bug (it
could not find bounds of current function). Switched to manual decode
using BDI
peek/poke and objdump.
--
Atul
^ permalink raw reply
* Re: Gdb with MPC85xx
From: Dan Malek @ 2006-02-03 21:05 UTC (permalink / raw)
To: atul.sabharwal; +Cc: linuxppc-embedded
In-Reply-To: <4A062D477D842B4C8FC48EA5AF2D41F201AC366C@us-bv-m23.global.tektronix.net>
On Feb 3, 2006, at 3:46 PM, <atul.sabharwal@exgate.tek.com> wrote:
> To the best of my knowledge, I had could single step but not run to a
> breakpoint in the initial u-boot code on PPC8540( an E500 core based)
This is a problem with many processors and has been discussed
at length too often. The quick response is that various initialization
code in both boot roms and Linux will disable/reset or otherwise
mess up debug registers the BDI has configured for it's use. So,
it isn't the fault of the BDI2000, you may have to temporarily disable
or modify the code under test in such a way to not do this. There are
several tricky places to debug code, that are completely inaccessible
without the use of the BDI2000, but that also require some common
sense and minor environment changes to properly debug. The e500
core (and Book-E in general) significantly complicated the ability
to debug in some modes of development, so you are most
likely to see problems with these processors than others.
Thanks.
-- Dan
^ permalink raw reply
* RE: Gdb with MPC85xx
From: atul.sabharwal @ 2006-02-03 20:46 UTC (permalink / raw)
To: fabidi, linuxppc-embedded
To the best of my knowledge, I had could single step but not run to a
breakpoint in the initial u-boot code on PPC8540( an E500 core based)
system
Esp. in the code in start.S. I had a problem where the flash was busted
and
The start.S was running from a DDR2 memory at 600+MHz rate. So, I had
to lock the TLB and define LAW for the DDR memory in BDI so that we
could run entire u-boot, kernel, ramdisk from RAM. =20
It seemed like a BDI bug to me unless the processor is designed to
always boot from a slow deviceflash or eeprom) till the initialization
sequence is=20
Completed. Did not try extensive debug with it, so not sure. If it
helps.
--
Atul
-----Original Message-----
From: linuxppc-embedded-bounces@ozlabs.org
[mailto:linuxppc-embedded-bounces@ozlabs.org] On Behalf Of Fahd Abidi
Sent: Friday, February 03, 2006 10:41 AM
To: linuxppc-embedded@ozlabs.org
Subject: Gdb with MPC85xx
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
_______________________________________________
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* 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
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