an 68060/68LC060, possibly switching on the 68060 FPU, instead of trusting
the value passed from the ROM OS to us by the bootblock.
Most 68060 boards, unlike the DraCo (which seems to have heavily patched OS
ROMs) don't set the AMIGA_68060 flag; instead, upon detecting an 68060, its
FPU is disabled to make the ROM scheduler work, and at a much later time (at
least, later than bootblock booting time), the "68060.library" installs the
Motorola 68060 software support, patches the scheduler for the 68060 FPU, and
re-enables the FPU.
Maybe this will be fixed one day, if Amiga International sells upgraded OS
ROMs which know about the 68060. Until then, and for legacy machines, this
kludge is needed if we want to boot a non-DraCo 68060.
Btw, thats why this is NOT in std.amiga, but in GENERIC; the DRACO
configuration doesn't need it (and I still plan to make std.draco go away).
or swap partitions. Booting from a miniroot on the swap partition will
detect the miniroot as the boot partition (if the bootblock loader passes
the boot partition offset to the kernel).
(thesing@cs.uni-sb.de), heavily hacked upon by me to
- make it work with -current audio system
- make it shut off Amiga audio DMA only at appropriate places.
XXX A couple of bugs still remain, which well be handled later.
XXX Among them: only mono output; doesn't refuse to handle input, but chokes;
will not play last millichunk (is this 20 ms?) of data.
kernels, at the same time getting rid of up to 3 conditional branches and a
bit over one cacheline fetch (for the 68060; the saving is a bit smaller for
040 and yet smaller for the 020/30).
While we're here, also get rid of an redundant lea (using SP-relative
addressing) and of two redundant pushes.
While we're here, also fix a panic which would tear us down on 68060 machines
if a branch prediction error ever occured.
>Signed shifts are evil.
>Thanks to Michael Smith for reporting, Jason Thorpe for pointing to the
>report, doing a quick workaround which pointed me to the right code part and
>for testing the final fix.
Some of the stuff (e.g., rarpd, bootpd, dhcpd etc., libsa) still will
only support Ethernet. Tcpdump itself should be ok, but libpcap needs
lot of work.
For the detailed change history, look at the commit log entries for
the is-newarp branch.
- Fixes for Interlace and DoubleScan
- Memorysizedetction for 1MB Bords
- Clockdoubling for PicassoIV and PiccoloSD64
NOTE: Don't use the X11R6.1 Xserver with -useHWC on the SD64
with a gfxmode >80Mhz or you get a broken mousepointer.
- HiColor and TrueColor Support
(doesn't work yet, since it needs some fixes for the XServer)
pass the block number of the boot partition to the kernel. The kernel
will use the block number to determine which disk device the kernel was
booted from and set the boot device based on that instead of the old
"generic" method.
- move the helper programs txlt and aout2bb to the topmost directory
- build the few files from libsa in the topmost directory
* while doing this, hunted down mysterious code expansion: It seems
that ld aligns code segments differently when linking .o's directly
than when using an archive consisting of the same files. Abuse this
effect to make the bootblock even smaller. The floppy boot block
"fdboot" is now small enough to build; add it back to the Makefile.
* while being here, remove a file which was committed by mistake.
Eliminate obsolete global kernel variable "struct timezone tz"
Add RTC_OFFSET option
Add global kernel variable rtc_offset, which is initialized by
RTC_OFFSET at kernel compile time.
on i386, x68k, mac68k, pc532 and arm32, RTC_OFFSET indicates how many
minutes west (east) of GMT the hardware RTC runs. Defaults to 0.
Places where tz variable was used to indicate this in the past have
been replaced with rtc_offset.
Add sysctl interface to rtc_offset.
Kill obsolete DST_* macros in sys/time.h
gettimeofday now always returns zeroed timezone if zone is requested.
settimeofday now ignores and logs attempts to set non-existant kernel
timezone.
For some reason it wouldn't get positioned right when mapped in through the
blitter memory mapped location, so switched to the register mapping, which
works.
XXX colormap handling for the cursor is still broken.
configuration. This way, the delay loop is calibrated before graphics and
serial hardware is touched.
This change should smooth pr 2890 by Thorsten Frueauf (also privately
reported by Laurent Badoukh). While the real problem with those is the
paranoically high delay() calls in the grf_cl initialization, it was made
even more visible by the miscalibrated (to the save side) new style delay
loop.
even if you "really didn't change anything dangerous" :-)
- While we're here, save a few bytes and clock cycles during kernel startup:
cinva ic clears the branch cache on the 68060, no need to do it explicitly.
for branch prediction errors (could be used to detect strange binaries),
integer instruction, FP instruction, FP data type and FP effective address
emulations. The latter can be used to diagnose binaries which should be
recompiled with -m68060.
XXX Maybe these diagnostics should be switchable by sysctl or
XXX options DIAGNOSTIC.
making me think that the Blizzard-IV and the Blizzard-2060 scsi
options have nearly identical DMA engines (just with a different
address offset). Alas, this isn't true.
Herewith I replace the "bznsc" (all-new-Blizzard-models) driver with the
"bztzsc" (Blizzard Two Zero).
on indirect-config busses a (permanent) softc that they could share
between 'match' and 'attach' routines:
Define __BROKEN_INDIRECT_CONFIG so that old autoconfiguration
interfaces are used, until drivers are converted to use the new
interfaces (actually, converted back to use the _older_ interfaces)
which prohibit indirect configuration devices from receiving a softc
in their match routine that they can share with their attach routine.
Lets users over-ride with makeoptions COPTS="..." in kernel config files.
Leave `mandatory' flags (like -msoft-float which on m68k enforces no
FP in kernel) in CFLAGS.
