LinuxPPC-Dev Archive on lore.kernel.org
 help / color / mirror / Atom feed
* Re: "Now booting the kernel"
From: Nathael PAJANI @ 2005-11-10 10:40 UTC (permalink / raw)
  To: linuxppc-embedded

(Sorry, I first replyed with the wrong mail address)

 >Linux/PPC load: console=ttyS0,9600 root=/dev/xsysace/disc0/part2 rw
 >Uncompressing Linux...done.
 >Now booting the kernel

Hi!

At this state the bootloader stops executing and the Linux Kernel 
starts. The problem is that the Linux kernel does not know yet how to 
use the serial.

You won't have any message before it is set up (in early-console if my 
memory is allright)

So what you can do to check what's going on, is put "breakpoints" in the 
boot sequence. This means in the file arch/ppc/kernel/head*.S used for 
your board you should try to comment the line with the "tlbwe" 
instruction in the section "/* 2. Invalidate all entries except the 
entry we're executing in */"
This will allow you to keep access to your board registers.

Then you go step by step, putting some code which will reboot the board 
when executed, so you know you're going up to that point, and then move 
the "breakpoint" further.

This code does the reboot (for the booke I can reboot the board by 
writting '4' at address 0xfa001001):

ASM:
   lis r4,0xfa00
   li  r5,4
   stb r5,0x1001(r4)
   msync

C:
*((volatile unsigned char*)0xfa001001 = 4;


This way, instead of hanging up, the board reboots and you know where 
you are.

If you're going up to this:
         bl      machine_init    /* arch/ppc/kernel/setup.c */
         bl      MMU_init    /* arch/ppc/mm/init.c */
It's quite good, these are C functions, but they are processor specific, 
once again, check that the ones used (compiled) are those you need.

And next you've got the "start_kernel" call, which leads you to C code 
definitely. It's in init/main.c.


I hope I did not tell anything wrong, and that this will help.

Have fun.
Nathael.

^ permalink raw reply
* Re: [PATCH] ppc32 8xx: MPC8xx PCMCIA update
From: Dominik Brodowski @ 2005-11-10 10:03 UTC (permalink / raw)
  To: Paul Mackerras; +Cc: linux-ppc-embedded
In-Reply-To: <17262.42993.975296.653728@cargo.ozlabs.ibm.com>

Hi,

On Mon, Nov 07, 2005 at 12:03:45PM +1100, Paul Mackerras wrote:
> Marcelo Tosatti writes:
> 
> > The following patch updates the MPC8xx PCMCIA driver:
> 
> This and the following patch look OK as far as I can tell - Dominik,
> will you take care of sending them to Linus?

Yes, will do.

Thanks,
	Dominik

^ permalink raw reply
* floating point  + kernel (PPC)
From: srideep.devireddy @ 2005-11-10 12:37 UTC (permalink / raw)
  To: linuxppc-embedded

[-- Attachment #1: Type: text/plain, Size: 1214 bytes --]


Thanks for your help friends ...



     I am able to bring my kernel up ...... right now I have a problem
after some time at the console .... I get floating point used in kernel
(task=C0188480,pc=1100)



10.0.0.2 login: root

Last login: Tnhu Jan  1 00:00sole

Linux 10.0.0.2 2.4.22 #1 Tue Nov 8 12:03:26 UTC 2005 ppc unknown




MontaVista(R) Linux(R) Professional Edition 3.1




root@10.0.0.2:~# <mailto:root@10.0.0.2:~> 



root@10.0.0.2:/home# cd ..

root@10.0.0.2:/# ls

bin  boot  dev  etc  home  lib  mnt  opt  proc  root  sbin  tmp  usr
var

root@10.0.0.2:/# floating point used in kernel (task=c0188480, pc=1100)





What does this mean ...? This makes the console hang .....Can any 1 help
me on in this?



Best Regards

srideep






Confidentiality Notice

The information contained in this electronic message and any attachments to this message are intended
for the exclusive use of the addressee(s) and may contain confidential or privileged information. If
you are not the intended recipient, please notify the sender at Wipro or Mailadmin@wipro.com immediately
and destroy all copies of this message and any attachments.

[-- Attachment #2: Type: text/html, Size: 7550 bytes --]

^ permalink raw reply
* SCC QMC driver for 8247
From: Robin Mathew @ 2005-11-10 14:48 UTC (permalink / raw)
  To: Linuxppc-embedded; +Cc: Nicholas Basker

Hello:

We are working on implementing driver for SCC operating in QMC mode that 
supports multiple HDLC channels. The details of the system we are using 
are the following.

CPU Version = 8247 based on 82xx family of processor(PVR 80822014)
The Linux OS Version = DENKS Linux version 2.4.20.
The Peripherals used are = FCC1 in 10/100 ethernet
                                            FCC2 in 10/100 ethernet
                                            SCC1 currently not used, but 
proposed to be used in HDLC mode.
                                            SCC3 is not used.
                                            SCC4 operating in QMC mode 
with super -channel capability. Trying to operate 192kbps HDLC channel 
(using 3x64kbps QMC channels).
                                            SMC2 in UART mode (as a 
simple debug port without any modem signals).
                                            SPI interface currently not 
used but shall be used in future.
                                            I2C is being used.

01. Can the channel specific parameters of the SCC4 in QMC mode be 
relocated from DPRAM base address?? There is no mention in the 
8272RM.pdf about configuring the base address of channel specific 
parameters. From the QMC memory structure diagram, it looks like the 
channel specific parameters will be taken from the the DPRAM base 
address. Can you please confirm it?

02. We have changed the function m8260_cpm_dpalloc() used for DPRAM 
allocation in the linux source code. It was allocating memory from 
128Byte location to 8KByte location in DPRAM. But since QMC requires the 
lower 4KByte for channel specific parameters, we changed the function to 
allocate DPRAM from 4KByte location. Will this change lead to any 
problem for proper linux operation?

03. We are encountering a strange problem with scc4 parameter RAM. When 
the driver is coming up, its trying to initialize the SCC4 parameter RAM 
for QMC. In the location (immr + 0x8318), we are writing the value 
0x8320 but the value magically changes to 0x8300. We tried to write to 
the location using BDI and again the problem is seen. Is this a known 
problem with the processor?? This problem doesnot appear everytime. Is 
there any known cause for this problem?

Regards,
Robin

^ permalink raw reply
* Re: PowerPC reservations
From: Michael R. Zucca @ 2005-11-10 15:20 UTC (permalink / raw)
  To: Kalle Pokki; +Cc: linuxppc-embedded
In-Reply-To: <437302CE.8070309@iki.fi>

Kalle Pokki wrote:

> Am I just not getting how this is really supposed to work? Are there 
> still some other constructs in use to prevent this, e.g. extra stwcx. 
> instructions when changing the thread of execution?

Yes. When a context switch occurs, there's a stcwx. to clear any 
reservations from the previous thread. When you enter another thread 
from a context switch, you enter it with no reservations pending.

So you might have something that looks like this:

thread 1 -> lwarx w/ successful reservation
context switch -> stwcx.. to garbage location to clear any reservations
thread 2 -> stwcx. fails since there's no reservation pending
context switch -> stwcx. to garbage location to clear any reservations
thread 1 -> stwcx. fails since there's no reservation pending
thread 1 -> loops to try lwarx again

So the context switcher protects a reservation from "leaking" into 
another thread. In that sense, you can act as though lwarx/stwcx. pairs 
belong to a single thread.

The other important thing to remember is that there can only be one 
outstanding reservation. Thus, lwarx and stcwx. instructions have to be 
"paired" or you're going to get unexpected results.

^ permalink raw reply
* [PATCH] ppc32: fix PQ2 PCI DMA interrupt handling
From: Kumar Gala @ 2005-11-10 16:34 UTC (permalink / raw)
  To: Paul Mackerras; +Cc: linuxppc-dev, linuxppc-embedded

The bit position in the status register corresponding to the
PCI DMA interrupt was incorrect.  Additionally, we did not
have a define for the PCI DMA interrupt.

Signed-off-by: Kumar Gala <galak@kernel.crashing.org>

---
commit 6a9fa9805be85c33a177061d6bf4f4c2a95c9c7e
tree 2a72692b7373d2f4d328aee3652ece9d9ff7e750
parent b23f8a20b85440d4bebf1a2ddea5830ca85ff655
author Kumar Gala <galak@kernel.crashing.org> Thu, 10 Nov 2005 10:35:15 -0600
committer Kumar Gala <galak@kernel.crashing.org> Thu, 10 Nov 2005 10:35:15 -0600

 arch/ppc/syslib/cpm2_pic.c |    2 +-
 include/asm-powerpc/irq.h  |    1 +
 2 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/arch/ppc/syslib/cpm2_pic.c b/arch/ppc/syslib/cpm2_pic.c
index c867be6..29d95d4 100644
--- a/arch/ppc/syslib/cpm2_pic.c
+++ b/arch/ppc/syslib/cpm2_pic.c
@@ -37,7 +37,7 @@ static	u_char	irq_to_siureg[] = {
 static	u_char	irq_to_siubit[] = {
 	 0, 15, 14, 13, 12, 11, 10,  9,
 	 8,  7,  6,  5,  4,  3,  2,  1,
-	 2,  1, 15, 14, 13, 12, 11, 10,
+	 2,  1,  0, 14, 13, 12, 11, 10,
 	 9,  8,  7,  6,  5,  4,  3,  0,
 	31, 30, 29, 28, 27, 26, 25, 24,
 	23, 22, 21, 20, 19, 18, 17, 16,
diff --git a/include/asm-powerpc/irq.h b/include/asm-powerpc/irq.h
index b3935ea..921bfa9 100644
--- a/include/asm-powerpc/irq.h
+++ b/include/asm-powerpc/irq.h
@@ -389,6 +389,7 @@ extern u64 ppc64_interrupt_controller;
 #define	SIU_INT_TIMER4		((uint)0x0f + CPM_IRQ_OFFSET)
 #define	SIU_INT_TMCNT		((uint)0x10 + CPM_IRQ_OFFSET)
 #define	SIU_INT_PIT		((uint)0x11 + CPM_IRQ_OFFSET)
+#define	SIU_INT_PCI		((uint)0x12 + CPM_IRQ_OFFSET)
 #define	SIU_INT_IRQ1		((uint)0x13 + CPM_IRQ_OFFSET)
 #define	SIU_INT_IRQ2		((uint)0x14 + CPM_IRQ_OFFSET)
 #define	SIU_INT_IRQ3		((uint)0x15 + CPM_IRQ_OFFSET)

^ permalink raw reply related
* Re: [PATCH] ppc: add support for new powerbooks
From: Olof Johansson @ 2005-11-10 16:44 UTC (permalink / raw)
  To: Andrew Morton; +Cc: linuxppc-dev
In-Reply-To: <20051109213837.47c8dce7.akpm@osdl.org>

On Wed, Nov 09, 2005 at 09:38:37PM -0800, Andrew Morton wrote:
> Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> >
> > Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> 
> I don't think I'm adding much value handling ppc/ppc64 patches, really. 
> I'd prefer to get out of that business.

Main benefit for me, as a patch submitter, is that you consistently,
always, ACK when you pick up or drop a patch. In other words, I don't
have to go polling a tree to see if it made it in or not.

> It would be better to have an arch maintainer who runs a git tree, same as
> ia64, arm, etc.
> 
> And, given the amount of shared infrastructure, I suspect it would have to
> be a single git tree for both architectures.
> 
> I'd still sweep up random ppc patches, but those will go into mainline via the
> originator->mm->git-powerpc->linus route.
> 
> Possible?

I'm fine with all that; to be honest I haven't been certain where the
smaller ppc/ppc64 patches should go during this whole merge business (or
after, for that matter).

If Paulus wants to start an arch tree, that's fine with me. I do share
Ben's opinion about less review though, I guess we'll just have to deal
with that.

Also, Paul, I kindly request some sort of ACK mechanism similar to
Andrew's when patches are picked up. :-)


Thanks,

-Olof

^ permalink raw reply
* Re: [PATCH] ppc: add support for new powerbooks
From: Kumar Gala @ 2005-11-10 17:12 UTC (permalink / raw)
  To: Olof Johansson; +Cc: Andrew Morton, linuxppc-dev
In-Reply-To: <20051110164404.GA7303@pb15.lixom.net>


On Nov 10, 2005, at 10:44 AM, Olof Johansson wrote:

> On Wed, Nov 09, 2005 at 09:38:37PM -0800, Andrew Morton wrote:
>> Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
>>>
>>> Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
>>
>> I don't think I'm adding much value handling ppc/ppc64 patches,  
>> really.
>> I'd prefer to get out of that business.
>
> Main benefit for me, as a patch submitter, is that you consistently,
> always, ACK when you pick up or drop a patch. In other words, I don't
> have to go polling a tree to see if it made it in or not.
>
>> It would be better to have an arch maintainer who runs a git tree,  
>> same as
>> ia64, arm, etc.
>>
>> And, given the amount of shared infrastructure, I suspect it would  
>> have to
>> be a single git tree for both architectures.
>>
>> I'd still sweep up random ppc patches, but those will go into  
>> mainline via the
>> originator->mm->git-powerpc->linus route.
>>
>> Possible?
>
> I'm fine with all that; to be honest I haven't been certain where the
> smaller ppc/ppc64 patches should go during this whole merge  
> business (or
> after, for that matter).
>
> If Paulus wants to start an arch tree, that's fine with me. I do share
> Ben's opinion about less review though, I guess we'll just have to  
> deal
> with that.
>
> Also, Paul, I kindly request some sort of ACK mechanism similar to
> Andrew's when patches are picked up. :-)

I agree with Olof's comments.  Additionally, I think one reason we  
had been sending things to Andrew for PPC32 embedded was that the sub- 
arch maintainers (Matt, Marcelo, Tom, Dan, Sylvain, myself, etc..)  
needed a responsive path to get things to Linus which Andrew was  
providing.  If Paul's going to be able to handle accepting and  
dealing with all the embedded patches I'm fine with having a PPC git  
tree.  I'm even willing to setup some GIT tree's for sub-arch's I  
deal with for Paul to pull from if he wants.

Just my two cents.

- kumar

^ permalink raw reply
* Re: "Now booting the kernel"
From: Nitesh Guinde @ 2005-11-10 18:26 UTC (permalink / raw)
  To: linuxppc-embedded

Hello Nathael,
I tried the stuff but I am still getting the same result.
I did not find the  section "/* 2. Invalidate all entries except the
 entry we're executing in */" So I commented the TLBWE line in the
section which says "invalidate all TLB entries " . Is it correct? The
ASM code for rebooting will have to be changed for my board... right?
Nitesh

^ permalink raw reply
* 82xxHCI driver for MPC8280 Specifically
From: Russell McGuire @ 2005-11-10 21:16 UTC (permalink / raw)
  To: linuxppc-embedded
In-Reply-To: <20051110145136.3E4EC68715@ozlabs.org>

All,

I have been trying to get the 82xxHCI driver to work on our protoboard and
after a lot of correspondence with Freescale FAE's there are some real
differences in code implementation for some CPU parts.

Our board is using a MPC8280 Rev 0.1 part, the Rev number of course is the
last bit of the IMMR register. So 0xXXXX0A01 is our CPU, the 0A is all 8280
parts.

I was curious if anyone else has gotten this driver to operation
specifically on an 8280 CPU. Freescale says that ALL 8280's do NOT NEED any
microcode patch only some Rev's only need hardware workarounds to generate
the SOF packets, mainly wiring a BRG or TIMER to the DREQ1 / 4 lines at
least for Rev 0.0 and Rev 0.1. Rev A parts do not need this, as it is all
working internally, guess they finally fixed it.

This documentation is not conclusive as to how to wire and setup the DREQ
lines, and is no longer available on their websites, I have the PDF file
entitled MPC8280UMAD_D.pdf if anyone is curious about Rev 0.0 and Rev 0.1
parts.

So help, has anyone got this working with the Rev 0.0 and Rev 0.1 parts, and
if so, how? I have been spending way to much time reading and hacking code
to this barely functional. I would be happy to send anyone the code I have
currently, if they want to start in on this.

Russell McGuire

-----Original Message-----
From: linuxppc-embedded-bounces@ozlabs.org
[mailto:linuxppc-embedded-bounces@ozlabs.org] On Behalf Of
linuxppc-embedded-request@ozlabs.org
Sent: Thursday, November 10, 2005 6:52 AM
To: linuxppc-embedded@ozlabs.org
Subject: Linuxppc-embedded Digest, Vol 15, Issue 21

Send Linuxppc-embedded mailing list submissions to
	linuxppc-embedded@ozlabs.org

To subscribe or unsubscribe via the World Wide Web, visit
	https://ozlabs.org/mailman/listinfo/linuxppc-embedded
or, via email, send a message with subject or body 'help' to
	linuxppc-embedded-request@ozlabs.org

You can reach the person managing the list at
	linuxppc-embedded-owner@ozlabs.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Linuxppc-embedded digest..."


Today's Topics:

   1. Re: [PATCH 2.6.14] mm: 8xx MM fix for (David Jander)
   2. PowerPC reservations (Kalle Pokki)
   3. Re: "Now booting the kernel" (Nathael PAJANI)
   4. floating point  + kernel (PPC) (srideep.devireddy@wipro.com)
   5. SCC QMC driver for 8247 (Robin Mathew)
   6. Re: "Now booting the kernel" (Nathael PAJANI)
   7. Re: [PATCH] ppc32 8xx: MPC8xx PCMCIA update (Dominik Brodowski)


----------------------------------------------------------------------

Message: 1
Date: Thu, 10 Nov 2005 10:18:07 +0200
From: David Jander <david.jander@protonic.nl>
Subject: Re: [PATCH 2.6.14] mm: 8xx MM fix for
To: linuxppc-embedded@ozlabs.org
Message-ID: <200511100918.08060.david.jander@protonic.nl>
Content-Type: text/plain;  charset="iso-8859-1"

On Thursday 10 November 2005 08:48, David Jander wrote:
>[...]
> Hmmm. This is a lot in the line of the tests I did with (the more generic
> benchmark) nbench. After looking at those results (see my other post in
> this thread) I already suspected something like this.

Sorry, I obviously did not mean this thread, but the following post on
another 
thread:

http://ozlabs.org/pipermail/linuxppc-embedded/2005-November/020775.html

Regards,

-- 
David Jander


------------------------------

Message: 2
Date: Thu, 10 Nov 2005 10:20:30 +0200
From: Kalle Pokki <kalle.pokki@iki.fi>
Subject: PowerPC reservations
To: linuxppc-embedded <linuxppc-embedded@ozlabs.org>
Message-ID: <437302CE.8070309@iki.fi>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

Hi,

Can someone please help me understand how the memory reservations in 
PowerPC actually work. Let's just assume uniprocessor with a pre-emptive 
scheduler, and take a text-book example of an atomic increment case, 
which is also frequently used in e.g. the Linux kernel. With two atomic 
operations, everything seems to be just fine. But how about with three 
concurrent threads of execution?

 From the following code, assume r3 contains the same address for each 
incrementing operation. If the first atomic increment is pre-empted  in 
the middle, execution then jumps to the second increment (by the 
scheduler). The second increment runs through and succeeds, and 
continues straight to the third increment. Then it is again pre-empted 
in the middle, execution returning to the first increment. Now the 
processor has the reservation with the correct address, and the first 
increment succeeds when still holding the original input value. The 
first and the second increment thus write the same value in memory. 
After the first increment, the scheduler again continues the third 
increment, which doesn't succeed a first, but the second round succeeds. 
However, the value in the address pointed by r3 was not increased by 
three, but by two.

Am I just not getting how this is really supposed to work? Are there 
still some other constructs in use to prevent this, e.g. extra stwcx. 
instructions when changing the thread of execution?

I'm also wondering why the architecture specifically defines the stwcx. 
instruction to have, well, undefined behavior in case the reservation 
address differs from the address of the previous lwarx...

1:      lwarx r6, r0, r3
        addi r6, r6, 1
        stwcx. r6, r0, r3
        bne- 1b

.....

2:      lwarx r7, r0, r3
        addi r7, r7, 1
        stwcx. r7, r0, r3
        bne- 2b

3:      lwarx r8, r0, r3
        addi r8, r8, 1
        stwcx. r8, r0, r3
        bne- 3b




------------------------------

Message: 3
Date: Thu, 10 Nov 2005 11:40:14 +0100
From: Nathael PAJANI <nathael.pajani@cpe.fr>
Subject: Re: "Now booting the kernel"
To: linuxppc-embedded@ozlabs.org
Message-ID: <4373238E.8000405@cpe.fr>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

(Sorry, I first replyed with the wrong mail address)

 >Linux/PPC load: console=ttyS0,9600 root=/dev/xsysace/disc0/part2 rw
 >Uncompressing Linux...done.
 >Now booting the kernel

Hi!

At this state the bootloader stops executing and the Linux Kernel 
starts. The problem is that the Linux kernel does not know yet how to 
use the serial.

You won't have any message before it is set up (in early-console if my 
memory is allright)

So what you can do to check what's going on, is put "breakpoints" in the 
boot sequence. This means in the file arch/ppc/kernel/head*.S used for 
your board you should try to comment the line with the "tlbwe" 
instruction in the section "/* 2. Invalidate all entries except the 
entry we're executing in */"
This will allow you to keep access to your board registers.

Then you go step by step, putting some code which will reboot the board 
when executed, so you know you're going up to that point, and then move 
the "breakpoint" further.

This code does the reboot (for the booke I can reboot the board by 
writting '4' at address 0xfa001001):

ASM:
   lis r4,0xfa00
   li  r5,4
   stb r5,0x1001(r4)
   msync

C:
*((volatile unsigned char*)0xfa001001 = 4;


This way, instead of hanging up, the board reboots and you know where 
you are.

If you're going up to this:
         bl      machine_init    /* arch/ppc/kernel/setup.c */
         bl      MMU_init    /* arch/ppc/mm/init.c */
It's quite good, these are C functions, but they are processor specific, 
once again, check that the ones used (compiled) are those you need.

And next you've got the "start_kernel" call, which leads you to C code 
definitely. It's in init/main.c.


I hope I did not tell anything wrong, and that this will help.

Have fun.
Nathael.


------------------------------

Message: 4
Date: Thu, 10 Nov 2005 18:07:31 +0530
From: <srideep.devireddy@wipro.com>
Subject: floating point  + kernel (PPC)
To: <linuxppc-embedded@ozlabs.org>
Message-ID:
	<6AD9F6A5F6E096408F0B703773355A07605C40@CHN-SNR-MBX01.wipro.com>
Content-Type: text/plain; charset="us-ascii"


Thanks for your help friends ...



     I am able to bring my kernel up ...... right now I have a problem
after some time at the console .... I get floating point used in kernel
(task=C0188480,pc=1100)



10.0.0.2 login: root

Last login: Tnhu Jan  1 00:00sole

Linux 10.0.0.2 2.4.22 #1 Tue Nov 8 12:03:26 UTC 2005 ppc unknown




MontaVista(R) Linux(R) Professional Edition 3.1




root@10.0.0.2:~# <mailto:root@10.0.0.2:~> 



root@10.0.0.2:/home# cd ..

root@10.0.0.2:/# ls

bin  boot  dev  etc  home  lib  mnt  opt  proc  root  sbin  tmp  usr
var

root@10.0.0.2:/# floating point used in kernel (task=c0188480, pc=1100)





What does this mean ...? This makes the console hang .....Can any 1 help
me on in this?



Best Regards

srideep






Confidentiality Notice

The information contained in this electronic message and any attachments to
this message are intended
for the exclusive use of the addressee(s) and may contain confidential or
privileged information. If
you are not the intended recipient, please notify the sender at Wipro or
Mailadmin@wipro.com immediately
and destroy all copies of this message and any attachments.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20051110/30c43a42/
attachment-0001.htm

------------------------------

Message: 5
Date: Thu, 10 Nov 2005 20:18:48 +0530
From: Robin Mathew <robin@india.tejasnetworks.com>
Subject: SCC QMC driver for 8247
To: Linuxppc-embedded <linuxppc-embedded@ozlabs.org>
Cc: Nicholas Basker <nbasker@india.tejasnetworks.com>
Message-ID: <43735DD0.9030205@india.tejasnetworks.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

Hello:

We are working on implementing driver for SCC operating in QMC mode that 
supports multiple HDLC channels. The details of the system we are using 
are the following.

CPU Version = 8247 based on 82xx family of processor(PVR 80822014)
The Linux OS Version = DENKS Linux version 2.4.20.
The Peripherals used are = FCC1 in 10/100 ethernet
                                            FCC2 in 10/100 ethernet
                                            SCC1 currently not used, but 
proposed to be used in HDLC mode.
                                            SCC3 is not used.
                                            SCC4 operating in QMC mode 
with super -channel capability. Trying to operate 192kbps HDLC channel 
(using 3x64kbps QMC channels).
                                            SMC2 in UART mode (as a 
simple debug port without any modem signals).
                                            SPI interface currently not 
used but shall be used in future.
                                            I2C is being used.

01. Can the channel specific parameters of the SCC4 in QMC mode be 
relocated from DPRAM base address?? There is no mention in the 
8272RM.pdf about configuring the base address of channel specific 
parameters. From the QMC memory structure diagram, it looks like the 
channel specific parameters will be taken from the the DPRAM base 
address. Can you please confirm it?

02. We have changed the function m8260_cpm_dpalloc() used for DPRAM 
allocation in the linux source code. It was allocating memory from 
128Byte location to 8KByte location in DPRAM. But since QMC requires the 
lower 4KByte for channel specific parameters, we changed the function to 
allocate DPRAM from 4KByte location. Will this change lead to any 
problem for proper linux operation?

03. We are encountering a strange problem with scc4 parameter RAM. When 
the driver is coming up, its trying to initialize the SCC4 parameter RAM 
for QMC. In the location (immr + 0x8318), we are writing the value 
0x8320 but the value magically changes to 0x8300. We tried to write to 
the location using BDI and again the problem is seen. Is this a known 
problem with the processor?? This problem doesnot appear everytime. Is 
there any known cause for this problem?

Regards,
Robin


------------------------------

Message: 6
Date: Thu, 10 Nov 2005 09:46:30 +0100
From: Nathael PAJANI <nathael.pajani@ecrin.com>
Subject: Re: "Now booting the kernel"
To: linuxppc-embedded@ozlabs.org
Message-ID: <437308E6.2070804@ecrin.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

 >Linux/PPC load: console=ttyS0,9600 root=/dev/xsysace/disc0/part2 rw
 >Uncompressing Linux...done.
 >Now booting the kernel

Hi!

At this state the bootloader stops executing and the Linux Kernel 
starts. The problem is that the Linux kernel does not know yet how to 
use the serial.

You won't have any message before it is set up (in early-console if my 
memory is allright)

So what you can do to check what's going on, is put "breakpoints" in the 
boot sequence. This means in the file arch/ppc/kernel/head*.S used for 
your board you should try to comment the line with the "tlbwe" 
instruction in the section "/* 2. Invalidate all entries except the 
entry we're executing in */"
This will allow you to keep access to your board registers.

Then you go step by step, putting some code which will reboot the board 
when executed, so you know you're going up to that point, and then move 
the "breakpoint" further.

This code does the reboot (for the booke I can reboot the board by 
writting '4' at address 0xfa001001):

ASM:
   lis r4,0xfa00
   li  r5,4
   stb r5,0x1001(r4)
   msync

C:
*((volatile unsigned char*)0xfa001001 = 4;


This way, instead of hanging up, the board reboots and you know where 
you are.

If you're going up to this:
         bl      machine_init	/* arch/ppc/kernel/setup.c */
         bl      MMU_init	/* arch/ppc/mm/init.c */
It's quite good, these are C functions, but they are processor specific, 
once again, check that the ones used (compiled) are those you need.

And next you've got the "start_kernel" call, which leads you to C code 
definitely. It's in init/main.c.


I hope I did not tell anything wrong, and that this will help.

Have fun.
Nathael.


------------------------------

Message: 7
Date: Thu, 10 Nov 2005 11:03:04 +0100
From: Dominik Brodowski <linux@dominikbrodowski.net>
Subject: Re: [PATCH] ppc32 8xx: MPC8xx PCMCIA update
To: Paul Mackerras <paulus@samba.org>
Cc: linux-ppc-embedded <linuxppc-embedded@ozlabs.org>
Message-ID: <20051110100304.GA21855@dominikbrodowski.de>
Content-Type: text/plain; charset=us-ascii

Hi,

On Mon, Nov 07, 2005 at 12:03:45PM +1100, Paul Mackerras wrote:
> Marcelo Tosatti writes:
> 
> > The following patch updates the MPC8xx PCMCIA driver:
> 
> This and the following patch look OK as far as I can tell - Dominik,
> will you take care of sending them to Linus?

Yes, will do.

Thanks,
	Dominik


------------------------------

_______________________________________________
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded

End of Linuxppc-embedded Digest, Vol 15, Issue 21
*************************************************

^ permalink raw reply
* Re: 2.6.14 USB vs. sleep issues
From: Wolfgang Pfeiffer @ 2005-11-11  0:24 UTC (permalink / raw)
  To: Benjamin Herrenschmidt; +Cc: linuxppc-dev list, debian-powerpc@lists.debian.org
In-Reply-To: <1130999620.4680.28.camel@gaston>

Hi Ben

Thanks for your work, for the patches: on a Titanium IV a kernel-org
based, self-made (via "make-kpkg") 2.6.14.1 patched kernel works. USB
seems being fine here: I put the machine to sleep with a camera and a
Logitech mouse plugged in to USB connectors: After resuming the system
from sleep the mouse is still working, and the camera is usable and
fine. I'm running pbbuttons here.

It seems I have problems because of a - I still can't believe that -
missing pcmciautils package on Debian. But that's unrelated to what
we're discussing here, I believe. I'll start another thread perhaps for
this latter issue ...

On Thu, Nov 03, 2005 at 05:33:39PM +1100, Benjamin Herrenschmidt wrote:
> For those who experience crashes on sleep and/or wakeup (typically due
> to USB) with 2.6.14, I made a test patch that might help. Please let me
> know if it makes things more reliable.
> 
> http://gate.crashing.org/~benh/fix-ohci-sleep.diff

                         [ ... ]


I didn't use the one above, but just the one you posted here Nov.8
(this thread), IINM:

$ patch -p1 < /home/shorty/downloads/ben-patches/benh.nov.8.sleep.diff
patching file drivers/usb/core/hcd-pci.c
patching file drivers/usb/core/hcd.c
patching file drivers/usb/core/hcd.h
patching file drivers/usb/host/ehci-hcd.c
patching file drivers/usb/host/ehci-q.c
patching file drivers/usb/host/ehci-sched.c
patching file drivers/usb/host/ohci-hcd.c
patching file drivers/usb/host/ohci-hub.c
patching file drivers/usb/host/ohci-pci.c
patching file drivers/usb/host/uhci-hcd.c


Following that, provided my .bash_history is well organised enough to
be trusted ( ... :) I applied the 2.6.14.1 patch
("patch-2.6.14.1.bz2")

So: As to sleep/USB: Everything seems being fine here on 2.6.14.1.

FYI:
Kismet still does not seem work for hermes/orinoco on 2.6.14.1.

Thanks again for the patches, Ben.

Best Regards
Wolfgang

-- 
Wolfgang Pfeiffer
http://profiles.yahoo.com/wolfgangpfeiffer

Key ID: E3037113
Key fingerprint = A8CA 9D8C 54C4 4CC1 0B26  AA3C 9108 FB42 E303 7113

^ permalink raw reply
* 11-11-05 2.6.14 on AMCC Yosemite board(boot error)
From: KylongMu @ 2005-11-11  2:04 UTC (permalink / raw)
  To: wd; +Cc: Linuxppc-embedded
In-Reply-To: <20051102164644.6D167353A2C@atlas.denx.de>

[-- Attachment #1: Type: text/plain, Size: 204 bytes --]

Dear Denk:
	With today's update, I can make the kernel by Yosemite_defconfig,
but
When boot my board with this new kernel, it halt at boot time, the
attachment
Is the boot message.

Cordially,
Kylong Mu


[-- Attachment #2: bootmessage.txt --]
[-- Type: text/plain, Size: 5911 bytes --]

U-Boot 1.1.3 (Sep  7 2005 - 09:03:02)

IBM PowerPC 440 EP Rev. B
Board: AMCC YOSEMITE
        VCO: 1066 MHz
        CPU: 533 MHz
        PLB: 133 MHz
        OPB: 66 MHz
        PER: 66 MHz
        PCI: 66 MHz
I2C:   ready
DRAM:  256 MB
FLASH: 32 MB
PCI:   Bus Dev VenId DevId Class Int
In:    serial
Out:   serial
Err:   serial
Net:   ppc_440x_eth0, ppc_440x_eth1
Hit any key to stop autoboot:  0
=> tftp 0x400000 uImage
Waiting for PHY auto negotiation to complete.. done
Using ppc_440x_eth0 device
TFTP from server 192.168.0.93; our IP address is 192.168.0.66
Filename 'uImage'.
Load address: 0x400000
Loading: #################################################################
         #################################################################
         #################################################################
         ##########################################
done
Bytes transferred = 1212626 (1280d2 hex)
=> bootm 0x400000 0xfed40000
## Booting image at 00400000 ...
   Image Name:   Linux-2.6.14
   Created:      2005-11-11   1:51:20 UTC
   Image Type:   PowerPC Linux Kernel Image (gzip compressed)
   Data Size:    1212562 Bytes =  1.2 MB
   Load Address: 00000000
   Entry Point:  00000000
   Verifying Checksum ... OK
   Uncompressing Kernel Image ... OK
## Loading RAMDisk Image at fed40000 ...
   Image Name:   Yosemite Ramdisk
   Created:      2005-08-30   2:13:49 UTC
   Image Type:   PowerPC Linux RAMDisk Image (gzip compressed)
   Data Size:    17770706 Bytes = 16.9 MB
   Load Address: 00000000
   Entry Point:  00000000
   Verifying Checksum ... OK
   Loading Ramdisk to 0ee9b000, end 0ff8d8d2 ... OK
Linux version 2.6.14 (root@dxp) (gcc version 4.0.0) #1 Fri Nov 11 09:51:04 CST 2005
AMCC PowerPC 440EP Yosemite Platform
Built 1 zonelists
Kernel command line: ramdisk=49152 root=/dev/ram ip=192.168.1.62:::::eth0:off
PID hash table entries: 2048 (order: 11, 32768 bytes)
Dentry cache hash table entries: 65536 (order: 6, 262144 bytes)
Inode-cache hash table entries: 32768 (order: 5, 131072 bytes)
Memory: 239488k available (1852k kernel code, 604k data, 136k init, 0k highmem)
Mount-cache hash table entries: 512
checking if image is initramfs...it isn't (no cpio magic); looks like an initrd
softlockup thread 0 started up.
Freeing initrd memory: 17354k freed
NET: Registered protocol family 16
PCI: Probing PCI hardware
usbcore: registered new driver usbfs
usbcore: registered new driver hub
SCSI subsystem initialized
io scheduler noop registered
io scheduler anticipatory registered
io scheduler deadline registered
io scheduler cfq registered
usbmon: debugfs is not available
ppc-soc-ohci ppc-soc-ohci.0: USB Host Controller
ppc-soc-ohci ppc-soc-ohci.0: new USB bus registered, assigned bus number 1
ppc-soc-ohci ppc-soc-ohci.0: irq 40, io mem 0xef601000
usb usb1: Product: USB Host Controller
usb usb1: Manufacturer: Linux 2.6.14 ohci_hcd
usb usb1: SerialNumber: PPC-SOC USB
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 2 ports detected
Initializing USB Mass Storage driver...
usbcore: registered new driver usb-storage
USB Mass Storage support registered.
pegasus: v0.6.12 (2005/01/13), Pegasus/Pegasus II USB Ethernet driver
usbcore: registered new driver pegasus
Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing enabled
serial8250: ttyS0 at MMIO 0x0 (irq = 0) is a 16550A
serial8250: ttyS1 at MMIO 0x0 (irq = 1) is a 16550A
RAMDISK driver initialized: 16 RAM disks of 49152K size 1024 blocksize
PPC 4xx OCP EMAC driver, version 3.53
mal0: initialized, 4 TX channels, 2 RX channels
zmii0: bridge in RMII mode
eth0: emac0, MAC 00:10:ec:00:8f:aa
eth0: found Generic MII PHY (0x01)
eth1: emac1, MAC 00:10:ec:80:8f:aa
eth1: found Generic MII PHY (0x03)
Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 50MHz system bus speed for PIO modes; override with idebus=xx
Data machine check in kernel mode.
PLB0: BEAR=0x0000000000000000 ACR=  0x00000000 BESR= 0xfdfff7ff
POB0: BEAR=0xc27e3194ffffffff BESR0=0x00000000 BESR1=0x00000000
OPB0: BEAR=0x0000000000000151 BSTAT=0x00000000
Oops: machine check, sig: 7 [#1]
NIP: 00000000 LR: C0157E9C SP: CFFA1EE0 REGS: c0270f50 TRAP: 0202    Not tainted
MSR: 00000000 EE: 0 PR: 0 FP: 0 ME: 0 IR/DR: 00
TASK = cee98b10[1] 'swapper' THREAD: cffa0000
Last syscall: 120
GPR00: 00000002 CFFA1EE0 CEE98B10 C022673C 00000000 00000000 CFFA1F18 00000000
GPR08: 00000002 00000002 00000002 00000001 000F1FFF 60000428 0FFE6E00 00000001
GPR16: FFFFFFFF 007FFF00 0FFE1AD4 00000000 00000003 007FFE70 00800000 00000001
GPR24: C01D0000 C01D0000 C0270000 00000000 C022673C CFFA1F18 00000000 C022673C
NIP [00000000] 0x0
LR [c0157e9c] mtd_do_chip_probe+0xdc/0x334
Call trace:
 [c0157e9c] mtd_do_chip_probe+0xdc/0x334
 [c0152214] cfi_probe+0x18/0x28
 [c0152160] do_map_probe+0x40/0xdc
 [c0265568] init_yosemite_flash+0xb4/0x110
 [c00013ac] init+0xb4/0x254
 [c00046c0] kernel_thread+0x48/0x64
Data machine check in kernel mode.
PLB0: BEAR=0x0000000000000000 ACR=  0x00000000 BESR= 0xfdfff7ff
POB0: BEAR=0xc27e3194ffffffff BESR0=0x00000000 BESR1=0x00000000
OPB0: BEAR=0x0000000000000151 BSTAT=0x00000000
Oops: machine check, sig: 7 [#2]
NIP: 00000000 LR: C000235C SP: C0270E70 REGS: c0270f50 TRAP: 0202    Not tainted
MSR: 00000000 EE: 0 PR: 0 FP: 0 ME: 0 IR/DR: 00
TASK = cee98b10[1] 'swapper' THREAD: cffa0000
Last syscall: 120
GPR00: 08000000 C0270E70 CEE98B10 C0270E80 00001529 FFFFFFFF C0270000 00004000
GPR08: C0270000 C000235C 00021002 C00039E8 CEE98CD8 60000428 0FFE6E00 00000001
GPR16: FFFFFFFF 007FFF00 0FFE1AD4 00000000 00000003 007FFE70 00800000 00000001
GPR24: C01D0000 C01D0000 C0270000 00000000 C022673C CFFA1F18 00000007 C0270F50
NIP [00000000] 0x0
LR [c000235c] ret_from_except+0x0/0x18
Kernel panic - not syncing: Attempted to kill init!
 <0>Rebooting in 180 seconds..

^ permalink raw reply
* Re: 11-11-05 2.6.14 on AMCC Yosemite board(boot error)
From: Wolfgang Denk @ 2005-11-11  8:39 UTC (permalink / raw)
  To: KylongMu; +Cc: Linuxppc-embedded
In-Reply-To: <20051111020420.9644C1073@smtp.263.net>

In message <20051111020420.9644C1073@smtp.263.net> you wrote:
> 
> 	With today's update, I can make the kernel by Yosemite_defconfig,
> but
> When boot my board with this new kernel, it halt at boot time, the
> attachment
> Is the boot message.

What you show is NOT the current code.

> U-Boot 1.1.3 (Sep  7 2005 - 09:03:02)

Please update U-Boot as well. You need this commit included:

commit f190c11b1f22ff766e046588e5a7bb55f28ae305
tree 1c41a7beffe8a293174dcb7c28b394349204a047
parent 4d03a21f2329bb13a9661a23742ac0b77a7a76d5
author Stefan Roese <sr@denx.de> Sat, 05 Nov 2005 15:50:16 +0100
committer Stefan Roese <sr@denx.de> Sat, 05 Nov 2005 15:50:16 +0100

    Adjust bd->bi_flashstart on Yellowstone & Yosemite to correct size
    Patch by Stefan Roese, 05 Nov 2005

I recommend to use the top-of-tree from the CVS or GIT repositories.

> Linux version 2.6.14 (root@dxp) (gcc version 4.0.0) #1 Fri Nov 11
> 09:51:04 CST 2005

This is not the current code base. You should  use  top-of-tree  from
GIT repository (commit ff1df84b3c3154ffdb646941e1c70d17554e3042); the
kernel will display something like this:

Linux version 2.6.14-gff1df84b ...



Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
                  Nail here --X-- for new monitor.

^ permalink raw reply
* floating point operation of ppc
From: lily @ 2005-11-11  9:13 UTC (permalink / raw)
  To: linuxppc-embedded

[-- Attachment #1: Type: text/plain, Size: 543 bytes --]

hi,all:
    i build an embedded linux on powerpc 405ep,i need execute floating point operation,and i enable "math emulate" option in kernel, i run a while(1)loop ,in the loop there was floating point expression ,after test ,i found the while (1) exit because of the floating point computation,that is the floating point can't execute on ppc stablely.Is there someone meets the same problems ,please give me some suggestion,thanks!!!

                                                                                                     lily 

[-- Attachment #2: Type: text/html, Size: 1466 bytes --]

^ permalink raw reply
* packet name created by rpmbuild
From: debora liu @ 2005-11-11  9:58 UTC (permalink / raw)
  To: linuxppc-embedde

SGVsbG8gRGVueA0KDQpJJ20gdXNpbmcgcnBtYnVpbGQsIGJ1dCBpdCBjcmVhdCBycG0gcGFja2V0
IG5hbWUgaXMgIk5BTUUtcHBjXzh4eC1WRVJTSU9OLVJFTEVBU0UucHBjLnJwbSIsDQpJIHRoaW5r
IGl0IHNob3VsZCBpcyAiTkFNRS1WRVJTSU9OLVJFTEVBU0UucHBjLnJwbSIsIHRydWU/DQpJIHVz
ZSBuYXRpdmUgcnBtYnVpbGQgb24gbXkgYm9hcmQgd2l0aCBlbGRrLTMuMS4xIFBQQzh4eCBORlMg
cm9vdC4NCg0KoaGhoaGhoaGhoaGhoaGhoWRlYm9yYSBsaXUNCqGhoaGhoaGhoaGhoaGhoaFkZWJv
cmFsaEBzaW5vdmVlLmNvbQ0KoaGhoaGhoaGhoaGhoaGhoaGhoaEyMDA1LTExLTExDQo=

^ permalink raw reply
* [PATCH] powerpc: Merge vdso's and add vdso support to 32 bits kernel
From: Benjamin Herrenschmidt @ 2005-11-11 10:15 UTC (permalink / raw)
  To: Paul Mackerras
  Cc: linuxppc64-dev, linuxppc-dev list, Steve Munroe, tom_gall@mac.com

This patch moves the vdso's to arch/powerpc, adds support for the 32
bits vdso to the 32 bits kernel, rename systemcfg (finally !), and adds
some new (still untested) routines to both vdso's: clock_gettime() with
support for CLOCK_REALTIME and CLOCK_MONOTONIC, clock_getres() (same
clocks) and get_tbfreq() for glibc to retreive the timebase frequency.

Tom,Steve: The implementation of get_tbfreq() I've done for 32 bits
returns a long long (r3, r4) not a long. This is such that if we ever
add support for >4Ghz timebases on ppc32, the userland interface won't
have to change.

I have tested gettimeofday() using some glibc patches in both ppc32 and
ppc64 kernels using 32 bits userland (I haven't had a chance to test a
64 bits userland yet, but the implementation didn't change and was
tested earlier). I haven't tested yet the new functions.

Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>

Due to the size of the patch, I haven't posted it to the lists, it's
available at http://gate.crashing.org/~benh/ppc64-vdso-update.diff

Ben.

^ permalink raw reply
* Re: "Now booting the kernel"
From: drizzt @ 2005-11-11 12:51 UTC (permalink / raw)
  To: linuxppc-embedded
In-Reply-To: <20051111010005.016A868717@ozlabs.org>

Hi,

> I tried the stuff but I am still getting the same result.
This step can be quite hard to go over... do not deseparate :)

> I did not find the  section "/* 2. Invalidate all entries except the
>  entry we're executing in */" So I commented the TLBWE line in the
> section which says "invalidate all TLB entries " . Is it correct?
I think it is.
Do not forget to uncomment it when you start having outputs.

> The ASM code for rebooting will have to be changed for my board... right?
Yes

On my board, this is a feature of the VME bus, which you should'nt have, 
so check for an instruction or register to perform a reset.


Have fun :) :)
Nathael.

^ permalink raw reply
* Re: [PATCH] gianfar mii needs to zero out the mii_bus structure
From: Jeff Garzik @ 2005-11-11 13:27 UTC (permalink / raw)
  To: Kumar Gala; +Cc: netdev, linuxppc-embedded
In-Reply-To: <Pine.LNX.4.44.0511091211030.26349-100000@gate.crashing.org>

applied

^ permalink raw reply
* Re: floating point operation of ppc
From: Greg Weeks @ 2005-11-11 12:51 UTC (permalink / raw)
  To: lily; +Cc: linuxppc-embedded
In-Reply-To: <331697990.25627@st.lzu.edu.cn>

lily wrote:

> hi,all:
> i build an embedded linux on powerpc 405ep,i need execute floating
> point operation,and i enable "math emulate" option in kernel, i run a
> while(1)loop ,in the loop there was floating point expression ,after
> test ,i found the while (1) exit because of the floating point
> computation,that is the floating point can't execute on ppc
> stablely.Is there someone meets the same problems ,please give me some
> suggestion,thanks!!!

The 405ep has some errata on floating point use. I didn't work on the
processor so I don't know exactly what they are, but Timesys has a
toolchain just for the 405ep to work around the problem. The other
workaround we've used is much slower and it involved disabling the
hardware floating point unit in the head.s for the 405ep and turning on
the emulator. Just turning on the emulator is insufficient. The Timesys
toolchain isn't the only one out there specifically for the 405ep.

Greg Weeks

^ permalink raw reply
* Re: floating point operation of ppc
From: Eugene Surovegin @ 2005-11-11 19:35 UTC (permalink / raw)
  To: Greg Weeks; +Cc: linuxppc-embedded
In-Reply-To: <437493D3.2070301@timesys.com>

On Fri, Nov 11, 2005 at 07:51:31AM -0500, Greg Weeks wrote:
> lily wrote:
> 
> > hi,all:
> > i build an embedded linux on powerpc 405ep,i need execute floating
> > point operation,and i enable "math emulate" option in kernel, i run a
> > while(1)loop ,in the loop there was floating point expression ,after
> > test ,i found the while (1) exit because of the floating point
> > computation,that is the floating point can't execute on ppc
> > stablely.Is there someone meets the same problems ,please give me some
> > suggestion,thanks!!!
> 
> The 405ep has some errata on floating point use. 

Are you sure it was 405ep? There is no floating point errata for this 
chip due to the simple reason, it doesn't support floating point in 
hardware at all.

You probably confusing it with 440ep.

I'm not aware of any 405ep specific toolchain. In fact, all what is 
needed is simple 4xx specific toolchain with soft-float enabled by 
default. This is how floating point is usually done for 4xx - just soft 
emulation in user-space by the compiler without in-kernel emulation, 
which is slow.

-- 
Eugene

^ permalink raw reply
* Re: floating point operation of ppc
From: Greg Weeks @ 2005-11-11 19:47 UTC (permalink / raw)
  To: Eugene Surovegin; +Cc: linuxppc-embedded
In-Reply-To: <20051111193516.GA31237@gate.ebshome.net>

Eugene Surovegin wrote:

>On Fri, Nov 11, 2005 at 07:51:31AM -0500, Greg Weeks wrote:
>  
>
>>lily wrote:
>>
>>    
>>
>>>hi,all:
>>>i build an embedded linux on powerpc 405ep,i need execute floating
>>>point operation,and i enable "math emulate" option in kernel, i run a
>>>while(1)loop ,in the loop there was floating point expression ,after
>>>test ,i found the while (1) exit because of the floating point
>>>computation,that is the floating point can't execute on ppc
>>>stablely.Is there someone meets the same problems ,please give me some
>>>suggestion,thanks!!!
>>>      
>>>
>>The 405ep has some errata on floating point use. 
>>    
>>
>
>Are you sure it was 405ep? There is no floating point errata for this 
>chip due to the simple reason, it doesn't support floating point in 
>hardware at all.
>
>You probably confusing it with 440ep.
>
>  
>
You're right. It was the 440ep. The 405ep BSP is using the 4xx 
toolchain. I don't think I've ever tried the math emulator on a 405.


Greg Weeks

^ permalink raw reply
* MPC8272 + kernel
From: srideep.devireddy @ 2005-11-11 20:05 UTC (permalink / raw)
  To: linuxppc-embedded

[-- Attachment #1: Type: text/plain, Size: 1374 bytes --]


Hi Sir ,



      With the help of mailing list I am able to get my u-boot 1.1.3
version ... right held up with kernel

....

I am able to boot my MPC8272ADS  with u-boot 1.1.3 version . how can
build my uImaze(compressed linux image so that I can boot it ) ,what are
the options .. I got the source from Montavista BSP for MPC 8272 .. so
can  you guide me in making a compressed image so that I can boot my
Linux kernel .



As of now I am getting and error of



## Booting image at 01000000 ...



   Image Name:   Linux-2.4.22



   Image Type:   PowerPC Linux Kernel Image (gzip compressed)



   Data Size:    782360 Bytes = 764 kB



   Load Address: 00000000



   Entry Point:  00000000



   Verifying Checksum ... OK



   Uncompressing Kernel Image ... OK





That's it ... kernel hangs .. why is this ? can you kindly help me
resolving in the issue





Best Regards







Confidentiality Notice

The information contained in this electronic message and any attachments to this message are intended
for the exclusive use of the addressee(s) and may contain confidential or privileged information. If
you are not the intended recipient, please notify the sender at Wipro or Mailadmin@wipro.com immediately
and destroy all copies of this message and any attachments.

[-- Attachment #2: Type: text/html, Size: 7652 bytes --]

^ permalink raw reply
* [RFC] Attempt to clean up sigsuspend et al
From: David Woodhouse @ 2005-11-11 21:37 UTC (permalink / raw)
  To: paulus; +Cc: linuxppc-dev

We currently play tricks with assembly wrappers for various syscalls, in
case a signal is delivered. We need to make sure the registers are all
saved for the benefit of ptrace, and we need to return to userspace
without clobbering r4 and r5, as the normal syscall exit path would.

As usual, these tricks differ subtly between ppc32 and ppc64 too.

This is an attempt to get rid of it all, motivated mostly because I want
to add two _new_ functions which would need such treatment (pselect,
ppoll).

We define a new thread flag TIF_RESTOREALL which is set by the syscall
which needs this treatment, and make the syscall return path honour it.
This seems to work as far as I've tested it (i.e. the system boots) for
ppc64, but I haven't even attempted to compile the 32-bit version yet.

I've also removed the explicit calls to ptrace_notify() which were in
#ifdef CONFIG_PPC64 -- if we're now stopping on the way back to
userspace, we don't need to do that any more. I'm going to need to go
through some of the sigsuspend/signal cases with a fine-tooth comb and
make sure we're still getting a ptrace stop (and only _one_ ptrace stop)
in all cases where that's appropriate.

I also tried to clean up entry_64.S so it only checks the thread flags
in the fast path _once_. This means that for ptrace we'll disable
interrupts, then check the flags and enable interrupts again before
calling do_syscall_trace_leave(). That makes the slow path match the
PPC32 code and makes the fast path smaller.

Comments?

diff --git a/arch/powerpc/kernel/entry_32.S b/arch/powerpc/kernel/entry_32.S
index 2e99ae4..59dc2e7 100644
--- a/arch/powerpc/kernel/entry_32.S
+++ b/arch/powerpc/kernel/entry_32.S
@@ -222,25 +222,25 @@ ret_from_syscall:
 	bl	do_show_syscall_exit
 #endif
 	mr	r6,r3
-	li	r11,-_LAST_ERRNO
-	cmplw	0,r3,r11
+	lwz	r11,_CCR(r1)			/* Load CR */
+	li	r10,-_LAST_ERRNO
+	cmplw	0,r3,r10
 	rlwinm	r12,r1,0,0,(31-THREAD_SHIFT)	/* current_thread_info() */
 	blt+	30f
-	lbz	r11,TI_SC_NOERR(r12)
-	cmpwi	r11,0
+	lbz	r10,TI_SC_NOERR(r12)
+	cmpwi	r10,0
 	bne	30f
 	neg	r3,r3
-	lwz	r10,_CCR(r1)	/* Set SO bit in CR */
-	oris	r10,r10,0x1000
-	stw	r10,_CCR(r1)
+	oris	r11,r11,0x1000	/* Set SO bit in CR */
 
 	/* disable interrupts so current_thread_info()->flags can't change */
 30:	LOAD_MSR_KERNEL(r10,MSR_KERNEL)	/* doesn't include MSR_EE */
 	SYNC
 	MTMSRD(r10)
 	lwz	r9,TI_FLAGS(r12)
-	andi.	r0,r9,(_TIF_SYSCALL_T_OR_A|_TIF_SIGPENDING|_TIF_NEED_RESCHED)
+	andi.	r0,r9,(_TIF_SYSCALL_T_OR_A|_TIF_SIGPENDING|_TIF_NEED_RESCHED|_TIF_RESTOREALL)
 	bne-	syscall_exit_work
+	stw	r11,_CCR(r1)
 syscall_exit_cont:
 #if defined(CONFIG_4xx) || defined(CONFIG_BOOKE)
 	/* If the process has its own DBCR0 value, load it up.  The single
@@ -292,9 +292,13 @@ syscall_dotrace:
 	b	syscall_dotrace_cont
 
 syscall_exit_work:
+	andi.	r0,r9,_TIF_RESTOREALL
+	bne-	3f
+
 	stw	r6,RESULT(r1)	/* Save result */
 	stw	r3,GPR3(r1)	/* Update return value */
-	andi.	r0,r9,_TIF_SYSCALL_T_OR_A
+	stw	r11,_CCR(r1)
+3:	andi.	r0,r9,_TIF_SYSCALL_T_OR_A
 	beq	5f
 	ori	r10,r10,MSR_EE
 	SYNC
@@ -407,22 +411,6 @@ show_syscalls_task:
  * to save all the nonvolatile registers (r13 - r31) before calling
  * the C code.
  */
-	.globl	ppc_sigsuspend
-ppc_sigsuspend:
-	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_sigsuspend
-
-	.globl	ppc_rt_sigsuspend
-ppc_rt_sigsuspend:
-	SAVE_NVGPRS(r1)
-	lwz	r0,_TRAP(r1)
-	rlwinm	r0,r0,0,0,30
-	stw	r0,_TRAP(r1)
-	b	sys_rt_sigsuspend
-
 	.globl	ppc_fork
 ppc_fork:
 	SAVE_NVGPRS(r1)
@@ -447,14 +435,6 @@ 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
@@ -626,16 +606,6 @@ END_FTR_SECTION_IFSET(CPU_FTR_601)
 	.long	ret_from_except
 #endif
 
-	.globl	sigreturn_exit
-sigreturn_exit:
-	subi	r1,r3,STACK_FRAME_OVERHEAD
-	rlwinm	r12,r1,0,0,(31-THREAD_SHIFT)	/* current_thread_info() */
-	lwz	r9,TI_FLAGS(r12)
-	andi.	r0,r9,_TIF_SYSCALL_T_OR_A
-	beq+	ret_from_except_full
-	bl	do_syscall_trace_leave
-	/* fall through */
-
 	.globl	ret_from_except_full
 ret_from_except_full:
 	REST_NVGPRS(r1)
@@ -658,7 +628,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)
+	andi.	r0,r9,(_TIF_SIGPENDING|_TIF_NEED_RESCHED|_TIF_RESTOREALL)
 	bne	do_work
 
 restore_user:
@@ -876,6 +846,8 @@ load_dbcr0:
 #endif /* !(CONFIG_4xx || CONFIG_BOOKE) */
 
 do_work:			/* r10 contains MSR_KERNEL here */
+	andi.	r0,r9,_TIF_RESTOREALL
+	bne-	do_clear_restoreall	
 	andi.	r0,r9,_TIF_NEED_RESCHED
 	beq	do_user_signal
 
@@ -890,6 +862,8 @@ recheck:
 	MTMSRD(r10)		/* disable interrupts */
 	rlwinm	r9,r1,0,0,(31-THREAD_SHIFT)
 	lwz	r9,TI_FLAGS(r9)
+	andi.	r0,r9,_TIF_RESTOREALL
+	bne-	do_clear_restoreall
 	andi.	r0,r9,_TIF_NEED_RESCHED
 	bne-	do_resched
 	andi.	r0,r9,_TIF_SIGPENDING
@@ -911,6 +885,9 @@ do_user_signal:			/* r10 contains MSR_KE
 	REST_NVGPRS(r1)
 	b	recheck
 
+do_clear_restoreall:
+	bl	do_clear_tif_restoreall
+	b	recheck
 /*
  * We come here when we are at the end of handling an exception
  * that occurred at a place where taking an exception will lose
diff --git a/arch/powerpc/kernel/entry_64.S b/arch/powerpc/kernel/entry_64.S
index 2d22bf0..756663e 100644
--- a/arch/powerpc/kernel/entry_64.S
+++ b/arch/powerpc/kernel/entry_64.S
@@ -157,12 +157,6 @@ syscall_exit:
 	bge-	syscall_error
 syscall_error_cont:
 
-	/* check for syscall tracing or audit */
-	ld	r9,TI_FLAGS(r12)
-	andi.	r0,r9,(_TIF_SYSCALL_T_OR_A|_TIF_SINGLESTEP)
-	bne-	syscall_exit_trace
-syscall_exit_trace_cont:
-
 	/* disable interrupts so current_thread_info()->flags can't change,
 	   and so that we don't get interrupted after loading SRR0/1. */
 	ld	r8,_MSR(r1)
@@ -173,8 +167,9 @@ syscall_exit_trace_cont:
 	rotldi	r10,r10,16
 	mtmsrd	r10,1
 	ld	r9,TI_FLAGS(r12)
-	andi.	r0,r9,(_TIF_SYSCALL_T_OR_A|_TIF_SIGPENDING|_TIF_NEED_RESCHED)
+	andi.	r0,r9,(_TIF_SYSCALL_T_OR_A|_TIF_SINGLESTEP|_TIF_SIGPENDING|_TIF_NEED_RESCHED|_TIF_RESTOREALL)
 	bne-	syscall_exit_work
+	std	r5,_CCR(r1)
 	ld	r7,_NIP(r1)
 	stdcx.	r0,0,r1			/* to clear the reservation */
 	andi.	r6,r8,MSR_PR
@@ -205,7 +200,6 @@ syscall_error:
 	bne-	syscall_error_cont
 	neg	r3,r3
 	oris	r5,r5,0x1000	/* Set SO bit in CR */
-	std	r5,_CCR(r1)
 	b	syscall_error_cont
         
 /* Traced system call support */
@@ -225,8 +219,22 @@ syscall_dotrace:
 	ld	r10,TI_FLAGS(r10)
 	b	syscall_dotrace_cont
 
-syscall_exit_trace:
+syscall_exit_work:
+	/* Avoid saving r3 and ccr if TIF_RESTOREALL flag is set */
+	andi.	r0,r9,_TIF_RESTOREALL
+	bne-	1f
+
 	std	r3,GPR3(r1)
+	std	r5,_CCR(r1)
+
+	/* If tracing, re-enable interrupts and do it */
+1:	andi.	r0,r9,(_TIF_SYSCALL_T_OR_A|_TIF_SINGLESTEP)
+	beq	.ret_from_except_lite
+
+	mfmsr	r10
+	ori	r10,r10,MSR_EE
+	mtmsrd	r10,1
+	
 	bl	.save_nvgprs
 	addi	r3,r1,STACK_FRAME_OVERHEAD
 	bl	.do_syscall_trace_leave
@@ -234,12 +242,14 @@ syscall_exit_trace:
 	ld	r3,GPR3(r1)
 	ld	r5,_CCR(r1)
 	clrrdi	r12,r1,THREAD_SHIFT
-	b	syscall_exit_trace_cont
 
-/* Stuff to do on exit from a system call. */
-syscall_exit_work:
-	std	r3,GPR3(r1)
-	std	r5,_CCR(r1)
+	/* Disable interrupts again and handle other work if any */
+	mfmsr	r10
+	rldicl	r10,r10,48,1
+	rotldi	r10,r10,16
+	mtmsrd	r10,1
+	
+	ld	r9,TI_FLAGS(r12)
 	b	.ret_from_except_lite
 
 /* Save non-volatile GPRs, if not already saved. */
@@ -260,35 +270,6 @@ _GLOBAL(save_nvgprs)
  * the C code.  Similarly, fork, vfork and clone need the full
  * register state on the stack so that it can be copied to the child.
  */
-_GLOBAL(ppc32_sigsuspend)
-	bl	.save_nvgprs
-	bl	.compat_sys_sigsuspend
-	b	70f
-
-_GLOBAL(ppc64_rt_sigsuspend)
-	bl	.save_nvgprs
-	bl	.sys_rt_sigsuspend
-	b	70f
-
-_GLOBAL(ppc32_rt_sigsuspend)
-	bl	.save_nvgprs
-	bl	.compat_sys_rt_sigsuspend
-70:	cmpdi	0,r3,0
-	/* If it returned an error, we need to return via syscall_exit to set
-	   the SO bit in cr0 and potentially stop for ptrace. */
-	bne	syscall_exit
-	/* If sigsuspend() returns zero, we are going into a signal handler. We
-	   may need to call audit_syscall_exit() to mark the exit from sigsuspend() */
-#ifdef CONFIG_AUDITSYSCALL
-	ld	r3,PACACURRENT(r13)
-	ld	r4,AUDITCONTEXT(r3)
-	cmpdi	0,r4,0
-	beq	.ret_from_except	/* No audit_context: Leave immediately. */
-	li	r4, 2			/* AUDITSC_FAILURE */
-	li	r5,-4			/* It's always -EINTR */
-	bl	.audit_syscall_exit
-#endif
-	b	.ret_from_except
 
 _GLOBAL(ppc_fork)
 	bl	.save_nvgprs
@@ -305,37 +286,6 @@ _GLOBAL(ppc_clone)
 	bl	.sys_clone
 	b	syscall_exit
 
-_GLOBAL(ppc32_swapcontext)
-	bl	.save_nvgprs
-	bl	.compat_sys_swapcontext
-	b	80f
-	
-_GLOBAL(ppc64_swapcontext)
-	bl	.save_nvgprs
-	bl	.sys_swapcontext
-	b	80f
-
-_GLOBAL(ppc32_sigreturn)
-	bl	.compat_sys_sigreturn
-	b	80f
-
-_GLOBAL(ppc32_rt_sigreturn)
-	bl	.compat_sys_rt_sigreturn
-	b	80f
-
-_GLOBAL(ppc64_rt_sigreturn)
-	bl	.sys_rt_sigreturn
-
-80:	cmpdi	0,r3,0
-	blt	syscall_exit
-	clrrdi	r4,r1,THREAD_SHIFT
-	ld	r4,TI_FLAGS(r4)
-	andi.	r4,r4,(_TIF_SYSCALL_T_OR_A|_TIF_SINGLESTEP)
-	beq+	81f
-	addi	r3,r1,STACK_FRAME_OVERHEAD
-	bl	.do_syscall_trace_leave
-81:	b	.ret_from_except
-
 _GLOBAL(ret_from_fork)
 	bl	.schedule_tail
 	REST_NVGPRS(r1)
@@ -602,7 +552,12 @@ user_work:
 	bl	.schedule
 	b	.ret_from_except_lite
 
-1:	bl	.save_nvgprs
+1:	andi.	r0,r4,_TIF_RESTOREALL
+	beq	2f
+	bl	.do_clear_tif_restoreall
+	b	.ret_from_except_lite
+
+2:	bl	.save_nvgprs
 	li	r3,0
 	addi	r4,r1,STACK_FRAME_OVERHEAD
 	bl	.do_signal
diff --git a/arch/powerpc/kernel/signal_32.c b/arch/powerpc/kernel/signal_32.c
index 081d931..d18aebd 100644
--- a/arch/powerpc/kernel/signal_32.c
+++ b/arch/powerpc/kernel/signal_32.c
@@ -75,7 +75,6 @@
  * registers from *regs.  This is what we need
  * to do when a signal has been delivered.
  */
-#define sigreturn_exit(regs)	return 0
 
 #define GP_REGS_SIZE	min(sizeof(elf_gregset_t32), sizeof(struct pt_regs32))
 #undef __SIGNAL_FRAMESIZE
@@ -178,8 +177,6 @@ static inline int restore_general_regs(s
 
 #else /* CONFIG_PPC64 */
 
-extern void sigreturn_exit(struct pt_regs *);
-
 #define GP_REGS_SIZE	min(sizeof(elf_gregset_t), sizeof(struct pt_regs))
 
 static inline int put_sigset_t(sigset_t __user *uset, sigset_t *set)
@@ -255,8 +252,10 @@ long sys_sigsuspend(old_sigset_t mask, i
 	while (1) {
 		current->state = TASK_INTERRUPTIBLE;
 		schedule();
-		if (do_signal(&saveset, regs))
-			sigreturn_exit(regs);
+		if (do_signal(&saveset, regs)) {
+			set_thread_flag(TIF_RESTOREALL);
+			return 0;
+		}
 	}
 }
 
@@ -291,8 +290,10 @@ long sys_rt_sigsuspend(
 	while (1) {
 		current->state = TASK_INTERRUPTIBLE;
 		schedule();
-		if (do_signal(&saveset, regs))
-			sigreturn_exit(regs);
+		if (do_signal(&saveset, regs)) {
+			set_thread_flag(TIF_RESTOREALL);
+			return 0;
+		}
 	}
 }
 
@@ -829,12 +830,6 @@ static int handle_rt_signal(unsigned lon
 	regs->gpr[6] = (unsigned long) rt_sf;
 	regs->nip = (unsigned long) ka->sa.sa_handler;
 	regs->trap = 0;
-#ifdef CONFIG_PPC64
-	regs->result = 0;
-
-	if (test_thread_flag(TIF_SINGLESTEP))
-		ptrace_notify(SIGTRAP);
-#endif
 	return 1;
 
 badframe:
@@ -912,8 +907,8 @@ long sys_swapcontext(struct ucontext __u
 	 */
 	if (do_setcontext(new_ctx, regs, 0))
 		do_exit(SIGSEGV);
-	sigreturn_exit(regs);
-	/* doesn't actually return back to here */
+
+	set_thread_flag(TIF_RESTOREALL);
 	return 0;
 }
 
@@ -946,12 +941,11 @@ long sys_rt_sigreturn(int r3, int r4, in
 	 * nobody does any...
 	 */
 	compat_sys_sigaltstack((u32)(u64)&rt_sf->uc.uc_stack, 0, 0, 0, 0, 0, regs);
-	return (int)regs->result;
 #else
 	do_sigaltstack(&rt_sf->uc.uc_stack, NULL, regs->gpr[1]);
-	sigreturn_exit(regs);		/* doesn't return here */
-	return 0;
 #endif
+	set_thread_flag(TIF_RESTOREALL);
+	return 0;
 
  bad:
 	force_sig(SIGSEGV, current);
@@ -1042,9 +1036,7 @@ int sys_debug_setcontext(struct ucontext
 	 */
 	do_sigaltstack(&ctx->uc_stack, NULL, regs->gpr[1]);
 
-	sigreturn_exit(regs);
-	/* doesn't actually return back to here */
-
+	set_thread_flag(TIF_RESTOREALL);
  out:
 	return 0;
 }
@@ -1109,12 +1101,6 @@ static int handle_signal(unsigned long s
 	regs->gpr[4] = (unsigned long) sc;
 	regs->nip = (unsigned long) ka->sa.sa_handler;
 	regs->trap = 0;
-#ifdef CONFIG_PPC64
-	regs->result = 0;
-
-	if (test_thread_flag(TIF_SINGLESTEP))
-		ptrace_notify(SIGTRAP);
-#endif
 
 	return 1;
 
@@ -1162,12 +1148,8 @@ long sys_sigreturn(int r3, int r4, int r
 	    || restore_user_regs(regs, sr, 1))
 		goto badframe;
 
-#ifdef CONFIG_PPC64
-	return (int)regs->result;
-#else
-	sigreturn_exit(regs);		/* doesn't return */
+	set_thread_flag(TIF_RESTOREALL);
 	return 0;
-#endif
 
 badframe:
 	force_sig(SIGSEGV, current);
diff --git a/arch/powerpc/kernel/signal_64.c b/arch/powerpc/kernel/signal_64.c
index 58194e1..7520ad4 100644
--- a/arch/powerpc/kernel/signal_64.c
+++ b/arch/powerpc/kernel/signal_64.c
@@ -96,8 +96,10 @@ long sys_rt_sigsuspend(sigset_t __user *
 	while (1) {
 		current->state = TASK_INTERRUPTIBLE;
 		schedule();
-		if (do_signal(&saveset, regs))
+		if (do_signal(&saveset, regs)) {
+			set_thread_flag(TIF_RESTOREALL);
 			return 0;
+		}
 	}
 }
 
@@ -343,6 +345,7 @@ int sys_swapcontext(struct ucontext __us
 		do_exit(SIGSEGV);
 
 	/* This returns like rt_sigreturn */
+	set_thread_flag(TIF_RESTOREALL);
 	return 0;
 }
 
@@ -375,7 +378,8 @@ int sys_rt_sigreturn(unsigned long r3, u
 	 */
 	do_sigaltstack(&uc->uc_stack, NULL, regs->gpr[1]);
 
-	return regs->result;
+	set_thread_flag(TIF_RESTOREALL);
+	return 0;
 
 badframe:
 #if DEBUG_SIG
@@ -454,9 +458,6 @@ static int setup_rt_frame(int signr, str
 	if (err)
 		goto badframe;
 
-	if (test_thread_flag(TIF_SINGLESTEP))
-		ptrace_notify(SIGTRAP);
-
 	return 1;
 
 badframe:
diff --git a/arch/powerpc/kernel/syscalls.c b/arch/powerpc/kernel/syscalls.c
index f72ced1..f8ec816 100644
--- a/arch/powerpc/kernel/syscalls.c
+++ b/arch/powerpc/kernel/syscalls.c
@@ -356,3 +356,8 @@ void do_show_syscall_exit(unsigned long 
 {
 	printk(" -> %lx, current=%p cpu=%d\n", r3, current, smp_processor_id());
 }
+
+void do_clear_tif_restoreall(void)
+{
+	clear_thread_flag(TIF_RESTOREALL);
+}
diff --git a/arch/powerpc/kernel/systbl.S b/arch/powerpc/kernel/systbl.S
index 65eaea9..4bb3650 100644
--- a/arch/powerpc/kernel/systbl.S
+++ b/arch/powerpc/kernel/systbl.S
@@ -113,7 +113,7 @@ SYSCALL(sgetmask)
 COMPAT_SYS(ssetmask)
 SYSCALL(setreuid)
 SYSCALL(setregid)
-SYSX(sys_ni_syscall,ppc32_sigsuspend,ppc_sigsuspend)
+SYS32ONLY(sigsuspend)
 COMPAT_SYS(sigpending)
 COMPAT_SYS(sethostname)
 COMPAT_SYS(setrlimit)
@@ -160,7 +160,7 @@ SYSCALL(swapoff)
 COMPAT_SYS(sysinfo)
 COMPAT_SYS(ipc)
 SYSCALL(fsync)
-SYSX(sys_ni_syscall,ppc32_sigreturn,sys_sigreturn)
+SYS32ONLY(sigreturn)
 PPC_SYS(clone)
 COMPAT_SYS(setdomainname)
 PPC_SYS(newuname)
@@ -213,13 +213,13 @@ COMPAT_SYS(nfsservctl)
 SYSCALL(setresgid)
 SYSCALL(getresgid)
 COMPAT_SYS(prctl)
-SYSX(ppc64_rt_sigreturn,ppc32_rt_sigreturn,sys_rt_sigreturn)
+COMPAT_SYS(rt_sigreturn)
 COMPAT_SYS(rt_sigaction)
 COMPAT_SYS(rt_sigprocmask)
 COMPAT_SYS(rt_sigpending)
 COMPAT_SYS(rt_sigtimedwait)
 COMPAT_SYS(rt_sigqueueinfo)
-SYSX(ppc64_rt_sigsuspend,ppc32_rt_sigsuspend,ppc_rt_sigsuspend)
+COMPAT_SYS(rt_sigsuspend)
 COMPAT_SYS(pread64)
 COMPAT_SYS(pwrite64)
 SYSCALL(chown)
@@ -290,7 +290,7 @@ COMPAT_SYS(clock_settime)
 COMPAT_SYS(clock_gettime)
 COMPAT_SYS(clock_getres)
 COMPAT_SYS(clock_nanosleep)
-SYSX(ppc64_swapcontext,ppc32_swapcontext,ppc_swapcontext)
+COMPAT_SYS(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 e525f49..d10ec17 100644
--- a/include/asm-powerpc/thread_info.h
+++ b/include/asm-powerpc/thread_info.h
@@ -123,6 +123,7 @@ static inline struct thread_info *curren
 #define TIF_SINGLESTEP		9	/* singlestepping active */
 #define TIF_MEMDIE		10
 #define TIF_SECCOMP		11	/* secure computing */
+#define TIF_RESTOREALL		12	/* signal handler invoked */
 
 /* as above, but as bit values */
 #define _TIF_SYSCALL_TRACE	(1<<TIF_SYSCALL_TRACE)
@@ -136,10 +137,11 @@ static inline struct thread_info *curren
 #define _TIF_SYSCALL_AUDIT	(1<<TIF_SYSCALL_AUDIT)
 #define _TIF_SINGLESTEP		(1<<TIF_SINGLESTEP)
 #define _TIF_SECCOMP		(1<<TIF_SECCOMP)
+#define _TIF_RESTOREALL		(1<<TIF_RESTOREALL)
 #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_NEED_RESCHED | _TIF_RESTOREALL)
 
 #endif /* __KERNEL__ */
 


-- 
dwmw2

^ permalink raw reply related
* Re: 2.6.14 USB vs. sleep issues
From: Eddy Petrisor @ 2005-11-11 21:47 UTC (permalink / raw)
  To: Benjamin Herrenschmidt; +Cc: linuxppc-dev list, debian-powerpc@lists.debian.org
In-Reply-To: <1131229041.5229.29.camel@gaston>

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=x-user-defined; format=flowed, Size: 1075 bytes --]



Benjamin Herrenschmidt wrote:
> On Sat, 2005-11-05 at 22:58 +0100, Bin Zhang wrote:
> 
>>On 11/3/05, Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
>>
>>>For those who experience crashes on sleep and/or wakeup (typically due
>>>to USB) with 2.6.14, I made a test patch that might help. Please let me
>>>know if it makes things more reliable.
>>>
>>
>>I've tried your patch with usb wifi dlink dwl-g122 (my eth1). It works.
>>There are some differences in /var/log/syslog :
> 
> 
> I have another patch tho:

With this patch the kernel panics on my PowerBook 5,2

I made a few pictures with my phone and I can put them smewhere, if needed.

I will try tonight the third patch you proposed and the kernel is 
compiling now...


BTW, is there any difference between the resulted .ko files when made with:

make SUBDIRS=drivers/usb/core

make SUBDIRS=drivers/usb/core modules

and what the make command ran from the root of the kernel source?

-- 
Regards,
EddyP
=============================================
"Imagination is more important than knowledge" A.Einstein

^ permalink raw reply
* Re: 2.6.14 USB vs. sleep issues
From: Benjamin Herrenschmidt @ 2005-11-11 21:52 UTC (permalink / raw)
  To: Eddy Petrisor; +Cc: linuxppc-dev list, debian-powerpc@lists.debian.org
In-Reply-To: <43751182.1020009@gmail.com>

The latest patch that is candidate for upstream is:

Index: 2.6.14-ben/drivers/usb/core/hcd-pci.c
===================================================================
--- 2.6.14-ben.orig/drivers/usb/core/hcd-pci.c
+++ 2.6.14-ben/drivers/usb/core/hcd-pci.c
@@ -32,6 +32,13 @@
 #include <linux/usb.h>
 #include "hcd.h"
 
+#ifdef CONFIG_PPC_PMAC
+#include <asm/machdep.h>
+#include <asm/pmac_feature.h>
+#include <asm/pci-bridge.h>
+#include <asm/prom.h>
+#endif
+
 
 /* PCI-based HCs are common, but plenty of non-PCI HCs are used too */
 
@@ -278,6 +285,18 @@ int usb_hcd_pci_suspend (struct pci_dev 
 		break;
 	}
 
+#ifdef CONFIG_PPC_PMAC
+	if (retval == 0 && _machine == _MACH_Pmac) {
+	   	struct device_node	*of_node;
+
+		/* Disable USB PAD & cell clock */
+		of_node = pci_device_to_OF_node (to_pci_dev(hcd->self.
+							    controller));
+		if (of_node)
+			pmac_call_feature(PMAC_FTR_USB_ENABLE, of_node, 0, 0);
+	}
+#endif /* CONFIG_PPC_PMAC */
+
 	/* update power_state **ONLY** to make sysfs happier */
 	if (retval == 0)
 		dev->dev.power.power_state = message;
@@ -303,6 +322,18 @@ int usb_hcd_pci_resume (struct pci_dev *
 		return 0;
 	}
 
+#ifdef CONFIG_PPC_PMAC
+	if (_machine == _MACH_Pmac) {
+		struct device_node *of_node;
+
+		/* Re-enable USB PAD & cell clock */
+		of_node = pci_device_to_OF_node (to_pci_dev(hcd->self.
+							    controller));
+		if (of_node)
+			pmac_call_feature(PMAC_FTR_USB_ENABLE, of_node, 0, 1);
+	}
+#endif /* CONFIG_PPC_PMAC */
+
 	/* NOTE:  chip docs cover clean "real suspend" cases (what Linux
 	 * calls "standby", "suspend to RAM", and so on).  There are also
 	 * dirty cases when swsusp fakes a suspend in "shutdown" mode.
Index: 2.6.14-ben/drivers/usb/core/hcd.c
===================================================================
--- 2.6.14-ben.orig/drivers/usb/core/hcd.c
+++ 2.6.14-ben/drivers/usb/core/hcd.c
@@ -1600,7 +1600,8 @@ irqreturn_t usb_hcd_irq (int irq, void *
 	struct usb_hcd		*hcd = __hcd;
 	int			start = hcd->state;
 
-	if (start == HC_STATE_HALT)
+	if (start == HC_STATE_HALT ||
+	    !test_bit(HC_FLAG_IRQ_ON, &hcd->bitflags))
 		return IRQ_NONE;
 	if (hcd->driver->irq (hcd, r) == IRQ_NONE)
 		return IRQ_NONE;
@@ -1736,6 +1737,9 @@ int usb_add_hcd(struct usb_hcd *hcd,
 	if (hcd->driver->irq) {
 		char	buf[8], *bufp = buf;
 
+		set_bit(HC_FLAG_IRQ_ON, &hcd->bitflags);
+		mb();
+
 #ifdef __sparc__
 		bufp = __irq_itoa(irqnum);
 #else
Index: 2.6.14-ben/drivers/usb/core/hcd.h
===================================================================
--- 2.6.14-ben.orig/drivers/usb/core/hcd.h
+++ 2.6.14-ben/drivers/usb/core/hcd.h
@@ -71,6 +71,9 @@ struct usb_hcd {	/* usb_bus.hcpriv point
 	/*
 	 * hardware info/state
 	 */
+       unsigned long           bitflags;       /* various single-bit flags */
+#define HC_FLAG_IRQ_ON         0
+
 	const struct hc_driver	*driver;	/* hw-specific hooks */
 	unsigned		saw_irq : 1;
 	unsigned		can_wakeup:1;	/* hw supports wakeup? */
Index: 2.6.14-ben/drivers/usb/host/ehci-hcd.c
===================================================================
--- 2.6.14-ben.orig/drivers/usb/host/ehci-hcd.c
+++ 2.6.14-ben/drivers/usb/host/ehci-hcd.c
@@ -750,6 +750,12 @@ static int ehci_suspend (struct usb_hcd 
 	if (time_before (jiffies, ehci->next_statechange))
 		msleep (100);
 
+	/* Disable emission of interrupts during suspend */
+	writel(0, &ehci->regs->intr_enable);
+	mb();
+	clear_bit(HC_FLAG_IRQ_ON, &hcd->bitflags);
+	synchronize_irq(to_pci_dev(hcd->self.controller)->irq);
+
 #ifdef	CONFIG_USB_SUSPEND
 	(void) usb_suspend_device (hcd->self.root_hub, message);
 #else
@@ -776,6 +782,8 @@ static int ehci_resume (struct usb_hcd *
 	if (time_before (jiffies, ehci->next_statechange))
 		msleep (100);
 
+	set_bit(HC_FLAG_IRQ_ON, &hcd->bitflags);
+
 	/* If any port is suspended (or owned by the companion),
 	 * we know we can/must resume the HC (and mustn't reset it).
 	 */
Index: 2.6.14-ben/drivers/usb/host/ehci-q.c
===================================================================
--- 2.6.14-ben.orig/drivers/usb/host/ehci-q.c
+++ 2.6.14-ben/drivers/usb/host/ehci-q.c
@@ -926,6 +926,11 @@ submit_async (
 #endif
 
 	spin_lock_irqsave (&ehci->lock, flags);
+	if (HC_IS_SUSPENDED(ehci_to_hcd(ehci)->state)) {
+		spin_unlock_irqrestore (&ehci->lock, flags);
+		return -ESHUTDOWN;
+	}
+
 	qh = qh_append_tds (ehci, urb, qtd_list, epnum, &ep->hcpriv);
 
 	/* Control/bulk operations through TTs don't need scheduling,
Index: 2.6.14-ben/drivers/usb/host/ehci-sched.c
===================================================================
--- 2.6.14-ben.orig/drivers/usb/host/ehci-sched.c
+++ 2.6.14-ben/drivers/usb/host/ehci-sched.c
@@ -602,6 +602,11 @@ static int intr_submit (
 
 	spin_lock_irqsave (&ehci->lock, flags);
 
+	if (HC_IS_SUSPENDED(ehci_to_hcd(ehci)->state)) {
+		spin_unlock_irqrestore (&ehci->lock, flags);
+		return -ESHUTDOWN;
+	}
+
 	/* get qh and force any scheduling errors */
 	INIT_LIST_HEAD (&empty);
 	qh = qh_append_tds (ehci, urb, &empty, epnum, &ep->hcpriv);
@@ -1456,6 +1461,11 @@ static int itd_submit (struct ehci_hcd *
 
 	/* schedule ... need to lock */
 	spin_lock_irqsave (&ehci->lock, flags);
+	if (HC_IS_SUSPENDED(ehci_to_hcd(ehci)->state)) {
+		spin_unlock_irqrestore (&ehci->lock, flags);
+		status = -ESHUTDOWN;
+		goto done;
+	}
 	status = iso_stream_schedule (ehci, urb, stream);
  	if (likely (status == 0))
 		itd_link_urb (ehci, urb, ehci->periodic_size << 3, stream);
@@ -1815,6 +1825,11 @@ static int sitd_submit (struct ehci_hcd 
 
 	/* schedule ... need to lock */
 	spin_lock_irqsave (&ehci->lock, flags);
+	if (HC_IS_SUSPENDED(ehci_to_hcd(ehci)->state)) {
+		spin_unlock_irqrestore (&ehci->lock, flags);
+		status = -ESHUTDOWN;
+		goto done;
+	}
 	status = iso_stream_schedule (ehci, urb, stream);
  	if (status == 0)
 		sitd_link_urb (ehci, urb, ehci->periodic_size << 3, stream);
Index: 2.6.14-ben/drivers/usb/host/ohci-hcd.c
===================================================================
--- 2.6.14-ben.orig/drivers/usb/host/ohci-hcd.c
+++ 2.6.14-ben/drivers/usb/host/ohci-hcd.c
@@ -252,6 +252,10 @@ static int ohci_urb_enqueue (
 
 	spin_lock_irqsave (&ohci->lock, flags);
 
+	if (HC_IS_SUSPENDED(hcd->state)) {
+		retval = -ESHUTDOWN;
+		goto fail;
+	}
 	/* don't submit to a dead HC */
 	if (!HC_IS_RUNNING(hcd->state)) {
 		retval = -ENODEV;
Index: 2.6.14-ben/drivers/usb/host/ohci-hub.c
===================================================================
--- 2.6.14-ben.orig/drivers/usb/host/ohci-hub.c
+++ 2.6.14-ben/drivers/usb/host/ohci-hub.c
@@ -219,13 +219,6 @@ static int ohci_hub_resume (struct usb_h
 	/* Sometimes PCI D3 suspend trashes frame timings ... */
 	periodic_reinit (ohci);
 
-	/* interrupts might have been disabled */
-	ohci_writel (ohci, OHCI_INTR_INIT, &ohci->regs->intrenable);
-	if (ohci->ed_rm_list)
-		ohci_writel (ohci, OHCI_INTR_SF, &ohci->regs->intrenable);
-	ohci_writel (ohci, ohci_readl (ohci, &ohci->regs->intrstatus),
-			&ohci->regs->intrstatus);
-
 	/* Then re-enable operations */
 	ohci_writel (ohci, OHCI_USB_OPER, &ohci->regs->control);
 	(void) ohci_readl (ohci, &ohci->regs->control);
@@ -241,6 +234,13 @@ static int ohci_hub_resume (struct usb_h
 	/* TRSMRCY */
 	msleep (10);
 
+	/* interrupts might have been disabled */
+	ohci_writel (ohci, OHCI_INTR_INIT, &ohci->regs->intrenable);
+	if (ohci->ed_rm_list)
+		ohci_writel (ohci, OHCI_INTR_SF, &ohci->regs->intrenable);
+	ohci_writel (ohci, ohci_readl (ohci, &ohci->regs->intrstatus),
+			&ohci->regs->intrstatus);
+
 	/* keep it alive for ~5x suspend + resume costs */
 	ohci->next_statechange = jiffies + msecs_to_jiffies (250);
 
Index: 2.6.14-ben/drivers/usb/host/ohci-pci.c
===================================================================
--- 2.6.14-ben.orig/drivers/usb/host/ohci-pci.c
+++ 2.6.14-ben/drivers/usb/host/ohci-pci.c
@@ -14,13 +14,6 @@
  * This file is licenced under the GPL.
  */
  
-#ifdef CONFIG_PPC_PMAC
-#include <asm/machdep.h>
-#include <asm/pmac_feature.h>
-#include <asm/pci-bridge.h>
-#include <asm/prom.h>
-#endif
-
 #ifndef CONFIG_PCI
 #error "This file is PCI bus glue.  CONFIG_PCI must be defined."
 #endif
@@ -118,6 +111,12 @@ static int ohci_pci_suspend (struct usb_
 	if (time_before (jiffies, ohci->next_statechange))
 		msleep (100);
 
+	/* Disable emission of interrupts during suspend */
+	ohci_writel(ohci, OHCI_INTR_MIE, &ohci->regs->intrdisable);
+	mb();
+	clear_bit(HC_FLAG_IRQ_ON, &hcd->bitflags);
+	synchronize_irq(to_pci_dev(hcd->self.controller)->irq);
+
 #ifdef	CONFIG_USB_SUSPEND
 	(void) usb_suspend_device (hcd->self.root_hub, message);
 #else
@@ -129,16 +128,6 @@ static int ohci_pci_suspend (struct usb_
 	/* let things settle down a bit */
 	msleep (100);
 	
-#ifdef CONFIG_PPC_PMAC
-	if (_machine == _MACH_Pmac) {
-	   	struct device_node	*of_node;
- 
-		/* Disable USB PAD & cell clock */
-		of_node = pci_device_to_OF_node (to_pci_dev(hcd->self.controller));
-		if (of_node)
-			pmac_call_feature(PMAC_FTR_USB_ENABLE, of_node, 0, 0);
-	}
-#endif /* CONFIG_PPC_PMAC */
 	return 0;
 }
 
@@ -148,20 +137,11 @@ static int ohci_pci_resume (struct usb_h
 	struct ohci_hcd		*ohci = hcd_to_ohci (hcd);
 	int			retval = 0;
 
-#ifdef CONFIG_PPC_PMAC
-	if (_machine == _MACH_Pmac) {
-		struct device_node *of_node;
-
-		/* Re-enable USB PAD & cell clock */
-		of_node = pci_device_to_OF_node (to_pci_dev(hcd->self.controller));
-		if (of_node)
-			pmac_call_feature (PMAC_FTR_USB_ENABLE, of_node, 0, 1);
-	}
-#endif /* CONFIG_PPC_PMAC */
-
 	/* resume root hub */
 	if (time_before (jiffies, ohci->next_statechange))
 		msleep (100);
+	set_bit(HC_FLAG_IRQ_ON, &hcd->bitflags);
+
 #ifdef	CONFIG_USB_SUSPEND
 	/* get extra cleanup even if remote wakeup isn't in use */
 	retval = usb_resume_device (hcd->self.root_hub);
Index: 2.6.14-ben/drivers/usb/host/uhci-hcd.c
===================================================================
--- 2.6.14-ben.orig/drivers/usb/host/uhci-hcd.c
+++ 2.6.14-ben/drivers/usb/host/uhci-hcd.c
@@ -797,6 +797,11 @@ static int uhci_suspend(struct usb_hcd *
 
 done:
 	spin_unlock_irq(&uhci->lock);
+	if (rc == 0) {
+		mb();
+		clear_bit(HC_FLAG_IRQ_ON, &hcd->bitflags);
+		synchronize_irq(hcd->irq);
+	}
 	return rc;
 }
 
@@ -818,6 +823,8 @@ static int uhci_resume(struct usb_hcd *h
 	 * system wakeup.  Check it and reconfigure to avoid problems.
 	 */
 	check_and_reset_hc(uhci);
+	set_bit(HC_FLAG_IRQ_ON, &hcd->bitflags);
+	mb();
 	configure_hc(uhci);
 
 #ifndef CONFIG_USB_SUSPEND

^ permalink raw reply
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox