print_cpuinfo() in board init code requires uclass CPU driver,
add it to be able to display CPU info when CONFIG_DISPLAY_CPUINFO
option is enabled. CPU node in DT will have to include 'clocks'
and 'u-boot,dm-pre-reloc' properties for generic print_cpuinfo()
to work as expected. The driver outputs info for i.MX8QXP Rev A
and Rev B CPUs.
Signed-off-by: Anatolij Gustschin <agust@denx.de>
Cc: Stefano Babic <sbabic@denx.de>
Reviewed-by: Peng Fan <peng.fan@nxp.com>
Add arch_cpu_init(_dm) mainly to open the channel between ACore and SCU.
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Reviewed-by: Anatolij Gustschin <agust@denx.de>
Cc: Stefano Babic <sbabic@denx.de>
Add mmu memmap, some memory regions are reserved by M4, Arm Trusted
Firmware, so need to get memreg using SCFW API and setup the memmap.
Add dram_init, dram_init_banksize, get_effective_memsize functions,
according to the memreg.
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Reviewed-by: Anatolij Gustschin <agust@denx.de>
Cc: Stefano Babic <sbabic@denx.de>
Add basic cpu support, including cpu revision, cpu type,
cpu core detection.
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Reviewed-by: Anatolij Gustschin <agust@denx.de>
Cc: Stefano Babic <sbabic@denx.de>
Add imx-regs header file to include the register base definition
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Reviewed-by: Anatolij Gustschin <agust@denx.de>
Cc: Stefano Babic <sbabic@denx.de>
Add clk/misc/pad/pm/rm scfw api implementaion for different
drivers to invoke. The low level code is using misc_call
to invoke imx8_scu driver.
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Reviewed-by: Anatolij Gustschin <agust@denx.de>
Cc: Stefano Babic <sbabic@denx.de>
Add i.MX8 MISC driver to handle the communication between
A35 Core and SCU.
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Reviewed-by: Anatolij Gustschin <agust@denx.de>
Cc: Stefano Babic <sbabic@denx.de>
Add scu_dev for i.MX8, this will be used as a handle
to communite with SCU from A35.
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Reviewed-by: Anatolij Gustschin <agust@denx.de>
Cc: Stefano Babic <sbabic@denx.de>
Add qemu-x86_64 to the list of targets we use for test.py runs.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
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>
So far the TSC timer driver supports trying hardware calibration first
and using device tree as last resort for its running frequency as the
normal timer.
However when it is used as the early timer, it only supports hardware
calibration and if it fails, the driver just panics. This introduces
a new config option to specify the early timer frequency in MHz and
it should be equal to the value described in the device tree.
Without this patch, the travis-ci testing on QEMU x86_64 target fails
each time after it finishes the 'bootefi selftest' as the test.py see
an error was emitted on the console like this:
TSC frequency is ZERO
resetting ...
### ERROR ### Please RESET the board ###
It's strange that this error is consistently seen on the travis-ci
machine, but only occasionally seen on my local machine (maybe 1 out
of 10). Since QEMU x86_64 target enables BOOTSTAGE support which uses
early timer, with this fix it should work without any failure.
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>
Since commit 380d4f787a ("rtc: Allow use of RTC in SPL and TPL")
qemu-x86_64_defconfig does not boot anymore.
Fixes: 380d4f787a ("rtc: Allow use of RTC in SPL and TPL")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
There are some sections in current doc saying 64-bit is unsupported.
This apparently is out of date. Remove it.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Currently only 32-bit U-Boot for QEMU x86 is documented. Mention
the 64-bit support.
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 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>
In initr_bootstage() we call bootstage_mark_name() which ends up calling
timer_get_us(). This call happens before initr_dm(), which inits driver
model.
On x86 we set gd->timer to NULL in the transition from board_init_f()
to board_init_r(). See board_init_f_r() for this assignment. So U-Boot
knows there is no timer available in the period immediately after
relocation.
On x86 the timer_get_us() call is implemented as calls to get_ticks() and
get_tbclk(). Both of these call dm_timer_init() to set up the timer, if
gd->timer is NULL and the early timer is not available.
However dm_timer_init() cannot succeed before initr_dm() is called.
So it seems that on x86 if we want to use CONFIG_BOOTSTAGE we must enable
CONFIG_TIMER_EARLY. Update the Kconfig to handle this.
Note: On most architectures we can rely on the pre-relocation memory still
being available, so that gd->timer pointers to a valid timer device and
everything works correctly. Admittedly this is not strictly correct since
the timer device is set up by pre-relocation U-Boot, but normally this is
fine. On x86 the 'CAR' (cache-as-RAM) memory used by pre-relocation U-Boot
disappears in board_init_f_r() and any attempt to access it will hang.
This is the reason why we must mark the timer as invalid when we get to
board_init_f_r().
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Some platforms use this instead of FSP to set up the platform, including
memory. Add support for this in binman. This is needed for
chromebook_samus, for example.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
With bootstage now allocating pre-relocation memory the current amount
available is insufficient. Increase it a little.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Add test which checks if a PCI device described in DT with an
entry and reg = <...> property, but without compatible string
results in a valid U-Boot PCI udevice with the udevice.node
populated with reference to this DT node. Also check if the
other PCI device without a DT node does not contain any bogus
udevice.node.
Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
Cc: Simon Glass <sjg@chromium.org>
Cc: Tom Rini <trini@konsulko.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Add PCI entry without compatible string and with a DT node only with
reg = <...> property into the DT. This is needed for the tests to
verify whether such a setup creates an U-Boot PCI device with the
DT node associated with it in udevice.node.
Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
Cc: Simon Glass <sjg@chromium.org>
Cc: Tom Rini <trini@konsulko.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Reword the documentation to make it clear the compatible string is now
optional, yet still matching on it takes precedence over PCI IDs and
PCI classes.
Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
Cc: Simon Glass <sjg@chromium.org>
Cc: Tom Rini <trini@konsulko.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
The PCI controller can have DT subnodes describing extra properties
of particular PCI devices, ie. a PHY attached to an EHCI controller
on a PCI bus. This patch parses those DT subnodes and assigns a node
to the PCI device instance, so that the driver can extract details
from that node and ie. configure the PHY using the PHY subsystem.
Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
Cc: Simon Glass <sjg@chromium.org>
Cc: Tom Rini <trini@konsulko.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
This converts the following to Kconfig:
CONFIG_FLASH_CFI_DRIVER
CONFIG_SYS_FLASH_USE_BUFFER_WRITE
CONFIG_FLASH_CFI_MTD
CONFIG_SYS_FLASH_PROTECTION
CONFIG_SYS_FLASH_CFI
Signed-off-by: Adam Ford <aford173@gmail.com>
[trini: Re-migrate]
Signed-off-by: Tom Rini <trini@konsulko.com>
To make testing with clang support easier, add sandbox/clang-7
combination to our testing matrix. To facilitate this, switch to using
the "sources" method that the travis.yml file supports to list
additional repositories and add the official one for llvm-7. Due to
buildman not supporting using clang at this time add logic to manually
build a single sandbox configuration in the expected output directory so
that we can still invoke all of our tests.
Cc: Simon Glass <sjg@chromium.org>
Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Add new Kconfig option, SYS_BOOTCOUNT_MAGIC, to select the boot
counter magic word. This can be useful ie. in case the entire
boot counter register is not usable.
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Tom Rini <trini@konsulko.com>
Currently this uses x86_64 version toolchain for x86 build in
travis-ci. Change it to i386 version to avoid updating the
buildman toolchain path every time when the toolchain version
number is changed, eg: from 7.3.0 to 8.1.0.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
This value is unly used in arch/arm/mach-omap2/am33xx/
clock_am33xx.c, so let's make it dependent on AM33XX since
that is the only way this file gets compiled into the code
according to the Makefile.
Signed-off-by: Adam Ford <aford173@gmail.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
[trini: Fix symbol name]
Signed-off-by: Tom Rini <trini@konsulko.com>
