Pages:
Author

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

legendary
Activity: 4354
Merit: 3614
what is this "brake pedal" you speak of?
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.
-ck
legendary
Activity: 4088
Merit: 1631
Ruu \o/
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).
full member
Activity: 121
Merit: 100
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
legendary
Activity: 1946
Merit: 1006
Bitcoin / Crypto mining Hardware.
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
full member
Activity: 121
Merit: 100
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.
legendary
Activity: 1946
Merit: 1006
Bitcoin / Crypto mining Hardware.
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  Grin! 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  Shocked

So 8.2GH/s without tons of CGMINER errors?
full member
Activity: 121
Merit: 100
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  Grin! 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  Shocked
full member
Activity: 121
Merit: 100
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.
full member
Activity: 121
Merit: 100
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.
member
Activity: 97
Merit: 10
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 Wink

+1
legendary
Activity: 2408
Merit: 1004
it will be great to have the firmware of jalapenos
full member
Activity: 121
Merit: 100
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.
full member
Activity: 121
Merit: 100

I don't think it will work. It looks like an ISP programmer, not a JTAG programmer.
full member
Activity: 121
Merit: 100
What would also be nice is if BFL would post on their website compiled firmware like they do with their FPGA products, although their ASIC line isn't meant to be user programmable. Maybe I should ask them.
hero member
Activity: 516
Merit: 500
Maybe someone can try and copy their firmware for you to unbrick yours.

+1

a public repository of stock and "tuned" firmwares for all devices would be great.
If someone could send me the images I would host and maintain a small website for it.

Cheers

     one4many
cp1
hero member
Activity: 616
Merit: 500
Stop using branwallets
Maybe someone can try and copy their firmware for you to unbrick yours.
full member
Activity: 121
Merit: 100
With the recent release of the source code for the firmware, I decided to take a look at it and I installed AVR studio. The project loaded up and compiled fine.

is there any particular version of avr studio I need? Im definably going to be messing with mine.

Im hoping a cheaper programmer like this one will work:

http://www.fasttech.com/product/1023000-atmel-avr-jtag-usb-in-circuit-debugger-programmer


best of luck getting it going again!



I downloaded the latest version, Atmel Studio 6.1. Sorry, I accidentally said AVR instead of Atmel Studio.

I'm not sure if that programmer will work. Looks like it emulates AVR JTAG ICE, but I think you need at least JTAGICE mkII. I'm no Atmel expert though, so I'm not sure. I would have gone cheaper, but looks like AVR Dragon is the cheapest while still knowing for sure it will work.
legendary
Activity: 4354
Merit: 3614
what is this "brake pedal" you speak of?
With the recent release of the source code for the firmware, I decided to take a look at it and I installed AVR studio. The project loaded up and compiled fine.

is there any particular version of avr studio I need? Im definably going to be messing with mine.

Im hoping a cheaper programmer like this one will work:

http://www.fasttech.com/product/1023000-atmel-avr-jtag-usb-in-circuit-debugger-programmer


best of luck getting it going again!

full member
Activity: 121
Merit: 100
The firmware specifically distributed appears to be for the single - if you look at what defines are enabled - not the Jalapeno or 5GH or 7GH or whatever it's being called now, so I'm guessing that if you have one that changes clocks, you have firmware that differs from what was distributed. Nasser confirmed that it would clock according to error rate, so I'm assuming that's what's causing your different speeds. Stick it in the fridge.

Yeah, there are definitely some discrepancies in that file. It says __PRODUCT_MODEL_LITTLE_SINGLE__ but further down it says UNIT_FIRMWARE_TYPE is ">>>>JALAPENO>>>>". But, your probably right about the clocks.
Pages:
Jump to: