[Replicant] libsamsung-ipc on xmm6160 and ste m5730

[Jonathan Bakker]

Hi Denis,

On 2020-04-08 6:05 p.m., Denis 'GNUtoo' Carikli wrote:
> 
>> 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?

Probably would be fast enough, but that might be overkill since I believe (not positive, never really used fuse) that it needs a full filesystem as opposed to raw data (the modem is written to the flash as raw data, in case I wasn't clear).  Do note that all custom roms (Replicant included) overwrite the area that it is stored in on the flash, so a return to stock is required for this to work properly.

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

Sure, it's first 12 bytes of the modem and an example from the T959PTLKH2 modem is

0A 00 01 00 74 03 00 00 00 00 00 00

The 74 03 bit appears to be a length of some sort, the 01 00 appears to be the padding size or type, I'm unsure of what the 0A 00 means.

It also reappears later in the form of

0B 00 01 00 A8 29 00 00 00 00 00 00

but again, I have no good idea what most of it means.  My FW loading code just ignores it (basic startup for m5730 goes something like write to serial, presumably to change the modems baud->change baud rate on serial->load part1 of fw via serial->load part2 of fw via serial->wait for modem to write magic to shared memory->write rest of fw to shared memory->wait for modem to write magic2 to shared memory)

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

A brief search brought https://github.com/LineageOS/android_external_fuse plus Google appears to be trying some experiment on Android 10 at https://android.googlesource.com/platform/external/libfuse

> 
> Denis.
> 

Jonathan