On Tue, 7 Apr 2020 11:07:54 -0700 Jonathan Bakker <[email protected]> wrote: > >> Good to know that there are plans to have a consistent coding > >> style. I agree that the Linux code style makes sense for > >> libsamsung-ipc > > I've looked rapidly at your libsamsung-ipc patches, and most of the > > patches don't touch much the existing code, so I guess it should be > > possible to easily rebase your code on top if needed. I've just sent > > patches to do this code style change. > > Yep, looks like it should be just fine for me to rebase on top of the > coding style changes and have no objections to those patches. After making all the coding style fixes, I was really tired and I sent the patch set way too early. I'll send a v2 when all the files pass all the relevant checkpatch.pl checks.
> > If the rebase is too much time consuming for you, we could also make > > some of your patches go in before merging this code style patch set, > > with a priority for the code that touch paths that are also used for > > other devices. > > > > In any case I think it could also be a good idea to try sending the > > ones that are the least intrusive and easiest to review first. > > Ok, I can consider what to post, but I think most should wait on the > modem abstraction. That works fine too for me. > > 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)? > 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. > 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. > 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. 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. Denis.
pgpeBDM_bfe_T.pgp
Description: OpenPGP digital signature
_______________________________________________ Replicant mailing list [email protected] https://lists.osuosl.org/mailman/listinfo/replicant
