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
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
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)
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
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
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:OdroidXUhttp://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
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
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
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