Experimenting with Jalapeno firmware...

[K1773R]

Lol, you OCers are a different breed of cat!  You wait 9 months for your Jalapeños and proceed to blow them up.

I'm just giving you some good-natured grief and I feel bad for the few who've lost or damaged their Jallys.  But for us less daring individuals it can difficult for us to understand why you'd even take the risk in the first place.

With difficulty rising so quickly, wouldn't it be wiser just to mine with it straight out of the box instead of modding and experimenting with firmware hour after hour, day after day?  I start to freak out if my ASICs have any downtime.  For example, I just setup 6 ASICMiner Blades a few days ago and during the first night, the PC that was running Stratum Proxy had a Windows update and restarted.  I about cried when I saw my stats.  Hell, I get mad if one of my USB Erupters goes offline for 5 minutes, lol.

if you know what you do, you wont damage your jala at all
changing source can be done without taking the jala offline, if you do it right you dont even have to disassemble the jala for flashing it. flashing takes 2-3 minutes spending 1 hour offline time for the jala is totaly worth it if you gain alot more hashpower.

[SLok]

I recognize a lot of your story from my 7GH jalap flash with the standard 1.2.5 FW, then I tried ckolivas' 1.2.5 and all was well again. Let the case front/sides and back plate off though, as the top plate, and have the fan blowing down getting 8.25GH average at 30-31C.

Thanks for the tip, I did end up trying ckolivas 1.2.5 and it improved the HW error rate quite a bit on the one working ASIC lol. Should have flashed that version right from the get-go. Other ASIC still doesn't even seem to be recognized, though.

Heatsink was snugged down tight and everything looked good when I had the case off. Only potential problem I can think of is one of the ASICs isn't entirely covered by the aluminum heatsink, actually a thread on the BFL forums about this. I didn't think too much of it when I first got it and opened it up since I didn't figure BFL would ship them out like this if it could cause problems, but almost wonder now if maybe that created hotspots on the ASIC or caused it to get hot enough to go belly up. Of course quieter/lower RPM fan and overclocking probably didn't help either, but for all I know it would have gone out sooner rather than later because of this even running it stock.

Are the heatsink mounting holes off compared to the good sink/board? Looks like some were 180 degrees turned when they drilled the holes, or are a standard model and some mirrored models slipped through. I would still ask for an rma in this case, can't imagine this would run proper for long..http://www.butterflylabs.com/technical-support/ Mention the chips are not covered completely by the sink.

[macromode]

Lol, you OCers are a different breed of cat!  You wait 9 months for your Jalapeños and proceed to blow them up.

I'm just giving you some good-natured grief and I feel bad for the few who've lost or damaged their Jallys.  But for us less daring individuals it can difficult for us to understand why you'd even take the risk in the first place.

With difficulty rising so quickly, wouldn't it be wiser just to mine with it straight out of the box instead of modding and experimenting with firmware hour after hour, day after day?  I start to freak out if my ASICs have any downtime.  For example, I just setup 6 ASICMiner Blades a few days ago and during the first night, the PC that was running Stratum Proxy had a Windows update and restarted.  I about cried when I saw my stats.  Hell, I get mad if one of my USB Erupters goes offline for 5 minutes, lol.

I'm a software engineer so I write code for a living and I love it. I'm certain there are tons of other software guys hanging out on this forum. With the source code in hand, asking us not to tinker with it would be like asking a mechanic to forget about dropping in the supercharger and just live with a 0-60 time of 9 seconds.

Hacking that firmware is like a sick reflex. And if we blow up that Jalapeño, then so be it. The extra juice is worth the squeeze.

[lightfoot]

Lol, you OCers are a different breed of cat!  You wait 9 months for your Jalapeños and proceed to blow them up.

I'm just giving you some good-natured grief and I feel bad for the few who've lost or damaged their Jallys.  But for us less daring individuals it can difficult for us to understand why you'd even take the risk in the first place.

Partially because this thing was never meant to make money. I'm smart enough to look at the concept of BC, see the logic behind difficuty, and understand the issues surrounding a classic queen's race game. If I wanted to make a profit I would sell it on Ebay for $500 or so which is more than it will probably mine in a year.

The reason I tweak it is because it's fun. It's a nice looking bit of equipment, it's well built, reading the code is kind of relaxng, and I'm curious to see what it can do. The time I'm wasting on it at $150 an hour billable rates means I will never get my money's worth out of it, but as I said, it's fun.

With difficulty rising so quickly, wouldn't it be wiser just to mine with it straight out of the box instead of modding and experimenting with firmware hour after hour, day after day?  I start to freak out if my ASICs have any downtime.  For example, I just setup 6 ASICMiner Blades a few days ago and during the first night, the PC that was running Stratum Proxy had a Windows update and restarted.  I about cried when I saw my stats.  Hell, I get mad if one of my USB Erupters goes offline for 5 minutes, lol.

The erupters are also kind of cute. I picked up two of them in the last 2 weeks, one for $28 and one for $24. They're at $22 or so, will be at 19.95 by the end of the week.

But they will never make their investement costs, maybe at $5.00 given a year. But they're fun, so try not to get too upset about the stats. Try taping them to your water tank to heat household water. That is why I would pay $150 for a broken one even though I bought mine for $169 or whatever. It would be fun to float off the chips with the air tools and build a 4 processor JP.

Haven't decided on picking up a FPGA BFL yet on Ebay, maybe for $100. Which is totally stupid since it can hash at 800mh using 40-50 watts while a trio of erupters can do 900+mh using 7.5 watts for 60% of the cost and still never break even :-)

It's the fun that counts. The fun of going to eclipse and seeing another nickel be created from thin air.
C

[frostedflakes]

Thanks for the tip, I did end up trying ckolivas 1.2.5 and it improved the HW error rate quite a bit on the one working ASIC lol. Should have flashed that version right from the get-go. Other ASIC still doesn't even seem to be recognized, though.

You too? Interesting, now I'm really wondering what that does. Might be time to crack out the threading disassembler :-)

Heatsink was snugged down tight and everything looked good when I had the case off. Only potential problem I can think of is one of the ASICs isn't entirely covered by the aluminum heatsink, actually a thread on the BFL forums about this. I didn't think too much of it when I first got it and opened it up since I didn't figure BFL would ship them out like this if it could cause problems, but almost wonder now if maybe that created hotspots on the ASIC or caused it to get hot enough to go belly up. Of course quieter/lower RPM fan and overclocking probably didn't help either, but for all I know it would have gone out sooner rather than later because of this even running it stock.

Mm. How tight was tight? I've been snugging the bolts down using a t8 torx bit by hand without handle or anything, pressing down on the sink and plate and snugging it down just enough to take out the slack. Finger tight, counting on the artic pad to do the work of transferring the heat. When I first took off the plate it was easy to remove with fingers on the torx bit, so I used that as the measurement of torque to snug it down.

Maybe one of the chips broke a bga connection or something. Do you have air tools to try and refloat it?

C

It was snug but was careful about over-tightening as well. Pretty sure there's less flex to the PCB now than there was when I got it, so heatsink shouldn't be torqued down more than it was from the factory.

I may have to try taking the heatsink off sometime and inspecting everything. Or may just leave well enough alone considering it's still hashing at 4GH/s or so. Hadn't thought about possibility of a bad BGA joint, I don't have a reflow station and proper tools, though, closest thing I'd have is an adjustable temp heat gun.

But as mentioned I think part of the chip being exposed and not covered by the heatsink might have been what did the one ASIC in, though. Had figured it was by design, didn't even realize it was a defect until after I had already flashed it, then I had seen the thread on BFL forums about it. Too late to request an RMA since firmware has been flashed. Couldn't hurt to ask I guess but doubt they'd grant one.

[elite.mafia]

Hey guys, my Jalapeno ran at 6.4ghash to 6.9ghash when I got it from BFL. I flashed it using an AVR Dragon and Atmel Studio. I used the BitForce_SC-1.2.5 firmware and set
#else   
   #define __ASIC_FREQUENCY_ACTUAL_INDEX   7

and was getting less thant 0.25% error rates at 7.25ghahs/s
I tried to push it a little further

#else   
   #define __ASIC_FREQUENCY_ACTUAL_INDEX   8

now I get about the same ghash/s but I get more than 1% HW error rate
this is the grep getinfo that shows up....


C:\Users\7950\Desktop\cgminer-3.3.1-windows>"C:\Program Files (x86)\Java\jre7\bi
n\java" API stats | "C:\Program Files (x86)\GnuWin32\bin\grep" GetInfo
Answer='STATUS=S,When=1379570645,Code=70,Msg=CGMiner stats,Description=cgminer 3
.3.1|STATS=0,ID=BAJ0,Elapsed=291,Calls=0,Wait=0.000000,Max=0.000000,Min=99999999
.000000,Temp1=30.16,Temp2=31.88,Vcc1=3.406,Vcc2=1.001,Vmain=12.163,Temp1 Max=31.
00,Temp2 Max=34.00,Temp1 Max Time=1379570479,Temp2 Max Time=1379570489,Work Queu
ed=36,Work Complete=488,Overheat=false,Flush ID=0,Result ID=288,Flushed=false,Sc
an Sleep=937,Results Sleep=100,Work ms=954,Driver=2,Firmware=1.2.5,Chips=(null),
Que Size=40,Que Full=36,Que Watermark=32,Que Low=8,GetInfo=DEVICE: BitFORCE SC0x
0aFIRMWARE: 1.2.50x0aIAR Executed: NO0x0aCHIP PARALLELIZATION: YES @ 20x0aQUEUE
DEPTH:400x0aPROCESSOR 3: 13 engines @ 284 MHz -- MAP: FF7A0x0aPROCESSOR 7: 14 en
gines @ 254 MHz -- MAP: EFFE0x0aTHEORETICAL MAX: 7248 MH/s0x0aENGINES: 270x0aFRE
QUENCY: 283 MHz0x0aXLINK MODE: MASTER0x0aCRITICAL TEMPERATURE: 00x0aXLINK PRESEN
T: NO0x0aOK0x0a0x00,USB Pipe=0|STATS=1,ID=POOL0,Elapsed=291,Calls=0,Wait=0.00000
0,Max=0.000000,Min=99999999.000000,Pool Calls=0,Pool Attempts=0,Pool Wait=0.0000
00,Pool Max=0.000000,Pool Min=99999999.000000,Pool Av=0.000000,Work Had Roll Tim
e=false,Work Can Roll=false,Work Had Expire=false,Work Roll Time=0,Work Diff=1.0
0000000,Min Diff=1.00000000,Max Diff=1.00000000,Min Diff Count=639,Max Diff Coun
t=639,Times Sent=432,Bytes Sent=50795,Times Recv=480,Bytes Recv=61262,Net Bytes
Sent=50795,Net Bytes Recv=61262|STATS=2,ID=POOL1,Elapsed=291,Calls=0,Wait=0.0000
00,Max=0.000000,Min=99999999.000000,Pool Calls=0,Pool Attempts=0,Pool Wait=0.000
000,Pool Max=0.000000,Pool Min=99999999.000000,Pool Av=0.000000,Work Had Roll Ti
me=false,Work Can Roll=false,Work Had Expire=false,Work Roll Time=0,Work Diff=0.
00000000,Min Diff=0.00000000,Max Diff=0.00000000,Min Diff Count=0,Max Diff Count
=0,Times Sent=6,Bytes Sent=424,Times Recv=0,Bytes Recv=0,Net Bytes Sent=424,Net
Bytes Recv=0|STATS=3,ID=POOL2,Elapsed=291,Calls=0,Wait=0.000000,Max=0.000000,Min
=99999999.000000,Pool Calls=0,Pool Attempts=0,Pool Wait=0.000000,Pool Max=0.0000
00,Pool Min=99999999.000000,Pool Av=0.000000,Work Had Roll Time=false,Work Can R
oll=false,Work Had Expire=false,Work Roll Time=0,Work Diff=0.00000000,Min Diff=0
.00000000,Max Diff=0.00000000,Min Diff Count=0,Max Diff Count=0,Times Sent=2,Byt
es Sent=155,Times Recv=3,Bytes Recv=925,Net Bytes Sent=155,Net Bytes Recv=925| '

   [GetInfo] => DEVICE: BitFORCE SC0x0aFIRMWARE: 1.2.50x0aIAR Executed: NO0x0aCH
IP PARALLELIZATION: YES @ 20x0aQUEUE DEPTH:400x0aPROCESSOR 3: 13 engines @ 284 M
Hz -- MAP: FF7A0x0aPROCESSOR 7: 14 engines @ 254 MHz -- MAP: EFFE0x0aTHEORETICAL
 MAX: 7248 MH/s0x0aENGINES: 270x0aFREQUENCY: 283 MHz0x0aXLINK MODE: MASTER0x0aCR
ITICAL TEMPERATURE: 00x0aXLINK PRESENT: NO0x0aOK0x0a0x00

What can I try to fix this? I feel like surely I should be able to get more than 7.2ghash out of this


I've just changed a few settings and am now seeing 7.45gh/s average but 16 hw errors out of 1024 accepted, 4 rejected, more than 1% error rate. I still feel like I should be able to go faster than this.

anyone have any idea why it shows less engines than it should for each processor?

[yonvanom]

Hey guys, my Jalapeno ran at 6.4ghash to 6.9ghash when I got it from BFL. I flashed it using an AVR Dragon and Atmel Studio. I used the BitForce_SC-1.2.5 firmware and set
#else   
   #define __ASIC_FREQUENCY_ACTUAL_INDEX   7

and was getting less thant 0.25% error rates at 7.25ghahs/s
I tried to push it a little further

#else   
   #define __ASIC_FREQUENCY_ACTUAL_INDEX   8

now I get about the same ghash/s but I get more than 1% HW error rate
this is the grep getinfo that shows up....


*snip*

What can I try to fix this? I feel like surely I should be able to get more than 7.2ghash out of this


I've just changed a few settings and am now seeing 7.45gh/s average but 16 hw errors out of 1024 accepted, 4 rejected, more than 1% error rate. I still feel like I should be able to go faster than this.

anyone have any idea why it shows less engines than it should for each processor?

I was getting about the same results with the "standard" 1.2.5 firmware and tweaking it. Try ckolivas' firmware: http://ck.kolivas.org/apps/cgminer/BitForce_SC/BitForce_SC_1.2.5ck.elf.zip it worked much better for me, it's running at 7.83 Gh/s and I'm getting around 0.8% HW errors.

[elite.mafia]

Hi, I'm not familiar with that type of file. I used Atmel studio to flash the first time and it doesn't seem to recognize the .elf as a project file. Is there a different program I need to use?

[frostedflakes]

It's already compiled, you don't need to load it a project and compile source code. Just go straight to the programming screen in Atmel Studio, select your programmer and the chip to be programmed like you did before, then go to the memories tab. On that screen should be able to select the .elf file on your computer to program to the chip.

[hahahafr]

Hello everyone, could a good spirit point me to the tools/software I need to flash a Single SC?

[lightfoot]

Hello everyone, could a good spirit point me to the tools/software I need to flash a Single SC?

Might not get a lot of boost out of that. I think the trick was that Jallys were underclocked/built with rotten-er chips, so tweaking them was a good way to get more cores online at a higher speed.

Speaking of which, my JP is still cruising along at 7.5-7.6gh, reasonable temps, and well under 1% error rate. Actually better than the two block erupters I have in there as well.

Not playing with it anymore, waiting for chips to come availible so I can float on another two processors. Anyone need a Dragon?

C

[Photon939]

Hello everyone, could a good spirit point me to the tools/software I need to flash a Single SC?

Might not get a lot of boost out of that. I think the trick was that Jallys were underclocked/built with rotten-er chips, so tweaking them was a good way to get more cores online at a higher speed.

Speaking of which, my JP is still cruising along at 7.5-7.6gh, reasonable temps, and well under 1% error rate. Actually better than the two block erupters I have in there as well.

Not playing with it anymore, waiting for chips to come availible so I can float on another two processors. Anyone need a Dragon?

C

Does yours have the hot or cool mosfets? Mine has the hot mosfets and while firmware tweaking has got mine flying along at 8.2GH/s I don't think the VRMs could handle 2 more chips, the mosfets get nearly burning hot even with the case removed and a better fan

[erk]

Has anybody experimented with under clocking the Jalapeno to see how far they can get the power consumption down? Most people seem to be fixated with trying to get the things to hash faster at the expense of power consumption.

Obviously at some point the BTC mined by the device ceases to cover the electricity cost, when that happens with one of my GPUs I reduce the clock speed until it's profitable again. I can see the need for doing so with the Jalapeno as well, exactly how low depends on your local cost per kWh.

[lightfoot]

Does yours have the hot or cool mosfets? Mine has the hot mosfets and while firmware tweaking has got mine flying along at 8.2GH/s I don't think the VRMs could handle 2 more chips, the mosfets get nearly burning hot even with the case removed and a better fan

Cool ones. It's a later model, and I think it has one chip that is good, one that is eh. Seems that the later ones will top off at 7.5 or so, but run cool and don't chew up much power.

That said, it is probably a losing game at this point to add chips. Given that BFL hasn't been shipping the things, and that a 10gh erupter blade can be gotten for 500 or so, prices dropping daily. :-) Unless the chips were $40 each it would probably not be worth the risk of shutdown+reflow right now.

Eventually the chips will be pretty much free and I'll give it a shot.

C

[GenTarkin]

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!

[juhakall]

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/

I just tried this, and it really does boost the hashrate. I'm not exactly sure how much yet, since I'm measuring by difficulty accepted, but my it seems to be settling in the 64-65 range, when it was previously doing a bit over 61. Here's a snippet of the ZCX reply:

THEORETICAL MAX: 68880 MH/s
ENGINES: 256
FREQUENCY: 291 MHz

As you can see it enabled all my engines, stock firmware was only seeing 245 or so. It's now doing ~3.5% errors instead of the stock 0.4%, but with BFGMiner I can see which chips are doing lots of errors, and using the 16 value array in this modified firmware, I can set those chips to a lower frequency.

[GenTarkin]

awesome, ... now Im trying to figure out higher frequency words for the clock generator. If anyone knows the order of words from 5555(current highest) to CD55(seems to be highest as specified in commented out line in osc control of ASIC_engine.c .. .that would be great if ya could post.
The current pattern looks like this - fill in blank lines between top group and bottom value(not sure how many lines are needed =P)
http://pastebin.com/GrrBtkzT

[danattacker]

Hey everyone. I was wondering if anyone has successfully soldered additional chips to their Jalapeno. I received two chips today and promptly soldered them. I had never soldered a BGA package before but I felt confident I could do it. Well, I jacked up soldering the first chip and messed up the solder balls. I tried again with the second chip and was successful. I managed to solder the first chip by removing the solder from the chip and using the solder balls on the PCB, although it sits almost flat against the board. What messed me up was that it required a lot more heat than I was expecting to solder the chip. I also noticed that the chip packaging is different and it's thinner than the old ones.

I checked for any shorts between the power and ground, and then I powered it up. The power LED came on for about a second and then cut out and was barely pulsating at around one second intervals. At this point I was thinking "Oh shit, I fried something". I decided to unplug it and plug it back in and it did the same thing, but I just waited for about 5 seconds and it powered back up. But, only the two original chips were detected.

So, at this point, I'm not sure what to do next. I already reheated the chips and tapped them when the solder was molten in case any solder balls didn't make contact with the board. I was hoping that the chips would just work when I soldered them on the board. If anyone has soldered additional chips to their board, I'd like to hear any thoughts you might have or if you had to do anything else (firmware setting?) to get them to work. Thanks.

[KNK]

I have not soldered any additional chips myself, but was planning to do so and as i remember there where some additional changes to make, because the chips are addressable and the address is wired on the board, then they are daisy-chained for the DONE interupt - check the chip specs - https://forums.butterflylabs.com/attachments/announcements/1321d1371338930-butterfly-labs-announces-bulk-chip-sales-bfl-sha2-spec-rev2.2-release.pdf for the exact pins 

[danattacker]

Thanks for the datasheet. I haven't seen it before. I'll be looking through it later today.