AW: Booting RTEMS PC386 via dos prompt

[John Bebbington]

John Bebbington wrote:

>>I have been looking at eXtender by Luca Abeni from
>>http://freedos-32.sourceforge.net/downloads.html  but had no luck so far.

Angelo Fraietta wrote :

>If you find one, let me know as this is something I would like to do
because it would allow me to write
>to the hard drive for firmware updates before booting. I don't think that
there is a PC386 FAT/IDE driver >fro RTEMS yet.
>
>Angelo Fraietta

----------------------------------------

Things have developed a bit since the initial question and with a lot of
help from Luca Abeni.


Luca wrote:

>Hi John,
>
>I was finally able to isolate the problem (I think...), it seems that your
program expects
>to be called with a valid stack, and it relies on this stack.
>
>But x.exe happens to call your code leaving ESP=0. Hence, the first ret
instruction gives problems,
>returning at a random address...
>
>If I understand well, this is not a bug in x.exe, since the MultiBoot
>standard says:
>``The OS image must create its own stack as soon as it needs one''.
>
>This means that you are not allowed to perform any call/ret before setting
>up your stack. If I understand your code well, you set up the stack in
>_establish_stack (address 0x00100014); the problem is that next_step
>(address 0x001022f5) calls _pc386_delay some times before jumping to
>_establish_stack...
>
>Everything happens to work with GRUB because GRUB jumps to your OS image
>with ESP!=0, but this is not guaranteed by the standard.
>
>Ok, I am going to put a work-around in the extender (I'll send you a new
>version in few hours, but I think the best thing to do is to ``fix'' your
>program (maybe the ``bug'' is in the executive that you are linking...). I
>think that inlining _pc386_delay should do the trick (if I understand well,
>it is the only function called before setting up the stack).
>
>                     Luca


John Bebbington wrote:

>Thanks Luca,
>
>I want to tell you that the modified x.exe works just fine on the target.
>
>I would like to ask you if I could send our e-mail correspondence to a
>users-group called rtems-users at oarcorp.com. There
>are some people there who would be interested in:
>
>1) the eXtender allowing rtems programs to boot directly from dos.
>
>2) the minimal stack problem and the proposed solution to in-line the
>prerequite code before stack establishment.
>
>3) when the new version of the eXtender.exe with minimal stack will be
>available on your web-site for download.
>
>thanks again for providing this feature.
>
>regards
>
>John Bebbington.
>


Luca wrote:

I am more than happy to see people that are willing to use x.exe,
and if it can be useful to someone I am willing to help as much as I can.

>There are some people there who would be interested in:
> the eXtender allowing rtems programs to boot directly from dos.

Good. In my experience, the eXtender can speed-up the development and
testing
process (if the rtems application does not corrupt dos memory, when it
finishes it can simply return to DOS, without rebooting the system).

>2) the minimal stack problem and the proposed solution to in-line the
>prerequite code before stack establishment.

Ok. I tried to track down the problem a little more, and these are my
results (well, don't trust me too much here, because I really don't know the
RTEMS internals...):
in _load_segments (in file c/src/lib/libbsp/i386/pc386/startup/ldsegs.S),
there are
multiple
call    SYM(pc386_delay)
however, the stack is not guaranteed to be valid. It will be valid only
after _establish_stack. Unfortunately, the execution jumps to
_establish_stack only at the end of _load_segments, when it is ``too late''.

In my opinion, there are at least 3 possible solutions:

1) remove the calls to pc386_delay. Are they really needed? If I
understand well, here RTEMS is reprogramming the PIC, and I never needed to
wait between OUTs during PIC programming. But maybe I was simply lucky ;)

2) move _establish_stack before this point, so that the stack
is valid when the call is performed

3) transform pc386_delay in a macro, so that no call is needed.
Something like

#define DELAY outb    al, $0x80

(substitutiong ``call    SYM(pc386_delay)'' with ``DELAY'') should work, but

I am not sure.

>3) when the new version of the eXtender.exe with minimal stack will be
>available on your web-site for download.

I think it will be available in 2 days or 3. Unfortunately, I am finishing
my PhD, and I can work on the eXtender only in my spare time... I am just
finishing to review the changes that I made, and after that I'll release the
new version. Since I did some other changes in ELF parsing, I'll probably
need your help to test the new version before releasing it...

                             Luca