On Sun, Oct 28, 2018 at 05:01:05PM +, Steve McIntyre wrote:
>...
> Hardware setup: I've configured the earlier 3 as buildds in little 1U
> cases with 32GiB RAM and mirrored SSDs, but for $reasons they're not
> yet installed and running. I'm assuming that a similar spec would be
> wanted for aut
On Sun, Oct 28, 2018 at 05:01:05PM +, Steve McIntyre wrote:
> I now have 3 more basic Synquacer machines in my posession, ready to
> order new cases, RAM, etc. (They ship in desktop cases with a single
> 1TB hard drive and 4 GiB of RAM.) Again, I'm hoping to pick more up in
> the future, but su
On Sun, Oct 28, 2018 at 05:01:05PM +, Steve McIntyre wrote:
> >On 20-09-18 10:24, Steve McIntyre wrote:
> >> * I'm expecting to pick up several Synquacer machines (24-core Cortex
> >>A53) to use for Debian, donated by Linaro. Some will become
> >>buildds, wanting to get more to use for
>On 20-09-18 10:24, Steve McIntyre wrote:
>> * I'm expecting to pick up several Synquacer machines (24-core Cortex
>>A53) to use for Debian, donated by Linaro. Some will become
>>buildds, wanting to get more to use for autopkgtest, debian-ci,
>>reproducible builds etc. [UPDATE: 3 of th
On Thu, Sep 20, 2018 at 09:49:45PM +0200, Paul Gevers wrote:
>Hi Steve,
>
>On 20-09-18 10:24, Steve McIntyre wrote:
>> * I'm expecting to pick up several Synquacer machines (24-core Cortex
>>A53) to use for Debian, donated by Linaro. Some will become
>>buildds, wanting to get more to use f
Hi Steve,
On 20-09-18 10:24, Steve McIntyre wrote:
> * I'm expecting to pick up several Synquacer machines (24-core Cortex
>A53) to use for Debian, donated by Linaro. Some will become
>buildds, wanting to get more to use for autopkgtest, debian-ci,
>reproducible builds etc. [UPDATE: 3
[ Please note the cross-post and Reply-To ]
Hi folks,
As promised, here's a quick summary of what was discussed at the Arm
ports BoF session in Hsinchu. Apologies for the delay in posting...
Thanks to the awesome efforts of our video team, the session is
already online [1]. I've taken
spoke again to TL and asked if pine64 would be willing to look at
sponsorship witn rockpro64 boards (the ones that take 4x PCIe): if
someone from debian were to contact him direct he would happily
consider it.
i then asked him if i could cc him into this discussion and he said he
was way *way* too
On Fri, Jun 29, 2018 at 8:13 PM, Luke Kenneth Casson Leighton
wrote:
> On Fri, Jun 29, 2018 at 6:59 PM, Jonathan Wiltshire wrote:
>
>>> also worth noting, they're working on a 2U rackmount server which
>>> will have i think something insane like 48 Rock64Pro boards in one
>>> full-length case.
>
---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
On Fri, Jun 29, 2018 at 8:31 PM, Florian Weimer wrote:
> * Luke Kenneth Casson Leighton:
>
>> that is not a surprise to hear: the massive thrashing caused by the
>> linker phase not being possible to be RAM-resident wil
* Luke Kenneth Casson Leighton:
> that is not a surprise to hear: the massive thrashing caused by the
> linker phase not being possible to be RAM-resident will be absolutely
> hammering the drives beyond reasonable wear-and-tear limits. which is
> why i'm recommending people try "-Wl,--no-keep-m
On Fri, Jun 29, 2018 at 6:59 PM, Jonathan Wiltshire wrote:
>> also worth noting, they're working on a 2U rackmount server which
>> will have i think something insane like 48 Rock64Pro boards in one
>> full-length case.
> None of this addresses the basic DSA requirement of remote management.
> T
On Fri, Jun 29, 2018 at 06:05:55PM +0100, Luke Kenneth Casson Leighton wrote:
> apologies for repeating it again: this is why i'm recommending people
> try "-Wl,--no-keep-memory" on the linker phase as if it works as
> intended it will almost certainly drastically reduce memory usage to
> the poin
On Fri, Jun 29, 2018 at 5:21 PM, Steve McIntyre wrote:
>>2G is also way too little memory these days for a new buildd.
>
> Nod - lots of packages are just too big for that now.
apologies for repeating it again: this is why i'm recommending people
try "-Wl,--no-keep-memory" on the linker phase a
;
>Rackable, while good, is only part of it. The main part is remote
>management. I'm not seeing any mention of ipmi or anything like that in
>the datasheet?
>
>2G is also way too little memory these days for a new buildd.
Nod - lots of packages are just too big for that now.
On Mon, Sep 18, 2017 at 10:50:39AM +0100, Ian Campbell wrote:
> On Mon, 2017-09-18 at 10:15 +0100, Edmund Grimley Evans wrote:
> > > But it did remind me that on some platforms writing "2" to
> > > /proc/sys/abi/cp15_barrier will enable hw support for these
> > > instructions, since some platforms
On Mon, 2017-09-18 at 10:15 +0100, Edmund Grimley Evans wrote:
> > But it did remind me that on some platforms writing "2" to
> > /proc/sys/abi/cp15_barrier will enable hw support for these
> > instructions, since some platforms do support them even thought
> > they
> > are deprecated. It's certain
> But it did remind me that on some platforms writing "2" to
> /proc/sys/abi/cp15_barrier will enable hw support for these
> instructions, since some platforms do support them even thought they
> are deprecated. It's certainly worth investigating what your hardware
> supports.
Not necessarily disa
On Sun, 2017-09-17 at 12:59 -0700, Vagrant Cascadian wrote:
> On 2017-09-15, Ben Hutchings wrote:
> > On Thu, 2017-09-14 at 03:40 +0100, Steve McIntyre wrote:
> > [...]
> >> There is optional kernel support to trap the exceptions here
> >> and emulate the instructions, but it's really not recommend
On Sun, 2017-09-17 at 21:30 +0100, Colin Watson wrote:
> On Sun, Sep 17, 2017 at 12:59:04PM -0700, Vagrant Cascadian wrote:
> > On 2017-09-15, Ben Hutchings wrote:
> > > On Thu, 2017-09-14 at 03:40 +0100, Steve McIntyre wrote:
> > > [...]
> > > > There is optional kernel support to trap the excepti
On Fri, Sep 15, 2017 at 07:11:38PM +0100, Ben Hutchings wrote:
>On Thu, 2017-09-14 at 03:40 +0100, Steve McIntyre wrote:
>[...]
>> There is optional kernel support to trap the exceptions here
>> and emulate the instructions, but it's really not recommended for
>> serious use (e.g. on a build machin
On Sun, 2017-09-17 at 12:59 -0700, Vagrant Cascadian wrote:
> On 2017-09-15, Ben Hutchings wrote:
> > On Thu, 2017-09-14 at 03:40 +0100, Steve McIntyre wrote:
> > [...]
> > > There is optional kernel support to trap the exceptions here
> > > and emulate the instructions, but it's really not recomme
On Sun, Sep 17, 2017 at 12:59:04PM -0700, Vagrant Cascadian wrote:
> On 2017-09-15, Ben Hutchings wrote:
> > On Thu, 2017-09-14 at 03:40 +0100, Steve McIntyre wrote:
> > [...]
> >> There is optional kernel support to trap the exceptions here
> >> and emulate the instructions, but it's really not re
On 2017-09-15, Ben Hutchings wrote:
> On Thu, 2017-09-14 at 03:40 +0100, Steve McIntyre wrote:
> [...]
>> There is optional kernel support to trap the exceptions here
>> and emulate the instructions, but it's really not recommended for
>> serious use (e.g. on a build machine!).
> [...]
>
> Why is i
On 2017-09-14 12:58 +0800, Paul Wise wrote:
> Wookey, could you add something about the motivation for arm64ilp32 to
> the wiki page about it?
Will do. But the short version is that it's only useful if you need to
run 32-bit code on hardware that only supports the 64-bit execution
mode. Such hardw
On Thu, 2017-09-14 at 03:40 +0100, Steve McIntyre wrote:
[...]
> There is optional kernel support to trap the exceptions here
> and emulate the instructions, but it's really not recommended for
> serious use (e.g. on a build machine!).
[...]
Why is it not recommended? Terrible performance, or kno
On Thu, Sep 14, 2017 at 12:06:13PM +0200, Marco d'Itri wrote:
>On Sep 14, Steve McIntyre wrote:
>
>> The Pine64 [6] is another alternative, based on a mobile CPU. It's
>> therefore got limited RAM and I/O. Upstreaming has taken a while, but
>> is getting there in current kernel releases. U-Boot he
nnel and tell doko you are there to
>support armel.
+1
>Improve the wiki page for armel, move it under the Ports hierarchy and
>base it off the port template:
>
>https://wiki.debian.org/ArmEabiPort
>https://wiki.debian.org/Ports
>https://wiki.debian.org/PortTemplate
>
&
On Sep 14, Steve McIntyre wrote:
> The Pine64 [6] is another alternative, based on a mobile CPU. It's
> therefore got limited RAM and I/O. Upstreaming has taken a while, but
> is getting there in current kernel releases. U-Boot head will work on
> the board, including the UEFI implementation ment
source package for anything other than virtual
machines (x86/ARMv7/ARMv8). It seems to me that u-boot is in a much
better position wrt upstream support for ARM *and* for support for
UEFI than TianoCore or other options that aren't in Debian like
coreboot.
> Hector asked about the current st
[ Please note the cross-post and Reply-To ]
Hi folks,
As promised, here's a quick summary of what was discussed at the Arm
ports BoF session in Montréal. Apologies for the delay in posting...
Thanks to the awesome efforts of our video team, the session is
already online [1]. I've ta
On 2017-09-03 01:14, John Paul Adrian Glaubitz wrote:
> * there are enough crazy people with too much time like Adrian,
>Roger and me who are willing to fix stuff
This reminds me of something: Thanks to all of you!
> So, currently all is good with armel and we can go back to
> discussing how
On 09/02/2017 11:44 PM, W. Martin Borgert wrote:
> Right, most RPi users run Raspbian, but there are also people
> - like me :~) - who prefer to run "pure" Debian, even at the
> cost of a performance penalty (in case of RPi 1 or Zero).
> I imagine, you know (and share) reasons to prefer Debian.
Ye
On 2017-08-28 11:19, John Paul Adrian Glaubitz wrote:
> Aren't most RPi users running Raspian anyway which is armhf with -march
> set to ARMv6?
Right, most RPi users run Raspbian, but there are also people
- like me :~) - who prefer to run "pure" Debian, even at the
cost of a performance penalty (
On Fri, 2017-09-01 at 19:27 +0300, Adrian Bunk wrote:
> [...]
>
> What matters for buster is gcc 8, and there is no current deprecation
> in gcc that would affect the armel port.
Thanks for all the info!
> armel is a port on borrowed time since it supports old hardware
> no longer supported else
On Mon, Aug 28, 2017 at 06:57:40PM +0100, Ian Campbell wrote:
> On Mon, 2017-08-28 at 06:53 +0800, Paul Wise wrote:
> > On Sun, Aug 27, 2017 at 9:49 PM, Roger Shimizu wrote:
> >
> > > However, I think armel is time to transit to v5.
> >
> > As someone who can no longer run Debian stable on his MI
On Mon, Aug 28, 2017 at 06:53:54AM +0800, Paul Wise wrote:
>...
> OTOH the
> only relevant hardware for armel these days seems to be RPi, so why
> not make armel into armhfv6 instead?
Incompatible ABI, your suggestion to move Raspbian as armhfv6
into Debian would therefore have to be a new port.
On Monday, 28 August 2017 16:23:24 BST W. Martin Borgert wrote:
> Quoting uhmgawa :
> > On 08/28/2017 08:46 AM, W. Martin Borgert wrote:
> >> As long as you have enough flash memory (some hundreds of MiB) and RAM
> >> (at least 64 MiB, better 128 MiB), Debian runs fine on such hardware
> >> in my e
On 08/28/2017 10:11 PM, W. Martin Borgert wrote:
> This depends on the build process: In my case we build in a
> clean environment with all build dependencies pre-installed.
> Remember, this is not a generic Debian build process, but a
> specialised one for certain packages.
I'm pretty sure the st
On 2017-08-28 19:16, John Paul Adrian Glaubitz wrote:
> On 08/28/2017 06:30 PM, W. Martin Borgert wrote:
> > But my experience is quiet good with this:
> >
> > ARCH=arm CROSS_COMPILE=/usr/bin/arm-linux-gnueabi- dpkg-buildpackage
> > -rfakeroot -aarmel ...
> >
> > I don't remember what the ARCH var
On 08/28/2017 07:57 PM, Ian Campbell wrote:
>> As someone who can no longer run Debian stable on his MIPS device due
>> to the CPU requirements bump in stretch, I'm not sure that bumping
>> CPU
>> requirements is a good idea in general. If there are actual benefits
>> to v5 as the default then bump
On Mon, 2017-08-28 at 06:53 +0800, Paul Wise wrote:
> On Sun, Aug 27, 2017 at 9:49 PM, Roger Shimizu wrote:
>
> > However, I think armel is time to transit to v5.
>
> As someone who can no longer run Debian stable on his MIPS device due
> to the CPU requirements bump in stretch, I'm not sure that
On 08/28/2017 06:30 PM, W. Martin Borgert wrote:
> AFAIK, there is no policy requiring that packages can be cross-build.
We are working on something like that, but it's a larger goal. Basically,
we're planning to have cross-buildds which will additionally test packages
for cross-buidability.
One
Quoting uhmgawa :
We've done so for Jessie, but it is a rather tedious manual process
and one which
starts eroding the benefit of project soak on a supported
installation footprint.
A relief I didn't call out previously is these figures are physical
sizes. We can shoe
horn in considerably m
On 08/28/2017 10:23 AM, W. Martin Borgert wrote:
> Quoting uhmgawa :
>> On 08/28/2017 08:46 AM, W. Martin Borgert wrote:
>>> As long as you have enough flash memory (some hundreds of MiB) and RAM
>>> (at least 64 MiB, better 128 MiB), Debian runs fine on such hardware
>>> in my experience. It depen
Quoting uhmgawa :
On 08/28/2017 08:46 AM, W. Martin Borgert wrote:
As long as you have enough flash memory (some hundreds of MiB) and RAM
(at least 64 MiB, better 128 MiB), Debian runs fine on such hardware
in my experience. It depends on your applications, of course.
Available flash is from 3
On 08/28/2017 08:46 AM, W. Martin Borgert wrote:
> Quoting uhmgawa :
>> We probably should be leveraging a cross built embedded class distro which
>> would place us in that mainstream and solve many of our logistical problems.
>
> As long as you have enough flash memory (some hundreds of MiB) and R
Quoting uhmgawa :
We probably should be leveraging a cross built embedded class distro which
would place us in that mainstream and solve many of our logistical problems.
As long as you have enough flash memory (some hundreds of MiB) and RAM
(at least 64 MiB, better 128 MiB), Debian runs fine on
On 08/27/2017 07:36 PM, W. Martin Borgert wrote:
> On 2017-08-28 06:53, Paul Wise wrote:
>> On Sun, Aug 27, 2017 at 9:49 PM, Roger Shimizu wrote:
>>
>>> However, I think armel is time to transit to v5.
>> As someone who can no longer run Debian stable on his MIPS device due
>> to the CPU requiremen
On 28/08/17 09:30, John Paul Adrian Glaubitz wrote:
On 08/28/2017 12:53 AM, Paul Wise wrote:
OTOH the only relevant hardware for armel these days seems
to be RPi, so why not make armel into armhfv6 instead?
Aren't most RPi users running Raspian anyway which is armhf with -march
set to ARMv6? B
On 08/28/2017 12:53 AM, Paul Wise wrote:
> OTOH the only relevant hardware for armel these days seems
> to be RPi, so why not make armel into armhfv6 instead?
Aren't most RPi users running Raspian anyway which is armhf with -march
set to ARMv6? Bumping armel from soft-fp to ARMv6 hard-fp doesn't s
On 2017-08-28 06:53, Paul Wise wrote:
> On Sun, Aug 27, 2017 at 9:49 PM, Roger Shimizu wrote:
>
> > However, I think armel is time to transit to v5.
>
> As someone who can no longer run Debian stable on his MIPS device due
> to the CPU requirements bump in stretch, I'm not sure that bumping CPU
> r
On Sun, Aug 27, 2017 at 9:49 PM, Roger Shimizu wrote:
> However, I think armel is time to transit to v5.
As someone who can no longer run Debian stable on his MIPS device due
to the CPU requirements bump in stretch, I'm not sure that bumping CPU
requirements is a good idea in general. If there ar
On Fri, Aug 18, 2017 at 5:22 AM, John Paul Adrian Glaubitz
wrote:
> On 08/17/2017 08:49 PM, Philippe Clérié wrote:
>> If none of the curent armel porters want to continue working on armel
>> for buster that is OK, but dropping armel from testing now would result
>> in additional work later for re-
Hi,
On Fri, Aug 11, 2017 at 03:04:26PM +0300, Adrian Bunk wrote:
> With plenty of v6 Raspberry Pi Zero still being sold today there's
> plenty of new v6 hardware available, and Debian should continue to
> offer an own root filesystem for such hardware.
+1
> Regarding the point that v4 is no lon
On 08/17/2017 08:49 PM, Philippe Clérié wrote:
> If none of the curent armel porters want to continue working on armel
> for buster that is OK, but dropping armel from testing now would result
> in additional work later for re-adding it.
Roger Shimizu and me are interested in keeping this port as
GOn 08/11/2017 08:04 AM, Adrian Bunk wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Hi,
since I am not in Montréal, I am sending my participation by email:
Since Debian dropping popular ports is nothing I consider good for
Debian, I hereby step up as armel porter for buster.
If none o
On 2017-08-11 15:04 +0300, Adrian Bunk wrote:
> If none of the curent armel porters want to continue working on armel
> for buster that is OK,
I still have v5 hardware running my house and thus am keen to see it
maintained. And it's not simple to upgrade to a new box as it's got
heating-control h
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Hi,
since I am not in Montréal, I am sending my participation by email:
Since Debian dropping popular ports is nothing I consider good for
Debian, I hereby step up as armel porter for buster.
If none of the curent armel porters want to continue w
[ Sorry, that fell off screen ]
Roger Shimizu wrote...
> [CC Vagrant, u-boot pkg maintainer]
>
> On Sat, Dec 10, 2016 at 11:31 PM, Christoph Biedl
> wrote:
> > Paul Wise wrote...
> >>
> >> Is it possible to put a bootloader like u-boot in the flash partitions
> >> and have it load the Linux ker
Lennart Sorensen wrote...
> I actually highly doubt there are that many armv7 boxes running armel.
> armhf was a nice performance improvement and worth the hassle to reinstall
> if you had such a box in the first place. I think most armel systems
> are probably armv5, often the marvell chips. No
On Sat, Dec 17, 2016 at 08:15:15PM +0800, Paul Wise wrote:
> On Sat, 2016-12-17 at 09:45 +0100, Wouter Verhelst wrote:
>
> > Yes, but that still says:
>
> Ack.
>
> > I think a proper procedure should involve a script that:
> >
> > - is packaged in Debian;
>
> Ack.
>
> > - checks whether the h
On Sun, Dec 18, 2016 at 11:22 PM, Roger Shimizu wrote:
> Is there any way to simplify?
Remove the obsolete armel binaries where they occur and then mark the
packages as NFU on armel:
https://wiki.debian.org/ftpmaster_Removals
https://wiki.debian.org/PackagesArchSpecific
--
bye,
pabs
https://w
On Sat, Dec 10, 2016 at 12:22 PM, Wookey wrote:
>
> We can do poor-mans partial arch by just being fairly agressive about
> disabling armel for packages that are broken or not suitable. Not very
> clever or efficient, but it is easy to do and requires no infra or
> tooling changes at all. So long
On Sat, 2016-12-17 at 09:45 +0100, Wouter Verhelst wrote:
> Yes, but that still says:
Ack.
> I think a proper procedure should involve a script that:
>
> - is packaged in Debian;
Ack.
> - checks whether the hardware it's running on has all the hardware
> requirements for the new architectur
On Thu, Dec 15, 2016 at 11:19:34AM +0800, Paul Wise wrote:
> On Thu, Dec 15, 2016 at 1:40 AM, Wouter Verhelst wrote:
>
> > One way in which the need to keep armel around would be reduced is if we
> > could somehow upgrade from armel machines to armhf ones, without
> > requiring a reinstall.
>
> T
On 2016-12-16, Roger Shimizu wrote:
> On Sat, Dec 10, 2016 at 11:31 PM, Christoph Biedl
> wrote:
>>> Is it possible to put a bootloader like u-boot in the flash partitions
>>> and have it load the Linux kernel and initrd from elsewhere?
There's no technical reason this wouldn't be possible, just
[CC Vagrant, u-boot pkg maintainer]
On Sat, Dec 10, 2016 at 11:31 PM, Christoph Biedl
wrote:
> Paul Wise wrote...
>>
>> Is it possible to put a bootloader like u-boot in the flash partitions
>> and have it load the Linux kernel and initrd from elsewhere?
>
> That how I've been running my Dockstar
On Thu, Dec 15, 2016 at 1:40 AM, Wouter Verhelst wrote:
> One way in which the need to keep armel around would be reduced is if we
> could somehow upgrade from armel machines to armhf ones, without
> requiring a reinstall.
There is a script for that here:
https://wiki.debian.org/CrossGrading
--
On Wed, Dec 07, 2016 at 08:50:40PM +0900, Roger Shimizu wrote:
[...asking for armel to be retained...]
One way in which the need to keep armel around would be reduced is if we
could somehow upgrade from armel machines to armhf ones, without
requiring a reinstall.
After all, armel has been around
On Wed, Dec 14, 2016 at 06:40:22PM +0100, Wouter Verhelst wrote:
> On Wed, Dec 07, 2016 at 08:50:40PM +0900, Roger Shimizu wrote:
> [...asking for armel to be retained...]
>
> One way in which the need to keep armel around would be reduced is if we
> could somehow upgrade from armel machines to ar
On Wed, Dec 07, 2016 at 03:53:31PM +, Steve McIntyre wrote:
> AFAIK there are potentially still similar problems with ARMv5 - lack
> of architcture-defined barrier primitives for C++11 atomics to
> work. (I'd love to be corrected on this if people know better!) This
> is one of the key points h
2016-12-09 0:12 GMT+02:00 Christoph Biedl :
> Same here. My Dockstars (orion5x/kirkwood) still work like a charm and
> it gives a bad feeling having to trash them some day just because
> there's no support any more.
>
> On the other hand, they face another problem I guess is typical for
> that gene
On 2016-12-07 15:53 +, Steve McIntyre wrote:
> On Wed, Dec 07, 2016 at 08:50:40PM +0900, Roger Shimizu wrote:
> >I'm ARM porter on armel/marvell (orion5x/kirkwood).
> >Stretch will be frozen and released soon, which makes me bit depressed,
> >because it means armel will be dropped out of unst
On Fri, 2016-12-09 at 22:14 +0900, Roger Shimizu wrote:
> On Fri, 09 Dec 2016 00:53:17 +
> > Ben Hutchings wrote:
>
> > Also, dedicated tiny flash partitions for the kernel and initrd. I
> > wouldn't be surprised to be find that by the time we want to release
> > buster we can't build a usef
On Fri, 09 Dec 2016 00:53:17 +
Ben Hutchings wrote:
> Also, dedicated tiny flash partitions for the kernel and initrd. I
> wouldn't be surprised to be find that by the time we want to release
> buster we can't build a useful kernel that fits into the 2 MB partition
> that most of these devic
Roger Shimizu wrote...
> I'm ARM porter on armel/marvell (orion5x/kirkwood).
> Stretch will be frozen and released soon, which makes me bit depressed,
> because it means armel will be dropped out of unstable/testing as the
> conclusion of Cape Town BoF.
Same here. My Dockstars (orion5x/kirkwood
x27;s a quick summary of what was discussed at the ARM
>> ports BoF session in Cape Town.
>
>Thanks for the summary!
>
>I'm ARM porter on armel/marvell (orion5x/kirkwood).
>Stretch will be frozen and released soon, which makes me bit depressed,
>because it means armel will
[ intentionally keep d-d CCed ]
On Fri, 22 Jul 2016 02:36:05 +0100
Steve McIntyre wrote:
> [ Please note the cross-post and Reply-To ]
>
> Hi folks,
>
> As promised, here's a quick summary of what was discussed at the ARM
> ports BoF session in Cape Town.
Thanks fo
On Thu, Aug 11, 2016 at 11:47:12AM +, Riku Voipio wrote:
>On Fri, Jul 22, 2016 at 02:36:05AM +0100, Steve McIntyre wrote:
>> armhf
>> =
>> Current port, first released with Wheezy. Due to cross-distro effort,
>> this setup (ARMv7 EABI using VFPv3D-16) is the default supported
>> 32-bit ARM
On Fri, Jul 22, 2016 at 02:36:05AM +0100, Steve McIntyre wrote:
> armhf
> =
> Current port, first released with Wheezy. Due to cross-distro effort,
> this setup (ARMv7 EABI using VFPv3D-16) is the default supported
> 32-bit ARM architecture in all distros now. We've got a couple of
> kernel var
On 2016-07-27 00:53 -0400, Jeffrey Walton wrote:
> >> The Mustang board is a nice test platform because its an early ARMv8
> >> board. While its ARMv8, it lacks CRC and Crypto extensions.
> >
> > That's interesting. Having almost given up on any AMD ARM
> > hardware ever appearing, I've been consi
>> The Mustang board is a nice test platform because its an early ARMv8
>> board. While its ARMv8, it lacks CRC and Crypto extensions.
>
> That's interesting. Having almost given up on any AMD ARM
> hardware ever appearing, I've been considering getting a
> Gigabyte MP30-AR0 (which I thought for a
On 2016-07-22, Steve McIntyre wrote:
> is the lack of direct support for C++11 atomics - it's possible to use
> a kernel helper to cover for this lack, but performance will be
> terrible.
This is going to be a real problem for Qt in the very near future. A
requirement for qt 5.7 is a c++11 compli
On 2016-07-23 18:46 +, Phil Endecott wrote:
> > > Affordable, usable machines are available now, e.g. the Cello
>
> Is the Cello actually available? 96boards is still saying "pre-order".
I have seen one, but that was '1st batch'. I don't know current
status, but yes I guess it's still under
> > Affordable, usable machines are available now, e.g. the Cello
Is the Cello actually available? 96boards is still saying "pre-order".
> There are three other ARM64 gadgets worth mentioning...
And the ODROID-C2. (Can someone add that to the list at
https://wiki.debian.org/Arm64Port#Hardwar
On Fri, Jul 22, 2016 at 9:36 AM, Steve McIntyre wrote:
> armel
> =
>
> armel is the longest-running of our current ARM ports in Debian,
> starting in 2007. It's starting to become difficult to support. Debian
> is the only common distro still supporting ARMv4t.
I n
On 22/07/16 02:36, Steve McIntyre wrote:
Affordable, usable machines are available now, e.g. the Cello
Does anyone know what is going on with this. Have boards actually
started shipping?
W dniu 22.07.2016 o 04:02, Jeffrey Walton pisze:
There are three other ARM64 gadgets worth mentioning...
* Raspberry Pi 3 Model B (http://www.amazon.com/dp/B01CD5VC92), $38 USD
This device has armv8 core but no support for running Linux in 64-bit mode.
The Mustang board is a nice test pla
> arm64
> =
>
> Most recent ARM port. All looking good now - we've been mostly able to
> move on from Juno development platforms to real server hardware
> now. We're using some APM Mustang machines and an AMD Seattle box
> hosted by ARM and Linaro at the moment, and even real arm64 server
> mac
[ Please note the cross-post and Reply-To ]
Hi folks,
As promised, here's a quick summary of what was discussed at the ARM
ports BoF session in Cape Town.
This year, unfortunately the session did not have video so I can't
link to it. I've taken a copy of the Gobby notes f
- Forwarded message from cont...@debconf.org -
From: cont...@debconf.org
Date: Wed, 22 Jun 2016 20:47:07 -
To: 93...@debian.org
Subject: DebConf - talk scheduled: Arm Ports BoF
X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on cheddar.halon.org.uk
X-Spam-Level:
X-Spam-Status
On Wed, Sep 16, 2015 at 9:02 PM, Christoph Biedl wrote:
> So add me to your list. I run four Seagate DockStar (v5) and two
> Raspberry Pi (v6, first generation). Although bout the latter, I was
> hoping for a "arm6hf" port and used armel until then. But with more
> recent Pi models AFAIK being arm
Steve McIntyre wrote...
> First released with Lenny, supports ARMv4t & later. QNAS etc. kirkwood
> & some freedombox. Toolchain and kernel support upstream are probably
> never going away due to the massive number of simple ARM devices still
> being made and shipped, however...
Quite recently I s
On September 14, 2015 12:45:03 PM GMT+02:00, JM wrote:
>On Fri, Sep 11, 2015 at 5:58 PM, Steve McIntyre
>wrote:
>>
>> Summary: if people care about armel for Stretch, they should make
>> noise NOW and convince people it's needed and can/should be supported
>> in future.
>>
>
>I'm running Debian o
This is microATX with 2 Gbe, 210Gbe and 4 SATA III ports. :
http://www.eteknix.com/latest-gigabyte-microatx-motherboard-arrives-with-octo-core-armv8-soc/
which is actually on-sale:
http://www.ldlc.com/fiche/PB00191584.html
But it's server kit so it's 950 EUR.
Wookey
Good to know that there
On Mon, 2015-09-14 at 15:31 +0200, Paul Wise wrote:
> On Mon, Sep 14, 2015 at 2:29 PM, Lucy Wayland wrote:
> > On Sat, Sep 12, 2015 at 03:55:38PM +0100, Ian Campbell wrote:
> > > On Fri, 2015-09-11 at 16:58 +0100, Steve McIntyre wrote:
> > > Does this issue go away entirely if we move from a v4t to
> SWP and SWPB - these were deprecated in ARMv7 but absent in ARMv8.
If I am not mistaken, these were deprecated in ARMv6 already, and they
are optional in ARMv7:
http://www.google.com/search?q=swp+swpb+armv6+armv7
The QNAP things that people seem keen not to lose support for are ARMv5TE.
+++ Paul Wise [2015-09-14 15:31 +0200]:
> On Mon, Sep 14, 2015 at 2:29 PM, Lucy Wayland wrote:
> > On Sat, Sep 12, 2015 at 03:55:38PM +0100, Ian Campbell wrote:
> >> On Fri, 2015-09-11 at 16:58 +0100, Steve McIntyre wrote:
> >> Does this issue go away entirely if we move from a v4t to v5 base, or
>
On Mon, Sep 14, 2015 at 2:29 PM, Lucy Wayland wrote:
> On Sat, Sep 12, 2015 at 03:55:38PM +0100, Ian Campbell wrote:
>> On Fri, 2015-09-11 at 16:58 +0100, Steve McIntyre wrote:
>> Does this issue go away entirely if we move from a v4t to v5 base, or
>> are there also v5 instructions which are (pote
1 - 100 of 116 matches
Mail list logo