00:29 <russell--> can someone point me at where the '|' operator comes from in the various image makefiles? e.g. how to read KERNEL := kernel-bin | append-dtb | lzma | loader-kernel | uImage none | arcadyan-trx 0x746f435d | pad-to $$(KERNEL_SIZE) ?

01:00 <owrt-images-builds> Build [#66](https://buildbot.openwrt.org/images/#/builders/115/builds/66) of `master_x86/64` completed successfully.

02:01 <Mangix> interesting that irssi logs are easier to grep than quassel logs

02:48 <owrt-images-builds> Build [#70](https://buildbot.openwrt.org/images/#/builders/45/builds/70) of `master_sunxi/cortexa7` completed successfully.

03:38 <schmars[m]> russell-- pipe operator from shell. take the kernel-bin, then append the device tree binary to it, the lzma the result, etc.

03:39 <schmars[m]> ah. "where" it is in the codebase i don't know :-)

05:35 <ynezz> russell--: https://github.com/openwrt/openwrt/blob/main/include/image.mk#L113

06:34 <russell--> ynezz: thank you!

08:07 <jow> russell--: split_args in include/image.mk

09:22 <nbd> robimarko: ping

09:22 <robimarko> nbd: pong

09:22 <nbd> so i just noticed again that we still have the two ath10k build variants and https://github.com/openwrt/openwrt/pull/11584 was never finished

09:22 <nbd> i'd like to get this sorted out soon, since the build variants are annoying

09:23 <robimarko> I agree

09:23 <nbd> in my opinion, dynamically modifying modules.d files in preinit is a bit weird. my preference would be to move forward with autoselecting the mode in the driver based on available system RAM, as long as the module parameter is at 0 (default)

09:24 <nbd> that way the user can override it via modules.conf if needed

09:24 <nbd> what do you think?

09:25 <robimarko> I dont really have a hard opinion, basically whatever is the easiest

09:25 <robimarko> RAM size could be a good measure

09:25 <nbd> what is the current per-board selection of smallbuffers vs regular based on?

09:25 <nbd> is it just an ad-hoc case by case decision?

09:26 <robimarko> Its basically up to the developer adding the board

09:26 <nbd> ok

09:26 <robimarko> I think it was if RAM was less than 256MB then you want to use the smallbuffers

09:26 <nbd> makes sense

09:28 <nbd> should probably check for something like <230MB (to account for reserved memory)

09:29 <nbd> would you have some time to take care of this? i don't have any hw for testing available right now

09:29 <nbd> i can help reviewing it

09:30 <nbd> i'll take care of merging the mac80211 update soon

09:30 <robimarko> Maybe over the weekend, I retired all of my ath10k gear

09:30 <nbd> ok, thx

09:30 <robimarko> I will see if the original author wants to respin it

09:31 <nbd> thx

09:32 <robimarko> Thanks

09:33 <slh> e.g. the (ipq807x) xiaomi ax3600 uses kmod-ath10k-ct-smallbuffers for its qca9888 AIoT radio

09:33 <slh> (not really a very useful radio, but it's ath10k)

09:34 <robimarko> Yeah, it has only 512MB of RAM so that is why smallbuffers for the ath10k one

09:34 <robimarko> This kind of nukes the RAM size only idea

10:01 <nbd> do a mix of ram-size default + ship a default modules.conf in base-files on ipq807x

10:44 <f00b4r0> why not check on <=128M? Anything >128M is going to be 256 or more, no? This avoids the guesstimate threshold

10:47 <robimarko> Because of cases like AX3600 which has 512M of RAM

10:47 <robimarko> But needs the smallbuffers version

10:48 <f00b4r0> well check for <230 would still not work there?

10:48 <robimarko> No, because it would have more RAM but needs the smallbuffers version

10:49 <f00b4r0> ok my argument was only about not using a guesstimate like 230. Not about combining with other checks :)

10:49 <f00b4r0> i.e. if you want to check for "256 or more", use "!<=128" instead of "!<230"

10:50 <robimarko> I get what you want to say, that is fine

10:50 <robimarko> We will just need to override those checks for special cases like this

11:06 <slh> f00b4r0: the 'problem' with the ax3600 is not the ath10k radio, but with 512 MB being already rather tight for its two main ath11k radios (ath11k really eats RAM for breakfast), so anything that conserves RAM -such as ath10k-ct-smallbuffers for the not useless, but of little use AIoT radio- is needed

11:30 <Piraty> ` make -j16 target/linux/compile package/kernel/linux/compile ` results in some module packages (not empty) but kernel package is empty. which target is required?

11:42 <robimarko> There isnt a real kernel package AFAIK

11:42 <Piraty> oh

11:43 <robimarko> make target/linux/compile

11:43 <robimarko> Will build the kernel and any kmod

11:54 <jow> maybe the formula should be simply: if ((amount of total ram / number of phys) <= 256) thne use smallbuffers

12:15 <Borromini> robimarko: congrats on joining the team :)

12:15 <robimarko> Borromini: Thanks

12:17 <Habbie> robimarko, congrats!

12:58 <castiel652> robimarko, congrats!

13:18 <robimarko> Thanks everybody

14:55 <rmilecki> can I encourage some ppl here to look at

14:55 <rmilecki> [PATCH] base-files: sysupgrade: include uci-defaults script disabling services

14:56 <rmilecki> it's a quesion whether we want to have "enabled" (or "disabled") UCI option for every configurable service?

14:56 <rmilecki> right now some services can be disabled only using /etc/init.d/foo disable

15:32 <f00b4r0> nbd: unfortunately we've got a crash. This time the backtrace is available, see end of http://sprunge.us/Cicovy

15:35 <sa7mfo> could someone please have a look and help me figure out why these test builds fails? I'm not sure if it is related to my change at all..

15:35 <sa7mfo> https://github.com/openwrt/packages/pull/23390

15:35 <f00b4r0> nbd: device is still up in case more forensics are needed

18:59 <mrkiko> svanheule: hi! I am back :)

19:01 <mrkiko> svanheule: the point was upstream wanted the limit be customizable in general, since the quality of manifacturing and other aspects may change what temperatures the chip might support. And that's why they suggested to implement reading the limits from the DTS.

19:04 <mrkiko> svanheule: this was the ideaI got from it, but maybe I am wrong and at the moment I don't have the link of the thread here. But I will check

19:17 <mrkiko> svanheule: ok, now I remembe rhings better. Yes, the only way might be to look at who the author is and ask them to try

19:20 <rmilecki> jow: i'm not much familiar with LuCI

19:20 <rmilecki> jow: do we have some generic UI module for displaying & managing service? using /etc/init.d/<service>

19:24 <rmilecki> i can't find anythig like that

19:25 <rmilecki> jow: could I add CBIService to form.js to manage /etc/init.d/<service> ?

19:36 <sandberm> Hello. A PR for adding a mt7621 based device would require attention from reviewers. Also, if you can think of a neat alternative way for fetching ethaddr from u-boot env on ubi I am interested. https://github.com/openwrt/openwrt/pull/13798

19:44 <svanheule> mrkiko: makes sense to have DT-specified limits, I guess. Thermal settings are pretty device specific

19:44 <robimarko> mrkiko, svanheule: What device are you guys talking about?

19:45 <svanheule> robimarko: realtek switch (Zyxel XGS1250-12)

19:45 <robimarko> Oh the fan trips

19:46 <svanheule> I think I saw someone speak about "when these phys are eventually used on big endian devices". Been doing that for a while already on our (underpowered) BE MIPS devices B-)

19:48 <robimarko> Oh you hit the stupid AQR driver not clamping the temperature range

19:48 <svanheule> robimarko: yup. And apparently upstream not liking the suggestion of clamping like all other hwmon devices :-/

19:49 <Borromini> svanheule: o/

19:49 <svanheule> Borromini: \o

19:50 <svanheule> robimarko: congrats on making it on the team btw :)

19:50 <robimarko> Thanks

20:47 <rmilecki> sandberm: u-boot env for MAC is still in plans

20:47 <rmilecki> sandberm: and it slowed down since Rob decided he doesn't like where we got with NVMEM layous

20:48 <rmilecki> ppl need some time to rest from it i'm afraid

20:56 <sandberm> rmilecki: okies, that's unfortunate but we'll just have to wait it out then. In the meantime, I guess ppl are not too keen on adding a new method to base-files/files/lib/functions/system.sh

21:00 <sandberm> rmilecki: one option is to hard code u-bootenv.conf in 02_network and use fw_getenv, but it's a bit clumsy.

21:03 <Bayruth> Hi! I have some trouble understanding how DTBs are handled in OpenWrt. I'd like to add support for SP7021 (Banana Pi BPI-F2S). They have a custom U-Boot repository. Thus I've created a uboot-sunplus package for generating the U-Boot. https://github.com/tibbotech/plus1_uboot Only problem is that it expects me to define a DTB file.

21:04 <Bayruth> Other targets in OpenWrt do not append the DTB to the U-Boot, they append it somehow to the kernel image, correct?

21:04 <KanjiMonster> Bayruth: DTB files are usually included in the fitImage along the kernel

21:05 <Bayruth> Thanks! So there must be some option in U-Boot I need to disable so that it does not expect a DTB?

21:13 <Bayruth> It seems they have some custom layout for their U-Boot due to some custom signature verification... Thus I think the easiest way would be to just pass the DTB file to the U-Boot build process.

21:17 <Bayruth> Unfortunately I can't get the generation of the DTB to work... I've added the DTS file in target/linux/sunplus/files/arch/arm/boot/dts and it gets copied correctly to the kernel build directory. The kernel builds successfully, but only for the upstreamed sunplus-sp7021-demo-v3.dts board I get a dtb file...

21:18 <PaulFertser> Bayruth: U-Boot needs DTB to work on a board

21:18 <PaulFertser> DTB describes hardware, so U-Boot needs to know what's connected where, so it needs that information, as Linux does.

21:19 <Bayruth> Okay... So do I need to add the DTS file in arm/boot/dts/Makefile to generate a DTB? For other targets like ipq4xx I don't see any magic there.

21:19 <PaulFertser> You mean for U-Boot itself?

21:20 <PaulFertser> Its build system should be producing a binary from source on its own.

21:22 <Bayruth> I've assumed I need to build the kernel first to get the DTB... Unfortunately it doesn't. They (Sunplus) take the DTB from the kernel build process and pass it to the U-Boot make with EXT_DTB parameter

21:25 <PaulFertser> Now that explains why it's confusing.

21:45 <Bayruth> Thank you for the help so far. So I want to create the DTB file in U-Boot now... The problem is that these DTS files have includes which DTC can not resolve. So I need a combined DTS file first if I understand correctly. How do you do this in OpenWrt ordinarily? This combined DTS file needs to be added to U-Boot then, correct? This sounds like redundancy which I would not expect from a Linux project. Thus I assume I'm still misunderstanding it.

21:47 <KanjiMonster> Bayruth: dtc supports search paths for includes, you need to pass in-kernel dtc directories to it (assuming this is where they reside)

22:01 <Bayruth> Thanks for the hint... It seems fdt_util.py does that stuff ordinarily...

23:55 <owrt-images-builds> Build [#71](https://buildbot.openwrt.org/images/#/builders/52/builds/71) of `master_ramips/mt76x8` failed.