- openSUSE ARM

[opensuse-arm] [PATCH] config: armv7hl/default: Disable CONFIG_USB_MUSB_TUSB6010
by matwey.kornilov＠gmail.com 19 Sep '14

19 Sep '14

From: "Matwey V. Kornilov" <matwey.kornilov(a)gmail.com> TUSB6010 is not used by any of our JeOSes*, but introduces issues with USB at BeagleBone. The way to resolve the issues is currently unknown, so we temporarily disable it. See for details: http://marc.info/?l=linux-usb&m=141088564307331&w=2 Cc: Guillaume Gardet <guillaume.gardet(a)free.fr> Signed-off-by: Matwey V. Kornilov <matwey.kornilov(a)gmail.com> --- * If you know JeOS which uses tusb6010 module, please inform config/armv7hl/default | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/config/armv7hl/default b/config/armv7hl/default index 379bcde..a957a9f 100644 --- a/config/armv7hl/default +++ b/config/armv7hl/default @@ -5509,7 +5509,7 @@ CONFIG_USB_MUSB_HDRC=m # CONFIG_USB_MUSB_HOST is not set # CONFIG_USB_MUSB_GADGET is not set CONFIG_USB_MUSB_DUAL_ROLE=y -CONFIG_USB_MUSB_TUSB6010=m +# CONFIG_USB_MUSB_TUSB6010 is not set CONFIG_USB_MUSB_OMAP2PLUS=m CONFIG_USB_MUSB_AM35X=m CONFIG_USB_MUSB_DSPS=m -- 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

1 0

[opensuse-arm] tusb6010 kernel module
by Matwey V. Kornilov 19 Sep '14

19 Sep '14

Hi, Which board use this module? BeagleBoard? -- To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org

2 7

[opensuse-arm] Utilite
by Ivan Skytte Jørgensen 18 Sep '14

18 Sep '14

I recently bought a Compulab Utilite Pro. It came with Ubuntu installed. I would like to get something else installed on it, preferably OpenSuSE. Since it already boots into Linux I'm wondering if I have really have to go the virtualbox+crosscompiliation route. I have an NFS server already so I could use nfsroot in U-Boot. As an intermediate step I could also set up Opensuse in an LXC container to verify that userland works. I'm not sure what the easiest approach would be. My goal is to use it as a headless searver running named/postfix/ssh/... Any advice is appreciated. Hardware details below. Regards, Ivan ---snip--- root@utilite-desktop:/etc# cat /proc/cpuinfo Processor : ARMv7 Processor rev 10 (v7l) processor : 0 BogoMIPS : 790.52 processor : 1 BogoMIPS : 790.52 processor : 2 BogoMIPS : 790.52 processor : 3 BogoMIPS : 790.52 Features : swp half thumb fastmult vfp edsp neon vfpv3 CPU implementer : 0x41 CPU architecture: 7 CPU variant : 0x2 CPU part : 0xc09 CPU revision : 10 Hardware : Compulab CM-FX6 Revision : 63012 Serial : ffff000000000000 root@utilite-desktop:/etc# lsusb -v Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Couldn't open device, some information will be missing Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass 9 Hub bDeviceSubClass 0 Unused bDeviceProtocol 1 Single TT bMaxPacketSize0 64 idVendor 0x1d6b Linux Foundation idProduct 0x0002 2.0 root hub bcdDevice 3.00 iManufacturer 3 iProduct 2 iSerial 1 bNumConfigurations 1 Couldn't get configuration descriptor 0, some information will be missing Couldn't get configuration descriptor 0, some information will be missing Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass 9 Hub bDeviceSubClass 0 Unused bDeviceProtocol 1 Single TT bMaxPacketSize0 64 idVendor 0x1d6b Linux Foundation idProduct 0x0002 2.0 root hub bcdDevice 3.00 iManufacturer 3 Linux 3.0.35-cm-fx6-6.1 ehci_hcd iProduct 2 Freescale On-Chip EHCI Host Controller iSerial 1 fsl-ehci.1 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 25 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0xe0 Self Powered Remote Wakeup MaxPower 0mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass 9 Hub bInterfaceSubClass 0 Unused bInterfaceProtocol 0 Full speed (or root) hub iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0004 1x 4 bytes bInterval 12 Hub Descriptor: bLength 9 bDescriptorType 41 nNbrPorts 1 wHubCharacteristic 0x0009 Per-port power switching Per-port overcurrent protection TT think time 8 FS bits bPwrOn2PwrGood 10 * 2 milli seconds bHubContrCurrent 0 milli Ampere DeviceRemovable 0x00 PortPwrCtrlMask 0xff Hub Port Status: Port 1: 0000.0507 highspeed power suspend enable connect Device Status: 0x0003 Self Powered Remote Wakeup Enabled Bus 002 Device 002: ID 0424:2514 Standard Microsystems Corp. USB 2.0 Hub Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass 9 Hub bDeviceSubClass 0 Unused bDeviceProtocol 2 TT per port bMaxPacketSize0 64 idVendor 0x0424 Standard Microsystems Corp. idProduct 0x2514 USB 2.0 Hub bcdDevice b.b3 iManufacturer 0 iProduct 0 iSerial 0 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 41 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0xe0 Self Powered Remote Wakeup MaxPower 2mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass 9 Hub bInterfaceSubClass 0 Unused bInterfaceProtocol 1 Single TT iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0001 1x 1 bytes bInterval 12 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 1 bNumEndpoints 1 bInterfaceClass 9 Hub bInterfaceSubClass 0 Unused bInterfaceProtocol 2 TT per port iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0001 1x 1 bytes bInterval 12 Hub Descriptor: bLength 9 bDescriptorType 41 nNbrPorts 4 wHubCharacteristic 0x0009 Per-port power switching Per-port overcurrent protection TT think time 8 FS bits bPwrOn2PwrGood 50 * 2 milli seconds bHubContrCurrent 1 milli Ampere DeviceRemovable 0x00 PortPwrCtrlMask 0xff Hub Port Status: Port 1: 0000.0100 power Port 2: 0000.0100 power Port 3: 0000.0100 power Port 4: 0000.0100 power Device Qualifier (for other device speed): bLength 10 bDescriptorType 6 bcdUSB 2.00 bDeviceClass 9 Hub bDeviceSubClass 0 Unused bDeviceProtocol 0 Full speed (or root) hub bMaxPacketSize0 64 bNumConfigurations 1 Device Status: 0x0001 Self Powered root@utilite-desktop:/etc# lspci -v 00:00.0 PCI bridge: Device 16c3:abcd (rev 01) (prog-if 00 [Normal decode]) Flags: bus master, fast devsel, latency 0 Memory at 01000000 (64-bit, prefetchable) [size=1M] Bus: primary=00, secondary=01, subordinate=01, sec-latency=0 I/O behind bridge: 00000000-00000fff Memory behind bridge: 01100000-011fffff [virtual] Expansion ROM at 01200000 [disabled] [size=64K] Capabilities: [40] Power Management version 3 Capabilities: [50] MSI: Enable- Count=1/1 Maskable+ 64bit+ Capabilities: [70] Express Root Port (Slot-), MSI 00 Capabilities: [100] Advanced Error Reporting Capabilities: [140] Virtual Channel 01:00.0 Ethernet controller: Intel Corporation I211 Gigabit Network Connection (rev 03) Subsystem: Intel Corporation Device 0000 Flags: bus master, fast devsel, latency 0, IRQ 155 Memory at 01100000 (32-bit, non-prefetchable) [size=128K] I/O ports at 1e00000 [disabled] [size=32] Memory at 01120000 (32-bit, non-prefetchable) [size=16K] Capabilities: [40] Power Management version 3 Capabilities: [50] MSI: Enable- Count=1/1 Maskable+ 64bit+ Capabilities: [70] MSI-X: Enable- Count=5 Masked- Capabilities: [a0] Express Endpoint, MSI 00 Capabilities: [100] Advanced Error Reporting Capabilities: [140] Device Serial Number 00-a0-c9-ff-ff-00-00-00 Capabilities: [1a0] Transaction Processing Hints Kernel driver in use: igb Kernel modules: igb root@utilite-desktop:/etc# lspci -v 00:00.0 PCI bridge: Device 16c3:abcd (rev 01) (prog-if 00 [Normal decode]) Flags: bus master, fast devsel, latency 0 Memory at 01000000 (64-bit, prefetchable) [size=1M] Bus: primary=00, secondary=01, subordinate=01, sec-latency=0 I/O behind bridge: 00000000-00000fff Memory behind bridge: 01100000-011fffff [virtual] Expansion ROM at 01200000 [disabled] [size=64K] Capabilities: [40] Power Management version 3 Capabilities: [50] MSI: Enable- Count=1/1 Maskable+ 64bit+ Capabilities: [70] Express Root Port (Slot-), MSI 00 Capabilities: [100] Advanced Error Reporting Capabilities: [140] Virtual Channel 01:00.0 Ethernet controller: Intel Corporation I211 Gigabit Network Connection (rev 03) Subsystem: Intel Corporation Device 0000 Flags: bus master, fast devsel, latency 0, IRQ 155 Memory at 01100000 (32-bit, non-prefetchable) [size=128K] I/O ports at 1e00000 [disabled] [size=32] Memory at 01120000 (32-bit, non-prefetchable) [size=16K] Capabilities: [40] Power Management version 3 Capabilities: [50] MSI: Enable- Count=1/1 Maskable+ 64bit+ Capabilities: [70] MSI-X: Enable- Count=5 Masked- Capabilities: [a0] Express Endpoint, MSI 00 Capabilities: [100] Advanced Error Reporting Capabilities: [140] Device Serial Number 00-a0-c9-ff-ff-00-00-00 Capabilities: [1a0] Transaction Processing Hints Kernel driver in use: igb Kernel modules: igb root@utilite-desktop:/etc# lsmod Module Size Used by fuse 59098 0 vivante 943 0 drm 153572 1 vivante mwifiex_sdio 11894 0 mwifiex 108875 1 mwifiex_sdio btmrvl_sdio 9714 0 pwm_bl 2190 0 btmrvl 10679 3 btmrvl_sdio backlight 3519 1 pwm_bl ads7846 8464 0 igb 170727 0 nfsd 63537 0 exportfs 3097 1 nfsd root@utilite-desktop:~# uname -a Linux utilite-desktop 3.0.35-cm-fx6-6.1 #140 SMP Tue Jun 17 10:40:25 IDT 2014 armv7l armv7l armv7l GNU/Linux root@utilite-desktop:~# dmesg Linux version 3.0.35-cm-fx6-6.1 (val@devel) (gcc version 4.5.2 (Sourcery G++ Lite 2011.03-41) ) #140 SMP Tue Jun 17 10:40:25 IDT 2014 CPU: ARMv7 Processor [412fc09a] revision 10 (ARMv7), cr=10c53c7d CPU: VIPT nonaliasing data cache, VIPT aliasing instruction cache Machine: Compulab CM-FX6 cm_fx6_v4l_setup: cm_fx6_v4l_msize: 134217728 Memory policy: ECC disabled, Data cache writealloc CPU identified as i.MX6Q, silicon rev 1.2 On node 0 totalpages: 507904 free_area_init_node: node 0, pgdat c0797580, node_mem_map cb800000 DMA zone: 368 pages used for memmap DMA zone: 0 pages reserved DMA zone: 46736 pages, LIFO batch:15 Normal zone: 720 pages used for memmap Normal zone: 91440 pages, LIFO batch:31 HighMem zone: 4544 pages used for memmap HighMem zone: 364096 pages, LIFO batch:31 PERCPU: Embedded 7 pages/cpu @cce11000 s5280 r8192 d15200 u32768 pcpu-alloc: s5280 r8192 d15200 u32768 alloc=8*4096 pcpu-alloc: [0] 0 [0] 1 [0] 2 [0] 3 Built 1 zonelists in Zone order, mobility grouping on. Total pages: 502272 Kernel command line: console=ttymxc3,115200 root=/dev/sda2 rw rootwait cm_fx6_v4l_msize=128M vmalloc=256M PID hash table entries: 4096 (order: 2, 16384 bytes) Dentry cache hash table entries: 131072 (order: 7, 524288 bytes) Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) Memory: 960MB 1024MB = 1984MB total Memory: 2006044k/2006044k available, 91108k reserved, 1474560K highmem Virtual kernel memory layout: vector : 0xffff0000 - 0xffff1000 ( 4 kB) fixmap : 0xfff00000 - 0xfffe0000 ( 896 kB) DMA : 0xf4600000 - 0xffe00000 ( 184 MB) vmalloc : 0xe2800000 - 0xf2000000 ( 248 MB) lowmem : 0xc0000000 - 0xe2000000 ( 544 MB) pkmap : 0xbfe00000 - 0xc0000000 ( 2 MB) modules : 0xbf000000 - 0xbfe00000 ( 14 MB) .init : 0xc0008000 - 0xc0044000 ( 240 kB) .text : 0xc0044000 - 0xc0739e20 (7128 kB) .data : 0xc073a000 - 0xc0798600 ( 378 kB) .bss : 0xc0798624 - 0xc0802e08 ( 426 kB) Hierarchical RCU implementation. RCU dyntick-idle grace-period acceleration is enabled. NR_IRQS:624 MXC GPIO hardware sched_clock: 32 bits at 3000kHz, resolution 333ns, wraps every 1431655ms arm_max_freq=1GHz MXC_Early serial console at MMIO 0x21f0000 (options '115200') bootconsole [ttymxc3] enabled Console: colour dummy device 80x30 Calibrating delay loop... 1581.05 BogoMIPS (lpj=7905280) pid_max: default: 32768 minimum: 301 Security Framework initialized Mount-cache hash table entries: 512 CPU: Testing write buffer coherency: ok hw perfevents: enabled with ARMv7 Cortex-A9 PMU driver, 7 counters available CPU1: Booted secondary processor CPU2: Booted secondary processor CPU3: Booted secondary processor Brought up 4 CPUs SMP: Total of 4 processors activated (6324.22 BogoMIPS). devtmpfs: initialized print_constraints: dummy: NET: Registered protocol family 16 print_constraints: vddpu: 725 <--> 1300 mV at 1150 mV fast normal print_constraints: vddcore: 725 <--> 1300 mV at 1150 mV fast normal print_constraints: vddsoc: 725 <--> 1300 mV at 1175 mV fast normal print_constraints: vdd2p5: 2000 <--> 2775 mV at 2400 mV fast normal print_constraints: vdd1p1: 800 <--> 1400 mV at 1100 mV fast normal print_constraints: vdd3p0: 2625 <--> 3400 mV at 3000 mV fast normal cpu regulator mode:ldo_enable hw-breakpoint: found 6 breakpoint and 1 watchpoint registers. hw-breakpoint: 1 breakpoint(s) reserved for watchpoint single-step. hw-breakpoint: maximum watchpoint size is 4 bytes. L310 cache controller enabled l2x0: 16 ways, CACHE_ID 0x410000c7, AUX_CTRL 0x02070000, Cache size: 1048576 B bio: create slab <bio-0> at 0 mxs-dma mxs-dma-apbh: initialized print_constraints: ads7846_vcc: 3300 mV print_constraints: vmmc: 3300 mV vgaarb: loaded SCSI subsystem initialized libata version 3.00 loaded. spi_imx imx6q-ecspi.0: probed spi_imx imx6q-ecspi.1: probed usbcore: registered new interface driver usbfs usbcore: registered new interface driver hub usbcore: registered new device driver usb Freescale USB OTG Driver loaded, $Revision: 1.55 $ imx-ipuv3 imx-ipuv3.0: IPU DMFC NORMAL mode: 1(0~1), 5B(4,5), 5F(6,7) imx-ipuv3 imx-ipuv3.1: IPU DMFC NORMAL mode: 1(0~1), 5B(4,5), 5F(6,7) Advanced Linux Sound Architecture Driver Version 1.0.24. Bluetooth: Core ver 2.16 NET: Registered protocol family 31 Bluetooth: HCI device and connection manager initialized Bluetooth: HCI socket layer initialized Bluetooth: L2CAP socket layer initialized Bluetooth: SCO socket layer initialized cfg80211: Calling CRDA to update world regulatory domain Switching to clocksource mxc_timer1 NET: Registered protocol family 2 IP route cache hash table entries: 32768 (order: 5, 131072 bytes) TCP established hash table entries: 131072 (order: 8, 1048576 bytes) TCP bind hash table entries: 65536 (order: 7, 524288 bytes) TCP: Hash tables configured (established 131072 bind 65536) TCP reno registered UDP hash table entries: 512 (order: 2, 16384 bytes) UDP-Lite hash table entries: 512 (order: 2, 16384 bytes) NET: Registered protocol family 1 RPC: Registered named UNIX socket transport module. RPC: Registered udp transport module. RPC: Registered tcp transport module. RPC: Registered tcp NFSv4.1 backchannel transport module. PCI: CLS 0 bytes, default 32 _regulator_get: etb supply vcore not found, using dummy regulator _regulator_get: etm.0 supply vcore not found, using dummy regulator _regulator_get: etm.1 supply vcore not found, using dummy regulator _regulator_get: etm.2 supply vcore not found, using dummy regulator _regulator_get: etm.3 supply vcore not found, using dummy regulator Static Power Management for Freescale i.MX6 wait mode is enabled for i.MX6 cpaddr = e2880000 suspend_iram_base=e28f0000 PM driver module loaded IMX usb wakeup probe the wakeup pdata is 0xe1c2a7e0 add wake up source irq 75 IMX usb wakeup probe the wakeup pdata is 0xe1c2a5a0 i.MXC CPU frequency driver highmem bounce pool size: 64 pages JFFS2 version 2.2. (NAND) \xffffffc2\xffffffa9 2001-2006 Red Hat, Inc. msgmni has been set to 1038 alg: No test for stdrng (krng) io scheduler noop registered io scheduler deadline registered io scheduler cfq registered (default) imx-sdma imx-sdma: loaded firmware 1.1 imx-sdma imx-sdma: initialized Serial: IMX driver imx-uart.0: ttymxc0 at MMIO 0x2020000 (irq = 58) is a IMX imx-uart.3: ttymxc3 at MMIO 0x21f0000 (irq = 61) is a IMX console [ttymxc3] enabled, bootconsole disabled imx-uart.1: ttymxc1 at MMIO 0x21e8000 (irq = 59) is a IMX imx-uart.4: ttymxc4 at MMIO 0x21f4000 (irq = 62) is a IMX brd: module loaded loop: module loaded at24 2-0050: 256 byte at24 EEPROM, writable, 16 bytes/write ahci: SSS flag set, parallel bus scan disabled ahci ahci.0: AHCI 0001.0300 32 slots 1 ports 3 Gbps 0x1 impl platform mode ahci ahci.0: flags: ncq sntf stag pm led clo only pmp pio slum part ccc apst scsi0 : ahci_platform ata1: SATA max UDMA/133 mmio [mem 0x02200000-0x02200fff] port 0x100 irq 71 m25p80 spi0.0: found m25px16, expected m25p80 m25p80 spi0.0: m25px16 (2048 Kbytes) Creating 3 MTD partitions on "spi_flash": 0x000000000000-0x0000000c0000 : "uboot" 0x0000000c0000-0x000000100000 : "uboot environment" 0x000000100000-0x000000200000 : "reserved" No NAND device found. Chip scan failed GPMI NAND driver registered. (IMX) vcan: Virtual CAN interface driver CAN device driver interface flexcan netdevice driver flexcan imx6q-flexcan.0: device registered (reg_base=e29b0000, irq=142) FEC Ethernet Driver fec_enet_mii_bus: probed ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver fsl-ehci fsl-ehci.0: Freescale On-Chip EHCI Host Controller fsl-ehci fsl-ehci.0: new USB bus registered, assigned bus number 1 fsl-ehci fsl-ehci.0: irq 75, io base 0x02184000 fsl-ehci fsl-ehci.0: USB 2.0 started, EHCI 1.00 hub 1-0:1.0: USB hub found hub 1-0:1.0: 1 port detected add wake up source irq 72 fsl-ehci fsl-ehci.1: Freescale On-Chip EHCI Host Controller fsl-ehci fsl-ehci.1: new USB bus registered, assigned bus number 2 fsl-ehci fsl-ehci.1: irq 72, io base 0x02184200 fsl-ehci fsl-ehci.1: USB 2.0 started, EHCI 1.00 hub 2-0:1.0: USB hub found hub 2-0:1.0: 1 port detected usbcore: registered new interface driver cdc_wdm Initializing USB Mass Storage driver... usbcore: registered new interface driver usb-storage USB Mass Storage support registered. ARC USBOTG Device Controller driver (1 August 2005) mousedev: PS/2 mouse device common for all mice =======snvs_pwrkey_probe() lp_cr 0x20 =======snvs_pwrkey_probe() lp_cr 0x20 input: snvs_power_key as /devices/virtual/input/input0 i.MX6 powerkey probe i2c-core: driver [isl29023] using legacy suspend method i2c-core: driver [isl29023] using legacy resume method i2c /dev entries driver at24 3-0050: 256 byte at24 EEPROM, writable, 16 bytes/write CM-FX6: Detected SB-FX6m (Utilite) base board rtc-em3027 3-0056: rtc core: registered rtc-em3027 as rtc0 iMX6 PCIe PCIe RC mode imx_pcie_pltfm_probe entering. ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300) ata1.00: ATA-9: SanDisk SSD U110 32GB, U221000, max UDMA/133 ata1.00: 62533296 sectors, multi 1: LBA48 NCQ (depth 31/32) ata1.00: configured for UDMA/133 scsi 0:0:0:0: Direct-Access ATA SanDisk SSD U110 U221 PQ: 0 ANSI: 5 sd 0:0:0:0: [sda] 62533296 512-byte logical blocks: (32.0 GB/29.8 GiB) sd 0:0:0:0: [sda] Write Protect is off sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00 sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA sda: sda1 sda2 sd 0:0:0:0: [sda] Attached SCSI disk PCIE: imx_pcie_pltfm_probe start link up. IMX PCIe port: link up. pci 0000:00:00.0: [16c3:abcd] type 1 class 0x000604 pci 0000:00:00.0: reg 10: [mem 0x00000000-0x000fffff 64bit pref] pci 0000:00:00.0: reg 38: [mem 0x00000000-0x0000ffff pref] pci 0000:00:00.0: supports D1 pci 0000:00:00.0: PME# supported from D0 D1 D3hot D3cold pci 0000:00:00.0: PME# disabled PCI: bus0: Fast back to back transfers disabled pci 0000:01:00.0: [8086:1539] type 0 class 0x000200 pci 0000:01:00.0: reg 10: [mem 0x00000000-0x0001ffff] pci 0000:01:00.0: reg 18: [io 0x0000-0x001f] pci 0000:01:00.0: reg 1c: [mem 0x00000000-0x00003fff] pci 0000:01:00.0: PME# supported from D0 D3hot D3cold pci 0000:01:00.0: PME# disabled PCI: bus1: Fast back to back transfers disabled PCI: Device 0000:00:00.0 not available because of resource collisions pcieport: probe of 0000:00:00.0 failed with error -22 pci 0000:00:00.0: BAR 0: assigned [mem 0x01000000-0x010fffff 64bit pref] pci 0000:00:00.0: BAR 0: set to [mem 0x01000000-0x010fffff 64bit pref] (PCI address [0x1000000-0x10fffff]) pci 0000:00:00.0: BAR 8: assigned [mem 0x01100000-0x011fffff] pci 0000:00:00.0: BAR 6: assigned [mem 0x01200000-0x0120ffff pref] pci 0000:00:00.0: BAR 7: assigned [io 0x1e00000-0x1e00fff] pci 0000:01:00.0: BAR 0: assigned [mem 0x01100000-0x0111ffff] pci 0000:01:00.0: BAR 0: set to [mem 0x01100000-0x0111ffff] (PCI address [0x1100000-0x111ffff]) pci 0000:01:00.0: BAR 3: assigned [mem 0x01120000-0x01123fff] pci 0000:01:00.0: BAR 3: set to [mem 0x01120000-0x01123fff] (PCI address [0x1120000-0x1123fff]) pci 0000:01:00.0: BAR 2: assigned [io 0x1e00000-0x1e0001f] usb 2-1: new high speed USB device number 2 using fsl-ehci pci 0000:01:00.0: BAR 2: set to [io 0x1e00000-0x1e0001f] (PCI address [0x1e00000-0x1e0001f]) pci 0000:00:00.0: PCI bridge to [bus 01-01] pci 0000:00:00.0: bridge window [io 0x1e00000-0x1e00fff] pci 0000:00:00.0: bridge window [mem 0x01100000-0x011fffff] pci 0000:00:00.0: bridge window [mem pref disabled] i2c i2c-0: Added multiplexed i2c bus 3 i2c i2c-0: Added multiplexed i2c bus 4 gpio-i2cmux gpio-i2cmux: 2 port mux on imx-i2c adapter Linux media interface: v0.10 lirc_dev: IR Remote Control driver registered, major 251 IR NEC protocol handler initialized IR RC5(x) protocol handler initialized IR RC6 protocol handler initialized IR JVC protocol handler initialized IR Sony protocol handler initialized IR RC5 (streamzap) protocol handler initialized IR LIRC bridge handler initialized Linux video capture interface: v2.00 imx2-wdt imx2-wdt.0: IMX2+ Watchdog Timer enabled. timeout=60s (nowayout=1) sdhci: Secure Digital Host Controller Interface driver sdhci: Copyright(c) Pierre Ossman mmc0: SDHCI controller on platform [sdhci-esdhc-imx.0] using DMA mmc1: SDHCI controller on platform [sdhci-esdhc-imx.2] using DMA VPU initialized mxc_asrc registered Thermal calibration data is 0x5934f169 Thermal sensor with ratio = 185 hub 2-1:1.0: USB hub found hub 2-1:1.0: 4 ports detected Anatop Thermal registered as thermal_zone0 anatop_thermal_probe: default cooling device is cpufreq! Registered led device: cm_fx6:green mmc0: new high speed SDIO card at address 0001 caam caam.0: device ID = 0x0a16010000000000 caam caam.0: job rings = 2, qi = 0 alg: No test for authenc(hmac(md5),cbc(aes)) (authenc-hmac-md5-cbc-aes-caam) caam caam.0: authenc-hmac-md5-cbc-aes-caam alg: No test for authenc(hmac(sha1),cbc(aes)) (authenc-hmac-sha1-cbc-aes-caam) caam caam.0: authenc-hmac-sha1-cbc-aes-caam alg: No test for authenc(hmac(sha224),cbc(aes)) (authenc-hmac-sha224-cbc-aes-caam) caam caam.0: authenc-hmac-sha224-cbc-aes-caam alg: No test for authenc(hmac(sha256),cbc(aes)) (authenc-hmac-sha256-cbc-aes-caam) caam caam.0: authenc-hmac-sha256-cbc-aes-caam alg: No test for authenc(hmac(md5),cbc(des3_ede)) (authenc-hmac-md5-cbc-des3_ede-caam) caam caam.0: authenc-hmac-md5-cbc-des3_ede-caam alg: No test for authenc(hmac(sha1),cbc(des3_ede)) (authenc-hmac-sha1-cbc-des3_ede-caam) caam caam.0: authenc-hmac-sha1-cbc-des3_ede-caam alg: No test for authenc(hmac(sha224),cbc(des3_ede)) (authenc-hmac-sha224-cbc-des3_ede-caam) caam caam.0: authenc-hmac-sha224-cbc-des3_ede-caam alg: No test for authenc(hmac(sha256),cbc(des3_ede)) (authenc-hmac-sha256-cbc-des3_ede-caam) caam caam.0: authenc-hmac-sha256-cbc-des3_ede-caam alg: No test for authenc(hmac(md5),cbc(des)) (authenc-hmac-md5-cbc-des-caam) caam caam.0: authenc-hmac-md5-cbc-des-caam alg: No test for authenc(hmac(sha1),cbc(des)) (authenc-hmac-sha1-cbc-des-caam) caam caam.0: authenc-hmac-sha1-cbc-des-caam alg: No test for authenc(hmac(sha224),cbc(des)) (authenc-hmac-sha224-cbc-des-caam) caam caam.0: authenc-hmac-sha224-cbc-des-caam alg: No test for authenc(hmac(sha256),cbc(des)) (authenc-hmac-sha256-cbc-des-caam) caam caam.0: authenc-hmac-sha256-cbc-des-caam caam caam.0: cbc-aes-caam caam caam.0: cbc-3des-caam caam caam.0: cbc-des-caam USB Host suspend begins will suspend roothub and its children ehci_fsl_bus_suspend begins, DR ehci_fsl_bus_suspend ends, DR host suspend ends platform caam_jr.0: registering rng-caam usbcore: registered new interface driver usbhid usbhid: USB HID core driver usbcore: registered new interface driver snd-usb-audio mxc_spdif mxc_spdif.0: MXC SPDIF Audio _regulator_get: 2-001a supply AVDD not found, using dummy regulator _regulator_get: 2-001a supply HPVDD not found, using dummy regulator _regulator_get: 2-001a supply DCVDD not found, using dummy regulator _regulator_get: 2-001a supply DBVDD not found, using dummy regulator imx_wm8731_init: success asoc: wm8731-hifi <-> imx-ssi.1 mapping ok asoc: mxc-spdif <-> imx-spdif-dai.0 mapping ok ALSA device list: #0: wm8731-audio #1: imx-spdif NET: Registered protocol family 26 ip_tables: (C) 2000-2006 Netfilter Core Team TCP cubic registered NET: Registered protocol family 17 can: controller area network core (rev 20090105 abi 8) NET: Registered protocol family 29 can: raw protocol (rev 20090105) can: broadcast manager protocol (rev 20090105 t) Bluetooth: RFCOMM TTY layer initialized Bluetooth: RFCOMM socket layer initialized Bluetooth: RFCOMM ver 1.11 Bluetooth: BNEP (Ethernet Emulation) ver 1.3 Bluetooth: BNEP filters: protocol multicast Bluetooth: HIDP (Human Interface Emulation) ver 1.2 lib80211: common routines for IEEE802.11 drivers lib80211_crypt: registered algorithm 'NULL' lib80211_crypt: registered algorithm 'WEP' lib80211_crypt: registered algorithm 'CCMP' lib80211_crypt: registered algorithm 'TKIP' HDMI CEC initialized mxc_vdoa mxc_vdoa: i.MX Video Data Order Adapter(VDOA) driver probed mxc_sdc_fb mxc_sdc_fb.0: register mxc display driver hdmi mxc_hdmi mxc_hdmi: Detected HDMI controller 0x13:0xa:0xa0:0xc1 imx-ipuv3 imx-ipuv3.1: IPU DMFC DP HIGH RESOLUTION: 1(0,1), 5B(2~5), 5F(6,7) Console: switching to colour frame buffer device 240x67 mxc_sdc_fb mxc_sdc_fb.1: register mxc display driver dvi _regulator_get: get() with no identifier mxc_hdmi_soc mxc_hdmi_soc.0: MXC HDMI Audio asoc: mxc-hdmi-soc <-> imx-hdmi-soc-dai.0 mapping ok mxc_v4l2_output mxc_v4l2_output.0: V4L2 device registered as video16 mxc_v4l2_output mxc_v4l2_output.0: V4L2 device registered as video17 mxc_v4l2_output mxc_v4l2_output.0: V4L2 device registered as video18 mxc_v4l2_output mxc_v4l2_output.0: V4L2 device registered as video19 VFP support v0.3: implementor 41 architecture 3 part 30 variant 9 rev 4 Bus freq driver module loaded Bus freq driver Enabled mxc_dvfs_core_probe DVFS driver module loaded regulator_init_complete: ads7846_vcc: incomplete constraints, leaving on rtc-em3027 3-0056: setting system clock to 2014-09-16 09:19:45 UTC (1410859185) EXT3-fs (sda2): error: couldn't mount because of unsupported optional features (240) EXT2-fs (sda2): error: couldn't mount because of unsupported optional features (240) EXT4-fs (sda2): mounted filesystem without journal. Opts: (null) VFS: Mounted root (ext4 filesystem) on device 8:2. devtmpfs: mounted Freeing init memory: 240K Installing knfsd (copyright (C) 1996 okir(a)monad.swb.de) udevd[1441]: starting version 175 Intel(R) Gigabit Ethernet Network Driver - version 4.1.2 Copyright (c) 2007-2012 Intel Corporation. PCI: enabling device 0000:01:00.0 (0140 -> 0142) igb: 0000:01:00.0: igb_check_options: VMDq option is not supported. igb 0000:01:00.0: Failed to initialize MSI-X interrupts. Falling back to MSI interrupts. igb 0000:01:00.0: Failed to initialize MSI interrupts. Falling back to legacy interrupts. udevd[1550]: renamed network interface eth0 to eth2 igb 0000:01:00.0: Intel(R) Gigabit Ethernet Network Connection igb 0000:01:00.0: eth0: (PCIe:2.5GT/s:Width x1) igb 0000:01:00.0: eth0: MAC: 00:01:c0:15:c2:ca igb 0000:01:00.0: eth0: PBA No: FFFFFF-0FF igb 0000:01:00.0: LRO is disabled igb 0000:01:00.0: Using legacy interrupts. 1 rx queue(s), 1 tx queue(s) udevd[1500]: renamed network interface eth0 to eth3 ads7846 spi0.1: touchscreen, irq 303 input: ADS7846 Touchscreen as /devices/platform/imx6q-ecspi.0/spi_master/spi0/spi0.1/input/input1 Bluetooth: vendor=0x2df, device=0x911a, class=255, fn=2 init: failsafe main process (2168) killed by TERM signal ehci_fsl_bus_suspend begins, Host 1 ehci_fsl_bus_suspend ends, Host 1 mwifiex_sdio mmc0:0001:1: WLAN FW already running! Skip FW download mwifiex_sdio mmc0:0001:1: WLAN FW is active mwifiex_sdio mmc0:0001:1: info: successfully registered wiphy device init: alsa-restore main process (2925) terminated with status 99 init: plymouth-stop pre-start process (3017) terminated with status 1 vgaarb: this pci device is not a vga device vgaarb: this pci device is not a vga device [drm] Initialized drm 1.1.0 20060810 [drm] Initialized vivante 1.0.0 20120216 on minor 0 mwifiex_sdio mmc0:0001:1: info: mlan0: Marvell 802.11 Adapter mwifiex_sdio mmc0:0001:1: driver_version = mwifiex 1.0 (14.57.5.p44) eth2: Freescale FEC PHY driver [Generic PHY] (mii_bus:phy_addr=1:00, irq=-1) ieee80211 phy0: info: ignoring the timeout value for IEEE power save ieee80211 phy0: info: received scan request on mlan0 fuse init (API version 7.16) ieee80211 phy0: info: ignoring the timeout value for IEEE power save ehci_fsl_bus_resume begins, Host 1 ehci_fsl_bus_resume ends, Host 1 ehci_fsl_bus_resume begins, DR warning: process `colord' used the deprecated sysctl system call with 8.1.2. mwifiex_sdio mmc0:0001:1: info: mwifiex_cfg80211_results: sending scan results PHY: 1:00 - Link is Up - 1000/Full ehci_fsl_bus_suspend begins, Host 1 ehci_fsl_bus_suspend ends, Host 1 ieee80211 phy0: info: received scan request on mlan0 mwifiex_sdio mmc0:0001:1: info: mwifiex_cfg80211_results: sending scan results ieee80211 phy0: info: received scan request on mlan0 mwifiex_sdio mmc0:0001:1: info: mwifiex_cfg80211_results: sending scan results ieee80211 phy0: info: received scan request on mlan0 mwifiex_sdio mmc0:0001:1: info: mwifiex_cfg80211_results: sending scan results ieee80211 phy0: info: received scan request on mlan0 mwifiex_sdio mmc0:0001:1: info: mwifiex_cfg80211_results: sending scan results ieee80211 phy0: info: received scan request on mlan0 mwifiex_sdio mmc0:0001:1: info: mwifiex_cfg80211_results: sending scan results ieee80211 phy0: info: received scan request on mlan0 mwifiex_sdio mmc0:0001:1: info: mwifiex_cfg80211_results: sending scan results ieee80211 phy0: info: received scan request on mlan0 mwifiex_sdio mmc0:0001:1: info: mwifiex_cfg80211_results: sending scan results imx-ipuv3 imx-ipuv3.0: WARNING: adapt panel end blank lines ieee80211 phy0: info: received scan request on mlan0 mwifiex_sdio mmc0:0001:1: info: mwifiex_cfg80211_results: sending scan results ehci_fsl_bus_resume begins, Host 1 ehci_fsl_bus_resume ends, Host 1 ehci_fsl_bus_suspend begins, Host 1 ehci_fsl_bus_suspend ends, Host 1 ieee80211 phy0: info: received scan request on mlan0 mwifiex_sdio mmc0:0001:1: info: mwifiex_cfg80211_results: sending scan results ieee80211 phy0: info: received scan request on mlan0 mwifiex_sdio mmc0:0001:1: info: mwifiex_cfg80211_results: sending scan results ieee80211 phy0: info: received scan request on mlan0 mwifiex_sdio mmc0:0001:1: info: mwifiex_cfg80211_results: sending scan results ieee80211 phy0: info: received scan request on mlan0 mwifiex_sdio mmc0:0001:1: info: mwifiex_cfg80211_results: sending scan results ieee80211 phy0: info: received scan request on mlan0 mwifiex_sdio mmc0:0001:1: info: mwifiex_cfg80211_results: sending scan results ieee80211 phy0: info: received scan request on mlan0 mwifiex_sdio mmc0:0001:1: info: mwifiex_cfg80211_results: sending scan results ieee80211 phy0: info: received scan request on mlan0 mwifiex_sdio mmc0:0001:1: info: mwifiex_cfg80211_results: sending scan results ieee80211 phy0: info: received scan request on mlan0 mwifiex_sdio mmc0:0001:1: info: mwifiex_cfg80211_results: sending scan results ieee80211 phy0: info: received scan request on mlan0 mwifiex_sdio mmc0:0001:1: info: mwifiex_cfg80211_results: sending scan results ieee80211 phy0: info: received scan request on mlan0 mwifiex_sdio mmc0:0001:1: info: mwifiex_cfg80211_results: sending scan results ieee80211 phy0: info: received scan request on mlan0 mwifiex_sdio mmc0:0001:1: info: mwifiex_cfg80211_results: sending scan results ieee80211 phy0: info: received scan request on mlan0 mwifiex_sdio mmc0:0001:1: info: mwifiex_cfg80211_results: sending scan results ieee80211 phy0: info: received scan request on mlan0 mwifiex_sdio mmc0:0001:1: info: mwifiex_cfg80211_results: sending scan results ieee80211 phy0: info: received scan request on mlan0 mwifiex_sdio mmc0:0001:1: info: mwifiex_cfg80211_results: sending scan results ieee80211 phy0: info: received scan request on mlan0 mwifiex_sdio mmc0:0001:1: info: mwifiex_cfg80211_results: sending scan results ieee80211 phy0: info: received scan request on mlan0 mwifiex_sdio mmc0:0001:1: info: mwifiex_cfg80211_results: sending scan results -- To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org

4 4

[opensuse-arm] Factory images for rasperry pi broken?
by Michael Ströder 15 Sep '14

15 Sep '14

HI! I'm trying to boot the images downloaded from http://download.opensuse.org/repositories/devel:/ARM:/Factory:/Contrib:/Ras… openSUSE-Factory-ARM-E17-raspberrypi.armv6l-1.12.1-Build210.2.raw.xz openSUSE-Factory-ARM-JeOS-raspberrypi.armv6l-1.12.1-Build207.2.raw.xz But both don't work and boot fails with: 1. Usage message of 'setenv' 2. Messages: ** File not found boot/linux.vmx ** SCRIPT FAILED: continuing ** Bad partition specification mmc 0:0:2 ** ** Bad partition specification mmc 0:0:2 ** ** Bad partition specification mmc 0:0:2 ** Former images did work. All hardware seems to be ok since using e.g. raspbian image etc. simply works. Any hint is appreciated. Ciao, Michael.

1 1

[opensuse-arm] 13.2 : arm tablet support
by christophe 12 Sep '14

12 Sep '14

Hello dear list members, i posted this thread on the opensuse forum : https://forums.opensuse.org/showthread.php/500751-13-2-arm-tablet-support I got no answer and someone told me to post my question here. I own an intel based tablet and managed to run opensuse 13.1 on it. But i would like to install and run opensuse on arm based tablets for me and for other members of my family. NB : On my intel tablet, though it runs quite well, the graphic interface isn't very good. Kde is bad and gnome a little less bad. But that's not the main problem... Arm tablets are more available, cheaper and there's more choice. So our next tablets will have arm, mostly. Will opensuse 13.2 be easy to install and run on such arm tablets ? To install, what is the procedure ? Copy a dowloaded iso on an usb key and boot and install like on classic pc ? Will there be all the same packages than on x86 opensuse ? Like packman, google-earth, etc...? How is the support ? Thank you for your answer. -- christophe -- To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org

4 5

Re: [opensuse-arm] ARM images builds broken
by Alexander Graf 12 Sep '14

12 Sep '14

On 12.09.14 09:05, Dirk Müller wrote: > > > Yeah, it does. I've fixed it and will copy over the built kernel > once it finished building. > > > Seems to be fixed now. on the bright side, I took the chance to remove > some other irrelevant drivers, so the kernel is 0.5 MB smaller than > before :-) Awesome :). Please also make sure that VFAT and the default NLS code pages are compiled in, so that we have the chance to build EFI images ;). Alex -- 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] ARM images builds broken
by Guillaume Gardet 11 Sep '14

11 Sep '14

Hi, our non-rootfs image builds are broken on OBS with the following error: ******************************************************************************** [ 407s] Sep-11 10:27:40 <1> : EXEC [/sbin/kpartx -sa /dev/loop0 2>&1] [ 407s] Sep-11 10:27:40 <1> : Failed mapping partition: /dev/mapper/control: open failed: No such device [ 407s] Failure to communicate with kernel device-mapper driver. [ 407s] Check that device-mapper is available in the kernel. [ 407s] device mapper prerequisites not met ******************************************************************************** Does our obs kernel need some update? Note that local build is fine. 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] JeOS image status (Beagle, Panda, Arndale and chromebook tested)
by Guillaume Gardet 10 Sep '14

10 Sep '14

Hi, Fatcory:ARM repo has new JeOS (E17 and XFCE) images but there are some ghost files remaining. Pandaboard and Beagleboard boots u-boot but then hangs after "Starting kernel ...". Beagle should use a newer u-boot managing FDT for Beagle. Is there any known problem with Factory Kernel for OMAP3/OMAP4 boards? Arndale : Does boot u-boot but fails with a "Wrong Image Format" which should be fixed by SR #248024 (already accepted by Alex, thanks). I fixed it manually before the SR were accepted but I get lots of "cpufreq: __target_index: Failed to change cpu frequency: -22" errors logged but I finaly get a prompt. Serial console and USB2 work, but eth0 seems to have some problems. Second boot seems to be broken (I fallback to a dracut prompt). Chromebook: Does boot u-boot but then fails with a black screen once kernel is (or seems to be) loaded. Guillaume -- To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org

4 17

[opensuse-arm] U-Boot v2014.10-rc2
by Guillaume Gardet 08 Sep '14

08 Sep '14

Hi, for information, I updated u-boot to v2014.10-rc2 and most patches in my home repo: https://build.opensuse.org/package/show/home:Guillaume_G:branches:Base:Syst… We are still missing u-boot-hyundaia7hd (not available upstream) and u-boot-mx6cubox-i (patch must be refreshed). I started to send some of our patches upstream to ease next u-boot updates. Guillaume -- To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org

2 4

[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

[opensuse-arm] U-Boot v2014.07 - volunteers?
by Andreas Färber 29 Aug '14

29 Aug '14

Hi, Handling a recent SR, I noticed that our Base:System u-boot is still at v2014.04. Some sun7i stuff landed in v2014.07, so our patches should hopefully start to shrink. https://build.opensuse.org/package/show/Base:System/u-boot I'm a bit preoccupied with kernel work already - is there anyone who can take on updating the package? Also a heads-up that for the next release, v2014.10, they have switched to Kconfig, which will then require us to modify build commands from ..._config to ..._defconfig. 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

7 25

[opensuse-arm] Parallella booting
by Andreas Färber 25 Aug '14

25 Aug '14

Hi Sean et al., Yesterday I finally received my Parallella board and last night managed to get Factory working on it. I roughly summarized my steps here: http://en.opensuse.org/HCL:Parallella - U-Boot is already on flash - FAT partition with uImage, devicetree.dtb, parallella.bit.bin - rootfs as usual I'm hoping to get upstream kernel working, be it without HDMI, so holding off packaging their kernel. If someone else wants to, go ahead. Enjoy, Andreas P.S. If anyone in the US wants to buy one, their shop is about to reopen for selling their remaining stock (I seemed among the last to receive a pre-order). Afterwards it'll be available through distributors. The Parallella seems the cheepest option currently to get your hands on a Zynq SoC, beating the MicroZed. -- 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

5 12

[opensuse-arm] 3.16.0 kernel / Cubietruck / Raspberry Pi
by Andreas Färber 20 Aug '14

20 Aug '14

Hi, Thanks to help from Jean, Michal and Takashi I was able to fix the build of 3.16 kernels in Kernel:HEAD. I tested armv7hl kernel-default on the Cubietruck. It required INITRD_MODULES="ahci_sunxi" in /etc/sysconfig/kernel for my SATA based rootfs; like in early RCs there is no serial console output (both with packaged and latest u-boot-sunxi), but at some point ssh is possible. # boot.scr setenv bootargs console=ttyS0,115200 root=/dev/sda1 rootfstype=btrfs rw rootwait ext2load mmc 0:1 0x46000000 boot/zImage ext2load mmc 0:1 0x49000000 boot/dtb/sun7i-a20-cubietruck.dtb ext2load mmc 0:1 0x4a000000 boot/initrd bootz 0x46000000 0x4a000000:0x${filesize} 0x49000000 kernel-lpae did not allow ssh, here's a quick SUNxI diff: $ diff -u /boot/config-3.16.0-5.g07174c1-default /boot/config-3.16.0-5.g07174c1-lpae | grep SUN.I CONFIG_ARCH_SUNXI=y -CONFIG_MACH_SUN4I=y -CONFIG_MACH_SUN5I=y +# CONFIG_MACH_SUN4I is not set +# CONFIG_MACH_SUN5I is not set CONFIG_MACH_SUN6I=y CONFIG_MACH_SUN7I=y CONFIG_AHCI_SUNXI=m -CONFIG_SUN4I_EMAC=m +# CONFIG_SUN4I_EMAC is not set -CONFIG_DWMAC_SUNXI=y -CONFIG_MDIO_SUN4I=m +# CONFIG_MDIO_SUN4I is not set CONFIG_I2C_SUN6I_P2WI=m -CONFIG_SPI_SUN4I=m +# CONFIG_SPI_SUN4I is not set CONFIG_SPI_SUN6I=m CONFIG_PINCTRL_SUNXI=y CONFIG_PINCTRL_SUNXI_COMMON=y CONFIG_PINCTRL_SUN4I_A10=y CONFIG_PINCTRL_SUN6I_A31=y CONFIG_PINCTRL_SUN6I_A31_R=y CONFIG_PINCTRL_SUN7I_A20=y CONFIG_POWER_RESET_SUN6I=y CONFIG_SUNXI_WATCHDOG=m CONFIG_MMC_SUNXI=m -CONFIG_RTC_DRV_SUNXI=m +CONFIG_RTC_DRV_SUNXI=y CONFIG_SUN4I_TIMER=y CONFIG_SUN5I_HSTIMER=y CONFIG_PHY_SUN4I_USB=m DWMAC_SUNXI is the network driver needed, so I added it to the lpae config and will need to re-test. As for RTC_DRV_* we seem to be inconsistent - should they all be y or m? On the Raspberry Pi the armv6hl kernel-default boots to the login prompt, but USB and network do not seem to be working (regression from 3.15 Kernel:HEAD). The only obviously missing option seemed to be DMA_BCM2835 - will re-test once we have a new kernel with that. # boot.scr setenv bootargs 'console=ttyAMA0,115200 console=tty1 root=/dev/mmcblk0p3 rootfstype=ext4 rw rootwait dwc_otg.lpm_enable=0' ext2load mmc 0:2 ${kernel_addr_r} zImage ext2load mmc 0:2 ${fdt_addr_r} dtb/bcm2835-rpi-b.dtb ext2load mmc 0:2 ${ramdisk_addr_r} initrd bootz ${kernel_addr_r} ${ramdisk_addr_r}:0x${filesize} ${fdt_addr_r} As always, help with testing appreciated. Maybe 3.16.1 will help, too. Cheers, 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

1 2

[opensuse-arm] compile andriod 4.4.3 on onpensuse failed.
by Huangwenhui 15 Aug '14

15 Aug '14

Hi, We evaluate the compiler performance on Hisi-D01 board with openSUSE. We get into trouble when compiling andriod4.4.3. I also failed to compile it on X86-64, I do not know how to get the dependent files and tools. Is there some documents or suggestions? Regards. Huangwenhui -- 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] Raspberry-Pi Version from Bernhard Wiedemann
by Edgar Dombrowski 14 Aug '14

14 Aug '14

Hi, folks. Last week the Raspberry Pi-Magazine published an article of an Raspi-Version for OpenSuse. As I am an OS-fan since Issue 4.0 I installed the image successfully on a SD-Stick. The SD started and I accessed using "root/linux" As the Eth0-ip-nummber did not correspond to my home network I changed it using > config eth0 192.168.x.y. Pinging to the router was ok. However when I tried to get yast2 using the command < zypper install yast2 I got the error message > could not resolve host: download.opensuse.org. What is wrong? Thanks to Bernhard Edgar Dombrowski, DJ3PU, Munich -- To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org

3 2

[opensuse-arm] Re: [opensuse-kernel] factory armv7l builds broken by omapdrm, patch available
by Andreas Färber 13 Aug '14

13 Aug '14

Hi, Am 13.08.2014 13:48, schrieb Josua Mayer: > The armv7l builds of kernel-default for openSUSE Factory have been > broken for quite a while now. Recently a patch fo fix the error with > %x and omapdrm has landed in linux-next: > > https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/dri… > > It would be nice if this patch could also be applied on the current > 3.16 suse kernel. I'm not in a position to help with applying the patches, but as a workaround I applied a config change to disable CONFIG_DRM_OMAP now. If would still be nice if the kernel maintainers could apply Matwey's previously posted patches and revert my workaround then. 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

2 1

[opensuse-arm] Kernel build broken
by Josua Mayer 04 Aug '14

04 Aug '14

Hi everyone, as you surely noticed, armv7l kernel builds are currently broken because of bad printf format in omapdrm code. I have seen that Matwey V. Kornilov tried to send a patch to LKML. Now, a fix has landed in linux-next: https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/dri… It would be nice if this could be applied to the suse 3.16 kernel tree. 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-Version for the Raspberry Pi
by Edgar Dombrowski 02 Aug '14

02 Aug '14

Hallo all I would appreciate if you could tellme which is the actual OpenSuse-Version for the Raspberry Pi and I could find it. Thanks to you and have a good weekend Edgar, DJ3PU, Munich -- 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] How does package "qemu-accel" work?
by Ilya Palachev 31 Jul '14

31 Jul '14

Hi, all. I have found that package "qemu-accel-armv7l-cross-arm" contains directory /emul/i586-for-arm/ with cross utilities that accelerate the build. Could you explain, how does this construction work? For example, there are 2 binaries in the chroot environemt: bash-4.2# file /usr/bin/make /usr/bin/make: ELF 32-bit LSB executable, ARM, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.16, BuildID[sha1]=0xe1ed5cff83cb3973a9b8ed363857cd796dba63cf, not stripped bash-4.2# file /emul/i586-for-arm/usr/bin/make /emul/i586-for-arm/usr/bin/make: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.16, BuildID[sha1]=0x90f51594906fdc9f7906c7e119ba8703a616d4b8, not stripped bash-4.2# whereis make make: /usr/bin/make /usr/share/man/man1/make.1.gz bash-4.2# LD_DEBUG=all make 2>&1 | tail -10 27438: binding file make [0] to /emul/i586-for-arm/lib/libc.so.6 [0]: normal symbol `exit' [GLIBC_2.0] 27438: symbol=ferror; lookup in file=make [0] 27438: symbol=ferror; lookup in file=/emul/i586-for-arm/lib/libc.so.6 [0] 27438: binding file make [0] to /emul/i586-for-arm/lib/libc.so.6 [0]: normal symbol `ferror' [GLIBC_2.0] 27438: symbol=fclose; lookup in file=make [0] 27438: symbol=fclose; lookup in file=/emul/i586-for-arm/lib/libc.so.6 [0] 27438: binding file make [0] to /emul/i586-for-arm/lib/libc.so.6 [0]: normal symbol `fclose' [GLIBC_2.1] 27438: 27438: calling fini: make [0] 27438: "whereis" says that "make" is taken from /usr/bin/, but ld.so says that it is taken from /emul/i586-for-arm/usr/bin/, so we have cross accelerated executable "make". How does this work? Best regards, Ilya Palachev -- To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org

3 3

[opensuse-arm] Build not enabled for Factory armv7hl at http://download.opensuse.org/ports/armv7hl/factory/repo/oss/
by Arnd Gronenberg 28 Jul '14

28 Jul '14

Hello, I'm running openSUSE Factory on some ARMv7 boards (cubietruck, Olimex A10 OLinuXino LIME) using the Factory ARM repository at http://download.opensuse.org/ports/armv7hl/factory/repo/oss/. Everything is working fine and I'm currently working on packaging the specific linux-sunxi kernel and tools for Allwinner processors as well as compiling some specific repositories (like hamradio) for ARM (v7 and v6). Unfortunately, the build for http://download.opensuse.org/ports/armv7hl/factory/repo/oss/ seems to be disable for a couple of weeks, last builds were create around May 20th. Is there any specific reason for no longer providing a Factory armv7hl repository? Whom may I contact to get the build enabled again? How may I help with the armv7hl target? Thanks in advance! -- Arnd (DJ9PZ / AB2QP)

6 12

[opensuse-arm] 13.1 ARM images builds broken - kiwi problem?
by Guillaume Gardet 24 Jul '14

24 Jul '14

Hi, there is a problem with all 13.1 ARM images. They failed with : "uboot-image-XXX-setup: No such file or directory". Probably a bug in a kiwi update? Marcus ? Guillaume -- To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org

2 11

[opensuse-arm] Re: SuSE for Beaglebone Black
by Matwey V. Kornilov 14 Jul '14

14 Jul '14

Dear Paul, Could you please use appropriate maillist (opensuse-arm) to describe the problems, where much more people could see it and helped you. So, answering your question. If you need all bells and whistles, you use wrong distro. openSUSE images for BBB use upstream linux kernel, where hardware support for BBB is still not complete and mainly due to lack of DT-overlays. However, I hope they fixed usb in 3.16 and as soon as openSUSE kernel team manage to build arm kernel we will see it. The reason to use openSUSE on BBB now is when you need to utilize KIWI advantages, i.e. do kind of mass-deployment or store your ready-to-use configuration. 2014-07-13 0:29 GMT+04:00 Paul Wallingford <paul(a)g-e-n-i-u-s.com>: > On 7/11/2014 8:52 AM, Matwey V. Kornilov wrote: >> >> 2014-07-11 19:49 GMT+04:00 Paul Wallingford <paul(a)g-e-n-i-u-s.com>: >> >>> Since these images do not work, >> >> >> For me, they work just perfect, except of lack of usb. >> > > Hello, > > I did some more work regarding this. I was able to get the openSuSE distro > to work, sort of. > > Did you generate this distro? Are you the maintainer? > > For most people who use the Beaglebone Black, lack of video, lack of USB, > accessing the system via the serial port which requires a separate piece of > hardware and separate software (FTDI drivers, terminal software, etc), the > lack of "flasher" scripts to install the distro on the on-board eMMC, ... > all add up to big show stoppers. > > At the very least, I suggest that you put a note on the wiki page that this > distro is for tinkerers and is not ready for "prime time" use, since there > are still significant unresolved issues. > > I was hoping that openSuSE would run on the BBB. I really hate using > Ubuntu, Fedora, etc., but those are my only choices right now. > > I can tell you how to set up the flasher scripts so the system installs > itself on the internal eMMC when powered on with the S2 button pressed. > This is fairly easy. > > As far as the USB, video, etc., other distros work, so I imagine it is just > a matter of including the correct drivers, but I have not looked into the > issue. > > Best. > > Paul Wallingford -- With best regards, Matwey V. Kornilov http://blog.matwey.name xmpp:0x2207@jabber.ru -- 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 Odroid XU (with downstream kernel)
by Joshua Krämer 09 Jul '14

09 Jul '14

Dear list, I have an Odroid XU from Hardkernel with an eMMC memory module. The Linux images provided by Hardkernel and on their forums work (Debian, Ubuntu). Now I'd like to make openSUSE work on it. At the end of this mail, I provide the steps of what I have done so far to prepare an eMMC. With this eMMC, the kernel seems to boot, but all I get is a black screen and the device doesn't appear on the network (so SSH isn't possible). With your help, I hope to be able to make HDMI and ethernet work. Links to openSUSE wiki (not much information) and official site: https://en.opensuse.org/HCL:OdroidXU http://hardkernel.com/main/products/prdt_info.php?g_code=G137510300620 Now, here's how I've prepared the eMMC in detail. (1) I got the SuSE rootfs from here: http://download.opensuse.org/ports/armv7hl/distribution/13.1/appliances/ope… (2) And the kernel from here: http://builder.mdrjr.net/kernel-3.4/LATEST/odroidxu.tar.xz (3) Prepared a boot.ini (File attached, I used this as a template: http://builder.mdrjr.net/tools/boot.scr_ubuntu_xu.tar) (4) Prepared rule files with following contents: 40-input.rules: KERNEL=="event*", SUBSYSTEM=="input", MODE="0777", GROUP="adm" 50-hk_hdmi.rules: KERNEL=="fb1", SYMLINK+="fb6" 60-cec.rules: KERNEL=="CEC", MODE="0777" (5) Partitioned the eMMC according to this layout: Device Boot Start End Blocks Id System /dev/sdb1 2048 133119 65536 c W95 FAT32 (LBA) /dev/sdb2 133120 122142719 61004800 83 Linux (6) Prepared partitions with following commands: mkfs.vfat -n boot /dev/sdb1 mkfs.ext4 -L rootfs /dev/sdb2 tune2fs /dev/sdb2 -U e139ce78-9841-40fe-8823-96a304a09859 tune2fs -O ^has_journal /dev/sdb2 (The UID is to make it compatible with hardkernel's kernel update script.) (7) Copied the rootfs to the eMMC, excluding following folders: /lib/modules/3.11.10-2-default /lib/firmware/3.11.10-2-default /boot (8) Copied config-3.4.91, zImage and boot.ini to the boot partition (9) Copied the rule files to /etc/udev/rules.d/ (10) Copied lib/* and usr/* from the kernel to /lib/ and /usr/, using "cp -aR" (don't know if this flags are necessary) With the eMMC prepared like that, the kernel seems to boot (blue LED blinking). The eMMC already has the bootloader preinstalled in a hidden partition. I hope you can give me some hints how to proceed from here. Thanks in advance and kind regards, Joshua Krämer

3 2

[opensuse-arm] JeOS uboot-image-setup - calculate addresses automatically
by Josua Mayer 06 Jul '14

06 Jul '14

Hello everyone, A few months ago I had the idea to automatically calculate fdt- and ramdisk load addresses based on their actual sizes. On IRC agraf then suggested to just guess offsets that will always hold true, and that is what I now implemented: The user now only has to specify kerneladdr. dtb and ramdisk will be put somewhere after that address. I assume that a kernel will be smaller than 63MB, and a device tree binary smaller than 1MB. The calculated addresses are then the following: fdtaddr=kerneladdr+63MB ramdiskaddr=fdtaddr+1MB I have created a submit request SR239214 implementing this automatic calculation and using it for the cubox-i. I have also attached the relevant diff so you can look at it easily. If you approve of this automatic calculation I'd encourage you to make use of it in the future! kind regards Josua Mayer

3 5

[opensuse-arm] ask for chroot to suse
by Huangwenhui 03 Jul '14

03 Jul '14

Hi, We are building a suse arm on our arm-a15 board, Linux kernel is linaro 3.12.0 version, and compiler is arm-linux-gnueabihf-, we got suse source and mount it on by nfsserver. when I chroot to suse, a error occured like this: sh (81): undefined instruction: pc=b6f76b48 # chroot /mnt/suse_root #[ 35.880000] sh (81): undefined instruction: pc=b6f76b48 #[ 35.890000] Code: e59f3034 e08f2002 e0822003 e5922040 (ecac8b10) #Illegal instruction # cat log #81 access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory) #81 --- SIGILL (Illegal instruction) @ 0 (0) --- #81 +++ killed by SIGILL +++ What could it? Expect replies. huangwenhui -- To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org

5 16

[opensuse-arm] Re: [RFC 0/4] ARM: dts: exynos: Prepare Spring
by Andreas Färber 02 Jul '14

02 Jul '14

Am 23.06.2014 22:11, schrieb Benson Leung: > On Mon, Jun 23, 2014 at 12:57 PM, Doug Anderson <dianders(a)chromium.org> wrote: >>> Also when the screen stayed on, the embedded controller's keymap seems >>> hardcoded to US English with system settings not taking effect; but >>> surely we don't want per-keyboard device tree files to remedy that. >> >> +Benson may be able to answer this. I believe generally non-US >> keyboard layouts are handled at a higher level. > > There's no such thing as a notion of US versus non-US keyboard layouts > at the embedded controller level or even in the kernel. Indeed, this > should all be handled in user space. > > The chromeos firmware and kernel should return the correct key codes > for every key pressed on keyboards with the ANSI layout (US based), or > ISO (UK and most other countries). > > The only differences are : > * the ISO keyboard has an extra key, which is immediately to the right > of the Left Shift key. This must return KEY_102ND key code from the > input layer. > * the ISO keyboard has a different location for the | \ key, which > accomodates the upside L shaped Enter key on the right side of the > keyboard. The keycode for this key is KEY_BACKSLASH. > > Basically, all of this should be verified using evtest to test that > the ec and kernel have the keys right. Hm, we may be talking about two different things here? I have been doing a minimum system bring-up for 3.16, with openSUSE userspace. My YaST-selected system keymap (German with deadkeys) is not taking effect on German Spring at the *framebuffer console* (tty1) - evdev is not involved at that level AIUI. Backspace and L-shaped enter keys work okay. The keymap here should be identical to that in the original German device and seemed to match that in the exynos5250-snow.dts file. I just checked (w/ dp-controller, hdmi, fimd commented out in my patch): * An external USB keyboard does not work correctly either. * In X11 (xdm), both internal and USB keyboard work as expected. Similar situation in ChromeOS IIRC, with keymap correct at graphical login but not on the right-arrow console - although I don't know the ChromeOS userland too well to judge if it was configured correctly. > If you are having other problems with keyboard layout being stuck to > US QWERTY, please check your user space. On my Raspberry Pi for instance, the equivalent openSUSE Factory works just fine with German keymap for USB keyboard. Might any related kernel config options be missing in exynos_defconfig? Anything in particular I should check in user space? Cheers, 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

2 2

[opensuse-arm] Mono bug on opensuse arm on Beagle Bone Black; works on opensuse intel
by lists 29 Jun '14

29 Jun '14

I'm running this program via "ssh -X" if it makes a different. Note that logging into the beagle bone black via the HDMI display doesn't work, otherwise I would test it that way as well. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ mono VirtualRadar.exe Stacktrace: at <unknown> <0xffffffff> at (wrapper managed-to-native) System.Drawing.GDIPlus.GdipCreateFont (intptr,single,System.Drawing.FontStyle,System.Drawing.GraphicsUnit,intptr&) <0xffffffff> at System.Drawing.Font.CreateFont (string,single,System.Drawing.FontStyle,System.Drawing.GraphicsUnit,byte,bool) <0x0013f> at System.Drawing.Font..ctor (string,single,System.Drawing.FontStyle,System.Drawing.GraphicsUnit,byte,bool) <0x0007f> at System.Drawing.Font..ctor (string,single,string) <0x00057> at (wrapper remoting-invoke-with-check) System.Drawing.Font..ctor (string,single,string) <0xffffffff> at System.Drawing.SystemFonts.get_DefaultFont () <0x0005b> at System.Windows.Forms.Theme.get_DefaultFont () <0x00027> at System.Windows.Forms.Control.get_DefaultFont () <0x0001f> at System.Windows.Forms.Control.get_Font () <0x00053> at System.Windows.Forms.Form..ctor () <0x00077> at VirtualRadar.WinForms.BaseForm..ctor () <0x00023> at VirtualRadar.WinForms.SplashView..ctor () <0x0001b> at (wrapper remoting-invoke-with-check) VirtualRadar.WinForms.SplashView..ctor () <0xffffffff> at VirtualRadar.Program.StartApplication (string[]) <0x00067> at VirtualRadar.Program.Main (string[]) <0x0034b> at (wrapper runtime-invoke) <Module>.runtime_invoke_void_object (object,intptr,intptr,intptr) <0xffffffff> Native stacktrace: mono() [0xac3c8] mono() [0x2aad4] /lib/libc.so.6(__default_rt_sa_restorer_v2+0) [0xb6dd6d50] /usr/lib/libgdiplus.so(GdipCreateFont+0x110) [0xb5d43aec] Debug info from gdb: ================================================================= Got a SIGSEGV while executing native code. This usually indicates a fatal error in the mono runtime or one of the native libraries used by your application. ================================================================= ========================================= The mono-complete package is 3.0.6-3.1.3 The libgdiplus0 pakage is 2.10.9-3.1.2 system info uname -a Linux linux 3.8.13 #1 SMP Thu Feb 6 16:19:16 CET 2014 armv7l armv7l armv7l GNU/Linux cat /proc/version Linux version 3.8.13 (koen@thinkpad) (gcc version 4.7.4 20130626 (prerelease) (Linaro GCC 4.7-2013.07) ) #1 SMP Thu Feb 6 16:19:16 CET 2014 -- 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] BBB image - able to run from onboard MMC versus SD card?
by Christopher Myers 26 Jun '14

26 Jun '14

Hi everyone! I'm new to the list, and this is my first post, so please forgive my ignorance if this has been covered before. I'd searched the archives and didn't see anything about it, so thought I'd pose the question here. I recently picked up one of the new Beaglebone Black rev. C boards, and wanted to try to run oS on it, since it's my OS of choice :) I was able to successfully get the JEOS image copied up to the SD card and installed, and it seems to run fine. However, I'd much rather have it running from the onboard MMC instead of the SD card. Is this even possible? I've seen how other OS images can be loaded to the MMC by booting off of the SD card, but it doesn't look like the oS one does that. Chris -- To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org

2 1

Re: [opensuse-arm] OS 13.1 Raspberry Pi image, Build 38.1 has no apparent root filesystem
by Alex Armstrong 26 Jun '14

26 Jun '14

>> I see where the root fs option is passed to the kernel in the boot >> script, but it surprises me that neither mount nor df show / in their >> listings. Although findmnt does show / in it's listing. Is this by >> design? If so, I'll make a note in the wiki. > The root file system in the output of df in shown in /dev/root mounted on / > Indeed, that is what I expect to see. But when I run df no entries for /dev/root on / are shown. This is all I get: # df -h Filesystem Size Used Avail Use% Mounted on /run 187M 1.1M 186M 1% /var/run No /boot, no /, just /run. >>> You can resize the partition used for the root file system on the system >>> you wrote the image to the SD card. You can use YaST on that system to do >>> so. >> Yes this does work. I had the impression from the wiki that I could use >> YaST on the RPi itself to resize root. If this is not the case I'll >> correct it. > You can't resize a mounted system, but without a mounted root you can't use > any program. > Makes sense - thanks. -Alex -- To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org

1 1

[opensuse-arm] OS 13.1 Raspberry Pi image, Build 38.1 has no apparent root filesystem
by Alex Armstrong 25 Jun '14

25 Jun '14

Greetings, I have successfully installed and run this JeOS for the Raspberry Pi: openSUSE-13.1-ARM-JeOS-raspberrypi.armv7l-1.12.1-Build38.1.raw Dated: 23-Jun-2014 Downloaded from: http://download.opensuse.org/repositories/devel:/ARM:/13.1:/Contrib:/Raspbe… But have noticed odd behavior with the filesystem tree. Specifically, running 'mount' produces this output: <SNIP> mqueue on /dev/mqueue type mqueue (rw) debugfs on /sys/kernel/debug type debugfs (rw) devpts on /dev/pts type devpts (rw,mode=0620,gid=5) proc on /proc type proc (rw) configfs on /sys/kernel/config type configfs (rw) /run on /var/run type none (rw,bind) /run/lock on /var/lock type none (rw,bind) <SNAP> And the output of df -h: <SNIP> Filesystem Size Used Avail Use% Mounted on /run 187M 1.1M 186M 1% /var/run <SNAP> It would appear that no root filesystem is mounted. And looking at /etc/mtab we see: <SNIP> mqueue /dev/mqueue mqueue rw 0 0 debugfs /sys/kernel/debug debugfs rw 0 0 devpts /dev/pts devpts rw,mode=0620,gid=5 0 0 proc /proc proc rw 0 0 configfs /sys/kernel/config configfs rw 0 0 /run /var/run none rw,bind 0 0 /run/lock /var/lock none rw,bind 0 0 <SNAP> Additionally, /etc/fstab contains only these entries: <SNIP> devpts /dev/pts devpts mode=0620,gid=5 0 0 proc /proc proc defaults 0 0 <SNAP> Which seems to confirm that there is no root fs. But if we look at fdisk -l: <SNIP> Disk /dev/mmcblk0: 7948 MB, 7948206080 bytes, 15523840 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk label type: dos Disk identifier: 0xa7e6536d Device Boot Start End Blocks Id System /dev/mmcblk0p1 * 2048 485383 241668 c W95 FAT32 (LBA) /dev/mmcblk0p2 487424 1980415 746496 83 Linux <SNAP> The structure looks ok (only missing a swap partition). If we try to use YaST to resize /dev/mmcblk0p2, we get an error saying the filesystem seems to be inconsistent. But then we try to run fsck /dev/mmcblk0 it tells us: <SNIP> fsck from util-linux 2.23.2 e2fsck 1.42.8 (20-Jun-3013) /dev/mmcblk0p2 is mounted. e2fsck: Cannot continue, aborting. <SNAP> This, plus the fact that the system runs fine seem to indicate that the root fs is actually mounted. I found the situation a bit puzzling, and would be interested to hear any thoughts on it. As a side note, it is possible to resize the root partition in a second computer using YaST and then install software from the on-line repos. -Alex -- To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org

2 2

[opensuse-arm] Using ssh -X on 13.1 JEOS; also problem logging directly into the Beagle Bone Black
by lists 25 Jun '14

25 Jun '14

I'm trying to open a terminal window with graphics on my desktop to ssh into the Beagle Bone Black running opensuse 13.1 JEOS. I installed x11-server, but that doesn't appear to be enough. command format is ssh -X me(a)xxx.xxx.xxx.xx Note also I can't log into the BBB from the using the graphic display and usb for keyboard/mouse. I get the login and password boxes, I see login successful flash on the screen, then it immediately goes back to the login box. A non-graphics ssh into the computer is fine. In fact, I could live with ncurses, but I have an app that uses Qt graphics just to set it up. I loaded qt3 and mono-qt. No luck. -- To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org

3 10

[opensuse-arm] Cubox-i - U-Boot
by Josua Mayer 24 Jun '14

24 Jun '14

Greetings you armed lizards, Now that my u-boot package adaptation for the cubox-i is basically finished I would like to get it merged into the Base:System:u-boot package. But there is a nasty showstopper! My patch conflicts with the mlo-ext2.patch, which btw looks rather hacky. The conflict is basically all about this line: + boot_mode = MMCSD_MODE_FAT; /* Fix OMAP4 boot */ Now I would like to know if this patch is needed, and also if my patch for the cubox-i does replace it. Maybe owners of omap4 devices using this patch can shed some light here? My adapted package can be found here: https://build.opensuse.org/package/show/home:mayerjosua:cubox-i/u-boot 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

3 2

[opensuse-arm] openSUSE-13.1-ARM-JeOS-beaglebone.armv7l-1.12.1-Build37.1.raw.xz boot issue
by lists 24 Jun '14

24 Jun '14

Boot issue? Well it doesn't. Here is the serial port output: ------------------------------------ \0x01\0x00 U-Boot SPL 2013.04-dirty (Jul 10 2013 - 14:02:53) musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, HB-ISO Rx, HB-ISO Tx, SoftConn) musb-hdrc: MHDRC RTL version 2.0 musb-hdrc: setup fifo_mode 4 musb-hdrc: 28/31 max ep, 16384/16384 memory USB Peripheral mode controller at 47401000 using PIO, IRQ 0 musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, HB-ISO Rx, HB-ISO Tx, SoftConn) musb-hdrc: MHDRC RTL version 2.0 musb-hdrc: setup fifo_mode 4 musb-hdrc: 28/31 max ep, 16384/16384 memory USB Host mode controller at 47401800 using PIO, IRQ 0 OMAP SD/MMC: 0 mmc_send_cmd : timeout: No status update reading u-boot.img reading u-boot.img U-Boot 2013.04-dirty (Jul 10 2013 - 14:02:53) I2C: ready DRAM: 512 MiB WARNING: Caches not enabled NAND: No NAND device found!!! 0 MiB MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1 *** Warning - readenv() failed, using default environment musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, HB-ISO Rx, HB-ISO Tx, SoftConn) musb-hdrc: MHDRC RTL version 2.0 musb-hdrc: setup fifo_mode 4 musb-hdrc: 28/31 max ep, 16384/16384 memory USB Peripheral mode controller at 47401000 using PIO, IRQ 0 musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, HB-ISO Rx, HB-ISO Tx, SoftConn) musb-hdrc: MHDRC RTL version 2.0 musb-hdrc: setup fifo_mode 4 musb-hdrc: 28/31 max ep, 16384/16384 memory USB Host mode controller at 47401800 using PIO, IRQ 0 Net: <ethaddr> not set. Validating first E-fuse MAC cpsw, usb_ether Hit any key to stop autoboot: 1 \0x08\0x08\0x08 0 gpio: pin 53 (gpio 53) value is 1 mmc0 is current device micro SD card found mmc0 is current device gpio: pin 54 (gpio 54) value is 1 SD/MMC found on device 0 Failed to mount ext2 filesystem... ** Unrecognized filesystem type ** gpio: pin 55 (gpio 55) value is 1 ** No partition table - mmc 0 ** -- To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org

2 2

[opensuse-arm] cavium
by Peter Czanik 13 Jun '14

13 Jun '14

Hi, I just read this: http://www.cavium.com/newsevents_Cavium_openSUSE_Community_Announces_Partne… Do you have any info, when this will be available? Does anybody have any first hand experience how openSUSE runs on it? It looks very promising! Bye, CzP -- 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] 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

[opensuse-arm] barebox bootloader
by Matwey V. Kornilov 29 May '14

29 May '14

Hi, What do you think about supporting barebox as arm-bootloader in parallel with u-boot? Is it going to be successor of u-boot? -- 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] Factory signing key(s) expired
by Andreas Färber 22 May '14

22 May '14

Hello, Both for ARMv6 and for ARMv7 I've been getting the warning that the signing key of the Factory repository has expired on May 4th. Warnung:The gpg key signing file 'content' has expired. Repository: openSUSE-Factory-repo-oss Key Name: openSUSE Project Signing Key <opensuse(a)opensuse.org> Key Fingerprint: 22C07BA534178CD02EFE22AAB88B2FD43DBDC284 Key Created: Fr 07 Nov 2008 15:10:07 CET Key Expires: So 04 Mai 2014 17:01:33 CEST (ABGELAUFEN) Rpm Name: gpg-pubkey-3dbdc284-49144c3f Is anyone aware of that and working on a fix? 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

3 6

[opensuse-arm] kernel-default 3.15-rc5 working on Raspberry Pi
by Andreas Färber 20 May '14

20 May '14

Hello, I have succeeded in booting our newly built kernel-default package from Kernel:HEAD on the Raspberry Pi model B with Factory and 3.15-rc2+. Here's a quick how-to: In yast, add Kernel:HEAD repository: http://download.opensuse.org/repositories/Kernel:/HEAD/ARM/ Install the kernel package: # zypper in kernel-default-3.15.rc5 Prepare initrd settings in /etc/sysconfig/kernel: INITRD_MODULES="sdhci-bcm2835" Create an initrd: # mkinitrd -v -k zImage-3.15.0-rc5-6.g923c7d2-default \ -i initrd-3.15.0-rc5-6.g923c7d2-default Make the files accessible to U-Boot: # cd /boot # ln -sf zImage-3.15.0-rc5-6.g923c7d2-default zImage # ln -sf initrd-3.15.0-rc5-6.g923c7d2-default initrd In your boot.scr make sure that the initrd is loaded as well, e.g.: setenv bootargs 'console=ttyAMA0,115200 console=tty1 root=/dev/mmcblk0p3 rootfstype=ext4 rw rootwait dwc_otg.lpm_enable=0' ext2load mmc 0:2 ${kernel_addr_r} zImage ext2load mmc 0:2 ${fdt_addr_r} dtb/bcm2835-rpi-b.dtb ext2load mmc 0:2 ${ramdisk_addr_r} initrd bootz ${kernel_addr_r} ${ramdisk_addr_r}:0x${filesize} ${fdt_addr_r} # mkimage -A arm -O linux -T script -C none -a 0 -e 0 -n Boot-Script \ -d boot.script .../boot.scr Now what's still missing for a proper JeOS image is the QEMU problem with partitioning in Kiwi, and right now the build is unresolvable. Cheers, 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

3 3

[opensuse-arm] Chromebook boot fixed, please accept SR #234660
by Guillaume Gardet 19 May '14

19 May '14

Hi, I fixed Chromebook boot after fisrt boot repartition with Marcus help. Please accept SR #234660 I also removed eth0 configuration for chromebook and added a wlan0 interface. That way, the wireless interface show up by default in YaST lan module. Guillaume -- To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org

2 5

[opensuse-arm] kernel-exynos 3.15-rc5 build failure
by Andreas Färber 19 May '14

19 May '14

Hi, kernel-exynos is failing as follows: [22654s] drivers/built-in.o: In function `exynos_drm_attach_lcd_bridge': [22654s] /home/abuild/rpmbuild/BUILD/kernel-exynos-3.15.rc5/linux-3.15-rc5/drivers/gpu/drm/exynos/exynos_dp_core.c:1004: undefined reference to `ptn3460_init' [22669s] /home/abuild/rpmbuild/BUILD/kernel-exynos-3.15.rc5/linux-3.15-rc5/Makefile:882: recipe for target 'vmlinux' failed [22669s] make[2]: *** [vmlinux] Error 1 [22669s] Makefile:148: recipe for target 'sub-make' failed [22669s] make[1]: *** [sub-make] Error 2 [22669s] Makefile:26: recipe for target 'all' failed [22669s] make: *** [all] Error 2 https://build.opensuse.org/package/live_build_log/Kernel:HEAD/kernel-exynos… Anyone any insights how to resolve? 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

3 5

Re: [opensuse-arm] Installing on semi-custom OK210 board.....
by Isaac Martinez G. 19 May '14

19 May '14

Thank you very much for bringing some light into this... I got the files from the manufacturer.... They built U-boot, then the linux kernel...then the created the image for flashing the board... Everything in Ubuntu Now, I am trying to do it on opensuse.... 1.-Building U-boot.. I get the following: make: arm-none-linux-gnueabi-gcc: Command not found I got the ARM crosscompiler in opensuse... cross-armv7hl-gcc47-icecream-backend - The GNU C Compiler and Support Files Is that the equivalent of the gnueabi??? I tried to find some answer online, but everything is for another distribution... not Suse... How can it be done using the suse x-compiler??? On Sunday, May 18, 2014 10:15 AM, Andreas Färber <afaerber(a)suse.de> wrote: Hi, Am 17.05.2014 20:22, schrieb Isaac Martinez G.: > > I got an ARM board on Ebay from Forlinx embedded. > Nice piece of hardware and planing to use to control an exotic piece of laboratory equipment. > > OK210 (you can search on Ebay for it) > > Architecture: Cortex-A8 > Processor: Samsung S5PV210 chip > 512MB of DDRII > 1GB of flash > > 1GHZ clock > > I took a look a the wiki... given that the board is obviously not on the list. > I downloaded the files (still deciding which one to use): > > openSUSE-13.1-ARM-JeOS.armv7-rootfs.armv7l-1.12.1-Build33.1.tbz > > and > > openSUSE-13.1-ARM-JeOS.armv7-rootfs.armv7l-1.12.1-Build33.1.tbz Those two look identical to me? ;) For a beginner, 13.1 is a safe choice, in case you were considering Factory as alternative (pretty usable recently, but you never know). > The instructions and wiki are not exactly great for non hardcore programmers. > > "And make your own SD card to boot on, with first bootloader > (manufacturer specific), U-Boot (configured for your board) and a kernel > (configured for your board) if openSUSE does not provide it" > > Could anybody explain or point out where I can get more information on actually how to do it???? The point is that there are no generic instructions, it does highly depend on the board. Usually the manufacturer's website has either instructions how to do it or a downloadable image that you can peek at using parted etc. Finding that information or figuring it out is the biggest obstacle in adding board support... Which bootloader(s) are required for the board? While I don't know the OK210, I have access to a board with an S5PV210: The armStoneA8 uses a preinstalled proprietary firmware NBoot in flash, which then loads U-Boot - also in flash. Other boards load U-Boot from an offset inside an unformatted first partition on the SD card, the Raspberry Pi even from a FAT partition. How can your bootloader load the kernel? U-Boot imposes how to further set up your partitions - in the best case your U-Boot is upstream and/or supports (or can be patched to support) ext4, then you can do one big ext4 partition with rootfs and kernel. Otherwise you'll have to prepend another partition for kernel/initrd, with preference from ext3, ext2 down to fat - I usually take ~100MB. Preference is usually for booting from SD card because of flexibility to fix on another machine or to some day exchange it in case of wear. Other boot options might include USB, SATA, TFTP and NFS. Which kernel format to choose? If bootz command is available in U-Boot, use a zImage; otherwise use a uImage (bootm command). Device trees S5PV210 does still not support the multi v7 kernel config upstream, so you can likely ignore anything you read about .dtb files for now. Graphics Note that the S5PV210 has a PowerVR SGX540 GPU, for which no real Open Source driver exists today: http://powervr.gnu.org.ve/doku.php HTH, 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

1 0

[opensuse-arm] Installing on semi-custom OK210 board.....
by Isaac Martinez G. 18 May '14

18 May '14

Hello everybody: Ok, I am a total beginner when it comes to install Suse on an embedded board. I got an ARM board on Ebay from Forlinx embedded. Nice piece of hardware and planing to use to control an exotic piece of laboratory equipment. OK210 (you can search on Ebay for it) Architecture: Cortex-A8 Processor: Samsung S5PV210 chip 512MB of DDRII 1GB of flash 1GHZ clock I took a look a the wiki... given that the board is obviously not on the list. I downloaded the files (still deciding which one to use): openSUSE-13.1-ARM-JeOS.armv7-rootfs.armv7l-1.12.1-Build33.1.tbz and openSUSE-13.1-ARM-JeOS.armv7-rootfs.armv7l-1.12.1-Build33.1.tbz The instructions and wiki are not exactly great for non hardcore programmers. "And make your own SD card to boot on, with first bootloader (manufacturer specific), U-Boot (configured for your board) and a kernel (configured for your board) if openSUSE does not provide it" Could anybody explain or point out where I can get more information on actually how to do it???? I am sort of clueless..... willing to share all what I get done on this little board. Thank you "Do not spend too much time in the lab, or you will get a one pack!!" (Instead of a six pack abs!!) "Do not spend too much time in the lab, or you will get a one pack!!" (Instead of a six pack abs!!) -- To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org

2 1