ARM alignment MMU setting again was Re: Raspberry Pi BSP debugging

Wed May 1 19:47:43 UTC 2013

Some of the other cp15 variants call the shared mmu_init function,
which is on the schedule to be examined if the MMU project goes
forward. This shared function does not set the unaligned access bit.
Maybe it needs to be documented better. I doubt it will make sense to
set unaligned access by default, because that seems like a property of
the CPU. I would guess there are some newlib multilib builds for ARM
targets using CP15 that use aligned access?

-Gedare

On Wed, May 1, 2013 at 3:41 PM, Alan Cudmore <alan.cudmore at gmail.com> wrote:
> The raspberry pi BSP uses the shared arm start.S, so the exception handlers
> should be there. I guess without a good debugger there is no way to really
> know what is going on.
>
> But I will try to turn off the alignment and see if it works tonight.
>
> Alan
>
>
>
> On Wed, May 1, 2013 at 3:29 PM, Joel Sherrill <joel.sherrill at oarcorp.com>
> wrote:
>>
>> On 5/1/2013 2:25 PM, Alan Cudmore wrote:
>>
>> It looks like the CP15 initialization is explicitly enabling unaligned
>> traps, so that is the likely cause.
>>
>> This came up recently (past week?). The default setting with the
>> MMU initialization code makes it a fault.
>>
>> Unless we compile newlib and other tool libraries to have strict
>> alignment, unaligned access must be allowed.  My gut says
>> cp15 is setup wrong by default for the way we generate code.
>>
>> Gedare has mentored the MMU projects so let's bring him in.
>>
>> The BSP has a good polled printk, so I might try to setup something for
>> the exception vectors as well.
>>
>> I wonder why there isn't a good exception handler. :(
>>
>> Is there not one? Or did you just not get that part of the
>> ARM BSP shared setup?
>>
>> Thanks,
>> Alan
>>
>>
>>
>> On Wed, May 1, 2013 at 1:11 PM, Claus, Ric <claus at slac.stanford.edu>
>> wrote:
>>>
>>> It's not clear what your debugging environment is like, but if you could
>>> put some sort of indicator (e.g. a printk, a write to memory that is
>>> persistent across reboots, or turn on an LED) in each of the exception
>>> vectors (except IRQ, since it will be tickled often by at least clock), then
>>> you could tell whether you've taken an exception.  It smells like you're
>>> taking an alignment exception and landing in a for (;;) loop.
>>>
>>> It'd interesting to know the pros and cons of enabling unaligned accesses
>>> with CP15.  Naively, it might seem like a good idea to always enable these.
>>> Presumably it kills performance to do so, however.
>>>
>>> Ric
>>>
>>> ________________________________________
>>> From: rtems-users-bounces at rtems.org [rtems-users-bounces at rtems.org] On
>>> Behalf Of Alan Cudmore [alan.cudmore at gmail.com]
>>> Sent: Wednesday, May 01, 2013 8:12 AM
>>> To: Gedare Bloom
>>> Cc: rtems-users at rtems.org
>>> Subject: Re: Raspberry Pi BSP debugging
>>>
>>> Great idea. It should be easy enough to try, and it looks like the bit to
>>> enable unaligned access is not set in the BSP.
>>>
>>> Thanks,
>>> Alan
>>>
>>>
>>>
>>> On Wed, May 1, 2013 at 10:38 AM, Gedare Bloom
>>> <gedare at rtems.org<mailto:gedare at rtems.org>> wrote:
>>> Could it be a matter of the compiler (not) knowing the correct
>>> alignment for the target architecture?
>>>
>>> To quote Sebastian from a recent post: "Please have a look in the
>>> ARM1176JZF-S manual.  You may have to enable the unaligned access in
>>> the CP15."
>>>
>>> -Gedare
>>>
>>> On Wed, May 1, 2013 at 10:16 AM, Alan Cudmore
>>> <alan.cudmore at gmail.com<mailto:alan.cudmore at gmail.com>> wrote:
>>> > I'm trying to track down a bug in the Raspberry Pi BSP. It will be much
>>> > easier once I get a JTAG device, but for now I have been able to narrow
>>> > down
>>> > one specific instance where the BSP hangs.
>>> >
>>> > The first symptom of this problem was with a shell example. If I type
>>> > an
>>> > invalid shell command, I noticed it will hang or crash on the strncat
>>> > function.
>>> >
>>> > Next, I modified the simple hello world sample and found that it will
>>> > also
>>> > hang with a strncat call. I copied the strncat function from the newlib
>>> > sources and found that the local copies ( optimized for size and speed
>>> > )
>>> > work. The attached example shows the two local strncat calls followed
>>> > by the
>>> > newlib call. It will always hang on the newlib call.
>>> >
>>> > This example works on the arm920/gdb simulator and the sparc-sis
>>> > simulator.
>>> >
>>> > Some other notes;
>>> > - The memory map looks reasonable, comparing it to the arm920 map
>>> > - Many other newlib functions work such as strncpy, printf, etc
>>> > - Much of the other basic RTEMS seem to work as well. I can create a
>>> > RAM
>>> > disk, format it , mount it, copy files, etc. I ran many of the tests
>>> > such as
>>> > unlimited, ticker, etc.
>>> >
>>> > If anyone has an idea I can try let me know. Otherwise I might just
>>> > wait
>>> > until I can get a JTAG device hooked up.
>>> >
>>> > Thanks,
>>> > Alan
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >
>>> > _______________________________________________
>>> > rtems-users mailing list
>>> > rtems-users at rtems.org<mailto:rtems-users at rtems.org>
>>> > http://www.rtems.org/mailman/listinfo/rtems-users
>>> >
>>>
>>
>>
>>
>> --
>> Joel Sherrill, Ph.D.             Director of Research & Development
>> joel.sherrill at OARcorp.com        On-Line Applications Research
>> Ask me about RTEMS: a free RTOS  Huntsville AL 35805
>> Support Available                (256) 722-9985
>
>