> -----Original Message-----
> From: Christian Löhle <CLoehle@xxxxxxxxxxxxxx>
> Sent: Tuesday, October 25, 2022 5:14 PM
> To: Avri Altman <Avri.Altman@xxxxxxx>; ulf.hansson@xxxxxxxxxx; linux-
> mmc@xxxxxxxxxxxxxxx
> Subject: RE: [PATCH] mmc-utils: Implement alternative boot operation
>
> CAUTION: This email originated from outside of Western Digital. Do not click
> on links or open attachments unless you recognize the sender and know that
> the content is safe.
>
>
> >> @@ -255,6 +255,18 @@ static struct Command commands[] = {
> >> "Issues a CMD0 GO_PRE_IDLE",
> >> NULL
> >> },
> >> + { do_alt_boot_op, -1,
> >> + "boot_operation", "<boot_data_file> <boot_blocks> <device>\n"
> >> + "Does the alternative boot operation and writes the
> >> + specified starting
> >> blocks of boot data into the requested file.\n\n"
> >> + "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?
>
> >> + 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.
Thanks,
Avri
>
> I will address the rest of you comments in v2.
>
> Regards,
> Christian
> Hyperstone GmbH | Reichenaustr. 39a | 78467 Konstanz Managing Director:
> Dr. Jan Peter Berns.
> Commercial register of local courts: Freiburg HRB381782
