Mailing List Archive: multiple comboot files?

multiple comboot files?

May 25, 2007, 9:51 AM

Post #1 of 3 (1223 views)

Is there a way for isolinux/syslinux to execute a list of comboot files
immediately at startup, and only once?
I have a bunch of small comboot .com files that I want to batch run immediately,
then after that do a
DISPLAY boot.msg

similar in some ways to an autoexec.bat.
For example:

DEFAULT mycd
APPEND ramdisk_size=100000 init=/etc/init lang=us ....
TIMEOUT 300

ONSTARTUP mybatch <- ???

LABEL mybatch <- start this right away, but not related to DEFAUT or TIMEOUT
KERNEL myisr1.com
KERNEL myisr2.com
KERNEL myisr3.com

Also, in my case some of these comboot files are ISRs, so they need to stay resident
in some way, even just before transferring the IP to a kernel.
(they work individually already, but just one at any given time and crash
at the point when a kernel is loading into memory).
Is there a way to ensure a loaded comboot file stays resident and
the memory it uses wont get overwritten, for example even when loading a kernel
or by yet another comboot file?
If the comboot file could be instructed to load in a reserved high segment,
or even just after the BDA, the
available memory reported by the bios (INT 12 and INT 15 AX=E820h)
could be reduced, but I dont know if this approach will work under syslinux.
>From the source, it looks like comboot_seg is 4000, right in the middle.

Also, related to the first question, if I want to disable one of my
ISR's just before loading a kernel, I need to execute another smaller comboot
file to restore the IVT and other hardware registers.
When some action is exceuted, by say a keyword label, or default,
I would like to be able to load that smaller comboot file, followed by
the loading of the kernel, basically like above, but not at startup.

For example:

LABEL mycd
KERNEL endisr1.com
KERNEL endisr2.com
KERNEL linux24
APPEND ramdisk_size=100000 init=/etc/init lang=us ....

Any help appreciated.

_______________________________________________
SYSLINUX mailing list
Submissions to SYSLINUX@zytor.com
Unsubscribe or set options at:
http://www.zytor.com/mailman/listinfo/syslinux
Please do not send private replies to mailing list traffic.

Re: multiple comboot files? [ In reply to ]

hpa at zytor

May 25, 2007, 10:53 AM

Post #2 of 3 (1151 views)

Permalink

Bryan E. Chafy wrote:
> Is there a way for isolinux/syslinux to execute a list of comboot files
> immediately at startup, and only once?

Not directly, no.

> Also, in my case some of these comboot files are ISRs, so they need to stay resident
> in some way, even just before transferring the IP to a kernel.
> (they work individually already, but just one at any given time and crash
> at the point when a kernel is loading into memory).
> Is there a way to ensure a loaded comboot file stays resident and
> the memory it uses wont get overwritten, for example even when loading a kernel
> or by yet another comboot file?
> If the comboot file could be instructed to load in a reserved high segment,
> or even just after the BDA, the
> available memory reported by the bios (INT 12 and INT 15 AX=E820h)
> could be reduced, but I dont know if this approach will work under syslinux.

That's pretty much what MEMDISK does -- it relocates itself to the very
end of DOS memory, and installs hooks into INT 12h and INT 15h.
However, you don't want to do that for each one for a bunch of different
files, you want to do it only once.

>>From the source, it looks like comboot_seg is 4000, right in the middle.
>
> Also, related to the first question, if I want to disable one of my
> ISR's just before loading a kernel, I need to execute another smaller comboot
> file to restore the IVT and other hardware registers.
> When some action is exceuted, by say a keyword label, or default,
> I would like to be able to load that smaller comboot file, followed by
> the loading of the kernel, basically like above, but not at startup.

What you're really asking for is a scripting engine in syslinux. It's a
common enough request, but it's unlikely to happen until I find time
enough to rewrite the UI functionality in C.

For now the only way to do this is to have your comboot file invoke the
next one instead of returning (via API function 0003h or similar.)

These ISRs aren't MS-DOS TSRs, are they? If so, there is pretty much no
hope to get them to work; DOS TSRs load from the bottom up, whereas in a
pure BIOS environment you have to load from the top down.

-hpa

_______________________________________________
SYSLINUX mailing list
Submissions to SYSLINUX@zytor.com
Unsubscribe or set options at:
http://www.zytor.com/mailman/listinfo/syslinux
Please do not send private replies to mailing list traffic.

Re: multiple comboot files? [ In reply to ]

bchafy at ccs

May 25, 2007, 2:51 PM

Post #3 of 3 (1155 views)

Permalink

Thanks, I'll look into memdisk..

No, the ISR's are real BIOS ISR's, not DOS TSR's. (vga hacks
to get the card to sync/scan at a low scanrate, suitable for an old tv and
other obsolete displays).. Actually they could be loaded anywhere in
real-mode addressing space..
I've been able to integrate the code into real system and vga rom bios's with
success.
Check out:
http://www.ccs.neu.edu/home/bchafy/lood.html
http://www.ccs.neu.edu/home/bchafy/kp/kaypro.html
http://www.ccs.neu.edu/home/bchafy/gw/tvinapc.html

However, reverse-debugging, hacking and flashing system and vga binary-only
bios's is pretty time consuming and in the end only works for one board desgin.
So Im in the process of making a live cd with the video mods as a
compromise, the challenge being to get the comboot ISR(s) started as soon as
practiaclly possible, so things are readable. Once this is working, the rest
(linux frame buffer, console, X, etc) is trivial :)

> Bryan E. Chafy wrote:
> > Is there a way for isolinux/syslinux to execute a list of comboot files
> > immediately at startup, and only once?
>
> Not directly, no.
>
> > Also, in my case some of these comboot files are ISRs, so they need to stay resident
> > in some way, even just before transferring the IP to a kernel.
> > (they work individually already, but just one at any given time and crash
> > at the point when a kernel is loading into memory).
> > Is there a way to ensure a loaded comboot file stays resident and
> > the memory it uses wont get overwritten, for example even when loading a kernel
> > or by yet another comboot file?
> > If the comboot file could be instructed to load in a reserved high segment,
> > or even just after the BDA, the
> > available memory reported by the bios (INT 12 and INT 15 AX=E820h)
> > could be reduced, but I dont know if this approach will work under syslinux.
>
> That's pretty much what MEMDISK does -- it relocates itself to the very
> end of DOS memory, and installs hooks into INT 12h and INT 15h.
> However, you don't want to do that for each one for a bunch of different
> files, you want to do it only once.
>
> >>From the source, it looks like comboot_seg is 4000, right in the middle.
> >
> > Also, related to the first question, if I want to disable one of my
> > ISR's just before loading a kernel, I need to execute another smaller comboot
> > file to restore the IVT and other hardware registers.
> > When some action is exceuted, by say a keyword label, or default,
> > I would like to be able to load that smaller comboot file, followed by
> > the loading of the kernel, basically like above, but not at startup.
>
> What you're really asking for is a scripting engine in syslinux. It's a
> common enough request, but it's unlikely to happen until I find time
> enough to rewrite the UI functionality in C.
>
> For now the only way to do this is to have your comboot file invoke the
> next one instead of returning (via API function 0003h or similar.)
>
> These ISRs aren't MS-DOS TSRs, are they? If so, there is pretty much no
> hope to get them to work; DOS TSRs load from the bottom up, whereas in a
> pure BIOS environment you have to load from the top down.
>
> -hpa
>
> _______________________________________________
> SYSLINUX mailing list
> Submissions to SYSLINUX@zytor.com
> Unsubscribe or set options at:
> http://www.zytor.com/mailman/listinfo/syslinux
> Please do not send private replies to mailing list traffic.
>
>

_______________________________________________
SYSLINUX mailing list
Submissions to SYSLINUX@zytor.com
Unsubscribe or set options at:
http://www.zytor.com/mailman/listinfo/syslinux
Please do not send private replies to mailing list traffic.