ASRock Rack PAUL IPMI Card

RageBone

Active Member
Jul 11, 2017
570
141
43
there are two AUX_PANEL connectors on the card.
Exactly, i'd say one needs to connect one of those to the Board, and the other possibly as usual, to the case?
The manual should be clear on that and which goes where.
 

RolloZ170

Well-Known Member
Apr 24, 2016
1,939
503
113
55
and the other possibly as usual, to the case?
yes, if you have AUX-Panel connected to the case front and unplug it to plug it to paul, the front panel of your case besomes dead.
the cable of the case front panel comes to the second AUX_PANEL conn. of the paul.
 
  • Like
Reactions: RageBone

Donatas

New Member
Jan 5, 2022
2
0
1
ASRock Rack's website does not seem to list such a version.


I thought the card could do that via NMI? At least that's what was stated up-thread.
Unfortunately the "HARD RESET" without any wiring/circuit on AUX1 does not work in my case.
Neither with firmware 1.01.00 nor with 1.01.05.
 

RolloZ170

Well-Known Member
Apr 24, 2016
1,939
503
113
55
They claim no compatibility outside of specific Asus motherboards, but that seems to be more a practical decision than the result of a different design.
you need a matching connector on the board. the Card have to acces all sensors and must know ther're addresses.
 

oneplane

Active Member
Jul 23, 2021
271
129
43
Technically, if you can find the addresses of the sensor devices on your current LCP/eSPI and SMBus buses you could provide the information to the card (in some way) and make it work. It's similar to the work needed in lm-sensors and coreboot when adding chips and mainboards.

Some of the data is available as ACPI data structure but that used to be notoriously unreliable, and the chips in question are always under some NDA (as if it's super secret how to read I2C data from a bog standard sensor...). Especially Nuvoton and ITE are horrible to get data on.
 
  • Like
Reactions: RageBone

RolloZ170

Well-Known Member
Apr 24, 2016
1,939
503
113
55
Technically, if you can find the addresses of the sensor devices on your current LCP/eSPI and SMBus buses you could provide the information to the card (in some way) and make it work.
will it more easy to make your own card then ?
 

oneplane

Active Member
Jul 23, 2021
271
129
43
will it more easy to make your own card then ?
Yes and no. The hardware generally isn't much of a problem (except for the NDAs and manufacturing), and the main BMC OS isn't all that hard either (just grab OpenBMC and off we go - ASpeed is specifically supported!).

The 'secrets' inside the PCH configuration, hard-wired management connections (the aforementioned SPI/I2C/LPC type interfaces) and any special addresses, registers and sequences the on-board sensors and control chips need are the real problem. It's not like those are special value and therefore must be kept secret to give the manufacturer an edge, it's just easier to NDA the whole thing to not have to deal with it (from a manufacturer's standpoint). This also applies to things like bare metal switches (BMS) and ONIE-installers. They are a bit ahead vs. x86 PC's in that respect since they actually have a standard that allows you to write multiplatform low-level installers, drivers, and controllers.

To control a mainboard you need to know what messages to send to which address and on which interface and in which order. Some of this gets abstracted by ACPI for the host operating system, but an IPMI/BMC controller cannot make use of in-band control (like the OS), it has to do it out-of-band. A IPMI/BMC card like this is directly hard-wired to the buses on the mainboard and can do things like ask the SuperIO chip what the current sensor readings are (temperature, voltage, amperage, tacho, frequency etc.) and also adjust outputs like fan speeds (since those are generally controlled by the SuperIO chip). It can also send information over the PCIe interface, over USB, SPI, I2C and LPC. Some systems have a WDT or power control circuit that is actually reachable over I2C instead of emulating power/reset button presses. Some systems use an NMI or CPU reset line instead. Which ones work and how they would work depends on what signals are available where.

All of this information could be out in the open, just a bunch of register addresses and usages, and we could run whatever commands we want. But that information is generally kept secret, mainly because the manufacturers aren't likely to make a profit on getting the lawyer department to un-NDA the right bits of information.

Most systems were we have gained control of the PCH, SuperIO and BMC have gotten that far by pure reverse engineering and experimentation. In some cases, leaked documents were used to figure out how the components are wired up so we know where we can inject/read commands from.