- openSUSE ARM

[opensuse-arm] Beagle Board Black boot from µSD
by Roger Oberholtzer 31 May '18

31 May '18

The openSUSE info for the Beagle Board Black (https://en.opensuse.org/HCL:BeagleBone_Black) says: To boot from µSD card, you must press boot select switch button (near µSD slot) on power-on. Otherwise, you will boot from internal eMMC. Is this still the case? I am guessing that this is a board-related thing. Is there no way to get the board to boot from the µSD card automatically? I do not have a card yet. I want to explore the ARM PRU (programmable real-time unit). But booting from the µSD will be a requirement if we chose to use this card. -- Roger Oberholtzer -- To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org

4 11

[opensuse-arm] Leap 15.0: beaglebone black
by Matwey V. Kornilov 24 May '18

24 May '18

Hi, I've just booted 15.0 image on BeagleBone Black. It works as expected, surprisingly, nothing crashed yet. -- 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] armv6 tumbleweed updates?
by Michael Ströder 23 May '18

23 May '18

HI! I'm running an raspberry pi 1 with this repo: http://download.opensuse.org/ports/armv6hl/tumbleweed/repo/oss/ Last update was snapshot 20180319 but no updates since then. Anything got stuck? Ciao, Michael.

8 10

[opensuse-arm] Leap 15 for Aarch64
by Peter Czanik 23 May '18

23 May '18

Hi, When will Leap 15 for Aarch64 arrive? I am already running Leap 15 on my laptop and wanted to give it a try also on my SoftIron ARM box. But currently http://download.opensuse.org/ports/aarch64/distribution/leap/15.0/iso/ is empty... Bye, CzP -- 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] Raspberry Pi 3 question on X Virtual Desktop sizing and panning
by Steve Moring 20 May '18

20 May '18

Hi, Trying to setup the pi to work with a UHD monitor, I've been reading that it can be done, but I've got what appears to be one remaining hurdle. This works: #cvt -r 3840 2160 60 #xrandr --newmode "3840x2160" 533.00 3840 3888 3920 4000 2160 2163 2168 2222 +hsync -vsync #xrandr --addmode HDMI-1 3840x2160 This doesn't: #xrandr --output HDMI-1 --mode "3840x2160" --rate 60 --fb 4096x4096 -- panning 4096x4096 error is: xrandr: screen cannot be larger than 2048x2048 (desired size 4096x4096) How do I change the default to something larger than 2048x2048 (desired is 4096x4096)? Is there a way to change it dynamically, or do I need to do some work with xorg.conf files? I pulled the image openSUSE-Tumbleweed-ARM-X11-raspberrypi3.aarch64- 2018.04.30-Build2.4.raw.xz but it doesn't seem to matter which one I start with, they all have the 2048x2048 limit. -Steve -- 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] New Raspberry Pi 3B image in repository
by Freek de Kruijf 11 May '18

11 May '18

I am very pleased to see a new image for the Raspberry Pi 3B in repository http://download.opensuse.org/ports/aarch64/tumbleweed/images I installed the image and it works. I also noticed that /boot/grub2/grub.conf only contains one console parameter, console=ttyS1,115200n8, on the boot command line. I have a connected serial interface to the proper GIO pins and I do see the initial output of the boot process appear on the screen. Even the GRUB screen, when pressing t. However I used to see also the output of the boot process of openSUSE, which used to appear when having only this console parameter in the boot command. This output does not appear. How do I get this output and how do I get the ability to log in on this serial line? Bug report? -- 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

2 2

[opensuse-arm] Ubuntu:18.04:Ports
by Matwey V. Kornilov 07 May '18

07 May '18

Hello, Is it possible to have Ubuntu:18.04:Ports with aarch64? I am trying to make some experiments with GStreamer and RockChip SBC and I need to rebuild specific deb-packages. Everything was ok until I found that only x86_64 is available. -- To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org

2 5

RE: [opensuse-arm] Raspberry Pi 2 [updated]
by jimmypierre.rouen.france＠gmail.com 25 Apr '18

25 Apr '18

From: Jimmy PIERRE [mailto:jimmypierre.rouen.france@gmail.com] Sent: 25 April 2018 14:38 To: Alexander Graf Cc: Matthias Brugger; opensuse-arm(a)opensuse.org Subject: Re: [opensuse-arm] Raspberry Pi 2 Thanks! On Mon, 23 Apr 2018 at 21:13, Alexander Graf <agraf(a)suse.de> wrote: On 23.04.18 19:28, jimmypierre.rouen.france(a)gmail.com wrote: > > > -----Original Message----- > From: Alexander Graf [mailto:agraf@suse.de] > Sent: 23 April 2018 19:20 > To: Matthias Brugger; jimmypierre.rouen.france(a)gmail.com; opensuse-arm(a)opensuse.org > Subject: Re: [opensuse-arm] Raspberry Pi 2 > > > > On 23.04.18 18:43, Matthias Brugger wrote: >> Hi Jimmy, >> >> On 04/23/2018 06:20 PM, jimmypierre.rouen.france(a)gmail.com wrote: >>> Greetings >>> >>> In view of Linux Presentation Day April 28, I got two Raspberry Pi 3 with SUSE and would happily install openSUSE on three Raspberry Pi 2, that we own, if only there is a straight forward image ready to go. If you happen to know of a working image for RPI 2. >>> >> >> Did you tried the images here: >> https://en.opensuse.org/HCL:Raspberry_Pi2 > > I think the published images are still broken :(. > > If they don't work for you, please directly fetch the current ones from OBS: > > $ osc getbinaries openSUSE:Factory:ARM:Live JeOS:JeOS-raspberrypi2 > images armv7l > > These should hopefully work :). > > Hi guys, > > I have been downloading many images but to no avail..... > > I will give OBS a try though. > > Do you burn the image to a SD exactly as with a RAW image? Yes, the procedure is the same as described on the wiki page above, just that the image is not the published one, but the current bleeding edge image. Hi guys, I would like to share what happened next: 1. >> This has been updated - I downloaded: openSUSE-Tumbleweed-ARM-JeOS-raspberrypi2.armv7l-2018.04.17-Build2.9.raw 2. copied to a 8 GB SD 3. did zypper ref, zypper up and zypper dup 4. used yast to install XFCE, Xorg, xrdp and setup ntp 5. changed hostname 6. installed screenfetch 7. executed vncserver :1 8. remotely connected from various devices 9. can't get wifi to work at the moment, using LAN over eth0 I am quite happy that I will have 2 SUSE RPI3 and 2 RPI2 with TW and finallly 1 RPI2 with raspbian.at Linux Presentation Day next Saturday. Cheers, guys! Jimmy nui.fr tw76one:~ # screenfetch /usr/bin/screenfetch: line 1341: [: =: unary operator expected .;ldkO0000Okdl;. root@tw76one .;d00xl:^''''''^:ok00d;. OS: openSUSE .d00l' 'o00d. Kernel: armv7l Linux 4.16.3-1-lpae .d0Kd' Okxol:;,. :O0d. Uptime: 56m .OKKKK0kOKKKKKKKKKKOxo:, lKO. Packages: 1716 ,0KKKKKKKKKKKKKKKK0P^,,,^dx: ;00, Shell: bash 4.4.19 .OKKKKKKKKKKKKKKKKk'.oOPPb.'0k. cKO. CPU: 4x ARMv7 rev 5 (v7l) :KKKKKKKKKKKKKKKKK: kKx..dd lKd 'OK: GPU: dKKKKKKKKKKKOx0KKKd ^0KKKO' kKKc dKd RAM: 678MiB / 964MiB dKKKKKKKKKKKK;.;oOKx,..^..;kKKK0. dKd :KKKKKKKKKKKK0o;...^cdxxOK0O/^^' .0K: kKKKKKKKKKKKKKKK0x;,,......,;od lKk '0KKKKKKKKKKKKKKKKKKKKK00KKOo^ c00' 'kKKKOxddxkOO00000Okxoc;'' .dKk' l0Ko. .c00l' 'l0Kk:. .;xK0l' 'lkK0xl:;,,,,;:ldO0kl' '^:ldxkkkkxdl:^' tw76one:~ # -- 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] Raspberry Pi 2
by jimmypierre.rouen.france＠gmail.com 23 Apr '18

23 Apr '18

Greetings In view of Linux Presentation Day April 28, I got two Raspberry Pi 3 with SUSE and would happily install openSUSE on three Raspberry Pi 2, that we own, if only there is a straight forward image ready to go. If you happen to know of a working image for RPI 2. Thanks 👍 Jimmy nui.fr -- Sent from my iPad -- 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] Raspberry Pi 1 and 2 boot failed - Initramfs unpacking failed: write error
by Kasimir _ 17 Apr '18

17 Apr '18

Both abort the boot process with the message: "Initramfs unpacking failed: write error" Raspberry Pi 1: - Image: openSUSE-Tumbleweed-ARM-JeOS-raspberrypi.armv6l-2018.03.19-Build1.1.raw.xz - Console output: https://paste.opensuse.org/5939196 Raspberry Pi2: - Image: openSUSE-Tumbleweed-ARM-JeOS-raspberrypi2.armv7l-2018.03.19-Build1.1.raw.xz - Console output: https://paste.opensuse.org/77297849 N��r��y隊Z)z{.�櫛맲��r��z�^�ˬz��N�(�֜��^� ޭ隊Z)z{.�櫛�0��Ǩ�

5 7

[opensuse-arm] New package: python-pyOCD
by Andreas Färber 15 Apr '18

15 Apr '18

Hi, I have submitted pyOCD for inclusion in Factory: https://build.opensuse.org/request/show/596738 pyOCD is an on-chip debugger tool for Arm mbed microcontroller boards. An alternative, more generic tool we already have in Factory is OpenOCD. I recall that someone had been maintaining a python3-pyOCD package in the past, but that appears to have disappeared as a result of the new singlespec packaging approach. Regards, 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

1 0

Re: [opensuse-arm] Chromebook builds disabled?
by Guillaume Gardet 09 Apr '18

09 Apr '18

HI Daniel, Le 03/04/2018 à 19:23, Daniel Bischof a écrit : > Hi Guillaume, > > thank you for your reply. > > On Fri, 30 Mar 2018, Guillaume Gardet wrote: > >> Le 30/03/2018 à 15:58, Daniel Bischof a écrit : >>> >>> checked for changes in >>> >>> https://build.opensuse.org/package/view_file/openSUSE:Factory/u-boot-snow/u… >>> >>> yesterday, and there's an update that may fix the ongoing boot issues >>> on my Chromebook (Snow). >> >> Which boot issue? > > ok, boot issue is probably misleading. The images boot, but after "Starting kernel" the screen turns black and nothing happens. I tried to just wait, used different SD cards and checked, whether my Chromebook works with Arch Linux ARM (it does). > >>> However, the JeOS-images for Snow haven't been rebuilt for more than >>> one month: >>> >>> http://download.opensuse.org/repositories/devel:/ARM:/Factory:/Contrib:/Chr… >>> >>> Intention or mistake? >> >> The Chromebook, is now fully upstream, so please use images from: >> http://download.opensuse.org/ports/armv7hl/tumbleweed/images/ > > Very good, I didn't know that. However, the February image shows the same behaviour as described above. Tried JeOS- and X11-images today. New images are building. There is also an u-boot update (to fix chromebook boot), on the way to Tumbleweed. Then, you could try those new images. :) Guillaume -- To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org

1 0

Re: [opensuse-arm] New kiwi and firmware=custom problem
by Guillaume Gardet 04 Apr '18

04 Apr '18

Le 04/04/2018 à 10:48, Marcus Schäfer a écrit : > Hi, > >> It seems that new kiwi does not support u-boot (non EFI/Grub2) images? Is there a solution/workaround? > I have not ported plain u-boot support to the next generation kiwi, because > of the effort to move all boards to efi boot. u-boot basically works as the > EFI firmware being capable to load the grub efi module(s). Yes, but not all boards are supporting EFI with U-Boot. Especially Arndale because "Samsung's bl1 lies at sector 1, overlapping with the EFI GPT, so we can not use EFI". Maybe for other boards, we may use the EFI config in kiwi, but still boot using u-boot script? (I will give it a try) > > One of the changelog entries I have here is this: > > Date: Fri Mar 18 10:23:07 2016 +0100 > > Delete obsolete support for uboot > > arm boot is using grub2 efi images loaded by a firmware. The > firmware could be uboot but due to the non generic way to > setup the board that it loads the firmware all of these tasks > are handled by custom scripts called via the kiwi > editbootconfig / editbootinstall script hooks. Therefore kiwi > itself does not have to setup or install uboot > > iirc this was one result of a conversation with Alex some time ago, > not sure though. In our integration test example for the panda board > I can see those kind of scripts: > > https://github.com/SUSE/kiwi/tree/master/build-tests/arm/test-image-panda-o… > > If this is going to become a problem we should start a discussion > what parts are missing in the builder Alex, you may give us more information, maybe? Guillaume > > Thanks > > Regards, > Marcus -- 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] Re: New kiwi and firmware=custom problem
by Guillaume Gardet 04 Apr '18

04 Apr '18

Le 04/04/2018 à 10:35, Marcus Schäfer a écrit : > Hi, > >> openSUSE:Factory:ARM switched to new kiwi to build images. But we have >> still a number of images requiring firmware=custom option to build >> with u-boot. But this leads to the following error: > I can not remember we ever had "custom" as allowed value for the > firmware attribute. No schema in v7 nor in the next generation kiwi > supported that. I remember bootkernel="custom" added via > > - added custom bootkernel profile (bnc #846068) > > in the past. Is this what you refer to ? No. It was in the image file to replace the old firmware=vboot option. Anyway, if I remove this option (and just use spare_part option), I hit the next error because standalone U-Boot is not supported. Guillaume > > Regards, > Marcus -- 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] New kiwi and firmware=custom problem
by Guillaume Gardet 04 Apr '18

04 Apr '18

Hi Marcus, openSUSE:Factory:ARM switched to new kiwi to build images. But we have still a number of images requiring firmware=custom option to build with u-boot. But this leads to the following error: ********************************************************************** [ 45s] running kiwi system build for oem... [ 45s] cd /usr/src/packages/SOURCES && rm -rf /usr/src/packages/KIWI-oem && LANG=en_US.UTF-8 /usr/bin/kiwi --debug system build --description /usr/src/packages/SOURCES --target-dir /usr/src/packages/KIWI-oem --ignore-repos-used-for-build --add-repo dir://./repos/openSUSE:Factory:ARM/standard,rpm-md,,99 [ 47s] [ DEBUG ]: 07:30:09 | EXEC: [mkdir -p /usr/src/packages/KIWI-oem/build] [ 47s] [ INFO ]: 07:30:10 | Loading XML description [ 48s] [ DEBUG ]: 07:30:10 | EXEC: [jing /usr/lib/python3.6/site-packages/kiwi/schema/kiwi.rng /tmp/tmpcw837wx_] [ 49s] [ INFO ]: 07:30:12 | RelaxNG validation failed. See jing report: [ 49s] [ INFO ]: 07:30:12 | --> /tmp/tmpcw837wx_:10:395: error: value of attribute "firmware" is invalid; must be equal to "bios", "ec2", "efi", "ofw", "opal" or "uefi" [ 49s] [ 49s] [ ERROR ]: 07:30:12 | KiwiDescriptionInvalid: Schema validation for /usr/src/packages/SOURCES/config.xml failed ********************************************************************** Does new kiwi support firmware=custom? Otherwise, what would be the solution? Guillaume -- 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] libieee.a not being found
by Russell Standish 03 Apr '18

03 Apr '18

I'm getting the error message on ARM builds: 326s] /usr/lib64/gcc/aarch64-suse-linux/7/../../../../aarch64-suse-linux/bin/ld: cannot find -lieee See https://build.opensuse.org/package/live_build_log/home:hpcoder1/ecolab/open… libieee is part of glibc, so should always be available. The dependency is coming in through the TCL linker flags. Something is askew with the ARM build service. -- ---------------------------------------------------------------------------- Dr Russell Standish Phone 0425 253119 (mobile) Principal, High Performance Coders Visiting Senior Research Fellow hpcoder(a)hpcoders.com.au Economics, Kingston University http://www.hpcoders.com.au ---------------------------------------------------------------------------- -- 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] Chromebook builds disabled?
by Daniel Bischof 30 Mar '18

30 Mar '18

Hi, checked for changes in https://build.opensuse.org/package/view_file/openSUSE:Factory/u-boot-snow/u… yesterday, and there's an update that may fix the ongoing boot issues on my Chromebook (Snow). However, the JeOS-images for Snow haven't been rebuilt for more than one month: http://download.opensuse.org/repositories/devel:/ARM:/Factory:/Contrib:/Chr… Intention or mistake? Best regards, --D. --- Daniel Bischof <suse-bugz(a)bischof.org> -- 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] mono-core build fails for AArch64 in OBS only
by Guillaume Gardet 27 Mar '18

27 Mar '18

Hi, mono-core build fails for AArch64 in OBS due to an unhandled exception. Log: [1] Locally it builds fine with "osc build", both chroot and KVM. Any idea what could be wrong with the OBS workers? Guillaume [1]: https://build.opensuse.org/build/openSUSE:Factory:ARM/standard/aarch64/mono… -- 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] _constraints file for kiwi images?
by Guillaume Gardet 27 Mar '18

27 Mar '18

Hi, Some ARM images are failing to build because they run out of disk space. Is the _constraints file working for kiwi image builds in OBS? Guillaume -- 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] Factory ARM packages failing due to wrong rpmlint errors on licenses
by Guillaume Gardet 22 Mar '18

22 Mar '18

Hi, Currently, some packages are failing in Factory ARM (aarch64 and armv6 only, armv7 seems to be ok) because of wrong rpmlint errors on licenses such as : invalid-license (Badness: 100000) GPL-2.0-or-later I guess rpmlint used on OBS workers for aarch64 and armv6 should be updated? Guillaume -- 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] File openSUSE...Current.raw.xz.sha256 used to have filename of ...raw.xz in it
by Freek de Kruijf 21 Mar '18

21 Mar '18

I used to download files with names openSUSE...Current.raw.xz.sha256 and found in line 4 not only the sha256 sum but also the name of the image with the date and Build number followed the sha256 sum. At least for Tumbleweed-ARM-JeOS for Raspberry Pi 1 and 2 this is no longer the case. Only the sha256 sum is present. For the Raspberry Pi 3 this still is the case. Is it possible to include that name in the ...Current.raw.xz.sha256 files? -- 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

1 0

[opensuse-arm] After zypper dup to TW20180305 and reboot zypper no longer works
by Freek de Kruijf 12 Mar '18

12 Mar '18

I used image openSUSE-Tumbleweed-ARM-JeOS-raspberrypi3.aarch64-2018.02.02- Build1.2.raw.xz to build a new Raspberry Pi 3B system and performed a "zypper dup --no-recommends" to TW20180305. Even before a reboot zypper does not work anymore. It stops on a segmantation fault. The basic system seems to work OK. However using git gives a coredump of git. Also wget. However rsync, which I installed before the upgrade still works. So I downloaded strace-4.21-1.1.aarch64.rpm and used rsync to get it in the RPi3. I installed it and used "strace zypper se git" to get an strace. Did not give a clue to me about what caused the segmentation fault. Last part is: write(3, "2018-03-12 12:02:53 <1> rpi3tumh"..., 164) = 164 openat(AT_FDCWD, "/dev/null", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 4 openat(AT_FDCWD, "/var/lib/YaST2/cookies", O_RDONLY) = -1 ENOENT (No such file or directory) mmap(NULL, 8392704, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_STACK, -1, 0) = 0xffff870a6000 mprotect(0xffff870a7000, 8388608, PROT_READ|PROT_WRITE) = 0 clone(child_stack=0xffff878a3820, flags=CLONE_VM|CLONE_FS|CLONE_FILES| CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID| CLONE_CHILD_CLEARTID, parent_tidptr=0xffff878a3fe0, tls=0xffff878a4600, child_tidptr=0xffff878a3fe0) = 1045 ppoll(NULL, 0, {tv_sec=0, tv_nsec=4000000}, NULL, 0) = 0 (Timeout) ppoll(NULL, 0, {tv_sec=0, tv_nsec=8000000}, NULL, 0) = 0 (Timeout) ppoll(NULL, 0, {tv_sec=0, tv_nsec=16000000}, NULL, 0 <unfinished ...>) = ? +++ killed by SIGSEGV (core dumped) +++ Bug report: https://bugzilla.opensuse.org/show_bug.cgi?id=1084796 I do have coredumps and can produce a full strace. Please advice. -- 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

1 0

[opensuse-arm] http://download.opensuse.org/ports/aarch64/debug/tumbleweed is missing
by Andreas Schwab 11 Mar '18

11 Mar '18

... and the last published snapshot is Build20170831. This may be related. Andreas. -- Andreas Schwab, SUSE Labs, schwab(a)suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different." -- 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] rock64
by Matwey V. Kornilov 10 Mar '18

10 Mar '18

Hello, I will receive my rock64 board soon. https://www.pine64.org/?page_id=7147 I would like to run some openSUSE on it. There are no upstream support but lets see what we could do. -- To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org

8 58

[opensuse-arm] initrd.vmx bloated
by Matwey V. Kornilov 09 Mar '18

09 Mar '18

Hi, initrd.vmx is almost 100MB big in JeOS-espressobin.aarch64-2018.03.07-Build3.4 (and other images). It is almost 1GB when uncompressed and the image is not bootable due ot it. There are 500 MB of /usr/lib/locale files inside initrd. Could somebody drop them out of initrd? -- 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] JeOS-efi.aarch64-2018.03.07-Build2.1.raw: Invalid FAT entry
by Matwey V. Kornilov 07 Mar '18

07 Mar '18

Hello, I am trying to use openSUSE-Tumbleweed-ARM-JeOS-efi.aarch64-2018.03.07-Build2.1.raw to run Rock64. I use manually compiled u-boot 2018.01-rc2-02249-g19e31fac0d-dirty and see the following: => load mmc 1:1 0x02000000 efi/boot/bootaa64.efi reading efi/boot/bootaa64.efi MMC: block number 0x100008005 exceeds max(0x1dacc00) MMC: block number 0x100008005 exceeds max(0x1dacc00) Invalid FAT entry 6144 bytes read in 11 ms (544.9 KiB/s) This didn't happen when we used kiwi-7 to build JeOS at Factory. Can it be some issue with FAT16/FAT32? -- 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] Opensuse on Rock64
by Bill Merriam 28 Feb '18

28 Feb '18

I have spent many weeks getting Opensuse working on Rock64. I bought 5 of them with 4GB RAM and 32GB EMMC. They make great little computers. I thought others might like to know about this so they can work on these machines. First thing is I "cheated". I grabbed a debian stretch image from ayufan4 and went from there. https://github.com/ayufan-rock64/linux-build/releases/tag/0.5.15 That image has 7 partitions containing the crazy rockchip boot process. I think the first partition is u-boot. Partition 6 is vfat and is where u-boot looks to load the the system from. It finds extlinux/extlinux.conf for boot instructions. It loads a kernel and an initrd and tells the kernel to look for the root file system with a label of linux-root. That is partition 7, which is ext4. I wrote a tumbleweed aarch64 root file system on partition 7 and installed ayufan4's patched 4.4 kernel there. That booted up pretty well (headless) with a serial console and I continued from there with ssh. I then got opensuse's current kernel from https://github.com/openSUSE/kernel I then merged ayufan4's mainline patches from https://github.com/ayufan-rock64/linux-mainline-kernel I was AMAZED that worked since I have very little experience with git or kernel patching. There was one conflict, which was easy to fix. I concatenated ayufan's kernel config with the opensuse config (are you allowed to do that?) and make menuconfig sorted it out. I turned on support for ceph and turned off support for various things like nvidia and Plan 9. After many days of running builds I got a configuration that worked. I did all that on the rock64. I ended up using -j1 with make because the compiler would seg fault otherwise. I built a binary RPM from this to make it easy to keep track of. The kernel and initrd end up in /boot on partition 7. I had to manually copy them to partition 6 and update the extlinux.conf file to point at the new files. You can't use symbolic links in a vfat. This kernel seems to work well. Ceph didn't work because there was a relocation error loading it's module. This is a known bug in gcc. I decided to build ceph into the kernel (instead of a module) and everything works. When I had everything working from a SDHC card I copied it to the EMMC. I also installed u-boot on the SPI flash using this procedure: https://github.com/ayufan-rock64/linux-build/releases/download/0.6.22/u-boo… Once you have a image on the emmc you have to install a jumper if you want to boot from a sdhc again. I got long jumpers to make it easy to do this. I now have opensuse running on all 5 rock64's and a ceph cluster on them. I put a usb3 enclosure on each machine with a SSD and a large spinning disk. This isn't very fast but it works. ayufan4 has done great work! He solicits a beer (via paypal) if you like his work. I will have to send him a few. I think he is in southern Italy. Do Italians have pizza with their beer? 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] JeOS-efi.aarch64-2018.02.22: Failed to mount ext2 filesystem
by Matwey V. Kornilov 28 Feb '18

28 Feb '18

Hi, I am faced the issue that recent JeOS builds cannot be read by u-boot: ls mmc 1:2 / Failed to mount ext2 filesystem... ** Unrecognized filesystem type ** And then dtb files cannot be read from /boot partition. Even without dtb, EFI application cannot be read correctly here: reading efi/boot/bootaa64.efi MMC: block number 0x100008005 exceeds max(0x1dacc00) MMC: block number 0x100008005 exceeds max(0x1dacc00) Invalid FAT entry 6144 bytes read in 11 ms (544.9 KiB/s) libfdt fdt_check_header(): FDT_ERR_BADMAGIC ## Starting EFI application at 02000000 ... Unknown Relocation off ffe type f ## Application terminated, r = 9223372036854775806 EFI LOAD FAILED: continuing... -- To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org

3 9

[opensuse-arm] I can't no longer connect by ssh
by victorhck 19 Feb '18

19 Feb '18

Hello! Today I made a zypper dup in my RaspberryPi 3 with Tw and that was what I get: zypper dup Recuperando los metadatos del repositorio openSUSE-Ports-Tumbleweed-repo-oss ..................................................................................[terminado] Construyendo el caché del repositorio openSUSE-Ports-Tumbleweed-repo-oss ......................................................................................[terminado] Cargando datos del repositorio... Leyendo los paquetes instalados... Calculando actualización de distribución... El siguiente paquete NUEVO va a ser instalado: raspberrypi-firmware-config El siguiente paquete va a ser ELIMINADO: raspberrypi-firmware-config-rpi3 Los siguientes 6 paquetes van a ser actualizados: libjemalloc2 openSUSE-release openSUSE-release-ftp raspberrypi-firmware yast2-core yast2-update El siguiente producto va a ser actualizado: openSUSE Tumbleweed 20180208-0 -> 20180218-0 After finished the installation I made a reboot, and now I can't connect via ssh by wifi It was removed the firmware-config-rpi3, and installed firmware-config ¿? any clue? do you need more information? 've phun! PS: I think this is my first post in this mailing list, sorry if I'm a bit newbie... -- ------------------- GPG Key: 0xcc742e8dc9b7e22a Fingerprint = 6FE2 3B1F AAC8 E5B7 63EA 88A9 CC74 2E8D C9B7 E22A Aprende a proteger la privacidad de tu correo: https://emailselfdefense.fsf.org/es/ Mi blog sobre openSUSE, GNU/Linux y software libre: https://victorhckinthefreeworld.com/

2 2

[opensuse-arm] openSUSE-Tumbleweed ARM JeOS-efi.armv7
by Matwey V. Kornilov 17 Feb '18

17 Feb '18

Hi, I am trying to run openSUSE-Tumbleweed-ARM-JeOS-efi.armv7l-2017.10.29-Build1.7.raw using qemu. When I use qemu-system-aarch64 with 64-bit UEFI code aavmf-aarch64-code.bin then the only I see is the EFI console: UEFI Interactive Shell v2.287477C2-69C7-11D2-8E39-00A0C969723B B8F1C820 EDK IIlProtocolInterface: 752F3136-4E16-4FDC-A22A-E5F46812F4CA B8F1FF18 UEFI v2.60 (EDK II, 0x00010000)008-7F9B-4F30-87AC-60C9FEF5DA4E B8348710 Mapping table FS0: Alias(s):HD1a0b:;BLK2: VenHw(837DCA9E-E874-4D82-B29A-23FE0E23D1E2,003E000A00000000)/Scsi(0x0,0x0)/HD(1,GPT,E30D92E4-F475-4D50-9D3D-DF05DA812008,0x800,0x64004) BLK5: Alias(s): VenHw(F9B94AE2-8BA6-409B-9D56-B9B417F53CB3) BLK0: Alias(s): VenHw(8047DB4B-7E9C-4C0C-8EBC-DFBBAACACE8F) BLK1: Alias(s): VenHw(837DCA9E-E874-4D82-B29A-23FE0E23D1E2,003E000A00000000)/Scsi(0x0,0x0) BLK3: Alias(s): VenHw(837DCA9E-E874-4D82-B29A-23FE0E23D1E2,003E000A00000000)/Scsi(0x0,0x0)/HD(2,GPT,3DF8DD35-94BC-4FF0-B74C-12853D4B1811,0x65000,0x83004) BLK4: Alias(s): VenHw(837DCA9E-E874-4D82-B29A-23FE0E23D1E2,003E000A00000000)/Scsi(0x0,0x0)/HD(3,GPT,38C4AA8C-4A7F-49C4-BCFD-6C2C755496BD,0xE8800,0x3DE781) Press ESC in 1 seconds to skip startup.nsh or any other key to continue. FSOpen: Open '\startup.nsh' Success FSOpen: Open '\startup.nsh' Success FSOpen: Open '\startup.nsh' Success Shell> bootarm FSOpen: Open '\efi\boot\bootarm.EFI' Success FSOpen: Open '\efi\boot\bootarm.EFI' Success FSOpen: Open '\efi\boot\bootarm.EFI' Success FSOpen: Open '\efi\boot\bootarm.EFI' Success [Security] 3rd party image[0] can be loaded after EndOfDxe: VenHw(837DCA9E-E874-4D82-B29A-23FE0E23D1E2,003E000A00000000)/Scsi(0x0,0x0)/HD(1,GPT,E30D92E4-F475-4D50-9D3D-DF05DA812008,0x800,0x64004)/\efi\boot\bootarm.EFI. InstallProtocolInterface: 5B1B31A1-9562-11D2-8E3F-00A0C969723B B8EDE440 Unloading driver at 0x00000000000 Shell> Error Status: Unsupported (line number 1) As far as I understand, 64-bit Qemu UEFI code doesn't expect to see and run 32-bit EFI executable. When I try to use qemu-uefi-aarch32.bin as firmware, then I see the following: Initialization of device cfi.pflash01 failed: failed to read the initial flash content As far as I understand, qemu-uefi-aarch32.bin is in wrong format, but there are no other files in ovfm rpm package. What is the proper way to run JeOS-efi.armv7? Is it supposed to work in qemu? -- To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org

3 23

[opensuse-arm] Initrd.vmx too big
by Guillaume Gardet 16 Feb '18

16 Feb '18

Hi, I just tested the latest Tumbleweed image for my Beagleboard xM and the boot fails because the initrd is too big (209M uncompressed) for the RAM. I quick search shows that: * /usr/lib/python3.6/ is 36M. Do we really need python libs in initrd? * /usr/lib/sysimage/rpm is 19M. Not really useful I guess? * /usr/lib/grub2 is 27M. Guillaume -- To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org

3 12

[opensuse-arm] Change to the rebuild behavior of openSUSE:Factory:ARM
by Dirk Müller 15 Feb '18

15 Feb '18

Hi, We had a couple of issues related to getting a new build of Factory into openqa recently. This was partially caused by ARM not able to catch up with the check in frequency of x86. To some extend this was bad luck (the critial long running build job hitting the slowest / misconfigured worker taking forever to finish) and to some extend we just can't keep up I guess. Over the last few days Alex and I have reconfigured the workers to be less overcommitted and redirecting more resource intensive jobs to the better performing variants. hopefully this helps with the overall build speed and gets us to catch up. In addition, there is a rebuild counter sync endless-loop issue that isn't fully understood yet, but apparently either aarch64 or armv7l were playing ping pong rebuilds with each other. we've stabilized that by disabling armv7l build temporarily (it is reenabled now). Last but not least as an experiment we've changed the source rebuild behavior. previously, Factory:ARM was directly using the sources from Factory, so whenever there was a source change there it immediately propagated to ARM. that contributed to rarely be able to finish a ftp tree build (because that one only starts when nothing else is building, and it takes a couple of hours to complete). without a ftp tree build, new DVDs are not entering openqa. So as an experiment we've switched to frozen links. this means we're linking sources from a particular level (0201 right now) of factory, and won't get automatic updates. That seems to work fine. unfortunately the "updating link" operation crashes the build service with an error 500, so we can't update anymore, and need an admin to fix that for us. The command to update the source state to build against is this: osc api -X POST '/source/openSUSE:Factory:ARM?cmd=freezelink' It needs to be run by someone who has maintainer rights in that project. currently it crashes though. Unfortunately I'll be out for a few days (vacation), so I hope alex or Andreas can figure out together with the OBS team on how to get that issue fixed. The plan is to add that into the totest manager, so that we're only taking source changes once when we just have handed off a build to openqa. this way we might not try to do every snapshot that x86 publishes, but if we were able to finish one, we take the next one from aarch64 (potentially skipping one or two interim ones on x86). this part isn't implemented yet though, I'll look at that end of next week. TIA, Dirk -- To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org

8 7

[opensuse-arm] Leap 15
by Bill Merriam 09 Feb '18

09 Feb '18

Is there any way to test Leap 15 on aarch64? Will aarch64 be there when 15 is released? 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] Out of memory problems with AArch64 workers
by Guillaume Gardet 04 Feb '18

04 Feb '18

Hi, In my OBS JeOS branch I cannot build AArch64 images because of early "out of memory" errors. I guess there is a problem with our AArch64 workers? 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] armv6 images publish problem
by Guillaume Gardet 31 Jan '18

31 Jan '18

Hi, If you check the armv6 download area here: http://download.opensuse.org/ports/armv6hl/tumbleweed/images/ You can see that there are problems: # *-raspberrypi images are outdated whereas newer images are build ok (openSUSE-Tumbleweed-ARM-JeOS-raspberrypi.armv7l-2018.01.22-Build1.6.raw.xz has been built) # We have outdated *armv6-rootfs.armv6l* images AND newer *-armv6-rootfs.armv7l* images I think the publish script has some problem with *-raspberrypi and we should remove old rootfs images. I wanted to fill a bug but I do not know which category to use. Guillaume -- 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] Repository for openSUSE Tumbleweed architecture aach64 is not kept up-to-date
by Freek de Kruijf 30 Jan '18

30 Jan '18

I filed a bug report with this subject as: https://bugzilla.opensuse.org/show_bug.cgi?id=1077011 I am using the image for the Raspberry Pi 3, which is available via OBS and which is build using the newest packages also available in OBS. This image should be available in the regular repository, also mentioned in the wiki. Also the newest packages should be available via the repository zypper uses to upgrade Tumbleweed, which is currently not the case. Can I be of any help with this? -- 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

7 14

[opensuse-arm] Old ARM boards status
by Guillaume Gardet 26 Jan '18

26 Jan '18

Hi, I updated HCL pages on the wiki for ARM devices by removing links to images which are unavailable (12.x, 13.x, etc.) and by adding TW and 42.3 links when images are available. Two boards seem to be not supported anymore: * Efika MX : OBS 12.3 contrib project is now empty and there is no upstream support. * Highbank : OBS 12.3 contrib project is now empty. There is only u-boot-highbank package in hardware:boot. Should we remove those 2 wiki pages, or at least write that those boards are no more supported? If those boards are still supported, please tell me. Guillaume -- 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] Serial line after booting Raspberry Pi 3 with Tumbleweed does not work
by Freek de Kruijf 25 Jan '18

25 Jan '18

I did put the image: openSUSE-Tumbleweed-ARM-JeOS-raspberrypi3.aarch64-2018.01.19-Build3.3.raw.xz on a micro-SD card and booted the system with the serial line connected. I get some data on that serial line in the beginning, only after that nothing. Also a reboot shows some data, but I do not get a login prompt. I am able to connect via ssh to that system and use it. I found some information about not using /dev/ttyAMA0 because that one is used on the RPi3 for bluetooth, but /dev/ttyS0 should be used. I tried to start both with: "systemctl start getty(a)ttyAMA0.service" and "systemctl start getty(a)ttyS0.service" but the serial line does not work. How do I enable the use of the serial line. -- 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

2 1

[opensuse-arm] RPi3 Leap image links broken
by Alexander Graf 24 Jan '18

24 Jan '18

Hi Adrian, We just had an openSUSE user report on IRC that the Leap 42.3 image links for the RPi3 are broken - and they indeed are: http://download.opensuse.org/ports/aarch64/distribution/leap/42.3/appliance… This is the link we provide on the web page. If you look at the directory, you will see that there is a properly built image: openSUSE-Leap42.3-ARM-JeOS-raspberrypi3.aarch64-2017.07.26-Build1.1.raw.xz but with full name indicating the build date. We usually have short links for those to allow links from the outside world. IIUC they get created in the publishing step, right? Funnily enough, we do have short links for "tbz" targets, but our "raw.xz" ones are all missing them. Alex -- To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org

3 7

[opensuse-arm] Tumbleweed image for Raspberry Pi 2 contains a corrupt ext4 partition after first boot
by Freek de Kruijf 13 Jan '18

13 Jan '18

I used two images from repository: http://download.opensuse.org/ports/aarch64/tumbleweed/images/ namely: openSUSE-Tumbleweed-ARM-JeOS-raspberrypi2.armv7l-2017.12.14-Build1.9.raw.xz openSUSE-Tumbleweed-ARM-JeOS-raspberrypi2.armv7l-2017.12.14-Build1.10.raw.xz The first one comes up properly. However "fdisk -l /dev/mmcblk0" shows: Disk /dev/mmcblk0: 7,5 GiB, 8068792320 bytes, 15759360 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 Disklabel type: gpt Disk identifier: FDA566EC-2187-40A0-8357-DCB2E5B6F63D Device Start End Sectors Size Type /dev/mmcblk0p1 2048 411651 409604 200M Linux filesystem /dev/mmcblk0p2 413696 839683 425988 208M Linux filesystem /dev/mmcblk0p3 841728 14747670 13905943 6,6G Linux filesystem /dev/mmcblk0p4 14749696 15759326 1009631 493M Linux filesystem Strangely, "lsblk" shows: NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT mmcblk0 179:0 0 14,9G 0 disk ├─mmcblk0p1 179:1 0 200M 0 part /boot/efi ├─mmcblk0p2 179:2 0 14,2G 0 part / └─mmcblk0p3 179:3 0 485,7M 0 part [SWAP] While "parted -l" shows this: Model: SD 00000 (sd/mmc) Disk /dev/mmcblk0: 16,0GB Sector size (logical/physical): 512B/512B Partition Table: gpt Disk Flags: Number Start End Size File system Name Flags 1 1049kB 211MB 210MB fat16 vcboot 2 212MB 413MB 201MB ext4 lxboot legacy_boot 3 414MB 15,5GB 15,1GB lxroot 4 15,5GB 16,0GB 516MB linux-swap(v1) lxswap After the first boot the system behaves as if it has only three partitions, so like lsblk shows. However a reboot of this system shows an error message from script /boot/boot.scr about accessing something outside limits, I assume outside the second partition, and starts to try to boot from the network. The second image shows in the first boot lots of errors trying to start services. A reboot shows the same behavior as the first image. It looks like these images are not properly formatting the micro-SD card, and leave a corrupt ext4 partion on this card. I filed a bug report about this: https://bugzilla.opensuse.org/show_bug.cgi?id=1075094 -- 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 8

[opensuse-arm] Fail with openSUSE JeOS pine 64 image
by Paul Gonin 08 Jan '18

08 Jan '18

Hi, I tried today the pine64 JeOS ipage on pine64 board with 2GB RAM Connected on ethernet (with dhcp server) Collected boot output with serial access on EXP port http://paste.opensuse.org/54338867 It seems to be failing with error (and keeps rebooting to same error status) echo -e '[1512344931.067261] Failed to find boot device !' Not sure what I can do from there... options seem limited. Thanks Paul -- To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org

5 9

[opensuse-arm] RaspberryPi 3 and wifi
by Hartmut Krummrei 03 Jan '18

03 Jan '18

Hello, I managed to get Opensuse 42.3 running on my Raspi 3. That took my just one day. After another day with the effortless tries to get the built-in-wifi runnung I am at end. Was anyone able to get the wifi-device working? What did I try: evrywhere is written, that you have to edit the raspberry-file in /etc/dracut.d/, but I have no such file. So what do I edit? I tried to manage the listed modules by hand, but if I remove sdhc_ipc the system freezes. Every package named "raspberry pi" is installed (for pi 3) and bcmxxx too. Other seems to have difficulties too: https://lists.opensuse.org/opensuse-arm/2017-08/msg00028.html Regards, Hartmut -- ------------------------------------------------------------------------ "Ich habe keine besondere Begabung, sondern bin nur leidenschaftlich neugierig." (Einstein) spielmops.org <http://spielmops.org> -- 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] How to use gpio pins via sysfs
by Frank Kunz 02 Jan '18

02 Jan '18

I try to control a few gpio pins via bash script. Board and OS version is: cat /proc/device-tree/compatible olimex,a13-olinuxinoallwinner,sun5i-a13 cat /etc/os-release NAME="openSUSE Leap" VERSION="42.3" ID=opensuse ID_LIKE="suse" VERSION_ID="42.3" PRETTY_NAME="openSUSE Leap 42.3" ANSI_COLOR="0;32" CPE_NAME="cpe:/o:opensuse:leap:42.3" BUG_REPORT_URL="https://bugs.opensuse.org" HOME_URL="https://www.opensuse.org/" In /sys/class/gpio I do: echo 3 > export ls export gpio3 gpiochip0 unexport ls gpio3/ active_low device/ direction power/ subsystem/ uevent value cat gpio3/direction in So when I want to change the pin direction: echo out > gpio3/direction bash: echo: write error: Unknown error 517 That is EPROBE_DEFER. The kernel signals that the requested device might be probed later, ...or never. I guess that there might be some device tree item missing, but from the kernel documentation I haven't found a solution for that. Does anybody have an idea how to get that working? Br, Frank -- 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] RPi 3 video requires CMA memory which is not automatically configures
by Michal Suchánek 01 Jan '18

01 Jan '18

Hello, for testing I installed stable and master kernel on Leap 42.3 E20 image. Initially it would work fine but later I would have to add cma=256MB (some random value found on a forum) to kernel commandline for video output to work. Has the cma requirement changed as a result of recent vc4 changes? Can the kernel allocate the required size automatically? The vc4 has probably some configuration in devicetree. As I understand it the devicetree is taken from some place other than the kernel. Is this devicetree ever updated after copying the image to the SD card? Thanks Michal -- To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org

4 6

[opensuse-arm] Packet fake-hwclock generated
by Freek de Kruijf 18 Dec '17

18 Dec '17

In Raspbian I noticed a packet always included in the image called fake- hwclock. I used the tar.gz file together with a .spec file to generate this packet for openSUSE distributions for systems without a Real Time Clock. The description is: Some machines don't have a working realtime clock (RTC) unit, or no driver for the hardware that does exist. fake-hwclock is a simple set of scripts to save the kernel's current clock periodically (including at shutdown) and restore it at boot so that the system clock keeps at least close to realtime. This will stop some of the problems that may be caused by a system believing it has travelled in time back to 1970, such as needing to perform file system checks at every boot. On top of this, use of NTP is still recommended to deal with the fake clock "drifting" while the hardware is halted or rebooting. Hope this is accepted to be included. -- 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

6 18

[opensuse-arm] No DMA on Raspberry Pi 3B using latest image
by Freek de Kruijf 15 Dec '17

15 Dec '17

I used repository: http://download.opensuse.org/repositories/devel:/ARM:/Factory:/Contrib:/ RaspberryPi3/images and downloaded the image: openSUSE-Tumbleweed-ARM-JeOS-raspberrypi3.aarch64-2017.12.04-Build4.5.raw.xz to start some testing. Earlier I used Build4.4 and upgraded from kernel- default-4.4.103 to 4.14.1, which resulted in regular messages about buffer full using DMA. So in the current test I left the kernel to 4.4.103. However journalctl -b shows the following error message: okt 26 14:29:18 rpi3tumhon kernel: mmc0: unable to initialise DMA channels. Falling back to PIO okt 26 14:29:18 rpi3tumhon kernel: mmc0: loaded - DMA disabled Should I enter a bug report? -- 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

6 11

[opensuse-arm] Problem with RPi2 image
by Freek de Kruijf 13 Dec '17

13 Dec '17

Using from repository: http://download.opensuse.org/ports/armv7hl/tumbleweed/images and image: openSUSE-Tumbleweed-ARM-JeOS-raspberrypi2.armv7l-2017.12.04-Build2.4.raw.xz sha256 check is OK, I can boot this image OK, however a reboot fails after having changed, via ssh, just minor things. Inspection of the microSD card using parted shows: Model: Generic STORAGE DEVICE (scsi) Disk /dev/sdg: 8069MB Sector size (logical/physical): 512B/512B Partition Table: gpt Disk Flags: Number Start End Size File system Name Flags 1 1049kB 211MB 210MB fat16 vcboot 2 212MB 430MB 218MB ext4 lxboot legacy_boot 3 431MB 7551MB 7120MB lxroot 4 7552MB 8069MB 517MB linux-swap(v1) lxswap It looks like partition 3 above should not be there and should be part of 2. -- 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

1 1

[opensuse-arm] Raspberry Pi 3 interrupt handling
by Roger Oberholtzer 13 Dec '17

13 Dec '17

We have written a minimal kernel interrupt handler for the Raspberry Pi 3. It is running the current 64-bit Tumbleweed kernel. I am curious about the rate of interrupts that we might be able to capture. The ISR does little other than run when a raising edge interrupt happens. We are looking at /proc/interrupts to see how many interrupts have happened. We see that at around 23 kHz we begin to loose interrupts. The system is not doing anything else. Does that seem reasonable? I have not seen any good discussion of this. I think it is rather low. I am guessing that the issue is how the Linux kernel responds to interrupts. The housework in setting things up so that the interrupt can run must be the resource hog. Opinions? Suggestions? -- Roger Oberholtzer -- 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] [aarch64] TW on Pinebook?
by Alex Naumov 12 Dec '17

12 Dec '17

Hello, yesterday I finally got my 14'' Pinebook [1]. There is Ubuntu 16.04 MATE as a default OS, but I would like to use openSUSE TW on it of course. So, I found raw.xz XFCE-image for aarch64 [2] and used this command "to burn" image on the microSD card: # unxz -c openSUSE-Tumbleweed-ARM-XFCE-efi.aarch64-2017.06.10-Build2.3.raw.xz | sudo dd of=/dev/mmcblk1p No success. Pinebook tried to boot from microSD card, but... it seems that there is something wrong with bootloader. Here [3] I found this command: # xzcat openSUSE-Tumbleweed-ARM-XFCE-efi.aarch64-2017.06.10-Build2.3.raw.xz | dd bs=4M of=/dev/ mmcblk1p oflag=sync Exactly the same... image is there, echo $? tells 0, but pinebook ignore it. Image on microSD card is marked as a bootable. I checked it with parted(8). I asked Google and it showed me this [4]. This is HOWTO for fedora 21 on Cubietruck, but there is one interesting thing: step (4) Write U-Boot to Media. Do we also need to install bootloader extra? Because, as I said, for me it seems like a bootloader problem. If yes, where is this script or documentation about it? Also I would ask about rootfs-images. Do we have some information/HOWTOs about these? Cheers, Alex [1] https://www.pine64.org/?page_id=3707 [2] http://download.opensuse.org/ports/aarch64/tumbleweed/images/openSUSE-Tumbl… [3] https://en.opensuse.org/HCL:AArch64_EFI [4] https://kashyapc.fedorapeople.org/arm/installing-Fedora-21-on-microSD-card-… -- To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org

5 7

[opensuse-arm] Raspberry Pi3 fail to boot
by Manu Maier 11 Dec '17

11 Dec '17

Hello, the last Tumbleweed image[1] of Raspberry Pi 3 fails to boot with the message: [ 5.646965] Initramfs unpacking failed: write error [ 5.901972] Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000007 [ 5.901972] [ 5.911609] CPU: 2 PID: 1 Comm: init Not tainted 4.14.4-1-default #1 [ 5.918290] Hardware name: raspberrypi rpi/rpi, BIOS 2017.11 11/16/2017 [ 5.925244] Call trace: [ 5.927832] [<ffff000008089ea8>] dump_backtrace+0x0/0x248 [ 5.933514] [<ffff00000808a114>] show_stack+0x24/0x30 [ 5.938833] [<ffff0000089192d4>] dump_stack+0x9c/0xc0 [ 5.944149] [<ffff0000080ce688>] panic+0x12c/0x2ac [ 5.949193] [<ffff0000080d3b04>] do_exit+0x99c/0x9a0 [ 5.954417] [<ffff0000080d3b98>] do_group_exit+0x40/0xb0 [ 5.960008] [<ffff0000080e021c>] get_signal+0x2dc/0x548 [ 5.965505] [<ffff000008089178>] do_signal+0x70/0x3f0 [ 5.970820] [<ffff000008089770>] do_notify_resume+0xd0/0x120 [ 5.976772] Exception stack(0xffff00000802bec0 to 0xffff00000802c000) [ 5.983547] bec0: 0000ffffaa00b688 0000000000000000 0000000000000978 0000ffffaa00b680 [ 5.991781] bee0: 0000ffffaa00c000 0000ffffaa00b688 0000000000000003 756e696c65736269 [ 6.000016] bf00: 00000000000000de 0000fffff5ec40e0 0000000000042a98 000000000002f000 [ 6.008251] bf20: 0000fffff5ec40e0 0000000000040688 0000ffffaa2908f8 0000000000000887 [ 6.016484] bf40: 0000ffffaa290f88 0000ffffaa276c18 0000000000000001 0000000000000000 [ 6.024718] bf60: 0000000000000004 0000ffffaa290000 0000000000000000 0000000000000002 [ 6.032952] bf80: 0000ffffaa28cc20 0000fffff5ec40b0 0000fffff5ec4490 0000fffff5ec44d0 [ 6.041186] bfa0: 0000000000000002 0000fffff5ec4240 0000ffffaa26679c 0000fffff5ec4080 [ 6.049421] bfc0: 0000ffffaa27924c 0000000020000000 0000ffffaa00a000 00000000ffffffff [ 6.057655] bfe0: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 [ 6.065890] [<ffff0000080836c0>] work_pending+0x8/0x10 [ 6.071299] SMP: stopping secondary CPUs [ 6.075431] Kernel Offset: disabled [ 6.079100] CPU features: 0x002004 [ 6.082675] Memory Limit: none [ 6.085893] Rebooting in 90 seconds.. [1] openSUSE-Tumbleweed-ARM-JeOS-raspberrypi3.aarch64-2017.12.04-Build2.8.raw.xz Regards, Manu

3 3