Hi Denis, On 2020-03-01 5:13 p.m., Denis 'GNUtoo' Carikli wrote: > On Sat, 29 Feb 2020 15:24:04 -0800 > Jonathan Bakker <[email protected]> wrote: > >> Hi there, > Hi, > >> I came across >> https://git.replicant.us/contrib/GNUtoo/hardware_replicant_libsamsung-ipc/commit/?h=patches-todo/xmm616-todo&id=44ebce3689469eef25f28b4601acc20c1a665b6b >> >> I have a Galaxy S that I've done some libsamsung-ipc experiments with >> and would be interested in making sure that the xmm6160 keeps >> working. > As there is some interest, I've asked Insurgo to ship me a Galaxy S > (GT-I9000) in order to convert the XMM616 to the new abstraction along > the way. > > While Replicant is not interested in supporting devices with a modem > that is not known to be isolated, we still want to collaborate with > people and projects wanting to support such devices. > > Since we are the libsamsung-ipc and libsamsung-ril upstream, It's also > a good idea to enable other projects to use it too for devices that are > not necessarily interesting for Replicant.
Excellent, good to hear. > >> I also have another Galaxy S variant (SGH-T959P) which uses >> an STE M5730, which has a different boot sequence, but once booted >> the kernel<->userspace interactions are the same as the xmm6160. > It would be interesting to add support for that device in libsamsung-ipc > too. > >> I added support for it in a series of commits on an older >> libsamsung-ipc version which I have at >> https://github.com/xc-racer99/libsamsung-ipc/commits/common-rfs-v2 - >> note that it does in fact use the RFS commands at >> https://redmine.replicant.us/projects/replicant/wiki/SamsungGalaxyBackdoor >> but I believe I've implemented them safely and that they'll only run >> for devices that need them. > We also use RFS commands in libsamsung-ipc. If I understand well the > issue with the stock implementation is that the modem could ask for > paths starting with ../ which would make the request look in / of the > host filesystem. This is my understanding as well. > > Feel free to send patches for adding that device. Should I wait for the modem separation changes to stabilize? I have used both the crespo kernel driver (custom IOCTLs) as well as the stock phonet sockets kernel driver. The i9000 can use both kernel drivers as well. > > Testing libsamsung-ipc on the Galaxy S (GT-I9000): > -------------------------------------------------- > Recently, I managed to build Replicant 4.2, which is the last supported > Replicant version for this device, for trying to bisect a bug. > > I did that with libsamsung-ipc from the master branch, and at first It > didn't work, but I retried later and it worked fine. The first try was > probably affected by a bug about the device selection that was > already fixed the second time I tried. > > libsamsung-ril was probably from the master branch too, and it worked > fine on the device I used for testing (I don't remember which one I > used). > My test bed is based on Android 4.4 and I've also used ipc-modem, including hacking in calling support. > Mainline kernel: > ---------------- >> I have both devices running both Android (3.0 kernel) and various >> linux distros (with a mainline-based kernel) with the modem working >> in all combinations. > What driver do you use with the mainline kernel? > > I've ported and cleaned up Simon Shields port of the modem driver > on top of mainline. I've still more cleanups to do. > > Note that work like that is typically done this way by making changes > and cleaning them up later, and Simon didn't have the time to do the > cleanup, and his work saves me a lot of time and effort. > > I use GNU/Linux to work on that part, as I've way faster turnaround > times for testing. > > The modem bootstrap is reliable and I validated that It works by > receiving samsung-ipc messages, but I need to reboot the device after > each test, so I need to fix that as well. > > I've currently two modem branches in that git repository on top of > Linux 5.2 and 5.4: > https://git.replicant.us/contrib/GNUtoo/kernel_replicant_linux/ > > As the branch names implies, on 5.4 the USB OTG is also reset too while > it's not in my 5.2 branch. It's not very convenient for adb so it needs > to be fixed too. > > As for upstreaming the driver, the protocol architecture seem similar > to the one used by the Nokia N900 where in both architectures > you have parts of it that are specific to a transport (like USB, HSIC, > MIPI, etc) and parts that are generic. > > Hoever I'm now concentrating more on libsamsung-ipc but at > some point I'll need to get back to the kernel driver to do more fixes > and see if it's possible to upstream it in reasonable time frame. > > It's also a good idea to have libsamsung-ipc ready to be reviewed by > Linux maintainers and to be able to support the upstream kernel > abstraction, before trying to upstream the modem support in Linux. > > Simon Shields's code has a different API, and upstream will probably > have a different API again. He also did patches for libsamsung-ipc > which I ported and cleaned which currently lives in the > patches-todo/replicant-9-kenrel-gnulinux branch of the following > repository: > https://git.replicant.us/contrib/GNUtoo/hardware_replicant_libsamsung-ipc Yes, I've followed a bunch of these patches from afar. I forward-ported the Crespo (Nexus S) kernel driver to the mainline kernel, as it required only a few patches and used it for both the ste m5730 and the xmm6160. Unfortunately, which the modem power and transport layer are closely intertwined and not properly separated. I briefly had a look at using Simon's kernel API, but decided it would be a fair bit of work as I'd also have to make modifications to the userspace side of things. With the proper modem abstraction it would make it much more feasible for me to do. > > This is also why I'm working on a small modem abstraction: it's > the best way I found to merge both codebase in a clean way. > > Though I've not yet decided which name to use for the callbacks. > > For the modem bootstrap part they they are currently based on the ioctl > names of the Linux driver, but the GPIO names differ, and I'm unsure > if I can manage to find generic enough names as I don't understand > enough things from modem point of view (as far as I know there is no > XMM6262 datasheet that explain what the pins do exactly for instance). > > I'll still look at code that handles the firmware loading of various > chips (WiFi, FPGAs, osmocomBB compatible modems, etc) to get some > inspiration for the names to use. > > I've also some work to left to do on libsamsung-ril as I need to > convert it to the new SIM API of more recent RILs. > > Ofono: > ------- >> I also have a WIP ofono backend supporting >> libsamsung-ipc at https://github.com/xc-racer99/ofono/ which works >> for network registration and SMS, > Long time ago, there was an attempt to upstream support for > libsamsung-ipc in oFono, but it was refused because the libsamsung-ipc > license was GPLv3 or later. Since then it has been re licensed to GPLv2 > or later, but as far as I know, no one retried to add support for it > upstream. > > This are the links to the thread about upstreaming libsamsung-ipc > support: > https://lists.ofono.org/pipermail/ofono/2012-September/013777.html > > And this is for the refusal: > https://lists.ofono.org/pipermail/ofono/2012-September/013778.html > Yes, I used those as an inspiration for my port. However, there's been a major change in the way libsamsung-ipc communicated with the higher levels plus all of the structures changed names so I had to do a fair bit of work. > However the links don't seem valid anymore since they started using > hyperkitty. > > There may be more up to date versions of this patchset lying around. > For instance Simon shields have them in this repository: > - https://github.com/fourkbomb/ofono Unfortunately, this one is even further behind than mine :( It didn't work for me at all. > > PostmarketOS is also interested in using libsamsung-ipc in one way or > another as it is mentioned in their wiki. > > We are really interested in having libsamsung-ipc support in oFono for > many different reasons: > - It would enable GNU/Linux to support devices that uses this protocol, > and it's a good idea to share the code and the maintenance of the code > with GNU/Linux. > - Replicant is also interested in using oFono to support devices with > the QMI protocol. Scintill is working on a RIL that can interface with > Ofono and, even if it wasn't reliable yet around the end of February, > there are already things working like data. > - Once oFono support will be added to Replicant through that oFono RIL, > It would be a good idea to use it too for devices that are using > libsamsung-ipc: If I understand correctly, oFono can automatically > detect which modems are there. So it would be a big step in having > generic Replicant images that work on many devices. Yes, ofono can automatically detect which device to use. For my port, I use ipc_detect_device and if a device is detected, then the modem is registered, otherwise nothing is registered. See https://github.com/xc-racer99/ofono/blob/1.30-samsungipc/plugins/samsungipcmgr.c#L45 I believe it's also possible to detect if a compatible device is present based on udev properties. > > Note that I'm merging patches that is breaking the libsamsung-ipc API, > but for now most of the changes consist in adding a new argument to > functions and callbacks for passing the ipc_client struct, so it's > probably easy to convert the oFono patches. > > This API change enable to use logging in many areas of the code where > it wasn't possible before. > > I think it's a good idea to do that as it could enable us to more > easily debug the code for the new kernel APIs. It would also be easier > to understand what's going on if we have bugreports about something > going wrong. Yes, I've noticed this so have held off on doing any more work for the time being. > > Denis. > Thanks, Jonathan _______________________________________________ Replicant mailing list [email protected] https://lists.osuosl.org/mailman/listinfo/replicant
