| Age | Commit message (Collapse) | Author |
|---|
|
This reverts commit 9320c2a1aaa085e94abd15ede0d93ffdab578e9d.
|
|
Some options that are hardware related, can either be built in or
modules, and meet the criteria of being acceptable for a BSP.
To allow these options to not throw warnings, we create a new
configuration fragment to go along with the 'hardware.cfg' and
'nonhardware.cfg' special fragments.
This new fragment is called 'y_or_m_enabled.cfg' and is effective
for the fragments in its directory. The format is the same as
hardware/nonhardware.cfg, is simply a list of CONFIG_ options.
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
|
|
If include directories (locations of layers) have relative
components, and the path to a patch doesn't share that relative
location, the detection of a common prefix can fail.
When the common prefix is incorrectly specified, it can be the
entire path to a patch. This results in everything being removed
and subtle errors (as this shouldn't happen).
By ensuring that both the relocation directories and patch path
are absolute, we can avoid this issue.
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
|
|
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
|
|
The audit phase of kernel configuration has been missing warnings due to
bad locations of fragments and special (hardware.cfg/non-hardware.cfg)
files being incorrectly logged with a path + their absolute original
path.
We adjust the logging to point directly at their copied/relocated
location and auditing works again.
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
|
|
It was found that some non-hardware fragments were being processed
as hardware, which can result in warnings or missed options in the
audit phase.
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
|
|
If an option is specified as 'hardware' it means that it is critical
to board operation and as such, will be reported as a warning during
the audit phase if the option does not match the specified value.
Once something has been specified as hardware, it can't be undone,
which means that an understood mismatch cannot have the warning
inhibited.
This change allows an option that is later specified as non-hardware
to inhibit a warning for an option that was previous specified as
hardware.
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
|
|
Previous incarnations of the tools had a merge command that was
capable of merging feature branches into the build branch. This
support was removed to streamline processing of the tree.
Now that we have the .queue implementation, we can generate a
merge.queue from any merge commands found in .scc files and
allow the do_patch phase to take care of updating the tree.
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
|
|
Create a new command to merge a feature branch inside the current branch
when processing meta-series.
Signed-off-by: David Vincent <freesilicon@gmail.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
|
|
When processing input files per-branch and global patch queues are
generated. If the meta-data has not created any branches in the repo,
no branch specific queue is required.
The tools assumed that one is always valid, and hence would throw a
non-zero exit code and stop processing.
By testing for a named per-branch queue, we avoid this issue.
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
|
|
If a patch contains characters like ; or (), it can cause processing
errors in the patch queue.
By ensuring that we wrap the patch names in quotes, we avoid shell
processing and hence they are valid.
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
|
|
spp (the preprocessor) and scc (the compiler) are used to generate
a meta-series. This meta-series contains all the patches, commands,
etc, to construct a tree from scratch.
Other tools in the kernel build process then processed the meta-series
to trigger patching and configuration. This need to process the meta
series coupled the tools to spp/scc and made changing the build process
challenging.
With this change, spp/scc can now be invoked directly (without wrapper
scripts) and produce simple output files:
config.queue
patches.queue
These files are a list of configuration options or patches that should
be process to either configure .. or patch the tree. The tools used to
configure and patch the kernel are up to the end user (but in the
linux-yocto build process these are already defined).
In addition to these plain text queues, scc also produces a meta-series
like the existing meta-series. This can be used by other tools to
re-create a kernel tree from scratch, but is not part of the typical
patch and configuration workflow.
To implement these changes, spp/scc have been modified to load
"commands" at runtime. These commands are used to execute the contents
of .scc files (patch, kconf, mark, define, etc) in a sandbox. As such
the list of valid commands (and output) can be changed without changing
the scc tool itself. This allows multiple passes of the same input files
to produce different types of output.
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
|
Bruce Ashfield
Bruce Ashfield
David Vincent