This makes it possible to ship differing system files depending on the
images being built. E.g. an ITB image might expect a different
/etc/fstab than a DDI.
run.sh has degenerated quite a bit over the years - in no small part
due to the way the qemu-system argv is constructed.
Cut our losses by taking a fresh look at this problem, now that lots
of things need to change anyway. Keep the old script as-is for targets
that still use ITB based images.
First user is the initramfs, where it is used to setup the verity
device.
Later on, it will be extended for use by RAUC during upgrades, to
fetch image info in statd, etc.
On platforms based on CN913{0,1,2}, collect all ECC related counters
so that we know if any correctable errors have been encountered since
the most recent boot.
Allow particular boards or platforms install hardware specific scripts
in /etc/support.d, via the usual /usr/share/product logic, which are
then run by /sbin/support and included in the resulting bundle.
This lets us collect hardware specific information, e.g., SoC-specific
error counters, without /sbin/support needing to know about all the
nitty gritty details.
Verify that if the system encounters a hard lockup, i.e., interrupts
are no longer being serviced, then the system's watchdog will
correctly reboot it.
Rev. A has a FLASH that Linux reconfigures to 4B-addressing, but must
be in 3B-addressing when accessed by the BootROM. Since it has no
reset input, this would not work on warm resets. Linux has a
workaround for this issue for the common case of a controlled reboot,
which this change enables on those boards (which are admittedly few
and far between, but still useful as testing vehicles).
(This won't take effect until Finit is updated to at least 4.15, which
switches over from watchdog- to reboot(2)- based reboot, by default)
By default, ensure that the target device accepts TCP connections on
the specified port before returning the device object. This aligns the
SSH implementation with {NET,REST}CONF.
This solves the issue where tests that use SSH commands early in their
execution would sometimes fail as the remote server had not started up
yet.
After merging post-post-image, TRUSTED_KEYS must be set in order for
the keys to be injected into the U-Boot DTB, so we need to explicitly
enable it for all boards that use the generic secure boot scripts.
This was a stray config fragment used during development that was
accedentally included in the referenced commit.
Fixes: 0fe5964909 ("aarch64_qemu_boot: Restore build after removing post-image.sh")
Previously, post-image.sh was able to create QEMU images from an
existing release tarball. This was useful when you wanted to test a
new bootloader build without having to wait for a full Infix build.
Restore this capability by adding a separate image target for it, and
then allow image-itb-qcow to source its input images from that instead
of a locally build squash+aux.
Limit support to x86, like we do on the "official" appliances on the
marketplace. Aarch64 has never really been used AFAIK.
Avoid the os-release import, since all that info is not important now
that these appliance files are only for development scenarios. In all
other cases, the official one, based on a proper release, should be
used.
We have not installed .dtb:s to $O/images/ for quite some time, and
nobody cared. That goes to show that this is not really used.
The image is still useful at times, so if it needed in the future,
then we can resurrect it from the logs and refactor it to an image
package.
Add a generic image target to build aux.ext4, which can be used both
when creating target-specific SD-card images, and when creating
regular disk images.
While we're here, make sure that we don't need a RAUC bundle in order
to generate aux.ext4 (which mkrauc-status.sh did). This saves us time
on _every_ incremental build.
Rather than using the creation of a signed image as a proxy for
whether the trusted keys should be installed RAUC/U-Boot's trust
stores, use the dedicated option.
The board/*/*/*.mk is very broad, intended to hit all board specific
definitions, but may also cause duplicate inclusions, e.g., in
board/common.
Let each architecture do the inclusion instead.
A bunch of different artifacts should follow the same naming scheme,
depending on a bunch of config settings + whether we're building a
release or not.
Therefore, provide a single definition of this that we can reuse to
name disk images, upgrade packages, etc.
This will make sure to apply NACM rules for all the data. It also
makes it possible for a luser access a subset of the data, even if
they to do not have read access to /cfg/startup-config.cfg.
In setups like this...
CPU
eth0
|
.----0----.
| dst0sw0 |
'-1-2-3-4-'
|
.----0----.
| dst1sw0 |
'-1-2-3-4-'
...both eth0 and dst0sw0p4 are DSA ports. But the latter is _also_ a
physical port as far as devlink is concerned. As a result, it would
first be marked as "internal" and is then instantly reclassified as a
"port".
Catch this condition and stick with the initial "internal"
classification.
In addition to matching on interface names, add support for matching
on ethtool information.
Example:
{
"@ethtool:driver=st_gmac": {
"broken-mqprio": true
}
}
This would mark any interface using the "st_gmac" driver as having a
broken mqprio implementation. Whereas this:
{
"@ethtool:driver=st_gmac;bus-info:30bf0000.ethernet": {
"broken-mqprio": true
}
}
Only matches an st_gmac-backed interface at the specified location.
As matching becomes more complicated, use the shell implementation
from confd as well, to make sure that they are always in agreement.
The defconfigs for all architectures other than x86_64 has this
enabled, so align it with the rest.
This has no on-target impact, but it enables us to attach to a live VM
instance and debug it, or do offline debugging like resolving stack
trace lines from oops messages to source locations.
Some netdev drivers, e.g. the FEC found on many i.MX SoCs from NXP,
will detach from their PHYs when configured down.
This means that when confd tries to configure L1 settings for the link
before bringing it up, ethtool fails - since there is no PHY to talk
to.
For interfaces that behave this way, delay the configuration until
after NETDAG_INIT, when the interface is brought up. This is not
optimal, since we are generating needless noise for the link partner,
which is why we only fall back to it as a last resort.
Fix#951
Ideally, all drivers should behave the same. Alas, that is not the
world we live in. For quirks that we can not reliably probe for in any
other way, let products supply a JSON file that declares them.
CID 507415 from coverity was the origin for this change. As it turns
out, the unreachable MAC address generation for VXLANs was hidden by
the generic setup (netdag_gen_link_addr()) saving the day. That is
likely something we want to phase out though, so the VXLAN code should
stand on its own.
Align the GRE code while we're here, because why not? :)
Do not allow the topology matcher to setup a LAG where one link is
running at 10G while the other one runs at 1G, since the bond will
never use the 1G port as long as there the 10G link is up.
To run LAG tests on hardware, we have to make sure that the chosen
links are running at the same speed. We do not want to require a
specific link speed from the logical topology, as the real requirement
is merely that the two (or however many) links are of the _same_
speed, not any _particular_ speed.
Rather than having to complicate the topology matcher, let it take
care of the common pattern of matching requirements to provided
features, then let tests pass custom node/edge matchers for the
complicated cases.
Tobias Waldekranz