Versal NET platform is based on Versal chip which is reusing a lot of IPs.
For more information about new IPs please take a look at DT which describe
currently supported devices.
The patch is adding architecture and board support with soc detection
algorithm. Generic setting should be very similar to Versal but it will
likely diverge in longer run.
Signed-off-by: Michal Simek <michal.simek@amd.com>
Link: https://lore.kernel.org/r/320206853dc370ce290a4e7b6d0bb26b05206021.1663589964.git.michal.simek@amd.com
Currently all GPIOs supported by CMD_EXT_CONTROL/CMD_GET_EXT_CONTROL_STATUS
commands (last 16 GPIOs) are available only when FEAT_PERIPH_MCU feature
bit is set. So do not register these GPIOs by U-Boot driver when this
feature bit is not set, so U-Boot 'gpio' command would see only GPIOs which
really exists.
Fixes: 5e4d24ccc1 ("gpio: Add Turris Omnia MCU driver")
Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>
Disable AVAILABLE_HARTS mechanism to make sure that all harts
can boot to Kernel shell successfully.
Signed-off-by: Rick Chen <rick@andestech.com>
Reviewed-by: Leo Yu-Chi Liang <ycliang@andestech.com>
In SMP all harts will register themself in available_hart
during start up. Then main hart will send IPI to other harts
according to this variables. But this mechanism may not
guarantee that all other harts can jump to next stage.
When main hart is sending IPI to other hart according to
available_harts, but other harts maybe still not finish the
registration. Then the SMP booting will miss some harts finally.
So let it become an option and it will be enabled by default.
Please refer to the discussion:
https://www.mail-archive.com/u-boot@lists.denx.de/msg449997.html
Signed-off-by: Rick Chen <rick@andestech.com>
Reviewed-by: Leo Yu-Chi Liang <ycliang@andestech.com>
U-Boot and SPL don't necessary share the same location, so we might end
with U-Boot SPL in read-only memory (XIP) and U-Boot in read-write memory.
In case of non XIP boot mode, we rely on such variables as "hart_lottery"
and "available_harts_lock" which we use as atomics.
The problem is that CONFIG_XIP also propagate to main U-Boot, not only SPL,
so we need CONFIG_SPL_XIP to distinguish SPL XIP from other XIP modes.
This adds an option special for SPL to behave it in XIP manner and we don't
use hart_lottery and available_harts_lock, during start proccess.
Signed-off-by: Nikita Shubin <n.shubin@yadro.com>
Reviewed-by: Rick Chen <rick@andestech.com>
When processing USB_REQ_CLEAR_FEATURE, USB_REQ_SET_FEATURE, and
USB_REQ_GET_STATUS packets in dwc2_ep0_setup an out of bounds access
can occur. This is caused by the wIndex field of the usb control packet
being used as an index into an array whose size is DWC2_MAX_ENDPOINTS (4).
Signed-off-by: Alison Huffman <alisn@google.com>
final patch for blk improvements
-----BEGIN PGP SIGNATURE-----
iQFFBAABCgAvFiEEslwAIq+Gp8wWVbYnfxc6PpAIreYFAmMws50RHHNqZ0BjaHJv
bWl1bS5vcmcACgkQfxc6PpAIreYM4ggAk6Zljtm3UfpW5RFdUGQ+hsy5dAAAJIpp
nXGXCCtpS055XE3FkWGX6huO+/5awsr1HiB2hoTQc5/ySg147CRqETulaDqMkaBZ
0ybqYko2o9kWmlCV7DSPFDyMr4rf/vD8FOblQnLVjkimcMBEufJba+bYhUcfA5Tg
BM+l9QX1OXjCht6apKPRM+WuKgsxd+qthdAZigjQ0KEVS3SblEbJLDXoYJPhkW8g
5gLBs8IMPfrgfIeuSN5s0t+wLnhxrQWqdSr59zjh/cR2FmYC+0+woK3peCZJULmS
KkKQWuhlWrj12n1RHFwZ8hCNpIaiEOvGR2Urk7GplnZvda/+4Dg/gA==
=AcpT
-----END PGP SIGNATURE-----
Merge tag 'dm-next-25sep22' of https://gitlab.denx.de/u-boot/custodians/u-boot-dm into next
sandbox SCSI conversion to driver model
final patch for blk improvements
Add a simple uclass test for SCSI. It reads the partition table from a
disk image and checks that it looks correct.
Signed-off-by: Simon Glass <sjg@chromium.org>
At present sandbox is producing a warning about SCSI migration. Drop the
legacy code and replace it with a new implementation.
Also drop the SATA command, which does not work with driver model.
Signed-off-by: Simon Glass <sjg@chromium.org>
This will be needed to run unit tests, once the SCSI code is used for USB
as well. Enable it for all sandbox builds.
Signed-off-by: Simon Glass <sjg@chromium.org>
Move this code out of the helper function so we can (later) add it as part
of the shared emulation code. Set a default value of 0 for buff_used since
that is what we use when there is an error.
Signed-off-by: Simon Glass <sjg@chromium.org>
In preparation for sharing the emulation code between two drivers, move
some of the fields into a new struct. Use a separate header file so it
can be used by various drivers.
Signed-off-by: Simon Glass <sjg@chromium.org>
This has the same name as a field in our local private struct, which is
confusing. Change the name to xfer_len instead.
Signed-off-by: Simon Glass <sjg@chromium.org>
The following faulty behavior was observed. The sandbox configured with
CONFIG_SANDBOX_CRASH_RESET=y was invoked with
./u-boot -T -S
After executing `exception undefined' the sandbox reboots.
When executing `exception undefined' the sandbox exits with SIGSEGV.
The expected behavior is that the sandbox should reboot again.
If we are relaunching the sandbox in a signal handler, we have to unblock
the respective signal before calling execv(). See signal(7) man-page.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
To quote the author:
On certain places it is required to flush output print buffers to ensure
that text strings were sent to console or serial devices. For example when
printing message that U-Boot is going to boot kernel or when U-Boot is
going to change baudrate of terminal device.
Some console devices, like UART, have putc/puts functions which just put
characters into HW transmit queue and do not wait until all data are
transmitted. Doing some sensitive operations (like changing baudrate or
starting kernel which resets UART HW) cause that U-Boot messages are lost.
Therefore introduce a new flush() function, implement it for all serial
devices via pending(false) callback and use this new flush() function on
sensitive places after which output device may go into reset state.
This change fixes printing of U-Boot messages:
"## Starting application at ..."
"## Switch baudrate to ..."
In addition, take a patch from Heinrich to rename some EFI test
functions in order to not conflict with this series.
In a lot of cases kernel resets UART HW. To ensure that U-Boot messages
printed before booting the kernel are not lost, call new U-Boot console
flush() function.
Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Changing baudrate is a sensitive operation. To ensure that U-Boot messages
printed before changing baudrate are not lost, call new U-Boot console
flush() function.
Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Like in all other console functions, implement also serial_flush() function
as a fallback int console flush() function.
Flush support is available only when config option CONSOLE_FLUSH_SUPPORT is
enabled. So when it is disabled then provides just empty static inline
function serial_flush().
Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
UART drivers have putc/puts functions which just put characters into HW
transmit queue and do not wait until all data are transmitted.
Implement flush callback via serial driver's pending(false) callback which
waits until HW transmit all characters from the queue.
Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
On certain places it is required to flush output print buffers to ensure
that text strings were sent to console or serial devices. For example when
printing message that U-Boot is going to boot kernel or when U-Boot is
going to change baudrate of terminal device.
Therefore introduce a new flush() and fflush() functions into console code.
These functions will call .flush callback of associated stdio_dev device.
As this function may increase U-Boot side, allow to compile U-Boot without
this function. For this purpose there is a new config CONSOLE_FLUSH_SUPPORT
which is enabled by default and can be disabled. It is a good idea to have
this option enabled for all boards which have enough space for it.
When option is disabled when U-Boot defines just empty static inline
function fflush() to avoid ifdefs in other code.
Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
An upcoming patch set creates a global function flush(). To make debugging
easier we should not use the same name for a static function.
Rename static functions in the LoadImage() unit test adding an efi_st_
prefix.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
To quote the author, for the first 9 patches:
This patch series fixes U-Boot code to correctly handle RAM size larger
than 2 GB and then fixes fsl ddr driver to do not crash U-Boot when 4 GB
DDR module is detected when U-Boot operates in 32-bit mode (as opposite
of the 36-bit mode).
With this patch series it is possible to boot 32-bit U-Boot with 4 GB
SODIMM DDR3 module without crashes. U-Boot will still use just
CONFIG_MAX_MEM_MAPPED amount of RAM, but it is better than crashing due
to the truncating of 4GB value to 32-bit number (which is zero).
I tested this patch series on powerpc P2020 based board but only with
U-Boot v2022.04 because U-Boot master branch is still broken on P2020.
And then the final two patches here are (in my mind at least) related
clean-ups.
32-bit U-Boot builds cannot use more than around 2 GB of DDR memory. But on
some platforms/boards it is possible to connect also 4 GB SODIMM DDR memory.
U-Boot currently prints only effective size of RAM which can use, which may
be misleading as somebody would expect that this line prints total size of
connected DDR modules. So change show_dram_config code to prints both real
and effective DRAM size if they are different. If they are same then print
just one number like before. It is possible that effective size is just few
bytes smaller than the real size, so print both numbers only in case
function print_size() prints formats them differently.
Signed-off-by: Pali Rohár <pali@kernel.org>
Function print_size() round size to the nearst value with one decimal
fraction number. But in special cases also unit order may overflow.
For example value 1073689396 is printed as "1024 MiB" and value 1073741824
as "1 GiB".
Fix this issue by detecting order overflow and increasing unit order.
With this change also value 1073689396 is printed as "1 GiB".
Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
During init_dram() is called also setup_ddr_tlbs_phys() function which may
print message about unmapped DDR memory. So in this case print also
re-aligning filler after unmapped DDR memory message.
Signed-off-by: Pali Rohár <pali@kernel.org>
Currently U-Boot SPL prints just generic message "2 GiB left unmapped".
Change it to more detailed "2 GiB of DDR memory left unmapped in U-Boot".
This is just U-Boot configuration and operating system may map more (or
also less) memory.
Signed-off-by: Pali Rohár <pali@kernel.org>
During init_dram() is called also compute_lowest_common_dimm_parameters()
function which prints multi-line detailed output. So print also re-aligning
filler after "Detected ?DIMM" line to have "DRAM: " output aligned.
Signed-off-by: Pali Rohár <pali@kernel.org>
U-Boot core code already handles the case when RAM size is bigger than
CONFIG_MAX_MEM_MAPPED. So there is no need to do duplicate check in fsl ddr
driver for CONFIG_MAX_MEM_MAPPED. Instead simplify code to just check if
RAM size can be representable in phys_size_t type. And avoid printing
warning if phys_size_t is just 1 byte smaller than RAM size, which is the
typical situation with 4 GB DDR module.
Signed-off-by: Pali Rohár <pali@kernel.org>
Function fsl_ddr_compute() always return size in unsigned long long type,
but function fsl_ddr_sdram_size() returns size in phys_size_t type.
When 36-bit addressing mode is not enabled then phys_size_t type is only
32-bit and thus it cannot store value 4GB (0x100000000). Function
fsl_ddr_sdram_size() in this case returns truncated value 0x0.
Fix this issue by returning the highest representable value, which is
0xffffffff (4GB - 1 byte).
This change fixes crashing of proper U-Boot because it detected 4 GB module
as RAM with zero size.
Signed-off-by: Pali Rohár <pali@kernel.org>
Check needs to be done against CONFIG_MAX_MEM_MAPPED macro and not fixed
size 4GB (as CONFIG_MAX_MEM_MAPPED can be lower and for example for e500
cores it is just 2GB). Also fix printf re-align, which should be applied
only for non-SPL builds, during init_dram() call.
Signed-off-by: Pali Rohár <pali@kernel.org>
Members gd->ram_size and gd->ram_top are of type phys_addr_t which does not
have to fit into ulong type. So cast them into unsigned long long.
Fixes: 37dc958947 ("global_data.h: Change ram_top type to phys_addr_t")
Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Commit 37dc958947 ("global_data.h: Change ram_top type to phys_addr_t")
changed type of ram_top member from ulong to phys_addr_t but did not
changed types in board_get_usable_ram_top() function which returns value
for ram_top.
So change ulong to phys_addr_t type also in board_get_usable_ram_top()
signature and implementations.
Fixes: 37dc958947 ("global_data.h: Change ram_top type to phys_addr_t")
Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Ensure that top of RAM can be represented by phys_size_t type. If RAM is
too large or RAM base address is too upper then limit RAM size to prevent
address space overflow.
Signed-off-by: Pali Rohár <pali@kernel.org>
CONFIG_MAX_MEM_MAPPED when defined specifies upper memory mapped limit.
So check for it always, and not only when CONFIG_VERY_BIG_RAM is defined.
Signed-off-by: Pali Rohár <pali@kernel.org>
