Re: using mmc2 on panda [was: Regression 3.11-rc1: omap4panda: no usb and consequently no ethernet]
On Wed, 2013-10-02 at 12:20 +0200, Arend van Spriel wrote: > On 10/01/2013 01:29 PM, Luca Coelho wrote: > > Hi, > > > > On Tue, 2013-10-01 at 12:53 +0200, Arend van Spriel wrote: > >> On 10/01/2013 11:53 AM, Roger Quadros wrote: > >>> On 10/01/2013 12:49 PM, Roger Quadros wrote: > Hi Arend, > > On 10/01/2013 11:05 AM, Arend van Spriel wrote: > > On 07/19/2013 12:57 PM, Arend van Spriel wrote: > >> On 07/19/2013 12:49 PM, Roger Quadros wrote: > >>> On 07/19/2013 01:36 PM, Arend van Spriel wrote: > On 07/18/2013 10:59 AM, Tony Lindgren wrote: > > Then for the SDIO with device tree, take a look at the following > > patches: > > > > [PATCH 0/3] WLAN support for omap4 when booted with devicetree > > http://comments.gmane.org/gmane.linux.ports.arm.omap/97522# > > I have been looking at the pandaboard patch in the series above and I > do have a question. Among other things the patch adds these dt > entries. > > +0x108 0x118/* sdmmc5_clk.sdmmc5_clk INPUT_PULLUP | > MODE0 */ > +0x10a 0x118/* sdmmc5_cmd.sdmmc5_cmd INPUT_PULLUP | > MODE0 */ > > If I look at the similar names in the deceased board-omap4panda.c: > > board-omap4panda.c:OMAP4_MUX(SDMMC5_CMD, OMAP_MUX_MODE0 | > OMAP_PIN_INPUT_PULLUP), > board-omap4panda.c:OMAP4_MUX(SDMMC5_CLK, OMAP_MUX_MODE0 | > OMAP_PIN_INPUT_PULLUP), > > and in mux44xx.h: > > mux44xx.h:#define OMAP4_CTRL_MODULE_PAD_SDMMC5_CLK_OFFSET0x0148 > mux44xx.h:#define OMAP4_CTRL_MODULE_PAD_SDMMC5_CMD_OFFSET0x014a > > So how did 0x0148 get 0x0108 in DT and 0x014a get 0x010a. There is > probably an explanation to it and it would help my understanding to > know where this difference comes from. Hope you can help me out here. > > >>> > >>> If you see omap4.dtsi, omap4_pmx_core starts at register address > >>> 0x4a100040. > >>> > >>> So, you need to subtract 0x40 from the offsets defined in mux44xx.h > >>> for pmx_core registers. > >> > >> That was what I was looking for. Thanks! > > > > Hi Roger, > > > > It has been a while, but I would like to pickup this thread. We have a > > couple of pandaboards used as test setup. These have an SDIO adapter > > hooked up to expansion connector A using MMC2. I have attached the > > patch file (just ignore platform_data stuff). Now on one board it > > works, but not for the other. I suspect a board issue so listing the > > two types that we use: > > > > PandaBoard rev A2 (dmesg: OMAP4430 ES2.1): works > > PandaBoardES rev B1 (dmesg: OMAP4460 ES1.1): nope > > > > Any hints for me. > > Does your PandaboardES have the WLAN chip (U4) mounted? If yes, how do > you isolate > it from your external SDIO adapter? > >> > >> On my 4460 board in front of me U4 is not populated, but U3 is (the TiWi > >> thing). > >> > >>> > >>> OK, just realized that the expansion connector uses different pads for > >>> MMC2. However, you still > >>> need to make sure that the other pins (connected to on board WLAN chip) > >>> are not muxed as MMC2. > >> > >> I think Luciano added DT patches for on-board WLAN and it uses MMC5 if I > >> am not mistaken(?). Attached are the dmesg logs of the two boards. > > > > I sent 2 patch series to add DT support for the on-board WLAN, but they > > were not applied, since there were some comments that required changes. > > I really don't have the time to revisit them now that I'm not with TI > > anymore, so I'm hoping someone else will pick them up at some point. > > I found this one in my email archive: > > [PATCH v2 0/4] ARM: dts: add WiLink support to panda and omap4-sdp > > Guess that is what you are referring to, right? Yes, that one and also this (which implements DT in the driver itself): [PATCH v4 0/8] wilink: add device tree support http://mid.gmane.org/1375189476-21557-1-git-send-email-coe...@ti.com -- Luca. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: using mmc2 on panda [was: Regression 3.11-rc1: omap4panda: no usb and consequently no ethernet]
On 10/01/2013 01:29 PM, Luca Coelho wrote: Hi, On Tue, 2013-10-01 at 12:53 +0200, Arend van Spriel wrote: On 10/01/2013 11:53 AM, Roger Quadros wrote: On 10/01/2013 12:49 PM, Roger Quadros wrote: Hi Arend, On 10/01/2013 11:05 AM, Arend van Spriel wrote: On 07/19/2013 12:57 PM, Arend van Spriel wrote: On 07/19/2013 12:49 PM, Roger Quadros wrote: On 07/19/2013 01:36 PM, Arend van Spriel wrote: On 07/18/2013 10:59 AM, Tony Lindgren wrote: Then for the SDIO with device tree, take a look at the following patches: [PATCH 0/3] WLAN support for omap4 when booted with devicetree http://comments.gmane.org/gmane.linux.ports.arm.omap/97522# I have been looking at the pandaboard patch in the series above and I do have a question. Among other things the patch adds these dt entries. +0x108 0x118/* sdmmc5_clk.sdmmc5_clk INPUT_PULLUP | MODE0 */ +0x10a 0x118/* sdmmc5_cmd.sdmmc5_cmd INPUT_PULLUP | MODE0 */ If I look at the similar names in the deceased board-omap4panda.c: board-omap4panda.c:OMAP4_MUX(SDMMC5_CMD, OMAP_MUX_MODE0 | OMAP_PIN_INPUT_PULLUP), board-omap4panda.c:OMAP4_MUX(SDMMC5_CLK, OMAP_MUX_MODE0 | OMAP_PIN_INPUT_PULLUP), and in mux44xx.h: mux44xx.h:#define OMAP4_CTRL_MODULE_PAD_SDMMC5_CLK_OFFSET0x0148 mux44xx.h:#define OMAP4_CTRL_MODULE_PAD_SDMMC5_CMD_OFFSET0x014a So how did 0x0148 get 0x0108 in DT and 0x014a get 0x010a. There is probably an explanation to it and it would help my understanding to know where this difference comes from. Hope you can help me out here. If you see omap4.dtsi, omap4_pmx_core starts at register address 0x4a100040. So, you need to subtract 0x40 from the offsets defined in mux44xx.h for pmx_core registers. That was what I was looking for. Thanks! Hi Roger, It has been a while, but I would like to pickup this thread. We have a couple of pandaboards used as test setup. These have an SDIO adapter hooked up to expansion connector A using MMC2. I have attached the patch file (just ignore platform_data stuff). Now on one board it works, but not for the other. I suspect a board issue so listing the two types that we use: PandaBoard rev A2 (dmesg: OMAP4430 ES2.1): works PandaBoardES rev B1 (dmesg: OMAP4460 ES1.1): nope Any hints for me. Does your PandaboardES have the WLAN chip (U4) mounted? If yes, how do you isolate it from your external SDIO adapter? On my 4460 board in front of me U4 is not populated, but U3 is (the TiWi thing). OK, just realized that the expansion connector uses different pads for MMC2. However, you still need to make sure that the other pins (connected to on board WLAN chip) are not muxed as MMC2. I think Luciano added DT patches for on-board WLAN and it uses MMC5 if I am not mistaken(?). Attached are the dmesg logs of the two boards. I sent 2 patch series to add DT support for the on-board WLAN, but they were not applied, since there were some comments that required changes. I really don't have the time to revisit them now that I'm not with TI anymore, so I'm hoping someone else will pick them up at some point. I found this one in my email archive: [PATCH v2 0/4] ARM: dts: add WiLink support to panda and omap4-sdp Guess that is what you are referring to, right? Gr. AvS -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: using mmc2 on panda [was: Regression 3.11-rc1: omap4panda: no usb and consequently no ethernet]
On 10/01/2013 03:19 PM, Balaji T K wrote: Hi Roger, It has been a while, but I would like to pickup this thread. We have a couple of pandaboards used as test setup. These have an SDIO adapter hooked up to expansion connector A using MMC2. I have attached the patch file (just ignore platform_data stuff). Now on one board it works, but not for the other. I suspect a board issue so listing the two types that we use: PandaBoard rev A2 (dmesg: OMAP4430 ES2.1): works PandaBoardES rev B1 (dmesg: OMAP4460 ES1.1): nope Any hints for me. Does your PandaboardES have the WLAN chip (U4) mounted? If yes, how do you isolate it from your external SDIO adapter? On my 4460 board in front of me U4 is not populated, but U3 is (the TiWi thing). OK, just realized that the expansion connector uses different pads for MMC2. However, you still need to make sure that the other pins (connected to on board WLAN chip) are not muxed as MMC2. I think Luciano added DT patches for on-board WLAN and it uses MMC5 if I am not mistaken(?). Attached are the dmesg logs of the two boards. Right. WLAN is supposed to use MMC5. But if you don't have Luca's patches, can you please ensure that those pins are muxed either as safe mode or as MMC5? Default seems to be safe mode, but you should cross check. Also in your patches you have set mmc2-clk to PIN_INPUT_PULLUP Shouldn't it be PIN_OUTPUT? Still I have no clue why it works on 4430 and not on 4460. Are you using the same bootloader image on both boards? if you are using vaux1, can you check the voltage levels, From dmesg you attached, vaux1 is set to 1.8V on omap4430 and to 2.8V on OMAP4460 4430 [2.425750] VAUX1_6030: 1000 <--> 3000 mV at 1800 mV 4460 [2.244262] VAUX1_6030: 1000 <--> 3000 mV at 2800 mV Nice catch. Not sure whether this is an issue, but worth looking into. Can you also check with MMC_DEBUG enabled for any clues. building cheers, -roger -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: using mmc2 on panda [was: Regression 3.11-rc1: omap4panda: no usb and consequently no ethernet]
On 10/01/2013 03:19 PM, Balaji T K wrote: Hi Roger, It has been a while, but I would like to pickup this thread. We have a couple of pandaboards used as test setup. These have an SDIO adapter hooked up to expansion connector A using MMC2. I have attached the patch file (just ignore platform_data stuff). Now on one board it works, but not for the other. I suspect a board issue so listing the two types that we use: PandaBoard rev A2 (dmesg: OMAP4430 ES2.1): works PandaBoardES rev B1 (dmesg: OMAP4460 ES1.1): nope Any hints for me. Does your PandaboardES have the WLAN chip (U4) mounted? If yes, how do you isolate it from your external SDIO adapter? On my 4460 board in front of me U4 is not populated, but U3 is (the TiWi thing). OK, just realized that the expansion connector uses different pads for MMC2. However, you still need to make sure that the other pins (connected to on board WLAN chip) are not muxed as MMC2. I think Luciano added DT patches for on-board WLAN and it uses MMC5 if I am not mistaken(?). Attached are the dmesg logs of the two boards. Right. WLAN is supposed to use MMC5. But if you don't have Luca's patches, can you please ensure that those pins are muxed either as safe mode or as MMC5? Default seems to be safe mode, but you should cross check. Also in your patches you have set mmc2-clk to PIN_INPUT_PULLUP Shouldn't it be PIN_OUTPUT? Still I have no clue why it works on 4430 and not on 4460. Are you using the same bootloader image on both boards? if you are using vaux1, can you check the voltage levels, From dmesg you attached, vaux1 is set to 1.8V on omap4430 and to 2.8V on OMAP4460 4430 [2.425750] VAUX1_6030: 1000 -- 3000 mV at 1800 mV 4460 [2.244262] VAUX1_6030: 1000 -- 3000 mV at 2800 mV Nice catch. Not sure whether this is an issue, but worth looking into. Can you also check with MMC_DEBUG enabled for any clues. building cheers, -roger -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: using mmc2 on panda [was: Regression 3.11-rc1: omap4panda: no usb and consequently no ethernet]
On 10/01/2013 01:29 PM, Luca Coelho wrote: Hi, On Tue, 2013-10-01 at 12:53 +0200, Arend van Spriel wrote: On 10/01/2013 11:53 AM, Roger Quadros wrote: On 10/01/2013 12:49 PM, Roger Quadros wrote: Hi Arend, On 10/01/2013 11:05 AM, Arend van Spriel wrote: On 07/19/2013 12:57 PM, Arend van Spriel wrote: On 07/19/2013 12:49 PM, Roger Quadros wrote: On 07/19/2013 01:36 PM, Arend van Spriel wrote: On 07/18/2013 10:59 AM, Tony Lindgren wrote: Then for the SDIO with device tree, take a look at the following patches: [PATCH 0/3] WLAN support for omap4 when booted with devicetree http://comments.gmane.org/gmane.linux.ports.arm.omap/97522# I have been looking at the pandaboard patch in the series above and I do have a question. Among other things the patch adds these dt entries. +0x108 0x118/* sdmmc5_clk.sdmmc5_clk INPUT_PULLUP | MODE0 */ +0x10a 0x118/* sdmmc5_cmd.sdmmc5_cmd INPUT_PULLUP | MODE0 */ If I look at the similar names in the deceased board-omap4panda.c: board-omap4panda.c:OMAP4_MUX(SDMMC5_CMD, OMAP_MUX_MODE0 | OMAP_PIN_INPUT_PULLUP), board-omap4panda.c:OMAP4_MUX(SDMMC5_CLK, OMAP_MUX_MODE0 | OMAP_PIN_INPUT_PULLUP), and in mux44xx.h: mux44xx.h:#define OMAP4_CTRL_MODULE_PAD_SDMMC5_CLK_OFFSET0x0148 mux44xx.h:#define OMAP4_CTRL_MODULE_PAD_SDMMC5_CMD_OFFSET0x014a So how did 0x0148 get 0x0108 in DT and 0x014a get 0x010a. There is probably an explanation to it and it would help my understanding to know where this difference comes from. Hope you can help me out here. If you see omap4.dtsi, omap4_pmx_core starts at register address 0x4a100040. So, you need to subtract 0x40 from the offsets defined in mux44xx.h for pmx_core registers. That was what I was looking for. Thanks! Hi Roger, It has been a while, but I would like to pickup this thread. We have a couple of pandaboards used as test setup. These have an SDIO adapter hooked up to expansion connector A using MMC2. I have attached the patch file (just ignore platform_data stuff). Now on one board it works, but not for the other. I suspect a board issue so listing the two types that we use: PandaBoard rev A2 (dmesg: OMAP4430 ES2.1): works PandaBoardES rev B1 (dmesg: OMAP4460 ES1.1): nope Any hints for me. Does your PandaboardES have the WLAN chip (U4) mounted? If yes, how do you isolate it from your external SDIO adapter? On my 4460 board in front of me U4 is not populated, but U3 is (the TiWi thing). OK, just realized that the expansion connector uses different pads for MMC2. However, you still need to make sure that the other pins (connected to on board WLAN chip) are not muxed as MMC2. I think Luciano added DT patches for on-board WLAN and it uses MMC5 if I am not mistaken(?). Attached are the dmesg logs of the two boards. I sent 2 patch series to add DT support for the on-board WLAN, but they were not applied, since there were some comments that required changes. I really don't have the time to revisit them now that I'm not with TI anymore, so I'm hoping someone else will pick them up at some point. I found this one in my email archive: [PATCH v2 0/4] ARM: dts: add WiLink support to panda and omap4-sdp Guess that is what you are referring to, right? Gr. AvS -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: using mmc2 on panda [was: Regression 3.11-rc1: omap4panda: no usb and consequently no ethernet]
On Wed, 2013-10-02 at 12:20 +0200, Arend van Spriel wrote: On 10/01/2013 01:29 PM, Luca Coelho wrote: Hi, On Tue, 2013-10-01 at 12:53 +0200, Arend van Spriel wrote: On 10/01/2013 11:53 AM, Roger Quadros wrote: On 10/01/2013 12:49 PM, Roger Quadros wrote: Hi Arend, On 10/01/2013 11:05 AM, Arend van Spriel wrote: On 07/19/2013 12:57 PM, Arend van Spriel wrote: On 07/19/2013 12:49 PM, Roger Quadros wrote: On 07/19/2013 01:36 PM, Arend van Spriel wrote: On 07/18/2013 10:59 AM, Tony Lindgren wrote: Then for the SDIO with device tree, take a look at the following patches: [PATCH 0/3] WLAN support for omap4 when booted with devicetree http://comments.gmane.org/gmane.linux.ports.arm.omap/97522# I have been looking at the pandaboard patch in the series above and I do have a question. Among other things the patch adds these dt entries. +0x108 0x118/* sdmmc5_clk.sdmmc5_clk INPUT_PULLUP | MODE0 */ +0x10a 0x118/* sdmmc5_cmd.sdmmc5_cmd INPUT_PULLUP | MODE0 */ If I look at the similar names in the deceased board-omap4panda.c: board-omap4panda.c:OMAP4_MUX(SDMMC5_CMD, OMAP_MUX_MODE0 | OMAP_PIN_INPUT_PULLUP), board-omap4panda.c:OMAP4_MUX(SDMMC5_CLK, OMAP_MUX_MODE0 | OMAP_PIN_INPUT_PULLUP), and in mux44xx.h: mux44xx.h:#define OMAP4_CTRL_MODULE_PAD_SDMMC5_CLK_OFFSET0x0148 mux44xx.h:#define OMAP4_CTRL_MODULE_PAD_SDMMC5_CMD_OFFSET0x014a So how did 0x0148 get 0x0108 in DT and 0x014a get 0x010a. There is probably an explanation to it and it would help my understanding to know where this difference comes from. Hope you can help me out here. If you see omap4.dtsi, omap4_pmx_core starts at register address 0x4a100040. So, you need to subtract 0x40 from the offsets defined in mux44xx.h for pmx_core registers. That was what I was looking for. Thanks! Hi Roger, It has been a while, but I would like to pickup this thread. We have a couple of pandaboards used as test setup. These have an SDIO adapter hooked up to expansion connector A using MMC2. I have attached the patch file (just ignore platform_data stuff). Now on one board it works, but not for the other. I suspect a board issue so listing the two types that we use: PandaBoard rev A2 (dmesg: OMAP4430 ES2.1): works PandaBoardES rev B1 (dmesg: OMAP4460 ES1.1): nope Any hints for me. Does your PandaboardES have the WLAN chip (U4) mounted? If yes, how do you isolate it from your external SDIO adapter? On my 4460 board in front of me U4 is not populated, but U3 is (the TiWi thing). OK, just realized that the expansion connector uses different pads for MMC2. However, you still need to make sure that the other pins (connected to on board WLAN chip) are not muxed as MMC2. I think Luciano added DT patches for on-board WLAN and it uses MMC5 if I am not mistaken(?). Attached are the dmesg logs of the two boards. I sent 2 patch series to add DT support for the on-board WLAN, but they were not applied, since there were some comments that required changes. I really don't have the time to revisit them now that I'm not with TI anymore, so I'm hoping someone else will pick them up at some point. I found this one in my email archive: [PATCH v2 0/4] ARM: dts: add WiLink support to panda and omap4-sdp Guess that is what you are referring to, right? Yes, that one and also this (which implements DT in the driver itself): [PATCH v4 0/8] wilink: add device tree support http://mid.gmane.org/1375189476-21557-1-git-send-email-coe...@ti.com -- Luca. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: using mmc2 on panda [was: Regression 3.11-rc1: omap4panda: no usb and consequently no ethernet]
Hi Roger, It has been a while, but I would like to pickup this thread. We have a couple of pandaboards used as test setup. These have an SDIO adapter hooked up to expansion connector A using MMC2. I have attached the patch file (just ignore platform_data stuff). Now on one board it works, but not for the other. I suspect a board issue so listing the two types that we use: PandaBoard rev A2 (dmesg: OMAP4430 ES2.1): works PandaBoardES rev B1 (dmesg: OMAP4460 ES1.1): nope Any hints for me. Does your PandaboardES have the WLAN chip (U4) mounted? If yes, how do you isolate it from your external SDIO adapter? On my 4460 board in front of me U4 is not populated, but U3 is (the TiWi thing). OK, just realized that the expansion connector uses different pads for MMC2. However, you still need to make sure that the other pins (connected to on board WLAN chip) are not muxed as MMC2. I think Luciano added DT patches for on-board WLAN and it uses MMC5 if I am not mistaken(?). Attached are the dmesg logs of the two boards. Right. WLAN is supposed to use MMC5. But if you don't have Luca's patches, can you please ensure that those pins are muxed either as safe mode or as MMC5? Default seems to be safe mode, but you should cross check. Also in your patches you have set mmc2-clk to PIN_INPUT_PULLUP Shouldn't it be PIN_OUTPUT? Still I have no clue why it works on 4430 and not on 4460. Are you using the same bootloader image on both boards? if you are using vaux1, can you check the voltage levels, From dmesg you attached, vaux1 is set to 1.8V on omap4430 and to 2.8V on OMAP4460 4430 [2.425750] VAUX1_6030: 1000 <--> 3000 mV at 1800 mV 4460 [2.244262] VAUX1_6030: 1000 <--> 3000 mV at 2800 mV Can you also check with MMC_DEBUG enabled for any clues. cheers, -roger -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: using mmc2 on panda [was: Regression 3.11-rc1: omap4panda: no usb and consequently no ethernet]
On 10/01/2013 01:53 PM, Arend van Spriel wrote: > On 10/01/2013 11:53 AM, Roger Quadros wrote: >> On 10/01/2013 12:49 PM, Roger Quadros wrote: >>> Hi Arend, >>> >>> On 10/01/2013 11:05 AM, Arend van Spriel wrote: On 07/19/2013 12:57 PM, Arend van Spriel wrote: > On 07/19/2013 12:49 PM, Roger Quadros wrote: >> On 07/19/2013 01:36 PM, Arend van Spriel wrote: >>> On 07/18/2013 10:59 AM, Tony Lindgren wrote: Then for the SDIO with device tree, take a look at the following patches: [PATCH 0/3] WLAN support for omap4 when booted with devicetree http://comments.gmane.org/gmane.linux.ports.arm.omap/97522# >>> >>> I have been looking at the pandaboard patch in the series above and I >>> do have a question. Among other things the patch adds these dt entries. >>> >>> +0x108 0x118/* sdmmc5_clk.sdmmc5_clk INPUT_PULLUP | >>> MODE0 */ >>> +0x10a 0x118/* sdmmc5_cmd.sdmmc5_cmd INPUT_PULLUP | >>> MODE0 */ >>> >>> If I look at the similar names in the deceased board-omap4panda.c: >>> >>> board-omap4panda.c:OMAP4_MUX(SDMMC5_CMD, OMAP_MUX_MODE0 | >>> OMAP_PIN_INPUT_PULLUP), >>> board-omap4panda.c:OMAP4_MUX(SDMMC5_CLK, OMAP_MUX_MODE0 | >>> OMAP_PIN_INPUT_PULLUP), >>> >>> and in mux44xx.h: >>> >>> mux44xx.h:#define OMAP4_CTRL_MODULE_PAD_SDMMC5_CLK_OFFSET0x0148 >>> mux44xx.h:#define OMAP4_CTRL_MODULE_PAD_SDMMC5_CMD_OFFSET0x014a >>> >>> So how did 0x0148 get 0x0108 in DT and 0x014a get 0x010a. There is >>> probably an explanation to it and it would help my understanding to >>> know where this difference comes from. Hope you can help me out here. >>> >> >> If you see omap4.dtsi, omap4_pmx_core starts at register address >> 0x4a100040. >> >> So, you need to subtract 0x40 from the offsets defined in mux44xx.h >> for pmx_core registers. > > That was what I was looking for. Thanks! Hi Roger, It has been a while, but I would like to pickup this thread. We have a couple of pandaboards used as test setup. These have an SDIO adapter hooked up to expansion connector A using MMC2. I have attached the patch file (just ignore platform_data stuff). Now on one board it works, but not for the other. I suspect a board issue so listing the two types that we use: PandaBoard rev A2 (dmesg: OMAP4430 ES2.1): works PandaBoardES rev B1 (dmesg: OMAP4460 ES1.1): nope Any hints for me. >>> >>> Does your PandaboardES have the WLAN chip (U4) mounted? If yes, how do you >>> isolate >>> it from your external SDIO adapter? > > On my 4460 board in front of me U4 is not populated, but U3 is (the TiWi > thing). > >> >> OK, just realized that the expansion connector uses different pads for MMC2. >> However, you still >> need to make sure that the other pins (connected to on board WLAN chip) are >> not muxed as MMC2. > > I think Luciano added DT patches for on-board WLAN and it uses MMC5 if I am > not mistaken(?). Attached are the dmesg logs of the two boards. Right. WLAN is supposed to use MMC5. But if you don't have Luca's patches, can you please ensure that those pins are muxed either as safe mode or as MMC5? Default seems to be safe mode, but you should cross check. Also in your patches you have set mmc2-clk to PIN_INPUT_PULLUP Shouldn't it be PIN_OUTPUT? Still I have no clue why it works on 4430 and not on 4460. Are you using the same bootloader image on both boards? cheers, -roger -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: using mmc2 on panda [was: Regression 3.11-rc1: omap4panda: no usb and consequently no ethernet]
Hi, On Tue, 2013-10-01 at 12:53 +0200, Arend van Spriel wrote: > On 10/01/2013 11:53 AM, Roger Quadros wrote: > > On 10/01/2013 12:49 PM, Roger Quadros wrote: > >> Hi Arend, > >> > >> On 10/01/2013 11:05 AM, Arend van Spriel wrote: > >>> On 07/19/2013 12:57 PM, Arend van Spriel wrote: > On 07/19/2013 12:49 PM, Roger Quadros wrote: > > On 07/19/2013 01:36 PM, Arend van Spriel wrote: > >> On 07/18/2013 10:59 AM, Tony Lindgren wrote: > >>> Then for the SDIO with device tree, take a look at the following > >>> patches: > >>> > >>> [PATCH 0/3] WLAN support for omap4 when booted with devicetree > >>> http://comments.gmane.org/gmane.linux.ports.arm.omap/97522# > >> > >> I have been looking at the pandaboard patch in the series above and I > >> do have a question. Among other things the patch adds these dt entries. > >> > >> +0x108 0x118/* sdmmc5_clk.sdmmc5_clk INPUT_PULLUP | > >> MODE0 */ > >> +0x10a 0x118/* sdmmc5_cmd.sdmmc5_cmd INPUT_PULLUP | > >> MODE0 */ > >> > >> If I look at the similar names in the deceased board-omap4panda.c: > >> > >> board-omap4panda.c:OMAP4_MUX(SDMMC5_CMD, OMAP_MUX_MODE0 | > >> OMAP_PIN_INPUT_PULLUP), > >> board-omap4panda.c:OMAP4_MUX(SDMMC5_CLK, OMAP_MUX_MODE0 | > >> OMAP_PIN_INPUT_PULLUP), > >> > >> and in mux44xx.h: > >> > >> mux44xx.h:#define OMAP4_CTRL_MODULE_PAD_SDMMC5_CLK_OFFSET0x0148 > >> mux44xx.h:#define OMAP4_CTRL_MODULE_PAD_SDMMC5_CMD_OFFSET0x014a > >> > >> So how did 0x0148 get 0x0108 in DT and 0x014a get 0x010a. There is > >> probably an explanation to it and it would help my understanding to > >> know where this difference comes from. Hope you can help me out here. > >> > > > > If you see omap4.dtsi, omap4_pmx_core starts at register address > > 0x4a100040. > > > > So, you need to subtract 0x40 from the offsets defined in mux44xx.h > > for pmx_core registers. > > That was what I was looking for. Thanks! > >>> > >>> Hi Roger, > >>> > >>> It has been a while, but I would like to pickup this thread. We have a > >>> couple of pandaboards used as test setup. These have an SDIO adapter > >>> hooked up to expansion connector A using MMC2. I have attached the patch > >>> file (just ignore platform_data stuff). Now on one board it works, but > >>> not for the other. I suspect a board issue so listing the two types that > >>> we use: > >>> > >>> PandaBoard rev A2 (dmesg: OMAP4430 ES2.1): works > >>> PandaBoardES rev B1 (dmesg: OMAP4460 ES1.1): nope > >>> > >>> Any hints for me. > >> > >> Does your PandaboardES have the WLAN chip (U4) mounted? If yes, how do you > >> isolate > >> it from your external SDIO adapter? > > On my 4460 board in front of me U4 is not populated, but U3 is (the TiWi > thing). > > > > > OK, just realized that the expansion connector uses different pads for > > MMC2. However, you still > > need to make sure that the other pins (connected to on board WLAN chip) are > > not muxed as MMC2. > > I think Luciano added DT patches for on-board WLAN and it uses MMC5 if I > am not mistaken(?). Attached are the dmesg logs of the two boards. I sent 2 patch series to add DT support for the on-board WLAN, but they were not applied, since there were some comments that required changes. I really don't have the time to revisit them now that I'm not with TI anymore, so I'm hoping someone else will pick them up at some point. FWIW, my patches were working with PandaBoardES rev B1, which was also OMAP4460 ES1.1. It worked fine for me, *except* that sometimes for some unknown reason the SDIO MMC connected to WiLink didn't get probed (as it appears to be the case on your dmesg-4460.txt). Most weirdly, it seems that booting the board with a non-DT kernel and then booting back to the DT kernel seemed to help and the problem was gone for many reboots, until it happened again. I never figure out why this was happening, though. :( -- Cheers, Luca. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: using mmc2 on panda [was: Regression 3.11-rc1: omap4panda: no usb and consequently no ethernet]
On 10/01/2013 11:53 AM, Roger Quadros wrote: On 10/01/2013 12:49 PM, Roger Quadros wrote: Hi Arend, On 10/01/2013 11:05 AM, Arend van Spriel wrote: On 07/19/2013 12:57 PM, Arend van Spriel wrote: On 07/19/2013 12:49 PM, Roger Quadros wrote: On 07/19/2013 01:36 PM, Arend van Spriel wrote: On 07/18/2013 10:59 AM, Tony Lindgren wrote: Then for the SDIO with device tree, take a look at the following patches: [PATCH 0/3] WLAN support for omap4 when booted with devicetree http://comments.gmane.org/gmane.linux.ports.arm.omap/97522# I have been looking at the pandaboard patch in the series above and I do have a question. Among other things the patch adds these dt entries. +0x108 0x118/* sdmmc5_clk.sdmmc5_clk INPUT_PULLUP | MODE0 */ +0x10a 0x118/* sdmmc5_cmd.sdmmc5_cmd INPUT_PULLUP | MODE0 */ If I look at the similar names in the deceased board-omap4panda.c: board-omap4panda.c:OMAP4_MUX(SDMMC5_CMD, OMAP_MUX_MODE0 | OMAP_PIN_INPUT_PULLUP), board-omap4panda.c:OMAP4_MUX(SDMMC5_CLK, OMAP_MUX_MODE0 | OMAP_PIN_INPUT_PULLUP), and in mux44xx.h: mux44xx.h:#define OMAP4_CTRL_MODULE_PAD_SDMMC5_CLK_OFFSET0x0148 mux44xx.h:#define OMAP4_CTRL_MODULE_PAD_SDMMC5_CMD_OFFSET0x014a So how did 0x0148 get 0x0108 in DT and 0x014a get 0x010a. There is probably an explanation to it and it would help my understanding to know where this difference comes from. Hope you can help me out here. If you see omap4.dtsi, omap4_pmx_core starts at register address 0x4a100040. So, you need to subtract 0x40 from the offsets defined in mux44xx.h for pmx_core registers. That was what I was looking for. Thanks! Hi Roger, It has been a while, but I would like to pickup this thread. We have a couple of pandaboards used as test setup. These have an SDIO adapter hooked up to expansion connector A using MMC2. I have attached the patch file (just ignore platform_data stuff). Now on one board it works, but not for the other. I suspect a board issue so listing the two types that we use: PandaBoard rev A2 (dmesg: OMAP4430 ES2.1): works PandaBoardES rev B1 (dmesg: OMAP4460 ES1.1): nope Any hints for me. Does your PandaboardES have the WLAN chip (U4) mounted? If yes, how do you isolate it from your external SDIO adapter? On my 4460 board in front of me U4 is not populated, but U3 is (the TiWi thing). OK, just realized that the expansion connector uses different pads for MMC2. However, you still need to make sure that the other pins (connected to on board WLAN chip) are not muxed as MMC2. I think Luciano added DT patches for on-board WLAN and it uses MMC5 if I am not mistaken(?). Attached are the dmesg logs of the two boards. Regards, Arend [0.00] Booting Linux on physical CPU 0x0 [0.00] Linux version 3.11.0-wl-27553-g4a20162 (arend@arend-ubuntu-1) (gcc version 4.5.1 (Sourcery G++ Lite 2010.09-50) ) #5 SMP Mon Sep 23 10:42:07 CEST 2013 [0.00] CPU: ARMv7 Processor [411fc092] revision 2 (ARMv7), cr=10c53c7d [0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache [0.00] Machine: Generic OMAP4 (Flattened Device Tree), model: TI OMAP4 PandaBoard [0.00] cma: CMA: reserved 16 MiB at ae80 [0.00] Memory policy: ECC disabled, Data cache writealloc [0.00] On node 0 totalpages: 261888 [0.00] free_area_init_node: node 0, pgdat c08835c0, node_mem_map c0ded000 [0.00] Normal zone: 1520 pages used for memmap [0.00] Normal zone: 0 pages reserved [0.00] Normal zone: 194560 pages, LIFO batch:31 [0.00] HighMem zone: 528 pages used for memmap [0.00] HighMem zone: 67328 pages, LIFO batch:15 [0.00] OMAP4430 ES2.1 [0.00] PERCPU: Embedded 9 pages/cpu @c1607000 s14208 r8192 d14464 u36864 [0.00] pcpu-alloc: s14208 r8192 d14464 u36864 alloc=9*4096 [0.00] pcpu-alloc: [0] 0 [0] 1 [0.00] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 260368 [0.00] Kernel command line: root=/dev/mmcblk0p2 rootwait console=ttyO2,115200 [0.00] PID hash table entries: 4096 (order: 2, 16384 bytes) [0.00] Dentry cache hash table entries: 131072 (order: 7, 524288 bytes) [0.00] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) [0.00] Memory: 1007680K/1047552K available (5750K kernel code, 614K rwdata, 1952K rodata, 381K init, 5522K bss, 39872K reserved, 269312K highmem) [0.00] Virtual kernel memory layout: [0.00] vector : 0x - 0x1000 ( 4 kB) [0.00] fixmap : 0xfff0 - 0xfffe ( 896 kB) [0.00] vmalloc : 0xf000 - 0xff00 ( 240 MB) [0.00] lowmem : 0xc000 - 0xef80 ( 760 MB) [0.00] pkmap : 0xbfe0 - 0xc000 ( 2 MB) [0.00] modules : 0xbf00 - 0xbfe0 ( 14 MB) [0.00] .text : 0xc0008000 - 0xc078d9c8 (7703
Re: using mmc2 on panda [was: Regression 3.11-rc1: omap4panda: no usb and consequently no ethernet]
On 10/01/2013 12:49 PM, Roger Quadros wrote: > Hi Arend, > > On 10/01/2013 11:05 AM, Arend van Spriel wrote: >> On 07/19/2013 12:57 PM, Arend van Spriel wrote: >>> On 07/19/2013 12:49 PM, Roger Quadros wrote: On 07/19/2013 01:36 PM, Arend van Spriel wrote: > On 07/18/2013 10:59 AM, Tony Lindgren wrote: >> Then for the SDIO with device tree, take a look at the following >> patches: >> >> [PATCH 0/3] WLAN support for omap4 when booted with devicetree >> http://comments.gmane.org/gmane.linux.ports.arm.omap/97522# > > I have been looking at the pandaboard patch in the series above and I > do have a question. Among other things the patch adds these dt entries. > > +0x108 0x118/* sdmmc5_clk.sdmmc5_clk INPUT_PULLUP | > MODE0 */ > +0x10a 0x118/* sdmmc5_cmd.sdmmc5_cmd INPUT_PULLUP | > MODE0 */ > > If I look at the similar names in the deceased board-omap4panda.c: > > board-omap4panda.c:OMAP4_MUX(SDMMC5_CMD, OMAP_MUX_MODE0 | > OMAP_PIN_INPUT_PULLUP), > board-omap4panda.c:OMAP4_MUX(SDMMC5_CLK, OMAP_MUX_MODE0 | > OMAP_PIN_INPUT_PULLUP), > > and in mux44xx.h: > > mux44xx.h:#define OMAP4_CTRL_MODULE_PAD_SDMMC5_CLK_OFFSET0x0148 > mux44xx.h:#define OMAP4_CTRL_MODULE_PAD_SDMMC5_CMD_OFFSET0x014a > > So how did 0x0148 get 0x0108 in DT and 0x014a get 0x010a. There is > probably an explanation to it and it would help my understanding to > know where this difference comes from. Hope you can help me out here. > If you see omap4.dtsi, omap4_pmx_core starts at register address 0x4a100040. So, you need to subtract 0x40 from the offsets defined in mux44xx.h for pmx_core registers. >>> >>> That was what I was looking for. Thanks! >> >> Hi Roger, >> >> It has been a while, but I would like to pickup this thread. We have a >> couple of pandaboards used as test setup. These have an SDIO adapter hooked >> up to expansion connector A using MMC2. I have attached the patch file (just >> ignore platform_data stuff). Now on one board it works, but not for the >> other. I suspect a board issue so listing the two types that we use: >> >> PandaBoard rev A2 (dmesg: OMAP4430 ES2.1): works >> PandaBoardES rev B1 (dmesg: OMAP4460 ES1.1): nope >> >> Any hints for me. > > Does your PandaboardES have the WLAN chip (U4) mounted? If yes, how do you > isolate > it from your external SDIO adapter? OK, just realized that the expansion connector uses different pads for MMC2. However, you still need to make sure that the other pins (connected to on board WLAN chip) are not muxed as MMC2. > > Most likely your Pandaboard (A2) doesn't have the WLAN chip (U3) on board so > there is no problem there. > cheers, -roger -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: using mmc2 on panda [was: Regression 3.11-rc1: omap4panda: no usb and consequently no ethernet]
Hi Arend, On 10/01/2013 11:05 AM, Arend van Spriel wrote: > On 07/19/2013 12:57 PM, Arend van Spriel wrote: >> On 07/19/2013 12:49 PM, Roger Quadros wrote: >>> On 07/19/2013 01:36 PM, Arend van Spriel wrote: On 07/18/2013 10:59 AM, Tony Lindgren wrote: > Then for the SDIO with device tree, take a look at the following > patches: > > [PATCH 0/3] WLAN support for omap4 when booted with devicetree > http://comments.gmane.org/gmane.linux.ports.arm.omap/97522# I have been looking at the pandaboard patch in the series above and I do have a question. Among other things the patch adds these dt entries. +0x108 0x118/* sdmmc5_clk.sdmmc5_clk INPUT_PULLUP | MODE0 */ +0x10a 0x118/* sdmmc5_cmd.sdmmc5_cmd INPUT_PULLUP | MODE0 */ If I look at the similar names in the deceased board-omap4panda.c: board-omap4panda.c:OMAP4_MUX(SDMMC5_CMD, OMAP_MUX_MODE0 | OMAP_PIN_INPUT_PULLUP), board-omap4panda.c:OMAP4_MUX(SDMMC5_CLK, OMAP_MUX_MODE0 | OMAP_PIN_INPUT_PULLUP), and in mux44xx.h: mux44xx.h:#define OMAP4_CTRL_MODULE_PAD_SDMMC5_CLK_OFFSET0x0148 mux44xx.h:#define OMAP4_CTRL_MODULE_PAD_SDMMC5_CMD_OFFSET0x014a So how did 0x0148 get 0x0108 in DT and 0x014a get 0x010a. There is probably an explanation to it and it would help my understanding to know where this difference comes from. Hope you can help me out here. >>> >>> If you see omap4.dtsi, omap4_pmx_core starts at register address >>> 0x4a100040. >>> >>> So, you need to subtract 0x40 from the offsets defined in mux44xx.h >>> for pmx_core registers. >> >> That was what I was looking for. Thanks! > > Hi Roger, > > It has been a while, but I would like to pickup this thread. We have a couple > of pandaboards used as test setup. These have an SDIO adapter hooked up to > expansion connector A using MMC2. I have attached the patch file (just ignore > platform_data stuff). Now on one board it works, but not for the other. I > suspect a board issue so listing the two types that we use: > > PandaBoard rev A2 (dmesg: OMAP4430 ES2.1): works > PandaBoardES rev B1 (dmesg: OMAP4460 ES1.1): nope > > Any hints for me. Does your PandaboardES have the WLAN chip (U4) mounted? If yes, how do you isolate it from your external SDIO adapter? Most likely your Pandaboard (A2) doesn't have the WLAN chip (U3) on board so there is no problem there. cheers, -roger -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
using mmc2 on panda [was: Regression 3.11-rc1: omap4panda: no usb and consequently no ethernet]
On 07/19/2013 12:57 PM, Arend van Spriel wrote:
On 07/19/2013 12:49 PM, Roger Quadros wrote:
On 07/19/2013 01:36 PM, Arend van Spriel wrote:
On 07/18/2013 10:59 AM, Tony Lindgren wrote:
Then for the SDIO with device tree, take a look at the following
patches:
[PATCH 0/3] WLAN support for omap4 when booted with devicetree
http://comments.gmane.org/gmane.linux.ports.arm.omap/97522#
I have been looking at the pandaboard patch in the series above and I
do have a question. Among other things the patch adds these dt entries.
+0x108 0x118/* sdmmc5_clk.sdmmc5_clk INPUT_PULLUP |
MODE0 */
+0x10a 0x118/* sdmmc5_cmd.sdmmc5_cmd INPUT_PULLUP |
MODE0 */
If I look at the similar names in the deceased board-omap4panda.c:
board-omap4panda.c:OMAP4_MUX(SDMMC5_CMD, OMAP_MUX_MODE0 |
OMAP_PIN_INPUT_PULLUP),
board-omap4panda.c:OMAP4_MUX(SDMMC5_CLK, OMAP_MUX_MODE0 |
OMAP_PIN_INPUT_PULLUP),
and in mux44xx.h:
mux44xx.h:#define OMAP4_CTRL_MODULE_PAD_SDMMC5_CLK_OFFSET0x0148
mux44xx.h:#define OMAP4_CTRL_MODULE_PAD_SDMMC5_CMD_OFFSET0x014a
So how did 0x0148 get 0x0108 in DT and 0x014a get 0x010a. There is
probably an explanation to it and it would help my understanding to
know where this difference comes from. Hope you can help me out here.
If you see omap4.dtsi, omap4_pmx_core starts at register address
0x4a100040.
So, you need to subtract 0x40 from the offsets defined in mux44xx.h
for pmx_core registers.
That was what I was looking for. Thanks!
Hi Roger,
It has been a while, but I would like to pickup this thread. We have a
couple of pandaboards used as test setup. These have an SDIO adapter
hooked up to expansion connector A using MMC2. I have attached the patch
file (just ignore platform_data stuff). Now on one board it works, but
not for the other. I suspect a board issue so listing the two types that
we use:
PandaBoard rev A2 (dmesg: OMAP4430 ES2.1): works
PandaBoardES rev B1 (dmesg: OMAP4460 ES1.1): nope
Any hints for me.
Regards,
Arend
NOTE: omap4_pmx_wkup starts at a different address. Those are for
wakeup domain
control registers.
Will keep that in mind.
Regards,
Arend
>From 4a20162935b27e23ec7ddc818c9fe6b451c1a968 Mon Sep 17 00:00:00 2001
From: Arend van Spriel
Date: Thu, 22 Aug 2013 12:29:23 +0200
Subject: [PATCH] brcmfmac: add device tree support for panda board
In linux mainline the pandaboard specific code moved to using
the device tree. Changing our internal patches to get platform
specific info from the device tree.
Signed-off-by: Arend van Spriel
---
arch/arm/boot/dts/omap4-panda-common.dtsi | 20 +++-
arch/arm/mach-omap2/devices.c | 36 -
2 files changed, 54 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/omap4-panda-common.dtsi
b/arch/arm/boot/dts/omap4-panda-common.dtsi
index faa95b5..6ebeb8e 100644
--- a/arch/arm/boot/dts/omap4-panda-common.dtsi
+++ b/arch/arm/boot/dts/omap4-panda-common.dtsi
@@ -226,6 +226,22 @@
0xf0 (PIN_INPUT_PULLUP | MUX_MODE0) /* i2c4_sda */
>;
};
+ mmc2_brcmf_en: pinmux_mmc2_brcmf_en {
+ pinctrl-single,pins = <
+ 0x92 (PIN_OUTPUT | MUX_MODE3) /* brcmf-power
*/
+ >;
+ };
+ mmc2_pins: pinmux_mmc2_pins {
+ pinctrl-single,pins = <
+ 0x44 (MUX_MODE1 | PIN_INPUT_PULLUP) /* mmc2-cmd */
+ 0x42 (MUX_MODE1 | PIN_INPUT_PULLUP) /* mmc2-clk */
+ 0x00 (MUX_MODE1 | PIN_INPUT_PULLUP) /* mmc2-dat 0-3
*/
+ 0x02 (MUX_MODE1 | PIN_INPUT_PULLUP)
+ 0x04 (MUX_MODE1 | PIN_INPUT_PULLUP)
+ 0x06 (MUX_MODE1 | PIN_INPUT_PULLUP)
+ 0x9a (MUX_MODE3 | PIN_INPUT_PULLDOWN) /* oob-irq */
+ >;
+ };
};
_pmx_wkup {
@@ -302,7 +318,9 @@
};
{
- status = "disabled";
+ vmmc-supply = <>;
+ bus-width = <4>;
+ non-removable;
};
{
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index 3c1279f..7a47535 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -21,7 +21,7 @@
#include
#include
#include
-
+#include
#include
#include
@@ -547,6 +547,39 @@ static inline void omap_init_wl12xx_of(void)
}
#endif
+#define GPIO_BRCMF_SDIO_PWR134
+#define GPIO_BRCMF_SDIO_OOB138
+static struct brcmfmac_sdio_platform_data brcmfmac_sdio_pdata;
+
+static struct platform_device brcmf_sdio_device = {
+ .name = BRCMFMAC_SDIO_PDATA_NAME,
+ .id = PLATFORM_DEVID_NONE,
+ .dev.platform_data = _sdio_pdata
+};
+
+static struct gpio brcmf_sdio_gpios[] __initdata = {
+ { GPIO_BRCMF_SDIO_PWR, GPIOF_OUT_INIT_HIGH,"brcmf_sdio_pwr"},
+ { GPIO_BRCMF_SDIO_OOB, GPIOF_IN, "brcmf_sdio_oob"},
+};
+
+void
Re: using mmc2 on panda [was: Regression 3.11-rc1: omap4panda: no usb and consequently no ethernet]
Hi Arend, On 10/01/2013 11:05 AM, Arend van Spriel wrote: On 07/19/2013 12:57 PM, Arend van Spriel wrote: On 07/19/2013 12:49 PM, Roger Quadros wrote: On 07/19/2013 01:36 PM, Arend van Spriel wrote: On 07/18/2013 10:59 AM, Tony Lindgren wrote: Then for the SDIO with device tree, take a look at the following patches: [PATCH 0/3] WLAN support for omap4 when booted with devicetree http://comments.gmane.org/gmane.linux.ports.arm.omap/97522# I have been looking at the pandaboard patch in the series above and I do have a question. Among other things the patch adds these dt entries. +0x108 0x118/* sdmmc5_clk.sdmmc5_clk INPUT_PULLUP | MODE0 */ +0x10a 0x118/* sdmmc5_cmd.sdmmc5_cmd INPUT_PULLUP | MODE0 */ If I look at the similar names in the deceased board-omap4panda.c: board-omap4panda.c:OMAP4_MUX(SDMMC5_CMD, OMAP_MUX_MODE0 | OMAP_PIN_INPUT_PULLUP), board-omap4panda.c:OMAP4_MUX(SDMMC5_CLK, OMAP_MUX_MODE0 | OMAP_PIN_INPUT_PULLUP), and in mux44xx.h: mux44xx.h:#define OMAP4_CTRL_MODULE_PAD_SDMMC5_CLK_OFFSET0x0148 mux44xx.h:#define OMAP4_CTRL_MODULE_PAD_SDMMC5_CMD_OFFSET0x014a So how did 0x0148 get 0x0108 in DT and 0x014a get 0x010a. There is probably an explanation to it and it would help my understanding to know where this difference comes from. Hope you can help me out here. If you see omap4.dtsi, omap4_pmx_core starts at register address 0x4a100040. So, you need to subtract 0x40 from the offsets defined in mux44xx.h for pmx_core registers. That was what I was looking for. Thanks! Hi Roger, It has been a while, but I would like to pickup this thread. We have a couple of pandaboards used as test setup. These have an SDIO adapter hooked up to expansion connector A using MMC2. I have attached the patch file (just ignore platform_data stuff). Now on one board it works, but not for the other. I suspect a board issue so listing the two types that we use: PandaBoard rev A2 (dmesg: OMAP4430 ES2.1): works PandaBoardES rev B1 (dmesg: OMAP4460 ES1.1): nope Any hints for me. Does your PandaboardES have the WLAN chip (U4) mounted? If yes, how do you isolate it from your external SDIO adapter? Most likely your Pandaboard (A2) doesn't have the WLAN chip (U3) on board so there is no problem there. cheers, -roger -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: using mmc2 on panda [was: Regression 3.11-rc1: omap4panda: no usb and consequently no ethernet]
On 10/01/2013 12:49 PM, Roger Quadros wrote: Hi Arend, On 10/01/2013 11:05 AM, Arend van Spriel wrote: On 07/19/2013 12:57 PM, Arend van Spriel wrote: On 07/19/2013 12:49 PM, Roger Quadros wrote: On 07/19/2013 01:36 PM, Arend van Spriel wrote: On 07/18/2013 10:59 AM, Tony Lindgren wrote: Then for the SDIO with device tree, take a look at the following patches: [PATCH 0/3] WLAN support for omap4 when booted with devicetree http://comments.gmane.org/gmane.linux.ports.arm.omap/97522# I have been looking at the pandaboard patch in the series above and I do have a question. Among other things the patch adds these dt entries. +0x108 0x118/* sdmmc5_clk.sdmmc5_clk INPUT_PULLUP | MODE0 */ +0x10a 0x118/* sdmmc5_cmd.sdmmc5_cmd INPUT_PULLUP | MODE0 */ If I look at the similar names in the deceased board-omap4panda.c: board-omap4panda.c:OMAP4_MUX(SDMMC5_CMD, OMAP_MUX_MODE0 | OMAP_PIN_INPUT_PULLUP), board-omap4panda.c:OMAP4_MUX(SDMMC5_CLK, OMAP_MUX_MODE0 | OMAP_PIN_INPUT_PULLUP), and in mux44xx.h: mux44xx.h:#define OMAP4_CTRL_MODULE_PAD_SDMMC5_CLK_OFFSET0x0148 mux44xx.h:#define OMAP4_CTRL_MODULE_PAD_SDMMC5_CMD_OFFSET0x014a So how did 0x0148 get 0x0108 in DT and 0x014a get 0x010a. There is probably an explanation to it and it would help my understanding to know where this difference comes from. Hope you can help me out here. If you see omap4.dtsi, omap4_pmx_core starts at register address 0x4a100040. So, you need to subtract 0x40 from the offsets defined in mux44xx.h for pmx_core registers. That was what I was looking for. Thanks! Hi Roger, It has been a while, but I would like to pickup this thread. We have a couple of pandaboards used as test setup. These have an SDIO adapter hooked up to expansion connector A using MMC2. I have attached the patch file (just ignore platform_data stuff). Now on one board it works, but not for the other. I suspect a board issue so listing the two types that we use: PandaBoard rev A2 (dmesg: OMAP4430 ES2.1): works PandaBoardES rev B1 (dmesg: OMAP4460 ES1.1): nope Any hints for me. Does your PandaboardES have the WLAN chip (U4) mounted? If yes, how do you isolate it from your external SDIO adapter? OK, just realized that the expansion connector uses different pads for MMC2. However, you still need to make sure that the other pins (connected to on board WLAN chip) are not muxed as MMC2. Most likely your Pandaboard (A2) doesn't have the WLAN chip (U3) on board so there is no problem there. cheers, -roger -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: using mmc2 on panda [was: Regression 3.11-rc1: omap4panda: no usb and consequently no ethernet]
On 10/01/2013 11:53 AM, Roger Quadros wrote: On 10/01/2013 12:49 PM, Roger Quadros wrote: Hi Arend, On 10/01/2013 11:05 AM, Arend van Spriel wrote: On 07/19/2013 12:57 PM, Arend van Spriel wrote: On 07/19/2013 12:49 PM, Roger Quadros wrote: On 07/19/2013 01:36 PM, Arend van Spriel wrote: On 07/18/2013 10:59 AM, Tony Lindgren wrote: Then for the SDIO with device tree, take a look at the following patches: [PATCH 0/3] WLAN support for omap4 when booted with devicetree http://comments.gmane.org/gmane.linux.ports.arm.omap/97522# I have been looking at the pandaboard patch in the series above and I do have a question. Among other things the patch adds these dt entries. +0x108 0x118/* sdmmc5_clk.sdmmc5_clk INPUT_PULLUP | MODE0 */ +0x10a 0x118/* sdmmc5_cmd.sdmmc5_cmd INPUT_PULLUP | MODE0 */ If I look at the similar names in the deceased board-omap4panda.c: board-omap4panda.c:OMAP4_MUX(SDMMC5_CMD, OMAP_MUX_MODE0 | OMAP_PIN_INPUT_PULLUP), board-omap4panda.c:OMAP4_MUX(SDMMC5_CLK, OMAP_MUX_MODE0 | OMAP_PIN_INPUT_PULLUP), and in mux44xx.h: mux44xx.h:#define OMAP4_CTRL_MODULE_PAD_SDMMC5_CLK_OFFSET0x0148 mux44xx.h:#define OMAP4_CTRL_MODULE_PAD_SDMMC5_CMD_OFFSET0x014a So how did 0x0148 get 0x0108 in DT and 0x014a get 0x010a. There is probably an explanation to it and it would help my understanding to know where this difference comes from. Hope you can help me out here. If you see omap4.dtsi, omap4_pmx_core starts at register address 0x4a100040. So, you need to subtract 0x40 from the offsets defined in mux44xx.h for pmx_core registers. That was what I was looking for. Thanks! Hi Roger, It has been a while, but I would like to pickup this thread. We have a couple of pandaboards used as test setup. These have an SDIO adapter hooked up to expansion connector A using MMC2. I have attached the patch file (just ignore platform_data stuff). Now on one board it works, but not for the other. I suspect a board issue so listing the two types that we use: PandaBoard rev A2 (dmesg: OMAP4430 ES2.1): works PandaBoardES rev B1 (dmesg: OMAP4460 ES1.1): nope Any hints for me. Does your PandaboardES have the WLAN chip (U4) mounted? If yes, how do you isolate it from your external SDIO adapter? On my 4460 board in front of me U4 is not populated, but U3 is (the TiWi thing). OK, just realized that the expansion connector uses different pads for MMC2. However, you still need to make sure that the other pins (connected to on board WLAN chip) are not muxed as MMC2. I think Luciano added DT patches for on-board WLAN and it uses MMC5 if I am not mistaken(?). Attached are the dmesg logs of the two boards. Regards, Arend [0.00] Booting Linux on physical CPU 0x0 [0.00] Linux version 3.11.0-wl-27553-g4a20162 (arend@arend-ubuntu-1) (gcc version 4.5.1 (Sourcery G++ Lite 2010.09-50) ) #5 SMP Mon Sep 23 10:42:07 CEST 2013 [0.00] CPU: ARMv7 Processor [411fc092] revision 2 (ARMv7), cr=10c53c7d [0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache [0.00] Machine: Generic OMAP4 (Flattened Device Tree), model: TI OMAP4 PandaBoard [0.00] cma: CMA: reserved 16 MiB at ae80 [0.00] Memory policy: ECC disabled, Data cache writealloc [0.00] On node 0 totalpages: 261888 [0.00] free_area_init_node: node 0, pgdat c08835c0, node_mem_map c0ded000 [0.00] Normal zone: 1520 pages used for memmap [0.00] Normal zone: 0 pages reserved [0.00] Normal zone: 194560 pages, LIFO batch:31 [0.00] HighMem zone: 528 pages used for memmap [0.00] HighMem zone: 67328 pages, LIFO batch:15 [0.00] OMAP4430 ES2.1 [0.00] PERCPU: Embedded 9 pages/cpu @c1607000 s14208 r8192 d14464 u36864 [0.00] pcpu-alloc: s14208 r8192 d14464 u36864 alloc=9*4096 [0.00] pcpu-alloc: [0] 0 [0] 1 [0.00] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 260368 [0.00] Kernel command line: root=/dev/mmcblk0p2 rootwait console=ttyO2,115200 [0.00] PID hash table entries: 4096 (order: 2, 16384 bytes) [0.00] Dentry cache hash table entries: 131072 (order: 7, 524288 bytes) [0.00] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) [0.00] Memory: 1007680K/1047552K available (5750K kernel code, 614K rwdata, 1952K rodata, 381K init, 5522K bss, 39872K reserved, 269312K highmem) [0.00] Virtual kernel memory layout: [0.00] vector : 0x - 0x1000 ( 4 kB) [0.00] fixmap : 0xfff0 - 0xfffe ( 896 kB) [0.00] vmalloc : 0xf000 - 0xff00 ( 240 MB) [0.00] lowmem : 0xc000 - 0xef80 ( 760 MB) [0.00] pkmap : 0xbfe0 - 0xc000 ( 2 MB) [0.00] modules : 0xbf00 - 0xbfe0 ( 14 MB) [0.00] .text : 0xc0008000 - 0xc078d9c8 (7703
Re: using mmc2 on panda [was: Regression 3.11-rc1: omap4panda: no usb and consequently no ethernet]
Hi, On Tue, 2013-10-01 at 12:53 +0200, Arend van Spriel wrote: On 10/01/2013 11:53 AM, Roger Quadros wrote: On 10/01/2013 12:49 PM, Roger Quadros wrote: Hi Arend, On 10/01/2013 11:05 AM, Arend van Spriel wrote: On 07/19/2013 12:57 PM, Arend van Spriel wrote: On 07/19/2013 12:49 PM, Roger Quadros wrote: On 07/19/2013 01:36 PM, Arend van Spriel wrote: On 07/18/2013 10:59 AM, Tony Lindgren wrote: Then for the SDIO with device tree, take a look at the following patches: [PATCH 0/3] WLAN support for omap4 when booted with devicetree http://comments.gmane.org/gmane.linux.ports.arm.omap/97522# I have been looking at the pandaboard patch in the series above and I do have a question. Among other things the patch adds these dt entries. +0x108 0x118/* sdmmc5_clk.sdmmc5_clk INPUT_PULLUP | MODE0 */ +0x10a 0x118/* sdmmc5_cmd.sdmmc5_cmd INPUT_PULLUP | MODE0 */ If I look at the similar names in the deceased board-omap4panda.c: board-omap4panda.c:OMAP4_MUX(SDMMC5_CMD, OMAP_MUX_MODE0 | OMAP_PIN_INPUT_PULLUP), board-omap4panda.c:OMAP4_MUX(SDMMC5_CLK, OMAP_MUX_MODE0 | OMAP_PIN_INPUT_PULLUP), and in mux44xx.h: mux44xx.h:#define OMAP4_CTRL_MODULE_PAD_SDMMC5_CLK_OFFSET0x0148 mux44xx.h:#define OMAP4_CTRL_MODULE_PAD_SDMMC5_CMD_OFFSET0x014a So how did 0x0148 get 0x0108 in DT and 0x014a get 0x010a. There is probably an explanation to it and it would help my understanding to know where this difference comes from. Hope you can help me out here. If you see omap4.dtsi, omap4_pmx_core starts at register address 0x4a100040. So, you need to subtract 0x40 from the offsets defined in mux44xx.h for pmx_core registers. That was what I was looking for. Thanks! Hi Roger, It has been a while, but I would like to pickup this thread. We have a couple of pandaboards used as test setup. These have an SDIO adapter hooked up to expansion connector A using MMC2. I have attached the patch file (just ignore platform_data stuff). Now on one board it works, but not for the other. I suspect a board issue so listing the two types that we use: PandaBoard rev A2 (dmesg: OMAP4430 ES2.1): works PandaBoardES rev B1 (dmesg: OMAP4460 ES1.1): nope Any hints for me. Does your PandaboardES have the WLAN chip (U4) mounted? If yes, how do you isolate it from your external SDIO adapter? On my 4460 board in front of me U4 is not populated, but U3 is (the TiWi thing). OK, just realized that the expansion connector uses different pads for MMC2. However, you still need to make sure that the other pins (connected to on board WLAN chip) are not muxed as MMC2. I think Luciano added DT patches for on-board WLAN and it uses MMC5 if I am not mistaken(?). Attached are the dmesg logs of the two boards. I sent 2 patch series to add DT support for the on-board WLAN, but they were not applied, since there were some comments that required changes. I really don't have the time to revisit them now that I'm not with TI anymore, so I'm hoping someone else will pick them up at some point. FWIW, my patches were working with PandaBoardES rev B1, which was also OMAP4460 ES1.1. It worked fine for me, *except* that sometimes for some unknown reason the SDIO MMC connected to WiLink didn't get probed (as it appears to be the case on your dmesg-4460.txt). Most weirdly, it seems that booting the board with a non-DT kernel and then booting back to the DT kernel seemed to help and the problem was gone for many reboots, until it happened again. I never figure out why this was happening, though. :( -- Cheers, Luca. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: using mmc2 on panda [was: Regression 3.11-rc1: omap4panda: no usb and consequently no ethernet]
On 10/01/2013 01:53 PM, Arend van Spriel wrote: On 10/01/2013 11:53 AM, Roger Quadros wrote: On 10/01/2013 12:49 PM, Roger Quadros wrote: Hi Arend, On 10/01/2013 11:05 AM, Arend van Spriel wrote: On 07/19/2013 12:57 PM, Arend van Spriel wrote: On 07/19/2013 12:49 PM, Roger Quadros wrote: On 07/19/2013 01:36 PM, Arend van Spriel wrote: On 07/18/2013 10:59 AM, Tony Lindgren wrote: Then for the SDIO with device tree, take a look at the following patches: [PATCH 0/3] WLAN support for omap4 when booted with devicetree http://comments.gmane.org/gmane.linux.ports.arm.omap/97522# I have been looking at the pandaboard patch in the series above and I do have a question. Among other things the patch adds these dt entries. +0x108 0x118/* sdmmc5_clk.sdmmc5_clk INPUT_PULLUP | MODE0 */ +0x10a 0x118/* sdmmc5_cmd.sdmmc5_cmd INPUT_PULLUP | MODE0 */ If I look at the similar names in the deceased board-omap4panda.c: board-omap4panda.c:OMAP4_MUX(SDMMC5_CMD, OMAP_MUX_MODE0 | OMAP_PIN_INPUT_PULLUP), board-omap4panda.c:OMAP4_MUX(SDMMC5_CLK, OMAP_MUX_MODE0 | OMAP_PIN_INPUT_PULLUP), and in mux44xx.h: mux44xx.h:#define OMAP4_CTRL_MODULE_PAD_SDMMC5_CLK_OFFSET0x0148 mux44xx.h:#define OMAP4_CTRL_MODULE_PAD_SDMMC5_CMD_OFFSET0x014a So how did 0x0148 get 0x0108 in DT and 0x014a get 0x010a. There is probably an explanation to it and it would help my understanding to know where this difference comes from. Hope you can help me out here. If you see omap4.dtsi, omap4_pmx_core starts at register address 0x4a100040. So, you need to subtract 0x40 from the offsets defined in mux44xx.h for pmx_core registers. That was what I was looking for. Thanks! Hi Roger, It has been a while, but I would like to pickup this thread. We have a couple of pandaboards used as test setup. These have an SDIO adapter hooked up to expansion connector A using MMC2. I have attached the patch file (just ignore platform_data stuff). Now on one board it works, but not for the other. I suspect a board issue so listing the two types that we use: PandaBoard rev A2 (dmesg: OMAP4430 ES2.1): works PandaBoardES rev B1 (dmesg: OMAP4460 ES1.1): nope Any hints for me. Does your PandaboardES have the WLAN chip (U4) mounted? If yes, how do you isolate it from your external SDIO adapter? On my 4460 board in front of me U4 is not populated, but U3 is (the TiWi thing). OK, just realized that the expansion connector uses different pads for MMC2. However, you still need to make sure that the other pins (connected to on board WLAN chip) are not muxed as MMC2. I think Luciano added DT patches for on-board WLAN and it uses MMC5 if I am not mistaken(?). Attached are the dmesg logs of the two boards. Right. WLAN is supposed to use MMC5. But if you don't have Luca's patches, can you please ensure that those pins are muxed either as safe mode or as MMC5? Default seems to be safe mode, but you should cross check. Also in your patches you have set mmc2-clk to PIN_INPUT_PULLUP Shouldn't it be PIN_OUTPUT? Still I have no clue why it works on 4430 and not on 4460. Are you using the same bootloader image on both boards? cheers, -roger -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: using mmc2 on panda [was: Regression 3.11-rc1: omap4panda: no usb and consequently no ethernet]
Hi Roger, It has been a while, but I would like to pickup this thread. We have a couple of pandaboards used as test setup. These have an SDIO adapter hooked up to expansion connector A using MMC2. I have attached the patch file (just ignore platform_data stuff). Now on one board it works, but not for the other. I suspect a board issue so listing the two types that we use: PandaBoard rev A2 (dmesg: OMAP4430 ES2.1): works PandaBoardES rev B1 (dmesg: OMAP4460 ES1.1): nope Any hints for me. Does your PandaboardES have the WLAN chip (U4) mounted? If yes, how do you isolate it from your external SDIO adapter? On my 4460 board in front of me U4 is not populated, but U3 is (the TiWi thing). OK, just realized that the expansion connector uses different pads for MMC2. However, you still need to make sure that the other pins (connected to on board WLAN chip) are not muxed as MMC2. I think Luciano added DT patches for on-board WLAN and it uses MMC5 if I am not mistaken(?). Attached are the dmesg logs of the two boards. Right. WLAN is supposed to use MMC5. But if you don't have Luca's patches, can you please ensure that those pins are muxed either as safe mode or as MMC5? Default seems to be safe mode, but you should cross check. Also in your patches you have set mmc2-clk to PIN_INPUT_PULLUP Shouldn't it be PIN_OUTPUT? Still I have no clue why it works on 4430 and not on 4460. Are you using the same bootloader image on both boards? if you are using vaux1, can you check the voltage levels, From dmesg you attached, vaux1 is set to 1.8V on omap4430 and to 2.8V on OMAP4460 4430 [2.425750] VAUX1_6030: 1000 -- 3000 mV at 1800 mV 4460 [2.244262] VAUX1_6030: 1000 -- 3000 mV at 2800 mV Can you also check with MMC_DEBUG enabled for any clues. cheers, -roger -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
using mmc2 on panda [was: Regression 3.11-rc1: omap4panda: no usb and consequently no ethernet]
On 07/19/2013 12:57 PM, Arend van Spriel wrote:
On 07/19/2013 12:49 PM, Roger Quadros wrote:
On 07/19/2013 01:36 PM, Arend van Spriel wrote:
On 07/18/2013 10:59 AM, Tony Lindgren wrote:
Then for the SDIO with device tree, take a look at the following
patches:
[PATCH 0/3] WLAN support for omap4 when booted with devicetree
http://comments.gmane.org/gmane.linux.ports.arm.omap/97522#
I have been looking at the pandaboard patch in the series above and I
do have a question. Among other things the patch adds these dt entries.
+0x108 0x118/* sdmmc5_clk.sdmmc5_clk INPUT_PULLUP |
MODE0 */
+0x10a 0x118/* sdmmc5_cmd.sdmmc5_cmd INPUT_PULLUP |
MODE0 */
If I look at the similar names in the deceased board-omap4panda.c:
board-omap4panda.c:OMAP4_MUX(SDMMC5_CMD, OMAP_MUX_MODE0 |
OMAP_PIN_INPUT_PULLUP),
board-omap4panda.c:OMAP4_MUX(SDMMC5_CLK, OMAP_MUX_MODE0 |
OMAP_PIN_INPUT_PULLUP),
and in mux44xx.h:
mux44xx.h:#define OMAP4_CTRL_MODULE_PAD_SDMMC5_CLK_OFFSET0x0148
mux44xx.h:#define OMAP4_CTRL_MODULE_PAD_SDMMC5_CMD_OFFSET0x014a
So how did 0x0148 get 0x0108 in DT and 0x014a get 0x010a. There is
probably an explanation to it and it would help my understanding to
know where this difference comes from. Hope you can help me out here.
If you see omap4.dtsi, omap4_pmx_core starts at register address
0x4a100040.
So, you need to subtract 0x40 from the offsets defined in mux44xx.h
for pmx_core registers.
That was what I was looking for. Thanks!
Hi Roger,
It has been a while, but I would like to pickup this thread. We have a
couple of pandaboards used as test setup. These have an SDIO adapter
hooked up to expansion connector A using MMC2. I have attached the patch
file (just ignore platform_data stuff). Now on one board it works, but
not for the other. I suspect a board issue so listing the two types that
we use:
PandaBoard rev A2 (dmesg: OMAP4430 ES2.1): works
PandaBoardES rev B1 (dmesg: OMAP4460 ES1.1): nope
Any hints for me.
Regards,
Arend
NOTE: omap4_pmx_wkup starts at a different address. Those are for
wakeup domain
control registers.
Will keep that in mind.
Regards,
Arend
From 4a20162935b27e23ec7ddc818c9fe6b451c1a968 Mon Sep 17 00:00:00 2001
From: Arend van Spriel ar...@broadcom.com
Date: Thu, 22 Aug 2013 12:29:23 +0200
Subject: [PATCH] brcmfmac: add device tree support for panda board
In linux mainline the pandaboard specific code moved to using
the device tree. Changing our internal patches to get platform
specific info from the device tree.
Signed-off-by: Arend van Spriel ar...@broadcom.com
---
arch/arm/boot/dts/omap4-panda-common.dtsi | 20 +++-
arch/arm/mach-omap2/devices.c | 36 -
2 files changed, 54 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/omap4-panda-common.dtsi
b/arch/arm/boot/dts/omap4-panda-common.dtsi
index faa95b5..6ebeb8e 100644
--- a/arch/arm/boot/dts/omap4-panda-common.dtsi
+++ b/arch/arm/boot/dts/omap4-panda-common.dtsi
@@ -226,6 +226,22 @@
0xf0 (PIN_INPUT_PULLUP | MUX_MODE0) /* i2c4_sda */
;
};
+ mmc2_brcmf_en: pinmux_mmc2_brcmf_en {
+ pinctrl-single,pins =
+ 0x92 (PIN_OUTPUT | MUX_MODE3) /* brcmf-power
*/
+ ;
+ };
+ mmc2_pins: pinmux_mmc2_pins {
+ pinctrl-single,pins =
+ 0x44 (MUX_MODE1 | PIN_INPUT_PULLUP) /* mmc2-cmd */
+ 0x42 (MUX_MODE1 | PIN_INPUT_PULLUP) /* mmc2-clk */
+ 0x00 (MUX_MODE1 | PIN_INPUT_PULLUP) /* mmc2-dat 0-3
*/
+ 0x02 (MUX_MODE1 | PIN_INPUT_PULLUP)
+ 0x04 (MUX_MODE1 | PIN_INPUT_PULLUP)
+ 0x06 (MUX_MODE1 | PIN_INPUT_PULLUP)
+ 0x9a (MUX_MODE3 | PIN_INPUT_PULLDOWN) /* oob-irq */
+ ;
+ };
};
omap4_pmx_wkup {
@@ -302,7 +318,9 @@
};
mmc2 {
- status = disabled;
+ vmmc-supply = vaux1;
+ bus-width = 4;
+ non-removable;
};
mmc3 {
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index 3c1279f..7a47535 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -21,7 +21,7 @@
#include linux/platform_data/omap4-keypad.h
#include linux/wl12xx.h
#include linux/platform_data/mailbox-omap.h
-
+#include linux/platform_data/brcmfmac-sdio.h
#include asm/mach-types.h
#include asm/mach/map.h
@@ -547,6 +547,39 @@ static inline void omap_init_wl12xx_of(void)
}
#endif
+#define GPIO_BRCMF_SDIO_PWR134
+#define GPIO_BRCMF_SDIO_OOB138
+static struct brcmfmac_sdio_platform_data brcmfmac_sdio_pdata;
+
+static struct platform_device brcmf_sdio_device = {
+ .name = BRCMFMAC_SDIO_PDATA_NAME,
+ .id = PLATFORM_DEVID_NONE,
+ .dev.platform_data = brcmfmac_sdio_pdata
+};
+
+static struct
Re: Regression 3.11-rc1: omap4panda: no usb and consequently no ethernet
On 07/26/2013 12:37 PM, Roger Quadros wrote: On 07/26/2013 01:23 PM, Arend van Spriel wrote: On 07/26/2013 12:15 PM, Arend van Spriel wrote: On 07/26/2013 12:13 PM, Arend van Spriel wrote: On 07/26/2013 05:00 AM, Joel Fernandes wrote: On 07/25/2013 09:49 PM, Joel Fernandes wrote: [..] Can I get back on this topic. When USB and ethernet was working for me as stated above, I was not doing tftpboot. When I use tftpboot the images are obtained from the tftp server, but after kernel has started there is nothing in /sys/bus/usb/devices/. I quickly tried 3.11-rc2 + Roger's USB PHY clock patch on omap4-panda-es and enabled following USB options: CONFIG_USB_MUSB_HDRC=y CONFIG_USB_PHY=y CONFIG_OMAP_USB2=y CONFIG_OMAP_CONTROL_USB=y CONFIG_USB_MUSB_OMAP2PLUS=y CONFIG_MFD_OMAP_USB_HOST=y CONFIG_USB_EHCI_HCD=y Aaargh. Missing this one. Will retry. Yes. That is working although it seems I don't need the MUSB stuff. MUSB is required for the micro OTG port and not USB host ports. Roger that (apologies for my corny sense of humor). cheers, -roger -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Regression 3.11-rc1: omap4panda: no usb and consequently no ethernet
On 07/26/2013 01:23 PM, Arend van Spriel wrote: > On 07/26/2013 12:15 PM, Arend van Spriel wrote: >> On 07/26/2013 12:13 PM, Arend van Spriel wrote: >>> On 07/26/2013 05:00 AM, Joel Fernandes wrote: On 07/25/2013 09:49 PM, Joel Fernandes wrote: [..] >> Can I get back on this topic. When USB and ethernet was working for me >> as stated above, I was not doing tftpboot. When I use tftpboot the >> images are obtained from the tftp server, but after kernel has started >> there is nothing in /sys/bus/usb/devices/. > > I quickly tried 3.11-rc2 + Roger's USB PHY clock patch on > omap4-panda-es > and enabled following USB options: > > CONFIG_USB_MUSB_HDRC=y > CONFIG_USB_PHY=y > CONFIG_OMAP_USB2=y > CONFIG_OMAP_CONTROL_USB=y > CONFIG_USB_MUSB_OMAP2PLUS=y > CONFIG_MFD_OMAP_USB_HOST=y > CONFIG_USB_EHCI_HCD=y >> >> Aaargh. Missing this one. Will retry. > > Yes. That is working although it seems I don't need the MUSB stuff. MUSB is required for the micro OTG port and not USB host ports. cheers, -roger -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Regression 3.11-rc1: omap4panda: no usb and consequently no ethernet
On 07/26/2013 12:15 PM, Arend van Spriel wrote: On 07/26/2013 12:13 PM, Arend van Spriel wrote: On 07/26/2013 05:00 AM, Joel Fernandes wrote: On 07/25/2013 09:49 PM, Joel Fernandes wrote: [..] Can I get back on this topic. When USB and ethernet was working for me as stated above, I was not doing tftpboot. When I use tftpboot the images are obtained from the tftp server, but after kernel has started there is nothing in /sys/bus/usb/devices/. I quickly tried 3.11-rc2 + Roger's USB PHY clock patch on omap4-panda-es and enabled following USB options: CONFIG_USB_MUSB_HDRC=y CONFIG_USB_PHY=y CONFIG_OMAP_USB2=y CONFIG_OMAP_CONTROL_USB=y CONFIG_USB_MUSB_OMAP2PLUS=y CONFIG_MFD_OMAP_USB_HOST=y CONFIG_USB_EHCI_HCD=y Aaargh. Missing this one. Will retry. Yes. That is working although it seems I don't need the MUSB stuff. Regards, Arend CONFIG_USB_OHCI_HCD=y CONFIG_USB_EHCI_HCD_OMAP=y Sorry I missed saying I also set had to set CONFIG_NOP_USB_XCEIV=y Here are the results of the dutch jury ;-) [2.537109] HS USB OTG: no transceiver configured [2.542541] musb-hdrc musb-hdrc.0.auto: musb_init_controller failed with status -517 [2.542541] platform musb-hdrc.0.auto: Driver musb-hdrc requests probe deferral I am surely missing something here. Either in device tree or .config. Regards, Arend -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Regression 3.11-rc1: omap4panda: no usb and consequently no ethernet
On 07/26/2013 12:13 PM, Arend van Spriel wrote: On 07/26/2013 05:00 AM, Joel Fernandes wrote: On 07/25/2013 09:49 PM, Joel Fernandes wrote: [..] Can I get back on this topic. When USB and ethernet was working for me as stated above, I was not doing tftpboot. When I use tftpboot the images are obtained from the tftp server, but after kernel has started there is nothing in /sys/bus/usb/devices/. I quickly tried 3.11-rc2 + Roger's USB PHY clock patch on omap4-panda-es and enabled following USB options: CONFIG_USB_MUSB_HDRC=y CONFIG_USB_PHY=y CONFIG_OMAP_USB2=y CONFIG_OMAP_CONTROL_USB=y CONFIG_USB_MUSB_OMAP2PLUS=y CONFIG_MFD_OMAP_USB_HOST=y CONFIG_USB_EHCI_HCD=y Aaargh. Missing this one. Will retry. CONFIG_USB_OHCI_HCD=y CONFIG_USB_EHCI_HCD_OMAP=y Sorry I missed saying I also set had to set CONFIG_NOP_USB_XCEIV=y Here are the results of the dutch jury ;-) [2.537109] HS USB OTG: no transceiver configured [2.542541] musb-hdrc musb-hdrc.0.auto: musb_init_controller failed with status -517 [2.542541] platform musb-hdrc.0.auto: Driver musb-hdrc requests probe deferral I am surely missing something here. Either in device tree or .config. Regards, Arend -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Regression 3.11-rc1: omap4panda: no usb and consequently no ethernet
On 07/26/2013 05:00 AM, Joel Fernandes wrote: On 07/25/2013 09:49 PM, Joel Fernandes wrote: [..] Can I get back on this topic. When USB and ethernet was working for me as stated above, I was not doing tftpboot. When I use tftpboot the images are obtained from the tftp server, but after kernel has started there is nothing in /sys/bus/usb/devices/. I quickly tried 3.11-rc2 + Roger's USB PHY clock patch on omap4-panda-es and enabled following USB options: CONFIG_USB_MUSB_HDRC=y CONFIG_USB_PHY=y CONFIG_OMAP_USB2=y CONFIG_OMAP_CONTROL_USB=y CONFIG_USB_MUSB_OMAP2PLUS=y CONFIG_MFD_OMAP_USB_HOST=y CONFIG_USB_EHCI_HCD=y CONFIG_USB_OHCI_HCD=y CONFIG_USB_EHCI_HCD_OMAP=y Sorry I missed saying I also set had to set CONFIG_NOP_USB_XCEIV=y I will compare this with my .config. At first glance it looks like I am missing some of these. Gr. AvS -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Regression 3.11-rc1: omap4panda: no usb and consequently no ethernet
On 07/26/2013 05:00 AM, Joel Fernandes wrote: On 07/25/2013 09:49 PM, Joel Fernandes wrote: [..] Can I get back on this topic. When USB and ethernet was working for me as stated above, I was not doing tftpboot. When I use tftpboot the images are obtained from the tftp server, but after kernel has started there is nothing in /sys/bus/usb/devices/. I quickly tried 3.11-rc2 + Roger's USB PHY clock patch on omap4-panda-es and enabled following USB options: CONFIG_USB_MUSB_HDRC=y CONFIG_USB_PHY=y CONFIG_OMAP_USB2=y CONFIG_OMAP_CONTROL_USB=y CONFIG_USB_MUSB_OMAP2PLUS=y CONFIG_MFD_OMAP_USB_HOST=y CONFIG_USB_EHCI_HCD=y CONFIG_USB_OHCI_HCD=y CONFIG_USB_EHCI_HCD_OMAP=y Sorry I missed saying I also set had to set CONFIG_NOP_USB_XCEIV=y I will compare this with my .config. At first glance it looks like I am missing some of these. Gr. AvS -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Regression 3.11-rc1: omap4panda: no usb and consequently no ethernet
On 07/26/2013 12:13 PM, Arend van Spriel wrote: On 07/26/2013 05:00 AM, Joel Fernandes wrote: On 07/25/2013 09:49 PM, Joel Fernandes wrote: [..] Can I get back on this topic. When USB and ethernet was working for me as stated above, I was not doing tftpboot. When I use tftpboot the images are obtained from the tftp server, but after kernel has started there is nothing in /sys/bus/usb/devices/. I quickly tried 3.11-rc2 + Roger's USB PHY clock patch on omap4-panda-es and enabled following USB options: CONFIG_USB_MUSB_HDRC=y CONFIG_USB_PHY=y CONFIG_OMAP_USB2=y CONFIG_OMAP_CONTROL_USB=y CONFIG_USB_MUSB_OMAP2PLUS=y CONFIG_MFD_OMAP_USB_HOST=y CONFIG_USB_EHCI_HCD=y Aaargh. Missing this one. Will retry. CONFIG_USB_OHCI_HCD=y CONFIG_USB_EHCI_HCD_OMAP=y Sorry I missed saying I also set had to set CONFIG_NOP_USB_XCEIV=y Here are the results of the dutch jury ;-) [2.537109] HS USB OTG: no transceiver configured [2.542541] musb-hdrc musb-hdrc.0.auto: musb_init_controller failed with status -517 [2.542541] platform musb-hdrc.0.auto: Driver musb-hdrc requests probe deferral I am surely missing something here. Either in device tree or .config. Regards, Arend -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Regression 3.11-rc1: omap4panda: no usb and consequently no ethernet
On 07/26/2013 12:15 PM, Arend van Spriel wrote: On 07/26/2013 12:13 PM, Arend van Spriel wrote: On 07/26/2013 05:00 AM, Joel Fernandes wrote: On 07/25/2013 09:49 PM, Joel Fernandes wrote: [..] Can I get back on this topic. When USB and ethernet was working for me as stated above, I was not doing tftpboot. When I use tftpboot the images are obtained from the tftp server, but after kernel has started there is nothing in /sys/bus/usb/devices/. I quickly tried 3.11-rc2 + Roger's USB PHY clock patch on omap4-panda-es and enabled following USB options: CONFIG_USB_MUSB_HDRC=y CONFIG_USB_PHY=y CONFIG_OMAP_USB2=y CONFIG_OMAP_CONTROL_USB=y CONFIG_USB_MUSB_OMAP2PLUS=y CONFIG_MFD_OMAP_USB_HOST=y CONFIG_USB_EHCI_HCD=y Aaargh. Missing this one. Will retry. Yes. That is working although it seems I don't need the MUSB stuff. Regards, Arend CONFIG_USB_OHCI_HCD=y CONFIG_USB_EHCI_HCD_OMAP=y Sorry I missed saying I also set had to set CONFIG_NOP_USB_XCEIV=y Here are the results of the dutch jury ;-) [2.537109] HS USB OTG: no transceiver configured [2.542541] musb-hdrc musb-hdrc.0.auto: musb_init_controller failed with status -517 [2.542541] platform musb-hdrc.0.auto: Driver musb-hdrc requests probe deferral I am surely missing something here. Either in device tree or .config. Regards, Arend -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Regression 3.11-rc1: omap4panda: no usb and consequently no ethernet
On 07/26/2013 01:23 PM, Arend van Spriel wrote: On 07/26/2013 12:15 PM, Arend van Spriel wrote: On 07/26/2013 12:13 PM, Arend van Spriel wrote: On 07/26/2013 05:00 AM, Joel Fernandes wrote: On 07/25/2013 09:49 PM, Joel Fernandes wrote: [..] Can I get back on this topic. When USB and ethernet was working for me as stated above, I was not doing tftpboot. When I use tftpboot the images are obtained from the tftp server, but after kernel has started there is nothing in /sys/bus/usb/devices/. I quickly tried 3.11-rc2 + Roger's USB PHY clock patch on omap4-panda-es and enabled following USB options: CONFIG_USB_MUSB_HDRC=y CONFIG_USB_PHY=y CONFIG_OMAP_USB2=y CONFIG_OMAP_CONTROL_USB=y CONFIG_USB_MUSB_OMAP2PLUS=y CONFIG_MFD_OMAP_USB_HOST=y CONFIG_USB_EHCI_HCD=y Aaargh. Missing this one. Will retry. Yes. That is working although it seems I don't need the MUSB stuff. MUSB is required for the micro OTG port and not USB host ports. cheers, -roger -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Regression 3.11-rc1: omap4panda: no usb and consequently no ethernet
On 07/26/2013 12:37 PM, Roger Quadros wrote: On 07/26/2013 01:23 PM, Arend van Spriel wrote: On 07/26/2013 12:15 PM, Arend van Spriel wrote: On 07/26/2013 12:13 PM, Arend van Spriel wrote: On 07/26/2013 05:00 AM, Joel Fernandes wrote: On 07/25/2013 09:49 PM, Joel Fernandes wrote: [..] Can I get back on this topic. When USB and ethernet was working for me as stated above, I was not doing tftpboot. When I use tftpboot the images are obtained from the tftp server, but after kernel has started there is nothing in /sys/bus/usb/devices/. I quickly tried 3.11-rc2 + Roger's USB PHY clock patch on omap4-panda-es and enabled following USB options: CONFIG_USB_MUSB_HDRC=y CONFIG_USB_PHY=y CONFIG_OMAP_USB2=y CONFIG_OMAP_CONTROL_USB=y CONFIG_USB_MUSB_OMAP2PLUS=y CONFIG_MFD_OMAP_USB_HOST=y CONFIG_USB_EHCI_HCD=y Aaargh. Missing this one. Will retry. Yes. That is working although it seems I don't need the MUSB stuff. MUSB is required for the micro OTG port and not USB host ports. Roger that (apologies for my corny sense of humor). cheers, -roger -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Regression 3.11-rc1: omap4panda: no usb and consequently no ethernet
On 07/25/2013 09:49 PM, Joel Fernandes wrote: [..] >> Can I get back on this topic. When USB and ethernet was working for me >> as stated above, I was not doing tftpboot. When I use tftpboot the >> images are obtained from the tftp server, but after kernel has started >> there is nothing in /sys/bus/usb/devices/. > > I quickly tried 3.11-rc2 + Roger's USB PHY clock patch on omap4-panda-es > and enabled following USB options: > > CONFIG_USB_MUSB_HDRC=y > CONFIG_USB_PHY=y > CONFIG_OMAP_USB2=y > CONFIG_OMAP_CONTROL_USB=y > CONFIG_USB_MUSB_OMAP2PLUS=y > CONFIG_MFD_OMAP_USB_HOST=y > CONFIG_USB_EHCI_HCD=y > CONFIG_USB_OHCI_HCD=y > CONFIG_USB_EHCI_HCD_OMAP=y Sorry I missed saying I also set had to set CONFIG_NOP_USB_XCEIV=y Thanks, -Joel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Regression 3.11-rc1: omap4panda: no usb and consequently no ethernet
Hi Arend, On 07/25/2013 08:06 AM, Arend van Spriel wrote: > On 07/18/2013 02:42 PM, Roger Quadros wrote: >> On 07/18/2013 03:38 PM, Arend van Spriel wrote: >>> On 07/18/2013 01:30 PM, Roger Quadros wrote: On 07/18/2013 02:24 PM, Arend van Spriel wrote: > On 07/18/2013 01:18 PM, Roger Quadros wrote: >> Hi Arend, >> >> On 07/18/2013 11:41 AM, Arend van Spriel wrote: >>> Hi Tony, >>> >>> >>> We are using the panda board (es variant) for testing our SDIO >>> based chips. For this we have an adapter card connection to >>> expansion connector A. As this adapter is not publicly available >>> we had internally patched board-omap4panda.c. Also we follow the >>> -rc releases and use TFTP to boot the kernel image which requires >>> USB. >>> >>> Moving to 3.11-rc1 I found that the mentioned board file was >>> removed by your commit: >>> >>> commit b42b918194c4791510ac049e3d507169a7de8544 >>> Author: Tony Lindgren >>> Date: Thu May 30 12:53:05 2013 -0700 >>> >>>ARM: OMAP2+: Remove board-omap4panda.c >>> >>> As our patches on that file are internal I do not hold it against >>> you. This is no regression and we need to fix it. >>> >>> So my first step was to follow the recipe given in that commit. >>> Beside that I noticed a thread about USB issue on LKML so I also >>> applied the following commit: >>> >>> commit 352f573e59050c7a604c35c58b4bbfc51edebbee >>> Author: Roger Quadros >>> Date: Tue Jun 18 19:04:47 2013 +0300 >>> >>>ARM: OMAP2+: Provide alias to USB PHY clock >>> >>> The attached kernel log seems to suggest that the device tree is >>> picked up by the kernel, but the USB does not seem very active. >>> No ethernet connectivity. This does seem a regression to me. Is >>> there some other patch that I need to get it going again? >>> >> >> I tried with your config and 3.11-rc1 kernel with the above commit >> on top and ethernet seems to >> work for me. My boot log is attached. >> >> Are you sure that you are building the DTB for panda-es and the >> bootloader is picking up the right file and >> not an outdated one? > > I appended the DTB to the kernel image thus avoiding the need to > update u-boot (at least that is what I understood from Tony's commit). > I understand this can be a little tedious at first. This is my u-boot boot.txt fatload mmc 0:1 0x825f omap4-panda-es.dtb fatload mmc 0:1 0x8030 uImage set fdt_high 0x setenv bootargs console=ttyO2,115200n8 mem=1G@0x8000 root=/dev/mmcblk0p2 rootwait bootm 0x8030 - 0x825f You need to generate boot.scr from the above boot.txt and place it in SD card boot partition. mkimage -A arm -T script -C none -n "Boot Image" -d boot.txt boot.scr And of course copy the omap4-panda-es.dtb to SD card boot partition. hope this helps. >>> >>> Thanks for sharing this. >>> >> Why is the version of SPL loader and u-boot different in your log? >> You need to use the MLO file generated by the u-boot build along >> with the uImage. >> >> Just to be sure we are on the same setup could you please try with >> latest u-boot release (2013-04). Thanks. > > I recall having difficulty with TFTP boot using a 2013 u-boot > release, but that hurdle is for later. I will try. > OK. We can figure this out as well. >>> >>> I tried with same SPL and u-boot version, but that did not work out. >>> So I moved to v2013.04 and the log looks better. I was especially >>> interested in this: >>> >>> [2.807434] usb 1-1.1: new high-speed USB device number 3 using >>> ehci-omap >>> [2.932495] usb 1-1.1: New USB device found, idVendor=0424, >>> idProduct=ec00 >>> [2.932495] usb 1-1.1: New USB device strings: Mfr=0, Product=0, >>> SerialNumbe0 >>> [2.958770] smsc95xx v1.0.4 >>> Starting logging: OK >>> Initializing random number generator... [3.045806] smsc95xx >>> 1-1.1:1.0 eth0 >> >> Cool! :). >> >> FYI. I also tested tftpboot from u-boot and NFS root file system and >> it works fine. > > Hi Roger, > > Can I get back on this topic. When USB and ethernet was working for me > as stated above, I was not doing tftpboot. When I use tftpboot the > images are obtained from the tftp server, but after kernel has started > there is nothing in /sys/bus/usb/devices/. I quickly tried 3.11-rc2 + Roger's USB PHY clock patch on omap4-panda-es and enabled following USB options: CONFIG_USB_MUSB_HDRC=y CONFIG_USB_PHY=y CONFIG_OMAP_USB2=y CONFIG_OMAP_CONTROL_USB=y CONFIG_USB_MUSB_OMAP2PLUS=y CONFIG_MFD_OMAP_USB_HOST=y CONFIG_USB_EHCI_HCD=y CONFIG_USB_OHCI_HCD=y CONFIG_USB_EHCI_HCD_OMAP=y With this I see both USB ports, and ethernet: bash-4.2# ifconfig eth0 eth0 Link encap:Ethernet HWaddr
Re: Regression 3.11-rc1: omap4panda: no usb and consequently no ethernet
On 07/18/2013 02:42 PM, Roger Quadros wrote: On 07/18/2013 03:38 PM, Arend van Spriel wrote: On 07/18/2013 01:30 PM, Roger Quadros wrote: On 07/18/2013 02:24 PM, Arend van Spriel wrote: On 07/18/2013 01:18 PM, Roger Quadros wrote: Hi Arend, On 07/18/2013 11:41 AM, Arend van Spriel wrote: Hi Tony, We are using the panda board (es variant) for testing our SDIO based chips. For this we have an adapter card connection to expansion connector A. As this adapter is not publicly available we had internally patched board-omap4panda.c. Also we follow the -rc releases and use TFTP to boot the kernel image which requires USB. Moving to 3.11-rc1 I found that the mentioned board file was removed by your commit: commit b42b918194c4791510ac049e3d507169a7de8544 Author: Tony Lindgren Date: Thu May 30 12:53:05 2013 -0700 ARM: OMAP2+: Remove board-omap4panda.c As our patches on that file are internal I do not hold it against you. This is no regression and we need to fix it. So my first step was to follow the recipe given in that commit. Beside that I noticed a thread about USB issue on LKML so I also applied the following commit: commit 352f573e59050c7a604c35c58b4bbfc51edebbee Author: Roger Quadros Date: Tue Jun 18 19:04:47 2013 +0300 ARM: OMAP2+: Provide alias to USB PHY clock The attached kernel log seems to suggest that the device tree is picked up by the kernel, but the USB does not seem very active. No ethernet connectivity. This does seem a regression to me. Is there some other patch that I need to get it going again? I tried with your config and 3.11-rc1 kernel with the above commit on top and ethernet seems to work for me. My boot log is attached. Are you sure that you are building the DTB for panda-es and the bootloader is picking up the right file and not an outdated one? I appended the DTB to the kernel image thus avoiding the need to update u-boot (at least that is what I understood from Tony's commit). I understand this can be a little tedious at first. This is my u-boot boot.txt fatload mmc 0:1 0x825f omap4-panda-es.dtb fatload mmc 0:1 0x8030 uImage set fdt_high 0x setenv bootargs console=ttyO2,115200n8 mem=1G@0x8000 root=/dev/mmcblk0p2 rootwait bootm 0x8030 - 0x825f You need to generate boot.scr from the above boot.txt and place it in SD card boot partition. mkimage -A arm -T script -C none -n "Boot Image" -d boot.txt boot.scr And of course copy the omap4-panda-es.dtb to SD card boot partition. hope this helps. Thanks for sharing this. Why is the version of SPL loader and u-boot different in your log? You need to use the MLO file generated by the u-boot build along with the uImage. Just to be sure we are on the same setup could you please try with latest u-boot release (2013-04). Thanks. I recall having difficulty with TFTP boot using a 2013 u-boot release, but that hurdle is for later. I will try. OK. We can figure this out as well. I tried with same SPL and u-boot version, but that did not work out. So I moved to v2013.04 and the log looks better. I was especially interested in this: [2.807434] usb 1-1.1: new high-speed USB device number 3 using ehci-omap [2.932495] usb 1-1.1: New USB device found, idVendor=0424, idProduct=ec00 [2.932495] usb 1-1.1: New USB device strings: Mfr=0, Product=0, SerialNumbe0 [2.958770] smsc95xx v1.0.4 Starting logging: OK Initializing random number generator... [3.045806] smsc95xx 1-1.1:1.0 eth0 Cool! :). FYI. I also tested tftpboot from u-boot and NFS root file system and it works fine. Hi Roger, Can I get back on this topic. When USB and ethernet was working for me as stated above, I was not doing tftpboot. When I use tftpboot the images are obtained from the tftp server, but after kernel has started there is nothing in /sys/bus/usb/devices/. I tried a 'usb stop' before booting the kernel, but that does not help either. As you stated to have tftpboot working, maybe you can help me. Regards, Arend -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Regression 3.11-rc1: omap4panda: no usb and consequently no ethernet
On 07/18/2013 02:42 PM, Roger Quadros wrote: On 07/18/2013 03:38 PM, Arend van Spriel wrote: On 07/18/2013 01:30 PM, Roger Quadros wrote: On 07/18/2013 02:24 PM, Arend van Spriel wrote: On 07/18/2013 01:18 PM, Roger Quadros wrote: Hi Arend, On 07/18/2013 11:41 AM, Arend van Spriel wrote: Hi Tony, We are using the panda board (es variant) for testing our SDIO based chips. For this we have an adapter card connection to expansion connector A. As this adapter is not publicly available we had internally patched board-omap4panda.c. Also we follow the -rc releases and use TFTP to boot the kernel image which requires USB. Moving to 3.11-rc1 I found that the mentioned board file was removed by your commit: commit b42b918194c4791510ac049e3d507169a7de8544 Author: Tony Lindgren t...@atomide.com Date: Thu May 30 12:53:05 2013 -0700 ARM: OMAP2+: Remove board-omap4panda.c As our patches on that file are internal I do not hold it against you. This is no regression and we need to fix it. So my first step was to follow the recipe given in that commit. Beside that I noticed a thread about USB issue on LKML so I also applied the following commit: commit 352f573e59050c7a604c35c58b4bbfc51edebbee Author: Roger Quadros rog...@ti.com Date: Tue Jun 18 19:04:47 2013 +0300 ARM: OMAP2+: Provide alias to USB PHY clock The attached kernel log seems to suggest that the device tree is picked up by the kernel, but the USB does not seem very active. No ethernet connectivity. This does seem a regression to me. Is there some other patch that I need to get it going again? I tried with your config and 3.11-rc1 kernel with the above commit on top and ethernet seems to work for me. My boot log is attached. Are you sure that you are building the DTB for panda-es and the bootloader is picking up the right file and not an outdated one? I appended the DTB to the kernel image thus avoiding the need to update u-boot (at least that is what I understood from Tony's commit). I understand this can be a little tedious at first. This is my u-boot boot.txt fatload mmc 0:1 0x825f omap4-panda-es.dtb fatload mmc 0:1 0x8030 uImage set fdt_high 0x setenv bootargs console=ttyO2,115200n8 mem=1G@0x8000 root=/dev/mmcblk0p2 rootwait bootm 0x8030 - 0x825f You need to generate boot.scr from the above boot.txt and place it in SD card boot partition. mkimage -A arm -T script -C none -n Boot Image -d boot.txt boot.scr And of course copy the omap4-panda-es.dtb to SD card boot partition. hope this helps. Thanks for sharing this. Why is the version of SPL loader and u-boot different in your log? You need to use the MLO file generated by the u-boot build along with the uImage. Just to be sure we are on the same setup could you please try with latest u-boot release (2013-04). Thanks. I recall having difficulty with TFTP boot using a 2013 u-boot release, but that hurdle is for later. I will try. OK. We can figure this out as well. I tried with same SPL and u-boot version, but that did not work out. So I moved to v2013.04 and the log looks better. I was especially interested in this: [2.807434] usb 1-1.1: new high-speed USB device number 3 using ehci-omap [2.932495] usb 1-1.1: New USB device found, idVendor=0424, idProduct=ec00 [2.932495] usb 1-1.1: New USB device strings: Mfr=0, Product=0, SerialNumbe0 [2.958770] smsc95xx v1.0.4 Starting logging: OK Initializing random number generator... [3.045806] smsc95xx 1-1.1:1.0 eth0 Cool! :). FYI. I also tested tftpboot from u-boot and NFS root file system and it works fine. Hi Roger, Can I get back on this topic. When USB and ethernet was working for me as stated above, I was not doing tftpboot. When I use tftpboot the images are obtained from the tftp server, but after kernel has started there is nothing in /sys/bus/usb/devices/. I tried a 'usb stop' before booting the kernel, but that does not help either. As you stated to have tftpboot working, maybe you can help me. Regards, Arend -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Regression 3.11-rc1: omap4panda: no usb and consequently no ethernet
Hi Arend, On 07/25/2013 08:06 AM, Arend van Spriel wrote: On 07/18/2013 02:42 PM, Roger Quadros wrote: On 07/18/2013 03:38 PM, Arend van Spriel wrote: On 07/18/2013 01:30 PM, Roger Quadros wrote: On 07/18/2013 02:24 PM, Arend van Spriel wrote: On 07/18/2013 01:18 PM, Roger Quadros wrote: Hi Arend, On 07/18/2013 11:41 AM, Arend van Spriel wrote: Hi Tony, We are using the panda board (es variant) for testing our SDIO based chips. For this we have an adapter card connection to expansion connector A. As this adapter is not publicly available we had internally patched board-omap4panda.c. Also we follow the -rc releases and use TFTP to boot the kernel image which requires USB. Moving to 3.11-rc1 I found that the mentioned board file was removed by your commit: commit b42b918194c4791510ac049e3d507169a7de8544 Author: Tony Lindgren t...@atomide.com Date: Thu May 30 12:53:05 2013 -0700 ARM: OMAP2+: Remove board-omap4panda.c As our patches on that file are internal I do not hold it against you. This is no regression and we need to fix it. So my first step was to follow the recipe given in that commit. Beside that I noticed a thread about USB issue on LKML so I also applied the following commit: commit 352f573e59050c7a604c35c58b4bbfc51edebbee Author: Roger Quadros rog...@ti.com Date: Tue Jun 18 19:04:47 2013 +0300 ARM: OMAP2+: Provide alias to USB PHY clock The attached kernel log seems to suggest that the device tree is picked up by the kernel, but the USB does not seem very active. No ethernet connectivity. This does seem a regression to me. Is there some other patch that I need to get it going again? I tried with your config and 3.11-rc1 kernel with the above commit on top and ethernet seems to work for me. My boot log is attached. Are you sure that you are building the DTB for panda-es and the bootloader is picking up the right file and not an outdated one? I appended the DTB to the kernel image thus avoiding the need to update u-boot (at least that is what I understood from Tony's commit). I understand this can be a little tedious at first. This is my u-boot boot.txt fatload mmc 0:1 0x825f omap4-panda-es.dtb fatload mmc 0:1 0x8030 uImage set fdt_high 0x setenv bootargs console=ttyO2,115200n8 mem=1G@0x8000 root=/dev/mmcblk0p2 rootwait bootm 0x8030 - 0x825f You need to generate boot.scr from the above boot.txt and place it in SD card boot partition. mkimage -A arm -T script -C none -n Boot Image -d boot.txt boot.scr And of course copy the omap4-panda-es.dtb to SD card boot partition. hope this helps. Thanks for sharing this. Why is the version of SPL loader and u-boot different in your log? You need to use the MLO file generated by the u-boot build along with the uImage. Just to be sure we are on the same setup could you please try with latest u-boot release (2013-04). Thanks. I recall having difficulty with TFTP boot using a 2013 u-boot release, but that hurdle is for later. I will try. OK. We can figure this out as well. I tried with same SPL and u-boot version, but that did not work out. So I moved to v2013.04 and the log looks better. I was especially interested in this: [2.807434] usb 1-1.1: new high-speed USB device number 3 using ehci-omap [2.932495] usb 1-1.1: New USB device found, idVendor=0424, idProduct=ec00 [2.932495] usb 1-1.1: New USB device strings: Mfr=0, Product=0, SerialNumbe0 [2.958770] smsc95xx v1.0.4 Starting logging: OK Initializing random number generator... [3.045806] smsc95xx 1-1.1:1.0 eth0 Cool! :). FYI. I also tested tftpboot from u-boot and NFS root file system and it works fine. Hi Roger, Can I get back on this topic. When USB and ethernet was working for me as stated above, I was not doing tftpboot. When I use tftpboot the images are obtained from the tftp server, but after kernel has started there is nothing in /sys/bus/usb/devices/. I quickly tried 3.11-rc2 + Roger's USB PHY clock patch on omap4-panda-es and enabled following USB options: CONFIG_USB_MUSB_HDRC=y CONFIG_USB_PHY=y CONFIG_OMAP_USB2=y CONFIG_OMAP_CONTROL_USB=y CONFIG_USB_MUSB_OMAP2PLUS=y CONFIG_MFD_OMAP_USB_HOST=y CONFIG_USB_EHCI_HCD=y CONFIG_USB_OHCI_HCD=y CONFIG_USB_EHCI_HCD_OMAP=y With this I see both USB ports, and ethernet: bash-4.2# ifconfig eth0 eth0 Link encap:Ethernet HWaddr BE:08:A9:74:3E:A0 inet addr:192.168.3.4 Bcast:192.168.3.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:6 errors:0 dropped:0 overruns:0 frame:0 TX packets:17 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:842 (842.0 B) TX bytes:4724 (4.6 KiB) bash-4.2# lsusb Bus 001 Device 002: ID 0424:9514 Standard Microsystems Corp. Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 002 Device 001: ID 1d6b:0001 Linux
Re: Regression 3.11-rc1: omap4panda: no usb and consequently no ethernet
On 07/25/2013 09:49 PM, Joel Fernandes wrote: [..] Can I get back on this topic. When USB and ethernet was working for me as stated above, I was not doing tftpboot. When I use tftpboot the images are obtained from the tftp server, but after kernel has started there is nothing in /sys/bus/usb/devices/. I quickly tried 3.11-rc2 + Roger's USB PHY clock patch on omap4-panda-es and enabled following USB options: CONFIG_USB_MUSB_HDRC=y CONFIG_USB_PHY=y CONFIG_OMAP_USB2=y CONFIG_OMAP_CONTROL_USB=y CONFIG_USB_MUSB_OMAP2PLUS=y CONFIG_MFD_OMAP_USB_HOST=y CONFIG_USB_EHCI_HCD=y CONFIG_USB_OHCI_HCD=y CONFIG_USB_EHCI_HCD_OMAP=y Sorry I missed saying I also set had to set CONFIG_NOP_USB_XCEIV=y Thanks, -Joel -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Regression 3.11-rc1: omap4panda: no usb and consequently no ethernet
On Thu, 2013-07-18 at 01:59 -0700, Tony Lindgren wrote: > * Arend van Spriel [130718 01:47]: > Then for the SDIO with device tree, take a look at the following > patches: > > [PATCH 0/3] WLAN support for omap4 when booted with devicetree > http://comments.gmane.org/gmane.linux.ports.arm.omap/97522# > > The wl12xx .dts changes for pandaboard are still missing too. Just for the record, I already have the DTS patches for wl12xx on Panda (and a few other boards). I held them back because I wanted the bindings to be properly defined first. I'll continue this work pretty soon, when I come back from my summer vacations (in a week). -- Cheers, Luca. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Regression 3.11-rc1: omap4panda: no usb and consequently no ethernet
On Thu, 2013-07-18 at 01:59 -0700, Tony Lindgren wrote: * Arend van Spriel ar...@broadcom.com [130718 01:47]: Then for the SDIO with device tree, take a look at the following patches: [PATCH 0/3] WLAN support for omap4 when booted with devicetree http://comments.gmane.org/gmane.linux.ports.arm.omap/97522# The wl12xx .dts changes for pandaboard are still missing too. Just for the record, I already have the DTS patches for wl12xx on Panda (and a few other boards). I held them back because I wanted the bindings to be properly defined first. I'll continue this work pretty soon, when I come back from my summer vacations (in a week). -- Cheers, Luca. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Regression 3.11-rc1: omap4panda: no usb and consequently no ethernet
On 07/19/2013 12:49 PM, Roger Quadros wrote: On 07/19/2013 01:36 PM, Arend van Spriel wrote: On 07/18/2013 10:59 AM, Tony Lindgren wrote: Then for the SDIO with device tree, take a look at the following patches: [PATCH 0/3] WLAN support for omap4 when booted with devicetree http://comments.gmane.org/gmane.linux.ports.arm.omap/97522# I have been looking at the pandaboard patch in the series above and I do have a question. Among other things the patch adds these dt entries. +0x108 0x118/* sdmmc5_clk.sdmmc5_clk INPUT_PULLUP | MODE0 */ +0x10a 0x118/* sdmmc5_cmd.sdmmc5_cmd INPUT_PULLUP | MODE0 */ If I look at the similar names in the deceased board-omap4panda.c: board-omap4panda.c:OMAP4_MUX(SDMMC5_CMD, OMAP_MUX_MODE0 | OMAP_PIN_INPUT_PULLUP), board-omap4panda.c:OMAP4_MUX(SDMMC5_CLK, OMAP_MUX_MODE0 | OMAP_PIN_INPUT_PULLUP), and in mux44xx.h: mux44xx.h:#define OMAP4_CTRL_MODULE_PAD_SDMMC5_CLK_OFFSET0x0148 mux44xx.h:#define OMAP4_CTRL_MODULE_PAD_SDMMC5_CMD_OFFSET0x014a So how did 0x0148 get 0x0108 in DT and 0x014a get 0x010a. There is probably an explanation to it and it would help my understanding to know where this difference comes from. Hope you can help me out here. If you see omap4.dtsi, omap4_pmx_core starts at register address 0x4a100040. So, you need to subtract 0x40 from the offsets defined in mux44xx.h for pmx_core registers. That was what I was looking for. Thanks! NOTE: omap4_pmx_wkup starts at a different address. Those are for wakeup domain control registers. Will keep that in mind. Regards, Arend -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Regression 3.11-rc1: omap4panda: no usb and consequently no ethernet
* Arend van Spriel [130719 03:43]: > On 07/18/2013 10:59 AM, Tony Lindgren wrote: > >Then for the SDIO with device tree, take a look at the following > >patches: > > > >[PATCH 0/3] WLAN support for omap4 when booted with devicetree > >http://comments.gmane.org/gmane.linux.ports.arm.omap/97522# > > I have been looking at the pandaboard patch in the series above and > I do have a question. Among other things the patch adds these dt > entries. > > + 0x108 0x118 /* sdmmc5_clk.sdmmc5_clk INPUT_PULLUP | > MODE0 */ > + 0x10a 0x118 /* sdmmc5_cmd.sdmmc5_cmd INPUT_PULLUP | > MODE0 */ > > If I look at the similar names in the deceased board-omap4panda.c: > > board-omap4panda.c: OMAP4_MUX(SDMMC5_CMD, OMAP_MUX_MODE0 | > OMAP_PIN_INPUT_PULLUP), > board-omap4panda.c: OMAP4_MUX(SDMMC5_CLK, OMAP_MUX_MODE0 | > OMAP_PIN_INPUT_PULLUP), > > and in mux44xx.h: > > mux44xx.h:#define OMAP4_CTRL_MODULE_PAD_SDMMC5_CLK_OFFSET 0x0148 > mux44xx.h:#define OMAP4_CTRL_MODULE_PAD_SDMMC5_CMD_OFFSET 0x014a > > So how did 0x0148 get 0x0108 in DT and 0x014a get 0x010a. There is > probably an explanation to it and it would help my understanding to > know where this difference comes from. Hope you can help me out > here. That's pretty confusing I agree.. The reason is that we have multiple instances of the pinctrl-single: one for core domain and one for wkup domain. Those instances cover the padconf registers. Then further instances of pinctrl-single,bits will be used for the various other SCM registers. Felipe suggested adding a macro like OMAP4_PAD(offset, value) to make it less confusing, but for omap4 core padconf area the difference is 0x40, and 0x30 for omap3 if I remember correctly. > Below are the definitions that I need to move into a dts. > > /* MMC2 Mux for extension board */ > /* MMC2 CMD */ > OMAP4_MUX(GPMC_NWE, OMAP_MUX_MODE1 | OMAP_PIN_INPUT_PULLUP), > /* MMC2 CLK */ > OMAP4_MUX(GPMC_NOE, OMAP_MUX_MODE1 | OMAP_PIN_INPUT_PULLUP), > /* MMC2 DAT 0-7 */ > OMAP4_MUX(GPMC_AD0, OMAP_MUX_MODE1 | OMAP_PIN_INPUT_PULLUP), > OMAP4_MUX(GPMC_AD1, OMAP_MUX_MODE1 | OMAP_PIN_INPUT_PULLUP), > OMAP4_MUX(GPMC_AD2, OMAP_MUX_MODE1 | OMAP_PIN_INPUT_PULLUP), > OMAP4_MUX(GPMC_AD3, OMAP_MUX_MODE1 | OMAP_PIN_INPUT_PULLUP), Assuming these are all in the core padconf area, just take the TRM register offset and subtract 0x40. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Regression 3.11-rc1: omap4panda: no usb and consequently no ethernet
On 07/19/2013 01:36 PM, Arend van Spriel wrote: > On 07/18/2013 10:59 AM, Tony Lindgren wrote: >> Then for the SDIO with device tree, take a look at the following >> patches: >> >> [PATCH 0/3] WLAN support for omap4 when booted with devicetree >> http://comments.gmane.org/gmane.linux.ports.arm.omap/97522# > > I have been looking at the pandaboard patch in the series above and I do have > a question. Among other things the patch adds these dt entries. > > +0x108 0x118/* sdmmc5_clk.sdmmc5_clk INPUT_PULLUP | MODE0 */ > +0x10a 0x118/* sdmmc5_cmd.sdmmc5_cmd INPUT_PULLUP | MODE0 */ > > If I look at the similar names in the deceased board-omap4panda.c: > > board-omap4panda.c:OMAP4_MUX(SDMMC5_CMD, OMAP_MUX_MODE0 | > OMAP_PIN_INPUT_PULLUP), > board-omap4panda.c:OMAP4_MUX(SDMMC5_CLK, OMAP_MUX_MODE0 | > OMAP_PIN_INPUT_PULLUP), > > and in mux44xx.h: > > mux44xx.h:#define OMAP4_CTRL_MODULE_PAD_SDMMC5_CLK_OFFSET0x0148 > mux44xx.h:#define OMAP4_CTRL_MODULE_PAD_SDMMC5_CMD_OFFSET0x014a > > So how did 0x0148 get 0x0108 in DT and 0x014a get 0x010a. There is probably > an explanation to it and it would help my understanding to know where this > difference comes from. Hope you can help me out here. > If you see omap4.dtsi, omap4_pmx_core starts at register address 0x4a100040. So, you need to subtract 0x40 from the offsets defined in mux44xx.h for pmx_core registers. NOTE: omap4_pmx_wkup starts at a different address. Those are for wakeup domain control registers. cheers, -roger -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Regression 3.11-rc1: omap4panda: no usb and consequently no ethernet
On 07/18/2013 10:59 AM, Tony Lindgren wrote: Then for the SDIO with device tree, take a look at the following patches: [PATCH 0/3] WLAN support for omap4 when booted with devicetree http://comments.gmane.org/gmane.linux.ports.arm.omap/97522# I have been looking at the pandaboard patch in the series above and I do have a question. Among other things the patch adds these dt entries. + 0x108 0x118 /* sdmmc5_clk.sdmmc5_clk INPUT_PULLUP | MODE0 */ + 0x10a 0x118 /* sdmmc5_cmd.sdmmc5_cmd INPUT_PULLUP | MODE0 */ If I look at the similar names in the deceased board-omap4panda.c: board-omap4panda.c: OMAP4_MUX(SDMMC5_CMD, OMAP_MUX_MODE0 | OMAP_PIN_INPUT_PULLUP), board-omap4panda.c: OMAP4_MUX(SDMMC5_CLK, OMAP_MUX_MODE0 | OMAP_PIN_INPUT_PULLUP), and in mux44xx.h: mux44xx.h:#define OMAP4_CTRL_MODULE_PAD_SDMMC5_CLK_OFFSET 0x0148 mux44xx.h:#define OMAP4_CTRL_MODULE_PAD_SDMMC5_CMD_OFFSET 0x014a So how did 0x0148 get 0x0108 in DT and 0x014a get 0x010a. There is probably an explanation to it and it would help my understanding to know where this difference comes from. Hope you can help me out here. Below are the definitions that I need to move into a dts. Regards, Arend /* MMC2 Mux for extension board */ /* MMC2 CMD */ OMAP4_MUX(GPMC_NWE, OMAP_MUX_MODE1 | OMAP_PIN_INPUT_PULLUP), /* MMC2 CLK */ OMAP4_MUX(GPMC_NOE, OMAP_MUX_MODE1 | OMAP_PIN_INPUT_PULLUP), /* MMC2 DAT 0-7 */ OMAP4_MUX(GPMC_AD0, OMAP_MUX_MODE1 | OMAP_PIN_INPUT_PULLUP), OMAP4_MUX(GPMC_AD1, OMAP_MUX_MODE1 | OMAP_PIN_INPUT_PULLUP), OMAP4_MUX(GPMC_AD2, OMAP_MUX_MODE1 | OMAP_PIN_INPUT_PULLUP), OMAP4_MUX(GPMC_AD3, OMAP_MUX_MODE1 | OMAP_PIN_INPUT_PULLUP), -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Regression 3.11-rc1: omap4panda: no usb and consequently no ethernet
On 07/18/2013 10:59 AM, Tony Lindgren wrote: Then for the SDIO with device tree, take a look at the following patches: [PATCH 0/3] WLAN support for omap4 when booted with devicetree http://comments.gmane.org/gmane.linux.ports.arm.omap/97522# I have been looking at the pandaboard patch in the series above and I do have a question. Among other things the patch adds these dt entries. + 0x108 0x118 /* sdmmc5_clk.sdmmc5_clk INPUT_PULLUP | MODE0 */ + 0x10a 0x118 /* sdmmc5_cmd.sdmmc5_cmd INPUT_PULLUP | MODE0 */ If I look at the similar names in the deceased board-omap4panda.c: board-omap4panda.c: OMAP4_MUX(SDMMC5_CMD, OMAP_MUX_MODE0 | OMAP_PIN_INPUT_PULLUP), board-omap4panda.c: OMAP4_MUX(SDMMC5_CLK, OMAP_MUX_MODE0 | OMAP_PIN_INPUT_PULLUP), and in mux44xx.h: mux44xx.h:#define OMAP4_CTRL_MODULE_PAD_SDMMC5_CLK_OFFSET 0x0148 mux44xx.h:#define OMAP4_CTRL_MODULE_PAD_SDMMC5_CMD_OFFSET 0x014a So how did 0x0148 get 0x0108 in DT and 0x014a get 0x010a. There is probably an explanation to it and it would help my understanding to know where this difference comes from. Hope you can help me out here. Below are the definitions that I need to move into a dts. Regards, Arend /* MMC2 Mux for extension board */ /* MMC2 CMD */ OMAP4_MUX(GPMC_NWE, OMAP_MUX_MODE1 | OMAP_PIN_INPUT_PULLUP), /* MMC2 CLK */ OMAP4_MUX(GPMC_NOE, OMAP_MUX_MODE1 | OMAP_PIN_INPUT_PULLUP), /* MMC2 DAT 0-7 */ OMAP4_MUX(GPMC_AD0, OMAP_MUX_MODE1 | OMAP_PIN_INPUT_PULLUP), OMAP4_MUX(GPMC_AD1, OMAP_MUX_MODE1 | OMAP_PIN_INPUT_PULLUP), OMAP4_MUX(GPMC_AD2, OMAP_MUX_MODE1 | OMAP_PIN_INPUT_PULLUP), OMAP4_MUX(GPMC_AD3, OMAP_MUX_MODE1 | OMAP_PIN_INPUT_PULLUP), -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Regression 3.11-rc1: omap4panda: no usb and consequently no ethernet
On 07/19/2013 01:36 PM, Arend van Spriel wrote: On 07/18/2013 10:59 AM, Tony Lindgren wrote: Then for the SDIO with device tree, take a look at the following patches: [PATCH 0/3] WLAN support for omap4 when booted with devicetree http://comments.gmane.org/gmane.linux.ports.arm.omap/97522# I have been looking at the pandaboard patch in the series above and I do have a question. Among other things the patch adds these dt entries. +0x108 0x118/* sdmmc5_clk.sdmmc5_clk INPUT_PULLUP | MODE0 */ +0x10a 0x118/* sdmmc5_cmd.sdmmc5_cmd INPUT_PULLUP | MODE0 */ If I look at the similar names in the deceased board-omap4panda.c: board-omap4panda.c:OMAP4_MUX(SDMMC5_CMD, OMAP_MUX_MODE0 | OMAP_PIN_INPUT_PULLUP), board-omap4panda.c:OMAP4_MUX(SDMMC5_CLK, OMAP_MUX_MODE0 | OMAP_PIN_INPUT_PULLUP), and in mux44xx.h: mux44xx.h:#define OMAP4_CTRL_MODULE_PAD_SDMMC5_CLK_OFFSET0x0148 mux44xx.h:#define OMAP4_CTRL_MODULE_PAD_SDMMC5_CMD_OFFSET0x014a So how did 0x0148 get 0x0108 in DT and 0x014a get 0x010a. There is probably an explanation to it and it would help my understanding to know where this difference comes from. Hope you can help me out here. If you see omap4.dtsi, omap4_pmx_core starts at register address 0x4a100040. So, you need to subtract 0x40 from the offsets defined in mux44xx.h for pmx_core registers. NOTE: omap4_pmx_wkup starts at a different address. Those are for wakeup domain control registers. cheers, -roger -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Regression 3.11-rc1: omap4panda: no usb and consequently no ethernet
* Arend van Spriel ar...@broadcom.com [130719 03:43]: On 07/18/2013 10:59 AM, Tony Lindgren wrote: Then for the SDIO with device tree, take a look at the following patches: [PATCH 0/3] WLAN support for omap4 when booted with devicetree http://comments.gmane.org/gmane.linux.ports.arm.omap/97522# I have been looking at the pandaboard patch in the series above and I do have a question. Among other things the patch adds these dt entries. + 0x108 0x118 /* sdmmc5_clk.sdmmc5_clk INPUT_PULLUP | MODE0 */ + 0x10a 0x118 /* sdmmc5_cmd.sdmmc5_cmd INPUT_PULLUP | MODE0 */ If I look at the similar names in the deceased board-omap4panda.c: board-omap4panda.c: OMAP4_MUX(SDMMC5_CMD, OMAP_MUX_MODE0 | OMAP_PIN_INPUT_PULLUP), board-omap4panda.c: OMAP4_MUX(SDMMC5_CLK, OMAP_MUX_MODE0 | OMAP_PIN_INPUT_PULLUP), and in mux44xx.h: mux44xx.h:#define OMAP4_CTRL_MODULE_PAD_SDMMC5_CLK_OFFSET 0x0148 mux44xx.h:#define OMAP4_CTRL_MODULE_PAD_SDMMC5_CMD_OFFSET 0x014a So how did 0x0148 get 0x0108 in DT and 0x014a get 0x010a. There is probably an explanation to it and it would help my understanding to know where this difference comes from. Hope you can help me out here. That's pretty confusing I agree.. The reason is that we have multiple instances of the pinctrl-single: one for core domain and one for wkup domain. Those instances cover the padconf registers. Then further instances of pinctrl-single,bits will be used for the various other SCM registers. Felipe suggested adding a macro like OMAP4_PAD(offset, value) to make it less confusing, but for omap4 core padconf area the difference is 0x40, and 0x30 for omap3 if I remember correctly. Below are the definitions that I need to move into a dts. /* MMC2 Mux for extension board */ /* MMC2 CMD */ OMAP4_MUX(GPMC_NWE, OMAP_MUX_MODE1 | OMAP_PIN_INPUT_PULLUP), /* MMC2 CLK */ OMAP4_MUX(GPMC_NOE, OMAP_MUX_MODE1 | OMAP_PIN_INPUT_PULLUP), /* MMC2 DAT 0-7 */ OMAP4_MUX(GPMC_AD0, OMAP_MUX_MODE1 | OMAP_PIN_INPUT_PULLUP), OMAP4_MUX(GPMC_AD1, OMAP_MUX_MODE1 | OMAP_PIN_INPUT_PULLUP), OMAP4_MUX(GPMC_AD2, OMAP_MUX_MODE1 | OMAP_PIN_INPUT_PULLUP), OMAP4_MUX(GPMC_AD3, OMAP_MUX_MODE1 | OMAP_PIN_INPUT_PULLUP), Assuming these are all in the core padconf area, just take the TRM register offset and subtract 0x40. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Regression 3.11-rc1: omap4panda: no usb and consequently no ethernet
On 07/19/2013 12:49 PM, Roger Quadros wrote: On 07/19/2013 01:36 PM, Arend van Spriel wrote: On 07/18/2013 10:59 AM, Tony Lindgren wrote: Then for the SDIO with device tree, take a look at the following patches: [PATCH 0/3] WLAN support for omap4 when booted with devicetree http://comments.gmane.org/gmane.linux.ports.arm.omap/97522# I have been looking at the pandaboard patch in the series above and I do have a question. Among other things the patch adds these dt entries. +0x108 0x118/* sdmmc5_clk.sdmmc5_clk INPUT_PULLUP | MODE0 */ +0x10a 0x118/* sdmmc5_cmd.sdmmc5_cmd INPUT_PULLUP | MODE0 */ If I look at the similar names in the deceased board-omap4panda.c: board-omap4panda.c:OMAP4_MUX(SDMMC5_CMD, OMAP_MUX_MODE0 | OMAP_PIN_INPUT_PULLUP), board-omap4panda.c:OMAP4_MUX(SDMMC5_CLK, OMAP_MUX_MODE0 | OMAP_PIN_INPUT_PULLUP), and in mux44xx.h: mux44xx.h:#define OMAP4_CTRL_MODULE_PAD_SDMMC5_CLK_OFFSET0x0148 mux44xx.h:#define OMAP4_CTRL_MODULE_PAD_SDMMC5_CMD_OFFSET0x014a So how did 0x0148 get 0x0108 in DT and 0x014a get 0x010a. There is probably an explanation to it and it would help my understanding to know where this difference comes from. Hope you can help me out here. If you see omap4.dtsi, omap4_pmx_core starts at register address 0x4a100040. So, you need to subtract 0x40 from the offsets defined in mux44xx.h for pmx_core registers. That was what I was looking for. Thanks! NOTE: omap4_pmx_wkup starts at a different address. Those are for wakeup domain control registers. Will keep that in mind. Regards, Arend -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Regression 3.11-rc1: omap4panda: no usb and consequently no ethernet
On 07/18/2013 03:38 PM, Arend van Spriel wrote: > On 07/18/2013 01:30 PM, Roger Quadros wrote: >> On 07/18/2013 02:24 PM, Arend van Spriel wrote: >>> On 07/18/2013 01:18 PM, Roger Quadros wrote: Hi Arend, On 07/18/2013 11:41 AM, Arend van Spriel wrote: > Hi Tony, > > > We are using the panda board (es variant) for testing our SDIO based > chips. For this we have an adapter card connection to expansion connector > A. As this adapter is not publicly available we had internally patched > board-omap4panda.c. Also we follow the -rc releases and use TFTP to boot > the kernel image which requires USB. > > Moving to 3.11-rc1 I found that the mentioned board file was removed by > your commit: > > commit b42b918194c4791510ac049e3d507169a7de8544 > Author: Tony Lindgren > Date: Thu May 30 12:53:05 2013 -0700 > > ARM: OMAP2+: Remove board-omap4panda.c > > As our patches on that file are internal I do not hold it against you. > This is no regression and we need to fix it. > > So my first step was to follow the recipe given in that commit. Beside > that I noticed a thread about USB issue on LKML so I also applied the > following commit: > > commit 352f573e59050c7a604c35c58b4bbfc51edebbee > Author: Roger Quadros > Date: Tue Jun 18 19:04:47 2013 +0300 > > ARM: OMAP2+: Provide alias to USB PHY clock > > The attached kernel log seems to suggest that the device tree is picked > up by the kernel, but the USB does not seem very active. No ethernet > connectivity. This does seem a regression to me. Is there some other > patch that I need to get it going again? > I tried with your config and 3.11-rc1 kernel with the above commit on top and ethernet seems to work for me. My boot log is attached. Are you sure that you are building the DTB for panda-es and the bootloader is picking up the right file and not an outdated one? >>> >>> I appended the DTB to the kernel image thus avoiding the need to update >>> u-boot (at least that is what I understood from Tony's commit). >>> >> >> I understand this can be a little tedious at first. >> >> This is my u-boot boot.txt >> >> fatload mmc 0:1 0x825f omap4-panda-es.dtb >> fatload mmc 0:1 0x8030 uImage >> set fdt_high 0x >> setenv bootargs console=ttyO2,115200n8 mem=1G@0x8000 root=/dev/mmcblk0p2 >> rootwait >> bootm 0x8030 - 0x825f >> >> You need to generate boot.scr from the above boot.txt and place it in SD >> card boot partition. >> >> mkimage -A arm -T script -C none -n "Boot Image" -d boot.txt boot.scr >> >> And of course copy the omap4-panda-es.dtb to SD card boot partition. >> >> hope this helps. > > Thanks for sharing this. > Why is the version of SPL loader and u-boot different in your log? You need to use the MLO file generated by the u-boot build along with the uImage. Just to be sure we are on the same setup could you please try with latest u-boot release (2013-04). Thanks. >>> >>> I recall having difficulty with TFTP boot using a 2013 u-boot release, but >>> that hurdle is for later. I will try. >>> >> >> OK. We can figure this out as well. > > I tried with same SPL and u-boot version, but that did not work out. So I > moved to v2013.04 and the log looks better. I was especially interested in > this: > > [2.807434] usb 1-1.1: new high-speed USB device number 3 using ehci-omap > [2.932495] usb 1-1.1: New USB device found, idVendor=0424, idProduct=ec00 > [2.932495] usb 1-1.1: New USB device strings: Mfr=0, Product=0, > SerialNumbe0 > [2.958770] smsc95xx v1.0.4 > Starting logging: OK > Initializing random number generator... [3.045806] smsc95xx 1-1.1:1.0 eth0 Cool! :). FYI. I also tested tftpboot from u-boot and NFS root file system and it works fine. cheers, -roger -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Regression 3.11-rc1: omap4panda: no usb and consequently no ethernet
On 07/18/2013 01:30 PM, Roger Quadros wrote: On 07/18/2013 02:24 PM, Arend van Spriel wrote: On 07/18/2013 01:18 PM, Roger Quadros wrote: Hi Arend, On 07/18/2013 11:41 AM, Arend van Spriel wrote: Hi Tony, We are using the panda board (es variant) for testing our SDIO based chips. For this we have an adapter card connection to expansion connector A. As this adapter is not publicly available we had internally patched board-omap4panda.c. Also we follow the -rc releases and use TFTP to boot the kernel image which requires USB. Moving to 3.11-rc1 I found that the mentioned board file was removed by your commit: commit b42b918194c4791510ac049e3d507169a7de8544 Author: Tony Lindgren Date: Thu May 30 12:53:05 2013 -0700 ARM: OMAP2+: Remove board-omap4panda.c As our patches on that file are internal I do not hold it against you. This is no regression and we need to fix it. So my first step was to follow the recipe given in that commit. Beside that I noticed a thread about USB issue on LKML so I also applied the following commit: commit 352f573e59050c7a604c35c58b4bbfc51edebbee Author: Roger Quadros Date: Tue Jun 18 19:04:47 2013 +0300 ARM: OMAP2+: Provide alias to USB PHY clock The attached kernel log seems to suggest that the device tree is picked up by the kernel, but the USB does not seem very active. No ethernet connectivity. This does seem a regression to me. Is there some other patch that I need to get it going again? I tried with your config and 3.11-rc1 kernel with the above commit on top and ethernet seems to work for me. My boot log is attached. Are you sure that you are building the DTB for panda-es and the bootloader is picking up the right file and not an outdated one? I appended the DTB to the kernel image thus avoiding the need to update u-boot (at least that is what I understood from Tony's commit). I understand this can be a little tedious at first. This is my u-boot boot.txt fatload mmc 0:1 0x825f omap4-panda-es.dtb fatload mmc 0:1 0x8030 uImage set fdt_high 0x setenv bootargs console=ttyO2,115200n8 mem=1G@0x8000 root=/dev/mmcblk0p2 rootwait bootm 0x8030 - 0x825f You need to generate boot.scr from the above boot.txt and place it in SD card boot partition. mkimage -A arm -T script -C none -n "Boot Image" -d boot.txt boot.scr And of course copy the omap4-panda-es.dtb to SD card boot partition. hope this helps. Thanks for sharing this. Why is the version of SPL loader and u-boot different in your log? You need to use the MLO file generated by the u-boot build along with the uImage. Just to be sure we are on the same setup could you please try with latest u-boot release (2013-04). Thanks. I recall having difficulty with TFTP boot using a 2013 u-boot release, but that hurdle is for later. I will try. OK. We can figure this out as well. I tried with same SPL and u-boot version, but that did not work out. So I moved to v2013.04 and the log looks better. I was especially interested in this: [2.807434] usb 1-1.1: new high-speed USB device number 3 using ehci-omap [2.932495] usb 1-1.1: New USB device found, idVendor=0424, idProduct=ec00 [2.932495] usb 1-1.1: New USB device strings: Mfr=0, Product=0, SerialNumbe0 [2.958770] smsc95xx v1.0.4 Starting logging: OK Initializing random number generator... [3.045806] smsc95xx 1-1.1:1.0 eth0 Regards, Arend -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Regression 3.11-rc1: omap4panda: no usb and consequently no ethernet
On 07/18/2013 02:24 PM, Arend van Spriel wrote: > On 07/18/2013 01:18 PM, Roger Quadros wrote: >> Hi Arend, >> >> On 07/18/2013 11:41 AM, Arend van Spriel wrote: >>> Hi Tony, >>> >>> >>> We are using the panda board (es variant) for testing our SDIO based chips. >>> For this we have an adapter card connection to expansion connector A. As >>> this adapter is not publicly available we had internally patched >>> board-omap4panda.c. Also we follow the -rc releases and use TFTP to boot >>> the kernel image which requires USB. >>> >>> Moving to 3.11-rc1 I found that the mentioned board file was removed by >>> your commit: >>> >>> commit b42b918194c4791510ac049e3d507169a7de8544 >>> Author: Tony Lindgren >>> Date: Thu May 30 12:53:05 2013 -0700 >>> >>> ARM: OMAP2+: Remove board-omap4panda.c >>> >>> As our patches on that file are internal I do not hold it against you. This >>> is no regression and we need to fix it. >>> >>> So my first step was to follow the recipe given in that commit. Beside that >>> I noticed a thread about USB issue on LKML so I also applied the following >>> commit: >>> >>> commit 352f573e59050c7a604c35c58b4bbfc51edebbee >>> Author: Roger Quadros >>> Date: Tue Jun 18 19:04:47 2013 +0300 >>> >>> ARM: OMAP2+: Provide alias to USB PHY clock >>> >>> The attached kernel log seems to suggest that the device tree is picked up >>> by the kernel, but the USB does not seem very active. No ethernet >>> connectivity. This does seem a regression to me. Is there some other patch >>> that I need to get it going again? >>> >> >> I tried with your config and 3.11-rc1 kernel with the above commit on top >> and ethernet seems to >> work for me. My boot log is attached. >> >> Are you sure that you are building the DTB for panda-es and the bootloader >> is picking up the right file and >> not an outdated one? > > I appended the DTB to the kernel image thus avoiding the need to update > u-boot (at least that is what I understood from Tony's commit). > I understand this can be a little tedious at first. This is my u-boot boot.txt fatload mmc 0:1 0x825f omap4-panda-es.dtb fatload mmc 0:1 0x8030 uImage set fdt_high 0x setenv bootargs console=ttyO2,115200n8 mem=1G@0x8000 root=/dev/mmcblk0p2 rootwait bootm 0x8030 - 0x825f You need to generate boot.scr from the above boot.txt and place it in SD card boot partition. mkimage -A arm -T script -C none -n "Boot Image" -d boot.txt boot.scr And of course copy the omap4-panda-es.dtb to SD card boot partition. hope this helps. >> Why is the version of SPL loader and u-boot different in your log? >> You need to use the MLO file generated by the u-boot build along with the >> uImage. >> >> Just to be sure we are on the same setup could you please try with latest >> u-boot release (2013-04). Thanks. > > I recall having difficulty with TFTP boot using a 2013 u-boot release, but > that hurdle is for later. I will try. > OK. We can figure this out as well. cheers, -roger -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Regression 3.11-rc1: omap4panda: no usb and consequently no ethernet
On 07/18/2013 01:18 PM, Roger Quadros wrote: Hi Arend, On 07/18/2013 11:41 AM, Arend van Spriel wrote: Hi Tony, We are using the panda board (es variant) for testing our SDIO based chips. For this we have an adapter card connection to expansion connector A. As this adapter is not publicly available we had internally patched board-omap4panda.c. Also we follow the -rc releases and use TFTP to boot the kernel image which requires USB. Moving to 3.11-rc1 I found that the mentioned board file was removed by your commit: commit b42b918194c4791510ac049e3d507169a7de8544 Author: Tony Lindgren Date: Thu May 30 12:53:05 2013 -0700 ARM: OMAP2+: Remove board-omap4panda.c As our patches on that file are internal I do not hold it against you. This is no regression and we need to fix it. So my first step was to follow the recipe given in that commit. Beside that I noticed a thread about USB issue on LKML so I also applied the following commit: commit 352f573e59050c7a604c35c58b4bbfc51edebbee Author: Roger Quadros Date: Tue Jun 18 19:04:47 2013 +0300 ARM: OMAP2+: Provide alias to USB PHY clock The attached kernel log seems to suggest that the device tree is picked up by the kernel, but the USB does not seem very active. No ethernet connectivity. This does seem a regression to me. Is there some other patch that I need to get it going again? I tried with your config and 3.11-rc1 kernel with the above commit on top and ethernet seems to work for me. My boot log is attached. Are you sure that you are building the DTB for panda-es and the bootloader is picking up the right file and not an outdated one? I appended the DTB to the kernel image thus avoiding the need to update u-boot (at least that is what I understood from Tony's commit). Why is the version of SPL loader and u-boot different in your log? You need to use the MLO file generated by the u-boot build along with the uImage. Just to be sure we are on the same setup could you please try with latest u-boot release (2013-04). Thanks. I recall having difficulty with TFTP boot using a 2013 u-boot release, but that hurdle is for later. I will try. cheers, -roger Thanks, Arend -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Regression 3.11-rc1: omap4panda: no usb and consequently no ethernet
Hi Arend, On 07/18/2013 11:41 AM, Arend van Spriel wrote: > Hi Tony, > > > We are using the panda board (es variant) for testing our SDIO based chips. > For this we have an adapter card connection to expansion connector A. As this > adapter is not publicly available we had internally patched > board-omap4panda.c. Also we follow the -rc releases and use TFTP to boot the > kernel image which requires USB. > > Moving to 3.11-rc1 I found that the mentioned board file was removed by your > commit: > > commit b42b918194c4791510ac049e3d507169a7de8544 > Author: Tony Lindgren > Date: Thu May 30 12:53:05 2013 -0700 > > ARM: OMAP2+: Remove board-omap4panda.c > > As our patches on that file are internal I do not hold it against you. This > is no regression and we need to fix it. > > So my first step was to follow the recipe given in that commit. Beside that I > noticed a thread about USB issue on LKML so I also applied the following > commit: > > commit 352f573e59050c7a604c35c58b4bbfc51edebbee > Author: Roger Quadros > Date: Tue Jun 18 19:04:47 2013 +0300 > > ARM: OMAP2+: Provide alias to USB PHY clock > > The attached kernel log seems to suggest that the device tree is picked up by > the kernel, but the USB does not seem very active. No ethernet connectivity. > This does seem a regression to me. Is there some other patch that I need to > get it going again? > I tried with your config and 3.11-rc1 kernel with the above commit on top and ethernet seems to work for me. My boot log is attached. Are you sure that you are building the DTB for panda-es and the bootloader is picking up the right file and not an outdated one? Why is the version of SPL loader and u-boot different in your log? You need to use the MLO file generated by the u-boot build along with the uImage. Just to be sure we are on the same setup could you please try with latest u-boot release (2013-04). Thanks. cheers, -roger U-Boot SPL 2013.04 (Jul 18 2013 - 14:04:55) OMAP4460 ES1.1 OMAP SD/MMC: 0 reading u-boot.img reading u-boot.img U-Boot 2013.04 (Jul 18 2013 - 14:04:55) CPU : OMAP4460 ES1.1 Board: OMAP4 Panda I2C: ready DRAM: 1 GiB MMC: OMAP SD/MMC: 0 Using default environment In:serial Out: serial Err: serial Net: No ethernet found. Hit any key to stop autoboot: 0 mmc0 is current device SD/MMC found on device 0 reading boot.scr 409 bytes read in 3 ms (132.8 KiB/s) Running bootscript from mmc0 ... ## Executing script at 8200 reading omap4-panda.dtb 18588 bytes read in 6 ms (3 MiB/s) reading uImage 3947784 bytes read in 189 ms (19.9 MiB/s) ## Booting kernel from Legacy Image at 8030 ... Image Name: Linux-3.11.0-rc1-1-g4861de4 Image Type: ARM Linux Kernel Image (uncompressed) Data Size:3947720 Bytes = 3.8 MiB Load Address: 80008000 Entry Point: 80008000 Verifying Checksum ... OK ## Flattened Device Tree blob at 825f Booting using the fdt blob at 0x825f Loading Kernel Image ... OK OK Using Device Tree in place at 825f, end 825f789b Starting kernel ... [0.00] Booting Linux on physical CPU 0x0 [0.00] Linux version 3.11.0-rc1-1-g4861de4 (roger@rockdesk) (gcc version 4.7.1 20120531 (prerelease) (crosstool-NG linaro-1.13.1-2012.06-20120625 - Linaro GCC 2012.06) ) #862 SMP Thu Jul 18 14:10:14 EEST 2013 [0.00] CPU: ARMv7 Processor [412fc09a] revision 10 (ARMv7), cr=10c5387d [0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache [0.00] Machine: Generic OMAP4 (Flattened Device Tree), model: TI OMAP4 PandaBoard [0.00] Memory policy: ECC disabled, Data cache writealloc [0.00] On node 0 totalpages: 261888 [0.00] free_area_init_node: node 0, pgdat c07b9500, node_mem_map c0d21000 [0.00] Normal zone: 1520 pages used for memmap [0.00] Normal zone: 0 pages reserved [0.00] Normal zone: 194560 pages, LIFO batch:31 [0.00] HighMem zone: 528 pages used for memmap [0.00] HighMem zone: 67328 pages, LIFO batch:15 [0.00] OMAP4460 ES1.1 [0.00] PERCPU: Embedded 9 pages/cpu @c153b000 s14208 r8192 d14464 u36864 [0.00] pcpu-alloc: s14208 r8192 d14464 u36864 alloc=9*4096 [0.00] pcpu-alloc: [0] 0 [0] 1 [0.00] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 260368 [0.00] Kernel command line: console=ttyO2,115200n8 mem=1G@0x8000 root=/dev/mmcblk0p2 rootwait debug earlyprintk loglevel=8 [0.00] PID hash table entries: 4096 (order: 2, 16384 bytes) [0.00] Dentry cache hash table entries: 131072 (order: 7, 524288 bytes) [0.00] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) [0.00] Memory: 1024916K/1047552K available (5122K kernel code, 558K rwdata, 1860K rodata, 345K init, 5515K bss, 22636K reserved, 269312K highmem) [0.00] Virtual kernel memory layout: [0.00] vector : 0x -
Re: Regression 3.11-rc1: omap4panda: no usb and consequently no ethernet
On 07/18/2013 10:59 AM, Tony Lindgren wrote: * Arend van Spriel [130718 01:47]: So my first step was to follow the recipe given in that commit. Beside that I noticed a thread about USB issue on LKML so I also applied the following commit: commit 352f573e59050c7a604c35c58b4bbfc51edebbee Author: Roger Quadros Date: Tue Jun 18 19:04:47 2013 +0300 ARM: OMAP2+: Provide alias to USB PHY clock The attached kernel log seems to suggest that the device tree is picked up by the kernel, but the USB does not seem very active. No ethernet connectivity. This does seem a regression to me. Is there some other patch that I need to get it going again? There are few .dts related patches missing for USB. Roger can point you to the current versions that Benoit should be queueing for the -rc series. Hope Roger or Benoit will chime in. Then for the SDIO with device tree, take a look at the following patches: [PATCH 0/3] WLAN support for omap4 when booted with devicetree http://comments.gmane.org/gmane.linux.ports.arm.omap/97522# The wl12xx .dts changes for pandaboard are still missing too. Then I'll be updating these soonish: [PATCH 0/4] Updated omap_hsmmc SDIO and remuxing patches Those are needed for the SDIO interrupt, SDIO will work also without those. Thanks for the pointers, Arend -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Regression 3.11-rc1: omap4panda: no usb and consequently no ethernet
* Arend van Spriel [130718 01:47]: > > We are using the panda board (es variant) for testing our SDIO based > chips. For this we have an adapter card connection to expansion > connector A. As this adapter is not publicly available we had > internally patched board-omap4panda.c. Also we follow the -rc > releases and use TFTP to boot the kernel image which requires USB. > > Moving to 3.11-rc1 I found that the mentioned board file was removed > by your commit: > > commit b42b918194c4791510ac049e3d507169a7de8544 > Author: Tony Lindgren > Date: Thu May 30 12:53:05 2013 -0700 > > ARM: OMAP2+: Remove board-omap4panda.c > > As our patches on that file are internal I do not hold it against > you. This is no regression and we need to fix it. Right, we need to move on to device tree based booting. Most of it should be pretty trivial configuring of the .dts file and some .config changes so whatever issues are remaining should be out of the way by v3.11. > So my first step was to follow the recipe given in that commit. > Beside that I noticed a thread about USB issue on LKML so I also > applied the following commit: > > commit 352f573e59050c7a604c35c58b4bbfc51edebbee > Author: Roger Quadros > Date: Tue Jun 18 19:04:47 2013 +0300 > > ARM: OMAP2+: Provide alias to USB PHY clock > > The attached kernel log seems to suggest that the device tree is > picked up by the kernel, but the USB does not seem very active. No > ethernet connectivity. This does seem a regression to me. Is there > some other patch that I need to get it going again? There are few .dts related patches missing for USB. Roger can point you to the current versions that Benoit should be queueing for the -rc series. Then for the SDIO with device tree, take a look at the following patches: [PATCH 0/3] WLAN support for omap4 when booted with devicetree http://comments.gmane.org/gmane.linux.ports.arm.omap/97522# The wl12xx .dts changes for pandaboard are still missing too. Then I'll be updating these soonish: [PATCH 0/4] Updated omap_hsmmc SDIO and remuxing patches Those are needed for the SDIO interrupt, SDIO will work also without those. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Regression 3.11-rc1: omap4panda: no usb and consequently no ethernet
* Arend van Spriel ar...@broadcom.com [130718 01:47]: We are using the panda board (es variant) for testing our SDIO based chips. For this we have an adapter card connection to expansion connector A. As this adapter is not publicly available we had internally patched board-omap4panda.c. Also we follow the -rc releases and use TFTP to boot the kernel image which requires USB. Moving to 3.11-rc1 I found that the mentioned board file was removed by your commit: commit b42b918194c4791510ac049e3d507169a7de8544 Author: Tony Lindgren t...@atomide.com Date: Thu May 30 12:53:05 2013 -0700 ARM: OMAP2+: Remove board-omap4panda.c As our patches on that file are internal I do not hold it against you. This is no regression and we need to fix it. Right, we need to move on to device tree based booting. Most of it should be pretty trivial configuring of the .dts file and some .config changes so whatever issues are remaining should be out of the way by v3.11. So my first step was to follow the recipe given in that commit. Beside that I noticed a thread about USB issue on LKML so I also applied the following commit: commit 352f573e59050c7a604c35c58b4bbfc51edebbee Author: Roger Quadros rog...@ti.com Date: Tue Jun 18 19:04:47 2013 +0300 ARM: OMAP2+: Provide alias to USB PHY clock The attached kernel log seems to suggest that the device tree is picked up by the kernel, but the USB does not seem very active. No ethernet connectivity. This does seem a regression to me. Is there some other patch that I need to get it going again? There are few .dts related patches missing for USB. Roger can point you to the current versions that Benoit should be queueing for the -rc series. Then for the SDIO with device tree, take a look at the following patches: [PATCH 0/3] WLAN support for omap4 when booted with devicetree http://comments.gmane.org/gmane.linux.ports.arm.omap/97522# The wl12xx .dts changes for pandaboard are still missing too. Then I'll be updating these soonish: [PATCH 0/4] Updated omap_hsmmc SDIO and remuxing patches Those are needed for the SDIO interrupt, SDIO will work also without those. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Regression 3.11-rc1: omap4panda: no usb and consequently no ethernet
On 07/18/2013 10:59 AM, Tony Lindgren wrote: * Arend van Spriel ar...@broadcom.com [130718 01:47]: So my first step was to follow the recipe given in that commit. Beside that I noticed a thread about USB issue on LKML so I also applied the following commit: commit 352f573e59050c7a604c35c58b4bbfc51edebbee Author: Roger Quadros rog...@ti.com Date: Tue Jun 18 19:04:47 2013 +0300 ARM: OMAP2+: Provide alias to USB PHY clock The attached kernel log seems to suggest that the device tree is picked up by the kernel, but the USB does not seem very active. No ethernet connectivity. This does seem a regression to me. Is there some other patch that I need to get it going again? There are few .dts related patches missing for USB. Roger can point you to the current versions that Benoit should be queueing for the -rc series. Hope Roger or Benoit will chime in. Then for the SDIO with device tree, take a look at the following patches: [PATCH 0/3] WLAN support for omap4 when booted with devicetree http://comments.gmane.org/gmane.linux.ports.arm.omap/97522# The wl12xx .dts changes for pandaboard are still missing too. Then I'll be updating these soonish: [PATCH 0/4] Updated omap_hsmmc SDIO and remuxing patches Those are needed for the SDIO interrupt, SDIO will work also without those. Thanks for the pointers, Arend -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Regression 3.11-rc1: omap4panda: no usb and consequently no ethernet
Hi Arend, On 07/18/2013 11:41 AM, Arend van Spriel wrote: Hi Tony, We are using the panda board (es variant) for testing our SDIO based chips. For this we have an adapter card connection to expansion connector A. As this adapter is not publicly available we had internally patched board-omap4panda.c. Also we follow the -rc releases and use TFTP to boot the kernel image which requires USB. Moving to 3.11-rc1 I found that the mentioned board file was removed by your commit: commit b42b918194c4791510ac049e3d507169a7de8544 Author: Tony Lindgren t...@atomide.com Date: Thu May 30 12:53:05 2013 -0700 ARM: OMAP2+: Remove board-omap4panda.c As our patches on that file are internal I do not hold it against you. This is no regression and we need to fix it. So my first step was to follow the recipe given in that commit. Beside that I noticed a thread about USB issue on LKML so I also applied the following commit: commit 352f573e59050c7a604c35c58b4bbfc51edebbee Author: Roger Quadros rog...@ti.com Date: Tue Jun 18 19:04:47 2013 +0300 ARM: OMAP2+: Provide alias to USB PHY clock The attached kernel log seems to suggest that the device tree is picked up by the kernel, but the USB does not seem very active. No ethernet connectivity. This does seem a regression to me. Is there some other patch that I need to get it going again? I tried with your config and 3.11-rc1 kernel with the above commit on top and ethernet seems to work for me. My boot log is attached. Are you sure that you are building the DTB for panda-es and the bootloader is picking up the right file and not an outdated one? Why is the version of SPL loader and u-boot different in your log? You need to use the MLO file generated by the u-boot build along with the uImage. Just to be sure we are on the same setup could you please try with latest u-boot release (2013-04). Thanks. cheers, -roger U-Boot SPL 2013.04 (Jul 18 2013 - 14:04:55) OMAP4460 ES1.1 OMAP SD/MMC: 0 reading u-boot.img reading u-boot.img U-Boot 2013.04 (Jul 18 2013 - 14:04:55) CPU : OMAP4460 ES1.1 Board: OMAP4 Panda I2C: ready DRAM: 1 GiB MMC: OMAP SD/MMC: 0 Using default environment In:serial Out: serial Err: serial Net: No ethernet found. Hit any key to stop autoboot: 0 mmc0 is current device SD/MMC found on device 0 reading boot.scr 409 bytes read in 3 ms (132.8 KiB/s) Running bootscript from mmc0 ... ## Executing script at 8200 reading omap4-panda.dtb 18588 bytes read in 6 ms (3 MiB/s) reading uImage 3947784 bytes read in 189 ms (19.9 MiB/s) ## Booting kernel from Legacy Image at 8030 ... Image Name: Linux-3.11.0-rc1-1-g4861de4 Image Type: ARM Linux Kernel Image (uncompressed) Data Size:3947720 Bytes = 3.8 MiB Load Address: 80008000 Entry Point: 80008000 Verifying Checksum ... OK ## Flattened Device Tree blob at 825f Booting using the fdt blob at 0x825f Loading Kernel Image ... OK OK Using Device Tree in place at 825f, end 825f789b Starting kernel ... [0.00] Booting Linux on physical CPU 0x0 [0.00] Linux version 3.11.0-rc1-1-g4861de4 (roger@rockdesk) (gcc version 4.7.1 20120531 (prerelease) (crosstool-NG linaro-1.13.1-2012.06-20120625 - Linaro GCC 2012.06) ) #862 SMP Thu Jul 18 14:10:14 EEST 2013 [0.00] CPU: ARMv7 Processor [412fc09a] revision 10 (ARMv7), cr=10c5387d [0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache [0.00] Machine: Generic OMAP4 (Flattened Device Tree), model: TI OMAP4 PandaBoard [0.00] Memory policy: ECC disabled, Data cache writealloc [0.00] On node 0 totalpages: 261888 [0.00] free_area_init_node: node 0, pgdat c07b9500, node_mem_map c0d21000 [0.00] Normal zone: 1520 pages used for memmap [0.00] Normal zone: 0 pages reserved [0.00] Normal zone: 194560 pages, LIFO batch:31 [0.00] HighMem zone: 528 pages used for memmap [0.00] HighMem zone: 67328 pages, LIFO batch:15 [0.00] OMAP4460 ES1.1 [0.00] PERCPU: Embedded 9 pages/cpu @c153b000 s14208 r8192 d14464 u36864 [0.00] pcpu-alloc: s14208 r8192 d14464 u36864 alloc=9*4096 [0.00] pcpu-alloc: [0] 0 [0] 1 [0.00] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 260368 [0.00] Kernel command line: console=ttyO2,115200n8 mem=1G@0x8000 root=/dev/mmcblk0p2 rootwait debug earlyprintk loglevel=8 [0.00] PID hash table entries: 4096 (order: 2, 16384 bytes) [0.00] Dentry cache hash table entries: 131072 (order: 7, 524288 bytes) [0.00] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) [0.00] Memory: 1024916K/1047552K available (5122K kernel code, 558K rwdata, 1860K rodata, 345K init, 5515K bss, 22636K reserved, 269312K highmem) [0.00] Virtual kernel memory layout: [0.00] vector : 0x - 0x1000
Re: Regression 3.11-rc1: omap4panda: no usb and consequently no ethernet
On 07/18/2013 01:18 PM, Roger Quadros wrote: Hi Arend, On 07/18/2013 11:41 AM, Arend van Spriel wrote: Hi Tony, We are using the panda board (es variant) for testing our SDIO based chips. For this we have an adapter card connection to expansion connector A. As this adapter is not publicly available we had internally patched board-omap4panda.c. Also we follow the -rc releases and use TFTP to boot the kernel image which requires USB. Moving to 3.11-rc1 I found that the mentioned board file was removed by your commit: commit b42b918194c4791510ac049e3d507169a7de8544 Author: Tony Lindgren t...@atomide.com Date: Thu May 30 12:53:05 2013 -0700 ARM: OMAP2+: Remove board-omap4panda.c As our patches on that file are internal I do not hold it against you. This is no regression and we need to fix it. So my first step was to follow the recipe given in that commit. Beside that I noticed a thread about USB issue on LKML so I also applied the following commit: commit 352f573e59050c7a604c35c58b4bbfc51edebbee Author: Roger Quadros rog...@ti.com Date: Tue Jun 18 19:04:47 2013 +0300 ARM: OMAP2+: Provide alias to USB PHY clock The attached kernel log seems to suggest that the device tree is picked up by the kernel, but the USB does not seem very active. No ethernet connectivity. This does seem a regression to me. Is there some other patch that I need to get it going again? I tried with your config and 3.11-rc1 kernel with the above commit on top and ethernet seems to work for me. My boot log is attached. Are you sure that you are building the DTB for panda-es and the bootloader is picking up the right file and not an outdated one? I appended the DTB to the kernel image thus avoiding the need to update u-boot (at least that is what I understood from Tony's commit). Why is the version of SPL loader and u-boot different in your log? You need to use the MLO file generated by the u-boot build along with the uImage. Just to be sure we are on the same setup could you please try with latest u-boot release (2013-04). Thanks. I recall having difficulty with TFTP boot using a 2013 u-boot release, but that hurdle is for later. I will try. cheers, -roger Thanks, Arend -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Regression 3.11-rc1: omap4panda: no usb and consequently no ethernet
On 07/18/2013 02:24 PM, Arend van Spriel wrote: On 07/18/2013 01:18 PM, Roger Quadros wrote: Hi Arend, On 07/18/2013 11:41 AM, Arend van Spriel wrote: Hi Tony, We are using the panda board (es variant) for testing our SDIO based chips. For this we have an adapter card connection to expansion connector A. As this adapter is not publicly available we had internally patched board-omap4panda.c. Also we follow the -rc releases and use TFTP to boot the kernel image which requires USB. Moving to 3.11-rc1 I found that the mentioned board file was removed by your commit: commit b42b918194c4791510ac049e3d507169a7de8544 Author: Tony Lindgren t...@atomide.com Date: Thu May 30 12:53:05 2013 -0700 ARM: OMAP2+: Remove board-omap4panda.c As our patches on that file are internal I do not hold it against you. This is no regression and we need to fix it. So my first step was to follow the recipe given in that commit. Beside that I noticed a thread about USB issue on LKML so I also applied the following commit: commit 352f573e59050c7a604c35c58b4bbfc51edebbee Author: Roger Quadros rog...@ti.com Date: Tue Jun 18 19:04:47 2013 +0300 ARM: OMAP2+: Provide alias to USB PHY clock The attached kernel log seems to suggest that the device tree is picked up by the kernel, but the USB does not seem very active. No ethernet connectivity. This does seem a regression to me. Is there some other patch that I need to get it going again? I tried with your config and 3.11-rc1 kernel with the above commit on top and ethernet seems to work for me. My boot log is attached. Are you sure that you are building the DTB for panda-es and the bootloader is picking up the right file and not an outdated one? I appended the DTB to the kernel image thus avoiding the need to update u-boot (at least that is what I understood from Tony's commit). I understand this can be a little tedious at first. This is my u-boot boot.txt fatload mmc 0:1 0x825f omap4-panda-es.dtb fatload mmc 0:1 0x8030 uImage set fdt_high 0x setenv bootargs console=ttyO2,115200n8 mem=1G@0x8000 root=/dev/mmcblk0p2 rootwait bootm 0x8030 - 0x825f You need to generate boot.scr from the above boot.txt and place it in SD card boot partition. mkimage -A arm -T script -C none -n Boot Image -d boot.txt boot.scr And of course copy the omap4-panda-es.dtb to SD card boot partition. hope this helps. Why is the version of SPL loader and u-boot different in your log? You need to use the MLO file generated by the u-boot build along with the uImage. Just to be sure we are on the same setup could you please try with latest u-boot release (2013-04). Thanks. I recall having difficulty with TFTP boot using a 2013 u-boot release, but that hurdle is for later. I will try. OK. We can figure this out as well. cheers, -roger -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Regression 3.11-rc1: omap4panda: no usb and consequently no ethernet
On 07/18/2013 01:30 PM, Roger Quadros wrote: On 07/18/2013 02:24 PM, Arend van Spriel wrote: On 07/18/2013 01:18 PM, Roger Quadros wrote: Hi Arend, On 07/18/2013 11:41 AM, Arend van Spriel wrote: Hi Tony, We are using the panda board (es variant) for testing our SDIO based chips. For this we have an adapter card connection to expansion connector A. As this adapter is not publicly available we had internally patched board-omap4panda.c. Also we follow the -rc releases and use TFTP to boot the kernel image which requires USB. Moving to 3.11-rc1 I found that the mentioned board file was removed by your commit: commit b42b918194c4791510ac049e3d507169a7de8544 Author: Tony Lindgren t...@atomide.com Date: Thu May 30 12:53:05 2013 -0700 ARM: OMAP2+: Remove board-omap4panda.c As our patches on that file are internal I do not hold it against you. This is no regression and we need to fix it. So my first step was to follow the recipe given in that commit. Beside that I noticed a thread about USB issue on LKML so I also applied the following commit: commit 352f573e59050c7a604c35c58b4bbfc51edebbee Author: Roger Quadros rog...@ti.com Date: Tue Jun 18 19:04:47 2013 +0300 ARM: OMAP2+: Provide alias to USB PHY clock The attached kernel log seems to suggest that the device tree is picked up by the kernel, but the USB does not seem very active. No ethernet connectivity. This does seem a regression to me. Is there some other patch that I need to get it going again? I tried with your config and 3.11-rc1 kernel with the above commit on top and ethernet seems to work for me. My boot log is attached. Are you sure that you are building the DTB for panda-es and the bootloader is picking up the right file and not an outdated one? I appended the DTB to the kernel image thus avoiding the need to update u-boot (at least that is what I understood from Tony's commit). I understand this can be a little tedious at first. This is my u-boot boot.txt fatload mmc 0:1 0x825f omap4-panda-es.dtb fatload mmc 0:1 0x8030 uImage set fdt_high 0x setenv bootargs console=ttyO2,115200n8 mem=1G@0x8000 root=/dev/mmcblk0p2 rootwait bootm 0x8030 - 0x825f You need to generate boot.scr from the above boot.txt and place it in SD card boot partition. mkimage -A arm -T script -C none -n Boot Image -d boot.txt boot.scr And of course copy the omap4-panda-es.dtb to SD card boot partition. hope this helps. Thanks for sharing this. Why is the version of SPL loader and u-boot different in your log? You need to use the MLO file generated by the u-boot build along with the uImage. Just to be sure we are on the same setup could you please try with latest u-boot release (2013-04). Thanks. I recall having difficulty with TFTP boot using a 2013 u-boot release, but that hurdle is for later. I will try. OK. We can figure this out as well. I tried with same SPL and u-boot version, but that did not work out. So I moved to v2013.04 and the log looks better. I was especially interested in this: [2.807434] usb 1-1.1: new high-speed USB device number 3 using ehci-omap [2.932495] usb 1-1.1: New USB device found, idVendor=0424, idProduct=ec00 [2.932495] usb 1-1.1: New USB device strings: Mfr=0, Product=0, SerialNumbe0 [2.958770] smsc95xx v1.0.4 Starting logging: OK Initializing random number generator... [3.045806] smsc95xx 1-1.1:1.0 eth0 Regards, Arend -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Regression 3.11-rc1: omap4panda: no usb and consequently no ethernet
On 07/18/2013 03:38 PM, Arend van Spriel wrote: On 07/18/2013 01:30 PM, Roger Quadros wrote: On 07/18/2013 02:24 PM, Arend van Spriel wrote: On 07/18/2013 01:18 PM, Roger Quadros wrote: Hi Arend, On 07/18/2013 11:41 AM, Arend van Spriel wrote: Hi Tony, We are using the panda board (es variant) for testing our SDIO based chips. For this we have an adapter card connection to expansion connector A. As this adapter is not publicly available we had internally patched board-omap4panda.c. Also we follow the -rc releases and use TFTP to boot the kernel image which requires USB. Moving to 3.11-rc1 I found that the mentioned board file was removed by your commit: commit b42b918194c4791510ac049e3d507169a7de8544 Author: Tony Lindgren t...@atomide.com Date: Thu May 30 12:53:05 2013 -0700 ARM: OMAP2+: Remove board-omap4panda.c As our patches on that file are internal I do not hold it against you. This is no regression and we need to fix it. So my first step was to follow the recipe given in that commit. Beside that I noticed a thread about USB issue on LKML so I also applied the following commit: commit 352f573e59050c7a604c35c58b4bbfc51edebbee Author: Roger Quadros rog...@ti.com Date: Tue Jun 18 19:04:47 2013 +0300 ARM: OMAP2+: Provide alias to USB PHY clock The attached kernel log seems to suggest that the device tree is picked up by the kernel, but the USB does not seem very active. No ethernet connectivity. This does seem a regression to me. Is there some other patch that I need to get it going again? I tried with your config and 3.11-rc1 kernel with the above commit on top and ethernet seems to work for me. My boot log is attached. Are you sure that you are building the DTB for panda-es and the bootloader is picking up the right file and not an outdated one? I appended the DTB to the kernel image thus avoiding the need to update u-boot (at least that is what I understood from Tony's commit). I understand this can be a little tedious at first. This is my u-boot boot.txt fatload mmc 0:1 0x825f omap4-panda-es.dtb fatload mmc 0:1 0x8030 uImage set fdt_high 0x setenv bootargs console=ttyO2,115200n8 mem=1G@0x8000 root=/dev/mmcblk0p2 rootwait bootm 0x8030 - 0x825f You need to generate boot.scr from the above boot.txt and place it in SD card boot partition. mkimage -A arm -T script -C none -n Boot Image -d boot.txt boot.scr And of course copy the omap4-panda-es.dtb to SD card boot partition. hope this helps. Thanks for sharing this. Why is the version of SPL loader and u-boot different in your log? You need to use the MLO file generated by the u-boot build along with the uImage. Just to be sure we are on the same setup could you please try with latest u-boot release (2013-04). Thanks. I recall having difficulty with TFTP boot using a 2013 u-boot release, but that hurdle is for later. I will try. OK. We can figure this out as well. I tried with same SPL and u-boot version, but that did not work out. So I moved to v2013.04 and the log looks better. I was especially interested in this: [2.807434] usb 1-1.1: new high-speed USB device number 3 using ehci-omap [2.932495] usb 1-1.1: New USB device found, idVendor=0424, idProduct=ec00 [2.932495] usb 1-1.1: New USB device strings: Mfr=0, Product=0, SerialNumbe0 [2.958770] smsc95xx v1.0.4 Starting logging: OK Initializing random number generator... [3.045806] smsc95xx 1-1.1:1.0 eth0 Cool! :). FYI. I also tested tftpboot from u-boot and NFS root file system and it works fine. cheers, -roger -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
