Experimenting with Jalapeno firmware...

[micax1]

GetInfo=DEVICE: BitFORCE SC0x0a
FIRMWARE: 1.2.90x0aIAR
Executed: NO0x0a
CHIP PARALLELIZATION: YES @ 20x0aQUEUE
DEPTH:400x0a
PROCESSOR 3: 13 engines @ 277 MHz -- MAP: FF8F0x0a
PROCESSOR 7: 15 engines @ 250 MHz -- MAP: 7FFF0x0a
THEORETICAL MAX: 7351 MH/s0x0a
ENGINES: 280x0a
FREQUENCY: 274 MHz0x0a

I can`t go more then 7.2 Ghash.
Please advise how to enable engines on first processor or freq or second.

Thank you!

[Red_Wolf_2]

GetInfo=DEVICE: BitFORCE SC0x0a
FIRMWARE: 1.2.90x0aIAR
Executed: NO0x0a
CHIP PARALLELIZATION: YES @ 20x0aQUEUE
DEPTH:400x0a
PROCESSOR 3: 13 engines @ 277 MHz -- MAP: FF8F0x0a
PROCESSOR 7: 15 engines @ 250 MHz -- MAP: 7FFF0x0a
THEORETICAL MAX: 7351 MH/s0x0a
ENGINES: 280x0a
FREQUENCY: 274 MHz0x0a

I can`t go more then 7.2 Ghash.
Please advise how to enable engines on first processor or freq or second.

Thank you!

You've pretty much maxxed that one out... You might get more by disabling some of the more rigorous checking done in the firmware on bootup, but chances are if the engine is defective you'll just end up with a higher HW error count.

[stridergt]

http://randomcontent.wolfnexus.net/RandomSite/reflashing-a-butterfly-labs-jalapeno-with-only-a-raspberry-pi/

I followed Red_Wolf_2's instructions and when I run jtag>detect I receive "warning: TDO seems to be stuck at 0error: not found: queue is empty"

I am connecting the pins based on the circuit board markings meaning:
 
pin 1 on jalapeno is the closest pin to the nearby corner edge and pin 9 is the last pin in the same 5pin row

pin 2 on the raspberry pi is the closest to the nearby corner edge and pin 26 is the last pin in the same 13pin row

Am I doing something wrong with the pin numbering or cable connections? I am using old internal cd rom to sound card 3/4 pin cables
Could it be a software problem? I think my jalapeno is fairly typical with the cut heatsink and firmware 1.0.0

I used noobs_v1_3_2.zip installation and chose raspbian (according to the release notes date, it is the 25-09-2013)
Installed srecord, git, bison, flex, autoconf, libtool, gettext, automake and python-dev using apt-get
Am I missing a package?
I used su (and even tried sudo jtag) but the same jtag>detect error message appears

BTW run sudo apt-get upate BEFORE installing the python-dev package in order to avoid python.h file missing during make

 
Thank you in advance

Solved it. I changed the cables, so it was probably a faulty one that generates the above error message. I also used this cabling/power up sequence:
Connect all pin cables unpowered, power up jalapeno (no usb), then power up raspberry pi. -I noticed that if you power up jalapeno after raspberry pi the HDMI signal blanks for a moment-

[lightfoot]

So I'll document the saga of trying to boost this Jally with more chips. First, code issues.

I'm still waiting on the chips to arrive, but since I have been running CK's 1.25 elf (which gives me .5% errors, 40c temps with the case closed, and a nice little 7.4gh speed on my crap chips) I will need to upgrade to 1.2.9 to use the new chips with the old ones. So I figured I would test upgrade before putting the chips on.

Glad I did.

First I flashed Tarkin's mods. Looks like he is using the 1.2.9 base code, with serious tweaks. Oddly enough I can't recompile it, AVR blows up looking for a /dev hard disk on my Windows box. Might be a code dependency in there, I'll look. But the supplied elf does work and loads up.

8.1gh speed, but with 30% errors as reported by BFG. WOW. More importantly the long term stats (third of the three percentages) is only 6.8%, I think this means I am hashing but am getting *less* throughput because once again my chips suck. I should just float them off and run with all new chips. Maybe when they hit a buck a chip or something.

So I went with the stock BFL 1.2.9. Compiled it on Atmel, no errors, hundreds of warnings and all that. Flashed it to the jally, hooked it up, no hashing. Front light would come on, then after a few seconds flash fast.

Oh that did a number on my heart. Tried recompiling and loading, still fast flash. So I reloaded ck's 1.2.5 and all is well again.

Questions:

Tarkin: Did you code a hard dependency in your changes? I'd like to remove it if so, seems to be blowing up Windows 7 and Atmel.

CK: Have you done whatever you did for 1.2.9? I love your changes the most, sending you some bitpennies in thanks.

Anyone: Why the hell is stock 1.2.9 blowing up?

Worst case I could run Tarkin's elf, but I am really glad I did this before soldering on new chips. Moral is to always do things one step at a time :-)

C

[danattacker]

I told someone the changes I made to stock 1.2.9 a while back...

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

[lightfoot]

I told someone the changes I made to stock 1.2.9 a while back...

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

Interesting. I remember that; was it necessary to get it to not flash?

Maybe the issue is little_single; it's looking for a pair of chained boards. Hm.

[danattacker]

I don't know. I never complied the firmware without any changes. But, you should try setting it to little single at least.

If you still have trouble, I can PM you a link to the firmware I am using.

Interesting. I remember that; was it necessary to get it to not flash?

Maybe the issue is little_single; it's looking for a pair of chained boards. Hm.

[lightfoot]

I don't know. I never complied the firmware without any changes. But, you should try setting it to little single at least.

If you still have trouble, I can PM you a link to the firmware I am using.

Interesting. I remember that; was it necessary to get it to not flash?

Maybe the issue is little_single; it's looking for a pair of chained boards. Hm.

Sounds good. Looking through the code yesterday I can see that compiling JP or LS has some impact. I'll try it again once the chips come in (Thursday or Friday is my guess). Power supply may take a bit longer; so I'll just do two chips and run on the crap power supply for a few days.

C

[FalconFour]

Little status post here for those curious about the fringe of hacking this thing... last night I spent a few hours compiling/assembling (hardware/software), adjusting, tweaking, and actually successfully programming my Jalapeno using only an Arduino. I think this effectively lifts all limitations on what JTAG programmer you can use

I compiled 1.2.9 with some comment adjustments in the config code. As others have noted, the code seems to be haphazardly thrown together with huge swaths of code commented out (like, in my case, the routines to test chips on startup - commented out by default). It compiled in AVR Studio, then I took the HEX file and made a BIN out of it - then for the next 2.5 hours, the Arduino and the Jalapeno had a conversation with the help of UrJTAG and Ubuntu. Finally, when it moved on to verifying (and a few pages passed by without errors), I killed the program and rebooted the Jally.

It worked! Sort of. It boots up, lights up the 2 LEDs for the two chips, and responds to ID commands (ZCX, etc), indicating the new firmware is there. Chips now running at 300MHz, which is far more than I expect it to run at (but with poor commenting in the code, I couldn't tell what I was setting it to). But that's all it will do now. The moment I fire up a miner, the Jally knocks out one of the chip LEDs and goes into a hard-lock until I power-cycle it.

Not bad for the first guy flashing a Jally using only an Arduino and about 30% custom code made up on the spot (on both UrJTAG's source code and in Arduiggler's code). When I get back to it today I'll give it another go.

Damn shame the "set frequency factor" (ZVX + 0x04 + 4-byte code) command interpreter function is broken - always saying "INVALID DATA" no matter what it's given, probably due to a broken wait/timeout loop mechanism (killing the command entry too early like it does with Z*X commands if not copied/pasted all at once). Probably could use that command to get the firmware working as it is now

[erk]

Little status post here for those curious about the fringe of hacking this thing... last night I spent a few hours compiling/assembling (hardware/software), adjusting, tweaking, and actually successfully programming my Jalapeno using only an Arduino. I think this effectively lifts all limitations on what JTAG programmer you can use

I compiled 1.2.9 with some comment adjustments in the config code. As others have noted, the code seems to be haphazardly thrown together with huge swaths of code commented out (like, in my case, the routines to test chips on startup - commented out by default). It compiled in AVR Studio, then I took the HEX file and made a BIN out of it - then for the next 2.5 hours, the Arduino and the Jalapeno had a conversation with the help of UrJTAG and Ubuntu. Finally, when it moved on to verifying (and a few pages passed by without errors), I killed the program and rebooted the Jally.

It worked! Sort of. It boots up, lights up the 2 LEDs for the two chips, and responds to ID commands (ZCX, etc), indicating the new firmware is there. Chips now running at 300MHz, which is far more than I expect it to run at (but with poor commenting in the code, I couldn't tell what I was setting it to). But that's all it will do now. The moment I fire up a miner, the Jally knocks out one of the chip LEDs and goes into a hard-lock until I power-cycle it.

Not bad for the first guy flashing a Jally using only an Arduino and about 30% custom code made up on the spot (on both UrJTAG's source code and in Arduiggler's code). When I get back to it today I'll give it another go.

Damn shame the "set frequency factor" (ZVX + 0x04 + 4-byte code) command interpreter function is broken - always saying "INVALID DATA" no matter what it's given, probably due to a broken wait/timeout loop mechanism (killing the command entry too early like it does with Z*X commands if not copied/pasted all at once). Probably could use that command to get the firmware working as it is now

I have an Arduino nano board lying around, would that be good enough? I love playing with the Arduino IDE it's nice and easy for me.

[FalconFour]

Anything with 5 I/O pins would work - the code is entirely made of "bit-banging", which is why it took 2.5 hours (YES! With tightly optimized code!) to program. It's absolutely a "desperate" measure, but from what I've seen, UrJTAG is extraordinarily careful with the commands it performs, checking and double-checking everything to account for "dirty" adapters like this.

Just a whole hell of a lot of modifications to the code, though, which made it program in less than 5 hours as it was originally running. UrJTAG is from LukeJr's git clone, patched with Arduiggler-urjtag's modified code to support the interface. Arduiggler itself was partially re-written to implement bit-banging in a more efficient way. So it's not exactly stock "go grab these things and run it like this"

[FalconFour]

Okay, so my Jally is now happily crunching along with the BitForce_SC_1.2.5ck.elf firmware at 8.5-8.9Gh/s, 39C, and about 1% HW errors. Same setup - just converted the firmware and fed it to UrJTAG in the same way as I did last time with the botched-compile firmware. Once it got to "Verifying" (and I slept through the programming, so it was a good halfway through verifying), I canceled it and fired up the board. Took a few seconds, and it finally came-to with 2 LEDs and ready to roll.

So, in the interest of helping the interwebnets, I'm posting a thread with the info for doing it with an Arduino.

[erk]

Okay, so my Jally is now happily crunching along with the BitForce_SC_1.2.5ck.elf firmware at 8.5-8.9Gh/s, 39C, and about 1% HW errors. Same setup - just converted the firmware and fed it to UrJTAG in the same way as I did last time with the botched-compile firmware. Once it got to "Verifying" (and I slept through the programming, so it was a good halfway through verifying), I canceled it and fired up the board. Took a few seconds, and it finally came-to with 2 LEDs and ready to roll.

So, in the interest of helping the interwebnets, I'm posting a thread with the info for doing it with an Arduino.

I am happy to give it a try, the JTAG programmer I ordered from eBay hasn't turned up yet, and I don't even know if it's compatible with the ATMEL 32bit chips. So the Arduino might be a safer bet.

[FalconFour]

Oh, trust and believe, Arduino is a desperate last measure. ANY, and I mean literally ANY, programmer that labels itself as "JTAG" capable, will be able to program this thing with some tool out there, if I'm able to patch this crap-spree together to make it work. I've got a $20 JTAG programmer on its way from eBay too, and it'll be freeing my Arduino up for other projects as soon as it comes in. So I figure it's best to chronicle my adventures now before I hop, skip, and jump my way gleefully away from 3-hour programming durations

[erk]

Oh, trust and believe, Arduino is a desperate last measure. ANY, and I mean literally ANY, programmer that labels itself as "JTAG" capable, will be able to program this thing with some tool out there, if I'm able to patch this crap-spree together to make it work. I've got a $20 JTAG programmer on its way from eBay too, and it'll be freeing my Arduino up for other projects as soon as it comes in. So I figure it's best to chronicle my adventures now before I hop, skip, and jump my way gleefully away from 3-hour programming durations

Gee you lashed out, I only went for th $8.95 programmer on eBay! My main worry will be identifying it to see its a compatible device. I like your i approach of using Linux rather than Atmel studio as that may not work with the drivers that are shipped with the device. I am more comfortable in Linux than windows anyway.

[mrdaydreamer]

Can you PM me your firmware too ? I got really bad luck and non of the binaries out there can work on my jala, neither my self-compiled one...

I don't know. I never complied the firmware without any changes. But, you should try setting it to little single at least.

If you still have trouble, I can PM you a link to the firmware I am using.

[EzCheese]

So I'll document the saga of trying to boost this Jally with more chips. First, code issues.

I'm still waiting on the chips to arrive, but since I have been running CK's 1.25 elf (which gives me .5% errors, 40c temps with the case closed, and a nice little 7.4gh speed on my crap chips) I will need to upgrade to 1.2.9 to use the new chips with the old ones. So I figured I would test upgrade before putting the chips on.

Glad I did.

First I flashed Tarkin's mods. Looks like he is using the 1.2.9 base code, with serious tweaks. Oddly enough I can't recompile it, AVR blows up looking for a /dev hard disk on my Windows box. Might be a code dependency in there, I'll look. But the supplied elf does work and loads up.

8.1gh speed, but with 30% errors as reported by BFG. WOW. More importantly the long term stats (third of the three percentages) is only 6.8%, I think this means I am hashing but am getting *less* throughput because once again my chips suck. I should just float them off and run with all new chips. Maybe when they hit a buck a chip or something.

So I went with the stock BFL 1.2.9. Compiled it on Atmel, no errors, hundreds of warnings and all that. Flashed it to the jally, hooked it up, no hashing. Front light would come on, then after a few seconds flash fast.

Oh that did a number on my heart. Tried recompiling and loading, still fast flash. So I reloaded ck's 1.2.5 and all is well again.

Questions:

Tarkin: Did you code a hard dependency in your changes? I'd like to remove it if so, seems to be blowing up Windows 7 and Atmel.

CK: Have you done whatever you did for 1.2.9? I love your changes the most, sending you some bitpennies in thanks.

Anyone: Why the hell is stock 1.2.9 blowing up?

Worst case I could run Tarkin's elf, but I am really glad I did this before soldering on new chips. Moral is to always do things one step at a time :-)

C

I'd love to see a full how-to document on adding more chippys to a jally.  Thank you in advance. 

[lightfoot]

So I'll document the saga of trying to boost this Jally with more chips. First, code issues.

I'm still waiting on the chips to arrive, but since I have been running CK's 1.25 elf (which gives me .5% errors, 40c temps with the case closed, and a nice little 7.4gh speed on my crap chips) I will need to upgrade to 1.2.9 to use the new chips with the old ones. So I figured I would test upgrade before putting the chips on.

Glad I did.

First I flashed Tarkin's mods. Looks like he is using the 1.2.9 base code, with serious tweaks. Oddly enough I can't recompile it, AVR blows up looking for a /dev hard disk on my Windows box. Might be a code dependency in there, I'll look. But the supplied elf does work and loads up.

8.1gh speed, but with 30% errors as reported by BFG. WOW. More importantly the long term stats (third of the three percentages) is only 6.8%, I think this means I am hashing but am getting *less* throughput because once again my chips suck. I should just float them off and run with all new chips. Maybe when they hit a buck a chip or something.

So I went with the stock BFL 1.2.9. Compiled it on Atmel, no errors, hundreds of warnings and all that. Flashed it to the jally, hooked it up, no hashing. Front light would come on, then after a few seconds flash fast.

Oh that did a number on my heart. Tried recompiling and loading, still fast flash. So I reloaded ck's 1.2.5 and all is well again.

Questions:

Tarkin: Did you code a hard dependency in your changes? I'd like to remove it if so, seems to be blowing up Windows 7 and Atmel.

CK: Have you done whatever you did for 1.2.9? I love your changes the most, sending you some bitpennies in thanks.

Anyone: Why the hell is stock 1.2.9 blowing up?

Worst case I could run Tarkin's elf, but I am really glad I did this before soldering on new chips. Moral is to always do things one step at a time :-)

C

I'd love to see a full how-to document on adding more chippys to a jally.  Thank you in advance. 

Chips are in my mailbox; I'll take some pictures.

[minternj]

I dont think you could just add more chips to a jally. Can the board support that extra load?

[erk]

I dont think you could just add more chips to a jally. Can the board support that extra load?

More like are all the components there to support more chips correctly or have they been left off?