upstream u-boot with additional patches for our devices/boards: https://lists.denx.de/pipermail/u-boot/2017-March/282789.html (AXP crashes) ; Gbit ethernet patch for some LIME2 revisions ; with SPI flash support
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
u-boot/arch/x86/include/asm/global_data.h

101 lines
2.3 KiB

/*
* (C) Copyright 2002-2010
* Wolfgang Denk, DENX Software Engineering, wd@denx.de.
*
* SPDX-License-Identifier: GPL-2.0+
*/
#ifndef __ASM_GBL_DATA_H
#define __ASM_GBL_DATA_H
#ifndef __ASSEMBLY__
enum pei_boot_mode_t {
PEI_BOOT_NONE = 0,
PEI_BOOT_SOFT_RESET,
PEI_BOOT_RESUME,
};
x86: ivybridge: Implement SDRAM init Implement SDRAM init using the Memory Reference Code (mrc.bin) provided in the board directory and the SDRAM SPD information in the device tree. This also needs the Intel Management Engine (me.bin) to work. Binary blobs everywhere: so far we have MRC, ME and microcode. SDRAM init works by setting up various parameters and calling the MRC. This in turn does some sort of magic to work out how much memory there is and the timing parameters to use. It also sets up the DRAM controllers. When the MRC returns, we use the information it provides to map out the available memory in U-Boot. U-Boot normally moves itself to the top of RAM. On x86 the RAM is not generally contiguous, and anyway some RAM may be above 4GB which doesn't work in 32-bit mode. So we relocate to the top of the largest block of RAM we can find below 4GB. Memory above 4GB is accessible with special functions (see physmem). It would be possible to build U-Boot in 64-bit mode but this wouldn't necessarily provide any more memory, since the largest block is often below 4GB. Anyway U-Boot doesn't need huge amounts of memory - even a very large ramdisk seldom exceeds 100-200MB. U-Boot has support for booting 64-bit kernels directly so this does not pose a limitation in that area. Also there are probably parts of U-Boot that will not work correctly in 64-bit mode. The MRC is one. There is some work remaining in this area. Since memory init is very slow (over 500ms) it is possible to save the parameters in SPI flash to speed it up next time. Suspend/resume support is not fully implemented, or at least it is not efficient. With this patch, link boots to a prompt. Signed-off-by: Simon Glass <sjg@chromium.org>
10 years ago
struct memory_area {
uint64_t start;
uint64_t size;
};
struct memory_info {
int num_areas;
uint64_t total_memory;
uint64_t total_32bit_memory;
struct memory_area area[CONFIG_NR_DRAM_BANKS];
};
#define MAX_MTRR_REQUESTS 8
/**
* A request for a memory region to be set up in a particular way. These
* requests are processed before board_init_r() is called. They are generally
* optional and can be ignored with some performance impact.
*/
struct mtrr_request {
int type; /* MTRR_TYPE_... */
uint64_t start;
uint64_t size;
};
/* Architecture-specific global data */
struct arch_global_data {
struct global_data *gd_addr; /* Location of Global Data */
uint8_t x86; /* CPU family */
uint8_t x86_vendor; /* CPU vendor */
uint8_t x86_model;
uint8_t x86_mask;
uint32_t x86_device;
uint64_t tsc_base; /* Initial value returned by rdtsc() */
uint32_t tsc_base_kclocks; /* Initial tsc as a kclocks value */
uint32_t tsc_prev; /* For show_boot_progress() */
uint32_t tsc_mhz; /* TSC frequency in MHz */
void *new_fdt; /* Relocated FDT */
uint32_t bist; /* Built-in self test value */
enum pei_boot_mode_t pei_boot_mode;
const struct pch_gpio_map *gpio_map; /* board GPIO map */
x86: ivybridge: Implement SDRAM init Implement SDRAM init using the Memory Reference Code (mrc.bin) provided in the board directory and the SDRAM SPD information in the device tree. This also needs the Intel Management Engine (me.bin) to work. Binary blobs everywhere: so far we have MRC, ME and microcode. SDRAM init works by setting up various parameters and calling the MRC. This in turn does some sort of magic to work out how much memory there is and the timing parameters to use. It also sets up the DRAM controllers. When the MRC returns, we use the information it provides to map out the available memory in U-Boot. U-Boot normally moves itself to the top of RAM. On x86 the RAM is not generally contiguous, and anyway some RAM may be above 4GB which doesn't work in 32-bit mode. So we relocate to the top of the largest block of RAM we can find below 4GB. Memory above 4GB is accessible with special functions (see physmem). It would be possible to build U-Boot in 64-bit mode but this wouldn't necessarily provide any more memory, since the largest block is often below 4GB. Anyway U-Boot doesn't need huge amounts of memory - even a very large ramdisk seldom exceeds 100-200MB. U-Boot has support for booting 64-bit kernels directly so this does not pose a limitation in that area. Also there are probably parts of U-Boot that will not work correctly in 64-bit mode. The MRC is one. There is some work remaining in this area. Since memory init is very slow (over 500ms) it is possible to save the parameters in SPI flash to speed it up next time. Suspend/resume support is not fully implemented, or at least it is not efficient. With this patch, link boots to a prompt. Signed-off-by: Simon Glass <sjg@chromium.org>
10 years ago
struct memory_info meminfo; /* Memory information */
#ifdef CONFIG_HAVE_FSP
void *hob_list; /* FSP HOB list */
#endif
struct mtrr_request mtrr_req[MAX_MTRR_REQUESTS];
int mtrr_req_count;
int has_mtrr;
/* MRC training data to save for the next boot */
char *mrc_output;
unsigned int mrc_output_len;
void *gdt; /* Global descriptor table */
};
#endif
#include <asm-generic/global_data.h>
#ifndef __ASSEMBLY__
static inline __attribute__((no_instrument_function)) gd_t *get_fs_gd_ptr(void)
{
gd_t *gd_ptr;
asm volatile("fs movl 0, %0\n" : "=r" (gd_ptr));
return gd_ptr;
}
#define gd get_fs_gd_ptr()
#endif
/*
* Our private Global Data Flags
*/
#define GD_FLG_COLD_BOOT 0x00100 /* Cold Boot */
#define GD_FLG_WARM_BOOT 0x00200 /* Warm Boot */
#define DECLARE_GLOBAL_DATA_PTR
#endif /* __ASM_GBL_DATA_H */