[coreboot] [coreboot - Bug #549] coreboot 24.05: SeaBIOS Windows 10/11 BSOD "ACPI BIOS ERROR" (Thinkpad W530)

[Matt DeVillier]

Issue #549 has been updated by Matt DeVillier.


> You're talking about `Devices --> Graphics initialization`, right? That's 
> probably it - I didn't touch that and by default is set to "Run VGA Option 
> ROMS".
> 
> Btw, if I use the me_cleaner script to shrink the me, what should the size of 
> cbfs be set to take up the free space?

edk2 requires a graphical framebuffer, either libgfxinit w/linear high-res 
framebuffer, or VGA BIOS with a VESA mode set. The latter is not recommended, 
nor the default when edk2 is selected as the payload from a clean config.

don't mess with ME cleaner until you have coreboot working properly, no need to 
add another variable to the mix. the CBFS size can be set plenty large enough 
for edk2 (2MB should suffice) without needed to shrink the ME region / enlarge 
the bios region.

here is a sane defconfig for W530 + edk2:

CONFIG_VENDOR_LENOVO=y
CONFIG_CBFS_SIZE=0x20
CONFIG_BOARD_LENOVO_W530=y
CONFIG_PAYLOAD_EDK2=y
CONFIG_EDK2_BOOT_MANAGER_ESCAPE=y
CONFIG_EDK2_FOLLOW_BGRT_SPEC=y
# CONFIG_EDK2_FULL_SCREEN_SETUP is not set

obviously since no IFD/ME blobs are included, you would just flash the bios 
region (using `--ifd -i bios`)


Bug #549: coreboot 24.05: SeaBIOS Windows 10/11 BSOD "ACPI BIOS ERROR" 
(Thinkpad W530)
https://ticket.coreboot.org/issues/549#change-1876

* Author: Simon Dominic
* Status: New
* Priority: Normal
* Category: board support
* Target version: master
* Start date: 2024-07-31
* Affected versions: master
* Affected hardware: Lenovo ThinkPad W530
* Affected OS: Windows 10/11

When using the latest coreboot (i.e. using command `git clone 
https://review.coreboot.org/coreboot`), which is currently 24.05, to build a 
rom for Thinkpad W530, I get BSOD with "ACPI BIOS ERROR" when trying to boot 
into Windows 10 or 11 from SeaBIOS. Even just booting from a Windows install 
usb will show this error.

This is even with incorporating the vga bios files (so i can external displays 
to work) - see my defconfig.

Did consider using EDK2 apparently Windows support is pretty solid, but could 
never make a successful build - not that `make` command had errors, but once 
flashing, would just having white underscore and have to recover with external 
flashing. A separate issue to write about in and of itself, but I prefer 
SeaBIOS so I'll be sticking with that.

I am quite new to coreboot - using for only about 2-3 months now. Let me know 
if there is further information I should provide.

---Files
defconfig (590 Bytes)
w530_bsod.jpg (1.98 MB)
dsl_files.zip (25 KB)


-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
https://ticket.coreboot.org/my/account
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] [coreboot - Bug #549] coreboot 24.05: SeaBIOS Windows 10/11 BSOD "ACPI BIOS ERROR" (Thinkpad W530)

[Matt DeVillier]

Issue #549 has been updated by Matt DeVillier.


Simon Dominic wrote:
> When using the latest coreboot (i.e. using command `git clone 
> https://review.coreboot.org/coreboot`), which is currently 24.05, to build a 
> rom for Thinkpad W530, I get BSOD with "ACPI BIOS ERROR" when trying to boot 
> into Windows 10 or 11 from SeaBIOS. Even just booting from a Windows install 
> usb will show this error.
> 
> This is even with incorporating the vga bios files (so i can external 
> displays to work) - see my defconfig.
> 
> Did consider using EDK2 apparently Windows support is pretty solid, but could 
> never make a successful build - not that `make` command had errors, but once 
> flashing, would just having white underscore and have to recover with 
> external flashing. A separate issue to write about in and of itself, but I 
> prefer SeaBIOS so I'll be sticking with that.
> 
> I am quite new to coreboot - using for only about 2-3 months now. Let me know 
> if there is further information I should provide.

quite simply, coreboot's ACPI for your device booted in legacy BIOS mode isn't 
Windows compliant. Boot linux, install acpica-tools, run `sudo acpidump -b` 
then `sudo iasl -d *.dat` and zip/attach the resulting .dsl files here.

IMO edk2 is the better choice for running Win10/11, and is known to work well. 
A flashing cursor sounds like you changed the display mode to text vs 
graphical, or didn't reset your config when changing payloads. edk2 + 
libgfxinit with defaults should boot Windows on your device.


Bug #549: coreboot 24.05: SeaBIOS Windows 10/11 BSOD "ACPI BIOS ERROR" 
(Thinkpad W530)
https://ticket.coreboot.org/issues/549#change-1873

* Author: Simon Dominic
* Status: New
* Priority: Normal
* Category: board support
* Target version: master
* Start date: 2024-07-31
* Affected versions: master
* Affected hardware: Lenovo ThinkPad W530
* Affected OS: Windows 10/11

When using the latest coreboot (i.e. using command `git clone 
https://review.coreboot.org/coreboot`), which is currently 24.05, to build a 
rom for Thinkpad W530, I get BSOD with "ACPI BIOS ERROR" when trying to boot 
into Windows 10 or 11 from SeaBIOS. Even just booting from a Windows install 
usb will show this error.

This is even with incorporating the vga bios files (so i can external displays 
to work) - see my defconfig.

Did consider using EDK2 apparently Windows support is pretty solid, but could 
never make a successful build - not that `make` command had errors, but once 
flashing, would just having white underscore and have to recover with external 
flashing. A separate issue to write about in and of itself, but I prefer 
SeaBIOS so I'll be sticking with that.

I am quite new to coreboot - using for only about 2-3 months now. Let me know 
if there is further information I should provide.

---Files
defconfig (590 Bytes)
w530_bsod.jpg (1.98 MB)


-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
https://ticket.coreboot.org/my/account
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Enforcing coreboot as lowercase

[Matt DeVillier]

AFAIK the project name has been all lowercase from the start, and I don't
see a compelling reason here to change it. To my eyes, it looks
strange/wrong when started with a capital C.

Phoronix et all can continue being wrong =D

On Thu, Jul 4, 2024, 12:53 PM Arthur Heymans  wrote:

> Hi
>
> Thanks for the reply.
>
> Are you proposing to give up trying to defend the spelling of the
>> project's name because too many people write it wrong and educating
>> them is too much effort? If so, I think this is a self-defeating
>> attitude and I completely disagree with it.
>
>
> Language is not a set in stone thing. There are default grammatical rules
> on how to write things and sometimes it is worth it to override the rules
> as I explained.
> It's basically a trade-off.
> There is no right and wrong here, except maybe from a trademark
> perspective, which most people are unaware of.
> Later I make the case that even from a trademark perspective I don't think
> it matters.
> I'm making the case that enforcing to write "coreboot" lowercase has more
> downsides than upsides, which is why I propose to allow "Coreboot" at the
> start of a sentence.
> Personally I think educating people about a trademark thing is superfluous
> work.
> Also in my personal communication it's a conundrum.
> For instance if I write a blog post I don't want to look like I'm making
> silly grammatical mistakes to those that haven't looked into the trademark
> registry (which almost no one does).
> At the same time I don't want to explain the trademark either as I think
> it blunts communicative efficiency.
>
> Or is it that the trademark only covers the all-lowercase "coreboot"
>> spelling, so one can use a name like "CoReboot" (e.g. for something
>> unrelated) without infringing the "coreboot" trademark? In that case,
>> making the trademark case-insensitive makes sense.
>>
>
> So currently the only reason lowercase coreboot is enforced is because
> that's how the trademark was obtained.
> I'm using the argument that trademark interpretation is typically broad
> and allows for using an uppercase letter at the start of a sentence since
> that's what grammatical rules want.
> So I think "Coreboot" is very much covered by the "coreboot" trademark.
>
> Arthur Heymans
>
>
> On Thu, Jul 4, 2024 at 7:19 PM Angel Pons  wrote:
>
>> Hi,
>>
>> On Thu, Jul 4, 2024 at 3:48 PM Arthur Heymans 
>> wrote:
>> >
>> > Hi
>> >
>> > The coreboot trademark is registered as lowercase.
>> > We enforce this in for instance commits, even when normal grammar would
>> dictate uppercase at the start of a sentence.
>> >
>> > This makes sense for very well known brands, companies and products
>> like "eBay", "iPhone", "AMD". They are all very well known trademarks and
>> they have some uppercase letter in them in atypical places. For these words
>> grammar exceptions seems reasonable.
>> >
>> > Coreboot is a reasonably well known as a project, but little people
>> know about the specificity of the trademark. This often causes confusion on
>> people either reading "coreboot" at the start of a sense, where it looks
>> grammatically wrong, making it even look unprofessional in the eyes of
>> some. This is because there is no other uppercase letter inside coreboot
>> that would make it a typical exception to regular grammar rules.
>> >
>> > People getting into the project making the mistake at the start of a
>> sentence, might get the wrong impression of too many idiosyncrasies. On top
>> of that it takes a non zero amount of effort on people in the project to
>> educate others on this trademark thing.
>> >
>> > Also trademark are typically a bit more broad than exactly how they are
>> registered. I cannot start a company called iNTel or aMD that makes chips.
>> I cannot put a product on the market called "IPHoNE". I think the same
>> applies to "coreboot".
>> >
>> > So my question is: can we relax the trademark in lowercase enforcement?
>> I would suggest to simply allow both ways.
>>
>> I am not sure if I understood you correctly.
>>
>> Are you proposing to give up trying to defend the spelling of the
>> project's name because too many people write it wrong and educating
>> them is too much effort? If so, I think this is a self-defeating
>> attitude and I completely disagree with it.
>>
>> Or is it that the trademark only covers the all-lowercase "coreboot"
>> spelling, so one can use a name like "CoReboot" (e.g. for something
>> unrelated) without infringing the "coreboot" trademark? In that case,
>> making the trademark case-insensitive makes sense.
>>
>> Or is it something else? Then... *confused noises*
>>
>> > Arthur Heymans
>> > ___
>> > coreboot mailing list -- coreboot@coreboot.org
>> > To unsubscribe send an email to coreboot-le...@coreboot.org
>>
>> Best regards,
>> Angel
>>
> ___
> coreboot mailing list -- coreboot@coreboot.org
> To unsubscribe send an email to 

[coreboot] MrChromebox-2405 Release Announcement

[Matt DeVillier]

As coreboot changed its version numbering to a YYMM scheme earlier this
year, MrChromebox releases will now do the same.

This new release is based on the coreboot 24.05 tag (May 2024) and now
supports well over 300 different devices. It includes the following notable
changes:

- Rebased on coreboot tag 24.05
- Added support for several new Intel Jasperlake boards (beadrix, boxy,
dexi, peezer, taranza)
- Added latest Google-built EC-RW updates for all Jasperlake boards
- Updated the EC-RW firmware for Fizz boards (Intel 7th/8th-gen Chromeboxes)
- Updated the EC-RW firmware for Zork boards (AMD Picasso)
- Updated the signed PSP verstage binaries for Zork/Guybrush boards (AMD
Picasso, Cezanne)
- Updated EC-RW software update code for improved compatibility
- Fixed SMBUS subsystem ID on several Sandy/Ivybridge Chromebooks
- Increased the UMA VRAM to 128MB on Zork boards (AMD Picasso boards)
- Filtered out some spurious error messages in the coreboot console log

All source code (and blobs) for coreboot, edk2, and Chrome-EC can be found
on my github repos:
https://github.com/MrChromebox/coreboot/commits/MrChromebox-2405
https://github.com/MrChromebox/edk2/commits/uefipayload_2402
https://github.com/MrChromebox/chrome-ec/branches/all
https://github.com/MrChromebox/blobs/

For device compatibility and installation, see https://mrchromebox.tech

cheers,
Matt
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] [coreboot - Bug #537] (Rejected) build failed with successfully built edk2 payload?!?

[Matt DeVillier]

Issue #537 has been updated by Matt DeVillier.

Status changed from New to Rejected


Bug #537: build failed with successfully built edk2 payload?!?
https://ticket.coreboot.org/issues/537#change-1826

* Author: Klaus Frank
* Status: Rejected
* Priority: Normal
* Target version: none
* Start date: 2024-05-08

Hi,

I get the following error when trying to build coreboot together with the edk2 
payload. It looks like it is compiling the wrong version of edk2 and thereby 
missing 
`payloads/external/edk2/workspace/Build/UefiPayloadPkgX64/UniversalPayload.elf` 
even though edk2 itself built successfully.

```
--
Ran 303 tests in 2.593s

OK
make[3]: Leaving directory 
'/home/user/fw_test/coreboot/payloads/external/edk2/workspace/tianocore/BaseTools/Tests'
make[2]: Leaving directory 
'/home/user/fw_test/coreboot/payloads/external/edk2/workspace/tianocore/BaseTools'
   # edk2 Build Summary #
   Repository: https://github.com/tianocore/edk2
   Branch: origin/master
   Packages path:  
/home/user/fw_test/coreboot/payloads/external/edk2/workspace/tianocore
 
   Option: BOOTLOADER=COREBOOT 
   Option: BOOTSPLASH_IMAGE=TRUE 
   Option: CPU_TIMER_LIB_ENABLE=FALSE 
   Option: DISABLE_SERIAL_TERMINAL=TRUE 
   Option: PLATFORM_BOOT_TIMEOUT=2 
   Option: PS2_KEYBOARD_ENABLE=TRUE 
   Option: SD_MMC_TIMEOUT=1 
   Option: SIO_BUS_ENABLE=TRUE 
   Pcd:gEfiMdeModulePkgTokenSpaceGuid.PcdConOutColumn=0 
   Pcd:gEfiMdeModulePkgTokenSpaceGuid.PcdConOutRow=0 
   Pcd:gEfiMdeModulePkgTokenSpaceGuid.PcdMaxVariableSize=0x8000 
   Pcd:gEfiMdeModulePkgTokenSpaceGuid.PcdSetupConOutColumn=0
   Pcd:gEfiMdeModulePkgTokenSpaceGuid.PcdSetupConOutRow=0 
   Pcd:gEfiMdePkgTokenSpaceGuid.PcdPciExpressBaseAddress=0xf000 
   Pcd:gEfiMdePkgTokenSpaceGuid.PcdPciExpressBaseSize=0x0400 
   Build:  Quiet
   Toolchain:  COREBOOT 
Loading previous configuration from 
/home/user/fw_test/coreboot/payloads/external/edk2/workspace/tianocore/Conf/BuildEnv.sh
Using EDK2 in-source Basetools
WORKSPACE: /home/user/fw_test/coreboot/payloads/external/edk2/workspace
EDK_TOOLS_PATH: 
/home/user/fw_test/coreboot/payloads/external/edk2/workspace/tianocore/BaseTools
CONF_PATH: 
/home/user/fw_test/coreboot/payloads/external/edk2/workspace/tianocore/Conf
EDK2: Building... python_exe=python3
build -p UefiPayloadPkg/UefiPayloadPkg.dsc -b RELEASE -a IA32 -a X64 -t 
COREBOOT -y 
/home/user/fw_test/coreboot/payloads/external/edk2/workspace/Build/UefiPayloadPkgIA32/UefiUniversalPayload.txt
 --quiet --pcd gEfiMdeModulePkgTokenSpaceGuid.PcdMaxVariableSize=0x8000 --pcd 
gEfiMdePkgTokenSpaceGuid.PcdPciExpressBaseAddress=0xf000 --pcd 
gEfiMdePkgTokenSpaceGuid.PcdPciExpressBaseSize=0x0400 --pcd 
gEfiMdeModulePkgTokenSpaceGuid.PcdConOutRow=0 --pcd 
gEfiMdeModulePkgTokenSpaceGuid.PcdConOutColumn=0 --pcd 
gEfiMdeModulePkgTokenSpaceGuid.PcdSetupConOutRow=0 --pcd 
gEfiMdeModulePkgTokenSpaceGuid.PcdSetupConOutColumn=0 -D BUILD_ARCH=IA32 -D 
UNIVERSAL_PAYLOAD=TRUE -D BOOTLOADER=COREBOOT -D BOOTSPLASH_IMAGE=TRUE -D 
CPU_TIMER_LIB_ENABLE=FALSE -D DISABLE_SERIAL_TERMINAL=TRUE -D 
PS2_KEYBOARD_ENABLE=TRUE -D PLATFORM_BOOT_TIMEOUT=2 -D SIO_BUS_ENABLE=TRUE -D 
SD_MMC_TIMEOUT=1 -D UNIVERSAL_PAYLOAD_FORMAT=ELF
Build environment: Linux-6.8.8-arch1-1-x86_64-with-glibc2.39
Build start time: 03:06:31, May.08 2024

WORKSPACE= /home/user/fw_test/coreboot/payloads/external/edk2/workspace
PACKAGES_PATH= 
/home/user/fw_test/coreboot/payloads/external/edk2/workspace/tianocore
EDK_TOOLS_PATH   = 
/home/user/fw_test/coreboot/payloads/external/edk2/workspace/tianocore/BaseTools
CONF_PATH= 
/home/user/fw_test/coreboot/payloads/external/edk2/workspace/tianocore/Conf
PYTHON_COMMAND   = python3

Processing meta-data  done!
Building ... 
/home/user/fw_test/coreboot/payloads/external/edk2/workspace/tianocore/MdePkg/Library/UefiDriverEntryPoint/UefiDriverEntryPoint.inf
 [X64]
Building ... 
/home/user/fw_test/coreboot/payloads/external/edk2/workspace/tianocore/MdeModulePkg/Library/RuntimeDxeReportStatusCodeLib/RuntimeDxeReportStatusCodeLib.inf
 [X64]
Building ... 
/home/user/fw_test/coreboot/payloads/external/edk2/workspace/tianocore/MdePkg/Library/UefiRuntimeLib/UefiRuntimeLib.inf
 [X64]
Building ... 
/home/user/fw_test/coreboot/payloads/external/edk2/workspace/tianocore/MdePkg/Library/UefiDevicePathLib/UefiDevicePathLib.inf
 [X64]
Building ... 
/home/user/fw_test/coreboot/payloads/external/edk2/workspace/tianocore/MdePkg/Library/UefiRuntimeServicesTableLib/UefiRuntimeServicesTableLib.inf
 [X64]
Building ... 
/home/user/fw_test/coreboot/payloads/external/edk2/workspace/tianocore/MdePkg/Library/UefiBootServicesTableLib/UefiBootServicesTableLib.inf

[coreboot] [coreboot - Bug #537] build failed with successfully built edk2 payload?!?

[Matt DeVillier]

Issue #537 has been updated by Matt DeVillier.


You've selected a bunch of non-default options that don't play well together, 
and the result is a failed build.
The UniversalPayload edk2 option only works with Starlabs' fork.
Upstream edk2 is always in a state of flux and may or may not build (usually 
does) / may or may not boot.
The MrChromebox edk2 fork is the default for a good reason.



Bug #537: build failed with successfully built edk2 payload?!?
https://ticket.coreboot.org/issues/537#change-1825

* Author: Klaus Frank
* Status: New
* Priority: Normal
* Target version: none
* Start date: 2024-05-08

Hi,

I get the following error when trying to build coreboot together with the edk2 
payload. It looks like it is compiling the wrong version of edk2 and thereby 
missing 
`payloads/external/edk2/workspace/Build/UefiPayloadPkgX64/UniversalPayload.elf` 
even though edk2 itself built successfully.

```
--
Ran 303 tests in 2.593s

OK
make[3]: Leaving directory 
'/home/user/fw_test/coreboot/payloads/external/edk2/workspace/tianocore/BaseTools/Tests'
make[2]: Leaving directory 
'/home/user/fw_test/coreboot/payloads/external/edk2/workspace/tianocore/BaseTools'
   # edk2 Build Summary #
   Repository: https://github.com/tianocore/edk2
   Branch: origin/master
   Packages path:  
/home/user/fw_test/coreboot/payloads/external/edk2/workspace/tianocore
 
   Option: BOOTLOADER=COREBOOT 
   Option: BOOTSPLASH_IMAGE=TRUE 
   Option: CPU_TIMER_LIB_ENABLE=FALSE 
   Option: DISABLE_SERIAL_TERMINAL=TRUE 
   Option: PLATFORM_BOOT_TIMEOUT=2 
   Option: PS2_KEYBOARD_ENABLE=TRUE 
   Option: SD_MMC_TIMEOUT=1 
   Option: SIO_BUS_ENABLE=TRUE 
   Pcd:gEfiMdeModulePkgTokenSpaceGuid.PcdConOutColumn=0 
   Pcd:gEfiMdeModulePkgTokenSpaceGuid.PcdConOutRow=0 
   Pcd:gEfiMdeModulePkgTokenSpaceGuid.PcdMaxVariableSize=0x8000 
   Pcd:gEfiMdeModulePkgTokenSpaceGuid.PcdSetupConOutColumn=0
   Pcd:gEfiMdeModulePkgTokenSpaceGuid.PcdSetupConOutRow=0 
   Pcd:gEfiMdePkgTokenSpaceGuid.PcdPciExpressBaseAddress=0xf000 
   Pcd:gEfiMdePkgTokenSpaceGuid.PcdPciExpressBaseSize=0x0400 
   Build:  Quiet
   Toolchain:  COREBOOT 
Loading previous configuration from 
/home/user/fw_test/coreboot/payloads/external/edk2/workspace/tianocore/Conf/BuildEnv.sh
Using EDK2 in-source Basetools
WORKSPACE: /home/user/fw_test/coreboot/payloads/external/edk2/workspace
EDK_TOOLS_PATH: 
/home/user/fw_test/coreboot/payloads/external/edk2/workspace/tianocore/BaseTools
CONF_PATH: 
/home/user/fw_test/coreboot/payloads/external/edk2/workspace/tianocore/Conf
EDK2: Building... python_exe=python3
build -p UefiPayloadPkg/UefiPayloadPkg.dsc -b RELEASE -a IA32 -a X64 -t 
COREBOOT -y 
/home/user/fw_test/coreboot/payloads/external/edk2/workspace/Build/UefiPayloadPkgIA32/UefiUniversalPayload.txt
 --quiet --pcd gEfiMdeModulePkgTokenSpaceGuid.PcdMaxVariableSize=0x8000 --pcd 
gEfiMdePkgTokenSpaceGuid.PcdPciExpressBaseAddress=0xf000 --pcd 
gEfiMdePkgTokenSpaceGuid.PcdPciExpressBaseSize=0x0400 --pcd 
gEfiMdeModulePkgTokenSpaceGuid.PcdConOutRow=0 --pcd 
gEfiMdeModulePkgTokenSpaceGuid.PcdConOutColumn=0 --pcd 
gEfiMdeModulePkgTokenSpaceGuid.PcdSetupConOutRow=0 --pcd 
gEfiMdeModulePkgTokenSpaceGuid.PcdSetupConOutColumn=0 -D BUILD_ARCH=IA32 -D 
UNIVERSAL_PAYLOAD=TRUE -D BOOTLOADER=COREBOOT -D BOOTSPLASH_IMAGE=TRUE -D 
CPU_TIMER_LIB_ENABLE=FALSE -D DISABLE_SERIAL_TERMINAL=TRUE -D 
PS2_KEYBOARD_ENABLE=TRUE -D PLATFORM_BOOT_TIMEOUT=2 -D SIO_BUS_ENABLE=TRUE -D 
SD_MMC_TIMEOUT=1 -D UNIVERSAL_PAYLOAD_FORMAT=ELF
Build environment: Linux-6.8.8-arch1-1-x86_64-with-glibc2.39
Build start time: 03:06:31, May.08 2024

WORKSPACE= /home/user/fw_test/coreboot/payloads/external/edk2/workspace
PACKAGES_PATH= 
/home/user/fw_test/coreboot/payloads/external/edk2/workspace/tianocore
EDK_TOOLS_PATH   = 
/home/user/fw_test/coreboot/payloads/external/edk2/workspace/tianocore/BaseTools
CONF_PATH= 
/home/user/fw_test/coreboot/payloads/external/edk2/workspace/tianocore/Conf
PYTHON_COMMAND   = python3

Processing meta-data  done!
Building ... 
/home/user/fw_test/coreboot/payloads/external/edk2/workspace/tianocore/MdePkg/Library/UefiDriverEntryPoint/UefiDriverEntryPoint.inf
 [X64]
Building ... 
/home/user/fw_test/coreboot/payloads/external/edk2/workspace/tianocore/MdeModulePkg/Library/RuntimeDxeReportStatusCodeLib/RuntimeDxeReportStatusCodeLib.inf
 [X64]
Building ... 
/home/user/fw_test/coreboot/payloads/external/edk2/workspace/tianocore/MdePkg/Library/UefiRuntimeLib/UefiRuntimeLib.inf
 [X64]
Building ... 
/home/user/fw_test/coreboot/payloads/external/edk2/workspace/tianocore/MdePkg/Library/UefiDevicePathLib/UefiDevicePathLib.inf
 [X64]
Building

[coreboot] Re: Porting Coreboot to a Mini PC

[Matt DeVillier]

you are of course free to do exactly that, or my MrChromebox firmware if
you prefer coreboot + UEFI. But ultimately, the only reason you have that
option is because others felt it was worth the additional price to support
the company paying for the coreboot development., so you might consider
donating to the SFF, coreboot.org, or whosever work you decide to use "for
free"

On Sat, Apr 20, 2024 at 12:23 PM Mason Corkern  wrote:

> yeah no thanks. I'll just buy the $300 exact hardware and then flash the
> firmware from Purism's website for free and save a bunch of money 
>
> Thanks,
> Mason Corkern
> ------
> *From:* Matt DeVillier 
> *Sent:* Wednesday, April 3, 2024 8:36 PM
> *To:* Mason Corkern 
> *Cc:* coreboot 
> *Subject:* Re: [coreboot] Porting Coreboot to a Mini PC
>
> *[EXTERNAL SENDER]*
> that's still going to cost more than $400. Add a zero and I'll think about
> it ;-)
>
> On Wed, Apr 3, 2024, 7:30 PM Mason Corkern  wrote:
>
> Yeah, I only want the port, not ongoing support.
>
> Thanks,
> Mason Corkern
> --
> *From:* Matt DeVillier 
> *Sent:* Wednesday, April 3, 2024 8:25 PM
> *To:* Mason Corkern 
> *Cc:* coreboot@coreboot.org 
> *Subject:* Re: [coreboot] Porting Coreboot to a Mini PC
>
> *[EXTERNAL SENDER]*
> The minisforum MiniPC you have linked is a completely different device
> from the one offered by Purism/Nitrokey; the only thing similar is the form
> factor.
>
> coreboot support has to be added on a per-mainboard basis, so the
> Minisforum device you linked would need to be ported by someone who
> understands coreboot and x86 firmware (or who has a lot of free time to
> learn). And the mainboard on the device would need to be unencumbered by
> things like Intel Bootguard (which fortunately IME most devices like that
> are, but it's not a guarantee).
>
> If you want not just a coreboot port, but ongoing support, it's going to
> cost you a heck of a lot more than the $400 you think Purism/Nitrokey are
> "overcharging" by. And I say that as the developer who did the initial port
> on the Purism Librem Mini/Mini v2 boards.
>
> -Matt
> (speaking on behalf of myself, not any present or past employer)
>
> On Wed, Apr 3, 2024 at 5:43 PM Mason Corkern  wrote:
>
> Greetings,
>
> I recently purchased a Mini PC from mini forums, a company based in Hong
> Kong [1]. I want to replace their custom BIOS with Coreboot since it's
> FOSS. Prisim and Nitro has been able to install Coreboot, but they said
> they did a custom port for the motherboard/cpu and they overcharge by $400
> and justify it due to the R spent on porting Coreboot to the minipc [2].
> Has anyone tried porting Coreboot for similar boars and/or made a tutorial?
> I couldn't find it when I googled around and looked in docs.
>
>
>
>1. Minisforum NAB6/NPB7 Intel i7-12650H/Intel i7-13700H
>
> <https://store.minisforum.com/products/minisforum-nab6?variant=44164535288053>
>2. Purism– Librem Mini <https://puri.sm/products/librem-mini/> and NitroPC
>1 | shop.nitrokey.com <https://shop.nitrokey.com/shop/nitropc-1-132>.
>3.
>
> Thanks,
> Mason Corkern
> ___
> coreboot mailing list -- coreboot@coreboot.org
> To unsubscribe send an email to coreboot-le...@coreboot.org
>
>
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Linux boot delayed by value of generic.reset_off_delay_ms (touchscreen reset)?

[Matt DeVillier]

On Tue, Dec 5, 2023 at 12:39 PM Paul Menzel  wrote:

> Dear coreboot folks,
>
>
> On the Dell Latitude 5430 Chromebook (google/brya/var/crota) there is a
> delay of 160 ms during startup in the Linux kernel [1]:
>
>  [0.00] microcode: microcode updated early to revision
> 0x430, date = 2023-06-07
>  [0.00] Linux version 5.15.124-20281-g306376f9e9db
> (chrome-bot@chromeos-release-builder-us-central1-c-x32-9-oel9) (Chromium
> OS 17.0_pre496208_p20230501-r16 clang version 17.0.0
> (/mnt/host/source/src/third_party/llvm-project
> 98f5a340975bc00197c57e39eb4ca26e2da0e8a2), LLD 17.0.0) #1 SMP PREEMPT
> Mon Oct 2 18:31:36 PDT 2023
>  […]
>  [0.150271] ACPI: PM: Power Resource [PR00]
>  [0.313289] ACPI: PM: Power Resource [PR01]
>
> A @google.com person commented, that this *could* be caused by the reset
> delay of the ELAN touchscreen. From
>
> `src/third_party/coreboot/src/mainboard/google/brya/variants/crota/overridetree.cb`:
>
> device ref i2c3 on
> chip drivers/i2c/hid
> register "generic.hid" = ""ELAN900C""
> register "generic.desc" = ""ELAN
> Touchscreen""
> register "generic.irq" =
> "ACPI_IRQ_LEVEL_LOW(GPP_C7_IRQ)"
> register "generic.detect" = "1"
> register "generic.reset_gpio" =
>
> "ACPI_GPIO_OUTPUT_ACTIVE_LOW(GPP_C1)"
> register "generic.reset_delay_ms" = "150"
> register "generic.reset_off_delay_ms" = "1"
> register "generic.enable_gpio" =
>
> "ACPI_GPIO_OUTPUT_ACTIVE_HIGH(GPP_C0)"
> register "generic.enable_delay_ms" = "6"
> register "generic.stop_gpio" =
>
> "ACPI_GPIO_OUTPUT_ACTIVE_LOW(GPP_C6)"
> register "generic.stop_off_delay_ms" = "1"
> register "generic.has_power_resource" = "1"
> register "hid_desc_reg_offset" = "0x01"
> device i2c 0x16 on end
> end
> end
>
> As I have been bitten the last time, I tried to flash a Dell Chromebook,
> I am weary to test, so I am asking here.
>

CROTA has been tested using my MrChromebox upstream-based firmware, you
shouldn't have any issues booting it


>
> > The delay is unavoidable, although I suppose there's room for
> > improvement on making ACPI power sequencing parallelizable or
> > otherwise deferring it until the device is actually getting probed
> > (preferably using asynchronous probe, since this is a slow device --
> > ChromeOS tends to configure touchscreen drivers for async probe
> > already, or else loaded as modules).
> >
> > Perhaps you can take this problem upstream if you'd like to work on
> > something, but from a ChromeOS perspective this is either Intended
> > Behavior or a Feature Request. I don't think we're interested in
> > tracking this as a Feature Request here.
>

IMO ChromeOS should drop the "probed" flag nonsense and implement TS power
sequencing and detection in coreboot for all devices going forward.


>
> During startup this reset delay should not hold up the boot, should it?
> Could the firmware reset the touchscreen, and somehow message the OS,
> that it’s not needed anymore?
>

What the OS driver does with the delay value isn't something coreboot can
really control. The Linux drivers assume nothing has been done and perform
their own power sequencing, regardless of whether coreboot has already done
it (which in most cases now, it has). The Linux drivers skipping power
sequencing would likely require a new ACPI flag to be added to both the
drivers and the firmware / ACPI device.


>
>
> Kind regards,
>
> Paul
>
>
> [1]: https://issuetracker.google.com/issues/303565666
>
>
> PS: I was unable to change the issue title to correct PR01 to PR00.
> ___
> coreboot mailing list -- coreboot@coreboot.org
> To unsubscribe send an email to coreboot-le...@coreboot.org
>
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] [coreboot - Bug #517] lenovo x230 boot stuck with connected external monitor

[Matt DeVillier]

Issue #517 has been updated by Matt DeVillier.


> No, I haven't tried other payloads like embedded grub, but it doesn't reach 
> coreboot boot menu (where I can run memtest for example).

that's not the coreboot boot menu, it's the SeaBIOS one.

> It seems that something broken in video adapter init (intel core graphics) 
> because if I boot with external monitor detached then boot succeeded.
> Monitor detach after boot start doesn't solve the problem.

can you pull a cbmem log after a failed boot? Compile with ADA debug enabled as 
well


Bug #517: lenovo x230 boot stuck with connected external monitor
https://ticket.coreboot.org/issues/517#change-1714

* Author: Vasily Evseenko
* Status: New
* Priority: High
* Target version: none
* Start date: 2023-12-04
* Affected versions: 4.21
* Affected hardware: Lenovo x230
* Affected OS: any

Coreboot releases 4.21 and 4.22.01 have a bug.
If lenovo x230 laptop has connected external monitor then boot stuck on Seabios 
greeting.
Boot without external monitor always succeeded.
Last release without bug is 4.20.1
Coreboot config attached.

---Files
.config (19.4 KB)


-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
https://ticket.coreboot.org/my/account
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] [coreboot - Bug #517] lenovo x230 boot stuck with connected external monitor

[Matt DeVillier]

Issue #517 has been updated by Matt DeVillier.


have you tried other payloads? This might be a SeaBIOS issue and not a coreboot 
one.



Bug #517: lenovo x230 boot stuck with connected external monitor
https://ticket.coreboot.org/issues/517#change-1712

* Author: Vasily Evseenko
* Status: New
* Priority: High
* Target version: none
* Start date: 2023-12-04
* Affected versions: 4.21
* Affected hardware: Lenovo x230
* Affected OS: any

Coreboot releases 4.21 and 4.22.01 have a bug.
If lenovo x230 laptop has connected external monitor then boot stuck on Seabios 
greeting.
Boot without external monitor always succeeded.
Last release without bug is 4.20.1
Coreboot config attached.

---Files
.config (19.4 KB)


-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
https://ticket.coreboot.org/my/account
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] [coreboot - Bug #516] brya/var/crota: `ACPI BIOS Error (bug): Failure creating named object [\_SB.MPTS], AE_ALREADY_EXISTS (20210730/dswload2-327)`

[Matt DeVillier]

Issue #516 has been updated by Matt DeVillier.





hi Paul,



can you check if this is exists with upstream coreboot as well? It's somewhat 
hard to debug Google's downstream firmware given it's branched off. If the 
issue doesn't exist upstream, I'd recommend filing an issue at 
https://issuetracker.google.com/issues.





Bug #516: brya/var/crota: `ACPI BIOS Error (bug): Failure creating named object 
[\_SB.MPTS], AE_ALREADY_EXISTS (20210730/dswload2-327)`

https://ticket.coreboot.org/issues/516#change-1708



* Author: Paul Menzel

* Status: New

* Priority: Normal

* Target version: none

* Start date: 2023-12-02



On the Dell Latitude 5430 Chromebook (brya/var/crota) with ChromeOS, Linux 
5.15.133 reports an ACPI error:



[0.00] Linux version 5.15.133-20573-g839a3133d611 
(chrome-bot@chromeos-release-builder-us-central1-a-x32-6-ibti) (Chromium OS 
17.0_pre498229-r6 clang version 17.0.0 
(/mnt/host/source/src/third_party/llvm-project 
14f0776550b5a49e1c42f49a00213f7f3fa047bf), LLD 17.0.0) #1 SMP PREEMPT Sun Nov 
26 18:55:03 PST 2023

2023-12-01T11:43:58.591525Z INFO kernel: [0.00] Command line: 
cros_secure console= loglevel=7 init=/sbin/init cros_secure drm.trace=0x106 
root=/dev/dm-0 rootwait ro dm_verity.error_behavior=3 dm_verity.max_bios=-1 
dm_verity.dev_wait=1 dm="1 vroot none ro 1,0 6348800 verity 
payload=PARTUUID=12e8cf21-bcc0-49b5-85bb-56fb8102f7d4/PARTNROFF=1 
hashtree=PARTUUID=12e8cf21-bcc0-49b5-85bb-56fb8102f7d4/PARTNROFF=1 
hashstart=6348800 alg=sha256 
root_hexdigest=4ad313ce4c441485f2be87533efe22a0d8b61bffb78260d17ccd2672e7edb538 
salt=8051d68355ccfca99de821939b957ff34d38b866a2951a595e4c0613a1c51f97" noinitrd 
vt.global_cursor_default=0 kern_guid=12e8cf21-bcc0-49b5-85bb-56fb8102f7d4 
add_efi_memmap noresume i915.modeset=1 ramoops.ecc=1 tpm_tis.force=0 
intel_pmc_core.warn_on_s0ix_failures=1 i915.enable_guc=3 i915.enable_dc=4 
xdomain=0 swiotlb=65536 intel_iommu=on i915.enable_psr=1

[…]

[0.00] DMI: Google Crota/Crota, BIOS Google_Crota.14505.456.0 
04/21/2023

[…]

[0.146114] ACPI BIOS Error (bug): Failure creating named object 
[\_SB.MPTS], AE_ALREADY_EXISTS (20210730/dswload2-327)

[0.146117] ACPI Error: AE_ALREADY_EXISTS, During name lookup/catalog 
(20210730/psobject-220)

[…]







-- 

You have received this notification because you have either subscribed to it, 
or are involved in it.

To change your notification preferences, please click here: 
https://ticket.coreboot.org/my/account

___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Jasper Lake: Commit 21e61847 (ramtop caching) causes FSP-M to fail with EFI_UNSUPPORTED

[Matt DeVillier]

I already pushed a revert: https://review.coreboot.org/c/coreboot/+/78091

Intel stated they have no intention of releasing a public FSP for JSL
unfortuantely

On Fri, Sep 22, 2023 at 10:01 AM Jonathon Hall 
wrote:

> For Librem 11 (Intel N5100, Jasper Lake), I had to revert 21e61847 [1] in
> order for FspMemoryInit to succeed for second and later boots.
>
> If the MTRR is set in early_ramtop_enable_cache_range(), all JSL FSPs I
> tested fail FspMemoryInit with EFI_UNSUPPORTED.  Since there is no public
> FSP release for JSL, I tested the FSP binaries from a number of Chromebooks
> - buggzy, cret, boten, storo.
>
> Before submitting a revert patch I wanted to discuss whether this should
> be conditionally enabled or reverted.  @Sean, I saw you authored this
> change, does it work for you?  Are there other FSP binaries available where
> this might work?
>
> CC Matt DeVillier, as this will probably affect 4.21 releases of the
> MrChromebox UEFI firmware for JSL devices.
>
> Thanks,
> Jonathon
>
> [1] https://review.coreboot.org/c/coreboot/+/74518
>
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: First time using coreboot+edk2, I didn't get to see the beginning.

[Matt DeVillier]

On Wed, Sep 13, 2023 at 11:28 PM Keith Hui  wrote:

> tldr: After my latest reflash of coreboot with edk2 payload, serial
> log didn't start flowing right away and no on screen activity until OS
> on drive has begun booting. What gives?
>
> After hacking on coreboot with SeaBIOS for so long, I finally tried
> edk2. It wasn't the smoothest transition.
>
> My testing hard drive has a bit of special hackery done[1] in hope it
> will boot under both legacy and UEFI schemes. I did add SeaBIOS as
> secondary payload, and it couldn't boot. Then I pulled out the main
> drive out of my laptop which is all UEFI, and it booted fine after
> probably 30 seconds of nothing - the first thing I saw on screen is
> the Fedora spinner. Nothing from edk2 or grub on the drive.
>

edk2 doesn't support secondary payloads


>
> There also was a bit of delay on my connected serial console, then
> when info finally started flowing, it's already well into ramstage.
> And when I checked cbmem, it unfortunately overflowed so I lost logs
> of raminit, which would be most important given my patch train now
> under review. It would take a warm reboot before I start getting the
> head of the boot logs.
>
> I didn't set a boot logo.
>
> What more set up I have to do to get my edk2 and grub boot menu back?
>
> I've attached logs from minicom, cbmem, and my Kconfig, if it helps.
>

as Nico said, you need to use a linear framebuffer, not vga text. The
display resolution should be native.

also, edk2 cbmem logging may or may not work, and may or may not slow down
boot time.


>
> Thanks for any insights.
> Keith
>
> [1] If I remember correctly, it is GPT partitioned with ESP plus a
> BIOS boot partition where grub can hide itself.
> ___
> coreboot mailing list -- coreboot@coreboot.org
> To unsubscribe send an email to coreboot-le...@coreboot.org
>
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] [coreboot - Bug #507] (New) Windows GPU driver fails to load on AMD based google/guybrush, google/skyrim boards

[Matt DeVillier]

Issue #507 has been reported by Matt DeVillier.


Bug #507: Windows GPU driver fails to load on AMD based google/guybrush, 
google/skyrim boards
https://ticket.coreboot.org/issues/507

* Author: Matt DeVillier
* Status: New
* Priority: Normal
* Target version: none
* Start date: 2023-08-30
* Affected versions: 4.21, 4.15, 4.16, 4.17, 4.18, 4.19, master
* Affected hardware: google/guybrush, google/skyrim

The Windows GPU drivers on AMD Cezanne and Mendocino platform ChromeOS devices 
(google guybrush and skyrim boards respectively) fail to load due to the PSP 
boot mode being `Development` vs `Production.` On these platforms, the PSP only 
boots in `Production` mode when ChromeOS verified boot mode is active.

Possible solutions include having the PSP boot in `Production` mode when vboot 
is not used at all, when CONFIG_CHROMEOS is not set, or (always) when PSP 
signed verstage is used. Any of these require changes to the PSP firmware from 
AMD.



-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
https://ticket.coreboot.org/my/account
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] [coreboot - Bug #506] (New) Apollolake/Geminilake boards fail to boot OS when CPU microcode included "from tree"

[Matt DeVillier]

Issue #506 has been reported by Matt DeVillier.


Bug #506: Apollolake/Geminilake boards fail to boot OS when CPU microcode 
included "from tree"
https://ticket.coreboot.org/issues/506

* Author: Matt DeVillier
* Status: New
* Priority: Normal
* Target version: none
* Start date: 2023-08-30
* Affected versions: 4.21, 4.15, 4.16, 4.17, 4.18, 4.19, master
* Affected hardware: all boards using Intel Apollolake/Geminilake SoCs
* Affected OS: All

Apollolake/Geminilake (APL/GLK) based devices are unique in that they have a 
special firmware region called IFWI, which contains the coreboot bootbock and 
CPU microcode, among other things. As part of building an image for an 
APL/GLK-based device, an existing IFWI binary must be supplied in order to be 
modified with coreboot's bootblock. The CPU microcode however is not updated, 
as the region size is fixed, and current tooling (util/cbfstool/ifwitool) does 
not have the ability to resize it. 

When the default coreboot Kconfig option `CPU_MICROCODE_CBFS_DEFAULT_BINS` for 
CPU microcode is selected, coreboot will include a microcode update in CBFS 
which is (much) newer than that in the IFWI, and apply it in ramstage. This 
causes any OS to fail to boot: Linux hangs, and Windows BSODs with an 
`UNSUPPORTED CPU` error. The only workaround is to include an external CPU 
microcode binary which matches the one in IFWI (ie, use both the IFWI and 
microcode extracted from the original vendor firmware image). Not including any 
microcode update has not been tested, and may also be an option.

There have been a few patches submitted to work around this (CB:65680, 
CB:64863), but the former requires external, non-public tooling, and the latter 
fails if the new microcode update is larger than the existing IFWI region.

Possible areas to investigate are adding resizing capability to ifwitool, and 
constructing an IFWI from scratch (vs copying/modifying the existing one)



-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
https://ticket.coreboot.org/my/account
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] [coreboot - Bug #495] (In Progress) Stoney chromebooks not booting PSPSecureOS -- Graphics driver takes 30 minutes to start

[Matt DeVillier]

Issue #495 has been updated by Matt DeVillier.

Status changed from Resolved to In Progress


Bug #495: Stoney chromebooks not booting PSPSecureOS -- Graphics driver takes 
30 minutes to start
https://ticket.coreboot.org/issues/495#change-1630

* Author: CoolStar Organization
* Status: In Progress
* Priority: High
* Category: chipset configuration
* Target version: none
* Start date: 2023-06-14
* Affected versions: 4.21, 4.15, 4.16, 4.17, 4.18, 4.19, master
* Affected hardware: stoney
* Affected OS: Windows 10, Windows 11

Windows 11 Graphics driver takes 30 minutes to start on Stoney due to missing 
PSPSecureOS. Windows 10 20H2 and newer hangs on boot (potentially from the same 
thing)



-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
https://ticket.coreboot.org/my/account
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] [coreboot - Bug #500] coreboot bootsplash only supports jpeg and does not support extended resolutions

[Matt DeVillier]

Issue #500 has been updated by Matt DeVillier.


editing the bug subject, affected hardware since there is no dependency on a 
specific GPU or display init method, only the framebuffer resolution


Bug #500: coreboot bootsplash only supports jpeg and does not support extended 
resolutions
https://ticket.coreboot.org/issues/500#change-1606

* Author: Thierry Laurion
* Status: New
* Priority: Normal
* Assignee: Patrick Georgi
* Category: coreboot common code
* Target version: master
* Start date: 2023-07-13
* Related links: https://github.com/coreboot/coreboot/blob/master/src/lib/jpeg.c
https://git.seabios.org/seabios.git/
https://github.com/osresearch/heads/pull/1403/commits/659308eff53f39633ffad71597a2463fa30eedd3#diff-816b79cd9a1192fa8cf78b9737f0d3fed5a943a0d2c952da591f8a2446edc1db

WiP PoC: https://github.com/osresearch/heads/pull/1403

* Affected hardware: All using coreboot display init + bootsplash
* Affected OS: n/a

For those of you on matrix, the discussion happened at 
https://matrix.to/#/!BZxDFuoBnMKnzVZwEp:libera.chat/$pQoGnN9DnokZ875fTbHiAtTc0IEVgQDycUJmB7PLulE?via=libera.chat=matrix.org=matrix.zerodao.gg

Short version:
- libgfxinit bootsplash through jpeg.c supports VESA old resolutions (1024x768)
- libgfxinit bootsplash through jpeg.c doesn't support native resolutions 
(1366x768)
- libgfxinit bootsplash image creation requires voodoo skills explained at 
https://puri.sm/posts/librem-13-coreboot-report-february-25th-2017 
- Basically, I do not think libgfxinit bootsplash is currently used otherwise 
there would be way more bug reports. Seabios is mostly used.
- Seabios bootsplash code should be borrowed (lgplv3) which supports both BMP 
and JPEG and is not 13yo.
- Coreboot should permit stiching of compressed bmp by default and deprecate 
old jpeg.c in tree
- By doing so, more people could promote coreboot directly from coreboot 
raminit (Heads currently does that)

Longer version:
- OSes are attacking legacy BIOS mode for a while now, and the next steps are 
to deprecate DRM drivers in initrd
  - To phase DRM out, simplefb and simpledrm are promoted instead where final 
OS will be in charge of deploying bigger unified kernels containing/initrd 
which will contain the accelerated DRM and fb drivers
  - Currently deploying DRM drivers inside of linuxboot (heads) on Intel iGPU 
requires to include i915drmfb, coreboot linux command lines hacks to have the 
FB address exposed (tainting the kernel) and kexec hacked to expose exposed fb 
address to next kernel (see https://github.com/osresearch/heads/pull/1378)
- Doing currently adds more then 500kb of in-kernel drivers, which bloats 
the firmware. In case of measured boot, that bigger payload needs to be 
measured prior of being read and jumped into (8-10 seconds under 5.10 kernel 
compared to 4-6 seconds under 4.14)
  - To have legacy BIOS survive this ecosystem attack against legacy boot, 
coreboot needs to push for a more generic way to provide a framebuffer 
(GOP/Native unified approach)
- With libgfxinit/GOP/native gfx init and the kernel config adapted, linux 
can efficiently be used as a bootloader and be enabled by simplefb 
(https://github.com/osresearch/heads/pull/1403/commits/659308eff53f39633ffad71597a2463fa30eedd3)
- The part missing is having coreboot drive the framebuffer with a native size 
bootsplash as everyone else does so that the waiting time to boot in 
kernel/payload is not a scary moment, and that the bootsplash doesn't restrict 
the size of the framebuffer configured under coreboot nor limit the UX.

Actual state:
- libgfxinit needs to have jpeg supported resolution to bootsplash 
(CONFIG_LINEAR_FRAMEBUFFER_MAX_HEIGHT=768 
CONFIG_LINEAR_FRAMEBUFFER_MAX_WIDTH=1024) 
- libgfxinit bootsplash needs to have a 1024x768 voodoo crafted jpeg 
(https://github.com/osresearch/heads/blob/master/blobs/ThePlexus-bootsplash-1024x768.jpg)
- Problem is that doing so, the whole console is limited to that resolution 
showing black borders on each side of the screen to compensate (1366 != 1024, 
so (1366-1024)/2 is the loss pixel width on each side of the screen for 
1366x764, same applying to all other resolutions since needs to be 4x4 for 
jpeg.c to do its job.

Desired state:
- flat bmp support in native format just like seabios support, where coreboot 
compressed them prior of adding it into CBFS.
- support for all crazy resolutions we currently have, not being stuck in 2000.
- Be able to promote coreboot from raminit code.

---Files
signal-2023-07-13-164022.jpeg (269 KB)
signal-2023-07-13-164047.jpeg (416 KB)
VID_20230713_154446.mp4 (3.78 MB)
signal-2023-07-13-171757.jpeg (275 KB)
signal-2023-07-13-171801.jpeg (350 KB)


-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
https://ticket.coreboot.org/my

[coreboot] [coreboot - Bug #500] coreboot bootsplash only supports jpeg and does not support extended resolutions

[Matt DeVillier]

Issue #500 has been updated by Matt DeVillier.

Subject changed from libgfxinit bootsplash only supports jpeg and does not 
support extended resolutions to coreboot bootsplash only supports jpeg and does 
not support extended resolutions
Affected hardware changed from iGPU driven by libgfxinit to All using coreboot 
display init + bootsplash
Affected OS changed from All to n/a


Bug #500: coreboot bootsplash only supports jpeg and does not support extended 
resolutions
https://ticket.coreboot.org/issues/500#change-1605

* Author: Thierry Laurion
* Status: New
* Priority: Normal
* Assignee: Patrick Georgi
* Category: coreboot common code
* Target version: master
* Start date: 2023-07-13
* Related links: https://github.com/coreboot/coreboot/blob/master/src/lib/jpeg.c
https://git.seabios.org/seabios.git/
https://github.com/osresearch/heads/pull/1403/commits/659308eff53f39633ffad71597a2463fa30eedd3#diff-816b79cd9a1192fa8cf78b9737f0d3fed5a943a0d2c952da591f8a2446edc1db

WiP PoC: https://github.com/osresearch/heads/pull/1403

* Affected hardware: All using coreboot display init + bootsplash
* Affected OS: n/a

For those of you on matrix, the discussion happened at 
https://matrix.to/#/!BZxDFuoBnMKnzVZwEp:libera.chat/$pQoGnN9DnokZ875fTbHiAtTc0IEVgQDycUJmB7PLulE?via=libera.chat=matrix.org=matrix.zerodao.gg

Short version:
- libgfxinit bootsplash through jpeg.c supports VESA old resolutions (1024x768)
- libgfxinit bootsplash through jpeg.c doesn't support native resolutions 
(1366x768)
- libgfxinit bootsplash image creation requires voodoo skills explained at 
https://puri.sm/posts/librem-13-coreboot-report-february-25th-2017 
- Basically, I do not think libgfxinit bootsplash is currently used otherwise 
there would be way more bug reports. Seabios is mostly used.
- Seabios bootsplash code should be borrowed (lgplv3) which supports both BMP 
and JPEG and is not 13yo.
- Coreboot should permit stiching of compressed bmp by default and deprecate 
old jpeg.c in tree
- By doing so, more people could promote coreboot directly from coreboot 
raminit (Heads currently does that)

Longer version:
- OSes are attacking legacy BIOS mode for a while now, and the next steps are 
to deprecate DRM drivers in initrd
  - To phase DRM out, simplefb and simpledrm are promoted instead where final 
OS will be in charge of deploying bigger unified kernels containing/initrd 
which will contain the accelerated DRM and fb drivers
  - Currently deploying DRM drivers inside of linuxboot (heads) on Intel iGPU 
requires to include i915drmfb, coreboot linux command lines hacks to have the 
FB address exposed (tainting the kernel) and kexec hacked to expose exposed fb 
address to next kernel (see https://github.com/osresearch/heads/pull/1378)
- Doing currently adds more then 500kb of in-kernel drivers, which bloats 
the firmware. In case of measured boot, that bigger payload needs to be 
measured prior of being read and jumped into (8-10 seconds under 5.10 kernel 
compared to 4-6 seconds under 4.14)
  - To have legacy BIOS survive this ecosystem attack against legacy boot, 
coreboot needs to push for a more generic way to provide a framebuffer 
(GOP/Native unified approach)
- With libgfxinit/GOP/native gfx init and the kernel config adapted, linux 
can efficiently be used as a bootloader and be enabled by simplefb 
(https://github.com/osresearch/heads/pull/1403/commits/659308eff53f39633ffad71597a2463fa30eedd3)
- The part missing is having coreboot drive the framebuffer with a native size 
bootsplash as everyone else does so that the waiting time to boot in 
kernel/payload is not a scary moment, and that the bootsplash doesn't restrict 
the size of the framebuffer configured under coreboot nor limit the UX.

Actual state:
- libgfxinit needs to have jpeg supported resolution to bootsplash 
(CONFIG_LINEAR_FRAMEBUFFER_MAX_HEIGHT=768 
CONFIG_LINEAR_FRAMEBUFFER_MAX_WIDTH=1024) 
- libgfxinit bootsplash needs to have a 1024x768 voodoo crafted jpeg 
(https://github.com/osresearch/heads/blob/master/blobs/ThePlexus-bootsplash-1024x768.jpg)
- Problem is that doing so, the whole console is limited to that resolution 
showing black borders on each side of the screen to compensate (1366 != 1024, 
so (1366-1024)/2 is the loss pixel width on each side of the screen for 
1366x764, same applying to all other resolutions since needs to be 4x4 for 
jpeg.c to do its job.

Desired state:
- flat bmp support in native format just like seabios support, where coreboot 
compressed them prior of adding it into CBFS.
- support for all crazy resolutions we currently have, not being stuck in 2000.
- Be able to promote coreboot from raminit code.

---Files
signal-2023-07-13-164022.jpeg (269 KB)
signal-2023-07-13-164047.jpeg (416 KB)
VID_20230713_154446.mp4 (3.78 MB)
signal-2023-07-13-171757.jpeg (275 KB)
signal-2023-07-13-171801.jpeg (350 KB)


-- 
You have

[coreboot] Re: Legacy OS Support

[Matt DeVillier]

hi Mason,

I'm a bit confused here - you're not going to be able to boot any OS which
requires legacy BIOS using my MrChromebox (UEFI) firmware images. But even
if you could, older OSes like Windows XP/7 don't have drivers to support
the newer hardware platform used on your Chromebook, to say nothing for the
peripherals like the touchpad which require custom drivers that simply
don't exist for older versions of Windows.

You're also unlikely to be able to run WinXP/7 even using a custom
coreboot+SeaBIOS firmware image, given that older versions of Windows were
pretty bad about following the ACPI spec, and/or required lots of firmware
workarounds for Windows quirks. And even if you could boot, you're going to
run into the driver issues as mentioned above.

Virtual machines exist for a reason, and running WinXP/7 in a VM from a
Linux host is going to be the best and easiest solution here.

cheers,
Matt / MrChromebox

On Wed, Jun 28, 2023 at 1:37 PM Peter Stuge  wrote:

> Mason McAlister wrote:
> > any idea when Legacy OS/BIOS support is coming to Coreboot?
>
> To coreboot itself probably never but you can use SeaBIOS as payload
> to get a BIOS environment that will boot Windows, if the ACPI tables
> created/delivered by coreboot for the mainboard are correct.
>
>
> > it'd just be cool if i could get windows XP or windows 7 on a chromebook.
>
> Should work as long as ACPI tables are correct, I would expect
> Chromebooks to have fairly good ones.
>
>
> //Peter
> ___
> coreboot mailing list -- coreboot@coreboot.org
> To unsubscribe send an email to coreboot-le...@coreboot.org
>
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: How to build UEFI payload for Coreboot?

[Matt DeVillier]

I don't believe it's supported directly via emerge, at least not building
the same branch/tag of edk2 as upstream coreboot uses as a payload (which
is my fork). If there's an emerge target, it's likely a much older
branch/tag that's been used for RW_LEGACY/AltFw but not kept up with what
upstream coreboot uses. Part of the issue AIUI is that the submodules edk2
uses need to be called out separately, so updating the build target isn't
quite as simple as changing the branch/tag/commit hash to be used

On Wed, Jun 14, 2023 at 5:02 PM Sarawadi, Ravishankar <
ravishankar.saraw...@intel.com> wrote:

> board --> google/rex
>
>
>
> is emerge/ebuild support available too for same?
>
>
>
> -Ravi
>
>
>
> *From:* Matt DeVillier 
> *Sent:* Wednesday, June 14, 2023 2:19 PM
> *To:* Sarawadi, Ravishankar 
> *Cc:* coreboot@coreboot.org
> *Subject:* Re: [coreboot] How to build UEFI payload for Coreboot?
>
>
>
> * make distclean
> * make menuconfig / nconfig
>
> * select board
>
> * select edk2 payload
>
> * ensure display init enabled, set to high-res linear framebuffer
>
> * save / exit
>
> * make
>
>
>
> should work for pretty much any x86_64 board in the tree currently, but
> there are a few exceptions. What board are you using?
>
>
>
> On Wed, Jun 14, 2023 at 3:42 PM Sarawadi, Ravishankar <
> ravishankar.saraw...@intel.com> wrote:
>
> Is EDK2/Tianocore payload not supported for coreboot on latest tip?
>
>
>
> Any build and interation steps for how-to for UEFI payload on top of
> coreboot?
>
>
>
> Thanks,
>
> -Ravi
>
> ___
> coreboot mailing list -- coreboot@coreboot.org
> To unsubscribe send an email to coreboot-le...@coreboot.org
>
>
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: How to build UEFI payload for Coreboot?

[Matt DeVillier]

* make distclean
* make menuconfig / nconfig
* select board
* select edk2 payload
* ensure display init enabled, set to high-res linear framebuffer
* save / exit
* make

should work for pretty much any x86_64 board in the tree currently, but
there are a few exceptions. What board are you using?

On Wed, Jun 14, 2023 at 3:42 PM Sarawadi, Ravishankar <
ravishankar.saraw...@intel.com> wrote:

> Is EDK2/Tianocore payload not supported for coreboot on latest tip?
>
>
>
> Any build and interation steps for how-to for UEFI payload on top of
> coreboot?
>
>
>
> Thanks,
>
> -Ravi
> ___
> coreboot mailing list -- coreboot@coreboot.org
> To unsubscribe send an email to coreboot-le...@coreboot.org
>
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Coffeelake Graphics Problem

[Matt DeVillier]

coreboot needs to initialize the display and provide the framebuffer for
edk2 to use. What display init option do you have selected? It needs to be
'RUN FSP GOP' and a valid VBT is needed for the FSP PEI GOP driver to
successfully execute

On Tue, Apr 4, 2023 at 8:17 AM cagatay bagci via coreboot <
coreboot@coreboot.org> wrote:

> Hello all,
> I have a custom CFL board. I used Tianocore UEFI payload. It boots without
> problem on console and I can enter BIOS menu. I put appropriate vbt.bin
> file and added that path to config file, so VBT exists. However, I cannot
> get display output. I inspected debug log and it says "graphics hand-off
> block not found" in one line. I understand that FSP does not build
> "gEfiGraphicsInfoHobGuid". Do you have an idea why FSP does not produce
> that HOB?
>
> In addition to that, by using FSP debug binary, I can see that FSP does
> not even enter PeiGraphicsEntryPoint. It somehow quits after
> "SerialIoInit() Start" and notifys Post PCI Enumeration.
>
> Thanks,
>
> ___
> coreboot mailing list -- coreboot@coreboot.org
> To unsubscribe send an email to coreboot-le...@coreboot.org
>
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] [coreboot - Feature #7] gnawty support based on acer cb3-111

[Matt DeVillier]

Issue #7 has been updated by Matt DeVillier.


Martin Roth wrote in #note-14:
> No updates in 7 years.  Closing.

also, gnawty has been supported as a rambi variant since early 2017


Feature #7: gnawty support based on acer cb3-111
https://ticket.coreboot.org/issues/7#change-1350

* Author: Alexander Couzens
* Status: Closed
* Priority: Normal
* Assignee: Alexander Couzens
* Category: board support
* Start date: 2015-11-20

Adding google gnawty boards.
This board is very similiar to rambi, the only difference known is the ram 
configuration.

http://review.coreboot.org/#/c/12500
https://www.coreboot.org/Board:acer/cb3-111

SeaBIOS hangs with message:
Press F12 ...

but pressing f12 does nothing.

~~Booting ELF payload with openwrt fails because e820 isn't properly passed.~~

Using Linux Payload + x64 kernel openwrt boots up.


---Files
bootup_x86_64_openwrt (60 KB)
vga_bios_hangs (29.1 KB)
dmesg (63.6 KB)
lspci_vvv (10.3 KB)
lspci (789 Bytes)
lspci_vvttnn (716 Bytes)
booting_4.1 (58.7 KB)
booting_4.1_with_ioapic (63.5 KB)


-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
https://ticket.coreboot.org/my/account
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Power button only works once - where to check for fixes (51nb X2100)?

[Matt DeVillier]

sounds to me like AP shutdown is causing the EC to power off as well, so
it's not active to respond to the subsequent power button press. Not sure
why disconnecting AC power would reset that though, unless you are also
disconnecting the internal battery as well

On Thu, Jan 12, 2023 at 11:08 AM Rafael Send 
wrote:

> Hi,
> As folks may have gathered from my other question about the GCC build
> environment, I've been playing around with the old X2100 port (
> https://github.com/mjg59/coreboot/tree/x2100_ng).
>
> I got it to build and added the latest version of MrChromebox's Tianocore,
> but there's still one issue that keep is from being very useable.
>
> After flashing / plugging in the machine, the power button will turn it
> on, but only once. If I shut down any OS, or even if it goes to sleep or
> suspends, the power button no longer has any effect so the only "fix" is
> currently to unplug power and re-plug it.
>
> Where might I look for causes of this? Is it a shutdown state thing? ACPI?
>
> Thanks,
> Rafael
> ___
> coreboot mailing list -- coreboot@coreboot.org
> To unsubscribe send an email to coreboot-le...@coreboot.org
>
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] MrChromebox coreboot 4.18-based community release is out

[Matt DeVillier]

Greetings all!

I've just now posted my MrChromebox-4.18 release, which currently
supports over 100 unique devices spanning a dozen platforms. A full
list of supported devices can be found at
https://mrchromebox.tech/#devices.

Beside updating the base coreboot code, this release as usual is full
of fixes and improvements:

* Added support for coolstar's upcoming Windows audio drivers for
Skylake, Kabylake, Apollolake, and Geminilake platform devices
* Fixed extraneous microphone channels picking up noise when recording (multi)
* updated Tianocore/edk2 using branch upp_202210
* Improved boot-time USB detection in Tianocore
* Fixed CR50 TPM init on devices with an I2C CR50 TPM
* Fixed Windows BSOD/ACPI BIOS ERROR on a handful of devices
* Updated CPU microcode for all devices to latest available

Beta images are available upon request for newer boards using
Tigerlake, Jasperlake, or Alderlake SoCs and AMD Zen+/Picasso (just
don't ask me how well they run Windows -- that's coolstar's domain).

As usual, the full list of changes can be found on my github repos:
https://github.com/MrChromebox/coreboot/commits/2022.10.24
https://github.com/MrChromebox/edk2/commits/upp_202210
https://github.com/MrChromebox/chrome-ec/branches/all

cheers,
Matt
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] [coreboot - Bug #429] (Resolved) I2C CR50 TPM fails to initialize

[Matt DeVillier]

Issue #429 has been updated by Matt DeVillier.

Status changed from New to Resolved


Bug #429: I2C CR50 TPM fails to initialize
https://ticket.coreboot.org/issues/429#change-1210

* Author: Matt DeVillier
* Status: Resolved
* Priority: High
* Target version: none
* Start date: 2022-10-17
* Affected versions: 4.15, 4.16, 4.17, master

On several (but not all) Chromebook platforms which use an I2C interface for 
the CR50 TPM, the TPM fails to initialize due to I2C transaction errors.

The following boards with I2C CR50 TPM are known to be affected:
google/brya (banshee variant confirmed, others untested)
google/drallion
google/poppy (soraka and nautilus variants)
google/reef (all variants)

The following boards with I2C CR50 TPM are known to be working:
google/eve
google/guybrush
google/kahlee
google/zork

cbmem shows the following, with the i2c transactions repeating 100x until 
failing. This causes a significant increase in boot time.

```
[INFO ]  Probing TPM I2C: i2c 2:50 W 1 bytes : 06   
   
[ERROR]  I2C TX abort detected (0001)   
   
[ERROR]  cr50_i2c_read: Address write failed
   
[INFO ]  .i2c 2:50 W 1 bytes : 06   
   
[ERROR]  I2C TX abort detected (0001)   
   
[ERROR]  cr50_i2c_read: Address write failed
   
...
``` 

soraka/nautilus show slightly different output:

```
[INFO ]  Probing TPM I2C: Cr50 TPM IRQ timeout!
[INFO ]  .Cr50 TPM IRQ timeout!
[INFO ]  .Cr50 TPM IRQ timeout!
[INFO ]  .Cr50 TPM IRQ timeout!
...
```



-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
https://ticket.coreboot.org/my/account
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] [coreboot - Bug #429] I2C CR50 TPM fails to initialize

[Matt DeVillier]

Issue #429 has been updated by Matt DeVillier.


proposed fix: https://review.coreboot.org/c/coreboot/+/68550




Bug #429: I2C CR50 TPM fails to initialize
https://ticket.coreboot.org/issues/429#change-1194

* Author: Matt DeVillier
* Status: New
* Priority: High
* Target version: none
* Start date: 2022-10-17
* Affected versions: 4.15, 4.16, 4.17, master

On several (but not all) Chromebook platforms which use an I2C interface for 
the CR50 TPM, the TPM fails to initialize due to I2C transaction errors.

The following boards with I2C CR50 TPM are known to be affected:
google/brya (banshee variant confirmed, others untested)
google/drallion
google/poppy (soraka and nautilus variants)
google/reef (all variants)

The following boards with I2C CR50 TPM are known to be working:
google/eve
google/guybrush
google/kahlee
google/zork

cbmem shows the following, with the i2c transactions repeating 100x until 
failing. This causes a significant increase in boot time.

```
[INFO ]  Probing TPM I2C: i2c 2:50 W 1 bytes : 06   
   
[ERROR]  I2C TX abort detected (0001)   
   
[ERROR]  cr50_i2c_read: Address write failed
   
[INFO ]  .i2c 2:50 W 1 bytes : 06   
   
[ERROR]  I2C TX abort detected (0001)   
   
[ERROR]  cr50_i2c_read: Address write failed
   
...
``` 

soraka/nautilus show slightly different output:

```
[INFO ]  Probing TPM I2C: Cr50 TPM IRQ timeout!
[INFO ]  .Cr50 TPM IRQ timeout!
[INFO ]  .Cr50 TPM IRQ timeout!
[INFO ]  .Cr50 TPM IRQ timeout!
...
```



-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
https://ticket.coreboot.org/my/account
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] [coreboot - Bug #429] I2C CR50 TPM fails to initialize

[Matt DeVillier]

Issue #429 has been updated by Matt DeVillier.


did some more testing, and confirmed that this issue is not present when vboot 
is used (RO only is fine) - so the issue potentially is the lack of early init 
by vboot leading to failure to init during ramstage. Will take a look and see 
what's different about the two


Bug #429: I2C CR50 TPM fails to initialize
https://ticket.coreboot.org/issues/429#change-1193

* Author: Matt DeVillier
* Status: New
* Priority: High
* Target version: none
* Start date: 2022-10-17
* Affected versions: 4.15, 4.16, 4.17, master

On several (but not all) Chromebook platforms which use an I2C interface for 
the CR50 TPM, the TPM fails to initialize due to I2C transaction errors.

The following boards with I2C CR50 TPM are known to be affected:
google/brya (banshee variant confirmed, others untested)
google/drallion
google/poppy (soraka and nautilus variants)
google/reef (all variants)

The following boards with I2C CR50 TPM are known to be working:
google/eve
google/guybrush
google/kahlee
google/zork

cbmem shows the following, with the i2c transactions repeating 100x until 
failing. This causes a significant increase in boot time.

```
[INFO ]  Probing TPM I2C: i2c 2:50 W 1 bytes : 06   
   
[ERROR]  I2C TX abort detected (0001)   
   
[ERROR]  cr50_i2c_read: Address write failed
   
[INFO ]  .i2c 2:50 W 1 bytes : 06   
   
[ERROR]  I2C TX abort detected (0001)   
   
[ERROR]  cr50_i2c_read: Address write failed
   
...
``` 

soraka/nautilus show slightly different output:

```
[INFO ]  Probing TPM I2C: Cr50 TPM IRQ timeout!
[INFO ]  .Cr50 TPM IRQ timeout!
[INFO ]  .Cr50 TPM IRQ timeout!
[INFO ]  .Cr50 TPM IRQ timeout!
...
```



-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
https://ticket.coreboot.org/my/account
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] [coreboot - Bug #429] (New) I2C CR50 TPM fails to initialize

[Matt DeVillier]

Issue #429 has been reported by Matt DeVillier.


Bug #429: I2C CR50 TPM fails to initialize
https://ticket.coreboot.org/issues/429

* Author: Matt DeVillier
* Status: New
* Priority: High
* Target version: none
* Start date: 2022-10-17
* Affected versions: 4.15, 4.16, 4.17, master

On several (but not all) Chromebook platforms which use an I2C interface for 
the CR50 TPM, the TPM fails to initialize due to I2C transaction errors.

The following boards with I2C CR50 TPM are known to be affected:
google/brya (banshee variant confirmed, others untested)
google/drallion
google/poppy (soraka and nautilus variants)
google/reef (all variants)

The following boards with I2C CR50 TPM are known to be working:
google/eve
google/guybrush
google/kahlee
google/zork

cbmem shows the following, with the i2c transactions repeating 100x until 
failing. This causes a significant increase in boot time.

[INFO ]  Probing TPM I2C: i2c 2:50 W 1 bytes : 06   
   
[ERROR]  I2C TX abort detected (0001)   
   
[ERROR]  cr50_i2c_read: Address write failed
   
[INFO ]  .i2c 2:50 W 1 bytes : 06   
   
[ERROR]  I2C TX abort detected (0001)   
   
[ERROR]  cr50_i2c_read: Address write failed
   
... 

soraka/nautilus show slightly different output:

[INFO ]  Probing TPM I2C: Cr50 TPM IRQ timeout!
[INFO ]  .Cr50 TPM IRQ timeout!
[INFO ]  .Cr50 TPM IRQ timeout!
[INFO ]  .Cr50 TPM IRQ timeout!
...



-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
https://ticket.coreboot.org/my/account
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] [coreboot - Feature #417] Show platform key on boot when secure boot is enabled

[Matt DeVillier]

Issue #417 has been updated by Matt DeVillier.


secure boot? Do you mean Verified Boot?

coreboot does not implement UEFI secure Boot (as it's not UEFI) nor are any 
Microsoft keys present anywhere in a coreboot firmware image.

If this is related to UEFI secure boot, then the proper place for this feature 
would be in edk2, not coreboot.


Feature #417: Show platform key on boot when secure boot is enabled
https://ticket.coreboot.org/issues/417#change-1098

* Author: Simon Brand
* Status: New
* Priority: Normal
* Target version: none
* Start date: 2022-10-02
* Related links: [0] 
https://source.android.com/docs/security/features/verifiedboot/boot-flow#locked-devices-with-custom-root-of-trust
[1] https://issuetracker.google.com/issues/217720443
[2] 
https://source.codeaurora.org/quic/la/abl/tianocore/edk2/tree/QcomModulePkg/Library/BootLib/VerifiedBootMenu.c?h=LA.UM.8.9.1.r1-03800-QCS610.0=8e06dfd3ceeb323546d330e918d19c542d2daee2#n340
* Affected hardware: All
* Affected OS: All but Windows

I think it is useful to show the hash of the platform key, if a different 
platform key than default (Microsoft trusted Platform Key) is the current 
platform key and secure boot is enabled. It must be shown, before the operating 
system could have been started (to avoid the OS showing it with an older UEFI, 
which lacks this feature), also it makes sense to pause the screen, so you can 
verify the hash.

Why?
To make sure the correct operation system is loading and nobody tampered the 
devices platform key and disk.

Android smartphones have this feature for several years. [0]
Please keep in mind, that the screenshots are not fully up-to-date, devices 
show not only the first 8 digits, but the full root of trust hash since a few 
months. [1]
The reference source code is available here: [2]





-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
https://ticket.coreboot.org/my/account
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Verifiable UEFI OS

[Matt DeVillier]

Ron,
if I had to hazard a guess, for most users with EOL ChromeOS hardware,
it's simply several orders of magnitude easier to flash my upstream
coreboot + edk2 firmware and install ChromeOS Flex, than to build
their own ChromiumOS (vs ChromeOS, since the private overlays are not
available) and manage updates

On Mon, Sep 5, 2022 at 4:21 PM ron minnich  wrote:
>
> I'm completely lost. Why would you update a chromebook to chromeos flex when 
> you can build chromeos and install that.
>
> Did you know that you can build chromeos from source, rekey the chromebook, 
> and then it will boot in normal mode with your build? You can even run the 
> chromeos OTA service from a machine you own, which is kinda fun. This is a 
> talk I gave at ELC in 2014 (15? I forget) about doing just that: 
> https://docs.google.com/presentation/d/1jSUJteAjEgHCFyx6VsqhWmNGTKipvTmAdsoW0gme7qA/edit?usp=sharing
>
> This is also the year the vendor LF hired to record the talks lost all the 
> videos of the talks, so the slides are all I have.
>
> But to the original question: chromeos flex IIUC is set up to boot on 
> non-chromebook environments like UEFI, so I'm a bit lost on why you'd want it 
> on a real chromebook.
>
> This probably means I'm about to learn something I did not know.
>
>
>
> On Mon, Sep 5, 2022 at 9:37 AM Matt DeVillier  
> wrote:
>>
>> This has nothing to do with coreboot, the message is from the UEFI
>> payload (Tianocore/edk2). It's telling you that whatever boot device
>> it is trying to boot (and it tells you in the error msg) does not
>> contain a UEFI-bootable 64-bit OS. If you didn't install ChromeOS Flex
>> to your internal storage, then that is why (since ChromeOS proper is
>> not UEFI-bootable).
>>
>> On Mon, Sep 5, 2022 at 9:10 AM CJ  wrote:
>> >
>> > First, I just want to thank all of you for what you do.  Using Coreboot is 
>> > delightful.  I had a question about how the program verifies UEFI OS's.  
>> > I'm using it to update a chromebook to ChromeOS flex and receiving the 
>> > error; doesn't contain a verifiable 64-bit UEFI OS.d From the 
>> > documentation ChromeOS Flex is supposed to be a 64 bit UEFI so I"m 
>> > wondering if it could be something I did while creating the boot media, a 
>> > problem with updating chromebook, or how coreboot is verifying the OS?  
>> > After entering the menu I can boot to the USB and install just fine so no 
>> > big deal just curious why it gave that error.  Thanks again for putting in 
>> > the work!  We all appreciate it.
>> > ___
>> > coreboot mailing list -- coreboot@coreboot.org
>> > To unsubscribe send an email to coreboot-le...@coreboot.org
>> ___
>> coreboot mailing list -- coreboot@coreboot.org
>> To unsubscribe send an email to coreboot-le...@coreboot.org
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] [coreboot - Bug #414] X9SAE-V: No USB keyboard init with SeaBIOS while using Radeon RX 6800XT

[Matt DeVillier]

Issue #414 has been updated by Matt DeVillier.


sure sounds to me like the USB-C port on the card is causing SeaBIOS'
USB init to fail. I'm guessing nothing at all to do with coreboot.
Raise the SeaBIOS logging level to 3 and grab a cbmem log after
booting

On Mon, Sep 5, 2022 at 9:55 AM Aaron Burton  wrote:
>
> Issue #414 has been reported by Aaron Burton.
>
> 
> Bug #414: X9SAE-V: No USB keyboard init with SeaBIOS while using Radeon RX 
> 6800XT
> https://ticket.coreboot.org/issues/414
>
> * Author: Aaron Burton
> * Status: New
> * Priority: Normal
> * Category: board support
> * Target version: none
> * Start date: 2022-09-05
> * Affected versions: 4.17
> * Affected hardware: X9SAE-V
> 
> While booting coreboot 4.17 to SeaBIOS 1.16 on a Supermicro X9SAE-V, the 
> keyboard flashes on then off (LED Backlit USB keyboard) and does not let me 
> interact with SeaBIOS until the linux kernel is loaded on the OS side. 
> Currently using a PS/2 keyboard to unlock my boot drive via SeaBIOS. Using 
> any other GPU does not affect the USB keyboard and works just fine. The 
> Radeon RX 6800XT is a reference card with a USB-C port on it, naturally I 
> tried a USB-C adaptor on the GPU to get the USB keyboard to work, but no 
> luck. Building coreboot with either native, secure VGABIOS loading, or 
> libgfxinit does not fix the problem either. Seems to be specific to this GPU 
> on hardware init. Coreboot dot config is attached.
>
> ---Files
> coreboot-config (17.7 KB)
>
>
> --
> You have received this notification because you have either subscribed to it, 
> or are involved in it.
> To change your notification preferences, please click here: 
> https://ticket.coreboot.org/my/account
> ___
> coreboot mailing list -- coreboot@coreboot.org
> To unsubscribe send an email to coreboot-le...@coreboot.org


Bug #414: X9SAE-V: No USB keyboard init with SeaBIOS while using Radeon RX 
6800XT
https://ticket.coreboot.org/issues/414#change-1087

* Author: Aaron Burton
* Status: New
* Priority: Normal
* Category: board support
* Target version: none
* Start date: 2022-09-05
* Affected versions: 4.17
* Affected hardware: X9SAE-V

While booting coreboot 4.17 to SeaBIOS 1.16 on a Supermicro X9SAE-V, the 
keyboard flashes on then off (LED Backlit USB keyboard) and does not let me 
interact with SeaBIOS until the linux kernel is loaded on the OS side. 
Currently using a PS/2 keyboard to unlock my boot drive via SeaBIOS. Using any 
other GPU does not affect the USB keyboard and works just fine. The Radeon RX 
6800XT is a reference card with a USB-C port on it, naturally I tried a USB-C 
adaptor on the GPU to get the USB keyboard to work, but no luck. Building 
coreboot with either native, secure VGABIOS loading, or libgfxinit does not fix 
the problem either. Seems to be specific to this GPU on hardware init. Coreboot 
dot config is attached.

---Files
coreboot-config (17.7 KB)


-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
https://ticket.coreboot.org/my/account
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Verifiable UEFI OS

[Matt DeVillier]

This has nothing to do with coreboot, the message is from the UEFI
payload (Tianocore/edk2). It's telling you that whatever boot device
it is trying to boot (and it tells you in the error msg) does not
contain a UEFI-bootable 64-bit OS. If you didn't install ChromeOS Flex
to your internal storage, then that is why (since ChromeOS proper is
not UEFI-bootable).

On Mon, Sep 5, 2022 at 9:10 AM CJ  wrote:
>
> First, I just want to thank all of you for what you do.  Using Coreboot is 
> delightful.  I had a question about how the program verifies UEFI OS's.  I'm 
> using it to update a chromebook to ChromeOS flex and receiving the error; 
> doesn't contain a verifiable 64-bit UEFI OS.d From the documentation ChromeOS 
> Flex is supposed to be a 64 bit UEFI so I"m wondering if it could be 
> something I did while creating the boot media, a problem with updating 
> chromebook, or how coreboot is verifying the OS?  After entering the menu I 
> can boot to the USB and install just fine so no big deal just curious why it 
> gave that error.  Thanks again for putting in the work!  We all appreciate it.
> ___
> coreboot mailing list -- coreboot@coreboot.org
> To unsubscribe send an email to coreboot-le...@coreboot.org
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] [coreboot - Bug #401] edk2 hangs indefiniately

[Matt DeVillier]

Issue #401 has been updated by Matt DeVillier.


Sean Rhodes wrote in #note-6:
> Disabling MTRR in edk2 seems to cause other issues - the most obvious being 
> the USB drivers constantly resetting.

on what platform(s) are you seeing that? I don't recall seeing here on my 
202107 and 202111 branches




Bug #401: edk2 hangs indefiniately 
https://ticket.coreboot.org/issues/401#change-1047

* Author: Sean Rhodes
* Status: New
* Priority: Normal
* Assignee: Arthur Heymans
* Category: board support
* Target version: none
* Start date: 2022-07-08
* Affected versions: master
* Affected hardware: Everything
* Affected OS: Doesn't matter

Since CB:63555, edk2 will no longer boot and hangs indefiniately

Various forks disable MTRR programming in edk2 (such as 
https://github.com/MrChromebox/edk2/commit/d641ea6920737fd9b9a94210e9a2e7636bfb3cdc)
 but this shouldn't be done as it breaks spec.

Workarounds are to revert CB:64804, CB:63550, CB:64803 and CB:63555.

---Files
with_avph_patch.txt (65.8 KB)
with_avph_patch_reverted.txt (64.6 KB)
master.txt (91.9 KB)
master_w_revert.txt (197 KB)
edk2.txt (251 KB)


-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
https://ticket.coreboot.org/my/account
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] [coreboot - Bug #327] MBOX3, OperationRegion (OPRG, SystemMemory, ASLS, 0x2000) causes windows uefi tianocore BSOD ACPI_BIOS_ERROR

[Matt DeVillier]

Issue #327 has been updated by Matt DeVillier.


> When set to 0x1000 windows UEFI tianocore mode boots fine

This seems to be a board-specific issue rather than platform or tree-wide 
issue. The IGD OpRegion spec published by Intel themselves specifies that the 
reserved region starting at ASLS is 0x2000 in size - see: 
https://01.org/sites/default/files/documentation/acpi_igd_opregion_spec_0.pdf 
p16.

Additionally, other SNB/IVB boards (such as google/link and samsung/stumpy) 
have no issues booting Windows via Tianocore with the correct OpRegion size set.

So, I suspect something else in the x230 ACPI code is overlapping with the IGD 
OpRegion and causing the BSOD


Bug #327: MBOX3, OperationRegion (OPRG, SystemMemory, ASLS, 0x2000) causes 
windows uefi tianocore BSOD ACPI_BIOS_ERROR
https://ticket.coreboot.org/issues/327#change-972

* Author: xinhua wang
* Status: New
* Priority: Normal
* Start date: 2021-12-30

https://review.coreboot.org/c/coreboot/+/27711/7/src/drivers/intel/gma/acpi/configure_brightness_levels.asl#28

this line .. OperationRegion (OPRG, SystemMemory, ASLS, 0x2000)
the 0x2000 will cause BSOD ACPI_BIOS_ERROR when booting installer, os, etc

When set to 0x1000 windows UEFI tianocore mode boots fine



---Files
dmesg.txt (76.9 KB)
results.log (204 KB)


-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
https://ticket.coreboot.org/my/account
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] [coreboot - Support #387] Support Framework Laptop

[Matt DeVillier]

Issue #387 has been updated by Matt DeVillier.


Jun Aruga wrote in #note-2:
> People in the community should be able to know the progress and involve the 
> task.

That's on Framework, not the coreboot commmunity.

> Anyway, first I want to know what prevents coreboot's port to the Framework 
> Laptop.

Intel BootGuard is active/enabled on the Framework laptop. That means that the 
system firmware (vendor UEFI, coreboot, etc) must be cryptographically signed 
with the same key fused into the PCH. Framework controls this key, and has 
proposed creating both a signed "official" coreboot image as well as signed 
shim which would allow user-built coreboot firmware to be used. 

Where they are on that process is unknown, because there has been no official 
overture from Framework to the coreboot community. They supposedly sent out 3 
dev units (which do not have Bootguard enabled) to individual developers. 
Matthew Garrett (mjg59) posted about his unsuccessful efforts a few months ago 
on Twitter but there has been nothing recent to my knowledge. Who else has dev 
boards is unknown.


Support #387: Support Framework Laptop
https://ticket.coreboot.org/issues/387#change-950

* Author: Jun Aruga
* Status: New
* Priority: Normal
* Category: board support
* Target version: none
* Start date: 2022-06-05
* Affected hardware: Framework Laptop

Dear coreboot developers,

I am a user of Framework Laptop[1][2]. Thank you for working to make coreboot 
work on Framework Laptop! This ticket is to track the task, as I didn't see any 
other issue tickets about Framework Laptop here. According to the Framework 
founder's comment[3] below, Framework provided Framework Laptops to the 
coreboot community.

> We've handed three systems that can boot unsigned bootloaders to folks in the 
> coreboot community. Our plan in the near term is to help them create a shim 
> loader that can be signed to run on any Framework Laptop, which then enables 
> anyone to do further coreboot development.

Then I saw Matthew's try to make the coreboot work on Framework Laptop,[4] but 
unfortunately it didn't work at that time.[5]

How is the current status? What prevents coreboot from working on the Framework 
Laptop? How can we, people in the Framework community, help you? As a 
reference, there is a coreboot specific thread on the Framework community 
forum.[6]

## References

* [1] https://frame.work/
* [2] Framework Computer - Wikipedia - 
https://en.wikipedia.org/wiki/Framework_Computer
* [3] Framework Laptop Mainboard, Hacker News, April 20, 2022 - 
https://news.ycombinator.com/item?id=31097434
* [4] Matthew tries to port Coreboot to the Framework laptop - February 27, 
2022 - https://www.youtube.com/watch?v=Jf_6xW-8tfQ
* [5] Matthew Garrett on Twitter, February 27, 2022 - 
https://twitter.com/mjg59/status/1497788538212917250
* [6] Free the EC! and Coreboot Only - 
https://community.frame.work/t/free-the-ec-and-coreboot-only/791



-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
https://ticket.coreboot.org/my/account
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Removing Yabits as a payload - Now, or after 4.19 release?

[Matt DeVillier]

I second Felix's suggestion

On Tue, May 31, 2022 at 3:39 PM Felix Singer  wrote:
>
> No objections. I think we should remove it now.
>
> // Felix
> ___
> coreboot mailing list -- coreboot@coreboot.org
> To unsubscribe send an email to coreboot-le...@coreboot.org
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Coreboot : Change/modify Boot maintenance manager for auto boot support.

[Matt DeVillier]

hi Amar,

What you're looking to change is not in coreboot, but the
Tianocore/edk2 payload - and from your post, a very old version of it,
since I'm not aware of any recent version booting directly into Boot
Maintenance Manager (unless you're building from upstream edk2, and
not including the EFI shell in the build, and don't have a valid UEFI
boot device available).

In terms of modifying/saving settings, upstream Tianocore does not
have a mechanism to do this when used as a coreboot payload; you need
to use the default Tianocore payload option in coreboot (my fork) and
enable coreboot's support for SMMSTOREv2 in order to have bootorder
and other settings persist.

On Thu, Apr 21, 2022 at 4:53 AM Putsala Amar via coreboot
 wrote:
>
> Hi,
>
>
> We are working on intel c508 intel denverton board.
> We have programmed coreboot image in 16MB NOR flash.
>
> After the coreboot hw initialization , it moves to payload stage by default 
> it is entering to "boot maintenance manager" . We expect the node to boot 
> without getting into boot manager(without waiting for any key) .
>
> Made below experiment which i found in BIOS :
> Change/Modify Auto Boot Time-out option as "0" in "Boot Maintenance manager".
> but this timeout parameter is not allow to commit/save the new changes.
>
> As per the Auto Boot Time-out description :
> Range: 0 means no wait , 65535 means waiting for Key.
> By default timeout hold 65535.
>
> Thanks in advance..,
>
>
>
> Thanks & Regards,
>
> Amar Putsala ( ID : 2353 )
> 4th Floor , Cubical : 4058
> J.P. Software Park,
> Electronic City Phase-1,
> Hosur Road, 560100
> Ext. No: 8110
> ___
> coreboot mailing list -- coreboot@coreboot.org
> To unsubscribe send an email to coreboot-le...@coreboot.org
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Two Payloads

[Matt DeVillier]

there are two ways to handle multiple payloads in coreboot:

1) have a single primary payload, which provides the mechanism to
execute secondary payloads. Grub and SeaBIOS can do this; Heads and
Tianocore cannot

2) have two primary payloads, and use the normal/fallback mechanism to
select between them using nvramtool

Either way you'd need to read/modify/write your existing coreboot
image, and in many cases simply rebuilding is easier.

For the example you gave, you'd want to use option #2 for
Heads+Tianocore, since launching one of those from the other is not
(currently) doable

On Thu, Apr 21, 2022 at 4:54 AM Lukas Jungbauer  wrote:
>
> Hi,
>
> is it possible to run two Payloads on Coreboot at the same Time, like Heads 
> and TianoCore?
>
> Payloads can only be installed by building a new Image and Software-Flashing 
> it, correct?
>
> Best Regards,
> Lukas
> ___
> coreboot mailing list -- coreboot@coreboot.org
> To unsubscribe send an email to coreboot-le...@coreboot.org
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Questions Regarding Flashing a Voxel (CP713-3W) Chromebook

[Matt DeVillier]

1) no, that's not the main firmware chip (possibly the EC firmware).
There's a 25Q256 chip for the main firmware somewhere, likely a WSON-8
package

2) N/A

3) You really need a Suzy-Q cable in order to reprogram the main
firmware, and to get serial debug info out in order to diagnose the
issue.

I've built test images of upstream coreboot+Tianocore for another
VOXEL user, and the payload was crashing for them, despite it working
on another volteer variant (DROBIT). I haven't had time to debug it,
but you're not really going to be able to do anything without a Suzy-Q
cable unfortunately

PS - you didn't mention what payload you built it with, that would be
helpful to know. Also, your defconfig and what region(s) you flashed.

On Fri, Dec 3, 2021 at 3:19 AM Matthew K  wrote:
>
> Hello!
>
> I've been attempting to flash Coreboot to a recently acquired Acer Chromebook 
> CP713-3W with the hope of eventually being able to boot from a USB drive and 
> install some variety of linux.
>
> Currently my system is only limitedly responsive when booting, so I acquired 
> a flash programmer to try and program the rom chip directly. When attempting 
> to do this (and also while building the rom from the google source code) I 
> noticed a few things that seemed to complicate the flashing process.
>
> The only chip I have identified so far as a rom chip is 1MB in size (Winbond 
> W25Q80DVSNIG). I was unable to read the intel firmware descriptor or a layout 
> file from it when attached with the usb programmer. When using the chromium 
> coreboot sources, selecting the voxel mainboard also automatically selected 
> the layout file associated with the volteer mainboards. Because this layout 
> file was for a 32MB chip, I was unable to use it to build the chip, but 
> because I didn't have a layout file, I didn't know what to set the size of 
> the CBFS filesystem to be in the build config. I attempted several guessed 
> sizes to just see if I could get a file to build, but no attempted size ended 
> up being able to even produce a rom image.
>
> I now have some questions.
>
> 1. Am I even looking at the right chip? Is there a different 32MB Rom that I 
> should be flashing to? Does the chromebook firmware live on the harddrive 
> somehow (I find this unlikely because the hard drive is replaceable, but I 
> wanted to mention the possibility)? If it's not the bios chip, then what is 
> it?
>
> 2. If this is the right chip, how do I reduce the size of the payload and/or 
> determine the appropriate size of the CBFS filesystem in order to create a 
> rom that I could flash? Is it feasible/would it be better to get a 32MB rom 
> chip, flash it with the built image from chromium coreboot and the volteer 
> layout file, and replace the current chip with it?
>
> 3. What sort of expectations should I have for the current status of coreboot 
> on this mainboard (either from the coreboot or chromium repositories)? What 
> additional work should I expect to have to do if I want to be able to e. g. 
> boot from a linux flash drive?
>
> Please let me know if there's more information I can provide that would be 
> useful, if there's a better place for me to ask these questions, or if there 
> are resources that can help guide me towards answering these questions for 
> myself.
>
> Matthew Kunjummen
> ___
> coreboot mailing list -- coreboot@coreboot.org
> To unsubscribe send an email to coreboot-le...@coreboot.org
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Another year, another blob?

[Matt DeVillier]

On Wed, Oct 20, 2021 at 8:53 AM Andy Pont  wrote:
>
> Nico wrote...
> >>  How about we set up some guidelines how to proceed when adding support
> >>  for a new platform that requires any blobs? My vague idea is as follows:
> >>  Before the very first commit for such a new platform can be merged, a
> >>  set of predefined, blob related questions (to be discussed) should be
> >>  answered.
> >
> >Some ideas for questions from the top of my head:
> That seems like a long list of questions and so my question in return
> would be how practical is it?
>
> Taking EC firmware as an example, in many situations the short answer is
> “it resides in the same binary image as coreboot and is a blob because
> that is all there is”.  Based on your list of questions I’m not
> convinced that would be sufficient to get it merged.

Why would we be adding EC blobs to the coreboot repo?

>
> -Andy.
>
>
> ___
> coreboot mailing list -- coreboot@coreboot.org
> To unsubscribe send an email to coreboot-le...@coreboot.org
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: The coreboot.org edk2 repo is live! (But don't get a heart attack)

[Matt DeVillier]

thanks for getting this set up Patrick!

On Tue, Oct 12, 2021 at 1:10 PM Patrick Georgi via coreboot
 wrote:
>
> Hi everybody,
>
> To facilitate cooperation on UEFI-as-a-payload work, we established a mirror 
> of tianocore's edk2 repo at https://review.coreboot.org/edk2. Unlike other 
> mirrors on review.coreboot.org, it's open for development.
>
> It's updated regularly, but the default branch that we set up, 
> coreboot-stable202108, is based on edk2-stable202108, so there won't be 
> changes flowing in automatically to the branch we will focus on.
>
> We will set up builders on qa.coreboot.org to cover that repo, so we get the 
> same "at the very least, it builds" guarantees that we have for any coreboot 
> contributions. Maybe we'll even get boot tests in the future, who knows?
>
> If you want to make coreboot+edk2 a viable option for starting hardware (with 
> the bonus compared to "regular" edk2 flows that hardware init happens on the 
> coreboot side, so if you want the same hardware to boot differently, it can 
> easily be made to be coreboot+SomethingElse!), there's plenty of 
> opportunities for developers.
>
> Matt DeVillier (Mr. Chromebox) offered to push his patch train there which 
> (as I understand it) is an amalgamation of changes made in various edk2 forks 
> in the coreboot ecosystem.
>
> Something people have talked about is adding Microsoft's Project Mu 
> (https://microsoft.github.io/mu/) UI improvements to tianocore-as-a-payload, 
> which could find a good home there, as well.
>
> Finally, SMMSTORE: it exists, it helps where it is supported to persist UEFI 
> variables, but as I understand it, actual support for devices is rather 
> limited.

SMMSTORE_V2 is fully working with the current coreboot default option
for Tianocore (UEFIPAYLOAD), and is selected by default. It should
work on all boards for which the default Tianocore option does;
currently it persists most (all?) EFI variables, including the boot
order entries. Most of the credit for this goes to the fine folks at
9elements.

> Making coreboot+edk2 the premier option for booting UEFI platforms would give 
> the rest of us something to work with that is more pleasant than trying to 
> NERF vendor firmware until it stops doing all the things we don't need it to 
> do.
>
> And if you don't care about UEFI (or if that's putting it mildly, even), 
> don't worry: this is only a payload. Just like we have FILO on our server or 
> SeaBIOS or depthcharge, this is just another option. But given the market 
> penetration of UEFI interfaces, it's an important one to get right.
>
>
> Patrick
> --
> Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
> Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: 
> Hamburg
> Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
> ___
> coreboot mailing list -- coreboot@coreboot.org
> To unsubscribe send an email to coreboot-le...@coreboot.org
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Coreboot on newer laptops

[Matt DeVillier]

On Fri, Sep 17, 2021 at 12:57 PM Brian Milliron
 wrote:
>
>
> > it's not going to be a setting in the vendor firmware.
> >
> > `intelmetool -b` should report the status properly
>
> intelmetool reports Bootguard is not activated, so looks like I am in
> the clear, though there was a memory read error for some reason.
>
> MEI found: [8086:2e0] Device 02e0
>
> ME Status   : 0xa245
> ME Status 2 : 0x6f10506
>
> ME: FW Partition Table  : OK
> ME: Bringup Loader Failure  : NO
> ME: Firmware Init Complete  : YES
> ME: Manufacturing Mode  : NO
> ME: Boot Options Present: NO
> ME: Update In Progress  : NO
> ME: Current Working State   : Normal
> ME: Current Operation State : M0 with UMA
> ME: Current Operation Mode  : Normal
> ME: Error Code  : No Error
> ME: Progress Phase  : ROM Phase
> ME: Power Management Event  : Pseudo-global reset
> ME: Progress Phase State: (null)
>
> ME: Extend SHA-256:
> 05045e8332f6cd294b001985eef893ac5c9fb1c58666459731b3fc0eeff07ad2
>
> Error mapping physical memory 0x01101824 [0x2000] ERRNO=1
> Operation not permitted Could not map ME setup memory.
> Do you have kernel cmdline argument 'iomem=relaxed' set ?
> BootGuard MSR Output : 0x0
>  [32mYour system isn't BootGuard ready.
> You can flash other firmware!
>  [0m
>
> Not sure why the memory error since I included iomem=relaxed in the
> grub.cfg
>
>  linux  /boot/vmlinuz-4.19.0-10-amd64
>  root=UUID=b889fd33-7705-4b9c-9c33-c304bbe7a6e5 ro iomem=relaxed quiet
>  linux  /boot/vmlinuz-4.19.0-10-amd64
>  root=UUID=b889fd33-7705-4b9c-9c33-c304bbe7a6e5 ro iomem=relaxed quiet
>  linux  /boot/vmlinuz-4.19.0-10-amd64
>  root=UUID=b889fd33-7705-4b9c-9c33-c304bbe7a6e5 ro single iomem=relaxed
>
> > nope, you'll need `inteltool -g` as well
>
> inteltool -g is one of the ones that doesn't work on this board.

well, fixing that is necessary, can't set up the GPIOs properly
without it (or the schematics)

>
> Error mapping SBREG_BAR: Operation not permitted
> CPU: ID 0x806ec, Processor Type 0x0, Family 0x6, Model 0x8e, Stepping
> 0xc Northbridge: 8086:9b61 (10th generation (Comet Lake family) Core
> Processor (Mobile)) Southbridge: 8086:0284 (Comet Point-LP U
> Premium/Cometlake) IGD: 8086:9b41 (Intel(R) UHD Graphics)
> SBREG_BAR = 0xfd00 (MEM)
>
> Error mapping physical memory 0xfd00[0x100]
>
> > me_cleaner doesn't support anything newer than 6th/7th-gen SoCs/CPUs.
> > The best you can do on Cometlake currently is to set the HAP bit in
> > the IFD.
>
> I suppose the HAP bit will have to do then.
>
> So, I guess the question at this point is how feasible would it be to
> install coreboot on this board? I'd rather not sink a lot of time into
> it if it's only going to lead to a dead end and using the board with
> vendor firmware is not an option for me because in addition to the
> Intel ME there is also Computrace which can't be disabled. I can't
> trust any PC with spyware built in.
>
> Andreas suggested I use the intel reference board setup in debug mode
> and use that to try to configure a working system. I see there is an
> intel reference board for Cometlake, but I don't know if I have the
> needed information to successfully configure the board properly, given
> the inteltool -g doesn't work and there may be problems finding the
> correct GPIO settings.

> I do have the pinout for the W25Q128JV chip
> which holds the BIOS. Not sure if that helps with the GPIO or not.

that's standard and not of any use with GPIOs

> What do the coreboot developers think about this situation? Is there a way
> forward and if so what would it involve?

I'm guessing it's kernel perms that's preventing inteltool from
dumping GPIOs, might try with an early 5.x kernel and see if any
different
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Coreboot on newer laptops

[Matt DeVillier]

On Thu, Sep 16, 2021 at 9:36 AM Brian Milliron
 wrote:
>
>
> > Using a hardware flasher isn't a workaround, the signature check is
> > done in hardware by the ACM using keys fused into the ME. If Bootguard
> > enabled and keys fused, nothing can be done unfortunately.
>
> I checked the BIOS. There was nothing specifically listed as
> "Bootguard" but all the BIOS protection options were turned off,
> including one listed as "Checked boot block on every boot". I'm
> guessing that means Bootguard is installed but not enabled. Is there
> another place to look to get a more accurate/detailed read on this?

it's not going to be a setting in the vendor firmware.

`intelmetool -b` should report the status properly

>
> > You can build a large chunk of the board profile using inteltool (if
> > platform supported), dumping ACPI, etc. But there are plenty of bits
> > that aren't currently documented. And getting the EC to cooperate can
> > be a real chore.
>
> I dumped what inteltool was able to read, but I got a lot of "platform
> not supported" errors. I've attached the output to the end of this
> message. Do you think this information would be enough to create a
> bootable board profile?

nope, you'll need `inteltool -g` as well

>
> > the IFD and ME aren't needed strictly speaking, unless you need to
> > modify them in some way. But you would extract those using ifdtool.
> > Definitely don't want to use a non-board-specific ME downloaded from
> > win-raid (eg) as the soft straps and clock mappings will not be
> > correct for your board.
>
> I intend on using me_cleaner to wipe all but a stub of the ME code, so
> having a working copy isn't something I'm too worried about as long as
> it passes the signature checks.

me_cleaner doesn't support anything newer than 6th/7th-gen SoCs/CPUs.
The best you can do on Cometlake currently is to set the HAP bit in
the IFD.

>
> > FSP (which contains both the MRC and PCH refcode) also does video
> > init, and VBIOS isn't used on modern platforms. coreboot's native
> > display init (libgfxinit) is preferred if available. The only bit you
> > will likely need is the VBT, which you can get from Linux (or dump
> > from vendor firmware, but often contains multiple copies).
>
> How would I get hold of this?

I don't have the method handy, I usually just extract it from the
vendor firmware using UEFITool

>
>
> ###Inteltool output###
>
> CPU: ID 0x806ec, Processor Type 0x0, Family 0x6, Model 0x8e, Stepping
> 0xc Northbridge: 8086:9b61 (10th generation (Comet Lake family) Core
> Processor (Mobile)) Southbridge: 8086:0284 (Comet Point-LP U
> Premium/Cometlake) IGD: 8086:9b41 (Intel(R) UHD Graphics)
> SBREG_BAR = 0xfd00 (MEM)
>
> Error mapping physical memory 0xfd00[0x100]
> CPU: ID 0x806ec, Processor Type 0x0, Family 0x6, Model 0x8e, Stepping
> 0xc Northbridge: 8086:9b61 (10th generation (Comet Lake family) Core
> Processor (Mobile)) Southbridge: 8086:0284 (Comet Point-LP U
> Premium/Cometlake) IGD: 8086:9b41 (Intel(R) UHD Graphics)
>
> == LPC/eSPI =
>
> Error: Dumping LPC/eSPI on this southbridge is not (yet) supported.
>
>
> CPU: ID 0x806ec, Processor Type 0x0, Family 0x6, Model 0x8e, Stepping
> 0xc Northbridge: 8086:9b61 (10th generation (Comet Lake family) Core
> Processor (Mobile)) Southbridge: 8086:0284 (Comet Point-LP U
> Premium/Cometlake) IGD: 8086:9b41 (Intel(R) UHD Graphics)
>
>
> CPU: ID 0x806ec, Processor Type 0x0, Family 0x6, Model 0x8e, Stepping
> 0xc Northbridge: 8086:9b61 (10th generation (Comet Lake family) Core
> Processor (Mobile)) Southbridge: 8086:0284 (Comet Point-LP U
> Premium/Cometlake) IGD: 8086:9b41 (Intel(R) UHD Graphics)
>
> = AHCI Registers ==
>
>
> = AHCI Configuration Registers ==
>
>
> = SATA Initialization Registers ==
>
>
> = ABAR ==
>
> ABAR = 0xf1215000 (MEM)
>
> Error mapping physical memory 0xf1215000[0x400]
> CPU: ID 0x806ec, Processor Type 0x0, Family 0x6, Model 0x8e, Stepping
> 0xc Northbridge: 8086:9b61 (10th generation (Comet Lake family) Core
> Processor (Mobile)) Southbridge: 8086:0284 (Comet Point-LP U
> Premium/Cometlake) IGD: 8086:9b41 (Intel(R) UHD Graphics)
>
> = Dumping INTEL SGX status =
> Number of CPUs = 8
> - CPU 0 
> SGX supported : YES
> SGX enabled   : YES
> Feature Control locked: YES
> - CPU 1 
> SGX supported : YES
> SGX enabled   : YES
> Feature Control locked: YES
> - CPU 2 
> SGX supported : YES
> SGX enabled   : YES
> Feature Control locked: YES
> - CPU 3 
> SGX supported : YES
> SGX enabled   : YES
> Feature Control locked: YES
> - CPU 4 
> SGX supported : YES
> SGX enabled   : YES
> Feature Control 

[coreboot] Re: Coreboot on newer laptops

[Matt DeVillier]

On Tue, Sep 14, 2021 at 1:58 PM Brian Milliron
 wrote:
>
> Hi Matt.
>
>
> > hi Brian,
> >
> > coreboot support is extremely hardware specific by nature, so there
> > are no generic platform targets (other than the emulation ones).
> >
> > In order to use coreboot on your board, you'd first need to ensure
> > that Bootguard (or similar signature checking schemes) are not being
> > used, which would prevent loading unsigned firmware. Then you'd need
> > to dump the hardware config of the device in order to build a board
> > profile (devicetree, GPIO assignments, etc).
>
> There is firmware signing, but as I'm using a hardware based flasher, I
> can circumvent this, I think. How would I dump the hardware config and
> build a board profile? Is that something I could do myself or would it
> be up to the coreboot devs to create and integrate a board profile?

Using a hardware flasher isn't a workaround, the signature check is
done in hardware by the ACM using keys fused into the ME. If Bootguard
enabled and keys fused, nothing can be done unfortunately.

You can build a large chunk of the board profile using inteltool (if
platform supported), dumping ACPI, etc. But there are plenty of bits
that aren't currently documented. And getting the EC to cooperate can
be a real chore.

>
> > cbfstool isn't going to recognize a dump of your vendor firmware as it
> > doesn't contain a CBFS (coreboot filesystem). You'll need to use other
> > tools if you need to dump/extract bits from the vendor firmware,
> > though that's not always necessary, given that FSP does most of the
> > heavy lifting and is included as part of the build process for (most)
> > platforms that use it
>
> I was under the impression I would need the flash descriptor, video
> BIOS or VBT, Intel ME, PCH Reference Code, and Memory
> Reference Code (MRC).  The Intel ME I downloaded from the winraid
> archive, but the others I would need to get from firmware. The Intel
> FSP is now included in coreboot? Are none of the others needed any
> more? If some of them are needed, what tools could I use to extract
> them?
>

the IFD and ME aren't needed strictly speaking, unless you need to
modify them in some way. But you would extract those using ifdtool.
Definitely don't want to use a non-board-specific ME downloaded from
win-raid (eg) as the soft straps and clock mappings will not be
correct for your board.

FSP (which contains both the MRC and PCH refcode) also does video
init, and VBIOS isn't used on modern platforms. coreboot's native
display init (libgfxinit) is preferred if available. The only bit you
will likely need is the VBT, which you can get from Linux (or dump
from vendor firmware, but often contains multiple copies).
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Coreboot on newer laptops

[Matt DeVillier]

hi Brian,

coreboot support is extremely hardware specific by nature, so there
are no generic platform targets (other than the emulation ones).

In order to use coreboot on your board, you'd first need to ensure
that Bootguard (or similar signature checking schemes) are not being
used, which would prevent loading unsigned firmware. Then you'd need
to dump the hardware config of the device in order to build a board
profile (devicetree, GPIO assignments, etc).

cbfstool isn't going to recognize a dump of your vendor firmware as it
doesn't contain a CBFS (coreboot filesystem). You'll need to use other
tools if you need to dump/extract bits from the vendor firmware,
though that's not always necessary, given that FSP does most of the
heavy lifting and is included as part of the build process for (most)
platforms that use it

cheers,
Matt

On Tue, Sep 14, 2021 at 12:42 PM Brian Milliron
 wrote:
>
> I've run into 2 problems with trying to set up coreboot for an HP
> Probook 440 G7. The first is that I don't see this model listed as an
> option in the menuconfig. It is a newer Intel Cometlake CPU/chipset and
> most of what I see listed as options are much older machines. Is there
> a "generic cometlake" config I can try or am I just out of luck on this?
>
> The 2nd problem is that cbfstool doesn't recognize the bios dump I did
> from the mainboard. I get the error "Selected image region is not a
> valid CBFS." I'm pretty sure the the dump is valid because I can read
> it using the Intel FIT tool or ME_Analyzer. I'm going to need to pull
> the various binary blobs out of the current firmware and this is the
> only way I know how. Is there another option here?
> ___
> coreboot mailing list -- coreboot@coreboot.org
> To unsubscribe send an email to coreboot-le...@coreboot.org
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Question On External Display

[Matt DeVillier]

On Wed, Aug 11, 2021 at 5:05 AM Rao G  wrote:
>
> Thanks Nico for your response.
>
> > am expecting some register should set with eDP as interface and when
> > display is connected
> >
> > any clue why the i915 OS driver was turning off DP display in case 2?
> I assume the HPD signal doesn't get through to the software.
>
> [Rao]
> You mean I need to check PORT_HOTPLUG_EN and PORT_HOTPLUG_STAT mmio offsets 
> for this issue?
> BIOS display is fine, Windows logo is also seen but there is no signal when 
> "windows login" is reached

IME, that's almost always due to incorrect/missing/mismatched VBT data
in the ACPI opregion/mailbox

>
> It had similar behaviour w.r.t to ubuntu 18.04, I configured DDI1 to "DP with 
> HDMI/DVI"
>
> Can this issue be fixed with VBE data configured through BMP or it needs a 
> fix from graphics MMIO?
>
> Regards
> Rao
>
> On Fri, Jul 30, 2021 at 10:27 PM Nico Huber  wrote:
>>
>> On 30.07.21 18:59, Rao G wrote:
>> > Thanks Nico.
>> >
>> > HPD is active , measured the signal
>>
>> Is your coreboot port public somewhere? If the hardware is fine, maybe
>> the firmware isn't?
>>
>> >
>> > Configured Ports
>> > 1.DDI0- PortB - DP with HDMI/DVI is good in BIOS & OS
>> > 2.DDI1- PortC - DP with HDMI/DVI is good in BIOS, i915 was turning off the
>> > DP display (Never understood the reason)
>>
>> It's very suspicious that these two behave differently. Does the HPD
>> signal (MMIO read) work for DDI0?
>>
>> >
>> > So configured PortC with eDP
>> >
>> > If there is no way BIOS to detect the external display with MMIO registers
>> > when configured as eDP, Can i not turn off the DDI1/Port C at runtime in
>> > BIOS,
>>
>> Maybe it's time to switch to an open-source solution? libgfxinit will
>> probably have the same issue, but it might be possible to get a rather
>> short delay.
>>
>> > am expecting some register should set with eDP as interface and when
>> > display is connected
>> >
>> > any clue why the i915 OS driver was turning off DP display in case 2?
>>
>> I assume the HPD signal doesn't get through to the software.
>>
>> Nico
>
> ___
> coreboot mailing list -- coreboot@coreboot.org
> To unsubscribe send an email to coreboot-le...@coreboot.org
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: coreboot on Chromebook octopus/casta/bluebird with u-boot payload - blank screen

[Matt DeVillier]

On Fri, Jul 23, 2021 at 12:13 PM James Feeney  wrote:
>
> On 7/23/21 8:07 AM, Matt DeVillier wrote:
>
> Thanks for your review.
>
> >> Are there any other things to try, before heating-up the soldering iron?  
> >> Is there any way to cross-check what flashrom is seeing?  Is there any way 
> >> for Cr50 to directly access the AP boot flash memory itself and then 
> >> report through the Cr50 console, without involving flashrom?
> > I don't believe so, someone from Google would likely be able to better 
> > answer
> >
>
> That seems like shortsightedness from Google, not providing some kind of 
> internal test/verification function for some hardware I/O.
>
> >> As to the "broken hardware" theory, have you ever heard of anyone 
> >> attaching a flash programmer to a Google octopus board and successfully 
> >> reading flash memory content *in circuit*?
> > never tried since CCD option is available, but in theory it should be 
> > possible.
> >
>
> Hmm - tentatively, it might be useful to other people to offer the advise 
> "NEVER attach an in-circut flash programmer to an octopus board!"  I don't 
> know that anyone would want to actually test this conjecture with their own 
> hardware.  It looks like I may have to buy the service manual from Samsung, 
> but they refuse to tell me whether it includes the schematics.
>
> Ironically, the inability to attach a flash programmer in-circuit to a 
> Chromebook having Google's H1 security chip represents a kind of security 
> failure.  Specifically, how is the boot flash content to be verified with the 
> certainty that the true content has not been hidden by Cr50, or by, for 
> instance, flashrom running from eMMC root, when the AP is used to read the 
> boot flash?

Inability? due to it being a WSON-8 chip or? Every Chromebook since
~2013 has supported ISP, AFAIK. And up until recently, most used a
clippable SOIC-8 chip.

>
> It cannot be verified.  The only alternative is to unsolder the flash chip, 
> and read it externally.  Of course, if Cr50 has been compromised, verifying 
> boot flash may not matter.  But then, in the end, this is Google's "Security 
> by Obscurity - just hide it in hardware" strategy, since I don't know that 
> there is any way to verify the Cr50 code running in the H1 chip.  You'd think 
> that, by now, people would have given-up on the "Security by Obscurity" 
> strategy - but I suppose that marketing and management have still not 
> caught-up, gotten the memo, whatever - "Intellectual Property Rights", "Trade 
> Secrets", "National Security", blah, blah, blah.
>
> Also ironically, the actual cost to provide circuit protection for in-circuit 
> flash programming is approximately "zero" - the cost of a few resistors and 
> maybe a diode.  I found this interesting:
>
> "Integrity Enhancements for Embedded Linux Devices", David Safford
> https://selinuxproject.org/~jmorris/lss2013_slides/safford_embedded_lss_slides.pdf
>
> It looks like the maximum current on a typical ARM SC300 GPIO, as used for 
> the H1, is about 4mA.  Compare this to the maximum current available from a 
> typical buffer output, as from a flash programmer, of about 50mA, if these 
> circuits were to be directly connected.
>
> 
>
> James
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: coreboot on Chromebook octopus/casta/bluebird with u-boot payload - blank screen

[Matt DeVillier]

On Thu, Jul 22, 2021 at 7:29 PM James Feeney  wrote:
>
> On 7/22/21 3:53 PM, Matt DeVillier wrote:
> ...
> >> I get "No EEPROM/flash device found".  Running with -V, I see flashrom is 
> >> just reading all 1's.
> >
> > you need to open the CCD first. With the battery disconnected, from a
> > terminal attached to /dev/ttyUSB0, run:
> > ccd open
> > ccd reset factory
> > ccd
> >
> > that should show the ccd state as open, with all capabilities in
> > column 1 set to 'Y'.
> >
> > then flashrom will be able to detect / read / write the flash chip
> >
>
> I believe that I have already done all of that.  But please, check to see if 
> I know what I'm doing here:
>

LGTM

>
> > ccd
> State: Opened
> Password: none
> Flags: 0x45
> Capabilities: 5500
>   UartGscRxAPTx   Y 1=Always
>   UartGscTxAPRx   Y 1=Always
>   UartGscRxECTx   Y 1=Always
>   UartGscTxECRx   Y 1=Always
>   FlashAP Y 1=Always
>   FlashEC Y 1=Always
>   OverrideWP  Y 1=Always
>   RebootECAP  Y 1=Always
>   GscFullConsole  Y 1=Always
>   UnlockNoReboot  Y 1=Always
>   UnlockNoShortPP Y 1=Always
>   OpenNoTPMWipe   Y 1=Always
>   OpenNoLongPPY 1=Always
>   BatteryBypassPP Y 1=Always
>   UpdateNoTPMWipe Y 1=Always
>   I2C Y 1=Always
>   FlashRead   Y 1=Always
>   OpenNoDevMode   Y 1=Always
>   OpenFromUSB Y 1=Always
>   OverrideBattY 1=Always
> read_tpm_nvmem: object at 0x100a not found
> [50.223548 Console unlock allowed]
> read_tpm_nvmem: object at 0x1007 not found
> TPM:
> Capabilities are modified.
> Use 'ccd help' to print subcommands
>
> > ccd testlab
> CCD test lab mode enabled
>

I've never used testlab mode, looks like it just disables the need for
physical presence so shouldn't be an issue

>
> >
> > see above, the ccd being closed w/default capabilities set is
> > preventing the flash chip from being visible/read/written.
> >
> > I've used ccd to read/write many an AP flash, including APL/GLK Chromebooks.
> >
>
> Including a Samsung octopus board?  Samsung didn't "cut corners" on the 
> design implementation?

Not a Samsung one, but considering they are all built from the same
reference board, it's unlikely Samsung somehow broke CR50 AP access.
Then again, they did manage to screw up the HPET (among other things)
on CELES. Still, I would consider that a pretty low possibility. I
have an Asus octopus/AMPTON board here that I've flashed 100x via ccd.

>
> I'm hoping very much that the problem is something simple.  But still:
>
> $ sudo ./flashrom -p raiden_debug_spi:target=AP
> flashrom abb3b091 on Linux 5.12.14-arch1-1 (x86_64)
> flashrom is free software, get the source code at https://flashrom.org
>
> Using clock_gettime for delay loops (clk_id: 1, resolution: 1ns).
> Raiden target: 2
> No EEPROM/flash device found.
> Note: flashrom can never write if the flash chip isn't found automatically.
>

that's definitely the issue, I'm just not sure offhand what else could
cause the AP flash to not be available.

>
> After running flashrom, the machine appears always to reboot.  The Cr50 
> console says:

this is expected, since the CR50 switches modes to enable flash
access. It will reboot when exiting SPI mux mode regardless of the
flash operation.

>
> [631.035522 enable_spi_pinmux: AP]
> [631.106361 usb_spi_board_disable]
> [631.668071 AP UART on]
> [631.669563 CCD state: UARTAP+TX UARTEC+TX I2C SPI USBEC+TX]
> [631.884475 deferred_tpm_rst_isr]
> [631.885501 AP on]
> [631.886077 tpm_reset_request(0, 0)]
> [631.886932 tpm_reset_now(0)]
> [631.890377 tpm_init]
> tpm_manufactured: manufactured
> [631.892402 tpm_reset_now: done]
> [632.031471 AC: R-]
>
>
> Are there any other things to try, before heating-up the soldering iron?  Is 
> there any way to cross-check what flashrom is seeing?  Is there any way for 
> Cr50 to directly access the AP boot flash memory itself and then report 
> through the Cr50 console, without involving flashrom?

I don't believe so, someone from Google would likely be able to better answer

>
> I see something called "spihash", which gives:
>
> > spihash ap
> [1396.457412 enable_spi_pinmux: AP]
> [1396.460723 spi_hash_pp_done: AP]
> >
>
> Then, there is a delay, followed spontaneously by:
>
> [1456.460903 spi_hash_disable]
> [1457.020969 AP UART on]
> [1457.022476 CCD state: UARTAP+TX UARTEC+TX I2C SPI USBEC+TX]
> [1457.237365 deferred_tpm_rst_isr]
> [1457.238426 AP on]
> [1457.239028 tpm_reset_request(0, 0)]
> [1457.239898 tpm_reset_now(0)]
> [1457.243381 tpm_init]
> tpm_manufactured: man

[coreboot] Re: coreboot on Chromebook octopus/casta/bluebird with u-boot payload - blank screen

[Matt DeVillier]

On Thu, Jul 22, 2021 at 3:56 PM James Feeney  wrote:
>
> On 7/3/21 8:22 AM, Matt DeVillier wrote:
>
> Thanks for that.
>
> > I don't see the command you used to flash -- what was that? You also
> > didn't clear the WP range (flashrom --wp-range 0,0) which has
> > historically been needed on small core/Atom boards, but if you didn't
> > get an error flashing/erasing then you're probably fine.
>
> >> $ flashrom -p host -l layout.txt -i BIOS  -w coreboot.rom
>
> The write-protect range was already 0,0, so I didn't bother with setting that.
>
> > display backlight means it's booted to ramstage, since that's where
> > FSP-S will init the backlight. It most likely means coreboot ran
> > successfully and the payload is the issue.
> >
> > How to debug? Get yourself a Suzy-Q cable, rebuild with the serial
> > console enabled, flash via Suzy-Q, and then monitor via the
> > /dev/ttyUSB1 serial port (CPU UART)
> >
> > see:
> > https://chromium.googlesource.com/chromiumos/platform/ec/+/cr50_stab/docs/case_closed_debugging_cr50.md
> > https://wiki.mrchromebox.tech/Unbricking#Unbricking.2FFlashing_with_a_Suzy-Q_cable
> >
>
> I finally received a SuzyQable.  There was a supply issue.
>
> And, after lots of reading at
>
> https://chromium.googlesource.com/chromiumos/platform/ec/+/cr50_stab/docs/case_closed_debugging_cr50.md
>
> and related, followed by a bit of trial and error, and then observing the AP 
> console, the boot sequence ends with
>
> ...
> CBFS: Found 'fallback/payload' @0xf2d00 size 0x3ce03
> Checking segment from ROM address 0xffc3402c
> Checking segment from ROM address 0xffc34048
> Loading segment from ROM address 0xffc3402c
>   code (compression=1)
>   New segment dstaddr 0x0111 memsize 0x8ccd4 srcaddr 0xffc34064 filesize 
> 0x3cdcb
> Loading Segment: addr: 0x0111 memsz: 0x0008ccd4 filesz: 
> 0x0003cdcb
> using LZMA
> Loading segment from ROM address 0xffc34048
>   Entry Point 0x01110015
> BS: BS_PAYLOAD_LOAD run times (exec / console): 147 / 46 ms
> CSE FWSTS1: 0x8245
> CSE FWSTS2: 0x3085
> CSE FWSTS3: 0x
> CSE FWSTS4: 0x0008
> CSE FWSTS5: 0x
> CSE FWSTS6: 0x4000
> ME: Manufacturing Mode  : NO
> ME: FPF status  : fused
> Putting xHCI port 0 into host mode.
> xHCI port 0 host switch over took 0 ms
> BS: BS_PAYLOAD_LOAD exit times (exec / console): 17 / 28 ms
> mp_park_aps done after 0 msecs.
> Jumping to boot code at 0x01110015(0x79b38000)
>
>
> And then - nothing - other than that the screen backlight comes on.
>
> So yes, as you say, seems like coreboot works, and my u-boot does not.
>
>
> > if you want to try a tested/verified prebuilt image w/Tianocore
> > payload, you can use:
> > https://mrchromebox.tech/test/fw/coreboot_tiano-bluebird-mrchromebox_20210621.rom
> > https://mrchromebox.tech/test/fw/coreboot_tiano-bluebird-mrchromebox_20210621.rom.sha1
> >
>
>
> Compiling flashrom from from both
>
> git clone https://chromium.googlesource.com/chromiumos/third_party/flashrom
> WARNERROR=no CONFIG_MEC1308=no CONFIG_ENE_LPC=no make
>
> and
>
> git clone 
> https://chromium.googlesource.com/chromiumos/platform/standalone-hdctools
> flashrom install
>
> which seem to act the same, and then running
>
> sudo ./flashrom -p raiden_debug_spi:target=AP
>
> I get "No EEPROM/flash device found".  Running with -V, I see flashrom is 
> just reading all 1's.

you need to open the CCD first. With the battery disconnected, from a
terminal attached to /dev/ttyUSB0, run:
ccd open
ccd reset factory
ccd

that should show the ccd state as open, with all capabilities in
column 1 set to 'Y'.

then flashrom will be able to detect / read / write the flash chip

>
> Hmm.  Nothing I can do until this is made to work.
>
> While waiting for the SuzyQable, I had tried reading the flash memory with 
> the TUMPA flash programmer.  No joy.  I suppose it is possible that I may 
> have burned-out something on the Chromebook board.  However, this seems 
> highly unlikely, because the AP can still boot from the flash memory, and 
> because of the apparent circuit layout.  While I do not have a schematic for 
> this Samsung Chromebook 4, listening to
>
> OSFC 2018 - Google Secure Microcontroller and CCD | Vadim Bendebury
> Oct 2, 2018
> https://www.youtube.com/watch?v=gC-lbMNmIsg
>
> and noting particularly the block diagram in slide 9, from
>
> https://2018.osfc.io/talks/google-secure-microcontroller-and-ccd-closed-case-debugging.html
> https://2018.osfc.io/uploads/talk/paper/7/gsc_copy.pdf
>
> - the "AP PROG" AND "EC PROG" labels on H1

[coreboot] Re: coreboot on Chromebook octopus/casta/bluebird with u-boot payload - blank screen

[Matt DeVillier]

I don't see the command you used to flash -- what was that? You also
didn't clear the WP range (flashrom --wp-range 0,0) which has
historically been needed on small core/Atom boards, but if you didn't
get an error flashing/erasing then you're probably fine.

display backlight means it's booted to ramstage, since that's where
FSP-S will init the backlight. It most likely means coreboot ran
successfully and the payload is the issue.

How to debug? Get yourself a Suzy-Q cable, rebuild with the serial
console enabled, flash via Suzy-Q, and then monitor via the
/dev/ttyUSB1 serial port (CPU UART)

see:
https://chromium.googlesource.com/chromiumos/platform/ec/+/cr50_stab/docs/case_closed_debugging_cr50.md
https://wiki.mrchromebox.tech/Unbricking#Unbricking.2FFlashing_with_a_Suzy-Q_cable

if you want to try a tested/verified prebuilt image w/Tianocore
payload, you can use:
https://mrchromebox.tech/test/fw/coreboot_tiano-bluebird-mrchromebox_20210621.rom
https://mrchromebox.tech/test/fw/coreboot_tiano-bluebird-mrchromebox_20210621.rom.sha1

On Fri, Jul 2, 2021 at 7:10 PM James Feeney  wrote:
>
> Ok, I finally flashed this coreboot.rom to the Samsung Chromebook 4, 
> octopus/casta/bluebird, after disconnecting the battery and:
>
> $ flashrom -p host --wp-status
> $ flashrom -p host --wp-disable
> $ flashrom -p host -l layout.txt -i BIOS  -w coreboot.rom
> $ flashrom -p host -r cbimage.bin
>
> with
>
> $ cat -A layout.txt
> 1000:00f7efff BIOS$
>
> where flashrom says
>
> FREG0:  Flash Descriptor region (0x   - 0x  0fff) is read-only.
> FREG5:  Device Expansion region (0x 00f7 f000 - 0x 00ff ) is locked.
>
>
> Now, pressing the power button lights the display backlight, but that is all.
>
> There is no u-boot prompt, though I have no experience with what to expect 
> here.
>
> Any suggestions, please?
>
> Thanks
> James
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: FsptUpd.h: No such file or directory - compilation terminated - Error 1

[Matt DeVillier]

I don't see the problem here TBH. There's no issue, security or
otherwise, with coreboot having fmap regions within the IFD BIOS
region that are not contiguous. Alignment requirements (eg, 64k) for
some regions practically guarantee this.

ifdtool complained here because a manually generated flashmap had a
BIOS region that wasn't top-aligned with the IFD one.

On Thu, Jun 24, 2021 at 7:37 AM James Feeney  wrote:
>
> On 6/24/21 12:48 AM, James Feeney wrote:
> > On 6/23/21 8:59 PM, James Feeney wrote:
> >> On 6/23/21 6:51 PM, Matt DeVillier wrote:
> >>> On Wed, Jun 23, 2021 at 4:36 PM James Feeney  wrote:
> >>>>
> >>>> On 6/23/21 1:40 PM, Matt DeVillier wrote:
> >>>>> I'm an idiot and made a stupid math error when I calculated the size
> >>>>> of the SI_BIOS region. 0xF7F000 - 0x1000 is 0xF7E000, not 0xF6F000.
> >>>>>
> >>>>> https://review.coreboot.org/c/coreboot/+/55815 fixes it
> >>>>>
> >>>>
> >>>> Ha!  I was a little suspicious of the suggestive pattern, 0xF7F000 - 
> >>>> 0x1 = 0xF6F000 vs 0xF7F000 - 0x1000 = 0xF7E000.  But, I missed the 
> >>>> hard-coded "SI_BIOS@0x1000 0xf6f000".
> >>>>
> >>>> So, I see src/mainboard/google/octopus/default.fmd, specifically, is 
> >>>> determining here.
> >>>>
> >>>> Still, many questions from those of us less familiar.  What is the 
> >>>> meaning of "SI"?  Does "SI_BIOS" have the same usage as "BIOS"?  
> >>>> Coreboot "BIOS" is not the same thing as original "BIOS".  
> >>>> ...
> >>>
> >>> coreboot's FMAP is a more finely grained map of the firmware image
> >>> than the IFD's, which is necessary for coreboot (and vboot, and other
> >>> utils) to locate things in the different regions.
> >>>
> >>> I'm not sure where the SI_BIOS nomenclature comes from, it's a Google
> >>> thing I think so one of those folks from the old days would have to
> >>> chime in. On older boards it did/does encapsulate all of the coreboot
> >>> FMAP regions which reside inside the IFD's BIOS region.
> >>>>
> >>>> Are there any "official" specifications for coreboot fmap format?
> >>>
> >>> https://doc.coreboot.org/lib/flashmap.html
> >>>
> >>>> Wish me luck.  I should have a functional bootrom image now!
> >>>
> >>> well, it would have been functional before, as I've apparently been
> >>> using improperly sized images for quite some time :)
> >>
> >> https://chromium-review.googlesource.com/c/chromiumos/third_party/coreboot/+/255031/11/util/cbfstool/README.fmaptool
> >>
> >> "... gaps are allowed ..."
> >>
> >> So then, your images are actually, technically, "proper", even though some 
> >> rom space was wasted.
> >>
> >> But, this element of the specification strikes me as a waking big security 
> >> problem waiting to happen.
> >>
> >> I don't see any substantive reason for the Flashmap Descriptor 
> >> specification to allow gaps, and, as we have seen, allowing gaps can also 
> >> lead to inadvertant errors being introduced into the resulting flashmap 
> >> descriptor files.
> >>
> >> I believe, instead, that gaps should specifically be *prohibited* in the 
> >> Flashmap Descriptor specification.
> >>
> >> I suggest that the question of allowing gaps in the flashmap descriptor 
> >> should receive wider discussion, particularly as having - I would think 
> >> obvious - security implications, if not simply to avoid inadvertant errors.
> >>
> >>
> >> James
> >>
> >
> > Hmm - on second thought, I suppose that there are *always* going to be 
> > "gaps", since the rom is never "full", and the actual space taken by some 
> > random mix of files will not be known in advance.
> >
> > Maybe the only alternative, simply for the sake of consistency and error 
> > checking, is to require and define certain "contiguous" regions of rom, 
> > within which gaps would not be allowed.  That way, errors would be 
> > disclosed, while gaps might be "forced" into defined regions, which could 
> > be specifically "locked", if desired.
> >
> > Other people have thought about this?
> >
> >
> > James
>
> Or, a simpler idea that could be useful - cbfstool layout could just 
> autogenerate "GAP" regions in the output, to make these more apparent.
>
>
> James
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: FsptUpd.h: No such file or directory - compilation terminated - Error 1

[Matt DeVillier]

On Wed, Jun 23, 2021 at 4:36 PM James Feeney  wrote:
>
> On 6/23/21 1:40 PM, Matt DeVillier wrote:
> > I'm an idiot and made a stupid math error when I calculated the size
> > of the SI_BIOS region. 0xF7F000 - 0x1000 is 0xF7E000, not 0xF6F000.
> >
> > https://review.coreboot.org/c/coreboot/+/55815 fixes it
> >
>
> Ha!  I was a little suspicious of the suggestive pattern, 0xF7F000 - 0x1 
> = 0xF6F000 vs 0xF7F000 - 0x1000 = 0xF7E000.  But, I missed the hard-coded 
> "SI_BIOS@0x1000 0xf6f000".
>
> So, I see src/mainboard/google/octopus/default.fmd, specifically, is 
> determining here.
>
> Still, many questions from those of us less familiar.  What is the meaning of 
> "SI"?  Does "SI_BIOS" have the same usage as "BIOS"?  Coreboot "BIOS" is not 
> the same thing as original "BIOS".  ...

coreboot's FMAP is a more finely grained map of the firmware image
than the IFD's, which is necessary for coreboot (and vboot, and other
utils) to locate things in the different regions.

I'm not sure where the SI_BIOS nomenclature comes from, it's a Google
thing I think so one of those folks from the old days would have to
chime in. On older boards it did/does encapsulate all of the coreboot
FMAP regions which reside inside the IFD's BIOS region.
>
> Are there any "official" specifications for coreboot fmap format?

https://doc.coreboot.org/lib/flashmap.html

> Wish me luck.  I should have a functional bootrom image now!

well, it would have been functional before, as I've apparently been
using improperly sized images for quite some time :)

>
>
> Thanks
> James
>
>
> > On Wed, Jun 23, 2021 at 1:48 PM James Feeney  wrote:
> >>
> >> On 6/22/21 11:13 PM, Matt DeVillier wrote:
> >>> On Tue, Jun 22, 2021 at 10:59 PM James Feeney  wrote:
> >>>>
> >>>> On 6/22/21 4:32 PM, Matt DeVillier wrote:
> >>>>> I'm not sure why you enabled so many things not selected in my
> >>>>> defconfig -- that's your issue.
> >>>>
> >>>> Ha!  Quite!  Bit of a learning curve, though...
> >>>>
> >>>> Ok, thanks for the clarifications - lots of things I do not need.
> >>>>
> >>>>> Use:
> >>>>>
> >>>>> CONFIG_VENDOR_GOOGLE=y
> >>>>> CONFIG_PAYLOAD_CONFIGFILE="../configubootJun14-2"
> >>>>> # CONFIG_POST_DEVICE is not set
> >>>>> CONFIG_BOARD_GOOGLE_CASTA=y
> >>>>> CONFIG_INCLUDE_NHLT_BLOBS=y
> >>>>> CONFIG_NEED_IFWI=y
> >>>>> CONFIG_HAVE_IFD_BIN=y
> >>>>> CONFIG_ADD_FSP_BINARIES=y
> >>>>> CONFIG_FSP_M_FILE="3rdparty/blobs/mainboard/$(MAINBOARDDIR)/fspm.bin"
> >>>>> CONFIG_FSP_S_FILE="3rdparty/blobs/mainboard/$(MAINBOARDDIR)/fsps.bin"
> >>>>> CONFIG_CPU_MICROCODE_CBFS_EXTERNAL_BINS=y
> >>>>> CONFIG_CPU_UCODE_BINARIES="3rdparty/blobs/mainboard/$(CONFIG_MAINBOARD_DIR)/cpu_microcode_blob.bin"
> >>>>> CONFIG_RUN_FSP_GOP=y
> >>>>> CONFIG_PAYLOAD_UBOOT=y
> >>>>> CONFIG_UBOOT_MASTER=y
> >>>>>
> >>>>> save as .config, then make olddefconfig.
> >>>>>
> >>>>> CAR NEM (non-evict mode) is default, leave that.
> >>>>>
> >>>>> No reason to select ChromeEC RTC, it's not supported.
> >>>>>
> >>>>> WiFi SAR is only used by ChromeOS, only selectable when 
> >>>>> CONFIG_CHROMEOS=y
> >>>>>
> >>>>> secondary payloads are almost certainly not useful with u-boot as
> >>>>> primary payload.
> >>>>>
> >>>>> I don't get any size mismatch errors when building for CASTA using the
> >>>>> default FMAP. Have you modified your IFD at all?
> >>>>
> >>>> I have not touched it.
> >>>>
> >>>> Did you *actually* run ifdtool validate?  Is your build, with no size 
> >>>> mismatch, recent?
> >>>>
> >>>> Using your config, and following your instructions, I get still the same 
> >>>> result:
> >>>>
> >>>> $ util/ifdtool/ifdtool -t build/coreboot.rom
> >>>> File build/coreboot.rom is 16777216 bytes
> >>>> Peculiar firmware descriptor, assuming Ibex Peak compatibility.
> >>>> Region mismatch between bios and SI_BIOS
> >>>>  Descriptor regio

[coreboot] Re: FsptUpd.h: No such file or directory - compilation terminated - Error 1

[Matt DeVillier]

I'm an idiot and made a stupid math error when I calculated the size
of the SI_BIOS region. 0xF7F000 - 0x1000 is 0xF7E000, not 0xF6F000.

https://review.coreboot.org/c/coreboot/+/55815 fixes it

On Wed, Jun 23, 2021 at 1:48 PM James Feeney  wrote:
>
> On 6/22/21 11:13 PM, Matt DeVillier wrote:
> > On Tue, Jun 22, 2021 at 10:59 PM James Feeney  wrote:
> >>
> >> On 6/22/21 4:32 PM, Matt DeVillier wrote:
> >>> I'm not sure why you enabled so many things not selected in my
> >>> defconfig -- that's your issue.
> >>
> >> Ha!  Quite!  Bit of a learning curve, though...
> >>
> >> Ok, thanks for the clarifications - lots of things I do not need.
> >>
> >>> Use:
> >>>
> >>> CONFIG_VENDOR_GOOGLE=y
> >>> CONFIG_PAYLOAD_CONFIGFILE="../configubootJun14-2"
> >>> # CONFIG_POST_DEVICE is not set
> >>> CONFIG_BOARD_GOOGLE_CASTA=y
> >>> CONFIG_INCLUDE_NHLT_BLOBS=y
> >>> CONFIG_NEED_IFWI=y
> >>> CONFIG_HAVE_IFD_BIN=y
> >>> CONFIG_ADD_FSP_BINARIES=y
> >>> CONFIG_FSP_M_FILE="3rdparty/blobs/mainboard/$(MAINBOARDDIR)/fspm.bin"
> >>> CONFIG_FSP_S_FILE="3rdparty/blobs/mainboard/$(MAINBOARDDIR)/fsps.bin"
> >>> CONFIG_CPU_MICROCODE_CBFS_EXTERNAL_BINS=y
> >>> CONFIG_CPU_UCODE_BINARIES="3rdparty/blobs/mainboard/$(CONFIG_MAINBOARD_DIR)/cpu_microcode_blob.bin"
> >>> CONFIG_RUN_FSP_GOP=y
> >>> CONFIG_PAYLOAD_UBOOT=y
> >>> CONFIG_UBOOT_MASTER=y
> >>>
> >>> save as .config, then make olddefconfig.
> >>>
> >>> CAR NEM (non-evict mode) is default, leave that.
> >>>
> >>> No reason to select ChromeEC RTC, it's not supported.
> >>>
> >>> WiFi SAR is only used by ChromeOS, only selectable when CONFIG_CHROMEOS=y
> >>>
> >>> secondary payloads are almost certainly not useful with u-boot as
> >>> primary payload.
> >>>
> >>> I don't get any size mismatch errors when building for CASTA using the
> >>> default FMAP. Have you modified your IFD at all?
> >>
> >> I have not touched it.
> >>
> >> Did you *actually* run ifdtool validate?  Is your build, with no size 
> >> mismatch, recent?
> >>
> >> Using your config, and following your instructions, I get still the same 
> >> result:
> >>
> >> $ util/ifdtool/ifdtool -t build/coreboot.rom
> >> File build/coreboot.rom is 16777216 bytes
> >> Peculiar firmware descriptor, assuming Ibex Peak compatibility.
> >> Region mismatch between bios and SI_BIOS
> >>  Descriptor region bios:
> >>   offset: 0x1000
> >>   length: 0x00f7e000
> >>  FMAP area SI_BIOS:
> >>   offset: 0x1000
> >>   length: 0x00f6f000
> >>
> >> I see now that I need *not* enable "Validate Intel firmware descriptor", 
> >> and the compile will complete without error.
> >>
> >> But - I still have to wonder about that: "This config enables validating 
> >> the Intel firmware descriptor against the fmap layout."
> >>
> >> Does that not matter?  Is that another "ChromeOS only" thing?
> >
> > This issue has nothing to do with ChromeOS.
> >
> >>
> >> They differ in size by 60kiB.  Hmm - "SI-BIOS" is one of the read-only 
> >> sections given by "cbfstool /build/coreboot.rom layout -w", as is "FMAP".  
> >> "BIOS" is one of the sections given by "ifdtool -d build/coreboot.rom".  
> >> They just happen to have different sizes.  It looks like "FMAP" is 
> >> specifically a coreboot thing?  The "SI" is an abbreviation for what?
> >>
> >> As I understand, the IFD section was simply copied from the recovery file, 
> >> and the FMAP section was generated from scratch, in the coreboot compile.  
> >> Did coreboot make an error in not matching the given IFD?
> >
> > the FMAP isn't generated from scratch, it's the default.fmd file in
> > the google/octopus directory. If you look at that file (and at
> > chromeos.fms), you can see why the layout and sizes are the way they
> > are.
> >
>
> Aha!  Ok, thanks for that.
>
> src/mainboard/google/octopus/chromeos.fmd
>
> # BIOS   --> 4K to 0xf7f000
>
>
> >>
> >> Since the IFD BIOS region is larger in size than the FMAP SI-BIOS region, 
> >> does it matter that th

[coreboot] Re: FsptUpd.h: No such file or directory - compilation terminated - Error 1

[Matt DeVillier]

On Tue, Jun 22, 2021 at 10:59 PM James Feeney  wrote:
>
> On 6/22/21 4:32 PM, Matt DeVillier wrote:
> > I'm not sure why you enabled so many things not selected in my
> > defconfig -- that's your issue.
>
> Ha!  Quite!  Bit of a learning curve, though...
>
> Ok, thanks for the clarifications - lots of things I do not need.
>
> > Use:
> >
> > CONFIG_VENDOR_GOOGLE=y
> > CONFIG_PAYLOAD_CONFIGFILE="../configubootJun14-2"
> > # CONFIG_POST_DEVICE is not set
> > CONFIG_BOARD_GOOGLE_CASTA=y
> > CONFIG_INCLUDE_NHLT_BLOBS=y
> > CONFIG_NEED_IFWI=y
> > CONFIG_HAVE_IFD_BIN=y
> > CONFIG_ADD_FSP_BINARIES=y
> > CONFIG_FSP_M_FILE="3rdparty/blobs/mainboard/$(MAINBOARDDIR)/fspm.bin"
> > CONFIG_FSP_S_FILE="3rdparty/blobs/mainboard/$(MAINBOARDDIR)/fsps.bin"
> > CONFIG_CPU_MICROCODE_CBFS_EXTERNAL_BINS=y
> > CONFIG_CPU_UCODE_BINARIES="3rdparty/blobs/mainboard/$(CONFIG_MAINBOARD_DIR)/cpu_microcode_blob.bin"
> > CONFIG_RUN_FSP_GOP=y
> > CONFIG_PAYLOAD_UBOOT=y
> > CONFIG_UBOOT_MASTER=y
> >
> > save as .config, then make olddefconfig.
> >
> > CAR NEM (non-evict mode) is default, leave that.
> >
> > No reason to select ChromeEC RTC, it's not supported.
> >
> > WiFi SAR is only used by ChromeOS, only selectable when CONFIG_CHROMEOS=y
> >
> > secondary payloads are almost certainly not useful with u-boot as
> > primary payload.
> >
> > I don't get any size mismatch errors when building for CASTA using the
> > default FMAP. Have you modified your IFD at all?
>
> I have not touched it.
>
> Did you *actually* run ifdtool validate?  Is your build, with no size 
> mismatch, recent?
>
> Using your config, and following your instructions, I get still the same 
> result:
>
> $ util/ifdtool/ifdtool -t build/coreboot.rom
> File build/coreboot.rom is 16777216 bytes
> Peculiar firmware descriptor, assuming Ibex Peak compatibility.
> Region mismatch between bios and SI_BIOS
>  Descriptor region bios:
>   offset: 0x1000
>   length: 0x00f7e000
>  FMAP area SI_BIOS:
>   offset: 0x1000
>   length: 0x00f6f000
>
> I see now that I need *not* enable "Validate Intel firmware descriptor", and 
> the compile will complete without error.
>
> But - I still have to wonder about that: "This config enables validating the 
> Intel firmware descriptor against the fmap layout."
>
> Does that not matter?  Is that another "ChromeOS only" thing?

This issue has nothing to do with ChromeOS.

>
> They differ in size by 60kiB.  Hmm - "SI-BIOS" is one of the read-only 
> sections given by "cbfstool /build/coreboot.rom layout -w", as is "FMAP".  
> "BIOS" is one of the sections given by "ifdtool -d build/coreboot.rom".  They 
> just happen to have different sizes.  It looks like "FMAP" is specifically a 
> coreboot thing?  The "SI" is an abbreviation for what?
>
> As I understand, the IFD section was simply copied from the recovery file, 
> and the FMAP section was generated from scratch, in the coreboot compile.  
> Did coreboot make an error in not matching the given IFD?

the FMAP isn't generated from scratch, it's the default.fmd file in
the google/octopus directory. If you look at that file (and at
chromeos.fms), you can see why the layout and sizes are the way they
are.

>
> Since the IFD BIOS region is larger in size than the FMAP SI-BIOS region, 
> does it matter that the sizes are different?  The IFD Intel ME, GbE, and 
> Platform Data regions are all unused.  There is nothing there to "mis-read", 
> because of any potential location mistake - unless something tries to 
> calculate a location "backward", from the end of the IFD BIOS region.  Could 
> the 60kiB size difference represent some kind of "padding"?

I'm curious about the IFD you're using. Dumping the IFD from
bios-casta.ro-11297-83-3.rw-11297-83-3.bin (extracted from the octopus
recovery image), the IFD layout matches that of the default.fmd used
by coreboot.

> By the way, do I need to be concerned with the final note at the end of the 
> compile, "Written area will abut bottom of target region: any unused space 
> will keep its current contents"?  A 16MiB file written onto a 16MiB rom 
> doesn't leave any "unused" space.  Or, is this "unused space" referring to 
> "unused" and "unusable" regions described in the FMAP layout?
>
> I should be able to write this coreboot.rom file directly to the boot rom now?

I would resolve the IFD/FMAP discrepancy first. The IFD from the
firmware images for all the octopus b

[coreboot] Re: FsptUpd.h: No such file or directory - compilation terminated - Error 1

[Matt DeVillier]

>
> Is this a mistake in the Kconfig?  Or, what should be done with this SAR file?
>
> Coreboot does seem to properly include my SAR file, since the coreboot.pre 
> wifi_sar_defaults.hex file exactly matches the SAR file I specified in the 
> WIFI_SAR_CBFS_FILEPATH.
>
>
> Thanks
> James
>
> $ cat defconfig
> CONFIG_ANY_TOOLCHAIN=y
> CONFIG_VENDOR_GOOGLE=y
> CONFIG_MAINBOARD_VENDOR="Octopus"
> CONFIG_MAINBOARD_SMBIOS_MANUFACTURER="Coreboot"
> # CONFIG_POST_IO is not set
> CONFIG_PAYLOAD_CONFIGFILE="../configubootJun14-2"
> # CONFIG_POST_DEVICE is not set
> CONFIG_BOARD_GOOGLE_CASTA=y
> CONFIG_INCLUDE_NHLT_BLOBS=y
> CONFIG_USE_LEGACY_8254_TIMER=y
> CONFIG_NEED_IFWI=y
> CONFIG_HAVE_IFD_BIN=y
> CONFIG_ADD_FSP_BINARIES=y
> CONFIG_FSP_M_FILE="3rdparty/blobs/mainboard/$(MAINBOARDDIR)/fspm.bin"
> CONFIG_FSP_S_FILE="3rdparty/blobs/mainboard/$(MAINBOARDDIR)/fsps.bin"
> CONFIG_CAR_CQOS=y
> # CONFIG_PAVP is not set
> CONFIG_X2APIC_RUNTIME=y
> CONFIG_CPU_MICROCODE_CBFS_EXTERNAL_BINS=y
> CONFIG_CPU_UCODE_BINARIES="3rdparty/blobs/mainboard/$(CONFIG_MAINBOARD_DIR)/cpu_microcode_blob.bin"
> CONFIG_VALIDATE_INTEL_DESCRIPTOR=y
> CONFIG_ME_REGION_ALLOW_CPU_READ_ACCESS=y
> CONFIG_RUN_FSP_GOP=y
> CONFIG_TPM_PPI=y
> CONFIG_USE_SAR=y
> CONFIG_WIFI_SAR_CBFS_FILEPATH="3rdparty/blobs/mainboard/$(MAINBOARDDIR)/wifi_sar-bluebird.hex"
> CONFIG_DEFAULT_CONSOLE_LOGLEVEL_6=y
> CONFIG_PAYLOAD_UBOOT=y
> CONFIG_UBOOT_MASTER=y
> CONFIG_COREINFO_SECONDARY_PAYLOAD=y
> CONFIG_MEMTEST_SECONDARY_PAYLOAD=y
>
> $ util/cbfstool/cbfstool build/coreboot.pre print
> FMAP REGION: COREBOOT
> Name   Offset Type   Size   Comp
> cbfs master header 0x0cbfs header32 none
> fallback/romstage  0x80   stage   59136 none
> cpu_microcode_blob.bin 0xe800 microcode  148480 none
> intel_fit  0x32c40raw80 none
> fallback/ramstage  0x32cc0stage  110054 LZMA (257508 
> decompressed)
> config 0x4db00raw  1184 none
> revision   0x4dfc0raw   722 none
> build_info 0x4e2c0raw   100 none
> fallback/dsdt.aml  0x4e380raw 13347 none
> pt 0x51800raw 20480 none
> pdpt   0x56840raw32 none
> dmic-2ch-48khz-16b.bin 0x56880raw  3048 none
> dmic-4ch-48khz-16b.bin 0x574c0raw  3048 none
> max98357-render-2ch-48khz-24b.bin 0x58100raw   116 none
> dialog-2ch-48khz-24b.bin   0x581c0raw   100 none
> fspm.bin   0x58280fsp417792 none
> vbt.bin0xbe2c0raw  1334 LZMA (5632 
> decompressed)
> wifi_sar_defaults.hex  0xbe840raw   119 none
> (empty)0xbe900null  932 none
> fsps.bin   0xbecc0fsp192512 none
> fallback/postcar   0xedd00stage   20388 none
> img/coreinfo   0xf2d00simple elf  54609 none
> fallback/payload   0x100280   simple elf 249347 none
> img/memtest0x13d0c0   simple elf  47497 none
> (empty)0x148a80   null  3234276 none
> bootblock  0x45e480   bootblock   10288 none
>
>
> On 6/22/21 8:17 AM, Matt DeVillier wrote:
> > FSP-T isn't used for APL/GLK Chromebooks. Sounds like your .config is
> > selecting something it shouldn't. run `make savedefconfig` then post
> > the contents of the defconfig. Possible CONFIG_USE_APOLLOLAKE_FSP_CAR
> > is selected when it shouldn't be.
> >
> > On Mon, Jun 21, 2021 at 9:17 PM James Feeney  wrote:
> >>
> >> $ cat defconfig
> >> ...
> >> CONFIG_ADD_FSP_BINARIES=y
> >> ...
> >>
> >> There is *no* "fspt.bin" file in this chromebook recovery bios file used 
> >> as source.
> >>
> >>
> >> $ make
> >> ...
> >> src/soc/intel/apollolake/fspcar.c:3:10: fatal error: FsptUpd.h: No such 
> >> file or directory
> >>  #include 
> >>   ^~~
> >> compilation terminated.
> >> make: *** [Makefile:379: build/bootblock/soc/intel/apollolake/fspcar.o] 
> >> Error 1
> >>
> >>
> >> What Makefile is that?  There is no such line 379.
> >>
&

[coreboot] Re: FsptUpd.h: No such file or directory - compilation terminated - Error 1

[Matt DeVillier]

FSP-T isn't used for APL/GLK Chromebooks. Sounds like your .config is
selecting something it shouldn't. run `make savedefconfig` then post
the contents of the defconfig. Possible CONFIG_USE_APOLLOLAKE_FSP_CAR
is selected when it shouldn't be.

On Mon, Jun 21, 2021 at 9:17 PM James Feeney  wrote:
>
> $ cat defconfig
> ...
> CONFIG_ADD_FSP_BINARIES=y
> ...
>
> There is *no* "fspt.bin" file in this chromebook recovery bios file used as 
> source.
>
>
> $ make
> ...
> src/soc/intel/apollolake/fspcar.c:3:10: fatal error: FsptUpd.h: No such file 
> or directory
>  #include 
>   ^~~
> compilation terminated.
> make: *** [Makefile:379: build/bootblock/soc/intel/apollolake/fspcar.o] Error 
> 1
>
>
> What Makefile is that?  There is no such line 379.
>
>
> $ find -name FsptUpd.h
> ...
> ./3rdparty/fsp/ApolloLakeFspBinPkg/Include/FsptUpd.h
> ...
>
>
>
> $ less src/soc/intel/alderlake/Kconfig
> ...
> config FSP_HEADER_PATH
> string "Location of FSP headers"
> default "src/vendorcode/intel/fsp/fsp2_0/alderlake/"
>
>
> $ less src/drivers/intel/fsp2_0/Kconfig
> ...
>
> config FSP_T_FILE
> string "Intel FSP-T (temp RAM init) binary path and filename" if 
> !FSP_FULL_FD
> depends on ADD_FSP_BINARIES
> depends on FSP_CAR
> default "\$(obj)/Fsp_T.fd" if FSP_FULL_FD
> help
>   The path and filename of the Intel FSP-T binary for this platform.
>
>
>
>
> $ make nconfig
> ...
> > Generic Drivers
> ...
> (src/vendorcode/intel/fsp/fsp2_0/glk) Location of FSP headers
>
> How did that get there?  Not me...
>
> $ ll src/vendorcode/intel/fsp/fsp2_0/glk
> total 116
> drwxr-x--- 2 james james  4096 Oct 29  2020 .
> drwxr-x--- 9 james james  4096 Jun 14 19:04 ..
> -rw-r- 1 james james 45977 Oct 29  2020 FspmUpd.h
> -rw-r- 1 james james 57332 Oct 29  2020 FspsUpd.h
> -rw-r- 1 james james  1967 Oct 29  2020 FspUpd.h
>
>
> Why is src/soc/intel/apollolake/fspcar.c being built here?  It seems that no 
> fspt.bin file is needed.
>
>
> James
> ___
> coreboot mailing list -- coreboot@coreboot.org
> To unsubscribe send an email to coreboot-le...@coreboot.org
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: ApolloLake/GeminiLake Status?

[Matt DeVillier]

On Sat, Jun 19, 2021 at 9:41 AM James Feeney  wrote:
>
> Hey Matt
>
> You recommend extracting all audio/dsp blobs, which appears straightforward, 
> but then, how can these blobs be referenced in the .config for inclusion in 
> coreboot?
>
> I only see "Include blobs for audio" with "make nconfig", symbol 
> INCLUDE_NHLT_BLOBS.  Enabling this, the coreboot compile ends with "make: *** 
> No rule to make target 
> '3rdparty/blobs/soc/intel/glk/nhlt-blobs/dmic-2ch-48khz-16b.bin', needed by 
> 'build/coreboot.pre'.  Stop."

I extracted these audio files from the recovery image, and placed them
into the hardcoded path referenced by the makefile, as shown above in
the error.

see: src/soc/intel/apollolake/Makefile.inc around ln 151 for the list
of files needed

>
> How did you include the chromeos recovery image audio blobs into coreboot?
>
> Thanks
> James
>
>
> On 6/18/21 9:16 PM, James Feeney wrote:
> > On 6/18/21 8:25 PM, Matt DeVillier wrote:
> >> `cbfstool  layout` will show the regions in the FMAP, use 
> >> `cbfstool  read -r IFWI -f ifwi.bin` to extract.
> >>
> >> I would use the exact same microcode file as the recovery image; coreboot 
> >> isn't guaranteed to include all applicable cpuids, and APL/GLK seem weird 
> >> about updating in the FIT
> >>
> >> FSP/GOP display init requires the vbt to be included/added, it should be 
> >> an option from the menu.
> >>
> >> vbgfx.bin is only used by depthcharge, it's not needed for any other 
> >> payload.
> >>
> >>
> >
> > Ha!  Many thanks Matt.  That is very useful information, every point!  The 
> > process is so simple, given the proper instructions - and seems 
> > insurmountably opaque without them.  Definitely information that would be 
> > useful to find in the wiki!
> >
> > I'll let you know how it works.
> >
> > James
> >
> >
> >> On Fri, Jun 18, 2021, 8:31 PM James Feeney  >> <mailto:ja...@nurealm.net>> wrote:
> >>
> >>
> >> On 6/18/21 11:00 AM, Matt DeVillier wrote:
> >> > hi James,
> >> >
> >> > I've built working upstream coreboot images for both APL and GLK
> >> > Chromebooks (reef and octopus boards respectively).
> >> >
> >> > Starting with a recovery image for the board you're working with,
> >> > you'll need to extract the ifwi.bin, vbt.bin, fspm.bin/fsps.bin (GLK
> >> > only; APL can use 3rdparty fsp repo), CPU microcode, and all 
> >> audio/dsp
> >> > blobs. use cbfstool for this. Then you'll need to set your config to
> >> > use the extracted blobs / place them in the expected locations, set
> >> > display init to FSP/GOP, and set the payload to Tianocore. Here's my
> >> > defconfig for google/ampton (GLK) as an example:
> >> >
> >> > CONFIG_VENDOR_GOOGLE=y
> >> > CONFIG_NO_POST=y
> >> > 
> >> CONFIG_IFD_BIN_PATH="3rdparty/blobs/mainboard/google/ampton/flashdescriptor.bin"
> >> > CONFIG_BOARD_GOOGLE_AMPTON=y
> >> > # CONFIG_CONSOLE_SERIAL is not set
> >> > CONFIG_INCLUDE_NHLT_BLOBS=y
> >> > CONFIG_INTEL_GMA_ADD_VBT=y
> >> > 
> >> CONFIG_INTEL_GMA_VBT_FILE="3rdparty/blobs/mainboard/google/ampton/vbt.bin"
> >> > CONFIG_NEED_IFWI=y
> >> > 
> >> CONFIG_IFWI_FILE_NAME="3rdparty/blobs/mainboard/google/ampton/ifwi.bin"
> >> > CONFIG_HAVE_IFD_BIN=y
> >> > CONFIG_ADD_FSP_BINARIES=y
> >> > CONFIG_FSP_M_FILE="3rdparty/blobs/mainboard/google/ampton/fspm.bin"
> >> > CONFIG_FSP_S_FILE="3rdparty/blobs/mainboard/google/ampton/fsps.bin"
> >> > CONFIG_CPU_MICROCODE_CBFS_EXTERNAL_BINS=y
> >> > 
> >> CONFIG_CPU_UCODE_BINARIES="3rdparty/blobs/soc/intel/glk/cpu_microcode_blob.bin"
> >> > CONFIG_LOCK_MANAGEMENT_ENGINE=y
> >> > CONFIG_PAYLOAD_TIANOCORE=y
> >> >
> >> > APL would be almost the exact same, but without the 3 FSP-related 
> >> lines.
> >> >
> >> > cheers,
> >> > Matt
> >> >
> >>
> >>
> >> Thanks very much for that.  Hmm - some questions:
> >>
> >> My chromebook is the google octopus casta bluebird.  Running "cbfstool 
> >> bios-casta.ro-11297-193-0.r

[coreboot] Re: ApolloLake/GeminiLake Status?

[Matt DeVillier]

`cbfstool  layout` will show the regions in the FMAP, use
`cbfstool  read -r IFWI -f ifwi.bin` to extract.

I would use the exact same microcode file as the recovery image; coreboot
isn't guaranteed to include all applicable cpuids, and APL/GLK seem weird
about updating in the FIT

FSP/GOP display init requires the vbt to be included/added, it should be an
option from the menu.

vbgfx.bin is only used by depthcharge, it's not needed for any other
payload.


On Fri, Jun 18, 2021, 8:31 PM James Feeney  wrote:

>
> On 6/18/21 11:00 AM, Matt DeVillier wrote:
> > hi James,
> >
> > I've built working upstream coreboot images for both APL and GLK
> > Chromebooks (reef and octopus boards respectively).
> >
> > Starting with a recovery image for the board you're working with,
> > you'll need to extract the ifwi.bin, vbt.bin, fspm.bin/fsps.bin (GLK
> > only; APL can use 3rdparty fsp repo), CPU microcode, and all audio/dsp
> > blobs. use cbfstool for this. Then you'll need to set your config to
> > use the extracted blobs / place them in the expected locations, set
> > display init to FSP/GOP, and set the payload to Tianocore. Here's my
> > defconfig for google/ampton (GLK) as an example:
> >
> > CONFIG_VENDOR_GOOGLE=y
> > CONFIG_NO_POST=y
> >
> CONFIG_IFD_BIN_PATH="3rdparty/blobs/mainboard/google/ampton/flashdescriptor.bin"
> > CONFIG_BOARD_GOOGLE_AMPTON=y
> > # CONFIG_CONSOLE_SERIAL is not set
> > CONFIG_INCLUDE_NHLT_BLOBS=y
> > CONFIG_INTEL_GMA_ADD_VBT=y
> >
> CONFIG_INTEL_GMA_VBT_FILE="3rdparty/blobs/mainboard/google/ampton/vbt.bin"
> > CONFIG_NEED_IFWI=y
> > CONFIG_IFWI_FILE_NAME="3rdparty/blobs/mainboard/google/ampton/ifwi.bin"
> > CONFIG_HAVE_IFD_BIN=y
> > CONFIG_ADD_FSP_BINARIES=y
> > CONFIG_FSP_M_FILE="3rdparty/blobs/mainboard/google/ampton/fspm.bin"
> > CONFIG_FSP_S_FILE="3rdparty/blobs/mainboard/google/ampton/fsps.bin"
> > CONFIG_CPU_MICROCODE_CBFS_EXTERNAL_BINS=y
> >
> CONFIG_CPU_UCODE_BINARIES="3rdparty/blobs/soc/intel/glk/cpu_microcode_blob.bin"
> > CONFIG_LOCK_MANAGEMENT_ENGINE=y
> > CONFIG_PAYLOAD_TIANOCORE=y
> >
> > APL would be almost the exact same, but without the 3 FSP-related lines.
> >
> > cheers,
> > Matt
> >
>
>
> Thanks very much for that.  Hmm - some questions:
>
> My chromebook is the google octopus casta bluebird.  Running "cbfstool
> bios-casta.ro-11297-193-0.rw-11297-193-0.bin print" does not show any kind
> of ifwi.bin file.  Running "ifwitool
> bios-casta.ro-11297-193-0.rw-11297-193-0.bin print -d" only gives
> references to the components, those shown with "ifwitool -h", under "NAME
> should be one of:".  That's why I was asking about how to extract an
> ifwi.bin.
>
> Did your Ampton recovery image include a distinct "ifwi.bin" file, by
> using cbfstool?
>
> I'm building u-boot as the payload, instead of Tianocore, but I don't
> expect that that make any difference.
>
> However, "cbfstool build/coreboot.rom print" does show a
> cpu_microcode_blob.bin file, built by coreboot.  I'm guessing that this
> microcode file is as good as the one in the recovery image?
>
> The recovery image also has a vbgfx.bin.  I'm wondering if I should do
> something with this?  "make nconfig" fails to offer any gfx settings,
> though several gfx settings can be seen when manually editing the .config.
>
> So, I'm stuck trying to understand sourcing this ifwi.bin file.  Any
> suggestions?
>
> James
>
>
>
> > On Fri, Jun 18, 2021 at 11:13 AM James Feeney  wrote:
> >>
> >> Back in 2017 there was some brief discussion of how to compile coreboot
> for apollolake, with some uncertainty about the IFWI segment.  Does anyone
> know the current status of coreboot support for apollolake/geminilake?  In
> particular, to replace a Chromebook boot rom?
> >>
> >> The coreboot configuration options are confusing in the sense that the
> intended outcome of particular settings is not explained.  For instance,
> there is coreboot code compiled addressing the Intel FSP, but there are no
> FSP files generated in the resulting coreboot.rom.
> >>
> >> Working from a Chromebook bios upgrade image, it seems that many
> components might simply be copied from there, but then, there seems to be
> no tool to extract the complete IFWI segment from an existing bios image,
> except in pieces that would require reassembly.  Is there some way that an
> existing IFWI segment can be extracted and used in another compiled
> coreboot image?  Or, is there "security" code in the IFWI segment that will
> prevent a compatible working coreboot rom built in this way?
> >>
> >> James
> >> ___
> >> coreboot mailing list -- coreboot@coreboot.org
> >> To unsubscribe send an email to coreboot-le...@coreboot.org
>
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: ApolloLake/GeminiLake Status?

[Matt DeVillier]

hi James,

I've built working upstream coreboot images for both APL and GLK
Chromebooks (reef and octopus boards respectively).

Starting with a recovery image for the board you're working with,
you'll need to extract the ifwi.bin, vbt.bin, fspm.bin/fsps.bin (GLK
only; APL can use 3rdparty fsp repo), CPU microcode, and all audio/dsp
blobs. use cbfstool for this. Then you'll need to set your config to
use the extracted blobs / place them in the expected locations, set
display init to FSP/GOP, and set the payload to Tianocore. Here's my
defconfig for google/ampton (GLK) as an example:

CONFIG_VENDOR_GOOGLE=y
CONFIG_NO_POST=y
CONFIG_IFD_BIN_PATH="3rdparty/blobs/mainboard/google/ampton/flashdescriptor.bin"
CONFIG_BOARD_GOOGLE_AMPTON=y
# CONFIG_CONSOLE_SERIAL is not set
CONFIG_INCLUDE_NHLT_BLOBS=y
CONFIG_INTEL_GMA_ADD_VBT=y
CONFIG_INTEL_GMA_VBT_FILE="3rdparty/blobs/mainboard/google/ampton/vbt.bin"
CONFIG_NEED_IFWI=y
CONFIG_IFWI_FILE_NAME="3rdparty/blobs/mainboard/google/ampton/ifwi.bin"
CONFIG_HAVE_IFD_BIN=y
CONFIG_ADD_FSP_BINARIES=y
CONFIG_FSP_M_FILE="3rdparty/blobs/mainboard/google/ampton/fspm.bin"
CONFIG_FSP_S_FILE="3rdparty/blobs/mainboard/google/ampton/fsps.bin"
CONFIG_CPU_MICROCODE_CBFS_EXTERNAL_BINS=y
CONFIG_CPU_UCODE_BINARIES="3rdparty/blobs/soc/intel/glk/cpu_microcode_blob.bin"
CONFIG_LOCK_MANAGEMENT_ENGINE=y
CONFIG_PAYLOAD_TIANOCORE=y

APL would be almost the exact same, but without the 3 FSP-related lines.

cheers,
Matt

On Fri, Jun 18, 2021 at 11:13 AM James Feeney  wrote:
>
> Back in 2017 there was some brief discussion of how to compile coreboot for 
> apollolake, with some uncertainty about the IFWI segment.  Does anyone know 
> the current status of coreboot support for apollolake/geminilake?  In 
> particular, to replace a Chromebook boot rom?
>
> The coreboot configuration options are confusing in the sense that the 
> intended outcome of particular settings is not explained.  For instance, 
> there is coreboot code compiled addressing the Intel FSP, but there are no 
> FSP files generated in the resulting coreboot.rom.
>
> Working from a Chromebook bios upgrade image, it seems that many components 
> might simply be copied from there, but then, there seems to be no tool to 
> extract the complete IFWI segment from an existing bios image, except in 
> pieces that would require reassembly.  Is there some way that an existing 
> IFWI segment can be extracted and used in another compiled coreboot image?  
> Or, is there "security" code in the IFWI segment that will prevent a 
> compatible working coreboot rom built in this way?
>
> James
> ___
> coreboot mailing list -- coreboot@coreboot.org
> To unsubscribe send an email to coreboot-le...@coreboot.org
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Chrome OS altfw questions (was: Can we get rid of SMMSTORE_IN_CBFS?)

[Matt DeVillier]

On Wed, Apr 14, 2021 at 7:08 PM Julius Werner  wrote:
>
> > The issue is that Tianocore fails to execute (hangs the system) when
> > used as a legacy boot/alternative bootloader entry on 90% of CrOS
> > devices which support the alternative bootloader feature, and since
> > coreboot disables console output via the CPU UART, I don't have a good
> > way to debug the issue (ie, no CCD output). The exact same Tianocore
> > payload works as the primary/only payload with upstream coreboot on
> > these platforms (all GeminiLake, Kabylake, Cometlake and probably
> > other boards). The only boards it works on are some (but not all) AMD
> > Stoneyridge boards (google/kahlee) and Intel Whiskeylake
> > (google/sarien).
>
> Well, if you want to track this down your best bet is probably to
> recompile coreboot with serial output enabled. If you cannot reproduce
> this with upstream, you can build from the respective Chromium OS
> firmware branch for that device. Then you'll have exactly the same
> code we build. (You could also try extracting the depthcharge binary
> from a Chrome OS image and inserting it into an upstream coreboot
> image you built, if you think it's a problem specifically with how
> depthcharge loads the payload. But I think it's more likely to be a
> difference in coreboot.)
>
> I can also just send you Chromium firmware images with serial output
> enabled for specific boards if that helps (we have those readily
> available, we just don't have a system to make them public). Let me
> know which ones you need.

if you have those prebuilt, that would save me quite a bit of effort.
Here's a few I could use:
AMPTON (octopus)
AKEMI (hatch)
ELECTRO (reef)
MORPHIUS (zork)
WYVERN (puff)

TIA :)
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Chrome OS altfw questions (was: Can we get rid of SMMSTORE_IN_CBFS?)

[Matt DeVillier]

The issue is that Tianocore fails to execute (hangs the system) when
used as a legacy boot/alternative bootloader entry on 90% of CrOS
devices which support the alternative bootloader feature, and since
coreboot disables console output via the CPU UART, I don't have a good
way to debug the issue (ie, no CCD output). The exact same Tianocore
payload works as the primary/only payload with upstream coreboot on
these platforms (all GeminiLake, Kabylake, Cometlake and probably
other boards). The only boards it works on are some (but not all) AMD
Stoneyridge boards (google/kahlee) and Intel Whiskeylake
(google/sarien).

I'm not looking for Google to ship or maintain anything, I just want
to be able to continue to provide users a RW_LEGACY update which
allows them to easily boot Linux.

On Wed, Apr 14, 2021 at 5:39 PM Dossym Nurmukhanov  wrote:
>
> I don't have much more to add. We do want to continue supporting the 
> alternative bootloader feature on Chrome OS devices to make it easy for folks 
> to use their own bootloaders/OSes. However, maintaining a set of alternative 
> bootloaders is currently out of our product scope.
>
> Thanks,
> Dossym
>
>
> On Wed, Apr 14, 2021 at 3:12 PM Julius Werner  wrote:
>>
>> > Unrelated -- who can I talk to about fixing the state of launching
>> > something other than u-boot from the Alternative Bootloader Menu?
>> > Tianocore has only ever worked on a handful of devices, and the lack
>> > of console output on release firmware makes it difficult to debug.
>>
>> I can try answering that -- let's fork this off into a new thread. Not
>> exactly sure what your question is, though? Is there some technical
>> problem with the altfw code that doesn't allow you to launch other
>> bootloaders? It should allow you to install and launch anything that
>> can run as a coreboot payload, and on more recent Chromebooks you
>> should be able to install those side-by-side with U-Boot and select on
>> each boot from the menu.
>>
>> If you're asking whether Google will start pre-installing more
>> alternative bootloaders on Chromebooks, unfortunately I don't think
>> there are any plans to do that. We currently see the alternative
>> bootloader feature as an option to allow users to run their own code
>> on Chromebooks, and we really appreciate the work of people like you
>> in developing and maintaining custom builds for that -- but we don't
>> have the bandwidth to maintain alternative bootloaders ourselves for
>> each board. There's just not enough business incentive for Google to
>> invest that effort, basically. Maybe +Dossym can comment on what, if
>> anything, would need to happen for us to reconsider that position, but
>> I don't think there's a high chance (there are just not enough
>> Chromebook users that would care about these compared to the necessary
>> effort).
>>
>> For console output, of course the alternative bootloader should do its
>> own console initialization and after that it shouldn't matter whether
>> coreboot set up a console anymore. If you want to see things that got
>> caught in depthcharge's exception handler before your console
>> initialization succeeded, one hacky workaround that should work is to
>> trigger the error, then soft-reset the machine (e.g. via the
>> Alt+VolUp+R key combination), then boot into normal Chrome OS
>> developer mode and read the last boot's persistent CBMEM console
>> output from /sys/firmware/log. (Of course you can also just recompile
>> coreboot and depthcharge with console output enabled if you prefer.)
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Can we get rid of SMMSTORE_IN_CBFS?

[Matt DeVillier]

On Wed, Apr 14, 2021 at 6:49 AM Julius Werner via coreboot
 wrote:
>
> As I'm trying to port all existing CBFS uses to the new APIs that
> support verification, the CONFIG_SMMSTORE_IN_CBFS option is a bit of a
> problem: It's the only CBFS use case where coreboot is actually trying
> to write back into CBFS, and thus needs access to the raw flash
> offsets of files (which is something I'm trying to stop from leaking
> out of the abstraction).
>
> Does anyone still need this? As far as I know it was just a hack
> invented to backport SMMSTORE onto a Chromebook that couldn't make
> FMAP changes anymore, and we never ended up using it after all.

This is my recollection as well.

Unrelated -- who can I talk to about fixing the state of launching
something other than u-boot from the Alternative Bootloader Menu?
Tianocore has only ever worked on a handful of devices, and the lack
of console output on release firmware makes it difficult to debug.

> Anyone
> still using SMMSTORE today should be putting it in a separate FMAP
> section. Would anyone mind if I just remove the CBFS option?

I've only ever used the FMAP option, so fine by me

> ___
> coreboot mailing list -- coreboot@coreboot.org
> To unsubscribe send an email to coreboot-le...@coreboot.org
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Status of Tianocore EDK2 on Coreboot

[Matt DeVillier]

Tianocore with the COREBOOTPAYLOAD option is my (heavily modified)
fork of the now-deprecated CorebootPayloadPkg package which works on
Intel Core-based platforms Sandybridge and newer. No attempt has been
make to get it working under qemu or other hardware. The UEFIPAYLOAD
option builds upstream edk2 master, which may or may not be functional
on any given day. You likely also need to remove your tianocore subdir
before switching between the two options. Remove the '-q' option from
the makefile if building continues to fail

On Mon, Mar 29, 2021 at 10:40 AM Julian Stecklina
 wrote:
>
> On Mon, 2021-03-29 at 17:45 +0300, Julian Stecklina wrote:
> > I'm currently trying to get Tianocore EDK2 running as a Coreboot payload in 
> > Qemu
> > and meeting with limited success, though. I have a working configuration 
> > for the
> > qemu q35 target. Building it for and running it with the 440fx/piix4 chipset
> > results in the crash below.
>
> Maybe some additional information: I was using
> CONFIG_TIANOCORE_COREBOOTPAYLOAD=y.
>
> With CONFIG_TIANOCORE_UEFIPAYLOAD, I get a build failure. I've opened
> https://ticket.coreboot.org/issues/303 for this.
>
> Julian
>
> ___
> coreboot mailing list -- coreboot@coreboot.org
> To unsubscribe send an email to coreboot-le...@coreboot.org
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: T440P porting and issues

[Matt DeVillier]

On Sat, Feb 27, 2021 at 7:43 AM  wrote:
>
> > what do you mean "coreboot driver"? libgfxinit?
>
> Yes, that's what's being used. The first logo looks full sized and the
> "press enter" message is on the actual bottom of the screen.
> Then tianocore boots and the logo is the same size but tianocore
> interface is just slightly bigger. It's all centered in my screen in a
> 600x600ish square.

the Tianocore UI is centered in the display, it's not supposed to be
full-screen. If the logo is showing at proper/native resolution, then
everything is working as intended.

>
>
> > Why would you do that? You can use upstream Tianocore master as-is by
> > simply selecting the Uefipayload option.
> >
>
> To check for fixes. I thought the 2 options were coreboot_fb and
> uefipayloadpkg both from the mrchromebox repo. Tianocore master has 3k
> more commits than those. I figured out how to try it though and switched
> to upstream/master... same problem just missing the logo, etc. Does it
> run at a fixed size or something without scaling?
>
> I'm only 5 days into this so I can for sure be wrong.

The corebootpayload option use my repo, the uefipayload option uses
upstream master. I have an updated branch which uses UefiPayloadPkg
(based on EDK-stable 08-2020) with all the fixes ported from the older
CorebootPayloadPkg based branch. if you want to try that:
* select UEFIPAYLOAD option
* set branch to: origin/uefipayloadpkg
* select SMMSTORE V2

you should keep using libgfxinit of course
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: T440P porting and issues

[Matt DeVillier]

On Fri, Feb 26, 2021 at 2:49 PM crabstorage--- via coreboot
 wrote:
>
>
> > that's dependent on how you have coreboot set to initialize the
> > screen. Are you using a VBIOS by chance?
>
> I'm using the coreboot driver. It's a UEFI only build.

what do you mean "coreboot driver"? libgfxinit?

Tianocore (at least, in the default package/branch used by coreboot)
simply uses whatever framebuffer coreboot has already set up. It makes
no changes to the video mode.

If it's showing 640x480 or some other VESA mode, it's because that's
what coreboot has set.

>
> I suspect
> https://github.com/MrChromebox/edk2/commit/cd5b08f9aa34a255c3b39c996a0f47609ab00e5e
> but I didn't see it in the coreboot_fb branch.

no, that only applies to some of my other branches which use an
external GOP driver compiled into Tianocore

> Maybe I should get froggy and merge upstream into tianocore.

Why would you do that? You can use upstream Tianocore master as-is by
simply selecting the Uefipayload option.

> ___
> coreboot mailing list -- coreboot@coreboot.org
> To unsubscribe send an email to coreboot-le...@coreboot.org
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: T440P porting and issues

[Matt DeVillier]

On Fri, Feb 26, 2021 at 9:38 AM  wrote:
>
> I've been running coreboot on my T440P and trying to fix it up.
>
> I have already resolved some things here:
> https://github.com/Ph0rk0z/coreboot/pulls
> Will have to figure out how to contribute this back to coreboot after
> testing so it can pass code review.
>
> Other things remain, including:
>
> - software changing of keyboard backlight doesn't work on windows (but I
> fixed it on linux)
> - lenovo hotkey / mic mute services crash windows (bad pool_caller)
> - intel haswell -mini hd audio shows exclamation point, will not start.
> I've read others don't have DP audio working either.
> - there is an unknown ACPI\VEN_BOOT@DEV_ device

that's the coreboot ACPI device, doesn't need a driver

> - card reader doesn't work in windows/linux and crashes windows on warm
> boot
> - plug/unplug ac under bios and windows causes screen to go dark for a
> second
> - occasionally power button light turns off (fixed by suspend)
> - TLP stats for charge mAH are off by a factor of 10.
> - tianocore picks up the windows loader as a boot option but doesn't
> pick up arch linux, old bios enumerated both.

that requires Arch to add a boot menu entry to the UEFI boot manager.
Reinstalling your bootloader will likely do this.

> - tianocore menus/graphics are only what looks like 640x480 and don't
> take up the screen

that's dependent on how you have coreboot set to initialize the
screen. Are you using a VBIOS by chance?

>
>
> I'd like to solve the card reader issue but not sure where to start. It
> appears correctly detected and matches everything on my x250.
> Any hints to what I should look at?
> ___
> coreboot mailing list -- coreboot@coreboot.org
> To unsubscribe send an email to coreboot-le...@coreboot.org
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Debugging Windows 10 BSOD

[Matt DeVillier]

Stoney has the same issue, pretty sure it's related to a memory
address range being incorrectly marked or something similar (based on
the DWORD output of the BSOD), but never bothered to troubleshoot

On Wed, Jan 13, 2021 at 4:21 PM Raul Rangel  wrote:
>
> I'm trying to boot the Windows 10 Installer on a picasso based device using 
> coreboot + tianocore. I keep getting a BSOD after the windows logo shows with 
> the very descriptive stop code `ACPI BIOS ERROR`.
>
> I've enabled bootdebug on the USB stick using the following:
>
> bcdedit /store H:\boot\bcd /bootdebug {bootmgr} on
> bcdedit /store H:\boot\bcd /bootdebug {default} on
> bcdedit /store H:\boot\bcd /debug {debug} on
>
> Here is the BCD:
>
> C:\Windows\system32>bcdedit /store h:\boot\bcd
> Windows Boot Manager
> 
> identifier  {bootmgr}
> description Windows Boot Manager
> locale  en-US
> inherit {globalsettings}
> bootdebug   Yes
> default {default}
> displayorder{default}
> toolsdisplayorder   {memdiag}
> timeout 30
>
> Windows Boot Loader
> ---
> identifier  {default}
> device  
> ramdisk=[boot]\sources\boot.wim,{7619dcc8-fafe-11d9-b411-000476eba25f}
> path\windows\system32\boot\winload.exe
> description Windows Setup
> locale  en-US
> inherit {bootloadersettings}
> bootdebug   Yes
> osdevice
> ramdisk=[boot]\sources\boot.wim,{7619dcc8-fafe-11d9-b411-000476eba25f}
> systemroot  \windows
> bootmenupolicy  Standard
> detecthal   Yes
> winpe   Yes
> debug   Yes
> ems No
>
> C:\Windows\system32>bcdedit /store h:\boot\bcd /dbgsettings
> debugtype   Serial
> debugport   1
> baudrate115200
>
>
> I have also added the SPCR table:
>
> [000h    4]Signature : "SPCR"[Serial Port 
> Console Redirection table]
> [004h 0004   4] Table Length : 0050
> [008h 0008   1] Revision : 02
> [009h 0009   1] Checksum : F1
> [00Ah 0010   6]   Oem ID : "COREv4"
> [010h 0016   8] Oem Table ID : "COREBOOT"
> [018h 0024   4] Oem Revision : 002A
> [01Ch 0028   4]  Asl Compiler ID : "CORE"
> [020h 0032   4]Asl Compiler Revision : 20200925
>
> [024h 0036   1]   Interface Type : 00
> [025h 0037   3] Reserved : 00
>
> [028h 0040  12] Serial Port Register : [Generic Address Structure]
> [028h 0040   1] Space ID : 00 [SystemMemory]
> [029h 0041   1]Bit Width : 20
> [02Ah 0042   1]   Bit Offset : 00
> [02Bh 0043   1] Encoded Access Width : 03 [DWord Access:32]
> [02Ch 0044   8]  Address : FEDC9000
>
> [034h 0052   1]   Interrupt Type : 03
> [035h 0053   1]  PCAT-compatible IRQ : 04
> [036h 0054   4]Interrupt : 0004
> [03Ah 0058   1]Baud Rate : 00
> [03Bh 0059   1]   Parity : 00
> [03Ch 0060   1]Stop Bits : 00
> [03Dh 0061   1] Flow Control : 00
> [03Eh 0062   1]Terminal Type : 00
> [04Ch 0076   1] Reserved : 00
> [040h 0064   2]PCI Device ID : 
> [042h 0066   2]PCI Vendor ID : 
> [044h 0068   1]  PCI Bus : 00
> [045h 0069   1]   PCI Device : 00
> [046h 0070   1] PCI Function : 00
> [047h 0071   4]PCI Flags : 
> [04Bh 0075   1]  PCI Segment : 00
> [04Ch 0076   4] Reserved : 
>
> And the DBG2 table:
>
> [000h    4]Signature : "DBG2"[Debug Port 
> table type 2]
> [004h 0004   4] Table Length : 005C
> [008h 0008   1] Revision : 00
> [009h 0009   1] Checksum : 78
> [00Ah 0010   6]   Oem ID : "COREv4"
> [010h 0016   8] Oem Table ID : "COREBOOT"
> [018h 0024   4] Oem Revision : 
> [01Ch 0028   4]  Asl Compiler ID : "CORE"
> [020h 0032   4]Asl Compiler Revision : 20200925
>
> [024h 0036   4]  Info Offset : 002C
> [028h 0040   4]   Info Count : 0001
>
> [02Ch 0044   1]   

[coreboot] Re: "Fixing" `1 << 31` (technically undefined behavior with known implementation-specific results)

[Matt DeVillier]

`1u << 31` is correct, clear, and easy to read/understand quickly. It
has my vote.

On Thu, Jan 7, 2021 at 3:42 PM Nico Huber  wrote:
>
> Hi coreboot fellows,
>
> another patch that fixes a `1 << 31` to `1UL << 31` [1] reminded me that
> some people objected to such changes. I'm not sure if we ever draw a
> conclusion on the matter.
>
> `1 << 31` is undefined behavior because the `1` can (and thus will) be
> represented as a (signed) `int` which is limited by 2^31-1 for all our
> targets. But we know very well that GCC (and I assume Clang too) do the
> right thing: Produce a value that when casted to an `unsigned int` is
> converted to 2^31.
>
> So, it's wrong but not broken ;) and any suffix to the `1` makes it a
> bit harder to read.
>
> What do you think? Should we allow such changes? Should we normalize
> on any style?
>
> If we want to make it defined behavior, my personal preference would be
> `1u << 31`. Lower case because it's more distinct from the number part,
> and we actually don't need a long (that might even hide actual errors
> if we want a 32-bit limited value).
>
> Cheers,
> Nico
>
> PS. Happy new year btw. :D
>
> [1] https://review.coreboot.org/c/coreboot/+/49076
> ___
> coreboot mailing list -- coreboot@coreboot.org
> To unsubscribe send an email to coreboot-le...@coreboot.org
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: SeaBios getting stuck in boot menu

[Matt DeVillier]

worth a try to deselect/unset SEABIOS_HARDWARE_IRQ in your coreboot .config

On Fri, Dec 25, 2020 at 1:45 AM Anatolii Vorobev <
anatolii.voro...@wayray.com> wrote:

> Dear Coreboot community,
>
> I am developing bios for my custom Apollo Lake SoC E3950 mainboard. I got
> to a point where SeaBios is loaded and awaits to choose a boot option. The
> problem is that its getting stuck while waiting for timeout or keyboard
> press (see log attached). I figured out that it is getting stuck on
> wait_irq() function. In particular, call stack looks like this:
>
>
>
> interactive_bootmenu()
> (/coreboot/payloads/external/SeaBIOS/seabios/src/boot.c)
>
> get_keystroke() (int scan_code = get_keystroke(menutime);)
>
> get_keystroke_full()
>
> yield_toirq()
>
> wait_irq()
>
> __stack_hop_back_wait_irq()
>
>
>
> Why can this happen? Is hardware not initialized properly during Coreboot
> operation or it should be done in SeaBios?
>
> Looks like interrupts from timer and keyboard are not working. I tried
> loading with FILO payload and keyboard was working Ok except keyboard leds
> were not working.
>
>
>
> Best Regards,
>
> Anatolii Vorobev
> ___
> coreboot mailing list -- coreboot@coreboot.org
> To unsubscribe send an email to coreboot-le...@coreboot.org
>
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: I NEED HELP

[Matt DeVillier]

BUDDY (Acer Chromebase 24) does not have functional audio under Windows (or
Linux), as there are no drivers.

You can fix the booting issue by updating the firmware to latest release.
There is a Windows utility to do that listed in the documentation on
https://reddit.com/r/chrultrabook

On Fri, Dec 18, 2020, 8:53 AM Nez Civil via coreboot 
wrote:

>
> *Hi*
>
> * I have an Acer aio device that has a BIOS type COREBOOT version 4.9*
>
> * acer chromebace CA5W1*
>
> * Chrome OS is installed by default, now I have installed the Windows
> operating system from the BIOS, but the sound card driver is not installed,
> and also to enter Windows, you must first enter the BIOS and enter Windows
> from the BIOS*
>
> * I wanted to ask, is there a way to solve the sound card problem?*
>
> * And entered Windows directly without the BIOS*
>
> * Photo of the device specifications and stickers on the back of the
> device are attached. *
> *Thank you for your guidance*
>
> ___
> coreboot mailing list -- coreboot@coreboot.org
> To unsubscribe send an email to coreboot-le...@coreboot.org
>
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Moving from 4.12 to 4.13 breaks boot

[Matt DeVillier]

On Thu, Dec 3, 2020 at 11:55 AM Matt DeVillier 
wrote:

>
>
> On Thu, Dec 3, 2020 at 5:52 AM Andy Pont  wrote:
>
>> Matt wrote…
>>
>> you're building master, or a branch with
>> https://review.coreboot.org/c/coreboot/+/40520 included?
>>
>> I’m running master branch at commit #f79f00991c (from 4 days ago) so yes,
>> it looks as though it has those changes included.
>>
>> -Andy.
>>
>
> I'll try to recheck here on my CML-based Chromebook that has serial
> output, and fix any compilation issues in debug mode
>

Andy, just pushed some updates to my uefipayloadpkg branch, and validated
SMMSTORE v2 working here on a CML-based Chromebook. Debug compilation
succeeds as long as your CBFS is large enough.  Give it a go and LMK
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Moving from 4.12 to 4.13 breaks boot

[Matt DeVillier]

On Thu, Dec 3, 2020 at 5:52 AM Andy Pont  wrote:

> Matt wrote…
>
> you're building master, or a branch with
> https://review.coreboot.org/c/coreboot/+/40520 included?
>
> I’m running master branch at commit #f79f00991c (from 4 days ago) so yes,
> it looks as though it has those changes included.
>
> -Andy.
>

I'll try to recheck here on my CML-based Chromebook that has serial output,
and fix any compilation issues in debug mode
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Moving from 4.12 to 4.13 breaks boot

[Matt DeVillier]

On Wed, Dec 2, 2020 at 9:05 AM Andy Pont  wrote:

> Matt wrote…
>
> That means that the SMMSTORE / NVRAM EFI variable storage is getting
>> corrupted somehow. What platform is this on? I've seen some older platforms
>> which are problematic, especially Braswell, but newer Core platforms seem
>> to work reasonably well. There's also a new SMMSTOREv2 implementation you
>> can try, but requires using the TIanocore UEFIPayload option as well as
>> setting the branch/commit ID to `origin/uefipayloadpkg`
>>
>> I then wrote some bits that aren’t relevant but led Matt to further write…
>
> I've mostly been using SMMSTOREv2 w/UefiPayload+uefipayloadpkg on the CML
> devices I've been working on here (both Google and other boards), with no
> issues. But SMMSTORE (v1) should also work w/CorebootPayload. The
> SMMSTORE region is 64k-aligned and 256k so don't see any issues with the
> FMAP layout.
>
> I have switched Tianocore to use the UEFIPayload option and specified the
> branch as origin/uefipayloadpkg and have enabled SMMSTOREv2.  The unit
> boots to Ubuntu but each time it does it emits the following:
>
> System BootOrder not found. Initialising defaults.
> Creating boot entry “Boot0003” with label “ubuntu” for file
> “EFI\ubuntu\shimx64.efi”
>
> No amount of pressing [ESC] and saving options changes the behaviour.  I’m
> assuming that this is the same issue as before and that the SMMSTORE is
> getting corrupted.
>

you're building master, or a branch with
https://review.coreboot.org/c/coreboot/+/40520 included?


>
> How to go about debugging it as I can’t get a debug build of the Tianocore
> payload in this configuration to build:
>

I probably need to increase the size of the FV for a debug build, I'll take
a look in a bit


>
> build.py...
>  : error 7000: Failed to generate FV
>
> build.py...
>  : error 7000: Failed to execute command
>
> - Failed -
> Build end time: 15:00:59, Dec.02 2020
> Build total time: 00:00:53
>
> mv: cannot stat
> ‘/home/xx/payloads/external/tianocore/tianocore/Build/UefiPayloadPkg*/*/FV/UEFIPAYLOAD.fd':
> No such file or directory
>
> -Andy.
>
>
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Moving from 4.12 to 4.13 breaks boot

[Matt DeVillier]

On Mon, Nov 30, 2020 at 1:57 PM Andy Pont  wrote:

> Matt wrote…
>
> That means that the SMMSTORE / NVRAM EFI variable storage is getting
> corrupted somehow. What platform is this on? I've seen some older platforms
> which are problematic, especially Braswell, but newer Core platforms seem
> to work reasonably well. There's also a new SMMSTOREv2 implementation you
> can try, but requires using the TIanocore UEFIPayload option as well as
> setting the branch/commit ID to `origin/uefipayloadpkg`
>
> This is hardware that is based on Intel Comet Lake.  It is using the flash
> descriptor from the stock BIOS but it could well be the case that I have
> something in the board.fmd or config defined incorrectly.
>

I've mostly been using SMMSTOREv2 w/UefiPayload+uefipayloadpkg on the CML
devices I've been working on here (both Google and other boards), with no
issues. But SMMSTORE (v1) should also work w/CorebootPayload. The
SMMSTORE region is 64k-aligned and 256k so don't see any issues with the
FMAP layout.


>
> The board.fmd file contains:
>
> FLASH 16M {
> BIOS@0x40 0xC0 {
> EC@0x0 0x2
> RW_MRC_CACHE@0x2 0x1
> SMMSTORE@0x3 0x4
> CONSOLE@0x7 0x2
> FMAP@0x9 0x200
> COREBOOT(CBFS)
> }
> }
>
> The key is that the EC firmware has to be the 128KiB at 0x40.  The
> rest of the definitions were cloned from one of the mainboards (I forget
> which).
>
> -Andy.
>
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Moving from 4.12 to 4.13 breaks boot

[Matt DeVillier]

On Mon, Nov 30, 2020 at 11:06 AM Andy Pont  wrote:

> Matt wrote...
>
> try disabling/deselecting SMMSTORE and see if that helps, assuming you are
> using the default CorebootPayloadPkg target
>
> That has fixed it, thanks.
>

That means that the SMMSTORE / NVRAM EFI variable storage is getting
corrupted somehow. What platform is this on? I've seen some older platforms
which are problematic, especially Braswell, but newer Core platforms seem
to work reasonably well. There's also a new SMMSTOREv2 implementation you
can try, but requires using the TIanocore UEFIPayload option as well as
setting the branch/commit ID to `origin/uefipayloadpkg`


>
> -Andy.
>
>
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Moving from 4.12 to 4.13 breaks boot

[Matt DeVillier]

hi Andy,

try disabling/deselecting SMMSTORE and see if that helps, assuming you are
using the default CorebootPayloadPkg target

cheers,
Matt

On Mon, Nov 30, 2020, 8:56 AM Andy Pont  wrote:

> Hello,
>
> I have migrated my work-in-progress project, adding a new mainboard,
> from coreboot v4.12 to v4.13 and now the boot using Tianocore is now
> broken!
>
> Under v4.12 it would boot into Ubuntu but under v4.13 it is just putting
> me at a menu screen with three options: “Default Boot”, “Boot Menu” and
> “Boot Manager”.  If I choose “Boot Menu” it doesn’t list any boot
> devices.
>
> Uisng "Boot Manager” -> “Boot from file” I can navigate into one of the
> NVMe partitions and down the folders efi/boot/bootx64.efi and that will
> boot into Ubuntu via the following messages being shown on the screen:
>
> System BootOrder not found. Initialising defaults.
> Creating boot entry “Boot0004” with label “ubuntu” for file
> “EFI\ubuntu\shimx64.efi”
> Could not create variable: Device Error
>
> When I reboot I just get back to the menu screen.
>
> I’m guessing there is a ne option in v4.13 that needs to be set or there
> is something that has changed v4.12 -> v4.13 but half a day of staring
> at it hasn’t shown it up.  Given the messages are referring to
> shimx64.efi I guess it is something to do with secure boot.
>
> -Andy.
> ___
> coreboot mailing list -- coreboot@coreboot.org
> To unsubscribe send an email to coreboot-le...@coreboot.org
>
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Splashscreens

[Matt DeVillier]

On Thu, Nov 26, 2020 at 12:19 PM Andy Pont  wrote:

> Matt wrote…
>
> for Tianocore, use the latter only. Needs to be a 24bpp windows BMP, no
> larger than the width of the screen and 75% of the height (the image is
> centered 38.2% down from top as per BGRT spec). Gimp can be used too but
> likely will have a pallette shift if a non B image used
>
> Customer sent me a png image of the logo they want to use so have
> manipulated it using ImageMagick to give it a black background and convert
> it to a Windows 3.x format BMP at 24bpp.  Not sure why but the first go
> converting it to a Windows 98/2000 and newer format failed.
>
> Is there any reason not to use both with TianoCore?  Does the
> CONFIG_BOOTSPLASH JPG file not spend long enough on screen to make it
> worthwhile using?
>

exactly this. On most devices, the payload will execute ~600ms after
coreboot starts, and the image probably wouldn't start being displayed
until halfway thru that. So it would be up for ~300ms and likely just
appear as a flicker. Not to mention needing a different sized/formatted
image than used for Tianocore


>  I tried putting a JPG image (400x400 pixels) into Coreboot but
> jpeg_decode() didn’t like it and returned ERR_HEIGHT_MISMATCH.  I haven’t
> looked into the cause (and may not do if it really isn’t needed).
>
> -Andy.
>
>
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Splashscreens

[Matt DeVillier]

for Tianocore, use the latter only. Needs to be a 24bpp windows BMP, no
larger than the width of the screen and 75% of the height (the image is
centered 38.2% down from top as per BGRT spec). Gimp can be used too but
likely will have a pallette shift if a non B image used

On Thu, Nov 26, 2020, 11:27 AM Andy Pont  wrote:

> Hello,
>
> Using the VBT route for graphics initialisation and TianoCore as the
> payload gives two options within .config for splash screen:
>
> CONFIG_BOOTSPLASH:
> This option shows a graphical bootsplash screen. The graphics are loaded
> from the CBFS file bootsplash.jpg.
>
> CONFIG_TIANOCORE_BOOTSPLASH_IMAGE:
> Select this option if you have a bootsplash image that you would like to
> be used. If this option is not selected, the default coreboot logo
> (European Brown Hare) will used.
>
> Do I need to define both?  What are the requirements for the images in
> terms of size, colour depth, etc?
>
> -Andy.
>
> ___
> coreboot mailing list -- coreboot@coreboot.org
> To unsubscribe send an email to coreboot-le...@coreboot.org
>
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Announcing coreboot 4.13

[Matt DeVillier]

awesome, great job getting this out the door Angel. And now that you've
shown competence in doing so, know that you've now inhereted the job for
the foreseeable future ;-)

cheers,
Matt

On Fri, Nov 20, 2020, 10:28 AM Angel Pons  wrote:

> Hi everyone,
>
> I'm pleased to announce that coreboot 4.13 has just been released, with
> release notes as follows:
>
> Since 4.12 there were 4200 new commits by over 234 developers.
> Of these, about 72 contributed to coreboot for the first time.
>
> Thank you to all developers who again helped made coreboot better
> than ever, and a big welcome to our new contributors!
>
> New mainboards
> --
>
> - Acer G43T-AM3
> - AMD Cereme
> - Asus A88XM-E FM2+
> - Biostar TH61-ITX
> - BostenTech GBYT4
> - Clevo L140CU/L141CU
> - Dell OptiPlex 9010
> - Example Min86 (fake board)
> - Google Ambassador
> - Google Asurada
> - Google Berknip
> - Google Boldar
> - Google Boten
> - Google Burnet
> - Google Cerise
> - Google Coachz
> - Google Dalboz
> - Google Dauntless
> - Google Delbin
> - Google Dirinboz
> - Google Dooly
> - Google Drawcia
> - Google Eldrid
> - Google Elemi
> - Google Esche
> - Google Ezkinil
> - Google Faffy
> - Google Fennel
> - Google Genesis
> - Google Hayato
> - Google Lantis
> - Google Lindar
> - Google Madoo
> - Google Magolor
> - Google Metaknight
> - Google Morphius
> - Google Noibat
> - Google Pompom
> - Google Shuboz
> - Google Stern
> - Google Terrador
> - Google Todor
> - Google Trembyle
> - Google Vilboz
> - Google Voema
> - Google Volteer2
> - Google Voxel
> - Google Willow
> - Google Woomax
> - Google Wyvern
> - HP EliteBook 2560p
> - HP EliteBook Folio 9480m
> - HP ProBook 6360b
> - Intel Alderlake-P RVP
> - Kontron COMe-bSL6
> - Lenovo ThinkPad X230s
> - Open Compute Project DeltaLake
> - Prodrive Hermes
> - Purism Librem Mini
> - Purism Librem Mini v2
> - Siemens Chili
> - Supermicro X11SSH-F
> - System76 lemp9
>
> Removed mainboards
> --
>
> - Google Cheza
> - Google DragonEgg
> - Google Ripto
> - Google Sushi
> - Open Compute Project SonoraPass
>
> Significant changes
> ---
>
> ### Native refcode implementation for Bay Trail
>
> Bay Trail no longer needs a refcode binary to function properly. The
> refcode
> was reimplemented as coreboot code, which should be functionally
> equivalent.
> Thus, coreboot only needs to run the MRC.bin to successfully boot Bay
> Trail.
>
> ### Unusual config files to build test more code
>
> There's some new highly-unusual config files, whose only purpose is to
> coerce
> Jenkins into build-testing several disabled-by-default coreboot config
> options.
> This prevents them from silently decaying over time because of build
> failures.
>
> ### Initial support for Intel Trusted eXecution Technology
>
> coreboot now supports enabling Intel TXT. Though it's not
> feature-complete yet,
> the code allows successfully launching tboot, a Measured Launch
> Environment. It
> was tested on Haswell using an Asrock B85M Pro4 mainboard with TPM 2.0
> on LPC.
> Though support for other platforms is still not ready, it is being
> worked on.
> The Haswell MRC.bin needs to be patched so as to enable DPR. Given that
> the MRC
> binary cannot be redistributed, the best long-term solution is to
> replace it.
>
> ### Hidden PCI devices
>
> This new functionality takes advantage of the existing 'hidden' keyword
> in the
> devicetree. Since no existing boards were using the keyword, its usage was
> repurposed to make dealing with some unique PCI devices easier. The
> particular
> case here is Intel's PMC (Power Management Controller). During the FSP-S
> run,
> the PMC device is made hidden, meaning that its config space looks as if
> there
> is no device there (Vendor ID reads as 0x_). However, the device
> does
> have fixed resources, both MMIO and I/O. These were previously recorded in
> different places (MMIO was typically an SA fixed resource, and I/O was
> treated
> as an LPC resource). With this change, when a device in the tree is
> marked as
> 'hidden', it is not probed (`pci_probe_dev()`) but rather assumed to
> exist so
> that its resources can be placed in a more natural location. This also
> adds the
> ability for the device to participate in SSDT generation.
>
> ### Tools for generating SPDs for LP4x memory on TGL and JSL
>
> A set of new tools `gen_spd.go` and `gen_part_id.go` are added to
> automate the
> process of generating SPDs for LP4x memory and assigning hardware strap
> IDs for
> memory parts used on TGL and JSL based boards. The SPD data obtained
> from memory
> part vendors has to be massaged to format it correctly as per JEDEC and
> Intel MRC
> expectations. These tools take a list of memory parts describing their
> physical
> attributes as per their datasheet and convert those attributes into SPD
> files for
> the platforms. More details about the tools are added in
> [README.md](
> 

[coreboot] Re: Memory initialisation error

[Matt DeVillier]

>
src/soc/intel/cannonlake/romstage/fsp_params.c/mainboard_memory_init_params
called

means your board isn't overriding mainboard_memory_init_params() -- so all
the defaults are being used, which I'm not sure will result in a bootable
device. You might want to look at the CML/CFL reference boards, or
system76/lemp9 to see how they are set up and then adapt for your board.
You'll definitely need to load the SPD somehow for a memory-down config,
though I'm not sure how to best obtain it from the stock firmware

On Mon, Nov 16, 2020 at 11:36 AM Andy Pont  wrote:

> Hello,
>
> I have some life out of my Comet Lake based board but the debug output
> ends with
>
> FMAP: area RW_MRC_CACHE found @ 42 (65536 bytes)
> MRC: no data in 'RW_MRC_CACHE'
> PRMRR disabled by config.
> WEAK:
> src/soc/intel/cannonlake/romstage/fsp_params.c/mainboard_memory_init_params
>
> called
> FspMemoryInit returned 0x8007
> FspMemoryInit returned an error!
>
> The board has all of the memory soldered directly down.  The spd.bin
> file in the build directory is 0 bytes.  Is there a way to extract the
> correct SPD information from either the original UEFI firmware or from a
> running Linux system?
>
> -Andy.
> ___
> coreboot mailing list -- coreboot@coreboot.org
> To unsubscribe send an email to coreboot-le...@coreboot.org
>
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Feature request: add payload "Tianocore with SeaBIOS CSM"

[Matt DeVillier]

if it were as simple as building Tianocore with SeaBIOS as the CSM, that
would be the default option offered, but unfortunately it's not. The
neither Tianocore package (the default CorebootPayloadPkg, nor
UefiPayloadPkg) has support for a CSM, like the emulator package (OmvhPkg).
I maintain the default CorebootPayloadPkg, and have tried unsuccessfully to
integrate SeaBIOS as a CSM, but I've also not put a ton of effort into it.
If someone else manages to get it working, I'll gladly take a pull request
on github

regards,
Matt

On Sun, Nov 15, 2020 at 5:27 AM Volkert 
wrote:

> Hi!
>
> This is my first post in this mailing list. Nice to meet you all.
>
> I have a feature request. (I'm not sure if I'm the first to request this,
> so feel free to direct me to any existing discussions about this topic, if
> there is one.)
>
> Would it be possible to add a payload option "Tianocore with SeaBIOS CSM"
> in the config menu? Right now, we have to choose between a Tianocore
> payload and a SeaBIOS payload, or otherwise provide our own manually built
> payload.
>
> It's possible for SeaBIOS to be built as a Compatibility Support Module
> (CSM) FOR UEFI BIOSes, and Tianocore can be built with the resulting CSM.
>
> However, right now people need to first build SeaBIOS as a CSM, then build
> Tianocore with the CSM and then add it as a custom ELF executable payload
> during the "make menuconfig" or "make nconfig" stage of the Coreboot build
> procedure. Those are quite a few extra error-prone manual steps.
>
> It would be really helpful if all these manual steps could be skipped by
> adding this payload option to the existing payload options and doing all
> the required intermediate building for us.
>
> The vendor BIOS that I wish to replace with Coreboot already contains a
> UEFI with a CSM, and I'd like to preserve that functionality once I switch
> to Coreboot. I'm sure I'm not the only one who'd like to have the
> flexibility of being able to boot both modern OSes through UEFI and legacy
> OSes using the CSM.
>
> Since new UEFI hardware will be shipping without CSMs as of 2020, having
> this in Coreboot by default would make Coreboot even more attractive to
> people who'd like to add back such legacy compatibility.
>
> Thanks for considering this!
> ___
> coreboot mailing list -- coreboot@coreboot.org
> To unsubscribe send an email to coreboot-le...@coreboot.org
>
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Flashing coreboot on T440p by just flashing the 4MB chip - how?

[Matt DeVillier]

hi Daniel,

On Tue, Oct 13, 2020 at 4:48 PM Daniel Kulesz via coreboot
 wrote:
>
> Hi Nico,
>
> thank you, this helped me a lot and I got coreboot running by just flashing 
> the top 4MB to the smaller chip. Yet there are a few things I still don't 
> understand:
>
> - as the bios region spans both chips, how does this work when I only flash 
> the bios region into one part of this region? I assumed some of the original 
> bios would be missing, resulting in a brick.

the top of the BIOS region is at the end of the 4MB chip, and that's
where things start from; the part at the end of the 8MB chip doesn't
matter uless your CBFS is > 4MB

> - where is the firmware of the EC controller actually located? It's not 
> mentioned in the ROM layout map.

on your device, it's on a separate chip, not the main SPI flash

> - to my understanding, applying me_cleaner would mean I need to flash the 8MB 
> chip as well. Can this be done internally once I have coreboot running or 
> will the ifd lock in the descriptor (that was left untouched) block this 
> access, so in the end I will need to disassemble the T440p to get physical 
> access to the 8MB chip?

not 'as well,' you would need to flash the 8MB chip only, since that
is where the IFD and ME regions are. By default, the IFD locks the
IFD/ME regions from being written to internally, so you must flash the
IFD (at a minimum) externally first to allow for internal flashing of
the IFD/ME regions.

> - to take advantage of the space gained by applying me_cleaner, the 
> descriptor would need to be reflashed as well, right? Can this be done 
> internally as well?

yes. not initially -- see above.

> - I tried to compile GRUB as payload first, but it didn't fit in the space so 
> I had to go for SeaBIOS. Is there a way to get GRUB working without touching 
> the 8MB chip? I wonder why it doesn't fit into the 4 MB space of the smaller 
> ... is the size of the CBFS region set correctly to the available maximum by 
> default?

the CBFS default is usually much smaller than the BIOS region, I'm
guessing 1-2MB. You can set it to 4MB and then use most other
payloads, and only flash the 4MB chip.

>
> Again, thanks a lot! I will try to submit a merge request for the doc article 
> about the T440p once I get a better understanding of this.
>
> Cheers, Daniel

cheers,
Matt

>
> On Tue, 13 Oct 2020 22:18:23 +0200
> Nico Huber  wrote:
>
> > Hi Daniel,
> >
> > On 13.10.20 21:59, Daniel Kulesz via coreboot wrote:
> > > The build fails because I don't have the other proprietary parts 
> > > (descriptor.bin, me.bin, gbe.bin).
> >
> > you can simply omit them. If you don't tell that you have them (in your
> > config), coreboot won't miss them.
> >
> > > Or is this process meant the way that I should build coreboot without 
> > > these parts and only flash the BIOS region, not touching them?
> >
> > That's it. Generally, for any retrofit coreboot, they are already on
> > the machine, so you never have to extract them. In case of the T440p,
> > the BIOS region spans the end of the 8MiB and the whole 4MiB chip[1].
> > Hence, you never need to deal with descriptor/gbe/me if you only flash
> > the latter.
> >
> > Remember to build coreboot for 12MiB and take the last 4MiB of the
> > resulting `coreboot.rom` and always keep a backup ;)
> >
> > Nico
> >
> > [1] https://doc.coreboot.org/_images/flashlayout_Ivy_Bridge.svg
> ___
> coreboot mailing list -- coreboot@coreboot.org
> To unsubscribe send an email to coreboot-le...@coreboot.org
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: [RFC] Proposal to move all FSP 1.x binaries to "legacy" branch

[Matt DeVillier]

On Thu, Sep 3, 2020 at 8:29 PM Desimone, Nathaniel L
 wrote:
>
> Hi Everyone,
>
> Given that the newest coreboot releases have not supported the FSP 1.x 
> specification for years now

support for FSP 1.0 was dropped, but FSP 1.1 is still used by Braswell
and supported in coreboot master

> seems that the 1.x FSP binaries at https://github.com/intel/FSP have become 
> increasingly limited in their usefulness. For this reason, I would like to 
> move those older binaries off master branch and create a new “legacy” branch 
> to store them. I'll be sure to mention the legacy branch in the readme.md 
> file in master. Any concerns with this change?

the biggest issue would be that even if coreboot did entirely drop
support for FSP 1.x in master, there would still be older
tags/branches from which boards using FSP 1.x could be built, and
moving those FSP binaries out of the master branch would break
building of those boards without changes to the older coreboot
branches to handle that, which would become quite tricky if one then
needs to support pulling FSP from multiple branches

>
> Thanks,
> Nate
>
> ___
> coreboot mailing list -- coreboot@coreboot.org
> To unsubscribe send an email to coreboot-le...@coreboot.org
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Proper way to obtain mrc.bin for thinkpad t440p?

[Matt DeVillier]

there is no "proper" way because there is no mrc.bin for the t440p.
mrc.bin is the ram init blob used in pre-FSP Chromebooks. The t440p
has to leverage this, because there is no native raminit option for
the Haswell platform, unlike the older Sandy/Ivybridge platform. So
mrc.bin must be extracted from a firmware image for a Haswell
Chromebook -- it doesn't matter which one. It should be 190.2kb. Use
coreboot master and don't screw with any config variables you don't
understand, and you should be fine :)

good luck!

On Thu, Aug 20, 2020 at 7:13 PM yk via coreboot  wrote:
>
> To anyone who has corebooted a t440p:
>
> I followed the instructions here
> https://doc.coreboot.org/northbridge/intel/haswell/mrc.bin.html to
> obtain an mrc.bin for the t440p, but it seems like these instructions
> are generalized and are meant for chromebooks, and not thinkpads. I
> gave it a try anyways and my t440p beeps and flashes LED's (as
> configured in .config, to do so on fatal error). Months of searching,
> and I can't find any documentation or archived emails from this
> mailing list for obtaining an mrc.bin specifically for the t440p.
>
> There exists this tutorial https://0xcb.dev/lenovo-t440p-coreboot/ but
> it tells me to use a forked version of coreboot which seems really
> fishy. I browsed the commits from that fork and I couldn't find anything
> that "automates obtaining mrc.bin" as it promises.
>
> What is the proper way to obtain the mrc.bin and configure for t440p?
>
> CONFIG_DCACHE_RAM_MRC_VAR_SIZE=0x3 <-- also what should this value
> be if the mrc.bin is 186K?
> ___
> coreboot mailing list -- coreboot@coreboot.org
> To unsubscribe send an email to coreboot-le...@coreboot.org
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Query regarding CoreBoot

[Matt DeVillier]

One would use coreboot + Tianocore + OpenCore. Whether a particular
board has the required hardware support, or whether coreboot provides
the firmware structures MacOS requires is another story (and yes, I
know part of that is what OpenCore works around).

FWIW I know of a few users with Acer c720 and Dell 13 7310 Chromebooks
running MacOS on my current coreboot 4.12/Tianocore-based firmware
using OpenCore

On Mon, Jun 8, 2020 at 10:31 AM Evgeny Zinoviev via coreboot
 wrote:
>
> coreboot doesn't boot the OS, it performs hardware initialization and passes 
> control to a payload (SeaBIOS, GRUB, Tianocore, etc. - these are payloads). 
> So you would have to use something like clover anyway.
>
> On 6/8/20 6:22 PM, lol wrote:
>
> Hi, I wanted to ask if coreboot is capable of booting macOS. There are 
> bootloaders like clover and opencore that does the job but does coreboot do 
> this thing with more efficiency?
>
> ___
> coreboot mailing list -- coreboot@coreboot.org
> To unsubscribe send an email to coreboot-le...@coreboot.org
>
> ___
> coreboot mailing list -- coreboot@coreboot.org
> To unsubscribe send an email to coreboot-le...@coreboot.org
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: CBFS pointer problem with SeaBios and Apollo Lake platform

[Matt DeVillier]

On Fri, Apr 24, 2020 at 4:59 AM Wolfgang Kamp - datakamp 
wrote:

> Hello Matt,
>
>
>
> Thank you for your response. I see that SeaBIOS still can’t handle the
> FMAP structure.
>
> The pointer depends on the FMAP layout and this is different to chromium
> devices.
>
> For the UP squared board I did not find any other solution than to set
> CONFIG_CBFS_LOCATION=0xFFFC and
>

this is for the upsquared board? looking at the fmap, I'm not sure how you
calculated that CBFS location


> to patch the 16M coreboot.rom image at address 0x00EBEFFE with 0x44.
>
> Then SeaBIOS will find the CBFS to load the APL VGA BIOS ROM.
>

what does patching 0x00EBEFFE with 0x44 do exactly?


>
>
>
>
> Kind regards,
>
> Wolfgang
>
> *Von:* Matt DeVillier [mailto:matt.devill...@gmail.com]
> *Gesendet:* Donnerstag, 23. April 2020 17:35
> *An:* Wolfgang Kamp - datakamp 
> *Cc:* coreboot@coreboot.org
> *Betreff:* [coreboot] Re: CBFS pointer problem with SeaBios and Apollo
> Lake platform
>
>
>
> Apollolake should work with:
>
> CONFIG_CBFS_LOCATION=0xfffb1000
>
> # CONFIG_HARDWARE_IRQ is not set
>
>
>
> That's what I use for SeaBIOS as a legacy boot payload on ChromeOS
> devices, but the CBFS address will be the same if using upstream coreboot
>
>
>
> regards,
> Matt
>
>
>
> On Thu, Apr 23, 2020 at 3:24 AM Wolfgang Kamp - datakamp <
> wmk...@datakamp.de> wrote:
>
> Hello,
>
>
>
> Am I correct that the problem still exists that SeaBios can’t find the
> CBFS in apl platform?
>
>
>
> Kind regards,
>
> Wolfgang Kamp
>
> ___
> coreboot mailing list -- coreboot@coreboot.org
> To unsubscribe send an email to coreboot-le...@coreboot.org
>
>
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: CBFS pointer problem with SeaBios and Apollo Lake platform

[Matt DeVillier]

Apollolake should work with:

CONFIG_CBFS_LOCATION=0xfffb1000
# CONFIG_HARDWARE_IRQ is not set

That's what I use for SeaBIOS as a legacy boot payload on ChromeOS devices,
but the CBFS address will be the same if using upstream coreboot

regards,
Matt

On Thu, Apr 23, 2020 at 3:24 AM Wolfgang Kamp - datakamp 
wrote:

> Hello,
>
>
>
> Am I correct that the problem still exists that SeaBios can’t find the
> CBFS in apl platform?
>
>
>
> Kind regards,
>
> Wolfgang Kamp
> ___
> coreboot mailing list -- coreboot@coreboot.org
> To unsubscribe send an email to coreboot-le...@coreboot.org
>
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Some problems with graphic display when using coreboot + seabios.

[Matt DeVillier]

On Sat, Mar 14, 2020, 11:02 PM Dalao  wrote:

> > SeaBIOS is a legacy BIOS implementation, so no it can't boot UEFI boot
> media. Likewise, Tianocore is a pure UEFI implementation, and doesn't boot
> legacy boot media / legacy installed OSes. There should be a way to use
> SeaBIOS as a CSM for Tianocore, but currently it's not working / not
> implemented (I tried briefly awhile back but didn't have any luck).
>
> I tried to follow the steps to build tianocore for SeaBIOS
> https://www.coreboot.org/TianoCore But I get these errors. It says it
> can't found nmake.exe... Is this should be build on Windows? How to setup
> the environment?
>

The Tianocore package which ran on top of SeaBIOS, DuetPkg, was remove long
ago, so that's not a viable approach (and it was buggy AF anyway). You'd
need to build SeaBIOS as a CSM, package it with Tianocore, and add the
appropriate hooks. Then debug from there


> [dalao@pc tianocore2018]$ git clone --branch UDK2018
> https://github.com/tianocore/edk2
> Cloning into 'edk2'...
> remote: Enumerating objects: 66, done.
> remote: Counting objects: 100% (66/66), done.
> remote: Compressing objects: 100% (43/43), done.
> remote: Total 342725 (delta 35), reused 31 (delta 23), pack-reused 342659
> Receiving objects: 100% (342725/342725), 286.48 MiB | 436.00 KiB/s, done.
> Resolving deltas: 100% (247240/247240), done.
> Updating files: 100% (15636/15636), done.
> [dalao@pc tianocore2018]$ cd edk2/
> [dalao@pc edk2]$ cd BaseTools
> [dalao@pc BaseTools]$ export EDK_TOOLS_PATH=$(pwd)
> [dalao@pc BaseTools]$ cd ../
> [dalao@pc edk2]$ . ./edksetup.sh BaseTools
> WORKSPACE:
> /home/dalao/T440pCorebooting/tianocoreAsSeabiosPayload/tianocore2018/edk2
> EDK_TOOLS_PATH:
> /home/dalao/T440pCorebooting/tianocoreAsSeabiosPayload/tianocore2018/edk2/BaseTools
> CONF_PATH:
> /home/dalao/T440pCorebooting/tianocoreAsSeabiosPayload/tianocore2018/edk2/Conf
> Copying $EDK_TOOLS_PATH/Conf/build_rule.template
>  to
> /home/dalao/T440pCorebooting/tianocoreAsSeabiosPayload/tianocore2018/edk2/Conf/build_rule.txt
> Copying $EDK_TOOLS_PATH/Conf/tools_def.template
>  to
> /home/dalao/T440pCorebooting/tianocoreAsSeabiosPayload/tianocore2018/edk2/Conf/tools_def.txt
> Copying $EDK_TOOLS_PATH/Conf/target.template
>  to
> /home/dalao/T440pCorebooting/tianocoreAsSeabiosPayload/tianocore2018/edk2/Conf/target.txt
> [dalao@pc edk2]$ build -p DuetPkg/DuetPkgIa32.dsc
> Build environment: Linux-5.4.22-1-MANJARO-x86_64-with-glibc2.2.5
> Build start time: 11:48:18, Mar.15 2020
>
> WORKSPACE=
> /home/dalao/T440pCorebooting/tianocoreAsSeabiosPayload/tianocore2018/edk2
> ECP_SOURCE   =
> /home/dalao/T440pCorebooting/tianocoreAsSeabiosPayload/tianocore2018/edk2/EdkCompatibilityPkg
> EDK_SOURCE   =
> /home/dalao/T440pCorebooting/tianocoreAsSeabiosPayload/tianocore2018/edk2/EdkCompatibilityPkg
> EFI_SOURCE   =
> /home/dalao/T440pCorebooting/tianocoreAsSeabiosPayload/tianocore2018/edk2/EdkCompatibilityPkg
> EDK_TOOLS_PATH   =
> /home/dalao/T440pCorebooting/tianocoreAsSeabiosPayload/tianocore2018/edk2/BaseTools
> CONF_PATH=
> /home/dalao/T440pCorebooting/tianocoreAsSeabiosPayload/tianocore2018/edk2/Conf
> POSTBUILD=
> /home/dalao/T440pCorebooting/tianocoreAsSeabiosPayload/tianocore2018/edk2/DuetPkg/PostBuild.bat
> -p DuetPkg/DuetPkgIa32.dsc -b DEBUG -a IA32 -t MYTOOLS
> --conf=/home/dalao/T440pCorebooting/tianocoreAsSeabiosPayload/tianocore2018/edk2/Conf
> all
>
>
> Architecture(s)  = IA32
> Build target = DEBUG
> Toolchain= MYTOOLS
>
> Active Platform  =
> /home/dalao/T440pCorebooting/tianocoreAsSeabiosPayload/tianocore2018/edk2/DuetPkg/DuetPkgIa32.dsc
> Flash Image Definition   =
> /home/dalao/T440pCorebooting/tianocoreAsSeabiosPayload/tianocore2018/edk2/DuetPkg/DuetPkg.fdf
>
> Processing meta-data . done!
> Building ...
> /home/dalao/T440pCorebooting/tianocoreAsSeabiosPayload/tianocore2018/edk2/MdePkg/Library/BasePcdLibNull/BasePcdLibNull.inf
> [IA32]
> Building ...
> /home/dalao/T440pCorebooting/tianocoreAsSeabiosPayload/tianocore2018/edk2/MdePkg/Library/BaseDebugLibNull/BaseDebugLibNull.inf
> [IA32]
> Building ...
> /home/dalao/T440pCorebooting/tianocoreAsSeabiosPayload/tianocore2018/edk2/MdePkg/Library/BaseMemoryLib/BaseMemoryLib.inf
> [IA32]
> /bin/sh: Vcbinnmake.exe: command not found
>
>
> build.py...
> : error 7000: Failed to execute command
> Vc\bin\nmake.exe /nologo tbuild
> [/home/dalao/T440pCorebooting/tianocoreAsSeabiosPayload/tianocore2018/edk2/Build/DuetPkgIA32/DEBUG_MYTOOLS/IA32/MdePkg/Library/BasePcdLibNull/BasePcdLibNull]
>
>
> build.py...
> : error 7000: Failed to execute command
> Vc\bin\nmake.exe /nologo tbuild
> [/home/dalao/T440pCorebooting/tianocoreAsSeabiosPayload/tianocore2018/edk2/Build/DuetPkgIA32/DEBUG_MYTOOLS/IA32/MdePkg/Library/BaseDebugLibNull/BaseDebugLibNull]
>
>
> build.py...
> : error 7000: Failed to execute command
> Vc\bin\nmake.exe /nologo tbuild
> 

[coreboot] Re: Some problems with graphic display when using coreboot + seabios.

[Matt DeVillier]

On Sat, Mar 14, 2020 at 8:33 PM Dalao via coreboot
 wrote:
>
>
> I have just corebooted T440p. Then I noticed some graphic display problems...
>
> Firstly I "Use libgfxinit" with "Legacy VGA text mode", insert a usb disk 
> with archlinux's latest install image iso. I can see a text mode of 
> archlinux's start screen.
>
> https://imgur.com/0QqQgJn
>
> But when I hit enter, it shows some log till "Triggering uevents" and then 
> there is no display...
>
> https://imgur.com/CHI9jeE
>
> Then I tried "Use libgfxinit" with "Linear "high-resolution" framebuffer". I 
> can see the graphic mode of archlinux's start screen, but again after I hit 
> enter and see some logs, there is no display... Also, the display is not 
> ideal, just at the top left corner not full screen.
>
> https://imgur.com/dvYLERu
>
> Also, under this setting, the nvramcui's display becomes bad.
>
> https://imgur.com/7YG0kOX
>

unfortunately, many legacy bootloaders seem to assume a full array of
VESA video modes will be available, and fail less than gracefully when
that's not the case. With libgfxinit there is no ability to change
video modes -- all that's available is either the native panel
resolution (high resolution framebuffer) or VGA text mode.

> Next I included pci8086,0416.rom vbios and tried "Run VGA Option ROMs" with 
> "Legacy VGA text mode". This time, I can't see the archlinux start screen as 
> shown above, there is no display at the beginning. But I can hit the enter 
> blindly. Then after a while I can see archlinux is booting and the first line 
> I can see is "Probing EDD (edd=off to disable)...ok" the archlinux starts ok.
>
> Lastly I also tried "Run VGA Option ROMs" with "Set framebuffer graphics 
> resolution" with the default "framebuffer graphics resolution (1024x768 
> 16.8M-color (8:8:8))" (although my T440p's resolution is 1920x1080). Also the 
> Framebuffer mode is changed to "VESA framebuffer". I still can't see 
> archlinux's start screen...
>
>
> How to make everything work like the vendor BIOS? i.e., I can see both the 
> archlinux's start screen and it's booting.
>

add the VGA BIOS. set the PCI IDs correctly. Set coreboot display init
to none, and let SeaBIOS run the VBIOS.

> How to fix the nvramcui under "high-resolution" framebuffer"?

will work properly with above settings

> Also, as for now it appears seabios can't boot UEFI media. Tianocore by 
> default can't boot Linux/Windows installed by legacy method (installed when 
> using seabios). my goal is to add UEFI support through tianocore as seabios 
> payload (or through tianocore's CSM compatibility support module? ). So that 
> it can boot both UEFI installed Windows or legacy installed Windows like the 
> vendor bios can do. How to achieve this?
>

SeaBIOS is a legacy BIOS implementation, so no it can't boot UEFI boot
media. Likewise, Tianocore is a pure UEFI implementation, and doesn't
boot legacy boot media / legacy installed OSes. There should be a way
to use SeaBIOS as a CSM for Tianocore, but currently it's not working
/ not implemented (I tried briefly awhile back but didn't have any
luck).

Personally, given that it's 2020, I'd not bother with legacy-installed
OSes (or SeaBIOS) outside of use with emulation or if a special use
case demands it. Esp given that it's easy enough to migrate Windows
from legacy to UEFI.

>
> ___
> coreboot mailing list -- coreboot@coreboot.org
> To unsubscribe send an email to coreboot-le...@coreboot.org
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Installing Core Boot on a Lenovo X230 with a script.

[Matt DeVillier]

On Fri, Feb 21, 2020 at 12:25 PM Nico Huber  wrote:
>
> On 21.02.20 19:16, Matt DeVillier wrote:
> > The x230 requires exploiting a vulnerability in an older UEFI version
> > in order to be flashed without external hardware (and even so, is
> > limited to flashing the 4MB BIOS region only; if you want to disable
> > the ME and use more space for the BIOS region, hardware flashing is
> > mandatory). See: https://github.com/n4ru/1vyrain/
>
> Actually, 7MiB BIOS region. And there is a guide for the procedure
> upstream now [1]. It's not easy and nothing one could/should do with
> a script, though.

looks like the 4MB limitation is an 1vyrain thing then, I just scanned
the link :)

>
> Nico
>
> [1] https://doc.coreboot.org/mainboard/lenovo/ivb_internal_flashing.html
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Installing Core Boot on a Lenovo X230 with a script.

[Matt DeVillier]

Chromebooks are flashable from a live system because their firmware
doesn't software lock the BIOS region as part of the boot process,
like all properly implemented UEFI firmware should; instead they a
combination of a hardware (jumper/screw/CR50) and software (SPI flash
chip registers) locks which provide security as well as the ability to
be modified by the physical owner of the device.

The x230 requires exploiting a vulnerability in an older UEFI version
in order to be flashed without external hardware (and even so, is
limited to flashing the 4MB BIOS region only; if you want to disable
the ME and use more space for the BIOS region, hardware flashing is
mandatory). See: https://github.com/n4ru/1vyrain/

On Fri, Feb 21, 2020 at 11:45 AM pk  wrote:
>
> Mr Chromebox uses a script to install Core Boot onto Chrome Book without 
> opening the laptop, or attaching a PROM; (CH341a, Ponoma 5250 Test Clip, F to 
> F Breadboard Jumper Cables.)
>
> Is using a Script without using hardware PROM, and so on, like Mr. Chromebox 
> does with a Chrome Book?
>
> Thanks for what you are doing. and for your replies.
>
> ___
> coreboot mailing list -- coreboot@coreboot.org
> To unsubscribe send an email to coreboot-le...@coreboot.org
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Discussing Controversial Upstreaming

[Matt DeVillier]

On Mon, Jan 27, 2020 at 3:57 PM Patrick Georgi via coreboot <
coreboot@coreboot.org> wrote:

> Hi Marshall,
>
> thanks for that cohesive report and insight into your development process
> and the trade-offs involved.
>
> Am Mo., 27. Jan. 2020 um 21:12 Uhr schrieb Marshall Dawson <
> marshalldawson...@gmail.com>:
>
>> Instead, please give me the opportunity to review any of your changes
>> that touch the picasso directory. If I have any concerns of building, I can
>> test and run it locally, recommend solutions, etc.  We can expect a few
>> problems to slip through that process, which I will immediately discover
>> prior to repushing my subsequent work. I will fix it, and allow you to
>> review that work. I am also committed to converting anything resembling a
>> fork to amd/common where it makes sense, and when the development
>> priorities allow.  The instant that mb/amd/mandolin lands, it will no
>> longer be work-in-progress and it will undoubtedly build successfully.
>>
> Should we add stub mainboards for new chipsets that build the code as a
> way to make sure nobody else inadvertently breaks things (at least not too
> bad)?
> While it's reassuring to know that you intend to keep track of these
> things and sort them out, that would help other developers do changes with
> more confidence that they won't leave a huge mess in a hard-to-test area of
> the tree.
>

having a src/mainboard/stub/ for **all** SoC might not be a bad idea,
especially if it were to select less common/non-default options that other
in-tree boards don't select by default, to ensure full coverage of all SoC
options.


>
> Ironically, I could have commonized the SMBus feature several times over
>> within the time we’ve had this discussion.  I feel this is an important
>> topic, however, so thank you for indulging me. Although I still won’t
>> reprioritize this work ahead of what I promised to my stakeholders, I
>> believe the time discussing this was valuable.
>>
> I'm quite sure that you won't forget all the little places that you intend
> to clean-up down the road. Would it help to document these somewhere, e.g.
> as issues on ticket.coreboot.org? Both for helping you keep track of
> things and to state publicly what you've postponed (so you don't have to
> argue every time somebody else gets the same idea that there's something
> that could be deduplicated).
>

for a WIP SoC, seems like comments in the code/header files indicating WIP
status or need to revisit would be a consistent, visible reminder that the
code isn't "finalized"


>
>
> Patrick
> --
> Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
> Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft:
> Hamburg
> Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
> ___
> coreboot mailing list -- coreboot@coreboot.org
> To unsubscribe send an email to coreboot-le...@coreboot.org
>
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: SuzyQable - ChromeOS Debug Cable

[Matt DeVillier]

On Sat, Jan 18, 2020 at 12:46 AM Mike Banon  wrote:

> Is that something like a cable with two built-in FT232H chips ? (to
> function as a USB dongle)
>

no, the CCD debug functionality is in the Google security chip (CR50) which
detects the special debug cable (https://www.sparkfun.com/products/14746 --
schematics linked) on a specific port and then enables the features
according to the CCD state (open/locked)
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: SuzyQable - ChromeOS Debug Cable

[Matt DeVillier]

sorry, what exactly is your question?  I have one of these cables, works
great for flashing/debugging Chromebooks via CCD

the updated Chromium CCD docs can be found at:
https://chromium.googlesource.com/chromiumos/platform/ec/+/master/docs/case_closed_debugging_cr50.md

On Fri, Jan 17, 2020 at 11:33 AM Gregg Levine 
wrote:

> Hello!
> Does the thing at https://www.sparkfun.com/products/14746 create a
> response with regards to anyone?
>
> On their documents tab they present the now wrong link where to find
> more information about how the cable works. And of course they also
> link to those devices that might be interested in working with it.
>
> Call me curious, but I'm interested in seeing how many of us recognize
> the unique nature of it.
> -
> Gregg C Levine gregg.drw...@gmail.com
> "This signature fought the Time Wars, time and again."
> ___
> coreboot mailing list -- coreboot@coreboot.org
> To unsubscribe send an email to coreboot-le...@coreboot.org
>
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: libgxfinit + latest master gives "static noise" bootscreen (Windows)

[Matt DeVillier]

no issues here with libgfxinit + Windows with google/eve on upstream master
(tested other KBL/AML devices too, no issues)

If it boots to Windows recovery, then libgfxinit is fine. If you see the
spinning dots and then the display becomes corrupted, then it's due to the
Windows/Intel display driver. Make sure the VBT is included and correct.

also, what version of Windows?

On Sun, Dec 29, 2019 at 4:54 PM Rafael Send 
wrote:

> Hi,
> 1) Yes, I've been using my old builds until today; they work for the most
> part (I was originally trying to solve some other remaining issues, but
> then found that I could not build a working version anymore. Hence this
> thread)
> 2) No, I've been using 1440 x 900 the entire time
> 3) Will check. However, I just bricked my machine with a failed erase; so
> I'll have to wait until next week to swap the BIOS chip and then pick this
> up.
>
> Are there any other coreboot build configurations that could cause these
> kinds of issues? It's entirely possible that I set something before I'm no
> longer doing, but I'm not sure what to be looking for there.
>
> Also, does the Windows recovery environment use a different graphics stack
> / setup from the actual installation? As mentioned before, I can get into
> the former just fine, but not the latter without seeing the static.
>
> Cheers,
> R
>
> On Sun, Dec 29, 2019 at 6:31 AM Nico Huber  wrote:
>
>> On 29.12.19 10:32, Rafael Send wrote:
>> > - I'm running linear frame buffer, but not at native resolution. If I
>> do,
>> > the boot menu text gets too small since this is a 13" 2k screen.
>> > - Payload is Tianocore
>> > - Windows is installed in UEFI (these last two have been the same
>> > configuration as always)
>>
>> hmmm, three thoughts:
>>
>> o have you re-tested your old builds to rule out changes in Windows?
>> o did you change the framebuffer resolution? IIRC, Windows is picky
>>about the width of the framebuffer (try a multiple of 16).
>> o if neither the Windows installation nor the resolution are to
>>blame, I'd check for changes in Tianocore.
>>
>> >
>> > I didn't know the commit hash was embedded in the binary, I'll take a
>> look
>> > and see if I can reproduce a working build.
>> >
>> > I do know that my display needed a patch to work correctly before this
>> > update , but I'm
>> unclear if
>> > THAT's what caused Windows to not work correctly (i.e whether the patch
>> > worked better or not). I guess if I start with the commit I originally
>> used
>> > I can play around with cherry-picking that commit vs the previous
>> patch).
>>
>> That's unlikely to be related. The only thing Windows gets in touch with
>> is the framebuffer configuration, which is merely the resolution, stride
>> and a pointer into gfx memory. It doesn't care how the hardware was set
>> up to get there.
>>
>> Nico
>>
>> >
>> > R
>> >
>> > On Sat, Dec 28, 2019 at 5:00 AM Nico Huber  wrote:
>> >
>> >> Hi Rafael,
>> >>
>> >> On 26.12.19 21:43, Rafael Send wrote:
>> >>> For the past month or two (I'm not actually sure WHEN it stopped
>> >> working) I
>> >>> haven't been able to successfully boot (any) Windows installations
>> using
>> >>> libgfxinit.
>> >>
>> >> libgfxinit just sets up a framebuffer, all the software compatibility
>> >> depends on how the framebuffer info is communicated (coreboot payload
>> >> mostly). Please tell us
>> >>
>> >> o do you run a textmode or linear (native resolution) framebuffer?
>> >> o is your Windows in BIOS or EFI mode? (these are completely different
>> >> cases wrt. the framebuffer)
>> >> o if you use SeaBIOS, please also attach your .config and the output
>> >> of `build/cbfstool build/coreboot.rom print`. There are many, many
>> >> variables with SeaBIOS with too many possible combinations.
>> >>
>> >>>
>> >>> Mid-October I had created some builds that worked, but I'm not sure
>> they
>> >>> were using master or something else at that point (only kept the
>> binaries
>> >>> unfortunately).
>> >>
>> >> coreboot binaries contain the commit hash and a defconfig they were
>> >> built with. You can compare that to your current built.
>> >>
>> >> Nico
>> >>
>> >
>>
>> ___
> coreboot mailing list -- coreboot@coreboot.org
> To unsubscribe send an email to coreboot-le...@coreboot.org
>
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Keyboard not working in core boot

[Matt DeVillier]

the keyboard I've been using for testing doesn't have any LEDs or other
indicators, so can't say

-M

On Sat, Dec 28, 2019 at 4:44 AM Kuppa Omkar  wrote:

> Hello Matt,
> Thank you for the reply. I just unset CONFIG_MALLOC_UPPERMEMORY. Then
> keyboard worked for me.
> Just one more clarification. The capslock/numlock LEDs doesn't work. Did
> you observe the same behaviour?
>
> Regards,
> Omkar
> ------
> *From:* Matt DeVillier 
> *Sent:* Friday, December 27, 2019 12:42 AM
> *To:* Kuppa Omkar 
> *Cc:* coreboot@coreboot.org 
> *Subject:* Re: [coreboot] Keyboard not working in core boot
>
> Broadwell-DE platform requires SeaBIOS config to have
> '# CONFIG_MALLOC_UPPERMEMORY is not set' so be sure that is unset in yours.
> I've also heard that disabling CONFIG_PMTIMER is necessary but haven't
> tested that myself.  On the 3 Broadwell-DE boards I tested, USB was only
> functional in SeaBIOS with CONFIG_MALLOC_UPPERMEMORY unset, with MRC cache
> disabled, and with the FSP debug level set to 3. Any of those conditions
> not met resulted in non-functional USB under SeaBIOS. YMMV.
>
> On Thu, Dec 26, 2019 at 4:37 AM Kuppa Omkar  wrote:
>
> Hello everyone,
> I'm trying to boot camelback mountain with coreboot image. I selected the
> seabios as primary payload. I attached USB keyboard.
> In the boot log, I'm able to see "USB is initialised",  "1 device found on
> USB port". So I think USB is initialised properly.
> But when I press escape key continuously while booting, the boot menu is
> not displayed at all. Even on pressing num lock, the num lock led doesn't
> glow. It looks like keyboard is not even powered on.
> Please let me know how to resolve this issue.
> Thanks in advance,
> Omkar
> L Technology Services Ltd
>
> www.LTTS.com
> <https://ind01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.LTTS.com=02%7C01%7Ckuppa.omkar%40ltts.com%7C70db16cd43944d820d0208d78a3788bd%7C311b33788e8a4b5ea33fe80a3d8ba60a%7C0%7C0%7C637129843435583260=h8EeOD%2BDLwBeXxehnAY2LsI8fFurwllKzyC8eQShPlc%3D=0>
>
> L Technology Services Limited (LTTS) is committed to safeguard your data
> privacy. For more information to view our commitment towards data privacy
> under GDPR, please visit the privacy policy on our website www.Ltts.com
> <https://ind01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.Ltts.com=02%7C01%7Ckuppa.omkar%40ltts.com%7C70db16cd43944d820d0208d78a3788bd%7C311b33788e8a4b5ea33fe80a3d8ba60a%7C0%7C0%7C637129843435583260=CqYi6fuvaQivkIOqAV0SgTczVAYmtDrhn7SvYQHmB0M%3D=0>.
> This Email may contain confidential or privileged information for the
> intended recipient (s). If you are not the intended recipient, please do
> not use or disseminate the information, notify the sender and delete it
> from your system.
> ___
> coreboot mailing list -- coreboot@coreboot.org
> To unsubscribe send an email to coreboot-le...@coreboot.org
>
> *L Technology Services Ltd*
>
> www.LTTS.com
>
> L Technology Services Limited (LTTS) is committed to safeguard your data
> privacy. For more information to view our commitment towards data privacy
> under GDPR, please visit the privacy policy on our website www.Ltts.com.
> This Email may contain confidential or privileged information for the
> intended recipient (s). If you are not the intended recipient, please do
> not use or disseminate the information, notify the sender and delete it
> from your system.
>
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Keyboard not working in core boot

[Matt DeVillier]

Broadwell-DE platform requires SeaBIOS config to have
'# CONFIG_MALLOC_UPPERMEMORY is not set' so be sure that is unset in yours.
I've also heard that disabling CONFIG_PMTIMER is necessary but haven't
tested that myself.  On the 3 Broadwell-DE boards I tested, USB was only
functional in SeaBIOS with CONFIG_MALLOC_UPPERMEMORY unset, with MRC cache
disabled, and with the FSP debug level set to 3. Any of those conditions
not met resulted in non-functional USB under SeaBIOS. YMMV.

On Thu, Dec 26, 2019 at 4:37 AM Kuppa Omkar  wrote:

> Hello everyone,
> I'm trying to boot camelback mountain with coreboot image. I selected the
> seabios as primary payload. I attached USB keyboard.
> In the boot log, I'm able to see "USB is initialised",  "1 device found on
> USB port". So I think USB is initialised properly.
> But when I press escape key continuously while booting, the boot menu is
> not displayed at all. Even on pressing num lock, the num lock led doesn't
> glow. It looks like keyboard is not even powered on.
> Please let me know how to resolve this issue.
> Thanks in advance,
> Omkar
> L Technology Services Ltd
>
> www.LTTS.com
>
> L Technology Services Limited (LTTS) is committed to safeguard your data
> privacy. For more information to view our commitment towards data privacy
> under GDPR, please visit the privacy policy on our website www.Ltts.com.
> This Email may contain confidential or privileged information for the
> intended recipient (s). If you are not the intended recipient, please do
> not use or disseminate the information, notify the sender and delete it
> from your system.
> ___
> coreboot mailing list -- coreboot@coreboot.org
> To unsubscribe send an email to coreboot-le...@coreboot.org
>
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: chromebook acer r11 cb5132t

[Matt DeVillier]

no. the stock firmware on most ChromeOS devices, especially older ones,
isn't Windows compatible. The R11 (CYAN - all ChromeOS device support is
done by board name, not make/model) is capable of running Windows when my
coreboot/Tianocore UEFI firmware is used, but CYAN lacks the custom drivers
needed for functional audio and touchscreen.

See the stickied top post at https://www.reddit.com/r/chrultrabook for the
authoritative info on running Windows on ChromeOS devices.

On Sat, Dec 14, 2019, 1:02 PM mattias jonsson 
wrote:

> will anny windows boot on acer r11 cb132t with seabios?
>
> Den 14 december 2019 19:58:23 skrev Matt DeVillier <
> matt.devill...@gmail.com>:
>
>> please resubmit your question in plain text format, nobody can read what
>> you sent
>>
> ___
> coreboot mailing list -- coreboot@coreboot.org
> To unsubscribe send an email to coreboot-le...@coreboot.org
>
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Tianocore: Long time to boot / Menu.

[Matt DeVillier]

are you able to tell what's reading/writing the EFI variables? what
are the few lines right before the loop starts?

On Fri, Dec 6, 2019 at 10:23 AM Jose Trujillo via coreboot
 wrote:
>
> Dear Matt/All:
>
> I enabled Tianocore debug in coreboot and the serial debug dump showed me 
> Tianocore was trying to open a ATA / ATAPI device and was getting stuck 
> there, so, i disabled a still driverless "ATA" device devicetree until I 
> attach some driver.
>
> After flashing this change, the first boot/reboot will go without delay 
> (normal fast tianocore boot) but after the second boot/reboot the serial dump 
> shows the following long and repeated loop of the following:
>
> Added variable: 0x0, val size: 0
> Found variable: key size: 0x0, val size: 0
> Added variable: 0x0, val size: 0
> Found variable: key size: 0x0, val size: 0
> Added variable: 0x0, val size: 0
> Found variable: key size: 0x0, val size: 0
> Added variable: 0x0, val size: 0
> Found variable: key size: 0x0, val size: 0
> Added variable: 0x0, val size: 0
> Found variable: key size: 0x0, val size: 0
> Added variable: 0x0, val size: 0
> Found variable: key size: 0x0, val size: 0
>
> Several minutes later boots normal.
> If someone here knows how to fix it or suspect which could be the reason 
> please let me know.
> I will ask for help in the EDK2 mail list too.
>
> Thank you,
> Jose Trujillo.
>
>
> > are you getting serial output via it from coreboot? If not, enabling
> > Tianocore debug output is just going to make that boot time longer.
> >
> > I'd recommend disabling all serial output and seeing what your boot
> > time is then. If normal, then you know it's the culprit and can start
> > debugging the coreboot side of things
> >
> ___
> coreboot mailing list -- coreboot@coreboot.org
> To unsubscribe send an email to coreboot-le...@coreboot.org
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org