FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor


 
 
LinkBack Thread Tools
 
Old 10-27-2008, 04:42 PM
wireless
 
Default FTDI jtag

Mike Frysinger wrote:

On Friday 12 September 2008, billium wrote:

get openocd from respository, svn checkout
svn://svn.berlios.de/openocd/trunk/openocd and extract


why ? we have an openocd-9999.ebuild which fetches straight from the upstream
site ...


I have to chuckle out loud......


Some time ago, I inquired about using developing on embedded (gentoo)
linux using Eclipse and any sort of TAG/BDM device.



I still remember the (focused) scolding you gave me about how that
was not the *nix way. Command line, burn and churn, etc etc....

As an old (*nix) fart, I rather enjoyed (and agreed with) your prose.
However, the planet is being overrun with young kids that like their
gui-fied tools....



Now you are pointing folks to openocd......?

It was after my visit to the Freescale conference in Orlando, 2007.
I then predicted (learned is more accurate) that many of the vendors
are planning on moving to Eclipse as the support package for
development (BSP: board support packages). It make a lots of sense.
And their FAE's can support Eclipse on a linux or windows platform.



*WOW* What's next?


Maybe we can all agree on a BSP that works well with a JTAG and
Eclipse, and make it an option for Noobs wanting to get into
embedded Gentoo? I think this is an easier sell than GNAP....?
Keeping cost down is a good idea, and my early vote goes for
an Arm9 board.


thoughts?




James
 
Old 10-27-2008, 06:59 PM
Jason
 
Default FTDI jtag

wireless wrote:
> Mike Frysinger wrote:
>> On Friday 12 September 2008, billium wrote:
>>> get openocd from respository, svn checkout
>>> svn://svn.berlios.de/openocd/trunk/openocd and extract
>>
>> why ? we have an openocd-9999.ebuild which fetches straight from the
>> upstream site ...
>
> I have to chuckle out loud......
>
>
> Some time ago, I inquired about using developing on embedded (gentoo)
> linux using Eclipse and any sort of TAG/BDM device.
>
>
> I still remember the (focused) scolding you gave me about how that
> was not the *nix way. Command line, burn and churn, etc etc....
>
> As an old (*nix) fart, I rather enjoyed (and agreed with) your prose.
> However, the planet is being overrun with young kids that like their
> gui-fied tools....
>

Rhetorical Question: How many of those "young kids" are _good_? There
is no shortcut to deep understanding (no, I'm no where close).
Something a GUI obfuscates away, the cli celebrates. But then, we
agree... ;-)

> Now you are pointing folks to openocd......?

Are you implying that openocd is a gui? I think you might be referring
to something else. Here's a quick and dirty:

http://openhardware.net/Embedded_ARM/OpenOCD_JTAG/#testocd

Basically, run openocd from the command line, specifying a config file.
Then telnet into it. ;-)

Someone may have glossed over this with a gui, but that's not what crops
up in google.

> Maybe we can all agree on a BSP that works well with a JTAG and
> Eclipse, and make it an option for Noobs wanting to get into
> embedded Gentoo? I think this is an easier sell than GNAP....?
> Keeping cost down is a good idea, and my early vote goes for
> an Arm9 board.

I haven't needed a jtag for it, since the bootloader was sufficient, but
I like the NSLU2 as a good starter kit. I recently saw one on ebay for
~$30US. I bought mine new years ago for ~$70US.

The next step after that (at least, what I did) was the Gateworks 2348-4
board. Same processor, 4 mini-pci, 2 ethernet, USB as an option. It's
less than $300US. Openocd works with it's parallel jtag programmer. I
haven't needed that yet either, since the bootloader works for me.

The ethernet support is native in the vanilla kernel since about 2.6.21
or .23. As of 2.6.27, the kernel has support for the hardware crypto
engine. IPsec VPN gateway, anyone?

insert 2 cent quote here.

Jason.
 
Old 10-27-2008, 09:00 PM
wireless
 
Default FTDI jtag

Jason wrote:

wireless wrote:

Mike Frysinger wrote:

On Friday 12 September 2008, billium wrote:

get openocd from respository, svn checkout
svn://svn.berlios.de/openocd/trunk/openocd and extract

why ? we have an openocd-9999.ebuild which fetches straight from the
upstream site ...

I have to chuckle out loud......


Some time ago, I inquired about using developing on embedded (gentoo)
linux using Eclipse and any sort of TAG/BDM device.


I still remember the (focused) scolding you gave me about how that
was not the *nix way. Command line, burn and churn, etc etc....

As an old (*nix) fart, I rather enjoyed (and agreed with) your prose.
However, the planet is being overrun with young kids that like their
gui-fied tools....



Rhetorical Question: How many of those "young kids" are _good_? There
is no shortcut to deep understanding (no, I'm no where close).
Something a GUI obfuscates away, the cli celebrates. But then, we
agree... ;-)


Most of what we do is old fashion roll your own state machine, async
programming (8-32) bit processors for products. So any RTOS/executive
is a luxury.... The designs typically used >90% of the resources.

Tight and Spartan still rules the roost in our embedded world.

It does not matter if they are good, they will eventually replace us,
and assembler will rise again, as it's understanding along with a firm
grasp of hardware is essential. Team programming is over rated. We put
one firmware person on each project. Sink or swim, but that's a
different issue.




Now you are pointing folks to openocd......?



Are you implying that openocd is a gui? I think you might be referring
to something else.


Eclipse vs command line.... look at the top of this page:

http://www.yagarto.de/

Second bullet (*works with Elipse*). That's what I refer to a
gui-fied. You interface to a variety of tasks and tools, via a gui.
Granted, many of the parts can and should run on the CLI, but,
it is dam nice to have an IDE to work from, and I'm an old *nix
hack making the statement. Sure you can go to another terminal
session under linux (X) and run a command line tool for what
ever reason, but, working centrally out of an IDE has it's merits,
and it is the industry standard way to write firmware.


If you work with Code Composer (TI) or CodeWarrior (Freescale) or any
number of gui based (packaged) tools, you see all of the pieces, via a
gui. That's where Eclipse is heading, in my opinion. It's not that CLI
tools will disappear, but using them and accessing them, via Eclipse,
is the future, from the many vendors we speak with. (ymmv).

After all 99% of firmware is still written (and cross compiled)
on windows boxes, from what I see, at the major vendor trade shows
(Freescale, Microchip, TI, Atmel etc etc) and talking to a myriad
of folks that write firmware, for a living. Sure every body has
a thing or 2 built on embedded linux, but most products still
are built via Integrated Development Environments (IDE), because
that's what their management feels comfortable with. They want those
vendor(ish) tools, so if an employee, or consultant leaves, it's
pretty much easy to find another firmware engineer to work on the next
revision of the product, (YMMV). Following another programmer on
somebody else's *nix CLI stuffage, is most often a drag, and that's if

you are 'into' *nix type of OSes.

Eclipse can be a game changer for the entire industry, methinks, as
the management, (you know, those folks that *FUND* new products within
a company), are hoping for something like Eclipse to mature and vendors

make the commitment to move to it, as well as open source choices.
Pie-in-the-sky, maybe, but I hear it more and more. We have some very
bright folks we work with. They do not have problems using linux or
*nix, but, when it comes to firmware development, most refuse to
use linux/*nix as the windows based tools allow them to code, much
faster. Time is money, when you bill by the hour, and our clients
are stingy and expect miracles, often on PO's of less than 100 hours.

Personally, embedded linux is way excessive for most of our clients,
but, if there was unification around eclipse (as an open source
IDE), then I think many companies would venture new embedded
products, upgrading the processor to something that can handle
embedded linux and be happy with Eclipse, knowing they can work
it from a windows or linux workstation, depending on what the
firmware engineer is most comfortable with.

I also think that once Eclipse (et. al) matures, many companies
will port their BSPs over to Eclipse and be done with paying
royalties, fees and (extorted) licenses to Micro Soft.

just my 2cents.


Here's a quick and dirty:


http://openhardware.net/Embedded_ARM/OpenOCD_JTAG/#testocd



Basically, run openocd from the command line, specifying a config file.
Then telnet into it. ;-)



Someone may have glossed over this with a gui, but that's not what crops
up in google.



Maybe we can all agree on a BSP that works well with a JTAG and
Eclipse, and make it an option for Noobs wanting to get into
embedded Gentoo? I think this is an easier sell than GNAP....?
Keeping cost down is a good idea, and my early vote goes for
an Arm9 board.



I haven't needed a jtag for it, since the bootloader was sufficient, but
I like the NSLU2 as a good starter kit. I recently saw one on ebay for
~$30US. I bought mine new years ago for ~$70US.


OK, if the group decides not to want a JTAG, then that's cool with me.
Folks occasionally become interested in embedded gentoo, are open to
what processor/board to use. IMHO, it'd be very cool to have an
introduction to embedded gentoo, say like Das Blinkenlights,
or Das AD/DA, on a simple, low cost board. Ethernet is the only real
hardware requirement I'd suggest, so I'd be cool to whatever the
consensus is.




The next step after that (at least, what I did) was the Gateworks 2348-4
board. Same processor, 4 mini-pci, 2 ethernet, USB as an option. It's
less than $300US. Openocd works with it's parallel jtag programmer. I
haven't needed that yet either, since the bootloader works for me.


Um, most of our customers want an custom bootloader. It's really not
an option when you write firmware for a custom designed board that
is going to become a product. Sure vendors provide reference code, but
I've never seen that be sufficient for a product. I know lots of
companies use code from the chip vendors (cisco), but, it gets them
into trouble, more often than most realize. Besides a JTAG can be used
for debugging lots of different firmware/hardware issues, particularly
when you have limited/constrained resources and many things flying

around, asynchronously. You could not even get a firmware engineer
anywhere I've seen that would do a project, without a JTAG, BDM or
ICE. This is where embedded linux (and hopefully embedded gentoo) can
go to whole new level, when you customize device drivers for various
optimized needs, under constrained resources. Am I talking about
deviation from what the kernel gods have published? Sure, but only

in small amounts, and it is done quite often with embedded products.
Just look at the number of vendors now offering 'embedded linux'.



The ethernet support is native in the vanilla kernel since about 2.6.21
or .23. As of 2.6.27, the kernel has support for the hardware crypto
engine. IPsec VPN gateway, anyone?


I'm not trying to upset anyone, I just see things slightly different
than most, because, as the end of the battle, I do want linux as a
workstation development platform (complete with a killer IDE) and
embedded linux (customized) as a ~rtos to win, or at least be a
realistic option for many processors and new products.

Sure (linux) is gaining market share, but, I think that
is a (relatively) few products that hit very high volume. It certainly
does not dominate where most firmware engineers actual do their work,
imho.



James
 
Old 10-28-2008, 08:44 AM
Mike Frysinger
 
Default FTDI jtag

On Monday 27 October 2008, wireless wrote:
> Mike Frysinger wrote:
> > On Friday 12 September 2008, billium wrote:
> >> get openocd from respository, svn checkout
> >> svn://svn.berlios.de/openocd/trunk/openocd and extract
> >
> > why ? we have an openocd-9999.ebuild which fetches straight from the
> > upstream site ...
>
> I have to chuckle out loud......
>
>
> Some time ago, I inquired about using developing on embedded (gentoo)
> linux using Eclipse and any sort of TAG/BDM device.
>
>
> I still remember the (focused) scolding you gave me about how that
> was not the *nix way. Command line, burn and churn, etc etc....
>
> As an old (*nix) fart, I rather enjoyed (and agreed with) your prose.
> However, the planet is being overrun with young kids that like their
> gui-fied tools....
>
>
> Now you are pointing folks to openocd......?

i dont know wtf you're talking about. i didnt point anyone to openocd.
someone said they were trying to use it directly instead of an ebuild already
in the tree. ive never used openocd myself seeing as how i dont even have
any hardware that it supports, so i really have no idea how it works. try
reading the full thread next time please.
-mike
 
Old 10-28-2008, 04:42 PM
Jason
 
Default FTDI jtag

wireless wrote:
> Jason wrote:
>> wireless wrote:
>>> Mike Frysinger wrote:
>>>> On Friday 12 September 2008, billium wrote:
>>>>> get openocd from respository, svn checkout
>>>>> svn://svn.berlios.de/openocd/trunk/openocd and extract
>>>> why ? we have an openocd-9999.ebuild which fetches straight from the
>>>> upstream site ...
>>> I have to chuckle out loud......
>>>
>>>
>>> Some time ago, I inquired about using developing on embedded (gentoo)
>>> linux using Eclipse and any sort of TAG/BDM device.
>>>
>>>
>>> I still remember the (focused) scolding you gave me about how that
>>> was not the *nix way. Command line, burn and churn, etc etc....
>>>
>>> As an old (*nix) fart, I rather enjoyed (and agreed with) your prose.
>>> However, the planet is being overrun with young kids that like their
>>> gui-fied tools....
>>>
>>
>> Rhetorical Question: How many of those "young kids" are _good_? There
>> is no shortcut to deep understanding (no, I'm no where close).
>> Something a GUI obfuscates away, the cli celebrates. But then, we
>> agree... ;-)
>
> Most of what we do is old fashion roll your own state machine, async
> programming (8-32) bit processors for products. So any RTOS/executive is
> a luxury.... The designs typically used >90% of the resources.
> Tight and Spartan still rules the roost in our embedded world.
>

So, you're coming at it from the bottom up (really small -> linux)
whereas I'm approaching it from the top down (desktop linux -> embedded
linux).

[snip]
>>> Now you are pointing folks to openocd......?
>
>> Are you implying that openocd is a gui? I think you might be referring
>> to something else.
>
> Eclipse vs command line.... look at the top of this page:
>
> http://www.yagarto.de/
>
> Second bullet (*works with Elipse*). That's what I refer to a
> gui-fied.

[root@localhost] # for i in `equery files openocd`; do if [ -x ${i} -a !
-d ${i} ]; then echo "-->${i}"; ldd ${i}; echo
"############################################# "; fi; done
-->/usr/bin/openocd
linux-gate.so.1 => (0xffffe000)
libftd2xx.so.0 => /usr/lib32/libftd2xx.so.0 (0xf7f79000)
libusb-0.1.so.4 => /lib32/libusb-0.1.so.4 (0xf7f70000)
libdl.so.2 => /lib32/libdl.so.2 (0xf7f6c000)
libc.so.6 => /lib32/libc.so.6 (0xf7e3e000)
libpthread.so.0 => /lib32/libpthread.so.0 (0xf7e26000)
/lib/ld-linux.so.2 (0xf7fb7000)
#############################################

_not_ gui. Just because one project (yagarto) uses openocd and works
with eclipse, doesn't make openocd a gui. That kind of logic is just
frightening. Are you sure you aren't a politician?

[snip]
>>> Maybe we can all agree on a BSP that works well with a JTAG and
>>> Eclipse, and make it an option for Noobs wanting to get into
>>> embedded Gentoo? I think this is an easier sell than GNAP....?
>>> Keeping cost down is a good idea, and my early vote goes for
>>> an Arm9 board.
>
>> I haven't needed a jtag for it, since the bootloader was sufficient, but
>> I like the NSLU2 as a good starter kit. I recently saw one on ebay for
>> ~$30US. I bought mine new years ago for ~$70US.
>
> OK, if the group decides not to want a JTAG, then that's cool with me.
> Folks occasionally become interested in embedded gentoo, are open to
> what processor/board to use. IMHO, it'd be very cool to have an
> introduction to embedded gentoo, say like Das Blinkenlights,
> or Das AD/DA, on a simple, low cost board. Ethernet is the only real
> hardware requirement I'd suggest, so I'd be cool to whatever the
> consensus is.

I think your basic premise is off in that you're attempting to herd
cats. It's faulty to assume there needs to be a consensus in the first
place. Sounds very cathedral-ish.

fwiw, to get where you want to go, I think the only thing g-e needs is a
place for contributors to place howtos in a loosely standardized format
(wiki? no, I didn't _say_ wiki ;-) ) A new user could then hit that
site and try one that works for their end goal, eg firmware for you,
low-power servers for me.

>
>> The next step after that (at least, what I did) was the Gateworks 2348-4
>> board. Same processor, 4 mini-pci, 2 ethernet, USB as an option. It's
>> less than $300US. Openocd works with it's parallel jtag programmer. I
>> haven't needed that yet either, since the bootloader works for me.
>
> Um, most of our customers want an custom bootloader. It's really not
> an option when you write firmware for a custom designed board that
> is going to become a product. Sure vendors provide reference code, but
> I've never seen that be sufficient for a product. I know lots of
> companies use code from the chip vendors (cisco), but, it gets them
> into trouble, more often than most realize. Besides a JTAG can be used
> for debugging lots of different firmware/hardware issues, particularly
> when you have limited/constrained resources and many things flying
> around, asynchronously. You could not even get a firmware engineer
> anywhere I've seen that would do a project, without a JTAG, BDM or
> ICE. This is where embedded linux (and hopefully embedded gentoo) can go
> to whole new level, when you customize device drivers for various
> optimized needs, under constrained resources. Am I talking about
> deviation from what the kernel gods have published? Sure, but only
> in small amounts, and it is done quite often with embedded products.
> Just look at the number of vendors now offering 'embedded linux'.
>

This is a different flavor of the top-down/bottom-up discussion. We
have different needs. As long as the bootloader launches the linux
kernel with the correct board id and command line arguments, I'm happy.
Caveat that with no crypto/signature/lockdown crap...

>
>> The ethernet support is native in the vanilla kernel since about 2.6.21
>> or .23. As of 2.6.27, the kernel has support for the hardware crypto
>> engine. IPsec VPN gateway, anyone?
>
> I'm not trying to upset anyone, I just see things slightly different
> than most, because, as the end of the battle, I do want linux as a
> workstation development platform (complete with a killer IDE) and
> embedded linux (customized) as a ~rtos to win, or at least be a
> realistic option for many processors and new products.
> Sure (linux) is gaining market share, but, I think that
> is a (relatively) few products that hit very high volume. It certainly
> does not dominate where most firmware engineers actual do their work,
> imho.

I'm confused. Are you looking to use linux (g-e) to develop bare metal
firmware, or to develop embedded linux firmware?

Jason.
 
Old 10-28-2008, 06:08 PM
wireless
 
Default FTDI jtag

Jason wrote:


I'm confused. Are you looking to use linux (g-e) to develop bare metal
firmware, or to develop embedded linux firmware?



Both, but, why would it matter? Using and IDE from TI, like Code
Composer, you can do both. Why would using a linux workstation for

either type of firmware, be any different?


Actually most firmware engineers still use IDE's on windows, even for
embedded linux development. That's why something like Eclipse

for embedded development is so promising, imho.


Anyway, I done with this thread.


James
 

Thread Tools




All times are GMT. The time now is 08:21 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org