December 2020 - coreboot - mail.coreboot.org

How to add & invoke driver correctly?
by Rafael Send Dec. 10, 2020

Dec. 10, 2020

Hi, I'm investigating adding a custom driver for a device on my system. I'm not a programmer by any means, so please pardon any silly questions... I'd like to learn more about how to properly add custom drivers, and how they are called from devicetrees. First, if there is a resource for this, could you point me to it, please? In my case, I need to read & write from specific PCIe registers, so I'm assuming I can use "pci_write_config" from pci_ops for that. However, I'm unclear on how to invoke a new driver. Looking at some examples & guidance from the IRC channel, I've been told I can add a chip.h, which I can call from a devicetree using the "chip path/to/driver" line. Specifically, what is the syntax & correct usage of the chip keyword? It looks like it's generally arranged under other devices, but I'm unclear on where I would put it. My device connects to a specific PCIe root port, so would it be placed under that specific root port's enable line, similar to this? *device pci 1f.0 on chip ec/51nb/npce985la0dx device pnp 0c09.0 on end .........* Further, it looks to me like arguments are passed to drivers using the "register" keyword. If my driver takes no arguments, is it sufficient to just place the "chip path/to/driver" ? Thanks, Rafael

1 0

Re: Apollo Lake cannot load coreboot
by Anatolii Vorobev Dec. 8, 2020

Dec. 8, 2020

Hi Wolfgang, If I read memory at address 0xFF00 0000-0xFFFE 0000 after SPI is initialized by bootblock_soc_early_init() then I will get only 0xFF bytes. So there is no mapped SPI image there – it is empty. But I should see at least IFD at 0xFF00 0000-0xFF00 1000, am I right? The mainboard I’m debugging is not UP Squared, the schematics are just a bit resembling (as far as I see, because UP2 design files are disclosed). That’s why there are some hardware differences that lead to problems above. Is it GPIO settings or bootstraps? What would you suggest me to check first? Best Regards, Anatolii Vorobev From: Wolfgang Kamp - datakamp <wmkamp(a)datakamp.de> Sent: Tuesday, December 1, 2020 5:33 PM To: Anatolii Vorobev <anatolii.vorobev(a)wayray.com> Cc: gerrit(a)coreboot.org Subject: AW: [coreboot] Re: Apollo Lake cannot load coreboot Hi Anatolii, In this early stage there is no RAM initialized. The SPI Flash is memory mapped starting at 0xFF00 0000 if the FLASH size is 16M, which is on UP Squared default. On address 0xFF30 0000 (0x300000 relative to FLASH start address) starts FMAP. You will find the header –FMAP—on this position. With an in circuit programmer like DEDIPROG 100 you can check this on UP Squared board. Kind regards, Wolfgan Von: Anatolii Vorobev [mailto:anatolii.vorobev@wayray.com] Gesendet: Dienstag, 1. Dezember 2020 12:44 An: Maxim Polyakov <max.senia.poliak(a)gmail.com<mailto:max.senia.poliak@gmail.com>> Cc: coreboot(a)coreboot.org<mailto:coreboot@coreboot.org> Betreff: [coreboot] Re: Apollo Lake cannot load coreboot Hi, Maxim. Sure, I’ve attached .config file. Here is cbfstool output: ./build/cbfstool build/coreboot.rom print FMAP REGION: COREBOOT Name Offset Type Size Comp cbfs master header 0x0 cbfs header 32 none fallback/romstage 0x80 stage 48164 none cpu_microcode_blob.bin 0xbd00 microcode 48128 none fallback/ramstage 0x17980 stage 106068 none vgaroms/seavgabios.bin 0x31840 raw 28160 none config 0x386c0 raw 283 none revision 0x38840 raw 681 none fallback/dsdt.aml 0x38b40 raw 6338 none fspm.bin 0x3a480 fsp 364544 none vbt.bin 0x934c0 raw 1299 LZMA (6154 decompressed) payload_revision 0x93a40 raw 235 none (empty) 0x93b80 null 1048 none fsps.bin 0x93fc0 fsp 176128 none fallback/postcar 0xbf000 stage 22064 none fallback/payload 0xc4680 simple elf 69275 none payload_config 0xd5580 raw 1760 none (empty) 0xd5cc0 null 11137752 none bootblock 0xb74fc0 bootblock 32768 none Best Regards, Anatolii Vorobev From: Maxim Polyakov <max.senia.poliak(a)gmail.com<mailto:max.senia.poliak@gmail.com>> Sent: Tuesday, December 1, 2020 2:05 PM To: Anatolii Vorobev <anatolii.vorobev(a)wayray.com<mailto:anatolii.vorobev@wayray.com>> Cc: coreboot(a)coreboot.org<mailto:coreboot@coreboot.org> Subject: Re: [coreboot] Apollo Lake cannot load coreboot Hi! Could you please send your .config ? The following command will help you find out which sections have been added to the image: (coreboot dir)$ ./build/cbfstool build/coreboot.rom print Please send the output // Regards, // Max вт, 1 дек. 2020 г. в 13:13, Anatolii Vorobev <anatolii.vorobev(a)wayray.com<mailto:anatolii.vorobev@wayray.com>>: Dear community, I’m trying to bring up custom motherboard with Apollo Lake e3950 SoC. The first thing I’ve tried is flashed UP Squared-based BIOS compiled using this instructions: https://doc.coreboot.org/mainboard/up/squared/index.html After I run the motherboard it showed this uart0 output: coreboot-4.12-4087-g6aaf7db719-dirty Tue Nov 17 09:50:24 UTC 2020 bootblock starting (log level: 7)... No FMAP found at 300000 offset. No FMAP found at 300000 offset. POST: 0xe0 Couldn't load romstage. After some time spent trying to figure out the reason of such problem I found out that bootblock cannot load FMAP into RAM. I printed out some parts of ram where romstage and FMAP should be and there where only 0xff values. Looks like bootblock can’t map SPI flash data to RAM although flash image has romstage and FMAP regions. The strange thing is that bootblock is loaded ok but any further load (FMAP) fails. Any ideas what can be the cause of this and how can I debug this thing? PS I tried flashing another BIOS (from AMI) and it passes CAR stage, FSP stage, it even successfully initializes/trains DDR and so on. But coreboot BIOS somehow fails on the very early stages. Best Regards, Anatolii Vorobev _______________________________________________ coreboot mailing list -- coreboot(a)coreboot.org<mailto:coreboot@coreboot.org> To unsubscribe send an email to coreboot-leave(a)coreboot.org<mailto:coreboot-leave@coreboot.org>

2 4

Re: Master currently broken on Thinkpad X230 when using option table
by Tom Englund Dec. 7, 2020

Dec. 7, 2020

im hitting the same issue on my x230, however i do have a ft232h and fetched some logs of booting with the bad commit, http://ix.io/2GJ0 , are some CBFS ERROR: CBFS mcache overflow! , at the bottom of it.

1 0

New Defects reported by Coverity Scan for coreboot
by scan-admin＠coverity.com Dec. 4, 2020

Dec. 4, 2020

Hi, Please find the latest report on new defect(s) introduced to coreboot found with Coverity Scan. 1 new defect(s) introduced to coreboot found with Coverity Scan. New defect(s) Reported-by: Coverity Scan Showing 1 of 1 defect(s) ** CID 1419483: Memory - corruptions (OVERRUN) /src/vendorcode/eltan/security/verified_boot/vboot_check.c: 85 in verified_boot_check_manifest() ________________________________________________________________________________________________________ *** CID 1419483: Memory - corruptions (OVERRUN) /src/vendorcode/eltan/security/verified_boot/vboot_check.c: 85 in verified_boot_check_manifest() 79 pre->body_signature.data_size = CONFIG_VENDORCODE_ELTAN_OEM_MANIFEST_ITEMS * 80 DIGEST_SIZE; 81 pre->body_signature.sig_offset = sizeof(struct vb2_signature) + 82 pre->body_signature.data_size; 83 pre->body_signature.sig_size = size - pre->body_signature.data_size; 84 sd->workbuf_used += size; >>> CID 1419483: Memory - corruptions (OVERRUN) >>> Overrunning struct type vb2_signature of 24 bytes by passing it to a function which accesses it at byte offset 663 using argument "size" (which evaluates to 640). [Note: The source code implementation of the function has been overridden by a builtin model.] 85 memcpy((void *)((void *)&pre->body_signature + (long)sizeof(struct vb2_signature)), 86 (uint8_t *)CONFIG_VENDORCODE_ELTAN_OEM_MANIFEST_LOC, size); 87 88 89 if (vb2api_verify_kernel_data(ctx, (void *)CONFIG_VENDORCODE_ELTAN_OEM_MANIFEST_LOC, 90 pre->body_signature.data_size)) ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…

1 0

Open Source Firmware and Bootloader devroom CFP
by Michał Żygowski Dec. 4, 2020

Dec. 4, 2020

Hi, The Open Source Firmware, BMC and Bootloader devroom will take place on Sunday, 7th February 2021 at FOSDEM, virtual. Call for Participation ---------------------- We are opening the call for participation to our devroom, with the deadline for talk proposals set to Sunday, 20th December 2020 23:59:59 UTC. Devroom Scope ------------- The devroom will focus on various topics related to the open source firmware, BMC and bootloaders including security issues. It will help to get together all interested people in one place, present and discuss current developments and issues haunting the community. Additionally, it will foster awareness among attendees about pre-OS topics. Possible topics: GRUB, TrustedGRUB, iPXE, TrenchBoot, coreboot, LinuxBoot, SeaBIOS, UEFI, OVMF, TianoCore, hostboot, IPMI, OpenBMC, u-bmc, TPM, attestation, security of firmware, BMC, bootloaders and related topics and technologies. Ideal submissions are actionable and opinionated. Submissions may be in the form of 25 or 45 minutes talks, panel sessions or round-table discussions. Dates ----- Submission Deadline: 20-Dec-2020 @ 23:59:59 UTC Acceptance Notification: 31-Dec-2020 Final Schedule Posted: 31-Dec-2020 Recording and uploading presentations: 04-Jan-2021 - 16-Jan-2021 Processing, reviewing, fixing videos: 17-Jan-2021 - 31-Jan-2021 How to submit -------------- Visit https://penta.fosdem.org/submission/FOSDEM21 1) If you do not have an account, create one here 2) Click "Create Event" 3) Enter your presentation details 4) Be sure to select the Open Source Firmware, BMC and Bootloader devroom track! 5) Submit What to include --------------- - The title of your submission - A 1-paragraph abstract - A longer description including the benefit of your talk to your target audience, including a definition of your target audience - Approximate length/type of submission (talk, BoF, ...) - Links to related websites/blogs/talk material (if any) Administrative Notes -------------------- Since the FOSDEM21 is going virtual, the talks will be prerecorded. We will be streaming the recordings and performing live Q&A of the Open Source Firmware, BMC and Bootloader devroom. Presenting at FOSDEM implies permission to record your session and distribute the recording afterwards. All videos will be made available under the standard FOSDEM content license (CC-BY). If you have any questions, feel free to contact the devroom organizers: Daniel Kiper (daniel.kiper at oracle.com) and Michał Żygowski (michal.zygowski at 3mdeb.com) Daniel & Michał

1 0

Moving from 4.12 to 4.13 breaks boot
by Andy Pont Dec. 3, 2020

Dec. 3, 2020

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.

2 10

GSOC 2021
by Omar Mohamed Dec. 3, 2020

Dec. 3, 2020

Hello, Hope this email finds you well I'm a junior computer engineering student interested in embedded system and embedded linux and want to contribute to coreboot. Does coreboot participating in GSOC 2021? And how can I start contributing before GSOC ? Thank you

1 0

FYI: CBFS metadata caching landed, let me know if something breaks
by Julius Werner Dec. 3, 2020

Dec. 3, 2020

I just landed a somewhat large-ish feature that enables CBFS metadata caching across most boards (this will avoid reloading CBFS file headers from flash on every file lookup and ultimately increase boot speed): https://review.coreboot.org/c/coreboot/+/38424 I wrote and tested it best as I could, but with the pandemic my access to different test platforms is limited. If anyone sees their platform break starting with this patch, please let me know, and if you need a quick fix just add `select NO_CBFS_MCACHE` to the respective board/platform Kconfig (this effectively disables the feature but without having to revert the whole patch and potential dependencies back out).

1 0

Apollo Lake cannot load coreboot
by Anatolii Vorobev Dec. 2, 2020

Dec. 2, 2020

Dear community, I'm trying to bring up custom motherboard with Apollo Lake e3950 SoC. The first thing I've tried is flashed UP Squared-based BIOS compiled using this instructions: https://doc.coreboot.org/mainboard/up/squared/index.html After I run the motherboard it showed this uart0 output: coreboot-4.12-4087-g6aaf7db719-dirty Tue Nov 17 09:50:24 UTC 2020 bootblock starting (log level: 7)... No FMAP found at 300000 offset. No FMAP found at 300000 offset. POST: 0xe0 Couldn't load romstage. After some time spent trying to figure out the reason of such problem I found out that bootblock cannot load FMAP into RAM. I printed out some parts of ram where romstage and FMAP should be and there where only 0xff values. Looks like bootblock can't map SPI flash data to RAM although flash image has romstage and FMAP regions. The strange thing is that bootblock is loaded ok but any further load (FMAP) fails. Any ideas what can be the cause of this and how can I debug this thing? PS I tried flashing another BIOS (from AMI) and it passes CAR stage, FSP stage, it even successfully initializes/trains DDR and so on. But coreboot BIOS somehow fails on the very early stages. Best Regards, Anatolii Vorobev

3 4

Please could you review the XMP / custom RAM timings patches for AMD ?
by Mike Banon Dec. 1, 2020

Dec. 1, 2020

Dear friends, These patches are of a critical importance - they help to increase the performance of AMD boards up to 20%. However, despite their small size and simplicity, they are waiting for your review for more than 6 months already. :( And it's sad to see the "unofficial patches" list of csb_patcher.sh growing. Please, could you take a look? https://review.coreboot.org/c/coreboot/+/40488 https://review.coreboot.org/c/coreboot/+/40489 Best regards, Mike Banon

1 1