[Replicant] libsamsung-ipc on xmm6160 and ste m5730

Jonathan Bakker xc-racer2 at live.ca
Tue Apr 7 18:07:54 UTC 2020


Hi Denis,

On 2020-04-06 8:16 a.m., Denis 'GNUtoo' Carikli wrote:
> I've not worked on that part recently and it's still at the same state:
> - I can boot the modem with ipc-test and receive samsung-ipc messages,
>   however I need to reboot after each tests. I didn't look into it yet
>   but in some drivers the .remove is not implemented if my memory is
>   correct.
> - In the modem/5.4-with-usb-disconnection-during-modem-init
>   branch, the usb device is reset during the modem init, so you
>   loose adb for a short moment that needs to be fixed as well.
> - The modem/5.2-without-usb-disconnections-during-modem-init doesn't
>   that issue but it's based on an older Linux version.
>
> I also did lot of cleanup and fixes on top of forkbomb's code but I
> still need to finish cleaning it up. I took forkbomb's most recent
> branch at the time to base my work on.
>
> What did you base your code on forkbomb's code directly?
> In that case we probably have different fixes. For instance if my
> memory is good there was some missing .remove in some drivers but I've
> not implemented that yet and that's may be why I need to reboot after
> each test.
>
> I use the following repository for that kernel:
> https://git.replicant.us/contrib/GNUtoo/kernel_replicant_linux/

Ok, looking back on it it appears I did implement it directly on fourkbomb's code.  I'll rebase it on yours and see if it still works.

>
>> Good to know that there are plans to have a consistent coding style.
>> I agree that the Linux code style makes sense for libsamsung-ipc
> I've looked rapidly at your libsamsung-ipc patches, and most of the
> patches don't touch much the existing code, so I guess it should be
> possible to easily rebase your code on top if needed. I've just sent
> patches to do this code style change.

Yep, looks like it should be just fine for me to rebase on top of the coding style changes and have no objections to those patches.

>
> If the rebase is too much time consuming for you, we could also make
> some of your patches go in before merging this code style patch set,
> with a priority for the code that touch paths that are also used for
> other devices.
>
> In any case I think it could also be a good idea to try sending the ones
> that are the least intrusive and easiest to review first.

Ok, I can consider what to post, but I think most should wait on the modem abstraction.

>
> Modem abstraction
> -----------------
> About the "modem abstraction", the idea is that there are functions
> like xmm626_kernel_smdk4412_* which, in forkbomb's libsamsung-ipc code
> are modified. And in some part of the code, the only change was to use
> a different / modified xmm626_kernel_smdk4412 function. 
>
> So my idea was just to wrap that in function that then call the actual
> implementation, as it's usually done in the various Linux frameworks.
> This is pretty easy to do.
>
> What takes me time is choosing the name of the functions, and this
> is not simple as we have very few information on how all that works
> under the hood.
>
> For instance we have:
> - xmm626_kernel_smdk4412_power which calls IOCTL_MODEM_ON
> and:
> - xmm626_kernel_smdk4412_boot_power which calls IOCTL_MODEM_BOOT_ON. 
>
> And it would be better to have names that really describes what
> is done under the hood rather that basing them on the ioctl name.
>
> I've started to document all what I found here:
> https://redmine.replicant.us/projects/replicant/wiki/XMMBoot
>
> This also helps me understand the GPIO interface between the modem and
> the SOC (Exynos 4412).
>
> As I will also need to understand how it works in greater details
> anyway if I want try to upstreaming some of the modem drivers, I
> took that as an opportunity to do that research now.
>
> However if you need to rebase and merge your code sooner, I could
> finish and rebase all the code I have sooner, especially the modem
> abstraction part, leaving the function name choice for later.
>
> As the function names won't be exposed outside of the library, we could
> also improve them later on without any drawbacks.

Ok, sounds good.  I'm pretty familiar with the XMM6160 and the STE M5730 GPIO and boot interface with the various IOCTLs.  I'd feel comfortable implementing/testing both the aries and the crespo libsamsung-ipc backends as I have devices that can work with both.  In addition to changing the GPIOs, they also involve both writing and reading some magic numbers (0x12341234 and 0xabcdabcd IIRC) to make sure things are setup correctly.

How are you proposing to determine which backend to use for the modem boot?  From a userspace perspective, both the XMM6160 and the STE M5730 s5pv210 devices look very similar - essentially the only difference being the model name in /proc/device-tree/model  Do the various xmm6260 devices have different boot requirements?

The other part of the puzzle is the binary modem firmware and where it is loaded from.  For example, the aries backend reads from /radio/modem.bin - but I'd like to be able to have a generic image that contains the modems for various devices (as different ones support different bands, etc) and the correct one loaded for each device.  Maybe this is just a pipe dream though and the user should be the one that makes sure the correct modem.bin is present.

>
> Denis.
>

Thanks,
Jonathan


More information about the Replicant mailing list