Leapster Explorer: GPIO subsystem - Revision history

Peter Huewe: Added Category

2011-10-27T09:56:42Z

Added Category

Jrspruitt at 05:46, 23 July 2011

2011-07-23T05:46:52Z

Show changes

Reggie at 13:48, 5 November 2010

2010-11-05T13:48:31Z

Reggie at 00:13, 29 August 2010

2010-08-29T00:13:55Z

Reggie at 19:49, 28 August 2010

2010-08-28T19:49:18Z

Reggie at 14:06, 28 August 2010

2010-08-28T14:06:04Z

Reggie at 13:44, 28 August 2010

2010-08-28T13:44:30Z

Reggie: Created page with '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 eme…'

2010-08-28T12:37:16Z

Created page with '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 eme…'

New page

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.

All of the 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 how it should try and boot and /etc/rcS uses this technique, again to setup the system for the different types of boot (mainly starting only the appropriate modules/services that are needed.

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:

/sys/devices/platform/lf1000-gpio/board_id # this is how the system works out whether its booting a didj,

explorer or LF Dev board(s)
/sys/devices/platform/lf1000-gpio/boot_image # 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_source # this is how it knows where it booted from (Nor,Nand,USB,UART)
/sys/devices/platform/lf1000-gpio/cart_id # this is how the system differentiates between cart types (Game,MFG cart)
/sys/devices/platform/lf1000-gpio/cpu_freq_in_hz # this is how the system determines what speed the cpu should run at
/sys/devices/platform/lf1000-gpio/panic # I think this tells the system whether the kernel panic'd or not
/sys/devices/platform/lf1000-gpio/power # whether it was a warm or cold boot?
/sys/devices/platform/lf1000-gpio/request # the type boot requested from the kerne;
/sys/devices/platform/lf1000-gpio/shutdown # how the system shutdown the last time

← Older revision		Revision as of 09:56, 27 October 2011
Line 135:		Line 135:

	This will fool the shutdown system into thinking that we have completed the update and will allow you ro boot from the normal kernel by simply issuing the '''reboot''' command.		This will fool the shutdown system into thinking that we have completed the update and will allow you ro boot from the normal kernel by simply issuing the '''reboot''' command.
		+
		+
		+	[[Category:Leapster Explorer]]

← Older revision		Revision as of 13:48, 5 November 2010
Line 1:		Line 1:
	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.		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.
		+
		+	I'd like to thank Nirvous, NullMoogleCable, PhillKll, Claude, JKent, Jburks, GrizzlyAdams and anyone I may have forgotten for their help :)

	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.		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.

@@ Line 6: / Line 6: @@
 here is a list of the registers:
   /sys/devices/platform/lf1000-gpio/board_id
@@ Line 63: / Line 61: @@
   # how the system shutdown the last time
   /sys/devices/platform/lf1000-gpio/shutdown
-lets break that down a bit further:
+lets break that down a bit further into scratchpad :
 '''board_id'''
@@ Line 74: / Line 77: @@
 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)
+  PLAY, RECOVERY, IMAGE_2, IMAGE_3
-I believe this also tells emerald boot whether to boot normally or from USB for recovery purposes
+I believe this also tells emerald boot whether to boot normally or from USB for recovery purposes, discussions on the #didj irc channel have suggested the use of the unused (needs confirmation) IMAGE_2, IMAGE_3 options for our own purposes such as USB kernel boot using an NFS rootfs or SD rootfs.
 '''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:
+This is how the system knows which boot source should be or was used to boot, as mentioned in board_id, valid values for the explorer are:
-  NOR,USB,UART
+  valid values are: NOR,NAND,USB,UART,UNKNOWN
-  and for the didj:
+  valid for the explorer:
-  NAND,UART
+ NOR,USB,UART, UNKNOWN
 '''cart_id'''
@@ Line 97: / Line 102: @@
   TRAPDOOR, SHORT, FAILED, UNCLEAN, BATTERY, UPDATE, RETURN, PLAY
-for an explanation of what they do see /usr/bin/show-scr
+for an explanation of what they do see /usr/bin/show-scr and linux2.6/arch/arm/mach-lf1000/include/mach/gpio.h
-This is a WIP., more to follow.
+This is a WIP. more to follow.

@@ Line 1: / Line 1: @@
-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.
+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 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 how it should try and boot and /etc/rcS uses this technique, again to setup the system for the different types of boot (mainly starting only the appropriate modules/services that are needed.
+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.
 here is a list of the registers:
@@ Line 86: / Line 88: @@
 '''cart_id'''
-The explorer and didj systems use 2 types of cartridge, a normal game cart of 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
+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.

← Older revision		Revision as of 14:06, 28 August 2010
Line 87:		Line 87:

	The explorer and didj systems use 2 types of cartridge, a normal game cart of 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		The explorer and didj systems use 2 types of cartridge, a normal game cart of 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.		This is a WIP., more to follow.

@@ Line 43: / Line 43: @@
 As you can see there are a lot of them, we are only really interested in a few at this moment:
- /sys/devices/platform/lf1000-gpio/board_id # this is how the system works out whether its booting a didj,
+lets break that down a bit further:
-explorer or LF Dev board(s)
+'''board_id'''
- /sys/devices/platform/lf1000-gpio/boot_image # 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_source # this is how it knows where it booted from (Nor,Nand,USB,UART)
+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.
- /sys/devices/platform/lf1000-gpio/cart_id # this is how the system differentiates between cart types (Game,MFG cart)
- /sys/devices/platform/lf1000-gpio/cpu_freq_in_hz # this is how the system determines what speed the cpu should run at
+'''boot_image'''
-  /sys/devices/platform/lf1000-gpio/panic # I think this tells the system whether the kernel panic'd or not
- /sys/devices/platform/lf1000-gpio/power # whether it was a warm or cold boot?
+this is how the system partly determines which set of scripts it should run at boot up via rcS, valid values are:
-  /sys/devices/platform/lf1000-gpio/request # the type boot requested from the kerne;
-  /sys/devices/platform/lf1000-gpio/shutdown # how the system shutdown the last time
+  PLAY, RECOVERY (there may be more, I will update as I find them)