Pmbootstrap: flash_kernel fails to flash RECOVERY using heimdall (samsung-s7562)

[cmdr2]

Hi,

Device: Samsung S7562

After ./pmbootstrap install, running ./pmbootstrap flasher flash_kernel results in heimdall failing with:

Uploading RECOVERY
100% 
ERROR: Failed to confirm end of file transfer sequence!
ERROR: RECOVERY upload failed!

To test that heimdall works, I tried flashing the original recovery.img (that I had dd-ed previously) using sudo heimdall flash --RECOVERY recovery.img and that flashed and booted fine. Then I tried sudo heimdall flash --RECOVERY /tmp/initramfs.lzo and that failed with the same error.

From what I understand, the flash_kernel step is asking heimdall to flash /tmp/initramfs.lzo, which isn't recognized by abootimg as a valid boot image. So I wonder whether my phone's download mode is refusing to flash a non-boot image file?

I was considering packing the kernel and initramfs into a custom boot image and flashing that to recovery, would that even work?

Apologies if I'm missing something obvious!

Cheers

~cmdr2

[ollieparanoid]

Thank you for the detailed bug report!

The heimdall authors reverse engineered the whole flashing process from the Windows program "odin" from Samsung, and it isn't perfect and fails sometimes. But it works in 4/5 cases or so for me. Could you just try it again?

More ideas:

• in the i9070 and i9100 we can (only!) flash non-boot.img files. you could use the command file to check if the dd'd image you have is actually in boot.img format, or what format it has (please post the result)
• maybe the initramfs.lzo is simply too big? please post the file size of both files.

[cmdr2]

Thanks!

/tmp/initramfs.lzo is 3.7M, and recovery.bin is 12M (this is the original recovery that was dd-ed)

Output of file checks:

$ file recovery.bin
recovery.bin: Android bootimg, kernel (0x208000), ramdisk (0x1500000), page size: 4096, cmdline (console = ttyHSL0, 115200,n8 andriodboot.hardware=qcom)

$ file /tmp/initramfs.lzo 
/tmp/initramfs.lzo: lzop compressed data - version 1.010, LZO1X-1, os: Unix

Also, for reference I unpacked recovery.bin using abootimg:

$ abootimg -x recovery.bin 
writing boot image config in bootimg.cfg
extracting kernel in zImage
extracting ramdisk in initrd.img

$ file initrd.img 
initrd.img: gzip compressed data, max compression, from Unix

$ file zImage 
zImage: Linux kernel ARM boot executable zImage (little-endian)

I don't know too much about how pmOS boots up, but what would happen if I pack the new kernel and new initramfs and flash the combined image directly to KERNEL? Can the recovery flashing step be bypassed entirely?

For e.g., I built a boot image from the generated pmOS initramfs and vmlinuz:

$ abootimg -u boot.img -k vmlinuz-samsung-s7562 -r initramfs-samsung-s7562 
reading kernel from vmlinuz-samsung-s7562
reading ramdisk from initramfs-samsung-s7562
Writing Boot Image boot.img

I confirmed that the generated initramfs and kernel are of the same binary format as the original (i.e. initramfs can be unpacked using gunzip -c | cpio -i like the initrd extracted from the original boot.img, and the description from file on vmlinuz is identical to the zImage from the original boot.img).

So if I flash this using --KERNEL, and then flash the system image, is that likely to work? I can give this a try later, thought I'd run it by you for an initial sanity check.

[drebrez]

So if I flash this using --KERNEL, and then flash the system image, is that likely to work?

Seems the correct way, it should be the same process that pmbootstrap uses for the fastboot mode.

@ollieparanoid We will need a way to configure the heimdall flasher to switch between the two cases.

[ollieparanoid]

@drebrez: Yep, you are right! We could split up the deviceinfo_flash_methods from heimdall into
heimdall-bootimg and heimdall-isorec ("isolated recovery", which we are doing now for i9070 and i9100)

@cmdr2: The way you have generated your boot.img file should work :+1:

I suggest testing this first, and then automatizing the generation of the boot.img file by postmarketos-mkinitfs in the following way:

• Set deviceinfo_generate_bootimg to "true"
• Extract the deviceinfo_flash_offset_* information from your existing boot.img file, as described here and add it to your deviceinfo
• Add mkbootimg as dependency in your device-... package's APKBUILD.
• Run pmbootstrap initfs, it should generate the boot.img file for you now.
• Until we patch the flashing code, that it will work with pmbootstrap flasher flash_kernel, you could flash that generated image manually. (mkdir /tmp/pmOS && pmbootstrap flasher export /tmp/pmOS gives you a convenience symlink)

[cmdr2]

Thanks @drebrez, that worked. The initramfs and kernel got packed into a boot.img (using abootimg), and flashed successfully using heimdall.

For reference, the boot partition on Samsung S7562 is called APPS. (yes, that's weird, but true. I verified by flashing back the original boot.img with a modified splash logo picture, and also others with this phone have the same PIT output).

$ sudo heimdall flash --APPS boot.img

I see that the latest heimdall flashing script in pmbootstrap allows configurable partition names, so the device-specific partition name can be used. :)

In the context of this issue, I'm unblocked.

Off-topic: pmOS starts up (more like limps up - blind without graphics, telnet works, but ssh throws an error after successful authentication, etc). Also, the generated kernel didn't boot, so I packed the original kernel with the new initramfs to make it boot up. So tonnes of work for this weekend. :)

[cmdr2]

Thanks @ollieparanoid, I saw your message after posting above. The device got flashed successfully using abootimg and heimdall, but would you like me to test the steps you described above?

[ollieparanoid]

@cmdr2: Great to hear, that you got it to boot! If you can spare the time, it would be awesome if you could follow the steps (especially for when your device gets included in the normal code tree).

It could be, that your kernel didn't boot because of the missing appended dtb file (as described in the porting guide).

[cmdr2]

@ollieparanoid Sure, will try out the steps.

Re: dtb, extract-dtb said no dtbs were appended to the original zImage, so I don't know if that's the problem. My current suspicion is that the defconfig is wrong, because while building I didn't find an exactly matching defconfig file for 'kyleopen' (which is supposed to be the model name, but that itself is also not 100% certain). So I had decided to try kyle02_defconfig on a weak hunch since that was among the few files edited in that repo. I wonder if a defconfig can be extracted from a pre-built zImage.

Edit: Sorry, I don't mean to hijack this github issue for unrelated discussion, but I did manage to extract /proc/config.gz out of pmOS (which was running the original kernel). I don't know too much about defconfigs, but it looks legit - https://pastebin.com/raw/SfTQxZNj

[ollieparanoid]

Closing, the Heimdall split part is in a new issue: #212.