[Replicant] Fwd: libsamsung-ipc and Ubuntu-3.18
Denis 'GNUtoo' Carikli
GNUtoo at cyberdimension.org
Tue Mar 30 19:30:01 UTC 2021
On Tue, 30 Mar 2021 19:28:25 +0300
Victor Shilin <chrono.monochrome at gmail.com> wrote:
> > As I understand the combination of forkbomb's modem branch (using
> > forkbomb's repository) and forkbomb's libsamsung-ipc wasn't tested
> > up to making a call. So while the modem is supposed to bootstrap we
> > don't know if the code fully works.
> Ah, I figured that could be the case, I was just hoping it would
> magically work on the dev branches of forkbomb :)
I was assuming that too, at the beginning so I didn't verify if it
really worked (like I didn't make a call). But after asking, If I
recall well, I was told by forkbomb that the code wasn't fully
validated (like no calls we made).
I didn't take the time to validate it yet as I was focused on other
aspects of the code (mainly integrating all that in libsamsung-ipc,
cleaning up the kernel drivers, porting them forward, etc).
I'm unsure if I understood you correctly on that, did you manage to do a
comparison between forkbomb's modem branch+libsamsung-ipc and Android?
If you validated that it didn't manage to register the network but that
in a similar test with Android that it did, we could safely assume that
some part are still missing in Forkbomb's branches as well.
In that case I should probably try to make it work on top of Replicant
11 kernel directly.
Once it work, I also wonder what to do with the gpiohack driver. That
code should probably stay in the kernel in some form as it would be too
complicated to handle the power management GPIOs in userspace.
Though I didn't find good examples on what to do with that code, for
instance I'm unsure if it should be merged in some kernel side firmware
loading driver or be cleaned and kept as standalone driver.
I'm also unsure how to handle firmware loading if it's completely done
in the kernel as usually this is done in the driver in stages, but here
the offsets that are probably device specific or even firmware
specific as there is a partition table at the beginning of it on more
recent devices (the GT-I9300 has one for instance).
> I might test other kernels such as 4.17-5.2, but for the moment I
> shifted my focus to the work on the USB HOST support (I got the VBUS
> to work on LK 5.12, I'll post some details later in the corresponding
Nice, thanks a lot for working on that.
> The issue is that older kernels doesn't seem to build anymore on my
> > system so I'll try to import the patches that fixes that and if it
> > takes too much time I'll build it on a VM.
> I didn't have any issues with the build on my host system (Ubuntu
> 17.04)... It must be the host system or the toolchains, I was able to
> build and test as old kernels as 4.2 (those ones with the DTS, I was
> doing the downgrade just for testing purposes, to see if I was able
> to port some drivers from the smdk4412 kernel to the mainline).
I should probably try to build it with Trisquel then if you didn't
already manage to validate that it doesn't register.
> I've also tried manually toggling the suspend-req GPIOs but when I
> > it in /sys/kernel/debug/gpio it stays high after the modem boot
> > whereas in the smdk4412 kernel it is low.
> That's interesting, I'm new to the GPIO stuff,
> but that could probably be controlled by the bootloader itself?
While it's technically possible and that GPIOSs are often used by
bootloaders to do various things, the bootloader is unlikely to enter
into the equation here.
I tested ipc-modem with the nonfree stock bootloader and the nonfree
u-boot (it depends on nonfree BL1). I even ran tests on the same device
with Replicant 6 and GNU/Linux with the Replicant 11 kernel (with the
stock kernel). Here I was mostly trying to rule out things like modem
firmware corruption or hardware issues and differences between GNU/Linux
> Or otherwise maybe it's only supposed to be set as low only at some
> modem booting stages (just some vague guesses, nothing more).
Basically there is some GPIOs lines between the modem and the SOC. I'm
unsure if they are connected directly or if there are things in between.
However I've spent a lot of time grepping code and trying to
understand what they actually do and all I could come up with is
educated guess. I guess I could probably manage to deduce more things
by reflecting on the boot process and doing some tests, but I'm unsure
if that could be improved much more.
Some GPIOs are involved in the power management, other are involved in
the modem boot.
I've documented that work here:
Though at some point I'll probably rename that page to something more
meaningful, like that contains something like GPIO or modem interface
As GPIOs are simple pins that are toggled, they also have to be
configured by the pinmux driver correctly. I didn't have the time yet to
compare both pinmux configurations.
Also, I've not found any public schematics for the GT-I9300, like the
ones on ifixit looks legally safe to use but the main part seems to
have been removed. In addition they might be the result of a mashup
between other manuals and/or for a different device variant.
So it could also be that I'm not doing right. In that case I probably
need to trace the GPIOs usage with printk to reproduce the exact same
I tried writing a tool that uses /sys/kernel/debug/gpio for that but it
cound't work as the kernel code doesn't implement .poll() but only
things like read / seek.
> It didn't seem to me that I ever corrupted the modem image during the
> tests, at least yet (sometimes I boot up Android which I have as the
> dualboot option to check if the modem image is still intact).
> I made the backup of the modem and EFS partitions just in the case,
> but so far so good - haven't had to restore them.
I had way fewer EFS corruption. Here with the test tools,
the nv_data.bin file from the EFS is just loaded into the modem at boot
and never written to. And it's sufficient to call a number.
Here I was mostly talking about the RADIO partition which contains the
In any case it's easy to check by rebooting in Android.
> I sometimes use the 3-key combo to get to the recovery mode, to then
> change the kernel.
> For some reason, reboot or power off doesn't work on the mainline
> kernels for me, but this should probably be only related to my setup
> I use.
We have an unfinished driver to do that in the Replicant 11 kernel, I
recall that other people also wrote one (forkbomb?).
> I boot via the buildroot, which mounts ubuntu EXT4 image on
> the sdcard, then it calls switch_root into that mounted ubuntu image.
> The image doesn't unmount correctly upon the reboot and hangs here
> (from my understanding, because the sdcard is unmounted before the
> image could have been unmounted first).
> It's quite a surprise I didn't end up corrupting the data on the
> image just yet (which is mounted read-write), as it's probably
> expected to happen.
AFAIK switch_root also deletes everything but what is in the directory
you switch_root to (it's meant for initramfs).
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 833 bytes
Desc: OpenPGP digital signature
More information about the Replicant