| Age | Commit message (Collapse) | Author |
|---|
|
All the currently supported BSPs are 64bit so use the
appropriate m64 TUNE_FEATURE in order to get the build
environment evaluated properly. Otherwise the basic -m64
switch which is required for proper linker output
specification and other such things do not end up in
the correct form and the build fails in case a toolchain
that supports 32 and 64bit builds is used.
Signed-off-by: Awais Belal <awais_belal@mentor.com>
|
|
|
|
Created IMAGE_FEATURES to be used by AMD BSPs removing all img.bbappends
|
|
Signed-off-by: Sudheesh Mavila <sudheesh.mavila@amd.com>
|
|
defaults to no package included
snowyowl adds its own pkgs
Signed-off-by: Arsalan H. Awan <Arsalan_Awan@mentor.com>
|
|
This defines AMD Features that can be added as EXTRA_IMAGE_FEATURES
to different machines based on what is supported on a machine. This adds
a broad flexibility and control over packages being installed on a
machine for any image without needing to create bbappends for all the
images that are to be supported.
> Each feature can contain packages and packagegroups as its components.
> Feature components can be dependent on DISTRO, IMAGE_FEATURE, or any
variable in general. e.g.: Components of "amd-feature-graphics" may be
dependent on "x11-base" as an IMAGE_FEATURE. Some packages may only be
included for a specific DISTRO. Some packages may only be installed if
user allows them in local.conf etc.
> Each machine must add the required features to EXTRA_IMAGE_FEATURES in
its own machine config file.
> All required features must be added to a machine regardless of the
image being built, but make sure that feature components are included
based on dependency conditions. e.g. say "amd-feature-graphics" was
added to a machine that supported graphics, but components of this
feature must not be installed on an image that is only console based
such as "core-image-base", therefore such components must depend on an
IMAGE_FEATURE that is based on graphics such as "x11-base".
> Each machine can also override feature components in its own machine
config when adding the feature to EXTRA_IMAGE_FEATURES. e.g.: a
feature may be added to a specific machine with minimal (or extended)
packages based on requirement.
Features are classified as:
* amd-common-pkgs : Common pkgs to be added to all machines
* amd-feature-multimedia : Multimedia packages (it does not depend
on graphics because a machine may not
have a GUI but could play videos and
sounds from console)
* amd-feature-graphics : Graphics packages
* amd-feature-networking : Networking packages
* amd-feature-debug-profile : Debugging and Profiling tools
* More features may be added later as needed
Signed-off-by: Arsalan H. Awan <Arsalan_Awan@mentor.com>
|
|
Signed-off-by: Sudheesh Mavila <sudheesh.mavila@amd.com>
|
|
Signed-off-by: Sudheesh Mavila <sudheesh.mavila@amd.com>
|
|
Signed-off-by: Sudheesh Mavila <sudheesh.mavila@amd.com>
|
|
Signed-off-by: Sudheesh Mavila <sudheesh.mavila@amd.com>
|
|
Signed-off-by: Sudheesh Mavila <sudheesh.mavila@amd.com>
|
|
Signed-off-by: Sudheesh Mavila <sudheesh.mavila@amd.com>
|
|
The change being applied to the recipe is generic and
breaks whenever the recipe version is updated so use
a wildcard for versioning to keep it maintainable.
Signed-off-by: Awais Belal <awais_belal@mentor.com>
|
|
The backports for Spectre/Meltdown changes include things
that break the builds for lttng-modules otherwise these
changes. We get build failures such as
git/probes/../probes/lttng-tracepoint-event-impl.h:142:6: error: conflicting types for 'trace_kvm_mmio'
| void trace_##_name(_proto);
| ^
Signed-off-by: Awais Belal <awais_belal@mentor.com>
|
|
|
|
This moves the VIRTIO configs to the KVM configuration
fragment and enables CONFIG_VIRTIO_INPUT.
Signed-off-by: Awais Belal <awais_belal@mentor.com>
|
|
Use a light assignment (?=) so configurations can be
overridden from elsewhere.
Signed-off-by: Awais Belal <awais_belal@mentor.com>
|
|
This moves the parts that can be utilized through the
common layer for the RT kernel and generalizes the
support.
Signed-off-by: Awais Belal <awais_belal@mentor.com>
|
|
The RT kernel patches modify the interrupt handling mechanisms
in a way that using do_softirq directly is prohibited. Rather
the support forces the user to use a thread based version for
the same sort of funtionality by calling thread_do_softirq.
This fixes the build issue by calling the appropriate function
depending on the kernel configuration.
Signed-off-by: Awais Belal <awais_belal@mentor.com>
|
|
Signed-off-by: Awais Belal <awais_belal@mentor.com>
|
|
This will allow for an easier maintenance procedure such that
the common fragments can be handled more seamlessly.
Signed-off-by: Awais Belal <awais_belal@mentor.com>
|
|
This drops the unnecessary MCE patches which conflict
with the upcoming RT kernel support and everything
functions as expected without these as well.
Signed-off-by: Awais Belal <awais_belal@mentor.com>
|
|
These generate unnecessary boot logs and are not needed
for the platform to work correctly.
Signed-off-by: Awais Belal <awais_belal@mentor.com>
|
|
|
|
AMD Spectre/Meltdown Upstream backports
|
|
This is now an upstream requirement for compliance
and throws warnings on the console if not handled
appropriately.
Signed-off-by: Awais Belal <awais_belal@mentor.com>
|
|
This moves further common settings from the BSP
specific appends to the common fragment.
Signed-off-by: Awais Belal <awais_belal@mentor.com>
|
|
The kernel 4.9 recipe is being used for v1000 as well
as snowyowl. Move the base recipe to common and then
use appends for BSP overrides.
Signed-off-by: Awais Belal <awais_belal@mentor.com>
|
|
This enables the userspace I/O drivers support
which is required by DPDK to function properly.
Signed-off-by: Awais Belal <awais_belal@mentor.com>
|
|
Signed-off-by: Sudheesh Mavila <sudheesh.mavila@amd.com>
|
|
Signed-off-by: Sudheesh Mavila <sudheesh.mavila@amd.com>
|
|
Signed-off-by: Sudheesh Mavila <sudheesh.mavila@amd.com>
|
|
Signed-off-by: Sudheesh Mavila <sudheesh.mavila@amd.com>
|
|
Signed-off-by: Sudheesh Mavila <sudheesh.mavila@amd.com>
|
|
snowyowl-user-config.cfg: set CONFIG_MMC_BLOCK=y
|
|
Snowyowl
|
|
The Snowy Owl board features an eMMC device that can
be used as a boot media. If the block device isn't
made part of the kernel the installation mechanism
which runs through initrd without kernel modules
fails to find the device which can be selected as
an installation candidate.
Signed-off-by: Awais Belal <awais_belal@mentor.com>
|
|
Signed-off-by: Sudheesh Mavila <sudheesh.mavila@amd.com>
|
|
Signed-off-by: Sudheesh Mavila <sudheesh.mavila@amd.com>
|
|
Signed-off-by: Sudheesh Mavila <sudheesh.mavila@amd.com>
|
|
Signed-off-by: Sudheesh Mavila <sudheesh.mavila@amd.com>
|
|
Signed-off-by: Sudheesh Mavila <sudheesh.mavila@amd.com>
|
|
The Mentor internal tools require RELEASE_IMAGE to be
set appropriately for generating the correct installers.
The amd-common-configuration fragment sets this to
core-image-sato however on the snowyowl BSP there's no
such support so we'll be using the console-image.
Signed-off-by: Awais Belal <awais_belal@mentor.com>
|
|
This fixes the build for all the components that fail
when an openssl enabled kernel is used for the target
where configurations such as CONFIG_MODULE_SIG are
used. The fix should probably be submitted upstream.
Signed-off-by: Awais Belal <awais_belal@mentor.com>
|
|
Kernel configurations such as CONFIG_MODULE_SIG require openssl
on the host. This fixes the issue by enabling the dependency
in the kernel recipe append along with allowing the use
of native sysroot for such dependencies so the user does not
have to install these separately on the host.
Signed-off-by: Awais Belal <awais_belal@mentor.com>
|
|
This drops the particular features from the DISTRO_FEATURES
as well so additional userland bits are removed appropriately.
Signed-off-by: Awais Belal <awais_belal@mentor.com>
|
|
Dropping whole features from a BSP should be handled
through configuration files rather than recipe files
so move it to machine config.
Signed-off-by: Awais Belal <awais_belal@mentor.com>
|
|
There's no graphics support on the platform for now
so the user won't be able to get the grub install
option working through the display as it works for
the other platforms.
We now disable the graphical console so the install
mechanism is handled through the serial console.
Signed-off-by: Awais Belal <awais_belal@mentor.com>
|
|
Dogwood release for snowyowl will not have graphics support
for the platform so disabling the kernel configuration/features
as needed.
Signed-off-by: Arsalan-Awan <Arsalan_Awan@mentor.com>
|
|
Dogwood release for snowyowl will not have sound support
for the platform, so disabling the kernel configuration/features
as needed.
Signed-off-by: Arsalan-Awan <Arsalan_Awan@mentor.com>
|
Awais Belal
Wade Farnsworth
Sudheesh Mavila
Arsalan H. Awan