07545d86 | 22-Jun-2015 |
Bin Meng <bmeng.cn@gmail.com> |
x86: Generate a valid MultiProcessor (MP) table
Implement write_mp_table() to create a minimal working MP table. This includes an MP floating table, a configuration table header and all of the 5 bas
x86: Generate a valid MultiProcessor (MP) table
Implement write_mp_table() to create a minimal working MP table. This includes an MP floating table, a configuration table header and all of the 5 base configuration table entries. The I/O interrupt assignment table entry is created based on the same information used in the creation of PIRQ routing table from device tree. A check duplicated entry logic is applied to prevent writing multiple I/O interrupt entries with the same information.
Use a Kconfig option GENERATE_MP_TABLE to tell U-Boot whether we need actually write the MP table at the F seg, just like we did for PIRQ routing and SFI tables. With MP table existence, linux kernel will switch to I/O APIC and local APIC to process all the peripheral interrupts instead of 8259 PICs. This takes full advantage of the multicore hardware and the SMP kernel.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org>
show more ...
|
7f5df8d4 | 22-Jun-2015 |
Bin Meng <bmeng.cn@gmail.com> |
x86: Add MultiProcessor (MP) table APIs
The MP table provides a way for the operating system to support for symmetric multiprocessing as well as symmetric I/O interrupt handling with the local APIC
x86: Add MultiProcessor (MP) table APIs
The MP table provides a way for the operating system to support for symmetric multiprocessing as well as symmetric I/O interrupt handling with the local APIC and I/O APIC. We provide a bunch of APIs for U-Boot to write the floating table, configuration table header as well as base and extended table entries.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org>
show more ...
|
a2d73fdb | 22-Jun-2015 |
Bin Meng <bmeng.cn@gmail.com> |
x86: Remove inline for lapic access routines
Remove inline for lapic access routines and expose lapic_read() & lapic_write() as APIs to read/write lapic registers. Also move stop_this_cpu() to mp_in
x86: Remove inline for lapic access routines
Remove inline for lapic access routines and expose lapic_read() & lapic_write() as APIs to read/write lapic registers. Also move stop_this_cpu() to mp_init.c as it has nothing to do with lapic.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org>
show more ...
|
63d54a67 | 16-Jun-2015 |
Bin Meng <bmeng.cn@gmail.com> |
x86: Clean up lapic codes
This commit cleans up the lapic codes: - Delete arch/x86/include/asm/lapic_def.h, and move register and bit defines into arch/x86/include/asm/lapic.h - Use MSR defines fr
x86: Clean up lapic codes
This commit cleans up the lapic codes: - Delete arch/x86/include/asm/lapic_def.h, and move register and bit defines into arch/x86/include/asm/lapic.h - Use MSR defines from msr-index.h in enable_lapic() and disable_lapic() - Remove unnecessary stuff like NEED_LAPIC, X86_GOOD_APIC and CONFIG_AP_IN_SIPI_WAIT - Move struct x86_cpu_priv defines to asm/arch-ivybridge/bd82x6x.h, as it is not apic related and only used by ivybridge - Fix coding convention issues
Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org>
show more ...
|
6e6f4ce4 | 16-Jun-2015 |
Bin Meng <bmeng.cn@gmail.com> |
x86: Move MP initialization codes into a common place
Most of the MP initialization codes in arch/x86/cpu/baytrail/cpu.c is common to all x86 processors, except detect_num_cpus() which varies from c
x86: Move MP initialization codes into a common place
Most of the MP initialization codes in arch/x86/cpu/baytrail/cpu.c is common to all x86 processors, except detect_num_cpus() which varies from cpu to cpu. Move these to arch/x86/cpu/cpu.c and implement the new 'get_count' method for baytrail and cpu_x86 drivers. Now we call cpu_get_count() in mp_init() to get the number of CPUs.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org>
show more ...
|
aefaff8e | 06-Jun-2015 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Move FspInitEntry call to board_init_f()
The call to FspInitEntry is done in arch/x86/lib/fsp/fsp_car.S so far. It worked pretty well but looks not that good. Apart from doing too much wor
x86: fsp: Move FspInitEntry call to board_init_f()
The call to FspInitEntry is done in arch/x86/lib/fsp/fsp_car.S so far. It worked pretty well but looks not that good. Apart from doing too much work than just enabling CAR, it cannot read the configuration data from device tree at that time. Now we want to move it a little bit later as part of init_sequence_f[] being called by board_init_f(). This way it looks and works better in the U-Boot initialization path.
Due to FSP's design, after calling FspInitEntry it will not return to its caller, instead it jumps to a continuation function which is given by bootloader with a new stack in system memory. The original stack in the CAR is gone, but its content is perserved by FSP and described by a bootloader temporary memory HOB. Technically we can recover anything we had before in the previous stack, but that is way too complicated. To make life much easier, in the FSP continuation routine we just simply call fsp_init_done() and jump back to car_init_ret() to redo the whole board_init_f() initialization, but this time with a non-zero HOB list pointer saved in U-Boot's global data so that we can bypass the FspInitEntry for the second time.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org> Tested-by: Andrew Bradford <andrew.bradford@kodakalaris.com> Tested-by: Simon Glass <sjg@chromium.org>
show more ...
|
4be2f42b | 25-May-2015 |
Bin Meng <bmeng.cn@gmail.com> |
x86: qemu: Adjust VGA initialization
As VGA option rom needs to run at C segment, although QEMU PAM emulation seems to only guard E/F segments, for correctness, move VGA initialization after PAM dec
x86: qemu: Adjust VGA initialization
As VGA option rom needs to run at C segment, although QEMU PAM emulation seems to only guard E/F segments, for correctness, move VGA initialization after PAM decode C/D/E/F segments.
Also since we already tested QEMU targets to differentiate I440FX and Q35 platforms, change to locate the VGA device via hardcoded b.d.f instead of dynamic search for its vendor id & device id pair.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org>
show more ...
|
0fcb7acf | 25-May-2015 |
Bin Meng <bmeng.cn@gmail.com> |
x86: qemu: Enable legacy IDE I/O ports decode
QEMU always decode legacy IDE I/O ports on PIIX chipset. However Linux ata_piix driver does sanity check to see whether legacy ports decode is turned on
x86: qemu: Enable legacy IDE I/O ports decode
QEMU always decode legacy IDE I/O ports on PIIX chipset. However Linux ata_piix driver does sanity check to see whether legacy ports decode is turned on. To make Linux ata_piix driver happy, turn on the decode via IDE_TIMING register.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org>
show more ...
|
05b98ec3 | 25-May-2015 |
Bin Meng <bmeng.cn@gmail.com> |
x86: quark: Implement PIRQ routing
Intel Quark SoC has the same interrupt routing mechanism as the Queensbay platform, only the difference is that PCI devices' INTA/B/C/D are harcoded and cannot be
x86: quark: Implement PIRQ routing
Intel Quark SoC has the same interrupt routing mechanism as the Queensbay platform, only the difference is that PCI devices' INTA/B/C/D are harcoded and cannot be changed freely.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org>
show more ...
|