imx6ULL memcpy issue in RTEMS 5

[Ian Caddy]

Actually probably have placed this in the email as well:

RTEMS version: 5.0.0.caccc5bfc6fab5672068e6cf6c32c1318a729cba-modified
RTEMS tools: 7.3.0 20180125 (RTEMS 5, RSB 
4bd8de535bbede68c7b46ea88a1b8eed356c3897, Newlib 3.0.0)

regards,

Ian C.


On 4/09/2018 4:13 PM, Ian Caddy wrote:
> Hi All,
>
> I am trying to get a imx6ULL custom BSP running on RTEMS 5.  I am 
> working through some startup issues between u-boot and RTEMS and I 
> think I have most of them squared away now.
>
> During the RTEMS higher level init, the IMFS is inited and as part of 
> that, /dev is created.  When creating the node for the "dev" 
> directory, in:
>
> rtems/cpukit/libfs/src/imfs/imfs_creat.c:56
>
> it performs a memcpy to place the name into the node->name:
>
> memcpy(RTEMS_DECONST(char *, node->name), name, namelen);
>
> where:
>
> node->name = 0x8031c4B8
>
> name = "dev" @ 0x8029aff1
>
> namelen = 3
>
> At the lowest level memcpy calls:
>
> gcc-7.3.0/newlib/libc/machine/arm/memcpy-armv7a.S
>
> which at line 236 performs a half word load from the source (which is 
> not aligned, not the name address above):
>
>  ldrhcs tmp1, [src], #2
>
> and I get a data abort as src = 0x8029aff1 which is a const string and 
> has no reason to be word (or half word) aligned.
>
> I pretty much copied the build tree, from the imx BSP (which is based 
> on an imx7 I think from memory) as the imx6ULL is a Cortex-A7 single 
> core proceessor, using the ARMv7-A architecture.
>
> Some places have been saying that I need to check whether or not the 
> particular processor support non-aligned access, but the imx 
> documentation is not that great and points to the ARM documentation 
> which is more generalised.
>
> There seemed to be a similar issue on the GNU embedded toolchain 
> mailing list:
>
> https://answers.launchpad.net/gcc-arm-embedded/+question/289328
>
> I can provide more detailed information if anyone is interested.
>
> We are going to need to be able to support unaligned access for memcpy 
> on both the source and destination, so I was hoping someone might be 
> able to point me in the correct direction to fix it?
>
> regards,
>
> Ian Caddy
>
>
> _______________________________________________
> users mailing list
> users at rtems.org
> http://lists.rtems.org/mailman/listinfo/users