November 2016 - openSUSE ARM - openSUSE Mailing Lists

[opensuse-arm] Attempt to run KIWI on unsupported architecture 'armv8l'
by Dirk Müller 12 Apr '17

12 Apr '17

Hi, this is a known OBS bug, asked the admins to deploy a fix shortly. Greetings, Dirk -- 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] Request for testing help: openSUSE Leap 42.2 for ARMv7 images
by Dirk Müller 12 Dec '16

12 Dec '16

Hi All, over the last few days I've been pretty busy with enabling pre-configured appliances for ARMv7 and AArch64 on openSUSE Leap 42.2, and I'm happy to report that we now have some images available: http://download.opensuse.org/ports/armv7hl/distribution/leap/42.2/appliance… http://download.opensuse.org/ports/aarch64/distribution/leap/42.2/appliance… As you can see its a pretty elaborative list of images, and I don't have time to test all of them myself. so whoever is interested in having some of those variants working for him, please try them out and report both successes and failures. The overall goal is to announce the ARM port end of next week (Dec 1st) so it would be great to have some testing feedback before that (and << before that so that we can maybe even fix it before announcement). Thanks a lot in advance, Dirk -- To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org

14 19

[opensuse-arm] RFC: Expansion boards in the Wiki
by Andreas Färber 29 Nov '16

29 Nov '16

Hey guys, I recently started playing with connecting Raspberry Pi Hats and Arduino Shields to boards and am wondering where/how to document this. Hats may be compatible with multiple boards but may need board-specific instructions for the device tree. I am therefore thinking that an expansion-board-centric page with instructions for one or more boards may be the best approach. For ARM boards we are so far using the flat HCL namespace and a Category:ARM_devices to group them. Should we do the same for shields (HCL:Foo_Shield) and have another Category page to locate them? Or should we have some two-level namespace like HCL:Arduino_Shield/Foo? Another interesting question then is how would we generate a list of compatible expansion boards pages on, say, HCL:Raspberry_Pi2? Would that be possible if we had, e.g., Category:Raspberry_Pi_B+_Connector? Or should we rather manually maintain such bidirectional links? Any thoughts and suggestions appreciated. Cheers, Andreas -- 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 4

[opensuse-arm] SLES on RPi3
by Bill Merriam 23 Nov '16

23 Nov '16

It appears SUSE gave out free RPi3's with cool custom cases at SUSEcon. They had SLES installed on them. I wasn't there so I missed out on the cool case but it turns out you can still get a copy of SLES with a 365 day license and 60 days of patches. https://www.raspberrypi.org/blog/suse-linux-enterprise-server-for-raspberry… http://hackerboards.com/first-64-bit-distro-for-raspberry-pi-3-issuse/ https://www.suse.com/communities/blog/suse-linux-enterprise-server-raspberr… That blog post has this link for the download. Why do people use URL shorteners for links that are on web pages? http://tinyurl.com/slespi This weekend I have lots of versions of OpenSUSE for ARM and now SLES to test. Bill -- 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] Tumbleweed-Jeos fails on second boot on raspberry and pi and pi2
by Herbert Graeber 23 Nov '16

23 Nov '16

Hi! I tried the latest raspberry pi and pi2 images (armv6l-2016.1.15-Build57 resp. armv7l-2016.11.15-Build5.9). Both fail on the second boot with the error "ext4fs_devread read outside partition ...". Afterward it tries to boot from TFTP. Searching the net gives the suggestion, that the 64bit feature may be set on the ext4 partition, so that U-Boot cannot boot. I have found a matching opensuse bug report (boo#989284), too. But checking the partition with dumpe2fs and haven't found this feature. Are any hints how I can make the images work? How can help to resolve this issue? Here is the full log from the pi2: > U-Boot 2016.09.01 (Oct 15 2016 - 11:25:48 +0000) > > DRAM: 880 MiB > RPI 2 Model B (0xa01041) > MMC: bcm2835_sdhci: 0 > reading uboot.env > > ** Unable to read "uboot.env" from mmc0:1 ** > Using default environment > > In: serial > Out: lcd > Err: lcd > Net: Net Initialization Skipped > No ethernet found. > starting USB... > USB0: Core Release: 2.80a > scanning bus 0 for devices... 3 USB Device(s) found > scanning usb for storage devices... 0 Storage Device(s) found > scanning usb for ethernet devices... 1 Ethernet Device(s) found > Hit any key to stop autoboot: 0 > switch to partitions #0, OK > mmc0 is current device > Scanning mmc 0:2... > Found U-Boot script /boot/boot.scr > ext4fs_devread read outside partition 2225344 > ## Executing script at 02000000 > Wrong image format for "source" command > SCRIPT FAILED: continuing... > 11691 bytes read in 128 ms (88.9 KiB/s) > > USB device 0: unknown device > Waiting for Ethernet connection... unable to connect. > missing environment variable: pxeuuid > missing environment variable: bootfile Herbert

1 0

[opensuse-arm] ARM auto tests
by Guillaume Gardet 21 Nov '16

21 Nov '16

Hi ARM guys! I think current openQA AArch64 tests are done using qemu (at least virtualization). But, how far is ARM tests on real hardware? It seems os-autoinst support real hardware and I remember that some people worked on it during hackweeks. I would like to collect all information in order to maybe work on it a bit. For example, which devices do you use to power on/off boards. Did you use os-autoinst or some other tests tools? 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] Tests with images from http://download.opensuse.org/repositories/devel:/ARM:/Factory:/Contrib:/RaspberryPi3/images/
by Freek de Kruijf 19 Nov '16

19 Nov '16

I did tests with images from the above site on: openSUSE-Tumbleweed-ARM-JeOS-raspberrypi3.aarch64-2016.11.15-Build7. [4-6].raw.xz All did show the Grub boot screen and continued, but stopped with a message on my TV screen as in the attached photo. -- fr.gr. member openSUSE Freek de Kruijf

1 2

[opensuse-arm] Image from download /ports/aarch64/tumbleweed does not boot at all
by Freek de Kruijf 18 Nov '16

18 Nov '16

I tried from http://download.opensuse.org/ports/aarch64/tumbleweed/images/ the image: openSUSE-Tumbleweed-ARM-JeOS-raspberrypi3_aarch64.aarch64-2016.06.03- Build4.1.raw.xz This one does not boot at all. Not a single message on the screen. Is there another image I should use on my RPi3? Maybe openSUSE-Tumbleweed-ARM-JeOS-efi.aarch64-2016.10.30-Build1.1.raw.xz ? I do not need any desktop on that device, just some servers. -- fr.gr. member openSUSE Freek de Kruijf -- To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org

3 2

[opensuse-arm] First boot of Leap 42.2 aarch64 image on RPI3
by Freek de Kruijf 18 Nov '16

18 Nov '16

I tried the image openSUSE-Leap42.2-ARM-JeOS- raspberrypi3_aarch64.aarch64-2016.11.09-Build3.2.raw.xz from http://download.opensuse.org/ports/aarch64/distribution/leap/42.2/appliance… on my RPi3 and found one problem. It hangs when a USB drive is connected, otherwise it works OK. -- fr.gr. member openSUSE Freek de Kruijf -- To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org

4 10

[opensuse-arm] Leap 42.2
by Bill Merriam 16 Nov '16

16 Nov '16

Leap 42.2 has been released (yeah!) and there are repositories for armv7 and aarch64 (YEAH!). Does anybody know if they work and if so on what machines? I notice there is an appliance for aarch64 rpi3 http://download.opensuse.org/ports/aarch64/distribution/leap/42.2-Current/a… and for a general EFI aarch64 device http://download.opensuse.org/ports/aarch64/distribution/leap/42.2-Current/a… . Also interestingly there is an ISO image http://download.opensuse.org/ports/aarch64/distribution/leap/42.2-Current/i… . Perhaps this is for the Softiron server. Does it work with something else? If I have Tumbleweed running on an ARM machine can I upgrade to Leap 42.2 with any hope of success? Bill -- 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] 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

[opensuse-arm] Last known working version of Raspberry Pi 2 Tumbleweed image
by Jimmy PIERRE 03 Nov '16

03 Nov '16

Greetings, I am preparing our next Software Freedom Day and has lost track of the working image for RPi 2 / RPi 3. Won't have time to test with Leap 42.2 and SLE 12 SP2 as well, would need a "plug and play" image :) Cheers, Jimmy nui.fr -- 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] BananaPi - usb out of function
by Stefan Mack 02 Nov '16

02 Nov '16

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