<div dir="ltr"><div dir="ltr"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I'm unsure if I understood you correctly on that, did you manage to do a<br>comparison between forkbomb's modem branch+libsamsung-ipc and Android?<br></blockquote><div><br></div><div>On 4.16 kernel, the modem doesn't appear in the lsusb output. </div><div>I tried both forkbomb's version of libsamsung-ipc and the one from <a href="https://git.replicant.us/contrib/GNUtoo/hardware_replicant_libsamsung-ipc/log/?h=replicant-11-i9300-modem">https://git.replicant.us/contrib/GNUtoo/hardware_replicant_libsamsung-ipc/log/?h=replicant-11-i9300-modem</a> .</div><div>4.16 kernel doesn't seem to bring EHCI subsystem back after it's powered down, so neither version of libsamsung-ipc work here.</div><div><br></div><div>Only few corrections to the original 4.16 modem branch were related to the compilation issue (correcting <b><span class="gmail-pl-smi" style="color:rgb(36,41,46);font-family:SFMono-Regular,Consolas,"Liberation Mono",Menlo,monospace;font-size:12px;white-space:pre;box-sizing:border-box">of_match_table</span></b>) and using devm_request_irq instead of request_irq (as the latter returned an error during my test):</div><div><a href="https://github.com/Midas-Mainline/android_kernel_samsung_smdk4412/commit/e62cbdb5ebbbe7400c0a194cfffeb7ab6c6516a8">https://github.com/Midas-Mainline/android_kernel_samsung_smdk4412/commit/e62cbdb5ebbbe7400c0a194cfffeb7ab6c6516a8</a><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">If you validated that it didn't manage to register the network but that<br>in a similar test with Android that it did, we could safely assume that<br>some part are still missing in Forkbomb's branches as well.<br></blockquote><div><br></div><div>The modem driver didn't appear in lsusb, in 4.16 kernel (so I wasn't able to test the remaining part of the ipc-modem initialization). </div><div>I didn't yet investigate how to make the EHCI subsystem work after it was powered down (for now it fails to power up with ETIMEDOUT error), </div><div>maybe some more recent kernels will make it work.</div><div>So I didn't verify if it does register to the network as the EHCI susbsystem needs some hack to get powered on.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Some GPIOs are involved in the power management, other are involved in<br>the modem boot.<br>I've documented that work here:<br><a href="https://redmine.replicant.us/projects/replicant/wiki/XMMBoot" rel="noreferrer" target="_blank">https://redmine.replicant.us/projects/replicant/wiki/XMMBoot</a></blockquote><div><br></div><div>Thanks, a lot of things to check...  I was just thinking that the suspend-req issue was one of those device quirks, but there are lot of posibilities.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">We have an unfinished driver to do that in the Replicant 11 kernel, I<br>recall that other people also wrote one (forkbomb?).<br></blockquote></div><div><br></div><div>Now that I tested 4.16, the reboot worked fine here. </div><div>Not sure if this is related to the patches I merged or the kernel version itself, I didn't test this thoroughly.</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">вт, 30 мар. 2021 г. в 22:30, Denis 'GNUtoo' Carikli <<a href="mailto:GNUtoo@cyberdimension.org">GNUtoo@cyberdimension.org</a>>:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Tue, 30 Mar 2021 19:28:25 +0300<br>
Victor Shilin <<a href="mailto:chrono.monochrome@gmail.com" target="_blank">chrono.monochrome@gmail.com</a>> wrote:<br>
<br>
> > As I understand the combination of forkbomb's modem branch (using<br>
> > forkbomb's repository) and forkbomb's libsamsung-ipc wasn't tested<br>
> > up to making a call. So while the modem is supposed to bootstrap we<br>
> > don't know if the code fully works.<br>
> >  <br>
> <br>
> Ah, I figured that could be the case, I was just hoping it would<br>
> magically work on the dev branches of forkbomb :)<br>
I was assuming that too, at the beginning so I didn't verify if it<br>
really worked (like I didn't make a call). But after asking, If I<br>
recall well, I was told by forkbomb that the code wasn't fully<br>
validated (like no calls we made).<br>
<br>
I didn't take the time to validate it yet as I was focused on other<br>
aspects of the code (mainly integrating all that in libsamsung-ipc,<br>
cleaning up the kernel drivers, porting them forward, etc).<br>
<br>
I'm unsure if I understood you correctly on that, did you manage to do a<br>
comparison between forkbomb's modem branch+libsamsung-ipc and Android?<br>
<br>
If you validated that it didn't manage to register the network but that<br>
in a similar test with Android that it did, we could safely assume that<br>
some part are still missing in Forkbomb's branches as well.<br>
<br>
In that case I should probably try to make it work on top of Replicant<br>
11 kernel directly.<br>
<br>
Once it work, I also wonder what to do with the gpiohack driver. That<br>
code should probably stay in the kernel in some form as it would be too<br>
complicated to handle the power management GPIOs in userspace.<br>
<br>
Though I didn't find good examples on what to do with that code, for<br>
instance I'm unsure if it should be merged in some kernel side firmware<br>
loading driver or be cleaned and kept as standalone driver.<br>
<br>
I'm also unsure how to handle firmware loading if it's completely done<br>
in the kernel as usually this is done in the driver in stages, but here<br>
the offsets that are probably device specific or even firmware<br>
specific as there is a partition table at the beginning of it on more<br>
recent devices (the GT-I9300 has one for instance).<br>
<br>
> I might test other kernels such as 4.17-5.2, but for the moment I<br>
> shifted my focus to the work on the USB HOST support (I got the VBUS<br>
> to work on LK 5.12, I'll post some details later in the corresponding<br>
> issue).<br>
Nice, thanks a lot for working on that.<br>
<br>
> The issue is that older kernels doesn't seem to build anymore on my<br>
> > system so I'll try to import the patches that fixes that and if it<br>
> > takes too much time I'll build it on a VM.<br>
> >  <br>
> I didn't have any issues with the build on my host system (Ubuntu<br>
> 17.04)... It must be the host system or the toolchains, I was able to<br>
> build and test as old kernels as 4.2 (those ones with the DTS, I was<br>
> doing the downgrade just for testing purposes, to see if I was able<br>
> to port some drivers from the smdk4412 kernel to the mainline).<br>
I should probably try to build it with Trisquel then if you didn't<br>
already manage to validate that it doesn't register.<br>
<br>
> I've also tried manually toggling the suspend-req GPIOs but when I<br>
> read<br>
> > it in /sys/kernel/debug/gpio it stays high after the modem boot<br>
> > whereas in the smdk4412 kernel it is low.<br>
> >  <br>
> That's interesting, I'm new to the GPIO stuff,<br>
<br>
> but that could probably be controlled by the bootloader itself?<br>
While it's technically possible and that GPIOSs are often used by<br>
bootloaders to do various things, the bootloader is unlikely to enter<br>
into the equation here.<br>
<br>
I tested ipc-modem with the nonfree stock bootloader and the nonfree<br>
u-boot (it depends on nonfree BL1). I even ran tests on the same device<br>
with Replicant 6 and GNU/Linux with the Replicant 11 kernel (with the<br>
stock kernel). Here I was mostly trying to rule out things like modem<br>
firmware corruption or hardware issues and differences between GNU/Linux<br>
and Android.<br>
<br>
> Or otherwise maybe it's only supposed to be set as low only at some<br>
> modem booting stages (just some vague guesses, nothing more).<br>
Basically there is some GPIOs lines between the modem and the SOC. I'm<br>
unsure if they are connected directly or if there are things in between.<br>
<br>
However I've spent a lot of time grepping code and trying to<br>
understand what they actually do and all I could come up with is<br>
educated guess. I guess I could probably manage to deduce more things<br>
by reflecting on the boot process and doing some tests, but I'm unsure<br>
if that could be improved much more.<br>
<br>
Some GPIOs are involved in the power management, other are involved in<br>
the modem boot.<br>
<br>
I've documented that work here:<br>
<a href="https://redmine.replicant.us/projects/replicant/wiki/XMMBoot" rel="noreferrer" target="_blank">https://redmine.replicant.us/projects/replicant/wiki/XMMBoot</a><br>
<br>
Though at some point I'll probably rename that page to something more<br>
meaningful, like that contains something like GPIO or modem interface<br>
in it.<br>
<br>
As GPIOs are simple pins that are toggled, they also have to be<br>
configured by the pinmux driver correctly. I didn't have the time yet to<br>
compare both pinmux configurations.<br>
<br>
Also, I've not found any public schematics for the GT-I9300, like the<br>
ones on ifixit looks legally safe to use but the main part seems to<br>
have been removed. In addition they might be the result of a mashup<br>
between other manuals and/or for a different device variant.<br>
<br>
So it could also be that I'm not doing right. In that case I probably<br>
need to trace the GPIOs usage with printk to reproduce the exact same<br>
sequence.<br>
<br>
I tried writing a tool that uses /sys/kernel/debug/gpio for that but it<br>
cound't work as the kernel code doesn't implement .poll() but only<br>
things like read / seek.<br>
<br>
> It didn't seem to me that I ever corrupted the modem image during the<br>
> tests, at least yet (sometimes I boot up Android which I have as the<br>
> dualboot option to check if the modem image is still intact).<br>
> I made the backup of the modem and EFS partitions just in the case,<br>
> but so far so good - haven't had to restore them.<br>
I had way fewer EFS corruption. Here with the test tools, <br>
the nv_data.bin file from the EFS is just loaded into the modem at boot<br>
and never written to. And it's sufficient to call a number.<br>
<br>
Here I was mostly talking about the RADIO partition which contains the<br>
modem firmware.<br>
<br>
In any case it's easy to check by rebooting in Android.<br>
<br>
> I sometimes use the 3-key combo to get to the recovery mode, to then<br>
> change the kernel.<br>
> For some reason, reboot or power off doesn't work on the mainline<br>
> kernels for me, but this should probably be only related to my setup<br>
> I use.<br>
We have an unfinished driver to do that in the Replicant 11 kernel, I<br>
recall that other people also wrote one (forkbomb?).<br>
<br>
> I boot via the buildroot, which mounts ubuntu EXT4 image on<br>
> the sdcard, then it calls switch_root into that mounted ubuntu image.<br>
> The image doesn't unmount correctly upon the reboot and hangs here<br>
> (from my understanding, because the sdcard is unmounted before the<br>
> image could have been unmounted first).<br>
> It's quite a surprise I didn't end up corrupting the data on the<br>
> image just yet (which is mounted read-write), as it's probably<br>
> expected to happen.<br>
AFAIK switch_root also deletes everything but what is in the directory<br>
you switch_root to (it's meant for initramfs).<br>
<br>
Denis.<br>
</blockquote></div></div>