11:32 <qschulz> Kwiboo: sorry, was OoO until today, will look at your patches as soon as I can, thanks for asking anyway :)

11:57 <Kwiboo> qschulz: no problem and thanks for taking a look!, I will try to send out patches to move rk3308, rk3328, rk3399 and rk356x to OF_UPSTREAM later today

11:57 <Kwiboo> will exclude rk3588 for now because the usb nodes and usb phy driver have diverged from what was finally accepted in linux

11:59 <Kwiboo> so we should probably clear that up before fully moving to OF_UPSTREAM for rk3588

12:03 <qschulz> Kwiboo: will try to remember to rebase the RK3588 Tiger patch series on that OF_UPSTREAM series whenever it comes (if my patches aren't merged before :) )

12:04 <qschulz> Kwiboo: FWIW, we have px30, rk3399 and rk3588 products so I can/will assist/help/review those ones specifically

12:53 <Kwiboo> qschulz: cool, I only have one rk3326 device and no px30 ones so will be reluctant to touch anything px30 related :-)

13:30 <Kwiboo> sre: are you looking into fusb302 issues? I was trying to get orientation detection working on my ZERO 3W/3E boards to work the other week and came across your issue #8 on collabora gitlab

13:32 <Kwiboo> the ZERO 3W/3E does not use it for PD, but reading up on the fusb302 datasheet it looked like it should support to be configured for automatic responses/requests

13:36 <Kwiboo> the use of tcpm also seem to hinder proper orientation detection in linux, the state machine does not seem to fully match the interrupts reported by fusb302, my port gets stuck in SRC_ATTACH_WAIT state waiting for a vsafe0v that will never come

13:38 <Kwiboo> for PD handling in U-Boot would it not be easier to just configure the fusb302 regs to handle automatic PD? instead of having a full state machine and interrupt handling implemented?

14:13 <mort> I'm building an image for a px30-based system with Yocto, using the Rockchip BSP meta layer. Somehow, when booting, everything looks 100% fine, the kernel starts and nothing looks wrong ... but there is no sign of any userspace??

14:13 <mort> Here's the full boot log: https://p.mort.coffee/5Iv

15:13 <robmur01> mort: "Waiting for root device PARTUUID=614e0000-0000..." - that will quite happily keep waiting for ever ;)

15:19 <robmur01> I'd try setting a time limit with "rootwait=..." rather than bare "rootwait", then when init gives up it should at least dump details of the partitions that did show up

15:44 <mort> robmur01: oh, good catch! I also noticed that but I disregarded it because, well, it makes sense that it has to wait until the MMC shows up, the MMC shows up a few hundred milliseconds later, so it's probably fine

15:47 <mort> robmur01: does it normally print something once it's done waiting and has found the partition with the right uuid?

15:47 <micken> sorry for repeating myself , but :

15:47 <micken> I have a question about Win2 on VOP (RK3399). I am trying to set it 1bpp .. but I get 8bpp.. a bit confusive how I should set virtual stride. I have win 0 set as 1920x1080 rgb 565

16:08 <robmur01> mort: yes, once the expected root device is found, init will proceed and you should see the "Freeing unused kernel memory" and "Run /init as init process" messages

16:16 <robmur01> so the implication is that presumably none of those eMMC partitions actually match that UUID

16:23 <mort> yeah

16:23 <mort> rburton over on #oe mentioned an initramfs module to add a shell

16:23 <mort> I'll try to use that and investigate

16:32 <diederik> Kwiboo: do you *know* if https://github.com/Kwiboo/u-boot-build/actions/runs/8501617322 PT2 build works (on PT2)?

16:33 <diederik> I've created an image and wrote it to eMMC and written that u-boot build, but it seems it doesn't boot up

16:33 <diederik> Could also be an issue with my image, but I suspect not

17:13 <diederik> hmm "mmc0: error -110 whilst initialising MMC card" doesn't sound good ... and I no longer have a /dev/mmcblk0 device ...

17:19 <diederik> phew, was PEBKAC issue; I've now booted it up \o/