Hello! With you again Maxim. Today I will talk a little about the management board for our server. In general, it is not particularly complex, but it is also impossible to skip this component - my colleagues and I decided that all essential subsystems and server components should be covered.
Can I do without this board?
Here, perhaps, the question will immediately follow - why do we even need to remove the control functions from the motherboard to a separate card? Why multiply the number of components, isn't it easier to put everything on the motherboard, as server manufacturers usually do?
I agree, under normal conditions, we would have done just that, but in this project and in this matter we had to do outside the box. Because of the density of the motherboard layout, there was simply no extra space to house the BMC chips, USB host, PCIe switch and wiring all the circuits associated with them. And besides, there was simply no space on the back of the chassis to install the Ethernet / USB connectors directly on the motherboard. In general, we decided not to complicate the already complicated motherboard, and brought all these components to a separate control card. This method, among other things, gives more flexibility in terms of future improvements and changes.
What's inside?
Actually, the structural scheme of the board is very simple:
')
The block diagram of the server management board.
The main component is the BMC ASPEED AST2400 chip, which is very popular and probably well known to many. It has its own 512 MB DDR3 dedicated memory.
Under the spoiler, a brief orientation about BMC is hardly interesting for experienced people in these areas.BMC is a Baseboard Management Controller, a system board management controller. It is turned on when the standby voltage is applied to the motherboard (that is, when the cable is connected to the power supply), it loads Linux from its own ROM-memory. In the working mode, it monitors the operation of the system - it collects information from sensors (fan speed, temperature, voltage and currents on components, sensor for penetration into the case), reads memory error codes, allows you to control system components both automatically and manually through the network. Keeps system monitoring logs, can turn on / off / reboot the system, update the host's ROM firmware, etc. In general, the lonely workhorse.
A USB3.0 host is connected to BMC, for which we use a TI7340 chip. From it, two USB3.0 ports are brought out. Also attached to the BMC is a two-channel Gigabit Ethernet controller (BCM5720), whose ports are routed to the outside. This is a very common controller that is well supported by the POWER architecture.
All this company is united by a PCIe switch (at the price it was optimal to supply the PEX8714), directly connected to the connector for connection to the motherboard. It splits PCIe x4 on x2 and 2 on x1.
Connector for connecting to the motherboard has a small feature. The connector itself is completely standard. But in order to completely eliminate the installation of the control board in a regular PCIe slot (on the motherboard we have a dedicated dedicated slot for the control board), we deployed the connector 180 degrees and shifted it relative to the standard for PCIe placement.
In the diagram, you can also notice the VGA video output and two serial ports - they were not brought out, they were left in the form of headers. They are needed mainly for debugging purposes - and there is simply no room left on the external panel of a low-profile PCIe card after placing two USB and two Ethernet ports.
What does the board look like
Actually, the geometry of the board turned out this way (the board is low-profile, but long):
On the left side of the image is the rear panel of the board - 2 USB3.0 ports are brought out of it, and under them are dual GbE ports.
I will also show our favorite tech-writing on the board:
Signals and power are spread over 8 layers.
I think it's great to print in color and hang on the wall - elegant, inspiring, and very vital! :)
Perhaps we should say a little more about the BMC. We develop the firmware for it on the basis of OpenBMC. Actually, the tasks are simple:
- fix requirements for firmware and prioritize their implementation;
- raise the initial version on our server (adapting the basic functionality to our hardware);
- add the functionality we need.
The resulting version, of course, in OpenBMC will commit.