>> >> + "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
