- 27 4月, 2020 4 次提交
-
-
由 Simon Glass 提交于
At present patman sets the python path on startup so that it can access the libraries it needs. If we convert to use absolute imports this is not necessary. Move patman to use absolute imports. This requires changes in tools which use the patman libraries (which is most of them). Signed-off-by: NSimon Glass <sjg@chromium.org>
-
由 Simon Glass 提交于
At present binman sets the python path on startup so that it can access the libraries it needs. If we convert to use absolute imports this is not necessary. Move binman to use absolute imports. This enables removable of the path adjusting in Entry also. Signed-off-by: NSimon Glass <sjg@chromium.org>
-
由 Simon Glass 提交于
Python does not like the module name being the same as the module directory. To allow buildman modules to be used from other tools, rename it. Signed-off-by: NSimon Glass <sjg@chromium.org>
-
由 Simon Glass 提交于
We don't need these now that the tools using Python 3. Drop them. Signed-off-by: NSimon Glass <sjg@chromium.org>
-
- 12 11月, 2019 1 次提交
-
-
由 Simon Glass 提交于
A recent change adjusted the symbol calculation to work on x86 but broke it for Tegra. In fact this is because they have different needs. On x86 devices the code is linked to a ROM address and the end-at-4gb property is used for the image. In this case there is no need to add the base address of the image, since the base address is already built into the offset and image-pos properties. On other devices we must add the base address since the offsets start at zero. In addition the base address is currently added to the 'offset' and 'size' values. It should in fact only be added to 'image-pos', since 'offset' is relative to its parent and 'size' is not actually an address. This code should have been adjusted when support for 'image-pos' and 'size' was added, but it was not. To correct these problems: - move the code that handles adding the base address to section.py, which can check the end-at-4gb property and which property (offset/size/image-pos) is being read - add the base address only when needed (only for image-pos and not if the image uses end-at-4gb) - add a note to the documentation - add a separate test to cover x86 behaviour Fixes: 15c981cc (binman: Correct symbol calculation with non-zero image base) Signed-off-by: NSimon Glass <sjg@chromium.org> Tested-by: NStephen Warren <swarren@nvidia.com>
-
- 05 11月, 2019 2 次提交
-
-
由 Simon Glass 提交于
Some tests have crept in with Python 2 strings and constructs. Convert then. Signed-off-by: NSimon Glass <sjg@chromium.org>
-
由 Simon Glass 提交于
At present all the 'command' methods return bytes. Most of the time we actually want strings, so change this. We still need to keep the internal representation as bytes since otherwise unicode strings might break over a read() boundary (e.g. 4KB), causing errors. But we can convert the end result to strings. Add a 'binary' parameter to cover the few cases where bytes are needed. Signed-off-by: NSimon Glass <sjg@chromium.org>
-
- 02 11月, 2019 2 次提交
-
-
由 Simon Glass 提交于
This entry is used to hold an Intel FSP-T (Firmware Support Package Temp-RAM init) binary. Add support for this in binman. Signed-off-by: NSimon Glass <sjg@chromium.org> Reviewed-by: NBin Meng <bmeng.cn@gmail.com>
-
由 Simon Glass 提交于
This entry is used to hold an Intel FSP-S (Firmware Support Package Silicon init) binary. Add support for this in binman. Signed-off-by: NSimon Glass <sjg@chromium.org> Reviewed-by: NBin Meng <bmeng.cn@gmail.com>
-
- 15 10月, 2019 19 次提交
-
-
由 Simon Glass 提交于
This code is not needed so drop it. Signed-off-by: NSimon Glass <sjg@chromium.org>
-
由 Simon Glass 提交于
The Intel FSP supports initialising memory early during boot using a binary blob called 'fspm'. Add support for this. Signed-off-by: NSimon Glass <sjg@chromium.org>
-
由 Simon Glass 提交于
It is useful to be able to access the size of an image in SPL, with something like: binman_sym_declare(unsigned long, u_boot_any, size); ... ulong u_boot_size = binman_sym(ulong, u_boot_any, size); Add support for this and update the tests. Signed-off-by: NSimon Glass <sjg@chromium.org>
-
由 Simon Glass 提交于
At present these are large enough to hold 20 bytes of symbol data. Add four more bytes so we can add another test. Unfortunately at present this involves changing a few test files to make room. We could adjust the test files to not specify sizes for entries. Then we could make the tests check the actual sizes. But for now, leave it as it is, since the effort is minor. Signed-off-by: NSimon Glass <sjg@chromium.org>
-
由 Simon Glass 提交于
Entries which include a section and need to obtain its contents call GetData(), as with any other entry. But the current implementation of this method in entry_Section requires the size of the section to be known. If it is unknown, an error is produced, since size is None: TypeError: can't multiply sequence by non-int of type 'NoneType' There is no need to know the size in advance since the code can be adjusted to build up the section piece by piece, instead of patching each entry into an existing bytearray. Update the code to handle this and add a test. Signed-off-by: NSimon Glass <sjg@chromium.org>
-
由 Simon Glass 提交于
Two of the test files somehow were not converted to three digits. Fix them, using the next available numbers. Signed-off-by: NSimon Glass <sjg@chromium.org>
-
由 Simon Glass 提交于
At present a small number of test files use hyphens instead of underscores. Rename them for consistency. Signed-off-by: NSimon Glass <sjg@chromium.org>
-
由 Simon Glass 提交于
At present we only support symbols inside binaries which are at the top level of an image. This restrictions seems unreasonable since more complex images may want to group binaries within different sections. Relax the restriction, adding a new _SetupTplElf() helper function. Also fix a typo in the comment for testTpl(). Signed-off-by: NSimon Glass <sjg@chromium.org>
-
由 Simon Glass 提交于
We use the Makefile for all ELF test files now, so drop all the code that checks whether to get the test file from the Makefile or from the git repo. Also add a comment to the Makefile indicating that it is run from binman. Signed-off-by: NSimon Glass <sjg@chromium.org>
-
由 Simon Glass 提交于
Remove this file from git and instead build it using the Makefile. Signed-off-by: NSimon Glass <sjg@chromium.org>
-
由 Simon Glass 提交于
Remove this file from git and instead build it using the Makefile. With this change a few things need to be adjusted: 1. The 'notes' section no-longer appears at the start of the ELF file (before the code), so update testSymbols to adjust the offsets. 2. The dynamic linker is disabled to avoid errors like: "Not enough room for program headers, try linking with -N" 3. The interpreter note is moved to the end of the image, so that the binman symbols appear first. Signed-off-by: NSimon Glass <sjg@chromium.org>
-
由 Simon Glass 提交于
Remove this file from git and instead build it using the Makefile. Signed-off-by: NSimon Glass <sjg@chromium.org>
-
由 Simon Glass 提交于
Remove this file from git and instead build it using the Makefile. Update tools.GetInputFilename() to support reading files from an absolute path, so that we can read the Elf test files easily. Also make sure that the temp directory is report in ELF tests as this was commented out. Signed-off-by: NSimon Glass <sjg@chromium.org>
-
由 Simon Glass 提交于
At present the ELF test files are checked into the U-Boot tree. This is covenient since the files never change and can be used on non-x86 platforms. However it is not good practice to check in binaries and in this case it does not seem essential. Update the binman test-file Makefile to support having source in a different directory. Adjust binman to run it to build bss_data, as a start. We can add other files as needed. Signed-off-by: NSimon Glass <sjg@chromium.org>
-
由 Simon Glass 提交于
At present this entry does not work correctly when a FIT image is used as the input. It updates the FIT instead of the output image. The test passed because the FIT image happened to have the right data already. Fix it. Signed-off-by: NSimon Glass <sjg@chromium.org>
-
由 Simon Glass 提交于
A Firmware Image Table (FIT) is a data structure defined by Intel which contains information about various things needed by the SoC, such as microcode. Add support for this entry as well as the pointer to it. The contents of FIT are fixed at present. Future work is needed to support adding microcode, etc. Signed-off-by: NSimon Glass <sjg@chromium.org>
-
由 Simon Glass 提交于
At present these two sections of code are linked together into a single 2KB chunk in a single file. Some Intel SoCs like to have a FIT (Firmware Interface Table) in the ROM and the pointer for this needs to go at 0xffffffc0 which is in the middle of these two sections. Make use of the new 'reset' entry and change the existing 16-bit entry to include just the 16-bit data. Signed-off-by: NSimon Glass <sjg@chromium.org>
-
由 Simon Glass 提交于
At present binman has a single entry type for the 16-bit code code needed to start up an x86 processor. This entry is intended to include both the reset vector itself as well as the code to move to 32-bit mode. However this is not very flexible since in some cases other data needs to be included at the top of the SPI flash, in between these two pieces. For example Intel requires that a FIT (Firmware Image Table) pointer be placed 0x40 bytes before the end of the ROM. To deal with this, add a new reset entry for just the reset vector. A subsequent change will adjust the existing 'start16' entry. Signed-off-by: NSimon Glass <sjg@chromium.org>
-
由 Simon Glass 提交于
It is more common to use the name 'cls' for the class object of a class method, to distinguish it from normal methods, which use 'self' Update the binman tests accordingly. Signed-off-by: NSimon Glass <sjg@chromium.org>
-
- 29 7月, 2019 12 次提交
-
-
由 Simon Glass 提交于
Add a 'replace' command to binman to permit entries to be replaced, either individually or all at once (using a filter). Signed-off-by: NSimon Glass <sjg@chromium.org>
-
由 Simon Glass 提交于
At present this message references -o for output file. But binman uses -f now. Fix it. Signed-off-by: NSimon Glass <sjg@chromium.org>
-
由 Simon Glass 提交于
At present some tests leave behind output directories. This happens because some tests call binman, which sets up an output directory, then call it again, which sets up another output directory and leaves the original one behind. Fix this by using a separate temporary directory when binman is called twice, or by manually removing the output directory. Signed-off-by: NSimon Glass <sjg@chromium.org>
-
由 Simon Glass 提交于
Put tearDown()'s logic into a new _CleanupOutputDir() function so that it can be called from elsewhere. Signed-off-by: NSimon Glass <sjg@chromium.org>
-
由 Simon Glass 提交于
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: NSimon Glass <sjg@chromium.org>
-
由 Simon Glass 提交于
The Intel descriptor must always appear at the start of an (x86) image, so it is supposed to position itself there always. However there is no explicit test for this. Add one and fix a bug introduced by the recent change to adjust Entry to read the node in a separate call. Signed-off-by: NSimon Glass <sjg@chromium.org>
-
由 Simon Glass 提交于
Sometimes an entry may shrink after it has already been packed. In that case we must repack the items. Of course it is always possible to just leave the entry at its original size and waste space at the end. This is what binman does by default, since there is the possibility of the entry changing size every time binman calculates its contents, thus causing a loop. Signed-off-by: NSimon Glass <sjg@chromium.org>
-
由 Simon Glass 提交于
Sometimes entries shrink after packing. As a start towards supporting this, update the _testing entry to handle the test case. Signed-off-by: NSimon Glass <sjg@chromium.org>
-
由 Simon Glass 提交于
So far we don't allow entries to change size when repacking. But this is not very useful since it is common for entries to change size after an updated binary is built, etc. Add support for this, respecting the original offset/size/alignment constraints of the image layout. For this to work the original image must have been created with the 'allow-repack' property. This does not support entry types with sub-entries such as files and CBFS, but it does support sections. Signed-off-by: NSimon Glass <sjg@chromium.org>
-
由 Simon Glass 提交于
The positioning does not currently work correctly if at the end of an image with no fixed size. Also if the header is in the middle of an image it can cause a gap in the image since the header position is normally at the image end, so entries after it are placed after the end of the image. Fix these problems and add more tests to cover these cases. Signed-off-by: NSimon Glass <sjg@chromium.org>
-
由 Simon Glass 提交于
At present it is not possible to discover the contraints to repacking an image (e.g. maximum section size) since this information is not preserved from the original image description. Add new 'orig-offset' and 'orig-size' properties to hold this. Add them to the main device tree in the image. Signed-off-by: NSimon Glass <sjg@chromium.org>
-
由 Simon Glass 提交于
While it is useful and efficient to build images in a single pass from a unified description, it is sometimes desirable to update the image later. Add support for replace an existing file with one of the same size. This avoids needing to repack the file. Support for more advanced updates will come in future patches. Signed-off-by: NSimon Glass <sjg@chromium.org>
-