Replace XILINX_DCACHE_BYTE_SIZE macro with two Kconfig symbols for
instruction and data caches sizes, respectively:
CONFIG_XILINX_MICROBLAZE0_ICACHE_SIZE
CONFIG_XILINX_MICROBLAZE0_DCACHE_SIZE
Also, get rid of the hardcoded value in icache_disable().
Signed-off-by: Ovidiu Panait <ovpanait@gmail.com>
Link: https://lore.kernel.org/r/20220531181435.3473549-8-ovpanait@gmail.com
Signed-off-by: Michal Simek <michal.simek@amd.com> (s/bralid/brlid/g)
Factor out icache/dcache components from flush_cache() function. Call the
newly added __flush_icache()/__flush_dcache() functions inside
icache_disable() and dcache_disable(), respectively. There is no need to
flush both caches when disabling a particular cache type.
Signed-off-by: Ovidiu Panait <ovpanait@gmail.com>
Link: https://lore.kernel.org/r/20220531181435.3473549-7-ovpanait@gmail.com
Signed-off-by: Michal Simek <michal.simek@amd.com>
Replace CONFIG_ICACHE with a Kconfig option more limited in scope -
XILINX_MICROBLAZE0_USE_WIC. It should be enabled if the processor supports
the "wic" (Write to Instruction Cache) instruction. It will be used to
guard "wic" invocations in microblaze cache code.
Signed-off-by: Ovidiu Panait <ovpanait@gmail.com>
Link: https://lore.kernel.org/r/20220531181435.3473549-6-ovpanait@gmail.com
Signed-off-by: Michal Simek <michal.simek@amd.com>
Replace CONFIG_DCACHE with a Kconfig option more limited in scope -
XILINX_MICROBLAZE0_USE_WDC. It should be enabled if the processor supports
the "wdc" (Write to Data Cache) instruction. It will be used to guard
"wdc" invocations in microblaze cache code.
Also, drop all ifdefs around flush_cache() calls and only keep one
CONFIG_IS_ENABLED() guard within flush_cache() itself.
Signed-off-by: Ovidiu Panait <ovpanait@gmail.com>
Link: https://lore.kernel.org/r/20220531181435.3473549-5-ovpanait@gmail.com
Signed-off-by: Michal Simek <michal.simek@amd.com>
XILINX_USE_DCACHE macro was removed in 7556fa09e0e ("microblaze: Simplify
cache handling"), but it was still used in a couple of places.
Replace those occurences with CONFIG_DCACHE.
Signed-off-by: Ovidiu Panait <ovpanait@gmail.com>
Link: https://lore.kernel.org/r/20220531181435.3473549-4-ovpanait@gmail.com
Signed-off-by: Michal Simek <michal.simek@amd.com>
Microblaze is using NEEDS_MANUAL_RELOC from the beginnging. This is causing
issues with function pointer arrays which need to be updated manually after
relocation. Building code with -fPIC and linking with -pic will remove this
limitation and there is no longer need to run manual update.
By default still old option is enabled but by disabling NEEDS_MANUAL_RELOC
code will be compiled for full relocation.
The patch does couple of things which are connected to each other.
- Define STATIC_RELA dependency to call relocate-rela to fill sections.
- REMAKE_ELF was already enabled but u-boot file can't be used because
sections are empty. relocate-rela will fill them and output file is
u-boot.elf which should be used.
- Add support for full relocation (u-boot.elf)
- Add support for early relocation when u-boot.bin is loaded to different
address then CONFIG_SYS_TEXT_BASE
- Add rela.dyn and dynsym sections
Disabling NEEDS_MANUAL_RELOC U-Boot size increased by 10% of it's original
size (550kB to 608kB).
Signed-off-by: Michal Simek <michal.simek@amd.com>
Link: https://lore.kernel.org/r/a845670b34925859b2e321875f7588a29f6655f9.1655299267.git.michal.simek@amd.com
Symbol handling depends on compilation flags. Right now manual relocation
is used that's why symbols can be referenced just by name and there is no
need to find them out. But when position independent code (PIC) is used
symbols need to be described differently. That's why having one macro
change is easier than changing the whole code.
Signed-off-by: Michal Simek <michal.simek@amd.com>
Link: https://lore.kernel.org/r/d704e9a267c8b536452fb999111dbfbc9d652be5.1655299267.git.michal.simek@amd.com
Right now U-Boot runs all the time from the same address where it is loaded
but going to full relocation code starting address doesn't need to be fixed
and can be simply discovered from reading PC register. That's why use r20
to get PC address and subtract offset from the beginning to get starting
address.
Signed-off-by: Michal Simek <michal.simek@amd.com>
Link: https://lore.kernel.org/r/044b727c33dfbe662f68512d0da0775a4805f360.1655299267.git.michal.simek@amd.com
Enable u-boot.elf recreation from u-boot.bin to prepare for removing manul
relocation. Enable option for big endian configuration but it is not used
too much that's why it is completely untested.
By supporting this system there is a need to define LITTLE/BIG endian
Kconfig options to pass -EL/-EB flags.
Full command line for u-boot.elf recreation looks like this:
microblazeel-xilinx-linux-gnu-objcopy -I binary -B microblaze \
-O elf32-microblazeel u-boot.bin u-boot-elf.o
Signed-off-by: Michal Simek <michal.simek@amd.com>
Link: https://lore.kernel.org/r/7e242a519fcd1c693b9103c5599b515af555ca43.1655299267.git.michal.simek@amd.com
CONFIG_SYS_INIT_SP_OFFSET macro place stack to TEXT_BASE - SYS_MALLOC_F_LEN
but there is no reason to do it now because board_init_f_alloc_reserve()
returns exact location where stack should be. That's why stack location is
calculated at run time and there is no need to hardcode it via macro. This
change will help with placing U-Boot to any address.
Signed-off-by: Michal Simek <michal.simek@amd.com>
Link: https://lore.kernel.org/r/e9aee69646e022fd8a96cbee2d2a07ab81fb6e05.1655299267.git.michal.simek@amd.com
When U-Boot starts stack protection can be already enabled that's why setup
the lowest possible SLR value which is address 0. And the highest possible
stack in front of U-Boot. That's why you should never load U-Boot to the
beginning of DDR. There must be some space reserved. Code is using this
location for early malloc space, early global data and stack.
Signed-off-by: Michal Simek <michal.simek@amd.com>
Link: https://lore.kernel.org/r/86b9748bad12142659804d6381bc6bbf20be44f1.1655299267.git.michal.simek@amd.com
Board is using kv260 design for couple of parts defined by spec like i2c
eeproms, ina260, uart, etc.
Board has 4 gems. One gem connected via PS SGMII(GT), another PS RGMII(MIO)
and 2 via EMIO. First two shares the same MIO lines for PHYs. PL based one
have separate EMIO lines via PL.
Also two USB 3.0 with usb hubs are present. USB phys and USB hubs should
have separate reset line. The first usb0 hub also has USB-SD controller
(usb2244) connected to port 0.
To test compatibility with k26 you can run:
fdtoverlay -o /tmp/output.dtb -i arch/arm/dts/zynqmp-sm-k26-revA.dtb \
arch/arm/dts/zynqmp-sck-kr-g-revA.dtbo
Also add support for kr260-revB board. Based on FRU it is revision B
but schematics can be label as revA03.
Changes in revB are:
- SFP light
- GEM2/3 TX_CLK fixes
- PMOD/RPI connector fixes
- Replace si5332 with oscilators
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Signed-off-by: Michal Simek <michal.simek@amd.com>
Link: https://lore.kernel.org/r/dac2ee1826e73b89c8cc1e430354eb43d291f675.1652870941.git.michal.simek@amd.com
Add a fuzzing engine driver for the sandbox to take inputs from
libfuzzer and expose them to the fuzz tests.
Signed-off-by: Andrew Scull <ascull@google.com>
Add an implementation of LLVMFuzzerTestOneInput() that starts the
sandbox on a secondary thread and exposes a function to synchronize the
generation of fuzzing inputs with their consumption by the sandbox.
Signed-off-by: Andrew Scull <ascull@google.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Move the program's entry point to os.c, in preparation for a separate
fuzzing entry point to be added.
Signed-off-by: Andrew Scull <ascull@google.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Add CONFIG_ASAN to build with the Address Sanitizer. This only works
with the sandbox so the config is likewise dependent. The resulting
executable will have ASAN instrumentation, including the leak detector
that can be disabled with the ASAN_OPTIONS environment variable:
ASAN_OPTIONS=detect_leaks=0 ./u-boot
Since u-boot uses its own dlmalloc, dynamic allocations aren't
automatically instrumented, but stack variables and globals are.
Instrumentation could be added to dlmalloc to poison and unpoison memory
as it is allocated and deallocated, and to introduce redzones between
allocations. Alternatively, the sandbox may be able to play games with
the system allocator and somehow still keep the required memory
abstraction. No effort to address dynamic allocation is made by this
patch.
The config is not yet enabled for any targets by default.
Signed-off-by: Andrew Scull <ascull@google.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Rename the sections used to implement linker lists so they begin with
'__u_boot_list' rather than '.u_boot_list'. The double underscore at the
start is still distinct from the single underscore used by the symbol
names.
Having a '.' in the section names conflicts with clang's ASAN
instrumentation which tries to add redzones between the linker list
elements, causing expected accesses to fail. However, clang doesn't try
to add redzones to user sections, which are names with all alphanumeric
and underscore characters.
Signed-off-by: Andrew Scull <ascull@google.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Rename the sections used for defining sandbox command line options so
that they don't start with a '.'. ELF says that sections starting with a
'.' are reserved for system use, but the sandbox runs as a normal user
process so should be using user sections instead.
Clang's ASAN adds redzones to non-user sections and the extra padding
meant that the list of options was being corrupted. Naming the sections
as user sections avoids this issue as clang handles them as we intended.
Signed-off-by: Andrew Scull <ascull@google.com>
Rename the sections used for placing the EFI runtime so that they don't
start with a '.'. ELF says that sections starting with a '.' are
reserved for system use, but the sandbox runs as a normal user process
so should be using user sections instead.
Clang's ASAN adds redzones to non-user sections and the extra padding
meant that the list of options was being corrupted. Naming the sections
as user sections avoids this issue as clang handles them as we intended.
Signed-off-by: Andrew Scull <ascull@google.com>
This was previously needed, but U-Boot is now capable of parsing
the new "phy-connection-type" property that is already used in
the main devicetree.
Signed-off-by: Frieder Schrempf <frieder.schrempf@kontron.de>
Reviewed-by: Fabio Estevam <festevam@denx.de>
This syncs the devicetree files with the latest Linux kernel (5.19-rc2).
This also fixes the currently broken ethernet support:
Before:
Net: Could not get PHY for FEC0: addr 0
After:
Net: eth0: ethernet@30be0000
Signed-off-by: Frieder Schrempf <frieder.schrempf@kontron.de>
Reviewed-by: Fabio Estevam <festevam@denx.de>
Timeouts are not expected to happen and are handled as fatal errors.
Increase all timeouts to 1 second as defensive measure to avoid relying
on the timing behaviour of certain firmware versions or configurations.
Signed-off-by: Janne Grunau <j@jannau.net>
Reviewed-by: Mark Kettenis <kettenis@openbsd.org>
Tested-by: Mark Kettenis <kettenis@openbsd.org>
The NVMe firmware in the macOS 13 beta blocks or crashes with u-boot's
current minimal RTKit implementation. It does not provide buffers for
the firmware's buffer requests. The ANS2 firmware included in macOS 11
and 12 tolerates this. The firmware included in the first macOS 13 beta
requires buffers for the crashlog and ioreport endpoints to function.
In the case of the NVMe the buffers are physical memory. Access to
physical memory is guarded by what Apple calls SART.
Import m1n1's SART driver (exclusively used for the NVMe controller).
Implement buffer management helpers for RTKit. These are generic since
other devices (none in u-boot so far) require different handling.
Signed-off-by: Janne Grunau <j@jannau.net>
Reviewed-by: Mark Kettenis <kettenis@openbsd.org>
Tested-by: Mark Kettenis <kettenis@openbsd.org>
AST2600 supports boot from SPI(mmap), eMMC, and UART.
This patch adds the boot mode detection and return the
corresponding boot device type.
Signed-off-by: Chia-Wei Wang <chiawei_wang@aspeedtech.com>
The commit b583348ca8c8 ("image: fit: Align hash output buffers") places
the hash output buffer at the .bss section. However, AST2600 by default
executes SPL in the NOR flash XIP way. This results in the hash output
cannot be written to the buffer as it is located at the R/X only region.
We need to move the .bss section out of the SPL body to the DRAM space,
where hash output can be written to. This patch includes:
- Define the .bss section base and size
- A new SPL linker script is added with a separate .bss region specified
- Enable CONFIG_SPL_SEPARATE_BSS kconfig option
Signed-off-by: Chia-Wei Wang <chiawei_wang@aspeedtech.com>
Reviewed-by: Neal Liu <neal_liu@aspeedtech.com>
The HPE SoC is new to linux. A basic device tree layout with minimum
required for linux to boot including a timer and watchdog support has
been created.
The dts file is empty at this point but will be updated in subsequent
updates as board specific features are enabled.
Signed-off-by: Nick Hawkins <nick.hawkins@hpe.com>
The GXP is the HPE BMC SoC that is used in the majority
of current generation HPE servers. Traditionally the asic will
last multiple generations of server before being replaced.
Info about SoC:
HPE GXP is the name of the HPE Soc. This SoC is used to implement many BMC
features at HPE. It supports ARMv7 architecture based on the Cortex A9
core. It is capable of using an AXI bus to whicha memory controller is
attached. It has multiple SPI interfaces to connect boot flash and BIOS
flash. It uses a 10/100/1000 MAC for network connectivity. It has multiple
i2c engines to drive connectivity with a host infrastructure. There
currently are no public specifications but this process is being worked.
Signed-off-by: Nick Hawkins <nick.hawkins@hpe.com>
Seems that u-boot can't probe i2c bus at 2.6Mhz speed, so lower
the speed to the default value 100Khz.
v2: fix i2c1 frequency in the root omap3-u-boot.dtsi include.
Signed-off-by: Anthoine Bourgeois <anthoine.bourgeois@gmail.com>
- Correct livetree support in stm32mp1 boards
- Activate livetree for stm32mp15 DHSOM boards
-----BEGIN PGP SIGNATURE-----
iQEzBAABCgAdFiEE56Yx6b9SnloYCWtD4rK92eCqk3UFAmKsehgACgkQ4rK92eCq
k3UexAf+JThCd7FlN3OkTVKIdZKeNm2KpQxrqt20whiqp/nSUzxXrjdlCTKZEER2
lLJoVnwr+bkmdlqsa6gAZXSsd0lUv37XnLsLA5or278tFNlKp6gzYrz49FR59mVC
ie7/NlY5FgM5qmKGCob7tjwJ78r2/S3T2EaLiAMWUmw2UB5KZU6h3napHZ+1T0se
vaEAVRzAaZeYzKU3k6RBSv2tXQ6ssvfpp9RcXpRGtrN908AqDhHiOfntuOrnsEe0
9rjY1DSXO9a5WqHRm2KQ3FrA/By2layQ+4WH/HgIPHasisnmo3E/euVWmhtTaiT/
g5bOLwyFQ2/RvdMlMxXlKUcuMfNwRA==
=Hhzj
-----END PGP SIGNATURE-----
Merge tag 'u-boot-stm32-20220620' of https://source.denx.de/u-boot/custodians/u-boot-stm into next
- Add STM32MP13 SoCs support with associated board STM32M135F-DK
- Correct livetree support in stm32mp1 boards
- Activate livetree for stm32mp15 DHSOM boards
