From mboxrd@z Thu Jan  1 00:00:00 1970
From: Hector Palacios <hector.palacios@digi.com>
Date: Mon, 31 Mar 2014 10:23:50 +0200
Subject: [U-Boot] [PATCH RFC] fsl_esdhc: flush cache after non-read
	operation
In-Reply-To: <533588FA.7030708@boundarydevices.com>
References: <1396001736-8657-1-git-send-email-hector.palacios@digi.com>
	<CAOMZO5DrgQZz-KMWqVKhPPQm=tgk==O7HM4aY4vF1bkKe9qbRw@mail.gmail.com>
	<533588FA.7030708@boundarydevices.com>
Message-ID: <53392616.2020405@digi.com>
List-Id: <u-boot.lists.denx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: u-boot@lists.denx.de

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@digi.com> wrote:
>>> Cache was invalidated on the read operation, but it should
>>> also be flushed otherwise.
>>>
>>> Signed-off-by: Hector Palacios <hector.palacios@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?

-- 
H?ctor Palacios