Build this swig module with Python 3.

Signed-off-by: Simon Glass <sjg@chromium.org>

At present if libfdt is not available binman can't do anything much.
Improve the situation a little.

Ideally there should be a test to cover this, but I'm not quite sure how
to fake this.

Signed-off-by: Simon Glass <sjg@chromium.org>
(fixed up missing ReadChildData() enty test)

At present binman cannot replace data within a CBFS since it does not
allow rewriting of the files in that CBFS. Implement this by using the
new WriteData() method to handle the case.

Add a header to compressed data so that the amount of compressed data can
be determined without reference to the size of the containing entry. This
allows the entry to be larger that the contents, without causing errors in
decompression. This is necessary to cope with a compressed device tree
being updated in such a way that it shrinks after the entry size is
already set (an obscure case). It is not used with CBFS since it has its
own metadata for this. Increase the number of passes allowed to resolve
the position of entries, to handle this case.

Add a test for this new logic.

Signed-off-by: Simon Glass <sjg@chromium.org>

At present the Entry constructor sets up the object and then immediately
reads its device-tree node to obtain its properties.

This breaks a convention that constructors should not do any processing.
A consequence is that we must pass all arguments to the constructor and
cannot have the node-reading proceed in a different way unless we pass
flags to that constructor. We already have a 'test' flag in a few cases,
and now need to control whether the 'orig_offset' and 'orig_size'
properties are set or not.

Adjust the code to require a separate call to ReadNode() after
construction. The Image class remains as it was.

Signed-off-by: Simon Glass <sjg@chromium.org>

At present the FDTs are keyed by their default filename (not their actual
filename). It seems easier to key by the entry type, since this is always
the same for each FDT type.

To do this, add a new Entry method called GetFdtEtype(). This is necessary
since some entry types contain a device tree which are not the simple
three entry types 'u-boot-dtb', 'u-boot-spl' or 'u-boot-tpl'.

The code already returns a dict for GetFdt(). Update the value of that
dict to include the filename so that existing code can work.

Signed-off-by: Simon Glass <sjg@chromium.org>

The current test for the 'entry' module is a bit convoluted since it has
to import the module multiple times. It also relies on ordering, in that
test1EntryNoImportLib() must run before test2EntryImportLib() if they are
running in the same Python process.

This is unreliable since neither the ordering of tests nor the process
that they run in is defined.

Fix this by always reloading the entry in these two tests. Also add a
check that the expected value of have_importlib is obtained.

This corrects a code-coverage problem in the 'entry' module on some
systems.

Signed-off-by: Simon Glass <sjg@chromium.org>

The reload() function is in a different place in Python 3. Update the code
to handle this.

Signed-off-by: Simon Glass <sjg@chromium.org>

We now have 99 tests. Before adding any more, rename everything to three
digits. This helps to preserve the ordering of tests and makes it easier
to find things.

Signed-off-by: Simon Glass <sjg@chromium.org>

At present the tests run one after the other using a single CPU. This is
not very efficient. Bring in the concurrencytest module and run the tests
concurrently, using one process for each CPU by default. A -P option
allows this to be overridden, which is necessary for code-coverage to
function correctly.

This requires fixing a few tests which are currently not fully
independent.

At some point we might consider doing this across all pytests in U-Boot.
There is a pytest version that supports specifying the number of processes
to use, but it did not work for me.

Signed-off-by: Simon Glass <sjg@chromium.org>

At present 'make check' leaves some temporary directories around. Part of
this is because we call tools.PrepareOutputDir() twice in some cases,
without calling tools.FinaliseOutputDir() in between.

Fix this.

Signed-off-by: Simon Glass <sjg@chromium.org>