|
Hi everyone,
I'm using 0.10.3 version because it is the latest which works fine on my XP server.
I plan to upgrade soon but now the client downloading the blockchain.
When i install the last release will this blockchain will be accepted by a latest release?
Thanks,
|
|
|
|
Что, всё, сдуваемся? Или 380 таки будет? (я не про рубль  ) Думаю выше 380 не пойдем в ближайшие 2 дня. |
|
|
|
Пик
Это наверно переводки из жвачки.  Да нет там нацистов, я укрновости читаю и знаю. А в рашановости одни постановки. Как говорится Путин ПНХ. Флаг имперский думаю все заметили. Это один из так называемых борцов с фашистами бендеровцами. Отважный воин луГАНДОНской народной республики. Опля! "У нас нет нацистов"
с какой поры националисты стали нацистами? |
|
|
|
Мое мнение, что они скупают монеты за $ по нынешней бросовой цене.
Так отчего тогда цена снижается? |
|
|
|
|
битфури собирался новый чип делать. Есть новости?
|
|
|
|
Что это за лошарская контора которая начисляет дивиденды (за что?!). Чем быстрее накроются такие шараги тем лучше. имхо |
|
|
|
Штаты на грани дефолта.
Уткуда инфа? |
|
|
|
Hope this does not demotivate you, but getting this issue stable was the hardest part with the boards at Bitmine.
Good Luck
Oh, Things are getting more interesting. Thanks. I have configured the chip at 250MHZ system clock and 16MHz reference clock. pre_div=2, post_div=4, fb_div=125: 0x88 0x7d 0x21 0x84 0x00 0x00 So the hashing speed is supposed to be 250MHZ* 32 cores = 8000 MH/s Am i correct? So maybe i need to reconfigure at a lower system clock? To make it work stable. I think the naming for post and pre divider were reversed in an earlier version of documentation / software, but basically yes, this should set the sys_clock to 250MHz. If unsure, you always can double-check by scoping the inter-chip SPI clock, which is sys_clk/64, so at 250MHz you should get ~3.9MHz. Note: take care to configure your host SPI clock below the inter-chip SPI clock, i.e. in this case configure your RPi SPI interface below 3.9MHz. I have checked the SPI. It shows 16MHZ . So i'm running the chip at 1024MHZ clock. There is one thing o don't understand in the datasheet. Here is the register: https://www.dropbox.com/s/45w9ta19af7y1fl/A1_registry.JPGIt is 48 bit but the numbering goes from 0 to 46. It is correct? I will program the dividers |
|
|
|
Hope this does not demotivate you, but getting this issue stable was the hardest part with the boards at Bitmine.
Good Luck
Oh, Things are getting more interesting. Thanks. I have configured the chip at 250MHZ system clock and 16MHz reference clock. pre_div=2, post_div=4, fb_div=125: 0x88 0x7d 0x21 0x84 0x00 0x00 So the hashing speed is supposed to be 250MHZ* 32 cores = 8000 MH/s Am i correct? So maybe i need to reconfigure at a lower system clock? To make it work stable. |
|
|
|
I'm using raspi driver with one chip. The chips starts hashing ok but after a while (30s) it stopes. I have examined the log and i have found that the problem is in the scanwork function. Here is the log: [2014-03-16 11:36:49] Processing command 0x0800
[2014-03-16 11:36:49] TX: 2 bytes:08 00
[2014-03-16 11:36:49] RX: 2 bytes:00 00
[2014-03-16 11:36:49] RX: 2 bytes:00 00
[2014-03-16 11:36:49] RX: 2 bytes:08 00
[2014-03-16 11:36:49] Output queue empty
[2014-03-16 11:36:49] Processing command 0x0a01
[2014-03-16 11:36:49] TX: 2 bytes:0A 01
[2014-03-16 11:36:49] RX: 2 bytes:00 00
[2014-03-16 11:36:49] RX: 2 bytes:00 00
[2014-03-16 11:36:49] RX: 2 bytes:0A 01
[2014-03-16 11:36:49] RX: 2 bytes:00 00
[2014-03-16 11:36:49] Failure: missing ACK for cmd 0x1a
[2014-03-16 11:36:49] Failed to read reg from chip 0
[2014-03-16 11:36:49] Processing command 0x0a01
[2014-03-16 11:36:49] TX: 2 bytes:0A 01
[2014-03-16 11:36:49] RX: 2 bytes:00 00
[2014-03-16 11:36:49] RX: 2 bytes:00 00
[2014-03-16 11:36:49] RX: 2 bytes:0A 01
[2014-03-16 11:36:49] RX: 2 bytes:00 00
[2014-03-16 11:36:49] Failure: missing ACK for cmd 0x1a
[2014-03-16 11:36:49] Disabling chip 1
We see that the registry values cannot be read. |
|
|
|
|
I have connected oscilloscope to the DO pin. On power up it shows 0.82V const. The Vddcore is 0.84V.
When cgminer is running it is still 0.82 const.
Does anyone saw such level?
|
|
|
|
...
If you still don't get any feedback from the chip, please double check that the RSTn is kept at 18V for at least 1s before your first command to the chip.
...
I think you mean 1.8V ! Sure 1.8V. But from the datasheet it states that signal is active low. So it must be kept for 1s 0V. Or do you mean that after it goes 0V for 1s it must be kept at 1.8V for another 1s before first command? |
|
|
|
Having some trouble with getting 0x04 responce on the 0x04 reset command.
I'm doing the HW reset as described. The signals from raspi passed through level shifters.
Chip select DI CLK are ok. I see 0x04 passing into the chip but there is nothing at the output.
The VDDcore is 0.7 volts. Maybe it is too low?
That's pretty likely too low. I had similar issues when I was running the chip that low. 0.8V seems to be pretty reliable for at least basic comms for most chips. A couple wouldn't hash at that voltage but once I brought it up to about 0.84V they were fine. Of course, now those chips run hotter than the others  I have just tested with 0.84V. Still no responce. zefir mentioned earlier that at the startup chip is configured at 12MHz reference clock. And the SPI speed must not be > system clock. I wounder what is the PLL multiplier at the startup to calculate the system clock. Or maybe it doesn't matter what SPI speed to use for initialization? I guess what i wrote above is applied to SPI speed between the chips not between uC and 1st chip. Currently when i run cgminer i see 500khz SPI speed. Is that sufficient? |
|
|
|
|
Having some trouble with getting 0x04 responce on the 0x04 reset command.
I'm doing the HW reset as described. The signals from raspi passed through level shifters.
Chip select DI CLK are ok. I see 0x04 passing into the chip but there is nothing at the output.
The VDDcore is 0.7 volts. Maybe it is too low?
|
|
|
|
Seems that there is a mistake in schematics. Check the gerbers to be 100% sure. |
|
|
|
I would like to ask about HW reset signal for raspi. In my version of cgminer is see the following: #ifdef NOTYET
a1_nreset_low();
cgsleep_ms(1000);
a1_nreset_hi();
cgsleep_ms(1000);
#endif
So it is not implemented yet. Maybe it is implemented in a newer version of cgminer? Another question. Can the lack of HW reset at the beginning be responsible for chip not to reply on the 0x04 (RESET) command? It is not implemented because it is HW dependent. You need to have your means of driving RSTn low and 1V8 high. This can't be done generic, since some design will have a level-shifted GPIO, others an i2c driven GPIO port expander, whatever. Every design will need to have its own HW reset routine implemented in the driver. As for your second question: yes, it was stated from the beginning and multiple times: you need to always start with a HW reset before you try to access the chain. That is not only for startup, but also for regaining access if chip chain got corrupt (which happens with unstable power or SPI communication failures). Thanks for fast reply. I have implemented low level access to the GPIO pins. Will try tomorrow. |
|
|
|
I would like to ask about HW reset signal for raspi. In my version of cgminer is see the following: #ifdef NOTYET
a1_nreset_low();
cgsleep_ms(1000);
a1_nreset_hi();
cgsleep_ms(1000);
#endif
So it is not implemented yet. Maybe it is implemented in a newer version of cgminer? Another question. Can the lack of HW reset at the beginning be responsible for chip not to reply on the 0x04 (RESET) command? |
|
|
|
|
fonzie where are you looking order book?
|
|
|
|
|
Мне кажется такого слива не будет во второй раз. Ведь те кто слил в первый раз поняли как лоханулись.
|
|
|
|
|
Show Posts
