hmm, I can't let my fingers from it...  I found the problem with flashing the bitstream to the SPI flash:  There is no blank betwen "-I" and the filename "xc6lx150.bit". I try now this, hope it works better when the unit is starting with the bitstream already loaded. Edit: When it's done it should look like this:  Wait until you see "Verify: Success". It takes 7:40 minutes per fpga! Nice, seems like an easy enough fix. Hope it works out for you ebereon. |
|
|
|
Yohan, could you please clarify what you mean with 'you should be able to do that now (i.e. writing to SPI)'? As said above, right now no one successfully wrote to the SPI flash and it is really a PITA to reprogram all devices non persistently again when one of them crashed and need to be powered fully down (you do not know which one is the problematic one and need to turn off all of them).
So either it is possible with the current controller programming, then could you please provide a detailed step-by-step instruction. Or it is not doable over USB but needs to be done via JTAG.
Either way it would be very helpful to flash the Icarus bitstream into SPI until your dedicated one is ready. Any clarification is highly appreciated.
Thanks.
Yes I think all of this is currently possible and I will double check that this morning that I am not talking crap in any shape or form. We use these processes on our lines already. The load of the 4 array SPI Flash does take over 30 minutes so it does need patience to do. We do a 5-10 boards together here to stop it becoming a line blocker. I will also see if we can somehow streamline the instructions. I too would prefer working instructions for flashing to the SPI for the twin_test bitstream. Personally I would prefer this now as opposed to getting the working bitstream a day earlier so then atleast I can run the twin_test bitstream without going through reflashing it every day. I would be happy to give enterpoint an interest free loan if they could beat BFl to it.
Who's with me?
I'm not giving anyone an interest free loan. Id rather they just focus on their bitstream or even release an early version that can hash at 300+, Ive tried for hours to get the twin, or 190_v3 working and it just wont do it on my board. I did get it working again with the shipping_test bitstream so at least I'm getting 110 hash. |
|
|
|
|
I'm looking forward to a new Bitstream, I have tried everything and every now and again I can get 1 ICA to work at around 120mhash. I'm bummed I'm not able to get the 300+ following the others instructions, and trying things on my own. It definitely seems to program but just wont do anything after that on one of the ports.
|
|
|
|
The twin test is more or less a standard Icarus build. I think the ID and maybe the DCM settings were changed but that was about it.
Ok, then it's based on the 190M_V4.bit. 190M_V3.bit and less is 100% different when i make a binary compare to the twin_test.bit. But then that's the problem with twin_test.bit. It will stop working after some time. It is not droping it will complete stop working. 50 minutes so far on the 190M_V3.bit without invalids and pool stat is still rising the Mh/s. 386Mh/s/10 minutes so far. (fingers crossed!) Eb when you did this did you use the twin_test.bit programing switches? I followed what you did Ebereon I'm still unable to get hashing at over 100, I did have 1 ICA hashing for a few minutes but they always die after a little bit. I also tried the 190M_V3 bitstream but was unsuccessful on that as well. I can program it now in Linux witch makes me happy, Thanks Zefir, and Spiccoli. |
|
|
|
|
Ramp mine doesn't hash either if it makes you feel any better, I had it going at about 25-50 for a few minutes, then tried to program it one more time and now it just connects and never finds a share.
|
|
|
|
|
Ok after further fiddling it looks as if the programming has not been working and that Ive been resetting it each time back to the shipping.test. As far as feedback goes, if you could go in to more detail on what as successful program looks like and what the lights should be doing when it was successful.
|
|
|
|
|
Ramp did your try this from daemonic a few posts back? Although with that programmed im still getting crap all for hash rate, im just happy it does something at all haha
To program, I had;
SW1 all on
SW6 all on
SW2 (PGA 0) all on
SW3 (PGA 1) 12 off, 34 on
SW4 (PGA 2) 12 off, 34 on
SW5 (PGA 3) all on
(as per progamming operation from virtual box, but ignoring the SW6 3 off)
then to use standard cgminer, i switched SW1 1 off;
SW1 1 off, 234 on
SW6 all on
SW2 (PGA 0) all on
SW3 (PGA 1) 12 off, 34 on
SW4 (PGA 2) 12 off, 34 on
SW5 (PGA 3) all on
(as per normal operation)
(this is for twin_test.bit)
Ok I actually got it to program as per the instructions this time, and noticed you have to flip the switches and wait for the lights to go amber in normal operation. Still hashing at like 25-50mh though with the twin.bit.
|
|
|
|
|
Yes, thats the only one I can seem to get to work. Any other configuration gets me a cannot mine all devices disabled in cgminer.
|
|
|
|
|
I am only able to get about 50mh with the twintest.bit file in normal cgminer. Mine seems to program without a hitch at least so thats good, but im not at the 380 yet.
Having fun playing with all this stuff though.
|
|
|
|
|
I get the same error as Ebereon I have 62-0013. The xc3sprog –c cm1 –p 0 twin_test.bit works, but loading to SPI Flash with xc3sprog –c cm1 –p 0 –I xc6lx150.bit twin_test.bit gives me the error below.
JEDEC: ff ff 0xff 0xff
unknown JEDEC manufacturer: ff
ISF Bitfile probably not loaded
Also looking forward to programming these in Linux.
Thanks!
|
|
|
|
|
Plug in your usb, then type dmesg, then make sure its not sdb1 instad of sdb.
|
|
|
|
|
Currently I have the switches set to the default way they were shipped to me. SW 1 and 6 all ON. SW2 all on, SW3 1off, 234 on, SW4 1off ,234 on, SW5 all ON.
I'm starting to think its my USB ports ill try a different windows pc tomorrow I suppose.
|
|
|
|
Im getting and error before I can get to programming, when I select the USB device I get this error . I also cant seem to mine anymore in windows, causes a blue screen after a couple tries, It was working. Works fine in Debian.  Uploaded with ImageShack.us |
|
|
|
Well, I will add that I've not had anyone come to IRC FreeNode #cgminer who has it hashing and come and ask about the --icarus-timing settings and see if we can make it do better. I don't have one of these devices and don't expect the people making profit from them will give a rats about me trying to help people with them ... but if someone comes by I'll try help anyway. But the limit at the moment may not be a timing issue, it may be something else - however I've no idea and also have no details about the device except what everyone here has posted. (P.S. however if you come to #cgminer right now, unfortunately I have very little time for the next couple of hours - but later should be OK  ) I actually added the =short timing and had 3 going, but then it killed my real Icarus and I decided to stop everything and start over without the timing setting. I was afraid I might hose my real Icarus, although Im prolly just being a bit paranoid. I think ill just hold off and see what Enterpoint brings us this week. |
|
|
|
|
Yeah you get 4 tty, 2 cgminer doesn't talk to and 2 do. If you do it that way you get 50mhs. I mean obviously EP has the exact way these are going to work, at this point like I said before its just blind fiddling. I'm just going to leave it the way it is for now and take the 100mhs and wait for any updates EP brings later on.
Either way it was fun to see them working.
|
|
|
|
Same on mine and i see in mpbm it produce ~16% invalids  In linux with those settings only one FPGA is running but getting 100mhz, I had two going briefly but it didint last long. Ill take what I can get for now. Doff |
|
|
|
I am only able to get 2 mining at a time no matter what switches I try. Since I really have no clue what any of them do I'm just blindly guessing anyhow. Eb was able to get 4 mining with his switch configuration a couple pages back, I tried the same and it didn't work for me you might give that a try. Works fine in windows, I just wish I could figure out what Linux wants to communicate with it. I couldn't get mpbm working with it either. I still think I have a driver issue even though the ttyUSB0-4 are all showing up properly, and the drivers look good in lsmod.
As ebereon worked out - try changing SW6 1 (that, I guess, changes the baud rate?) The real cgminer uses 115200 in the icarus code That did the trick thanks Eb and Kano! Doff Are you getting results from all 4 fpgas? If so, can you please post your switch settings for all 6 switches? |
|
|
|
Works fine in windows, I just wish I could figure out what Linux wants to communicate with it. I couldn't get mpbm working with it either. I still think I have a driver issue even though the ttyUSB0-4 are all showing up properly, and the drivers look good in lsmod.
As ebereon worked out - try changing SW6 1 (that, I guess, changes the baud rate?) The real cgminer uses 115200 in the icarus code That did the trick thanks Eb and Kano! Doff |
|
|
|
|
Works fine in windows, I just wish I could figure out what Linux wants to communicate with it. I couldn't get mpbm working with it either. I still think I have a driver issue even though the ttyUSB0-4 are all showing up properly, and the drivers look good in lsmod.
|
|
|
|
|
Show Posts
