[Replicant] libsamsung-ipc on xmm6160 and ste m5730

Tue Apr 7 20:18:37 UTC 2020

Hi Denis,

On 2020-04-07 12:01 p.m., Denis 'GNUtoo' Carikli wrote:
>>> 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)?

No, I don't have any devices that use the HSIC interface, unfortunately, so I haven't looked into it.

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

Yep, but the current auto-detection code only parses /proc/cpuinfo which is identical for the various models.  I guess what I'm trying to get at is that there will need to be changes there as well, which you already seem aware of :)

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

Ok, looks like the XMM6260 is significantly more complicated.  While there are a couple of references in the stock kernel driver to the flm_uart_sel gpio, it's not implemented anywhere.  There is no sim detect pin wired in either from what I can tell.

The PSI is definitely loaded via serial on the XMM6160 and the STE M5730 before the second part of the modem.bin is written directly to the shared memory.

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

When the i9000 shipped, the OneNAND was behind Samsung's proprietary BML (block management layer, for wear leveling and to expose a block interface vs an MTD interface).  One of the filesystems on top, STL, was implemented with a closed source kernel module...

When the CyanogenMod developers switched to using an MTD interface, they simply created a yaffs2 filesystem mounted at /radio with the modem.bin file inside.  They then symlinked the file to /dev/block/bml12 and the stock RIL blobs read it just fine.  This is why the install notes at https://redmine.replicant.us/projects/replicant/wiki/GalaxySI9000Installation make note that you need to install CM first.

Since the Nexus S shipped with MTD partitions, it doesn't have this issue and the modem can simply be read from the MTD device.

Since yaffs isn't mainline and I've switched to using UBI partitions, I've simply copied the modem.bin to the /radio folder.  However, since I have the same rootfs for multiple devices on an SD card, I have to keep switching out the file when I'm reading from there.

However, this whole thing got me thinking: is the "real" modem partition actually inaccessible from mainline linux?  I did some experiments, and the answer is yes and no :)  It appears that the modem is written directly to the raw flash and can be read from a properly setup /dev/mtd device.  However, if there is a bad block in this area, then BML comes into play as it maps bad blocks to a good block in the reservoir area of the flash.  While BML is fairly well understood (eg via https://github.com/TeamWin/Team-Win-Recovery-Project/blob/master/mtdutils/bml_over_mtd.c), I'm not sure if this is the way to go.  I'll probably do some more experiments and see if it's possible to integrate the BML reading code into libsamsung-ipc.

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

The STE M5730 modems do appear to have some sort of header, but whether it's same as the XMM ones or not I don't know (probably not).  I haven't looked at the XMM6160 ones in any great depth.

The one thing I did try with some success was to append the compatible of the device to the modem.bin file, eg modem.bin,samsung,fascinate4g and then have the multiple present in the /radio folder.  However, it probably does make sense to just rely on the user having some method of putting the modem.bin there.

I've also considered doing all the modem initialization in the kernel driver and loading the modem.bin as a firmware, but have never implemented this.

> 
> Denis.
> 

Jonathan