u-boot.git, branch v2022.10-rc1 Unnamed repository; edit this file 'description' to name the repository. Prepare v2022.10-rc1 2022-07-26T00:31:12+00:00 Tom Rini trini@konsulko.com 2022-07-26T00:31:12+00:00 6e15cda270a060cf87c6c643a1cc3da65ffb242d Signed-off-by: Tom Rini <trini@konsulko.com> 
Signed-off-by: Tom Rini <trini@konsulko.com>
configs: Resync with savedefconfig 2022-07-25T21:19:18+00:00 Tom Rini trini@konsulko.com 2022-07-25T21:19:18+00:00 0fc5c499db1467f5bf7db5c4fee9adbc804e8982 Resync all defconfig files using moveconfig.py Signed-off-by: Tom Rini <trini@konsulko.com> 
Resync all defconfig files using moveconfig.py

Signed-off-by: Tom Rini <trini@konsulko.com>
Merge branch '2022-07-25-assorted-platform-updates' 2022-07-25T20:40:43+00:00 Tom Rini trini@konsulko.com 2022-07-25T20:40:43+00:00 af18c329730e11800792e10514b3eb33320e1abb - Assorted TI, Apple, Snapdragon and Xen updates. 
- Assorted TI, Apple, Snapdragon and Xen updates.
drivers: xen: unmap Enlighten page before jumping to Linux 2022-07-25T18:57:27+00:00 Dmytro Firsov Dmytro_Firsov@epam.com 2022-07-19T14:55:28+00:00 0001a964b840a62c66da42a89a10a2656831aa4b This commit fixes issue with usage of Xen hypervisor shared info page. Previously U-boot did not unmap it at the end of OS boot process. Xen did not prevent guest from this. So, it worked, but caused wierd issues - one memory page, that was returned by memalign in U-boot for Enlighten mapping was not unmaped by Xen (shared_info values was not removed from there) and returned to allocator. During the Linux boot, it uses shared_info page as regular RAM page, which leads to hypervisor shared info corruption. So, to fix this issue, as discussed on the xen-devel mailing list, the code should: 1) Unmap the page 2) Populate the area with memory using XENMEM_populate_physmap This patch adds page unmapping via XENMEM_remove_from_physmap, fills hole in address space where page was mapped via XENMEM_populate_physmap and return this address to memory allocator for freeing. Signed-off-by: Dmytro Firsov <dmytro_firsov@epam.com> Reviewed-by: Anastasiia Lukianenko <vicooodin@gmail.com> 
This commit fixes issue with usage of Xen hypervisor shared info page.
Previously U-boot did not unmap it at the end of OS boot process. Xen
did not prevent guest from this. So, it worked, but caused wierd
issues - one memory page, that was returned by memalign in U-boot
for Enlighten mapping was not unmaped by Xen (shared_info values was
not removed from there) and returned to allocator. During the Linux
boot, it uses shared_info page as regular RAM page, which leads to
hypervisor shared info corruption.

So, to fix this issue, as discussed on the xen-devel mailing list, the
code should:
   1) Unmap the page
   2) Populate the area with memory using XENMEM_populate_physmap

This patch adds page unmapping via XENMEM_remove_from_physmap, fills
hole in address space where page was mapped via XENMEM_populate_physmap
and return this address to memory allocator for freeing.

Signed-off-by: Dmytro Firsov <dmytro_firsov@epam.com>
Reviewed-by: Anastasiia Lukianenko <vicooodin@gmail.com>
arm: Remove unused references to CONFIG_SOC_DM* 2022-07-25T18:57:27+00:00 Tom Rini trini@konsulko.com 2022-07-18T15:33:39+00:00 032c9b045c6cf8f9acc38bd7867b6314614ebddc There are no references to CONFIG_SOC_DM355 / CONFIG_SOC_DM365 / CONFIG_SOC_DM644X / CONFIG_SOC_DM646X and the files these Makefile lines reference have already been dropped. Signed-off-by: Tom Rini <trini@konsulko.com> 
There are no references to CONFIG_SOC_DM355 / CONFIG_SOC_DM365 /
CONFIG_SOC_DM644X / CONFIG_SOC_DM646X and the files these Makefile lines
reference have already been dropped.

Signed-off-by: Tom Rini <trini@konsulko.com>
spl: Use SPL_TEXT_BASE instead of ISW_ENTRY_ADDR 2022-07-25T18:57:27+00:00 Andrew Davis afd@ti.com 2022-07-15T17:31:48+00:00 a9ec2f6509f09eacd5094eff176723d4f99a483e The ISW_ENTRY_ADDR symbol was used for OMAP devices in place of SPL_TEXT_BASE. Keystone2 HS devices were not using it right either. Remove ISW_ENTRY_ADDR and use SPL_TEXT_BASE directly. Signed-off-by: Andrew Davis <afd@ti.com> Reviewed-by: Tom Rini <trini@konsulko.com> 
The ISW_ENTRY_ADDR symbol was used for OMAP devices in place of
SPL_TEXT_BASE. Keystone2 HS devices were not using it right either.
Remove ISW_ENTRY_ADDR and use SPL_TEXT_BASE directly.

Signed-off-by: Andrew Davis <afd@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
arm: k3: config.mk: Read software revision information from file on HS 2022-07-25T18:57:27+00:00 Andrew Davis afd@ti.com 2022-07-15T16:38:54+00:00 121596a98fea008d15b052879239f2d2b0e16f6b Read the swrv.txt file from the TI Security Development Tools when TI_SECURE_DEVICE is enabled. This allows us to set our software revision in one place and have it used by all the tools that create TI x509 boot certificates. Signed-off-by: Andrew Davis <afd@ti.com> 
Read the swrv.txt file from the TI Security Development Tools when
TI_SECURE_DEVICE is enabled. This allows us to set our software
revision in one place and have it used by all the tools that create
TI x509 boot certificates.

Signed-off-by: Andrew Davis <afd@ti.com>
k3_gen_x509_cert: Make SWRV configurable for anti-rollback protection 2022-07-25T18:57:27+00:00 Yogesh Siraswar yogeshs@ti.com 2022-07-15T16:38:53+00:00 00194272519855ad26b7d5de2fd0419cf2963942 The x509 certificate SWRV is currently hard-coded to 0. This need to be updated to 1 for j721e 1.1, j7200 and am64x. It is don't care for other k3 devices. Added new config K3_X509_SWRV to k3. Default is set to 1. Signed-off-by: Yogesh Siraswar <yogeshs@ti.com> Reviewed-by: Dave Gerlach <d-gerlach@ti.com> 
The x509 certificate SWRV is currently hard-coded to 0. This need to be
updated to 1 for j721e 1.1, j7200 and am64x. It is don't care for other
k3 devices.

Added new config K3_X509_SWRV to k3. Default is set to 1.

Signed-off-by: Yogesh Siraswar <yogeshs@ti.com>
Reviewed-by: Dave Gerlach <d-gerlach@ti.com>
arm: mach-k3: Remove ROM firewalls on GP devices 2022-07-25T18:57:27+00:00 Andrew Davis afd@ti.com 2022-07-15T16:21:27+00:00 080fe39b8cede93691b1988c7b6173a9c06e8219 This isn't strictly needed as these firewalls should all be disabled on GP, but it also doesn't hurt, so do this unconditionally to remove this use of CONFIG_TI_SECURE_DEVICE. Signed-off-by: Andrew Davis <afd@ti.com> Reviewed-by: Tom Rini <trini@konsulko.com> 
This isn't strictly needed as these firewalls should all be disabled on
GP, but it also doesn't hurt, so do this unconditionally to remove this
use of CONFIG_TI_SECURE_DEVICE.

Signed-off-by: Andrew Davis <afd@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
defconfigs: j721e_hs_evm: Sync HS and non-HS defconfigs 2022-07-25T18:57:27+00:00 Andrew Davis afd@ti.com 2022-07-15T16:19:41+00:00 f673b4670de6006b068dad7c2312cadb09cf2c02 Additions have been made to the non-HS defconfig without the same being made to the HS defconfig, sync them. Signed-off-by: Andrew Davis <afd@ti.com> 
Additions have been made to the non-HS defconfig without the same
being made to the HS defconfig, sync them.

Signed-off-by: Andrew Davis <afd@ti.com>