RE: [PATCH] mmc-utils: Implement alternative boot operation

["Christian Löhle" <CLoehle@hyperstone.com>]

>> >> +         "Note some limitations\n:"
>> >> +         "1. The boot operation must be configured, e.g. for legacy speed:\n"
>> >> +         "mmc-utils bootbus set single_backward retain x8 /dev/mmcblk2\n"
>> >> +         "mmc-utils bootpart enable 1 0 /dev/mmcblk2\n"
>> >> +         "2. The MMC must currently be running at the bus mode 
>> >> + that is
>> >> configured for the boot operation (HS200 and HS400 not supported at
>> all).\n"
>> >> +         "3. Most hosts cannot do transfers of the typical size of 
>> >> + the boot partition,
>> >> adjust <boot_blocks> accordingly.\n"
>> > A redundant arg?
>> > Since blksz is 512, Maybe just set it to be ext_csd[226] * 256?
>> 
>> As the help above explains this will not work on most hosts.
>> Limitations of maximum transfers of like 512K to a couple MB are very 
>> common.
>> One could just read the max, but I found it less misleading that way.
> But isn't the mmc_blk_ioctl_copy_from_user impose a hard MMC_IOC_MAX_BYTES limit?
> So you won't be able to read more than 512K anyway?

You're right, I changed that locally and missed it.

>> >> +       mioc->num_of_cmds = 2;
>> >> +       mioc->cmds[0].opcode = MMC_GO_IDLE_STATE;
>> >> +       mioc->cmds[0].arg = MMC_GO_PRE_IDLE_STATE_ARG;
>> >> +       mioc->cmds[0].flags = MMC_RSP_NONE | MMC_CMD_AC;
>> >> +       mioc->cmds[0].write_flag = 0;
>> >> +
>> >> +       mioc->cmds[1].opcode = MMC_GO_IDLE_STATE;
>> >> +       mioc->cmds[1].arg = MMC_BOOT_INITIATION_ARG;
>> >> +       mioc->cmds[1].flags = MMC_RSP_NONE | MMC_CMD_ADTC;
>> >> +       mioc->cmds[1].write_flag = 0;
>> >> +       mioc->cmds[1].blksz = 512;
>> >> +       mioc->cmds[1].blocks = boot_blocks;
>> >> +       /* Access time of boot part differs wildly, spec mandates 1s */
>> >> +       mioc->cmds[1].data_timeout_ns = 2 * 1000 * 1000 * 1000;
>> >> +       mmc_ioc_cmd_set_data(mioc->cmds[1], boot_buf);
>> > Don't you get "010" prior to the boot content?
>> > Most cards have their EXT_CSD_PART_CONFIG_ACC_ACK bit set.
>> > So you need to eliminate it from the boot file?
>> > But your compare show that the files are identical - how so?
>> 
>> By configuring the card to not send BOOT ACK.
>> With it enabled there is unfortunately no way to get the transfer 
>> through from userspace.
>> (The host will sample part of the ACK, CRC wont match and so on)
> This doesn't seems to be a reasonable requirement from the average user - e.g. validation & field application engineers who address eMMC issues as well, but mostly other embedded flash protocols - ufs & others.

Is it? I mean usually they configure the boot partition, too and mmc-utils gives them all they need with:
e.g. mmc-utils bootpart enable 1 0 /dev/mmcblkX
But yeah, if this is too much of a limitation to be considered useful then this patch is not worth pursuing as pretending the boot operation is a normal block transfer for ioctl and the host driver only works with boot ack off.
Anything with boot ack on cannot be done from userspace and not even host-controller-agnostic, i.e. would need its own host_ops call, which is a bit overkill for testing / debugging purposes I'd say.

Regards,
Christian


Hyperstone GmbH | Reichenaustr. 39a  | 78467 Konstanz
Managing Director: Dr. Jan Peter Berns.
Commercial register of local courts: Freiburg HRB381782