Package: linux-image-arm64
Version: 4.9+78
Severity: wishlist
Linux commit 9822504c1, included in v4.7, introduced EFI framebuffer
support on arm/arm64.
The Debian arm64 kernel config currently explicitly sets CONFIG_FB to
'm', overriding the defconfig 'y'. Since CONFIG_FB_EFI is "depends on
(FB
X-Debbugs-CC: ard.biesheu...@linaro.org
On Sun, Aug 21, 2016 at 02:46:06PM +0100, Ben Hutchings wrote:
> > > I seem to remember that AArch64 has the ill-advised rule that VA bits
> > > outside the range of the current page table format are ignored, so
> > > presumably you're concerned that the cod
X-Debbugs-CC: ard.biesheu...@linaro.org
On Sun, Aug 21, 2016 at 03:04:02PM +0100, Ian Campbell wrote:
> On Sun, 2016-08-21 at 11:42 +0100, Leif Lindholm wrote:
> >
> > You're not wrong, but unfortunately the ability to write semi-portable
> > code left the pla
On Sun, Aug 21, 2016 at 01:11:15AM +0100, Ben Hutchings wrote:
> > > > I think this would be opening up a real can of worms. Not all sizes
> > > > are supported by the architecture, and only certain VA_BITS/pagesize
> > > > combinations work in the kernel.
> > > >
> > > > We could switch to 42-bit
On Fri, Aug 19, 2016 at 12:50:49PM +0100, Ben Hutchings wrote:
> >> > > > everything using mozilla-js).
> >> [...]
> >>
> >> Could we possibly work around that by reducing
> >> CONFIG_ARCH_MMAP_RND_BITS_MAX? (That's not directly configurable; it
> >> requires patching arch/arm64/Kconfig.)
> >
> >
On Fri, Aug 19, 2016 at 02:04:07AM +0100, Ben Hutchings wrote:
> > > > So please enable CONFIG_ARM64_VA_BITS_48 for arm64 kernels.
> > > >
> > > > Note: this change _will_ cause breakage in certain userland software
> > > > making non-portable assumptions about available of top address bits
> > >
Package: linux
Version: 4.6.4-1
X-Debbugs-CC: st...@einval.com, woo...@wookware.org, zheng...@linaro.org
Upstream commit 211102d85 ("arm64: defconfig: enable 48-bit virtual
addresses") changed the default configuration for arm64 to be 48-bit
VA (CONFIG_ARM64_VA_BITS_48). This is required in order
On Thu, Dec 18, 2014 at 06:35:25PM +, Ian Campbell wrote:
> > > Is PSTORE (going to be) a thing on arm64? (I'm not entirely sure what
> > > pstore is, so sorry if this is a silly question).
> >
> > I am actually not concerned about pstore itself, but rather by the
> > lack of similarity betwee
*grumble, accidental send*
On Thu, Dec 18, 2014 at 08:08:31PM +, Leif Lindholm wrote:
> > > > (I don't have an x86 EFI system available to poke around and answer
> > > > these for myself).
> > > >
> > > > I'm wonder
On Wed, Dec 17, 2014 at 02:57:17PM +, Ian Campbell wrote:
> > Could we enable CONFIG_PSTORE for arm64 as well, please?
>
> Is PSTORE (going to be) a thing on arm64? (I'm not entirely sure what
> pstore is, so sorry if this is a silly question).
I am actually not concerned about pstore itself,
Package: src:linux
Severity: normal
X-Debbugs-CC: i...@debian.org
I noticed efivars was being automatically loaded on boot on my
installed amd64 Jessie, but not on my arm64 Jessie. The
installer/rescue image automatically loads it for both.
Turns out on amd64, efivars is being pulled in as a depen
X-Debbugs-CC: i...@debian.org
Package: src:linux
Version: 3.16.7
Severity: wishlist
Linux 3.17 gained support for using a device-tree provided default
console, from the ePAPR 1.1 'stdout-path' property. This removes the
need for explicitly passing a console= parameter to pick the
appropriate conso
12 matches
Mail list logo
