
On Mon, Aug 22, 2011 at 11:31 AM, Mike Frysinger vapier@gentoo.org wrote:
On Monday, August 22, 2011 14:15:22 Anton Staaf wrote:
please dont top post
Sorry about that.
Yes, this would be a much preferable approach. The only problem that I encountered when attempting to do that in the Chromium U-Boot was that there are exposed stand alone U-Boot API's that can pass in pointers that make their way all the way down to the device driver. Two solutions occurred to me. One was to put an Error or assert as high up as possible and expect violators to fix their code, the other was to patch things up in lower layers (right now we have a bounce buffer in the tegra MMC driver to deal with unaligned buffers). My intent was that this would give us a functional U-Boot while we took the time to clean up as many of the unaligned buffers that U-Boot uses, and then tackle the question of stand alone applications.
could you elaborate on the code paths in question ?
Heh, now I've got to go fine them again. The ub_dev_read function in the example/api/glue.c is an example of a use of the public syscall API that as far as I can tell passes down the buffer pointer all the way to the driver layer.
As for the unaligned buffers I've run into:
fs/ext2/dev.c: sec_buf is allocated on the stack and thus is not guaranteed to be aligned. drivers/mmc/mmc.c: ext_csd in mmc_change_freq is allocated on the stack. drivers/mmc/mmc.c: scr and switch_status in sd_change_freq are allocated on the stack. drivers/mmc/mmc.c: ext_csd in mmc_startup is allocated on the stack. disk/part_efi.c: gpt_header in print_part_efi is allocated on the stack. disk/part_efi.c: gpt_header in get_partition_info_efi is allocated on the stack. disk/part_efi.c: legacy_mbr in test_part_efi is allocated on the stack. disk/part_efi.c: pte in alloc_read_gpt_entries is allocated using malloc (not memalign).
I have working solutions to all of these but they generally use the lazy allocation of an aligned buffer as needed pattern. I wanted to see the results of Lukasz current thread before sending them upstream. But that's probably not right. I should probably send them now so we can see a number of examples of the problem and get a better idea of how to fix it.
Thanks, Anton
-mike