d/freebsd-skq
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
4f8d3e6851
freebsd-skq/sys/conf/files.sparc64

138 lines
5.5 KiB
Plaintext
Raw Normal View History

Add a Makefile, ldscript, and config magic for sparc64. This is tailored to build with a cross compiler alongside the standard compiler; it would be more desirable to build in a chroot.
2001-08-03 01:09:10 +00:00
# This file tells config what files go into building a kernel,
# files marked standard are always included.
#
# $FreeBSD$
#
# The long compile-with and dependency lines are required because of
# limitations in config: backslash-newline doesn't work in strings, and
# dependency lines other than the first are silently ignored.
#
- Hook up atkbdc(4), atkbd(4) and psm(4) to the sparc64 build, not 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.
2005-06-10 20:58:59 +00:00
atkbdmap.h optional atkbd_dflt_keymap \
compile-with "/usr/sbin/kbdcontrol -L ${ATKBD_DFLT_KEYMAP} | sed -e 's/^static keymap_t.* = /static keymap_t key_map = /' -e 's/^static accentmap_t.* = /static accentmap_t accent_map = /' > atkbdmap.h" \
no-obj no-implicit-rule before-depend \
clean "atkbdmap.h"
#
- In sunkbd_probe_keyboard() don't bother to determine the keyboard layout 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]
2006-11-02 00:01:15 +00:00
sunkbdmap.h optional sunkbd_dflt_keymap \
compile-with "/usr/sbin/kbdcontrol -L ${SUNKBD_DFLT_KEYMAP} | sed -e 's/^static keymap_t.* = /static keymap_t key_map = /' -e 's/^static accentmap_t.* = /static accentmap_t accent_map = /' > sunkbdmap.h" \
no-obj no-implicit-rule before-depend \
clean "sunkbdmap.h"
#
Sync with the other files.<arch> files and put the keyboard map generation stuff at the beginning of this file as well as add a dependency on dev/kbd/kbd.c for ukbd(4).
2005-05-19 22:56:00 +00:00
ukbdmap.h optional ukbd_dflt_keymap \
compile-with "/usr/sbin/kbdcontrol -L ${UKBD_DFLT_KEYMAP} | sed -e 's/^static keymap_t.* = /static keymap_t key_map = /' -e 's/^static accentmap_t.* = /static accentmap_t accent_map = /' > ukbdmap.h" \
no-obj no-implicit-rule before-depend \
clean "ukbdmap.h"
#
Commit the change from FAST_IPSEC to IPSEC. The FAST_IPSEC 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
2007-07-03 12:13:45 +00:00
crypto/blowfish/bf_enc.c optional crypto | ipsec
crypto/des/des_enc.c optional crypto | ipsec | netsmb
- Hook up atkbdc(4), atkbd(4) and psm(4) to the sparc64 build, not 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.
2005-06-10 20:58:59 +00:00
dev/atkbdc/atkbd.c optional atkbd atkbdc
dev/atkbdc/atkbd_atkbdc.c optional atkbd atkbdc
dev/atkbdc/atkbdc.c optional atkbdc
dev/atkbdc/atkbdc_ebus.c optional atkbdc ebus
dev/atkbdc/atkbdc_isa.c optional atkbdc isa
dev/atkbdc/atkbdc_subr.c optional atkbdc
dev/atkbdc/psm.c optional psm atkbdc
Make config(8) understand ORed dependecies in "files*" and improve tracking of known devices. Bump config(8) version.
2005-11-27 21:41:58 +00:00
dev/auxio/auxio.c optional auxio sbus | auxio ebus
Add the esp(4) files. Two of them are sbus-specific and therefore only apply to sparc64.
2004-06-10 05:21:44 +00:00
dev/esp/esp_sbus.c optional esp sbus
Hook syscons and the creator driver up to the sparc64. This compiles but will not link due to missing keyboard drivers.
2003-08-24 01:54:06 +00:00
dev/fb/creator.c optional creator sc
dev/fb/fb.c optional sc
Move the gallant 12 x 22 font data from a .h to a .c so it doesn't need 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.
2007-06-16 21:48:50 +00:00
dev/fb/gallant12x22.c optional sc
- Hook up machfb(4) to the sparc64 build, not enabled in GENERIC 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.
2005-05-21 20:50:45 +00:00
dev/fb/machfb.c optional machfb sc
MFP4: - 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.
2005-06-09 19:45:09 +00:00
dev/hwpmc/hwpmc_sparc64.c optional hwpmc
Pull in kbd.c with usb2_input_kbd, just like ukbd.
2009-02-15 20:24:21 +00:00
dev/kbd/kbd.c optional atkbd | sc | ukbd | usb2_input_kbd
Add front-ends for the 'lebuffer' variants found on some SBus cards. 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.
2007-01-20 12:53:30 +00:00
dev/le/if_le_lebuffer.c optional le sbus
Hook up le(4) to the build. For now it's only added to the sparc64 GENERIC 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.
2006-01-31 22:34:13 +00:00
dev/le/if_le_ledma.c optional le sbus
Add front-ends for the 'lebuffer' variants found on some SBus cards. 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.
2007-01-20 12:53:30 +00:00
dev/le/lebuffer_sbus.c optional le sbus
Modularize the Open Firmware client interface to allow run-time switching 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
2008-12-20 00:33:10 +00:00
dev/ofw/ofw_if.m standard
- Introduce an ofw_bus kobj-interface for retrieving the OFW node and a 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
2004-08-12 17:41:33 +00:00
dev/ofw/ofw_bus_if.m standard
- Add a new method ofw_bus_default_get_devinfo() that allows to retrieve 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
2005-11-22 16:37:45 +00:00
dev/ofw/ofw_bus_subr.c standard
Modularize the Open Firmware client interface to allow run-time switching 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
2008-12-20 00:33:10 +00:00
dev/ofw/ofw_standard.c standard
Add counter.c and sbus.c. Unify style.
2002-02-13 16:29:51 +00:00
dev/ofw/ofw_console.c optional ofw_console
Add emul.c and in_cksum.c, make the OpenFirmware console driver optional, reorder a bit.
2001-11-06 20:25:44 +00:00
dev/ofw/openfirm.c standard
Build openfirmio on sparc64.
2002-10-18 15:27:02 +00:00
dev/ofw/openfirmio.c standard
Hook openpromio up to the build.
2003-06-19 18:06:58 +00:00
dev/ofw/openpromio.c standard
Conditionalize the compilation of the envctrl.c front-end of pcf(4) 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.
2005-11-22 17:25:10 +00:00
dev/pcf/envctrl.c optional pcf ebus
Finally complete some work on generalizing the PCF8584-based I2C 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).
2005-10-28 15:58:19 +00:00
dev/pcf/pcf_ebus.c optional pcf ebus
Make config(8) understand ORed dependecies in "files*" and improve tracking of known devices. Bump config(8) version.
2005-11-27 21:41:58 +00:00
dev/sound/sbus/cs4231.c optional snd_audiocs ebus | \
snd_audiocs sbus
Hook syscons and the creator driver up to the sparc64. This compiles but will not link due to missing keyboard drivers.
2003-08-24 01:54:06 +00:00
dev/syscons/scgfbrndr.c optional sc
Replace syscons terminal renderer by a new renderer that uses libteken. 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)
2009-01-01 13:26:53 +00:00
dev/syscons/scterm-teken.c optional sc
Hook syscons and the creator driver up to the sparc64. This compiles but will not link due to missing keyboard drivers.
2003-08-24 01:54:06 +00:00
dev/syscons/scvtb.c optional sc
Replace syscons terminal renderer by a new renderer that uses libteken. 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)
2009-01-01 13:26:53 +00:00
dev/syscons/teken/teken.c optional sc
Hook-up the uart(4) driver to the build. For a detailed description of what uart(4) is and/or is not see the initial commit log of one of the files in sys/dev/uart (or see share/man/man4/uart.4). Note that currently pc98 shares the MD file with i386. This needs to change when pc98 support is fleshed-out to properly support the various UARTs. A good example is sparc64 in this respect. We build uart(4) as a module on all platforms. This may break the ppc port. That depends on whether they do actually build modules. To use uart(4) on alpha, one must use the NO_SIO option.
2003-09-06 23:23:26 +00:00
dev/uart/uart_cpu_sparc64.c optional uart
Add a uart attachment/syscons keyboard driver for sun keyboards. In theory this will work with any uart backend, currently supported hardware uses either ns8250 or z8530.
2003-11-11 07:33:24 +00:00
dev/uart/uart_kbd_sun.c optional uart sc
Add kern/syscalls.c, which is needed for some KTR traces in trap.c.
2002-03-25 05:01:05 +00:00
kern/syscalls.c optional ktr
Re-add libkern/ffs.c. I thought sparc64 had an inline version, but failed to notice that it's #if 0'ed out.
2004-01-14 08:38:13 +00:00
libkern/ffs.c standard
Add ffsl(), fls() flsl() to platforms that don't already have them.
2004-01-13 15:37:23 +00:00
libkern/ffsl.c standard
libkern/fls.c standard
libkern/flsl.c standard
Add memmove() to the kernel, making the kernel compile with Clang. When copying big structures, LLVM generates calls to memmove(), because it may not be able to figure out whether structures overlap. This caused linker errors to occur. memmove() is now implemented using bcopy(). Ideally it would be the other way around, but that can be solved in the future. On ARM we don't do add anything, because it already has memmove(). Discussed on: arch@ Reviewed by: rdivacky
2009-02-28 16:21:25 +00:00
libkern/memmove.c standard
Add drivers for the central and fhc busses found in enterprise class UltraSPARCs, and an eeprom attachment for fhc, which allows the date to be set properly on these machines. Central is a wierd bus which seems to only ever have 1 fhc attached to it. FHC (FireHose Controller) is another wierd bus with various things on it depending where its attached. The fhc attached to central has eeprom and zs, and the fhcs which attach directly to nexus have simm-status, environment and other nodes, none of which I'll probably ever have documentation for. Thanks to Ade Lovett for providing access to an 8 cpu e4500.
2003-02-18 09:01:01 +00:00
sparc64/central/central.c optional central
ebus is not a 'count' device. There are no NEBUS references.
2002-07-20 08:16:51 +00:00
sparc64/ebus/ebus.c optional ebus
Remove clkbrd(4) as a separate device and compile it solely based 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.
2008-08-23 14:28:44 +00:00
sparc64/fhc/clkbrd.c optional fhc
Add drivers for the central and fhc busses found in enterprise class UltraSPARCs, and an eeprom attachment for fhc, which allows the date to be set properly on these machines. Central is a wierd bus which seems to only ever have 1 fhc attached to it. FHC (FireHose Controller) is another wierd bus with various things on it depending where its attached. The fhc attached to central has eeprom and zs, and the fhcs which attach directly to nexus have simm-status, environment and other nodes, none of which I'll probably ever have documentation for. Thanks to Ade Lovett for providing access to an 8 cpu e4500.
2003-02-18 09:01:01 +00:00
sparc64/fhc/fhc.c optional fhc
Add entries for the recently committed code.
2001-11-09 20:44:44 +00:00
sparc64/isa/isa.c optional isa
Device driver for onboard CS4231 audio controller which is found 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)
2004-10-25 10:29:57 +00:00
sparc64/isa/isa_dma.c optional isa
Make config(8) understand ORed dependecies in "files*" and improve tracking of known devices. Bump config(8) version.
2005-11-27 21:41:58 +00:00
sparc64/isa/ofw_isa.c optional ebus | isa
Remove the separate kernel option for Sun APB PCI-PCI bridges and make support for them conditional on the pci(4) kernel option instead. OK'ed by: tmm
2004-04-30 15:00:41 +00:00
sparc64/pci/apb.c optional pci
- Remove the old sparc64 OFW PCI code (as opposed to the former "options OFW_NEWPCI"). This is a bit overdue, the new sparc64 OFW PCI code which is meant to replace the old one is in place for 10 months and enabled by default in GENERIC for 8 months. FreeBSD 5.2 and 5.2.1 also shipped with the new code enabled by default. - Some minor clean-up, e.g. remove functions that encapsulated the #ifdefs for OFW_NEWPCI, remove unused resp. no longer required includes, etc. Approved by: tmm, no objections on freebsd-sparc64
2004-05-08 13:53:47 +00:00
sparc64/pci/ofw_pcib.c optional pci
sparc64/pci/ofw_pcib_subr.c optional pci
sparc64/pci/ofw_pcibus.c optional pci
Add entries for the recently committed code.
2001-11-09 20:44:44 +00:00
sparc64/pci/psycho.c optional pci
Add a driver for `Schizo' Fireplane/Safari to PCI 2.1 and `Tomatillo' 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.
2008-09-28 00:07:05 +00:00
sparc64/pci/schizo.c optional pci
- Try to not leak resources in the attach functions of the esp(4) SBus 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)
2005-05-19 14:51:10 +00:00
sparc64/sbus/dma_sbus.c optional sbus
Add counter.c and sbus.c. Unify style.
2002-02-13 16:29:51 +00:00
sparc64/sbus/sbus.c optional sbus
- Try to not leak resources in the attach functions of the esp(4) SBus 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)
2005-05-19 14:51:10 +00:00
sparc64/sbus/lsi64854.c optional sbus
The Sun disk label only uses 16-bit fields for cylinders, heads and 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
2008-02-11 21:40:22 +00:00
sparc64/sparc64/ata_machdep.c optional atadisk
Add a Makefile, ldscript, and config magic for sparc64. This is tailored to build with a cross compiler alongside the standard compiler; it would be more desirable to build in a chroot.
2001-08-03 01:09:10 +00:00
sparc64/sparc64/autoconf.c standard
Add entries for the recently committed code.
2001-11-09 20:44:44 +00:00
sparc64/sparc64/bus_machdep.c standard
sparc64/sparc64/cache.c standard
- Remove unused cache flushing routines. These will not necessary work on future UltraSPARC cpus for which the data cache is not direct mapped. - Move UltraSPARC I and II (spitfire, blackbird, sapphire, sabre) specific functions to spitfire.c, and add cheetah.c for UltraSPARC III specific functions. Initially just cache flushing, but there are a few other functions that will need to move here. - Add an ipi handler for data cache flushing on UltraSPARC III. - Use function pointers to select the right cache flushing functions based on cpu_impl. With this it is possible to boot single user from an mfs root on UltraSPARC III systems, including spinning up secondary processors. There is currently no support for the host to pci bridge, and no documentation for it is publically available. Thanks to Oleg Derevenetz for providing access to a system with UltraSPARC III+ cpus.
2003-03-19 06:55:37 +00:00
sparc64/sparc64/cheetah.c standard
Add a Makefile, ldscript, and config magic for sparc64. This is tailored to build with a cross compiler alongside the standard compiler; it would be more desirable to build in a chroot.
2001-08-03 01:09:10 +00:00
sparc64/sparc64/clock.c standard
Add counter.c and sbus.c. Unify style.
2002-02-13 16:29:51 +00:00
sparc64/sparc64/counter.c standard
sparc64/sparc64/db_disasm.c optional ddb
sparc64/sparc64/db_interface.c optional ddb
sparc64/sparc64/db_trace.c optional ddb
sparc64/sparc64/db_hwwatch.c optional ddb
Add kernel dump support, based on the ia64 version (which was committed as sparc64/sparc64/dump_machdep.c a while back). Other than ia64 (which uses ELF), sparc64 uses a homegrown format for the dumps (headers are required because the physical address and size of the tsb must be noted, and because physical memory may be discontiguous); ELF would not offer any advantages here. Reviewed by: jake
2002-10-20 17:03:15 +00:00
sparc64/sparc64/dump_machdep.c standard
Add a Makefile, ldscript, and config magic for sparc64. This is tailored to build with a cross compiler alongside the standard compiler; it would be more desirable to build in a chroot.
2001-08-03 01:09:10 +00:00
sparc64/sparc64/elf_machdep.c standard
Some of the assembly files depend on v9a/v9b-only instructions so 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.
2008-09-20 11:28:42 +00:00
sparc64/sparc64/exception.S standard no-obj \
compile-with "${NORMAL_S} -mcpu=ultrasparc"
Make config(8) understand ORed dependecies in "files*" and improve tracking of known devices. Bump config(8) version.
2005-11-27 21:41:58 +00:00
sparc64/sparc64/eeprom.c optional eeprom ebus | eeprom fhc | \
eeprom sbus
Hook the GDB backend into the build.
2004-07-10 23:31:17 +00:00
sparc64/sparc64/gdb_machdep.c optional gdb
Add identcpu.c.
2001-09-30 21:35:32 +00:00
sparc64/sparc64/identcpu.c standard
Add counter.c and sbus.c. Unify style.
2002-02-13 16:29:51 +00:00
sparc64/sparc64/in_cksum.c optional inet
Some of the assembly files depend on v9a/v9b-only instructions so 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.
2008-09-20 11:28:42 +00:00
sparc64/sparc64/interrupt.S standard no-obj \
compile-with "${NORMAL_S} -mcpu=ultrasparc"
Add early code to support interrupts.
2001-08-10 04:48:48 +00:00
sparc64/sparc64/intr_machdep.c standard
Add entries for the recently committed code.
2001-11-09 20:44:44 +00:00
sparc64/sparc64/iommu.c standard
Add drivers for the power management devices found on Fireplane/ 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.
2008-09-10 20:22:27 +00:00
sparc64/sparc64/jbusppm.c standard
Standardize handling of locore.[sS] etc. files. Submitted by: jake, bde, ru
2003-02-28 21:59:14 +00:00
sparc64/sparc64/locore.S standard no-obj
Add a Makefile, ldscript, and config magic for sparc64. This is tailored to build with a cross compiler alongside the standard compiler; it would be more desirable to build in a chroot.
2001-08-03 01:09:10 +00:00
sparc64/sparc64/machdep.c standard
Break out the MI part of the /dev/[k]mem and /dev/io drivers into 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.
2004-08-01 11:40:54 +00:00
sparc64/sparc64/mem.c optional mem
Some of the assembly files depend on v9a/v9b-only instructions so 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.
2008-09-20 11:28:42 +00:00
sparc64/sparc64/mp_exception.S optional smp \
compile-with "${NORMAL_S} -mcpu=ultrasparc"
*.s -> *.S.
2002-07-31 15:52:04 +00:00
sparc64/sparc64/mp_locore.S optional smp
Connect smp support to the kernel build.
2002-01-08 05:55:46 +00:00
sparc64/sparc64/mp_machdep.c optional smp
Add entries for the recently committed code.
2001-11-09 20:44:44 +00:00
sparc64/sparc64/nexus.c standard
sparc64/sparc64/ofw_machdep.c standard
Add a Makefile, ldscript, and config magic for sparc64. This is tailored to build with a cross compiler alongside the standard compiler; it would be more desirable to build in a chroot.
2001-08-03 01:09:10 +00:00
sparc64/sparc64/pmap.c standard
Add routines needed for high resolution profiling.
2002-07-29 00:45:13 +00:00
sparc64/sparc64/prof_machdep.c optional profiling-routine
Make config(8) understand ORed dependecies in "files*" and improve tracking of known devices. Bump config(8) version.
2005-11-27 21:41:58 +00:00
sparc64/sparc64/rtc.c optional rtc ebus | rtc isa
Add rwindow.c, forgotten earlier.
2001-09-04 01:18:39 +00:00
sparc64/sparc64/rwindow.c standard
Hook syscons and the creator driver up to the sparc64. This compiles but will not link due to missing keyboard drivers.
2003-08-24 01:54:06 +00:00
sparc64/sparc64/sc_machdep.c optional sc
Add drivers for the power management devices found on Fireplane/ 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.
2008-09-10 20:22:27 +00:00
sparc64/sparc64/schppm.c standard
- Remove unused cache flushing routines. These will not necessary work on future UltraSPARC cpus for which the data cache is not direct mapped. - Move UltraSPARC I and II (spitfire, blackbird, sapphire, sabre) specific functions to spitfire.c, and add cheetah.c for UltraSPARC III specific functions. Initially just cache flushing, but there are a few other functions that will need to move here. - Add an ipi handler for data cache flushing on UltraSPARC III. - Use function pointers to select the right cache flushing functions based on cpu_impl. With this it is possible to boot single user from an mfs root on UltraSPARC III systems, including spinning up secondary processors. There is currently no support for the host to pci bridge, and no documentation for it is publically available. Thanks to Oleg Derevenetz for providing access to a system with UltraSPARC III+ cpus.
2003-03-19 06:55:37 +00:00
sparc64/sparc64/spitfire.c standard
Break out stack(9) from ddb(4): - 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)
2007-12-02 20:40:35 +00:00
sparc64/sparc64/stack_machdep.c optional ddb | stack
Some of the assembly files depend on v9a/v9b-only instructions so 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.
2008-09-20 11:28:42 +00:00
sparc64/sparc64/support.S standard \
compile-with "${NORMAL_S} -mcpu=ultrasparc"
Add a Makefile, ldscript, and config magic for sparc64. This is tailored to build with a cross compiler alongside the standard compiler; it would be more desirable to build in a chroot.
2001-08-03 01:09:10 +00:00
sparc64/sparc64/sys_machdep.c standard
*.s -> *.S.
2002-07-31 15:52:04 +00:00
sparc64/sparc64/swtch.S standard
Add early code to support interrupts.
2001-08-10 04:48:48 +00:00
sparc64/sparc64/tick.c standard
De-inline the tlb demap functions. These were so big that gcc3.1 refused to inline them anyway. ;)
2002-05-20 16:10:17 +00:00
sparc64/sparc64/tlb.c standard
Add a Makefile, ldscript, and config magic for sparc64. This is tailored to build with a cross compiler alongside the standard compiler; it would be more desirable to build in a chroot.
2001-08-03 01:09:10 +00:00
sparc64/sparc64/trap.c standard
sparc64/sparc64/tsb.c standard
Add an implementation of uiomove_fromphys() to sparc64. This implementation could be characterized as a hybrid of the amd64 and i386 implementations. Specifically, the direct virtual-to-physical mapping is used if possible and sf_buf_alloc() is used if the direct map cannot.
2004-03-22 08:08:25 +00:00
sparc64/sparc64/uio_machdep.c standard
Resurrect upa(4), now used for the subordinate/slave UPA bridge and 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.
2007-01-16 22:08:27 +00:00
sparc64/sparc64/upa.c optional creator
Add a Makefile, ldscript, and config magic for sparc64. This is tailored to build with a cross compiler alongside the standard compiler; it would be more desirable to build in a chroot.
2001-08-03 01:09:10 +00:00
sparc64/sparc64/vm_machdep.c standard
Reference in New Issue Copy Permalink