> On 21 Apr 2018, at 19:00, Måns Rullgård <m...@mansr.com> wrote: > > Christoph Müllner <christoph.muell...@theobroma-systems.com > <mailto:christoph.muell...@theobroma-systems.com>> writes: > >>> On 21 Apr 2018, at 15:24, Måns Rullgård <m...@mansr.com> wrote: >>> >>> Klaus Goger <klaus.go...@theobroma-systems.com> writes: >>> >>>> The current arch implementation of memcpy cannot be called >>>> from thumb code, because it does not use bx instructions on return. >>>> This patch addresses that. Note, that this patch does not touch >>>> the hot loop of memcpy, so performance is not affected. >>>> >>>> Tested on MXS (arm926ejs) with and without thumb-mode enabled. >>>> >>>> Signed-off-by: Klaus Goger <klaus.go...@theobroma-systems.com> >>>> Signed-off-by: Christoph Muellner >>>> <christoph.muell...@theobroma-systems.com> >>> >>> There are many more instances of mov to pc that ought to be fixed too. >>> Why not do them all at once rather than picking them off one by one as >>> they happen to break things? >> >> I could not find exit points within memcpy other than those which we fixed. >> The many other mov pc, $lr instructions are just branches within memcpy. >> Am I overseeing anything here? > > I meant elsewhere, not just in memcpy.
We just bumped in to the start.S and the memcpy code when running with C-code compiled to thumb. We were able to boot a Linux kernel with those changes. Why should we touch code, which we don’t use (and therefore don’t test)? Background is, that we have to meet restricted size limitations for the resulting U-Boot image. Turning off all not-required features was not enough, so we had the idea to compile C-code to thumb (which U-Boot offers via Kconfig option). This did the trick and we wanted to share what’s needed to get this configuration up and running.
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
