e74429bb | 10-Dec-2018 |
Simon Glass <sjg@chromium.org> |
buildman: Deal nicely with invalid build-status file
The 'done' files created by buildman may end up being empty if buildman runs out of disk space while writing them. This error is then persistent,
buildman: Deal nicely with invalid build-status file
The 'done' files created by buildman may end up being empty if buildman runs out of disk space while writing them. This error is then persistent, since even if disk space is reclaimed and the build retries, the empty file causes an exception in the builder thread.
Deal with this silently by doing a rebuild.
Signed-off-by: Simon Glass <sjg@chromium.org>
show more ...
|
74473ed0 | 11-Dec-2018 |
Andy Shevchenko <andriy.shevchenko@linux.intel.com> |
tools: mtk_image: replace strncpy(d, s, sizeof(d)) with snprintf()
Starting from version 8 the GCC, i.e. C compiler, starts complaining about possible '\0' terminator loss or, as in this case, garba
tools: mtk_image: replace strncpy(d, s, sizeof(d)) with snprintf()
Starting from version 8 the GCC, i.e. C compiler, starts complaining about possible '\0' terminator loss or, as in this case, garbage copy.
In function ‘mtk_image_set_gen_header’, inlined from ‘mtk_image_set_header’ at tools/mtk_image.c:733:3: tools/mtk_image.c:659:2: warning: ‘strncpy’ specified bound 12 equals destination size [-Wstringop-truncation] strncpy(hdr->boot.name, bootname, sizeof(hdr->boot.name)); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ In function ‘mtk_brom_parse_imagename’, inlined from ‘mtk_image_check_params’ at tools/mtk_image.c:388:9: tools/mtk_image.c:325:5: warning: ‘strncpy’ specified bound 32 equals destination size [-Wstringop-truncation] strncpy(lk_name, val, sizeof(lk_name)); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Replace it with snprintf() to tell compiler how much room we have in the destination buffer for source string.
Fixes: 3b975a147c3c ("tools: MediaTek: add MTK boot header generation to mkimage") Cc: Ryder Lee <ryder.lee@mediatek.com> Cc: Weijie Gao <weijie.gao@mediatek.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Weijie Gao <weijie.gao@mediatek.com>
show more ...
|
b11f1264 | 21-Nov-2018 |
Trevor Woerner <trevor@toganlabs.com> |
buildman/toolchain.py: handle inconsistent tarball names
Unfortunately, for some releases the kernel.org toolchain tarball names adhere to the following pattern:
<hostarch>-gcc-<ver>-nolib-<target
buildman/toolchain.py: handle inconsistent tarball names
Unfortunately, for some releases the kernel.org toolchain tarball names adhere to the following pattern:
<hostarch>-gcc-<ver>-nolib-<targetarch>-<type>.tar.xz
e.g.: x86_64-gcc-8.1.0-nolibc-aarch64-linux.tar.xz
while others use the following pattern:
<hostarch>-gcc-<ver>-nolib_<targetarch>-<type>.tar.xz
e.g.:
x86_64-gcc-7.3.0-nolibc_aarch64-linux.tar.xz
Notice that the first pattern has dashes throughout, while the second has dashes throughout except just before the target architecture which has an underscore.
The "dash throughout" versions from kernel.org are:
8.1.0, 6.4.0, 5.5.0, 4.9.4, 4.8.5, 4.6.1
while the "dash and underscore" versions from kernel.org are:
7.3.0, 4.9.0, 4.8.0, 4.7.3, 4.6.3, 4.6.2, 4.5.1, 4.2.4
This tweak allows the code to handle both versions. Note that this tweak also causes the architecture parsing to get confused and find the following two bogus architectures, "2.0" and "64", which are explicitly checked for, and removed.
Signed-off-by: Trevor Woerner <trevor@toganlabs.com> Reviewed-by: Simon Glass <sjg@chromium.org> Change single quotes to double quotes: Signed-off-by: Simon Glass <sjg@chromium.org>
show more ...
|
4b6dbaa3 | 06-Nov-2018 |
Simon Glass <sjg@chromium.org> |
binman: Set the pathname correctly for ELF files
At present, stripped files don't have the right pathname which means that blob compression cannot be used. Fix this.
Signed-off-by: Simon Glass <sjg
binman: Set the pathname correctly for ELF files
At present, stripped files don't have the right pathname which means that blob compression cannot be used. Fix this.
Signed-off-by: Simon Glass <sjg@chromium.org>
show more ...
|