| Commit message (Collapse) | Author | Age | Lines |
|
|
|
|
|
| |
Move this option to Kconfig and tidy up existing uses.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
|
|
|
|
| |
Move this option to Kconfig and tidy up existing uses.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
|
|
|
|
|
| |
A few boards define this in a header file which is incorrect. It means that
Kconfig options that rely on this cannot be used. Move it.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
A few boards define this in a header file which is incorrect. It means that
Kconfig options that rely on this cannot be used. Move it.
Note that quite a few boards defined this options but do not appear to
actually use SPL:
BSC9132QDS_NOR_DDRCLK100_SECURE
BSC9132QDS_NOR_DDRCLK133_SECURE
BSC9132QDS_SDCARD_DDRCLK100_SECURE
BSC9132QDS_SDCARD_DDRCLK133_SECURE
BSC9132QDS_SPIFLASH_DDRCLK100_SECURE
BSC9132QDS_SPIFLASH_DDRCLK133_SECURE
C29XPCIE_NOR_SECBOOT
P1010RDB-PA_36BIT_NAND_SECBOOT
P1010RDB-PA_36BIT_SPIFLASH_SECBOOT
P1010RDB-PA_NAND_SECBOOT
P1010RDB-PA_NOR_SECBOOT
P1010RDB-PB_36BIT_NOR_SECBOOT
P1010RDB-PB_36BIT_SPIFLASH_SECBOOT
P1010RDB-PB_NAND_SECBOOT
P1010RDB-PB_NOR_SECBOOT
P3041DS_SECURE_BOOT
P4080DS_SECURE_BOOT
P5020DS_NAND_SECURE_BOOT
P5040DS_SECURE_BOOT
T1023RDB_SECURE_BOOT
T1024QDS_DDR4_SECURE_BOOT
T1024QDS_SECURE_BOOT
T1024RDB_SECURE_BOOT
T1040RDB_SECURE_BOOT
T1042D4RDB_SECURE_BOOT
T1042RDB_SECURE_BOOT
T2080QDS_SECURE_BOOT
T2080RDB_SECURE_BOOT
T4160QDS_SECURE_BOOT
T4240QDS_SECURE_BOOT
ls1021aqds_nor_SECURE_BOOT
ls1021atwr_nor_SECURE_BOOT
ls1043ardb_SECURE_BOOT
For these boards CONFIG_SPL_DM will no-longer be defined in SPL. But since
they apparently don't have an SPL, this should not matter.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
| |
The secure boot header files incorrectly define SPL options only if
CONFIG_SPL_BUILD is defined. This means that the options are only enabled
in an SPL build, and not with a normal 'make xxx_defconfig'. This means
that moveconfig.py cannot work, since it sees the options as disabled even
when they may be manually enabled in an SPL build.
Fix this by changing the order.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
|
|
|
|
|
|
| |
Update erratum workaround for A006379 to set register CPCHDBCR0
with value 0x001e0000, replacing the old value 0x003c0000.
Signed-off-by: York Sun <york.sun@nxp.com>
Reported-by: Dave Liu <dave.liu@nxp.com>
|
|
|
|
|
|
|
|
|
|
|
| |
Add support for reading bootscript and bootscript header from SD. Also
renamed macros *_FLASH to *_DEVICE to represent SD alongwith NAND and
NOR flash.
Reviewed-by: Aneesh Bansal <aneesh.bansal@nxp.com>
Signed-off-by: Sumit Garg <sumit.garg@nxp.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: York Sun <york.sun@nxp.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
For mpc85xx SoCs, the core begins execution from address 0xFFFFFFFC.
In non-secure boot scenario from NAND, this address will map to CPC
configured as SRAM. But in case of secure boot, this default address
always maps to IBR (Internal Boot ROM).
The IBR code requires that the bootloader(U-boot) must lie in 0 to 3.5G
address space i.e. 0x0 - 0xDFFFFFFF.
For secure boot target from NAND, the text base for SPL is kept same as
non-secure boot target i.e. 0xFFFx_xxxx but the SPL U-boot binary will
be copied to CPC configured as SRAM with address in 0-3.5G(0xBFFC_0000)
As a the virtual and physical address of CPC would be different. The
virtual address 0xFFFx_xxxx needs to be mapped to physical address
0xBFFx_xxxx.
Create a new PBI file to configure CPC as SRAM with address 0xBFFC0000
and update DCFG SCRTACH1 register with location of Header required for
secure boot.
The changes are similar to
commit 467a40dfe35f48d830f01a72617207d03ca85b4d
powerpc/mpc85xx: SECURE BOOT- NAND secure boot target for P3041
While P3041 has a 1MB CPC and does not require SPL. On T104x, CPC
is only 256K and thus SPL framework is used.
The changes are only applicable for SPL U-Boot running out of CPC SRAM
and not the next level U-Boot loaded on DDR.
Reviewed-by: Ruchika Gupta <ruchika.gupta@nxp.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Aneesh Bansal <aneesh.bansal@nxp.com>
Signed-off-by: Sumit Garg <sumit.garg@nxp.com>
Reviewed-by: York Sun <york.sun@nxp.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
As part of Chain of Trust for Secure boot, the SPL U-Boot will validate
the next level U-boot image. Add a new function spl_validate_uboot to
perform the validation.
Enable hardware crypto operations in SPL using SEC block.
In case of Secure Boot, PAMU is not bypassed. For allowing SEC block
access to CPC configured as SRAM, configure PAMU.
Reviewed-by: Ruchika Gupta <ruchika.gupta@nxp.com>
Signed-off-by: Aneesh Bansal <aneesh.bansal@nxp.com>
Signed-off-by: Sumit Garg <sumit.garg@nxp.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: York Sun <york.sun@nxp.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fix a number of typos, including:
* "compatble" -> "compatible"
* "eanbeld" -> "enabled"
* "envrionment" -> "environment"
* "FTD" -> "FDT" (for "flattened device tree")
* "ommitted" -> "omitted"
* "overriden" -> "overridden"
* "partiton" -> "partition"
* "propogate" -> "propagate"
* "resourse" -> "resource"
* "rest in piece" -> "rest in peace"
* "suport" -> "support"
* "varible" -> "variable"
Signed-off-by: Robert P. J. Day <rpjday@crashcourse.ca>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Define a platform data structure for the MPC85XX GPIO driver to allow
use of the driver without device tree. Users should define the GPIO
blocks for their platform like this:
struct mpc85xx_gpio_plat gpio_blocks[] = {
{
.addr = 0x130000,
.ngpios = 32,
},
{
.addr = 0x131000,
.ngpios = 32,
},
};
U_BOOT_DEVICES(my_platform_gpios) = {
{ "gpio_mpc85xx", &gpio_blocks[0] },
{ "gpio_mpc85xx", &gpio_blocks[1] },
};
This is intended to build upon the recent submission of the base
MPC85XX driver from Mario Six. We need to use that new driver
without dts support and this patch gives us that flexibility.
This has been tested on a Freescale T2080 CPU, although only the first
GPIO block.
Signed-off-by: Hamish Martin <hamish.martin@alliedtelesis.co.nz>
Reviewed-by: Mario Six <mario.six@gdsys.cc>
Tested-by: Mario Six <mario.six@gdsys.cc>
Acked-by: Simon Glass <sjg@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch adds a driver for the built-in GPIO controller of the MPC85XX
SoC (probably supporting other PowerQUICC III SoCs as well).
Each GPIO bank is identified by its own entry in the device tree, i.e.
gpio-controller@fc00 {
#gpio-cells = <2>;
compatible = "fsl,pq3-gpio";
reg = <0xfc00 0x100>
}
By default, each bank is assumed to have 32 GPIOs, but the ngpios
setting is honored, so the number of GPIOs for each bank in configurable
to match the actual GPIO count of the SoC (e.g. the 32/32/23 banks of
the P1022 SoC).
The usual functions of GPIO drivers (setting input/output mode and output
value setting) are supported.
The driver has been tested on MPC85XX, but it is likely that other
PowerQUICC III devices will work as well.
Signed-off-by: Mario Six <mario.six@gdsys.cc>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: York Sun <york.sun@nxp.com>
|
|
|
|
|
|
| |
Since generic board init is enabled, this is not used. Drop it.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|\ |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Some SOCs, specifically the ones in the C29x familiy can have
multiple security engines. This patch adds a system configuration
define which indicates the maximum number of SEC engines that
can be found on a SoC.
Signed-off-by: Alex Porosanu <alexandru.porosanu@nxp.com>
Reviewed-by: York Sun <york.sun@nxp.com>
|
| |
| |
| |
| | |
Signed-off-by: Mario Six <mario.six@gdsys.cc>
|
|/
|
|
| |
Signed-off-by: Mario Six <mario.six@gdsys.cc>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There are already two FIT options in Kconfig but the CONFIG options are
still in the header files. We need to do a proper move to fix this.
Move these options to Kconfig and tidy up board configuration:
CONFIG_FIT
CONFIG_OF_BOARD_SETUP
CONFIG_OF_SYSTEM_SETUP
CONFIG_FIT_SIGNATURE
CONFIG_FIT_BEST_MATCH
CONFIG_FIT_VERBOSE
CONFIG_OF_STDOUT_VIA_ALIAS
CONFIG_RSA
Unfortunately the first one is a little complicated. We need to make sure
this option is not enabled in SPL by this change. Also this option is
enabled automatically in the host builds by defining CONFIG_FIT in the
image.h file. To solve this, add a new IMAGE_USE_FIT #define which can
be used in files that are built on the host but must also build for U-Boot
and SPL.
Note: Masahiro's moveconfig.py script is amazing.
Signed-off-by: Simon Glass <sjg@chromium.org>
[trini: Add microblaze change, various configs/ re-applies]
Signed-off-by: Tom Rini <trini@konsulko.com>
|
|
|
|
|
|
|
|
|
| |
Kconfig options must defined in the defconfig files. Since RSA_SOFTWARE_EXP
relies on CONFIG_DM, unless it is set in kconfig we cannot enable RSA.
Remove the hacks which enable CONFIG_DM in header files and update the
defconfig.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
PAMU driver basic support for usage in Secure Boot.
In secure boot PAMU is not in bypass mode. Hence to use
any peripheral (SEC Job ring in our case), PAMU has to be
configured.
The patch reverts commit 7cad2e38d61e27ea59fb7944f7e647e97ef292d3.
The Header file pamu.h and few functions in driver have been derived
from Freescale Libos.
Signed-off-by: Ruchika Gupta <ruchika.gupta@nxp.com>
Signed-off-by: Aneesh Bansal <aneesh.bansal@nxp.com>
Reviewed-by: York Sun <york.sun@nxp.com>
|
|\ |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Chain of Trust is enabled for PowerPC platforms for Secure Boot.
CONFIG_BOARD_LATE_INIT is defined.
In board_late_init(), fsl_setenv_chain_of_trust() is called which
will perform the following:
- If boot mode is non-secure, return (No Change)
- If boot mode is secure, set the following environmet variables:
bootdelay = 0 (To disable Boot Prompt)
bootcmd = CONFIG_CHAIN_BOOT_CMD (Validate and execute Boot script)
Signed-off-by: Aneesh Bansal <aneesh.bansal@nxp.com>
Acked-by: Ruchika Gupta <ruchika.gupta@nxp.com>
Reviewed-by: York Sun <york.sun@nxp.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
A function is created to detrmine if the boot mode is secure
or non-secure for differnt SoC's.
Signed-off-by: Aneesh Bansal <aneesh.bansal@nxp.com>
Acked-by: Ruchika Gupta <ruchika.gupta@nxp.com>
Reviewed-by: York Sun <york.sun@nxp.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
There are two phases in Secure Boot
1. ISBC: In BootROM, validate the BootLoader (U-Boot).
2. ESBC: In U-Boot, continuing the Chain of Trust by
validating and booting LINUX.
For ESBC phase, there is no difference in SoC's based on ARM or
PowerPC cores.
But the exit conditions after ISBC phase i.e. entry conditions for
U-Boot are different for ARM and PowerPC.
PowerPC:
If Secure Boot is executed, a separate U-Boot target is required
which must be compiled with a diffrent Text Base as compared to
Non-Secure Boot. There are some LAW and TLB settings which are
required specifically for Secure Boot scenario.
ARM:
ARM based SoC's have a fixed memory map and exit conditions from
BootROM are same irrespective of boot mode (Secure or Non-Secure).
Thus the current Secure Boot functionlity has been split into
two parts:
CONFIG_CHAIN_OF_TRUST
This will have the following functionality as part of U-Boot:
1. Enable commands like esbc_validate, esbc_halt
2. Change the environment settings based on bootmode, determined
at run time:
- If bootmode is non-secure, no change
- If bootmode is secure, set the following:
- bootdelay = 0 (Don't give boot prompt)
- bootcmd = Validate and execute the bootscript.
CONFIG_SECURE_BOOT
This is defined only for creating a different compile time target
for secure boot.
Traditionally, both these functionalities were defined under
CONFIG_SECURE_BOOT. This patch is aimed at removing the requirement
for a separate Secure Boot target for ARM based SoC's.
CONFIG_CHAIN_OF_TRUST will be defined and boot mode will be
determine at run time.
Another Security Requirement for running CHAIN_OF_TRUST is that
U-Boot environemnt must not be picked from flash/external memory.
This cannot be done based on bootmode at run time in current U-Boot
architecture. Once this dependency is resolved, no separate
SECURE_BOOT target will be required for ARM based SoC's.
Currently, the only code under CONFIG_SECURE_BOOT for ARM SoC's is
defining CONFIG_ENV_IS_NOWHERE
Signed-off-by: Aneesh Bansal <aneesh.bansal@nxp.com>
Acked-by: Ruchika Gupta <ruchika.gupta@nxp.com>
Reviewed-by: York Sun <york.sun@nxp.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
CONFIG_CMD_BLOB must be defined in case of Secure Boot. It was
earlier defined in all config files. The definition has been
moved to a common file which is included by all configs.
Signed-off-by: Aneesh Bansal <aneesh.bansal@nxp.com>
Acked-by: Ruchika Gupta <ruchika.gupta@nxp.com>
Reviewed-by: York Sun <york.sun@nxp.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Erratum A-009663 workaround requires to set DDR_INTERVAL[BSTOPRE] to 0
before setting DDR_SDRAM_CFG[MEM_EN] and set DDR_INTERVAL[BSTOPRE]
to the desired value after DDR initialization has completed.
When DDR controller is configured to operate in auto-precharge
mode(DDR_INTERVAL[BSTOPRE]=0), this workaround is not needed.
Signed-off-by: Shengzhou Liu <Shengzhou.Liu@freescale.com>
Reviewed-by: York Sun <york.sun@nxp.com>
|
|/
|
|
|
|
|
|
|
|
|
| |
The old mail address will stop working soon.
Update it all the files
Signed-off-by: Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Reviewed-by: Michal Simek <michal.simek@xilinx.com>
|
|
|
|
|
|
|
|
|
| |
In a number of places we had wordings of the GPL (or LGPL in a few
cases) license text that were split in such a way that it wasn't caught
previously. Convert all of these to the correct SPDX-License-Identifier
tag.
Signed-off-by: Tom Rini <trini@konsulko.com>
|
|
|
|
|
|
|
|
|
| |
DDR errata-A008378 applies to LS1021-20-22A-R1.0, T1023-R1.0,
T1024-R1.0, T1040-42-20-22-R1.0/R1.1, it has been fixed on
LS102x Rev2.
Signed-off-by: Shengzhou Liu <Shengzhou.Liu@freescale.com>
Reviewed-by: York Sun <yorksun@freescale.com>
|
|
|
|
|
|
|
|
|
| |
move arch/powerpc/include/asm/fsl_errata.h to include/fsl_errata.h
to make it public for both ARM and POWER SoCs.
Signed-off-by: Shengzhou Liu <Shengzhou.Liu@freescale.com>
[York Sun: fix soc.h path in fsl_errata.h]
Reviewed-by: York Sun <yorksun@freescale.com>
|
|
|
|
|
|
|
|
|
| |
Unify serial_ppc, and use the generic binding.
Signed-off-by: Thomas Chou <thomas@wytron.com.tw>
Reviewed-by: Tom Rini <trini@konsulko.com>
[trini: Add TODO comment]
Signed-off-by: Tom Rini <trini@konsulko.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
A number of headers define functions as "extern inline" which is
causing problems with gcc5. The reason is that starting with
version 5.1, gcc defaults to the standard C99 semantics for the
inline keyword.
Under the traditional GNU inline semantics, an "extern inline"
function would never create an external definition, the same
as inline *without* extern in C99. In C99, and "extern inline"
definition is simply an external definition with an inline hint.
In short, the meanings of inline with and without extern are
swapped between GNU and C99.
The upshot is that all these definitions in header files create
an external definition wherever those headers are included,
resulting in multiple definition errors at link time.
Changing all these functions to "static inline" fixes the problem
since this works as desired in all gcc versions. Although the
semantics are slightly different (a static inline definition may
result in an actual function being emitted), it works as intended
in practice.
This patch also removes extern prototype declarations for the
changed functions where they existed.
Signed-off-by: Mans Rullgard <mans@mansr.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Remove __ilog2_u64 and ffs4 from powerpc bitops to align with the
kernel implementation.
Use the generic __ffs64 instead of a custom powerpc implementation.
Cc: York Sun <yorksun@freescale.com>
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Heiko Schocher <hs@denx.de>
Reviewed-by: Jagan Teki <jteki@openedev.com>
|
|
|
|
|
|
|
|
|
| |
qe-tdm is muxed with diu, if hwconfig setted as qe-tdm,
assign muxed pins to qe-tdm, then delete diu node from
device tree.
Signed-off-by: Zhao Qiang <qiang.zhao@freescale.com>
Reviewed-by: York Sun <yorksun@freescale.com>
|
|
|
|
|
|
|
|
|
|
| |
The fsl_dtsec.h & fsl_tgec.h & fsl_fman.h can be shared on both ARM
and PPC, move it out of ppc to include/, and change the path in
drivers accordingly.
Signed-off-by: Shaohui Xie <Shaohui.Xie@freescale.com>
Signed-off-by: Gong Qianyu <Qianyu.Gong@freescale.com>
Reviewed-by: York Sun <yorksun@freescale.com>
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit 8fe11b8901a31d11990488c82bc23612589d57be.
I'll add support to lwmon5 in the next patch and will remove
support for the broken lcd4_lwmon5 as well.
Signed-off-by: Stefan Roese <sr@denx.de>
Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
|
|
|
|
|
|
|
|
|
|
|
| |
This has not been converted to Generic Board, so should be removed.
(See doc/README.generic-board for details.)
Remove CONFIG_LWMON5 references.
(Also, remove undefined CONFIG_WD_MAX_RATE while I am here.)
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Cc: Stefan Roese <sr@denx.de>
|
|\ |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Recently the FMan Port and MAC compatibles were changed.
This patch aligns the FMan Port and MAC compatibles
to the new FMan device tree binding document.
The FMan device tree binding document can be found in the Linux kernel:
./Documentation/devicetree/bindings/powerpc/fsl/fman.txt
This patch doesn't affect legacy compatibles support.
Signed-off-by: Igal Liberman <igal.liberman@freescale.com>
Tested-by: Xing Lei <xing.lei@freescale.com>
Reviewed-by: York Sun <yorksun@freescale.com>
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
| |
ISBC Key Extension feature is not applicable for RAMBOOT
as there is no way to retrieve the CSF Header and validated
IE Key table from SRAM once CPC has been disabled.
The feature is only applicable in case of NOR SECURE BOOT.
Code Cleanup:
The SECURE_BOOT specific defines have been moved from
arch-ls102xa/config.h to
arm/include/asm/fsl_secure_boot.h
Signed-off-by: Aneesh Bansal <aneesh.bansal@freescale.com>
Reviewed-by: York Sun <yorksun@freescale.com>
|
|
|
|
|
|
|
|
|
| |
gpio.h - Added missing copyright in few files.
rsa-mod-exp.h - Corrected copyright in the file.
fsl_sec.h - Added missing license in files
drivers/crypto/fsl/Makefile - Removed the incomplete GPLv2 license and replaced it with GPLv2+ license
Signed-off-by: Ruchika Gupta <ruchika.gupta@freescale.com>
|
|
|
|
|
|
|
|
|
|
|
|
| |
For running Chain of Trust when doing Secure Boot from NAND,
the Bootscript header and bootscript must be copied from NAND
to RAM(DDR).
The addresses and commands for the same have been defined.
Signed-off-by: Saksham Jain <saksham@freescale.com>
Signed-off-by: Ruchika Gupta <ruchika.gupta@freescale.com>
Signed-off-by: Aneesh Bansal <aneesh.bansal@freescale.com>
Reviewed-by: York Sun <yorksun@freescale.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Secure Boot Target is added for NAND for P3041.
For mpc85xx SoCs, the core begins execution from address 0xFFFFFFFC.
In case of secure boot, this default address maps to Boot ROM.
The Boot ROM code requires that the bootloader(U-boot) must lie
in 0 to 3.5G address space i.e. 0x0 - 0xDFFFFFFF.
In case of NAND Secure Boot, CONFIG_SYS_RAMBOOT is enabled and CPC is
configured as SRAM. U-Boot binary will be located on SRAM configured
at address 0xBFF00000.
In the U-Boot code, TLB entries are created to map the virtual address
0xFFF00000 to physical address 0xBFF00000 of CPC configured as SRAM.
Signed-off-by: Saksham Jain <saksham@freescale.com>
Signed-off-by: Ruchika Gupta <ruchika.gupta@freescale.com>
Signed-off-by: Aneesh Bansal <aneesh.bansal@freescale.com>
Reviewed-by: York Sun <yorksun@freescale.com>
|
|
|
|
|
|
|
|
| |
Correct the value CONFIG_USB_MAX_CONTROLLER_COUNT macro to 1
for p1025 as it has one USB controller
Signed-off-by: Nikhil Badola <nikhil.badola@freescale.com>
Reviewed-by: York Sun <yorksun@freescale.com>
|
|
|
|
|
|
|
|
|
|
|
|
| |
MAC1 acts as 1G/10G dual-role MAC on T1024. We introduce
macro SET_FMAN_RX_10G_TYPE2_LIODN for 10G MACs which have
same Port ID and same offset of address with 1G MAC.
Update it to match with the setting of fman in t1024 device
tree, otherwise there is no 'fsl,liodn' in
/proc/device-tree/soc@ffe000000/fman@400000/port@88000/
Signed-off-by: Shengzhou Liu <Shengzhou.Liu@freescale.com>
Reviewed-by: York Sun <yorksun@freescale.com>
|
|
|
|
|
|
|
|
| |
defconfig files are added and SFP version for these platforms
is updated.
Signed-off-by: Gaurav Rana <gaurav.rana@freescale.com>
Reviewed-by: York Sun <yorksun@freescale.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
To replicate:
1. add to include/configs/p1_p2_rdb_pc.h "#define CONFIG_CMD_GPIO"
2. run `make P1020RDB-PC_defconfig`
3. run CROSS_COMPILE=powerpc-linux- make
and you will get:
common/built-in.o: In function `do_gpio':
u-boot/common/cmd_gpio.c:186: undefined reference to `gpio_request'
u-boot/common/cmd_gpio.c:194: undefined reference to `gpio_direction_input'
u-boot/common/cmd_gpio.c:195: undefined reference to `gpio_get_value'
u-boot/common/cmd_gpio.c:200: undefined reference to `gpio_get_value'
u-boot/common/cmd_gpio.c:203: undefined reference to `gpio_direction_output'
u-boot/common/cmd_gpio.c:209: undefined reference to `gpio_free
Signed-off-by: Michael Durrant <mdurrant@arcturusnetworks.com>
Signed-off-by: Oleksandr G Zhadan <oleks@arcturusnetworks.com>
Reviewed-by: York Sun <yorksun@freescale.com>
|
|
|
|
|
|
|
|
|
|
|
|
| |
The SD clock could be generated by platform clock or peripheral
clock for some platforms. This patch adds peripheral clock
support for T1024/T1040/T2080. To enable it, define
CONFIG_FSL_ESDHC_USE_PERIPHERAL_CLK.
Signed-off-by: Yangbo Lu <yangbo.lu@freescale.com>
Cc: York Sun <yorksun@freescale.com>
Cc: Pantelis Antoniou <panto@antoniou-consulting.com>
Reviewed-by: York Sun <yorksun@freescale.com>
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add adapter card type identification support by reading
FPGA STAT_PRES1 register SDHC Card ID[0:2] bits. To use this function,
define CONFIG_FSL_ESDHC_ADAPTER_IDENT.
Signed-off-by: Yangbo Lu <yangbo.lu@freescale.com>
Cc: York Sun <yorksun@freescale.com>
Cc: Pantelis Antoniou <panto@antoniou-consulting.com>
[York Sun: resolve conflicts in README.fsl-esdhc]
Reviewed-by: York Sun <yorksun@freescale.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Freescale PCIe controllers v3.0 and later need to set bit
CFG_READY to allow all inbound configuration transactions
to be processed normally when in EP mode. However, bit
CFG_READY has been moved from PCIe configuration space to
CCSR PCIe configuration register comparing previous version.
The patch is to set this bit according to PCIe version.
Signed-off-by: Ed Swarthout <Ed.Swarthout@freescale.com>
Signed-off-by: Roy Zang <tie-fei.zang@freescale.com>
Signed-off-by: Minghuan Lian <Minghuan.Lian@freescale.com>
Reviewed-by: York Sun <yorksun@freescale.com>
|