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. [EMAIL PROTECTED] # 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.
