* [ECOS] Problems when aborting tftp transfers @ 2004-07-21 10:52 Øyvind Harboe 2004-08-02 13:01 ` Andrew Lunn 0 siblings, 1 reply; 15+ messages in thread From: Øyvind Harboe @ 2004-07-21 10:52 UTC (permalink / raw) To: ecos-discuss I'm seing problems when aborting tftp transfers: - With CYGSEM_NET_TFTPD_MULTITHREADED == 0, a subsequent tftp transfer after an aborted tftp transfer can get "stuck" since the main tftp server loop is receiving stale packets and hence e.g. _write_file() is invoked for the terminated tftp transfer session(there can be as many as a dozen outstanding stale packets, hence tftp can take a *really* long time to return to normal operation). Q: Is CYGSEM_NET_TFTPD_MULTITHREADED == 0 working as intended for aborted tftp transfers? - I'm not sure this is a problem or just the way tftp works. When I set CYGSEM_NET_TFTPD_MULTITHREADED==1, tftp works even if I abort transfers, but the current tftp transfer session on the eCos end does not return to the main tftp server loop until the current transfer session has exhausted its retries. -- Øyvind Harboe http://www.zylin.com -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [ECOS] Problems when aborting tftp transfers 2004-07-21 10:52 [ECOS] Problems when aborting tftp transfers Øyvind Harboe @ 2004-08-02 13:01 ` Andrew Lunn 2004-08-02 13:45 ` Øyvind Harboe 0 siblings, 1 reply; 15+ messages in thread From: Andrew Lunn @ 2004-08-02 13:01 UTC (permalink / raw) To: ?yvind Harboe; +Cc: ecos-discuss On Wed, Jul 21, 2004 at 12:47:53PM +0200, ?yvind Harboe wrote: > I'm seing problems when aborting tftp transfers: > > - With CYGSEM_NET_TFTPD_MULTITHREADED == 0, a subsequent tftp transfer > after an aborted tftp transfer can get "stuck" since the main tftp > server loop is receiving stale packets and hence e.g. _write_file() is > invoked for the terminated tftp transfer session(there can be as many as > a dozen outstanding stale packets, hence tftp can take a *really* long > time to return to normal operation). Q: Is > CYGSEM_NET_TFTPD_MULTITHREADED == 0 working as intended for aborted tftp > transfers? > > - I'm not sure this is a problem or just the way tftp works. When I set > CYGSEM_NET_TFTPD_MULTITHREADED==1, tftp works even if I abort transfers, > but the current tftp transfer session on the eCos end does not return to > the main tftp server loop until the current transfer session has > exhausted its retries. I don't follow what you are taking about here. Could you give some more details, describe how you produce the problems, what goes wrong and how you would expect it to act. Thanks Andrew -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [ECOS] Problems when aborting tftp transfers 2004-08-02 13:01 ` Andrew Lunn @ 2004-08-02 13:45 ` Øyvind Harboe 2004-08-02 14:02 ` Andrew Lunn 0 siblings, 1 reply; 15+ messages in thread From: Øyvind Harboe @ 2004-08-02 13:45 UTC (permalink / raw) To: Andrew Lunn; +Cc: ecos-discuss On Mon, 2004-08-02 at 15:01, Andrew Lunn wrote: > On Wed, Jul 21, 2004 at 12:47:53PM +0200, ?yvind Harboe wrote: > > I'm seing problems when aborting tftp transfers: > > > > - With CYGSEM_NET_TFTPD_MULTITHREADED == 0, a subsequent tftp transfer > > after an aborted tftp transfer can get "stuck" since the main tftp > > server loop is receiving stale packets and hence e.g. _write_file() is > > invoked for the terminated tftp transfer session(there can be as many as > > a dozen outstanding stale packets, hence tftp can take a *really* long > > time to return to normal operation). Q: Is > > CYGSEM_NET_TFTPD_MULTITHREADED == 0 working as intended for aborted tftp > > transfers? > > > > - I'm not sure this is a problem or just the way tftp works. When I set > > CYGSEM_NET_TFTPD_MULTITHREADED==1, tftp works even if I abort transfers, > > but the current tftp transfer session on the eCos end does not return to > > the main tftp server loop until the current transfer session has > > exhausted its retries. > > I don't follow what you are taking about here. Could you give some > more details, describe how you produce the problems, what goes wrong > and how you would expect it to act. here is what I did: - with CYGSEM_NET_TFTPD_MULTITHREADED=0. - started a tftp transfer from Windows machine - aborted it on the Windows end - at this point the tftp server goes back to the main loop and sees multiple tftp transfer initiation requests from the aborted transfer session. Eventually, the tftp server times out and recovers, but his takes a *very* long time(minutes at least). - since I only have a single tftp server thread, subsequent tftp transfer requests will fail while the tftp server is busy timing out on the obsolete session initiation requests. If this rewording does not help explain things, I could try formulating a patch. > Thanks > Andrew -- Øyvind Harboe http://www.zylin.com -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [ECOS] Problems when aborting tftp transfers 2004-08-02 13:45 ` Øyvind Harboe @ 2004-08-02 14:02 ` Andrew Lunn 2004-08-02 14:14 ` Øyvind Harboe 2004-08-03 6:40 ` [ECOS] Problems when aborting tftp transfers Øyvind Harboe 0 siblings, 2 replies; 15+ messages in thread From: Andrew Lunn @ 2004-08-02 14:02 UTC (permalink / raw) To: ?yvind Harboe; +Cc: ecos-discuss On Mon, Aug 02, 2004 at 03:45:01PM +0200, ?yvind Harboe wrote: > On Mon, 2004-08-02 at 15:01, Andrew Lunn wrote: > > On Wed, Jul 21, 2004 at 12:47:53PM +0200, ?yvind Harboe wrote: > > > I'm seing problems when aborting tftp transfers: > > > > > > - With CYGSEM_NET_TFTPD_MULTITHREADED == 0, a subsequent tftp transfer > > > after an aborted tftp transfer can get "stuck" since the main tftp > > > server loop is receiving stale packets and hence e.g. _write_file() is > > > invoked for the terminated tftp transfer session(there can be as many as > > > a dozen outstanding stale packets, hence tftp can take a *really* long > > > time to return to normal operation). Q: Is > > > CYGSEM_NET_TFTPD_MULTITHREADED == 0 working as intended for aborted tftp > > > transfers? > > > > > > - I'm not sure this is a problem or just the way tftp works. When I set > > > CYGSEM_NET_TFTPD_MULTITHREADED==1, tftp works even if I abort transfers, > > > but the current tftp transfer session on the eCos end does not return to > > > the main tftp server loop until the current transfer session has > > > exhausted its retries. > > > > I don't follow what you are taking about here. Could you give some > > more details, describe how you produce the problems, what goes wrong > > and how you would expect it to act. > > here is what I did: > > - with CYGSEM_NET_TFTPD_MULTITHREADED=0. > - started a tftp transfer from Windows machine > - aborted it on the Windows end Does the M$ end send an error packet to terminate the transfer or simply stop sending data packets? > - at this point the tftp server goes back to the main loop and sees > multiple tftp transfer initiation requests from the aborted transfer > session. Initiation requests? You mean WRQ packets from the tftp client you have just killed? That would be strange. Andrew -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [ECOS] Problems when aborting tftp transfers 2004-08-02 14:02 ` Andrew Lunn @ 2004-08-02 14:14 ` Øyvind Harboe 2004-08-02 14:27 ` Andrew Lunn 2004-08-03 6:40 ` [ECOS] Problems when aborting tftp transfers Øyvind Harboe 1 sibling, 1 reply; 15+ messages in thread From: Øyvind Harboe @ 2004-08-02 14:14 UTC (permalink / raw) To: Andrew Lunn; +Cc: ecos-discuss On Mon, 2004-08-02 at 16:02, Andrew Lunn wrote: > On Mon, Aug 02, 2004 at 03:45:01PM +0200, ?yvind Harboe wrote: > > On Mon, 2004-08-02 at 15:01, Andrew Lunn wrote: > > > On Wed, Jul 21, 2004 at 12:47:53PM +0200, ?yvind Harboe wrote: > > > > I'm seing problems when aborting tftp transfers: > > > > > > > > - With CYGSEM_NET_TFTPD_MULTITHREADED == 0, a subsequent tftp transfer > > > > after an aborted tftp transfer can get "stuck" since the main tftp > > > > server loop is receiving stale packets and hence e.g. _write_file() is > > > > invoked for the terminated tftp transfer session(there can be as many as > > > > a dozen outstanding stale packets, hence tftp can take a *really* long > > > > time to return to normal operation). Q: Is > > > > CYGSEM_NET_TFTPD_MULTITHREADED == 0 working as intended for aborted tftp > > > > transfers? > > > > > > > > - I'm not sure this is a problem or just the way tftp works. When I set > > > > CYGSEM_NET_TFTPD_MULTITHREADED==1, tftp works even if I abort transfers, > > > > but the current tftp transfer session on the eCos end does not return to > > > > the main tftp server loop until the current transfer session has > > > > exhausted its retries. > > > > > > I don't follow what you are taking about here. Could you give some > > > more details, describe how you produce the problems, what goes wrong > > > and how you would expect it to act. > > > > here is what I did: > > > > - with CYGSEM_NET_TFTPD_MULTITHREADED=0. > > - started a tftp transfer from Windows machine > > - aborted it on the Windows end > > Does the M$ end send an error packet to terminate the transfer or > simply stop sending data packets? I don't know what ctrl-c does(I haven't got the equipment wired up so I can't test right now), but surely terminating the process would cause an error packet not to be transferred? > > - at this point the tftp server goes back to the main loop and sees > > multiple tftp transfer initiation requests from the aborted transfer > > session. > > Initiation requests? You mean WRQ packets from the tftp client you > have just killed? Yes. I really don't speak PPP, TCP/IP, Windows and tftp well enough to pick this apart without more study. Perhaps this is something that was lingering in the PPP channel or tcp/ip stack... > That would be strange. Setting CYGSEM_NET_TFTPD_MULTITHREADED=1 fixes the problem because the original port is closed + reopened. > > Andrew -- Øyvind Harboe http://www.zylin.com -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [ECOS] Problems when aborting tftp transfers 2004-08-02 14:14 ` Øyvind Harboe @ 2004-08-02 14:27 ` Andrew Lunn 2004-08-02 14:49 ` [ECOS] Question on wigglers, debugging Redboot in flash for the XScale target in single step mode Krishna Ganugapati 0 siblings, 1 reply; 15+ messages in thread From: Andrew Lunn @ 2004-08-02 14:27 UTC (permalink / raw) To: ?yvind Harboe; +Cc: ecos-discuss > > Does the M$ end send an error packet to terminate the transfer or > > simply stop sending data packets? > > I don't know what ctrl-c does(I haven't got the equipment wired up so I > can't test right now), but surely terminating the process would cause an > error packet not to be transferred? In the unix world, i would expect the application to trap ^C so that it can do a clean shutdown. I don't know if M$ does this. Anyway, this is probably not the real problem, its only an optimization. Since TFTP is based on UDP, the error packet can get lost so the real method is based on timeouts. It should give up after 30 seconds. > > > - at this point the tftp server goes back to the main loop and sees > > > multiple tftp transfer initiation requests from the aborted transfer > > > session. > > > > Initiation requests? You mean WRQ packets from the tftp client you > > have just killed? > > Yes. > > I really don't speak PPP, TCP/IP, Windows and tftp well enough to pick > this apart without more study. > > Perhaps this is something that was lingering in the PPP channel or > tcp/ip stack... That does not make sense. We need a trace of packets being transfered to be able to understand this further. Use windump or something similar on the M$ box to get a packet capture so we can see what is going on. Andrew -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss ^ permalink raw reply [flat|nested] 15+ messages in thread
* [ECOS] Question on wigglers, debugging Redboot in flash for the XScale target in single step mode 2004-08-02 14:27 ` Andrew Lunn @ 2004-08-02 14:49 ` Krishna Ganugapati 2004-08-02 14:59 ` Gary Thomas 0 siblings, 1 reply; 15+ messages in thread From: Krishna Ganugapati @ 2004-08-02 14:49 UTC (permalink / raw) To: ecos-discuss Hello, I'm looking for some clarification on the following issues. Target;: Custom IXP425 XScale (almost identical to the IXDP development board, minus the highspeed UART and minus the LEDs), Redboot in ROM mode. Debugging interface: Macraigor Wiggler, OCD Commander for the software debugger on the host. Situation: I can successfully download my redboot rom image to Flash using the Wiggler and the Macraigor Flash Programmer. When I reset my target, I connect to the JTAG port using the OCD Commander debugger and attempt to single step through instructions. Results 1) Through the OCD Debugger, I note that Flash memory is correctly relocated at 0x000000000. 2) Using the OCD Debugger, I can manual configure the SDRAM registers and determine that my SDRAM acc ANy recess is good. I flip the EXP_BUS_CONFIGURATION bits that switc SDRAM and Flash around and determine that SDRAM is now located at 0x00000000 - I can successfully read and write words to the first 256 MB so I am assuming memory is good. 3) Reset the board, board is now in bootup mode, flash is at 0x00000000. I now attempt to single step through my redboot rom image. On the first instruction, the board transfers control to the reset handler. Questions: a) Has anyone seen behavior like this? b) On the web it looks like quite a few people have seen something like this, but there have been no followups on how to fix this. c) When I reviewed the XScale documentation, it says that when a debugger executes a single step instruction, a debug event handler is expected and that this debug event handler is overloaded at the reset handler. It also says that the debug event handler code needs to be downloaded to the target through the JTAG. Questions: i) Does the OCD Commander software debugger interface actually download a debug event handler? If it does, then my conclusions are wrong and I have to look elsewhere for why things in single step are not progressing, but if I'm right, then perhaps I need a more sophisticated debugger for my JTAG interface (the OCD Commander is free). Any recommendations Other clarifications: 1) One thing that was not very clear in XScale little endian vs big endian modes was the opcode fetch modes for the XScale. After investigating, my understanding is that whether in big endian or in little endian mode, XScale opcode fetches are always in little endian mode. Which is why when you build a big endian target for the XScale IXP425 board which generates the instructions in big endian mode, you need to byte swap the image. Is this correct? Thanks for any input. Krishna -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [ECOS] Question on wigglers, debugging Redboot in flash for the XScale target in single step mode 2004-08-02 14:49 ` [ECOS] Question on wigglers, debugging Redboot in flash for the XScale target in single step mode Krishna Ganugapati @ 2004-08-02 14:59 ` Gary Thomas 2004-08-02 15:15 ` [ECOS] Question on wigglers, debugging Redboot in flash forthe " Krishna Ganugapati 0 siblings, 1 reply; 15+ messages in thread From: Gary Thomas @ 2004-08-02 14:59 UTC (permalink / raw) To: Krishna Ganugapati; +Cc: ecos-discuss On Mon, 2004-08-02 at 08:49, Krishna Ganugapati wrote: > Hello, > > I'm looking for some clarification on the following issues. > > Target;: Custom IXP425 XScale (almost identical to the IXDP development > board, minus the highspeed UART and minus the LEDs), Redboot in ROM mode. > Debugging interface: Macraigor Wiggler, OCD Commander for the software > debugger on the host. > > Situation: I can successfully download my redboot rom image to Flash using > the Wiggler and the Macraigor Flash Programmer. > When I reset my target, I connect to the JTAG port using the OCD Commander > debugger and attempt to single step through instructions. > > Results > > 1) Through the OCD Debugger, I note that Flash memory is correctly relocated > at 0x000000000. > 2) Using the OCD Debugger, I can manual configure the SDRAM registers and > determine that my SDRAM acc ANy recess is good. I flip the > EXP_BUS_CONFIGURATION bits that switc SDRAM and Flash around and determine > that SDRAM is now located at 0x00000000 - I can successfully read and write > words to the first 256 MB so I am assuming memory is good. > > 3) Reset the board, board is now in bootup mode, flash is at 0x00000000. I > now attempt to single step through my redboot rom image. On the first > instruction, the board transfers control to the reset handler. > > Questions: > > a) Has anyone seen behavior like this? > b) On the web it looks like quite a few people have seen something like > this, but there have been no followups on how to fix this. > c) When I reviewed the XScale documentation, it says that when a debugger > executes a single step instruction, a debug event handler is expected and > that this debug event handler is overloaded at the reset handler. It also > says that the debug event handler code needs to be downloaded to the target > through the JTAG. Questions: > i) Does the OCD Commander software debugger interface actually download > a debug event handler? If it does, then my conclusions are wrong and I have > to look elsewhere for why things in single step are not progressing, but if > I'm right, then perhaps I need a more sophisticated debugger for my JTAG > interface (the OCD Commander is free). Any recommendations Why do you think this is wrong? When you reset the board, single stepping (via hardware which is very different that what you describe in item "c" above), you should execute the "reset handler" an instruction at a time. This is just what is supposed to happen. > > Other clarifications: > 1) One thing that was not very clear in XScale little endian vs big endian > modes was the opcode fetch modes for the XScale. After investigating, my > understanding is that whether in big endian or in little endian mode, > XScale opcode fetches are always in little endian mode. Which is why when > you build a big endian target for the XScale IXP425 board which generates > the instructions in big endian mode, you need to byte swap the image. Is > this correct? > > Thanks for any input. > > Krishna -- Gary Thomas <gary@mlbassoc.com> MLB Associates -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [ECOS] Question on wigglers, debugging Redboot in flash forthe XScale target in single step mode 2004-08-02 14:59 ` Gary Thomas @ 2004-08-02 15:15 ` Krishna Ganugapati 2004-08-02 15:21 ` Gary Thomas 0 siblings, 1 reply; 15+ messages in thread From: Krishna Ganugapati @ 2004-08-02 15:15 UTC (permalink / raw) To: Gary Thomas; +Cc: ecos-discuss Gary, Thanks for the response. I'm afraid I don't quite understand what you're saying.. a) > Why do you think this is wrong? When you reset the board, single > stepping (via hardware which is very different that what you describe in > item "c" above), you should execute the "reset handler" an instruction > at a time. This is just what is supposed to happen. Are you saying that this is correct behavior? When I hit the reset vector, I'm stuck.. subsequent single steps only keep me at the reset vector - I don't advance any further.. b) How do I debug my redboot image? ------------------------------------------------- ----- Original Message ----- From: "Gary Thomas" <gary@mlbassoc.com> To: "Krishna Ganugapati" <krishnag@marakicorp.com> Cc: <ecos-discuss@sources.redhat.com> Sent: Monday, August 02, 2004 7:59 AM Subject: Re: [ECOS] Question on wigglers, debugging Redboot in flash forthe XScale target in single step mode > On Mon, 2004-08-02 at 08:49, Krishna Ganugapati wrote: > > Hello, > > > > I'm looking for some clarification on the following issues. > > > > Target;: Custom IXP425 XScale (almost identical to the IXDP development > > board, minus the highspeed UART and minus the LEDs), Redboot in ROM mode. > > Debugging interface: Macraigor Wiggler, OCD Commander for the software > > debugger on the host. > > > > Situation: I can successfully download my redboot rom image to Flash using > > the Wiggler and the Macraigor Flash Programmer. > > When I reset my target, I connect to the JTAG port using the OCD Commander > > debugger and attempt to single step through instructions. > > > > Results > > > > 1) Through the OCD Debugger, I note that Flash memory is correctly relocated > > at 0x000000000. > > 2) Using the OCD Debugger, I can manual configure the SDRAM registers and > > determine that my SDRAM acc ANy recess is good. I flip the > > EXP_BUS_CONFIGURATION bits that switc SDRAM and Flash around and determine > > that SDRAM is now located at 0x00000000 - I can successfully read and write > > words to the first 256 MB so I am assuming memory is good. > > > > 3) Reset the board, board is now in bootup mode, flash is at 0x00000000. I > > now attempt to single step through my redboot rom image. On the first > > instruction, the board transfers control to the reset handler. > > > > Questions: > > > > a) Has anyone seen behavior like this? > > b) On the web it looks like quite a few people have seen something like > > this, but there have been no followups on how to fix this. > > c) When I reviewed the XScale documentation, it says that when a debugger > > executes a single step instruction, a debug event handler is expected and > > that this debug event handler is overloaded at the reset handler. It also > > says that the debug event handler code needs to be downloaded to the target > > through the JTAG. Questions: > > i) Does the OCD Commander software debugger interface actually download > > a debug event handler? If it does, then my conclusions are wrong and I have > > to look elsewhere for why things in single step are not progressing, but if > > I'm right, then perhaps I need a more sophisticated debugger for my JTAG > > interface (the OCD Commander is free). Any recommendations > > Why do you think this is wrong? When you reset the board, single > stepping (via hardware which is very different that what you describe in > item "c" above), you should execute the "reset handler" an instruction > at a time. This is just what is supposed to happen. > > > > > Other clarifications: > > 1) One thing that was not very clear in XScale little endian vs big endian > > modes was the opcode fetch modes for the XScale. After investigating, my > > understanding is that whether in big endian or in little endian mode, > > XScale opcode fetches are always in little endian mode. Which is why when > > you build a big endian target for the XScale IXP425 board which generates > > the instructions in big endian mode, you need to byte swap the image. Is > > this correct? > > > > Thanks for any input. > > > > Krishna > -- > Gary Thomas <gary@mlbassoc.com> > MLB Associates > -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [ECOS] Question on wigglers, debugging Redboot in flash forthe XScale target in single step mode 2004-08-02 15:15 ` [ECOS] Question on wigglers, debugging Redboot in flash forthe " Krishna Ganugapati @ 2004-08-02 15:21 ` Gary Thomas 2004-08-02 16:51 ` [ECOS] Question on wigglers, debugging Redboot in flash fortheXScale " Krishna Ganugapati 2004-08-03 15:59 ` Krishna Ganugapati 0 siblings, 2 replies; 15+ messages in thread From: Gary Thomas @ 2004-08-02 15:21 UTC (permalink / raw) To: Krishna Ganugapati; +Cc: ecos-discuss On Mon, 2004-08-02 at 09:12, Krishna Ganugapati wrote: > Gary, Thanks for the response. > > I'm afraid I don't quite understand what you're saying.. > > a) > Why do you think this is wrong? When you reset the board, single > > stepping (via hardware which is very different that what you describe in > > item "c" above), you should execute the "reset handler" an instruction > > at a time. This is just what is supposed to happen. > > Are you saying that this is correct behavior? Yes. > > When I hit the reset vector, I'm stuck.. subsequent single steps only keep > me at the reset vector - I don't advance any further.. > > b) How do I debug my redboot image? Figure out the answer to why single step doesn't progress, then you'll be able to debug RedBoot. You _should_ be able to do this with the hardware you have, but alas you may have problems. Given that MacRaigor doesn't really support OCD and the Wiggler is pretty primitive and ... You might consider getting a more powerful debug tool, especially if debugging hardware [initialization] is new to you. One of the best available is the BDI2000 from Abatron, but there are many others. > ------------------------------------------------- > ----- Original Message ----- > From: "Gary Thomas" <gary@mlbassoc.com> > To: "Krishna Ganugapati" <krishnag@marakicorp.com> > Cc: <ecos-discuss@sources.redhat.com> > Sent: Monday, August 02, 2004 7:59 AM > Subject: Re: [ECOS] Question on wigglers, debugging Redboot in flash forthe > XScale target in single step mode > > > > On Mon, 2004-08-02 at 08:49, Krishna Ganugapati wrote: > > > Hello, > > > > > > I'm looking for some clarification on the following issues. > > > > > > Target;: Custom IXP425 XScale (almost identical to the IXDP development > > > board, minus the highspeed UART and minus the LEDs), Redboot in ROM > mode. > > > Debugging interface: Macraigor Wiggler, OCD Commander for the software > > > debugger on the host. > > > > > > Situation: I can successfully download my redboot rom image to Flash > using > > > the Wiggler and the Macraigor Flash Programmer. > > > When I reset my target, I connect to the JTAG port using the OCD > Commander > > > debugger and attempt to single step through instructions. > > > > > > Results > > > > > > 1) Through the OCD Debugger, I note that Flash memory is correctly > relocated > > > at 0x000000000. > > > 2) Using the OCD Debugger, I can manual configure the SDRAM registers > and > > > determine that my SDRAM acc ANy recess is good. I flip the > > > EXP_BUS_CONFIGURATION bits that switc SDRAM and Flash around and > determine > > > that SDRAM is now located at 0x00000000 - I can successfully read and > write > > > words to the first 256 MB so I am assuming memory is good. > > > > > > 3) Reset the board, board is now in bootup mode, flash is at 0x00000000. > I > > > now attempt to single step through my redboot rom image. On the first > > > instruction, the board transfers control to the reset handler. > > > > > > Questions: > > > > > > a) Has anyone seen behavior like this? > > > b) On the web it looks like quite a few people have seen something like > > > this, but there have been no followups on how to fix this. > > > c) When I reviewed the XScale documentation, it says that when a > debugger > > > executes a single step instruction, a debug event handler is expected > and > > > that this debug event handler is overloaded at the reset handler. It > also > > > says that the debug event handler code needs to be downloaded to the > target > > > through the JTAG. Questions: > > > i) Does the OCD Commander software debugger interface actually > download > > > a debug event handler? If it does, then my conclusions are wrong and I > have > > > to look elsewhere for why things in single step are not progressing, but > if > > > I'm right, then perhaps I need a more sophisticated debugger for my JTAG > > > interface (the OCD Commander is free). Any recommendations > > > > Why do you think this is wrong? When you reset the board, single > > stepping (via hardware which is very different that what you describe in > > item "c" above), you should execute the "reset handler" an instruction > > at a time. This is just what is supposed to happen. > > > > > > > > Other clarifications: > > > 1) One thing that was not very clear in XScale little endian vs big > endian > > > modes was the opcode fetch modes for the XScale. After investigating, my > > > understanding is that whether in big endian or in little endian mode, > > > XScale opcode fetches are always in little endian mode. Which is why > when > > > you build a big endian target for the XScale IXP425 board which > generates > > > the instructions in big endian mode, you need to byte swap the image. Is > > > this correct? > > > > > > Thanks for any input. > > > > > > Krishna > > -- > > Gary Thomas <gary@mlbassoc.com> > > MLB Associates > > -- Gary Thomas <gary@mlbassoc.com> MLB Associates -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [ECOS] Question on wigglers, debugging Redboot in flash fortheXScale target in single step mode 2004-08-02 15:21 ` Gary Thomas @ 2004-08-02 16:51 ` Krishna Ganugapati 2004-08-03 15:59 ` Krishna Ganugapati 1 sibling, 0 replies; 15+ messages in thread From: Krishna Ganugapati @ 2004-08-02 16:51 UTC (permalink / raw) To: Gary Thomas; +Cc: ecos-discuss Thanks Gary. I'm investigating why the single step fails, (I've sent logs to Macraigor). Thanks for the tip on BDI2000 - I hope to switch debuggers and JTAG devices. -- Krishna ------------------------------------------------- ----- Original Message ----- From: "Gary Thomas" <gary@mlbassoc.com> To: "Krishna Ganugapati" <krishnag@marakicorp.com> Cc: <ecos-discuss@sources.redhat.com> Sent: Monday, August 02, 2004 8:20 AM Subject: Re: [ECOS] Question on wigglers, debugging Redboot in flash fortheXScale target in single step mode > On Mon, 2004-08-02 at 09:12, Krishna Ganugapati wrote: > > Gary, Thanks for the response. > > > > I'm afraid I don't quite understand what you're saying.. > > > > a) > Why do you think this is wrong? When you reset the board, single > > > stepping (via hardware which is very different that what you describe in > > > item "c" above), you should execute the "reset handler" an instruction > > > at a time. This is just what is supposed to happen. > > > > Are you saying that this is correct behavior? > > Yes. > > > > > When I hit the reset vector, I'm stuck.. subsequent single steps only keep > > me at the reset vector - I don't advance any further.. > > > > b) How do I debug my redboot image? > > Figure out the answer to why single step doesn't progress, then you'll > be able to debug RedBoot. You _should_ be able to do this with the > hardware you have, but alas you may have problems. Given that MacRaigor > doesn't really support OCD and the Wiggler is pretty primitive and ... > > You might consider getting a more powerful debug tool, especially if > debugging hardware [initialization] is new to you. One of the best > available is the BDI2000 from Abatron, but there are many others. > > > ------------------------------------------------- > > ----- Original Message ----- > > From: "Gary Thomas" <gary@mlbassoc.com> > > To: "Krishna Ganugapati" <krishnag@marakicorp.com> > > Cc: <ecos-discuss@sources.redhat.com> > > Sent: Monday, August 02, 2004 7:59 AM > > Subject: Re: [ECOS] Question on wigglers, debugging Redboot in flash forthe > > XScale target in single step mode > > > > > > > On Mon, 2004-08-02 at 08:49, Krishna Ganugapati wrote: > > > > Hello, > > > > > > > > I'm looking for some clarification on the following issues. > > > > > > > > Target;: Custom IXP425 XScale (almost identical to the IXDP development > > > > board, minus the highspeed UART and minus the LEDs), Redboot in ROM > > mode. > > > > Debugging interface: Macraigor Wiggler, OCD Commander for the software > > > > debugger on the host. > > > > > > > > Situation: I can successfully download my redboot rom image to Flash > > using > > > > the Wiggler and the Macraigor Flash Programmer. > > > > When I reset my target, I connect to the JTAG port using the OCD > > Commander > > > > debugger and attempt to single step through instructions. > > > > > > > > Results > > > > > > > > 1) Through the OCD Debugger, I note that Flash memory is correctly > > relocated > > > > at 0x000000000. > > > > 2) Using the OCD Debugger, I can manual configure the SDRAM registers > > and > > > > determine that my SDRAM acc ANy recess is good. I flip the > > > > EXP_BUS_CONFIGURATION bits that switc SDRAM and Flash around and > > determine > > > > that SDRAM is now located at 0x00000000 - I can successfully read and > > write > > > > words to the first 256 MB so I am assuming memory is good. > > > > > > > > 3) Reset the board, board is now in bootup mode, flash is at 0x00000000. > > I > > > > now attempt to single step through my redboot rom image. On the first > > > > instruction, the board transfers control to the reset handler. > > > > > > > > Questions: > > > > > > > > a) Has anyone seen behavior like this? > > > > b) On the web it looks like quite a few people have seen something like > > > > this, but there have been no followups on how to fix this. > > > > c) When I reviewed the XScale documentation, it says that when a > > debugger > > > > executes a single step instruction, a debug event handler is expected > > and > > > > that this debug event handler is overloaded at the reset handler. It > > also > > > > says that the debug event handler code needs to be downloaded to the > > target > > > > through the JTAG. Questions: > > > > i) Does the OCD Commander software debugger interface actually > > download > > > > a debug event handler? If it does, then my conclusions are wrong and I > > have > > > > to look elsewhere for why things in single step are not progressing, but > > if > > > > I'm right, then perhaps I need a more sophisticated debugger for my JTAG > > > > interface (the OCD Commander is free). Any recommendations > > > > > > Why do you think this is wrong? When you reset the board, single > > > stepping (via hardware which is very different that what you describe in > > > item "c" above), you should execute the "reset handler" an instruction > > > at a time. This is just what is supposed to happen. > > > > > > > > > > > Other clarifications: > > > > 1) One thing that was not very clear in XScale little endian vs big > > endian > > > > modes was the opcode fetch modes for the XScale. After investigating, my > > > > understanding is that whether in big endian or in little endian mode, > > > > XScale opcode fetches are always in little endian mode. Which is why > > when > > > > you build a big endian target for the XScale IXP425 board which > > generates > > > > the instructions in big endian mode, you need to byte swap the image. Is > > > > this correct? > > > > > > > > Thanks for any input. > > > > > > > > Krishna > > > -- > > > Gary Thomas <gary@mlbassoc.com> > > > MLB Associates > > > > -- > Gary Thomas <gary@mlbassoc.com> > MLB Associates > > > -- > Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos > and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss > -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [ECOS] Question on wigglers, debugging Redboot in flash fortheXScale target in single step mode 2004-08-02 15:21 ` Gary Thomas 2004-08-02 16:51 ` [ECOS] Question on wigglers, debugging Redboot in flash fortheXScale " Krishna Ganugapati @ 2004-08-03 15:59 ` Krishna Ganugapati 1 sibling, 0 replies; 15+ messages in thread From: Krishna Ganugapati @ 2004-08-03 15:59 UTC (permalink / raw) To: Gary Thomas; +Cc: ecos-discuss Hello Gary and others. I figured out why my OCD Commander single step was not working... I thoight I'd post this for anyone else who might be planning to debug rom code through OCD Commander From Macraigor: As I've noted, I can upload my flash memory without trouble, I can dump disassemble and write data to both flash and memory, which indicates my internal bus is fine. On single step I get a target bus error 25:11 and I do not know how to interpret it. You need to move the minIcache (containing the JTAG monitor) out of the way of your flash . By default the miniIcache starts out mapped to 0x0 - 2K, You need to enter on the OCD Commander's command line : "xmon 0x500000" (valid address values are 0 - 0x1000000) this will move the miniIcache to an area that is not going to be executed by your load image. You should then be able to step and run without a problem. Once I did this, it worked beautifully. Sadly, after several dozen instructions, in the process of attempting the first store operation, it fails with a Read Large: Target Bus Error 41:11. The interesting thing here is this is the first set of instructions that attempt to write the Configuration Register values. Prior to this all the instructions are about setting the endianness (from default little to big), invalidating the caches, configuring the MMU etc. All these prior instructions manipulate data between the registers, the coprocessor regisrters and some load immediate instructions. The instructions that forces the error is a str r0, [r1] where both r0 and r1 are good. I asked Macraigor what this is - still waiting to hear from them.... ------------------------------------------------- ----- Original Message ----- From: "Gary Thomas" <gary@mlbassoc.com> To: "Krishna Ganugapati" <krishnag@marakicorp.com> Cc: <ecos-discuss@sources.redhat.com> Sent: Monday, August 02, 2004 8:20 AM Subject: Re: [ECOS] Question on wigglers, debugging Redboot in flash fortheXScale target in single step mode > On Mon, 2004-08-02 at 09:12, Krishna Ganugapati wrote: > > Gary, Thanks for the response. > > > > I'm afraid I don't quite understand what you're saying.. > > > > a) > Why do you think this is wrong? When you reset the board, single > > > stepping (via hardware which is very different that what you describe in > > > item "c" above), you should execute the "reset handler" an instruction > > > at a time. This is just what is supposed to happen. > > > > Are you saying that this is correct behavior? > > Yes. > > > > > When I hit the reset vector, I'm stuck.. subsequent single steps only keep > > me at the reset vector - I don't advance any further.. > > > > b) How do I debug my redboot image? > > Figure out the answer to why single step doesn't progress, then you'll > be able to debug RedBoot. You _should_ be able to do this with the > hardware you have, but alas you may have problems. Given that MacRaigor > doesn't really support OCD and the Wiggler is pretty primitive and ... > > You might consider getting a more powerful debug tool, especially if > debugging hardware [initialization] is new to you. One of the best > available is the BDI2000 from Abatron, but there are many others. > > > ------------------------------------------------- > > ----- Original Message ----- > > From: "Gary Thomas" <gary@mlbassoc.com> > > To: "Krishna Ganugapati" <krishnag@marakicorp.com> > > Cc: <ecos-discuss@sources.redhat.com> > > Sent: Monday, August 02, 2004 7:59 AM > > Subject: Re: [ECOS] Question on wigglers, debugging Redboot in flash forthe > > XScale target in single step mode > > > > > > > On Mon, 2004-08-02 at 08:49, Krishna Ganugapati wrote: > > > > Hello, > > > > > > > > I'm looking for some clarification on the following issues. > > > > > > > > Target;: Custom IXP425 XScale (almost identical to the IXDP development > > > > board, minus the highspeed UART and minus the LEDs), Redboot in ROM > > mode. > > > > Debugging interface: Macraigor Wiggler, OCD Commander for the software > > > > debugger on the host. > > > > > > > > Situation: I can successfully download my redboot rom image to Flash > > using > > > > the Wiggler and the Macraigor Flash Programmer. > > > > When I reset my target, I connect to the JTAG port using the OCD > > Commander > > > > debugger and attempt to single step through instructions. > > > > > > > > Results > > > > > > > > 1) Through the OCD Debugger, I note that Flash memory is correctly > > relocated > > > > at 0x000000000. > > > > 2) Using the OCD Debugger, I can manual configure the SDRAM registers > > and > > > > determine that my SDRAM acc ANy recess is good. I flip the > > > > EXP_BUS_CONFIGURATION bits that switc SDRAM and Flash around and > > determine > > > > that SDRAM is now located at 0x00000000 - I can successfully read and > > write > > > > words to the first 256 MB so I am assuming memory is good. > > > > > > > > 3) Reset the board, board is now in bootup mode, flash is at 0x00000000. > > I > > > > now attempt to single step through my redboot rom image. On the first > > > > instruction, the board transfers control to the reset handler. > > > > > > > > Questions: > > > > > > > > a) Has anyone seen behavior like this? > > > > b) On the web it looks like quite a few people have seen something like > > > > this, but there have been no followups on how to fix this. > > > > c) When I reviewed the XScale documentation, it says that when a > > debugger > > > > executes a single step instruction, a debug event handler is expected > > and > > > > that this debug event handler is overloaded at the reset handler. It > > also > > > > says that the debug event handler code needs to be downloaded to the > > target > > > > through the JTAG. Questions: > > > > i) Does the OCD Commander software debugger interface actually > > download > > > > a debug event handler? If it does, then my conclusions are wrong and I > > have > > > > to look elsewhere for why things in single step are not progressing, but > > if > > > > I'm right, then perhaps I need a more sophisticated debugger for my JTAG > > > > interface (the OCD Commander is free). Any recommendations > > > > > > Why do you think this is wrong? When you reset the board, single > > > stepping (via hardware which is very different that what you describe in > > > item "c" above), you should execute the "reset handler" an instruction > > > at a time. This is just what is supposed to happen. > > > > > > > > > > > Other clarifications: > > > > 1) One thing that was not very clear in XScale little endian vs big > > endian > > > > modes was the opcode fetch modes for the XScale. After investigating, my > > > > understanding is that whether in big endian or in little endian mode, > > > > XScale opcode fetches are always in little endian mode. Which is why > > when > > > > you build a big endian target for the XScale IXP425 board which > > generates > > > > the instructions in big endian mode, you need to byte swap the image. Is > > > > this correct? > > > > > > > > Thanks for any input. > > > > > > > > Krishna > > > -- > > > Gary Thomas <gary@mlbassoc.com> > > > MLB Associates > > > > -- > Gary Thomas <gary@mlbassoc.com> > MLB Associates > > > -- > Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos > and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss > -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [ECOS] Problems when aborting tftp transfers 2004-08-02 14:02 ` Andrew Lunn 2004-08-02 14:14 ` Øyvind Harboe @ 2004-08-03 6:40 ` Øyvind Harboe 2004-08-03 9:49 ` Andrew Lunn 1 sibling, 1 reply; 15+ messages in thread From: Øyvind Harboe @ 2004-08-03 6:40 UTC (permalink / raw) To: Andrew Lunn; +Cc: ecos-discuss I haven't got the setup available right now, but I think I remember the steps to reproduce a bit better: 1. start tftp transfer 2. abort tftp transfer 3. at this point the new tftp server thread is waiting for timeout on #1 4. start new tftp transfer 5. wait a bit(but not long enough for tftp transfer to start). 6. abort tftp transfer 7. at this point the tftp server is stuck in the main loop timing out on WRQ requests. Each WRQ request requires a tftpd_write_file() to time out, so this takes a loooong time. My working theory is that the Windows tftp client, in #4, filled up the socket with WRQ requests while it was trying to get in touch with the tftp server. Closing and opening the sockets, which happens as an unintended(?) side effect of setting CYGSEM_NET_TFTPD_MULTITHREADED=1, flushes any such obsolete WRQ requests. Once I some time and my hands on the system again, I'll run the above tests and try to capture some packages. I'll also try to remove Windows from the equation by reproducing the problem with a Linux tftp client. -- Øyvind Harboe http://www.zylin.com -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [ECOS] Problems when aborting tftp transfers 2004-08-03 6:40 ` [ECOS] Problems when aborting tftp transfers Øyvind Harboe @ 2004-08-03 9:49 ` Andrew Lunn 2004-08-03 9:56 ` Øyvind Harboe 0 siblings, 1 reply; 15+ messages in thread From: Andrew Lunn @ 2004-08-03 9:49 UTC (permalink / raw) To: ?yvind Harboe; +Cc: ecos-discuss On Tue, Aug 03, 2004 at 08:40:46AM +0200, ?yvind Harboe wrote: > I haven't got the setup available right now, but I think I remember the steps > to reproduce a bit better: > > 1. start tftp transfer > 2. abort tftp transfer > 3. at this point the new tftp server thread is waiting for timeout on > #1 > 4. start new tftp transfer > 5. wait a bit(but not long enough for tftp transfer to start). > 6. abort tftp transfer > 7. at this point the tftp server is stuck in the main loop timing out on > WRQ requests. Each WRQ request requires a tftpd_write_file() to time out, so > this takes a loooong time. This now make sense. It is the starting of the new connection before the old one times out that causes the delay. Since the system is single threaded it has two choices when the new connection request arrives. The current implementation simply buffers the request until later. The alternative implementation would be to discard the request and let the client retry. Both implementations are probably correct but have pros and cons. All these aborted connections is a corner case that should not happen very often so i would not worry about it. Having said that, i think the real solution is to teach your users to have some patients and not abort the connections.... Andrew -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [ECOS] Problems when aborting tftp transfers 2004-08-03 9:49 ` Andrew Lunn @ 2004-08-03 9:56 ` Øyvind Harboe 0 siblings, 0 replies; 15+ messages in thread From: Øyvind Harboe @ 2004-08-03 9:56 UTC (permalink / raw) To: Andrew Lunn; +Cc: ecos-discuss On Tue, 2004-08-03 at 11:49, Andrew Lunn wrote: > On Tue, Aug 03, 2004 at 08:40:46AM +0200, ?yvind Harboe wrote: > > I haven't got the setup available right now, but I think I remember the steps > > to reproduce a bit better: > > > > 1. start tftp transfer > > 2. abort tftp transfer > > 3. at this point the new tftp server thread is waiting for timeout on > > #1 > > 4. start new tftp transfer > > 5. wait a bit(but not long enough for tftp transfer to start). > > 6. abort tftp transfer > > 7. at this point the tftp server is stuck in the main loop timing out on > > WRQ requests. Each WRQ request requires a tftpd_write_file() to time out, so > > this takes a loooong time. > > This now make sense. It is the starting of the new connection before > the old one times out that causes the delay. Since the system is > single threaded it has two choices when the new connection request > arrives. The current implementation simply buffers the request until > later. The alternative implementation would be to discard the request > and let the client retry. Both implementations are probably correct > but have pros and cons. All these aborted connections is a corner case > that should not happen very often so i would not worry about it. > > Having said that, i think the real solution is to teach your users to > have some patients and not abort the connections.... :-) The problem is that the timeout is *very* long because it is number of queued WRQ (ca 5) * timeout for tftpd_write_file(). A single timeout is acceptable, but minutes is very confusing for the user. > Andrew -- Øyvind Harboe http://www.zylin.com -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss ^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2004-08-03 15:59 UTC | newest] Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2004-07-21 10:52 [ECOS] Problems when aborting tftp transfers Øyvind Harboe 2004-08-02 13:01 ` Andrew Lunn 2004-08-02 13:45 ` Øyvind Harboe 2004-08-02 14:02 ` Andrew Lunn 2004-08-02 14:14 ` Øyvind Harboe 2004-08-02 14:27 ` Andrew Lunn 2004-08-02 14:49 ` [ECOS] Question on wigglers, debugging Redboot in flash for the XScale target in single step mode Krishna Ganugapati 2004-08-02 14:59 ` Gary Thomas 2004-08-02 15:15 ` [ECOS] Question on wigglers, debugging Redboot in flash forthe " Krishna Ganugapati 2004-08-02 15:21 ` Gary Thomas 2004-08-02 16:51 ` [ECOS] Question on wigglers, debugging Redboot in flash fortheXScale " Krishna Ganugapati 2004-08-03 15:59 ` Krishna Ganugapati 2004-08-03 6:40 ` [ECOS] Problems when aborting tftp transfers Øyvind Harboe 2004-08-03 9:49 ` Andrew Lunn 2004-08-03 9:56 ` Øyvind Harboe
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).