To achieve the complete run-time configuration by device trees, ifdef
conditionals in header files are not preferable.
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>

In UniPhier SoCs before ProXstream2 and PH1-LD6b, two address spaces
 0x00000000 - 0x0fffffff
 0x40000000 - 0x4fffffff
are both mapped to the external bus (also called system bus),
so either was OK.

In the newest two SoCs, the former (0x00000000 - 0x0fffffff) is
assigned for the serial NOR interface.

Going forward, use the latter for the external bus.
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: NSimon Glass <sjg@chromium.org>

This command will be used in the next commit to calculate
base-offseted addresses.
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>

Historically (for compatibility with very old platforms), two
different types of micro support cards have been used with the
UniPhier SoC development boards.  It has been painful to maintain
both.  Having one of them is enough.
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: NSimon Glass <sjg@chromium.org>

These input enable settings are handled by the pinctrl drivers.

Because the external bus pins are input-enabled by default, on-board
devices such as LED still work fine even with this delayed input
enabling.
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>

As the UniPhier serial driver had already switched to Drive Model
and the pinctrl drivers are now enabled, these pin-muxing settings
are properly handled by the pinctrl drivers.
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: NSimon Glass <sjg@chromium.org>

Now, UniPhier SoCs are ready to enable pinctrl drivers.
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>

Add "u-boot,dm-pre-reloc" for device nodes we want in SPL DTB
(spl/u-boot-spl.dtb).

The "soc" node (this is simple-bus node) also needs the property
to bind the pinctrl node located under it.

I am collecting this U-Boot specific hack to the bottom of board
DTS rather than inserting "u-boot,dm-pre-reloc" into SoC DTSI.
My goal is to sync DTSI with Linux for easier maintenance.
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: NSimon Glass <sjg@chromium.org>

In the next commit, I will add "u-boot,dm-pre-reloc" to the "soc"
(simple-bus) nodes in UniPhier device trees.  But, before that,
CONFIG_SYS_MALLOC_F_LEN must be increased.

Adding "u-boot,dm-pre-reloc" to a simple-bus node causes it to bind
all of its child nodes.  (See simple_bus_post_bind() function)

Actually, I want only UART0 and pinctrl to be bound in SPL and before
relocation in U-boot proper.  But, with "u-boot,dm-pre-reloc" in the
simple-bus node, all the other unwanted nodes are also bound.  The
default value for CONFIG_SYS_MALLOC_F_LEN, 0x400, is not enough for
that.  Increase the pre-reloc malloc size to 0x2000, hoping the root
cause will be fixed later.
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>

In UniPhier device trees, pinctrl device nodes are located under the
simple-bus (AMBA).

This is needed to bind pinctrl devices in SPL.
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>

Add pin configuration and pinmux support for UniPhier PH1-LD6b SoC.
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>

Add pin configuration and pinmux support for UniPhier ProXstream2
SoC.
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>

Add pin configuration and pinmux support for UniPhier PH1-Pro5 SoC.
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>

Add pin configuration and pinmux support for UniPhier PH1-sLD8 SoC.
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>

Add pin configuration and pinmux support for UniPhier PH1-Pro4 SoC.
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>

Add pin configuration and pinmux support for UniPhier PH1-LD4 SoC.
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>

The core support for the pinctrl drivers for all the UniPhier SoCs.
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: NSimon Glass <sjg@chromium.org>

Commit c5acf4a2 ("pinctrl: Add the concept of peripheral IDs")
added some additional change that was not mentioned in the git-log.

That commit added dm_scan_fdt_node() in the pinctrl uclass binding.
It should be handled by the simple-bus driver or the low-level
driver, not by the pinctrl framework.

I guess Simon's motivation was to bind GPIO banks located under the
Rockchip pinctrl device.  It is true some chips have sub-devices
under their pinctrl devices, but it is basically SoC-specific matter.

This commit partly reverts commit c5acf4a2 to keep the only
pinctrl-generic features in the uclass.  The dm_scan_fdt_node()
should be called from the rk3288_pinctrl driver.
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
Acked-by: NSimon Glass <sjg@chromium.org>
Tested-by: NSimon Glass <sjg@chromium.org>

Quark SoC does not support MSR MTRRs. Fixed and variable range MTRRs
are accessed indirectly via the message port and not the traditional
MSR mechanism. Only UC, WT and WB cache types are supported.

We configure all the fixed range MTRRs with common values (VGA RAM
as UC, others as WB) and 3 variable range MTRRs for ROM/eSRAM/RAM as
WB, which significantly improves the boot time performance.

With this commit, it takes only 2 seconds for U-Boot to boot to shell
on Intel Galileo board. Previously it took about 6 seconds.
Signed-off-by: NBin Meng <bmeng.cn@gmail.com>
Acked-by: NSimon Glass <sjg@chromium.org>
Tested-by: NSimon Glass <sjg@chromium.org>

Desktop Management Interface (DMI) is not supported by U-Boot now.
Add it to the TODO list.
Signed-off-by: NBin Meng <bmeng.cn@gmail.com>
Acked-by: NSimon Glass <sjg@chromium.org>

Document porting considerations for Intel Quark based board,
including MRC parameters and PCIe initialization.
Signed-off-by: NBin Meng <bmeng.cn@gmail.com>
Acked-by: NSimon Glass <sjg@chromium.org>

Now we have enabled PCIe root port on Quark SoC, add its PIRQ
routing information in the device tree as well.
Signed-off-by: NBin Meng <bmeng.cn@gmail.com>
Acked-by: NSimon Glass <sjg@chromium.org>

Thermal sensor on Quark SoC needs to be properly initialized per
Quark firmware writer guide, otherwise when booting Linux kernel,
it triggers system shutdown because of wrong temperature in the
thermal sensor is detected by the kernel driver (see below):

[    5.119819] thermal_sys: Critical temperature reached(206 C),shutting down
[    5.128997] Failed to start orderly shutdown: forcing the issue
[    5.135495] Emergency Sync complete
Signed-off-by: NBin Meng <bmeng.cn@gmail.com>
Acked-by: NSimon Glass <sjg@chromium.org>

When Linux kernel boots, it hangs at:

[    0.829408] Intel Quark side-band driver registered

This happens when Quark kernel Isolated Memory Region (IMR) driver
tries to lock an IMR register to protect kernel's text and rodata
sections. However in order to have IMR function correctly, HMBOUND
register must be locked otherwise the system just hangs.
Signed-off-by: NBin Meng <bmeng.cn@gmail.com>
Acked-by: NSimon Glass <sjg@chromium.org>

Change existing codes to use clrbits, setbits, clrsetbits macros.
Signed-off-by: NBin Meng <bmeng.cn@gmail.com>
Acked-by: NSimon Glass <sjg@chromium.org>

On Intel Quark, lots of registers on the message port need be
programmed. Add handy clrbits, setbits, clrsetbits macros for
message port access.
Signed-off-by: NBin Meng <bmeng.cn@gmail.com>
Reviewed-by: NSimon Glass <sjg@chromium.org>

Not like other Intel Ethernet controllers (e.g.: E1000), Intel Quark
SoC integrated designware Ethernet controller does not have a chipset
defined way to store/restore mac address. Enable random mac address
so that we can use Ethernet even without 'ethaddr'.
Signed-off-by: NBin Meng <bmeng.cn@gmail.com>
Acked-by: NSimon Glass <sjg@chromium.org>

This adds static register programming for PCIe and USB after memory
init as required by Quark firmware writer guide. Although not doing
this did not cause any malfunction, just do it for safety.
Signed-off-by: NBin Meng <bmeng.cn@gmail.com>
Acked-by: NSimon Glass <sjg@chromium.org>

Convert to use DM version of Designware ethernet driver on Intel
quark/galileo.
Signed-off-by: NBin Meng <bmeng.cn@gmail.com>
Acked-by: NSimon Glass <sjg@chromium.org>

The Designware ethernet controller is also seen on PCI bus, e.g.
on Intel Quark SoC. Add this support in the DM version driver.
Signed-off-by: NBin Meng <bmeng.cn@gmail.com>
Acked-by: NSimon Glass <sjg@chromium.org>

Introduce device_is_on_pci_bus() which can be utilized by driver
to test if a device is on a PCI bus.
Signed-off-by: NBin Meng <bmeng.cn@gmail.com>
Acked-by: NSimon Glass <sjg@chromium.org>

These properties are necessary to use full-featured pinctrl drivers
in SPL.
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
Acked-by: NSimon Glass <sjg@chromium.org>

Enabling a PLL while IDDQ is high. The Linux kernel checks for this
condition and warns about it verbosely, so while this seems to work
fine, fix it up according to the programming guidelines provided in
the Tegra K1 TRM (v02p), Section 5.3.8.1 ("PLLC and PLLC4 Startup
Sequence"). The Tegra114 TRM doesn't contain this information, but
the programming of PLLC is the same on Tegra114 and Tegra124.
Signed-off-by: NThierry Reding <treding@nvidia.com>
Signed-off-by: NTom Warren <twarren@nvidia.com>

Enabling a PLL while IDDQ is high. The Linux kernel checks for this
condition and warns about it verbosely, so while this seems to work
fine, fix it up according to the programming guidelines provided in
the Tegra K1 TRM (v02p), Section 5.3.8.1 ("PLLC and PLLC4 Startup
Sequence").
Reported-by: NNicolas Chauvet <kwizart@gmail.com>
Signed-off-by: NThierry Reding <treding@nvidia.com>
Signed-off-by: NTom Warren <twarren@nvidia.com>

Add the device tree node for the SPI controllers found on Tegra20 SOCs.
Signed-off-by: NMirza Krak <mirza.krak@hostmobility.com>
Signed-off-by: NTom Warren <twarren@nvidia.com>

The counter frequency is derived from clk_m on Tegra, but that clock can
be configured by the primary bootloader to run at the same frequency as
the oscillator (38.4 MHz on Tegra210) or a divided down frequency (most
typically 19.2 MHz). Remove the hard-coded frequency and allow the timer
setup code to query the correct value at runtime.
Signed-off-by: NThierry Reding <treding@nvidia.com>
Signed-off-by: NTom Warren <twarren@nvidia.com>

The counter frequency is derived from clk_m on Tegra, but that clock can
be configured by the primary bootloader to run at the same frequency as
the oscillator (38.4 MHz on Tegra210) or a divided down frequency (most
typically 19.2 MHz). Remove the hard-coded frequency and allow the timer
setup code to query the correct value at runtime.
Signed-off-by: NThierry Reding <treding@nvidia.com>
Signed-off-by: NTom Warren <twarren@nvidia.com>

The counter frequency is derived from clk_m on Tegra, but that clock can
be configured by the primary bootloader to run at the same frequency as
the oscillator (38.4 MHz on Tegra210) or a divided down frequency (most
typically 19.2 MHz). Remove the hard-coded frequency and allow the timer
setup code to query the correct value at runtime.
Signed-off-by: NThierry Reding <treding@nvidia.com>
Signed-off-by: NTom Warren <twarren@nvidia.com>