September 2014 - openSUSE ARM - openSUSE Mailing Lists

[opensuse-arm] i.mx6 vivante binary blobs packaged
by Josua Mayer 04 Sep '14

04 Sep '14

And another one. I have turned the vivante binary blobs for i.mx6{q,dl} into rpm packages and made them available in a repository[0]. They may be of interest to any hardware containing the i.mx6, so feel free to use them! But there is a major difficulty about them: When trying to compile programs using xorg on systems with those RPMs installed, xorg-devel requires dri.pc. Now dri.pc is provided by Mesa-devel, which requires Mesa-libGL-devel, Mesa-libEGL-devel, ... which in turn require the Mesa-libGL1 and Mesa-libEGL. It is impossible to keep the vivante binaries without breaking some dependency. I think it would be nice if dri.pc was not provided by Mesa-devel, but by its own package, e.g. Mesa-dri-devel. To use the blobs, it is also required to patch[1] libdrm and rebuild xorg against that. [0] https://github.com/Artox/vivante-packaging http://vps.jm0.eu/vivante [1] https://github.com/Freescale/meta-fsl-arm/blob/master/recipes-graphics/drm/… -- To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org

1 0

[opensuse-arm] opensuse cubox-i and hummingboard support status
by Josua Mayer 04 Sep '14

04 Sep '14

Hello everybody, I want to inform you all about the current state of the cubox-i and hummingboard devices on opensuse, and some outstanding issues that may apply to other devices as well. Right now, opensuse 13.1 is running on all the above mentioned devices as either JeOS, or graphical images, with only a few problems left. There is Mozilla Firefox, it currently does not build on arm natively but I produced qemu builds that work reasonably well. But there is a serious problem: clicking on the download status widget next to the addressbar durign a download, makes firefox crash. Then it will crash on every restart until the profile is deleted(there may be another way to stop it). I am interested if this issue exists on other arm devices too. Then, there is WebGL. Firefox is able to use EGL and GLES for webgl, supposedly. The firefox arm builds are currently configured to use egl by default. In my tests, the get.webgl.org sample works fine but everything else I tried crashes horribly. Again, I'd be interested if this occurs on other arm devices using accelerated graphics too. Chromium. While it did nto build on arm for quite a while, I switched it do a so-called component build, and now the final linking step now works fine on the opensuse arm buildbots. Binaries are produced in network:chromium as I am writing this. Here, too, there should be WebGL available. I am not aware of any compile-time switches that tell chromium to use/enable gl or gles backend for it, but there is a runtime-switch "--use-gl=egl" which seems to do the job. Sadly, it does not work for me. about:gpu shows some acceleration for a few seconds, then everything turns to software rendering with an error that the gpu process died. I know that webgl works on a debian build with the same hardware. So again, I am wondering if other people can get webgl working with chromium on their hardware. Factory: While opensuse factory has been without a kernel-default binary far too long now, I ran a test using 3.16 and found that it works with the cubox-i without any modifications. kind regards Josua Mayer -- To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org

1 0

[opensuse-arm] AArch64 EFI builds
by Alexander Graf 02 Sep '14

02 Sep '14

Howdy, I've enabled a new "efi" target for AArch64 image builds. This target takes the default kernel and builds an image with it for SBSA and SBBA compliant AArch64 systems. In a nutshell, it hopefully allows us to have a single image for all AArch64 platforms we care about. To try it out, fetch it from http://download.opensuse.org/ports/aarch64/factory/images/ (a patched kiwi is still building, expect the images to drop out in a few hours - I've verified that the image is built correctly locally) and unless you have real hardware, get yourself a copy of the Foundation model: http://www.arm.com/products/tools/models/fast-models/foundation-model.php and a recent build of uEFI for the Foundation model: http://releases.linaro.org/13.12/components/kernel/uefi-linaro/uefi-bootstr… http://snapshots.linaro.org/components/kernel/linaro-edk2/22/release/uefi_f… Then you can just run a guest with $ Foundation_v8 \ --image=uefi-bootstrap-el3-foundation.axf \ --no-secure-memory \ --data=uefi_foundation.bin@0xa0000000 \ --block-device=openSUSE*efi*raw For some reason the firmware does not detect the default boot entry of the disk (to be debugged), so you have to manually point it to efi\boot\boota64.efi as boot binary in its menu. Then you should see grub showing up with a proper menu. You can select the entry it tries to start the kernel and then at least for me I get a good bunch of Synchronous Exception at 0x0000000080080210 but all of the groundwork is there for people to play with it now :). Happy ARM hacking! Alex -- To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org

3 16