[U-Boot-Users] U-boot - odd errors in memsetup
davids at student.unsw.edu.au
Sun Aug 29 16:12:06 CEST 2004
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?
>>> 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
>> (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
>> 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
>> the PXA255's reset values, which are all the slowest as I understand
>> (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
> 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
More information about the U-Boot