* Re: signal/syscall/swapcontext fixes
From: Paul Mackerras @ 2006-03-07 20:59 UTC (permalink / raw)
To: David Woodhouse; +Cc: linuxppc-dev
In-Reply-To: <1141736951.4110.167.camel@pmac.infradead.org>
David Woodhouse writes:
> The 64-bit version (bl .save_nvgprs) is prettier than the 32-bit version
> (doing it longhand), and they're still gratuitously different. We should
> probably fix that.
There's also the difference where ret_from_except in 32-bit does what
ret_from_except_lite does in 64-bit, and the 32-bit
ret_from_except_full is approximately the same as the 64-bit
ret_from_except. :)
> On a similar note, we should also do a ptrace stop when we deliver
> signals, to ensure that the debugger gets a stop _on_ the first
> instruction of the handler. Once upon a time there was a stop in
> handle_rt_signal() and handle_signal(), but doing it that way gave a
> _double_ stop when we ended up in a signal handler from sigsuspend(),
> because the syscall stop you just fixed for ppc32 happened too.
Do we have a fix for this for 2.6.16, or will we leave it until
2.6.17?
> On a purely cosmetic note I'm not sure about this though -- it was
> slightly easier to follow when it was more explicit:
> - andi. r0,r9,(_TIF_SYSCALL_T_OR_A|_TIF_SINGLESTEP|_TIF_SIGPENDING|_TIF_NEED_RESCHED|_TIF_RESTOREALL|_TIF_SAVE_NVGPRS|_TIF_NOERROR|_TIF_RESTORE_SIGMASK)
> + andi. r0,r9,(_TIF_SYSCALL_T_OR_A|_TIF_SINGLESTEP|_TIF_USER_WORK_MASK|_TIF_PERSYSCALL_MASK)
I did it that way because we are clearing _TIF_PERSYSCALL_MASK further
down. If we expand one we should expand both.
Paul.
^ permalink raw reply
* Re: Calling PCI Autoconfig again
From: Michael Richardson @ 2006-03-07 15:48 UTC (permalink / raw)
To: Wyse, Chris; +Cc: linuxppc-embedded
In-Reply-To: <927594BA71733F4BAA815162B79A3F513B27FD@ala-mail04.corp.ad.wrs.com>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
You need some kind of hotplug PCI interface to make this work.
When I last tried this -- for the same reason --- it was hard because we
couldn't get the physical memory map from the (PC) BIOS. (This was
before ACPI 2.0...)
Since you have complete control over the board, you should have this
information already.
- --
] ON HUMILITY: to err is human. To moo, bovine. | firewalls [
] Michael Richardson, Xelerance Corporation, Ottawa, ON |net architect[
] mcr@xelerance.com http://www.sandelman.ottawa.on.ca/mcr/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Finger me for keys
iQEVAwUBRA2rNICLcPvd0N1lAQLchQf9E6B6ISMnpam5rgCXe67RQz3IWseOMtAb
8m65WKBDwTUxwKIwiOygY0AnLudL4+dSKp8QaswXsjl4g7BvjVBwjWH0itmIvWew
1V0BUVJUNMpzYH7I9fEtbJXjQvN/8VyJRX+7HIndvH1CWpeDzHgQTAVu+CIVfyGI
SEEZsgwzgq8mzbopawxPORd+rKv9F6tlnbqAU8P1eHB8wcUEu+WZQ+oA3WGS+Zhn
5ZjK3dX+QXI2JykicyS7VVUT5D6vaZFon4Ikk4Ao0JKfNHmAD7fN4BHhORrpGYyR
+dHlRZlZiRfw3AEoqg6XZZrcGWfciBK8mD6utPnSHomMsaTk80jbtQ==
=o2Wv
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: Calling PCI Autoconfig again
From: Kumar Gala @ 2006-03-07 19:57 UTC (permalink / raw)
To: Wyse, Chris; +Cc: linuxppc-embedded, McComb, Michael, Touron, Emmanuel
In-Reply-To: <927594BA71733F4BAA815162B79A3F513B2B03@ala-mail04.corp.ad.wrs.com>
On Mar 7, 2006, at 1:25 PM, Wyse, Chris wrote:
> Hi Kumar,
>
> Thanks for the response. Also, I apologize to the group - I didn't
> mean
> to CC: the list with the last note. However, I am glad that it got a
> response from you.
>
> Regarding the FPGA address assignment - it doesn't matter at all to
> me,
> I just need to be able to access it on the PCI once the load is
> complete.
>
> As for the FPGA loader, the intent is that it will make the call to
> rescan the PCI after the load is complete. In fact, I intend to
> use it
> as a way of determining if the load completed successfully, since we
> don't have access to the DONE signal from the FPGA (we ran out of GPIO
> pins).
>
> If you missed this link from a previous post, please check it out. It
> implements a rescan of the PCI.
>
> http://marc.theaimsgroup.com/?l=linux-hotplug-
> devel&m=101318310111131&w=
> 2
I saw this link and felt that the code was doing alot of work that
was already handled by the PCI subsystem for you. For example, there
isn't a need for you to kmalloc your own dev and go through all the
effort.
For your case it should be as simple as the following:
bus = pci_find_bus(0, bus_of_dev);
dev = pci_scan_single_device(bus, devfn);
pci_bus_alloc_resource(...);
pci_bus_add_devices(bus);
You could also look at using the pci_scan_slot() / pci_find_slot()
instead of pci_scan_single_device().
- kumar
^ permalink raw reply
* RE: Calling PCI Autoconfig again
From: Wyse, Chris @ 2006-03-07 19:25 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-embedded, McComb, Michael, Touron, Emmanuel
Hi Kumar,
Thanks for the response. Also, I apologize to the group - I didn't mean
to CC: the list with the last note. However, I am glad that it got a
response from you.
Regarding the FPGA address assignment - it doesn't matter at all to me,
I just need to be able to access it on the PCI once the load is
complete.
As for the FPGA loader, the intent is that it will make the call to
rescan the PCI after the load is complete. In fact, I intend to use it
as a way of determining if the load completed successfully, since we
don't have access to the DONE signal from the FPGA (we ran out of GPIO
pins). =20
If you missed this link from a previous post, please check it out. It
implements a rescan of the PCI.
http://marc.theaimsgroup.com/?l=3Dlinux-hotplug-devel&m=3D101318310111131=
&w=3D
2=20
I see that you have a requirement for a fixed BAR address. I think you
could modify the code from the above link to load a new BAR address
after the PCI has been rescanned. You could probably add a routine to
register a BAR address for a device, and change the check_hw() routine
to see if a BAR address is registered. If so, it would free the
allocated space for the device, allocate space at the desired address,
then write the new address to the BAR.
Hope this helps. I'll be monitoring your thread for future
developments.
Chris Wyse
Member of Technical Staff
Embedded Technologies
860-749-1556 office
860-978-0849 cell
413-778-9101 fax
http://www.windriver.com
=20
-----Original Message-----
From: Kumar Gala [mailto:galak@kernel.crashing.org]=20
Sent: Tuesday, March 07, 2006 11:27 AM
To: Wyse, Chris
Cc: Touron, Emmanuel; McComb, Michael; linuxppc-embedded@ozlabs.org
Subject: Re: Calling PCI Autoconfig again
On Mar 7, 2006, at 8:17 AM, Wyse, Chris wrote:
> Hi,
>
> This code will do the rescan of the PCI that we need for the FPGA.
> However, it currently only supports a single execution after the FPGA=20
> gets loaded. Additional calls will continue to add FPGA devices to=20
> the PCI device list data structure. I'm going to make some changes to
> it to handle multiple calls and to support multiple device ids. I'm=20
> expecting it to take a day or two, but I'll make an initial cut at it=20
> today that will let us load the Spartan FPGA (only once). This driver
> will be loaded when the kernel boots, so I believe that we'll just=20
> need to make a call into it (we won't have to dynamically load it like
> the phob driver).
I'm dealing with this exact same situation and having a discussion on
lkml regarding the proper way to do this. In your case, do you care
what addresses the FPGA is assigned at?
http://marc.theaimsgroup.com/?l=3Dlinux-kernel&m=3D114140791428032&w=3D2
> Michael,
>
> For the FPGA loader, you should load the FPGA, then make a call to
> pci_rescan_bus0() (I'm renaming check_hw() to pci_rescan_bus0()). =20
> Next,
> you need to do a pci_find_device() to detect the newly loaded FPGA. =20
> If the pci_find_device() fails, assume that the FPGA load has not=20
> completed, so delay for some time frame (100 ms??), then rescan again.
> If still not found, rescan up to MAX_PCI_RESCANS (probably set it to=20
> 3) times, then return an error that the FPGA load failed.
Do you not know when the FPGA load is done? I assume its under software
control so the "fpga loader" should just call the PCI setup code once it
has completed successfully.
- kumar
^ permalink raw reply
* RE: help reqd
From: atul.sabharwal @ 2006-03-07 18:27 UTC (permalink / raw)
To: achim.machura, prabha.j; +Cc: linuxppc-embedded
> insmod: unresolved symbol copy_to_user=20
> insmod: unresolved symbol down=20
> insmod: unresolved symbol up=20
> insmod: unresolved symbol copy_from_user=20
>>you have to include <asm/uacces.h>
Including a header file is only needed for compilation. This is a
dynamic link/load error. Unless the header file is putting some
information about the kernel link/load method. Without module
versioning, you should be able=20
To load any driver binary compiled for a given kernel version. Any
exceptions to this concept ?
--
Atul
^ permalink raw reply
* RE: help reqd
From: atul.sabharwal @ 2006-03-07 18:23 UTC (permalink / raw)
To: prabha.j, linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 1796 bytes --]
Possible answers: Module versioning turned on in kernel? insmod module
format not compatible with kernel ? Try modprobe which
checks the dependencies. These calls are kernel space to user space
copy operations. Top 3GB to below 3GB on most systems
unless it's a 2GB/2GB split between user/kernel space.
--
Atul
________________________________
From: linuxppc-embedded-bounces+atul.sabharwal=tek.com@ozlabs.org
[mailto:linuxppc-embedded-bounces+atul.sabharwal=tek.com@ozlabs.org] On
Behalf Of prabha.j@tcs.com
Sent: Tuesday, March 07, 2006 3:17 AM
To: linuxppc-embedded@ozlabs.org
Subject: help reqd
Hi all ,
I have a driver and when i am doing insmod the driver its giving
unresolved symbol.
insmod: unresolved symbol copy_to_user
insmod: unresolved symbol down
insmod: unresolved symbol up
insmod: unresolved symbol copy_from_user
Can anyone suggest me where i am doing wrong.
I am using linux-2.4.25 kernel from denx and my board is a
customboard(mpc8260 processor).
This is a upm driver and built as a loadable module.
Please help me in this regard
Thanks in advance.
Regards
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: 7131 bytes --]
^ permalink raw reply
* Re: GNU and Freescale MPC83xx / e300 core support?
From: Kim Phillips @ 2006-03-07 18:11 UTC (permalink / raw)
To: rmcguire; +Cc: linuxppc-embedded
In-Reply-To: <7C2FA1F5-DF91-495E-A2C3-052048E34DFE@kernel.crashing.org>
according to one of our architects, the 81xx, 82xx, 83xx, 52xx, and 51xx (all G2/e300 based parts) all share the same 603 pipeline:
o dispatch 2 instructions, plus 1 branch per cycle,
o up to 5 instructions in the pipeline at any given time,
o a maximum of 2 instructions are completed per cycle.
the changes are:
o multiple HID0, HID1, HID3 bits for optimizing system,
o icbt
o PLL options
so, the answer is no, modifying the compiler's scheduler won't do anything for you.
as Kumar says, the caches and adding icbt to your code does improve performance.
Kim
On Tue, 7 Mar 2006 10:03:53 -0600
Kumar Gala <galak@kernel.crashing.org> wrote:
>
> On Mar 7, 2006, at 9:54 AM, Russell McGuire wrote:
>
> > Thanks all...
> >
> > The author of that comment humbly apologizes for his ineptitude on
> > the FPU.
> >
> > It would appear both cores have the same number of execution units,
> > i.e. 5
> > So David, I guess in all this the only real difference seems to be
> > the bus
> > architecture, raw clock speed, and perhaps a few new instructions.
> > I checked
> > both manuals this morning and they do differ in some small ways.
> >
> > * 603e, up to 4 instructions in the pipeline, only 3 being complete
> > per
> > clock
> > * e300, up to 5 instructions in the pipeline, still only 3 being
> > completed
> > or start per clock.
> > * Add/compare instructions are now executed in the IU unit instead
> > of the
> > load/store unit. May be the same, but wasn't specific in earlier 603e
> > manuals.
> > * One more HID0 bit than G2, ability to interrupt based on cache
> > parity
> > error
> > * new icbt instruction, instruction cache initialization
> >
> > So there is a section inside the 8360E manual that outlines the
> > specific
> > enhancements. "Features specific to the e300 core not present on
> > the G2
> > processors follow:" Page 1-5.
> >
> > So I guess my question is back up, does anyone know if an optimized
> > compiler
> > would offer any noticeable performance enhancements in regards to
> > these
> > changes? Other than the obvious instruction being added?
>
> If you are asking about relative performance between the same
> compiler tuned for a 603 vs e300, the there would most likely be a
> small improvement.
>
> However, a few things to note. The new icbt instruction is really
> intended for hand written assemble code and its highly unlikely that
> a compiler will ever generate it. Second, the other improvements
> from the base 603e/G2LE in 8280, like doubling of the L1 caches has a
> significant improvement in performance.
>
> - kumar
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
--
^ permalink raw reply
* Re: Calling PCI Autoconfig again
From: Mark Chambers @ 2006-03-07 17:22 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-embedded
In-Reply-To: <84F54A3B-0B2A-45B5-968D-68266C6EDEDA@kernel.crashing.org>
>
> On Mar 7, 2006, at 10:53 AM, Mark Chambers wrote:
>
>>> I'm dealing with this exact same situation and having a discussion
>>> on lkml regarding the proper way to do this. In your case, do
>>> you care what addresses the FPGA is assigned at?
>>> http://marc.theaimsgroup.com/?l=linux-kernel&m=114140791428032&w=2
>>
>> Why does the PCI device have to have a fixed address? And how do
>> you load an FPGA from user space - mmap?
>
> In my case it does because we have other devices (DSPs) that are hard
> coded to know where in PCI address space the FPGA is.
>
Ah, ok. So I'm guessing we're talking about DSP bus-master operations
where the DSP is putting out physical PCI space addresses that the
MMU can't help map. I've run into a similar problem where I'd like to
be able to have a DSP do CPM/BD-like operations from SDRAM, but
it's exceedingly difficult to get the physical address of user-space data.
Well, FWIW, seems to me that something like what Greg K-H referred to,
where you pre-reserve space in PCI land, and then put the device there
when it becomes available, is the way to go. Otherwise you have this
un-managed hole in PCI space allocation that might cause other problems
with true hot-swap PCI, or break with kernel revisions.
Mark
^ permalink raw reply
* Re: Calling PCI Autoconfig again
From: Kumar Gala @ 2006-03-07 16:59 UTC (permalink / raw)
To: Mark Chambers; +Cc: linuxppc-embedded
In-Reply-To: <004901c64207$a31403c0$6401a8c0@CHUCK2>
On Mar 7, 2006, at 10:53 AM, Mark Chambers wrote:
>> I'm dealing with this exact same situation and having a discussion
>> on lkml regarding the proper way to do this. In your case, do
>> you care what addresses the FPGA is assigned at?
>> http://marc.theaimsgroup.com/?l=linux-kernel&m=114140791428032&w=2
>
> Why does the PCI device have to have a fixed address? And how do
> you load an FPGA from user space - mmap?
In my case it does because we have other devices (DSPs) that are hard
coded to know where in PCI address space the FPGA is.
As for how does one load it. We have GPIO pins connected to the FPGA
and load it from a file in user space with a kernel driver
implementing the bit "protocol" over GPIO.
- kumar
^ permalink raw reply
* Re: Calling PCI Autoconfig again
From: Mark Chambers @ 2006-03-07 16:53 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-embedded
In-Reply-To: <BAB64425-65CD-4311-9A93-004EBA27729A@kernel.crashing.org>
> I'm dealing with this exact same situation and having a discussion on
> lkml regarding the proper way to do this. In your case, do you care
> what addresses the FPGA is assigned at?
>
> http://marc.theaimsgroup.com/?l=linux-kernel&m=114140791428032&w=2
>
Why does the PCI device have to have a fixed address? And how do
you load an FPGA from user space - mmap?
Mark C.
^ permalink raw reply
* Re: fs_enet on 2.4 and 8xx_immap
From: Brent Cook @ 2006-03-07 16:18 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <20060307154903.18326.qmail@mx1.aruba.it>
On Tuesday 07 March 2006 09:49, antonio.dibacco wrote:
> Hi,
>
> I'm a novice and I don't understand what is "IIRC". Is something that
> handles the two FECs on 885ads? I knew that on 885ads the second ethernet
> was realized via an SCC and not FEC. Am I wrong?
>
> Bye,
> Antonio.
That is too funny! "IIRC" is an abbreviation for "if I recall"
^ permalink raw reply
* Re: Calling PCI Autoconfig again
From: Kumar Gala @ 2006-03-07 16:26 UTC (permalink / raw)
To: Wyse, Chris; +Cc: linuxppc-embedded, McComb, Michael, Touron, Emmanuel
In-Reply-To: <927594BA71733F4BAA815162B79A3F513B2958@ala-mail04.corp.ad.wrs.com>
On Mar 7, 2006, at 8:17 AM, Wyse, Chris wrote:
> Hi,
>
> This code will do the rescan of the PCI that we need for the FPGA.
> However, it currently only supports a single execution after the FPGA
> gets loaded. Additional calls will continue to add FPGA devices to
> the
> PCI device list data structure. I'm going to make some changes to
> it to
> handle multiple calls and to support multiple device ids. I'm
> expecting
> it to take a day or two, but I'll make an initial cut at it today that
> will let us load the Spartan FPGA (only once). This driver will be
> loaded when the kernel boots, so I believe that we'll just need to
> make
> a call into it (we won't have to dynamically load it like the phob
> driver).
I'm dealing with this exact same situation and having a discussion on
lkml regarding the proper way to do this. In your case, do you care
what addresses the FPGA is assigned at?
http://marc.theaimsgroup.com/?l=linux-kernel&m=114140791428032&w=2
> Michael,
>
> For the FPGA loader, you should load the FPGA, then make a call to
> pci_rescan_bus0() (I'm renaming check_hw() to pci_rescan_bus0()).
> Next,
> you need to do a pci_find_device() to detect the newly loaded
> FPGA. If
> the pci_find_device() fails, assume that the FPGA load has not
> completed, so delay for some time frame (100 ms??), then rescan again.
> If still not found, rescan up to MAX_PCI_RESCANS (probably set it
> to 3)
> times, then return an error that the FPGA load failed.
Do you not know when the FPGA load is done? I assume its under
software control so the "fpga loader" should just call the PCI setup
code once it has completed successfully.
- kumar
^ permalink raw reply
* Re: GNU and Freescale MPC83xx / e300 core support?
From: Kumar Gala @ 2006-03-07 16:03 UTC (permalink / raw)
To: Russell McGuire; +Cc: linuxppc-embedded
In-Reply-To: <002b01c641ff$666ccc70$6405a8c0@absolut>
On Mar 7, 2006, at 9:54 AM, Russell McGuire wrote:
> Thanks all...
>
> The author of that comment humbly apologizes for his ineptitude on
> the FPU.
>
> It would appear both cores have the same number of execution units,
> i.e. 5
> So David, I guess in all this the only real difference seems to be
> the bus
> architecture, raw clock speed, and perhaps a few new instructions.
> I checked
> both manuals this morning and they do differ in some small ways.
>
> * 603e, up to 4 instructions in the pipeline, only 3 being complete
> per
> clock
> * e300, up to 5 instructions in the pipeline, still only 3 being
> completed
> or start per clock.
> * Add/compare instructions are now executed in the IU unit instead
> of the
> load/store unit. May be the same, but wasn't specific in earlier 603e
> manuals.
> * One more HID0 bit than G2, ability to interrupt based on cache
> parity
> error
> * new icbt instruction, instruction cache initialization
>
> So there is a section inside the 8360E manual that outlines the
> specific
> enhancements. "Features specific to the e300 core not present on
> the G2
> processors follow:" Page 1-5.
>
> So I guess my question is back up, does anyone know if an optimized
> compiler
> would offer any noticeable performance enhancements in regards to
> these
> changes? Other than the obvious instruction being added?
If you are asking about relative performance between the same
compiler tuned for a 603 vs e300, the there would most likely be a
small improvement.
However, a few things to note. The new icbt instruction is really
intended for hand written assemble code and its highly unlikely that
a compiler will ever generate it. Second, the other improvements
from the base 603e/G2LE in 8280, like doubling of the L1 caches has a
significant improvement in performance.
- kumar
^ permalink raw reply
* RE: GNU and Freescale MPC83xx / e300 core support?
From: Russell McGuire @ 2006-03-07 15:54 UTC (permalink / raw)
To: 'Dan Malek'; +Cc: linuxppc-embedded
In-Reply-To: <50206c46cf7e37ede345eebf82ad6fbc@embeddedalley.com>
Thanks all...
The author of that comment humbly apologizes for his ineptitude on the FPU.
It would appear both cores have the same number of execution units, i.e. 5
So David, I guess in all this the only real difference seems to be the bus
architecture, raw clock speed, and perhaps a few new instructions. I checked
both manuals this morning and they do differ in some small ways.
* 603e, up to 4 instructions in the pipeline, only 3 being complete per
clock
* e300, up to 5 instructions in the pipeline, still only 3 being completed
or start per clock.
* Add/compare instructions are now executed in the IU unit instead of the
load/store unit. May be the same, but wasn't specific in earlier 603e
manuals.
* One more HID0 bit than G2, ability to interrupt based on cache parity
error
* new icbt instruction, instruction cache initialization
So there is a section inside the 8360E manual that outlines the specific
enhancements. "Features specific to the e300 core not present on the G2
processors follow:" Page 1-5.
So I guess my question is back up, does anyone know if an optimized compiler
would offer any noticeable performance enhancements in regards to these
changes? Other than the obvious instruction being added?
Thanks
-Russ
-----Original Message-----
From: Dan Malek [mailto:dan@embeddedalley.com]
Sent: Tuesday, March 07, 2006 4:33 AM
To: Russell McGuire
Cc: 'David Hawkins'; linuxppc-embedded@ozlabs.org
Subject: Re: GNU and Freescale MPC83xx / e300 core support?
On Mar 7, 2006, at 12:52 AM, Russell McGuire wrote:
> ..... The most obvious core difference is
> the Floating Point unit; the MPC8280, 603e or G2LE core had no floating
> point ability at all.
I just want to state for archive purposes this simply isn't true.
All of those processors had hardware FPUs. If you would take
a few seconds and read the product overviews for these parts,
you can make your own informed decision. The person you
are talking to doesn't seem to have all of the facts in order.
-- Dan
^ permalink raw reply
* Re: fs_enet on 2.4 and 8xx_immap
From: antonio.dibacco @ 2006-03-07 15:49 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <20060307184217.1422472c@vitb.ru.mvista.com>
Hi,
I'm a novice and I don't understand what is "IIRC". Is something that
handles the two FECs on 885ads? I knew that on 885ads the second ethernet
was realized via an SCC and not FEC. Am I wrong?
Bye,
Antonio.
Vitaly Bordug Scrive:
> On Tue, 07 Mar 2006 15:37:16 GMT
> "antonio.dibacco" <antonio.dibacco@aruba.it> wrote:
>
>> I think I will use the 8xx_immap.h borrowed from u-boot-1.1.4, it is really
>> similar to that of 2.4.25, with some explicit padding and fec2. Do you think
>> that porting fs_enet to 2.4 is it the best way to have both FECs working on
>> a MPC875? I don't want to use 2.6.
>>
> Sounds reasonable, but I'll repeat:
> fs_enet patches for 2.6 used to support 2.4 thing(via #ifdef's), it was cleaned up close to submission. IIRC, it handles 2 fecs quite great on my 885ads, so it worths to search around a bit before hacking...
>
>> Bye,
>> Antonio.
>>
>> Vitaly Bordug Scrive:
>>
>> > On Tue, 07 Mar 2006 13:15:00 GMT
>> > "antonio.dibacco" <antonio.dibacco@aruba.it> wrote:
>> >
>> >> I think that to make it work I need to update cpm8xx_t inserting the fec2
>> >> filed. Is this true? Could I use the 8xx_immap.h of a 2.6 kernel?
>> >>
>> > Not exactly. I think you can borrow the structures from 2.6, but do a triple-check that the result offsets are the same.
>> >
>> >> Bye,
>> >> Antonio.
>> >> _______________________________________________
>> >> Linuxppc-embedded mailing list
>> >> Linuxppc-embedded@ozlabs.org
>> >> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>> >>
>> >>
>> >
>> >
>> > --
>> > Sincerely,
>> > Vitaly
>>
>>
>>
>
>
> --
> Sincerely,
> Vitaly
^ permalink raw reply
* Re: fs_enet on 2.4 and 8xx_immap
From: Vitaly Bordug @ 2006-03-07 15:42 UTC (permalink / raw)
To: antonio.dibacco; +Cc: linuxppc-embedded
In-Reply-To: <20060307153716.1130.qmail@mx1.aruba.it>
On Tue, 07 Mar 2006 15:37:16 GMT
"antonio.dibacco" <antonio.dibacco@aruba.it> wrote:
> I think I will use the 8xx_immap.h borrowed from u-boot-1.1.4, it is really
> similar to that of 2.4.25, with some explicit padding and fec2. Do you think
> that porting fs_enet to 2.4 is it the best way to have both FECs working on
> a MPC875? I don't want to use 2.6.
>
Sounds reasonable, but I'll repeat:
fs_enet patches for 2.6 used to support 2.4 thing(via #ifdef's), it was cleaned up close to submission. IIRC, it handles 2 fecs quite great on my 885ads, so it worths to search around a bit before hacking...
> Bye,
> Antonio.
>
> Vitaly Bordug Scrive:
>
> > On Tue, 07 Mar 2006 13:15:00 GMT
> > "antonio.dibacco" <antonio.dibacco@aruba.it> wrote:
> >
> >> I think that to make it work I need to update cpm8xx_t inserting the fec2
> >> filed. Is this true? Could I use the 8xx_immap.h of a 2.6 kernel?
> >>
> > Not exactly. I think you can borrow the structures from 2.6, but do a triple-check that the result offsets are the same.
> >
> >> Bye,
> >> Antonio.
> >> _______________________________________________
> >> Linuxppc-embedded mailing list
> >> Linuxppc-embedded@ozlabs.org
> >> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
> >>
> >>
> >
> >
> > --
> > Sincerely,
> > Vitaly
>
>
>
--
Sincerely,
Vitaly
^ permalink raw reply
* Re: fs_enet on 2.4 and 8xx_immap
From: antonio.dibacco @ 2006-03-07 15:37 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <20060307165522.7936fd7b@vitb.ru.mvista.com>
I think I will use the 8xx_immap.h borrowed from u-boot-1.1.4, it is really
similar to that of 2.4.25, with some explicit padding and fec2. Do you think
that porting fs_enet to 2.4 is it the best way to have both FECs working on
a MPC875? I don't want to use 2.6.
Bye,
Antonio.
Vitaly Bordug Scrive:
> On Tue, 07 Mar 2006 13:15:00 GMT
> "antonio.dibacco" <antonio.dibacco@aruba.it> wrote:
>
>> I think that to make it work I need to update cpm8xx_t inserting the fec2
>> filed. Is this true? Could I use the 8xx_immap.h of a 2.6 kernel?
>>
> Not exactly. I think you can borrow the structures from 2.6, but do a triple-check that the result offsets are the same.
>
>> Bye,
>> Antonio.
>> _______________________________________________
>> Linuxppc-embedded mailing list
>> Linuxppc-embedded@ozlabs.org
>> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>>
>>
>
>
> --
> Sincerely,
> Vitaly
^ permalink raw reply
* RE: Calling PCI Autoconfig again
From: Wyse, Chris @ 2006-03-07 14:17 UTC (permalink / raw)
To: Touron, Emmanuel, McComb, Michael; +Cc: linuxppc-embedded
Hi,
This code will do the rescan of the PCI that we need for the FPGA.
However, it currently only supports a single execution after the FPGA
gets loaded. Additional calls will continue to add FPGA devices to the
PCI device list data structure. I'm going to make some changes to it to
handle multiple calls and to support multiple device ids. I'm expecting
it to take a day or two, but I'll make an initial cut at it today that
will let us load the Spartan FPGA (only once). This driver will be
loaded when the kernel boots, so I believe that we'll just need to make
a call into it (we won't have to dynamically load it like the phob
driver). =20
Michael,
For the FPGA loader, you should load the FPGA, then make a call to
pci_rescan_bus0() (I'm renaming check_hw() to pci_rescan_bus0()). Next,
you need to do a pci_find_device() to detect the newly loaded FPGA. If
the pci_find_device() fails, assume that the FPGA load has not
completed, so delay for some time frame (100 ms??), then rescan again.
If still not found, rescan up to MAX_PCI_RESCANS (probably set it to 3)
times, then return an error that the FPGA load failed.=20
Chris Wyse
Member of Technical Staff
Embedded Technologies
860-749-1556 office
860-978-0849 cell
413-778-9101 fax
http://www.windriver.com
=20
-----Original Message-----
From: Wyse, Chris=20
Sent: Tuesday, March 07, 2006 8:49 AM
To: 'David Hawkins'
Cc: 'linuxppc-embedded@ozlabs.org'; Touron, Emmanuel; McComb, Michael
Subject: RE: Calling PCI Autoconfig again
Hi Dave,
Thanks for the input.
I was thinking about making the FPGA a hotplug device. I was really
hoping that I could just enable CONFIG_HOTPLUG in the kernel build, but
after some research, I don't believe that will work. The hotplug
approach was more work than I wanted, but after your response, I decided
to look into it some more, specifically looking for an FPGA
implementation similar to ours. I searched the linux-hotplug-devel list
for FPGA, and found this:
http://marc.theaimsgroup.com/?l=3Dlinux-hotplug-devel&m=3D101318310111131=
&w=3D
2
It implements a rescan of the PCI bus for a newly loaded FPGA device
(although despite the group name, it doesn't use HotPlug).
I'm going to try to use the code from the above link rather than
implement a hotplug driver. =20
Thanks again for the help.
Chris Wyse
Member of Technical Staff
Embedded Technologies
860-749-1556 office
860-978-0849 cell
413-778-9101 fax
http://www.windriver.com
=20
-----Original Message-----
From: David Hawkins [mailto:dwh@ovro.caltech.edu]
Sent: Monday, March 06, 2006 11:33 PM
To: Wyse, Chris
Cc: linuxppc-embedded@ozlabs.org
Subject: Re: Calling PCI Autoconfig again
Wyse, Chris wrote:
> Hi,
> =20
> I'm working on a board (PPC440GX CPU) that has an FPGA on it. The=20
> FPGA software has a PCI interface. If I load the FPGA, then boot the=20
> Linux kernel, the FPGA is recognized as a device on the PCI bus.
> However, I'd like to load the FPGA after the kernel has booted, then=20
> run autoconfig again to detect the device. What's the best way to do
this?
> =20
> Please send responses directly to me (in addition to the list), since=20
> I am not subscribed to the list.
Hi Chris,
I haven't had to do this, but I've thought about how I might do it.
In compact PCI, you can hot-swap a PCI device, and the Linux host is
supposed to go and re-enumerate the PCI bus. There is a pci (host-side)
hotplug skeleton in the source;
linux-2.6/drivers/pci/hotplug/pcihp_skeleton.c
I believe you can do the following;
- consider the 440GX is a hotplug controller
(and write a hotplug driver appropriately)
- when Linux loads the FPGA, the FPGA generates a hotplug
event, i.e., it just got plugged in
(I'm not sure what signal is generated, perhaps a
power-management interrupt PME#?)
- the 440GX hotplug controller re-enumerates the PCI bus
and finds the device
I'm sure you can get an idea from the hotplug skeleton what
re-enumeration entails.
Cheers
Dave
^ permalink raw reply
* Re: fs_enet on 2.4 and 8xx_immap
From: Vitaly Bordug @ 2006-03-07 13:55 UTC (permalink / raw)
To: antonio.dibacco; +Cc: linuxppc-embedded
In-Reply-To: <20060307131500.3467.qmail@mx1.aruba.it>
On Tue, 07 Mar 2006 13:15:00 GMT
"antonio.dibacco" <antonio.dibacco@aruba.it> wrote:
> I think that to make it work I need to update cpm8xx_t inserting the fec2
> filed. Is this true? Could I use the 8xx_immap.h of a 2.6 kernel?
>
Not exactly. I think you can borrow the structures from 2.6, but do a triple-check that the result offsets are the same.
> Bye,
> Antonio.
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
>
--
Sincerely,
Vitaly
^ permalink raw reply
* RE: Calling PCI Autoconfig again
From: Wyse, Chris @ 2006-03-07 13:49 UTC (permalink / raw)
To: David Hawkins; +Cc: Touron, Emmanuel, McComb, Michael, linuxppc-embedded
Hi Dave,
Thanks for the input.
I was thinking about making the FPGA a hotplug device. I was really
hoping that I could just enable CONFIG_HOTPLUG in the kernel build, but
after some research, I don't believe that will work. The hotplug
approach was more work than I wanted, but after your response, I decided
to look into it some more, specifically looking for an FPGA
implementation similar to ours. I searched the linux-hotplug-devel list
for FPGA, and found this:
http://marc.theaimsgroup.com/?l=3Dlinux-hotplug-devel&m=3D101318310111131=
&w=3D
2
It implements a rescan of the PCI bus for a newly loaded FPGA device
(although despite the group name, it doesn't use HotPlug).
I'm going to try to use the code from the above link rather than
implement a hotplug driver. =20
Thanks again for the help.
Chris Wyse
Member of Technical Staff
Embedded Technologies
860-749-1556 office
860-978-0849 cell
413-778-9101 fax
http://www.windriver.com
=20
-----Original Message-----
From: David Hawkins [mailto:dwh@ovro.caltech.edu]=20
Sent: Monday, March 06, 2006 11:33 PM
To: Wyse, Chris
Cc: linuxppc-embedded@ozlabs.org
Subject: Re: Calling PCI Autoconfig again
Wyse, Chris wrote:
> Hi,
> =20
> I'm working on a board (PPC440GX CPU) that has an FPGA on it. The=20
> FPGA software has a PCI interface. If I load the FPGA, then boot the=20
> Linux kernel, the FPGA is recognized as a device on the PCI bus. =20
> However, I'd like to load the FPGA after the kernel has booted, then=20
> run autoconfig again to detect the device. What's the best way to do
this?
> =20
> Please send responses directly to me (in addition to the list), since=20
> I am not subscribed to the list.
Hi Chris,
I haven't had to do this, but I've thought about how I might do it.
In compact PCI, you can hot-swap a PCI device, and the Linux host is
supposed to go and re-enumerate the PCI bus. There is a pci (host-side)
hotplug skeleton in the source;
linux-2.6/drivers/pci/hotplug/pcihp_skeleton.c
I believe you can do the following;
- consider the 440GX is a hotplug controller
(and write a hotplug driver appropriately)
- when Linux loads the FPGA, the FPGA generates a hotplug
event, i.e., it just got plugged in
(I'm not sure what signal is generated, perhaps a
power-management interrupt PME#?)
- the 440GX hotplug controller re-enumerates the PCI bus
and finds the device
I'm sure you can get an idea from the hotplug skeleton what
re-enumeration entails.
Cheers
Dave
^ permalink raw reply
* fs_enet on 2.4 and 8xx_immap
From: antonio.dibacco @ 2006-03-07 13:15 UTC (permalink / raw)
To: linuxppc-embedded
I think that to make it work I need to update cpm8xx_t inserting the fec2
filed. Is this true? Could I use the 8xx_immap.h of a 2.6 kernel?
Bye,
Antonio.
^ permalink raw reply
* Re: signal/syscall/swapcontext fixes
From: David Woodhouse @ 2006-03-07 13:09 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <17421.32092.442696.49291@cargo.ozlabs.ibm.com>
On Tue, 2006-03-07 at 23:32 +1100, Paul Mackerras wrote:
> * The TIF_SAVE_NVGPRS mechanism was only being used by swapcontext, so
> I removed it and put swapcontext back the way it was in 2.6.15, with
> an assembler stub to save the non-volatile GPRs before calling the C
> code. The save_general_regs functions now WARN_ON(!FULL_REGS(regs)).
OK. As observed, I'd mostly obsoleted TIF_SAVE_NVGPRS when I implemented
TIF_RESTORE_SIGMASK.
The 64-bit version (bl .save_nvgprs) is prettier than the 32-bit version
(doing it longhand), and they're still gratuitously different. We should
probably fix that.
> * 32-bit wasn't testing the _TIF_NOERROR bit in the syscall fast exit
> path, so it was only doing anything with it once it saw some other
> bit being set.
OK.
> * 32-bit wasn't doing the call to ptrace_notify in the syscall exit
> path when the _TIF_SINGLESTEP bit was set.
Yeah. That was historical (arch/ppc never did this) but nonetheless
still wrong. Without it, we never stop on the instruction immediately
following the 'sc', when we're supposed to be single-stepping.
On a similar note, we should also do a ptrace stop when we deliver
signals, to ensure that the debugger gets a stop _on_ the first
instruction of the handler. Once upon a time there was a stop in
handle_rt_signal() and handle_signal(), but doing it that way gave a
_double_ stop when we ended up in a signal handler from sigsuspend(),
because the syscall stop you just fixed for ppc32 happened too.
> * _TIF_RESTOREALL was in both _TIF_USER_WORK_MASK and
> _TIF_PERSYSCALL_MASK, which is odd since _TIF_RESTOREALL is only set
> by system calls. I took it out of _TIF_USER_WORK_MASK.
Right.
> * On 64-bit, _TIF_RESTOREALL wasn't causing the non-volatile registers
> to be restored (unless perhaps a signal was delivered or the syscall
> was traced or single-stepped). Thus the non-volatile registers
> weren't restored on exit from a signal handler. We probably got
> away with it mostly because signal handlers written in C wouldn't
> alter the non-volatile registers.
Hm, yes. The idea behind TIF_RESTOREALL was just to prevent r3 and the
flags from getting stomped on -- I didn't look at the nvgprs at that
point, and I'm not sure if the nvgprs were being restored on ppc32
before my changes. They could well have been on ppc64 -- this was
another area in which the two were different.
> * On 32-bit I simplified the code and made it more like 64-bit by
> making the syscall exit path jump to ret_from_except to handle
> preemption and signal delivery.
OK, good. It would actually be nice if we could split a bunch of this
code out into a shared file and use the PPC_LL, PPC_STL, etc. macros.
> * 32-bit was calling do_signal unnecessarily when _TIF_RESTOREALL was
> set - but I think because of that 32-bit was actually restoring the
> non-volatile registers on exit from a signal handler.
OK.
> * I changed the order of enabling interrupts and saving the
> non-volatile registers before calling do_syscall_trace_leave; now we
> enable interrupts first.
OK.
> Any comments before I send this off to Linus to go in 2.6.16?
Looks good.
On a purely cosmetic note I'm not sure about this though -- it was
slightly easier to follow when it was more explicit:
- andi. r0,r9,(_TIF_SYSCALL_T_OR_A|_TIF_SINGLESTEP|_TIF_SIGPENDING|_TIF_NEED_RESCHED|_TIF_RESTOREALL|_TIF_SAVE_NVGPRS|_TIF_NOERROR|_TIF_RESTORE_SIGMASK)
+ andi. r0,r9,(_TIF_SYSCALL_T_OR_A|_TIF_SINGLESTEP|_TIF_USER_WORK_MASK|_TIF_PERSYSCALL_MASK)
--
dwmw2
^ permalink raw reply
* Re: GNU and Freescale MPC83xx / e300 core support?
From: Dan Malek @ 2006-03-07 12:33 UTC (permalink / raw)
To: Russell McGuire; +Cc: linuxppc-embedded
In-Reply-To: <000901c641ab$466428a0$6405a8c0@absolut>
On Mar 7, 2006, at 12:52 AM, Russell McGuire wrote:
> ..... The most obvious core difference is
> the Floating Point unit; the MPC8280, 603e or G2LE core had no floating
> point ability at all.
I just want to state for archive purposes this simply isn't true.
All of those processors had hardware FPUs. If you would take
a few seconds and read the product overviews for these parts,
you can make your own informed decision. The person you
are talking to doesn't seem to have all of the facts in order.
-- Dan
^ permalink raw reply
* signal/syscall/swapcontext fixes
From: Paul Mackerras @ 2006-03-07 12:32 UTC (permalink / raw)
To: linuxppc-dev; +Cc: dwmw2
Here is the current set of changes I have for fixing various problems
and potential problems I found in the syscall entry/exit code.
Briefly, the changes are:
* The TIF_SAVE_NVGPRS mechanism was only being used by swapcontext, so
I removed it and put swapcontext back the way it was in 2.6.15, with
an assembler stub to save the non-volatile GPRs before calling the C
code. The save_general_regs functions now WARN_ON(!FULL_REGS(regs)).
* 32-bit wasn't testing the _TIF_NOERROR bit in the syscall fast exit
path, so it was only doing anything with it once it saw some other
bit being set.
* 32-bit wasn't doing the call to ptrace_notify in the syscall exit
path when the _TIF_SINGLESTEP bit was set.
* _TIF_RESTOREALL was in both _TIF_USER_WORK_MASK and
_TIF_PERSYSCALL_MASK, which is odd since _TIF_RESTOREALL is only set
by system calls. I took it out of _TIF_USER_WORK_MASK.
* On 64-bit, _TIF_RESTOREALL wasn't causing the non-volatile registers
to be restored (unless perhaps a signal was delivered or the syscall
was traced or single-stepped). Thus the non-volatile registers
weren't restored on exit from a signal handler. We probably got
away with it mostly because signal handlers written in C wouldn't
alter the non-volatile registers.
* On 32-bit I simplified the code and made it more like 64-bit by
making the syscall exit path jump to ret_from_except to handle
preemption and signal delivery.
* 32-bit was calling do_signal unnecessarily when _TIF_RESTOREALL was
set - but I think because of that 32-bit was actually restoring the
non-volatile registers on exit from a signal handler.
* I changed the order of enabling interrupts and saving the
non-volatile registers before calling do_syscall_trace_leave; now we
enable interrupts first.
Any comments before I send this off to Linus to go in 2.6.16?
Paul.
diff --git a/arch/powerpc/kernel/asm-offsets.c b/arch/powerpc/kernel/asm-offsets.c
index 840aad4..c9a660e 100644
--- a/arch/powerpc/kernel/asm-offsets.c
+++ b/arch/powerpc/kernel/asm-offsets.c
@@ -92,7 +92,6 @@ int main(void)
DEFINE(TI_FLAGS, offsetof(struct thread_info, flags));
DEFINE(TI_PREEMPT, offsetof(struct thread_info, preempt_count));
- DEFINE(TI_SIGFRAME, offsetof(struct thread_info, nvgprs_frame));
DEFINE(TI_TASK, offsetof(struct thread_info, task));
#ifdef CONFIG_PPC32
DEFINE(TI_EXECDOMAIN, offsetof(struct thread_info, exec_domain));
diff --git a/arch/powerpc/kernel/entry_32.S b/arch/powerpc/kernel/entry_32.S
index f20a672..4827ca1 100644
--- a/arch/powerpc/kernel/entry_32.S
+++ b/arch/powerpc/kernel/entry_32.S
@@ -227,7 +227,7 @@ ret_from_syscall:
MTMSRD(r10)
lwz r9,TI_FLAGS(r12)
li r8,-_LAST_ERRNO
- andi. r0,r9,(_TIF_SYSCALL_T_OR_A|_TIF_SIGPENDING|_TIF_NEED_RESCHED|_TIF_RESTOREALL|_TIF_RESTORE_SIGMASK)
+ andi. r0,r9,(_TIF_SYSCALL_T_OR_A|_TIF_SINGLESTEP|_TIF_USER_WORK_MASK|_TIF_PERSYSCALL_MASK)
bne- syscall_exit_work
cmplw 0,r3,r8
blt+ syscall_exit_cont
@@ -287,8 +287,10 @@ syscall_dotrace:
syscall_exit_work:
andi. r0,r9,_TIF_RESTOREALL
- bne- 2f
- cmplw 0,r3,r8
+ beq+ 0f
+ REST_NVGPRS(r1)
+ b 2f
+0: cmplw 0,r3,r8
blt+ 1f
andi. r0,r9,_TIF_NOERROR
bne- 1f
@@ -302,9 +304,7 @@ syscall_exit_work:
2: andi. r0,r9,(_TIF_PERSYSCALL_MASK)
beq 4f
- /* Clear per-syscall TIF flags if any are set, but _leave_
- _TIF_SAVE_NVGPRS set in r9 since we haven't dealt with that
- yet. */
+ /* Clear per-syscall TIF flags if any are set. */
li r11,_TIF_PERSYSCALL_MASK
addi r12,r12,TI_FLAGS
@@ -318,8 +318,13 @@ syscall_exit_work:
subi r12,r12,TI_FLAGS
4: /* Anything which requires enabling interrupts? */
- andi. r0,r9,(_TIF_SYSCALL_T_OR_A|_TIF_SINGLESTEP|_TIF_SAVE_NVGPRS)
- beq 7f
+ andi. r0,r9,(_TIF_SYSCALL_T_OR_A|_TIF_SINGLESTEP)
+ beq ret_from_except
+
+ /* Re-enable interrupts */
+ ori r10,r10,MSR_EE
+ SYNC
+ MTMSRD(r10)
/* Save NVGPRS if they're not saved already */
lwz r4,_TRAP(r1)
@@ -328,71 +333,11 @@ syscall_exit_work:
SAVE_NVGPRS(r1)
li r4,0xc00
stw r4,_TRAP(r1)
-
- /* Re-enable interrupts */
-5: ori r10,r10,MSR_EE
- SYNC
- MTMSRD(r10)
-
- andi. r0,r9,_TIF_SAVE_NVGPRS
- bne save_user_nvgprs
-
-save_user_nvgprs_cont:
- andi. r0,r9,(_TIF_SYSCALL_T_OR_A|_TIF_SINGLESTEP)
- beq 7f
-
+5:
addi r3,r1,STACK_FRAME_OVERHEAD
bl do_syscall_trace_leave
- REST_NVGPRS(r1)
-
-6: lwz r3,GPR3(r1)
- LOAD_MSR_KERNEL(r10,MSR_KERNEL) /* doesn't include MSR_EE */
- SYNC
- MTMSRD(r10) /* disable interrupts again */
- rlwinm r12,r1,0,0,(31-THREAD_SHIFT) /* current_thread_info() */
- lwz r9,TI_FLAGS(r12)
-7:
- andi. r0,r9,_TIF_NEED_RESCHED
- bne 8f
- lwz r5,_MSR(r1)
- andi. r5,r5,MSR_PR
- beq ret_from_except
- andi. r0,r9,_TIF_SIGPENDING|_TIF_RESTORE_SIGMASK
- beq ret_from_except
- b do_user_signal
-8:
- ori r10,r10,MSR_EE
- SYNC
- MTMSRD(r10) /* re-enable interrupts */
- bl schedule
- b 6b
-
-save_user_nvgprs:
- lwz r8,TI_SIGFRAME(r12)
-
-.macro savewords start, end
- 1: stw \start,4*(\start)(r8)
- .section __ex_table,"a"
- .align 2
- .long 1b,save_user_nvgprs_fault
- .previous
- .if \end - \start
- savewords "(\start+1)",\end
- .endif
-.endm
- savewords 14,31
- b save_user_nvgprs_cont
-
-
-save_user_nvgprs_fault:
- li r3,11 /* SIGSEGV */
- lwz r4,TI_TASK(r12)
- bl force_sigsegv
+ b ret_from_except_full
- rlwinm r12,r1,0,0,(31-THREAD_SHIFT) /* current_thread_info() */
- lwz r9,TI_FLAGS(r12)
- b save_user_nvgprs_cont
-
#ifdef SHOW_SYSCALLS
do_show_syscall:
#ifdef SHOW_SYSCALLS_TASK
@@ -490,6 +435,14 @@ ppc_clone:
stw r0,_TRAP(r1) /* register set saved */
b sys_clone
+ .globl ppc_swapcontext
+ppc_swapcontext:
+ SAVE_NVGPRS(r1)
+ lwz r0,_TRAP(r1)
+ rlwinm r0,r0,0,0,30 /* clear LSB to indicate full */
+ stw r0,_TRAP(r1) /* register set saved */
+ b sys_swapcontext
+
/*
* Top-level page fault handling.
* This is in assembler because if do_page_fault tells us that
@@ -683,7 +636,7 @@ user_exc_return: /* r10 contains MSR_KE
/* Check current_thread_info()->flags */
rlwinm r9,r1,0,0,(31-THREAD_SHIFT)
lwz r9,TI_FLAGS(r9)
- andi. r0,r9,(_TIF_SIGPENDING|_TIF_NEED_RESCHED|_TIF_RESTOREALL|_TIF_RESTORE_SIGMASK)
+ andi. r0,r9,(_TIF_SIGPENDING|_TIF_RESTORE_SIGMASK|_TIF_NEED_RESCHED)
bne do_work
restore_user:
diff --git a/arch/powerpc/kernel/entry_64.S b/arch/powerpc/kernel/entry_64.S
index 388f861..24be0cf 100644
--- a/arch/powerpc/kernel/entry_64.S
+++ b/arch/powerpc/kernel/entry_64.S
@@ -160,7 +160,7 @@ syscall_exit:
mtmsrd r10,1
ld r9,TI_FLAGS(r12)
li r11,-_LAST_ERRNO
- andi. r0,r9,(_TIF_SYSCALL_T_OR_A|_TIF_SINGLESTEP|_TIF_SIGPENDING|_TIF_NEED_RESCHED|_TIF_RESTOREALL|_TIF_SAVE_NVGPRS|_TIF_NOERROR|_TIF_RESTORE_SIGMASK)
+ andi. r0,r9,(_TIF_SYSCALL_T_OR_A|_TIF_SINGLESTEP|_TIF_USER_WORK_MASK|_TIF_PERSYSCALL_MASK)
bne- syscall_exit_work
cmpld r3,r11
ld r5,_CCR(r1)
@@ -216,8 +216,10 @@ syscall_exit_work:
If TIF_NOERROR is set, just save r3 as it is. */
andi. r0,r9,_TIF_RESTOREALL
- bne- 2f
- cmpld r3,r11 /* r10 is -LAST_ERRNO */
+ beq+ 0f
+ REST_NVGPRS(r1)
+ b 2f
+0: cmpld r3,r11 /* r10 is -LAST_ERRNO */
blt+ 1f
andi. r0,r9,_TIF_NOERROR
bne- 1f
@@ -229,9 +231,7 @@ syscall_exit_work:
2: andi. r0,r9,(_TIF_PERSYSCALL_MASK)
beq 4f
- /* Clear per-syscall TIF flags if any are set, but _leave_
- _TIF_SAVE_NVGPRS set in r9 since we haven't dealt with that
- yet. */
+ /* Clear per-syscall TIF flags if any are set. */
li r11,_TIF_PERSYSCALL_MASK
addi r12,r12,TI_FLAGS
@@ -240,10 +240,9 @@ syscall_exit_work:
stdcx. r10,0,r12
bne- 3b
subi r12,r12,TI_FLAGS
-
-4: bl .save_nvgprs
- /* Anything else left to do? */
- andi. r0,r9,(_TIF_SYSCALL_T_OR_A|_TIF_SINGLESTEP|_TIF_SAVE_NVGPRS)
+
+4: /* Anything else left to do? */
+ andi. r0,r9,(_TIF_SYSCALL_T_OR_A|_TIF_SINGLESTEP)
beq .ret_from_except_lite
/* Re-enable interrupts */
@@ -251,26 +250,10 @@ syscall_exit_work:
ori r10,r10,MSR_EE
mtmsrd r10,1
- andi. r0,r9,_TIF_SAVE_NVGPRS
- bne save_user_nvgprs
-
- /* If tracing, re-enable interrupts and do it */
-save_user_nvgprs_cont:
- andi. r0,r9,(_TIF_SYSCALL_T_OR_A|_TIF_SINGLESTEP)
- beq 5f
-
+ bl .save_nvgprs
addi r3,r1,STACK_FRAME_OVERHEAD
bl .do_syscall_trace_leave
- REST_NVGPRS(r1)
- clrrdi r12,r1,THREAD_SHIFT
-
- /* Disable interrupts again and handle other work if any */
-5: mfmsr r10
- rldicl r10,r10,48,1
- rotldi r10,r10,16
- mtmsrd r10,1
-
- b .ret_from_except_lite
+ b .ret_from_except
/* Save non-volatile GPRs, if not already saved. */
_GLOBAL(save_nvgprs)
@@ -282,51 +265,6 @@ _GLOBAL(save_nvgprs)
std r0,_TRAP(r1)
blr
-
-save_user_nvgprs:
- ld r10,TI_SIGFRAME(r12)
- andi. r0,r9,_TIF_32BIT
- beq- save_user_nvgprs_64
-
- /* 32-bit save to userspace */
-
-.macro savewords start, end
- 1: stw \start,4*(\start)(r10)
- .section __ex_table,"a"
- .align 3
- .llong 1b,save_user_nvgprs_fault
- .previous
- .if \end - \start
- savewords "(\start+1)",\end
- .endif
-.endm
- savewords 14,31
- b save_user_nvgprs_cont
-
-save_user_nvgprs_64:
- /* 64-bit save to userspace */
-
-.macro savelongs start, end
- 1: std \start,8*(\start)(r10)
- .section __ex_table,"a"
- .align 3
- .llong 1b,save_user_nvgprs_fault
- .previous
- .if \end - \start
- savelongs "(\start+1)",\end
- .endif
-.endm
- savelongs 14,31
- b save_user_nvgprs_cont
-
-save_user_nvgprs_fault:
- li r3,11 /* SIGSEGV */
- ld r4,TI_TASK(r12)
- bl .force_sigsegv
-
- clrrdi r12,r1,THREAD_SHIFT
- ld r9,TI_FLAGS(r12)
- b save_user_nvgprs_cont
/*
* The sigsuspend and rt_sigsuspend system calls can call do_signal
@@ -352,6 +290,16 @@ _GLOBAL(ppc_clone)
bl .sys_clone
b syscall_exit
+_GLOBAL(ppc32_swapcontext)
+ bl .save_nvgprs
+ bl .compat_sys_swapcontext
+ b syscall_exit
+
+_GLOBAL(ppc64_swapcontext)
+ bl .save_nvgprs
+ bl .sys_swapcontext
+ b syscall_exit
+
_GLOBAL(ret_from_fork)
bl .schedule_tail
REST_NVGPRS(r1)
diff --git a/arch/powerpc/kernel/ptrace.c b/arch/powerpc/kernel/ptrace.c
index 400793c..bcb8357 100644
--- a/arch/powerpc/kernel/ptrace.c
+++ b/arch/powerpc/kernel/ptrace.c
@@ -561,10 +561,7 @@ void do_syscall_trace_leave(struct pt_re
regs->result);
if ((test_thread_flag(TIF_SYSCALL_TRACE)
-#ifdef CONFIG_PPC64
- || test_thread_flag(TIF_SINGLESTEP)
-#endif
- )
+ || test_thread_flag(TIF_SINGLESTEP))
&& (current->ptrace & PT_PTRACED))
do_syscall_trace();
}
diff --git a/arch/powerpc/kernel/signal_32.c b/arch/powerpc/kernel/signal_32.c
index bd837b5..d7a4e81 100644
--- a/arch/powerpc/kernel/signal_32.c
+++ b/arch/powerpc/kernel/signal_32.c
@@ -151,10 +151,7 @@ static inline int save_general_regs(stru
elf_greg_t64 *gregs = (elf_greg_t64 *)regs;
int i;
- if (!FULL_REGS(regs)) {
- set_thread_flag(TIF_SAVE_NVGPRS);
- current_thread_info()->nvgprs_frame = frame->mc_gregs;
- }
+ WARN_ON(!FULL_REGS(regs));
for (i = 0; i <= PT_RESULT; i ++) {
if (i == 14 && !FULL_REGS(regs))
@@ -215,15 +212,7 @@ static inline int get_old_sigaction(stru
static inline int save_general_regs(struct pt_regs *regs,
struct mcontext __user *frame)
{
- if (!FULL_REGS(regs)) {
- /* Zero out the unsaved GPRs to avoid information
- leak, and set TIF_SAVE_NVGPRS to ensure that the
- registers do actually get saved later. */
- memset(®s->gpr[14], 0, 18 * sizeof(unsigned long));
- current_thread_info()->nvgprs_frame = &frame->mc_gregs;
- set_thread_flag(TIF_SAVE_NVGPRS);
- }
-
+ WARN_ON(!FULL_REGS(regs));
return __copy_to_user(&frame->mc_gregs, regs, GP_REGS_SIZE);
}
@@ -826,8 +815,8 @@ static int do_setcontext(struct ucontext
}
long sys_swapcontext(struct ucontext __user *old_ctx,
- struct ucontext __user *new_ctx,
- int ctx_size, int r6, int r7, int r8, struct pt_regs *regs)
+ struct ucontext __user *new_ctx,
+ int ctx_size, int r6, int r7, int r8, struct pt_regs *regs)
{
unsigned char tmp;
diff --git a/arch/powerpc/kernel/signal_64.c b/arch/powerpc/kernel/signal_64.c
index 497a5d3..4324f8a 100644
--- a/arch/powerpc/kernel/signal_64.c
+++ b/arch/powerpc/kernel/signal_64.c
@@ -118,14 +118,7 @@ static long setup_sigcontext(struct sigc
err |= __put_user(0, &sc->v_regs);
#endif /* CONFIG_ALTIVEC */
err |= __put_user(&sc->gp_regs, &sc->regs);
- if (!FULL_REGS(regs)) {
- /* Zero out the unsaved GPRs to avoid information
- leak, and set TIF_SAVE_NVGPRS to ensure that the
- registers do actually get saved later. */
- memset(®s->gpr[14], 0, 18 * sizeof(unsigned long));
- set_thread_flag(TIF_SAVE_NVGPRS);
- current_thread_info()->nvgprs_frame = &sc->gp_regs;
- }
+ WARN_ON(!FULL_REGS(regs));
err |= __copy_to_user(&sc->gp_regs, regs, GP_REGS_SIZE);
err |= __copy_to_user(&sc->fp_regs, ¤t->thread.fpr, FP_REGS_SIZE);
err |= __put_user(signr, &sc->signal);
diff --git a/arch/powerpc/kernel/systbl.S b/arch/powerpc/kernel/systbl.S
index 8a9f994..1ad55f0 100644
--- a/arch/powerpc/kernel/systbl.S
+++ b/arch/powerpc/kernel/systbl.S
@@ -288,7 +288,7 @@ COMPAT_SYS(clock_settime)
COMPAT_SYS(clock_gettime)
COMPAT_SYS(clock_getres)
COMPAT_SYS(clock_nanosleep)
-COMPAT_SYS(swapcontext)
+SYSX(ppc64_swapcontext,ppc32_swapcontext,ppc_swapcontext)
COMPAT_SYS(tgkill)
COMPAT_SYS(utimes)
COMPAT_SYS(statfs64)
diff --git a/include/asm-powerpc/thread_info.h b/include/asm-powerpc/thread_info.h
index 237fc2b..ffc7462 100644
--- a/include/asm-powerpc/thread_info.h
+++ b/include/asm-powerpc/thread_info.h
@@ -37,7 +37,6 @@ struct thread_info {
int preempt_count; /* 0 => preemptable,
<0 => BUG */
struct restart_block restart_block;
- void __user *nvgprs_frame;
/* low level flags - has atomic operations done on it */
unsigned long flags ____cacheline_aligned_in_smp;
};
@@ -120,7 +119,6 @@ static inline struct thread_info *curren
#define TIF_MEMDIE 10
#define TIF_SECCOMP 11 /* secure computing */
#define TIF_RESTOREALL 12 /* Restore all regs (implies NOERROR) */
-#define TIF_SAVE_NVGPRS 13 /* Save r14-r31 in signal frame */
#define TIF_NOERROR 14 /* Force successful syscall return */
#define TIF_RESTORE_SIGMASK 15 /* Restore signal mask in do_signal */
@@ -137,15 +135,13 @@ static inline struct thread_info *curren
#define _TIF_SINGLESTEP (1<<TIF_SINGLESTEP)
#define _TIF_SECCOMP (1<<TIF_SECCOMP)
#define _TIF_RESTOREALL (1<<TIF_RESTOREALL)
-#define _TIF_SAVE_NVGPRS (1<<TIF_SAVE_NVGPRS)
#define _TIF_NOERROR (1<<TIF_NOERROR)
#define _TIF_RESTORE_SIGMASK (1<<TIF_RESTORE_SIGMASK)
#define _TIF_SYSCALL_T_OR_A (_TIF_SYSCALL_TRACE|_TIF_SYSCALL_AUDIT|_TIF_SECCOMP)
#define _TIF_USER_WORK_MASK (_TIF_NOTIFY_RESUME | _TIF_SIGPENDING | \
- _TIF_NEED_RESCHED | _TIF_RESTOREALL | \
- _TIF_RESTORE_SIGMASK)
-#define _TIF_PERSYSCALL_MASK (_TIF_RESTOREALL|_TIF_NOERROR|_TIF_SAVE_NVGPRS)
+ _TIF_NEED_RESCHED | _TIF_RESTORE_SIGMASK)
+#define _TIF_PERSYSCALL_MASK (_TIF_RESTOREALL|_TIF_NOERROR)
#endif /* __KERNEL__ */
^ permalink raw reply related
* AW: help reqd
From: Achim Machura @ 2006-03-07 11:36 UTC (permalink / raw)
To: prabha.j; +Cc: Linuxppc-Embedded (E-Mail)
In-Reply-To: <OF46AD2988.50343CDA-ON6525712A.003D6847-6525712A.003DEE14@tcs.com>
Hello,
> insmod: unresolved symbol copy_to_user
> insmod: unresolved symbol down
> insmod: unresolved symbol up
> insmod: unresolved symbol copy_from_user
you have to include <asm/uacces.h>
See the online book linux device driver form Alessandro Rubini
aze
^ 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