[Replicant] libsamsung-ipc on xmm6160 and ste m5730

[Denis 'GNUtoo' Carikli]

On Tue, 7 Apr 2020 11:07:54 -0700
Jonathan Bakker <xc-racer2 at live.ca> wrote:
> >> 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.
After making all the coding style fixes, I was really tired and I sent
the patch set way too early. I'll send a v2 when all the files pass all
the relevant checkpatch.pl checks.

> > 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.
That works fine too for me.

> > Modem abstraction
> > -----------------
[...]
> 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.
Nice. I'm still learning and documenting the GPIO interfaces. There
might also be relevant information for privacy as the modem is running
nonfree software.

Did you look into devices with either an HSIC interface between the
modem and the Application Processor SOC (Exynos)?

> 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
With the infrastructure that already determine which device and
function to use which is already in place. It also uses the model name
among other things like the kernel version.

The main change needed is to add support for selecting which modem
function handler to use, that's all.

> Do the various xmm6260 devices have different boot requirements?
In practice the devices using a given modem can and do have different
requirements. 

For instance for the Galaxy Nexus, you probably need to use the
IOCTL_MODEM_BOOT_ON. I didn't test without it but it's present in the
code so I guess that the proprietary implementation also does use that
IOCTL.

That ioctl toggle the "gpio_flm_uart_sel" GPIO.

My current hypothesis is based on reading source code and schematics of
several devices (but not the Galaxy Nexus yet) is that:
- 2 of the modem UARTS are connected to 1 of the SOC UARTs and that the
  gpio_flm_uart_sel enables somehow to switch from one to the other.
- That FLM stands for firmware load mode, and that the PSIRAM
  bootloader is loaded through that UART. I've not confirmed or
  infirmed that yet, but the information should be somewhere in the
  source code.

If that hypothesis is correct, this makes part of the boot specific to
a given smartphone model variant (like GT-I9100) and potentially even 
version of the variant if we are not lucky.

> 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
I'm already having issues with that. At some point I'll probably write
a function that autodetects the location as the path is not the same
between GNU/Linux and Android, which is really annoying.

> - 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.
I'm not sure to completely understand what you mean. On Replicant we
rely on the modem firmware that is already present in a partition of
the device. In SHR, which was a GNU/Linux distribution that supported
Samsung devices too, we did the same thing.

On some device the modem binary is just flashed to a block device
partition. On some other, like the Galaxy S it seems to be in a
filesystem.

On devices where the modem firmware is on a block device partition, I
also want to add support in libsamsung-ipc to pick the modem firmware
from a patch from within the filesystem.

As for the different partitions in the modem firmware, on some devices
you have a partition header that could be parsed, but it's not present
in the Galaxy S or Nexus S as PSIRAM starts at 0, so here we probably
need to rely on hardcoded partition location which is what
libsamsung-ipc currently relies on for every device.

Denis.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.osuosl.org/pipermail/replicant/attachments/20200407/1c89fb89/attachment.asc>