Using Linux 2.6.19 with Xilinx ML405

Using Linux 2.6.19 with Xilinx ML405

[Peter Mendham]

Dear all,

I am attempting to get a 2.6.19 kernel running on an ML405.  In the 
spirit of walking before I start to run, I have setup a very simple 
system with a 10/100 MAC, a UARTlite and the SystemACE controller (other 
than that, my EDK project has the DDR RAM,  some BRAM, an interrupt 
controller and the usual gubbins to get a system to work).  I am having 
some serious issues just getting the thing to compile so I was hoping to 
pick the brains of this list.  I would appreciate any tips on where I am 
going wrong.

First thing I did was to patch the kernel with the BSP from my EDK 
project (maybe this is my first mistake).  Several files #include 
config.h - I changed this to autoconf.h.  The ocp_def structure 
definition was being ignored because CONFIG_PPC_OCP was not defined - I 
altered some Kconfig files to ensure that when and an ML403 is selected 
XILINX_OCP is defined, and when that is defined PPC_OCP is also 
defined.  That solved that problem but left me with a missing definition 
for ppc_sys_platform_devices which was not present in virtex.c.  I added 
one but am a bit stuck as to what this should contain.  Another one I 
have seen lists a UART (which xilinx_ml403.c seems to depend upon).  But 
this is for a 8250-type UART.  How can I configure this for a UARTlite?  
Do I need to add an entry for the SystemACE?  I have already added an 
entry for the EMAC.

Any hints/experience would be gratefully received.

TIA,
-- Peter


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
MailScanner thanks transtec Computers for their support.

Re: Using Linux 2.6.19 with Xilinx ML405

[Andrei Konovalov]

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

Hi Peter,

CONFIG_PPC_OCP and ppc_sys_platform_devices related problems are
due to the kernel.org tree stopped using the OCP infrastructure in favor
of ppc_sys stuff (originally created for Freescale 8xx/8xxx SOCs).

What BSP vesion have you selected in the xps?
As far as I can tell, linux_2_6_v1_00_a uses
the approach similar to 2.6 kernel based MontaVista LSP:
"manual" registration of all the devices in arch/ppc/platforms/4xx/virtex.c,
static int __init xilinx_platform_init(void). The only exception
are 16x50 compatible UARTs, that rely on struct ocp_def core_ocp[] etc.

At the moment I am doing some rework of our code (includes rebasing the patches
against a more-or-less recent kernel.org tree). My plan is to drop
both PPC_OCP and ppc_sys, and register all the devices inside xilinx_platform_init().
For Xilinx'es using ppc_sys adds no value but some unneeded complexity.
And it seems ppc_sys is no longer used/supported after Freescale 8xx/8xxx SOCs
moved to arc/powerpc?
Having all the device registration (and references to xparameters.h as well!) in one
place IMHO would make it easier to move Xilinx based boards to arc/powerpc
(someday).

Attached is the patch to get rid of both XILINX_OCP and ppc_sys for
the Xilinx boards. With this patch applied it should be not so difficult
to add the relevant entries to arch/ppc/platforms/4xx/virtex.c by
copying them from the EDK generated linux_2_6_v1_00_a BSP.
The patch is against 2.6.21-rc4 if it matters.


Thanks,
Andrei


Peter Mendham wrote:
> Dear all,
> 
> I am attempting to get a 2.6.19 kernel running on an ML405.  In the 
> spirit of walking before I start to run, I have setup a very simple 
> system with a 10/100 MAC, a UARTlite and the SystemACE controller (other 
> than that, my EDK project has the DDR RAM,  some BRAM, an interrupt 
> controller and the usual gubbins to get a system to work).  I am having 
> some serious issues just getting the thing to compile so I was hoping to 
> pick the brains of this list.  I would appreciate any tips on where I am 
> going wrong.
> 
> First thing I did was to patch the kernel with the BSP from my EDK 
> project (maybe this is my first mistake).  Several files #include 
> config.h - I changed this to autoconf.h.  The ocp_def structure 
> definition was being ignored because CONFIG_PPC_OCP was not defined - I 
> altered some Kconfig files to ensure that when and an ML403 is selected 
> XILINX_OCP is defined, and when that is defined PPC_OCP is also 
> defined.  That solved that problem but left me with a missing definition 
> for ppc_sys_platform_devices which was not present in virtex.c.  I added 
> one but am a bit stuck as to what this should contain.  Another one I 
> have seen lists a UART (which xilinx_ml403.c seems to depend upon).  But 
> this is for a 8250-type UART.  How can I configure this for a UARTlite?  
> Do I need to add an entry for the SystemACE?  I have already added an 
> entry for the EMAC.
> 
> Any hints/experience would be gratefully received.
> 
> TIA,
> -- Peter
> 
> 


[-- Attachment #2: get-rid-of-ppc_sys.patch --]
[-- Type: text/x-patch, Size: 4261 bytes --]

Index: linux-2.6.20/arch/ppc/platforms/4xx/virtex.c
===================================================================
--- linux-2.6.20.orig/arch/ppc/platforms/4xx/virtex.c
+++ linux-2.6.20/arch/ppc/platforms/4xx/virtex.c
@@ -17,7 +17,6 @@
 #include <linux/module.h>
 #include <linux/device.h>
 #include <linux/serial_8250.h>
-#include <asm/ppc_sys.h>
 #include <platforms/4xx/virtex.h>
 #include <platforms/4xx/xparameters/xparameters.h>
 
@@ -30,7 +29,14 @@
 		.regshift = 2, \
 	}
 
-struct plat_serial8250_port serial_platform_data[] = {
+/* Xilinx Virtex-II Pro device descriptions */
+
+
+/*************************/
+/* 16x50 compatible UART */
+/*************************/
+
+static struct plat_serial8250_port serial_platform_data[] = {
 #ifdef XPAR_UARTNS550_0_BASEADDR
 	XPAR_UART(0),
 #endif
@@ -46,11 +52,24 @@ struct plat_serial8250_port serial_platf
 	{ }, /* terminated by empty record */
 };
 
-struct platform_device ppc_sys_platform_devices[] = {
-	[VIRTEX_UART] = {
-		.name		= "serial8250",
-		.id		= 0,
-		.dev.platform_data = serial_platform_data,
-	},
+void *xilinx_get_serial_pdata(void)
+{
+	return (void *) serial_platform_data;
+}
+
+static struct platform_device serial8250_platform_devices = {
+	.name		= "serial8250",
+	.id		= 0,
+	.dev.platform_data = serial_platform_data,
 };
 
+static int __init xilinx_platform_init(void)
+{
+#ifdef XPAR_UARTNS550_0_BASEADDR
+	platform_device_register(&serial8250_platform_devices);
+#endif
+
+	return 0;
+}
+
+subsys_initcall(xilinx_platform_init);
Index: linux-2.6.20/arch/ppc/platforms/4xx/virtex.h
===================================================================
--- linux-2.6.20.orig/arch/ppc/platforms/4xx/virtex.h
+++ linux-2.6.20/arch/ppc/platforms/4xx/virtex.h
@@ -23,13 +23,10 @@
 #if !defined(BASE_BAUD)
  #define BASE_BAUD		(0) /* dummy value; not used */
 #endif
-  
-/* Device type enumeration for platform bus definitions */
+
 #ifndef __ASSEMBLY__
-enum ppc_sys_devices {
-	VIRTEX_UART, NUM_PPC_SYS_DEVS,
-};
+void *xilinx_get_serial_pdata(void);
 #endif
-  
+
 #endif				/* __ASM_VIRTEX_H__ */
 #endif				/* __KERNEL__ */
Index: linux-2.6.20/arch/ppc/syslib/Makefile
===================================================================
--- linux-2.6.20.orig/arch/ppc/syslib/Makefile
+++ linux-2.6.20/arch/ppc/syslib/Makefile
@@ -18,7 +18,7 @@ obj-$(CONFIG_440SP)		+= ibm440gx_common.
 obj-$(CONFIG_440SPE)		+= ibm440gx_common.o ibm440sp_common.o ppc440spe_pcie.o
 ifeq ($(CONFIG_4xx),y)
 ifeq ($(CONFIG_XILINX_VIRTEX),y)
-obj-$(CONFIG_40x)		+= xilinx_pic.o ppc_sys.o
+obj-$(CONFIG_40x)		+= xilinx_pic.o
 else
 ifeq ($(CONFIG_403),y)
 obj-$(CONFIG_40x)		+= ppc403_pic.o
Index: linux-2.6.20/arch/ppc/platforms/4xx/xilinx_ml403.c
===================================================================
--- linux-2.6.20.orig/arch/ppc/platforms/4xx/xilinx_ml403.c
+++ linux-2.6.20/arch/ppc/platforms/4xx/xilinx_ml403.c
@@ -22,7 +22,6 @@
 #include <linux/serialP.h>
 #include <asm/io.h>
 #include <asm/machdep.h>
-#include <asm/ppc_sys.h>
 
 #include <syslib/gen550.h>
 #include <platforms/4xx/xparameters/xparameters.h>
@@ -57,22 +56,6 @@
  *          ppc4xx_pic_init			arch/ppc/syslib/xilinx_pic.c
  */
 
-/* Board specifications structures */
-struct ppc_sys_spec *cur_ppc_sys_spec;
-struct ppc_sys_spec ppc_sys_specs[] = {
-	{
-		/* Only one entry, always assume the same design */
-		.ppc_sys_name	= "Xilinx ML403 Reference Design",
-		.mask 		= 0x00000000,
-		.value 		= 0x00000000,
-		.num_devices	= 1,
-		.device_list	= (enum ppc_sys_devices[])
-		{
-			VIRTEX_UART,
-		},
-	},
-};
-
 #if defined(XPAR_POWER_0_POWERDOWN_BASEADDR)
 
 static volatile unsigned *powerdown_base =
@@ -125,7 +108,7 @@ ml403_early_serial_map(void)
 	struct plat_serial8250_port *pdata;
 	int i = 0;
 
-	pdata = (struct plat_serial8250_port *) ppc_sys_get_pdata(VIRTEX_UART);
+	pdata = (struct plat_serial8250_port *) xilinx_get_serial_pdata();
 	while(pdata && pdata->flags)
 	{
 		pdata->membase = ioremap(pdata->mapbase, 0x100);
@@ -159,8 +142,6 @@ platform_init(unsigned long r3, unsigned
 {
 	ppc4xx_init(r3, r4, r5, r6, r7);
 
-	identify_ppc_sys_by_id(mfspr(SPRN_PVR));
-
 	ppc_md.setup_arch = ml403_setup_arch;
 	ppc_md.setup_io_mappings = ml403_map_io;
 	ppc_md.init_IRQ = ml403_init_irq;

Re: Using Linux 2.6.19 with Xilinx ML405

[Peter Mendham]

Hi Andrei,

Thanks for your reply
> CONFIG_PPC_OCP and ppc_sys_platform_devices related problems are due 
> to the kernel.org tree stopped using the OCP infrastructure in favor 
> of ppc_sys stuff (originally created for Freescale 8xx/8xxx SOCs).
Excellent - thanks for explaining this.  I had wondered whether this was 
the case but didn't want to do anything drastic without understanding 
what was going on.
> What BSP vesion have you selected in the xps? As far as I can tell, 
> linux_2_6_v1_00_a uses the approach similar to 2.6 kernel based 
> MontaVista LSP: "manual" registration of all the devices in 
> arch/ppc/platforms/4xx/virtex.c, static int __init 
> xilinx_platform_init(void). The only exception are 16x50 compatible 
> UARTs, that rely on struct ocp_def core_ocp[] etc.
I had selected linux_2_6_v1_00_a also, I just wasn't sure how "current" 
some of the generated code was.
> At the moment I am doing some rework of our code (includes rebasing 
> the patches against a more-or-less recent kernel.org tree). My plan is 
> to drop both PPC_OCP and ppc_sys, and register all the devices inside 
> xilinx_platform_init(). For Xilinx'es using ppc_sys adds no value but 
> some unneeded complexity. And it seems ppc_sys is no longer 
> used/supported after Freescale 8xx/8xxx SOCs moved to arc/powerpc? 
> Having all the device registration (and references to xparameters.h as 
> well!) in one place IMHO would make it easier to move Xilinx based 
> boards to arc/powerpc (someday).
OK, that is also good to know.  I buy your argument, so I'd like to use 
the "manual" approach.  However, when I tried compiling there was some 
code that expected a ppc_sys_platform_devices (and a ppc_sys_specs).  Am 
I right in thinking that your patch sorts this out?
> Attached is the patch to get rid of both XILINX_OCP and ppc_sys for 
> the Xilinx boards. With this patch applied it should be not so 
> difficult to add the relevant entries to 
> arch/ppc/platforms/4xx/virtex.c by copying them from the EDK generated 
> linux_2_6_v1_00_a BSP. The patch is against 2.6.21-rc4 if it matters.
Brilliant!  Thanks.  The code your patch produces expects there to be an 
8250 compatible UART around.  What happens if I only have a UARTlite?  
What do I need to fill in to a platform_device structure for a 
UARTlite?  I have just moved to 2.6.20 kernel in the hope of using the 
mainline uartlite driver - was this a stupid thing to do?  Do you know 
if I can use it for early serial in the same way as an 8250?

Many thanks for your help,

-- Peter

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
MailScanner thanks transtec Computers for their support.

Re: Using Linux 2.6.19 with Xilinx ML405

[Peter Korsgaard]

>>>>> "PM" == Peter Mendham <petermendham@computing.dundee.ac.uk> writes:

Hi,

PM> Brilliant!  Thanks.  The code your patch produces expects there to
PM> be an 8250 compatible UART around.  What happens if I only have a
PM> UARTlite?  What do I need to fill in to a platform_device
PM> structure for a UARTlite?

Something like:

static struct resource myboarduartlite_resources[] = {
	[0] = {
		.start  = 0xa1000003,
		.end    = 0xa1000012,
		.flags  = IORESOURCE_MEM,
	},
	[1] = {
		.start	= 2,
		.end	= 2,
		.flags	= IORESOURCE_IRQ,
	},
};

static struct platform_device myboard_uartlite = {
	.name			= "uartlite",
	.id			= 0,
	.num_resources		= ARRAY_SIZE(myboarduartlite_resources),
	.resource		= myboarduartlite_resources,
};

static struct platform_device *myboard_devices[] __initdata = {
	..
	&myboard_uartlite,
        ..
};

static int __init
myboard_platform_add_devices(void)
{
	return platform_add_devices(myboard_devices,
                ARRAY_SIZE(myboard_devices));

}
arch_initcall(myboard_platform_add_devices);

Notice the +3 for the base address as the registers are accessed using
8bit I/O.

PM> I have just moved to 2.6.20 kernel in the hope of using the
PM> mainline uartlite driver - was this a stupid thing to do?

Not if you ask me ;)

PM> Do you know if I can use it for early serial in the same way as an
PM> 8250?

Unfortunately not. I started working on some patches for this some
months ago, but got stalled doing other stuff. I doubt it will get
integrated before the move to arch/powerpc.

-- 
Bye, Peter Korsgaard

Re: Using Linux 2.6.19 with Xilinx ML405

[David H. Lynch Jr.]

>
> PM> Do you know if I can use it for early serial in the same way as an
> PM> 8250?
>
> Unfortunately not. I started working on some patches for this some
> months ago, but got stalled doing other stuff. I doubt it will get
> integrated before the move to arch/powerpc.
>   
I posted working early serial patches as part of an earlier uartlite
driver (not PK's)
http://ozlabs.org/pipermail/linuxppc-embedded/2006-January/021545.html

The patch is a single big patch with compete board support for the Pico
E12 cards,
but it includes complete boot2bash uartlite support, including early serial.
The uartlite code much more closely follows the 8250 code.
The early serial portions probably would work asis with PK's driver. 
Though I can't confirm that as PK's driver does not work on my hardware.
A newer version of the same big patch is at
http://www.picocomputing.com/software/files/Installers/coLinux/Pico-2.6.patch.bz2
When I have more time and am more proficient with git I will likely break
it up into individual pieces.


-- 
Dave Lynch 					  	    DLA Systems
Software Development:  				         Embedded Linux
717.627.3770 	       dhlii@dlasys.net 	  http://www.dlasys.net
fax: 1.253.369.9244 			           Cell: 1.717.587.7774
Over 25 years' experience in platforms, languages, and technologies too numerous to list.

"Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction."
Albert Einstein

Re: Using Linux 2.6.19 with Xilinx ML405

[Andrei Konovalov]

Hi Peter,

Peter Mendham wrote:
> Hi Andrei,
> 
> Thanks for your reply
>> CONFIG_PPC_OCP and ppc_sys_platform_devices related problems are due 
>> to the kernel.org tree stopped using the OCP infrastructure in favor 
>> of ppc_sys stuff (originally created for Freescale 8xx/8xxx SOCs).
> Excellent - thanks for explaining this.  I had wondered whether this was 
> the case but didn't want to do anything drastic without understanding 
> what was going on.
>> What BSP vesion have you selected in the xps? As far as I can tell, 
>> linux_2_6_v1_00_a uses the approach similar to 2.6 kernel based 
>> MontaVista LSP: "manual" registration of all the devices in 
>> arch/ppc/platforms/4xx/virtex.c, static int __init 
>> xilinx_platform_init(void). The only exception are 16x50 compatible 
>> UARTs, that rely on struct ocp_def core_ocp[] etc.
> I had selected linux_2_6_v1_00_a also, I just wasn't sure how "current" 
> some of the generated code was.
>> At the moment I am doing some rework of our code (includes rebasing 
>> the patches against a more-or-less recent kernel.org tree). My plan is 
>> to drop both PPC_OCP and ppc_sys, and register all the devices inside 
>> xilinx_platform_init(). For Xilinx'es using ppc_sys adds no value but 
>> some unneeded complexity. And it seems ppc_sys is no longer 
>> used/supported after Freescale 8xx/8xxx SOCs moved to arc/powerpc? 
>> Having all the device registration (and references to xparameters.h as 
>> well!) in one place IMHO would make it easier to move Xilinx based 
>> boards to arc/powerpc (someday).
> OK, that is also good to know.  I buy your argument, so I'd like to use 
> the "manual" approach.  However, when I tried compiling there was some 
> code that expected a ppc_sys_platform_devices (and a ppc_sys_specs).  Am 
> I right in thinking that your patch sorts this out?

Yes, my patch makes the Xilinx board not to use ppc_sys[whatever]

>> Attached is the patch to get rid of both XILINX_OCP and ppc_sys for 
>> the Xilinx boards. With this patch applied it should be not so 
>> difficult to add the relevant entries to 
>> arch/ppc/platforms/4xx/virtex.c by copying them from the EDK generated 
>> linux_2_6_v1_00_a BSP. The patch is against 2.6.21-rc4 if it matters.
> Brilliant!  Thanks.  The code your patch produces expects there to be an 
> 8250 compatible UART around.

The code supports 8250 compatible UART, but not having 8250 is OK as well.
As long as you have some alternative console device ;)

> What happens if I only have a UARTlite?  
> What do I need to fill in to a platform_device structure for a 
> UARTlite?

It depends on the UARTlite driver you use...

> I have just moved to 2.6.20 kernel in the hope of using the 
> mainline uartlite driver - was this a stupid thing to do?  Do you know 
> if I can use it for early serial in the same way as an 8250?

At the moment there is no uartlite driver accepted into the mainline
(or whatever community) tree.
There were several postings to this list. Can't recall if the final patch
has been attached to any of them. But at least people were saying
they have the driver almost ready to go to the community.
MontaVista has UARTlite driver in Pro 4.0 release, but it is
not platform device (yet), and I'd prefer not to publish it
until it becomes a platform device. And it probably should not
use generic_serial.c any more (the current one does).

As for early serial, it should work.

> Many thanks for your help,
> 
> -- Peter

Re: Using Linux 2.6.19 with Xilinx ML405

[Peter Korsgaard]

>>>>> "AK" == Andrei Konovalov <akonovalov@ru.mvista.com> writes:

Hi,

AK> At the moment there is no uartlite driver accepted into the
AK> mainline (or whatever community) tree.  There were several
AK> postings to this list. Can't recall if the final patch has been
AK> attached to any of them. But at least people were saying they have
AK> the driver almost ready to go to the community.  MontaVista has
AK> UARTlite driver in Pro 4.0 release, but it is not platform device
AK> (yet), and I'd prefer not to publish it until it becomes a
AK> platform device. And it probably should not use generic_serial.c
AK> any more (the current one does).

My uartlite driver is in mainline since 2.6.20.

-- 
Bye, Peter Korsgaard

RE: Using Linux 2.6.19 with Xilinx ML405

[Leonid]

Take a look in 2.6.20 kernel - it's said to be supporting uartlite - u =
can port it back to 2.6.19.

-----Original Message-----
From: "Peter Korsgaard" <jacmet@sunsite.dk>
To: "linuxppc-embedded@ozlabs.org" <linuxppc-embedded@ozlabs.org>
Sent: 4/4/07 6:33 AM
Subject: Re: Using Linux 2.6.19 with Xilinx ML405

>>>>> "PM" =3D=3D Peter Mendham <petermendham@computing.dundee.ac.uk> =
writes:

Hi,

PM> Brilliant!  Thanks.  The code your patch produces expects there to
PM> be an 8250 compatible UART around.  What happens if I only have a
PM> UARTlite?  What do I need to fill in to a platform_device
PM> structure for a UARTlite?

Something like:

static struct resource myboarduartlite_resources[] =3D {
	[0] =3D {
		.start  =3D 0xa1000003,
		.end    =3D 0xa1000012,
		.flags  =3D IORESOURCE_MEM,
	},
	[1] =3D {
		.start	=3D 2,
		.end	=3D 2,
		.flags	=3D IORESOURCE_IRQ,
	},
};

static struct platform_device myboard_uartlite =3D {
	.name			=3D "uartlite",
	.id			=3D 0,
	.num_resources		=3D ARRAY_SIZE(myboarduartlite_resources),
	.resource		=3D myboarduartlite_resources,
};

static struct platform_device *myboard_devices[] __initdata =3D {
	..
	&myboard_uartlite,
        ..
};

static int __init
myboard_platform_add_devices(void)
{
	return platform_add_devices(myboard_devices,
                ARRAY_SIZE(myboard_devices));

}
arch_initcall(myboard_platform_add_devices);

Notice the +3 for the base address as the registers are accessed using
8bit I/O.

PM> I have just moved to 2.6.20 kernel in the hope of using the
PM> mainline uartlite driver - was this a stupid thing to do?

Not if you ask me ;)

PM> Do you know if I can use it for early serial in the same way as an
PM> 8250?

Unfortunately not. I started working on some patches for this some
months ago, but got stalled doing other stuff. I doubt it will get
integrated before the move to arch/powerpc.

--=20
Bye, Peter Korsgaard
_______________________________________________
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded