July 2014 - openSUSE ARM - openSUSE Mailing Lists

[opensuse-arm] Parallella booting
by Andreas Färber 25 Aug '14

25 Aug '14

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 … [View More]

5 12

[opensuse-arm] How does package "qemu-accel" work?
by Ilya Palachev 31 Jul '14

31 Jul '14

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 … [View More]

3 3

[opensuse-arm] Build not enabled for Factory armv7hl at http://download.opensuse.org/ports/armv7hl/factory/repo/oss/
by Arnd Gronenberg 28 Jul '14

28 Jul '14

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/… [View More]

6 12

[opensuse-arm] 13.1 ARM images builds broken - kiwi problem?
by Guillaume Gardet 24 Jul '14

24 Jul '14

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

2 11

[opensuse-arm] Re: SuSE for Beaglebone Black
by Matwey V. Kornilov 14 Jul '14

14 Jul '14

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. … [View More]

1 0

[opensuse-arm] openSUSE on Odroid XU (with downstream kernel)
by Joshua Krämer 09 Jul '14

09 Jul '14

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 … [View More]

3 2

[opensuse-arm] JeOS uboot-image-setup - calculate addresses automatically
by Josua Mayer 06 Jul '14

06 Jul '14

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: … [View More]

3 5

[opensuse-arm] ask for chroot to suse
by Huangwenhui 03 Jul '14

03 Jul '14

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 … [View More]

5 16

[opensuse-arm] Re: [RFC 0/4] ARM: dts: exynos: Prepare Spring
by Andreas Färber 02 Jul '14

02 Jul '14

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 … [View More]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 [View Less]

2 2