[Replicant] libsamsung-ipc on xmm6160 and ste m5730

[Denis 'GNUtoo' Carikli]

On Wed, 8 Apr 2020 19:50:00 -0700
Jonathan Bakker <xc-racer2 at live.ca> wrote:

> 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).
I didn't know it was the case for the Galaxy S.

I found BUSE (block device in userspace[1]) but it's very experimental
and seem to abuse the NBD interface.

> 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.
Right, or we would need to detect if the partition still uses BML which
might be complicated to do.

The idea behind FUSE for this part was to make the code as generic as
possible and potentially benefit other projects as well, as this way
BML block devices could be read even if there was no modem firmware
inside that block layer.

Having a kernel driver seem to be the best way but it would probably
require to spend way more time to upstream 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
Thanks. 

It doesn't seem to match the ones I found on devices with an XMM626.
I'll probably look into it in more details some time after the patches
are merged to see if they match the partition offset and size.

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

In Replicant 6 I have the following for instance:
> /dev/fuse on /mnt/runtime/read/emulated type fuse

I didn't have the time yet to look from where it comes from or how
it was implemented.

The question was mainly if there as a way to use arbitrary FUSE
programs and if so how they are integrated in Android as if we go this
route we would still need to integrate it somehow.

I just didn't have the time yet to look into it, but would be important
to do it before starting to actually implement such scheme as we would
need to make sure that Replicant can also use it.

As for the metadata:
- The permissions could simply be reused from the block device.
- The file names could be generated from the header and/or static
  information. We now know the modem partition names more precisely
  than before thank to that header. It also gives some more information
  on the modem side as we can suppose that SECPACK is implementing a
  part specific to Samsung, which probably includes the samsung-ipc
  protocol.

References:
-----------
[1]https://github.com/acozzette/BUSE

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