Still working on tweaking things. I did set that !define to define w/ no adverse affect. Its weird, the comment right above it even reinforced that its supposed to be !define... I wonder why, maybe its just redundant or something, I cant find anything else in the code that does it elsewhere.
donation addy: 12jjayHWtUci3ygPXD4i2yUHMySytiUBd4
The latest tweak or test is turning on running heavy diagnostics w/ the 3 nonce test... Doing this disabled only a few more of my engines but not nearly as much as stock. I really believe that running the diags at a lower clock yield more accurate results as to what engines are pretty much useless at any clock vs others that work fine otherwise... just have more potential for error as clocks raise.
So, my latest build yields 400-700mh/s less avg rate, but dropped my HW by about 50%
Topic: ANN: custom BFL firmware - tested 5-7GH pool meas. improvement on 60GH singles - page 3. (Read 7197 times)
October 15, 2013, 12:55:13 AM
October 14, 2013, 11:27:51 AM
Good work! I will try it out later!
Where is your BTC address so I can donate?
Where is your BTC address so I can donate?
October 13, 2013, 08:40:59 PM
Excellent!
October 13, 2013, 07:29:52 PM
Great work, GenTarkin !!!
I just flashed one of my 2 Singles.
It jumped from 63GH/s to 66GH/s (I had done some work with the firmware already, like disabling "tune down").
I just flashed one of my 2 Singles.
It jumped from 63GH/s to 66GH/s (I had done some work with the firmware already, like disabling "tune down").
October 13, 2013, 12:54:56 PM
Hey guys.....
First of all this is highly experimental code...as such if you blow up ur shit, not my fault. Ive provided both source and elf in the link below.
Ive been slaving away for the last 3 days at wrapping my head around, and tweaking BFL firmware.
Ive done some major changes that basically, reliably seem to get most peoples singles(60GH) an additional 5-7GH/s pool measureable.
My single stock was 58.4GH ... now its 64.8GH ... nearly all engines are enabled and happily hashing away.
Here is the source and the elf is also prebuilt in the debug folder.
http://www.fileswap.com/dl/oPZeK2NqSm/
Some changes, off the top of my head, a lot of my changes are in ASIC_engine.c
Ive created 4 user specifiable variables at the top - they are commented
1. specifies the frequency to boot the chips at
2. specifies the frequency to perform diagnostics on chips
3. specifies the frequency chips operate at during actual runtime
4. specifies the error threshold for the rewritten diagnostics routine I written against the engine processor(I still dont know if the processor is a seperate part of each engine or what, but the coding makes it sound like it)
These are specified using the index values (not frequency)
I only run the "processor diags" on each engine, I run them 20x(40 tests) on my single and I have set the threshold to 0 .. so if any error at all that engine gets disabled. Otherwise engine is left on. ( run no other diagnostics on single) ... on my particular single this leaves only 1 engine disabled(stock I had several engines turned off). So, its a very relaxed testing scheme as you can see, but I believe it provides enough to allow cgminer to measure speed incorrectly & HW error as well... whereas leaving all engines on.... well the engines that cant even return a response to cgminer dont even get flagged as HW Error... and create fake hashrate readouts.
Its my theory that the multi level chip clock frequency initialization Ive created...actually helps the engines come on line more reliably. Whereas BFL's method of booting up chips at full boar clockspeed ... actually can hinder more engines. Also, the way Ive written the processor diag for each engine...is a more relaxed method of testing, think of it as "benefit of the doubt"..
Future things to tweak:
1: mhz readout accuracy. - the way mhz is measured on these devices is kinda just guesswork. The firmware sends a job to engine, figures out how long it takes then calculates resultant mhz and assigns that as mhz for entire chip. I may write it so it does several samples of that job then averages reported time taken and use that as mhz...
2: ...theres a function called __ENGINE_AUTHORITIVE_ACTIVITY_SUPERVISION ... and looking at how it gets called and what its designed to do... I think it actually doesnt end ever getting properly executed. I see that there is an if statement in file HighLevel_Operations.c ... which looks like it should be inside a loop...cuz it incriments a value each time and if equals 200 then it executes the if statement... Problem is... I dont see where the loop is!?!?.... So, I think that if statement never gets executed and its designed to be runtime engine error handling. ....BFL....
If anyone could look at this and see...that would be great!
First of all this is highly experimental code...as such if you blow up ur shit, not my fault. Ive provided both source and elf in the link below.
Ive been slaving away for the last 3 days at wrapping my head around, and tweaking BFL firmware.
Ive done some major changes that basically, reliably seem to get most peoples singles(60GH) an additional 5-7GH/s pool measureable.
My single stock was 58.4GH ... now its 64.8GH ... nearly all engines are enabled and happily hashing away.
Here is the source and the elf is also prebuilt in the debug folder.
http://www.fileswap.com/dl/oPZeK2NqSm/
Some changes, off the top of my head, a lot of my changes are in ASIC_engine.c
Ive created 4 user specifiable variables at the top - they are commented
1. specifies the frequency to boot the chips at
2. specifies the frequency to perform diagnostics on chips
3. specifies the frequency chips operate at during actual runtime
4. specifies the error threshold for the rewritten diagnostics routine I written against the engine processor(I still dont know if the processor is a seperate part of each engine or what, but the coding makes it sound like it)
These are specified using the index values (not frequency)
I only run the "processor diags" on each engine, I run them 20x(40 tests) on my single and I have set the threshold to 0 .. so if any error at all that engine gets disabled. Otherwise engine is left on. ( run no other diagnostics on single) ... on my particular single this leaves only 1 engine disabled(stock I had several engines turned off). So, its a very relaxed testing scheme as you can see, but I believe it provides enough to allow cgminer to measure speed incorrectly & HW error as well... whereas leaving all engines on.... well the engines that cant even return a response to cgminer dont even get flagged as HW Error... and create fake hashrate readouts.
Its my theory that the multi level chip clock frequency initialization Ive created...actually helps the engines come on line more reliably. Whereas BFL's method of booting up chips at full boar clockspeed ... actually can hinder more engines. Also, the way Ive written the processor diag for each engine...is a more relaxed method of testing, think of it as "benefit of the doubt"..
Future things to tweak:
1: mhz readout accuracy. - the way mhz is measured on these devices is kinda just guesswork. The firmware sends a job to engine, figures out how long it takes then calculates resultant mhz and assigns that as mhz for entire chip. I may write it so it does several samples of that job then averages reported time taken and use that as mhz...
2: ...theres a function called __ENGINE_AUTHORITIVE_ACTIVITY_SUPERVISION ... and looking at how it gets called and what its designed to do... I think it actually doesnt end ever getting properly executed. I see that there is an if statement in file HighLevel_Operations.c ... which looks like it should be inside a loop...cuz it incriments a value each time and if equals 200 then it executes the if statement... Problem is... I dont see where the loop is!?!?.... So, I think that if statement never gets executed and its designed to be runtime engine error handling. ....BFL....
If anyone could look at this and see...that would be great!
Jump to: