[U-Boot] Minor bug found in board/zylonite/lowlevel_init.S. 0x300 changed to 300.

[U-Boot] Minor bug found in board/zylonite/lowlevel_init.S. 0x300 changed to 300.

[Tom Evans]

I was looking through some board files based on the zylonite ones, and 
spotted the following changes.

| $ git-log board/zylonite/lowlevel_init.S
| ...
| commit 951a954b77ef30df1f5c1b7b9b4312e783b2cbb4
| Merge: ac7d97d... bfc8125...
| Author: Wolfgang Denk <wd@atlas.denx.de>
| Date:   Mon Mar 6 23:18:48 2006 +0100
|
|     Merge with /home/wd/git/u-boot/master
|     Code cleanup.
|
| commit 9d803d8c0b7fd9aeb2e708e9e48dd76d7287856d
| Author: Markus Klotzb^(n)cher <Markus Klotzb^(n)mk@pollux.(none)>
| Date:   Wed Feb 8 18:56:28 2006 +0100
|
|     Changes:
|
|         * lots of bugfixes in the assembler code
|         * reverted hardware.h back to original
|         * enabled hardware DRAM calibration
|         * GCC-4 fix: modified GLOBAL_DATA_POINTER macro

| $ git diff
|   af646e865f4bc67623ca957dfe3d3e4a95ff0468..
|   9d803d8c0b7fd9aeb2e708e9e48dd76d7287856d
|   board/zylonite/lowlevel_init.S
| ...
| +       /* mk:   replaced with wait macro */
| +/*     ldr r3, =OSCR     /\* reset the OS Timer Count to zero *\/ */
| +/*     mov r2, #0 */
| +/*     str r2, [r3] */
| +/*     ldr r4, =0x300    /\* really 0x2E1 is about 200usec, *\/ */
| +/*                         /\* so 0x300 should be plenty    *\/ */
| +/* 1: */
| +/*     ldr r2, [r3] */
| +/*     cmp r4, r2 */
| +/*     bgt 1b */
| +       wait #300

Note that the linear code has been replaced with a macro.

The comments above the code above state:

   /* Step 1: Wait for at least 200 microsedonds to allow internal */
   /*         clocks to settle. Only necessary after hard reset... */

The bug is that "=0x300" has been changed to "#300", and the latter is 
interpreted by the assembler as a decimal number. So the code is only 
waiting for 92us instead of 200 (13MHz clock divided by 4, divided by 300).

I don't know if this causes any problems. The code doesn't match the 
comments, and it probably isn't following the manufacturer's 
specification for this timing either.

Anyone else based of the Zylonite port might like to check their code.

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

Phone  (+61 3) 9458 4955
Direct         Unsupported
FAX    (+61 3) 9458 4966
Mobile         0405 776 431

[U-Boot] Minor bug found in board/zylonite/lowlevel_init.S. 0x300 changed to 300.

[Wolfgang Denk]

Dear Tom,

In message <4959A41F.50701@ceos.com.au> you wrote:
>
> | commit 9d803d8c0b7fd9aeb2e708e9e48dd76d7287856d
> | Author: Markus Klotzb^(n)cher <Markus Klotzb^(n)mk@pollux.(none)>
> | Date:   Wed Feb 8 18:56:28 2006 +0100
> |
> |     Changes:
> |
> |         * lots of bugfixes in the assembler code
> |         * reverted hardware.h back to original
> |         * enabled hardware DRAM calibration
> |         * GCC-4 fix: modified GLOBAL_DATA_POINTER macro
> 
> | $ git diff
> |   af646e865f4bc67623ca957dfe3d3e4a95ff0468..
> |   9d803d8c0b7fd9aeb2e708e9e48dd76d7287856d
> |   board/zylonite/lowlevel_init.S
> | ...
> | +       /* mk:   replaced with wait macro */
> | +/*     ldr r3, =OSCR     /\* reset the OS Timer Count to zero *\/ */
> | +/*     mov r2, #0 */
> | +/*     str r2, [r3] */
> | +/*     ldr r4, =0x300    /\* really 0x2E1 is about 200usec, *\/ */
> | +/*                         /\* so 0x300 should be plenty    *\/ */
> | +/* 1: */
> | +/*     ldr r2, [r3] */
> | +/*     cmp r4, r2 */
> | +/*     bgt 1b */
> | +       wait #300
> 
> Note that the linear code has been replaced with a macro.
> 
> The comments above the code above state:
> 
>    /* Step 1: Wait for at least 200 microsedonds to allow internal */
>    /*         clocks to settle. Only necessary after hard reset... */
> 
> The bug is that "=0x300" has been changed to "#300", and the latter is 
> interpreted by the assembler as a decimal number. So the code is only 
> waiting for 92us instead of 200 (13MHz clock divided by 4, divided by 300).
> 
> I don't know if this causes any problems. The code doesn't match the 
> comments, and it probably isn't following the manufacturer's 
> specification for this timing either.
> 
> Anyone else based of the Zylonite port might like to check their code.

I fixed this for the delta and zylonite boards now. Thanks for
pointing out.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"There are three principal ways to lose money: wine, women, and engi-
neers. While the first two are more pleasant, the third is by far the
more certain."                           - Baron Rothschild, ca. 1800

[U-Boot] U-Boot Scripting suggestions to decrement counter in EEPROM. Alignment bug in itest on ARM.

[Tom Evans]

I'm implementing a rather complex boot that involves flags and counters 
in EEPROM.

This is to detect multiple boot failures and to then revert to a 
previous Linux kernel and sysroot.

The Hush shell and applications almost support this by using scripts 
(even autoscripting), but not quite.

"ee read" and "ee write" let me read and write the counters and flags to 
memory.

 From there, "if itest *$buf_addr == 1" (and so on) can be used to test 
the values of flags in the EEPROM (except for bad bug in itest, listed 
later). "mw.b" can write flags into memory to then be written to eeprom.

The only way I can currently think of to "read" a byte from EEPROM into 
a shell variable so it can be decremented (with setexpr) and then 
written back is to use something like the following:

     READ_ADDR=0x82000000
     setenv FN_READ_BYTE 'setenv DATA; DATA=0; while itest \
     *$READ_ADDR != $DATA; do setexp DATA $DATA + 1; done'
     mw.l 0x82000000 254
     run FN_READ_BYTE
     echo $DATA

Yes, it is comparing every value from zero and incrementing until it 
gets a match! That results in $DATA being set to "254" (the value I 
wrote to memory) but it takes 9 seconds to run on an 800MHz ARM core!

Am I missing a simpler way or am I going to have to add some new 
commands, like a "memory read" variant that reads into an environment 
variable. If setexpr took a "*" to be a pointer (to be consistent with 
itest) it might be the easiest addition.


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;
     } else {
         l = simple_strtoul(s, NULL, 16);
     }

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

"l = *p" works on a 486 but not on an ARM. It is a simple change - a 
three-way case on the width reading through the "right pointer".

Yes, I should fix this and submit a patch, but I'm not working on 
anything close to the distribution tree unfortunately. I'm pretty sure 
this hasn't been fixed lately though.

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

[U-Boot] U-Boot Scripting suggestions to decrement counter in EEPROM. Alignment bug in itest on ARM.

[Jean-Christophe PLAGNIOL-VILLARD]

On 17:40 Tue 03 Mar     , Tom Evans wrote:
> I'm implementing a rather complex boot that involves flags and counters 
> in EEPROM.

in which case do you need this?

update?

in u-boot you have better system that involve watchdog and bootcount

I do not known which cpu or soc you use but you can implement it simply

> 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
b>      } else {
>          l = simple_strtoul(s, NULL, 16);
>      }
> 
>      return (l & ((1 << (w * 8)) - 1));
> }
> 
> "l = *p" works on a 486 but not on an ARM. It is a simple change - a 
> three-way case on the width reading through the "right pointer".
the arm does not allow you to do an non aligned access

Best Regards,
J.