;>> Quite. This is exactly the tension behind the dicussion - while arm64
> >>> machines are mainly mobile so far, we're finally starting to see
> >>> bigger and more capable systems that you'd actually be happy to use as
> >>> a desktop/laptop.
On 26/11/2018 16:58, Wookey wrote:
> On 2018-11-26 09:08 -0600, Tom Gall wrote:
>> On Mon, Nov 26, 2018 at 8:46 AM Steve McIntyre
>> wrote:
>>>
>>> Quite. This is exactly the tension behind the dicussion - while arm64
>>> machines are mainly mo
On 2018-11-26 09:08 -0600, Tom Gall wrote:
> On Mon, Nov 26, 2018 at 8:46 AM Steve McIntyre
> wrote:
> >
> > Quite. This is exactly the tension behind the dicussion - while arm64
> > machines are mainly mobile so far, we're finally starting to see
> > bigger
; >> Hi Wookey,
> > >>
> > >> This was something bouncing around in the Graphics Working Group back
> > >> in the day. Alexandros as I recall was the key dev. As far as a shim
> > >> goes given the effort that would have been involved and the lack o
the Graphics Working Group back
> >> in the day. Alexandros as I recall was the key dev. As far as a shim
> >> goes given the effort that would have been involved and the lack of
> >> interest, it wasn't worked on.
> >>
> >> For ARM64 and QT would a move t
On Mon, 26 Nov 2018 at 14:46, Steve McIntyre wrote:
> Is it true that most PCIe graphics cards (and drivers) will also
> support GLES as well as GL? I've seen that asserted.
Supporting GLES doesn't mean applications will use GLES. Desktop
applications use GL/DX (via Wine)/Vulkan. I'm no expert in
As far as a shim
> > goes given the effort that would have been involved and the lack of
> > interest, it wasn't worked on.
> >
> > For ARM64 and QT would a move to GLES be a "good thing?" Yes.
> >
> > When it comes to graphics drivers today for arm
s far as a shim
>> goes given the effort that would have been involved and the lack of
>> interest, it wasn't worked on.
>>
>> For ARM64 and QT would a move to GLES be a "good thing?" Yes.
>>
>> When it comes to graphics drivers today for arm h
; interest, it wasn't worked on.
>
> For ARM64 and QT would a move to GLES be a "good thing?" Yes.
>
> When it comes to graphics drivers today for arm hardware GLES is
> pretty universal. GLES is a standard, there is compliance through
*Shouts* ThunderX2 Worksta
Hi Wookey,
This was something bouncing around in the Graphics Working Group back
in the day. Alexandros as I recall was the key dev. As far as a shim
goes given the effort that would have been involved and the lack of
interest, it wasn't worked on.
For ARM64 and QT would a move to GLES
from
building QT for arm64 for openGLES instead of openGL because there is
a lot more hardware available (cheapish dev boards) with drivers
supporting GLES then desktop style hardware with standard graphics
card supporting 'proper GL'. Ubuntu did this 2 years ago.
Unfortunately building f
Hi,
You can find prebuilt debian/stretch arm64 virtualization images from:
https://cdimage.debian.org/cdimage/openstack/current/
Riku
On 13 December 2017 at 19:47, Nicolas Dechesne
wrote:
> +linaro-dev mailing
>
> I would recommend you do not use these tools, except if you really
cross debootstrap)
cheers
nico
On Wed, Dec 13, 2017 at 5:17 PM, miracle.huang
wrote:
> Dear Nicolas, and fathi,
>
> Sorry for bother you.
>
> I clone the repository “git://git.linaro.org/ci/ubuntu-build-service.git”,
> and want to build ARM64 minial rootfs for arm kvm vir
> Op 6 sep. 2016, om 20:42 heeft Denys Dmytriyenko het
> volgende geschreven:
>
> Koen, Fathi, et al,
>
> Any chance to get EXTRA_OEMAKE to not hardcode ARM64 flags?
>
> https://git.linaro.org/openembedded/meta-linaro.git/blob/HEAD:/meta-optee/recipes-security/o
Koen, Fathi, et al,
Any chance to get EXTRA_OEMAKE to not hardcode ARM64 flags?
https://git.linaro.org/openembedded/meta-linaro.git/blob/HEAD:/meta-optee/recipes-security/optee/optee-os_git.bb#l23
Thanks,
--
Denys
___
linaro-dev mailing list
linaro
On Fri, Nov 13, 2015 at 12:47 PM, sk.syed2 wrote:
>Please excuse me if this is not appropriate list to post this question.
> I just got arm64 snapdragon 810 development board(msm8994) and am trying to
> see if there is a u-boot port available on this platform yet.
>
not tha
Hi
Please excuse me if this is not appropriate list to post this question.
I just got arm64 snapdragon 810 development board(msm8994) and am trying to
see if there is a u-boot port available on this platform yet.
Thanks
-syed
___
linaro-dev mailing
On Tue, Sep 15, 2015 at 5:36 PM, James Cloos wrote:
> > "TG" == Tom Gall writes:
>
> TG> I like to use USB to Ethernet. Works well!
>
> Thanks. I should have thought to try that.
>
> Now I just need to find mine ☺
>
USB Gadget (g_ether) works quite well as well, and doesn't require an
> "TG" == Tom Gall writes:
TG> I like to use USB to Ethernet. Works well!
Thanks. I should have thought to try that.
Now I just need to find mine ☺
-JimC
--
James Cloos OpenPGP: 0x997A9F17ED7DAEA6
___
linaro-dev mailing list
linaro
I like to use USB to Ethernet. Works well!
Regards,
Tom
> On Sep 14, 2015, at 5:26 PM, James Cloos wrote:
>
> Are there any decent arm64 boards available?
>
> I ordered a dragonboard some time back, and it finally shipped and
> arrived today.
>
> But the networking
Are there any decent arm64 boards available?
I ordered a dragonboard some time back, and it finally shipped and
arrived today.
But the networking sucks.
There is no proper ethernet, just 802.11. And it works for only a few
seconds at a time.
Effectively worthless.
Is there anything better
izeof(uint64_t);
>> + }
>> +
>> + /* The following is more efficient than the straight loop */
>> + if (length & sizeof(uint32_t)) {
>> + CRC32CW(crc, *(uint32_t *)buffer);
>> + buffer += size
ARM64_H
> +#define CEPH_COMMON_CRC32C_ARM64_H
> +
> +#ifdef __cplusplus
> +extern "C" {
> +#endif
> +
> +#ifdef __aarch64__
> +
> +extern uint32_t ceph_crc32c_arm64(uint32_t crc, unsigned char const *buffer,
> unsigned len);
> +
> +#else
> +
mmon/test_crc32c.cc b/src/test/common/test_crc32c.cc
index b4297c6..1a9b2e2 100644
--- a/src/test/common/test_crc32c.cc
+++ b/src/test/common/test_crc32c.cc
@@ -13,6 +13,7 @@
#include "common/sctp_crc32.h"
#include "common/crc32c_intel_baseline.h"
+#include "common/crc32
Hi Leif,
I think I got it. Thank you very much.
-Original Message-
From: Leif Lindholm [mailto:leif.lindh...@linaro.org]
Sent: 2014-5-1 (星期四) 19:32
To: Kelvin K. Li
Cc: linaro-dev@lists.linaro.org
Subject: Re: 答复: why is the the smp_mb() in arm64's barrier.h "dmb ish"?
On Thu, May 01, 2014 at 06:49:44PM +0800, kelvin...@via-alliance.com wrote:
> Another questions:
>
> In Arm V8 Architecture Reference Manual，there is an example (see beblow) to
> explain the shareability attribute of clusters. It is easy to know: each
> cluster is corresponding to a Inner sharea
Cc: linaro-dev
Subject: 答复: why is the the smp_mb() in arm64's barrier.h "dmb ish"?
Hi Leif，
Why do the smp_mb()/smp_rmb()/smp_wmb() for arm (arm-32) not change to the "dmb
ishxx" too?
Is there some consideration？
-Original Message-
From: Leif Lindholm [mailto:le
Hi Kelvin,
On Thu, May 01, 2014 at 06:08:14PM +0800, kelvin...@via-alliance.com wrote:
> Why do the smp_mb()/smp_rmb()/smp_wmb() for arm (arm-32) not change to the
> "dmb ishxx" too?
But they do. For ARMv7, smb_mb(), smp_rmb() and smp_wmb() become dmb
ish, dmb ish and dmb ishst respectively.
Th
why is the the smp_mb() in arm64's barrier.h "dmb ish"?
Hi Kelvin.
On 30 April 2014 10:52, wrote:
> In arch/arm64/include/asm/barrier.h, there is the definition of
> smp_mb()/smp_rmb()/smp_wmb() for arm64. I noticed that all the 3 macors are
> using “dmb ishxx”, which is
Hi Kelvin.
On 30 April 2014 10:52, wrote:
> In arch/arm64/include/asm/barrier.h, there is the definition of
> smp_mb()/smp_rmb()/smp_wmb() for arm64. I noticed that all the 3 macors are
> using “dmb ishxx”, which is only affect the cluster of the CPU executing the
> instructi
Hi All,
In arch/arm64/include/asm/barrier.h, there is the definition of
smp_mb()/smp_rmb()/smp_wmb() for arm64. I noticed that all the 3 macors
are using "dmb ishxx", which is only affect the cluster of the CPU
executing the instruction. But in the big.LITTLE system, there will be
Hi all,
I'd like to announce the availability of a preview/prototype of Go for
arm64 platforms.
This is based around gccgo but includes a version of the 'go' tool for
your familiar "go get" experience.
This release is based on the latest Ubuntu development version,
Hi, expert:
Recently, I encounter a tricky issue when using "aplay" to playback music on
arm64 core, but "aplay" application and "alsa-lib" are 32 bit version. The
exception happens and it results in "aplay" segment fault. I tried to root
cause it tho
arm64)?
It is possible to run both AArch32 (arm) and AArch64 (arm64)
applications under an arm64 kernel.
What is not possible is for an AArch32 user-space program to use an
AArch64 user-space library (or any combination like this).
So if you want to run 32-bit user-space programs you need to
Hi,
We are working on userspace aarch64 and aarch32 apps and we are trying
to run 32/64 mode app simultaneously.
Is there any multi-arch support for mixed rootfs (has linkers/libs of
both arm and arm64)?
--
Thanks,
-Zhou
___
linaro-dev mailing list
Hi Wookey,
On 10/18/2013 11:49 AM, Wookey wrote:
> +++ Christopher Covington [2013-10-18 10:25 -0400]:
>
> I still haven't determined to my satisfaction whether the linaro binary
> (cross) toolchains
> can be used for multiarch cross-building by just moving files
> about/symlinking and fiddlin
+++ Christopher Covington [2013-10-18 10:25 -0400]:
> On 10/17/2013 07:21 AM, Zhou Zhu wrote:
> It would be nice if it were easier to install the binary toolchain releases
> into a multi-arch rootfs,
It would. Currently you can use distro cross-toolchains (from Ubuntu,
and Debian soon if I get
On 10/17/2013 07:21 AM, Zhou Zhu wrote:
> So how does the libraries place in the rootfs? like lib/lib64 as in x86/x64?
> Is there any similar rule in arm/arm64 system (whatever
> openebedded/ubuntu/android/...) for that? Like multi arch spec in ubuntu?
OpenEmbedded unfortunately does no
mode app simultaneously.
>>> Is there any multi-arch support for mixed rootfs (has linkers/libs of both
>>> arm and arm64)?
>>
>> It is possible to run both AArch32 (arm) and AArch64 (arm64)
>> applications under an arm64 kernel.
>>
>> What is n
ort for mixed rootfs (has linkers/libs of both
> > arm and arm64)?
>
> It is possible to run both AArch32 (arm) and AArch64 (arm64)
> applications under an arm64 kernel.
>
> What is not possible is for an AArch32 user-space program to use an
> AArch64 user-space library (or
Hi,
On 16 October 2013 11:45, Zhou Zhu wrote:
> Hi,
> We are working on userspace aarch64 and aarch32 apps and we are trying to
> run 32/64 mode app simultaneously.
> Is there any multi-arch support for mixed rootfs (has linkers/libs of both
> arm and arm64)?
It is possible to r
Hi Thorsten,
The 'lstat' issue is fixed now and with this fix, only 3 tests fail on mksh
all of which are ignored as below.
..
pass ./check.t:history-subst-4
pass ./check.t:history-subst-5
FAIL ./check.t:history-ed-1 (ignored)
Description:
Basic (ed) editing works (assu
Hi Marcin,
Thanks for your replay.
On 2013/4/25 18:10, Marcin Juszkiewicz wrote:
> W dniu 25.04.2013 11:07, zhanqing Zhan(Qing) pisze:
>
>> So, i want to build arm64 kernel according to the steps of
>> HowTo/BuildArm64Kernel.Then i use Foundatin_v8 with args such a
> "FATAL: kernel too old" is clean message.
> Use AT LEAST 3.7 kernel but better would be to use 3.9-rc even.
I have tried 3.7 kernel and used 3.9-rc even. But i cannot built kenel
correctly.Because some files such as
arm64/boot/dts/vexpress-v2p-aarch64.dts,vexpress-foundation
W dniu 25.04.2013 11:07, zhanqing Zhan(Qing) pisze:
> So, i want to build arm64 kernel according to the steps of
> HowTo/BuildArm64Kernel.Then i use Foundatin_v8 with args such as
> linux-system-foundation.axf,vexpress64-openembedded_lam-armv8_20130320-274.img.
>
>
But ke
+++ Wookey [2013-02-27 02:10 +]:
> State of the Debian/Ubuntu arm64 port
> =
>
> *** Arm64 lives! ***
>
> Executive summary
> -
>
> * There is now a bootable (raring) image to download and run
> * A bit m
On Fri, Mar 01, 2013 at 08:41:47AM +, Anup Patel wrote:
> This patch adds support for using earlyprintk with 8250/16550 UART
> ports.
>
> The 8250/16550 UART can either have 8-bit or 32-bit aligned registers
> which is HW vendor dependent.
>
> Kernel args for 8-bit aligned regs: earlyprintk=u
On Fri, 1 Mar 2013 14:11:47 +0530, Anup Patel
wrote:
> This patch adds support for using earlyprintk with 8250/16550 UART
ports.
>
> The 8250/16550 UART can either have 8-bit or 32-bit aligned registers
> which is HW vendor dependent.
>
> Kernel args for 8-bit aligned regs:
> earlyprintk=uart82
-32bit,
Signed-off-by: Anup Patel
---
arch/arm64/kernel/early_printk.c | 23 +++
1 file changed, 23 insertions(+)
diff --git a/arch/arm64/kernel/early_printk.c b/arch/arm64/kernel/early_printk.c
index 7e320a2..c39e90b 100644
--- a/arch/arm64/kernel/early_printk.c
+++ b/arch
match the actual code.
Sure, I will fix this.
>
>
> > Signed-off-by: Anup Patel
> > ---
> > arch/arm64/kernel/early_printk.c | 23 +++
> > 1 file changed, 23 insertions(+)
> >
> > diff --git a/arch/arm64/kernel/early_printk.c
> &g
egs:
> earlyprintk=uart8250-8bit,
>
> Kernel args for 32-bit aligned regs:
> earlyprintk=uart8250-16bit,
^
Please fix this comment to match the actual code.
> Signed-off-by: Anup Patel
> ---
> arch/arm64/kernel/early_printk.c | 23 +
-16bit,
Signed-off-by: Anup Patel
---
arch/arm64/kernel/early_printk.c | 23 +++
1 file changed, 23 insertions(+)
diff --git a/arch/arm64/kernel/early_printk.c b/arch/arm64/kernel/early_printk.c
index 7e320a2..d57f300 100644
--- a/arch/arm64/kernel/early_printk.c
+++ b/arch
13 6:11 PM, "Wookey" wrote:
> State of the Debian/Ubuntu arm64 port
> =
>
> *** Arm64 lives! ***
>
> Executive summary
> -
>
> * There is now a bootable (raring) image to download and run
> * Everything has
On Wed, Feb 27, 2013 at 06:38:55PM -0300, Cláudio Sampaio wrote:
> Is there any device with Aarch64 on sale? I couldn't find any, only some
> mentions from Calxeda.
> Would you mind to provide suggestions of any seller which sells through the
> internet?
There are none for sale yet. I believe som
On Tue, Feb 26, 2013 at 11:10 PM, Wookey wrote:
> State of the Debian/Ubuntu arm64 port
> =
>
> *** Arm64 lives! ***
>
Hi,
Is there any device with Aarch64 on sale? I couldn't find any, only some
mentions from Calxeda.
Would you mind to
a little bit ahead of myself anyway --
I'm working on aarch64 guest support for Xen at the minute and your mail
prompted me to wonder how hard it would be to build the Xen tools for
arm64 in a multiarch environment, to some extent the toolchain is the
least of my worries ;-).
Ian.
--
Ian Cam
+++ Ian Campbell [2013-02-27 12:00 +]:
> On Wed, 2013-02-27 at 02:10 +, Wookey wrote:
> >
> > Setting up an arm64 build environment is very simple. Use
> > sbuild-createchroot or mk-sbuild
> > and point at the bootstrap repo, with a bit of config and some updat
On Wed, 2013-02-27 at 02:10 +, Wookey wrote:
>
> Setting up an arm64 build environment is very simple. Use sbuild-createchroot
> or mk-sbuild
> and point at the bootstrap repo, with a bit of config and some updated tools
> packages from
> the repo (amd64 only supplied). De
W dniu 27.02.2013 03:10, Wookey pisze:
> State of the Debian/Ubuntu arm64 port
> =
>
> *** Arm64 lives! ***
Congratulations Wookey (and everyone involved)!
> * There is now a bootable (raring) image to download and run
> Once you&#x
On 27 February 2013 04:10, Wookey wrote:
> State of the Debian/Ubuntu arm64 port
> =
>
> *** Arm64 lives! ***
Awesome work Wookey!
> Executive summary
> -
>
> * There is now a bootable (raring) image to download and
State of the Debian/Ubuntu arm64 port
=
*** Arm64 lives! ***
Executive summary
-
* There is now a bootable (raring) image to download and run
* Everything has been rebuilt against glibc 2.17 so it works
* A bit more work is needed to make
Hi Tixy,
On Wed, Jan 09, 2013 at 05:04:38PM +, Jon Medhurst (Tixy) wrote:
> Patch 25c92a37a (arm64: Always select ARM_AMBA and GENERIC_GPIO)
> expects platforms to have GPIO so we need to make sure vexpress
> always has this by selecting ARCH_REQUIRE_GPIOLIB.
>
> Without this
On 01/08/2013 04:08 AM, Peter Maydell wrote:
> The translator sources (as and when we implement a
> TCG QEMU target for this) should live under the existing target-arm.
Of this I'm not certain, given that A64 is different enough from A32
to warrant a brand new gcc backend. I havn't tried to rever
Patch 25c92a37a (arm64: Always select ARM_AMBA and GENERIC_GPIO)
expects platforms to have GPIO so we need to make sure vexpress
always has this by selecting ARCH_REQUIRE_GPIOLIB.
Without this change drivers like MMC fail to compile due to missing
gpio definitions like:
In file included from
On 8 January 2013 15:57, Richard Henderson wrote:
> On 01/08/2013 04:08 AM, Peter Maydell wrote:
>> The translator sources (as and when we implement a
>> TCG QEMU target for this) should live under the existing target-arm.
>
> Of this I'm not certain, given that A64 is different enough from A32
>
We should be able to configure QEMU for cross compiling it for ARM64 host.
This patch only tries to make sure that the configure step falls through
and atleast QEMU cross-compilation starts.
The rationale behind cpu=aarch64 naming (as commented by Peter Maydell):
For the target architecture
On 8 January 2013 12:24, Anup Patel wrote:
> On 8 January 2013 17:38, Peter Maydell wrote:
>> Also, I suspect this isn't the only thing that will be required.
> Yes. This patch only tries to make sure that the configure step falls
> through and at-least QEMU cross-compilation starts.
It's gener
> >fi
> > elif check_define __arm__ ; then
> >cpu="arm"
> > +elif check_define __aarch64__ ; then
> > + cpu="arm64"
>
> This should be "aarch64"...
>
> > elif check_define __hppa__ ; then
> >cpu="hpp
;
> +elif check_define __aarch64__ ; then
> + cpu="arm64"
This should be "aarch64"...
> elif check_define __hppa__ ; then
>cpu="hppa"
> else
> @@ -388,6 +390,9 @@ case "$cpu" in
>armv*b|armv*l|arm)
> cpu=&quo
W dniu 08.01.2013 12:05, Anup Patel pisze:
> We should be able to cross compile QEMU for ARM64 host.
>
> This is required for trying out ARM 32-bit guest on ARM64 host using QEMU +
> KVM ARM64.
Which version you got built with this patch? 1.3.0 f
We should be able to cross compile QEMU for ARM64 host.
This is required for trying out ARM 32-bit guest on ARM64 host using QEMU + KVM
ARM64.
Signed-off-by: Anup Patel
---
configure |5 +
1 file changed, 5 insertions(+)
diff --git a/configure b/configure
index fe18ed2..0bfb8bb
[I already replied to this in private, but as other may have similar
problems, I'll make my answers public]
On 04/01/13 11:06, Anup Patel wrote:
> Hi Marc,
>
> We tried kvm-arm64/soc-armv8-kvm branch from your git tree on v8
> Foundation Model but we dont get any prints o
Hi Marc,
We tried kvm-arm64/soc-armv8-kvm branch from your git tree on v8 Foundation
Model but we dont get any prints on serial terminal.
We followed the step mentioned in
https://wiki.linaro.org/HowTo/BuildArm64Kernel except:
1. We used kernel compiled from kvm-arm64/soc-armv8-kvm branche from
73 matches
Mail list logo
