* Re: [PATCH] Handle I-TLB Error and Miss separately on 8xx
From: Tom Rini @ 2005-01-12 14:06 UTC (permalink / raw)
To: Joakim Tjernlund; +Cc: Linuxppc-Embedded@Ozlabs. Org
In-Reply-To: <JPEALJAFNGDDLOPNDIEEMEPMCPAA.joakim.tjernlund@lumentis.se>
On Wed, Jan 12, 2005 at 08:53:17AM +0100, Joakim Tjernlund wrote:
> > As the code stands currently, there is a bug in the 2.4 and 2.6 handling
> > of I-TLB Miss and Error exceptions on 8xx. The problem is that since we
> > treat both of them as the same exception when we hit do_page_fault,
> > there is a case where we can incorrectly find that a protection fault
> > has occured, when it hasn't. This is because we check bit 4 of SRR1 in
> > both cases, but in the case of an I-TLB Miss, this bit is always set,
> > and it only indicates a protection fault on an I-TLB Error.
>
> Patch looks good to me, but I want to ask when this error
> can be triggered in practice?
It is possible to see this in the real world, as we (<hat=mvista>) found
this with a customers app.
--
Tom Rini
http://gate.crashing.org/~trini/
^ permalink raw reply
* RE: [PATCH] Handle I-TLB Error and Miss separately on 8xx
From: Joakim Tjernlund @ 2005-01-12 14:17 UTC (permalink / raw)
To: Tom Rini; +Cc: Linuxppc-Embedded@Ozlabs. Org
In-Reply-To: <20050112140630.GP3391@smtp.west.cox.net>
> On Wed, Jan 12, 2005 at 08:53:17AM +0100, Joakim Tjernlund wrote:
> > > As the code stands currently, there is a bug in the 2.4 and 2.6 handling
> > > of I-TLB Miss and Error exceptions on 8xx. The problem is that since we
> > > treat both of them as the same exception when we hit do_page_fault,
> > > there is a case where we can incorrectly find that a protection fault
> > > has occured, when it hasn't. This is because we check bit 4 of SRR1 in
> > > both cases, but in the case of an I-TLB Miss, this bit is always set,
> > > and it only indicates a protection fault on an I-TLB Error.
> >
> > Patch looks good to me, but I want to ask when this error
> > can be triggered in practice?
>
> It is possible to see this in the real world, as we (<hat=mvista>) found
> this with a customers app.
hmm, this app must have been doing something pretty special. Any idea what
caused it?
Jocke
^ permalink raw reply
* Re: Kernel 2.6.10 running on mpc8272ads
From: Tom Rini @ 2005-01-12 14:19 UTC (permalink / raw)
To: Dan Malek; +Cc: alebas, linuxppc-embedded
In-Reply-To: <71A72D18-5F4C-11D9-A045-003065F9B7DC@embeddededge.com>
On Wed, Jan 05, 2005 at 02:03:11PM -0500, Dan Malek wrote:
>
> On Jan 5, 2005, at 12:48 PM, Tom Rini wrote:
>
> >Indeed. While I had a PQ2FADS for a bit, I had to do that as well.
> >Kumar, what/why is that needed exactly? Did I screw up in re-working
> >the 82xx init stuff and it needs to happen a bit later in boot?
>
> I don't understand the what/why question, but that has never stopped
> me from providing answers in the past :-)
Ha!
> So, In 2.6, and I think in some of the 2.4 cpm2 stuff, we no longer
> automatically map any of the hardware IO resources for common
> access like I used to do in the past. If you want to access the
> BCSR, you need to make sure it is ioremap()'ed in your driver before
> you make the access. Was that the question, or was it that
> the BCSR should have been set someplace outside of the
> driver for the serial port to work?
Actually, I did break it. When I re-worked the hooks around
platform_init/ppc_md.setup_arch, I added a call-out from platform_init()
but not from m82xx_setup_arch(), when I really needed one. I'll follow
up with a patch momentarily.
--
Tom Rini
http://gate.crashing.org/~trini/
^ permalink raw reply
* [PATCH 2.6.10] ppc32: Fix mpc8272ads
From: Tom Rini @ 2005-01-12 14:22 UTC (permalink / raw)
To: Andrew Morton; +Cc: alebas, linuxppc-embedded
In-Reply-To: <20050112141902.GQ3391@smtp.west.cox.net>
When I reworked the m82xx init functions, I inadvertantly broke the
callout we had from ppc_md.setup_arch() that boards can use to poke &
prod things, once mappings are set. The following adds in a callback
and updates the one m82xx board that needs it.
Signed-off-by: Tom Rini <trini@kernel.crashing.org>
--- 1.28/arch/ppc/syslib/m8260_setup.c 2004-11-24 23:42:43 -07:00
+++ edited/arch/ppc/syslib/m8260_setup.c 2005-01-12 07:18:14 -07:00
@@ -37,6 +37,12 @@
extern void m8260_find_bridges(void);
extern void idma_pci9_init(void);
+/* Place-holder for board-specific init */
+void __attribute__ ((weak)) __init
+m82xx_board_setup(void)
+{
+}
+
static void __init
m8260_setup_arch(void)
{
@@ -56,6 +62,7 @@
if (initrd_start)
ROOT_DEV = Root_RAM0;
#endif
+ m82xx_board_setup();
}
/* The decrementer counts at the system (internal) clock frequency
@@ -203,7 +210,7 @@
io_block_mapping(IO_VIRT_ADDR, IO_PHYS_ADDR, 0x10000000, _PAGE_IO);
}
-/* Place-holder for board-specific init */
+/* Place-holder for board-specific ppc_md hooking */
void __attribute__ ((weak)) __init
m82xx_board_init(void)
{
--- 1.6/arch/ppc/platforms/pq2ads.c 2004-08-13 16:33:54 -07:00
+++ edited/arch/ppc/platforms/pq2ads.c 2005-01-10 16:32:52 -07:00
@@ -19,8 +19,8 @@
#include <asm/mpc8260.h>
void __init
-m82xx_board_init(void)
+m82xx_board_setup(void)
{
/* Enable the 2nd UART port */
- *(volatile uint *)(BCSR_ADDR + 4) &= ~BCSR1_RS232_EN2;
+ *(volatile uint *)(BCSR_ADDR + 4) &= ~BCSR1_RS232_EN2;
}
--
Tom Rini
http://gate.crashing.org/~trini/
^ permalink raw reply
* Re: Some issues with kernel 2.6 for MPC8260 target
From: Saso Kavcic @ 2005-01-12 14:27 UTC (permalink / raw)
To: Steven Blakeslee; +Cc: linuxppc-embedded
In-Reply-To: <1628E43D99629C46988BE46087A3FBB912F207@ep-01.EmbeddedPlanet.local>
Hi Steven,
Have you noticed any improvements in 2.6.10. over 2.6.9? We were porting
2.6.9 to a custom mpc8275vr
board and we were able to get everything working except ethernet (fcc
enet). We did manage to get
a few packets over it but it was all very slow, unstable and
unpredictable and it seemed that fcc enet
driver doesn't work well in 2.6. Were you able to use fcc under 2.6.9?
Best Regards, Saso
Steven Blakeslee wrote:
>I would suggest going to the latest 2.6.10 kernel. I have it running
>with several ethernets running on all the 82xx processors.
>
>
>
>>-----Original Message-----
>>From: linuxppc-embedded-bounces@ozlabs.org
>>[mailto:linuxppc-embedded-bounces@ozlabs.org] On Behalf Of
>>Vijay Padiyar
>>Sent: Wednesday, January 12, 2005 5:37 AM
>>To: LinuxPPC Support
>>Subject: Some issues with kernel 2.6 for MPC8260 target
>>
>>Hi all
>>
>>I wish to discuss some strange issues that I faced with
>>respect to the Linux
>>2.6.8 kernel (downloaded from kernel.org). Firstly, I wish to
>>know whether this has been known to work on an MPC8260 PowerPC target.
>>
>>Secondly, when I tried to compile the Linux kernel with my
>>toolchain (built with Dan Kegel's crosstool for the PowerPC
>>603e core, which is what my processor has), I got some errors
>>which I found to rather queer after investigation. Firstly,
>>let me state the errors that I got:
>>
>>------------------------------------------------------
>>
>> LD init/built-in.o
>> LD .tmp_vmlinux1
>>arch/ppc/8260_io/built-in.o(.text+0x103c): In function
>>`mii_queue_relink':
>>arch/ppc/8260_io/fcc_enet.c:1254: undefined reference to
>>`schedule_task'
>>arch/ppc/8260_io/built-in.o(.text+0x1074): In function
>>`mii_queue_config':
>>arch/ppc/8260_io/fcc_enet.c:1263: undefined reference to
>>`schedule_task'
>>
>>------------------------------------------------------
>>
>>On further investigation, I find that 'schedule_task()' is
>>simply not defined anywhere in the 2.6.8 kernel sources. This
>>is quite wierd! However, it is defined in a file 'context.c'
>>(linux-src/kernel) in the 2.4.27 kernel sources, which we
>>were using earlier. How is it that a function is being called
>>but its definition has been removed from the sources?
>>
>>Another such example is with the structure 'tq_struct'. It is
>>referred to in the file 'fcc_enet.c'
>>(linux-src/arch/ppc/8260_io) but it's not defined anywhere!
>>Again, after checking in the 2.4.27 sources, I find that it's
>>defined in the file 'tqueue.h' (linux-src/include/linux)!
>>
>>A third thing is that the 2.4.27 kernel source file 'uart.c'
>>(linux-src/arch/ppc/cpm2_io) is not present in the
>>corresponding folder in the 2.6.8 source
>>(linux-src/arch/ppc/8260_io). There is one 'uart.c' in the
>>folder '8xx_io', but it doesn't get compiled during the
>>kernel build process. Will my UART work correctly with this build?
>>
>>Can someone please tell me if there's some explanation for
>>this that I'm unaware of? Which would be the proper forum to
>>report this? Again I would like to ask: Has the 2.6.8 kernel
>>been tested successfully on the MPC8260 PowerPC platform?
>>
>>Lastly, where can I get the latest stable Linux kernel source
>>for the PowerPC platform?
>>
>>Regards
>>
>>Vijay Padiyar
>>_______________________________________________
>>Linuxppc-embedded mailing list
>>Linuxppc-embedded@ozlabs.org
>>https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>>
>>
>>
>_______________________________________________
>Linuxppc-embedded mailing list
>Linuxppc-embedded@ozlabs.org
>https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
>
^ permalink raw reply
* RE: Help with PPC440GX + MontaVista + uBoot
From: Matt Sheahan @ 2005-01-12 14:24 UTC (permalink / raw)
To: 'Howard, Marc'; +Cc: linuxppc-embedded
In-Reply-To: <20050112113708.9E414C108D@atlas.denx.de>
Check ocotea_calibrate_decr. It is using a hard coded clock value of 25
MHz. When I ported the Ocotea code to my custom board, used the value
passed from U-Boot (bi_intfreq).
I think the Ocotea code in 2.4.x might have been developed using a rev. B
440GX and there are some differences in how the timers and decrementers
derive their clock on the rev. C parts.
Also, using the bd_info definition in asm/ppcboot.h did not work perfectly
for me. Be sure to check the conditional compiles that are being set in
U-Boot against Linux for the bd_info structure. The 440GX structures did
not align properly and I had to tweak them and make sure U-Boot was filing
them in correctly (lib_ppc/board.c).
-----Original Message-----
From: linuxppc-embedded-bounces@ozlabs.org
[mailto:linuxppc-embedded-bounces@ozlabs.org] On Behalf Of Wolfgang Denk
Sent: Wednesday, January 12, 2005 6:37 AM
To: Howard, Marc
Cc: linuxppc-embedded@ozlabs.org
Subject: Re: Help with PPC440GX + MontaVista + uBoot
In message
<91B22F93A880FA48879475E134D6F0BE316B8C@CA1EXCLV02.adcorp.kla-tencor.com>
you wrote:
>
> PIBS isn't what we want to use long term, we'd rather use uBoot. I've
> downloaded and built the latest version of uBoot (1.1.2). I then
> created a multi-file image with mkimage. I can download it via TFTP but
> when I start to run it strange/bad things happen:
>
> Kernel command line: ip=3Don console=3DttyS0,115200 root=3D/dev/ram
rw
> Warning: real time clock seems stuck!
> Calibrating delay loop... 37.27 BogoMIPS
>
> ...now the RTC is know to work and the mips calculation is seriously
> off. Then...
That's a FAQ. Please see the part about "Bad definition of the
bd_info structure" in
http://www.denx.de/twiki/bin/view/DULG/LinuxHangsAfterUncompressingKernel
> I realize that ocotea.c will have to be modified to grab command line
> options from NVRAM (uBoot) instead of FLASH (PIBS) but that doesn't seem
Wrong. U-Boot (please mind the spelling) does not pass command line
options in NVRAM. They get passed in RAM.
> to explain why the internal timer is way off and the ethernet PHYs can't
> be found.
Because you use a wrong definition of bd_info. Delete the existing
definition and include asm/ppcboot.h in your board config file.
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
Bradley's Bromide: If computers get too powerful, we can organize
them into a committee - that will do them in.
_______________________________________________
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* RE: Some issues with kernel 2.6 for MPC8260 target
From: Steven Blakeslee @ 2005-01-12 14:34 UTC (permalink / raw)
To: Saso Kavcic; +Cc: linuxppc-embedded
I ported it to the Embedded Planet ep8260 board with FCC3, ep8248 board
with FCC1 and FCC2 and ep8280 with FCC2 and FCC3. I had to make very
little, if anything, to get it to work. I did not try 2.6.9. I am
currently using 2.6.10-rc3 which I believe after the last merge is now
2.6.10. I did practically nothing to get all of these to work.=20
> -----Original Message-----
> From: Saso Kavcic [mailto:saso@activetools.si]=20
> Sent: Wednesday, January 12, 2005 9:27 AM
> To: Steven Blakeslee
> Cc: linuxppc-embedded@ozlabs.org
> Subject: Re: Some issues with kernel 2.6 for MPC8260 target
>=20
> Hi Steven,
>=20
> Have you noticed any improvements in 2.6.10. over 2.6.9? We=20
> were porting
> 2.6.9 to a custom mpc8275vr
> board and we were able to get everything working except=20
> ethernet (fcc enet). We did manage to get a few packets over=20
> it but it was all very slow, unstable and unpredictable and=20
> it seemed that fcc enet driver doesn't work well in 2.6. Were=20
> you able to use fcc under 2.6.9?
>=20
> Best Regards, Saso
>=20
> Steven Blakeslee wrote:
>=20
> >I would suggest going to the latest 2.6.10 kernel. I have=20
> it running=20
> >with several ethernets running on all the 82xx processors.
> >
> > =20
> >
> >>-----Original Message-----
> >>From: linuxppc-embedded-bounces@ozlabs.org
> >>[mailto:linuxppc-embedded-bounces@ozlabs.org] On Behalf Of Vijay=20
> >>Padiyar
> >>Sent: Wednesday, January 12, 2005 5:37 AM
> >>To: LinuxPPC Support
> >>Subject: Some issues with kernel 2.6 for MPC8260 target
> >>
> >>Hi all
> >>
> >>I wish to discuss some strange issues that I faced with=20
> respect to the=20
> >>Linux
> >>2.6.8 kernel (downloaded from kernel.org). Firstly, I wish to know=20
> >>whether this has been known to work on an MPC8260 PowerPC target.
> >>
> >>Secondly, when I tried to compile the Linux kernel with my=20
> toolchain=20
> >>(built with Dan Kegel's crosstool for the PowerPC 603e=20
> core, which is=20
> >>what my processor has), I got some errors which I found to rather=20
> >>queer after investigation. Firstly, let me state the errors that I=20
> >>got:
> >>
> >>------------------------------------------------------
> >>
> >> LD init/built-in.o
> >> LD .tmp_vmlinux1
> >>arch/ppc/8260_io/built-in.o(.text+0x103c): In function
> >>`mii_queue_relink':
> >>arch/ppc/8260_io/fcc_enet.c:1254: undefined reference to=20
> >>`schedule_task'
> >>arch/ppc/8260_io/built-in.o(.text+0x1074): In function
> >>`mii_queue_config':
> >>arch/ppc/8260_io/fcc_enet.c:1263: undefined reference to=20
> >>`schedule_task'
> >>
> >>------------------------------------------------------
> >>
> >>On further investigation, I find that 'schedule_task()' is=20
> simply not=20
> >>defined anywhere in the 2.6.8 kernel sources. This is quite wierd!=20
> >>However, it is defined in a file 'context.c'
> >>(linux-src/kernel) in the 2.4.27 kernel sources, which we=20
> were using=20
> >>earlier. How is it that a function is being called but its=20
> definition=20
> >>has been removed from the sources?
> >>
> >>Another such example is with the structure 'tq_struct'. It=20
> is referred=20
> >>to in the file 'fcc_enet.c'
> >>(linux-src/arch/ppc/8260_io) but it's not defined anywhere!=20
> >>Again, after checking in the 2.4.27 sources, I find that=20
> it's defined=20
> >>in the file 'tqueue.h' (linux-src/include/linux)!
> >>
> >>A third thing is that the 2.4.27 kernel source file 'uart.c'
> >>(linux-src/arch/ppc/cpm2_io) is not present in the corresponding=20
> >>folder in the 2.6.8 source (linux-src/arch/ppc/8260_io).=20
> There is one=20
> >>'uart.c' in the folder '8xx_io', but it doesn't get compiled during=20
> >>the kernel build process. Will my UART work correctly with=20
> this build?
> >>
> >>Can someone please tell me if there's some explanation for=20
> this that=20
> >>I'm unaware of? Which would be the proper forum to report=20
> this? Again=20
> >>I would like to ask: Has the 2.6.8 kernel been tested=20
> successfully on=20
> >>the MPC8260 PowerPC platform?
> >>
> >>Lastly, where can I get the latest stable Linux kernel=20
> source for the=20
> >>PowerPC platform?
> >>
> >>Regards
> >>
> >>Vijay Padiyar
> >>_______________________________________________
> >>Linuxppc-embedded mailing list
> >>Linuxppc-embedded@ozlabs.org
> >>https://ozlabs.org/mailman/listinfo/linuxppc-embedded
> >>
> >> =20
> >>
> >_______________________________________________
> >Linuxppc-embedded mailing list
> >Linuxppc-embedded@ozlabs.org
> >https://ozlabs.org/mailman/listinfo/linuxppc-embedded
> > =20
> >
>=20
>=20
^ permalink raw reply
* canonical source for latest 2.6 kernels for 8xx?
From: Robert P. J. Day @ 2005-01-12 14:08 UTC (permalink / raw)
To: Embedded PPC Linux list
where is the primary site these days for up-to-date kernel source
trees for the 2.6 kernel for PPC? thanks.
rday
^ permalink raw reply
* Re: RFC: [PATCH] platform device driver model support
From: Kumar Gala @ 2005-01-12 14:41 UTC (permalink / raw)
To: Eugene Surovegin; +Cc: Kumar Gala, linuxppc-embedded
In-Reply-To: <20050112083637.GA13794@gate.ebshome.net>
On Jan 12, 2005, at 2:36 AM, Eugene Surovegin wrote:
> On Wed, Jan 12, 2005 at 01:43:09AM -0600, Kumar Gala wrote:
> >
> > Please take a look at the following patch.=A0 It adds driver model=20=
> support
> > via platform devices to 85xx.=A0 This is originally based on patches=20=
> from
> > Jason M.
> >
> > The idea behind the code is that for a give family: 4xx, 8xx, 82xx,=20=
> 83xx,
> > 85xx, 86xx we will have structure defns for the following:
> >
> > enum ppc_soc_devices
> > in asm-ppc/<family.h>:
> >=A0=A0 list of all unique devices in the family
> >
> > struct platform_device soc_platform_devices[]
> > in arch/ppc/platforms/<family>/<family>_devices.c:
> >=A0=A0 describes all platform devices that exist in the family
> >
> > struct soc_spec soc_specs[]
> > in arch/ppc/platforms/<family>/<family>_soc.c:
> >=A0=A0 describes each unique chip in the family and what devices it =
has
>
> Well, there is a problem right here at least for 4xx.
> Current OCP implementation is much more flexible IMHO.
>
> For 4xx is not uncommon when you have the same "logical" device at the
> different places with different "properties" (e.h. different channel,
> etc).
>
> Your case (85xx) looks simpler - all you need is a list of devices
> which particular SoC supports, without significant differences in
> "properties". This will not work that easy for 4xx.
>
> In fact, I don't see any gain (at least for 4xx) in all these changes.
> It makes 4xx much more tangled IMHO, because we'll still need all
> those ibm405gp.c, ibm405ep.c, ibm440gp.c etc.
>
> Please note, using platform_device is orthogonal to the way we
> describe each SoC (this is what I don't quite like in your patch), and
> I don't have any strong objections to using platform_device instead of
> OCP or feature_call or whatever for communication with device drivers.
I need to understand a bit more about how 4xx does things. When I=20
started the SOC stuff, it was freescale specific. I agree that its=20
orthogonal to the use of platform device. Does this some like a bad=20
idea for the fsl case?
> > Plus the following functions:
> >
> > identify_soc_by_id() -- determine soc by an int id
> > identify_soc_by_name() -- determin soc by name (useful in some 82xx=20=
> cases)
> > ppc_soc_get_pdata() -- get platform_data pointer so board code can=20=
> modify
> > ppc_soc_update_paddr() -- update iomem resources with a given paddr
>
> IMHO, ppc_soc_update_paddr - is a very confusing name, in fact, from
> first read I though it _changes_ paddr to the new value, not _adds_ it
> :)
>
> Probably this function should be made 85xx specific as I cannot come
> up with any use for it in 4xx (we don't have anything similar to
> CCSRBAR ;).
Not an issue, any suggestions on renaming to make it clear what it=20
does? Also, I can make this fsl_increment_paddr() since its useful to=20=
more than on family of fsl processors.
> [snip]
>
> > +
> > +struct platform_device soc_platform_devices[] =3D {
> > +=A0=A0=A0=A0 [MPC85xx_TSEC1] =3D {
> > +=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0 .name =3D "fsl-gianfar",
> > +=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0 .id=A0=A0=A0=A0 =3D 1,
> > +=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0 .dev.platform_data =3D =
&mpc85xx_tsec1_pdata,
> > +=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0 .num_resources=A0=A0 =3D 4,
> > +=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0 .resource =3D (struct =
resource[]) {
> > +=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0 {
> > +=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=
=A0=A0=A0 .start=A0 =3D MPC85xx_ENET1_OFFSET,
> > +=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=
=A0=A0=A0 .end=A0=A0=A0 =3D MPC85xx_ENET1_OFFSET +
> > +=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=
=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0 MPC85xx_ENET1_SIZE =
-=20
> 1,
> > +=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=
=A0=A0=A0 .flags=A0 =3D IORESOURCE_MEM,
> > +=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0 },
> > +=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0 {
> > +=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=
=A0=A0=A0 .name=A0=A0 =3D "tx",
> > +=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=
=A0=A0=A0 .start=A0 =3D MPC85xx_IRQ_TSEC1_TX,
> > +=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=
=A0=A0=A0 .end=A0=A0=A0 =3D MPC85xx_IRQ_TSEC1_TX,
> > +=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=
=A0=A0=A0 .flags=A0 =3D IORESOURCE_IRQ,
> > +=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0 },
> > +=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0 {
> > +=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=
=A0=A0=A0 .name=A0=A0 =3D "rx",
> > +=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=
=A0=A0=A0 .start=A0 =3D MPC85xx_IRQ_TSEC1_RX,
> > +=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=
=A0=A0=A0 .end=A0=A0=A0 =3D MPC85xx_IRQ_TSEC1_RX,
> > +=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=
=A0=A0=A0 .flags=A0 =3D IORESOURCE_IRQ,
> > +=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0 },
> > +=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0 {
> > +=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=
=A0=A0=A0 .name=A0=A0 =3D "error",
> > +=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=
=A0=A0=A0 .start=A0 =3D MPC85xx_IRQ_TSEC1_ERROR,
> > +=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=
=A0=A0=A0 .end=A0=A0=A0 =3D MPC85xx_IRQ_TSEC1_ERROR,
> > +=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=
=A0=A0=A0 .flags=A0 =3D IORESOURCE_IRQ,
> > +=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0 },
> [snip]
>
>
>
> I already wrote about this but repeat again :(.
>
> Why put all these defines (e.g. for memory regions) into header when
> the only user is this particular file. It doesn't help readability and
> only obfuscates sources (and 4xx is a very good example of such mess
> :)
Understood, I forgot about this. I've got now issue with changing it,=20=
just trying to minimize changes.
thanks
- kumar
^ permalink raw reply
* RE: MPC8xx: Using SCM/SCC and standard 16C550 Uarts together...
From: Demke Torsten-atd012 @ 2005-01-12 14:46 UTC (permalink / raw)
To: David Jander, linuxppc-embedded
Hello David,
>
> On Wednesday 12 January 2005 10:59, Demke Torsten-atd012 wrote:
> > I dont know exactly the state of the DENX kernel, but in
> the standard
> > kernel the 8xx UART driver and the 16550 driver are using the same
> > device numbers (TTY_MAJOR) and device names (/dev/ttySx).
> > You have to change one of them.
>
> You are right! What now? I cannot go around and change TTY_MAJOR!
> Is it true then, that you normally cannot have a mix of
> non-16550 uarts and
> 16550 uarts on the same system, without doing nonstandard
> things with major
> numbers?
> Should maybe arch/ppc/8xx_io/uart.c use another major number?
Yes, indeed I changed the major device number and the name in
8xx_io/uart.c. I used the same numbers and names that are used
in the 2.6 kernel (TTY_CPM_MAJOR=42, name= "ttyCPM"). Of course
you have to change all applications that use the 8xx UART then.
See pseudo-patch:
+#ifdef CONFIG_SERIAL_CONSOLE
static struct console sercons = {
- name: "ttyS",
+ name: "ttyCPM",
write: serial_console_write,
device: serial_console_device,
setup: serial_console_setup,
flags: CON_PRINTBUFFER,
index: CONFIG_SERIAL_CONSOLE_PORT,
};
+#endif
...
static kdev_t serial_console_device(struct console *c)
{
+#ifdef CONFIG_SERIAL
+ return MKDEV(TTY_CPM_MAJOR, 42 + c->index);
+#else
return MKDEV(TTY_MAJOR, 64 + c->index);
+#endif
}
...
serial_driver.magic = TTY_DRIVER_MAGIC;
serial_driver.driver_name = "serial";
+#ifdef CONFIG_SERIAL
+/* use different numbers if "standard" serial driver is enabled */
+ serial_driver.driver_name = "serialCPM";
+#ifdef CONFIG_DEVFS_FS
+ serial_driver.name = "tts/%d";
+#else
+ serial_driver.name = "ttyCPM";
+#endif
+ serial_driver.major = TTY_CPM_MAJOR;
+ serial_driver.minor_start = 42;
+#else
+ serial_driver.driver_name = "serial";
#ifdef CONFIG_DEVFS_FS
serial_driver.name = "tts/%d";
#else
@@ -2553,6 +2585,7 @@ int __init rs_8xx_init(void)
#endif
serial_driver.major = TTY_MAJOR;
serial_driver.minor_start = 64;
+#endif /* CONFIG_SERIAL */
serial_driver.num = NR_PORTS;
serial_driver.type = TTY_DRIVER_TYPE_SERIAL;
serial_driver.subtype = SERIAL_TYPE_NORMAL;
Greetings,
Torsten
>
> Greetings,
>
> --
> David Jander
> Protonic Holland.
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
^ permalink raw reply
* Re: Some issues with kernel 2.6 for MPC8260 target
From: Saso Kavcic @ 2005-01-12 14:53 UTC (permalink / raw)
To: Steven Blakeslee; +Cc: linuxppc-embedded
In-Reply-To: <1628E43D99629C46988BE46087A3FBB912F225@ep-01.EmbeddedPlanet.local>
Thanks for the info. Nice to know that it can work.
Steven Blakeslee wrote:
>I ported it to the Embedded Planet ep8260 board with FCC3, ep8248 board
>with FCC1 and FCC2 and ep8280 with FCC2 and FCC3. I had to make very
>little, if anything, to get it to work. I did not try 2.6.9. I am
>currently using 2.6.10-rc3 which I believe after the last merge is now
>2.6.10. I did practically nothing to get all of these to work.
>
>
>
>>-----Original Message-----
>>From: Saso Kavcic [mailto:saso@activetools.si]
>>Sent: Wednesday, January 12, 2005 9:27 AM
>>To: Steven Blakeslee
>>Cc: linuxppc-embedded@ozlabs.org
>>Subject: Re: Some issues with kernel 2.6 for MPC8260 target
>>
>>Hi Steven,
>>
>>Have you noticed any improvements in 2.6.10. over 2.6.9? We
>>were porting
>>2.6.9 to a custom mpc8275vr
>>board and we were able to get everything working except
>>ethernet (fcc enet). We did manage to get a few packets over
>>it but it was all very slow, unstable and unpredictable and
>>it seemed that fcc enet driver doesn't work well in 2.6. Were
>>you able to use fcc under 2.6.9?
>>
>>Best Regards, Saso
>>
>>Steven Blakeslee wrote:
>>
>>
>>
>>>I would suggest going to the latest 2.6.10 kernel. I have
>>>
>>>
>>it running
>>
>>
>>>with several ethernets running on all the 82xx processors.
>>>
>>>
>>>
>>>
>>>
>>>>-----Original Message-----
>>>>From: linuxppc-embedded-bounces@ozlabs.org
>>>>[mailto:linuxppc-embedded-bounces@ozlabs.org] On Behalf Of Vijay
>>>>Padiyar
>>>>Sent: Wednesday, January 12, 2005 5:37 AM
>>>>To: LinuxPPC Support
>>>>Subject: Some issues with kernel 2.6 for MPC8260 target
>>>>
>>>>Hi all
>>>>
>>>>I wish to discuss some strange issues that I faced with
>>>>
>>>>
>>respect to the
>>
>>
>>>>Linux
>>>>2.6.8 kernel (downloaded from kernel.org). Firstly, I wish to know
>>>>whether this has been known to work on an MPC8260 PowerPC target.
>>>>
>>>>Secondly, when I tried to compile the Linux kernel with my
>>>>
>>>>
>>toolchain
>>
>>
>>>>(built with Dan Kegel's crosstool for the PowerPC 603e
>>>>
>>>>
>>core, which is
>>
>>
>>>>what my processor has), I got some errors which I found to rather
>>>>queer after investigation. Firstly, let me state the errors that I
>>>>got:
>>>>
>>>>------------------------------------------------------
>>>>
>>>> LD init/built-in.o
>>>> LD .tmp_vmlinux1
>>>>arch/ppc/8260_io/built-in.o(.text+0x103c): In function
>>>>`mii_queue_relink':
>>>>arch/ppc/8260_io/fcc_enet.c:1254: undefined reference to
>>>>`schedule_task'
>>>>arch/ppc/8260_io/built-in.o(.text+0x1074): In function
>>>>`mii_queue_config':
>>>>arch/ppc/8260_io/fcc_enet.c:1263: undefined reference to
>>>>`schedule_task'
>>>>
>>>>------------------------------------------------------
>>>>
>>>>On further investigation, I find that 'schedule_task()' is
>>>>
>>>>
>>simply not
>>
>>
>>>>defined anywhere in the 2.6.8 kernel sources. This is quite wierd!
>>>>However, it is defined in a file 'context.c'
>>>>(linux-src/kernel) in the 2.4.27 kernel sources, which we
>>>>
>>>>
>>were using
>>
>>
>>>>earlier. How is it that a function is being called but its
>>>>
>>>>
>>definition
>>
>>
>>>>has been removed from the sources?
>>>>
>>>>Another such example is with the structure 'tq_struct'. It
>>>>
>>>>
>>is referred
>>
>>
>>>>to in the file 'fcc_enet.c'
>>>>(linux-src/arch/ppc/8260_io) but it's not defined anywhere!
>>>>Again, after checking in the 2.4.27 sources, I find that
>>>>
>>>>
>>it's defined
>>
>>
>>>>in the file 'tqueue.h' (linux-src/include/linux)!
>>>>
>>>>A third thing is that the 2.4.27 kernel source file 'uart.c'
>>>>(linux-src/arch/ppc/cpm2_io) is not present in the corresponding
>>>>folder in the 2.6.8 source (linux-src/arch/ppc/8260_io).
>>>>
>>>>
>>There is one
>>
>>
>>>>'uart.c' in the folder '8xx_io', but it doesn't get compiled during
>>>>the kernel build process. Will my UART work correctly with
>>>>
>>>>
>>this build?
>>
>>
>>>>Can someone please tell me if there's some explanation for
>>>>
>>>>
>>this that
>>
>>
>>>>I'm unaware of? Which would be the proper forum to report
>>>>
>>>>
>>this? Again
>>
>>
>>>>I would like to ask: Has the 2.6.8 kernel been tested
>>>>
>>>>
>>successfully on
>>
>>
>>>>the MPC8260 PowerPC platform?
>>>>
>>>>Lastly, where can I get the latest stable Linux kernel
>>>>
>>>>
>>source for the
>>
>>
>>>>PowerPC platform?
>>>>
>>>>Regards
>>>>
>>>>Vijay Padiyar
>>>>_______________________________________________
>>>>Linuxppc-embedded mailing list
>>>>Linuxppc-embedded@ozlabs.org
>>>>https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>>>>
>>>>
>>>>
>>>>
>>>>
>>>_______________________________________________
>>>Linuxppc-embedded mailing list
>>>Linuxppc-embedded@ozlabs.org
>>>https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>>>
>>>
>>>
>>>
>>
>>
^ permalink raw reply
* Re: Some issues with kernel 2.6 for MPC8260 target
From: Hans Schillstrom @ 2005-01-12 14:38 UTC (permalink / raw)
To: Saso Kavcic; +Cc: Steven Blakeslee, linuxppc-embedded
In-Reply-To: <41E533CB.6060208@activetools.si>
Hi,
I have 2.6.10 working on a mpc8250vr, the only thing that had to be done
was moving around the clock pins. The performace is good.
/Hans
On Wed, 2005-01-12 at 15:27, Saso Kavcic wrote:
> Hi Steven,
>
> Have you noticed any improvements in 2.6.10. over 2.6.9? We were porting
> 2.6.9 to a custom mpc8275vr
> board and we were able to get everything working except ethernet (fcc
> enet). We did manage to get
> a few packets over it but it was all very slow, unstable and
> unpredictable and it seemed that fcc enet
> driver doesn't work well in 2.6. Were you able to use fcc under 2.6.9?
>
> Best Regards, Saso
>
> Steven Blakeslee wrote:
>
> >I would suggest going to the latest 2.6.10 kernel. I have it running
> >with several ethernets running on all the 82xx processors.
> >
> >
> >
> >>-----Original Message-----
> >>From: linuxppc-embedded-bounces@ozlabs.org
> >>[mailto:linuxppc-embedded-bounces@ozlabs.org] On Behalf Of
> >>Vijay Padiyar
> >>Sent: Wednesday, January 12, 2005 5:37 AM
> >>To: LinuxPPC Support
> >>Subject: Some issues with kernel 2.6 for MPC8260 target
> >>
> >>Hi all
> >>
> >>I wish to discuss some strange issues that I faced with
> >>respect to the Linux
> >>2.6.8 kernel (downloaded from kernel.org). Firstly, I wish to
> >>know whether this has been known to work on an MPC8260 PowerPC target.
> >>
> >>Secondly, when I tried to compile the Linux kernel with my
> >>toolchain (built with Dan Kegel's crosstool for the PowerPC
> >>603e core, which is what my processor has), I got some errors
> >>which I found to rather queer after investigation. Firstly,
> >>let me state the errors that I got:
> >>
> >>------------------------------------------------------
> >>
> >> LD init/built-in.o
> >> LD .tmp_vmlinux1
> >>arch/ppc/8260_io/built-in.o(.text+0x103c): In function
> >>`mii_queue_relink':
> >>arch/ppc/8260_io/fcc_enet.c:1254: undefined reference to
> >>`schedule_task'
> >>arch/ppc/8260_io/built-in.o(.text+0x1074): In function
> >>`mii_queue_config':
> >>arch/ppc/8260_io/fcc_enet.c:1263: undefined reference to
> >>`schedule_task'
> >>
> >>------------------------------------------------------
> >>
> >>On further investigation, I find that 'schedule_task()' is
> >>simply not defined anywhere in the 2.6.8 kernel sources. This
> >>is quite wierd! However, it is defined in a file 'context.c'
> >>(linux-src/kernel) in the 2.4.27 kernel sources, which we
> >>were using earlier. How is it that a function is being called
> >>but its definition has been removed from the sources?
> >>
> >>Another such example is with the structure 'tq_struct'. It is
> >>referred to in the file 'fcc_enet.c'
> >>(linux-src/arch/ppc/8260_io) but it's not defined anywhere!
> >>Again, after checking in the 2.4.27 sources, I find that it's
> >>defined in the file 'tqueue.h' (linux-src/include/linux)!
> >>
> >>A third thing is that the 2.4.27 kernel source file 'uart.c'
> >>(linux-src/arch/ppc/cpm2_io) is not present in the
> >>corresponding folder in the 2.6.8 source
> >>(linux-src/arch/ppc/8260_io). There is one 'uart.c' in the
> >>folder '8xx_io', but it doesn't get compiled during the
> >>kernel build process. Will my UART work correctly with this build?
> >>
> >>Can someone please tell me if there's some explanation for
> >>this that I'm unaware of? Which would be the proper forum to
> >>report this? Again I would like to ask: Has the 2.6.8 kernel
> >>been tested successfully on the MPC8260 PowerPC platform?
> >>
> >>Lastly, where can I get the latest stable Linux kernel source
> >>for the PowerPC platform?
> >>
> >>Regards
> >>
> >>Vijay Padiyar
> >>_______________________________________________
> >>Linuxppc-embedded mailing list
> >>Linuxppc-embedded@ozlabs.org
> >>https://ozlabs.org/mailman/listinfo/linuxppc-embedded
> >>
> >>
> >>
> >_______________________________________________
> >Linuxppc-embedded mailing list
> >Linuxppc-embedded@ozlabs.org
> >https://ozlabs.org/mailman/listinfo/linuxppc-embedded
> >
> >
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* Re: [PATCH] Handle I-TLB Error and Miss separately on 8xx
From: Tom Rini @ 2005-01-12 15:15 UTC (permalink / raw)
To: Joakim Tjernlund; +Cc: Linuxppc-Embedded@Ozlabs. Org
In-Reply-To: <JPEALJAFNGDDLOPNDIEEAEADDAAA.joakim.tjernlund@lumentis.se>
On Wed, Jan 12, 2005 at 03:17:11PM +0100, Joakim Tjernlund wrote:
> > On Wed, Jan 12, 2005 at 08:53:17AM +0100, Joakim Tjernlund wrote:
> > > > As the code stands currently, there is a bug in the 2.4 and 2.6 handling
> > > > of I-TLB Miss and Error exceptions on 8xx. The problem is that since we
> > > > treat both of them as the same exception when we hit do_page_fault,
> > > > there is a case where we can incorrectly find that a protection fault
> > > > has occured, when it hasn't. This is because we check bit 4 of SRR1 in
> > > > both cases, but in the case of an I-TLB Miss, this bit is always set,
> > > > and it only indicates a protection fault on an I-TLB Error.
> > >
> > > Patch looks good to me, but I want to ask when this error
> > > can be triggered in practice?
> >
> > It is possible to see this in the real world, as we (<hat=mvista>) found
> > this with a customers app.
>
> hmm, this app must have been doing something pretty special. Any idea what
> caused it?
Only vaugely. I'll poke the folks who did the investigation to see if
they recall (the app is quite large) and follow up with details, I hope.
--
Tom Rini
http://gate.crashing.org/~trini/
^ permalink raw reply
* mpc8270vr
From: Hans Schillstrom @ 2005-01-12 14:55 UTC (permalink / raw)
To: linuxppc-embedded
Hi,
Is there any one that have a mpc8270vr (rev 0.01 1k49M mask) running
a 2.6 kernel ?
I have a couple of boards with mpc8250vr and mpc8270vr (the board is
identical for the processor).
The kernel image is the same, the 8250 works fine.
The 8270 hangs when creating the init thread:
kernel_thread(init, NULL, CLONE_FS | CLONE_SIGHAND);
Any one that have an idea ?
Regards
/Hans
^ permalink raw reply
* RE: Kernel boot hangs by parallel flood pings
From: Rune Torgersen @ 2005-01-12 15:32 UTC (permalink / raw)
To: Steffen Rumler, linuxppc
I have had the problem before (and so has several other people)
This is a reply I got on the old Linux PPC mailinglist last year
(from Gerard Guevel [gguevel@interfaceconcept.com])
---- Original message -----
RE: FCC ethernets not stable
I received the right solution from Jean-Denis Boyer (thanks to him...)
>>
It registers the IPv4 handling functions AFTER initializing the IP
routing
stuff.
Early packets could enter the stack and crash the system.
--- Kernel.old/net/ipv4/ip_output.c Thu Jun 5 09:00:39 2003
+++ Kernel/net/ipv4/ip_output.c Thu Jun 5 09:00:28 2003
@@ -1087,11 +1087,11 @@
void __init ip_init(void)
{
- dev_add_pack(&ip_packet_type);
-
ip_rt_init();
inet_initpeers();
+ dev_add_pack(&ip_packet_type);
+
#ifdef CONFIG_IP_MULTICAST
proc_net_create("igmp", 0, ip_mc_procinfo);
#endif
>>
I never saw this problem after installing this patch.
Regards
Gerard Guevel=20
> -----Original Message-----
> From: linuxppc-embedded-bounces@ozlabs.org=20
> [mailto:linuxppc-embedded-bounces@ozlabs.org] On Behalf Of=20
> Steffen Rumler
> Sent: Wednesday, January 12, 2005 02:38
> To: linuxppc
> Subject: Kernel boot hangs by parallel flood pings
>=20
> I'm using a 2.4.20 kernel (PPC).
>=20
> When I run multiple 'ping -f' directed to my board
> during the kernel boots, sometimes it hangs with
> the following messages:
>=20
>=20
> Memory BAT mapping: BAT2=3D64Mb, BAT3=3D32Mb, residual: 84Mb
> Linux version 2.4.20-rthal5 (ru@styx) (gcc version 2.95.3=20
> 20010111 (prerelease/franzo/20010111))
> #9 Tue Jan 11 17:09:22 CET 2005
> On node 0 totalpages: 29859
> zone(0): 29859 pages.
> zone(1): 0 pages.
> zone(2): 0 pages.
> Kernel command line: bootdev=3Daps0=20
> ip=3D218.1.36.70:218.1.36.47:218.1.36.254:255.255.255.0::eth0:off
> panic=3D1 mem=3D119436k
> Calibrating delay loop... 194.15 BogoMIPS
> ...
> NET4: Linux TCP/IP 1.0 for NET4.0
> IP Protocols: ICMP, UDP, TCP
> IP: routing cache ha
> ^^^^^^^
> the kernel boot hangs here
>=20
>=20
> I have checked this with the BDI2000 and found that the
> kernel loops anywhere inside ip_route_input().
>=20
> I think this is because the ethernet driver (fcc_enet.c)
> enables the hardware too already inside it's init routine=20
> (fec_enet_init()).
>=20
> In this way, frames may be received and forwarded to the upper
> layers with netif_rx(), before the TCP/IP was initialized.
>=20
> I suggest to delay the lines
>=20
> /* Enable transmit/receive */
> fccp->fcc_gfmr |=3D FCC_GFMR_ENR | FCC_GFMR_ENT;
>=20
> to the open entry point (fcc_enet_open()), which is
> triggered by 'ifconfig up' in the following way:
>=20
>=20
> if(!((fccp->fcc_gfmr) & FCC_GFMR_ENR))
> fccp->fcc_gfmr |=3D (FCC_GFMR_ENR | FCC_GFMR_ENT);
>=20
> By the way, fcc_enet_close() does _NOT_ stop the hardware.
> Hopefully, this is not a real problem.
>=20
>=20
> Steffen
>=20
> --=20
>=20
>=20
> --------------------------------------------------------------
>=20
> Steffen Rumler
> ICN CP D NT SW 3
> Siemens AG
> Hofmannstr. 51 Email: Steffen.Rumler@siemens.com
> D-81359 Munich Phone: +49 89 722-44061
> Germany Fax : +49 89 722-36703
>=20
> --------------------------------------------------------------
>=20
>=20
>=20
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>=20
>=20
^ permalink raw reply
* RE: mpc8270vr
From: Steven Blakeslee @ 2005-01-12 15:37 UTC (permalink / raw)
To: Hans Schillstrom, linuxppc-embedded
>=20
> Hi,
> Is there any one that have a mpc8270vr (rev 0.01 1k49M mask)=20
> running a 2.6 kernel ?
I have 2.6.10-rc3 booting just fine on a 8270 and 8280 as well as 8250
and 8260.
> I have a couple of boards with mpc8250vr and mpc8270vr (the=20
> board is identical for the processor).
> The kernel image is the same, the 8250 works fine.
> The 8270 hangs when creating the init thread:
> kernel_thread(init, NULL, CLONE_FS | CLONE_SIGHAND);
Don't know why it would die there but the calcualtions for the clocks on
an 8250 are different than that of the 8270. If it is working on the
8250 then you may be doing the calculations wrong on the 8270. Other
than the clocks it should be the same.
^ permalink raw reply
* Re: Kernel boot hangs by parallel flood pings
From: Wolfgang Denk @ 2005-01-12 16:10 UTC (permalink / raw)
To: Rune Torgersen; +Cc: Steffen Rumler, linuxppc
In-Reply-To: <DCEAAC0833DD314AB0B58112AD99B93B85928F@ismail.innsys.innovsys.com>
In message <DCEAAC0833DD314AB0B58112AD99B93B85928F@ismail.innsys.innovsys.com> you wrote:
> I have had the problem before (and so has several other people)
>
> This is a reply I got on the old Linux PPC mailinglist last year
> (from Gerard Guevel [gguevel@interfaceconcept.com])
According to my records the patch was by Jean-Denis Boyer, 05 Jun
2003.
> I never saw this problem after installing this patch.
I can confirm this, too.
Steffen: this is PatchSet 251 (Date: 2004/06/07 20:05:39) in our CVS
tree.
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
Yes, it's a technical challenge, and you have to kind of admire
people who go to the lengths of actually implementing it, but at the
same time you wonder about their IQ...
-- Linus Torvalds in <5phda5$ml6$1@palladium.transmeta.com>
^ permalink raw reply
* Linux 2.6 8xx kernel booting vs watchdog
From: Povolotsky, Alexander @ 2005-01-12 19:41 UTC (permalink / raw)
To: 'linuxppc-dev@ozlabs.org',
'linuxppc-embedded@ozlabs.org'
Hi,
I wonder if someone could help me with answering couple of my questions:
How watchdog resetting is handled for PPC
in Linux 2.6 on the kernel level ?
Does one need to add code for it or is it supported "off the shelf" ?
Is "early printk" supported for PPC on 2.6 ?
If yes - how and where it could be enabled?
Thanks,
Alex
^ permalink raw reply
* Re: RFC: [PATCH] platform device driver model support
From: Matt Porter @ 2005-01-12 21:14 UTC (permalink / raw)
To: Kumar Gala, trini, linuxppc-embedded, mporter, jason.mcmullan
In-Reply-To: <20050112083637.GA13794@gate.ebshome.net>
On Wed, Jan 12, 2005 at 12:36:37AM -0800, Eugene Surovegin wrote:
> On Wed, Jan 12, 2005 at 01:43:09AM -0600, Kumar Gala wrote:
> >
> > Please take a look at the following patch. It adds driver model support
> > via platform devices to 85xx. This is originally based on patches from
> > Jason M.
> >
> > The idea behind the code is that for a give family: 4xx, 8xx, 82xx, 83xx,
> > 85xx, 86xx we will have structure defns for the following:
> >
> > enum ppc_soc_devices
> > in asm-ppc/<family.h>:
> > list of all unique devices in the family
> >
> > struct platform_device soc_platform_devices[]
> > in arch/ppc/platforms/<family>/<family>_devices.c:
> > describes all platform devices that exist in the family
> >
> > struct soc_spec soc_specs[]
> > in arch/ppc/platforms/<family>/<family>_soc.c:
> > describes each unique chip in the family and what devices it has
>
> Well, there is a problem right here at least for 4xx.
> Current OCP implementation is much more flexible IMHO.
>
> For 4xx is not uncommon when you have the same "logical" device at the
> different places with different "properties" (e.h. different channel,
> etc).
>
> Your case (85xx) looks simpler - all you need is a list of devices
> which particular SoC supports, without significant differences in
> "properties". This will not work that easy for 4xx.
>
> In fact, I don't see any gain (at least for 4xx) in all these changes.
> It makes 4xx much more tangled IMHO, because we'll still need all
> those ibm405gp.c, ibm405ep.c, ibm440gp.c etc.
Summarizing some stuff from IRC (now that I'm caught up after time
off :P), I think we can live with this on 4xx. What seems to be
acceptable is that we can have an soc_specs[] and soc_platform_devices[]
in each 4xx SoC platform file. So, core_ocp[] can be merged and split
into soc_specs[]/soc_platform_devices[]. The active one will be selected
at build time just like we do now. This is due to the static nature
of the 4xx memory map (per SoC) and well as the variation in location
of iomem and irq resources as well as platform_data. Our soc_specs[]
will only have one SoC in it, since there is one per file. Doing
something like 85xx will scatter info about as you point out
above...and that doesn't make sense for 4xx.
> Please note, using platform_device is orthogonal to the way we
> describe each SoC (this is what I don't quite like in your patch), and
> I don't have any strong objections to using platform_device instead of
> OCP or feature_call or whatever for communication with device drivers.
Hurray. ;)
> > Plus the following functions:
> >
> > identify_soc_by_id() -- determine soc by an int id
> > identify_soc_by_name() -- determin soc by name (useful in some 82xx cases)
> > ppc_soc_get_pdata() -- get platform_data pointer so board code can modify
> > ppc_soc_update_paddr() -- update iomem resources with a given paddr
>
> IMHO, ppc_soc_update_paddr - is a very confusing name, in fact, from
> first read I though it _changes_ paddr to the new value, not _adds_ it
> :)
I think it should be ppc_soc_update_mem_resource() or some such.
You are updating the IOMEM resource.
> Probably this function should be made 85xx specific as I cannot come
> up with any use for it in 4xx (we don't have anything similar to
> CCSRBAR ;).
Can't be, it can be used on Marvell and others.
> [snip]
>
> > +
> > +struct platform_device soc_platform_devices[] = {
> > + [MPC85xx_TSEC1] = {
> > + .name = "fsl-gianfar",
> > + .id = 1,
> > + .dev.platform_data = &mpc85xx_tsec1_pdata,
> > + .num_resources = 4,
> > + .resource = (struct resource[]) {
> > + {
> > + .start = MPC85xx_ENET1_OFFSET,
> > + .end = MPC85xx_ENET1_OFFSET +
> > + MPC85xx_ENET1_SIZE - 1,
> > + .flags = IORESOURCE_MEM,
> > + },
> > + {
> > + .name = "tx",
> > + .start = MPC85xx_IRQ_TSEC1_TX,
> > + .end = MPC85xx_IRQ_TSEC1_TX,
> > + .flags = IORESOURCE_IRQ,
> > + },
> > + {
> > + .name = "rx",
> > + .start = MPC85xx_IRQ_TSEC1_RX,
> > + .end = MPC85xx_IRQ_TSEC1_RX,
> > + .flags = IORESOURCE_IRQ,
> > + },
> > + {
> > + .name = "error",
> > + .start = MPC85xx_IRQ_TSEC1_ERROR,
> > + .end = MPC85xx_IRQ_TSEC1_ERROR,
> > + .flags = IORESOURCE_IRQ,
> > + },
> [snip]
>
>
> I already wrote about this but repeat again :(.
>
> Why put all these defines (e.g. for memory regions) into header when
> the only user is this particular file. It doesn't help readability and
> only obfuscates sources (and 4xx is a very good example of such mess
> :)
Having been previously convinced of this style, I'd say it's the The
Right Thing To Do(tm).
-Matt
^ permalink raw reply
* Re: RFC: [PATCH] platform device driver model support
From: Matt Porter @ 2005-01-12 21:28 UTC (permalink / raw)
To: Kumar Gala, trini, linuxppc-embedded, jason.mcmullan
In-Reply-To: <20050112141449.B22626@home.com>
On Wed, Jan 12, 2005 at 02:14:49PM -0700, Matt Porter wrote:
> On Wed, Jan 12, 2005 at 12:36:37AM -0800, Eugene Surovegin wrote:
> > IMHO, ppc_soc_update_paddr - is a very confusing name, in fact, from
> > first read I though it _changes_ paddr to the new value, not _adds_ it
> > :)
>
> I think it should be ppc_soc_update_mem_resource() or some such.
> You are updating the IOMEM resource.
More IRC chatter and ppc_soc_fixup_mem_resource() seems to be more
descriptive.
-Matt
^ permalink raw reply
* Re: Linux 2.6 8xx kernel booting vs watchdog
From: Marcelo Tosatti @ 2005-01-12 18:27 UTC (permalink / raw)
To: Povolotsky, Alexander
Cc: 'linuxppc-dev@ozlabs.org',
'linuxppc-embedded@ozlabs.org'
In-Reply-To: <313680C9A886D511A06000204840E1CF0A6474B2@whq-msgusr-02.pit.comms.marconi.com>
On Wed, Jan 12, 2005 at 02:41:18PM -0500, Povolotsky, Alexander wrote:
> Hi,
>
> I wonder if someone could help me with answering couple of my questions:
>
> How watchdog resetting is handled for PPC
> in Linux 2.6 on the kernel level ?
> Does one need to add code for it or is it supported "off the shelf" ?
It is not supported off the shelf.
We (Cyclades) have a timer to periodically touch the watchdog on boot, and afterwards
a watchdog driver which gets periodically written by a userspace daemon.
I can send a patch if you wish.
> Is "early printk" supported for PPC on 2.6 ?
> If yes - how and where it could be enabled?
Not sure.
^ permalink raw reply
* [PATCH 2.6.10] ppc32: Add Freescale PQ2FADS support
From: Tom Rini @ 2005-01-12 23:22 UTC (permalink / raw)
To: Andrew Morton, linuxppc-embedded
Hello. The following adds support for Freescale's PQ2FADS board to the
kernel.
(The 'real' changes required for the board are in the ethernet driver,
which needs a massive sync-up with mainline as I've been holding out for
a better, rewritten one from the Freescale folks, who're waiting for the
PHY lib patch sent to the net-dev list to get ack'd)
Signed-off-by: Tom Rini <trini@kernel.crashing.org>
--- 1.94/arch/ppc/Kconfig 2005-01-04 19:48:07 -07:00
+++ edited/arch/ppc/Kconfig 2005-01-12 16:17:17 -07:00
@@ -623,6 +623,12 @@
config ADS8272
bool "ADS8272"
+config PQ2FADS
+ bool "Freescale-PQ2FADS"
+ help
+ Select PQ2FADS if you wish to configure for a Freescale
+ PQ2FADS board (-VR or -ZU).
+
config LITE5200
bool "Freescale LITE5200 / (IceCube)"
select PPC_MPC52xx
@@ -655,7 +661,7 @@
config 8260
bool "CPM2 Support" if WILLOW
depends on 6xx
- default y if TQM8260 || RPX8260 || EST8260 || SBS8260 || SBC82xx
+ default y if TQM8260 || RPX8260 || EST8260 || SBS8260 || SBC82xx || PQ2FADS
help
The MPC8260 is a typical embedded CPU made by Motorola. Selecting
this option means that you wish to build a kernel for a machine with
--- 1.2/arch/ppc/platforms/pq2ads.h 2004-08-13 14:03:33 -07:00
+++ edited/arch/ppc/platforms/pq2ads.h 2005-01-12 16:20:03 -07:00
@@ -40,6 +40,8 @@
#define BCSR1_FETH_RST ((uint)0x04000000) /* 0 == reset */
#define BCSR1_RS232_EN1 ((uint)0x02000000) /* 0 == enable */
#define BCSR1_RS232_EN2 ((uint)0x01000000) /* 0 == enable */
+#define BCSR3_FETHIEN2 ((uint)0x10000000) /* 0 == enable */
+#define BCSR3_FETH2_RST ((uint)0x80000000) /* 0 == reset */
#define PHY_INTERRUPT SIU_INT_IRQ7
--- 1.10/include/asm-ppc/mpc8260.h 2004-08-23 11:08:39 -07:00
+++ edited/include/asm-ppc/mpc8260.h 2005-01-12 16:17:18 -07:00
@@ -36,7 +36,7 @@
#include <platforms/tqm8260.h>
#endif
-#ifdef CONFIG_PQ2ADS
+#if defined(CONFIG_PQ2ADS) || defined (CONFIG_PQ2FADS)
#include <platforms/pq2ads.h>
#endif
--
Tom Rini
http://gate.crashing.org/~trini/
^ permalink raw reply
* board with no RTC
From: Goforth, Edward @ 2005-01-12 23:25 UTC (permalink / raw)
To: linuxppc-embedded
We have a 440gx based custom board. I have learned that it does not
have a RTC. Has anyone had any success with a board without a RTC, or is
it even possible? How much of a problem will this cause? =20
Should we get the board respun with a RTC? We would prefer using a 2.4
kernel, but would certainly go to a 2.6 kernel if that made things
easier.
Thanks in advance for any advice.
Ed Goforth
^ permalink raw reply
* Re: board with no RTC
From: Eugene Surovegin @ 2005-01-12 23:42 UTC (permalink / raw)
To: Goforth, Edward; +Cc: linuxppc-embedded
In-Reply-To: <9A48EF7239039B48834A3F6B644B0C71EF8679@vaff06-mail01.ad.gd-ais.com>
On Wed, Jan 12, 2005 at 06:25:45PM -0500, Goforth, Edward wrote:
> We have a 440gx based custom board. I have learned that it does not
> have a RTC. Has anyone had any success with a board without a RTC, or is
> it even possible? How much of a problem will this cause?
>
There shouldn't be any problems without RTC except the fact that you
need to worry about getting correct time.
I have many 4xx-based boards without RTC. They "just work".
--
Eugene
^ permalink raw reply
* Re: board with no RTC
From: Matt Porter @ 2005-01-12 23:48 UTC (permalink / raw)
To: Goforth, Edward; +Cc: linuxppc-embedded
In-Reply-To: <9A48EF7239039B48834A3F6B644B0C71EF8679@vaff06-mail01.ad.gd-ais.com>
On Wed, Jan 12, 2005 at 06:25:45PM -0500, Goforth, Edward wrote:
> We have a 440gx based custom board. I have learned that it does not
> have a RTC. Has anyone had any success with a board without a RTC, or is
> it even possible? How much of a problem will this cause?
>
> Should we get the board respun with a RTC? We would prefer using a 2.4
> kernel, but would certainly go to a 2.6 kernel if that made things
> easier.
>
> Thanks in advance for any advice.
No problems. Just set your time from another source. Many PPC boards
do this that don't need local time retention across power cycles.
I've got a 440gx board sitting here running happily this way.
-Matt
^ 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