openSUSE ARM June 2014

arm@lists.opensuse.org

15 participants
17 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] 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

[opensuse-arm] Mono bug on opensuse arm on Beagle Bone Black; works on opensuse intel

by lists

I'm running this program via "ssh -X" if it makes a different. Note that logging into the beagle bone black via the HDMI display doesn't work, otherwise I would test it that way as well. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ mono VirtualRadar.exe Stacktrace: at <unknown> <0xffffffff> at (wrapper managed-to-native) System.Drawing.GDIPlus.GdipCreateFont (intptr,single,System.Drawing.FontStyle,System.Drawing.GraphicsUnit,intptr&) <0xffffffff> at System.Drawing.Font.CreateFont (string,single,System.Drawing.FontStyle,System.Drawing.GraphicsUnit,byte,bool) <0x0013f> at System.Drawing.Font..ctor (string,single,System.Drawing.FontStyle,System.Drawing.GraphicsUnit,byte,bool) <0x0007f> at System.Drawing.Font..ctor (string,single,string) <0x00057> at (wrapper remoting-invoke-with-check) System.Drawing.Font..ctor (string,single,string) <0xffffffff> at System.Drawing.SystemFonts.get_DefaultFont () <0x0005b> at System.Windows.Forms.Theme.get_DefaultFont () <0x00027> at System.Windows.Forms.Control.get_DefaultFont () <0x0001f> at System.Windows.Forms.Control.get_Font () <0x00053> at System.Windows.Forms.Form..ctor () <0x00077> at VirtualRadar.WinForms.BaseForm..ctor () <0x00023> at VirtualRadar.WinForms.SplashView..ctor () <0x0001b> at (wrapper remoting-invoke-with-check) VirtualRadar.WinForms.SplashView..ctor () <0xffffffff> at VirtualRadar.Program.StartApplication (string[]) <0x00067> at VirtualRadar.Program.Main (string[]) <0x0034b> at (wrapper runtime-invoke) <Module>.runtime_invoke_void_object (object,intptr,intptr,intptr) <0xffffffff> Native stacktrace: mono() [0xac3c8] mono() [0x2aad4] /lib/libc.so.6(__default_rt_sa_restorer_v2+0) [0xb6dd6d50] /usr/lib/libgdiplus.so(GdipCreateFont+0x110) [0xb5d43aec] Debug info from gdb: ================================================================= Got a SIGSEGV while executing native code. This usually indicates a fatal error in the mono runtime or one of the native libraries used by your application. ================================================================= ========================================= The mono-complete package is 3.0.6-3.1.3 The libgdiplus0 pakage is 2.10.9-3.1.2 system info uname -a Linux linux 3.8.13 #1 SMP Thu Feb 6 16:19:16 CET 2014 armv7l armv7l armv7l GNU/Linux cat /proc/version Linux version 3.8.13 (koen@thinkpad) (gcc version 4.7.4 20130626 (prerelease) (Linaro GCC 4.7-2013.07) ) #1 SMP Thu Feb 6 16:19:16 CET 2014 -- 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] BBB image - able to run from onboard MMC versus SD card?

by Christopher Myers

Hi everyone! I'm new to the list, and this is my first post, so please forgive my ignorance if this has been covered before. I'd searched the archives and didn't see anything about it, so thought I'd pose the question here. I recently picked up one of the new Beaglebone Black rev. C boards, and wanted to try to run oS on it, since it's my OS of choice :) I was able to successfully get the JEOS image copied up to the SD card and installed, and it seems to run fine. However, I'd much rather have it running from the onboard MMC instead of the SD card. Is this even possible? I've seen how other OS images can be loaded to the MMC by booting off of the SD card, but it doesn't look like the oS one does that. Chris -- 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

Re: [opensuse-arm] OS 13.1 Raspberry Pi image, Build 38.1 has no apparent root filesystem

by Alex Armstrong

>> I see where the root fs option is passed to the kernel in the boot >> script, but it surprises me that neither mount nor df show / in their >> listings. Although findmnt does show / in it's listing. Is this by >> design? If so, I'll make a note in the wiki. > The root file system in the output of df in shown in /dev/root mounted on / > Indeed, that is what I expect to see. But when I run df no entries for /dev/root on / are shown. This is all I get: # df -h Filesystem Size Used Avail Use% Mounted on /run 187M 1.1M 186M 1% /var/run No /boot, no /, just /run. >>> You can resize the partition used for the root file system on the system >>> you wrote the image to the SD card. You can use YaST on that system to do >>> so. >> Yes this does work. I had the impression from the wiki that I could use >> YaST on the RPi itself to resize root. If this is not the case I'll >> correct it. > You can't resize a mounted system, but without a mounted root you can't use > any program. > Makes sense - thanks. -Alex -- 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

[opensuse-arm] OS 13.1 Raspberry Pi image, Build 38.1 has no apparent root filesystem

by Alex Armstrong

Greetings, I have successfully installed and run this JeOS for the Raspberry Pi: openSUSE-13.1-ARM-JeOS-raspberrypi.armv7l-1.12.1-Build38.1.raw Dated: 23-Jun-2014 Downloaded from: http://download.opensuse.org/repositories/devel:/ARM:/13.1:/Contrib:/Raspbe… But have noticed odd behavior with the filesystem tree. Specifically, running 'mount' produces this output: <SNIP> mqueue on /dev/mqueue type mqueue (rw) debugfs on /sys/kernel/debug type debugfs (rw) devpts on /dev/pts type devpts (rw,mode=0620,gid=5) proc on /proc type proc (rw) configfs on /sys/kernel/config type configfs (rw) /run on /var/run type none (rw,bind) /run/lock on /var/lock type none (rw,bind) <SNAP> And the output of df -h: <SNIP> Filesystem Size Used Avail Use% Mounted on /run 187M 1.1M 186M 1% /var/run <SNAP> It would appear that no root filesystem is mounted. And looking at /etc/mtab we see: <SNIP> mqueue /dev/mqueue mqueue rw 0 0 debugfs /sys/kernel/debug debugfs rw 0 0 devpts /dev/pts devpts rw,mode=0620,gid=5 0 0 proc /proc proc rw 0 0 configfs /sys/kernel/config configfs rw 0 0 /run /var/run none rw,bind 0 0 /run/lock /var/lock none rw,bind 0 0 <SNAP> Additionally, /etc/fstab contains only these entries: <SNIP> devpts /dev/pts devpts mode=0620,gid=5 0 0 proc /proc proc defaults 0 0 <SNAP> Which seems to confirm that there is no root fs. But if we look at fdisk -l: <SNIP> Disk /dev/mmcblk0: 7948 MB, 7948206080 bytes, 15523840 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 Disk label type: dos Disk identifier: 0xa7e6536d Device Boot Start End Blocks Id System /dev/mmcblk0p1 * 2048 485383 241668 c W95 FAT32 (LBA) /dev/mmcblk0p2 487424 1980415 746496 83 Linux <SNAP> The structure looks ok (only missing a swap partition). If we try to use YaST to resize /dev/mmcblk0p2, we get an error saying the filesystem seems to be inconsistent. But then we try to run fsck /dev/mmcblk0 it tells us: <SNIP> fsck from util-linux 2.23.2 e2fsck 1.42.8 (20-Jun-3013) /dev/mmcblk0p2 is mounted. e2fsck: Cannot continue, aborting. <SNAP> This, plus the fact that the system runs fine seem to indicate that the root fs is actually mounted. I found the situation a bit puzzling, and would be interested to hear any thoughts on it. As a side note, it is possible to resize the root partition in a second computer using YaST and then install software from the on-line repos. -Alex -- 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

[opensuse-arm] Using ssh -X on 13.1 JEOS; also problem logging directly into the Beagle Bone Black

by lists

I'm trying to open a terminal window with graphics on my desktop to ssh into the Beagle Bone Black running opensuse 13.1 JEOS. I installed x11-server, but that doesn't appear to be enough. command format is ssh -X me(a)xxx.xxx.xxx.xx Note also I can't log into the BBB from the using the graphic display and usb for keyboard/mouse. I get the login and password boxes, I see login successful flash on the screen, then it immediately goes back to the login box. A non-graphics ssh into the computer is fine. In fact, I could live with ncurses, but I have an app that uses Qt graphics just to set it up. I loaded qt3 and mono-qt. No luck. -- 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

[opensuse-arm] Cubox-i - U-Boot

by Josua Mayer

Greetings you armed lizards, Now that my u-boot package adaptation for the cubox-i is basically finished I would like to get it merged into the Base:System:u-boot package. But there is a nasty showstopper! My patch conflicts with the mlo-ext2.patch, which btw looks rather hacky. The conflict is basically all about this line: + boot_mode = MMCSD_MODE_FAT; /* Fix OMAP4 boot */ Now I would like to know if this patch is needed, and also if my patch for the cubox-i does replace it. Maybe owners of omap4 devices using this patch can shed some light here? My adapted package can be found here: https://build.opensuse.org/package/show/home:mayerjosua:cubox-i/u-boot kind regards Josua Mayer -- 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

[opensuse-arm] openSUSE-13.1-ARM-JeOS-beaglebone.armv7l-1.12.1-Build37.1.raw.xz boot issue

by lists

Boot issue? Well it doesn't. Here is the serial port output: ------------------------------------ \0x01\0x00 U-Boot SPL 2013.04-dirty (Jul 10 2013 - 14:02:53) musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, HB-ISO Rx, HB-ISO Tx, SoftConn) musb-hdrc: MHDRC RTL version 2.0 musb-hdrc: setup fifo_mode 4 musb-hdrc: 28/31 max ep, 16384/16384 memory USB Peripheral mode controller at 47401000 using PIO, IRQ 0 musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, HB-ISO Rx, HB-ISO Tx, SoftConn) musb-hdrc: MHDRC RTL version 2.0 musb-hdrc: setup fifo_mode 4 musb-hdrc: 28/31 max ep, 16384/16384 memory USB Host mode controller at 47401800 using PIO, IRQ 0 OMAP SD/MMC: 0 mmc_send_cmd : timeout: No status update reading u-boot.img reading u-boot.img U-Boot 2013.04-dirty (Jul 10 2013 - 14:02:53) I2C: ready DRAM: 512 MiB WARNING: Caches not enabled NAND: No NAND device found!!! 0 MiB MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1 *** Warning - readenv() failed, using default environment musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, HB-ISO Rx, HB-ISO Tx, SoftConn) musb-hdrc: MHDRC RTL version 2.0 musb-hdrc: setup fifo_mode 4 musb-hdrc: 28/31 max ep, 16384/16384 memory USB Peripheral mode controller at 47401000 using PIO, IRQ 0 musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, HB-ISO Rx, HB-ISO Tx, SoftConn) musb-hdrc: MHDRC RTL version 2.0 musb-hdrc: setup fifo_mode 4 musb-hdrc: 28/31 max ep, 16384/16384 memory USB Host mode controller at 47401800 using PIO, IRQ 0 Net: <ethaddr> not set. Validating first E-fuse MAC cpsw, usb_ether Hit any key to stop autoboot: 1 \0x08\0x08\0x08 0 gpio: pin 53 (gpio 53) value is 1 mmc0 is current device micro SD card found mmc0 is current device gpio: pin 54 (gpio 54) value is 1 SD/MMC found on device 0 Failed to mount ext2 filesystem... ** Unrecognized filesystem type ** gpio: pin 55 (gpio 55) value is 1 ** No partition table - mmc 0 ** -- 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

[opensuse-arm] cavium

by Peter Czanik

Hi, I just read this: http://www.cavium.com/newsevents_Cavium_openSUSE_Community_Announces_Partne… Do you have any info, when this will be available? Does anybody have any first hand experience how openSUSE runs on it? It looks very promising! Bye, CzP -- 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 June 2014