Whitebox
/
u-boot
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity
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.
53086 Commits
3 Branches
0 Tags
148 MiB
Tag: Branch: Tree: lime2-spi
Branches Tags
${ item.name }
Create tag ${ searchTerm }
Create branch ${ searchTerm }
from 'lime2-spi'
${ noResults }
u-boot/arch/x86/include/asm/post.h

55 lines
1.2 KiB
Raw Permalink Normal View History Unescape

SPDX: Convert all of our single license tags to Linux Kernel style When U-Boot started using SPDX tags we were among the early adopters and there weren't a lot of other examples to borrow from. So we picked the area of the file that usually had a full license text and replaced it with an appropriate SPDX-License-Identifier: entry. Since then, the Linux Kernel has adopted SPDX tags and they place it as the very first line in a file (except where shebangs are used, then it's second line) and with slightly different comment styles than us. In part due to community overlap, in part due to better tag visibility and in part for other minor reasons, switch over to that style. This commit changes all instances where we have a single declared license in the tag as both the before and after are identical in tag contents. There's also a few places where I found we did not have a tag and have introduced one. Signed-off-by: Tom Rini <trini@konsulko.com>
6 years ago
/* SPDX-License-Identifier: GPL-2.0+ */
x86: Emit post codes in startup code for Chromebooks On x86 it is common to use 'post codes' which are 8-bit hex values emitted from the code and visible to the user. Traditionally two 7-segment displays were made available on the motherboard to show the last post code that was emitted. This allows diagnosis of a boot problem since it is possible to see where the code got to before it died. On modern hardware these codes are not normally visible. On Chromebooks they are displayed by the Embedded Controller (EC), so it is useful to emit them. We must enable this feature for the EC to see the codes, so add an option for this. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
10 years ago
/*
* Copyright (c) 2014 Google, Inc
*/
#ifndef _post_h
#define _post_h
/* port to use for post codes */
#define POST_PORT 0x80
/* post codes which represent various stages of init */
#define POST_START 0x1e
#define POST_CAR_START 0x1f
x86: chromebook_link: Implement CAR support (cache as RAM) Add support for CAR so that we have memory to use prior to DRAM init. On link there is a total of 128KB of CAR available, although some is used for the memory reference code. Signed-off-by: Simon Glass <sjg@chromium.org>
10 years ago
#define POST_CAR_SIPI 0x20
#define POST_CAR_MTRR 0x21
#define POST_CAR_UNCACHEABLE 0x22
#define POST_CAR_BASE_ADDRESS 0x23
#define POST_CAR_MASK 0x24
#define POST_CAR_FILL 0x25
#define POST_CAR_ROM_CACHE 0x26
#define POST_CAR_MRC_CACHE 0x27
#define POST_CAR_CPU_CACHE 0x28
x86: Emit post codes in startup code for Chromebooks On x86 it is common to use 'post codes' which are 8-bit hex values emitted from the code and visible to the user. Traditionally two 7-segment displays were made available on the motherboard to show the last post code that was emitted. This allows diagnosis of a boot problem since it is possible to see where the code got to before it died. On modern hardware these codes are not normally visible. On Chromebooks they are displayed by the Embedded Controller (EC), so it is useful to emit them. We must enable this feature for the EC to see the codes, so add an option for this. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
10 years ago
#define POST_START_STACK 0x29
#define POST_START_DONE 0x2a
x86: chromebook_link: Implement CAR support (cache as RAM) Add support for CAR so that we have memory to use prior to DRAM init. On link there is a total of 128KB of CAR available, although some is used for the memory reference code. Signed-off-by: Simon Glass <sjg@chromium.org>
10 years ago
#define POST_CPU_INIT 0x2b
x86: ivybridge: Add early init for PCH devices Many PCH devices are hard-coded to a particular PCI address. Set these up early in case they are needed. Signed-off-by: Simon Glass <sjg@chromium.org>
10 years ago
#define POST_EARLY_INIT 0x2c
#define POST_CPU_INFO 0x2d
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
#define POST_PRE_MRC 0x2e
#define POST_MRC 0x2f
x86: Correct duplicate POST values Two power-on-self-test values are the same. Fix this. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
8 years ago
#define POST_DRAM 0x30
#define POST_LAPIC 0x31
x86: Add post codes for OS resume This adds OS_RESUME (0x40) and RESUME_FAILURE (0xed) post codes. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org> Tested-by: Stefan Roese <sr@denx.de>
7 years ago
#define POST_OS_RESUME 0x40
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
#define POST_RAM_FAILURE 0xea
x86: Add post failure codes for bist and car Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org>
10 years ago
#define POST_BIST_FAILURE 0xeb
#define POST_CAR_FAILURE 0xec
x86: Add post codes for OS resume This adds OS_RESUME (0x40) and RESUME_FAILURE (0xed) post codes. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org> Tested-by: Stefan Roese <sr@denx.de>
7 years ago
#define POST_RESUME_FAILURE 0xed
x86: Emit post codes in startup code for Chromebooks On x86 it is common to use 'post codes' which are 8-bit hex values emitted from the code and visible to the user. Traditionally two 7-segment displays were made available on the motherboard to show the last post code that was emitted. This allows diagnosis of a boot problem since it is possible to see where the code got to before it died. On modern hardware these codes are not normally visible. On Chromebooks they are displayed by the Embedded Controller (EC), so it is useful to emit them. We must enable this feature for the EC to see the codes, so add an option for this. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
10 years ago
/* Output a post code using al - value must be 0 to 0xff */
#ifdef __ASSEMBLY__
#define post_code(value) \
movb $value, %al; \
outb %al, $POST_PORT
#else
x86: chromebook_link: Implement CAR support (cache as RAM) Add support for CAR so that we have memory to use prior to DRAM init. On link there is a total of 128KB of CAR available, although some is used for the memory reference code. Signed-off-by: Simon Glass <sjg@chromium.org>
10 years ago
#include <asm/io.h>
x86: Emit post codes in startup code for Chromebooks On x86 it is common to use 'post codes' which are 8-bit hex values emitted from the code and visible to the user. Traditionally two 7-segment displays were made available on the motherboard to show the last post code that was emitted. This allows diagnosis of a boot problem since it is possible to see where the code got to before it died. On modern hardware these codes are not normally visible. On Chromebooks they are displayed by the Embedded Controller (EC), so it is useful to emit them. We must enable this feature for the EC to see the codes, so add an option for this. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
10 years ago
static inline void post_code(int code)
{
outb(code, POST_PORT);
}
#endif
#endif