Dingoonity.org
Dingux (Dingoo Linux) => General => Topic started by: vimrc on October 30, 2009, 10:41:22 pm
-
Hi, guys,
Now I post the modified zImage files again... All the following zImage files have been patched to enable the power off function. Additionally, If you want to use Mplayer to player videos, please download the zImage with IPU enabled. Don't forget to change the filename to zImage. It should be noted the modified zImage is unofficial, you use it at your own risk!
The maximum attachment size is limited, so I put them in my google page:
For 9331:
http://bossninja.googlepages.com/zImage_9331.rar (IPU disabled)
http://bossninja.googlepages.com/zImage_9331_ipu.rar (IPU enabled)
For 9325:
http://bossninja.googlepages.com/zImage_9325.rar (IPU disabled)
http://bossninja.googlepages.com/zImage_9325_ipu.rar (IPU enabled)
======================================================================================
I also release the modified zImage in which the MMC interface mode is set to 4-bit.
(Faster R/W speed, but more probabilities to corrupt your SD card. In fact, it works well in my dingoo so I'm using this one. Freaks only!! )
For 9331:
http://bossninja.googlepages.com/zImage4bit_noipu_9331.rar (IPU disabled)
http://bossninja.googlepages.com/zImage4bit_ipu_9331.rar (IPU enabled)
For 9325:
http://bossninja.googlepages.com/zImage4bit_noipu_9325.rar (IPU disabled)
http://bossninja.googlepages.com/zImage4bit_ipu_9325.rar (IPU enabled)
=====================================================================================
(Optional)
I also wrote two very simple scripts to enable or disable the IPU for dmenu so you can switch the two modes without a computer. (Well, I concede this way is a little stupid, but it's safe and effective before the kexec is activated.)
1. Rename the two zImage files corresponding to your type of LCD to "zImage_ipu" and "zImage_noipu" respectively.
2. Put the "zImage_ipu" and "zImage_noipu" to /local/. (Please do not remove the old zImage file in your SD card!!)
3. Extract the compressed file and copy disableipu.sh and enableipu.sh to /local/dmenu/scripts.
http://bossninja.googlepages.com/zImage_switch_scripts.rar
4. Add the following entries in dmenu. (For example: menu_system.cfg)
MenuItem EnableIPU
{
Icon = "res/system/terminal.png"
Name = " EnableIPU"
Executable = "sh ./enableipu.sh"
WorkDir = "/boot/local/dmenu/scripts"
}
MenuItem DisableIPU
{
Icon = "res/system/terminal.png"
Name = " DisableIPU"
Executable = "sh ./disableipu.sh"
WorkDir = "/boot/local/dmenu/scripts"
}
If you want to disable the IPU, just select the DisableIPU in dmenu and Dingux will reboot automatically. To enable IPU is the same story.
Enjoy it!
-
Might be a noobish question, but what do i have to do to switch off the Dingoo, after i installed this image (the 4bit one btw ^^ )? :D
edit: Nevermind, found it myself, had to add this to dmenu:
MenuItem Poweroff
{
Icon = "res/system/reboot.png"
Name = " Poweroff"
Executable = "poweroff"
WorkDir = "/"
}
note to myself: first seek, then ask ;D
-
Might be a noobish question, but what do i have to do to switch off the Dingoo, after i installed this image (the 4bit one btw ^^ )? :D
edit: Nevermind, found it myself, had to add this to dmenu:
MenuItem Poweroff
{
Icon = "res/system/reboot.png"
Name = " Poweroff"
Executable = "poweroff"
WorkDir = "/"
}
Note to myself: first seek, then ask ;D
Humm, I didn't add anything to my dmanu, and now the power-off switch works, You just have to hold it a while, and it re-boots to native, from which you can turn off then.
I guess adding THIS would give you a place to where you wouldn't even need the switch, you'd just have a menu option??
Do I have that right?
-
Actually, after downloading the right zImage and adding that piece of code to dmenu, you have a Power Off button in Dmenu that actually works! I.e.: It switches off the Dingoo, just like a Linux PC, very nice! :D
The Reboot button should be in Dmenu already, under System, if you use toddlers local pack.
-
I dunno which one I do use...mine is local 0.1.0 whichever one that is.
I'll look for it.
Anyway, I got an idea how to go about this, now...one way or another.
EDIT: Yeah, I got it right.
Nice. Now power-off is an actual menu item.
<-----wonders if the old "re-boot" command, which she replaced...would have re-booted into native, or Dingux. If a re-boot into native, from Dingux...may re-add the re-boot command, so I have a choice to power-off or re-boot into native.
Be nice if there's a re-boot in native, as well...so that one could then choose to power-off...or boot into Dingux...from native.
-
Reboot is reboot. You reboot the hole dingoo and you can press select during boot again to boot dingux or leave it and boot the native firmware.
I have both menu items. One with a red button for shutdown and a yellow one for reboot.
-
Reboot is reboot. You reboot the hole dingoo and you can press select during boot again to boot dingux or leave it and boot the native firmware.
I have both menu items. One with a red button for shutdown and a yellow one for reboot.
Nice.
Could you post your .png file for the Yellow button?
I'd like to set mine up the same way.
-
Reboot:
(http://codiak.net/dingoo/reboot.png)
Shutdown:
(http://codiak.net/dingoo/shutdown.png)
My config looks like this:
MenuItem Reboot
{
Icon = "res/system/reboot.png"
Name = " Reboot"
Executable = "reboot"
WorkDir = "/"
}
MenuItem Poweroff
{
Icon = "res/system/shutdown.png"
Name = " Shutdown"
Executable = "poweroff"
WorkDir = "/"
}
-
You have definitely helped, and I most certainly gave you karma. Thanks!
-
Nice feature, works like a charm :D
-
I also release the modified zImage in which the MMC interface mode is set to 4-bit.
(Faster R/W speed, but more probabilities to corrupt your SD card. In fact, it works well in my dingoo so I'm using this one. Freaks only!! )
Is there an application or method to test for SD corruption when using this kernel?
-
If your dingux wont boot, then the fs is corrupt :)
-
Thanks vimrc! Great job, I will try the "freaks only" zImage :D
-
If your dingux wont boot, then the fs is corrupt :)
FS = File System??
Seriously...sorry to ask such a noobish question, but I honestly do not know what you mean by "fs"
-
Yes, I think so.
@QBert:If you are using Linux like me, you can always do a fsck for eleminate inconsistencies on the sd. (man fsck should do)
-
Tried both IPU and non-IPU version and they both did not work, Dingoo just freezes in the Dingux screen of dualboot.
LCD MODULE: LCM_FAIR_ILI9331_3
Only Booboo compilation from August works on my Dingoo, the newer one does not work either.
-
Tried both IPU and non-IPU version and they both did not work, Dingoo just freezes in the Dingux screen of dualboot.
LCD MODULE: LCM_FAIR_ILI9331_3
Only Booboo compilation from August works on my Dingoo, the newer one does not work either.
I have the exact same problem. I tried both as well. I have no idea why it's working for everyone else.
Update: I just replaced the the zImage file that wasn't working with the Dingux release 20091022 version that I previously had and that isn't working either now! It is just showing the Dingux.com splashscreen and freezes. Does anyone know what I should do?
ANOTHER Update: I just formatted my SD card. While I was backing up the local directory I found about 30 corrupted files! I don't know how this happened. Anyway, after formatting I copied my backup local minus the corrupted files and Dingux is alive and well again!
-
@QBert:If you are using Linux like me, you can always do a fsck for eleminate inconsistencies on the sd. (man fsck should do)
Good advice. Thanks schanall.
A user on the official Dingux site (Gh0ce_>0) mentioned he's been using a kernel with 32K block size and hasn't experienced any corruption. Are there any pre-compiled 32K kernels available? I'd like to see if this fixes the hiccups with larger cached games on FBA320 (eg: Marvel vs Capcom).
-
Heh... I wasn't using a precompiled kernel with a 32K block size, I formatted my SDHC card with a 32K block size. To do this from windows (sorry if this is too basic of instructions for some, but since I work in the IT industry, I have met a lot of people who prefer if you can spell it out as simple as possible):
1) click on start
2) click on run
3) type in "cmd" and click ok
4) In the command prompt window that comes up type in "format X: /FS:fat32 /A:32K" (replacing the X with the drive letter of your SD card)
You will now have a completely empty SD card with a 32K block size. I did that over 3 weeks ago, have played games (emu, ports, and linux), listened to music, everything I can think of to push it to corrupt and no sign of corruption yet. Thinking that maybe that dingux has problems writing multiple blocks (from a file system perspecitve) at a time. 32K block size on an SD card results in more wastage of space with small files, but it seems to beat the corruption problem.
gonna try the 4-bit writing and see how that handles on mine now (with poweroff... woot poweroff).
-
Heh... I wasn't using a precompiled kernel with a 32K block size, I formatted my SDHC card with a 32K block size.
Thanks for the clarification, and the formatting instructions. I'm pretty sure the block size can also be selected when using the XP/Vista "Format" utility. I've always used 32K blocks myself, and haven't experienced any corruption issues to my knowledge.
-
With the card I had, I wasn't given the option for 32K block size unless I went through command prompt. Windows only offered "Default" (4K). Using Vista SP2 I am able to select 64K block size instead of 32K. XP told me the card wasn't compatible with 64K block size. Testing 64K block size now with the various zImages listed in this thread. So far, backed up my dingux partition and tried tossing the zImage on and it failed to load. I noticed this problem every time I went to change the zImage/rootfs I needed to format the SD card. I am wondering if maybe dingux writes something to the start of the card when it is first run or something? or do the rootfs and zImage have to be the first files on the disk? If the latter is the case, that would explain why I always had issues updating to the new zImage (and probably solve the issues that others are having), but it doesn't explain why when I put the "working" zImage back on (without formatting) the dingux boots properly.
May need to grab a copy of the dingux source and read through the whole thing (large project that i don't currently have time for, but be good for in the future).
crossing my fingers...
Thanks for the new zImage and thanks for all the info that everyone posts... it keeps me motivated to keep poking at some projects (and testing).
The Gh0ce_>0
-
bah... 64K block size limits the disk to be a 2 GB disk... so sticking with the 32K block size. I testing the 4-bit with poweroff zImage and it worked great. Had it running mp3's for an extended period of time (over 8 hours) and no problems with corruption. 32K block size seems to fix the corruption issue (based on my testing). If anyone has a method to force corruption, I would like to experiment with it. I remembered reading something somewhere about copying a large file and doing an MD5 hash on it showed that the file was corrupt, but I am not a linux expert and was hoping I could just copy->paste the sample code (or put it into a shell script) to test it.
Thanks
The Gh0ce_>0
EDIT: sorry about not editing the previous post (and thus doubleposting... that was my bad). But I tried again with the 4-bit one and am getting corruption for sure. Going back to the 1-bit with poweroff and going to do more testing. Sucks that the corruption is still occuring... wonder what exactly is causing it and why it seems to occur a lot more often with lower block sizes?
The Gh0ce_>0
-
But I tried again with the 4-bit one and am getting corruption for sure. Going back to the 1-bit with poweroff and going to do more testing. Sucks that the corruption is still occuring... wonder what exactly is causing it and why it seems to occur a lot more often with lower block sizes?
Until the problem is solved (if it can be solved), I'd personally like to see a kernel with 4-bit reads and 1-bit writes (since I assume there's no corruption when reading).
Booboo's already said this wouldn't be straightforward, however. :(
-
But I tried again with the 4-bit one and am getting corruption for sure. Going back to the 1-bit with poweroff and going to do more testing. Sucks that the corruption is still occuring... wonder what exactly is causing it and why it seems to occur a lot more often with lower block sizes?
Until the problem is solved (if it can be solved), I'd personally like to see a kernel with 4-bit reads and 1-bit writes (since I assume there's no corruption when reading).
Booboo's already said this wouldn't be straightforward, however. :(
That would be nice, but apparently the 1-bit writes doesn't make the problem go away, just makes it less likely to happen. It still can (and does in some cases) occur. I would like to do more testing, but I have no method of forcing the corruption. I am thinking using dd and an md5 check (or something similar) would work... I just have to get my linux to work properly (backtrack in a VM doesn't like some things... but I'm getting it going).
more testing and results to come... in a few days... probably a week... maybe longer...
The Gh0ce_>0
-
Hey vimrc I tried to do insert the options of switching between IPU enabled and IPU disabled zImages. I followed your instructions but I can't get it to run. This is what it says when I try to use the IPU enable function from a IPU disabled zImage:
cp: cannot stat './zImage': no such file or directory
Any idea why this is showing? I followed your instructions with the scripts and all already. In fact, I opened the scripts and tried to change it from /boot/cp to /boot/local to see if it help. Instead, it shows some access denied thing.
Please help! :(
-
If anyone has a method to force corruption, I would like to experiment with it.
Booboo suggested this method to test card corruption:
#!/bin/sh
cd /boot
dd if=/dev/urandom bs=1M count=100 | tee test1.bin | md5sum
md5sum test1.bin
cp test1.bin test2.bin
md5sum test2.bin
You can copy it into a shell script (i.e. corruption.sh) the launch it from the shell (Look for "telnet access" if you don't know how). Report us results! Thanks!
-
Let me have a look. :D
-
Dingoo with new LCD 9338 was released , can you update a zImage-enabled-poweroff for it?
Thank you.
-
There's any zImage-enabled-poweroff for LCD 9938 available at this moment??
-
OpenDingux :P
-
Yeah I know, I'm already using opendingux on another sd card but I'm waiting the third installment to make the total migration to OD (Impressive work btw). So there's no turn-off for dingux legacy with the new screen, good to know that.
Anyway, thanks Ayla.
-
Well maybe there is one, as I don't own one of these dingoos I didn't try it myself.