Re: arm64 pointer tagging, VA-bits, the end of the world...

2016-08-17 Thread peter green
On 17/08/16 17:06, Leif Lindholm wrote: Indeed. And we need to stay on the ball with that, and try to ensure any changes we do from this point onwards are at least 56-bit safe. And start agitating against pointer tagging in general. AIUI a big problem is that some systems (in particular

Re: arm64 pointer tagging, VA-bits, the end of the world...

2016-08-17 Thread Alexander Graf
> Am 17.08.2016 um 16:58 schrieb Jeremy Linton : > > Hi, > >> On 08/17/2016 09:51 AM, Koen Kooi wrote: >> >>> Op 17 aug. 2016, om 16:39 heeft Leif Lindholm >>> het volgende geschreven: >>> >>> Hi all, >>> >>> (Sent to cross-distro with

Re: Porter roll call for Debian Stretch

2016-08-17 Thread Kurt Roeckx
On Wed, Aug 17, 2016 at 10:05:06PM +0200, ni...@thykier.net wrote: > * If we were to enable -fPIE/-pie by default in GCC-6, should that change >also apply to this port? [0] If -fPIE is the default will -fPIC override it? It will also default to tell the linker to use -pie, but then don't do

Re: Which port for armv4l?

2016-08-17 Thread peter green
On 17/08/16 10:19, Adam Wysocki wrote: Is it possible for a compiler to generate BX instructions without Thumb code (for example to return from a function with bx lr, where lr will always be even - no Thumb)? Correct me if I'm wrong, but I thought that BX patch (to emulate BX instruction in

Re: Porter roll call for Debian Stretch

2016-08-17 Thread Niels Thykier
Martin Michlmayr: > * ni...@thykier.net [2016-08-17 22:05]: >> 2020), please respond with a signed email containing the following >> before Friday, the 9th of September: > > Can you please specify where to respond to? I don't think dozens of > emails to -ports and -devel make

Re: arm64 pointer tagging, VA-bits, the end of the world...

2016-08-17 Thread Alexander Graf
> On 17 Aug 2016, at 16:51, Koen Kooi wrote: > > >> Op 17 aug. 2016, om 16:39 heeft Leif Lindholm het >> volgende geschreven: >> >> Hi all, >> >> (Sent to cross-distro with debian-arm on cc.) >> >> We have an 'interesting' situation

Re: Porter roll call for Debian Stretch

2016-08-17 Thread Martin Michlmayr
* ni...@thykier.net [2016-08-17 22:05]: > 2020), please respond with a signed email containing the following > before Friday, the 9th of September: Can you please specify where to respond to? I don't think dozens of emails to -ports and -devel make any sense. Maybe

Porter roll call for Debian Stretch

2016-08-17 Thread niels
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi, Like last release, we are doing a roll call for porters of all release architectures. If you are an active porter behind one of the [release architectures] for the entire lifetime of Debian Stretch (est. end of 2020), please respond with a

Re: arm64 pointer tagging, VA-bits, the end of the world...

2016-08-17 Thread Leif Lindholm
On Wed, Aug 17, 2016 at 06:34:31PM +0100, Peter Maydell wrote: > On 17 August 2016 at 17:06, Leif Lindholm wrote: > > And start agitating against pointer tagging in general. > > Why would you want to do that when the architecture has > specific support for it? Apart

Re: arm64 pointer tagging, VA-bits, the end of the world...

2016-08-17 Thread Peter Maydell
On 17 August 2016 at 17:06, Leif Lindholm wrote: > And start agitating against pointer tagging in general. Why would you want to do that when the architecture has specific support for it? thanks -- PMM

Re: arm64 pointer tagging, VA-bits, the end of the world...

2016-08-17 Thread Peter Robinson
On Wed, Aug 17, 2016 at 3:39 PM, Leif Lindholm wrote: > Hi all, > > (Sent to cross-distro with debian-arm on cc.) > > We have an 'interesting' situation ahead of us, or indeed some of us > have already fallen into it: > > ARM64 platforms with > 512GB between the lowest

Re: arm64 pointer tagging, VA-bits, the end of the world...

2016-08-17 Thread Leif Lindholm
On Wed, Aug 17, 2016 at 04:40:29PM +0100, Mark Rutland wrote: > > > ARMv8.2 bumps the maximum address limit to 52 bits [1]. Architecturally, > > > only the upper 8 bits of address are reserved for tagging (and this has > > > been the case since the original ARMv8-A release), and all other bits > >

Re: arm64 pointer tagging, VA-bits, the end of the world...

2016-08-17 Thread Mark Rutland
Hi, On Wed, Aug 17, 2016 at 03:39:36PM +0100, Leif Lindholm wrote: > We have an 'interesting' situation ahead of us, or indeed some of us > have already fallen into it: > ARM64 platforms with > 512GB between the lowest and highest RAM > addresses end up getting their amount of usable memory

Re: arm64 pointer tagging, VA-bits, the end of the world...

2016-08-17 Thread Mark Rutland
On Wed, Aug 17, 2016 at 04:16:37PM +0100, Leif Lindholm wrote: > On Wed, Aug 17, 2016 at 04:03:07PM +0100, Mark Rutland wrote: > > > ARM64 platforms with > 512GB between the lowest and highest RAM > > > addresses end up getting their amount of usable memory truncated if > > > the kernel is built

Re: arm64 pointer tagging, VA-bits, the end of the world...

2016-08-17 Thread Leif Lindholm
On Wed, Aug 17, 2016 at 04:03:07PM +0100, Mark Rutland wrote: > > ARM64 platforms with > 512GB between the lowest and highest RAM > > addresses end up getting their amount of usable memory truncated if > > the kernel is built for 39-bit VA (which is what currently happens for > > Debian kernels).

Re: arm64 pointer tagging, VA-bits, the end of the world...

2016-08-17 Thread Koen Kooi
> Op 17 aug. 2016, om 16:39 heeft Leif Lindholm het > volgende geschreven: > > Hi all, > > (Sent to cross-distro with debian-arm on cc.) > > We have an 'interesting' situation ahead of us, or indeed some of us > have already fallen into it: > > ARM64 platforms with

arm64 pointer tagging, VA-bits, the end of the world...

2016-08-17 Thread Leif Lindholm
Hi all, (Sent to cross-distro with debian-arm on cc.) We have an 'interesting' situation ahead of us, or indeed some of us have already fallen into it: ARM64 platforms with > 512GB between the lowest and highest RAM addresses end up getting their amount of usable memory truncated if the kernel

Re: Which port for armv4l?

2016-08-17 Thread Tixy
On Wed, 2016-08-17 at 14:34 +0200, Adam Wysocki wrote: [...] > I don't see why using MOV PC,reg would prevent interworking with binaries > built using Thumb, as this code executes in ARM state anyway... it could > use BX only to switch to Thumb (and when it doesn't use Thumb at all, it > would

Re: Which port for armv4l?

2016-08-17 Thread Adam Wysocki
On Wed, 17 Aug 2016, Tixy wrote: > > What about other (conditional) branch exchange instructions (BXCC, BXNE > > etc.)? > > That's a BX instruction with condition checks, I was treating that as > the same instruction (all older ARM instructions supported conditional > execution, it's the top 4

Re: Which port for armv4l?

2016-08-17 Thread Tixy
On Wed, 2016-08-17 at 11:19 +0200, Adam Wysocki wrote: > On Wed, 17 Aug 2016, Tixy wrote: > > > BX is the only ARM state instruction on ARMv4 that exists for Thumb > > interworking. > > What about other (conditional) branch exchange instructions (BXCC, BXNE > etc.)? That's a BX instruction

Qnap TS-421: GPIOs (for qcontrol and ethernet) not working

2016-08-17 Thread debian-arm
Hi, I'm running Debian on my TS-421 and recently switched to stretch, with the most recent kernel: "Linux TS-421 4.6.0-1-marvell #1 Debian 4.6.4-1 (2016-07-18) armv5tel GNU/Linux" Since then some features of qcontrol are not working anymore, like controlling the LCD and Backlight, turning

Re: Which port for armv4l?

2016-08-17 Thread Adam Wysocki
On Wed, 17 Aug 2016, Tixy wrote: > BX is the only ARM state instruction on ARMv4 that exists for Thumb > interworking. What about other (conditional) branch exchange instructions (BXCC, BXNE etc.)? > Why would the code be trying to enter Thumb state if it isn't compiled > for Thumb? Is it

Re: Which port for armv4l?

2016-08-17 Thread Tixy
On Wed, 2016-08-17 at 00:18 +0200, Adam Wysocki wrote: > On Tue, 16 Aug 2016, Adam Wysocki wrote: > > > I tested it with a small test program and it generates code with BX > > instruction (and other BXxx instructions, which - judging from the code - > > don't seem to be emulated by patch -