Rasmus Villemoes [Wed, 19 May 2021 16:08:11 +0000 (18:08 +0200)]
remove struct uclass_driver::ops
Each _device_ belonging to a given uclass of course has its own ->ops,
of a type determined by and known to the uclass.
However, no instance of a uclass_driver seems to populate ->ops, and
the only reference to it in code is this relocation.
Moreover, it's not really clear what could sensibly be assigned; it
would have to be some "struct uclass_ops *" providing a set of methods
for the core to call on that particular uclass, but should the need
for that ever arise, it would be better to have a member of that
particular type instead of void*.
Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk> Reviewed-by: Simon Glass <sjg@chromium.org>
GCC provides a symbol _init in crti.o on x86_64 and aarch64 but not on
RISC-V. The following lines leads to a build error for sandbox_defconfig on
RISC-V due to the missing symbol:
state_uninit() and dm_uninit() are mutually exclusive:
state_uninit() prints via drivers. So it cannot be executed after
dm_uninit().
dm_uninit() requires memory. So it cannot be executed after state_uninit()
which releases all memory.
Just skip dm_uninit() when resetting the sandbox. We will wake up in a new
process and allocate new memory. So this cleanup is not required. We don't
do it in sandbox_exit() either.
This avoids a segmentation error when efi_reset_system_boottime() is
invoked by a UEFI application.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
sandbox: ensure that state->ram_buf is in low memory
Addresses in state->ram_buf must be in the low 4 GiB of the address space.
Otherwise we cannot correctly fill SMBIOS tables. This shows up in warnings
like:
Simon Glass [Mon, 22 Mar 2021 05:21:01 +0000 (18:21 +1300)]
sandbox: Support signal handling only when requested
At present if sandbox crashes it prints a message and tries to exit. But
with the recently introduced signal handler, it often seems to get stuck
in a loop until the stack overflows:
Segmentation violation
Segmentation violation
Segmentation violation
Segmentation violation
Segmentation violation
Segmentation violation
Segmentation violation
...
The signal handler is only useful for a few tests, as I understand it.
Make it optional.
Tom Rini [Mon, 5 Jul 2021 19:29:44 +0000 (15:29 -0400)]
Merge branch '2021-07-01-update-CI-containers'
- General test.py improvements
- Rewrite the squashfs tests
- Update our CI container to Ubuntu 20.04 "focal" base.
- Make some changes to the Azure yaml so that we can have more tests run
there.
Tom Rini [Thu, 10 Jun 2021 14:57:36 +0000 (10:57 -0400)]
Docker/CI: Update to "focal" and latest build
Move us up to being based on Ubuntu 20.04 "focal" and the latest tag
from Ubuntu for this release. For this, we make sure that "python" is
now python3 but still include python2.7 for the rx51 qemu build as that
is very old and does not support python3.
Add more details to test cases by comparing each expected line with the
command's output. Add new test cases:
- sqfsls at an empty directory
- sqfsls at a sub-directory
Reviewed-by: Simon Glass <sjg@chromium.org> Tested-by: Simon Glass <sjg@chromium.org> [on sandbox] Signed-off-by: Joao Marcos Costa <jmcosta944@gmail.com>
The previous strategy to know if a file was correctly loaded was to
check for how many bytes were read and compare it against the file's
original size. Since this is not a good solution, replace it by
comparing the checksum of the loaded bytes against the original file's
checksum. Add more test cases: files at a sub-directory and non-existent
file.
Reviewed-by: Simon Glass <sjg@chromium.org> Tested-by: Simon Glass <sjg@chromium.org> [on sandbox] Signed-off-by: Joao Marcos Costa <jmcosta944@gmail.com>
Remove the previous OOP approach, which was confusing and incomplete.
Add more test cases by making SquashFS images with various options,
concerning file fragmentation and its compression. Add comments to
properly document the code.
Reviewed-by: Simon Glass <sjg@chromium.org> Tested-by: Simon Glass <sjg@chromium.org> [on sandbox] Signed-off-by: Joao Marcos Costa <jmcosta944@gmail.com>
Azure: Add loop devices and CAP_SYS_ADMIN for sandbox test.py tests
The filesystem test setup needs to prepare disk images for its tests,
with either guestmount or loop mounts. The former requires access to the
host fuse device (added in a previous patch), the latter requires access
to host loop devices. Both mounts also need additional privileges since
docker's default configuration prevents the containers from mounting
filesystems (for host security).
Add any available loop devices to the container and try to add as few
privileges as possible to run these tests, which narrow down to adding
SYS_ADMIN capability and disabling apparmor confinement. However, this
much still seems to be insecure enough to let malicious container
processes escape as root on the host system [1].
Since the mentioned tests are marked to run only on the sandbox board,
add these additional devices and privileges only when testing with that.
An alternative to using mounts is modifying the filesystem tests to use
virt-make-fs (like some EFI tests do), but it fails to generate a
partitionless FAT filesystem image on Debian systems. Other more
feasible alternatives are using guestfish or directly using libguestfs
Python bindings to create and populate the images, but switching the
test setups to these is nontrivial and is left as future work.
The EFI secure boot and capsule test setups need to prepare disk images
for their tests using virt-make-fs, which requires access to the host
fuse device. This is not exposed to the docker container by default and
has to be added explicitly. Add it.
tools: docker: Install a readable kernel for libguestfs-tools
The filesystem and EFI (capsule and secure boot) test setups try to use
guestmount and virt-make-fs respectively to prepare disk images to run
tests on. However, these libguestfs tools need a kernel image and fail
with the following message (revealed in debug/trace mode) if it can't
find one:
supermin: failed to find a suitable kernel (host_cpu=x86_64).
I looked for kernels in /boot and modules in /lib/modules.
If this is a Xen guest, and you only have Xen domU kernels
installed, try installing a fullvirt kernel (only for
supermin use, you shouldn't boot the Xen guest with it).
This failure then causes these tests to be skipped in CIs. Install a
kernel package in the Docker containers so the CIs can run these
tests with libguestfs tools again (assuming the container is run with
necessary host devices and privileges). As this kernel would be only
used for virtualization, we can use the kernel package specialized for
that. On Ubuntu systems kernel images are not readable by non-root
users, so explicitly add read permissions with chmod as well.
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com> Acked-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
test/py: Wait for guestmount worker to exit after running guestunmount
Some filesystem tests are failing when their image is prepared with
guestmount, but succeeding if loop mounts are used instead. The reason
seems to be a race condition the guestmount(1) manual page explains:
When guestunmount(1)/fusermount(1) exits, guestmount may still be
running and cleaning up the mountpoint. The disk image will not be
fully finalized.
This means that scripts like the following have a nasty race condition:
guestmount -a disk.img -i /mnt
# copy things into /mnt
guestunmount /mnt
# immediately try to use 'disk.img' ** UNSAFE **
The solution is to use the --pid-file option to write the guestmount
PID to a file, then after guestunmount spin waiting for this PID to
exit.
The Python standard library has an os.waitpid() function for waiting a
child to terminate, but it cannot wait on non-child processes. Implement
a utility function that can do this by polling the process repeatedly
for a given duration, optionally killing the process if it won't
terminate on its own. Apply the suggested solution with this utility
function, which makes the failing tests succeed again.
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
test/py: Use loop mounts if guestmount fails in filesystem tests
If guestmount isn't available on the system, filesystem test setup falls
back to using loop mounts to prepare its disk images. If guestmount is
available but fails to work, the tests are immediately skipped. Instead
of giving up on a guestmount failure, try using loop mounts as an
attempt to keep tests running.
Also stop checking if guestmount is in PATH, as trying to run a missing
guestmount can now follow the same failure codepath and fall back to
loop mounts anyway.
Da Xue [Fri, 2 Jul 2021 21:11:40 +0000 (17:11 -0400)]
configs: libretech: set SPI mode to 0
Kconfig defaults to mode 3 if CONFIG_SF_DEFAULT_MODE is not set.
It becomes an issue since meson_spifc does not support SPI_CPHA.
Needed after commit e2e95e5e25 ("spi: Update speed/mode on change").
Ilias Apalodimas [Tue, 29 Jun 2021 04:55:51 +0000 (07:55 +0300)]
efi_loader: Allow capsule update on-disk without checking OsIndications
Although U-Boot supports capsule update on-disk, it's lack of support for
SetVariable at runtime prevents applications like fwupd from using it.
In order to perform the capsule update on-disk the spec says that the OS
must copy the capsule to the \EFI\UpdateCapsule directory and set a bit in
the OsIndications variable. The firmware then checks for the
EFI_OS_INDICATIONS_FILE_CAPSULE_DELIVERY_SUPPORTED bit in OsIndications
variable, which is set by the submitter to trigger processing of the
capsule on the next reboot.
Let's add a config option which ignores the bit and just relies on the
capsule being present. Since U-Boot deletes the capsule while processing
it, we won't end up applying it multiple times.
Note that this is allowed for all capsules. In the future, once
authenticated capsules are fully supported, we can limit the functionality
to those only.
Signed-off-by: apalos <ilias.apalodimas@linaro.org>
Reword Kconfig description. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Masami Hiramatsu [Wed, 30 Jun 2021 15:49:48 +0000 (00:49 +0900)]
efi_loader: Improve the parameter check for QueryVariableInfo()
Improve efi_query_variable_info() to check the parameter settings and
return correct error code according to the UEFI Specification 2.9,
and the Self Certification Test (SCT) II Case Specification, June
2017, chapter 4.1.4 QueryVariableInfo().
Ilias Apalodimas [Tue, 22 Jun 2021 14:38:53 +0000 (17:38 +0300)]
efi_loader: Always install FMPs
We only install FMPs if a CapsuleUpdate is requested. Since we now have an
ESRT table which relies on FMPs to build the required information, it
makes more sense to unconditionally install them. This will allow userspace
applications (e.g fwupd) to make use of the ERST and provide us with files
we can use to run CapsuleUpdate on-disk
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Ilias Apalodimas [Tue, 22 Jun 2021 14:38:52 +0000 (17:38 +0300)]
efi_loader: Force a single FMP instance per hardware store
Chapter 23 of the EFI spec (rev 2.9) says:
"A specific updatable hardware firmware store must be represented by
exactly one FMP instance".
This is not the case for us, since both of our FMP protocols can be
installed at the same time because they are controlled by a single
'dfu_alt_info' env variable.
So make the config options depend on each other and allow the user to
install one of them at any given time. If we fix the meta-data provided
by the 'dfu_alt_info' in the future, to hint about the capsule type
(fit or raw) we can revise this and enable both FMPs to be installed, as
long as they target different firmware hardware stores
Note that we are not using a Kconfig 'choice' on purpose, since we
want to allow both of those to be installed and tested in sandbox
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Masami Hiramatsu [Tue, 22 Jun 2021 14:38:51 +0000 (17:38 +0300)]
efi: Fix to use null handle to create new handle for efi_fmp_raw
When running the efidebug capsule disk-update command, the efi_fmp_raw
protocol installation fails with 2 (EFI_INVALID_PARAMETER) as below.
This is because the code passes efi_root instead of the handle local var.
To fix this issue, pass the handle local var which is set NULL right
before installing efi_fmp_raw as same as the installing efi_fmp_fit.
(In both cases, the local reference to the handle will be just discarded)
Tom Rini [Thu, 1 Jul 2021 21:53:26 +0000 (17:53 -0400)]
Merge branch '2021-07-01-buildtime-gd-sanity-check' into next
- Merge build-time sanity checks to ensure the size of gd doesn't
change. This can happen during cleanups due to not all symbols being
implemented in Kconfig.
Rasmus Villemoes [Tue, 18 May 2021 09:19:47 +0000 (11:19 +0200)]
global-data.h: add build-time sanity check of sizeof(struct global_data)
The layout and contents of struct global_data depends on a lot of
CONFIG_* preprocessor macros, not all of which are entirely converted
to Kconfig - not to mention weird games played here and there. This
can result in one translation unit using one definition of struct
global_data while the actual layout is another.
That can be very hard to debug. But we already have a mechanism that
can help catch such bugs at build time, namely the asm-offsets
machinery which is necessary anyway to provide assembly code with the
necessary constants. So make sure that every C translation unit that
include global_data.h actually sees the same size of struct
global_data as that which was seen by the asm-offsets.c TU.
It is likely that this patch will break the build of some boards. For
example, without the patch from Matt Merhar
(https://lists.denx.de/pipermail/u-boot/2021-May/450135.html) or some
other fix, this breaks P2041RDB_defconfig:
CC arch/powerpc/lib/traps.o
AS arch/powerpc/cpu/mpc85xx/start.o
In file included from include/asm-generic/global_data.h:26,
from ./arch/powerpc/include/asm/global_data.h:109,
from include/init.h:21,
from arch/powerpc/lib/traps.c:7:
include/linux/build_bug.h:99:41: error: static assertion failed: "sizeof(struct global_data) == GD_SIZE"
99 | #define __static_assert(expr, msg, ...) _Static_assert(expr, msg)
| ^~~~~~~~~~~~~~
include/linux/build_bug.h:98:34: note: in expansion of macro ‘__static_assert’
98 | #define static_assert(expr, ...) __static_assert(expr, ##__VA_ARGS__, #expr)
| ^~~~~~~~~~~~~~~
include/asm-generic/global_data.h:470:1: note: in expansion of macro ‘static_assert’
470 | static_assert(sizeof(struct global_data) == GD_SIZE);
| ^~~~~~~~~~~~~
make[1]: *** [scripts/Makefile.build:266: arch/powerpc/lib/traps.o] Error 1
make: *** [Makefile:1753: arch/powerpc/lib] Error 2
make: *** Waiting for unfinished jobs....
Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk> Reviewed-by: Simon Glass <sjg@chromium.org>
BUILD_BUG_ON() is a little annoying, since it cannot be used outside
function scope. So one cannot put assertions about the sizeof() a
struct next to the struct definition, but has to hide that in some more
or less arbitrary function.
Since gcc 4.6 (which is now also the required minimum), there is support
for the C11 _Static_assert in all C modes, including gnu89. So add a
simple wrapper for that.
_Static_assert() requires a message argument, which is usually quite
redundant (and I believe that bug got fixed at least in newer C++
standards), but we can easily work around that with a little macro
magic, making it optional.
For example, adding
static_assert(sizeof(struct printf_spec) == 8);
in vsprintf.c and modifying that struct to violate it, one gets
Tom Rini [Thu, 1 Jul 2021 12:57:23 +0000 (08:57 -0400)]
Merge tag 'xilinx-for-v2021.10' of https://source.denx.de/u-boot/custodians/u-boot-microblaze into next
Xilinx changes for v2021.10
clk:
- Add driver for Xilinx Clocking Wizard IP
fdt:
- Also record architecture in /fit-images
net:
- Fix plat/priv data handling in axi emac
- Add support for 10G/25G speeds
pca953x:
- Add missing dependency on i2c
serial:
- Fix dependencies for DEBUG uart for pl010/pl011
- Add setconfig option for cadence serial driver
watchdog:
- Add cadence wdt expire now function
zynq:
- Update DT bindings to reflect the latest state and descriptions
zynqmp:
- Update DT bindings to reflect the latest state and descriptions
- SPL: Add support for ECC DRAM initialization
- Fix R5 core 1 handling logic
- Enable firmware driver for mini configurations
- Enable secure boot, regulators, wdt
- Add support xck devices and 67dr
- Add psu init for sm/smk-k26 SOMs
- Add handling for MMC seq number via mmc_get_env_dev()
- Handle reserved memory locations
- Add support for u-boot.itb generation for secure OS
- Handle BL32 handoffs for secure OS
- Add support for 64bit addresses for u-boot.its generation
- Change eeprom handling via nvmem aliases
Michal Simek [Mon, 28 Jun 2021 11:44:16 +0000 (13:44 +0200)]
watchdog: cadence: Add expire_now method
It is working in a way that only minimal timeout is setup to reach
expiration just right after it is setup.
Please make sure that PMUFW is compiled with ENABLE_EM flag.
On U-Boot prompt you can test it like:
ZynqMP> wdt dev watchdog@fd4d0000
ZynqMP> wdt list
watchdog@fd4d0000 (cdns_wdt)
ZynqMP> wdt dev
dev: watchdog@fd4d0000
ZynqMP> wdt expire
(And reset should happen here)
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Marek Vasut [Thu, 10 Jun 2021 12:00:00 +0000 (14:00 +0200)]
spi: Update speed/mode on change
The spi_get_bus_and_cs() may be called on the same bus and chipselect
with different frequency or mode. This is valid usecase, but the code
fails to notify the controller of such a configuration change. Call
spi_set_speed_mode() in case bus frequency or bus mode changed to let
the controller update the configuration.
The problem can easily be triggered using the sspi command:
=> sspi 0:0@1000
=> sspi 0:0@2000
Without this patch, both transfers happen at 1000 Hz. With this patch,
the later transfer happens correctly at 2000 Hz.
Signed-off-by: Marek Vasut <marex@denx.de> Cc: Jagan Teki <jagan@amarulasolutions.com> Cc: Patrick Delaunay <patrick.delaunay@foss.st.com>
Tom Rini [Tue, 29 Jun 2021 15:25:39 +0000 (11:25 -0400)]
Merge tag 'efi-2021-07-rc5-2' of https://source.denx.de/u-boot/custodians/u-boot-efi
Pull request for efi-2021-07-rc5-2
Documentation:
* man-page for askenv
bug fixes
* correct display of BootOrder in efidebug command
* do not allow TPL_HIGH_LEVEL for CreateEvent(Ex)
* correct handling of unknown properties in SMBIOS tables
Takahiro Kuwano [Tue, 29 Jun 2021 06:01:03 +0000 (15:01 +0900)]
mtd: spi-nor-core: Add fixups for Cypress s25hl-t/s25hs-t
The nor->ready() and spansion_sr_ready() introduced earlier in this
series are used for multi-die package parts.
The nor->quad_enable() sets the volatile QE bit on each die.
The nor->erase() is hooked if the device is not configured to uniform
sectors, assuming it has 32 x 4KB sectors overlaid on bottom address.
Other configurations, top and split, are not supported at this point.
Will submit additional patches to support it as needed.
The post_bfpt/sfdp() fixes the params wrongly advertised in SFDP.
Signed-off-by: Takahiro Kuwano <Takahiro.Kuwano@infineon.com> Reviewed-by: Jagan Teki <jagan@amarulasolutions.com>
Takahiro Kuwano [Tue, 29 Jun 2021 06:01:01 +0000 (15:01 +0900)]
mtd: spi-nor-core: Read status by Read Any Register
The spansion_sr_ready() reads status register 1 by Read Any Register
commnad. This function is called from Flash specific hook with die address
and dummy cycles to support multi-die package parts from Spansion/Cypress.
Takahiro Kuwano [Tue, 29 Jun 2021 06:01:00 +0000 (15:01 +0900)]
mtd: spi-nor-core: Add the ->ready() hook
For dual/quad die package devices from Spansion/Cypress, the device's
status needs to be checked by reading status registers in all dies, by
using Read Any Register command. To support this, a Flash specific hook
that can overwrite the legacy status check is needed.
Takahiro Kuwano [Tue, 29 Jun 2021 06:00:59 +0000 (15:00 +0900)]
mtd: spi-nor-core: Add support for volatile QE bit
Some of Spansion/Cypress chips support volatile version of configuration
registers and it is recommended to update volatile registers in the field
application due to a risk of the non-volatile registers corruption by
power interrupt. This patch adds a function to set Quad Enable bit in CFR1
volatile.
Signed-off-by: Takahiro Kuwano <Takahiro.Kuwano@infineon.com> Reviewed-by: Jagan Teki <jagan@amarulasolutions.com>
Takahiro Kuwano [Tue, 29 Jun 2021 06:00:58 +0000 (15:00 +0900)]
mtd: spi-nor-core: Add support for Read/Write Any Register
Some of Spansion/Cypress chips support Read/Write Any Register commands.
These commands are mainly used to write volatile registers and access to
the registers in second and subsequent die for multi-die package parts.
The Read Any Register instruction (65h) is followed by register address
and dummy cycles, then the selected register byte is returned.
The Write Any Register instruction (71h) is followed by register address
and register byte to write.
Takahiro Kuwano [Tue, 29 Jun 2021 06:00:57 +0000 (15:00 +0900)]
mtd: spi-nor-ids: Add Cypress s25hl-t/s25hs-t
The S25HL-T/S25HS-T family is the Cypress Semper Flash with Quad SPI.
https://www.cypress.com/file/424146/download (256Mb/512Mb/1Gb, single die)
https://www.cypress.com/file/499246/download (2Gb/4Gb, dual/quad die)
The full version can be found in the following links (registration
required).
https://community.cypress.com/t5/Semper-Flash-Access-Program/Datasheet-Semper-Flash-with-Quad-SPI/ta-p/260789?attachment-id=19522
https://community.cypress.com/t5/Semper-Flash-Access-Program/Datasheet-2Gb-MCP-Semper-Flash-with-Quad-SPI/ta-p/260823?attachment-id=29503
S25HL/HS-T (Semper Flash with Quad SPI) Family has user-configurable
sector architecture. By default, the 512Mb and 1Gb, single-die package
parts are configured to non-uniform that 4KB sectors overlaid on bottom
address. To support this, an erase hook makes overlaid sectors appear as
uniform sectors. The 2Gb, dual-die package parts are configured to uniform
by default.
Kunihiko Hayashi [Tue, 15 Jun 2021 06:33:02 +0000 (15:33 +0900)]
arm64: Fix relocation of env_addr if POSITION_INDEPENDENT=y
If both POSITION_INDEPENDENT and SYS_RELOC_GD_ENV_ADDR are enabled,
wherever original env is placed anywhere, it should be relocated to
the right address.
Relocation offset gd->reloc_off is calculated with SYS_TEXT_BASE in
setup_reloc() and env address gd->env_addr is relocated by the offset in
initr_reloc_global_data().
However, SYS_TEXT_BASE isn't always runtime base address when
POSITION_INDEPENDENT is enabled. So the relocated env_addr might point to
wrong address. For example, if SYS_TEXT_BASE is zero, gd->env_addr is
out of memory location and memory exception will occur.
There is a difference between linked address such as SYS_TEXT_BASE and
runtime base address. In _main, the difference is calculated as
"run-vs-link" offset. The env_addr should also be added to the offset
to fix the address.
Ilias Apalodimas [Thu, 10 Jun 2021 09:33:15 +0000 (12:33 +0300)]
smbios: Fix SMBIOS tables
Commit e4f8e543f1a9("smbios: Drop the unused Kconfig options")
break SMBIOS tables. The reason is that the patch drops the Kconfig
options *after* removing the code using them, but that changes the semantics
of the code completely. Prior to the change a non NULL value was used in
the 'product' and 'manufacturer ' fields.
Chapter 6.2 of the DMTF spec requires Manufacturer and Product Name to be
non-null on some of the tables. So let's add sane defaults for Type1/2/3.
* Before the patchset:
<snip>
Handle 0x0002, DMI type 2, 14 bytes
Base Board Information
Manufacturer: Not Specified
Product Name: Not Specified
Version: Not Specified
Serial Number: Not Specified
Asset Tag: Not Specified
Features:
Board is a hosting board
Location In Chassis: Not Specified
Chassis Handle: 0x0000
Type: Motherboard
Invalid entry length (0). DMI table is broken! Stop.
* After the patchset:
<snip>
Handle 0x0005, DMI type 32, 11 bytes
System Boot Information
Status: No errors detected
Handle 0x0006, DMI type 127, 4 bytes
End Of Table
Fixes: e4f8e543f1a9 ("smbios: Drop the unused Kconfig options") Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
We currently define the EFI support of an SMBIOS table as the third bit of
"BIOS Characteristics Extension Byte 1". The latest DMTF spec defines it
on "BIOS Characteristics Extension Byte 2".
help file for using askenv cmd is created.
It provides description on the command purpose,
description of arguments,
couple of examples (illustrating command usage),
configuration parameter and
possible return values.
Signed-off-by: Adarsh Babu Kalepalli <opensource.kab@gmail.com>
Add missing entry in doc/usage/index.rst. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
There are lot of accesses to priv data in of_to_plat(), which is incorrect.
Create a platform data structure and use it in of_to_plat(), then copy all
platform data to priv data in probe.
Signed-off-by: Ashok Reddy Soma <ashok.reddy.soma@xilinx.com> Reviewed-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Kunihiko Hayashi [Fri, 25 Jun 2021 11:19:11 +0000 (20:19 +0900)]
serial: zynq: Add support for serial parameters
This adds serial parameters that include stop bit mode, parity mode,
and character length. Mark parity and space parity modes are not
supported.
At the moment, the only path to call setconfig directly is DM testing,
however, this affects the size of SPL for DM testing, so it doesn't
apply to SPL.
Signed-off-by: Kunihiko Hayashi <hayashi.kunihiko@socionext.com> Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Michal Simek [Thu, 24 Jun 2021 11:36:23 +0000 (13:36 +0200)]
serial: Add additional depencies for PL010 and PL011 drivers
Both of these drivers are implemented with and without DM that's why more
symbols should be handled.
The most problematic one is enabling DEBUG_UART_PL011 based on
PL01X_SERIAL(DM based) because debug console has type selection based on
it.
enum pl01x_type type = CONFIG_IS_ENABLED(DEBUG_UART_PL011) ?
TYPE_PL011 : TYPE_PL010;
Without it pl01x_generic_setbrg() is configuring different registers.
Fixes: 4cc24aeaf420 ("serial: Add missing Kconfig dependencies for debug consoles") Signed-off-by: Michal Simek <michal.simek@xilinx.com> Reviewed-by: Simon Glass <sjg@chromium.org>
Pratyush Yadav [Fri, 25 Jun 2021 19:17:29 +0000 (00:47 +0530)]
mtd: spi-nor-core: Allow using Micron mt35xu512aba in Octal DTR mode
Since this flash doesn't have a Profile 1.0 table, the Octal DTR
capabilities are enabled in the post SFDP fixup, along with the 8D-8D-8D
fast read settings.
Enable Octal DTR mode with 20 dummy cycles to allow running at the
maximum supported frequency of 200Mhz.
Signed-off-by: Pratyush Yadav <p.yadav@ti.com> Reviewed-by: Jagan Teki <jagan@amarulasolutions.com>
Takahiro Kuwano [Fri, 25 Jun 2021 19:17:27 +0000 (00:47 +0530)]
mtd: spi-nor-core: Add non-uniform erase for Spansion/Cypress
Some of Spansion/Cypress chips have overlaid 4KB sectors at top and/or
bottom, depending on the device configuration, while U-Boot supports
uniform sector layout only.
The spansion_erase_non_uniform() erases overlaid 4KB sectors,
non-overlaid portion of normal sector, and remaining normal sectors, by
selecting correct erase command and size based on the address to erase
and size of overlaid portion in parameters. Since different Spansion
flashes can use different opcode for erasing the 4K sectors, the opcode
must be passed in as a parameter based on the flash being used.
Signed-off-by: Takahiro Kuwano <Takahiro.Kuwano@infineon.com> Signed-off-by: Pratyush Yadav <p.yadav@ti.com>
[p.yadav@ti.com: Refactor the function to be compatible with nor->erase,
make 4K opcode customizable, call spi_nor_setup_op() before executing
the op.] Acked-by: Jagan Teki <jagan@amarulasolutions.com>
Pratyush Yadav [Fri, 25 Jun 2021 19:17:26 +0000 (00:47 +0530)]
mtd: spi-nor-core: allow truncated erases
On devices with non-uniform sector sizes like Spansion S25 or S28 family
of flashes the sector under erase does not necessarily have to be
mtd->erasesize bytes long. For example, on S28 flashes the first 128 KiB
region is composed of 32 4 KiB sectors, then a 128 KiB sector, and then
256 KiB sectors till the end.
Let the flash-specific erase functions erase less than the requested
length in case of the 4 or 128 KiB sectors and report the number of
bytes erased back to the calling function.
Signed-off-by: Pratyush Yadav <p.yadav@ti.com> Reviewed-by: Jagan Teki <jagan@amarulasolutions.com>
Pratyush Yadav [Fri, 25 Jun 2021 19:17:25 +0000 (00:47 +0530)]
mtd: spi-nor-core: Perform a Soft Reset on boot
When the flash is handed to us in a stateful mode like 8D-8D-8D, it is
difficult to detect the mode the flash is in. One option is to read SFDP
in all modes and see which one gives the correct "SFDP" signature, but
not all flashes support SFDP in 8D-8D-8D mode.
Further, even if you detect the mode of the flash via SFDP, you still
have the problem of actually reading the ID. The Read ID command is not
standardized across flash vendors. Flashes can have different dummy
cycles needed for reading the ID. Some flashes even expect a 4-byte
dummy address with the Read ID command. All this information cannot be
obtained from the SFDP table.
So, perform a Software Reset sequence before reading the ID and
initializing the flash. A Soft Reset will bring back the flash in its
default protocol mode assuming no non-volatile configuration was set.
This will let us detect the flash even if ROM hands it to us in Octal
DTR mode.
To accommodate cases where there is more than one flash on a board, and
only one of them needs a soft reset, failure to reset is not made fatal,
and we still try to read ID if possible.
Signed-off-by: Pratyush Yadav <p.yadav@ti.com> Reviewed-by: Jagan Teki <jagan@amarulasolutions.com>
Pratyush Yadav [Fri, 25 Jun 2021 19:17:24 +0000 (00:47 +0530)]
mtd: spi-nor-core: Perform a Soft Reset on shutdown
On probe, the SPI NOR core will put a flash in 8D-8D-8D mode if it
supports it. But Linux as of now expects to get the flash in 1S-1S-1S
mode. Handing the flash to Linux in Octal DTR mode means the kernel will
fail to detect the flash.
So, we need to reset to Power-on-Reset (POR) state before handing off
the flash. A Software Reset command can be used to do this.
One limitation of the soft reset is that it will restore state from
non-volatile registers in some flashes. This means that if the flash was
set to 8D mode in a non-volatile configuration, a soft reset won't help.
This commit assumes that we don't set any non-volatile bits anywhere,
and the flash doesn't have any non-volatile Octal DTR mode
configuration.
Since spi-nor-tiny doesn't (and likely shouldn't) have
spi_nor_soft_reset(), add a dummy spi_nor_remove() for it that does
nothing.
Signed-off-by: Pratyush Yadav <p.yadav@ti.com> Reviewed-by: Jagan Teki <jagan@amarulasolutions.com>
Pratyush Yadav [Fri, 25 Jun 2021 19:17:23 +0000 (00:47 +0530)]
mtd: spi-nor-core: Detect Soft Reset sequence support from BFPT
A Soft Reset sequence will return the flash to Power-on-Reset (POR)
state. It consists of two commands: Soft Reset Enable and Soft Reset.
Find out if the sequence is supported from BFPT DWORD 16.
Signed-off-by: Pratyush Yadav <p.yadav@ti.com> Reviewed-by: Jagan Teki <jagan@amarulasolutions.com>
Pratyush Yadav [Fri, 25 Jun 2021 19:17:22 +0000 (00:47 +0530)]
mtd: spi-nor-core: Do not make invalid quad enable fatal
The Micron MT35XU512ABA flash does not support the quad enable bit. But
instead of programming the Quad Enable Require field to 000b ("Device
does not have a QE bit"), it is programmed to 111b ("Reserved").
While this is technically incorrect, it is not reason enough to abort
BFPT parsing. Instead, continue BFPT parsing assuming there is no quad
enable bit present.
Signed-off-by: Pratyush Yadav <p.yadav@ti.com> Reviewed-by: Jagan Teki <jagan@amarulasolutions.com>
Pratyush Yadav [Fri, 25 Jun 2021 19:17:20 +0000 (00:47 +0530)]
mtd: spi-nor-core: Prepare Read SR and FSR for Octal DTR mode
The xSPI Profile 1.0 table specifies how many dummy cycles and address
bytes are needed for the Read Status Register command in Octal DTR mode.
Use that information to send the correct Read SR command.
Some controllers might have trouble reading just 1 byte in DTR mode. So,
when we are in DTR mode read 2 bytes and discard the second. This shows
no side effects with the two flashes I tested: Micron mt35xu512aba and
Cypress s28hs512t.
Update Read FSR to mimic Read SR because they share the same
characteristics.
Signed-off-by: Pratyush Yadav <p.yadav@ti.com> Reviewed-by: Jagan Teki <jagan@amarulasolutions.com>
Pratyush Yadav [Fri, 25 Jun 2021 19:17:19 +0000 (00:47 +0530)]
mtd: spi-nor-core: Parse xSPI Profile 1.0 table
This table is indication that the flash is xSPI compliant and hence
supports octal DTR mode. Extract information like the fast read opcode,
the number of dummy cycles needed for a Read Status Register command,
and the number of address bytes needed for a Read Status Register
command.
The default dummy cycles for a fast octal DTR read are set to 20. Since
there is no simple way of determining the dummy cycles needed for the
fast read command, flashes that use a different value should update it
in their flash-specific hooks.
Signed-off-by: Pratyush Yadav <p.yadav@ti.com> Acked-by: Jagan Teki <jagan@amarulasolutions.com>
Pratyush Yadav [Fri, 25 Jun 2021 19:17:18 +0000 (00:47 +0530)]
mtd: spi-nor-core: Get command opcode extension type from BFPT
Some devices in DTR mode expect an extra command byte called the
extension. The extension can either be same as the opcode, bitwise
inverse of the opcode, or another additional byte forming a 16-byte
opcode. Get the extension type from the BFPT. For now, only flashes with
"repeat" and "inverse" extensions are supported.
Signed-off-by: Pratyush Yadav <p.yadav@ti.com> Reviewed-by: Jagan Teki <jagan@amarulasolutions.com>
Pratyush Yadav [Fri, 25 Jun 2021 19:17:17 +0000 (00:47 +0530)]
mtd: spi-nor-core: prepare BFPT parsing for JESD216 rev D
JESD216 rev D makes BFPT 20 DWORDs. Update the BFPT size define to
reflect that.
The check for rev A or later compared the BFPT header length with the
maximum BFPT length, BFPT_DWORD_MAX. Since BFPT_DWORD_MAX was 16, and so
was the BFPT length for both rev A and B, this check worked fine. But
now, since BFPT_DWORD_MAX is 20, it means this check will also stop BFPT
parsing for rev A or B, since their length is 16.
So, instead check for BFPT_DWORD_MAX_JESD216 to stop BFPT parsing for
the first JESD216 version, and check for BFPT_DWORD_MAX_JESD216B for the
next two versions.
Signed-off-by: Pratyush Yadav <p.yadav@ti.com> Reviewed-by: Jagan Teki <jagan@amarulasolutions.com>
Pratyush Yadav [Fri, 25 Jun 2021 19:17:16 +0000 (00:47 +0530)]
mtd: spi-nor-core: Add support for DTR protocol
Double Transfer Rate (DTR) is SPI protocol in which data is transferred
on each clock edge as opposed to on each clock cycle. Make
framework-level changes to allow supporting flashes in DTR mode.
Right now, mixed DTR modes are not supported. So, for example a mode
like 4S-4D-4D will not work. All phases need to be either DTR or STR.
Signed-off-by: Pratyush Yadav <p.yadav@ti.com> Reviewed-by: Jagan Teki <jagan@amarulasolutions.com>
Pratyush Yadav [Fri, 25 Jun 2021 19:17:15 +0000 (00:47 +0530)]
mtd: spi-nor-core: Do not set data direction when there is no data
Even when spi_nor_write_reg() has no data to write, like when executing
a write enable operation, it sets the data direction to
SPI_MEM_DATA_OUT. This trips up spi_mem_check_buswidth() because it
expects a data phase when there is none. Make sure the data direction is
set to SPI_MEM_NO_DATA when there is no data to write.
Signed-off-by: Pratyush Yadav <p.yadav@ti.com> Reviewed-by: Jagan Teki <jagan@amarulasolutions.com>
Pratyush Yadav [Fri, 25 Jun 2021 19:17:14 +0000 (00:47 +0530)]
mtd: spi-nor-core: Rework hwcaps selection
The spi-mem layer provides a spi_mem_supports_op() function to check
whether a specific operation is supported by the controller or not.
This is much more accurate than the hwcaps selection logic based on
SPI_{RX,TX}_ flags.
Rework the hwcaps selection logic to use spi_mem_supports_op().
To make sure the build doesn't break for boards not using CONFIG_DM_SPI,
add a simple SPI_{RX,TX}_ based hwcaps selection logic in spi-mem-nodm
similar to spi_mem_default_supports_op(). This change is only
compile-tested.
To avoid SPL size problems on the x530 board, the old hwcaps selection
is still kept around. Leaving the code in-place was getting difficult to
read and understand, so the code is restructured to have it all in one
isolated function. As a result of this, the parameter hwcaps to
spi_nor_setup() is no longer needed. Remove it.
Based on the Linux commit c76f5089796a (mtd: spi-nor: Rework hwcaps
selection for the spi-mem case, 2019-08-06)
Signed-off-by: Pratyush Yadav <p.yadav@ti.com> Reviewed-by: Jagan Teki <jagan@amarulasolutions.com>
Sometimes the information in a flash's SFDP tables is wrong. Sometimes
some information just can't be expressed in the SFDP table. So,
introduce the fixup hooks to allow tailoring settings for a specific
flash.
Three hooks are added: default_init, post_sfdp, and post_bfpt. These
allow tweaking the flash settings at different point in the probe
sequence. Since the hooks reside in nor->info, set that value just
before the call to spi_nor_init_params().
The hooks and at what points they are executed mimics Linux's spi-nor
framework. One major difference is that Linux puts the struct
spi_nor_fixups in nor->info. This is not possible in U-Boot because the
spi-nor-ids list is shared between spi-nor-core.c and spi-nor-tiny.c.
Since spi-nor-tiny shouldn't have those fixup hooks populated, add a
separate function that lets flashes populate their fixup hooks.
Signed-off-by: Pratyush Yadav <p.yadav@ti.com> Reviewed-by: Jagan Teki <jagan@amarulasolutions.com>
Pratyush Yadav [Fri, 25 Jun 2021 19:17:12 +0000 (00:47 +0530)]
mtd: spi-nor-core: Move SFDP related declarations to top
These structures will be used in a later commit inside another structure
definition. Also take the declarations out of the ifdef since they won't
affect the final binary anyway and will be used in a later commit.
Signed-off-by: Pratyush Yadav <p.yadav@ti.com> Reviewed-by: Jagan Teki <jagan@amarulasolutions.com>
Pratyush Yadav [Fri, 25 Jun 2021 19:17:11 +0000 (00:47 +0530)]
mtd: spi-nor-core: Add a ->setup() hook
nor->setup() can be used by flashes to configure settings in case they
have any peculiarities that can't be easily expressed by the generic
spi-nor framework. This includes things like different opcodes, dummy
cycles, page size, uniform/non-uniform sector sizes, etc.
Move related declarations to avoid forward declarations.
Inspired by the Linux kernel's setup() hook.
Signed-off-by: Pratyush Yadav <p.yadav@ti.com> Acked-by: Jagan Teki <jagan@amarulasolutions.com>
Pratyush Yadav [Fri, 25 Jun 2021 19:17:09 +0000 (00:47 +0530)]
spi: cadence-qspi: Add support for octal DTR flashes
Set up opcode extension and enable/disable DTR mode based on whether the
command is DTR or not.
xSPI flashes can have a 4-byte dummy address associated with some
commands like the Read Status Register command in octal DTR mode. Since
the flash does not support sending the dummy address, we can not use
automatic write completion polling in DTR mode. Further, no write
completion polling makes it impossible to use DAC mode for DTR writes.
In that mode, the controller does not know beforehand how long a write
will be and so it can de-assert Chip Select (CS#) at any time. Once CS#
is de-assert, the flash will go into burning phase. But since the
controller does not do write completion polling, it does not know when
the flash is busy and might send in writes while the flash is not ready.
So, disable write completion polling and make writes go through indirect
mode for DTR writes and let spi-mem take care of polling the SR.
Signed-off-by: Pratyush Yadav <p.yadav@ti.com> Acked-by: Jagan Teki <jagan@amarulasolutions.com>
Pratyush Yadav [Fri, 25 Jun 2021 19:17:08 +0000 (00:47 +0530)]
spi: cadence-qspi: Add a small delay before indirect writes
Once the start bit is toggled it takes a small amount of time before it
is internally synchronized. This means we can't start writing during
that part. So add a small delay to allow the bit to be synchronized.
Signed-off-by: Pratyush Yadav <p.yadav@ti.com> Acked-by: Jagan Teki <jagan@amarulasolutions.com>
Pratyush Yadav [Fri, 25 Jun 2021 19:17:07 +0000 (00:47 +0530)]
spi: cadence-qspi: Do not calibrate when device tree sets read delay
If the device tree provides a read delay value, use that directly and do
not perform the calibration procedure.
This allows the device tree to over-ride the read delay value in cases
where the read delay value obtained via calibration is incorrect. One
such example is the Cypress Semper flash. It needs a read delay of 4 in
octal DTR mode. But since the calibration procedure is run before the
flash is switched in octal DTR mode, it yields a read delay of 2. A
value of 4 works for both octal DTR and legacy modes.
Signed-off-by: Pratyush Yadav <p.yadav@ti.com> Reviewed-by: Jagan Teki <jagan@amarulasolutions.com>
Pratyush Yadav [Fri, 25 Jun 2021 19:17:06 +0000 (00:47 +0530)]
spi: spi-mem: add spi_mem_dtr_supports_op()
spi_mem_default_supports_op() rejects DTR ops by default to ensure that
the controller drivers that haven't been updated with DTR support
continue to reject them. It also makes sure that controllers that don't
support DTR mode at all (which is most of them at the moment) also
reject them.
This means that controller drivers that want to support DTR mode can't
use spi_mem_default_supports_op(). Driver authors have to roll their own
supports_op() function and mimic the buswidth checks. Or even worse,
driver authors might skip it completely or get it wrong.
Add spi_mem_dtr_supports_op(). It provides a basic sanity check for DTR
ops and performs the buswidth requirement check. Move the logic for
checking buswidth in spi_mem_default_supports_op() to a separate
function so the logic is not repeated twice.
Signed-off-by: Pratyush Yadav <p.yadav@ti.com> Acked-by: Jagan Teki <jagan@amarulasolutions.com>
Pratyush Yadav [Fri, 25 Jun 2021 19:17:04 +0000 (00:47 +0530)]
spi: spi-mem: allow specifying a command's extension
In xSPI mode, flashes expect 2-byte opcodes. The second byte is called
the "command extension". There can be 3 types of extensions in xSPI:
repeat, invert, and hex. When the extension type is "repeat", the same
opcode is sent twice. When it is "invert", the second byte is the
inverse of the opcode. When it is "hex" an additional opcode byte based
is sent with the command whose value can be anything.
So, make opcode a 16-bit value and add a 'nbytes', similar to how
multiple address widths are handled.
All usages of sizeof(op->cmd.opcode) also need to be changed to be
op->cmd.nbytes because that is the actual indicator of opcode size.
Signed-off-by: Pratyush Yadav <p.yadav@ti.com> Reviewed-by: Jagan Teki <jagan@amarulasolutions.com>
projects / u-boot.git / log