[PATCH][RFC] Second version of MPC10x OCP
On Jun 20, 2004, at 10:47 AM, Adrian Cox wrote: > Here's the second version of OCP-ifying the mpc10x. I've removed the > hardcoded positions in the core_ocp array, and I've added the DMA > devices in case anybody needs them. I haven't yet tested the I2C driver > from 2.4, but I've put in the flags field for it. > - Adrian Cox > Humboldt Solutions Ltd. > > # This is a BitKeeper generated diff -Nru style patch. > # > # ChangeSet > # 2004/06/20 16:25:45+01:00 adrian at humboldt.co.uk > # Add OCP code for MPC10x, and a common Openpic setup routine. > # > # include/asm-ppc/mpc10x.h > # 2004/06/20 16:25:10+01:00 adrian at humboldt.co.uk +3 -0 > # Add Openpic setup routine. > # > # arch/ppc/syslib/mpc10x_common.c > # 2004/06/20 16:25:10+01:00 adrian at humboldt.co.uk +79 -2 > # Add MPC10x OCP code, and a standard Openpic setup routine. > # > # arch/ppc/syslib/Makefile > # 2004/06/20 16:25:10+01:00 adrian at humboldt.co.uk +4 -4 > # Add common MPC10x openpic config option. > # > # arch/ppc/platforms/sandpoint.c > # 2004/06/20 16:25:10+01:00 adrian at humboldt.co.uk +1 -11 > # Use common Openpic setup. > # > # arch/ppc/platforms/powerpmc250.c > # 2004/06/20 16:25:10+01:00 adrian at humboldt.co.uk +1 -1 > # Use common Openpic setup. > # > # arch/ppc/platforms/lopec_setup.c > # 2004/06/20 16:25:10+01:00 adrian at humboldt.co.uk +1 -14 > # Use common Openpic setup. > # > # arch/ppc/Kconfig > # 2004/06/20 16:25:10+01:00 adrian at humboldt.co.uk +10 -0 > # Add OCP and common Openpic code for MPC10x boards. > # > diff -Nru a/arch/ppc/Kconfig b/arch/ppc/Kconfig > --- a/arch/ppc/KconfigSun Jun 20 16:40:17 2004 > +++ b/arch/ppc/KconfigSun Jun 20 16:40:17 2004 > @@ -685,6 +685,16 @@ > depends on PCORE || POWERPMC250 || LOPEC || SANDPOINT > default y > > +config FSL_OCP > + bool > + depends on MPC10X_BRIDGE > + default y > + > +config MPC10X_OPENPIC > + bool > + depends on POWERPMC250 || LOPEC || SANDPOINT > + default y > + > config MPC10X_STORE_GATHERING > bool "Enable MPC10x store gathering" > depends on MPC10X_BRIDGE > diff -Nru a/arch/ppc/platforms/lopec_setup.c > b/arch/ppc/platforms/lopec_setup.c > --- a/arch/ppc/platforms/lopec_setup.cSun Jun 20 16:40:17 2004 > +++ b/arch/ppc/platforms/lopec_setup.cSun Jun 20 16:40:17 2004 > @@ -193,21 +193,8 @@ > OpenPIC_InitSenses = lopec_openpic_initsenses; > OpenPIC_NumInitSenses = sizeof(lopec_openpic_initsenses); > > - /* > - * We need to tell openpic_set_sources where things actually are. > - * mpc10x_common will setup OpenPIC_Addr at ioremap(EUMB phys base + > - * EPIC offset (0x4)); The EPIC IRQ Register Address Map - > - * Interrupt Source Configuration Registers gives these numbers > - * as offsets starting at 0x50200, we need to adjust occordinly. > - */ > - /* Map serial interrupts 0-15 */ > - openpic_set_sources(0, 16, OpenPIC_Addr + 0x10200); > - /* Skip reserved space and map i2c and DMA Ch[01] */ > - openpic_set_sources(16, 3, OpenPIC_Addr + 0x11020); > - /* Skip reserved space and map Message Unit Interrupt (I2O) */ > - openpic_set_sources(19, 1, OpenPIC_Addr + 0x110C0); > + mpc10x_set_openpic(); > > - openpic_init(NUM_8259_INTERRUPTS); > /* We have a cascade on OpenPIC IRQ 0, Linux IRQ 16 */ > openpic_hookup_cascade(NUM_8259_INTERRUPTS, "82c59 cascade", > &i8259_irq); > diff -Nru a/arch/ppc/platforms/powerpmc250.c > b/arch/ppc/platforms/powerpmc250.c > --- a/arch/ppc/platforms/powerpmc250.cSun Jun 20 16:40:17 2004 > +++ b/arch/ppc/platforms/powerpmc250.cSun Jun 20 16:40:17 2004 > @@ -197,7 +197,7 @@ > > OpenPIC_InitSenses = powerpmc250_openpic_initsenses; > OpenPIC_NumInitSenses = sizeof(powerpmc250_openpic_initsenses); > - openpic_init(1, 0, 0, -1); > + mpc10x_set_openpic(); > } > > /* > diff -Nru a/arch/ppc/platforms/sandpoint.c > b/arch/ppc/platforms/sandpoint.c > --- a/arch/ppc/platforms/sandpoint.c Sun Jun 20 16:40:17 2004 > +++ b/arch/ppc/platforms/sandpoint.c Sun Jun 20 16:40:17 2004 > @@ -433,17 +433,7 @@ > OpenPIC_InitSenses = sandpoint_openpic_initsenses; > OpenPIC_NumInitSenses = sizeof(sandpoint_openpic_initsenses); > > - /* > - * We need to tell openpic_set_sources where things actually are. > - * mpc10x_common will setup OpenPIC_Addr at ioremap(EUMB phys base + > - * EPIC offset (0x4)); The EPIC IRQ Register Address Map - > - * Interrupt Source Configuration Registers gives these numbers > - * as offsets starting at 0x50200, we need to adjust occordinly. > - */ > - /* Map serial interrupts 0-15 */ > - openpic_set_sources(0, 16, OpenPIC_Addr + 0x10200); > - > - openpic_init(NUM_8259_INTERRUPTS); > + mpc10x_set_openpic(); > openpic_hookup_cascade(NUM_8259_INTERRUPTS, "82c59 cascade", > i8259_irq
linux shell
hi,all I am wondering about the usage of ". ifcfg-eth0" since ifcfg-eth0 is not an execuatable. Can anyone tell me? Best regards Jack Liu ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
GT64260_eth (Ethernet) Driver
Dieu Morales wrote: >Greetings, I am working with the latest 2.6.7 kernel >source on a ppc radstone PPC7A board and was curious >if anyone was in the process or planned on porting the >gt64260_eth driver to support the 2.6.x kernel. > >Not being familiar with the gt64260 Ethernet device or >code, I plan to take it line by line. I have attempted >to use the driver from the ppc.bkbits.net 2.4 >development tree and currently have only changed the >dev = init_etherdev(dev, sizeof (gt_eth_priv)); >to >dev = alloc_etherdev(sizeof (gt_eth_priv_struct )); >Shortly after, when attempting to allocate the Tx and >Rx page buffers, I get an exception in the >uncachedPages function. I have traced the problem to >the pmd_present?(*pmd) function in va_to_pte(addr) >returning 0. I dumped the values of pmd, init_mm, and >pmd in the va_to_pte() and the values seemed O.K., so >I commented out the pmd_present?(*pmd) check but was >once again stopped by the pte_present(*pte) check. I >have seen the driver operate under 2.4.26 dev tree >from ppc.bkbits.net where this problem does not occur. >One difference I have noticed is that during >initialization of the 2.6.7 kernel, I do not get the >following output. >Buffer-cache hash table entries: >Page-cache hash table entries: >The filemap.c, where the "Page-cache " printk resides >in 2.4, looks heavily reworked, so I don't suspect >this is an issue? > > Dieu, You should sync up with Brian Waite (look at CC: list) who has been looking at writing a new enet driver for the 2.6 kernel using the latest bridge support code. You can get a look at the latest support code by cloning bk://source.mvista.com/linux-2.5-marvell. Note the the mpsc driver that's there still isn't working correctly. Mark ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
ELDK 3.0 download
I had the same problem, and the same error, too. But this is not a permission problem (i think explorer reports the wrong answer) It is down almost all the day. Yesterday, it was down all the day, but finally I arrived to enter and download de "iso" late in the afternoon. Wait. Alex Bastos > -Mensaje original- > De: Ing.Gianfranco Morandi [SMTP:gianfranco.morandi at euro-studio.it] > Enviado el: mi?rcoles, 23 de junio de 2004 13:33 > Para: LinuxPPC > Asunto: ELDK 3.0 download > > > I'm trying to down load the ISO image of ELDK 3.0 for ARM platform from > ftp://ftp.leo.org/pub/eldk/3.0/ppc-linux-x86/iso/ but it answers that I do > not have the required authorization. > > Anybody have seen that before? > > Thank You in advance > > Gianfranco > > ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
ELDK 3.0 download
In message <000601c45915$d4a70f40$0300a8c0 at pc005> you wrote: > > I'm trying to down load the ISO image of ELDK 3.0 for ARM platform from > ftp://ftp.leo.org/pub/eldk/3.0/ppc-linux-x86/iso/ but it answers that I do > not have the required authorization. LEO seems to have problems today with their FTP server. Sorry. [Anybody who wants to host a mirror?] Best regards, Wolfgang Denk -- Software Engineering: Embedded and Realtime Systems, Embedded Linux Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Email: wd at denx.de The amount of time between slipping on the peel and landing on the pavement is precisely 1 bananosecond. ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
ELDK 3.0 download
From: "Ing.Gianfranco Morandi" <[EMAIL PROTECTED]> Date sent: Wed, 23 Jun 2004 13:32:53 +0200 > > I'm trying to down load the ISO image of ELDK 3.0 for ARM platform from > ftp://ftp.leo.org/pub/eldk/3.0/ppc-linux-x86/iso/ but it answers that I do > not have the required authorization. > it seems to be down. I've got: awaiting response... 500 Internal Server Error 13:56:08 ERROR 500: Internal Server Error. Oliver ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
ELDK 3.0 download
I'm trying to down load the ISO image of ELDK 3.0 for ARM platform from ftp://ftp.leo.org/pub/eldk/3.0/ppc-linux-x86/iso/ but it answers that I do not have the required authorization. Anybody have seen that before? Thank You in advance Gianfranco ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
[PATCH][RFC] Second version of MPC10x OCP
Adrian Cox wrote: >Here's the second version of OCP-ifying the mpc10x. I've removed the >hardcoded positions in the core_ocp array, and I've added the DMA >devices in case anybody needs them. I haven't yet tested the I2C driver >from 2.4, but I've put in the flags field for it. > > Adrian, Sorry for the delay, I've been out the last few days. FWIW, your patch looks fine to me. Mark ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
2.6 networking support for Redwood[56]
On Wed, Jun 23, 2004 at 05:58:35AM -0700, Dale Farnsworth wrote: > > On Tue, Jun 22, 2004 at 12:41:11AM +, Dale Farnsworth wrote: > > On Mon, Jun 21, 2004 at 11:12:14PM +, Matt Porter wrote: > > > On Mon, Jun 21, 2004 at 02:39:48PM -0700, Dale Farnsworth wrote: > > > > > > > > I'm adding network support for the IBM Redwood5 and Redwood6 in 2.6. > > > > > > > > It looks like the best supported driver for the smc9 chip > > > > is used by the ARM folks and is found in drivers/net/arm/smc91x.[ch] > > > > This driver recently went into the linux-2.5 tree. > > > > > > > > I moved these two files into drivers/net so they are available for > > > > PPC as well as ARM and added some Redwood-specific support. That > > > > was straightforward. This driver calls a couple of ARM-specific > > > > functions platform_get_resource() and platform_get_irq(). ARM > > > > implements these functions in arch/arm/common/platform.c. I > > > > copied arch/arm/common/platform.c into arch/ppc/syslib/platform.c > > > > which works fine, but I don't care for duplicated code. Maybe a > > > > better approach would be to add these functions to > > > > drivers/base/platform.c > > > > > > How about wrapping each arch-specific call up in something more abstract > > > and then using OCP to get the PPC info? > > > > > > roughly... > > > > > > #ifdef CONFIG_PPC_OCP > > > TO_SMC_DEVto_ocp_device() > > > SMC_GET_BASE_ADDR dev->def->paddr > > > ... > > > #else /* ARM */ > > > TO_SMC_DEVto_platform_device() > > > SMC_GET_BASE_ADDR platform_get_resource(dev, IORESOURCE_MEM, 1) > > > ... > > > #endif > > > > > > There's only about 4 places in the probe/remove calls to do this. > > > Add an ocp_add_one_device in your redwood*.c to enable the smc9111 > > > device with the board-specific attributes. > > > > > > You may have to play a bit with the prove/remove calls since they > > > want to deal with a resource struct, but it might be worth looking > > > at. > > > > Sounds like a better approach. I'll modify the driver to present > > either the ARM interface or the PPC_OCP interface. Muddles the > > driver a bit, but should keep both archs happy. > > FYI, platform_get_resource() and platform_get_irq() just went into > linux-2.5/drivers/base/platform.c so this issue is now moot. Yep, I agree with that. -Matt ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
linux shell
. file is a built-in shell command. It executes the commands in file in the current shell, no sub-shell is spawned. Since no sub-shell is spawned, variable settings stay in effect. file is found along $PATH and does not have to be executable. Cheers, T.mike -Original Message- From: [EMAIL PROTECTED] [mailto:owner-linuxppc-embedded at lists.linuxppc.org]On Behalf Of Jack Liu Sent: Wednesday, June 23, 2004 2:35 AM To: linuxppc-embedded at lists.linuxppc.org Subject: linux shell hi,all I am wondering about the usage of ". ifcfg-eth0" since ifcfg-eth0 is not an execuatable. Can anyone tell me? Best regards Jack Liu ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Lite5200 USB with Vbus=1.7V
[ I?igo Lopez Barranco writes: ] > The only strange thing is that in Motorola's schematics says that > pins 3 and 5 of the Micrel 2025 are Not Connected and 4 is GND, and > Micrel's 2025 datasheet says that 3 is GND and 4 and 5 NC. Then, in > the Lite5200 GND pin 3 is connected to GND through an 1k resistor, > instead of directly as I suppose they pretended in the schematic, and That is correct and an error in our Lite5200 layout. Thanks for the feedback. We are replacing R164 with a 0 Ohm resistor. Our Total5200 platform does not share this problem. -- David Wolfe Digital Audio, Radio & Telematics Freescale Semiconductor ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
2.6 networking support for Redwood[56]
On Tue, Jun 22, 2004 at 12:41:11AM +, Dale Farnsworth wrote: > On Mon, Jun 21, 2004 at 11:12:14PM +, Matt Porter wrote: > > On Mon, Jun 21, 2004 at 02:39:48PM -0700, Dale Farnsworth wrote: > > > > > > I'm adding network support for the IBM Redwood5 and Redwood6 in 2.6. > > > > > > It looks like the best supported driver for the smc9 chip > > > is used by the ARM folks and is found in drivers/net/arm/smc91x.[ch] > > > This driver recently went into the linux-2.5 tree. > > > > > > I moved these two files into drivers/net so they are available for > > > PPC as well as ARM and added some Redwood-specific support. That > > > was straightforward. This driver calls a couple of ARM-specific > > > functions platform_get_resource() and platform_get_irq(). ARM > > > implements these functions in arch/arm/common/platform.c. I > > > copied arch/arm/common/platform.c into arch/ppc/syslib/platform.c > > > which works fine, but I don't care for duplicated code. Maybe a > > > better approach would be to add these functions to drivers/base/platform.c > > > > How about wrapping each arch-specific call up in something more abstract > > and then using OCP to get the PPC info? > > > > roughly... > > > > #ifdef CONFIG_PPC_OCP > > TO_SMC_DEV to_ocp_device() > > SMC_GET_BASE_ADDR dev->def->paddr > > ... > > #else /* ARM */ > > TO_SMC_DEV to_platform_device() > > SMC_GET_BASE_ADDR platform_get_resource(dev, IORESOURCE_MEM, 1) > > ... > > #endif > > > > There's only about 4 places in the probe/remove calls to do this. > > Add an ocp_add_one_device in your redwood*.c to enable the smc9111 > > device with the board-specific attributes. > > > > You may have to play a bit with the prove/remove calls since they > > want to deal with a resource struct, but it might be worth looking > > at. > > Sounds like a better approach. I'll modify the driver to present > either the ARM interface or the PPC_OCP interface. Muddles the > driver a bit, but should keep both archs happy. FYI, platform_get_resource() and platform_get_irq() just went into linux-2.5/drivers/base/platform.c so this issue is now moot. -Dale Farnsworth ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
