Experimenting with Jalapeno firmware...

[danattacker]

This may work as well to reprogram the ATMEL MCU. What do you guys think?

http://www.ebay.com/itm/USBASP-USBISP-AVR-Programmer-USB-ATMEGA8-ATMEGA128-ATMEL-AVR-ATmege-AT90-ATtiny-/190855600470?pt=LH_DefaultDomain_0&hash=item2c6fe15956

I don't think it will work. It looks like an ISP programmer, not a JTAG programmer.

[danattacker]

You can access that straight through the usb iirc, sink the reset pins and it re-initializes in programing mode. Dfu-programmer has more details on how to talk to it in that state.

Yes, I did read about the USB bootloader. However, I don't think it would be easily accessible because the usb port goes to the FTDI chip, not the microcontroller. And, the USB bootloader could have also been overwritten.

[jelin1984]

it will be great to have the firmware of jalapenos

[whitefeather]

Current firmware theoretically tests the hardware error count and clocks accordingly when you're starting it up, so theoretically you should let it cool down before firing it up again for it to choose the higher rate

+1

[danattacker]

Nasser replied to my post on the BFL forums confirming some of the settings in std_def.h, here's his reply...

in Std-Def.h, the "__PRODUCT_MODEL_LITTLE_SINGLE__" should be defined and other product types must be commented. Also the __ASIC_FREQUENCY_ACTUAL_INDEX should be set to like 7 for 274MHz operation. Higher will increase speed but the chips may not support it and hang. The safe value for it is '0'.

I just asked him about the __DO_NOT_TUNE_CHIPS_FREQUENCY being set to 1. Hopefully he will give us some insight on that.

[danattacker]

Nasser's reply about __DO_NOT_TUNE_CHIPS_FREQUENCY:

Frequency tuning is Regressive. Meaning if you set the frequency-index to 9, the firmware tests the chips at 281MHz. If they don't behave correctly, it reduces it one step down and repeats the test. Now if "DO NOT TUNE CHIP FR..." is set, it wont run these tests...


I should be getting my AVR Dragon within the next 2 hours. I made my own 10-pin JTAG cable since I don't think the Dragon comes with one. I'll let you guys know how it works out.

[danattacker]

Ok guys. The good news is that my Jalapeno is alive again. I downloaded the firmware from the Jalapeno and it was obviously trashed. Somehow, it looked like the actual JTAG commands that were sent using that crappy software got written to the flash. It was also a challenge getting the JTAG hooked up to the Jalapeno PCB because the heat sink was in the way of the cable, and since I had to remove the heat sink, I needed to way to cool it when I applied power. I ended up putting masking tape around the ASIC chips and pressing the metal backplate on the top of the chips. Fortunately, the metal didn't get that hot when I was programming. But, when it finished programming, the chips got hot real fast. I guess that was a good sign  ! I compiled the firmware with no changes to the code and although it is working, there are a ton of errors in cgminer. I will see whats up with it later tonight since I have to go someplace soon.

It is now hashing at 8.2 GH/s 

[goxed]

Ok guys. The good news is that my Jalapeno is alive again. I downloaded the firmware from the Jalapeno and it was obviously trashed. Somehow, it looked like the actual JTAG commands that were sent using that crappy software got written to the flash. It was also a challenge getting the JTAG hooked up to the Jalapeno PCB because the heat sink was in the way of the cable, and since I had to remove the heat sink, I needed to way to cool it when I applied power. I ended up putting masking tape around the ASIC chips and pressing the metal backplate on the top of the chips. Fortunately, the metal didn't get that hot when I was programming. But, when it finished programming, the chips got hot real fast. I guess that was a good sign  ! I compiled the firmware with no changes to the code and although it is working, there are a ton of errors in cgminer. I will see whats up with it later tonight since I have to go someplace soon.

It is now hashing at 8.2 GH/s 

So 8.2GH/s without tons of CGMINER errors?

[danattacker]

So 8.2GH/s without tons of CGMINER errors?

The cgminer errors seem to have something to do with come kind of hex2str conversion problem. I think that this new firmware is not quite supported by cgminer.

I believe it is indeed hashing at (or near) 8.2 GH/s since uploaded shares is currently ~117 per minute, much higher than i was getting before.

[goxed]

So 8.2GH/s without tons of CGMINER errors?

The cgminer errors seem to have something to do with come kind of hex2str conversion problem. I think that this new firmware is not quite supported by cgminer.

I believe it is indeed hashing at (or near) 8.2 GH/s since uploaded shares is currently ~117 per minute, much higher than i was getting before.

Wel this should be a notable milestone

[danattacker]

After letting it run for a while, the average hash rate is 8.225 GH/s and the uploaded share average is now around ~114. Temp is at 45C with case open, 25.5C ambient.

When I was running at 7.65 GH/s, uploaded share average was ~107.
8.225 is a 7.5% increase from 7.65
114 is a 6.5% increase from 107

So, it looks like the increase in hash rate is somewhat proportional to the increase in upload share rate, with the share rate being slightly less possibly due to errors. I should let it run longer though to get a more accurate average. On the pool side, hash rate is averaging ~8.1 GH/s.

__DO_NOT_TUNE_CHIPS_FREQUENCY is set to 1, so it is not tuning the frequency. Also, the frequency value is 7, so it is running at 274 MHz.

This firmware is sending more data than cgminer is expecting, and it is trying to interpret it as nonces. Here's a snippet of what is being output.

 [2013-06-19 16:53:57] BAJ0: incorrect data count (3) will use -6 instead from (
INPROCESS:10x00)
 [2013-06-19 16:53:57] BAJ0: invalid nonce (INPROCESS:10x00) will try to process
 anyway
 [2013-06-19 16:53:58] hex2bin str truncated
 [2013-06-19 16:53:58] BAJ0: invalid nonce - HW error
 [2013-06-19 16:53:58] BAJ0: incorrect data count (7) will use -7 instead from (
COUNT:20x00)
 [2013-06-19 16:53:58] BAJ0: invalid nonce (COUNT:20x00) will try to process any
way
 [2013-06-19 16:53:58] hex2bin str truncated
 [2013-06-19 16:53:58] BAJ0: invalid nonce - HW error

[-ck]

After letting it run for a while, the average hash rate is 8.225 GH/s and the uploaded share average is now around ~114. Temp is at 45C with case open, 25.5C ambient.

When I was running at 7.65 GH/s, uploaded share average was ~107.
8.225 is a 7.5% increase from 7.65
114 is a 6.5% increase from 107

So, it looks like the increase in hash rate is somewhat proportional to the increase in upload share rate, with the share rate being slightly less possibly due to errors. I should let it run longer though to get a more accurate average. On the pool side, hash rate is averaging ~8.1 GH/s.

__DO_NOT_TUNE_CHIPS_FREQUENCY is set to 1, so it is not tuning the frequency. Also, the frequency value is 7, so it is running at 274 MHz.

This firmware is sending more data than cgminer is expecting, and it is trying to interpret it as nonces. Here's a snippet of what is being output.

 [2013-06-19 16:53:57] BAJ0: incorrect data count (3) will use -6 instead from (
INPROCESS:10x00)
 [2013-06-19 16:53:57] BAJ0: invalid nonce (INPROCESS:10x00) will try to process
 anyway
 [2013-06-19 16:53:58] hex2bin str truncated
 [2013-06-19 16:53:58] BAJ0: invalid nonce - HW error
 [2013-06-19 16:53:58] BAJ0: incorrect data count (7) will use -7 instead from (
COUNT:20x00)
 [2013-06-19 16:53:58] BAJ0: invalid nonce (COUNT:20x00) will try to process any
way
 [2013-06-19 16:53:58] hex2bin str truncated
 [2013-06-19 16:53:58] BAJ0: invalid nonce - HW error

Try the latest cgminer from git. They have a different communication in the singles and consequently you have uploaded that firmware, which only the git master for cgminer supports since we didn't hear about it till only a couple of days ago and the jalapenos ran v1.0.0 firmware (the release is 1.2.5).

[vapourminer]

NICE WORK!

OK, just ordered my AVR Dragon from atmel. gonna grab the 6.1 studio software.

did it come with the needed cable?

which heatsink do you have? mine is the heatpipe version, it may have more clearance than the aluminum one.

care to post fairly detailed instructions? Im good with electronics (olde skoole here, TTL stuff) but never programmed via jtag.

[danattacker]

NICE WORK!

OK, just ordered my AVR Dragon from atmel. gonna grab the 6.1 studio software.

did it come with the needed cable?

which heatsink do you have? mine is the heatpipe version, it may have more clearance than the aluminum one.

care to post fairly detailed instructions? Im good with electronics (olde skoole here, TTL stuff) but never programmed via jtag.

It does not come with a cable.

I have the non-heatpipe version.

I'll help you out, it's not terribly complicated anyways. Good luck!

[vapourminer]

It does not come with a cable.

I have the non-heatpipe version.

I'll help you out, it's not terribly complicated anyways. Good luck!

thats what I was hoping to hear

read the instructions, back up the original firmware, compile the jally code,  program it, compile cgminer from git, and away it goes (hopefully).

I hope not to need your step by step help, but I am glad you are offering.

4-7 days shipping time. plenty of time to whip up a cable.

[danattacker]

I just finished compiling the latest cgminer from git and the errors are gone, as expected 

[tom99]

can you take picture of 7 Gh/s upgrade please and everyone want to see it.


Thank you

[-ck]

I just finished compiling the latest cgminer from git and the errors are gone, as expected 

That's because of the access we had to a minirig yesterday to work on the new firmware. In essence, you are now running a picorig

[TheSwede75]

Damn, you should totally upload your modified image/firmware so that other 7 gh jala owners can bump their speed as well.

[danattacker]

Damn, you should totally upload your modified image/firmware so that other 7 gh jala owners can bump their speed as well.

The thing is, I didn't modify the code at all. I just compiled it and flashed it on the microcontroller.

I'm about to bump up the clock frequency. But, I'm probably not going to increase it any more after this since it isn't recommended and I would also have to figure out the format for the commands being sent to the ASICs. I'll try to get a picture up as well.

And a stat update: 8.222 GH/s, A:29293 R:96 HW:252 U:113.89/m. The HW error rate is definitely higher than it was before, but still tolerable.