NetBSD-Bugs archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

port-i386/58624: dosboot(8) fails to load kernel through eXtended Memory Specification API (XMS)



>Number:         58624
>Category:       port-i386
>Synopsis:       dosboot(8) fails to load kernel through eXtended Memory Specification API (XMS)
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    port-i386-maintainer
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Wed Aug 21 21:20:00 +0000 2024
>Originator:     Andrius V
>Release:        NetBSD 10 and lower
>Organization:
>Environment:
>Description:
Distribution provides a dosboot.com application which allows to load kernel in real mode. It works, when DOS is not loaded with so called eXtended Memory Specification (XMS) API support, but fails if it does. dosboot.com application, if detected, will use XMS code, however it seems to be broken for ages (likely after "Merge XMS changes from exec_fromdos.c" in this commit https://github.com/NetBSD/src/commit/e58bb7948317c81664b47ff2d86b21df13f69251), potentially worked back in 1.3.x releases. Currently bootloader reboots on ppbcopy() call (https://nxr.netbsd.org/xref/src/sys/arch/i386/stand/lib/exec.c#450). There are some multiple problems I can observe now:

1) https://nxr.netbsd.org/xref/src/sys/arch/i386/stand/lib/exec.c#446 has duplication loadaddr subtraction for MARK_END and no for MARK_ENTRY and MARK_DATA, likely this part should be similar to efi part:
		marks[MARK_START] -= loadaddr;
		marks[MARK_ENTRY] -= loadaddr;
		marks[MARK_DATA] -= loadaddr;
		marks[MARK_SYM] -= loadaddr;
		marks[MARK_END] -= loadaddr;

or at least MARK_END not subtracted twice.
2) origaddr passed to ppbcopy() is 0x0, since original loadaddr is 0 coming from the dosboot main(), which seemingly causes reboot. I would assume this value should not be 0.

3) As a result of passing higher, code will reach startprog(), but will either hang or reboot (I assume entry is not calculated properly). 

And at this point I am already not sure how to move forward besides wild guesses with little chance of successful results.

This bug has a negligible priority, considering nobody really complained in years, and unlikely booting netbsd from DOS in real mode is preferred way for any imaginable reasons, but application is still provided and works in certain conditions, described above... Maybe somebody will have an interest in fixing XMS code too.
>How-To-Repeat:
The way I was testing by running qemu with FreeDOS 1.3 installed:
qemu-img create c.hd 100M
qemu-system-i386  -hda c.hd -cdrom FD13LIVE.iso -boot d
install FreeDOS to HD
create and mount c.hd on vnd0 
mount /dev/vnd0e /mnt
copy dosboot.com and any i386 kernel (e.g. install)
qemu-system-i386 -hda c.hd -boot d
Choose "4 - Load FreeDOS low with some drivers (Safe Mode)" in FreeDOS booloader selection menu
(should load DOS in real-mode with XMS)
dosboot.com netbsd 
observe reboot

As alternative
"5 - Load FreeDOS without drivers (emergency mode)"
dosboot.com netbsd will boot system successfully (XMS code is not used).
>Fix:



Home | Main Index | Thread Index | Old Index