[U-Boot-Users] U-boot - odd errors in memsetup
G'Day U-boot users,
I'm trying to get U-boot going on a custom built board based on the PXA255. Unfortunately, I'm having a few problems, and got to the if(clueless){ send email to mailing list } part of the porting to a new board sequence. :-).
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).
Now, what's odd is that when I'm stepping through the code, it seems to 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).
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.
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?
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.
There exists the possibility that the processor has been killed by ESD or something, but I thought I'd email you guys in a last ditch effort before I go about the rather arduous task of pulling off the BGA and place another one.
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).
Many thanks in advance,
Dave.
- David Snowdon PhD Student National ICT Australia (NICTA) Phone: 9385 7355 Email: daves@cse.unsw.edu.au
- David Snowdon PhD Student National ICT Australia (NICTA) Phone: 9385 7355 Email: daves@cse.unsw.edu.au
In message B32437B1-F4F0-11D8-84C7-000393C7979E@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
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.
Dear David,
in message 3551A602-F519-11D8-84C7-000393C7979E@student.unsw.edu.au you wrote:
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
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@denx.de Knowledge, sir, should be free to all! -- Harry Mudd, "I, Mudd", stardate 4513.3
Dear David,
in message 68C5FA02-F9C5-11D8-9008-000393C7979E@student.unsw.edu.au you wrote:
It turns out that you were absolutely right about my problems. You were
It's not difficult being right here; chances are 999:1 here ;-)
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?
You're welcome - see the README for instructions.
Best regards,
Wolfgang Denk
participants (2)
-
David Snowdon -
Wolfgang Denk