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

DEVICE: BitFORCE SC                                                         
FIRMWARE: 1.2.5                                                               
IAR Executed: NO                                                             
CHIP PARALLELIZATION: YES @ 2                                               
QUEUE DEPTH:40                                                               
PROCESSOR 3: 15 engines @ 289 MHz -- MAP: FFFE                               
PROCESSOR 7: 14 engines @ 275 MHz -- MAP: BFFE                               
THEORETICAL MAX: 8185 MH/s                                                   
ENGINES: 29                                                                 
FREQUENCY: 274 MHz                                                           
XLINK MODE: MASTER                                                             
CRITICAL TEMPERATURE: 0                                             
XLINK PRESENT: NO                                                           
OK

I thought that when __DO_NOT_TUNE_CHIPS_FREQUENCY is 1 it would just set the chosen frequency but I guess that isn't the case.


I saw this in the code and I was wondering if you or ckolivas had implemented it in cgminer but I guess you didn't.


I tried out the command but it didn't seem to be changing the frequencies. I tried several different values to no avail. It was returning two "OK"s so it was accepting the commands.
Perhaps something else needs to be done to get it to change frequency.

Given  your track record, I'd say waiting it out is prolly safer.

Did a Getinfo from my 5gh Jala (firmware 1.0.0) and it seems i have 2 full processors with 15 / 13 engines for a total of 28 engines. The frequency is set to 189mhz (setting 1) although it rapports one processor at 183mhz and the other as 192mhz. Is the frequency maybe a variable and the 189mhz setting a guideline?

According to the BFL website:
My Jala has a grade B and D chip, but they do have the potential to run at 250mhz .

So the summ everything up, if i flash 1.2.5 firmware and set the frequency to setting 5 (253mhz) i shouldn't encounter big problems.

danattacker can you do a Getinfo to get an idea which grade processors you have?

I am not sure if the fridge did it, but I chilled my Jalapeno down, and its been haashing at 7.6GH/s for 24 Hrs, previously it was between 7 and 7.3GH/s. I tried flipping the fan, and noticed the temperature drop by 10°C, however there was no improvement in hash rate. When it was power cylcled hot I did notice a reduction - worst was 6.9 GH/s.

Dont want to switch it off now just in case it was a fluke

Well I bought all the jtag stuff (that I've never used) that you could buy from ngzhang for the Icarus ... so when I get a spare day (never ) I guess I should try also

There are a few differences in the 1.2.5 source firmware.
I spent a bit of time reading through it to do the initial V2 changes in cgminer
(after Luke-Jr told me about them ... and I misunderstood what he said until I read the code )

Firstly it tunes each chip independently - so if one is faster then the other they will run at the 2 different speeds.
In the 1.0.0 firmware this means that it runs at the speed of the slowest chip since it divides each work item up across all the chips and waits for them all to finish to queue the results for the work item.
In the 1.2.? firmware it gives a separate job to each chip. So if one chip is faster than the other, it will do more work over time since it starts the next queued work item as soon as it finishes the current one.

There is a command to set the frequency that's even in the 1.0.0 firmware - but it may be ignored in 1.0.0?
I've not tried this, but ckolivas did and found it seemed to ignore it.
The command to set the frequency is ZVX and the command to read it is ZKX
Reading the code I worked it out to actually set the frequency you need to send 5 bytes after the ZVX:
firstly 0x04 (which means 4 bytes follow - which is required) then 4 bytes of the 'coded' frequency number of which the lower 2 bytes are the number used (the other 2 bytes are ignored)

It seems to be from the table in __ASIC_FREQUENCY_WORDS

The commented out code in ASIC_Engine.c may be the actual values that might work with the standard Jalapeno, but I've not tried myself
According to commented out ASIC_Engine.c
//Set Osc Control to slowest frequency:0000 (highest=0xCD55)
 and
DATAIN = 0x5555; // 280MHz
 and a lot more comments around there.
If you read ASIC_Engine.c it makes a bit more sense and has more info

__ASIC_FREQUENCY_WORDS (in std_defs.c and std_defs.h) says:
const unsigned int __ASIC_FREQUENCY_WORDS [10] = {0x0, 0xFFFF, 0xFFFD, 0xFFF5, 0xFFD5, 0xFF55, 0xFD55, 0xF555, 0xD555, 0x5555};
and
const unsigned int __ASIC_FREQUENCY_VALUES[10] = {189, 233, 240, 246, 253, 260, 266, 274, 283, 291}; // TO BE DETERMINED

If anyone manages to get these doing anything let me know
On linux, in cgminer there is a usbtest.py in the folder that you can send commands and see the replies.
You must stop cgminer (or disable hotplug with java API 'hotplug|0')
then unplug the Jalapeno and plug it back in and it will have a /dev/ttyUSBx
Then it would be something like e.g. ./usbtest.py /dev/ttyUSB0 0x5A56580455550000 would try to set it to 280MHz
If anyone plays with this and actually gets it to work let me know!
If I get around to trying and get any results I'll report back.

For what it's worth, the 5GH ones, which I have one of, report the frequency back at setting 1, so I assume there is heaps of room for raising the frequency given how few hardware errors these units produce - unless you got one of the rare single chip ones which would be running absolutely flat out. Mine has ~.01% HW errors so it's itching to be reprogrammed... wish there was an easier way.

This is what I would have guessed from reading your (original) post ...

  Thx

I did some more testing with different clock frequencies and one test with __DO_NOT_TUNE_CHIPS_FREQUENCY set to 0 (as in it will tune the chips).

The problem is I think I really have a flaky engine or two in my chips. After testing the different frequencies, I went back to the original firmware. I was expecting ~8.2 GH/s like before, but I got ~7.75 and ~8 GH/s. I was able to get it back to 8.2 GH/s after restarting it a few times. So, the results of my tests might be with a missing engine or two. I plan on doing more tests tomorrow with changing the settings for the startup tests done with the engines (making them less vigorous).

With frequency index 8, a little less than 8.2 GH/s, about 3-4% error rate.
With frequency index 9, ~8.1 GH/s, about 10% error rate. It was pretty bad and I don't recommend this setting.
With frequency index 9 and __DO_NOT_TUNE_CHIPS_FREQUENCY set to 0, I was expecting it to slow down the chips but it seems exactly the same as without the chip tuning.
With frequency index 6, I think it was a little less than 8 GH/s (I should have wrote this stuff down), insignificant error rate (only 1 during test).

I think BFL has already determined that 7 is the sweet spot, so that's what I went back to. But, like I said before, there may have been engines disabled and if I can get them working then perhaps the results will be better.

I also just flipped my fan around where the air is blowing down. Now it's about 10C less than what it was getting before.

Alright, I'm taking a break from this until tomorrow.

Pictures as requested...

Oh, ok then. I guess I'll have to post my firmwares at some point.

No, that file is as-is from BFL, I didn't compile it.

I've got one compiled myself, but for all I know it bricks it.
Maybe a bit more poking and I'll try it out.

I believe luke-jr already compiled the unmodified 1.2.5 source code.

https://bitcointalksearch.org/topic/bfl-bitforce-sc-firmware-source-code-235312 (the hex file)

Can you post the image somewhere?
My offer still stands ... I mean in hosting a small site keeping the images for others.

    one4many

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.

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

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

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


Thank you

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

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.

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!