Here's a quick introduction to using a cheap FTDI FT2232H based module (left-hand side on the photo) as a JTAG programmer together with the OpenOCD JTAG software for ARM and MIPS devices. The module I am using for thіs purpose is a DLP Design DLP-USB1232H, which is available from various sources (Digikey, Mouser, Saelig, and probably others) for 20-30 bucks plus shipping, depending on where you live.
By properly connecting the correct pins of the DLP-USB1232H to the target JTAG
device (I used an Olimex STM32-H103 eval board for testing) you can easily abuse the DLP-USB1232H as JTAG programmer. As I chose the proper DLP-USB1232H GPIOs for the TRST and (S)RST pins, OpenOCD even worked out of the box, without having to change a single line of code.
The only thing that's required is to provide OpenOCD with an interface config file that uses the usbjtag "layout". I have already submitted that config file upstream, I guess it should be merged soonish.
The usage is then pretty simple:
$ openocd -f interface/dlp-usb1232h.cfg -f board/olimex_stm32_h103.cfg
And in another xterm:
$ telnet localhost 4444 > init > reset halt > flash write_image erase fancyblink.bin 0x08000000 > reset
This flashes the given fancyblink.bin image onto the STM32-H103 eval board via the DLP-USB1232H JTAG programmer, where fancyblink.bin is an example program from my libopenstm32 project (that aims to create a full-blown firmware library for ST STM32 microcontrollers, similar to what avr-libc does for AVRs). Contributions for libopenstm32 (license is GPLv3 or later) are highly welcome btw., hint hint...
$ git clone git://libopenstm32.git.sourceforge.net/gitroot/libopenstm32/libopenstm32
Full schematics, datasheets, and detailed instructions for the JTAG programmer are available from a small page I created in my Random Projects wiki, which is intended for the various smaller projects I'm working on that don't warrant getting their own domain, wiki, etc:
The Random Projects wiki is open-for-all btw, feel free to use it for any freeish, software or hardware projects of your own if you want.
Anyway, the DLP-USB1232H is a really nice device as it can also be used for many other purposes, such as USB-to-Serial or SPI BIOS chip programming, but more on that in another blog post...
I have upgraded my kernel to Linux 2.6.16 today with some consequences:
SysKonnect Yukon2 support (EXPERIMENTAL)" option supports my network card just fine now, no need for external sk98lin drivers anymore (gah, I bet this URL will break in a few hours). For googling purposes: I have the following card:
Ethernet controller: Marvell Technology Group Ltd. 88E8036 Fast Ethernet Controller (rev 10).
Intel PRO/Wireless 2200BGwireless network card without having to use external drivers. However, the driver does not allow you to put the card into monitor mode. The code is there, it just isn't enabled, for whatever reason. I have created a trivial patch, but it seems that someone else has already fixed this issue. Just in case anyone cares, here's my patch:
diff -Naur linux-2.6.16.orig/drivers/net/wireless/ipw2200.c linux-2.6.16/drivers/net/wireless/ipw2200.c --- linux-2.6.16.orig/drivers/net/wireless/ipw2200.c 2006-03-20 06:53:29.000000000 +0100 +++ linux-2.6.16/drivers/net/wireless/ipw2200.c 2006-03-24 01:27:15.000000000 +0100 @@ -38,6 +38,9 @@ #define DRV_COPYRIGHT "Copyright(c) 2003-2005 Intel Corporation" #define DRV_VERSION IPW2200_VERSION +#define CONFIG_IPW2200_MONITOR "y" + + #define ETH_P_80211_STATS (ETH_P_80211_RAW + 1) MODULE_DESCRIPTION(DRV_DESCRIPTION);
You should better copy+paste the patch from the HTML source or it might break...
Update 2006-03-24: The loop-aes v3.1c patches apply just fine. I almost forgot to mention the NVIDIA changes...
High (arbitrary remote code execution under the user ID running the player) when streaming an ASF file from a malicious server, medium (local code execution under the user ID running the player) if you play a malicious ASF file locally. At the time the buffer overflow was fixed there was no known exploit.
Users of the older MPlayer 1.0pre7try2 should apply this patch in order to fix the security issue. CVS users should update to the most recent revision.
I tried to do the latter, but I stumbled over several problems. First, I noticed and filed a bug (I think) in Debian's libavcodec-dev package which prevented a successful compile. After a few more problems I gave up and stayed with 1.0pre7try2 by applying the above-mentioned patch. I'll wait a few more days until the MPlayer developers fix the build issues in CVS...
There's no known exploit in the wild yet, but I bet it won't take too long until one appears. So better fix your Mplayer!
Just a quick update on Amaya Rodrigo's recent post on Planet Debian about xbubble's upstream author sending a patch for the Debian xlibs-dev transition: I have uploaded a (hopefully) fixed version of the package yesterday => one step closer to the end of the transition.
Addicting game, btw., give it a try!