Searched hist:5 (Results 126 - 150 of 11096) sorted by relevance
/freebsd-11.0-release/sys/dev/bxe/ | ||
H A D | ecore_init.h | diff 295830 Fri Feb 19 22:53:52 MST 2016 davidcs Remove dead code. Code Cleanup. Improve clarity in debug messages MFC after:5 days diff 292639 Wed Dec 23 03:29:52 MST 2015 davidcs Add support for firmware dump (a.k.a grcdump) MFC after:5 days diff 265411 Tue May 06 02:40:04 MDT 2014 davidcs Modify Copyright information to reflect Qlogic Corporation's purchase of Broadcom's NetXtreme business Submitted by:David C Somayajulu (davidcs@freebsd.org) QLogic Corporation MFC after:5 days |
H A D | ecore_reg.h | diff 284335 Sat Jun 13 01:33:45 MDT 2015 davidcs PHY LOCK acquires the hardware lock via bxe_acquire_phy_lock() and releases it via bxe_release_phy_lock(). It was simply acquiring a mutex earlier which can cause the PHY to use bogus values. Fixes intermittent link failures. bxe_ioctl() completes all functions within its context as opposed to a taskqueue earlier. bxe_handle_rx_mode_tq() no longer required. bxe_set_rx_mode() handles the functionality within its context Submitted by:gary.zambrano@qlogic.com MFC after:5 days diff 268854 Fri Jul 18 20:14:46 MDT 2014 davidcs Initiate error recovery stats fail to update after 3 retries. Change bxe_panic() ECORE_DBG_BREAK_IF() ECORE_BUG() ECORE_BUG_ON() to panic only if ECORE_STOP_ON_ERROR is defined. MFC after:5 days diff 265411 Tue May 06 02:40:04 MDT 2014 davidcs Modify Copyright information to reflect Qlogic Corporation's purchase of Broadcom's NetXtreme business Submitted by:David C Somayajulu (davidcs@freebsd.org) QLogic Corporation MFC after:5 days |
H A D | bxe_stats.h | diff 297873 Tue Apr 12 21:11:22 MDT 2016 davidcs 1. Process tx completions in bxe_periodic_callout_func() and restart transmissions if possible. 2. For SIOCSIFFLAGS call bxe_init_locked() only if !BXE_STATE_DISABLED 3. remove code not needed in bxe_init_internal_common() Submitted by:vaishali.kulkarni@qlogic.com;venkata.bhavaraju@qlogic.com Approved by:davidcs@freebsd.org MFC after:5 days diff 292638 Wed Dec 23 01:41:00 MST 2015 davidcs Check for packet_length is greater than 60 bytes as well as packet_length is greater than len_on_bd, before invoking the routine to handle jumbo over SGL (bxe_service_rxsgl()). Add counters for number of jumbo_over_SGL packets (rx_bxe_service_rxsgl) and erroneous jumbo_over_SGL packets (rx_erroneous_jumbo_sge_pkts) Fix formatting in bxe_sysctl_state() MFC after:5 days diff 283274 Fri May 22 01:49:37 MDT 2015 davidcs Add stat counters for Jumbo Frames using SGE ring. Also remove the checks for IFCAP_LRO in bxe_alloc_fp_buffers() and bxe_pf_rx_q_prep() since both TPA and Jumbo can use SGE ring. Submitted by:gary.zambrano@qlogic.com Approved by:davidcs@freebsd.org MFC after:5 days diff 265411 Tue May 06 02:40:04 MDT 2014 davidcs Modify Copyright information to reflect Qlogic Corporation's purchase of Broadcom's NetXtreme business Submitted by:David C Somayajulu (davidcs@freebsd.org) QLogic Corporation MFC after:5 days |
/freebsd-11.0-release/sys/geom/raid/ | ||
H A D | tr_raid5.c | diff 254275 Tue Aug 13 08:07:48 MDT 2013 mav Return error when opening read-only volumes (like RAID4/5/...) for writing. Previously opens succeeded, but actual write operations returned errors. Requested by: peter MFC after: 2 weeks diff 234993 Fri May 04 07:42:32 MDT 2012 mav Implement read-only support for volumes in optimal state (without using redundancy) for the following RAID levels: RAID4/5E/5EE/6/MDF. diff 234993 Fri May 04 07:42:32 MDT 2012 mav Implement read-only support for volumes in optimal state (without using redundancy) for the following RAID levels: RAID4/5E/5EE/6/MDF. |
/freebsd-11.0-release/sys/modules/bxe/ | ||
H A D | Makefile | diff 298591 Mon Apr 25 19:07:16 MDT 2016 davidcs 1. Removed -Wno-shift-negative-value from Makefile 2. Fixed warning its absence caused in bxe_elink.c MFC after:5 days diff 271726 Wed Sep 17 22:29:14 MDT 2014 davidcs Remove clean option MFC after:5 days diff 265411 Tue May 06 02:40:04 MDT 2014 davidcs Modify Copyright information to reflect Qlogic Corporation's purchase of Broadcom's NetXtreme business Submitted by:David C Somayajulu (davidcs@freebsd.org) QLogic Corporation MFC after:5 days |
/freebsd-11.0-release/lib/libc/posix1e/ | ||
H A D | mac.conf.5 | diff 113741 Sun Apr 20 04:43:56 MDT 2003 rwatson Add FILES section to mac.3 and mac.conf.5. Properly Xref mac.conf.5 from mac.3; likewise, mac.conf.5 from mac_prepare.3. Obtained from: TrustedBSD Project Sponsored by: DARPA, Network Associates Laboratories diff 113741 Sun Apr 20 04:43:56 MDT 2003 rwatson Add FILES section to mac.3 and mac.conf.5. Properly Xref mac.conf.5 from mac.3; likewise, mac.conf.5 from mac_prepare.3. Obtained from: TrustedBSD Project Sponsored by: DARPA, Network Associates Laboratories diff 113741 Sun Apr 20 04:43:56 MDT 2003 rwatson Add FILES section to mac.3 and mac.conf.5. Properly Xref mac.conf.5 from mac.3; likewise, mac.conf.5 from mac_prepare.3. Obtained from: TrustedBSD Project Sponsored by: DARPA, Network Associates Laboratories |
/freebsd-11.0-release/etc/defaults/ | ||
H A D | Makefile | diff 152286 Thu Nov 10 19:09:22 MST 2005 emax Start integrating Bluetooth into rc.d system. Introduce /etc/rc.d/bluetooth script to start/stop Bluetooth devices. It will be called from devd(8) in response to device arrival/departure events. It is also possible to call it by hand to start/stop particular device without unplugging it. Introduce generic way to set configuration parameters for Bluetooth devices. By default /etc/rc.d/bluetooth script has hardwired defaults compatible with old rc.bluetooth from /usr/share/netgraph/bluetooth/examples. These can be overridden using /etc/defaults/bluetooth.device.conf file (system wide defaults). Finally, there could be another device specific override file located in /etc/bluetooth/$device.conf (where $device is ubt0, btccc0 etc.) The list of configuration parameters and their meaning described in the /etc/defaults/bluetooth.device.conf file. Even though Bluetooth device configuration files are not shell scripts, they must follow basic sh(1) syntax. The bluetooth.device.conf(5) and handbook update will follow shortly. Inspired by: Panagiotis Astithas ( past at ebs dot gr ) Reviewed by: brooks, yar MFC after: 1 week diff 119166 Wed Aug 20 06:15:18 MDT 2003 mtm Add a general mechanism for creating and applying devfs(8) rules in rc(8). It is most useful for applying rules to devfs(5) mount points in /dev or inside jails. The following line of script is sufficient to mount a relatively useful+secure devfs(5) in a jail: devfs_mount_jail /some/jail/dev Some new shell routines available to scripts that source rc.subr(5): o devfs_link - Makes it a little easier to create symlinks o devfs_init_rulesets - Create devfs(8) rulesets from devfs.rules o devfs_set_ruleset - Set a ruleset to a devfs(5) mount o devfs_apply_ruleset - Apply a ruleset to a devfs(5) mount o devfs_domount - Mount devfs(5) and apply some ruleset o devfs_mount_jail - Mount devfs(5) and apply a ruleset appropriate to jails. Additional rulesets can be specified in /etc/devfs.rules. If the devfs_system_ruleset variable is defined in rc.conf and it contains the name of a ruleset defined in /etc/defaults/devfs.rules or user supplied rulesets in /etc/devfs.rules then that ruleset will be applied to /dev at startup by the /etc/rc.d/devfs script. It can also be applied post-startup: /etc/rc.d/devfs start This is a more flexible mechanism than the previous method of using /etc/devfs.conf. However, that method is still available. Note: since devfs(8) doesn't provide any way for creating symlinks as part of a ruleset, anyone wishing to create symlinks in a devfs(5) as part of the bootup sequence will still have to rely on /etc/devfs.conf. diff 119166 Wed Aug 20 06:15:18 MDT 2003 mtm Add a general mechanism for creating and applying devfs(8) rules in rc(8). It is most useful for applying rules to devfs(5) mount points in /dev or inside jails. The following line of script is sufficient to mount a relatively useful+secure devfs(5) in a jail: devfs_mount_jail /some/jail/dev Some new shell routines available to scripts that source rc.subr(5): o devfs_link - Makes it a little easier to create symlinks o devfs_init_rulesets - Create devfs(8) rulesets from devfs.rules o devfs_set_ruleset - Set a ruleset to a devfs(5) mount o devfs_apply_ruleset - Apply a ruleset to a devfs(5) mount o devfs_domount - Mount devfs(5) and apply some ruleset o devfs_mount_jail - Mount devfs(5) and apply a ruleset appropriate to jails. Additional rulesets can be specified in /etc/devfs.rules. If the devfs_system_ruleset variable is defined in rc.conf and it contains the name of a ruleset defined in /etc/defaults/devfs.rules or user supplied rulesets in /etc/devfs.rules then that ruleset will be applied to /dev at startup by the /etc/rc.d/devfs script. It can also be applied post-startup: /etc/rc.d/devfs start This is a more flexible mechanism than the previous method of using /etc/devfs.conf. However, that method is still available. Note: since devfs(8) doesn't provide any way for creating symlinks as part of a ruleset, anyone wishing to create symlinks in a devfs(5) as part of the bootup sequence will still have to rely on /etc/devfs.conf. diff 119166 Wed Aug 20 06:15:18 MDT 2003 mtm Add a general mechanism for creating and applying devfs(8) rules in rc(8). It is most useful for applying rules to devfs(5) mount points in /dev or inside jails. The following line of script is sufficient to mount a relatively useful+secure devfs(5) in a jail: devfs_mount_jail /some/jail/dev Some new shell routines available to scripts that source rc.subr(5): o devfs_link - Makes it a little easier to create symlinks o devfs_init_rulesets - Create devfs(8) rulesets from devfs.rules o devfs_set_ruleset - Set a ruleset to a devfs(5) mount o devfs_apply_ruleset - Apply a ruleset to a devfs(5) mount o devfs_domount - Mount devfs(5) and apply some ruleset o devfs_mount_jail - Mount devfs(5) and apply a ruleset appropriate to jails. Additional rulesets can be specified in /etc/devfs.rules. If the devfs_system_ruleset variable is defined in rc.conf and it contains the name of a ruleset defined in /etc/defaults/devfs.rules or user supplied rulesets in /etc/devfs.rules then that ruleset will be applied to /dev at startup by the /etc/rc.d/devfs script. It can also be applied post-startup: /etc/rc.d/devfs start This is a more flexible mechanism than the previous method of using /etc/devfs.conf. However, that method is still available. Note: since devfs(8) doesn't provide any way for creating symlinks as part of a ruleset, anyone wishing to create symlinks in a devfs(5) as part of the bootup sequence will still have to rely on /etc/devfs.conf. diff 119166 Wed Aug 20 06:15:18 MDT 2003 mtm Add a general mechanism for creating and applying devfs(8) rules in rc(8). It is most useful for applying rules to devfs(5) mount points in /dev or inside jails. The following line of script is sufficient to mount a relatively useful+secure devfs(5) in a jail: devfs_mount_jail /some/jail/dev Some new shell routines available to scripts that source rc.subr(5): o devfs_link - Makes it a little easier to create symlinks o devfs_init_rulesets - Create devfs(8) rulesets from devfs.rules o devfs_set_ruleset - Set a ruleset to a devfs(5) mount o devfs_apply_ruleset - Apply a ruleset to a devfs(5) mount o devfs_domount - Mount devfs(5) and apply some ruleset o devfs_mount_jail - Mount devfs(5) and apply a ruleset appropriate to jails. Additional rulesets can be specified in /etc/devfs.rules. If the devfs_system_ruleset variable is defined in rc.conf and it contains the name of a ruleset defined in /etc/defaults/devfs.rules or user supplied rulesets in /etc/devfs.rules then that ruleset will be applied to /dev at startup by the /etc/rc.d/devfs script. It can also be applied post-startup: /etc/rc.d/devfs start This is a more flexible mechanism than the previous method of using /etc/devfs.conf. However, that method is still available. Note: since devfs(8) doesn't provide any way for creating symlinks as part of a ruleset, anyone wishing to create symlinks in a devfs(5) as part of the bootup sequence will still have to rely on /etc/devfs.conf. diff 119166 Wed Aug 20 06:15:18 MDT 2003 mtm Add a general mechanism for creating and applying devfs(8) rules in rc(8). It is most useful for applying rules to devfs(5) mount points in /dev or inside jails. The following line of script is sufficient to mount a relatively useful+secure devfs(5) in a jail: devfs_mount_jail /some/jail/dev Some new shell routines available to scripts that source rc.subr(5): o devfs_link - Makes it a little easier to create symlinks o devfs_init_rulesets - Create devfs(8) rulesets from devfs.rules o devfs_set_ruleset - Set a ruleset to a devfs(5) mount o devfs_apply_ruleset - Apply a ruleset to a devfs(5) mount o devfs_domount - Mount devfs(5) and apply some ruleset o devfs_mount_jail - Mount devfs(5) and apply a ruleset appropriate to jails. Additional rulesets can be specified in /etc/devfs.rules. If the devfs_system_ruleset variable is defined in rc.conf and it contains the name of a ruleset defined in /etc/defaults/devfs.rules or user supplied rulesets in /etc/devfs.rules then that ruleset will be applied to /dev at startup by the /etc/rc.d/devfs script. It can also be applied post-startup: /etc/rc.d/devfs start This is a more flexible mechanism than the previous method of using /etc/devfs.conf. However, that method is still available. Note: since devfs(8) doesn't provide any way for creating symlinks as part of a ruleset, anyone wishing to create symlinks in a devfs(5) as part of the bootup sequence will still have to rely on /etc/devfs.conf. diff 119166 Wed Aug 20 06:15:18 MDT 2003 mtm Add a general mechanism for creating and applying devfs(8) rules in rc(8). It is most useful for applying rules to devfs(5) mount points in /dev or inside jails. The following line of script is sufficient to mount a relatively useful+secure devfs(5) in a jail: devfs_mount_jail /some/jail/dev Some new shell routines available to scripts that source rc.subr(5): o devfs_link - Makes it a little easier to create symlinks o devfs_init_rulesets - Create devfs(8) rulesets from devfs.rules o devfs_set_ruleset - Set a ruleset to a devfs(5) mount o devfs_apply_ruleset - Apply a ruleset to a devfs(5) mount o devfs_domount - Mount devfs(5) and apply some ruleset o devfs_mount_jail - Mount devfs(5) and apply a ruleset appropriate to jails. Additional rulesets can be specified in /etc/devfs.rules. If the devfs_system_ruleset variable is defined in rc.conf and it contains the name of a ruleset defined in /etc/defaults/devfs.rules or user supplied rulesets in /etc/devfs.rules then that ruleset will be applied to /dev at startup by the /etc/rc.d/devfs script. It can also be applied post-startup: /etc/rc.d/devfs start This is a more flexible mechanism than the previous method of using /etc/devfs.conf. However, that method is still available. Note: since devfs(8) doesn't provide any way for creating symlinks as part of a ruleset, anyone wishing to create symlinks in a devfs(5) as part of the bootup sequence will still have to rely on /etc/devfs.conf. diff 119166 Wed Aug 20 06:15:18 MDT 2003 mtm Add a general mechanism for creating and applying devfs(8) rules in rc(8). It is most useful for applying rules to devfs(5) mount points in /dev or inside jails. The following line of script is sufficient to mount a relatively useful+secure devfs(5) in a jail: devfs_mount_jail /some/jail/dev Some new shell routines available to scripts that source rc.subr(5): o devfs_link - Makes it a little easier to create symlinks o devfs_init_rulesets - Create devfs(8) rulesets from devfs.rules o devfs_set_ruleset - Set a ruleset to a devfs(5) mount o devfs_apply_ruleset - Apply a ruleset to a devfs(5) mount o devfs_domount - Mount devfs(5) and apply some ruleset o devfs_mount_jail - Mount devfs(5) and apply a ruleset appropriate to jails. Additional rulesets can be specified in /etc/devfs.rules. If the devfs_system_ruleset variable is defined in rc.conf and it contains the name of a ruleset defined in /etc/defaults/devfs.rules or user supplied rulesets in /etc/devfs.rules then that ruleset will be applied to /dev at startup by the /etc/rc.d/devfs script. It can also be applied post-startup: /etc/rc.d/devfs start This is a more flexible mechanism than the previous method of using /etc/devfs.conf. However, that method is still available. Note: since devfs(8) doesn't provide any way for creating symlinks as part of a ruleset, anyone wishing to create symlinks in a devfs(5) as part of the bootup sequence will still have to rely on /etc/devfs.conf. diff 119166 Wed Aug 20 06:15:18 MDT 2003 mtm Add a general mechanism for creating and applying devfs(8) rules in rc(8). It is most useful for applying rules to devfs(5) mount points in /dev or inside jails. The following line of script is sufficient to mount a relatively useful+secure devfs(5) in a jail: devfs_mount_jail /some/jail/dev Some new shell routines available to scripts that source rc.subr(5): o devfs_link - Makes it a little easier to create symlinks o devfs_init_rulesets - Create devfs(8) rulesets from devfs.rules o devfs_set_ruleset - Set a ruleset to a devfs(5) mount o devfs_apply_ruleset - Apply a ruleset to a devfs(5) mount o devfs_domount - Mount devfs(5) and apply some ruleset o devfs_mount_jail - Mount devfs(5) and apply a ruleset appropriate to jails. Additional rulesets can be specified in /etc/devfs.rules. If the devfs_system_ruleset variable is defined in rc.conf and it contains the name of a ruleset defined in /etc/defaults/devfs.rules or user supplied rulesets in /etc/devfs.rules then that ruleset will be applied to /dev at startup by the /etc/rc.d/devfs script. It can also be applied post-startup: /etc/rc.d/devfs start This is a more flexible mechanism than the previous method of using /etc/devfs.conf. However, that method is still available. Note: since devfs(8) doesn't provide any way for creating symlinks as part of a ruleset, anyone wishing to create symlinks in a devfs(5) as part of the bootup sequence will still have to rely on /etc/devfs.conf. |
/freebsd-11.0-release/sys/dev/ath/ath_hal/ar9002/ | ||
H A D | ar9002phy.h | 219393 Tue Mar 08 07:10:35 MST 2011 adrian Implement open-loop TX power control (OLC) for Merlin (AR9280) and generally tidy up the TX power programming code. Enforce that the TX power offset for Merlin is -5 dBm, rather than any other value programmable in the EEPROM. This requires some further code to be ported over from ath9k, so until that is done and tested, fail to attach NICs whose TX power offset isn't -5 dBm. This improves both legacy and HT transmission on my merlin board. It allows for stable MCS TX up to MCS15. Specifics: * Refactor out a bunch of the TX power calibration code - setting/obtaining the power detector / gain boundaries, programming the PDADC * Take the -5 dBm TX power offset into account on Merlin - "0" in the per-rate TX power register means -5 dBm, not 0 dBm * When doing OLC * Enforce min (0) and max (AR5416_MAX_RATE_POWER) when fiddling with the TX power, to avoid the TX power values from wrapping when low. * Implement the 1 dBm cck power offset when doing OLC * Implement temperature compensation for 2.4ghz mode when doing OLC * Implement an AR9280 specific TX power calibration routine which includes the OLC twiddles, leaving the earlier chipset path (AR5416, AR9160) alone Whilst here, use these refactored routines for the AR9285 TX power calibration/programming code and enforce correct overflow/underflow handling when fiddling with TX power values. Obtained from: linux ath9k 219393 Tue Mar 08 07:10:35 MST 2011 adrian Implement open-loop TX power control (OLC) for Merlin (AR9280) and generally tidy up the TX power programming code. Enforce that the TX power offset for Merlin is -5 dBm, rather than any other value programmable in the EEPROM. This requires some further code to be ported over from ath9k, so until that is done and tested, fail to attach NICs whose TX power offset isn't -5 dBm. This improves both legacy and HT transmission on my merlin board. It allows for stable MCS TX up to MCS15. Specifics: * Refactor out a bunch of the TX power calibration code - setting/obtaining the power detector / gain boundaries, programming the PDADC * Take the -5 dBm TX power offset into account on Merlin - "0" in the per-rate TX power register means -5 dBm, not 0 dBm * When doing OLC * Enforce min (0) and max (AR5416_MAX_RATE_POWER) when fiddling with the TX power, to avoid the TX power values from wrapping when low. * Implement the 1 dBm cck power offset when doing OLC * Implement temperature compensation for 2.4ghz mode when doing OLC * Implement an AR9280 specific TX power calibration routine which includes the OLC twiddles, leaving the earlier chipset path (AR5416, AR9160) alone Whilst here, use these refactored routines for the AR9285 TX power calibration/programming code and enforce correct overflow/underflow handling when fiddling with TX power values. Obtained from: linux ath9k 219393 Tue Mar 08 07:10:35 MST 2011 adrian Implement open-loop TX power control (OLC) for Merlin (AR9280) and generally tidy up the TX power programming code. Enforce that the TX power offset for Merlin is -5 dBm, rather than any other value programmable in the EEPROM. This requires some further code to be ported over from ath9k, so until that is done and tested, fail to attach NICs whose TX power offset isn't -5 dBm. This improves both legacy and HT transmission on my merlin board. It allows for stable MCS TX up to MCS15. Specifics: * Refactor out a bunch of the TX power calibration code - setting/obtaining the power detector / gain boundaries, programming the PDADC * Take the -5 dBm TX power offset into account on Merlin - "0" in the per-rate TX power register means -5 dBm, not 0 dBm * When doing OLC * Enforce min (0) and max (AR5416_MAX_RATE_POWER) when fiddling with the TX power, to avoid the TX power values from wrapping when low. * Implement the 1 dBm cck power offset when doing OLC * Implement temperature compensation for 2.4ghz mode when doing OLC * Implement an AR9280 specific TX power calibration routine which includes the OLC twiddles, leaving the earlier chipset path (AR5416, AR9160) alone Whilst here, use these refactored routines for the AR9285 TX power calibration/programming code and enforce correct overflow/underflow handling when fiddling with TX power values. Obtained from: linux ath9k 219393 Tue Mar 08 07:10:35 MST 2011 adrian Implement open-loop TX power control (OLC) for Merlin (AR9280) and generally tidy up the TX power programming code. Enforce that the TX power offset for Merlin is -5 dBm, rather than any other value programmable in the EEPROM. This requires some further code to be ported over from ath9k, so until that is done and tested, fail to attach NICs whose TX power offset isn't -5 dBm. This improves both legacy and HT transmission on my merlin board. It allows for stable MCS TX up to MCS15. Specifics: * Refactor out a bunch of the TX power calibration code - setting/obtaining the power detector / gain boundaries, programming the PDADC * Take the -5 dBm TX power offset into account on Merlin - "0" in the per-rate TX power register means -5 dBm, not 0 dBm * When doing OLC * Enforce min (0) and max (AR5416_MAX_RATE_POWER) when fiddling with the TX power, to avoid the TX power values from wrapping when low. * Implement the 1 dBm cck power offset when doing OLC * Implement temperature compensation for 2.4ghz mode when doing OLC * Implement an AR9280 specific TX power calibration routine which includes the OLC twiddles, leaving the earlier chipset path (AR5416, AR9160) alone Whilst here, use these refactored routines for the AR9285 TX power calibration/programming code and enforce correct overflow/underflow handling when fiddling with TX power values. Obtained from: linux ath9k |
/freebsd-11.0-release/sys/dev/bwn/ | ||
H A D | if_bwnvar.h | diff 300114 Wed May 18 06:05:16 MDT 2016 adrian [bwn] add initial 5xx firmware API support * Add the new TX/RX frame formats; * Use the right TX/RX format based on the frame info; * Disable the 5xx firmware check, since now it should somewhat work (but note, we don't yet use it unless you manually add ucode11/initvals11 from the 5.x driver to bwn-kmod-firmware; * Misc: update some comments/debugging now I know what's actually going on. Tested: * BCM4321MC, STA mode, both 4xx and 666 firmware, DMA mode TODO: * The newer firmware ends up logging "warn: firmware state (0)"; not sure yet what's going on there. But, yes, it still works. I'm committing this via a BCM4321MC, 11a station, firmware rev 666. Obtained from: Linux b43 (TX/RX descriptor format for 5xx) diff 300114 Wed May 18 06:05:16 MDT 2016 adrian [bwn] add initial 5xx firmware API support * Add the new TX/RX frame formats; * Use the right TX/RX format based on the frame info; * Disable the 5xx firmware check, since now it should somewhat work (but note, we don't yet use it unless you manually add ucode11/initvals11 from the 5.x driver to bwn-kmod-firmware; * Misc: update some comments/debugging now I know what's actually going on. Tested: * BCM4321MC, STA mode, both 4xx and 666 firmware, DMA mode TODO: * The newer firmware ends up logging "warn: firmware state (0)"; not sure yet what's going on there. But, yes, it still works. I'm committing this via a BCM4321MC, 11a station, firmware rev 666. Obtained from: Linux b43 (TX/RX descriptor format for 5xx) diff 300114 Wed May 18 06:05:16 MDT 2016 adrian [bwn] add initial 5xx firmware API support * Add the new TX/RX frame formats; * Use the right TX/RX format based on the frame info; * Disable the 5xx firmware check, since now it should somewhat work (but note, we don't yet use it unless you manually add ucode11/initvals11 from the 5.x driver to bwn-kmod-firmware; * Misc: update some comments/debugging now I know what's actually going on. Tested: * BCM4321MC, STA mode, both 4xx and 666 firmware, DMA mode TODO: * The newer firmware ends up logging "warn: firmware state (0)"; not sure yet what's going on there. But, yes, it still works. I'm committing this via a BCM4321MC, 11a station, firmware rev 666. Obtained from: Linux b43 (TX/RX descriptor format for 5xx) diff 300114 Wed May 18 06:05:16 MDT 2016 adrian [bwn] add initial 5xx firmware API support * Add the new TX/RX frame formats; * Use the right TX/RX format based on the frame info; * Disable the 5xx firmware check, since now it should somewhat work (but note, we don't yet use it unless you manually add ucode11/initvals11 from the 5.x driver to bwn-kmod-firmware; * Misc: update some comments/debugging now I know what's actually going on. Tested: * BCM4321MC, STA mode, both 4xx and 666 firmware, DMA mode TODO: * The newer firmware ends up logging "warn: firmware state (0)"; not sure yet what's going on there. But, yes, it still works. I'm committing this via a BCM4321MC, 11a station, firmware rev 666. Obtained from: Linux b43 (TX/RX descriptor format for 5xx) diff 299790 Sat May 14 23:52:44 MDT 2016 adrian [bwn] add new types, prepare for PHY-N; prepare for rev 5xx firmware. This is a big commit with a whole lot of little changes, all in preparation for PHY-N and rev 5xx firmware. * add in a write method that does an explicit flush * change the txpwr recalc type to return an enum, versus just an int. * add in PHY-N RX frame format bits, for decoding RX RSSI and such * add in the header space calculation for rev 5xx firmware. * add in a whole bunch of new types that the newer and 5g phy code needs. Notably, broadcom has a split 5GHz band concept - 5G-Low, 5G(-Mid) and 5G-High. I kept encountering this at my day job and wondered whether it was just some marketing thing. Nope, turns out it isn't; it's an actual PHY thing. * Add a "am I a siba bus device" method, that returns true. The aim is to convert all the siba/bhnd specific bits in if_bwn over to be wrapped in this check, so when landon does a BHND drive through he knows which bits need updating. Now, this the /complete/ set of changes for rev 5xx firmware. Notably, the TX descriptor handling isn't at all done yet and the format has changed. So don' try blindly flipping this on just yet! diff 299790 Sat May 14 23:52:44 MDT 2016 adrian [bwn] add new types, prepare for PHY-N; prepare for rev 5xx firmware. This is a big commit with a whole lot of little changes, all in preparation for PHY-N and rev 5xx firmware. * add in a write method that does an explicit flush * change the txpwr recalc type to return an enum, versus just an int. * add in PHY-N RX frame format bits, for decoding RX RSSI and such * add in the header space calculation for rev 5xx firmware. * add in a whole bunch of new types that the newer and 5g phy code needs. Notably, broadcom has a split 5GHz band concept - 5G-Low, 5G(-Mid) and 5G-High. I kept encountering this at my day job and wondered whether it was just some marketing thing. Nope, turns out it isn't; it's an actual PHY thing. * Add a "am I a siba bus device" method, that returns true. The aim is to convert all the siba/bhnd specific bits in if_bwn over to be wrapped in this check, so when landon does a BHND drive through he knows which bits need updating. Now, this the /complete/ set of changes for rev 5xx firmware. Notably, the TX descriptor handling isn't at all done yet and the format has changed. So don' try blindly flipping this on just yet! diff 299790 Sat May 14 23:52:44 MDT 2016 adrian [bwn] add new types, prepare for PHY-N; prepare for rev 5xx firmware. This is a big commit with a whole lot of little changes, all in preparation for PHY-N and rev 5xx firmware. * add in a write method that does an explicit flush * change the txpwr recalc type to return an enum, versus just an int. * add in PHY-N RX frame format bits, for decoding RX RSSI and such * add in the header space calculation for rev 5xx firmware. * add in a whole bunch of new types that the newer and 5g phy code needs. Notably, broadcom has a split 5GHz band concept - 5G-Low, 5G(-Mid) and 5G-High. I kept encountering this at my day job and wondered whether it was just some marketing thing. Nope, turns out it isn't; it's an actual PHY thing. * Add a "am I a siba bus device" method, that returns true. The aim is to convert all the siba/bhnd specific bits in if_bwn over to be wrapped in this check, so when landon does a BHND drive through he knows which bits need updating. Now, this the /complete/ set of changes for rev 5xx firmware. Notably, the TX descriptor handling isn't at all done yet and the format has changed. So don' try blindly flipping this on just yet! diff 299790 Sat May 14 23:52:44 MDT 2016 adrian [bwn] add new types, prepare for PHY-N; prepare for rev 5xx firmware. This is a big commit with a whole lot of little changes, all in preparation for PHY-N and rev 5xx firmware. * add in a write method that does an explicit flush * change the txpwr recalc type to return an enum, versus just an int. * add in PHY-N RX frame format bits, for decoding RX RSSI and such * add in the header space calculation for rev 5xx firmware. * add in a whole bunch of new types that the newer and 5g phy code needs. Notably, broadcom has a split 5GHz band concept - 5G-Low, 5G(-Mid) and 5G-High. I kept encountering this at my day job and wondered whether it was just some marketing thing. Nope, turns out it isn't; it's an actual PHY thing. * Add a "am I a siba bus device" method, that returns true. The aim is to convert all the siba/bhnd specific bits in if_bwn over to be wrapped in this check, so when landon does a BHND drive through he knows which bits need updating. Now, this the /complete/ set of changes for rev 5xx firmware. Notably, the TX descriptor handling isn't at all done yet and the format has changed. So don' try blindly flipping this on just yet! diff 299790 Sat May 14 23:52:44 MDT 2016 adrian [bwn] add new types, prepare for PHY-N; prepare for rev 5xx firmware. This is a big commit with a whole lot of little changes, all in preparation for PHY-N and rev 5xx firmware. * add in a write method that does an explicit flush * change the txpwr recalc type to return an enum, versus just an int. * add in PHY-N RX frame format bits, for decoding RX RSSI and such * add in the header space calculation for rev 5xx firmware. * add in a whole bunch of new types that the newer and 5g phy code needs. Notably, broadcom has a split 5GHz band concept - 5G-Low, 5G(-Mid) and 5G-High. I kept encountering this at my day job and wondered whether it was just some marketing thing. Nope, turns out it isn't; it's an actual PHY thing. * Add a "am I a siba bus device" method, that returns true. The aim is to convert all the siba/bhnd specific bits in if_bwn over to be wrapped in this check, so when landon does a BHND drive through he knows which bits need updating. Now, this the /complete/ set of changes for rev 5xx firmware. Notably, the TX descriptor handling isn't at all done yet and the format has changed. So don' try blindly flipping this on just yet! diff 299790 Sat May 14 23:52:44 MDT 2016 adrian [bwn] add new types, prepare for PHY-N; prepare for rev 5xx firmware. This is a big commit with a whole lot of little changes, all in preparation for PHY-N and rev 5xx firmware. * add in a write method that does an explicit flush * change the txpwr recalc type to return an enum, versus just an int. * add in PHY-N RX frame format bits, for decoding RX RSSI and such * add in the header space calculation for rev 5xx firmware. * add in a whole bunch of new types that the newer and 5g phy code needs. Notably, broadcom has a split 5GHz band concept - 5G-Low, 5G(-Mid) and 5G-High. I kept encountering this at my day job and wondered whether it was just some marketing thing. Nope, turns out it isn't; it's an actual PHY thing. * Add a "am I a siba bus device" method, that returns true. The aim is to convert all the siba/bhnd specific bits in if_bwn over to be wrapped in this check, so when landon does a BHND drive through he knows which bits need updating. Now, this the /complete/ set of changes for rev 5xx firmware. Notably, the TX descriptor handling isn't at all done yet and the format has changed. So don' try blindly flipping this on just yet! diff 299790 Sat May 14 23:52:44 MDT 2016 adrian [bwn] add new types, prepare for PHY-N; prepare for rev 5xx firmware. This is a big commit with a whole lot of little changes, all in preparation for PHY-N and rev 5xx firmware. * add in a write method that does an explicit flush * change the txpwr recalc type to return an enum, versus just an int. * add in PHY-N RX frame format bits, for decoding RX RSSI and such * add in the header space calculation for rev 5xx firmware. * add in a whole bunch of new types that the newer and 5g phy code needs. Notably, broadcom has a split 5GHz band concept - 5G-Low, 5G(-Mid) and 5G-High. I kept encountering this at my day job and wondered whether it was just some marketing thing. Nope, turns out it isn't; it's an actual PHY thing. * Add a "am I a siba bus device" method, that returns true. The aim is to convert all the siba/bhnd specific bits in if_bwn over to be wrapped in this check, so when landon does a BHND drive through he knows which bits need updating. Now, this the /complete/ set of changes for rev 5xx firmware. Notably, the TX descriptor handling isn't at all done yet and the format has changed. So don' try blindly flipping this on just yet! diff 299790 Sat May 14 23:52:44 MDT 2016 adrian [bwn] add new types, prepare for PHY-N; prepare for rev 5xx firmware. This is a big commit with a whole lot of little changes, all in preparation for PHY-N and rev 5xx firmware. * add in a write method that does an explicit flush * change the txpwr recalc type to return an enum, versus just an int. * add in PHY-N RX frame format bits, for decoding RX RSSI and such * add in the header space calculation for rev 5xx firmware. * add in a whole bunch of new types that the newer and 5g phy code needs. Notably, broadcom has a split 5GHz band concept - 5G-Low, 5G(-Mid) and 5G-High. I kept encountering this at my day job and wondered whether it was just some marketing thing. Nope, turns out it isn't; it's an actual PHY thing. * Add a "am I a siba bus device" method, that returns true. The aim is to convert all the siba/bhnd specific bits in if_bwn over to be wrapped in this check, so when landon does a BHND drive through he knows which bits need updating. Now, this the /complete/ set of changes for rev 5xx firmware. Notably, the TX descriptor handling isn't at all done yet and the format has changed. So don' try blindly flipping this on just yet! diff 299790 Sat May 14 23:52:44 MDT 2016 adrian [bwn] add new types, prepare for PHY-N; prepare for rev 5xx firmware. This is a big commit with a whole lot of little changes, all in preparation for PHY-N and rev 5xx firmware. * add in a write method that does an explicit flush * change the txpwr recalc type to return an enum, versus just an int. * add in PHY-N RX frame format bits, for decoding RX RSSI and such * add in the header space calculation for rev 5xx firmware. * add in a whole bunch of new types that the newer and 5g phy code needs. Notably, broadcom has a split 5GHz band concept - 5G-Low, 5G(-Mid) and 5G-High. I kept encountering this at my day job and wondered whether it was just some marketing thing. Nope, turns out it isn't; it's an actual PHY thing. * Add a "am I a siba bus device" method, that returns true. The aim is to convert all the siba/bhnd specific bits in if_bwn over to be wrapped in this check, so when landon does a BHND drive through he knows which bits need updating. Now, this the /complete/ set of changes for rev 5xx firmware. Notably, the TX descriptor handling isn't at all done yet and the format has changed. So don' try blindly flipping this on just yet! |
/freebsd-11.0-release/sys/boot/forth/ | ||
H A D | check-password.4th.8 | diff 281616 Thu Apr 16 20:54:11 MDT 2015 dteske Add "GELI Passphrase:" prompt to boot loader. A new loader.conf(5) option of geom_eli_passphrase_prompt="YES" will now allow you to enter your geli(8) root-mount credentials prior to invoking the kernel. See check-password.4th(8) for details. Differential Revision: https://reviews.freebsd.org/D2105 Reviewed by: imp, kmoore Discussed on: -current MFC after: 3 days X-MFC-to: stable/10 Relnotes: yes diff 280938 Wed Apr 01 02:03:27 MDT 2015 dteske Add "GELI Passphrase:" prompt to boot loader. Summary: Add "GELI Passphrase:" prompt to boot loader. A new loader.conf(5) option of geom_eli_passphrase_prompt="YES" will now allow you to enter your geli(8) root-mount credentials prior to invoking the kernel. See check-password.4th(8) for details. Differential Revision: https://reviews.freebsd.org/D2105 Reviewed by: (your name[s] here) MFC after: 3 days X-MFC-to: stable/10 Relnotes: yes Test Plan: Drop a head copy of check-password.4th into /boot and then apply the patch (only the patch to /boot/check-password.4th is required; no other changes are required but you do have to have a HEAD copy of check-password.4th to apply the patch). NB: The rest of your /boot files can be up to 2 years old but no older. NB: The test won't work unless your kernel has the following change https://svnweb.freebsd.org/base?view=revision&revision=273489 Now, put into /boot/loader.conf: geom_eli_passphrase_prompt="YES" and reboot. You should be prompted for a GELI passphrase before the menu (if enabled), just after loading loader.conf(5). NB: It doesn't matter if you're using GELI or not. However if you are using GELI and a sufficiently new enough release (has SVN r273489) and you entered the proper passphrase to mount your GELI encrypted root device(s), you should notice that the boot process did not stop (you went from loader all the way to login). Reviewers: cperciva, allanjude, scottl, kmoore Subscribers: jkh, imp Differential Revision: https://reviews.freebsd.org/D2105 diff 280938 Wed Apr 01 02:03:27 MDT 2015 dteske Add "GELI Passphrase:" prompt to boot loader. Summary: Add "GELI Passphrase:" prompt to boot loader. A new loader.conf(5) option of geom_eli_passphrase_prompt="YES" will now allow you to enter your geli(8) root-mount credentials prior to invoking the kernel. See check-password.4th(8) for details. Differential Revision: https://reviews.freebsd.org/D2105 Reviewed by: (your name[s] here) MFC after: 3 days X-MFC-to: stable/10 Relnotes: yes Test Plan: Drop a head copy of check-password.4th into /boot and then apply the patch (only the patch to /boot/check-password.4th is required; no other changes are required but you do have to have a HEAD copy of check-password.4th to apply the patch). NB: The rest of your /boot files can be up to 2 years old but no older. NB: The test won't work unless your kernel has the following change https://svnweb.freebsd.org/base?view=revision&revision=273489 Now, put into /boot/loader.conf: geom_eli_passphrase_prompt="YES" and reboot. You should be prompted for a GELI passphrase before the menu (if enabled), just after loading loader.conf(5). NB: It doesn't matter if you're using GELI or not. However if you are using GELI and a sufficiently new enough release (has SVN r273489) and you entered the proper passphrase to mount your GELI encrypted root device(s), you should notice that the boot process did not stop (you went from loader all the way to login). Reviewers: cperciva, allanjude, scottl, kmoore Subscribers: jkh, imp Differential Revision: https://reviews.freebsd.org/D2105 diff 244158 Wed Dec 12 17:57:56 MST 2012 dteske Fix a regression caused by SVN r222417. Prior to r222417, setting `password' in loader.conf(5) did not prevent boot but instead only prevented changes to boot options by prompting for password if autoboot failed or the user interrupted the countdown sequence. After r222417 the same machine with `password' set in loader.conf(5) would no longer boot without _always_ entering the password. This patch restores the old (8.x and older) functionality for password in loader.conf(5) while adding a new bootlock_password feature to replace the edge-case should anybody desire the regressed functionality (HINT: great for PXE servers and/or private distributions). loader.conf(5) was updated to be more clear with-respect to password setting (previous text was misleading). Documentation (loader.conf(5) and check-password.4th(8)) has been updated to include notes on the new bootlock_password setting. Special thanks to Alex Verbod for bringing this to my attention and helping to refine the loader.conf(5) text. PR: conf/170110 Submitted by: Vitaly Zakharov <ded3axap@gmail.com> Reviewed by: Alexander Verbod <alexander.verbod@gmail.com> diff 244158 Wed Dec 12 17:57:56 MST 2012 dteske Fix a regression caused by SVN r222417. Prior to r222417, setting `password' in loader.conf(5) did not prevent boot but instead only prevented changes to boot options by prompting for password if autoboot failed or the user interrupted the countdown sequence. After r222417 the same machine with `password' set in loader.conf(5) would no longer boot without _always_ entering the password. This patch restores the old (8.x and older) functionality for password in loader.conf(5) while adding a new bootlock_password feature to replace the edge-case should anybody desire the regressed functionality (HINT: great for PXE servers and/or private distributions). loader.conf(5) was updated to be more clear with-respect to password setting (previous text was misleading). Documentation (loader.conf(5) and check-password.4th(8)) has been updated to include notes on the new bootlock_password setting. Special thanks to Alex Verbod for bringing this to my attention and helping to refine the loader.conf(5) text. PR: conf/170110 Submitted by: Vitaly Zakharov <ded3axap@gmail.com> Reviewed by: Alexander Verbod <alexander.verbod@gmail.com> diff 244158 Wed Dec 12 17:57:56 MST 2012 dteske Fix a regression caused by SVN r222417. Prior to r222417, setting `password' in loader.conf(5) did not prevent boot but instead only prevented changes to boot options by prompting for password if autoboot failed or the user interrupted the countdown sequence. After r222417 the same machine with `password' set in loader.conf(5) would no longer boot without _always_ entering the password. This patch restores the old (8.x and older) functionality for password in loader.conf(5) while adding a new bootlock_password feature to replace the edge-case should anybody desire the regressed functionality (HINT: great for PXE servers and/or private distributions). loader.conf(5) was updated to be more clear with-respect to password setting (previous text was misleading). Documentation (loader.conf(5) and check-password.4th(8)) has been updated to include notes on the new bootlock_password setting. Special thanks to Alex Verbod for bringing this to my attention and helping to refine the loader.conf(5) text. PR: conf/170110 Submitted by: Vitaly Zakharov <ded3axap@gmail.com> Reviewed by: Alexander Verbod <alexander.verbod@gmail.com> diff 244158 Wed Dec 12 17:57:56 MST 2012 dteske Fix a regression caused by SVN r222417. Prior to r222417, setting `password' in loader.conf(5) did not prevent boot but instead only prevented changes to boot options by prompting for password if autoboot failed or the user interrupted the countdown sequence. After r222417 the same machine with `password' set in loader.conf(5) would no longer boot without _always_ entering the password. This patch restores the old (8.x and older) functionality for password in loader.conf(5) while adding a new bootlock_password feature to replace the edge-case should anybody desire the regressed functionality (HINT: great for PXE servers and/or private distributions). loader.conf(5) was updated to be more clear with-respect to password setting (previous text was misleading). Documentation (loader.conf(5) and check-password.4th(8)) has been updated to include notes on the new bootlock_password setting. Special thanks to Alex Verbod for bringing this to my attention and helping to refine the loader.conf(5) text. PR: conf/170110 Submitted by: Vitaly Zakharov <ded3axap@gmail.com> Reviewed by: Alexander Verbod <alexander.verbod@gmail.com> diff 244158 Wed Dec 12 17:57:56 MST 2012 dteske Fix a regression caused by SVN r222417. Prior to r222417, setting `password' in loader.conf(5) did not prevent boot but instead only prevented changes to boot options by prompting for password if autoboot failed or the user interrupted the countdown sequence. After r222417 the same machine with `password' set in loader.conf(5) would no longer boot without _always_ entering the password. This patch restores the old (8.x and older) functionality for password in loader.conf(5) while adding a new bootlock_password feature to replace the edge-case should anybody desire the regressed functionality (HINT: great for PXE servers and/or private distributions). loader.conf(5) was updated to be more clear with-respect to password setting (previous text was misleading). Documentation (loader.conf(5) and check-password.4th(8)) has been updated to include notes on the new bootlock_password setting. Special thanks to Alex Verbod for bringing this to my attention and helping to refine the loader.conf(5) text. PR: conf/170110 Submitted by: Vitaly Zakharov <ded3axap@gmail.com> Reviewed by: Alexander Verbod <alexander.verbod@gmail.com> diff 244158 Wed Dec 12 17:57:56 MST 2012 dteske Fix a regression caused by SVN r222417. Prior to r222417, setting `password' in loader.conf(5) did not prevent boot but instead only prevented changes to boot options by prompting for password if autoboot failed or the user interrupted the countdown sequence. After r222417 the same machine with `password' set in loader.conf(5) would no longer boot without _always_ entering the password. This patch restores the old (8.x and older) functionality for password in loader.conf(5) while adding a new bootlock_password feature to replace the edge-case should anybody desire the regressed functionality (HINT: great for PXE servers and/or private distributions). loader.conf(5) was updated to be more clear with-respect to password setting (previous text was misleading). Documentation (loader.conf(5) and check-password.4th(8)) has been updated to include notes on the new bootlock_password setting. Special thanks to Alex Verbod for bringing this to my attention and helping to refine the loader.conf(5) text. PR: conf/170110 Submitted by: Vitaly Zakharov <ded3axap@gmail.com> Reviewed by: Alexander Verbod <alexander.verbod@gmail.com> |
/freebsd-11.0-release/sys/boot/pc98/boot0/ | ||
H A D | Makefile | 64123 Wed Aug 02 08:46:08 MDT 2000 kato Added PC-98 HDD boot manager. The boot0 is the `IPL' which occupies sector 0 of a disk and boot0.5 is the `boot selector' which starts from address 0x400. The IPL loads boot0.5 and boot0.5 loads bootblock of a slice. The boot manager stuff was developed by me (kato) with Borland C++, and then, translated into bcc in the ports collection by Nokubi-san. After that, boot0 has been translated into gas with the .code16 directive by Takahashi-san (nyan) and boot0.5 has been rewritten in gas by me. 64123 Wed Aug 02 08:46:08 MDT 2000 kato Added PC-98 HDD boot manager. The boot0 is the `IPL' which occupies sector 0 of a disk and boot0.5 is the `boot selector' which starts from address 0x400. The IPL loads boot0.5 and boot0.5 loads bootblock of a slice. The boot manager stuff was developed by me (kato) with Borland C++, and then, translated into bcc in the ports collection by Nokubi-san. After that, boot0 has been translated into gas with the .code16 directive by Takahashi-san (nyan) and boot0.5 has been rewritten in gas by me. 64123 Wed Aug 02 08:46:08 MDT 2000 kato Added PC-98 HDD boot manager. The boot0 is the `IPL' which occupies sector 0 of a disk and boot0.5 is the `boot selector' which starts from address 0x400. The IPL loads boot0.5 and boot0.5 loads bootblock of a slice. The boot manager stuff was developed by me (kato) with Borland C++, and then, translated into bcc in the ports collection by Nokubi-san. After that, boot0 has been translated into gas with the .code16 directive by Takahashi-san (nyan) and boot0.5 has been rewritten in gas by me. 64123 Wed Aug 02 08:46:08 MDT 2000 kato Added PC-98 HDD boot manager. The boot0 is the `IPL' which occupies sector 0 of a disk and boot0.5 is the `boot selector' which starts from address 0x400. The IPL loads boot0.5 and boot0.5 loads bootblock of a slice. The boot manager stuff was developed by me (kato) with Borland C++, and then, translated into bcc in the ports collection by Nokubi-san. After that, boot0 has been translated into gas with the .code16 directive by Takahashi-san (nyan) and boot0.5 has been rewritten in gas by me. |
/freebsd-11.0-release/sys/boot/pc98/boot0.5/ | ||
H A D | Makefile | 64123 Wed Aug 02 08:46:08 MDT 2000 kato Added PC-98 HDD boot manager. The boot0 is the `IPL' which occupies sector 0 of a disk and boot0.5 is the `boot selector' which starts from address 0x400. The IPL loads boot0.5 and boot0.5 loads bootblock of a slice. The boot manager stuff was developed by me (kato) with Borland C++, and then, translated into bcc in the ports collection by Nokubi-san. After that, boot0 has been translated into gas with the .code16 directive by Takahashi-san (nyan) and boot0.5 has been rewritten in gas by me. 64123 Wed Aug 02 08:46:08 MDT 2000 kato Added PC-98 HDD boot manager. The boot0 is the `IPL' which occupies sector 0 of a disk and boot0.5 is the `boot selector' which starts from address 0x400. The IPL loads boot0.5 and boot0.5 loads bootblock of a slice. The boot manager stuff was developed by me (kato) with Borland C++, and then, translated into bcc in the ports collection by Nokubi-san. After that, boot0 has been translated into gas with the .code16 directive by Takahashi-san (nyan) and boot0.5 has been rewritten in gas by me. 64123 Wed Aug 02 08:46:08 MDT 2000 kato Added PC-98 HDD boot manager. The boot0 is the `IPL' which occupies sector 0 of a disk and boot0.5 is the `boot selector' which starts from address 0x400. The IPL loads boot0.5 and boot0.5 loads bootblock of a slice. The boot manager stuff was developed by me (kato) with Borland C++, and then, translated into bcc in the ports collection by Nokubi-san. After that, boot0 has been translated into gas with the .code16 directive by Takahashi-san (nyan) and boot0.5 has been rewritten in gas by me. 64123 Wed Aug 02 08:46:08 MDT 2000 kato Added PC-98 HDD boot manager. The boot0 is the `IPL' which occupies sector 0 of a disk and boot0.5 is the `boot selector' which starts from address 0x400. The IPL loads boot0.5 and boot0.5 loads bootblock of a slice. The boot manager stuff was developed by me (kato) with Borland C++, and then, translated into bcc in the ports collection by Nokubi-san. After that, boot0 has been translated into gas with the .code16 directive by Takahashi-san (nyan) and boot0.5 has been rewritten in gas by me. |
/freebsd-11.0-release/share/man/man5/ | ||
H A D | rctl.conf.5 | 220640 Thu Apr 14 18:40:13 MDT 2011 trasz Add manual page for rctl.conf(5). |
/freebsd-11.0-release/tools/build/options/ | ||
H A D | WITHOUT_ACPI | 156932 Tue Mar 21 07:50:50 MST 2006 ru Prepare to autogenerate the src.conf(5) manpage. |
H A D | WITHOUT_ATM | 156932 Tue Mar 21 07:50:50 MST 2006 ru Prepare to autogenerate the src.conf(5) manpage. |
H A D | WITHOUT_AUDIT | 156932 Tue Mar 21 07:50:50 MST 2006 ru Prepare to autogenerate the src.conf(5) manpage. |
H A D | WITHOUT_AUTHPF | 156932 Tue Mar 21 07:50:50 MST 2006 ru Prepare to autogenerate the src.conf(5) manpage. |
H A D | WITHOUT_BLUETOOTH | 156932 Tue Mar 21 07:50:50 MST 2006 ru Prepare to autogenerate the src.conf(5) manpage. |
H A D | WITHOUT_BOOT | 156932 Tue Mar 21 07:50:50 MST 2006 ru Prepare to autogenerate the src.conf(5) manpage. |
H A D | WITHOUT_CALENDAR | 156932 Tue Mar 21 07:50:50 MST 2006 ru Prepare to autogenerate the src.conf(5) manpage. |
H A D | WITHOUT_CPP | 156932 Tue Mar 21 07:50:50 MST 2006 ru Prepare to autogenerate the src.conf(5) manpage. |
H A D | WITHOUT_CRYPT | 156932 Tue Mar 21 07:50:50 MST 2006 ru Prepare to autogenerate the src.conf(5) manpage. |
H A D | WITHOUT_CVS | 156932 Tue Mar 21 07:50:50 MST 2006 ru Prepare to autogenerate the src.conf(5) manpage. |
H A D | WITHOUT_DICT | 156932 Tue Mar 21 07:50:50 MST 2006 ru Prepare to autogenerate the src.conf(5) manpage. |
H A D | WITHOUT_DYNAMICROOT | 156932 Tue Mar 21 07:50:50 MST 2006 ru Prepare to autogenerate the src.conf(5) manpage. |
Completed in 406 milliseconds