status of mpc52xx with arch=powerpc?

status of mpc52xx with arch=powerpc?

[Sascha Hauer]

Is someone working on this already?

There are some Kconfig entries, but there seems to be no code, at least
not in vanilla.

Sascha

-- 
 Dipl.-Ing. Sascha Hauer | http://www.pengutronix.de
  Pengutronix - Linux Solutions for Science and Industry
    Handelsregister: Amtsgericht Hildesheim, HRA 2686
      Hannoversche Str. 2, 31134 Hildesheim, Germany
    Phone: +49-5121-206917-0 |  Fax: +49-5121-206917-9

Re: status of mpc52xx with arch=powerpc?

[Grant Likely]

On 10/18/06, Sascha Hauer <s.hauer@pengutronix.de> wrote:
> Is someone working on this already?
>
> There are some Kconfig entries, but there seems to be no code, at least
> not in vanilla.

I'm slowly working on it.  I've got a .dts written and I've got u-boot
w/ the fdt patches running on the board.  I need to port the 52xx PIC
driver into arch/powerpc before I attempt to boot.

g.

-- 
Grant Likely, B.Sc. P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195

Re: status of mpc52xx with arch=powerpc?

[Sascha Hauer]

On Wed, Oct 18, 2006 at 07:52:02AM -0600, Grant Likely wrote:
> On 10/18/06, Sascha Hauer <s.hauer@pengutronix.de> wrote:
> >Is someone working on this already?
> >
> >There are some Kconfig entries, but there seems to be no code, at least
> >not in vanilla.
> 
> I'm slowly working on it.  I've got a .dts written and I've got u-boot
> w/ the fdt patches running on the board.  I need to port the 52xx PIC
> driver into arch/powerpc before I attempt to boot.

Could you post your .dts?
I'm too working on it, so maybe we should stay synchronized. At the
moment I have nothing but a minimal dts and some .progress() messages.

Sascha

-- 
 Dipl.-Ing. Sascha Hauer | http://www.pengutronix.de
  Pengutronix - Linux Solutions for Science and Industry
    Handelsregister: Amtsgericht Hildesheim, HRA 2686
      Hannoversche Str. 2, 31134 Hildesheim, Germany
    Phone: +49-5121-206917-0 |  Fax: +49-5121-206917-9

Re: status of mpc52xx with arch=powerpc?

[Roman Fietze]

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

Hello,

On Thursday 19 October 2006 10:13, Sascha Hauer wrote:

> Could you post your .dts?
> I'm too working on it, so maybe we should stay synchronized. At the
> moment I have nothing but a minimal dts and some .progress() messages.

Could you both double check e.g. with Sylvain Munaut at

  http://246tnt.com/mpc52xx/

There are many drivers (git heads) available already, including IDE,
FEC, and so on. There's also new BestComm/FEC/IDE code from Dale
Farnsworth and John Rigby (Freescale) somewhere on the net.

I've already opened my own branch using DENX 2.6 and several patches
from Sylvain, Dale and John and got a first working 2.6 for the
MPC5200 including DMA driven FEC and IDE. Sylvain promised to get in
touch with the 2.6 maintainers to incorporate his changes into vanilla
2.6. I don't know if he still works on that since his server crashed a
few months ago, that's why I didn't do anything about it.


Here's a part of a mail I got from John in 2006-05:

"Sylvain Munaut is working on a different bestcomm patch.  It's much
cleaner and is based on bestcomm code written by Dale Farnsworth.

You can search the mailing list for a pointer to Sylvain's git tree."


I assume that's what I have here, spinning around with 15k for a few
months now.


Roman

-- 
Roman Fietze              Telemotive AG Büro Mühlhausen
Breitwiesen                            73347 Mühlhausen
Tel.: +49(0)7335/18493-45      http://www.telemotive.de


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: status of mpc52xx with arch=powerpc?

[Sascha Hauer]

On Thu, Oct 19, 2006 at 11:49:07AM +0200, Roman Fietze wrote:
> Hello,
> 
> On Thursday 19 October 2006 10:13, Sascha Hauer wrote:
> 
> > Could you post your .dts?
> > I'm too working on it, so maybe we should stay synchronized. At the
> > moment I have nothing but a minimal dts and some .progress() messages.
> 
> Could you both double check e.g. with Sylvain Munaut at
> 
>   http://246tnt.com/mpc52xx/

I have his tree here and and it does not seem to contain bits for
mpc52xx with arch=powerpc (unless there are some git-secrets I'm not
aware of)

> 
> There are many drivers (git heads) available already, including IDE,
> FEC, and so on. There's also new BestComm/FEC/IDE code from Dale
> Farnsworth and John Rigby (Freescale) somewhere on the net.
> 

We have these drivers running already with arch=ppc. I have not looked
into it deeper, but I think (well, hope) they only need minor changes
like a transition from platform_device to of_device.

I just received a patch from nicolas det with a port from ppc to
powerpc, I'll have a look at it. He posted it on linuxppc-dev

Sascha

-- 
 Dipl.-Ing. Sascha Hauer | http://www.pengutronix.de
  Pengutronix - Linux Solutions for Science and Industry
    Handelsregister: Amtsgericht Hildesheim, HRA 2686
      Hannoversche Str. 2, 31134 Hildesheim, Germany
    Phone: +49-5121-206917-0 |  Fax: +49-5121-206917-9

Re: status of mpc52xx with arch=powerpc?

[Grant Likely]

On 10/19/06, Roman Fietze <roman.fietze@telemotive.de> wrote:
> Could you both double check e.g. with Sylvain Munaut at

If Sylvain is around and has available bandwidth, I'm sure he is
monitoring this list.

> There are many drivers (git heads) available already, including IDE,
> FEC, and so on. There's also new BestComm/FEC/IDE code from Dale
> Farnsworth and John Rigby (Freescale) somewhere on the net.

Yes, I'm using those patches; but they don't help with getting the
mpc52xx moved over to arch/powerpc

-- 
Grant Likely, B.Sc. P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195

Re: status of mpc52xx with arch=powerpc?

[John Rigby]

Last time I offered to help Sylvain with the migration to powerpc he said:

>Frankly ... I don't know, I don't get how this new thing works ...
>if you figure it out, be my guest do it and explain it to me ;)

>It would be great because I get this cleaned API sitting on my
>tree along with the IDE DMA and the FEC code that I'd really
>like to send ...

Unfortunately I haven't been able to work on it either.

On 10/19/06, Grant Likely <grant.likely@secretlab.ca> wrote:
> On 10/19/06, Roman Fietze <roman.fietze@telemotive.de> wrote:
> > Could you both double check e.g. with Sylvain Munaut at
>
> If Sylvain is around and has available bandwidth, I'm sure he is
> monitoring this list.
>
> > There are many drivers (git heads) available already, including IDE,
> > FEC, and so on. There's also new BestComm/FEC/IDE code from Dale
> > Farnsworth and John Rigby (Freescale) somewhere on the net.
>
> Yes, I'm using those patches; but they don't help with getting the
> mpc52xx moved over to arch/powerpc
>
> --
> Grant Likely, B.Sc. P.Eng.
> Secret Lab Technologies Ltd.
> grant.likely@secretlab.ca
> (403) 399-0195
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>

Re: status of mpc52xx with arch=powerpc?

[Benjamin Herrenschmidt]

On Wed, 2006-10-18 at 07:52 -0600, Grant Likely wrote:
> On 10/18/06, Sascha Hauer <s.hauer@pengutronix.de> wrote:
> > Is someone working on this already?
> >
> > There are some Kconfig entries, but there seems to be no code, at least
> > not in vanilla.
> 
> I'm slowly working on it.  I've got a .dts written and I've got u-boot
> w/ the fdt patches running on the board.  I need to port the 52xx PIC
> driver into arch/powerpc before I attempt to boot.

Can you send me your .dts ? The bplan folks are doing things for their
EFIKA board and I didn't manage to get them to open up publically their
device-tree until the firmware is final and in production :( But I've
got them to change a few things already, and I'd like to make sure
things are in sync.

Regarding devices, I want to move everything to of_platform_device. I
have some patches in progress to make those easier to work with. I'll
send something in the upcoming couple of days as it's all part of some
Cell related work for a new southbridge.

I'm trying to make sure the bplan stuff and whatever you guys come up
with don't conflict.

Ben.

Re: status of mpc52xx with arch=powerpc?

[Grant Likely]

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

On 10/24/06, Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> Can you send me your .dts ?

Here you go; for discussion purposes only!  :)

This is pretty rough stuff, and it haven't even got to the point of
using it to boot a kernel.  But if it's a starting point to figure out
what the 52xx device tree should look like then go to it!

g.


-- 
Grant Likely, B.Sc. P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195

[-- Attachment #2: lite5200b.dts --]
[-- Type: application/octet-stream, Size: 5022 bytes --]

/*
 * Lite5200b board Device Tree Source
 *
 * Copyright 2006 Secret Lab Technologies Ltd.
 * Grant Likely <grant.likely@secretlab.ca>
 *
 * This program is free software; you can redistribute  it and/or modify it
 * under  the terms of  the GNU General  Public License as published by the
 * Free Software Foundation;  either version 2 of the  License, or (at your
 * option) any later version.
 */

/ {
	model = "Lite5200b";
	compatible = "mpc52xx";
	#address-cells = <1>;
	#size-cells = <1>;

	cpus {
		#cpus = <1>;
		#address-cells = <1>;
		#size-cells = <0>;

		PowerPC,5200@0 {
			device_type = "cpu";
			reg = <0>;
			d-cache-line-size = <20>;
			i-cache-line-size = <20>;
			d-cache-size = <4000>;		// L1, 16K
			i-cache-size = <4000>;		// L1, 16K
			timebase-frequency = <0>;	// from bootloader
			bus-frequency = <0>;		// from bootloader
			clock-frequency = <0>;		// from bootloader
			32-bit;
		};
	};

	memory {
		device_type = "memory";
		reg = <00000000 10000000>;	// 256MB
	};

	soc5200@f0000000 {
		#address-cells = <1>;
		#size-cells = <1>;
		#interrupt-cells = <2>;
		device_type = "soc";
		ranges = <0 f0000000 f0010000>;
		reg = <f0000000 00010000>;
		bus-frequency = <0>;

		pic@500 {
			linux,phandle = <500>;
			interrupt-controller;
			#address-cells = <0>;
			#interrupt-cells = <2>;
			reg = <500 80>;
			built-in;
			device_type = "52xx-pic";
		};

		gpt@600 {	// General Purpose Timers
			// Should this be here at all?
			// Or should there be one entry per timer (8 total)?
			compatible = "5200";
			device_type = "gpt";
			reg = <600 100>;
			interrupts = <0e 2 0f 2 10 2 11 2
			              12 2 13 2 14 2 14 2>;
			interrupt-parent = <500>;
		};

		rtc@800 {	// Real time clock
			// Should this be here at all?
			compatible = "5200";
			device_type = "rtc";
			reg = <800 100>;
			interrupts = <0a 2 0b 2>;
			interrupt-parent = <500>;
		};

		mscan@900 {
			compatible = "5200";
			device_type = "mscan";
			interrupts = <37 2>;
			interrupt-parent = <500>;
			reg = <900 80>;
		};

		mscan@980 {
			compatible = "5200";
			device_type = "mscan";
			interrupts = <38 2>;
			interrupt-parent = <500>;
			reg = <980 80>;
		};

		gpio@b00 {
			compatible = "5200";
			device_type = "gpio";
			reg = <b00 100>;
		};

		gpio_wkup@c00 {
			compatible = "5200";
			device_type = "gpio-wkup";
			reg = <c00 100>;
		};

		pci@0d00 {
			#interrupt-cells = <1>;
			#size-cells = <2>;
			#address-cells = <3>;
			compatible = "5200";
			device_type = "pci";
			// I actually know very little about setting up PCI,
			// so anything here would just be pulled out of my
			// butt.  Instead I'll leave these placeholders until
			// I figure out what it should be
			//
			// interrupt-map-mask = <>;
			// interrupt-map = <>;
			// bus-range = <>;
			// ranges = <>;
			//
			clock-frequency = <3f940aa>;
			interrupts = <2f 2 30 2 31 2>;
			interrupt-parent = <500>;
		};

		spi@f00 {
			device_type = "spi";
			compatible = "5200";
			reg = <f00 20>;
			interrupts = <34 2 35 2>;
			interrupt-parent = <500>;
		};

		serial@2000 {		// PSC1
			device_type = "serial";
			compatible = "5200-psc";
			reg = <2000 100>;
			clock-frequency = <0>;
			interrupts = <28 2>;
			interrupt-parent = <500>;
		};

		// PSC2 in spi mode example
		spi@2200 {		// PSC2
			device_type = "spi";
			compatible = "5200-psc";
			reg = <2200 100>;
			clock-frequency = <0>;
			interrupts = <29 2>;
			interrupt-parent = <500>;
		};

		// PSC3 in CODEC mode example
		i2s@2400 {		// PSC3
			device_type = "i2s";
			compatible = "5200-psc";
			reg = <2400 100>;
			clock-frequency = <0>;
			interrupts = <2a 2>;
			interrupt-parent = <500>;
		};

		// PSC4 unconfigured (example of AC97 mode)
		//@2600 {		// PSC4
		//	device_type = "serial";
		//	compatible = "5200-psc";
		//	reg = <2600 100>;
		//	clock-frequency = <0>;
		//	interrupts = <32 2>;
		//	interrupt-parent = <500>;
		//};

		// PSC5 unconfigured
		//serial@2800 {		// PSC5
		//	device_type = "serial";
		//	compatible = "5200-psc";
		//	reg = <2800 100>;
		//	clock-frequency = <0>;
		//	interrupts = <33 2>;
		//	interrupt-parent = <500>;
		//};

		// PSC6 in AC97 mode example
		ac97@2c00 {		// PSC6
			device_type = "ac97";
			compatible = "5200-psc";
			reg = <2c00 100>;
			clock-frequency = <0>;
			interrupts = <2b 2>;
			interrupt-parent = <500>;
		};

		ethernet@3000 {
			#address-cells = <1>;
			#size-cells = <0>;
			device_type = "network";
			model = "FEC";
			compatible = "5200";
			reg = <3000 800>;
			mac-address = [ 02 03 04 05 06 07 ]; // Bad!
			interrupts = <2c 2>;
			interrupt-parent = <500>;
		};

		ata@3a00 {
			device_type = "ata";
			compatible = "5200";
			reg = <3a00 100>;
			interrupts = <2e 2>;
			interrupt-parent = <500>;
		};

		i2c@3d00 {
			device_type = "i2c";
			compatible = "5200";
			reg = <3d00 40>;
			interrupts = <35 2>;
			interrupt-parent = <500>;
		};

		i2c@3d40 {
			device_type = "i2c";
			compatible = "5200";
			reg = <3d40 40>;
			interrupts = <36 2>;
			interrupt-parent = <500>;
		};
	};
};

Re: status of mpc52xx with arch=powerpc?

[John Rigby]

Does Bestcomm dma belong in here somewhere?

On 10/25/06, Grant Likely <grant.likely@secretlab.ca> wrote:
> On 10/24/06, Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> > Can you send me your .dts ?
>
> Here you go; for discussion purposes only!  :)
>
> This is pretty rough stuff, and it haven't even got to the point of
> using it to boot a kernel.  But if it's a starting point to figure out
> what the 52xx device tree should look like then go to it!
>
> g.
>
>
> --
> Grant Likely, B.Sc. P.Eng.
> Secret Lab Technologies Ltd.
> grant.likely@secretlab.ca
> (403) 399-0195
>
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
>
>

Re: status of mpc52xx with arch=powerpc?

[Grant Likely]

On 10/26/06, John Rigby <jcrigby@gmail.com> wrote:
> Does Bestcomm dma belong in here somewhere?

I don't think so for embedded targets; but I may be wrong.  Of course;
I think the kernel should be responsible for setting up the bestcomm
tasks.  If a spec is defined for how firmware could preload bestcomm
tasks, then maybe.

g.

-- 
Grant Likely, B.Sc. P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195

Re: status of mpc52xx with arch=powerpc?

[Sylvain Munaut]

Grant Likely wrote:
> On 10/26/06, John Rigby <jcrigby@gmail.com> wrote:
>> Does Bestcomm dma belong in here somewhere?
>
> I don't think so for embedded targets; but I may be wrong.  Of course;
> I think the kernel should be responsible for setting up the bestcomm
> tasks.  If a spec is defined for how firmware could preload bestcomm
> tasks, then maybe.
Yes, we discussed that on IRC.
For I got from it would be something like that :

We would use the API we worked earlier on (Dale, Andrey, John, ...).
To add support of fw preloaded task :
 - The bestcomm.ko module would be used when bestcomm is completely
controlled by the kernel
- A different module but with the same exported function would be used
when the fw has a part to play in the init. That allows to customize a bunch
of the sdma init / sram mapping ...
- All the other code (task helpers / the .h / the driver api) would be
exactly
the same.
- Currently the task support code (the arch/ppc/syslib/fec.c for example in
the current code) does this :

        struct sdma_task *tsk;

        tsk = sdma_task_alloc(queue_len, sizeof(struct sdma_fec_bd));
        if (!tsk)
                return NULL;

To reuse the preloaded task, it would be changed to

    tsk = sdma_task_find_by_name("fec", 0);
    if (!tsk)
        tsk = sdma_task_alloc("fec", 0, queue_len, sizeof(struct
sdma_fec_bd));
    if (!tsk)
        return NULL;

So the bestcomm modules maintain a list with all task loaded with a name and
a index attribute. (The index would be used when there is multiple
device with
the same name, like "psc". We could use names like "psc1", "psc2". But that
would imply string manipulation to "create" the name string ;)

In the case of the "classic" (kernel handles it all), the table of task
is just
initially empty. But for the "custom" case, it's filled with whatever
the fw has
passed as infos.



        Sylvain

Re: status of mpc52xx with arch=powerpc?

[Benjamin Herrenschmidt]

> We would use the API we worked earlier on (Dale, Andrey, John, ...).
> To add support of fw preloaded task :
>  - The bestcomm.ko module would be used when bestcomm is completely
> controlled by the kernel
> - A different module but with the same exported function would be used
> when the fw has a part to play in the init. That allows to customize a bunch
> of the sdma init / sram mapping ...
> - All the other code (task helpers / the .h / the driver api) would be
> exactly
> the same.

No. Two different modules is the wrong approach. I want to be able to
build everything in the kernel (no modules) and still boot machines with
both types.

There should be a single implementation. I know bestcomm is fucked by
design but still.

> So the bestcomm modules maintain a list with all task loaded with a name and
> a index attribute. (The index would be used when there is multiple
> device with
> the same name, like "psc". We could use names like "psc1", "psc2". But that
> would imply string manipulation to "create" the name string ;)
> 
> In the case of the "classic" (kernel handles it all), the table of task
> is just
> initially empty. But for the "custom" case, it's filled with whatever
> the fw has
> passed as infos.

A single module should handle all cases though. If, for some reasons, it
looks like that will cause a lot of additional code, them it can be
internally split and we can have config options to enable only one way,
but it should be possible to enable both.

Ben.