On Wed, 8 Apr 2020 19:50:00 -0700 Jonathan Bakker <[email protected]> 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.
pgpIeobhuIp2e.pgp
Description: OpenPGP digital signature
_______________________________________________ Replicant mailing list [email protected] https://lists.osuosl.org/mailman/listinfo/replicant
