* 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: 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: 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: 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: 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: 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: 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 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: 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: 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: 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: 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: 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: 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: 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
* Hints on hard hang
From: Bizhan Gholikhamseh (bgholikh) @ 2006-03-07 21:19 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 394 bytes --]
Hi All,
Our custom board based on 8541 processor running Linux 2.6.11 gets hard
hang during run time. We can't soft reset (SRESET, Pin#AF20) and get a
machine check interrupt when the hang happens, and JTAG can not
communicate with the processor. We do not know how to go to debug this
issue. If you have any idea or hints, we greatly appreciate.
Many thanks in advance,
Bizhan
[-- Attachment #2: Type: text/html, Size: 1275 bytes --]
^ permalink raw reply
* 440gx dma transfer with no data change at dest
From: Kevin Kleinosowski @ 2006-03-07 21:16 UTC (permalink / raw)
To: linuxppc-embedded
I am running a simple test with a software initiated DMA transfer from one
bigphysarea allocated buffer to another bigphysarea allocated buffer.
The destination buffer shows no data changes once the transfer is done.
However, I perform the same simple test using __get_dma_pages() rather
then the bigphysarea_alloc_pages() and the destination does get the
data transfer.
Is there a reason this should fail for bigphysarea? I understand the low
memory addresses needed for the DMA controller on some platforms, but I
didnt think that limitation existed on the PPC. Besides that, the
bigphysarea returns low memory address anyway. Anyone have an idea why?
An old archive email had someone with a similar problem, but there were no
follow-ups to the message.
I have linux 2.4.27-pre3 patched, ppc-linux-gcc (GCC) 3.3.3 (DENX ELDK
3.1.1 3.3.3-9), U-Boot 1.1.2, and GMS 440gx board.
thanks,
Kevin
^ permalink raw reply
* double fec on adder875
From: Antonio Di Bacco @ 2006-03-07 22:59 UTC (permalink / raw)
To: linuxppc-embedded
I found a patch to "fec.c" in 2.4 on http://patchwork.ozlabs.org/linuxppc/ to
make work both the fecs on mpc875.
Anyone used it? The patch is from Jan Damborsky.
The patch is in state "REJECTED"!!
What is http://patchwork.ozlabs.org/linuxppc/? Something you can post patches
that will be part of the official kernel?
Bye,
Antonio.
^ permalink raw reply
* Re: signal/syscall/swapcontext fixes
From: David Woodhouse @ 2006-03-07 23:36 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <17421.62535.805543.661898@cargo.ozlabs.ibm.com>
On Wed, 2006-03-08 at 07:59 +1100, Paul Mackerras wrote:
> 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. :)
Oh yeah -- I remember that now :)
> > 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?
It's hardly a showstopper -- I suspect we can happily leave it for now.
Adding the stops back where they were isn't perfect, and I thought I had
a better plan when I removed them. Buggered if I can remember it now
though.
> > 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.
Yeah, I suppose you're right.
--
dwmw2
^ permalink raw reply
* please pull powerpc-merge.git
From: Paul Mackerras @ 2006-03-08 2:32 UTC (permalink / raw)
To: torvalds; +Cc: linuxppc-dev
Linus,
Please do a pull from
git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc-merge.git
There is just one new commit - the one from me fixing some problems in
the syscall entry/exit path. There are 8 commits still there from the
last pull request.
Thanks,
Paul.
Benjamin Herrenschmidt:
powerpc: Fix old g5 issues with windfarm
powerpc: Fix windfarm_pm112 not starting all control loops
powerpc: Expose SMT and L1 icache snoop userland features
powerpc: incorrect rmo_top handling in prom_init
David Gibson:
powerpc: Fix incorrect pud_ERROR() message
Paul Mackerras:
powerpc: Fix might-sleep warning in program check exception handler
powerpc: Turn off verbose debug output in powermac platform functions
powerpc32: Fix timebase synchronization on 32-bit powermacs
powerpc: Fix various syscall/signal/swapcontext bugs
arch/powerpc/kernel/asm-offsets.c | 1
arch/powerpc/kernel/cputable.c | 9 ++
arch/powerpc/kernel/entry_32.S | 95 +++++++-------------------
arch/powerpc/kernel/entry_64.S | 94 ++++++--------------------
arch/powerpc/kernel/prom_init.c | 2 -
arch/powerpc/kernel/ptrace.c | 5 -
arch/powerpc/kernel/signal_32.c | 19 +----
arch/powerpc/kernel/signal_64.c | 9 --
arch/powerpc/kernel/systbl.S | 2 -
arch/powerpc/kernel/traps.c | 2 +
arch/powerpc/platforms/powermac/pfunc_base.c | 5 +
arch/powerpc/platforms/powermac/pfunc_core.c | 6 ++
arch/powerpc/platforms/powermac/smp.c | 2 -
arch/ppc/kernel/asm-offsets.c | 1
arch/ppc/kernel/entry.S | 95 +++++++-------------------
drivers/macintosh/windfarm_core.c | 7 ++
drivers/macintosh/windfarm_cpufreq_clamp.c | 8 ++
drivers/macintosh/windfarm_lm75_sensor.c | 32 ++++++---
drivers/macintosh/windfarm_max6690_sensor.c | 25 +++++--
drivers/macintosh/windfarm_pm112.c | 8 +-
include/asm-powerpc/cputable.h | 2 +
include/asm-powerpc/pgtable-4k.h | 2 -
include/asm-powerpc/thread_info.h | 8 +-
23 files changed, 163 insertions(+), 276 deletions(-)
^ permalink raw reply
* Re: please pull powerpc-merge.git
From: Olaf Hering @ 2006-03-08 8:08 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, torvalds
In-Reply-To: <17422.16982.705624.256207@cargo.ozlabs.ibm.com>
On Wed, Mar 08, Paul Mackeras wrote:
> powerpc: incorrect rmo_top handling in prom_init
I would leave this one out. It gives the false impression that ibook1
works ok, while later it will likely eat your filesystem. Its not a
regression in that sense because 2.6.15 was also broken and noone
complained.
^ permalink raw reply
* Re: How to quickly write cleanmarkers to jffs2 partitions?
From: David Jander @ 2006-03-08 8:38 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <1141647684.23522.7.camel@linpc041.aimsys.nl>
On Monday 06 March 2006 13:21, Jaap-Jan Boor wrote:
> On Fri, 2006-03-03 at 10:08 +0100, Mathieu Deschamps wrote:
> > Hi,
> >
> > "When preparing a flash partition for JFFS2, it is recommended to put
> > cleanmarkers to the erased blocks.
> > This might be done my means of "-j" option of the "flash_eraseall" MTD
> > utility. Otherwise, JFFS2 will re-erase the blocks
> > which contain all 0xFF and have no cleanmarker. This is an unneeded
> > wasting of time."
> >
> > Source : http://www.linux-mtd.infradead.org/faq/jffs2.html
> >
> > does this may be relevant ?
>
> This is correct, however flash_eraseall does also (as it's
> name suggests, erase all flash blocks, which takes
> some time on NOR flash. If you 'know' the flash is erased,
> it's not needed.
> I used flash_eraseall to write the cleanmarkers, but without
> erasing blocks (and called that utility cleanmark)
Thanks to all for the suggestions.
Is "cleanmark" an open-source tool? Would you share it?
Greetings,
--
David Jander
^ permalink raw reply
* bdi2000 config file
From: Mustafa Çayır @ 2006-03-08 10:09 UTC (permalink / raw)
To: linuxppc-embedded
Hi,
Are thare any guide about generating bdi2000 config file ?
I'm working on board MVME6100. are there bdi2000 config file of this =
board? Or, anyone has a bdi2000 config file of a board that has marvell =
64360 bridge?
thanks .
^ permalink raw reply
* Re: linux DMA capabilities in MV64460
From: Phil Nitschke @ 2006-03-08 14:02 UTC (permalink / raw)
To: linuxppc-embedded; +Cc: Brian Waite
In-Reply-To: <200603060821.29220.brian@waitefamily.us>
>>>>> "BW" == Brian Waite <brian@waitefamily.us> writes:
>> I'm now looking seriously (and reluctantly!) at writing a DMA
>> Controller Driver to supplement these functions, and I've started
>> the process of getting an NDA from Marvell, so I can get their
>> User Manual (and errata!).
BW> You won't get very far without the user manual, then I think you
BW> will find it pretty easy to write the driver with the frameworks
BW> already in the kernel.
>> Can someone point me in the right direction to get me started? I
>> need to come up the learning curve to find out where to start.
>>
>> How is a DMA controlled (from a device driver writer's
>> perspective) when a third-party (i.e. in the bridge) DMA
>> controller needs to do the work to get the data from a PCI Target
>> into main memory?
>>
>> What kernel API should be provided by the DMA Controller Driver?
BW> My first guess would be to follow something like
BW> Documentation/DMA-API.txt and Documentation/DMA-mapping.txt
I can't see how trying to match those DMA functions would work.
The dma_map_xxx() functions and friends appear to be invoked from
driver interrupt handlers, which are either responding to an interrupt
from a PCI Target which wants to commence a bus-mastered DMA to/from
main memory, or responding to a second interrupt to say the interrupt
is complete.
In my case, my driver receives one interrupt from a PCI Target which
cannot perform a DMA, and I presumably have to use an alternative API
(i.e. my "new" set of ("DMA Controller") driver functions) to get the
platform DMA controller to fetch the data and wake (interrupt) me once
complete. Right?
>> Any documentation, examples, similar device drivers, etc, would
>> be appreciated. TIA,
BW> You could look to followup that by groking
BW> arch/ppc/kernel/dma-mapping.c
OK.
BW> Finally, arch/ppc/syslib ppc4xx_dma.c seems to show an example
BW> of a low level driver.
OK, so suppose I write a bunch of functions, like this:
mv64x60_disable_dma();
mv64x60_disable_dma_interrupt();
mv64x60_enable_dma();
mv64x60_enable_dma_interrupt();
mv64x60_get_dma_status();
mv64x60_init_dma_channel();
... etc,
then how do these get called; directly from my other driver?
(I could not see any place that the ppc4xx_ dma functions were being
called, i.e. they don't seem to dovetail into some higher level kernel
API...?)
BW> I didn't notice any platform dma controllers like MAG
BW> reccommended, but that should be a better way to go.
Perhaps Mark was talking about ppc4xx_dma.c and ppc4xx_sgdma.c ?
Sorry if I'm too slow on the uptake. Thanks for your input,
--
Phil
^ permalink raw reply
* Stable Linux kernel 2.6 for MPC8XX
From: Laurent Lagrange @ 2006-03-08 14:32 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <000201c63c44$14a9c1b0$5201a8c0@GEG2400>
Hello,
I would want to use a linux kernel 2.6 on a custom MPC8xx board.
Which stable kernel release must or can I use ?
Thanks
Laurent
^ 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