Hi,
Here's quickly cleaned notes from etherpad:
People affiliated with at least Debian, Fedora, OpenEmbedded, OpenSUSE, Redhat, Ubuntu and Yocto were present and voiced opinions.
Kernel: - Good: most Interesting platforms mainline now - Qualcomm IFC (in progress), raspi2, hikey probably mostly wanted? - Bad: sometimes mainline kernels features limited "it boots to serial console" - OEMs still put their own kernels on everything they ship
Kernel testing: - http://kernelci.org is gaining traction by kernel devs, but so far tests mostly defconfigs (which are rather minimal) - all options needed by the new pid 1 and other hard requirements to boot a modern distro should be in the arm64 defconfig and multi_v* configs - if not, kernel developers present think adding them is definetly OK - make allmodconfig testing at kernelci.org http://kernelci.org/build/mainline/kernel/v3.19-rc7-200-gda2d96d3aa18/defcon... - TODO: make allmodconfig boot! - ACTION Koen volunteered to put some distro-style config fragments into the kernel
Kernel command line options - Now firmware can tell where console= is instead of defining in command - https://www.kernel.org/doc/Documentation/devicetree/bindings/chosen.txt - Similar setting exists for ACPI (SPCR) - Userspace support needs to be done - ACTION device tree files need to get chosen/stdout-path added - Systemd should magically use that as serial console if CONFIG_FHANDLE is enabled
Page size: - 64/4K? (AArch64 Fedora/Red Hat kernels will differ: 4K for Fedora for now, 64K for RH, there are a few issues with 64K left for triage) - 32bit binaries compiled with latest binutils work with 64k pages (trunk, so not in 2.25) - 20-30 packages already fixed. - probably more things making assumptions (BTRFS was glaring example)
Kernel trapping for old instructions not supported on v8. (mostly android). SWP, SETEND, cp15 barriers. - Some current packages have SWP due to embedded libatomicops. being fixed. - need to make the personality do the right thing for chroots. linux32 says armv8l Would be nice to have a armv8l for building (or just fix things) - coreutils repeats uname name (aarch64 x3 - could be improved) Riku will look into
32bit kernels on 64bit machines? - Works with QEMU, but you don't get KVM acceleration. - has worked on XEN - should still be working. IJC will fix if not.
Graphics - framebuffer/drm/hdmi/panel drivers often half-done - should DRM be built as modules or builtin? - graphics developers prefer built-in, server people want them as modules... - libdrm: enable tegra, exynos, freedreno, omap - conclusion: nobody in the session was confident enough to take lead on graphics issues
Applications still needing porting? - golang in progress. Should arrive in 1.5 (release in August) - gccgo also works for docker (esp gcc5) - ocaml already fixed upstream - mogodb, libv8, nodejs is tangled. (only new libv8 has arm64 support, mongodb forked the old one - big job to update). nodejs .12 needs to be released. ubuntu still maintains external libv8. suse gave up. some pressure to stabilise ABI would help (and stop everyone embedding copies) - mono is done/built, still needs upstreaming ("some legal issues"). $someone should build Microsofts code? - GHCi - give some people a board, and wait longer - freepascal, etc have bugs - time to tell upstreams that hardware exist maybe hand out some boards to people to get stuff done.
Is booting solved problem? - Document requirements/recommendations for OEMS - Common requirements: - boot into EL2 / Hyp mode! - SPCR is serial port console redirection. No problem to implement.(MS promise) - there are two sets of EFIvars. You need to mount the newer psedofilesystem (efivarfs). This is kernel build option.
ILP32 (some network people want it). Distros don't want to support it!. Demo OE in a container and tell them to use that. (ssh broken on ILP32) has different syscalls. Are they turned on?
Post-meeting discussion: - Monthly Cross-Distro Google hangout planned (ACTION Riku)
On Thu, Feb 12, 2015 at 3:14 PM, Riku Voipio riku.voipio@linaro.org wrote:
Hi,
Here's quickly cleaned notes from etherpad:
People affiliated with at least Debian, Fedora, OpenEmbedded, OpenSUSE, Redhat, Ubuntu and Yocto were present and voiced opinions.
Kernel:
- Good: most Interesting platforms mainline now
- Qualcomm IFC (in progress), raspi2, hikey probably mostly wanted?
- Bad: sometimes mainline kernels features limited "it boots to serial console"
- OEMs still put their own kernels on everything they ship
Kernel testing:
- http://kernelci.org is gaining traction by kernel devs, but so far
tests mostly defconfigs (which are rather minimal)
- all options needed by the new pid 1 and other hard requirements to
boot a modern distro should be in the arm64 defconfig and multi_v* configs
- if not, kernel developers present think adding them is definetly OK
- make allmodconfig testing at kernelci.org
http://kernelci.org/build/mainline/kernel/v3.19-rc7-200-gda2d96d3aa18/defcon...
- TODO: make allmodconfig boot!
- ACTION Koen volunteered to put some distro-style config fragments
into the kernel
Kernel command line options
- Now firmware can tell where console= is instead of defining in command
- https://www.kernel.org/doc/Documentation/devicetree/bindings/chosen.txt
- Similar setting exists for ACPI (SPCR)
- Userspace support needs to be done
- ACTION device tree files need to get chosen/stdout-path added
- Systemd should magically use that as serial console if
CONFIG_FHANDLE is enabled
Page size:
- 64/4K? (AArch64 Fedora/Red Hat kernels will differ: 4K for Fedora
for now, 64K for RH, there are a few issues with 64K left for triage)
- 32bit binaries compiled with latest binutils work with 64k pages
(trunk, so not in 2.25)
- 20-30 packages already fixed.
- probably more things making assumptions (BTRFS was glaring example)
Kernel trapping for old instructions not supported on v8. (mostly android). SWP, SETEND, cp15 barriers.
- Some current packages have SWP due to embedded libatomicops. being fixed.
- need to make the personality do the right thing for chroots. linux32
says armv8l Would be nice to have a armv8l for building (or just fix things)
- coreutils repeats uname name (aarch64 x3 - could be improved) Riku
will look into
32bit kernels on 64bit machines?
- Works with QEMU, but you don't get KVM acceleration.
there are patches for KVM 32-bit support on 64-bit hosts on the list for QEMU. The KVM support has been in for a while.
-Christoffer
On 12 February 2015 at 09:23, Christoffer Dall christoffer.dall@linaro.org wrote:
On Thu, Feb 12, 2015 at 3:14 PM, Riku Voipio riku.voipio@linaro.org wrote:
- Works with QEMU, but you don't get KVM acceleration.
there are patches for KVM 32-bit support on 64-bit hosts on the list for QEMU. The KVM support has been in for a while.
Great news! I guess the right patchset for interested parties is:
[PATCH v8 0/4] target-arm: ARM64: Adding EL1 AARCH32 guest support http://lists.nongnu.org/archive/html/qemu-devel/2015-02/msg02302.html
Riku
On 13 February 2015 at 03:21, Riku Voipio riku.voipio@linaro.org wrote:
On 12 February 2015 at 09:23, Christoffer Dall christoffer.dall@linaro.org wrote:
On Thu, Feb 12, 2015 at 3:14 PM, Riku Voipio riku.voipio@linaro.org wrote:
- Works with QEMU, but you don't get KVM acceleration.
there are patches for KVM 32-bit support on 64-bit hosts on the list for QEMU. The KVM support has been in for a while.
Great news! I guess the right patchset for interested parties is:
[PATCH v8 0/4] target-arm: ARM64: Adding EL1 AARCH32 guest support http://lists.nongnu.org/archive/html/qemu-devel/2015-02/msg02302.html
Yes. This will get into QEMU master within a week or so I expect.
-- PMM
On 02/11/2015 11:14 PM, Riku Voipio wrote:
Page size:
- 64/4K? (AArch64 Fedora/Red Hat kernels will differ: 4K for Fedora
for now, 64K for RH, there are a few issues with 64K left for triage)
- 32bit binaries compiled with latest binutils work with 64k pages
(trunk, so not in 2.25)
Hi guys,
Does somebody know the specific commit that provides this feature? We see this:
commit 7572ca8989ead4c3425a1500bc241eaaeffa2c89 Author: Will Newton will.newton@linaro.org
But it's all material found in 2.25.
On 18 February 2015 at 01:15, Brendan Conoboy blc@redhat.com wrote:
On 02/11/2015 11:14 PM, Riku Voipio wrote:
Page size:
- 64/4K? (AArch64 Fedora/Red Hat kernels will differ: 4K for Fedora
for now, 64K for RH, there are a few issues with 64K left for triage)
- 32bit binaries compiled with latest binutils work with 64k pages
(trunk, so not in 2.25)
Does somebody know the specific commit that provides this feature? We see this:
commit 7572ca8989ead4c3425a1500bc241eaaeffa2c89 Author: Will Newton will.newton@linaro.org
Will confirmed that this is the commit, and that is in 2.25 already. The talk at meeting that the commit is not yet in released binutils was probable a misunderstanding.
Riku
On 12 February 2015 at 09:14, Riku Voipio riku.voipio@linaro.org wrote:
- coreutils repeats uname name (aarch64 x3 - could be improved) Riku
will look into
This is a side-effect of some distributions carrying a patch[1] to make uname -p and -i return same as uname -m. There is more than a decade of bikeshedding on the subject, for example at[2]. Unless "how would you like your /proc/cpuinfo parsed" is one of your favorite discussion subjects, time is probably better spent on something else.
Riku
[1] http://pkgs.fedoraproject.org/cgit/coreutils.git/tree/coreutils-8.2-uname-pr... [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=193170
- Qualcomm IFC (in progress), raspi2, hikey probably mostly wanted?
Any plans for qualcomm to support a bootloader other than aboot? It would be useful for generic distros to be able to support u-boot
Page size:
- 64/4K? (AArch64 Fedora/Red Hat kernels will differ: 4K for Fedora
for now, 64K for RH, there are a few issues with 64K left for triage)
Fedora is 64K pages on aarch64, not 4K as noted. It's needed for AMD Seattle support.
Graphics
- framebuffer/drm/hdmi/panel drivers often half-done
- should DRM be built as modules or builtin?
- graphics developers prefer built-in, server people want them as modules...
Fedora at least would prefer modular as the DRM modules can be quite large.
- libdrm: enable tegra, exynos, freedreno, omap
We build all of these on Fedora.
It would also be useful to get some NEON acceleration in the modesetting driver for where there's not decent mesa acceleration. There's a fbdev driver [1] with this already, but ultimately there's a move away from fbdev in general.
Applications still needing porting? - golang in progress. Should arrive in 1.5 (release in August) - gccgo also works for docker (esp gcc5) - ocaml already fixed upstream - mogodb, libv8, nodejs is tangled. (only new libv8 has arm64 support, mongodb forked the old one - big job to update). nodejs .12 needs to be released. ubuntu still maintains external libv8. suse gave up. some pressure to stabilise ABI would help (and stop everyone embedding copies)
nodejs 0.12 is out and should support this now, although it might be a while before it lands distro side.
- mono is done/built, still needs upstreaming ("some legalissues"). $someone should build Microsofts code? - GHCi - give some people a board, and wait longer - freepascal, etc have bugs - time to tell upstreams that hardware exist maybe hand out some boards to people to get stuff done.
fpc has an aarch64 port for iOS [2] not sure how much work on top of that for a linux port.
The other things on my list are gprolog sbcl (possibly some other lisp implementations) pypy D (ldc)
There's also the Linaro lab? I suspect for some maintainers they don't want to have to mess around getting boards running and would sooner just be able to login to a distro and debug.
Is booting solved problem?
- Document requirements/recommendations for OEMS
- Common requirements:
The documentation and recommendation of the u-boot distro defaults here would be useful too for those vendors that will still use u-boot over uEFI.
Post-meeting discussion:
- Monthly Cross-Distro Google hangout planned (ACTION Riku)
[1] https://github.com/ssvb/xf86-video-fbturbo [2] http://lists.freepascal.org/pipermail/fpc-devel/2015-February/035397.html
Page size:
- 64/4K? (AArch64 Fedora/Red Hat kernels will differ: 4K for Fedora
for now, 64K for RH, there are a few issues with 64K left for triage)
Fedora is 64K pages on aarch64, not 4K as noted. It's needed for AMD Seattle support.
You can use 4K pages with Seattle, you just have to use 4-level (48-bit VA) tables in order for the idmap to be able to address the physical memory.
Ard Biesheuvel has some patches [1,2] which will allow the idmap to use 4 levels while keeping the rest of the tables as 3-level, which should alleviate any performance impact 4-level tables could have.
Hopefully those will be upstream shortly.
Thanks, Mark.
[1] http://lists.infradead.org/pipermail/linux-arm-kernel/2015-March/328541.html [2] http://lists.infradead.org/pipermail/linux-arm-kernel/2015-March/328542.html
On Fri, Mar 06, 2015 at 02:42:17PM +0000, Peter Robinson wrote:
[snip]
Is booting solved problem?
- Document requirements/recommendations for OEMS
- Common requirements:
The documentation and recommendation of the u-boot distro defaults here would be useful too for those vendors that will still use u-boot over uEFI.
And of course if there's something on the U-Boot side that's not quite right / clear please let us know, we want this to work right for everyone.
On 6 March 2015 at 17:00, Mark Rutland mark.rutland@arm.com wrote:
Page size:
- 64/4K? (AArch64 Fedora/Red Hat kernels will differ: 4K for Fedora
for now, 64K for RH, there are a few issues with 64K left for triage)
Fedora is 64K pages on aarch64, not 4K as noted. It's needed for AMD Seattle support.
You can use 4K pages with Seattle, you just have to use 4-level (48-bit VA) tables in order for the idmap to be able to address the physical memory.
Ard Biesheuvel has some patches [1,2] which will allow the idmap to use 4 levels while keeping the rest of the tables as 3-level, which should alleviate any performance impact 4-level tables could have.
Hopefully those will be upstream shortly.
FYI these patches have been pulled into v4.1-rc1, so no special provisions to allow booting on AMD Seattle are required anymore.
Regards, Ard.
-
Ard Biesheuvel -
Brendan Conoboy -
Christoffer Dall -
Mark Rutland -
Peter Maydell -
Peter Robinson -
Riku Voipio -
Tom Rini