Hi,
I have a working setup for using the accelerated binaries for aarch64
builds in
home:adrianSuSE:branches:openSUSE:Factory:ARM
also, I am working on accelerated armv6hl.
Is there any reason not to apply the current state already in
openSUSE:Factory:ARM for aarch64?
moin
adrian
--
Adrian Schroeter
email: adrian(a)suse.de
SUSE LINUX GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 21284
(AG Nürnberg)
Maxfeldstraße 5
90409 Nürnberg
Germany
--
To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org
Hi,
what happened? why do we suddenly have 3800 unresolvable packages?!
very weird errors as well:
unresolvable: nothing provides libpng16.so.16()(64bit) needed by libqt4-devel
but libpng16 exists..
Thanks,
Dirk
--
To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org
Hi,
Just created an initial template of images for AArch64 in
openSUSE:Factory:ARM. Will debug this in the next few days.
Greetings
Dirk
--
To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org
Hi,
unfortunately the file server for the ARMv7 build farm gave up due to
a disk crash. I'll try to restore service.
Greetings,
Dirk
--
To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org
Hi,
I know many people are waiting for it, so here it is, a new raspberry Pi image:
http://guillaume.gardet.free.fr/openSUSE/RPi/openSUSE-RPi-image-20130906.ra…
To check download, have a look at sha256sum:
http://guillaume.gardet.free.fr/openSUSE/RPi/openSUSE-RPi-image-20130906.ra…
Changelog:
* Fix openssl packages (which fixes zypper/yast2/openssh)
* Added Contrib repo to get latest Raspberry Pi software
login: root
passwd: linux
Note that once OBS will build a working image for Raspberry Pi, we will switch back to it.
Have a nice day,
Guillaume
--
To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org
To all those interested,
ARM have finally published the reference manual for ARMv8 \o/ You can grab a copy [0] now, you will need to accept the EULA first.
Regards,
Andy
0 - http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0487a/index.…
--
Andrew Wafaa - Principal Engineer, Open Source - ARM Ltd.
Tel: +44 1223 405981 Mob: +44 7974 074546
-- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2557590
ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2548782
--
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'm trying to get RasPi to boot with U-Boot, streamlined with the other
ARM platforms (I guess).
So how is this designed to work? That's what I understand:
* U-Boot
* loads boot.scr.img from <whatever the board boots from>
* boot.scr loads kernel.img
* really?, or the zImage directly?
* from where? always from the same boot partition U-Boot came from?
or possibly from the root fs? (extload should be able to do that?)
* maybe boot.scr has the kernel cmdline embedded? Or does it load
it from storage?
If this is not correct, please tell me the correct sequence (or point me
to the documentation ;)
Then, the more interesting questions are:
* who creates kernel.img U-Boot image (if this is used)?
* who creates boot.scr.img?
Actually I am trying to do the following for the RPI:
* u-boot on SDCard FAT partition
* boot.script on SDCard FAT partition, intelligent enough to fetch some
sort of config from /boot on ext4 rootfs (for kernel command line
options)
* boot.script to load kernel from /boot on ext4 rootfs
The idea is, that the FAT partitions does not need to be touched after a
kernel update etc, but that it will just fetch all that's needed from
the rootfs.
Not sure if this is a good idea and if it is going to work, but it would
surely make kernel updates etc. much more painless than they are now.
Best regards,
seife
--
Stefan Seyfried
"If your lighter runs out of fluid or flint and stops making
fire, and you can't be bothered to figure out about lighter
fluid or flint, that is not Zippo's fault." -- bkw
--
To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org
I have a bluetooth USB stick in my Raspberry Pi and with the rapberrypi kernel
I do see bluetooth modules loaded in the kernel. However, some bleutooth
packages are available in the repository, but the most imported one, bleuz, is
missing.
Is it possible to add this package to the repository?
--
fr.gr.
member openSUSE
Freek de Kruijf
--
To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org
Hi,
> Alex, Dirk, are you ok to remove :kernel-3.6 subproject since all people want to go for 3.6 kernel in Contrib:RPi repo because it fixes lots of bugs?
Sounds good to me, go ahead.
Greetings,
Dirk
--
To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org
Hi all,
after Andreas' and Guillaume's great HOWTO, I finally pulled out my
raspi over the weekend and played with it.
It works pretty well.
However, the system is pretty unstable with the 3.1 kernel.
I noticed when trying to build ffmpeg from source. Lots of strange
errors, from ext4 complaining about delayed allocation to spurios
"ENOPERM" when closing temporary files during compilation etc.
Also, the raspberrypi-gfx demo/test tools did not work, erroring with
messages about "vcihq not connected" in dmesg.
Additionally, my 512MB Raspi only had 256MB available, no matter what
amount of gpu_mem I put into config.txt.
Then I simply grabbed the binary kernel and modules from
https://github.com/raspberrypi/linux and new firmware from
https://github.com/raspberrypi/firmware and voila -- the little box was
running stable.
So I took the kernel from
devel:ARM:Factory:Contrib:RaspberryPi:kernel-3.6 and updated the patch
set to yesterdays git and changed the configuration to be pretty similar
to what is in the "upstream" git.
I also updated the firmware package.
Both together run very fine for me. I have all RAM available, the test
tools work, etc.pp.
So maybe it would make sense to use the 3.6.11 kernel as "upstream"
Raspberry Pi also does?
I created SRs 198076 (raspberrypi-firmware) and 198080
(kernel-raspberrypi) and maybe we should use
devel:ARM:Factory:Contrib:RaspberryPi:kernel-3.6 as the default raspi
kernel?
Best regards,
Stefan
--
Stefan Seyfried
"If your lighter runs out of fluid or flint and stops making
fire, and you can't be bothered to figure out about lighter
fluid or flint, that is not Zippo's fault." -- bkw
--
To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org
