Pages:
Author

Topic: ROCKMINER ASIC miner official thread - page 21. (Read 199664 times)

legendary
Activity: 3374
Merit: 1859
Curmudgeonly hardware guy
September 04, 2014, 12:50:51 PM
Novak is our resident tech wizard, case anyone's wondering. We were already looking into this issue and have no problem helping someone else out that's already farther down the path.
full member
Activity: 173
Merit: 100
September 04, 2014, 12:03:32 PM
Note how it prints "devpath (rsz)", and in your picture rsz is zero.  Makes it seem like you've got nothing, and none of the other code that it goes through seems to do any serial comm either.  Why would this error happen?  The most likely answer is differing serial parameters, either different baud rate, or parity bits, or something along those lines.  

Since this is based off the open source X24 design then I would check https://github.com/blockerupter/avr_hbc for UART parameters.  Once you confirm that data is transfered, the next step is to see if the serial protocol is similar enough based on the commands in the X24 AVR design spec or if we need a totally custom driver.  Based on the issues we've seen thus far, it would not surprise me if they had totally unrelated communication methods.


From some hacking around in cgminer, I think I've determined I am getting no serial comm whatsoever.  I guess hooking up the tx/rx/GND lines aren't enough. Sad

I only have a rudimentary knowledge of the hardware part.  Any idea how one would wire up the adapter I linked earlier?

I think you have it wired correctly, those should be the only lines you need.  I've checked tubes and it is a UART connection, using those wires.  The thing is that UART is simpler and older than USB, just plugging in the wire doesn't necessarily mean you can talk.  On the ASICminer tubes I've seen a 11.0592 MHz crystal, which is apparently used as the AVR clock and divided, (from here https://github.com/blockerupter/avr_hbc/blob/master/BE200S.c#L232) to get serial baud rate.  It looks like, according to the same data source that a 9 bit mode is used, which according to here: (www.atmel.com/images/doc8025.pdf) is a single stop bit.  Looks like baud should be 11059200/(8*(UBRRn+1), and based off a UBRRn of 2, should be equal to 460800.  You should be able to use those serial parameters to at least get the chip to say hello, even if your reply is based on the wrong drivers (the more I look, the more I would say rockminer drivers have nothing to do with X24 drivers, though that is not necessarily the case.)

So try this for your serial port:
baud rate: 460800
data bits: 8
stop bits: 1

See if you can at least get a single read- that would imply that your serial port is correctly configured, even if the drivers are wrong.


--
novak
hero member
Activity: 728
Merit: 500
cryptoshark
September 04, 2014, 11:45:08 AM
i have noticed that one of my r4/r3 boards are dropping constantly.
reboot solve issue for while.
is it sign that one of boards is dying?

thanks.
full member
Activity: 145
Merit: 100
September 04, 2014, 11:24:15 AM
Note how it prints "devpath (rsz)", and in your picture rsz is zero.  Makes it seem like you've got nothing, and none of the other code that it goes through seems to do any serial comm either.  Why would this error happen?  The most likely answer is differing serial parameters, either different baud rate, or parity bits, or something along those lines.  

Since this is based off the open source X24 design then I would check https://github.com/blockerupter/avr_hbc for UART parameters.  Once you confirm that data is transfered, the next step is to see if the serial protocol is similar enough based on the commands in the X24 AVR design spec or if we need a totally custom driver.  Based on the issues we've seen thus far, it would not surprise me if they had totally unrelated communication methods.


From some hacking around in cgminer, I think I've determined I am getting no serial comm whatsoever.  I guess hooking up the tx/rx/GND lines aren't enough. Sad

I only have a rudimentary knowledge of the hardware part.  Any idea how one would wire up the adapter I linked earlier?
legendary
Activity: 896
Merit: 1001
September 04, 2014, 11:01:22 AM
Any financial updates or updates on new miners?
full member
Activity: 173
Merit: 100
September 04, 2014, 10:16:02 AM
I got my USB-UART converter, wired it up, programmed it as a "Rockminer T1" device, added that product info as an identifying factor in BFGMiners drive-rockminer.c, upped ,the chipcount_max to 128, and...



What would cause a "short read?"  That seems to be where it errors out.  That part of the code is nebulous.  Anyone who knows more about bfgminer/cgminer source willing to help?  I'd really like to get this working with a third party controller.

Rockxie, if you could provide the source code you used for your cgminer/bfgminer build incorperated into the Block Erupter controller, this would be very helpful in my efforts!

Thanks in advance!  You might not be able to tell from my comments above, but this is constructive criticism.  I really do like your product!

This seems to be the segment of code that fails, for reference:

Code:
static
bool rockminer_detect_one(const char * const devpath)
{
int fd, chips;
uint8_t buf[ROCKMINER_WORK_REQ_SIZE], reply[ROCKMINER_REPLY_SIZE];
ssize_t rsz;

fd = rockminer_open(devpath);
if (fd < 0)
return_via_applog(err, , LOG_DEBUG, "%s: %s %s", rockminer_drv.dname, "Failed to open", devpath);

applog(LOG_DEBUG, "%s: %s %s", rockminer_drv.dname, "Successfully opened", devpath);

rockminer_job_buf_init(buf, 0);
rockminer_job_buf_set_freq(buf, ROCKMINER_MIN_FREQ_MHZ);
memcpy(&buf[   0], golden_midstate, 0x20);
memcpy(&buf[0x34], golden_datatail,  0xc);

if (rockminer_write(fd, buf, sizeof(buf)) != sizeof(buf))
return_via_applog(err, , LOG_DEBUG, "%s: %s %s", rockminer_drv.dname, "Error sending request to ", devpath);

while (true)
{
rsz = rockminer_read(fd, reply, sizeof(reply));
if (rsz != sizeof(reply))
return_via_applog(err, , LOG_DEBUG, "%s: Short read from %s (%d)", rockminer_drv.dname, devpath, rsz);
if ((!memcmp(reply, golden_result, sizeof(golden_result))) && (reply[4] & 0xf) == ROCKMINER_REPLY_NONCE_FOUND)
break;
}

applog(LOG_DEBUG, "%s: Found chip 0 on %s, probing for total chip count", rockminer_drv.dname, devpath);
chips = rockminer_bisect_chips(fd, buf);
applog(LOG_DEBUG, "%s: Identified %d chips on %s", rockminer_drv.dname, chips, devpath);

if (serial_claim_v(devpath, &rockminer_drv))
goto err;

serial_close(fd);

struct cgpu_info * const cgpu = malloc(sizeof(*cgpu));
*cgpu = (struct cgpu_info){
.drv = &rockminer_drv,
.set_device_funcs = rockminer_set_device_funcs,
.device_path = strdup(devpath),
.deven = DEV_ENABLED,
.procs = chips,
.threads = 1,
};
// NOTE: Xcode's clang has a bug where it cannot find fields inside anonymous unions (more details in fpgautils)
cgpu->device_fd = -1;

return add_cgpu(cgpu);

err:
if (fd >= 0)
serial_close(fd);
return false;
}

I don't have rockminer gear but we have some of the ASICminer tubes, so I've been poking around in this.  I don't have your USB->UART connector either or I'd probably fire it up but I can see some stuff to look at immediately.  Here's what I would check though.

1.  Check rsz versus sizeof(reply)

Code:
rsz = rockminer_read(fd, reply, sizeof(reply));

All you know is that those are not equal.  What should sizeof(reply) be?

2.  I'm pretty sure you've got no communication between USB and your chips.  Check out how it checks successful opening:
Code:
fd = rockminer_open(devpath);
if (fd < 0)
return_via_applog(err, , LOG_DEBUG, "%s: %s %s", rockminer_drv.dname, "Failed to open", devpath);

All you know is that it was able to get a file lock on the device file, you have no idea if it can communicate or not.  Judging by the error message, I'd say not.

Code:
return_via_applog(err, , LOG_DEBUG, "%s: Short read from %s (%d)", rockminer_drv.dname, devpath, rsz);

Note how it prints "devpath (rsz)", and in your picture rsz is zero.  Makes it seem like you've got nothing, and none of the other code that it goes through seems to do any serial comm either.  Why would this error happen?  The most likely answer is differing serial parameters, either different baud rate, or parity bits, or something along those lines. 

Since this is based off the open source X24 design then I would check https://github.com/blockerupter/avr_hbc for UART parameters.  Once you confirm that data is transfered, the next step is to see if the serial protocol is similar enough based on the commands in the X24 AVR design spec or if we need a totally custom driver.  Based on the issues we've seen thus far, it would not surprise me if they had totally unrelated communication methods.

Just for completeness, here's what "rockminer_open" calls- I don't see any serial comm, just getting a file lock.

Code:
int rockminer_open(const char *devpath)
{
return serial_open(devpath, ROCKMINER_IO_SPEED, ROCKMINER_READ_TIMEOUT, true);
}

And that calls:

Code:
int serial_open(const char *devpath, unsigned long baud, uint8_t timeout, bool purge)
{
#ifdef WIN32
HANDLE hSerial = CreateFile(devpath, GENERIC_READ | GENERIC_WRITE, 0, NULL, OPEN_EXISTING, 0, NULL);
if (unlikely(hSerial == INVALID_HANDLE_VALUE))
{
DWORD e = GetLastError();
switch (e) {
case ERROR_ACCESS_DENIED:
applog(LOG_ERR, "Do not have user privileges required to open %s", devpath);
break;
case ERROR_SHARING_VIOLATION:
applog(LOG_ERR, "%s is already in use by another process", devpath);
break;
default:
applog(LOG_DEBUG, "Open %s failed, GetLastError:%u", devpath, (unsigned)e);
break;
}
return -1;
}
if (baud)
{
COMMCONFIG comCfg = {0};
comCfg.dwSize = sizeof(COMMCONFIG);
comCfg.wVersion = 1;
comCfg.dcb.DCBlength = sizeof(DCB);
comCfg.dcb.BaudRate = baud;
comCfg.dcb.fBinary = 1;
comCfg.dcb.fDtrControl = DTR_CONTROL_ENABLE;
comCfg.dcb.fRtsControl = RTS_CONTROL_ENABLE;
comCfg.dcb.ByteSize = 8;
SetCommConfig(hSerial, &comCfg, sizeof(comCfg));
}
// Code must specify a valid timeout value (0 means don't timeout)
const DWORD ctoms = ((DWORD)timeout * 100);
COMMTIMEOUTS cto = {ctoms, 0, ctoms, 0, ctoms};
SetCommTimeouts(hSerial, &cto);
if (purge) {
PurgeComm(hSerial, PURGE_RXABORT);
PurgeComm(hSerial, PURGE_TXABORT);
PurgeComm(hSerial, PURGE_RXCLEAR);
PurgeComm(hSerial, PURGE_TXCLEAR);
}
return _open_osfhandle((intptr_t)hSerial, 0);
#else
int fdDev = open(devpath, O_RDWR | O_CLOEXEC | O_NOCTTY);
if (unlikely(fdDev == -1))
{
if (errno == EACCES)
applog(LOG_ERR, "Do not have user privileges required to open %s", devpath);
else
applog(LOG_DEBUG, "Open %s failed: %s", devpath, bfg_strerror(errno, BST_ERRNO));
return -1;
}
#if defined(LOCK_EX) && defined(LOCK_NB)
if (likely(!flock(fdDev, LOCK_EX | LOCK_NB)))
applog(LOG_DEBUG, "Acquired exclusive advisory lock on %s", devpath);
else
if (errno == EWOULDBLOCK)
{
applog(LOG_ERR, "%s is already in use by another process", devpath);
close(fdDev);
return -1;
}
else
applog(LOG_WARNING, "Failed to acquire exclusive lock on %s: %s (ignoring)", devpath, bfg_strerror(errno, BST_ERRNO));
#endif
struct termios my_termios;
tcgetattr(fdDev, &my_termios);
#ifdef TERMIOS_DEBUG
termios_debug(devpath, &my_termios, "before");
#endif
if (baud)
{
speed_t speed = tiospeed_t(baud);
if (speed == B0)
applog(LOG_WARNING, "Unrecognized baud rate: %lu", baud);
else
{
cfsetispeed(&my_termios, speed);
cfsetospeed(&my_termios, speed);
}
}
my_termios.c_cflag &= ~(CSIZE | PARENB);
my_termios.c_cflag |= CS8;
my_termios.c_cflag |= CREAD;
#ifdef USE_AVALON
// my_termios.c_cflag |= CRTSCTS;
#endif
my_termios.c_cflag |= CLOCAL;
my_termios.c_iflag &= ~(IGNBRK | BRKINT | PARMRK |
ISTRIP | INLCR | IGNCR | ICRNL | IXON);
my_termios.c_oflag &= ~OPOST;
my_termios.c_lflag &= ~(ECHO | ECHONL | ICANON | ISIG | IEXTEN);
// Code must specify a valid timeout value (0 means don't timeout)
my_termios.c_cc[VTIME] = (cc_t)timeout;
my_termios.c_cc[VMIN] = 0;
#ifdef TERMIOS_DEBUG
termios_debug(devpath, &my_termios, "settings");
#endif
tcsetattr(fdDev, TCSANOW, &my_termios);
#ifdef TERMIOS_DEBUG
tcgetattr(fdDev, &my_termios);
termios_debug(devpath, &my_termios, "after");
#endif
if (purge)
tcflush(fdDev, TCIOFLUSH);
return fdDev;
#endif
}



--
novak
full member
Activity: 145
Merit: 100
September 03, 2014, 08:20:42 PM
Rockminer, is there any chance to getting answers about my requests for input on developing a cgminer driver?  Huh
sr. member
Activity: 322
Merit: 250
3D Printed!
August 31, 2014, 01:45:35 PM
Two good news coming

1. Gift NEW RBOX to you!
People who has platform to show our product, tech guys, online shop, medias etc,can apply our new product NEW RBOX for free.
We'll gift one NEW RBOX to everyone who can prove his ability to show that miner.
If you are interested in the showing, pls PM me or email [email protected], we'll ship out NEW RBOX this month.

2. Good news for NEW RBOX and RBOX by mining MED
People who is interested in the new crypto currency, MED, can get ROI by using RBOX or NEW RBOX to get coins!!!!
MED team contacted us, after long term researched, they found only ROCKMINER RBOX is the Bitcoin miner which can mine MED!!!!
People who wanna learn more about mining MED can contact the official service of MED or ROCKMINER.
BTW, NEW RBOX can also do this by tech setting.

Hi
Any updates for Rockhash.com and their participants?
I emailed 2 weeks ago about new stuff and still no answer.
When project will be terminated or expanded?

thanks

Dang, I forgot about Rockhash.com...need to get my RK-Box on there, even if just in shifts depending on how it works.
hero member
Activity: 728
Merit: 500
cryptoshark
August 31, 2014, 09:35:40 AM
Two good news coming

1. Gift NEW RBOX to you!
People who has platform to show our product, tech guys, online shop, medias etc,can apply our new product NEW RBOX for free.
We'll gift one NEW RBOX to everyone who can prove his ability to show that miner.
If you are interested in the showing, pls PM me or email [email protected], we'll ship out NEW RBOX this month.

2. Good news for NEW RBOX and RBOX by mining MED
People who is interested in the new crypto currency, MED, can get ROI by using RBOX or NEW RBOX to get coins!!!!
MED team contacted us, after long term researched, they found only ROCKMINER RBOX is the Bitcoin miner which can mine MED!!!!
People who wanna learn more about mining MED can contact the official service of MED or ROCKMINER.
BTW, NEW RBOX can also do this by tech setting.

Hi
Any updates for Rockhash.com and their participants?
I emailed 2 weeks ago about new stuff and still no answer.
When project will be terminated or expanded?

thanks
full member
Activity: 145
Merit: 100
August 31, 2014, 12:19:17 AM
^^^ Nice work so far bro! Keep on rockin!

Thanks...  though I am not rockin' so much as stumbling through the dark.  Cheesy

Anyhow, I'm switching to cgminer to see if maybe the codebase there is more flexible or even understandable...  We'll see...

EDIT:  I am starting to wonder if I have the UART pins hooked up wrong.  It's just ground and TX+RX right?

EDIT EDIT:  Giving up for now and switching back to my control (which still won't resolve DNS queries at all for some reason)...

I'd really like to get this working, but it seems beyond my skillset, at least on my own. Sad
sr. member
Activity: 322
Merit: 250
3D Printed!
August 30, 2014, 11:26:09 PM
^^^ Nice work so far bro! Keep on rockin!
full member
Activity: 145
Merit: 100
August 30, 2014, 09:58:42 PM
I got my USB-UART converter, wired it up, programmed it as a "Rockminer T1" device, added that product info as an identifying factor in BFGMiners drive-rockminer.c, upped ,the chipcount_max to 128, and...



What would cause a "short read?"  That seems to be where it errors out.  That part of the code is nebulous.  Anyone who knows more about bfgminer/cgminer source willing to help?  I'd really like to get this working with a third party controller.

Rockxie, if you could provide the source code you used for your cgminer/bfgminer build incorperated into the Block Erupter controller, this would be very helpful in my efforts!

Thanks in advance!  You might not be able to tell from my comments above, but this is constructive criticism.  I really do like your product!

This seems to be the segment of code that fails, for reference:

Code:
static
bool rockminer_detect_one(const char * const devpath)
{
int fd, chips;
uint8_t buf[ROCKMINER_WORK_REQ_SIZE], reply[ROCKMINER_REPLY_SIZE];
ssize_t rsz;

fd = rockminer_open(devpath);
if (fd < 0)
return_via_applog(err, , LOG_DEBUG, "%s: %s %s", rockminer_drv.dname, "Failed to open", devpath);

applog(LOG_DEBUG, "%s: %s %s", rockminer_drv.dname, "Successfully opened", devpath);

rockminer_job_buf_init(buf, 0);
rockminer_job_buf_set_freq(buf, ROCKMINER_MIN_FREQ_MHZ);
memcpy(&buf[   0], golden_midstate, 0x20);
memcpy(&buf[0x34], golden_datatail,  0xc);

if (rockminer_write(fd, buf, sizeof(buf)) != sizeof(buf))
return_via_applog(err, , LOG_DEBUG, "%s: %s %s", rockminer_drv.dname, "Error sending request to ", devpath);

while (true)
{
rsz = rockminer_read(fd, reply, sizeof(reply));
if (rsz != sizeof(reply))
return_via_applog(err, , LOG_DEBUG, "%s: Short read from %s (%d)", rockminer_drv.dname, devpath, rsz);
if ((!memcmp(reply, golden_result, sizeof(golden_result))) && (reply[4] & 0xf) == ROCKMINER_REPLY_NONCE_FOUND)
break;
}

applog(LOG_DEBUG, "%s: Found chip 0 on %s, probing for total chip count", rockminer_drv.dname, devpath);
chips = rockminer_bisect_chips(fd, buf);
applog(LOG_DEBUG, "%s: Identified %d chips on %s", rockminer_drv.dname, chips, devpath);

if (serial_claim_v(devpath, &rockminer_drv))
goto err;

serial_close(fd);

struct cgpu_info * const cgpu = malloc(sizeof(*cgpu));
*cgpu = (struct cgpu_info){
.drv = &rockminer_drv,
.set_device_funcs = rockminer_set_device_funcs,
.device_path = strdup(devpath),
.deven = DEV_ENABLED,
.procs = chips,
.threads = 1,
};
// NOTE: Xcode's clang has a bug where it cannot find fields inside anonymous unions (more details in fpgautils)
cgpu->device_fd = -1;

return add_cgpu(cgpu);

err:
if (fd >= 0)
serial_close(fd);
return false;
}
full member
Activity: 145
Merit: 100
August 29, 2014, 10:22:14 PM
I wish I could say I liked the controller that comes with this, but I don't.  It's a piece of junk for any pool but BTCGUILD...  Heck, I even had trouble getting it to work with BTCGUILD.  I had to use the default ip that came with it (50.31.149.57).  (BTC-Guild for reference doesn't even list that ip...)  Attempts to connect to ANY other ip OR dns name are failing, showing all boards hashing at 0.  Don't know what the story with that is.  At least it's working for my BTCguild account and not the default worker that's inputted, lol.

I'm going to be trying hooking this thing up to a USB->SERIAL CP2102 adapter this weekend, and using generic BFGminer.  Anyone interested in this possibility may want to watch this space for a full status report.  I suspect the existing rockminer driver will need some hacking, but I think it can be done.

Here is the part I bought to try this, for reference:

http://www.ebay.com/itm/181088668352

My miner however, I am quite happy with.  Just get a raspi controller and get rid of that block erupter thing, I can't stand it.
member
Activity: 60
Merit: 10
August 29, 2014, 12:58:28 PM

   Was wondering what the schedule for financial reports and divs were moving forward?

Update:

1. ROCKMINER Operational Progress and Financial Report
https://drive.google.com/file/d/0BwVxGR-76wFeeVplZ3YyeGFxWkU/edit?usp=sharing

2. Dividend
Receiver: ROCKMINER public IPO shareholders.
Amount: 18.75BTC
Date: July 29, 2014 (Beijing Time, GMT+8)



ROCKMINER IPO


Dividend:
Initial dividend: depends on the chips delivery date of ASCMINER ,in May around.
Total Amount of Dividend: the profit after deducting the profits retained within ROCKMINER.
Time and Frequency for Dividend: Dividends will be paid out on Wednesday every two weeks.


 
 

   
 
sr. member
Activity: 284
Merit: 254
August 28, 2014, 03:08:40 AM

Thank you, Dogie, you did so many amazing works for ROCKMINER.
legendary
Activity: 1288
Merit: 1004
August 27, 2014, 04:39:54 PM
Thanks for getting me the T1 so quickly so I could get the word out about them.
It is a nice running miner.


Dear All,

Thanks for all your words to ROCKMINER about T1.
1. We said that T1 is based on the solution by FC in lots of days ago, that's why someone doubt its not our product.
2. For the interview by ManeBjorn, its just the prototype one without cage.
sr. member
Activity: 284
Merit: 254
August 27, 2014, 11:04:21 AM
Two good news coming

1. Gift NEW RBOX to you!
People who has platform to show our product, tech guys, online shop, medias etc,can apply our new product NEW RBOX for free.
We'll gift one NEW RBOX to everyone who can prove his ability to show that miner.
If you are interested in the showing, pls PM me or email [email protected], we'll ship out NEW RBOX this month.

2. Good news for NEW RBOX and RBOX by mining MED
People who is interested in the new crypto currency, MED, can get ROI by using RBOX or NEW RBOX to get coins!!!!
MED team contacted us, after long term researched, they found only ROCKMINER RBOX is the Bitcoin miner which can mine MED!!!!
People who wanna learn more about mining MED can contact the official service of MED or ROCKMINER.
BTW, NEW RBOX can also do this by tech setting.
sr. member
Activity: 284
Merit: 254
August 27, 2014, 10:50:33 AM
Dear All,

Thanks for all your words to ROCKMINER about T1.
1. We said that T1 is based on the solution by FC in lots of days ago, that's why someone doubt its not our product.
2. For the interview by ManeBjorn, its just the prototype one without cage.
legendary
Activity: 1666
Merit: 1185
dogiecoin.com
newbie
Activity: 10
Merit: 0
August 27, 2014, 10:10:14 AM
Regarding the HW errors:

From what I can tell, it appears to be a display glitch. If a board drops out it would be indicated on the test status page, I assume. Unless there's a display glitch on that page also.

Slush's pool reports roughly the same hashing rate as the controller status page. I can't seem to find the rejects anywhere on the pool site.

Pages:
Jump to: