d/freebsd-nq
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
520b635320
freebsd-nq/sys/conf/files.sparc64

126 lines
4.6 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.
#
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"
#
#
- Speedup 3DES by using assembly code for i386. - Sync des/blowfish to more recent openssl. Obtained from: KAME/NetBSD MFC after: 2 weeks
2002-03-05 09:19:02 +00:00
crypto/blowfish/bf_enc.c optional ipsec ipsec_esp
crypto/des/des_enc.c optional ipsec ipsec_esp
hookup new crypto support to the config/build process
2002-10-04 20:42:36 +00:00
crypto/blowfish/bf_enc.c optional crypto
crypto/des/des_enc.c optional crypto
Port NetBSD auxio driver. The driver was modified to use led(4) and can 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
2004-10-09 07:31:03 +00:00
dev/auxio/auxio.c optional auxio sbus
dev/auxio/auxio.c optional 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
- 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
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/splash.c optional splash
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
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/kbd/kbd.c optional sc
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
dev/kbd/kbd.c optional ukbd
- 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 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
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
dev/sound/sbus/cs4231.c optional snd_audiocs ebus
dev/sound/sbus/cs4231.c optional 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
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
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
NB: This commit does *NOT* make GEOM the default in FreeBSD NB: But it will enable it in all kernels not having options "NO_GEOM" Put the GEOM related options into the intended order. Add "options NO_GEOM" to all kernel configs apart from NOTES. In some order of controlled fashion, the NO_GEOM options will be removed, architecture by architecture in the coming days. There are currently three known issues which may force people to need the NO_GEOM option: boot0cfg/fdisk: Tries to update the MBR while it is being used to control slices. GEOM does not allow this as a direct operation. SCSI floppy drives: Appearantly the scsi-da driver return "EBUSY" if no media is inserted. This is wrong, it should return ENXIO. PC98: It is unclear if GEOM correctly recognizes all variants of PC98 disklabels. (Help Wanted! I have neither docs nor HW) These issues are all being worked. Sponsored by: DARPA & NAI Labs.
2002-10-05 16:35:33 +00:00
geom/geom_bsd.c standard
Separate the encoding/decoding functions for struct disklabel into a separate source file which can be used from both kernel and userland code.
2003-04-17 07:39:03 +00:00
geom/geom_bsd_enc.c standard
NB: This commit does *NOT* make GEOM the default in FreeBSD NB: But it will enable it in all kernels not having options "NO_GEOM" Put the GEOM related options into the intended order. Add "options NO_GEOM" to all kernel configs apart from NOTES. In some order of controlled fashion, the NO_GEOM options will be removed, architecture by architecture in the coming days. There are currently three known issues which may force people to need the NO_GEOM option: boot0cfg/fdisk: Tries to update the MBR while it is being used to control slices. GEOM does not allow this as a direct operation. SCSI floppy drives: Appearantly the scsi-da driver return "EBUSY" if no media is inserted. This is wrong, it should return ENXIO. PC98: It is unclear if GEOM correctly recognizes all variants of PC98 disklabels. (Help Wanted! I have neither docs nor HW) These issues are all being worked. Sponsored by: DARPA & NAI Labs.
2002-10-05 16:35:33 +00:00
geom/geom_sunlabel.c standard
Update GEOM::SUN to use the decoding functions in geom_sunlabel_enc.c and #defines from sys/sun_disklabel.h.
2003-04-21 19:54:11 +00:00
geom/geom_sunlabel_enc.c standard
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 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
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/creator/creator_upa.c optional creator sc
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
Add a driver for the 'clock-board' device (the clock board is an 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
2005-03-19 01:04:48 +00:00
sparc64/fhc/clkbrd.c optional clkbrd 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
sparc64/fhc/fhc_central.c optional fhc central
sparc64/fhc/fhc_nexus.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
Back out no longer necessary work-arounds added in rev. 1.59 for building SBus-only kernels regarding ofw_machdep.c.
2005-02-12 19:19:20 +00:00
sparc64/isa/ofw_isa.c optional ebus
sparc64/isa/ofw_isa.c optional 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
Add entries for the recently committed code.
2001-11-09 20:44:44 +00:00
sparc64/pci/ofw_pci.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
Back out no longer necessary work-arounds added in rev. 1.59 for building SBus-only kernels regarding ofw_machdep.c.
2005-02-12 19:19:20 +00:00
sparc64/pci/ofw_pci_if.m optional pci
Add entries for the recently committed code.
2001-11-09 20:44:44 +00:00
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
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
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
Standardize handling of locore.[sS] etc. files. Submitted by: jake, bde, ru
2003-02-28 21:59:14 +00:00
sparc64/sparc64/exception.S standard no-obj
- Collapse eeprom_ebus.c and eeprom_sbus.c into eeprom.c and 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.
2005-05-19 18:15:37 +00:00
sparc64/sparc64/eeprom.c optional eeprom ebus
sparc64/sparc64/eeprom.c optional eeprom fhc
sparc64/sparc64/eeprom.c optional 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
Standardize handling of locore.[sS] etc. files. Submitted by: jake, bde, ru
2003-02-28 21:59:14 +00:00
sparc64/sparc64/interrupt.S standard no-obj
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
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
*.s -> *.S.
2002-07-31 15:52:04 +00:00
sparc64/sparc64/mp_exception.S optional smp
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
Fix the ofw_isa.c entries, readd ofw_bus.c. Pointy hat to: tmm
2002-04-05 02:42:25 +00:00
sparc64/sparc64/ofw_bus.c standard
Add entries for the recently committed code.
2001-11-09 20:44:44 +00:00
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
Add a front-end for the `rtc' device which is a MC146818 compatible 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)
2004-11-17 16:41:42 +00:00
sparc64/sparc64/rtc.c optional rtc ebus
sparc64/sparc64/rtc.c optional 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
- 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
*.s -> *.S.
2002-07-31 15:52:04 +00:00
sparc64/sparc64/support.S 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/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
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