freebsd-dev/sys/conf/files.sparc64

147 lines
5.9 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"
#
- 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"
#
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"
#
cddl/contrib/opensolaris/common/atomic/sparc64/opensolaris_atomic.S optional zfs compile-with "${ZFS_S}"
2010-04-24 16:27:43 +00:00
crypto/blowfish/bf_enc.c optional crypto | ipsec
crypto/des/des_enc.c optional crypto | ipsec
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/gallant12x22.c optional sc
dev/fb/machfb.c optional machfb sc
dev/hwpmc/hwpmc_sparc64.c optional hwpmc
dev/kbd/kbd.c optional atkbd | sc | ukbd
dev/le/if_le_lebuffer.c optional le sbus
dev/le/if_le_ledma.c optional le sbus
dev/le/lebuffer_sbus.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
2010-04-24 16:27:43 +00:00
dev/ofw/ofw_if.m standard
dev/ofw/ofw_standard.c standard
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
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
dev/syscons/scvtb.c optional sc
dev/uart/uart_cpu_sparc64.c optional uart
dev/uart/uart_kbd_sun.c optional uart sc
kern/kern_clocksource.c standard
kern/subr_dummy_vdso_tc.c standard
kern/syscalls.c optional ktr
libkern/ffs.c standard
libkern/ffsl.c standard
libkern/fls.c standard
libkern/flsl.c standard
libkern/memmove.c standard
sparc64/central/central.c optional central
sparc64/ebus/ebus.c optional ebus
sparc64/ebus/epic.c optional epic ebus
sparc64/fhc/clkbrd.c optional fhc
sparc64/fhc/fhc.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/fire.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
2010-04-24 16:27:43 +00:00
sparc64/pci/sbbc.c optional sbbc uart
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
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/ata_machdep.c optional ada | da
sparc64/sparc64/autoconf.c standard
sparc64/sparc64/bus_machdep.c standard
sparc64/sparc64/cache.c standard
sparc64/sparc64/cam_machdep.c optional scbus
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 \
compile-with "${NORMAL_S} -mcpu=ultrasparc"
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
sparc64/sparc64/in_cksum.c optional inet | inet6
sparc64/sparc64/interrupt.S standard no-obj \
compile-with "${NORMAL_S} -mcpu=ultrasparc"
2001-08-10 04:48:48 +00:00
sparc64/sparc64/intr_machdep.c standard
sparc64/sparc64/iommu.c standard
sparc64/sparc64/jbusppm.c standard
sparc64/sparc64/locore.S standard no-obj
sparc64/sparc64/machdep.c standard
sparc64/sparc64/mem.c optional mem
sparc64/sparc64/mp_exception.S optional smp \
compile-with "${NORMAL_S} -mcpu=ultrasparc"
2002-07-31 15:52:04 +00:00
sparc64/sparc64/mp_locore.S optional smp
sparc64/sparc64/mp_machdep.c optional smp
sparc64/sparc64/nexus.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/schppm.c standard
sparc64/sparc64/spitfire.c standard
sparc64/sparc64/ssm.c standard
sparc64/sparc64/stack_machdep.c optional ddb | stack
sparc64/sparc64/support.S standard \
compile-with "${NORMAL_S} -mcpu=ultrasparc"
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/upa.c optional creator
sparc64/sparc64/vm_machdep.c standard
sparc64/sparc64/zeus.c standard