philipp64|work has quit [Ping timeout: 272 seconds]
philipp64|work_ is now known as philipp64|work
nitroshift has joined #openwrt-devel
_whitelogger has joined #openwrt-devel
<damex>
PaulFertser: any idea what could go wrong if Phys with the same setup (only port order changed but links to &phy is correct) as on built in dts does not transmit data on embedded/external dts? no idea where to look at this point
<damex>
it affects <all> phy drivers. generic ( ethernet-phy-ieee802.3-c22 ), vitesse ( vitesse,vsc8504 ) or microsemi ( mscc,vsc8504 )
gch981213 has quit [Read error: Connection reset by peer]
gch9812133 has joined #openwrt-devel
<mangix>
Grommish: hardware acceleration is mostly useless
<Grommish>
Good for hashes
<mangix>
The cost of setting up an instance outweighs any CPU savings
<mangix>
actually, bad for hashes for that reason
<Grommish>
explain?
<damex>
any idea where to find docs about reg-init for various phy's ? vitesse,reg-init = <0x1f 0x00 0x03 0x10 0xff7f 0x80 0x1f 0x00 0x00>; is not documented at'all but seems like it is working
<damex>
i only found marvell reg-init in a kernel tree
<mangix>
Grommish: say you need a single hash computed. the effort to set up an encryption context is more expensive than just computing the hash on CPU
<mangix>
hashing en masse when you use one context is of course fast
<mangix>
hence those openssl results
feriman has joined #openwrt-devel
<Grommish>
Yes, but in the context of a router, it would help packet inspection, no?
<mangix>
do packets use any hashes
<stintel>
damex: probably documented in the datasheet
koniu has quit [Remote host closed the connection]
<Grommish>
I'm reading the link :) I'm just flipping switches to see what breaks at the moment :)
koniu has joined #openwrt-devel
voxadam has quit [Quit: WeeChat 2.8]
voxadam has joined #openwrt-devel
<damex>
stintel: but kernel/module have to use that reg-init. i don't see -anything- that uses it for vitesse phy.
black_ant has joined #openwrt-devel
black_ant has joined #openwrt-devel
black_ant has quit [Changing host]
<stintel>
where did you find that vitesse,reg-init = <0x1f 0x00 0x03 0x10 0xff7f 0x80 0x1f 0x00 0x00>; ? maybe git blame and contact the author?
<damex>
stintel: extracted from built in dts :D
<PaulFertser>
That's from decompiled vendor DT
<PaulFertser>
It's not really dts (source0 that's built in, it's dtb/fdt.
<stintel>
ah, does the vendor use upstream or some unknown driver instead?
<PaulFertser>
Patched upstream driver which apparently ignores vitesse,reg-init attribute
<damex>
PaulFertser: official sources seem to ignore it too ;p
<damex>
'vendor sources'
<PaulFertser>
damex: yes, that's what I meant/said
<damex>
what it is doing there if even vedor do not use it?
<damex>
s/vedor/vendor/
<damex>
gonna check other vendor sources. current branch is based on debian 9 and previous one is debian 7
dedeckeh has joined #openwrt-devel
<damex>
mangix: but there is a benefit when you need to compute lots of hashes
am0rphis has quit [Ping timeout: 240 seconds]
<rsalvaterra>
Grommish: Which crypto engine are you using?
Nick_Lowe has joined #openwrt-devel
voxadam_ has joined #openwrt-devel
<mangix>
damex: I'd love to see a use case
aszeszo has quit [Quit: aszeszo]
voxadam has quit [Ping timeout: 260 seconds]
<damex>
mangix: ipsec offload maybe?
am0rphis has joined #openwrt-devel
<damex>
you won't host a website so openssl offload is kinda meaningless (although might be useful)
<damex>
s/openssl/ssl/
aszeszo has joined #openwrt-devel
voxadam_ has quit [Quit: WeeChat 2.8]
voxadam has joined #openwrt-devel
ivanich has quit [Quit: Konversation terminated!]
am0rphis has quit [Ping timeout: 240 seconds]
ivanich has joined #openwrt-devel
ivanich has quit [Remote host closed the connection]
ivanich has joined #openwrt-devel
ivanich has quit [Write error: Broken pipe]
ivanich has joined #openwrt-devel
ivanich has quit [Quit: Konversation terminated!]
ivanich has joined #openwrt-devel
f00b4r0 has joined #openwrt-devel
matteo has joined #openwrt-devel
<f00b4r0>
gch9812133: ping?
Guest88073 is now known as lep-delete
lep-delete is now known as Guest88073
Guest88073 is now known as lep-delete
lep-delete is now known as Guest88073
<mangix>
damex: yeah vpn is pretty much the only one.
<mangix>
then again, everything should transition to wireguard
<damex>
mangix: there is also offload for forwarding in that cavium3 ;p
<damex>
also lots of other variants of offload present ;p
<damex>
mangix: wireguard might benefit from it too if there is ChaCha20 support :)
<mangix>
which will never happen :)
<mangix>
aes is stupid fast in hardware by design
dedeckeh has quit [Remote host closed the connection]
<mangix>
chacha20 is not as fast when implemented in ASIC. but it is faster in software
<damex>
oh, didn't knew ;p
<damex>
mangix: could there be other benefit like - offload it so cpu could be used for <somethin else> ?
<mangix>
so hardware acceleration is mainly used for power savings AFAIK. this is how it is on Android.
<mangix>
implementing stuff in ASIC is a time/space tradeoff
<gch9812133>
f00b4r0: pong - FYI: kernel zboot doesn't contain any relocation code. The main kernel relocation code is for a completely different purpose.
gch9812133 is now known as gch981213
<f00b4r0>
gch9812133: relocate and lzma-loader both copy (on MIPS) the kernel's head.S relocation code which is executed when the kernel is jumped into, unless I'm mistaken
<f00b4r0>
gch981213: in any case, such code wouldn't be portable.
<f00b4r0>
imho it should be avoided at all costs
<gch981213>
f00b4r0: lzma-loader copies itself to the linked address if u-boot placed it elsewhere. kernel relocation copies itself to (a maybe random) address.
<f00b4r0>
there are already several versions of this code for MIPS alone, with various bugs and levels of bitrot
<f00b4r0>
gch981213: yes, but it's the same (assembly) code which is executed. And by the way, those multiple copies take time during boot.
<gch981213>
f00b4r0: squashing the long image recipes with various reusable bits into one long definition is also not acceptable.
<f00b4r0>
sure, let's try to fix that in the build instead of "fixing" that at runtime
<gch981213>
f00b4r0: The kernel code can't be used to do what we are currently doing with our relocation.
<f00b4r0>
it makes no sense to penalize the boot process for our build system shortcomings
<gch981213>
so that's not necessarily a duplication
<f00b4r0>
i still don't see why we would need to relocate anything when ELF-booting a zboot image
<f00b4r0>
if we move things around as soon as we jump into code it suggests we're not taking advantage of the ELF loader at all
<gch981213>
f00b4r0: not necessary for zboot image. But is required for other devices.
<f00b4r0>
gch981213: yes, and I'm afraid you're already strapping other constraints on this particular PR: please bear in mind the initial goal is to get rid of any intermediary loader for ELF-capable bootloaders
<f00b4r0>
specifically, we want to get rid of lzma-loader on mikrotik devices
<f00b4r0>
i think we should take this one step at a time, otherwise the same cause (trying to satisfy everyone) will lead to the exact same technical results (lzma-loader)
<f00b4r0>
and by result I really mean failure ;P
<f00b4r0>
i have to bail, bbi ~2h. Also purely FYI I think lynxis is also working on this issue
<gch981213>
f00b4r0: when I posted my first comment I've mentioned that I hope the work done on zboot can be reused. my goal has become getting rid of lzma-loader for all devices with kernel-loader used.
<f00b4r0>
i understand. But maybe that's a bit ambitious in one go? :)
<f00b4r0>
anyway, really have to run. bbl
<gch981213>
f00b4r0: I've done the relocation part anyway.
<gch981213>
just copy some assembly from lzma-loader into zboot head.S
Borromini has joined #openwrt-devel
Nick_Lowe has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
Nick_Lowe has joined #openwrt-devel
brn has quit [Remote host closed the connection]
brn has joined #openwrt-devel
brn has quit [Ping timeout: 256 seconds]
am0rphis has joined #openwrt-devel
brn has joined #openwrt-devel
am0rphis has quit [Remote host closed the connection]
<eduardas>
hello, has anyone worked on a Linux-based Zigbee enabled embedded system? does mainline kernel have any kind of support for it?
f00b4r0 has joined #openwrt-devel
<stintel>
eduardas: I'm using a conbee usb zigbee dongle with deconz
<stintel>
how I understand it is that this is done entirely in userspace
dopje_ has quit [Read error: Connection reset by peer]
<stintel>
can't answer your kernel question
<eduardas>
stintel: well, that is still useful to know... thank you
<stintel>
welcome
<eduardas>
I still wonder whether some kind of kernel subsystem for Zigbee would make sense
<stintel>
I'm using this successfully for some time with a bunch of ikea lamps and remotes, with home assistant
<eduardas>
yeah, home assistant is pretty popular... haave not tired it myself, though
nitroshift has quit [Quit: Gone that way --->]
<eduardas>
"tried it"
gch9812130 has joined #openwrt-devel
gch981213 has quit [Ping timeout: 256 seconds]
gch9812130 is now known as gch981213
dopje has joined #openwrt-devel
<eduardas>
stintel: I've looked at what you're using. Is deconz FOSS?
<eduardas>
I am unsure
<eduardas>
at least I can not find the source code
feriman has joined #openwrt-devel
<rr123_>
" paulbarker> rr123_: openwrt has major bugs in their opkg fork still unfixed after I reported them in 2013" , anyone aware of this?
Borromini has joined #openwrt-devel
<karlp>
do they have anything actually actionable?
<damex>
i see that board have two SFP related eeprom (@50 and @51) at first two wire bus. uses at24 eeprom. on official firmware it is detected but on openwrt i get error and second one detected as 'dummy'. is there anything i could check to get it running?
<damex>
first one detected properly though
gch981213 has quit [Quit: Ping timeout (120 seconds)]
gch981213 has joined #openwrt-devel
jow has quit [Ping timeout: 256 seconds]
jow has joined #openwrt-devel
aszeszo has joined #openwrt-devel
eduardas has quit [Quit: Konversation terminated!]
someone32 has joined #openwrt-devel
someone32 has quit [Remote host closed the connection]
Borromini has quit [Ping timeout: 264 seconds]
Redfoxmoon has quit [Ping timeout: 272 seconds]
Borromini has joined #openwrt-devel
philipp64|work has quit [Ping timeout: 258 seconds]
philipp64|work has joined #openwrt-devel
feriman has quit [Ping timeout: 260 seconds]
muhaha has joined #openwrt-devel
valku has joined #openwrt-devel
muhaha has quit [Ping timeout: 256 seconds]
Nick_Lowe has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
Nick_Lowe has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<damex>
PaulFertser: is there anything beside kmod-ledtrig-gpio needs to be enabled? getting leds-gpio: probe of leds failed with error -16 and device tree enabled leds are not appear in /sys/class/leds but they're working as described in dts
muhaha has quit [Ping timeout: 272 seconds]
<PaulFertser>
damex: -16 means busy, probably you're loading kmod after exporting or something? you can check /sys/kernel/debug/gpio to see what can be holding it busy.
<damex>
i tried unloading leds_gpio and loading again - still -16
<damex>
something fishy
<Grommish>
Interesting.. PaulFertser, are you familar with the target system?
<PaulFertser>
Grommish: what target system?
<Grommish>
./target/xxx in the build root
brn has quit [Remote host closed the connection]
<Grommish>
I remained my config-5.4 kernel config to config-5.4-bak to try some new things.. and the system continued to use config-5.4-bak (or maybe config-5.4*)? I had to remove it completely and replace it with a stock config-5.4
<Grommish>
er renamed
brn has joined #openwrt-devel
<Grommish>
Was just curious if you knew if that was expected behavior or not
Nick_Lowe has joined #openwrt-devel
Nick_Lowe has quit [Client Quit]
<Grommish>
Somehow along the line I managed to completely remove my console and couldn't figure out why it wasn't resetting ehe
brn has quit [Ping timeout: 260 seconds]
Nick_Lowe has joined #openwrt-devel
Nick_Lowe has quit [Ping timeout: 246 seconds]
<damex>
PaulFertser: there is interrupts for phys on that gpio bus too, could be the issue here
<PaulFertser>
damex: it shouldn't be taking the whole bus
<damex>
PaulFertser: i checked how upstream deal with it - there is some octeons that use same bindings for gpio bus - turns out configuration for the bus is <the same> and they just point to it the same way and it is supposed to work
<damex>
is there a way to build dtb from dts with c-style includes for files and external kernel bindings?
<damex>
openwrt expects you to use c-style but dtc can't parse that
brn has joined #openwrt-devel
MichaelOF has quit [Quit: Konversation terminated!]
samantaz has joined #openwrt-devel
brn has quit [Ping timeout: 240 seconds]
danitool has joined #openwrt-devel
<philipp64|work>
I just installed a WLE600VX 7AA into my APU2, and rebooted… dmesg and lspci aren’t seeing the hardware. Help
<philipp64|work>
It’s in the middle slot (mPCIE 2)… does it need to be in the rightmost one?
kubrickdave_ has quit [Read error: Connection reset by peer]
kubrickdave has joined #openwrt-devel
danitool has quit [Quit: Cubum autem in duos cubos, aut quadratoquadratum in duos quadratoquadratos]
Darkmatter66_ has quit [Quit: ZNC 1.7.5 - https://znc.in]
danitool has joined #openwrt-devel
Darkmatter66 has joined #openwrt-devel
zx2c4 has quit [Ping timeout: 272 seconds]
zx2c4 has joined #openwrt-devel
Redfoxmoon has quit [Read error: Connection reset by peer]
Redfoxmoon has joined #openwrt-devel
Redfoxmoon has quit [Changing host]
Redfoxmoon has joined #openwrt-devel
aszeszo has quit [Quit: aszeszo]
fonix232 has quit [Ping timeout: 256 seconds]
fonix232 has joined #openwrt-devel
dansan has quit [Quit: The C preprocessor is a pathway to many abilities some consider to be unnatural.]
dansan has joined #openwrt-devel
Grommish has quit [Ping timeout: 240 seconds]
<mirko>
mangix: do you have this info from anywhere else other than the openwrt makefile? because i didn't find anything except the headers in its source files, and nothing states ISC