FreeDOS boot hangs at "Loading FreeDOS 123" on Intel Atom Z3735F (Bay Trail) device with ia32 UEFI

[volkertb]

The Intel Atom Z3735F ("Bay Trail") SoC, which shipped a decade ago on a number of low-power and budget devices, such as the Intel Compute Stick and a number of tablets, is notorious for having an ia32 UEFI, even though the CPU is perfectly capable of running 64-bit software. It also didn't come with a CSM, so out of the box, it usually only shipped with the 32-bit editions of Windows 8, Windows 10, or Ubuntu Linux.

Later versions of the most common 64-bit Linux distros (Ubuntu, Fedora, Arch Linux) later gained the ability to boot and run on these devices through some kind of shim/thunking solution, even though the UEFI was 32-bit.

It was still not possible to boot 64-bit versions of Windows 10, or (pre-UEFI) Windows versions older than Windows 8.

With the IA-32 build of CSMWrap, however, this should now be possible. (Thanks again for making this!)

So I tried CSMWrap 1.2.1 (ia32) on my Bay Trail device. The good news is that it successfully loaded SeaBIOS, it accepted input from the USB keyboard that I had attached to it, and it appeared to support booting either from the integrated eMMC drive or from a USB drive.

The bad news is that FreeDOS appears to hang on boot, at the message Loading FreeDOS 123.

Pressing CTRL-ALT-DEL did not help. The system appeared to be completely locked up at this point. I've tried booting it more than once, but I never got past the Loading FreeDOS 123 message.

I did some googling for this message, to see whether this was a common problem separately from the whole UEFI/CSM thing, but I couldn't find anything after a few minutes of searching.

The FreeDOS image that I tried was the FullUSB IMG file of FreeDOS 1.4, extracted from FD14-FullUSB.zip, and written to an SD card with the dd command-line tool. I had that SD card plugged into a USB SD card reader, which I had plugged in to the device through a USB hub, since SeaBIOS unfortunately did not detect the SD card when I had it inserted in the integrated SD card slot of the device.

Below I'm attaching a video of the failed boot attempt. You can see that I have also installed the rEFInd boot manager on the device, which appears to launch CSMWrap just fine.

It from what I briefly saw from the output while loading SeaBIOS, CSMWrap was unable to locate a legacy VGA Option ROM on this device, and so fell back to the SeaBIOS fallback VGA ROM. I hope to find a compatible ROM that adds actual native legacy VGA compatibility to this device, but I don't think this SoC ever shipped with a CSM in any device.

But it would be nice if we can get FreeDOS to at least boot in text mode.

Thanks for your continued work on this amazing project!

https://github.com/user-attachments/assets/9499eace-131e-4a3f-a829-91ce0886e59e

[FlyGoat]

I would suspect it's something related to SD Card, can you try a proper USB flash disk?

I see a somewhat related post: https://www.vogons.org/viewtopic.php?t=53743

I recall baytrail lacks some legacy IO port support, maybe that's the problem. Can you try other OS? e.g. Modern Windows/Linux.

Thanks

[Gelip]

To volkertb Wow. If you want you can test my WinXP 32-bit tutorial - I added eMMC drivers: https://forums.mydigitallife.net/threads/winxp-32-bit-on-a-modern-pc-iso-boot-wim-install-wim.88834/ https://forums.mydigitallife.net/threads/winxp-32-bit-on-a-modern-pc-iso-boot-wim-install-wim.88834/#post-1873965

I found VBIOS for BayTrail: https://github.com/FlyGoat/csmwrap/issues/37#issuecomment-2921265627

[volkertb]

@Gelip Thanks for sharing. I'll go into that further in that thread. 👍🏽

[volkertb]

I would suspect it's something related to SD Card, can you try a proper USB flash disk?

I just tried it with a USB stick (not an SD card), containing a bootable FreeDOS 1.3 image (one release earlier than the FreeDOS 1.4 image on the SD card that failed earlier). The result is unfortunately very similar:

I recall baytrail lacks some legacy IO port support, maybe that's the problem. Can you try other OS? e.g. Modern Windows/Linux.

First I'll try some other DOS variants (SvarDOS and MS-DOS), to see what result I get with those. I'll try some older Windows versions after that.

I'll also try CloverBootloader, as a way to get a 64-bit UEFI working on this device. (32-bit native UEFI -> CSMWrap -> Clover 64-bit UEFI)

I'll let you know what my results are.

[Gelip]

volkertb - why do you need UEFI 64-bit? UEFI32 > CSMWrap > UEFI64 > CSMWrap > FreeDOS ????? This is stupid and that's probably why FreeDOS isn't working for you.

Try like this: UEFI32 > CSMWrap32 > FreeDOS

[FlyGoat]

Yes, this is likely irrelevant to EFI bitness.

I'd recommend trying a modern OS to get some debug information.

[volkertb]

@Gelip My proposed Clover trick is not for booting DOS. It's for booting the 64-bit version of Windows 10 on Bay Trail devices with a 32-bit UEFI. Clover is indeed not needed for FreeDOS, or any DOS for that matter. Sorry if I caused any confusion there.

[volkertb]

@FlyGoat I ultimately managed to boot SvarDOS successfully. However, the boot process is quite unstable, regularly hanging in different phases of the boot process or while loading the DOS kernel, sometimes not detecting the USB device, or suddenly automatically rebooting while loading the DOS kernel. Also, the fact that I had two (quite populated) USB hubs daisy-chained to the Bay Trail device didn't help. After I had plugged in just one USB hub with only a USB keyboard and the populated USB SD card reader, it would work about one out of 10 times or so. Also, the device would sometimes hang before it even loaded the rEFInd boot manager that I installed on it, which should have nothing to do with CSMWrap.

But, 1 out of x times it does work, so that in and of itself is already impressive. Good work! 😃

As you can see from the video, screen updates during scrolling are very slow. Of course it has to constantly redraw all the characters to the GOP framebuffer in software. Also, when I ran the SvarDOS installer, it just showed an empty blue screen. Pressing the Escape key brought me back to the command prompt.

My guess it that this device would boot more reliably if the bootable DOS partition were installed on the integrated eMMC as opposed to a USB drive. But it will take me some more work to set that up.

https://github.com/user-attachments/assets/38651e81-03f0-4491-bf7e-624a600dc05d

[Gelip]

volkertb - try this Win10: https://windowsxlite.com/Micro10_x86_SE/

[volkertb]

OK, so I hooked up a USB Blu-ray drive through the USB hub, and it gets detected on each start, without any weird hangs before getting into the rEFInd menu. Also SeaBIOS appears to detect it on each boot. This is unlike the flaky behavior that I experienced with the USB flash drive and the populated USB SD card reader, that I'd been trying before.

I tried booting the installers of multiple operating systems on optical media.

Here are my findings.

• Windows XP x64 Edition: within seconds when the CD starts booting after selecting the optical drive in the SeaBIOS boot menu, the screen goes black and the system is unresponsive.

• OpenSuse 11.3 (an OS installation CD-ROM I got with a magazine in 2010): It boots into the boot menu of the installation CD, but it does show the message graphics initialization failed. Apparently, it tried to show a graphical boot menu with a splash screen. The boot menu shown is apparently some text mode fallback menu. I can enter any of the boot options at the boot : prompt, but none of them work and result in a hanging system. In the case of booting the live system, I get a black screen, as I did when I tried to boot the Windows XP x64 Edition installation disc. Ditto when I enter mediacheck. When I enter memtest, part of the screen goes black, some text on the side of the screen is still visible, but the system hangs at that point.

  

• Windows 8 64-bit installation disc: shows the blue Windows 8 logo for a while, and then shows an error message with a blue background. It offers me a menu, but none of the options that I try selecting get me any further than the error.

  

  

  

The error code displayed, 0xc0000225, apparently means that it couldn't find certain boot/system files, or that they are corrupted. The installation disc looked fine, and I've rarely used it.

• Windows 8 32-bit installation disc: as expected, this CD also shows up as a boot option in rEFInd, since it's actually designed to natively boot from 32-bit UEFI systems. And booting it that way, the installer comes up fine. But when booting it through CSMWrap, I initially get the same (off-center) boot logo as I did with the 64-bit disc, followed by another error message, this time without a blue background or any possible menu options to select. It specifically shows error code 0X0000005C, which apparently means HAL initialization failed and apparently is something driver-related, or a problem with expecting certain subsystems (APIC). At least, that's what a quick Google search yielded me.

  

  

It would seem that Windows XP x64 Edition and OpenSuse 11.3 are so old that they simply won't work if there is no actual legacy VGA compatibility, whereas Windows 8 was new enough that it accessed graphics through VBE, so it would work with the GOP framebuffer. But apparently there are still some other things missing (or different) that both the 64-bit and 32-bit variants of Windows 8 are unhappy with for some reason.

I hope this is useful!

[volkertb]

By the way, sorry for the dust particles on the monitor in those pictures. I really should clean it. 😅

[win98se]

For Windows 8.1 x86, I have the exact same 0x0000005C error (even parameters are exact same) after DISM applying install.wim to the internal storage. However, my device (Asus Transformer Pad TF103C) has a Z3745 instead (it has a 64-bit UEFI without any Legacy booting option).

P/S: Installing Windows 8.1 x64 by native UEFI works, but it doesn't have any usable driver.

[Gelip]

@volkertb I compile CSMWrap replacing SeaVGABIOS to ValleyView Legacy video BIOS but risky to use because it can reportedly damage the screen.

[xCuri0]

@Gelip

This is unlikely to work because every Intel iGPU VBIOS is specific to each motherboard because of connector differences and stuff. You can use Intel BMP tool to fix this though, there are many guides for this.

https://winraid.level1techs.com/t/guide-transfer-of-specific-intel-orom-vbios-and-gop-vbt-settings-by-using-intel-bmp-tool/30930

EDIT: Reading through this it might be a bit tricky to transfer the setting from GOP-only ROM to legacy option ROM. Still should be possible though because you can find downloads for the tools OEM use to set the VBT connector options and stuff.

[Gelip]

This is unlikely to work because every Intel iGPU VBIOS is specific to each motherboard because of connector differences

That's why I wrote 99%, but I think that on some computers it should work.

I use an AMD6450 graphics card with GOP firmware from a similar model AMD7450 and it works OK. Similarly, @dietmarpapagei1 sent me a bios from Arrow Lake Gigabyte B860 DS3H, I extracted the GOP (22.0.1057) and found the same GOP in many others motherboards: Z890M AORUS ELITE WIFI7 ICE, MSI MS-CF20: https://ipc.msi.com/en/product_download/Industrial-Motherboard/ATX/MS-CF20 https://ipc.msi.com/en/product_detail/Industrial-Motherboard/ATX/MS-CF20

If GOP fits different motherboards then legacy VBIOS too.

[xCuri0]

@Gelip the link I sent says intel iGPU GOP stores the VBT (connectors and stuff) in another section of the UEFI firmware (which they say how to read/write), that will probably differ.

[Gelip]

the link I sent says intel iGPU GOP stores the VBT (connectors and stuff) in another section of the UEFI firmware (which they say how to read/write), that will probably differ.

After all, the graphics are integrated in the processor and the same processor can, after all, be installed in many different motherboards.

I will look for Haswell motherboard bios like mine and compare if the graphics bios is different or identical.

May not fit if video bios is Mobile or Desktop type - edited > No - Intel makes universal Mobile/Desktop bios:

[win98se]

baytrail_x64.efi almost works on my TF103C! But the graphics are glitched, and after spinning for a while, it finally BSoDed (and I can't even read the error code) -

[win98se]

I don't know if it's useful for you, but here is the UEFI of the TF103C (compressed to ZIP) - capsule_fdk_edk2.zip

[xCuri0]

Probably a Intel VBT issue like I said, if there's a mismatch it would be an issue like this. CSMWrap should support reading option ROM file soon could try some experiments then.

[Gelip]

@win98se What is PCI Vendor Device? Maybe PCIR not fit? My CSMWrap BayTrail have PCIR 8086 0F31 https://devicehunt.com/view/type/pci/vendor/8086/device/0F31 > Atom Processor Z36xxx/Z37xxx Series Graphics & Display

[win98se]

@win98se What is PCI Vendor Device? Maybe PCIR not fit? My CSMWrap BayTrail have PCIR 8086 0F31 https://devicehunt.com/view/type/pci/vendor/8086/device/0F31 > Atom Processor Z36xxx/Z37xxx Series Graphics & Display

I have the same PCI vendor & device IDs as yours, PCI\VEN_8086&DEV_0F31 - (The title of the device [that doesn't have any driver installed, because I'm in Windows PE] says Video Controller (VGA Compatible))

[Gelip]

@xCuri0 @win98se xCuri0 may be right. It seems that the VBT table can be extracted from the GOP and insert to VBIOS:

[xCuri0]

Don't hex edit it, there are proper tools for this that win-raid link should say how to do it.

[Gelip]

@xCuri0 Yes, you right: https://winraid.level1techs.com/t/guide-transfer-of-specific-intel-orom-vbios-and-gop-vbt-settings-by-using-intel-bmp-tool/30930/288

Unfortunately not. You cannot take the GOP VBT file from another model and use it with you. It is necessary to configure GOP VBT personally.

but where download BSF script for ValleyView? .DAT = VBIOS 55 AA

I have VBios'es and BSF's for many generation but not for ValleyView:

[Gelip]

@win98se But on normal version CSMWrap 1.2.1 black screen?

[xCuri0]

If you could find a legacy ROM with the exact VBT version you may be able to directly swap the VBT tables without any issues, atleast win-raid says you can. Though the UEFI version contains more settings which might be an issue

@win98se you should stop trying to boot with this incorrectly configured option ROM, it could damage the screen because of incorrect timings, etc.

[xCuri0]

@Gelip

Ignore the previous comment I deleted.

Found an actual Valley View BSF here edk2-non-osi/blob/master/Silicon/Intel/Vlv2SocBinPkg/GOP/7.2.1011/VBT/MNW2/vbt.bsf

It still doesn't seem to work correctly, displays even more red pages than the Bay Trail one both with the tablet VBT and legacy ROM. Probably because of differing versions ?

At the bare minimum will have to transfer all the display settings for it to work correctly, I'll see what intel_vbt_decode and other tools from intel-gpu-tools say because BMP is being problematic.

[win98se]

@win98se But on normal version CSMWrap 1.2.1 black screen?

On normal CSMWrap 1.2.1, the display works OK; Although it doesn't even spin and directly shows the error on second pic -

@win98se you should stop trying to boot with this incorrectly configured option ROM, it could damage the screen because of incorrect timings, etc.

I've only used it once just for testing.

[xCuri0]

@Gelip @win98se

Output of intel_vbt_decode --file=VBT.bin --devid=0f31 --all-panels for both VBTs. I used WSL Ubuntu 24.04 for intel_vbt_decode

vbt_decode_tablet.txt vbt_decode_legacy.txt

Do a diff compare of the two.

You can see the tablet one has information on the panel and even tells the model name, B101UAN01.7. It apparently uses MIPI unlike the usual eDP or LVDS laptops use.

I think the best chance of getting this working would be to find a legacy ROM which matches the version exactly and then hex editing this tablet VBT in. There should be zero difference besides the display stuff otherwise it likely won't work

The offset for the version number is at 0x40 from start of VBT btw.

Unfortunately besides Intel BMP there isn't any tool to rebuild the VBT I could find, intel_vbt_decode only can read. So we can only replace the whole thing and not do any selective edits easily.