On 09/03/2014 09:59 AM, Peter A. Bigot wrote:
On 09/03/2014 10:48 AM, Stephen Warren wrote:
On 09/02/2014 05:31 PM, Peter A. Bigot wrote:
The capacity and lba for an MMC device with part_num 0 reflects the
whole device.  When mmc_switch_part() successfully switches to a
partition, the capacity is changed to that partition.  As partition 0
does not physically exist, attempts to switch back to the whole device
will indicate an error, but the capacity setting for the whole device
must still be restored to match the partition.

diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c

@@ -594,10 +594,15 @@ int mmc_switch_part(int dev_num, unsigned int
part_num)
      ret = mmc_switch(mmc, EXT_CSD_CMD_SET_NORMAL, EXT_CSD_PART_CONF,
               (mmc->part_config & ~PART_ACCESS_MASK)
               | (part_num & PART_ACCESS_MASK));
-    if (ret)
-        return ret;

-    return mmc_set_capacity(mmc, part_num);
+    /*
+     * Set the capacity if the switch succeeded or was intended
+     * to return to representing the raw device.
+     */
+    if ((ret == 0) || ((ret == -ENODEV) && (part_num == 0)))
+        ret = mmc_set_capacity(mmc, part_num);
+
+    return ret;
  }

I think this wouldn't be needed without patch 1/2, since without that
patch, no partition switching should ever happen if HW partitions
don't exist, and hence this patch shouldn't be required.

Not so.

In SPL mode, the mmc device passed in to the environment code is set up
for partition 0.  In the failure case, u-boot is configured to expect an

What failure case?

environment in partition 2, and so invokes mmc_switch_part to go to
partition 2 to see if it's a valid partition.  In my case that fails
because the partition size is zero, but regardless the mmc_switch_part
back to mmc->part_num fails because the mmc_switch() call rejects the
attempt with an error.

Isn't that where the bug should be fixed then; why doesn't mmc_switch() work as desired? If mmc_switch() isn't intended to work on devices without HW partitions, then why is it being called at all in any case (normal or failure case)?

I also wonder why, if your board configuration is set up to assume an eMMC device with HW partitions, you're using a device without eMMC HW partitions; it seems like either the board configuration or your HW configuration is incorrect (or at least don't match), so if you have problems, it's not surprising, and not something that should be fixed.

Without this second patch, you end up with mmc->part_num left at zero
but the capacity/lba fields configured for partition 2 which does not
exist and has size zero, and SPL is unable to locate u-boot.img to
continue.

Please review the details in the meta-ti discussion.

I have no idea what that is.
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Reply via email to