June 2014 - openSUSE ARM - openSUSE Mailing Lists

[opensuse-arm] SR for JeOS: add cubox-i image
by Josua Mayer 12 Jun '14

12 Jun '14

Hi, So I have finalized the changes required to build a bootable JeOS image for cubox-i. 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] openSUSE on ARM status update
by Guillaume Gardet 12 Jun '14

12 Jun '14

Hi, Here are some information about openSUSE on ARM. * Firstly,, the good news: - openSUSE 13.1 image for Raspberry Pi is now bootable (no need to resize the FAT boot partition anymore.). - Chromebook images are now able to boot after the first boot. * The problems : - Qemu images (armv6l and aarch64) are broken when parted is used with a "Invalid type 0x9" error message. Andreas, you may help here according to this thread: http://lists.opensuse.org/opensuse-arm/2014-01/msg00090.html - Factory Chromebook image boots u-boot but nothing append then (no display, no SD resize). - Factory E17 and XFCE images are unresolvable due to missing icedtea-web. It seems it has been dropped from factory. Is it really the case? If so, I can update the image packagelist. - armv7l factory images are not bootable (fail in initrd) because MMC modules are not loaded in the initrd due to a dependency loop. Should be fixed in next kernel update thanks to the Matwey patches: http://lists.opensuse.org/opensuse-kernel/2014-06/msg00000.html - But latest armv7l kernels from Kernel:HEAD are broken: https://build.opensuse.org/project/monitor/Kernel:HEAD but fixes should be on the way. - Some images are not xz compressed before publishing (13.1 Raspberry Pi, Factory Chromebook, maybe more). Guillaume -- To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org

3 4

[opensuse-arm] [PATCH] Disable OMAP4 video to avoid build failure.
by Matwey V. Kornilov 11 Jun '14

11 Jun '14

Reference: http://lists.opensuse.org/opensuse-arm/2014-06/msg00004.html Signed-off-by: Matwey V. Kornilov <matwey.kornilov(a)gmail.com> --- config/armv7hl/default | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/config/armv7hl/default b/config/armv7hl/default index 62d484b..be36a40 100644 --- a/config/armv7hl/default +++ b/config/armv7hl/default @@ -5406,7 +5406,7 @@ CONFIG_USB_MSI3101=m CONFIG_MEDIA_TUNER_MSI001=m # CONFIG_VIDEO_TCM825X is not set CONFIG_USB_SN9C102=m -CONFIG_VIDEO_OMAP4=y +# CONFIG_VIDEO_OMAP4 is not set # CONFIG_VIDEO_OMAP4_DEBUG is not set # CONFIG_DVB_RTL2832_SDR is not set CONFIG_LIRC_STAGING=y -- 1.8.1.4 -- To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org

2 1

[opensuse-arm] Re: [opensuse-kernel] [PATCH] ARM: update armv7 default config - master branch
by Guillaume Gardet 11 Jun '14

11 Jun '14

CC'ing -arm ML Le 03/04/2014 13:48, Alexander Graf a écrit : > > On 03.04.14 13:47, Guillaume Gardet wrote: >> Le 03/04/2014 13:39, Alexander Graf a écrit : >>> On 02.04.14 20:48, Guillaume Gardet wrote: >>>> Hi, >>>> >>>> please find in attachment an ARMv7 -default config update to fix Ethernet and HDMI output on iMX6 SABRE Lite board. It also add initial support to USB on this board. >>>> >>>> This patch is against master branch. >>>> >>>> Signed-off-by: Guillaume GARDET <guillaume.gardet(a)opensuse.org> >>> Moving modules from =m to =y is the wrong answer usually. Why don't the modules work as modules? >> I do not know. >> Modules are loaded with no error but they do not work. The fact is switching FEC and SDMA from =m to =y fix the problems. It is true for 13.1 and master branches. > > Yes, I've spent some time myself to fix FEC as a module on i.MX53 a while ago. We really don't want to even start going into the game of enabling random devices as =y on the default config, otherwise we'll end up with a 30MB kernel on all boards. I agree, but the fact is we have no board which works really fine ATM. See: http://en.opensuse.org/openSUSE:Supported_ARM_boards#13.1 There are only RPi and Chromebook which have a correct support (and they use _downstream_ kernels). But chromebook boot only once and need a hack to boot then (I am on it, Marcus gave me some hints to fix that using kiwi hooks) and had a lot of X stability problems (random freezes, X crash when switching VT). Raspberry Pi is not booting at all as is (kiwi partitioning bug) and need a hack to get a bootable image: http://en.opensuse.org/HCL:Raspberry_Pi#Known_Issues Maybe Beaglebone or Beaglebone black have a good support? (I do not have such devices and there is no feedback on our wiki) Now, SABRE Lite is the only board where I got graphics working with upstream kernel. The last blocking problem on this board is USB which is not working, even with imx_v6_v7_defconfig. The main things to do for boards support are : 1) Get boards booting Linux (should be a minimum). 2) Have a maximum number of supported devices (USB, sound, video, etc.) on each board (even if it does mean to have '=y' instead of '=m'). 3) Clean-up / fix our kernel / kernel configs to use modules (=m) instead of built-in (=y) when it is possible. I think we should use again our Trello board or setup a wiki page or something to write down what must be done for each board and who is taking care of each task. What do you think about that? Guillaume -- To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org

3 5

[opensuse-arm] kernel-default 3.15-rc5 build failing on armv7l
by Andreas Färber 05 Jun '14

05 Jun '14

Hello, And another build failure: [ 7576s] CC [M] drivers/gpu/drm/msm/msm_fbdev.o [ 7578s] /home/abuild/rpmbuild/BUILD/kernel-default-3.15.rc5/linux-3.15-rc5/drivers/gpu/drm/msm/msm_fbdev.c: In function 'msm_fbdev_create': [ 7578s] /home/abuild/rpmbuild/BUILD/kernel-default-3.15.rc5/linux-3.15-rc5/drivers/gpu/drm/msm/msm_fbdev.c:108:2: error: passing argument 3 of 'msm_gem_get_iova_locked' from incompatible pointer type [-Werror] [ 7578s] msm_gem_get_iova_locked(fbdev->bo, 0, &paddr); [ 7578s] ^ [ 7578s] In file included from /home/abuild/rpmbuild/BUILD/kernel-default-3.15.rc5/linux-3.15-rc5/drivers/gpu/drm/msm/msm_fbdev.c:18:0: [ 7578s] /home/abuild/rpmbuild/BUILD/kernel-default-3.15.rc5/linux-3.15-rc5/drivers/gpu/drm/msm/msm_drv.h:153:5: note: expected 'uint32_t *' but argument is of type 'dma_addr_t *' [ 7578s] int msm_gem_get_iova_locked(struct drm_gem_object *obj, int id, [ 7578s] ^ [ 7578s] cc1: all warnings being treated as errors [ 7578s] /home/abuild/rpmbuild/BUILD/kernel-default-3.15.rc5/linux-3.15-rc5/scripts/Makefile.build:334: recipe for target 'drivers/gpu/drm/msm/msm_fbdev.o' failed [ 7578s] make[6]: *** [drivers/gpu/drm/msm/msm_fbdev.o] Error 1 [ 7578s] /home/abuild/rpmbuild/BUILD/kernel-default-3.15.rc5/linux-3.15-rc5/scripts/Makefile.build:495: recipe for target 'drivers/gpu/drm/msm' failed [ 7578s] make[5]: *** [drivers/gpu/drm/msm] Error 2 [ 7578s] /home/abuild/rpmbuild/BUILD/kernel-default-3.15.rc5/linux-3.15-rc5/scripts/Makefile.build:495: recipe for target 'drivers/gpu/drm' failed [ 7578s] make[4]: *** [drivers/gpu/drm] Error 2 [ 7578s] /home/abuild/rpmbuild/BUILD/kernel-default-3.15.rc5/linux-3.15-rc5/scripts/Makefile.build:495: recipe for target 'drivers/gpu' failed [ 7578s] make[3]: *** [drivers/gpu] Error 2 [ 7578s] /home/abuild/rpmbuild/BUILD/kernel-default-3.15.rc5/linux-3.15-rc5/Makefile:904: recipe for target 'drivers' failed [ 7578s] make[2]: *** [drivers] Error 2 [ 7578s] Makefile:148: recipe for target 'sub-make' failed [ 7578s] make[1]: *** [sub-make] Error 2 [ 7578s] Makefile:26: recipe for target 'all' failed [ 7578s] make: *** [all] Error 2 I guess disabling the msm DRM module would be the easiest workaround. Won't get around to it right away myself. Guillaume? Also, can anyone drop x86_64 from "ARM" repository in Kernel:HEAD? https://build.opensuse.org/project/repositories/Kernel:HEAD Similarly, why is armv6l selected for "Ports" but not armv7l? Would've expected it the other way around. Regards, Andreas -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg -- To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org

6 10

[opensuse-arm] Porting to Cubox-i
by Josua Mayer 04 Jun '14

04 Jun '14

Hello everyone, I have been working on getting opensuse running on the Cubox-i for a while and want to tell about the progress: So far, I have patched the u-boot and JeOS packages to provide a booting image. That is, bootloader is in place and kernel, ramdisk and fdt are loaded. Work is done in home:mayerjosua:cubox-i project on OBS. While the Cubox-i should boot a vanilla 3.14 kernel, the current kernel-default never gets to detecting the sdcard. I haven't tried to debug this yet. Instead I have packaged the 3.0.35 kernel by SolidRun and am using that one currently. But there are issues with this setup: firstboot works, but then there is no new initrd created. That has to be done manually after postinstall by running: mkinitrd -k /boot/zImage-3.0.35-cubox-i -i /boot/initrd-3.0.35-cubox-i -M /boot/System.map-3.0.35-cubox-i mkinitrd says in its output that kernel modules are not available. I have no cue whats going on there, but I some kernel modules are installed. The important stuff is builtin to the kernel so no modules are needed at boot time. Yet I dont like this behaviour, mkinitrd should treat that kernel like any other. The 3.0.35 kernel can not be used for kiwi image builds. Building an image fails with parted: error notifying kernel about <whatever> -- invalid argument I wonder if anyone knows a simple fix for this problem. There is a 3.10 kernel available for the cubox-i, but it doesn't work with my monitor so I am not using it. Vivante Binary Blobs: The 3.0.35 kernel has the vivante kernel parts integrated and I have succeeded in running the vivante demos exactly once now. I am working on creating proper packages of them. What I wonder is how they might be provided to the user in the future. At the moment I am hosting a repository with them on a server, but can tehy be provided by opensuse? Kind regards and happy ARMing Josua Mayer -- To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org

2 3

[opensuse-arm] vexpress
by Matwey V. Kornilov 02 Jun '14

02 Jun '14

Hi, Why kernel/initrd tarball is not published for Factory? Is there a way to boot the image in qemu from .raw? -- To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org

1 1