From: Lokesh Vutla <a0131933@ti.com>
To: hs@denx.de
Cc: linux-kernel@vger.kernel.org, Arnd Bergmann <arnd@arndb.de>,
linux-mmc@vger.kernel.org, Dirk Behme <dirk.behme@bosch.com>,
Georg.Soffel@bosch-si.com, linux-omap@vger.kernel.org,
Ulf Hansson <ulf.hansson@linaro.org>,
"Menon, Nishanth" <nm@ti.com>
Subject: Re: [PATCH] mmc: omap_hsmmc: fix initialization order of mmc block devices
Date: Tue, 13 Oct 2015 13:33:47 +0530 [thread overview]
Message-ID: <561CBAE3.3020707@ti.com> (raw)
In-Reply-To: <561CB653.5020707@denx.de>
On Tuesday 13 October 2015 01:14 PM, Heiko Schocher wrote:
> Hello Lokesh,
>
> Am 13.10.2015 um 08:46 schrieb Lokesh Vutla:
>> +Nishanth,
>>
>> On Tuesday 13 October 2015 10:59 AM, Heiko Schocher wrote:
>>> On embedded devices, often there is a combination of
>>> removable mmc devices (e.g. MMC/SD cards) and hard
>>> wired ones (e.g. eMMC). Depending on the hardware
>>> configuration, the 'mmcblkN' node might change if
>>> the removable device is available or not at boot time.
>>>
>>> E.g. if the removable device is attached at boot time,
>>> it might become mmxblk0. And the hard wired one mmcblk1.
>>> But if the removable device isn't there at boot time,
>>> the hard wired one will become mmcblk0. This makes it
>>> somehow difficult to hard code the root device to the
>>> non-removable device and boot fast.
>>
>> Why not use "root=PARTUUID=${uuid}" option instead of relying on
>> mmcblk no?
>> U-Boot can easily detect your partuuid. Refer to [1] on how TI platforms
>> does this in u-boot.
>
> Good tip ... I do not know, if it is possible to update U-Boot
> on this boards...
>
> Current U-Boot says:
> U-Boot 2013.01.01_heads/master-gc7900a0 (2015-05-06 - 20:37:15)
>
> I2C: ready
> DRAM: 512 MiB
> [...]
> U-Boot# mmc rescan
> U-Boot# mmc part
>
> Partition Map for MMC device 0 -- Partition Type: DOS
>
> Part Start Sector Num Sectors UUID Type
> 1 63 144522 000ce343-01 0e Boot
> 2 144585 659861 000ce343-02 83
> U-Boot# part uuid mmc 0:2 uuid
> Unknown command 'part' - try 'help'
> U-Boot#
>
> So, if this patch has no chance for mainline, please let me
> know it, thanks!
>
IIRC, Nishanth had posted a patch something similar but got rejected for
some reason. Probably Nishanth can comment more here.
Thanks and regards,
Lokesh
WARNING: multiple messages have this Message-ID (diff)
From: Lokesh Vutla <a0131933@ti.com>
To: <hs@denx.de>
Cc: <linux-kernel@vger.kernel.org>, Arnd Bergmann <arnd@arndb.de>,
<linux-mmc@vger.kernel.org>, Dirk Behme <dirk.behme@bosch.com>,
<Georg.Soffel@bosch-si.com>, <linux-omap@vger.kernel.org>,
Ulf Hansson <ulf.hansson@linaro.org>,
"Menon, Nishanth" <nm@ti.com>
Subject: Re: [PATCH] mmc: omap_hsmmc: fix initialization order of mmc block devices
Date: Tue, 13 Oct 2015 13:33:47 +0530 [thread overview]
Message-ID: <561CBAE3.3020707@ti.com> (raw)
In-Reply-To: <561CB653.5020707@denx.de>
On Tuesday 13 October 2015 01:14 PM, Heiko Schocher wrote:
> Hello Lokesh,
>
> Am 13.10.2015 um 08:46 schrieb Lokesh Vutla:
>> +Nishanth,
>>
>> On Tuesday 13 October 2015 10:59 AM, Heiko Schocher wrote:
>>> On embedded devices, often there is a combination of
>>> removable mmc devices (e.g. MMC/SD cards) and hard
>>> wired ones (e.g. eMMC). Depending on the hardware
>>> configuration, the 'mmcblkN' node might change if
>>> the removable device is available or not at boot time.
>>>
>>> E.g. if the removable device is attached at boot time,
>>> it might become mmxblk0. And the hard wired one mmcblk1.
>>> But if the removable device isn't there at boot time,
>>> the hard wired one will become mmcblk0. This makes it
>>> somehow difficult to hard code the root device to the
>>> non-removable device and boot fast.
>>
>> Why not use "root=PARTUUID=${uuid}" option instead of relying on
>> mmcblk no?
>> U-Boot can easily detect your partuuid. Refer to [1] on how TI platforms
>> does this in u-boot.
>
> Good tip ... I do not know, if it is possible to update U-Boot
> on this boards...
>
> Current U-Boot says:
> U-Boot 2013.01.01_heads/master-gc7900a0 (2015-05-06 - 20:37:15)
>
> I2C: ready
> DRAM: 512 MiB
> [...]
> U-Boot# mmc rescan
> U-Boot# mmc part
>
> Partition Map for MMC device 0 -- Partition Type: DOS
>
> Part Start Sector Num Sectors UUID Type
> 1 63 144522 000ce343-01 0e Boot
> 2 144585 659861 000ce343-02 83
> U-Boot# part uuid mmc 0:2 uuid
> Unknown command 'part' - try 'help'
> U-Boot#
>
> So, if this patch has no chance for mainline, please let me
> know it, thanks!
>
IIRC, Nishanth had posted a patch something similar but got rejected for
some reason. Probably Nishanth can comment more here.
Thanks and regards,
Lokesh
next prev parent reply other threads:[~2015-10-13 8:03 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-10-13 5:29 [PATCH] mmc: omap_hsmmc: fix initialization order of mmc block devices Heiko Schocher
2015-10-13 6:46 ` Lokesh Vutla
2015-10-13 6:46 ` Lokesh Vutla
2015-10-13 7:44 ` Heiko Schocher
2015-10-13 8:03 ` Lokesh Vutla [this message]
2015-10-13 8:03 ` Lokesh Vutla
2015-10-13 13:24 ` Nishanth Menon
2015-10-13 13:24 ` [U-Boot] " Nishanth Menon
2015-10-13 14:00 ` Tom Rini
2015-10-13 14:00 ` [U-Boot] " Tom Rini
2015-10-13 13:59 ` Dirk Behme
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=561CBAE3.3020707@ti.com \
--to=a0131933@ti.com \
--cc=Georg.Soffel@bosch-si.com \
--cc=arnd@arndb.de \
--cc=dirk.behme@bosch.com \
--cc=hs@denx.de \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mmc@vger.kernel.org \
--cc=linux-omap@vger.kernel.org \
--cc=nm@ti.com \
--cc=ulf.hansson@linaro.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.