48 -> 504
96 -> 528
192 -> 624
312 -> 744
408 -> 840
504 -> 936
600 -> 1032
696 -> 1128I set both min and max to 1512000 and the box was on 1200MHz for 18 hours without any overheating or hickups or restarts.... and it seems more responsive...
Yeah it definitely is more responsive.
I couldn't find anything in cat /dev/nand_env related to clk, in fact it started at b for me with batfull=
Trying to dump the mtd partitions now, did you use nanddump/nandwrite from here:
http://xdaforums.com/showthread.php?t=1247908
Or are there newer versions of the binary I should be using that you could direct me to? :good:
My system only came with nandread in /system/bin/.
QU▲▀batfull_threshold=98 batlow_threshold=10 baudrate=115200 bootargs=root=/dev/
cardblksd2 rw rootfstype=ext3 rootwait init=/init console=ttyS0,115200n8 nohlt v
malloc=256m mem=1024m logo=osd1,0x84100000,720p bootcmd=run nandboot bootdelay=1
bootfile=boot.img chipname=8726m6 console=ttyS2,115200n8 cvbscheck=setenv outpu
ttemp ${outputmode};if test ${outputmode} = 480i; then if test ${cvbsenable} = t
rue; then setenv outputtemp 480cvbs;fi;fi; if test ${outputmode} = 576i; then if
test ${cvbsenable} = true; then setenv outputtemp 576cvbs;fi;fi cvbsenable=fals
e display_bpp=24 display_color_bg=0 display_color_fg=0xffff display_color_format
_index=24 display_height=480 display_layer=osd1 display_width=720 ethaddr=c4:4e:
ac:00:e2:47 fb_addr=0x84900000 gatewayip=10.18.9.1 hostname=arm_m6 ipaddr=10.18.
9.97 loadaddr=0x82000000 loadaddr_misc=0x83000000 machid=4e27 mmcargs=setenv boo
targs console=${console} boardname=m6_mbx nandargs=run cvbscheck;nand read aml_l
ogo 0x84100000 0 400000;setenv bootargs root=/dev/cardblksd2 rw rootfstype=ext3
rootwait init=/init console=ttyS0,115200n8 mac=${ethaddr} logo=osd1,0x84100000,$
{outputtemp},full androidboot.resolution=${outputmode} nohlt vmalloc=256m mem=10
24m a9_clk_max=1512000000 nandboot=echo Booting from nand ...;run nandargs;nand
read boot ${loadaddr} 0 600000;hdcp prefetch nand;bootm;run recovery netmask=255
.255.255.0 outputmode=720p outputtemp=720p preboot=get_rebootmode; clear_rebootm
ode; echo reboot_mode=${reboot_mode}; if test ${reboot_mode} = usb_burning; then
tiny_usbtool 20000; fi; run upgrade_check; run updatekey_or_not; run switch_boo
tmode reboot_mode=charging recovery=echo enter recovery;run nandargs;if mmcinfo;
then if fatload mmc 0 ${loadaddr} recovery.img; then bootm;fi;fi; nand read rec
overy ${loadaddr} 0 600000; bootm serverip=10.18.9.113 sleep_threshold=20 switch
_bootmode=if test ${reboot_mode} = factory_reset; then run recovery;else if test
${reboot_mode} = update; then run recovery;fi;fi testaddr=0x82400000 update=if
mmcinfo; then if fatload mmc 0 ${loadaddr} aml_autoscript; then autoscr ${loadad
dr}; fi;fi;run recovery updatekey_or_not=saradc open 4;if saradc get_in_range 0x
0 0x50 ;then msleep 500;if saradc get_in_range 0x0 0x50; then run update; fi; fi
upgrade_check=if itest ${upgrade_step} == 1; then defenv_without reboot_mode;se
tenv upgrade_step 2; save; fi upgrade_step=2 usbnet_devaddr=00:15:18:01:81:31usb
net_hostddr=00:15:18:01:a1:3bcdc_connect_timeout=9999999999 usbtty=cdc_acm video
_dev=tvout cvbsmode=480cvbs has.accelerometer=0p^⌠τ
batfull_threshold=98
batlow_threshold=10
baudrate=115200
bootargs=root=/dev/cardblksd2 rw rootfstype=ext3 rootwait init=/init console=ttyS0,115200n8 nohlt vmalloc=256m mem=1024m logo=osd1,0x84100000,720p
bootcmd=run nandboot
bootdelay=1
bootfile=boot.img
chipname=8726m6
console=ttyS2,115200n8
cvbscheck=
setenv outputtemp ${outputmode};
if test ${outputmode} = 480i; then
if test ${cvbsenable} = true; then
setenv outputtemp 480cvbs;
fi;
fi;
if test ${outputmode} = 576i; then
if test ${cvbsenable} = true; then
setenv outputtemp 576cvbs;
fi;
fi
cvbsenable=false
display_bpp=24
display_color_bg=0
display_color_fg=0xffff
display_color_format_index=24
display_height=480
display_layer=osd1
display_width=720
ethaddr=c4:4e:ac:02:45:67
fb_addr=0x84900000
gatewayip=10.18.9.1
hostname=arm_m6
ipaddr=10.18.9.97
loadaddr=0x82000000
loadaddr_misc=0x83000000
machid=4e27
mmcargs=setenv bootargs console=${console} boardname=m6_mbx
nandargs=
run cvbscheck;
nand read aml_logo 0x84100000 0 400000;
setenv bootargs root=/dev/cardblksd2 rw rootfstype=ext3 rootwait init=/init console=ttyS0,115200n8 mac=${ethaddr} logo=osd1,0x84100000,${outputtemp},full androidboot.resolution=${outputmode} nohlt vmalloc=256m mem=1024m a9_clk_max=1512000000 nandboot=echo Booting from nand ...;
run nandargs;
nandread boot ${loadaddr} 0 600000;
hdcp prefetch nand;
bootm;
run recovery
netmask=255.255.255.0
outputmode=576p
outputtemp=720p
preboot=
get_rebootmode;
clear_rebootmode;
echo reboot_mode=${reboot_mode};
if test ${reboot_mode} = usb_burning; then
tiny_usbtool 20000;
fi;
run upgrade_check;
run updatekey_or_not;
run switch_bootmode
reboot_mode=charging
recovery=echo enter recovery;
run nandargs;
if mmcinfo; then
if fatload mmc 0 ${loadaddr} recovery.img; then
bootm;
fi;
fi;
nand read recovery ${loadaddr} 0 600000;
bootm serverip=10.18.9.113
sleep_threshold=20
switch_bootmode=
if test ${reboot_mode} = factory_reset; then
run recovery;
else
if test ${reboot_mode} = update; then
run recovery;
fi;
fi
testaddr=0x82400000
update=
if mmcinfo; then
if fatload mmc 0 ${loadaddr} aml_autoscript; then
autoscr ${loadaddr};
fi;
fi;
run recovery
updatekey_or_not=
saradc open 4;
if saradc get_in_range 0x0 0x50; then
msleep 500;
if saradc get_in_range 0x0 0x50; then
run update;
fi;
fi
upgrade_check=
if itest ${upgrade_step} == 1; then
defenv_without reboot_mode;
setenv upgrade_step 2;
save;
fi
upgrade_step=2
usbnet_devaddr=00:15:18:01:81:31usbnet_hostddr=00:15:18:01:a1:3bcdc_connect_timeout=9999999999
usbtty=cdc_acm
video_dev=tvout cvbsmode=480cvbs has.accelerometer=0 digitaudiooutput=PCM 576poutputx=36 576poutputy=34 576poutputwidth=628 576poutputheight=514Just going through the .rc files and noticed references to these:
/sys/class/mali_freq/max 333000
/sys/class/freq_limit/limit 0
My guess is freq_limit is what allows it to not use the proper scaling_available_frequencies
And if we can modify the mali max freq...
Edit: Was just reading some docs, and apparently the MALI 400 has a normal max of 500. Setting it directly in the shell didn't affect it. I'll try it on boot.
Edit: No effect on boot either.. Maybe it's just the userspace output of the kernel set max. If that's the case then a recompile would be required to alter it.
Have you ever had to nandwrite those nanddump backups? I tried it with just nandwrite and it threw up a warning recommending -p to pad the images to pagesize. So then I did nandwrite -p and it wouldn't boot. Restoring with your sdcard image now.
Examined the original dumped kernel image and my repacked one and padded it out appropriately, going to try again.
My only worry is that the last padded portion is all FF, and that ubootenv is ALL "blank" FF hex data where I expected it to contain variables we could hack, making me think it's a placeholder for something else, like the OOB info. So I'm worried that we're in a bit of a catch-22: If we dump the OOB then we can't edit the ramdisk; if we don't dump the OOB then the device won't boot after the image is rewritten.
Dumping with nanddump definitely worked well, though I didn't use -b since I wanted an exact copy. Anyway, if you know a method to write the images correctly again then I can definitely do ramdisk mods on this thing.
Edit: Hmm even won't work when nandwriting the original boot.img back.. Maybe if I try to dd it back.. Bad news is all my backups are likely useless and I'll have to set it up from scratch.
Edit 2: dd was also a failed experiment. Not sure how to write things back now. Any help here would be appreciated.
This doesn't grab a correct kernel image:
dd if=/dev/block/mtdblock5 of=/sdcard/mtd5-boot.img;
These definitely grab the kernel since the sha1sums match and I can unpack it afterwards perfectly:
nanddump -f /sdcard/mtd5-boot.img /dev/mtd/mtd5;
dd if=/dev/mtd/mtd5 of=/sdcard/mtd5-boot.img
But the opposite doesn't seem to result in a device that boots at all:
nandwrite /dev/mtd/mtd5 /sdcard/mtd5-boot.img; #or whatever, I did it correctly at the time.
dd if=/sdcard/md5-boot.img of=/dev/mtd/mtd5;
And this just goes black after the bootlogo:
dd if=/sdcard/md5-boot.img of=/dev/block/mtdblock5;
Edit: Apparently that FF stuff I noticed before is just how nand handles empty pages:
http://stackoverflow.com/questions/11279473/how-to-correctly-nandwrite-a-nanddumped-dump-with-oob
Luckily your restore sdcard still worked in all these circumstances. Pretty frustrating though.. if I can write the kernel back in a working fashion then I can mod the ramdisk. Any ideas?
/block/mtdblock can't work because it does not exist on this reference board.
cd mtd
root@android:/dev/mtd # ls
mtd0
mtd0ro
mtd1
mtd1ro
mtd2
mtd2ro
mtd3
mtd3ro
mtd4
mtd4ro
mtd5
mtd5ro
mtd6
mtd6ro
mtd7
mtd7ro
mtd8
mtd8ro
mtd9
mtd9ro
Maybe the writing can be done in uboot only? By sf command?
http://forum.androidgadget.co.uk/showthread.php?tid=174&pid=964#pid964
And connecting the UART to this box is not so hard, all you need are these test hooks for about 1.6 dollars:
EBAY TEST HOOK
And this excellent UART connector for around 2.6 dollars
EBAY UART
Here are instructions and UART layout.
And picture of my connection with these test hooks:
@BenniBenassi
I decided I'd at least figure out the why of it not working after nandwrite, so I redumped after writing. The differences are pretty obvious:
00000000-00003FF0 (0-16384) Blanked with FF
Correct data...
00008000-0000BFF0 (32768-49152) Blank with FF
Correct data...
00010000-00013FF0 (65536-81920) Blank with FF
Every second 16384 sized block of data is blank.
I wonder if another nandwrite would handle it better? Going to try that one from the other thread. I've also got this vague hope that commandline options could resolve it if we could figure it out.
The good news is that you can nanddump with -b or without and you still get the same image sha1sum, so there aren't any bad blocks to worry about (at least on my device).
#!/system/bin/sh
# chmod -R 755 /system/etc/init.d
# osm0sis @ xda-developers
# move the dalvik-cache to /cache to save space on /data
busybox rm -f /data/dalvik-cache/*;
busybox mkdir /cache/dalvik-cache;
busybox chown system:system /cache/dalvik-cache;
busybox chmod 771 /cache /cache/dalvik-cache;
busybox mount -o bind /cache/dalvik-cache /data/dalvik-cache;The first one is my favorite
Doing a bit of testing, then I'll upload my modded boot.img which will also include all the MTD-Utils in /sbin/. :good:Ah. No idea. Go for it.
