From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric Nelson Date: Wed, 19 Mar 2014 11:18:02 -0700 Subject: [U-Boot] MMC and buffer alignment question In-Reply-To: <5329D685.80402@tqsc.de> References: <5329A6BD.3090309@tqsc.de> <5329A80B.9020908@boundarydevices.com> <20140319144452.BB9C8382243@gemini.denx.de> <5329D685.80402@tqsc.de> Message-ID: <5329DF5A.7090604@boundarydevices.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Hi Markus and Wolfgang, On 03/19/2014 10:40 AM, Markus Niebel wrote: > Am 19.03.2014 15:44, wrote Wolfgang Denk: >> Dear Eric Nelson, >> >> In message <5329A80B.9020908@boundarydevices.com> you wrote: >>> >>>> short question to the usage of the mmc command (and also the mmc >>>> driver API): is it intended that mmc read / write may fail when the >>>> supplied address in RAM is not aligned? >>> >>> If not intended, it is known. >> >> I consider this a known bug. >> >>>> ARMV7 will give output like this: >>>> >>>> U-Boot > mmc read 12000002 44 44 >>>> >>> Why would you want to do this? >> >> For example, BMP images require loading on a +2 aligned address due to >> their stupid header format. I ran into this before myself: it is >> impossible to match both the alignment reuqirements of the bmp command >> and the mmc read command at the same time. One must manually copy the >> memory ragen again. This is a plain, stupid bug. >> > > Exactly here it popped up ... > It seems to me that if you're resorting to using un-formatted storage space to store a broken data structure (the BMP header), you could just write it at an offset +2. The BMP support is pretty difficult to use anyway (only supports BMPV3 headers), so asking the user to know about the offset doesn't seem onerous. Also note that the patch I submitted recently handles the case for gzipped files for those using cfb_console. >>>> Special commands inside the mmc drivers and in env_mmc implement the >>>> alignment magic. Shouldn't the mmc do the magic (and if neccesarry >>>> provide help using temp buffers if needed) so that all users outside can >>>> read / write without caring for special cases? >>> >>> Is there a use case here? There are plenty of memory addresses that >>> won't work with commands like "mmc read". >> > > env_mmc needs to care for cache aligned buffers - This was fixed some time ago > for the redundant env case > >> "mmc read" and "mmc write" are operations that work on character >> buffers, like all other file IO ops. These should not require any >> specific alignment. >> >>> Is it worth **any** code to try and catch them? >> >> Definitely yes. >> IMHO, this seems like overkill. Should we also prevent over-writing the stack or heap? > > So just as an idea - we could use a bounce buffer for mmc_bwrite / mmc_bread for the > unaligned case. Is definitely slow but should work. > Note that "sata read/write" and "usb read/write" have the same issues. Regards, Eric