September 2016 - openSUSE ARM - openSUSE Mailing Lists

Re: [opensuse-arm] Raspberry Pi 3 images broken (was: ARM images broken!)
by Jogchum Reitsma 23 Sep '16

23 Sep '16

Hi, New to this list (and to the set of Raspberry Pi-owners), I have the same problem on my Raspberry Pi3 Freek de Kruijff describes in his post of 12 September in this thread: when booting it hangs on "stub: Exiting boot services and installing virtual address map..." I am using the newest JeOS-image (ARM-JeOS-raspberrypi3_aarch64.aarch64-2016.09.19-Build6.1.raw.xz, from 22/09). I'm not sure I understand the solution he described in the same post, maybe because I don't know where to find a proper firmware that works - could it be possible to give me a hint here? I suppose this is a bug in the image that is still worked on? 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 3

[opensuse-arm] openSUSE AArch64, 64k vs 4k PAGE_SIZE
by Alexander Graf 19 Sep '16

19 Sep '16

Hello fellow openSUSE ARM developers, As you might have realized, we haven’t published openSUSE Tumbleweed in quite some time. The biggest reason for that (among minor hickups) is that we’re using btrfs on 64k PAGE_SIZE, which started to have massive disk space requirements (1GB of data doesn’t fit in an 8GB partition). We also in between benchmarked 64k vs 4k intensively and concluded that 4k PAGE_SIZE is the much better option, so we’re at 4k with the Leap 42.2 backing kernel tree. However, because we have people who have Leap 42.1 and current Tumbleweed installed, we can’t just switch from 64k to 4k PAGE_SIZE, because our friend btrfs embeds the page size into its on-disk format and can only read it when they’re identical. So switching would break existing btrfs installations. There hasn’t been any well working solution to make btrfs more compatible, we don’t really want 42.2 to diverge from its origins and 4k gets us running on smaller systems which are starting to pop up more and more in the 64bit world. Given all that, is anyone seriously opposed to switching everything to 4k? We could have a patch like the one below in the kernel pre-install script, preventing people from breaking their systems, add notes on the wiki, maybe ask SoftIron to send emails to people who bought systems with Tumbleweed/42.1 preinstalled and then close that horrible chapter forever. Keep in mind that non-btrfs and 32bit installations are completely untouched by any of this. I’m sure we would lose one or two users, but I’d rather have that than spend more time not publishing images and keeping us from doing a future-looking 42.2 release which would drive us into a corner that makes us lose even more. For reference, there’s a bugzilla about this atm as well: http://bugzilla.opensuse.org/show_bug.cgi?id=998663 Alex diff --git a/rpm/pre.sh b/rpm/pre.sh index f02d9c0..347b0d4 100644 --- a/rpm/pre.sh +++ b/rpm/pre.sh @@ -19,3 +19,22 @@ if [ @BASE_PACKAGE@ = 1 -a "$YAST_IS_RUNNING" != "" ]; then fi fi fi + +# On AArch64 we switched from 64k PAGE_SIZE to 4k PAGE_SIZE. Unfortunately +# btrfs can only use file systems created with the same PAGE_SIZE. So we +# check if the user has any btrfs file systems mounted and refuse to install +# in that case. +if [ $( uname -m ) = aarch64 -a "$( zgrep CONFIG_ARM64_64K_PAGES=y /proc/config.gz )" ]; then + if cut -d ' ' -f 3 /proc/mounts | grep -q btrfs; then + echo "You are using btrfs on a 64kb PAGE_SIZE kernel. This" >&2 + echo "kernel switched to 4kb PAGE_SIZE which will prevent" >&2 + echo "it from mounting that file system." >&2 + echo >&2 + echo "Refusing from installing this kernel, to make sure you" >&2 + echo "do not end up with an unusable system. If you want to" >&2 + echo "install it, please convert the btrfs file system to a" >&2 + echo "different file system." >&2 + + exit 1 + fi +fi-- To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org

5 11

[opensuse-arm] 4.8-rc4 kernel testing
by Andreas Färber 19 Sep '16

19 Sep '16

Hello, The master branch kernel configs have all been updated to 4.8-rc4. As reported on opensuse-kernel, the dtb packages did not get rebuilt in Kernel:HEAD, so I tested with my own branch. == armv6hl == === Raspberry Pi === * 4.8.0-rc4-2.gb12c2a7-default oopses in arm_pmu_device_probe! * 4.7.2-1-default boots with dtb-bcm2835 4.8.rc4 == armv7hl == armv7l kernels failed to build! (OOM errors) === Cubietruck === * 4.7.0-1-lpae boots with dtb-sun7i 4.8.rc4 === Raspberry Pi 2 === * 4.7.0-1-default boots with dtb-bcm2836 4.8.rc4 (USB broken) == arm64 == === Raspberry Pi 3 === * 4.8.0-rc4-2.gb12c2a7-default boots, but USB broken like on Pi 2 * 4.4.19-7-default (contrib) boots with dtb-broadcom 4.8.rc4 * brcmfmac driver is missing => patch queued 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

2 3

Re: [opensuse-arm] openSUSE AArch64, 64k vs 4k PAGE_SIZE
by Alexander Graf 16 Sep '16

16 Sep '16

> On 16 Sep 2016, at 07:51, Takashi Iwai <tiwai(a)suse.de> wrote: > > On Fri, 16 Sep 2016 00:25:42 +0200, > Alexander Graf wrote: >> >> >>>> [...] How many "customers" does Leap 42.1 aarch64 have? I thought >>>> it's a tech preview, experiment, unsupported port, whatever? [...] >>> >>> If someone opts for a stable release then I'd think that choice is made >>> on the reasonable assumption or "promise" that they can upgrade to the >>> next stable release either when the new one gets released or before the >>> old one goes out of updates. That has exactly nothing to do with whether >>> it's a main architecture or a port. >>> >>> Also note that there were aarch64 13.1 and 13.2 before 42.1 already. >>> >>>>>> We could have a patch like the one below in the kernel pre-install script, preventing people from breaking their systems, add notes on the wiki, maybe ask SoftIron to send emails to people who bought systems with Tumbleweed/42.1 preinstalled and then close that horrible chapter forever. >>>>> >>>>> Note that your patch does not address the 42.2 installer, whose kernel >>>>> and initrd to not get installed by rpm. >>>> >>>> It does, because the 42.2 installer wouldn’t be able to mount the btrfs volume. >>> >>> That's not addressing anything, that's the status quo. If we decide that >> >> Yes, but at least that means that even without any effort or code changes, users won’t break their systems by upgrading via the iso path, so it’s not as bad as could be. >> >>> btrfs upgrade will be unsupported (as opposed to just not taking any >>> decision as before) then the installer would need to detect the mismatch >>> and inform the user in a meaningful way why it's not possible and what >>> they should do instead - cancel the installation, reboot into the >>> previous system, back up the data and do a clean installation. Not just >>> leave the user silently without an upgrade option. >> >> I agree that that would be the better option, but we would need to write the code for that and push it into the installer ;). Or we just document it on the wiki, be vocal about it and hope that not too many people run into it. > > Another option would be to provide a driver update disk (DUD) > containing btrfs-64k-kmp or create a new ISO containing the KMP. > Besides that, you'd have to install btrfs kmp as well in the updated > system, and this means that we still need some other changes in the > installer side, too (or maybe hacking in kiso?) > > However, the biggest concern is the quality and the maintenance of > btrfs-64k-kmp. We'd have to maintain it as long as 42.2 is alive, and > this is a significant burden. So, I don't think it's a good way to > go. I suggested just as a discussion material. Yes, the more people actually look at the patches the more I get the feeling that it’s not a supportable path ;). > > >>>>> Any other userspace packages that may require a rebuild if changed? >>>> >>>> Nope. >>> >>> Is that an assumption or did you really check? :) In particular does >>> this affect the installed headers (glibc-linux-devel?), or just anything >>> that requires kernel-source directly? >> >> All user space applications *should* work unchanged. If they don’t, it’s a clear bug - but I am not aware of any atm. The kernel headers are all page size agnostic. > > Well, at least there is one bug in Qt5 QML where it crashes with 48bit > VA (boo#989341). But the fix patches are floating around upstream, so > we may give it a try. Not going 48 bits again diverges from the parent code base, so I don’t think it’s a smart move. Worst case, it would bite us again in package hub. Alex -- 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] Location of latest images
by Alessio Adamo 15 Sep '16

15 Sep '16

Hi Andreas, I tried the image "openSUSE-Tumbleweed-ARM-JeOS-cuboxi.armv7l-2016.09.11-Build1.1.raw.xz" and I get the following errors at boot: [ 9.532713] imx-gpc 20dc000.gpc: failed to get pu regulator: -517 [ 9.552823] imx-gpc 20dc000.gpc: failed to get pu regulator: -517 [ 9.577379] imx-gpc 20dc000.gpc: failed to get pu regulator: -517 [ 9.672825] imx-gpc 20dc000.gpc: failed to get pu regulator: -517 [ 9.834491] etnaviv-gpu 2204000.gpu: hw init failed: -6 [ 10.216881] systemd-udevd[290]: ctx=0x7fb94090 path=/lib/modules/4.7.2-2-default/kernel/drivers/net/wireless/broadcom/brcm80211/brcmutil/brcmutil.ko error=No such file or directory [ 10.218228] systemd-udevd[289]: ctx=0x7fb94090 path=/lib/modules/4.7.2-2-default/kernel/drivers/net/wireless/broadcom/brcm80211/brcmutil/brcmutil.ko error=No such file or directory So I guess it is unrelated to the uboot issue. Is there anything else I can provide you to debug it? Regards, Alessio -- 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] ARM images broken!
by Guillaume Gardet 14 Sep '16

14 Sep '16

Hi, I noticed that latest ARM images running u-boot (e.g. JeOS-beagle) are broken because: * Mke2fs now creates file systems with the metadata_csum and 64bit features enabled by default See: https://build.opensuse.org/package/view_file/openSUSE:Factory/e2fsprogs/e2f… * But u-boot does not support it: See: http://lists.denx.de/pipermail/u-boot/2016-July/261417.html What would be the easiest way to tell kiwi to not use those features? Guillaume -- To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org

8 20

[opensuse-arm] Location of latest images
by Alessio Adamo 12 Sep '16

12 Sep '16

Hello everybody, I'm a happy possessor of a Cubox-i 4Pro (based on i.MX6) used as a server with JeOS. For many months the Tumbleweed images from time to time available at http://download.opensuse.org/ports/armv7hl/tumbleweed/images/ had been broken and the latest has not been updated since June. Where can I find a new version? Thank you Alessio -- 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] No update of ARM64 Tumbleweed?
by LOIC DEVULDER 08 Sep '16

08 Sep '16

Hello all! I have a ARM64 server installed with Tumbleweed but there’s no update since june  The repository at http://download.opensuse.org/ports/aarch64/factory/repo/oss/ seems untouched since the 3rd june! Is someone know why? Should I use Leap 42.2 beta instead? Regards, Loic

3 4

[opensuse-arm] New package: bcm43xx-firmware
by Andreas Färber 06 Sep '16

06 Sep '16

Hello, I have submitted a new package bcm43xx-firmware for inclusion in Tumbleweed (and later Leap 42.2), containing two things: 1) Redistributable BCM43430 Wifi+Bluetooth firmware files 2) NVRAM config files for BCM43430 and BCM43362 The former will hopefully at some point go into kernel-firmware package via linux-firmware.git (open GitHub ticket for Raspberry Pi Foundation) and could then be dropped from this package. However, both pcie and sdio variants of brcmfmac driver use a single per-chipset .txt file for initialization that will not go into linux-firmware.git because it doesn't depend on just the chipset but on the "wiring" of the module or board. We therefore may have multiple configs for the same chipset, as demonstrated for bcm43362, and need to determine at installation time which file to use. For Kiwi images - where we cannot detect this during %post - the idea is to not provide a potentially wrong config file by default and instead add a symlink manually from a Kiwi hook script. https://build.opensuse.org/request/show/424758 Note: Please do not add additional firmware files to this package without obtaining confirmation that they are in fact redistributable! For non-redistributable firmware see pullin-bcm43xx-firmware package. A corresponding arm64 kernel config patch to enable brcmfmac on master branch is pending; on openSUSE-42.2 branch it is already enabled and on stable branch it's not needed. 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

2 1

[opensuse-arm] RFC: u-boot in Leap 42.2
by Andreas Färber 05 Sep '16

05 Sep '16

Hello, Forwarding a raspberrypi-firmware SR to 42.2, I noticed that its u-boot is still at version 2015.10-rc3 [1]. Apparently it is the same version as in 42.1 [2] and therefore has no u-boot-rpi3 subpackage yet. Can I update u-boot to the latest Factory version (2016.07)? I.e., was this package forgotten about in absence of JeOS images, or is there a reason it needs to remain at this odd version? Thanks, Andreas [1] https://build.opensuse.org/package/show/openSUSE:Leap:42.2/u-boot [2] https://build.opensuse.org/package/view_file/openSUSE:Leap:42.2/00Meta/look… -- 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