So, my Purism Librem13v2 finally arrived. Ordered in November and delivered in February, 2 months later than first promised(mid december), due to high demand and TPM. Missing the USB stick with Qubes OS, but I was promised they will send it in a few weeks time.
Long anticipated, I looked forward to run Qubes 4.0rc4, but the installed Coreboot 4.6 version does not support Qubes OS version 4 yet, and we still await the official 4.7 release, so I was forced(and recommended) to run Qubes 3.2, with the issues it presented.
I now run Qubes 3.2, restored my VMs from my older Lenovo Yoga 2 Pro, and most stuff seems to work, except my Kali VM. A reinstall did not help :(, so I might jump to forums, if the issue persists.
Workaround:
After installing qubes 3.2, the system hangs during boot up. The solution is somewhat provided here: https://forums.puri.sm/t/librem-13v2-qubes-stuck-at-booting-from-hard-disk-after-install/1072/10
Boot Qubes installer into recovery:
Select Troubleshooting:
Select Rescue a Qubes system:
After booting to anaconda installer choose
1) Continue
(and enter your Qubes partition password if you chose to encrypt it during install)
In the prompt:
chroot /mnt/sysimage
lsblk(To identify the whereabouts of your Qubes installation.)
GRUB_CMDLINE_XEN_DEFAULT="console=none dom0_mem=min:1024M dom0_mem=max:1024M"(Fixed size, following recommendations: https://wiki.xen.org/wiki/Xen_Project_Best_Practices but looking at another qubes installation it says 1024/4096 as min/max. So feel free to pick)
grub2-install /dev/nvme0n(or where your Qubes installation lies.)
grub2-mkconfig
I managed to do without the GRUB_XEN thingy, but don’t know if there is a hidden effect of it somewhere.
exit (leave the chroot environment)
reboot
Reboot and voila. The system starts, but has a cluttered text interface for the disk encryption password, instead of the graphical part. 
Here the normal graphical question:
I can live with that, but not ideal. Hopefully the coreboot 4.7 and Qubes 4 will work better together.
Initial setup after reboot:
Qubes needs to finish up the installation, asking some relevant questions about sys-usb, whonix, tor, etc.
First an opening window of no interest, but a button to click….
Then we have to select if updates should go through tor and if we need usb, and I recommend the usage of a separate qubes for USB. sys-usb might say experimental, but updates seem to fix what issues there has been.
The login window comes up and the user created during install can be used to login.
Notice the lack of wifi support for the machine.
This is purely a one time only thing and will come up after reboot:
You will be asked how you wan’t, if you wan’t, to use tor. That should be a no brainer, if you wan’t to run qubes, but I will recommend some machines configured without tor, since cloudflare and others just hate tor and blocks you terribly with captchas, etc.
Then you should update all the machines, so your sys-usb won’t hang during startup, etc.
commands like :
sudo qubes-dom0-update (updates the current dom0 qube)
sudo qubes-dom0-update qubes-template-fedora-26 (installs the newer fedora 26 template, to replace fedora-23 as default in VM Manager and the rest of the pre-configured machines is a first.
Then you can select “Update VM” on the rest of the templates and begin to either restore images from a previous qubes installation or configure email clients or other settings on your new machines.
I have problems creating kali images on the Purism Librem13v2, that works fine on other qubes-machines running Lenovo and HP, so I guess that there is something about Purism Librem13v2 and Qubes that is just not fun at all.
Hopefully CoreBoot 4.7 and Qubes 4.x will run better.