sgminer: Baikal Giant X10 / N / B - Open Source - Confirmed OC Giant B!

[cod3gen]

Rebuild of Baikal`s SG Miner for Giant X10 / N / B

Quick update 03.09.18;
Baikal N70 is missing from Baikal`s github, if any one have the orginal sgminer executable for this one, publish it here. N240 executable does not work for N70.

To those with N70 and N240, this sgminer will NOT work, at all.
It will only OC Giant B, and not X10, N.

Since the guys over at Baikal obviously have not made their version of SG Miner open source, lets do it for them!

The purpose for this recovery and rebuild was to see if it was possible to overclock these miners, and unlock extra algos for X10. Its not identical to the included sgminer with baikal miners however its performance is pretty damn close after monitoring two days. Some code cleanup should have been done, its messy thats its there without any proper use - and some of them are additional code from me thats not needed or even not correct.

I would like for the community to contribute, maybe we can find a solution for both overclocking and unlocking the extra algorithms, i also hope that this will make the guys over at baikal start to open source their software as according to SG Miner licensing, Bitmain already do this with their CG Miner! Let me know if you would like to collaborate, hit me up @ Discord or PM.

libusb and jansson is included of which libusb seems to be modified so i had to recover it.

More information about SG Miner is better to look for at https://github.com/sgminer-dev/sgminer

Github

https://github.com/cod3gen/sgminer-baikal


The Recovery
Currently recovered data from:

PiZero_GX10_171229_V1.1.img
PiZero_GN_180310_V1.0.img
PiZero_GB_180105_V1.0.img
Giant X10 Miner on hand
Giant N Miner on hand
With a total of ~687000 files recovered, of which about 601000 files where duplicates and removed. After some additional sorting i was left with 60223 files. These files can be found here: https://drive.google.com/open?id=1ZSFova5RtgaxZD7K2PJdv-lI5BKC07KH

Firmware (STM Chip) files for X10 / B / N:
https://drive.google.com/open?id=1hgHN2FtyQAZx8-7_oAgYIb8Zs657SrrT

Get in touch
Get in touch at Discord - cod3gen#5466

Like my work?

ETH: 0x57A9F99645dC74F9373409A8Ba18Bc0F92566af3
LTC: MGWHyZpZytPeKwvKLGZseuHAS8C2Ak3Xqe
BTC: 3CVEThoqDY3RqS4fwnJWcUR6zd9Mfa2VLo
XVG: DD3aZcGATCh55TvVTW4chg2PrUHLdV4u5k

[1714605952]

1714605952

[1714605952]

1714605952

[1714605952]

1714605952

[1714605952]

1714605952

[cod3gen]

reserved..

[cod3gen]

Great if anyone with a Giant B can test if this miner works for them. I have yet to test Skein on X10, or Aeon on N to verify that those are working.

[rogerthat55]

https://pastebin.com/LS9D2F9p

I don't exactly what I'm looking at, but I've found it interesting here, where they are testing out the X10, N, and B at the same time. You can see where they set #if 0 for Groestl, Nist5, X11-Gost, Veltor for the X10.

Code:

#ifdef USE_BAIKAL
int to_baikal_algorithm(algorithm_type_t type)
{
    switch (type) {
#if BAIKAL_TYPE & BAIKAL_1772
    case ALGO_X11:
        return 0x01;
    case ALGO_QUARK:
        return 0x05;
    case ALGO_QUBIT:
        return 0x06;
    case ALGO_SKEINCOIN:
        return 0x08;
    case ALGO_MYRIAD_GROESTL:
        return 0x09;
#if 0
    case ALGO_GROESTL:
        return 0x0A;
    case ALGO_NIST:
        return 0x0C;
    case ALGO_X11GOST:
        return 0x07;
    case ALGO_VELTOR:
        return 0x0D;
#endif
#endif 

#if BAIKAL_TYPE & BAIKAL_1751
    case ALGO_CRYPTONIGHT:
        return 0x20;
    case ALGO_CRYPTONIGHT_LITE:
        return 0x22;
#endif 

#if BAIKAL_TYPE & BAIKAL_1791
    case ALGO_BLAKECOIN:
    case ALGO_VANILLA:
        return 0x30;
    case ALGO_DECRED: // input data 180byte
        return 0x32;
    case ALGO_SIA:
        return 0x34;
    case ALGO_LBRY:
        return 0x36;
    case ALGO_PASCAL:
        return 0x37;
    case ALGO_BLAKE:  // input data 80byte
#endif 
    default:
        return 0;
    }
}
#endif

[rogerthat55]

As far as I can tell, it's setting the base clock to whatever type of miner it is.

1751 = N
1791 = B
else/1772 = X10

Code:

#if BAIKAL_TYPE == BAIKAL_1751
#define BAIKAL_CLK_DEF  		(200)
#elif BAIKAL_TYPE == BAIKAL_1791
#define BAIKAL_CLK_DEF  		(400)
#else
#define BAIKAL_CLK_DEF  		(300)
#endif

[cod3gen]

https://pastebin.com/LS9D2F9p
I don't exactly what I'm looking at, but I've found it interesting here, where they are testing out the X10, N, and B at the same time. You can see where they set #if 0 for Groestl, Nist5, X11-Gost, Veltor for the X10.

They have done that, because those algo`s simply dont work yet, seems to be missing on firmware side.

But, the "two" extra algos for sure is some of those - a firmware upgrade is needed. Ive looked over the statistics of the different algo`s, and i have not seen so much unnatural rises in hashrate on any of those really, so that may mean that they are not finished developing them just yet. Unlike Monero which had a high rise in quarter 4 of 2017, no doubt that was Giant N.

As far as I can tell, it's setting the base clock to whatever type of miner it is.

1751 = N
1791 = B
else/1772 = X10

Code:

#if BAIKAL_TYPE == BAIKAL_1751
#define BAIKAL_CLK_DEF  		(200)
#elif BAIKAL_TYPE == BAIKAL_1791
#define BAIKAL_CLK_DEF  		(400)
#else
#define BAIKAL_CLK_DEF  		(300)
#endif

Yepp, thats what they want to do atleast. Not the correct method, so it does not work, since BAIKAL_TYPE will always be (0x7) while BAIKAL_1751 will always be (0x1). Some changes are required there.

Honestly, i have no idea what the chip frequency actually are. The return numbers from the STM32 chip just does not add up, the displayed number is static, while returned from STM32 chip is always 440 Mhz, both on Giant N and X10 - so i know its not correct.

[DigitalCruncher]

They have done that, because those algo`s simply dont work yet, seems to be missing on firmware side.

But, the "two" extra algos for sure is some of those - a firmware upgrade is needed. Ive looked over the statistics of the different algo`s, and i have not seen so much unnatural rises in hashrate on any of those really, so that may mean that they are not finished developing them just yet. Unlike Monero which had a high rise in quarter 4 of 2017, no doubt that was Giant N.

The global hash rate of the Groestl had increased in 5... 10 times from  autumn of 2017. From Jan 2018 it became obvious that Groestl is solo mined by single wallet.  Week ago I have seen 700+ GH/s, it is absolute record in this coin.

So I am 99% sure that two algorithms are operational.

[boxalex]

They have done that, because those algo`s simply dont work yet, seems to be missing on firmware side.

But, the "two" extra algos for sure is some of those - a firmware upgrade is needed. Ive looked over the statistics of the different algo`s, and i have not seen so much unnatural rises in hashrate on any of those really, so that may mean that they are not finished developing them just yet. Unlike Monero which had a high rise in quarter 4 of 2017, no doubt that was Giant N.

The global hash rate of the Groestl had increased in 5... 10 times from  autumn of 2017. From Jan 2018 it became obvious that Groestl is solo mined by single wallet.  Week ago I have seen 700+ GH/s, it is absolute record in this coin.

So I am 99% sure that two algorithms are operational.

I doubt that 700 Gh/s is enough for a whole Baikal Farm mining Groestl. Having in mind that 1 Baikal should do about 5 - 10 Gh/s it would mean only 70 - 140 Baikals, just nothing in my opinion. On the other side, it would take about 12.000 1089ti Cards to mine ~700 Gh/s. Having in mind that since December/January there are no more graphic cards available and evertyhing is sold out it makes more sence in my opinion that a small part of these Cards are just mining Groestl, mostly through nicehash, hence the single wallet.

If the hasrate was 700 Th/s or Ph/s i would agree with being it Baikals, but "only" 700 Gh/s i would bet on Nicehash and graphic cards.

[DigitalCruncher]

I doubt that 700 Gh/s is enough for a whole Baikal Farm mining Groestl. Having in mind that 1 Baikal should do about 5 - 10 Gh/s it would mean only 70 - 140 Baikals, just nothing in my opinion. On the other side, it would take about 12.000 1089ti Cards to mine ~700 Gh/s. Having in mind that since December/January there are no more graphic cards available and evertyhing is sold out it makes more sence in my opinion that a small part of these Cards are just mining Groestl, mostly through nicehash, hence the single wallet.

If the hasrate was 700 Th/s or Ph/s i would agree with being it Baikals, but "only" 700 Gh/s i would bet on Nicehash and graphic cards.

700 TH/s is unreasonable hashrate for Groestl, it is a waste of power. Hidden miner will gain no increase in profit by using terahashes. But 700 GH/s is just enough to mine most of blocks.

[cod3gen]

They have done that, because those algo`s simply dont work yet, seems to be missing on firmware side.

But, the "two" extra algos for sure is some of those - a firmware upgrade is needed. Ive looked over the statistics of the different algo`s, and i have not seen so much unnatural rises in hashrate on any of those really, so that may mean that they are not finished developing them just yet. Unlike Monero which had a high rise in quarter 4 of 2017, no doubt that was Giant N.

The global hash rate of the Groestl had increased in 5... 10 times from  autumn of 2017. From Jan 2018 it became obvious that Groestl is solo mined by single wallet.  Week ago I have seen 700+ GH/s, it is absolute record in this coin.

So I am 99% sure that two algorithms are operational.

https://www.coinwarz.com/network-hashrate-charts/groestlcoin-network-hashrate-chart

There is a short peak at 551 Gh/s there.. It could be something

[cod3gen]

Updated post with link for download firmware on both my X10 and N.

[Mattthev]

We need Wolf here

[boxalex]

They have done that, because those algo`s simply dont work yet, seems to be missing on firmware side.

But, the "two" extra algos for sure is some of those - a firmware upgrade is needed. Ive looked over the statistics of the different algo`s, and i have not seen so much unnatural rises in hashrate on any of those really, so that may mean that they are not finished developing them just yet. Unlike Monero which had a high rise in quarter 4 of 2017, no doubt that was Giant N.

The global hash rate of the Groestl had increased in 5... 10 times from  autumn of 2017. From Jan 2018 it became obvious that Groestl is solo mined by single wallet.  Week ago I have seen 700+ GH/s, it is absolute record in this coin.

So I am 99% sure that two algorithms are operational.

https://www.coinwarz.com/network-hashrate-charts/groestlcoin-network-hashrate-chart

There is a short peak at 551 Gh/s there.. It could be something

on that date the price for Groestl was up too and had a peak, one more evidience in my opinion that it was nicehash mining there or maybe another bigger pool with profit switching. Makes no sense to to put just for 1 day a larger amount of Baikals on it, but makes perfect sense for profit switching gpus.

[boxalex]

I doubt that 700 Gh/s is enough for a whole Baikal Farm mining Groestl. Having in mind that 1 Baikal should do about 5 - 10 Gh/s it would mean only 70 - 140 Baikals, just nothing in my opinion. On the other side, it would take about 12.000 1089ti Cards to mine ~700 Gh/s. Having in mind that since December/January there are no more graphic cards available and evertyhing is sold out it makes more sence in my opinion that a small part of these Cards are just mining Groestl, mostly through nicehash, hence the single wallet.

If the hasrate was 700 Th/s or Ph/s i would agree with being it Baikals, but "only" 700 Gh/s i would bet on Nicehash and graphic cards.

700 TH/s is unreasonable hashrate for Groestl, it is a waste of power. Hidden miner will gain no increase in profit by using terahashes. But 700 GH/s is just enough to mine most of blocks.

700 TH/s is not much in the Asics world, whats left for 700 GH/s as you mention.
If its a waste of power one more reason it is not the baikals there. Anyway, i checked now the hashrate for groestle and it was never 700 Gh/s at any time, expect that only peek for 1 day when groestle coin had some peak too. There is absolutly nothing even indicating that there is a larger amount of baikals on the groestl algo.

Beside that, i wish as much as you that the 2 missing algos come out finally, but we should stay serious and objective when investigating or observing whatever.

[agatazit]

I have extracted Baikal_pizero_GN.img downloaded from Baikal git, with full dir tree and all filenames, if you need it i will upload it somewhere.

[CNoteFan]

So, I'm confused by the mystic line of code in driver-baikalu.c:

Code:

msg.data[0] = (clk == 0) ? clk : ((clk / 10) % 20) + 2;

I decided to run some common settings.  These resulting values in no way correlate, even if the controller board was accepting input:

mhz  | ((clk / 10) % 20) + 2      
-------------------------------
150   |    17
200   |    2
250   |    7
300   |    12
350   |    17
400   |    2

Perhaps someone smarter can enlighten me?

Also, I found that the following line seems to be leftover from an earlier generation of miner (PiZero_170605_V1.4.img):

Code:

miner->clock        = msg.data[3] << 1;

But I'm not sure why they are bitwise left shifting it.

[cod3gen]

Got the same results as you did when i checked that. Im not so sure either. Ive tried to send multiple different values just to see if i could get the read data to change at all, but its just none. But then again, this SG Miner covers many of baikal`s miners, including earlier models - which i think this function is for.

Did go over the responses from ST chip, only data field;

Code:

Command BAIKAL_SET_ID
Returns:
Data(0) -> 1
Data(7) -> TEMP

Command BAIKAL_SEND_WORK
Returns:
Data(0) -> 220 (Frequency?)
Data(7) -> TEMP

Command BAIKAL_SET_OPTION
Returns:
Data(0) -> 220 (Frequency?)
Data(7) -> TEMP

Command BAIKAL_RESET
Returns:
Data(0) -> 3
Data(7) -> TEMP

Command BAIKAL_GET_INFO
Returns:
Data(1) -> 22 (Firmware ver?) Same return on Giant N so cant be..
Data(2) -> 113 (HW Ver?) Return 81 on Giant N, that may be firmware ver.
Data(3) -> 7 (BBG, whats that?) Return 0 on Giant N
Data(4) -> 220 (Frequency?) Return 210 on Giant N
Data(5) -> 64 (Total count of ASIC chips?) Return 32 on Giant N
Data(6) -> 64, 63 on two boards(Total count of Working ASIC chips?) Return 32 on Giant N
Data(7) -> 114 (Asic version?) returns 81 on Giant N.

Command GET_RESULT
Returns:
Data(7) -> TEMP

[CNoteFan]

Got the same results as you did when i checked that. Im not so sure either. Ive tried to send multiple different values just to see if i could get the read data to change at all, but its just none. But then again, this SG Miner covers many of baikal`s miners, including earlier models - which i think this function is for.

Did go over the responses from ST chip, only data field;

Code:

Command BAIKAL_SET_ID
Returns:
Data(0) -> 1
Data(7) -> TEMP

Command BAIKAL_SEND_WORK
Returns:
Data(0) -> 220 (Frequency?)
Data(7) -> TEMP

Command BAIKAL_SET_OPTION
Returns:
Data(0) -> 220 (Frequency?)
Data(7) -> TEMP

Command BAIKAL_RESET
Returns:
Data(0) -> 3
Data(7) -> TEMP

Command BAIKAL_GET_INFO
Returns:
Data(1) -> 22 (Firmware ver?) Same return on Giant N so cant be..
Data(2) -> 113 (HW Ver?) Return 81 on Giant N, that may be firmware ver.
Data(3) -> 7 (BBG, whats that?) Return 0 on Giant N
Data(4) -> 220 (Frequency?) Return 210 on Giant N
Data(5) -> 64 (Total count of ASIC chips?) Return 32 on Giant N
Data(6) -> 64, 63 on two boards(Total count of Working ASIC chips?) Return 32 on Giant N
Data(7) -> 114 (Asic version?) returns 81 on Giant N.

Command GET_RESULT
Returns:
Data(7) -> TEMP

I have actually seen the firmware version change when I changed the firmware to an older version (Notice the firmware fix on v22 for asic_count_r:

GX10_V16_20171111 (From X10 v1.1 Image).bin:
baikal_getinfo : Firmware Version: 22 - Hardware Version: 113 - BBG?: 7 - Clock: 220 - Clock << 1: 440 - ASIC Count: 45 - ASIC Count R: 45 - ASIC Ver: 114

GX10_V13_20171109 (From X10 v1.0 Image).bin:
baikal_getinfo : Firmware Version: 19 - Hardware Version: 113 - BBG?: 7 - Clock: 220 - Clock << 1: 440 - ASIC Count: 45 - ASIC Count R: 23 - ASIC Ver: 114

GX10_V11_2017 (From X10 v1.1 Image).bin:
baikal_getinfo : Firmware Version: 17 - Hardware Version: 113 - BBG?: 7 - Clock: 210 - Clock << 1: 420 - ASIC Count: 45 - ASIC Count R: 23 - ASIC Ver: 114

[cod3gen]

I have actually seen the firmware version change when I changed the firmware to an older version (Notice the firmware fix on v22 for asic_count_r:

GX10_V16_20171111 (From X10 v1.1 Image).bin:
baikal_getinfo : Firmware Version: 22 - Hardware Version: 113 - BBG?: 7 - Clock: 220 - Clock << 1: 440 - ASIC Count: 45 - ASIC Count R: 45 - ASIC Ver: 114

GX10_V13_20171109 (From X10 v1.0 Image).bin:
baikal_getinfo : Firmware Version: 19 - Hardware Version: 113 - BBG?: 7 - Clock: 220 - Clock << 1: 440 - ASIC Count: 45 - ASIC Count R: 23 - ASIC Ver: 114

GX10_V11_2017 (From X10 v1.1 Image).bin:
baikal_getinfo : Firmware Version: 17 - Hardware Version: 113 - BBG?: 7 - Clock: 210 - Clock << 1: 420 - ASIC Count: 45 - ASIC Count R: 23 - ASIC Ver: 114

Okey. I noticed the clock report went down to 210 on V11.. Did you perhaps notice any differences to hash speed?

[CNoteFan]

I have actually seen the firmware version change when I changed the firmware to an older version (Notice the firmware fix on v22 for asic_count_r:

GX10_V16_20171111 (From X10 v1.1 Image).bin:
baikal_getinfo : Firmware Version: 22 - Hardware Version: 113 - BBG?: 7 - Clock: 220 - Clock << 1: 440 - ASIC Count: 45 - ASIC Count R: 45 - ASIC Ver: 114

GX10_V13_20171109 (From X10 v1.0 Image).bin:
baikal_getinfo : Firmware Version: 19 - Hardware Version: 113 - BBG?: 7 - Clock: 220 - Clock << 1: 440 - ASIC Count: 45 - ASIC Count R: 23 - ASIC Ver: 114

GX10_V11_2017 (From X10 v1.1 Image).bin:
baikal_getinfo : Firmware Version: 17 - Hardware Version: 113 - BBG?: 7 - Clock: 210 - Clock << 1: 420 - ASIC Count: 45 - ASIC Count R: 23 - ASIC Ver: 114

Okey. I noticed the clock report went down to 210 on V11.. Did you perhaps notice any differences to hash speed?

I didn't check!  I back-dated the firmware, then tried to get the clock to accept a value then I went back to the current version.