dangole has quit [Remote host closed the connection]
dangole has joined #openwrt-devel
torv has quit [Ping timeout: 483 seconds]
Gaspare has quit [Quit: Gaspare]
dangole has quit [Ping timeout: 480 seconds]
Gaspare has joined #openwrt-devel
Gaspare has quit [Ping timeout: 480 seconds]
isak has quit [Remote host closed the connection]
danitool has quit [Quit: Cubum autem in duos cubos, aut quadratoquadratum in duos quadratoquadratos]
mzvd has joined #openwrt-devel
mzvd has quit [Remote host closed the connection]
mzvd has joined #openwrt-devel
mzvd has quit [Read error: Connection reset by peer]
mzvd has joined #openwrt-devel
mzvd has quit [Read error: Connection reset by peer]
mzvd has joined #openwrt-devel
mzvd has quit [Read error: Connection reset by peer]
mzvd has joined #openwrt-devel
mzvd has quit [Read error: Connection reset by peer]
mzvd has joined #openwrt-devel
mzvd has quit [Read error: Connection reset by peer]
mzvd has joined #openwrt-devel
mzvd has quit [Read error: Connection reset by peer]
Tapper has quit [Ping timeout: 480 seconds]
aiyion has quit [Remote host closed the connection]
aiyion has joined #openwrt-devel
mzvd has joined #openwrt-devel
mzvd has quit [Read error: Connection reset by peer]
<philipp64>
how do people work around not having associative arrays in busybox shell (ash) when writing complex scripts?
mzvd has joined #openwrt-devel
<svanheule>
mrnuke: if an LED have a label on the device with "5GHz" or "5G", it would make sense to specify that it triggers on activity from that phy. But not all triggers are hardware related, so I agree it's a bit of a grey area.
mzvd has quit [Read error: Connection reset by peer]
mzvd has joined #openwrt-devel
<dwfreed>
philipp64: don't use shell?
* dwfreed
ducks
<dwfreed>
you could abuse eval to make prefixed var names, as long as your keys are valid as shell vars
mzvd has quit [Read error: Connection reset by peer]
Misanthropos has quit [Ping timeout: 480 seconds]
mzvd has joined #openwrt-devel
bluew has quit [Ping timeout: 480 seconds]
Misanthropos has joined #openwrt-devel
<Lechu>
hurricos: nope - regarding that Ruckus AP, there are external 74LV164 shift registers attached to each chip using GPIO15 for clock and GPIO16 for data. And they drive diode switches used to selectively cut off antenna segments, seven per band. IMO way too advanced to configure that in EEPROM.
<Lechu>
So it has to be done in SW, then. Even using bit-banging SPI it would be plenty fast - I think they did it all from kernel, though - attaching antenna configuration field to a STA structure in driver.
<Lechu>
spi-gpio driver I bound to it could do 1,5MHz clock in SW over the slower PCI radio, using just GPIOs it did around 3MHz.
<mrkiko>
Namidairo: thanks! O h - I don't have the device. Was only curious since I was under the (probably wrong at this point) impression that Xiaomi devices where pretty complicated to handle due to bootloaders not helping with recovery and/or signed firmwares and so on
mzvd has joined #openwrt-devel
mzvd has quit [Read error: Connection reset by peer]
thilde_ has left #openwrt-devel [#openwrt-devel]
mzvd has joined #openwrt-devel
goliath has joined #openwrt-devel
valku has joined #openwrt-devel
Kali_ has quit [Remote host closed the connection]
mzvd has quit [Read error: Connection reset by peer]
mzvd has joined #openwrt-devel
mzvd has quit [Read error: Connection reset by peer]
matteo| has joined #openwrt-devel
matteo has quit [Ping timeout: 480 seconds]
mzvd has joined #openwrt-devel
mzvd has quit [Read error: Connection reset by peer]
<hurricos>
and no idea whether u-boot will be happy letting you tell it what the initial registers should be, it tends to manipulate what you send to `bootm`
<hurricos>
I'll check when I get home
srslypascal is now known as Guest4932
srslypascal has joined #openwrt-devel
mzvd has quit [Read error: Connection reset by peer]
mzvd has joined #openwrt-devel
Guest4932 has quit [Ping timeout: 480 seconds]
mzvd has quit [Read error: Connection reset by peer]
philipp64 has quit [Quit: philipp64]
mzvd has joined #openwrt-devel
mzvd has quit [Read error: Connection reset by peer]
<tmn505>
Question to IPQ experts. The router I'm trying to port has an update from vendor, which looks suspicious, as it wants to also update U-Boot. This is binwalk output from both: https://paste.debian.net/plain/1247131. The new U-Boot has additional 'OpenSSL encryption, salted, salt: 0x8000000'. Should I be worried about this update enabling Secure Boot?
<tmn505>
For the record vendor fimwares are encrypted with AES-CBC-128, so that OpenSSL addition got me suspicious. What should I look for if the new U-Boot want's to blow a fuse?
<robimarko_>
Thats almost impossible to figure out from a binary
<tmn505>
damn
<robimarko_>
You can try and see if the kernel has a custom ELF or QCA-s mbn header