kmod-jtag-gpio?

[Nathan]

I was looking into the JTAG protocol. And I understand that the Biffer
has a JTAG reception port. But is there a way to make a Bifferboard
into a JTAG reader/writer for other devices that use JTAG using its
GPIOs? I sounds like there are a lot of small USB boards that
basically do different types of JTAG, but why not from a embedded
linux board.

[Andrew Scheller]

> has a JTAG reception port. But is there a way to make a Bifferboard
> into a JTAG reader/writer for other devices that use JTAG using its
> GPIOs? I sounds like there are a lot of small USB boards that
> basically do different types of JTAG, but why not from a embedded
> linux board.

A quick google for "openocd gpio" finds
http://comments.gmane.org/gmane.comp.debugging.openocd.devel/13728 and
http://www.omnima.co.uk/forums/index.php?showtopic=96

And I guess you may find
http://groups.google.com/group/bifferboard/browse_thread/thread/7c4835cb1773b5d4
useful too :)

Lurch

[biff...@yahoo.co.uk]

Ha, Lurch beat me to it, but I'll send this anyhow.

These links will probably be of interest:
http://groups.google.com/group/bifferboard/browse_thread/thread/7c4835cb1773b5d4
http://blog.famzah.net/tag/avrdude/
https://sites.google.com/site/bifferboard/Home/howto/serial-terminal-project/parallax-propeller-investigation
https://sites.google.com/site/bifferboard/Home/digital-photo-frames/parrot_df3120/debricking-using-the-bifferboard
https://sites.google.com/site/bifferboard/Home/pov-persistence-of-vision-project

Yes, you can program anything that needs bits wiggling at 3.3v, and if
you bypass the Linux GPIO interface you can do it pretty fast (see the
last link in particular for that). Most JTAG cables have >4 lines
though, so to use the Bifferboard requires you to use the serial port
as a couple of extra GPIO lines. The best approach is to have a basic
linux initrd system with ftpd and telnetd (which is easy to configure
using busybox), and then you use pexpect (or expect) to automate a
telnet session with the target machine:

1) Connect
2) ftp your GPIO-controlling binary to the bifferboard
3) ftp your data that you want to program
4) execute your binary on the bifferboard and parse the responses to
see what the result was

Python also has an ftp module that makes the ftp client automation bit
trivial as well, to do the upload (or the download if you're reading
data). This is way better than trying to write some custom protocol
to control your Bifferboard remotely, (assuming security isn't a
concern), and will take you 1/10th the time.

regards,
Biff.

[Nathan]

Okay,

I can see that there is OpenOCD and URJtag. Neither seems to be
available for OpenWRT or other embedded OSes. Also I can see that some
are more enabled for dongles etc. In general the GPIOs of embedded
devices should already be 3.3v and don't need buffering or wiggling. I
could be wrong though, people mention 1.8v too. So maybe it depends on
the device.

I am getting deeper into embedded, so I wonder how interesting JTAG-
everything project will be. I can possibly get a device that has 7
GPIOs which would be enough for at least most JTAG protocols...

How do you mean by bypass. I will check out your links.

[biff...@yahoo.co.uk]

On Mar 22, 12:59 am, Nathan <nathan.vanfl...@gmail.com> wrote:
> How do you mean by bypass.

I gave you the links in the hopes that I wouldn't have to explain :).

Maybe you should just forget about that for your initial version, and
get something working using the GPIO sysfs interface instead.

regards,
Biff.

[Nathan]

Hmm, I am looking into getting openocd into a OpenWRT package. Though
I have experience writing a package, I don't know exactly how to
integrate one (especially one that uses sourceforge git).

From there I will hopefully have something that I can add to.

On Mar 22, 6:11 am, "biffe...@yahoo.co.uk" <biffe...@yahoo.co.uk>
wrote:

[biff...@yahoo.co.uk]

On Mar 22, 1:18 pm, Nathan <nathan.vanfl...@gmail.com> wrote:
> Hmm, I am looking into getting openocd into a OpenWRT package. Though

Cool.

> I have experience writing a package, I don't know exactly how to
> integrate one (especially one that uses sourceforge git).

Don't base it on sourceforget git, use the github version instead:
https://github.com/bifferos/bb, as it's much more up to date.

But if you prefer to base your work directly on the OpenWrt project,
then you can do that and I'll adapt it for our fork. If you use GPIO
sysfs interface there's no reason for it to be Bifferboard-specific,
and you can submit the whole thing directly to the OpenWrt project.

regards,
Biff.

[biff...@yahoo.co.uk]

On Mar 22, 1:18 pm, Nathan <nathan.vanfl...@gmail.com> wrote:

> I have experience writing a package, I don't know exactly how to
> integrate one (especially one that uses sourceforge git).

Oh, I see what you're saying now. What you mean is you don't know
what OpenWrt makefile command to use to pull a SF git revision
number. The normal way is to download a release tarball and them
apply your own patches. Or is there some reason why you can't do
that? Surely there's an example package makefile that uses git
sources? Perhaps you can ask on the OpenWrt developers list.

cheers,
Biff.

[nicolas le falher]

Hi,

 

>especially one that uses sourceforge git

https://dev.openwrt.org/browser/trunk/package/hostapd/Makefile

This configuration seems download git repo and create archive PKG_SOURCE in dl/

 

How do you plan creating an interface with gpio for use with Openocd ?

Nicolas

[Nathan]

I think the idea is to do this:

http://www.omnima.co.uk/forums/index.php?showtopic=96
http://www.omnima.co.uk/forums/index.php?showtopic=50

So essentially make a package for openOCD that uses the "parport"
feature which is for "wiggler" still usage which means a bare (not
through a USB/serial dongle for example) for JTAG.

So a basic package with the configuration of "--enable-parport --
enable-parport_ppdev"

For using GPIOs you need to compile the kernel with a gpio-proxy. I
have no idea how to get this into openwrt mind you.

I've tried to just dump the entire src package into a openwrt package
with particular configs and install parts, but I get errors about
being in c99 mode and some other stuff. I'm not sure if I should just
put all of the package code in src or how to patch it.

[Nathan]

I should also say that I find the OpenWRT is not very responsive, at
least in the developer forums.

I've submitted a ticket to them to actually have the kernel option to
enable the pwm-gpio feature (from Biffer). I had a lot of trouble
before because I included the kmod but the sysfs never showed up. Well
essentially they never included the patch for the kernel_menuconfig to
enable pwm, so the kmod package did nothing at all. I submitted the
patch and they never did anything about it. I think they should have
both the kernel option and the module or neither, since the module
depends on the config. But whatever.

[biff...@yahoo.co.uk]

On Mar 22, 3:54 pm, Nathan <nathan.vanfl...@gmail.com> wrote:
> For using GPIOs you need to compile the kernel with a gpio-proxy. I
> have no idea how to get this into openwrt mind you.

You do not need gpio-proxy to do this! Instead of using gpio-proxy
client you need to copy the code used in
the avrdude patch by Radoslav Kolev (see link above). By adding the
gpio-proxy kernel module you are needlessly complicating the whole
thing.

> I've tried to just dump the entire src package into a openwrt package
> with particular configs and install parts, but I get errors about
> being in c99 mode and some other stuff. I'm not sure if I should just
> put all of the package code in src or how to patch it.

The hardest part is configuring it for cross-compilation. You'll have
to supply various options at the configure stage to do this. Again,
you can only look at other package Makefiles to see how this is done,
unless the OpenWrt devs are feeling in particularly charitable mood
when you ask! The OpenWrt forum is another place to ask.

regards,
Biff.

[Nathan]

Okay I will take a look into this.

I am still trying to deal with different levels of MakeFiles. Like how
there is one for the package itself, and then one in the src directory
that pulls all of that together.

If I can get a precise question or request together I might ask the
Openwrt guys. But they don't seem much into projects that are somehow
outside of their mission.

Thanks very much.


On Mar 22, 12:38 pm, "biffe...@yahoo.co.uk" <biffe...@yahoo.co.uk>
wrote:

[biff...@yahoo.co.uk]

On Mar 22, 6:46 pm, Nathan <nathan.vanfl...@gmail.com> wrote:
> Okay I will take a look into this.
>
> I am still trying to deal with different levels of MakeFiles. Like how
> there is one for the package itself, and then one in the src directory
> that pulls all of that together.

If you didn't write the software yourself, there should be no src
directory.

> If I can get a precise question or request together I might ask the
> Openwrt guys. But they don't seem much into projects that are somehow
> outside of their mission.

They'll have little patience with you if you haven't read and
understood this:
http://wiki.openwrt.org/doc/devel/packages

But questions that aren't covered there should be answered, I would
have thought.

Biff.

[nicolas le falher]

Makefile for openocd 0.5.0 from SF.
Compile works, just include binary "openocd".

Not tested on Openwrt/Bifferboard.

Nicolas

[biff...@yahoo.co.uk]

Cool. That was nice and easy :-). If it compiled it probably runs
fine. I wonder how receptive the devs are to a patch, and whether
Nathan would fare better than Radoslav:
http://lists.gnu.org/archive/html/avrdude-dev/2010-04/msg00014.html

Nahh... on second thoughts let's just make a patch :).

Biff.

PS: I just realised there is a voting button for Radoslav's patch, so
I'm going to add a vote there. Maybe everyone else on the list can do
the same, perhaps it'll work :)))).
https://savannah.nongnu.org/patch/?7165#votes

>  Makefile
> 1KViewDownload

[nicolas le falher]

>Nahh... on second thoughts let's just make a patch :).

Yea, let's make a tool for Biff :).
Nathan, you want make gpio port to avrdude for Openwrt ? (or I make that)

Nicolas

[Nathan]

Whoa, this is moving fast for me.

Well the build of openOCD won't work on every platform right? That's
why a binary blob doesn't work for everyone.

If you know more about it I would have to vote for you to do it. It
seems as if there are too many people interested for them to wait for
me to do it.

[Nathan]

Holy crap it's compiling.

It took me maybe 30 seconds to even get how you referred to
sourceforge since it's a variable @SF. I had quite a bit of problems
grepping the other packages for hints about external sites. Probably
because it is all so convenient. ;-)

-Nathan

>  Makefile
> 1KViewDownload

[nicolas le falher]

>Holy crap it's compiling.

I always post a Makefile that compiles ! :)

>It took me maybe 30 seconds to even get how you referred to sourceforge since it's a variable @SF

I got two failings on download, it's not your problem, don't worry about that

What do you need for next step, gpio support for avrdude from Radoslav ?

Nicolas

[Nathan]

Will avrdude only enable programming for avr or any generic JTAG that
openocd is compatible with?

At this point the install script took a really long time, maybe a
minute. Seems to crash on running.

root@OpenWrt:/tmp# opkg install openocd_0.5.0-1_atheros.ipk
Installing openocd (0.5.0-1) to root...
Configuring openocd.
root@OpenWrt:/tmp# openocd
/usr/bin/openocd: line 1: syntax error: unexpected "("
root@OpenWrt:/tmp# openocd --help
/usr/bin/openocd: line 1: syntax error: unexpected "("
root@OpenWrt:/tmp#

-Nathan

[Nathan]

It looks as if you need to install the config files

If you look at these directions it says you need the config files.
http://www.omnima.co.uk/forums/index.php?showtopic=96

Which are in source directory. So I think this needs to be put into
the install dir.

mkdir /etc/openocd
cp -r $(PKG_BUILD_DIR)/src/tcl /etc/openocd

[nicolas le falher]

>/usr/bin/openocd: line 1: syntax error: unexpected "("

It's time to unpack my Biff :)

Nicolas

[Nathan]

This might make more sense.

$(INSTALL_DIR) $(1)/etc/openocd
$(INSTALL_BIN) $(PKG_BUILD_DIR)/src/tcl $(1)/etc/openocd/tcl

[Nathan]

Here is the corrected Makefile portion

define Package/openocd/install
$(INSTALL_DIR) $(1)/usr/bin
$(INSTALL_BIN) $(PKG_BUILD_DIR)/src/openocd $(1)/usr/bin/
$(INSTALL_DIR) $(1)/etc/openocd
$(CP) -r $(PKG_BUILD_DIR)/tcl $(1)/etc/openocd
endef

[nicolas le falher]

Not working for me :/

root@OpenWrt:/# openocd -v
/bin/ash: openocd: not found
root@OpenWrt:/# /bin/ash /usr/bin/openocd

/usr/bin/openocd: line 1: syntax error: unexpected "("

root@OpenWrt:/# ls /etc/openocd/
tcl
root@OpenWrt:/# ls /etc/openocd/tcl/
bitsbytes.tcl    cpld             mem_helper.tcl   target
board            cpu              memory.tcl       test
chip             interface        mmr_helpers.tcl
root@OpenWrt:/#

Nicolas

[biff...@yahoo.co.uk]

Added to git:
https://github.com/bifferos/bb/blob/master/openwrt/package/feeds/bifferos/openocd/Makefile

Let me know if you want any further changes.

thanks,
Biff.

[nicolas le falher]

Erm, maybe is not a good choice to add on git a Makefile who is not validated.
Nathan, can you confirm you successfully run openocd on Bifferboard ?

Nicolas

[biff...@yahoo.co.uk]

It doesn't matter, we can call it work in progress, and can easily
update it in the future It's just a place-holder, and it does compile
which is something (at least it compiles for me....)

[Andrew Scheller]

> It doesn't matter, we can call it work in progress, and can easily
> update it in the future It's just a place-holder, and it does compile
> which is something (at least it compiles for me....)

Done a bit of investigation in Qemu, and it looks like the reason it
compiles but doesn't run on the bifferboard, is that it gets compiled
as:
/usr/bin/openocd: ELF 64-bit LSB executable, x86-64, version 1 (SYSV),
for GNU/Linux 2.6.15, dynamically linked (uses shared libs), corrupted
section header size

i.e. it's being compiled using the native-toolchain rather than the
32-bit cross-toolchain.
I dunno OpenWRT well enough to suggest a fix...

Lurch

[nicolas le falher]

Is that, I work on.
But got some compilation problem again (like siglist with uclibc).

define Build/Compile
    $(MAKE) -C $(PKG_BUILD_DIR) CC="$(TARGET_CC)" CFLAGS="$(TARGET_CFLAGS) -I. -I$(BUILD_DIR_TOOLCHAIN)/$(LIBC)-$(LIBCV)/include" LDFLAGS="$(TARGET_LDFLAGS)" CPPFLAGS="$(TARGET_CPPFLAGS)"
endef

Nicolas

[Andrew Scheller]

I managed to get a bit further... (maybe you've already done the same)

I updated openocd/Makefile with that, and got a bash error about
\302\240 - a google search turns up that this is a non-breaking space,
which my browser must have helpfully inserted when I cut'n'pasted. So
I manully deleted and re-inserted all the spaces in that line which
fixed it.

And then I got the same siglist error as you and was able to fix it by
editing jimtcl/jimautoconf.h and changing
#define HAVE_SYS_SIGLIST 1
to
#undef HAVE_SYS_SIGLIST
(however this file is autogenerated, so I think to fix it properly
you'd need to get jimctl/autosetup run using the cross-toolchain. For
now you can just edit sys_siglist out of jimtcl/auto.def )

So the compilation got a bit further and it gave errors about
variables declared inside for-loop initialisers, so I added -std=c99
to the CFLAGS in your Build/Compile line above.

So the compilation got a bit further and it gave errors about
isascii() - I found this in uClibc's ctype.h and it's declared as:
#if (defined __USE_SVID || defined __USE_MISC || defined __USE_XOPEN) && \
defined __UCLIBC_SUSV4_LEGACY__
/* Return nonzero iff C is in the ASCII set
(i.e., is no more than 7 bits wide). */
extern int isascii(int __c) __THROW;
libc_hidden_proto(isascii)
/* Return the part of C that is in the ASCII set
(i.e., the low-order 7 bits of C). */
extern int toascii(int __c) __THROW;
#endif

So I added "-D__USE_MISC -D__UCLIBC_SUSV4_LEGACY__" to the CFLAGS but
that didn't fix it, I still get the same error.

And that'll do me for today I think ;)

Lurch

[Nathan]

It compiles but fails in the same way for me.

You have to use configure options to make it cross compile, and I
spent a significant time last night trying to figure out what to tell
it to do. It appears as if it might only compile to arm, i686 or
windows.

Here is the windows configure flags, you have to say where it's
compiling, and then the host platform

./configure --build=i686-pc-linux-gnu --host=i586-mingw32msvc

-Nathan

[Nathan]

It is

--build=i686-pc-linux-gnu --host=mipsel-openwrt-linux-uclibc

http://www.omnima.co.uk/forums/index.php?showtopic=50

-Nathan

[nicolas le falher]

>So the compilation got a bit further and it gave errors about isascii()

True, same problem.
I take a look to add SUSV4 support to uclibc

Nicolas

[nicolas le falher]

Already enabled,
#cat build_dir/toolchain-i386_gcc-4.5-linaro_uClibc-0.9.32/uClibc/.config | grep SUS
UCLIBC_SUSV3_LEGACY=y
UCLIBC_SUSV3_LEGACY_MACROS=y
UCLIBC_SUSV4_LEGACY=y

So, it's just above

Nicolas

[Nathan]

Okay,

You firstly have to modify your path variable that is specific to
trunk openwrt.

PATH = $PATH:whatever/staging_dir/toolchain-mips_gcc-4.6-
linaro_uClibc-0.9.33/bin

I don't know if there is anyway to make this more dynamic?

Here is the new config, which also removes the doxygen manual build.
It is also not too dynamic, in the sense that you will have to change
the --host=X depending on the platform that you are building

define Build/Configure
(cd $(PKG_BUILD_DIR); \
./configure --build=i686-pc-linux-gnu --host=mips-openwrt-linux-
uclibc --enable-parport --enable-parport_ppdev --disable-doxygen-html\
);
endef

[nicolas le falher]

But, your openocd binary run fine on Bifferboard/Openwrt ?

Nicolas

[Nathan]

It works!

root@OpenWrt:/etc/openocd/tcl/interface# openocd
Open On-Chip Debugger 0.5.0 (2012-03-24-10:36)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.berlios.de/doc/doxygen/bugs.html
Can't find openocd.cfg
in procedure 'script'
Error: Debug Adapter has to be specified, see "interface" command
in procedure 'init'

[nicolas le falher]

Nice :) !
Can you join your entire Makefile in attachment ?

Nicolas

[Nathan]

I would have been doing that but I have no idea how you attach a file.

Here is a pastebin

http://pastebin.com/9dHLnEv9

But you have to modify your path

I will also try and slim dow the included .cfg files since we don't
need all the interfaces.

[nicolas le falher]

>I would have been doing that but I have no idea how you attach a file.

Like an mail attachment to the list.

>But you have to modify your path

I've change --host with openwrt variable, and delete --build (auto-detect).
But I'm not sure if we really using openwrt toolchain or if we using just gcc from openwrt toolchain.
Anyway it works for your test.

Can you make a test on your environment ?

Nicolas

[Nathan]

It said on a page that you need to include build because otherwise
there will be errors. This may or may not still be an issue I guess.
Not sure which page sorry.

It mentions on this page that we need to create a config file too,
which I guess we can supply in the package as well. But I guess we'll
have to figure out the gpio->par port thingy

http://www.omnima.co.uk/forums/index.php?showtopic=50

-Nathan

>  Makefile
> 1KViewDownload

[nicolas le falher]

>But I guess we'll have to figure out the gpio->par port thingy

I let you see it :)

Nicolas

[Nathan]

Not sure what happened to my post yesterday.

Here is a Makefile that incorporates some changes. Including a patch to the parport.c file. The user will have to change this to the GPIOs they want to use for their device too. They will need to include the config and the parport.c file in the main package directory.

I have tested that it builds, but not that it works. I will have to find something to JTAG.

https://sites.google.com/site/bifferboard/Home/digital-photo-frames/parrot_df3120/debricking-using-the-bifferboard

Does this seem to make sense?

Edit: I see, it seems that the Makefile was not allowed to be uploaded. Here is the pastebin again.

http://pastebin.com/DGpgsVj1

-Nathan

[Andrew Scheller]

> use for their device too. They will need to include the config and the
> parport.c file in the main package directory.
>

> Edit: I see, it seems that the Makefile was not allowed to be uploaded. Here
> is the pastebin again.
>
> http://pastebin.com/DGpgsVj1

There's references in the Makefile to ./parport.c and ./openocd.cfg
which I'm guessing only exist on your PC? ;)
And general practice seems to be to always use absolute paths (i.e.
avoid ./filename ) in Makefiles (that's what all the $DIR variables
are for) so that the Makefile works regardless of which directory you
call it from.

Lurch

[biff...@yahoo.co.uk]

On Mar 27, 9:32 pm, Nathan <nathan.vanfl...@gmail.com> wrote:
> https://sites.google.com/site/bifferboard/Home/digital-photo-frames/p...

>
> Does this seem to make sense?

Just a warning about the link - It was a while back but I think I only
partially got that working. In the end I flashed linux onto the frame
using the firmware upgrade method.

cheers,
Biff.

[Nathan]

Check the first link. The one with the webpage that has two files to download that I referenced.

Absolute paths require absolute certainty where the files are on the system, but if you have a new version of the Makefile I will try it.

-Nathan

[Nathan]

Okay,

I will do some testing, but it looks to be the best bet. I'm not sure about the patch by the other guy, but seems AVRDude specific?

[biff...@yahoo.co.uk]

On Mar 28, 12:52 am, Nathan <nathan.vanfl...@gmail.com> wrote:
> Okay,
>
> I will do some testing, but it looks to be the best bet. I'm not sure about
> the patch by the other guy, but seems AVRDude specific?

I think the idea was you adapt that AVRDude mechanism to OpenOCD,
instead of using io port access directly. This would have the
advantage that:

1) It works on any OpenWrt device (with support for GPIO)
2) It doesn't require you to remember to disable other stuff that
accesses the RDC southbridge, (e.g. the watchdog driver) first.

But you can also hack parport.c.

cheers,
Biff.