Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Latest SKL, GRUB and Linux #45

Merged
merged 7 commits into from
Nov 15, 2024
Merged

Latest SKL, GRUB and Linux #45

merged 7 commits into from
Nov 15, 2024

Conversation

SergiiDmytruk
Copy link
Contributor

Xen is removed until #44 is clarified.

@SergiiDmytruk SergiiDmytruk mentioned this pull request Oct 29, 2024
Closed
@krystian-hebel krystian-hebel mentioned this pull request Oct 30, 2024
Closed
@SergiiDmytruk SergiiDmytruk force-pushed the amd branch 2 times, most recently from ef4d990 to f567255 Compare November 3, 2024 23:26
@SergiiDmytruk SergiiDmytruk changed the base branch from master to images-fixes November 3, 2024 23:26
Base automatically changed from images-fixes to master November 6, 2024 18:49
@SergiiDmytruk
scripts/tb.sh: fix deploying linux-tb
4f78c9f 
Add `-L` flag to make the deployment work instead of skipping over the
source symbolic link.

Signed-off-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
@macpijan
Copy link
Collaborator

macpijan commented Nov 13, 2024 •
edited
Loading

It's probably not updated after force-pushing linux branch ?

WARNING: linux-tb-6.11.0-rc7-r0 do_fetch: Failed to fetch URL git://github.com/TrenchBoot/linux.git;protocol=https;branch=linux-sl-amd-refresh;name=machine;, attempting MIRRORS if available
ERROR: linux-tb-6.11.0-rc7-r0 do_fetch: Fetcher failure: Unable to find revision bd46a2617f584046eac7b1d9c7842dc0aff013fd in branch linux-sl-amd-refresh even from upstream
ERROR: linux-tb-6.11.0-rc7-r0 do_fetch: Bitbake Fetcher Error: FetchError('Unable to fetch URL from any source.', 'git://github.com/TrenchBoot/linux.git;protocol=https;branch=linux-sl-amd-refresh;name=machine;')
ERROR: Logfile of failure stored in: /build/tmp/work/genericx86_64-tb-linux/linux-tb/6.11.0-rc7/temp/log.do_fetch.476
ERROR: Task (/build/../repo/recipes-kernel/linux/linux-tb_6.11.bb:do_fetch) failed with exit code '1'

@SergiiDmytruk
Copy link
Contributor Author

It's probably not updated after force-pushing linux branch ?

That branch was removed after the PR was merged. Updated that commit, improved commit messages and bumped Xen as well. SKL from master won't work with that Linux though.

@SergiiDmytruk
linux: update to latest (6.6 -> 6.11)
614b4b0 
Switch to patches targeting 6.11 version (not just a rebase, includes
incompatible changes done during upstream review).

Signed-off-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
@SergiiDmytruk
grub: update to latest (2.06 -> 2.12)
58b99e2 
Not simply a rebase, the changes are incompatible with older versions of
TrenchBoot Linux and SKL.

Bash completion seems to get installed now.

Also work around a workaround in poky:

Tarballs of 2.12 are missing an automatically created file, so poky
creates it not taking into account that this breaks out-of-tree builds:
Make finds the file as "extra_deps.lst" in the source tree for its
dependency checking through VPATH, but shell commands run in the build
tree don't check the source tree and just fail.

Signed-off-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
@SergiiDmytruk
packagegroup-tb: add kexec
33b9e52 
This is to allow testing that kexec doesn't produce unexpected effects
with DRTM.

Example usage:

    kexec -l /boot/bzImage --reuse-cmdline && kexec -e

Signed-off-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
@SergiiDmytruk
skl: update to latest (v0.4.0 -> master)
c5700ab 
This includes changes which align it against latest GRUB and Linux.

Signed-off-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
@SergiiDmytruk
scripts/tb.sh: use $KAS_YAML "constant" in more places
37c5713 
Signed-off-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
@SergiiDmytruk SergiiDmytruk force-pushed the amd branch 2 times, most recently from 0dec086 to a0c8eea Compare November 13, 2024 18:21
@SergiiDmytruk
Copy link
Contributor Author

pre-commit.ci autofix

@SergiiDmytruk SergiiDmytruk marked this pull request as ready for review November 13, 2024 18:26
@SergiiDmytruk
Copy link
Contributor Author

I let CI did the changes it wanted and it did this nonsense: e91a44f. Not sure what to make of it.

@macpijan, I suspect that #49 broke xen-tb, because I get:

WARNING: preferred version 4.17+tb of xen not available (for item xen)
WARNING: versions of xen available: 4.17+stable 4.18+stable 4.19+git

4.17+stable is what gets build, so no TrenchBoot support for Xen and I couldn't test that this doesn't break Xen as it seems to be already broken.

@macpijan
Copy link
Collaborator

I let CI did the changes it wanted and it did this nonsense: e91a44f. Not sure what to make of it.

It is actually correct and important to add this space when using append: https://docs.yoctoproject.org/bitbake/2.2/bitbake-user-manual/bitbake-user-manual-metadata.html#appending-and-prepending-override-style-syntax

Instead += can be used to avoid manual addition of space, and is more commonly used in such scenario.

@macpijan
Copy link
Collaborator

@SergiiDmytruk I fixed the xen recipe in: 0f96933

Can you please test it again, and publish results in some form to: https://github.com/dasharo/osfv-results ?

We could merge it and assign some tag in meta-trenchboot, so in the future we know which set of components resulted in these results.

@macpijan macpijan mentioned this pull request Nov 14, 2024
Merged
@SergiiDmytruk
Copy link
Contributor Author

Instead += can be used to avoid manual addition of space, and is more commonly used in such scenario.

That's what I tried to use at first, but CI didn't like it:

/code/recipes-support/skl/skl_git.bb:11:error:oelint.vars.srcuriappend:Use SRC_URI:append otherwise this will override weak defaults by inherit

Will take the space change then, maybe doubled addtask do_deploy after do_compile before do_build isn't necessary.

@SergiiDmytruk SergiiDmytruk mentioned this pull request Nov 14, 2024
Merged
krystian-hebel
krystian-hebel reviewed Nov 14, 2024
View reviewed changes
Copy link

@krystian-hebel krystian-hebel left a comment •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm also getting a kernel panic on HP t630 (both legacy and UEFI, both with and without slaunch) regarding TPM code:

[    2.681030] BUG: unable to handle page fault for address: ffffb2f100062000
[    2.681694] #PF: supervisor read access in kernel mode
[    2.681694] #PF: error_code(0x0000) - not-present page
[    2.681694] PGD 100000067 P4D 100000067 PUD 100213067 PMD 100214067 PTE 0
[    2.681694] Oops: Oops: 0000 [#1] PREEMPT SMP NOPTI
[    2.681694] CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.11.0-rc7-yocto-standard #1
[    2.681694] Hardware name: HP HP t630 Thin Client/8158, BIOS M40 v01.05 07/07/2017
[    2.681694] RIP: 0010:ioread8+0x35/0x70
[    2.681694] Code: 77 28 48 81 ff 00 00 01 00 76 0b 89 fa ec 0f b6 c0 e9 4f af 7a 00 8b 05 89 06 21 01 85 c0 75 14 b8 ff 00 00 00 e9 3b af 7a 00 <8a> 07 0f b6 c0 e9 31 af 7a 00 55 83 e8 01 48 89 fe 48 c7 c2 58 71
[    2.681694] RSP: 0018:ffffb2f100037ad0 EFLAGS: 00010292
[    2.681694] RAX: 0000000000000000 RBX: ffffb2f100037b10 RCX: ffffb2f100037b0f
[    2.681694] RDX: 0000000000000001 RSI: 0000000000001000 RDI: ffffb2f100062000
[    2.681694] RBP: ffffb2f100037af8 R08: 0000000000000000 R09: 0000000000000010
[    2.681694] R10: ffffb2f100037aa0 R11: ffffffff9241b210 R12: 0000000000001000
[    2.681694] R13: ffff8ea34303bd28 R14: ffffb2f100037b10 R15: 0000000000000000
[    2.681694] FS:  0000000000000000(0000) GS:ffff8ea513c00000(0000) knlGS:0000000000000000
[    2.681694] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[    2.681694] CR2: ffffb2f100062000 CR3: 000000021dc32000 CR4: 00000000001506f0
[    2.681694] Call Trace:
[    2.681694]  <TASK>
[    2.681694]  ? show_regs+0x68/0x80
[    2.681694]  ? __die+0x28/0x70
[    2.681694]  ? page_fault_oops+0x17f/0x4c0
[    2.681694]  ? ioread8+0x35/0x70
[    2.681694]  ? search_bpf_extables+0x64/0x90
[    2.681694]  ? ioread8+0x35/0x70
[    2.681694]  ? kernelmode_fixup_or_oops.isra.0+0x5f/0x70
[    2.681694]  ? __bad_area_nosemaphore+0x17b/0x240
[    2.681694]  ? bad_area_nosemaphore+0x16/0x20
[    2.681694]  ? do_kern_addr_fault.part.0+0x6e/0x80
[    2.681694]  ? exc_page_fault+0x140/0x1a0
[    2.681694]  ? asm_exc_page_fault+0x2b/0x30
[    2.681694]  ? ioread8+0x35/0x70
[    2.681694]  ? tpm_tcg_read_bytes+0x51/0xb0
[    2.681694]  check_locality+0x4b/0x90
[    2.681694]  tpm_tis_core_init+0x2f7/0x8f0
[    2.681694]  tpm_tis_init.part.0+0xa3/0x120
[    2.681694]  ? __pfx_tpm_tis_pnp_init+0x10/0x10
[    2.681694]  tpm_tis_pnp_init+0xda/0x110
[    2.681694]  pnp_device_probe+0xc4/0x170
[    2.681694]  really_probe+0xde/0x2e0
[    2.681694]  __driver_probe_device+0x78/0x120
[    2.681694]  driver_probe_device+0x24/0xf0
[    2.681694]  __driver_attach+0x8f/0x190
[    2.681694]  ? __pfx___driver_attach+0x10/0x10
[    2.681694]  bus_for_each_dev+0x91/0xe0
[    2.681694]  driver_attach+0x22/0x30
[    2.681694]  bus_add_driver+0xee/0x220
[    2.681694]  driver_register+0x62/0x120
[    2.681694]  ? __pfx_init_tis+0x10/0x10
[    2.681694]  pnp_register_driver+0x24/0x30
[    2.681694]  init_tis+0x73/0xe0
[    2.681694]  do_one_initcall+0x6b/0x260
[    2.681694]  kernel_init_freeable+0x1c6/0x300
[    2.681694]  ? __pfx_kernel_init+0x10/0x10
[    2.681694]  kernel_init+0x1e/0x1b0
[    2.681694]  ret_from_fork+0x41/0x60
[    2.681694]  ? __pfx_kernel_init+0x10/0x10
[    2.681694]  ret_from_fork_asm+0x1a/0x30
[    2.681694]  </TASK>
[    2.681694] Modules linked in:
[    2.681694] CR2: ffffb2f100062000
[    2.681694] ---[ end trace 0000000000000000 ]---
[    2.681694] RIP: 0010:ioread8+0x35/0x70
[    2.681694] Code: 77 28 48 81 ff 00 00 01 00 76 0b 89 fa ec 0f b6 c0 e9 4f af 7a 00 8b 05 89 06 21 01 85 c0 75 14 b8 ff 00 00 00 e9 3b af 7a 00 <8a> 07 0f b6 c0 e9 31 af 7a 00 55 83 e8 01 48 89 fe 48 c7 c2 58 71
[    2.681694] RSP: 0018:ffffb2f100037ad0 EFLAGS: 00010292
[    2.681694] RAX: 0000000000000000 RBX: ffffb2f100037b10 RCX: ffffb2f100037b0f
[    2.681694] RDX: 0000000000000001 RSI: 0000000000001000 RDI: ffffb2f100062000
[    2.681694] RBP: ffffb2f100037af8 R08: 0000000000000000 R09: 0000000000000010
[    2.681694] R10: ffffb2f100037aa0 R11: ffffffff9241b210 R12: 0000000000001000
[    2.681694] R13: ffff8ea34303bd28 R14: ffffb2f100037b10 R15: 0000000000000000
[    2.681694] FS:  0000000000000000(0000) GS:ffff8ea513c00000(0000) knlGS:0000000000000000
[    2.681694] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[    2.681694] CR2: ffffb2f100062000 CR3: 000000021dc32000 CR4: 00000000001506f0
[    2.681694] note: swapper/0[1] exited with irqs disabled
[    3.072368] Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000009
[    3.073356] Kernel Offset: 0xfa00000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff)
[    3.073356] ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000009 ]---

This particular platform has TPM1.2, I have the same platform with TPM2.0 at home, I'll check if the same problem exists there.

With UEFI, on VGA I'm getting this:

error: no such device: ((hd0,msdos1)/EFI/BOOT)/EFI/BOOT/grub.cfg

Normal GRUB output doesn't show there, IIUC this is because grub.cfg is built-in into EFI binary. Serial output works fine.

wic/grub-full.cfg Outdated Show resolved Hide resolved
@SergiiDmytruk
skl: add patch to pass entry point in %ebx
beeccbb 
Done this way because things in SKL will change more drastically later
and there is no point in committing this.

Signed-off-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
@SergiiDmytruk
Copy link
Contributor Author

both legacy and UEFI, both with and without slaunch

There is no UEFI slaunch in these changes, it's not Oracle's GRUB, so don't bother testing UEFI.

ffffb2f100062000 suggests that something goes wrong when new slaunch code (unrelated to AMD) tries to access locality 2. This might be a bug, although it's weird if it happens with DRTM as well.

@krystian-hebel
Copy link

It is remapped, so the offset doesn't matter. I've analyzed last instructions leading to the fault and the locality address (locality << 12) is in %rsi at the point of #PF, so it is locality 1. This happens as part of the loop that relinquishes all active localities. I thought it may be caused by TPM range not being marked as reserved, but everything seems fine there:

[    0.000000] BIOS-provided physical RAM map:
[    0.000000] BIOS-e820: [mem 0x0000000000000000-0x000000000009ffff] usable
[    0.000000] BIOS-e820: [mem 0x0000000000100000-0x00000000ddfa6fff] usable
[    0.000000] BIOS-e820: [mem 0x00000000ddfa7000-0x00000000de0a0fff] reserved
[    0.000000] BIOS-e820: [mem 0x00000000de0a1000-0x00000000de0dafff] ACPI data
[    0.000000] BIOS-e820: [mem 0x00000000de0db000-0x00000000de577fff] ACPI NVS
[    0.000000] BIOS-e820: [mem 0x00000000de578000-0x00000000de853fff] reserved
[    0.000000] BIOS-e820: [mem 0x00000000de854000-0x00000000deffffff] usable
[    0.000000] BIOS-e820: [mem 0x00000000f8000000-0x00000000fbffffff] reserved
[    0.000000] BIOS-e820: [mem 0x00000000feb80000-0x00000000fec01fff] reserved
[    0.000000] BIOS-e820: [mem 0x00000000fec10000-0x00000000fec10fff] reserved
[    0.000000] BIOS-e820: [mem 0x00000000fed00000-0x00000000fed00fff] reserved
[    0.000000] BIOS-e820: [mem 0x00000000fed40000-0x00000000fed44fff] reserved
[    0.000000] BIOS-e820: [mem 0x00000000fed80000-0x00000000fed8ffff] reserved
[    0.000000] BIOS-e820: [mem 0x00000000fedc0000-0x00000000fedc0fff] reserved
[    0.000000] BIOS-e820: [mem 0x00000000fedc2000-0x00000000fedc8fff] reserved
[    0.000000] BIOS-e820: [mem 0x00000000ff000000-0x00000000ffffffff] reserved
[    0.000000] BIOS-e820: [mem 0x0000000100000000-0x00000002deffffff] usable
[    0.000000] printk: legacy bootconsole [earlyser0] enabled
[    0.000000] NX (Execute Disable) protection: active
[    0.000000] APIC: Static calls initialized
[    0.000000] extended physical RAM map:
[    0.000000] reserve setup_data: [mem 0x0000000000000000-0x000000000009ffff] usable
[    0.000000] reserve setup_data: [mem 0x0000000000100000-0x00000000d5723017] usable
[    0.000000] reserve setup_data: [mem 0x00000000d5723018-0x00000000d5732c57] usable
[    0.000000] reserve setup_data: [mem 0x00000000d5732c58-0x00000000ddfa6fff] usable
[    0.000000] reserve setup_data: [mem 0x00000000ddfa7000-0x00000000de0a0fff] reserved
[    0.000000] reserve setup_data: [mem 0x00000000de0a1000-0x00000000de0dafff] ACPI data
[    0.000000] reserve setup_data: [mem 0x00000000de0db000-0x00000000de577fff] ACPI NVS
[    0.000000] reserve setup_data: [mem 0x00000000de578000-0x00000000de853fff] reserved
[    0.000000] reserve setup_data: [mem 0x00000000de854000-0x00000000deffffff] usable
[    0.000000] reserve setup_data: [mem 0x00000000f8000000-0x00000000fbffffff] reserved
[    0.000000] reserve setup_data: [mem 0x00000000feb80000-0x00000000fec01fff] reserved
[    0.000000] reserve setup_data: [mem 0x00000000fec10000-0x00000000fec10fff] reserved
[    0.000000] reserve setup_data: [mem 0x00000000fed00000-0x00000000fed00fff] reserved
[    0.000000] reserve setup_data: [mem 0x00000000fed40000-0x00000000fed44fff] reserved
[    0.000000] reserve setup_data: [mem 0x00000000fed80000-0x00000000fed8ffff] reserved
[    0.000000] reserve setup_data: [mem 0x00000000fedc0000-0x00000000fedc0fff] reserved
[    0.000000] reserve setup_data: [mem 0x00000000fedc2000-0x00000000fedc8fff] reserved
[    0.000000] reserve setup_data: [mem 0x00000000ff000000-0x00000000ffffffff] reserved
[    0.000000] reserve setup_data: [mem 0x0000000100000000-0x00000002deffffff] usable
[    0.000000] efi: EFI v2.4 by American Megatrends
[    0.000000] efi: ESRT=0xde7ef298 ACPI=0xde0ac000 ACPI 2.0=0xde0ac000 SMBIOS=0xf05e0 
[    0.000000] efi: Remove mem27: MMIO range=[0xf8000000-0xfbffffff] (64MB) from e820 map
[    0.000000] efi: Remove mem28: MMIO range=[0xfeb80000-0xfec01fff] (0MB) from e820 map
[    0.000000] efi: Not removing mem29: MMIO range=[0xfec10000-0xfec10fff] (4KB) from e820 map
[    0.000000] efi: Not removing mem30: MMIO range=[0xfed00000-0xfed00fff] (4KB) from e820 map
[    0.000000] efi: Not removing mem31: MMIO range=[0xfed40000-0xfed44fff] (20KB) from e820 map
[    0.000000] efi: Not removing mem32: MMIO range=[0xfed80000-0xfed8ffff] (64KB) from e820 map
[    0.000000] efi: Not removing mem33: MMIO range=[0xfedc0000-0xfedc0fff] (4KB) from e820 map
[    0.000000] efi: Not removing mem34: MMIO range=[0xfedc2000-0xfedc8fff] (28KB) from e820 map
[    0.000000] efi: Remove mem35: MMIO range=[0xff000000-0xffffffff] (16MB) from e820 map

@SergiiDmytruk
Copy link
Contributor Author

Don't know why I thought that 64K-alignment is reasonable to expect...

I thought it may be caused by TPM range not being marked as reserved

tpm_tis.c seems to use 0xFED40000-0xFED44FFF range if forced, but otherwise uses data from ACPI. Maybe ACPI reports 0xFED40000-0xFED40FFF range?

@krystian-hebel
Copy link

tpm_tis.force allowed me to boot, with few lines in dmesg, not sure if they are bad or expected when forced:

[    2.615695] tpm_tis tpm_tis: 1.2 TPM (device-id 0x1A, rev-id 16)
[    2.712345] tpm_tis 00:09: error -EBUSY: can't request region for resource [mem 0xfed40000-0xfed40fff]
[    2.721690] tpm_tis 00:09: probe with driver tpm_tis failed with error -16

It doesn't get this from ACPI, but it does from PNP:

root@tb:~# cat /sys/devices/pnp0/00\:09/resources                               
state = active                                                                  
mem 0xfed40000-0xfed40fff

I will check again if platform with TPM 2.0 (and a newer BIOS) also has this problem. It seems to be firmware issue.

@macpijan
Copy link
Collaborator

Since this has been confirmed to work on at least Linux path on APU2 board, I will go ahead and merge it. Let's discuss further improvements in followup MRs or issues.

@macpijan macpijan merged commit beeccbb into master Nov 15, 2024
1 check passed
@macpijan macpijan deleted the amd branch November 15, 2024 17:37
@macpijan macpijan mentioned this pull request Nov 15, 2024
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@macpijan macpijan macpijan approved these changes

@krystian-hebel krystian-hebel krystian-hebel approved these changes

Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
3 participants
@SergiiDmytruk @macpijan @krystian-hebel