Using Linux 2.6.19 with Xilinx ML405

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.

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

Index: 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
===================================================================
@@ -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
===================================================================
@@ -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
===================================================================
@@ -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;

Hi Andrei,

Thanks for your reply

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.

I had selected linux_2_6_v1_00_a also, I just wasn't sure how "current" some of the generated code was.

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?

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.

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

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 	       [email protected] 	  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

Hi Peter,

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

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

It depends on the UARTlite driver you use...

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.

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