openSUSE ARM July 2014

arm@lists.opensuse.org

16 participants
9 discussions

by Andreas Färber

Hi Sean et al., Yesterday I finally received my Parallella board and last night managed to get Factory working on it. I roughly summarized my steps here: http://en.opensuse.org/HCL:Parallella - U-Boot is already on flash - FAT partition with uImage, devicetree.dtb, parallella.bit.bin - rootfs as usual I'm hoping to get upstream kernel working, be it without HDMI, so holding off packaging their kernel. If someone else wants to, go ahead. Enjoy, Andreas P.S. If anyone in the US wants to buy one, their shop is about to reopen for selling their remaining stock (I seemed among the last to receive a pre-order). Afterwards it'll be available through distributors. The Parallella seems the cheepest option currently to get your hands on a Zynq SoC, beating the MicroZed. -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 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

6 years, 11 months

[opensuse-arm] How does package "qemu-accel" work?

by Ilya Palachev

Hi, all. I have found that package "qemu-accel-armv7l-cross-arm" contains directory /emul/i586-for-arm/ with cross utilities that accelerate the build. Could you explain, how does this construction work? For example, there are 2 binaries in the chroot environemt: bash-4.2# file /usr/bin/make /usr/bin/make: ELF 32-bit LSB executable, ARM, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.16, BuildID[sha1]=0xe1ed5cff83cb3973a9b8ed363857cd796dba63cf, not stripped bash-4.2# file /emul/i586-for-arm/usr/bin/make /emul/i586-for-arm/usr/bin/make: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.16, BuildID[sha1]=0x90f51594906fdc9f7906c7e119ba8703a616d4b8, not stripped bash-4.2# whereis make make: /usr/bin/make /usr/share/man/man1/make.1.gz bash-4.2# LD_DEBUG=all make 2>&1 | tail -10 27438: binding file make [0] to /emul/i586-for-arm/lib/libc.so.6 [0]: normal symbol `exit' [GLIBC_2.0] 27438: symbol=ferror; lookup in file=make [0] 27438: symbol=ferror; lookup in file=/emul/i586-for-arm/lib/libc.so.6 [0] 27438: binding file make [0] to /emul/i586-for-arm/lib/libc.so.6 [0]: normal symbol `ferror' [GLIBC_2.0] 27438: symbol=fclose; lookup in file=make [0] 27438: symbol=fclose; lookup in file=/emul/i586-for-arm/lib/libc.so.6 [0] 27438: binding file make [0] to /emul/i586-for-arm/lib/libc.so.6 [0]: normal symbol `fclose' [GLIBC_2.1] 27438: 27438: calling fini: make [0] 27438: "whereis" says that "make" is taken from /usr/bin/, but ld.so says that it is taken from /emul/i586-for-arm/usr/bin/, so we have cross accelerated executable "make". How does this work? Best regards, Ilya Palachev -- To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org

7 years

[opensuse-arm] Build not enabled for Factory armv7hl at http://download.opensuse.org/ports/armv7hl/factory/repo/oss/

by Arnd Gronenberg

Hello, I'm running openSUSE Factory on some ARMv7 boards (cubietruck, Olimex A10 OLinuXino LIME) using the Factory ARM repository at http://download.opensuse.org/ports/armv7hl/factory/repo/oss/. Everything is working fine and I'm currently working on packaging the specific linux-sunxi kernel and tools for Allwinner processors as well as compiling some specific repositories (like hamradio) for ARM (v7 and v6). Unfortunately, the build for http://download.opensuse.org/ports/armv7hl/factory/repo/oss/ seems to be disable for a couple of weeks, last builds were create around May 20th. Is there any specific reason for no longer providing a Factory armv7hl repository? Whom may I contact to get the build enabled again? How may I help with the armv7hl target? Thanks in advance! -- Arnd (DJ9PZ / AB2QP)

7 years

[opensuse-arm] 13.1 ARM images builds broken - kiwi problem?

by Guillaume Gardet

Hi, there is a problem with all 13.1 ARM images. They failed with : "uboot-image-XXX-setup: No such file or directory". Probably a bug in a kiwi update? Marcus ? Guillaume -- To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org

7 years

[opensuse-arm] Re: SuSE for Beaglebone Black

by Matwey V. Kornilov

Dear Paul, Could you please use appropriate maillist (opensuse-arm) to describe the problems, where much more people could see it and helped you. So, answering your question. If you need all bells and whistles, you use wrong distro. openSUSE images for BBB use upstream linux kernel, where hardware support for BBB is still not complete and mainly due to lack of DT-overlays. However, I hope they fixed usb in 3.16 and as soon as openSUSE kernel team manage to build arm kernel we will see it. The reason to use openSUSE on BBB now is when you need to utilize KIWI advantages, i.e. do kind of mass-deployment or store your ready-to-use configuration. 2014-07-13 0:29 GMT+04:00 Paul Wallingford <paul(a)g-e-n-i-u-s.com>: > On 7/11/2014 8:52 AM, Matwey V. Kornilov wrote: >> >> 2014-07-11 19:49 GMT+04:00 Paul Wallingford <paul(a)g-e-n-i-u-s.com>: >> >>> Since these images do not work, >> >> >> For me, they work just perfect, except of lack of usb. >> > > Hello, > > I did some more work regarding this. I was able to get the openSuSE distro > to work, sort of. > > Did you generate this distro? Are you the maintainer? > > For most people who use the Beaglebone Black, lack of video, lack of USB, > accessing the system via the serial port which requires a separate piece of > hardware and separate software (FTDI drivers, terminal software, etc), the > lack of "flasher" scripts to install the distro on the on-board eMMC, ... > all add up to big show stoppers. > > At the very least, I suggest that you put a note on the wiki page that this > distro is for tinkerers and is not ready for "prime time" use, since there > are still significant unresolved issues. > > I was hoping that openSuSE would run on the BBB. I really hate using > Ubuntu, Fedora, etc., but those are my only choices right now. > > I can tell you how to set up the flasher scripts so the system installs > itself on the internal eMMC when powered on with the S2 button pressed. > This is fairly easy. > > As far as the USB, video, etc., other distros work, so I imagine it is just > a matter of including the correct drivers, but I have not looked into the > issue. > > Best. > > Paul Wallingford -- With best regards, Matwey V. Kornilov http://blog.matwey.name xmpp:0x2207@jabber.ru -- To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org

7 years

[opensuse-arm] openSUSE on Odroid XU (with downstream kernel)

by Joshua Krämer

Dear list, I have an Odroid XU from Hardkernel with an eMMC memory module. The Linux images provided by Hardkernel and on their forums work (Debian, Ubuntu). Now I'd like to make openSUSE work on it. At the end of this mail, I provide the steps of what I have done so far to prepare an eMMC. With this eMMC, the kernel seems to boot, but all I get is a black screen and the device doesn't appear on the network (so SSH isn't possible). With your help, I hope to be able to make HDMI and ethernet work. Links to openSUSE wiki (not much information) and official site: https://en.opensuse.org/HCL:OdroidXU http://hardkernel.com/main/products/prdt_info.php?g_code=G137510300620 Now, here's how I've prepared the eMMC in detail. (1) I got the SuSE rootfs from here: http://download.opensuse.org/ports/armv7hl/distribution/13.1/appliances/ope… (2) And the kernel from here: http://builder.mdrjr.net/kernel-3.4/LATEST/odroidxu.tar.xz (3) Prepared a boot.ini (File attached, I used this as a template: http://builder.mdrjr.net/tools/boot.scr_ubuntu_xu.tar) (4) Prepared rule files with following contents: 40-input.rules: KERNEL=="event*", SUBSYSTEM=="input", MODE="0777", GROUP="adm" 50-hk_hdmi.rules: KERNEL=="fb1", SYMLINK+="fb6" 60-cec.rules: KERNEL=="CEC", MODE="0777" (5) Partitioned the eMMC according to this layout: Device Boot Start End Blocks Id System /dev/sdb1 2048 133119 65536 c W95 FAT32 (LBA) /dev/sdb2 133120 122142719 61004800 83 Linux (6) Prepared partitions with following commands: mkfs.vfat -n boot /dev/sdb1 mkfs.ext4 -L rootfs /dev/sdb2 tune2fs /dev/sdb2 -U e139ce78-9841-40fe-8823-96a304a09859 tune2fs -O ^has_journal /dev/sdb2 (The UID is to make it compatible with hardkernel's kernel update script.) (7) Copied the rootfs to the eMMC, excluding following folders: /lib/modules/3.11.10-2-default /lib/firmware/3.11.10-2-default /boot (8) Copied config-3.4.91, zImage and boot.ini to the boot partition (9) Copied the rule files to /etc/udev/rules.d/ (10) Copied lib/* and usr/* from the kernel to /lib/ and /usr/, using "cp -aR" (don't know if this flags are necessary) With the eMMC prepared like that, the kernel seems to boot (blue LED blinking). The eMMC already has the bootloader preinstalled in a hidden partition. I hope you can give me some hints how to proceed from here. Thanks in advance and kind regards, Joshua Krämer

7 years

[opensuse-arm] JeOS uboot-image-setup - calculate addresses automatically

by Josua Mayer

Hello everyone, A few months ago I had the idea to automatically calculate fdt- and ramdisk load addresses based on their actual sizes. On IRC agraf then suggested to just guess offsets that will always hold true, and that is what I now implemented: The user now only has to specify kerneladdr. dtb and ramdisk will be put somewhere after that address. I assume that a kernel will be smaller than 63MB, and a device tree binary smaller than 1MB. The calculated addresses are then the following: fdtaddr=kerneladdr+63MB ramdiskaddr=fdtaddr+1MB I have created a submit request SR239214 implementing this automatic calculation and using it for the cubox-i. I have also attached the relevant diff so you can look at it easily. If you approve of this automatic calculation I'd encourage you to make use of it in the future! kind regards Josua Mayer

7 years

[opensuse-arm] ask for chroot to suse

by Huangwenhui

Hi, We are building a suse arm on our arm-a15 board, Linux kernel is linaro 3.12.0 version, and compiler is arm-linux-gnueabihf-, we got suse source and mount it on by nfsserver. when I chroot to suse, a error occured like this: sh (81): undefined instruction: pc=b6f76b48 # chroot /mnt/suse_root #[ 35.880000] sh (81): undefined instruction: pc=b6f76b48 #[ 35.890000] Code: e59f3034 e08f2002 e0822003 e5922040 (ecac8b10) #Illegal instruction # cat log #81 access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory) #81 --- SIGILL (Illegal instruction) @ 0 (0) --- #81 +++ killed by SIGILL +++ What could it? Expect replies. huangwenhui -- To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org

7 years

[opensuse-arm] Re: [RFC 0/4] ARM: dts: exynos: Prepare Spring

by Andreas Färber

Am 23.06.2014 22:11, schrieb Benson Leung: > On Mon, Jun 23, 2014 at 12:57 PM, Doug Anderson <dianders(a)chromium.org> wrote: >>> Also when the screen stayed on, the embedded controller's keymap seems >>> hardcoded to US English with system settings not taking effect; but >>> surely we don't want per-keyboard device tree files to remedy that. >> >> +Benson may be able to answer this. I believe generally non-US >> keyboard layouts are handled at a higher level. > > There's no such thing as a notion of US versus non-US keyboard layouts > at the embedded controller level or even in the kernel. Indeed, this > should all be handled in user space. > > The chromeos firmware and kernel should return the correct key codes > for every key pressed on keyboards with the ANSI layout (US based), or > ISO (UK and most other countries). > > The only differences are : > * the ISO keyboard has an extra key, which is immediately to the right > of the Left Shift key. This must return KEY_102ND key code from the > input layer. > * the ISO keyboard has a different location for the | \ key, which > accomodates the upside L shaped Enter key on the right side of the > keyboard. The keycode for this key is KEY_BACKSLASH. > > Basically, all of this should be verified using evtest to test that > the ec and kernel have the keys right. Hm, we may be talking about two different things here? I have been doing a minimum system bring-up for 3.16, with openSUSE userspace. My YaST-selected system keymap (German with deadkeys) is not taking effect on German Spring at the *framebuffer console* (tty1) - evdev is not involved at that level AIUI. Backspace and L-shaped enter keys work okay. The keymap here should be identical to that in the original German device and seemed to match that in the exynos5250-snow.dts file. I just checked (w/ dp-controller, hdmi, fimd commented out in my patch): * An external USB keyboard does not work correctly either. * In X11 (xdm), both internal and USB keyboard work as expected. Similar situation in ChromeOS IIRC, with keymap correct at graphical login but not on the right-arrow console - although I don't know the ChromeOS userland too well to judge if it was configured correctly. > If you are having other problems with keyboard layout being stuck to > US QWERTY, please check your user space. On my Raspberry Pi for instance, the equivalent openSUSE Factory works just fine with German keymap for USB keyboard. Might any related kernel config options be missing in exynos_defconfig? Anything in particular I should check in user space? Cheers, Andreas -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 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

7 years, 1 month

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

openSUSE ARM July 2014