[Replicant] libsamsung-ipc on xmm6160 and ste m5730

Denis 'GNUtoo' Carikli GNUtoo at cyberdimension.org
Thu Apr 9 01:05:47 UTC 2020


On Tue, 7 Apr 2020 13:18:37 -0700
Jonathan Bakker <xc-racer2 at live.ca> wrote:

> Hi Denis,
Hi,

> 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 Galaxy Nexus uses that but it uses a different kernel
(kernel_samsung_tuna) than the usual smdk4412 one.

> 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.
I'll think about that. What about approaches like FUSE? Would that be
fast enough to implement this way?

> 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.
Interesting. If the header is only data, it would be interesting to
post it somewhere so I could look at it.

> 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.
I'm also considering this, and it's probably a good place to start to
upstream support for the modem, but I wonder how to properly implement
it.

The modem firmware is a single file with multiple pieces. If I look at
the libertas WiFi driver, you can send 2 files to the firmware
interface, one after the other. So from the kernel side, that is
pretty simple as you don't need to parse the modem firmware images in
any way.

But then, if it is done that way, handling that in userspace is more
complicated as in GNU/Linux and Android there are daemons that handles
the firmware loading to /sys/class/firmware, which means that we would
need to extract the pieces of the modem firmware and store them
somewhere. 

So I'm looking for a solution that:
- enables to use the modem firmware as-is without having to modify it
- is compatible with udev / systemd / android firmware loading
- doesn't complicate the kernel driver
- has the firmware parsing logic implemented in userspace

Maybe using FUSE could also work here.

Note that I didn't look yet how FUSE drivers can be integrated with
Android.

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/20200409/d40038c9/attachment.asc>


More information about the Replicant mailing list