Leapster Explorer: GPIO subsystem

From eLinux.org
Revision as of 19:49, 28 August 2010 by Reggie (Talk | contribs)

Jump to: navigation, search

This is a short article on using the lf1000-gpio subsystem. This is used internally by /etc/init.d/rcS and other system scripts to start the explorer in different states via emerald-boot. at least some the 'registers' in the gpio subsytem are loaded by reading a 'scratchpad' area of nand, then converting that raw scratchpad data to a human readable form via the values you will see below.

All of the kernel based magic happens via /sys/devices/platform/lf1000-gpio/ using cat you can find out the values of these registers, this is pretty much what emerald-boot does to tell itself which buttons config it should be using and how it should try and boot. /etc/rcS also uses this technique, again to setup the system for the different types of boot, mainly starting only the appropriate modules/services that are needed.

I believe that we can use some of the registers to our advantage and give ourselves extra boot modes where we only start a minimal set, which should see us getting some kind of performance boost from the various subsystems, this will also leave our recovery process alone.

here is a list of the registers:


/sys/devices/platform/lf1000-gpio/board_id
/sys/devices/platform/lf1000-gpio/boot_image
/sys/devices/platform/lf1000-gpio/boot_source
/sys/devices/platform/lf1000-gpio/bus/
/sys/devices/platform/lf1000-gpio/cart_id
/sys/devices/platform/lf1000-gpio/cpu_freq_in_hz
/sys/devices/platform/lf1000-gpio/driver/
/sys/devices/platform/lf1000-gpio/memcfg
/sys/devices/platform/lf1000-gpio/memclkdelay
/sys/devices/platform/lf1000-gpio/memcontrol
/sys/devices/platform/lf1000-gpio/memdqsindelay
/sys/devices/platform/lf1000-gpio/memdqsoutdelay
/sys/devices/platform/lf1000-gpio/memrefresh
/sys/devices/platform/lf1000-gpio/memtime0
/sys/devices/platform/lf1000-gpio/memtime1
/sys/devices/platform/lf1000-gpio/modalias
/sys/devices/platform/lf1000-gpio/pad_strength_bus
/sys/devices/platform/lf1000-gpio/pad_strength_gpio_a_high
/sys/devices/platform/lf1000-gpio/pad_strength_gpio_a_low
/sys/devices/platform/lf1000-gpio/pad_strength_gpio_b_high
/sys/devices/platform/lf1000-gpio/pad_strength_gpio_b_low
/sys/devices/platform/lf1000-gpio/pad_strength_gpio_c_high
/sys/devices/platform/lf1000-gpio/pad_strength_gpio_c_low
/sys/devices/platform/lf1000-gpio/panic
/sys/devices/platform/lf1000-gpio/power
/sys/devices/platform/lf1000-gpio/pullup_enable_gpio_a
/sys/devices/platform/lf1000-gpio/pullup_enable_gpio_b
/sys/devices/platform/lf1000-gpio/pullup_enable_gpio_c
/sys/devices/platform/lf1000-gpio/request
/sys/devices/platform/lf1000-gpio/shutdown
/sys/devices/platform/lf1000-gpio/subsystem/
/sys/devices/platform/lf1000-gpio/touchscreen
/sys/devices/platform/lf1000-gpio/uevent
/sys/devices/platform/lf1000-gpio/user_0

As you can see there are a lot of them, we are only really interested in a few at this moment:

# this is how the system works out whether its booting a didj, explorer or LF Dev board(s)
/sys/devices/platform/lf1000-gpio/board_id
# this is how rcS/EB knows which boot type it should use and which set of scripts to run once the kernel is loaded
/sys/devices/platform/lf1000-gpio/boot_image
# this is how it knows where it booted from (Nor,Nand,USB,UART)
/sys/devices/platform/lf1000-gpio/boot_source
# this is how the system differentiates between cart types (Game,MFG cart)
/sys/devices/platform/lf1000-gpio/cart_id
# this is how the system determines what speed the cpu should run at
/sys/devices/platform/lf1000-gpio/cpu_freq_in_hz
# I think this tells the system whether the kernel panic'd or not
/sys/devices/platform/lf1000-gpio/panic
# whether it was a warm or cold boot?
/sys/devices/platform/lf1000-gpio/power
# the type boot requested from the kernel
/sys/devices/platform/lf1000-gpio/request
# how the system shutdown the last time
/sys/devices/platform/lf1000-gpio/shutdown

lets break that down a bit further:

board_id

The system uses board ID at compile time as well as boot, this is crucial to the system as it tells it which board type and consequently which types of boot it can perform, for the didj this will be nand or uart, for the explorer it will be nor,usb or uart. At compile time CONFIG_BOARD_ID is crucial for the system to know how the gpio pins are configured for the buttons.

boot_image

this is how the system partly determines which set of scripts it should run at boot up via rcS, valid values are:

PLAY, RECOVERY (there may be more, I will update as I find them)

I believe this also tells emerald boot whether to boot normally or from USB for recovery purposes

boot_source

This is how the system knows which method was used to boot, as mentioned in board_id, valid values for the explorer are:

NOR,USB,UART
and for the didj:
NAND,UART

cart_id

The explorer and didj systems use at least 2 types of cartridge, a normal game cart or a MFG cart, with the latter being able to perform system recovery, cart_id is how the system can tell the difference between cart types.


request

The explorer has various types of kernel boot modes, that it can set on exit or during the course of a session, on next startup these 'requests' tell it which scripts /etc/init.d/rcS should run, with valid values being:

TRAPDOOR, SHORT, FAILED, UNCLEAN, BATTERY, UPDATE, RETURN, PLAY

for an explanation of what they do see /usr/bin/show-scr


This is a WIP., more to follow.