03:49 <Percius> Hello. I am working to port OpenWRT to BPI-R3-Mini, using BPI-R3 and ImmortalWRT's Phy drivers as a starting point. -- Unfortunately I am not quite sure how the Uboot artifacts are generated. In particular this line ARTIFACT/snand-bl31-uboot.fip := mt7986-bl31-uboot bananapi_bpi-r3-snand from linux/mediatek/image/filogic.mk:.

03:50 <Percius> In adapting that line for the Mini, I get a compiler Error openwrt-mediatek-filogic-bananapi_bpi-r3-mini-emmc-bl31-uboot.fip] Error 1. (File not Found). In greping the target directory, I don't see how/were the uboot is actually built. Can someone teach me

05:18 <Percius> So if I take my same DTS file and run it as the bpi-r3 instead of bpi-r3-mini the source compiles fine (haven't tested running yet, doing so now).

08:39 <hadis> Is it somehow possible what is using a certain gpio pin? The pin I'm interested in is shows 'write error: Device or resource busy' when trying to export it. I would like to somehow make it available again and manipulate it myself.

08:52 <Piraty> when inspecting an ipk package file, can i obtain the openwrt-release branch it belongs to? it's not part of 'control' (and should not be really). i mean technically there could be clashes in VERSION/RELEASE tuples across branches

08:59 <slh> not really, the package itself doesn't know about it (only implicitly via package dependencies, but that's vague at best)

09:40 <rmilecki> robimarko: hey! I've some MediaTek board with 2 x Aquantia AQR113C

09:40 <rmilecki> my problem is:

09:41 <rmilecki> 1. I can't compile custom U-Boot

09:41 <rmilecki> 2. Existing U-Boot doesn't have aq_load_fw

09:41 <rmilecki> robimarko: i'll be trying aq-fw-download now

09:41 <rmilecki> i'm wondering: should ideally Linux's driver be able to upload firmware to that PHY?

09:47 <Ansuel> rmilecki mh? that is already possible we just added support for it

09:47 <Ansuel> (and backport to openwrt)

10:09 <rmilecki> Ansuel: oh, i missed sth then

10:09 <rmilecki> oh, nice!

10:09 <rmilecki> 6f5c301eab71 ("generic: 6.1: backport upstream Aquantia PHY firmware loader patches")

10:11 <rmilecki> so it seems I just need to add "firmware-name"

10:11 <rmilecki> to DT

10:13 <Ansuel> yep

10:34 <robimarko> rmilecki: Yeah, driver can do it now

10:37 <gch981213> hadis: cat /sys/kernel/debug/gpio

11:02 <rmilecki> ah, there's a problem with CONFIG_AQUANTIA_PHY=y

11:02 <rmilecki> [ 1.588068] Aquantia AQR113C mdio-bus:00: Falling back to sysfs fallback for: Rhe-05.06-Candidate9-AQR_Mediatek_23B_P5_ID45824_LCLVER1.cld

11:02 <rmilecki> [ 64.526387] Aquantia AQR113C mdio-bus:00: failed to find FW file Rhe-05.06-Candidate9-AQR_Mediatek_23B_P5_ID45824_LCLVER1.cld (-110)

11:02 <rmilecki> firmware in on rootfs and can't be accessed that earlu

11:03 <rmilecki> should we allow packaging that PHY driver as module?

11:03 <robimarko> We alredy do it

11:03 <robimarko> AQR driver is packaged as module

11:03 <robimarko> That is what we use on qualcommax

11:03 <rmilecki> ah, great

11:03 <rmilecki> let me try that

11:26 <rmilecki> Ansuel: thank you for your work on upstream firmware loading for that PHY

11:26 <rmilecki> [ 6.276329] Aquantia AQR113C mdio-bus:00: loading firmware version 'v5.6.9 Mediatek Mediatek 23B 100522 05:37:14' from 'FS'

11:27 <Ansuel> happy it does work right away!

13:55 <Piraty> there is quite some pkg/ver/rel duplication across the branches, some of them are the same, most are not .

13:56 <Piraty> i wonder how many users have this installed:D packages-23.05/mips_24kc/base/amdgpu-firmware_20230804-1_mips_24kc.ipk

16:31 <Ansuel> (the joy od using DEBUG_LL to bisect and fix a linux kernel decompresso problem ahhhh)

16:50 <xback> robimarko: Ansuel: Anyone any idea why CONFIG_PPS would be enabled by default in ipq40xx or ipq806x targets? :-) (Pulse-Per-Second)

16:51 <robimarko> xback: Not really, I can only guess that its just been carried over for years

16:51 <xback> i'll prep a patch to kick it out then. thanks

16:52 <robimarko> That would be great, I am sure there is more stuff in those kernel configs that arent used

16:52 <xback> Also noticed these lines on a ipq40xx board

16:52 <xback> [ 0.187209] bam-dma-engine 8e04000.dma-controller: num-channels unspecified in dt

16:52 <xback> [ 0.187231] bam-dma-engine 8e04000.dma-controller: num-ees unspecified in dt

16:53 <robimarko> Thats expected

16:53 <robimarko> Only the newer SoC-s had those set in DT as previously they all used the same number

17:00 <Ansuel> btw i notice we enable

17:00 <Ansuel> ARCH_MULTIBOOT

17:01 <Ansuel> and that guard and disable some specific option.... why we have that enable if we build specifically for a target?