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!
