On Fri, Sep 6, 2013 at 9:40 AM, Dave Martin <Dave.Martin@xxxxxxx> wrote: > On Fri, Sep 06, 2013 at 12:14:08PM +0100, Russell King - ARM Linux wrote: >> On Wed, Sep 04, 2013 at 02:47:51PM -0700, Russ Dill wrote: >> > I think this is already taken care of by the way sram.c is using >> > genalloc. The allocation returned should be aligned to 32 bytes. The >> > thumb bit shouldn't be an issue as code is copied based on the start >> > and end makers made by the linker. I may need to add .align statements >> > in the linker so that the start and end markers for the copied code >> > are aligned to at least 8 bytes. >> >> I think you need to read up on what fncpy does... there's more to it >> than just merely copying code at an appropriate alignment. > > The technique of putting each loadable blob in a specific vmlinux > section, and then adjusting entry-point symbols by adding/subtracting > the appropriate offset, probably does work. > > This relies on the functions' code alignment requirement being > honoured by both the vmlinux link map, and the allocator used to find > SRAM space to copy the functions to. > > Searching the entire list of known blobs every time we want to convert > a symbol seems unnecessary though. Surely the caller could know the > blob<->symbol mapping anyway? It doesn't search the list of known blobs, only loaded blobs. On all the platforms I'm aware of, only one SRAM section is loaded with code. > One thing fncpy() doesn't provide is a way to copy groups of functions > that call each other, if vmlinux needs to know about any symbol other > than the one at the start. We might need a better mechanism if that is > needed. > > > I actually wonder whether fncpy() contains a buglet, whereby > flush_icache_range() is used instead of coherent_kern_range(). > The SRAM is probably not mapped cached, but at least a DSB would be > needed before flushing the relevant lines from the I-cache. It is mapped cached on most platforms. > However, flush_icache_range() seems to be implemented by a call to > coherent_kern_range() anyway, so perhaps that's not a problem. > > Cheers > ---Dave > > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel@xxxxxxxxxxxxxxxxxxx > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
