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 <[email protected]>
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 <[email protected]>
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?
Regards,
Arend
* Arend van Spriel <[email protected]> [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 <[email protected]>
> 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 <[email protected]>
> 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
On 07/18/2013 10:59 AM, Tony Lindgren wrote:
> * Arend van Spriel <[email protected]> [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 <[email protected]>
>> 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
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 <[email protected]>
> 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 <[email protected]>
> 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
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 <[email protected]>
>> 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 <[email protected]>
>> 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
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 <[email protected]>
>>> 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 <[email protected]>
>>> 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 0x825f0000 omap4-panda-es.dtb
fatload mmc 0:1 0x80300000 uImage
set fdt_high 0xffffffff
setenv bootargs console=ttyO2,115200n8 mem=1G@0x80000000 root=/dev/mmcblk0p2 rootwait
bootm 0x80300000 - 0x825f0000
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
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 <[email protected]>
>>>> 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 <[email protected]>
>>>> 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 0x825f0000 omap4-panda-es.dtb
> fatload mmc 0:1 0x80300000 uImage
> set fdt_high 0xffffffff
> setenv bootargs console=ttyO2,115200n8 mem=1G@0x80000000 root=/dev/mmcblk0p2 rootwait
> bootm 0x80300000 - 0x825f0000
>
> 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
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 <[email protected]>
>>>>> 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 <[email protected]>
>>>>> 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 0x825f0000 omap4-panda-es.dtb
>> fatload mmc 0:1 0x80300000 uImage
>> set fdt_high 0xffffffff
>> setenv bootargs console=ttyO2,115200n8 mem=1G@0x80000000 root=/dev/mmcblk0p2 rootwait
>> bootm 0x80300000 - 0x825f0000
>>
>> 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
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),
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_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.
>
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
* Arend van Spriel <[email protected]> [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
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_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.
>>
>
> 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
On Thu, 2013-07-18 at 01:59 -0700, Tony Lindgren wrote:
> * Arend van Spriel <[email protected]> [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.
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 <[email protected]>
>>>>>> 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 <[email protected]>
>>>>>> 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 0x825f0000 omap4-panda-es.dtb
>>> fatload mmc 0:1 0x80300000 uImage
>>> set fdt_high 0xffffffff
>>> setenv bootargs console=ttyO2,115200n8 mem=1G@0x80000000 root=/dev/mmcblk0p2 rootwait
>>> bootm 0x80300000 - 0x825f0000
>>>
>>> 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
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 <[email protected]>
>>>>>>> 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 <[email protected]>
>>>>>>> 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 0x825f0000 omap4-panda-es.dtb
>>>> fatload mmc 0:1 0x80300000 uImage
>>>> set fdt_high 0xffffffff
>>>> setenv bootargs console=ttyO2,115200n8 mem=1G@0x80000000
>>>> root=/dev/mmcblk0p2 rootwait
>>>> bootm 0x80300000 - 0x825f0000
>>>>
>>>> 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 Foundation 1.1 root hub
Bus 001 Device 003: ID 0424:ec00 Standard Microsystems Corp.
bash-4.2# ls /sys/bus/usb/devices/
1-0:1.0 1-1 1-1.1 1-1.1:1.0 1-1:1.0 2-0:1.0 usb1
usb2
> 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.
I am tftp'ing kernel over USB network. I think U-boot shouldn't have
anything to do with Kernel USB though. If it does, then its a bug.
Hope this helps, Thanks,
-Joel
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
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
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
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
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
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
>
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
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
>
>
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_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.
>>>
>>
>> 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
>
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_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.
>>>>
>>>
>>> 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
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_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.
>>>>>
>>>>
>>>> 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
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_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.
>>>>>>
>>>>>
>>>>> 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
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_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.
> >>>>>>
> >>>>>
> >>>>> 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.
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_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.
>>>>>>>
>>>>>>
>>>>>> 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
>>>>> 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 [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
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 [email protected]
>> 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 [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
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_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.
>>>>>>>>
>>>>>>>
>>>>>>> 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
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_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.
> >>>>>>>>
> >>>>>>>
> >>>>>>> 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/[email protected]
--
Luca.