November 2016 - openSUSE ARM - openSUSE Mailing Lists

[opensuse-arm] wlan getting new hw-address every 5 minutes on raspberry pi 3
by Jogchum Reitsma 15 Nov '16

15 Nov '16

Hi, After succeeding in getting wifi enabled on the pi 3 (see my previous posting 6th of nov., 20:31 WET, and follow ups) the next problem arises: every 5 minutes the wifi connection gets another hw-address, and hence another ip address... Rather inconvenient. Dmesg spits out the following: [ 1306.573949] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready [ 1306.576314] brcmfmac: brcmf_cfg80211_reg_notifier: not a ISO3166 code [ 1306.576327] cfg80211: World regulatory domain updated: [ 1306.576341] cfg80211: DFS Master region: unset [ 1306.576341] cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp), (dfs_cac_time) [ 1306.576347] cfg80211: (2402000 KHz - 2472000 KHz @ 40000 KHz), (N/A, 2000 mBm), (N/A) [ 1306.576352] cfg80211: (2457000 KHz - 2482000 KHz @ 20000 KHz, 92000 KHz AUTO), (N/A, 2000 mBm), (N/A) [ 1306.576355] cfg80211: (2474000 KHz - 2494000 KHz @ 20000 KHz), (N/A, 2000 mBm), (N/A) [ 1306.576359] cfg80211: (5170000 KHz - 5250000 KHz @ 80000 KHz, 160000 KHz AUTO), (N/A, 2000 mBm), (N/A) [ 1306.576362] cfg80211: (5250000 KHz - 5330000 KHz @ 80000 KHz, 160000 KHz AUTO), (N/A, 2000 mBm), (0 s) [ 1306.576366] cfg80211: (5490000 KHz - 5730000 KHz @ 160000 KHz), (N/A, 2000 mBm), (0 s) [ 1306.576370] cfg80211: (5735000 KHz - 5835000 KHz @ 80000 KHz), (N/A, 2000 mBm), (N/A) [ 1306.576373] cfg80211: (57240000 KHz - 63720000 KHz @ 2160000 KHz), (N/A, 0 mBm), (N/A) [ 1307.277503] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready [ 1622.583086] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready [ 1622.585585] brcmfmac: brcmf_cfg80211_reg_notifier: not a ISO3166 code [ 1622.585603] cfg80211: World regulatory domain updated: [ 1622.585611] cfg80211: DFS Master region: unset [ 1622.585611] cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp), (dfs_cac_time) [ 1622.585618] cfg80211: (2402000 KHz - 2472000 KHz @ 40000 KHz), (N/A, 2000 mBm), (N/A) [ 1622.585623] cfg80211: (2457000 KHz - 2482000 KHz @ 20000 KHz, 92000 KHz AUTO), (N/A, 2000 mBm), (N/A) [ 1622.585626] cfg80211: (2474000 KHz - 2494000 KHz @ 20000 KHz), (N/A, 2000 mBm), (N/A) [ 1622.585630] cfg80211: (5170000 KHz - 5250000 KHz @ 80000 KHz, 160000 KHz AUTO), (N/A, 2000 mBm), (N/A) [ 1622.585634] cfg80211: (5250000 KHz - 5330000 KHz @ 80000 KHz, 160000 KHz AUTO), (N/A, 2000 mBm), (0 s) [ 1622.585637] cfg80211: (5490000 KHz - 5730000 KHz @ 160000 KHz), (N/A, 2000 mBm), (0 s) [ 1622.585641] cfg80211: (5735000 KHz - 5835000 KHz @ 80000 KHz), (N/A, 2000 mBm), (N/A) [ 1622.585644] cfg80211: (57240000 KHz - 63720000 KHz @ 2160000 KHz), (N/A, 0 mBm), (N/A) [ 1623.287611] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready [ 1938.580273] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready [ 1938.587515] brcmfmac: brcmf_cfg80211_reg_notifier: not a ISO3166 code [ 1938.587571] cfg80211: World regulatory domain updated: [ 1938.587604] cfg80211: DFS Master region: unset [ 1938.587604] cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp), (dfs_cac_time) [ 1938.587617] cfg80211: (2402000 KHz - 2472000 KHz @ 40000 KHz), (N/A, 2000 mBm), (N/A) [ 1938.587633] cfg80211: (2457000 KHz - 2482000 KHz @ 20000 KHz, 92000 KHz AUTO), (N/A, 2000 mBm), (N/A) [ 1938.587654] cfg80211: (2474000 KHz - 2494000 KHz @ 20000 KHz), (N/A, 2000 mBm), (N/A) [ 1938.587666] cfg80211: (5170000 KHz - 5250000 KHz @ 80000 KHz, 160000 KHz AUTO), (N/A, 2000 mBm), (N/A) [ 1938.587676] cfg80211: (5250000 KHz - 5330000 KHz @ 80000 KHz, 160000 KHz AUTO), (N/A, 2000 mBm), (0 s) [ 1938.587687] cfg80211: (5490000 KHz - 5730000 KHz @ 160000 KHz), (N/A, 2000 mBm), (0 s) [ 1938.587694] cfg80211: (5735000 KHz - 5835000 KHz @ 80000 KHz), (N/A, 2000 mBm), (N/A) [ 1938.587705] cfg80211: (57240000 KHz - 63720000 KHz @ 2160000 KHz), (N/A, 0 mBm), (N/A) [ 1939.294771] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready [ 2083.905735] fuse init (API version 7.23) [ 2254.629486] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready [ 2254.631800] brcmfmac: brcmf_cfg80211_reg_notifier: not a ISO3166 code [ 2254.631815] cfg80211: World regulatory domain updated: [ 2254.631823] cfg80211: DFS Master region: unset [ 2254.631823] cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp), (dfs_cac_time) [ 2254.631828] cfg80211: (2402000 KHz - 2472000 KHz @ 40000 KHz), (N/A, 2000 mBm), (N/A) [ 2254.631833] cfg80211: (2457000 KHz - 2482000 KHz @ 20000 KHz, 92000 KHz AUTO), (N/A, 2000 mBm), (N/A) [ 2254.631836] cfg80211: (2474000 KHz - 2494000 KHz @ 20000 KHz), (N/A, 2000 mBm), (N/A) [ 2254.631840] cfg80211: (5170000 KHz - 5250000 KHz @ 80000 KHz, 160000 KHz AUTO), (N/A, 2000 mBm), (N/A) [ 2254.631844] cfg80211: (5250000 KHz - 5330000 KHz @ 80000 KHz, 160000 KHz AUTO), (N/A, 2000 mBm), (0 s) [ 2254.631847] cfg80211: (5490000 KHz - 5730000 KHz @ 160000 KHz), (N/A, 2000 mBm), (0 s) [ 2254.631850] cfg80211: (5735000 KHz - 5835000 KHz @ 80000 KHz), (N/A, 2000 mBm), (N/A) [ 2254.631853] cfg80211: (57240000 KHz - 63720000 KHz @ 2160000 KHz), (N/A, 0 mBm), (N/A) [ 2255.303333] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready ================================================================ ever going. What is going on here, and what can be done? Of course I did some googling, but I didn't find anything alike... Regards, Jogchum -- To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org

4 12

[opensuse-arm] raspberry pi 3 D-state hung
by Matwey V. Kornilov 15 Nov '16

15 Nov '16

Hello, I am running 4.4.24-4-default from devel:ARM:Factory:Contrib:RaspberryPi3 and sometimes see the following when do readings from /sys like # cat /sys/devices/system/cpu/cpu?/cpufreq/cpuinfo_cur_freq [ 9138.093049] INFO: task cat:4444 blocked for more than 50 seconds. [ 9138.093058] Not tainted 4.4.24-4-default #1 [ 9138.093060] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 9138.093073] cat D ffff800000086c28 0 4444 4426 0x00000001 [ 9138.093076] Call trace: [ 9138.093090] [<ffff800000086c28>] __switch_to+0x90/0xa8 [ 9138.093097] [<ffff800000749d14>] __schedule+0x234/0x758 [ 9138.093100] [<ffff80000074a278>] schedule+0x40/0xa0 [ 9138.093105] [<ffff80000074d25c>] schedule_timeout+0x214/0x280 [ 9138.093109] [<ffff80000074ae8c>] wait_for_common+0xb4/0x168 [ 9138.093113] [<ffff80000074af68>] wait_for_completion+0x28/0x38 [ 9138.093119] [<ffff8000005dd6f0>] rpi_firmware_property_list+0x120/0x280 [ 9138.093122] [<ffff8000005dd8d0>] rpi_firmware_property+0x80/0xc8 [ 9138.093133] [<ffff7ffffc115088>] bcm2835_cpufreq_get_clock+0x38/0x88 [bcm2835_cpufreq] [ 9138.093138] [<ffff7ffffc1150f4>] bcm2835_cpufreq_get+0x1c/0x28 [bcm2835_cpufreq] [ 9138.093144] [<ffff8000005d1264>] __cpufreq_get+0x34/0xc8 [ 9138.093148] [<ffff8000005d3304>] show_cpuinfo_cur_freq+0x24/0x78 [ 9138.093151] [<ffff8000005d1208>] show+0x48/0x70 [ 9138.093157] [<ffff8000002cb990>] sysfs_kf_seq_show+0xc0/0x158 [ 9138.093161] [<ffff8000002c9f94>] kernfs_seq_show+0x44/0x50 [ 9138.093166] [<ffff80000026cdac>] seq_read+0x17c/0x438 [ 9138.093169] [<ffff8000002cac34>] kernfs_fop_read+0x124/0x1b0 [ 9138.093175] [<ffff800000246430>] __vfs_read+0x48/0xf8 [ 9138.093178] [<ffff800000246e38>] vfs_read+0x88/0x160 [ 9138.093182] [<ffff800000247bc4>] SyS_read+0x54/0xb0 [ 9138.093187] [<ffff800000085e04>] el0_svc_naked+0x38/0x3c So, what do you think? Is it known? Probably I just need to try kernel 4.8.6 from openSUSE:Factory:ARM? -- 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] Booting a Surface RT (Arm based) from openSUSE media
by Greg Freemyer 14 Nov '16

14 Nov '16

I need to boot a Surface RT (Arm based) from boot media so I can grab a copy of the hard drive (SSD) contents. I don't specifically need openSUSE, but it is what I know best. The contents are encrypted, but I have the decryption keys so that isn't a problem. Can anyone point me at what I need to know / do for this to happen. Thanks Greg -- Greg Freemyer -- To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org

3 8

[opensuse-arm] Raspberry Pi 1&2 (probably 3, too) borken due to u-boot / grub setup.
by Stefan Seyfried 13 Nov '16

13 Nov '16

Hi, after years of just ignoring openSUSE for rpi, and using yocto/openembedded, I thought I'd try it again. After all, I could even get support for it on raspi3 (which I do not yet have) ;-) It is still broken the same as when I last tried. The reason when booted normally, as almost everyone does, start.elf reads config.txt, configures the hardware according to it *and passes some customized boot parameters to the kernel*. Example (on a working yocto/OE-build, but raspbian does the same): root@raspi02:~# cat /proc/cmdline dma.dmachans=0x7f35 bcm2708_fb.fbwidth=640 bcm2708_fb.fbheight=480 bcm2708.boardrev=0xe bcm2708.serial=0x6xxxxxxx smsc95xx.macaddr=B8:27:EB:A9:00:DE bcm2708_fb.fbswap=1 sdhci-bcm2708.emmc_clock_freq=250000000 vc_mem.mem_base=0x1fa00000 vc_mem.mem_size=0x20000000 dwc_otg.lpm_enable=0 console=ttyAMA0,115200 kgdboc=ttyAMA0,115200 root=/dev/mmcblk0p2 rootfstype=ext4 rootwait console=tty0 now some of these are static, namely root@raspi02:~# strings /media/mmcblk0p1/start.elf|grep root= console=ttyAMA0,115200 kgdboc=ttyAMA0,115200 console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 rootwait but others are dynamic, and filled in by start.elf root@raspi02:~# strings /media/mmcblk0p1/start.elf|grep ^dma\\. dma.dmachans=0x%x bcm2708_fb.fbwidth=%d bcm2708_fb.fbheight=%d bcm2708.boardrev=0x%x bcm2708.serial=0x%x root@raspi02:~# strings /media/mmcblk0p1/start.elf|grep vc_mem\\. vc_mem.mem_base=0x%x vc_mem.mem_size=0x%x The worst part of this is, that the serial number and the mac address are not set. The NIC comes up with a random mac address and the raspi gets a new IP address on every boot. Not nice. So what's needed to fix this? Due to the convoluted way openSUSE does boot, the command line needs to be passed from start.elf to u-boot (easy, see below), then from u-boot to grub2-efi (here I gave up) and then in grub.cfg to the kernel. I have a patched, working u-boot-rpi2 in https://build.opensuse.org/package/show/home:seife:branches:Base:System/u-b… (this is a proof of concept patch, it exports the command line as "bootargs_orig" variable to the u-boot shell) I'm back to openembedded on the raspis for now, will check if SLES12-SP2 is really sold with this bug too, once I get my hands on an raspberrypi3 :-) have fun, seife -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- 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] Raspberry Pi3: working system?
by Edgar Dombrowski 11 Nov '16

11 Nov '16

Hi, OpenSuse-Raspberry Pi friends. I downloaded yesterday 2 of the "latest ?" Tumbleweed versions - the armV6 and the armV7-versions and installed them on 2 sd-sticks. After installation on a Raspi 3B - Board (and although on a Raspi-2B+ board) and applying power, only te PWR-Led lights, but not the ACT-Led and no further activity indicated on the Monitor. With "Debian-Jessie" no problemindicating tht the board is working. Using gparted on my main PC, shows 3 partitions: Nbr. 2 für "/BOOT" and Nbr. 3 für "/". I tried to ask a member of the Novell-Team at the actual ELECTRONICA-Fair in Munich, but he had no answer. Any ideas to solve my problem? Thank you for your assistance Mfg 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

1 0

[opensuse-arm] Still no wlan on Raspberry 3
by Jogchum Reitsma 08 Nov '16

08 Nov '16

Hi, Installing the latest aarch64 XFCE image (http://download.opensuse.org/repositories/devel:/ARM:/Factory:/Contrib:/Ras…) I still cannot get wifi to work. Is there any chance it will be available soonish? Regards, Jogchum Reitsma -- To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org

4 9

[opensuse-arm] grub2 at RPi3: press t to show the boot menu
by Matwey V. Kornilov 07 Nov '16

07 Nov '16

Hello, I am running aarch64 Raspberry Pi3 image with Tumbleweed, grub2-2.02~beta3-12.1.aarch64 u-boot-rpi3-2016.07-5.1.aarch64 At booting I see the following (I use serial console and don't use graphical terminal): ## Starting EFI application at 0x01000000 ... Scanning disks on usb... Scanning disks on mmc... MMC Device 1 not found MMC Device 2 not found MMC Device 3 not found Found 5 disks Welcome to GRUB! Please press t to show the boot menu on this console And nothing happens until I press 't'. And I've failed to find the setting in /etc/default/grub to disable this waiting. Could you help me? -- 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] Turris Omnia (prototype) enablement report
by Andreas Färber 06 Nov '16

06 Nov '16

Hello, This weekend I've had the opportunity to test openSUSE on a prototype of CZ.NIC's Indiegogo-funded Turris Omnia router [1]. In a FOSDEM 2016 talk a prototype had already been shown to the public, whereas this was the first time we could peek at the current software environment of a running prototype ourselves and provide some early third-party distro feedback to its creators. Known for being overly critical and aiming at perfect solutions, let me say in advance that the Armada 385 mainline kernel support looks quite good already, needing only the Turris Omnia Device Tree [2] apparently. Turris Omnia's U-Boot [3] is quite usable but will need a little more love before we can benefit from new features such as UEFI boot support (both upstream where it's not yet using the distro defaults [4] and downstream for deriving a clean new turris_omnia_defconfig). I'm confident that most of the functional limitations I observed can be fixed until the final board version ships to backers. That said, here's a quick how-to I would've added to the Wiki [1] if it let me... == Manual installation == As of 2016-03-18, the prototype's U-Boot does not yet support XHCI, so that the two USB ports cannot be used for booting. That leaves eMMC and mSATA as local boot options. === Building an upstream kernel === Use mvebu_v7_defconfig and enable CONFIG_BTRFS_FS. === Installation to USB === As of 2016-03-18, the prototype's U-Boot does not yet support XHCI and therefore does not recognize any USB devices on either of the two USB ports. Still you can place your rootfs onto USB. As of 2016-03-18, the prototype's kernel has USB drivers built as modules and no initrd, so you cannot directly boot a USB rootfs with it. An easy solution is to build an upstream kernel yourself with those drivers built-in and to copy it to the eMMC's /boot directory (e.g., zImage-next). Note: In linux-next.git next-20160318 kernel only USB 3.0 devices work. Partition your USB disk with GPT or MBR. Create a partition for the rootfs and extract an [http://download.opensuse.org/ports/armv7hl/tumbleweed/images/openSUSE-Tumbl… openSUSE-Tumbleweed-JeOS.armv7-rootfs.armv7l-Current.tbz] tarball. Then boot similar to this (derived from bootargs and mmcboot variables): setenv bootargs 'console=ttyS0,115200 root=/dev/sda1 rootfstype=ext4 rootwait rw' btrload mmc 0 0x01000000 boot/zImage-next @ btrload mmc 0 0x02000000 boot/dtb @ bootz 0x01000000 - 0x02000000 Note: As always, "/dev/sda1" is unsafe as it may become, e.g., /dev/sdb1 when an mSATA SSD or a second USB storage device is connected. You could save those commands in a U-Boot environment variable, otherwise you will need to re-type them on each boot. === Installation to mSATA === Unless you have another device with mSATA port, you may find it difficult to set up the SSD. As of 2016-03-18, the prototype's OpenWrt kernel did not recognize a Samsung SSD 850 EVO 120 GB mSATA card (while U-Boot's scsi scan does). As workaround you can compile an upstream kernel (cf. [[#Building_an_upstrea_kernel|above]]), copy it under a new name to /boot on the eMMC (e.g., zImage-next) and boot OpenWrt with this new kernel (derived from mmcboot variable): btrload mmc 0 0x01000000 boot/zImage-next @ btrload mmc 0 0x02000000 boot/dtb @ bootz 0x01000000 - 0x02000000 Now that you have a /dev/sda device for the mSATA SSD, you may find that OpenWrt does not come with parted, fdisk or gdisk tools for partitioning this device. One solution is to boot into openSUSE Tumbleweed, where you can easily install those tools, from USB (cf. [[#Installation_to_USB|above]]): setenv bootargs 'console=ttyS0,115200 root=/dev/sdb1 rootfstype=ext4 rootwait rw' btrload mmc 0 0x01000000 boot/zImage-next @ btrload mmc 0 0x02000000 boot/dtb @ bootz 0x01000000 - 0x02000000 >From inside openSUSE verify that /dev/sda is your mSATA card and partition it using gdisk (zypper in gptfdisk). Format your new partition and extract a JeOS rootfs tarball. For now just copy zImage-next and dtb over. mount /dev/sda1 /mnt tar xvjf [http://download.opensuse.org/ports/armv7hl/tumbleweed/images/openSUSE-Tumbl… openSUSE-Tumbleweed-JeOS.armv7-rootfs.armv7l-XXX.tbz] -C /mnt cp /boot/zImage-next /mnt/boot/zImage-next cp /boot/dtb /mnt/boot/armada-385-turris-omnia.dtb ln -sf zImage-next /mnt/boot/zImage ln -sf armada-385-turris-omnia.dtb /mnt/boot/dtb Boot similar to this: setenv bootargs 'console=ttyS0,115200 root=/dev/sda1 rootfstype=btrfs rootwait rw' setenv fdtfile armada-385-turris-omnia.dtb scsi scan btrload scsi 0:1 0x01000000 boot/zImage-next btrload scsi 0:1 0x02000000 boot/dtb/$fdtfile bootz 0x01000000 - 0x02000000 It's beginning to look much more like openSUSE, just lacking an openSUSE kernel still. === Installation to eMMC === In theory you can also replace OpenWrt with openSUSE, optionally backing it up as btrfs snapshot. To do so you'll need to boot from some other root device such as USB or mSATA. mount /dev/mmcblk0p1 /mnt btrfs subvolume snapshot /mnt/@ /mnt/root-pre-opensuse rm -rf /mnt/@/* tar xvjf [http://download.opensuse.org/ports/armv7hl/tumbleweed/images/openSUSE-Tumbl… openSUSE-Tumbleweed-JeOS.armv7-rootfs.armv7l-XXX.tbz] -C /mnt/@ cp /boot/zImage-next /mnt/@/boot/zImage-next cp /boot/dtb /mnt/(a)/boot/armada-385-turris-omnia.dtb ln -sf zImage-next /mnt/@/boot/zImage ln -sf armada-385-turris-omnia.dtb /mnt/@/boot/dtb Then on next boot you should boot into openSUSE automatically. === openSUSE kernel === Unlike mvebu_v7_defconfig, the openSUSE kernels build drivers as modules whenever possible. To boot you will need additional driver modules in a ramdisk. There's two easy ways to create such an initrd file. Either use Kiwi (as done for our JeOS SD card images) or boot into the system once without modules and have the initrd be created by dracut. If you zypper up or zypper dup the system for the first time, chances are a new kernel-default package gets installed and generates an initrd; you can force this the easy way by reinstalling the package (zypper in -f kernel-default) or figure out the lengthy dracut command line. Try to boot it like this: setenv bootargs 'console=ttyS0,115200 root=/dev/sda1 rootfstype=btrfs rootwait rw' scsi scan btrload scsi 0:1 0x01000000 boot/zImage btrload scsi 0:1 0x02000000 boot/dtb/armada-385-turris-omnia.dtb btrload scsi 0:1 0x03000000 boot/initrd bootz 0x01000000 0x03000000:$filesize 0x02000000 This resulted in: Kernel image @ 0x1000000 [ 0x000000 - 0x6f2d78 ] Wrong Ramdisk Image Format Ramdisk image is corrupt or invalid ''To be investigated - U-Boot lacking CONFIG_SUPPORT_RAW_INITRD?'' This is blocking creation of a JeOS disk image. Cheers, Andreas [1] https://en.opensuse.org/HCL:Turris_Omnia [2] https://gitlab.labs.nic.cz/turris/openwrt/tree/test/target/linux/mvebu/file… [3] https://gitlab.labs.nic.cz/turris/turris-omnia-uboot/commits/omnia [4] http://git.denx.de/?p=u-boot.git;a=blob;f=include/configs/db-88f6820-gp.h;h… -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton; HRB 21284 (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

Re: [opensuse-arm] BananaPi - usb out of function
by Stefan Mack 05 Nov '16

05 Nov '16

...solved... usb works fine! the reason: Modul axp20x_i2c isn't loaded during boot. the solution: vi /etc/modules-load.d/arm.conf axp20x_i2c Regards Stefan -------- Weitergeleitete Nachricht -------- Von: Stefan Mack <mack.stefan(a)web.de> An: Andreas Färber <afaerber(a)suse.de>, opensuse-arm(a)opensuse.org Betreff: Re: [opensuse-arm] BananaPi - usb out of function Datum: Wed, 02 Nov 2016 20:04:31 +0100 Hello Andreas, I just opened a Bugzilla ticket and CC to you. I hope everything is o.k. I did. With the actual banana-image (kernel 4.8.4) it usb dosn't work either. Thanks and regards Stefan -------- Weitergeleitete Nachricht -------- Von: Stefan Mack <mack.stefan(a)web.de> An: Andreas Färber <afaerber(a)suse.de>, opensuse-arm(a)opensuse.org Betreff: Re: [opensuse-arm] BananaPi - usb out of function Datum: Mon, 24 Oct 2016 19:32:18 +0200 Hello Andreas, today I installed a fresh JeOS-bananapi-image-Tumbleweed on my banana (SD-card). The results are: bananavdr:/home/stefan # dmesg |grep usb [ 0.391001] reg-fixed-voltage usb0-vbus: could not find pctldev for node /soc@01c00000/pinctrl@01c20800/usb0_vbus_pin@0, defe rring probe [ 0.391068] reg-fixed-voltage usb1-vbus: could not find pctldev for node /soc@01c00000/pinctrl@01c20800/usb1_vbus_pin@0, defe rring probe [ 0.391105] reg-fixed-voltage usb2-vbus: could not find pctldev for node /soc@01c00000/pinctrl@01c20800/usb2_vbus_pin@0, defe rring probe [ 4.618572] usb0-vbus: disabling [ 4.618581] usb1-vbus: disabling [ 4.618594] usb2-vbus: disabling [ 10.227698] usbcore: registered new interface driver usbfs [ 10.227805] usbcore: registered new interface driver hub [ 10.235037] usbcore: registered new device driver usb bananavdr:/home/stefan # lsusb bananavdr:/home/stefan # -> NOTHING bananavdr:/home/stefan # uname -a Linux bananavdr 4.7.6-1-default #1 SMP PREEMPT Fri Sep 30 12:22:14 UTC 2016 (fb37fcc) armv7l armv7l armv7l GNU/Linux The same result with kernel-lpae - no difference to the kernel-default. Where can I open a Bugzilla ticket? Is this the correct account and I need an acount? https://login.microfocus.com/nidp/idff/sso?id=132&sid=2&option=credenti al&sid=2&target=https://esp.microfocus.com/LAGBroker?%22https://bugzill a.opensuse.org/accessmanagerlogin.cgi?target=enter_bug.cgi?product%3Dop enSUSE%2520Tumbleweed%26format%3Dguided%22 Sorry for the delay and thank you very much! bananavdr:/home/stefan # lsmod | grep usb musb_hdrc 131072 1 sunxi udc_core 24576 1 musb_hdrc phy_sun4i_usb 16384 1 sunxi extcon 24576 2 sunxi,phy_sun4i_usb usbcore 253952 5 musb_hdrc,ohci_platform,ohci_hcd,ehci_hcd,ehci_platform usb_common 16384 4 sunxi,musb_hdrc,udc_core,usbcore Regards Stefan -------- Weitergeleitete Nachricht -------- Von: Andreas Färber <afaerber(a)suse.de> An: Stefan Mack <mack.stefan(a)web.de>, opensuse-arm(a)opensuse.org Betreff: Re: [opensuse-arm] BananaPi - usb out of function Datum: Sat, 15 Oct 2016 18:17:46 +0200 Hi Stefan, Am 10.10.2016 um 18:59 schrieb Stefan Mack: > I have an original Banana Pi and I'm using the JeOS-bananapi-image > from > the link you've posted. > > Network and sata are working fine. After the boot I log in per ssh > and > can copy the sd-image to the ssd. All is fine except usb. > I use the original power-in and not the OTG. > > Only keyboard, mouse or usb sticks aren't recogniced in the log and > don't work. > > Is the log enough? Unfortunately no. I understood you boot from SD, can login via ssh and then USB doesn't work in the SD-booted running system? Nothing to do with the SSD yet? If that is the case, please do open a Bugzilla ticket and CC me on it, so that we can track this. The full dmesg including kernel version and command line as well as lsusb output would be useful as a start. On my A20 based Cubietruck with kernel-lpae 4.8.0 it looks like this: andreas@lastwagen:~> dmesg | grep usb [ 0.695769] reg-fixed-voltage usb0-vbus: could not find pctldev for node /soc@01c00000/pinctrl@01c20800/usb0_vbus_pin@0, deferring probe [ 0.695808] reg-fixed-voltage usb1-vbus: could not find pctldev for node /soc@01c00000/pinctrl@01c20800/usb1_vbus_pin@0, deferring probe [ 0.695843] reg-fixed-voltage usb2-vbus: could not find pctldev for node /soc@01c00000/pinctrl@01c20800/usb2_vbus_pin@0, deferring probe [ 7.215472] usb0-vbus: disabling [ 7.218702] usb1-vbus: disabling [ 7.221930] usb2-vbus: disabling [ 10.404986] usbcore: registered new interface driver usbfs [ 10.410634] usbcore: registered new interface driver hub [ 10.424817] usbcore: registered new device driver usb [ 28.772266] ohci-platform 1c14400.usb: Generic Platform OHCI controller [ 28.854799] ohci-platform 1c14400.usb: new USB bus registered, assigned bus number 1 [ 28.948835] ohci-platform 1c14400.usb: irq 31, io mem 0x01c14400 [...] andreas@lastwagen:~> lsusb Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 004 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 001 Device 002: ID 067b:2303 Prolific Technology, Inc. PL2303 Serial Port Bus 001 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 005 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub The connected USB UART adapter (third line) works just fine. kernel-lpae 4.7.6 or 4.7.4 worked equally well last time I checked. I note that the bananapi image uses kernel-default. Have you tried installing kernel-lpae and rebooting? Regards, Andreas -- 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 Leap 42.2 on BeagleBone Black
by Matwey V. Kornilov 04 Nov '16

04 Nov '16

Hello, I've just booted Leap 42.2 on BBB: http://download.opensuse.org/repositories/home:/matwey:/experimental:/Leap:… Join the party! -- To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org

2 8