In SquashFS, the contents of a directory is stored by
squashfs_directory_entry structures which contain the file's name, inode
and position within the filesystem.
The inode number is not stored directly; instead each directory has one
or more headers which set a base inode number, and files store the
offset from that to the file's inode number.
In mksquashfs, each inode is allocated a number in the same order as
they are written to the directory table; thus the offset from the
header's base inode number to the file's inode number is usually
positive.
Hardlinks are simply stored with two directory entries referencing the
same file. This means the second entry will thus have an inode number
much lower than the surrounding files. Since the header's base inode
number comes from the first entry that uses the header, this delta will
usually be negative.
Previously, U-Boot's squashfs_directory_entry.inode_offset field was
declared as an unsigned value. Thus when a negative value was found, it
would either resolve to an invalid inode number or to that of an
unrelated file.
A squashfs image to test this can be created like so:
echo hi > sqfs_test_files/001-root-file
mkdir sqfs_test_files/002-subdir
touch sqfs_test_files/002-subdir/003-file
ln sqfs_test_files/{001-root-file,002-subdir/004-link}
mksquashfs sqfs_test_files/ test.sqfs -noappend
Note that squashfs sorts the files ASCIIbetacally, so we can use the
names to control the order they appear in. The ordering is important -
the first reference to the file must have a lower inode number than the
directory in which the second reference resides, and the second
reference cannot be the first file in the directory.
Listing this sample image in U-Boot results in:
=> sqfsls virtio 2 002-subdir
0 003-file
Inode not found.
0 004-link
Signed-off-by: Campbell Suter <campbell@snapit.group>
Reviewed-by: Miquel Raynal <miquel.raynal@bootlin.com>
The "-E" option to mkimage generates a FIT with external data using the
data-size and data-offset properties which must both be ignored when
verifying a signature.
Add "data-offset" to the list of excluded properties for signature
verification; since the line is now too long, re-format the list to
one-per-line and make it static since the data is constant.
Signed-off-by: John Keeping <john@metanate.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
The current stable release of LLVM is 12, update to that. While at it,
fix that we had not correctly upgraded to LLVM 11 previously.
Signed-off-by: Tom Rini <trini@konsulko.com>
The DT bindings of "jedec,spi-nor" [1] defines "m25p,fast-read" property
to indicate that "fast read" opcode can be used to read data from the
chip instead of the usual "read" opcode.
If this property is not present in DT, mask out fast read in
spi_nor_init_params(). This change mirrors the same logic in
spi_nor_info_init_params() in drivers/mtd/spi-nor/core.c in
the Linux kernel v5.14-rc3.
[1] Documentation/devicetree/bindings/mtd/jedec,spi-nor.yaml in the kernel tree
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Jagan Teki <jagan@amarulasolutions.com>
The smart spi_nor_adjust_hwcaps() does not respect the SPI flash's
hwcaps, and only looks to the controller on what can be supported.
The flash's hwcaps needs to be AND'ed before checking.
Fixes: 71025f013c ("mtd: spi-nor-core: Rework hwcaps selection")
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Pratyush Yadav <p.yadav@ti.com>
Reviewed-by: Jagan Teki <jagan@amarulasolutions.com>
When slave drivers don't set the max_read_size, the spi-mem should
directly use data.nbytes and not limit to any size. But current
logic will limit to the max_write_size.
This commit mirrors the same changes in the dm version done in
commit 535b1fdb8e ("spi: spi-mem: Fix read data size issue").
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Jagan Teki <jagan@amarulasolutions.com>
This chip has been (briefly) tested on the MediaTek MT7688 based GARDENA
smart gateway.
Datasheet: http://xmcwh.com/Uploads/2020-12-17/XM25QH64C_Ver1.1.pdf
Signed-off-by: Reto Schneider <reto.schneider@husqvarnagroup.com>
Reviewed-by: Stefan Roese <sr@denx.de>
Reviewed-by: Jagan Teki <jagan@amarulasolutions.com>
- Fixed broken ICH SPI driver in software sequencer mode
- Added "m25p,fast-read" to SPI flash node for x86 boards
- Drop ROM_NEEDS_BLOBS and BUILD_ROM for x86 ROM builds
- Define a default TSC timer frequency for all x86 boards
- x86 MTRR MSR programming codes bug fixes
- x86 "hob" command bug fixes
- Don't program MTRR for DRAM for FSP1
- Move INIT_PHASE_END_FIRMWARE to FSP2
- Use external graphics card by default on Intel Crown Bay
- tangier: Fix DMA controller IRQ polarity in CSRT
U-Boot mostly uses hex for value input, largely because addresses are much
easier to understand in hex.
But in some cases a decimal value is requested, such as where the value is
small or hex does not make sense in the context. In these cases it is
sometimes useful to be able to provide a hex value in any case, if only to
resolve any ambiguity.
Add this functionality, for increased flexibility.
Signed-off-by: Simon Glass <sjg@chromium.org>
The code to convert a character into a digit is repeated twice in this
file. Factor it out into a separate function. This also makes the code a
little easier to read.
Signed-off-by: Simon Glass <sjg@chromium.org>
Add some tests that check the behaviour of this function. These are the
same as for simple_strtoul() but with a few longer values.
Signed-off-by: Simon Glass <sjg@chromium.org>
If we see 0x then we can assume this is the start of a hex value. It
does not seem necessary to check for a hex digit after that since it will
happen when parsing the value anyway.
Drop this check to simplify the code and reduce size. Add a few more test
cases for when a 0x prefix is used.
Signed-off-by: Simon Glass <sjg@chromium.org>
This parameter is not documented properly since it does not cover the
meaning when the base is 0. Update this in both functions.
Signed-off-by: Simon Glass <sjg@chromium.org>
It is a pain to have to specify the value 10 in each call. Add a new
dectoul() function and update the code to use it.
Signed-off-by: Simon Glass <sjg@chromium.org>
It is a pain to have to specify the value 16 in each call. Add a new
hextoul() function and update the code to use it.
Add a proper comment to simple_strtoul() while we are here.
Signed-off-by: Simon Glass <sjg@chromium.org>
This function seems to assume that the chr[] variable contains zeros at
the start, which is not always true. Use strlcpy() to be safe.
Signed-off-by: Simon Glass <sjg@chromium.org>
The board routes the Integrated Graphics Device (IGD) to an LVDS
panel, which is less popular than a PCIe based graphics card.
Disable the IGD so that it does not show up in the PCI configuration
space as a VGA display controller, so we can use an external PCIe
graphics card with whatever cable we have.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Initialize 'igd' and 'sdvo' to NULL so that we just need to test
them against NULL later, to be compatible with that case that IGD
and SDVO devices were already in disabled state.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
For FSP1, there is no such INIT_PHASE_END_FIRMWARE.
Move board_final_cleanup() to fsp2 directory.
Fixes: 7c73cea442 ("x86: Notify the FSP of the 'end firmware' event")
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested on chromebook_coral, chromebook_samus, chromebook_link, minnowmax
Tested-by: Simon Glass <sjg@chromium.org>
There are several outstanding issues as to why this does not apply
to FSP1:
* For FSP1, the system memory and reserved memory used by FSP are
already programmed in the MTRR by FSP.
* The 'mtrr_top' mistakenly includes TSEG memory range that has the
same RES_MEM_RESERVED resource type. Its address is programmed
and reported by FSP to be near the top of 4 GiB space, which is
not what we want for SDRAM.
* The call to mtrr_add_request() is not guaranteed to have its size
to be exactly the power of 2. This causes reserved bits of the
IA32_MTRR_PHYSMASK register to be written which generates #GP.
For FSP2, it seems this is necessary as without this, U-Boot boot
process on Chromebook Coral goes very slowly.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested on chromebook_coral, chromebook_samus, chromebook_link, minnowmax
Tested-by: Simon Glass <sjg@chromium.org>
The resource type for system memory is currently displayed as
"unknown", which is wrong.
Fixes: 51af144eb7 ("x86: Allow showing details about a HOB entry")
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested on chromebook_coral, chromebook_samus, chromebook_link, minnowmax
Tested-by: Simon Glass <sjg@chromium.org>
At present the hob command usage and help messages are messed up
in a single line. They should be separated.
This was a regression introduced when [seq] and [-v] were added
to the command.
Fixes: d11544dfa9 ("x86: hob: Add way to show a single hob entry")
Fixes: 51af144eb7 ("x86: Allow showing details about a HOB entry")
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested on chromebook_coral, chromebook_samus, chromebook_link, minnowmax
Tested-by: Simon Glass <sjg@chromium.org>
The size parameter of mtrr_add_request() and mtrr_set_next_var()
shall be power of 2, otherwise the logic creates a mask that does
not meet the requirement of IA32_MTRR_PHYSMASK register.
Programming such a mask value to IA32_MTRR_PHYSMASK generates #GP.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested on chromebook_coral, chromebook_samus, chromebook_link, minnowmax
Tested-by: Simon Glass <sjg@chromium.org>
At present mtrr_commit() programs the MTRR MSRs starting from
index 0, which may overwrite MSRs that were already programmed
by previous boot stage or FSP.
Switch to call mtrr_set_next_var() instead.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested on chromebook_coral, chromebook_samus, chromebook_link, minnowmax
Tested-by: Simon Glass <sjg@chromium.org>
Current mtrr_commit() logic assumes that MTRR MSRs are programmed
consecutively from index 0 to its maximum number, and whenever it
detects an unused one, it clears all other MTRRs starting from that
one. However this may not always be the case.
In fact, the clear is not much helpful because these MTRRs come out
of reset as disabled already. Drop the clear codes.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested on chromebook_coral, chromebook_samus, chromebook_link, minnowmax
Tested-by: Simon Glass <sjg@chromium.org>
If for some reason, TSC timer frequency cannot be determined from
hardware, nor is it specified in the device tree, U-Boot will panic
resulting in endless reset during boot.
Let's define a default TSC timer frequency using the Kconfig value
CONFIG_X86_TSC_TIMER_FREQ (note: #include must be used instead of
/include/ otherwise the macro is not pre-processed).
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Currently there are two places to specify the x86 TSC timer frequency
with one in Kconfig used for early timer and the other one in device
tree used when the frequency cannot be determined from hardware.
This may potentially create an inconsistent config where the 2 values
do not match. Let's use the one specified in Kconfig in the device
tree as well.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
These 2 options are no longer needed as now binman is used to build
u-boot.rom.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
binman complains when binary blobs are present:
Node '/binman/rom/intel-vga': Offset 0xfff90000 (4294508544) overlaps
with previous entry '/binman/rom/u-boot-dtb-with-ucode' ending at
0xfff9204c (4294516812)
Adjust VGA rom address to 0xfffa0000 so that u-boot.rom image can be
successfully built again.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
IRQ polarity in CSRT has the same definition as by ACPI specification
chapter 19.6.64 "Interrupt (Interrupt Resource Descriptor Macro)", i.e.
ActiveHigh is 0, and ActiveLow is 1. On Intel Tangier the DMA controller
IRQ polarity is ActiveHigh.
Note, in DSDT (see southcluster.asl) it's described correctly.
Fixes: 5e99fde34a ("x86: tangier: Populate CSRT for shared DMA controller")
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Except ICH7 SPI, all SPI flashes connected to ICH9 / Fast SPI should
have "m25p,fast-read" property present in their DT nodes.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Since commit 71025f013c ("mtd: spi-nor-core: Rework hwcaps selection")
SPI flash on Intel Crown Bay board does not work anymore.
Disable CONFIG_SPI_FLASH_SMART_HWCAPS until a proper fix is made to
the spi-nor core.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Since commit 43c145b8b3 ("spi: ich: Correct max-size bug in ich_spi_adjust_size()")
(in v2020.04-rc1), SPI flash read no longer works with ICH SPI controller
in software sequencer mode.
ICH controller can only transfer a small number of bytes at once.
Before commit 43c145b8b3, the logic happens to make sure data.nbytes
is limited to slave->max_write_size but after commit 43c145b8b3
data.nbytes is no longer limited because slave->max_read_size is not
initialized with a valid number.
Fixes: 43c145b8b3 ("spi: ich: Correct max-size bug in ich_spi_adjust_size()")
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Parameter -W for sphinx-build turns build warnings into errors. This helps
us to avoid bad patches passing Gitlab CI.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
rST documentation and fixes for moveconfig
handle empty 'ranges' property in dtoc
patman warning for invalid tag
clean-ups to 'fdt add' command
-----BEGIN PGP SIGNATURE-----
iQFFBAABCgAvFiEEslwAIq+Gp8wWVbYnfxc6PpAIreYFAmEG4R4RHHNqZ0BjaHJv
bWl1bS5vcmcACgkQfxc6PpAIreapJwgAtKsKWy+TReCluKdG6Rdc3vtJwE9WP0/O
ms5JE/Rxk2wP7TMhuC6Sgl8WWhxuRpo623BfbtvbcBnxN/kugQRVNMYHiPTLzR78
SUq/DxLbWz46MbYTPwgJxhMquJKAzgSh8YgHwgvFLB31EozQzXB8LYHorRQdW0TG
42dKAOO3eDRMlT/DGkUcqm7dh9oG2T0rhGgJ1eQ/6vRksz8U0adunZeLA+sQQKRQ
uwPbNbCX3mx1nVqN37bitatHYVxvJg6yVq9awcaAhk1gtlUzBvJghNFkEmLTALBd
UFRMbWZXwf+7msffWJE5IcWrZxOAHixYgRMVv+iyFHEkyiSEKUAtZA==
=4cKs
-----END PGP SIGNATURE-----
Merge tag 'dm-pull-1aug21' of https://source.denx.de/u-boot/custodians/u-boot-dm
sandbox TPM-emulator improvements
rST documentation and fixes for moveconfig
handle empty 'ranges' property in dtoc
patman warning for invalid tag
clean-ups to 'fdt add' command
At present if we see 'ranges' property (with no value) we assume it is a
boolean, as per the devicetree spec.
But another node may define 'ranges' with a value, forcing us to widen it
to an int array. At present this is not supported and causes an error.
Fix this and add some test cases.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reported-by: Tom Rini <trini@konsulko.com>
An int array can hold a single int so we should not need to do anything
in the widening operation. However due to a quirk in the code, an int[3]
widened with an int produced an int[4]. Fix this and add a test.
Fix a comment typo while we are here.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reported-by: Tom Rini <trini@konsulko.com>
The current name is confusing because the logic is actually backwards from
what you might expect. Rename it to needs_widening() and update the
comments.
Signed-off-by: Simon Glass <sjg@chromium.org>
The autoboot tests are a recent addition to U-Boot, providing much-needed
coverage in this area.
A side effect of the keyed autoboot test is that this feature is enabled
in sandbox always. This changes the autoboot prompt and confuses the
pytests. Some tests become slower, for example the vboot tests take about
27s now instead of 3s.
We don't actually need this feature enabled to be able to run the tests.
Add a switch to allow sandbox to turn it on and off as needed. Use this
in the one test that needs it.
Add a command-line flag in case this is desired in normal use.
Signed-off-by: Simon Glass <sjg@chromium.org>
Fixes: 25c8b9f298 ("test: add first autoboot unit tests")
Reviewed-by: Steffen Jaeckel <jaeckel-floss@eyet-services.de>
