* Re: MPC8555 USB host support
From: Yuli Barcohen @ 2005-11-17 12:34 UTC (permalink / raw)
To: Vitaly Bordug; +Cc: Jonathan Masel, 'linuxppc-embedded@ozlabs.org'
In-Reply-To: <437B56E7.5090109@ru.mvista.com>
>>>>> Vitaly Bordug writes:
...
Vitaly> I also have a bunch of patches for gregkh, supporting serial
Vitaly> function, but they need nontrivial cleanup I do not have
Vitaly> time currently for. So I think I grab this one together with
Vitaly> my stuff when I head for it.
Kumar> Also, are you aware of Freescale's driver for this?
Vitaly> I used to try arabella one (came with MW bsp) but that
Vitaly> version does not work with 8272.
If so, it's a very old version. The driver works with any MPC82xx (and
MPC885, BTW). Also, please remember that many Freescale ADS boards have
hardware problems (depending on the board's revision).
Vitaly> If there are something usable, it will be interesting to
Vitaly> look at.
...
--
========================================================================
Yuli Barcohen | Phone +972-9-765-1788 | Software Project Leader
yuli@arabellasw.com | Fax +972-9-765-7494 | Arabella Software, Israel
========================================================================
^ permalink raw reply
* Re: [REQUEST] Tap for right click on PowerBook trackpad
From: Felix Oxley @ 2005-11-17 12:34 UTC (permalink / raw)
To: Dustin Lang; +Cc: linuxppc-dev
In-Reply-To: <Pine.LNX.4.60.0511161918050.29361@tin.icics.ubc.ca>
On Thursday 17 November 2005 03:32, Dustin Lang wrote:
>
> On my PowerBook, I map F11 to the middle mouse button and F12 to the right
> mouse button. I've grown so used to it that I get annoyed when it doesn't
> work in OSX :)
>
Thanks for your repsonse.
Actually, ububtu which I was experimenting with had this feature enabled by default.
However I find it extremely cumbersome to have to remove my hand form the trackpad in order to press F12.
I believe the Linux trackpad driver can do other specail action such as 'click and drag' or something similar.
Therefore I was/am hoping that implementing tap for right click would be possible.
(please cc me as I am not subscribed)
cheers,
Felix
^ permalink raw reply
* help
From: prabha.j @ 2005-11-17 6:02 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 2059 bytes --]
Hi all,
I am trying to build kernel image for my custom borad which is similar to
mpc8260ads board. But i am getting the error.
I am using denx enldk and also the kernel source.
The error is
make[1]: Entering directory
`/home/cdot/eldk/ppc_6xx/usr/src/linux-2.4.25/arch/ppc/lib'
make all_targets
make[2]: Entering directory
`/home/cdot/eldk/ppc_6xx/usr/src/linux-2.4.25/arch/ppc/lib'
make[2]: Nothing to be done for `all_targets'.
make[2]: Leaving directory
`/home/cdot/eldk/ppc_6xx/usr/src/linux-2.4.25/arch/ppc/lib'
make[1]: Leaving directory
`/home/cdot/eldk/ppc_6xx/usr/src/linux-2.4.25/arch/ppc/lib'
ppc_6xx-ld -T arch/ppc/vmlinux.lds -Ttext 0xc0000000 -Bstatic
arch/ppc/kernel/head.o arch/ppc/kernel/idle_6xx.o init/main.o
init/version.o init/do_mounts.o \
--start-group \
arch/ppc/kernel/kernel.o arch/ppc/platforms/platform.o
arch/ppc/mm/mm.o arch/ppc/lib/lib.o kernel/kernel.o mm/mm.o fs/fs.o
ipc/ipc.o \
drivers/char/char.o drivers/block/block.o drivers/misc/misc.o
drivers/net/net.o drivers/pci/driver.o drivers/mtd/mtdlink.o
drivers/macintosh/macintosh.o drivers/media/media.o \
net/network.o \
/home/cdot/eldk/ppc_6xx/usr/src/linux-2.4.25/lib/lib.a \
--end-group \
-o vmlinux
arch/ppc/kernel/kernel.o(__ksymtab+0x480): In function `sys_call_table':
arch/ppc/kernel/entry.S: undefined reference to `__res'
make: *** [vmlinux] Error 1
Thanks in advance
Prabha J.
Tata Consultancy Services Limited
Mailto: prabha.j@tcs.com
Website: http://www.tcs.com
Notice: The information contained in this e-mail message and/or attachments to it may contain confidential or privileged information. If you are not the intended recipient, any dissemination, use, review, distribution, printing or copying of the information contained in this e-mail message and/or attachments to it are strictly prohibited. If you have received this communication in error, please notify us by reply e-mail or telephone and immediately and permanently delete the message and any attachments. Thank you
[-- Attachment #2: Type: text/html, Size: 3272 bytes --]
^ permalink raw reply
* Re: Help ! 2.6.14 kernel can't bring up
From: Clemens Koller @ 2005-11-17 11:02 UTC (permalink / raw)
To: zjznliang; +Cc: linuxppc-embedded
In-Reply-To: <20051117075009.B2C4E6872B@ozlabs.org>
Hello, zjznliang!
zjznliang wrote:
> And there is nothing output ,I thought that it was serial port fault.
> I checked my Linux configuration ,but found nothing .
Check your kernel configuration.
Have you tried to turn on "early printk" support in your kernel config?
Linux might be booting already, but you just don't see it on your console.
Good luck,
--
Clemens Koller
_______________________________
R&D Imaging Devices
Anagramm GmbH
Rupert-Mayer-Str. 45/1
81379 Muenchen
Germany
http://www.anagramm.de
Phone: +49-89-741518-50
Fax: +49-89-741518-19
^ permalink raw reply
* Re: "Now booting the kernel"
From: David H. Lynch Jr. @ 2005-11-17 9:31 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <437308E6.2070804@ecrin.com>
I am having similar difficulties on a Xilinx Virtex 4.
I have some advantages over Nitesh in that I have a 32bit port at
0x70000000 that I can write values to and see what they are (at least
until the MMU is enabled)
and with some additional complexity use as a sort of UART to write text.
Thus far this is what I get:
Starting MonitorX.elf: V3.3.2.0.
Loading zImage.elf.
loaded at: 00400000 0048C138
board data at: 0048A124 0048A138
relocated to: 004050AC 004050C0
zimage at: 00405865 00489E79
avail ram: 0048D000 08000000
Linux/PPC load: console=ttyS0,9600 console=tty0 root=/dev/sda2
Uncompressing Linux...done.
Now booting the kernel
After that I am in arch/ppc/kernel/head_4xx.S and only get output from
my debug port.
I have used that to determine as follows:
B1B1B1B1 - @head_4xx.S
00058001 - @initial_mmu
C0000000 - output Virtual
Address of KERNELBASE
00000000 - output physical
address of KERNELBASE
00057003 - @setup tlb
entry for debug console
70000000 - physical
address of memory to create tlb for debug console (same as debug port)
00057002 - @turn_on_mmu
00021032 - MSR Machine
status register
C00022A0 - virtual address
of start_here
40000000 - physical
address of start_here ??? shouldn't this be 000022A0 ?
I can trace right up to the rfi that kicks the processor into virtual mode.
The very first thing I have done at start_here is write a unique value
to my debug - I never see that.
That should mean either:
I do not have the correct tlb entry to enable my debug port to
work once the MMU is enabled
or
I am not getting to start_here.
Interestingly I also output identifiers for exceptions - and I am
getting repeated DTLB miss exceptions - all for address FFB13458
I also did memory dumps of what I thought were interesting regions at
the end of load_kernel
The dump of 0x0 looks very much like the start of head_4xx.S - the
signature values I am writing to my debug port (as well as the address
of the debug port itself) all in close proximity
are tty good clues.
the dump of 0x400000 looks like the start of arch/ppc/boot/simple/head.S
which is what I would expect.
the dump of 0x22a0 looks like start_here.
The only thing I see that seems to be wrong is that if I use tophys() to
try to convert start_here to a physical address I don't think I should
get 0x40000000
For reference a snippet of my debug output code is below.
lis r14,0x7000 //
high address of debug port
lis r0,0x5
ori r0,r0,0x7002
stw r0,4(r14)
eieio
// output 0x57002
lis r0,start_here@h //
output start_here (virtual)
ori r0,r0,start_here@l
stw r0,4(r14)
eieio
tophys (r0,r0);
// output start_here physical
stw r0,4(r14)
eieio
Help !?
^ permalink raw reply
* Re: [PATCH] m8xx_wdt: software watchdog reset/interrupt select
From: Florian Schirmer @ 2005-11-17 9:13 UTC (permalink / raw)
To: Marcelo Tosatti; +Cc: obi, carjay, linux-ppc-embedded
In-Reply-To: <20051116083609.GC4441@logos.cnet>
Hi,
okay here is what the current driver does:
During startup it installs a timer irq (PIT) handler and sets the
frequency to half of the watchdog timeout. As soon as this timer irq
triggers we reset the watchdog inside the irq handler.
If a userspace handler takes over the watchdog we deinstall the timer
irq handler and let the userspace daemon handle the watchdog resets.
Please not that we're talking about the timer irq, not the watchdog
interrupt.
I don't see why it should make a difference wether the watchdog
generates a IRQ0/HRESET or a system reset directly since it should never
trigger anyway.
All the patch does is to use a kernel timer instead of the hardware
timer. So i'm little confused.
And yes you should be right about the watchdog irq. It doesn't make
sense to install a watchdog irq handler. It doesn't make any sense to
put the watchdog into irq mode. As far as i know nobody ever tried to
use that mode.
If you're bound to irq mode because the bootloader activates it the
whole code should still work out of the box as long as the irq causes a
system reset. But maybe i'm missing something obvious or the docs are
incorrect/incomplete?
Best,
Florian
> Anyway, the SWRI bit selects interrupt (0) or reset mode (1) for the watchdog.
>
> On reset mode no interrupt is sent to the kernel - the watchdog logic resets
> the system with HRESET.
>
> So, the timer in m8xx_wdt is _required_ for reset mode.
>
> Does that make sense?
>
>> Otherwise i'm fine with the patch. Feel free to add my Signed-off-by line.
>
> Ok, lets sort this out first.
>
> I wonder how interrupt mode is supposed to work, because the manual states
> that in interrupt mode (SWRI == 0) an NMI (IRQ0) is triggered, which jumps
> to 0x100 exception vector (SW reset).
>
> Maybe I'm misunderstanding the interrupt mode?
>
> Folks who wrote the patch claim it works on their 8xx's (as can be found
> on mailing list archives).
^ permalink raw reply
* Booting hangs after "Calibrating delay loop..."
From: Nguyen Thanh Binh @ 2005-11-17 8:19 UTC (permalink / raw)
To: linuxppc-embedded
Hi all,
When booting Monta Vista Linux on Memec board
(Virtex-4 FX12 LC), it hung after printing the
following message:
"Calibrating delay loop..."
By looking at the source code, I found that in the
init/main.c the problem came from the
calibrate_delay()
function: jiffies was not incremented (jiffies was
always equal to 0).
Have anyone get the similar problem or any experience
to fix it?
Thank you.
Binh Nguyen
Nguyễn Thanh Bình
___________________________________________________________
How much free photo storage do you get? Store your holiday
snaps for FREE with Yahoo! Photos http://uk.photos.yahoo.com
^ permalink raw reply
* Help ! 2.6.14 kernel can't bring up
From: zjznliang @ 2005-11-17 7:50 UTC (permalink / raw)
To: linuxppc-embedded
SGkgbGludXhwcGMtZW1iZWRkZWSjoQ0KDQoJICAgICAgICAgSSAgaGF2ZSBkb3dubG9hZGVkIHRo
ZSBMaW51eCAyLjYuMTQgZnJvbSB3d3cuZGVueC5kZS5JIGFkZGVkIGFuZCBtb2RpZmllZCB0aGUg
ZmlsZSBhbmQgY29tcGlsZSBpdCBhcyB3aGF0IEkgZGlkIG9uIExpbnV4IDIuNC4yNSB3aGljaCB3
YXMgYWxzbyBkb3dubG9hZGVkIG9uIHd3dy5kZW54LmRlLiBNeSBib2FyZCBpcyBiYXNlIG9uIE1Q
QyA4NTcgLGFuZCBpdCBnb2VzIHdlbGwgaW4gTGludXggMi40LjI1IC4gTXkgYm9vdGxvYWRlciBp
cyBVLUJvb3QgMS4xLjMgd2hpY2ggZ29lcyB3ZWxsIHRvby4gQnV0IHdoZW4gSSBicmluZyB1cCB0
aGUgTGludXggMi42LjE0ICxJIG9ubHkgZ290IHRoZSBpbmZvcm1hdGlvbiBhcyBmb2xsb3cgOg0K
DQojIyBCb290aW5nIGltYWdlIGF0IGZmYzQwMDAwIC4uLg0KICAgSW1hZ2UgTmFtZTogICBMaW51
eC0yLjYuMTQNCiAgIENyZWF0ZWQ6ICAgICAgMjAwNS0xMS0xNyAgIDc6MTE6NDIgVVRDDQogICBJ
bWFnZSBUeXBlOiAgIFBvd2VyUEMgTGludXggS2VybmVsIEltYWdlIChnemlwIGNvbXByZXNzZWQp
DQogICBEYXRhIFNpemU6ICAgIDY3ODE3MCBCeXRlcyA9IDY2Mi4zIGtCDQogICBMb2FkIEFkZHJl
c3M6IDAwMDAwMDAwDQogICBFbnRyeSBQb2ludDogIDAwMDAwMDAwDQogICBWZXJpZnlpbmcgQ2hl
Y2tzdW0gLi4uIE9LDQogICBVbmNvbXByZXNzaW5nIEtlcm5lbCBJbWFnZSAuLi4gT0sNCiMjIExv
YWRpbmcgUkFNRGlzayBJbWFnZSBhdCBmZmQwMDAwMCAuLi4NCiAgIEltYWdlIE5hbWU6DQogICBD
cmVhdGVkOiAgICAgIDIwMDUtMTEtMDkgICA5OjI4OjI3IFVUQw0KICAgSW1hZ2UgVHlwZTogICBQ
b3dlclBDIExpbnV4IFJBTURpc2sgSW1hZ2UgKGd6aXAgY29tcHJlc3NlZCkNCiAgIERhdGEgU2l6
ZTogICAgMTU2NDM2OSBCeXRlcyA9ICAxLjUgTUINCiAgIExvYWQgQWRkcmVzczogMDBjMDAwMDAN
CiAgIEVudHJ5IFBvaW50OiAgMDBjMDAwMDANCiAgIFZlcmlmeWluZyBDaGVja3N1bSAuLi4gT0sN
CiAgIExvYWRpbmcgUmFtZGlzayB0byAwMGUzZTAwMCwgZW5kIDAwZmJiZWQxIC4uLiBPSw0KDQpB
bmQgdGhlcmUgaXMgbm90aGluZyBvdXRwdXQgLEkgdGhvdWdodCB0aGF0IGl0IHdhcyBzZXJpYWwg
cG9ydCBmYXVsdCAuIEkgY2hlY2tlZCBteSBMaW51eCBjb25maWd1cmF0aW9uICxidXQgZm91bmQg
bm90aGluZyAuDQoNCkhvdyB0byBtYWtlIHRoZSBsaW51eCAyLjYuMTQgd2VsbCBvbiBteSBib2Fy
ZCA/Pw0KDQogDQogICBBbnkgaGVscCBvbiB0aGlzIHdvdWxkIGJlIGdyZWF0bHkgYXBwcmVjaWF0
ZWQuIFRoYW5rcyBmb3IgeW91ciBwYXRpZW5jZS4gDQoNCiAJCQkJDQoNCqGhoaF6anpubGlhbmcN
CqGhoaGhoaGhemp6bmxpYW5nX3BvcG9AMTYzLmNvbQ0KoaGhoaGhoaGhoaGhMjAwNS0xMS0xNw0K
^ permalink raw reply
* Re: [REQUEST] Tap for right click on PowerBook trackpad
From: Dustin Lang @ 2005-11-17 3:32 UTC (permalink / raw)
To: Felix Oxley; +Cc: linuxppc-dev
In-Reply-To: <200511170213.16926.lkml@oxley.org>
Hi,
On my PowerBook, I map F11 to the middle mouse button and F12 to the right
mouse button. I've grown so used to it that I get annoyed when it doesn't
work in OSX :)
You can do the same by:
-be sure to enable CONFIG_MAC_EMUMOUSEBTN in the kernel config
-at startup time (or whenever):
echo "1" > /proc/sys/dev/mac_hid/mouse_button_emulation
echo "87" > /proc/sys/dev/mac_hid/mouse_button2_keycode
echo "88" > /proc/sys/dev/mac_hid/mouse_button3_keycode
Cheers,
dstn.
> One big reason that I don't use Linux on my PowerBook (1.25 AlBook) is
> the difficulty of using the single button trackpad. Under OS X I use
> SideTrack which provides the ability to tap for right-click. I did some
> investigation a few months ago and could not find a Linux replacement
> for SideTrack.
>
> Would this be a difficult feature to implement?
> Would any one be interested in doing it? :-)
>
> (Please CC me as I am not subscribed)
> regards,
> Felix
^ permalink raw reply
* U-Boot MPC859TnnA support !
From: zjznliang @ 2005-11-17 3:37 UTC (permalink / raw)
To: linuxppc-embedded
SGkgbGludXhwcGMtZW1iZWRkZWSjoQ0KDQoJICAgICAgICAgIEkgYW0gcG9ydGluZyBVLUJvb3Qg
b24gdGhlIE1QQzg1OVRubkEgY2FyZCxidXQgVS1Cb290IGNhbid0IGZpbmQgdGhlIENQVSBpbiB0
aGUgaW5pdGlhbGl6YXRpb24gLiBJIGNoZWNrIHRoZSBjb2RlICx0aGVyZSBpcyBub3QgdHlwZSBv
ZiBNUEM4NTlUbm5BIHRvIHN1cHBvcnQgLlRoZSBVLUJvb3QgdmVyc2lvbiBpcyAxLjEuMy4NCg0K
CQkJCVRoZXJlIE1QQyBmYW1pbHkgdmVyc2lvbnMgaXMgaGVyZSA6DQoJCQkJaHR0cDovL3d3dy5m
cmVlc2NhbGUuY29tL3dlYmFwcC9zcHMvc2l0ZS9wcm9kX3N1bW1hcnkuanNwP2NvZGU9TVBDODU5
VCZzcmNoPTEgDQoNCgkJCQlNUEM4NjYgRmFtaWx5IFZlcnNpb25zIGFuZCBNYXNrcyANCgkJCQlS
ZXYgCU1hc2sgCVByb2Nlc3MgCVF1YWwgCUlNTVJbMTY6MzFdIAlNaWNyb2NvZGUgUkVWX05VTSAJ
UGFydCBOdW1iZXIgDQoJCQkJMC4zIAkzTDkwSCAJSGlQNlcgCQlNQyAJCTB4MDgwMCAJCQkJMHgw
MDAzIAkJCQkJCQkJICBNUEM4NjZQbm4NCgkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJ
CQkgIAlNUEM4NjZUbm4NCgkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJTVBDODU5
VG5uDQoJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCU1QQzg1OURTTG5uDQoJCQkJ
CQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCU1QQzg1MlRubiANCgkJCQlBLjAgCTBMOTZS
IAlIaVA2VyAJCU1DIAkJMHgwODAxIAkJCQkweDAwMDQgCQkJCQkJCQlNUEM4NjZQbm5BDQoJCQkJ
CQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCU1QQzg2NlRubkENCgkJCQkJCQkJCQkJCQkJ
CQkJCQkJCQkJCQkJCQkJCQkJCQkJTVBDODU5VG5uQQ0KCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJ
CQkJCQkJCQkJCQlNUEM4NTlEU0xubkEgDQoNCgkJCQlUaGUgY29kZSBpbiBVLUJvb3QgaXMgaW4g
dGhlIGNoZWNrX0NQVSgpICAobGluZSA0OCBvZiAiXGNwdVxtcGM4eHhcQ3B1LmMiKQ0KCQkJCVRo
ZSBVLUJvb3Qgc3VwcG9ydHMgdGhlIHR5cGUgb2YgMHgwODAwMDAwMyBidXQgbm90IDB4MDgwMTAw
MDQsIHNvIGFkZCB0aGUgY29kZSBmb3IgMHgwODAxMDAwNCx5b3Ugd2lsbCBmaW5kIHlvdXIgTVBD
eG5uQSBjcHUgLjopDQogCQkJCQ0KICAgICAgICAgICAgIAlQZXJoYXBzIEkgd2lsbCBiZSBhIGhl
bHAuDQqhoaGhemp6bmxpYW5nDQqhoaGhoaGhoXpqem5saWFuZ19wb3BvQDE2My5jb20NCqGhoaGh
oaGhoaGhoTIwMDUtMTEtMTcNCg==
^ permalink raw reply
* [REQUEST] Tap for right click on PowerBook trackpad
From: Felix Oxley @ 2005-11-17 2:13 UTC (permalink / raw)
To: lkml; +Cc: linuxppc-dev
One big reason that I don't use Linux on my PowerBook (1.25 AlBook) is the difficulty of using the single button trackpad.
Under OS X I use SideTrack which provides the ability to tap for right-click.
I did some investigation a few months ago and could not find a Linux replacement for SideTrack.
Would this be a difficult feature to implement?
Would any one be interested in doing it? :-)
(Please CC me as I am not subscribed)
regards,
Felix
^ permalink raw reply
* Re: 2.6.14 USB vs. sleep issues
From: Eddy Petrisor @ 2005-11-16 23:21 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev list, debian-powerpc@lists.debian.org
In-Reply-To: <1132174868.5646.112.camel@gaston>
Benjamin Herrenschmidt wrote:
> On Wed, 2005-11-16 at 19:09 +0100, Wolfgang Pfeiffer wrote:
>
>>>For those who experience crashes on sleep and/or wakeup (typically due
>>>to USB) with 2.6.14, I made a test patch that might help. [ ... ]
> Only newer machines with a NEC USB2 chip that shares interrupts appear
> to be affected by the problem.
So is there any chance that the sleep issue is fixed until 2.6.15?
--
Regards,
EddyP
=============================================
"Imagination is more important than knowledge" A.Einstein
^ permalink raw reply
* Re: [PATCH] powerpc: Merge align.c (#2)
From: Paul Mackerras @ 2005-11-16 22:14 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev list, linuxppc64-dev
In-Reply-To: <1132025664.6094.47.camel@gaston>
Benjamin Herrenschmidt writes:
> Since it's likely that I won't be able to test all scenario, code
> inspection is much welcome.
I think you need this patch on top...
Paul.
diff -urN powerpc/arch/powerpc/kernel/align.c merge-hack/arch/powerpc/kernel/align.c
--- powerpc/arch/powerpc/kernel/align.c 2005-11-17 09:05:04.000000000 +1100
+++ merge-hack/arch/powerpc/kernel/align.c 2005-11-17 09:06:29.000000000 +1100
@@ -198,21 +198,20 @@
/* bits 6:15 --> 22:31 */
dsisr = (instr & 0x03ff0000) >> 16;
- if ( IS_XFORM(instr) ) {
+ if (IS_XFORM(instr)) {
/* bits 29:30 --> 15:16 */
dsisr |= (instr & 0x00000006) << 14;
/* bit 25 --> 17 */
dsisr |= (instr & 0x00000040) << 8;
/* bits 21:24 --> 18:21 */
dsisr |= (instr & 0x00000780) << 3;
- }
- else {
+ } else {
/* bit 5 --> 17 */
dsisr |= (instr & 0x04000000) >> 12;
/* bits 1: 4 --> 18:21 */
dsisr |= (instr & 0x78000000) >> 17;
/* bits 30:31 --> 12:13 */
- if ( IS_DSFORM(instr) )
+ if (IS_DSFORM(instr))
dsisr |= (instr & 0x00000003) << 18;
}
@@ -247,13 +246,22 @@
/*
* Emulate load & store multiple instructions
+ * On 64-bit machines, these instructions only affect/use the
+ * bottom 4 bytes of each register, and the loads clear the
+ * top 4 bytes of the affected register.
*/
+#ifdef CONFIG_PPC64
+#define REG_BYTE(rp, i) *((u8 *)((rp) + ((i) >> 2)) + ((i) & 3) + 4)
+#else
+#define REG_BYTE(rp, i) *((u8 *)(rp) + (i))
+#endif
+
static int emulate_multiple(struct pt_regs *regs, unsigned char __user *addr,
unsigned int reg, unsigned int nb,
unsigned int flags, unsigned int instr)
{
- unsigned char *rptr;
- int nb0, i;
+ unsigned long *rptr;
+ unsigned int nb0, i;
/*
* We do not try to emulate 8 bytes multiple as they aren't really
@@ -291,29 +299,38 @@
if (!access_ok((flags & ST ? VERIFY_WRITE: VERIFY_READ), addr, nb+nb0))
return -EFAULT; /* bad address */
- rptr = (unsigned char *) ®s->gpr[reg];
+ rptr = ®s->gpr[reg];
if (flags & LD) {
+ /*
+ * This zeroes the top 4 bytes of the affected registers
+ * in 64-bit mode, and also zeroes out any remaining
+ * bytes of the last register for lsw*.
+ */
+ memset(rptr, 0, ((nb + 3) / 4) * sizeof(unsigned long));
+ if (nb0 > 0)
+ memset(®s->gpr[0], 0,
+ ((nb0 + 3) / 4) * sizeof(unsigned long));
+
for (i = 0; i < nb; ++i)
- if (__get_user(rptr[i], addr + i))
+ if (__get_user(REG_BYTE(rptr, i), addr + i))
return -EFAULT;
if (nb0 > 0) {
- rptr = (unsigned char *) ®s->gpr[0];
+ rptr = ®s->gpr[0];
addr += nb;
for (i = 0; i < nb0; ++i)
- if (__get_user(rptr[i], addr + i))
+ if (__get_user(REG_BYTE(rptr, i), addr + i))
return -EFAULT;
}
- for (; (i & 3) != 0; ++i)
- rptr[i] = 0;
+
} else {
for (i = 0; i < nb; ++i)
- if (__put_user(rptr[i], addr + i))
+ if (__put_user(REG_BYTE(rptr, i), addr + i))
return -EFAULT;
if (nb0 > 0) {
- rptr = (unsigned char *) ®s->gpr[0];
+ rptr = ®s->gpr[0];
addr += nb;
for (i = 0; i < nb0; ++i)
- if (__put_user(rptr[i], addr + i))
+ if (__put_user(REG_BYTE(rptr, i), addr + i))
return -EFAULT;
}
}
@@ -338,7 +355,7 @@
unsigned char __user *p;
int ret, t;
union {
- long ll;
+ u64 ll;
double dd;
unsigned char v[8];
struct {
^ permalink raw reply
* Re: 2.6.14 USB vs. sleep issues
From: Benjamin Herrenschmidt @ 2005-11-16 21:01 UTC (permalink / raw)
To: Wolfgang Pfeiffer; +Cc: linuxppc-dev list, debian-powerpc@lists.debian.org
In-Reply-To: <20051116180925.GB3080@localhost>
On Wed, 2005-11-16 at 19:09 +0100, Wolfgang Pfeiffer wrote:
> On Thu, Nov 03, 2005 at 05:33:39PM +1100, Benjamin Herrenschmidt wrote:
> > For those who experience crashes on sleep and/or wakeup (typically due
> > to USB) with 2.6.14, I made a test patch that might help. [ ... ]
>
> Ben, I just compiled and installed a 2.6.14.1 from kernel.org with
> none of your patches from this thread applied to it, and I have no
> sleep/wakeup probs with it so far: about 3 instances of sleep/wakeup
> until now, all of them successful.
>
> Maybe I even made it a bit more complicated for the system, as I
> connected a USB HUB, with 4 ports, to the machine: It just seems to
> work ...
Only newer machines with a NEC USB2 chip that shares interrupts appear
to be affected by the problem.
Ben.
^ permalink raw reply
* Re: [PATCH] powerpc: Merge align.c
From: Dan Malek @ 2005-11-16 20:36 UTC (permalink / raw)
To: Gabriel Paubert; +Cc: linuxppc64-dev, linuxppc-dev list
In-Reply-To: <20051116194553.GA23679@iram.es>
On Nov 16, 2005, at 2:45 PM, Gabriel Paubert wrote:
> I originally asked because I believed that these cores are
> actually closer to the 603e than to the original 603.
That's correct. In fact, I think the original 8260 and
perhaps the 5200 were 603e cores. As I mentioned,
the newer ones are subtly different, but better than
the 603e ;-)
Thanks.
-- Dan
^ permalink raw reply
* Re: [PATCH] powerpc: Merge align.c
From: Gabriel Paubert @ 2005-11-16 19:45 UTC (permalink / raw)
To: Dan Malek; +Cc: linuxppc64-dev, linuxppc-dev list
In-Reply-To: <755b1bfb034aebb5de36dc0594e08ec6@embeddededge.com>
On Wed, Nov 16, 2005 at 02:20:43PM -0500, Dan Malek wrote:
>
> On Nov 16, 2005, at 10:15 AM, Kumar Gala wrote:
>
> >603 is used in all 82xx/83xx processors from Freescale. The 8641 is
> >the same core as 7448.
>
> The 82xx uses G2_LE, and 83xx is e300, which are
> similar to the old 603 but do have some subtle
> improvements that make them better cores.
I originally asked because I believed that these cores are
actually closer to the 603e than to the original 603.
But take this with a pinch of salt, I might be wrong.
Gabriel
^ permalink raw reply
* Re: [PATCH] powerpc: Merge align.c
From: Dan Malek @ 2005-11-16 19:24 UTC (permalink / raw)
To: Becky Bruce; +Cc: linuxppc-dev list, linuxppc64-dev
In-Reply-To: <28076a8ba1e55469c74b0677a289fd0b@freescale.com>
On Nov 16, 2005, at 11:31 AM, Becky Bruce wrote:
> As far as I can tell, the only one that cares about segment boundaries
> is 603
Why would 603 care about segment boundaries? I couldn't
find any documentation old enough that indicated such a thing :-)
Thanks.
-- Dan
^ permalink raw reply
* Re: [PATCH] powerpc: Merge align.c
From: Dan Malek @ 2005-11-16 19:20 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc64-dev, linuxppc-dev list
In-Reply-To: <43D0A21D-89BC-4EFE-BA2A-94760BA32276@kernel.crashing.org>
On Nov 16, 2005, at 10:15 AM, Kumar Gala wrote:
> 603 is used in all 82xx/83xx processors from Freescale. The 8641 is
> the same core as 7448.
The 82xx uses G2_LE, and 83xx is e300, which are
similar to the old 603 but do have some subtle
improvements that make them better cores.
-- Dan
^ permalink raw reply
* Re: 2.6.14 USB vs. sleep issues
From: Wolfgang Pfeiffer @ 2005-11-16 18:25 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev list, debian-powerpc@lists.debian.org
In-Reply-To: <20051116180925.GB3080@localhost>
On Wed, Nov 16, 2005 at 07:09:26PM +0100, Wolfgang Pfeiffer wrote:
> Ben, I just compiled and installed a 2.6.14.1 from kernel.org with
> none of your patches from this thread applied to it, and I have no
> sleep/wakeup probs with it so far: about 3 instances of sleep/wakeup
> until now, all of them successful.
>
> Maybe I even made it a bit more complicated for the system, as I
> connected a USB HUB, with 4 ports, to the machine: It just seems to
> work ... [ ... ]
Just for the sake of completeness: I have (SCSI) problems with 2.6.14.1,
but none of them seem to be USB/sleep related:
<http://sourceforge.net/mailarchive/forum.php?thread_id=8964383&forum_id=5389>
Not being sure whether this latter URL works: I just read "The
SourceForge.net Website is currently down for maintenance" But the
name of the thread up there is:
"Fw: 2.6.14.1: Loading FireWire disk fails. Fix: "modprobe ieee1394
disable_irm=1""
Best Regards
Wolfgang
--
Wolfgang Pfeiffer
http://profiles.yahoo.com/wolfgangpfeiffer
Key ID: E3037113
Key fingerprint = A8CA 9D8C 54C4 4CC1 0B26 AA3C 9108 FB42 E303 7113
^ permalink raw reply
* Re: 2.6.14 USB vs. sleep issues
From: Wolfgang Pfeiffer @ 2005-11-16 18:09 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev list, debian-powerpc@lists.debian.org
In-Reply-To: <1130999620.4680.28.camel@gaston>
On Thu, Nov 03, 2005 at 05:33:39PM +1100, Benjamin Herrenschmidt wrote:
> For those who experience crashes on sleep and/or wakeup (typically due
> to USB) with 2.6.14, I made a test patch that might help. [ ... ]
Ben, I just compiled and installed a 2.6.14.1 from kernel.org with
none of your patches from this thread applied to it, and I have no
sleep/wakeup probs with it so far: about 3 instances of sleep/wakeup
until now, all of them successful.
Maybe I even made it a bit more complicated for the system, as I
connected a USB HUB, with 4 ports, to the machine: It just seems to
work ...
-------------------------------------
$ cat /proc/cpuinfo
processor : 0
cpu : 7455, altivec supported
clock : 867MHz
revision : 0.2 (pvr 8001 0302)
bogomips : 865.18
machine : PowerBook3,5
motherboard : PowerBook3,5 MacRISC2 MacRISC Power Macintosh
detected as : 80 (PowerBook Titanium IV)
pmac flags : 0000001b
L2 cache : 256K unified
memory : 768MB
pmac-generation : NewWorld
-----------------------------------
HTH
Best Regards
Wolfgang
--
Wolfgang Pfeiffer
http://profiles.yahoo.com/wolfgangpfeiffer
Key ID: E3037113
Key fingerprint = A8CA 9D8C 54C4 4CC1 0B26 AA3C 9108 FB42 E303 7113
^ permalink raw reply
* Re: [PATCH] powerpc: Merge align.c
From: Andrey Volkov @ 2005-11-16 16:54 UTC (permalink / raw)
To: Becky Bruce; +Cc: linuxppc-dev list, linuxppc64-dev
In-Reply-To: <4ad202b87fa52d954e645b05fb45ca13@freescale.com>
Becky Bruce wrote:
> On Nov 15, 2005, at 8:34 PM, Benjamin Herrenschmidt wrote:
>
>> >
>> > BTW, Based on the pile of docs I have here, I think the list of
>> > alignment-exception-causing events on FSL's current parts (603, 603e,
>> > 750, 74x, 74xx, e500) is:
>> >
>> > - lmw/stmw (all procs, non-word aligned)
>> > - single and double precision floating point ld/st ops (non-E500, non
>> > data size aligned)
>> > - dcbz to WT or CI memory (all procs)
>> > - dcbz with cache disabled (all procs but 603e?)
>> > - misaligned little endian accesses (603e)
>> > - lwarx/stwcx (all procs)
>> > - multiple/string with LE set (750, 603e, 7450, 7400)
>> > - eciwx/ecowx (750, 7450, 7400)
>> > - a couple of others related to vector processing
>> >
>> > If anybody knows offhand of something missing there, let me know.
>>
>> What about lwz/stw cropssing page boundaries ? Is this handled in HW ?
>>
>> Ben.
>
>
> Apparently so, much to my surprise - I ran the testcase with those
> instructions misaligned across a page boundary last night and got no
> alignment exception. I was surprised, and asked my husband about it (he
> worked on the load/store units for a bunch of our parts), and he says
> these guys never cause an exception for any of FSL's current parts as
> far as he knows. This is supported by our documentation as well - the
> only place I see these listed is on 603e, where they can cause an
> exception if the page is mapped little endian.
>
Try this for 603e (BE):
memcpy(xxxx3, xxxx0, 8);
I get invalid behavior (0 in second dword) on MPC5200 for external flash
access.
--
Regards
Andrey Volkov
^ permalink raw reply
* Re: [PATCH] pmu_register_sleep_notifier needs ADB_PMU
From: Olaf Hering @ 2005-11-16 16:38 UTC (permalink / raw)
To: Benjamin Herrenschmidt, linuxppc-dev
In-Reply-To: <20051022213206.GB6097@suse.de>
On Sat, Oct 22, Olaf Hering wrote:
>
> a simple patch for a pegsos user:
> https://bugzilla.novell.com/show_bug.cgi?id=119606
Still not fully fixed:
drivers/video/aty/radeon_pm.c: In function `radeonfb_pm_init':
drivers/video/aty/radeon_pm.c:2769: warning: implicit declaration of function `pmac_call_feature'
drivers/video/aty/radeon_pm.c:2769: error: `PMAC_FTR_DEVICE_CAN_WAKE' undeclared (first use in this function)
drivers/video/aty/radeon_pm.c:2769: error: (Each undeclared identifier is reported only once
drivers/video/aty/radeon_pm.c:2769: error: for each function it appears in.)
drivers/video/aty/radeon_pm.c:2770: warning: implicit declaration of function `pmac_set_early_video_resume'
drivers/video/aty/radeon_pm.c | 12 ++++++------
1 files changed, 6 insertions(+), 6 deletions(-)
Index: linux-2.6.15-rc1-olh/drivers/video/aty/radeon_pm.c
===================================================================
--- linux-2.6.15-rc1-olh.orig/drivers/video/aty/radeon_pm.c
+++ linux-2.6.15-rc1-olh/drivers/video/aty/radeon_pm.c
@@ -1321,7 +1321,7 @@ static void radeon_pm_full_reset_sdram(s
mdelay( 15);
}
-#ifdef CONFIG_PPC_OF
+#ifdef CONFIG_PPC_PMAC
static void radeon_pm_reset_pad_ctlr_strength(struct radeonfb_info *rinfo)
{
@@ -2401,7 +2401,7 @@ static void radeon_reinitialize_QW(struc
}
#endif /* 0 */
-#endif /* CONFIG_PPC_OF */
+#endif /* CONFIG_PPC_PMAC */
static void radeon_set_suspend(struct radeonfb_info *rinfo, int suspend)
{
@@ -2700,7 +2700,7 @@ int radeonfb_pci_resume(struct pci_dev *
return rc;
}
-#ifdef CONFIG_PPC_OF
+#ifdef CONFIG_PPC_PMAC
static void radeonfb_early_resume(void *data)
{
struct radeonfb_info *rinfo = data;
@@ -2734,7 +2734,7 @@ void radeonfb_pm_init(struct radeonfb_in
* BIOS does tho. Right now, all this PM stuff is pmac-only for that
* reason. --BenH
*/
-#if defined(CONFIG_PM) && defined(CONFIG_PPC_OF)
+#if defined(CONFIG_PM) && defined(CONFIG_PPC_PMAC)
if (_machine == _MACH_Pmac && rinfo->of_node) {
if (rinfo->is_mobility && rinfo->pm_reg &&
rinfo->family <= CHIP_FAMILY_RV250)
@@ -2778,12 +2778,12 @@ void radeonfb_pm_init(struct radeonfb_in
OUTREG(TV_DAC_CNTL, INREG(TV_DAC_CNTL) | 0x07000000);
#endif
}
-#endif /* defined(CONFIG_PM) && defined(CONFIG_PPC_OF) */
+#endif /* defined(CONFIG_PM) && defined(CONFIG_PPC_PMAC) */
}
void radeonfb_pm_exit(struct radeonfb_info *rinfo)
{
-#if defined(CONFIG_PM) && defined(CONFIG_PPC_OF)
+#if defined(CONFIG_PM) && defined(CONFIG_PPC_PMAC)
if (rinfo->pm_mode != radeon_pm_none)
pmac_set_early_video_resume(NULL, NULL);
#endif
--
short story of a lazy sysadmin:
alias appserv=wotan
^ permalink raw reply
* Re: [PATCH] powerpc: Merge align.c
From: Becky Bruce @ 2005-11-16 16:31 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev list, linuxppc64-dev
In-Reply-To: <43D0A21D-89BC-4EFE-BA2A-94760BA32276@kernel.crashing.org>
> >
> > The 603 is still in production? And is the upcoming 8641 exactly
> > the same as the 74xx series in this respect?
>
> 603 is used in all 82xx/83xx processors from Freescale. The 8641 is=A0
> the same core as 7448.
The differences between 603 and 603e wrt alignment exceptions, as far=20
as I can tell, are:
- 603 does not take exception on misaligned LE accesses except for=20
strings and multiples
- 603 takes an alignment exception on ecowx/eciwx, 603e does not
- 603 generates an alignment when a ld/st crosses a segment boundary=20
and the T bit is different in the 2 segments
I should have listed these out above, sorry!
>
> >> - single and double precision floating point ld/st ops (non-E500,=20=
> non
> >> data size aligned)
> >
> > Hmm, you can load a double from any 4 byte aligned address AFAIR.
>
> This is only because every processor handles the misalignment for=A0
> you.=A0 Its completely valid for someone to build a PPC that has an=A0
> alignment exception in this case.
You're right, I should have said "word-aligned", not "data size=20
aligned". While a load of a doubleword from a word aligned address is=20=
considered misaligned by the hardware, it doesn't generate an exception=20=
in any parts we have now that I know of.
> > However we do care about byte reversal instructions, which
> > probably believe like the corresponding normal instruction
> > (i.e., lwbrx has the same rules as lwzx, etc.)
Yep, they would work the same way, which for all of FSL's current parts=20=
would mean no exception.
> >
> >> - lwarx/stwcx (all procs)
> >
> > And ldarx/stdcx. on 64 bit, but these ones should not
> > be emulated. So it's easy ;-)
> >
> >> - multiple/string with LE set (750, 603e, 7450, 7400)
> >
> > Again LE mode is probably irrelevant.
>
> Agree with that. We dont support LE on classic.
Yep. Just listed for completeness.
>
>
> >> - eciwx/ecowx (750, 7450, 7400)
> >
> > Have these instructions ever been used for something
> > under Linux?
>
> I dont believe so.
These guys are legagy - I don't think anyone uses them, and the=20
alignment exception doesn't (and, IMHO shouldn't) care about them at=20
all. They're just listed here for completeness.
>
> >> - a couple of others related to vector processing
> >
> > Which ones? The Altivec load and store instructions
> > simply mask the low order bits AFAIR.
>
> SPE misalignment is something to look at.
I'll look into it when I have a moment to breathe...... There are 2=20
conditions here that aren't currently handled (from the manual):
- SPFP and SPE instructions are not aligned on a natural boundary=20
(defined by the size of the data element being accessed)
- physical address of certain evld/st instructions is not aligned on a=20=
64-bit boundary.
=09
>
> >> If anybody knows offhand of something missing there, let me know.
> >
> > Nothing, but did you check when crossing a segment (256MB) boundary.
> > I seem to remember that some processors performed misaligned
> > load/store across pages but not across segments.
As far as I can tell, the only one that cares about segment boundaries=20=
is 603 (604, 604e, and 601 may care, but I don't consider those=20
"current", and I don't have any working hardware). And it only takes=20
an exception if there's a difference in the T-bit across the segments.
Cheers!
-B=
^ permalink raw reply
* Re: MPC8555 USB host support
From: Vitaly Bordug @ 2005-11-16 15:57 UTC (permalink / raw)
To: Kumar Gala; +Cc: 'linuxppc-embedded@ozlabs.org'
In-Reply-To: <F9559612-EC8F-44BB-BA15-05DB48D4F031@kernel.crashing.org>
Kumar Gala wrote:
> Hmm, we should understand what caveats it has and still look at getting
> it into mainline.
>
I also have a bunch of patches for gregkh, supporting serial function, but they need
nontrivial cleanup I do not have time currently for. So I think I grab this one together
with my stuff when I head for it.
> Also, are you aware of Freescale's driver for this?
>
I used to try arabella one (came with MW bsp) but that version does not work with 8272.
If there are something usable, it will be interesting to look at.
> - kumar
>
> On Nov 15, 2005, at 9:40 AM, Vitaly Bordug wrote:
>
>> Kumar Gala wrote:
>>> Any reason not to get this driver into the kernel main line?
>> I guess because this device is known to work in some specific
>> instance, but bot generic one. The best we can do is to consolidate
>> our efforts to make it more usable or state that it is impossible.
>>
>>> - kumar
>>> On Nov 15, 2005, at 12:59 AM, Mike Rapoport wrote:
>>>> Hans Schillstrom wrote:
>>>>
>>>>> Hi Mike
>>>>> I'm working with a 8270 board and 2.6.12 kernel and searching for USB
>>>>> drivers.
>>>>>
>>>>> Could you help me finding the files ?
>>>>>
>>>> I've opened a project on the SourceForge,
>>>> http://cpm2usb.sourceforge.net. The file containing patch against
>>>> 2.6.12.3 can be downloaded at http://sourceforge.net/projects/cpm2usb.
>>>>
>>>>> I can help you with the testing.
>>>>> What status do they have right now ?
>>>>>
>>>> The driver was developed on MPC8272ADS, but should go as well on
>>>> 8270 since they have the same USB host controller AFAIK.
>>>> Currently, as far as I tested it works fine with full-speed single
>>>> device attached through hub, but fails is there are transfers
>>>> from/to several devices simultaneously.
>>>> As for the code itself, it's far from being perfect.
>>>>
>>>>> Regards Hans
>>>>>
>>>>
>>>>
>>>> --Sincerely yours,
>>>> Mike Rapoport
>>>>
>>>>
>>>> _______________________________________________
>>>> Linuxppc-embedded mailing list
>>>> Linuxppc-embedded@ozlabs.org
>>>> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>>> _______________________________________________
>>> Linuxppc-embedded mailing list
>>> Linuxppc-embedded@ozlabs.org
>>> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>>
>>
>> --Sincerely,
>> Vitaly
>
>
--
Sincerely,
Vitaly
^ permalink raw reply
* Re: MPC8555 USB host support
From: Kumar Gala @ 2005-11-16 15:50 UTC (permalink / raw)
To: Vitaly Bordug; +Cc: 'linuxppc-embedded@ozlabs.org'
In-Reply-To: <437A016C.8070405@ru.mvista.com>
Hmm, we should understand what caveats it has and still look at
getting it into mainline.
Also, are you aware of Freescale's driver for this?
- kumar
On Nov 15, 2005, at 9:40 AM, Vitaly Bordug wrote:
> Kumar Gala wrote:
>> Any reason not to get this driver into the kernel main line?
> I guess because this device is known to work in some specific
> instance, but bot generic one. The best we can do is to consolidate
> our efforts to make it more usable or state that it is impossible.
>
>> - kumar
>> On Nov 15, 2005, at 12:59 AM, Mike Rapoport wrote:
>>> Hans Schillstrom wrote:
>>>
>>>> Hi Mike
>>>> I'm working with a 8270 board and 2.6.12 kernel and searching
>>>> for USB
>>>> drivers.
>>>>
>>>> Could you help me finding the files ?
>>>>
>>> I've opened a project on the SourceForge, http://
>>> cpm2usb.sourceforge.net. The file containing patch against
>>> 2.6.12.3 can be downloaded at http://sourceforge.net/projects/
>>> cpm2usb.
>>>
>>>> I can help you with the testing.
>>>> What status do they have right now ?
>>>>
>>> The driver was developed on MPC8272ADS, but should go as well on
>>> 8270 since they have the same USB host controller AFAIK.
>>> Currently, as far as I tested it works fine with full-speed
>>> single device attached through hub, but fails is there are
>>> transfers from/to several devices simultaneously.
>>> As for the code itself, it's far from being perfect.
>>>
>>>> Regards Hans
>>>>
>>>
>>>
>>> --Sincerely yours,
>>> Mike Rapoport
>>>
>>>
>>> _______________________________________________
>>> Linuxppc-embedded mailing list
>>> Linuxppc-embedded@ozlabs.org
>>> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>> _______________________________________________
>> Linuxppc-embedded mailing list
>> Linuxppc-embedded@ozlabs.org
>> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
>
> --
> Sincerely,
> Vitaly
^ 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