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. _______________________________________________ Linuxppc-embedded mailing list [email protected] https://ozlabs.org/mailman/listinfo/linuxppc-embedded
