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

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>

show more ...

printk: collect printk stuff into <linux/printk.h> with loglevel support

When we import code from Linux, with regular re-sync planned, we want
to use printk() and pr_*(). U-Boot does not support th

printk: collect printk stuff into <linux/printk.h> with loglevel support

When we import code from Linux, with regular re-sync planned, we want
to use printk() and pr_*(). U-Boot does not support them in a clean
way. So, people end up with local macros, or compat headers here and
there, then we occasionally see build errors of definition conflicts.

We have include/linux/compat.h, but putting all sorts of unrelated
things into a single header is just a temporal workaround. Hence this
patch, to find the best home for all printk variants. If you want to
use printk() and friends, please include <linux/printk.h>. This header
is self-contained, and pulls in only a few headers.

When I was testing this clean-up, I noticed the image size exceeded
its platform limit on some boards. This is because all pr_*() that
were previously defined as no-op in include/linux/mtd/mtd.h (unless
CONFIG_MTD_DEBUG is set), are now enabled.

To make such boards happy, this commit also implements CONFIG_LOGLEVEL.
The concept is similar to the kernel parameter "loglevel". (Actually,
the Kconfig help message was taken from kernel-paremeter.txt of Linux)
Messages with a loglevel smaller than console loglevel will be printed.

The difference is the loglevel is build-time determined. To save the
image size, lower priority pr_*() are compiled out. I set the default
of CONFIG_LOGLEVEL to 6, i.e. pr_notice and higher priority messages
are compiled in.

I adjusted CONFIG_LOGLEVEL to avoid build error for some boards.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
[trini: Add in SPL_LOGLEVEL that is the same as LOGLEVEL]
Signed-off-by: Tom Rini <trini@konsulko.com>

show more ...

Merge git://git.denx.de/u-boot-uniphier

- Fix unmet direct dependencies warning
- Remove old sLD3 SoC support
- Update reset data
- Add dr_mode DT property to avoid warning

ARM: uniphier: remove sLD3 SoC support

This SoC is too old. It is difficult to maintain any longer.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>

Merge git://git.denx.de/u-boot-uniphier

ARM: uniphier: remove SPL support for ARMv8 SoCs

It has been a while since ARM Trusted Firmware supported UniPhier SoC
family. U-Boot SPL was intended as a temporary loader that runs in
secure worl

ARM: uniphier: remove SPL support for ARMv8 SoCs

It has been a while since ARM Trusted Firmware supported UniPhier SoC
family. U-Boot SPL was intended as a temporary loader that runs in
secure world. It is a maintenance headache to support two different
boot mechanisms. Secure firmware is realm of ARM Trusted Firmware
and now U-Boot only serves as a non-secure boot loader for UniPhier
ARMv8 SoCs.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>

show more ...

Merge git://git.denx.de/u-boot-uniphier

- fix sparse warnings
- sync DT with Linux
- add new board support (LD11/LD20 global)

ARM: uniphier: fix various sparse warnings

Fix warnings reported by sparse:
- ... was not declared. Should it be static?"
- cast to restricted __be32

While fixing those, the type conflict of cci5

ARM: uniphier: fix various sparse warnings

Fix warnings reported by sparse:
- ... was not declared. Should it be static?"
- cast to restricted __be32

While fixing those, the type conflict of cci500_init() was found.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>

show more ...

Merge git://git.denx.de/u-boot-uniphier

- Add workaround code to make LD20 SoC boot from ARM Trusted Firmware
- Sync DT with Linux to fix DTC warnings
- Add new SoC support code
- Misc fix, updates

ARM: uniphier: add more init code for PXs3

Add the boot device table and reset deassertion for eMMC.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>

Merge branch 'master' of git://git.denx.de/u-boot

Signed-off-by: Stefano Babic <sbabic@denx.de>

Merge branch 'master' of git://git.denx.de/u-boot-uniphier

ARM: uniphier: show STM (SCP) status on boot and pinmon command

The SCP (System Control Processor) or what we call STM (Stand-by
MPU) is integrated in LD4, Pro4, sLD8, LD6b, LD11, and LD20.
For thes

ARM: uniphier: show STM (SCP) status on boot and pinmon command

The SCP (System Control Processor) or what we call STM (Stand-by
MPU) is integrated in LD4, Pro4, sLD8, LD6b, LD11, and LD20.
For these SoCs, show the information if STM is enabled.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>

show more ...

Merge branch 'master' of git://git.denx.de/u-boot-uniphier

- Fix regressions caused by the previous reworks
- Add pin configuration support
- Re-work SPL code
- Update DRAM and PLL setup cod

Merge branch 'master' of git://git.denx.de/u-boot-uniphier

- Fix regressions caused by the previous reworks
- Add pin configuration support
- Re-work SPL code
- Update DRAM and PLL setup code
- Enable needed configs, disable unneeded configs

show more ...

ARM: uniphier: deassert RST_n of eMMC device for LD11/LD20

For LD11 and LD20 SoCs, the RST_n pin is asserted by default. If
the EXT_CSD[162], bit[1:0] (RST_n_ENABLE) is fused, the eMMC device
would

ARM: uniphier: deassert RST_n of eMMC device for LD11/LD20

For LD11 and LD20 SoCs, the RST_n pin is asserted by default. If
the EXT_CSD[162], bit[1:0] (RST_n_ENABLE) is fused, the eMMC device
would stay in the reset state until its RST_n pin is deasserted by
software.

Currently, this is cared by an ad-hoc way because the eMMC hardware
reset provider is not supported in U-Boot for now. This code should
be re-written once the "mmc-pwrseq-emmc" binding is supported.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>

show more ...

ARM: uniphier: remove dram_nr_ch from board parameters

This parameter is redundant because we can know the number of
channels by checking if dram_ch[2].size is zero.

Signed-off-by: Masahiro Yamada

ARM: uniphier: remove dram_nr_ch from board parameters

This parameter is redundant because we can know the number of
channels by checking if dram_ch[2].size is zero.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>

show more ...

ARM: uniphier: rework spl_boot_device() and related code

The current implementation has ugly switch statements here and there,
and duplicates similar code. Rework it using table lookups for SoC
dat

ARM: uniphier: rework spl_boot_device() and related code

The current implementation has ugly switch statements here and there,
and duplicates similar code. Rework it using table lookups for SoC
data and reduce code duplication.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>

show more ...

ARM: uniphier: remove DRAM base address from board parameters

The base address of each DRAM channel can be calculated from other
parameters, so does not need hard-coding. What we need is the size
o

ARM: uniphier: remove DRAM base address from board parameters

The base address of each DRAM channel can be calculated from other
parameters, so does not need hard-coding. What we need is the size
of each DRAM channel and DRAM_SPARSE flag to decide the start address
of DRAM channel 1.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>

show more ...

Merge branch 'master' of git://git.denx.de/u-boot-uniphier

- Fix clk driver
- Optimize DRAM init code for LD20 SoC
- Get DRAM information from more reliable source
- Clean up SoC init code

Merge branch 'master' of git://git.denx.de/u-boot-uniphier

- Fix clk driver
- Optimize DRAM init code for LD20 SoC
- Get DRAM information from more reliable source
- Clean up SoC init code
- Allow to use Image.gz for booting ARM64 Linux
- Tidy up environments to use with ATF
- Clean up I2C drivers

show more ...

ARM: uniphier: detect RAM size by decoding HW register instead of DT

U-Boot needs to set up available memory area(s) in dram_init() and
dram_init_banksize(). It is platform-dependent how to detect

ARM: uniphier: detect RAM size by decoding HW register instead of DT

U-Boot needs to set up available memory area(s) in dram_init() and
dram_init_banksize(). It is platform-dependent how to detect the
memory banks. Currently, UniPhier adopts the memory banks _alleged_
by DT. This is based on the assumption that users bind a correct DT
in their build process.

Come to think of it, the DRAM controller has already been set up
before U-Boot is entered (because U-Boot runs on DRAM). So, the
DRAM controller setup register seems a more reliable source of any
information about DRAM stuff. The DRAM banks are initialized by
preliminary firmware (SPL, ARM Trusted Firmware BL2, or whatever),
so this means the source of the reliability is shifted from Device
Tree to such early-stage firmware. However, if the DRAM controller
is wrongly configured, the system will crash. If your system is
running, the DRAM setup register is very likely to provide the
correct DRAM mapping.

Decode the SG_MEMCONF register to get the available DRAM banks.
The dram_init() and dram_init_banksize() need similar decoding.
It would be nice if dram_init_banksize() could reuse the outcome
of dram_init(), but global variables are unavailable at this stage
because the .bss section is available only after the relocation.
As a result, SG_MEMCONF must be checked twice, but a new helper
uniphier_memconf_decode() will help to avoid code duplication.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>

show more ...

Merge branch 'master' of git://git.denx.de/u-boot-uniphier

- Allow to disable SPL (mainly for ATF)
- Refactor SoC init code
- Update DRAM settings
- Add PXs3 SoC support (DT, pinctrl driver,

Merge branch 'master' of git://git.denx.de/u-boot-uniphier

- Allow to disable SPL (mainly for ATF)
- Refactor SoC init code
- Update DRAM settings
- Add PXs3 SoC support (DT, pinctrl driver, SoC code)

show more ...

ARM: uniphier: add PXs3 SoC support

Initial support for PXs3 SoC.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>

Merge branch 'master' of git://git.denx.de/u-boot-uniphier

- Enable eMMC driver for LD11/LD20 SoCs
- Refactoring of SoC init code
- Bug fix of pinctrl driver

ARM: uniphier: refactor spl_init_board()

Merge init-*.c into a single file using a table of callbacks because
the initialization flow is almost common among SoCs.

Signed-off-by: Masahiro Yamada <ya

ARM: uniphier: refactor spl_init_board()

Merge init-*.c into a single file using a table of callbacks because
the initialization flow is almost common among SoCs.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>

show more ...

ARM: uniphier: refactor board_init()

The code here is cluttered due to the switch statement. Introduce a
table of callbacks to clean up the initialization code across SoCs.

Signed-off-by: Masahiro

ARM: uniphier: refactor board_init()

The code here is cluttered due to the switch statement. Introduce a
table of callbacks to clean up the initialization code across SoCs.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>

show more ...