Jump to content

reboot12

Member
  • Posts

    440
  • Joined

  • Last visited

  • Donations

    0.00 USD 
  • Country

    Poland

Posts posted by reboot12

  1. 1 hour ago, Dietmar said:

    On CSM-enabled boards, the firmware gives you a tiny real-mode stub (the “thunk”) or leaves paging/PE bits clear so you can drop back to real mode.

    I test CSMWrap in virt-manager QEMU KVM virtual machine with 2016 OVMF UEFI 64-bit firmware OVMF_CODE-pure-efi.fd

    There are other firmware versions in the edk2-ovmf-x64-20160418gita8c39ba-1.mga6.noarch.rpm archive:
    OVMF-3-types.png

    The OVMF_CODE-with-csm.fd version includes SeaBIOS for Legacy support:
    https://github.com/tianocore/tianocore.github.io/wiki/OVMF

    Quote

    Some of these builds include a seabios CSM and can boot non-UEFI “legacy” operating systems. (Note: seabios is GPLv3 licensed.)

    Can you check if in OVMF_CODE-pure-efi.fd give real-mode "thunk"?
    https://www.mediafire.com/file/ezj7uzxix2mgs68/ovmf_x64_pure&CSM.zip/file

    .fd files can be opened in UEFITool

  2. @Dietmar

    You probably spreading misinformation - FlyGoat cannot create an account on MSFN and asked me to put such a post 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.

    Original github post: https://github.com/FlyGoat/csmwrap/issues/14#issuecomment-2903984783

  3. 8 hours ago, Dietmar said:

    I think, even in the new 1.2 version of the csmwraper there is no INT13h support,

    No, CSMWrap support all BIOS services:

    Quote

    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.

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

  4. 6 hours ago, sonyu said:

    So... maybe there is a change to boot X64 Windows in non-UEFI mode in UEFI32 baytrail?

    Yes of course. You need use CSMWrap ia32 32-bit version:

    OVMF32-64-bit-OS-1.png OVMF32-64-bit-OS-2.png

    P.S. I purposely bought such a laptop - Asus T100TAF for testing but I bricked it when I changed the hidden settings in CMOS - I need reprogramming bios - probably need desolder SPI chip:
    https://www.elektroda.pl/rtvforum/topic4120094.html

    My tests before CSMWrap was released: https://forums.mydigitallife.net/threads/winxp-32-bit-on-a-modern-pc-iso-boot-wim-install-wim.88834/#post-1873937

    Many laptops with UEFI32 have an eMMC drive - I don't know if there will be a problem with that. If the laptop has a normal SATA drive it should be OK.

    @Dietmar

    Do you still have Lenovo Flex 10 with UEFI32?

  5. Test this build: https://github.com/FlyGoat/csmwrap/actions/runs/15122472115

    Memory Remap Enabled, Asus H61 SandyBridge, PCIe AMD6450 VBIOS AMD from this card:

    WinXP SP2 32-bit - ntldr+NTDETECT.COM > 0K low memory:
    https://github.com/FlyGoat/csmwrap/issues/7#issuecomment-2892732313
    spacer.png

    Same WinXP but Longhorn 5472 winload.exe loader boot but on screen stuck aurora bootscreen:
    aurora.jpg
    Screenshot over Remote Desktop:
    spacer.png

    P.S. If remove PCIe card and use iGPU then VBIOS is SeaVGABIOS

  6. No, You need run AMISCE tool for your platform or newer with /d option in UEFI Shell then generate CMOS settings to .txt file:

    sceefi64 /d /o /s CMOS.txt

    As I remember correctly I already explained to you recently (about unlock CSM in yours Intel Gen12 mobo) and I think I even sent for you AMISCE tool.

    Yes, I found in topic Compiling ACPI v2.0... https://msfn.org/board/topic/183464-compiling-acpi-v20-driver-for-windows-xp-sp3-and-windows-2003-sp2-x32x64/page/133/#findComment-1266974

     

  7. not.png

    But I do not need change remap on this way because I have normal option in CMOS Setup:
    remap-CMOS.png

    I can also change this with ru.efi in the UEFI Setup variable at the appropriate offset:

    Setup Question    = Memory Remap
    Token    =2E3    // Do NOT change this line
    Offset    =33B
    Width    =01
    BIOS Default    =[01]Enabled
    Options    =*[01]Enabled    // Move "*" to the desired Option
             [00]Disabled

    Offset is 33B then in ru.efi need change like this:
    Setup-ru.png

  8. @Dietmar

    F..k, why don't you read the previous posts? :}

    3 hours ago, Dietmar said:

    and this version on winload.exe crashes

    What crash - like this?
    bad-BCD1.png
    Sorry, I forgot to write that you need to correct 2 entries in BCD - ApplicationDevice and OSDevice:
    bad-BCD2.png bad-BCD3.png bad-BCD4.png

    After fix BCD WinXP boot OK:
    virt-manager-VGA-virtual-GPU.png virt-manager-VGA-virtual-GPU2.png

    P.S. CSMWrap support AHCI and works OK on virt-manager:

    virt-manager-AHCI.png virt-manager-AHCI2-png.png

    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:
    AHCI:Asus-H61-AHCI.jpg IDE:Asus-H61-IDE.jpg

  9. Test, test, test and noticed that CSMWrap works differently on each machine or does not work:

    • virt-manager - wrapper work, XP32 need Longhorn 5472 loader - tested AMD6450 driver but probably work also on vga.sys
    • Asus H61 (iGPU 2gen) - wrapper work, SATA mode IDE, XP32 need Longhorn 5472 loader and work on vga.sys
    • Asus B85 (iGPU 4gen) - wrapper run but stuck on CALL16 - not start SeaBIOS
    • AIMB-786 (CPU 8Gen, PCIe AMD7450) - wrapper work from NVMe MBR disk, SATA mode AHCI, XP64 boot on standard ntldr + NTDETECT.COM :rolleyes:
      Quote

      1.0.0

      Initial Release!

      Booting FreeDOS and Windows XP/7 is possible in QEMU and some physical machines.

      Full E820/SMBIOS/ACPI support

       

  10. Yeeeeeeaaaaaaaaaaa!!! This works :cheerleader::rolleyes::worship:

    First time WinXP 32-bit on UEFI 64-bit using CSMWrap 1.1.0

    virt-manager QEMU on Debian 9, OVMF_CODE-pure-efi.fd 64-bit 2016, passthrough PCIe AMD6450 graphics card (drivers installed), bootmgr + winload.exe 5472 x86 (patched) + BCD

    Virtual graphics card VGA - stuck on aurora boot screen but WinXP work on AMD 6450:
    5472-x86-winload-exe-patched-amd6450.png 5472-x86-winload-exe-patched-VGA-QEMU.pn CSMWrap.png virt-manager-Debian9.png

    Test on real hardware Asus H61 iGPU - works in safe mode in 800x600 on vga.sys - GUID 23A set to 800x600 60Hz
    safe-mode-asus-h61.jpg

    If change GUID 23A to e.g. 3840x2160 1Hz then safe mode work in 1024x768:
    safe-mode-GUID23-A-high.png

×
×
  • Create New...