| 19038e1b | 08-Oct-2015 |
Bin Meng <bmeng.cn@gmail.com> |
x86: Initialize GDT entry 1 to be the 32-bit CS as well
Some OS (like VxWorks) requires GDT entry 1 to be the 32-bit CS.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Acked-by: Simon Glass <sjg@chro
x86: Initialize GDT entry 1 to be the 32-bit CS as well
Some OS (like VxWorks) requires GDT entry 1 to be the 32-bit CS.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Acked-by: Simon Glass <sjg@chromium.org>
Tested-by: Jian Luo <jian.luo4@boschrexroth.de>
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 ...
|
| 8e368302 | 10-Sep-2015 |
Bin Meng <bmeng.cn@gmail.com> |
x86: quark: Convert to use clrbits, setbits, clrsetbits macros
Change existing codes to use clrbits, setbits, clrsetbits macros.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Acked-by: Simon Glass <
x86: quark: Convert to use clrbits, setbits, clrsetbits macros
Change existing codes to use clrbits, setbits, clrsetbits macros.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Acked-by: Simon Glass <sjg@chromium.org>
show more ...
|
| 2afb6230 | 11-Sep-2015 |
Bin Meng <bmeng.cn@gmail.com> |
x86: quark: Add PCIe/USB static register programming after memory init
This adds static register programming for PCIe and USB after memory
init as required by Quark firmware writer guide. Although n
x86: quark: Add PCIe/USB static register programming after memory init
This adds static register programming for PCIe and USB after memory
init as required by Quark firmware writer guide. Although not doing
this did not cause any malfunction, just do it for safety.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Acked-by: Simon Glass <sjg@chromium.org>
show more ...
|
| b06862b9 | 03-Sep-2015 |
Bin Meng <bmeng.cn@gmail.com> |
x86: quark: Add USB PHY initialization support
USB PHY needs to be properly initialized per Quark firmware writer
guide, otherwise the EHCI controller on Quark SoC won't work.
Signed-off-by: Bin Me
x86: quark: Add USB PHY initialization support
USB PHY needs to be properly initialized per Quark firmware writer
guide, otherwise the EHCI controller on Quark SoC won't work.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Acked-by: Simon Glass <sjg@chromium.org>
show more ...
|
| aa09505b | 03-Sep-2015 |
Bin Meng <bmeng.cn@gmail.com> |
x86: quark: Avoid chicken and egg problem
If we convert to use driver model pci on quark, we will encounter
some chicken and egg problems like below:
- To enable PCIe root ports, we need program so
x86: quark: Avoid chicken and egg problem
If we convert to use driver model pci on quark, we will encounter
some chicken and egg problems like below:
- To enable PCIe root ports, we need program some registers on the
message bus via pci bus. With driver model, the first time to
access pci bus, the pci enumeration process will be triggered.
But without first enabling PCIe root ports, pci enumeration
just hangs when scanning PCIe root ports.
- Similar situation happens when trying to access GPIO from the
PCIe enabling codes, as GPIO requires its block base address
to be assigned via a pci configuration register in the bridge.
To avoid such dilemma, replace all pci calls in the quark codes
to use the local version which does not go through driver model.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Acked-by: Simon Glass <sjg@chromium.org>
show more ...
|
| 5750e5e2 | 03-Sep-2015 |
Bin Meng <bmeng.cn@gmail.com> |
x86: quark: Optimize MRC execution time
Intel Quark SoC has a low end x86 processor with only 400MHz
frequency. Currently it takes about 15 seconds for U-Boot to
boot to shell and the most time cons
x86: quark: Optimize MRC execution time
Intel Quark SoC has a low end x86 processor with only 400MHz
frequency. Currently it takes about 15 seconds for U-Boot to
boot to shell and the most time consuming part is with MRC,
which is about 12 seconds. MRC programs lots of registers on
the SoC internal message bus indirectly accessed via pci bus.
To speed up the boot, create an optimized version of pci config
read/write dword routines which directly operate on PCI I/O ports.
These two routines are inlined to provide better performance too.
Now it only takes about 3 seconds to finish MRC, which is really
fast (4 times faster than before).
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Acked-by: Simon Glass <sjg@chromium.org>
show more ...
|
| fa6af7b4 | 20-Aug-2015 |
Bin Meng <bmeng.cn@gmail.com> |
x86: baytrail: Remove the fsp_init_phase_pci() call
It turns out that calling fsp_init_phase_pci() in arch_misc_init()
is subject to break pci device drivers as with driver model, when
the bus enume
x86: baytrail: Remove the fsp_init_phase_pci() call
It turns out that calling fsp_init_phase_pci() in arch_misc_init()
is subject to break pci device drivers as with driver model, when
the bus enumeration happens is not deterministic.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Acked-by: Simon Glass <sjg@chromium.org>
show more ...
|
| 090290f9 | 20-Aug-2015 |
Bin Meng <bmeng.cn@gmail.com> |
x86: queensbay: Move unprotect_spi_flash() to arch_misc_init()
With dm pci conversion, pci config read/write in unprotect_spi_flash()
silently fails as at that time dm pci is not ready and bus enume
x86: queensbay: Move unprotect_spi_flash() to arch_misc_init()
With dm pci conversion, pci config read/write in unprotect_spi_flash()
silently fails as at that time dm pci is not ready and bus enumeration
is not done yet. Actually we don't need to do this in that early phase,
hence we delay this call to arch_misc_init().
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Acked-by: Simon Glass <sjg@chromium.org>
show more ...
|
| a25bc78e | 13-Aug-2015 |
Bin Meng <bmeng.cn@gmail.com> |
x86: coreboot: Allow >=4GiB memory bank size
Some platforms may have >=4GiB memory, so we need make U-Boot report
such configuration correctly when booting as the coreboot payload.
Signed-off-by: B
x86: coreboot: Allow >=4GiB memory bank size
Some platforms may have >=4GiB memory, so we need make U-Boot report
such configuration correctly when booting as the coreboot payload.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
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 ...
|
| 052e34b3 | 13-Aug-2015 |
Simon Glass <sjg@chromium.org> |
x86: Return -1 when reading a PCI config register fails
This can fail for internal reasons, so return a sensible value rather than
a random one.
Signed-off-by: Simon Glass <sjg@chromium.org>
Review
x86: Return -1 when reading a PCI config register fails
This can fail for internal reasons, so return a sensible value rather than
a random one.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
show more ...
|