mxc_request_iomux() seg fault

[JasonWhite]

I'm configuring a GPIO as an input for an interrupt for a network device driver.  It works fine the first time around as I bring the interface up.  But if I 'reboot' the board, the next time I bring the interface up a seg fault occurs.  I'm using an IMX35 running a version of Linux 2.6.31.

Unhandled fault: imprecise external abort (0xc06) at 0x00000000
Internal error: : c06 [#1] PREEMPT

PC is at mxc_request_iomux+0x2c/0x154

It looks to be a read of 0x00 if I understand the above, but I am new at Linux device drivers.  Here is how I am configuring the driver.

mxc_request_iomux(MX35_PIN_HCKR, MUX_CONFIG_ALT5);

mxc_iomux_set_input(MUX_IN_GPIO1_IN_6, INPUT_CTL_PATH1);

pad_setting = PAD_CTL_DRV_3_3V | PAD_CTL_HYS_CMOS | PAD_CTL_PKE_NONE | PAD_CTL_100K_PD | PAD_CTL_ODE_CMOS |
                    PAD_CTL_DRV_NORMAL | PAD_CTL_SRE_SLOW;
mxc_iomux_set_pad(MX35_PIN_HCKR, pad_setting);

I also have

gpio_request(IOMUX_TO_GPIO(MX35_PIN_HCKR), NULL);
gpio_direction_input(IOMUX_TO_GPIO(MX35_PIN_HCKR));

but not sure if the above two lines are really needed.

I have

gpio_free(IOMUX_TO_GPIO(MX35_PIN_HCKR));
mxc_free_iomux(MX35_PIN_HCKR, MUX_CONFIG_ALT5);

when the interface is brought down.  Whether I bring the interface down or not, the seg fault still occurs.  The only way to bring the interface up without a seg fault is to totally power off the board.  I've looked into mxc_request_iomux() but I can't see anywhere within that would cause a seg fault.

It seems like something needs to be unconfigured prior to rebooting since a power off fixes it, but I can't seem to find out what.

Any ideas on what to do?

Thanks,

Jason

[jose]

@Jason:

what JTAG do you use before?

how about IDE?

We are scouting for debugger solutions also.

Thanks.

[JasonWhite]

Finally tracked down the problem to the raw read of the mapped memory.  Since it was accessing an FPGA, I asked another team member about this.  He was finally able to track it down to a board reset circuity problem.  'reboot' was not working properly and the FGPA wasn't able to remap its memory (and load its pattern) on reboot.  The hardware people had fixed the issue in a new board spin, but had failed to inform us software guys :(

Hardware problems are super hard to track down especially without a lot of debug support.

What does everyone normally use for hardware debug support?  I've mostly used printk, but I'm used to hardware JTAG or Nexus debuggers for other processors.

Thanks everyone for their help.

Jason

[fabio_estevam]

You should do the iomux settings in your board file (the equivalent of mx35_3stack_gpio.c).

Then inside your driver you should call the GPIO API when needed (gpio_request , gpio_set_value, gpio_get_value, etc).

It is hard to see what is wrong in your case without seeing the source code and the complete kernel dump.

Are you sure my_device is not NULL?

Regards,

Fabio Estevam

[JasonWhite]

This is in a separate kernel module and the imux settings were in the net driver open routine (called on the ifconfig <device> up).  I decided to move the iomux settings around in my code and moved it to the __init routine for the kernel module.  This ruled out the iomux settings causing the problem.  Should have done this sooner.  :)  I think the PC indicated a few addresses ahead of the real problem, which is why I thought it was the imoux function.

I've commented different parts of my code and narrowed it down to my first access of IO memory.

__raw_readw( my_device->io_base + FPGA_IRQ_STATUS_OFFSET );

I read this location to clear out any pending interrupts before calling netif_carrier_on().  Also this is done after setting the irq type and requesting the irq.

The ioremap() routine does not fail and I know io_base is not NULL.  I perform an iounmap() on __exit.  Is there anything else needed with ioremap()?

Thanks,

Jason

[fabio_estevam]

Looks like your settings are correct.

Which file are you putting this IOMUX settings? They should be on your board file, like in arch/arm/mach-mx35/mx35_3stack_gpio.c

The error you are seeing can be due to the usage of these functions within an interrupt context inside your driver.

Regards,

Fabio Estevam

[JasonWhite]

I call this directly after setting up the GPIO

error_code = set_irq_type(IOMUX_TO_IRQ(MX35_PIN_HCKR), IRQF_TRIGGER_FALLING);

[JasonWhite]

Not quite.  Some of the GPIO are different than the PDK.  We are using MX35_PIN_HCKR as an interrupt line.

[daiane_angolini]

Do you mean you´re using the same pin configuration?

[JasonWhite]

Custom board using IMX35..  based off the pdk  Running 2.6.31 that is provided from Freescale

[daiane_angolini]

Please, describe your hardware.