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>
New ACPI assembler issues a warning:
board/intel/edison/dsdt.asl.tmp 13: Offset (0x00),
Remark 2158 - ^ Unnecessary/redundant use of Offset operator
Indeed, in the OperationRegion the offset is 0x00 by default.
Thus, drop unneeded Offset() use as suggested by ACPI assembler.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Since commit 80df194f01 ("x86: detect unsupported relocation types"),
an error message is seen on QEMU x86 target during boot:
do_elf_reloc_fixups32: unsupported relocation type 0x1 at fff841f0, offset = 0xfff00087
do_elf_reloc_fixups32: unsupported relocation type 0x2 at fff841f8, offset = 0xfff00091
Check offset 0xfff00087 and 0xfff00091 in the u-boot ELF image,
fff00087 000df401 R_386_32 00000000 car_uninit
fff00091 000df402 R_386_PC32 00000000 car_uninit
we see R_386_32 and R_386_PC32 relocation type is generated for
symbol car_uninit, which is declared as a weak symbol in start.S.
However the actual weak symbol implementation ends up nowhere. As
we can see below, it's *UND*.
$ objdump -t u-boot | grep car_uninit
00000000 w *UND* 00000000 car_uninit
With this fix, it is normal now.
$ objdump -t u-boot | grep car_uninit
fff00094 w F .text.start 00000001 car_uninit
Reported-by: Hannes Schmelzer <hannes@schmelzer.or.at>
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Tested-by: Hannes Schmelzer <oe5hpm@oevsv.at>
To allow bigger 64 bit prefetchable PCI regions in Linux, this patch
changes the base address and range of the ACPI area passed to Linux.
BayTrail can only physically access 36 bit of PCI address space. So
just chaning the range without changing the base address won't work
here, as 0xf.ffff.ffff is already the maximum address.
With this patch, a maximum of 16 GiB of local DDR is supported. This
should be enough for all BayTrail boards though.
Signed-off-by: Stefan Roese <sr@denx.de>
Cc: Bin Meng <bmeng.cn@gmail.com>
Cc: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Specify X86_TSC_TIMER_EARLY_FREQ for Quark SoC so that TSC as
the early timer can be supported.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
At present in arch_setup_gd() it calls printch(' ') at the end which
has been a mystery for a long time as without such call the 64-bit
U-Boot just does not boot at all.
In fact this is due to the bug that board_init_f() was called with
boot_flags not being set. Hence whatever value being there in the
rdi register becomes the boot_flags if without such magic call.
With a printch(' ') call the rdi register is initialized as 0x20
and this value seems to be sane enough for the whole boot process.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
On x86_64 the field global_data_ptr is assigned before relocation. As
sections for uninitialized global data (.bss) overlap with the relocation
sections (.rela) this destroys the relocation table and leads to spurious
errors.
Initialization forces the global_data_ptr into a section for initialized
global data (.data) which cannot overlap any .rela section.
Fixes: a160092a61 ("x86: Support global_data on x86_64")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Tested-by: Bin Meng <bmeng.cn@gmail.com>
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Currently we support only relocations of type ELF64_R_TYPE or ELF32_R_TYPE.
We should be warned if other relocation types appear in the relocation
sections.
This type of message has helped to identify code overwriting a relocation
section before relocation and incorrect parsing of relocation tables.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
With the '-march=core2' fix, it seems that we have some luck that
the 64-bit U-Boot boots again. However if we examine the disassembly
codes there are still SSE instructions elsewhere which means passing
cpu type to GCC is not enough to prevent it from generating these
instructions. A simple test case is doing a 'bootefi selftest' from
the U-Boot shell and it leads to a reset too.
The 'bootefi selftest' reset is even seen with the image created by
the relative older GCC 5.4.0, the one shipped by Ubuntu 16.04.
The reset actually originates from undefined instruction exception
caused by these SSE instructions. To keep U-Boot as a bootloader as
simple as possible, we don't want to handle such advanced SIMD stuff.
To make sure no MMX/SSE instruction sets are generated, tell GCC not
to do this. Note AVX is out of the question as CORE2 is old enough
to support AVX yet.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
With newer kernel.org GCC (7.3.0 or 8.1.0), the u-boot.rom image
built for qemu-x86_64 target does not boot. It keeps resetting
soon after the 32-bit SPL jumps to 64-bit proper. Debugging shows
that the reset happens inside env_callback_init().
000000000113dd85 <env_callback_init>:
113dd85: 41 54 push %r12
113dd87: 55 push %rbp
113dd88: 31 c0 xor %eax,%eax
113dd8a: 53 push %rbx
113dd8b: 0f 57 c0 xorps %xmm0,%xmm0
Executing "xorps %xmm0,%xmm0" causes CPU to immediately reset.
However older GCC like 5.4.0 (the one shipped by Ubuntu 16.04)
does not generate such instructions that utilizes SSE for this
function - env_callback_init() and U-Boot boots without any issue.
Explicitly specifying -march=core2 for newer GCC allows U-Boot
proper to boot again. Examine assembly codes of env_callback_init
and there is no SSE instruction in that function hence U-Boot
continues to boot.
core2 seems to be the oldest arch in GCC that supports 64-bit.
Like 32-bit U-Boot build we use -march=i386 which is the most
conservative cpu type so that the image can run on any x86
processor, let's do the same for the 64-bit U-Boot build.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Once we get a zero pointer from load_zimage(...) we must bunch out
instead of continue boot.
Signed-off-by: Hannes Schmelzer <hannes.schmelzer@br-automation.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
At present the mtrr functions disable the cache before making changes and
enable it again afterwards. This is fine in U-Boot, but does not work if
running in CAR (such as we are in SPL).
Update the functions so that the caller can request that caches be left
alone.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
A lot of goodness in this release. We're *very* close to running the
UEFI Shell and SCT natively. The only missing piece are HII protocols.
- FAT write support (needed for SCT)
- improved FAT directory support (needed for SCT)
- RTC support with QEMU -M virt
- Sandbox support (run UEFI binaries in Linux - yay)
- Proper UTF-16 support
- EFI_UNICODE_COLLATION_PROTOCOL support (for UEFI Shell)
- EFI_SIMPLE_TEXT_INPUT_EX_PROTOCOL support (for UEFI Shell)
- Fix window size determination
- Fix Tegra by explicitly unmapping RAM
- Clean up handle entanglement
- Lots of generic code cleanup
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQIcBAABAgAGBQJbq6+cAAoJECszeR4D/txgV1cP+wZPVsY/kRDwCZ8PODOIyLW/
YWWX0CHOUNIXcvWyrQQVflRKE7IbsoPNU+PxOze/toBZvNGZofCqd/P0sT0kk8UU
/aQ55+Hn8/N4etysKxhk2uszBuEXZsOdprNV3H7tO9vKsMHpImAdLvIyviYK0eCF
WnNsmDVFv/W4M5IWDJrS7KqwTuLPYE5Xli9BW/O2qi8NOvpfyb4EEqdL7OHyHAxe
8zpzyaRXJkPcgPkJ6z3WZ+BmAuXSl5DsLWqfsnZJQzkXatRhT8PneRk787e+xK3A
OEFarj5t/94T1KivxquM9iYi0NzwGWrrCfRzbQh5klV4Z/bRYHbGQ92j6iZyfnpj
0zvWrJCalDaUz310BKZDyzKYQnoDj5/iYaMJHtaG6zmkXCzM41kniGKxuy/3IpTB
ozeFtH2AOwlAFZRIzQiazkyU0bizis2Y/K4xzOQczvVajdLW0DsLXL/hyqaFaGO2
3oVK350FXMHKa1UhpsG05aoQvyYq8N4YVEfOSdBKah8qhhMG8zZ2IaX5oheZJjr4
yPV8iaSj8trX3mI9clsnX9YT7qJdcS188JYSii+8SVpVH4VpgwvUSHfDqznn7JNz
COue6rFo9sg55Le9OsoxUgaQ5GO4oz+5iGmfyBmOtQ3n83JxmP4CJK84Ykw2i9fi
sxJR6aNtktsLhfYhlDO/
=ZuJG
-----END PGP SIGNATURE-----
Merge tag 'signed-efi-next' of git://github.com/agraf/u-boot
Patch queue for efi - 2018-09-26
A lot of goodness in this release. We're *very* close to running the
UEFI Shell and SCT natively. The only missing piece are HII protocols.
- FAT write support (needed for SCT)
- improved FAT directory support (needed for SCT)
- RTC support with QEMU -M virt
- Sandbox support (run UEFI binaries in Linux - yay)
- Proper UTF-16 support
- EFI_UNICODE_COLLATION_PROTOCOL support (for UEFI Shell)
- EFI_SIMPLE_TEXT_INPUT_EX_PROTOCOL support (for UEFI Shell)
- Fix window size determination
- Fix Tegra by explicitly unmapping RAM
- Clean up handle entanglement
- Lots of generic code cleanup
[trini: Fixup merge conflict in include/configs/qemu-arm.h]
Signed-off-by: Tom Rini <trini@konsulko.com>
Now that we already disable the "strict-aliasing" globally, remove
the duplicates in the nds32/riscv/x86 arch-specific Makefiles.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Rick Chen <rick@andestech.com>
Reviewed-by: Simon Glass <sjg@chromium.org>