d/freebsd-dev
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
605da56bc3
freebsd-dev/sys/conf/files.amd64

329 lines
13 KiB
Plaintext
Raw Normal View History

This is the start of the FreeBSD/x86_64 kernel.
2002-06-30 08:05:21 +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.
#
Add preliminary support for running 32-bit Linux binaries on amd64, enabled with the COMPAT_LINUX32 option. This is largely based on the i386 MD Linux emulations bits, but also builds on the 32-bit FreeBSD and generic IA-32 binary emulation work. Some of this is still a little rough around the edges, and will need to be revisited before 32-bit and 64-bit Linux emulation support can coexist in the same kernel.
2004-08-16 07:55:06 +00:00
#
linux32_genassym.o optional compat_linux32 \
dependency "$S/amd64/linux32/linux32_genassym.c" \
compile-with "${CC} ${CFLAGS:N-fno-common} -c ${.IMPSRC}" \
no-obj no-implicit-rule \
clean "linux32_genassym.o"
#
linux32_assym.h optional compat_linux32 \
dependency "$S/kern/genassym.sh linux32_genassym.o" \
compile-with "sh $S/kern/genassym.sh linux32_genassym.o > ${.TARGET}" \
no-obj no-implicit-rule before-depend \
clean "linux32_assym.h"
#
Initial landing of SMP support for FreeBSD/amd64. - This is heavily derived from John Baldwin's apic/pci cleanup on i386. - I have completely rewritten or drastically cleaned up some other parts. (in particular, bootstrap) - This is still a WIP. It seems that there are some highly bogus bioses on nVidia nForce3-150 boards. I can't stress how broken these boards are. I have a workaround in mind, but right now the Asus SK8N is broken. The Gigabyte K8NPro (nVidia based) is also mind-numbingly hosed. - Most of my testing has been with SCHED_ULE. SCHED_4BSD works. - the apic and acpi components are 'standard'. - If you have an nVidia nForce3-150 board, you are stuck with 'device atpic' in addition, because they somehow managed to forget to connect the 8254 timer to the apic, even though its in the same silicon! ARGH! This directly violates the ACPI spec.
2003-11-17 08:58:16 +00:00
ia32_genassym.o standard \
Complete the switch to the common 32 bit support code.
2003-08-23 00:58:33 +00:00
dependency "$S/compat/ia32/ia32_genassym.c" \
Add BASIC i386 binary support for the amd64 kernel. This is largely stolen from the ia64/ia32 code (indeed there was a repocopy), but I've redone the MD parts and added and fixed a few essential syscalls. It is sufficient to run i386 binaries like /bin/ls, /usr/bin/id (dynamic) and p4. The ia64 code has not implemented signal delivery, so I had to do that. Before you say it, yes, this does need to go in a common place. But we're in a freeze at the moment and I didn't want to risk breaking ia64. I will sort this out after the freeze so that the common code is in a common place. On the AMD64 side, this required adding segment selector context switch support and some other support infrastructure. The %fs/%gs etc code is hairy because loading %gs will clobber the kernel's current MSR_GSBASE setting. The segment selectors are not used by the kernel, so they're only changed at context switch time or when changing modes. This still needs to be optimized. Approved by: re (amd64/* blanket)
2003-05-14 04:10:49 +00:00
compile-with "${CC} ${CFLAGS:N-fno-common} -c ${.IMPSRC}" \
no-obj no-implicit-rule \
clean "ia32_genassym.o"
#
Initial landing of SMP support for FreeBSD/amd64. - This is heavily derived from John Baldwin's apic/pci cleanup on i386. - I have completely rewritten or drastically cleaned up some other parts. (in particular, bootstrap) - This is still a WIP. It seems that there are some highly bogus bioses on nVidia nForce3-150 boards. I can't stress how broken these boards are. I have a workaround in mind, but right now the Asus SK8N is broken. The Gigabyte K8NPro (nVidia based) is also mind-numbingly hosed. - Most of my testing has been with SCHED_ULE. SCHED_4BSD works. - the apic and acpi components are 'standard'. - If you have an nVidia nForce3-150 board, you are stuck with 'device atpic' in addition, because they somehow managed to forget to connect the 8254 timer to the apic, even though its in the same silicon! ARGH! This directly violates the ACPI spec.
2003-11-17 08:58:16 +00:00
ia32_assym.h standard \
Add BASIC i386 binary support for the amd64 kernel. This is largely stolen from the ia64/ia32 code (indeed there was a repocopy), but I've redone the MD parts and added and fixed a few essential syscalls. It is sufficient to run i386 binaries like /bin/ls, /usr/bin/id (dynamic) and p4. The ia64 code has not implemented signal delivery, so I had to do that. Before you say it, yes, this does need to go in a common place. But we're in a freeze at the moment and I didn't want to risk breaking ia64. I will sort this out after the freeze so that the common code is in a common place. On the AMD64 side, this required adding segment selector context switch support and some other support infrastructure. The %fs/%gs etc code is hairy because loading %gs will clobber the kernel's current MSR_GSBASE setting. The segment selectors are not used by the kernel, so they're only changed at context switch time or when changing modes. This still needs to be optimized. Approved by: re (amd64/* blanket)
2003-05-14 04:10:49 +00:00
dependency "$S/kern/genassym.sh ia32_genassym.o" \
Protect the NM expansion.
2004-12-21 02:08:14 +00:00
compile-with "env NM='${NM}' sh $S/kern/genassym.sh ia32_genassym.o > ${.TARGET}" \
Add BASIC i386 binary support for the amd64 kernel. This is largely stolen from the ia64/ia32 code (indeed there was a repocopy), but I've redone the MD parts and added and fixed a few essential syscalls. It is sufficient to run i386 binaries like /bin/ls, /usr/bin/id (dynamic) and p4. The ia64 code has not implemented signal delivery, so I had to do that. Before you say it, yes, this does need to go in a common place. But we're in a freeze at the moment and I didn't want to risk breaking ia64. I will sort this out after the freeze so that the common code is in a common place. On the AMD64 side, this required adding segment selector context switch support and some other support infrastructure. The %fs/%gs etc code is hairy because loading %gs will clobber the kernel's current MSR_GSBASE setting. The segment selectors are not used by the kernel, so they're only changed at context switch time or when changing modes. This still needs to be optimized. Approved by: re (amd64/* blanket)
2003-05-14 04:10:49 +00:00
no-obj no-implicit-rule before-depend \
clean "ia32_assym.h"
#
Add rules for font.h atkbdmap.h ukbdmap.h so more of LINT can be built.
2004-03-03 09:37:44 +00:00
font.h optional sc_dflt_font \
compile-with "uudecode < /usr/share/syscons/fonts/${SC_DFLT_FONT}-8x16.fnt && file2c 'static u_char dflt_font_16[16*256] = {' '};' < ${SC_DFLT_FONT}-8x16 > font.h && uudecode < /usr/share/syscons/fonts/${SC_DFLT_FONT}-8x14.fnt && file2c 'static u_char dflt_font_14[14*256] = {' '};' < ${SC_DFLT_FONT}-8x14 >> font.h && uudecode < /usr/share/syscons/fonts/${SC_DFLT_FONT}-8x8.fnt && file2c 'static u_char dflt_font_8[8*256] = {' '};' < ${SC_DFLT_FONT}-8x8 >> font.h" \
no-obj no-implicit-rule before-depend \
clean "font.h ${SC_DFLT_FONT}-8x14 ${SC_DFLT_FONT}-8x16 ${SC_DFLT_FONT}-8x8"
#
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"
#
FreeBSD consumer bits of the nForce MCP NIC binary blob. Demanded by: DES Encouraged by: scottl Obtained from: q@onthenet.com.au (partially) KNF'ed by: obrien
2005-03-12 00:29:30 +00:00
nvenetlib.o optional nve pci \
dependency "$S/contrib/dev/nve/amd64/nvenetlib.o.bz2.uu" \
compile-with "uudecode $S/contrib/dev/nve/amd64/nvenetlib.o.bz2.uu ; bzip2 -df nvenetlib.o.bz2" \
Align.
2007-10-25 14:16:07 +00:00
no-implicit-rule
FreeBSD consumer bits of the nForce MCP NIC binary blob. Demanded by: DES Encouraged by: scottl Obtained from: q@onthenet.com.au (partially) KNF'ed by: obrien
2005-03-12 00:29:30 +00:00
#
os+%DIKED-nve.h optional nve pci \
dependency "$S/contrib/dev/nve/os.h" \
compile-with "sed -e 's/^.*#include.*phy\.h.*$$//' $S/contrib/dev/nve/os.h > os+%DIKED-nve.h" \
Clean generated os+%DIKED-nve.h.
2005-04-22 19:55:52 +00:00
no-implicit-rule no-obj before-depend \
clean "os+%DIKED-nve.h"
FreeBSD consumer bits of the nForce MCP NIC binary blob. Demanded by: DES Encouraged by: scottl Obtained from: q@onthenet.com.au (partially) KNF'ed by: obrien
2005-03-12 00:29:30 +00:00
#
Hook up the hptmv driver for amd64. MFC After: 3 days
2005-09-08 03:29:18 +00:00
hptmvraid.o optional hptmv \
dependency "$S/dev/hptmv/amd64-elf.raid.o.uu" \
compile-with "uudecode < $S/dev/hptmv/amd64-elf.raid.o.uu" \
no-implicit-rule
Add the 'hptrr' driver for supporting the following Highpoint RocketRAID cards: o RocketRAID 172x series o RocketRAID 174x series o RocketRAID 2210 o RocketRAID 222x series o RocketRAID 2240 o RocketRAID 230x series o RocketRAID 231x series o RocketRAID 232x series o RocketRAID 2340 o RocketRAID 2522 Many thanks to Highpoint for their continued support of FreeBSD. Submitted by: Highpoint
2007-12-15 00:56:17 +00:00
hptrr_lib.o optional hptrr \
dependency "$S/dev/hptrr/amd64-elf.hptrr_lib.o.uu" \
compile-with "uudecode < $S/dev/hptrr/amd64-elf.hptrr_lib.o.uu" \
no-implicit-rule
#
Port acpica to amd64. Approved by: re (amd64/* blanket)
2003-05-31 06:47:05 +00:00
amd64/acpica/acpi_machdep.c optional acpi
Initial suspend/resume support for amd64. This code is heavily inspired by Takanori Watanabe's experimental SMP patch for i386 and large portion was shamelessly cut and pasted from Peter Wemm's AP boot code.
2009-03-17 00:48:11 +00:00
amd64/acpica/acpi_switch.S optional acpi
Move i386-inherited logic of building ACPI headers for acpi_wakeup.c into better places and remove intermediate makefile and shell scripts. This makes parallel kernel build little bit safer for amd64.
2010-07-12 21:08:35 +00:00
acpi_wakecode.o optional acpi \
dependency "$S/amd64/acpica/acpi_wakecode.S assym.s" \
compile-with "${NORMAL_S}" \
Initial suspend/resume support for amd64. This code is heavily inspired by Takanori Watanabe's experimental SMP patch for i386 and large portion was shamelessly cut and pasted from Peter Wemm's AP boot code.
2009-03-17 00:48:11 +00:00
no-obj no-implicit-rule before-depend \
Move i386-inherited logic of building ACPI headers for acpi_wakeup.c into better places and remove intermediate makefile and shell scripts. This makes parallel kernel build little bit safer for amd64.
2010-07-12 21:08:35 +00:00
clean "acpi_wakecode.o"
acpi_wakecode.bin optional acpi \
dependency "acpi_wakecode.o" \
compile-with "objcopy -S -O binary acpi_wakecode.o ${.TARGET}" \
no-obj no-implicit-rule before-depend \
clean "acpi_wakecode.bin"
acpi_wakecode.h optional acpi \
dependency "acpi_wakecode.bin" \
compile-with "file2c -sx 'static char wakecode[] = {' '};' < acpi_wakecode.bin > ${.TARGET}" \
no-obj no-implicit-rule before-depend \
clean "acpi_wakecode.h"
acpi_wakedata.h optional acpi \
dependency "acpi_wakecode.o" \
Stop hard coding nm(1) and make it overridable.
2010-10-14 23:31:58 +00:00
compile-with '${NM} -n --defined-only acpi_wakecode.o | while read offset dummy what; do echo "#define $${what} 0x$${offset}"; done > ${.TARGET}' \
Move i386-inherited logic of building ACPI headers for acpi_wakeup.c into better places and remove intermediate makefile and shell scripts. This makes parallel kernel build little bit safer for amd64.
2010-07-12 21:08:35 +00:00
no-obj no-implicit-rule before-depend \
clean "acpi_wakedata.h"
Initial suspend/resume support for amd64. This code is heavily inspired by Takanori Watanabe's experimental SMP patch for i386 and large portion was shamelessly cut and pasted from Peter Wemm's AP boot code.
2009-03-17 00:48:11 +00:00
#
Port acpica to amd64. Approved by: re (amd64/* blanket)
2003-05-31 06:47:05 +00:00
amd64/acpica/acpi_wakeup.c optional acpi
Be consistant; make the memrange bit be part of the mem module like i386.
2004-09-28 07:29:54 +00:00
amd64/amd64/amd64_mem.c optional mem
Fixed profiling of trap, syscall and interrupt handlers and some ordinary functions, essentially by backing out half of rev.1.115 of amd64/exception.S. The handlers must be between certain labels for the purposes of profiling, and this was broken by scattering them in separately compiled .S files, especially for ordinary functions that ended up between the labels. Merge the files by #including them as before, except with different pathnames and better comments and organization. Changes to the scattered files are minimal -- just move the labels to the file that does the #includes. This also partly fixes profiling of IPIs -- all IPI handlers are now correctly classified as interrupt handlers, but many are still missing mcount calls.
2004-05-24 12:08:56 +00:00
#amd64/amd64/apic_vector.S standard
Initial landing of SMP support for FreeBSD/amd64. - This is heavily derived from John Baldwin's apic/pci cleanup on i386. - I have completely rewritten or drastically cleaned up some other parts. (in particular, bootstrap) - This is still a WIP. It seems that there are some highly bogus bioses on nVidia nForce3-150 boards. I can't stress how broken these boards are. I have a workaround in mind, but right now the Asus SK8N is broken. The Gigabyte K8NPro (nVidia based) is also mind-numbingly hosed. - Most of my testing has been with SCHED_ULE. SCHED_4BSD works. - the apic and acpi components are 'standard'. - If you have an nVidia nForce3-150 board, you are stuck with 'device atpic' in addition, because they somehow managed to forget to connect the 8254 timer to the apic, even though its in the same silicon! ARGH! This directly violates the ACPI spec.
2003-11-17 08:58:16 +00:00
amd64/amd64/atomic.c standard
Sync up with the files in the hammer branch in the p4 tree to get basic AMD64 support. There is still more to add.
2003-05-01 02:59:24 +00:00
amd64/amd64/autoconf.c standard
Converge towards i386. I originally resisted creating <machine/pc/bios.h> because it was mostly irrelevant - except for the silly BIOS_PADDRTOVADDR etc macros. Along the way of working around this, I missed a few things. * Make syscons properly inherit the bios capslock/shiftlock/etc state like i386 does. Note that we cannot inherit the bios key repeat rate because that requires a bios call (which is impossible for us). * Give syscons the ability to beep on amd64. Oops. While here, make bios.c compile and add it to files.amd64.
2004-09-24 01:08:34 +00:00
amd64/amd64/bios.c standard
Add BPF Just-In-Time compiler support for ng_bpf(4). The sysctl is changed from net.bpf.jitter.enable to net.bpf_jitter.enable and this controls both bpf(4) and ng_bpf(4) now.
2005-12-07 21:30:47 +00:00
amd64/amd64/bpf_jit_machdep.c optional bpf_jitter
Spell cpu_switch correctly.
2003-05-03 03:30:29 +00:00
amd64/amd64/cpu_switch.S standard
Add ddb machdep bits. Approved by: re (amd64 bits)
2003-05-30 01:03:43 +00:00
amd64/amd64/db_disasm.c optional ddb
amd64/amd64/db_interface.c optional ddb
amd64/amd64/db_trace.c optional ddb
Sync up with the files in the hammer branch in the p4 tree to get basic AMD64 support. There is still more to add.
2003-05-01 02:59:24 +00:00
amd64/amd64/elf_machdep.c standard
Rename amd64/*.s to amd64/*.S
2003-05-03 00:19:42 +00:00
amd64/amd64/exception.S standard
Initial landing of SMP support for FreeBSD/amd64. - This is heavily derived from John Baldwin's apic/pci cleanup on i386. - I have completely rewritten or drastically cleaned up some other parts. (in particular, bootstrap) - This is still a WIP. It seems that there are some highly bogus bioses on nVidia nForce3-150 boards. I can't stress how broken these boards are. I have a workaround in mind, but right now the Asus SK8N is broken. The Gigabyte K8NPro (nVidia based) is also mind-numbingly hosed. - Most of my testing has been with SCHED_ULE. SCHED_4BSD works. - the apic and acpi components are 'standard'. - If you have an nVidia nForce3-150 board, you are stuck with 'device atpic' in addition, because they somehow managed to forget to connect the 8254 timer to the apic, even though its in the same silicon! ARGH! This directly violates the ACPI spec.
2003-11-17 08:58:16 +00:00
amd64/amd64/fpu.c standard
Hook the GDB backend into the build.
2004-07-10 23:31:17 +00:00
amd64/amd64/gdb_machdep.c optional gdb
Sync up with the files in the hammer branch in the p4 tree to get basic AMD64 support. There is still more to add.
2003-05-01 02:59:24 +00:00
amd64/amd64/identcpu.c standard
Initial landing of SMP support for FreeBSD/amd64. - This is heavily derived from John Baldwin's apic/pci cleanup on i386. - I have completely rewritten or drastically cleaned up some other parts. (in particular, bootstrap) - This is still a WIP. It seems that there are some highly bogus bioses on nVidia nForce3-150 boards. I can't stress how broken these boards are. I have a workaround in mind, but right now the Asus SK8N is broken. The Gigabyte K8NPro (nVidia based) is also mind-numbingly hosed. - Most of my testing has been with SCHED_ULE. SCHED_4BSD works. - the apic and acpi components are 'standard'. - If you have an nVidia nForce3-150 board, you are stuck with 'device atpic' in addition, because they somehow managed to forget to connect the 8254 timer to the apic, even though its in the same silicon! ARGH! This directly violates the ACPI spec.
2003-11-17 08:58:16 +00:00
amd64/amd64/in_cksum.c optional inet
Sync up with the files in the hammer branch in the p4 tree to get basic AMD64 support. There is still more to add.
2003-05-01 02:59:24 +00:00
amd64/amd64/initcpu.c standard
Initial landing of SMP support for FreeBSD/amd64. - This is heavily derived from John Baldwin's apic/pci cleanup on i386. - I have completely rewritten or drastically cleaned up some other parts. (in particular, bootstrap) - This is still a WIP. It seems that there are some highly bogus bioses on nVidia nForce3-150 boards. I can't stress how broken these boards are. I have a workaround in mind, but right now the Asus SK8N is broken. The Gigabyte K8NPro (nVidia based) is also mind-numbingly hosed. - Most of my testing has been with SCHED_ULE. SCHED_4BSD works. - the apic and acpi components are 'standard'. - If you have an nVidia nForce3-150 board, you are stuck with 'device atpic' in addition, because they somehow managed to forget to connect the 8254 timer to the apic, even though its in the same silicon! ARGH! This directly violates the ACPI spec.
2003-11-17 08:58:16 +00:00
amd64/amd64/intr_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
amd64/amd64/io.c optional io
Sync up with the files in the hammer branch in the p4 tree to get basic AMD64 support. There is still more to add.
2003-05-01 02:59:24 +00:00
amd64/amd64/legacy.c standard
Rename amd64/*.s to amd64/*.S
2003-05-03 00:19:42 +00:00
amd64/amd64/locore.S standard no-obj
Sync up with the files in the hammer branch in the p4 tree to get basic AMD64 support. There is still more to add.
2003-05-01 02:59:24 +00:00
amd64/amd64/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
amd64/amd64/mem.c optional mem
Introduce minidumps. Full physical memory crash dumps are still available via the debug.minidump sysctl and tunable. Traditional dumps store all physical memory. This was once a good thing when machines had a maximum of 64M of ram and 1GB of kvm. These days, machines often have many gigabytes of ram and a smaller amount of kvm. libkvm+kgdb don't have a way to access physical ram that is not mapped into kvm at the time of the crash dump, so the extra ram being dumped is mostly wasted. Minidumps invert the process. Instead of dumping physical memory in in order to guarantee that all of kvm's backing is dumped, minidumps instead dump only memory that is actively mapped into kvm. amd64 has a direct map region that things like UMA use. Obviously we cannot dump all of the direct map region because that is effectively an old style all-physical-memory dump. Instead, introduce a bitmap and two helper routines (dump_add_page(pa) and dump_drop_page(pa)) that allow certain critical direct map pages to be included in the dump. uma_machdep.c's allocator is the intended consumer. Dumps are a custom format. At the very beginning of the file is a header, then a copy of the message buffer, then the bitmap of pages present in the dump, then the final level of the kvm page table trees (2MB mappings are expanded into a 4K page mappings), then the sparse physical pages according to the bitmap. libkvm can now conveniently access the kvm page table entries. Booting my test 8GB machine, forcing it into ddb and forcing a dump leads to a 48MB minidump. While this is a best case, I expect minidumps to be in the 100MB-500MB range. Obviously, never larger than physical memory of course. minidumps are on by default. It would want be necessary to turn them off if it was necessary to debug corrupt kernel page table management as that would mess up minidumps as well. Both minidumps and regular dumps are supported on the same machine.
2006-04-21 04:24:50 +00:00
amd64/amd64/minidump_machdep.c standard
Initial landing of SMP support for FreeBSD/amd64. - This is heavily derived from John Baldwin's apic/pci cleanup on i386. - I have completely rewritten or drastically cleaned up some other parts. (in particular, bootstrap) - This is still a WIP. It seems that there are some highly bogus bioses on nVidia nForce3-150 boards. I can't stress how broken these boards are. I have a workaround in mind, but right now the Asus SK8N is broken. The Gigabyte K8NPro (nVidia based) is also mind-numbingly hosed. - Most of my testing has been with SCHED_ULE. SCHED_4BSD works. - the apic and acpi components are 'standard'. - If you have an nVidia nForce3-150 board, you are stuck with 'device atpic' in addition, because they somehow managed to forget to connect the 8254 timer to the apic, even though its in the same silicon! ARGH! This directly violates the ACPI spec.
2003-11-17 08:58:16 +00:00
amd64/amd64/mp_machdep.c optional smp
Add the mp_watchdog hooks, although it locks up my SMP test box. It might be useable to somebody.
2004-08-30 23:33:33 +00:00
amd64/amd64/mp_watchdog.c optional mp_watchdog smp
Initial landing of SMP support for FreeBSD/amd64. - This is heavily derived from John Baldwin's apic/pci cleanup on i386. - I have completely rewritten or drastically cleaned up some other parts. (in particular, bootstrap) - This is still a WIP. It seems that there are some highly bogus bioses on nVidia nForce3-150 boards. I can't stress how broken these boards are. I have a workaround in mind, but right now the Asus SK8N is broken. The Gigabyte K8NPro (nVidia based) is also mind-numbingly hosed. - Most of my testing has been with SCHED_ULE. SCHED_4BSD works. - the apic and acpi components are 'standard'. - If you have an nVidia nForce3-150 board, you are stuck with 'device atpic' in addition, because they somehow managed to forget to connect the 8254 timer to the apic, even though its in the same silicon! ARGH! This directly violates the ACPI spec.
2003-11-17 08:58:16 +00:00
amd64/amd64/mpboot.S optional smp
Eliminate compilation warnings due to the use of non-static inlines through the introduction and use of the __gnu89_inline attribute. Submitted by: bde (i386) MFC after: 3 days
2007-12-09 21:00:36 +00:00
amd64/amd64/pmap.c standard
Fixed insertion sort error in previous commit (prof_machdep.c). Fixed apparently-intentional disorder of the crypto files. Lists of files should be sorted first on the pathname, not on the option name or subsystem.
2004-05-24 09:55:02 +00:00
amd64/amd64/prof_machdep.c optional profiling-routine
Rename amd64/*.s to amd64/*.S
2003-05-03 00:19:42 +00:00
amd64/amd64/sigtramp.S 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
amd64/amd64/stack_machdep.c optional ddb | stack
Rename amd64/*.s to amd64/*.S
2003-05-03 00:19:42 +00:00
amd64/amd64/support.S standard
Sync up with the files in the hammer branch in the p4 tree to get basic AMD64 support. There is still more to add.
2003-05-01 02:59:24 +00:00
amd64/amd64/sys_machdep.c standard
amd64/amd64/trap.c standard
Introduce uiomove_fromphys(). This is a variant of uiomove() that takes a collection of physical pages as the source. On amd64 it is implemented using the direct virtual-to-physical map.
2004-03-20 19:36:29 +00:00
amd64/amd64/uio_machdep.c standard
MFia64 Move uma_small_alloc() and uma_small_free() to uma_machdep.c.
2003-10-14 05:51:31 +00:00
amd64/amd64/uma_machdep.c standard
Sync up with the files in the hammer branch in the p4 tree to get basic AMD64 support. There is still more to add.
2003-05-01 02:59:24 +00:00
amd64/amd64/vm_machdep.c standard
amd64/pci/pci_bus.c optional pci
Initial landing of SMP support for FreeBSD/amd64. - This is heavily derived from John Baldwin's apic/pci cleanup on i386. - I have completely rewritten or drastically cleaned up some other parts. (in particular, bootstrap) - This is still a WIP. It seems that there are some highly bogus bioses on nVidia nForce3-150 boards. I can't stress how broken these boards are. I have a workaround in mind, but right now the Asus SK8N is broken. The Gigabyte K8NPro (nVidia based) is also mind-numbingly hosed. - Most of my testing has been with SCHED_ULE. SCHED_4BSD works. - the apic and acpi components are 'standard'. - If you have an nVidia nForce3-150 board, you are stuck with 'device atpic' in addition, because they somehow managed to forget to connect the 8254 timer to the apic, even though its in the same silicon! ARGH! This directly violates the ACPI spec.
2003-11-17 08:58:16 +00:00
amd64/pci/pci_cfgreg.c optional pci
Crypto(4) driver for AESNI. The aeskeys_{amd64,i386}.S content was mostly obtained from OpenBSD, no objections to the license from core. Hardware provided by: Sentex Communications Tested by: fabient, pho (previous versions) MFC after: 1 month
2010-07-23 11:00:46 +00:00
crypto/aesni/aesencdec_amd64.S optional aesni
crypto/aesni/aeskeys_amd64.S optional aesni
crypto/aesni/aesni.c optional aesni
crypto/aesni/aesni_wrap.c optional aesni
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
Connect padlock(4) to amd64 build for VIA Nano processors.
2009-01-12 19:23:46 +00:00
crypto/via/padlock.c optional padlock
crypto/via/padlock_cipher.c optional padlock
crypto/via/padlock_hash.c optional padlock
Fix a mis-sort.
2004-12-21 02:07:38 +00:00
dev/acpica/acpi_if.m standard
* Driver for ACPI WMI (Windows Management Instrumentation) * Driver for ACPI HP extra functionations, which required ACPI WMI driver. Submitted by: Michael <freebsdusb at bindone.de> Approved by: re MFC after: 2 weeks
2009-06-23 13:17:25 +00:00
dev/acpi_support/acpi_wmi_if.m standard
- Add few VIA bridges to agp_via.c and connect it to amd64 build as they support Intel Core/Core 2 and VIA Nano processors. - Align "optional agp" in conf/files.* for consistency while I am here.
2009-01-23 17:48:18 +00:00
dev/agp/agp_amd64.c optional agp
dev/agp/agp_i810.c optional agp
dev/agp/agp_intel.c optional agp
dev/agp/agp_via.c optional agp
amdsbwd: new driver for AMD SB600/SB7xx watchdog timer The hardware is compliant with WDRT specification, so I originally considered including generic WDRT watchdog support, but decided against it, because I couldn't find anyone to the code for me. WDRT seems to be not very popular. Besides, generic WDRT porbably requires a slightly different driver approach. Reviewed by: des, gavin, rpaulo MFC after: 3 weeks
2009-11-30 11:44:03 +00:00
dev/amdsbwd/amdsbwd.c optional amdsbwd
Rename the k8temp driver to amdtemp. MFC after: 2 weeks
2009-03-13 16:08:08 +00:00
dev/amdtemp/amdtemp.c optional amdtemp
FIx a botch with the addition of the arcmsr driver.
2005-04-01 19:32:12 +00:00
dev/arcmsr/arcmsr.c optional arcmsr pci
Connect asmc to the build infrastructure. Approved by: njl (mentor) Reviewed by: njl (mentor)
2007-11-07 20:08:15 +00:00
dev/asmc/asmc.c optional asmc isa
- Hook up the new locations of the atkbdc(4), atkbd(4) and psm(4) source files after they were repo-copied to sys/dev/atkbdc. The sources of atkbdc(4) and its children were moved to the new location in preparation for adding an EBus front-end to atkbdc(4) for use on sparc64; i.e. in order to not further scatter them over the whole tree which would have been the result of adding atkbdc_ebus.c in e.g. sys/sparc64/ebus. Another reason for the repo-copies was that some of the sources were misfiled, e.g. sys/isa/atkbd_isa.c wasn't ISA-specific at all but for hanging atkbd(4) off of atkbdc(4) and was renamed to atkbd_atkbdc.c accordingly. Most of sys/isa/psm.c, i.e. expect for its PSMC PNP part, also isn't ISA-specific. - Separate the parts of atkbdc_isa.c which aren't actually ISA-specific but are shareable between different atkbdc(4) bus front-ends into atkbdc_subr.c (repo-copied from atkbdc_isa.c). While here use bus_generic_rl_alloc_resource() and bus_generic_rl_release_resource() respectively in atkbdc_isa.c instead of rolling own versions. - Add sparc64 MD bits to atkbdc(4) and atkbd(4) and an EBus front-end for atkbdc(4). PS/2 controllers and input devices are used on a couple of Sun OEM boards and occur on either the EBus or the ISA bus. Depending on the board it's either the only on-board mean to connect a keyboard and mouse or an alternative to either RS232 or USB devices. - Wrap the PSMC PNP part of psm.c in #ifdef DEV_ISA so it can be compiled without isa(4) (e.g. for EBus-only machines). This ISA-specific part isn't separated into its own source file, yet, as it requires more work than was feasible for 6.0 in order to do it in a clean way. Actually philip@ is working on a rewrite of psm(4) so a more comprehensive clean-up and separation of hardware dependent and independent parts is expected to happen after 6.0. Tested on: i386, sparc64 (AX1105, AXe and AXi boards) Reviewed by: philip
2005-06-10 20:56:38 +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_isa.c optional atkbdc isa
dev/atkbdc/atkbdc_subr.c optional atkbdc
dev/atkbdc/psm.c optional psm atkbdc
Add a driver for the on-die digital thermal sensor found on Intel Core and newer CPUs (including Core 2 and Core / Core 2 based Xeons). The driver attaches to each cpu device and creates a sysctl node in that device's sysctl context (dev.cpu.N.temperature). When invoked, the handler binds to the appropriate CPU to ensure a correct reading. Submitted by: Rui Paulo <rpaulo@fnop.net> Sponsored by: Google Summer of Code 2007 Tested by: des, marcus, Constantine A. Murenin, Ian FREISLICH Approved by: re (kensmith) MFC after: 3 weeks
2007-08-15 19:26:03 +00:00
dev/coretemp/coretemp.c optional coretemp
- Add cpuctl(4) pseudo-device driver to provide access to some low-level features of CPUs like reading/writing machine-specific registers, retrieving cpuid data, and updating microcode. - Add cpucontrol(8) utility, that provides userland access to the features of cpuctl(4). - Add subsequent manpages. The cpuctl(4) device operates as follows. The pseudo-device node cpuctlX is created for each cpu present in the systems. The pseudo-device minor number corresponds to the cpu number in the system. The cpuctl(4) pseudo- device allows a number of ioctl to be preformed, namely RDMSR/WRMSR/CPUID and UPDATE. The first pair alows the caller to read/write machine-specific registers from the correspondent CPU. cpuid data could be retrieved using the CPUID call, and microcode updates are applied via UPDATE. The permissions are inforced based on the pseudo-device file permissions. RDMSR/CPUID will be allowed when the caller has read access to the device node, while WRMSR/UPDATE will be granted only when the node is opened for writing. There're also a number of priv(9) checks. The cpucontrol(8) utility is intened to provide userland access to the cpuctl(4) device features. The utility also allows one to apply cpu microcode updates. Currently only Intel and AMD cpus are supported and were tested. Approved by: kib Reviewed by: rpaulo, cokane, Peter Jeremy MFC after: 1 month
2008-08-08 16:26:53 +00:00
dev/cpuctl/cpuctl.c optional cpuctl
Automatically depend on x86emu when vesa or dpms is being built into kernel. With this change the user no longer need to remember building this option. Submitted by: swell.k at gmail.com
2009-09-21 07:08:20 +00:00
dev/dpms/dpms.c optional dpms
Add the ed driver for lint building. The PCI instances are still useful. In theory, there are no isa slots on any amd64/em64t systems, but it doesn't hurt to keep these tiny fragments compiling.
2005-07-21 21:55:11 +00:00
# There are no systems with isa slots, so all ed isa entries should go..
dev/ed/if_ed_3c503.c optional ed isa ed_3c503
dev/ed/if_ed_isa.c optional ed isa
dev/ed/if_ed_wd80x3.c optional ed isa
dev/ed/if_ed_hpp.c optional ed isa ed_hpp
dev/ed/if_ed_sic.c optional ed isa ed_sic
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/fb/fb.c optional fb | vga
Enable s3pci on amd64 which works on top of VESA, and allow static building it into kernel on i386 and amd64. Submitted by: swell.k at gmail.com
2009-09-21 07:05:48 +00:00
dev/fb/s3_pci.c optional s3pci
Automatically depend on x86emu when vesa or dpms is being built into kernel. With this change the user no longer need to remember building this option. Submitted by: swell.k at gmail.com
2009-09-21 07:08:20 +00:00
dev/fb/vesa.c optional vga vesa
Sync up with the files in the hammer branch in the p4 tree to get basic AMD64 support. There is still more to add.
2003-05-01 02:59:24 +00:00
dev/fb/vga.c optional vga
Sync i386->amd64. * Add ichwd (The Intel EM64T folks have an ICH) * Cosmetic comment syncs * Merge cpufreq change over to NOTES * add pbio (it compiles, but isn't useful since no boxes have ISA slots) * copy ath settings (note: wlan disabled here since its in global NOTES) * copy profiling, including fixing a previous i386->amd64 merge typo. Approved by: re (blanket i386 <-> amd64 sync/convergence)
2005-06-30 05:33:26 +00:00
dev/ichwd/ichwd.c optional ichwd
Add support for Windows/x86-64 binaries to Project Evil. Ville-Pertti Keinonen (will at exomi dot comohmygodnospampleasekthx) deserves a big thanks for submitting initial patches to make it work. I have mangled his contributions appropriately. The main gotcha with Windows/x86-64 is that Microsoft uses a different calling convention than everyone else. The standard ABI requires using 6 registers for argument passing, with other arguments on the stack. Microsoft uses only 4 registers, and requires the caller to leave room on the stack for the register arguments incase the callee needs to spill them. Unlike x86, where Microsoft uses a mix of _cdecl, _stdcall and _fastcall, all routines on Windows/x86-64 uses the same convention. This unfortunately means that all the functions we export to the driver require an intermediate translation wrapper. Similarly, we have to wrap all calls back into the driver binary itself. The original patches provided macros to wrap every single routine at compile time, providing a secondary jump table with a customized wrapper for each exported routine. I decided to use a different approach: the call wrapper for each function is created from a template at runtime, and the routine to jump to is patched into the wrapper as it is created. The subr_pe module has been modified to patch in the wrapped function instead of the original. (On x86, the wrapping routine is a no-op.) There are some minor API differences that had to be accounted for: - KeAcquireSpinLock() is a real function on amd64, not a macro wrapper around KfAcquireSpinLock() - NdisFreeBuffer() is actually IoFreeMdl(). I had to change the whole NDIS_BUFFER API a bit to accomodate this. Bugs fixed along the way: - IoAllocateMdl() always returned NULL - kern_windrv.c:windrv_unload() wasn't releasing private driver object extensions correctly (found thanks to memguard) This has only been tested with the driver for the Broadcom 802.11g chipset, which was the only Windows/x86-64 driver I could find.
2005-02-16 05:41:18 +00:00
dev/if_ndis/if_ndis.c optional ndis
dev/if_ndis/if_ndis_pccard.c optional ndis pccard
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/if_ndis/if_ndis_pci.c optional ndis cardbus | ndis pci
Throw the switch on the new driver generation/loading mechanism. From here on in, if_ndis.ko will be pre-built as a module, and can be built into a static kernel (though it's not part of GENERIC). Drivers are created using the new ndisgen(8) script, which uses ndiscvt(8) under the covers, along with a few other tools. The result is a driver module that can be kldloaded into the kernel. A driver with foo.inf and foo.sys files will be converted into foo_sys.ko (and foo_sys.o, for those who want/need to make static kernels). This module contains all of the necessary info from the .INF file and the driver binary image, converted into an ELF module. You can kldload this module (or add it to /boot/loader.conf) to have it loaded automatically. Any required firmware files can be bundled into the module as well (or converted/loaded separately). Also, add a workaround for a problem in NdisMSleep(). During system bootstrap (cold == 1), msleep() always returns 0 without actually sleeping. The Intel 2200BG driver uses NdisMSleep() to wait for the NIC's firmware to come to life, and fails to load if NdisMSleep() doesn't actually delay. As a workaround, if msleep() (and hence ndis_thsuspend()) returns 0, use a hard DELAY() to sleep instead). This is not really the right thing to do, but we can't really do much else. At the very least, this makes the Intel driver happy. There are probably other drivers that fail in this way during bootstrap. Unfortunately, the only workaround for those is to avoid pre-loading them and kldload them once the system is running instead.
2005-04-24 20:21:22 +00:00
dev/if_ndis/if_ndis_usb.c optional ndis usb
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
dev/io/iodev.c optional io
Tie the ipmi driver into the i386/amd64 builds.
2006-02-13 17:56:24 +00:00
dev/ipmi/ipmi.c optional ipmi
Update the ipmi(4) driver: - Split out the communication protocols into their own files and use a couple of function pointers in the softc that the commuication protocols setup in their own attach routine. - Add support for the SSIF interface (talking to IPMI over SMBus). - Add an ACPI attachment. - Add a PCI attachment that attaches to devices with the IPMI interface subclass. - Split the ISA attachment out into its own file: ipmi_isa.c. - Change the code to probe the SMBIOS table for an IPMI entry to just use pmap_mapbios() to map the table in rather than trying to setup a fake resource on an isa device and then activating the resource to map in the table. - Make bus attachments leaner by adding attach functions for each communication interface (ipmi_kcs_attach(), ipmi_smic_attach(), etc.) that setup per-interface data. - Formalize the model used by the driver to handle requests by adding an explicit struct ipmi_request object that holds the state of a given request and reply for the entire lifetime of the request. By bundling the request into an object, it is easier to add retry logic to the various communication backends (as well as eventually support BT mode which uses a slightly different message format than KCS, SMIC, and SSIF). - Add a per-softc lock and remove D_NEEDGIANT as the driver is now MPSAFE. - Add 32-bit compatibility ioctl shims so you can use a 32-bit ipmitool on FreeBSD/amd64. - Add ipmi(4) to i386 and amd64 NOTES. Submitted by: ambrisko (large portions of 2 and 3) Sponsored by: IronPort Systems, Yahoo! MFC after: 6 days
2006-09-22 22:11:29 +00:00
dev/ipmi/ipmi_acpi.c optional ipmi acpi
dev/ipmi/ipmi_isa.c optional ipmi isa
dev/ipmi/ipmi_kcs.c optional ipmi
dev/ipmi/ipmi_smic.c optional ipmi
dev/ipmi/ipmi_smbus.c optional ipmi smbus
dev/ipmi/ipmi_smbios.c optional ipmi
dev/ipmi/ipmi_ssif.c optional ipmi smbus
Tie the ipmi driver into the i386/amd64 builds.
2006-02-13 17:56:24 +00:00
dev/ipmi/ipmi_pci.c optional ipmi pci
Sigh, not my day. Check-in the update version that didn't have the linux_compat mistakes.
2009-03-26 20:23:21 +00:00
dev/ipmi/ipmi_linux.c optional ipmi compat_linux32
Fix mismerge of fdc. Also, OLDCARD never was supported on amd64, so remove fdc attachment for it.
2004-07-09 05:05:13 +00:00
dev/fdc/fdc.c optional fdc
Hook up fdc_acpi for the kernel build.
2004-07-15 16:43:52 +00:00
dev/fdc/fdc_acpi.c optional fdc
Break out the isa and pccard front ends to the fdc controller device. This should allow us to more easily break out the acpi and 'legacy pc' front ends as well (so only the bus front end would touch rtc, for example). This isn't a great separation, since isa dma routines are still called from the MI code, but it is a start.
2004-07-07 22:29:33 +00:00
dev/fdc/fdc_isa.c optional fdc isa
dev/fdc/fdc_pccard.c optional fdc pccard
Hook up the hptmv driver for amd64. MFC After: 3 days
2005-09-08 03:29:18 +00:00
dev/hptmv/entry.c optional hptmv
dev/hptmv/mv.c optional hptmv
dev/hptmv/gui_lib.c optional hptmv
dev/hptmv/hptproc.c optional hptmv
dev/hptmv/ioctl.c optional hptmv
Add the 'hptrr' driver for supporting the following Highpoint RocketRAID cards: o RocketRAID 172x series o RocketRAID 174x series o RocketRAID 2210 o RocketRAID 222x series o RocketRAID 2240 o RocketRAID 230x series o RocketRAID 231x series o RocketRAID 232x series o RocketRAID 2340 o RocketRAID 2522 Many thanks to Highpoint for their continued support of FreeBSD. Submitted by: Highpoint
2007-12-15 00:56:17 +00:00
dev/hptrr/hptrr_os_bsd.c optional hptrr
dev/hptrr/hptrr_osm_bsd.c optional hptrr
dev/hptrr/hptrr_config.c optional hptrr
Update the file.* entries for the new home of hwpmc
2005-04-29 02:40:16 +00:00
dev/hwpmc/hwpmc_amd.c optional hwpmc
- Separate PMC class dependent code from other kinds of machine dependencies. A 'struct pmc_classdep' structure describes operations on PMCs; 'struct pmc_mdep' contains one or more 'struct pmc_classdep' structures depending on the CPU in question. Inside PMC class dependent code, row indices are relative to the PMCs supported by the PMC class; MI code in "hwpmc_mod.c" translates global row indices before invoking class dependent operations. - Augment the OP_GETCPUINFO request with the number of PMCs present in a PMC class. - Move code common to Intel CPUs to file "hwpmc_intel.c". - Move TSC handling to file "hwpmc_tsc.c".
2008-11-09 17:37:54 +00:00
dev/hwpmc/hwpmc_intel.c optional hwpmc
- Add support for PMCs in Intel CPUs of Family 6, model 0xE (Core Solo and Core Duo), models 0xF (Core2), model 0x17 (Core2Extreme) and model 0x1C (Atom). In these CPUs, the actual numbers, kinds and widths of PMCs present need to queried at run time. Support for specific "architectural" events also needs to be queried at run time. Model 0xE CPUs support programmable PMCs, subsequent CPUs additionally support "fixed-function" counters. - Use event names that are close to vendor documentation, taking in account that: - events with identical semantics on two or more CPUs in this family can have differing names in vendor documentation, - identical vendor event names may map to differing events across CPUs, - each type of CPU supports a different subset of measurable events. Fixed-function and programmable counters both use the same vendor names for events. The use of a class name prefix ("iaf-" or "iap-" respectively) permits these to be distinguished. - In libpmc, refactor pmc_name_of_event() into a public interface and an internal helper function, for use by log handling code. - Minor code tweaks: staticize a global, freshen a few comments. Tested by: gnn
2008-11-27 09:00:47 +00:00
dev/hwpmc/hwpmc_core.c optional hwpmc
- Support for uncore counting events: one fixed PMC with the uncore domain clock, 8 programmable PMC. - Westmere based CPU (Xeon 5600, Corei7 980X) support. - New man pages with events list for core and uncore. - Updated Corei7 events with Intel 253669-033US December 2009 doc. There is some removed events in the documentation, they have been kept in the code but documented in the man page as obsolete. - Offcore response events can be setup with rsp token. Sponsored by: NETASQ
2010-04-02 13:23:49 +00:00
dev/hwpmc/hwpmc_uncore.c optional hwpmc
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_piv.c optional hwpmc
- Separate PMC class dependent code from other kinds of machine dependencies. A 'struct pmc_classdep' structure describes operations on PMCs; 'struct pmc_mdep' contains one or more 'struct pmc_classdep' structures depending on the CPU in question. Inside PMC class dependent code, row indices are relative to the PMCs supported by the PMC class; MI code in "hwpmc_mod.c" translates global row indices before invoking class dependent operations. - Augment the OP_GETCPUINFO request with the number of PMCs present in a PMC class. - Move code common to Intel CPUs to file "hwpmc_intel.c". - Move TSC handling to file "hwpmc_tsc.c".
2008-11-09 17:37:54 +00:00
dev/hwpmc/hwpmc_tsc.c optional hwpmc
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_x86.c optional hwpmc
Remove the usb2_input_kbd directive that was missed during the renaming of the drivers in the usb2 stack. Approved by: rrs (mentor)
2010-02-08 19:48:33 +00:00
dev/kbd/kbd.c optional atkbd | sc | ukbd
lindev(4) [1] is supposed to be a collection of linux-specific pseudo devices that we also support, just not by default (thus only LINT or module builds by default). While currently there is only "/dev/full" [2], we are planning to see more in the future. We may decide to change the module/dependency logic in the future should the list grow too long. This is not part of linux.ko as also non-linux binaries like kFreeBSD userland or ports can make use of this as well. Suggested by: rwatson [1] (name) Submitted by: ed [2] Discussed with: markm, ed, rwatson, kib (weeks ago) Reviewed by: rwatson, brueffer (prev. version) PR: kern/68961 MFC after: 6 weeks
2009-09-26 12:45:28 +00:00
dev/lindev/full.c optional lindev
dev/lindev/lindev.c optional lindev
Add a pure open source nForce Ethernet driver, under BSDL. This driver was ported from OpenBSD by Shigeaki Tagashira <shigeaki@se.hiroshima-u.ac.jp> and posted at http://www.se.hiroshima-u.ac.jp/~shigeaki/software/freebsd-nfe.html It was additionally cleaned up by me. It is still a work-in-progress and thus is purposefully not in GENERIC. And it conflicts with nve(4), so only one should be loaded.
2006-06-26 23:41:07 +00:00
dev/nfe/if_nfe.c optional nfe pci
FreeBSD consumer bits of the nForce MCP NIC binary blob. Demanded by: DES Encouraged by: scottl Obtained from: q@onthenet.com.au (partially) KNF'ed by: obrien
2005-03-12 00:29:30 +00:00
dev/nve/if_nve.c optional nve pci
Split /dev/nvram driver out of isa/clock.c for i386 and amd64. I have not refactored it to be a generic device. Instead of being part of the standard kernel, there is now a 'nvram' device for i386/amd64. It is in DEFAULTS like io and mem, and can be turned off with 'nodevice nvram'. This matches the previous behavior when it was first committed.
2007-10-26 03:23:54 +00:00
dev/nvram/nvram.c optional nvram isa
Initial landing of SMP support for FreeBSD/amd64. - This is heavily derived from John Baldwin's apic/pci cleanup on i386. - I have completely rewritten or drastically cleaned up some other parts. (in particular, bootstrap) - This is still a WIP. It seems that there are some highly bogus bioses on nVidia nForce3-150 boards. I can't stress how broken these boards are. I have a workaround in mind, but right now the Asus SK8N is broken. The Gigabyte K8NPro (nVidia based) is also mind-numbingly hosed. - Most of my testing has been with SCHED_ULE. SCHED_4BSD works. - the apic and acpi components are 'standard'. - If you have an nVidia nForce3-150 board, you are stuck with 'device atpic' in addition, because they somehow managed to forget to connect the 8254 timer to the apic, even though its in the same silicon! ARGH! This directly violates the ACPI spec.
2003-11-17 08:58:16 +00:00
dev/sio/sio.c optional sio
dev/sio/sio_isa.c optional sio isa
Remove sio(4) and related options from MI files to amd64, i386 and pc98 MD files. Remove nodevice and nooption lines specific to sio(4) from ia64, powerpc and sparc64 NOTES. There were no such lines for arm yet. sio(4) is usable on less than half the platforms, not counting a future mips platform. Its presence in MI files is therefore increasingly becoming a burden.
2006-07-29 18:38:54 +00:00
dev/sio/sio_pccard.c optional sio pccard
dev/sio/sio_pci.c optional sio pci
dev/sio/sio_puc.c optional sio puc
Add /dev/speaker support to amd64. The following repo-copies were made (by Mark Murray): sys/i386/isa/spkr.c -> sys/dev/speaker/spkr.c sys/i386/include/speaker.h -> sys/dev/speaker/speaker.h share/man/man4/man4.i386/spkr.4 -> share/man/man4/spkr.4
2005-11-11 09:57:32 +00:00
dev/speaker/spkr.c optional speaker
Initial landing of SMP support for FreeBSD/amd64. - This is heavily derived from John Baldwin's apic/pci cleanup on i386. - I have completely rewritten or drastically cleaned up some other parts. (in particular, bootstrap) - This is still a WIP. It seems that there are some highly bogus bioses on nVidia nForce3-150 boards. I can't stress how broken these boards are. I have a workaround in mind, but right now the Asus SK8N is broken. The Gigabyte K8NPro (nVidia based) is also mind-numbingly hosed. - Most of my testing has been with SCHED_ULE. SCHED_4BSD works. - the apic and acpi components are 'standard'. - If you have an nVidia nForce3-150 board, you are stuck with 'device atpic' in addition, because they somehow managed to forget to connect the 8254 timer to the apic, even though its in the same silicon! ARGH! This directly violates the ACPI spec.
2003-11-17 08:58:16 +00:00
dev/syscons/apm/apm_saver.c optional apm_saver apm
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
Automatically depend on x86emu when vesa or dpms is being built into kernel. With this change the user no longer need to remember building this option. Submitted by: swell.k at gmail.com
2009-09-21 07:08:20 +00:00
dev/syscons/scvesactl.c optional sc vga vesa
Sync up with the files in the hammer branch in the p4 tree to get basic AMD64 support. There is still more to add.
2003-05-01 02:59:24 +00:00
dev/syscons/scvgarndr.c optional sc vga
dev/syscons/scvtb.c optional sc
Add support 'device tpm' for amd64. Add tpm(4)'s default setting to /boot/defaults/loader.conf. Add 'device tpm' to NOTES for amd64 and i386. Discussed with: takawata Approved by: imp (mentor)
2010-09-19 14:40:37 +00:00
dev/tpm/tpm.c optional tpm
dev/tpm/tpm_acpi.c optional tpm acpi
dev/tpm/tpm_isa.c optional tpm isa
Initial landing of SMP support for FreeBSD/amd64. - This is heavily derived from John Baldwin's apic/pci cleanup on i386. - I have completely rewritten or drastically cleaned up some other parts. (in particular, bootstrap) - This is still a WIP. It seems that there are some highly bogus bioses on nVidia nForce3-150 boards. I can't stress how broken these boards are. I have a workaround in mind, but right now the Asus SK8N is broken. The Gigabyte K8NPro (nVidia based) is also mind-numbingly hosed. - Most of my testing has been with SCHED_ULE. SCHED_4BSD works. - the apic and acpi components are 'standard'. - If you have an nVidia nForce3-150 board, you are stuck with 'device atpic' in addition, because they somehow managed to forget to connect the 8254 timer to the apic, even though its in the same silicon! ARGH! This directly violates the ACPI spec.
2003-11-17 08:58:16 +00:00
dev/uart/uart_cpu_amd64.c optional uart
Link wpi(4) into the build. This includes: o mtree (for legal/intel_wpi) o manpage for i386/amd64 archs o module for i386/amd64 archs o NOTES for i386/amd64 archs Approved by: mlaier (comentor)
2007-11-08 22:09:37 +00:00
dev/wpi/if_wpi.c optional wpi
Sync up with the files in the hammer branch in the p4 tree to get basic AMD64 support. There is still more to add.
2003-05-01 02:59:24 +00:00
isa/syscons_isa.c optional sc
isa/vga_isa.c optional vga
Rename timeevents.c to kern_clocksource.c. Suggested by: jhb@
2010-07-14 18:43:27 +00:00
kern/kern_clocksource.c standard
Enable first part of kld's on amd64. This is known to not work right yet, but building kld's is OK now and they can be loaded by kldload(2). (but the machine will likely crash soon afterwards, a "minor" problem :-) Brought to you by: my injured knee (from moving)
2004-05-16 20:11:38 +00:00
kern/link_elf_obj.c standard
Initial landing of SMP support for FreeBSD/amd64. - This is heavily derived from John Baldwin's apic/pci cleanup on i386. - I have completely rewritten or drastically cleaned up some other parts. (in particular, bootstrap) - This is still a WIP. It seems that there are some highly bogus bioses on nVidia nForce3-150 boards. I can't stress how broken these boards are. I have a workaround in mind, but right now the Asus SK8N is broken. The Gigabyte K8NPro (nVidia based) is also mind-numbingly hosed. - Most of my testing has been with SCHED_ULE. SCHED_4BSD works. - the apic and acpi components are 'standard'. - If you have an nVidia nForce3-150 board, you are stuck with 'device atpic' in addition, because they somehow managed to forget to connect the 8254 timer to the apic, even though its in the same silicon! ARGH! This directly violates the ACPI spec.
2003-11-17 08:58:16 +00:00
#
# IA32 binary support
#
Provide groundwork for 32-bit binary compatibility on non-x86 platforms, for upcoming 64-bit PowerPC and MIPS support. This renames the COMPAT_IA32 option to COMPAT_FREEBSD32, removes some IA32-specific code from MI parts of the kernel and enhances the freebsd32 compatibility code to support big-endian platforms. Reviewed by: kib, jhb
2010-03-11 14:49:06 +00:00
#amd64/ia32/ia32_exception.S optional compat_freebsd32
amd64/ia32/ia32_reg.c optional compat_freebsd32
amd64/ia32/ia32_signal.c optional compat_freebsd32
amd64/ia32/ia32_sigtramp.S optional compat_freebsd32
amd64/ia32/ia32_syscall.c optional compat_freebsd32
amd64/ia32/ia32_misc.c optional compat_freebsd32
compat/freebsd32/freebsd32_ioctl.c optional compat_freebsd32
compat/freebsd32/freebsd32_misc.c optional compat_freebsd32
compat/freebsd32/freebsd32_syscalls.c optional compat_freebsd32
compat/freebsd32/freebsd32_sysent.c optional compat_freebsd32
compat/ia32/ia32_sysvec.c optional compat_freebsd32
- change the example of compiling only specific modules to not contain the linux module, since it is not cross-platform - move linprocfs from "files" and "options" to architecture specific files, since it only makes sense to build this for those architectures, where we also have a linuxolator - disable the build of the linuxolator on our tier-2 architecture "Alpha": * we don't have a linux_base port which supports Alpha and at the same time is not outdated/obsoleted upstream/in a good condition/ currently working * the upcomming new default linux base port is based upon Fedora Core 3 (security support via http://www.fedoralegacy.org), which isn't available for Alpha (like the current default linux base port which is based upon Red Hat 8) * nobody answered my request for testing it ~1 month ago on current@ and alpha@ (it doesn't surprises me, see above) * a SoC student wouldn't have to waste time on something which nobody is willing to test This does not remove the alpha specific MD files of the linuxolator yet. Discussed on: arch (mostly silence) Spiritual support by: scottl
2006-05-07 18:12:18 +00:00
compat/linprocfs/linprocfs.c optional linprocfs
Add in linsysfs. A linux 2.6 like sys filesystem to pacify the Linux LSI MegaRAID SAS utility. Sponsored by: IronPort Systems Man page help from: brueffer
2006-05-09 22:27:01 +00:00
compat/linsysfs/linsysfs.c optional linsysfs
Provide groundwork for 32-bit binary compatibility on non-x86 platforms, for upcoming 64-bit PowerPC and MIPS support. This renames the COMPAT_IA32 option to COMPAT_FREEBSD32, removes some IA32-specific code from MI parts of the kernel and enhances the freebsd32 compatibility code to support big-endian platforms. Reviewed by: kib, jhb
2010-03-11 14:49:06 +00:00
kern/imgact_elf32.c optional compat_freebsd32
Add preliminary support for running 32-bit Linux binaries on amd64, enabled with the COMPAT_LINUX32 option. This is largely based on the i386 MD Linux emulations bits, but also builds on the 32-bit FreeBSD and generic IA-32 binary emulation work. Some of this is still a little rough around the edges, and will need to be revisited before 32-bit and 64-bit Linux emulation support can coexist in the same kernel.
2004-08-16 07:55:06 +00:00
#
# Linux/i386 binary support
#
amd64/linux32/linux32_dummy.c optional compat_linux32
amd64/linux32/linux32_locore.s optional compat_linux32 \
dependency "linux32_assym.h"
amd64/linux32/linux32_machdep.c optional compat_linux32
Fix the dependency for the linux_support.s, explicitely add linux_assym.h. Reported by: rwatson In collaboration with: rdivacky Sponsored by: Google SoC 2007
2007-05-23 15:45:52 +00:00
amd64/linux32/linux32_support.s optional compat_linux32 \
dependency "linux32_assym.h"
Add preliminary support for running 32-bit Linux binaries on amd64, enabled with the COMPAT_LINUX32 option. This is largely based on the i386 MD Linux emulations bits, but also builds on the 32-bit FreeBSD and generic IA-32 binary emulation work. Some of this is still a little rough around the edges, and will need to be revisited before 32-bit and 64-bit Linux emulation support can coexist in the same kernel.
2004-08-16 07:55:06 +00:00
amd64/linux32/linux32_sysent.c optional compat_linux32
amd64/linux32/linux32_sysvec.c optional compat_linux32
Move futex support code from <arch>/support.s into linux compat directory. Implement all futex atomic operations in assembler to not depend on the fuword() that does not allow to distinguish between -1 and failure return. Correctly return 0 from atomic operations on success. In collaboration with: rdivacky Tested by: Scot Hetzel <swhetzel gmail com>, Milos Vyletel <mvyletel mzm cz> Sponsored by: Google SoC 2007
2007-05-23 08:33:06 +00:00
compat/linux/linux_emul.c optional compat_linux32
Add preliminary support for running 32-bit Linux binaries on amd64, enabled with the COMPAT_LINUX32 option. This is largely based on the i386 MD Linux emulations bits, but also builds on the 32-bit FreeBSD and generic IA-32 binary emulation work. Some of this is still a little rough around the edges, and will need to be revisited before 32-bit and 64-bit Linux emulation support can coexist in the same kernel.
2004-08-16 07:55:06 +00:00
compat/linux/linux_file.c optional compat_linux32
Move linux_clone(), linux_fork(), linux_vfork() to a MI path.
2011-02-12 18:17:12 +00:00
compat/linux/linux_fork.c optional compat_linux32
Add the linux 2.6.x stuff (not used by default!): - TLS - complete - pid/tid mangling - complete - thread area - complete - futexes - complete with issues - clone() extension - complete with some possible minor issues - mq*/timer*/clock* stuff - complete but untested and the mq* stuff is disabled when not build as part of the kernel with native FreeBSD mq* support (module support for this will come later) Tested with: - linux-firefox - works, tested - linux-opera - works, tested - linux-realplay - doesnt work, issue with futexes - linux-skype - doesnt work, issue with futexes - linux-rt2-demo - works, tested - linux-acroread - doesnt work, unknown reason (coredump) and sometimes issue with futexes - various unix utilities in linux-base-gentoo3 and linux-base-fc4: everything tried worked On amd64 not everything is supported like on i386, the catchup is planned for later when the remaining bugs in the new functions are fixed. To test this new stuff, you have to run sysctl compat.linux.osrelease=2.6.16 to switch back use sysctl compat.linux.osrelease=2.4.2 Don't switch while running a linux program, strange things may or may not happen. Sponsored by: Google SoC 2006 Submitted by: rdivacky Some suggestions/help by: jhb, kib, manu@NetBSD.org, netchild
2006-08-15 12:54:30 +00:00
compat/linux/linux_futex.c optional compat_linux32
Add preliminary support for running 32-bit Linux binaries on amd64, enabled with the COMPAT_LINUX32 option. This is largely based on the i386 MD Linux emulations bits, but also builds on the 32-bit FreeBSD and generic IA-32 binary emulation work. Some of this is still a little rough around the edges, and will need to be revisited before 32-bit and 64-bit Linux emulation support can coexist in the same kernel.
2004-08-16 07:55:06 +00:00
compat/linux/linux_getcwd.c optional compat_linux32
compat/linux/linux_ioctl.c optional compat_linux32
compat/linux/linux_ipc.c optional compat_linux32
compat/linux/linux_mib.c optional compat_linux32
compat/linux/linux_misc.c optional compat_linux32
compat/linux/linux_signal.c optional compat_linux32
compat/linux/linux_socket.c optional compat_linux32
compat/linux/linux_stats.c optional compat_linux32
compat/linux/linux_sysctl.c optional compat_linux32
Add the linux 2.6.x stuff (not used by default!): - TLS - complete - pid/tid mangling - complete - thread area - complete - futexes - complete with issues - clone() extension - complete with some possible minor issues - mq*/timer*/clock* stuff - complete but untested and the mq* stuff is disabled when not build as part of the kernel with native FreeBSD mq* support (module support for this will come later) Tested with: - linux-firefox - works, tested - linux-opera - works, tested - linux-realplay - doesnt work, issue with futexes - linux-skype - doesnt work, issue with futexes - linux-rt2-demo - works, tested - linux-acroread - doesnt work, unknown reason (coredump) and sometimes issue with futexes - various unix utilities in linux-base-gentoo3 and linux-base-fc4: everything tried worked On amd64 not everything is supported like on i386, the catchup is planned for later when the remaining bugs in the new functions are fixed. To test this new stuff, you have to run sysctl compat.linux.osrelease=2.6.16 to switch back use sysctl compat.linux.osrelease=2.4.2 Don't switch while running a linux program, strange things may or may not happen. Sponsored by: Google SoC 2006 Submitted by: rdivacky Some suggestions/help by: jhb, kib, manu@NetBSD.org, netchild
2006-08-15 12:54:30 +00:00
compat/linux/linux_time.c optional compat_linux32
Add preliminary support for running 32-bit Linux binaries on amd64, enabled with the COMPAT_LINUX32 option. This is largely based on the i386 MD Linux emulations bits, but also builds on the 32-bit FreeBSD and generic IA-32 binary emulation work. Some of this is still a little rough around the edges, and will need to be revisited before 32-bit and 64-bit Linux emulation support can coexist in the same kernel.
2004-08-16 07:55:06 +00:00
compat/linux/linux_uid16.c optional compat_linux32
compat/linux/linux_util.c optional compat_linux32
Add in the Linux IOCTL shim and create the megadev0 device so Linux LSI MegaRaid tools can run on FreeBSD until Linux emulation. Add in the Linux IOCTL shim and create the megadev0 device so Linux LSI MegaRaid tools can run on FreeBSD until Linux emulation. Add glue to build the modules but don't tie it into the build yet until I test it from the CVS repo. via the mirror on an amd64 machine. Tie this into the Linux32 emulation on amd64 so the tools can run on amd64 kernel. Cleaned up by: ps (amr_linux.c)
2006-01-24 21:13:50 +00:00
dev/amr/amr_linux.c optional compat_linux32 amr
Add in a bunch of things to the mfi driver: - Linux ioctl support, with the other Linux changes MegaCli will run if you mount linprocfs & linsysfs then set sysctl compat.linux.osrelease=2.6.12 or similar. This works on i386. It should work on amd64 but not well tested yet. StoreLib may or may not work. Remember to kldload mfi_linux. - Add in AEN (Async Event Notification) support so we can get messages from the firmware when something happens. Not all messages are in defined in event detail. Use event_log to try to figure out what happened. - Try to implement something like SIGIO for StoreLib. Since mrmonitor doesn't work right I can't fully test it. StoreLib works best with the rh9 base. In theory mrmonitor isn't needed due to native driver support of AEN :-) Now we can configure and monitor the RAID better. Submitted by: IronPort Systems.
2006-05-18 23:30:48 +00:00
dev/mfi/mfi_linux.c optional compat_linux32 mfi
Add support for Windows/x86-64 binaries to Project Evil. Ville-Pertti Keinonen (will at exomi dot comohmygodnospampleasekthx) deserves a big thanks for submitting initial patches to make it work. I have mangled his contributions appropriately. The main gotcha with Windows/x86-64 is that Microsoft uses a different calling convention than everyone else. The standard ABI requires using 6 registers for argument passing, with other arguments on the stack. Microsoft uses only 4 registers, and requires the caller to leave room on the stack for the register arguments incase the callee needs to spill them. Unlike x86, where Microsoft uses a mix of _cdecl, _stdcall and _fastcall, all routines on Windows/x86-64 uses the same convention. This unfortunately means that all the functions we export to the driver require an intermediate translation wrapper. Similarly, we have to wrap all calls back into the driver binary itself. The original patches provided macros to wrap every single routine at compile time, providing a secondary jump table with a customized wrapper for each exported routine. I decided to use a different approach: the call wrapper for each function is created from a template at runtime, and the routine to jump to is patched into the wrapper as it is created. The subr_pe module has been modified to patch in the wrapped function instead of the original. (On x86, the wrapping routine is a no-op.) There are some minor API differences that had to be accounted for: - KeAcquireSpinLock() is a real function on amd64, not a macro wrapper around KfAcquireSpinLock() - NdisFreeBuffer() is actually IoFreeMdl(). I had to change the whole NDIS_BUFFER API a bit to accomodate this. Bugs fixed along the way: - IoAllocateMdl() always returned NULL - kern_windrv.c:windrv_unload() wasn't releasing private driver object extensions correctly (found thanks to memguard) This has only been tested with the driver for the Broadcom 802.11g chipset, which was the only Windows/x86-64 driver I could find.
2005-02-16 05:41:18 +00:00
#
# Windows NDIS driver support
#
compat/ndis/kern_ndis.c optional ndisapi pci
compat/ndis/kern_windrv.c optional ndisapi pci
compat/ndis/subr_hal.c optional ndisapi pci
compat/ndis/subr_ndis.c optional ndisapi pci
compat/ndis/subr_ntoskrnl.c optional ndisapi pci
compat/ndis/subr_pe.c optional ndisapi pci
- Correct one aspect of the driver_object/device_object/IRP framework: when we create a PDO, the driver_object associated with it is that of the parent driver, not the driver we're trying to attach. For example, if we attach a PCI device, the PDO we pass to the NdisAddDevice() function should contain a pointer to fake_pci_driver, not to the NDIS driver itself. For PCI or PCMCIA devices this doesn't matter because the child never needs to talk to the parent bus driver, but for USB, the child needs to be able to send IRPs to the parent USB bus driver, and for that to work the parent USB bus driver has to be hung off the PDO. This involves modifying windrv_lookup() so that we can search for bus drivers by name, if necessary. Our fake bus drivers attach themselves as "PCI Bus," "PCCARD Bus" and "USB Bus," so we can search for them using those names. The individual attachment stubs now create and attach PDOs to the parent bus drivers instead of hanging them off the NDIS driver's object, and in if_ndis.c, we now search for the correct driver object depending on the bus type, and use that to find the correct PDO. With this fix, I can get my sample USB ethernet driver to deliver an IRP to my fake parent USB bus driver's dispatch routines. - Add stub modules for USB support: subr_usbd.c, usbd_var.h and if_ndis_usb.c. The subr_usbd.c module is hooked up the build but currently doesn't do very much. It provides the stub USB parent driver object and a dispatch routine for IRM_MJ_INTERNAL_DEVICE_CONTROL. The only exported function at the moment is USBD_GetUSBDIVersion(). The if_ndis_usb.c stub compiles, but is not hooked up to the build yet. I'm putting these here so I can keep them under source code control as I flesh them out.
2005-02-24 21:49:14 +00:00
compat/ndis/subr_usbd.c optional ndisapi pci
Add support for Windows/x86-64 binaries to Project Evil. Ville-Pertti Keinonen (will at exomi dot comohmygodnospampleasekthx) deserves a big thanks for submitting initial patches to make it work. I have mangled his contributions appropriately. The main gotcha with Windows/x86-64 is that Microsoft uses a different calling convention than everyone else. The standard ABI requires using 6 registers for argument passing, with other arguments on the stack. Microsoft uses only 4 registers, and requires the caller to leave room on the stack for the register arguments incase the callee needs to spill them. Unlike x86, where Microsoft uses a mix of _cdecl, _stdcall and _fastcall, all routines on Windows/x86-64 uses the same convention. This unfortunately means that all the functions we export to the driver require an intermediate translation wrapper. Similarly, we have to wrap all calls back into the driver binary itself. The original patches provided macros to wrap every single routine at compile time, providing a secondary jump table with a customized wrapper for each exported routine. I decided to use a different approach: the call wrapper for each function is created from a template at runtime, and the routine to jump to is patched into the wrapper as it is created. The subr_pe module has been modified to patch in the wrapped function instead of the original. (On x86, the wrapping routine is a no-op.) There are some minor API differences that had to be accounted for: - KeAcquireSpinLock() is a real function on amd64, not a macro wrapper around KfAcquireSpinLock() - NdisFreeBuffer() is actually IoFreeMdl(). I had to change the whole NDIS_BUFFER API a bit to accomodate this. Bugs fixed along the way: - IoAllocateMdl() always returned NULL - kern_windrv.c:windrv_unload() wasn't releasing private driver object extensions correctly (found thanks to memguard) This has only been tested with the driver for the Broadcom 802.11g chipset, which was the only Windows/x86-64 driver I could find.
2005-02-16 05:41:18 +00:00
compat/ndis/winx64_wrap.S optional ndisapi pci
Be more conservative and compile libkern/memset.c only on architectures than need it. These are i386, amd64 and powerpc so far.
2007-04-06 04:51:50 +00:00
#
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
Be more conservative and compile libkern/memset.c only on architectures than need it. These are i386, amd64 and powerpc so far.
2007-04-06 04:51:50 +00:00
libkern/memset.c standard
Hide x86bios stuff in i386/amd64 specific files as atkbdc would get these stuff into build.
2009-09-22 07:10:23 +00:00
#
# x86 real mode BIOS emulator, required by atkbdc/dpms/vesa
#
Move sys/dev/x86bios to sys/compat/x86bios. It may not be optimal but it is clearly better than the old place. OK'ed by: delphij, paradox (ddkprog yahoo com)
2009-09-23 20:49:14 +00:00
compat/x86bios/x86bios.c optional x86bios | atkbd | dpms | vesa
r197444 unnecessarily changed positions of these files. Re-sort.
2009-09-24 19:42:56 +00:00
contrib/x86emu/x86emu.c optional x86bios | atkbd | dpms | vesa
Introduce the new kernel sub-tree x86 which should contain all the code shared and generalized between our current amd64, i386 and pc98. This is just an initial step that should lead to a more complete effort. For the moment, a very simple porting of cpufreq modules, BIOS calls and the whole MD specific ISA bus part is added to the sub-tree but ideally a lot of code might be added and more shared support should grow. Sponsored by: Sandvine Incorporated Reviewed by: emaste, kib, jhb, imp Discussed on: arch MFC: 3 weeks
2010-02-25 14:13:39 +00:00
#
# x86 shared code between IA32, AMD64 and PC98 architectures
#
Now OsdEnvironment.c is identical on amd64 and i386. Move it to a new home.
2010-11-09 00:27:18 +00:00
x86/acpica/OsdEnvironment.c optional acpi
Refactor acpi_machdep.c for amd64 and i386, move APM emulation into a new file acpi_apm.c, and place it on sys/x86/acpica.
2010-11-10 01:29:56 +00:00
x86/acpica/acpi_apm.c optional acpi
Move the MADT parser for amd64 and i386 to sys/x86/acpica now that it is identical on both platforms.
2010-11-08 20:57:02 +00:00
x86/acpica/madt.c optional acpi
Add a parser for the ACPI SRAT table for amd64 and i386. It sets PCPU(domain) for each CPU and populates a mem_affinity array suitable for the NUMA support in the physical memory allocator. Reviewed by: alc
2010-07-27 20:40:46 +00:00
x86/acpica/srat.c optional acpi
Introduce the new kernel sub-tree x86 which should contain all the code shared and generalized between our current amd64, i386 and pc98. This is just an initial step that should lead to a more complete effort. For the moment, a very simple porting of cpufreq modules, BIOS calls and the whole MD specific ISA bus part is added to the sub-tree but ideally a lot of code might be added and more shared support should grow. Sponsored by: Sandvine Incorporated Reviewed by: emaste, kib, jhb, imp Discussed on: arch MFC: 3 weeks
2010-02-25 14:13:39 +00:00
x86/bios/smbios.c optional smbios
x86/bios/vpd.c optional vpd
x86/cpufreq/powernow.c optional cpufreq
x86/cpufreq/est.c optional cpufreq
x86/cpufreq/hwpstate.c optional cpufreq
x86/cpufreq/p4tcc.c optional cpufreq
x86/isa/atpic.c optional atpic isa
Fix a mis-change about the compiling of atrtc.c. Sponsored by: Sandvine Incorporated Reported by: Giovanni Trematerra <giovannit dot trematerra at gmail dot com> MFC: 3 weeks X-MFC: r204309
2010-02-25 15:00:27 +00:00
x86/isa/atrtc.c standard
Introduce the new kernel sub-tree x86 which should contain all the code shared and generalized between our current amd64, i386 and pc98. This is just an initial step that should lead to a more complete effort. For the moment, a very simple porting of cpufreq modules, BIOS calls and the whole MD specific ISA bus part is added to the sub-tree but ideally a lot of code might be added and more shared support should grow. Sponsored by: Sandvine Incorporated Reviewed by: emaste, kib, jhb, imp Discussed on: arch MFC: 3 weeks
2010-02-25 14:13:39 +00:00
x86/isa/clock.c standard
x86/isa/elcr.c standard
x86/isa/isa.c standard
x86/isa/isa_dma.c standard
x86/isa/nmi.c standard
x86/isa/orm.c optional isa
Intel QPI chipsets actually provide two extra "non-core" PCI buses that provide PCI devices for various hardware such as memory controllers, etc. These PCI buses are not enumerated via ACPI however. Add qpi(4) psuedo bus and Host-PCI bridge drivers to enumerate these buses. Currently the driver uses the CPU ID to determine the bridges' presence. In collaboration with: Joseph Golio @ Isilon Systems MFC after: 2 weeks
2010-08-25 19:12:05 +00:00
x86/pci/qpi.c standard
Replace i386/i386/busdma_machdep.c and amd64/amd64/busdma_machdep.c (which are identical) with a single x86/x86/busdma_machdep.c.
2010-12-09 06:41:50 +00:00
x86/x86/busdma_machdep.c standard
Merge dump_machdep.c i386/amd64 under the x86 subtree. Sponsored by: Sandvine Incorporated Tested by: gianni
2010-10-26 12:46:26 +00:00
x86/x86/dump_machdep.c standard
Move the I/O APIC code to the x86 tree since it is identical on i386 and amd64.
2010-06-08 17:51:21 +00:00
x86/x86/io_apic.c standard
x86/x86/local_apic.c standard
Move the machine check support code to the x86 tree since it is identical on i386 and amd64. Requested by: alc
2010-06-08 18:04:07 +00:00
x86/x86/mca.c standard
Merge the mptable support from MD bits to x86 subtree. Sponsored by: Sandvine Incorporated Discussed with: jhb
2010-10-28 07:58:06 +00:00
x86/x86/mptable.c optional mptable
x86/x86/mptable_pci.c optional mptable pci
Move the MD support for PCI message signalled interrupts to the x86 tree as it is identical for i386 and amd64.
2010-06-08 18:36:03 +00:00
x86/x86/msi.c optional pci
Merge nexus.c from amd64 and i386 to x86 subtree. Sponsored by: Sandvine Incorporated Tested by: gianni
2010-10-28 16:31:39 +00:00
x86/x86/nexus.c standard
Merge sys/amd64/amd64/tsc.c and sys/i386/i386/tsc.c and move to sys/x86/x86. Discussed with: avg
2010-12-08 00:09:24 +00:00
x86/x86/tsc.c standard
Reference in New Issue Copy Permalink