RE: [U-Boot-Users] 405Gpr timer interrup
I have a new problem that I am trying to solve - up until now I have not noticed that the timer interrupt has not been working with my 405GPr and u-boot. I just discovered this problem because we recently connected a phy to the 405, and I am now trying to perform a "tftpboot" - I see a message that one ARP packet goes out, and then the board just sits there with no further output - I expected at least a timeout message, and there is indeed a timeout in the code that is supposed to occur if a proper response to the ARP is not recieved within some period of time.
We had a very similar problem with our Ebony system with a single ARP request going out and nothing happening after that (but we didn't concentrate on timer issues). It turned out our problem was with our ethernet drop from the "wiring closet". U-boot displayed something to the effect of "10 MBit/sec, half duplex" for the status of the enet port. When we change things to "100 MBit/sec, full duplex", everything worked OK. What does your enet port status show?
Erik Teose erik.teose@tek.com
my enet port status shows - "100 MBit/sec, full duplex" so I think that is a-okay -
Still can't figure out why I'm not getting a timer interrupt
Jerry Walden
-----Original Message----- From: u-boot-users-admin@lists.sourceforge.net [mailto:u-boot-users-admin@lists.sourceforge.net]On Behalf Of erik.teose@exgate.tek.com Sent: Wednesday, April 09, 2003 12:28 PM To: jwalden@digitalatlantic.com; u-boot-users@lists.sourceforge.net Subject: RE: [U-Boot-Users] 405Gpr timer interrup
I have a new problem that I am trying to solve - up until now I have not noticed that the timer interrupt has not been working with my 405GPr and u-boot. I just discovered this problem because we recently connected a phy to the 405, and I am now trying to perform a "tftpboot" - I see a message that one ARP packet goes out, and then the board just sits there with no further output - I expected at least a timeout message, and there is indeed a timeout in the code that is supposed to occur if a proper response to the ARP is not recieved within some period of time.
We had a very similar problem with our Ebony system with a single ARP request going out and nothing happening after that (but we didn't concentrate on timer issues). It turned out our problem was with our ethernet drop from the "wiring closet". U-boot displayed something to the effect of "10 MBit/sec, half duplex" for the status of the enet port. When we change things to "100 MBit/sec, full duplex", everything worked OK. What does your enet port status show?
Erik Teose erik.teose@tek.com
------------------------------------------------------- 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
In message EGEGIJHKDKJGAJMGIDPNEEIPCKAA.jwalden@digitalatlantic.com you wrote:
my enet port status shows - "100 MBit/sec, full duplex" so I think that is a-okay -
Still can't figure out why I'm not getting a timer interrupt
Does the "sleep" command work, with correct timing, i. e. will "sleep 5" sleep for approx. 5 seconds?
Wolfgang Denk
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.
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?
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: Wednesday, April 09, 2003 5:18 PM To: jwalden@digitalatlantic.com Cc: erik.teose@exgate.tek.com; u-boot-users@lists.sourceforge.net Subject: Re: [U-Boot-Users] 405Gpr timer interrup
In message EGEGIJHKDKJGAJMGIDPNEEIPCKAA.jwalden@digitalatlantic.com you wrote:
my enet port status shows - "100 MBit/sec, full duplex" so I think that is a-okay -
Still can't figure out why I'm not getting a timer interrupt
Does the "sleep" command work, with correct timing, i. e. will "sleep 5" sleep for approx. 5 seconds?
Wolfgang Denk
-- Software Engineering: Embedded and Realtime Systems, Embedded Linux Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Email: wd@denx.de If I have seen further it is by standing on the shoulders of giants. - Isaac Newton, Letter to Robert Hooke, 5 February 1676
------------------------------------------------------- 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
I'm probably just missing it, but I cannot see where the Interrupt Vector Table is being copied over in U-Boot (for the PPC405gp) - could someone give me a sanity check please?
Thanks Jerry Walden
-----Original Message----- From: Jerry Walden [mailto:jwalden@digitalatlantic.com] Sent: Thursday, April 10, 2003 2:48 PM To: Wolfgang Denk Cc: u-boot-users@lists.sourceforge.net Subject: RE: [U-Boot-Users] 405Gpr timer interrup
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.
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?
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: Wednesday, April 09, 2003 5:18 PM To: jwalden@digitalatlantic.com Cc: erik.teose@exgate.tek.com; u-boot-users@lists.sourceforge.net Subject: Re: [U-Boot-Users] 405Gpr timer interrup
In message EGEGIJHKDKJGAJMGIDPNEEIPCKAA.jwalden@digitalatlantic.com you wrote:
my enet port status shows - "100 MBit/sec, full duplex" so I think that is a-okay -
Still can't figure out why I'm not getting a timer interrupt
Does the "sleep" command work, with correct timing, i. e. will "sleep 5" sleep for approx. 5 seconds?
Wolfgang Denk
-- Software Engineering: Embedded and Realtime Systems, Embedded Linux Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Email: wd@denx.de If I have seen further it is by standing on the shoulders of giants. - Isaac Newton, Letter to Robert Hooke, 5 February 1676
------------------------------------------------------- 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
In message EGEGIJHKDKJGAJMGIDPNEEKBCKAA.jwalden@digitalatlantic.com you wrote:
I'm probably just missing it, but I cannot see where the Interrupt Vector Table is being copied over in U-Boot (for the PPC405gp) - could someone give me a sanity check please?
See "lib_ppc/board.c" around line 663:
/* * Setup trap handlers */ trap_init (dest_addr);
Wolfgang Denk
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
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
participants (4)
-
erik.teose＠exgate.tek.com -
Jerry Walden -
Jerry Walden -
Wolfgang Denk