03:50 <jernej> apritzel: for H616 maybe, but H6 has all requirements already covered

06:28 <loki666> apritzel: I've ordered this sd card breakout board, but since the device only has one sd card slot, can we program the eMMC from FEL ?

06:29 <loki666> because I guess, we won't be able to boot from the SD card and use it as UART port

06:31 <loki666> you also say something about about a hacked boot0 that use portF for UART, can this boot0 be used on my A527 ?

09:11 <apritzel> loki666: so I connected a switch between the pins on the board and the UART adapter, so I can put the board into FEL via an SD card, then pop out the SD card and switch over to serial

09:12 <apritzel> loki666: but yeah, at the same it's either SD card OR UART, not both

09:13 <apritzel> sometimes I insert some extra delays, to let it boot, then switch over to the UART

09:34 <loki666> I can get into fel via Vol-/power button combo

09:35 <loki666> It will help for getting u-boot

10:56 <apritzel> loki666: ah nice, just keep in mind that this is vendor firmware induced FEL entry, which might be slightly different from the hardware triggered or early FEL entry

10:57 <apritzel> the vendor firmware runs for quite a bit, so does some SoC and maybe PMIC setup and UART init and such, and only then enters FEL

10:57 <apritzel> so it's not the normal pristine SoC state that FEL normally puts you in

10:58 <loki666> ok, would using the sdcard img to enter FEL safer?

11:00 <loki666> so workflow would be boot FEL sdcard, eject, insert sd card UART, send u-boot

11:01 <apritzel> yes, but I think you should keep using the button method, since it's much easier. Only if you see issues, you could use the SD card to verify that it's not related to the "vendor firmware FEL"

11:01 <loki666> noted

11:01 <apritzel> I often use FEL to query reset state of the SoC, and to do experiments, and there is might make a difference

11:02 <loki666> I guess I'll have to patch u-boot to use UART on portF

11:04 <loki666> btw: my panfrost got applied to drm-misc-next

11:04 <loki666> so all stars are aligned for GPU on H616

11:04 <apritzel> yeah, saw that, well done!

11:05 <apritzel> loki666: UART on PortF is controlled via CONFIG_UART0_PORT_F, so no need for a hack, just enable that Kconfig option

11:06 <apritzel> (not sure that's well tested on the newer SoCs, though)

11:06 <loki666> ah ok we'll see

11:07 <loki666> since this a vendor FEL, it still means I can brick the device if I screw eMMC ?

11:08 <loki666> I can use PhonexSuits to flash the device, but not sure it will work if it's FEL from sdcard

11:09 <apritzel> those actions should work regardless of how you enter FEL, really

11:09 <apritzel> it's just some more hacky stuff that one can do via FEL that might differ

11:10 <loki666> ok

11:11 <apritzel> but yes, this way of entering FEL relies on code loaded from the eMMC, so if you change that, you might need to revert to the SD card method

11:12 <apritzel> I also proposed a patch to gain this "entering FEL on a button press" functionality in mainline U-Boot: https://lore.kernel.org/linux-sunxi/20250417000539.3709-1-andre.przywara@arm.com/

11:13 <apritzel> not sure if those (volume) buttons on your device are direct GPIOs or via LRADC/GPADC?

11:16 <loki666> seems GPIO (looking at BSP dts)

11:41 <junari> apritzel: do you have any work on the power domain for the a523?

12:21 <warpme> guys: i have cpu-opp overlay with some extra opps. I'm loading it at runtime it via configfs. /sys/firmware/devicetree/base/opp-table-cpu shows those extra opps with status enabled. but cpufreq is not listing nor uses them. It looks to me like cpufreq subsytem needs kind of "refresh" to get those extra opps into operation. How i can do that at runtime ?

12:32 <dlan> apritzel: I'd plan to update the emac0 patch and roll out a patch v3 (will have a short holiday)

12:34 <dlan> for the allwinner,tx(rx)-delay-ps, I didn't quite follow to the discussion, but want to listen to your suggestion.. is anything I should update?

12:48 <apritzel> dlan: I think your series is fine, seems to be just nits that have been mentioned?

12:52 <apritzel> junari_: you mean that H6/H616 PRCM GPU power domain driver? Do you need that for anything?

12:59 <junari> I see that: allwinner,sun55i-a523-prcm-ppu on your [PATCH v2 0/4] arm64: sunxi: h616: Enable Mali GPU

13:01 <dlan> apritzel: thanks (also for the sram explanation), for patch 5/5 which adding avaota support, ideally someone own that board should give a Tested-by or Acked-by, so I can remove comment in that patch

13:01 <apritzel> junari: yeah, so I saw that the registers are there on the A523, and already added the compatible string to the binding, to save some churn later

13:02 <apritzel> junari: but the driver is missing the details at the moment, I wanted to wait until we actually need it and can test it

13:03 <apritzel> dlan: yeah, I was about to, but something is weird, as I have trouble booting it. I cannot really enter FEL mode reliably (it works on some days, and not on others)

13:03 <apritzel> dlan: and booting via SD card also fails for some odd reason. Haven't time yet to debug this

13:05 <apritzel> warpme: so you want to overclock the CPU, dynamically at runtime? A method using DT overlay wouldn't work easily, without explicit support in the driver: it would need to register a notifier using of_overlay_notifier_register()

13:08 <dlan> apritzel: no problem, I can wait, and maybe send an updated version the day after tomorrow (we should still have time)

13:09 <warpme> apritzel : oh well - my target is to do this at boot (via loading overlay in uboot). this Q about configfs is because i just want to test: is my overlay correct one...

13:10 <warpme> do you remember what command loads overlay in uboot (i'm using extlinux.conf approach) ?

13:10 <dlan> btw, if we target the patch for 6.16, is time to accept them between -rc4 ~ -rc5 still ok?

13:12 <apritzel> dlan: depends on the subsystem, and the people involved. If it goes via the sunxi tree, it's usually no problem to land just before -rc5 or -rc6 to get in

13:14 <dlan> yeah, it's all dts, so should via sunxi, I personally think rc6 is a little bit too late which give people no space to test

13:18 <apritzel> well, thorough testing can be done after it's been merged in -rc1, there is plenty of time still, and it's easier for people to get the code (they don't need to pull/merge specific branches)

13:20 <apritzel> dlan: the only potential problem in your case is that the bindings need to go in before the DT changes. That prevented the A523 DTs to be merged already in v6.15: there was one(!) binding missing

13:20 <dlan> ok, good point

13:20 <dlan> since there is no driver change, so it's perfectly fine to take the binding via sunxi tree

13:21 <dlan> but probably with DT maintainer's Ack

13:24 <dlan> Rob's comment, https://lore.kernel.org/all/CAL_JsqKD=yespd0WM90VBr_XWdppimzDzecmwNfGMV+hNSHuRA@mail.gmail.com/

13:25 <dlan> anyway, I don't want this to be pushy, so, it's fine if need to delay to 6.17

13:27 <apritzel> I wouldn't worry, I think it will make it. After all it's really just DT changes, the driver is already compatible

13:27 <apritzel> and it's a new SoC, so there would be no regressions