Root for Note Air 2?

[Renate]

It is empiracally proven that "fastboot boot x.img" is not always the same as "fastboot flash boot_x x.img", <reset>.
You've got backups and EDL, why not flash?
OTOH, why not get a robust recovery first?

[bazookajoe]

Originally Posted by Renate

It is empiracally proven that "fastboot boot x.img" is not always the same as "fastboot flash boot_x x.img", <reset>.
You've got backups and EDL, why not flash?
OTOH, why not get a robust recovery first?

Yes I know I can try flash or edl it. I'm building to that psychologically.

I'll look at your recovery today/on the weekend and start testing on that for you. I'm a little bit nervous without being able to use stock recovery if necessary because I have no volume buttons anywhere but I'm building up to it psychologically as well lol.

I do nevertheless still want to know how one can test the boot image before flashing it on this device. I know "fastboot boot boot.img" and "fastboot flash partitionname boot.img" do different things. I want to know why a boot test doesn't work on my Note Air 2 when Cascade94 has been able to do it here

Originally Posted by Cascade94

Testing & making permanent

1. Reboot in to fastboot mode - this'll take us to fastbootd (adb reboot fastboot)
2. Now go in to bootloader mode (fastboot reboot bootloader)
3. Now boot from your patched boot image (fastboot boot magisk_patched.img)
4. The device should power on normally. Open the Magisk app, check that Magisk has installed correctly...
5. If everything looks fine, select "Install", then select "Direct install" and wait for it to complete.
6. When you reboot, you should be still rooted - success!

See? They're testing to see if the boot image works and Magisk reads it. Now that's what I usually do for Leaf and also previous Android devices generally the only difference is I usually go back and fastboot flash rather than use Magisk to finish installing it like that. It's just what I'm used to doing.

Has something changed? Can other users still use that method to test but not me? Is my device brummy? If so, I've got a ticket open with Boox right now complaining about the delivery and I'll give them a mouthful if it's a weird one that doesn't properly respect fastboot because what you said about fastbootd makes me hella sussy. I'm not doing anything weird. I'm doing stuff that all of us do on the most basic level which if duplicated on my Leaf or Samsung devices it does what I expect it to do.

[Renate]

Well, here's one situation where "fastboot boot image" doesn't work.
If you are trying to check a recovery by "fastboot boot image" the system doesn't know offhand that it is a recovery.
A bunch of parameters are attached to the image by the cmdline (you can see this by "imgutil.exe /v image"):

console=ttyMSM0,115200,n8 androidboot.console=ttyMSM0 earlycon=msm_serial_dm,0xc170000 androidboot.hardware=qcom user_debug=31 msm_rtb.filter=0x37 ehci-hcd.park=3 lpm_levels.sleep_disabled=1 sched_enable_hmp=1 sched_enable_power_aware=1 service_locator.enable=1 swiotlb=1 loop.max_part=7 buildvariant=user veritykeyid=id:7e4333f9bba00adfe0ede979e28ed1920492b40

But, when the image gets started the system throws in a bunch more extra parameters (you can see this by "cat /proc/cmdline"):

rcupdate.rcu_expedited=1 console=ttyMSM0,115200,n8 androidboot.console=ttyMSM0 earlycon=msm_serial_dm,0xc170000 androidboot.hardware=qcom user_debug=31 msm_rtb.filter=0x37 ehci-hcd.park=3 lpm_levels.sleep_disabled=1 sched_enable_hmp=1 sched_enable_power_aware=1 service_locator.enable=1 swiotlb=1 loop.max_part=7 buildvariant=user androidboot.selinux=permissive veritykeyid=id:7e4333f9bba00adfe0ede979e28ed1920492b40f root=/dev/dm-0 dm="system none ro,0 1 android-verity /dev/mmcblk0p10" androidboot.verifiedbootstate=orange androidboot.keymaster=1  androidboot.veritymode=logging androidboot.bootdevice=c0c4000.sdhci androidboot.serialno=12345678 androidboot.mode=recovery androidboot.baseband=apq mdss_mdp.panel=1:dsi:0:qcom,mdss_dsi_nt35695b_truly_fhd_cmd:config0:1:none:cfg:single_dsi rootwait ro init=/init androidboot.dtb_idx=-1347440721 pcb_version=0

This is a difference of 393 vs 858 characters.
If you try to "fastboot boot image" a recovery it will be missing the flag "androidboot.mode=recovery" and it will fail.
The kernel is the same in boot and recovery and it has to know what it is.

Usually this should work for regular (non-recovery) images.
I just tried "fastboot boot image" of my regular image and it worked fine.
Still, there is more unresolved mystery in all this.

Edit: Did you check your Magisk'ed image with imgutil.exe /v?

Edit^2: The DTB on boot_a is really screwed up. Which boot image did you start with?

Edit^3: Ok, it's only a secondary DTB for RTIC (RealTime Integrity Check). I ain't ever heard of that; they're always throwing new stuff at us.

[Herschenglime]

Hi! Sorry for the necro, but this process should work the same for the Note Air 2 Plus because it has the same processor (Snapdragon 662), right?

After skimming the thread it seems like using the q662_loader.elf file instead of the bin file is the only necessary change if not using renate's tool.

Thanks for your help!

Edit: I meant to quote post #52 as this question was in regards to Cascade94's rooting guide. Whoops

[Renate]

Originally Posted by Herschenglime

After skimming the thread it seems like using the q662_loader.elf file instead of the bin file is the only necessary change if not using renate's tool.

Just to clarify:

All "loader" files for current Qualcomm processors are ELF files but could be labelled .bin or .elf or really anything.

C:\>elfview /v /p poke3.bin
 #  Type     Flags     Size  Offset  Address
--  -------  -----  -------  ------  --------
 0  null                792  000000  00000000 // program header
 1  null               6856  001000  85e28000 // signing
 2  load     RX      356508  003000  14015000
 3  load     RWZ          0  05a0a0  14077000
 4  load     RW       40704  05a0a0  1407a000
 5  load     RWX      39176  063fa0  14084800
 6  load     RWZ          0  06d8b0  85e10000
 7  load     RX        7804  06d8b0  146ae000
 8  load     RWZ          0  06f730  146b1000
 9  load     RWX     100568  06f730  14098000
10  load     RWZ          0  088010  146b2000
11  load     RWZ          0  088010  14680000
12  load     RX       77248  088010  14699000

There are different loaders for different processors, different variants, different OEM signing, even different flash memory (sometimes).
But you would always use the same loader when using any tool, MSM Tool, the Python tool or my Windows version.

[Herschenglime]

I see, thank you! Is there the possibility of damaging the device if I use the wrong loader, or would it just not work?

[Renate]

There's almost zero potential of damage from just the loader. Either it works or it doesn't.
If the loader works most any damage you do (by intentionally writing/erasing partitions) can be fixed.

If you want to play it safe (and you have plenty of space on your desktop hard drive) you can either save the entire flash as one 32 GB (or 64 or 128) file or save all the partitions individually.

You might consider strategies for safeguarding of data, which is a sort of different subject. Yes, you can rely on raw device/partition schemes, but it might be easier to save/restore a few GB of books rather than a 100 GB partition. Also, if you decide to replace your Note Air 2 with a Zircon 77.

[Chitter]

I've read through this thread and am trying my best to follow, but I'm having difficulties getting ADB access to my NA2+ (which seems to be one of the preliminary steps). Cascade94 said "Guide assumes you already have developer mode enabled and ADB mode on your Note Air 2". Would anyone be able to walk me through that process or point me in the right direction? I see mentions of enabling USB debugging elsewhere, but that's not an option in the settings of the NA2+.

[Renate]

For any stock Android device you have to go to Settings, navigate to About or System.
There is a field called Build Number. Click on that 7 times and it should say, "You are a developer!"
Go back to Setting, either System > Developer Settings or just Developer Settings and Enable USB debugging.

It's been so long since I've seen Onyx settings I'm not sure exactly how they did this.
If you can't find it there download and install a Launcher and you can run the Android settings, which definitely has this.

[downeaster59]

With the new 3.3 firmware upgrade, it's much simpler to enable USB debugging. Three clicks will do it. On the Apps page, click the icon on the upper right hand corner that has three horizontal lines. In the small popup window that emerges, choose App Management. In the window that then appears, the first option is USB Debug mode. Turn that on. USB debugging is enabled!

[Renate]

Aw, I was going to write an app to redirect to the black-listed stock Settings.

[Chitter]

@Renate - This is my first time using Android, so thank you for those tips.
@downeaster59 - Ah! That was so simple. Thank you! Now I will try again.

If I can figure this out I'm going to create a "dummy's guide" for rooting the NA2+. I know there are lots of people who want to do it but it can be intimidating. I know just enough to follow most of the instructions, but that's it. No dev experience for me.

[Chitter]

Well, I got little further. I was able to get the EDL tool to work, but neither the included sdm662 loader nor the one @downeaster59 uploaded work for my Note Air2 Plus.

If I run:

python edl r boot_a boot.img --memory=ufs --loader 0014d0e100000000_d40eee56f3194665_FHPRG.bin

I get:

Qualcomm Sahara / Firehose Client V3.60 (c) B.Kerler 2018-2022.
main - Using loader 0014d0e100000000_d40eee56f3194665_FHPRG.bin ...
main - Waiting for the device
Traceback (most recent call last):
  File "C:\Users\<username>\edl\edl", line 391, in <module>
    base.run()
  File "C:\Users\<username>\edl\edl", line 299, in run
    conninfo = self.doconnect(loop)
  File "C:\Users\<username>\edl\edl", line 193, in doconnect
    self.cdc.connected = self.cdc.connect(portname=self.portname)
  File "C:\Users\<username>\edl\edlclient\Library\Connection\usblib.py", line 226, in connect
    self.configuration = self.device.get_active_configuration()
  File "C:\Users\<username>\AppData\Local\Programs\Python\Python310\lib\site-packages\usb\core.py", line 921, in get_active_configuration
    return self._ctx.get_active_configuration(self)
  File "C:\Users\<username>\AppData\Local\Programs\Python\Python310\lib\site-packages\usb\core.py", line 113, in wrapper
    return f(self, *args, **kwargs)
  File "C:\Users\<username>\AppData\Local\Programs\Python\Python310\lib\site-packages\usb\core.py", line 249, in get_active_configuration
    self.managed_open()
  File "C:\Users\<username>\AppData\Local\Programs\Python\Python310\lib\site-packages\usb\core.py", line 113, in wrapper
    return f(self, *args, **kwargs)
  File "C:\Users\<username>\AppData\Local\Programs\Python\Python310\lib\site-packages\usb\core.py", line 131, in managed_open
    self.handle = self.backend.open_device(self.dev)
  File "C:\Users\<username>\AppData\Local\Programs\Python\Python310\lib\site-packages\usb\backend\libusb1.py", line 804, in open_device
    return _DeviceHandle(dev)
  File "C:\Users\<username>\AppData\Local\Programs\Python\Python310\lib\site-packages\usb\backend\libusb1.py", line 652, in __init__
    _check(_lib.libusb_open(self.devid, byref(self.handle)))
  File "C:\Users\<username>\AppData\Local\Programs\Python\Python310\lib\site-packages\usb\backend\libusb1.py", line 600, in _check
    raise NotImplementedError(_strerror(ret))
NotImplementedError: Operation not supported or unimplemented on this platform

[Renate]

I love stack traces! I love Python! Just kidding.

May I modestly suggest that you try my EDL client (in the sig).
The command formats are different, but it's all documented there.

[Chitter]

@Renate, I'll give it a go. Thank you for the suggestion.