Changelog since:
v1:
* s/count_cpu/apic_id_init/
* merge handle_x2apic() into apic_id_init()
RFC:
* move out max-cpus check out of mptable_setup()
* factor out CPU counting/apic ID detection in separate function
* return back accidentially deleted debug message with APIC ID
* drop unused code in smp_setup()
According to SDM, if CPUs have APIC ID more than 254
firmware should pass control to OS in x2APIC mode.
This series adds x2APIC bootstrap initialization.
QEMU side of x2APIC support:
https://lists.gnu.org/archive/html/qemu-devel/2016-05/msg01094.html
Igor Mammedov (3):
paravirt: disable legacy bios tables in case of more than 255 CPUs
support booting with more than 255 CPUs
cleanup smp_setup()
Kevin O'Connor (1):
smp: refactor present CPU APIC ID detection and counting
src/fw/paravirt.c | 6 ++++--
src/fw/smp.c | 57 ++++++++++++++++++++++++++++++++++++-------------------
src/x86.h | 1 +
3 files changed, 42 insertions(+), 22 deletions(-)
--
1.8.3.1
Hi,
I'm sure I had sent this before, but appearently totally forgot about
it. Just tested booting with virtio bars mapped above 4G, didn't work.
Investigated, found this bitroting in a local branch. Undusted it,
rebased to latest master with some fixups, and here it is ...
Gerd Hoffmann (2):
virtio: uninline _vp_{read,write}
virtio: pci cfg access
src/hw/virtio-pci.c | 254 ++++++++++++++++++++++++++++++++++++++++++++++++----
src/hw/virtio-pci.h | 94 ++++---------------
2 files changed, 252 insertions(+), 96 deletions(-)
--
1.8.3.1
I am booting SeaBIOS as a payload of coreboot. I am then booting memtest86
as a secondary payload from SeaBIOS. It looks like memtest86 support
command line options, but I can't figure out how to pass a command line to
a secondary payload from SeaBIOS. Looks like it is somehow related to the
multiboot option in SeaBIOS, which I have tried enabling, but I still can't
figure out how add and pass a command line to a payload ran from SeaBIOS.
On 06/07/16 16:35, Zoran Stojsavljevic wrote:
>> Note that you can build seabios as CSM for tianocore already.
>
> These are the opposites: SeaBIOS is CSM ON (emulates Leagcy BIOS), while
> Tiano Core supposed to be CSM OFF (UEFI), Thus, SeaBIOS and Tiano Core
> exclude each other (should not be used together -> wrong architecture).
SeaBIOS can be built and used as a CSM with UEFI firmware built from
tianocore/edk2. The projects themselves are not "opposites".
The resultant firmware binary can boot OSes in UEFI mode or in legacy
mode. I guess those boot modes can be called opposites.
>> What is the point? You can just run tianocore as coreboot playload.
>
> The point is to make minimal Tiano Core (minimum for making FAT32
> partition/file system on HDD/SDD to create /boot/EFI/ directory, in
> other words minimal UEFI compliant BIOS), Tiano Core as such is good to
> be used/run for/on x86 architecture ONLY
This is patently false. Several aarch64 platforms exist that run UEFI
firmware based more or less directly on tianocore/edk2. In my living
room I have an APM Mustang that has UEFI firmware, based on tianocore/edk2.
The SBBR spec (Server Base Boot Requirements
System Software on ARM ® Platforms) mandates UEFI. Of course, not all
ARM platforms are required to conform to the SBBR, but the SBBR would be
quite foolish to require a practically unfeasible thing. tianocore/edk2
is the open source reference implementation of PI (Platform Init) and UEFI.
It's a separate question wheter specific aarch64 platform code lives
directly within the edk2 tree, or in some external tree (open source or
proprietary).
> (and side effect is the
> extended time for booting, since all these DXE drivers must be
> installed, which will be later mostly replaced/run over with OS drivers,
> except run time services).
DXE drivers are supposed to drive peripherals only in the exceptional
case. Most devices that are not integrated in the platform are supposed
to be driven by UEFI drivers that conform to the UEFI Driver Model.
The point of that driver model is that no compliant driver, when
initially launched, starts to drive any kind of hardware. Instead, it
installs only three callbacks (member functions of its driver binding
protocol instance): supported, start, and stop. The supported callback
is used as a very quick check by the system to see if a driver supports
a given piece of hardware. The start and stop functions instruct the
driver to actually bind (and unbind) the specified piece of hardware.
The calls to the supported and bind functions are initiated by Platform
BDS (Boot Device Selection). In other words, it is a platform decision
to automatically bind this or that set of devices. In OVMF and
ArmVirtPkg (running in QEMU, Xen, and possibly other virtual machines),
we choose to automatically bind all possible devices, because in virt,
that's generally the best approach (and it is even necessary for some
QEMU boot order quirks that I'm not going to go into now).
But, auto-binding all devices is nowhere mandated by the UEFI spec, or
any other related spec. In fact, on some x86 platforms the vendor seeks
to speed up the boot by not connecting USB keyboards even.
(And then, if you want to use the USB keyboard before the OS is booted,
for example for modifying firmware settings, you have to set a
non-volatile UEFI variable from within the OS, sometimes displayed as
"change firmware settings" or some such.
Then at the next boot, the firmware will drop you into the setup TUI,
with the keyboard (and possibly other devices) connected. The user can
massage firmware settings then; e.g., if the platform vendor wants it
too, the user may be able to add the USB keyboard to the set of
auto-connected devices.)
Other schemes exist too. The Platform Init specification (separate from
the UEFI specification) defines the Boot Mode HOB (hand-off block). The
HOB-producer phase of the firmware (usually: PEI, Pre-EFI
Initialization) can produce this HOB, so that later phases of the
firmware can key off of it. For example, dependent on platform hardware
support, this HOB can tell the Boot Device Selection phase *not* to
connect any other devices than the last time around, because the chassis
has not been opened since. Otherwise, BDS might want to auto-connect
everything (perhaps the user installed a new SSD, etc).
> As such, Minimal Tiano Core (minimal UEFI compliant BIOS) could be used
> on ARM architectures too, thus making ARM HW platforms also
> compatible/lookalike as x86 UEFI compliant BIOS.
The UEFI specification already contains AArch32 and AArch64 bindings. It
is already possible to implement UEFI on ARM platforms, and several
vendors have. Boot performance, as far as it is affected by the set of
devices automatically connected, is platform policy.
> In nutshell, then you can build PC/Laptop with ARM CPU/SoC HW platform,
>From last September, a blog post from one of my colleagues:
https://marcin.juszkiewicz.com.pl/2015/09/21/aarch64-desktop-day-one/
> having coreboot + minimal Tiano Core + WIN 10 Boot Loader + WIN10 on it
> (since WIN10 BL does see UEFI compliance, not knowing what is really
> under the hood). ;-)
For the record, I am definitely not arguing against coreboot, or u-boot,
or even a stripped down platform firmware built purely from
tianocore/edk2. Still for the record, I'm also not arguing that people
should move to UEFI *at all*, unless they have specific reasons.
But claiming that tianocore/edk2 is only good for x86 in its current
shape and form, and implying that UEFI on ARM unconditionally needs a
lower-level "shim", are just preposterous.
Laszlo
Here's a patch to build the UEFI coreboot payload package directly as a
coreboot payload.
https://review.coreboot.org/#/c/15057/
Martin
On Tue, Jun 7, 2016 at 1:13 PM, Zoran Stojsavljevic <
zoran.stojsavljevic(a)gmail.com> wrote:
> > I fail to see what you are trying to tell me.
> > I'm not sure you even know what a CSM is.
>
> I probably do not. ;-)
>
> > And what has all this to do with seabios?
>
> Did I ever mention SeaBIOS to play minimal TianoCore?
>
> Thank you,
> Zoran
>
> On Tue, Jun 7, 2016 at 5:18 PM, Gerd Hoffmann <kraxel(a)redhat.com> wrote:
>
>> On Di, 2016-06-07 at 16:35 +0200, Zoran Stojsavljevic wrote:
>> > > Note that you can build seabios as CSM for tianocore already.
>>
>> > These are the opposites: SeaBIOS is CSM ON (emulates Leagcy BIOS),
>> > while Tiano Core supposed to be CSM OFF (UEFI), Thus, SeaBIOS and
>> > Tiano Core exclude each other (should not be used together -> wrong
>> > architecture).
>>
>> I fail to see what you are trying to tell me.
>> I'm not sure you even know what a CSM is.
>>
>> > > What is the point? You can just run tianocore as coreboot playload.
>>
>> > The point is to make minimal Tiano Core (minimum for making FAT32
>> > partition/file system on HDD/SDD to create /boot/EFI/ directory, in
>> > other words minimal UEFI compliant BIOS), Tiano Core as such is good
>> > to be used/run for/on x86 architecture ONLY (and side effect is the
>> > extended time for booting, since all these DXE drivers must be
>> > installed, which will be later mostly replaced/run over with OS
>> > drivers, except run time services).
>>
>> > As such, Minimal Tiano Core (minimal UEFI compliant BIOS) could be
>> > used on ARM architectures too, thus making ARM HW platforms also
>> > compatible/lookalike as x86 UEFI compliant BIOS.
>>
>> tianocore already runs on arm.
>> seabios doesn't and it never will.
>>
>> > In nutshell, then you can build PC/Laptop with ARM CPU/SoC HW
>> > platform, having coreboot + minimal Tiano Core + WIN 10 Boot Loader +
>> > WIN10 on it (since WIN10 BL does see UEFI compliance, not knowing what
>> > is really under the hood). ;-)
>>
>> And what has all this to do with seabios?
>>
>> confused,
>> Gerd
>>
>>
>
> --
> coreboot mailing list: coreboot(a)coreboot.org
> https://www.coreboot.org/mailman/listinfo/coreboot
>
On Di, 2016-06-07 at 16:35 +0200, Zoran Stojsavljevic wrote:
> > Note that you can build seabios as CSM for tianocore already.
> These are the opposites: SeaBIOS is CSM ON (emulates Leagcy BIOS),
> while Tiano Core supposed to be CSM OFF (UEFI), Thus, SeaBIOS and
> Tiano Core exclude each other (should not be used together -> wrong
> architecture).
I fail to see what you are trying to tell me.
I'm not sure you even know what a CSM is.
> > What is the point? You can just run tianocore as coreboot playload.
> The point is to make minimal Tiano Core (minimum for making FAT32
> partition/file system on HDD/SDD to create /boot/EFI/ directory, in
> other words minimal UEFI compliant BIOS), Tiano Core as such is good
> to be used/run for/on x86 architecture ONLY (and side effect is the
> extended time for booting, since all these DXE drivers must be
> installed, which will be later mostly replaced/run over with OS
> drivers, except run time services).
> As such, Minimal Tiano Core (minimal UEFI compliant BIOS) could be
> used on ARM architectures too, thus making ARM HW platforms also
> compatible/lookalike as x86 UEFI compliant BIOS.
tianocore already runs on arm.
seabios doesn't and it never will.
> In nutshell, then you can build PC/Laptop with ARM CPU/SoC HW
> platform, having coreboot + minimal Tiano Core + WIN 10 Boot Loader +
> WIN10 on it (since WIN10 BL does see UEFI compliance, not knowing what
> is really under the hood). ;-)
And what has all this to do with seabios?
confused,
Gerd
Hi all,
I noticed that seabios/libpayload could have interresting use cases and I want
to share/discuss them.
1) Have a SeaBIOS be a UEFI application. This would benefit on UEFI platforms
without CSM.
2) Provide a minimum UEFI environment. As I noticed u-boot started to have such
support. In fact it has UEFI glue to u-boot drivers. As such it provides a
minimal boot services + minimum runtime services. In seabios, it is almost
there, only PE loader and filesystem support is missing.
The 2) could be perhaps be some independent project utilizing the coreboot
libpayload library.
Maybe those can be done in next year GSoC.
I guess 2) could be useful to boot future OSes without legacy support.
Thanks
Rudolf
