(01-16-2020, 11:59 PM)NigelT Wrote: The block device names are as follows:
mmcblk1 = internal eMMC device
mmcblk0 = microSDXC card
However, once booted into Debian bullseye/sid, those devices have different names
mmcblk2 = internal eMMC device
mmcblk1 = microSDXC card
Note how mmcblk1 can either be the internal eMMC or the MicroSD card.
Good point.
We could perhaps point the default at /dev/disk/by-path/platform-fe320000.dwmmc instead (and add some code to follow the softlink). What name does the uSD card appear at under /dev/disk/by-path when running with the default Debian 9 kernel?
dptx.bin loading works OK for me meaning the (D)isplay (P)ort (TX) over USB-C works ok for me ;-)
I think this is because I have a slightly customized install where only /home is encrypted. As a result although the first two load attempts fail the firmware does loads on its third try after the rootfs is mounted. Anyone with an encrypted rootfs will have problems because the third try will take place during the rootfs decrypt prompt and will also fail.
Ultimately this is causes because the drm module is built into the kernel so the initramfs tools cannot find it: https://bugs.debian.org/cgi-bin/bugrepor...=857054#10
There is a hack further up in the above bug report showing how to add an initramfs hook to ensure the dptx.bin firmware gets included in the initramfs. If you have have problems with this firmware loading then please experiment with that and report back!
(01-17-2020, 04:21 AM)e-minguez Wrote: What about having the wiki enabled in the github repo?
I will if that's where people are happiest editing it but personally I was thinking of a page on the pine64 wiki.
As discussed in the Roadmap I rather hope that upstream Debian (and the PBP bootloaders) will improve to the point my installer becomes obsolete. At that point a wiki page on pine64 wiki would, as I remove obsolete hacks from the installer, end up describing the upstream status.