Now that we are able to get the size of high memory from QEMU,
report its memory range as usable ram.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Aiden Park <aiden.park@intel.com>
At present only size of memory that is below 4GiB is retrieved from
QEMU. Add a function that gets size of memory that is above 4GiB.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Aiden Park <aiden.park@intel.com>
This extracts getting memory size logic in dram_init() to a separate
routine qemu_get_low_memory_size(). No functional changes.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Aiden Park <aiden.park@intel.com>
Every x86 platform provides board_get_usable_ram_top(), hence there
is no need to provide a weak version board_get_usable_ram_top(), not
to mention there is another weak version board_get_usable_ram_top()
in common/board_f.c.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Aiden Park <aiden.park@intel.com>
Using ACPI predefined macros, such as Zero or One, will reduce a binary
size of resulting ACPI tables.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
[bmeng: manually fixed the conflicts when applying]
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
This patch removes the x86 architecture specific GD flags
(GD_FLG_COLD_BOOT & GD_FLG_WARM_BOOT), as they are not used. Only
GD_FLG_COLD_BOOT is referenced in coreboot.c but assigned in start16.S.
But the coreboot target does not use start16.S at all and boots directly
from the 32-bit start code.
Signed-off-by: Stefan Roese <sr@denx.de>
Cc: Bin Meng <bmeng.cn@gmail.com>
Cc: Simon Glass <sjg@chromium.org>
Cc: Tom Rini <trini@konsulko.com>
Cc: Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Tested-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com>
This file contains lots of internal details about the environment. Most
code can include env.h instead, calling the functions there as needed.
Rename this file and add a comment at the top to indicate its internal
nature.
Signed-off-by: Simon Glass <sjg@chromium.org>
Acked-by: Joe Hershberger <joe.hershberger@ni.com>
Reviewed-by: Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com>
[trini: Fixup apalis-tk1.c]
Signed-off-by: Tom Rini <trini@konsulko.com>
This declaration is only used in three files. Although it relates to
malloc() it is actually only used during malloc() init. It uses CONFIG
options including CONFIG_ENV_ADDR which are defined only in environment.h
so this header must be included anyway, for TOTAL_MALLOC_LEN to be
correct.
Nove it to environment.h to simplify the common file.
Signed-off-by: Simon Glass <sjg@chromium.org>
Acked-by: Joe Hershberger <joe.hershberger@ni.com>
Reviewed-by: Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com>
The setting up MTRRs have already been done in previous
Slim Bootloader stages.
Signed-off-by: Aiden Park <aiden.park@intel.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Tested-by: Bin Meng <bmeng.cn@gmail.com>
Add a new device tree which has very minimum nodes
- x86 reset
- x86 tsc_timer
- x86 pci
- Slim Bootloader serial
Signed-off-by: Aiden Park <aiden.park@intel.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Tested-by: Bin Meng <bmeng.cn@gmail.com>
Slim Bootloader already calibrated TSC and provides it to U-Boot.
Therefore, U-Boot does not have to re-calibrate TSC.
Configuring tsc_base and clock_rate makes x86 tsc_timer driver bypass
TSC calibration and use the provided TSC frequency.
- Get TSC frequency from performance info hob
- Set tsc_base and clock_rate for tsc_timer driver
Signed-off-by: Aiden Park <aiden.park@intel.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Tested-by: Bin Meng <bmeng.cn@gmail.com>
Slim Bootloader provides serial port info thru its HOB list pointer.
All these HOBs are eligible for Slim Bootloader based board only.
- Get serial port information from the serial port info HOB
- Leverage ns16550 driver with slimbootloader specific platform data
Signed-off-by: Aiden Park <aiden.park@intel.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Tested-by: Bin Meng <bmeng.cn@gmail.com>
Slim Bootloader provides memory map info thru its HOB list pointer.
Configure memory size and relocation memory from the HOB data, and
provide e820 entries as well.
- Get memory size from the memory map info HOB
- Set available top memory lower than 4GB for U-Boot relocation
- Provide e820 entries from the memory map info HOB
Signed-off-by: Aiden Park <aiden.park@intel.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Tested-by: Bin Meng <bmeng.cn@gmail.com>
FSP (CONFIG_HAVE_FSP) and Slim Bootloader (CONFIG_SYS_SLIMBOOTLOADER)
consume HOB (CONFIG_USE_HOB) data from the each HOB list pointer.
Add a common HOB library in lib/hob.c and include/asm/hob.h.
Signed-off-by: Aiden Park <aiden.park@intel.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Tested-by: Bin Meng <bmeng.cn@gmail.com>
Use existing EFI_GUID and efi_guid_t instead of struct efi_guid.
This is pre-work before making a common HOB library.
- Change 'struct efi_guid' to efi_guit_t
- Remove 'struct efi_guid'
- Define GUIDs with EFI_GUID() macro
- Use guidcmp() instead of compare_guid()
- Remove compare_guid()
Signed-off-by: Aiden Park <aiden.park@intel.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Tested on MinnowMax
Tested-by: Bin Meng <bmeng.cn@gmail.com>
This slimbootloader CPU type is to enable U-Boot as a payload which
runs on top of Slim Bootloader (https://github.com/slimbootloader).
The Slim Bootloader is designed with multi-stage architecture for
the execution from reset vector to OS booting, and supports QEMU,
Apollolake, Whiskeylake and Coffeelake platforms consuming Intel
FSP (https://github.com/IntelFsp) for silicon initialization
including CAR and memory initialization.
The Slim Bootloader generates new HOB (Hand Off Block) which are
serial port info, memory map info, performance data info and so on,
and passes it to a Payload. U-Boot as a payload will use these HOB
information for basic initialization such as serial console.
As an initial commit,
- Add CONFIG_SYS_SLIMBOOTLOADER to enable slimbootloader CPU type
- Add new arch/x86/cpu/slimbootloader directory with minimum codes
- Get hob_list pointer from Slim Bootloader
Signed-off-by: Aiden Park <aiden.park@intel.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Tested-by: Bin Meng <bmeng.cn@gmail.com>
Intel Tangier has a shared DMA controller that, according to Microsoft spec,
has to be presented in CSRT table.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
ACPI has a capability to specify DMA parameters for DMA channel consumers.
To enable this for Intel Edison, describe GP DMA device in ACPI table
in order to get an ACPI handle to it in OS.
This works in conjunction with CSRT, which must be in align with DSDT.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Here is a stub function that generates an empty CSRT. If the target platform
provides acpi_fill_csrt() function, it will be used to populate the table.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Enable SD slot on Intel Edison platform.
By default firmware doesn't put device on active state. Thus,
we have to do this explicitly.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
This struct is not defined in this header file. Add a forward declaration
so that it can be included in any context.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
This breaks Intel Edison to work. It gets laggish and unable to boot kernel.
Reverts commit 665cb18ea6 for now
till better solution will be proposed.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: Bin Meng <bmeng.cn@gmail.com>
coreboot makes it possible to add own entries into coreboot's
table at a per mainboard basis. As there might be some custom
ones it makes sense to provide a way to process them.
Signed-off-by: Christian Gmeiner <christian.gmeiner@gmail.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Add nvdata drivers for the TPM and RTC as used on samus. These are needed
for Chromium OS verified boot on samus.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Add the required CPU code so that TPL builds correctly. Also update the
SPL code to deal with being booted from TPL.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
When TPL finishes it needs to jump to SPL with the stack set up correctly.
Add a function to handle this.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
The early init should only happen once. Update the probe method to
deal with TPL, SPL and U-Boot proper.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
With the use of a phandle we can outdent the device tree nodes a little.
Fix this.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
The standard image generated by U-Boot on x86 is u-boot.rom. Add a
separate image called image.bin for verified boot. This supports
verification in TPL of which SPL/U-Boot to start, then jumping to the
correct one, with SPL setting up the SDRAM and U-Boot proper providing
the user interface if needed.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Add TPL binaries to the device x86 binman desciption. When enabled, TPL
will start first, doing the 16-bit init, then jump to SPL and finally
U-Boot proper.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
This report is normally generated by U-Boot proper. Correct the condition
here so that it respects the Kconfig options for bootstage.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
The MTRRs are normally set up in U-Boot proper, so avoid setting them up
in SPL as well.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Update the Makefie rules to ensure that the correct files are built when
TPL is being used.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
When the MRC cache fails to save it is useful to have some debugging info
to indicate what when wrong. Add some more debug() calls.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
When SPL is used to set up the memory controller we want to save the MRC
data in SPL to avoid needing to pass it up to U-Boot proper to save. Add a
function to handle that.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Add an implementation of arch_cpu_init_f() so that the x86 SPL code builds
and identifies the CPU.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Allow broadwell to build for SPL and include the reference code.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
At present broadwell only supports booting straight into U-Boot proper.
Add a separate init file to boot from SPL into U-Boot proper, and select
it when SPL is in use.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
At present we support having 16-bit init be in SPL or U-Boot proper, but
not TPL. Add support for this so that TPL can boot.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
When a previous phase of U-Boot has run we need to adjust the init of
subsequent states to avoid messing up the CPU state.
Add a new version of the start logic for SPL, when it boots from TPL
(start_from tpl.c) and a new version for U-Boot when it boots from SPL.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Split the CPU init into two parts - the 'full' init which happens in the
first U-Boot phase, and the rest of the init that happens on subsequent
stages.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
At present the debug UART is set up in sdram.c which is not the best place
since it has nothing in particular to do with SDRAM. Since we want to
support initing this in SPL too, move it to a common file.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
[bmeng: added 'broadwell' tag in the commit title]
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
At present, for broadwell, SDRAM is always set up in U-Boot proper since
the 64-bit mode (which uses SDRAM init in SPL) is not supported.
Update the code to allow SDRAM init in SPL instead so that U-Boot proper
can be loaded into SDRAM and run from there. This allows U-Boot to be
compressed to reduce space, since it is not necessary to run it directly
from flash. It could later allow us to support 64-bit U-Boot on broadwell.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Add debugging during SDRAM init so that problems are easier to
diagnose.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Add an arch-specific handoff header so that we can use the HANDOFF feature
on x86 devices.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Some boards want to use TPL as the first phase of U-Boot. This allows
selection of A or B SPL phases, thus allowing the memory init to be
upgraded in the field.
Add a new Kconfig option for this.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
At present only chromebook_link64 supports SPL. It is useful to eb able to
support both TPL and SPL to implement verified boot on x86.
Enable the options for both along with some suitable default options
needed to boot through these phases.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Add labels for these nodes so that board DT files can reference them.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
We cannot init the CPU fully both than once during a boot. Add a new
function which can be called to figure out the CPU identity, but which
does not change anything. For x86_64, this is empty for now.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
At present many of the functions in this file return -1 as an error
number. which is -EPERM. Update the code to use real error numbers.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
We use binman to build the x86 image now. Update a comment which still
refers to ifdtool.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
The x86 code and DT uses "spi-flash" to detect a flash node, switch to
"jedec,spi-nor" in the DTS files and in fdtdec by switching the
GENERIC_SPI_FLASH value to to jedec,spi-nor.
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Reviewed-by: Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com>
Reviewed-by: Jagan Teki <jagan@openedev.com>
This is currently missing and without it the i8254 beeper driver
won't work.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
The pc speaker driven by the i8254 is generic enough to deserve
a single dtsi file to be included by boards that use it.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
The i8254 timer control IO port (0x43) should be setup correctly
by using PIT counter 2 to generate beeps, however in U-Boot other
codes like TSC driver utilizes PIT for TSC frequency calibration
and configures the counter 2 to a different mode that does not
beep. Fix this by always ensuring the PIT counter 2 is correctly
initialized so that the i8254 beeper driver works as expected.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Intel Edison has three UART ports, i.e.
port 0 - Bluetooth
port 1 - auxiliary, available for general purpose use
port 2 - debugging, usually console output is here
Enable all of them for future use.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
The console is actually serial #2. When we would like to enable other ports,
this would be not okay to mess up with the ordering.
Thus, fix the number of default console interface to be 2.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
We may not do an assumption that current console device is always a first
of UCLASS_SERIAL one.
For example, on properly described Intel Edison board the console UART
is a third one.
Use current serial device as described in global data.
Fixes: a61cbad78e ("dm: serial: Adjust serial_getinfo() to use proper API")
Cc: Simon Glass <sjg@chromium.org>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Intel Tangier SoC has a general purpose DMA which can serve to speed up
communications on SPI and I2C serial buses.
Provide DMA descriptors to utilize this capability in the future.
Note, I2C6, which is available to user, has no DMA request lines connected.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Intel Tangier SoC has a general purpose DMA which can serve to speed up
communications on SPI and I2C serial buses.
Provide DMA descriptors to utilize this capability in the future.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Enable sound on samus using the broadwell I2S and an RT5677 audio codec.
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Signed-off-by: Simon Glass <sjg@chromium.org>
Add support for initing the I2C device and ADSP on broadwell. These are
needed for sound to work.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
At present the pinctrl probes the PCH but since it only uses it to obtain
a PCI address, this is no necessary. Avoiding this fixes one of the two
co-dependent loops in broadwell.
This driver really should be a proper pinctrl driver, but for now it
remains a syscon device.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
The Application Digital Signal Processor is used for sound processing with
broadwell. Add a driver to support this.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Adjust the code to allow beeping at different frequencies, using a
calculated value for timer 2.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Add sound support for link, using the HDA codec implementation.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Add a way check to whether HD audio is enabled. Use ioctl() to avoid
adding too many unusual operations to PCH.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
At present these macros give warnings on 64-bit machines and do not
correctly do 32-bit accesses. Update them to use linux types.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
arch/x86/lib/string.c contains assembler implementations of memcpy(),
memmove(), and memset() written for i386. Don't use it on x86_64.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: Alexander Graf <agraf@suse.de>
Basin Cove PMIC is connected to I2C0 bus which is hidden from the OS
and access is going via SCU device, enumerated via PCI.
For now, we add just a minimum support of PMIC device to allow enabling,
e.g. USB OTG, in the OS.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: Bin Meng <bmeng.cn@gmail.com>
It is unnecessary to use a RAM version GDT for 64-bit U-Boot proper.
In fact we can just use the ROM version directly, which not only
eliminates the risk of being overwritten by application, but also
removes the complexity of patching the cpu_call64().
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Before jumping to 64-bit U-Boot proper, SPL copies the cpu_call64()
function to a hardcoded address 0x3000000. This can have potential
conflicts with application usage. Switch the destination address
to be allocated from the heap to avoid such risk.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
At present the 4-level page table base address for 64-bit U-Boot
proper is assigned an address that conflicts with CONFIG_LOADADDR.
Change it to an address within the low memory range instead.
Fixes crashes seen when 'dhcp' on QEMU x86_64 with
"-net nic -net user,tftp=.,bootfile=u-boot".
Reported-by: Alexander Graf <agraf@suse.de>
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Make use of "IMAGE_MAX_SIZE" and "IMAGE_TEXT_BASE" rather than
CONFIG_SPL_MAX_SIZE and CONFIG_SPL_TEXT_BASE. This lets us re-use the
same script for both SPL and TPL. Add logic to scripts/Makefile.spl to
pass in the right value when preprocessing the script.
Cc: Stefano Babic <sbabic@denx.de>
Cc: Fabio Estevam <fabio.estevam@nxp.com>
Cc: Jagan Teki <jagan@openedev.com>
Cc: Maxime Ripard <maxime.ripard@bootlin.com>
Cc: Andreas Bießmann <andreas@biessmann.org>
Cc: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
Cc: Michal Simek <monstr@monstr.eu>
Cc: Daniel Schwierzeck <daniel.schwierzeck@gmail.com>
Cc: York Sun <york.sun@nxp.com>
Cc: Bin Meng <bmeng.cn@gmail.com>
Cc: Heiko Schocher <hs@denx.de>
Cc: Adam Ford <aford173@gmail.com>
Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Daniel Schwierzeck <daniel.schwierzeck@gmail.com>
Tested-by: Daniel Schwierzeck <daniel.schwierzeck@gmail.com>
Tested-by: Adam Ford <aford173@gmail.com> #da850evm & omap3_logic_somlv
Reviewed-by: Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com>
All driver-model functions should have a device as the first parameter.
Update this function accordingly.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
All driver-model functions should have a device as the first parameter.
Update this function accordingly.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Up until now the call to initialize the USB subsystem was hardcoded
for U-Boot running as an EFI payload. This was used to enable the
use of a USB keyboard in the U-Boot shell. However not all boards
might need this functionality. As initializing the USB subsystem can
take a considerable amount of time (several seconds on some boards),
we now initialize the USB subsystem only if U-Boot is configured to
use USB keyboards.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>
Up until now the call to initialize the USB subsystem was hardcoded
for U-Boot running as a coreboot payload. This was used to enable
the use of a USB keyboard in the U-Boot shell. However not all boards
might need this functionality. As initializing the USB subsystem can
take a considerable amount of time (several seconds on some boards),
we now initialize the USB subsystem only if U-Boot is configured to
use USB keyboards.
Signed-off-by: Thomas RIENOESSL <thomas.rienoessl@bachmann.info>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>
At present the Kconfig options (CONFIG_I8259_PIC and CONFIG_APIC)
do not include a prompt message, which makes it impossible to
be disabled from a board defconfig file.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
mask_irq(), unmask_irq() and specific_eoi() are provided by the
i8259 PIC driver and should be wrapped with CONFIG_I8259_PIC.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Hannes Schmelzer <oe5hpm@oevsv.at>
There are still systems running which do not have any LAPIC or even
IOAPIC. Responsible MSRs for those do not exist and the systems are
crashing on trying to setup LAPIC.
This commit makes the APIC stuff able to switch off for those boards
which dont' have an LAPIC / IOAPIC.
Signed-off-by: Hannes Schmelzer <oe5hpm@oevsv.at>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Make the indentation aligned with what used elsewhere in U-Boot.
No functional change intended.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Intel Tangier SoC has RTC inside. So, enable it in ACPI.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Add SPCR table description as it provided in Linux kernel.
Port subtype for ACPI_DBG2_SERIAL_PORT is used as an interface type in SPCR.
Thus, provide a set of definitions to be utilized later.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Per Microsoft PE Format documentation [1], PointerToSymbolTable and
NumberOfSymbols should be zero for an image in the COFF file header.
Currently U-Boot is generating u-boot-app.efi in which these two
members are not zero.
This updates the build rules to tell linker to remove the symbol
table completely so that we can generate compliant *.efi images.
[1] https://docs.microsoft.com/zh-cn/windows/desktop/Debug/pe-format
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: Alexander Graf <agraf@suse.de>
Per Microsoft PE Format documentation [1], PointerToSymbolTable and
NumberOfSymbols should be zero for an image in the COFF file header.
Currently U-Boot is generating u-boot-payload.efi image in which
these two members are not zero.
This updates the build rules to tell linker to remove the symbol
table completely so that we can generate compliant *.efi images.
[1] https://docs.microsoft.com/zh-cn/windows/desktop/Debug/pe-format
Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: Alexander Graf <agraf@suse.de>
It turns out commit c0434407b5 broke some boards which have DM CPU
driver with CONFIG_DISPLAY_CPUINFO option on. These boards just fail
to boot when print_cpuinfo() is called during boot.
Fixes: c0434407b5 ("board_f: Use static print_cpuinfo if CONFIG_CPU is active")
Reported-by: Stefan Roese <sr@denx.de>
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Stefan Roese <sr@denx.de>
Tested-by: Stefan Roese <sr@denx.de>
When a driver declares DM_FLAG_PRE_RELOC flag, it wishes to be
bound before relocation. However due to a bug in the DM core,
the flag only takes effect when devices are statically declared
via U_BOOT_DEVICE(). This bug has been fixed recently by commit
"dm: core: Respect drivers with the DM_FLAG_PRE_RELOC flag in
lists_bind_fdt()", but with the fix, it has a side effect that
all existing drivers that declared DM_FLAG_PRE_RELOC flag will
be bound before relocation now. This may expose potential boot
failure on some boards due to insufficient memory during the
pre-relocation stage.
To mitigate this potential impact, the following changes are
implemented:
- Remove DM_FLAG_PRE_RELOC flag in the driver, if the driver
only supports configuration from device tree (OF_CONTROL)
- Keep DM_FLAG_PRE_RELOC flag in the driver only if the device
is statically declared via U_BOOT_DEVICE()
- Surround DM_FLAG_PRE_RELOC flag with OF_CONTROL check, for
drivers that support both statically declared devices and
configuration from device tree
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
At present the generic io{read,write}{8,16,32} routines only support
MMIO access. With architecture like x86 that has a separate IO space,
these routines cannot be used to access I/O ports.
Implement x86-specific version to support both PIO and MMIO access,
so that drivers for multiple architectures can use these accessors
without the need to know whether it's MMIO or PIO.
These are ported from Linux kernel lib/iomap.c, with slight changes.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
