Leapster Explorer: USB Boot settings - Revision history

Peter Huewe at 09:58, 27 October 2011

2011-10-27T09:58:38Z

Jrspruitt: /* Notes */

2011-07-23T05:48:17Z

‎Notes

Jrspruitt at 05:32, 23 July 2011

2011-07-23T05:32:00Z

Reggie at 13:49, 5 November 2010

2010-11-05T13:49:08Z

Reggie at 00:03, 28 August 2010

2010-08-28T00:03:56Z

Reggie at 23:15, 27 August 2010

2010-08-27T23:15:34Z

Reggie at 23:08, 27 August 2010

2010-08-27T23:08:46Z

Reggie: Created page with 'This is a short tutorial to explain how to setup the explorer so that you can use the USB Boot method to test a kernel running a 'stock' bootup rcS script. This shouldn't damage …'

2010-08-27T23:05:45Z

Created page with 'This is a short tutorial to explain how to setup the explorer so that you can use the USB Boot method to test a kernel running a 'stock' bootup rcS script. This shouldn't damage …'

New page

This is a short tutorial to explain how to setup the explorer so that you can use the USB Boot method to test a kernel running a 'stock' bootup rcS script. This shouldn't damage your explorer but should you mess up your OS you won't be able to automatically start the recovery process. as long as you have console access you should be able to manually start the recovery process. You have been warned.

Usually when you boot the leapfrog explorer in USB Boot mode you are setting off a chain of actions that are supposed to lead to updating a new kernel and rootfs or recovering a broken OS, whatever the boot method, the explorer runs /etc/init.d/rcS and reads the boot image type on line 32 of /etc/init.d/rcS :

<code>

if [ `cat /sys/devices/platform/lf1000-gpio/boot_image` = "RECOVERY" ]; then
# Recovery boot
echo "Recovery Mode"
# Launch in background; it will "poweroff" when done
/usr/bin/recovery &
exit 0
elif .....
</code>

the elif copes with the different types of boot mode that could be expected, this is fine if you want to update or fix your explorer but if you want to use USB Boot to test a kernel with the normal file system and boot settings then then you're out of luck. This is where this tutorial comes in. for the time being I have created a quick and dirty hack to overcome this issue.

in rcS edit lines 32 and 38 and make them look like this:

<code>
if [ `cat /sys/devices/platform/lf1000-gpio/boot_image` = "RECOVERY" ] && [ !-e /flags/usbdev ]; then

elif [ `cat /sys/devices/platform/lf1000-gpio/request` = "TRAPDOOR" ] && [ !-e /flags/usbdev ]; then
</code>

on the explorer when you want to boot 'normally' from USB boot run the following command:

<code>
touch /flags/usbdev
</code>

and to reverse the process to allow an automatic recovery:

<code>
rm /flags/subdev
</code>

notes
----

whilst this method works and allows you to test a custom kernel booting it from usb using the 'normal' boot options as if you were booting the kernel from the explorer normally its probably not the absolute best way to do things. At the moment if you have usbdev set if something goes wrong with the OS it won't kick start recovery mode, however as long as you've got serial access then you will be able to start dftpdevice manually and start the recovery process via pager.sh or LFConnect or simply remove /flags/usbdev

Files to note:
/etc/init.d/rcS
/usr/bin/recovery
/usr/bin/trapdoor
/usr/bin/short-circuit

the latter 3 being scripts called via rcS

I believe there is a better method using the leapfrogs internal flagging system, using /sys/devices/platform/lf1000-gpio/ subsystem:

request
boot_image
boot_source

but this will require further investigation as some of this will be tied to emerald boot and messing with that could be dangerous.

← Older revision		Revision as of 09:58, 27 October 2011
Line 55:		Line 55:

	But this will require further investigation as some of this will be tied to Emerald-Boot and messing with that could be dangerous.		But this will require further investigation as some of this will be tied to Emerald-Boot and messing with that could be dangerous.
		+
		+	[[Category:Leapster Explorer]]

← Older revision		Revision as of 05:48, 23 July 2011
Line 54:		Line 54:
	power		power

−	But this will require further investigation as some of this will be tied to ~~emerald boot~~ and messing with that could be dangerous.	+	But this will require further investigation as some of this will be tied to Emerald-Boot and messing with that could be dangerous.

@@ Line 1: / Line 1: @@
 This is a short tutorial to explain how to setup the explorer so that you can use the USB Boot method to test a kernel running a 'stock' bootup rcS script. This shouldn't damage your explorer but should you mess up your OS you won't be able to automatically start the recovery process. as long as you have console access you should be able to manually start the recovery process. You have been warned.
-I'd like to thank Nirvous, NullMoogleCable, PhillKll, Claude, JKent, Jburks, GrizzlyAdams and anyone I may have forgotten for their help :)
+== Hardware Needed ==
+== Editing rcS ==
-Usually when you boot the leapfrog explorer in USB Boot mode you are setting off a chain of actions that are supposed to lead to updating a new kernel and rootfs or recovering a broken OS, whatever the boot method, the explorer runs /etc/init.d/rcS and reads the boot image type on line 32 of /etc/init.d/rcS :
+Usually when you boot the LeapFrog Explorer in USB Boot mode you are setting off a chain of actions that are supposed to lead to updating a new kernel and rootfs or recovering a broken OS, whatever the boot method, the Explorer runs /etc/init.d/rcS and reads the boot image type on line 32 of /etc/init.d/rcS :
   if [ `cat /sys/devices/platform/lf1000-gpio/boot_image` = "RECOVERY" ]; then
@@ Line 15: / Line 17: @@
-the elif copes with the different types of boot mode that could be expected, this is fine if you want to update or fix your explorer but if you want to use USB Boot to test a kernel with the normal file system and boot settings then then you're out of luck.  This is where this tutorial comes in.  for the time being I have created a quick and dirty hack to overcome this issue.
+The elif copes with the different types of boot mode that could be expected, this is fine if you want to update or fix your Explorer but if you want to use USB Boot to test a kernel with the normal file system and boot settings then you're out of luck. This is where this tutorial comes in. For the time being I have created a quick and dirty hack to overcome this issue.
-in rcS edit lines 32 and 38 and make them look like this:
+In rcS edit lines 32 and 38 and make them look like this:
@@ Line 24: / Line 26: @@
-on the explorer when you want to boot 'normally' from USB boot run the following command:
+On the explorer when you want to boot 'normally' from USB boot run the following command:
-−
-−
   touch /flags/usbdev
-and to reverse the process to allow an automatic recovery:
+And to reverse the process to allow an automatic recovery:
-−
-−
   rm /flags/usbdev
+== Notes ==
+whilst this method works and allows you to test a custom kernel booting it from USB using the 'normal' boot options as if you were booting the kernel from the explorer normally, its probably not the absolute best way to do things.  At the moment if you have usbdev set if something goes wrong with the OS it won't kick start recovery mode, however, as long as you've got serial access then you will be able to start dftpdevice manually and start the recovery process via pager.sh or LFConnect or simply remove /flags/usbdev and reboot.  Using USB Boot will also set you into a loop where after a reboot it will try and do another usb boot, this can be desirable if you are testing kernels/software but if you want it to stop simply power off the unit by holding down the power button.
-notes
-----
-−
-whilst this method works and allows you to test a custom kernel booting it from usb using the 'normal' boot options as if you were booting the kernel from the explorer normally, its probably not the absolute best way to do things.  At the moment if you have usbdev set if something goes wrong with the OS it won't kick start recovery mode, however, as long as you've got serial access then you will be able to start dftpdevice manually and start the recovery process via pager.sh or LFConnect or simply remove /flags/usbdev and reboot.  Using USB Boot will also set you into a loop where after a reboot it will try and do another usb boot, this can be desirable if you are testing kernels/software but if you want it to stop simply power off the unit by holding down the power button.
 Files to note:
@@ Line 48: / Line 42: @@
 /usr/bin/short-circuit
-the latter 3 being scripts called via rcS depending on what type of boot the system expects to perform.
+The latter 3 being scripts called via rcS depending on what type of boot the system expects to perform.
-−
-I believe there is a better method using the leapfrogs internal flagging system, using the /sys/devices/platform/lf1000-gpio/ subsystem:
+I believe there is a better method using the LeapFrog's internal flagging system, using the /sys/devices/platform/lf1000-gpio/ subsystem:
 request
@@ Line 61: / Line 54: @@
 power
-but this will require further investigation as some of this will be tied to emerald boot and messing with that could be dangerous.
+But this will require further investigation as some of this will be tied to emerald boot and messing with that could be dangerous.

← Older revision		Revision as of 13:49, 5 November 2010
Line 1:		Line 1:
	This is a short tutorial to explain how to setup the explorer so that you can use the USB Boot method to test a kernel running a 'stock' bootup rcS script. This shouldn't damage your explorer but should you mess up your OS you won't be able to automatically start the recovery process. as long as you have console access you should be able to manually start the recovery process. You have been warned.		This is a short tutorial to explain how to setup the explorer so that you can use the USB Boot method to test a kernel running a 'stock' bootup rcS script. This shouldn't damage your explorer but should you mess up your OS you won't be able to automatically start the recovery process. as long as you have console access you should be able to manually start the recovery process. You have been warned.
		+
		+	I'd like to thank Nirvous, NullMoogleCable, PhillKll, Claude, JKent, Jburks, GrizzlyAdams and anyone I may have forgotten for their help :)

@@ Line 4: / Line 4: @@
 Usually when you boot the leapfrog explorer in USB Boot mode you are setting off a chain of actions that are supposed to lead to updating a new kernel and rootfs or recovering a broken OS, whatever the boot method, the explorer runs /etc/init.d/rcS and reads the boot image type on line 32 of /etc/init.d/rcS :
   if [ `cat /sys/devices/platform/lf1000-gpio/boot_image` = "RECOVERY" ]; then
-	# Recovery boot
+    # Recovery boot
-	echo "Recovery Mode"
+    echo "Recovery Mode"
-	# Launch in background; it will "poweroff" when done
+    # Launch in background; it will "poweroff" when done
-	/usr/bin/recovery &
+    /usr/bin/recovery &
-	exit 0
+    exit 0
   elif
-</code>
 the elif copes with the different types of boot mode that could be expected, this is fine if you want to update or fix your explorer but if you want to use USB Boot to test a kernel with the normal file system and boot settings then then you're out of luck.  This is where this tutorial comes in.  for the time being I have created a quick and dirty hack to overcome this issue.
@@ Line 18: / Line 17: @@
 in rcS edit lines 32 and 38 and make them look like this:
-<code>
   if [ `cat /sys/devices/platform/lf1000-gpio/boot_image` = "RECOVERY" ] && [ !-e /flags/usbdev ]; then
   elif [ `cat /sys/devices/platform/lf1000-gpio/request` = "TRAPDOOR" ] && [ !-e /flags/usbdev ]; then
-</code>
 on the explorer when you want to boot 'normally' from USB boot run the following command:
-<code>
-touch /flags/usbdev
+ touch /flags/usbdev
-</code>
 and to reverse the process to allow an automatic recovery:
-<code>
-rm /flags/subdev
+ rm /flags/usbdev
-</code>
@@ Line 39: / Line 38: @@
 ----
-whilst this method works and allows you to test a custom kernel booting it from usb using the 'normal' boot options as if you were booting the kernel from the explorer normally its probably not the absolute best way to do things.  At the moment if you have usbdev set if something goes wrong with the OS it won't kick start recovery mode, however as long as you've got serial access then you will be able to start dftpdevice manually and start the recovery process via pager.sh or LFConnect or simply remove /flags/usbdev
+whilst this method works and allows you to test a custom kernel booting it from usb using the 'normal' boot options as if you were booting the kernel from the explorer normally, its probably not the absolute best way to do things.  At the moment if you have usbdev set if something goes wrong with the OS it won't kick start recovery mode, however, as long as you've got serial access then you will be able to start dftpdevice manually and start the recovery process via pager.sh or LFConnect or simply remove /flags/usbdev and reboot.  Using USB Boot will also set you into a loop where after a reboot it will try and do another usb boot, this can be desirable if you are testing kernels/software but if you want it to stop simply power off the unit by holding down the power button.
 Files to note:
@@ Line 47: / Line 46: @@
 /usr/bin/short-circuit
-the latter 3 being scripts called via rcS
+the latter 3 being scripts called via rcS depending on what type of boot the system expects to perform.
-−
-I believe there is a better method using the leapfrogs internal flagging system, using /sys/devices/platform/lf1000-gpio/ subsystem:
+I believe there is a better method using the leapfrogs internal flagging system, using the /sys/devices/platform/lf1000-gpio/ subsystem:
 request