this code is controlled by smptests.h: TEST_CPUSTOP, OFF by default
new code for handling mixed-mode 8259/APIC programming without 'ExtInt'
this code is controlled by smptests.h: TEST_ALTTIMER, ON by default
- TEST_CPUSTOP adds stop_cpus()/restart_cpus(), OFF by default
- TEST_ALTTIMER new method for attaching 8259 PIC to APIC
this method avoids 'ExtInt' programming, ON by default
- TIMER_ALL sends 8259/8254 timer INTs to all CPUs, ON by default
- ASMPOSTCODExxx code to display bytes to POST hardware, OFF by default
and bios.S were small enough and have been merged back into their
respective files in biosboot/, conditionalized on CDBOOT. Other
files might be merged at a later stage.
Caveat emptor: i cannot test this right now.
This is the long-threatened ISO 9660 CD-ROM bootstrap code.
This work has been sponsored by Plutotech International, Inc (who paid
the initial work), and interface business GmbH (where i did most of
the work). A big thanks also goes to Bruce Evans, for his continuing
help and answering my stupid questions.
The code is basically functioning, with the following caveats:
. Rock Ridge attributes are not yet supported.
. Only SCSI CD-ROMs are supported, since i fail to see any possibility
to determine the drive type using BIOS functions. (Even for hard disks,
this determination is done by a big hack only.)
. El Torito specifies a lot of crap and useless misfeatures, but crucial
things like the ability to figure out the CD TOC have been ``forgotten''.
Thus, if you wanna boot a multisession CD, you need to know at which CD
block your session starts, and need to speciffy it using the @ clause.
. None of the CD-ROM controllers i've seen so far implements the full
El Torito specification at all. Adaptec is probably the closest, but
they miss on non-emulation booting (which would be the most logical
choice for us). Thus, the current code bloats the 7.5 KB boot code
up to 1.44 MB, in order to fake a `floppy' image.
If you wanna use it, specify this file as the boot image on the
command-line of the mksiosfs command (option -b).
Caveat emptor: some versions of the Adaptec BIOS might even fail to
access the CD-ROM at all, using the BIOS functions. I think i've
notice this for ver 1.26, the code has been tested with ver 1.23.
The boot string is as follows:
[@sess-start] [filename] [-flags]
sess-start Extend # where the last session starts, measured in
CD-ROM blocks.
filename As usual, but the input is case-insensitive by now
(since we don't grok RR anyway).
flags As usual, but -C (use CDROM root f/s) is default, so
specifying -C will decactivate this option (which is
probably not what you want :).
A lot of cleanup work is probably required, and some of the files
could/should be merged back to biosboot, perhaps made conditional on
some #ifdef. The malloc implementation that comes with cdboot might
also be useful for kzipboot. (I needed a malloc() since the root dir
ain't fixed in size on a CD.)
I've been testing all this with a 2.2-STABLE as the base for biosboot.
I don't expect too many surprises, although i know the biosboot stuff
has been changed a lot in -current lately. I'm sure Bruce will
comment on all this here anyway. :-)
This work has been sponsored by Plutotech International, Inc (who paid
the initial work), and interface business GmbH (where i did most of
the work). A big thanks also goes to Bruce Evans, for his continuing
help and answering my stupid questions.
The code is basically functioning, with the following caveats:
. Rock Ridge attributes are not yet supported.
. Only SCSI CD-ROMs are supported, since i fail to see any possibility
to determine the drive type using BIOS functions. (Even for hard disks,
this determination is done by a big hack only.)
. El Torito specifies a lot of crap and useless misfeatures, but crucial
things like the ability to figure out the CD TOC have been ``forgotten''.
Thus, if you wanna boot a multisession CD, you need to know at which CD
block your session starts, and need to speciffy it using the @ clause.
. None of the CD-ROM controllers i've seen so far implements the full
El Torito specification at all. Adaptec is probably the closest, but
they miss on non-emulation booting (which would be the most logical
choice for us). Thus, the current code bloats the 7.5 KB boot code
up to 1.44 MB, in order to fake a `floppy' image.
If you wanna use it, specify this file as the boot image on the
command-line of the mksiosfs command (option -b).
Caveat emptor: some versions of the Adaptec BIOS might even fail to
access the CD-ROM at all, using the BIOS functions. I think i've
notice this for ver 1.26, the code has been tested with ver 1.23.
The boot string is as follows:
[@sess-start] [filename] [-flags]
sess-start Extend # where the last session starts, measured in
CD-ROM blocks.
filename As usual, but the input is case-insensitive by now
(since we don't grok RR anyway).
flags As usual, but -C (use CDROM root f/s) is default, so
specifying -C will decactivate this option (which is
probably not what you want :).
A lot of cleanup work is probably required, and some of the files
could/should be merged back to biosboot, perhaps made conditional on
some #ifdef. The malloc implementation that comes with cdboot might
also be useful for kzipboot. (I needed a malloc() since the root dir
ain't fixed in size on a CD.)
I've been testing all this with a 2.2-STABLE as the base for biosboot.
I don't expect too many surprises, although i know the biosboot stuff
has been changed a lot in -current lately. I'm sure Bruce will
comment on all this here anyway. :-)
POSIX.4. Additionally, there is some initial code that supports LIO.
This code supports AIO/LIO for all types of file descriptors, with
few if any restrictions. There will be a followup very soon that
will support significantly more efficient operation for VCHR type
files (raw.) This code is also dependent on some kernel features
that don't work under SMP yet. After I commit the changes to the
kernel to support proper address space sharing on SMP, this code
will also work under SMP.
1: cvs and cvsup don't really support vendor branches other than 1.1.1.x,
this is on 1.1.2.x and causing problems in cvsup 'checkout mode', just the
same as cvs has problems interpreting dates. (cvs has "1.1.1" hard coded)
2: cvs 'rm'ing them takes them off the vendor branch and should hide the
above problems.
3: it's just clutter until the merge is done.
4: if the problem isn't sufficiently resolved by taking these off the
vendor branch, the files will have to be nuked and re-imported.
