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

[David Snowdon]

G'Day Wolfgang, u-boot-users,

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

No. It was there for reference, should it be required.

> 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 am not 100% sure. There is a chance, but that is what Multi-ICE is 
showing, and I have no better way of verifying what's going on. It does 
seem consistent, however.

> 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.

> 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.

>> 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.

Ok.

>> 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.

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).

I have read the coding standard, and will certainly fix any 
inconsistencies with it when submitting a patch for the new board.

The code is derived from the memsetup.S for the "cradle" board.

The hardware is essentially a development board with a PXA255 
processor, TE28F320B3 Flash, and Micron MT48LC16M16A2 SDRAM. The Flash 
and SDRAM are both configured as single banks (each with two 16-bit 
wide chips). There is a serial transceiver connected to the FFUART 
TX/RX. The flash is certainly working (checked using JTAG boundary scan 
on the PXA255).

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?

Cheers,

Dave.