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?