yes you need AVR dragon to flash.

yes I will update thread, at this point Im out of ideas to get further actual performance from, other than by seeing if theres additional values that can be used to adjust the clock generator upwards.

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%

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!

Hey guys.....
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 40x 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!

1 @ 6.5btc

Ill offer 6.5btc for 1  =)

bumpity, remember submit any price! =)

Cool, at a decent price, I would get in B2 for sure... depending on timeframe of B2 actually shipping. =)

when is b2 ready to ship? Its a shame prices went up... at $425 & current BTC price...these things will never ROI =/

So, Ill start offers at an actual reasonable price. 15BTC for 2, overnight to Portland, OR, escrow, insured.

Ill offer 6.5btc each, shipped overnight, insured, escrow. Im in Portland OR

This is why you cant: http://mining.thegenesisblock.com/a/1190ba0d00

How much I can expect to mine from it =)

I obviously retract my offer... for some reason I misread the OP, I swear I thought it said 2x 60GH =P

60GH itself is alone only worth around 7btc atm...
So, yeah I would have to readjust my offer to 7tc, including shipping overnight + escrow. All fees paid.

um.... 12... right


Ill offer 14, overnight shipping insured, escrow

for both

I do dude =) whats up ... hehe! yeah, I would like singles instead of the avy so I can easily add to my space heater setup indoors.

Well, RAM I may be willin to ship elsewhere since so small, I dont know. Never really done international shipping before... what ya interested in?

Whats their hashrate?

Pacific Northwest region - US =)

I would like BTC, post or PM offers
Shipping can be negotiated and only to CON-US

Escrow optional =)

Ive purchased 2x 240CFM fans for it(externally powered through molex), they are currently installed and keep it extremely cool. The avalon sustains 85+ GH @ 35c or less. Clock speeds at these temps between 360-366
But due to environmental variables beyond my control, this unit will be sold guaranteeing its stock rated hashrate.

I still have the original fans as well and can be reinstalled if desired.