Drop the unneeded code. lib/time.c use timebase_l/h.

Signed-off-by: Peng Fan <peng.fan@nxp.com>
Cc: Stefano Babic <sbabic@denx.de>
Reviewed-by: Stefano Babic <sbabic@denx.de>

Select CONFIG_FSL_IIM and CONFIG_CMD_FUSE so that the fuse API can
be used.

Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com>

Specify the registered eth index by dev_id.

Signed-off-by: Fugang Duan <fugang.duan@nxp.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Cc: Joe Hershberger <joe.hershberger@ni.com>

Avoid transfer parameter dev_id value with "-1" to .fec_get_hwaddr(),
it should transfer fec->dev_id to get mac address from fuse.

Signed-off-by: Fugang Duan <fugang.duan@nxp.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Cc: Joe Hershberger <joe.hershberger@ni.com>
Acked-by: Stefano Babic <sbabic@denx.de>

The MIB RAM and FIFO receive start register does not exist on
i.MX6ULL. Accessing these register will cause enet not work well or
cause system report fault.

Signed-off-by: Peng Fan <peng.fan@nxp.com>
Cc: Joe Hershberger <joe.hershberger@ni.com>

- 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

Add the boot device table and reset deassertion for eMMC.

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

Reserve enough space below the kernel base.
The assumed address map is:
  80000000 - 80ffffff : for IPP
  81000000 - 81ffffff : for ARM secure
  82000000 -          : for Linux

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

Fix the following DTC warnings:
Warning (simple_bus_reg): Node /soc/system-bus@58c00000/support_card@1,1f00000/ethernet@00000000 simple-bus unit address format error, expected "0"
Warning (simple_bus_reg): Node /soc/system-bus@58c00000/support_card@1,1f00000/uart@000b0000 simple-bus unit address format error, expected "b0000"
Warning (simple_bus_reg): Node /soc/smpctrl@59800000 simple-bus unit address format error, expected "59801000"

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

When booting from ARM Trusted Firmware, U-Boot runs in EL1-NS.
The boot flow is as follows:
  BL1 -> BL2 -> BL31 -> BL33 (i.e. U-Boot)

This boot sequence works fine for LD11 SoC (Cortex-A53), but LD20
SoC (Cortex-A72) hangs in U-Boot.  The solution I found is to
read sctlr_el1 and write back the value as-is.  This should be
no effect, but surprisingly fixes the problem for LD20 to boot.
I do not know why.

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

This script command will be useful to update boot images in the
USB storage.

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

The MODEL field is 3 bit wide.

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

Remove 'pad-offset' of soc_gpio_s5_0, soc_gpio_s5_1, soc_gpio_s5_2,
pin_usb_host_en0 and pin_usb_host_en1. These offsets are actually
wrong. Correct value should be added by 0x2000, but since they
are supposed to be 'mode-gpio', 'pad-offset' is not needed at all.

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Stefan Roese <sr@denx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>

Add a device-tree property use-lvl-write-cache that will cause
writes to lvl to be cached instead of read from lvl before each
write. This is required on some platforms that have the register
implemented as dual read/write (such as Baytrail).

Prior to this fix the blue USB port on the Minnowboard Max was
unusable since USB_HOST_EN0 was set high then immediately set
low when USB_HOST_EN1 was written.

This also resolves the 'gpio clear | set' command warning like:
  "Warning: value of pin is still 0"

Signed-off-by: George McCollister <george.mccollister@gmail.com>
<rebased on latest origin/master, fixed all baytrail boards>
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Stefan Roese <sr@denx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>

This patch adds a remove function to the Intel ICH SPI driver, that will
be called upon U-Boot exit, directly before the OS (Linux) is started.
This function takes care of configuring the BIOS registers in the SPI
controller (similar to what a "standard" BIOS or coreboot does), so that
the Linux MTD device driver is able to correctly read/write to the SPI
NOR chip. Without this, the chip is not detected at all.

Signed-off-by: Stefan Roese <sr@denx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Cc: Bin Meng <bmeng.cn@gmail.com>
Cc: Jagan Teki <jteki@openedev.com>

This patch adds a call to dm_remove_devices_flags() to
bootm_announce_and_cleanup() so that drivers that have one of the removal
flags set (e.g. DM_FLAG_ACTIVE_DMA_REMOVE) in their driver struct, may
do some last-stage cleanup before the OS is started.

Signed-off-by: Stefan Roese <sr@denx.de>
Cc: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

This new flag can be added to DM device drivers, which need to do some
final configuration before U-Boot exits and the OS (e.g. Linux) is
started. The remove functions of those drivers will get called at
this stage to do these last-stage configuration steps.

Signed-off-by: Stefan Roese <sr@denx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Cc: Bin Meng <bmeng.cn@gmail.com>

On my x86 platform I've noticed, that calling dm_uninit() or the new
function dm_remove_devices_flags() does not remove the desired device at
all. Debugging showed, that the serial uclass returns -EPERM in
serial_pre_remove(). This patch sets the force parameter when calling
stdio_deregister_dev() resulting in a removal of the device.

Signed-off-by: Stefan Roese <sr@denx.de>
Cc: Simon Glass <sjg@chromium.org>
Cc: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

Convert the pci_mmc driver over to driver model and migrate all x86 boards
that use it.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Tested-by: Bin Meng <bmeng.cn@gmail.com>

Now that we have ACPI S3 support on Intel MinnowMax board, document
some generic information of S3 and how to test it.

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Stefan Roese <sr@denx.de>

This turns on ACPI S3 resume for minnowmax board.

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Stefan Roese <sr@denx.de>

U-Boot sets up the real mode interrupt handler stubs starting from
address 0x1000. In most cases, the first 640K (0x00000 - 0x9ffff)
system memory is reported as system RAM in E820 table to the OS.
(see install_e820_map() implementation for each platform). So OS
can use these memories whatever it wants.

If U-Boot is in an S3 resume path, care must be taken not to corrupt
these memorie otherwise OS data gets lost. Testing shows that, on
Microsoft Windows 10 on Intel Baytrail its wake up vector happens to
be installed at the same address 0x1000. While on Linux its wake up
vector does not overlap this memory range, but after resume kernel
checks low memory range per config option CONFIG_X86_RESERVE_LOW
which is 64K by default to see whether a memory corruption occurs
during the suspend/resume (it's harmless, but warnings are shown
in the kernel dmesg logs).

We cannot simply mark the these memory as reserved in E820 table
because such configuration makes GRUB complain: unable to allocate
real mode page. Hence we choose to back up these memories to the
place where we reserved on our stack for our S3 resume work.
Before jumping to OS wake up vector, we need restore the original
content there.

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Stefan Roese <sr@denx.de>

Introduce a new CONFIG_S3_VGA_ROM_RUN option so that U-Boot can
bypass executing VGA roms in S3.

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Stefan Roese <sr@denx.de>

Before jumping to OS waking up vector, we need turn on ACPI mode
for S3, just like what we do for a normal boot.

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Stefan Roese <sr@denx.de>

To do something more in acpi_resume() like turning on ACPI mode,
we need locate ACPI FADT table pointer first. But currently this
is done in acpi_find_wakeup_vector().

This changes acpi_resume() signature to accept ACPI FADT pointer
as the parameter. A new API acpi_find_fadt() is introduced, and
acpi_find_wakeup_vector() is updated to use FADT pointer as the
parameter as well.

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Stefan Roese <sr@denx.de>

enter_acpi_mode() is useful on other boot path like S3 resume, so
make it public.

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Stefan Roese <sr@denx.de>

In enter_acpi_mode() PM1_CNT register is changed to PM1_CNT_SCI_EN
directly without preserving its previous value. Update to change
the register access to read-modify-write (RMW).

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Stefan Roese <sr@denx.de>

Call board_final_cleanup() before write_tables(), so that anything
done in board_final_cleanup() on a normal boot path is also done
on an S3 resume path.

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Stefan Roese <sr@denx.de>

When SeaBIOS is being used, U-Boot reserves a memory area to be
used for configuration tables like ACPI. But it should not be
cleared otherwise ACPI table will be missing.

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Stefan Roese <sr@denx.de>

At the end of pre-relocation phase, save the new stack address
to CMOS and use it as the stack on next S3 boot for fsp_init()
continuation function.

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Stefan Roese <sr@denx.de>

This adds a library that provides CMOS (inside RTC SRAM) access
at a very early stage when driver model is not available yet.

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Stefan Roese <sr@denx.de>

In an S3 resume path, U-Boot does everything like a cold boot except
in the last_stage_init() it jumps to the OS resume vector.

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Stefan Roese <sr@denx.de>

This adds one API acpi_find_wakeup_vector() to locate OS wakeup
vector from the ACPI FACS table, to be used in the S3 boot path.

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Stefan Roese <sr@denx.de>

This adds a wake up stub before jumping to OS wake up vector.

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Stefan Roese <sr@denx.de>

U-Boot itself as well as everything that is consumed by U-Boot (like
heap, stack, dtb, etc) needs to be reserved and reported in the E820
table when S3 resume is on.

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Stefan Roese <sr@denx.de>

When U-Boot is built without ACPI S3 support, it should not report
S3 in the ACPI table otherwise when kernel does STR it won't work.

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Stefan Roese <sr@denx.de>

Add one member in the global data to store previous sleep state,
and display the state during boot in print_cpuinfo().

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Stefan Roese <sr@denx.de>

When ACPI S3 resume is turned on, we should pass different boot mode
to FSP init instead of default BOOT_FULL_CONFIG.

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Stefan Roese <sr@denx.de>

This adds OS_RESUME (0x40) and RESUME_FAILURE (0xed) post codes.

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Stefan Roese <sr@denx.de>