Topic: Cairnsmore1 - Quad XC6SLX150 Board - page 49. (Read 286370 times)

Third time I ask this but as my question is buried under pages of people testing new bitstreams and yohan didn't seem to notice it...

Is there any way to flash a controller bitstream from a Linux computer or any plan to allow it ? I don't know if compiling spiprog is possible, if a specific version or patch is needed to make it work (Windows users are advised to download their SPIprog.exe from Enterpoint for example). So I don't even know if hacking my way through a random spiprog source compilation would not make my boards pricey door stops.

@yohan, please advise.

Just a question ... out of curiosity ...
Wouldn't it be that when you flash or change the CM1, the switch settings would depend on what is in there at the moment,
not what you are trying to put in there?
i.e. the switch settings will depend on the current CM1 contents since that can change the meaning of the switch settngs?

I don't have a CM1 (though someone who has bought a few was generous enough to offer me one today - however I have no use for it until the firmware and bitstream are decided and working so I declined until a later date - it would be idle in my hands at the moment, so since they are using it, it's best to stay where it is)

Anyway, I was thinking of 2 obvious additions to --icarus-timing:
1) Specify the baud 112 vs 56 (default will still be 112 of course as current)
2) Specify the FPGA multiplier (1x, 2x, 3x etc ... up to 8x I guess to consider the future? default will be 2x as current)

I think they are the only things that have been different for people so far?

There is no rollback from the glasswalker controller via usb. Not atleast with the current instructions.

On a slightly more positive note, Im currently flashing in the latest bitstream glasswalker pushed out and should have something to report in an hour or so.

Anyone had any luck with the testing bitstream yet? I'm eager to hear if it was successful at all

The board Im currently working on has controller 1.3 in it, I now want to get the glasswalker bitstream controller in there, but spiprog gives me an error and suggests that I have incorrect dip-switch settings, miner are as they are guided in the pdf accompaning the glasswalker controller. SW1 all on SW6 2nd off rest on. Other positions "any setting". What am I doing wrong this time ?

(10:59:50 PM) Glasswalker [[email protected]] entered the room.
(10:59:54 PM) Glasswalker: Hey anyone here?
(11:00:29 PM) Glasswalker: I'm on my laptop at my inlaws, and don't have my password db readily available to log into bitcointalk
(11:00:37 PM) Glasswalker: but I have a new bitstream for people to test
(11:01:02 PM) Glasswalker: at http://www.btcsyn.com/bitstreams/cairnsmore_125_test.zip
(11:01:15 PM) Glasswalker: be aware this is untested, it uses new code that may not even work
(11:01:21 PM) Glasswalker: but I hope it's nice and stable in all 4 slots
(11:01:30 PM) Glasswalker: so I'm not wasting time optimizing the 175Mhz version of the same code.
(11:01:48 PM) Glasswalker: It's 25Mhz source clock, 57600 baud same as last bitstream, uses glasswalker controller
(11:02:11 PM) Glasswalker: If someone here could please post this info to the bitcointalk threads I would appreciate it
(11:02:30 PM) Glasswalker: This one is 125Mhz (125Mhash)
(11:02:33 PM) Glasswalker: only for testing functionality
(11:02:45 PM) Glasswalker: But if this works, I should have a 175Mhz version very soon
(11:03:00 PM) Glasswalker: if it fails, at least I know I need to debug it. instead of wasting a ton of compute power on optimizing bugged code
(11:03:27 PM) Glasswalker: Isokivi: *poke*
(11:03:50 PM) Glasswalker: zefir: *poke*
(11:04:01 PM) Glasswalker: makomk: *poke*
(11:04:03 PM) Glasswalker: lol
(11:04:32 PM) Glasswalker: ok well I've got to head to sleep, hopefully someone sees this, Tomorrow I'll get my pwdb going and get on and post it up myself if nobody beats me to it, but it might not be till the end of the day
(11:08:40 PM) Glasswalker: Night all, here's hoping someone has some success with the 125Mhz test.
(11:08:51 PM) Glasswalker: I've also sent it to Yohan at Enterpoint for testing.
(11:13:50 PM) Glasswalker left the room (quit: Ping timeout: 240 seconds).

Love the script btw zefir.

Thanks!

Yes, that's how it should work. You should get 280 mh/s per comm. 2 comms per board. The screenshot of the person I was quoting is a little misleading as it looks like he was trying to open 4 comms per board. I guess I don't know which fpga is actually doing the work of each pair, but it looks like the same situation as before as far as only 1 active fpga per comm channel. My 280 mh/s is composed of 140/140 as opposed to 280/0. It should be 280/280.

I had the same results, if I read correctly I think ebereon uses a jtag cable, maybe that makes it work? Im just using the usb cable.

Yes, to all.

Should do...hmm

Controller rev. 1.3?
Flashed to SPI and powered completly down?
Changed USB cable?
What SN?

My boards are all working and SN# is betwen 62-406 and 62-415. U is betwen 3.76 and 4.00 for each pair.

I tried on a different board with the same results. 140 makomk bitsteam works on fpga 0,3 just like twin_test. It

does not work on fpga 1,2. I double checked the comms. I can only think I'm making a procedure error.

For programming:

SW6   1 off, all else on

SW1   3 off, all else on

SW2,5   all on

SW3,4   2 off, all else on



For mining:

SW1   all on


no other changes

I had 1 board that i had to flash permanently (SPI) to get it working. All others run with the temporary mode. I don't know why, but yohan knows...


@Makomk: Please post your Wallet address, i will throw some coins to you =D  - your bitstream is the best at the moment, nothing is faster or easyer to flash.

eb

This is my experience also. All 4 fpga positions produce the occasional green flash. Sometimes the 2 fpga positions next to each other produce a simultaneous very quick red flash. I've tried different setting for sw 2-5. None seem to make a difference to anything.

Sheeit, how much RAM do you have anyway? I've been considering building a monster, but with 24 cores I'm assuming you already have a lot of RAM.

Ok I'm leaving town now... And unfortunately neither the 150 or 125 closed timing on first attempt (which is silly, stupid xilinx tools)...

Anyway, I'm now running smartxplorer on BOTH the 125 and the 175... The 175 is set to run all possible options and find the best, the 125 is set to find the first possible option that closes timing at all, and then quit...

With both running all 24 of the processor cores in my machine are maxed out at 100% and my ram is pegged at 98%... So it's bordering on bursting into flames lol...

Hopefully it will close timing very quickly on the 125, I don't know why it didn't on the first try, amusingly the 175's first attempt would likely run fine at 125 out of the gate, but because the DCMs are configured differently if I simply underclocked it it would fail to work. And when I rebuilt with the needed clocking changes, it resulted in this crippled bitstream.

Anyway, I'll keep checking on it remotely, and when it's closed the 125, I'll release it for testing.

Once I get something viable on the 175 I'll do the same.

I've sent all my work to Enterpoint, hopefully they can continue running with it over the weekend while I'm gone and maybe we'll get an improved controller that helps mitigate more of the problems.

Also while waiting on the build today, I made some fairly major headway on my "from scratch" bitstream... It may be closer than I originally estimated (ie weeks instead of months)

Thanks!

which usb hubs are you guys using?

Thanks! this data is helpful, and interesting.

I ran into an ongoing battle with the xilinx tools, my last build I attempted to do too much at once, and ended up having to backtrack. But I'm now caught up.

What I have now:

- Rewritten UART core to be improved and a bit more noise resiliant, and should be better at locking onto the data cleanly
- Adjusted the timing some more
- Reworked the project to be buildable purely in Xilinx ISE. (no more requirement for third party tools!)
- Using the above code I've built a 175Mhz version that doesn't fully meet timing (1.5ns off)
- I'm not running that build through smartxplorer on my workhorse to get it to close timing.
- In the meantime I'm now trying a build of both a 125Mhz and 150Mhz version of the same bitstream, hoping one of the 2 will meet timing so we can at least do functional testing to ensure the new code actually works as expected, and if so we can do some stability tests on the lower hashrate.

I'll post once I have a finished build of one of the "slower test builds" so some of you can try them out. Unfortunately this evening I leave town for the weekend and won't be able to get any work done. But the optimization run will run all weekend long and should be done early next week, so provided this new code actually works (and the slower cores test out fine) the 175Mhz version should finish sometime soon.

I'll be sending all my work to Yohan at Enterpoint, and he'll do some additional poking and testing on their end, perhaps another improved controller will help as well.

So I'm in rush mode right now to validate the code on a slower bitstream before I leave for the weekend, so I don't waste too much compute time on invalid code (if that's the case). Here's hoping though that it's all solid, and this can get us runing reliably on all 4 chips (at a slower rate), and early next week we'll see a 175Mhz version of the same.

Hopefully within an hour or two I'll post a .bit file for you to test out.