NetBSD Atari Frequently Asked Questions Table of Contents 0. What is this document about? 1. General Information 1.1 What are NetBSD and NetBSD-Atari? 1.2 Where can I get NetBSD-Atari? 1.3 Where can I get more information 2. Installation 2.1 What is the minimum hardware configuration for NetBSD-Atari? 2.2 How do I install NetBSD on my Atari 3. Kernel messages 3.1 What does St-mem pool exhausted, binpatch 'st_pool_size' mean? 3.2 What does dma-ready: code = 2 mean? 3.3 What does NetBSD bootblock not on primary AHDI partition mean 4. System configuration 4.1 Can I tell my Atari which OS it should boot? 4.2 How do I increase the number of virtual consoles? 4.3 Can I change my screen colors and resolution? 4.4 What is the floppy device scheme? 4.5 What is the hard disk partitioning scheme? 4.6 Can I create a disklabel on my disk? 4.7 Can I fix the link between a SCSI target and a device node? 4.8 Why doesn't NetBSD use the time I set my system clock to? 4.9 How do I build my own kernel? 4.10 What do I need to get X11 running? 4.11 Where can I get information about networking services 5. Hardware configuration 5.1 Riebl card jumper settings 5.2 Termination on the TT SCSI-bus 5.3 Serial ports (which is which) 6. Bugs and current development ==================== 0. What is this document about? This is the frequently asked questions list for the Atari port of NetBSD. It was compiled by Rainer J. H. Brandt . Most of the answers were written by Leo Weppelman , the port-master, or taken from postings to the port-atari mail list. (See question 1.3) Parts of the installation instructions are included as well. When the personal pronoun "I" appears, it is often Leo Weppelman speaking. If you have any questions on NetBSD-Atari that are not answered here, check the material referenced in the answer to question 1.3. If you still find no answer, turn to the port-atari mail list. ==================== 1. General Information -------------------- 1.1 What are NetBSD and NetBSD-Atari? NetBSD is a Berkeley Networking Release 2 (Net/2) and 4.4BSD-Lite-derived Operating System. It is a fully functional UN*X-like system which runs on many architectures and is being ported to more. NetBSD, as the name implies, is a creation of the members of the network community and without the net it's likely that this release wouldn't have come about. If you want to read more on its history and current state, see question 1.3. The Atari release stepped in in March 1995. It is available for Atari TT, Falcon and Hades computers. The first official release was 1.1; the current release is 1.2. -------------------- 1.2 Where can I get NetBSD-Atari? There are several anonymous ftp site that carry the NetBSD distribution. The Atari distribution can be found in the NetBSD-1.2/atari/ directory within the NetBSD directories given in the following URL list. The NetBSD home site is ftp.netbsd.org . Mirrors exist at: coombs.anu.edu.au (Australia) ftp.funet.fi (Finland) wipux2.wifo.uni-mannheim.de (Germany) ftp.uni-regensburg.de (Germany) ftp.unit.no (Norway) ftp.stacken.kth.se (Sweden) ftp.demon.co.uk (UK) ftp.iastate.edu (USA) ftp.eecs.umich.edu (USA) gatekeeper.dec.com (USA) flick.lerc.nasa.gov (USA) -------------------- 1.3 Where can I get more information? There is a mail list for the Atari port. To subscribe, send an email to majordomo@NetBSD.ORG . The message contents should be help or subscribe port-atari. The NetBSD Organisation has a web site at URL There are several mirror sites. Archives of the NetBSD mailing lists are available. ==================== 2. Installation -------------------- 2.1 What is the minimum hardware configuration for NetBSD-Atari? NetBSD/Atari 1.2 runs on a TT030, a Falcon, and a Hades. The Hades kernel currently ONLY works on a Hades with an et4000 PCI video card. An FPU is not required. The minimum amount of RAM required is 4Mb. You will need at least 64MB free space on your hard disk, but it is recommended that you provide twice as much, especially if you plan to install X11 or build your own kernel. Add the space needed for applications and data you plan to install. -------------------- 2.2 How do I install NetBSD on my Atari? Follow the instructions given in the INSTALL document. It comes with the source distribution. ==================== 3. Kernel messages -------------------- 3.1 What does St-mem pool exhausted, binpatch '_st_pool_size' mean? This section does not apply to the Hades. The "St-mem pool" is a allocated at boot-time. It is located in the lower 16Mb of memory. It is used by drivers for Atari peripherals that were designed for the old 1040 ST that had an 24-bit address bus. As it is currently impossible to specify where to allocate memory at run-time, there is no other way than allocate this memory at boot-time, before memory management is setup. The St-mem pool is currently used by the video, floppy and the Falcon SCSI driver. The default (BOOT) kernel supplied has a rather small St-mem pool. This is done to enable it to boot in systems having only 4Mb of ram. In fact it has a pool just big enough for 2 virtual consoles in ST-mode. You can extend the size of the pool by binpatch-ing the kernel. In the distribution directory .../utils.NetBSD, you can find a binpatch binary and binpatch(8) manual page. For setting the St-mem pool size, issue the following command from the shell prompt: binpatch -s _st_pool_size -o 8192 -r The value of new_size should be given in bytes and depends on the following: video-resolution: ST-mode: : 32Kb + 8Kb slack TT-mode : 154Kb + 8Kb slack Falcon modes: size = (width * height * depth)/8 + 8Kb slack Falcon SCSI bounce buffers: I think 16Kb per SCSI target will do. Floppy: Maximum 1 track == 18Kb Note that each virtual console needs a video buffer. So you should multiply the value needed by the video by the number of virtual consoles defined. -------------------- 3.2 What does dma-ready: code = 2 mean? You are probably suffering from SCSI parity errors. By default, parity checking is off on all devices - unless I make a mistake and upload a kernel with parity checking on, which I sometimes do.... The discussion of whether or not SCSI parity checking should work on all devices on the Atari has not yet ended. There were rumours of hardware problems but until now, I've not yet seen a sensible reason why it shouldn't work. In practice however, some devices will give a _lot_ of parity errors. Note that the discussion is about the parity checking on the _host adapter_ (the Atari), not about parity checking on the SCSI-targets. The Atari generates the parity bit correctly (Although I remember Christoph Simon having a different experience). So it should be possible to enable parity checking on the SCSI-targets. The NetBSD/Atari kernel has a "bitfield" describing on what targets parity checking should be disabled. You can modify it with the binpatch program. The exact command line is: binpatch -b -s _ncr5380_no_parchk -o 8192 -r Target 0 is the low-order bit and target 7 the most significant bit of the mask. So if you want to disable parity checking on targets 0 and 3, subsitute 0x09 for . In my personal opinion, you should try to enable parity checking on all devices that it works for. The parity bit was not invented for fun! Also, you should enable the parity check on all connected targets. -------------------- 3.3 What does NetBSD bootblock not on primary AHDI partition mean? An explanation from Udo Erdelhoff: As you might know; every hard disk has a "root sector" that contains information about the size of the hard disk and the partitions on the hard disk. The root sector can only contain the neccessary data for four partitions. Nobody thought that this limitation would cause any problems. After all, 640 KByte should be enough. As hard disks grew, it was neccessary to define more than four partitions. In order to be more or less compatible with the old format, a new type of partition entry was defined: XGM partitions. An XGM partition is a "look over there" sign: Another root sector can be found at the start of the XGM partition. This root sector contains the remaining real partitions. And this is the big mystery: Partitions defined in the root sector of the hard disk are called "primary partitions", partitions defined in the root sector of an XGM partition are called "extended partitions". The bootblock will only work if the first NBD partition is a primary partition. This is not a limitation of NetBSD but a limitation of TOS/AHDI: You can only boot from primary partitions. If you are creating your partitions with HDX, you'll have to be very careful to fulfill this rule. HDX has some very strange ideas when it comes to extended partitions. Fortunately, you can edit this stuff: The "Edit partition scheme of the unit" dialog box has a button label "expert". This button is inactive unless you have defined more than four partitions. Click on it _after_ you have defined the sizes of the partitions. A new dialog box appears on the screen. The left side contains two blocks of partitions: The upper block always contains the first four partitions, the lower block contains the last three partitions. If you have defined less than 7 partitions, some fields of the lower block will contain the string "unused". Some of the partitions will be displayed in reverse video: These are the extended partitions. The right side contains six possible ranges for the extended partitions. It is not possible to define your own range, you will have to use one of the schemes offered by HDX. To quote from Ghostbusters: "Choose and die". The default scheme used by HDX is the first scheme: Extended partitions start with the second partition and end with the second to last partition. If you have defined 7 partitions, partitions #2 to #5 will be extended partitions, while partitions #1, #6 and #7 will be primary partitions. You can move the extended partition range by clicking on one of the buttons on the right side of the dalog box. Try to find one where your first NetBSD partition is a primary partition. Golden rules: If the disk contains no GEMDOS partitions, don't use AHDI. Let NetBSD handle it alone. If the disk contains one GEMDOS partition, make it partition #1 and start the extended partition range at partition #3. This allows you to boot from both the GEMDOS and the NetBSD partitions. If the disk contains two GEMDOS partitions, use partitions #1 and #2 for GEMDOS, partition #3 for NetBSD-root. Start the extended partition range with partition #4. If your disks contains three or more GEMDOS partitions, you are in trouble. Try using partitions #1 and #2 as the first two GEMDOS partitions. Use partition #3 as the first NetBSD partition. Start the extended partition range with partition #4. ==================== 4. System configuration -------------------- 4.1 Can I tell my Atari which OS it should boot? Yes. The Atari's clock chip contains 64 bytes of battery-sustained non-volatile RAM, of which only the first 14 bytes are used for the system clock. Of the remaining 50 bytes, 48 bytes can be used for other purposes. The highest two bytes contain a check sum. The XBIOS call 46 (NVMaccess) is available for reading and writing these 48 bytes. (A side note for Hades owners: Although the Hades BIOS does not support the BootPreference-bit (this was acknowledged by Christoph Aschwanden), the NetBSD boot loader _will_ take it into account.) When Atari was working on a System V port, it was decided to use the first byte for boot preference. While Waldi Ravens was working on a bootstrap loader for NetBSD/Atari, he wanted to remain compatible with TOS and ASV. So he asked Eric Smith if it would be possible to reserve boot preference bit 0x20 for NetBSD. They agreed on the following scheme: 0x80 - TOS 0x40 - ASV 0x20 - NetBSD 0x10 - Linux While in the NetBSD install program, you are given an opportunity to install bootblock code on your root disk. This requires a valid disklabel, though. (See question 4.6.) You can also install the bootloader from a running NetBSD system. Read the boot_atari(8) and the installboot(8) manual pages. -------------------- 4.2 How do I increase the number of virtual consoles? To change the number of virtual consoles, you have to build your own kernel. The atari console driver is built of the following components: view A view is an abstraction of the video hardware. grf This is the graphics driver. This driver deals with the screen in graphics mode. The X11 driver accesses the console through grf. Each grf-driver is layered above a single view. ite This is the terminal emulator. Each ite-driver is layered above a single grf. There is a 1-1 connection between the layers. ite2 talks to grfxx2 that talks to view2. (On the TT and Falcon, xx is cc, on the Hades, it's et.) For autoconfigure purposes, the grf-devices are grouped as a bus, the grfbus0. If you want to have 3 virtual consoles, your config file looks like: pseudo-device # View (graphics mapping) grfxx1 at grfbus0 # second graphics driver grfxx2 at grfbus0 # third graphics driver ite1 at grfxx1 # second tty ite2 at grfxx2 # third The devices ite0/grfxx0 are always defined. To be exact, they are defined in the file std.atari which is included in all config files. The minimum number of virtual consoles is 1. -------------------- 4.3 Can I change my screen colors and resolution? Yes, you can. Take a look at the iteconfig(1) and iteconfig_atari(8) manual pages. Owners of a TT can change the colors/height/width and depth. Falcon owners can changes colors, but can they change depths? -------------------- 4.4 What is the floppy device scheme? Floppy devices are coded as follows: /dev/fd0a - 360Kb /dev/fd0b - 720Kb /dev/fd0c - 1.44Mb -------------------- 4.5 What is the hard disk partitioning scheme? partition a: A root-filesystem (if any) partition b: Swap space (if any) partition c: Whole disk (always :-) ) partition d: First user/other partition | | partition p: Last user/other partition The number of partitons that NetBSD can handle is currently 15 per disk. (That may be changed to 32 later.) When you mount a GEMDOS file system, don't forget to use the -G option (see mount_msdos(8)). Notice: There seems to be a problem with ICD-formatted disks. Try to mount them without -G. -------------------- 4.6 Can I create a disklabel on my disk? Read the INSTALL document on this issue and consult the disklabel(8) and disklabel(5) manual pages. Waldi Ravens remarks: Disklabel(8) doesn't know anything about the AHDI partition table. It can only handle a NetBSD partition table. It is very old software, from the times that hard disks had a fixed geometry. Modern SCSI disks do not have a fixed number of sectors per cylinder, so you'll have to do some calculations here. Guaranteed is the total number of sectors per unit (the size of partition c, the whole disk), which is provided by the SCSI driver. You'll have to figure out which values are best used for the number of cylinders and sectors per cylinder (depending on your partitions; it's best if partitions start and end at cylinder boundaries). BTW, when you add a partition to the label, you must increase the number of partitions manually. It will certainly be improved. But disklabel(8) is not a platform dependent tool, so it's much more difficult to get some improved code in the main source tree. I recommend that you: never change the bytes/sector field. choose a proper sectors/cylinder value, I suggest 1024, 512 or 256. (note that bsd-ffs can't use part of a cylinder, only complete cyls). based on sec/cyl, set tracks/cyl and sectors/track, for example 512 sec/cyl => 8 tracks/cyl and 64 sectors/track. determine the number of cylinders: (size of c partition)/(secpercyl) if the remainder is not equal to zero, add one to the result. when splitting AHDI partitions, try to use sizes which are a multiple of the secpercyl value, and make sure it can be split in an integer number of cylinder groups (see newfs(8) option -c). changing partition c is generally not a good idea. the bsize, fsize and cpg fields are set by newfs(8), but it's usually a good idea to determine those values, when creating the partitions. -------------------- 4.7 Can I fix the link between a SCSI target and a device node? Currently, the device nodes for SCSI devices are assigned dynamically. For example if you have 2 harddisks at scsi-id's 1 and 2, they will have device numbers sd0 and sd1. When you add a new disk with scsi-id 0, the old disks will become sd1 and sd2 while the new disk becomes sd0. To fixate the links, you have to build your own kernel. Go to the the config directory and edit 'std.atari'. Currently the line for configuring disks looks like: sd* at scsibus? target ? lun ? If you change this to read: sd0 at scsibus0 target0 lun? sd1 at scsibus0 target1 lun? sd2 at scsibus0 target2 lun? | | | | | | | | you can remove scsi-0 without having to worry about scsi-id's sd1 and sd2 getting a different name. -------------------- 4.8 Why doesn't NetBSD use the time I set my system clock to? A UN*X system expects its system clock to be set to UTC (Universal Time Coordinated). Your local time zone is used to calculate your local time. This only works if you link /etc/timezone to the appropriate file in /usr/share/timezone. If you live in Central Europe, for instance, use ln -s /usr/share/timezone/MET /etc/timezone Daylight Savings Time will automatically be taken care of. This may break if your local politicians change the DST scheme. You will then need a new time zone file. There is currently a problem with this approach: Files copied to a Gemdos partition from NetBSD will appear to have a modification time that is off by the difference between UTC and your local time. If you copy these files back to a NetBSD file system, this offset will double. If you don't want your Atari system clock to run UTC, set it to your local time and symlink to UTC under NetBSD. Manually adjust the system clock for DST twice a year as you did in the past. In kernels newer than mid-december 1996 (1.2B), there is a new device /dev/rtc. I consider it experimental - there is no consensus in the NetBSD developers group about this. In the meantime, it's there and you can use it and it has some side effects that you have to be aware of. Also, let me know what you think of it and your experiences using it. Both the DST and TIMEZONE options are gone from the kernel config-files. When the kernel boots, it grabs the time from the RTC as if it were running in UTC. When the kernel is instructed to reboot/halt, it _won't_ update the RTC device with the kernels idea of the time. This means that setting the date with date(1) will _not_ change the RTC time. If you want to update the RTC, you'll have to do so explicitely using: date [-u] +%y%m%d%H%M.%S>/dev/rtc If your RTC runs in UTC, supply the -u flag. For a clock running in local time, omit it. In the latter case, you have to reset the date during startup too. Add a line date `cat /dev/rtc` to /etc/rc.local (or something equivalent). -------------------- 4.9 How do I build my own kernel? You should start by obtaining the kernel sources from ftp.netbsd.org or one of it's mirrors. The path to look in depends on you: /pub/NetBSD/NetBSD-1.2/source/ksrc12 (the sources of the 1.2 kernel) /pub/NetBSD/NetBSD-current/tar_files/src/sys.tar.gz (the latest kernel sources) After unpacking the sources, the kernel source is located on '/usr/src/sys'. You should now start with configuring the kernel you wish to build. So go to the directory: /usr/src/sys/arch/atari/conf . Among others, you see a bunch of files in capital letters - the kernel config files: - BOOT The kernel as supplied on the boot floppy - BOOTX Basically BOOT with 3 virtual consoles - ATARITT A more TT specific kernel - FALCON A more Falcon specific kernel - HADES A more Hades specific kernel - GENERIC A bulky kernel with a lot of options turned on Browse a bit through the files and copy the one you like most to, say, MYKERNEL. add or change the file to your liking and when you are finished, type: config MYKERNEL. When there are no errors, a new directory is setup for you: /usr/src/sys/arch/atari/compile/MYKERNEL. Go to this directory and type: make depend && make. You'll have some time to drink coffee now ;-) When all goes well, you will have a file called netbsd. This is your newly built kernel. Save your working kernel to netbsd.old, copy the new kernel to wherever you keep your kernels and try booting it. If you went for the -current kernel and config(1) gave error messages, fetch config.tar.gz and rebuild config. WARNING: You should always have a backup of a working kernel at hand! -------------------- 4.10 What do I need to get X11 running? Get the Amiga X11R6.1 distribution from Regensburg, Germany : X11R6.1-01Oct96.README X11R6.1-bin-01Oct96.tar.gz X11R6.1-fonts-01Oct96.tar.gz X11R6.1-include-01Oct96.tar X11R6.1-lib-01Oct96.tar.gz X11R6.1-man-01Oct96.tar.gz This site also has binaries for some popular programs that you might like to download: ghostview, gnuplot, mosaic, xv, xfig, and more... Check out the Amiga binary directory. The Xserver is available from ftp.netbsd.org . There are both color and monochrome versions. If you have a monochrome monitor, you need to use Xdaniver-mfb and call it with the option -FlipPixels. If you want to fiddle with the X-server yourself, also get Xdaniver-1.01.readme and Xdaniver-1.01.src.tar.gz. You need a kernel with 3 views (or at least one more than there are ite's). (The BOOTX kernel of release 1.2 has 4 views.) Make sure the "ST-mem pool" message doesn't appear during system startup. (See question 3.1.) add a line to \etc\rc.local : ldconfig /usr/local/X11R6/lib make a (sym)link from /usr/local/X11R6/bin/X to wherever you put the Xserver. If you need more information about the X Window System, read the Usenet news group comp.windows.x or visit the X Consortium at www.x.org There are several FAQ lists on X and related topics. Start by reading the X FAQ . -------------------- 4.11 Where can I get information about networking services? As always, the man pages provide a starting point. Check networking(4) first. Ask specific questions on the port list. Hubert Feyrer has written a networking faq for NetBSD/Amiga. It is available at rfhs8012.fh-regensburg.de ==================== 5. Hardware configuration -------------------- 5.1 Riebl card jumper settings "top side" +-----------------------------------------------------------------+ | | A++ +-----+ ++ U|| | A | ++ || I|| +-----+ || D || ++ ++ +-+ || VME | | | || | | | C || B | | | || N-+ +-+ || C | +---+ ++ | +---+ B | +-----------------------------------------------------------------+ jumper array A (J1-J6): all to bottom -> BNC (thin Ethernet) all to top -> AUI (thick Ethernet) jumper D (J7) to top -> BNC (according to Udo there should be NO jumper!) to bottom -> AUI jumper array C (J17-J23): all closed -> TT all open -> MegaSTE jumper array B (J8-J10) meaning unknown. Jumpering on Udo's and mine TT-card: closed/open/closed

-------------------- 5.2 Termination on the TT SCSI-bus As you might know, a SCSI-bus should be terminated on both ends of the cable (no more, no less!). On a stock TT, the internal harddisk is on one end of the cable (and thus should always be terminated), the host adapter is in the middle and the external connector is on the other end of the cable.

+---------------+ | | '| | | | (The ' gives the location of the 3 packs - note |===============| that this was supposed to be a top view...) All TT's have sockets for terminators located near the SCSI connector on the back (see picture above). Not all TT's have the resistors inserted. These resistors should be inserted only when no external device is present and be removed otherwise. In the latter case, the external device at the end of the chain should be terminated. -------------------- 5.3 Serial ports (which is which) The following table should clear up some confusion: text devicename driver chip supported see note# =============================================================== serial1 /dev/ser01 68901 No serial2 /dev/ser02 zs0 ZS8530 Yes 1 modem1 /dev/mdm01 ser0 68901 Yes 2/3 modem2 /dev/mdm02 zs0 ZS8530 Yes On the Hades and the Falcon, this port is only available as a 'lan' connector. The Falcon has no connector for this port. You can use this port as a console. When DCD is supplied during the device probing, the mdm01 port will become the system console. 6. Bugs and current development If you find a bug in NetBSD-Atari, first check the FAQ to see if there is some description about it. If not, you can either post a message to the port-atari list or use the send-pr(1) command. In both cases, make sure to provide as much info as possible. Although the relevant info is, of course, dependant on the type of bug, the following things are nearly always important: type of your machine (TT/Falcon/Hades). The amount of memory present. The version of the kernel you are running. The special things you did in the config-file. In case of panics, as much stack-trace as you can provide (the t command in the debugger produces a stack-trace). Try to repoduce the bug and describe how you did it as _exactly_ as you can. If you are interested in the current development of the port, subscribe to the port list. (See question 1.3.) ====================
www@NetBSD.ORG
$NetBSD: faq.html,v 1.6 1997/10/29 14:04:56 leo Exp $
Copyright (c) 1996 Rainer J. H. Brandt. ALL RIGHTS RESERVED.
Copyright (c) 1996, 1997 The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.