This is the mail archive of the mailing list for the newlib project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: MMU Off / Strict Alignment


On 11/20/2013 03:45 PM, Matthew Gretton-Dann wrote:
> On 20 November 2013 17:57, Christopher Covington <> wrote:
>> Hi,
>> We've noticed an issue trying to use the Linaro AArch64 binary bare metal
>> toolchain release with the MMU turned off for some low-level tests.
>> Anytime puts, sprintf, etc. gets called, a reent structure gets created with
>> references to STDIN, STDOUT, STDERR FILE types. A member in the __sFile
>> struct, _mbstate, is an 8 byte struct, but is not aligned on an 8 byte
>> boundary. This means that when memset (or a similar function) gets called on
>> this struct, and doesn't operate one byte at a time, a data alignment fault
>> will be generated when operating out of device memory, such as on a system
>> where the MMU has not yet been turned on yet.

We believe to have narrowed down the issue to the AArch64 optimized
memcpy/memset implementations that assume unaligned accesses will not fault.
While the current AArch64 libgloss startup code turns the MMU on so such
accesses will succeed, I don't think turning on the MMU should be required of
all startup code. Would it be possible to modify these routines to make only
size-aligned accesses without degrading performance? If a single
implementation can't make everyone happy, should the ifdefs around them
perhaps be expanded to include something about requiring the MMU to be on?


Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by the Linux Foundation.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]