Re: [OpenOCD-devel] Remote 'g' packet reply is too long
It has been a few years, but I used to hit this on x86 too. If I correctly recall... The kernel is loading in 32b mode initially before switching to 64b mode. Your gdb is set to 64b mode. I think the way to get around this is to set a break on a symbol after the kernel has switched to 64b mode. continue until you hit that symbol and then everything will work. You can set 'set arch' in gdb to change the arch. On Mon, Mar 12, 2012 at 11:09 AM, Justin Drake wrote: > I am using OpenOCD and DGB to talk with my ARM Cortex 3M chip. When I > load my .elf file onto GDB, the moment I connect to my board (target > remote localhost:) I get the error message: > > Remote 'g' packet reply is too long: > fc01002001202001 > > Reading about the issue, I gather it might be a 32bit vs 64bit issue. > How can I fix this? > > -- > Try before you buy = See our experts in action! > The most comprehensive online learning library for Microsoft developers > is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, > Metro Style Apps, more. Free future releases when you subscribe now! > http://p.sf.net/sfu/learndevnow-dev2 > ___ > OpenOCD-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/openocd-devel -- Jon Smirl [email protected] -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ OpenOCD-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/openocd-devel
[OpenOCD-devel] using ft2232 for AVR
Is this something that could be added to openocd to allow it to support AVR processors? http://www.lura.sk/?&LP=111EN&MP=4&ML=3&PO=%27%27 I have a JTAGICEMK2 but a lot of people complain that it costs $300. -- Jon Smirl [email protected] -- Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev ___ OpenOCD-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/openocd-devel
[OpenOCD-devel] Bit banging SWD
We're designing a new board that uses a MIPS based RT5350. The RT5350 doesn't have any ADC support so the idea is to also add a Cortex-M0 on the board. The Cortex would look like an I2C device to the MIPS CPU. The MIPS CPU can be initialized via JTAG and it runs Linux. So is it feasible to run OpenOCD on the MIPS then bit bang SWD over some GPIO to initially program the flash on the Cortex? This is my first SWD design so I'm still figuring things out. -- Jon Smirl [email protected] -- Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis & visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter___ OpenOCD-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/openocd-devel
Re: [OpenOCD-devel] Bit banging SWD
On Mon, Apr 22, 2013 at 4:49 PM, Andreas Fritiofson < [email protected]> wrote: > On Mon, Apr 22, 2013 at 9:22 PM, [email protected] wrote: > >> We're designing a new board that uses a MIPS based RT5350. The RT5350 >> doesn't have any ADC support so the idea is to also add a Cortex-M0 on the >> board. The Cortex would look like an I2C device to the MIPS CPU. >> >> The MIPS CPU can be initialized via JTAG and it runs Linux. So is it >> feasible to run OpenOCD on the MIPS then bit bang SWD over some GPIO to >> initially program the flash on the Cortex? >> >> This is my first SWD design so I'm still figuring things out. >> >> > That sounds extremely complex, considering for one thing that OpenOCD > doesn't even officially support SWD yet. > > I think you would be better off selecting a Cortex-Mx µC that includes a > boot loader in ROM. I think most do. At least I know that many, if not all, > ST devices do. They can be programmed over a simple UART protocol, or some > even via USB or CAN. > > Since you still need JTAG for the MIPS you could also pick an only > slightly more expensive Cortex with JTAG and connect it in the chain. For > field upgrades you could still want to have a boot loader on the Cortex, of > course. > We use the LPC3130 on another board that has the ROM bootloader over UART feature. I was looking for something with JTAG or UART boot and I haven't identified one in the $2.00 range. Maybe a STM32F051K4U6? I'll check out the datasheet. -- Jon Smirl [email protected] -- Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis & visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter___ OpenOCD-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/openocd-devel
Re: [OpenOCD-devel] Bit banging SWD
On Mon, Apr 22, 2013 at 5:30 PM, [email protected] wrote: > > > > On Mon, Apr 22, 2013 at 4:49 PM, Andreas Fritiofson < > [email protected]> wrote: > >> On Mon, Apr 22, 2013 at 9:22 PM, [email protected] >> wrote: >> >>> We're designing a new board that uses a MIPS based RT5350. The RT5350 >>> doesn't have any ADC support so the idea is to also add a Cortex-M0 on the >>> board. The Cortex would look like an I2C device to the MIPS CPU. >>> >>> The MIPS CPU can be initialized via JTAG and it runs Linux. So is it >>> feasible to run OpenOCD on the MIPS then bit bang SWD over some GPIO to >>> initially program the flash on the Cortex? >>> >>> This is my first SWD design so I'm still figuring things out. >>> >>> >> That sounds extremely complex, considering for one thing that OpenOCD >> doesn't even officially support SWD yet. >> >> I think you would be better off selecting a Cortex-Mx µC that includes a >> boot loader in ROM. I think most do. At least I know that many, if not all, >> ST devices do. They can be programmed over a simple UART protocol, or some >> even via USB or CAN. >> >> Since you still need JTAG for the MIPS you could also pick an only >> slightly more expensive Cortex with JTAG and connect it in the chain. For >> field upgrades you could still want to have a boot loader on the Cortex, of >> course. >> > > We use the LPC3130 on another board that has the ROM bootloader over UART > feature. > > I was looking for something with JTAG or UART boot and I haven't > identified one in the $2.00 range. Maybe a STM32F051K4U6? I'll check out > the datasheet. > This board is targeted at hobbyists so I want them to be able to reload the software without needing special hardware. Thanks for the tip. I do like those UART boot loaders. STM32F051K4U6 supports one. I had been looking at Freescale and Nordic Cortex chips which do not have the UART boot ROM. http://www.st.com/st-web-ui/static/active/en/resource/technical/document/application_note/CD00264342.pdf The RT5350 has a UART on it we were leaving open for customer use. Should be possible to jumper it onto the STM32 UART. Maybe I can get create with pin select and not need jumpers. -- Jon Smirl [email protected] -- Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis & visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter___ OpenOCD-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/openocd-devel
Re: [OpenOCD-devel] Bit banging SWD
On Mon, Apr 22, 2013 at 6:19 PM, Peter Stuge wrote: > [email protected] wrote: > > is it feasible to run OpenOCD on the MIPS then bit bang SWD over > > some GPIO to initially program the flash on the Cortex? > > Don't bother with OpenOCD. > > > > This is my first SWD design so I'm still figuring things out. > > Reuse the Black Magic Probe. > Do any of the Black Magic or Versaloon type probes work like a FT2232 and support both JTAG and UART pass through? > > > //Peter > > > -- > Precog is a next-generation analytics platform capable of advanced > analytics on semi-structured data. The platform includes APIs for building > apps and a phenomenal toolset for data science. Developers can use > our toolset for easy data analysis & visualization. Get a free account! > http://www2.precog.com/precogplatform/slashdotnewsletter > ___ > OpenOCD-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/openocd-devel > -- Jon Smirl [email protected] -- Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis & visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter___ OpenOCD-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/openocd-devel
[OpenOCD-devel] Mismatch in number of MIPS registers
OpenOCD is sending 90 registers to gdb but gdb doesn't want 90. What is this 18 unknown registers to handle gdb requests? MIPSNUMCOREREG 38 /* number of mips dummy fp regs fp0 - fp31 + fsr and fir * we also add 18 unknown registers to handle gdb requests */ #define MIPS32NUMFPREGS 34 + 18 But my gdb is complaining about too many regisiters jonsmirl@terra:/home/apps/openwrt$ ./staging_dir/toolchain-mipsel_dsp_gcc-4.7.2_uClibc-0.9.33.2/bin/mipsel-openwrt-linux-uclibc-gdb GNU gdb (Linaro GDB) 7.5-2012.12-1 Copyright (C) 2012 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "--host=x86_64-linux-gnu --target=mipsel-openwrt-linux-uclibc". For bug reporting instructions, please see: <http://bugs.launchpad.net/gdb-linaro/>. (gdb) target remote localhost: Remote debugging using localhost: Remote 'g' packet reply is too long: 62000a0040001050f780c080fc80439d11001050f780d0b2fc80d52ef580ca2ef5800040fb80a02ff580b02ff780ac72fc80ff8160c2fc80d830f58055aa55aa06000100424644202c800060040200800000 (gdb) quit -- Jon Smirl [email protected] -- How ServiceNow helps IT people transform IT departments: 1. A cloud service to automate IT design, transition and operations 2. Dashboards that offer high-level views of enterprise services 3. A single system of record for all IT processes http://p.sf.net/sfu/servicenow-d2d-j ___ OpenOCD-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/openocd-devel
Re: [OpenOCD-devel] Mismatch in number of MIPS registers
I commented out those 18 dummy registers and it seems to be working, What is going on? On Sun, Jun 9, 2013 at 10:33 AM, [email protected] wrote: > OpenOCD is sending 90 registers to gdb but gdb doesn't want 90. What > is this 18 unknown registers to handle gdb requests? > > MIPSNUMCOREREG 38 > > /* number of mips dummy fp regs fp0 - fp31 + fsr and fir > * we also add 18 unknown registers to handle gdb requests */ > > #define MIPS32NUMFPREGS 34 + 18 > > But my gdb is complaining about too many regisiters > > jonsmirl@terra:/home/apps/openwrt$ > ./staging_dir/toolchain-mipsel_dsp_gcc-4.7.2_uClibc-0.9.33.2/bin/mipsel-openwrt-linux-uclibc-gdb > GNU gdb (Linaro GDB) 7.5-2012.12-1 > Copyright (C) 2012 Free Software Foundation, Inc. > License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> > This is free software: you are free to change and redistribute it. > There is NO WARRANTY, to the extent permitted by law. Type "show copying" > and "show warranty" for details. > This GDB was configured as "--host=x86_64-linux-gnu > --target=mipsel-openwrt-linux-uclibc". > For bug reporting instructions, please see: > <http://bugs.launchpad.net/gdb-linaro/>. > (gdb) target remote localhost: > Remote debugging using localhost: > Remote 'g' packet reply is too long: > 62000a0040001050f780c080fc80439d11001050f780d0b2fc80d52ef580ca2ef5800040fb80a02ff580b02ff780ac72fc80ff8160c2fc80d830f58055aa55aa06000100424644202c8000600402008000000000 > (gdb) quit > > > > -- > Jon Smirl > [email protected] -- Jon Smirl [email protected] -- How ServiceNow helps IT people transform IT departments: 1. A cloud service to automate IT design, transition and operations 2. Dashboards that offer high-level views of enterprise services 3. A single system of record for all IT processes http://p.sf.net/sfu/servicenow-d2d-j ___ OpenOCD-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/openocd-devel
[OpenOCD-devel] Why is JTAG so slow?
I'm using an Olimex ARM-USB-OCD. Target is a MIPS based router chip?
openocd seems to be working, it is just painfully slow. It took 15
minutes to download uboot.
> load_image /home/apps/u-boot/uboot.bin 0x8020 bin
99772 bytes written at address 0x8020
downloaded 99772 bytes in 900.955444s (0.108 KiB/s)
source [find interface/arm-usb-ocd.cfg]
set _CHIPNAME rt5350
set _ENDIAN little
set _CPUTAPID 0x1535024f
#daemon configuration
telnet_port
gdb_port
#jtag_speed
adapter_khz 8000
adapter_nsrst_delay 100
jtag_ntrst_delay 100
# jtag scan chain
# format L IRC IRCM IDCODE (Length, IR Capture, IR Capture Mask, IDCODE)
jtag newtap $_CHIPNAME cpu -irlen 5 -ircapture 0x1 -irmask 0x3
-expected-id $_CPUTAPID
set _TARGETNAME [format "%s.cpu" $_CHIPNAME]
target create $_TARGETNAME mips_m4k -endian $_ENDIAN -chain-position
$_TARGETNAME
$_TARGETNAME configure -work-area-phys 0x8004 -work-area-size 4096
$_TARGETNAME configure -event reset-init {
#reset
halt
echo "init SDRAM controller.."
mww 0x1300 0xd1825282
mww 0x1304 0xe0120300
# load_image /home/apps/u-boot/u-boot.bin 0x8000 bin
# resume 0x8000
}
reset_config trst_and_srst
--
Jon Smirl
[email protected]
--
This SF.net email is sponsored by Windows:
Build for Windows Store.
http://p.sf.net/sfu/windows-dev2dev
___
OpenOCD-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/openocd-devel
Re: [OpenOCD-devel] Why is JTAG so slow?
On Thu, Jul 4, 2013 at 5:32 PM, Andreas Fritiofson wrote: > > On Thu, Jul 4, 2013 at 9:32 PM, [email protected] > wrote: >> >> I'm using an Olimex ARM-USB-OCD. Target is a MIPS based router chip? >> openocd seems to be working, it is just painfully slow. It took 15 >> minutes to download uboot. >> >> > load_image /home/apps/u-boot/uboot.bin 0x8020 bin >> 99772 bytes written at address 0x8020 >> downloaded 99772 bytes in 900.955444s (0.108 KiB/s) >> >> >> >> source [find interface/arm-usb-ocd.cfg] > > > For one thing, you should be using the ftdi adapter driver instead of the > ft2232. If you configured OpenOCD with --enable-ftdi, it's a simple matter > of sourcing interface/ftdi/olimex-arm-usb-ocd.cfg instead. I switched that. > > But for this level of (non-)performance, there's a bigger problem than the > adapter driver. Post a -d3 debug log and we'll try to see where all the time > is spent. > > What is at 0x8020? At 0x8004? Is it slow if you load something to > the latter (make sure not to overlap with the working area)? How about > dump_image reads? > > Also make sure you're using a recent enough openocd, including any relevant > pending MIPS patches in gerrit (I have no idea what's relevant, though). I am built from source. I had to add this patch to get it working at all. Those 18 dummy regs don't seem to be needed anymore. diff --git a/src/target/mips32.c b/src/target/mips32.c index d649901..8705ebc 100644 --- a/src/target/mips32.c +++ b/src/target/mips32.c @@ -92,7 +92,7 @@ static struct mips32_core_reg mips32_core_reg_list_arch_info[MIPS32NUMCOREREGS] /* number of mips dummy fp regs fp0 - fp31 + fsr and fir * we also add 18 unknown registers to handle gdb requests */ -#define MIPS32NUMFPREGS (34 + 18) +#define MIPS32NUMFPREGS (34) static uint8_t mips32_gdb_dummy_fp_value[] = {0, 0, 0, 0}; > > I have no experience with MIPS but if I understand correctly, there are > different methods to access memory. Is the fastest one available in use? I am new too MIPS too. Reads are slow... mdw 0x8198 200 Take 20 seconds. mww 0x8198 200 0 is instant register dump is instant This has a lot about using OpenOCD on MIPs that I don't really understand. http://openocd.sourceforge.net/doc/doxygen/html/targetmips.html > > /Andreas > -- Jon Smirl [email protected] -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ OpenOCD-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/openocd-devel
Re: [OpenOCD-devel] Why is JTAG so slow?
On Thu, Jul 4, 2013 at 6:22 PM, [email protected] wrote: > On Thu, Jul 4, 2013 at 5:32 PM, Andreas Fritiofson > wrote: >> >> On Thu, Jul 4, 2013 at 9:32 PM, [email protected] >> wrote: >>> >>> I'm using an Olimex ARM-USB-OCD. Target is a MIPS based router chip? >>> openocd seems to be working, it is just painfully slow. It took 15 >>> minutes to download uboot. >>> >>> > load_image /home/apps/u-boot/uboot.bin 0x8020 bin >>> 99772 bytes written at address 0x8020 >>> downloaded 99772 bytes in 900.955444s (0.108 KiB/s) >>> >>> >>> >>> source [find interface/arm-usb-ocd.cfg] >> >> >> For one thing, you should be using the ftdi adapter driver instead of the >> ft2232. If you configured OpenOCD with --enable-ftdi, it's a simple matter >> of sourcing interface/ftdi/olimex-arm-usb-ocd.cfg instead. > > I switched that. > >> >> But for this level of (non-)performance, there's a bigger problem than the >> adapter driver. Post a -d3 debug log and we'll try to see where all the time >> is spent. > > > >> >> What is at 0x8020? At 0x8004? Is it slow if you load something to >> the latter (make sure not to overlap with the working area)? How about >> dump_image reads? I moved the workarea to 0x8008 . That's 500K which should be plenty far away from uboot. SDRAM is working. I can write a value and get it back. >> >> Also make sure you're using a recent enough openocd, including any relevant >> pending MIPS patches in gerrit (I have no idea what's relevant, though). > > I am built from source. I had to add this patch to get it working at all. > Those 18 dummy regs don't seem to be needed anymore. > > diff --git a/src/target/mips32.c b/src/target/mips32.c > index d649901..8705ebc 100644 > --- a/src/target/mips32.c > +++ b/src/target/mips32.c > @@ -92,7 +92,7 @@ static struct mips32_core_reg > mips32_core_reg_list_arch_info[MIPS32NUMCOREREGS] > /* number of mips dummy fp regs fp0 - fp31 + fsr and fir > * we also add 18 unknown registers to handle gdb requests */ > > -#define MIPS32NUMFPREGS (34 + 18) > +#define MIPS32NUMFPREGS (34) > > static uint8_t mips32_gdb_dummy_fp_value[] = {0, 0, 0, 0}; > > > >> >> I have no experience with MIPS but if I understand correctly, there are >> different methods to access memory. Is the fastest one available in use? > > I am new too MIPS too. > > Reads are slow... > mdw 0x8198 200 > Take 20 seconds. > > mww 0x8198 200 0 > is instant > > register dump is instant > > This has a lot about using OpenOCD on MIPs that I don't really understand. > > http://openocd.sourceforge.net/doc/doxygen/html/targetmips.html > > > > > >> >> /Andreas >> > > > > -- > Jon Smirl > [email protected] -- Jon Smirl [email protected] -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ OpenOCD-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/openocd-devel
Re: [OpenOCD-devel] Why is JTAG so slow?
On Thu, Jul 4, 2013 at 7:40 PM, Drasko DRASKOVIC wrote: > On Thu, Jul 4, 2013 at 11:32 PM, Andreas Fritiofson > wrote: > >> What is at 0x8020? At 0x8004? Is it slow if you load something to >> the latter (make sure not to overlap with the working area)? > > Which reminded me that this might be a cache problem. > > Jon, > can you please try loading to Kseg1, i.e. replace your addresses with > 0xA020 and similar. 0x0020, 0x8020, 0xA020 all are the same 15 minutes I'm loading uboot right after reset and the ROM has run. Have the virtual segments been setup yet? What should I be using for a work area? This is something to do with reads, writes are almost instant. It is like openocd is getting an error on every read. But nothing usual displayed when I ran openocd -d 3 What about those 18 dummy registers I had to remove into order to get started? With them in-place I couldn't start gdb. I can try putting them back and using direct openocd commands. > > Take a look here to get an idea about MIPS virtual memory segments : > http://www.google.com/imgres?biw=1280&bih=651&tbm=isch&tbnid=al_AkHqbkFZBAM:&imgrefurl=http://infocenter.arm.com/help/topic/com.arm.doc.dai0235c/&docid=CXLqk2CTjj0MTM&imgurl=http://infocenter.arm.com/help/topic/com.arm.doc.dai0235c/AN235_migrating_from_mips_to_arm_files/image004.png&w=624&h=398&ei=xAbWUa3kB4SRhQewsoC4Dg&zoom=1&ved=1t:3588,r:0,s:0,i:79&iact=rc&page=1&tbnh=143&tbnw=224&start=0&ndsp=20&tx=113&ty=52 > > BR, > Drasko -- Jon Smirl [email protected] -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ OpenOCD-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/openocd-devel
Re: [OpenOCD-devel] Why is JTAG so slow?
On Thu, Jul 4, 2013 at 10:10 PM, [email protected] wrote: > On Thu, Jul 4, 2013 at 7:40 PM, Drasko DRASKOVIC > wrote: >> On Thu, Jul 4, 2013 at 11:32 PM, Andreas Fritiofson >> wrote: >> >>> What is at 0x8020? At 0x8004? Is it slow if you load something to >>> the latter (make sure not to overlap with the working area)? >> >> Which reminded me that this might be a cache problem. >> >> Jon, >> can you please try loading to Kseg1, i.e. replace your addresses with >> 0xA020 and similar. > > 0x0020, 0x8020, 0xA020 all are the same 15 minutes > I'm loading uboot right after reset and the ROM has run. Have the > virtual segments been setup yet? > What should I be using for a work area? > > This is something to do with reads, writes are almost instant. It is > like openocd is getting an error on every read. But nothing usual > displayed when I ran openocd -d 3 > > What about those 18 dummy registers I had to remove into order to get > started? With them in-place I couldn't start gdb. I can try putting > them back and using direct openocd commands. My build of openocd from git and the one in ubuntu both have the 15 minute load time. This makes the problem much simpler Reads are slow... mdw 0x8198 200 Take 20 seconds. mww 0x8198 200 0 is instant > > > >> >> Take a look here to get an idea about MIPS virtual memory segments : >> http://www.google.com/imgres?biw=1280&bih=651&tbm=isch&tbnid=al_AkHqbkFZBAM:&imgrefurl=http://infocenter.arm.com/help/topic/com.arm.doc.dai0235c/&docid=CXLqk2CTjj0MTM&imgurl=http://infocenter.arm.com/help/topic/com.arm.doc.dai0235c/AN235_migrating_from_mips_to_arm_files/image004.png&w=624&h=398&ei=xAbWUa3kB4SRhQewsoC4Dg&zoom=1&ved=1t:3588,r:0,s:0,i:79&iact=rc&page=1&tbnh=143&tbnw=224&start=0&ndsp=20&tx=113&ty=52 >> >> BR, >> Drasko > > > > -- > Jon Smirl > [email protected] -- Jon Smirl [email protected] -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ OpenOCD-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/openocd-devel
Re: [OpenOCD-devel] Why is JTAG so slow?
All of the delay is happening inside mips32_pracc_exec(). When I read 200 bytes it will go through the inner while loop 1,000 times. -- Jon Smirl [email protected] -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ OpenOCD-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/openocd-devel
Re: [OpenOCD-devel] Why is JTAG so slow?
On Fri, Jul 5, 2013 at 4:37 AM, Drasko DRASKOVIC wrote: > Hi Jon, > > On Fri, Jul 5, 2013 at 4:10 AM, [email protected] wrote: >> On Thu, Jul 4, 2013 at 7:40 PM, Drasko DRASKOVIC >> wrote: >>> On Thu, Jul 4, 2013 at 11:32 PM, Andreas Fritiofson >>> wrote: >>> >>>> What is at 0x8020? At 0x8004? Is it slow if you load something to >>>> the latter (make sure not to overlap with the working area)? >>> >>> Which reminded me that this might be a cache problem. >>> >>> Jon, >>> can you please try loading to Kseg1, i.e. replace your addresses with >>> 0xA020 and similar. >> >> 0x0020, 0x8020, 0xA020 all are the same 15 minutes >> I'm loading uboot right after reset and the ROM has run. Have the >> virtual segments been setup yet? > > Yes, this is HW setup. > >> What should I be using for a work area? > > Exactly non-cachable region, 0xA. Work area is where EJTAG > miniprograms (that assembly that you see in mips32_pracc.c) > >> >> This is something to do with reads, writes are almost instant. It is >> like openocd is getting an error on every read. But nothing usual >> displayed when I ran openocd -d 3 > > What I was most concerned is to see if mips32_pracc_fastdata_xfer() > gets called, or you are reading byte by byte (long). > >> >> What about those 18 dummy registers I had to remove into order to get >> started? With them in-place I couldn't start gdb. I can try putting >> them back and using direct openocd commands. > > Huh... I do not know much about this (did not follow all the > conversation, I'll check it later), but from what I know mips used to > work fine. I can guarantee only till the period of my last commit (I > do not know really what was added later), so can you maybe try git > reseting to that point, just to check. From what i see from git log, > it is a commit 8e198e94712f8e677faffb8e0e3e9e590bae0161. Same problem at your commit. > mdw 0x800001c8 200 takes 20 seconds. Note that my target is a RT5350. Maybe something has changed from the RT3050? All of the delay is happening inside mips32_pracc_exec(). When I read 200 bytes it will go through the inner while loop 1,000 times. > > BR, > Drasko -- Jon Smirl [email protected] -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ OpenOCD-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/openocd-devel
Re: [OpenOCD-devel] Why is JTAG so slow?
On your commit.. $_TARGETNAME configure -work-area-phys 0xA008 -work-area-size 4096 > mdw 0xa1c8 200 No difference in time, about 20 seconds. On Fri, Jul 5, 2013 at 9:04 AM, Drasko DRASKOVIC wrote: > On Fri, Jul 5, 2013 at 2:41 PM, [email protected] wrote: >> Same problem at your commit. >>> mdw 0x81c8 200 >> takes 20 seconds. > > How about: > >> mdw 0xa1c8 200 > > And move work area to 0xa... zone also. > > BR, > Drasko -- Jon Smirl [email protected] -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ OpenOCD-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/openocd-devel
Re: [OpenOCD-devel] Why is JTAG so slow?
On Fri, Jul 5, 2013 at 9:54 AM, [email protected] wrote: > On your commit.. > > $_TARGETNAME configure -work-area-phys 0xA008 -work-area-size 4096 > >> mdw 0xa1c8 200 > > No difference in time, about 20 seconds. I backed up to the commit behind yours, same behavior so it wasn't broken by your commit. Is there a good place in mips32_pracc_exec() to add a printf() to see why it is looping so much? > > > > On Fri, Jul 5, 2013 at 9:04 AM, Drasko DRASKOVIC > wrote: >> On Fri, Jul 5, 2013 at 2:41 PM, [email protected] >> wrote: >>> Same problem at your commit. >>>> mdw 0x81c8 200 >>> takes 20 seconds. >> >> How about: >> >>> mdw 0xa1c8 200 >> >> And move work area to 0xa... zone also. >> >> BR, >> Drasko > > > > -- > Jon Smirl > [email protected] -- Jon Smirl [email protected] -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ OpenOCD-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/openocd-devel
Re: [OpenOCD-devel] Why is JTAG so slow?
On Fri, Jul 5, 2013 at 1:13 PM, Andreas Fritiofson wrote: > On Fri, Jul 5, 2013 at 3:58 PM, [email protected] > wrote: >> >> On Fri, Jul 5, 2013 at 9:54 AM, [email protected] >> wrote: >> > On your commit.. >> > >> > $_TARGETNAME configure -work-area-phys 0xA008 -work-area-size 4096 >> > >> >> mdw 0xa1c8 200 >> > >> > No difference in time, about 20 seconds. >> >> >> I backed up to the commit behind yours, same behavior so it wasn't >> broken by your commit. >> >> Is there a good place in mips32_pracc_exec() to add a printf() to see >> why it is looping so much? >> > > Just a thought... Since you're ending up in mips32_pracc_exec it seems > ejtag_info->mode == 0. And grepping on that one gives, in mips32.c: > > COMMAND_HANDLER(mips32_handle_scan_delay_command) > { > ... > if (ejtag_info->scan_delay >= 200) { > ejtag_info->mode = 0; > command_print(CMD_CTX, "running in legacy mode"); > } else { > ejtag_info->mode = 1; > command_print(CMD_CTX, "running in fast queued mode"); > } > ... > } scan_delay may be the source of the problem > mips_m4k scan_delay scan delay: 200 nsec running in fast queued mode---> not right, >= 20 is legacy > mips_m4k scan_delay 100 scan delay: 100 nsec running in fast queued mode > load_image /home/apps/u-boot/uboot.bin 0xA020 bin 99772 bytes written at address 0xa020 downloaded 99772 bytes in 37.319073s (2.611 KiB/s) > Not blazing fast but a lot better! > > "Fast queued mode" sounds a lot faster than "legacy mode". Can it be used on > your chip? > > Indeed, the mips32_pracc_exec method seems extremely inefficient, as far as > I can tell from a quick glance, executing the JTAG queue at least three > times per pracc access, which in turn are at least three per word read. > > /Andreas > -- Jon Smirl [email protected] -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ OpenOCD-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/openocd-devel
Re: [OpenOCD-devel] Why is JTAG so slow?
reducing scan_delay now lets me load uboot in a reasonable amount of
time. Next problem I am hitting is gdb and openocd disagreeing about
how many registers there are...
To get gdb to initially load at had to remove the 18 dummy regs
Those 18 dummy regs don't seem to be needed anymore.
diff --git a/src/target/mips32.c b/src/target/mips32.c
index d649901..8705ebc 100644
--- a/src/target/mips32.c
+++ b/src/target/mips32.c
@@ -92,7 +92,7 @@ static struct mips32_core_reg
mips32_core_reg_list_arch_info[MIPS32NUMCOREREGS]
/* number of mips dummy fp regs fp0 - fp31 + fsr and fir
* we also add 18 unknown registers to handle gdb requests */
-#define MIPS32NUMFPREGS (34 + 18)
+#define MIPS32NUMFPREGS (34)
static uint8_t mips32_gdb_dummy_fp_value[] = {0, 0, 0, 0};
This is the openocd output from loading uboot...
At the bottom it got a different register mismatch.
Warn : negative acknowledgment, but no packet pending
Warn : negative acknowledgment, but no packet pending
Warn : keep_alive() was not invoked in the 1000ms timelimit. GDB alive
packet not sent! (5868). Workaround: increase "set remotetimeout" in
GDB
Warn : negative acknowledgment, but no packet pending
Warn : negative acknowledgment, but no packet pending
Warn : negative acknowledgment, but no packet pending
Warn : negative acknowledgment, but no packet pending
Warn : negative acknowledgment, but no packet pending
Warn : negative acknowledgment, but no packet pending
Warn : keep_alive() was not invoked in the 1000ms timelimit. GDB alive
packet not sent! (4624). Workaround: increase "set remotetimeout" in
GDB
Warn : negative acknowledgment, but no packet pending
Warn : negative acknowledgment, but no packet pending
Error: gdb sent a packet with wrong register size
Info : dropped 'gdb' connection
--
Jon Smirl
[email protected]
--
This SF.net email is sponsored by Windows:
Build for Windows Store.
http://p.sf.net/sfu/windows-dev2dev
___
OpenOCD-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/openocd-devel
Re: [OpenOCD-devel] Why is JTAG so slow?
Other issues (gdb) si warning: GDB can't find the start of the function at 0x81e4. Fetch addr mismatch, read: ff200200 expected: ff200204 count: 1 Fetch addr mismatch, read: ff2001fc expected: ff200200 count: 0 Fetch addr mismatch, read: ff2001fc expected: ff200200 count: 0 [Remote target] #1 stopped. 0x81e4 in ?? () (gdb) ni warning: GDB can't find the start of the function at 0x81e4. Warning: Cannot insert breakpoint 2. Error accessing memory address 0x80200400: Unknown error -1. Cannot insert breakpoint 1. Error accessing memory address 0x802006cc: Unknown error -1. (gdb) ni Warning: Cannot insert breakpoint 2. Error accessing memory address 0x80200400: Unknown error -1. Cannot insert breakpoint 1. Error accessing memory address 0x802006cc: Unknown error -1. -- Jon Smirl [email protected] -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ OpenOCD-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/openocd-devel
Re: [OpenOCD-devel] Why is JTAG so slow?
Here's the error when gdb sends the wrong register size... Debug: 451 20330 gdb_server.c:2016 gdb_input_inner(): received packet: 'X80217fd0,424:' Debug: 452 20331 gdb_server.c:1323 gdb_write_memory_binary_packet(): addr: 0x80217fd0, len: 0x0424 Debug: 453 20331 target.c:1689 target_write_buffer(): writing buffer of 1060 byte at 0x80217fd0 Debug: 454 20331 mips_m4k.c:976 mips_m4k_write_memory(): address: 0x80217fd0, size: 0x0004, count: 0x0109 Debug: 455 20331 mips_m4k.c:1108 mips_m4k_bulk_write_memory(): address: 0x80217fd0, count: 0x0109 Debug: 456 20331 mips32_pracc.c:1025 mips32_pracc_fastdata_xfer(): mips32_pracc_fastdata_xfer using 0xa008 for write handler Debug: 457 20360 gdb_server.c:2016 gdb_input_inner(): received packet: 'X802183f4,1c8:' Debug: 458 20360 gdb_server.c:1323 gdb_write_memory_binary_packet(): addr: 0x802183f4, len: 0x01c8 Debug: 459 20360 target.c:1689 target_write_buffer(): writing buffer of 456 byte at 0x802183f4 Debug: 460 20360 mips_m4k.c:976 mips_m4k_write_memory(): address: 0x802183f4, size: 0x0004, count: 0x0072 Debug: 461 20360 mips_m4k.c:1108 mips_m4k_bulk_write_memory(): address: 0x802183f4, count: 0x0072 Debug: 462 20360 mips32_pracc.c:1025 mips32_pracc_fastdata_xfer(): mips32_pracc_fastdata_xfer using 0xa008 for write handler Debug: 463 20385 gdb_server.c:2018 gdb_input_inner(): received packet: 'g' Debug: 464 20387 gdb_server.c:2018 gdb_input_inner(): received packet: 'P25=2080' Debug: 465 20387 gdb_server.c:1110 gdb_set_register_packet(): - Error: 466 20387 gdb_server.c:1131 gdb_set_register_packet(): gdb sent a packet with wrong register size. chars 8 str 16 - P25=2080 Debug: 467 20387 gdb_server.c:840 gdb_connection_closed(): GDB Close, Target: rt5350.cpu, state: halted, gdb_actual_connections=0 Debug: 468 20387 target.c:1300 target_call_event_callbacks(): target event 6 (gdb-end) Debug: 469 20387 target.c:1300 target_call_event_callbacks(): target event 24 (gdb-detach) Info : 470 20387 server.c:476 server_loop(): dropped 'gdb' connection -- Jon Smirl [email protected] -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ OpenOCD-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/openocd-devel
Re: [OpenOCD-devel] Why is JTAG so slow?
On Fri, Jul 5, 2013 at 5:11 PM, [email protected] wrote: > Here's the error when gdb sends the wrong register size... I built gdb from current git source to make sure it is the latest. With 'set arch mips:isa32' in gdb I don't get the 'P25=2080' error. It sends P25=2080. If I set arch mips:4000 I get the P25 error. I'm kind of functioning with the gdb from git source. > > Debug: 451 20330 gdb_server.c:2016 gdb_input_inner(): received packet: > 'X80217fd0,424:' > Debug: 452 20331 gdb_server.c:1323 gdb_write_memory_binary_packet(): > addr: 0x80217fd0, len: 0x0424 > Debug: 453 20331 target.c:1689 target_write_buffer(): writing buffer > of 1060 byte at 0x80217fd0 > Debug: 454 20331 mips_m4k.c:976 mips_m4k_write_memory(): address: > 0x80217fd0, size: 0x0004, count: 0x0109 > Debug: 455 20331 mips_m4k.c:1108 mips_m4k_bulk_write_memory(): > address: 0x80217fd0, count: 0x0109 > Debug: 456 20331 mips32_pracc.c:1025 mips32_pracc_fastdata_xfer(): > mips32_pracc_fastdata_xfer using 0xa008 for write handler > Debug: 457 20360 gdb_server.c:2016 gdb_input_inner(): received packet: > 'X802183f4,1c8:' > Debug: 458 20360 gdb_server.c:1323 gdb_write_memory_binary_packet(): > addr: 0x802183f4, len: 0x01c8 > Debug: 459 20360 target.c:1689 target_write_buffer(): writing buffer > of 456 byte at 0x802183f4 > Debug: 460 20360 mips_m4k.c:976 mips_m4k_write_memory(): address: > 0x802183f4, size: 0x0004, count: 0x0072 > Debug: 461 20360 mips_m4k.c:1108 mips_m4k_bulk_write_memory(): > address: 0x802183f4, count: 0x0072 > Debug: 462 20360 mips32_pracc.c:1025 mips32_pracc_fastdata_xfer(): > mips32_pracc_fastdata_xfer using 0xa008 for write handler > Debug: 463 20385 gdb_server.c:2018 gdb_input_inner(): received packet: 'g' > Debug: 464 20387 gdb_server.c:2018 gdb_input_inner(): received packet: > 'P25=2080' > Debug: 465 20387 gdb_server.c:1110 gdb_set_register_packet(): - > Error: 466 20387 gdb_server.c:1131 gdb_set_register_packet(): gdb sent > a packet with wrong register size. chars 8 str 16 - > P25=2080 > Debug: 467 20387 gdb_server.c:840 gdb_connection_closed(): GDB Close, > Target: rt5350.cpu, state: halted, gdb_actual_connections=0 > Debug: 468 20387 target.c:1300 target_call_event_callbacks(): target > event 6 (gdb-end) > Debug: 469 20387 target.c:1300 target_call_event_callbacks(): target > event 24 (gdb-detach) > Info : 470 20387 server.c:476 server_loop(): dropped 'gdb' connection > > > > -- > Jon Smirl > [email protected] -- Jon Smirl [email protected] -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ OpenOCD-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/openocd-devel
Re: [OpenOCD-devel] Why is JTAG so slow?
I was able to debrick my board. But this setup has a lot of issues making it difficult to use for debugging. Twice during the debrick process I got protocol errors and had to restart openocd/gdb. I'm willing to test any new versions. I'll also be more careful about which uboot I load. I got into this problem because I loaded a uboot built for 64MB onto a 32MB board. When uboot relocated, it relocated into non-existent memory. -- Jon Smirl [email protected] -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ OpenOCD-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/openocd-devel
Re: [OpenOCD-devel] Why is JTAG so slow?
On Sat, Jul 6, 2013 at 6:09 AM, Oleksij Rempel wrote: > Am 06.07.2013 11:51, schrieb Andreas Fritiofson: >> On Sat, Jul 6, 2013 at 1:18 AM, [email protected] >> <mailto:[email protected]> > <mailto:[email protected]>> wrote: >> >> I was able to debrick my board. But this setup has a lot of issues >> making it difficult to use for debugging. Twice during the debrick >> process I got protocol errors and had to restart openocd/gdb. > > I have lots of instability issue with one of broadcom-mips based board. > After some testing i would say it is partially jtag adapter issue. > Incorrect pull-ups/downs and, wrong cable and so on will couse different > noise issues. These aren't stability issues, they are 100% reproducible. It could be this Ralink RT5350 core. They have the MIPS DSP option on the CPU. The biggest problem seems to be finding the correct gdb that is matched to what openocd is sending. I tried three different gdbs and they are had problems. gdb built from the project git source was the best, but it still had issues. For example if gdb arch is set to mips:4000 in gdb I get this error: Debug: 464 20387 gdb_server.c:2018 gdb_input_inner(): received packet: 'P25=2080' Debug: 465 20387 gdb_server.c:1110 gdb_set_register_packet(): - Error: 466 20387 gdb_server.c:1131 gdb_set_register_packet(): gdb sent a packet with wrong register size. chars 8 str 16 - P25=2080 Set the architecture to mips:ia32 makes it go away. Or this patch... gdb wouldn't even connect without this fix I am built from source. I had to add this patch to get it working at all. Those 18 dummy regs don't seem to be needed anymore. diff --git a/src/target/mips32.c b/src/target/mips32.c index d649901..8705ebc 100644 --- a/src/target/mips32.c +++ b/src/target/mips32.c @@ -92,7 +92,7 @@ static struct mips32_core_reg mips32_core_reg_list_arch_info[MIPS32NUMCOREREGS] /* number of mips dummy fp regs fp0 - fp31 + fsr and fir * we also add 18 unknown registers to handle gdb requests */ -#define MIPS32NUMFPREGS (34 + 18) +#define MIPS32NUMFPREGS (34) static uint8_t mips32_gdb_dummy_fp_value[] = {0, 0, 0, 0}; As for scan_delay it is defaulting to legacy mode. In legacy mode openocd does so many jtag operations that it simply takes 15 minutes to complete to download. I reduced the scan-delay a little below the legacy mode threshold so that fast-write mode was used. Now the download happens in about 30 seconds. But that's because openocd isn't doing a million JTAG operations on the chip any more. These are also common... they always happen at the same addresses Fetch addr mismatch, read: ff200200 expected: ff200204 count: 1 Fetch addr mismatch, read: ff2001fc expected: ff200200 count: 0 Fetch addr mismatch, read: ff2001fc expected: ff200200 count: 0 Using gdb built from source I was able to set breakpoints. I'm still getting various protocol errors which make openocd and gdb disconnect. But they are disagreements in the command packet contents and are 100% reproducible. I reconnect and they avoid those commands. > > For example i have adapter which works perfectly on Atheros based mips > at 100kHz. And same adapter regularly fail on Broadcom-mips even with > lover speed: 10kHz. > >> >> Did you see this before you lowered scan_delay? Because this is the type >> of errors I'd expect from a too low scan_delay setting. But really, I'm >> just guessing here. Someone with MIPS knowledge will be better suited to >> answer. >> >> /Andreas > > > -- > Regards, > Oleksij > > -- > This SF.net email is sponsored by Windows: > > Build for Windows Store. > > http://p.sf.net/sfu/windows-dev2dev > ___ > OpenOCD-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/openocd-devel -- Jon Smirl [email protected] -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ OpenOCD-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/openocd-devel
Re: [OpenOCD-devel] Mismatch in number of MIPS registers
On Wed, Nov 20, 2013 at 3:50 PM, Gregory Fong wrote: > On Tue, Nov 12, 2013 at 10:07 PM, Paul Fertser wrote: >> On Wed, Nov 13, 2013 at 12:57:41AM +, Gregory Fong wrote: >>> Are there plans to change this? Just verified that HEAD is also broken >>> with mipsel-linux-gnu gdb 7.6.1. Changing >> >> Someone should implement code to enable gdb target description >> generation like 1255b18fc650193094666ba8afd2018089cc9794 for mips32, >> it shouldn't be hard. > > That would be a better solution than just changing the number of dummy > registers listed---if nobody else is currently working on this, I'll > go ahead and make that change. CC me when you post patches and I will check them on the Ralink RT5350 CPU. > > Thanks, > > Gregory > > -- > Shape the Mobile Experience: Free Subscription > Software experts and developers: Be at the forefront of tech innovation. > Intel(R) Software Adrenaline delivers strategic insight and game-changing > conversations that shape the rapidly evolving mobile landscape. Sign up now. > http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk > ___ > OpenOCD-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/openocd-devel -- Jon Smirl [email protected] -- Shape the Mobile Experience: Free Subscription Software experts and developers: Be at the forefront of tech innovation. Intel(R) Software Adrenaline delivers strategic insight and game-changing conversations that shape the rapidly evolving mobile landscape. Sign up now. http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk ___ OpenOCD-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/openocd-devel
