[U-Boot-Users] U-boot - odd errors in memsetup

[Wolfgang Denk]

In message <B32437B1-F4F0-11D8-84C7-000393C7979E at student.unsw.edu.au> you wrote:
> 
> I'm stepping through the code using a Multi-ICE, and am able to 
> reliably read the flash, downloading the entire program, etc, so I'm 
> fairly certain that the flash is hooked up and working ok. I can also 
> disassemble this using arm-linux-objdump, and get some sane-looking 
> output (1st 1000 lines clagged below).

Do yuou actually expect us tp read this? 1000 lines of dubious  stuff
without any explanation what to look for or so? Gosh!

> work pretty well up until the point (at address 0x550) where it loads a 
> particular register's address into R3 (e.g. ldr r3,0x00000744). It 
> seems to load the top 16 bits without any worries, but the bottom 16 
> bits are FFFF (rather than the bottom half of the address of the OS 
> counter register).

You mean a ldr statement is not  woprking  correctly?  Are  you  100%
sure? Or is there a chance that the Multi-ICE is showing bad register
contents?

> I had a quick look back at what it does when its setting up the GPIO 
> registers, and it seems that it happens sporadically while its doing 
> any ldr instruction. It doesn't seem to be correlated with the address, 
> and looking at the disassembly, the correct values are being read by 
> the processor.

What has the disassembly to do with the values read by the processor?
It may be what you _want_ to be read by the  CPU,  but  what  do  you
actually see on your data bus?

> Is there anything different that the ldr instruction would do (as 
> opposed to when I'm reading it out with multi-ice?) that might cause 
> this effect?

Timing, for example. Also it may use bursts to fetch  the  data  into
cache. Depends on your configuration and system setup which you don't
bother to share with us.

> Before I noticed this problem, I was getting prefetch faults, and 
> unknown instruction exceptions on a mov instruction (hence the addition 
> of the nops at 0x56c to see whether it was dependent on the address - 
> the addition of the nops caused the code above it to break in the way I 
> described above.

Sounds like a misconfigured system and/or broken hardware.

> Any ideas? Any further information that I can provide that might shed 
> some light on the situation? I've attached the memsetup.S file that all 
> this is generated from (from address 0x444 onward).

And do you really expect that we check this without  any  explanation
what  it  wwas  derived  from,  what  you  changed and why, what your
hardware is looking like etc.?

I stopped looking when I saw that your changes  violate  the  Codiing
Style requirements as specified in the README.


You're sending 40kB of trash to the list, and expect that we solve  a
problem for you without being given any relevant data?

Sorry, this is not the way it works.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
I will also, for an appropriate fee, certify that  your  keyboard  is
object-oriented,  and  that  the bits on your hard disk are template-
compatible.            - Jeffrey S. Haemer in <411akr$3ga at cygnus.com>