Author Topic: zImage with power-off function enabled  (Read 23482 times)

fbreve

  • Guest
Re: zImage with power-off function enabled
« Reply #15 on: November 06, 2009, 04:55:16 pm »
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.

Jolu42

  • Guest
Re: zImage with power-off function enabled
« Reply #16 on: November 07, 2009, 05:22:32 pm »
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!
« Last Edit: November 07, 2009, 08:05:55 pm by Jolu42 »

QBert

  • Guest
Re: zImage with power-off function enabled
« Reply #17 on: November 07, 2009, 07:11:40 pm »
@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).

bmg002

Re: zImage with power-off function enabled
« Reply #18 on: November 07, 2009, 08:33:37 pm »
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).

QBert

  • Guest
Re: zImage with power-off function enabled
« Reply #19 on: November 07, 2009, 08:52:29 pm »
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.

bmg002

Re: zImage with power-off function enabled
« Reply #20 on: November 07, 2009, 10:21:36 pm »
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

bmg002

Re: zImage with power-off function enabled
« Reply #21 on: November 08, 2009, 06:40:00 pm »
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
« Last Edit: November 09, 2009, 02:12:09 am by bmg002 »

QBert

  • Guest
Re: zImage with power-off function enabled
« Reply #22 on: November 10, 2009, 12:42:10 am »
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. :(

bmg002

Re: zImage with power-off function enabled
« Reply #23 on: November 12, 2009, 04:00:17 am »
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

apkapkapk

  • Guest
Re: zImage with power-off function enabled
« Reply #24 on: December 17, 2009, 09:53:49 am »
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! :(

batman52

Re: zImage with power-off function enabled
« Reply #25 on: December 17, 2009, 10:42:22 am »
If anyone has a method to force corruption, I would like to experiment with it.

Booboo suggested this method to test card corruption:

Code: [Select]
#!/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!

Renata12

  • Guest
Re: zImage with power-off function enabled
« Reply #26 on: April 07, 2010, 10:06:06 am »
Let me have a look. :D

lilarcor

Re: zImage with power-off function enabled
« Reply #27 on: June 07, 2011, 10:10:53 am »
Dingoo with new LCD 9338 was released , can you update a zImage-enabled-poweroff for it?

Thank you.

CREATICA

Re: zImage with power-off function enabled
« Reply #28 on: December 09, 2011, 08:32:15 pm »
There's any zImage-enabled-poweroff for LCD 9938 available at this moment??

pcercuei

  • ***
  • Posts: 1395
    • GitHub
Re: zImage with power-off function enabled
« Reply #29 on: December 09, 2011, 10:46:47 pm »
OpenDingux  :P

 

Post a new topic
Post a new topic