> - 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 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.
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
_______________________________________________
cross-distro mailing list
cross-distro@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/cross-distro
