* Re: GNU and Freescale MPC83xx / e300 core support?
From: David Hawkins @ 2006-03-07 2:26 UTC (permalink / raw)
To: Russell McGuire; +Cc: linuxppc-embedded
In-Reply-To: <000301c6418a$86b32ee0$6405a8c0@absolut>
Russell McGuire wrote:
> I was recently involved in a meeting with a Freescale FAE, which informed us
> that the current revisions of the GNU C/C++ compilers do not yet possess any
> optimizations for the MPC83xx cores, more precisely no optimizations for the
> e300 cores inside the MPC83xx line up.
>
> They did say it was 100% backwards compatible with the existing 603e / 6xx
> core support, so all the code should work just fine.
>
> I was curious if anyone out there was aware of any efforts to produce /
> patch any of the GNU compilers to have optimizations for these newer
> MPC83xx's with the e300 cores?
>
Hi Russ,
Out of interest, what are the main differences that optimization
would help with?
I'm going to take a look at the 8349E, but I'm waiting on the
Freescale MDS board.
I haven't read the user manual in great detail, other than to
check out the potential bus performance, but I thought
the main change in the G2 vs e300 core was the cache size.
Did they add new instructions, or change the number-of-cycles
required for existing instructions?
The Freescale document:
Freescale PowerPC™ Architecture Primer, POWRPCARCPRMRM,
Rev. 0.1, 6/2005
Has the following on page 12 of the PDF:
e300 Cores and Platform
The ongoing presence of the e300 testifies to the longevity
of both the PowerPC architecture and the microarchitecture.
The e300 was introduced in 1994 as the MPC603, running at
100 MHz, and continues to be proliferated more than a decade
later reaching speeds exceeding 600 MHz. The e300 PowerPC
core and platform address the low- to mid-range performance
needs of the market. The e300 core is an enhanced version
of the popular PowerPC 603e core used in previous-generation
PowerQUICC II devices that scale from 266 to 667 MHz in
130 nm process technology. Enhancements include twice as
much L1 cache as the 603e (32-Kbyte data and instruction
caches) with integrated parity checking and other
performance-oriented features. The e300 core is fully
software-compatible with existing 603e core-based products
and provides the processing foundation for the company's new
MPC8349E PowerQUICC II™ Pro communications processor family.
So I guess the question is what are the
'other performance-oriented features'
this statement is referring to?
The e300 core reference manual comments:
The e300c1core integrates five execution units: an integer
unit (IU), a floating-point unit (FPU), a branch processing
unit (BPU), a load/store unit (LSU), and a system register
unit (SRU). The ability to execute five instructions in
parallel and the use of simple instructions with rapid
execution times yield high efficiency and throughput
for e300-core-based systems. Most integer instructions
execute in one clock cycle. On the e300c1 core, the FPU is
pipelined so a single-precision multiply-add instruction
can be issued and completed every clock cycle.
So I guess an important optimization would be to keep each
execution unit busy. I haven't looked at an older 603e manual,
do they have fewer units?
Cheers
Dave
^ permalink raw reply
* Re: Calling PCI Autoconfig again
From: David Hawkins @ 2006-03-07 4:32 UTC (permalink / raw)
To: Wyse, Chris; +Cc: linuxppc-embedded
In-Reply-To: <927594BA71733F4BAA815162B79A3F513B27FD@ala-mail04.corp.ad.wrs.com>
Wyse, Chris wrote:
> Hi,
>
> I'm working on a board (PPC440GX CPU) that has an FPGA on it. The FPGA
> software has a PCI interface. If I load the FPGA, then boot the 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 run autoconfig
> again to detect the device. What's the best way to do this?
>
> Please send responses directly to me (in addition to the list), since 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: GNU and Freescale MPC83xx / e300 core support?
From: Russell McGuire @ 2006-03-07 5:52 UTC (permalink / raw)
To: 'David Hawkins'; +Cc: linuxppc-embedded
In-Reply-To: <440CEF66.4090109@ovro.caltech.edu>
All,
Our meetings with Freescale were aimed specifically at the differences
between the MPC8280 and the MPC8360E. The most obvious core difference is
the Floating Point unit; the MPC8280, 603e or G2LE core had no floating
point ability at all.
I am not sure if its core support or not, but I know the MPC83xx line up has
drastically altered the bus architecture inside the chips. There are more
DMA engines now, and things like the DDR SDRAM bus and 60x / local Bus are
separated to run in parallel. Previously, in the 8260/8280 they were
mutually exclusive for bus cycles. Internally the shared bus now operates at
the DDR frequency, shortly to be DDR2 frequency for later masks. We should
see a very large performance improvement for memory intensive applications.
Same applies to the PCI 2.2 bus; it was also given separate pins and DMA
engines. According to the Freescale FAE the chip can handle simultaneous bus
cycles on all three busses at once. I do not have enough internal knowledge
on the compilers to know if this is a specific optimization, but it would
definitely hinder performance if we couldn't take advantage of it.
Freescale claims their newest revision of Metrowerks is optimized for these
newer cores, I guess one could get compile with a version of that and
disassemble it.
Aside:
I know the CPM of the older 82xx lineup has been removed, and so has the
optimization for its access to the 32 bit local bus. The QUICC engines have
replaced it and now have equal priority to all busses, though this probably
has little to do with the compiler.
Of random, if anyone is using the 'E' revisions of the 83xx lineup,
Freescale is claiming that the encryption engine is almost 10x faster than
their previous lineup of sister encryption chips that would normally partner
with the MPC8260 and MPC8280 chips.
I have another meeting tomorrow with Freescale, I can get more specifics.
-Russ
-----Original Message-----
From: David Hawkins [mailto:dwh@ovro.caltech.edu]
Sent: Monday, March 06, 2006 6:27 PM
To: Russell McGuire
Cc: linuxppc-embedded@ozlabs.org
Subject: Re: GNU and Freescale MPC83xx / e300 core support?
Russell McGuire wrote:
> I was recently involved in a meeting with a Freescale FAE, which informed
us
> that the current revisions of the GNU C/C++ compilers do not yet possess
any
> optimizations for the MPC83xx cores, more precisely no optimizations for
the
> e300 cores inside the MPC83xx line up.
>
> They did say it was 100% backwards compatible with the existing 603e / 6xx
> core support, so all the code should work just fine.
>
> I was curious if anyone out there was aware of any efforts to produce /
> patch any of the GNU compilers to have optimizations for these newer
> MPC83xx's with the e300 cores?
>
Hi Russ,
Out of interest, what are the main differences that optimization
would help with?
I'm going to take a look at the 8349E, but I'm waiting on the
Freescale MDS board.
I haven't read the user manual in great detail, other than to
check out the potential bus performance, but I thought
the main change in the G2 vs e300 core was the cache size.
Did they add new instructions, or change the number-of-cycles
required for existing instructions?
The Freescale document:
Freescale PowerPCT Architecture Primer, POWRPCARCPRMRM,
Rev. 0.1, 6/2005
Has the following on page 12 of the PDF:
e300 Cores and Platform
The ongoing presence of the e300 testifies to the longevity
of both the PowerPC architecture and the microarchitecture.
The e300 was introduced in 1994 as the MPC603, running at
100 MHz, and continues to be proliferated more than a decade
later reaching speeds exceeding 600 MHz. The e300 PowerPC
core and platform address the low- to mid-range performance
needs of the market. The e300 core is an enhanced version
of the popular PowerPC 603e core used in previous-generation
PowerQUICC II devices that scale from 266 to 667 MHz in
130 nm process technology. Enhancements include twice as
much L1 cache as the 603e (32-Kbyte data and instruction
caches) with integrated parity checking and other
performance-oriented features. The e300 core is fully
software-compatible with existing 603e core-based products
and provides the processing foundation for the company's new
MPC8349E PowerQUICC IIT Pro communications processor family.
So I guess the question is what are the
'other performance-oriented features'
this statement is referring to?
The e300 core reference manual comments:
The e300c1core integrates five execution units: an integer
unit (IU), a floating-point unit (FPU), a branch processing
unit (BPU), a load/store unit (LSU), and a system register
unit (SRU). The ability to execute five instructions in
parallel and the use of simple instructions with rapid
execution times yield high efficiency and throughput
for e300-core-based systems. Most integer instructions
execute in one clock cycle. On the e300c1 core, the FPU is
pipelined so a single-precision multiply-add instruction
can be issued and completed every clock cycle.
So I guess an important optimization would be to keep each
execution unit busy. I haven't looked at an older 603e manual,
do they have fewer units?
Cheers
Dave
^ permalink raw reply
* Re: GNU and Freescale MPC83xx / e300 core support?
From: Kumar Gala @ 2006-03-07 6:07 UTC (permalink / raw)
To: Russell McGuire; +Cc: linuxppc-embedded
In-Reply-To: <000901c641ab$466428a0$6405a8c0@absolut>
On Mar 6, 2006, at 11:52 PM, Russell McGuire wrote:
> All,
>
> Our meetings with Freescale were aimed specifically at the differences
> between the MPC8280 and the MPC8360E. The most obvious core
> difference is
> the Floating Point unit; the MPC8280, 603e or G2LE core had no
> floating
> point ability at all.
I'm not sure what the FAE is telling you but its wrong. All current
PQ2 processors have FP in the 603 core.
Will e300 had an instruction or two, they are very minor things with
respect to the compiler. Its possible that the scheduler could be
tuned for e300 above and beyond what exists for the 603.
> I am not sure if its core support or not, but I know the MPC83xx
> line up has
> drastically altered the bus architecture inside the chips. There
> are more
> DMA engines now, and things like the DDR SDRAM bus and 60x / local
> Bus are
> separated to run in parallel. Previously, in the 8260/8280 they were
> mutually exclusive for bus cycles. Internally the shared bus now
> operates at
> the DDR frequency, shortly to be DDR2 frequency for later masks. We
> should
> see a very large performance improvement for memory intensive
> applications.
> Same applies to the PCI 2.2 bus; it was also given separate pins
> and DMA
> engines. According to the Freescale FAE the chip can handle
> simultaneous bus
> cycles on all three busses at once. I do not have enough internal
> knowledge
> on the compilers to know if this is a specific optimization, but it
> would
> definitely hinder performance if we couldn't take advantage of it.
>
> Freescale claims their newest revision of Metrowerks is optimized
> for these
> newer cores, I guess one could get compile with a version of that and
> disassemble it.
I truly doubt the Metrowerks compiler takes into account anything
beyond the core differences. As I said earlier, the scheduler in GCC
could probably be tuned for e300. Beyond that there is little to be
done that is specific for the e300.
- kumar
^ permalink raw reply
* help reqd
From: prabha.j @ 2006-03-07 11:16 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 1106 bytes --]
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: 1694 bytes --]
^ permalink raw reply
* 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
* 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
* 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
* 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
* 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: 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
* 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 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: 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: 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: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
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