* MCP2518FD : Failed to detect MCP2518FD (osc=0x00000000)
@ 2022-01-31 8:33 petter
2022-01-31 8:42 ` Marc Kleine-Budde
0 siblings, 1 reply; 9+ messages in thread
From: petter @ 2022-01-31 8:33 UTC (permalink / raw)
To: linux-can; +Cc: mkl
Hi Folks,
I am working on an IMX7D board. Some time ago I have back-ported the MCP2518FD driver to the official 5.4.70 NXP kernel and it works fine.
I am struggleing to get the mcp driver working on the latest nxp kernel 5.10.72.
Same hardware.
I did not find any unusal in the logs. pinctrl did not complain, spi seems to initialize normal.
The old kernel with the new (almost old one) device tree works. The new kernel did not work with the old or new device tree.
At the moment I am stuck. Could be anything. Must not be the driver itself.
BR
Niels
mcp2518fd_clk: mcp2818fd_clk {
compatible = "fixed-clock";
#clock-cells = <0>;
clock-frequency = <40000000>;
};
&ecspi2 {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_ecspi2>;
status = "okay";
fsl,spi-num-chipselects = <2>;
cs-gpios = <&gpio5 1 0>, <&gpio1 3 0>;
mcp2518fd@0 {
compatible = "microchip,mcp2518fd";
reg = <0>;
interrupts-extended = <&gpio3 0 IRQ_TYPE_LEVEL_LOW>;
spi-max-frequency = <20000000>;
clocks = <&mcp2518fd_clk>;
};
mcp2518fd@1 {
compatible = "microchip,mcp2518fd";
reg = <1>;
interrupts-extended = <&gpio4 23 IRQ_TYPE_LEVEL_LOW>;
spi-max-frequency = <20000000>;
clocks = <&mcp2518fd_clk>;
};
};
^ permalink raw reply [flat|nested] 9+ messages in thread* Re: MCP2518FD : Failed to detect MCP2518FD (osc=0x00000000) 2022-01-31 8:33 MCP2518FD : Failed to detect MCP2518FD (osc=0x00000000) petter @ 2022-01-31 8:42 ` Marc Kleine-Budde 2022-01-31 9:35 ` petter 0 siblings, 1 reply; 9+ messages in thread From: Marc Kleine-Budde @ 2022-01-31 8:42 UTC (permalink / raw) To: petter; +Cc: linux-can [-- Attachment #1: Type: text/plain, Size: 966 bytes --] On 31.01.2022 09:33:04, petter@ka-long.de wrote: > I am working on an IMX7D board. Some time ago I have back-ported the > MCP2518FD driver to the official 5.4.70 NXP kernel and it works fine. > > I am struggleing to get the mcp driver working on the latest nxp > kernel 5.10.72. > > Same hardware. > > I did not find any unusal in the logs. pinctrl did not complain, spi > seems to initialize normal. > > The old kernel with the new (almost old one) device tree works. The > new kernel did not work with the old or new device tree. > > At the moment I am stuck. Could be anything. Must not be the driver > itself. Is SPI DMA enabled? Try disabling it. regards, Marc -- Pengutronix e.K. | Marc Kleine-Budde | Embedded Linux | https://www.pengutronix.de | Vertretung West/Dortmund | Phone: +49-231-2826-924 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 | [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 488 bytes --] ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: MCP2518FD : Failed to detect MCP2518FD (osc=0x00000000) 2022-01-31 8:42 ` Marc Kleine-Budde @ 2022-01-31 9:35 ` petter 2022-01-31 9:58 ` Marc Kleine-Budde 0 siblings, 1 reply; 9+ messages in thread From: petter @ 2022-01-31 9:35 UTC (permalink / raw) To: linux-can; +Cc: mkl Hi Marc, I have disabled DMAs in imx7s.dtsi for all ecspis and recompile the device tree. Still get the same failure. Thanks Niels ecspi2: spi@30830000 { #address-cells = <1>; #size-cells = <0>; compatible = "fsl,imx7d-ecspi", "fsl,imx51-ecspi"; reg = <0x30830000 0x10000>; interrupts = <GIC_SPI 32 IRQ_TYPE_LEVEL_HIGH>; clocks = <&clks IMX7D_ECSPI2_ROOT_CLK>, <&clks IMX7D_ECSPI2_ROOT_CLK>; clock-names = "ipg", "per"; /* dmas = <&sdma 2 7 1>, <&sdma 3 7 2>; dma-names = "rx", "tx"; */ status = "disabled"; }; Marc Kleine-Budde schrieb am 31.01.2022 08:42 (GMT +00:00): > On 31.01.2022 09:33:04, petter@ka-long.de wrote: >> I am working on an IMX7D board. Some time ago I have back-ported the >> MCP2518FD driver to the official 5.4.70 NXP kernel and it works fine. >> >> I am struggleing to get the mcp driver working on the latest nxp >> kernel 5.10.72. >> >> Same hardware. >> >> I did not find any unusal in the logs. pinctrl did not complain, spi >> seems to initialize normal. >> >> The old kernel with the new (almost old one) device tree works. The >> new kernel did not work with the old or new device tree. >> >> At the moment I am stuck. Could be anything. Must not be the driver >> itself. > > Is SPI DMA enabled? Try disabling it. > > regards, > Marc > > -- > Pengutronix e.K. | Marc Kleine-Budde | > Embedded Linux | https://www.pengutronix.de | > Vertretung West/Dortmund | Phone: +49-231-2826-924 | > Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 | > ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: MCP2518FD : Failed to detect MCP2518FD (osc=0x00000000) 2022-01-31 9:35 ` petter @ 2022-01-31 9:58 ` Marc Kleine-Budde 2022-01-31 12:44 ` petter 0 siblings, 1 reply; 9+ messages in thread From: Marc Kleine-Budde @ 2022-01-31 9:58 UTC (permalink / raw) To: petter; +Cc: linux-can [-- Attachment #1: Type: text/plain, Size: 624 bytes --] On 31.01.2022 10:35:54, petter@ka-long.de wrote: > I have disabled DMAs in imx7s.dtsi for all ecspis and recompile the > device tree. Still get the same failure. You can check if that really works by looking at the used DT: $ dtc -I fs /proc/device-tree Next step would be to get a scope and attach it to the MISO/MOSI/CLk/CS pins. Marc -- Pengutronix e.K. | Marc Kleine-Budde | Embedded Linux | https://www.pengutronix.de | Vertretung West/Dortmund | Phone: +49-231-2826-924 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 | [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 488 bytes --] ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: MCP2518FD : Failed to detect MCP2518FD (osc=0x00000000) 2022-01-31 9:58 ` Marc Kleine-Budde @ 2022-01-31 12:44 ` petter 2022-01-31 13:09 ` Marc Kleine-Budde 0 siblings, 1 reply; 9+ messages in thread From: petter @ 2022-01-31 12:44 UTC (permalink / raw) To: mkl; +Cc: linux-can Hi, DMA is disabled. CLK and MOSI are looking fine. Very interessing, CSs are not asserted when loading driver (on old kernel it does), but I can measure "high" after HW initialisation. Since I did not change the IOs between the old and new device tree assuming the "high" on CS also showing correct PAD / GPIO configuration there seems a problem asserting the CS. cat /sys/kernel/debug/gpio looks good (gpio-3 and gpio-129) gpiochip0: GPIOs 0-31, parent: platform/30200000.gpio, 30200000.gpio: gpio-3 ( |spi1 CS1 ) out hi ACTIVE LOW gpio-5 ( |regulator-vbus ) out lo gpiochip1: GPIOs 64-95, parent: platform/30220000.gpio, 30220000.gpio: gpio-67 ( |spi3 CS0 ) out hi ACTIVE LOW gpiochip2: GPIOs 96-127, parent: platform/30230000.gpio, 30230000.gpio: gpiochip3: GPIOs 128-159, parent: platform/30240000.gpio, 30240000.gpio: gpio-128 ( |cd ) in hi IRQ ACTIVE LOW gpio-129 ( |spi1 CS0 ) out hi ACTIVE LOW BR Niels Marc Kleine-Budde schrieb am 31.01.2022 09:58 (GMT +00:00): > On 31.01.2022 10:35:54, petter@ka-long.de wrote: >> I have disabled DMAs in imx7s.dtsi for all ecspis and recompile the >> device tree. Still get the same failure. > > You can check if that really works by looking at the used DT: > > $ dtc -I fs /proc/device-tree > > Next step would be to get a scope and attach it to the MISO/MOSI/CLk/CS > pins. > > Marc > > -- > Pengutronix e.K. | Marc Kleine-Budde | > Embedded Linux | https://www.pengutronix.de | > Vertretung West/Dortmund | Phone: +49-231-2826-924 | > Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 | > ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: MCP2518FD : Failed to detect MCP2518FD (osc=0x00000000) 2022-01-31 12:44 ` petter @ 2022-01-31 13:09 ` Marc Kleine-Budde 2022-01-31 14:15 ` petter 0 siblings, 1 reply; 9+ messages in thread From: Marc Kleine-Budde @ 2022-01-31 13:09 UTC (permalink / raw) To: petter; +Cc: linux-can [-- Attachment #1: Type: text/plain, Size: 3356 bytes --] On 31.01.2022 13:44:28, petter@ka-long.de wrote: > DMA is disabled. CLK and MOSI are looking fine. > > Very interessing, CSs are not asserted when loading driver (on old > kernel it does), but I can measure "high" after HW initialisation. Asserted means low? > Since I did not change the IOs between the old and new device tree > assuming the "high" on CS also showing correct PAD / GPIO > configuration there seems a problem asserting the CS. | &ecspi2 { | pinctrl-names = "default"; | pinctrl-0 = <&pinctrl_ecspi2>; | status = "okay"; | | fsl,spi-num-chipselects = <2>; V | cs-gpios = <&gpio5 1 0>, <&gpio1 3 0>; ^ ^ Have a look at include/dt-bindings/gpio/gpio.h: /* Bit 0 express polarity */ #define GPIO_ACTIVE_HIGH 0 #define GPIO_ACTIVE_LOW 1 I'm using GPIO_ACTIVE_LOW in my DT on imx6dl. | | | mcp2518fd@0 { | compatible = "microchip,mcp2518fd"; | reg = <0>; | interrupts-extended = <&gpio3 0 IRQ_TYPE_LEVEL_LOW>; | spi-max-frequency = <20000000>; | clocks = <&mcp2518fd_clk>; | }; | | mcp2518fd@1 { | compatible = "microchip,mcp2518fd"; | reg = <1>; | interrupts-extended = <&gpio4 23 IRQ_TYPE_LEVEL_LOW>; | spi-max-frequency = <20000000>; | clocks = <&mcp2518fd_clk>; | }; | }; > cat /sys/kernel/debug/gpio looks good (gpio-3 and gpio-129) This doesn't look consistent with your DT, above. I'm always confused with numbering starting with 0 and 1 in the DT, but I think: gpiochip0: gpio-3 == &gpio1 3 gpiochip3: gpio-129 == &gpio4 1 (not &gpio5 1 as in you DT) > gpiochip0: GPIOs 0-31, parent: platform/30200000.gpio, 30200000.gpio: > gpio-3 ( |spi1 CS1 ) out hi ACTIVE LOW > gpio-5 ( |regulator-vbus ) out lo > > gpiochip1: GPIOs 64-95, parent: platform/30220000.gpio, 30220000.gpio: > gpio-67 ( |spi3 CS0 ) out hi ACTIVE LOW > > gpiochip2: GPIOs 96-127, parent: platform/30230000.gpio, 30230000.gpio: > > gpiochip3: GPIOs 128-159, parent: platform/30240000.gpio, 30240000.gpio: > gpio-128 ( |cd ) in hi IRQ ACTIVE LOW > gpio-129 ( |spi1 CS0 ) out hi ACTIVE LOW regards, Marc -- Pengutronix e.K. | Marc Kleine-Budde | Embedded Linux | https://www.pengutronix.de | Vertretung West/Dortmund | Phone: +49-231-2826-924 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 | [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 488 bytes --] ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: MCP2518FD : Failed to detect MCP2518FD (osc=0x00000000) 2022-01-31 13:09 ` Marc Kleine-Budde @ 2022-01-31 14:15 ` petter 2022-01-31 15:17 ` Marc Kleine-Budde 0 siblings, 1 reply; 9+ messages in thread From: petter @ 2022-01-31 14:15 UTC (permalink / raw) To: mkl; +Cc: linux-can Hi Marc, CS = High (de-asserted, slave not selected) CS = low (asserted, slave selected) I also did not like the 0/1 starting point, but it is defined here: aliases { gpio0 = &gpio1; gpio1 = &gpio2; gpio2 = &gpio3; ... &gpio1 3 = gpiochip0 = 0*32 + 3 = gpio3 &gpio5 1 = gpiochip4 = 4*32 + 1 = gpio129 Interresting with ACTIVE HIGH / LOW. cat debug/gpio tells me "ACTIVE LOW" but anyway I did not see CS toggle at all. Also tested "1" but nothing changed. By the way, the old kernel is working with the new device tree. I did a make clean and make sure that I really use latest build artefacts. Everything is okay. Still failure. Maybe there are problems when using "make imx_v7_defconfig" ... possible conflicts between drivers because there are much changes between 5.4 and 5.10 whats enabled and/or new by default ? Try to go with a very small kernel. BR Niels Marc Kleine-Budde schrieb am 31.01.2022 13:09 (GMT +00:00): > On 31.01.2022 13:44:28, petter@ka-long.de wrote: >> DMA is disabled. CLK and MOSI are looking fine. >> >> Very interessing, CSs are not asserted when loading driver (on old >> kernel it does), but I can measure "high" after HW initialisation. > > Asserted means low? > >> Since I did not change the IOs between the old and new device tree >> assuming the "high" on CS also showing correct PAD / GPIO >> configuration there seems a problem asserting the CS. > > | &ecspi2 { > | pinctrl-names = "default"; > | pinctrl-0 = <&pinctrl_ecspi2>; > | status = "okay"; > | > | fsl,spi-num-chipselects = <2>; > V > | cs-gpios = <&gpio5 1 0>, <&gpio1 3 0>; > ^ ^ > Have a look at include/dt-bindings/gpio/gpio.h: > > /* Bit 0 express polarity */ > #define GPIO_ACTIVE_HIGH 0 > #define GPIO_ACTIVE_LOW 1 > > I'm using GPIO_ACTIVE_LOW in my DT on imx6dl. > > | > | > | mcp2518fd@0 { > | compatible = "microchip,mcp2518fd"; > | reg = <0>; > | interrupts-extended = <&gpio3 0 IRQ_TYPE_LEVEL_LOW>; > | spi-max-frequency = <20000000>; > | clocks = <&mcp2518fd_clk>; > | }; > > > > | > | mcp2518fd@1 { > | compatible = "microchip,mcp2518fd"; > | reg = <1>; > | interrupts-extended = <&gpio4 23 IRQ_TYPE_LEVEL_LOW>; > | spi-max-frequency = <20000000>; > | clocks = <&mcp2518fd_clk>; > | }; > > > > | }; > >> cat /sys/kernel/debug/gpio looks good (gpio-3 and gpio-129) > > This doesn't look consistent with your DT, above. I'm always confused > with numbering starting with 0 and 1 in the DT, but I think: > > gpiochip0: gpio-3 == &gpio1 3 > gpiochip3: gpio-129 == &gpio4 1 (not &gpio5 1 as in you DT) > >> gpiochip0: GPIOs 0-31, parent: platform/30200000.gpio, 30200000.gpio: >> gpio-3 ( |spi1 CS1 ) out hi ACTIVE LOW >> gpio-5 ( |regulator-vbus ) out lo >> >> gpiochip1: GPIOs 64-95, parent: platform/30220000.gpio, 30220000.gpio: >> gpio-67 ( |spi3 CS0 ) out hi ACTIVE LOW >> >> gpiochip2: GPIOs 96-127, parent: platform/30230000.gpio, 30230000.gpio: >> >> gpiochip3: GPIOs 128-159, parent: platform/30240000.gpio, 30240000.gpio: >> gpio-128 ( |cd ) in hi IRQ ACTIVE LOW >> gpio-129 ( |spi1 CS0 ) out hi ACTIVE LOW > > regards, > Marc > > -- > Pengutronix e.K. | Marc Kleine-Budde | > Embedded Linux | https://www.pengutronix.de | > Vertretung West/Dortmund | Phone: +49-231-2826-924 | > Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 | > ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: MCP2518FD : Failed to detect MCP2518FD (osc=0x00000000) 2022-01-31 14:15 ` petter @ 2022-01-31 15:17 ` Marc Kleine-Budde 2022-02-01 9:08 ` petter 0 siblings, 1 reply; 9+ messages in thread From: Marc Kleine-Budde @ 2022-01-31 15:17 UTC (permalink / raw) To: petter; +Cc: linux-can [-- Attachment #1: Type: text/plain, Size: 2240 bytes --] On 31.01.2022 15:15:03, petter@ka-long.de wrote: > > Hi Marc, > > CS = High (de-asserted, slave not selected) > CS = low (asserted, slave selected) > > I also did not like the 0/1 starting point, but it is defined here: > > aliases { > gpio0 = &gpio1; > gpio1 = &gpio2; > gpio2 = &gpio3; > ... > > > > &gpio1 3 = gpiochip0 = 0*32 + 3 = gpio3 > &gpio5 1 = gpiochip4 = 4*32 + 1 = gpio129 In your output of /sys/kernel/debug/gpio, gpiochip3 starts at 128: >> gpiochip3: GPIOs 128-159, parent: platform/30240000.gpio, 30240000.gpio: >> gpio-128 ( |cd ) in hi IRQ ACTIVE LOW >> gpio-129 ( |spi1 CS0 ) out hi ACTIVE LOW Here it looks like this: gpiochip4: GPIOs 128-159, parent: platform/20ac000.gpio, 20ac000.gpio: gpio-130 (EIM_A25 |user1 ) out lo ACTIVE LOW gpio-133 (GPIO5_05 ) gpio-134 (GPIO5_06 |reset ) out lo gpio-135 (GPIO5_07 ) gpio-136 (GPIO5_08 ) gpio-137 (CSPI2_CS1 |spi1 CS1 ) out hi ACTIVE LOW gpio-138 (CSPI2_MOSI ) gpio-139 (CSPI2_MISO ) gpio-140 (CSPI2_CS0 |spi1 CS0 ) out hi ACTIVE LOW gpio-141 (CSPI2_CLK ) > Interresting with ACTIVE HIGH / LOW. cat debug/gpio tells me "ACTIVE > LOW" but anyway I did not see CS toggle at all. Also tested "1" but > nothing changed. > > By the way, the old kernel is working with the new device tree. > > I did a make clean and make sure that I really use latest build > artefacts. Everything is okay. Still failure. > > Maybe there are problems when using "make imx_v7_defconfig" ... > possible conflicts between drivers because there are much changes > between 5.4 and 5.10 whats enabled and/or new by default ? Try to go > with a very small kernel. There shouldn't be any conflicts between drivers. regards, Marc -- Pengutronix e.K. | Marc Kleine-Budde | Embedded Linux | https://www.pengutronix.de | Vertretung West/Dortmund | Phone: +49-231-2826-924 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 | [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 488 bytes --] ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: MCP2518FD : Failed to detect MCP2518FD (osc=0x00000000) 2022-01-31 15:17 ` Marc Kleine-Budde @ 2022-02-01 9:08 ` petter 0 siblings, 0 replies; 9+ messages in thread From: petter @ 2022-02-01 9:08 UTC (permalink / raw) To: mkl; +Cc: linux-can Hi Folks, Embarrassing ... There was a small build of 5. There was an hw change afterwarts regardging CS. Reworked 4/5. I got the one without rework but special "local" working test software. I wonder why switching to master is not working ... Sorry for your time lapse. BR Niels Marc Kleine-Budde schrieb am 31.01.2022 15:17 (GMT +00:00): > On 31.01.2022 15:15:03, petter@ka-long.de wrote: >> >> Hi Marc, >> >> CS = High (de-asserted, slave not selected) >> CS = low (asserted, slave selected) >> >> I also did not like the 0/1 starting point, but it is defined here: >> >> aliases { >> gpio0 = &gpio1; >> gpio1 = &gpio2; >> gpio2 = &gpio3; >> ... >> >> >> >> &gpio1 3 = gpiochip0 = 0*32 + 3 = gpio3 >> &gpio5 1 = gpiochip4 = 4*32 + 1 = gpio129 > > In your output of /sys/kernel/debug/gpio, gpiochip3 starts at 128: > >>> gpiochip3: GPIOs 128-159, parent: platform/30240000.gpio, 30240000.gpio: >>> gpio-128 ( |cd ) in hi IRQ ACTIVE LOW >>> gpio-129 ( |spi1 CS0 ) out hi ACTIVE LOW > > Here it looks like this: > > gpiochip4: GPIOs 128-159, parent: platform/20ac000.gpio, 20ac000.gpio: > gpio-130 (EIM_A25 |user1 ) out lo ACTIVE LOW > gpio-133 (GPIO5_05 ) > gpio-134 (GPIO5_06 |reset ) out lo > gpio-135 (GPIO5_07 ) > gpio-136 (GPIO5_08 ) > gpio-137 (CSPI2_CS1 |spi1 CS1 ) out hi ACTIVE LOW > gpio-138 (CSPI2_MOSI ) > gpio-139 (CSPI2_MISO ) > gpio-140 (CSPI2_CS0 |spi1 CS0 ) out hi ACTIVE LOW > gpio-141 (CSPI2_CLK ) > >> Interresting with ACTIVE HIGH / LOW. cat debug/gpio tells me "ACTIVE >> LOW" but anyway I did not see CS toggle at all. Also tested "1" but >> nothing changed. >> >> By the way, the old kernel is working with the new device tree. >> >> I did a make clean and make sure that I really use latest build >> artefacts. Everything is okay. Still failure. >> >> Maybe there are problems when using "make imx_v7_defconfig" ... >> possible conflicts between drivers because there are much changes >> between 5.4 and 5.10 whats enabled and/or new by default ? Try to go >> with a very small kernel. > > There shouldn't be any conflicts between drivers. > > regards, > Marc > > -- > Pengutronix e.K. | Marc Kleine-Budde | > Embedded Linux | https://www.pengutronix.de | > Vertretung West/Dortmund | Phone: +49-231-2826-924 | > Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 | > ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2022-02-01 9:08 UTC | newest] Thread overview: 9+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2022-01-31 8:33 MCP2518FD : Failed to detect MCP2518FD (osc=0x00000000) petter 2022-01-31 8:42 ` Marc Kleine-Budde 2022-01-31 9:35 ` petter 2022-01-31 9:58 ` Marc Kleine-Budde 2022-01-31 12:44 ` petter 2022-01-31 13:09 ` Marc Kleine-Budde 2022-01-31 14:15 ` petter 2022-01-31 15:17 ` Marc Kleine-Budde 2022-02-01 9:08 ` petter
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox