| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
| |
Currently arch specific headers can be included with
longer possible as there won't be a single mach anymore.
Move all stm32mp specific header files to include/mach/stm32mp/ to
prepare for multi-arch support.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The barebox stack is always located at a fixed offset from the end of
SDRAM. To determine end of SDRAM, barebox may need a stack setup, so
at that early time, either stack pointer set up by BootROM is reused
or we set up a temporary stack on some on-chip SRAM .
On STM32MP1, TF-A runs after BootROM, so barebox runs in normal world
without prepared stack and TF-A is located on on-chip SRAM.
So what we did so far was have a small stack of 64 bytes starting behind
end of barebox image to cover the first function call to determine
actual memory size. This may have been chosen that small with the thought
that an overflow would give an error message anyway, because of failed
decompression. An overflow of exactly 4 bytes overwrites just the barebox
proper image size though located at the end of the barebox image, thereby
overflowing the size and leading to out-of-bounds access during decompression
in 1 of 4 cases depending on barebox size, because we align barebox
proper size to 16 bytes...
Let's just use a fully sized stack even in the early state. That's
usually 32K and we expect a barebox loaded into DRAM to always have
that much bytes following it. Another way would've been to use
some of the other SRAMs, but I decided to leave those alone, as not
to clobber data used by the coprocessor, when reloading barebox.
Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de>
Link: https://lore.barebox.org/20230217175124.1897402-1-a.fatoum@pengutronix.de
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
BootROM boots from GPT partition fsbl1 or fsbl2 on SD-Card and from
boot partition on eMMC. Recent TF-A without legacy image support will
then look in a GPT partition named fip in the user area.
With recent patches[1], TF-A will also check offset SZ_256K in the boot
partition to see if the FIP is there.
Add a barebox_update handler that covers these scenarios.
[1]: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/15332
Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de>
Link: https://lore.barebox.org/20220602090133.3190450-7-a.fatoum@pengutronix.de
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
We have some special handling for legacy (non-FIP) STM32 images:
We have a bootm handler for chainloading and an update handler
for use with GPT ssbl partitions. Both aren't applicable to the
TF-A image used as FSBL. As barebox always has 0x00000000 at
offset 0xfc and TF-A alrways has 0x10000000, we can use that
to differentiate between the two images to make sure we refuse
TF-A images when barebox images are expected.
Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de>
Link: https://lore.barebox.org/20220602090133.3190450-6-a.fatoum@pengutronix.de
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
|
| |
|
|
|
|
|
|
|
| |
Full buswidth for STM32MP131 means 2 byte wide, not 4 as the memory bus
is restricted to 16-bit. Teach barebox the difference.
Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de>
Link: https://lore.barebox.org/20220221103625.3728055-1-a.fatoum@pengutronix.de
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
|
| |
|
|
|
|
|
|
|
| |
Record GPL-2.0-only as license for all files lacking an explicit license
statement.
Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de>
Link: https://lore.barebox.org/20220103120539.1730644-9-a.fatoum@pengutronix.de
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
|
| |\ |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This was ported from U-Boot to support st32mp_get_forced_boot_mode(),
which allows board code to customize boot according to values the kernel
places in the reboot mode region on the TAMP syscon.
We no have a syscon-reboot-mode driver, a device node in the
stm32mp151.dtsi, a ${global.system.reboot_mode} variable and a common
reboot_mode_get(), which together achieve the same, but in a generic
manner. Drop the now duplicate code. There has been no in-tree users so
far, so we don't need to touch anything else.
Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
|
| |/
|
|
|
|
|
|
|
| |
There is nothing holding holding us back from reading SoC type in
the PBL. Migrate the necessary definitions to the header to allow
for this.
Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
|
| |
|
|
|
|
|
|
|
| |
BSEC_SMC_READ_SHADOW and BSEC_SMC_WRITE_SHADOW aren't fields, but
operations to apply on fields. Rename it accordingly and fix up instances
where it was used wrongly.
Signed-off-by: Ahmad Fatoum <ahmad@a3f.at>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Revision A was 0x1000 and B was 0x2000, so I assumed the next would
be revision C valued 0x3000. Alas, it's revision Z with 0x2001...
Change the code accordingly and add detection for the new 800Mhz
profiles.
Code taken from U-Boot commit
cf0818b477 ("stm32mp1: support of STM32MP15x Rev.Z") and
Patch[1] "stm32mp1: add 800 MHz profile support".
[1]: https://st-md-mailman.stormreply.com/pipermail/uboot-stm32/2020-February/002170.html
Signed-off-by: Ahmad Fatoum <ahmad@a3f.at>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When barebox is invoked out of the TF-A v2.1, it's started with
sp, r0, r1, r2 all equal to zero. To use the new RAM size calculating
stm32mp1_barebox_entry, we need to have a stack to handle spillage.
Add a stm32mp_cpu_lowlevel_init wrapper around arm_cpu_lowlevel_init,
which additionally configures a 64 byte stack after the end of the
barebox binary. This should be enough to help us through the RAM size
calculation. If not, compression will fail because of data corruption
and stack size can be increased as necessary.
Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
The STM32MP DDR Controller has a very flexible way of mapping address
bits to columns/rows/banks. This is so far configured by the ARM TF-A
as part of the SDRAM setup, so we don't need to do this in barebox.
Nevertheless reading it out in barebox, allows us to determine unused
address bits and thus the total size of SDRAM configured.
Add a barebox_arm_entry wrapper that computes the SDRAM size internally,
so boards may drop their hard-coded RAM size specifications.
Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
|
| |
|
|
|
|
|
|
| |
Now with the SD/MMC controller supported, lets add a bbu handler, so we
can use it to update the second stage boot loader partition.
Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
The BSEC OTP holds information about SoC type and package.
The Tamp registers hold information from the BootROM about boot
source. Add support for both.
Additionally, the tamp registers can also hold a request from the
operating system about what mode to enter after boot, e.g.
boot-into-recovery. A global function is exported for this, but
unused so far.
Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
|
| |
|
|
|
|
|
|
|
| |
The bsec on the STM32MP157C provides a 380 byte OTP. Add initial support
for reading and writing the shadow copy of the fuses. Direct fuse
access is not yet supported.
Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
|
|
|
Serial and clk driver both depend on CONFIG_ARCH_STM32MP1,
so either the Kconfig symbol or their depend needs to change.
Patches posted by the vendor to Linux, U-Boot and their BSP
Yocto-Layer speak of a STM32MP-Family of which the STM32MP1
is the first series, thus rename the arch by dropping the 1.
Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
|
