| 0a2ea020 | 23-Oct-2015 |
Bin Meng <bmeng.cn@gmail.com> |
x86: Fix cosmetic issues in the i8254 and i8259 codes
This cleans up i8254 and i8259 codes to fix several cosmetic
issues, like coding convention and some comments improvement.
Signed-off-by: Bin M
x86: Fix cosmetic issues in the i8254 and i8259 codes
This cleans up i8254 and i8259 codes to fix several cosmetic
issues, like coding convention and some comments improvement.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Acked-by: Simon Glass <sjg@chromium.org>
show more ...
|
| 4b9f6a66 | 12-Oct-2015 |
Bin Meng <bmeng.cn@gmail.com> |
x86: Use struct mrc_region to describe a mrc region
Currently struct fmap_entry is used to describe a mrc region.
However this structure contains some other fields that are not
related to mrc cache
x86: Use struct mrc_region to describe a mrc region
Currently struct fmap_entry is used to describe a mrc region.
However this structure contains some other fields that are not
related to mrc cache and causes confusion. Besides, it does not
include a base address field to store SPI flash's base address.
Instead in the mrccache.c it tries to use CONFIG_ROM_SIZE to
calculate the SPI flash base address, which unfortunately is
not 100% correct as CONFIG_ROM_SIZE may not match the whole
SPI flash size.
Define a new struct mrc_region and use it instead.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Acked-by: Simon Glass <sjg@chromium.org>
show more ...
|
| ed800961 | 12-Oct-2015 |
Bin Meng <bmeng.cn@gmail.com> |
x86: Add more common routines to manipulate mrc cache
This adds mrccache_reserve(), mrccache_get_region() and
mrccache_save() APIs to the mrccache codes. They are ported
from the ivybridge implement
x86: Add more common routines to manipulate mrc cache
This adds mrccache_reserve(), mrccache_get_region() and
mrccache_save() APIs to the mrccache codes. They are ported
from the ivybridge implementation, but with some changes.
For example, in the mrccache_reserve(), ivybridge version
only reserves the pure MRC data, which causes additional
malloc() when saving the cache as the save API needs some
meta data. Now we change it to save the whole MRC date plus
the meta data to elinimate the need for the malloc() later.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Acked-by: Simon Glass <sjg@chromium.org>
show more ...
|
| bfa95c53 | 12-Oct-2015 |
Bin Meng <bmeng.cn@gmail.com> |
x86: Add various minor tidy-ups in mrccache codes
Fix some nits, improve some comments and reorder some codes
a little bit.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Acked-by: Simon Glass <sjg@c
x86: Add various minor tidy-ups in mrccache codes
Fix some nits, improve some comments and reorder some codes
a little bit.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Acked-by: Simon Glass <sjg@chromium.org>
show more ...
|
| 2fe66dbc | 12-Oct-2015 |
Bin Meng <bmeng.cn@gmail.com> |
x86: Do sanity test on the cache record in mrccache_update()
For the cache record to write in mrccache_update(), we should
perform a sanity test to see if it is a valid one.
Signed-off-by: Bin Meng
x86: Do sanity test on the cache record in mrccache_update()
For the cache record to write in mrccache_update(), we should
perform a sanity test to see if it is a valid one.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Acked-by: Simon Glass <sjg@chromium.org>
show more ...
|
| c6d4705f | 14-Sep-2015 |
Bin Meng <bmeng.cn@gmail.com> |
x86: quark: Configure MTRR to enable cache
Quark SoC does not support MSR MTRRs. Fixed and variable range MTRRs
are accessed indirectly via the message port and not the traditional
MSR mechanism. On
x86: quark: Configure MTRR to enable cache
Quark SoC does not support MSR MTRRs. Fixed and variable range MTRRs
are accessed indirectly via the message port and not the traditional
MSR mechanism. Only UC, WT and WB cache types are supported.
We configure all the fixed range MTRRs with common values (VGA RAM
as UC, others as WB) and 3 variable range MTRRs for ROM/eSRAM/RAM as
WB, which significantly improves the boot time performance.
With this commit, it takes only 2 seconds for U-Boot to boot to shell
on Intel Galileo board. Previously it took about 6 seconds.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Acked-by: Simon Glass <sjg@chromium.org>
Tested-by: Simon Glass <sjg@chromium.org>
show more ...
|
| 554778c2 | 10-Sep-2015 |
Bin Meng <bmeng.cn@gmail.com> |
x86: quark: Initialize thermal sensor properly
Thermal sensor on Quark SoC needs to be properly initialized per
Quark firmware writer guide, otherwise when booting Linux kernel,
it triggers system s
x86: quark: Initialize thermal sensor properly
Thermal sensor on Quark SoC needs to be properly initialized per
Quark firmware writer guide, otherwise when booting Linux kernel,
it triggers system shutdown because of wrong temperature in the
thermal sensor is detected by the kernel driver (see below):
[ 5.119819] thermal_sys: Critical temperature reached(206 C),shutting down
[ 5.128997] Failed to start orderly shutdown: forcing the issue
[ 5.135495] Emergency Sync complete
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Acked-by: Simon Glass <sjg@chromium.org>
show more ...
|
| 693b5f6c | 10-Sep-2015 |
Bin Meng <bmeng.cn@gmail.com> |
x86: quark: Lock HMBOUND register before jumping to kernel
When Linux kernel boots, it hangs at:
[ 0.829408] Intel Quark side-band driver registered
This happens when Quark kernel Isolated Memo
x86: quark: Lock HMBOUND register before jumping to kernel
When Linux kernel boots, it hangs at:
[ 0.829408] Intel Quark side-band driver registered
This happens when Quark kernel Isolated Memory Region (IMR) driver
tries to lock an IMR register to protect kernel's text and rodata
sections. However in order to have IMR function correctly, HMBOUND
register must be locked otherwise the system just hangs.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Acked-by: Simon Glass <sjg@chromium.org>
show more ...
|
| d0b3e3bf | 10-Sep-2015 |
Bin Meng <bmeng.cn@gmail.com> |
x86: quark: Add clrbits, setbits, clrsetbits macros for message port access
On Intel Quark, lots of registers on the message port need be
programmed. Add handy clrbits, setbits, clrsetbits macros fo
x86: quark: Add clrbits, setbits, clrsetbits macros for message port access
On Intel Quark, lots of registers on the message port need be
programmed. Add handy clrbits, setbits, clrsetbits macros for
message port access.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
show more ...
|
| 867bcb63 | 22-Aug-2015 |
Saket Sinha <saket.sinha89@gmail.com> |
x86: Generate a valid ACPI table
Implement write_acpi_table() to create a minimal working ACPI table.
This includes writing FACS, XSDT, RSDP, FADT, MCFG, MADT, DSDT & SSDT
ACPI table entries.
Use a
x86: Generate a valid ACPI table
Implement write_acpi_table() to create a minimal working ACPI table.
This includes writing FACS, XSDT, RSDP, FADT, MCFG, MADT, DSDT & SSDT
ACPI table entries.
Use a Kconfig option GENERATE_ACPI_TABLE to tell U-Boot whether we need
actually write the APCI table just like we did for PIRQ routing, MP table
and SFI tables. With ACPI table existence, linux kernel gets control of
power management, thermal management, configuration management and
monitoring in hardware.
Signed-off-by: Saket Sinha <saket.sinha89@gmail.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Tidied up whitespace and aligned some tabs:
Signed-off-by: Simon Glass <sjg@chromium.org>
show more ...
|
| c17ca6b5 | 13-Aug-2015 |
Bin Meng <bmeng.cn@gmail.com> |
x86: Remove calculate_relocation_address()
Now that we have generic routine to calculate relocation address,
remove the x86 specific one which is now only used by coreboot.
Signed-off-by: Bin Meng
x86: Remove calculate_relocation_address()
Now that we have generic routine to calculate relocation address,
remove the x86 specific one which is now only used by coreboot.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
show more ...
|
| 2db93745 | 11-Aug-2015 |
Simon Glass <sjg@chromium.org> |
x86: Move the GDT into global_data
Rather than keeping track of the Global Descriptor Table in its own memory
we may as well put it in global_data with everything else. As a first step,
stop using t
x86: Move the GDT into global_data
Rather than keeping track of the Global Descriptor Table in its own memory
we may as well put it in global_data with everything else. As a first step,
stop using the separately allocated GDT.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
show more ...
|