All the technical details you'd like - G1 Android Development

Here's the thread for tech details. No questions in this thread, please.
My input:
Rooting the Rogers Dream
Download the tools required
Extract to anywhere on your computer.
Place update.zip on the root of your sd card.
Reboot the device into SPL (power off, hold camera button, boot, press "back" or "send" [check prompt on device] to enter "FASTBOOT" instead of "HBOOT")
Code:
fastboot boot recovery.img
Apply update, wait until phone idles, press HOME+BACK, it will reboot, finish writing hboot, then reboot again into recovery by itself. Do not interrupt it at all until it's done.
HOME+BACK to reboot into regular device.
Power off, hold camera, boot, go back into FASTBOOT
Code:
fastboot flash recovery recovery.img
Code:
fastboot flash boot boot.img
Code:
fastboot reboot
that's it!
Rooting the HTC Magic / Sapphire: http://android-dls.com/wiki/index.php?title=Magic_Rooting
Developer notes (for devs and rom builders):
Dev's (cyanogen, i'm looking at you [you requested this info ]) you can download my hacked up mkbootimg and some other tools here: http://www.mediafire.com/?njl4x5ozldm
these are all baked up by me in a flurry of rush and etc, so excuse the sloppiness
You will have 2 tools to use now, compileboot and compilebootmagic.
compileboot creates a regular g1 boot img (and the vodafone magic as well supports these old boot locations)
compilebootmagic has 2 options.
compilebootmagic -1 will create an image supported by the HTC Dream (rogers), all new magic devices, and most likely the hero and etc (these new locations are based on ram size pretty much)
compilebootmagic -2 will create an image with user supplied arguments (it says dream but disregard it, i made it before finding out the new codes matched -1)
Discovering new boot locations!
This is a fun (and easy) bit.
Just grab a boot.img from the device you'd like to learn about, and follow the chart below:
Code:
0xf-0xc (backwards): kernel addr
0x17-0x14 (backwards): ramdisk addr
0x1f-0x1c (backwards): second addr
0x23-0x20 (backwards): tags addr
you can also use this script (linux users):
Code:
#!/usr/bin/php
<?php
function bootloc($file) {
$handle = fopen($file, 'rb');
$data = stream_get_contents($handle);
fclose($handle);
$text = "";
for($a = 0; $a < 8; $a++) {
$text .= $data[$a];
}
if($text == "ANDROID!") {
$out = sprintf("Kernel addr : 0x%02x%02x%02x%02x", ord($data[hexdec('f')]), ord($data[hexdec('e')]), ord($data[hexdec('d')]), ord($data[hexdec('c')]))."\n";
$out .= sprintf("Ramdisk addr: 0x%02x%02x%02x%02x", ord($data[hexdec('17')]), ord($data[hexdec('16')]), ord($data[hexdec('15')]), ord($data[hexdec('14')]))."\n";
$out .= sprintf("Second addr : 0x%02x%02x%02x%02x", ord($data[hexdec('1f')]), ord($data[hexdec('1e')]), ord($data[hexdec('1d')]), ord($data[hexdec('1c')]))."\n";
$out .= sprintf("tags addr : 0x%02x%02x%02x%02x", ord($data[hexdec('23')]), ord($data[hexdec('22')]), ord($data[hexdec('21')]), ord($data[hexdec('20')]))."\n";
return $out;
} else {
return false;
}
}
if($argc < 2) {
echo "Usage:\n";
echo $argv[0]." <img file/s>\n";
echo "example:\n";
echo $argv[0]." boot.img boot-new.img recovery.img recovery-new.img\n";
} else {
for($a = 1; $a < $argc; $a++) {
$out = bootloc($argv[$a]);
if($out) {
echo $argv[$a],":\n";
echo $out;
} else {
echo $argv[$a]," is not a boot/recovery img!\n";
}
}
}
usage: bootlocations.php <boot.img, more than one can be supplied>
example: bootlocations.php boot.img boot-new.img
NOTE: i will try to keep adding to this until it's full. any information that isn't in here, feel free to request via pm.

Reserved for future postings

Once again, great work Haykuro

Okay, I see the trickery now.
Thanks for this info, I'll build a version of CM for Rogers later

Another thing.. Does this device use the same libhtc_ril.so as the G1 ROM and/or does it need different RIL properties in build.prop? I am thinking it does because of the different radio, but I've only seen G1 "ports" of the ROM.

cyanogen said:
Another thing.. Does this device use the same libhtc_ril.so as the G1 ROM and/or does it need different RIL properties in build.prop? I am thinking it does because of the different radio, but I've only seen G1 "ports" of the ROM.
Click to expand...
Click to collapse
lol the g1 ports of the rom never changed the lib much (if not at all [do an md5sum ;P])
the phone is practically identical to ours, aside some physical things (crystals, etc)

thx for the tools
cheers

Thanks again Haykuro! This is great information.

thank you for this! Hopefully intructions on how to root the mytouch will come soon!

Tried to make a version of CM-3.6 for the Rogers Dream and it isn't booting according to the testers.. Doesn't even get adbd started.
I set the boot.img up properly.
Code:
Kernel addr : 0x19208000
Ramdisk addr: 0x1a200000
Second addr : 0x1a100000
tags addr : 0x19200100
Something else has to be different, or that device hates my kernel.
EDIT:
Haykuro sent me the kernel config from a running Dream device, and there are some options enabled in it that aren't part of any Linux kernel.
CONFIG_MSM_AMSS_SUPPORT_256MB_EBI1=y
CONFIG_CPU_FREQ_GOV_MSM7K=y
So we are going to need whatever they patched in to be able to build custom kernels. Interestingly, the device is also using cpufreq settings of 384MHz/528MHz by default.

Great job haykuro, but ive been hearing reports that you cannot flash any rom (only rogers based roms) Any news on this? Thanks again!

I commend your turn around, Steve, and am quite impressed.

cyanogen said:
EDIT:
Haykuro sent me the kernel config from a running Dream device, and there are some options enabled in it that aren't part of any Linux kernel.
CONFIG_MSM_AMSS_SUPPORT_256MB_EBI1=y
CONFIG_CPU_FREQ_GOV_MSM7K=y
So we are going to need whatever they patched in to be able to build custom kernels. Interestingly, the device is also using cpufreq settings of 384MHz/528MHz by default.
Click to expand...
Click to collapse
That is my stumbling block too. It's not just those two options, config diff is quite significant. I've sent a couple of emails to htc kernel devs a few weeks ago, but got no response. HTC must release the patched source, though, to comply with GPL2. I'm not sure what's be the best way to persuade them to.

Can't ender code in SPL
Once I boot into SPL how do I enter the code. nothing happens when I press the keys on my keyboard.

stongest said:
Once I boot into SPL how do I enter the code. nothing happens when I press the keys on my keyboard.
Click to expand...
Click to collapse
Wow this was pretty dead and you just revived it from its slumber among the dead.
Theres no code to enter
You have to install once you get a custom rec.

Ace42 said:
Wow this was pretty dead and you just revived it from its slumber among the dead.
Theres no code to enter
You have to install once you get a custom rec.
Click to expand...
Click to collapse
At least he searched for it

stongest said:
Once I boot into SPL how do I enter the code. nothing happens when I press the keys on my keyboard.
Click to expand...
Click to collapse
through adb

ok.. I am getting closer to understanding this!
But, still no luck.
I downloaded this file
http://sapphire-port-dream.googlecode.com/files/spl-signed.zip
then saved it to my SD card and renamed it to update.zip
Then I do this
Reboot the device into SPL (power off, hold camera button, boot, press "back" or "send" [check prompt on device] to enter "FASTBOOT" instead of "HBOOT")
and nothing happens.. any ideas?

You install .zip things like that, like the SPL and new roms in the recovery mode, not bootloader. You'll start up with home + power to get to that.
However, given that you don't know this yet, I'd spend a *lot* more time getting comfortable with the whole flashing roms/messing with your phone stuff before installing that SPL, that's a pretty good way to brick your phone if you don't know a bit more about what you're doing.

Sorry for necro posting, i'm new to the whole rooting thing. My phone info is:
Firmware: 1.5
Baseband Version: 62.59S.20.23U_3.22.26.17
Kernel Version: 2.6.27-d5acf552
Build Number: 1.89.631.1 146733 CL#94714
I have a rogers HTC dream for Canada.
What files do i exactly need, and once acquiring them I just follow the instructions in the first post?

Related

Need help to recompe kernel for the Nordic HTC Magic to support netfilter/iptables

Hi all!
As many of you might already know we have gotten a HTC Magic here in Scandinavia without support for netfilter and iptables. I've been trying to recompile a new version of the kernel on my x86_64 Archlinux box while adding these lines to the .config which I exported from my rooted phone:
Code:
CONFIG_NETFILTER=y
CONFIG_IP_NF_IPTABLES=y
CONFIG_IP_NF_MATCH_STATE=y
CONFIG_IP_NF_FILTER=y
CONFIG_IP_NF_TARGET_REJECT=Y
I am a n00b when it comes to compiling, booting and flashing Android stuff and not really a git wizard either. I've downloaded the source, cross-compiled it with my new .config and tried booting it with fastboot only to stare at the HTC logo for 15 minutes before giving up. I suspect that I have probably failed doing the right thing at more than one step in the process but have troubles finding a full guide for Android kernel hacking and loading on the web. I am not even sure if I really compiled the 2.6.27 version used in the daldroid build I have on the phone instead of the latest version in git.
I will provide the step-by-step details below.
1. Downloading and installing the CodeSourcery Cross-compiler from
HTML:
http://www.codesourcery.com/sgpp/lite/arm/portal/release858
2. Downloading setting up the android source code:
Code:
git clone git://android.git.kernel.org/kernel/msm.git
git checkout --track -b msm_htc origin/android-msm-2.6.27
git checkout -f
(here I noticed that the checkouts did not seem to download any extra code, is that expected?)
3. Setting up the cross compilation in the Makefile.
Code:
CROSS_COMPILE=../arm-2009q1/bin/arm-none-linux-gnueabi-
4. Using my .config when running make like this:
Code:
make zImage ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabi-
(a few additional options not present in the .config-file need to be manually specified before the build starts)
5. Extracting the ramdisk from the nordic daldroid boot.img:
Code:
split_bootimg.pl boot.img
5. Trying the new kernel with the daldroid ramdisk:
Code:
fastboot boot arch/arm/boot/zImage ../../boot.img-ramdisk.daldroid.gz
creating boot image...
creating boot image - 1634304 bytes
downloading 'boot.img'... OKAY
booting... OKAY
6. Fail
I would really appreciate some help to get this going. How can I confirm that 2.6.27 was really used? What other gotchas I have forgotten about?
CONFIG_MACH_SAPPHIRE=y
ridli said:
CONFIG_MACH_SAPPHIRE=y
Click to expand...
Click to collapse
Hmm, unfortunately this option is already set to true.
Perhaps it is mainly a fastboot problem. I dunno.
maybe but why you dont try to make a boot.img and flash it?
did you set the system type to msm? it is important.
copy here your .config, maybe we can try to see if something is wrong or you can do this.
Code:
make ARCH=arm CROSS_COMPILE=../arm-2009q1/bin/arm-none-linux-gnueabi- msm_defconfig
for do a default msm .config.
For what I've seen, you're not making a kernel+ramdisk image, but loading them both splitted. Maybe you're missing the command line parametters?
Also, you can patch the kernel code to make it light up one of the leds so you can know if at least the kernel is actually booting or is getting stucked somewhere. To make this, you can patch, on board-sapphire.c, the init function:
Code:
static void __init sapphire_init(void)
{
int rc;
printk("sapphire_init() revision = 0x%X\n", system_rev);
/*
* Setup common MSM GPIOS
*/
config_gpios();
msm_hw_reset_hook = sapphire_reset;
msm_acpu_clock_init(&sapphire_clock_data);
/* adjust GPIOs based on bootloader request */
printk("sapphire_init: cpld_usb_hw2_sw = %d\n", cpld_usb_h2w_sw);
gpio_set_value(SAPPHIRE_GPIO_USB_H2W_SW, cpld_usb_h2w_sw);
[] INSERT HERE:
gpio_set_value(SAPPHIRE_CPLD_LED_BASE+XX, 1);
Where XX is the led number you want to enable.
Any progresses ?
shwan_3 said:
Any progresses ?
Click to expand...
Click to collapse
Not yet, but the posts above are encouraging. I'll post my .config below.
My .config
I stripped all the '#' commented lines from the file to have it go below the 1000 lines limit.
Code:
CONFIG_ARM=y
CONFIG_SYS_SUPPORTS_APM_EMULATION=y
CONFIG_GENERIC_GPIO=y
CONFIG_GENERIC_TIME=y
CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_MMU=y
CONFIG_GENERIC_HARDIRQS=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_HAVE_LATENCYTOP_SUPPORT=y
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_TRACE_IRQFLAGS_SUPPORT=y
CONFIG_HARDIRQS_SW_RESEND=y
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_RWSEM_GENERIC_SPINLOCK=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_ARCH_SUPPORTS_AOUT=y
CONFIG_ZONE_DMA=y
CONFIG_GENERIC_HARDIRQS_NO__DO_IRQ=y
CONFIG_OPROFILE_ARMV6=y
CONFIG_OPROFILE_ARM11_CORE=y
CONFIG_VECTORS_BASE=0xffff0000
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
CONFIG_EXPERIMENTAL=y
CONFIG_BROKEN_ON_SMP=y
CONFIG_LOCK_KERNEL=y
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_LOCALVERSION=""
CONFIG_LOCALVERSION_AUTO=y
CONFIG_SWAP=y
CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y
CONFIG_LOG_BUF_SHIFT=17
CONFIG_BLK_DEV_INITRD=y
CONFIG_INITRAMFS_SOURCE=""
CONFIG_CC_OPTIMIZE_FOR_SIZE=y
CONFIG_SYSCTL=y
CONFIG_PANIC_TIMEOUT=5
CONFIG_EMBEDDED=y
CONFIG_UID16=y
CONFIG_KALLSYMS=y
CONFIG_HOTPLUG=y
CONFIG_PRINTK=y
CONFIG_BUG=y
CONFIG_COMPAT_BRK=y
CONFIG_BASE_FULL=y
CONFIG_FUTEX=y
CONFIG_ANON_INODES=y
CONFIG_EPOLL=y
CONFIG_SIGNALFD=y
CONFIG_TIMERFD=y
CONFIG_EVENTFD=y
CONFIG_SHMEM=y
CONFIG_ASHMEM=y
CONFIG_VM_EVENT_COUNTERS=y
CONFIG_SLAB=y
CONFIG_PROFILING=y
CONFIG_OPROFILE=y
CONFIG_HAVE_OPROFILE=y
CONFIG_HAVE_KPROBES=y
CONFIG_HAVE_KRETPROBES=y
CONFIG_PROC_PAGE_MONITOR=y
CONFIG_HAVE_GENERIC_DMA_COHERENT=y
CONFIG_SLABINFO=y
CONFIG_RT_MUTEXES=y
CONFIG_BASE_SMALL=0
CONFIG_MODULES=y
CONFIG_MODULE_UNLOAD=y
CONFIG_MODULE_FORCE_UNLOAD=y
CONFIG_KMOD=y
CONFIG_BLOCK=y
CONFIG_IOSCHED_NOOP=y
CONFIG_IOSCHED_AS=y
CONFIG_DEFAULT_AS=y
CONFIG_DEFAULT_IOSCHED="anticipatory"
CONFIG_CLASSIC_RCU=y
CONFIG_ARCH_MSM7XXX=y
CONFIG_ARCH_MSM7201A=y
CONFIG_MACH_TROUT=y
CONFIG_MACH_SAPPHIRE=y
CONFIG_HTC_BATTCHG=y
CONFIG_HTC_PWRSINK=y
CONFIG_MSM_AMSS_VERSION=6225
CONFIG_MSM_AMSS_VERSION_6225=y
CONFIG_MSM_AMSS_SUPPORT_256MB_EBI1=y
CONFIG_MSM_DEBUG_UART_NONE=y
CONFIG_MSM7XXX_USE_GP_TIMER=y
CONFIG_MSM7XXX_SLEEP_MODE_POWER_COLLAPSE_SUSPEND=y
CONFIG_MSM7XXX_SLEEP_MODE=0
CONFIG_MSM7XXX_IDLE_SLEEP_MODE_POWER_COLLAPSE=y
CONFIG_MSM7XXX_IDLE_SLEEP_MODE=1
CONFIG_MSM7XXX_IDLE_SLEEP_MIN_TIME=20000000
CONFIG_MSM7XXX_IDLE_SPIN_TIME=80000
CONFIG_MSM_IDLE_STATS=y
CONFIG_MSM_IDLE_STATS_FIRST_BUCKET=62500
CONFIG_MSM_IDLE_STATS_BUCKET_SHIFT=2
CONFIG_MSM_IDLE_STATS_BUCKET_COUNT=10
CONFIG_MSM_FIQ_SUPPORT=y
CONFIG_MSM_SERIAL_DEBUGGER=y
CONFIG_MSM_SMD=y
CONFIG_MSM_ONCRPCROUTER=y
CONFIG_MSM_RPCSERVERS=y
CONFIG_MSM_CPU_FREQ=y
CONFIG_MSM_CPU_FREQ_MSM7K=y
CONFIG_MSM_CPU_FREQ_SCALING_MAX=528000
CONFIG_MSM_CPU_FREQ_SCALING_MIN=384000
CONFIG_MSM_HW3D=y
CONFIG_MSM_ADSP=y
CONFIG_HTC_HEADSET=y
CONFIG_HTC_ACOUSTIC=y
CONFIG_WIFI_CONTROL_FUNC=y
CONFIG_WIFI_MEM_PREALLOC=y
CONFIG_CPU_32=y
CONFIG_CPU_V6=y
CONFIG_CPU_32v6=y
CONFIG_CPU_ABRT_EV6=y
CONFIG_CPU_PABRT_NOIFAR=y
CONFIG_CPU_CACHE_V6=y
CONFIG_CPU_CACHE_VIPT=y
CONFIG_CPU_COPY_V6=y
CONFIG_CPU_TLB_V6=y
CONFIG_CPU_HAS_ASID=y
CONFIG_CPU_CP15=y
CONFIG_CPU_CP15_MMU=y
CONFIG_ARM_THUMB=y
CONFIG_TICK_ONESHOT=y
CONFIG_NO_HZ=y
CONFIG_HIGH_RES_TIMERS=y
CONFIG_GENERIC_CLOCKEVENTS_BUILD=y
CONFIG_PREEMPT=y
CONFIG_HZ=100
CONFIG_AEABI=y
CONFIG_ARCH_FLATMEM_HAS_HOLES=y
CONFIG_SELECT_MEMORY_MODEL=y
CONFIG_FLATMEM_MANUAL=y
CONFIG_FLATMEM=y
CONFIG_FLAT_NODE_MEM_MAP=y
CONFIG_PAGEFLAGS_EXTENDED=y
CONFIG_SPLIT_PTLOCK_CPUS=4
CONFIG_RESOURCES_64BIT=y
CONFIG_ZONE_DMA_FLAG=1
CONFIG_BOUNCE=y
CONFIG_VIRT_TO_BUS=y
CONFIG_ALIGNMENT_TRAP=y
CONFIG_ZBOOT_ROM_TEXT=0x0
CONFIG_ZBOOT_ROM_BSS=0x0
CONFIG_CMDLINE="mem=64M console=ttyMSM,115200n8"
CONFIG_CPU_FREQ=y
CONFIG_CPU_FREQ_TABLE=y
CONFIG_CPU_FREQ_DEFAULT_GOV_MSM7K=y
CONFIG_CPU_FREQ_GOV_PERFORMANCE=y
CONFIG_CPU_FREQ_GOV_USERSPACE=y
CONFIG_CPU_FREQ_GOV_ONDEMAND=y
CONFIG_CPU_FREQ_GOV_MSM7K=y
CONFIG_BINFMT_ELF=y
CONFIG_PM=y
CONFIG_PM_SLEEP=y
CONFIG_SUSPEND=y
CONFIG_SUSPEND_FREEZER=y
CONFIG_HAS_WAKELOCK=y
CONFIG_HAS_EARLYSUSPEND=y
CONFIG_WAKELOCK=y
CONFIG_WAKELOCK_STAT=y
CONFIG_USER_WAKELOCK=y
CONFIG_EARLYSUSPEND=y
CONFIG_FB_EARLYSUSPEND=y
CONFIG_ARCH_SUSPEND_POSSIBLE=y
CONFIG_NET=y
CONFIG_PACKET=y
CONFIG_NETFILTER=y
CONFIG_IP_NF_IPTABLES=y
CONFIG_IP_NF_MATCH_STATE=y
CONFIG_IP_NF_FILTER=y
CONFIG_UNIX=y
CONFIG_INET=y
CONFIG_IP_ADVANCED_ROUTER=y
CONFIG_ASK_IP_FIB_HASH=y
CONFIG_IP_FIB_HASH=y
CONFIG_IP_MULTIPLE_TABLES=y
CONFIG_IP_ROUTE_VERBOSE=y
CONFIG_TCP_CONG_CUBIC=y
CONFIG_DEFAULT_TCP_CONG="cubic"
CONFIG_ANDROID_PARANOID_NETWORK=y
CONFIG_BT=y
CONFIG_BT_L2CAP=y
CONFIG_BT_SCO=y
CONFIG_BT_RFCOMM=y
CONFIG_BT_RFCOMM_TTY=y
CONFIG_BT_BNEP=y
CONFIG_BT_HIDP=y
CONFIG_BT_HCIUART=y
CONFIG_BT_HCIUART_H4=y
CONFIG_BT_HCIUART_LL=y
CONFIG_FIB_RULES=y
CONFIG_RFKILL=y
CONFIG_RFKILL_LEDS=y
CONFIG_UEVENT_HELPER_PATH=""
CONFIG_STANDALONE=y
CONFIG_PREVENT_FIRMWARE_BUILD=y
CONFIG_FW_LOADER=y
CONFIG_EXTRA_FIRMWARE=""
CONFIG_MTD=y
CONFIG_MTD_PARTITIONS=y
CONFIG_MTD_CMDLINE_PARTS=y
CONFIG_MTD_CHAR=y
CONFIG_MTD_BLKDEVS=y
CONFIG_MTD_BLOCK=y
CONFIG_MTD_MAP_BANK_WIDTH_1=y
CONFIG_MTD_MAP_BANK_WIDTH_2=y
CONFIG_MTD_MAP_BANK_WIDTH_4=y
CONFIG_MTD_CFI_I1=y
CONFIG_MTD_CFI_I2=y
CONFIG_MTD_MSM_NAND=y
CONFIG_BLK_DEV=y
CONFIG_MISC_DEVICES=y
CONFIG_ANDROID_PMEM=y
CONFIG_TIMED_OUTPUT=y
CONFIG_TIMED_GPIO=y
CONFIG_BINDER_IPC=y
CONFIG_KERNEL_DEBUGGER_CORE=y
CONFIG_LOW_MEMORY_KILLER=y
CONFIG_LOGGER=y
CONFIG_ANDROID_RAM_CONSOLE=y
CONFIG_ANDROID_RAM_CONSOLE_ENABLE_VERBOSE=y
CONFIG_ANDROID_RAM_CONSOLE_ERROR_CORRECTION=y
CONFIG_ANDROID_RAM_CONSOLE_ERROR_CORRECTION_DATA_SIZE=128
CONFIG_ANDROID_RAM_CONSOLE_ERROR_CORRECTION_ECC_SIZE=16
CONFIG_ANDROID_RAM_CONSOLE_ERROR_CORRECTION_SYMBOL_SIZE=8
CONFIG_ANDROID_RAM_CONSOLE_ERROR_CORRECTION_POLYNOMIAL=0x11d
CONFIG_HAVE_IDE=y
CONFIG_MD=y
CONFIG_BLK_DEV_DM=y
CONFIG_DM_DEBUG=y
CONFIG_DM_CRYPT=y
CONFIG_DM_UEVENT=y
CONFIG_NETDEVICES=y
CONFIG_DUMMY=y
CONFIG_NET_ETHERNET=y
CONFIG_MII=y
CONFIG_SMC91X=y
CONFIG_NETDEV_1000=y
CONFIG_NETDEV_10000=y
CONFIG_PPP=y
CONFIG_PPP_ASYNC=y
CONFIG_PPP_DEFLATE=y
CONFIG_PPP_BSDCOMP=y
CONFIG_SLHC=y
CONFIG_MSM_RMNET=y
CONFIG_INPUT=y
CONFIG_INPUT_EVDEV=y
CONFIG_INPUT_KEYRESET=y
CONFIG_INPUT_TOUCHSCREEN=y
CONFIG_TOUCHSCREEN_ELAN_I2C_8232=y
CONFIG_TOUCHSCREEN_SYNAPTICS_I2C_RMI=y
CONFIG_INPUT_MISC=y
CONFIG_INPUT_UINPUT=y
CONFIG_INPUT_GPIO=y
CONFIG_INPUT_KEYCHORD=y
CONFIG_SERIAL_CORE=y
CONFIG_SERIAL_MSM=y
CONFIG_SERIAL_MSM_CLOCK_CONTROL=y
CONFIG_SERIAL_MSM_RX_WAKEUP=y
CONFIG_SERIAL_MSM_HS=y
CONFIG_UNIX98_PTYS=y
CONFIG_I2C=y
CONFIG_I2C_BOARDINFO=y
CONFIG_I2C_HELPER_AUTO=y
CONFIG_I2C_MSM=y
CONFIG_SENSORS_AKM8976=y
CONFIG_SENSORS_PCA963X=y
CONFIG_SENSORS_MT9T013=y
CONFIG_SENSORS_MT9P012=y
CONFIG_POWER_SUPPLY=y
CONFIG_SSB_POSSIBLE=y
CONFIG_DAB=y
CONFIG_VIDEO_OUTPUT_CONTROL=y
CONFIG_FB=y
CONFIG_FB_CFB_FILLRECT=y
CONFIG_FB_CFB_COPYAREA=y
CONFIG_FB_CFB_IMAGEBLIT=y
CONFIG_FB_MSM=y
CONFIG_FB_MSM_LOGO=y
CONFIG_HID_SUPPORT=y
CONFIG_HID=y
CONFIG_USB_SUPPORT=y
CONFIG_USB_ARCH_HAS_HCD=y
CONFIG_USB_FUNCTION=y
CONFIG_USB_FUNCTION_MSM_HSUSB=y
CONFIG_USB_FUNCTION_ADB=y
CONFIG_USB_FUNCTION_MASS_STORAGE=y
CONFIG_MMC=y
CONFIG_MMC_UNSAFE_RESUME=y
CONFIG_MMC_EMBEDDED_SDIO=y
CONFIG_MMC_PARANOID_SD_INIT=y
CONFIG_MMC_BLOCK=y
CONFIG_MMC_BLOCK_PARANOID_RESUME=y
CONFIG_MMC_MSM7XXX=y
CONFIG_NEW_LEDS=y
CONFIG_LEDS_CLASS=y
CONFIG_LEDS_GPIO=y
CONFIG_LEDS_CPLD=y
CONFIG_LEDS_TRIGGERS=y
CONFIG_LEDS_TRIGGER_TIMER=y
CONFIG_LEDS_TRIGGER_HEARTBEAT=y
CONFIG_LEDS_TRIGGER_SLEEP=y
CONFIG_SWITCH=y
CONFIG_SWITCH_GPIO=y
CONFIG_RTC_LIB=y
CONFIG_RTC_CLASS=y
CONFIG_RTC_HCTOSYS=y
CONFIG_RTC_HCTOSYS_DEVICE="rtc0"
CONFIG_RTC_INTF_ALARM=y
CONFIG_RTC_DRV_MSM7XXX=y
CONFIG_EXT2_FS=y
CONFIG_EXT2_FS_XATTR=y
CONFIG_EXT2_FS_POSIX_ACL=y
CONFIG_EXT2_FS_SECURITY=y
CONFIG_EXT3_FS=y
CONFIG_EXT3_FS_XATTR=y
CONFIG_EXT3_FS_POSIX_ACL=y
CONFIG_EXT3_FS_SECURITY=y
CONFIG_JBD=y
CONFIG_FS_MBCACHE=y
CONFIG_FS_POSIX_ACL=y
CONFIG_INOTIFY=y
CONFIG_INOTIFY_USER=y
CONFIG_FAT_FS=y
CONFIG_VFAT_FS=y
CONFIG_FAT_DEFAULT_CODEPAGE=437
CONFIG_FAT_DEFAULT_IOCHARSET="iso8859-1"
CONFIG_PROC_FS=y
CONFIG_PROC_SYSCTL=y
CONFIG_SYSFS=y
CONFIG_TMPFS=y
CONFIG_YAFFS_FS=y
CONFIG_YAFFS_YAFFS1=y
CONFIG_YAFFS_YAFFS2=y
CONFIG_YAFFS_AUTO_YAFFS2=y
CONFIG_YAFFS_SHORT_NAMES_IN_RAM=y
CONFIG_NETWORK_FILESYSTEMS=y
CONFIG_MSDOS_PARTITION=y
CONFIG_NLS=y
CONFIG_NLS_DEFAULT="iso8859-1"
CONFIG_NLS_CODEPAGE_437=y
CONFIG_NLS_ISO8859_1=y
CONFIG_PRINTK_TIME=y
CONFIG_ENABLE_WARN_DEPRECATED=y
CONFIG_ENABLE_MUST_CHECK=y
CONFIG_FRAME_WARN=1024
CONFIG_MAGIC_SYSRQ=y
CONFIG_DEBUG_FS=y
CONFIG_DEBUG_KERNEL=y
CONFIG_DETECT_SOFTLOCKUP=y
CONFIG_BOOTPARAM_SOFTLOCKUP_PANIC_VALUE=0
CONFIG_SCHED_DEBUG=y
CONFIG_SCHEDSTATS=y
CONFIG_TIMER_STATS=y
CONFIG_DEBUG_PREEMPT=y
CONFIG_DEBUG_MUTEXES=y
CONFIG_DEBUG_SPINLOCK_SLEEP=y
CONFIG_DEBUG_INFO=y
CONFIG_DEBUG_VM=y
CONFIG_DEBUG_SG=y
CONFIG_FRAME_POINTER=y
CONFIG_HAVE_FTRACE=y
CONFIG_HAVE_DYNAMIC_FTRACE=y
CONFIG_HAVE_ARCH_KGDB=y
CONFIG_CRYPTO=y
CONFIG_CRYPTO_ALGAPI=y
CONFIG_CRYPTO_BLKCIPHER=y
CONFIG_CRYPTO_MANAGER=y
CONFIG_CRYPTO_CBC=y
CONFIG_CRYPTO_AES=y
CONFIG_CRYPTO_TWOFISH=y
CONFIG_CRYPTO_TWOFISH_COMMON=y
CONFIG_CRYPTO_HW=y
CONFIG_BITREVERSE=y
CONFIG_CRC_CCITT=y
CONFIG_CRC32=y
CONFIG_ZLIB_INFLATE=y
CONFIG_ZLIB_DEFLATE=y
CONFIG_REED_SOLOMON=y
CONFIG_REED_SOLOMON_ENC8=y
CONFIG_REED_SOLOMON_DEC8=y
CONFIG_PLIST=y
CONFIG_HAS_IOMEM=y
CONFIG_HAS_IOPORT=y
CONFIG_HAS_DMA=y
biktor_gj said:
For what I've seen, you're not making a kernel+ramdisk image, but loading them both splitted. Maybe you're missing the command line parametters?
Where XX is the led number you want to enable.
Click to expand...
Click to collapse
Yeah, that could be a problem. I was under the impression that fastboot built the boot.img itself before transfering the kernel to the phone.
Interesting test with the leds. I'll check it out if I don't solve this.
I'm working on the exact same thing. can you contact me via im? pm for my screen names
I think that HTC patched some things in that are not available in the source tree... So I doubt that you'll be able to get a kernel running build from source. If you do happen to make it run let us know
Amon_RA said:
I think that HTC patched some things in that are not available in the source tree... So I doubt that you'll be able to get a kernel running build from source. If you do happen to make it run let us know
Click to expand...
Click to collapse
I would not be suprised at all if that was the case. However, since the Linux kernel is GPL, such patches, as I understand it, also need to be under the GPL and made available upon request. Is there a public HTC source tree anywhere?
And btw, how can I fix the "recompile" misspelling in the title of this thread? It is driving me insane
This might be a very stupid question, but here it goes:
Shouldn't it be possible to build all the extra netfilter/iptables support for the vanilla 2.6.27 kernel as modules and insmod them when running HTC's kernel? Or will that result in swift and horrible death?
i don't see why it wouldn't. we wouldn't need the source for htc's kernel then, right? just figure out how to build the modules? isn't that kind of how proprietary video drivers work for linux?
EDIT: Modules will work, that is certain. A little googling confirmed that's how wlan and such work (on Android)
EDIT 2: It seems like there is .config for the kernel on the phone that can be used with the standard 2.6.27 kernel source to build the android kernel.
EDIT 3: found the kernel here http://github.com/zhoukejun/android-2.6.27-yf255/tree/master
sammypwns said:
i don't see why it wouldn't. we wouldn't need the source for htc's kernel then, right? just figure out how to build the modules? isn't that kind of how proprietary video drivers work for linux?
EDIT: Modules will work, that is certain. A little googling confirmed that's how wlan and such work (on Android)
EDIT 2: It seems like there is .config for the kernel on the phone that can be used with the standard 2.6.27 kernel source to build the android kernel.
EDIT 3: found the kernel here http://github.com/zhoukejun/android-2.6.27-yf255/tree/master
Click to expand...
Click to collapse
I wonder if access to the kernel can help with the Bluetooth problems in the Hero ROM?
Bump!
Is there any news about iptables on PVT 32A based sapphire?
gboddina said:
Bump!
Is there any news about iptables on PVT 32A based sapphire?
Click to expand...
Click to collapse
Well. The kernels that we successfully have built by cross-compiling refuse to boot. Looking at the config.gz that the phone exports and trying
Code:
make oldconfig
we have learnt that HTC has a lot of parameters specified for code that appears not to be in the standard android 2.6.27 kernel source tree. We would be very very happy if someone around here could point us to the repository holding HTC specific patches and code for the Magic/Sapphire.
Based on http://www.mail-archive.com/[email protected]/msg00442.html , it seems we need to find the source of the android-msm-htc-2.6.27 kernel.
Which don't seems to be public.
gboddina said:
Based on http://www.mail-archive.com/[email protected]/msg00442.html , it seems we need to find the source of the android-msm-htc-2.6.27 kernel.
Which don't seems to be public.
Click to expand...
Click to collapse
But it has to be made public if requested. That is essence of the GPL.
i emailed them a while ago. i also talked to someone who has gotten his own kernels to boot but on the dream dev phone

[JTAG] T-Mobile G1 w/ EBI1 radio (Trip to Rogers rom 1.89.631.1 and back to CM)

NOTE: full jtag instructions to unbrick or root devices can be found on the cyanogen mod wiki:
http://wiki.cyanogenmod.com/index.php/JTAG_DREAM_AND_MAGIC
----
Any G1 user disappointing believing they are unable to use the latest buggy 1.5 cupcake android release from rogers.. look no further.
With a 2005 series SPL all you need to do to successfully use this spectacular firmware on your phone is:
1) extract the rom.nbh form the windows installer;
2) enter fastboot mode on your phone and run "fastboot flash nbh rom.nbh"
This flashes the Official Rogers firmware on your phone in all its glory; including:
1) bad battery life
2) internet that drops periodically even in strong signal.
3) old version of android (1.5)
4) no apps2sd
http://twitpic.com/19p2wm - Home Screen
http://twitpic.com/19p355 - Rogers boot logo
http://twitpic.com/19p397 - About Screen
http://twitpic.com/19p3bm - SPL (close)
http://twitpic.com/19p3gk - SPL (again)
-----
So now you are asking ... why did I do this.. mostly because (as the wires show) The phone is already jtaged And I intend to use it to show how to remove the firmware via jtag. (hopefully tomorrows posting)
However its interesting to note the T-Moblie G1 *CAN* run the EBI1 radio 3.22.26.17 with related EBI1 port and SPL. (I do recommend that if you care to test EBI1 ports on a G1 ... make it a rooted rom not the rogers one)
----
Edit: Brick->Alive .. Rogers->custom a A phone's journey is posted..
While many technical details are provided this is *not* intended as a solution for all. as it requires some skill and equipment to utilize jtag. openocd is used for its relative cheapness and open source nature. Other products will likely work just as well but may need some minor process changes.
How to remove the post 911 firmware via jtag right?
(ROM version 1.89.631.1 Rogers)
Newbies please do not threadcrap this asking for unbrick for your G1 yet. As of right now this method is still not just for everyone.
Original JTAG thread for more info: http://forum.xda-developers.com/showthread.php?t=591048
xaueious said:
(ROM version 1.89.631.1 Rogers)
Click to expand...
Click to collapse
That is what the phone says it is on the about screen (not surprised I did flash the full nbh)
I was asking because you didn't mention which one you were talking about. There was also that old pre 911 nbh, ROM version 1.85.631.5 for Rogers. This rom worked with flashrec (one-click root).
I still know very little about JTAG but I thought I might as well post some of the SPL/radio combinations here with some links.
A link to the old Rogers ROM is here for future reference for any Rogers Dream users to return to a rootable stock image for some reason: http://forum.xda-developers.com/showthread.php?t=625073
Contains stock pre-911 update Rogers ROM with
HBOOT Version 1.33.0009
Radio Version 3.22.20.17
* * * Reference Recommended SPL + Radio Combinations * * *
Anyhow if everything works... Useful links for SPL, radio and recovery flashing:
Rogers Dream Info for Reference, no Rogers Waiver Signed
Upgrade to 3.22.26.17 if you haven't signed the waiver or don't want to. This makes your phone incompatible to most ROMs in this thread until you flash a 'kernel port' update file.
Needs Amon_RA G1/Dream recovery version R
So target would be:
HBOOT VERSION: 1.33.2005
RADIO VERSION: 3.22.26.17
Rogers Dream Info for Reference, Rogers Waiver Signed OR T-Mobile G1
This radio makes the phone work with most G1 ROMs you can find on these forums.
Needs Amon_RA non-R G1/Dream recovery or Cyanogen's G1/Dream recovery
HBOOT VERSION: 1.33.2005
RADIO VERSION: 2.22.23.02
* * * Download Links for Relevant Files * * *
Amon_RA Recovery for G1/Dream
http://forum.xda-developers.com/showthread.php?t=566669
Radio 2.22.23.02
T-Mobile G1 radio. EBI0 kernel. Makes the G1/Dream compatible with most ROMs posted in this forum.
http://forum.xda-developers.com/showpost.php?p=5763943&postcount=1
Radio 3.22.26.17
T-Mobile G1 radio. EBI1 kernel (aka Magic 32A old radio kernel). Makes the G1/Dream incompatible with most ROMs posted in this forum until you flash an additional kernel (kernel port). Allows for flashing of Magic old radio ROMs if ROM is not too large for the G1/Dream's internal flash memory.
http://wiki.cyanogenmod.com/index.php/Upgrade_Rogers_Dream_Radio#Preparations
SPL/HBOOT 1.33.2005
Also Danger/Death SPL. Originally for Sapphire/Magic but has support for Dream to increase size of /system partition. Prerequisite for some ROMs.
http://sapphire-port-dream.googlecode.com/files/spl-signed.zip
Or here:
http://wiki.cyanogenmod.com/index.php/Upgrade_Rogers_Dream_Radio#Preparations
xaueious said:
I was asking because you didn't mentioned which one you were talking about. There's also that old pre 911 nbh aka ROM 1.85.631.5 Rogers.
Now this ROM might be good for your procedure for Rogers Dream users. It's here by the way in case you didn't have a link: http://forum.xda-developers.com/showthread.php?t=625073
Click to expand...
Click to collapse
Yes, that should be just as good (and you will have a way to root without jtag just in case ). I believe that it is the exact same SPL and slightly different radio (might matter for jtag though). The only reason we were able to root this rom was because of the kernel exploit.
A phones Journey
So a short recap for those not following along in the various threads.
The T-Mobile Phone in question
I've recently (off ebay) got a bricked HTC T-Mobile G1. (failed attempt to install the 2005 SPL.. (**sidenote)
Given it was a cheap phone it was a good candidate for jtag testing; after shorting something out on previous jtag work on my rogers dream. (the jtag port is the same on both phones.. and it did work on the dream for a bunch of tests before the incident)
Details of the de-brick are on this thread​Rogers Rom
Given the phone already has jtag attached (a little bit of a painful process) I decided to try unrooting a rogers rom on it before going to any other phone. So I took the nbh from the rogers installer (I still have the original 1.89.631.1 rom.nbh from when I created the hacked version which skipped the spl/splash1 portions of the flash.)
This flashed from the 2005 SPL without incident making the T-Mobile phone running a full rogers stack (splash image included) see op post for images of the phone/rom in this mode.​Unroot (I know this is what you are here for)
(Note an updated version of this process now exists on a wiki: http://wiki.cyanogenmod.com/index.php/JTAG_DREAM_AND_MAGIC )
So now with a fully locked SPL in place and jtag already set up time to hack out of the rogers rom to an EBI1 port!!
Prerequisites:
A) phone running locked roger rom 1.89.631.1 (actually as listed it will work for any rom on radio 3.22.26.17 and with offsets in my de-brick post other radios.
B) Jtag adapter.. I'm using OLIMEX ARM-USB-OCD.. however others will work as well.. my steps assume the openocd program on your computer which supports many USB/ParPort adapters. (my current cfg hopefully will improve but works for this hack.. note its for version "Open On-Chip Debugger 0.4.0" not the old cvs/svn version that is on the CD with the hardware)
C) outfit phone with jtag adapter.. this i will leave to another topic.. see the Jtag thread for the test points.
D) A HTC Serial wire.. I recommend without the +5 power line since blue light mode is sometimes hard to enter while the device is charging.. (information on my wire with links to parts. If you wish you can also attatch a USB wire to the USB leads which allows you to see serial output while flashing.. but ensure you can have the USB unplugged while the oemspl serial is in use.
E) 2005 SPL *.img file extract it from the zip file: http://sapphire-port-dream.googlecode.com/files/spl-signed.zip
MD5 (hboot.img) = cdf75d34e24937da1a8a84bcd72496c3
F) Recovery *.img .. your favorite flavor of '-R' version from this thread: http://forum.xda-developers.com/showthread.php?t=566669
G) a sense of adventure
Procedure:
1) Ensure the jtag adapter is hooked up to the phone
2) power on phone into blue light mode
3) attach serial wire
4) connect to serial console (mtty in windows, "screen /dev/<serial device> 115200" in osx/linux)
5) start openocd or other jtag application (openocd -f dream.cfg)
6) start telnet to the ocd: "telnet localhost 4444"
7) run the following:
Code:
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
Open On-Chip Debugger
> [color=blue]halt[/color]
target state: halted
target halted in ARM state due to debug-request, current mode: Supervisor
cpsr: 0x200000d3 pc: 0x0090861c
MMU: disabled, D-Cache: disabled, I-Cache: disabled
> [color=blue]mww 0x0090379C 0xea000013[/color]
> [color=blue]mww 0x9029d8 0x0[/color]
> [color=blue]load_image [b]<pathto>[/b]/hboot.img 0x0[/color]
No working memory available. Specify -work-area-phys to target.
no working area available, falling back to memory writes
524288 bytes written at address 0x00000000
downloaded 524288 bytes in 11.635834s (44.002 kb/s)
> [color=blue]mww 0x00000c0c 0x98000C4C[/color]
> [color=blue]mww 0x00000c08 0x98000C4C[/color]
> [color=blue]mww 0x00000c04 0x98000C4C[/color]
> [color=blue]mww 0x00000c00 0x98000C4C[/color]
> [color=blue]resume[/color]
The offsets are based off my de-brick post
* 0x0090379C is the CID bypass point for 3.22.26.17
* 0x009029d8 is 4 less than the previously defined breakpoint for 3.22.26.17 SPL modification (for other radios subtract 4 from my breakpoint location);
This is the location of a subroutine call to load the SPL.. since we are going to load it our self we want to nop the instruction.. no 0x0 is not the nop instruction.. but it will achieve the same results (and lack their of).
* load_image will load a file into the phones ram; point this at the hboot.img you downloaded as that is what we want to run
* 0x00000c00 to 0x00000c0c is the switch jump table in the 2005 hboot image once loaded for the boot mode.. we are forcing modes 0-3 to ruu/fastboot mode.
* then we can resume the CPU and optionally kill openocd.
​8) into the serial termal run command "?" this ought to now output help on many commands (before it would only say invalid command)
9) run command "cego"
<phone will now boot into the ram image of 2005 SPL; display splash image (if screen is connected) and enter fastboot mode>
10) remove serial wire and attach USB wire.. or plug in usb part of USB/serial hybrid wire.
12) "fastboot flash hboot hboot.img"
13) "fastboot flash recovery recovery.img" (the ebi1 RA recovery)
14) "fastboot oem powerdown"
Now you can boot into recovery and flash your favorite EBI1 rom.. or if you don't like EBI1.. follow the EBI0 installation instructions​
** sidenote: To packagers and those making processes.. Given all I have seen to date.. whenever possible flash radios and SPLs via fastboot not recovory zip files..
If you are stuck on a splash screen on boot.. both the SPL and radio are working.. they are just usually stuck in an invalid mode.. which is less likely to happen if flashed by fastboot.. this particularly applies where the 2005 SPL is involved.
Hacking can be fun.. but this hacking is not cheap
If interested donations are accepted​
I wonder why no one's responding to this thread. This is great news!
I agree that this is good news. Just bought a slightly used Dream and it was. Just my luck that the previous owner ran the mandatory update shortly before selling it.
I am a little unsure about the process though. Does the jtag involve physically modifying the phone? If so, is there any chance that this method will lead to a non-jtag way of getting around the perfect SPL?
SilentTweak said:
I wonder why no one's responding to this thread.
Click to expand...
Click to collapse
Because most of newbies here doesn't have idea about what is talking ezterry with his method
I might be motivated to try this if I actually had a brick. If I buy a Dream I might look into this.
For now I am not motivated to get my own jtag working. ezterry and other fellow xdaers on the other thread seem to be trying to find a method that doesn't require soldering.
Dreaming
I would be willing to try this on the $100 Dream i picked up, but the only thing is spending another $50-$100 on JTAG and serial cable equipment. which i might F#@CK the phone LOL
PS is it possible to use a cheap parallel port jtag to do this?, i think diffrent software would be required for the process though....any suggestions?
Thanks
Raymar23
raymar23 said:
I would be willing to try this on the $100 Dream i picked up, but the only thing is spending another $50-$100 on JTAG and serial cable equipment. which i might F#@CK the phone LOL
PS is it possible to use a cheap parallel port jtag to do this?, i think diffrent software would be required for the process though....any suggestions?
Thanks
Raymar23
Click to expand...
Click to collapse
No reason a parport adapter won't work, and openocd supports many part port adapters.
Also if you are more comfortable with other arm compatable software it ought to be easy to port the steps.. its just ram writes.
I just don't own any computers I can plug in Part port devices anymore.
scholbert from the other jtag thread may be able to give more info.
http://www.diygadget.com/universal-jtag-adapter-for-routers-modem-fta-and-more.html
Could I use this JTAG adapter? Or is there another adapter on this site I can purchase to do this process? I'm thinking of buying a couple bricked phones and trying this out lol
SilentTweak said:
http://www.diygadget.com/universal-jtag-adapter-for-routers-modem-fta-and-more.html
Could I use this JTAG adapter? Or is there another adapter on this site I can purchase to do this process? I'm thinking of buying a couple bricked phones and trying this out lol
Click to expand...
Click to collapse
Looks like a 74HCT244....
I posted a link to a schematic for what is really the exact same thing -- should be in the other thread. It takes about 10 minutes to solder one of those up and you can make it for $2 in locally acquired parts.
Hey,
ezterry opened up another hacker thread...
Nice work mate
Anyway here's a schematic and some comments i once posted at the original JTAG on Dream thread.
http://forum.xda-developers.com/showpost.php?p=5110255&postcount=37
It's low cost LPT-adaptor and works very well with the MSM IO voltage of 2.6V.
Feel free to re-distribute
Maybe some soft tweaks are needed to integrate in openocd.
Once made a patch... but it's lost somewhere.
Cheers,
scholbert
Thanks
ezterry said:
No reason a parport adapter won't work, and openocd supports many part port adapters.
Also if you are more comfortable with other arm compatable software it ought to be easy to port the steps.. its just ram writes.
I just don't own any computers I can plug in Part port devices anymore.
scholbert from the other jtag thread may be able to give more info.
Click to expand...
Click to collapse
Thank you very much for the insights and also for all your work and knowledge that has been shared with the community.
BTW. Anyone know where to buy a parallel port JTAG in Canada (i hate customs) lol
Thanks again to everyone who posts in these forums
lbcoder said:
Looks like a 74HCT244....
I posted a link to a schematic for what is really the exact same thing -- should be in the other thread. It takes about 10 minutes to solder one of those up and you can make it for $2 in locally acquired parts.
Click to expand...
Click to collapse
I was searching that schematic without luck, can you please post the link here?
thanks!
kR105! said:
I was searching that schematic without luck, can you please post the link here?
Click to expand...
Click to collapse
Anyway here's a schematic and some comments i once posted at the original JTAG on Dream thread.
http://forum.xda-developers.com/show...5&postcount=37
Click to expand...
Click to collapse
If you want a true wiggler clone, this isn't...
I'll prepare another schematic...
Regards,
scholbert
ezterry said:
So a short recap for those not following along in the various threads.
The T-Mobile Phone in question
I've recently (off ebay) got a bricked HTC T-Mobile G1. (failed attempt to install the 2005 SPL.. (**sidenote)
Given it was a cheap phone it was a good candidate for jtag testing; after shorting something out on previous jtag work on my rogers dream. (the jtag port is the same on both phones.. and it did work on the dream for a bunch of tests before the incident)
Details of the de-brick are on this thread​Rogers Rom
Given the phone already has jtag attached (a little bit of a painful process) I decided to try unrooting a rogers rom on it before going to any other phone. So I took the nbh from the rogers installer (I still have the original 1.89.631.1 rom.nbh from when I created the hacked version which skipped the spl/splash1 portions of the flash.)
This flashed from the 2005 SPL without incident making the T-Mobile phone running a full rogers stack (splash image included) see op post for images of the phone/rom in this mode.​Unroot (I know this is what you are here for)
So now with a fully locked SPL in place and jtag already set up time to hack out of the rogers rom to an EBI1 port!!
Prerequisites:
A) phone running locked roger rom 1.89.631.1 (actually as listed it will work for any rom on radio 3.22.26.17 and with offsets in my de-brick post other radios.
B) Jtag adapter.. I'm using OLIMEX ARM-USB-OCD.. however others will work as well.. my steps assume the openocd program on your computer which supports many USB/ParPort adapters. (my current cfg hopefully will improve but works for this hack.. note its for version "Open On-Chip Debugger 0.4.0" not the old cvs/svn version that is on the CD with the hardware)
C) outfit phone with jtag adapter.. this i will leave to another topic.. see the Jtag thread for the test points.
D) A HTC Serial wire.. I recommend without the +5 power line since blue light mode is sometimes hard to enter while the device is charging.. (information on my wire with links to parts. If you wish you can also attatch a USB wire to the USB leads which allows you to see serial output while flashing.. but ensure you can have the USB unplugged while the oemspl serial is in use.
E) 2005 SPL *.img file extract it from the zip file: http://sapphire-port-dream.googlecode.com/files/spl-signed.zip
MD5 (hboot.img) = cdf75d34e24937da1a8a84bcd72496c3
F) Recovery *.img .. your favorite flavor of '-R' version from this thread: http://forum.xda-developers.com/showthread.php?t=566669
G) a sense of adventure
Procedure:
1) Ensure the jtag adapter is hooked up to the phone
2) power on phone into blue light mode
3) attach serial wire
4) connect to serial console (mtty in windows, "screen /dev/<serial device> 115200" in osx/linux)
5) start openocd or other jtag application (openocd -f dream.cfg)
6) start telnet to the ocd: "telnet localhost 4444"
7) run the following:
Code:
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
Open On-Chip Debugger
> [color=blue]halt[/color]
target state: halted
target halted in ARM state due to debug-request, current mode: Supervisor
cpsr: 0x200000d3 pc: 0x0090861c
MMU: disabled, D-Cache: disabled, I-Cache: disabled
> [color=blue]mww 0x0090379C 0xea000013[/color]
> [color=blue]mww 0x9029d8 0x0[/color]
> [color=blue]load_image [b]<pathto>[/b]/hboot.img 0x0[/color]
No working memory available. Specify -work-area-phys to target.
no working area available, falling back to memory writes
524288 bytes written at address 0x00000000
downloaded 524288 bytes in 11.635834s (44.002 kb/s)
> [color=blue]mww 0x00000c0c 0x98000C4C[/color]
> [color=blue]mww 0x00000c08 0x98000C4C[/color]
> [color=blue]mww 0x00000c04 0x98000C4C[/color]
> [color=blue]mww 0x00000c00 0x98000C4C[/color]
> [color=blue]resume[/color]
The offsets are based off my de-brick post
* 0x0090379C is the CID bypass point for 3.22.26.17
* 0x009029d8 is 4 less than the previously defined breakpoint for 3.22.26.17 SPL modification (for other radios subtract 4 from my breakpoint location);
This is the location of a subroutine call to load the SPL.. since we are going to load it our self we want to nop the instruction.. no 0x0 is not the nop instruction.. but it will achieve the same results (and lack their of).
* load_image will load a file into the phones ram; point this at the hboot.img you downloaded as that is what we want to run
* 0x00000c00 to 0x00000c0c is the switch jump table in the 2005 hboot image once loaded for the boot mode.. we are forcing modes 0-3 to ruu/fastboot mode.
* then we can resume the CPU and optionally kill openocd.
​8) into the serial termal run command "?" this ought to now output help on many commands (before it would only say invalid command)
9) run command "cego"
<phone will now boot into the ram image of 2005 SPL; display splash image (if screen is connected) and enter fastboot mode>
10) remove serial wire and attach USB wire.. or plug in usb part of USB/serial hybrid wire.
12) "fastboot flash hboot hboot.img"
13) "fastboot flash recovery recovery.img" (the ebi1 RA recovery)
14) "fastboot oem powerdown"
Now you can boot into recovery and flash your favorite EBI1 rom.. or if you don't like EBI1.. follow the EBI0 installation instructions​
** sidenote: To packagers and those making processes.. Given all I have seen to date.. whenever possible flash radios and SPLs via fastboot not recovory zip files..
If you are stuck on a splash screen on boot.. both the SPL and radio are working.. they are just usually stuck in an invalid mode.. which is less likely to happen if flashed by fastboot.. this particularly applies where the 2005 SPL is involved.
Hacking can be fun.. but this hacking is not cheap
If interested in giving a donation feel free to contact me​
Click to expand...
Click to collapse
how build device to reflash dead G1 ? electro scheme?
some buy exterry the solderless jtag adapter
mentioned in the other post
or he will end up with a huge collection of phones
I'll even chip in
my dream is fine and rooted but my magic was shipped the rogers ways
so I am waiting with great hopes for the jtagless option
and more than willing to help where I can

Kexec-hardboot patch

In this post, I would like to explain what kexec-hardboot patch is and also bring it to light a bit more since until now, it was only burried in MultiROM thread.
@kernel developers: I would like to ask you to merge this patch to your kernels, because it is essential part of MultiROM - it allows me to boot any kernel without changing the boot partition. I realize that it is no small request, but the patch is not big, touches relatively stable parts of kernel and should not cause any problems. Thank you.
What is kexec?
It is syscall of Linux kernel, which allows you to boot another Linux kernel without restarting the device - "Linux boots itself". The functionality is equivalent to fastboot -c *cmdline* boot zImage initrd.img, but without PC and fastboot. It is fairly known thing, so more info at wikipedia and man kexec.
Standard kexec call unfortunatelly does not work on Nexus 7. It freezes somewhere, and it is very difficult to find out where - probably some of the drivers are not shut down/re-initialized properly, it is a commong thing among Android devices, which is why kexec-hardboot was made.
What is the difference between normal and hardboot exec?
Kexec-hardboot patch adds a real device restart to that process, so that all the drivers can be properly reinitialized. It stores new kernel to RAM, reboots the device as usual, and kernel from boot partition immediately jumps to the one which was stored to RAM before reboot.
Another difference is that both kernels must be patched. The "host" kernel requires a full patch, the one which is being kexecd' requires only two small compatibility patches.
To sumarize the process:
kexec --load-hardboot.... is called and kernel it loaded into RAM.
kexec -e is called. Special info is written to memory (to area which is not overwritten on reboot) and the device is rebooted.
After reboot, very early in the boot process, kernel checks if that special info is present in RAM and if so, it loads new kernel from RAM and jumps to it.
Kexecd' kernel starts and boots.
For more info, read the original thread.
Patches:
Full kernel patch: https://gist.github.com/4558647, 4.1 kernel repo, cm 10.1 kernel repo
This is the full kernel patch. Kernels with this patch can be both "host" and "guest" kernels.
Related CONFIG options:
CONFIG_KEXEC=y
CONFIG_KEXEC_HARDBOOT=y
CONFIG_ATAGS_PROC=y
CONFIG_GROUPER_HARDBOOT_RECOVERY=n
First three options must be enabled. Last one, GROUPER_HARDBOOT_RECOVERY, specifies if the kexec call should reboot to normal mode or to recovery. This can be useful if you don't have the kernel in boot partition but only as kernel in recovery partition. You usualy want to disable this option.​
Compatibility patch: https://gist.github.com/4458581
This patch only makes the kernel bootable via kexec, ie. it can't be the host kernel. This was made for Ubuntu kernel (and it was accepted), because I did not want to drag the whole patch in there. If your kernel is for Android ROMs, you should use the full patch.​
Userspace kexec binary: View attachment kexec-tools.zip
That ZIP file contains kexec source, patches and README. It is from the original patch from Mike Kasick. It also contains precompiled, statically linked kexec binary, so you probably just want to use that.​
Usage:
Once you have the kernel patches and kexec userspace binary in place, just run following command to boot into new kernel:
Code:
kexec --load-hardboot zImage --initrd=initrd.img --mem-min=0x85000000 --command-line="$(cat /proc/cmdline)"
kexec -e
Note the command line parameter - cmdline from bootloader is not added automatically, you have to put it there by yourself.
Currently used by:
MultiROM - I use it to boot different kernels (eg. Ubuntu).
MOSLO - Part of Plasma Active for Nexus 7, also usefull tool for every N7 developer - read more: http://ruedigergad.com/2012/12/09/nexus-7-easily-flashaccess-entire-userdata-partition/
Authors:
This patch was made by Mike Kasick for Samsung Epic 4G. Since that, it was ported to several devices, one of them is Asus Transformer TF201 - I used patch from TF201 and modified it a bit (basically just changed few SoC specific constants). People at #ubuntu-arm helped me out with that, thanks.
Hi Tasssadar,
im trying to get this to work on the HOX in order to have a shot at multiboot,
the patched applied with no problem... however on compiling i gett this error
"Adress for kexec hardboot page not defined"
ask this error naturely defined to kick in with every device beside N7 i that comment completely....
and that ended up giving me an error about KEXEC_HB_PAGE_ADDR not defined,
so i readded it, but i removed the "#if defined(CONFIG_MACH_GROUPER)"
now trying to compile it, its gets pretty close to the end... but failed with unexpected string error at line OUTPUT_ARCH(arm) in file linux/arch/arm/boot/compressed/vmlinux.lds
Code:
/*
* linux/arch/arm/boot/compressed/vmlinux.lds.in
*
* Copyright (C) 2000 Russell King
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License version 2 as
* published by the Free Software Foundation.
*/
OUTPUT_ARCH(arm)
ENTRY(_start)
SECTIONS
{
/DISCARD/ : {
*(.ARM.exidx*)
*(.ARM.extab*)
/*
* Discard any r/w data - this produces a link error if we have any,
* which is required for PIC decompression. Local data generates
* GOTOFF relocations, which prevents it being relocated independently
* of the text/got segments.
*/
*(.data)
}
. = 0;
_text = .;
.text : {
_start = .;
*(.start)
*(.text)
*(.text.*)
*(.fixup)
*(.gnu.warning)
*(.glue_7t)
*(.glue_7)
}
.rodata : {
*(.rodata)
*(.rodata.*)
}
.piggydata : {
*(.piggydata)
}
. = ALIGN(4);
_etext = .;
.got.plt : { *(.got.plt) }
_got_start = .;
.got : { *(.got) }
_got_end = .;
_edata = .;
. = ALIGN(8);
__bss_start = .;
.bss : { *(.bss) }
_end = .;
. = ALIGN(8); /* the stack must be 64-bit aligned */
.stack : { *(.stack) }
.stab 0 : { *(.stab) }
.stabstr 0 : { *(.stabstr) }
.stab.excl 0 : { *(.stab.excl) }
.stab.exclstr 0 : { *(.stab.exclstr) }
.stab.index 0 : { *(.stab.index) }
.stab.indexstr 0 : { *(.stab.indexstr) }
.comment 0 : { *(.comment) }
}
also, im booted into windows now... so i can't provide the exact error.
I'm afraid "comment everything which doesn't work" won't work here. The KEXEC_HB_PAGE_ADDR and END_MEM is device-specific, it will most likely be different for HTC One X. You can find out what address is it supposed to be by examining /proc/iomem on your device. For example, here's memory map from grouper:
Code:
...
80000000-be9fffff : System RAM
80008000-808faba7 : Kernel text
80940000-80b8228f : Kernel data
beb00000-bebfffff : ram_console
...
So, for grouper, END_MEM is 0xbe9fffff + 1 = 0xbea00000.
KEXEC_HB_PAGE_ADDR is located 1MB before console RAM, which is in this case also immediatelly after System RAM, so for grouper, it is also 0xbea00000.
but failed with unexpected string error at line OUTPUT_ARCH(arm) in file linux/arch/arm/boot/compressed/vmlinux.lds
Click to expand...
Click to collapse
That doesn't seem to be related to this patch. Are you using correct cross-compiler?
Tasssadar said:
I'm afraid "comment everything which doesn't work" won't work here. The KEXEC_HB_PAGE_ADDR and END_MEM is device-specific, it will most likely be different for HTC One X.
Click to expand...
Click to collapse
i figured
but im walking you through what i did.
You can find out what address is it supposed to be by examining /proc/iomem on your device. For example, here's memory map from grouper:
Code:
...
80000000-be9fffff : System RAM
80008000-808faba7 : Kernel text
80940000-80b8228f : Kernel data
beb00000-bebfffff : ram_console
...
So, for grouper, END_MEM is 0xbe9fffff + 1 = 0xbea00000.
KEXEC_HB_PAGE_ADDR is located 1MB before console RAM, which is in this case also immediatelly after System RAM, so for grouper, it is also 0xbea00000.
Click to expand...
Click to collapse
Code:
7d000000-7d003fff : tegra-udc.0
7d000000-7d003fff : tegra-otg
7d000000-7d003fff : tegra-udc
7d004000-7d007fff : tegra-ehci.1
80000000-beafffff : System RAM
80008000-8094000f : Kernel text
809a8000-810b940f : Kernel data
beb00000-bebfffff : ram_console
bec00000-beffffff : fbmem
bf000000-bf7fffff : fbmem
0xbeafffff + 1 = 0xbeb00000
grrr that would put me inside the ram_console...
aaaa would it wok if i used the address before??
7d00800
Edit:
or did your ram RAM end earlier because you set you END_MEM 0xbea00000
in that case, it works out just the same with the HOX
That doesn't seem to be related to this patch. Are you using correct cross-compiler?
Click to expand...
Click to collapse
i would have guessed so, but the kernel compiled and is working before the patch.
im using the one provided by google (Android NDK r9) while it contains booth gcc 4.6/4.8 im using 4.6 (arm-linux-androideabi-)
The patch will move ram_console 1MB further, see https://gist.github.com/Tasssadar/4558647#file-n7_hardboot-diff-L387 . You'll have to modify this part of the patch, it will be in different file for your device.
Tasssadar said:
The patch will move ram_console 1MB further, see https://gist.github.com/Tasssadar/4558647#file-n7_hardboot-diff-L387 . You'll have to modify this part of the patch, it will be in different file for your device.
Click to expand...
Click to collapse
HOX is also a Tegra 3 device... so im guessing i wont need to touch a thing?
also note... that iomem provided is from an unpatched kernel (as i cant compile a patched one)
also,
im currently on freenode #htc-one-x
if you dont mind joining.
I've been looking through the kexec-hardboot patch these last few days, trying to actually understand it instead of just blindly porting it and after several hours of messing with assembler with no means to debug it, I've managed to remove the need for guest kernel to be patched. This is not really useful for grouper, since thanks to multirom and accepting kernel devs, nearly every third-party kernel has the proper patches. But, if I'll port multirom to some other device (hello, flo), it will be very useful
To know more see the changes in this commit, but you'll probably need to understand how the patch does things: https://github.com/Tasssadar/androi...mmit/2ce4130061f72430a8ddfde25346c4e528c5c30b
@mkasick: Could you please look over this? I'm afraid there's some good reason why you didn't do this in the first place, like rewriting some part of memory which shouldn't be rewritten or something like that. Thank you.
Tasssadar said:
I've been looking through the kexec-hardboot patch these last few days, trying to actually understand it instead of just blindly porting it and after several hours of messing with assembler with no means to debug it, I've managed to remove the need for guest kernel to be patched. This is not really useful for grouper, since thanks to multirom and accepting kernel devs, nearly every third-party kernel has the proper patches. But, if I'll port multirom to some other device (hello, flo), it will be very useful
To know more see the changes in this commit, but you'll probably need to understand how the patch does things: https://github.com/Tasssadar/androi...mmit/2ce4130061f72430a8ddfde25346c4e528c5c30b
@mkasick: Could you please look over this? I'm afraid there's some good reason why you didn't do this in the first place, like rewriting some part of memory which shouldn't be rewritten or something like that. Thank you.
Click to expand...
Click to collapse
Perfect timing, just finished my last exam
Edit:
Also, this applies on top of the original patch right??
Edit2:
i can't seem to get it to kexec boot, but i didn't do much testing, maybe 2morrow night!
Edit3:
fixed, it was a problem with min-addr,
changed it to 0x82000000 and it worked
One more question...
TEGRA_PMC_BASE is also device specific, ain't it???
So, for a Qualcomm device, what should I be using? I am guessing it is MSM_RPM_BASE, which I got from here: http://forum.xda-developers.com/showpost.php?p=31127486&postcount=7
Yes, it is SoC-specific. This is using some special register to reset the chip, I'm not sure if that is available on msm chips - probably yes, but in some different form. Your best chance is to examine restart sequence in arch/arm/mach-msm/restart.c and port it to assembler.
Tasssadar said:
Usage:
Once you have the kernel patches and kexec userspace binary in place, just run following command to boot into new kernel:
Code:
kexec --load-hardboot zImage --initrd=initrd.img --mem-min=0xA0000000 --command-line="$(cat /proc/cmdline)"
kexec -e
Click to expand...
Click to collapse
The address of 0xA0000000 is not necessarily the best choice going forward. It originally made perfect sense, as it is well above everything else. But now that we can boot unpatched guest kernels, we can hit the interesting situation where the guest decompression may take a full minute. At least it's when I've seen on the Ouya game console that's running the next chip after Grouper.
When I realized what's going on, I changed to 0x8E000000, as it gets me just below the 256 MB limit of cache-enabled memory that's present on a typical guest at that early decompression stage. It's enough to hold a typical 8 MB boot image kernel/ramdisk. Now the guest kernel startup is fast in all cases.
Thank you Tasssadar for continuing your work in this area, especially with finding that way to allow unpatched guests.
Indeed, that's actually what I'm using in MultiROM for flo and mako (and grouper, but it is useless 'cause not all 3rd-party kernels have been updated), I just kinda "forgot" to update these threads.
Would it work on devices with locked bootloaders (Xperias). I mean :does the idea of this patch would also work on bootloader unlock allowed :no devices?
Sent from my LT22i using xda app-developers app
I am trying to build a kexec patched kernel integrated into a ROM. I make sure that the following code is there in the defconfig:
CONFIG_KEXEC=y
CONFIG_KEXEC_HARDBOOT=y
CONFIG_ATAGS_PROC=y
The ROM works well, except that it does not boot my secondary ROMs - kexec hardboot patch missing. I have multi ROM and TWRP recovery installed
What am I missing?
Logs or it didn't happen.
Show me dmesg from normal boot into android, with MultiROM and your kernel installed.
Code:
adb shell
su
dmesg > /data/local/tmp/dmesg.txt
exit
exit
adb pull /data/local/tmp/dmesg.txt
Porting?
Tassadar which things do I need to boot kexec kernel on my device (Motorola Electrify 2) .
@Tasssadar, Sorry for picking up this kinda "old topic" but I'm sadly experiencing some problems while trying to port kexec-hardboot to the Sony Xperia Z2 (aka sirius). I applyed all needed commits (cherry-picked from a apparently working Z1 repo for stock kernel) to my CM based custom kernel (https://github.com/Myself5/android_kernel_sony_msm8974/tree/kexec-cm-12.0) and it does not boot at all. It's stuck on the Sony Logo, and it seems like I can't get any log either. I also tryed the stock cm kernel with the patch (https://github.com/Myself5/android_kernel_sony_msm8974-kexec) cause I tought it might be some incompatibility, but sadly it wasn't. Hope you have any ideas to solve my problems, cause I'm out of ideas ATM. I also checked the kexec commits for other devices (namely the One Plus One) and it seems like I got everything needed.
Thanks in Advance
Tasssadar said:
In this post, I would like to explain what kexec-hardboot patch is and also bring it to light a bit more since until now, it was only burried in MultiROM thread.
@kernel developers: I would like to ask you to merge this patch to your kernels, because it is essential part of MultiROM - it allows me to boot any kernel without changing the boot partition. I realize that it is no small request, but the patch is not big, touches relatively stable parts of kernel and should not cause any problems. Thank you.
What is kexec?
It is syscall of Linux kernel, which allows you to boot another Linux kernel without restarting the device - "Linux boots itself". The functionality is equivalent to fastboot -c *cmdline* boot zImage initrd.img, but without PC and fastboot. It is fairly known thing, so more info at wikipedia and man kexec.
Standard kexec call unfortunatelly does not work on Nexus 7. It freezes somewhere, and it is very difficult to find out where - probably some of the drivers are not shut down/re-initialized properly, it is a commong thing among Android devices, which is why kexec-hardboot was made.
What is the difference between normal and hardboot exec?
Kexec-hardboot patch adds a real device restart to that process, so that all the drivers can be properly reinitialized. It stores new kernel to RAM, reboots the device as usual, and kernel from boot partition immediately jumps to the one which was stored to RAM before reboot.
Another difference is that both kernels must be patched. The "host" kernel requires a full patch, the one which is being kexecd' requires only two small compatibility patches.
To sumarize the process:
kexec --load-hardboot.... is called and kernel it loaded into RAM.
kexec -e is called. Special info is written to memory (to area which is not overwritten on reboot) and the device is rebooted.
After reboot, very early in the boot process, kernel checks if that special info is present in RAM and if so, it loads new kernel from RAM and jumps to it.
Kexecd' kernel starts and boots.
For more info, read the original thread.
Patches:
Full kernel patch: https://gist.github.com/4558647, 4.1 kernel repo, cm 10.1 kernel repo
This is the full kernel patch. Kernels with this patch can be both "host" and "guest" kernels.
Related CONFIG options:
CONFIG_KEXEC=y
CONFIG_KEXEC_HARDBOOT=y
CONFIG_ATAGS_PROC=y
CONFIG_GROUPER_HARDBOOT_RECOVERY=n
First three options must be enabled. Last one, GROUPER_HARDBOOT_RECOVERY, specifies if the kexec call should reboot to normal mode or to recovery. This can be useful if you don't have the kernel in boot partition but only as kernel in recovery partition. You usualy want to disable this option.​
Compatibility patch: https://gist.github.com/4458581
This patch only makes the kernel bootable via kexec, ie. it can't be the host kernel. This was made for Ubuntu kernel (and it was accepted), because I did not want to drag the whole patch in there. If your kernel is for Android ROMs, you should use the full patch.​
Userspace kexec binary: View attachment 1653562
That ZIP file contains kexec source, patches and README. It is from the original patch from Mike Kasick. It also contains precompiled, statically linked kexec binary, so you probably just want to use that.​
Usage:
Once you have the kernel patches and kexec userspace binary in place, just run following command to boot into new kernel:
Code:
kexec --load-hardboot zImage --initrd=initrd.img --mem-min=0x85000000 --command-line="$(cat /proc/cmdline)"
kexec -e
Note the command line parameter - cmdline from bootloader is not added automatically, you have to put it there by yourself.
Currently used by:
MultiROM - I use it to boot different kernels (eg. Ubuntu).
MOSLO - Part of Plasma Active for Nexus 7, also usefull tool for every N7 developer - read more: http://ruedigergad.com/2012/12/09/nexus-7-easily-flashaccess-entire-userdata-partition/
Authors:
This patch was made by Mike Kasick for Samsung Epic 4G. Since that, it was ported to several devices, one of them is Asus Transformer TF201 - I used patch from TF201 and modified it a bit (basically just changed few SoC specific constants). People at #ubuntu-arm helped me out with that, thanks.
Click to expand...
Click to collapse
I'm sorry for picking up this older topic as well, but I always played with the thought of merging kexec support into a kernel and I'm doing one right now.. But my secondary device is a LG G2 and since the era of Lollipop began, somehow MultiBoot just stopped working and nobody can figure out why. I think they even started to build some new concept now.. So before I spark a heated debated by Note 4 users I'd love to know if you have any idea if this patch is still applicable? Altough the only way to find out is to probably just try it lol.
Tasssadar said:
In this post, ....
Click to expand...
Click to collapse
Bro can you please mention on your wiki that kexec isnt supported for x64 devices? It will be great help and save developers hours! I was porting for oneplus 2 when a dev told me that kexec isnt there for x64. I was shocked
Is any alternative available for that? Please reply! Thanks.
All other devs, who cant make multirom to work (lollipop is the x64 era) stop working. Kexec isnt supported for x64. Find an alternative for it.
Can Anyone help me to port this? Here is my patched kernel (ignore arch/arm64) and this is /proc/iomem.
Code:
80000000-854fffff : System RAM
80008000-80fa43ef : Kernel code
81112000-817bf797 : Kernel data
8cb00000-9fefffff : System RAM
9ff00000-9ff3ffff : persistent_ram
9ff40000-9ff7ffff : persistent_ram
9ff80000-9fffffff : persistent_ram
a0000000-ffffefff : System RAM
For kexec_hb_page_addr the value i inseted is 85500000 coz as tasssadar said 884fffff + 1 = 85500000, but I don't know what value add for
Code:
#elif defined(CONFIG_ARCH_MSM8916)
/* Restart using the PMIC chip, see mach-msm/restart.c */
ldr r0, =MSM8916_HARDBOOT
mov r1, #0
str r1, [r0, #0]
loop: b loop
MSM8916_HARDBOOT, and if I compile the kernel it stucks on samsung logo.

Detection of key-pressing at boot-time.

Hi good people of N7 land,
I wanted to ask if it's possible to make keys get detected at boot-time so that a certain function is carried out. If so how?
For example:
The N7 is booting up. I press the Vol + key, and due to a script executed by the init.delta.rc, /system is mounted to a IMG file in the sdcard. A dual-boot mod.
I also ask if this is the best way to do this, and please for the love of God, don't point me to MultiROM. I want to work on my own mod.
I expect helpful answers. And if you can't answer my question, don't even bother posting here.
Although this is a question, this is more dev-related than anything I've encountered in the Q/A section. So I thought of posting it here.
Please move this if this is not the right place, and accept my apologies.
sgt. meow
I don't think this is possible using just some script - init has no way to get input events from keys, so you would have to either edit the init binary or use exec init command.
You could use it to run another binary, which would check if volwhatever is pressed and either did nothing or did the dual-boot stuff.
It depends on when you want to check for the keypress, because if it is after the /system partition is mounted, you could use busybox and run bash script, otherwise it would have to be real binary, because when init is started, you have pretty much "just" kernel running and no userspace.
Or you could pack busybox to boot.img, but if you can code, the binary is pretty easy to make.
@up
Exactly the kind of answer I was hoping to find. Sucks to realize that I still don't know a lot of coding. But I'm willing to learn if you could point me to the right direction.
sgt. meow said:
Hi good people of N7 land,
I wanted to ask if it's possible to make keys get detected at boot-time so that a certain function is carried out. If so how?
For example:
The N7 is booting up. I press the Vol + key, and due to a script executed by the init.delta.rc, /system is mounted to a IMG file in the sdcard. A dual-boot mod.
I also ask if this is the best way to do this, and please for the love of God, don't point me to MultiROM. I want to work on my own mod.
I expect helpful answers. And if you can't answer my question, don't even bother posting here.
Although this is a question, this is more dev-related than anything I've encountered in the Q/A section. So I thought of posting it here.
Please move this if this is not the right place, and accept my apologies.
sgt. meow
Click to expand...
Click to collapse
The first idea that comes to my mind would be to code a simple no-UI app which would use a Service executed by a BroadCastReceiver set to BOOT_COMPLETED.
Then, when triggered (=at boot-time), the service would wait for the user to press a defined key (i.e : volume up). When the service receives the key press, it would mount /system or whatever you wanna do, then stop running (so that other volume up presses don't trigger this event again).
The code could be something like :
Your AndroidManifest.xml :
Code:
< ?xml version="1.0" encoding="utf-8"?>
< manifest xmlns:android="http://schemas.android.com/apk/res/android"
package="com.sgtmeow.boot.service"
android:versionCode="1"
android:versionName="1.0">
< uses-permission android:name="android.permission.RECEIVE_BOOT_COMPLETED" />
< application android:icon="@drawable/icon" android:label="@string/app_name">
< service android:name=".BootService">
< intent-filter>
< action
android:name = "com.sgtmeow.boot.service.BootService">
< /action>
< /intent-filter>
< /service>
< receiver android:name=".BootReceiver">
< intent-filter>
< action
android:name ="android.intent.action.BOOT_COMPLETED">
< /action>
< /intent-filter>
< /receiver>
< /application>
< uses-sdk android:minSdkVersion="8"
android:targetSdkVersion="17"android:targetSdkVersion="17" />
< /manifest>
BootReceiver.java :
Code:
package com.sgtmeow.boot.service;
import android.content.BroadcastReceiver;
import android.content.Context;
import android.content.Intent;
public class BootDemoReceiver extends BroadcastReceiver {
@Override
public void onReceive(final Context context, final Intent bootintent) {
Intent mServiceIntent = new Intent();
mServiceIntent.setAction("com.sgtmeow.boot.service.BootService");
context.startService(mServiceIntent);
}
}
BootService.java
Code:
package com.sgtmeow.boot.service;
import java.io.DataOutputStream;
import android.app.Service;
import android.content.Intent;
import android.os.IBinder;
import android.util.Log;
import android.view.KeyEvent;
import com.sgtmeow.boot.service.BootReceiver;
public class BootService extends Service {
Runtime mRuntime;
Process mProcess = null;
DataOutputStream mOutput = null;
@Override
public IBinder onBind(final Intent intent) {
return null;
}
@Override
public void onCreate() {
super.onCreate();
}
public boolean onKeyDown(int keyCode, KeyEvent event) {
super.onKeyDown(keyCode, event);
if (keyCode == KeyEvent.KEYCODE_VOLUME_UP) {
mountSystem();
Log.w("SGT.MEOW", "Volume Up has been pressed");
return true;
}
return true;
}
public void onStartCommand(final Intent intent, final int startId) {
super.onStartCommand(intent, startId, startId);
mountSystem();
}
private void mountSystem() {
Runtime.getRuntime();
// The service is now started, ask for root and mount /system using
// busybox (or not)
try {
mProcess = mRuntime.exec("su");
mOutput = new DataOutputStream(mProcess.getOutputStream());
mOutput.writeBytes("busybox mount -o remount,rw /system");
mOutput.flush();
stopService(new Intent(BootService.this, BootReceiver.class));
} catch (Exception e) {
Log.e("SGT.MEOW", "An Error Has Occured", e);
e.printStackTrace();
}
}
}
EDIT : unfortunately after some research I found out that Services cannot act as an onKeyListener, you'll have to call an activity to actually listen to the keypress so maybe just a dialog or something, but you won't be able to do it completely UI-less this way, my bad.
This is not something i would attempt to if you dont know what your doing due to the chance of bricks. but your best bet would be to luanch a binary from early init in the ram disk
aaronpoweruser said:
This is not something i would attempt to if you dont know what your doing due to the chance of bricks. but your best bet would be to luanch a binary from early init in the ram disk
Click to expand...
Click to collapse
I know how to launch the binary during init. The binary is the problem I am running into.
Thanks though.
You might want to take a look at how custom recoveries on the Xperia T handles the initial recovery vs. boot selection. On that device, there is no recovery partition, so a single kernel image must support both recovery and normal operation. The bootloader doesn't support an "enter recovery" poweron keycombo, so on the T there are some tricks so that at boot, it:
Sets the LED to purple
Waits 3 seconds or so
If the VolUp key is pressed during those 3 seconds, boot to recovery
Otherwise, boot normally
I believe the same approach is also used on the Xperia Z.
Maybe you could have a custom recovery that allows this? TWRP and CWM Touch both have source code available that you can check out so you can make your own recovery, which could allow booting of separate ROMS. Recoveries generally boot faster than full ROMs.
That's not what I was aiming to achieve. If I can manage to map the keys and find a way to detect them at boot-time, the rest is easy as pie. . Thanks though.
Entropy512 said:
You might want to take a look at how custom recoveries on the Xperia T handles the initial recovery vs. boot selection. On that device, there is no recovery partition, so a single kernel image must support both recovery and normal operation. The bootloader doesn't support an "enter recovery" poweron keycombo, so on the T there are some tricks so that at boot, it:
Sets the LED to purple
Waits 3 seconds or so
If the VolUp key is pressed during those 3 seconds, boot to recovery
Otherwise, boot normally
I believe the same approach is also used on the Xperia Z.
Click to expand...
Click to collapse
sgt. meow said:
That's not what I was aiming to achieve. If I can manage to map the keys and find a way to detect them at boot-time, the rest is easy as pie. . Thanks though.
Click to expand...
Click to collapse
None of the phones made by Sony have a recovery partition so they have to use a work around to detect keys on boot up. This is what all Xperia devices do to get into recovery: on boot check to see if the desired key is being pressed and if it is unzip the recovery, if it isn't being pressed unzip the normal ramdisk. (I'll post the ramdisk here for you to see how everything works yourself) So with the Xperia Play CyanogenMod kernel that I have how it works is it has two .cpio files. One for the ramdisk and one for the recovery. It uses a .sh file in the sbin to check if keys are being pressed by using /dev/input/event# which in most cases is event1 for volume down (on Nexus 7 the is event0, event1, and event2. My guess is 0 = power button and one and two are vol + and vol -). It then has a link to the init.sh in the root of the ramdisk called init so that when the kernel starts and calls init it starts the script. So what you could do is the same but instead of having two .cpio files you could rename the init file to something else then place the script and link in your ramdisk so that when the key is pressed it calls both what you want to do and the rename init executable. (Not sure how well this would work this is just an idea, if not depending on what you want to do you can keep the compressed ramdisk idea...)
Here is a ramdisk of what I've been talking about that is pulled from my kernel (extracted from an already compiled kernel to make it easy read.):
Link
It's made for the Xperia Play so it also tries to start the LED and vibrator to tell you when to click the Vol - key so how you would tell people to click it on the Nexus 7 I'm not sure...probably just have to have people will just have to spam the key. If you have any questions feel free to ask or if this didn't help I'm sorry just an idea.
Also what it seems like you want to do with the dual boot mod being with the SDCard sounds a lot like what a guy named CosmicDan did on the Xperia Play. You had to change the updater-script in your flashable zip but it worked. Here is the thread: Turbo Kernel and the source code to his kernel: GitHub
I know what he did with his kernel. I am working on something similar to the HD2 dual boot method. Haven't had any success yet.
Sent from my Nexus 7 using xda app-developers app
sgt. meow said:
I know what he did with his kernel. I am working on something similar to the HD2 dual boot method. Haven't had any success yet.
Sent from my Nexus 7 using xda app-developers app
Click to expand...
Click to collapse
hi! were you able to solve this?
thanks!

Linux ISO - Unbrick the Fire HD6/HD7 [Video] [Testers Wanted]

Testers wanted: Anyone who uses this method, let me know if you can access stock recovery after this method.
Summery
Thanks to the amazing work by our active member @bibikalka, a method was found to unbrick these devices Thread link here. The method he found was slightly tedious for some people, so I've decided to put together a Linux iso that you can boot into on your computer with everything you need to get your device running again. It uses the same methods proposed but makes things easier. This comes with all the necessary drivers, scripts to do everything you need, all the img files needed to flash, a hex editor for advanced users, and more. Before the scripts included in this OS, determining the option (A, B, or C) to take in order to unbrick the device required .part files to be evaluated manually. Now with the custom script, it can quickly evaluate what option to take.
Video Instructions
Brief Instructions
1. Download the Linux iso:
Linux ISO
2. Burn the iso to a USB drive or cd
3. Boot into the operating system
4. Type "root" at the login prompt
5. Right click on the desktop and choose file manager. Go to "aftv2-tools" folder
6. Right click on file manager and press "open in terminal"
7. From device turned off, enter command "./handshake.py", then plug in device. You may need to do this a couple times to get a connection. Try pressing volume keys & power etc to get it connected. See video if you have problems
8. After handshake is complete, run "./reader.sh"
9. After all addresses are read in, run "./determineOption.sh". You should get back a result of A, B, or C
10. Depending on the option returned (A,B,or C), run "./readerSpecialOptionA.sh", "./readerSpecialOptionB.sh", or "./readerSpecialOptionC.sh". This is an optional step but may be useful if you want to back up part files or their were no options available. Back up part files to a usb drive if you want to be safe.
11. Now the actual unbricking. Run "./unbrickOptionA.sh", "./unbrickOptionB.sh", or "./unbrickOptionA.sh" depending on your option. This can take about 40 minutes
12. hold volume up and run "./complete.sh" at the same time to get into TWRP
13. boot into your default operating system on your computer
BE VERY CAREFUL FROM NOW ON
13. We will be installing Fire OS 5.3.1. If you are not installing this ROM, make sure you know what you are doing. Download the ROM:
update-kindle-20.5.5.2_user_552153420.bin
14. Download 5.4.1_1133_stock_recovery_uboot.zip: 5.4.1_1133_stock_recovery_uboot.zip. Without this you could turn your device into a paperweight. This installs stock recovery and a uboot version that MUST be installed. This file was taken from the thread here: how-to-upgrade-to-lollipop-root-gapps
15. Rename the ROM extension from .bin to .zip
16. Transfer the two files to the Fire
17. Do a factory reset. Flash the ROM and uboot&recovery file
18. Reboot! Your device should now be working. It will take about 15 mins to boot up.
Big thanks to @bibikalka for helping work everything out and for the initial unbrick method.
Edit 10/13/21: Fixed Google Drive Link
Linux ISO Changelog
Updated 10/5/16:
*Optomized scripts
*Added "complete.sh" This reboots the device
Updated 9/27/16:
*Added script to auto-detect which unbrick option to use (determineOption.sh)
*Added scripts to write img files to correct addresses ( unbrickOptionA.sh, unbrickOptionB.sh, and unbrickOptionC.sh)
*Added scripts to read in and label part files (readerSpecialOptionA.sh, readerSpecialOptionB.sh, and readerSpecialOptionC.sh)
*Nemo open in terminal fixed
*.part files set to open with ghex by default
Updated 9/24/16:
*Nemo as default file manager
*Updated html page with instructions from forum
well, after seriously struggling with the parent thread mentioned in the OP I've managed to get to TWRP & am just waiting for my win10 machine to install it's updates before attempting to adb push the uboot & zip files for installation back to fireOS.
feels great to see the screen displaying something other than the looping amazon logo after months of frustration. I do not have the words to express my gratitude for @powerpoint45 for an excellent & well thought through tool and walkthrough. special mention also goes out to @bibikalka
gascomm said:
well, after seriously struggling with the parent thread mentioned in the OP I've managed to get to TWRP & am just waiting for my win10 machine to install it's updates before attempting to adb push the uboot & zip files for installation back to fireOS.
feels great to see the screen displaying something other than the looping amazon logo after months of frustration. I do not have the words to express my gratitude for @powerpoint45 for an excellent & well thought through tool and walkthrough. special mention also goes out to @bibikalka
Click to expand...
Click to collapse
great to hear! I hope everything works for you! After you get everything done, can you check if you can get into recovery.
after flashing both zips & rebooting I've now got my working fire (OS 5.3.1.0) back. thank you Mr PowerPoint!
i tried rebooting to recovery & it now takes me to the stock amazon recovery not TWRP..... which is unfortunate.
I did get asked if I wanted to install SuperUser which was a no-brainer YES. although I'm staying offline until I identify a functional (fast) flavour of android to flash. suggestions welcome.
gascomm said:
after flashing both zips & rebooting I've now got my working fire (OS 5.3.1.0) back. thank you Mr PowerPoint!
i be tried rebooting to recovery & it now takes me to the stock amazon recovery not TWRP..... which is unfortunate.
I did get asked if I wanted to install SuperUser which was a no-brainer YES. although I'm staying offline until I identify a functional (fast) flavour of android to flash. suggestions welcome.
Click to expand...
Click to collapse
Good to hear everything is working. Ya TWRP does not work with 5.x bootloader. Good to hear you can get into stock recovery because I had some incidents where I could not get into it. Thanks for responding. The only custom ROM ATM is CM13.
powerpoint45 said:
The only custom ROM ATM is CM13.
Click to expand...
Click to collapse
sorry to trouble you again but do you know where I can find a guide/walkthrough of how to root via adb & install twrp or cwm to allow flashing of a rom & gapps..
I can only find the kingroot method & the CM11 rom discussion. where might I find the CM13 you mentioned?
I have searched fruitlessly. I guess I just need a little guidance to avoid running straight into another brick.
cheers.
gascomm said:
sorry to trouble you again but do you know where I can find a guide/walkthrough of how to root via adb & install twrp or cwm to allow flashing of a rom & gapps..
I can only find the kingroot method & the CM11 rom discussion. where might I find the CM13 you mentioned?
I have searched fruitlessly. I guess I just need a little guidance to avoid running straight into another brick.
cheers.
Click to expand...
Click to collapse
I meant to say CM11. This guide is probably one of the best http://forum.xda-developers.com/fire-hd/general/how-to-upgrade-to-lollipop-root-gapps-t3163950/page1
This is a bit older one: http://forum.xda-developers.com/fire-hd/general/how-to-downgrade-to-4-5-3-root-device-t3139351/page1
In order to have TWRP, you must have a 4.x bootloader so CM11 would work with it.
Thank you
I have a question I can work downgrade from 5.3.1 to 4.5.3
I'm currently on version 5.3.1
PRInCEI7 said:
Thank you
I have a question I can work downgrade from 5.3.1 to 4.5.3
I'm currently on version 5.3.1
Click to expand...
Click to collapse
yes you should be fine doing that
Unfortunately, did not respond
I worked
MacBook-Air-2:ROOT IP$ ./handshake.py
Waiting for preloader...
Found port = /dev/cu.usbmodem1420
Handshake complete!
In the second step does not respond to the order ./reader.sh
Also tried
/.read_mmc.py 0x0000000 0x1000 0x0000000.part
Does not respond
By the way tried way on more than one device
And tried through the system Max os x and the system arch-custom-firehd67-unbrick100516.iso did not work and also the same result
MY device Amazon Fire HD 6 version 5.3.1 All functions work, but I need to work downgrade to 4.5.3
Is there a solution to my problem
[/SIZE]
@powerpoint45 thanks for the pointers. I am now the proud owned of an hd6 booting straight into cm11 & it's been well worth the wait. I am forever in your digital debt.
gascomm said:
@powerpoint45 thanks for the pointers. I am now the proud owned of an hd6 booting straight into cm11 & it's been well worth the wait. I am forever in your digital debt.
Click to expand...
Click to collapse
sweet!!!
PRInCEI7 said:
Unfortunately, did not respond
I worked
MacBook-Air-2:ROOT IP$ ./handshake.py
Waiting for preloader...
Found port = /dev/cu.usbmodem1420
Handshake complete!
In the second step does not respond to the order ./reader.sh
Also tried
/.read_mmc.py 0x0000000 0x1000 0x0000000.part
Does not respond
By the way tried way on more than one device
And tried through the system Max os x and the system arch-custom-firehd67-unbrick100516.iso did not work and also the same result
MY device Amazon Fire HD 6 version 5.3.1 All functions work, but I need to work downgrade to 4.5.3
Is there a solution to my problem
[/SIZE]
Click to expand...
Click to collapse
I am also getting the same results with my HD 7 4th gen. The handshake completes just fine, but the reader just hangs. When I'm in recovery, I get errors saying the /cache folder failed to mount. I'm thinking the memory is corrupt and there is no way to fix this.
nai1ed said:
I am also getting the same results with my HD 7 4th gen. The handshake completes just fine, but the reader just hangs. When I'm in recovery, I get errors saying the /cache folder failed to mount. I'm thinking the memory is corrupt and there is no way to fix this.
Click to expand...
Click to collapse
Unfortunately it appears that with the latest bootloader on the latest Amazon update that they have disabled these commands (such as reading and writing). Unfortunately if you can't get into recovery with (vol+ & power) then it is currently unrecoverable. Best option for an unrecoverable device would be to buy another motherboard from eBay or some place. They are pretty cheap and easy to replace. I've had to do it a couple times now.
Confused
First you say it should be OK to downgrade:
powerpoint45 said:
PRInCEI7 said:
Thank you
I have a question I can work downgrade from 5.3.1 to 4.5.3
I'm currently on version 5.3.1
Click to expand...
Click to collapse
yes you should be fine doing that
Click to expand...
Click to collapse
Although, it's unclear how, since reports indicate that sideloading older
firmware bricks the device (or, does that only apply to 5.x?).
Then, we learn that the preloader trick (from aftv2-tools) doesn't work anymore:
Code:
[[email protected] aftv2-tools]# ./handshake.py
Waiting for preloader...
Found port = /dev/ttyACM0
Handshake complete!
[[email protected] aftv2-tools]# ./reader.sh
^CTraceback (most recent call last):
File "./read_mmc.py", line 355, in <module>
if msdc_dma_status():
File "./read_mmc.py", line 146, in msdc_dma_status
return False if sdr_read32(MSDC_CFG) & MSDC_CFG_PIO else True
File "./read_mmc.py", line 82, in sdr_read32
check(dev.read(2), b'\x00\x00') # arg check
File "/usr/lib/python3.5/site-packages/serial/serialposix.py", line 450, in read
ready, _, _ = select.select([self.fd, self.pipe_abort_read_r], [], [], timeout)
KeyboardInterrupt
^CTraceback (most recent call last):
File "./read_mmc.py", line 355, in <module>
if msdc_dma_status():
File "./read_mmc.py", line 146, in msdc_dma_status
return False if sdr_read32(MSDC_CFG) & MSDC_CFG_PIO else True
File "./read_mmc.py", line 82, in sdr_read32
check(dev.read(2), b'\x00\x00') # arg check
File "/usr/lib/python3.5/site-packages/serial/serialposix.py", line 450, in read
ready, _, _ = select.select([self.fd, self.pipe_abort_read_r], [], [], timeout)
KeyboardInterrupt
^Z
[1]+ Stopped ./reader.sh
[[email protected] aftv2-tools]# kill %1
[[email protected] aftv2-tools]#
[1]+ Terminated ./reader.sh
[[email protected] aftv2-tools]#
The above is for a 4th gen HD7 with this device showing in 'lsusb':
Code:
Bus 001 Device 006: ID 0e8d:3000 MediaTek Inc.
powerpoint45 said:
Unfortunately it appears that with the latest bootloader on the latest Amazon update that they have disabled these commands (such as reading and writing). Unfortunately if you can't get into recovery with (vol+ & power) then it is currently unrecoverable. Best option for an unrecoverable device would be to buy another motherboard from eBay or some place. They are pretty cheap and easy to replace. I've had to do it a couple times now.
Click to expand...
Click to collapse
BTW, are we sure that this is *disabled* as opposed to _tweaked_?
(e.g. by changing the protocol slightly by, say, requiring an extra byte
or two "confirmation" before execution? has anyone bothered reversing
the bootloader? [Please excuse my ignorance, but would this be handled
by UBOOT, TEE1, or some other component?])
So, what's the current best option for 5.3.1?
---------- Post added at 11:23 ---------- Previous post was at 10:58 ----------
draxie said:
BTW, are we sure that this is *disabled* as opposed to _tweaked_?
(e.g. by changing the protocol slightly by, say, requiring an extra byte
or two "confirmation" before execution? has anyone bothered reversing
the bootloader?
Click to expand...
Click to collapse
OK. So, I found this post by @zeroepoch,
which makes it very clear that said exercise has been performed for the AFTV2...
No reason to believe that this would be different for the Fire HD7...
draxie said:
First you say it should be OK to downgrade:
Although, it's unclear how, since reports indicate that sideloading older
firmware bricks the device (or, does that only apply to 5.x?).
Then, we learn that the preloader trick (from aftv2-tools) doesn't work anymore:
The above is for a 4th gen HD7 with this device showing in 'lsusb':
BTW, are we sure that this is *disabled* as opposed to _tweaked_?
(e.g. by changing the protocol slightly by, say, requiring an extra byte
or two "confirmation" before execution? has anyone bothered reversing
the bootloader? [Please excuse my ignorance, but would this be handled
by UBOOT, TEE1, or some other component?])
So, what's the current best option for 5.3.1?
---------- Post added at 11:23 ---------- Previous post was at 10:58 ----------
OK. So, I found this post by @zeroepoch,
which makes it very clear that said exercise has been performed for the AFTV2...
No reason to believe that this would be different for the Fire HD7...
Click to expand...
Click to collapse
My understanding is that you only need to worry about bricking if You are downgrading to another lollypop ROM. We found out that the device has a fuse that is set in later lollypop ROMs where it will check against the current version. But this check only seems to be on lollipop ROM's. As for the aftv2 protocol, you might be right but I don't know enough about that yet to know. Currently we have no unbrick method for latest bootloader. If you can get into recovery then you could sideload but most can't get into recovery during brick.
I've followed the steps but not into twrp, only screen amazon and reset. I'm not good at English
error trying to unbrick hd6
[[email protected] aftv2-tools]# ./complete.sh
1: 0xd1
4: 0x00 0x00 0x00 0x00
4: 0x00 0x00 0x00 0x01
Traceback (most recent call last):
File "/usr/lib/python3.5/site-packages/serial/serialposix.py", line 468, in read
'device reports readiness to read but returned no data '
serial.serialutil.SerialException: device reports readiness to read but returned no data (device disconnected or multiple access on port?)
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "./read32.py", line 69, in <module>
ret = read32(addr, size)
File "./read32.py", line 45, in read32
print_hex_byte(dev.read(2)) # status
File "/usr/lib/python3.5/site-packages/serial/serialposix.py", line 475, in read
raise SerialException('read failed: {}'.format(e))
serial.serialutil.SerialException: read failed: device reports readiness to read but returned no data (device disconnected or multiple access on port?)
[[email protected] aftv2-tools]#
kingwill101 said:
[[email protected] aftv2-tools]# ./complete.sh
1: 0xd1
4: 0x00 0x00 0x00 0x00
4: 0x00 0x00 0x00 0x01
Traceback (most recent call last):
File "/usr/lib/python3.5/site-packages/serial/serialposix.py", line 468, in read
'device reports readiness to read but returned no data '
serial.serialutil.SerialException: device reports readiness to read but returned no data (device disconnected or multiple access on port?)
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "./read32.py", line 69, in <module>
ret = read32(addr, size)
File "./read32.py", line 45, in read32
print_hex_byte(dev.read(2)) # status
File "/usr/lib/python3.5/site-packages/serial/serialposix.py", line 475, in read
raise SerialException('read failed: {}'.format(e))
serial.serialutil.SerialException: read failed: device reports readiness to read but returned no data (device disconnected or multiple access on port?)
[[email protected] aftv2-tools]#
Click to expand...
Click to collapse
You are on any version.
You can access to recovery now

Categories

Resources