[coreboot] [ANNOUNCE] SeaBIOS 1.16.0

2022-03-01 Thread Kevin O'Connor
The 1.16.0 version of SeaBIOS has now been released.  For more
information on the release, please see:

https://seabios.org/Releases


New in this release:

* SMBIOS v3.0 support on QEMU
* Several bug fixes and code cleanups.


For information on obtaining SeaBIOS, please see:

https://seabios.org/Download


= git shortlog -n rel-1.15.0..rel-1.16.0 =

Eduardo Habkost (19):
  biostables: copy_fseg_table() function
  util.h: Delete unused get_smbios_entry_point() prototype
  smbios: Rename code specific for SMBIOS 2.1 entry points
  smbios: Generic smbios_next() function
  smbios: smbios_get_tables() function
  smbios: Use smbios_get_tables()/smbios_next() at display_uuid()
  smbios: smbios_major_version()/smbios_minor_version() helpers
  tpm: Use smbios_get_tables()
  csm: Don't check SMBios21Addr before calling copy_smbios_21()
  smbios: Make SMBios21Addr variable static
  smbios: Use smbios_next() at smbios_romfile_setup()
  smbios: Extract SMBIOS table building code to separate function
  smbios: Make smbios_build_tables() more generic
  smbios: smbios_21_setup_entry_point() function
  smbios: Make some smbios_build_tables() arguments optional
  smbios: Make smbios_build_tables() ready for 64-bit tables
  smbios: copy_smbios_30() function
  smbios: Support SMBIOS 3.0 entry point at copy_table()
  smbios: Support SMBIOS 3.0 entry point at smbios_romfile_setup()

Kevin O'Connor (13):
  vgasrc: Don't use VAR16 in header files to fix gcc warning
  memmap: Fix gcc out-of-bounds warning
  readserial: Improve Python3 compatibility
  scripts: Remove python23compat.py
  smm: Suppress gcc array-bounds warnings
  nvme: Rework nvme_io_readwrite() to return -1 on error
  nvme: Add nvme_bounce_xfer() helper function
  nvme: Convert nvme_build_prpl() to nvme_prpl_xfer()
  nvme: Pass prp1 and prp2 directly to nvme_io_xfer()
  nvme: Build the page list in the existing dma buffer
  nvme: Only allocate one dma bounce buffer for all nvme drives
  sercon: Fix missing GET_LOW() to access rx_bytes
  docs: Note v1.16.0 release

Andy Pei (3):
  virtio-blk: add feature VIRTIO_BLK_F_SIZE_MAX and VIRTIO_BLK_F_SEG_MAX
  virtio-blk: abstract a function named virtio_blk_op_one_segment to handle 
r/w request
  virtio-blk: split large IO according to size_max

Igor Mammedov (2):
  pci: reserve resources for pcie-pci-bridge to fix regressed hotplug on q35
  pci: let firmware reserve IO for pcie-pci-bridge

Florian Larysch (1):
  nvme: fix LBA format data structure

Gerd Hoffmann (1):
  svgamodes: add standard 4k modes

Jan Beulich via SeaBIOS (1):
  nvme: avoid use-after-free in nvme_controller_enable()
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org


[coreboot] Re: 2022-03-01 - coreboot UEFI working group meeting minutes

2022-03-01 Thread Rudolf Marek

Hi,

On 01. 03. 22 20:21, coreboot org wrote:

 * [Nate] Might need to save the efi memory map so that data isn’t
lost when converting to an e820 memory map and back. Linux may rely on
GRUB doing that - so look into GRUB.


Looks like the the superset of various memory region types is defined in ACPI 
spec,
see [1] And especially nice mapping table here [2]. Probably you can also 
consult multiboot2 [3]
to see what is defined in there. Look for ( MULTIBOOT_MEMORY_)  But, I suspect 
the broadest range is still [1].


* [Daniel] Trammell Hudson is working on Getting UEFI mapped into
linux.  Coreboot could boot into something that provides a UEFI
environment, then into linux, which could then load other operating
systems.


What about the video BIOS stuff/OptionROM stuff? Using Linux would perhaps 
eliminate that.

Or another idea - recycling SeaBIOS drivers and doing UEFISeaBIOS instead?

Please note that Windows 11 require UEFI secureboot to boot (among other things)

Thanks,
Rudolf

[1] 
https://uefi.org/specs/ACPI/6.4/15_System_Address_Map_Interfaces/Sys_Address_Map_Interfaces.html?highlight=reclaim#system-address-map-interfaces
[2] 
https://uefi.org/specs/ACPI/6.4/15_System_Address_Map_Interfaces/uefi-getmemorymap-boot-services-function.html#uefi-getmemorymap-boot-services-function
[3] https://www.gnu.org/software/grub/manual/multiboot2/multiboot.html
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org


[coreboot] 2022-03-01 - coreboot UEFI working group meeting minutes

2022-03-01 Thread coreboot org
# 2022-03-01 - coreboot EFI working group meeting minutes

## Attendees:
Martin, Sheng, Daniel Maslowski, Nate Desimone, Ron Minnich, Jay
Talbott, Ahamed Husni, Matt Devillier, Sean Rhodes, Matt
Papageorge,Tim Crawford, David Hendricks

## Minutes:
* [Martinr]: This meeting has been restarted as a monthly (every 4
weeks) meeting.  If you want an invite, please add a comment to the
meeting agenda document requesting to be added.
* Agenda/Minutes
https://docs.google.com/document/d/13RjAddskjjCGhzIwxDTE1-w6HOIwhyoZsZUIOcauaxo/edit#heading=h.pbrqmoq67l4a
* Next meeting is 2022-02-29.  The schedule is posted on the
coreboot calendar. https://coreboot.org/calendar.html


* [Sheng] Need to discuss the edk2 branching plan. Had a discussion
with Intel folks to make Sean Rhodes as maintainer of
edk2uefipayloadpkg maintainer (done). Sean is uploading all coreboot
edk2 patches to EDK2 masterbranch to get merged, 9elements will follow
afterwards. Will need help to review.
* Most of the patches in Matt’s fork are already approved.  There
are a couple of stragglers and a couple more that they don’t want.
* How do we want to handle the EDK2 codebase going forward?  Do we
want to just use the upstream branch?
* This should be decided by the community, probably led by Sean & Matt
* If we do go with upstream, we should keep an older branch
around to support the older thinkpads that don’t work with the current
upstream.
* Also, we can apply a list of coreboot-specific patches to
the upstream codebase.
* Matt DeVillier and Matt Papageorge can help review the changes.

* [Martinr] Where do we find the source for the U-Boot UEFI
implementation?  Is this it?
[https://source.denx.de/u-boot/custodians/u-boot-efi](https://source.denx.de/u-boot/custodians/u-boot-efi)
* Was the suggestion to use U-Boot as a payload with it’s UEFI code?
* [Ron] We should look at using their code and pulling it in
so that coreboot can use it.  Very different approach - just implement
the block drivers for example, main point is they have about 12
protocols they implement, don’t need specific types, e.g. no usb block
or nvme block protocol
* Martin - don’t want to pull it in to coreboot - want to use a payload.
* see also 64-bit U-Boot in
[https://source.denx.de/u-boot/u-boot/-/blob/master/doc/board/coreboot/coreboot.rst](https://source.denx.de/u-boot/u-boot/-/blob/master/doc/board/coreboot/coreboot.rst)
“In addition to the 32-bit 'coreboot' build there is a
'coreboot64' build. This produces an image which can be booted from
coreboot (32-bit). Internally it works by using a 32-bit SPL binary to
switch to 64-bit for running U-Boot. It can be useful for running UEFI
applications, for example.”
* Ron - Just use the U-Boot implementation as a direction that
we want to go in.  See if it can be compiled against


* Ahamed:  Gsoc project Idea
* Hasn’t worked with UEFI. Tried running an EFI application in
coreboot/u-boot.
* Has sent an email to the mailing list.
* 
[https://mail.coreboot.org/hyperkitty/list/coreboot@coreboot.org/thread/SV6XH6UYLDN73EQWJ2HNVBXFJ6CHWNP5/](https://mail.coreboot.org/hyperkitty/list/coreboot@coreboot.org/thread/SV6XH6UYLDN73EQWJ2HNVBXFJ6CHWNP5/)


* [Sheng] Need feedback on how to move ahead with hostbridge resources
allocation in UEFI payload. Patrick has submitted a WA:
[https://github.com/9elements/edk2/commit/070ce932bdf0feb13c47bcd172c55319cef60976#diff-45b1ff71ae85b29fa6829229109c6e404bbe51baa489fe9014cc5aae33a97a1b](https://github.com/9elements/edk2/commit/070ce932bdf0feb13c47bcd172c55319cef60976#diff-45b1ff71ae85b29fa6829229109c6e404bbe51baa489fe9014cc5aae33a97a1b)
* The path forward is to report the right resources from coreboot
to edk2 payload
* chain loading was suggested earlier, but doesn't seem to have
been worked on?
* Could this be a GSOC project?
* Add devicetree to CBMEM for something to parse into a format
that the UEFI payload can use?
* Why is chain-loading needed?
* [Martin] Maybe it isn’t.  Chain loading was suggested for
adding a parser for coreboot data and turning it into something that
can be used by the EDK2 payload.


* [Daniel] Trammell Hudson is working on Getting UEFI mapped into
linux.  Coreboot could boot into something that provides a UEFI
environment, then into linux, which could then load other operating
systems.
* You can talk to him on the Efi boot support channel in slack.
* [Nate] Might need to save the efi memory map so that data isn’t
lost when converting to an e820 memory map and back. Linux may rely on
GRUB doing that - so look into GRUB.
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org