01:56 <Namidairo> tarring up /etc/config and mtd writing it every boot seems like a very bad idea

01:58 <Namidairo> unless of course your objective was for nand to die within <=100k boots

10:47 <neggles> do we have any documentation on what the various image build makefile options are/do other than the usual "look at other devices' configurations/makefiles" ?

10:49 <neggles> trying to work out how to make build system give me a ubi image with the kernel+dtb blob as a file inside a volume

10:50 <neggles> so i can make u-boot do a ubifsload

10:52 <neggles> at least I worked out why u-boot seems to be incapable of writing to this NAND and having it read back out successfully - these samsung chips don't support subpage writes >:(

11:17 <PaulFertser> neggles: basically, they're all in include/image-commands.mk , and looking for dtb you can see there's a ready made way "append-dtb-elf" which adds dtb in a dedicated elf section of the image or "install-dtb" which copies the binary to BIN_DIR

11:19 <PaulFertser> And there's KERNEL_IN_UBI option.

11:21 <neggles> PaulFertser: I did find those options, still trying to work out the exact combo I need - `KERNEL_INITRAMFS := kernel-bin | append-dtb-elf` works fine for the kernel+initramfs blob

11:21 <neggles> but when i turn on generation of the ubifs image, whether it's got KERNEL_IN_UBI on or not, I'm currently getting "Error: min. I/O unit was not specified (use -h for help)" from mkfs.ubifs

11:22 <neggles> I have PAGESIZE / SUBPAGESIZE / BLOCKSIZE set

11:36 <neggles> oh i think I just found the info I needed in an ath79 target, neat

11:39 <hauke> stintel: brcmfmac still has problems when I create a wifi AP. DId you look into this already?

12:10 <neggles> yes! found a combo that works

12:39 <stintel> hauke: I have not tried, I only have raspberry pis with brcmfmac, they're pretty bad at being AP

13:49 <userx> Hello, I'm trying to build package for ramips with using SDK and got error: "strip: Unable to recognise the format of the input file". Where should I look for the problem?

13:49 <PaulFertser> userx: looks like it's trying to strip a non-executable. Use some pastebin to show the full log.

13:58 <userx> PaulFertser: Thank you for the reply! https://paste.debian.net/hidden/2aaff9e8/

14:00 <PaulFertser> userx: apparently 3proxy makefile is using host strip instead of mipsel-openwrt-linux-musl-strip . Why are you running the install stage at all there?

14:02 <userx> PaulFertser: yes, it is. Well, I probably need to learn how to do this correctly.

14:03 <PaulFertser> userx: probably whatever you're trying to do with 3proxy can be done other way, or someone would have packaged it for OpenWrt already.

14:05 <userx> PaulFertser: And this person also uses the install command, https://github.com/zCookie/openwrt-3proxy/blob/master/openwrt/Makefile#L42

14:06 <PaulFertser> userx: I do not think so

14:06 <PaulFertser> It's a custom install sequence ignoring what's in the makefile.

14:11 <userx> PaulFertser: I did not fully understand your thought. I created Makefile by "Creating packages" guide, https://openwrt.org/docs/guide-developer/packages

14:11 <userx> PaulFertser: So I don't sure why I cannot use INSTALL_BIN command and why build process use host strip instead of strip from staging.

14:12 <userx> PaulFertser: Anyway, I will not waste your time, Thanks for the help!

14:13 <PaulFertser> userx: I'm not using SDK usually, I use full build system.

14:16 <userx> PaulFertser: Thanks again for your time and help! Goodbye.

17:34 <jow> PaulFertser: the full build system would exhibit the same error

17:34 <jow> PaulFertser: the root cause is the upstream build system (3proxy's) invokes install -s

17:34 <jow> which is likely caused by using PKG_INSTALL:=1 in the OpenWrt Makefile

18:39 <Lynx-> Can anyone suggest a reason why with mt76 updates mesh is broken in the sense that node shows up as still connected on other two nodes, but node becomes inaccessible?

18:51 <Lynx-> what dictates which mesh in mesh of 3x nodes is the 'master' mesh to which other two connects?

18:51 <owrt-snap-builds> Build [#412](https://buildbot.openwrt.org/master/images/#builders/2/builds/412) of `layerscape/armv7` failed.

19:10 <PaulFertser> jow: thank you, will pay more attention to that variable in the future.

19:13 <Slimey> heh doing the hotfixes update on a cisco fmc-2500 is about 20 minutes of shear terror watching the KVM session while it updates firmware wondering if its ever going to act normal and come back up again

22:57 <nick[m]1234> dangole: can you merge the lhg 60 with my ethernet interface fix? https://github.com/openwrt/openwrt/pull/2417#issuecomment-974723045

22:58 <nick[m]1234> than I would go on and also add DSA support for this device

23:02 <dangole> nick[m]1234: we can do that or you finish converting it to DSA (only a single port, right?), give it some more testing (incl. sysupgrade) and we merge it in a couple of days.

23:07 <nick[m]1234> dangole: yep, single port device. okay, I will go on and add this to DSA. hopefully dsa is soon merged. :)

23:09 <nick[m]1234> dangole: whups. just saw that I did not commited my changes to fix ethernet interface

23:10 <nick[m]1234> dangole: here is the correct device tree https://github.com/PolynomialDivision/openwrt/commit/14cabc372020056183288598217c8565599a4b3c

23:17 <dangole> nick[m]1234: picked that up into my tree on github. i also wonder if wil6210 is just working now, as it claims to be "Sparrow B0, flash exist". on the other hand it also claims to load a board file and that is supposedly just a linux-firmware default and we should extract whatever MikroTik ships in their firmware...

23:23 <nick[m]1234> dangole: I remember that strange discussion about board files that they are somehow "encrypted" with some seed

23:23 <nick[m]1234> dangole: maybe I can fetch me a second device

23:24 <nick[m]1234> and test if wifi is working

23:35 <hauke> dangole: are you taking care of DSA on ipq40xx?

23:36 <hauke> I didn't follow the github thread

23:37 <nick[m]1234> hauke: Robert Marko is doing that

23:37 <dangole> hauke: not actively ;) i'm reading the thread and the whole thing being quite a mess (forward-port of ancient fork of qca8k driver...), i prefer to stay out if it...

23:38 <hauke> ok

23:45 <nick[m]1234> I hope we can find the cause of the freezes that at least one other users (not only me) reported. :/