Same applied to me :highfive:
Like I said, HD 8.9" is being developed for.
Just to clear this up.
I do not have Kindle Fire HD 7" and so I cannot try.
We've got a volunteer to try this at irc and bootloader unlock works the same way (as expected, but you need a different bootloader binary).
We were not able to get anything to show up on the screen after booting CM10, thought it appears the OS boots and behaves fine, backlight is on too.
Anyway, I'd much rather prefer people to buy Nexus 7, it costs the same as Kindle Fire HD 7, but is a much more open device with much more developer support.
If you need CM10 and further, get Nexus 7 and you'll be soo much more happier. You still can run kindle app on it to read your books if you so desire.
With this out of the way, let's not touch on the 7" device topic here anymore, it's for 8.9" development discussion only. Thank you for your understanding.
Nexus 10 if you want a larger device.
Sent from my Galaxy Nexus using xda app-developers app
Can someone help a dummy like me understand how this exploit works? Whats special about the 4kB of 0x00507c80 in the middle of the system partition? And what does the 3 at 4104 of the boot partition do? Once CWM is loaded, does that eliminate the need for modifying the system/boot partition, or does something in verygreens device tree/local_manifest take care of adding the necessary code for every build?
0x807c5000 is the address where our replacement bootloader is loaded.
Boot partition is used by amazon uboot to get various properties like serial number of device, wifi mac and what partition to boot from.
1 is normal boot, 3 - recovery, 2 - diagnostic kernel (don't boot it if you don't know what you are doing), 5 and 6 are boot from USB.
the need to load uboot address is never disappearing, but updater-script in the install zip takes care of that.
Repetitions of the addresses is because we don't really know exact location of the return address, and yes, that's part of the fix for the bug fattire have identified.Thanks verygreen! Couple of add-on questions: Why do you need such a long string repeating the memory address? Is that the part that exploits the bug that fattire found in the stock uboot? 0x807c5000 would be 2GB into storage, wouldn't that be in the userdata partition? Does the updater-script in the install zip also take care of making sure that the custom uboot gets put at the correct address?
Repetitions of the addresses is because we don't really know exact location of the return address, and yes, that's part of the fix for the bug fattire have identified.
Regarding offsets, I think your math is off, it's just a dozen megabytes into /system.
The updated boot.img is already generated to contain uboot at the correct address, so the only job left for the installer script is to write it in place.
Repetitions of the addresses is because we don't really know exact location of the return address, and yes, that's part of the fix for the bug fattire have identified.
Regarding offsets, I think your math is off, it's just a dozen megabytes into /system.
The updated boot.img is already generated to contain uboot at the correct address, so the only job left for the installer script is to write it in place.
Sure, download the source and submit patches?
Yes.verygreen, can we use this for kindle 8.9?
http://omappedia.org/wiki/4AJ.1.1_OMAP4_Jelly_Bean_Release_Notes
Last I heard he got KFHD8.9 a few days ago. I imagine he's not planning to use it as a bookreaderMaybe Hashcode could help us out as I know he has a lot of experience with TI hw.
Last I heard he got KFHD8.9 a few days ago. I imagine he's not planning to use it as a bookreader
Last I heard he got KFHD8.9 a few days ago. I imagine he's not planning to use it as a bookreader
mkdir android/system
cd android/system
curl https://dl-ssl.google.com/dl/googlesource/git-repo/repo > ~/repo
chmod a+x ~/repo
repo init -u git://github.com/CyanogenMod/android.git -b jellybean
wget -O .repo/local_manifest.xml https://github.com/verygreen/android_manifests/raw/master/bowser-jb/local_manifest.xml
repo sync -j16
. build/envsetup.sh
lunch cm_bowser-userdebug
. vendor/cm/get-prebuilts
mka bacon
adb shell su -c "chmod 777 /dev/block/*"
adb pull /dev/block/mmcblk0p9
adb pull /dev/block/mmcblk0p10
adb pull /dev/block/mmcblk0p11
[code]
Save these block images.
Step 2: Prepare and run CWM:
[code]
rm -f /tmp/stack; for i in $(seq 1024) ; do echo -ne '\x00\x50\x7c\x80' >>/tmp/stack ; done
adb push /tmp/stack /data/local/tmp/
adb shell su -c "dd if=/data/local/tmp/stack of=/dev/block/platform/omap/omap_hsmmc.1/by-name/boot bs=6519488 seek=1"
adb shell su -c "chmod 777 /cache"
adb push /path/to/cm-10-XXXXXXXX-UNOFFICIAL-bowser.zip /cache/
adb shell su -c "echo 0 > /sys/block/mmcblk0boot0/force_ro"
adb shell su -c "echo -n 3 | dd of=/dev/block/mmcblk0boot0 bs=1 count=1 seek=4104"
fastboot flash recovery /path/to/recovery.img -i 0x1949
fastboot reboot -i 0x1949
adb shell "mount /data"
adb shell "rm -r /data/*"
fastboot flash recovery /path/to/mmcblk0p9 -i 0x1949
fastboot flash boot /path/to/mmcblk0p10 -i 0x1949
fastboot flash system /path/to/mmcblk0p11 -i 0x1949 # This one will take a few minutes
fastboot reboot -i 0x1949
Not to be a bother, but has any more progress been made? I realize that these sorts of things take time, but even the slightest news of progress would be nice.