Copy the best rational approximation calculation routines from Linux.
Typical usecase for these routines is to calculate the M/N divider
values for PLLs to reach a specific clock rate.
This is based on linux kernel commit:
"lib/math/rational.c: fix possible incorrect result from rational
fractions helper"
(sha1: 323dd2c3ed0641f49e89b4e420f9eef5d3d5a881)
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Signed-off-by: Tero Kristo <kristo@kernel.org>
On reset, the RTC loads the 2000-01-01 date with a wrong day of the
week (Sunday instead of Saturday).
Signed-off-by: Dario Binacchi <dariobin@libero.it>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Link: https://lore.kernel.org/r/20210602203805.11494-9-dariobin@libero.it
Update the driver to support the device tree and the driver model.
The read / write helpers in rtc_ops allow access to scratch registers
only. The offset parameter is added to the address of the scratch0
register.
Support for non-DM has been removed as there were no users.
Signed-off-by: Dario Binacchi <dariobin@libero.it>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Link: https://lore.kernel.org/r/20210602203805.11494-8-dariobin@libero.it
There have been some changes to the am335x-<board> DTs related to the
rtc node, so let's re-syncs them with Linux.
Signed-off-by: Dario Binacchi <dariobin@libero.it>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Link: https://lore.kernel.org/r/20210602203805.11494-7-dariobin@libero.it
The RTC module contains a kicker mechanism to prevent any spurious
writes from changing the register values. To set the time, you must
first unlock the TC registers, update them and then lock.
Signed-off-by: Dario Binacchi <dariobin@libero.it>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Link: https://lore.kernel.org/r/20210602203805.11494-6-dariobin@libero.it
To write correct data to the TC registers, the STATUS register must be
read until the BUSY bit is equal to zero. Once the BUSY flag is zero,
there is a 15 μs access period in which the TC registers can be
programmed.
The rtc_wait_not_busy() has been inspired by the Kernel.
Signed-off-by: Dario Binacchi <dariobin@libero.it>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Link: https://lore.kernel.org/r/20210602203805.11494-5-dariobin@libero.it
Use 32-bit access only where it is needed. Most of the RTC registers
contain useful information in the 8 least significant bits, the others
are reserved.
Signed-off-by: Dario Binacchi <dariobin@libero.it>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Link: https://lore.kernel.org/r/20210602203805.11494-4-dariobin@libero.it
The Davinci's onchip RTC is also present on TI OMAP1, AM33XX, AM43XX and
DRA7XX SOCs. So, let's enable compilation for these architectures too.
Signed-off-by: Dario Binacchi <dariobin@libero.it>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Link: https://lore.kernel.org/r/20210602203805.11494-2-dariobin@libero.it
Enable config options required to add support for USB Mass storage boot,
USB DFU boot, host and device modes in U-Boot.
Signed-off-by: Aswath Govindraju <a-govindraju@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Link: https://lore.kernel.org/r/20210604163043.12811-11-a-govindraju@ti.com
For USB DFU boot mode there is a limitation on the load address of boot
images that they have to be less than 0x70001000. Therefore, move the
SPL_TEXT_BASE address to 0x70000000.
Currently ATF is being loaded at 0x70000000, if the SPL is being loaded at
0x70000000 then ATF would overwrite SPL image when loaded. Therefore, move
the location of ATF to a latter location in SRAM, past the SPL image. Also
rearrange the EEPROM and BSS data on top of ATF.
Given below is the placement of various data sections in SRAM
┌──────────────────────────────────────┐0x70000000
│ │
│ │
│ │
│ SPL IMAGE (Max size 1.5 MB) │
│ │
│ │
│ │
├──────────────────────────────────────┤0x7017FFFF
│ │
│ SPL STACK │
│ │
├──────────────────────────────────────┤0x70192727
│ GLOBAL DATA(216 B) │
├──────────────────────────────────────┤0x701927FF
│ │
│ INITIAL HEAP (32 KB) │
│ │
├──────────────────────────────────────┤0x7019A7FF
│ │
│ BSS (20 KB) │
├──────────────────────────────────────┤0x7019F7FF
│ EEPROM DATA (2 KB) │
├──────────────────────────────────────┤0x7019FFFF
│ │
│ │
│ ATF (123 KB) │
│ │
│ │
├──────────────────────────────────────┤0x701BEBFB
│ BOOT PARAMETER INDEX TABLE (5124 B)│
├──────────────────────────────────────┤0x701BFFFF
│ │
│SYSFW FIREWALLED DUE TO A BUG (128 KB)│
│ │
├──────────────────────────────────────┤0x701DFFFF
│ │
│ DMSC CODE AREA (128 KB) │
│ │
└──────────────────────────────────────┘0x701FFFFF
Signed-off-by: Aswath Govindraju <a-govindraju@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Link: https://lore.kernel.org/r/20210604163043.12811-9-a-govindraju@ti.com
AM64 EVM board has a micro USB 2.0 AB connector and the USB0_VBUS is
connected with a resistor divider in between. USB0_DRVVBUS pin is muxed
between USB0_DRVVBUS and GPIO1_79 signals.
Add the corresponding properties and set the pinmux mode for USB subsystem
in the evm dts file.
Signed-off-by: Aswath Govindraju <a-govindraju@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Link: https://lore.kernel.org/r/20210604163043.12811-7-a-govindraju@ti.com
U-Boot either supports USB host or device mode for a node at a time in the
device tree nodes. To support both host and dfu bootmodes, dr_mode is set
to "peripheral" by default and then fixed based on the mode selected by
the boot mode config dip switches on the board.
This needs to happen before the cdns3 generic layer binds the usb device
to a host or a device driver. Therefore, use fdtdec_setup_board()
implementation to fixup the device tree property.
Signed-off-by: Aswath Govindraju <a-govindraju@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Link: https://lore.kernel.org/r/20210604163043.12811-4-a-govindraju@ti.com
Add support for providing ATF load address with a Kconfig symbol.
Signed-off-by: Aswath Govindraju <a-govindraju@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Reviewed-by: Suman Anna <s-anna@ti.com>
Link: https://lore.kernel.org/r/20210604163043.12811-2-a-govindraju@ti.com
Update the ddr settings to use the DDR reg config tool rev 0.5.0.
This enables 2666MTs LPDDR configuration on J7200.
Signed-off-by: Kevin Scholz <k-scholz@ti.com>
Signed-off-by: Praneeth Bajjuri <praneeth@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Tested-by: Suman Anna <s-anna@ti.com>
Link: https://lore.kernel.org/r/20210603131453.11414-1-praneeth@ti.com
Currently the config options CONFIG_SYS_DFU_DATA_BUF_SIZE and
CONFIG_SYS_DFU_MAX_FILE_SIZE are being set in include/configs/<board>.h
files and also in <board_name>_defconfig files without a Kconfig option. It
is easier for users to set these configs in defconfig files than in config
header files as they are a part of the source code.
Add Kconfig symbols, and update the defconfigs by using tools/moveconfig.py
script.
Suggested-by: Pratyush Yadav <p.yadav@ti.com>
Signed-off-by: Aswath Govindraju <a-govindraju@ti.com>
Acked-by: Oleksandr Suvorov <oleksandr.suvorov@toradex.com>
Acked-by: Matthias Brugger <mbrugger@suse.com>
Acked-by: Lukasz Majewski <lukma@denx.de>
TFTP transfer size can be used to re-size the TFTP progress bar on
single line based on the server reported file size. The support for
this has been around from 2019, but it was never converted to proper
Kconfig.
While adding this new Kconfig, enable it by default for OMAP2+ and K3
devices also.
Signed-off-by: Tero Kristo <kristo@kernel.org>
To quote Simon, first for the display changes:
At present we have two ways of showing a hex dump. Once has been in
U-Boot since the dawn of time and the other was recently added from
Linux.
They both have their own unique features.
This series makes a few changes to bring them closer together. It also
adds support for logging a buffer, which is useful since it can put it
through the same log drivers as other logging output.
Also it adds tests, so we can check the behaviour.
And then the logging changes:
At present when logging is not enabled, all log() calls become nops.
This does not seem right, since if the log level is high enough then
there should be some sort of message. So in that case, this series
updates it to print the message if the log level is above LOGL_INFO.
This mimics the behaviour for the log_...() macros like log_debug() and
log_info(), so we can drop the special case for these.
Also the current implementation does not support multiple log calls on
the same line nicely. The tags are repeated so the line is very hard to
read. This series adds that as a new feature.
At present if logging not enabled, log_info() becomes a nop. But we want
log output at the 'info' level to be akin to printf(). Update the macro to
pass the output straight to printf() in this case.
This mimics the behaviour for the log_...() macros like log_debug() and
log_info(), so we can drop the special case for these.
Add new tests to cover this case.
Signed-off-by: Simon Glass <sjg@chromium.org>
The pr_cont_test.c test requires CONFIG_LOG since it directly accesses
fields in global_data that require it. Move the test into the CONFIG_LOG
condition to avoid build errors.
Enable CONFIG_LOG on sandbox (not sandbox_spl, etc.) so that we still run
this test. This requires resyncing of the configs.
Signed-off-by: Simon Glass <sjg@chromium.org>
At present print_buffer() outputs a hex dump but it is not possible to
place this dump in a string. Refactor it into a top-level function which
does the printing and a utility function that dumps a line into a string.
This makes the code more generally useful.
Signed-off-by: Simon Glass <sjg@chromium.org>
At present print_hex_dump() only supports either 16- or 32-byte lines.
With U-Boot we want to support any line length up to a maximum of 64.
Update the function to support this, with 0 defaulting to 16, as with
print_buffer().
Signed-off-by: Simon Glass <sjg@chromium.org>
The current implementation outputs an address as a pointer. Update the
code to use an address instead, respecting the 32/64 nature of the CPU.
Add some initial tests copied from print_test_display_buffer(), just the
ones that can pass with the current implementation.
Note that for this case print_hex_dump() and print_bufffer() produce the
same result. For now the tests are duplicated sine we have separate
functions.
Signed-off-by: Simon Glass <sjg@chromium.org>
Move the comments to the header file so people can find the function info
without digging in the implementation. Fix up the code style and add an
enum for the first arg.
Signed-off-by: Simon Glass <sjg@chromium.org>
At present with print_buffer() U-Boot shows four spaces between the hex
and ASCII data. Two seems enough and matches print_hex_dump(). Change it.
Signed-off-by: Simon Glass <sjg@chromium.org>
Add a test for this function, to cover the various features. Expand the
expect_str length to take acount of the ~300-bytes lines generated in one
case.
Signed-off-by: Simon Glass <sjg@chromium.org>
This test predates the test framework in U-Boot. It uses #define DEBUG and
assert() to check the result. Update it to use the framework so it can
report failure constitent with other tests.
Signed-off-by: Simon Glass <sjg@chromium.org>
If a line of more than 256 bytes is generated, the test will fail but the
reason is not clear. Add a check for this condition and print a helpful
message.
Signed-off-by: Simon Glass <sjg@chromium.org>
If the console output buffer is exhausted, characters are silently dropped
from the end. Detect this condition and report an error when reading back
the characters.
Signed-off-by: Simon Glass <sjg@chromium.org>
To quote the series author, Patrick Delaunay:
On STM32MP15x platform we can use OP-TEE, loaded in DDR in a region
protected by a firewall. This region is reserved in the device with
the "no-map" property as defined in the binding file
doc/device-tree-bindings/reserved-memory/reserved-memory.txt.
Sometime the platform boot failed in U-Boot on a Cortex A7 access to
this region (depending of the binary and the issue can change with compiler
version or with code alignment), then the firewall raise an error,
for example:
E/TC:0 tzc_it_handler:19 TZC permission failure
E/TC:0 dump_fail_filter:420 Permission violation on filter 0
E/TC:0 dump_fail_filter:425 Violation @0xde5c6bf0, non-secure privileged read,
AXI ID 5c0
E/TC:0 Panic
After investigation, the forbidden access is a speculative request performed
by the Cortex A7 because all the DDR is mapped as MEMORY with CACHEABLE
property.
The issue is solved only when the region reserved by OP-TEE is no more
mapped in U-Boot as it is already done in Linux kernel.
Tested on DK2 board with OP-TEE 3.12 / TF-A 2.4:
With hard-coded address for OP-TEE reserved memory,
the error doesn't occur.
void dram_bank_mmu_setup(int bank)
{
....
for (i = start >> MMU_SECTION_SHIFT;
i < (start >> MMU_SECTION_SHIFT) + (size >> MMU_SECTION_SHIFT);
i++) {
option = DCACHE_DEFAULT_OPTION;
if (i >= 0xde0)
option = INVALID_ENTRY;
set_section_dcache(i, option);
}
}
Just by modifying the test on 0xde0 to 0xdf0, the OP-TEE memory protected
by firewall is mapped cacheable and the error occurs.
I think that it can be a general issue for ARM architecture: the "no-map" tag
of reserved memory in device should be respected by U-Boot if firewall
is configured before U-Boot execution.
But I don't propose a generic solution in
arm/lib/cache-cp15.c:dram_bank_mmu_setup()
because the device tree parsing done in lmb_init_and_reserve() takes a
long time when it is executed without data cache.
No more map the reserved region with "no-map" property by marking
the corresponding TLB entries with invalid entry (=0) to avoid
speculative access.
The device tree parsing done in lmb_init_and_reserve() takes a
long time when it is executed without data cache, so it is called in
enable_caches() before to disable it.
This patch fixes an issue where predictive read access on secure DDR
OP-TEE reserved area are caught by firewall.
Series-cc: marex
Series-cc: pch
Series-cc: marek.bykowski@gmail.com
Series-cc: Ard Biesheuvel <ardb@kernel.org>
Series-cc: Etienne Carriere <etienne.carriere@linaro.org>
Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
Add 8M for the U-Boot reserved memory (display, fdt, gd, ...)
mapped cacheable before relocation.
Without this patch the device tree, located before the MALLOC area
is not tagged cacheable just after relocation, before mmu reconfiguration.
This patch reduces the duration for device tree parsing in
lmb_init_and_reserve.
Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
Save the 'no-map' information present in 'reserved-memory' node to allow
correct handling when the MMU is configured in board to avoid
speculative access.
This binding is defined in
doc/device-tree-bindings/reserved-memory/reserved-memory.txt
Additional properties:
...
no-map (optional) - empty property
- Indicates the operating system must not create a virtual mapping
of the region as part of its standard mapping of system memory,
nor permit speculative access to it under any circumstances other
than under the control of the device driver using the region.
Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
Add a test to check the management of reserved region with flags.
Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Add a new function lmb_is_reserved_flags to check if
an address is reserved with a specific flags.
This function can be used to check if an address was
reserved with no-map flags with:
lmb_is_reserved_flags(lmb, addr, LMB_NOMAP);
Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
Add "flags" in lmb_property to save the "no-map" property of
reserved region and a new function lmb_reserve_flags() to check
this flag.
The default allocation use flags = LMB_NONE.
The adjacent reserved memory region are merged only when they have
the same flags value.
This patch is partially based on flags support done in Linux kernel
mm/memblock .c (previously lmb.c); it is why LMB_NOMAP = 0x4, it is
aligned with MEMBLOCK_NOMAP value.
Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Enable NAND on mmc defconfig for greater flexibility and for consistency
reasons. All our other boards that have a NAND flash integrated, enable
NAND regardless of the type of the defconfig.
Signed-off-by: Tudor Ambarus <tudor.ambarus@microchip.com>
