DIDJ Hacking
Received my 2 ebay didjs 2day...haven't done much with them yet but my 6 year old loves his 
Re: DIDJ Hacking
hmm, i've tried following the instructions on claude's web site but no luck so far
im not seeing anything in the terminal after transferring lightning boot through the uart. i went ahead and tried uploading u-boot but i still get nothing. can someone clarify the steps required to transfer lightning boot?
Re: DIDJ Hacking
I can get to the part where it asks to download uboot thru xmodem. But I'm not exactly sure whats the difference between xmodem and sending the file thru the terminal program, when I send it and push a button on the didj, I get the error "Xmodem_error: retryexceeded" but it says it loaded a bunch of bytes and is starting image at a certain number. Am going to install a switch that locks into position, thats for sure, holding that thing down gets old. Which I'm wondering weirdo557, are you holding the power button down the entire time? It took me a few tries to figure out it has to be held down the entire time, or the didj just shuts off.
Re: DIDJ Hacking
PhilKll wrote:I can get to the part where it asks to download uboot thru xmodem. But I'm not exactly sure whats the difference between xmodem and sending the file thru the terminal program, when I send it and push a button on the didj, I get the error "Xmodem_error: retryexceeded" but it says it loaded a bunch of bytes and is starting image at a certain number. Am going to install a switch that locks into position, thats for sure, holding that thing down gets old. Which I'm wondering weirdo557, are you holding the power button down the entire time? It took me a few tries to figure out it has to be held down the entire time, or the didj just shuts off.
Hey great,you are half way through!
Xmodem uses some control mechanism for file transfers (CRC,length,etc) , I used Hyperterminal to transfer uboot with Xmodem.
After you have transfered lighning-boot you have to switch to 115200 Baud and start the Xmodem transfer in your terminal program , as soon as you press a button on the Didj uboot is transmitted to the Didj.
There is a compile time switch in lighning-boot to prevent the automatic shutdown of the Didj , so you can release the power switch just after lightning-boot runs.
IIRC the compiler flag was '-DALIVE' , but I suggest you look at the lighning-boot sources.
Re: DIDJ Hacking
Is there any particular reason people are going the UART route to hack it? From what I can tell, it mounts as a standard drive (under Windows, you don't even have to change the drive letter -- it's mounted under C:\ProgramData\Leapfrog\LeapFrog Connect\Mnt\... on Vista), and all of the fun files are accessible. I would suspect there's minimal verification of applications that you install (probably only meta.inf and packagefiles.md5 are checked), so it seems like you could create a terminal app and toss it on via USB.
I disassembled the app.so for Jetpack Heroes, and they left all the symbols in.
IDA Pro is able to decipher all of g++ decorated names, so it's pretty straight-forward to read. As an example of this, I went to examine PowApp::Enter, and one of the things it does is checks the profile name. If it's "JEFF KATZ", it enables a cheat mode -- press the R shoulder button and forward to bypass most parts of the game!
The great thing about name decoration is that it also encodes the argument types, which can give you some hints as to how to use the built-in libraries. For example, it's pretty obvious what to pass to LeapFrog::Brio::CDebugMPI::DebugOut(LeapFrog::Brio::tDebugLevel, char const*, ...)const.
app.so also has references to OpenGL functions, so hopefully OpenGL apps won't be hard to port. Quake, anyone?
I disassembled the app.so for Jetpack Heroes, and they left all the symbols in.
The great thing about name decoration is that it also encodes the argument types, which can give you some hints as to how to use the built-in libraries. For example, it's pretty obvious what to pass to LeapFrog::Brio::CDebugMPI::DebugOut(LeapFrog::Brio::tDebugLevel, char const*, ...)const.
app.so also has references to OpenGL functions, so hopefully OpenGL apps won't be hard to port. Quake, anyone?
Re: DIDJ Hacking
Only parts of the NAND are exposed over USB. You won't be able to alter the kernel or bootloader over USB mass storage.
So if you can live with the Kernel as given by Leapfrog everything is fine , but I tried to alter the kernel towards my needs (e.g. SD Card support,USB RNDIS and a standard Linux Framebuffer with ioctls every Linux app. or lib understands). Further the USB device stack in the Leapfrog stock kernel isn't able to do any other "USB Gadget" mode than mass storage class -> no console over USB
Regarding OpenGL, yes there is a lib called libopengles.so (or so) , I did a disassembly of this lib and it should be doable to link against this lib
But I'm afraid Quake won't run without some heavy modifications, there is simply not enough RAM to run GLQUAKE imho.
But just for information http://www.youtube.com/watch?v=oEZYmJX1LwQ some stuff I did on the GPH WIZ. The WIZ has the same type of processor as the DIDJ , GLQUAKE was ported to the WIZ by 'Pickle' of GP32X.com. I added support for BSP30 (Halflife Maps) to the Quake Engine and did some patches to the texture memory handling. The Map in this video needs about 16MB Heap , the DIDJ ,IIRC ,has only 18MB usable RAM in Linux.
So if you can live with the Kernel as given by Leapfrog everything is fine , but I tried to alter the kernel towards my needs (e.g. SD Card support,USB RNDIS and a standard Linux Framebuffer with ioctls every Linux app. or lib understands). Further the USB device stack in the Leapfrog stock kernel isn't able to do any other "USB Gadget" mode than mass storage class -> no console over USB
Regarding OpenGL, yes there is a lib called libopengles.so (or so) , I did a disassembly of this lib and it should be doable to link against this lib
But just for information http://www.youtube.com/watch?v=oEZYmJX1LwQ some stuff I did on the GPH WIZ. The WIZ has the same type of processor as the DIDJ , GLQUAKE was ported to the WIZ by 'Pickle' of GP32X.com. I added support for BSP30 (Halflife Maps) to the Quake Engine and did some patches to the texture memory handling. The Map in this video needs about 16MB Heap , the DIDJ ,IIRC ,has only 18MB usable RAM in Linux.
Re: DIDJ Hacking
Thanks Claude, I got it to work, had some trouble with hyperterminal, but got it figured out, and was able to load zImage2, until the "reboot failed -- system halted" just like the output on your site. Now to get the compiler and stuff set up.
Re: DIDJ Hacking
Claude wrote:Further the USB device stack in the Leapfrog stock kernel isn't able to do any other "USB Gadget" mode than mass storage class -> no console over USB.
I have been messing around a bit, and don't currently have the hardware to give myself a contingency plan so I apologize for asking about something with which I've not tried yet. Looking at the jffs root I've seen that there is an init script for usbether and telnetd (192.168.2.63). Is the g_ether module not compiled in-kernel which would prevent that from being used? These scripts just appear as though they would provide shell access over the USB cable, even though the binaries may need to be rebuilt to run on the system. This would work along the lines of Gumstix embedded devices.
/usr/bin/launch_main is also very interesting. I would try modding this a bit to try putting binaries on the system but, again, I would like to have a bit more preparedness for a probable failure.
Also, do you happen to know the logistics of the "usbgadget" device and how, say, the "Needs Maintenance" (clear the doom file) flag are conveyed?
I've got a retail cart on the way to hook the cart insert/remove functions for a reliable hook into the launch_main script in such a way that I would feel comfortable doing so. I don't know if those files are checksumed but, considering how it DidJMfgTest and such are referenced, I don't think that is really going to be an issue. I have a scratchbox instance set up and am starting to look at linking to some of the object files (BLT/blitter and such). After I get the hardware that I have on order I will post anything possibly notable as far as on-hardware apps.
Re: DIDJ Hacking
rnddev wrote:Claude wrote:Further the USB device stack in the Leapfrog stock kernel isn't able to do any other "USB Gadget" mode than mass storage class -> no console over USB.
I have been messing around a bit, and don't currently have the hardware to give myself a contingency plan so I apologize for asking about something with which I've not tried yet. Looking at the jffs root I've seen that there is an init script for usbether and telnetd (192.168.2.63). Is the g_ether module not compiled in-kernel which would prevent that from being used? These scripts just appear as though they would provide shell access over the USB cable, even though the binaries may need to be rebuilt to run on the system. This would work along the lines of Gumstix embedded devices.
the Development board had a (USB ??) Ethernet adapter on board
I found something interesting embedded in the system that looks like it can take any game cart and turn it into a bare boot cart.
Look at mkbase.sh
Im going though all the scripts that come preloaded on the didj and documenting them
http://wtfmoogle.com/?page_id=757
fun commands I have found so far
http://wtfmoogle.com/?page_id=764
To display a raw rbg image on the lcd
layer-control /dev/layer0 s enable on
layer-control /dev/layer0 s format B8G8R8
layer-control /dev/layer0 s hstride 3
layer-control /dev/layer0 s vstride 960
layer-control /dev/layer0 s position 0 0 320 240
layer-control /dev/layer0 s dirty
imager /dev/layer0 /yourimage.rgb
if you have a .png it will work too
to change the default images you have to remount the root partition as WR and change the pngs in /var/screens
im working on a "Dark Didj" theme
Re: DIDJ Hacking
TheMoogle wrote:the Development board had a (USB ??) Ethernet adapter on board
Are you certain of that?
http://www.linux-usb.org/gadget/
http://www.armadeus.com/wiki/index.php?title=USB_Gadget
That looks to be how the usb mass storage is handled (the g_file_storage.ko). I was able to run some shell scripts and pipe some lsmod/strace/etc out and if you can find an instance of the g_ether.ko compiled for the USB chipset, a RNDIS file on the PC-side will let you encapsulate the traffic over USB. Even though they didn't include the driver, that's not to say that you couldn't get a binary-compatible file on there. In their provided source: Didj-Linux-3197-20080429-1631\linux-2.6.20-lf1000\drivers\usb\gadget\ether.c
telnetd is already installed on the device as part of busybox, also. It may require running rmmod for the mass storage to get ethernet going over the port, but with a serial terminal active that would not really be something that couldn't be repaired in the event of a problem loading g_ether.
Who is online
Users browsing this forum: No registered users and 1 guest
