| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
| |
Now the build systems have the openstack-clients stratum,
and this system is not longer needed.
|
| |
|
|\
| |
| |
| |
| | |
Reviewed-By: Adam Coldrick <adam.coldrick@codethink.co.uk>
Reviewed-By: Richard Maw <richard.maw@codethink.co.uk>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Lorry is used by the Baserock Import tool for fetching source code of
components that are to be imported.
It's also generally useful in devel systems as it can be used for
testing .lorry files prior to pushing them to a Trove.
Additionally, this means that devel systems now contain 'hg', 'bzr',
'svn' and 'cvs', any of which may come in handy.
This increases the size of the devel-system-x86_64-chroot system from
1.4GB to 1.5GB.
|
| | |
|
|\ \
| | |
| | |
| | |
| | | |
Reviewed-by: Paul Sherwood <paul.sherwood@codethink.co.uk>
Reviewed-by: Francisco Redondo Marchena <francisco.marchena@codethink.co.uk>
|
| | | |
|
| | | |
|
| |/
|/|
| |
| |
| | |
Reviewed-by: James Thomas <james.thomas@codethink.co.uk>
Reviewed-by: Francisco Redondo Marchena <francisco.marchena@codethink.co.uk>
|
|\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Reviewed-By: Richard Maw <richard.maw@codethink.co.uk>
Reviewed-By: Paul Sherwood <paul.sherwood@codethink.co.uk>
Conflicts:
systems/devel-system-armv7-highbank.morph
systems/devel-system-armv7-versatile.morph
systems/devel-system-armv7-wandboard.morph
systems/devel-system-armv7b-highbank.morph
systems/devel-system-armv7lhf-highbank.morph
systems/devel-system-armv7lhf-wandboard.morph
systems/devel-system-ppc64-generic.morph
systems/devel-system-x86_32-generic.morph
systems/devel-system-x86_64-generic.morph
|
| | | |
|
|\ \ \
| | | |
| | | |
| | | |
| | | | |
Reviewed-by: Sam Thursfield <sam.thursfield@codethink.co.uk>
Reviewed-by: James Thomas <james.thomas@codethink.co.uk>
|
| | | | |
|
| | | | |
|
| | | |
| | | |
| | | |
| | | | |
To remove unneded systemd units
|
| | | |
| | | |
| | | |
| | | | |
This is automatically configured by systemd
|
| | | | |
|
| | | | |
|
| | | | |
|
|/ / / |
|
| | | |
|
|\ \ \
| | | |
| | | |
| | | | |
Reviewed-by: Richard Maw
|
|/ / / |
|
|\ \ \
| | | |
| | | |
| | | |
| | | | |
Reviewed-by: Sam Thursfield
Reviewed-by: Pedro Alvarez
|
| | | |
| | | |
| | | |
| | | | |
This causes crashes in clickdot in the hmi-controller
|
|\ \ \ \
| | | | |
| | | | |
| | | | | |
Reviewed-by: Richard Maw
|
|/ / / /
| | | |
| | | |
| | | |
| | | | |
This will avoid problems when self-upgrading a system and also
will save time when flashing a JETSON TK1 board.
|
|\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | | |
Reviewed-by: Richard Maw
Reviewed-by: Sam Thursfield
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Add a morph file as well, this way we don't need to modify the source to
build
|
| | | | | |
|
|\ \ \ \ \
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
This includes the patches from Pedro Alvarez required to make the
release.
Reviewed-by: Pedro Alvarez
Reviewed-by: Sam Thursfield
|
| | | | | | |
|
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Needed for the GPU
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
I've branched this from gk20a since this has been forced-pushed before,
so want to ensure this stays around
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
This is in a special jetson branch because:
i) it's still a rc, so probably don't want to use this for everything
ii) it contains specific jetson patches (cpufreq)
However the goal will be to maintain a branch all systems will use,
hopefully the 3.18 mainline will include the cpufreq stuff, so we can
start using that for everything
|
| | | | | | |
|
| | | | | | |
|
|\ \ \ \ \ \
| |_|_|_|_|/
|/| | | | |
| | | | | |
| | | | | |
| | | | | | |
Reviewed-By: Pedro Alvarez <pedro.alvarez@codethink.co.uk>
Reviewed-By: Francisco Redondo Marchena <francisco.marchena@codethink.co.uk>
Reviewed-By: Sam Thursfield <sam.thursfield@codethink.co.uk>
|
|/ / / / /
| | | | |
| | | | |
| | | | |
| | | | | |
This will make egl weston demos (like weston-simple-egl)
work in a qemu virtual machine
|
| | | | | |
|
|\ \ \ \ \
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Reviewed-by: Jim MacArthur
Reviewed-by: Sam Thursfield
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
It has 4 modes.
1. Specify PXEBOOT_DEPLOYER_INTERFACE and PXEBOOT_VLAN to
configure the target to pxeboot on a vlan and spawn a dhcp, nfs and
tftp server. This is potentially the fastest, since it doesn't need
to copy data to other servers.
2. Specify PXEBOOT_DEPLOYER_INTERFACE without PXEBOOT_VLAN to
configure do 1, but without creating the vlan interface. This
assumes that you have exclusive access to the interface, such as if
you're plugged in to the device directly, or your interface is
vlanned by your infrastructure team.
This is required if you are serving from a VM and bridging it to the
correct network via macvtap. For this to work, you need to macvtap
bridge to a pre-vlanned interface on your host machine.
3. Specify PXEBOOT_DEPLOYER_INTERFACE and PXEBOOT_CONFIG_TFTP_ADDRESS
to put config on an existing tftp server, already configured by the
dhcp server.
This spawns a tftp server and configures the local nfs server, but
doesn't do a dhcp server. This is useful if you have already got a
dhcp server that serves PXE images.
4. Specify at least PXEBOOT_CONFIG_TFTP_ADDRESS and
PXEBOOT_ROOTFS_RSYNC_ADDRESS to specify existing servers to copy
config, kernels and the rootfs to.
The mode detection can be overridden by specifying PXEBOOT_MODE.
Mode 1 is `spawn-vlan`. Mode 2 is `spawn-novlan`, Mode 3 is
`existing-dhcp` and Mode 4 is `existing-server`.
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
With VLANs it's possible to PXE boot hardware without needing to fiddle
with the DHCP server, by starting your own PXE server on a VLAN, and
configure the NIC of the target to start in that VLAN.
|
| | | | | | |
|
| | | | | | |
|
|/ / / / /
| | | | |
| | | | |
| | | | | |
It's handy to be able to start an NFS server when you want to.
|
|/ / / /
| | | |
| | | |
| | | |
| | | | |
Reviewed-By: Richard Maw <richard.maw@codethink.co.uk>
Reviewed-By: James Thomas <james.thomas@codethink.co.uk>
|
|\ \ \ \
| |/ / /
|/| | |
| | | |
| | | |
| | | | |
Reviewed-by:
- Paul Sherwood
- Adam Coldrick
|
|/ / / |
|
|\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Reviewed-by:
- Paul Sherwood
- Francisco Redondo Marchena
Notes:
Author: Pedro Alvarez <pedro.alvarez@codethink.co.uk>
|