09:27 <gamiee> iscle : does that WCH MCU have SDIO slave peripheral? Isn't it Master?

09:27 <gamiee> Additionally, implementing the SD stack can be quite tricky

09:29 <iscle> gamiee: you're right, it's host only! i completely missed that

09:31 <gamiee> iscle: in that case, you cannot use it, sadly.

09:32 <iscle> yeah... well, at least I'm glad that was not the original idea haha

09:32 <gamiee> Also, that chip have only USB FS as far as I remember, so only 12Mbps bandwidth... That would be super slow.

09:32 <gamiee> What is your current plan iscle?

09:33 <iscle> Also, doing SD card emulation (even if the MCU supported peripheral mode) would have required a different schematic from what I am designing now, so less work for me I guess xD

09:34 <iscle> gamiee: The CH32V305 has USB HS :) The plan is to use it to write to the sd card directly (just like a normal SD card reader) and also take advantage of the UART peripheral, doing some sort of multi-purpose USB device

09:35 <gamiee> iscle : so you will still have SD card switch IC there, just use CH32 directly to be USB to SD, right?

09:35 <iscle> gamiee: exactly that

09:35 <gamiee> ah hmm

09:35 <iscle> I want to have a simple setup, avoid having to swap the sd card and the sd breakout (for serial) all the time, and having multiple cables on my desk

09:35 <gamiee> I was thinking about doing same thing some time ago.

09:36 <iscle> the project is on easyeda, I can share it if you want to check out the current state of it

09:37 <gamiee> Bouffalo Labs BL618 have both SDIO Master and SDIO Slave and USB HS. (Also, it have Ethernet). Theoretically it should be possible to do it with this chip. Although, I am not sure how much low-level access is there within SDIO slave, as some SDIO Slave IP cores do some communication handling in silicon, disallowing doing SD sim.

09:39 <iscle> gamiee: The problem with the BL616/618/818 is that they are not available on LCSC and would have to be soldered manually, which most people would not want to do if buying the board

09:39 <iscle> And also the SDK is the worst I've seen. I actually own a BL818 and we never got wifi/bluetooth working

09:40 <iscle> Otherwise, that MCU would be a no-brainer for any project

09:41 <gamiee> iscle: BL818 does not exists. And yeah, getting the chips directly is problem, but there are Ai-Thinker modules with the chip. The SDK is actually not that bad, at least, I was working with much worse ones in the past :D . Also, WiFi & BT worked fine for me on BL618.

09:42 <iscle> That was a typo, I meant BL808 xD

09:43 <iscle> The 618 seems to be a bit better supported: https://github.com/bouffalolab/bouffalo_sdk?tab=readme-ov-file#wireless-support

09:43 <gamiee> Ohh, BL808 is different story. BL618 is in much better shape.

09:43 <iscle> (not that we need wireless for this project, but it was annoying at the time)

10:24 <pitillo> Hello, good day, I hope I don't disturb anyone. Has anyone been able to compile the Mali kernel module (r6p2) from mripard/sunxi-mali on a 6.1.X kernel?

10:28 <pitillo> I'm having problems compiling it: mali_devfreq.c:63:17: error: 'struct mali_device' has no member named 'current_freq'

10:29 <pitillo> looking for its definition I can find it at r6p2/src/devicedrv/mali/common/mali_osk_mali.h (if I'm right)

10:32 <pitillo> and the current_freq depends on: #ifdef CONFIG_PM_DEVFREQ which is currently supported on my kernel: zgrep -i CONFIG_PM_DEVFREQ /proc/config.gz -> CONFIG_PM_DEVFREQ=y

10:40 <apritzel> pitillo: are you aware that this is very out of date? I don't know if anyone invested much time in this since we now have the OpenSource Lima/Panfrost drivers in mainline

10:41 <apritzel> pitillo: on which SoC / for which Mali is this? Do you desperately need the Closed Source blob?

10:54 <pitillo> apritzel: yeah, I know it's an ancient device. I'm trying to get closed source running on a Cubieboard2 (I have a Cubieboard ready too which will support it)

10:55 <pitillo> it's not really needed (it's just for fun, keep learning a bit more and to keep alive these toys)

10:56 <pitillo> I have lima support at kernel level, but I haven't deeped/researched to much about it. I've done some tests wth Xorg and the kernel module wasn't used, so I need to spend more time to understand what am I doing wrong with it

10:57 <pitillo> I was curious about its state, but like you said, may be it's not interesting for anyone to put time on these old devices, more when they are supported upstream by kernel/mesa

10:59 <pitillo> apritzel: anyway, thank you very much for answering and for your time

11:01 <apritzel> pitillo: it's not so much about the age of the device (CB2), but more about the pain to get that ancient closed source Mali400 blob running on halfway recent kernels

11:02 <apritzel> that was never fun back in the days, but since you should be able to run any mainline distro with decent OpenSource Mali support out-of-the-box nowadays, it's probably even more painful to go the old way

11:03 <apritzel> hence my question if you *relly* need that Arm provided Mali blob, or if the mainline kernel/Mesa would work for you as well

11:04 <pitillo> indeed, I've been reading sources to understand all the procedure a bit and I've seen the amount of patches required to get it working on kernels > 5.15.... so I just gave it a try and got far, but at that point that I don't really understand why it isn't detecting DEVFREQ.... but tweaking the sources to add the needed headers didn't help... sooooo probably it's more than enoght for my small knowledge

11:05 <pitillo> yeah, completely understandable. I just wanted to try to get advantage of those blobs to get full support, but they aren't really needed... Furthermore, few people will currently use this device, much less our distribution.

11:06 <apritzel> pitillo: but you wouldn't need to patch *anything* for mainline/Mesa on the A20. It should just work (given the right config options)

11:07 <apritzel> also: why 6.1.x? What's wrong with the latest kernel, say v6.15?

11:08 <pitillo> yes, I need to review libdrm/mesa stuff and check Xorg config to verify what's going on. Xorg works with sun4i-drm but kernel lima module isn't used

11:09 <pitillo> long history..... I've started testing with that version after I was able to build a current u-boot version for this device...

11:10 <pitillo> it shouldn't take too much time to rebuild a fresh/newer one on a container... so I can do it while I keep researching a bit more about lima

11:11 <apritzel> pitillo: did you run into any issues with current U-Boot? Because we would like to know...

11:12 <pitillo> apritzel: nop, it's working like a charm on the Cubieboard2 (v2025.04)... I still need to "finish" with it and put hands on the Cubieboard

11:13 <apritzel> and yes, it makes much more sense and is much more sustainable to drop the closed sourced blobs, and focus on Lima

11:13 <pitillo> you are doing and amazing job with U-boot... it keeps growing and it maintain support with older devices, so improving and maintaining tasks are awesome

11:13 <pitillo> s/it maintain/it maintains/

11:16 <pitillo> sorry my english level, I meant: improvement and maintenance work is incredible

11:18 <apritzel> and don't worry: A20 support will be "tier 1" for quite a while, so it's not really "old" (in the sunxi context). There are far too many users out there ;-)

11:22 <pitillo> great! good to know... so probably that's a good argument to keep it in shape from our side too