* RE: help with inittab
From: Scott Coulter @ 2006-06-09 19:19 UTC (permalink / raw)
To: Chris Dumoulin; +Cc: linuxppc-embedded
Chris,
Does your serial output stop after "Freeing unused kernel memory..."
If it does, you may have an interrupt problem with the UART. I had to
track down that very problem the other day. As a test, even if my UART
interrupt was purposely misconfigured, I still saw all of the output up
to and including "Freeing unused kernel memory..."
Scott
___________________________________________________________________
Scott N. Coulter
Senior Software Engineer
=20
Cyclone Microsystems =20
370 James Street Phone: 203.786.5536 ext. 118
New Haven, CT 06513-3051 Email: scott.coulter@cyclone.com
U.S.A. Web: http://www.cyclone.com
___________________________________________________________________
-----Original Message-----
From: linuxppc-embedded-bounces+scott.coulter=3Dcyclone.com@ozlabs.org
[mailto:linuxppc-embedded-bounces+scott.coulter=3Dcyclone.com@ozlabs.org]=
On Behalf Of Chris Dumoulin
Sent: Friday, June 09, 2006 3:15 PM
To: Steve Iribarne (GMail)
Cc: linuxppc-embedded@ozlabs.org
Subject: Re: help with inittab
The init is from Busybox. Since I'm getting output from my serial port=20
during the kernel boot process, I think it's safe to say that my=20
/dev/ttyS0 is properly configured. Besides passing the kernel argument=20
console=3DttyS0,57600, is there anything else I need to do to properly=20
configure the console? I've looked through my kernel configuration to=20
make sure that any serial device or console related stuff was enabled=20
and configured.
I'm feeling pretty stumped.
- Chris
Steve Iribarne (GMail) wrote:
> On 6/9/06, Chris Dumoulin <cdumoulin@ics-ltd.com> wrote:
>
>> I've now determined that my kernel seems to stop in the following
line
>> of code, in the function init(void * unused), in init/main.c:
>> run_init_process("/sbin/init");
>
>
> Who's init are you using??
>
> Are you using Busyboxes or sysinit from GNU?
>
>
>> I've determined that it stops at this call by stepping through the
code
>> with a BDI2000.
>>
>> My boot arguments are:
>> console=3DttyS0,57600n8 ip=3Doff root=3D/dev/ram0 rw
>>
>> My current inittab is:
>> ::sysinit:/etc/rc.sh
>> ::ctrlaltdel:/sbin/reboot
>> ::shutdown:/sbin/swapoff -a
>> ::shutdown:/bin/umount -a -r
>> ::restart:/sbin/init
>> ::respawn:/bin/sh
>>
>> I've tried adding an "echo" command to the /etc/rc.sh script that is
>> called, but I don't see any output. I've also trying changing the
>> ::sysinit line in inittab to point to some non-existent script, to
see
>> if I'll get some error message, but I still see nothing. Is it
possible
>> that /sbin/init is dying before it gets to the point of reading
inittab?
>> Any ideas?
>>
>> Regards,
>> Chris Dumoulin
>>
>>
>> Wolfgang Denk wrote:
>>
>> >In message <44888B92.40409@ics-ltd.com> you wrote:
>> >
>> >
>> >>I am using the linux kernel 2.6.15 and initrd ramdisk image from
ELDK
>> >>4.0. Currently, I seem to be able to boot without errors, but after
>> the
>> >>root filesystem is mounted, things just stop.
>> >>
>> >>
>> >
>> >And what's your console device? Are you passing any
console=3D
>> >arguments on the command line? Is the corresponding device
entry
>> >present in the /dev/directory?
>> >
>> >Best regards,
>> >
>> >Wolfgang Denk
>> >
>> >
>> >
>>
>> --=20
>> *--Christopher Dumoulin--*
>> Software Team Leader
>>
>> <http://ics-ltd.com/>
>> <http://ics-ltd.com/>
>>
>> Interactive Circuits and Systems Ltd.
>> 5430 Canotek Road
>> Ottawa, ON
>> K1J 9G2
>> (613)749-9241
>> 1-800-267-9794 (USA only)
>>
>>
------------------------------------------------------------------------
>> This e-mail is private and confidential and is for the addressee
only.
>> If misdirected, please notify us by telephone and confirm that it has
>> been deleted from your system and any hard copies destroyed. You are
>> strictly prohibited from using, printing, distributing or
disseminating
>> it or any information contained in it save to the intended recipient.
>> _______________________________________________
>> Linuxppc-embedded mailing list
>> Linuxppc-embedded@ozlabs.org
>> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>>
>
--=20
*--Christopher Dumoulin--*
Software Team Leader
<http://ics-ltd.com/>
<http://ics-ltd.com/>
Interactive Circuits and Systems Ltd.
5430 Canotek Road
Ottawa, ON
K1J 9G2
(613)749-9241
1-800-267-9794 (USA only)
------------------------------------------------------------------------
This e-mail is private and confidential and is for the addressee only.=20
If misdirected, please notify us by telephone and confirm that it has=20
been deleted from your system and any hard copies destroyed. You are=20
strictly prohibited from using, printing, distributing or disseminating=20
it or any information contained in it save to the intended recipient.
_______________________________________________
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* Re: booting Linux 2.6.15 using a ramdisk and greater than 512MB of DRAM
From: Xianghua Xiao @ 2006-06-09 19:46 UTC (permalink / raw)
To: Scott Coulter, linuxppc-embedded
In-Reply-To: <43EB80E07C42E1408726E4905FB96B0466C6C1@CYBORG3.cyclone.com>
I think it's a u-boot 'feature' and has nothing to do with the kernel.
xianghua
Scott Coulter wrote:
>Xianghua,
>
>That seems to have worked.
>
>Do you think that this is worth investigating?
>
>Thanks,
>
>
>Scott
>
>
>
>
>
>
>___________________________________________________________________
>
> Scott N. Coulter
> Senior Software Engineer
>
> Cyclone Microsystems
> 370 James Street Phone: 203.786.5536 ext. 118
> New Haven, CT 06513-3051 Email: scott.coulter@cyclone.com
> U.S.A. Web: http://www.cyclone.com
>___________________________________________________________________
>
>-----Original Message-----
>From: Xianghua Xiao [mailto:x.xiao@freescale.com]
>Sent: Friday, June 09, 2006 3:37 PM
>To: Scott Coulter
>Subject: Re: booting Linux 2.6.15 using a ramdisk and greater than 512MB
>of DRAM
>
>try set initrd_high=0xffffffff under u-boot, see if it helps
>
>Scott Coulter wrote:
>
>
>
>>Hi everyone,
>>
>>I am not sure if this is a linux question or a u-boot question. I have
>>a custom MPC8540 board running U-boot 1.1.4. With a NFS root
>>configuration, I have booted and run 2.6.15 with memory from 256MB to
>>2GB. If I build a ramdisk image (or even if I use the ramdisk image
>>with the 85xx version of ELDK 4.0) and then combine it with the kernel
>>image (vmlinux.gz) using "mkimage", the linux boot blows out with an
>>oops if I boot the board with more that 512MB of DRAM. From the U-boot
>>output, it looks like the ramdisk image is getting copied to the upper
>>portion of DRAM. Is it possible that the kernel doesn't map enough
>>
>>
>DRAM
>
>
>>to allow the image to be read?
>>
>>I haven't spent a lot of time debugging this once I saw that the 512MB
>>configuration worked OK. Has anyone run into this?
>>
>>Thanks,
>>
>>Scott
>>
>>
>>
>>___________________________________________________________________
>>
>> Scott N. Coulter
>> Senior Software Engineer
>>
>> Cyclone Microsystems
>> 370 James Street Phone: 203.786.5536 ext. 118
>> New Haven, CT 06513-3051 Email: scott.coulter@cyclone.com
>> U.S.A. Web: http://www.cyclone.com
>>___________________________________________________________________
>>
>>_______________________________________________
>>Linuxppc-embedded mailing list
>>Linuxppc-embedded@ozlabs.org
>>https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>>
>>
>>
>>
^ permalink raw reply
* Re: help with inittab
From: Chris Dumoulin @ 2006-06-09 19:49 UTC (permalink / raw)
To: Scott Coulter; +Cc: linuxppc-embedded
In-Reply-To: <43EB80E07C42E1408726E4905FB96B0466C6BF@CYBORG3.cyclone.com>
Hi Scott,
That is where my output stops. What was the cause of your interrupt
problem? Were you able to fix it?
- Chris
Scott Coulter wrote:
>Chris,
>
>Does your serial output stop after "Freeing unused kernel memory..."
>
>If it does, you may have an interrupt problem with the UART. I had to
>track down that very problem the other day. As a test, even if my UART
>interrupt was purposely misconfigured, I still saw all of the output up
>to and including "Freeing unused kernel memory..."
>
>Scott
>
>
>
>
>___________________________________________________________________
>
> Scott N. Coulter
> Senior Software Engineer
>
> Cyclone Microsystems
> 370 James Street Phone: 203.786.5536 ext. 118
> New Haven, CT 06513-3051 Email: scott.coulter@cyclone.com
> U.S.A. Web: http://www.cyclone.com
>___________________________________________________________________
>
>-----Original Message-----
>From: linuxppc-embedded-bounces+scott.coulter=cyclone.com@ozlabs.org
>[mailto:linuxppc-embedded-bounces+scott.coulter=cyclone.com@ozlabs.org]
>On Behalf Of Chris Dumoulin
>Sent: Friday, June 09, 2006 3:15 PM
>To: Steve Iribarne (GMail)
>Cc: linuxppc-embedded@ozlabs.org
>Subject: Re: help with inittab
>
>The init is from Busybox. Since I'm getting output from my serial port
>during the kernel boot process, I think it's safe to say that my
>/dev/ttyS0 is properly configured. Besides passing the kernel argument
>console=ttyS0,57600, is there anything else I need to do to properly
>configure the console? I've looked through my kernel configuration to
>make sure that any serial device or console related stuff was enabled
>and configured.
>
>I'm feeling pretty stumped.
>
>- Chris
>
>Steve Iribarne (GMail) wrote:
>
>
>
>>On 6/9/06, Chris Dumoulin <cdumoulin@ics-ltd.com> wrote:
>>
>>
>>
>>>I've now determined that my kernel seems to stop in the following
>>>
>>>
>line
>
>
>>>of code, in the function init(void * unused), in init/main.c:
>>>run_init_process("/sbin/init");
>>>
>>>
>>Who's init are you using??
>>
>>Are you using Busyboxes or sysinit from GNU?
>>
>>
>>
>>
>>>I've determined that it stops at this call by stepping through the
>>>
>>>
>code
>
>
>>>with a BDI2000.
>>>
>>>My boot arguments are:
>>>console=ttyS0,57600n8 ip=off root=/dev/ram0 rw
>>>
>>>My current inittab is:
>>>::sysinit:/etc/rc.sh
>>>::ctrlaltdel:/sbin/reboot
>>>::shutdown:/sbin/swapoff -a
>>>::shutdown:/bin/umount -a -r
>>>::restart:/sbin/init
>>>::respawn:/bin/sh
>>>
>>>I've tried adding an "echo" command to the /etc/rc.sh script that is
>>>called, but I don't see any output. I've also trying changing the
>>>::sysinit line in inittab to point to some non-existent script, to
>>>
>>>
>see
>
>
>>>if I'll get some error message, but I still see nothing. Is it
>>>
>>>
>possible
>
>
>>>that /sbin/init is dying before it gets to the point of reading
>>>
>>>
>inittab?
>
>
>>>Any ideas?
>>>
>>>Regards,
>>>Chris Dumoulin
>>>
>>>
>>>Wolfgang Denk wrote:
>>>
>>>
>>>
>>>>In message <44888B92.40409@ics-ltd.com> you wrote:
>>>>
>>>>
>>>>
>>>>
>>>>>I am using the linux kernel 2.6.15 and initrd ramdisk image from
>>>>>
>>>>>
>ELDK
>
>
>>>>>4.0. Currently, I seem to be able to boot without errors, but after
>>>>>
>>>>>
>
>
>
>>>the
>>>
>>>
>>>>>root filesystem is mounted, things just stop.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>And what's your console device? Are you passing any
>>>>
>>>>
>console=
>
>
>>>>arguments on the command line? Is the corresponding device
>>>>
>>>>
>entry
>
>
>>>>present in the /dev/directory?
>>>>
>>>>Best regards,
>>>>
>>>>Wolfgang Denk
>>>>
>>>>
>>>>
>>>>
>>>>
>>>--
>>>*--Christopher Dumoulin--*
>>>Software Team Leader
>>>
>>><http://ics-ltd.com/>
>>><http://ics-ltd.com/>
>>>
>>>Interactive Circuits and Systems Ltd.
>>>5430 Canotek Road
>>>Ottawa, ON
>>>K1J 9G2
>>>(613)749-9241
>>>1-800-267-9794 (USA only)
>>>
>>>
>>>
>>>
>------------------------------------------------------------------------
>
>
>>>This e-mail is private and confidential and is for the addressee
>>>
>>>
>only.
>
>
>>>If misdirected, please notify us by telephone and confirm that it has
>>>been deleted from your system and any hard copies destroyed. You are
>>>strictly prohibited from using, printing, distributing or
>>>
>>>
>disseminating
>
>
>>>it or any information contained in it save to the intended recipient.
>>>_______________________________________________
>>>Linuxppc-embedded mailing list
>>>Linuxppc-embedded@ozlabs.org
>>>https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>>>
>>>
>>>
>
>
>
>
--
*--Christopher Dumoulin--*
Software Team Leader
<http://ics-ltd.com/>
<http://ics-ltd.com/>
Interactive Circuits and Systems Ltd.
5430 Canotek Road
Ottawa, ON
K1J 9G2
(613)749-9241
1-800-267-9794 (USA only)
------------------------------------------------------------------------
This e-mail is private and confidential and is for the addressee only.
If misdirected, please notify us by telephone and confirm that it has
been deleted from your system and any hard copies destroyed. You are
strictly prohibited from using, printing, distributing or disseminating
it or any information contained in it save to the intended recipient.
^ permalink raw reply
* RE: help with inittab
From: Scott Coulter @ 2006-06-09 19:53 UTC (permalink / raw)
To: Chris Dumoulin; +Cc: linuxppc-embedded
Chris,
I was getting linux 2.6.15 running an MPC8560 board with an external
UART. In my board specific code that was setting up the Programmable
Interrupt Controller (openpic), I had a problem with a loop index and
the external interrupts were not getting setup correctly, but the
internal interrupts were...
Once I fixed the loop, there was output from the init process...
What type of board are you running on? Do you have the UART interrupt
configured correctly (interrupt level high or low, interrupt input
definition, etc.)?
Scott
___________________________________________________________________
Scott N. Coulter
Senior Software Engineer
=20
Cyclone Microsystems =20
370 James Street Phone: 203.786.5536 ext. 118
New Haven, CT 06513-3051 Email: scott.coulter@cyclone.com
U.S.A. Web: http://www.cyclone.com
___________________________________________________________________
-----Original Message-----
From: Chris Dumoulin [mailto:cdumoulin@ics-ltd.com]=20
Sent: Friday, June 09, 2006 3:50 PM
To: Scott Coulter
Cc: linuxppc-embedded@ozlabs.org
Subject: Re: help with inittab
Hi Scott,
That is where my output stops. What was the cause of your interrupt=20
problem? Were you able to fix it?
- Chris
Scott Coulter wrote:
>Chris,
>
>Does your serial output stop after "Freeing unused kernel memory..."
>
>If it does, you may have an interrupt problem with the UART. I had to
>track down that very problem the other day. As a test, even if my UART
>interrupt was purposely misconfigured, I still saw all of the output up
>to and including "Freeing unused kernel memory..."
>
>Scott
>
>
>
>
>___________________________________________________________________
>
> Scott N. Coulter
> Senior Software Engineer
> =20
> Cyclone Microsystems =20
> 370 James Street Phone: 203.786.5536 ext. 118
> New Haven, CT 06513-3051 Email: scott.coulter@cyclone.com
> U.S.A. Web: http://www.cyclone.com
>___________________________________________________________________
>
>-----Original Message-----
>From: linuxppc-embedded-bounces+scott.coulter=3Dcyclone.com@ozlabs.org
>[mailto:linuxppc-embedded-bounces+scott.coulter=3Dcyclone.com@ozlabs.org=
]
>On Behalf Of Chris Dumoulin
>Sent: Friday, June 09, 2006 3:15 PM
>To: Steve Iribarne (GMail)
>Cc: linuxppc-embedded@ozlabs.org
>Subject: Re: help with inittab
>
>The init is from Busybox. Since I'm getting output from my serial port=20
>during the kernel boot process, I think it's safe to say that my=20
>/dev/ttyS0 is properly configured. Besides passing the kernel argument=20
>console=3DttyS0,57600, is there anything else I need to do to properly=20
>configure the console? I've looked through my kernel configuration to=20
>make sure that any serial device or console related stuff was enabled=20
>and configured.
>
>I'm feeling pretty stumped.
>
>- Chris
>
>Steve Iribarne (GMail) wrote:
>
> =20
>
>>On 6/9/06, Chris Dumoulin <cdumoulin@ics-ltd.com> wrote:
>>
>> =20
>>
>>>I've now determined that my kernel seems to stop in the following
>>> =20
>>>
>line
> =20
>
>>>of code, in the function init(void * unused), in init/main.c:
>>>run_init_process("/sbin/init");
>>> =20
>>>
>>Who's init are you using??
>>
>>Are you using Busyboxes or sysinit from GNU?
>>
>>
>> =20
>>
>>>I've determined that it stops at this call by stepping through the
>>> =20
>>>
>code
> =20
>
>>>with a BDI2000.
>>>
>>>My boot arguments are:
>>>console=3DttyS0,57600n8 ip=3Doff root=3D/dev/ram0 rw
>>>
>>>My current inittab is:
>>>::sysinit:/etc/rc.sh
>>>::ctrlaltdel:/sbin/reboot
>>>::shutdown:/sbin/swapoff -a
>>>::shutdown:/bin/umount -a -r
>>>::restart:/sbin/init
>>>::respawn:/bin/sh
>>>
>>>I've tried adding an "echo" command to the /etc/rc.sh script that is
>>>called, but I don't see any output. I've also trying changing the
>>>::sysinit line in inittab to point to some non-existent script, to
>>> =20
>>>
>see
> =20
>
>>>if I'll get some error message, but I still see nothing. Is it
>>> =20
>>>
>possible
> =20
>
>>>that /sbin/init is dying before it gets to the point of reading
>>> =20
>>>
>inittab?
> =20
>
>>>Any ideas?
>>>
>>>Regards,
>>>Chris Dumoulin
>>>
>>>
>>>Wolfgang Denk wrote:
>>>
>>> =20
>>>
>>>>In message <44888B92.40409@ics-ltd.com> you wrote:
>>>>
>>>>
>>>> =20
>>>>
>>>>>I am using the linux kernel 2.6.15 and initrd ramdisk image from
>>>>> =20
>>>>>
>ELDK
> =20
>
>>>>>4.0. Currently, I seem to be able to boot without errors, but after
>>>>> =20
>>>>>
>
> =20
>
>>>the
>>> =20
>>>
>>>>>root filesystem is mounted, things just stop.
>>>>>
>>>>>
>>>>> =20
>>>>>
>>>>And what's your console device? Are you passing any
>>>> =20
>>>>
>console=3D
> =20
>
>>>>arguments on the command line? Is the corresponding device
>>>> =20
>>>>
>entry
> =20
>
>>>>present in the /dev/directory?
>>>>
>>>>Best regards,
>>>>
>>>>Wolfgang Denk
>>>>
>>>>
>>>>
>>>> =20
>>>>
>>>--=20
>>>*--Christopher Dumoulin--*
>>>Software Team Leader
>>>
>>><http://ics-ltd.com/>
>>><http://ics-ltd.com/>
>>>
>>>Interactive Circuits and Systems Ltd.
>>>5430 Canotek Road
>>>Ottawa, ON
>>>K1J 9G2
>>>(613)749-9241
>>>1-800-267-9794 (USA only)
>>>
>>>
>>> =20
>>>
>-----------------------------------------------------------------------
-
> =20
>
>>>This e-mail is private and confidential and is for the addressee
>>> =20
>>>
>only.
> =20
>
>>>If misdirected, please notify us by telephone and confirm that it has
>>>been deleted from your system and any hard copies destroyed. You are
>>>strictly prohibited from using, printing, distributing or
>>> =20
>>>
>disseminating
> =20
>
>>>it or any information contained in it save to the intended recipient.
>>>_______________________________________________
>>>Linuxppc-embedded mailing list
>>>Linuxppc-embedded@ozlabs.org
>>>https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>>>
>>> =20
>>>
>
>
> =20
>
--=20
*--Christopher Dumoulin--*
Software Team Leader
<http://ics-ltd.com/>
<http://ics-ltd.com/>
Interactive Circuits and Systems Ltd.
5430 Canotek Road
Ottawa, ON
K1J 9G2
(613)749-9241
1-800-267-9794 (USA only)
------------------------------------------------------------------------
This e-mail is private and confidential and is for the addressee only.=20
If misdirected, please notify us by telephone and confirm that it has=20
been deleted from your system and any hard copies destroyed. You are=20
strictly prohibited from using, printing, distributing or disseminating=20
it or any information contained in it save to the intended recipient.
^ permalink raw reply
* Re: help with inittab
From: Steve Iribarne (GMail) @ 2006-06-09 20:24 UTC (permalink / raw)
To: Chris Dumoulin; +Cc: linuxppc-embedded
In-Reply-To: <4489C8A9.1080401@ics-ltd.com>
On 6/9/06, Chris Dumoulin <cdumoulin@ics-ltd.com> wrote:
> The init is from Busybox. Since I'm getting output from my serial port
> during the kernel boot process, I think it's safe to say that my
> /dev/ttyS0 is properly configured. Besides passing the kernel argument
> console=ttyS0,57600, is there anything else I need to do to properly
> configure the console? I've looked through my kernel configuration to
> make sure that any serial device or console related stuff was enabled
> and configured.
>
> I'm feeling pretty stumped.
>
Ok.. so if you are using the init from Busybox, there should be a
softlink and I can't remember where they put it. I think it is the
root file system. I think they call in linuxrc or something like
that. I'd make sure you have that.
**OR** what I did..
Get sysinit from GNU and tell Busybox not to use the init. I've had
this exact same problem and it was my init.
-stv
> - Chris
>
> Steve Iribarne (GMail) wrote:
>
> > On 6/9/06, Chris Dumoulin <cdumoulin@ics-ltd.com> wrote:
> >
> >> I've now determined that my kernel seems to stop in the following line
> >> of code, in the function init(void * unused), in init/main.c:
> >> run_init_process("/sbin/init");
> >
> >
> > Who's init are you using??
> >
> > Are you using Busyboxes or sysinit from GNU?
> >
> >
> >> I've determined that it stops at this call by stepping through the code
> >> with a BDI2000.
> >>
> >> My boot arguments are:
> >> console=ttyS0,57600n8 ip=off root=/dev/ram0 rw
> >>
> >> My current inittab is:
> >> ::sysinit:/etc/rc.sh
> >> ::ctrlaltdel:/sbin/reboot
> >> ::shutdown:/sbin/swapoff -a
> >> ::shutdown:/bin/umount -a -r
> >> ::restart:/sbin/init
> >> ::respawn:/bin/sh
> >>
> >> I've tried adding an "echo" command to the /etc/rc.sh script that is
> >> called, but I don't see any output. I've also trying changing the
> >> ::sysinit line in inittab to point to some non-existent script, to see
> >> if I'll get some error message, but I still see nothing. Is it possible
> >> that /sbin/init is dying before it gets to the point of reading inittab?
> >> Any ideas?
> >>
> >> Regards,
> >> Chris Dumoulin
> >>
> >>
> >> Wolfgang Denk wrote:
> >>
> >> >In message <44888B92.40409@ics-ltd.com> you wrote:
> >> >
> >> >
> >> >>I am using the linux kernel 2.6.15 and initrd ramdisk image from ELDK
> >> >>4.0. Currently, I seem to be able to boot without errors, but after
> >> the
> >> >>root filesystem is mounted, things just stop.
> >> >>
> >> >>
> >> >
> >> >And what's your console device? Are you passing any console=
> >> >arguments on the command line? Is the corresponding device entry
> >> >present in the /dev/directory?
> >> >
> >> >Best regards,
> >> >
> >> >Wolfgang Denk
> >> >
> >> >
> >> >
> >>
> >> --
> >> *--Christopher Dumoulin--*
> >> Software Team Leader
> >>
> >> <http://ics-ltd.com/>
> >> <http://ics-ltd.com/>
> >>
> >> Interactive Circuits and Systems Ltd.
> >> 5430 Canotek Road
> >> Ottawa, ON
> >> K1J 9G2
> >> (613)749-9241
> >> 1-800-267-9794 (USA only)
> >>
> >> ------------------------------------------------------------------------
> >> This e-mail is private and confidential and is for the addressee only.
> >> If misdirected, please notify us by telephone and confirm that it has
> >> been deleted from your system and any hard copies destroyed. You are
> >> strictly prohibited from using, printing, distributing or disseminating
> >> it or any information contained in it save to the intended recipient.
> >> _______________________________________________
> >> Linuxppc-embedded mailing list
> >> Linuxppc-embedded@ozlabs.org
> >> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
> >>
> >
>
>
> --
> *--Christopher Dumoulin--*
> Software Team Leader
>
> <http://ics-ltd.com/>
> <http://ics-ltd.com/>
>
> Interactive Circuits and Systems Ltd.
> 5430 Canotek Road
> Ottawa, ON
> K1J 9G2
> (613)749-9241
> 1-800-267-9794 (USA only)
>
> ------------------------------------------------------------------------
> This e-mail is private and confidential and is for the addressee only.
> If misdirected, please notify us by telephone and confirm that it has
> been deleted from your system and any hard copies destroyed. You are
> strictly prohibited from using, printing, distributing or disseminating
> it or any information contained in it save to the intended recipient.
>
^ permalink raw reply
* Re: help with inittab
From: Chris Dumoulin @ 2006-06-09 20:43 UTC (permalink / raw)
To: Scott Coulter; +Cc: linuxppc-embedded
In-Reply-To: <43EB80E07C42E1408726E4905FB96B0466C6C5@CYBORG3.cyclone.com>
Scott, you are my saviour. The problem was in fact the IRQ setting. I
changed the IRQ and now I get a shell, prompt, and everything. I never
would have thought to check the UART settings, since I was getting
output during kernel boot-up, I thought everything was good.
Thanks again,
Chris
Scott Coulter wrote:
>Chris,
>
>I was getting linux 2.6.15 running an MPC8560 board with an external
>UART. In my board specific code that was setting up the Programmable
>Interrupt Controller (openpic), I had a problem with a loop index and
>the external interrupts were not getting setup correctly, but the
>internal interrupts were...
>
>Once I fixed the loop, there was output from the init process...
>
>What type of board are you running on? Do you have the UART interrupt
>configured correctly (interrupt level high or low, interrupt input
>definition, etc.)?
>
>
>Scott
>
>
>
>
>
>___________________________________________________________________
>
> Scott N. Coulter
> Senior Software Engineer
>
> Cyclone Microsystems
> 370 James Street Phone: 203.786.5536 ext. 118
> New Haven, CT 06513-3051 Email: scott.coulter@cyclone.com
> U.S.A. Web: http://www.cyclone.com
>___________________________________________________________________
>
>-----Original Message-----
>From: Chris Dumoulin [mailto:cdumoulin@ics-ltd.com]
>Sent: Friday, June 09, 2006 3:50 PM
>To: Scott Coulter
>Cc: linuxppc-embedded@ozlabs.org
>Subject: Re: help with inittab
>
>Hi Scott,
>That is where my output stops. What was the cause of your interrupt
>problem? Were you able to fix it?
>
>- Chris
>
>Scott Coulter wrote:
>
>
>
>>Chris,
>>
>>Does your serial output stop after "Freeing unused kernel memory..."
>>
>>If it does, you may have an interrupt problem with the UART. I had to
>>track down that very problem the other day. As a test, even if my UART
>>interrupt was purposely misconfigured, I still saw all of the output up
>>to and including "Freeing unused kernel memory..."
>>
>>Scott
>>
>>
>>
>>
>>___________________________________________________________________
>>
>> Scott N. Coulter
>> Senior Software Engineer
>>
>> Cyclone Microsystems
>> 370 James Street Phone: 203.786.5536 ext. 118
>> New Haven, CT 06513-3051 Email: scott.coulter@cyclone.com
>> U.S.A. Web: http://www.cyclone.com
>>___________________________________________________________________
>>
>>-----Original Message-----
>>From: linuxppc-embedded-bounces+scott.coulter=cyclone.com@ozlabs.org
>>[mailto:linuxppc-embedded-bounces+scott.coulter=cyclone.com@ozlabs.org]
>>On Behalf Of Chris Dumoulin
>>Sent: Friday, June 09, 2006 3:15 PM
>>To: Steve Iribarne (GMail)
>>Cc: linuxppc-embedded@ozlabs.org
>>Subject: Re: help with inittab
>>
>>The init is from Busybox. Since I'm getting output from my serial port
>>during the kernel boot process, I think it's safe to say that my
>>/dev/ttyS0 is properly configured. Besides passing the kernel argument
>>console=ttyS0,57600, is there anything else I need to do to properly
>>configure the console? I've looked through my kernel configuration to
>>make sure that any serial device or console related stuff was enabled
>>and configured.
>>
>>I'm feeling pretty stumped.
>>
>>- Chris
>>
>>Steve Iribarne (GMail) wrote:
>>
>>
>>
>>
>>
>>>On 6/9/06, Chris Dumoulin <cdumoulin@ics-ltd.com> wrote:
>>>
>>>
>>>
>>>
>>>
>>>>I've now determined that my kernel seems to stop in the following
>>>>
>>>>
>>>>
>>>>
>>line
>>
>>
>>
>>
>>>>of code, in the function init(void * unused), in init/main.c:
>>>>run_init_process("/sbin/init");
>>>>
>>>>
>>>>
>>>>
>>>Who's init are you using??
>>>
>>>Are you using Busyboxes or sysinit from GNU?
>>>
>>>
>>>
>>>
>>>
>>>
>>>>I've determined that it stops at this call by stepping through the
>>>>
>>>>
>>>>
>>>>
>>code
>>
>>
>>
>>
>>>>with a BDI2000.
>>>>
>>>>My boot arguments are:
>>>>console=ttyS0,57600n8 ip=off root=/dev/ram0 rw
>>>>
>>>>My current inittab is:
>>>>::sysinit:/etc/rc.sh
>>>>::ctrlaltdel:/sbin/reboot
>>>>::shutdown:/sbin/swapoff -a
>>>>::shutdown:/bin/umount -a -r
>>>>::restart:/sbin/init
>>>>::respawn:/bin/sh
>>>>
>>>>I've tried adding an "echo" command to the /etc/rc.sh script that is
>>>>called, but I don't see any output. I've also trying changing the
>>>>::sysinit line in inittab to point to some non-existent script, to
>>>>
>>>>
>>>>
>>>>
>>see
>>
>>
>>
>>
>>>>if I'll get some error message, but I still see nothing. Is it
>>>>
>>>>
>>>>
>>>>
>>possible
>>
>>
>>
>>
>>>>that /sbin/init is dying before it gets to the point of reading
>>>>
>>>>
>>>>
>>>>
>>inittab?
>>
>>
>>
>>
>>>>Any ideas?
>>>>
>>>>Regards,
>>>>Chris Dumoulin
>>>>
>>>>
>>>>Wolfgang Denk wrote:
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>>In message <44888B92.40409@ics-ltd.com> you wrote:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>I am using the linux kernel 2.6.15 and initrd ramdisk image from
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>ELDK
>>
>>
>>
>>
>>>>>>4.0. Currently, I seem to be able to boot without errors, but after
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>
>>
>>
>>
>>>>the
>>>>
>>>>
>>>>
>>>>
>>>>>>root filesystem is mounted, things just stop.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>And what's your console device? Are you passing any
>>>>>
>>>>>
>>>>>
>>>>>
>>console=
>>
>>
>>
>>
>>>>>arguments on the command line? Is the corresponding device
>>>>>
>>>>>
>>>>>
>>>>>
>>entry
>>
>>
>>
>>
>>>>>present in the /dev/directory?
>>>>>
>>>>>Best regards,
>>>>>
>>>>>Wolfgang Denk
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>--
>>>>*--Christopher Dumoulin--*
>>>>Software Team Leader
>>>>
>>>><http://ics-ltd.com/>
>>>><http://ics-ltd.com/>
>>>>
>>>>Interactive Circuits and Systems Ltd.
>>>>5430 Canotek Road
>>>>Ottawa, ON
>>>>K1J 9G2
>>>>(613)749-9241
>>>>1-800-267-9794 (USA only)
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>-----------------------------------------------------------------------
>>
>>
>-
>
>
>>
>>
>>
>>
>>>>This e-mail is private and confidential and is for the addressee
>>>>
>>>>
>>>>
>>>>
>>only.
>>
>>
>>
>>
>>>>If misdirected, please notify us by telephone and confirm that it has
>>>>been deleted from your system and any hard copies destroyed. You are
>>>>strictly prohibited from using, printing, distributing or
>>>>
>>>>
>>>>
>>>>
>>disseminating
>>
>>
>>
>>
>>>>it or any information contained in it save to the intended recipient.
>>>>_______________________________________________
>>>>Linuxppc-embedded mailing list
>>>>Linuxppc-embedded@ozlabs.org
>>>>https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>>>>
>>>>
>>>>
>>>>
>>>>
>>
>>
>>
>>
>
>
>
>
--
*--Christopher Dumoulin--*
Software Team Leader
<http://ics-ltd.com/>
<http://ics-ltd.com/>
Interactive Circuits and Systems Ltd.
5430 Canotek Road
Ottawa, ON
K1J 9G2
(613)749-9241
1-800-267-9794 (USA only)
------------------------------------------------------------------------
This e-mail is private and confidential and is for the addressee only.
If misdirected, please notify us by telephone and confirm that it has
been deleted from your system and any hard copies destroyed. You are
strictly prohibited from using, printing, distributing or disseminating
it or any information contained in it save to the intended recipient.
^ permalink raw reply
* Re: [PATCH 2/10 v2] Add the MPC8641 HPCN platform files.
From: Benjamin Herrenschmidt @ 2006-06-09 22:07 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <E1FojK9-0004AD-DN@jdl.com>
> > Cascade handling is changing with my genirq port. It will be easy to
> > adapt though. Same comments howveer, you should have a device-tree node
> > for the 8259 (under an ISA bridge, those shall really be in the
> > device-tree). In general, on-board bridges should be in the device-tree,
> > only slots or standardly routed child PCI devices need not.
>
> Can you send me an example?
I'll try to dig something. Power3 at least has MPIC<->8259 cascade, as
do some IBM blades when running bare metal kernels.
> > The above looks dodgy... powerpc uses the timebase frequency for delays
> > anyway, lpj will be initialized by the bogomips code, and should but
> > unused mostly nowadays anyway.
>
> Uh, you want I should rip it out, boss? :-)
Well, in any case it's bogus... your loops_per_jiffies is generally not
your processor frequency... I might be close on some CPUs and not on
others (it was double of it on early G4s for example), it may also
depend if things like BTIC are enabled.
I think you may just rip that out. Just check it doesn't break
anything :)
> > > +#ifdef CONFIG_PEX
> > > + for (np = NULL; (np = of_find_node_by_type(np, "pci")) != NULL;)
> > > + add_bridge(np);
> > > +
> > > + ppc_md.pci_swizzle = common_swizzle;
> > > + ppc_md.pci_map_irq = mpc86xx_map_irq;
> > > + ppc_md.pci_exclude_device = mpc86xx_exclude_device;
> > > +#endif
> >
> > I'm not sure I like this CONFIG_PEX (in general). Just use CONFIG_PCI
> > for now all over the place. PCI-E has it's own binding that we don't
> > quite respect yet but will do and all of that will be in the
> > device-tree. However, as far as the kernel is concerned, this is all
> > under CONFIG_PCI.
>
> But I think we are looking for independent PCI/PCI-E options
> to be independently configurable still...?
Well, if you want to separately configure a given PCI-E bridge, then do
a CONFIG_MPC86xx_PCIE or something like that, but in general, PCI-E
support _is_ the same as PCI support as far as the kernel is concerned.
> > > +#ifdef CONFIG_SMP
> > > + /* Release Core 1 in boot holdoff */
> > > + mcm_paddr = get_immrbase() + MPC86xx_MCM_OFFSET;
> > > + mcm_vaddr = ioremap(mcm_paddr, MPC86xx_MCM_SIZE);
> > > +
> > > + vaddr = (unsigned long)mcm_vaddr + MCM_PORT_CONFIG_OFFSET;
> > > + out_be32((volatile unsigned *)vaddr, CPU_ALL_RELEASED);
> > > + smp_ops = &smp_8641_ops;
> > > +#endif
> > > +}
> >
> > Instead of ifdef's, just do a mpc86xx_smp_init() and put it somewhere
> > with the other SMP things in the file that contains them (and remove the
> > #ifdef's there too, just only build the file if CONFIG_SMP is set).
>
> OK, I catch your drift, but if the file is missing and
> there is a hard call to mpc86xx_smp_init() here, how is
> that resolved? Is mpc86xx_smp_init #defined empty when
> compiled non-SMP then? Like in the header file:
>
> #ifndef CONFIG_SMP
> #define mpc86xx_smp_init()
> #endif
Well, you could keep a #ifdef around the call, or you can define it as a
weak empty function
> > > +void
> > > +mpc86xx_hpcn_show_cpuinfo(struct seq_file *m)
> > > +{
> > > + uint pvid, svid, phid1;
> > > + uint memsize = total_memory;
> > > +
> > > + pvid = mfspr(SPRN_PVR);
> > > + svid = mfspr(SPRN_SVR);
> > >
> > > + seq_printf(m, "Vendor\t\t: Freescale Semiconductor\n");
> > > + seq_printf(m, "Machine\t\t: MPC86xx HPCN Board\n");
> > > + seq_printf(m, "PVR\t\t: 0x%x\n", pvid);
> > > + seq_printf(m, "SVR\t\t: 0x%x\n", svid);
> >
> > The PVR is probably a duplicate and the SVR should be added to per-cpu
> > info instead.
>
> I confess, I am not sure what you mean here. Could you
> clarify this a bit for me, or point to an example perhaps?
Well, the generic cpuinfo code already displays the PVR for each CPU and
you have a per-cpu hook you can use to display the SVR.
^ permalink raw reply
* Re: [PATCH 4/10 v2] Guard L3CR references with CPU_FTR_L3CR.
From: Benjamin Herrenschmidt @ 2006-06-09 22:07 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <E1FojPE-0004Aj-0l@jdl.com>
On Fri, 2006-06-09 at 11:00 -0500, Jon Loeliger wrote:
> So, like, the other day Benjamin Herrenschmidt mumbled:
> > On Thu, 2006-06-08 at 16:58 -0500, Jon Loeliger wrote:
> > > Signed-off-by: Jon Loeliger <jdl@freescale.com>
> >
> > Beware about this one... the CPU setup code might run before the feature
> > fixup in the future...
> > ...
> > or go read the feature bit directly in the structure
> > rather than relying on the fixup mecanism.
>
> OK.
>
> > you should probably do a separate setup function for your core
>
> Truth be told, this is a pretty generic fix for other
> parts as well. If I recall correctly, 7447, 7448, 7448A and 7450
> as well as the new 8641 now.
>
> But I can certainly introduce a new setup function here
> if you think that is the right thing to do. No problem.
No, go for the generic fix.
Ben.
^ permalink raw reply
* Re: [PATCH 3/10 v2] Add MPC8641 HPCN PCI and PCI-Express files.
From: Benjamin Herrenschmidt @ 2006-06-09 22:11 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <E1FojYV-0004O8-L0@jdl.com>
On Fri, 2006-06-09 at 11:09 -0500, Jon Loeliger wrote:
> So, like, the other day Benjamin Herrenschmidt mumbled:
> > On Thu, 2006-06-08 at 16:57 -0500, Jon Loeliger wrote:
> > > Signed-off-by: Xianghua Xiao <x.xiao@freescale.com>
> > > Signed-off-by: Wei Zhang <Wei.Zhang@freescale.com>
> > > Signed-off-by: Haiying Wang <Haiying.Wang@freescale.com>
> > > Signed-off-by: Jon Loeliger <jdl@freescale.com>
> >
> > There are various things in this code that duplicate names used by other
> > platforms and thus makes the board unsuitable for use in a common
> > kernel. That needs to be fixed. Try avoiding too generic names. Also,
> > PCI Express shall be named "pcie" and not "pex" :)
> >
> > I don't have time at the moment to go too deep in the details here.
> >
> > Ben.
>
> I will also prefix some routines with mpc86xx_ to avoid
> the generic names problems. But I'm not sure which other
> platforms you expect this one kernel image to run on.
> Specifically, this pcie code is very similar to the 8548
> family, but not exactly the same.
It's a policy. On powerpc, MULTIPLATFORM will be the default. One can
build an image that boots a powermac, a pseries and your machines. The
user doesn't _have_ to but the possibility is there. Might be useful in
the long run for embedded distros. It also force us into staying clean
and that's a good thing in general.
> My understanding is that we are shooting for a single 86xx
> family kernel image here, with this 8641 HPCN platform being
> the first such port.
>
> I will s/pex/pcie/g and rename files accordingly.
There is no compelling reason to prevent a true multiplatform kernel
since it's not a different enough CPU (like 4xx or 8xx would be), thus
it shall be in the common config. That's something that we need to fix
about Kumar couple of initial ports to arch/powerpc too.
Ben
^ permalink raw reply
* Re: booting Linux 2.6.15 using a ramdisk and greater than 512MB of DRAM
From: Wolfgang Denk @ 2006-06-09 22:41 UTC (permalink / raw)
To: Scott Coulter; +Cc: linuxppc-embedded
In-Reply-To: <43EB80E07C42E1408726E4905FB96B0466C6C0@CYBORG3.cyclone.com>
Dear Scott,
in message <43EB80E07C42E1408726E4905FB96B0466C6C0@CYBORG3.cyclone.com> you wrote:
>
> I am not sure if this is a linux question or a u-boot question. I have
> a custom MPC8540 board running U-boot 1.1.4. With a NFS root
> configuration, I have booted and run 2.6.15 with memory from 256MB to
> 2GB. If I build a ramdisk image (or even if I use the ramdisk image
> with the 85xx version of ELDK 4.0) and then combine it with the kernel
> image (vmlinux.gz) using "mkimage", the linux boot blows out with an
> oops if I boot the board with more that 512MB of DRAM. From the U-boot
Do you see something like
mem_pieces_remove: [3fe32000,3ff93ec7) not in any region
in your boot messages?
> output, it looks like the ramdisk image is getting copied to the upper
> portion of DRAM. Is it possible that the kernel doesn't map enough DRAM
> to allow the image to be read?
>
> I haven't spent a lot of time debugging this once I saw that the 512MB
> configuration worked OK. Has anyone run into this?
Yes. Normally you can use only use 0x30000000 (768MB) RAM (lowmem);
if you need more you have to change your kernel configuration,
including shifting the kernel start address.
For example, on on a 1 GB system something like this could work:
CONFIG_ADVANCED_OPTIONS=y
CONFIG_LOWMEM_SIZE_BOOL=y
CONFIG_LOWMEM_SIZE=0x40000000
CONFIG_KERNEL_START_BOOL=y
CONFIG_KERNEL_START=0xa0000000
# CONFIG_CONSISTENT_START_BOOL is not set
# CONFIG_CONSISTENT_SIZE_BOOL is not set
# CONFIG_BOOT_LOAD_BOOL is not set
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
Disobedience: The silver lining to the cloud of servitude.
- Ambrose Bierce
^ permalink raw reply
* Re: pmf_register_irq_client gives sleep with locks held warning
From: Benjamin Herrenschmidt @ 2006-06-10 0:03 UTC (permalink / raw)
To: Johannes Berg; +Cc: Andrew Morton, linuxppc-dev list
In-Reply-To: <1149793098.11525.34.camel@johannes>
On Thu, 2006-06-08 at 20:58 +0200, Johannes Berg wrote:
> On Thu, 2006-06-01 at 10:59 +1000, Benjamin Herrenschmidt wrote:
>
> > This fixes request_irq() potentially called from atomic context.
> > [...]
>
> Sorry, almost forgot about this.
>
> I don't think your patch is right, it seems to me that now
> pmf_unregister_irq_client races against pmf_do_irq: what happens when an
> interrupt comes in right in the middle of the list_del()?
Yeah, possibly... too late for 2.6.17 tho.
> By the way, what do I do when like this I change a patch? Do I rely on
> your Signed-off-by and simply put mine instead (like I did now)?
You add yours.
> Anyway, here's a changed patch that illustrates my point. I've tested it
> and it works and as expected fixes the problem :)
Too late :)
Cheers,
Ben.
> ---
> This fixes request_irq() being called with interrupts disabled in the
> powermac platform function code when registering the first irq client
> for a given platform function.
>
> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
>
> --- a/arch/powerpc/platforms/powermac/pfunc_core.c
> +++ b/arch/powerpc/platforms/powermac/pfunc_core.c
> @@ -11,6 +11,7 @@ #include <linux/delay.h>
> #include <linux/kernel.h>
> #include <linux/spinlock.h>
> #include <linux/module.h>
> +#include <linux/mutex.h>
>
> #include <asm/semaphore.h>
> #include <asm/prom.h>
> @@ -546,6 +547,7 @@ struct pmf_device {
>
> static LIST_HEAD(pmf_devices);
> static spinlock_t pmf_lock = SPIN_LOCK_UNLOCKED;
> +static DEFINE_MUTEX(pmf_irq_mutex);
>
> static void pmf_release_device(struct kref *kref)
> {
> @@ -864,16 +866,25 @@ int pmf_register_irq_client(struct devic
>
> spin_lock_irqsave(&pmf_lock, flags);
> func = __pmf_find_function(target, name, PMF_FLAGS_INT_GEN);
> - if (func == NULL) {
> - spin_unlock_irqrestore(&pmf_lock, flags);
> + if (func)
> + func = pmf_get_function(func);
> + spin_unlock_irqrestore(&pmf_lock, flags);
> + if (func == NULL)
> return -ENODEV;
> - }
> +
> + /* guard against manipulations of list */
> + mutex_lock(&pmf_irq_mutex);
> if (list_empty(&func->irq_clients))
> func->dev->handlers->irq_enable(func);
> +
> + /* guard against pmf_do_irq while changing list */
> + spin_lock_irqsave(&pmf_lock, flags);
> list_add(&client->link, &func->irq_clients);
> - client->func = func;
> spin_unlock_irqrestore(&pmf_lock, flags);
>
> + client->func = func;
> + mutex_unlock(&pmf_irq_mutex);
> +
> return 0;
> }
> EXPORT_SYMBOL_GPL(pmf_register_irq_client);
> @@ -885,12 +896,19 @@ void pmf_unregister_irq_client(struct pm
>
> BUG_ON(func == NULL);
>
> - spin_lock_irqsave(&pmf_lock, flags);
> + /* guard against manipulations of list */
> + mutex_lock(&pmf_irq_mutex);
> client->func = NULL;
> +
> + /* guard against pmf_do_irq while changing list */
> + spin_lock_irqsave(&pmf_lock, flags);
> list_del(&client->link);
> + spin_unlock_irqrestore(&pmf_lock, flags);
> +
> if (list_empty(&func->irq_clients))
> func->dev->handlers->irq_disable(func);
> - spin_unlock_irqrestore(&pmf_lock, flags);
> + mutex_unlock(&pmf_irq_mutex);
> + pmf_put_function(func);
> }
> EXPORT_SYMBOL_GPL(pmf_unregister_irq_client);
>
>
^ permalink raw reply
* Re: RFC: dma_mmap_coherent() for powerpc/ppc architecture and ALSA?
From: Benjamin Herrenschmidt @ 2006-06-10 0:34 UTC (permalink / raw)
To: Gerhard Pircher; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <20060608205048.113800@gmx.net>
> This leads me to the question, if there are any plans to include the dma_mmap_coherent() function (for powerpc/ppc and/or any other platform) in one of the next kernel versions and if an adapation of the ALSA drivers is planned. Or is there a simple way (hack) to fix this problem?
You are welcome to do a patch implementing this :)
Ben.
^ permalink raw reply
* Re: RFC: dma_mmap_coherent() for powerpc/ppc architecture and ALSA?
From: Lee Revell @ 2006-06-10 0:46 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linux-kernel, linuxppc-dev
In-Reply-To: <1149899665.12687.95.camel@localhost.localdomain>
On Sat, 2006-06-10 at 10:34 +1000, Benjamin Herrenschmidt wrote:
> > This leads me to the question, if there are any plans to include the dma_mmap_coherent() function (for powerpc/ppc and/or any other platform) in one of the next kernel versions and if an adapation of the ALSA drivers is planned. Or is there a simple way (hack) to fix this problem?
>
> You are welcome to do a patch implementing this :)
Please cc: alsa-devel when you do so.
Lee
^ permalink raw reply
* Jumbo ethernet frames on MVME6100
From: Martin, Tim @ 2006-06-10 0:57 UTC (permalink / raw)
To: linuxppc-embedded
I'm using Linux 2.6.6 with the Motorola Computer Group patch for the
MVME6100 available at
https://mcg.motorola.com/cfm/templates/swDetails.cfm?PageID=3D704&Softwar=
e
ID=3D6&ProductID=3D202
and compiling with GCC from ELDK 3.1.1, although using the userspace
module utils (e.g. insmod) from ELDK 4.0.
The patch includes support for the Marvel gigabit ethernet part on the
board (MV64360?) which works for non-jumbo ethernet frames, but doesn't
receive (or even generate errors) if I send jumbo-ethernet frames. I
haven't debugged this issue very long, but a cursory look through the
driver hints that jumbo frame support should be on (the port config
serial register PCSR has what I imagine to be okay bits).
I'm ifconfiging the 2nd ethernet device with the command
ifconfig eth1 mtu 9000 192.168.1.1
I'm wondering if anyone else using an MVME6100 has gotten jumbo frame
support to work?
Also, at what point did the Linux 2.6 kernel embedded PPC support start
working with GCC 4.x (e.g. GCC in ELDK 4.0). I'm getting compiler
errors when I use GCC 4.x with this version of the kernel.
Tim
^ permalink raw reply
* Re: [PATCH] reorg RTAS delay code
From: Anton Blanchard @ 2006-06-10 2:04 UTC (permalink / raw)
To: John Rose; +Cc: Paul Mackerras, Nathan Lynch, External List
In-Reply-To: <1149543108.17307.6.camel@sinatra.austin.ibm.com>
Hi John,
> This patch attempts to handle RTAS "busy" return codes in a more simple
> and consistent manner. Typical callers of RTAS shouldn't have to
> manage wait times and delay calls.
>
> This patch also changes the kernel to use msleep() rather than udelay()
> when a runtime delay is necessary. This will avoid CPU soft lockups
> for extended delay conditions.
Looks like you missed one:
WARNING: ".rtas_extended_busy_delay_time" [arch/powerpc/platforms/pseries/scanlog.ko] undefined!
Anton
^ permalink raw reply
* Re: [PATCH] reorg RTAS delay code
From: Anton Blanchard @ 2006-06-10 2:08 UTC (permalink / raw)
To: John Rose; +Cc: Paul Mackerras, Nathan Lynch, External List
In-Reply-To: <20060610020453.GF23891@krispykreme>
> Looks like you missed one:
>
> WARNING: ".rtas_extended_busy_delay_time" [arch/powerpc/platforms/pseries/scanlog.ko] undefined!
And a missing export:
WARNING: ".rtas_busy_delay" [arch/powerpc/kernel/rtas_flash.ko] undefined!
ANton
^ permalink raw reply
* Re: [PATCH] powerpc vdso updates
From: Anton Blanchard @ 2006-06-10 3:15 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev list, Ingo Molnar, Paul Mackerras
In-Reply-To: <1148961097.15722.11.camel@localhost.localdomain>
Hi Ben,
> This patch cleans up some locking & error handling in the ppc vdso and
> moves the vdso base pointer from the thread struct to the mm context
> where it more logically belongs. It brings the powerpc implementation
> closer to Ingo's new x86 one and also adds an arch_vma_name() function
> allowing to print [vsdo] in /proc/<pid>/maps if Ingo's x86 vdso patch is
> also applied.
Im getting this on the current powerpc git tree:
arch/powerpc/kernel/signal_32.c: In function 'handle_rt_signal':
arch/powerpc/kernel/signal_32.c:763: error: request for member
'vdso_base' in something not a structure or union
It looks like we use the mm_context_t definition in asm-ppc/mmu.h for
32bit ARCH=powerpc builds and need vdso_base there too.
Anton
^ permalink raw reply
* Re: [PATCH] powerpc vdso updates
From: Benjamin Herrenschmidt @ 2006-06-10 6:30 UTC (permalink / raw)
To: Anton Blanchard; +Cc: linuxppc-dev list, Ingo Molnar, Paul Mackerras
In-Reply-To: <20060610031543.GH23891@krispykreme>
On Sat, 2006-06-10 at 13:15 +1000, Anton Blanchard wrote:
> Hi Ben,
>
> > This patch cleans up some locking & error handling in the ppc vdso and
> > moves the vdso base pointer from the thread struct to the mm context
> > where it more logically belongs. It brings the powerpc implementation
> > closer to Ingo's new x86 one and also adds an arch_vma_name() function
> > allowing to print [vsdo] in /proc/<pid>/maps if Ingo's x86 vdso patch is
> > also applied.
>
> Im getting this on the current powerpc git tree:
>
> arch/powerpc/kernel/signal_32.c: In function 'handle_rt_signal':
> arch/powerpc/kernel/signal_32.c:763: error: request for member
> 'vdso_base' in something not a structure or union
>
> It looks like we use the mm_context_t definition in asm-ppc/mmu.h for
> 32bit ARCH=powerpc builds and need vdso_base there too.
Yes, I have a patch almost ready for that.
Ben.
^ permalink raw reply
* Re: Re: RFC: dma_mmap_coherent() for powerpc/ppc architecture and ALSA?
From: Gerhard Pircher @ 2006-06-10 8:22 UTC (permalink / raw)
To: Lee Revell, benh; +Cc: linuxppc-dev, alsa-devel, linux-kernel
> -------- Original-Nachricht --------
> Datum: Fri, 09 Jun 2006 20:46:32 -0400
> Von: Lee Revell <rlrevell@joe-job.com>
> An: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Betreff: Re: RFC: dma_mmap_coherent() for powerpc/ppc architecture and
> ALSA?
>
> On Sat, 2006-06-10 at 10:34 +1000, Benjamin Herrenschmidt wrote:
> > > This leads me to the question, if there are any plans to include the
> > > dma_mmap_coherent() function (for powerpc/ppc and/or any other
> > > platform) in one of the next kernel versions and if an adapation of
> > > the ALSA drivers is planned. Or is there a simple way (hack) to fix
> > > this problem?
> >
> > You are welcome to do a patch implementing this :)
>
> Please cc: alsa-devel when you do so.
:)
Well, implementing the dma_mmap_coherent() function isn't the problem, because it is already implemented for the ARM architecture. But as far as I understand this would require a rewrite of all the ALSA drivers (or at least a rewrite of the ALSA's DMA helper functions).
Original mail included for alsa-devel mailing list:
> I'm trying to adapt Linux for the AmigaOne, which is a G3/G4 PPC desktop
> system with a non cache coherent northbridge (MAI ArticiaS), a VIA82C686B
> southbridge and the U-boot firmware. Due to the cache coherency problem I
> compiled in the CONFIG_NOT_COHERENT_CACHE option
> (arch/ppc/kernel/dma-mapping.c) in the AmigaOne Linux kernel.
> While that fixes the DMA data corruption problem, it causes a kernel oops
> or a complete system lookup after starting sound playback. With kernel
> versions =<2.6.14 the oops messages refered to a BUG() entry in
> mm/rmap.c. Therefore I tried out a newer kernel (2.6.16.15), where the
> oops refers to the ALSA function snd_pcm_mmap_data_nopage() implemented
> in pcm_native.c.
> Well, after searching a while in some old linux kernel threads, I found
> this thread here:
> http://www.thisishull.net/showthread.php?t=22080&page=3&pp=10
> Based on the information in this thread, I came to the conclusion that
> ALSA simply won't work on non cache coherent architectures (except ARM),
> because the generic DMA API was never expanded to support the
> functionality required by ALSA (namely mapping dma pages into user space > with dma_mmap_coherent()).
> This leads me to the question, if there are any plans to include the
> dma_mmap_coherent() function (for powerpc/ppc and/or any other platform)
> in one of the next kernel versions and if an adapation of the ALSA
> drivers is planned. Or is there a simple way (hack) to fix this problem?
Gerhard
--
Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer
^ permalink raw reply
* Re: pmf_register_irq_client gives sleep with locks held warning
From: Johannes Berg @ 2006-06-10 9:27 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Andrew Morton, linuxppc-dev list
In-Reply-To: <1149897784.12687.87.camel@localhost.localdomain>
[-- Attachment #1: Type: text/plain, Size: 526 bytes --]
On Sat, 2006-06-10 at 10:03 +1000, Benjamin Herrenschmidt wrote:
> > I don't think your patch is right, it seems to me that now
> > pmf_unregister_irq_client races against pmf_do_irq: what happens when an
> > interrupt comes in right in the middle of the list_del()?
>
> Yeah, possibly... too late for 2.6.17 tho.
That's ok, we don't have any in-kernel users anyway. Alas the alsa
people will be dissatisfied because they like to ship new drivers for
old kernels or something. Oh well, I don't care.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 793 bytes --]
^ permalink raw reply
* [PATCH] powerpc: Fix pseries IOMMU allocations
From: Anton Blanchard @ 2006-06-10 10:00 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: linuxppc-dev, paulus
In-Reply-To: <20060606141135.GB6974@lst.de>
> Make sure dma_alloc_coherent allocates memory from the local node. This
> is important on Cell where we avoid going through the slow cpu
> interconnect.
>
> Note: I could only test this patch on Cell, it should be verified on
> some pseries machine by thos that have the hardware.
Looks like this patch is merged in Pauls tree and breaking pseries boot.
The patch below should fix it.
--
The arguments to alloc_pages_node were reversed, resulting in IOMMU
allocation failures. Fix it.
Signed-off-by: Anton Blanchard <anton@samba.org>
---
Index: build/arch/powerpc/kernel/iommu.c
===================================================================
--- build.orig/arch/powerpc/kernel/iommu.c 2006-06-10 19:49:51.000000000 +1000
+++ build/arch/powerpc/kernel/iommu.c 2006-06-10 19:52:12.000000000 +1000
@@ -561,7 +561,7 @@ void *iommu_alloc_coherent(struct iommu_
return NULL;
/* Alloc enough pages (and possibly more) */
- page = alloc_pages_node(flag, order, node);
+ page = alloc_pages_node(node, flag, order);
if (!page)
return NULL;
ret = page_address(page);
^ permalink raw reply
* [PATCH] powerpc: 64bit FPSCR support
From: Anton Blanchard @ 2006-06-10 10:18 UTC (permalink / raw)
To: linuxppc-dev; +Cc: paulus
Add 64bit FPSCR support. This requires a new form of mtfsf instruction.
Signed-off-by: Anton Blanchard <anton@samba.org>
---
Index: build/arch/powerpc/kernel/fpu.S
===================================================================
--- build.orig/arch/powerpc/kernel/fpu.S 2006-06-08 10:57:36.000000000 +1000
+++ build/arch/powerpc/kernel/fpu.S 2006-06-10 11:38:37.000000000 +1000
@@ -72,7 +72,7 @@ _GLOBAL(load_up_fpu)
std r12,_MSR(r1)
#endif
lfd fr0,THREAD_FPSCR(r5)
- mtfsf 0xff,fr0
+ MTFSF_L(fr0)
REST_32FPRS(0, r5)
#ifndef CONFIG_SMP
subi r4,r5,THREAD
@@ -127,7 +127,7 @@ _GLOBAL(giveup_fpu)
_GLOBAL(cvt_fd)
lfd 0,THREAD_FPSCR(r5) /* load up fpscr value */
- mtfsf 0xff,0
+ MTFSF_L(0)
lfs 0,0(r3)
stfd 0,0(r4)
mffs 0
@@ -136,7 +136,7 @@ _GLOBAL(cvt_fd)
_GLOBAL(cvt_df)
lfd 0,THREAD_FPSCR(r5) /* load up fpscr value */
- mtfsf 0xff,0
+ MTFSF_L(0)
lfd 0,0(r3)
stfs 0,0(r4)
mffs 0
Index: build/arch/powerpc/kernel/vector.S
===================================================================
--- build.orig/arch/powerpc/kernel/vector.S 2006-06-08 10:57:36.000000000 +1000
+++ build/arch/powerpc/kernel/vector.S 2006-06-10 11:38:37.000000000 +1000
@@ -53,12 +53,12 @@ fpenable:
stfd fr31,8(r1)
LDCONST(fr1, fpzero)
mffs fr31
- mtfsf 0xff,fr1
+ MTFSF_L(fr1)
blr
fpdisable:
mtlr r12
- mtfsf 0xff,fr31
+ MTFSF_L(fr31)
lfd fr31,8(r1)
lfd fr1,16(r1)
lfd fr0,24(r1)
Index: build/include/asm-powerpc/reg.h
===================================================================
--- build.orig/include/asm-powerpc/reg.h 2006-06-10 11:37:33.000000000 +1000
+++ build/include/asm-powerpc/reg.h 2006-06-10 11:38:37.000000000 +1000
@@ -499,6 +499,19 @@
#define MMCR0_PMC2_LOADMISSTIME 0x5
#endif
+/*
+ * An mtfsf instruction with the L bit set. On CPUs that support this a
+ * full 64bits of FPSCR is restored and on other CPUs it is ignored.
+ *
+ * Until binutils gets the new form of mtfsf, hardwire the instruction.
+ */
+#ifdef CONFIG_PPC64
+#define MTFSF_L(REG) \
+ .long (0xfc00058e | ((0xff) << 17) | ((REG) << 11) | (1 << 25))
+#else
+#define MTFSF_L(REG) mtfsf 0xff, (REG)
+#endif
+
/* Processor Version Register (PVR) field extraction */
#define PVR_VER(pvr) (((pvr) >> 16) & 0xFFFF) /* Version field */
^ permalink raw reply
* [PATCH] powerpc: Optimise some TOC usage
From: Anton Blanchard @ 2006-06-10 10:23 UTC (permalink / raw)
To: linuxppc-dev; +Cc: paulus
Micro-optimisation - add no-minimal-toc to some more arch/powerpc Makefiles.
Signed-off-by: Anton Blanchard <anton@samba.org>
---
Index: build/arch/powerpc/lib/Makefile
===================================================================
--- build.orig/arch/powerpc/lib/Makefile 2006-05-27 09:52:19.000000000 +1000
+++ build/arch/powerpc/lib/Makefile 2006-05-27 09:52:27.000000000 +1000
@@ -2,6 +2,10 @@
# Makefile for ppc-specific library files..
#
+ifeq ($(CONFIG_PPC64),y)
+EXTRA_CFLAGS += -mno-minimal-toc
+endif
+
ifeq ($(CONFIG_PPC_MERGE),y)
obj-y := string.o strcase.o
obj-$(CONFIG_PPC32) += div64.o copy_32.o checksum_32.o
Index: build/arch/powerpc/oprofile/Makefile
===================================================================
--- build.orig/arch/powerpc/oprofile/Makefile 2006-05-27 09:52:19.000000000 +1000
+++ build/arch/powerpc/oprofile/Makefile 2006-05-27 09:52:27.000000000 +1000
@@ -1,3 +1,7 @@
+ifeq ($(CONFIG_PPC64),y)
+EXTRA_CFLAGS += -mno-minimal-toc
+endif
+
obj-$(CONFIG_OPROFILE) += oprofile.o
DRIVER_OBJS := $(addprefix ../../../drivers/oprofile/, \
Index: build/arch/powerpc/sysdev/Makefile
===================================================================
--- build.orig/arch/powerpc/sysdev/Makefile 2006-05-27 09:52:19.000000000 +1000
+++ build/arch/powerpc/sysdev/Makefile 2006-05-27 09:52:27.000000000 +1000
@@ -1,3 +1,7 @@
+ifeq ($(CONFIG_PPC64),y)
+EXTRA_CFLAGS += -mno-minimal-toc
+endif
+
obj-$(CONFIG_MPIC) += mpic.o
obj-$(CONFIG_PPC_INDIRECT_PCI) += indirect_pci.o
obj-$(CONFIG_PPC_I8259) += i8259.o
Index: build/arch/powerpc/platforms/pseries/Makefile
===================================================================
--- build.orig/arch/powerpc/platforms/pseries/Makefile 2006-05-27 09:52:19.000000000 +1000
+++ build/arch/powerpc/platforms/pseries/Makefile 2006-05-27 09:52:27.000000000 +1000
@@ -1,3 +1,7 @@
+ifeq ($(CONFIG_PPC64),y)
+EXTRA_CFLAGS += -mno-minimal-toc
+endif
+
obj-y := pci.o lpar.o hvCall.o nvram.o reconfig.o \
setup.o iommu.o ras.o rtasd.o pci_dlpar.o \
firmware.o
^ permalink raw reply
* [PATCH] powerpc: Remove stale 64bit on 32bit kernel code
From: Anton Blanchard @ 2006-06-10 10:32 UTC (permalink / raw)
To: linuxppc-dev; +Cc: paulus
Remove some stale POWER3/POWER4/970 on 32bit kernel support.
Signed-off-by: Anton Blanchard <anton@samba.org>
---
Index: build/arch/powerpc/kernel/cputable.c
===================================================================
--- build.orig/arch/powerpc/kernel/cputable.c 2006-06-10 11:37:31.000000000 +1000
+++ build/arch/powerpc/kernel/cputable.c 2006-06-10 11:39:51.000000000 +1000
@@ -189,17 +189,11 @@ struct cpu_spec cpu_specs[] = {
.oprofile_type = PPC_OPROFILE_POWER4,
.platform = "ppc970",
},
-#endif /* CONFIG_PPC64 */
-#if defined(CONFIG_PPC64) || defined(CONFIG_POWER4)
{ /* PPC970FX */
.pvr_mask = 0xffff0000,
.pvr_value = 0x003c0000,
.cpu_name = "PPC970FX",
-#ifdef CONFIG_PPC32
- .cpu_features = CPU_FTRS_970_32,
-#else
.cpu_features = CPU_FTRS_PPC970,
-#endif
.cpu_user_features = COMMON_USER_POWER4 |
PPC_FEATURE_HAS_ALTIVEC_COMP,
.icache_bsize = 128,
@@ -210,8 +204,6 @@ struct cpu_spec cpu_specs[] = {
.oprofile_type = PPC_OPROFILE_POWER4,
.platform = "ppc970",
},
-#endif /* defined(CONFIG_PPC64) || defined(CONFIG_POWER4) */
-#ifdef CONFIG_PPC64
{ /* PPC970MP */
.pvr_mask = 0xffff0000,
.pvr_value = 0x00440000,
Index: build/include/asm-powerpc/cputable.h
===================================================================
--- build.orig/include/asm-powerpc/cputable.h 2006-06-10 11:37:33.000000000 +1000
+++ build/include/asm-powerpc/cputable.h 2006-06-10 11:39:51.000000000 +1000
@@ -300,13 +300,6 @@ extern void do_cpu_ftr_fixups(unsigned l
CPU_FTR_COMMON)
#define CPU_FTRS_CLASSIC32 (CPU_FTR_COMMON | CPU_FTR_SPLIT_ID_CACHE | \
CPU_FTR_USE_TB | CPU_FTR_HPTE_TABLE)
-#define CPU_FTRS_POWER3_32 (CPU_FTR_COMMON | CPU_FTR_SPLIT_ID_CACHE | \
- CPU_FTR_USE_TB | CPU_FTR_HPTE_TABLE)
-#define CPU_FTRS_POWER4_32 (CPU_FTR_COMMON | CPU_FTR_SPLIT_ID_CACHE | \
- CPU_FTR_USE_TB | CPU_FTR_HPTE_TABLE | CPU_FTR_NODSISRALIGN)
-#define CPU_FTRS_970_32 (CPU_FTR_COMMON | CPU_FTR_SPLIT_ID_CACHE | \
- CPU_FTR_USE_TB | CPU_FTR_HPTE_TABLE | CPU_FTR_ALTIVEC_COMP | \
- CPU_FTR_MAYBE_CAN_NAP | CPU_FTR_NODSISRALIGN)
#define CPU_FTRS_8XX (CPU_FTR_SPLIT_ID_CACHE | CPU_FTR_USE_TB)
#define CPU_FTRS_40X (CPU_FTR_SPLIT_ID_CACHE | CPU_FTR_USE_TB | \
CPU_FTR_NODSISRALIGN)
@@ -367,12 +360,6 @@ enum {
#else
CPU_FTRS_GENERIC_32 |
#endif
-#ifdef CONFIG_PPC64BRIDGE
- CPU_FTRS_POWER3_32 |
-#endif
-#ifdef CONFIG_POWER4
- CPU_FTRS_POWER4_32 | CPU_FTRS_970_32 |
-#endif
#ifdef CONFIG_8xx
CPU_FTRS_8XX |
#endif
@@ -412,12 +399,6 @@ enum {
#else
CPU_FTRS_GENERIC_32 &
#endif
-#ifdef CONFIG_PPC64BRIDGE
- CPU_FTRS_POWER3_32 &
-#endif
-#ifdef CONFIG_POWER4
- CPU_FTRS_POWER4_32 & CPU_FTRS_970_32 &
-#endif
#ifdef CONFIG_8xx
CPU_FTRS_8XX &
#endif
Index: build/arch/powerpc/Makefile
===================================================================
--- build.orig/arch/powerpc/Makefile 2006-06-10 11:36:57.000000000 +1000
+++ build/arch/powerpc/Makefile 2006-06-10 11:39:51.000000000 +1000
@@ -108,7 +108,6 @@ ifeq ($(CONFIG_6xx),y)
CFLAGS += -mcpu=powerpc
endif
-cpu-as-$(CONFIG_PPC64BRIDGE) += -Wa,-mppc64bridge
cpu-as-$(CONFIG_4xx) += -Wa,-m405
cpu-as-$(CONFIG_6xx) += -Wa,-maltivec
cpu-as-$(CONFIG_POWER4) += -Wa,-maltivec
Index: build/arch/powerpc/mm/hash_low_32.S
===================================================================
--- build.orig/arch/powerpc/mm/hash_low_32.S 2006-06-10 11:36:57.000000000 +1000
+++ build/arch/powerpc/mm/hash_low_32.S 2006-06-10 11:39:51.000000000 +1000
@@ -74,12 +74,6 @@ _GLOBAL(hash_page_sync)
*/
.text
_GLOBAL(hash_page)
-#ifdef CONFIG_PPC64BRIDGE
- mfmsr r0
- clrldi r0,r0,1 /* make sure it's in 32-bit mode */
- MTMSRD(r0)
- isync
-#endif
tophys(r7,0) /* gets -KERNELBASE into r7 */
#ifdef CONFIG_SMP
addis r8,r7,mmu_hash_lock@h
@@ -285,7 +279,6 @@ Hash_base = 0xc0180000
Hash_bits = 12 /* e.g. 256kB hash table */
Hash_msk = (((1 << Hash_bits) - 1) * 64)
-#ifndef CONFIG_PPC64BRIDGE
/* defines for the PTE format for 32-bit PPCs */
#define PTE_SIZE 8
#define PTEG_SIZE 64
@@ -299,21 +292,6 @@ Hash_msk = (((1 << Hash_bits) - 1) * 64)
#define SET_V(r) oris r,r,PTE_V@h
#define CLR_V(r,t) rlwinm r,r,0,1,31
-#else
-/* defines for the PTE format for 64-bit PPCs */
-#define PTE_SIZE 16
-#define PTEG_SIZE 128
-#define LG_PTEG_SIZE 7
-#define LDPTEu ldu
-#define STPTE std
-#define CMPPTE cmpd
-#define PTE_H 2
-#define PTE_V 1
-#define TST_V(r) andi. r,r,PTE_V
-#define SET_V(r) ori r,r,PTE_V
-#define CLR_V(r,t) li t,PTE_V; andc r,r,t
-#endif /* CONFIG_PPC64BRIDGE */
-
#define HASH_LEFT 31-(LG_PTEG_SIZE+Hash_bits-1)
#define HASH_RIGHT 31-LG_PTEG_SIZE
@@ -331,14 +309,8 @@ BEGIN_FTR_SECTION
END_FTR_SECTION_IFSET(CPU_FTR_NEED_COHERENT)
/* Construct the high word of the PPC-style PTE (r5) */
-#ifndef CONFIG_PPC64BRIDGE
rlwinm r5,r3,7,1,24 /* put VSID in 0x7fffff80 bits */
rlwimi r5,r4,10,26,31 /* put in API (abbrev page index) */
-#else /* CONFIG_PPC64BRIDGE */
- clrlwi r3,r3,8 /* reduce vsid to 24 bits */
- sldi r5,r3,12 /* shift vsid into position */
- rlwimi r5,r4,16,20,24 /* put in API (abbrev page index) */
-#endif /* CONFIG_PPC64BRIDGE */
SET_V(r5) /* set V (valid) bit */
/* Get the address of the primary PTE group in the hash table (r3) */
@@ -516,14 +488,8 @@ _GLOBAL(flush_hash_pages)
add r3,r3,r0 /* note code below trims to 24 bits */
/* Construct the high word of the PPC-style PTE (r11) */
-#ifndef CONFIG_PPC64BRIDGE
rlwinm r11,r3,7,1,24 /* put VSID in 0x7fffff80 bits */
rlwimi r11,r4,10,26,31 /* put in API (abbrev page index) */
-#else /* CONFIG_PPC64BRIDGE */
- clrlwi r3,r3,8 /* reduce vsid to 24 bits */
- sldi r11,r3,12 /* shift vsid into position */
- rlwimi r11,r4,16,20,24 /* put in API (abbrev page index) */
-#endif /* CONFIG_PPC64BRIDGE */
SET_V(r11) /* set V (valid) bit */
#ifdef CONFIG_SMP
Index: build/arch/powerpc/mm/ppc_mmu_32.c
===================================================================
--- build.orig/arch/powerpc/mm/ppc_mmu_32.c 2006-06-10 11:36:57.000000000 +1000
+++ build/arch/powerpc/mm/ppc_mmu_32.c 2006-06-10 11:39:51.000000000 +1000
@@ -42,11 +42,7 @@ unsigned long _SDR1;
union ubat { /* BAT register values to be loaded */
BAT bat;
-#ifdef CONFIG_PPC64BRIDGE
- u64 word[2];
-#else
u32 word[2];
-#endif
} BATS[4][2]; /* 4 pairs of IBAT, DBAT */
struct batrange { /* stores address ranges mapped by BATs */
@@ -220,15 +216,9 @@ void __init MMU_init_hw(void)
if ( ppc_md.progress ) ppc_md.progress("hash:enter", 0x105);
-#ifdef CONFIG_PPC64BRIDGE
-#define LG_HPTEG_SIZE 7 /* 128 bytes per HPTEG */
-#define SDR1_LOW_BITS (lg_n_hpteg - 11)
-#define MIN_N_HPTEG 2048 /* min 256kB hash table */
-#else
#define LG_HPTEG_SIZE 6 /* 64 bytes per HPTEG */
#define SDR1_LOW_BITS ((n_hpteg - 1) >> 10)
#define MIN_N_HPTEG 1024 /* min 64kB hash table */
-#endif
/*
* Allow 1 HPTE (1/8 HPTEG) for each page of memory.
Index: build/include/asm-ppc/mmu.h
===================================================================
--- build.orig/include/asm-ppc/mmu.h 2006-06-10 11:36:57.000000000 +1000
+++ build/include/asm-ppc/mmu.h 2006-06-10 11:39:51.000000000 +1000
@@ -29,20 +29,11 @@ typedef unsigned long mm_context_t;
/* Hardware Page Table Entry */
typedef struct _PTE {
-#ifdef CONFIG_PPC64BRIDGE
- unsigned long long vsid:52;
- unsigned long api:5;
- unsigned long :5;
- unsigned long h:1;
- unsigned long v:1;
- unsigned long long rpn:52;
-#else /* CONFIG_PPC64BRIDGE */
unsigned long v:1; /* Entry is valid */
unsigned long vsid:24; /* Virtual segment identifier */
unsigned long h:1; /* Hash algorithm indicator */
unsigned long api:6; /* Abbreviated page index */
unsigned long rpn:20; /* Real (physical) page number */
-#endif /* CONFIG_PPC64BRIDGE */
unsigned long :3; /* Unused */
unsigned long r:1; /* Referenced */
unsigned long c:1; /* Changed */
@@ -83,11 +74,7 @@ typedef struct _P601_BATU { /* Upper par
} P601_BATU;
typedef struct _BATU { /* Upper part of BAT (all except 601) */
-#ifdef CONFIG_PPC64BRIDGE
- unsigned long long bepi:47;
-#else /* CONFIG_PPC64BRIDGE */
unsigned long bepi:15; /* Effective page index (virtual address) */
-#endif /* CONFIG_PPC64BRIDGE */
unsigned long :4; /* Unused */
unsigned long bl:11; /* Block size mask */
unsigned long vs:1; /* Supervisor valid */
@@ -102,11 +89,7 @@ typedef struct _P601_BATL { /* Lower par
} P601_BATL;
typedef struct _BATL { /* Lower part of BAT (all except 601) */
-#ifdef CONFIG_PPC64BRIDGE
- unsigned long long brpn:47;
-#else /* CONFIG_PPC64BRIDGE */
unsigned long brpn:15; /* Real page index (physical address) */
-#endif /* CONFIG_PPC64BRIDGE */
unsigned long :10; /* Unused */
unsigned long w:1; /* Write-thru cache */
unsigned long i:1; /* Cache inhibit */
Index: build/arch/um/sys-ppc/misc.S
===================================================================
--- build.orig/arch/um/sys-ppc/misc.S 2006-06-10 11:36:57.000000000 +1000
+++ build/arch/um/sys-ppc/misc.S 2006-06-10 11:39:51.000000000 +1000
@@ -23,14 +23,10 @@
#define CACHE_LINE_SIZE 16
#define LG_CACHE_LINE_SIZE 4
#define MAX_COPY_PREFETCH 1
-#elif !defined(CONFIG_PPC64BRIDGE)
+#else
#define CACHE_LINE_SIZE 32
#define LG_CACHE_LINE_SIZE 5
#define MAX_COPY_PREFETCH 4
-#else
-#define CACHE_LINE_SIZE 128
-#define LG_CACHE_LINE_SIZE 7
-#define MAX_COPY_PREFETCH 1
#endif /* CONFIG_4xx || CONFIG_8xx */
.text
^ permalink raw reply
* [PATCH] powerpc: Update pseries defconfig
From: Anton Blanchard @ 2006-06-10 10:37 UTC (permalink / raw)
To: linuxppc-dev; +Cc: paulus
pseries defconfig updates:
- Enable jsm and re-enable qlogic FC drivers as modules.
- Enable ocfs2, autofs4 and fuse filesystems as modules.
- Enable Kprobes.
- Enable ebus, binfmt_misc, sas attrs, md5 reshape, hvc rtas backend and
some infiniband options.
- Finally disable debug options: DEBUG_MUTEXES and DEBUG_STACK_USAGE.
Signed-off-by: Anton Blanchard <anton@samba.org>
---
Index: build/arch/powerpc/configs/pseries_defconfig
===================================================================
--- build.orig/arch/powerpc/configs/pseries_defconfig 2006-05-28 07:36:12.000000000 +1000
+++ build/arch/powerpc/configs/pseries_defconfig 2006-05-28 07:36:31.000000000 +1000
@@ -1,7 +1,7 @@
#
# Automatically generated make config: don't edit
-# Linux kernel version: 2.6.17-rc1
-# Wed Apr 19 11:48:00 2006
+# Linux kernel version: 2.6.17-rc4
+# Sun May 28 07:26:56 2006
#
CONFIG_PPC64=y
CONFIG_64BIT=y
@@ -11,6 +11,7 @@ CONFIG_GENERIC_HARDIRQS=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
+CONFIG_GENERIC_FIND_NEXT_BIT=y
CONFIG_PPC=y
CONFIG_EARLY_PRINTK=y
CONFIG_COMPAT=y
@@ -126,8 +127,9 @@ CONFIG_RTAS_PROC=y
CONFIG_RTAS_FLASH=m
# CONFIG_MMIO_NVRAM is not set
CONFIG_IBMVIO=y
-# CONFIG_IBMEBUS is not set
+CONFIG_IBMEBUS=y
# CONFIG_PPC_MPC106 is not set
+# CONFIG_PPC_970_NAP is not set
# CONFIG_CPU_FREQ is not set
# CONFIG_WANT_EARLY_SERIAL is not set
@@ -143,7 +145,7 @@ CONFIG_PREEMPT_NONE=y
# CONFIG_PREEMPT is not set
# CONFIG_PREEMPT_BKL is not set
CONFIG_BINFMT_ELF=y
-# CONFIG_BINFMT_MISC is not set
+CONFIG_BINFMT_MISC=m
CONFIG_FORCE_MAX_ZONEORDER=13
CONFIG_IOMMU_VMERGE=y
CONFIG_HOTPLUG_CPU=y
@@ -155,6 +157,7 @@ CONFIG_EEH=y
CONFIG_SCANLOG=m
CONFIG_LPARCFG=y
CONFIG_NUMA=y
+CONFIG_NODES_SHIFT=4
CONFIG_ARCH_SELECT_MEMORY_MODEL=y
CONFIG_ARCH_SPARSEMEM_ENABLE=y
CONFIG_ARCH_SPARSEMEM_DEFAULT=y
@@ -467,7 +470,7 @@ CONFIG_SCSI_CONSTANTS=y
CONFIG_SCSI_SPI_ATTRS=y
CONFIG_SCSI_FC_ATTRS=y
CONFIG_SCSI_ISCSI_ATTRS=m
-# CONFIG_SCSI_SAS_ATTRS is not set
+CONFIG_SCSI_SAS_ATTRS=m
#
# SCSI low-level drivers
@@ -499,13 +502,18 @@ CONFIG_SCSI_SYM53C8XX_2=y
CONFIG_SCSI_SYM53C8XX_DMA_ADDRESSING_MODE=0
CONFIG_SCSI_SYM53C8XX_DEFAULT_TAGS=16
CONFIG_SCSI_SYM53C8XX_MAX_TAGS=64
-# CONFIG_SCSI_SYM53C8XX_IOMAPPED is not set
+CONFIG_SCSI_SYM53C8XX_MMIO=y
CONFIG_SCSI_IPR=y
CONFIG_SCSI_IPR_TRACE=y
CONFIG_SCSI_IPR_DUMP=y
-# CONFIG_SCSI_QLOGIC_FC is not set
# CONFIG_SCSI_QLOGIC_1280 is not set
-# CONFIG_SCSI_QLA_FC is not set
+CONFIG_SCSI_QLA_FC=m
+CONFIG_SCSI_QLA2XXX_EMBEDDED_FIRMWARE=y
+CONFIG_SCSI_QLA21XX=m
+CONFIG_SCSI_QLA22XX=m
+CONFIG_SCSI_QLA2300=m
+CONFIG_SCSI_QLA2322=m
+CONFIG_SCSI_QLA24XX=m
CONFIG_SCSI_LPFC=m
# CONFIG_SCSI_DC395x is not set
# CONFIG_SCSI_DC390T is not set
@@ -521,7 +529,7 @@ CONFIG_MD_RAID0=y
CONFIG_MD_RAID1=y
CONFIG_MD_RAID10=m
CONFIG_MD_RAID5=y
-# CONFIG_MD_RAID5_RESHAPE is not set
+CONFIG_MD_RAID5_RESHAPE=y
CONFIG_MD_RAID6=m
CONFIG_MD_MULTIPATH=m
CONFIG_MD_FAULTY=m
@@ -764,7 +772,7 @@ CONFIG_SERIAL_8250_RUNTIME_UARTS=4
CONFIG_SERIAL_CORE=y
CONFIG_SERIAL_CORE_CONSOLE=y
CONFIG_SERIAL_ICOM=m
-# CONFIG_SERIAL_JSM is not set
+CONFIG_SERIAL_JSM=m
CONFIG_UNIX98_PTYS=y
CONFIG_LEGACY_PTYS=y
CONFIG_LEGACY_PTY_COUNT=256
@@ -773,7 +781,7 @@ CONFIG_LEGACY_PTY_COUNT=256
# CONFIG_TIPAR is not set
CONFIG_HVC_DRIVER=y
CONFIG_HVC_CONSOLE=y
-# CONFIG_HVC_RTAS is not set
+CONFIG_HVC_RTAS=y
CONFIG_HVCS=m
#
@@ -1031,9 +1039,7 @@ CONFIG_USB_HIDDEV=y
# CONFIG_USB_ACECAD is not set
# CONFIG_USB_KBTAB is not set
# CONFIG_USB_POWERMATE is not set
-# CONFIG_USB_MTOUCH is not set
-# CONFIG_USB_ITMTOUCH is not set
-# CONFIG_USB_EGALAX is not set
+# CONFIG_USB_TOUCHSCREEN is not set
# CONFIG_USB_YEALINK is not set
# CONFIG_USB_XPAD is not set
# CONFIG_USB_ATI_REMOTE is not set
@@ -1105,16 +1111,25 @@ CONFIG_USB_MON=y
# CONFIG_NEW_LEDS is not set
#
+# LED drivers
+#
+
+#
+# LED Triggers
+#
+
+#
# InfiniBand support
#
CONFIG_INFINIBAND=m
-# CONFIG_INFINIBAND_USER_MAD is not set
-# CONFIG_INFINIBAND_USER_ACCESS is not set
+CONFIG_INFINIBAND_USER_MAD=m
+CONFIG_INFINIBAND_USER_ACCESS=m
CONFIG_INFINIBAND_MTHCA=m
-# CONFIG_INFINIBAND_MTHCA_DEBUG is not set
+CONFIG_INFINIBAND_MTHCA_DEBUG=y
CONFIG_INFINIBAND_IPOIB=m
-# CONFIG_INFINIBAND_IPOIB_DEBUG is not set
-# CONFIG_INFINIBAND_SRP is not set
+CONFIG_INFINIBAND_IPOIB_DEBUG=y
+# CONFIG_INFINIBAND_IPOIB_DEBUG_DATA is not set
+CONFIG_INFINIBAND_SRP=m
#
# EDAC - error detection and reporting (RAS) (EXPERIMENTAL)
@@ -1159,15 +1174,15 @@ CONFIG_XFS_EXPORT=y
CONFIG_XFS_SECURITY=y
CONFIG_XFS_POSIX_ACL=y
# CONFIG_XFS_RT is not set
-# CONFIG_OCFS2_FS is not set
+CONFIG_OCFS2_FS=m
# CONFIG_MINIX_FS is not set
# CONFIG_ROMFS_FS is not set
CONFIG_INOTIFY=y
# CONFIG_QUOTA is not set
CONFIG_DNOTIFY=y
-CONFIG_AUTOFS_FS=m
-# CONFIG_AUTOFS4_FS is not set
-# CONFIG_FUSE_FS is not set
+# CONFIG_AUTOFS_FS is not set
+CONFIG_AUTOFS4_FS=m
+CONFIG_FUSE_FS=m
#
# CD-ROM/DVD Filesystems
@@ -1199,7 +1214,7 @@ CONFIG_TMPFS=y
CONFIG_HUGETLBFS=y
CONFIG_HUGETLB_PAGE=y
CONFIG_RAMFS=y
-# CONFIG_CONFIGFS_FS is not set
+CONFIG_CONFIGFS_FS=m
#
# Miscellaneous filesystems
@@ -1317,7 +1332,7 @@ CONFIG_ZLIB_DEFLATE=m
#
CONFIG_PROFILING=y
CONFIG_OPROFILE=y
-# CONFIG_KPROBES is not set
+CONFIG_KPROBES=y
#
# Kernel hacking
@@ -1329,7 +1344,7 @@ CONFIG_LOG_BUF_SHIFT=17
CONFIG_DETECT_SOFTLOCKUP=y
# CONFIG_SCHEDSTATS is not set
# CONFIG_DEBUG_SLAB is not set
-CONFIG_DEBUG_MUTEXES=y
+# CONFIG_DEBUG_MUTEXES is not set
# CONFIG_DEBUG_SPINLOCK is not set
# CONFIG_DEBUG_SPINLOCK_SLEEP is not set
# CONFIG_DEBUG_KOBJECT is not set
@@ -1339,17 +1354,13 @@ CONFIG_DEBUG_FS=y
CONFIG_FORCED_INLINING=y
# CONFIG_RCU_TORTURE_TEST is not set
CONFIG_DEBUG_STACKOVERFLOW=y
-CONFIG_DEBUG_STACK_USAGE=y
+# CONFIG_DEBUG_STACK_USAGE is not set
CONFIG_DEBUGGER=y
CONFIG_XMON=y
CONFIG_XMON_DEFAULT=y
CONFIG_IRQSTACKS=y
# CONFIG_BOOTX_TEXT is not set
-# CONFIG_PPC_EARLY_DEBUG_LPAR is not set
-# CONFIG_PPC_EARLY_DEBUG_G5 is not set
-# CONFIG_PPC_EARLY_DEBUG_RTAS is not set
-# CONFIG_PPC_EARLY_DEBUG_MAPLE is not set
-# CONFIG_PPC_EARLY_DEBUG_ISERIES is not set
+# CONFIG_PPC_EARLY_DEBUG is not set
#
# Security options
^ 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