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

The 'ljmp' issue: at last a solution?

On Tue, 2 Jun 1998, Joel Sherrill wrote:

> On Tue, 2 Jun 1998, Pedro Romano wrote:
> > I got this working with beta3. I haven't tested it with the newest
> > snapshot, cause I haven't had a chance to download it yet.
> It should not make that much of a difference.  start16 is mostly
> independent of the rest of the BSP.  
> > and try it. I believe this is a much cleanier way to do it, amd I don't
> > think I'll ever find a better way of doing it.
> This is as good a way as any. It is clear and simple.
> Unfortunately, it still resets.  I will enable the speaker again and
> verify that it is going right up to the return but not getting to the
> 32-bit start code.
> Did any of the things Eric V. mention make sense as potential problems?

In which post? The last two seemed to be directly related with this
> > 0x97e24 is the offset into the 'bin2boot' header where the address of the
> > image is stored. I'm changing this into a constant passed at compile time
> > so the header can change place. For now it should do the trick. I'll send
> > a patch later against the newest snapshot if I get it to work.
> I was wondering how you got this number.  It would be nice if you could
> make it clear where this came from.  Is there any way this number is
> incorrect for me locally?

The advantage of this approach (I'll be changing 0x97e24 to preprocessor
constants, as I've mentioned) is that you won't have to re-compile
'start16.s' anymore after you change the start address of the main image!
Until now you had to since it was hardwired into start16.s.

The important defines in 'pc386.cfg' are:

  RELOCADDR=0x00100000 - start address of main image (relevant for both
                         GRUB and netboot

and the following which are only relevant to netboot:

START16ADDR=0x00097C00 - start address of 16 bit startup code
 HEADERADDR=0x00097E00 - start address of 'bin2boot' header

If you haven't changed these in 'pc386.cfg' it shouldn't be causing

If you manage to have the speaker beep in 'start16.s' it's because it is
getting there and there is some problem before jumping to the 32 bit code.

I've downloaded the latest snapshot and will try it myself.

> --joel