path: root/documentation/plain_sources/special_notes.tex

%
% Charset: utf8
% Content type: Plain LATEX
% Content: This chapter give some Mini6410 specific hints how to use the
%          hardware provided by the Mini6410.
%
% Copyright Jürgen Beisert <jbe@pengutronix.de>, 2011
%
% This work is licensed under the Creative Commons Attribution 3.0 Unported License.
% To view a copy of this license, visit:
%           http://creativecommons.org/licenses/by/3.0/
% or send a letter to:
% Creative Commons, 444 Castro Street, Suite 900, Mountain View, California, 94041, USA.
%
% Refer the file CREDITS for all people working on this document.
%
% This file content will be part of the "OSELAS.BSP-Pengutronix-Mini6410-Quickstart.pdf"
%
% Note: This document uses some externaly defined LATEX commands. If you try to
% run LATEX only on this file it will fail due to the absense of these commands.
% All these commands are starting with 'ptxdist'.
%

\newcommand{\perCpuName}{S3C6410}
\newcommand{\curKernelRev}{3.7}

\section{Available Kernel Releases}	\label{sec:kernelreleases}

The predifined Mini6410 platform configuration always uses the latest Linux
kernel release. If users want to stay with an older Linux kernel release,
they are also available. Here is a list of currently available Linux kernel
releases in the \ptxdistBSPName{}:

\begin{itemize}
	\item 3.1, stable patch level 10
	\item \curKernelRev{}, stable patch level 10 (defaultl)
	\item 3.0, stable patch level 67
	\item 2.6.39, stable patch level 4
\end{itemize}

If we want to build the BSP with a non-default kernel release, we just run
\texttt{ptxdist platformconfig} and change the kernel setting prior to building.
As \ptxdist{} checks the MD5 sums of the archives, we also have to change the
MD5 sum of the corresponding kernel archive.

Note: The MD5 sums for the kernels are (used by \ptxdist{}):
\begin{itemize}
	\item 3.7: \texttt{21223369d682bcf44bcdfe1521095983}
	\item 3.1: \texttt{edbdc798f23ae0f8045c82f6fa22c536}
	\item 3.0: \texttt{ecf932280e2441bdd992423ef3d55f8f}
	\item 2.6.39: \texttt{25cd73d797a49ad5b4119b67f1caf2cc}
\end{itemize}

For older \ptxdist{} revisions than 2012.05.0 the kernel's archive format
is \textit{bz2} instead of the newer \textit{xz}. Here are the MD5 sums
for reference for the \textit{bz2} format.

\begin{itemize}
	\item 3.1: \texttt{8d43453f8159b2332ad410b19d86a931}
	\item 3.0: \texttt{398e95866794def22b12dfbc15ce89c0}
	\item 2.6.39: \texttt{1aab7a741abe08d42e8eccf20de61e05}
\end{itemize}

% ----------------------------------------------------------------------------

\section{Available Userland Configuration}	\label{sec:userland}

The Mini6410 BSP comes with two different predefined userland configurations:

\begin{itemize}
	\item \textbf{configs/ptxconfig}: it is the standard one to get a small
	running embedded system. It can be used as a base for your own
	development running the Mini6410 headless (without an LCD unit).
	\item \textbf{configs/ptxconfig.qt}: this configuration is intended for
	graphical usage of the Mini6410. It has the Qt library enabled and brings
	in a small Qt based application. This application will be started
	automatically at system's startup, to show how to get a graphical system
	up and running.
\end{itemize}

It's up to you and your needs which configuration you may choose in section
\ref{sec:selectingauserlandconfig}.

\subsection{Some details about the \texttt{configs/ptxconfig.qt}}

The mentioned small Qt based application we can find in
\texttt{local\_src/qt4-demo-2011.07.0/}. It can act as a template for our own
Qt development.

The "secrets" how to build and install this application we can find in
\texttt{rules/qt4-demo.make} and the corresponding menu file in
\texttt{rules/qt4-demo.in}.

The "magic" behind the autostart of this small Qt based application at system
startup can be found in \texttt{projectroot/etc/init.d/startup}.

Note: The small Qt demo is prepared to run on a landsscape 480 x 272 screen. If
your screen differs from this setup, don't expect a correct image.

% ----------------------------------------------------------------------------

\newcommand{\perDisplayName}{LCDN43-1020 (N43)}
\newcommand{\perDisplayRes}{480x272}

\section{Framebuffer}					\label{sec:fb}
% --------------------

This driver gains access to the display via device node \texttt{/dev/fb0}.
For this BSP the \perDisplayName{} display with a resolution of
\perDisplayRes{} is supported.

A simple test of this feature can be run with:

\begin{ptxshell}[escapechar=|]{^}
# fbtest
\end{ptxshell}

This will show various pictures on the display.

You can check your framebuffer resolution with the command
\begin{ptxshell}[escapechar=|]{^}
# fbset
\end{ptxshell}

NOTE: \texttt{fbset} cannot be used to change display resolution or colour depth.
Depending on the framebuffer device different kernel command line may be needed
to do this. Please refer to your display driver manual for details.

% ----------------------------------------------------------------------------

\newcommand{\perGpioChip}{32}
\newcommand{\perGpioNumber}{34}

\section{GPIO}					\label{sec:GPIO}
% ------------

Like most modern System-on-Chip CPUs, the \perCpuName{} has numerous GPIO pins.
Some of them are inaccessible for the userspace, as Linux drivers use them
internally. Others are also used by drivers but are exposed to userspace via
sysfs. Finally, the remaining GPIOs can be requested for custom use by
userspace, also via sysfs.

Refer to the in-kernel documentation \texttt{Documentation/gpio.txt} for
complete details how to use the sysfs-interface for manually exporting GPIOs.

% ----------------------------------------------------------------------------

\subsection{GPIO Usage Example}		\label{sec:gpioexample}

When generic architecture GPIO support is enabled in the kernel, some new
entries appear in sysfs. Everything is controlled via read and writable
files to generate events on the digital lines.

We find all the control files in \texttt{/sys/class/gpio}. In that path, there are
a number of \texttt{gpiochipXXX} entries, with \texttt{XXX} being a decimal
number. Each of these folders provide information about a single GPIO
controller registered on the Mini6410 board, for example with
\texttt{gpiochip\perGpioChip}:

\begin{ptxshell}[escapechar=|]{^}
# ls /sys/class/gpio/gpiochip|\perGpioChip |
base       label      ngpio      subsystem  uevent
\end{ptxshell}

The entry \texttt{base} contains information about the base GPIO number and
\texttt{ngpio} contains all GPIOs provided by this GPIO controller.\\
We use \texttt{GPIO\perGpioNumber{}} as an example to show the usage of a
single GPIO pin.

\begin{ptxshell}[escapechar=|]{^}
# echo |\ptxshellcmd\perGpioNumber | > /sys/class/gpio/export|
\end{ptxshell}

This way we export \texttt{gpio\perGpioNumber{}} for userspace usage. If the
export was successful, we will find a new directory named
\texttt{/sys/class/gpio/gpio\perGpioNumber{}} afterwards. Within this directory
we will be able to find the entries to access the functions of this GPIO.
If we wish to set the direction and initial level of the GPIO, we can use the
command:

\begin{ptxshell}[escapechar=|]{^}
# echo high > /sys/class/gpio|\perGpioNumber |/direction|
\end{ptxshell}

This way we export \texttt{GPIO\perGpioNumber{}} for userspace usage and define
our GPIO's direction attribute to an output with initially high level. We can
change the value or direction of this GPIO by using the entries
\texttt{direction} or \texttt{value}.

Note: This method is not very fast, so for quickly changing GPIOs it is still
necessary to write a kernel driver. The method shown works well, for example to
influence an LED directly from userspace.

To unexport an already exported GPIO, write the corresponding gpio-number into
\texttt{/sys/class/gpio/export}.

\begin{ptxshell}[escapechar=|]{^}
# echo |\perGpioNumber | > /sys/class/gpio/unexport
\end{ptxshell}

Now the directory \texttt{/sys/class/gpio/gpio\perGpioNumber} will disappear.

Note: The GPIO\perGpioNumber{} is available at connector 6, pin 4 for
measurement.

\begin{important}
The current usage of most of the pins can be read from the entry in
\texttt{/sys/kernel/debug/gpio}.
\end{important}
% ----------------------------------------------------------------------------

\section{I\texttwosuperior C Master}			\label{sec:I2C}
% -------------------------------------

The \perCpuName{} processor based Mini6410 supports a dedicated
I\texttwosuperior C controller onchip. The kernel supports this controller as a
master controller.

Additional I\texttwosuperior C device drivers can use the standard
I\texttwosuperior C device API to gain access to their devices through this
master controller.
For further information about the I\texttwosuperior C framework see
\texttt{Documentation/i2c} in the kernel source tree.

% ----------------------------------------------------------------------------

\newcommand{\perEepromName}{AT24c04}
\newcommand{\perEepromSize}{512 bytes}
\newcommand{\perEepromPath}{0-0050}

\subsection{I\texttwosuperior C Device \perEepromName {}}	\label{sec:EEPROM}
% ------------------------------------------------------------

This device is a \perEepromSize{} non-volatile memory for general purpose usage.

This type of memory is accessible through the sysfs filesystem. To read the
EEPROM content simply \texttt{open()} the entry
\texttt{/sys/bus/i2c/devices/\perEepromPath{}/eeprom} and use
\texttt{fseek()} and \texttt{read()} to get the values.

% ----------------------------------------------------------------------------

\newcommand{\perLedName}{led4}
\newcommand{\perAvailableTriggers}{[none] nand-disk mmc0 mmc1 timer heartbeat backlight gpio}

\newcommand{\LedPath}{/sys/class/leds/\perLedName\#}

\section{LEDs}				\label{sec:LED}
% ------------

The LEDs on the Mini6410 can be controlled via the LED-subsystem of the Linux
kernel. It provides methods for switching them on and off as well as using
so-called triggers.  For example, you could trigger the LED using a timer.
That enables us to make it blink with any frequency we want.

All LEDs can be found in the directory \texttt{/sys/class/leds}. Each one has
its own subdirectory. We will use \texttt{\perLedName} for the following
examples.

For each directory, you have a file named \texttt{brightness} which can be read and
written with a decimal value between 0 and 255. The first one means LED off,
the latter maximum brightness. Inbetween values scale the brightness if the LED
supports that. If not, non-zero means just LED on.

\begin{ptxshell}[escapechar=|]{^}
|\LedPath| echo 255 > brightness; # LED on
|\LedPath| echo 128 > brightness; # LED at 50% (if supported)
|\LedPath| echo 0 > brightness; # LED off
\end{ptxshell}

LEDs can be connected to triggers. A list of available triggers we can get from the
\texttt{trigger} entry

\begin{ptxshell}[escapechar=|]{^}
|\LedPath| cat trigger
|\perAvailableTriggers{}|
\end{ptxshell}

The embraced entry is the currectly connected trigger to this LED.

To change the trigger source to the \textit{timer}, just run a:

\begin{ptxshell}[escapechar=|]{^}
|\LedPath| echo timer > trigger
\end{ptxshell}

If the timer-trigger is activated you should see two additional files in the
current directory, namely \texttt{delay\_on} and \texttt{delay\_off}. You can
read and write decimal values there, which will set the corresponding delay in
milliseconds. As an example:

\begin{ptxshell}[escapechar=|]{^}
|\LedPath| echo 250 > delay_on
|\LedPath| echo 750 > delay_off
\end{ptxshell}

will blink the LED being on for 250ms and off for 750 ms.

Replace \texttt{timer} with \texttt{none} to disable the trigger again. Or
select a different one from the list read from the \texttt{trigger} entry.

Refer to \texttt{Documentation/leds/leds-class.txt} in-kernel documentation for
further details about this subsystem.

% ----------------------------------------------------------------------------

\section{MMC/SD Card}					\label{sec:SDC}
%-----------------------

The Mini6410 supports \textit{Secure Digital Cards} and
\textit{Multi Media Cards} to be used as general purpose blockdevices. These
devices can be used in the same way as any other blockdevice.

\begin{important}
These kind of devices are hot pluggable, so you must pay attention not to
unplug the device while its still mounted. This may result in data loss.
\end{important}

After inserting an MMC/SD card, the kernel will generate new device nodes in
\texttt{dev/}. The full device can be reached via its \texttt{/dev/mmcblk0}
device node, MMC/SD card partitions will occur in the following way:

\begin{ptxshell}[escapechar=|]{^}
/dev/mmcblk0p|\textbf{Y}|
\end{ptxshell}
\texttt{\textbf{Y}} counts as the partition number starting from 1 to the max
count of partitions on this device.

Note: These partition device nodes will only occur if the card contains a
valid partition table ("harddisk" like handling). If it does not contain one,
the whole device can be used for a filesystem ("floppy" like handling). In
this case \texttt{/dev/mmcblk0} must be used for formatting and mounting.

The partitions can be formatted with any kind of filesystem and also handled in
a standard manner, e.g. the \texttt{mount} and \texttt{umount} command work as
expected.

\section{SDIO Card}					\label{sec:SDIO}
%-----------------------

This interface is available at connector CON9. Its feature is untested yet.

% ----------------------------------------------------------------------------

\newcommand{\perNetworkChip}{ DM9000}
\newcommand{\perNetworkInterface}{eth0}

\section{Network}				\label{sec:NET}
% ------------------

The Mini6410 module has a\perNetworkChip{} ethernet chip onboard,
which is being used to provide the \texttt{\perNetworkInterface{}} network
interface. The interface offers a standard Linux network port which can be
programmed using the BSD socket interface.

% ----------------------------------------------------------------------------

% Note: not supported yet
%
% \section{SPI Master}				\label{sec:SPI}
% % ---------------------
% 
% The Mini6410 board supports an SPI bus, based on the \perCpuName 's
% integrated SPI controller. It is connected to the onboard devices using the
% standard kernel method, so all methods described here are not special to the
% Mini6410.
% 
% Connected devices can be found in the sysfs at the path
% \texttt{/sys/bus/spi/devices}. It depends on the corresponding SPI slave device
% driver providing access to the SPI slave device through this way (sysfs),
% or any different kind of API.
% 
% \begin{important}
% Currently no SPI slave devices are registered, so the
% \texttt{/sys/bus/spi/devices} directory is empty.
% \end{important}

%
% Idea: Describe how to add an existing SPI device driver to the platform
%

% ----------------------------------------------------------------------------

\section{Touchscreen}					\label{sec:TOUCH}
% --------------------

A simple test of this feature can be run with:

\begin{ptxshell}[escapechar=|]{^}
# ts_calibrate
\end{ptxshell}

to calibrate the touch and with:

\begin{ptxshell}[escapechar=|]{^}
# ts_test
\end{ptxshell}

to run a simple application using this feature.

To see the exact events the touch generates, we can also use the
\texttt{evtest} tool.

\begin{ptxshell}[escapechar=|]{^}
# evtest /dev/input/touchscreen
Input driver version is 1.0.1
Input device ID: bus 0x19 vendor 0xdead product 0xbeef version 0x102
Input device name: "S3C24XX TouchScreen"
Supported events:
  Event type 0 (Sync)
  Event type 1 (Key)
    Event code 330 (Touch)
  Event type 3 (Absolute)
    Event code 0 (X)
     Value      0
     Min        0
     Max     1023
  Event code 1 (Y)
     Value      0
     Min        0
     Max     1023
Testing ... (interrupt to exit)
\end{ptxshell}

Whenever we touch the screen this tool lists the values the driver reports.

\begin{important}
Don't rely on the event node the kernel creates in the \texttt{/dev/input/}
direcory. Over the time the index can change. This board support package comes
with a special \textit{udev} rule, which creates a link called \texttt{touchscreen}
always pointing to the correct event node. Use the \texttt{touchscreen} in your
setup instead of the plain event node.
\end{important}

\subsection{If the Touchscreen does not work}

A functional touchscreen depends on some external configurations and parameters.
Firstly, the touchscreen driver for the \perCpuName CPU must be enabled in the
kernel. If it is supported, it can be checked at run-time with the following
command:

\begin{ptxshell}[escapechar=|]{^}
# ls /sys/bus/platform/drivers
\end{ptxshell}

A \texttt{samsung-ts} must be listed in this directory. If not, the kernel
must be re-configured to support this device.

Secondly, a functional touchscreen depends on is the registered touchscreen
device. If it is registered, this can be checked at run-time with this command:

\begin{ptxshell}[escapechar=|]{^}
# ls /sys/bus/platform/devices
\end{ptxshell}

A \texttt{samsung-ts} must be listed in this directory. If not, something
is preventing the kernel from registering this device.

\subsection{If the Touchscreen does not work as expected}

It's not easy to create a touchscreen driver that works with all kinds of
touchscreens. They differ in their hardware parameters, so most of the time
some adaptions must be done to get better results.

Two locations exists where parameters can be changed:

\begin{itemize}
	\item in the kernel driver
	\item in the \textit{tslib} (\textbf{t}ouch\textbf{s}creen \textbf{lib}rary)
\end{itemize}

The \textit{tslib} is a userland component and can be changed at any time.
The kernel driver is a compiled in component, so the kernel must be re-built
and re-started to make any change visible.

Lets start with the kernel driver: It uses three parameters to support the
physical behaviour of the touchscreen.

\begin{itemize}
	\item \textbf{.delay} a delay counted in clocks of 3.68 MHz between
		the measurement of the X and Y coordinate. If the touchscreen
		lines are filtered with a low-pass it could be useful to
		increase this value. Max value is 0xffff.
	\item \textbf{.presc} clock prescaler for the AD converter. The larger the
		value is, the lower the AD converter works (FIXME: Seems not be
		used)
	\item \textbf{.oversampling\_shift} defines the samples to be measured and
		to be averaged before reporting a coordinate. '0' means one sample per
		report, '1' means two samples per report, '2' means 4 samples and
		so on.
\end{itemize}

To modify the setting, open the file
\texttt{\ptxdistPlatformDir /build-target/linux-\curKernelRev /arch/arm/mach-s3c64xx/mach-mini6410.c}
and search for the \texttt{s3c\_ts\_platform} structure. It looks like this:

\begin{ptxshell}[escapechar=|]{^}
static struct s3c2410_ts_mach_info s3c_ts_platform __initdata = {
    .delay = 10000,
    .presc = 49,
    .oversampling_shift = 2,
};
\end{ptxshell}

After modifying, the kernel must be re-built:

\begin{ptxshell}[escapechar=|]{^}
|\$| ptxdist drop kernel compile
|\$| ptxdist go
\end{ptxshell}

These steps ensure the modified sources are re-compiled. Use this new kernel
and do the tests with the touchscreen again.

To change the userland \textit{tslib} this can be done at run-time of
the Mini6410. Just modify the \texttt{/etc/ts.conf}.

\begin{itemize}
	\item \textbf{module\_raw input} means the tslib uses the raw data from
		the Linux's input system
	\item \textbf{module pthres pmin=1} means the minimal pressure must be
		'1' to count as a touchscreen event. Other values do not make
		sense yet, as the driver does not support pressure measurement
	\item \textbf{module variance delta=30} FIXME
	\item \textbf{module dejitter delta=10} FIXME
	\item \textbf{module linear} FIXME
\end{itemize}

After changing one of these entries a run of \texttt{ts\_test} can show if the
new settings are better than the previous ones.

\begin{important}
Some display units with touchscreen support for the Mini6410 are using a OneWire
interface to control the touchscreen. These kind of display units are not
supported by this board support package.
\end{important}

% ----------------------------------------------------------------------------

\section{LCD Backlight}				\label{sec:BLIGHT}
% -----------------------

The backlight of the LCD can be controlled via the sysfs entry in:

\begin{ptxshell}{|}
/sys/class/leds/backlight/
\end{ptxshell}

To switch it \textit{off}, just write a '0' into its \texttt{brightness} entry:

\begin{ptxshell}{|}
# echo 0 > /sys/class/leds/backlight/brightness
\end{ptxshell}

and a '1' to switch it \textit{on} again:

\begin{ptxshell}{|}
# echo 1 > /sys/class/leds/backlight/brightness
\end{ptxshell}

% ----------------------------------------------------------------------------

% note: not supported yet
%
% \section{USB Host Controller Unit}			\label{sec:USBHOST}
% % -----------------------------------
% 
% The Mini6410 supports a standard OHCI Rev. 1.0a compliant host controller
% onboard for low and full speed connections.
% 
%
% Idea: Describe how to add support for various USB devices
%

% ----------------------------------------------------------------------------

% note: not supported yet
%

% \newcommand{\perWatchdogTimeout}{15}
% 
% \section{Watchdog}			\label{sec:WD}
% % -------------------
% 
% The internal watchdog will be activated when an application opens the device
% \texttt{/dev/watchdog}. Default timeout is \perWatchdogTimeout{} seconds.
% An application must periodically write to this device. It does not matter what
% is written. Just the interval between these writes should not exceed the
% timeout value, otherwise the system will be reset.
% 
% For testing the hardware, there is also a shell command which can do the
% triggering:
% 
% \begin{ptxshell}{|}
% # watchdog -t <trigger-time-in-seconds> /dev/watchdog
% \end{ptxshell}
% 
% This command is part of the busybox shell environment. Keep in mind, that
% it should only be used for testing. If the watchdog gets fed by it, a crash of
% the real application will go unnoticed.
% 
% For the Mini6410 the default 60 seconds interval period the
% tool is using is too long. The driver for the \perCpuName{} only supports up to
% a 40 seconds interval. So, the additional parameter \texttt{-T 40} must be
% given.

%----------------------------------------------------------------------------

\section{ADC}							\label{sec:ADC}
%------------

Getting the digital equivalent of one of the analogue input channels can be
done by reading the corresponding entries in the sysfs.

For example the analogue input channel 0 on the Mini6410 is connected to the
potentiometer W1. By reading the entry
\texttt{/sys/devices/platform/s3c64xx-adc/s3c-hwmon/in0\_input}
we can watch the different digital values while turning the potentiometer W1.

Note: The analogue input channels 4 ... 7 are occupied by the touchscreen
feature and can only be used as simple analogue inputs if the touchscreen
feature is disabled.

%----------------------------------------------------------------------------

\section{Keypad}						\label{sec:ADC}
%----------------

Using the up to 6 available key buttons on the Mini6410 in a reqular manner
requires a working console in the kernel. Here the list of the current key codes
they generate when pressed:

\begin{itemize}
	\item K1, code 'F1'
	\item K2, code 'F2'
	\item K3, code 'F3'
	\item K4, code 'F4'
	\item K5, code 'F5'
	\item K6, code 'F6'
	\item K7, code 'F7'
	\item K8, code 'F8'
\end{itemize}

If one wants to change the generated codes, she/he can change it in the
platform code found in \texttt{arch/arm/mach-s3c64xx/mach-mini6410.c},
specially in the array \texttt{mini6410\_buttons}.

If the key buttons are working as expected, can also be checked without a
working console with the following command:

\begin{ptxshell}[escapechar=|]{^}
# evtest /dev/input/buttons
Input driver version is 1.0.1
Input device ID: bus 0x19 vendor 0x1 product 0x1 version 0x100
Input device name: "gpio-keys"
Supported events:
  Event type 0 (Sync)
  Event type 1 (Key)
   Event code 59 (F1)
    Event code 60 (F2)
    Event code 61 (F3)
    Event code 62 (F4)
    Event code 63 (F5)
    Event code 64 (F6)
    Event code 65 (F7)
    Event code 66 (F8)
Testing ... (interrupt to exit)
\end{ptxshell}

\begin{important}
Don't rely on the event node the kernel creates in the \texttt{/dev/input/}
direcory. Over the time the index can change. This board support package comes
with a special \textit{udev} rule, which creates a link called \texttt{buttons}
always pointing to the correct event node. Use the \texttt{buttons} in your
setup instead of the plain event node.
\end{important}

%----------------------------------------------------------------------------

\section{Buzzer}					\label{sec:Buzzer}
%---------------

The buzzer on the Mini6410 will be triggered by a regular alert in a console.
So, a simple

\begin{ptxshell}[escapechar=|]{^}
# echo -e "\a"
\end{ptxshell}

can make a noise. But this only works if local console support is enabled.

If no local console is available the small \texttt{ring-bell} tool will help.

\begin{ptxshell}[escapechar=|]{^}
# ring-bell /dev/input/beeper
\end{ptxshell}

will make some noise for you.

%----------------------------------------------------------------------------

% note: not supported yet
%
% \section{Audio}						\label{sec:AUDIO}
% %--------------
% 
% This kernel supports the audio capabilities of the Mini6410 via a standard
% ALSA device. So, most of the available tools to play or record sounds should
% work out of the box.
% 
% To control the audio mixer run the tool \texttt{alsamixer}, to play a simple
% sound file \texttt{aplay} can be used and for MP3 files, texttt{madplay} is the
% correct tool.

%----------------------------------------------------------------------------

% note: not supported yet
%
% \section{USB Device}					\label{sec:USBgadget}
% %--------------------
% 
% The S3C2440 processor in the Mini6410 comes with a USB device unit. This is
% the physical interface to let the Mini6410 act in some roles in the USB world.
% For example the Mini6410 can act as a printer or a simple serial adapter.
% There are also drivers to act as a mass storage device, but its setup is more
% complicated. So, this section describes the printer case.
% 
% To prepare the Mini6410 to act as a printer just load the printer gadget driver.
% 
% \begin{ptxshell}[escapechar=|]{^}
% # modprobe g_printer
% Printer Gadget: Printer Gadget, version: 2007 OCT 06
% Printer Gadget: using s3c2410_udc, OUT ep2-bulk IN ep1-bulk
% \end{ptxshell}
% 
% Starting this driver will create a \texttt{/dev/g\_printer} device node. This
% device node can be opened for reading and writing. It's the end of two
% "pipes" for data to and from a connected host.
% 
% Now, the Mini6410 is ready for connection to a host via its USB B plug.
% If it works, the kernel at the host side will detect a new device:
% 
% \begin{ptxshell}[escapechar=|]{^}
% usb 1-1: new full speed USB device number 2 using s3c2410-ohci
% usblp0: USB Bidirectional printer dev 7 if 0 alt 0 proto 2 vid 0x0525 pid 0xA4A8
% \end{ptxshell}
% 
% Note: At the host side the \texttt{usblp} module is required to make this new
% USB hotplug device visible as a printer.
% 
% At the host side now a \texttt{/dev/usblp0} device node will be created. Also
% this device node can be opened for reading and writing. And also this node is
% the end of two "pipes" for data to and from the "printer".
% 
% Everything we 'echo' into \texttt{/dev/usblp0} at the host side, we can 'cat'
% from \texttt{/dev/g\_printer} at the Mini6410 side. And vice versa.
% 
% And a real funny game is to connect Mini6410's USB A to its own USB B. Then
% the Mini6410 can talk to itself.

%----------------------------------------------------------------------------

%
% What is still missing?
%
% - how to use the Mini6410 as a gadget (printer, serial or ...)
% - on the FriendlyARM forum someone asks how to implement a W1 controller
%
% Ideas:
% - how to speed up booting
% - boot splash
% - how to bring in Qt and an example application
% - how to bring up a local terminal and accept USB keyboard input

%----------------------------------------------------------------------------

\section{Get the latest BSP Release for the Mini6410}

Information and the latest release of the Mini6410 BSP can be found on
our website at:

\url{http://www.oselas.org/oselas/bsp/index\_en.html}

%----------------------------------------------------------------------------

\section{Be Part of the Mini6410 BSP Development}

If you want to use the latest and greatest board support package for the
Mini6410 you can use the git repository as your working source, instead
of a release archive.

The git repository can be found here:

\begin{center}
\texttt{http://git-public.pengutronix.de/git-public/OSELAS.BSP-Pengutronix-Mini6410.git}
\end{center}

If you want to contribute to this project by sending patches, these patches
should always be based on the \textbf{master} branch of this repository.

% Dave McLaughlin 2012-03-29 19:57:27 Link
% Similar to the Mini210 model, this is a simplified version of the Mini6410
% for download.
%
% http://www.3dcontentcentral.com/parts/download-Part.aspx?id=357787&catalogid=171
%
% Remember this is not 100\% accurate as the connectors are generic and not
% the exact ones but it was enough for me to use with my PCB software.
%
% Enjoy.
%
% Dave...