Re: [gentoo-embedded] FTDI jtag

[Jason]

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.