Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Question on baud rate of sol-util / mTerm on Tioga Pass #95

Open
MennoCB opened this issue Oct 21, 2018 · 5 comments
Open

Question on baud rate of sol-util / mTerm on Tioga Pass #95

MennoCB opened this issue Oct 21, 2018 · 5 comments

Comments

@MennoCB
Copy link

MennoCB commented Oct 21, 2018

Hi,

Facebook 2S Server Tioga Pass specification says:
Setting for the local physical COM port (COM0) and SOL (COM1): The default is enable console redirection on both ports with baud rate 57600, no flow control, terminal type VT100, 8 data bits, No Parity, 1 Stop Bit."
But we have noticed that our Tioga Pass channel version motherboards come with a default of 115200 for the BIOS, which is probably the default setting from AMI.

With everything set to 57600 it works just fine. But I have found no setting for baud rate in OpenBMC, is it possible to set it to something else besides 57600?
I don't see this as an OpenBMC issues, but it would be nice in those cases where your devices turns out to have a different setting.

Thanks & Regards,
Menno

@amithash
Copy link
Contributor

The BMC console baudrate is set in different components depending on who has control of the UART during boot.
Uboot, kernel:
CONFIG_BAUDRATE and CONFIG_BOOTARGS in include/configs/{platform}.h.
Example: include/configs/fbtp.h
Once user-space takes over, it is in common/recipes-utils/openbmc-utils/files/revise_inittab and meta-facebook/meta-{platform}/recipes-core/sysvinit/sysvinit-inittab_%.bbappend

The SOL (host-server) baud-rate is not under BMC control. So, I would recommend sticking to 57600.

@MennoCB
Copy link
Author

MennoCB commented Oct 23, 2018

My question was not so much about the baud rate of the BMC, but what if the host-server baud rate is not set to 57600, is there any option to change it on the SOL client side?
Of course recommended is 57600, but in my case the BIOS was set to 115200 by default, it could also be someone that installs the OS and sets it to 115200 by mistake. I would still like to be able to reach that BIOS or OS through SOL...

@tfangit
Copy link
Contributor

tfangit commented Oct 23, 2018

The current mTerm hard code the baudrate to 57600. In order to change it, you will need to modify the code and build/flash.

It won't be difficult to add an option to mTerm to accept baudrate parameter and then use board layer to override it.

One more enhancement could be to allow mTerm client to send a cmd to mTerm server to change the baudrate on the fly.

@amithash amithash reopened this Oct 23, 2018
@amithash
Copy link
Contributor

@MennoCB Thanks for the clarification! Re-opening the issue. Lets use this issue to track runtime configuration of baud rate as proposed by @tfangit.
In the meanwhile, you might need to recompile after changing tty_helper.h:#define BAUDRATE B57600

@MennoCB
Copy link
Author

MennoCB commented Oct 23, 2018

Thank you Amit, that is great and this already helps me with all the channel version gear from this manufacturer.

bbinxie pushed a commit to SW-CSA/openbmc that referenced this issue Aug 29, 2019
…em high CPU usage rate (facebook#95)

Summary:
Base on below commit:
facebookexternal/openbmc.accton@f986be3

1. Remove modbus function which can not get.
Pull Request resolved: facebookexternal/openbmc.accton#95

Test Plan: Test on Minipack:pass

Reviewed By: mikechoifb

fbshipit-source-id: 2f35b23c3
facebook-github-bot pushed a commit that referenced this issue Aug 30, 2019
…sent status (#95)

Summary:
presence_util.sh to get scm/fan/psu(pem)/debug card present status
Pull Request resolved: facebookexternal/openbmc.celestica#95

Test Plan:
root@bmc-oob:~# presence_util.sh
CARDS
scm : 1
FANS
fan1 : 1
fan2 : 1
fan3 : 1
fan4 : 1
POWER SUPPLIES
psu1 : 1
psu2 : 0
DEBUG CARD
debug_card : 1
root@bmc-oob:~#

Pass

Reviewed By: joancaneus

fbshipit-source-id: 4b957efd4d
facebook-github-bot pushed a commit that referenced this issue Oct 9, 2020
Summary:
ELBERT: SCM fpga upgrade keeps x86 state

Previously, SCM fpga upgrades would reset the x86 enable register to the default  which is x86 off. To prevent this, we need to latch and restore the x86 reset signal when programming scm fpga.

Testing:
Before this image: an upgrade would cause x86 to go down until reboot/powercycle
After this image: Downgrade/Upgraded and confirmed that x86 stays up. Repeated 30 times.

Pull Request resolved: facebookexternal/openbmc.arista#95

Reviewed By: benwei13

fbshipit-source-id: d69748af68
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants