Topic: Experimenting with Jalapeno firmware... - page 9. (Read 62561 times)

Define through the roof? I don't think error work is sent back; I think it's just dropped. Mine now is 2.5% overall, 0% on one chip, 5% on the other. But in a technical sense, a chip core that is 25% bad is still doing 75% of the work and contributing to my overall dollars.

Perhaps.

C

I am in a very similar boat as you. I have both jallys set to 9. One Jally has normal hw errors while the other is through the roof. Plus my average speeds are all over the place.

http://eligius.st/~wizkid057/newstats/userstats.php/1Cx2wsdoBjdJMxEvZiXGUMMAoUPddt6cnA

This thread inspired me, so after getting my 5gh/s jally last Tuesday I ran it (5.1gh/s, 34 C), and ordered a Dragon.

Dragon came on Tuesday, flashed the unit with the stock 1.25 firmware (speed 7) and performance went to 7.3gh/s. Nice. Temp went to 40c, I noticed one chip was putting out 3% error rate, other was at zero %.

This evening I flashed it with diagnostics set to one (to try to get more cores), speed to 8. Performance is around 7.7gh/s, Temp is 45C, one chip is putting out close to 9% error rate.

Looks like one of my chips is a tad bit substandard. Not sure if going to 9 will speed me up more or overwhelm the slower chip, but in either case the heat increase is substantial.

I've ordered some artic heat sink pads to replace the wimpy ones on the unit now, but for a $169 or whatever I paid for this when I ordered it in Jan it's not too bad. I might back the speed back down to 7 since the higher error rate might not be worth it, or should I go to 9?

Thank you everyone for the help.

Definitely. Always a tradeoff.

i hear you, but although that stock fan is loud, it hauls butt and moves a lot of air

It actually did come with some nice sleeving. It was pretty stiff and hard to deal with inside the cramped Jalapeno case, though. So just cut the sleeve off, far easier to route the fan ribbon cable inside the case without it.

And yeah made a huge difference in noise, really happy with the fan. The stock one was unbearable.

nice fan man.. Surprised the 92mm noctua's dont come braided

Don't know if this is typical for newer Jalapenos, but mine actually came from BFL with two chunks of the heatsink cut out over the fan and JTAG1 headers. Mine also didn't have a JTAG2 header soldered on. So didn't need to remove the heatsink to put the JTAG cable on and program the μC (of course didn't open it up and realize this until after I had already ordered a JTAG cable w/grabber kit that still hasn't arrived yet for like $10 off eBay).

http://img843.imageshack.us/img843/9178/c7dv.th.jpghttp://img15.imageshack.us/img15/1646/m435.th.jpghttp://img543.imageshack.us/img543/2346/mcf7.th.jpghttp://img801.imageshack.us/img801/2996/0ghf.th.jpg

Was getting ~5.8GH/s with default firmware (not sure why but was running pretty high straight from the factory, but also had what seems to be fairly high HW error rate, about 2%, so effective hash rate would actually be a bit lower). Flashed an unmodified 1.2.5 to it and now getting 8.1GH/s-8.3GH/s, depending on how many engines initialize and at what speed they initialize. Even more hardware errors now, though, looks like roughly 4%. Might be some other issue with my setup.

Going to try letting it cool down for a bit here sometime and seeing if I can get it to reinitialize at a higher hash. Looks like currently it's only initialized with 13 engines on on chip 3 and 14 engines on chip 7, but they are clocked super high, 305MHz for chip 3 and 296MHz for chip 7. The #define __ASIC_FREQUENCY_ACTUAL_INDEX should be whatever the default is, 7 right? I didn't realize it would clock them that aggressively.

Before I was getting about the same number of engines initializing, 13-14, and they were clocking at 190-200MHz I think (again depending on whether you were cold booting and starting up the unit after it had been running for a bit).

I have flashed it, and it ended with chip near LED7 fired up after 5 seconds I have turned it on after reflashing  

try ck's http://ck.kolivas.org/apps/cgminer/BitForce_SC/BitForce_SC_1.2.5ck.elf.zip  you dont have to compile it use it at the memories stage..

reflashed with this change (#define __PRODUCT_MODEL_JALAPENO__ ) - no result again

I saw this one, it is nice one.

Switch to the latest versions of mining software, also check the firmware you used, there is another define (#define __PRODUCT_MODEL_JALAPENO__) which must be set for the Jalapeno line of products. If you have anything else defined it will probably upset it.

  you make sure program right mcu for your Jal.

upgraded cgminer to 3.4.0 - no any changes.
I have used AVR Dragon, compiled the firmware with Atmel Studio

   tell us more what kind jtag did you use and what kind firmware file you use  .hex or bin?

yes, I have 3.3.2 cgminer installed...

its good that uve read the dependencys for the newer firmwares
for firmware 1.2.5++ you need cmigner 3.3.2. not 3.3.1

I have the same problem with my Jalapeno.
I have flashed it with default __ASIC_FREQUENCY_ACTUAL_INDEX=7
and got this problem.
Reflashed with __ASIC_FREQUENCY_ACTUAL_INDEX 5   - same problem again...
with __ASIC_FREQUENCY_ACTUAL_INDEX 1 - same problem.
Also after upgrade there is only one big LED4 blinking and LED1 (power), but before upgrade there 2 LEDs on the other side of board was on too...


How can I get it fixed?

Thanks

Thanks! :-)
There is also no reason this shouldn't work on other 3.3v JTAG supporting devices, so long as UrJTAG can recognise the chips involved... I'd guess this would work on other ASIC devices (non BFL) too, so long as they have JTAG ports and header components on their boards.

EDIT:
Actually, I can't think of any reason this wouldn't work on other embedded ARM based linux boards with exposed GPIO pins, such as the BeagleBone or similar. Anyone care to try it out? The instructions should be virtually the same, but you will need to map the GPIO pins to suit your device.