* [U-Boot] Are mmc open/close subcommands needed?
@ 2014-01-02 16:53 Hector Palacios
2014-01-02 23:36 ` Marek Vasut
0 siblings, 1 reply; 5+ messages in thread
From: Hector Palacios @ 2014-01-02 16:53 UTC (permalink / raw)
To: u-boot
Hi,
I saw commit 2a91c9134675140853577b565210458b5774e6cf that introduces mmc subcommands
'open' and 'close' to access eMMC boot partitions and was wondering if they are really
needed. Can't the same be achieved with already existing 'mmc dev [dev] [part]' command?
mmc open <dev> <boot_partition>
is the same as
mmc dev <dev> <part>
where <part> is the boot partition
mmc close <dev> <boot_partition>
is the same as
mmc dev <dev> 0
as a 0 will switch to partition 0 (user data).
Best regards,
--
Hector Palacios
^ permalink raw reply [flat|nested] 5+ messages in thread
* [U-Boot] Are mmc open/close subcommands needed?
2014-01-02 16:53 [U-Boot] Are mmc open/close subcommands needed? Hector Palacios
@ 2014-01-02 23:36 ` Marek Vasut
2014-01-03 17:35 ` Otavio Salvador
0 siblings, 1 reply; 5+ messages in thread
From: Marek Vasut @ 2014-01-02 23:36 UTC (permalink / raw)
To: u-boot
On Thursday, January 02, 2014 at 05:53:00 PM, Hector Palacios wrote:
> Hi,
>
> I saw commit 2a91c9134675140853577b565210458b5774e6cf that introduces mmc
> subcommands 'open' and 'close' to access eMMC boot partitions and was
> wondering if they are really needed. Can't the same be achieved with
> already existing 'mmc dev [dev] [part]' command?
>
> mmc open <dev> <boot_partition>
> is the same as
> mmc dev <dev> <part>
> where <part> is the boot partition
>
> mmc close <dev> <boot_partition>
> is the same as
> mmc dev <dev> 0
> as a 0 will switch to partition 0 (user data).
>
> Best regards,
> --
> Hector Palacios
+CC Panto
Best regards,
Marek Vasut
^ permalink raw reply [flat|nested] 5+ messages in thread
* [U-Boot] Are mmc open/close subcommands needed?
2014-01-02 23:36 ` Marek Vasut
@ 2014-01-03 17:35 ` Otavio Salvador
2014-01-07 7:47 ` Hector Palacios
0 siblings, 1 reply; 5+ messages in thread
From: Otavio Salvador @ 2014-01-03 17:35 UTC (permalink / raw)
To: u-boot
On Thu, Jan 2, 2014 at 9:36 PM, Marek Vasut <marex@denx.de> wrote:
> On Thursday, January 02, 2014 at 05:53:00 PM, Hector Palacios wrote:
>> Hi,
>>
>> I saw commit 2a91c9134675140853577b565210458b5774e6cf that introduces mmc
>> subcommands 'open' and 'close' to access eMMC boot partitions and was
>> wondering if they are really needed. Can't the same be achieved with
>> already existing 'mmc dev [dev] [part]' command?
>>
>> mmc open <dev> <boot_partition>
>> is the same as
>> mmc dev <dev> <part>
>> where <part> is the boot partition
>>
>> mmc close <dev> <boot_partition>
>> is the same as
>> mmc dev <dev> 0
>> as a 0 will switch to partition 0 (user data).
>>
>> Best regards,
>> --
>> Hector Palacios
>
> +CC Panto
No; this is for different use.
The open and close are to open the Boot partitions part of eMMC 4; by
default those eMMC will be using the user partitions, not the boot
area.
The nice, and confusing thing, is that those boot partitions also
start in address 0 as a 'virtual disk'.
--
Otavio Salvador O.S. Systems
http://www.ossystems.com.br http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854 Mobile: +1 (347) 903-9750
^ permalink raw reply [flat|nested] 5+ messages in thread
* [U-Boot] Are mmc open/close subcommands needed?
2014-01-03 17:35 ` Otavio Salvador
@ 2014-01-07 7:47 ` Hector Palacios
2014-01-09 8:45 ` Jaehoon Chung
0 siblings, 1 reply; 5+ messages in thread
From: Hector Palacios @ 2014-01-07 7:47 UTC (permalink / raw)
To: u-boot
Dear Otavio,
On 01/03/2014 06:35 PM, Otavio Salvador wrote:
> On Thu, Jan 2, 2014 at 9:36 PM, Marek Vasut <marex@denx.de> wrote:
>> On Thursday, January 02, 2014 at 05:53:00 PM, Hector Palacios wrote:
>>> Hi,
>>>
>>> I saw commit 2a91c9134675140853577b565210458b5774e6cf that introduces mmc
>>> subcommands 'open' and 'close' to access eMMC boot partitions and was
>>> wondering if they are really needed. Can't the same be achieved with
>>> already existing 'mmc dev [dev] [part]' command?
>>>
>>> mmc open <dev> <boot_partition>
>>> is the same as
>>> mmc dev <dev> <part>
>>> where <part> is the boot partition
>>>
>>> mmc close <dev> <boot_partition>
>>> is the same as
>>> mmc dev <dev> 0
>>> as a 0 will switch to partition 0 (user data).
>>>
>>> Best regards,
>>> --
>>> Hector Palacios
>>
>> +CC Panto
>
> No; this is for different use.
>
> The open and close are to open the Boot partitions part of eMMC 4; by
> default those eMMC will be using the user partitions, not the boot
> area.
>
> The nice, and confusing thing, is that those boot partitions also
> start in address 0 as a 'virtual disk'.
I don't think they are different commands that do the same by coincidence. The 'mmc
dev' command, when passed a fourth argument for the partition is calling the function
'mmc_switch_part()'.
This function executes the CMD6 command to write the Extended CSD register
PARTITION_CONFIG field that gives you access to any MMC partition (user data area,
boot partitions 1 and 2, RPMB, General Purpose 1-4 partitions).
It doesn't look like specific eMMC commands are needed to access the boot partitions,
but maybe I'm misinterpreting the code.
Best regards,
--
Hector Palacios
^ permalink raw reply [flat|nested] 5+ messages in thread
* [U-Boot] Are mmc open/close subcommands needed?
2014-01-07 7:47 ` Hector Palacios
@ 2014-01-09 8:45 ` Jaehoon Chung
0 siblings, 0 replies; 5+ messages in thread
From: Jaehoon Chung @ 2014-01-09 8:45 UTC (permalink / raw)
To: u-boot
On 01/07/2014 04:47 PM, Hector Palacios wrote:
> Dear Otavio,
>
> On 01/03/2014 06:35 PM, Otavio Salvador wrote:
>> On Thu, Jan 2, 2014 at 9:36 PM, Marek Vasut <marex@denx.de> wrote:
>>> On Thursday, January 02, 2014 at 05:53:00 PM, Hector Palacios wrote:
>>>> Hi,
>>>>
>>>> I saw commit 2a91c9134675140853577b565210458b5774e6cf that introduces mmc
>>>> subcommands 'open' and 'close' to access eMMC boot partitions and was
>>>> wondering if they are really needed. Can't the same be achieved with
>>>> already existing 'mmc dev [dev] [part]' command?
>>>>
>>>> mmc open <dev> <boot_partition>
>>>> is the same as
>>>> mmc dev <dev> <part>
>>>> where <part> is the boot partition
>>>>
>>>> mmc close <dev> <boot_partition>
>>>> is the same as
>>>> mmc dev <dev> 0
>>>> as a 0 will switch to partition 0 (user data).
>>>>
>>>> Best regards,
>>>> --
>>>> Hector Palacios
>>>
>>> +CC Panto
>>
>> No; this is for different use.
>>
>> The open and close are to open the Boot partitions part of eMMC 4; by
>> default those eMMC will be using the user partitions, not the boot
>> area.
>>
>> The nice, and confusing thing, is that those boot partitions also
>> start in address 0 as a 'virtual disk'.
>
> I don't think they are different commands that do the same by coincidence. The 'mmc dev' command, when passed a fourth argument for the partition is calling the function 'mmc_switch_part()'.
> This function executes the CMD6 command to write the Extended CSD register PARTITION_CONFIG field that gives you access to any MMC partition (user data area, boot partitions 1 and 2, RPMB, General Purpose 1-4 partitions).
>
> It doesn't look like specific eMMC commands are needed to access the boot partitions, but maybe I'm misinterpreting the code.
Well, I think also your opinion. This code is the same behavior.
I didn't find any difference...
Best Regard,
Jaehoon Chung
>
> Best regards,
> --
> Hector Palacios
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
>
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2014-01-09 8:45 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2014-01-02 16:53 [U-Boot] Are mmc open/close subcommands needed? Hector Palacios
2014-01-02 23:36 ` Marek Vasut
2014-01-03 17:35 ` Otavio Salvador
2014-01-07 7:47 ` Hector Palacios
2014-01-09 8:45 ` Jaehoon Chung
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).