1 (edited by marius 2011-03-21 15:41:09)

Topic: Application UART

By finding the schematic http://files.chumby.com/hackerboard/falconwing_chb3.pdf for the v1 hacker board I finally found the pins the RX and TX pins are connected to. So the next step was to try make and make it work. Off course I can't get it to work wink I'm not really a die hard kernel guru, so most of my changes are just by looking at the code and changing what looks right to me smile

My steps so far:
Downloaded the kernel and found the part where the appuart is configured. A little digging let me to /linux-2.6.28.mx233/arch/arm/mach-stmp3xxx/stmp378x.c

Changed the appuart_pins_1 to the following:

struct pin_desc appuart_pins_1[] = {
        { PINID_GPMI_D14, PIN_FUN2, PIN_4MA, PIN_1_8V, 0, },
        { PINID_GPMI_D15, PIN_FUN2, PIN_4MA, PIN_1_8V, 0, },
};

Can I just leave out the CTR and RTS pins?

and changed appuart_pins to:

struct pin_group appuart_pins[] = {
        [0] = {
                .pins           = appuart_pins_1,
                .nr_pins        = ARRAY_SIZE(appuart_pins_1),
        },
};

Removed appuart_pins_0 because they look like AUART1 and I want to use AUART2.

In /linux-2.6.28.mx233/arch/arm/mach-stmp3xxx/stmp378x_devb.c I uncommented the following:

static struct platform_device *devices[] = {
  *snip*
        &stmp3xxx_appuart,
  *snip*

So it compiles, and update my chumby, run "modprobe stmp-app" and I see the following line in dmesg:

[  154.530000] stmp37xx-appuart.0: ttySP0 at MMIO 0xf006c000 (irq = 24) is a stmp37xx-appuart.0

Success? I hooked up a "Oscilloscope" (an Arduino running a analogread and GUI showing a graph) and send some data to the device:

while [ 1 ]; do echo -n "U" > /dev/ttySP0; done

No luck sad So after some head scratching I check the Mux setting for the GPIO14&15 pins:

chumby-:/ # regutil -r HW_PINCTRL_MUXSEL0
Value at 0x80018100: 0xffffffff

Hmm thats wrong, should be 0x5fffffff right? So I change it:

regutil -w HW_PINCTRL_MUXSEL0_CLR=0xa0000000
Setting 0x80018108: 0x5fffffff -> 0x5fffffff ok

And still no luck. And that is where I am now smile Anybody any insights? Maybe the chumby ppl already have a fixed kernel? (x-ing fingers) I'm probably doing it completely wrong smile

2

Re: Application UART

Did you ever get any further on this?

Re: Application UART

Nope. Didn't go much further. Choose to use a USB -> Serial for now.

Re: Application UART

I would really like to get the auxiliary serial port working properly from within openembedded linux. Although I've done a lot of experimentation with openembedded on the CHB I'm still not sure how to go about incorporating the kinds of changes that marius has made here into the chumby-dev-image produced by openembedded. Can anyone give me some pointers?

I've added kernel-module-stmp-app to my version of the image but executing "modprobe stmp-app" doesn't even yield the dmesg result that marius documented so I figure that the modifications to the stock stmp378x.c and/or stmp378x_devb.c files are necessary. I'm pretty sure it would also be necessary to remove GPMI_D14 and GPMI_D15 from the list of pins that are initialised as GPIO's but I haven't got as far as figuring out the details yet.

Re: Application UART

With these changes to the kernel modeled on marius' example plus adding kernel-module-stmp-app to my receipe (overlooked that the first time through), I get this response to "insmod stmp-app.ko"

[  677.600000] stmp37xx-appuart.0: ttySP0 at MMIO 0xf006c000 (irq = 24) is a stmp37xx-appuart.0
[  677.620000] Found APPUART 3.0.0

I was expecting to see two devices detected since I've defined two, but only one shows.  I think all I've managed to do is reproduce marius' state and I don't think I have any way to test a 3.3V serial port.  Hmm - I think I might have a logic level converter that I could use to pair up with a 5V Arduino serial port... if I can find it.

Re: Application UART

Oops, confirmed in a round-about way that my /dev/ttySP0 is talking to AUART1, not AUART2.  Writing the /dev/ttySP0 resets the USB hub as evidenced by dmesg logs showing USB disconnecting and re-scanning.  This makes sense as AUART1_TX is tied to HUB_RESET.

# cat > /dev/ttySP0

[ 6252.330000] usb 1-1: USB disconnect, address 6
[ 6252.330000] usb 1-1.2: USB disconnect, address 7
[ 6252.720000] usb 1-1: new high speed USB device using fsl-ehci and address 8
[ 6252.910000] usb 1-1: configuration #1 chosen from 1 choice
[ 6252.920000] hub 1-1:1.0: USB hub found
[ 6252.950000] hub 1-1:1.0: 4 ports detected
...

Re: Application UART

After reading the driver code more carefully I see that it only defines a single device even if appuart_pin declares two pin groups.  I'll try again with only auart2 defined.  Building...

Re: Application UART

Well no one said this was going to be easy...

Changing the definition of appuart_pins is not enough.
The driver stmp-app.c uses DMA to move data through the UART.
We also need to update the DMA parameters.

In arch/arm/mach-stmp3xxx/devices.h there is a definition for appuart_resources
which defines channel 6 for Rx and channel 7 for Tx.  According to Table 11-1
"APBX DMA Channel Assignments" in the i.MX23 reference manual those are
the correct channels for AUART1, and should be 8 and 9 respectively for AUART2.

The values for IRQ_UARTAPP_TX_DMA and IRQ_UARTAPP_RX_DMA in that table
also need to be changed to the values for UART2 shown in Table 5-1. i.MX23 Interrupt Sources.

Not clear to me if the registers also need to be changed - the manual doesn't seem to list separate registers for each UART.  More research required.

Re: Application UART

I've been able to build linux 3.4 separately for the chumby but I'm still trying to figure out how to use it in chumby-oe. Using the latest version of linux has the advantage that it already has complete support for the imx23 built-in, no hacks required, but it does seem to introduce a fresh set of problems.

I keep getting the following error:

Nothing PROVIDES 'virtual/arm-angstrom-linux-gnueabi-depmod-3.4'

After talking to one of the openembedded developers last night I've got some ideas about how to proceed. Apparently older versions of openembedded which maintain compatibility with kernel 2.4 have problems keeping track of newer versions. The solution is to either declare PV explicitly or to use a newer version of openembedded.

http://arago-project.org/git/?p=arago.g … c663565504

http://cgit.openembedded.org/openembedd … 04e7dfd6ce

Re: Application UART

Oooooh! You've got Linux 3.4 working on Falconwing? Any chance you can toss your .config up somewhere? smile

11 (edited by infurl 2012-04-25 21:49:40)

Re: Application UART

I'm not sure if it will work or not because I haven't been able to figure out how to install and test it yet, however I have been able to compile it using the cross compiler tools from the chumby-oe repository.

Linux 3.4 already has a defconfig which as far as I can tell is an exact match for the i.MX233 in the Chumby. Modifications to that config will mainly depend on what wireless adapter you are using. I'm using one based on the RTL8192C so I had to enable the legacy API in the kernel configuration and compile the drivers externally, but there are many other wireless adapters that are supported by the kernel and which should be easier to use.

The steps that I've taken so far are as follows:

cd
git clone git://github.com/clearwater/chumby-oe.git
# follow the instructions in the readme to build chumby-oe
cd
git clone git://github.com/torvalds/linux.git
mkdir arm-linux
cd arm-linux
export ARCH=arm
export CROSS_COMPILE=../chumby-oe/output-angstrom-.9/sysroots/x86_64-linux/usr/armv5te/bin/arm-angstrom-linux-gnueabi-
make --directory ../linux O=../arm-linux imx_v4_v5_defconfig
#make --directory ../linux O=../arm-linux menuconfig
make --directory ../linux O=../arm-linux
make --directory ../linux O=../arm-linux modules_prepare