* [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 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.