06:22 <szemzoa> apritzel: I would like to communicate with the RISC-V mcu inside the v85x. There are not to many specific things, it can be extended to other SOC(s), but I'm not an expert. All of my patches for v85x are here: https://github.com/szemzoa/awboot/commit/9a476a92e5fa1c67eeb83c4ccaf07f08a4abcb02

06:24 <dsimic> isn't that MCU supposed to run some SCP firmware?

06:47 <szemzoa> I think no, thats a completely free to use E907 RISC-V core.

06:49 <dsimic> that's quite interesting

09:13 <apritzel> szemzoa: yeah, I think that's the problem: we decided to not expose the management core to the OS, because it is indeed supposed to run firmware code, for power management and such

09:14 <apritzel> (as dsimic said)

09:14 <apritzel> now technically there is indeed no reason to not use this for any kind of "outsourced" code

09:15 <apritzel> and we could indeed use remoteproc to give access to that, if the firmware chooses to not use that core

09:15 <apritzel> but that would be optional, I guess, so you could not rely on that

09:16 <apritzel> which might not be a problem in an embedded use case, but is quite some caveat for general purpose use

09:16 <apritzel> szemzoa: so just brace yourself when you send this to the list - which you should do regardless

09:34 <szemzoa> I don't know if it's even worth the effort.

09:34 <szemzoa> It could be a nice upgrade from the relatively popular F1Cxxx. ARM9 -> CA7 + RISC-V + Viplite NPU + the s3 variant with 128MB ram.

09:35 <szemzoa> But without GOOD documentation/ml-linux support it's only a hobby toy, there are better alternatives, like Sophgo SG2002.

09:35 <szemzoa> This is how it should be done: https://github.com/sophgo/linux/wiki

09:36 <szemzoa> (by allwinner)

11:01 <apritzel> szemzoa: Well, if no one steps up and actually sends patches, just nothing will happen.

11:02 <apritzel> and you can't be seriously waiting for Allwinner to do this?

11:03 <apritzel> I mean either from a professional standpoint you wouldn't chose Allwinner in the first place, for this behaviour, or...

11:04 <apritzel> you recognise that the community is better anyway, but then you would need to contribute, since the V85x series seems a bit niche, at least among hobbyists that typically contribute to mainline

11:05 <apritzel> I am happy to help out with support and review, but someone needs to send patches

11:05 <apritzel> (and since you apparently sit on something that applies to mainline-ish kernel, this could be as well you)

12:20 <iscle> Hi! I was also working (playing) with V853 (V851s actually) and szemzoa contacted me via email regarding this topic. I think we might be able to contribute to mainline the basics like the ccu, pinctrl and usb phy drivers. I've tested them on my board (a cheap usb to wireless carplay adapter) and they work as expected. I also did the u-boot port, which i would also love to mainline.

12:20 <iscle> However, I've never contributed to big projects such as u-boot or linux, and IMO it's a steep learning curve with the mailing lists and everything. Either way, I love to learn so I can try to contribute those 3-4 drivers + base dts (crediting szemzoa where needed, since his work also helped me get where I am), and then maybe szemzoa can contribute the riscv core stuff which I'm not interested in.

12:49 <apritzel> iscle: that sounds great, thanks for stepping up!

12:50 <apritzel> iscle: so first step would be to get the patches in acceptable state, in your private git repository. You could push this somewhere (your github?) for prior inspection, if you are unsure

12:50 <apritzel> then the next step would be to setup git-send-email, and send a series to yourself, to see if that works

12:52 <apritzel> iscle: maybe post a link to some repo (of yours) in here, so people could give you more specific advice on what to do

12:57 <apritzel> iscle: feel free to ask more specific questions, it's a bit hard to explain all his. Also https://docs.kernel.org/process/submitting-patches.html gives you a good (though lengthy) intro, I guess

12:58 <apritzel> if in doubt, when it comes to the contribution process, consider U-Boot like the little sister of Linux

15:27 <iscle> Sure, let me clean the commit history a bit and I'll post a link here. I'm sure the commit messages will have to be changed or improved in some way, but hopefully the code (which is based on sun20i-d1) will be more or less right. IIRC there was a way to format the code automatically or at least run a check to see if indentations or something is wrong, which I'm also afraid might be somewhere haha

15:31 <apritzel> iscle: "scripts/checkpatch.pl -f path/to/source/file.c" would check a file, or you run the script on the patch file, then without the "-f"

15:37 <iscle> apritzel: Thanks, will try it later today or tomorrow and report back :) It's really interesting stuff!

16:03 <apritzel> iscle: if there is quite some code to reformat, check: https://docs.kernel.org/dev-tools/clang-format.html