On Thu, Apr 10, 2014 at 3:40 AM, David Laight <[email protected]> wrote: > On Wed, Apr 09, 2014 at 09:10:42AM -0500, John D. Baker wrote: >> On Wed, 9 Apr 2014, John D. Baker wrote: >> >> > disk, the last part of the display actually looked like: >> > >> > prot_to_real: can't return to 0001296DFn: Diskn >> >> Should have been: >> >> prot_to_real: can't return to 000129CD Fn: Diskn >> >> The amd64-built version behaves the same. The only difference was the >> address reported in the message above: 00012D19 > > All the calls to 'prot_to_real' have to reside in the first 64k of > the code area. > The code them bombs out back to the outer loader.
s/prot_to_real/real_to_prot/ http://nxr.netbsd.org/xref/src/sys/arch/i386/stand/boot/Makefile.boot#131 This is quite a hack... > The linker used to manage that, but it might have been relying > on the linker putting object files into a section in the order they > were specified on the command line. > > Plausibly prot_to_real could set the real mode $cs value to one > appropriate for the return address. > The calls are all from assembler and are followed by a bios call > and then a call to real_to_prot. > > If that were done the /boot code itself could probably be linked with a > virtual base address of 1MB and run with virtual == physical removing > the confusing offset. > > David > > -- > David Laight: [email protected]
