03:47 <philipp64> rmilecki: yes and no. hope it was a good holiday. the issue is that preinit tries to remap interfaces once with the "required for boot" drivers, but no one does it a second time for the NOT "required for boot" drivers after kmodloader runs in /etc/init.d/boot ...

03:48 <philipp64> filed a bug on it. https://github.com/openwrt/openwrt/issues/13329

09:18 <linusw> rmilecki: built the trunk image for DIR-890L with LuCI and ksmbd and tested, it works like a charm. Thanks!

10:29 <hadis_> Is the only way to repartition an mtd device to edit the device tree?

10:29 <dwfreed> yes, because mtd devices don't actually have partitions

10:30 <hadis_> I was under the impression that u-boot is aware of the partition layout

10:32 <dwfreed> uboot just sees one giant flash; the uboot env usually contains the partition information

10:32 <dwfreed> and uboot is built with the location of the env in the flash hardcoded, so don't try to move that

10:33 <dwfreed> (unless you can rebuild uboot for your device)

10:35 <hadis_> so could I have u-boot read data that goes over partition boundaries?

10:36 <dwfreed> yes, because partition boundaries aren't real like a true partition table

10:36 <hadis_> cool, thanks for your insight

12:24 <linusw> hadis_: well rmilecki is working on this cool thing: https://lore.kernel.org/linux-mtd/20211230090449.11808-2-zajec5@gmail.com/

12:33 <KanjiMonster> linusw: "Date: Thu, 30 Dec 2021" - not sure if "is" is the right tense here ;p

12:36 <linusw> KanjiMonster: actually, it is merged https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/mtd/partitions/u-boot.yaml

12:38 <linusw> there is the driver https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/mtd/parsers/brcm_u-boot.c

12:38 <linusw> But it has a "brcm," prefix so I guess it currently only is tested on the Broadcom version of U-Boot.

12:38 <linusw> However the idea should extend to other vendors I think?

12:42 <robimarko> That was shot down, look at the commit for the bindings

12:42 <robimarko> It states that there is no reason to specially handle regular u-boot env partitions

12:42 <robimarko> Except for on Broadcom

13:03 <rmilecki> KanjiMonster: hauke: in openwrt-23.05 branch we already have https://github.com/openwrt/openwrt/commit/57a8ea6d749e5fe0e00673cc77b5f2c17b792650 ("uboot-bcm4908: update to the latest generic")

13:03 <rmilecki> but it clearly looks related

13:03 <rmilecki> i'll have to debug that

13:04 <rmilecki> it also seems it's sth new

13:04 <rmilecki> has something big in toolchain change since the last rc/

13:04 <rmilecki> ?

13:08 <KanjiMonster> rmilecki: 22.03, not 23.05

13:08 <rmilecki> KanjiMonster: oh, thank you

13:08 <rmilecki> i'll backport it today

13:09 <KanjiMonster> I did the same mistake at first as well

16:18 <rmilecki> hauke: fix pushed to the openwrt-22.03 thaks for pinging me

16:23 <rmilecki> linusw: i don't think my U-Boot partition binding would help with partitioning flash device

16:23 <rmilecki> hadis_: i'm not sure what you want to achieve

16:23 <rmilecki> hadis_: U-Boot has access to flash device so it can read any of its content

16:24 <rmilecki> linusw: thanks for testing DIR-890L and I'm sorry it took so much time

16:24 <rmilecki> linusw: would you be interested in getting writing access to OpenWrt repo?

16:24 <rmilecki> philipp64: i've verified that logging doesn't work from preinit scripts, it's probably before logd runs

16:25 <rmilecki> philipp64: i use echo "foo" > /dev/kmsg whenever I need to debug sth

16:58 <philipp64> rmilecki: that's what I ended up doing. any ideas about the boot/kmodloader bug?

16:59 <rmilecki> philipp64: i took a look at your report but i'm clueless

16:59 <rmilecki> i'm not familiar with that stuff at all

18:35 <KanjiMonster> philipp64: I guess one solution could be to handle this via a hotplug handler or so and rename them as they appear; then it shouldn't matter when modules are loaded

20:13 <linusw> rmilecki: yeah I could use the access I think, but don't know the process. It'd be nice with technical access and no involvement in administration... heh.

20:13 <linusw> I don't know who could commit the ixp4xx port otherwise.

23:34 <philipp64> KanjiMonster: we should be able to synthesize rules from the `ucidef_set_network_path` arguments.