On Sun, 10 Jul 2022 21:27:14 -0400 "A. F. Cano via Replicant" <replicant@osuosl.org> wrote: > Not strictly a replicant question, but I can't think of a better place > to ask. If people here can't help probably no one can. I would love > it if this phone could run replicant. Has it been tried? The first step would be to find information on that device.
The entry about the Galaxy S6 in the Replicant wiki doesn't tell if it
has shared memory or not, or if the battery is replaceable[1].
In addition I looked very rapidly on Wikipedia and I didn't find
information if the SM-G920T had any differences with the SM-G920F that
is or was supported by LineageOS.
> What are the possibly incompatible devices/firmware?
We have some requirements for officially supported devices, like having
an isolated modem or having replaceable battery.
Though we also accept patches for devices that don't met the
requirements but it will be up to the people who send these patches to
make the releases for that device, and to handle the bug reports.
We'd also have to find a good name for the fork. Replicant can help for
all the rest.
> The upgrade to the official latest software was completed after a few
> protocol errors and hard resets. The official software consists of 2
> files:
>
> recovery.img and boot.img. These were installed with:
>
> heimdall flash --RECOVERY recovery.img --no-reboot
> heimdall flash --BOOT boot.img
>
> The phone reports "official" after installing these.
Usually there are more files than just boot and recovery images, like
a system.img.
The boot.img file typically contains the boot kernel (+ sometimes an
initramfs), and the recovery.img usually contains the recovery
initramfs (+ sometimes a recovery kernel as well).
> This command appears to have succeeded, but when I tried the next one:
>
> heimdall flash --CACHE cache.img
>
> it failed.
Replicant 6.0 supports several devices, and they either have a Samsung
Exynos or a TI OMAP CPU/system on a chip.
On the ones with the Samsung Exynos, heimdall is not very reliable with
large files: I can reliably make heimdall fail with a very large file
(for instance a system.img) and by increasing the IO and CPU load on
the computer that runs heimdall (for instance by compiling Replicant
at the same time or doing some heavy file copy).
The issue seems to be in the bootloader, so the workaround we use is to
keep the boot.img and recovery.img files small and then use the recovery
to make the install.
> The first time I tried this it succeeded and then rebooted
> immediately. During reboot a lot of messages came up: patching ...,
> installing super su, etc... and then something about installing
> standard recovery. Weird. I can still not run adb root (not allowed
> in production environment, but if I do adb shell and from there type
> su it does work. I get the # prompt.
> This was then. When I tried doing this again after a factory reset
> (the only way to get rid of a continously running media app that was
> making the phone very hot and drained the battery in an hour [1]),
> flashing the cache doesn't do any of the above, I only see a red
> message briefly that says "RECOVERY IS NOT STANDARD ENFORCING" and
> then the phone boots normally. Of course if I do "su" from adb
> shell, it claims "su not found". So now I can't get back to even the
> result achieved the first time.
Note that on Samsung phones more recent than the ones actually supported
by Replicant, when it boots, the stock boot.img restores the stock
recovery.img if it was modified.
Also I don't know how root works in your case, but:
- For Replicant 6.0, the cache partition can contains commands to be
executed in the recovery in /cache/recovery/command
- As I understand some solutions to add root depend on either boot.img
(like magisk that adds su inside the initramfs) or recovery.img (to
add the su binary to the rootfs).
> What am I missing?
> Is the order these files are flashed critical?
Yes and no. If you don't reboot between flashes, the order doesn't
matter. If you reboot between flashes the order matters a lot.
> The first time (in the order described) it worked, at least to get su
> from adb shell. But why didn't "adb root" work? ("adbd cannot run as
> root in production builds").
I've no idea. I'm not familiar with Samsung's stock Android
distributions. I've only used them for very limited purposes (like
trying to understand how to get the modem operating system debug logs in
Replicant, installing Replicant, doing failed root exploits tests for
backuping the stock OS).
Why do you need the stock distribution? Is there some community
distribution for the SM-G920F that could make it easier for you to
do tests on that device (like finding the system on a chip it use to
understand how easily it might be to port Replicant to it)?
Apart from very specific tests (like getting debug logs from the modem
operating system, or trying to find how to reconstruct an EFS from
scratch) the stock OS is not required.
> Do I need to select some obscure option? All the commands above
> eventually completed without error, the only strange behavior was
> having to do a hard reset (vol down/home/power) for quite a few
> seconds after flashing recovery.img or the next file would give
> protocol errors.
> I have read that the turning off immediately after flashing
> recovery.img is important or the system will reinstall the original.
> Is this what seems to have happened? How do I prevent it?
It depends on how the rooting solution works.
The LineageOS installation instructions typically tell people to
install a recovery with heimdall flash [...] --no-reboot and then to
not reboot and power off the phone instead, and then boot directly on
the recovery by holding the correct button sequence.
If for some reasons it boots to the boot.img instead of the recovery,
the original recovery is restored, so users need to try again to flash
the recovery and to boot from it.
The advantage of that procedure is that users can make the decision to
overwrite the existing system when they are in the recovery.
To do that the installation instructions make the users install the
recovery only to the recovery partition.
Replicant has different tradeoffs: the decision to override the
existing system is done earlier (when users use heimdall). That makes
the installation instructions much easier to follow.
To do that it installs the recovery to both the boot and recovery
partitions. This way it boots in the Replicant recovery in all the
cases.
As for how your rooting procedure work in details I've no idea.
I would also be interested in knowing more about it because I've to add
root support in Replicant 11 where root is currently only available
through adb and not through the local terminal, and magisk requires an
initramfs which we don't have anymore on Replicant 11.
And since the BOOT and RECOVERY partitions are only 8MiB, adding an
initramfs would be complicated. And I'm not sure that re-partitioning
would work on the Galaxy SIII (GT-I9300).
References:
-----------
[1]https://redmine.replicant.us/projects/replicant/wiki/TargetsEvaluation
Denis.
pgp2sMC2n2VRC.pgp
Description: OpenPGP digital signature
_______________________________________________ Replicant mailing list Replicant@osuosl.org https://lists.osuosl.org/mailman/listinfo/replicant
