[U-Boot-Users] 405Gpr timer interrup
jwalden123 at adelphia.net
Thu Apr 10 23:35:44 CEST 2003
>Where did you check? In flash, before relocation, or in RAM, after
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.
From: u-boot-users-admin at lists.sourceforge.net
[mailto:u-boot-users-admin at lists.sourceforge.net]On Behalf Of Wolfgang
Sent: Thursday, April 10, 2003 5:28 PM
To: jwalden at digitalatlantic.com
Cc: u-boot-users at lists.sourceforge.net
Subject: Re: [U-Boot-Users] 405Gpr timer interrup
In message <EGEGIJHKDKJGAJMGIDPNOEJPCKAA.jwalden at digitalatlantic.com> you
> >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
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
> should there be either vectors or code?
Where did you check? In flash, before relocation, or in RAM, after
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Email: wd at 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 at lists.sourceforge.net
More information about the U-Boot