Re: [U-Boot] [PATCH v3 5/7] dfu:cmd: Support for DFU u-boot command
Dear Stephen Warren, On 08/03/2012 12:13 AM, Lukasz Majewski wrote: Dear Stephen Warren, Again, this is confusing two different kinds of partitions. There are HW-level partitions/regions/areas within the eMMC HW itself. You need to send commands to the eMMC device to select whether read/write commands act on the boot0/boot1/general*/user HW partition. This will be done via mmc boot [dev] [HW partition (boot0/1/user] command (from u-boot prompt). Hmm. I still fail to see how this is any different to the existing mmc dev command. Are the following two commands not exactly identical: mmc dev $dev $part # already exists today mmc boot $dev $part # new command you're proposing ? You are totally right the $part part is the thing I'm looking for. I had in mind a previous version of mmc dev command with only the $dev part. As I can see in the code - the mmc_switch() call does exactly the things that I need :-) This command is not yet implemented at u-boot (at least for Trats development board). After its implementation it will be used as a helper function for dfu. -- Best regards, Lukasz Majewski Samsung Poland RD Center | Linux Platform Group ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 5/7] dfu:cmd: Support for DFU u-boot command
Dear Stephen Warren, Again, this is confusing two different kinds of partitions. There are HW-level partitions/regions/areas within the eMMC HW itself. You need to send commands to the eMMC device to select whether read/write commands act on the boot0/boot1/general*/user HW partition. This will be done via mmc boot [dev] [HW partition (boot0/1/user] command (from u-boot prompt). This command is not yet implemented at u-boot (at least for Trats development board). After its implementation it will be used as a helper function for dfu. As a result the access to those partition will be done via proper DFU's alt settings: mmc-boot0 mmc-boot1 etc. There are (or can be) SW-level partitions within any/all of those HW partitions. This is the level at which an MBR/GPT partition would exist. With DFU, I'd expect an alt setting for each of the HW partitions at least. And this is my goal. Now only the user HW partition is supported. After mmc boot ... command implementation support for other partitions will be added for DFU as well. With UMS, I'd expect a device to appear for each of the HW partitions. (these may show up as say /dev/sdb for boot0, /dev/sdc for boot1, /dev/sdd for the user area). Frankly speaking I've thought of providing access only to user HW partition for initial UMS implementation (the UMS v1 implementation). However access to all HW partitions from UMS is worth consideration. If an MBR/GPT is present within any of those, Linux may then create a device for each SW partition, so e.g. /dev/sdd1, /dev/sdd2, etc. This is the functionality which now UMS (v1) provides. -- Best regards, Lukasz Majewski Samsung Poland RD Center | Linux Platform Group ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 5/7] dfu:cmd: Support for DFU u-boot command
On 08/03/2012 12:13 AM, Lukasz Majewski wrote: Dear Stephen Warren, Again, this is confusing two different kinds of partitions. There are HW-level partitions/regions/areas within the eMMC HW itself. You need to send commands to the eMMC device to select whether read/write commands act on the boot0/boot1/general*/user HW partition. This will be done via mmc boot [dev] [HW partition (boot0/1/user] command (from u-boot prompt). Hmm. I still fail to see how this is any different to the existing mmc dev command. Are the following two commands not exactly identical: mmc dev $dev $part # already exists today mmc boot $dev $part # new command you're proposing ? This command is not yet implemented at u-boot (at least for Trats development board). After its implementation it will be used as a helper function for dfu. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 5/7] dfu:cmd: Support for DFU u-boot command
Dear Mike Frysinger, On Tuesday 31 July 2012 02:37:01 Lukasz Majewski wrote: --- /dev/null +++ b/common/cmd_dfu.c + static char *s = dfu; no need for this to be static It can be pulled out of the function and be made into const static -mike Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 5/7] dfu:cmd: Support for DFU u-boot command
On Wed, 01 Aug 2012 11:13:14 -0600 Stephen Warren swar...@wwwdotorg.org wrote: On 08/01/2012 01:16 AM, Lukasz Majewski wrote: Hi Stephen Warren, On 07/31/2012 12:37 AM, Lukasz Majewski wrote: Support for u-boot's dfu interface dev [list] command. +U_BOOT_CMD(dfu, CONFIG_SYS_MAXARGS, 1, do_dfu, + Device Firmware Upgrade, + interface dev [list]\n + - device firmware upgrade on a device dev\n + attached to interface interface\n + [list] - list available alt settings +); ... Somewhat related to this, it looks like the eMMC support doesn't allow the HW partition to be specified; it would be nice to expose alt settings for all of: a) Each individual HW partition (boot0/1 if present, general0/1/2/3 if present, the user area, maybe the replay block) I'm fully aware of this problem. In the eMMC case, the access to boot partitions will be served by defining special alt settings for DFU. Those altsettings will be defined as follows: -a[N] boot0 -a[N+1] boot1 Prerequisite for this functionality is support of boot command, which will allow switching of the MMC available address spaces (e.g. between boot0/boot1 and user accessible space). Is this boot command a DFU protocol command, or a U-Boot command-line command? I note that the U-Boot command-line already allows HW partition selection using an additional parameter to mmc - mmc dev $mmc_device_id $partition_id. I'm rather thinking of a U-boot command (as it is easier to integrate). The command would be mmc boot dev params .. boot partition Although it is not yet implemented, it is on the top of mine TO DO list :-). b) Perhaps also a linearized view of the raw eMMC (LBAs 0..boot_size-1 write to boot 0, LBAs boot_size..(2*boot_size)-1 write to boot1, LBAs 2*boot_size..end_of_device write to user area for example). Access to partitions will be done differently. I assume that each eMMC memory (the user accessible part) will be equipped with MBR or GPT definition. That's a different kind of partition though. In general, there's no need for the eMMC device to contain any kind of standardized SW-level partition table. On Tegra, the boot ROM can boot directly from an eMMC device, and that requires raw data in the partitions, not a standardized SW partition table. For this reason I'm now developing the USB Mass Storage (UMS) gadget to export eMMC to host PC. This solves the problem with accessing separate partitions. OK, if the raw eMMC device is exposed using USB storage, we should be able to dd directly to it and the presence-or-lack-thereof of any MBR/GPT wouldn't even be relevant. With the UMS you would see the whole mmc address space as one partition. Then you can use dd with several parameters to dump data to a specific LBA address. When correct MBR or GPT is present, then we can specify partitions to be accessed. It'd still be useful to have a linearized view of the flash that concatenated all the HW partitions into a single raw device, but I guess an alt setting for that probably could be added later. I think that UMS solves this issue. However, correct me if I'm wrong. Let's assume, that UMS causes host to see following partitions: sde: sde1 sde2 sde3 sde4 sde5 .. sdeN Is the mount -t vfat /dev/sde /mnt not allowing access to the whole eMMC device (despite of the partitions)? Please also be aware, that DFU shall be used only for relatively small files (due to small EP0 bandwidth). Large files shall be copied with UMS. Oh, didn't know that. Just out of curiosity, are you thinking of implementing that too? The USB Mass Storage gadget is now working with the g_dnl composite gadget as a f_ums function. Unfortunately it is not polished enough to be posted to ML. I'd prefer that DFU related patches would be pulled to ML first. Afterwards I would post the UMS function. -- Best regards, Lukasz Majewski Samsung Poland RD Center | Linux Platform Group ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 5/7] dfu:cmd: Support for DFU u-boot command
Dear Marek Vasut, Dear Mike Frysinger, On Tuesday 31 July 2012 02:37:01 Lukasz Majewski wrote: --- /dev/null +++ b/common/cmd_dfu.c + static char *s = dfu; no need for this to be static It can be pulled out of the function and be made into const static Ok. -mike Best regards, Marek Vasut -- Best regards, Lukasz Majewski Samsung Poland RD Center | Linux Platform Group ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 5/7] dfu:cmd: Support for DFU u-boot command
On 08/02/2012 02:31 AM, Lukasz Majewski wrote: On Wed, 01 Aug 2012 11:13:14 -0600 Stephen Warren swar...@wwwdotorg.org wrote: On 08/01/2012 01:16 AM, Lukasz Majewski wrote: Hi Stephen Warren, On 07/31/2012 12:37 AM, Lukasz Majewski wrote: Support for u-boot's dfu interface dev [list] command. +U_BOOT_CMD(dfu, CONFIG_SYS_MAXARGS, 1, do_dfu, + Device Firmware Upgrade, + interface dev [list]\n + - device firmware upgrade on a device dev\n + attached to interface interface\n + [list] - list available alt settings +); ... Somewhat related to this, it looks like the eMMC support doesn't allow the HW partition to be specified; it would be nice to expose alt settings for all of: a) Each individual HW partition (boot0/1 if present, general0/1/2/3 if present, the user area, maybe the replay block) I'm fully aware of this problem. In the eMMC case, the access to boot partitions will be served by defining special alt settings for DFU. Those altsettings will be defined as follows: -a[N] boot0 -a[N+1] boot1 Prerequisite for this functionality is support of boot command, which will allow switching of the MMC available address spaces (e.g. between boot0/boot1 and user accessible space). Is this boot command a DFU protocol command, or a U-Boot command-line command? I note that the U-Boot command-line already allows HW partition selection using an additional parameter to mmc - mmc dev $mmc_device_id $partition_id. I'm rather thinking of a U-boot command (as it is easier to integrate). The command would be mmc boot dev params .. boot partition Although it is not yet implemented, it is on the top of mine TO DO list :-). I guess I'm confused what that boot command would actually do then... The only thing I can think that it might do is already covered by the mmc command's partition parameter. b) Perhaps also a linearized view of the raw eMMC (LBAs 0..boot_size-1 write to boot 0, LBAs boot_size..(2*boot_size)-1 write to boot1, LBAs 2*boot_size..end_of_device write to user area for example). Access to partitions will be done differently. I assume that each eMMC memory (the user accessible part) will be equipped with MBR or GPT definition. That's a different kind of partition though. In general, there's no need for the eMMC device to contain any kind of standardized SW-level partition table. On Tegra, the boot ROM can boot directly from an eMMC device, and that requires raw data in the partitions, not a standardized SW partition table. For this reason I'm now developing the USB Mass Storage (UMS) gadget to export eMMC to host PC. This solves the problem with accessing separate partitions. OK, if the raw eMMC device is exposed using USB storage, we should be able to dd directly to it and the presence-or-lack-thereof of any MBR/GPT wouldn't even be relevant. With the UMS you would see the whole mmc address space as one partition. Then you can use dd with several parameters to dump data to a specific LBA address. When correct MBR or GPT is present, then we can specify partitions to be accessed. It'd still be useful to have a linearized view of the flash that concatenated all the HW partitions into a single raw device, but I guess an alt setting for that probably could be added later. I think that UMS solves this issue. However, correct me if I'm wrong. Let's assume, that UMS causes host to see following partitions: sde: sde1 sde2 sde3 sde4 sde5 .. sdeN Is the mount -t vfat /dev/sde /mnt not allowing access to the whole eMMC device (despite of the partitions)? Again, this is confusing two different kinds of partitions. There are HW-level partitions/regions/areas within the eMMC HW itself. You need to send commands to the eMMC device to select whether read/write commands act on the boot0/boot1/general*/user HW partition. There are (or can be) SW-level partitions within any/all of those HW partitions. This is the level at which an MBR/GPT partition would exist. With DFU, I'd expect an alt setting for each of the HW partitions at least. With UMS, I'd expect a device to appear for each of the HW partitions. (these may show up as say /dev/sdb for boot0, /dev/sdc for boot1, /dev/sdd for the user area). If an MBR/GPT is present within any of those, Linux may then create a device for each SW partition, so e.g. /dev/sdd1, /dev/sdd2, etc. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 5/7] dfu:cmd: Support for DFU u-boot command
On Thursday 02 August 2012 03:16:18 Marek Vasut wrote: Dear Mike Frysinger, On Tuesday 31 July 2012 02:37:01 Lukasz Majewski wrote: --- /dev/null +++ b/common/cmd_dfu.c + static char *s = dfu; no need for this to be static It can be pulled out of the function and be made into const static err, there's no point. the static markings here are for the pointer s, not the stuff it's pointing to dfu. use: char s[] = dfu; and it'll probably all optimize away correctly -mike signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 5/7] dfu:cmd: Support for DFU u-boot command
Hi Stephen Warren, On 07/31/2012 12:37 AM, Lukasz Majewski wrote: Support for u-boot's dfu interface dev [list] command. +U_BOOT_CMD(dfu, CONFIG_SYS_MAXARGS, 1, do_dfu, + Device Firmware Upgrade, + interface dev [list]\n + - device firmware upgrade on a device dev\n + attached to interface interface\n + [list] - list available alt settings +); Hmm. Is there any way to make this work without specifying interface dev, or to allow specifying multiple interface dev entries? On a system with all of eMMC, NAND, and SPI, I'd like to just run dfu as the U-Boot command, and have the host specify which of those devices it wants to download to using the DFU protocol. So, if flashing a bunch of devices, there is no need to interact with U-Boot over both serial and USB in order to invoke the dfu command multiple times. It would be possible by specifying proper altsettings e.g.: a1 mmc-boot a2 mmc-uImage a3 nand-part0 a4 nand-part1 etc. However, I think that for the start, the approach proposed here (as dfu mmc 0 command call) is sufficient. This approach is used with several file systems calls (e.g. fatload mmc ... , fatwrite mmc ... etc.) and in my opinion it is consistent. Somewhat related to this, it looks like the eMMC support doesn't allow the HW partition to be specified; it would be nice to expose alt settings for all of: a) Each individual HW partition (boot0/1 if present, general0/1/2/3 if present, the user area, maybe the replay block) I'm fully aware of this problem. In the eMMC case, the access to boot partitions will be served by defining special alt settings for DFU. Those altsettings will be defined as follows: -a[N] boot0 -a[N+1] boot1 Prerequisite for this functionality is support of boot command, which will allow switching of the MMC available address spaces (e.g. between boot0/boot1 and user accessible space). b) Perhaps also a linearized view of the raw eMMC (LBAs 0..boot_size-1 write to boot 0, LBAs boot_size..(2*boot_size)-1 write to boot1, LBAs 2*boot_size..end_of_device write to user area for example). Access to partitions will be done differently. I assume that each eMMC memory (the user accessible part) will be equipped with MBR or GPT definition. For this reason I'm now developing the USB Mass Storage (UMS) gadget to export eMMC to host PC. This solves the problem with accessing separate partitions. Please also be aware, that DFU shall be used only for relatively small files (due to small EP0 bandwidth). Large files shall be copied with UMS. -- Best regards, Lukasz Majewski Samsung Poland RD Center | Linux Platform Group ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 5/7] dfu:cmd: Support for DFU u-boot command
On 08/01/2012 01:16 AM, Lukasz Majewski wrote: Hi Stephen Warren, On 07/31/2012 12:37 AM, Lukasz Majewski wrote: Support for u-boot's dfu interface dev [list] command. +U_BOOT_CMD(dfu, CONFIG_SYS_MAXARGS, 1, do_dfu, + Device Firmware Upgrade, + interface dev [list]\n + - device firmware upgrade on a device dev\n + attached to interface interface\n + [list] - list available alt settings +); ... Somewhat related to this, it looks like the eMMC support doesn't allow the HW partition to be specified; it would be nice to expose alt settings for all of: a) Each individual HW partition (boot0/1 if present, general0/1/2/3 if present, the user area, maybe the replay block) I'm fully aware of this problem. In the eMMC case, the access to boot partitions will be served by defining special alt settings for DFU. Those altsettings will be defined as follows: -a[N] boot0 -a[N+1] boot1 Prerequisite for this functionality is support of boot command, which will allow switching of the MMC available address spaces (e.g. between boot0/boot1 and user accessible space). Is this boot command a DFU protocol command, or a U-Boot command-line command? I note that the U-Boot command-line already allows HW partition selection using an additional parameter to mmc - mmc dev $mmc_device_id $partition_id. b) Perhaps also a linearized view of the raw eMMC (LBAs 0..boot_size-1 write to boot 0, LBAs boot_size..(2*boot_size)-1 write to boot1, LBAs 2*boot_size..end_of_device write to user area for example). Access to partitions will be done differently. I assume that each eMMC memory (the user accessible part) will be equipped with MBR or GPT definition. That's a different kind of partition though. In general, there's no need for the eMMC device to contain any kind of standardized SW-level partition table. On Tegra, the boot ROM can boot directly from an eMMC device, and that requires raw data in the partitions, not a standardized SW partition table. For this reason I'm now developing the USB Mass Storage (UMS) gadget to export eMMC to host PC. This solves the problem with accessing separate partitions. OK, if the raw eMMC device is exposed using USB storage, we should be able to dd directly to it and the presence-or-lack-thereof of any MBR/GPT wouldn't even be relevant. It'd still be useful to have a linearized view of the flash that concatenated all the HW partitions into a single raw device, but I guess an alt setting for that probably could be added later. Please also be aware, that DFU shall be used only for relatively small files (due to small EP0 bandwidth). Large files shall be copied with UMS. Oh, didn't know that. Just out of curiosity, are you thinking of implementing that too? ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 5/7] dfu:cmd: Support for DFU u-boot command
On Tuesday 31 July 2012 02:37:01 Lukasz Majewski wrote: --- /dev/null +++ b/common/cmd_dfu.c + static char *s = dfu; no need for this to be static -mike signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 5/7] dfu:cmd: Support for DFU u-boot command
On 07/31/2012 12:37 AM, Lukasz Majewski wrote: Support for u-boot's dfu interface dev [list] command. +U_BOOT_CMD(dfu, CONFIG_SYS_MAXARGS, 1, do_dfu, + Device Firmware Upgrade, + interface dev [list]\n + - device firmware upgrade on a device dev\n + attached to interface interface\n + [list] - list available alt settings +); Hmm. Is there any way to make this work without specifying interface dev, or to allow specifying multiple interface dev entries? On a system with all of eMMC, NAND, and SPI, I'd like to just run dfu as the U-Boot command, and have the host specify which of those devices it wants to download to using the DFU protocol. So, if flashing a bunch of devices, there is no need to interact with U-Boot over both serial and USB in order to invoke the dfu command multiple times. Somewhat related to this, it looks like the eMMC support doesn't allow the HW partition to be specified; it would be nice to expose alt settings for all of: a) Each individual HW partition (boot0/1 if present, general0/1/2/3 if present, the user area, maybe the replay block) b) Perhaps also a linearized view of the raw eMMC (LBAs 0..boot_size-1 write to boot 0, LBAs boot_size..(2*boot_size)-1 write to boot1, LBAs 2*boot_size..end_of_device write to user area for example). ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
