Intel Management Engine is required by the platform, however it's
not a must have when building a U-Boot image. For example, during
development normally programming ME firmware is a one-time effort.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
At present the AHCI SCSI driver only supports PCI with driver model.
Rename the existing function to indicate this and add support for adding
a non-PCI controller .
Signed-off-by: Simon Glass <sjg@chromium.org>
In Baytrail and Quark support code acpi_fill_madt() is identical.
Deduplicate its implementation by moving to lib/acpi_tables.c.
At the same time mark acpi_fill_madt() with __weak attribute to keep a
possibility to override it in platform code
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Add Intel Edison board which is using U-Boot.
The patch is based on work done by the following people (in alphabetical
order):
Aiden Park <aiden.park@intel.com>
Dukjoon Jeon <dukjoon.jeon@intel.com>
eric.park <eric.park@intel.com>
Fabien Chereau <fabien.chereau@intel.com>
Felipe Balbi <felipe.balbi@linux.intel.com>
Scott D Phillips <scott.d.phillips@intel.com>
Sebastien Colleur <sebastienx.colleur@intel.com>
Steve Sakoman <steve.sakoman@intel.com>
Vincent Tinelli <vincent.tinelli@intel.com>
In case we're building for Intel Edison, we must have 4096 bytes of
zeroes in the beginning on u-boot.bin. This is done in
board/intel/edison/config.mk.
First run sets hardware_id environment variable which is read from
System Controller Unit (SCU).
Serial number (serial# environment variable) is generated based on eMMC
CID.
MAC address on USB network interface is unique to the board but kept the
same all over the time.
Set mac address from U-Boot using following scheme:
OUI = 02:00:86
next 3 bytes of MAC address set from eMMC serial number
This allows to have a unique mac address across reboot and flashing.
Signed-off-by: Vincent Tinelli <vincent.tinelli@intel.com>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
[bmeng: Add MAINTAINERS file for Intel Edison board]
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Add Intel Tangier SoC support.
Intel Tangier SoC is a core part of Intel Merrifield platform. For
example, Intel Edison board is based on such platform.
The patch is based on work done by the following people (in alphabetical
order):
Aiden Park <aiden.park@intel.com>
Dukjoon Jeon <dukjoon.jeon@intel.com>
eric.park <eric.park@intel.com>
Fabien Chereau <fabien.chereau@intel.com>
Scott D Phillips <scott.d.phillips@intel.com>
Sebastien Colleur <sebastienx.colleur@intel.com>
Steve Sakoman <steve.sakoman@intel.com>
Vincent Tinelli <vincent.tinelli@intel.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Signed-off-by: Vincent Tinelli <vincent.tinelli@intel.com>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
As a demonstration of how to use SCSI with driver model, move link over
to use this. This patch needs more work, but illustrates the concept.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
This reverts commit ddb3ac3c71.
With MMC converted to driver model, SCSI driver is broken due to
zero address access at (ops->read) in block_dread() function.
The fix (SCSI driver converted to DM) is ready in u-boot-dm branch,
but it is too late for this relese to get that in.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
It was observed that when -DDEBUG is used to generate a debug build,
U-Boot does not boot on MinnowMax board. A workaround is to disable
CONFIG_DEBUG_UART. The real issue is that in order to have the debug
uart to work, BayTrail SoC needs to be configured so that its internal
uart is available to be used as the debug uart.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Stefan Roese <sr@denx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
At present lpe/lpss-sio/scc FSP properties are all boolean, but in
fact for "enable-lpe" it has 3 possible options. This adds macros
for these options and change the property from a boolean type to
an integer type, and change their names to explicitly indicate what
the property is really for.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Stefan Roese <sr@denx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Introduce various meaningful macros for FSP settings and switch over
to use them instead of magic numbers.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Stefan Roese <sr@denx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
"serial-debug-port-address" and "serial-debug-port-type" settings
are actually reserved in the FSP UPD data structure. Remove them.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Stefan Roese <sr@denx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
The default value of "fsp,mrc-init-tseg-size" should be 1 (1MB) per
FSP default settings. 0 is not valid.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Stefan Roese <sr@denx.de>
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>
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>
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>
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>
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>
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 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>
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>
This adds APIs for determining previous sleep state from ACPI I/O
registers, as well as clearing sleep state on BayTrail SoC.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Stefan Roese <sr@denx.de>
Rather than using CMD_CBFS for both the filesystem and its command, we
should have a separate option for each. This allows us to enable CBFS
support without the command, if desired, which reduces U-Boot's size
slightly.
Signed-off-by: Simon Glass <sjg@chromium.org>
[trini: imply FS_CBFS on SYS_COREBOOT]
Signed-off-by: Tom Rini <trini@konsulko.com>
This converts the following to Kconfig:
CONFIG_CMD_CBFS
Signed-off-by: Simon Glass <sjg@chromium.org>
[trini: imply CMD_CBFS on SYS_COREBOOT]
Signed-off-by: Tom Rini <trini@konsulko.com>
The Intel CPU name can have leading spaces. Remove them since they are not
useful.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
By making dram_init_banksize() return an error code we can drop the
wrapper. Adjust this and clean up all implementations.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Stefan Roese <sr@denx.de>
At present we misuse print_cpuinfo() do so CPU init on x86. This is done
because it is the next available call after the console is enabled. But
several arches use checkcpu() instead. Despite the horrible name (which
we can fix), it seems a better choice.
Adjust the various x86 CPU implementations to move their init code into
checkcpu() and use print_cpuinfo() only for printing CPU info.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Stefan Roese <sr@denx.de>
This patch adds the flags parameter to device_remove() and changes all
calls to this function to provide the default value of DM_REMOVE_NORMAL
for "normal" device removal.
This is in preparation for the driver specific pre-OS (e.g. DMA
cancelling) remove support.
Signed-off-by: Stefan Roese <sr@denx.de>
Cc: Simon Glass <sjg@chromium.org>
Acked-by: Simon Glass <sjg@chromium.org>
There is no microcode update available for SoCs used on Intel MID
platforms.
Use conditional to bypass it.
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Depending upon the compiler used, IRQ entries could vary in sizes. With
GCC 5.x, the code generator will use short jumps for some IRQ entries
but near jumps for others. For example, GCC 5.4.0 generates the
following:
$ objdump -d interrupt.o
<snip>
00000207 <irq_18>:
207: 6a 12 push $0x12
209: eb 85 jmp 190 <irq_common_entry>
0000020b <irq_19>:
20b: 6a 13 push $0x13
20d: eb 81 jmp 190 <irq_common_entry>
0000020f <irq_20>:
20f: 6a 14 push $0x14
211: e9 7a ff ff ff jmp 190 <irq_common_entry>
00000216 <irq_21>:
216: 6a 15 push $0x15
218: e9 73 ff ff ff jmp 190 <irq_common_entry>
This causes a problem in cpu_init_interrupts(), because the IDT setup
assumed same sizes for all IRQ entries. GCC 4.x always generated 32-bit
jumps, so this previously was not a problem.
The fix is to force 32-bit near jumps for all entries within the
inline assembly. This works for GCC 5.x, and 4.x was already using
that form of jumping.
Signed-off-by: Jason Tang <tang@jtang.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
At present devices use a simple integer offset to record the device tree
node associated with the device. In preparation for supporting a live
device tree, which uses a node pointer instead, refactor existing code to
access this field through an inline function.
Signed-off-by: Simon Glass <sjg@chromium.org>
This option is useful not only for development, but for the platforms
where U-Boot is run from custom ROM bootloader. For example, Intel
Edison is that board.
Make this option visible that platforms can select it if needed.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
arch_cpu_init() and print_cpuinfo() should be only available in SPL
build.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
DECLARE_GLOBAL_DATA_PTR is missing which causes 64-bit build error.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Update config.mk settings to support both 32-bit and 64-bit U-Boot.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
We don't have the code for this yet. Add a dummy version for now, so that
EFI builds correctly.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
This code is only used in 32-bit mode. Move it so that it does not get
built with 64-bit U-Boot.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
This code is only used in 32-bit mode. Move it so that it does not get
built with 64-bit U-Boot.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
To avoid using BSS in SPL before SDRAM is set up, move this field to
global_data.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
To avoid using BSS in SPL before SDRAM is set up, move this field to
global_data.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Add a rough function to handle jumping from 32-bit SPL to 64-bit U-Boot.
This still needs work to clean it up.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Some files cannot be built with 64-bit and mostly don't make sense in that
context. Disable them.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
These are currently not supported. Calling 64-bit code from 64-bit U-Boot is
much simpler, so this code is not needed. setjmp() is not yet implemented for
64-bit.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
We don't support SDRAM init in 64-bit mode since it is essentially
impossible to get into that mode before SDRAM set up. Provide dummy functions
for now. At some point we will need to pass the SDRAM parameters through from
SPL.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
If SPL is used it is always build in 32-bit mode. Add a link script to
handle the correct placement of the sections.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
This needs a different image format from 32-bit x86, so add a new link
script.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
When SPL and U-Boot proper have different settings for this flag, we need to
use the correct one. Fix this up in the interrupt code.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
At present this is just an ordinary variable. We may consider making it a
fixed register in the future.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
There is not much needed at present, but set up a separate directory to put
this code as it grows.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Much of the cpu and interrupt code cannot be compiled on 64-bit x86. Move it
into its own directory and build it only in 32-bit mode.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Add code to start up U-Boot in 64-bit mode. It is fairly simple since we are
running from RAM and SPL has done the low-level init.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Update the Makefile so that some 32-bit init can be built into SPL rather
than U-Boot proper.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Use this new option to control the location of 32-bit init. This will allow
us to place this in SPL if needed.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Use this new option to control the location of 16-bit init. This will allow
us to place this in SPL if needed.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Add various debug() messages in places where errors occur. This aids with
debugging.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Some files are missing this declaration. Add it to avoid build errors when
we actually need the declaration.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
We should use unsigned long rather than u32 for addresses. Update this so
that the table-generation code builds correctly on 64-bit machines.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
These files now need to be in a standard place so that they can be located
by generic Makefile rules. Move them to the 'lib' directory.
Signed-off-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Alexander Graf <agraf@suse.de>
Highlights this time around:
- Add run time service (power control) support for PSCI (fixed in v3)
- Add efi gop pointer exposure
- SMBIOS support for EFI (on ARM)
- efi pool memory unmap support (needed for 4.8)
- initial x86 efi payload support (fixed up in v2)
- various bug fixes
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQIcBAABAgAGBQJYBx6vAAoJECszeR4D/txgiNwQAJAcdx7m54D+c3juXR3wT3WR
9A0NIkyY9M/lwdG8MRZubaXV6b7s1iZhROvEGN6sZVKe+hR+c8KWbjNC34i/Mzd2
SLFTax+EWiNogSwPxBUG4R5rpPb4UFDreG9ava7L2A07E/zmXlOTJMj8YBPWKUMf
FltmpLFm4lBpm5l/e47f1hotUnRcvwr44dp09G4hjYGh8cdusHeKebwlkyCPhhH7
GwYDI4Reg8dHQqbKNSPaAeK97zE30H+w6kzF4DH1Dl4W9gI9fIlJC3XVajt9qoDz
8CLAMr4ptqnYZlVq+LYPpNDFG9Pkpb78ksCBmolbs/xSo9Nd0s0WRQA6Jvg5oSpu
aVDTJW3qWs3I1zfIDb0maX0yKer8QAm3D99zURxoyjALjNIS4++Tpa6TbgH/KvoQ
Si+ExfGc+MsWFS9K2FMp6ukDhuPypirRF5VsliSXK7kwg2QWQ2DMS9LLgabK3y2e
RxURzy9SJZf6NL7bUmCxvqdQd+S0+5sLJuc8n5sobiBRkvpmABHSelKKDg87C9OW
IYDNI4iHZ1hJZb37Z2LO7R+PAUIX+vbRitnzWSXfXGNstR0Q48I4Lg2Ud1j7xkr2
+uUB0wqbAksaRnDfNNod6hNqBmgueJFK9eVvE2PP1Pl6B83sc6yBDgMNjngQ6hia
7nv3bhAqrnMTPoQkN7C+
=peNm
-----END PGP SIGNATURE-----
Merge tag 'signed-efi-next' of git://github.com/agraf/u-boot
Patch queue for efi - 2016-10-19
Highlights this time around:
- Add run time service (power control) support for PSCI (fixed in v3)
- Add efi gop pointer exposure
- SMBIOS support for EFI (on ARM)
- efi pool memory unmap support (needed for 4.8)
- initial x86 efi payload support (fixed up in v2)
- various bug fixes
Signed-off-by: Tom Rini <trini@konsulko.com>
Conflicts:
include/tables_csum.h
Add the required pieces to support the EFI loader on x86.
Since U-Boot only builds for 32-bit on x86, only a 32-bit EFI application
is supported. If a 64-bit kernel must be booted, U-Boot supports this
directly using FIT (see doc/uImage.FIT/kernel.its). U-Boot can act as a
payload for both 32-bit and 64-bit EFI.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Signed-off-by: Alexander Graf <agraf@suse.de>
The CPU udevice already has a few callbacks to retreive information
about the currently running CPUs. This patch adds a new get_vendor()
call that returns the vendor of the main CPUs.
Signed-off-by: Alexander Graf <agraf@suse.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
For SMBIOS tables we need to know the CPU family as well as CPU IDs. This
patches allocates some space for them in the cpu device and populates it
on x86.
Signed-off-by: Alexander Graf <agraf@suse.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Bring in these functions from Linux v4.4. They will be needed for EFI loader
support.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
These have now landed upstream. The naming is different and in one case the
function signature has changed. Update the code to match.
This applies the following upstream commits by
Thierry Reding <treding@nvidia.com> :
604e61e fdt: Add functions to retrieve strings
8702bd1 fdt: Add a function to get the index of a string
2218387 fdt: Add a function to count strings
Signed-off-by: Simon Glass <sjg@chromium.org>
Fix the hex case and remove unused brackets. Use ~0U instead of ~0UL to
allow compilation on 64-bit machines.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
At present pch_power_options() has the arguments to writel() around the
wrong way. Fix this and update it to compile on 64-bit machines.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Update the configuration to use the new driver. Drop the existing plumbing
code and unused header files.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Update the samus driver to avoid the direct call to the video BIOS setup.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
With this addition, the eMMC device available on the congatec and DFI
BayTrail SoM is detected correctly.
Signed-off-by: Stefan Roese <sr@denx.de>
Cc: Simon Glass <sjg@chromium.org>
Cc: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
arch_cpu_init() can be simpler by this refactoring.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Generally the microcode is combined into a single block only (and removed
from the device tree) when there are multiple blocks. But this is not a
requirement.
Adjust the ivybridge code to avoid assuming this.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Add a debug() at this point to help figure out what is wrong.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Heiko Schocher<hs@denx.de>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
To support the BayTrail internal SIO HS UART, the internal UART clock
needs to get configured. This patch adds support for this clock
configuration which will be done, if the PCI device(s) are found.
Signed-off-by: Stefan Roese <sr@denx.de>
Cc: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
With the change to set up pinctrl after relocation, link fails to boot. Add
a special case in the link code to handle this.
Fixes: d8906c1f (x86: Probe pinctrl driver in cpu_init_r())
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
This introduces quark-specific ACPI global NVS structure, defined in
both C header file and ASL file.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
This introduces baytrail-specific ACPI global NVS structure, defined in
both C header file and ASL file.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: George McCollister <george.mccollister@gmail.com>
Tested-by: George McCollister <george.mccollister@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
There are quite a number of BayTrail boards that uses an external
SuperIO chipset to provide the legacy UART. For such cases, it's
better to have a Kconfig option to enable the internal UART.
So far BayleyBay and MinnowMax boards are using internal UART as
the U-Boot console, enable this on these two boards.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Stefan Roese <sr@denx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
We have drivers for several more devices now, so drop the strings which are
no-longer used.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
There is a dummy pch driver in the coreboot directory. This causes
drivers of its children fail to function due to empty ops. Remove
the whole file since it is no longer needed.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
At present pinctrl driver gets probed in ich6_gpio driver's probe
routine, which has two issues:
- Pin's PADs only gets configured when GPIO driver is probed, which
is not done by default. This leaves the board in a partially
functional state as we must initialize PADs correctly to get
perepherals fully working.
- The probe routine of pinctrl driver is called multiple times, as
normally there are multiple GPIO controllers. It should really
be called just once.
Move the call to syscon_get_by_driver_data() from ich6_gpio driver
to cpu_init_r().
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Stefan Roese <sr@denx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: George McCollister <george.mccollister@gmail.com>
Tested-by: George McCollister <george.mccollister@gmail.com>
So far this is hardcoded to 2, but it should really be read
from the I/O APIC register.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Currently ID 2 is assgined to broadwell I/O APIC, however per
chromebook_samus.dts 2 is the core#2 LAPIC ID. Now we change
I/O APIC ID to 4 to avoid conflict.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
After power-on, both LAPIC and I/O APIC appear with the same APIC ID
zero, which creates an ID conflict. When generating MP table, U-Boot
reports zero as the LAPIC ID in the processor entry, and zero as the
I/O APIC ID in the I/O APIC as well as the I/O interrupt assignment
entries. Such MP table confuses Linux kernel and finally a kernel
panic is seen during boot:
BUG: unable to handle kernel paging request at ffff9000
IP: [<c101d462>] native_io_apic_write+0x22/0x30
*pdpt = 00000000014fb001 *pde = 00000000014ff067 *pte = 0000000000000000
Oops: 0002 [#1]
Modules linked in:
Pid: 1, comm: swapper Tainted: G W 3.8.7 #3 intel galileo/galileo
EIP: 0060:[<c101d462>] EFLAGS: 00010086 CPU: 0
EIP is at native_io_apic_write+0x22/0x30
...
Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000009
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
At present LAPIC is enabled and configured as virtual wire mode
in lapic_setup() only when CONFIG_SMP is on. This limitation is
however not necessary as for uniprocessor this is still needed.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Intel Quark processor core provides an integrated Local APIC but
does not support the IA32_APIC_BASE MSR. As a result, the Local
APIC is always globally enabled and the Local APIC base address
is fixed at 0xfee00000. Attempting to access the IA32_APIC_BASE
MSR causes a general protection fault.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
When SeaBIOS is on, reserve configuration tables in reserve_arch().
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Instead of asking each platform to provide reserve_arch(),
supply it in arch/x86/cpu/cpu.c in a unified way.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
PIRQ routing table checksum is fixed up in copy_pirq_routing_table(),
which is fine if we only write the configuration table once. But with
the SeaBIOS case, when we write the table for the second time, the
checksum will be fixed up to zero per the checksum algorithm, which
is caused by the checksum field not being zero before fix up, since
the checksum has already been calculated in the first run.
To fix this, move the checksum fixup to create_pirq_routing_table(),
so that copy_pirq_routing_table() only does what its function name
suggests: copy the table to somewhere else.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
At present board_final_cleanup() is called before booting a Linux
kernel. This actually needs to be done before booting anything,
like SeaBIOS, VxWorks or Windows.
Move the call to last_stage_init() instead.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Rename qemu/acpi_table.c to qemu/e820.c, because ACPI stuff is moved
to qfw core, this file only contains code for installing e820 table.
Signed-off-by: Miao Yan <yanmiaobest@gmail.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Loading ACPI table from QEMU's fw_cfg interface is not x86 specific
(ARM64 may also make use of it). So move the code to common place.
Signed-off-by: Miao Yan <yanmiaobest@gmail.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Make file names consistent with CONFIG_QFW and CONFIG_CMD_QFW
Signed-off-by: Miao Yan <yanmiaobest@gmail.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
This patch adds some comments about qfw register endianness for clarity.
Signed-off-by: Miao Yan <yanmiaobest@gmail.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
The original implementation of qfw includes several x86 specific
operations, like directly calling outb/inb and using some inline
assembly code which prevents it being ported to other architectures.
This patch adds callback functions and moves those to arch/x86/
Signed-off-by: Miao Yan <yanmiaobest@gmail.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
This patch splits qfw command interface and qfw core function into two
files, and introduces a new Kconfig option (CONFIG_QFW) for qfw core.
Now when qfw command interface is enabled, it will automatically select
qfw core. This patch also makes the ACPI table generation select
CONFIG_QFW.
Signed-off-by: Miao Yan <yanmiaobest@gmail.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
This patch is part of the qfw refactor work.
The qemu_fwcfg_free_files() function is only used in error handling in
ACPI table generation, let's not make this a core function and move it
to the right place.
Signed-off-by: Miao Yan <yanmiaobest@gmail.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
CONFIG_GENENRATE_ACPI_TABLE controls the generation of ACPI table which
uses U-Boot's built-in methods and CONFIG_QEMU_ACPI_TABLE controls whether
to load ACPI table from QEMU's fw_cfg interface.
But with commit "697ec431469ce0a4c2fc2c02d8685d907491af84 x86: qemu: Drop
our own ACPI implementation", there is only one way to support ACPI table
for QEMU targets which is the fw_cfg interface. Having two Kconfig options
for this purpose is not necessary any more, so this patch consolidates
the two.
Signed-off-by: Miao Yan <yanmiaobest@gmail.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
- Move the command portion of arch/x86/cpu/qemu/fw_cfg.c into
cmd/qemu_fw_cfg.c
- Move arch/x86/include/asm/fw_cfg.h to include/qemu_fw_cfg.h
- Rename ACPI table portion to arch/x86/cpu/qemu/acpi_table.c
Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
FADT/MADT tables are platform specific. Generate them for BayTrail.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
By default SCI is disabled after power on. ACTL is the register to
enable SCI and route it to PIC/APIC. To support both ACPI in PIC
mode and APIC mode, configure SCI to use IRQ9.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Stefan Roese <sr@denx.de>
Tested-by: Stefan Roese <sr@denx.de>
Reserve IRQ9 which is to be used as SCI interrupt number
for ACPI in PIC mode.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Stefan Roese <sr@denx.de>
Tested-by: Stefan Roese <sr@denx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Remove asm/acpi.h which is never used.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Stefan Roese <sr@denx.de>
Tested-by: Stefan Roese <sr@denx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
This started as 'ahci' and was renamed to 'disk' during code review. But it
seems that this is too generic. Now that we have a 'blk' uclass, we can use
that as the generic piece, and revert to ahci for this.
Signed-off-by: Simon Glass <sjg@chromium.org>
Our own ACPI implementation (when CONFIG_QEMU_ACPI_TABLE is not set)
does not build anymore after x86 has been fully converted to DM PCI.
Instead of trying to fix the build errors, given we now have the ACPI
support via QEMU's fw_cfg interface, which is a more reliable way to
generate correct ACPI tables than by ourselves, hence drop our own
ACPI implementation.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Update the link script to drop this code when not needed. This is only done
for two architectures at present.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
Sometimes it is useful to jump into U-Boot directly from coreboot or UEFI
without any 16-bit init. This can help during development by allowing U-Boot
to avoid doing all the init required by the platform.
U-Boot expects its GDT to be set up correctly by its 16-bit code. If
coreboot doesn't do this (because it hasn't run the payload setup code yet)
then this won't happen.
In this case we cannot rely on the GDT settings. U-Boot will hang or crash
if these are wrong. Provide a development-only option to set up the GDT
correctly. This is just a hack so you can jump to U-Boot from any stage of
coreboot, not just at the end.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Adjust the existing implementation to use the new common SDRAM init code.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
The code to call the memory reference code is common to several Intel CPUs.
Add common code for performing this init. Intel calls this 'Pre-EFI-Init'
(PEI), where EFI stands for Extensible Firmware Interface.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
The SATA indexed register write functions are common to several Intel PCHs.
Move this into a common location.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Provide a way to determine the HSIO (high-speed I/O) version supported by
the Intel Management Engine (ME) implementation on the platform.
Signed-off-by: Simon Glass <sjg@chromium.org>
Acked-by: Bin Meng <bmeng.cn@gmail.com>
Broadwell uses a binary blob called the memory reference code (MRC) to start
up its SDRAM. This is similar to ivybridge so we can mostly use common code
for running this blob.
Signed-off-by: Simon Glass <sjg@chromium.org>
Acked-by: Bin Meng <bmeng.cn@gmail.com>
Broadwell requires quite a bit of power-management setup. Add code to set
this up correctly.
Signed-off-by: Simon Glass <sjg@chromium.org>
Acked-by: Bin Meng <bmeng.cn@gmail.com>
[squashed in http://patchwork.ozlabs.org/patch/598373/]
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Broadwell needs a special binary blob to set up the PCH. Add code to run
this on start-up.
Signed-off-by: Simon Glass <sjg@chromium.org>
Acked-by: Bin Meng <bmeng.cn@gmail.com>
Add a driver for the broadwell LPC (low-pin-count peripheral). This mostly
uses common code.
Signed-off-by: Simon Glass <sjg@chromium.org>
Acked-by: Bin Meng <bmeng.cn@gmail.com>
Add a driver for the broadwell northbridge. This sets up the location of
several blocks of registers.
Signed-off-by: Simon Glass <sjg@chromium.org>
Acked-by: Bin Meng <bmeng.cn@gmail.com>
Add a SATA driver for broadwell. This supports connecting an SSD and the
usual U-Boot commands to read and write data.
Signed-off-by: Simon Glass <sjg@chromium.org>
Acked-by: Bin Meng <bmeng.cn@gmail.com>
GPIO pins need to be set up on start-up. Add a driver to provide this,
configured from the device tree.
The binding is slightly different from the existing ICH6 binding, since that
is quite verbose. The new binding should be just as extensible.
Signed-off-by: Simon Glass <sjg@chromium.org>
Acked-by: Bin Meng <bmeng.cn@gmail.com>
Add a driver for the broadwell low-power platform controller hub.
Signed-off-by: Simon Glass <sjg@chromium.org>
Acked-by: Bin Meng <bmeng.cn@gmail.com>
This adds the broadwell architecture, with the CPU driver and some useful
header files.
Signed-off-by: Simon Glass <sjg@chromium.org>
Acked-by: Bin Meng <bmeng.cn@gmail.com>
Each CPU needs to have its microcode loaded. Add support for this so that
all CPUs will have the same version.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Enable the microcode feature so that the microcode version is shown with the
'cpu detail' command.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
As each core starts up, record its microcode version and CPU ID so these can
be presented with the 'cpu detail' command.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
At present the MRC options are private to ivybridge. Other Intel CPUs also
use these settings. Move them to a common place.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Some of the Intel ME code is common to several Intel CPUs. Move it into a
common location. Add a header file for report_platform.c also.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
[squashed in http://patchwork.ozlabs.org/patch/598372/]
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
This same name is used in USB. Add a prefix to distinguish it.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Some of the Intel CPU code is common to several Intel CPUs. Move it into a
common location along with required declarations.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Some of the LPC code is common to several Intel LPC devices. Move it into a
common location.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
This is similar to MCH in that it is used in various drivers. Add it to
the common header.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
There are several blocks of registers that are accessed from all over the
code on Intel CPUs. These don't currently have their own driver and it is
not clear whether having a driver makes sense.
An example is the Memory Controller Hub (MCH). We map it to a known location
on some Intel chips (mostly those without FSP - Firmware Support Package).
Add a new header file for these registers, and move MCH into it.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
This code is used on several Intel CPUs. Move it into a common location.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
This cache-as-RAM (CAR) code is common to several Intel chips. Create a new
intel_common directory and move it in there.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
These two identifiers can be useful for drivers which need to adjust their
behaviour depending on the CPU family or stepping (revision).
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
The Intel SIPI (start-up inter-processor interrupt) vector is the entry
point for each secondary CPU (also called an AP - applications processor).
The assembler and C code are linked, so add comments to indicate this.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
The timeout step is always 50us. By updating apic_wait_timeout() to print
the debug messages we can simplify the code. Also tidy up a few messages and
comments while we are here.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Many of the model-specific indexes are common to several Intel CPUs. Add
some more common ones, and remove them from the ivybridge-specific header
file.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
