The name of the board is indeed A64-LTS, but upstream U-Boot names it
pine64-lts so let's keep the U-Boot moniker.
This previously was supported using the SOPINE build.
The hack of using `crossConfig` to enforce stricter handling of
dependencies is replaced with a dedicated `strictDeps` for that purpose.
(Experience has shown that my punning was a terrible idea that made more
difficult and embarrising to teach teach.)
Now that is is clear, a few packages now use `strictDeps`, to fix
various bugs:
- bintools-wrapper and cc-wrapper
This build is compatible with PINE A64-LTS.
[dezgeg changed the original device tree patch to v4 of the patch series
"sunxi: sync H3, H5, A64 DTs from mainline Linux" submitted to the
upstream mailing list by Andre Przywara. Also install the
u-boot-sunxi-with-spl.bin binary similar to 32-bit boards
since it's now being built by the upstream build system.]
(cherry picked from commit 2ff31f71ae)
(cherry picked from commit 176d151f4d)
These derivations have not seen any updates since they were created in 2010,
and some of their sources have disappeared. There are upstream configs for
these boards, so these are now used, and they build correctly. I have no way
of testing them, and I don't if anyone even uses either board with Nix anymore.
(cherry picked from commit 01020b3263)
(cherry picked from commit 48ade50d8e)
This build is compatible with PINE A64-LTS.
[dezgeg changed the original device tree patch to v4 of the patch series
"sunxi: sync H3, H5, A64 DTs from mainline Linux" submitted to the
upstream mailing list by Andre Przywara. Also install the
u-boot-sunxi-with-spl.bin binary similar to 32-bit boards
since it's now being built by the upstream build system.]
These derivations have not seen any updates since they were created in 2010,
and some of their sources have disappeared. There are upstream configs for
these boards, so these are now used, and they build correctly. I have no way
of testing them, and I don't if anyone even uses either board with Nix anymore.
ARM trusted firmware is required as part of the boot process on some ARMv8-A
boards. Currently, only the RK3328 is supported in nixpkgs.
This makes the Rock64 u-boot image bootable.
u-boot only builds some architecture-specific tools, if this
architecture is selected in configuration. So a 'allnoconfig' won't
include them.
As they are pretty useful however, we'd like to have them in ubootTools.
This can be accomplished by enabling CONFIG_KIRKWOOD=y and possibly
more later.
Certain tools, e.g. compilers, are customarily prefixed with the name of
their target platform so that multiple builds can be used at once
without clobbering each other on the PATH. I was using identifiers named
`prefix` for this purpose, but that conflicts with the standard use of
`prefix` to mean the directory where something is installed. To avoid
conflict and confusion, I renamed those to `targetPrefix`.
* pkgs: refactor needless quoting of homepage meta attribute
A lot of packages are needlessly quoting the homepage meta attribute
(about 1400, 22%), this commit refactors all of those instances.
* pkgs: Fixing some links that were wrongfully unquoted in the previous
commit
* Fixed some instances
I don't own this board, but someone on IRC reported this as working (and
anyway it's practically identical to ubootPcduino3Nano since they're both
Allwinner boards)
Someone submitted conflicting (and non-complete) distro bootconfig
support for the Versatile board, so the patch needs changing, yet again.
But at least it's getting smaller.
A new regularly release. Some improvements I've noted:
- Keyboard on the pcDuino3 Nano now works without a hub.
- Ctrl-C now correctly cancels the 'sysboot' boot menu
Also, config_cmd_default.h is replaced by equivalents in the kconfig
system, so the vexpress patch needs some updating.
With this patch in place, ARMv7 NixOS can be booted in QEMU:
qemu-system-arm -kernel u-boot -M vexpress-a9 -serial stdio -sd nixos-sd-image-armv7l-linux.img -m 1024
...with all the features that boot.loader.generic-extlinux-compatible
supports, like the boot generation menu and seamless kernel upgrades
in the VM.
Instead of selecting the defconfig based on stdenv.platform.uboot,
provide different ubootFoo packages. Otherwise we couldn't easily build
U-Boots for different platforms than what we are currently running on.
All users of the ubootChooser function appear to be using only CLI tools
like mkimage, whose behaviour is not affected by the defconfig (their
build outputs are bitwise-identical). So add a separate package for the
CLI tools.
Of the removed patches, some version of sheevaplug-sdio.patch has
apparently been applied upstream (with at least mv_sdio.c renamed to
mvebu_mmc.c). sheevaplug-config.patch needs rebasing & re-testing on
real hardware.
Tested boards and input/output methods that upstream supports:
- Raspberry Pi:
- HDMI works, USB keyboard not yet supported
- Serial via the 26-pin connector (3.3V)
- pcDuino3 Nano:
- HDMI + USB keyboard (only if attached to a hub)
- Serial via the 3-pin connector (3.3V)
- Jetson TK1: RS-232 serial port only
- Versatile Express CA9 (for QEMU only): Serial via '-serial stdio'
the cross compilation functionality.
- I renamed some expected stdenv.mkDerivation parameter attributes so we can
keep this branch properly updated from trunk. We agreed with Nicolas Pierron
doing a massive renaming, so all current buildInputs become hostInputs (input
as build for the host machine, in autotools terminology) , and
then buildInputs would mean "input as for the build machine".
By now, the specific "input as for the build machine" is specified through
buildNativeInputs. We should fix this in the merge to trunk.
- I made the generic stdenv understand the buildNativeInputs, otherwise if
we start changing nixpkgs expressions so they distinguish the current
buildInputs into buildInputs and buildNativeInputs, we could break even more
nixpkgs for other platforms.
- I changed the default result of mkDerivation so it becomes the derivation for
to be run in the build machine. This allows, without any special rewriting,
"fetchurl" derivations to be always results for the build machine to use
them.
- The change above implies that, for anyone wanting to cross-compile, has to
build the hostDrv of the wanted derivation. For example, after this commit,
the usual test of "nix-build -A bison.hostDrv arm.nix" works. I described
the contents of this arm.nix in r18398.
svn path=/nixpkgs/branches/stdenv-updates/; revision=18471
