[U-Boot] Minor bug found in board/zylonite/lowlevel_init.S. 0x300 changed to 300.
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.
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
participants (2)
-
Tom Evans -
Wolfgang Denk