Skip to content

Draft: add a generic sdm845 port

Administrator requested to merge generic-devices into master

This MR adds support for generic device ports, these ports should be able to support all devices which match a specific criteria, whether that be SoC, vendor, chip maker etc. Whilst it's acceptable for there to be exceptions to the rule, if there are too many devices which aren't able to be included in a generic port it defeats the purpose of having one in the first place.

This port has come about as I found out that the bootloader shipping on SDM845 devices is capable of selecting the correct DTB when multiple are appended to the kernel. This means that the OnePlus 6 and PocoPhone F1 can boot from the same boot image, as both are already supported by the same kernel.

Current issues

As it stands, the OnePlus 6 and one of the PocoPhone F1 panel variants can use this port, the 6T and other panel variant both seem to use the same board-id as their respective counterparts, this MR shouldn't be merged until these issues are solved, of which there are a few potential solutions:

  1. An early kernel hook to apply dynamic DT overlays, I have previously discussed this with @ollieparanoid although I couldn't remember where, to summarise: have some DT nodes which define an override for some other node based on arbitrary matching (could be cmdline - most devices pass the display panel model via cmdline, register values etc) and have the kernel apply these matches before driver probing. This would allow us to combine the OnePlus 6 and 6T devicetrees into one and produce the correct DT at runtime.

  2. The more "sane" option is to chainload a bootloader like u-boot and implement DT matching there (by reading cmdline from the stock bootloader for example), pick the right DTB and boot the kernel. u-boot does now boot on SDM845 but we're some ways of getting UFS support, this also comes with other complexities like finding a nice way to install the bootloader.

A new deviceinfo format

The deviceinfo format is really really nice, except for the fact that every dang device package conflicts with every other one, we should fix this by renaming deviceinfo to the format: deviceinfo.$VENDOR-$CODENAME, e.g. deviceinfo.oneplus-enchilada, we can then match generic device ports by globbing for deviceinfo.generic*.

Alternatively, we could make this an even more generic solution by adding some numbers, deviceinfo.10.$VENDOR-$CODENAME for devices, deviceinfo.90.generic-$TYPE for generic deviceinfo parts, this leaves it open an expansion in the future.

There are a few ways this might be improved, we could implement some post-upgrade script / apk trigger which parses all deviceinfo files, deals with ordering and produces the final /etc/deviceinfo file, this way existing tools will still be able to rely on /etc/deviceinfo to represent the running device, this seems like a sensible approach to just handle it without adding complexity to whatever software might be interested in parsing /etc/deviceinfo and removes the possibility of different tools parsing in different orders leading to different values being read. This would have to run at first boot and on device package upgrades.

Alternatively, we take the naive approach currently implemented here which is to just glob and let the shell handle it, I expect this to cause havoc with CI.

To summarise

  • How should we deal with device specific and generic deviceinfo parts?
  • How should we install multiple deviceinfo files?
  • What requirements should there be to justify a generic device port?
  • Where should generic ports go in pmaports? Maybe device/generic/...?

ToDo

  • Move device-generic-sdm845 to testing
  • Find the best way forward for supporting the 6T and both beryllium panel variants - we really shouldn't be expecting users to find out what panel type they have.
  • Add proper support for generic deviceinfo files to pmbootstrap
  • Create a tool for combining deviceinfo files in the right order
  • Replace fbsplash with something that isn't tied to the resolution (can center now)
  • ... anything else?

This MR depends on https://gitlab.com/postmarketOS/boot-deploy/-/merge_requests/6 and https://gitlab.com/postmarketOS/pmbootstrap/-/merge_requests/2120

Edited by Administrator

Merge request reports