Hello,
I tried to build a kernel myself and it just fails to boot. I have UART access (through headphone adapter) and I just get nothing in the serial console.
I have CM 11.0 and I cloned CM's android_kernel_lge_hammerhead repo and checked out stable/cm-11.0 with hammerhead_defconfig.
I used google's arm-eabi-4.8 precompiled toolchain.
To boot:
Code:
ttouch android_kernel_lge_hammerhead> sudo fastboot boot arch/arm/boot/zImage-dtb
creating boot image...
creating boot image - 8583168 bytes
downloading 'boot.img'...
OKAY [ 0.375s]
booting...
OKAY [ 0.123s]
finished. total time: 0.498s
Here is what I get in UART:
Code:
welcome to hammerhead bootloader
[10] Power on reason 81
[10] DDR: elpida
[90] Loaded IMGDATA at 0x11000000
[90] Display Init: Start
[170] MDP GDSC already enabled
[170] bpp 24
[210] Config MIPI_CMD_PANEL.
[210] display panel: ORISE
[210] display panel: Default setting
[340] Turn on MIPI_CMD_PANEL.
[390] Display Init: Done
[390] cable type from shared memory: 8
[390] vibe
[590] USB init ept @ 0xf957000
[610] secured device: 1
[610] fastboot_init()
[660] splash: fastboot_op
FASTBOOT MODE
PRODUCT_NAME - hammerhead
VARIANT - hammerhead D821(E) 16GB
HW VERSION - rev_11
BOOTLOADER VERSION - HHZ11k
BASEBAND VERSION - M8974A-2.0.50.1.16
CARRIER INFO - None
SERIAL NUMBER - <blablablabla>
SIGNING - production
SECURE BOOT - enabled
LOCK STATE - unlocked
[770] splash: start
[1260] splash: bootloader
[1260] Fastboot mode started
[1260] udc_start()
�����l[60660] -- reset --
[60660] -- portchange --
[60820] -- reset --
[60820] -- portchange --
[60990] fastboot: processing commands
��[112660] fastboot: download:0082f800
downloading...
[113140] fastboot: boot
[113150] Found Appeneded Flattened Device tree
[113150] DTB: platform id 126, board id 150, soc rev 20002, board rev 11
[113160] get_display_kcal = 0, 0, 0, x
[113200] vibe
[113300] splash: boot
[113340] splash: unlocked
[113380] cmdline: uart_console=enable lcd_maker_id=primary lge.hreset=off lge.reset=unknown gpt=enable lge.kcal=0|0|0|x lge.rev=rev_11 androidboot.laf androidboot.emmc=true fastboot=true androidboot.serialno=<blablablabla> androidboot.bootloader=HHZ11k androidb[113400] Updating device tree: start
[113420] Updating device tree: done
[113420] booting linux @ 0x10008000, ramdisk @ 0x11000000 (0), tags/device tree @ 0x10000100
[113430] Turn off MIPI_CMD_PANEL.
[113430] Continuous splash enabled, keeping panel alive.
[113430] undefined abort, halting
[113430] r0 0x00000000 r1 0x00000000 r2 0x10000100 r3 0x003996e3
[113430] r4 0x10008000 r5 0x0f92607a r6 0x0f925d5b r7 0x0f925f89
[113430] r8 0x0f955652 r9 0x0f9556c7 r10 0x00000001 r11 0x10000100
[113430] r12 0x20000193 usp 0x00000000 ulr 0x00000000 pc 0x1000800c
[113430] spsr 0x40000193
I've never installed a kernel like that (via fastboot) and I had to look up the headphone UART adapter thing.
I don't have much to offer. I always use mkbootimg to link my kernel and ramdisk, then flash it via fastboot. Looking at your serial dump, the only thing I see is that the base, ramdisk, and tags offsets look completely different from the ones I use with mkbootimg.
BASE=0x00000000
PAGESIZE=2048
RAMDISK_OFFSET=0x02900000
TAGS_OFFSET=0x02700000
I'm playing around with my breadboard and an FTDI USB<-->Serial board I have to try and make a working serial console and I'll see what my N5 dumps.
Gene Poole said:
I've never installed a kernel like that (via fastboot) and I had to look up the headphone UART adapter thing.
I don't have much to offer. I always use mkbootimg to link my kernel and ramdisk, then flash it via fastboot. Looking at your serial dump, the only thing I see is that the base, ramdisk, and tags offsets look completely different from the ones I use with mkbootimg.
BASE=0x00000000
PAGESIZE=2048
RAMDISK_OFFSET=0x02900000
TAGS_OFFSET=0x02700000
Click to expand...
Click to collapse
Thanks, I'll try that.
Gene Poole said:
I'm playing around with my breadboard and an FTDI USB<-->Serial board I have to try and make a working serial console and I'll see what my N5 dumps.
Click to expand...
Click to collapse
I guess you're trying to build the N4 cable, but it does not work.
For the N5 to work you need to supply 3V3 and not 1V8 to the VCC
The RX though (serial input to the N5) should be 1V8 (done with a simple voltage divider, try 1K and 1.2K to GND) or there is a chance that you'll fry your serial.
Yeah, my search showed that the N5 version needed no resistors, but I used some anyway just to shunt some voltage. It worked. I got a dump and it does appear that your offsets are not right. Here's my dump up to the kernel taking over:
Code:
welcome to hammerhead bootloader
[10] Power on reason 80
[10] DDR: hynix
[90] Loaded IMGDATA at 0x11000000
[90] Display Init: Start
[170] MDP GDSC already enabled
[170] bpp 24
[210] Config MIPI_CMD_PANEL.
[210] display panel: ORISE
[260] Found Appeneded Flattened Device tree
[260] DTB: platform id 126, board id 150, soc rev 20002, board rev 11
[300] Set panel ON cmds [35]
[420] Turn on MIPI_CMD_PANEL.
[470] Display Init: Done
[470] cable type from shared memory: 8
[470] reboot_mode restart reason = power_on
[520] vibe
[620] splash: boot
[660] splash: unlocked
[700] use_signed_kernel=0, is_unlocked=1, is_tampered=0.
[700] Loading boot image (9226240): start
[1030] Loading boot image (9226240): done
[1030] Found Appeneded Flattened Device tree
[1040] DTB: platform id 126, board id 150, soc rev 20002, board rev 11
[1040] get_display_kcal = 0, 0, 0, x
[1050]
Booting Linux
[1050] cmdline: console=ttyHSL0,115200,n8 androidboot.hardware=hammerhead user_debug=31 maxcpus=2 msm_watchdog_v2.enable=1 selinuxt
[1090] Updating device tree: done
[1090] booting linux @ 0x8000, ramdisk @ 0x2900000 (714802), tags/device tree @ 0x2700000
[1100] Turn off MIPI_CMD_PANEL.
[1100] Continuous splash enabled, keeping panel alive.
[ 0.000000] Booting Linux on physical CPU 0
[ 0.000000] Initializing cgroup subsys cpu
[ 0.000000] Linux version 3.4.0-hoxnet-gd745771 ([email protected]) (gcc version 4.6.x-google 20120106 (prerelease) (GCC) ) #7 SMP PREE5
[ 0.000000] CPU: ARMv7 Processor [512f06f0] revision 0 (ARMv7), cr=10c5387d
[ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, PIPT instruction cache
...
I see a fastboot option, -b, for specifying the kernel base address. Try with -b 0x8000.
Edit: maybe it's -b 0. looks like the address gets 0x8000 added by default.
Gene Poole said:
Yeah, my search showed that the N5 version needed no resistors, but I used some anyway just to shunt some voltage. It worked. I got a dump and it does appear that your offsets are not right. Here's my dump up to the kernel taking over:
Code:
welcome to hammerhead bootloader
[10] Power on reason 80
[10] DDR: hynix
[90] Loaded IMGDATA at 0x11000000
[90] Display Init: Start
[170] MDP GDSC already enabled
[170] bpp 24
[210] Config MIPI_CMD_PANEL.
[210] display panel: ORISE
[260] Found Appeneded Flattened Device tree
[260] DTB: platform id 126, board id 150, soc rev 20002, board rev 11
[300] Set panel ON cmds [35]
[420] Turn on MIPI_CMD_PANEL.
[470] Display Init: Done
[470] cable type from shared memory: 8
[470] reboot_mode restart reason = power_on
[520] vibe
[620] splash: boot
[660] splash: unlocked
[700] use_signed_kernel=0, is_unlocked=1, is_tampered=0.
[700] Loading boot image (9226240): start
[1030] Loading boot image (9226240): done
[1030] Found Appeneded Flattened Device tree
[1040] DTB: platform id 126, board id 150, soc rev 20002, board rev 11
[1040] get_display_kcal = 0, 0, 0, x
[1050]
Booting Linux
[1050] cmdline: console=ttyHSL0,115200,n8 androidboot.hardware=hammerhead user_debug=31 maxcpus=2 msm_watchdog_v2.enable=1 selinuxt
[1090] Updating device tree: done
[1090] booting linux @ 0x8000, ramdisk @ 0x2900000 (714802), tags/device tree @ 0x2700000
[1100] Turn off MIPI_CMD_PANEL.
[1100] Continuous splash enabled, keeping panel alive.
[ 0.000000] Booting Linux on physical CPU 0
[ 0.000000] Initializing cgroup subsys cpu
[ 0.000000] Linux version 3.4.0-hoxnet-gd745771 ([email protected]) (gcc version 4.6.x-google 20120106 (prerelease) (GCC) ) #7 SMP PREE5
[ 0.000000] CPU: ARMv7 Processor [512f06f0] revision 0 (ARMv7), cr=10c5387d
[ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, PIPT instruction cache
...
I see a fastboot option, -b, for specifying the kernel base address. Try with -b 0x8000.
Edit: maybe it's -b 0. looks like the address gets 0x8000 added by default.
Click to expand...
Click to collapse
Didn't work.
I also tried to build a boot.img, I flashed it (just to be sure) and I get all the same results.
My tags/device tree is different and I don't know how to change it. There is no available option in fastboot or mkbootimg
ttouch said:
Didn't work.
I also tried to build a boot.img, I flashed it (just to be sure) and I get all the same results.
My tags/device tree is different and I don't know how to change it. There is no available option in fastboot or mkbootimg
Click to expand...
Click to collapse
mkbootimg has an undocumented --tags_offset option. I don't know why it doesn't show up in the --help. I found it in the source for mkbootimg (in the AOSP tree) when I first ran the unpackbootimg and noticed that it dumped text files containing info about the offsets.
I have a shell script I use to make boot images. Here it is:
Code:
#!/bin/sh
RAMDISK=ramdisk
KERNEL=zImage
BASE=0x00000000
PAGESIZE=2048
RAMDISK_OFFSET=0x02900000
TAGS_OFFSET=0x02700000
CMDLINE="console=ttyHSL0,115200,n8 androidboot.hardware=hammerhead user_debug=31 maxcpus=2 msm_watchdog_v2.enable=1 selinux=1"
echo Making ramdisk image ...
(cd ${RAMDISK} ; mkbootfs . | gzip -9c > ../${RAMDISK}.cpio.gz )
echo Making boot image ...
mkbootimg --kernel ${KERNEL} --ramdisk ${RAMDISK}.cpio.gz --cmdline "${CMDLINE}" -o boot.img --base ${BASE} --pagesize ${PAGESIZE} --ramdisk_offset ${RAMDISK_OFFSET} --tags_offset ${TAGS_OFFSET}
"ramdisk" is a directory containing the unpacked AOSP stock ramdisk (plus my modifications). These offset values were obtained from unpackbootimg executable but I can't remember where I found the source. I'll send you a copy if you want it.
Gene Poole said:
mkbootimg has an undocumented --tags_offset option. I don't know why it doesn't show up in the --help. I found it in the source for mkbootimg (in the AOSP tree) when I first ran the unpackbootimg and noticed that it dumped text files containing info about the offsets.
I have a shell script I use to make boot images. Here it is:
Code:
#!/bin/sh
RAMDISK=ramdisk
KERNEL=zImage
BASE=0x00000000
PAGESIZE=2048
RAMDISK_OFFSET=0x02900000
TAGS_OFFSET=0x02700000
CMDLINE="console=ttyHSL0,115200,n8 androidboot.hardware=hammerhead user_debug=31 maxcpus=2 msm_watchdog_v2.enable=1 selinux=1"
echo Making ramdisk image ...
(cd ${RAMDISK} ; mkbootfs . | gzip -9c > ../${RAMDISK}.cpio.gz )
echo Making boot image ...
mkbootimg --kernel ${KERNEL} --ramdisk ${RAMDISK}.cpio.gz --cmdline "${CMDLINE}" -o boot.img --base ${BASE} --pagesize ${PAGESIZE} --ramdisk_offset ${RAMDISK_OFFSET} --tags_offset ${TAGS_OFFSET}
"ramdisk" is a directory containing the unpacked AOSP stock ramdisk (plus my modifications). These offset values were obtained from unpackbootimg executable but I can't remember where I found the source. I'll send you a copy if you want it.
Click to expand...
Click to collapse
My mkbootimg does not have the tags_offset.
When I try to build the boot image with tags_offset, mkbootimg shows me the help message, which means it got no tags_offset option.
EDIT: Nevermind, I cloned and compiled the latest mkbootimg from here. Trying to boot it now...
EDIT2: IT WORKS!!
Since the AOSP build has to create a boot image, it is included in the utilities. I always use the one native to the build tree. It is in:
[aosp_root]/out/host/linux-x86/bin/mkbootimg
and the source is in:
[aosp_root]/system/core/mkbootimg/
Related
config_cmdline won't take effect if I modify there.
mkbootimg plus costumized command like also do not show up when kernel booting.
it looks like the kernel command line is in the bootloader code and passed to the kernel, and can NOT be overriden.
any one has sucussful experience changing the kernel commandline on droid?
Thanks in advance.
my kernel command line in dmesg is attached here:
<5>[ 0.000000] Kernel command line: console=ttyS2,115200n8 console=ttyMTD7 rw [email protected] init=/init ip=off brdrev=P3A_CDMA mtdparts=omap2-nand.0:[email protected](pds),[email protected](misc),3584k(boot)ro,4608k(recovery),143744k(system),94848k(cache),268032k(userdata),2m(kpanic) androidboot.mode=normal androidboot.bootloader=2C6C0 androidboot.serialno=xxxxxxxxxxxxxxxxxxxx
<6>[ 0.000000] boot_mode=normal
<6>[ 0.000000] PID hash table entries: 1024 (order: 0, 4096 bytes)
Nexus 1 said:
config_cmdline won't take effect if I modify there.
mkbootimg plus costumized command like also do not show up when kernel booting.
it looks like the kernel command line is in the bootloader code and passed to the kernel, and can NOT be overriden.
any one has sucussful experience changing the kernel commandline on droid?
Thanks in advance.
Click to expand...
Click to collapse
I just finished doing this so that I could boot Debian. I'll post my notes here, and come back and pretty them up later.
Code:
Install the following packages using your favorite package manager:
Debian based Linux distributions
32bit and 64bit systems:
git-core gnupg sun-java6-jdk flex bison gperf libsdl-dev libesd0-dev libwxgtk2.6-dev build-essential zip curl libncurses5-dev zlib1g-dev abootimg
64bit only:
ia32-libs lib32z1-dev lib32ncurses5-dev gcc-multilib g++-multilib
Download Code Sourcery ARM EABI Toolchain:
Use "./arm-2012.03-56-arm-none-eabi.bin" to install, then create an environment variable denoting the location of the toolchain as follows:
export CCOMPILER=[Install Folder]/bin/arm-none-eabi
Download Kernel Source Code
mkdir -p ~/android/kernel
cd ~/android/kernel
git clone git://github.com/cvpcs/android_kernel_omap.git --branch cm-sholes
cd android_kernel_omap
git reset --hard 470cb3613f8da9a2483d5592f750ef4ad7de29bf
Download cm-7.2.0-sholes.zip:
Extract, then copy boot.img to cm-kernel folder, then pull .config as follows:
scripts/extract-ikconfig boot.img > .config
The heart of this hack relies on a kernel configuration option that was created for situations when you can't change the command-line options of the boot loader, but you can change the kernel.
1) Open .config and replace:
------------------------------------
CONFIG_CMDLINE="root=/dev/nfs nfsroot=192.168.0.1:/home/user/buildroot ip=192.168.0.2:192.168.0.1:192.168.0.1:255.255.255.0:tgt:eth0:off rw console=ttyS2,115200n8"
------------------------------------
with
------------------------------------
CONFIG_CMDLINE="[email protected] mtdparts=omap2-nand.0:[email protected](mbm),[email protected](cdt),[email protected](lbl),[email protected](misc),3584k(boot),4608k(recovery),143744k(system),94848k(cache),268032k(userdata),2m(kpanic) root=/dev/mmcblk0p2 console=tty1"
CONFIG_CMDLINE_FORCE=y
------------------------------------
2)
Open arch/arm/Kconfig and replace:
------------------------------------
time by entering them here. As a minimum, you should specify the
memory size and the root device (e.g., mem=64M root=/dev/nfs).
config XIP_KERNEL
bool "Kernel Execute-In-Place from ROM"
depends on !ZBOOT_ROM
------------------------------------
with
------------------------------------
time by entering them here. As a minimum, you should specify the
memory size and the root device (e.g., mem=64M root=/dev/nfs).
config CMDLINE_FORCE
bool "Always use the default kernel command string"
depends on CMDLINE != ""
help
Always use the default kernel command string, even if the boot
loader passes other arguments to the kernel.
This is useful if you cannot or don't want to change the
command-line options your boot loader passes to the kernel.
If unsure, say N.
config XIP_KERNEL
bool "Kernel Execute-In-Place from ROM"
depends on !ZBOOT_ROM
------------------------------------
3)
Open arch/arm/kernel/setup.c and replace:
------------------------------------
static int __init parse_tag_cmdline(const struct tag *tag)
{
strlcpy(default_command_line, tag->u.cmdline.cmdline, COMMAND_LINE_SIZE);
return 0;
}
------------------------------------
with
------------------------------------
static int __init parse_tag_cmdline(const struct tag *tag)
{
#ifndef CONFIG_CMDLINE_FORCE
strlcpy(default_command_line, tag->u.cmdline.cmdline, COMMAND_LINE_SIZE);
#else
pr_warning("Ignoring tag cmdline (using the default kernel command line)\n");
#endif /* CONFIG_CMDLINE_FORCE */
return 0;
}
------------------------------------
Actual Compiling!
make ARCH=arm CROSS_COMPILE=$CCOMPILER -j`grep 'processor' /proc/cpuinfo | wc -l`
Creating "boot.img"!
mkdir ~/android/boot/
mv boot.img ~/android/boot/boot.img
cd ~/android/boot/
abootimg -x boot.img
sed -i 8d bootimg.cfg
rm boot.img initrd.img zImage
cp ~/android/kernel/android_kernel_omap/arch/arm/boot/zImage ~/android/boot/zImage
echo > ~/android/boot/initrd.img
abootimg --create boot.img -f bootimg.cfg -k zImage -r initrd.img
Flashing "bootimg"!
adb push boot.img /tmp/boot.img
adb shell flash_image boot /tmp/boot.img
use pst editor
My Tab has become a compete brick after firmware flashing. Screen is black, no USB connection, no other signs of life. I've disassembled the device and have access to JTAG pins. Does anyone have experience with using OpenOCD to recover Galaxy Tab or Galaxy S? In my understanding, I need to flash initial and secondary bootloader to be able to proceed with Odin/Heimdall.
For anyone interested, I was able to attach to board with OpenOCD using configuration script bellow.
Tab halted in first bootloader with next output
PBL: Error.. sbl verification failed..
PBL: booting stop!
Code:
reset_config trst_and_srst
jtag_rclk 8
if { [info exists CHIPNAME] } {
set _CHIPNAME $CHIPNAME
} else {
set _CHIPNAME S5PC110
}
# CoreSight Debug Access Port
if { [info exists DAP_TAPID ] } {
set _DAP_TAPID $DAP_TAPID
} else {
set _DAP_TAPID 0x1ba00477
}
jtag newtap $_CHIPNAME DAP -irlen 4 -ircapture 0x1 -irmask 0xf -expected-id $_DAP_TAPID
# GDB target: Cortex-A8, using DAP
set _TARGETNAME $_CHIPNAME.cpu
target create $_TARGETNAME cortex_a8 -chain-position $_CHIPNAME.DAP
proc S5PC110_dbginit {target} {
# General Cortex A8 debug initialisation
cortex_a8 dbginit
}
# Slow speed to be sure it will work
#jtag_rclk 1000
#$_TARGETNAME configure -event "reset-start" { jtag_rclk 1000 }
$_TARGETNAME configure -event reset-assert-post "S5PC110_dbginit $_TARGETNAME"
I haven't got any experience with OpenOCD yet. But from what I heard, oneNAND access using openOCD is hard. I would try first to load SBL directly into memory. Dunno whats it location in Tab, if you upload somewhere PBL+SBL I can tell you. If its the same mem location as in I9000, then run it, halt core where PBL hangs (its important, because then you've got DRAM controllers configured - mem is accessible) and write sbl.bin onto 0x40244000 (or whatever is the address in Tab, it should be hex written in little endian notation at 0x20 offset of sbl.bin), then just jump into beggining of SBL holding download mode key combination. If partitions are corrupted it probably wont show anything on screen, but should produce UART output and enter dload mode.
Its just my concept, but should work.
If it doesn't work - try to find S5P oneNAND drivers for OpenOCD, maybe they exists already.
Thank you for this suggestion. Unfortunately it doesn't help. I downloaded Sbl image and run it, but it stacked somewhere in UART2 transmition.
Will try to connect to UART lines to see what's output there.
Here is my logs of OpenOcd session
connected and halted board
Code:
Open On-Chip Debugger
> halt
target state: halted
target halted in ARM state due to debug-request, current mode: Supervisor
cpsr: 0x600001d3 pc: 0x40205450
MMU: disabled, D-Cache: disabled, I-Cache: enabled
> arm disassemble 0x40205430 15
0x40205430 0xeb004b0f BL 0x40218074 ; ?? call some verification function
0x40205434 0xe1a03000 MOV r3, r0
0x40205438 0xe3530000 CMP r3, #0x0
0x4020543c 0x0a000004 BEQ 0x40205454 ; result OK, jump _VerifyOK
0x40205440 0xe59f002c LDR r0, [r15, #0x2c]
0x40205444 0xebfffdff BL 0x40204c48 ; printf "PBL: Error.. sbl verification failed.."
0x40205448 0xe59f0028 LDR r0, [r15, #0x28]
0x4020544c 0xebfffdfd BL 0x40204c48 ; printf "PBL: booting stop!"
0x40205450 0xeafffffe B 0x40205450 ; halt
; _VerifyOK
0x40205454 0xe59f3014 LDR r3, [r15, #0x14] ; r3 = 0x4053924c
0x40205458 0xe5933000 LDR r3, [r3] ; r3 = 0x40244000
0x4020545c 0xe12fff33 BLX r3 ; call Sbl at RAM 0x40244000
0x40205460 0xe24bd004 SUB r13, r11, #0x4
0x40205464 0xe8bd8800 LDM r13!, {r11, r15}
0x40205468 0x402186e0 EORMI r8, r1, r0, ROR #0xd
lets insert NOP (0xe1a00000) at 0x40205450 to continue execution
Code:
> mww 0x40205450 0xe1a00000
> arm disassemble 0x40205450 3
0x40205450 0xe1a00000 NOP
0x40205454 0xe59f3014 LDR r3, [r15, #0x14]
0x40205458 0xe5933000 LDR r3, [r3]
one more thing, let's put a breakpoint at start of Sbl
Code:
> bp 0x40244000 4 hw
breakpoint set at 0x40244000
> resume
after a while board halted at breakpoint
Code:
target state: halted
target halted in ARM state due to breakpoint, current mode: Supervisor
cpsr: 0x600001d3 pc: 0x40244000
MMU: disabled, D-Cache: disabled, I-Cache: enabled
remove breakpoint
> rbp 0x40244000
let's check where we are
Code:
> arm disassemble 0x40244000 15
0x40244000 0xea000007 B 0x40244024
0x40244004 0xeafffffe B 0x40244004
0x40244008 0xeafffffe B 0x40244008
0x4024400c 0xeafffffe B 0x4024400c
0x40244010 0xeafffffe B 0x40244010
0x40244014 0xeafffffe B 0x40244014
0x40244018 0xeafffffe B 0x40244018
0x4024401c 0xeafffffe B 0x4024401c
0x40244020 0x40244000 EORMI r4, r4, r0
0x40244024 0xe10f0000 MRS r0, CPSR
0x40244028 0xe3c000ff BIC r0, r0, #0xff
0x4024402c 0xe38000d3 ORR r0, r0, #0xd3
0x40244030 0xe129f000 MSR CPSR_cf, r0
0x40244034 0xe59fd17c LDR r13, [r15, #0x17c]
0x40244038 0xe3a00000 MOV r0, #0x0
load Sbl image and resume
> load_image Sbl.bin 0x40244000 bin
> resume 0x40244000
Tab still dead, no USB, no screen. If I halt it, it stacked at this function.
Code waits for transmit empty (UTRSTAT2), but UTRSTAT2 value always #0
Code:
40253394: e52db004 push {fp} ; (str fp, [sp, #-4]!)
40253398: e28db000 add fp, sp, #0
4025339c: e24dd00c sub sp, sp, #12
402533a0: e50b0008 str r0, [fp, #-8]
402533a4: e59f302c ldr r3, [pc, #44] ; 0x402533d8 r3 = 0xe2900810 (UTRSTAT2)
402533a8: e5933000 ldr r3, [r3]
402533ac: e2033002 and r3, r3, #2
402533b0: e3530000 cmp r3, #0
402533b4: 0afffffa beq 0x402533a4
402533b8: e59f201c ldr r2, [pc, #28] ; 0x402533dc r2 = 0xe2900820 (UTXH2)
402533bc: e51b3008 ldr r3, [fp, #-8]
402533c0: e5823000 str r3, [r2]
402533c4: e3a03000 mov r3, #0
402533c8: e1a00003 mov r0, r3
402533cc: e28bd000 add sp, fp, #0
402533d0: e8bd0800 pop {fp}
402533d4: e12fff1e bx lr
Odd. PBL is loading SBL but checksum function fails.
Maybe try with different SBL version. Also please upload SBL and PBL you're using. I can't find the right one to analyze. (look at your private messages)
A look into UART output may be useful also. You can always try to set NOP in SBL there, bricking UART handling and pray that it will run USB Dload successfully.
To provide progress on unbricking. I was unable to find OpenNAND support for OpenOCD to flash correct images.
Got Riff Box and reflashed bootloaders with it. Now my device back to healthy condition.
Hey there,
I hope that you don't mind me posting here, but I figure that this is the best place to get some assistance. I'm attempting to port CM11 to the Galaxy Note 10.1 2014 Edition (SM-P605). This is a very similar device to the Note 3, and as such, I've started by forking the Note 3 device tree. This is the first port that I've attempted, so I am very new to all of this.
I am using the Samsung stock 4.3 kernel sources for my device. When I run "make recoveryimage", everything seems to work fine and I get a recovery.img file. However, despite fiddling with all manner of settings in BoardConfig.mk, I cannot get it to boot. It just gets itself into a bootloop, saying "Recovery boooting..." at the top left, and then rinse-repeat.
I suspect that my problem lies with the ramdisk, and/or the ramdisk offset. The following is taken from the Note 3 BoardConfig.mk.
Code:
# Kernel
BOARD_KERNEL_CMDLINE := console=null androidboot.hardware=qcom user_debug=31 msm_rtb.filter=0x3F
BOARD_KERNEL_BASE := 0x00000000
BOARD_KERNEL_PAGESIZE := 2048
BOARD_MKBOOTIMG_ARGS := --ramdisk_offset 0x02900000 --tags_offset 0x02700000
BOARD_KERNEL_SEPARATED_DT := true
BOARD_CUSTOM_BOOTIMG_MK := device/samsung/hlte/mkbootimg.mk
I presume that those offsets are different per device. After a bit of research, I came across an app called unmkbootimg which can supposedly tell me what I need to know. After feeding it my boot.img, I got the following result.
Code:
unmkbootimg version 1.2 - Mikael Q Kuisma <[email protected]>
Kernel size 7536872
Kernel address 0x8000
Ramdisk size 1375263
Ramdisk address 0x2000000
Secondary size 0
Secondary address 0xf00000
Kernel tags address 0x1e00000
Flash page size 2048
Board name is ""
Command line "console=null androidboot.hardware=qcom user_debug=31 msm_rtb.filter=0x3F"
*** WARNING ****
This image is built using NON-standard mkbootimg!
OFF_KERNEL_ADDR is 0xFE208100
OFF_RAMDISK_ADDR is 0x00200100
OFF_SECOND_ADDR is 0xFF100100
Please modify mkbootimg.c using the above values to build your image.
****************
Extracting kernel to file zImage ...
Extracting root filesystem to file initramfs.cpio.gz ...
All done.
---------------
To recompile this image, use:
mkbootimg --kernel zImage --ramdisk initramfs.cpio.gz --base 0x1dfff00 --cmdline 'console=null androidboot.hardware=qcom user_debug=31 msm_rtb.filter=0x3F' -o new_boot.img
---------------
I've tried 0x00200100 and 0x2000000 for ramdisk offset (purely because I am not sure which one is correct there), but both give the same result (ie. nothing).
I've also tried outputting the log to the LCD with
Code:
BOARD_KERNEL_CMDLINE := console=tty0,115200 fbcon=rotate:1 fbcon=font:VGA8x8 androidboot.hardware=qcom user_debug=31 msm_rtb.filter=0x3F
This made no difference at all either.
I'm not sure what else to try, so I'm looking for any suggestions please.
If you'd like to take a look at my device tree, it is here:
https://github.com/StNick
Thanks in advance.
Code:
*** WARNING ****
This image is built using NON-standard mkbootimg!
OFF_KERNEL_ADDR is 0xFE208100
OFF_RAMDISK_ADDR is 0x00200100
OFF_SECOND_ADDR is 0xFF100100
Please modify mkbootimg.c using the above values to build your image.
****************
Just to get that out of the way, did you try the above values?
What board does the SM-P605 use? (MSM8974AB?) Is it a Qualcomm or Exynos device?
You are able to get no output?
This may or may not be the right place to post such a question, but I think you'd be more likely to find the answer to your question here
StNickZA said:
Hey there,
I hope that you don't mind me posting here, but I figure that this is the best place to get some assistance. I'm attempting to port CM11 to the Galaxy Note 10.1 2014 Edition (SM-P605).
...
Click to expand...
Click to collapse
Are you certain that this one isn't a better place to start:
http://forum.xda-developers.com/galaxy-note-10-2014/development
xclub_101 said:
Are you certain that this one isn't a better place to start:
http://forum.xda-developers.com/galaxy-note-10-2014/development
Click to expand...
Click to collapse
Fairly certain, yes. The work being done on the Note 10.1 2014 Edition all pertains to the Exynos version which is less relevant to my device than the Note 3.
Just looking for some help from guys that have built for a similar device.
[WIP]Dissecting the bootloader aka: get rid of annoying "Your device is corrupt"
This is WIP (work in progress) ... posting this as a separate thread to get other people involved so we can try to get rid of the annoying "Your device is corrupt" thing.
On the back of my thread on the splash screen (see https://forum.xda-developers.com/oneplus-6t/development/tool-splash-screen-modification-t3874158), @AnoopKumar and I started checking the bootloader.
The bootloader is in the partition called: abl_a (and/or abl_b) depending on whether you boot from A or B slot.
(https://forum.xda-developers.com/showpost.php?p=78409574&postcount=28)
All below is on Linux ... I am not a Windows guru ...
Take a raw dump of the abl_a partition. Reboot into TWRP, once there do: "adb shell".
Code:
> adb shell
# dd if=/dev/block/bootdevice/by-name/abl_b of=/sdcard/img.abl_a
# <ctrl-D>
> adb pull /sdcard/img.abl_a
You will now have the dump of the bootloader partition in the file
Then, use "binwalk" to see what is inside the abl_a image:
Code:
> binwalk -e img.abl_a
DECIMAL HEXADECIMAL DESCRIPTION
--------------------------------------------------------------------------------
0 0x0 ELF, 32-bit LSB executable, ARM, version 1 (SYSV)
4488 0x1188 Certificate in DER format (x509 v3), header length: 4, sequence length: 1279
5771 0x168B Certificate in DER format (x509 v3), header length: 4, sequence length: 1133
6908 0x1AFC Certificate in DER format (x509 v3), header length: 4, sequence length: 1149
12408 0x3078 LZMA compressed data, properties: 0x5D, dictionary size: 16777216 bytes, uncompressed size: 487624 bytes
I am thinking that bytes 0...4487 is the real bootloader code, so:
Code:
> head --bytes=4488 img.abl_b > abc
> file abc
abc: ELF 32-bit LSB executable, ARM, version 1 (SYSV), statically linked, corrupted section header size
Not sure why it says "corrupt section header size".
Then check the detail of the ELF file:
Code:
> readelf abc
ELF Header:
Magic: 7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00
Class: ELF32
Data: 2's complement, little endian
Version: 1 (current)
OS/ABI: UNIX - System V
ABI Version: 0
Type: EXEC (Executable file)
Machine: ARM
Version: 0x1
Entry point address: 0x9fa00000
Start of program headers: 52 (bytes into file)
Start of section headers: 0 (bytes into file)
Flags: 0x0
Size of this header: 52 (bytes)
Size of program headers: 32 (bytes)
Number of program headers: 3
Size of section headers: 0 (bytes)
Number of section headers: 0
Section header string table index: 0
There are no sections in this file.
There are no sections to group in this file.
Program Headers:
Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
NULL 0x000000 0x00000000 0x00000000 0x00094 0x00000 0
NULL 0x001000 0x9fa30000 0x9fa30000 0x01988 0x02000 0x1000
LOAD 0x003000 0x9fa00000 0x9fa00000 0x30000 0x30000 RWE 0x1000
There is no dynamic section in this file.
There are no relocations in this file.
Dynamic symbol information is not available for displaying symbols.
No version information found in this file.
Elf file type is EXEC (Executable file)
Entry point 0x9fa00000
There are 3 program headers, starting at offset 52
The bootloader binary code is in the LOAD segment
More to follow later ... have to catch some sleep now ...
foobar66 said:
This is WIP (work in progress) ... posting this as a separate thread to get other people involved so we can try to get rid of the annoying "Your device is corrupt" thing.
On the back of my thread on the splash screen (see https://forum.xda-developers.com/oneplus-6t/development/tool-splash-screen-modification-t3874158), @AnoopKumar and I started checking the bootloader.
The bootloader is in the partition called: abl_a (and/or abl_b) depending on whether you boot from A or B slot.
(https://forum.xda-developers.com/showpost.php?p=78409574&postcount=28)
All below is on Linux ... I am not a Windows guru ...
Take a raw dump of the abl_a partition. Reboot into TWRP, once there do: "adb shell".
You will now have the dump of the bootloader partition in the file
Then, use "binwalk" to see what is inside the abl_a image:
I am thinking that bytes 0...4487 is the real bootloader code, so:
Not sure why it says "corrupt section header size".
Then check the detail of the ELF file:
The bootloader binary code is in the LOAD segment
More to follow later ... have to catch some sleep now ...
Click to expand...
Click to collapse
Wow! Excited to see this! Thanks
It doesn't matter if you find it.
I don't think you can flash a modified BL partition and have the device boot.
This is part of secure boot. The notice will always be there with an unlocked BL.
It's on all devices that have ARM trust zone and secure boot, if they run Android.
This is part of Google's requirements.
foobar66 said:
This is WIP (work in progress) ... posting this as a separate thread to get other people involved so we can try to get rid of the annoying "Your device is corrupt" thing.
On the back of my thread on the splash screen (see https://forum.xda-developers.com/oneplus-6t/development/tool-splash-screen-modification-t3874158), @AnoopKumar and I started checking the bootloader.
The bootloader is in the partition called: abl_a (and/or abl_b) depending on whether you boot from A or B slot.
(https://forum.xda-developers.com/showpost.php?p=78409574&postcount=28)
All below is on Linux ... I am not a Windows guru ...
Take a raw dump of the abl_a partition. Reboot into TWRP, once there do: "adb shell".
Code:
> adb shell
# dd if=/dev/block/bootdevice/by-name/abl_b of=/sdcard/img.abl_a
# <ctrl-D>
> adb pull /sdcard/img.abl_a
You will now have the dump of the bootloader partition in the file
Then, use "binwalk" to see what is inside the abl_a image:
Code:
> binwalk -e img.abl_a
DECIMAL HEXADECIMAL DESCRIPTION
--------------------------------------------------------------------------------
0 0x0 ELF, 32-bit LSB executable, ARM, version 1 (SYSV)
4488 0x1188 Certificate in DER format (x509 v3), header length: 4, sequence length: 1279
5771 0x168B Certificate in DER format (x509 v3), header length: 4, sequence length: 1133
6908 0x1AFC Certificate in DER format (x509 v3), header length: 4, sequence length: 1149
12408 0x3078 LZMA compressed data, properties: 0x5D, dictionary size: 16777216 bytes, uncompressed size: 487624 bytes
I am thinking that bytes 0...4487 is the real bootloader code, so:
Code:
> head --bytes=4488 img.abl_b > abc
> file abc
abc: ELF 32-bit LSB executable, ARM, version 1 (SYSV), statically linked, corrupted section header size
Not sure why it says "corrupt section header size".
Then check the detail of the ELF file:
Code:
> readelf abc
ELF Header:
Magic: 7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00
Class: ELF32
Data: 2's complement, little endian
Version: 1 (current)
OS/ABI: UNIX - System V
ABI Version: 0
Type: EXEC (Executable file)
Machine: ARM
Version: 0x1
Entry point address: 0x9fa00000
Start of program headers: 52 (bytes into file)
Start of section headers: 0 (bytes into file)
Flags: 0x0
Size of this header: 52 (bytes)
Size of program headers: 32 (bytes)
Number of program headers: 3
Size of section headers: 0 (bytes)
Number of section headers: 0
Section header string table index: 0
There are no sections in this file.
There are no sections to group in this file.
Program Headers:
Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
NULL 0x000000 0x00000000 0x00000000 0x00094 0x00000 0
NULL 0x001000 0x9fa30000 0x9fa30000 0x01988 0x02000 0x1000
LOAD 0x003000 0x9fa00000 0x9fa00000 0x30000 0x30000 RWE 0x1000
There is no dynamic section in this file.
There are no relocations in this file.
Dynamic symbol information is not available for displaying symbols.
No version information found in this file.
Elf file type is EXEC (Executable file)
Entry point 0x9fa00000
There are 3 program headers, starting at offset 52
The bootloader binary code is in the LOAD segment
More to follow later ... have to catch some sleep now ...
Click to expand...
Click to collapse
Good job, if needed i can help with the checking
tech_head said:
It doesn't matter if you find it.
I don't think you can flash a modified BL partition and have the device boot.
This is part of secure boot. The notice will always be there with an unlocked BL.
It's on all devices that have ARM trust zone and secure boot, if they run Android.
This is part of Google's requirements.
Click to expand...
Click to collapse
abl.img is not the bootloader i guess.
tech_head said:
It doesn't matter if you find it.
I don't think you can flash a modified BL partition and have the device boot.
This is part of secure boot. The notice will always be there with an unlocked BL.
It's on all devices that have ARM trust zone and secure boot, if they run Android.
This is part of Google's requirements.
Click to expand...
Click to collapse
On other devices they've been able to swap this image with another one to "hide" the message, to "get rid of it".
Would we sweet if we could get rid of the unlocked bootloader message too.
dennisbednarz said:
Would we sweet if we could get rid of the unlocked bootloader message too.
Click to expand...
Click to collapse
+1
U guys should talk [email protected] We had this issue of broken verity with the essential phone and he came up with a redboot.img that u flash and it bootloops the phone and fixes verity. It keeps bootlooping till.it fixes it, then u flash a proper kernel and you are good. Cuz as It stands one can only resolve this properly with the tool
jacksummers said:
U guys should talk [email protected] We had this issue of broken verity with the essential phone and he came up with a redboot.img that u flash and it bootloops the phone and fixes verity. It keeps bootlooping till.it fixes it, then u flash a proper kernel and you are good. Cuz as It stands one can only resolve this properly with the tool
Click to expand...
Click to collapse
Different issue.
They are not trying to get rid of the red warning but the yellow warning for an unlocked BL.
On this phone, if you have a "red" warning you use the MSMDownload tool and go back factory including locking the BL.
This is a different case.
Well ... bad luck ... I tried to change abl_b and reflash it ... phone is sort of *dead* now.
Does no longer boot at all.
However, when I plug it into the PC, I can see:
Code:
> lsusb
Bus 001 Device 034: ID 05c6:9008 Qualcomm, Inc. Gobi Wireless Modem (QDL mode)
And then:
Code:
> dmesg
[ 9395.999112] usb 1-1: new high-speed USB device number 34 using xhci_hcd
[ 9396.149376] usb 1-1: New USB device found, idVendor=05c6, idProduct=9008
[ 9396.149380] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[ 9396.149383] usb 1-1: Product: QUSB_BULK_CID:0402_SN:33B9DDAC
[ 9396.149386] usb 1-1: Manufacturer: Qualcomm CDMA Technologies MSM
[ 9396.150184] qcserial 1-1:1.0: Qualcomm USB modem converter detected
[ 9396.150372] usb 1-1: Qualcomm USB modem converter now attached to ttyUSB0
So it is not completely *dead* but in some sort of Qualcomm low level mode. I found some info here: https://together.jolla.com/question...ss-modem-any-chance-to-bring-it-back-to-life/ but did not make any progress yet.
EDIT: looking at MsmDownloadTool to debrick the phone ...
foobar66 said:
Well ... bad luck ... I tried to change abl_b and reflash it ... phone is sort of *dead* now.
Does no longer boot at all.
However, when I plug it into the PC, I can see:
Code:
> lsusb
Bus 001 Device 034: ID 05c6:9008 Qualcomm, Inc. Gobi Wireless Modem (QDL mode)
And then:
Code:
> dmesg
[ 9395.999112] usb 1-1: new high-speed USB device number 34 using xhci_hcd
[ 9396.149376] usb 1-1: New USB device found, idVendor=05c6, idProduct=9008
[ 9396.149380] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[ 9396.149383] usb 1-1: Product: QUSB_BULK_CID:0402_SN:33B9DDAC
[ 9396.149386] usb 1-1: Manufacturer: Qualcomm CDMA Technologies MSM
[ 9396.150184] qcserial 1-1:1.0: Qualcomm USB modem converter detected
[ 9396.150372] usb 1-1: Qualcomm USB modem converter now attached to ttyUSB0
So it is not completely *dead* but in some sort of Qualcomm low level mode. I found some info here: https://together.jolla.com/question...ss-modem-any-chance-to-bring-it-back-to-life/ but did not make any progress yet.
EDIT: looking at MsmDownloadTool to debrick the phone ...
Click to expand...
Click to collapse
Use this https://forum.xda-developers.com/oneplus-6t/how-to/tool-6t-msmdownloadtool-v4-0-oos-9-0-5-t3867448
Should try for several times with instruction here
Question - when does device show red warning? When u disable dm verity?
I unlocked and rooted but only had yellow warning, but when i installed aosp gsi i had a red warning. Once of the step to install the rom was flashing vbmeta and disabling dm verity.
patelparth120595 said:
Question - when does device show red warning? When u disable dm verity?
I unlocked and rooted but only had yellow warning, but when i installed aosp gsi i had a red warning. Once of the step to install the rom was flashing vbmeta and disabling dm verity.
Click to expand...
Click to collapse
Disabled dm-verity caused red warning, i guess.
---------- Post added at 10:01 AM ---------- Previous post was at 09:58 AM ----------
foobar66 said:
Well ... bad luck ... I tried to change abl_b and reflash it ... phone is sort of *dead* now.
Does no longer boot at all.
However, when I plug it into the PC, I can see:
And then:
So it is not completely *dead* but in some sort of Qualcomm low level mode. I found some info here: https://together.jolla.com/question...ss-modem-any-chance-to-bring-it-back-to-life/ but did not make any progress yet.
EDIT: looking at MsmDownloadTool to debrick the phone ...
Click to expand...
Click to collapse
Edited abl.img ? and flashed via recovery/fastboot ?
AnoopKumar said:
Edited abl.img ? and flashed via recovery/fastboot ?
Click to expand...
Click to collapse
No, just flashed using dd command in TWRP shell.
foobar66 said:
No, just flashed using dd command in TWRP shell.
Click to expand...
Click to collapse
Phone still dead ?
OK ... I managed to recover my phone !
A windows PC with the MSM program did the trick.
I am now back to stock 9.0.5
foobar66 said:
OK ... I managed to recover my phone !
A windows PC with the MSM program did the trick.
I am now back to stock 9.0.5
Click to expand...
Click to collapse
I assume that, there is nothing to do with the abl.img. Only thing we can do with it is change the default strings to a song lyric or something. abl.img is the uefi firmware i guess. Bootloader is using the images stored in the logo partition.
Gsi's flash without breaking verity if u flash to both slots. And totally format. Fastboot -w. The phone sees any changes to partitions as corruption and breaks verity, hence red warning.. if someone would be inclined to talk to invisiblek from the essential threads, he could tell u of a fix. The solution is not in abl. It's in the stock boot.img. if I had more time, I would help
---------- Post added at 02:52 PM ---------- Previous post was at 02:51 PM ----------
tech_head said:
Different issue.
They are not trying to get rid of the red warning but the yellow warning for an unlocked BL.
On this phone, if you have a "red" warning you use the MSMDownload tool and go back factory including locking the BL.
This is a different case.
Click to expand...
Click to collapse
No, they are talking about breaking verity also. Seems to be both messages, but more recently the broken verity message. Which there is two types, one u can boot from, one u cannot.
jacksummers said:
U guys should talk [email protected] We had this issue of broken verity with the essential phone and he came up with a redboot.img that u flash and it bootloops the phone and fixes verity. It keeps bootlooping till.it fixes it, then u flash a proper kernel and you are good. Cuz as It stands one can only resolve this properly with the tool
Click to expand...
Click to collapse
I would love that idea. That would be really nice to have on our device
So many Thank for : Android Root Team
Code:
https://github.com/AndroidRoot
So many Thank for: Jevinskie
Code:
https://github.com/jevinskie
My github
Code:
https://github.com/GeorgeMato4/nvcrypttools/tree/forN7
required: Use linux based OS.!!!!
First time:
To make your encrypted blob for your Tegra3 Device ( Nexus7/tf201/tf300/tf700) you need another working tegra3 Device.
I am sorry for that, but i was going with easys possible way. I will solve this, but not now.
But, when you give me information (sbk and cpuid) , i will try create blob for you. And , if will be your device restored, please, help others with same problem.
How get sbk from your bricked device?
Download from Jevinskie Github page source code.
Code:
https://github.com/jevinskie/fusee-launcher
Unzip and make it. (Open in folder with source code command line and type “make” )
It is need install pyusb with command “pip install pyusb”.
It is need connected device to usb v3.
Check if is device in apx mode with command “lsusb”. In list must be Nvidia corp.
Run Command on sudo “./fusee-launcher.py –tty dump-sbk-via-usb.bin”
You get something like this:
Code:
05f4a5d01'
Stack snapshot: b'0000000000000000100000003c9f0040'
EndpointStatus_stack_addr: 0x40009f3c
ProcessSetupPacket SP: 0x40009f30
InnerMemcpy LR stack addr: 0x40009f20
overwrite_len: 0x00004f20
overwrite_payload_off: 0x00004de0
payload_first_length: 0x00004de0
overwrite_payload_off: 0x00004de0
payload_second_length: 0x0000c7b0
b'00a0004000300040e04d0000b0c70000'
Setting rcm msg size to 0x00030064
RCM payload (len_insecure): b'64000300'
Setting ourselves up to smash the stack...
Payload offset of intermezzo: 0x00000074
overwrite_payload_off: 0x00004de0
overwrite_len: 0x00004f20
payload_overwrite_len: 0x00004e5c
overwrite_payload_off: 0x00004de0
smash_padding: 0x00000000
overwrite_payload_off: 0x00004de0
Uploading payload...
txing 73728 bytes total
txing 4096 bytes (0 already sent) to buf[0] 0x40003000
txing 4096 bytes (4096 already sent) to buf[1] 0x40005000
txing 4096 bytes (8192 already sent) to buf[0] 0x40003000
txing 4096 bytes (12288 already sent) to buf[1] 0x40005000
txing 4096 bytes (16384 already sent) to buf[0] 0x40003000
txing 4096 bytes (20480 already sent) to buf[1] 0x40005000
txing 4096 bytes (24576 already sent) to buf[0] 0x40003000
txing 4096 bytes (28672 already sent) to buf[1] 0x40005000
txing 4096 bytes (32768 already sent) to buf[0] 0x40003000
txing 4096 bytes (36864 already sent) to buf[1] 0x40005000
txing 4096 bytes (40960 already sent) to buf[0] 0x40003000
txing 4096 bytes (45056 already sent) to buf[1] 0x40005000
txing 4096 bytes (49152 already sent) to buf[0] 0x40003000
txing 4096 bytes (53248 already sent) to buf[1] 0x40005000
txing 4096 bytes (57344 already sent) to buf[0] 0x40003000
txing 4096 bytes (61440 already sent) to buf[1] 0x40005000
txing 4096 bytes (65536 already sent) to buf[0] 0x40003000
txing 4096 bytes (69632 already sent) to buf[1] 0x40005000
txing 4096 bytes total
txing 4096 bytes (0 already sent) to buf[0] 0x40003000
Smashing the stack...
sending status request with length 0x00004f20
The USB device stopped responding-- sure smells like we've smashed its stack. :)
Launch complete!
b'4445414442454546'
DEADBEEF
b'3030303030303030'
00000000
b'3030303030303030'
00000000
b'3034303030303930'
04000090
b'4634314330433241'
F41C0C2A
b'3133333731333337'
13371337
b'3535353535353535'
55555555
b'3430303033303030'
40003000
b'3430303035303030'
40005000
b'4141414141414141'
AAAAAAAA
b'3131313131313131'
11111111
b'3030303030303236'
00000026
b'3232323232323232'
22222222
b'68656c6c6f2c20776f726c640a00'
hello, world
b'e57de3bab6cb499d874d5772cb219f0101042c20' (This is SBK)
Traceback (most recent call last):
File "./fusee-launcher.py", line 823, in <module>
buf = switch.read(USB_XFER_MAX)
File "./fusee-launcher.py", line 530, in read
return self.backend.read(length)
File "./fusee-launcher.py", line 134, in read
return bytes(self.dev.read(0x81, length, 3000))
File "/usr/local/lib/python3.6/dist-packages/usb/core.py", line 988, in read
self.__get_timeout(timeout))
File "/usr/local/lib/python3.6/dist-packages/usb/_debug.py", line 60, in do_trace
return f(*args, **named_args)
File "/usr/local/lib/python3.6/dist-packages/usb/backend/libusb1.py", line 833, in bulk_read
timeout)
File "/usr/local/lib/python3.6/dist-packages/usb/backend/libusb1.py", line 936, in __read
_check(retval)
File "/usr/local/lib/python3.6/dist-packages/usb/backend/libusb1.py", line 595, in _check
raise USBError(_strerror(ret), ret, _libusb_errno[ret])
usb.core.USBError: [Errno 110] Operation timed out
You need this two number: Tegra with Device ID: b'01042c205f4a5d01
and
hello, world
b'e57de3bab6cb499d874d5772cb219f0101042c20'. This is not real sbk.
Sbk have only 32 number. Your sbk is only “e57de3bab6cb499d874d5772cb219f” and after this number is first 8 number from tegra device id.
Congratulation, you get sbk.
I test dump-sbk-via-usb on nexus 7 and on asus TF300. I thing this will work on other device.
How get chip id?
Download wheelei from this page:
Code:
https://github.com/AndroidRoot/androidroot.github.io/tree/master/download
and download some bad blob.bin or my blank blob.bin
Reboot your device and connect to your pc. Check if is this on apx mode with command “lsusb”.
With sudo run “./wheelie --blob blob.bin ”
You get cpu id and 0x4 error (bad blob format).
Format cpu id for grouper is like this 0x15d4a5f202c0401
Chip id is 015d4a5f202c0401.
Tegra Id from dump-sbk-via-usb is cpu id, but on bad format. 01042c205f4a5d01 vs 015d4a5f202c0401.
I have another Tegra3 device: How build blob?
Try my precompiled mknvfblob. Download from :
Code:
https://github.com/GeorgeMato4/nvcrypttools/tree/forN7/precompiled
precompiledN7 is for Nexus,
precompiledCardhu is for other device.
Type:
mkdir /AndroidRoot
cat /proc/cpuinfo > /AndroidRoot/cpuinfo
Cpuinfo file look like this:
Code:
Processor : ARMv7 Processor rev 9 (v7l)
processor : 0
BogoMIPS : 1993.93
processor : 1
BogoMIPS : 1993.93
processor : 2
BogoMIPS : 1993.93
processor : 3
BogoMIPS : 1993.93
Features : swp half thumb fastmult vfp edsp neon vfpv3 tls
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x2
CPU part : 0xc09
CPU revision : 9
Hardware : grouper
Revision : 0000
Serial : 015d4a5f202c0401
Where Hardware is type of chip-set, can be grouper (for Nexus 7 2012) or cardhu (for TF 201/300/700) and serial is chip id. Change this number with your chip id.
Now, untar my precompilated mknvfblob.
From
Code:
https://github.com/GeorgeMato4/nvcrypttools/tree/forN7/bct
download btc file for your device
Code:
https://github.com/GeorgeMato4/nvcrypttools/tree/forN7/bootloaders
download bootloader.xbt for your device
and take this files to AndroidRoot folder.
If you have on your device working linux, type :
./mknvfblob -W -K e57de3bab6cb499d874d5772cb219f01 --blob /AndroidRoot/test.blob --bctin /AndroidRoot/testa.bct --bctr /AndroidRoot/testr.bct --bctc /AndroidRoot/testc.bct --blin /AndroidRoot/bootloader.blob.XBT --blout /AndroidRoot/test.ebt
Where: e57de3bab6cb499d874d5772cb219f01 is your bsk
testa.bct is your bct.
bootloader.blob.XBT is your bootloader bct.
If you have android, use adb shell command.
how this work?
When you use blob.bin (test.blob) with “./wheelie --blob blob.bin ”
You get error 3 reciever.
But this is not problem.
Run command with sudo:
./nvflash --btc testr.bct --ebt test.ebt --blob test.blob --go
after run this, restore bootloader.
./nvflash --resrore --download 4 bootloader.img --go
Where number 4 is partition with bootloader and bootloadr.img is bootloader for your device.
Helppp, im keep getting this problem
log:
Code:
Traceback (most recent call last):
File "./fusee-launcher.py", line 692, in <module>
pid=arguments.pid, os_override=arguments.platform, override_checks=arguments.skip_checks)
File "./fusee-launcher.py", line 490, in __init__
self.dev = self._find_device(vid, pid)
File "./fusee-launcher.py", line 526, in _find_device
return self.backend.find_device(vid, pid)
File "./fusee-launcher.py", line 156, in find_device
import usb
ImportError: No module named 'usb'
edit: nvm fix it
when i do "lsusb" it show nothing, help!
edit: nvm fix this too
enderzip said:
when i do "lsusb" it show nothing, help!
Click to expand...
Click to collapse
lsusb show command not found ?
Then try command sudo apt-get install usbutils
and try lsusb again
or
Nvidia Corp is not in list ?
Then you not start on apx mode.
power button + volume up.
or
Do you install pyusb with command : pip install pyusb ?
try use command: pip3 install pyusb.
Jirmd said:
lsusb show command not found ?
Then try command sudo apt-get install usbutils
and try lsusb again
or
Nvidia Corp is not in list ?
Then you not start on apx mode.
power button + volume up.
or
Do you install pyusb with command : pip install pyusb ?
try use command: pip3 install pyusb.
Click to expand...
Click to collapse
"pip3 install pyusb" didnt work. This is all it show:
Code:
fusee-launcher-n7$: lsusb
fusee-launcher-n7$:
What OS are you using to unbrick Tegra 3? Linux or Windows?
edit: fix it
ok after spending a day trying to dump sbk, i finnaly did it.
First, you need to have ubuntu. WINDOWS WILL NOT WORK. Make a bootable ubuntu usb and live boot it or install it
Second, open temernial inside of the fusee-launcher-n7 folder
Thirdly, type: sudo apt-get install python-usb python3-usb. If it say cant locate package, open Software and Update and check the 4 first box
Lastly, type: pip install pyusb
After that, type: sudo ./fusee-launcher.py --tty dump-sbk-via-usb.bin and you are good to go
enderzip said:
ok after spending a day trying to dump sbk, i finnaly did it.
First, you need to have ubuntu. WINDOWS WILL NOT WORK. Make a bootable ubuntu usb and live boot it or install it
Second, open temernial inside of the fusee-launcher-n7 folder
Thirdly, type: sudo apt-get install python-usb python3-usb. If it say cant locate package, open Software and Update and check the 4 first box
Lastly, type: pip install pyusb
After that, type: sudo ./fusee-launcher.py --tty dump-sbk-via-usb.bin and you are good to go
Click to expand...
Click to collapse
Im so sorry, I forget to write this first. I use debian based os more than 10 years. I forgot then exist something like windows.
I will edit my first post.
im not getting error 3 receiver in nvflash it just stuck at sending file 100%
but my nexus 7 display a GOOGLE LOGO!!! with the "battery is too low" text on the upper left corner
idk what to do next
am i suppose to use the ./nvflash.exe command instead of the wheelie.exe one?
your guide is so confuse
---------- Post added at 04:38 AM ---------- Previous post was at 04:25 AM ----------
now im stuck on "waiting for bootloader to initialize" after the ./nvflash --bct command
Code:
[email protected]:/mnt/c/Users/EnderZip/Desktop/Nexus 7 recovery stuffs/ehr$ sudo ./nvflash.exe --bct testr.bct -
-bl test.ebt --blob test.blob --go
[sudo] password for enderzip:
Nvflash v1.13.87205 started
Using blob v1.13.00000ommon½╣·┌√¬
chip uid from BR is: 0x0000000000000000015d2bc2ad43f602
rcm version 0X30001
System Information:
chip name: unknown
chip id: 0x30 major: 1 minor: 3
chip sku: 0x83
chip uid: 0x0000000000000000015d2bc2ad43f602
macrovision: disabled
hdcp: enabled
jtag: disabled
sbk burned: true
dk burned: true
boot device: emmc
operating mode: 4
device config strap: 1
device config fuse: 17
sdram config strap: 1
downloading bootloader -- load address: 0x80108000 entry point: 0x80108000
sending file: test.ebt
- 2146896/2146896 bytes sent
test.ebt sent successfully
waiting for bootloader to initialize
I write something about error 3 on wheelie, for people, who want start nvflash sessions with wheelie (like nvflash preloader) . This mean for people who know quide for wheelie and nvflash from AndroidRoot team. But how i see, it is not real good idea. If you want, write your own nvflash guide.
Jirmd said:
I write something about error 3 on wheelie, for people, who want start nvflash sessions with wheelie (like nvflash preloader) . This mean for people who know quide for wheelie and nvflash from AndroidRoot team. But how i see, it is not real good idea. If you want, write your own nvflash guide.
Click to expand...
Click to collapse
what? so im meant to get that error 3?
Hello @Jirmd I have an issue with your post...it is very well explained but i cannot create the blob.bin for my 32Gb Nexus 7 , because i do not have a working tegra to get the cat/proc/cpu info and i cannot run the mknvfblob command it gives me and error that cannot execute, maybe because i am missing some files. Like the test.blob testa.blob testr.blob If I paste you the sbk and CPU ID will you please create a blob for my N7?
Found a Tegra with Device ID: b'1710282806495d01'
Hello World
b'87e2b3998fc0483c86931785736d7cbe17102828'
SBK 87e2b3998fc0483c86931785736d7cbe
CHIP ID 015d490628281017
Paste you this completely so i make sure it is correct.
Many Thanks
in list Nvidia corp.
Run Command on
sudo ./fusee-launcher.py --tty dump-sbk-via-usb.bin
Invalid payload path specified!
help me...
Enplat said:
in list Nvidia corp.
Run Command on
sudo ./fusee-launcher.py --tty dump-sbk-via-usb.bin
Invalid payload path specified!
help me...
Click to expand...
Click to collapse
You need to download the COMPLETE fusee launcher from github. Install python 3 via adb. Run the make command. Then install the pip command thingy. And run the command sudo ./fusee...bla...bla from the folder where fusee is located on your system.
The_Pacifier said:
You need to download the COMPLETE fusee launcher from github. Install python 3 via adb. Run the make command. Then install the pip command thingy. And run the command sudo ./fusee...bla...bla from the folder where fusee is located on your system.
Click to expand...
Click to collapse
Code:
[email protected]:~/Downloads/fusee-launcher-n7$ sudo apt-get install python-usb python3-usb
[sudo] password for enplat:
Reading package lists... Done
Building dependency tree
Reading state information... Done
python-usb is already the newest version (1.0.0-1).
python3-usb is already the newest version (1.0.0-1).
0 to upgrade, 0 to newly install, 0 to remove and 42 not to upgrade.
[email protected]:~/Downloads/fusee-launcher-n7$ pip install pyusb
Collecting pyusb
Installing collected packages: pyusb
Successfully installed pyusb-1.0.2
[email protected]:~/Downloads/fusee-launcher-n7$ lsusb
Bus 001 Device 004: ID 058f:6361 Alcor Micro Corp. Multimedia Card Reader
Bus 001 Device 003: ID 04e8:6860 Samsung Electronics Co., Ltd Galaxy (MTP)
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 002 Device 002: ID 0a5f:0157 Zebra
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 007 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 006 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 005 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 004 Device 004: ID 04b4:0510 Cypress Semiconductor Corp.
Bus 004 Device 019: ID 0955:7330 NVidia Corp.
Bus 004 Device 003: ID 05e3:0608 Genesys Logic, Inc. Hub
Bus 004 Device 002: ID 04a9:2737 Canon, Inc. MF4410
Bus 004 Device 012: ID 058f:6362 Alcor Micro Corp. Flash Card Reader/Writer
Bus 004 Device 008: ID 045e:07a5 Microsoft Corp. Wireless Receiver 1461C
Bus 004 Device 011: ID 0a12:0001 Cambridge Silicon Radio, Ltd Bluetooth Dongle (HCI mode)
Bus 004 Device 009: ID 1516:8628 CompUSA Pen Drive
Bus 004 Device 006: ID 05e3:0608 Genesys Logic, Inc. Hub
Bus 004 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
[email protected]:~/Downloads/fusee-launcher-n7$ sudo ./fusee-launcher.py --tty dump-sbk-via-usb.bin
Invalid payload path specified!
[email protected]:~/Downloads/fusee-launcher-n7$
I already did it.....
Enplat said:
Code:
[email protected]:~/Downloads/fusee-launcher-n7$ sudo apt-get install python-usb python3-usb
[sudo] password for enplat:
Reading package lists... Done
Building dependency tree
Reading state information... Done
python-usb is already the newest version (1.0.0-1).
python3-usb is already the newest version (1.0.0-1).
0 to upgrade, 0 to newly install, 0 to remove and 42 not to upgrade.
[email protected]:~/Downloads/fusee-launcher-n7$ pip install pyusb
Collecting pyusb
Installing collected packages: pyusb
Successfully installed pyusb-1.0.2
[email protected]:~/Downloads/fusee-launcher-n7$ lsusb
Bus 001 Device 004: ID 058f:6361 Alcor Micro Corp. Multimedia Card Reader
Bus 001 Device 003: ID 04e8:6860 Samsung Electronics Co., Ltd Galaxy (MTP)
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 002 Device 002: ID 0a5f:0157 Zebra
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 007 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 006 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 005 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 004 Device 004: ID 04b4:0510 Cypress Semiconductor Corp.
Bus 004 Device 019: ID 0955:7330 NVidia Corp.
Bus 004 Device 003: ID 05e3:0608 Genesys Logic, Inc. Hub
Bus 004 Device 002: ID 04a9:2737 Canon, Inc. MF4410
Bus 004 Device 012: ID 058f:6362 Alcor Micro Corp. Flash Card Reader/Writer
Bus 004 Device 008: ID 045e:07a5 Microsoft Corp. Wireless Receiver 1461C
Bus 004 Device 011: ID 0a12:0001 Cambridge Silicon Radio, Ltd Bluetooth Dongle (HCI mode)
Bus 004 Device 009: ID 1516:8628 CompUSA Pen Drive
Bus 004 Device 006: ID 05e3:0608 Genesys Logic, Inc. Hub
Bus 004 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
[email protected]:~/Downloads/fusee-launcher-n7$ sudo ./fusee-launcher.py --tty dump-sbk-via-usb.bin
Invalid payload path specified!
[email protected]:~/Downloads/fusee-launcher-n7$
I already did it.....
Click to expand...
Click to collapse
[email protected]:/mnt/c/Users/EnderZip/Desktop/nexus 7 stuff lol/Nexus 7 recovery stuffs/fusee-launcher-n7/fusee-launcher-n7$ sudo ./fusee-launcher.py --tty dump-sbk-via-usb.bin
2020-04-11 16:44:07,350 INFO:usb.core:find(): using backend "usb.backend.libusb1"
No TegraRCM device found?
Click to expand...
Click to collapse
check for the dump-sbk-via-usb.bin file inside of your fusee-launcher folder
if there is no dump-sbk-via-usb.bin file inside of your folder, open a terminal inside of that folder then type: make
after done that type : pip install pyusb
then: sudo ./fusee-launcher.py --tty dump-sbk-via-usb.bin
and that might gonna solve your problem
I was going to say the same as Enderzip, i do not see the make command. You just need to type make in the fusee folder just the word make alone. Be sure you download ALL the folder from github, by just hitting the green Download button.
I am really sorry.
1. On GitHub, I downloaded it and extracted it. (by just hitting the green Download button)
2. I ran the terminal from that folder and entered the make command
[email protected]:~/Downloads/fusee-launcher-n7$ make
arm-none-eabi-gcc -mtune=arm7tdmi -mlittle-endian -fno-stack-protector -fno-common -fno-builtin -ffreestanding -std=gnu99 -Werror -Wall -Wno-error=unused-function -fomit-frame-pointer -g -Os -DENTRY_POINT_ADDRESS=0x4000A000 intermezzo.S -c -o intermezzo.o
make: arm-none-eabi-gcc: Command not found
Makefile:38: recipe for target 'intermezzo.o' failed
make: *** [intermezzo.o] Error 127
Am I doing something wrong?
I say thank you.....
Enplat said:
I am really sorry.
1. On GitHub, I downloaded it and extracted it. (by just hitting the green Download button)
2. I ran the terminal from that folder and entered the make command
[email protected]:~/Downloads/fusee-launcher-n7$ make
arm-none-eabi-gcc -mtune=arm7tdmi -mlittle-endian -fno-stack-protector -fno-common -fno-builtin -ffreestanding -std=gnu99 -Werror -Wall -Wno-error=unused-function -fomit-frame-pointer -g -Os -DENTRY_POINT_ADDRESS=0x4000A000 intermezzo.S -c -o intermezzo.o
make: arm-none-eabi-gcc: Command not found
Makefile:38: recipe for target 'intermezzo.o' failed
make: *** [intermezzo.o] Error 127
Am I doing something wrong?
I say thank you.....
Click to expand...
Click to collapse
Try my already maked fusee-launcher
You may have to install pip using: pip install pyusb
enderzip said:
Try my already maked fusee-launcher
You may have to install pip using: pip install pyusb
Click to expand...
Click to collapse
thank you enderzip. im back from hospital now. so, i will solve your request for encrypted blob. please, send me your email address on pm. enderzip will write new tutorial for unbrick.