I know that I missed the opportunity to order librem 5 dev board and I don’t want to wait for the delivery of the phones, so I thought about buying I.MX8 dev board, just to start learning.
I found PICO-PI-IMX8M also NXP Evaluation kit MCIMX8M-EVK.
Has anyone tried something like this? Or maybe advise a dev board?
I was looking at the same things curious if it would help get me a head start.
Why don’t you use the images for a virtual machine. QEMU, for example:
https://developer.puri.sm/Boards/qemu.html
Cheers,
orrence.
I’ve been using that but I can’t get it to rotate properly.
Because it lags and too far from the hardware.
Interest in this as well.
I would reccomend the PICO-PI-IMX8M-DEV. It seems to be the most similar to the Librem development kit at the most reasonable cost.
The following is a breakdown of similarities and differences between the two.
Information on the Librem 5 DevKit comes from a blog post that Purism has since taken down and may therefore be incorrect.
Information on the Wand PICO-PI-IMX8M-DEV comes from here and here and should be correct.
| Librem Dev Kit | PICO-PI-IMX8M-DEV | |
| Processor | i.MX 8M | i.MX 8M |
| Display | LCD, 5.7", 720x1440 | LCD, 5", 720x1280 |
| Modem | SIMCom 7100A/E | None |
| WiFi+BT | Redpine RS9116 M.2 module: 2.4/5GHz, no 802.11ac | Qualcomm Atheros QCA9377: 802.11 a/b/g/n/ac |
| Camera Sensor | Omnivision OV5640 | Omnivision OV5645 |
In think the same way. You can certainly collect almost identical board, buy MCIMX8M-EVK, Redpine RS9116 M.2 module, SIMCom 7100A/E and LCD, 5.7", 720x1440, but it will be expensive.
Where can one buy the Redpine RS9116 M.2 module? Is it this? https://www.mouser.com/ProductDetail/Redpine-Signals/RS9116N-DBT0-MB0-12?qs=lc2O%2bfHJPVYJPiz%2bvjBRZg==
Is the driver already libre, or is Redpine still working on that? Does anyone have a picture of the device? Is it Key E?
Also, https://puri.sm/posts/librem5-2018-09-hardware-report/ says, “Redpine Signal will supply us with a low power WiFi/Bluetooth solution using SDIO as the data interface.”
Does this mean that the m.2 module isn’t going to be used and a different SDIO module will be used instead?
I bought this board. Downloaded latest build image for devkit and flash it. I left original kernel and device tree from TechNexion.
And I got this when starting phosh.service.
Maybe someone also tried to run and it worked. U-boot was from TechNexion.
With Linux pureos-test 4.18.11-00356-g336a968-dirty problem same:
I used:
U-Boot 2017.03-tn-imx_v2017.03_4.9.88_2.0.0_ga-test+gbcface4
Linux version 4.9.51-tn-imx_4.9.51_imx8m_ga-test+ga329f6f - original kernel.
root@pureos-test:~# dpkg -l | grep librem
ii libegl-mesa0:arm64 18.3.2-1purple+librem5.2~117838.gbpa57af7 arm64 free implementation of the EGL API --y
ii libegl1-mesa:arm64 18.3.2-1purple+librem5.2~117838.gbpa57af7 arm64 transitional dummy package
ii libegl1-mesa-dev:arm64 18.3.2-1purple+librem5.2~117838.gbpa57af7 arm64 free implementation of the EGL API --s
ii libgbm-dev:arm64 18.3.2-1purple+librem5.2~117838.gbpa57af7 arm64 generic buffer management API -- deves
ii libgbm1:arm64 18.3.2-1purple+librem5.2~117838.gbpa57af7 arm64 generic buffer management API -- runte
ii libgl1-mesa-dev:arm64 18.3.2-1purple+librem5.2~117838.gbpa57af7 arm64 free implementation of the OpenGL APIs
ii libglapi-mesa:arm64 18.3.2-1purple+librem5.2~117838.gbpa57af7 arm64 free implementation of the GL API -- y
ii libgles2-mesa-dev:arm64 18.3.2-1purple+librem5.2~117838.gbpa57af7 arm64 free implementation of the OpenGL|ES s
ii libglx-mesa0:arm64 18.3.2-1purple+librem5.2~117838.gbpa57af7 arm64 free implementation of the OpenGL APIy
ii libmm-glib0:arm64 1.9.0~git201809273f6f4f-1+librem5.2~5856.gbpc1ed9a arm64 D-Bus service for managing modems - ss
ii librem5-base 3~47.gbpe29e26 all Metapackage for the Librem5
ii librem5-base-defaults 3~47.gbpe29e26 all Default themes and configuration for 5
ii librem5-dev-tools 3~45.gbpa24bb5 all Librem5 development tools
ii librem5-devkit-check 0.0.3~100.gbpc7c72f all Check script for the librem5-evk (dev)
ii librem5-gnome 3~47.gbpe29e26 all GNOME metapackage for the Librem5
ii librem5-gnome-base 3~47.gbpe29e26 all GNOME base metapackage for the Librem5
ii librem5-gnome-dev 3~45.gbpa24bb5 all Librem5 GNOME development packages
ii librem5-gnome-phone 3~47.gbpe29e26 all GNOME PTSN telephony metapackage for 5
ii libwlroots-examples 0.0.0~git20180912.1-1~librem5.2~3112.gbp23bec6 arm64 Modular wayland compositor library - s
ii libwlroots0:arm64 0.0.0~git20180912.1-1~librem5.2~3112.gbp23bec6 arm64 Modular wayland compositor library - y
ii mesa-common-dev:arm64 18.3.2-1purple+librem5.2~117838.gbpa57af7 arm64 Developer documentation for Mesa
ii mesa-va-drivers:arm64 18.3.0-2~pureos+librem5.3~117597.gbpa21991 arm64 Mesa VA-API video acceleration drivers
ii modemmanager 1.9.0~git201809273f6f4f-1+librem5.2~5856.gbpc1ed9a arm64 D-Bus service for managing modemsIIRC, the Librem5 developers are planning on doing some sort of pixel multiplying with the screen. (Which, I find disappointing. I like my high res screens!) So, I wouldn’t be surprised to find out that whatever they are doing isn’t quite compatible with the hardware on your dev kit. (But, full disclosure, I am FAR from an expert on the inner workings of X-Windows, compositors, etc. So, this is just a guess.)
My suggestion would be to post on the developer mailing list and see if they are willing to help you try to get things going. (That said, the screen on my dev kit has never lit up, so you are farther along than I am! 
)
I don’t want to come across as being negative, but I don’t think the Librem 5 developers will want to spend too much time debugging phosh on another development board at this point.
I would recommend trying a variety of shells and display managers on the hardware and seeing if the screen works with those first. Then look at the resolution in the configuration files for phosh (run dpkg -L phosh) and start digging from there.
Good luck!
Hi @david.boddie,
I don’t view your message as negative in any way. I considered that angle before posting my comment. I agree that they probably won’t want to spend much time, but my thinking was more that perhaps they could give them a starting point for troubleshooting the problem on their own. After all, it is in their best interest to have as many people looking at code, and helping out as possible. But, I also understand that they are probably under a lot of pressure to deliver.
In the end, my goal was simply to offer one additional way of attacking the problem. As I believe that more developers poking at this will mean a better end result. But, I understand the other point of view as well.
I was more replying to @Driim that to you, though I didn’t want to discourage either of you from investigating problems with the software. I was more worried about having to support two different development boards: one that I have access to and another that I don’t. One is enough for me at the moment!
However, that shouldn’t stop others from making suggestions and helping each other out.
For a start, I spent some time running Librem5 kernel on this board (if it is interesting to someone, then kernel with my patches is here).
But the problem has not disappeared anywhere. Weston and kmscube work fine. I can conclude that the problem is most likely in rootston or phosh. And in general, it will be enough for me to point to a possible place, then I will try to solve the problem by myself.
So, I was able to fix this problem. I created repo with my patch(just in case someone will try it).
Lockscreen looks fine.
But the rest… not so fine.
And now I want to understand, this is because I have a different hardware component, or everyone has same.
I think some applications aren’t ported with libhandy yet so they still appear as on desktop.
Is there a list of ported applications?
