CSMWrap hangs on Surface Pro 1

[2W10]

Hi,

I am trying to make this work on my Surface Pro 1. But when I put it on the UEFI partition, it boots but hangs at SeaBIOS. I tried pressing ESC and 1-2 but nothing worked. How do I fix this?

I am using v1.2

FYI: I have gotten XP x64 Vista and 7 to work on the SP1: https://youtube.com/playlist?list=PLJgjiVZvN6T3lndRPzHltu8NiNwSkvweA&si=Hg6zf7cPkjgPOYtZ

https://github.com/user-attachments/assets/2372321d-ac67-442b-9177-f6c40f87393a

[FlyGoat]

Will look into it once I get some time.

[2W10]

K sounds good. I also got similar issues on my gaming PC

It's an intel 12th gen I think ![Uploading 446827000...]![Uploading 446827002...]![Uploading 446827003...]

[FlyGoat]

K sounds good. I also got similar issues on my gaming PC

It's an intel 12th gen I think ![Uploading 446827000...]![Uploading 446827002...]![Uploading 446827003...]

It's likely to be another issue tho....

Why this UEFI firmware is having that much non-continuous memory maps that is even overflowing 128 e820 entries....

[2W10]

Ok so on my surface pro it started randomly working with freedos but it didn't load

Then I replaced it with windows 7 x86 and made it the active partition and now it's hanging at this screen again

[FlyGoat]

It actually sounds like a issue on SeaBIOS disk driver.

Where was your FreeDOS/Windows7 image placed? SSD? USB flash disk? If it's USB was it USB 3.0?

Thanks

[2W10]

ok so it started to randomly work it was on my ssd

my setup was MBR disk 100MB partition with the csmwrap.efi placed in /EFI/BOOT and named as bootx64.efi

and then the Windows 7 x86/FreeDOS partition

[FlyGoat]

I suspect this is a variant of previous AHCI issue, can you try this build: https://github.com/FlyGoat/csmwrap/actions/runs/15207637444

Thanks

[2W10]

i tried it it still isnt working

[2W10]

update: i tried installing ms-dos on there

it still hung but after a few reboots it actually said "press esc for boot menu"

It freezes on this screen tho Think the driver might be buggy

[2W10]

also i dont think keyboard works either btw i installed dos 7.10 on there

[2W10]

i think there may be some issues when u use ntfs partition idk

[FlyGoat]

SeaBIOS won't look into NTFS partition at all, it only reads MBR. Likely to be a hardware driver issue...

[2W10]

oh alr u think it will be fixed soon?

[FlyGoat]

To be honest I have no idea on the root cause. Will try to make a couple of improvements but can't promise on this problem.

[Gelip]

@2W10 Disconnect all USB flash drive from USB port and run CSMWrap from FAT32 partition on SATA disk - best using UEFI Shell. I use UEFI Shell 1.0, CSMWrap.efi efafa75-CSMWrap-34ee5ec

[2W10]

Ok so here's smth I found out

When I used an old Dell usb keyboard and detached the type cover I was able to use the Dell keyboard

However MS-DOS still did not boot. I will try windows 7 x86

Update: it now hangs on the seabios version number. Seems like it doesn't Like NTFS lol

But weirdly with dos it always gets further in the boot process after a few reboots

[2W10]

is there a way to debug?

[Gelip]

@2W10 Do you use CSMWrap AHCI path - efafa75-CSMWrap-34ee5ec ? Version 1.2.0 and other not works - only this version work: https://github.com/FlyGoat/csmwrap/actions/runs/15173994519

https://github.com/FlyGoat/csmwrap/issues/14#issuecomment-2899432822

https://github.com/FlyGoat/csmwrap/issues/14#issuecomment-2900465894

   Version 1.2.0 not work with AHCI on Asus H61
Yes, the fix was introduced after 1.2.0 release.

[2W10]

wdym ahci path?

[2W10]

just tried it — still same error

[Gelip]

wdym ahci path?

On my Sandy Bridge PC is AHCI Timeout error and CSMWrap not work without patch: https://github.com/FlyGoat/csmwrap/issues/14#issuecomment-2889000170

[2W10]

ok what patch did u use

[Gelip]

https://github.com/FlyGoat/csmwrap/commit/34ee5ec9b66b5a85c1774f9265300091812f37d7

[2W10]

yea I used this ver It didn't work But like what patches did you use alongside csmwrap.efi

[NS-Clone]

Surface Pro 1 does not have native csm?

[FlyGoat]

Surface Pro 1 does not have native csm?

Yes, it's UEFI Class 3. I own Surface Pro 1 back in days......

[NS-Clone]

Surface Pro 1 does not have native csm?

Yes, it's UEFI Class 3. I own Surface Pro 1 back in days......

just several hours ago ask chatgpt about csm tablets :rofl:

[2W10]

I found this on MSFN. Is this true??????:

Posted in CSMwrap - boot CSM on UEFI only systems. A Detailed “For Dummies” Guide to Why CSMWrap Only Works with CSM-Enabled Firmware

1. CPU Modes 101 Real Mode (16-bit): The original x86 state. Uses segment:offset addressing (e.g. 0x0000:0x7C00), can directly access hardware ports and BIOS interrupts (like INT 13h for disks). Protected Mode (32-bit) & Long Mode (64-bit): Modern OSes run here. UEFI loaders put you into protected/long mode, identity-mapping the first 1 MiB so firmware data structures remain reachable—but you’re still in 32/64-bit mode. Key takeaway: SeaBIOS’s disk routines are 16-bit real-mode code and cannot execute inside 32/64-bit mode.

2. What CSMWrap Needs to Do

3. Switch the CPU from 64-bit back into 16-bit real mode

4. Set up an Interrupt Vector Table (IVT) so INT 13h jumps into SeaBIOS code

5. Execute I/O port instructions in that real-mode stub to talk to hardware Without all three, there is no BIOS-style disk service.

6. The “Thunk”: Jumping Back to Real Mode A thunk is a tiny stub that: • Saves registers/segment state
   • Clears CR0.PG (paging) and CR0.PE (protected-mode enable) → CPU drops to real mode
   • Jumps to a 16-bit entry in SeaBIOS
   • After disk work, restores CR0 bits → back to 64-bit mode
   • Restores registers → resume UEFI code
   In CSMWrap this is implemented in x86thunk.c.

7. Why CSM Matters

Feature	CSM-Enabled Firmware	Pure-UEFI Firmware
Real-mode stub (“thunk”)	✔ firmware provides a stub or leaves CR0 togglable	✖ firmware locks CR0.PG/PE → faults on toggle
IVT setup	✔ firmware or stub initializes legacy IVT at 0x0000	✖ IVT remains empty (zeros)
INT 13h hook	✔ IVT entries point to BIOS ROM code	✖ no IVT → no entry point

CSM-Enabled firmware either ships a real-mode stub or leaves CR0 bits clear, plus sets up an IVT pointing INT 13h at BIOS ROM. Pure-UEFI firmware typically locks CR0 bits so any attempt to clear them faults, and never sets up an IVT in the first 1 MiB.

5. The INT 13h Story With CSM: At boot, IVT[0x13] → firmware’s BIOS ROM. CSMWrap can override or chain to it. UEFI-Only: IVT is all zeros. Even if you could run real-mode code, there’s no vector telling CPU where to go on INT 13h. CSMWrap therefore must allocate the legacy region, write its own IVT entries, and install SeaBIOS’s handlers—but only if it can actually execute in real mode.

6. Putting It All Together

7. Identity-map 1 MiB (UEFI spec) → always ✔

8. Real-mode entry (CR0 toggle) → only ✔ with CSM, ✖ without

9. IVT present → only ✔ with CSM, ✖ without

10. SeaBIOS run → only possible if both (2) and (3) are ✔
    No CSM ⇒ CR0 locked + no IVT ⇒ no way to run SeaBIOS ⇒ no BIOS disk services.

11. “But the CPU Always Supports Real Mode!” True, but firmware can program the CPU and chipset so software can’t switch modes. Pure-UEFI boards do exactly this: they lock CR0.PG/PE, preventing any drop into real mode.

12. No “Stealing” Needed CSMWrap doesn’t hijack motherboard BIOS calls—it bundles its own SeaBIOS INT 13h code. On CSM boards you override an existing IVT entry; on UEFI-only boards you’d have to create the IVT yourself—but you can’t run real mode to use it.

TL;DR CSMWrap’s magic is simply: SeaBIOS + a real-mode thunk + IVT setup. Without CSM, UEFI firmware actively blocks both the CR0 toggles needed for real mode and any IVT initialization—so SeaBIOS never gets to run, and you lose legacy disk services.

By the way: "Yes, it works on my Alder Lake N100 which shipped without CSM."

CSM is only hidden on that board. I aktivate it by myself.

@canonkong He tested win7 bit64. It can ran on pure UEFI without csmwrap.efi

Dietmar

[FlyGoat]

@2W10 I need to address this directly: the posts by Dietmar on MSFN contain completely false information.

I initially tried responding to their claims in another thread (https://github.com/FlyGoat/csmwrap/issues/14#issuecomment-2907720410), but eventually gave up. It became clear that they're simply feeding my responses to an LLM and using the AI-generated replies to spread misinformation about this project.

The evidence clearly shows that CSMWrap works on UEFI Class 3 devices, including OVMF, some Alder Lake-N and Alder Lake S systems. They've chosen to ignore this evidence entirely.

Regarding their claims in this post: the entire "firmware lock" theory is an AI hallucination. The Intel 64 and IA-32 Architectures Software Developer's Manual Volume 3A: System Programming Guide, Part 1 (section 11.9.2) explicitly states that switching back to real mode is always possible using a specific code sequence. The CR0.PG/PE bits remain read/write with sufficient privilege.

I acknowledge this project is far from perfect and may fail on some systems. I investigate issues case by case when possible, though I don't always find solutions. This is a hobby project, and I can only dedicate limited time and resource to it.

Honestly, seeing this kind of misinformation being spread about my work is really disheartening.

[NS-Clone]

Honestly, seeing this kind of misinformation being spread about my work is really disheartening.

we already seen this xphaters with their security updates thousands times... they even can waste time to make video about "how xp is unsecure in 2025 update it to win11"...