Where did you check? In flash, before relocation, or in RAM, after relocation?
I checked in RAM after relocation.
Before I run u-boot, I zero out where I think the vector table should be.
Then I run u-boot to the point where I get a => prompt.
Then - with the BDI - I verify that I could read valid opcodes from where I calculated the "in_ram" label should be, and the bytes corresponded to the opcodes of my disassembled file that contains the "in_ram" code.
Then - with the BDI - I dumped bytes from 0x700 to 0x800. There are only two words that were changed - at 0x788 - this looks like the address where the vector (address) of the handler should be, and the address of the exception return routine - however everything else is zero - there is no "prologue" code.
Worse yet, the addresses appear to be bogus, and certainly do not point to and code space in the relocated code.
Is appears that the only reason the above addresses are getting populated with anything is a function called "trap_init" is getting called, which pulls what is supposed to be a vector out of ram, and adds and offset to it, and puts it back. Because of the value I see that it is trying to add to the address it appears as though that offset might be incorrect as well.
Thanks
Jerry Walden
-----Original Message----- From: u-boot-users-admin@lists.sourceforge.net [mailto:u-boot-users-admin@lists.sourceforge.net]On Behalf Of Wolfgang Denk Sent: Thursday, April 10, 2003 5:28 PM To: jwalden@digitalatlantic.com Cc: u-boot-users@lists.sourceforge.net Subject: Re: [U-Boot-Users] 405Gpr timer interrup
In message EGEGIJHKDKJGAJMGIDPNOEJPCKAA.jwalden@digitalatlantic.com you wrote:
Does the "sleep" command work, with correct timing, i. e. will "sleep 5" sleep for approx. 5 seconds?
Yes - however that is using udelay which does not seem connected to the timestamp which is incremented in the PIT handler.
Right. But it gives an indication if your clock configuration is approximately oK. I was just eliminating potential problems ;-)
Anyway... I figured one reason why the PIT was not causing the timestamp to interate - I had interrupts turned off. I had interrupts_enable commented out from my very first days of working on u-boot.
;-)
Now - when I turn the interrupts on and then - and only when - I enable the PIT - u-boot gets a ProgramCheck.
So - Just to check, I looked to see if there was an address for a handler in the Interrupt Vector Table for the PIT - and I did not find a valid address.
However to cross-check myself, I looked in the IVT for the ProgramCheck vector (I used the BDI to dump 0x700) there was not a valid address there and no code.
So the question now is what should the IVT look like, and at what
addresses
should there be either vectors or code?
Where did you check? In flash, before relocation, or in RAM, after relocation?
Wolfgang Denk
-- Software Engineering: Embedded and Realtime Systems, Embedded Linux Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Email: wd@denx.de Proboscis: The rudimentary organ of an elephant which serves him in place of the knife-and-fork that Evolution has as yet denied him. For purposes of humor it is popularly called a trunk. - Ambrose Bierce
------------------------------------------------------- This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger for complex code. Debugging C/C++ programs can leave you feeling lost and disoriented. TotalView can help you find your way. Available on major UNIX and Linux platforms. Try it free. www.etnus.com _______________________________________________ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users