summaryrefslogtreecommitdiffstats
path: root/sys/conf/files.sparc64
Commit message (Collapse)AuthorAgeFilesLines
* Replace syscons terminal renderer by a new renderer that uses libteken.ed2009-01-011-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Some time ago I started working on a library called libteken, which is terminal emulator. It does not buffer any screen contents, but only keeps terminal state, such as cursor position, attributes, etc. It should implement all escape sequences that are implemented by the cons25 terminal emulator, but also a fair amount of sequences that are present in VT100 and xterm. A lot of random notes, which could be of interest to users/developers: - Even though I'm leaving the terminal type set to `cons25', users can do experiments with placing `xterm-color' in /etc/ttys. Because we only implement a subset of features of xterm, this may cause artifacts. We should consider extending libteken, because in my opinion xterm is the way to go. Some missing features: - Keypad application mode (DECKPAM) - Character sets (SCS) - libteken is filled with a fair amount of assertions, but unfortunately we cannot go into the debugger anymore if we fail them. I've done development of this library almost entirely in userspace. In sys/dev/syscons/teken there are two applications that can be helpful when debugging the code: - teken_demo: a terminal emulator that can be started from a regular xterm that emulates a terminal using libteken. This application can be very useful to debug any rendering issues. - teken_stress: a stress testing application that emulates random terminal output. libteken has literally survived multiple terabytes of random input. - libteken also includes support for UTF-8, but unfortunately our input layer and font renderer don't support this. If users want to experiment with UTF-8 support, they can enable `TEKEN_UTF8' in teken.h. If you recompile your kernel or the teken_demo application, you can hold some nice experiments. - I've left PC98 the way it is right now. The PC98 platform has a custom syscons renderer, which supports some form of localised input. Maybe we should port PC98 to libteken by the time syscons supports UTF-8? - I've removed the `dumb' terminal emulator. It has been broken for years. It hasn't survived the `struct proc' -> `struct thread' conversion. - To prevent confusion among people that want to hack on libteken: unlike syscons, the state machines that parse the escape sequences are machine generated. This means that if you want to add new escape sequences, you have to add an entry to the `sequences' file. This will cause new entries to be added to `teken_state.h'. - Any rendering artifacts that didn't occur prior to this commit are by accident. They should be reported to me, so I can fix them. Discussed on: current@, hackers@ Discussed with: philip (at 25C3)
* Modularize the Open Firmware client interface to allow run-time switchingnwhitehorn2008-12-201-0/+2
| | | | | | | | | | | | of OFW access semantics, in order to allow future support for real-mode OF access and flattened device frees. OF client interface modules are implemented using KOBJ, in a similar way to the PPC PMAP modules. Because we need Open Firmware to be available before mutexes can be used on sparc64, changes are also included to allow KOBJ to be used very early in the boot process by only using the mutex once we know it has been initialized. Reviewed by: marius, grehan
* Adapt parts of the sparc64 Open Firmware bus enumeration code (in particular,nwhitehorn2008-12-151-1/+0
| | | | | | | | | | | | | | | the code for parsing interrupt maps) to PowerPC and reflect their new MI status by moving them to the shared dev/ofw directory. This commit also modifies the OFW PCI enumeration procedure on PowerPC to allow the bus to find non-firmware-enumerated devices that Apple likes to add, and adds some useful Open Firmware properties (compat and name) to the pnpinfo string of children on OFW SBus, EBus, PCI, and MacIO links. Because of the change to PCI enumeration on PowerPC, X has started working again on PPC machines with Grackle hostbridges. Reviewed by: marius Obtained from: sparc64
* Switch to ath hal source code. Note this removes the ath_halsam2008-12-011-10/+0
| | | | | | | | | | | | | | | | | module; the ath module now brings in the hal support. Kernel config files are almost backwards compatible; supplying device ath_hal gives you the same chip support that the binary hal did but you must also include options AH_SUPPORT_AR5416 to enable the extended format descriptors used by 11n parts. It is now possible to control the chip support included in a build by specifying exactly which chips are to be supported in the config file; consult ath_hal(4) for information.
* Add a driver for `Schizo' Fireplane/Safari to PCI 2.1 and `Tomatillo'marius2008-09-281-0/+1
| | | | | | JBus to PCI 2.2 bridges. In theory, this driver should also handle `XMITS' Fireplane/Safari to PCI-X bridges but due to lack of access to such hardware, support for these hasn't be fleshed out, yet.
* Remove duplicate entry accidentally introduced with r183202.marius2008-09-201-1/+0
|
* Some of the assembly files depend on v9a/v9b-only instructions somarius2008-09-201-3/+8
| | | | | | compile these with -mcpu=ultrasparc (which is the hard-coded default of our system compiler), which allows the remainder of the kernel to be compiled with "only" -mcpu=v9 for reference and testing purposes.
* Add drivers for the power management devices found on Fireplane/marius2008-09-101-0/+2
| | | | | | Safari- and JBus-based machines. Currently the main purpose of these drivers is debugging of the resource allocation on nexus(4) and the register content of these devices though.
* Remove clkbrd(4) as a separate device and compile it solely basedmarius2008-08-231-1/+1
| | | | | | | on the presence of fhc(4) instead; we by far don't support all of the functionality provide by the clock board but in general it's an integral part of FireHose-based systems which shouldn't be possible to omit.
* Remove the MD isa_irq_pending() and the underlying PCI-specificmarius2008-04-261-1/+0
| | | | | | | | | infrastructure. Its only consumer ever was sio(4) and thus was unused on sparc64 since removing the last traces of sio(4) in sparc64 configuration files in favor for uart(4) over three years ago. If similar functionality is required again it should be brought back as an MD intr_pending() which works for all busses by using for example interrupt controller hooks.
* The Sun disk label only uses 16-bit fields for cylinders, heads andmarius2008-02-111-0/+1
| | | | | | | | | | | | | | sectors so the geometry of large IDE disks has to be adjusted. This corresponds to what the OpenSolaris dad(7D) driver does except that the latter only tweaks sectors and effectively limits the mediasize to 128GB so the cylinders and heads fields won't ever overflow. Not limiting the mediasize is a compromise between allowing to use Sun disk label as far as possible and being able to use the entire disk with another disk label. This allows to use the full capacity of large IDE disks if they were not labeled under (Open)Solaris (in both ways of the meaning). MFC after: 2 weeks
* Break out stack(9) from ddb(4):rwatson2007-12-021-0/+1
| | | | | | | | | | | | | | | | | | | | - Introduce per-architecture stack_machdep.c to hold stack_save(9). - Introduce per-architecture machine/stack.h to capture any common definitions required between db_trace.c and stack_machdep.c. - Add new kernel option "options STACK"; we will build in stack(9) if it is defined, or also if "options DDB" is defined to provide compatibility with existing users of stack(9). Add new stack_save_td(9) function, which allows the capture of a stacktrace of another thread rather than the current thread, which the existing stack_save(9) was limited to. It requires that the thread be neither swapped out nor running, which is the responsibility of the consumer to enforce. Update stack(9) man page. Build tested: amd64, arm, i386, ia64, powerpc, sparc64, sun4v Runtime tested: amd64 (rwatson), arm (cognet), i386 (rwatson)
* Commit the change from FAST_IPSEC to IPSEC. The FAST_IPSECgnn2007-07-031-3/+2
| | | | | | | | option is now deprecated, as well as the KAME IPsec code. What was FAST_IPSEC is now IPSEC. Approved by: re Sponsored by: Secure Computing
* - Move ofw_pci_alloc_busno() to the ofw_pci KOBJ interface,marius2007-06-181-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | allowing the driver for the host-PCI-bridge to indicate that reenumeration of the PCI busses isn't supported by returning -1 instead of a valid PCI bus number. This is needed in order support both Tomatillo, which don't support reenumeration and thus are apparently intended to be used for independently numbered PCI domains only, and Psycho bridges, whose busses need to be reenumerated on at least some E450, without the #ifndef currently used for sun4v in order to support multiple independently PCI domains. The actual allocation/incrementation of the PCI bus numbers is now done in psycho(4), though it no longer establish a mapping between bus numbers and device nodes like ofw_pci_alloc_busno() did as that functionality wasn't used (but can easily brought back if really needed). The now no longer used sys/sparc64/pci/ofw_pci.c is also removed from sys/conf/files.sun4v as ofw_pci_alloc_busno() wasn't used there in the first place. - In ofw_pci_default_{adjust_busrange,intr_pending}() sanity check that the device has a parent before passing it on. - Make psycho_softcs static to sys/sparc64/pci/psycho.c as it's not used outside of that module. - In sys/sparc64/pci/ofw_pcib_subr.c remove the superfluous inclusion of opt_global.h and correct the debug output for adjusting the subordinate bus number.
* Move the gallant 12 x 22 font data from a .h to a .c so it doesn't needmarius2007-06-161-0/+1
| | | | | | | to be compiled into every driver making use of it. Use a const instance of struct gfb_font for this as the font isn't intended to be changed at run-time and in order to accompany the font data with height and width info.
* Use default options for default partitioning schemes, rather thanmarcel2007-06-111-4/+0
| | | | | | | | making the relevant files standard. This avoids duplication and makes it easier to override/disable unwanted schemes. Since ARM doesn't have a DEFAULTS configuration file, leave the source files for the BSD and MBR partitioning schemes in files.arm for now.
* Rototill the sparc64 nexus(4) (actually this brings in the code themarius2007-03-071-2/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | sun4v nexus(4) in turn is based on): o Change nexus(4) to manage the resources of its children so the respective device drivers don't need to figure them out of OFW themselves. o Change nexus(4) to provide the ofw_bus KOBJ interface instead of using IVARs for supplying the OFW node and the subset of standard properties of its children. Together with the previous change this also allows to fully take advantage of newbus in that drivers like fhc(4), which attach on multiple parent busses, no longer require different bus front-ends as obtaining the OFW node and properties as well as resource allocation works the same for all supported busses. As such this change also is part 4/4 of allowing creator(4) to work in USIII-based machines as it allows this driver to attach on both nexus(4) and upa(4). On the other hand removing these IVARs breaks API compatibility with the powerpc nexus(4) but which isn't that bad as a) sparc64 currently doesn't share any device driver hanging off of nexus(4) with powerpc and b) they were no longer compatible regarding OFW-related extensions at the pci(4) level since quite some time. o Provide bus_get_dma_tag methods in nexus(4) and its children in order to handle DMA tags in a hierarchical way and get rid of the sparc64_root_dma_tag kludge. Together with the previous two items this changes also allows to completely get rid of the nexus(4) IVAR interface. It also includes: - pushing the constraints previously specified by the nexus_dmatag down into the DMA tags of psycho(4) and sbus(4) as it's their IOMMUs which induce these restrictions (and nothing at the nexus(4) or anything that would warrant specifying them there), - fixing some obviously wrong constraints of the psycho(4) and sbus(4) DMA tags, which happened to not actually be used with the sparc64_root_dma_tag kludge in place and therefore didn't cause problems so far, - replacing magic constants for constraints with macros as far as it is obvious as to where they come from. This doesn't include taking advantage of the newbus way to get the parent DMA tags implemented by this change in order to divorce the IOTSBs of the PCI and SBus IOMMUs or for implementing the workaround for the DMA sync bug in Sabre (and Tomatillo) bridges, yet, though. o Get rid of the notion that nexus(4) (mostly) reflects an UPA bus by replacing ofw_upa.h and with ofw_nexus.h (which was repo-copied from ofw_upa.h) and renaming its content, which actually applies to all of Fireplane/Safari, JBus and UPA (in the host bus case), as appropriate. o Just use M_DEVBUF instead of a separate M_NEXUS malloc type for allocating the device info for the children of nexus(4). This is done in order to not need to export M_NEXUS when deriving drivers for subordinate busses from the nexus(4) class. o Use the DEFINE_CLASS_0() macro to declare the nexus(4) driver so we can derive subclasses from it. o Const'ify the nexus_excl_name and nexus_excl_type arrays as well as add 'associations' and 'rsc', which are pseudo-devices without resources and therefore of no real interest for nexus(4), to the former. o Let the nexus(4) device memory rman manage the entire 64-bit address space instead of just the UPA_MEMSTART to UPA_MEMEND subregion as Fireplane/Safari- and JBus-based machines use multiple ranges, which can't be as easily divided as in the case of UPA (limiting the address space only served for sanity checking anyway). o Use M_WAITOK instead of M_NOWAIT when allocating the device info for children of nexus(4) in order to give one less opportunity for adding devices to nexus(4) to fail. o While adapting the drivers affected by the above nexus(4) changes, change them to take advantage of rman_get_rid() instead of caching the RIDs assigned to allocated resources, now that the RIDs of resources are correctly set. o In iommu(4) and nexus(4) replace hard-coded functions names, which actually became outdated in several places, in panic strings and status massages with __func__. [1] o Use driver_filter_t in prototypes where appropriate. o Add my copyright to creator(4), fhc(4), nexus(4), psycho(4) and sbus(4) as I changed considerable amounts of these drivers as well as added a bunch of new features, workarounds for silicon bugs etc. o Fix some white space nits. Due to lack of access to Exx00 hardware, these changes, i.e. central(4) and fhc(4), couldn't be runtime tested on such a machine. Exx00 are currently reported to panic before trying to attach nexus(4) anyway though. PR: 76052 [1] Approved by: re (kensmith)
* Add front-ends for the 'lebuffer' variants found on some SBus cards.marius2007-01-201-0/+2
| | | | | | | | | These are shared-memory variants based on Am79C90-compatible chips that apart from the missing DMA engine are similar to the 'ledma' variant including using a (pseudo-)bus/device for the buffer that the actual LANCE device hangs off from. The performance of these is close to that of the 'ledma' one, like expected at a few times the CPU load though.
* Resurrect upa(4), now used for the subordinate/slave UPA bridge andmarius2007-01-161-0/+1
| | | | | | | | bus hanging off from the Fireplane/Safari bus in some USIII machines. This is part 3/4 of allowing creator(4) to work in these machines. The little info needed on how to configure the bridge and to work around the incorrect values contained in the `interrupts' properties of its children were obtained form OpenSolaris.
* - Merge sys/sparc64/creator/creator_upa.c into sys/dev/fb/creator.c.marius2007-01-161-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The separate bus front-end was inherited from the OpenBSD creator(4), which at that time had a mainbus(4) (for USI/II machines, which use an UPA interconnection bus as the nexus) and an upa(4) (for USIII machines, which use a subordinate/slave UPA bus hanging off from the Fireplane/Safari interconnection bus) front-end. With FreeBSD and newbus there is/will be no need to have two separate bus front-ends for these busses, so we can easily coallapse the shared front-end and the back-end into a single source file (note that the FreeBSD creator_upa.c was misnomer anyway; based on what it actually attached to that should have been creator_nexus.c), actually OpenBSD meanwhile also has moved to a shared front-end and a single source file. Due to the low-level console support creator.c also wasn't free from bus related things before. While at it, also split sys/sparc64/creator/creator.h into a sys/dev/fb/creatorreg.h that only contains register macros and move the structures to the top of sys/dev/fb/creator.c as suggested by style(9) so creator(4) is no longer scattered over two directories. - Use OF_decode_addr()/sparc64_fake_bustag() to obtain the bus tags and handles for the low-level console support instead of hardcoding support for AFB/FFB hanging off from nexus(4) only. This is part 2/4 of allowing creator(4) to work in USIII machines (which have a UPA bus hanging off from the Fireplane/Safari bus reflected by the nexus), which already makes it work as the low-level console there. - Allocate resources in the bus attach routine regardless of whether creator(4) is used as for the low-level console and thus the required bus tags and handles have been already obtained or not so the resources are marked as taken in the respective RMAN. - For both obtaining the bus tags and handles for the low-level console support as well as allocating the corresponding resources in the regular bus attach routine don't bother to get all for the maximum of 24 register banks but only (for) the two tag/handle pairs required for providing the video interface for syscons(4) support. If we can't allocate the rest of them just limit the memory range accessible via creator_fb_mmap() accordingly. - Sanity check the memory range spanned by the first and last resources and the resources in between as far as possible, as the XFree86/Xorg sunffb(4) expects to be able to access the whole region, even though the backing resources are actually non-continuous. Limit and check the memory range accessible via creator_fb_mmap() accordingly. - Reduce the size of buffers for OFW properties to what they actually need to hold. - Rename some tables to creator_<foo> for consistency. - Also for the sizes in the creator_fb_mmap() mapping table entries use macros for consistency, add macros for the remaining register banks for completeness.
* opt_ah.h ends up copied into a kernelcompile directory in somemjacob2006-12-181-1/+1
| | | | | | | | | | | aches as a read-only file. In a number of cases this has led to compiles failing- usually due to some strange NFS drift which thinks that the opt_ah.h in the compile directory is out of date wrt the source it is copied from. When the copy is executed again, it fails because the target is read-only. Oops. Modify the compile hooks avoid this. Discussed with a while back with: Sam Leffler
* - In sunkbd_probe_keyboard() don't bother to determine the keyboard layoutmarius2006-11-021-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | as we have no use for that info. Instead let this function return the keyboard ID and verify at its invocation in sunkbd_configure() that we're talking to a Sun type 4/5/6 keyboard, i.e. a keyboard supported by this driver. - Add an option SUNKBD_EMULATE_ATKBD whose code is based on the respective code in ukbd(4) and like UKBD_EMULATE_ATSCANCODE causes this driver to emit AT keyboard/KB_101 compatible scan codes in K_RAW mode as assumed by kbdmux(4). Unlike UKBD_EMULATE_ATSCANCODE, SUNKBD_EMULATE_ATKBD also triggers the use of AT keyboard maps and thus allows to use the map files in share/syscons/keymaps with this driver at the cost of an additional translation (in ukbd(4) this just is the way of operation). - Implement an option SUNKBD_DFLT_KEYMAP, which like the equivalent options of the other keyboard drivers allows to specify the default in-kernel keyboard map. For obvious reasons this made to only work when also using SUNKBD_EMULATE_ATKBD. - Implement sunkbd_check(), sunkbd_check_char() and sunkbd_clear_state(), which are also required for interoperability with kbdmux(4). - Implement K_CODE mode and FreeBSD keypad compose. - As a minor hack define KBD_DFLT_KEYMAP also in the !SUNKBD_EMULATE_ATKBD case so we can obtain fkey_tab from <dev/kbd/kbdtables.h> rather than having to duplicate it and #ifdef some more code. - Don't use the TX-buffer for writing the two command bytes for setting the keyboard LEDs as this consequently requires a hardware FIFO that is at least two bytes in depth, which the NMOS-variant of the Zilog SCCs doesn't have. Thus use an inlined version of uart_putc() to consecutively write the command bytes (a cleaner approach would be to do this via the soft interrupt handler but that variant wouldn't work while in ddb(4)). [1] - Fix some minor style(9) bugs. PR: 90316 [1] Reviewed by: marcel [1]
* Move "device splash" back to MI NOTES and "files", it's MI.ru2006-10-231-1/+0
|
* Move MI parts of syscons into MI "files".ru2006-10-231-7/+0
|
* add ath_hal gluesam2006-03-141-0/+9
| | | | MFC after: 3 days
* Retire NETSMBCRYPTO as a kernel option and make its functionalityyar2006-03-051-1/+1
| | | | | | | | | | | | | | | enabled by default in NETSMB and smbfs.ko. With the most of modern SMB providers requiring encryption by default, there is little sense left in keeping the crypto part of NETSMB optional at the build time. This will also return smbfs.ko to its former properties users are rather accustomed to. Discussed with: freebsd-stable, re (scottl) Not objected by: bp, tjr (silence) MFC after: 5 days
* Hook up le(4) to the build. For now it's only added to the sparc64 GENERICmarius2006-01-311-0/+1
| | | | | | | in order to support the on-board LANCE in Ultra 1 and to the MI NOTES as it should work just fine with the AMD PCnet family of chips on all archs but is not yet meant to replace lnc(4). If a kernel includes all of le(4), lnc(4) and pcn(4) precedence is given to lnc(4)/pcn(4) for now.
* Make config(8) understand ORed dependecies in "files*" andru2005-11-271-19/+11
| | | | improve tracking of known devices. Bump config(8) version.
* Conditionalize the compilation of the envctrl.c front-end of pcf(4)marius2005-11-221-1/+1
| | | | | | additionally on ebus(4) as the 'SUNW,envctrl' devices (as well as 'SUNW,envctrltwo' and 'SUNW,rasctrl', which we might want to also support in envctrl.c in the future) are only found on EBus.
* - Add a new method ofw_bus_default_get_devinfo() that allows to retrievemarius2005-11-221-0/+1
| | | | | | | | | | | | | | | | a newly introduced struct ofw_bus_devinfo which can hold the OFW info of a device recallable via the ofw_bus KOBJ interface. Introduce a set of functions ofw_bus_gen_get_*() which use ofw_bus_default_get_devinfo() to provide generic subroutines for implementing the rest of the ofw_bus KOBJ interface in a bus driver. This is inspired by bus_get_resource_list() and bus_generic_rl_*_resource() and allows to reduce code duplication in bus drivers as they only have to provide an ofw_bus_default_get_devinfo() implementation in order to provide the ofw_bus KOBJ interface via ofw_bus_gen_get_*(). - While here add a comment to ofw_bus_if.m describing the intention of the ofw_bus KOBJ interface. Reviewed by: marcel
* Finally complete some work on generalizing the PCF8584-based I2Cjoerg2005-10-281-0/+2
| | | | | | | | | | | drivers I started quite some time before. Retire the old i386-only pcf driver, and activate the new general driver that has been sitting in the tree already for quite some time. Build the i2c modules for sparc64 architectures as well (where I've been developing all this on).
* Refactor the NETSMBCRYPTO option so that it does the same on allmarcel2005-06-121-2/+3
| | | | | | | | platforms. ARM is excluded as it doesn't yet have any crypto sources. Approved by: re (dwhite) MFC after: 1 day
* - Hook up atkbdc(4), atkbd(4) and psm(4) to the sparc64 build, notmarius2005-06-101-0/+13
| | | | | | enabled in GENERIC by default, yet. - While here remove the exclusion of ukbd(4) from the sparc64 NOTES as ukbd(4) compiles and works on sparc64.
* MFP4:jkoshy2005-06-091-0/+1
| | | | | | | | | | | | | | | | - Implement sampling modes and logging support in hwpmc(4). - Separate MI and MD parts of hwpmc(4) and allow sharing of PMC implementations across different architectures. Add support for P4 (EMT64) style PMCs to the amd64 code. - New pmcstat(8) options: -E (exit time counts) -W (counts every context switch), -R (print log file). - pmc(3) API changes, improve our ability to keep ABI compatibility in the future. Add more 'alias' names for commonly used events. - bug fixes & documentation.
* - Hook up machfb(4) to the sparc64 build, not enabled in GENERICmarius2005-05-211-0/+1
| | | | | | | by default, yet. - Replace "graphics cards" with "framebuffers" in the description of creator(4) in order to make it uniform with the description of machfb(4) and the latter occur both on-board and as add-on cards.
* Sync with the other files.<arch> files and put the keyboard mapmarius2005-05-191-7/+7
| | | | | generation stuff at the beginning of this file as well as add a dependency on dev/kbd/kbd.c for ukbd(4).
* - Collapse eeprom_ebus.c and eeprom_sbus.c into eeprom.c andmarius2005-05-191-4/+3
| | | | | | | | | | | | eeprom_ebus_attach() and eeprom_sbus_attach() into eeprom_attach() respectively. Since the introduction of the ofw_bus interface some time ago and now that ebus(4) also uses SYS_RES_MEMORY for the memory resources since ebus.c rev. 1.22 there is no longer a need to have separate front-ends for ebus(4), fhc(4) and sbus(4). - Fail gracefully instead of panicing when the model can't be determined. - Don't leak resources when mk48txx_attach() fails. - Use FBSDID.
* - Try to not leak resources in the attach functions of the esp(4) SBusmarius2005-05-191-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | front-end and the LSI64854 and NCR53C9x code in case one of these functions fails. Add detach functions to these parts and make esp(4) detachable. - Revert rev. 1.7 of esp_sbus.c, since rev. 1.34 of sbus.c the clockfreq IVAR defaults to the per-child values. - Merge ncr53c9x.c rev. 1.111 from NetBSD (partial): On reset, clear state flags and the msgout queue. In NetBSD code to notify the upper layer (i.e. CAM in FreeBSD) on reset was also added with this revision. This is believed to be not necessary in FreeBSD and was not merged. This makes ncr53c9x.c to be in sync with NetBSD up to rev. 1.114. - Conditionalize the LSI64854 support on sbus(4) only instead of sbus(4) and esp(4) as it's also required for the 'dma', 'espdma' and 'ledma' busses/devices as well as the 'SUNW,bpp' device (printer port) which all hang off of sbus(4). - Add a driver for the 'dma', 'espdma' and 'ledma' (pseudo-)busses/ devices. These busses and devices actually represent the LSI64854 DMA engines for the ESP SCSI and LANCE Ethernet controllers found on the SBus of Ultra 1 and SBus add-on cards. With 'espdma' and 'ledma' the 'esp' and 'le' devices hang off of the respective DMA bus instead of directly from the SBus. The 'dma' devices are either also used in this manner or on some add-on cards also as a companion device to an 'esp' device which also hangs off directly from the SBus. With the latter variant it's a bit tricky to glue the DMA engine to the core logic of the respective 'esp' device. With rev. 1.35 of sbus.c we are however guaranteed that such a 'dma' device is probed before the respective 'esp' device which simplifies things a lot. [1] - In the esp(4) SBus front-end read the part-unique ID code of Fast-SCSI capable chips the right way. This fixes erroneously detecting some chips as FAS366 when in fact they are not. Add explicit checks for the FAS100A, FAS216 and FAS236 variants instead treating all of these as ESP200. That way we can correctly set the respective Fast-SCSI config bits instead of driving them out of specs. This includes adding the FAS100A and FAS236 variants to the NCR53C9x core code. We probably still subsume some chip variants as ESP200 while in fact they are another variant which however shouldn't really matter as this will only happen when these chips are driven at 25MHz or less which implies not being able to run Fast-SCSI. [3] - Add a workaround to the NCR53C9x interrupt handler which ignores the stray interrupt generated by FAS100A when doing path inquiry during boot and which otherwiese would trigger a panic. - Add support for the 'esp' devices hanging off of a 'dma' or 'espdma' busses or which are companions of 'dma' devices to esp(4). In case of the variants that hang off of a DMA device this is a bit hackish as esp(4) then directly uses the softc of the respective parent to talk to the DMA engine. It might make sense to add an interface for this in order to implement this in a cleaner way however it's not yet clear how the requirements for the LANCE Ethernet controllers are and the hack works for now. [2] This effectively adds support for the onboard SCSI controller in Ultra 1 as well as most of the ESP-based SBus add-on cards to esp(4). With this the code for supporting the Performance Technologies SBS430 SBus SCSI add-on cards is also largely in place the remaining bits were however omitted as it's unclear from the NetBSD how to couple the DMA engine and the core logic together for these cards. Obtained from: OpenBSD [1] Obtained from: NetBSD [2] Clue from: BSD/OS [3] Reviewed by: scottl (earlier version) Tested with: FSBE/S add-on card (FAS236), SSHA add-on card (ESP100A), Ultra 1 (onboard FAS100A), Ultra 2 (onboard FAS366)
* Divorce critical sections from spinlocks. Critical sections as denoted byjhb2005-04-041-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | critical_enter() and critical_exit() are now solely a mechanism for deferring kernel preemptions. They no longer have any affect on interrupts. This means that standalone critical sections are now very cheap as they are simply unlocked integer increments and decrements for the common case. Spin mutexes now use a separate KPI implemented in MD code: spinlock_enter() and spinlock_exit(). This KPI is responsible for providing whatever MD guarantees are needed to ensure that a thread holding a spin lock won't be preempted by any other code that will try to lock the same lock. For now all archs continue to block interrupts in a "spinlock section" as they did formerly in all critical sections. Note that I've also taken this opportunity to push a few things into MD code rather than MI. For example, critical_fork_exit() no longer exists. Instead, MD code ensures that new threads have the correct state when they are created. Also, we no longer try to fixup the idlethreads for APs in MI code. Instead, each arch sets the initial curthread and adjusts the state of the idle thread it borrows in order to perform the initial context switch. This change is largely a big NOP, but the cleaner separation it provides will allow for more efficient alternative locking schemes in other parts of the kernel (bare critical sections rather than per-CPU spin mutexes for per-CPU data for example). Reviewed by: grehan, cognet, arch@, others Tested on: i386, alpha, sparc64, powerpc, arm, possibly more
* Add a driver for the 'clock-board' device (the clock board is anmarius2005-03-191-0/+1
| | | | | | | | | | | | inevitable component in Sun Exx00 machines and provides serial ports, NVRAM and TOD amongst others which are handled by uart(4) and eeprom(4) respectively). This driver currently only prints out information about the chassis on attach and allows to blink the 'Cycling' LED (which is duplicated on the front panel) of the clock board just like fhc(4) does for the other boards. The device name for the LED is /dev/led/clockboard. Obtained from: OpenBSD Tested by: joerg
* Back out no longer necessary work-arounds added in rev. 1.59 for buildingmarius2005-02-121-5/+3
| | | | SBus-only kernels regarding ofw_machdep.c.
* Add a front-end for the `rtc' device which is a MC146818 compatiblemarius2004-11-171-0/+2
| | | | | | | | clock found on the ISA bus (some USIIe, USIIi and USIIIi models) and EBus (USIII models) instead of a MK48Txx clock. Testet by: Matthew T. Lager" <freebsd@trinetworks.com> on Sun Fire V100, Xavier Beaudouin <kiwi@oav.net> on Netra X1 (initial version)
* Fix paths after repocopies done by scottltrhodes2004-11-101-1/+1
| | | | | Reviewed by: marius OK'ed by: scottl
* Device driver for onboard CS4231 audio controller which is foundyongari2004-10-251-0/+3
| | | | | | | | | | | | | | | on UltraSPARC workstations. The driver is based on OpenBSD's SBus cs4231 driver and heavily modified to incorporate into sound(4) infrastructure. Due to the lack of APCDMA documentation, the DMA code of SBus cs4231 came from OpenBSD's driver. The driver runs without Giant lock and supports both SBus and EBus based CS4231 audio controller. Special thanks to marius for providing feedbacks during the driver writing. His feedback made it possible to write hiccup free playback code under high system loads. Approved by: jake (mentor) Reviewed by: marius (initial version) Tested by: marius, kwm, Julian C. Dunn(jdunn AT opentrend DOT net)
* Port NetBSD auxio driver. The driver was modified to use led(4) and canyongari2004-10-091-0/+2
| | | | | | | | | | | be used to announce various system activity. The auxio device provides auxiliary I/O functions and is found on various SBus/EBus UltraSPARC models. At present, only front panel LED is controlled by this driver. Approved by: jake (mentor) Reviewed by: joerg Tested by: joerg
* Add a kludge for building SBus-only kernels, i.e. kernels without supportmarius2004-08-151-3/+5
| | | | | | | | | for EBus, ISA and PCI, by compiling ofw_isa.c and ofw_pci_if.m unconditio- nally. The correct way is to rewrite OF_decode_addr() in ofw_machdep.c in a bus-neutral way. That's certainly possible but we unfortunately didn't make it for FreeBSD 5.3. Approved by: tmm
* sio(4), which never really worked on sparc64, was removed in favour ofmarius2004-08-151-2/+0
| | | | | uart(4) in sparc64/conf/GENERIC revision 1.63 about 9 months ago. Remove its source files here, too.
* - Introduce an ofw_bus kobj-interface for retrieving the OFW node and amarius2004-08-121-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | subset ("compatible", "device_type", "model" and "name") of the standard properties in drivers for devices on Open Firmware supported busses. The standard properties "reg", "interrupts" und "address" are not covered by this interface because they are only of interest in the respective bridge code. There's a remaining standard property "status" which is unclear how to support properly but which also isn't used in FreeBSD at present. This ofw_bus kobj-interface allows to replace the various (ebus_get_node(), ofw_pci_get_node(), etc.) and partially inconsistent (central_get_type() vs. sbus_get_device_type(), etc.) existing IVAR ones with a common one. This in turn allows to simplify and remove code-duplication in drivers for devices that can hang off of more than one OFW supported bus. - Convert the sparc64 Central, EBus, FHC, PCI and SBus bus drivers and the drivers for their children to use the ofw_bus kobj-interface. The IVAR- interfaces of the Central, EBus and FHC are entirely replaced by this. The PCI bus driver used its own kobj-interface and now also uses the ofw_bus one. The IVARs special to the SBus, e.g. for retrieving the burst size, remain. Beware: this causes an ABI-breakage for modules of drivers which used the IVAR-interfaces, i.e. esp(4), hme(4), isp(4) and uart(4), which need to be recompiled. The style-inconsistencies introduced in some of the bus drivers will be fixed by tmm@ in a generic clean-up of the respective drivers later (he requested to add the changes in the "new" style). - Convert the powerpc MacIO bus driver and the drivers for its children to use the ofw_bus kobj-interface. This invloves removing the IVARs related to the "reg" property which were unused and a leftover from the NetBSD origini of the code. There's no ABI-breakage caused by this because none of these driver are currently built as modules. There are other powerpc bus drivers which can be converted to the ofw_bus kobj-interface, e.g. the PCI bus driver, which should be done together with converting powerpc to use the OFW PCI code from sparc64. - Make the SBus and FHC front-end of zs(4) and the sparc64 eeprom(4) take advantage of the ofw_bus kobj-interface and simplify them a bit. Reviewed by: grehan, tmm Approved by: re (scottl) Discussed with: tmm Tested with: Sun AX1105, AXe, Ultra 2, Ultra 60; PPC cross-build on i386
* Break out the MI part of the /dev/[k]mem and /dev/io drivers intomarkm2004-08-011-1/+1
| | | | | | | | their own directory and module, leaving the MD parts in the MD area (the MD parts _are_ part of the modules). /dev/mem and /dev/io are now loadable modules, thus taking us one step further towards a kernel created entirely out of modules. Of course, there is nothing preventing the kernel from having these statically compiled.
* Hook the GDB backend into the build.marcel2004-07-101-0/+1
|
OpenPOWER on IntegriCloud