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
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
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
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
>> 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
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
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
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
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