silver has quit [Quit: One for all, all for One (2 Corinthians 5)]
silver has joined #openwrt-devel
Rentong has joined #openwrt-devel
Rentong has quit [Ping timeout: 480 seconds]
dorf has quit [Remote host closed the connection]
dorf has joined #openwrt-devel
Rentong has joined #openwrt-devel
<Tusker>
heya guys, is it possible to build a kernel module inside another package? or do I need to set up a depends on the new kernel package ?
<slh>
ath10k-ct, mwlwifi and mt76 are built out of tree, but if you can, avoid the extra pain
Pepes has quit [Read error: Connection reset by peer]
Pepes has joined #openwrt-devel
<Tusker>
slh: OK, will play around with it
shibboleth has quit [Quit: shibboleth]
goliath has quit [Quit: SIGSEGV]
Rentong has quit [Ping timeout: 480 seconds]
danitool has quit [Ping timeout: 480 seconds]
rmilecki has joined #openwrt-devel
dorf has quit [Remote host closed the connection]
dorf has joined #openwrt-devel
lmore377_ has quit [Quit: No Ping reply in 180 seconds.]
lmore377 has joined #openwrt-devel
nitroshift has joined #openwrt-devel
dorf has quit [Remote host closed the connection]
dorf has joined #openwrt-devel
goliath has joined #openwrt-devel
decke has joined #openwrt-devel
Rentong has joined #openwrt-devel
<Tusker>
I am trying to build a kernel module package (one I am writing), which depends on another kernel option being selected to build, but KCONFIG:=CONFIG_PHYLIB CONFIG_MDIO_BUS doesn't seem to actually set those parameters, what I am doing wrong ?
Rentong has quit [Ping timeout: 480 seconds]
<russell-->
Tusker: i'm going to hazard a guess that you are not looking hard enough for examples
<Tusker>
russell--: that is probably true... I've changed it to KCONFIG:=CONFIG_PHYLIB=y CONFIG_MDIO_BUS=y, with the same impact
<Tusker>
OK, so, .config contains the expected CONFIG_MDIO_BUS=y now, but I am still getting a compile error :( digging some more...
<Tusker>
OK, figured it out - the function isn't present anymore in 5.4.128 :|
<Tusker>
sorry for the noise
<Tusker>
OK, so, if I need a patch for the kernel, because of a package I am putting together, should the PR include both the package as well as the kernel patch ? Or get the kernel patch included first, and then do the package ?
<Tusker>
(works really nicely, diagnosed my gmac issues with my dts and now both eth0 and eth1 are working)
<rmilecki>
Tusker: probably not a big difference, I suppose that patch can be takes on its own too
<rmilecki>
*taken
<Tusker>
OK, thanks, I'll do a PR for it when I get some time :)
<skyper>
the openwrt-20 release no longer has AR71xxx as a target system. Which target do i have to select if I like to compile for AR71xxx?
<skyper>
ATH79 i guess...unless the ATH79 breaks backward compatibility..hmm.
aleasto has joined #openwrt-devel
<PaulFertser>
skyper: ath79 is a new target for the same old hardware
rsalvaterra_ has quit []
<PaulFertser>
skyper: not sure what kind of compatibility you have in mind
rsalvaterra has joined #openwrt-devel
<skyper>
interestingly it's allowed to leave PKG_MAINTAINER empty but if not left entry than it must be a real name.
<Pepes>
For new packages, I'd say that we don't let anyone to leave PKG_MAINTAINER empty. ;-)
<Pepes>
It can be empty in such case when maintainer is no longer interested in it
<PaulFertser>
But why can't a feeds packages maintainer be pseudonymous?
<skyper>
PaulFertser: I'm wondering myself. With realname being mandatory there is no hope that 'Madonna' will ever create a package (also some people are not allowed to use their real name [corporate policy] or prefer to keep it private).
<Pepes>
PaulFertser: For the same reason, why you can not contribute to OpenWrt. That's why there is required real name. Same for the kernel. More details: https://openwrt.org/submitting-patches
<PaulFertser>
Pepes: I think unless someone doesn't explicitly say that the name is not real it's meaningful to use anything that looks like one, just doing it consistently.
<PaulFertser>
Also, what makes one's name real? E.g. my international ID has "Pavel", does it mean I can't contribute as Paul? Or can you consider both names real, just with different spelling?
<skyper>
Pepes: thanks for the link. It refers to the linux kernel patching guide. That guide does not give a reasoning behind the real-name thing (just that it needs to be real name but without a logical explanation of 'why'?)
<PaulFertser>
skyper: the real name thing is explained on the DCO website
<karlp>
"explained"
<skyper>
I like to make some changes to the wiki (https://openwrt.org/docs/guide-developer/feeds) as yesterday I pointed out a mistake and was told 'go fix it yourself' - but it says i need to ask here for access. Please?
<PaulFertser>
skyper: send me your desired wiki nick and e-mail, I'll manually add an account.
<PaulFertser>
karlp: I agree, I was wrong, it's just the text itself but you do not get the rationale there. The idea is to reliably (as in accepted by courts) shift the liability from maintainers (and the project as a whole) to the individual contributors. It seems to be working nicely, and not really limiting.
<skyper>
PaulFertser: as d1z noted, the current rule seems to prevent developers to assume maintainer role. The rule is limiting and that it 'shifts liability' has never been tested in court = and i doubt that aliases would make it worse or better (now that even in court aliases are allowed...or on commercial contracts).
<PaulFertser>
skyper: so why not use an alias without mentioning it?
<skyper>
PaulFertser: because that would not be honest (and perhaps "Madonna" gets away with it but "d1zFoo666" is more obviously an alias than Madonna).
<PaulFertser>
skyper: yes, but why not use a reasonably sounding alias to provide maintainers with a plausible argument?
<skyper>
PaulFertser: because it would not be honest if the rule is to use real names and then to create a 'fake' name that looks like a real name.
<PaulFertser>
skyper: I think it's honest enough for the purposes this rule exists.
<skyper>
PaulFertser: i think the reason that this needs discussion is reason enough that the rule is not clear and needs updating to the modern way of how society runs now,.
<karlp>
still, wiki accounts have no real name requirement to the best of my understanding, so you can still get that and can go and fix what you wanted to fix...
<PaulFertser>
skyper: have you followed the SCO case?
danitool has joined #openwrt-devel
Rentong has joined #openwrt-devel
rejoicetreat has joined #openwrt-devel
Rentong has quit [Ping timeout: 480 seconds]
rejoicetreat has quit [Ping timeout: 480 seconds]
<Tusker>
for ath eeprom data, looking at the factory logs, it is pulling from the same location for both atk10k cards, but there are two bmi. one card seems to work fine with the package supplied firmware, but the other one fails (so probably needs to use the one from art). what is the magic number I need to look for the the ath10k eeprom ?
<Tusker>
jschwart: except the workaround causes both wlan0 and wlan1 to be 5ghz
<Tusker>
loeading boardData_AR900B_CUS240_2GMipiHigh_v2_006.bin instead of board.bin shows up as 2.4ghz as expected
Acinonyx_ has joined #openwrt-devel
Acinonyx has quit [Ping timeout: 480 seconds]
<jschwart>
Tusker: in case of that fritzbox, it's not supposed to support 2.4 GHz at all (there's a ath9k for that)
<Tusker>
jschwart: sure, but it's interesting that the supposed precal data in 0x1000 is invalid for 2G...
<Tusker>
jschwart: if the ath10k loads fine with the uploaded board data... where would the factory firmware be getting the precal data from? somewhere else other than art ?
<jschwart>
I could also boot up my device and copy the versions I have here if really needed, I don't know if they are identical
dorf has quit [Remote host closed the connection]
dorf has joined #openwrt-devel
Rentong has joined #openwrt-devel
<Tusker>
jschwart: I am looking at the commits for Fritzbox, and I wonder where the 11-ath10k-caldata script updates are coming from ? what does hexdump -n 100 -C -s 0x5000 /dev/<whatever your caldata or art partition> show ?
<jschwart>
Tusker: let me turn on the device and get you that info
<Tusker>
looks like the upload-wasp.sh is taking care of the cal-pci board data, and it is grabbing it from 0x199F or 0x198A
SamantazFox has quit [Ping timeout: 480 seconds]
<jschwart>
yeah I have a 5490 here
Rentong has quit [Remote host closed the connection]
Rentong has joined #openwrt-devel
<Tusker>
be interesting to compare 0x199F with 0x5000 on that mtd partition
Rentong has quit [Remote host closed the connection]
<jschwart>
it's /dev/mtdblock3
<jschwart>
I should have a copy of that entire thing I think
Rentong has joined #openwrt-devel
<jschwart>
Tusker: can I mail you all this? mtdblock3 is 384kB (even less compressed)
Tapper has quit [Remote host closed the connection]
Tapper has joined #openwrt-devel
<Tusker>
sure, DCC send or email is fine tusker@tusker.org
Rentong has quit [Ping timeout: 480 seconds]
<jschwart>
Tusker: should be all in your mailbox!
<Tusker>
jschwart: yup, looking at it
Rentong has joined #openwrt-devel
<jschwart>
great!
<Tusker>
well, the data at 0x199F doesn't look like board.bin data to me
<jschwart>
yeah there's a mention of AVM7490_CAL2_V5 there
<jschwart>
but I suppose that's not supposed to be in the actual data :)
<Tusker>
yeah, probably not
Rentong has quit [Ping timeout: 480 seconds]
<Tusker>
you are missing 0x16 bytes from the start of that board data
<jschwart>
so that 0x199F value should be lowered with 0x16?
<Tusker>
well, I don't think mtdblock3 relates to ${mtd} in that wasp uploader
<jschwart>
yeah I was just reading it seems to have the mac addresses & wifi keys only
<jschwart>
/dev/mtd2 is needed
<jschwart>
let me mail that
<Tusker>
and it looks like the fritz3490 uses offset 0x198A which could be the correct location, otherwise try 0x1989, whatever offset has 44 08
<Tusker>
yup - 0x198A starts with 44 08 board data
Rentong has joined #openwrt-devel
<jschwart>
odd, I had tried that value too I think, but that didn't work out
<jschwart>
let me check it now
<Tusker>
definitely 0x198A based on your provided mtd2
<Tusker>
i need to sleep, you OK to play around a bit more ? :)
<jschwart>
sure, I'll look a bit further, thanks a lot for the info!!
<jschwart>
good night!
<Tusker>
no worries, quite similar problem to mine, so helps me think through my own one :)
<jschwart>
that's only great :)
<Tusker>
might have to do some hackery around providing files as a sideload... since I can't find my board.bin anywhere on the flash
silver has quit [Quit: One for all, all for One (2 Corinthians 5)]
<jschwart>
yeah I also have no idea how important it is that this matches up
<Tusker>
the proper board data will allow for "best" operation based on the vendor providing the hardware
<Tusker>
the generic one may work OK, but not necessarily as good or worse
<jschwart>
yeah that makes sense
<Tusker>
OK, time for rest, otherwise won't be able to function tomorrow :)
<Tusker>
good luck, and pop me an email if you make any progress, am interested
<Tusker>
ciao
Tusker has quit [Quit: Time wasted on IRC: 16 hours 14 minutes 12 seconds]
Rentong has quit [Ping timeout: 480 seconds]
<jschwart>
sure will do!
<jschwart>
yep, so that solved it!
<jschwart>
you should have mail from github on this :)
Rentong has joined #openwrt-devel
Rentong has quit [Ping timeout: 480 seconds]
<xback>
blogic_: hi
<xback>
Just got my hands on a dozen of different boards
<xback>
I already have 4 different hw versions :-o
SamantazFox has joined #openwrt-devel
Rentong has joined #openwrt-devel
Rentong has quit [Remote host closed the connection]
Rentong has joined #openwrt-devel
Rentong has quit [Remote host closed the connection]
Rentong has joined #openwrt-devel
Rentong has quit [Remote host closed the connection]
chder has joined #openwrt-devel
Rentong has joined #openwrt-devel
chder has quit [Quit: chder]
Rentong has quit [Ping timeout: 480 seconds]
chder has joined #openwrt-devel
Rentong has joined #openwrt-devel
Rentong has quit [Ping timeout: 480 seconds]
lynxis has quit [Remote host closed the connection]
lynxis has joined #openwrt-devel
<blogic_>
xback: sorry just logged in, I'll ship the board tomorrow or the day after
<blogic_>
I'll also test the gmii delay settings tomorrow. is there a way to tell the HW rev ?