[Replicant] Fwd: libsamsung-ipc and Ubuntu-3.18

Tue Mar 30 21:07:08 UTC 2021

>
> 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?
>

On 4.16 kernel, the modem doesn't appear in the lsusb output.
I tried both forkbomb's version of libsamsung-ipc and the one from
https://git.replicant.us/contrib/GNUtoo/hardware_replicant_libsamsung-ipc/log/?h=replicant-11-i9300-modem
.
4.16 kernel doesn't seem to bring EHCI subsystem back after it's powered
down, so neither version of libsamsung-ipc work here.

Only few corrections to the original 4.16 modem branch were related to the
compilation issue (correcting *of_match_table*) and using devm_request_irq
instead of request_irq (as the latter returned an error during my test):
https://github.com/Midas-Mainline/android_kernel_samsung_smdk4412/commit/e62cbdb5ebbbe7400c0a194cfffeb7ab6c6516a8

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.
>

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).
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),
maybe some more recent kernels will make it work.
So I didn't verify if it does register to the network as the EHCI
susbsystem needs some hack to get powered on.

Some GPIOs are involved in the power management, other are involved in
> the modem boot.
> I've documented that work here:
> https://redmine.replicant.us/projects/replicant/wiki/XMMBoot

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.

We have an unfinished driver to do that in the Replicant 11 kernel, I
> recall that other people also wrote one (forkbomb?).
>

Now that I tested 4.16, the reboot worked fine here.
Not sure if this is related to the patches I merged or the kernel version
itself, I didn't test this thoroughly.

вт, 30 мар. 2021 г. в 22:30, Denis 'GNUtoo' Carikli <
GNUtoo at cyberdimension.org>:

> 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
> > issue).
> 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
> > read
> > > 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
> and Android.
>
> > 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:
> https://redmine.replicant.us/projects/replicant/wiki/XMMBoot
>
> Though at some point I'll probably rename that page to something more
> meaningful, like that contains something like GPIO or modem interface
> in it.
>
> 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
> sequence.
>
> 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
> modem firmware.
>
> 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).
>
> Denis.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osuosl.org/pipermail/replicant/attachments/20210331/d7cb9681/attachment-0001.html>