Take a look:
https://bitcointalk.org/index.php?topic=2790982.msg33090927#msg33090927

It's a bug in sgminer. It should be something like
instead. However it doesn't really matter (for the reasons mentioned in my last post) so I didn't bother correcting it in the version I posted.

For clarification to anyone who is thinking their miner is overclocked or underclocked by looking only at the hash rate sgminer reports:

As defined by the baikal_hash_done() function in sgminer:driver-baikalu.c:


Note: clock is hardcoded in sgminer (see #define BAIKAL_CLK_DEF in sgminer:driver-baikal.h)


example (single hashboard):
clock = 300MHz
ASICs = 64
ALGO = Groestl, so modifier = 120
therefore 300 * 64 * 120 / 1000000 = 2.304 (GHz)

Note that the hash rate value you see reported by sgminer is not based on what the hash rate actually is, but rather what it should be (given all your ASICs are working and everything is stock). Imagine you did a 200% hardware overclock without any software changes - sgminer would still report the original hash rate because it would still be using the same hardcoded BAIKAL_CLK_DEF, see the same number of ASICs, and be on the same algorithm (i.e. the only inputs to the hash rate calculation as explained above). If you want, it's trivial to modify the web interface code or sgminer to display an arbitrary hash rate but it does not mean you're actually getting that hash rate. sgminer does not get any direct feedback from the STM controller regarding the actual hash rate. If you really want to know your true hash rate, check the pool you're mining at. They'll use the number of accepted shares vs. time & difficulty to calculate your actual hash rate.

BAIKAL_CLK_DEF is sent to the STM, but it does not actually set the hashing speed.

That all looks good except for the checksum of the bin file you're using. I'm getting b7ee4ca88a190fb086655761e1f55c6c for the stock v1.2 file. I'd try pulling the file from the v1.2 OrangePi image and try again. Remember to revert back to the stock v1.2 sgminer too.

At least the STM shows up for you! That's better than the problem chup has.

Is 0483:5740 STMicroelectronics STM32F407 the result you have currently? If so, are you also saying you do not see the blue LED at all? IF the STM has my firmware, AND it is in RUN mode (as your last result would indicate), AND sgminer is not running (as indicated by your previous post where you ran the miner-stop script), then the blue LED should be flashing (especially if you also ran the reset_stm script as previously indicated).

Try this next if you would:

• Put the desired .bin firmware file in /media/boot
• Make sure the filename starts with a capital G
• Run md5sum /media/boot/G*.bin    -what is the result?
• Run python /usr/bin/update_fw.py   & please post the entire output of that command

What does this command show when you run it?
Either there's nothing, or something with "STMicroelectronics" in it.

Same question as to chup: What was the last firmware you successfully flashed (the one I posted? flexmeister's? One of the stock images?)

Not getting any STM devices in that list is pretty odd. Obviously if you haven't tried you should completely power cycle the miner and try again. In order to determine if the problem lies with the OrangePi or STM you could do this:

• Remove the OrangePi from the controller board (important). Leave the Ethernet connected.
• Use a USB cable to connect the USB device connector on the controller board with the USB A host port on the Orange Pi
• Use another USB cable to connect the Orange Pi's micro USB port to any other powered device's USB host port (to power the Orange Pi)
• Run the lsusb | grep 0483 command again.

A working setup will show the STM device on Bus 006 (not 007 like when the OrangePi is seated on the controller board directly). If this time you DO get something, then the USB port on the Pi pin headers isn't working, but the STM probably is. If you still get nothing, you could swap controller boards with another Baikal Giant miner (if you have another) and try again.

What was the last firmware you successfully flashed (the one I posted? flexmeister's? One of the stock images?)

Spending a lot of time poking at the miner. You'll need to have a decent background in software & hardware.


I had just spent several months of my free time reverse engineering with the collaborator so a few months of slightly higher profit mining helped make me feel a little better about trading a small part of my life away for it.


Looks like I have a comment in the firmware for keccak saying "experimental" so I don't think I got it working, although I don't remember putting much time into figuring out why not.


I can only vouch for Groestl with the software I posted.


From these quotes I'm not sure if there are actual "bricking" problems or if people are just having trouble with the steps to change firmware. I will confirm that I am able to rollback firmware from the firmware image I posted. If ONLY the red LEDs are showing, then that should mean the control board is in firmware update mode. If the red LEDs are on and you see a blue flashing LED, then the control board is in RUN mode but sgminer has not given it work to do (either sgminer died or the pools are all down, etc). If you see blue solid LEDs then it's hashing. If you don't see any LEDs then your device is not powered .

If you run update_fw.py and get:
you can try editing the update_fw.py script by commenting out (adding a "#" at the start of the line) the last couple lines:
Run the modified script and it should have reset the STM and left it in firmware update mode. Then run:
And the result sholuld be this:
(the "device" number will vary)
If instead you get:
we'll have to go from there.

Thank you for the speed confirmations. I attempted to replicate the behavior of the original firmware as much as possible, but obviously came up short somewhere. Besides fixing the firmware to bring the speed up to stock rates, there are likely a few more optimizations that might bring it up to, say, 110% stock speed. I don't have the time required to work on this at the moment, and I'm not sure when I'll get that time.


Now that I think of it I may not have tested Skein2 on a pool. I may have just compared the hash output to what the expected hash should have been and saw it matched Skein2. I concur with chup that it probably isn't worth investigating since there doesn't seem to be much coin support for it anyway. I apologize for advertising Skein2 support originally when it wasn't fully tested.


Personally since about May, on a single hash board. At that time I needed to transition to another unrelated project and promptly forgot all about crypto for a few months. flexmeister wasn't the collaborator I was originally referring to and I'm guessing only for a few days for them since their solution seems to use the same firmware & sgminer that I posted, if I'm not mistaken. Here's a screenshot of the Groestlcoin network hash rate around that time:


Sure thing: https://drive.google.com/open?id=1c6klf2gfuawZqOiOC7cHuWijc_iUxqXc . I apologize for not having the time to do this earlier.


astraleureka would you care to share more of your knowledge on the X10? Were you contributing to the large jumps in Groestlcoin hash rate earlier in the year ? Any other algos you've found? How much of an overclock were you able to achieve?


flexmeister does this mean you were able to fix the hash rate and boost it up to stock speeds? My custom firmware runs slower than stock so if you found a solution I'd be happy to hear how you fixed it.


Thanks for the acknowledgement. I appreciate the offer but I'll politely decline. I think I'd feel kinda dirty accepting a share, but thank you regardless.

If you have any others you could try swapping a known good Orange Pi/controller board with one of the ones that don't work. If only the Orange Pi or controller board died you're in luck since those are easy to replace (Baikal sells them separately if you contact them). If the hash boards died you may not be able to repair them depending on if the ASICs themselves fried of if it was any of the other components.

If that hash board looks corroded have you checked all your other equipment in your mining shed? It might be worth converting your shed to use closed-loop cooling so you could remove the heat without transferring air directly from/to outside.

Do you think you'll be able to clean/repair the corroded board and get it working again?

If you don't mind directly editing the miner.conf file for pool settings then only two files are required to be copied:


If you want to be able to use the web interface for modifying your pools then a bit more work is required, but I haven't looked into it. After you've copied the new firmware file you can run:

Updating sgminer and the STM firmware seems to be all that is needed. Both are obviously found in the new image file using something like 7zip to open the archive, then browse to 1.img/opt/bin/scripta/sgminer and 0.fat/GX10.bin. Copy both to your X10, the GX10 file should go in /media/boot. Rebooting should auto-update the STM firmware.

Remember to do
after you've replaced the old version.

From the new image:


Covering their tracks this time, then making sure the secure delete worked using the same program used on this thread to extract deleted files. Hi Baikal!

Interesting!

• How many people have confirmed with you that a modified sgminer can overclock a Giant B?
• Did they share their code changes/improvements with you or give you any idea of what they did?
• What method did they use to measure the 10-15% increase in hash rate?
• What do you have in mind for further software changes in order to boost the OC higher?

How much current does your overclocked miner draw compared to the stock unmodified miner? Did you find that using 16VDC was necessary or is that only what you had available?



Did you actually try doing that modification?

It seems to me like they're using a lookup table of clock settings to get actual speeds (https://bitcointalk.org/index.php?topic=2790982.msg33090927#msg33090927). If true the max speed might be 490, for a 490/440= 11% overclock (vs 440 stock x10).

Nicely done! How many different source files did you need to find and/or modify? When you call baikal_setoption() what arguments do you use? Do you plan on open-sourcing the work you've done or listing the modifications you had to make?

[divide by 10] indicates 10MHz increments, [mod 20] indicates a lookup table with 20 items, [+ 2] indicates the list begins at index #2:


Not sure whether, for example, #7 would give 450 or 250MHz - an experiment is needed.

Thanks. Now I'm interested in:

In a different file:

Looks like this is a pretty old version of the source as that list doesn't contain Skein or MGroestl, as the x10 is known to have. This looks like the same list of algorithms that Baikal's older Mini Miner and Giant A900 Dash Miner had so it may not have any new code at all for the x10/B/N (in this deleted version). Maybe it's just as easy as adding a few cases in there for the missing ones and using guess-and-check to get the right values.