10 Dec, 2018
7 commits
-
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
Reviewed-by: Christian Gmeiner -
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
Reviewed-by: Bin Meng
Reviewed-by: Christian Gmeiner -
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
Reviewed-by: Simon Glass -
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
Reviewed-by: Simon Glass
Tested-by: Hannes Schmelzer -
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
Reviewed-by: Bin Meng -
Make the indentation aligned with what used elsewhere in U-Boot.
No functional change intended.
Signed-off-by: Andy Shevchenko
Reviewed-by: Bin Meng -
Intel Tangier SoC has RTC inside. So, enable it in ACPI.
Signed-off-by: Andy Shevchenko
Reviewed-by: Bin Meng
05 Dec, 2018
2 commits
-
Microsoft specifies a SPCR (Serial Port Console Redirection Table) [1].
Let's provide it in U-Boot.[1]: https://docs.microsoft.com/en-us/windows-hardware/drivers/serports/serial-port-console-redirection-table
Signed-off-by: Andy Shevchenko
Reviewed-by: Simon Glass -
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
Reviewed-by: Bin Meng
03 Dec, 2018
2 commits
-
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
Reviewed-by: Heinrich Schuchardt
Signed-off-by: Alexander Graf -
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
Signed-off-by: Bin Meng
Reviewed-by: Heinrich Schuchardt
Signed-off-by: Alexander Graf
15 Nov, 2018
3 commits
-
It turns out commit c0434407b595 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: c0434407b595 ("board_f: Use static print_cpuinfo if CONFIG_CPU is active")
Reported-by: Stefan Roese
Signed-off-by: Bin Meng
Reviewed-by: Stefan Roese
Tested-by: Stefan Roese -
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 treeSigned-off-by: Bin Meng
Reviewed-by: Simon Glass -
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
Reviewed-by: Simon Glass
06 Nov, 2018
1 commit
-
New ACPI assembler issues a warning:
board/intel/edison/dsdt.asl.tmp 13: Offset (0x00),
Remark 2158 - ^ Unnecessary/redundant use of Offset operatorIndeed, in the OperationRegion the offset is 0x00 by default.
Thus, drop unneeded Offset() use as suggested by ACPI assembler.
Signed-off-by: Andy Shevchenko
Reviewed-by: Bin Meng
28 Oct, 2018
2 commits
-
Since commit 80df194f0165 ("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 = 0xfff00091Check 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_uninitwe 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_uninitWith this fix, it is normal now.
$ objdump -t u-boot | grep car_uninit
fff00094 w F .text.start 00000001 car_uninitReported-by: Hannes Schmelzer
Signed-off-by: Bin Meng
Tested-by: Heinrich Schuchardt
Reviewed-by: Heinrich Schuchardt
Tested-by: Hannes Schmelzer -
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
Cc: Bin Meng
Cc: Simon Glass
Reviewed-by: Bin Meng
22 Oct, 2018
7 commits
-
Specify X86_TSC_TIMER_EARLY_FREQ for Quark SoC so that TSC as
the early timer can be supported.Signed-off-by: Bin Meng
Reviewed-by: Simon Glass -
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
Reviewed-by: Heinrich Schuchardt -
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: a160092a610f ("x86: Support global_data on x86_64")
Signed-off-by: Heinrich Schuchardt
Reviewed-by: Bin Meng
Tested-by: Bin Meng
Signed-off-by: Bin Meng -
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
Reviewed-by: Bin Meng
Signed-off-by: Bin Meng -
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
Reviewed-by: Heinrich Schuchardt
Reviewed-by: Simon Glass -
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 :
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,%xmm0Executing "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
Reviewed-by: Heinrich Schuchardt
Reviewed-by: Simon Glass -
Once we get a zero pointer from load_zimage(...) we must bunch out
instead of continue boot.Signed-off-by: Hannes Schmelzer
Reviewed-by: Bin Meng
09 Oct, 2018
1 commit
-
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
Reviewed-by: Bin Meng
27 Sep, 2018
1 commit
-
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
26 Sep, 2018
1 commit
-
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
Reviewed-by: Rick Chen
Reviewed-by: Simon Glass
24 Sep, 2018
1 commit
-
Use CONFIG_IS_ENABLED(EFI_LOADER) to avoid explicitly checking CONFIG_SPL
too. This simplifies the conditional.Signed-off-by: Stephen Warren
Signed-off-by: Alexander Graf
17 Sep, 2018
5 commits
-
These comments were copied from the Linux kernel driver in
drivers/platform/x86/intel_scu_ipc.cSigned-off-by: Georgii Staroselskii
Reviewed-by: Andy Shevchenko
Reviewed-by: Bin Meng -
Now that we have I2C#6 working, it's time to add a corresponsing
ACPI binding.Signed-off-by: Georgii Staroselskii
Reviewed-by: Andy Shevchenko
Reviewed-by: Bin Meng -
Now that we have the pinctrl driver for Merrifield in place we can make
use of it and set I2C#6 pins appropriately.Initial configuration came from the firmware. Which quite likely has
been used in the phones, where that is not part of Atom peripheral, is
in use. Thus we need to override the leftover.Signed-off-by: Georgii Staroselskii
Reviewed-by: Andy Shevchenko
Reviewed-by: Bin Meng -
This API is going to be used to configure some pins that are protected
for simple modification.It's not a comprehensive pinctrl driver but can be turned into one
when we need this in the future. Now it is planned to be used only
in one place. So that's why I decided not to pollute the codebase with a
full-blown pinctrl-merrifield nobody will use.This driver reads corresponding fields in DT and configures pins
accordingly.The "protected" flag is used to distinguish configuration of SCU-owned
pins from the ordinary ones.The code has been adapted from Linux work done by Andy Shevchenko
in pinctrl-merrfifield.cSigned-off-by: Georgii Staroselskii
Reviewed-by: Andy Shevchenko
Reviewed-by: Bin Meng
[bmeng: fix build warning]
Signed-off-by: Bin Meng -
This interface will be used to configure properly some pins on
Merrifield that are shared with SCU.scu_ipc_raw_command() writes SPTR and DPTR registers before sending
a command to SCU.This code has been ported from Linux work done by Andy Shevchenko.
Signed-off-by: Georgii Staroselskii
Reviewed-by: Andy Shevchenko
Reviewed-by: Bin Meng
11 Sep, 2018
3 commits
-
In int-ll64.h, we always use the following typedefs:
typedef unsigned int u32;
typedef unsigned long uintptr_t;
typedef unsigned long long u64;This does not need to match to the compiler's .
Do not include it.The use of PRI* makes the code super-ugly. You can simply use
"l" for printing uintptr_t, "ll" for u64, and no modifier for u32.Signed-off-by: Masahiro Yamada
-
All architectures have the same definition for s8/16/32/64
and u8/16/32/64.Factor out the duplicated code into .
BTW, Linux unified the kernel space definition into int-ll64.h
a few years ago as you see in Linux commit 0c79a8e29b5f
("asm/types.h: Remove include/asm-generic/int-l64.h").Signed-off-by: Masahiro Yamada
-
You do not need to use the typedefs provided by compiler.
Our compilers are either IPL32 or LP64. Hence, U-Boot can/should
always use int-ll64.h typedefs like Linux kernel, whatever the
typedefs the compiler internally uses.Signed-off-by: Masahiro Yamada
30 Aug, 2018
3 commits
-
As of today, the proposal of adding "acpi_rsdp_addr" to the kernel
boot protocol does not make its way to the kernel mainline. This
creates some confusion if we leave it in the U-Boot code base.
Remove it for now until we have a clear picture with kernel upstream.Note this eventually does a partial revert to commit 3469bf427454
("x86: zImage: Propagate acpi_rsdp_addr to kernel via boot parameters")Signed-off-by: Bin Meng
Acked-by: Andy Shevchenko
Reviewed-by: Simon Glass -
At present Linux kernel loaded from U-Boot as an EFI payload does
not boot. This fills in kernel's boot params structure with the
required critical EFI information like system table address and
memory map stuff so that kernel can obtain essential data like
runtime services and ACPI table to boot.With this patch, now U-Boot as an EFI payload becomes much more
practical: it is another option of kernel bootloader, ie, can be
a replacement for grub.Signed-off-by: Bin Meng
Reviewed-by: Simon Glass -
This implements payload-specific install_e820_map() to get E820 map
from the EFI memory map descriptors.Signed-off-by: Bin Meng
Reviewed-by: Simon Glass
22 Aug, 2018
1 commit
-
Patch queue for efi - 2018-08-21
A few fixes for 2018.09. Most noticable are:
- unbreak x86 target (-fdata-section fallout)
- fix undefined behavior in a few corner cases
- make Jetson TX1 boot again
- RTS fixes
- implement reset for simple output