Menu
▾
▴
openocd-devel
|
From: Brian H. <b.h...@gm...> - 2008-07-24 21:37:43
|
Hi, Could someone point me in the right direction so I don't go in the weeds too far? I know this is mostly for ARM but I would really like to take a interface line the Amontec JAGKey Tiny and make an adaptor to match the pinouts of an AMD Elan SC520 (Soekris net4526 board to be more specific). I'd like to know how to take the BSDL file I have for the SC520 and what all I would need to do to get a JTAG interface working with it and what I would need to do in order to use OpenOCD tools with it. I would also like to use GDB in order to debug the target so would looking at the ARM GDB Server be a start to figure out how to port such a thing to the SC520? I've always been a user of commercial JTAG products and now want to learn how this all really works so I can tinker with boards at home on a low cost basis. Thank you! Brian |
|
From: Ø. H. <oyv...@zy...> - 2008-07-25 08:25:00
|
> I would also like to use GDB in order to debug the target so would looking > at the ARM GDB Server be a start to figure out how to port such a thing to > the SC520? Take a look at the MIPS branch. Perhaps you can start by porting over the MIPS stuff to trunk as an exercise? :-) I'd like to have MIPS in main trunk even if it is work in progress as long as the risk of interference and regression is medium to low. https://lists.berlios.de/pipermail/openocd-development/2008-June/002261.html -- Øyvind Harboe http://www.zylin.com/zy1000.html ARM7 ARM9 XScale Cortex JTAG debugger and flash programmer |
|
From: Brian H. <b.h...@gm...> - 2008-07-25 19:26:47
|
I'll check out the MIPS branch. I'll have to look around at all the devices I have here at home and see if any of them are MIPS based. I don't think they are. Off the top of my head, they are all ARM 7/9, MPC860, x86, or Broadcom. The x86 Soekris board looks like the easiest to play with to learn on. On Fri, Jul 25, 2008 at 2:24 AM, Øyvind Harboe <oyv...@zy...> wrote: > > I would also like to use GDB in order to debug the target so would > looking > > at the ARM GDB Server be a start to figure out how to port such a thing > to > > the SC520? > > Take a look at the MIPS branch. > > Perhaps you can start by porting over the MIPS stuff to trunk as an > exercise? :-) > > I'd like to have MIPS in main trunk even if it is work in progress as long > as > the risk of interference and regression is medium to low. > > > https://lists.berlios.de/pipermail/openocd-development/2008-June/002261.html > > -- > Øyvind Harboe > http://www.zylin.com/zy1000.html > ARM7 ARM9 XScale Cortex > JTAG debugger and flash programmer > |
|
From: Ø. H. <oyv...@zy...> - 2008-07-25 19:29:44
|
On Fri, Jul 25, 2008 at 7:26 PM, Brian Hutchinson <b.h...@gm...> wrote: > I'll check out the MIPS branch. I'll have to look around at all the devices > I have here at home and see if any of them are MIPS based. I don't think > they are. Off the top of my head, they are all ARM 7/9, MPC860, x86, or > Broadcom. The x86 Soekris board looks like the easiest to play with to > learn on. The reason I mentioned the MIPS branch is that it is an example of how to add non-ARM target... If you want to make a patch for some other CPU, I'd like to see that against trunk and if it looks like danger of collateral damage is limited, then I'd like to apply a non-ARM example to trunk, even if it is work in progress. -- Øyvind Harboe http://www.zylin.com/zy1000.html ARM7 ARM9 XScale Cortex JTAG debugger and flash programmer |
|
From: Brian H. <b.h...@gm...> - 2008-07-25 21:50:25
|
I'll check it out to try an come up to speed with the project. Any other pointers are welcome if anyone thinks of things I should look at. Regards, Brian On Fri, Jul 25, 2008 at 1:29 PM, Øyvind Harboe <oyv...@zy...> wrote: > On Fri, Jul 25, 2008 at 7:26 PM, Brian Hutchinson <b.h...@gm...> > wrote: > > I'll check out the MIPS branch. I'll have to look around at all the > devices > > I have here at home and see if any of them are MIPS based. I don't think > > they are. Off the top of my head, they are all ARM 7/9, MPC860, x86, or > > Broadcom. The x86 Soekris board looks like the easiest to play with to > > learn on. > > > The reason I mentioned the MIPS branch is that it is an example of how to > add non-ARM target... If you want to make a patch for some other CPU, > I'd like to see that against trunk and if it looks like danger of > collateral > damage is limited, then I'd like to apply a non-ARM example to trunk, > even if it is work in progress. > > > > -- > Øyvind Harboe > http://www.zylin.com/zy1000.html > ARM7 ARM9 XScale Cortex > JTAG debugger and flash programmer > |
|
From: Magnus L. <lu...@ml...> - 2008-07-26 00:38:37
|
Hi
I think it can be useful to compare the Cortex-M3 code which implements
the arm_v7m architecture to the targets that descends from the armv_7_9.
The usage and dependency looks as follows:
target.c - General target framwork,
common to all targets
armv7m.c - Basic architecture methods -
specific to armv7m targets
cortex_m3.c - Target specific metods -
specific to the cortexm3 cores
cortex_swjdp.c - Debug interface methods - the
swjdp debug model uséd in, but not exclusive to, the cortex m3
jtag.c - General JTAG framework,
common to all JTAG based target debuggers
They all implements the methods in the target.c interface, and they all
use jtag.c to communicate with the the target debug hardware.
They share methods to handle target endienaess, data word sizes and the
external interfaces to gdb,
The specific processors with onboard flash need flash interfaces, but
this is no different from arm targets.
So adding a non arm target is not more difficult than this..... And a
lot of small details ... but thats just the fun part.
Regards
Magnus
Brian Hutchinson wrote:
> I'll check it out to try an come up to speed with the project. Any
> other pointers are welcome if anyone thinks of things I should look at.
>
> Regards,
>
> Brian
>
> On Fri, Jul 25, 2008 at 1:29 PM, Øyvind Harboe
> <oyv...@zy... <mailto:oyv...@zy...>> wrote:
>
> On Fri, Jul 25, 2008 at 7:26 PM, Brian Hutchinson
> <b.h...@gm... <mailto:b.h...@gm...>> wrote:
> > I'll check out the MIPS branch. I'll have to look around at all
> the devices
> > I have here at home and see if any of them are MIPS based. I
> don't think
> > they are. Off the top of my head, they are all ARM 7/9, MPC860,
> x86, or
> > Broadcom. The x86 Soekris board looks like the easiest to play
> with to
> > learn on.
>
>
> The reason I mentioned the MIPS branch is that it is an example of
> how to
> add non-ARM target... If you want to make a patch for some other CPU,
> I'd like to see that against trunk and if it looks like danger of
> collateral
> damage is limited, then I'd like to apply a non-ARM example to trunk,
> even if it is work in progress.
>
>
>
> --
> Øyvind Harboe
> http://www.zylin.com/zy1000.html
> ARM7 ARM9 XScale Cortex
> JTAG debugger and flash programmer
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Openocd-development mailing list
> Ope...@li...
> https://lists.berlios.de/mailman/listinfo/openocd-development
>
|
|
From: Dominic R. <Dom...@gm...> - 2008-07-25 08:51:48
|
On Thursday 24 July 2008 21:37:41 Brian Hutchinson wrote: > Hi, > > Could someone point me in the right direction so I don't go in the weeds > too far? > > I know this is mostly for ARM but I would really like to take a interface > line the Amontec JAGKey Tiny and make an adaptor to match the pinouts of an > AMD Elan SC520 (Soekris net4526 board to be more specific). > > I'd like to know how to take the BSDL file I have for the SC520 and what > all I would need to do to get a JTAG interface working with it and what I > would need to do in order to use OpenOCD tools with it. Boundary scan does not offer any debugging features. It gives you control over the external pins of the device. > I would also like to use GDB in order to debug the target so would looking > at the ARM GDB Server be a start to figure out how to port such a thing to > the SC520? Debugging requires support from dedicated on-chip debug circuitry. Apparently the Elan SC520 has something they call "AMDebug", which probably does what you want, but I'm not sure if the necessary information is publicly available. > I've always been a user of commercial JTAG products and now want to learn > how this all really works so I can tinker with boards at home on a low cost > basis. > > Thank you! > > Brian Best regards, Dominic |
|
From: Brian H. <b.h...@gm...> - 2008-07-25 19:20:11
|
On Fri, Jul 25, 2008 at 2:51 AM, Dominic Rath <Dom...@gm...> wrote: > On Thursday 24 July 2008 21:37:41 Brian Hutchinson wrote: > > Hi, > > > > Could someone point me in the right direction so I don't go in the weeds > > too far? > > > > I know this is mostly for ARM but I would really like to take a interface > > line the Amontec JAGKey Tiny and make an adaptor to match the pinouts of > an > > AMD Elan SC520 (Soekris net4526 board to be more specific). > > > > I'd like to know how to take the BSDL file I have for the SC520 and what > > all I would need to do to get a JTAG interface working with it and what I > > would need to do in order to use OpenOCD tools with it. > > Boundary scan does not offer any debugging features. It gives you control > over > the external pins of the device. I've used commercial debuggers that use the 4 JTAG signals in order to establish a debugging session and I know the ARM guys have gdbserver going so I know it is possible ... I just don't know how to go about learning it. That is why I'm posting ... so you guys can "show me the way". Right now I would be just happy being able to flash the Soekris board I'm using as I would like to port a different bios to it but I would like to learn how to get gdb to work over the jtag link in the future. > > > I would also like to use GDB in order to debug the target so would > looking > > at the ARM GDB Server be a start to figure out how to port such a thing > to > > the SC520? > > Debugging requires support from dedicated on-chip debug circuitry. > Apparently > the Elan SC520 has something they call "AMDebug", which probably does what > you want, but I'm not sure if the necessary information is publicly > available. AMDebug is a propritery AMD thing that I'm not interested in. > > > > I've always been a user of commercial JTAG products and now want to learn > > how this all really works so I can tinker with boards at home on a low > cost > > basis. > > > > Thank you! > > > > Brian > > Best regards, > > Dominic > _______________________________________________ > Openocd-development mailing list > Ope...@li... > https://lists.berlios.de/mailman/listinfo/openocd-development > |
|
From: Dominic R. <Dom...@gm...> - 2008-07-25 19:47:03
|
On Friday 25 July 2008 19:20:08 you wrote: > I've used commercial debuggers that use the 4 JTAG signals in order to > establish a debugging session Have you debugged x86 targets that way? Is is possible for e.g. ARM (though without reset signals you're rather limited). > and I know the ARM guys have gdbserver going > so I know it is possible ... I just don't know how to go about learning it. gdbserver uses the debug functionality provided by the underlying platform, e.g. Linux. When talking to bare metal, you need that debug functionality in the hardware. For ARM (7, 9, ...), that's the EmbeddedICE macrocell. > That is why I'm posting ... so you guys can "show me the way". > > Right now I would be just happy being able to flash the Soekris board I'm > using as I would like to port a different bios to it but I would like to > learn how to get gdb to work over the jtag link in the future. It is possible to flash via boundary scan, but it is generally not possible to debug that way. > > Debugging requires support from dedicated on-chip debug circuitry. > > Apparently > > the Elan SC520 has something they call "AMDebug", which probably does > > what you want, but I'm not sure if the necessary information is publicly > > available. > > AMDebug is a propritery AMD thing that I'm not interested in. You'll probably have to look for another platform then. PowerPCs come with a debug interface, but there's little or no documentation to get hold off. MIPS support is still in an early state afaik, as Øyvind suggested it would be great if someone looked after the code in the MIPS branch. The Atmel controllers provide debug support, too, the AVR32 for example might be a nice target. Regards, Dominic |
|
From: Kishore <kit...@gm...> - 2008-07-25 20:21:11
|
On Friday 25 Jul 2008 11:16:57 pm Dominic Rath wrote: > You'll probably have to look for another platform then. PowerPCs come with > a debug interface, but there's little or no documentation to get hold off. > MIPS support is still in an early state afaik, as Øyvind suggested it would > be great if someone looked after the code in the MIPS branch. The Atmel > controllers provide debug support, too, the AVR32 for example might be a > nice target Hi. Sorry for going off topic in here. I have been following this list though not in great detail and i seem to have lost track somewhere. Is openocd tending towards being universal tool for all processor types rather than just ARM? Could one expect that one day it would support AVR[32] through the JTAGICE-MKII (and maybe others) and replacing the current avarice? I have nothing against this and would definitely appreciate the ability of one tool that aids in working with all embedded platforms that i work with. Just curious! ;) -- Cheers! Kishore |
|
From: Dominic R. <Dom...@gm...> - 2008-07-25 20:26:11
|
On Friday 25 July 2008 20:21:02 Kishore wrote: > On Friday 25 Jul 2008 11:16:57 pm Dominic Rath wrote: > > You'll probably have to look for another platform then. PowerPCs come > > with a debug interface, but there's little or no documentation to get > > hold off. MIPS support is still in an early state afaik, as Øyvind > > suggested it would be great if someone looked after the code in the MIPS > > branch. The Atmel controllers provide debug support, too, the AVR32 for > > example might be a nice target > > Hi. Sorry for going off topic in here. I have been following this list > though not in great detail and i seem to have lost track somewhere. Is > openocd tending towards being universal tool for all processor types rather > than just ARM? Could one expect that one day it would support AVR[32] > through the JTAGICE-MKII (and maybe others) and replacing the current > avarice? I have nothing against this and would definitely appreciate the > ability of one tool that aids in working with all embedded platforms that i > work with. Just curious! ;) Heh, world domination is of course the ultimate goal... the limitation to ARM comes from ARM being easily available, relatively simple, supported by rich documentation, etc. PowerPC for example would be great, but the devices are a lot more expensive, and documentation is impossible to get. It would be great if we could get support for other processors as well. Regards, Dominic |
|
From: Ø. H. <oyv...@zy...> - 2008-07-25 21:30:40
|
On Fri, Jul 25, 2008 at 8:21 PM, Kishore <kit...@gm...> wrote: > On Friday 25 Jul 2008 11:16:57 pm Dominic Rath wrote: >> You'll probably have to look for another platform then. PowerPCs come with >> a debug interface, but there's little or no documentation to get hold off. >> MIPS support is still in an early state afaik, as Øyvind suggested it would >> be great if someone looked after the code in the MIPS branch. The Atmel >> controllers provide debug support, too, the AVR32 for example might be a >> nice target > > Hi. Sorry for going off topic in here. I have been following this list though > not in great detail and i seem to have lost track somewhere. Is openocd > tending towards being universal tool for all processor types rather than just > ARM? Could one expect that one day it would support AVR[32] through the > JTAGICE-MKII (and maybe others) and replacing the current avarice? I have > nothing against this and would definitely appreciate the ability of one tool > that aids in working with all embedded platforms that i work with. Just > curious! ;) OpenOCD will go the direction of contributions. If there are contributors (testing, documentation & code) for a particular direction then OpenOCD will go in that direction pretty much. Code can get deleted if nobody tests or maintains it and it is becoming a burden. That said, there is interest in making OpenOCD much more instruction set agnostic. Currently there are ARM32 instruction hardcoded into various drivers and this causes headaches for Cortex that is ARM thumb only. There has been some thoughts on how to be able to write target code in C rather than position independent hardcoded machine code and there are in fact two flash drivers that operate on this principle. Also, we already have a MIPS in a branch, that I'm hoping someone will bring into trunk so we can migrate towards more CPU independent code. W.r.t. JTAG on the backend, there is of course a JTAG layer there today, but if someone contributes a different physical layer(BDM?), then I don't see why we shouldn't accept that as well. -- Øyvind Harboe http://www.zylin.com/zy1000.html ARM7 ARM9 XScale Cortex JTAG debugger and flash programmer |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X