Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Hisense U6H - magiskinit fails b/c bootloader adds skip_initramfs on 2SI device #8063

Closed
latelylk opened this issue May 19, 2024 · 4 comments · Fixed by #8337
Closed

Hisense U6H - magiskinit fails b/c bootloader adds skip_initramfs on 2SI device #8063

latelylk opened this issue May 19, 2024 · 4 comments · Fixed by #8337
Labels
stale No response for a long time

Comments

@latelylk
Copy link

Device: Hisense U6H
Android version: 11
Magisk version name: 81658d4
Magisk version code: 27002

In October 2023 I was successful in patching the boot image, but faced a black screen and no OS when trying to boot from it. The debug logs showed that Magisk was seeing skip_initramfs in the patched image of our 2SI device:

[ 5.742326] magiskinit: Device config:
[ 5.746102] magiskinit: skip_initramfs=[1]
[ 5.750236] magiskinit: force_normal_boot=[0]

Magisk normally patches skip_initramfs out of the boot image. At some point in the past devices (ex: Galaxy A21s) started having skip_initramfs added to the dtb bootargs. Magisk v24.0 fixed this by patching the dtb. Similar to how that issue presented, magiskinit treats the Hisense U6H as a Legacy SAR device because skip_initramfs is added by U-Boot (MBOOT).

Special thanks to @throwaway96 for finding this. Hisense adds skip_initramfs in the bootloader (0x274F108C):

void env_add_boot_skip_initramfs(void)
{
    const char boot_skip_initramfs[] = "skip_initramfs";
    env_add_bootargs(boot_skip_initramfs, boot_skip_initramfs);
}

it does this with a check in the do_readKL() function (0x274F1654):

// append command line.
if(strcmp(partition_name,"boot") == 0)
{
    env_add_boot_skip_initramfs();
}

Luckily with this understanding we can easily patch Magisk to achieve root:

Patching Magisk :) Prereqs: - [Magisk v27.0 Source](https://github.com/topjohnwu/Magisk/releases/tag/v27.0)* - Ability to compile Magisk
  1. Edit lines 85-87 of native/src/init/init.cpp from:
if (config.skip_initramfs)
  init = new LegacySARInit(argv, &config);
else if (config.force_normal_boot)

to:

/*if (config.skip_initramfs)
    init = new LegacySARInit(argv, &config);
else*/ if (config.force_normal_boot)
  1. That's it. Compile and use Magisk as normal. Have fun?

A similar issue to this was created when Galaxy A21s devices began including skip_initramfs in the dtb (xda, #4307). In that issue osm0sis stated:

Creating a device/board whitelist is not a proper solution

I'm not sure what Magisk can do to solve this without hardcoding for these devices. Patching the bootloader seems risky. Depending on how other devices are structured, can the order for checking skip_initramfs and force_normal_boot be swapped? Any other ideas?

Thank you :)

Quick reference:
Hisense U6H XDA Thread
Patching Magisk for Galaxy A21s XDA Thread
#4307

tl;dr Assumptions that Magisk makes should be correct, but the patches Hisense have applied to U-Boot make that not so

@latelylk latelylk changed the title Hisense U6H - magiskinit fails b/c bootloader passes skip_initramfs on 2SI device Hisense U6H - magiskinit fails b/c bootloader adds skip_initramfs on 2SI device May 19, 2024
@yujincheng08
Copy link
Collaborator

How about moving

else if (check_two_stage())
init = new FirstStageInit(argv, &config);

before

if (config.skip_initramfs)
init = new LegacySARInit(argv, &config);

But I dont know if this will break other devices.

@yujincheng08 yujincheng08 added the stale No response for a long time label Jun 13, 2024
@yujincheng08 yujincheng08 closed this as not planned Won't fix, can't repro, duplicate, stale Jun 13, 2024
@latelylk
Copy link
Author

latelylk commented Jul 2, 2024

Hi @yujincheng08 just checking whether this is truly "not planned" or if it was closed for being stale. I'll have a device on-hand again soon - am I able to re-open this or open a new issue when I am available to work on it?

@yujincheng08
Copy link
Collaborator

it was closed for being stale

@latelylk
Copy link
Author

latelylk commented Jul 2, 2024

Perfect. Thank you :)

@vvb2060 vvb2060 linked a pull request Aug 26, 2024 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
stale No response for a long time
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants