Topics created by luz

@luz said

unfortunately, after a seemingly perfect start with the patches from 20 days ago, the mt76 again behaves erratically for me as well.

Some days it works fine without a hitch for a long time, and then other days (like yesterday) performance is extremely poor and there are a lot of lengthy connection dropouts - without any change in the setup or wifi environment (as far as I can tell).

This is a guess based on a hunch ... looking at a discussion at the Linux wireless patch, referenced by the LEDE developers you sited - I see some code that changes a value based on the wifi channel. Perhaps some of these channel dependent values are bad code ...? Or, I have often seen Omegas jump to another wifi channel in the boot process when wifi is initialized. Here I used the free Android app Wifi Analyzer and sometimes see the Omega2 change it's AP wifi channel during the boot. Have you observed if firmware with the Mt76 patch might work fine on some wifi channel and not well on another? Perhaps there is a bug here, could that channel related value be wrong if and when the Omega2 switches the wifi channel?!

If you see some merit in this hypothesis, during the Omega boot you can observe the wifi channel behavior and assignment using an app like Wifi Analyzer, running on your phone or other tablet.

Crickets and tumbleweed

Re: [WS281x](SK6812 driver for the Omega2? [Solved])

Hi.
In the last days I played a bit with Python to get the WS281x working wirth Luz' module.
As I want to use HLS color schema (it allows to change the luminosity of the color by only one number), I programmed a function HLS to RGB color string:

def hls2rgb(h,l,s): r, g, b = colorsys.hls_to_rgb(h,l,s) shr = str(hex(int(r * 255.0))) shg = str(hex(int(g * 255.0))) shb = str(hex(int(b * 255.0))) # print ([int(255.0*r), int(255.0*g), int(255.0*b)]) if len(shr) == 3: shr = shr[0:2] + str(0) + shr[2] if len(shg) == 3: shg = shg[0:2] + str(0) + shg[2] if len(shb) == 3: shb = shb[0:2] + str(0) + shb[2] col_led_string = shr[2:4].decode('hex') +shg[2:4].decode('hex') + shb[2:4].decode('hex')

By using the following additional function, it allows using a 2 dimensional color matrix which is converted in the corresponding hex color string needed for the module. (It might be useful and easier to use a matrix to handle LED chains instead of a string of hexadigitals)

def hls2rgb_hexstring(hls_matrix): dim1 = len(hls_matrix) try: dim2t = len(hls_matrix[0]) except: dim2t = 0 if dim2t == 0: dim2 = dim1 dim1 = 1 else: dim2 = dim2t if dim1 == 1: h = hls_matrix[0]/360.0 l = hls_matrix[1]/100.0 s = hls_matrix[2]/100.0 col_led_string = hls2rgb(h,l,s) return col_led_string else: col_led_string="" for i in range(0,dim1): h = hls_matrix[i][0]/360.0 l = hls_matrix[i][1]/100.0 s = hls_matrix[i][2]/100.0 col_led_string = col_led_string + hls2rgb(h,l,s) return col_led_string

To display a color gradient among several LED's (here 40) one has to run this code, which is using both function above:

color_start = 0 color_end = 359 nr_led = 40 lum = 2 sat = 100 colorMatrix = [] for i in range(color_start,color_end, abs(color_end-color_start)/nr_led): colorMatrix.append([i,lum,sat]) #print [i,lum, sat] print colorMatrix with open('/dev/ledchain0','w') as export: export.write(hls2rgb_hexstring(colorMatrix))

@luz Hi,

Finally, I had some time to capture the boot process.GPIO17 and UART TX lines were connected to Saleae Logic's inputs. I recorded the waveform from issuing the reboot command on previously booted system, through U-boot, until the next kernel boot (official Omega2 image).

Since I was not able to upload the captured file to this comment (although the zipped file was smaller than the 2MB limit), I put in on my Google Drive: omega2_boot.logicdata - if any of you interested in.

There are three spot where GPIO17 changes its state:

In U-boot at Resetting MT7628 PHY:

Where it is switched to Ethernet (there is a short period when it seems to configured as GPIO output (for ~70us)).

During kernel boot around MTD partitions check:

This takes ~700us.

And finally, SD init set those pins to normal GPIOs as I figured it out previously:

There are three voltage levels:

~2.5V (I assume this is when the pin is GPIO input and the logic analyzer pulls somewhat down the pin) ~1.5V (when the pin is configured for Ethernet) ~3.3V (probably the pin is configured as GPIO output)

So, based on the above, I suppose, it is proven that U-boot changes the state from normal GPIO to Ethernet.

/sza2

Not yet. Pls be patient.

@fossette said in Any omega hackers at 33C3?:

PS: 6809 is a nice number. My preference is 6502...
I guess it depends on personal experience back in the old days :-) I never had a 6502 based machine, but built a few 6809 ones

@Iker this time the malaware just was a popup ... now i got it.

At least, you guys are using smilies. :tools: It's an excellent start! :grinning:

@Alexander-Pitzer A docker image would be most convenient! But that's something the community could do, once the .config is known (plus maybe some stuff for /files).

Figuring out the right .config by reverse engineering however would be really tedious and completely redundant work, because that .config already does exist - only it's not available! So I still hope Onion will decide to publish it! Any chances for that, @Lazar-Demin?