On Monday 28 November 2016 07:45 PM, See, Chin Liang wrote: > On Jum, 2016-11-25 at 17:51 +0100, Marek Vasut wrote: >> On 11/24/2016 06:35 AM, Vignesh R wrote: >>> >>> According to Section 11.15.4.9.2 Indirect Write Controller of K2G >>> SoC >>> TRM SPRUHY8D[1], the external master is only permitted to issue 32- >>> bit >>> data interface writes until the last word of an indirect transfer >>> otherwise indirect writes is known to fails sometimes. So, make >>> sure >>> that QSPI indirect writes are 32 bit sized except for the last >>> write. If >>> the txbuf is unaligned then use bounce buffer to avoid data aborts. >>> >>> So, now that the driver uses bounce_buffer, enable >>> CONFIG_BOUNCE_BUFFER >>> for all boards that use Cadence QSPI driver. >>> >>> [1]www.ti.com/lit/ug/spruhy8d/spruhy8d.pdf >>> >>> Signed-off-by: Vignesh R <vigne...@ti.com> >>> --- >> Reviewed-by: Marek Vasut <ma...@denx.de> >> >> I'd like to have at least Dinh's/Chin's ack on this. > > THanks Marek > > Hmmm... From 11.15.4.1.1, the data slave port should able to accept > only byte, half-word and word access. This should not create any data > abort but probably bad performance. But it should insignificant as > access time for the flash is longer than the data port access itself. >
Data slave port does accept byte, half-word and word access, there are no data aborts. But indirect write controller seems to have limitation(as documented in section 11.15.4.9.2) couping with non 32-bit data writes on TI platform. For example with current driver if I try: fatload mmc 0 0x82000000 zImage sf erase 0x0 0x500000 sf write 0x82000000 0x0 0x35 sf read 0xA0000000 0x0 0x35 md.b 0xA0000000 a0000000: 00 00 a0 00 00 00 a0 00 00 00 a0 00 00 00 a0 00 a0000010: 00 00 a0 00 00 00 a0 00 00 00 a0 00 00 00 a0 00 a0000020: 03 00 00 00 18 28 6f 00 00 00 00 00 d8 5b 35 00 a0000030: 01 02 03 00 00 00 00 00 00 00 00 00 00 00 00 00 md.b 0x82000000 82000000: 00 00 a0 e1 00 00 a0 e1 00 00 a0 e1 00 00 a0 e1 82000010: 00 00 a0 e1 00 00 a0 e1 00 00 a0 e1 00 00 a0 e1 82000020: 03 00 00 ea 18 28 6f 01 00 00 00 00 d8 5b 35 00 82000030: 01 02 03 04 00 90 0f e1 88 07 00 eb 01 70 a0 e1 As you can see, every fourth byte turn out to be 0x00. Therefore this patch is required. -- Regards Vignesh _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
