freebsd-skq/sys/conf/files.sparc64

145 lines
5.6 KiB
Plaintext
Raw Normal View History

# 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.
#
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"
#
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"
#
2006-03-14 22:40:44 +00:00
hal.o optional ath_hal \
dependency "$S/contrib/dev/ath/public/sparc64-be-elf.hal.o.uu" \
compile-with "uudecode < $S/contrib/dev/ath/public/sparc64-be-elf.hal.o.uu" \
no-implicit-rule
opt_ah.h optional ath_hal \
dependency "$S/contrib/dev/ath/public/sparc64-be-elf.opt_ah.h" \
compile-with "cp $S/contrib/dev/ath/public/sparc64-be-elf.opt_ah.h opt_ah.h" \
no-obj no-implicit-rule before-depend \
clean "opt_ah.h"
#
crypto/blowfish/bf_enc.c optional crypto | ipsec ipsec_esp
crypto/des/des_enc.c optional crypto | ipsec ipsec_esp | \
netsmb
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
dev/auxio/auxio.c optional auxio sbus | auxio ebus
dev/esp/esp_sbus.c optional esp sbus
dev/fb/creator.c optional creator sc
dev/fb/fb.c optional sc
dev/fb/machfb.c optional machfb sc
dev/fb/splash.c optional splash
dev/hwpmc/hwpmc_sparc64.c optional hwpmc
dev/kbd/kbd.c optional atkbd | sc | ukbd
dev/le/if_le_ledma.c optional le sbus
- 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
dev/ofw/ofw_bus_subr.c standard
2002-02-13 16:29:51 +00:00
dev/ofw/ofw_console.c optional ofw_console
dev/ofw/openfirm.c standard
2002-10-18 15:27:02 +00:00
dev/ofw/openfirmio.c standard
2003-06-19 18:06:58 +00:00
dev/ofw/openpromio.c standard
dev/pcf/envctrl.c optional pcf ebus
dev/pcf/pcf_ebus.c optional pcf ebus
dev/sound/sbus/cs4231.c optional snd_audiocs ebus | \
snd_audiocs sbus
dev/syscons/scgfbrndr.c optional sc
dev/syscons/schistory.c optional sc
dev/syscons/scmouse.c optional sc
dev/syscons/scterm.c optional sc
dev/syscons/scterm-dumb.c optional sc
dev/syscons/scterm-sc.c optional sc
dev/syscons/scvidctl.c optional sc
dev/syscons/scvtb.c optional sc
dev/syscons/syscons.c optional sc
dev/syscons/sysmouse.c optional sc
dev/uart/uart_cpu_sparc64.c optional uart
dev/uart/uart_kbd_sun.c optional uart sc
geom/geom_bsd.c standard
geom/geom_bsd_enc.c standard
geom/geom_sunlabel.c standard
geom/geom_sunlabel_enc.c standard
kern/syscalls.c optional ktr
libkern/ffs.c standard
libkern/ffsl.c standard
libkern/fls.c standard
libkern/flsl.c standard
sparc64/central/central.c optional central
sparc64/creator/creator_upa.c optional creator sc
sparc64/ebus/ebus.c optional ebus
sparc64/fhc/clkbrd.c optional clkbrd fhc
sparc64/fhc/fhc.c optional fhc
sparc64/fhc/fhc_central.c optional fhc central
sparc64/fhc/fhc_nexus.c optional fhc
sparc64/isa/isa.c optional isa
sparc64/isa/isa_dma.c optional isa
sparc64/isa/ofw_isa.c optional ebus | isa
sparc64/pci/apb.c optional pci
sparc64/pci/ofw_pci.c optional pci
sparc64/pci/ofw_pcib.c optional pci
sparc64/pci/ofw_pcib_subr.c optional pci
sparc64/pci/ofw_pcibus.c optional pci
sparc64/pci/ofw_pci_if.m optional pci
sparc64/pci/psycho.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
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
sparc64/sparc64/autoconf.c standard
sparc64/sparc64/bus_machdep.c standard
sparc64/sparc64/cache.c standard
sparc64/sparc64/cheetah.c standard
sparc64/sparc64/clock.c standard
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
sparc64/sparc64/dump_machdep.c standard
sparc64/sparc64/elf_machdep.c standard
sparc64/sparc64/exception.S standard no-obj
sparc64/sparc64/eeprom.c optional eeprom ebus | eeprom fhc | \
eeprom sbus
2004-07-10 23:31:17 +00:00
sparc64/sparc64/gdb_machdep.c optional gdb
2001-09-30 21:35:32 +00:00
sparc64/sparc64/identcpu.c standard
2002-02-13 16:29:51 +00:00
sparc64/sparc64/in_cksum.c optional inet
sparc64/sparc64/interrupt.S standard no-obj
2001-08-10 04:48:48 +00:00
sparc64/sparc64/intr_machdep.c standard
sparc64/sparc64/iommu.c standard
sparc64/sparc64/locore.S standard no-obj
sparc64/sparc64/machdep.c standard
sparc64/sparc64/mem.c optional mem
2002-07-31 15:52:04 +00:00
sparc64/sparc64/mp_exception.S optional smp
sparc64/sparc64/mp_locore.S optional smp
sparc64/sparc64/mp_machdep.c optional smp
sparc64/sparc64/nexus.c standard
sparc64/sparc64/ofw_bus.c standard
sparc64/sparc64/ofw_machdep.c standard
sparc64/sparc64/pmap.c standard
sparc64/sparc64/prof_machdep.c optional profiling-routine
sparc64/sparc64/rtc.c optional rtc ebus | rtc isa
2001-09-04 01:18:39 +00:00
sparc64/sparc64/rwindow.c standard
sparc64/sparc64/sc_machdep.c optional sc
sparc64/sparc64/spitfire.c standard
2002-07-31 15:52:04 +00:00
sparc64/sparc64/support.S standard
sparc64/sparc64/sys_machdep.c standard
2002-07-31 15:52:04 +00:00
sparc64/sparc64/swtch.S standard
2001-08-10 04:48:48 +00:00
sparc64/sparc64/tick.c standard
sparc64/sparc64/tlb.c standard
sparc64/sparc64/trap.c standard
sparc64/sparc64/tsb.c standard
sparc64/sparc64/uio_machdep.c standard
sparc64/sparc64/vm_machdep.c standard