Commit graph

21 commits

Author SHA1 Message Date
Tom Rini
65cc0e2a65 global: Move remaining CONFIG_SYS_* to CFG_SYS_*
The rest of the unmigrated CONFIG symbols in the CONFIG_SYS namespace do
not easily transition to Kconfig. In many cases they likely should come
from the device tree instead. Move these out of CONFIG namespace and in
to CFG namespace.

Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
2022-12-05 16:06:08 -05:00
Tom Rini
a322afc9f9 global: Move remaining CONFIG_*SRIO_* to CFG_*
The rest of the unmigrated CONFIG symbols in the SRIO namespace do not
easily transition to Kconfig. In many cases they likely should come from
the device tree instead. Move these out of CONFIG namespace and in to
CFG namespace.

Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
2022-12-05 16:06:08 -05:00
Tom Rini
ecc8d425fd global: Move remaining CONFIG_SYS_PCI* to CFG_SYS_PCI*
The rest of the unmigrated CONFIG symbols in the CONFIG_SYS_PCI and
CONFIG_SYS_PCIE namespace do not easily transition to Kconfig. In many
cases they likely should come from the device tree instead. Move these
out of CONFIG namespace and in to CFG namespace.

Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
2022-12-05 16:06:07 -05:00
Tom Rini
4e5909450e global: Move remaining CONFIG_SYS_NAND_* to CFG_SYS_NAND_*
The rest of the unmigrated CONFIG symbols in the CONFIG_SYS_NAND
namespace do not easily transition to Kconfig. In many cases they likely
should come from the device tree instead. Move these out of CONFIG
namespace and in to CFG namespace.

Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
2022-12-05 16:05:38 -05:00
Simon Glass
97229af027 pci: freescale: Drop old code
Drop this old pre-driver model code.

Signed-off-by: Simon Glass <sjg@chromium.org>
2021-08-05 16:14:36 -04:00
Masahiro Yamada
b75d8dc564 treewide: convert bd_t to struct bd_info by coccinelle
The Linux coding style guide (Documentation/process/coding-style.rst)
clearly says:

  It's a **mistake** to use typedef for structures and pointers.

Besides, using typedef for structures is annoying when you try to make
headers self-contained.

Let's say you have the following function declaration in a header:

  void foo(bd_t *bd);

This is not self-contained since bd_t is not defined.

To tell the compiler what 'bd_t' is, you need to include <asm/u-boot.h>

  #include <asm/u-boot.h>
  void foo(bd_t *bd);

Then, the include direcective pulls in more bloat needlessly.

If you use 'struct bd_info' instead, it is enough to put a forward
declaration as follows:

  struct bd_info;
  void foo(struct bd_info *bd);

Right, typedef'ing bd_t is a mistake.

I used coccinelle to generate this commit.

The semantic patch that makes this change is as follows:

  <smpl>
  @@
  typedef bd_t;
  @@
  -bd_t
  +struct bd_info
  </smpl>

Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2020-07-17 09:30:13 -04:00
Simon Glass
2cf431c228 common: Move pci_init_board() out of common.h
This function can be dropped when all boards use driver model for PCI. For
now, move it into init.h with a comment.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
2019-12-02 18:25:25 -05:00
Udit Agarwal
bef1845404 freescale/powerpc: Rename the config CONFIG_SECURE_BOOT name
Rename the CONFIG_SECURE_BOOT name to CONFIG_NXP_ESBC to avoid
conflicts with UEFI secure boot.

Signed-off-by: Udit Agarwal <udit.agarwal@nxp.com>
Signed-off-by: Priyanka Jain <priyanka.jain@nxp.com>
2019-11-08 16:32:08 +05:30
Hou Zhiqiang
5833a35748 powerpc: p_corenet: Compile legacy PCIe routines conditionally
Compile the legacy PCIe initialization routines for P2041RDB,
P3041, P4080, P5020 and P5040 DS boards only when DM_PCI is
 not enabled.

Signed-off-by: Hou Zhiqiang <Zhiqiang.Hou@nxp.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Prabhakar Kushwaha <prabhakar.kushwaha@nxp.com>
2019-08-28 13:47:46 +05:30
Tom Rini
83d290c56f SPDX: Convert all of our single license tags to Linux Kernel style
When U-Boot started using SPDX tags we were among the early adopters and
there weren't a lot of other examples to borrow from.  So we picked the
area of the file that usually had a full license text and replaced it
with an appropriate SPDX-License-Identifier: entry.  Since then, the
Linux Kernel has adopted SPDX tags and they place it as the very first
line in a file (except where shebangs are used, then it's second line)
and with slightly different comment styles than us.

In part due to community overlap, in part due to better tag visibility
and in part for other minor reasons, switch over to that style.

This commit changes all instances where we have a single declared
license in the tag as both the before and after are identical in tag
contents.  There's also a few places where I found we did not have a tag
and have introduced one.

Signed-off-by: Tom Rini <trini@konsulko.com>
2018-05-07 09:34:12 -04:00
Masahiro Yamada
b08c8c4870 libfdt: move headers to <linux/libfdt.h> and <linux/libfdt_env.h>
Thomas reported U-Boot failed to build host tools if libfdt-devel
package is installed because tools include libfdt headers from
/usr/include/ instead of using internal ones.

This commit moves the header code:
  include/libfdt.h         -> include/linux/libfdt.h
  include/libfdt_env.h     -> include/linux/libfdt_env.h

and replaces include directives:
  #include <libfdt.h>      -> #include <linux/libfdt.h>
  #include <libfdt_env.h>  -> #include <linux/libfdt_env.h>

Reported-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2018-03-05 10:16:28 -05:00
Aneesh Bansal
467a40dfe3 powerpc/mpc85xx: SECURE BOOT- NAND secure boot target for P3041
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>
2015-07-31 08:50:18 -07:00
Masahiro Yamada
878a095e44 Makefile: delete unnecessary CPPFLAGS settings
Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
2013-12-13 09:18:45 -05:00
Masahiro Yamada
377e1048d3 board: powerpc: convert makefiles to Kbuild style
Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
Cc: Wolfgang Denk <wd@denx.de>
Cc: Kim Phillips <kim.phillips@freescale.com>
Cc: York Sun <yorksun@freescale.com>
Cc: Stefan Roese <sr@denx.de>
2013-11-01 11:42:12 -04:00
Wolfgang Denk
1a4596601f Add GPL-2.0+ SPDX-License-Identifier to source files
Signed-off-by: Wolfgang Denk <wd@denx.de>
[trini: Fixup common/cmd_io.c]
Signed-off-by: Tom Rini <trini@ti.com>
2013-07-24 09:44:38 -04:00
Liu Gang
461632bd71 powerpc/corenet_ds: Slave module for boot from PCIE
When boot from PCIE, slave's core should be in holdoff after powered on for
some specific requirements. Master will release the slave's core at the
right time by PCIE interface.

Slave's ucode and ENV can be stored in master's memory space, then slave
can fetch them through PCIE interface. For the corenet platform, ucode is
for Fman.

NOTE: Because the slave can not erase, write master's NOR flash by
	  PCIE interface, so it can not modify the ENV parameters stored
	  in master's NOR flash using "saveenv" or other commands.

environment and requirement:

master:
	1. NOR flash for its own u-boot image, ucode and ENV space.
	2. Slave's u-boot image is in master NOR flash.
	3. Put the slave's ucode and ENV into it's own memory space.
	4. Normally boot from local NOR flash.
	5. Configure PCIE system if needed.
slave:
	1. Just has EEPROM for RCW. No flash for u-boot image, ucode and ENV.
	2. Boot location should be set to one PCIE interface by RCW.
	3. RCW should configure the SerDes, PCIE interfaces correctly.
	4. Must set all the cores in holdoff by RCW.
	5. Must be powered on before master's boot.

For the slave module, need to finish these processes:
	1. Set the boot location to one PCIE interface by RCW.
    2. Set a specific TLB entry for the boot process.
	3. Set a LAW entry with the TargetID of one PCIE for the boot.
	4. Set a specific TLB entry in order to fetch ucode and ENV from
	   master.
	5. Set a LAW entry with the TargetID one of the PCIE ports for
	   ucode and ENV.
	6. Slave's u-boot image should be generated specifically by
	   make xxxx_SRIO_PCIE_BOOT_config.
	   This will set SYS_TEXT_BASE=0xFFF80000 and other configurations.

In addition, the processes are very similar between boot from SRIO and
boot from PCIE. Some configurations like the address spaces can be set to
the same. So the module of boot from PCIE was added based on the existing
module of boot from SRIO, and the following changes were needed:
	1. Updated the README.srio-boot-corenet to add descriptions about
	   boot from PCIE, and change the name to
	   README.srio-pcie-boot-corenet.
	2. Changed the compile config "xxxx_SRIOBOOT_SLAVE" to
	   "xxxx_SRIO_PCIE_BOOT", and the image builded with
	   "xxxx_SRIO_PCIE_BOOT" can support both the boot from SRIO and
	   from PCIE.
	3. Updated other macros and documents if needed to add information
	   about boot from PCIE.

Signed-off-by: Liu Gang <Gang.Liu@freescale.com>
Signed-off-by: Andy Fleming <afleming@freescale.com>
2012-08-23 10:24:15 -05:00
Liu Gang
81fa73bab0 powerpc/corenet_ds: Get rid of the CONFIG_SRIOBOOT_SLAVE_PORTx macro
When compile the slave image for boot from SRIO, no longer need to
specify which SRIO port it will boot from. The code will get this
information from RCW and then finishes corresponding configurations.

This has the following advantages:
	1. No longer need to rebuild an image when change the SRIO port for
	   boot from SRIO, just rewrite the new RCW with selected port,
	   then the code will get the port information by reading new RCW.
	2. It will be easier to support other boot location options, for
	   example, boot from PCIE.

Signed-off-by: Liu Gang <Gang.Liu@freescale.com>
Signed-off-by: Andy Fleming <afleming@freescale.com>
2012-08-23 10:24:14 -05:00
Liu Gang
3f1af81b80 powerpc/corenet_ds: Slave uploads ucode when boot from SRIO
When boot from SRIO, slave's ucode can be stored in master's memory space,
then slave can fetch the ucode image through SRIO interface. For the
corenet platform, ucode is for Fman.

Master needs to:
	1. Put the slave's ucode image into it's own memory space.
	2. Set an inbound SRIO window covered slave's ucode stored in master's
	   memory space.
Slave needs to:
	1. Set a specific TLB entry in order to fetch ucode from master.
	2. Set a LAW entry with the TargetID SRIO1 or SRIO2 for ucode.

Signed-off-by: Liu Gang <Gang.Liu@freescale.com>
Signed-off-by: Shaohui Xie <Shaohui.Xie@freescale.com>
2012-04-24 23:58:33 -05:00
Liu Gang
292dc6c501 powerpc/corenet_ds: Slave module for boot from SRIO
For the powerpc processors with SRIO interface, boot location can be configured
from SRIO1 or SRIO2 by RCW. The processor booting from SRIO can do without flash
for u-boot image. The image can be fetched from another processor's memory
space by SRIO link connected between them.

The processor boots from SRIO is slave, the processor boots from normal flash
memory space and can help slave to boot from its memory space is master.
They are different environments and requirements:

master:
	1. NOR flash for its own u-boot image, ucode and ENV space.
	2. Slave's u-boot image in master NOR flash.
	3. Normally boot from local NOR flash.
	4. Configure SRIO switch system if needed.
slave:
	1. Just has EEPROM for RCW. No flash for u-boot image, ucode and ENV.
	2. Boot location should be set to SRIO1 or SRIO2 by RCW.
	3. RCW should configure the SerDes, SRIO interfaces correctly.
	4. Slave must be powered on after master's boot.
	5. Must define CONFIG_SYS_QE_FMAN_FW_IN_REMOTE because of no ucode
	   locally.

For the slave module, need to finish these processes:
	1. Set the boot location to SRIO1 or SRIO2 by RCW.
    2. Set a specific TLB entry for the boot process.
	3. Set a LAW entry with the TargetID SRIO1 or SRIO2 for the boot.
	4. Slave's u-boot image should be generated specifically by
	   make xxxx_SRIOBOOT_SLAVE_config.
	   This will set SYS_TEXT_BASE=0xFFF80000 and other configurations.

Signed-off-by: Liu Gang <Gang.Liu@freescale.com>
Signed-off-by: Shaohui Xie <Shaohui.Xie@freescale.com>
2012-04-24 23:58:33 -05:00
Kumar Gala
f8bc7bb5a7 powerpc/85xx: Refactor P2041RDB to use common p_corenet files
The P2041RDB has almost identical setup for TLB, LAWS, and PCI with
other P-Series CoreNet platforms.

The only difference between P2041RDB & P3041DS/P4080DS/P5020DS is the
CPLD vs PIXIS FPGA which we can handle via some simple #ifdefs in the
TLB and LAW setup tables.

Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
2011-09-29 19:01:06 -05:00
Kumar Gala
360275b362 powerpc/85xx: refactor common P-Series CoreNet files for FSL boards
We currently support 4 SoC/Boards from the P-Series of QorIQ SoCs that
are based on the 'CoreNet' Architecture: P2041RDB, P3041DS, P4080DS, and
P5020DS.  There is a significant amount of commonality shared between
these boards that we can refactor into common code:

* Initial LAW setup
* Initial TLB setup
* PCI setup

We start by moving the shared code between P3041DS, P4080DS, and P5020DS
into a common directory to be shared with other P-Series CoreNet boards.

Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
2011-09-29 19:01:06 -05:00