[beagleboard] PinMux for Tin Can Tools Trainer board

Hi Folks,

I am currently playing with Trainer board from Tin Can Tols and got a
question regarding pin muxes. With test image offered at [1] there are
GPIO pins made available for example to control power for built-in AVR
(pin 162). However, I can not find the corresponding sources (mux.c?)
which I can use to build the kernel myself with the same pin mux
settings. So can someone please point me to the place where this
information is available? I know that it would probably be unavoidable
to understand how to configure it myself :slight_smile: but I just want to
jump-start by repeating at least what was already done and I know
(tested) that it works.

Thank you,
Andrey.

[1] http://elinux.org/BeagleBoard_Trainer#Copy_files_onto_the_BOOT_partition

Hi Folks,

I am currently playing with Trainer board from Tin Can Tols and got a
question regarding pin muxes. With test image offered at [1] there are
GPIO pins made available for example to control power for built-in AVR
(pin 162). However, I can not find the corresponding sources (mux.c?)
which I can use to build the kernel myself with the same pin mux
settings. So can someone please point me to the place where this
information is available? I know that it would probably be unavoidable
to understand how to configure it myself :slight_smile: but I just want to
jump-start by repeating at least what was already done and I know
(tested) that it works.

I'm working with the great people from Tincantools to get the trainerboard supported in stock angstrom builds, so the modification should be public soon.

regards,

Koen

Hi Folks,

I am currently playing with Trainer board from Tin Can Tols and got a
question regarding pin muxes. With test image offered at [1] there are
GPIO pins made available for example to control power for built-in AVR
(pin 162). However, I can not find the corresponding sources (mux.c?)
which I can use to build the kernel myself with the same pin mux
settings. So can someone please point me to the place where this
information is available? I know that it would probably be unavoidable
to understand how to configure it myself :slight_smile: but I just want to
jump-start by repeating at least what was already done and I know
(tested) that it works.

I'm working with the great people from Tincantools to get the trainerboard
supported in stock angstrom builds, so the modification should be public
soon.

Great! I hope you will announce it also on this list as soon as it is available.
Do you have a rough estimation when it might happen?

Thanks,
Andrey.

I'm aiming for "next week", but it's a spare time project for me, so I can't make hard guarantees.

regards,

Koen

Hi Folks,

I am currently playing with Trainer board from Tin Can Tols and got a
question regarding pin muxes. With test image offered at [1] there are
GPIO pins made available for example to control power for built-in AVR
(pin 162). However, I can not find the corresponding sources (mux.c?)
which I can use to build the kernel myself with the same pin mux
settings. So can someone please point me to the place where this
information is available? I know that it would probably be unavoidable
to understand how to configure it myself :slight_smile: but I just want to
jump-start by repeating at least what was already done and I know
(tested) that it works.

I'm working with the great people from Tincantools to get the trainerboard
supported in stock angstrom builds, so the modification should be public
soon.

Great! I hope you will announce it also on this list as soon as it is available.
Do you have a rough estimation when it might happen?

I'm aiming for "next week", but it's a spare time project for me, so I can't make hard guarantees.

Sure. I understand. Thank you very much for the information!

Regards,
Andrey.

According to Dave the only difference between zippy and trainer is that the mmc pins are GPIOs, so this should work:

http://gitorious.org/beagleboard-validation/u-boot/commit/f5796d9de9622ef47fff175613f1baf1d372b5ff

I should have access to a trainer board soon, so any testing before that is greatly appreciated.

regards,

Koen

Hi Folks,

I am currently playing with Trainer board from Tin Can Tols and got a
question regarding pin muxes. With test image offered at [1] there are
GPIO pins made available for example to control power for built-in AVR
(pin 162). However, I can not find the corresponding sources (mux.c?)
which I can use to build the kernel myself with the same pin mux
settings. So can someone please point me to the place where this
information is available? I know that it would probably be unavoidable
to understand how to configure it myself :slight_smile: but I just want to
jump-start by repeating at least what was already done and I know
(tested) that it works.

I'm working with the great people from Tincantools to get the trainerboard
supported in stock angstrom builds, so the modification should be public
soon.

Great! I hope you will announce it also on this list as soon as it is available.
Do you have a rough estimation when it might happen?

I'm aiming for "next week", but it's a spare time project for me, so I can't make hard guarantees.

Sure. I understand. Thank you very much for the information!

According to Dave the only difference between zippy and trainer is that the mmc pins are GPIOs, so this should work:

http://gitorious.org/beagleboard-validation/u-boot/commit/f5796d9de9622ef47fff175613f1baf1d372b5ff

I should have access to a trainer board soon, so any testing before that is greatly appreciated.

Great! I'll try it today or tomorrow and post the results here.

Thanks,
Andrey.

Hi Folks,

I am currently playing with Trainer board from Tin Can Tols and got a
question regarding pin muxes. With test image offered at [1] there are
GPIO pins made available for example to control power for built-in AVR
(pin 162). However, I can not find the corresponding sources (mux.c?)
which I can use to build the kernel myself with the same pin mux
settings. So can someone please point me to the place where this
information is available? I know that it would probably be unavoidable
to understand how to configure it myself :slight_smile: but I just want to
jump-start by repeating at least what was already done and I know
(tested) that it works.

I'm working with the great people from Tincantools to get the trainerboard
supported in stock angstrom builds, so the modification should be public
soon.

Great! I hope you will announce it also on this list as soon as it is available.
Do you have a rough estimation when it might happen?

I'm aiming for "next week", but it's a spare time project for me, so I can't make hard guarantees.

Sure. I understand. Thank you very much for the information!

According to Dave the only difference between zippy and trainer is that the mmc pins are GPIOs, so this should work:

http://gitorious.org/beagleboard-validation/u-boot/commit/f5796d9de9622ef47fff175613f1baf1d372b5ff

I should have access to a trainer board soon, so any testing before that is greatly appreciated.

Since I did it first time, here are the steps I did to compile u-boot
(just to make sure that I did not make a mistake).

1. git clone git://gitorious.org/beagleboard-validation/u-boot.git
2. export CROSS_COMPILE=arm-angstrom-linux-gnueabi-
3. add angstrom-dev/cross/armv7a/bin/ to the PATH
4. make omap3_beagle_config
5. make
6. copy MLO, newly created u-boot.bin and my uImage to mmc

Here is the output from beagleboard:

Texas Instruments X-Loader 1.4.4ss (Apr 13 2010 - 22:36:28)
Beagle Rev C1/C2/C3
Reading boot sector
Loading u-boot.bin from mmc

U-Boot 2010.03-rc1 (Apr 27 2010 - 22:58:28)

OMAP3530-GP ES3.0, CPU-OPP2, L3-165MHz, Max clock-600Mhz
OMAP3 Beagle board + LPDDR/NAND
I2C: ready
DRAM: 256 MB
NAND: 256 MiB
In: serial
Out: serial
Err: serial

Probing for expansion boards, if none are connected you'll see a
harmless I2C error.

Recognized Tincantools Zippy2 expansion board (rev 1 )
Beagle Rev C1/C2/C3
Die ID #5ac400030000000004013f8901001001
Hit any key to stop autoboot: 0
OMAP3 beagleboard.org #

After booting (kernel 2.6.29-omap1 #1 PREEMPT) I can not see any new
entries in /sys/class/gpio comparing to the previous u-boot:

root@beagleboard:~# ls /sys/class/gpio/

export gpiochip0 gpiochip160 gpiochip32 gpiochip96
gpio157 gpiochip128 gpiochip192 gpiochip64 unexport

Based on the following piece of code from u-boot/board/ti/beagle/beagle.c

                case TINCANTOOLS_ZIPPY2:
                        printf("Recognized Tincantools Zippy2
expansion board (rev %d %s)\n",
                                expansion_config.revision,
expansion_config.fab_revision);
                        MUX_TINCANTOOLS_ZIPPY();
                        break;
                case TINCANTOOLS_TRAINER:
                        printf("Recognized Tincantools Trainer
expansion board (rev %d %s)\n",
                                expansion_config.revision,
expansion_config.fab_revision);
                        MUX_TINCANTOOLS_ZIPPY();
                        MUX_TINCANTOOLS_TRAINER();
                        break;

I would expect to see the "Recognized Tincantools Trainer ... "
message. However, as mentioned above, I've got "Recognized Tincantools
Zippy2 expansion board (rev 1 )" from u-boot. So either I was doing
something wrong or get_expansion_id() function does not detect Trainer
board.

I add a couple of printf's to dump the expansion_config structure and
here is the output:

Device vendor: 0x2000100
Revision: 0x1
Content: 0x0
Fab revision: 0x00FFFFFFFFFFFF
Env var: 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
Env setting: 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF

So it match the TINCANTOOLS_ZIPPY2 define but I am pretty sure that I
have a Trainer board and not Zippy :slight_smile: . So at this point I am somehow
start to think that the board reports wrong ID.

Thanks,
Andrey.

looks like the eeprom got incorrectly programmed. i'll write up some notes on reprogramming the eeprom from userspace.

dave

looks like the eeprom got incorrectly programmed. i'll write up some notes on reprogramming the eeprom from userspace.

You should be able to use the gumstix tools: http://www.sakoman.net/cgi-bin/gitweb.cgi?p=openembedded.git;a=commitdiff;h=73f8e5656e061e480dbf8cc3bb3c25030c380538

The only difference is that the gumstix eeprom is on bus 3 and the beagle one on bus 2 (iirc).

regards,

Koen

looks like the eeprom got incorrectly programmed. i'll write up some notes on reprogramming the eeprom from userspace.

You should be able to use the gumstix tools: http://www.sakoman.net/cgi-bin/gitweb.cgi?p=openembedded.git;a=commitdiff;h=73f8e5656e061e480dbf8cc3bb3c25030c380538

The only difference is that the gumstix eeprom is on bus 3 and the beagle one on bus 2 (iirc).

I just give it a quick shot. I change the bus in the script to 2 and
vendorid to 0x01. Invoking
writeeprom.sh 0x04 0x01 0x00
does not report any errors. However after rebooting, the same
information as before is read from eeprom (print using debug printfs()
I mentioned above). So the Zippy2 is still detected instead of Trainer
board.

Does anyone on the list updated eeprom for Trainer board successfully?

Tnanks,
Andrey.

looks like the eeprom got incorrectly programmed. i'll write up some notes on reprogramming the eeprom from userspace.

You should be able to use the gumstix tools: http://www.sakoman.net/cgi-bin/gitweb.cgi?p=openembedded.git;a=commitdiff;h=73f8e5656e061e480dbf8cc3bb3c25030c380538

The only difference is that the gumstix eeprom is on bus 3 and the beagle one on bus 2 (iirc).

I just give it a quick shot. I change the bus in the script to 2 and
vendorid to 0x01. Invoking
writeeprom.sh 0x04 0x01 0x00
does not report any errors. However after rebooting, the same
information as before is read from eeprom (print using debug printfs()
I mentioned above). So the Zippy2 is still detected instead of Trainer
board.

I think I forget to remove eeprom write protection :slight_smile: .
Will try again later today.

I think it might be a good idea to change the script so that it always
print a reminder to
remove write protection.

Regards,
Andrey.

looks like the eeprom got incorrectly programmed. i'll write up some notes on reprogramming the eeprom from userspace.

You should be able to use the gumstix tools: http://www.sakoman.net/cgi-bin/gitweb.cgi?p=openembedded.git;a=commitdiff;h=73f8e5656e061e480dbf8cc3bb3c25030c380538

The only difference is that the gumstix eeprom is on bus 3 and the beagle one on bus 2 (iirc).

I just give it a quick shot. I change the bus in the script to 2 and
vendorid to 0x01. Invoking
writeeprom.sh 0x04 0x01 0x00
does not report any errors. However after rebooting, the same
information as before is read from eeprom (print using debug printfs()
I mentioned above). So the Zippy2 is still detected instead of Trainer
board.

I think I forget to remove eeprom write protection :slight_smile: .
Will try again later today.

I think it might be a good idea to change the script so that it always
print a reminder to
remove write protection.

I've tried to make the script work on both beagle and overo: openembedded - Classic OpenEmbedded Development Tree

could you give it a try please?

regards,

Koen

Works perfect! After executing
./writeprom.sh 0x01 0x04 0x01 0x00
u-boot correctly recognizes Trainer board. Thanks!

However, booting stable 2.6.29 kernel does not lead to the wanted set
of files in /sys/class/gpio. Basically it is the same as before. Maybe
with the unstable 2.6.32 it would be better but I still need to find
out why it hangs up at the very early phase as I mentioned in other
thread.

Thank you,
Andrey.

Works perfect! After executing
./writeprom.sh 0x01 0x04 0x01 0x00
u-boot correctly recognizes Trainer board. Thanks!

However, booting stable 2.6.29 kernel does not lead to the wanted set
of files in /sys/class/gpio. Basically it is the same as before. Maybe
with the unstable 2.6.32 it would be better but I still need to find
out why it hangs up at the very early phase as I mentioned in other
thread.

Thank you,
Andrey.

P.S.
For some reasons I was not sure whether my post was sent successfully.
Sorry if you receive the same message twice.

Andrey,

the gpio's listed under sysfs can be exported like this:

http://blog.makezine.com/archive/2009/02/blinking_leds_with_the_beagle_board.html

i'll post a patch against 2.6.29 to add the exports to the beagle machine file.

just curious, what are you planning to do with your trainer board?

thanks
Dave

Hi Dave,

the gpio's listed under sysfs can be exported like this:

http://blog.makezine.com/archive/2009/02/blinking_leds_with_the_beagle_board.html

I was trying to echo 162 > /sys/class/gpio/export
but it does not create corresponding new entry.

But it was very late night yesterday and so maybe I just made
something wrong. Will try today again. In addition, it looks to me
like my BB shows hardware problems. Both 29 and 32 kernels are
crashing or hanging up periodically during boot up, etc. So I am not
sure anymore that what I am observing is pure software related
problem.

i'll post a patch against 2.6.29 to add the exports to the beagle machine file.

Great! Thanks.

just curious, what are you planning to do with your trainer board?

Quad-copter. Something similar to www.mikrokopter.com with on board
camera and I want it to make it controllable over internet. I already
have such car made with Intel Atom platform but now I want to fly :slight_smile:
and need to reduce the weight. That is why BB and Trainer.

Thanks,
Andrey.

Tn

How are you powering it? It could be that your PSU isn't delivering enough mA.

regards,

Koen

Hi Dave,

the gpio's listed under sysfs can be exported like this:

http://blog.makezine.com/archive/2009/02/blinking_leds_with_the_beagle_board.html

I was trying to echo 162 > /sys/class/gpio/export
but it does not create corresponding new entry.

But it was very late night yesterday and so maybe I just made
something wrong. Will try today again. In addition, it looks to me
like my BB shows hardware problems. Both 29 and 32 kernels are
crashing or hanging up periodically during boot up, etc. So I am not
sure anymore that what I am observing is pure software related
problem.

How are you powering it? It could be that your PSU isn't delivering enough mA.

Currently just over USB OTG connected to the notebook. Could it be the problem?
Anyway thank you very much for the hint!

Regards,
Andrey.

Hi Dave,

the gpio's listed under sysfs can be exported like this:

http://blog.makezine.com/archive/2009/02/blinking_leds_with_the_beagle_board.html

I was trying to echo 162 > /sys/class/gpio/export
but it does not create corresponding new entry.

But it was very late night yesterday and so maybe I just made
something wrong. Will try today again. In addition, it looks to me
like my BB shows hardware problems. Both 29 and 32 kernels are
crashing or hanging up periodically during boot up, etc. So I am not
sure anymore that what I am observing is pure software related
problem.

How are you powering it? It could be that your PSU isn't delivering enough mA.

Currently just over USB OTG connected to the notebook. Could it be the problem?
Anyway thank you very much for the hint!

That usually is the problem. The current kernel enables everything and some usb ports don't give 500mA, but closer to 400.

regards,

Koen