Make serial port and console flag be able to customize #2
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Accton AS5712_54X uses COM2 as serial port. And it needs to turn on the flag of console to make syslinux boot menu be visible. This patch provides additional variables to configure the settings. Reference: 1. http://www.syslinux.org/wiki/index.php/SYSLINUX#CONSOLE_flag_val 2. http://www.syslinux.org/wiki/index.php/SYSLINUX#SERIAL_port_.5Bbaudrate_.5Bflowcontrol.5D.5D
Contributor
|
Looks great. Applied with commit 087232e. |
david56
added a commit
to david56/onie
that referenced
this pull request
Jan 27, 2016
The patch has been tested in Accton AS7716_32X with the following
features:
- demo Diag
- demo OS
The demo OS's GRUB menu looks like:
GNU GRUB version 2.02~beta2+e4a1fe391
+----------------------------------------------------------------------------+
|*Demo OS opencomputeproject#1 |
| Demo OS opencomputeproject#2 |
| ONIE |
| |
| |
| |
| |
| |
| |
| |
| |
| |
+----------------------------------------------------------------------------+
Use the ^ and v keys to select which entry is highlighted.
Press enter to boot the selected OS, `e' to edit the commands
before booting or `c' for a command-line.
The demo OS's linux shell looks like:
Welcome to the accton_as7716_32x DEMO OS platform opencomputeproject#2.
Please press Enter to activate this console.
Welcome to the accton_as7716_32x DEMO OS platform opencomputeproject#2.
ACCTON_AS7716_32X-OS-2:/ #
cbrune
pushed a commit
to cbrune/onie
that referenced
this pull request
Mar 7, 2016
During image discovery, ONIE looks for installer names in the following order: 1. onie-installer-<cpu_arch>-<hw_vendor>_<machine>-r<machine_revision> 2. onie-installer-<cpu_arch>-<hw_vendor>_<machine> 3. onie-installer-<hw_vendor>_<machine> 4. onie-installer-<cpu_arch> 5. onie-installer With the advent of ONIE enabled systems supporting multiple switch silicon vendors, step 4 has become ambiguous. This patch adds an additional step to the ONIE waterfall that includes the switch silicon vendor. In the above waterfall this new step would be between steps 3 and 4. The new step looks like: onie-installer-<cpu_arch>-<switch_silicon_vendor> Before the change the kvm_x86_64 machine waterfall discovery looks like this: <cpu_arch> = x86_64 <hw_vendor>_<machine> = kvm_x86_64 Info: Fetching http://10.0.2.2/onie-installer-x86_64-kvm_x86_64-r0 ... Info: Fetching http://10.0.2.2/onie-installer-x86_64-kvm_x86_64 ... Info: Fetching http://10.0.2.2/onie-installer-kvm_x86_64 ... Info: Fetching http://10.0.2.2/onie-installer-x86_64 ... Info: Fetching http://10.0.2.2/onie-installer ... After the changing, using a completely fictitious silicon vendor, the waterfall looks like: <switch_silicon_vendor> = qemu Info: Fetching http://10.0.2.2/onie-installer-x86_64-kvm_x86_64-r0 ... Info: Fetching http://10.0.2.2/onie-installer-x86_64-kvm_x86_64 ... Info: Fetching http://10.0.2.2/onie-installer-kvm_x86_64 ... Info: Fetching http://10.0.2.2/onie-installer-x86_64-qemu ... Info: Fetching http://10.0.2.2/onie-installer-x86_64 ... Info: Fetching http://10.0.2.2/onie-installer ... Technically the same information is contained in step opencomputeproject#3 "onie-installer-<hw_vendor>_<machine>", however the new file name is more generic and will be easier for customers to maintain when using multiple platforms. Imagine the case of a customer who has multiple x86 hardware platforms, from different hardware vendors, using different switch silicon. Also imagine NOS installers that target a specific switch silicon. The customer could maintain NOS installers named as in step opencomputeproject#2 and be OK, however, that is a lot of files to manage. Using the new step "<cpu_arch>-<switch_silicon_vendor>" the end customer could target all of the x86 platforms from a particular silicon vendor with a single NOS image.
cbrune
pushed a commit
to cbrune/onie
that referenced
this pull request
Mar 8, 2016
During image discovery, ONIE looks for installer names in the following order: 1. onie-installer-<cpu_arch>-<hw_vendor>_<machine>-r<machine_revision> 2. onie-installer-<cpu_arch>-<hw_vendor>_<machine> 3. onie-installer-<hw_vendor>_<machine> 4. onie-installer-<cpu_arch> 5. onie-installer With the advent of ONIE enabled systems supporting multiple switch silicon vendors, step 4 has become ambiguous. This patch adds an additional step to the ONIE waterfall that includes the switch silicon vendor. In the above waterfall this new step would be between steps 3 and 4. The new step looks like: onie-installer-<cpu_arch>-<switch_silicon_vendor> Before the change the kvm_x86_64 machine waterfall discovery looks like this: <cpu_arch> = x86_64 <hw_vendor>_<machine> = kvm_x86_64 Info: Fetching http://10.0.2.2/onie-installer-x86_64-kvm_x86_64-r0 ... Info: Fetching http://10.0.2.2/onie-installer-x86_64-kvm_x86_64 ... Info: Fetching http://10.0.2.2/onie-installer-kvm_x86_64 ... Info: Fetching http://10.0.2.2/onie-installer-x86_64 ... Info: Fetching http://10.0.2.2/onie-installer ... After the changing, using a completely fictitious silicon vendor, the waterfall looks like: <switch_silicon_vendor> = qemu Info: Fetching http://10.0.2.2/onie-installer-x86_64-kvm_x86_64-r0 ... Info: Fetching http://10.0.2.2/onie-installer-x86_64-kvm_x86_64 ... Info: Fetching http://10.0.2.2/onie-installer-kvm_x86_64 ... Info: Fetching http://10.0.2.2/onie-installer-x86_64-qemu ... Info: Fetching http://10.0.2.2/onie-installer-x86_64 ... Info: Fetching http://10.0.2.2/onie-installer ... Technically the same information is contained in step opencomputeproject#3 "onie-installer-<hw_vendor>_<machine>", however the new file name is more generic and will be easier for customers to maintain when using multiple platforms. Imagine the case of a customer who has multiple x86 hardware platforms, from different hardware vendors, using different switch silicon. Also imagine NOS installers that target a specific switch silicon. The customer could maintain NOS installers named as in step opencomputeproject#2 and be OK, however, that is a lot of files to manage. Using the new step "<cpu_arch>-<switch_silicon_vendor>" the end customer could target all of the x86 platforms from a particular silicon vendor with a single NOS image.
Closed
cbrune
pushed a commit
that referenced
this pull request
Mar 15, 2016
During image discovery, ONIE looks for installer names in the following order: 1. onie-installer-<cpu_arch>-<hw_vendor>_<machine>-r<machine_revision> 2. onie-installer-<cpu_arch>-<hw_vendor>_<machine> 3. onie-installer-<hw_vendor>_<machine> 4. onie-installer-<cpu_arch> 5. onie-installer With the advent of ONIE enabled systems supporting multiple switch silicon vendors, step 4 has become ambiguous. This patch adds an additional step to the ONIE waterfall that includes the switch silicon vendor. In the above waterfall this new step would be between steps 3 and 4. The new step looks like: onie-installer-<cpu_arch>-<switch_silicon_vendor> Before the change the kvm_x86_64 machine waterfall discovery looks like this: <cpu_arch> = x86_64 <hw_vendor>_<machine> = kvm_x86_64 Info: Fetching http://10.0.2.2/onie-installer-x86_64-kvm_x86_64-r0 ... Info: Fetching http://10.0.2.2/onie-installer-x86_64-kvm_x86_64 ... Info: Fetching http://10.0.2.2/onie-installer-kvm_x86_64 ... Info: Fetching http://10.0.2.2/onie-installer-x86_64 ... Info: Fetching http://10.0.2.2/onie-installer ... After the changing, using a completely fictitious silicon vendor, the waterfall looks like: <switch_silicon_vendor> = qemu Info: Fetching http://10.0.2.2/onie-installer-x86_64-kvm_x86_64-r0 ... Info: Fetching http://10.0.2.2/onie-installer-x86_64-kvm_x86_64 ... Info: Fetching http://10.0.2.2/onie-installer-kvm_x86_64 ... Info: Fetching http://10.0.2.2/onie-installer-x86_64-qemu ... Info: Fetching http://10.0.2.2/onie-installer-x86_64 ... Info: Fetching http://10.0.2.2/onie-installer ... Technically the same information is contained in step #3 "onie-installer-<hw_vendor>_<machine>", however the new file name is more generic and will be easier for customers to maintain when using multiple platforms. Imagine the case of a customer who has multiple x86 hardware platforms, from different hardware vendors, using different switch silicon. Also imagine NOS installers that target a specific switch silicon. The customer could maintain NOS installers named as in step #2 and be OK, however, that is a lot of files to manage. Using the new step "<cpu_arch>-<switch_silicon_vendor>" the end customer could target all of the x86 platforms from a particular silicon vendor with a single NOS image. Signed-off-by: Curt Brune <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Accton AS5712_54X uses COM2 as serial port. And it needs to turn
on the flag of console to make syslinux boot menu be visible.
This patch provides additional variables to configure the settings.
Reference: