# Coreboot/OpenSIL Porting Underway for AMD FW16

**URL:** <https://community.frame.work/t/coreboot-opensil-porting-underway-for-amd-fw16/81031>\
**Category:** Framework Laptop 16\
**Tags:** bios, project, framework-laptop-16-amd-7040, expansion-bay-shell, feature-requests\
**Created:** [March 2, 2026, 4:39pm UTC](https://community.frame.work/t/coreboot-opensil-porting-underway-for-amd-fw16/81031 "2026-03-02T16:39:44Z")\
**Posts on this page:** 20\
**Page:** 1

<div class="post-metadata">

**Author:** ![GhostLegion](https://sea1.discourse-cdn.com/flex001/user_avatar/community.frame.work/ghostlegion/32/3356_2.png) [@GhostLegion](https://community.frame.work/u/GhostLegion)\
**Post date:** [March 2, 2026, 4:39pm UTC](https://community.frame.work/t/coreboot-opensil-porting-underway-for-amd-fw16/81031/1 "2026-03-02T16:39:44Z")

</div>

> **[Framework 16 Gen1 Seeing Coreboot + AMD openSIL Port, Framework 13 AMD Gen1...](https://www.phoronix.com/news/Framework-16-Coreboot-openSIL)**
>
> Work is underway by 9elements on porting Coreboot plus AMD openSIL to the first-generation Ryzen 7000 series Framework 16 laptop and is expected to be followed by a similar port to the Framework 13 Gen1 laptop too.

If and when this happens to the FW13 and is at least MVP then Framework becomes a viable option for me again. I got burned so horribly with the Intel 12th gen platform that never again will I buy a laptop without FOSS firmware already available.

I sincerely hope FW is privately supporting this effort. FOSS firmware and firmware support in general has not been well handled by this company in the past.

Hopefully the port will be complete or in a MVP stage by the end of the year.

---

<div class="post-metadata">

**Author:** ![jared\_kidd](https://avatars.discourse-cdn.com/v4/letter/j/91b2a8/32.png) [@jared\_kidd](https://community.frame.work/u/jared_kidd)\
**Post date:** [March 2, 2026, 5:56pm UTC](https://community.frame.work/t/coreboot-opensil-porting-underway-for-amd-fw16/81031/2 "2026-03-02T17:56:58Z")

</div>

No link in that article that I can find, so I’m not holding my breath.

However, a working alternative to Framework’s garbage firmware would be an amazing thing to happen. We are still tortured with terrible firmware bugs over a year into this laptop.

---

<div class="post-metadata">

**Author:** ![RokeJulianLockhart](https://sea1.discourse-cdn.com/flex001/user_avatar/community.frame.work/rokejulianlockhart/32/45602_2.png) [@RokeJulianLockhart](https://community.frame.work/u/RokeJulianLockhart)\
**Post date:** [March 2, 2026, 7:29pm UTC](https://community.frame.work/t/coreboot-opensil-porting-underway-for-amd-fw16/81031/3 "2026-03-02T19:29:35Z")

</div>

[@admins](https://community.frame.work/groups/admins), best to merge with the pre-existent thread:

> [@\[RESPONDED\] Coreboot on the Framework Laptop](https://community.frame.work/t/responded-coreboot-on-the-framework-laptop/791/574):
>
> Seams to some work done on the matter. Worth to keep an eye on.

---

<div class="post-metadata">

**Author:** ![TechPriestNhyk](https://sea1.discourse-cdn.com/flex001/user_avatar/community.frame.work/techpriestnhyk/32/27853_2.png) [@TechPriestNhyk](https://community.frame.work/u/TechPriestNhyk)\
**Post date:** [March 2, 2026, 7:38pm UTC](https://community.frame.work/t/coreboot-opensil-porting-underway-for-amd-fw16/81031/4 "2026-03-02T19:38:53Z")

</div>

For the uninitiated like me, what would coreboot support mean? Is it like a custom-bios or something?

---

<div class="post-metadata">

**Author:** ![MayOrMayNotBeACat](https://avatars.discourse-cdn.com/v4/letter/m/d26b3c/32.png) [@MayOrMayNotBeACat](https://community.frame.work/u/MayOrMayNotBeACat)\
**Post date:** [March 2, 2026, 7:50pm UTC](https://community.frame.work/t/coreboot-opensil-porting-underway-for-amd-fw16/81031/5 "2026-03-02T19:50:50Z")

</div>

I think so. The big advantage would be that Framework would be free to focus on newer hardware without having to support old boards via frequent software updates in order to patch exploits.

---

<div class="post-metadata">

**Author:** ![TechPriestNhyk](https://sea1.discourse-cdn.com/flex001/user_avatar/community.frame.work/techpriestnhyk/32/27853_2.png) [@TechPriestNhyk](https://community.frame.work/u/TechPriestNhyk)\
**Post date:** [March 2, 2026, 7:52pm UTC](https://community.frame.work/t/coreboot-opensil-porting-underway-for-amd-fw16/81031/6 "2026-03-02T19:52:08Z")

</div>

Ah gotcha. My first thought was that it might expose options available through something like smokeless easier to get to, but from a business perspective I could see the sense in what you say.

---

<div class="post-metadata">

**Author:** ![GhostLegion](https://sea1.discourse-cdn.com/flex001/user_avatar/community.frame.work/ghostlegion/32/3356_2.png) [@GhostLegion](https://community.frame.work/u/GhostLegion)\
**Post date:** [March 3, 2026, 4:50am UTC](https://community.frame.work/t/coreboot-opensil-porting-underway-for-amd-fw16/81031/7 "2026-03-03T04:50:21Z")

</div>

It was a private message from the developer to Michael who runs Phoronix. He said as much in the comments on the article.

---

<div class="post-metadata">

**Author:** ![GhostLegion](https://sea1.discourse-cdn.com/flex001/user_avatar/community.frame.work/ghostlegion/32/3356_2.png) [@GhostLegion](https://community.frame.work/u/GhostLegion)\
**Post date:** [March 3, 2026, 4:54am UTC](https://community.frame.work/t/coreboot-opensil-porting-underway-for-amd-fw16/81031/8 "2026-03-03T04:54:42Z")

</div>

It replaces the InsydeH2O BIOS currently in use with a FOSS alternative. This would enable the community to implement features desired that Framework has failed to enable such as ReBAR support and yes, provide firmware support after Framework abandons/EOLs products.

There are theoretical security benefits that come inherently with open-source as well. Plus the ideological consistency between R2R and FOSS.

---

<div class="post-metadata">

**Author:** ![TechPriestNhyk](https://sea1.discourse-cdn.com/flex001/user_avatar/community.frame.work/techpriestnhyk/32/27853_2.png) [@TechPriestNhyk](https://community.frame.work/u/TechPriestNhyk)\
**Post date:** [March 3, 2026, 2:08pm UTC](https://community.frame.work/t/coreboot-opensil-porting-underway-for-amd-fw16/81031/9 "2026-03-03T14:08:14Z")

</div>

Ahhh, that’s pretty cool. Thanks! Like many other’s here, I’m also a FOSS enjoyer.

---

<div class="post-metadata">

**Author:** ![GhostLegion](https://sea1.discourse-cdn.com/flex001/user_avatar/community.frame.work/ghostlegion/32/3356_2.png) [@GhostLegion](https://community.frame.work/u/GhostLegion)\
**Post date:** [March 5, 2026, 10:38am UTC](https://community.frame.work/t/coreboot-opensil-porting-underway-for-amd-fw16/81031/11 "2026-03-05T10:38:41Z")

</div>

Thanks for your efforts! I’m sure the fruits of your labors will be greatly appreciated when it’s all done!

---

<div class="post-metadata">

**Author:** ![James3](https://avatars.discourse-cdn.com/v4/letter/j/b5e925/32.png) [@James3](https://community.frame.work/u/James3)\
**Post date:** [March 5, 2026, 8:59pm UTC](https://community.frame.work/t/coreboot-opensil-porting-underway-for-amd-fw16/81031/12 "2026-03-05T20:59:00Z")

</div>

@ellyqw  
What bits are working on your opensil bios?  
From memory, the steps are approx:

1. self test some instructions.
2. program the cache to act as the ram
3. do some more self tests
4. get RAM chips working.
5. get Cpu bootstraped. SMM etc.
6. get devices configured.
7. get display working
8. boot os from a device.

---

<div class="post-metadata">

**Author:** ![ellyqw](https://sea1.discourse-cdn.com/flex001/user_avatar/community.frame.work/ellyqw/32/46459_2.png) [@ellyqw](https://community.frame.work/u/ellyqw)\
**Post date:** [March 5, 2026, 10:56pm UTC](https://community.frame.work/t/coreboot-opensil-porting-underway-for-amd-fw16/81031/13 "2026-03-05T22:56:49Z")

</div>

Your information is outdated (although mostly correct in terms of Intel CPUs).

If i may do a bit of shamelss self-plug here, I explained it in detail at 38C3:

> **[corebooting Intel-based systems](https://media.ccc.de/v/38c3-corebooting-intel-based-systems)**
>
> Gaining a reasonable level of trust on the firmware that runs your everyday activities
> 
> Corebootable or not corebootable, that is the que...

Also worth watching in terms of PSP:

> **[Uncover, Understand, Own - Regaining Control Over Your AMD CPU](https://media.ccc.de/v/36c3-10942-uncover_understand_own_-_regaining_control_over_your_amd_cpu)**
>
> The AMD Platform Security Processor (PSP) is a dedicated ARM CPU inside your AMD processor and runs undocumented, proprietary firmware pr...

> **[Opening pAMDora's box and unleashing a thousand paths on the journey to play...](https://media.ccc.de/v/39c3-opening-pamdora-s-box-and-unleashing-a-thousand-paths-on-the-journey-to-play-beatsaber-custom-songs)**
>
> While trying to apply fault injection to the AMD Platform Security Processor with unusual (self-imposed) requirements/restrictions, it we...

Another (older) shameless self-plug. relevant to the discussion only because of CrosEC:

> **[Turning Chromebooks into regular laptops](https://media.ccc.de/v/37c3-11929-turning_chromebooks_into_regular_laptops#t=2320)**
>
> Deep dive into (ex)ChromeOS hardware from developer's perspective.
> 
> In this talk you will learn how ChromeOS hardware designed by Google ...

On AMD Zen architecture you don’t have CAR anymore. Memory initialization is done by the PSP (Platform Security Processor), a tiny ARM core(s) (one per CCX). So it looks more or less like:

1. Apply power to the SoC.
2. PSP BootROM wakes up, loads off-chip bootloader.
3. ABL (AGESA Boot Loader).
4. Parse APCB, in our case memory isn’t soldered so SPD ROMs are located at SMBus 0x50 and 0x51.
5. Perform memory training and initialization, save to APOB.
6. Load SecureOS, TPM and other “security” stuff.
7. Release x86\_64 cores from reset.
8. Bring-up the UART GPIOs and other things you added to bootblock.
9. Jump to romstage, it’s not doing anything here (since memory is already up) except for passing some pointers etc.
10. Jump to ramstage, where silicon initialization is taking place (APIC, MPIO, CCX, PCIe etc.)
11. Payload (we’re not at this point yet): For now it will be only EDK2. Modern AMD iGPUs don’t support legacy BIOSes anymore, OpenSIL ships with GOP driver that needs to be added to the build. I’m planning on reverse-engineering it though and using LinuxBoot should be possible anyway as Linux kernel can perform gfxinit on it’s own).

[https://f.sakamoto.pl/elly/coreboot/boot-cb-lotus-opensil.txt](https://f.sakamoto.pl/elly/coreboot/boot-cb-lotus-opensil.txt)

---

<div class="post-metadata">

**Author:** ![ellyqw](https://sea1.discourse-cdn.com/flex001/user_avatar/community.frame.work/ellyqw/32/46459_2.png) [@ellyqw](https://community.frame.work/u/ellyqw)\
**Post date:** [March 8, 2026, 9:01am UTC](https://community.frame.work/t/coreboot-opensil-porting-underway-for-amd-fw16/81031/14 "2026-03-08T09:01:12Z")

</div>

Thought you folks might be interested. I think it’s a decent progress for one week 😛

1. Figuring out the `SIL_CONTEXT` structure took me quite a while, but eventually saw which values SilContext is passing data to. After adding it the memory was “initialized” without any hacks:  
`SIL_CONTEXT silcontext;`  
`silcontext.ApobBaseAddress = CONFIG_PSP_APOB_DRAM_ADDRESS;`  
`silcontext.SilMemBaseAddress = CONFIG_EARLY_RESERVED_DRAM_BASE;`

2. There are still some issues with memory however, as during CCX init it reports nonsensical values:  
`[DEBUG] SIL:xUSL:AmdGetApobEntry:67:APOB SIG Check fail, APOB is not supported`  
`[DEBUG] SIL:xUSL:AmdGetApobEntryInstance:172:No entry found`  
`[ERROR] SIL:xUSL:ApobGetCcdLogToPhysMapPhx:386:Failed to retrieve Apob Instance (InstanceId = 0x0)`  
`[DEBUG] SIL:xUSL:InitializeCcxAndLaunchAps:330:NumberOfSockets=1`  
`[DEBUG] SIL:xUSL:InitializeCcxAndLaunchAps:331:NumberOfDies=1`  
`[DEBUG] SIL:xUSL:InitializeCcxAndLaunchAps:332:NumberOfCcds=1550182662`  
`[DEBUG] SIL:xUSL:InitializeCcxAndLaunchAps:333:NumberOfComplexes=1550639000`  
`[DEBUG] SIL:xUSL:InitializeCcxAndLaunchAps:334:NumberOfCores=1550639376`  
`[DEBUG] SIL:xUSL:InitializeCcxAndLaunchAps:335:NumberOfThreads=33`  
`[DEBUG] SIL:xUSL:InitializeCcxAndLaunchAps:351:AmdDownCoreMode is changed to CCX_DOWN_CORE_7_0`  
`[DEBUG] SIL:xUSL:CcxDownCoreInit:213:CCD mode: 0x8`  
`[DEBUG] SIL:xUSL:GetZen4DesiredCcdCount:63:Unsupported CCD Mode 8`  
`[DEBUG] SIL:xUSL:GetZen4DesiredCcdCount:70:Zen4: DesiredCcdCount 0xFFFFFFFF CcdDisMask 0x0`  
`[ERROR] SIL:xUSL:CcxDownCoreInit:228:Invalid CCD mode requested!`  
`[ERROR] SIL:xUSL:CcxDownCoreInit:263:Invalid CCX downcore mode requested!`

3. Had to hack-up OpenSIL’s code for AOAC as it would disable UART0 during powering it on. I suspect OpenSIL uses different device definitions, but I find it a bit funny that I ran into the same exact issue when I was working on PantherLake about half a year ago (although that was a problem with early silicon revision). I simply sabotaged the check for now:

Looks like _now_ we’re getting to the point of initialising USB and PCIe, but obviously I haven’t worked on that code yet as I expected more issues with silicon initialization:

`[SPEW] SIL:xUSL:InitializeMpioPhxTp1:116:`  
`[SPEW] SIL:xUSL:xUslFindStructure:92:`  
`[DEBUG] SIL:xUSL:xUslFindStructure:99:Looking for IP block ID 17`  
`[DEBUG] SIL:xUSL:xUslFindStructure:106:SilMemoryBase: 0x2000000, FreeSpaceOffset: 0x1b7a4, FreeSpaceBase = 0x201b7a4`  
`[SPEW] SIL:xUSL:xUslFindStructure:116:FoundStruc.Data @0x2006a3c`  
`[DEBUG] SIL:xUSL:InitializeMpioPhxTp1:130:MPIO IP block is located at 2006a3c`  
`[SPEW] SIL:xUSL:xUslFindStructure:92:`  
`[DEBUG] SIL:xUSL:xUslFindStructure:99:Looking for IP block ID 13`  
`[DEBUG] SIL:xUSL:xUslFindStructure:106:SilMemoryBase: 0x2000000, FreeSpaceOffset: 0x1b7a4, FreeSpaceBase = 0x201b7a4`  
`[SPEW] SIL:xUSL:xUslFindStructure:116:FoundStruc.Data @0x2019b0c`  
`[SPEW] SIL:xUSL:NbioInitializeDxio:92:`  
`[SPEW] SIL:xUSL:FixupLaneMappingForFP8:804:`  
`[DEBUG] SIL:xUSL:FixupLaneMappingForFP8:825:Lane Mapping for PHX1 and HPT1`  
`[SPEW] SIL:xUSL:FixupLaneMappingForFP8:845:`  
`[SPEW] SIL:xUSL:MpioRemoveCxlLinksPhx:573:`  
`[SPEW] SIL:xUSL:MpioRemoveCxlLinksPhx:579:`  
`[SPEW] SIL:xUSL:MpioConfigurePsppPhx:1794:`  
`[SPEW] SIL:xUSL:xUslFindStructure:92:`  
`[DEBUG] SIL:xUSL:xUslFindStructure:99:Looking for IP block ID 17`  
`[DEBUG] SIL:xUSL:xUslFindStructure:106:SilMemoryBase: 0x2000000, FreeSpaceOffset: 0x1b7a4, FreeSpaceBase = 0x201b7a4`  
`[SPEW] SIL:xUSL:xUslFindStructure:116:FoundStruc.Data @0x2019aac`  
`[SPEW] SIL:xUSL:MpioConfigurePsppPhx:1818:`  
`[DEBUG] SIL:xUSL:MpioCfgBeforeDxioInit:202: Socket 0`  
`[SPEW] SIL:xUSL:MpioManageTopology:435:`  
`[ERROR] SIL:xUSL:MpioManageTopology:471:Complex descriptors reached limit without terminator.`  
`[DEBUG] SIL:xUSL:MpioUserConfigDump:134:<---------- PCIe User Config Start------------->`  
`[DEBUG] SIL:xUSL:MpioUserConfigDump:135: BMC Link Location is 0`  
`[DEBUG] SIL:xUSL:MpioUserConfigDump:140:<---------------- Socket 0 ----------------->`  
`[DEBUG] SIL:xUSL:MpioUserConfigDump:140:<---------------- Socket 1 ----------------->`  
`[DEBUG] SIL:xUSL:MpioUserConfigDump:140:<---------------- Socket 2 ----------------->`  
`[DEBUG] SIL:xUSL:MpioUserConfigDump:140:<---------------- Socket 3 ----------------->`  
`[///]`  
`[DEBUG] SIL:xUSL:MpioUserDescriptorConfigDump:33: Engine Type - Invalid`  
`[DEBUG] SIL:xUSL:MpioUserDescriptorConfigDump:38: Start Phy Lane - 41`  
`[DEBUG] End Phy Lane - 16`  
`[DEBUG] SIL:xUSL:MpioUserDescriptorConfigDump:43: Hotplug - 0`  
`[DEBUG] SIL:xUSL:MpioUserDescriptorConfigDump:44: GpioGroupId - 67`

I reckon we should be able to get into payload (EDK2) by the end of next week if I won’t run into some silly issues with MPIO. I’m going to enjoy my weekend first though 😉

---

<div class="post-metadata">

**Author:** ![James3](https://avatars.discourse-cdn.com/v4/letter/j/b5e925/32.png) [@James3](https://community.frame.work/u/James3)\
**Post date:** [March 8, 2026, 10:17am UTC](https://community.frame.work/t/coreboot-opensil-porting-underway-for-amd-fw16/81031/15 "2026-03-08T10:17:52Z")

</div>

In the boot logs, one of the errors is stack corruption. I would suggest probably start looking there, before sorting the apob problem.  
Maybe a problem with calls between source code and binary blobs and the associated return values.

`[ERROR] Stack corruption detected at eip: 0x5c666f54`

---

<div class="post-metadata">

**Author:** ![sirwolfgang](https://avatars.discourse-cdn.com/v4/letter/s/a9adbd/32.png) [@sirwolfgang](https://community.frame.work/u/sirwolfgang)\
**Post date:** [March 8, 2026, 7:36pm UTC](https://community.frame.work/t/coreboot-opensil-porting-underway-for-amd-fw16/81031/16 "2026-03-08T19:36:27Z")

</div>

I’m excited to see that there is active effort here. I’ve been running into some issues with the current bios.

How different/much of a lift do you think it would be to go from the Gen 1 AMD 7040 to the Gen 2 Ryzen AI 300?

---

<div class="post-metadata">

**Author:** ![ellyqw](https://sea1.discourse-cdn.com/flex001/user_avatar/community.frame.work/ellyqw/32/46459_2.png) [@ellyqw](https://community.frame.work/u/ellyqw)\
**Post date:** [March 9, 2026, 7:54pm UTC](https://community.frame.work/t/coreboot-opensil-porting-underway-for-amd-fw16/81031/17 "2026-03-09T19:54:05Z")

</div>

@James3 that was a problem (mostly) with my sleep deprivation, I missed some places where `SIL_CONTEXT` should’ve been present.

Michał from 3mdeb shared his take on this patch series and while it’s not fully correct (in my opinion), it fixed some of those issues: [Fix building phoenix\_poc with coreboot by ellyq · Pull Request #43 · openSIL/openSIL · GitHub](https://github.com/openSIL/openSIL/pull/43)

With those changes, it looks like MPIO (MicroProcessor Input/Output) block initializes PCIe. I can see that my NVME SSD (in big slot) and WiFi card are detected:

```plaintext
[DEBUG] SIL:xUSL:GetAsk:227:Response = 0x1 | 0xd0 | 0x0 | 0x0 | 0x0 | 0x0
[SPEW] SIL:xUSL:MpioUpdatePortTrainingStatus:45:
[DEBUG] SIL:xUSL:MpioUpdatePortTrainingStatus:56: Training State for Device 1 Function 1 is 0x8
[DEBUG] SIL:xUSL:MpioUpdatePortTrainingStatus:85: linkTrainingState indicates EMPTY_SLOT
[DEBUG] SIL:xUSL:MpioUpdatePortTrainingStatus:56: Training State for Device 1 Function 2 is 0x8
[DEBUG] SIL:xUSL:MpioUpdatePortTrainingStatus:85: linkTrainingState indicates EMPTY_SLOT
[DEBUG] SIL:xUSL:MpioUpdatePortTrainingStatus:56: Training State for Device 2 Function 2 is 0x6
[DEBUG] SIL:xUSL:MpioUpdatePortTrainingStatus:67:Successful Device is on Socket 0 StartLane 23 Endlane 23 Device 2 Function 2
[DEBUG] SIL:xUSL:MpioUpdatePortTrainingStatus:56: Training State for Device 2 Function 4 is 0x6
[DEBUG] SIL:xUSL:MpioUpdatePortTrainingStatus:67:Successful Device is on Socket 0 StartLane 24 Endlane 27 Device 2 Function 4
[SPEW] SIL:xUSL:MpioUpdatePortTrainingStatus:93:
[DEBUG] SIL:xUSL:WaitReady:40:Wait for MPIO ready...
[DEBUG] SIL:xUSL:MpioServiceRequestCommon:75:MpioServiceRequest Enter
[DEBUG] SIL:xUSL:MpioServiceRequestCommon:88: MPIO Service Request 0x1
[DEBUG] SIL:xUSL:MpioServiceRequestCommon:89: MPIO Service Request Argument 0x0, 0x0, 0x0, 0x0, 0x0, 0x0
[DEBUG] SIL:xUSL:MpioServiceRequestCommon:212:MpioServiceRequest Exit

```

@sirwolfgang I was told that Strix/Krackan will not receive OpenSIL support. However, AMD’s engineers said they would be open to support this and my coworkers added preliminary support for this platform in coreboot.

If PSB (Platform Secure Boot) is disabled on that platform, we’ll simply need to nicely ask Nirav to share schematics with me once I get this model up and running 😉

You can check if PSB is disabled by pulling coreboot repository, going to `util/amdtool`, compiling it and launching it as root (disable secureboot, add `iomem=relaxed` to cmdline at boot): `./amdtool -a`.

At the bottom of report you should see the status. Here’s how it looks on Phoenix:

```plaintext
============= Platform Secure Boot ==============

PSB: STATUS = 00000000
0x0000 = PLATFORM_VENDOR_ID
0x0000 = PLATFORM_MODEL_ID
0x0000 = BIOS_KEY_REVISION_ID
0x0000 = ROOT_KEY_SELECT
0x0000 = PLATFORM_SECURE_BOOT_EN
0x0000 = DISABLE_BIOS_KEY_ANTIROLLBACK
0x0000 = DISABLE_AMD_KEY_USAGE
0x0000 = DISABLE_SECURE_DEBUG_UNLOCK
0x0000 = CUSTOMER_KEY_LOCK
PSB: HSTI = 50001001
0x0001 = PSB Status/Error (Other)
0x0000 = PSB Fusing Readiness
0x0001 = SPL Fuse Update Required
0x0000 = SPL Fuse Error
0x0000 = SPL Entry Error
0x0000 = SPL Table Missing
0x0001 = HSTISTATE_PSP_SECURE_EN
0x0000 = HSTISTATE_PSP_PLATFORM_SECURE_EN
0x0001 = HSTISTATE_PSP_DEBUG_LOCK_ON
0x0000 = HSTISTATE_PSP_CUSTOMER_KEY_LOCK_ON

PSB state: NOT ENABLED
You may flash other firmware!
But the Platform Secure Boot state may still be changed to ENABLED or DISABLED!

=================================================

```

---

<div class="post-metadata">

**Author:** ![James3](https://avatars.discourse-cdn.com/v4/letter/j/b5e925/32.png) [@James3](https://community.frame.work/u/James3)\
**Post date:** [March 9, 2026, 8:48pm UTC](https://community.frame.work/t/coreboot-opensil-porting-underway-for-amd-fw16/81031/18 "2026-03-09T20:48:55Z")

</div>

@ellyqw  
On the FW16 AMD 7840HS that you have.  
Which pins on the mainboard are you using to flash the BIOS ?  
Which tool / software are you using to flash the BIOS?

---

<div class="post-metadata">

**Author:** ![ellyqw](https://sea1.discourse-cdn.com/flex001/user_avatar/community.frame.work/ellyqw/32/46459_2.png) [@ellyqw](https://community.frame.work/u/ellyqw)\
**Post date:** [March 9, 2026, 9:47pm UTC](https://community.frame.work/t/coreboot-opensil-porting-underway-for-amd-fw16/81031/19 "2026-03-09T21:47:52Z")

</div>

I believe I already mentioned it in the thread where you asked about JUDC connector.

- [Glasgow Interface Explorer](https://glasgow-embedded.org/latest/intro.html#what-is-glasgow)
- [Raspberry Pi Pico](https://www.raspberrypi.com/documentation/microcontrollers/pico-series.html)
- [Shelly Plus Plug S](https://www.shelly.com/products/shelly-plug-s-gen3-1)

1. Glasgow is connected to JSPI (interfacing with Winbond 256Mbit SPI flash) and JUDC (SoC UART0).  
It’s capable of driving it’s I/O pins with 1.8V and can run two applets at the same time, which makes it perfect for the job (as mentioned, I/O on AMD SoCs is 1.8V only).
2. Pi Pico is connected to JECDB and it’s used for talking with the Embedded Controller’s UART (3.3V I/O).
3. Shelly Plug is connected between power strip and official 180W power adapter that came with the laptop. It allows me to toggle power on/off from terminal using curl (including toggling power on for specified amount of time, so I don’t have to worry about leaving system in powered-on state and forgetting about it).

 ![mpv-shot0021](https://us1.discourse-cdn.com/flex001/uploads/framework3/original/3X/2/d/2dbb2de0f5601d580cb8b19ccd62b992e54ca5ab.jpeg)

 ![spi](https://us1.discourse-cdn.com/flex001/uploads/framework3/original/3X/a/b/ab29a457bd07f35ddcb13a53b06cb9b0616c647d.jpeg)

 ![jecdb](https://us1.discourse-cdn.com/flex001/uploads/framework3/original/3X/e/d/ed7454d9820b9ee57e41ebd94d1b69029489f7d1.jpeg)

 ![setup](https://us1.discourse-cdn.com/flex001/uploads/framework3/original/3X/6/f/6fb19f28eaffa663071bef4d201734634ae6dfc8.jpeg)

 ![Screenshot_20260309_224517](https://us1.discourse-cdn.com/flex001/uploads/framework3/original/3X/b/2/b2fe9db62cd826bbed0da8c4fcdb09eade35612e.jpeg)

---

<div class="post-metadata">

**Author:** ![sirwolfgang](https://avatars.discourse-cdn.com/v4/letter/s/a9adbd/32.png) [@sirwolfgang](https://community.frame.work/u/sirwolfgang)\
**Post date:** [March 9, 2026, 10:43pm UTC](https://community.frame.work/t/coreboot-opensil-porting-underway-for-amd-fw16/81031/20 "2026-03-09T22:43:25Z")

</div>

@ellyqw Unfortunately it’s reporting that dumping PSB status is not yet supported on this northbridge. Southbridge is also reporting not fully supported.

AMD Krackan Root Complex [1022:1122]  
Ryzen AI 7 350 w/ Radeon 860M: Family 26, Model 96, Stepping 0

I’ve ordered a [cheaper] spare mainboard, headers, connectors, etc so I can get a sled up and running.

---

<div class="post-metadata">

**Author:** ![ellyqw](https://sea1.discourse-cdn.com/flex001/user_avatar/community.frame.work/ellyqw/32/46459_2.png) [@ellyqw](https://community.frame.work/u/ellyqw)\
**Post date:** [March 9, 2026, 10:57pm UTC](https://community.frame.work/t/coreboot-opensil-porting-underway-for-amd-fw16/81031/21 "2026-03-09T22:57:08Z")

</div>

We should add support for that then, shouldn’t be too difficult. Happy hacking! 😃

[Next page](https://community.frame.work/t/coreboot-opensil-porting-underway-for-amd-fw16/81031.md?page=2)