[U-Boot-Users] 405Gpr timer interrup

[Jerry Walden]

>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 at lists.sourceforge.net
[mailto:u-boot-users-admin at lists.sourceforge.net]On Behalf Of Wolfgang
Denk
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
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 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
https://lists.sourceforge.net/lists/listinfo/u-boot-users