Topic: Experimenting with Jalapeno firmware... - page 6. (Read 62616 times)

I only made 3 changes to std_defs.h :

Changed product model to  __PRODUCT_MODEL_LITTLE_SINGLE__
Commented out #define __RUN_HEAVY_DIAGNOSTICS_ON_EACH_ENGINE   1
Changed #define __TOTAL_DIAGNOSTICS_RUN  10 to 1

I had the temp set at 450 C. I didn't time how long I heated them but it was maybe a minute. I know I had the temp set too high (I normally run 350 C), but it was taking much longer to solder than I was expecting. When I first powered on the unit and it didn't work, I believed that I may have very well burned up my chips. Thankfully, this was not the case.


I'm running it open.

Eh.... It's a losing game. Due to the wonderful world of difficulty, the most the chips are worth is the cost of BTC they can mine before going obsolete. When you add the risk of trashing your unit and the difficulty of soldering BGA, it's way more worth it to just buy BTCs directly.

But of course we're not normal people. :-)

Ok, I've got a small Aoyue rework station myself, and I have done a fair bit of SMD work on IGBT drivers with a preheater element as well. So it might not be impossible for me to do (never done BGA either). Hm, I do have some old craptops, maybe I can practice on removing and installing their BGA cpus this weekend.

What's the worst that can happen?

For the list, what temps did you use and how long did you keep the heat on them? Given that you have a success, info is good.

I used the artic pads on my JP when I reassembled, and it seemed to transfer the heat fairly well when I jumped to 7.25 (One of my chips is crummy, so I can't make . I have a friend shipping me his JP that was hashing stock at 5.8gh that he bricked, two day USPS Priority shipping and the stupid thing is still in MA. Talk about sad ships. :-) I'll compare the temps between his and mine (mine is at 41c now) and see if having more ALUs online brings up the temp.

But it sounds like each chip is adding another 10-15 degrees to the sink, since the fan don't run any faster temp goes up. Are you running it open, or with the shroud on?

As for the PS, the stock one has a really crappy power factor of like .55, so it's already overloaded. A PFC corrected power supply would go a long way towards making it better but since we pay for watts and not for how sad we are with the lead/lag on power cycles people don't care much.

This might really work once it gets super cold out there.

Anyway, once I get his going I might be able to set aside some time this weekend to practice, then next weekend to risk my unit. Someone is selling chips for $40 on Ebay, that's probably high I'll see if he would accept $60 for two. Next week might be less, in perfect Crassus style.

Thanks for the info.

Shhhh, nobody will sell me their jallies and chips dirt cheap now. Ummm I mean, good job dan.

I used a hot air rework station with a cylindrical nozzle. I don't have any box tips. I did not use a board preheater but it would be a good idea since the power and ground planes just soak up the heat and it makes it harder to solder. This was my first time soldering BGA and I made some mistakes but I ultimately managed to get the chips soldered.

The reason the chips are running so hot is that I am using thermal pads so the heat is not being transferred to the heat sink as efficiently. Before, I was using thermal paste. But, the new chips are thinner, so I have to use thermal pads so all the chips are making contact with the heat sink. Also, the power supply is running extremely hot, almost too hot to touch. You will probably need to use a different power supply for more than 4 chips. I should also note that I have significantly overvolted my chips so that will add to the heat as well.

The board temps are stabilizing at around 70 C. So far I don't see anything adverse, so I'm not going to mess with the clocks right now. It's stabilized at 17.7 GH/s @ freq index 7 with ~1% errors.

Wow, congratulations! Chips are tougher than I thought. Question: How did you solder the chips on? Air tool plus box tip? Did you use a board pre-heater? Now I *really* want a pair of chips. Or maybe six...... :-)

I'm impressed with the heat; if you dial the speeds back to slower clocks can you get the temps down? I've noticed my JP went from pretty cool at 5gh to warm at 7 and hotter by 7.5+ so I dropped it to 7.3 or so and it's a happy little clam.

C

sick! nice job

Ok, I got the chips working. I just had to upgrade to the latest 1.2.9 firmware. I guess these new revision chips weren't compatible with the older 1.2.5 firmware I was using. Hashing at 17.42 GH/s with 4 chips. It is running really hot though; currently 71 C and the heatsink backplate on the bottom of the board is too hot to touch for more than half a second. But, error rate is only ~1% with freq index 7 so maybe it will work out.

If someone wants to send me a pair of chips to check I'd be happy to try to install them on my board.

C

I did a ZCX command and it says CHIP PARALLELIZATION: YES @ 4, so it is detecting the chips. But nothing else is different from when I had 2 chips. Obviously, the chips have power and are communicating, but they are not doing any work. I changed the firmware so it forces it to detect the chips and the LEDs for the chips come on but it still isn't doing anything. Device info now shows the chips but it says the chips are running at 0 MHz. I think it estimates the clock speed based on how quickly it does work, so I don't think its doing any work at all. I'm not sure how to proceed at this point.

No idea then. Have not received my jala yet  (it is sitting in Chicago for over 2 weeks now ) , so can't even take a look at the board.

I checked the schematic for the board and it looks like each chip has its own pin on the MCU for the DONE interrupt (i.e. they are not daisy-chained).

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

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 

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.

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

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.

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!

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