| Age | Commit message (Collapse) | Author |
|---|
|
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>
|
|
Signed-off-by: Chris Packham <judge.packham@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
|
|
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>
|
|
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 <andriy.shevchenko@linux.intel.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
|
|
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 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 <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 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 = 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: a160092a610f ("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>
|
|
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>
|
|
Use CONFIG_IS_ENABLED(EFI_LOADER) to avoid explicitly checking CONFIG_SPL
too. This simplifies the conditional.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Alexander Graf <agraf@suse.de>
|
|
These comments were copied from the Linux kernel driver in
drivers/platform/x86/intel_scu_ipc.c
Signed-off-by: Georgii Staroselskii <georgii.staroselskii@emlid.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
|
|
Now that we have I2C#6 working, it's time to add a corresponsing
ACPI binding.
Signed-off-by: Georgii Staroselskii <georgii.staroselskii@emlid.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
|
|
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 <georgii.staroselskii@emlid.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
|
|
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.c
Signed-off-by: Georgii Staroselskii <georgii.staroselskii@emlid.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
[bmeng: fix build warning]
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
|
|
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 <georgii.staroselskii@emlid.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
|
|
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 <inttypes.h>.
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 <yamada.masahiro@socionext.com>
|
|
All architectures have the same definition for s8/16/32/64
and u8/16/32/64.
Factor out the duplicated code into <asm-generic/int-ll64.h>.
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 <yamada.masahiro@socionext.com>
|
|
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 <yamada.masahiro@socionext.com>
|
|
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 <bmeng.cn@gmail.com>
Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
|
