04:32 <dsimic> mmind00: regarding the descriptions of Rudraksha's patches, I'll send an example of description in prose to the ML in the next few days

04:33 <dsimic> (for future reference: https://lore.kernel.org/linux-rockchip/115da845d9161e6ecfa67cf189b84aa8@manjaro.org/T/#u)

06:10 <wens> Ermine: Mac hardware expecting 16kb pages is the main reason?

06:28 <Ermine> wens: probably

08:45 <mmind00> dsimic: though I would assume Rudraksha might be able to create their own version from the example? That was what my mail was meant to facilitate ... provide the scheme, but let them invent their own for the patches :-)

08:59 <dsimic> oh, of course

09:02 <dsimic> I'll wait a few days before sending that to the ML, because it's better for someone to figure things out on their own and learn in the process, than to just "copy & paste" a possible solution offered by someone else

09:04 <dsimic> in fact, I need to finish and submit a couple of accelerometer mount-matrix patches for some Pine64 devices, whose descriptions are direectly related to Rudraksha's patches... I'll leave that for the next week, to let Rudraksha do some work on improving the patch descriptions on their own :)

09:04 <dsimic> I think that sounds like a plan

14:16 <pinchartl> has anyone encountered "EQOS_DMA_MODE_SWR stuck

14:16 <pinchartl> on a RK3588 ?

14:16 <pinchartl> I'm trying to use mainline U-Boot on an orange pi cm5 base board

14:16 <pinchartl> which has no upstream DT yet

15:19 <pinchartl> Kwiboo: do you run upstream or bsp tf-a on your orange pi 5 ?

18:22 <mmind00> pinchartl: I've not enountered that particular message yet ... but am wondering at what stage that happens

18:24 <mmind00> and in which vendor<-> upstream software permutation for uboot tf-a kernel :-)

18:45 <pinchartl> mmind00: I've tried various combinations

18:46 <pinchartl> at the moment I'm running tf-a master and u-boot master

18:46 <pinchartl> with a .dts that is a merge of rk3588s-orangepi-5.dtsi (from u-boot upstream) and the orangepi kernel BSP DT sources

18:47 <pinchartl> I've double-checked everything I could agains the schematics

18:47 <pinchartl> but very annoyingly, while the carrier board schematics is available, the CM's isn't :-(

18:47 <pinchartl> I was previously using a tf-a binary from rkbin

18:48 <pinchartl> the message occurs when I run "dhcp"

18:48 <pinchartl> "mii info" doesn't find the PHY so I'm investigating that too

18:58 <mmind00> pinchartl: ah, now I found the message in the u-boot sources ... was unsure if you had already booted "something"

18:59 <mmind00> pinchartl: I'm running (and network boot) a rk3588 tiger+jaguar with upstream tf-a for a while now

18:59 <pinchartl> I'm sure it can work :-)

18:59 <pinchartl> I just wonder why it doesn't work

18:59 <mmind00> pinchartl: One thing I could think of is the clocking of the phy

19:01 <mmind00> like the ethernet phys get their 25MHz or whatever clock from somewhere ... sometimes from a separate oscillator and sometimes from a soc clock source ... there are probably even more wonky variants

19:02 <pinchartl> according to the schematics it's an on-board oscillator and it doesn't have an enable pin

19:02 <mmind00> darn, there goes my theory

19:02 <pinchartl> my bad, it's even a crystal

19:02 <pinchartl> so clearly no enable pin :-)

19:02 <pinchartl> the power supply is always on (again according to the schematics)

20:14 <Kwiboo> pinchartl: I have mostly use latest vendor rkbin tf-a blobs for board bringup testing in U-Boot, and my ethernet testing has been limited sometime only ensuring dhcp and ping cmd works, I have never seen a EQOS_DMA_MODE_SWR stuck message, most testing is also with cold boot or pmic reset

20:20 <pinchartl> I think I've found the issue. I'm testing a fix

20:45 <pinchartl> apparently turning the 3v3 power supply helps...

20:45 <pinchartl> there are still issues, but it's better