AM43xx Industrial Development Kit is a new board
based on AM437x line of SoCs. Targetted at Industrial
Automation applications, it comes with EtherCAT, motor
control and other goodies.
Thanks to James Doublesin for all the help.
Cc: James Doublesin <doublesin@ti.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
This regulator is used with AM437x IDK to feed
VDD_MPU, without means to scale VDD_MPU we can't
support higher frequencies.
Signed-off-by: Felipe Balbi <balbi@ti.com>
Make sure that all OPPs are checked on
scale_vcores(). While at that also fix 600MHz
VDD_MPU voltage according to AM437x Data Manual
available at [1].
Table 5-3 on that document, lists all valid
voltages per frequency.
[1] http://www.ti.com/lit/ds/symlink/am4379.pdf
Signed-off-by: Felipe Balbi <balbi@ti.com>
DCDC1 is used as VDD_MPU in all known boards,
let's define all other valid voltages for that
rail so it can be used by our boards.
Signed-off-by: Felipe Balbi <balbi@ti.com>
The frequencies for 25MHz in dpll_per were out of spec for 25MHz,
correct.
Signed-off-by: James Doublesin <doublesin@ti.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Switch to using hardware leveling for certain parameters on the EMIF
rather than using precalculated values. Doing this also means we have a
common place now between am437x and am335x for setting
emif_sdram_ref_ctrl with a value for the correct delay length.
Tested-by: Felipe Balbi <balbi@ti.com>
Tested-by: Tom Rini <trini@ti.com>
Signed-off-by: James Doublesin <doublesin@ti.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Need to provide PLL values for all possible input frequencies (19.2, 24,
25, 26MHz). Values provide are also optimized for jitter (needed
especially for PER PLL and DDR PLL).
Signed-off-by: James Doublesin <doublesin@ti.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Tested-by: Mugunthan V N <mugunthanvnm@ti.com>
Enable GPMC's prefetch feature for NAND access. This speeds up NAND read
access a lot by pre-fetching contents in the background and reading them
through the FIFO address.
The current implementation has two limitations:
a) it only works in 8-bit mode
b) it only supports read access
Both is easily fixable by someone who has hardware to implement it.
Note that U-Boot code uses non word-aligned buffers to read data into, and
request read lengths that are not multiples of 4, so both partial buffers
(head and tail) have to be addressed.
Tested on AM335x hardware.
Tested-by: Guido Martínez <guido@vanguardiasur.com.ar>
Reviewed-by: Guido Martínez <guido@vanguardiasur.com.ar>
Signed-off-by: Daniel Mack <zonque@gmail.com>
[trini: Make apply again, use 'cs' fix pointed out by Guido]
Signed-off-by: Tom Rini <trini@ti.com>
CONFIG_DISPLAY_CPUINFO is already defined in x86-common.h, so remove
it to avoid duplication.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Acked-by: Simon Glass <sjg@chromium.org>
Update README.x86 to include new build instructions for U-Boot as
the coreboot payload and testing considerations with coreboot.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Acked-by: Simon Glass <sjg@chromium.org>
Configure coreboot pci memory regions so that pci device drivers
could work correctly.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Acked-by: Simon Glass <sjg@chromium.org>
cros_ec_board_init() should be called only when CONFIG_CROS_EC is
enabled.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Acked-by: Simon Glass <sjg@chromium.org>
Change SYS_CONFIG_NAME and DEFAULT_DEVICE_TREE to chromebook_link
which is currently the only real board officially supported to run
U-Boot loaded by coreboot.
Note the symbolic link file chromebook_link.dts is deleted and
link.dts is renamed to chromebook_link.dts.
To avoid multiple definition of video_hw_init, the CONFIG_VIDEO_X86
define needs to be moved to arch/x86/cpu/ivybridge/Kconfig.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Acked-by: Simon Glass <sjg@chromium.org>
Since we already swtiched to use the new mechanism for building
U-Boot for coreboot, coreboot.h is no longer needed so remove it.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Acked-by: Simon Glass <sjg@chromium.org>
Move CONFIG_SYS_CAR_ADDR and CONFIG_SYS_CAR_SIZE to Kconfig so that
we don't need them in the board configuration file thus the same
board configuratoin file can be used to build both coreboot version
and bare version.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Acked-by: Simon Glass <sjg@chromium.org>
There are many places in the U-Boot source tree which refer to
CONFIG_SYS_COREBOOT, CONFIG_CBMEM_CONSOLE and CONFIG_VIDEO_COREBOOT
that is currently defined in coreboot.h.
Move them to arch/x86/cpu/coreboot/Kconfig so that we can switch
to board configuration file to build U-Boot later.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Acked-by: Simon Glass <sjg@chromium.org>
In theory U-Boot built for coreboot is supposed to run as a payload
to be loaded by coreboot on every board that coreboot supports.
The U-Boot build process uses SYS_CONFIG_NAME and DEFAULT_DEVICE_TREE
which are hardcoded in board defconfig and Kconfig files. For better
support of coreboot, we want to make these two options configurable
so that we can easily change them during 'make menuconfig' so that
the generated U-Boot image for coreboot is board configuration aware.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Acked-by: Simon Glass <sjg@chromium.org>
When CONFIG_X86_RESET_VECTOR is not selected, specifying the ROM chip
size is meaningless, hence hide it.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Acked-by: Simon Glass <sjg@chromium.org>
Convert CONFIG_X86_RESET_VECTOR and CONFIG_SYS_X86_START16 to Kconfig
options so that we can remove them from board configuration file.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Acked-by: Simon Glass <sjg@chromium.org>
By default U-Boot automatically calibrates TSC running frequency via
MSR and PIT. The calibration may not work on every x86 processor, so
a new Kconfig option CONFIG_TSC_CALIBRATION_BYPASS is introduced to
allow bypassing the calibration and assign a hardcoded TSC frequency
CONFIG_TSC_FREQ_IN_MHZ.
Normally the bypass should be turned on in a simulation environment
like qemu.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Acked-by: Simon Glass <sjg@chromium.org>
If coreboot is built with CONFIG_COLLECT_TIMESTAMPS, use the value
of base_time in coreboot's timestamp table as our timer base,
otherwise TSC counter value will be used.
Sometimes even coreboot is built with CONFIG_COLLECT_TIMESTAMPS,
the value of base_time in the timestamp table is still zero, so
we must exclude this case too (this is currently seen on booting
coreboot in qemu).
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Acked-by: Simon Glass <sjg@chromium.org>
These two are not worth having separate inline functions as they are
really simple, so drop them.
Also changed 'type' parameter of fsp_get_next_hob() from u16 to uint.
Suggested-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Acked-by: Simon Glass <sjg@chromium.org>
It is useful to be able to see the MTRR setup in U-Boot. Add a command
to list the state of the variable MTRR registers and allow them to be
changed.
Update the documentation to list some of the available commands.
This does not support fixed MTRRs as yet.
Signed-off-by: Simon Glass <sjg@chromium.org>
Tested-by: Bin Meng <bmeng.cn@gmail.com>
At present the normal update (which happens much later) does not work. This
seems to have something to do with the 'no eviction' mode in the CAR, or at
least moving the microcode update after that causes it not to work.
For now, do an update early on so that it definitely works. Also refuse to
continue unless the microcode update check (later in boot) is successful.
Signed-off-by: Simon Glass <sjg@chromium.org>
For platforms with CAR we should disable it before relocation. Check if
this function is available and call it if so.
Signed-off-by: Simon Glass <sjg@chromium.org>
Cache-as-RAM should be turned off when we relocate since we want to run from
RAM. Add a function to perform this task.
Signed-off-by: Simon Glass <sjg@chromium.org>
Once we stop running from ROM we should set up the MTTRs to speed up
execution. This is only needed for platforms that don't have an FSP.
Also in the Coreboot case, the MTRRs are set up for us.
Signed-off-by: Simon Glass <sjg@chromium.org>
We should use MTRRs to speed up execution. Add a list of MTRR requests which
will dealt with when we relocate and run from RAM.
We set RAM as cacheable (with write-back) and registers as non-cacheable.
Signed-off-by: Simon Glass <sjg@chromium.org>
For bare platforms we turn off ROM-caching before calling board_init_f_r()
It is then very slow to copy U-Boot from ROM to RAM. So adjust the order so
that the copying happens before we turn off ROM-caching.
Signed-off-by: Simon Glass <sjg@chromium.org>
Set the frame buffer to write-combining. This makes it faster, although for
scrolling write-through is even faster for U-Boot.
Signed-off-by: Simon Glass <sjg@chromium.org>
Memory Type Range Registers are used to tell the CPU whether memory is
cacheable and if so the cache write mode to use.
Clean up the existing header file to follow style, and remove the unneeded
code.
These can speed up booting so should be supported. Add these to global_data
so they can be requested while booting. We will apply the changes during
relocation (in a later commit).
Signed-off-by: Simon Glass <sjg@chromium.org>
This is set up along with CAR (Cache-as-RAM) anyway. When we relocate we
don't really need ROM caching (we read the VGA BIOS from ROM but that is
about it)
Drop it.
Signed-off-by: Simon Glass <sjg@chromium.org>
The hex value is more commonly understood, so use that instead of decimal.
Add a 0x prefix to avoid confusion.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
There are some bits which should be ignored when displaying the mode number.
Make sure that they are not included in the mode that is displayed.
Signed-off-by: Simon Glass <sjg@chromium.org>
There is no need to run with the cache disabled, and there is no point in
clearing the display frame buffer since U-Boot does it later.
Signed-off-by: Simon Glass <sjg@chromium.org>
This takes about about 700ms on link when running natively and 900ms when
running using the emulator. It is a waste of time if video is not enabled,
so don't bother running the video BIOS in that case.
We could add a command to run the video BIOS later when needed, but this is
not considered at present.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
This can be very slow - typically 80ms even on a fast machine since it uses
the SPI flash to read the data. Add an option to display the time taken.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
If the video has not been set up, we should not return a success code. This
can be detected by seeing if any of the variables are non-zero.
Signed-off-by: Simon Glass <sjg@chromium.org>
This currently assumes that U-Boot resides at the start of ROM. Update
it to remove this assumption.
Signed-off-by: Simon Glass <sjg@chromium.org>
Tested-by: Bin Meng <bmeng.cn@gmail.com>
We don't need this in U-Boot since we calculate it based on available memory.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
The Topcliff PCH has 4 UART devices integrated (Device 10, Funciton
1/2/3/4). Add the corresponding device nodes in the crownbay.dts per
Open Firmware PCI bus bindings.
Also a comment block is added for the 'stdout-path' property in the
chosen node, mentioning that by default the legacy superio serial
port (io addr 0x3f8) is still used on Crown Bay as the console port.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Acked-by: Simon Glass <sjg@chromium.org>
Use ePAPR defined properties for x86-uart: clock-frequency and
current-speed. Assign the value of clock-frequency in device tree
to plat->clock of x86-uart instead of using hardcoded number.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Acked-by: Simon Glass <sjg@chromium.org>
There are many pci uart devices which are ns16550 compatible. We can
describe them in the board dts file and use it as the U-Boot serial
console as specified in the chosen node 'stdout-path' property.
Those pci uart devices can have their register be memory-mapped, or
i/o-mapped. The driver will try to use the memory-mapped register if
the reg property in the node has an entry to describe the memory-mapped
register, otherwise i/o-mapped register will be used.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Acked-by: Simon Glass <sjg@chromium.org>
This commit adds several APIs to decode PCI device node according to
the Open Firmware PCI bus bindings, including:
- fdtdec_get_pci_addr() for encoded pci address
- fdtdec_get_pci_vendev() for vendor id and device id
- fdtdec_get_pci_bdf() for pci device bdf triplet
- fdtdec_get_pci_bar32() for pci device register bar
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Acked-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Simon Glass <sjg@chromium.org>
(Include <pci.h> in fdtdec.h and adjust tegra to fix build error)
