This announces the availability of version 1.2.13pl5 of Linux/68k. The source and a precompiled kernel are in /pub/Linux/LOCAL/680x0 on ftp.uni-erlangen.de and its mirrors. Changes against the last version: - Some updates to the Atari Lance Ethernet driver: deleted some debugging stuff and added more comments; some minor performance optimizations (save register/memory accesses); there are 8 instead of 4 TX buffers now (and still 32 RX buffers), what may speed up NFS, since one NFS block (8 KByte) now fits completely in the board's memory; the non-VME RieblCards need a slower memory access, so they use an own memcpy now that inserts a MFPDELAY() after each copied byte; the memory address 0x00d00000 is also probed now to support modified ST RieblCards (to avoid conflict with ROM address) (myself, tnx to Torsten Lang for some hints) - Two data areas in the FPSP040 were erroneously commented out. That may have caused wrong calculations of tanh(), frem() and fmod(). (floeck@wctc6.chemie.uni-wuppertal.de and myself) - ksymoops.cc adapted to m68k (schwab@issan.informatik.uni-dortmund.de) - The Atari bootstrap sets (again) the FPU type to 68040 if the CPU is a '040 and doesn't look at the _FPU cookie. This is necessary if some FPU software under TOS sets the cookie to a wrong value (e.g. 68882). The same applies for a '060 (if you have one :-) (myself) - Some code for the '060, but still incomplete (and totally untested...): o '060 support (PCR and branch cache) in the Atari bootstrap and head.S o Respect new bits in the CACR o New access error handler (completely different again) o Clear user mode branch cache on context switches o The '060 has a CPUSH mode that pushes the cache but doesn't invalidate it. This is used for cache_push(). cache_clear() on the '060 first does CPUSH, then CINV. o The '060 cannot supply data in its cache on snooped external reads (as the '040 can), so the cache must be pushed before DMA writes (on machines that support snooping, like the Medusa). It still can invalidate cache entries on external writes, so a cache_clear() before DMA reads isn't necessary. Since all the cache maintainance for DMAing drivers is getting more and more complicated with this, I've written a general function for this, dma_cache_maintainance(), that is defined in asm-m68k/atarihw.h and now is used by all DMAing Atari drivers. Maybe this should further generalized in future for use by all machines (i.e., Amiga also), together with some overall flag whether the machine can snoop the bus. o There's some irritation about the cache mode allowed for page containing page descriptors. The manuals say, the '040 needs non-cacheable, and the '060 allows write-through (but no copyback). But in real life, it seems the other way 'round: the '040 works fine with write-through (and probably even copyback), but the '060 needs a non-cacheable mode...?!? My current solution to this: The cache mode can be chosen for both processors separately at the start of head.S. Currently it's write-through for a '040 and non-cacheable/non-serialized for the '060. What I know to still be missing: o Integration of the MC68060SP ("software package", similar to the MC68040FPSP) o Avoiding use of separate ISP/MSP registers (the '060 has only one SSP). o I think we have to rewrite the calibration of the delay loops and the delay loop preparations, since the use divl and mull with 64-bit operands/results, that are unimplemented on the '060. Ok, the MC68060SP would catch these instructions, but that is much overhead... Motorola also supplies some library functions for the divl/mull operations, maybe we should use these. (all myself) - Added the prototypes of request_dma() and free_dma() to asm/dma.h to avoid warnings about missing prototypes. (myself) - The "keep" parameter to atavideo= should now really work on the Falcon. No VIDEL registers are touched anymore if keep is set. (guenther@pool.informatik.rwth-aachen.de) - Falcon video mode changes are done in the VBL now, which should fix the nasty shifts of the screen picture in monochrome modes. (guenther@pool.informatik.rwth-aachen.de) - amicon.c and atacon.c have been merged into one file, arch/m68k/console/fbcon.c, since they had many similarities. There are several implications and minor updates due to this: o The console font size is now a general sub-option (not Atari only anymore) in the "video=" or "atavideo=" kernel parameter. The old "f8x8" and "f8x16" are gone. The new syntax is "font:", where name is (currently) one of "VGA8x8" or "VGA8x16". The default is chosen the same on yres. o fbcon.c chooses the console scrolling method based on the capabilities of the underlying framebuffer: ywrap (fastest, screen splitting), ypan (pan screen and copy at end, old Atari method), or ymove (slowest, just block copy). o The fonts are in arch/m68k/console now, too, together with an extra abstraction layer for font selection. o There's a skeleton for a text based console, arch/m68k/console/txtcon.c. o Virtual consoles of different sizes should work now. (all Geert.Uytterhoeven@cs.kuleuven.ac.be) I just changed the cursor blinking speeds to the old values, depending on the machine (Amiga/Atari). - General framebuffer changes: o The framebuffer device now reserves the last 8 minors for user defined "standard" resolutions. It's recommended for framebuffer implementations to use the last 8 minors for this purpose if that's possible and it makes sense. This implemented for both, Amiga and Atari. You can use Geert's "fbset" utility to define these user modes. For the Atari, there's also a new command line option for initializing userdef slot #0: It's syntax is "R;;" as sub-option of "atavideo=", and must be used instead of "vga2", "vga4"... . This will initialize /dev/fb0user0 to the given video mode, with a timing chosen automatically by the frame buffer to match the monitor capabilities. New devices: mknod /dev/fb0user0 c 29 24 mknod /dev/fb0user1 c 29 25 mknod /dev/fb0user2 c 29 26 mknod /dev/fb0user3 c 29 27 mknod /dev/fb0user4 c 29 28 mknod /dev/fb0user5 c 29 29 mknod /dev/fb0user6 c 29 30 mknod /dev/fb0user7 c 29 31 o New ioctl FBIOPAN_DISPLAY with less overhead than FBIOPUT_VSCREENINFO (most Geert.Uytterhoeven@cs.kuleuven.ac.be, fb0userx on Atari by guenther@pool.informatik.rwth-aachen.de) - Atari framebuffer changes: o Implemented the FBIOPAN_DISPLAY ioctl for the Atari. The Falcon can do X- and Y-panning, TT/STE Y-panning only (for now), and a plain ST no panning at all. With this, there's a small change in how yres_virtual is handled when changing video modes (e.g. with fbset) on the Falcon. If the input yres_virtual is 0, it is changed to the maximum possible value to support hardware scrolling on the console. If yres_virtual yres on input, it's unchanged, so that X11 gets exactly this value. This change was necessary to support Geert's new X-Server with panning. This means: If you want to use hardware scrolling in the console, always give the option "-vyres 0" to fbset, and set vyres to 0 for any predefined video mode in /etc/fb.modes. To use it with the new X-Server, set vyres (and vxres on Falcon) to some appropriate values. (guenther@pool.informatik.rwth-aachen.de) - Amiga framebuffer changes: o The latest version of the AGA color framebuffer is included. The following modes are available: - ntsc (640x200, 15 kHz, 60 Hz (NTSC)) - ntsc-lace (640x400, 15 kHz, 60 Hz interlaced (NTSC)) - pal (640x256, 15 kHz, 50 Hz (PAL)) - pal-lace (640x512, 15 kHz, 50 Hz interlaced (PAL)) - multiscan (640x480, 29 kHz, 57 Hz) - multiscan-lace (640x960, 29 kHz, 57 Hz interlaced) - a2024-10 (1024x800, 10 Hz (*)) - a2024-15 (1024x800, 15 Hz (*)) - euro36 (640x200, 15 kHz, 72 Hz) - euro36-lace (640x400, 15 kHz, 72 Hz interlaced) - euro72 (640x400, 29 kHz, 68 Hz) - euro72-lace (640x800, 29 kHz, 68 Hz interlaced) - super72 (800x300, 23 kHz, 70 Hz) - super72-lace (800x600, 23 kHz, 70 Hz interlaced) - dblntsc (640x200, 27 kHz, 57 Hz doublescan) - dblntsc-ff (640x400, 27 kHz, 57 Hz) - dblntsc-lace (640x800, 27 kHz, 57 Hz interlaced) - dblpal (640x256, 27 kHz, 47 Hz doublescan) - dblpal-ff (640x512, 27 kHz, 47 Hz) - dblpal-lace (640x1024, 27 kHz, 47 Hz interlaced) - vga (640x480, 31 kHz, 60 Hz (VGA)) - vga70 (640x400, 31 kHz, 70 Hz (VGA)) (*) The a2024-?? modes don't work yet. The default mode is vga70 (for AGA :-) The following devices are used: mknod /dev/fb0current c 29 0 mknod /dev/fb0autodetect c 29 1 mknod /dev/fb0ntsc c 29 2 mknod /dev/fb0ntsc-lace c 29 3 mknod /dev/fb0pal c 29 4 mknod /dev/fb0pal-lace c 29 5 mknod /dev/fb0multiscan c 29 6 mknod /dev/fb0multiscan-lace c 29 7 mknod /dev/fb0a2024-10 c 29 8 mknod /dev/fb0a2024-15 c 29 9 mknod /dev/fb0euro36 c 29 10 mknod /dev/fb0euro36-lace c 29 11 mknod /dev/fb0euro72 c 29 12 mknod /dev/fb0euro72-lace c 29 13 mknod /dev/fb0super72 c 29 14 mknod /dev/fb0super72-lace c 29 15 mknod /dev/fb0dblntsc c 29 16 mknod /dev/fb0dblntsc-ff c 29 17 mknod /dev/fb0dblntsc-lace c 29 18 mknod /dev/fb0dblpal c 29 19 mknod /dev/fb0dblpal-ff c 29 20 mknod /dev/fb0dblpal-lace c 29 21 mknod /dev/fb0vga c 29 22 mknod /dev/fb0vga70 c 29 23 On OCS/ECS, the old special device nodes are still used! o Merged the old monochrome frame buffer (OCS/ECS) with the new color version for AGA. Until OCS/ECS support for the color version is finished, the old version is invoked when running on a non-AGA machine. Thus from now on AGA users will get color with the standard source tree. o Monitor capabilities (kernel parameter `video', cfr. Atari): monitorcap:;;;) are vertical freq. in Hz, horizontal ones in kHz; default is a generic Amiga monitor (50-90 Hz, 15-38 kHz) o Hold-And-Modify (HAM6/HAM8) if var->nonstd == FB_NONSTD_HAM Someone interested in porting ZGV to the frame buffer concept? o VESA suspend mode: pwrsave (not for BROADCAST (PAL/NTSC) modes) o PAL and NTSC work now (incl. ywrap) o The maximum display depth for which hardware scrolling (ywrap) is possible is determined using ddfstrt now (was: hardcoded at 4 planes) o Hardware cursor basics (very preliminary) (all Geert.Uytterhoeven@cs.kuleuven.ac.be) - Preliminary support for the Cybervision graphics board, though only in a very limited way. The current driver is neither able to set up the screen as needed nor does it use the blitter on the Cybervision under X (this is rather caused by the need for a special X server than by the framebuffer device). It can do the following: It can use a screen that exists at boot time to render its output to. The screen has to be either 640, 800, 1024, 1152 or 1280 pixels wide, the height is not restricted. The width and height of the desired screen have to be set in defines in arch/m68k/amiga/cyberfb.c accordingly. Due to the fact that it needs an existing screen it cannot be used together with 'lilo', you have to use 'bootstrap' for booting. (apel@tecmath.de) The Amiga bootstrap has a new option, "-v", to support the Cybervision. This option causes the video mode not to be reset, as currently needed for the Cybervision framebuffer. (A bit similar in effect to "atavideo=keep".) (Geert.Uytterhoeven@cs.kuleuven.ac.be) - Fix inverse video mode initialization and throw away a leftover commenting-out for testing; fix ICD partition numbering (schwab@issan.informatik.uni-dortmund.de & guenther@pool.informatik.rwth-aachen.de) - Misc documentation updates (kernel-options, Configure.help, CREDITS.m68k) (Geert.Uytterhoeven@cs.kuleuven.ac.be) - On the Medusa, always using 8 MB as ST-RAM has caused problems with a ramdisk, because the assumptions about the relative positions of memory areas became wrong. The fix is to use the same amount of ST-RAM as TOS does. (myself with floeck@wctc6.chemie.uni-wuppertal.de) - The Amiga interrupts were handled (within the same interrupt level) in a different order than under AmigaOS. Shouldn't have had much influence, but at least these reversed priorities were a bit confusing. (Geert.Uytterhoeven@cs.kuleuven.ac.be) - The read and write functions for /dev/vcs* contained a few byte order dependencies. Also, the display is now correctly updated if writes go to the currently visible vcs. (schwab@issan.informatik.uni-dortmund.de) - Some stuff for the Afterburner040 for the Falcon: o Check for a VIDEL in the bootstrap to distinguish the AB040 from a Medusa; the AB040 also allows writing to the address range 0x0...0x7 (no ROM shadow!) o A similar test also added in head.S for the same reason o Also the Atari internal framebuffer now takes care of the cache mode of video memory: this must be write-through (no copyback) on a '040+, else changes appear on the screen only when data are pushed out of the cache... For this, a new function, kernel_set_cachemode(), was necessary. Hope it works. o What still doesn't work: putting the kernel into TT-RAM :-( The problem seems to be the jump to virtual address space in head.S. Still investigating on this... (all myself) - Atari SCSI driver changes: o Falcon-SCSI should now work with TT-RAM! My old idea to use the 'unchecked_isa_dma' flag in the host structure for this case was wrong, simply wrong... It had the implication to clean up all the mid-level SCSI code in respect to ST-RAM handling. It's much easier to implement a dribble buffer internal to the Atari SCSI driver. I.e., if a transfer is from/to memory that the ST-DMA can't access, a pre-allocated ST-RAM buffer is used instead as an intermediate. One buffer is enough, since Falcon-SCSI cannot do scatter-gather anyway. Only allocating this buffer requires a new, not very clean call from scsi.c. This is untested for now, but it should work. o The driver now does a SCSI bus reset during initialization. Maybe that helps for the problems with the ICD and CBHD drivers under TOS. o Fixed some NCR_abort() return codes. o After a bus reset, the interrupt condition must be cleared, else no ints get through anymore. o Fixed some (possible) NULL pointer references in debugging output statements. o The cleanup of the disconnected_queue and the connected command after a reset could have caused problems (stale pointers, too early restarting). Completely rewritten this so no bad things should happen there anymore. The last three things should make SCSI resets work now (do you know Will Robinson? :-), i.e. the machine shouldn't panic anymore under normal circumstances. Good news for Falcon users... (all myself, the last item guenther@pool.informatik.rwth-aachen.de) - The Amiga Lance drivers (A2065 and Ariadne) didn't check right at the start of their isr whether it was really their board that caused the interrupt. Now the int status bit is tested ASAP. This might have been a part of the reason why people have had problems with these drivers in the past (well, just maybe). (jds@kom.auc.dk) - Fix the problem with Zorro detection when there is more than one GVP board. (jds@kom.auc.dk) Current Amiga bootstrap version: 2.2 (changed) Current Atari bootstrap version: 1.5 (changed) The precompiled kernel contains both, Amiga and Atari support, so it is very big. You probably want to compile your own kernel tailored to your personal needs. Note also that there have been some problems reported that such big kernels cannot be booted with Amiga Lilo. Roman