board_get_usable_ram_top() returns a physical address that is stored in
gd->ram_top. The return type of the function should be phys_addr_t like the
current type of gd->ram_top.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
These files rely on the config.h file provided this include. Add it
explictily so we can move to a text environment.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> # Intel Edison
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
This is needed for this file, so include it here explicitly.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> # Intel Edison
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
This is only used in one file and the value is the same for both boards
which define it. Use the fixed value of 32KB and drop the CFG. This will
allow removal of the config.h files.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> # Intel Edison
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
This is copying beyond the end of the destination buffer. Correct the code
by using the size of the vesa_mode_info struct. We don't need to copy the
rest of the bytes in the buffer.
This long-standing bug prevents virtio bootdevs working correctly on
qemu-x86 at present.
Fixes: 0ca2426bea ("x86: Add support for running option ROMs natively")
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Tested-by: Bin Meng <bmeng.cn@gmail.com> # qemu-x86_64
Unfortunately the bochs driver does not currently work with distros.
It causes a hang between grub menu selection and the OS displaying
something.
Preliminary investigation shows that GRUB does not jump to the kernel
at all.
This reproduces reliably.
This reverts commit b8956425d5.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Tested-by: Bin Meng <bmeng.cn@gmail.com> # qemu-x86_64
[Slightly modify the commit message about preliminary investigation]
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Call the hardware-init function from QEMU from SPL. This allows the
video BIOS to operate correctly.
Create an x86-wide qemu.h header to avoid having to #ifdef the header
in spl.c
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Tested-by: Bin Meng <bmeng.cn@gmail.com> # qemu-x86_64
Show the number of records in the table and the total table size in
bytes.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
This function used to be for adding a list of requests to be actioned on
relocation. Revert it back to this purpose, to avoid problems with boards
which need control of their MTRRs (i.e. those which don't use FSP).
The mtrr_set_next_var() function is available when the next free
variable-MTRR must be set, so this can be used instead.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Fixes: 3bcd6cf89e ("x86: mtrr: Skip MSRs that were already programmed..")
Fixes: 596bd0589a ("x86: mtrr: Do not clear the unused ones..")
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
At present this uses mtrr_add_request() & mtrr_commit() combination
to program the MTRR for graphics memory. This usage has two major
issues as below:
- mtrr_commit() will re-initialize all MTRR registers from index 0,
using the settings previously added by mtrr_add_request() and saved
in gd->arch.mtrr_req[], which won't cause any issue but is unnecessary
- The way such combination works is based on the assumption that U-Boot
has full control with MTRR programming (e.g.: U-Boot without any blob
that does all low-level initialization on its own, or using FSP2 which
does not touch MTRR), but this is not the case with FSP. FSP programs
some MTRRs during its execution but U-Boot does not have the settings
saved in gd->arch.mtrr_req[] and when doing mtrr_commit() it will
corrupt what was already programmed previously.
Correct this to use mtrr_set_next_var() instead.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
On Coral U-Boot SPL programs some MTRRs and FSPv2 in U-Boot proper
needs to program MTRRs too. With current testing logic of mtrr
commit in init_cache_f_r(), the mtrr commit is skipped which won't
work as the queued mtrr requests include setup for DRAM regions.
Change the logic to allow such configuration.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Tweak to put back CONFIG_FSP_VERSION2 at top:
Signed-off-by: Simon Glass <sjg@chromium.org>
This is more convenient since it does not require a video BIOS. Enable
it for QEMU.
Also drop use of video in SPL for the 64-bit QEMU, since it not needed
now.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Some boards need to access GPIOs to determine which SDRAM is fitted to the
board, for example chromebook_link. Probe this device (if it exists) to
make sure that this works as expected.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Add the required tag so that micron memory can be set up correctly.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Move from using debug() to log_debug() so that we don't have to use the
__func__ parameter and can access other logging features.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
The ACPI tables are special in that they are passed to EFI as a separate
piece, independent of other tables.
Also they can be spread over two areas of memory, e.g. with QEMU we end
up with tables kept in high memory as well.
Add new global_data fields to hold this information and update the bdinfo
command to show the table areas.
Move the rom_table_end variable into the loop that uses it.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
The implementation of write_tables() is confusing because it uses the
rom_table_start variable as the address pointer as it progresses.
Rename it to rom_addr to make the code clearer. Move the rom_table_end
variable into the block where it is used.
Also update logging to use the ACPI category, now that it is available.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
When global_data is relocated, log_head moves in memory, meaning that
the items in that list point to the wrong place.
Disable logging when making the change, then reenable it afterwards, so
that logging works normally.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
When video is required in SPL, set this up ready for use. Ignore any
problems since it may be that video is not actually available and we
still want to continue on to U-Boot proper in that case.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Print the banner in SPL init only if the spl_board_init() function isn't
enabled. The spl_board_init() function is in the same file, but is called
later, by board_init_r().
This avoids printing two banners, which causes tests to fail.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
With qemu-x86_64 we need to run the video BIOS while in 32-bit mode, i.e.
SPL. Add a Kconfig option for this, adjust the Makefile rules and use
CONFIG_IS_ENABLED() where needed.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
At present this leaves the stack at the pre-relocation value. This is not
ideal since we want to have U-Boot running entirely from the top of
memory.
In addition, the new global_data pointer is not actually used, since
the global_data pointer itself is relocated, then the pre-relocation value
is changed, so the effective value (after relocation) does not update.
Adjust the implementation to follow the 32-bit code more closely, with a
trampoline function which is passed the new stack and global_data pointer.
This ensures that the correct values come through even when relocating.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Rather than silently hanging, show an error first. This can happen when
there is something wrong with the video BIOS.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Use an assembler implementation as is done for i386, so that the results
are equivalent for i386 and x86_64.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
This is useful information so show it with the bdinfo command.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Add a comment for this function in the header.
Change the function (and the one after) to use __noreturn to keep
checkpatch happy.
Add docs to board_init_f_r() while we are here.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
The ll_boot_init() check handles the EFI case so we don't need the rest
of the code. Drop it.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Move MTRR-listing code into a common file so it can be used from SPL.
Update the 'mtrr' command to call it.
Use this in SPL just before adjusting the MTRRs, so we can see the state
set up by the board. Only show it when debug is enabled.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Allow reading the command line from a zimage, so that it can be recorded
in the bootflow.
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Signed-off-by: Simon Glass <sjg@chromium.org>
Add a direct interface to booting a zimage, so that bootstd can call it
without going through the command-line interface.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
After Linux commit ff61f0791ce9, x86 documentation was moved to
arch/x86 and the link in bootparam.h was broken.
Signed-off-by: Paul Barker <paul.barker.ct@bp.renesas.com>
Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
These are not used in TPL so disable the drivers to save space.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
This copies the cpu_call64() function to memory address and then jumps to
it. This seems to work correctly even when called from SPL, which is
running from SPI flash.
Drop the copy as it is not needed.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
We don't need to commit the SPI-flash MTRR change immediately, since it is
now done in the board_init_f_r(). Also this causes chromebook_link64 to
hang, presumably since we are still running from CAR (Cache-as-RAM) in
SPL. Coral handles this OK, perhaps since it is running from a different
memory area, but it has no effect on Coral anyway.
Drop the extra mtrr_commit() in the SPL implementation.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
This function is used by U-Boot proper. It does not set up MTRRs when SPL
is enabled, but we do want this done when it is called from SPL. In fact
it is confusing to use the same function from SPL, since there are quite
a few conditions there.
All init_cache_f_r() really does is commit the MTRRs and set up the cache.
Do this in the SPL's version of this function instead.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Use the binman symbols for this, to avoid hard-coding the value. We could
use CONFIG_X86_OFFSET_U_BOOT for the address, but it seems better to
obtain the offset and size through the same mechanism.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Show the area of memory cleared for BSS, when debugging is enabled.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
SPL printf() does not normally support %#x so just use %x instead. Hex is
expected in U-Boot anyway.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
For now, just enable the fast-but-large string functions in 32-boot
U-Boot proper only. Avoid using them in SPL. We cannot use then in 64-bit
builds since we only have 32-bit assembly.
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Signed-off-by: Simon Glass <sjg@chromium.org>
The debug UART is already set up in SPL, so there is no need to do
anything here. We must provide the (empty) function though.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
The bd82x6x_get_gpio_base() does not work if the LPC is not set up.
Probe it early to avoid this problem.
In chromebook_link64 this problem shows up as an inability to read
the GPIO straps for the memory type.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
The original function was only called once, before relocation. The new
one is called again after relocation. This was not the intent of the
original call. Fix this by renaming and updating the calling logic.
With this, chromebook_link64 makes it through SPL.
Fixes: 7fe32b3442 ("event: Convert arch_cpu_init_dm() to use events")
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Sometimes coreboot adds new tags that U-Boot does not know about. These
are silently ignored, but it is useful to at least know what we are
missing.
Add a way to collect this information. For Brya it shows:
Unimpl. 38 41 37 34 42 40
These are:
LB_TAG_PLATFORM_BLOB_VERSION
LB_TAG_ACPI_CNVS
LB_TAG_FMAP
LB_TAG_VBOOT_WORKBUF
LB_TAG_TYPE_C_INFO
LB_TAG_BOARD_CONFIG
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Tested-by: Bin Meng <bmeng.cn@gmail.com>
At present any ACPI tables created by prior-stage firmware are ignored.
It is useful to be able to view these in U-Boot.
Pick this up from the sysinfo tables and display it with the cbsysinfo
command. This allows the 'acpi list' command to work when booting from
coreboot.
Adjust the global_data condition so that acpi_start is available even if
table-generation is disabled.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Tested-by: Bin Meng <bmeng.cn@gmail.com>
Avoid searching starting at 0 since this memory may not be available,
e.g. if protection against NULL-pointer access is enabled. The table
cannot be there anyway, since the first 1KB of memory was originally
used for the interrupt table and coreboot avoids it.
Start at 0x400 instead.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
CONFIG_IS_ENABLED(SPL_X86_32BIT_INIT)
would check for CONFIG_SPL_SPL_X86_32BIT_INIT for SPL builds
Signed-off-by: Troy Kisky <troykiskyboundary@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
