01:51 <yangxuan> hi

04:08 <yangxuan> How to enable 3d acceleration on meson gxl s905d with mainline 4.18 kernel? I tried run deepin on a s905d, it not support windows effect.

08:32 <mjourdan> ndufresne: Thanks! It's possible that you don't receive the event if you already S_FMT and the amount of capture buffers is enough to please the dpb size.. In that case it keeps going as usual.

12:31 <afaerber> lvrp16, thanks for considering the EBBR for La Frite. It's not explicitly spelled out on the campaign page: Will it be S905X again, as seen in the gallery photos?

12:35 <ldevulder_> afaerber, S805X, https://libre.computer/products/boards/aml-s805x-ac/

12:35 <narmstrong> afaerber: it's a goal, there is a SPI NOR for that explicitely

12:35 <narmstrong> ldevulder: champagne !

12:36 <ldevulder> narmstrong, for? :)

12:36 <narmstrong> ldevulder: u-boot vim2 patches merged

12:36 <ldevulder> narmstrong, oh yes :)

12:37 <ldevulder> don't know also if you see: the usb dwc3 patches from Jean Jacques Hiblot fixe the usb issue on vim and le potato, hope it will be merged soon

12:37 <ldevulder> I added a tested-by

12:38 <narmstrong> ldevulder: I haven't followed... thanks for testing & following !

12:39 <ldevulder> but not on kvim2 :-( I hope to have some times in few weeks to investigate more, this week I tested ATF with AntonioND on S905X, not to bad for a first try

12:40 <narmstrong> yep, it's on the good path

13:06 <afaerber> ldevulder, thanks for the link

13:08 <afaerber> narmstrong, yes, I read that on the campaign page (the typo has since been fixed ;)) - they're the first SBC vendor I see publicly striving for EBBR compliance, so that is worth a big thank-you :)

13:08 <AntonioND> mainline linux doesn't have support for the timers of gxbb, right? only the 3.x fork. not the architectural ones, the ones of the datasheet (timer a - h)

13:09 <xdarklight_> AntonioND: there's the meson_timer driver which supports timer A (with IRQ) and E

13:09 <AntonioND> yes, but that's not in mainline, as far as I can see

13:10 <xdarklight_> drivers/clocksource/meson6_timer.c

13:11 <AntonioND> oh, interesting

13:11 <AntonioND> I was grepping for meson-timer

13:11 <xdarklight_> I have three patches in my tree because I was wondering whether I could support all 4 timer IRQs

13:11 <xdarklight_> https://github.com/xdarklight/linux/commit/da70b065d5c8e8efd16a8da8471798216655b57f https://github.com/xdarklight/linux/commit/a7f83fff65e75bbf4cfd4a3cd9f25385a7505c58 https://github.com/xdarklight/linux/commit/6fb537b2066351658dae3e477ca5fbf33a22735a

13:11 <AntonioND> so I assume that IRQs are working, right?

13:12 <xdarklight_> on Meson8b and Meson8m2 the Timer A IRQ is working fine, yes

13:12 <xdarklight_> (that's 32-bit SoCs)

13:13 <AntonioND> ok, I will then give it another shot today. I however, I can't see you using any special new register...

13:13 <xdarklight_> my change only updates the naming of the existing register definitions

13:14 <xdarklight_> with the existing ones it wasn't clean to me that it was using Timer A and E

13:14 <xdarklight_> s/clean/clear/

13:14 <AntonioND> yeah, I see

13:15 <AntonioND> why are there only 4 timers in the dts? shouldn't it have 2 sets of 4?

13:15 <xdarklight_> yep, I think the reason is: nobody cared so far

13:16 <AntonioND> this guy did... https://forum.odroid.com/viewtopic.php?f=139&t=30269

13:16 <AntonioND> :P

13:16 <AntonioND> at least about having timers

13:18 <ndufresne> mjourdan, right, so source change could also be from a an SPS/PPS update

13:19 <ndufresne> so same resolution, but more buffers might be needed

13:19 <ndufresne> good to keep in mind

13:22 <narmstrong> AntonioND: we don't have yet the need for these timers... at least we didn't found the need yet (we are maybe missing something...)

13:22 <narmstrong> The arch timers seems enough for now...

13:23 <narmstrong> I'm not a clockevent/timer expert either !

13:23 <AntonioND> well, for the most part you can just use the arch timers, but in this case I need a global timer for the framework to work...

13:23 <AntonioND> i think...

13:24 <mjourdan> ndufresne: Also important to note is that if you receive a src_change event, you must restart the capture queue (even if you don't intend on touching the buffers). Otherwise the decoder is paused.

13:24 <mjourdan> But since right now you are doing a full reset then it doesn't really matter

13:24 <narmstrong> AntonioND: The S905 Datasheet IRQ numbers are completely wrong, only the 3.14 DT has the correct numbers

13:25 <AntonioND> yes, i've had some fun with that... I actually enabled irqs from all SPI ids targeted to my CPU and i still couldn't get any interrupt

13:27 <ndufresne> mjourdan, yeah, well, right now, it's not implemented, so it will pause ;-D

13:28 <ndufresne> but only in very rare conditions, you'll need multi-sps streams, which is really rare

13:34 <ndufresne> mjourdan, I just hope we'll be able to get a good experience with dash as soon as this is implemented, well in fact, we just need to get Chrome running to test

13:51 <ldevulder> ndufresne, AntonioND, if we can't trust docs what can we trust? xD

13:52 <AntonioND> what is better, having no docs or having misleading docs? :P

13:56 <xdarklight_> AntonioND: I believe the answer to that is: "talking to the SoC designers" ;)

13:59 <AntonioND> they are usually behind an IP wall :(

14:19 <chewitt> AntonioND: we have some good senior contacts in Amlogic if questions need to be asked

14:19 <chewitt> they are most effective when people are asking for something explicit

14:20 <AntonioND> i don't think i need them for now... i'm just playing with timers :(

14:20 <AntonioND> it should be easy

14:21 <chewitt> okay, but if you get stuck on something please ping me (or via narmstrong) so we can organise an email address for someone you can correspond with

14:31 <AntonioND> ok, thanks, chewitt. i suppose that they are fine with this port, then? or indiferent? it's not like I want to replace what they have, I just want a minimal implementation of PSCI and basic cpu errata and stuff support...

14:33 <chewitt> hard to tell sometimes

14:34 <AntonioND> i see

14:34 <chewitt> mostly I talk to the management people to make them aware of what we (LibreELEC) are up to so they don't make daft decisions that impact us down the line

14:34 <chewitt> we aren't important enough to actually influence their direction

14:35 <AntonioND> well, in the case of odroid it has zero support from the company, so even if they were annoyed they can't really complain that someone wants to support it by himself

14:35 <AntonioND> the c2

14:35 <chewitt> but I think we've avoided future issues by talking .. so it's not a waste of diplomacy

14:35 <AntonioND> yeah, that's good

14:36 <chewitt> i'd kind of summarise as saying they're foss supportive as long as it doesn't cost anything :)

14:37 <AntonioND> ok, that's good enough :P

14:37 <chewitt> they've always tried to be helpful when we've asked for things

14:37 <chewitt> they're lost with general requests

14:37 <chewitt> but when we're explicit about things we can usually get answers

14:39 <AntonioND> but I guess that you are talking about EL2-EL0 stuff, right? they removed a good chunk of information from the datasheet they gave to hardkernel, so I'm not sure if they would be as willing to talk about that as with other things

14:45 <chewitt> better to ask and be politely refused than not try tho

14:46 <chewitt> most vendors are secretive because the documentation doesn't exist :)

14:52 <AntonioND> true...

18:20 <poulecaca> don't know if it could interest someone. But I think I have successfully reverse aml_encrypt_gxl binary for "-bl3enc" and "-bl2sig". I am currently able to reproduce a "-bl3enc" with a shell script and "-bl2sig" should be doable soon also. I'll soon write a tool to do bl3enc and bl2sig if some people are insterested in using an open tool to produce binaries images for gxl.

19:08 <ldevulder> poulecaca, interesting yes!

21:18 <ldevulder> poulecaca, if you have the algorithm we can then try to adapt this in C and add it in afaerber's meson-tools, could be interesting to have it here also (meson-tools already support S905)

21:24 <poulecaca> ldevulder: yes I have it. It's not a hard one, I began to write the code. I could try to integrate it after to afaerber's repo.

21:26 <poulecaca> bl3enc is easy, it's just a matter of generating an random aes-256-cbc key put it in header along with a iv. encrypt the whole binary. Prepare a header of 512 bytes, and put it in place of the first 512byte of encrypted payload. Relocating this first 512bytes block at the end

21:27 <poulecaca> and you need to hash the whole encrypted payload with sha256 also