public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Tom Evans <tom@ceos.com.au>
To: u-boot@lists.denx.de
Subject: [U-Boot] Alignment bug in itest on ARM & doesn't work on big-endian either?
Date: Wed, 04 Mar 2009 11:19:08 +1100	[thread overview]
Message-ID: <49ADC8FC.5030803@ceos.com.au> (raw)
In-Reply-To: <mailman.3.1236078002.3349.u-boot@lists.denx.de>

Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com> wrote:
> On 17:40 Tue 03 Mar     , Tom Evans wrote:
>> BUG IN ITEST
>> ------------
>> itest crashes ARM chips. I can "iread.b *82000000 == 0",
 >> but "iread.b *82000001 == 0" throws an alignment
 >> exception that kills the box. The code in itest.c is:
>>
>> static long evalexp(char *s, int w)
>> {
>>      long l, *p;
>>
>>      /* if the parameter starts with a * then assume
 >>         is a pointer to the value we want */
>>      if (s[0] == '*') {
>>          p = (long *)simple_strtoul(&s[1], NULL, 16);
>>          l = *p;

> here you are support to use the good accessor
 > readb/readw/readl

Thank you for your response.

readl() is defined in asm-arm/io.h as "__arch_getl(a)" which
is defined as "(*(volatile unsigned int *)(a))" which
doesn't handle misalignment and will still crash.

I think those functions are only meant for I/O reads.

The code then "selects the byte" with the following:

 >>      return (l & ((1 << (w * 8)) - 1));

That selects the LOWER 8/16/32 bits of the 32-bit read.

Which works on a 486, ARM variants with unaligned transfers, but NOT on 
a PPC or any other big-endian CPUs (about half of them supported by U-Boot).

On a big-endian unaligned supporting CPU I'd expect a byte read of 
address "0" to read "3" and a read of "1" to read "4" (in the next 
word!). Ditto for itest.w.

Whoever owns/maintains this code, and/or can test it on a big-endian 
target should fix these, taking hints from the cmd_mem.c code which does 
all of this in a portable manner. I don't have a big-endian target so I 
can't test the big-endian fix.

> the arm does not allow you to do an non aligned access

I know that. The current itest code doesn't. The "indirect pointer 
feature" mustn't be used much if I'm the first one to find these problems.

-- 
===
Tom Evans      Tom.Evans at ceos.com.au
CEOS Pty Ltd   www.ceos.com.au
3/17 Burgundy St, Heidelberg,
Victoria 3084, Australia

      parent reply	other threads:[~2009-03-04  0:19 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <mailman.3.1236078002.3349.u-boot@lists.denx.de>
2009-03-03 22:57 ` [U-Boot] U-Boot Scripting suggestions to decrement, counter in EEPROM Tom Evans
2009-03-05 23:57   ` Wolfgang Denk
2009-03-04  0:19 ` Tom Evans [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=49ADC8FC.5030803@ceos.com.au \
    --to=tom@ceos.com.au \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox