This is the mail archive of the
ecos-discuss@sourceware.org
mailing list for the eCos project.
RE: memory alignment issue when compile eCos with codesourcery toolchain arm-none-eabi-gcc
- From: "Chris Zimman" <czimman at bloomberg dot com>
- To: "Lu Karl-B01968" <Karl dot Lu at freescale dot com>
- Cc: <ecos-discuss at ecos dot sourceware dot org>
- Date: Wed, 15 Oct 2008 08:52:49 -0400
- Subject: [ECOS] RE: memory alignment issue when compile eCos with codesourcery toolchain arm-none-eabi-gcc
- References: <7FD1F85C96D70C4A89DA1DF7667EAE960D7C2C@zch01exm23.fsl.freescale.net> <F31C1582037F5041B0CD525FD870AE6A012E8BA1@ny2545.corp.bloomberg.com> <7FD1F85C96D70C4A89DA1DF7667EAE960D7C2F@zch01exm23.fsl.freescale.net>
> We are using Freescale i.Mx31 which is an ARM11 chip.
> The problem happens when a 2-byte aligned address is assigned to
> pointer which requires 4-byte aligned. For example, in lan92xx_send()
> in if_lan92xx.c, one code line is as below,
> ----------
> unsigned int data, *pdata;
> pdata = (unsigned int *)sg_list[i].buf;
> -----------
> Here sg_list[i].buf is 2-byte aligned while pdata needs 4-byte aligned.
> Then following code will hang the system
> ----------
> data = *pdata;
> ---------
> In fconfig.c, the problem is similar. Val_ptr is of "void *" type and
> it is pointed to a char in a long string (for command processing). It
> is not guaranteed to be 4-byte aligned. Then when setting IP address,
> following code will fail
> ----------
> lp += diag_sprintf(lp, "%s", inet_ntoa((in_addr_t *)val_ptr));
> ---------
> Because (in_addr_t *) in function inet_ntoa expects val_ptr to be 4-
> byte aligned.
>
> Do you think there is a way to work around this issue without code
> modification?
Hi Karl,
The ARM11 requires 32 bit accesses to be word aligned unless you have CP15 c1
set to allow unaligned access. I am suspicious that this is what may be
happening based off of what you're saying.
See chapter 4 of
http://infocenter.arm.com/help/topic/com.arm.doc.ddi0211j/DDI0211J_arm1136_r1
p5_trm.pdf
--Chris