openSUSE ARM April 2014

arm@lists.opensuse.org

19 participants
23 discussions

[opensuse-arm] Re: [opensuse-kernel] [PATCH] ARM: update armv7 default config - master branch

by Guillaume Gardet

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

7 years, 11 months

[opensuse-arm] Package clamav for ARM

by Freek de Kruijf

Some time ago I generated the clamav rpm package in OBS as a copy from that package in the security project. Somehow the status of this rpm for different ARM architectures is Not Public. I wonder why. I can't find this package in a repository except my own. The oss repository only contains the srcrpm of clamav. Is this a bug? -- fr.gr. Freek de Kruijf -- To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org

8 years

[opensuse-arm] BeagleBone Black: openSUSE 13.1

by Matwey V. Kornilov

Hi, I've just checked JeOS. Now, 13.1 works as described in https://en.opensuse.org/HCL:BeagleBone_Black -- To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org

8 years

[opensuse-arm] systemd waiting on dev-ttySAC3.device

by Andreas Färber

Hello, On Exynos5 devices I've seen the following problem with Factory rootfs. For example, using upstream v3.14 plus a .dts patch with exynos_defconfig (devtmpfs) on Arndale Octa: [ 10.900000] systemd[1]: Expecting device dev-ttySAC3.device... Expecting device dev-ttySAC3.device... [...] [ TIME ] Timed out waiting for device dev-ttySAC3.device. [DEPEND] Dependency failed for Serial Getty on ttySAC3. systemd proceeds printing to console=ttySAC3,115200n8 until reaching target Graphical Interface, but I do not get a login prompt on serial. The YaST firstboot worked on first run, too. No HDMI output, and network not blinking/lit. Booting is currently broken on 3.15.0-rc2-00205-g9a60ee1, and we do not have a building kernel-exynos package, therefore vanilla 3.14 plus http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/arch/… Initially I had seen this issue on a downstream kernel 3.4.x on my ODROID-XU with s/ttySAC3/ttySAC2/g. There, I was able to log in via ssh and confirm that /dev/ttySAC2 was in fact present. Any suggestions how to debug what is going wrong there? Thanks, 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

8 years

[opensuse-arm] Package clamav for ARM

by Freek de Kruijf

8 years, 1 month

[opensuse-arm] Does NOT boot on Pandaboard-ES Rev B3

by 孙钰

Hi all, Neither the 12.3 and 13.1 image boot on Pandaboard-ES Rev B3 because the Modification of Elpida DDR2 RAM Here follows the serial port messages: U-Boot SPL 2013.04 (Jan 08 2014 - 14:33:37) OMAP4460 ES1.1 SDRAM: identified size not same as expected size identified: 0 expected: 40000000 Regards, SunYu -- To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org

8 years, 1 month

[opensuse-arm] Can't make recent Raspberry Pi image to work

by Freek de Kruijf

I downloaded the image from http://download.opensuse.org/repositories/devel:/ARM:/13.1:/Contrib:/Raspbe… Used the command "xzcat [image].raw.xz | dd bs=4M of=/dev/sdc; sync" to write the image to the SD card. While the SD card was still plugged in, I gave the command # parted /dev/sdc --script -- resize 1 1049kB 185MB which changed the FAT partition to 185MB, see the output below. # parted /dev/sdc --script print Model: SD/MMC Card Reader (scsi) Disk /dev/sdc: 3980MB Sector size (logical/physical): 512B/512B Partition Table: msdos Number Start End Size Type File system Flags 1 1049kB 185MB 184MB primary fat16 boot, lba, type=0e 2 212MB 976MB 764MB primary ext4 type=83 Running this SD card in the Raspberry Pi does not bring up the network, although I do see activity on the network. -- fr.gr. member openSUSE Freek de Kruijf -- To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org

8 years, 1 month

[opensuse-arm] Freedreno vs. X11 module ABI mismatch

by Andreas Färber

Hi, On my IFC6410 board running Factory I am seeing the following error: [ 14129.554] (II) LoadModule: "freedreno" [ 14129.556] (II) Loading /usr/lib/xorg/modules/drivers/freedreno_drv.so [ 14129.557] (II) Module freedreno: vendor="X.Org Foundation" [ 14129.557] compiled for 1.15.0, module version = 1.0.0 [ 14129.557] ABI class: X.Org Video Driver, version 15.0 [ 14129.557] (EE) module ABI major version (15) doesn't match the server's version (17) [ 14129.557] (II) UnloadModule: "freedreno" [ 14129.557] (II) Unloading freedreno [ 14129.557] (EE) Failed to load module "freedreno" (module requirement mismatch, 0) Rob Clark, the freedreno author, told me that this indicates the xf86-video-freedreno driver was built against a too old X11, i.e. X11 is newer than freedreno. However, I observed xf86-video-freedreno package [1] going from "Blocked" to "Succeeded", without a new package becoming available via OBS web interface (and not getting published either). Among others there's BuildRequires: pkgconfig(xorg-server) which I had copied from another xf86-video-* package and would expect it to trigger a rebuild if X11 is updated... Here's my installed versions: i | libdrm_freedreno1 | Paket | 2.4.53-1.1 | armv7hl | openSUSE-Factory-repo-oss i | xf86-video-freedreno | Paket | 1.0.0-2.1 | armv7hl | openSUSE-Factory-repo-oss i | xorg-x11-driver-video | Paket | 7.6_1-13.1 | armv7hl | openSUSE-Factory-repo-oss i | xorg-x11-server | Paket | 7.6_1.15.99.902-1.1 | armv7hl | openSUSE-Factory-repo-oss Any hints what might be going wrong here? Thanks, Andreas [1] https://build.opensuse.org/package/show/openSUSE:Factory:ARM/xf86-video-fre… -- 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

8 years, 1 month

Re: [opensuse-arm] SR for openSUSE:13.1:Ports kernel

by Alexander Graf

On 27.04.14 17:23, Matwey V. Kornilov wrote: > > > I don't know. If it is the best solution, then we can. Basically, what > I need is to fetch the 11 patches from Kernel:openSUSE-13.1 > However, I am not aware of how does kernel updates usually get into > Ports tree. > Please don't top post :). I don't think we have a really good solution for this. The "usual" way we envisioned things to work is that openSUSE:<release> just contains everything necessary for the release. Any board we have to enable after that process should just get a Contrib subproject where we can add newer versions of kernels etc specific to that board. In parallel all the changes go into Factory where we can then enable that board for the next <release> version of openSUSE. However, getting hardware support working for a release is so incredibly hard that I'm fairly sure we'd end up with an empty set of hardware platforms if we really went with that plan. So we started loosing up the requirements. I'm not sure up to which point it does make sense to loosen them though. Would it help you if we create a Contrib for the BeagleBone and add you as admin for that? There you could linkpac the JeOS package inside and copypac the latest kernel and then have your own playing ground for that particular platform without necessarily relying on us. Alex -- To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org

8 years, 1 month

[opensuse-arm] osc broken in Factory:ARM

by Andreas Färber

Hey, Recently Dirk assured that the latest version of python-M2Crypto got published for fixing a library load error on osc co. Unfortunately since then I am seeing a different error: $ osc getbinaries openSUSE:Factory:ARM xf86-video-freedreno standard armv7l cannot import name HTTPSConnection M2Crypto is needed to access https://api.opensuse.org in a secure way. Please install python-m2crypto. $ osc co Xorg:X11 xf86-video-freedreno cannot import name HTTPSConnection M2Crypto is needed to access https://api.opensuse.org in a secure way. Please install python-m2crypto. python-M2Crypto is installed: i | python-M2Crypto | Paket | 0.22.3-1.1 | armv7hl | openSUSE-Factory-repo-oss Any help? Thanks, 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

8 years, 1 month

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

openSUSE ARM April 2014