SeaBIOS not detect AHCI HDD and DVD/CD-ROM

[Gelip]

I test CSMWrap on virt-manager and AHCI works OK, but on real hardware - Asus H61 AHCI not work (SeaBIOS detect only USB stick) and I need change to IDE in CMOS setup so that SeaBIOS can detect the HDD:

[FlyGoat]

Do you have access to serial (i.e. COM/RS232) port on this machine? SeaBIOS will print out relevant log via serial (COM1) and it would be helpful to troubleshooting with those logs.

[Gelip]

Yes, I have but after Enable in CMOS and connect to other PC with Putty CSMWrap stuck on CALL16 f000:cda5 No any data in Putty - I use 115200 baudrate.

[Gelip]

OK, I found way how to enable COM in UEFI Shell - I need load 2 drivers PciSerial.efi & TerminalDxe.efi load pciserial.efi terminaldxe.efi Now logs from SeaBIOS also working: IDE mode: https://pastebin.com/zuz57zvW AHCI mode: https://pastebin.com/TrADcTxc

In AHCI mode is Timeout problem:

|77ee8000| WARNING - Timeout at ahci_port_setup:477!
|77ee8000| AHCI/0: device not ready (tf 0x80)
\77ee8000/ End thread
|77ee5000| WARNING - Timeout at ahci_port_setup:477!
|77ee5000| AHCI/1: device not ready (tf 0x80)
\77ee5000/ End thread
All threads complete.

[FlyGoat]

Thanks, that's wired tho.

I'll make a debug build for you to print more information.

[FlyGoat]

@Gelip here is the debug build.

csmwrap.efi.zip

[Gelip]

Thx. I noticed same thing on other PC - Asus B85 (CPU Intel Gen4 Haswell) Besides, if there is a COM port on the motherboard and it is enabled in CMOS then CSMWrap gets stuck on the CALL16 f000:cda5 on screen - SeaBIOS UI is not displayed but probably start.

[FlyGoat]

Thx. I noticed same thing on other PC - Asus B85 (CPU Intel Gen4 Haswell) Besides, if there is a COM port on the motherboard and it is enabled in CMOS then CSMWrap gets stuck on the CALL16 f000:cda5 on screen - SeaBIOS UI is not displayed but probably start.

Is there anything on serial when it got stuck?

[Gelip]

OK, I already know how it works. If there is a COM port on the motherboard and enabled in CMOS, then you need to load the pciserial.efi and terminal.efi drivers under UEFI Shell before running CSMWrap.efi Now CSMWrap works OK (IDE only mode of course) - not stuck at CALL16, I see SeaBIOS UI and Windows boot OK. In C0000 memory is loaded SeaVGABIOS:

Running option rom at c000:0003
Start SeaVGABIOS (version rel-1.15.0-0-g2dd4b9b-dirty-20211209_153523-nico)
VGABUILD: gcc: (Debian 10.2.1-6) 10.2.1 20210110 binutils: (GNU Binutils for Debian) 2.35.2

CSMWrap DEBUG version displays a lot of data e.g.

enter handle_15:
   a=00008700  b=00000000  c=00000010  d=e00f9300 ds=0000 es=0000 ss=de80
  si=00006de8 di=00000010 bp=00006e2a sp=0000fc6e cs=c000 ip=0243  f=0003

or

Got key 0 0

DEBUG version produce too big .log ~600KB and this exceeded the maximum size of 512 kilobytes per Paste on pastebin.com https://www.mediafire.com/file/xi345b2uu3kybsn/CSMWrap_AHCI_Debug.log/file

[Gelip]

Regarding the AHCI problem, I found a similar one and it is a SeaBIOS problem: https://seabios.seabios.narkive.com/gyejagh2/coreboot-i945-ahci-timeout-with-crucial-m4-ssd-2-5-in-on-cold-boot

It is also reproducible on the Lenovo T60 with coreboot from four years
ago and SeaBIOS 1.7.0-91-g7a39e72.
The drive is detected correctly on the ASRock E350M1 with coreboot and
SeaBIOS 1.7.5.

Maybe SeaBIOS need patch for AHCI: https://github.com/coreboot/seabios/blob/master/src/hw/ahci.c

#define AHCI_REQUEST_TIMEOUT 32000 // 32 seconds max for IDE ops
#define AHCI_RESET_TIMEOUT     500 // 500 miliseconds
#define AHCI_LINK_TIMEOUT       10 // 10 miliseconds
...
/* wait for device becoming ready */
    end = timer_calc(AHCI_REQUEST_TIMEOUT);
    for (;;) {
        tf = ahci_port_readl(ctrl, pnr, PORT_TFDATA);
        if (!(tf & (ATA_CB_STAT_BSY |
                    ATA_CB_STAT_DRQ)))
            break;
        if (timer_check(end)) {
            warn_timeout();
            dprintf(1, "AHCI/%d: device not ready (tf 0x%x)\n", port->pnr, tf);
            return -1;
        }
        yield();
    }

[FlyGoat]

Maybe somewhat related to this: https://mail.coreboot.org/hyperkitty/list/[email protected]/thread/RDNRKWBN4N5XQX2TQMM5P4WZ2OOPPNAM/

[FlyGoat]

Hi @Gelip,

Sorry for hijacking this topic, it seems like there are some misunderstanding in MSFN thread stating that CSMWrap doesn't support INT13h emulation. I guess this conclusion was drawn up on some AI generated BS.

The truth is all BIOS interrupt service, including INT13h are always handled by SeaBIOS which is a part of CSMWrap. If there is any problem on recognising boot device, it might be caused by this issue, or ARL's PCI issue, or maybe another SeaBIOS driver issue.

I don't have MSFN account so I can't reply, do you mind to help me to clarify on MSFN? Maybe just guide people to this issue.

Thanks

[FlyGoat]

Can you try this build?

https://github.com/FlyGoat/csmwrap/actions/runs/15173994519

[Gelip]

@FlyGoat Yeeeeeeeeeaaaaa! This works on Asus H61 :-) 👍

But on Asus B85 other problem and don't detect any boot devices - stuck on SeaBIOS (version efafa75-CSMWrap-34ee5ec)

Version 1.2.0 not work with AHCI on Asus H61

[FlyGoat]

But on Asus B85 other problem and don't detect any boot devices - stuck on SeaBIOS (version efafa75-CSMWrap-34ee5ec)

Thanks for reporting back!

Is this a regression? Was ASUS B85 working before?

I suspect it's somewhat related to #25 as Surface Pro 1 is Haswell as well.

Version 1.2.0 not work with AHCI on Asus H61

Yes, the fix was introduced after 1.2.0 release.

[Gelip]

Is this a regression? Was ASUS B85 working before? No, from version 1.0.0 CSMWrap does not work on ASUS B85 (Haswell)

[FlyGoat]

Is this a regression? Was ASUS B85 working before? No, from version 1.0.0 CSMWrap does not work on ASUS B85 (Haswell)

Do you mind to try COM debug build on this machine?

[Gelip]

CSMWrap Version 1.1.0-12-g90453305b043-dirty debug - https://www.mediafire.com/file/5tqaoapitwm661f/B85.log/file The ahci and 1.2.0 versions show the same thing in Putty: AHCI_34ee5ec - https://pastebin.com/UYxxvnEd 1.2.0 - https://pastebin.com/CqBHnfXc

[FlyGoat]

CSMWrap Version 1.1.0-12-g90453305b043-dirty debug - https://www.mediafire.com/file/5tqaoapitwm661f/B85.log/file The ahci and 1.2.0 versions show the same thing in Putty: AHCI_34ee5ec - https://pastebin.com/UYxxvnEd 1.2.0 - https://pastebin.com/CqBHnfXc

Sorry.. Forgot to attach latest debug build

csmwrap.efi.zip

[FlyGoat]

Alas, people on MSFN is still spreading misinformation, despite I tried to clarify here.

I guess they (or maybe LLM behind them) never really understood how the project work. There is NO interrupt handler redirection happening to UEFI code, but it doesn't mean int13h (and other interrupt calls) won't work. They are handled by SeaBIOS.

For misinformation in their comments:

1. No Real-Mode Environment

SeaBIOS is executing in Real Mode.

2. No Legacy BIOS ROM Code

SeaBIOS is Legacy BIOS ROM Code.

3. No IVT Vector Patching

SeaBIOS will fill IVT table, no need to do any patching.

4. No Mode-Switch Plumbing

x86thunk in CSMWrap and SeaBIOS are doing all mode switch works.

5. UEFI’s Native Disk Interface Differs Completely

Yes, that's why SeaBIOS's own disk drivers are operating after handling control to CSM module. It's talking to hardware directly.

For the int13h handler flow, the IVT vector is set at ivt_init() https://github.com/FlyGoat/seabios-csmwrap/blob/efafa7514862b2caf082329e29dd8878dfe1d63d/src/post.c#L33, which set IVT to an assembly thunk handler, and redirected to actual handle function handle_13(struct bregs *regs) https://github.com/FlyGoat/seabios-csmwrap/blob/efafa7514862b2caf082329e29dd8878dfe1d63d/src/disk.c#L741.

They also tried to provide some code that will never work in this project, PLEASE, look into current implementation, we are not even using EDK II build environment. If in doubt, they can always ask me.

[Gelip]

Sorry.. Forgot to attach latest debug build

Unfortunately, this version does not work - stuck on: CALL16 f000:cc6b

[FlyGoat]

Sorry.. Forgot to attach latest debug build

Unfortunately, this version does not work - stuck on: CALL16 f000:cc6b

That's wired, this is just current master with COM debug enabled...

No seabios message on serial at all?

[Gelip]

@FlyGoat https://pastebin.com/RFMV6ppy

[FlyGoat]

@FlyGoat https://pastebin.com/RFMV6ppy

Seems like it hangs on XHCI driver somehow. Let me review XHCI driver in SeaBIOS.

[xCuri0]

@Gelip does XHCI handoff in UEFI setup make any difference ? I have to change it for Hackintosh to work on a similar platform (it would hang too).

[FlyGoat]

@Gelip does XHCI handoff in UEFI setup make any difference ? I have to change it for Hackintosh to work on a similar platform.

Maybe! Any pointer for me to read?

Thanks

[Gelip]

Works, works, works - WinXP SP2 32-bit on Haswell using winload.exe 5472 - 640x480 :-) :-) :-)

I have to run this way:

• HDD FAT32 100MB EFI\Boot\bootx64.efi < this is UEFI Shell 1.0
• from shell need run CSMWrap (ahci.efi)

ntldr + iGPU + SeaVGABIOS -> black screen winload.exe + iGPU + SeaVGABIOS -> OK

@FlyGoat Thank you very much for this loader 👍

[FlyGoat]

@Gelip wait, what did you do to make it work? Just load it from shell instead of load directly as BootX64.EFI？

[FlyGoat]

Sorry @Gelip, could you please help me relay my message to MSFN again? https://github.com/FlyGoat/csmwrap/issues/14#issuecomment-2903984783

The guy is still trying to mislead others.

[Gelip]

@FlyGoat This is a problem with the XHCI controller. CSMWrap always gets stuck on SeaBIOS (version) when a flash drive is connected to the USB port. In order for CSMWrap to work properly, you need to run it from a FAT32 partition on hard drive. In the case of winload.exe, you have to run from UEFI Shell because otherwise I get 0xc0000017 error. In CMOS I have Intel xHCI Mode - Enabled because on Smart Auto or Auto USB often doesn't work after reboots. https://forums.mydigitallife.net/threads/winxp-64-bit-on-a-modern-pc-iso-boot-wim-install-wim.88435/#post-1845235 https://forums.mydigitallife.net/threads/drivers-and-tools-to-run-windows-xp-on-newer-hardware.81607/page-20#post-1763978 https://forums.mydigitallife.net/threads/usb-3-xhci-driver-stack-for-windows-7.81934/page-18#post-1847262

[FlyGoat]

Thanks for testing, is your USB flash disk USB2.0 or 3.0? I suspect it's somewhat related to EHCI XHCI interaction.