openSUSE ARM November 2017

arm@lists.opensuse.org

16 participants
15 discussions

[opensuse-arm] http://download.opensuse.org/ports/aarch64/debug/tumbleweed is missing

by Andreas Schwab

... 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 years, 1 month

[opensuse-arm] rock64

by Matwey V. Kornilov

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

3 years, 1 month

[opensuse-arm] openSUSE-Tumbleweed ARM JeOS-efi.armv7

by Matwey V. Kornilov

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 years, 2 months

[opensuse-arm] Raspberry Pi 3 interrupt handling

by Roger Oberholtzer

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

3 years, 4 months

[opensuse-arm] [aarch64] TW on Pinebook?

by Alex Naumov

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

3 years, 4 months

[opensuse-arm] Re: [opensuse-factory] New Tumbleweed snapshot 20171120 released!

by Andreas Färber

Hi Daniel, Let's move the discussion to opensuse-arm list. Am 23.11.2017 um 12:07 schrieb Daniel Molkentin: > On 11/22/2017 06:31 PM, Andreas Färber wrote: >> Am 22.11.2017 um 04:25 schrieb Dominique Leuenberger: >>> ==== kernel-source ==== >>> Version update (4.13.12 -> 4.14.0) >>> Subpackages: kernel-default kernel-default-devel kernel-devel kernel-docs kernel-macros kernel-syms >>> >>> - Update to 4.14-final. >> On the aarch64 based Pine64 board it has been observed that the updated >> dtb-allwinner package now requires the axp20x-regulator module in the >> initrd for using the MMC driver, and its parent module axp20x-rsb does >> not get loaded automatically even if added to the initrd. > I would prefer if that would be fixed in the kernel by adding the proper > dependencies. > Is there any chance for that? There's multiple issues at play here: 1) This is not a module compile-time dependency issue, but rather a run-time dependency issue, which AFAIU dracut is not resolving today. As a result the JeOS images in openSUSE:Factory:ARM etc. contain a number of add_drivers entries to load such extra modules: https://build.opensuse.org/package/view_file/openSUSE:Factory:ARM/JeOS/conf… That is of course ugly and would be nice to get resolved differently. Dracut would need to parse the Device Tree in /sys/firmware/ to discover what regulator, clock, power domain, etc. nodes are being referenced, then read their "compatible" strings and resolve them to the modules to add. The kernel uses generic API calls such as clk_get() and regulator_get(), thus no compile-time dependency for e.g. mmc modules. However when updating from 4.13 to 4.14 or from 4.14-rc4 to -rc8 it would've still read the current Device Tree and not discovered this new dependency for next boot. And Kiwi images get built in KVM, which will have a different Device Tree than the user's system or even ACPI. So I don't see a full solution yet. Let me know if I should report this somewhere upstream - it didn't seem a distro-specific issue for our Bugzilla. https://www.kernel.org/pub/linux/utils/boot/dracut/dracut.html#_troubleshoo… explains what info to include in a bug report, but not actually where to file it. ;) No link on dracut.wiki.kernel.org either. 2) axp20x-rsb driver does have MODULE_DEVICE_TABLE(of, ...), so it is unclear to me why the DT -> module resolution for auto-loading is not working here. https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/dri… It is almost certainly an upstream kernel issue, possibly in sunxi-rsb bus driver. Stefan has already reported this on #linux-sunxi. > Otherwise, the "proper" dracut patch would > looks something like the attached one. Hm, instmod is just the equivalent of "add_drivers", is it? That would not be enough here. Also not all ARM systems need this driver, it's an extra chip on some boards only. What you could do is more generally add all =drivers/mfd drivers. But if we keep adding drivers by category instead of addressing the underlying discovery issue, we risk at some point the initrd getting too large for low-RAM systems. 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

3 years, 5 months

Re: [opensuse-arm] Re: EspressoBin

by Matwey V. Kornilov

2017-10-22 9:31 GMT+03:00 Rick Ashford <Rick.Ashford(a)suse.com>: > There is a great thread on the Armbian forum about the EspressoBin, and it > helped me get things up and running with Tumbleweed. > > One of the guys there has a public Dropbox link that includes their images > for flashing the u-boot loader: > https://www.dropbox.com/sh/kmgmo1uubhcczx5/AAAYEvTIFxpBr0dHG2QcapTza?dl=0 > > The thread: > https://forum.armbian.com/index.php?/topic/4089-espressobin-support-develop… > > With their boot loader I was able to finally use BTRFS images as well as PXE > boot. It also has an EFI load function in the help that I need to get around > to trying. Well, If armian u-boot is able to boot our standard EFI-Grub JeOS, then we can recommend to use it with openSUSE and don't reinvent the wheel. > > Rick Ashford > Sales Engineering Manager - West > SUSE Linux > rick.ashford(a)suse.com > Office: 512-782-4318 > Mobile: 512-731-3035 > > On Oct 21, 2017, at 12:32 PM, Matwey V. Kornilov <matwey.kornilov(a)gmail.com> > wrote: > > 2017-10-21 19:47 GMT+03:00 Matwey V. Kornilov <matwey.kornilov(a)gmail.com>: > > 2017-10-21 19:35 GMT+03:00 Matwey V. Kornilov <matwey.kornilov(a)gmail.com>: > > 2017-10-20 18:02 GMT+03:00 Matwey V. Kornilov <matwey.kornilov(a)gmail.com>: > > 2017-10-20 17:37 GMT+03:00 Alexander Graf <agraf(a)suse.de>: > > > > On 20.10.17 16:21, Matwey V. Kornilov wrote: > > 20.10.2017 17:12, Alexander Graf пишет: > > > > On 20.10.17 13:57, Matwey V. Kornilov wrote: > > Hi, > > > I've just received EspressoBin 1G. Any success stories how to run openSUSE? > > > > I think you'll basically have to somehow flash a working U-Boot with > > distro boot onto it and then just dd the tumbleweed/42.3 iso onto a usb > > stick and cross your fingers that gets you to a point where you can > > install :) > > > It has microsd card, I think it should be able to boot from sd, no? > > I also need to to find serial console pins on the board :) > > > There seems to be a lengthy discussion on the mailing list. I guess you > > can select the boot device using DIP switches though? > > > Yes, I can. I think it is preferred way. Need to find expected layout > > to place u-boot image. > > > Well, at least while booting from SATA, they say that BootRom looks > > for code starting with zero offset, which implies that there can not > > be any GPT partition table. > > Probably, it is similar for SD. If so, we need to flash our EFI-aware > > u-boot instead of upstream one. > > > > Well, SATA flash image from here > > > http://wiki.espressobin.net/tiki-index.php?page=Boot+ESPRESSObin+from+SATA+… > > > suits for booting from microsd card, when it is flushed from zero > > offset and boot selection switchs are set to 7. > > > At least, there is non-destructive way to check out u-boot image. > > > Double checked. Seems that microsd boot doesn't work and is not > supported. At least for my V5 board. > It just falls back to SPINOR > > > > > http://espressobin.net/forums/topic/how-to-flash-u-boot/ > > > > Alex > > > > > -- > > With best regards, > > Matwey V. Kornilov > > > > > -- > > With best regards, > > Matwey V. Kornilov > > > > > -- > > With best regards, > > Matwey V. Kornilov > > > > > -- > With best regards, > Matwey V. Kornilov > -- > To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org > To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org > > -- With best regards, Matwey V. Kornilov -- To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org

3 years, 5 months

[opensuse-arm] Re: [opensuse-factory] New Tumbleweed snapshot 20171120 released!

by Andreas Färber

Am 22.11.2017 um 04:25 schrieb Dominique Leuenberger: > ==== kernel-source ==== > Version update (4.13.12 -> 4.14.0) > Subpackages: kernel-default kernel-default-devel kernel-devel kernel-docs kernel-macros kernel-syms > > - Update to 4.14-final. > - commit c152297 > - rpm/kernel-binary.spec.in: rename kGraft to KLP (fate#323682) > - commit 0ed191d On the aarch64 based Pine64 board it has been observed that the updated dtb-allwinner package now requires the axp20x-regulator module in the initrd for using the MMC driver, and its parent module axp20x-rsb does not get loaded automatically even if added to the initrd. https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/a… Workaround is to add to your /etc/dracut.conf.d/sunxi_modules.conf: force_drivers+=" axp20x-rsb " and (if after the update) to re-run dracut by, e.g., mkinitrd. Without such an initrd change it will wait indefinitely for the root partition on SD card on next boot. Selecting an older kernel in GRUB will not help - only manually loading an older dtb in U-Boot can help (if e.g. you had multiversion enabled). 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

3 years, 5 months

[opensuse-arm] Error in C++ compiler on Rasberry Pi 2

by Freek de Kruijf

Recently I tried to use all Tumbleweed images on my three Raspberry Pi's (1B, 2B, and 3B). I did not experience problems with booting the image. Also upgrading to the newest version works OK. After that I tried to generate a third party package from GitHub, SBFspot, om my Raspberry Pi 2B. Generating means a.o. compiling a C++ module. The compiler produced a fatal internal error, which I reported on bugzilla. https://bugzilla.opensuse.org/show_bug.cgi?id=1068967 I would not expect such an error from a compiler. Should I report this error also somewhere upstream? If, yes, where? -- fr.gr. Freek de Kruijf member openSUSE -- To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org

3 years, 5 months

[opensuse-arm] Samsung Chromebook (Snow) status?

by Daniel Bischof

Hi, I tried openSUSE-Tumbleweed-ARM-XFCE-chromebook.armv7l-2017.07.22-Build1.1 recently, but it just beeps and kicks me back to the boot screen immediately. No messages on screen, partition resizing, etc. Any hints? Some cgpt magic I could try from ChromeOS perhaps? Best regards, --D. -- To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org

3 years, 5 months

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

openSUSE ARM November 2017