Experimenting with Jalapeno firmware...

[one4many]

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.

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

    one4many

[danattacker]

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

    one4many

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

https://bitcointalk.org/index.php?topic=235312.0 (the hex file)

[Luke-Jr]

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

    one4many

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

https://bitcointalk.org/index.php?topic=235312.0 (the hex file)

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.

[danattacker]

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

    one4many

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

https://bitcointalk.org/index.php?topic=235312.0 (the hex file)

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.

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

[danattacker]

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


Thank you

Pictures as requested...

[danattacker]

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.

[one4many]

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

    one4many

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

https://bitcointalk.org/index.php?topic=235312.0 (the hex file)

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.

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

  Thx

[-ck]

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.

[kano]

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.

[peterepeat]

Im going to put mine in the fridge for a while before turning it back on.

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

[pvtbrutus]

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:

Chip grades:  Chips come in four grades of performance.  Chips are sold in mixed grade lots.  A grade has 16 engines, B grade has 15 engines, C grade has 14 engines and D grade has no less than 12 engines.  All chips run at a minimum of 250 mhz.  Higher grade chips will run up to 294mhz.

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?

[crazyates]

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.

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

[danattacker]

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

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.

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.

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.

Then it would be something like e.g. ./usbtest.py /dev/ttyUSB0 0x5A56580455550000 would try to set it to 280MHz

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.

[BFL-Engineer]

The GetFrequency and SetFrequency never became operational. The reason is that we realized it's best to determine the frequency on startup. So I'm not sure if the command works at all or not.



Regards,

[danattacker]

The GetFrequency and SetFrequency never became operational. The reason is that we realized it's best to determine the frequency on startup. So I'm not sure if the command works at all or not.

Regards,

Ah, ok that explains it. Thank you.

[kano]

I don't suppose anyone has details about how to compile the firmware on linux?

[Gomeler]

I don't suppose anyone has details about how to compile the firmware on linux?

Virtualbox? 

[Luke-Jr]

I don't suppose anyone has details about how to compile the firmware on linux?

I have a "make" branch on GitHub with a Makefile.
This is still very WIP-quality: I don't know if the output works at all.

But first, you need a toolchain...

Here's how to get one on Gentoo (not intended for novice users!):

Code:

crossdev -t avr32 -s1  # this will fail! but sets up stuff for us


# BEGIN binutils

mkdir -p /etc/portage/patches/cross-avr32/binutils/
cd /etc/portage/patches/cross-avr32/binutils/
PATCHES="
	20-binutils.2.20.1-avr32-autoconf.patch
	30-binutils-2.20.1-avr32-bfd.patch
	31-binutils-2.20.1-avr32-binutils.patch
	32-binutils-2.20.1-avr32-gas.patch
	33-binutils-2.20.1-avr32-include.patch
	34-binutils-2.20.1-avr32-ld.patch
	35-binutils-2.20.1-avr32-opcodes.patch
	40-binutils-2.20.1-avr32-fixes.patch
	41-binutils-2.20.1-avr32-fpu.patch
	42-binutils-2.20.1-avr32-bug-7435.patch
	50-binutils-2.20.1-avr32-mxt768e.patch
	51-binutils-2.20.1-avr32-uc3c.patch
	52-binutils-2.20.1-avr32-uc3l0128.patch
	53-binutils-2.20.1-avr32-uc3a4.patch
	54-binutils-2.20.1-avr32-uc3d.patch
	55-binutils-2.20.1-avr32-uc3l3l4.patch
"
for patch in $PATCHES; do
	wget http://distribute.atmel.no/tools/opensource/avr32-gcc/binutils-2.20.1/$patch
done

# Possibly change make.conf to MAKEOPTS=-j1 - not sure if necessary


USE='-* multitarget' emerge =cross-avr32/binutils-2.20.1-r1

# interrupt build (Ctrl-Z) immediately after patches are applied
cd /var/tmp/portage/cross-avr32/binutils-2.20.1-r1/work/binutils-2.20.1
$EDITOR opcodes/Makefile.am  # find avr-dis.c and add under it: avr32-asm.c avr32-dis.c avr32-opc.c
for d in . gold intl libiberty gprof ld binutils etc gas opcodes bfd; do ( cd "$d"; autoreconf; ); done
fg

aclocal -I config
autoconf
automake
autoheader
for d in bfd opcodes binutils gas ld; do
	pushd $d
	autoconf
	automake
	autoheader
	popd
done
fg

# interrupt build (Ctrl-Z) after bfd has configured
cd /var/tmp/portage/cross-avr32/binutils-2.20.1-r1/work/build/bfd
make headers
fg

# DONE binutils


# BEGIN gcc

mkdir -p /etc/portage/patches/cross-avr32/gcc/
cd /etc/portage/patches/cross-avr32/gcc/
PATCHES="
	30-gcc-4.4.3-avr32.patch
	31-gcc-4.4.3-avr32-rmw.patch
	32-gcc-4.4.3-avr32-sleep-builtin.patch
	33-gcc-4.4.3-avr32-ucr3fp.patch
	34-gcc-4.4.3-avr32-fpu.patch
	35-gcc-4.4.3.avr32-delay-cycles.patch
	36-gcc-4.4.3.avr32-list-devices.patch
	40-gcc-4.4.3-avr32-fpemul-fixes.patch
	41-gcc-4.4.3-avr32-fix-const_int_addr.patch
	42-gcc-4.4.3-avr32-fix-reorg_opt_bug11763.patch
	43-gcc-4.4.3-avr32-4_4_3-upgrade.patch
	44-gcc-4.4.3-avr32-bug-12671.patch
	45-gcc-4.4.3-avr32-bug-7435.patch
	46-gcc-4.4.3-avr32-bug-9675.patch
	50-gcc-4.4.3-avr32-mxt768e.patch
	51-gcc-4.4.3-avr32-uc3c.patch
	52-gcc-4.4.3-avr32-uc3l0128.patch
	53-gcc-4.4.3-avr32-uc3a4.patch
	54-gcc-4.4.3-avr32-uc3d.patch
	55-gcc-4.4.3-avr32-uc3l3l4u.patch
"
for patch in $PATCHES; do
	wget http://distribute.atmel.no/tools/opensource/avr32-gcc/gcc-4.4.3/$patch
done

USE='-*' ACCEPT_KEYWORDS=** emerge =cross-avr32/gcc-4.4.3-r3

# DONE gcc


# BEGIN atmel-headers

layman -a luke-jr
ACCEPT_KEYWORDS=** emerge cross-avr32/atmel-headers

# DONE atmel-headers


# BEGIN newlib

mkdir -p /etc/portage/patches/cross-avr32/newlib/
cd /etc/portage/patches/cross-avr32/newlib/
# skip 10-newlib-1.16.0-avr32-atmel-version.patch
PATCHES="
	30-newlib-1.16.0-avr32.patch
	31-newlib-1.16.0-flashvault.patch
"
for patch in $PATCHES; do
	wget http://distribute.atmel.no/tools/opensource/avr32-gcc/newlib-1.16.0/$patch
done

ln -s /usr/portage/sys-libs/newlib /usr/portage/local/crossdev/cross-avr32/
USE=-* ACCEPT_KEYWORDS=** emerge =cross-avr32/newlib-2.0.0

# interrupt build (Ctrl-Z) immediately after source unpacks
cd /var/tmp/portage/cross-avr32/newlib-2.0.0/work/newlib-2.0.0/
for patch in $PATCHES; do
	patch -p0 <"/etc/portage/patches/cross-avr32/newlib/$patch"
done
cd newlib
autoreconf
fg

# interrupt build (Ctrl-Z) immediately after you see:
#    >>> Install newlib-2.0.0 into /var/tmp/portage/cross-avr32/newlib-2.0.0/image/ category cross-avr32
mkdir -p /var/tmp/portage/cross-avr32/newlib-2.0.0/image//usr/avr32/lib

# DONE newlib


ln -s /usr/lib/binutils/avr32/2.20.1/ldscripts/ /usr/avr32/lib/

[BFL-Engineer]

I don't suppose anyone has details about how to compile the firmware on linux?

Atmel Studio exists on Linux as well.


Regards

[kano]

Hmm after comments from Luke-Jr I've looked in the Fedora repositories and there are
RPMs of all of: gcc-avr32 4.7.1-0.1.20120606.fc18.1, binutils-avr32 2.23.51.0.3-1.fc18 and avrdude 5.11.1-2.fc18 ...
So it's a start at least ...
Damn, I'm gonna end up spending a lot of time with this
(better put it aside until I finish what I'm doing at the moment)