Mini6410/Debian Squeeze: touchscreen causing reboot on boot

Was hoping that someone else came across this and has a fix for it ...

I followed the instructions at
http://code.google.com/p/mini6410-debian/wiki/Tutorial

to get my system working. Kernel config config_mini6410_a70 was modified to
add support for dm-crypt, and to shut off the initram. System will boot
just fine to serial console. When trying to boot with console going to the
touchscreen, the penguin logo comes up, the boot messages scroll by, and
the kernel gets as far as requesting an IP from the DHCP server, then
immediately reboots. This will happen over and over again, until the
touchscreen simply stays completely white. Note that when that finally
occurs, you can still access a console via serial port, and the system is
up and running. This occurs with more than one of the 7" touch screens, so
it is not related to the specific piece of hardware.

Is there something wrong with the kernel driver for the touchscreen, or
does it need to be configured somehow? Is this something that works in a
later version of the kernel (i.e. post 2.6.36)?

Thanks in advance.

this is just a guess, the FA kernel sources use initramfs, which you've
disabled, so you're no longer using the /scripts/friendlyarm.cpio in the
kernel sources, I know for the mini210 that this file contains all of the
touchscreen setup stuff in the 'init' file and adds it to the /dev/ folder.

Thanks, Reggie. Will take a look at that. I had disabled the initramfs for
booting from the SD card, but, technically, I am booting from U-Boot in the
NAND at this point, so perhaps that is something to look into. I do see
touchscreeen and touchscreen1wire in the /dev/ folder already, but maybe
there is something that the kernel needs during the startup process in the
initrd to make it work right.
I had tried this with the stock kernel (mini6410_config_a70) as well, and
had gotten the same results, but I had not taken the "noinitrd" out of the
kernel boot args. Going to try this now.

There is more, take a look at the /scripts/friendlyarm.cpio file, you
should be able to open it in any archive manager, then open up the init
file in a text editor, it's all in there what it does :)

Looked into the friendlyarm.cpio file ... I see a couple of nodes for /dev/
that I don't have, but nothing related to the touchscreen. There is also an
installation of BusyBox in there; not sure if this is of any use to me
since I am running a full Debian install.

Also looked at the init file ... looks like there are a couple of
configuration files that I am missing out of /etc/, but I have not seen
where they come from. Going to poke around and see if I can find them.

This is the contents of the init file in the cpio, there is a distinct
section that starts at the ONE_WIRE_PROC= line that deals specifically with
touchscreens.

Do you have serial console connection to your 6410?  If so it might be
useful if you post a log including the errors.

#! /bin/sh

PATH=/sbin:/bin:/usr/sbin:/usr/bin
runlevel=S
prevlevel=N
umask 022
export PATH runlevel prevlevel

#
#  Trap CTRL-C &c only in this shell so we can interrupt subprocesses.
#
trap ":" INT QUIT TSTP
/bin/hostname FriendlyARM
/bin/mount -n -t proc proc /proc

cmdline=`cat /proc/cmdline`

ROOT=none
ROOTFLAGS=
ROOTFSTYPE=
NFSROOT=
IP=
INIT=/sbin/init

for x in $cmdline ; do
  case $x in
  root=*)
    ROOT=${x#root=}
    ;;
  rootfstype=*)
    ROOTFSTYPE="-t ${x#rootfstype=}"
    ;;
  rootflags=*)
    ROOTFLAGS="-o ${x#rootflags=}"
    ;;
  init=*)
    INIT=${x#init=}
    ;;
  nfsroot=*)
    NFSROOT=${x#nfsroot=}
    ;;
  ip=*)
    IP=${x#ip=}
    ;;

  esac
done

if [ ! -z $NFSROOT ] ; then
  echo $NFSROOT | sed s/:/\ /g  > /dev/x ;  read sip dir < /dev/x
  echo $IP | sed s/:/\ /g > /dev/x;  read cip sip2 gip netmask hostname
device autoconf < /dev/x
  rm /dev/x
  #echo $sip $dir $cip $sip2 $gip $netmask $hostname $device $autoconf
  mount -t nfs $NFSROOT /r -o nolock,proto=tcp
  #[ -e /r/dev/console ] || exec /bin/sh

elif [ ! -z $run_fs_image ] ; then
  ROOTFSTYPE="-t ext3"
  for i in 1 2 3 4 5 ; do
  /bin/mount -n -o sync -o noatime -o nodiratime -t vfat /dev/mmcblk0p1
/sdcard && break
  echo Waiting for SD Card...
  sleep 1
  done
  /sbin/losetup /dev/loop0 /sdcard/$run_fs_image
  /bin/mount $ROOTFSTYPE /dev/loop0 /r
  mount -o move /sdcard /r/sdcard
  #/sbin/losetup /dev/loop1 /r/sdcard/swap
  #/sbin/swapon /dev/loop1

else
  /bin/mount -n $ROOTFLAGS $ROOTFSTYPE $ROOT /r
fi

ONE_WIRE_PROC=/proc/driver/one-wire-info
ETC_BASE=/r/etc
[ -d /r/system/etc ] && ETC_BASE=/r/system/etc
[ -e $ETC_BASE/ts.detected ] && . $ETC_BASE/ts.detected
[ -z $CHECK_1WIRE ] && CHECK_1WIRE=Y
if [ $CHECK_1WIRE = "Y" -a -e $ONE_WIRE_PROC ] ; then
  if read lcd_type fw_ver tail < $ONE_WIRE_PROC ; then
    if [ x$lcd_type = "x0" -a x$fw_ver = "x0" ] ; then
      TS_DEV=/dev/touchscreen
    else
      TS_DEV=/dev/touchscreen-1wire
      echo "1Wire touchscreen OK"
    fi
    if [ -e $ETC_BASE/friendlyarm-ts-input.conf ]; then
      sed "s:^\(TSLIB_TSDEVICE=\).*:\1$TS_DEV:g"
$ETC_BASE/friendlyarm-ts-input.conf > $ETC_BASE/ts-autodetect.conf
      mv $ETC_BASE/ts-autodetect.conf $ETC_BASE/friendlyarm-ts-input.conf
-f
      echo "CHECK_1WIRE=N" > $ETC_BASE/ts.detected
      sync
    fi
  fi
fi

[ -e /r/etc/friendlyarm-ts-input.conf ] && .
/r/etc/friendlyarm-ts-input.conf
[ -e /r/system/etc/friendlyarm-ts-input.conf ] && .
/r/system/etc/friendlyarm-ts-input.conf
export TSLIB_TSDEVICE

#exec /bin/sh

umount /proc
exec switch_root /r $INIT </r/dev/console >/r/dev/console 2>&1

Really no log to post, unfortunately. When it resets, it is in the middle
of DHCP negotiation, you see a single "K" appear like it is trying to say
"Kernel panic", and the board resets.

I don't have any of those configuration files at the moment, but I did find
another blog post that mentions pulling them out of the Qt archives that
come on the DVDs I got with the board. Going to take a look at that next.
Maybe all I need is to get them into place, then make an init script that
gets called early to configure the touchscreen like this init does. Will
see how it goes.

I would set loglevel=8 in the kernel commandline, you won't have any of
those files, do you know which touchscreen driver the a70 is using?  If
it's 1-wire then you'll need do what that touchscreen section is doing,
you'll only need to do it once.

I'm starting to think it's something hardware related at this point ...

Noted that the touchscreen apps/conf wasn't loaded from Debian. apt-get'ed
the libts-bin and tsconf packages. No friendlyarm-ts-input driver, so
grabbed that from the rootfs_qtopia_qt4 tarball that came with the board.
Set up an init script to mimic what the initrd is doing. Still doesn't make
a difference.

For s**ts & grins I decided to re-flash the Qtopia installation onto the
NAND and try and eliminate my installation from the equation. The Qtopia
install does the same thing as my install.

Since the error seems to be happening when the Ethernet port is being
brought up, I disconnected the network line. Boots through fine. Connect
the line, no problem. Try and bring up eth0 with an address - board reset.

So at this point, I'm at a loss as to where to go with this. I'm going to
try and get one of the reps at andahammer on the phone and see if they have
any suggestions to try. I'm hoping that the NAND is not shot, though there
should be no reason for it to be. Will post back when I have some more
info. I hope that no one else has had to go through this to customize their
board.

Well, as it all seems to live or die around the ethernet, I would start
looking at how the networking is setup, maybe turn on debugging in the
dm9000 driver?

Also look at the standard networking files, perhaps there's something
stupid missing?  hosts file, hostname, routing etc?

Ok, found the culprit ... wrong power supply. Apparently the Mini2440 uses
a different power supply than the Mini6410, and we are looking at both
boards right now. When I gathered up the hardware from our recently
released developer, he was using the wrong plug; never knew it because he
never had the display connected. *facepalm*

So .... for anyone else who experiences some oddity like this, make sure
you have the right plug. The Mini6410 requires a 5V/2A plug; the Mini2440
uses a 5V/1A plug. The difference in amperage is just enough that when all
peripheral devices are connected and online (touchscreen, Ethernet, and USB
keyboard), the board pulls just a tad too much power, and everything resets
(and when I say a tad too much, I'm talking about the voltage dropping <
0.1V from the 5.0V required to power everything).

Reggie, thanks for the help and the time you spent here; it has been
greatly appreciated. I'm now off to label the hardware so that I know which
blessed plug I'm supposed to use ..... *grumble grumble* :)

William, congratulations and you're welcome.

All of the PSU that I have for mini boards are the US 2 prong style plugs,
so I have to use the 'travel' plugs you find in £ stores, it's actually
very handy as I have to hot-glue the psu to the travel plug, then I write
on the side of the plug which board it's for.

FYI. I have been running a mini210S from a 5v/1.5a psp charger without
issues.