[U-Boot] [PATCH RFC] fsl_esdhc: flush cache after non-read operation

[Marek Vasut]

On Monday, March 31, 2014 at 10:23:50 AM, Hector Palacios wrote:
> Hi,
> 
> On 03/28/2014 03:36 PM, Eric Nelson wrote:
> > Hi Hector,
> > 
> > On 03/28/2014 06:49 AM, Fabio Estevam wrote:
> >> On Fri, Mar 28, 2014 at 7:15 AM, Hector Palacios
> >> 
> >> <hector.palacios at digi.com> wrote:
> >>> Cache was invalidated on the read operation, but it should
> >>> also be flushed otherwise.
> >>> 
> >>> Signed-off-by: Hector Palacios <hector.palacios at digi.com>
> 
> After further testing it looks like I misinterpreted the results:
> First, please disregard the patch as it does not fix anything.
> Second, 'mmc part' command seems to be returning cached data after I use
> 'gpt' command to partition the uSD card. I can reproduce it as follows
> (consider mmc 1 is my uSD card):
> 
> 1. Write random data to corrupt the partition table
> 	=> mmc dev 1
> 	=> mmc write $loadaddr 0 30
> 2. Check partition table is corrupt
> 	=> mmc part		(shows error invalid GPT)
> 3. Soft reset the target
> 4. Write a correct partition table
> 	=> mmc dev 1
> 	=> gpt write mmc 1 "..."
> 5. Read back partition table
> 	=> mmc part
> 
> At this point 'mmc part' returns again an incorrect partition table.
> However, if after a while I do an 'mmc rescan' or a soft reset and rerun
> the 'mmc part' command, it will show the correct partition table was
> written.
> 
> The partition table is read during mmc_init():
> 
> int test_part_efi(block_dev_desc_t * dev_desc)
> {
> 	ALLOC_CACHE_ALIGN_BUFFER_PAD(legacy_mbr, legacymbr, 1, dev_desc->blksz);
> 
> 	/* Read legacy MBR from block 0 and validate it */
> 	if ((dev_desc->block_read(dev_desc->dev, 0, 1, (ulong *)legacymbr) != 1)
> 
> 		|| (is_pmbr_valid(legacymbr) != 1)) {
> 
> 		return -1;
> 	}
> 	return 0;
> }
> 
> Could it be that the read partition table is cached so that after writing
> it with 'gpt', reading it again returns cached data instead of physical
> data, just written?

You mean cached as in "in data cache of the CPU" ? You can test that quite 
easily, add CONFIG_CMD_CACHE into your board config and then use "dcache off" 
before running your testcase. You can try "dcache on" and retry the testcase. 
See if that makes some difference.

Best regards,
Marek Vasut