serial console: platform_device

serial console: platform_device

[Ashlesha Shintre]

Hi,

I m working on porting the 2.6.14.6 kernel to the Encore M3 (AU1500)
board --

The kernel mounts the NFS root and executes the init=/bin/sh program --
however I dont see it on the console (standard 8250 UART)

The reason is that there was no platform_device structure defined for
the serial console in the platform.c file.

I therefore added the following to the
arch/mips/au1000/common/platform.c file,


> 
> #ifdef CONFIG_MIPS_AMPRO_M3
> static struct plat_serial8250_port encm3_via_uart_data[] = {
>           {
>              .mapbase        = 0x50000000 + 0x3f8, 
>              .membase        = (char *)(0x50000000 +0x3f8),         
>              .irq            = AU1000_GPIO_0,
>              .flags          = UPF_SHARE_IRQ, 
>              .iotype         = UPIO_PORT,
>              .regshift       = 1,
>              .uartclk        = 1843200,
> 
>              },
>                         { },
> };
> 
> static struct resource encm3_via_uart_resource = {
>                 .start  = VIA_COM1_ADDR, // this is 0x3f8
>                 .end    = VIA_COM1_ADDR + 0x7,
>                 .flags  = IORESOURCE_IO,
> };
> 
> 
> static struct platform_device encm3_via_uart = {        
>                 .name           = "serial8250",
>                 .id             = 1,
>                 .dev                    = {
>                                 .platform_data  = encm3_via_uart_data,
>                  },
>                 .num_resources  = 1,
>                 .resource       = &encm3_via_uart_resource,
> };
> #endif
> 

I have a these queries about the above entries:

1) The serial console is on a VIA 686B southbridge which is on the PCI
bus -- however, because of the way the VIA is designed, any references
from the processor to port 0x3f8 are routed to the console -- 
- the  0x50000000 is the mips_io_port_base address for the Southbridge
so should the resource.flags be IORESOURCE_IO or IORESOURCE_MEM -- what
does this signify exactly? I tried both and neither makes a difference
to the output from the log buffer which I have pasted below.  Does this
have to do with whether the ports are i/o or memory mapped -- cus in
that case it should be IORESOURCE_MEM as all io ports on MIPS processors
are memory mapped -- right?

2) in the platform_device structure, does the name of the device have to
be coherent with a name given to it elsewhere, if yes, where? 

3) control goes into the serial8250_probe function and assigns values
from the plat_serial8250_port encm3_via_uart_data to the port..so what
is the basic difference between registration of "probe device" versus
"platform bus" devices in the 2.6 kernel?

When I build the kernel with this platform.c file and run it, I see an
error in the pci_register_driver function executed to register the usb
port which is on the AU1500 chip, which is the other platform device -- 
I did not get such an error before the above entries were added to the
file!  I have pasted the contents of the entire file below.

Sorry about the length of this email and Thank you,
Ashlesha.


> /*
>  * Platform device support for Au1x00 SoCs.
>  *
>  * Copyright 2004, Matt Porter <mporter@kernel.crashing.org>
>  *
>  * This file is licensed under the terms of the GNU General Public
>  * License version 2.  This program is licensed "as is" without any
>  * warranty of any kind, whether express or implied.
>  */
> #include <linux/device.h>
> #include <linux/kernel.h>
> #include <linux/init.h>
> #include <linux/resource.h>
> #include <linux/serial_8250.h>
> #include <linux/tty.h>
> 
> #include <asm/mach-au1x00/au1000.h>
> #include <asm/mach-encm3/encm3.h>
> 
> static struct resource au1xxx_usb_ohci_resources[] = {
>         [0] = {
>                 .start          = USB_OHCI_BASE,
>                 .end            = USB_OHCI_BASE + USB_OHCI_LEN,
>                 .flags          = IORESOURCE_MEM,
>         },
>         [1] = {
>                 .start          = AU1000_USB_HOST_INT,
>                 .end            = AU1000_USB_HOST_INT,
>                 .flags          = IORESOURCE_IRQ,
>         },
> };
> 
> /* The dmamask must be set for OHCI to work */
> static u64 ohci_dmamask = ~(u32)0;
> 
> static struct platform_device au1xxx_usb_ohci_device = {
>         .name           = "au1xxx-ohci",
>         .id             = 0,
>         .dev = {
>                 .dma_mask               = &ohci_dmamask,
>                 .coherent_dma_mask      = 0xffffffff,
>         },
>         .num_resources  = ARRAY_SIZE(au1xxx_usb_ohci_resources),
>         .resource       = au1xxx_usb_ohci_resources,
>                                                                                                             44,2-9        Top
> 
> };
> 
> 
> 
> #ifdef CONFIG_MIPS_AMPRO_M3
> static struct plat_serial8250_port encm3_via_uart_data[] = {
>                 {
> //                      .mapbase        = 0x50000000 + 0x3f8,                   //resource base
>                         .membase        = (char *)(0x50000000 + 0x3f8),         // is a pointer - ioremap cookie or NULL
>                         .irq            = AU1000_GPIO_0,
>                         .flags          = UPF_SHARE_IRQ, //| UPF_IOREMAP, //UPF_BOOT_AUTOCONF | UPF_SKIP_TEST |
>                         .iotype         = UPIO_PORT,
>                         .regshift       = 1,
>                         .uartclk        = 1843200,
> 
>                   },
>                         { },
> };
> 
> static struct resource encm3_via_uart_resource = {
>                 .start  = VIA_COM1_ADDR,
>                 .end    = VIA_COM1_ADDR + 0x7,
>                 .flags  = IORESOURCE_IO,
> };
> 
> 
> static struct platform_device encm3_via_uart = {        // coyote_uart arm/mach-ixp4xx/coyote-setup.c
>                 .name           = "serial8250",
>                 .id             = 1,
>                 .dev                    = {
>                                 .platform_data  = encm3_via_uart_data,
>                  },
>                 .num_resources  = 1,
>                 .resource       = &encm3_via_uart_resource,
> };
> #endif
> 
> static struct platform_device *au1xxx_platform_devices[] __initdata = {
>         &au1xxx_usb_ohci_device,
>         &encm3_via_uart,
> };
> int au1xxx_platform_init(void)
> {
>         printk("size of au1xxx platform devices is %d\n",ARRAY_SIZE(au1xxx_platform_devices));
>         return platform_add_devices(au1xxx_platform_devices, ARRAY_SIZE(au1xxx_platform_devices));
> }
> 
> arch_initcall(au1xxx_platform_init);
> 

Re: serial console: platform_device

[Sergei Shtylyov]

Hello.

Ashlesha Shintre wrote:

> I m working on porting the 2.6.14.6 kernel to the Encore M3 (AU1500)
> board --

> The kernel mounts the NFS root and executes the init=/bin/sh program --
> however I dont see it on the console (standard 8250 UART)

> The reason is that there was no platform_device structure defined for
> the serial console in the platform.c file.

> I therefore added the following to the
> arch/mips/au1000/common/platform.c file,

    I doubt this is fitting place, since it only registers SoC devices. Move 
this to the *board* specific code instead.

>>#ifdef CONFIG_MIPS_AMPRO_M3
>>static struct plat_serial8250_port encm3_via_uart_data[] = {
>>          {
>>             .mapbase        = 0x50000000 + 0x3f8, 

    I highly doubt this is correct -- the address 0x3f8 is in I/O space. And 
since 0x50000000 is mips_io_port_base, you do *not* need to add it here.

>>             .membase        = (char *)(0x50000000 +0x3f8),

    This needs a kernel address, i.e. in KSEG1. As the UARTs are in the I/O 
space, you just don't need to set this.

>>static struct resource encm3_via_uart_resource = {
>>                .start  = VIA_COM1_ADDR, // this is 0x3f8
>>                .end    = VIA_COM1_ADDR + 0x7,
>>                .flags  = IORESOURCE_IO,
>>};
>>
>>
>>static struct platform_device encm3_via_uart = {        
>>                .name           = "serial8250",
>>                .id             = 1,
>>                .dev                    = {
>>                                .platform_data  = encm3_via_uart_data,
>>                 },
>>                .num_resources  = 1,

    Where the IRQ is declared?

>>                .resource       = &encm3_via_uart_resource,
>>};
>>#endif

    Well, I doubt that you need to also decalre the UART as platform_device in 
addition to registering it with 8250.x -- it'll do everything for you.

> I have a these queries about the above entries:

> 1) The serial console is on a VIA 686B southbridge which is on the PCI
> bus -- however, because of the way the VIA is designed, any references
> from the processor to port 0x3f8 are routed to the console -- 
> - the  0x50000000 is the mips_io_port_base address for the Southbridge
> so should the resource.flags be IORESOURCE_IO or IORESOURCE_MEM -- what
> does this signify exactly?

    On x86 the hardware on the busses is accessible via both memory and I/O 
address space (the 2nd method was historically preferred) -- so, all archs 
that want to reuse the standard x86 h/w have to adapt to its ways, 
implementing I/O address space accesses by some means, usually by dedicating 
the certain range of the physical addresses to it....

> I tried both and neither makes a difference
> to the output from the log buffer which I have pasted below.  Does this
> have to do with whether the ports are i/o or memory mapped -- cus in

    This has to do with improper UART addresses you were passing.

> that case it should be IORESOURCE_MEM as all io ports on MIPS processors
> are memory mapped -- right?

    No, it should be IORESOURCE_IO.

> 2) in the platform_device structure, does the name of the device have to
> be coherent with a name given to it elsewhere, if yes, where? 

    You just don't need it in this case.

> 3) control goes into the serial8250_probe function and assigns values
> from the plat_serial8250_port encm3_via_uart_data to the port..so what
> is the basic difference between registration of "probe device" versus
> "platform bus" devices in the 2.6 kernel?

    I'm not sure I follow you here.

WBR, Sergei

Re: serial console: platform_device

[Sergei Shtylyov]

Hello.

Ashlesha Shintre wrote:

>>>3) control goes into the serial8250_probe function and assigns values
>>>from the plat_serial8250_port encm3_via_uart_data to the port..so what
>>>is the basic difference between registration of "probe device" versus

>>>"platform bus" devices in the 2.6 kernel?

>>    I'm not sure I follow you here.

> What I meant was, what was the basis for the implementation of
> platform_device and platform_init functions in 2.6?

    This is a convenient way to registers the various SoC and on-board devices 
residing on the busses that can't be scanned like ISA/LPC/whatever (and unlike 
PCI, for example).

> By my understanding the way it worked in 2.4 was by the device probing
> functions that would allocate memory, io ports etc..

    Basically, you don't need to probe for device which you *know* is there, 
you just need to tell the driver where it is.

> m working on making the changes you suggested --

> without the addition of the platform_device and other structures, the

    I meant that you *only* need struct plat_serial8250_port, and not 
platform_device.

> serial console is never detected -- I never get a msg at boot time that
> reads 

> serial8250: ttyS0 at I/O 0x3f8 (irq = whatever) is a 16550A

> so I think i might need these routines

> Also, the Southbridge interrupts are assigned interrupt number:
> AU1000_GPIO_0..and I have included this as below:

    Ah, I forgot to mention that if your UART is a part of the south bridge, 
its IRQ number is _4_ on the integrated 8259 interrupt controller. I'm sure 
that AU1000_GPIO_0 is the cascaded interrupt request from 8259, not the UART's 
own IRQ...

>>static struct plat_serial8250_port encm3_via_uart_data[] = {
>>                {
>>                        .mapbase        = 0x3f8,
>>                        .irq            = AU1000_GPIO_0,

    So, this is wrong. You need to specify to what platform IRQ 8259's IRQ4 
gets routed here.

> Thanks again!
> Ashlesha.

WBR, Sergei

Re: serial console: platform_device

[Ashlesha Shintre]

Hi,

Thank you for your prompt response -- I really appreciate it.


On Tue, 2006-12-05 at 22:42 +0300, Sergei Shtylyov wrote:
> > 3) control goes into the serial8250_probe function and assigns
> values
> > from the plat_serial8250_port encm3_via_uart_data to the port..so
> what
> > is the basic difference between registration of "probe device"
> versus
> > "platform bus" devices in the 2.6 kernel?
> 

>     I'm not sure I follow you here.
What I meant was, what was the basis for the implementation of
platform_device and platform_init functions in 2.6?

By my understanding the way it worked in 2.4 was by the device probing
functions that would allocate memory, io ports etc..

m working on making the changes you suggested --

without the addition of the platform_device and other structures, the
serial console is never detected -- I never get a msg at boot time that
reads 

serial8250: ttyS0 at I/O 0x3f8 (irq = whatever) is a 16550A

so I think i might need these routines

Also, the Southbridge interrupts are assigned interrupt number:
AU1000_GPIO_0..and I have included this as below:


> static struct plat_serial8250_port encm3_via_uart_data[] = {
>                 {
>                         .mapbase        = 0x3f8,
>                         .irq            = AU1000_GPIO_0,
>                         .flags          = UPF_SHARE_IRQ, 
>                         .iotype         = UPIO_PORT,
>                         .regshift       = 1,
>                         .uartclk        = 1843200,
> 
>                   },
>                         { },
> };

Thanks again!
Ashlesha.

Re: serial console: platform_device

[Ashlesha Shintre]

Hi Sergei,

Another query:

>     Ah, I forgot to mention that if your UART is a part of the south bridge, 
> its IRQ number is _4_ on the integrated 8259 interrupt controller. I'm sure 
> that AU1000_GPIO_0 is the cascaded interrupt request from 8259, not the UART's 
> own IRQ...
> 
> >>static struct plat_serial8250_port encm3_via_uart_data[] = {
> >>                {
> >>                        .mapbase        = 0x3f8,
> >>                        .irq            = AU1000_GPIO_0,
> 
>     So, this is wrong. You need to specify to what platform IRQ 8259's IRQ4 
> gets routed here.
I m not sure what you mean here -- the AU1000_GPIO_0 is the cascaded
interrupt request from the 8259 on the VIA Southbridge -- 

Best Regards,
Ashlesha.

Re: serial console: platform_device

[Sergei Shtylyov]

Hello.

Ashlesha Shintre wrote:

>>    Ah, I forgot to mention that if your UART is a part of the south bridge, 
>>its IRQ number is _4_ on the integrated 8259 interrupt controller. I'm sure 
>>that AU1000_GPIO_0 is the cascaded interrupt request from 8259, not the UART's 
>>own IRQ...

>>>>static struct plat_serial8250_port encm3_via_uart_data[] = {
>>>>               {
>>>>                       .mapbase        = 0x3f8,
>>>>                       .irq            = AU1000_GPIO_0,

>>    So, this is wrong. You need to specify to what platform IRQ 8259's IRQ4 
>>gets routed here.

> I m not sure what you mean here -- the AU1000_GPIO_0 is the cascaded
> interrupt request from the 8259 on the VIA Southbridge -- 

    I meant that the UART interrupts from the south bridge *cannot* be 
delivered *directly* to the Alchemy's embedded interrupt controller), so 
AU1000_GPIO_0 must be used to deliver all the interrupts from 8259 (the 
interrupt controller integrated into the south bridge) to the embedded 
interrupt controller. So, you need to setup some kind of the cascading 
interrupt handler for AU1000_GPIO_0 to read the vector from 8259 I think...

> Best Regards,
> Ashlesha.

WBR, Sergei

Re: serial console: platform_device

[Ashlesha Shintre]

hi,

There is already an interrupt handler in place for the AU1000_GPIO_0
that takes care of the cascaded interrupts -- so I *can* say 
 .irq= AU1000_GPIO_0 ----right?

Also, how will I make sure my board specific encm3_platform_init is
called during the arch init calls?

I have put in an entry in the Makefile for the board specific
encm3_platform.c file -- so it is built - but when control goes to the 
static int __devinit serial8250_probe(struct device *dev) function in
the 8250.c it never executes the serial8250_register_port function.
I know this cus I m using the JTAG port on the board to look inside and
step through the code..

Here is my /arch/mips/au1000/encm3/encm3_platform.c file:

Thanks and Regards,
Ashlesha.

> /*
>  * Platform device support for Au1x00 SoCs.
>  *
>  * Copyright 2004, Matt Porter <mporter@kernel.crashing.org>
>  *
>  * This file is licensed under the terms of the GNU General Public
>  * License version 2.  This program is licensed "as is" without any
>  * warranty of any kind, whether express or implied.
>  */
> #include <linux/device.h>
> #include <linux/kernel.h>
> #include <linux/init.h>
> #include <linux/resource.h>
> #include <linux/serial_8250.h>
> #include <linux/tty.h>
> 
> #include <asm/mach-au1x00/au1000.h>
> #include <asm/mach-encm3/encm3.h>
> static struct plat_serial8250_port encm3_via_uart_data[] = {
>                 {
>                         .mapbase        =
> 0x3f8,                        //resource base
> //                      .membase        = (char *)(0x50000000 +
> 0x3f8),         // is a pointer - ioremap cookie or NULL
>                         .irq            = AU1000_GPIO_0,
>                         .flags          = UPF_SHARE_IRQ, //|
> UPF_IOREMAP, //UPF_BOOT_AUTOCONF | UPF_SKIP_TEST |
>                         .iotype         = UPIO_PORT,
>                         .regshift       = 1,
>                         .uartclk        = 1843200,
> 
>                   },
>                         { },
> };
> 
> static struct resource encm3_via_uart_resource = {
>                 .start  = VIA_COM1_ADDR,
>                 .end    = VIA_COM1_ADDR + 0x7,
>                 .flags  = IORESOURCE_IO,
> };
> 
> 
> static struct platform_device encm3_via_uart = {
>                 .name           = "serial8250",
>                 .id             = 1,
>                 .dev                    = {
>                                 .platform_data  = encm3_via_uart_data,
>                  },
>                 .num_resources  = 1,
>                 .resource       = &encm3_via_uart_resource,
> };
> 
> static struct platform_device *encm3_platform_devices[] __initdata = {
>         &encm3_via_uart,
> };
> 
> int encm3_platform_init(void)
> {
>         printk("size of encm3 platform devices is %d
> \n",ARRAY_SIZE(encm3_platform_devices));
>         return platform_add_devices(encm3_platform_devices,
> ARRAY_SIZE(encm3_platform_devices));
> }
> 
> arch_initcall(encm3_platform_init);


On Wed, 2006-12-06 at 15:59 +0300, Sergei Shtylyov wrote:
> Hello.
> 
> Ashlesha Shintre wrote:
> 
> >>    Ah, I forgot to mention that if your UART is a part of the south bridge, 
> >>its IRQ number is _4_ on the integrated 8259 interrupt controller. I'm sure 
> >>that AU1000_GPIO_0 is the cascaded interrupt request from 8259, not the UART's 
> >>own IRQ...
> 
> >>>>static struct plat_serial8250_port encm3_via_uart_data[] = {
> >>>>               {
> >>>>                       .mapbase        = 0x3f8,
> >>>>                       .irq            = AU1000_GPIO_0,
> 
> >>    So, this is wrong. You need to specify to what platform IRQ 8259's IRQ4 
> >>gets routed here.
> 
> > I m not sure what you mean here -- the AU1000_GPIO_0 is the cascaded
> > interrupt request from the 8259 on the VIA Southbridge -- 
> 
>     I meant that the UART interrupts from the south bridge *cannot* be 
> delivered *directly* to the Alchemy's embedded interrupt controller), so 
> AU1000_GPIO_0 must be used to deliver all the interrupts from 8259 (the 
> interrupt controller integrated into the south bridge) to the embedded 
> interrupt controller. So, you need to setup some kind of the cascading 
> interrupt handler for AU1000_GPIO_0 to read the vector from 8259 I think...
> 
> > Best Regards,
> > Ashlesha.
> 
> WBR, Sergei

Re: serial console: platform_device

[Sergei Shtylyov]

Hello.

Ashlesha Shintre wrote:

> There is already an interrupt handler in place for the AU1000_GPIO_0
> that takes care of the cascaded interrupts -- so I *can* say 
>  .irq= AU1000_GPIO_0 ----right?

    No, you can't. You'll have to specify to what 8259's IRQ4 maps to on your 
platform.

> Also, how will I make sure my board specific encm3_platform_init is
> called during the arch init calls?

    Mentioning it in arch_initcall() arranges for that. :-/

> I have put in an entry in the Makefile for the board specific
> encm3_platform.c file -- so it is built - but when control goes to the 
> static int __devinit serial8250_probe(struct device *dev) function in
> the 8250.c it never executes the serial8250_register_port function.
> I know this cus I m using the JTAG port on the board to look inside and
> step through the code..

    That's strange. Although the UART declaration has a grave defect....

> Here is my /arch/mips/au1000/encm3/encm3_platform.c file:

>>/*
>> * Platform device support for Au1x00 SoCs.
>> *
>> * Copyright 2004, Matt Porter <mporter@kernel.crashing.org>
>> *
>> * This file is licensed under the terms of the GNU General Public
>> * License version 2.  This program is licensed "as is" without any
>> * warranty of any kind, whether express or implied.
>> */

    That boilerplate is no longer applicable. :-)

>>#include <linux/device.h>
>>#include <linux/kernel.h>
>>#include <linux/init.h>
>>#include <linux/resource.h>
>>#include <linux/serial_8250.h>
>>#include <linux/tty.h>
>>
>>#include <asm/mach-au1x00/au1000.h>
>>#include <asm/mach-encm3/encm3.h>
>>static struct plat_serial8250_port encm3_via_uart_data[] = {
>>                {
>>                        .mapbase        =
>>0x3f8,                        //resource base

    Damn, I didn't notice: .mapbase should be changed to .iobase!

>>//                      .membase        = (char *)(0x50000000 +
>>0x3f8),         // is a pointer - ioremap cookie or NULL
>>                        .irq            = AU1000_GPIO_0,
>>                        .flags          = UPF_SHARE_IRQ, //|
>>UPF_IOREMAP, //UPF_BOOT_AUTOCONF | UPF_SKIP_TEST |
>>                        .iotype         = UPIO_PORT,
>>                        .regshift       = 1,
>>                        .uartclk        = 1843200,
>>
>>                  },
>>                        { },
>>};

>>static struct resource encm3_via_uart_resource = {
>>                .start  = VIA_COM1_ADDR,
>>                .end    = VIA_COM1_ADDR + 0x7,
>>                .flags  = IORESOURCE_IO,
>>};

    Still, you don't need to declare the resources for the 8250 devices -- the 
driver should handle requesting them for you -- as they're alredy specified by 
struct plat_serial8250_port.

>>static struct platform_device encm3_via_uart = {
>>                .name           = "serial8250",
>>                .id             = 1,

    I guess it should be PLAT8250_DEV_LEGACY...

>>                .dev                    = {
>>                                .platform_data  = encm3_via_uart_data,
>>                 },

    So, you also don't need the following 2 lines:

>>                .num_resources  = 1,
>>                .resource       = &encm3_via_uart_resource,
>>};

>>static struct platform_device *encm3_platform_devices[] __initdata = {
>>        &encm3_via_uart,
>>};

>>int encm3_platform_init(void)
>>{
>>        printk("size of encm3 platform devices is %d
>>\n",ARRAY_SIZE(encm3_platform_devices));
>>        return platform_add_devices(encm3_platform_devices,
>>ARRAY_SIZE(encm3_platform_devices));

    I think it's better to call platform_device_register() for a single device...

WBR, Sergei

Cant analyze prologue code

[Ashlesha Shintre]

Hi Sergei!

So now encm3_platform_init function is linked to the kernel image -- and
is part of the executable -- i added this line to the
arch/mips/au1000/encm3/Makefile:

obj-y +=encm3_platform.o

However, I now get a "Cant analyze prologue code at 80294aec." error!

Any remedies/suggestions for the same?

Thank you!
Best Regards,
Ashlesha.

On Wed, 2006-12-06 at 22:54 +0300, Sergei Shtylyov wrote:
> Hello.
> 
> Ashlesha Shintre wrote:
> 
> > There is already an interrupt handler in place for the AU1000_GPIO_0
> > that takes care of the cascaded interrupts -- so I *can* say 
> >  .irq= AU1000_GPIO_0 ----right?
> 
>     No, you can't. You'll have to specify to what 8259's IRQ4 maps to on your 
> platform.
> 
> > Also, how will I make sure my board specific encm3_platform_init is
> > called during the arch init calls?
> 
>     Mentioning it in arch_initcall() arranges for that. :-/
> 
> > I have put in an entry in the Makefile for the board specific
> > encm3_platform.c file -- so it is built - but when control goes to the 
> > static int __devinit serial8250_probe(struct device *dev) function in
> > the 8250.c it never executes the serial8250_register_port function.
> > I know this cus I m using the JTAG port on the board to look inside and
> > step through the code..
> 
>     That's strange. Although the UART declaration has a grave defect....
> 
> > Here is my /arch/mips/au1000/encm3/encm3_platform.c file:
> 
> >>/*
> >> * Platform device support for Au1x00 SoCs.
> >> *
> >> * Copyright 2004, Matt Porter <mporter@kernel.crashing.org>
> >> *
> >> * This file is licensed under the terms of the GNU General Public
> >> * License version 2.  This program is licensed "as is" without any
> >> * warranty of any kind, whether express or implied.
> >> */
> 
>     That boilerplate is no longer applicable. :-)
> 
> >>#include <linux/device.h>
> >>#include <linux/kernel.h>
> >>#include <linux/init.h>
> >>#include <linux/resource.h>
> >>#include <linux/serial_8250.h>
> >>#include <linux/tty.h>
> >>
> >>#include <asm/mach-au1x00/au1000.h>
> >>#include <asm/mach-encm3/encm3.h>
> >>static struct plat_serial8250_port encm3_via_uart_data[] = {
> >>                {
> >>                        .mapbase        =
> >>0x3f8,                        //resource base
> 
>     Damn, I didn't notice: .mapbase should be changed to .iobase!
> 
> >>//                      .membase        = (char *)(0x50000000 +
> >>0x3f8),         // is a pointer - ioremap cookie or NULL
> >>                        .irq            = AU1000_GPIO_0,
> >>                        .flags          = UPF_SHARE_IRQ, //|
> >>UPF_IOREMAP, //UPF_BOOT_AUTOCONF | UPF_SKIP_TEST |
> >>                        .iotype         = UPIO_PORT,
> >>                        .regshift       = 1,
> >>                        .uartclk        = 1843200,
> >>
> >>                  },
> >>                        { },
> >>};
> 
> >>static struct resource encm3_via_uart_resource = {
> >>                .start  = VIA_COM1_ADDR,
> >>                .end    = VIA_COM1_ADDR + 0x7,
> >>                .flags  = IORESOURCE_IO,
> >>};
> 
>     Still, you don't need to declare the resources for the 8250 devices -- the 
> driver should handle requesting them for you -- as they're alredy specified by 
> struct plat_serial8250_port.
> 
> >>static struct platform_device encm3_via_uart = {
> >>                .name           = "serial8250",
> >>                .id             = 1,
> 
>     I guess it should be PLAT8250_DEV_LEGACY...
> 
> >>                .dev                    = {
> >>                                .platform_data  = encm3_via_uart_data,
> >>                 },
> 
>     So, you also don't need the following 2 lines:
> 
> >>                .num_resources  = 1,
> >>                .resource       = &encm3_via_uart_resource,
> >>};
> 
> >>static struct platform_device *encm3_platform_devices[] __initdata = {
> >>        &encm3_via_uart,
> >>};
> 
> >>int encm3_platform_init(void)
> >>{
> >>        printk("size of encm3 platform devices is %d
> >>\n",ARRAY_SIZE(encm3_platform_devices));
> >>        return platform_add_devices(encm3_platform_devices,
> >>ARRAY_SIZE(encm3_platform_devices));
> 
>     I think it's better to call platform_device_register() for a single device...
> 
> WBR, Sergei
> 

Re: Cant analyze prologue code

[Atsushi Nemoto]

On Wed, 06 Dec 2006 16:13:23 -0800, Ashlesha Shintre <ashlesha@kenati.com> wrote:
> However, I now get a "Cant analyze prologue code at 80294aec." error!
> 
> Any remedies/suggestions for the same?

Please look at this thread:

http://www.linux-mips.org/archives/linux-mips/2004-09/msg00123.html

Final patch is:

http://www.linux-mips.org/archives/linux-mips/2004-10/msg00312.html

And actual commit is:

http://www.linux-mips.org/git?p=linux.git;a=commitdiff;h=dc953df1ba5526814982676f47580c8e1bcdbfeb

---
Atsushi Nemoto

Re: Cant analyze prologue code

[Ashlesha Shintre]

Hi,

I cant build the kernel with this patch -- i m using the 2.6.14.6
kernel..

also, the kernel does not hang, but the output produced on the console 
is not complete: eg
i.e. I get this:


> 1000 i 1.5 P P <v@e.>
> 0: A1 Er n  01500000,  28
> 0: Bd BCM5221 10/100 BT PHY   e 0
> 0: U Bo BCM5221 10/100 BT PHY  a
> 1: A1 Ee    01510000,  29
> 1: Bm BCM5221 10/100 BT PHY   e 0
> 1: U Bc BCM5221 10/100 BT PHY  l
> NET: Re c l 2
> IP t   h l i: 1024 (: 0, 4096 s)
> TCP l h  i: 4096 (: 2, 16384 s)
> TCP d h  i: 4096 (: 2, 16384 s)
> TCP: H s u (a 4096  4096)
> TCP  s
> TCP  s
> NET: Rs o y 1
> NET: Rt o i 17
> IP-C: Gn s 255.255.255.0

instead of :


> au1000eth version 1.5 Pete Popov <ppopov@embeddedalley.com>
> eth0: Au1x Ethernet found at 0xb1500000, irq 28
> eth0: Broadcom BCM5221 10/100 BaseT PHY at phy address 0
> eth0: Using Broadcom BCM5221 10/100 BaseT PHY as default
> eth1: Au1x Ethernet found at 0xb1510000, irq 29
> eth1: Broadcom BCM5221 10/100 BaseT PHY at phy address 0
> eth1: Using Broadcom BCM5221 10/100 BaseT PHY as default
> NET: Registered protocol family 2
> IP route cache hash table entries: 1024 (order: 0, 4096 bytes)
> TCP established hash table entries: 4096 (order: 2, 16384 bytes)
> TCP bind hash table entries: 4096 (order: 2, 16384 bytes)
> TCP: Hash tables configured (established 4096 bind 4096)
> TCP reno registered
> TCP bic registered
> NET: Registered protocol family 1
> NET: Registered protocol family 17
> IP-Config: Guessing netmask 255.255.255.0
> IP-Config: Complete:


which makes me think there is some kind of a wrong initialisation of the UART -- but i ve checked all the parameters:
iobase, IRQ, etc and nothing is obviously wrong --

I was wondering what the significance of the flags in the plat_serial8250_port is?


> static struct plat_serial8250_port encm3_via_uart_data[] = {
>                 {
> 
>                    .flags          = UPF_SHARE_IRQ, 
>                        
Thanks and Regards,
Ashlesha.


On Thu, 2006-12-07 at 10:37 +0900, Atsushi Nemoto wrote:
> On Wed, 06 Dec 2006 16:13:23 -0800, Ashlesha Shintre <ashlesha@kenati.com> wrote:
> > However, I now get a "Cant analyze prologue code at 80294aec." error!
> > 
> > Any remedies/suggestions for the same?
> 
> Please look at this thread:
> 
> http://www.linux-mips.org/archives/linux-mips/2004-09/msg00123.html
> 
> Final patch is:
> 
> http://www.linux-mips.org/archives/linux-mips/2004-10/msg00312.html
> 
> And actual commit is:
> 
> http://www.linux-mips.org/git?p=linux.git;a=commitdiff;h=dc953df1ba5526814982676f47580c8e1bcdbfeb
> 
> ---
> Atsushi Nemoto

Re: Cant analyze prologue code

[Atsushi Nemoto]

On Wed, 06 Dec 2006 19:39:14 -0800, Ashlesha Shintre <ashlesha@kenati.com> wrote:
> I cant build the kernel with this patch -- i m using the 2.6.14.6
> kernel..

Then these patch might fit your needs:

http://www.linux-mips.org/archives/linux-mips/2005-11/msg00088.html
or
http://www.linux-mips.org/archives/linux-mips/2006-02/msg00097.html
(http://www.linux-mips.org/git?p=linux.git;a=commitdiff;h=63077519899721120b61d663a68adced068a459d)

> also, the kernel does not hang, but the output produced on the console 
> is not complete: eg
> i.e. I get this:

Anyway, "Cant analyze prologue code" message should not irrelevant to
your serial console problem.

---
Atsushi Nemoto

Serial 8250 driver registration:

[Ashlesha Shintre]

Hi,

Yeah, i thought you might have meant that :-)

i m starting to think that the uartclk parameter that i pass to the
platform_add_devices function might be wrong --

i m passing the standard value of 1843200 for a baudrate of 115200...

now the output after the board specific encm3_platform_init function is
called, is the kernel messages with mostly alternate characters missing,
like so:


> 1000 s 1.5 P P <o@d.>
> 0: A1 Ee d  01500000,  28
> 0: Bd BCM5221 10/100 BT PHY   e 0
> 0: U Bd BCM5221 10/100 BT PHY  a
> 1: A1 Er   01510000,  29
> 1: Bo BCM5221 10/100 BT PHY   r 0
> 1: U Bo BCM5221 10/100 BT PHY  a
> NET: Rt c l 2
> IP   h  e r: 1024 (r: 0, 4096 )
> TCP a  e r: 4096 (r: 2, 16384 e)
> TCP   e r: 4096 (r: 2, 16384 e)
> TCP: H e i (b 4096 d 4096)
> TCP o i
> TCP  t
> NET: Re c l 1
> NET: Rs t y 17
> IP-Ci: Gs m 255.255.255.0
> IP-C:: Ce:
>       c=0, =192.168.1.147, =255.255.255.0, =255.255.255.255,
>      =192.168.1.147, ==, -n=(e)<6>0: n  l x
> ,
>      s=255.255.255.255, s=192.168.1.8, p=
>  d c n
>  i  n
> Ln  t  RPC 100003/2  192.168.1.8
> Li    RPC 100005/1  192.168.1.8
> VFS: Me  ( y).
> Fi e e y: 128

Could there be another cause for this?
This is my platform_device structure:


> static struct plat_serial8250_port encm3_via_uart_data[] = {
>                 {
>                         .iobase         = 0x3f8,                        //iobase address
> //                      .membase        = (char *)(0x50000000 + 0x3f8),         // is a pointer - ioremap cookie or NULL
>                         .irq            = INT_PIC_4,    // interrupt 4 from the 8259 on the southbridge
> //                      .flags          = UPF_SHARE_IRQ, //| UPF_SKIP_TEST |
>                         .flags          = UPF_BOOT_AUTOCONF | UPF_SKIP_TEST | UPF_AUTO_IRQ,
>                         .iotype         = UPIO_PORT,
>                         .regshift       = 1,
>                         .uartclk        = 1843200,
> 
>                                             },
>                         { },
> };


Regards,
Ashlesha.

Re: Serial 8250 driver registration:

[Sergei Shtylyov]

Hello.

Ashlesha Shintre wrote:

> Yeah, i thought you might have meant that :-)

> i m starting to think that the uartclk parameter that i pass to the
> platform_add_devices function might be wrong --

> i m passing the standard value of 1843200 for a baudrate of 115200...

    Since it's a standard x86 UART built into the x86 south bridge, it should 
be clocked by the standard 1.8432 MHz clock.

WBR, Sergei