Am 19.03.2014 15:44, wrote Wolfgang Denk:
> Dear Eric Nelson,
> 
> In message <5329a80b.9020...@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 ...

>>> 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.
> 

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.

> Best regards,
> 
> Wolfgang Denk
> 

_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Reply via email to