01:56 <tokyovigilante> acmeplus: can you check your -2024 board and see if it has a wifi chip? Just noticed the product page suggests it supports bluetooth controllers, and the DTS references both wifi and bt

01:58 <tokyovigilante> no never mind, chip not there on a youtube teardown.

02:00 <tokyovigilante> I suppose they mean with a dongle

02:04 <tokyovigilante> otherwise very few differences diffing the vendor DTS between the -2024 and the -Plus

04:44 <tokyovigilante> macromorgan: can you post your r_intc define? I assume you've added it to your H616 DTSI

06:00 <tokyovigilante> ok, have pushed a first rough draft DTS patchset to https://git.sr.ht/~tokyovigilante/linux/tree/anbernic-dts

06:01 <tokyovigilante> Have munged together all the regulators from my minimal set and macromorgan's complete set, but that will need refining, as do some of the GPIOs, and I'm missing the interrupt controller definition for the AXP. Otherwise in reasonable shape I think.

08:21 <Jookia> tokyovigilante: nice!

10:14 <apritzel> tokyovigilante: that looks quite good, and I think it's now time to move the technical discussions into the proper mailing list channels

10:15 <apritzel> I haven't looked at the actual patches, and would like to do this on the list only anyways, but would suggest some minor fixes to the commit messages:

10:17 <apritzel> the first patch looks good, just add one sentence saying what those devices are

10:18 <apritzel> the split of the patches looks good

10:19 <apritzel> but the subject prefix of the three .dts patches should be: "arm64: dts: allwinner: h700: ...." (not bindings: ...)

10:20 <apritzel> and maybe add "2024" to the base RG35XX, to avoid confusion with that older version

10:20 <Jookia> i know i shouldn't... but i feel like tomorrow i want to debug why dfu is so slow

10:20 <Jookia> i need to get my embedded code profiling skills up

10:20 <apritzel> Jookia: oh yes, please do, it looks indeed like something is fishy with the dfu implementation

10:21 <apritzel> tokyovigilante: the rest looks good, so please send the series to the lists, with the changes above

10:21 <Jookia> i haven't tried to profile code before without a debugger

10:21 <Jookia> or a proper profiler

10:22 <Jookia> u-boot wouldn't happen to have a ring buffer logging subsystem would it? :)

10:48 <tokyovigilante> apritzel: thanks for the feedback and vote of confidence, will tidy up and aubmit tomorrow.

16:20 <macromorgan> tokyovigilante: https://paste.debian.net/1313973/

16:21 <macromorgan> the compatible strings may need to be altered, depends on how upstream feels I guess. Note that something with interrupts isn't working currently as when I push the power button my board freaks out

16:22 <macromorgan> tokyovigilante: No wifi on my 2024 model either

16:22 <macromorgan> truth be told if that is literally the only difference you can use an identical tree, and it's just the wifi won't show up on the newer one without it

16:23 <macromorgan> not sure sure on the bluetooth though now that I think about it...

16:23 <macromorgan> I also need to get pwm controller working (I think trivial but need to confirm) and add the gpadc as well for the H series, I don't think it's used on the other models.

16:24 <macromorgan> If possible, please define the LEDs as PWMs if you can... I like the ability to control the brightness :-)

16:24 <macromorgan> otherwise I can define them once I get the pwm controller up and running (probably next week)

16:34 <apritzel> macromorgan: what's the timer about?

16:34 <macromorgan> I dunno... I just added it because it was there

16:35 <macromorgan> I had a list of hardware I was trying to add "because it was there" and I guess I forgot to take that one out

16:35 <apritzel> and in general the compatible name follow the scheme: "SoC specific name", "name of existing compatible device"

16:35 <macromorgan> right

16:35 <macromorgan> a proper mainline submission would do that and update the docs to match

16:35 <apritzel> the idea is that if it turns out there are not quite fully compatible, we can just fix this in the driver, by tying it to the specific compatible string

16:36 <macromorgan> right... let's just say I have experience being burned like that before...

16:36 <apritzel> yeah, it's also if the driver gains new features, which just the new chip has, for instance

16:37 <macromorgan> right

16:38 <macromorgan> anyway, I've got to do family stuff today (it's a saturday here) so I'll probably not look at this much more today. That said, any thoughts on the IRQ stuff? You don't have an H700 in hand do you by chance?

17:06 <apritzel> no I don't, though I feel it's more an AXP717 driver issue than anything else

17:07 <apritzel> so you say the IRQ triggers, but doesn't get acknowledged properly, so it stays triggered?

17:33 <macromorgan> I haven't done a ton of debugging yet, but basically when I define the NMI I see a handful of issues at boot: https://paste.debian.net/1313990/

18:19 <KREYREN_oftc> > <ity> KREYREN_oftc: since when are you back on copyleft? < -- I am doing copyfree but pinephone's copyleft and i might be working on a copyfree design

18:20 <jakllsch> pinephone hardware isn't copyleft..

18:20 <KREYREN_oftc> jakllsch, it's proprietary with copyleft schematics

18:21 <jakllsch> afaik the schematics are merely published

18:21 <KREYREN_oftc> i was told it has GPL

18:21 <gamiee> who told you thatň

18:26 <jakllsch> the schematics sure aren't published in "source form"

18:26 <jakllsch> they're PDFs, not the original EDA files

18:28 <warpme> guys: i'm playing with h313 tanix tx1 (https://linux-sunxi.org/Tanix_TX1). I got 6.8.5 kernel nicely booting without rootfs via sunxi-fel. Now i'm trying to boot 6.8.5 via sunxi-fel with rootfs and i'm getting like this: https://gist.github.com/warpme/6bf711b581174ede7ae158504017104e Line123 says about issue with allocation. I don't have much ideas how to move forward with this. Maybe somebody has any idea here?

20:08 <KREYREN_oftc> jakllsch, ye you are right it seems that it's proprietary and just published i asked a lawyer to review the files

20:08 <KREYREN_oftc> pain..

21:59 <apritzel> warpme: try in U-Boot: setenv initrd_high 0xffffffffffffffff

21:59 <apritzel> U-Boot wants to move the initrd, but it's too large to allocate a buffer for that

22:12 <apritzel> so is there any chance someone can review the AXP717 driver? Just grab a manual and compare it against the nonsense I put in the driver. Please. https://lore.kernel.org/linux-sunxi/20240329235033.25309-1-andre.przywara@arm.com/T/#u

22:13 <apritzel> macromorgan: please change "regmap_reg_range(AXP717_IRQ0_EN, AXP717_IRQ4_EN)," to "regmap_reg_range(AXP717_IRQ0_EN, AXP717_IRQ4_STATE),"

23:26 <Jookia> apritzel: I'll do a review if i don't fall asleep :)