schwicht has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<kabel>
are there some rpi clones with 2.5g / 5g ethernet?
<stintel>
NanoPi R5S
danitool has quit [Quit: Cubum autem in duos cubos, aut quadratoquadratum in duos quadratoquadratos]
Danct12 has quit [Ping timeout: 480 seconds]
minimal has quit [Quit: Leaving]
Danct12 has joined #openwrt-devel
<stintel>
neggles: was it you who mentioned the xirrus xd something in here in the beginning of the year?
schwicht has joined #openwrt-devel
schwicht has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
goliath has quit [Quit: SIGSEGV]
goliath has joined #openwrt-devel
goliath has quit [Quit: SIGSEGV]
bluew has quit [Remote host closed the connection]
minimal has joined #openwrt-devel
bluew has joined #openwrt-devel
<robimarko>
Ansuel: Do you have PHY LED examples?
<robimarko>
Is Marvell driver a good one?
<f00b4r0>
so firewall4 doesn't allow inverted match on set elements (i.e. match when NOT in set)?
<f00b4r0>
or am i missing something?
<f00b4r0>
oh, exclamation mark before set name
bluew has quit [Read error: Connection reset by peer]
philipp64 has quit [Quit: philipp64]
<tmn505>
robimarko: tested the pakedge device with SPI-NOR and U-Boot bootloops when I've writen image created with FitImage recipe. After altering bootcmd variable to 'sf probe; sf read 0x84000000 0x180000 0x1e80000; bootm 0x84000000' it booted without issues. Reading almost whole flash is a bit overkill and takes some time, but I wanted to test if it overwrites some crucial memory region.
<tmn505>
btw the meraki devices mentioned on GH have NAND flash but seem to be affected, I guess some of them also read a fixed size kernel image
<robimarko>
tmn505: There is no limit with U-boot itself
<robimarko>
But rather the kernel partitions that were set by the vendor in the fake SMEM config
<robimarko>
So when bootipq is ran it will try to load only that size
<tmn505>
ok that clears things, so changing bootcmd is the easiest fix, unless someone writes LZMA loader
<robimarko>
Yes, as unfortunatelly most of the vendors did not enable LZMA support
<robimarko>
As QCA did not enable it in defconfig, which is sad as it works just fine but saves a lot of space for the kernel
<tmn505>
what about zImage? Was it usually enabled?
<robimarko>
Its also hit and miss
<tmn505>
so seems like Pakedge did decent job, as it supports all three methods
<robimarko>
Yes, that is the best scenario
<robimarko>
Sadly, most of them just used the defconfig and shipped it
<SlimeyX>
testing bsap-192x build..
<tmn505>
robimarko: anyway I'll make PR to alter environment on sysupgrade for my devices, after I'm back from holidays, thanks for clarification.
bluecmd[m] has joined #openwrt-devel
philipp64 has joined #openwrt-devel
<bluecmd[m]>
Hello, just popping in to say hi. I'm working on porting OpenWRT to the Cisco/Viptela vEdge 1000 platform. I have it working with OpenWRT so hopefully you'll see some patches from me and my friends in the not too distant future
<PaulFertser>
Awesome :)
<PaulFertser>
BTW, it's OpenWrt, not WRT.
<PaulFertser>
bluecmd[m]: please see PM
<bluecmd[m]>
Thanks! My bad on the spelling :)
<bluecmd[m]>
In terms of contributing. This platform has a few drivers that are platform specific, like CPLD interrupt controller, GPIO controller, I2C and so on. In an ideal world these will be upstreamed to mainline kernel, but that might take a few review cycles I assume. Are you open to carrying "experimental" patches for platforms before they get merged upstream? Basically, I'm trying to figure out if we should get to a v1.0 state on the
<bluecmd[m]>
OpenWR..^W OpenWrt port first and upstream it to OpenWrt, or if you strongly prefer not to carry driver patches
<PaulFertser>
bluecmd[m]: there's a wiki page that describes policy on the kernel patches. Basically, it's OK to add them to OpenWrt if you're also reasonably trying to upstream them, and the guide explains the details.
<bluecmd[m]>
Great, I will have a look and see if I can find it
<PaulFertser>
Sometimes apparently it's ok to even not try to upstream them...
<robimarko>
I am big opponent of carrying downstream patches
<robimarko>
Its fine in cases where its actively being worked on upstream, but lot of time OpenWrt just ends up being a downstream code dump
<robimarko>
That becomes a pain every kernel bump
<bluecmd[m]>
Yeah. I guess it's a different story if they have been merged in the very latest kernel and patches are just backports though
<bluecmd[m]>
That seems like it would be a no brainer
<f00b4r0>
jow: am I misreading this https://git.openwrt.org/?p=project/firewall4.git;a=blob;f=root/usr/share/ucode/fw4.uc;hb=23a434d0d15d61db61bb065c89f266a326c78a88#l3255 or is "counters" not actually implemented?
<robimarko>
bluecmd[m]: Its fine if you/somebody is actively working on upstreaming stuff as that takes time
<robimarko>
But a lot of times, patches are just added and newer even sent upstream
Borromini has joined #openwrt-devel
chder has quit [Read error: Connection reset by peer]
minimal has quit [Quit: Leaving]
danitool has joined #openwrt-devel
<Ansuel>
f00b4r0 myabe a typo ?
<Ansuel>
PaulFertser downstream patch are sometimes accepted if it's mandatory for the device and for generic if the benefits are much greater... but the official statement is that we don't like downstream patch or else people would complain
<Ansuel>
(example complain that OEM implement that in that specific way and that is the only way possible <--- 99% of the times this is wrong and just people are lazy and don't want to find better solution)
schwicht has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<jow>
f00b4r0: seems so, yes. probalby needs something along these lines: http://sprunge.us/nDxIT3
fakuivan has quit [Remote host closed the connection]
fakuivan has joined #openwrt-devel
<f00b4r0>
jow: thanks!
<SlimeyX>
hauke merged updates to PR
cmonroe has joined #openwrt-devel
fakuivan has quit [Ping timeout: 480 seconds]
<bluecmd[m]>
Scratch the hwdata question, we're figuring it out - but the SFP port field only goes to 4, our platform has 8 ports. Can we request somebody to update that?
<SlimeyX>
bluecmd[m] how did you accomplish that? was this before the cisco acquisition?
<bluecmd[m]>
accomplish what specifically? port openwrt to vedge 1000?
<SlimeyX>
ya
<SlimeyX>
i've only see it once with someone getting linux to boot on a cat 2950 lol
<bluecmd[m]>
buying them of ebay and going to town with reverse engineering tools and osciloscopes
<bluecmd[m]>
most stuff is supported by mainline kernel, but there are some octeon ethernet bitrot and the custom CPLD was a pain to figure out
<SlimeyX>
heh i have some palo alto pa200 boxes gathering dust
<Ansuel>
\x i love that card that is connected to 2 pcie
<dalurka>
Hi there! I've been adding some info about the vEdge 1000 together with bluecmd[m] and I'm wondering about what the inbox stuff is in the url?
<SlimeyX>
devices with Cascade (QCA9984) cards the ones with 50 bin files, how does one get it to work
<SlimeyX>
ie Netgear R7800
<Ansuel>
the 50 bin file are just the same bin file tweaked
<Ansuel>
for some secenario
<tmn505>
dalurka: bluecmd[m]: TBF I don't know exact process of advancement from inbox, just fill gradually all information at some point it gets moved. Try to ask same qestion in https://forum.openwrt.org/c/documentation and mention @tmomas he's the wiki admin.
<Ansuel>
(boosted power not so legal relaxed reg domains)
<Ansuel>
the original qcom driver have some logic to dynamically load them based on someuserspace scripts
hbug has joined #openwrt-devel
<SlimeyX>
yeah i've been trying to find this script on the bsap-3040 :P
<SlimeyX>
otherwise it boots fine
<Ansuel>
but ath10k doesn't work that way
<SlimeyX>
i have the oem source to look at
<Ansuel>
you can consider using the specific one
<Ansuel>
or just use the generic one
<Ansuel>
to use the specific one you have to package it and provide a calibration variant
<Ansuel>
to package you need to use the qca swissarmyknife tools
<SlimeyX>
got a link for how to on that
<Ansuel>
it's pretty easy the real hard thing is find the right bin out of the 50 thing