Rather than naming the phandle struct according to the number of cells it
uses (e.g. struct phandle_2_cell) name it according to the number of
arguments it has (e.g. struct phandle_1_arg). This is a more intuitive
naming.
Signed-off-by: Simon Glass <sjg@chromium.org>
Tested-by: Kever Yang <kever.yang@rock-chips.com>
Update this function to return more detail about a property that contains
phandles. This will allow (in a future commit) more accurate handling of
these properties.
Signed-off-by: Simon Glass <sjg@chromium.org>
Tested-by: Kever Yang <kever.yang@rock-chips.com>
This function will need to have access to class members once we enhance it
to support multiple phandle values. In preparation for that, move it into
the class.
Signed-off-by: Simon Glass <sjg@chromium.org>
Tested-by: Kever Yang <kever.yang@rock-chips.com>
Now that the Fdt class can map phandles to the associated nodes, use that
instead of a separate implementation.
Signed-off-by: Simon Glass <sjg@chromium.org>
Tested-by: Kever Yang <kever.yang@rock-chips.com>
Add a map from phandles to nodes. This can be used by clients of the the
class instead of maintaining this themselves.
Signed-off-by: Simon Glass <sjg@chromium.org>
Tested-by: Kever Yang <kever.yang@rock-chips.com>
At present dtoc assumes that all 'reg' properties have both an address and
a size. For I2C devices we do not have this. Adjust dtoc to cope.
Reported-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
Signed-off-by: Simon Glass <sjg@chromium.org>
Tested-by: Kever Yang <kever.yang@rock-chips.com>
When using 32-bit addresses dtoc works correctly. For 64-bit addresses it
does not since it ignores the #address-cells and #size-cells properties.
Update the tool to use fdt64_t as the element type for reg properties when
either the address or size is larger than one cell. Use the correct value
so that C code can obtain the information from the device tree easily.
Alos create a new type, fdt_val_t, which is defined to either fdt32_t or
fdt64_t depending on the word size of the machine. This type corresponds
to fdt_addr_t and fdt_size_t. Unfortunately we cannot just use those types
since they are defined to phys_addr_t and phys_size_t which use
'unsigned long' in the 32-bit case, rather than 'unsigned int'.
Add tests for the four combinations of address and size values (32/32,
64/64, 32/64, 64/32). Also update existing uses for rk3399 and rk3368
which now need to use the new fdt_val_t type.
Signed-off-by: Simon Glass <sjg@chromium.org>
Suggested-by: Heiko Stuebner <heiko@sntech.de>
Reported-by: Kever Yang <kever.yang@rock-chips.com>
Reviewed-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
Tested-by: Kever Yang <kever.yang@rock-chips.com>
Large arrays can result in lines with hundreds or thousands of characters
which is not very editor-friendly. To avoid this, addjust the tool to
group values 8 per line.
Signed-off-by: Simon Glass <sjg@chromium.org>
Tested-by: Kever Yang <kever.yang@rock-chips.com>
When dealing with multi-cell values we need a type that can hold this
value. Add this and a function to process it from a list of cell values.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
Tested-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
Tested-by: Kever Yang <kever.yang@rock-chips.com>
We need to be able to search back up the tree for #address-cells and
#size-cells. Record the parent of each node to make this easier.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
Tested-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
Tested-by: Kever Yang <kever.yang@rock-chips.com>
In order to display the company's logo via the API of DM_VIDEO,
and add the logo files of both Atmel and Microchip.
Signed-off-by: Wenyou Yang <wenyou.yang@microchip.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
This section of the settings file may be missing. Handle that gracefully
rather than emitting an error.
Also update patman to write this section when a new settings file is
created.
Fixes: e11aa602 (patman: add support for omitting bouncing addresses)
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Chris Packham <judge.pckham@gmail.com>
Tested-by: Bin Meng <bmeng.cn@gmail.com>
Add support for reading a list of bouncing addresses from a in-tree file
(doc/bounces) and from the ~/.patman config file. These addresses are
stripped from the Cc list.
Signed-off-by: Chris Packham <judge.packham@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com <mailto:philipp.tomsich@theobroma-systems.com>>
Adjust this code so that it can work with Python 2 and 3.
Fixes: d73fcb1 (moveconfig: Support building a simple config database)
Reported-by: Chris Packham <judge.packham@gmail.com>
Signed-off-by: Simon Glass <sjg@chromium.org>
At present we sometimes see warnings of the form:
/tmp/tmpMA89kB:36: warning: overriding the value of CMD_SPL.
Old value: "y", new value: "y".
This is not very useful as it does not show whch defconfig file it relates
to. Update the tool to show this.
Signed-off-by: Simon Glass <sjg@chromium.org>
Some files are generated during libfdt build. Ignore them.
This was wrongly put in the .gitignore in the root directory before.
Now let's remove entries there and put them in the right place.
Fixes: 34e2c285 ("gitignore: add intermediates from libfdt build")
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
This was broken by the recent environment refactoring. Specifically:
$ make environ
scripts/Makefile.build:59: tools/environ/Makefile: No such file or directory
make[1]: *** No rule to make target 'tools/environ/Makefile'. Stop.
make: *** [Makefile:1469: environ] Error 2
Fix this by updating the Makefile and adjusting the #include filesnames in
two C files.
Fixes: ec74f5f (Makefile: Rename 'env' target to 'environ')
Reported-by: Måns Rullgård <mans@mansr.com>
Signed-off-by: Simon Glass <sjg@chromium.org>
With the move of environment code from common/ to env/ a number of
changes needed to be made to various make targets. We missed updating
some of the files required for out of tree builds of the tools. Correct
the 'environ' target to know that we need to work under tools/env/ still
(not tools/environ/) and then update the wrappers in env_attr.c and
env_flags.c to point to the new correct file.
Reported-by: Peter Robinson <pbrobinson@gmail.com>
Tested-by: Peter Robinson <pbrobinson@gmail.com>
Signed-off-by: Tom Rini <trini@konsulko.com>
This should not be printed by default. Prefix it with $(Q).
Fixes ee95d10b: ("fdt: Build the new python libfdt module")
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Since commit 3809e302 "Makefile: honor PYTHON configuration properly",
the build commands of libfdt are printed while previously were not.
This adds the missing '--quiet' back.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
According to fsync specification [1] some special files (e.g., a pipe, FIFO,
or socket) don't support synchronization and return either EROFS or EINVAL.
On the linux side the sys_fsync -> do_fsync() checks if the requested file
has f_op->fsync defined. If not it returns EINVAL [2].
This commit prevents writing error messages for files (devices), which
do not support fsync().
[1] - http://man7.org/linux/man-pages/man2/fsync.2.html
[2] - http://elixir.free-electrons.com/linux/v4.13-rc6/source/fs/sync.c#L183
Signed-off-by: Lukasz Majewski <lukma@denx.de>
Acked-by: Michael Heimpold <mhei@heimpold.de>
Move the imximage.h header file to a common location so we can make
use of it from U-Boot too.
Signed-off-by: Stefan Agner <stefan.agner@toradex.com>
Reviewed-by: Łukasz Majewski <lukma@denx.de>
On some systems `python` is `python3` (for instance, Archlinux). The
`PYTHON` variable can be used to point to `python2` to have a successful
build.
The use of `PYTHON` is currently limited in the Makefile and needs to be
extended in other places:
First, pylibfdt is required to be a Python 2 binding (binman imports
pylibfdt and is only compatible Python 2), so its setup.py needs to be
called accordingly. An alternative would be to change the libfdt
setup.py shebang to python2, but the binding is actually portable. Also,
it would break on system where there is no such thing as `python2`.
Secondly, the libfdt import checks need to be done against Python 2 as
well since the Python 2 compiled modules (in this case _libdft.so) can
not be imported from Python 3.
Note on the libfdt imports: "@if ! PYTHONPATH=tools $(PYTHON) -c 'import
libfdt'; then..." is probably simpler than the currently sub-optimal
pipe.
Reviewed-by: Jonathan Gray <jsg@jsg.id.au>
We are now using an env_ prefix for environment functions. Rename setenv()
for consistency. Also add function comments in common.h.
Suggested-by: Wolfgang Denk <wd@denx.de>
Signed-off-by: Simon Glass <sjg@chromium.org>
About a quarter of the files in common/ relate to the environment. It
seems better to put these into their own subdirectory and remove the
prefix.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
This commit adds support for RK3368 SoC in mkimage.
Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
It seems that gcc 6.3 at least is smart enough to warn about the _val
variable being unassigned in the default case in the set_hdr_field()
macro, but not smart enough to figure out that the default case is never
taken. This results in warnings such as the following:
pfx##hdr32[idx].field = _val; \
^
../tools/mips-relocs.c:51:11: note: _val was declared here
uint64_t _val; \
^
../tools/mips-relocs.c:88:2: note: in expansion of macro set_hdr_field
set_hdr_field(p, idx, field, val)
^~~~~~~~~~~~~
../tools/mips-relocs.c:408:3: note: in expansion of macro set_phdr_field
set_phdr_field(i, p_filesz, load_sz);
^~~~~~~~~~~~~~
../tools/mips-relocs.c: In function main:
../tools/mips-relocs.c:77:25: warning: _val may be used uninitialized
in this function [-Wmaybe-uninitialized]
Avoid this by assigning _val = 0 in the default case, and asserting that
we didn't actually hit it for good measure.
For reference gcc 7.1.1 seems to be smart enough to not hit the above
warning without this patch.
Signed-off-by: Paul Burton <paul.burton@imgtec.com>
Fixes: 011dd93ca97a ("MIPS: Stop building position independent code")
Cc: Daniel Schwierzeck <daniel.schwierzeck@gmail.com>
Cc: Tom Rini <trini@konsulko.com>
Cc: u-boot@lists.denx.de
U-Boot has up until now built with -fpic for the MIPS architecture,
producing position independent code which uses indirection through a
global offset table, making relocation fairly straightforward as it
simply involves patching up GOT entries.
Using -fpic does however have some downsides. The biggest of these is
that generated code is bloated in various ways. For example, function
calls are indirected through the GOT & the t9 register:
8f998064 lw t9,-32668(gp)
0320f809 jalr t9
Without -fpic the call is simply:
0f803f01 jal be00fc04 <puts>
This is more compact & faster (due to the lack of the load & the
dependency the jump has on its result). It is also easier to read &
debug because the disassembly shows what function is being called,
rather than just an offset from gp which would then have to be looked up
in the ELF to discover the target function.
Another disadvantage of -fpic is that each function begins with a
sequence to calculate the value of the gp register, for example:
3c1c0004 lui gp,0x4
279c3384 addiu gp,gp,13188
0399e021 addu gp,gp,t9
Without using -fpic this sequence no longer appears at the start of each
function, reducing code size considerably.
This patch switches U-Boot from building with -fpic to building with
-fno-pic, in order to gain the benefits described above. The cost of
this is an extra step during the build process to extract relocation
data from the ELF & write it into a new .rel section in a compact
format, plus the added complexity of dealing with multiple types of
relocation rather than the single type that applied to the GOT. The
benefit is smaller, cleaner, more debuggable code. The relocate_code()
function is reimplemented in C to handle the new relocation scheme,
which also makes it easier to read & debug.
Taking maltael_defconfig as an example the size of u-boot.bin built
using the Codescape MIPS 2016.05-06 toolchain (gcc 4.9.2, binutils
2.24.90) shrinks from 254KiB to 224KiB.
Signed-off-by: Paul Burton <paul.burton@imgtec.com>
Cc: Daniel Schwierzeck <daniel.schwierzeck@gmail.com>
Cc: u-boot@lists.denx.de
Reviewed-by: Daniel Schwierzeck <daniel.schwierzeck@gmail.com>
Tested-by: Daniel Schwierzeck <daniel.schwierzeck@gmail.com>
It is annoying to have to set up and maintain two sets of toolchains, one
for buildman and one for moveconfig.
Adjust moveconfig to make use to buildman's toolchains. This should make
things easier.
One missing feature is the ability to specify the toolchain on the command
line with a special environment variable, e.g. CROSS_COMPILE_ARM. I'm not
sure if that is useful, but if it is it could be implemented in buildman.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
Tested-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
Add an option to specify 'all' to enable all flags. Also print an error
if an unrecognised flag is used. At present it just prints usage
information which is not very helpful.
Signed-off-by: Simon Glass <sjg@chromium.org>
FreeBSD recently switch to it's BSDL dtc. While it support most of the
features of the GPL one it still lacks the incbin directive.
Add the possibility to specify which dtc we want to use for compiling dts
and generating fit image.
Signed-off-by: Emmanuel Vadot <manu@bidouilliste.com>
Acked-by: Simon Glass <sjg@chromium.org>
Closing a file descriptor does not guarantee that the data has been
successfully saved to disk, as the kernel might defer the write.
Signed-off-by: Michael Heimpold <mhei@heimpold.de>
Change is consistent with other SOCs and it is in preparation
for adding SOMs. SOC's related files are moved from cpu/ to
mach-imx/<SOC>.
This change is also coherent with the structure in kernel.
Signed-off-by: Stefano Babic <sbabic@denx.de>
CC: Fabio Estevam <fabio.estevam@nxp.com>
CC: Akshay Bhat <akshaybhat@timesys.com>
CC: Ken Lin <Ken.Lin@advantech.com.tw>
CC: Marek Vasut <marek.vasut@gmail.com>
CC: Heiko Schocher <hs@denx.de>
CC: "Sébastien Szymanski" <sebastien.szymanski@armadeus.com>
CC: Christian Gmeiner <christian.gmeiner@gmail.com>
CC: Stefan Roese <sr@denx.de>
CC: Patrick Bruenn <p.bruenn@beckhoff.com>
CC: Troy Kisky <troy.kisky@boundarydevices.com>
CC: Nikita Kiryanov <nikita@compulab.co.il>
CC: Otavio Salvador <otavio@ossystems.com.br>
CC: "Eric Bénard" <eric@eukrea.com>
CC: Jagan Teki <jagan@amarulasolutions.com>
CC: Ye Li <ye.li@nxp.com>
CC: Peng Fan <peng.fan@nxp.com>
CC: Adrian Alonso <adrian.alonso@nxp.com>
CC: Alison Wang <b18965@freescale.com>
CC: Tim Harvey <tharvey@gateworks.com>
CC: Martin Donnelly <martin.donnelly@ge.com>
CC: Marcin Niestroj <m.niestroj@grinn-global.com>
CC: Lukasz Majewski <lukma@denx.de>
CC: Adam Ford <aford173@gmail.com>
CC: "Albert ARIBAUD (3ADEV)" <albert.aribaud@3adev.fr>
CC: Boris Brezillon <boris.brezillon@free-electrons.com>
CC: Soeren Moch <smoch@web.de>
CC: Richard Hu <richard.hu@technexion.com>
CC: Wig Cheng <wig.cheng@technexion.com>
CC: Vanessa Maegima <vanessa.maegima@nxp.com>
CC: Max Krummenacher <max.krummenacher@toradex.com>
CC: Stefan Agner <stefan.agner@toradex.com>
CC: Markus Niebel <Markus.Niebel@tq-group.com>
CC: Breno Lima <breno.lima@nxp.com>
CC: Francesco Montefoschi <francesco.montefoschi@udoo.org>
CC: Jaehoon Chung <jh80.chung@samsung.com>
CC: Scott Wood <oss@buserror.net>
CC: Joe Hershberger <joe.hershberger@ni.com>
CC: Anatolij Gustschin <agust@denx.de>
CC: Simon Glass <sjg@chromium.org>
CC: "Andrew F. Davis" <afd@ti.com>
CC: "Łukasz Majewski" <l.majewski@samsung.com>
CC: Patrice Chotard <patrice.chotard@st.com>
CC: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
CC: Hans de Goede <hdegoede@redhat.com>
CC: Masahiro Yamada <yamada.masahiro@socionext.com>
CC: Stephen Warren <swarren@nvidia.com>
CC: Andre Przywara <andre.przywara@arm.com>
CC: "Álvaro Fernández Rojas" <noltari@gmail.com>
CC: York Sun <york.sun@nxp.com>
CC: Xiaoliang Yang <xiaoliang.yang@nxp.com>
CC: Chen-Yu Tsai <wens@csie.org>
CC: George McCollister <george.mccollister@gmail.com>
CC: Sven Ebenfeld <sven.ebenfeld@gmail.com>
CC: Filip Brozovic <fbrozovic@gmail.com>
CC: Petr Kulhavy <brain@jikos.cz>
CC: Eric Nelson <eric@nelint.com>
CC: Bai Ping <ping.bai@nxp.com>
CC: Anson Huang <Anson.Huang@nxp.com>
CC: Sanchayan Maity <maitysanchayan@gmail.com>
CC: Lokesh Vutla <lokeshvutla@ti.com>
CC: Patrick Delaunay <patrick.delaunay@st.com>
CC: Gary Bisson <gary.bisson@boundarydevices.com>
CC: Alexander Graf <agraf@suse.de>
CC: u-boot@lists.denx.de
Reviewed-by: Fabio Estevam <fabio.estevam@nxp.com>
Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>
The verify_header callback in kwbimage.c only verifies v0 headers checksum.
Running 'mkimage -l' on a v1 image gives the following misleading output:
GP Header: Size ae000000 LoadAddr 34160600
Implement support for v1 headers. For that, factor out the header checksum code
to a separate main_hdr_checksum_ok() routine. This routine relies on the fact
that the checksum field offset is the same in both v0 and v1 headers. With this
patch applied 'mkimage -l' correctly identifies the image:
Image Type: MVEBU Boot from sdio Image
Image version:1
Data Size: 398904 Bytes = 389.55 KiB = 0.38 MiB
Load Address: 007fffc0
Entry Point: 00800000
Signed-off-by: Baruch Siach <baruch@tkos.co.il>
Signed-off-by: Stefan Roese <sr@denx.de>
The offset marking in kwbimage.h is inconsistent. main_hdr_v0 uses decimals,
main_hdr_v1 uses hex without '0x' prefix, secure_hdr_v1 uses hex with '0x'
prefix. Make all offset marks hex with '0x' prefix.
Signed-off-by: Baruch Siach <baruch@tkos.co.il>
Signed-off-by: Stefan Roese <sr@denx.de>
If a system module is named the same as one of those used by binman we
currently pick the system module. Adjust the ordering so that our modules
are chosen instead.
The module conflict reported was 'tools' from jira-python. I cannot access
that package to test it.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reported-by: Kevin Hilman <khilman@baylibre.com>
Acked-by: Kevin Hilman <khilman@baylibre.com>
This function uses several separate string replaces where a regular
expression might seem more reasonable. Add a comment justifying the way it
is currently done.
Signed-off-by: Simon Glass <sjg@chromium.org>
Collect the main logic of dtoc into a function and put it into
dtb_platdata. This will allow tests to use this function instead of
duplicating the code themselves.
Signed-off-by: Simon Glass <sjg@chromium.org>
Rather than using static functions within the class, move them out of the
class. This will make it slightly easier for tests to call them.
Signed-off-by: Simon Glass <sjg@chromium.org>
This option is the only one actually used by the dtb_platdata class. Pass
it explicitly to avoid needing to pass the whole option object to the
constructor.
Signed-off-by: Simon Glass <sjg@chromium.org>
To simplify running tests we should move this class into its own file.
This allows the tests to import it without having to import dtoc.py, which
runs the tests.
Signed-off-by: Simon Glass <sjg@chromium.org>
By using a Kconfig parser we can find the location of each option in the
Kconfig tree. Using the information from the database we can then
automatically add an 'imply' option into the right place if requested by
the user.
Add a -a option to support adding 'imply' options. Display the location of
any existing 'imply' option so that progress can be examined. Add a -A
option to hide any existing 'imply' options so that already-completed
additions need not be considered further.
Also add documentation for this feature.
Signed-off-by: Simon Glass <sjg@chromium.org>
Sometimes it is useful to display CONFIG_TARGET or CONFIG_CMD configs. Add
an option to control this.
Also we generally ignore implying configs which affect fewer than 5
boards. But sometimes it is useful to show those those, so add an option
that reduces the minimum to two.
ERRATUM configs are never useful for implying things, so ignore those.
Signed-off-by: Simon Glass <sjg@chromium.org>
It is useful to be able to process only a subset of boards to save time.
Often that subset is defined by the defconfig files in a git commit. This
change allows things like:
# Build the database
./tools.moveconfig.py -b
# Find some implying configs
./tools/moveconfig.py -i CONFIG_X
# Add some 'imply' statements to Kconfig files
./tools/moveconfig.py -i CONFIG_X -a CONFIG_A,CONFIG_B
# Reprocess the defconfig files to see if we can drop some changes
git show --stat | ./tools/moveconfig.py -s -d -
# Update the commit, with fewer defconfig changes
gii commit -au
Where the commit contains defconfig files, this will reprocess them to
take account of the imply statements that you added.
Signed-off-by: Simon Glass <sjg@chromium.org>
Sometimes a node will have multiple compatible strings. Drivers may use
one or the other so the best approach seems to be to #define them to be
equivalent.
Update dtoc to support this.
Signed-off-by: Simon Glass <sjg@chromium.org>
Tested-by: Kever Yang <kever.yang@rock-chips.com>
Some CONFIG options can be implied by others and this can help to reduce
the size of the defconfig files. For example, CONFIG_X86 implies
CONFIG_CMD_IRQ, so we can put 'imply CMD_IRQ' under 'config X86' and
all x86 boards will have that option, avoiding adding CONFIG_CMD_IRQ to
each of the x86 defconfig files.
Add a -i option which searches for such options.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Heiko Schocher <hs@denx.de>
Add a -b option which scans all the defconfigs and builds a database of
all the CONFIG options used by each. This is useful for querying later.
At present this only works with the separate -b option, which does not
move any configs. It would be possible to adjust the script to build the
database automatically when moving configs, but this might not be useful
as the database does not change that often.
Signed-off-by: Simon Glass <sjg@chromium.org>
The newest clean-up features are not mentioned in the docs. Fix this and
add a few hints for particular workflows that are hopefully helpful.
Signed-off-by: Simon Glass <sjg@chromium.org>
It is convenient to provide the full patch to the defconfig files in some
situations, e.g. when the file was generated by a shell command (e.g.
'ls configs/zynq*').
Add support for this, and move the globbing code into a function with its
own documentation.
Signed-off-by: Simon Glass <sjg@chromium.org>
Add support for rk322x package header in mkimage tool.
Signed-off-by: Kever Yang <kever.yang@rock-chips.com>
Reviewed-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
AVR32 is gone. It's already more than two years for no support in Buildroot,
even longer there is no support in GCC (last version is heavily patched 4.2.4).
Linux kernel v4.12 got rid of it (and v4.11 didn't build successfully).
There is no good point to keep this support in U-Boot either.
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Heiko Schocher <hs@denx.de>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Since commit 5b9d44df23 (mkimage: Display a better list of available image
types) mkimage usage text suggest to "use -T to see a list of available image
types". Unfortunately, commit 02221f29deb8 (mkimage: Convert to use getopt())
broke that feature, because getopt() fails when -T has no option argument.
Add a pseudo image type name 'list' that lists all image types. Update the
usage text accordingly.
Cc: Simon Glass <sjg@chromium.org>
Signed-off-by: Baruch Siach <baruch@tkos.co.il>
The maximum spl_size for rk3399 is the internal memory size minus
the size used in bootrom (which usually can get from SPL_TEXT_BASE).
Signed-off-by: Kever Yang <kever.yang@rock-chips.com>
Reviewed-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
This function is unused, remove. Reported by clang-3.8.
Fixes: a1c29d4b43 ("rockchip: mkimage: set init_boot_size to avoid ...")
Cc: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
refer in the README to tbots webpage, and delete
the README in tools/tbot, as the latest documentation
for tbot is on this webpage.
Signed-off-by: Heiko Schocher <hs@denx.de>
Assigning a variable to itself is not necessary. Drop this and also add a
check for malloc() failure.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reported-by: Coverity (CID: 161418)
Fixes: 111bcc4 (rockchip: mkimage: pad the header to 8-bytes (using a 'nop') for RK3399)
Since the parameter can be NULL we must be careful not to dereference it
in this case.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reported-by: Coverity (CID: 163250)
Fixes: 1043d0a0 (fdt: Add fdtgrep tool)
The kwbimage utility fails to compile when LibreSSL is present on
the host system instead of OpenSSL. This one-line patch resolves
this.
Signed-off-by: Marek Behun <marek.behun@nic.cz>
The build output can still produce unicode encoded output. But in
the buildman's log and err files we only want plain ASCII characters.
To handle all situations with unicode and non-unicode output, encode
the stdout and stderr strings to UTF-8 and afterwards to ASCII with
replacing all special characters.
Signed-off-by: Daniel Schwierzeck <daniel.schwierzeck@gmail.com>
Build tools like Make, gcc or binutils support localized output
or unicode encoded output dependent on the default system locale.
This is not useful for buildman, where we want reproducible
warning or error messages or where the output of binutils is
further processed.
Signed-off-by: Daniel Schwierzeck <daniel.schwierzeck@gmail.com>
The existing test (patman --test) only covers basic checkpatch output.
We have had some problems with unicode processing and could use test
coverage for the various tags patman supports.
Add a new functional test which runs most of the patman flow on a few
test commits and checks that the results are correct.
See the documentation in the test for a description of what it does.
Signed-off-by: Simon Glass <sjg@chromium.org>
Tested-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
This is not a good variable name in Python because 'list' is a type. It
shows up highlighted in some editors. Rename it.
Signed-off-by: Simon Glass <sjg@chromium.org>
Tested-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
Allow the add_maintainers parameter to be a list of maintainers, thus
allowing us to simulate calling the script in tests without actually
needing it to work.
Signed-off-by: Simon Glass <sjg@chromium.org>
Tested-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
Add some unicode to the test patches to make sure that patman does the
right thing.
Signed-off-by: Simon Glass <sjg@chromium.org>
Tested-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
There is no need for this function to return the same object that was
passed in. Drop the return value.
Signed-off-by: Simon Glass <sjg@chromium.org>
Tested-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
Unicode characters may appear in input patches so we should not warn about
them. Drop this warning.
Signed-off-by: Simon Glass <sjg@chromium.org>
Tested-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
This is not a good variable name in Python because 'str' is a type. It
shows up highlighted in some editors. Rename it.
Signed-off-by: Simon Glass <sjg@chromium.org>
Tested-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
The communication filter reads data in blocks and converts each block to
unicode (if necessary) one at a time. In the unlikely event that a unicode
character in the input spans a block this will not work. We get an error
like:
UnicodeDecodeError: 'utf8' codec can't decode bytes in position 1022-1023:
unexpected end of data
There is no need to change the input to unicode, so the easiest fix is to
drop this feature.
Signed-off-by: Simon Glass <sjg@chromium.org>
Tested-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
Don't mess with the email address when outputting them. Just make sure
they are encoded with utf-8.
Signed-off-by: Simon Glass <sjg@chromium.org>
Tested-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
This change encodes the CC list to UTF-8 to avoid failures on
maintainer-addresses that include non-ASCII characters (observed on
Debian 7.11 with Python 2.7.3).
Without this, I get the following failure:
Traceback (most recent call last):
File "tools/patman/patman", line 159, in <module>
options.add_maintainers)
File "[snip]/u-boot/tools/patman/series.py", line 234, in MakeCcFile
print(commit.patch, ', '.join(set(list)), file=fd)
UnicodeEncodeError: 'ascii' codec can't encode character u'\xfc' in position 81: ordinal not in range(128)
from Heiko's email address:
[..., u'"Heiko St\xfcbner" <heiko@sntech.de>', ...]
While with this change added this encodes to:
"=?UTF-8?q?Heiko=20St=C3=BCbner?= <heiko@sntech.de>"
Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Simon Glass <sjg@chromium.org>
Tested-by: Simon Glass <sjg@chromium.org>
Tested-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
In the case where a new build only decreases sizes and does not increase
any size we still want to report what functions have been dropped when
doing a bloat comparison.
Cc: Simon Glass <sjg@chromium.org>
Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Add support to mkimage for rv1108 soc, the max
spl code size for rv1108 is 6kb, and the spl
code should be packed by rksd, wether boot from
emmc or spi nor flash.
Signed-off-by: Andy Yan <andy.yan@rock-chips.com>
Reviewed-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
This change restores the earlier setting of init_boot_size to include
the maximum area covered by the the boot ROM of each chip for resolve
issues with back-to-bootrom functionality reported by Kever and Heiko.
To ensure that we don't run into the same issue again in the future,
I have updated the comments accordingly and added a reference to the
mailing list archive (there's some very helpful info from Andy Yan
that provides background on the BootROM requirements regarding these
fields).
See https://lists.denx.de/pipermail/u-boot/2017-May/293267.html for
some background (by Andy Yan) of how the BootROM processes this field.
Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
The Rockchip BootROM relies on init_size being aligned to 2KB
(see https://lists.denx.de/pipermail/u-boot/2017-May/293268.html).
This pads the image to 2KB both for SD card images and SPI images
and uses a common symbolic constant for the alignment.
Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
The rockchip image generation was previously missing the ability to
verify the generated header (and dump the image-type) without having
to resort to hexdump or od. Experience in our testing has showed it
to be very easy to get the rkspi and rksd images mixed up and the
lab... so we add the necessary support to have dumpimage tell us
what image type we're dealing with.
This change set adds the verify_header and print_header capability
to the rksd/rkspi image drivers (through shared code in rkcommon).
As of now, we only support images fully that are not RC4-encoded for
the SPL payload (i.e. header1 and payload). For RC4-encoded payloads,
the outer header (header0) is checked, but no detection of whether
this is a SD/MMC or SPI formatted payload takes place.
The output of dumpsys now prints the image type (spl_hdr), whether it
is a SD/MMC or SPI image, and the (padded) size of the image:
$ ./tools/dumpimage -l ./spl.img
Image Type: Rockchip RK33 (SD/MMC) boot image
^^^^^^ SD/MMC vs. SPI indication
^^^^ spl_hdr indicated by the image
Data Size: 79872 bytes
Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
Acked-by: Simon Glass <sjg@chromium.org>
This file was used to select between the normal and fallback libfdt
implementations. Now that we only have one, it is not needed.
Drop it and fix up all users.
Signed-off-by: Simon Glass <sjg@chromium.org>
Since we only have one Fdt implementation now we don't need to have a base
class. Merge the implementation and the base class together.
Signed-off-by: Simon Glass <sjg@chromium.org>
Previously we were sometimes forced to collate x86 microcode due to not
having access to the offset of each individual piece. Now that we never
use fdt_fallback, we don't have this problem. Drop this special case from
the code.
Signed-off-by: Simon Glass <sjg@chromium.org>
The tests don't currently cover all the different property types. Add a
new test which checks each property type in turn, to make sure each has
the correct type and value.
Signed-off-by: Simon Glass <sjg@chromium.org>
Since fdt is a module it conflicts with this variable name and prevents it
being used in tests. Rename the variable.
Signed-off-by: Simon Glass <sjg@chromium.org>
Build the upstream python libfdt module. At present the legacy module is
still built and is the one that it used. Future work will switch this
over.
Signed-off-by: Simon Glass <sjg@chromium.org>
Now that this module has been accepted upstream we should stop using the
local U-Boot one. In preparation for this, rename it to indicate it is for
legacy use.
Signed-off-by: Simon Glass <sjg@chromium.org>
At present only a subset of source files are build. Add the rest and
refactor this so that a source file list is available also. This will be
used in later commit.
Signed-off-by: Simon Glass <sjg@chromium.org>
image_version_file()'s only use is to return the version number of the
specified image, and it's only called by kwbimage_generate(). This
version function mallocs "image_cfg" and reads the contents of the image
into that buffer. Before return to its caller it frees the buffer.
After extracting the version, kwb_image_generate() tries to calculate
the header size by calling image_headersz_v1(). This function now
accesses "image_cfg", which has already been freed.
Since image_version_file() is only used by a single function, inline it
into kwbimage_generate() and only free the buffer after it is no longer
needed. This also improves code readability since the code is mostly
equal to kwbimage_set_header().
Signed-off-by: Patrick Wildt <patrick@blueri.se>
Signed-off-by: Stefan Roese <sr@denx.de>
This patch updates the mksunxiboot tool to optionally add
the default device tree name string to the SPL header. This
information can be used by the firmware upgrade tools to
protect users from harming themselves by trying to upgrade
to an incompatible bootloader.
The primary use case here is a non-removable bootable media
(such as NAND, eMMC or SPI flash), which already may have
a properly working, but a little bit outdated bootloader
installed. For example, the user may download or build a
new U-Boot image for "Cubieboard", and then attemept to
install it on a "Cubieboard2" hardware by mistake as a
replacement for the already existing bootloader. If this
happens, the flash programming tool can identify this
problem and warn the user.
The size of the SPL header is also increased from 64 bytes
to 96 bytes to provide enough space for the device tree name
string.
[Andre: split patch to remove OF_LIST hash feature]
Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com>
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
mksunxiboot limits the size of the resulting SPL binaries to pretty
conservative values to cover all SoCs and all boot media (NAND).
It turns out that we have limit checks in place in the build process,
so mksunxiboot can be relaxed and allow packaging binaries up to the
actual 32KB the mask boot ROM actually imposes.
This allows to have a bigger SPL, which is crucial for AArch64 builds.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Jagan Teki <jagan@openedev.com>
As per MAINTAINERS[1] file description, 'Supported' is
a valid status for a board. But buildman thinks 'Maintained'
is the only valid state and complains about boards with 'Supported'
status. Update buildman to accept 'Supported' as valid state.
[1] http://git.denx.de/?p=u-boot.git;a=blob;f=MAINTAINERS;h=0962b47bf9057b22e93624e070c0204b893790dc;hb=HEAD#l10
Reported-by: Sekhar Nori <nsekhar@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
The rsa_st struct has been made opaque in 1.1.x, add forward compatible
code to access the n, e, d members of rsa_struct.
EVP_MD_CTX_cleanup has been removed in 1.1.x and EVP_MD_CTX_reset should be
called to reinitialise an already created structure.
Signed-off-by: Jelle van der Waa <jelle@vdwaa.nl>
At present dtoc assumes that nodes which are phandles do not themselves
reference other phandle nodes. Unfortunately this is not necessarilly
true. As a result we can currently output C code which does not compile
because a node declaration can be referenced before it is declared.
Adjust the code to explicitly output all phandle nodes needed by node
before the node itself is output.
This fixes building with the latest rk3399-firefly.dts from Linux, which
has reordered the nodes.
Signed-off-by: Simon Glass <sjg@chromium.org>
Tested-by: Kever Yang <kever.yang@rock-chips.com>
The code to generate the tables is quite long. Move the node-output code
into its own function.
Signed-off-by: Simon Glass <sjg@chromium.org>
Tested-by: Kever Yang <kever.yang@rock-chips.com>
The imagetool framework checks whether function pointer for the verify,
print and extract actions are available and will will handle their
absence appropriately.
This change removes the unnecessary functions and uses the driver
structure to convey available functionality to imagetool. This is in
fact better than having verify just return 0 (which previously broke
dumpimage, as dumpimage assumed that we had handled the image and did
not continue to probe further).
Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
Acked-by: Simon Glass <sjg@chromium.org>
Dumpimage (it invoked with "-T rkspi" or "-T rksd") would not work due
to check_params failing. These changes ensure that we can both be called
with an empty imagename.
Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
Acked-by: Simon Glass <sjg@chromium.org>
This change set adds documentation to the header0 initialisation and
improves readability for the calculations of various offsets/lengths.
As the U-Boot SPL stage doesn't use any payload beyond what is covered
by init_size, we no longer add RK_MAX_BOOT_SIZE to init_boot_size.
Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
Acked-by: Simon Glass <sjg@chromium.org>
The calculation of the variable header size in rkcommon_vrec_header
had been update twice in the earlier series (introducing boot0-style
images to deal with the alignment of the first instruction in 64bit
binaries). Unfortunately, I didn't update the comment twice (so it
remained out-of-date).
This change brings the comment back in-sync with what the code is
doing.
Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
Acked-by: Simon Glass <sjg@chromium.org>
In (first) breaking and (then) fixing the rkspi tool, I realised that
the calculation of the required padding (for the header-size and the
2K-in-every-4K SPI layout) was not as self-explainatory as it could
have been. This change rewrites the code (using new, common functions
in rkcommon.c) and adds verbose in-line comments to ensure that we
won't fall into the same pit in the future...
Tested on the RK3399 (with has a boot0-style payload) with SD/MMC and SPI.
Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
Acked-by: Simon Glass <sjg@chromium.org>
Our earlier change broke the generation of SPI images, by excluding the
2K used for header0 from the size-calculation.
This commit makes sure that these are included before calculating the
required total size (including the padding from the 2K-from-every-4K
conversion).
Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
Acked-by: Simon Glass <sjg@chromium.org>
Add support for rk3328 package header in mkimage tool.
Signed-off-by: Kever Yang <kever.yang@rock-chips.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
The Kconfig description replaces the description in the README file so
as options are migrated they can be removed from the README.
Signed-off-by: Chris Packham <judge.packham@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
After moving to KConfig and removing from all headers options should be
removed from config_whitelist.txt so the build starts complaining if
someone adds them back.
Acked-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Chris Packham <judge.packham@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Avoid repetitive code dealing with asking the user for confirmation.
Signed-off-by: Chris Packham <judge.packham@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
The evaluation of option -c is incorrect:
According to the C99 standard endptr in the first strtol is always
set as &endptr is not NULL.
So the first part of the or condition is always true.
If all digits in optarg are valid endptr will point to the closing \0
and the second strtol will read beyond the end of the string optarg
points to.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Acked-by: Boris Brezillon <boris.brezillon@free-electrons.com>
An assignment (of a value to itself) was left over (after removing and
addition from the line) from moving the common padding code into
rkcommon_vrec_header.
This change removes this to avoid a spurious warning in static code
analysis (i.e. Coverity).
Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
Reported-by: Coverity (CID: 161418)
Reviewed-by: Tom Rini <trini@konsulko.com>
If realloc fails we should release the old buffer.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Many toolchains for ARM use the 'gnueabihf' suffix rather than just
'gnueabi', so allow these to be used, but with a lower priority than
'gnueabi' ones.
Cc: Simon Glass <sjg@chromium.org>
Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
When writing out some of our results we may now have UTF-8 characters
in there as well. Translate these to latin-1 and ignore any errors (as
this is for diagnostic and given the githash anything else can be
reconstructed by the user.
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Tom Rini <trini@konsulko.com>
One of these has crept in in this commit:
40a808f1 ARCv2: SLC: Make sure busy bit is set properly on SLC flushing
Adjust buildman to handle it.
Signed-off-by: Simon Glass <sjg@chromium.org>
Not force to use python from PATH. Issue was noted when building with
Yocto, because python from the distro is always taken instead of
python-native built during Yocto process.
Signed-off-by: Stefano Babic <sbabic@denx.de>
CC: Simon Glass <sjg@chromium.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
With skeleton.dtsi being dropped it is more likely that the /aliases node
will be last in the device tree. Update fdtgrep to handle this.
Signed-off-by: Simon Glass <sjg@chromium.org>
Tested-by: Masahiro Yamada <yamada.masahiro@socionext.com>
With Python 3.5.2 encode will throw an exception if val is a byte array.
Decode it to a string first. This assumes it's utf-8, if it's not valid
utf-8 it will throw an exception.
Signed-off-by: George McCollister <george.mccollister@gmail.com>
Acked-by: Simon Glass <sjg@chromium.org>
os.read() returns a byte array in Python 3.5.2 and needs to be converted
into a string. Check if the returned value is an instance of bytes and
if it is decode it as a utf-8 string. If it is not a utf-8 encoded string
the decoding may fail with an exception.
Prior to this fix the comparisions check data == "" would fail when data
was b'' and would cause an infinite memory leaking loop. joins would
also fail with an exception below but due to the infinite loop it never
made it that far.
Signed-off-by: George McCollister <george.mccollister@gmail.com>
Acked-by: Simon Glass <sjg@chromium.org>
fw_env_open allocates buffers to store the environment, but these
buffers are never freed. This becomes quite nasty using the fw_ tools as
library, because each access to the environment (even just reading a
variable) generates a memory leak equal to the size of the environment.
Fix this renaming fw_env_close() as fw_env_flush(), because the function
really flushes the environment from RAM to storage, and add a
fw_env_close function to free the allocated resources.
Signed-off-by: Stefano Babic <sbabic@denx.de>
Changes in the environment library are difficult to tracked by programs
using the library. Add simply an API version number that must be
increased each time when the API is changed.
This can be detected and a program can work with different versions of
the library.
Signed-off-by: Stefano Babic <sbabic@denx.de>
Move U-Boot private data into a separate file. This
lets export fw_env.h to be used by external programs
that want to change the environment using the library
built in tools/env.
Signed-off-by: Stefano Babic <sbabic@denx.de>
aes.h is a too generic name if this file can
be exported and used by a program.
Rename it to avoid any conflicts with
other files (for example, from openSSL).
Signed-off-by: Stefano Babic <sbabic@denx.de>
With recent changes, some x86-specific rom tests of binman fail to
run. Fix it by adding missing filenames in corresponding entries.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Now that we have added file names from Kconfig in x86 u-boot.dtsi,
update binman to avoid using hard-coded names.
Signed-off-by: Stefan Roese <sr@denx.de>
Cc: Bin Meng <bmeng.cn@gmail.com>
Cc: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
This program generates raw SPL images that can be flashed on the NAND with
the ECC and randomizer properly set up.
This has been copied (and tweaked to find the right headers) from the
sunxi-tools (https://github.com/linux-sunxi/sunxi-tools) upstream
repository, commit 1c3a6ca5.
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Acked-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Jagan Teki <jagan@openedev.com>
To simplify the creation of AArch64 SPL images for the RK3399, we
use the ENABLE_ARM_SOC_BOOT0_HOOK option and prepend 4 bytes of
padding at the start of the text section. This makes it easy for
mkimage to rewrite this word with the 'RK33' boot magic.
This change brings logic to calculate the header size and allocate
the header back in sync. For the RK3399 we now limit the header to
before the payload (i.e. the 'header0' and the padding up to the
actual image) and overwrite the first word (inserted by the
boot0-hook for this purpose) with the 'RK33' magic in-place.
X-AffectedPlatforms: RK3399-Q7
Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
Tested-by: Klaus Goger <klaus.goger@theobroma-systems.com>
The RK3399 boot code (running as AArch64) poses a bit of a challenge
for SPL image generation:
* The BootROM will start execution right after the 4-byte header (at
the odd instruction word loaded into SRAM at 0xff8c2004, with the
'RK33' boot magic residing at 0xff8c2000).
* The default padding (during ELF generation) for AArch64 is 0x0,
which is an illegal instruction and the .text section needs to be
naturally aligned (someone might locate a 64bit constant relative
to the section start and unaligned loads trigger a fault for all
privileged modes of an ARMv8)... so we can't simply define the
CONFIG_SPL_TEXT_BASE option to the odd address (0xff8c2004).
* Finally, we don't want to change the values used for padding of
the SPL .text section for all ARMv8 targets to the instruction
word encoding 'nop', as this would affect all padding in this
section and might hide errors that would otherwise quickly trigger
an illegal insn exception.
To deal with this situation, we modify the rkimage generation to
- understand the fact that the RK3399 needs to pad the header to an
8 byte boundary using an AArch64 'nop'
- the necessary logic to adjust the header_size (which controls the
location where the payload is copied into the image) and to insert
this padding (AArch64 insn words are always little-endian) into
the image following the 4-byte header magic.
X-AffectedPlatforms: RK3399-Q7
Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
Tested-by: Klaus Goger <klaus.goger@theobroma-systems.com>
The RC4 encoding works on full blocks, but the calculation of the
starting offset and size are needlessly complicated by using a
reference value known to be offset into a block by the size of the
header and then correcting for the (hard-coded) size of the header
(i.e. 4 bytes).
We change this over to use the RK_SPL_HDR_START directly (which is
known to be on a block boundary).
X-AffectedPlatforms: RK3399-Q7
Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
Tested-by: Klaus Goger <klaus.goger@theobroma-systems.com>
some system will not generate pbl format u-boot, but require rcw.
Signed-off-by: yuan linyu <Linyu.Yuan@alcatel-sbell.com.cn>
Reviewed-by: Alison Wang <alison.wang@nxp.com>
Reviewed-by: York Sun <york.sun@nxp.com>
Previously, dtoc could only process the top-level nodes which led to
device nodes in hierarchical trees to be ignored. E.g. the mmc0 node
in the following example would be ignored, as only the soc node was
processed:
/ {
soc {
mmc0 {
/* ... */
};
};
};
This introduces a recursive helper method ScanNode, which is used by
ScanTree to recursively parse the entire tree hierarchy.
Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
When building u-boot tools in cross-build environment CFLAGS environment
variable set up for target is taken into an account when building code
for host. Make it empty on invocation of python.
This fixes the following build errors when cross-compiling for xtensa:
cc1: error: unrecognized command line option "-mlongcalls"
cc1: error: unrecognized command line option "-mauto-litpools"
Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
