 Show Posts
|
|
Pages: [1] 2 3 »
|
Is this mod of giantB legit? Can’t be, right? 185Gh/s? I have 4 pcs and will direct them all for some time it’s true and someone’s willing to help a fellow out?
After modifying the code it doesn't matter what you see in sgminer. You should check the hash rate on the pool side, and it should be pretty close to 46 GH/s. |
|
|
|
Boy, I talking about the firmware inside the STMCHIP 3 way board controller, find / -name fw_upgrade.sh
cod3gen, I love your work, so I give you a hint,
the original code show
msg.data[0] = (clk == 0) ? clk : ((clk / 10) % 20) + 2;
so your chip frequency is 2 + result of modulos....
msg.data[0] = (clk == 0) ? clk : ((clk / 10) % 20) + 2.2;
this is not ASIC chip .... so the chip frequency is 2 + modulo of + 2.0 + add 0.2 = 10% more power freq
32 chip X 3 = 96 X 2.2 = 211mhz...
To be honest this doesn't make any sense. Here is the baikal msg structure that is used in that case: typedef struct {
uint8_t miner_id;
uint8_t cmd;
uint8_t param;
uint8_t dest;
uint8_t data[512];
uint32_t len;
} baikal_msg;As you can see the data field consists of 8 bit integer values. So by adding a floating point number of 2.2 makes absolutely no difference compared to the standard 2. Both numbers (2 and 2.2) are converted to uint8_t resulting in a value of 2. |
|
|
|
|
For obtaining the assembly code I used eabi objdump, and for generating a more readable C pseudo code I used IDA Pro. Keep in mind that the pseudo code is just a reasonable guess.
|
|
|
|
Unfortunately I couldn't find any sign of such a lookup table in the X10 STM firmware (not to be confused with the image file, which has nothing to do with the actual firmware). I uploaded the pseudo code of the X10 firmware, which I used for static analysis: https://pastebin.com/PQ8e7H7R |
|
|
|
put a new update management program BaikalMonitor. Two days one of the Baikal began to glitch ( became often turn on the fan). Turned off, turned on and as wrote above Hashrate av showed 44 GH. Within a few minutes fell to 16 GC. Then another few minutes went down to 14 GC. And smoothly fell to 10.14 GH. Neither of which is not pierced. The question, maybe already from the factory to have the firmware and how to find it? But you can get to see the traffic from each machine. Possible hidden traffic, that is, the main to another address..
If you read back in this topic, then you can find the firmware of the X10. Still don't expect to edit the binary file without a hex editor. |
|
|
|
this is the current driver-baikal.h file that i use. Very similiar to the one you have #ifndef __DEVICE_BAIKAL_H__
#define __DEVICE_BAIKAL_H__
#include "miner.h"
#define BAIKAL_1751 (0x1)
#define BAIKAL_1772 (0x2)
#define BAIKAL_1791 (0x4)
#define BAIKAL_ALL (0x7)
#define BAIKAL_TYPE (BAIKAL_ALL)
#define BAIKAL_MAXMINERS (5)
#define BAIKAL_MAXUNIT (4)
#define BAIKAL_MAXASICS (16)
#define BAIKAL_WORK_FIFO (200)
#define BAIKAL_CLK_MIN (150)
#define BAIKAL_CLK_DEF (400)
#define BAIKAL_CLK_MAX (400)
#define BAIKAL_CUTOFF_TEMP (55)
#define BAIKAL_FANSPEED_DEF (100)
#define BAIKAL_FANSPEED_MAX (100)
#define BAIKAL_RECOVER_TEMP (40)
#define BAIKAL_RESET (0x01)
#define BAIKAL_GET_INFO (0x02)
#define BAIKAL_SET_OPTION (0x03)
#define BAIKAL_SEND_WORK (0x04)
#define BAIKAL_GET_RESULT (0x05)
#define BAIKAL_SET_ID (0x06)
#define BAIKAL_SET_IDLE (0x07)
#define BAIKAL_MINER_TYPE_NONE (0x00)
#define BAIKAL_MINER_TYPE_MINI (0x01)
#define BAIKAL_MINER_TYPE_CUBE (0x02)
#define BAIKAL_ENABLE_SETCLK (0)
#define BAIKAL_CHECK_STALE (0)
#define BAIKAL_EN_HWE (0)
#define BAIKAL_CLK_FIX (1)
struct asic_info {
uint32_t nonce;
uint32_t error;
};
struct miner_info {
int thr_id;
int asic_count;
int asic_count_r;
int unit_count;
int temp;
int clock;
int bbg;
bool working;
bool overheated;
uint8_t fw_ver;
uint8_t hw_ver;
uint8_t asic_ver;
uint32_t nonce;
uint32_t error;
double working_diff;
struct asic_info asics[BAIKAL_MAXUNIT][BAIKAL_MAXASICS];
uint8_t work_idx;
struct work *works[BAIKAL_WORK_FIFO];
cgtimer_t start_time;
};
struct baikal_info {
struct pool pool;
int miner_count;
int clock;
uint8_t cutofftemp;
uint8_t fanspeed; // percent
uint8_t recovertemp;
pthread_t *process_thr;
struct miner_info miners[BAIKAL_MAXMINERS];
uint8_t miner_type;
};
typedef struct {
uint8_t miner_id;
uint8_t cmd;
uint8_t param;
uint8_t dest;
uint8_t data[512];
uint32_t len;
} baikal_msg;
#endif /* __DEVICE_BAIKAL_H__ */ If you are already experimenting, then my recommendation is the following for the hardware errors: Set the hardware error handling to 1 in the header file: #define BAIKAL_EN_HWE (1) Comment out the following lines like this: /* #define BAIKAL_MINER_TYPE_NONE (0x00) #define BAIKAL_MINER_TYPE_MINI (0x01) #define BAIKAL_MINER_TYPE_CUBE (0x02) */ Please let me know about the result. |
|
|
|
Have not tried any other algo`s just yet, so i only know that quark works at the moment. However, i see a high rise in hardware errors, on stock sgminer this have always been "0"(Ive had the X10 in only 2 day though). Chip temps are the same as before. Ill see over the night if hashrates are showing up correctly at nicehash. Will continue tomorrow.
Nice job! This is what I call an achievement. If everything is properly configured, then the hardware errors should be 0 on the X10. This indicates a slight misconfiguration in the driver-baikal header file. Probably some of the given values did not belong to the X10, but to another miner. You should also try another pool other than Nicehash. If you are lucky, then your hardware errors might disappear. |
|
|
|
Also while messing with the terminal, an auto generated mail went to the root folder saying
Subject: *** SECURITY information for baikal ***
baikal : Feb 10 07:34:20 : www-data : user NOT in sudoers ; TTY=unknown ;$
From www-data@baikal Fri Feb 10 07:35:24 2017
Return-Path: <www-data@baikal>
Received: from baikal (baikal [127.0.0.1])
by baikal (8.15.2/8.15.2/Debian-3) with ESMTP id v1A7ZOC3017405
for <root@baikal>; Fri, 10 Feb 2017 07:35:24 GMT
Received: (from www-data@localhost)
by baikal (8.15.2/8.15.2/Submit) id v1A7ZOLM017255;
Fri, 10 Feb 2017 07:35:24 GMT
Date: Fri, 10 Feb 2017 07:35:24 GMT
Message-Id: <201702100735.v1A7ZOLM017255@baikal>
To: root@baikal
From: www-data@baikal
Auto-Submitted: auto-generated
Subject: *** SECURITY information for baikal ***
baikal : Feb 10 07:34:24 : www-data : user NOT in sudoers ; TTY=unknown ;$
Don't worry about the mail part. It is the mail service of Ubuntu, which sends a mail to your own device if you log in, or you encounter an error, or security issue, etc. Usually it is just bullshit. |
|
|
|
Of particular interest is this line: msg.data[0] = (clk == 0) ? clk : ((clk / 10) % 20) + 2; It looks like calling baikal_setoption() allows the clock to be set to an arbitrary value. To be honest I don't get the point of this part ((clk / 10) % 20) + 2It just doesn't make any sense to me. If the clock is set to 400 MHz, then the msg.data[0] value will be 2. While if the clock is 300 MHz, then msg.data[0] is 12. What is the logic here? |
|
|
|
I just used photorec to recovery any/all deleted files, then used astrogrep to do some searching. The file names do not correlate. Photorec just gives them a generic name. We'll need more people searching for the other source files, my brain hurts. ;o)
Can someone post the very first image file for the X10? I have v1.0 and v1.1, but was thinking I heard someone mention an earlier one.
Nice find! Actually the c file source code looks like that it belongs to a Giant B based on the static bool baikal_send_work function. And the DEVICE_BAIKAL_H header file that you posted seems to belong to a MINI or CUBE miner. Strange... Could you please upload the v1.0 image file to mega.nz or google drive? |
|
|
|
That just seem the sgminer listing , may be nothing to do with baikal.
Actually it does. This is the source code of the sgminer that has been customized by Baikal. Unfortunately even if you could compile your very own sgminer it wouldn't be enough without modifying the firmware of the microcontroller. I'd like it to be true, but x10 onboard chips must support and match sgminer algos, otherwise I think you will see no accepted shares.
That's right. Otherwise it would be too easy. But at least you have a chance if you know what you are editing in the firmware's binary file. |
|
|
|
I have a question. adra12
If you checked the firmware source code, did you check all three X10 firmware?
I know that there are three firmware versions in October, November, and December.
I have only the firmware in November, December. There is no firmware in October.
All three firmware did not have sgminer source code?
I only have the following image file: PiZero_GX10_171229_V1.1.img And the microcontroller firmware I have is exactly the same like this one: http://leteckaposta.cz/473537086It would be nice to have the previous image, sgminer, firmware files for comparison. |
|
|
|
From the link above, some of the bash history from @adra12: // Open the following file with VIM text editor for editing
vi driver-baikalu.c
// View sgminer CLI
sudo screen -r
// List content
ls
// List content
ls
// Delete this folder
rm -rf sgminer/
That means that sgminer was compiled on the machine, and they deleted the folder with the source code. Still there are no traces of the source code of the firmware. And both of them are needed. |
|
|
|
Isn't the firmware in the flashcard that is used? The sgminer code may also be in that since it would be impractical to embed permanently into a rom, don't you think? Anyone have any experience with this?
By the time you get your miner the firmware is flashed to the microcontroller. You can still obtain it, but it is as useful as the compiled sgminer. You can only edit it with a Hex editor, but development is not possible without the source code. |
|
|
|
Good morning.
Can I apply it in the same way as in url?
Does it work properly on x10?
Is there a command to add SGMINER Options in x10 miner setting?
I would appreciate your reply.
Thank you.
These commands are just for reference if you intend to reverse-engineer their work step by step. Unless you have the source code of sgminer and the firmware, it is pointless to issue the same commands as you don't have the same files. |
|
|
|
So I am guessing that the YAAMP pool software tries to spread the hashrate around instead of just mining the most profitable.
Your observation is correct. This is why I contacted Starpool about a week ago. I noticed that for some reason it is always distributing the hash rate, especially when it comes to Skein or Myr-gr. Which results in lower profits due to mining absolutely non-profitable coins like Myriadcoin and the rest that are always on the bottom, no matter when I check it. |
|
|
|
Which one is the second algo?
Based on the decompiled pseudo code of sgminer there are references to the new algos that are not fully implemented. One of them is NIST and the other is GROESTL. Both of them are treated as the rest of the 10 GH/s algos, so probably the hashing rate will be the same. |
|
|
|
|
They have just released the Baikal N for Cryptonight and it is already obsolete with 20 kH/s. Bitmain announced the X3 with 220 kH/s hashing power. Needless to say what is going to happen with the difficulty of all Cryptonight currencies. Not to mention that almost all of the coin developers are thinking about switching to a non ASIC algorithm instead. It is not worth to buy any of the two miners.
There are algorithms that you shouldn't mess with. Ethash and Cryptonight are good examples for this.
|
|
|
|
MPH indicate CURRENT profitability per GH, not 24H approximate.
Thanks for the info, good to know. |
|
|
|
|
