Intel x86 SoCs have a power manager/controller which handles several
power-related aspects of the platform. Add a uclass for this, with a few
useful operations.
Signed-off-by: NSimon Glass <sjg@chromium.org>
Reviewed-by: NBin Meng <bmeng.cn@gmail.com>

We don't expect an exception in TPL and don't need to set up interrupts in
TPL. Drop this whole file.
Signed-off-by: NSimon Glass <sjg@chromium.org>
Reviewed-by: NBin Meng <bmeng.cn@gmail.com>

We don't need to know every detail about the CPU in TPL. Drop some
superfluous functions to reduce code size. Add a simple CPU detection
algorithm which just supports Intel and AMD, since we only support TPL
on Intel, so far.
Signed-off-by: NSimon Glass <sjg@chromium.org>
Reviewed-by: NBin Meng <bmeng.cn@gmail.com>

Most of the timer-calibration methods are not needed on recent Intel CPUs
and just increase code size. Add an option to use the known-good way to
get the clock frequency in TPL. Size reduction is about 700 bytes.

Note that version 1 of this commit caused bootstage to crash since the CPU
was not identified. This is corrected by changes previously applied to
make sure that the CPU is identified before spl_init() is called, such as

   39146a2e0b x86: Move CPU init to before spl_init()
Signed-off-by: NSimon Glass <sjg@chromium.org>
Reviewed-by: NBin Meng <bmeng.cn@gmail.com>

On x86 platforms the timer is reset to 0 when the SoC is reset. Having
this as the timer base is useful since it provides an indication of how
long it takes before U-Boot is running.

When U-Boot sets the timer base to something else, time is lost and we
no-longer have an accurate account of the time since reset. This
particularly affects bootstage.

Change the default to not read the timer base, leaving it at 0. Add an
option for when U-Boot is the secondary bootloader.
Signed-off-by: NSimon Glass <sjg@chromium.org>
Reviewed-by: NBin Meng <bmeng.cn@gmail.com>

At present the early timer init happens as soon as driver model is set up.
This makes it impossible to do anything that needs driver model but must
run before devices are probed (as needed with Intel's FSP-S, for example).

In any case it is not a good idea to tie probing of particular drivers too
closely to the DM init.

Create a new function to init the timer and put it a bit later in the
sequence.
Signed-off-by: NSimon Glass <sjg@chromium.org>
Reviewed-by: NBin Meng <bmeng.cn@gmail.com>

At present these options cannot be enabled for SPL/TPL, but this can be
useful in some cases. Add Kconfig options to allow it.
Signed-off-by: NSimon Glass <sjg@chromium.org>
Reviewed-by: NBin Meng <bmeng.cn@gmail.com>

When device-tree compilation fails it is sometimes tricky to see which
line is broken, since the input file to dtc is a pre-processed version
of the device tree.

Add a line that points to the file that needs to be checked:

When the error is in the main .dts file, output is something like this:

   output: 'Error: arch/x86/dts/.chromebook_coral.dtb.pre.tmp:478.46-47
	syntax error
   FATAL ERROR: Unable to parse input tree

but in fact looking at that file shows nothing useful:

   PAD_CFG_NF_IOSSTATE_IOSTERM(GPIO_157, UP_20K, DEEP, NF1, HIZCRX1, DISPUPD)

Instead we need to look at the preprocessed file, which shows:

   163 ((1U << 30) | (1 << 10)) ((0xb << 10) | PAD_CFG1_IOSSTATE_HIZCRX1)

Here it is clear that PAD_CFG1_IOSSTATE_HIZCRX1 is not defined and so is
not being resolved by the preprocessor.

This commit adds an additional useful message:

   Check arch/x86/dts/.chromebook_coral.dtb.dts.tmp for errors

Note that if the error is reported in an included file, such as
u-boot.dtsi then the output is the following:

   Error: arch/x86/dts/u-boot.dtsi:137.14-15 syntax error
   FATAL ERROR: Unable to parse input tree

But again, if the error is due to a preprocessor failure, like this:

   filename = CONFIG_IFW_INPUT_FILE;

then you can't tell what the problem is by looking at the source. All you
see is the original code:

	intel-ifwi {
		filename = CONFIG_IFW_INPUT_FILE;
		...
		};
	};
	intel-fsp-m {
		filename = CONFIG_FSP_FILE_M;
	};

Everything looks fine. But looking at the output of the preprocessor:

 intel-ifwi {
  filename = CONFIG_IFW_INPUT_FILE;
  ...
 };
 intel-fsp-m {
  filename = "fsp_m.bin";
 };

This shows that the filename (normally "fitimage.bin") has not been
inserted the preprocess, leading to the realisation that the value should
be CONFIG_IFWI_INPUT_FILE.

If the above does not make sense, I encourage people to try introducing
errors in the device tree preprocessed values.
Signed-off-by: NSimon Glass <sjg@chromium.org>
Reviewed-by: NBin Meng <bmeng.cn@gmail.com>

Most x86 CPUs use a mechanism where the SPI flash is mapped into the very
top of 32-bit address space, so that it can be executed in place and read
simply by copying from memory. For an 8MB ROM the mapping starts at
0xff800000.

However some recent Intel CPUs do not use a simple 1:1 memory map. Instead
the map starts at a different address and not all of the SPI flash is
accessible through the map. This 'Fast SPI' feature requires that U-Boot
check the location of the map. It is also possible (optionally) to read
from the SPI flash using a driver.

Add support for booting from Fast SPI. The memory-mapped version is used
by both TPL and SPL on Apollo Lake.

In respect of a SPI flash driver, the actual SPI driver is ich.c - this
just adds a few helper functions and definitions.

This is used by Apollo Lake.
Signed-off-by: NSimon Glass <sjg@chromium.org>
Reviewed-by: NBin Meng <bmeng.cn@gmail.com>

Allow this driver to set up an IO address in SPL using an 'early-regs'
property. This allows SPL to use the I2C driver without having to enable
the full PCI stack.

Also split out ofdata_to_platdata in designware driver since this is more
correct, and more convenient for the new logic.
Signed-off-by: NSimon Glass <sjg@chromium.org>
Reviewed-by: NBin Meng <bmeng.cn@gmail.com>

Drivers are not allowed to use static data since they may be used in SPL
where BSS is not available.

It is possible that driver model may provide support for numbering devices
in the future. But for now, move this to global_data.
Signed-off-by: NSimon Glass <sjg@chromium.org>
Reviewed-by: NBin Meng <bmeng.cn@gmail.com>

This is hacked into the driver at present. It seems better to have it as
a separate driver that uses the base driver. Create a new file and put
the X86 code into it.

Actually the Baytrail settings should really come from the device tree.

Note that 'has_max_speed' is added as well. This is currently always false
but since only Baytrail provides the config, it does not affect operation
for other devices.
Signed-off-by: NSimon Glass <sjg@chromium.org>
Reviewed-by: NHeiko Schocher <hs@denx.de>
Reviewed-by: NBin Meng <bmeng.cn@gmail.com>

These functions are used by code outside the network support, so move them
to lib/ to be more accessible.

Without this, the functions are only accessible in SPL/TPL only if
CONFIG_SPL/TPL_NET are defined. Many boards do not enable those option but
still want to do checksums in this format.

Fix up a few code-style nits while we are here.
Signed-off-by: NSimon Glass <sjg@chromium.org>
Acked-by: NJoe Hershberger <joe.hershberger@ni.com>
Reviewed-by: NBin Meng <bmeng.cn@gmail.com>

Early in boot it is necessary to decode the PCI device/function values for
particular peripherals in the device tree or of-platdata. This is needed
in TPL where CONFIG_PCI is not defined.

To handle this, move pci_get_devfn() into a file that is built even when
CONFIG_PCI is not defined.

Also add a function for use by of-platdata, to convert a reg property to
a pci_dev_t.
Signed-off-by: NSimon Glass <sjg@chromium.org>
Reviewed-by: NBin Meng <bmeng.cn@gmail.com>

At present PCI auto-configuration happens in U-Boot both before and after
relocation. This is a waste of time and may mess up static addresses used
in board_init_f(). Adjust the code to supporting doing auto-configuration
once, after relocation, under control of a device-tree property.

This is needed for Apollo Lake for debugging the silicon-init code. Once
the UART is moved to a different MMIO address the debug UART does not work
and any debug output in Apollo Lake's arch_fsp_init_r() causes a hang.
Signed-off-by: NSimon Glass <sjg@chromium.org>
Reviewed-by: NBin Meng <bmeng.cn@gmail.com>

If the offset is -1 this function correctly sets up a null ofnode. But if
the offset is any other negative number (e.g. -FDT_ERR_BADPATH) then it
does the wrong thing.

An offset of -1 in ofnode indicates that the ofnode is not valid. Any
other negative value is not handled by ofnode_valid(). We could of course
change that function, but it seems much better to always use the same
value for an invalid node.

Fix it by setting the offset to -1 if it is invalid for any reason.
Signed-off-by: NSimon Glass <sjg@chromium.org>
Reviewed-by: NBin Meng <bmeng.cn@gmail.com>

At present if CONFIG_SPL_GPIO_SUPPORT is enabled then the GPIO uclass
is included in SPL/TPL without any control for boards. Some boards may
want to disable this to reduce code size where GPIOs are not needed in
SPL or TPL.

Add a new Kconfig option to permit this. Default it to 'y' so that
existing boards work correctly.

Change existing uses of CONFIG_DM_GPIO to CONFIG_IS_ENABLED(DM_GPIO) to
preserve the current behaviour. Also update the 74x164 GPIO driver since
it cannot build with SPL.

This allows us to remove the hacks in config_uncmd_spl.h and
Makefile.uncmd_spl (eventually those files should be removed).
Signed-off-by: NSimon Glass <sjg@chromium.org>
Reviewed-by: NBin Meng <bmeng.cn@gmail.com>

SPL and TPL can access information about binman entries using link-time
symbols but this is not available in U-Boot proper. Of course it could be
made available, but the intention is to just read the device tree.

Add support for this, so that U-Boot can locate entries.
Signed-off-by: NSimon Glass <sjg@chromium.org>
Reviewed-by: NBin Meng <bmeng.cn@gmail.com>

buildman improvements including toolchain environment feature
sandbox unicode support in serial

- fix DRAM bank detection for unified binary
- fix 32bit RPi4 config

i2c bugfixes for 2020.01
- i2c: i2c_cdns: fix write timeout on fifo boundary
  fixes timout issue when writting number of bytes is multiple
  of the FIFO depth.

- First set of u-boot-atmel fixes for 2020.01 cycle:
  This set includes a small fix for gpio bank names, one for removing
  unused headers (also touches some other boards), and a fix for the QSPI
  env read on one of the boards.

The rpi_4_32b_defconfig states that only one DRAM bank is present. This
leads to a wrong configuration of the available DRAM. Fix this by
setting the DRAM bank config accordingly.

Fixes: 193279d7 ("RPI: Add defconfigs for rpi4 (32/64)")
Signed-off-by: NMatthias Brugger <mbrugger@suse.com>

Up to now we only update the DRAM banks when we are define
CONFIG_BCM2711. But our one binary approach uses a config that supports
BCM2837 and BCM2711. As a result we only see one gibibyte of RAM on
Raspberry Pi 4, even if it has more RAM.
Fix this by calling dram_init_banksize.

Fixes: 56940906 ("ARM: defconfig: add unified config for RPi3 and RPi4")
Signed-off-by: NMatthias Brugger <mbrugger@suse.com>

To update the dram bank information from device-tree we use
fdtdec_decode_ram_size() which expectes the the size-cells and
address-cells to be defined in the memory node. For normal system RAM
these values are defined in the root node. When the values differ from
the default values defined in the spec, we can end up with wrong RAM
bank information.

Switch to the "standard" way to update the RAM bank information to
avoid this.

Fixes: 9de5b89e ("rpi4: enable dram bank initialization")
Signed-off-by: NMatthias Brugger <mbrugger@suse.com>

This fixes an issue that would cause I2C writes to timeout when the
number of bytes is a multiple of the FIFO depth (i.e. 16 bytes).

Within the transfer loop, after writing the data register with a new
byte to transfer, if the transfer size equals the FIFO depth, the loop
pauses until the INTERRUPT_COMP bit asserts to indicate data has been
sent. This same check is performed after the loop as well to ensure data
has been transferred prior to returning.

In the case where the amount of data to be written is a multiple of the
FIFO depth, the transfer loop would wait for the INTERRUPT_COMP bit to
assert after writing the final byte, and then wait for this bit to
assert once more. However, since the transfer has finished at this
point, no new data has been written to the data register, and hence
INTERRUPT_COMP will never assert.

Fix this by only waiting for INTERRUPT_COMP in the transfer loop if
there's still data to be written.
Signed-off-by: NMichael Auchter <michael.auchter@ni.com>
Reviewed-by: NSimon Glass <sjg@chromium.org>

Chromium EC commands can be up to 16-bits, so using a uint8_t here can
cause truncation. Update to use a uint instead.

It looks like this should likely have been done as a part of
9fea76f5, but this function was skipped
for some reason.
Signed-off-by: NMichael Auchter <michael.auchter@ni.com>
Cc: Simon Glass <sjg@chromium.org>
Reviewed-by: NSimon Glass <sjg@chromium.org>

Today when parsing the .sizes files we get a warning about an invalid
line in the file as it's blank.  Solve this by checking that we have a
non-blank line prior to processing.

Cc: Simon Glass <sjg@chromium.org>
Signed-off-by: NTom Rini <trini@konsulko.com>
Reviewed-by: NSimon Glass <sjg@chromium.org>

Sometimes it is useful for external tools to use buildman to provide the
toolchain information. Add an -a option which shows the value to use for
the ARCH environment variable, and -A which does the same for
CROSS_COMPILE
Signed-off-by: NSimon Glass <sjg@chromium.org>

At present buildman looks at toolchains, then commits and then boards.
Move the board processing up above the commit processing, since it relates
to the toolchain code. This will make it easier to check the toolchains
needed for a board without processing commits first.
Signed-off-by: NSimon Glass <sjg@chromium.org>

Now that this tool has a 'quiet' flag, use it.
Signed-off-by: NSimon Glass <sjg@chromium.org>

We don't really need buildman to print this every time it runs. Add a flag
to run quietly, that buildman can use.
Signed-off-by: NSimon Glass <sjg@chromium.org>

- fix crash and board reset when drawing RLE8 bitmaps
  bigger than the framebuffer resolution
- reduce dead code in video and console uclass routines
  (tested on mx53cx9020, sama5d2_xplained, stm32mp157c-ev1,
   stm32f746-disco, stm32f769-disco and wandboard)

Buildman doesn't store this file in the same directory as a normal build.
Update the conftest code to handle both cases.

Change-Id: I1fd0e56054d7dc77394a7589336aa0991bd0133d
Signed-off-by: NSimon Glass <sjg@chromium.org>

The parser responsible for the '[make-flags]' section in
the '.buildman' settings file is currently not able to
handle quoted strings, as given in the sample bellow:

[make-flags]
qemu_arm=HOSTCC="cc -isystem /add/include" HOSTLDFLAGS="-L/add/lib"

This patch replaces the simple string splitter based on the <space>
delimiter with a regex tokenizer that preserves spaces inside double
quoted strings.
Signed-off-by: NCristian Ciocaltea <cristian.ciocaltea@gmail.com>

Due to a conversion error the sandbox does not accept byte values 0x80-0xff
from the keyboard. The UEFI extended text input unit test requires Unicode
support.

Use unsigned char for the serial buffer.
Signed-off-by: NHeinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: NAndy Shevchenko <andy.shevchenko@gmail.com>

In the device tree UEFI unit test the compatible property of the device is
read.

Provide the missing property.
Signed-off-by: NHeinrich Schuchardt <xypron.glpk@gmx.de>

In the initial SPI flash setup, the default bus mode being used was 3,
which is incorrect, causing a CRC error when the ENV was being read from
QSPI. Setting the default bus mode to 0 which is the correct mode.
Signed-off-by: NSwapna Gurumani <swapna.gurumani@microchip.com>

- Increase stack size to avoid a stack overflow during distro boot.
- Add hifive-unleashed-a00.dts for SIFIVE FU540.
- Add OF_SEPARATE support for SIFIVE FU540.
- Add SPL support for Andes AX25 AE350.
- Improve U-Boot SPL / OpenSBI smp boot flow for RISC-V.

At the start, OpenSBI relocates itself to its link address. If the link
address ranges of U-Boot SPL and OpenSBI overlap, the relocation can
lead to code corruption if a hart is still running U-Boot SPL during
relocation. To avoid this problem, the main hart is specified as the
preferred boot hart to perform the relocation. This fixes the code
corruption problems based on the assumption that since the main hart
schedules the secondary harts to enter OpenSBI, it will be the last to
enter OpenSBI. However it was reported that this assumption is not
always correct.

To make sure the assumption always holds true, wait for all secondary
harts to acknowledge the call-function request before entering OpenSBI
on the main hart.
Reported-by: NRick Chen <rick@andestech.com>
Signed-off-by: NLukas Auer <lukas.auer@aisec.fraunhofer.de>
Reviewed-by: NRick Chen <rick@andestech.com>
Tested-by: NRick Chen <rick@andestech.com>
Reviewed-by: NAnup Patel <anup.patel@wdc.com>