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

[David Snowdon]

G'Day Wolfgang, u-boot-users,

It turns out that you were absolutely right about my problems. You were 
suggesting that the debugger accesses memory in a different way to the 
processor. What I think was wrong was a high-resistance solder 
connection which caused one of the chips to not work so well when being 
accessed at speed, but when being accessed via a debugger (presumably 
using boundary scan), it would work just fine.

I used our CRO to look at the signals and they were indeed doing the 
wrong thing. (A logic analyser would have been wonderful).

I'm presently fixing up any problems with my coding style and would be 
grateful if I could then submit a patch adding the new board?

Regards,

Dave.

>>> 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?
>>
>> The disassembly is derived from the code which was read from the 
>> flash.
>> (e.g. Multi-ICE downloads the data from flash, runs it through a
>> disassembler, and displays it as you step through). In order to get 
>> the
>> correct disassembly, the correct code has to be in flash.
>
> But again, this is just what the Multi-ICE is telling you. And I  bet
> it  accesses  the  flash memory in a different way than the processor
> when fetching instructions.
>
>>> 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.
>>
>> This is all before the flash timings have been configured, so its 
>> using
>> the PXA255's reset values, which are all the slowest as I understand 
>> it
>> (and non-burst). I am using two Intel 28F320B3 (Advanced boot block
>> flash memory) chips configured as a single 32-bit wide bank.
>
> Well, attach a logic analyzer and verify which data are actually seen
> on the bus.
>
>>> 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.
>>
>> You've asked for two contradicting qualities -- a small email along
>> with all the possible relevant data. I provided what I thought was the
>> relevant data, and specifically asked if I had got it right (which I
>> guess I didn't).
>
> No. The data you sent was not relevant, and not usable.
>
> If you think that the memset code was critical, you could have simply
> referred to a known version and provided a diff against the  file  in
> the  CVS  tree.  No need to send 500 lines of source when 22 lines of
> diff will do as well.
>
>> Thankyou for your thoughts. I'll try to do it better next time. If
>> you've got any ideas regarding the problem, it would be much
>> appreciated. Is it possible that the PXA could be reading the flash in
>> burst-mode at startup?
>
> See above. Attach a logic analyzer and check what's going on  on  the
> bus.
>
> 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
> Knowledge, sir, should be free to all!
> 	-- Harry Mudd, "I, Mudd", stardate 4513.3
>