13:39 <marc|gonzalez> narmstrong: thanks for the review. What does "Why was ? it's no more it's codename ?" mean??

13:42 <marc|gonzalez> narmstrong: you didn't split the yaml part in b7be144932a83 but I suppose this is the privilege of maintainers ;) and I was expecting that request

13:46 <narmstrong> marc|gonzalez: yeah it was in the old days, thing were simpler and more chaotic, now it's expected to be separate!

13:47 <marc|gonzalez> I'm on it :)

13:47 <marc|gonzalez> What did "Why was ? it's no more it's codename ?" mean?

13:47 <narmstrong> oh ok now I understand the Pop is based on SEI530FB

13:48 <narmstrong> ok you should reformulate like : "Based on the SEI530FB, derivative of the SEI510"

13:49 <marc|gonzalez> Oh my brain managed to parse the sentence!

13:50 <marc|gonzalez> I'll ask phh, but I think pop = fbx8am = sei530fb

13:51 <marc|gonzalez> I wrote 'was' because usually we use codenames early in the life of the project, then use a different name later on

13:53 <phh> SEI530FB is the codename SEI-side, fbx8am is the codename Freebox-side, Player Pop is the commercial name

13:53 <narmstrong> Oh ok, I see now, it's ok then

13:53 <narmstrong> you can replace with this sentence, it would be perfect!

13:53 <f_> I guess marc|gonzalez also works for free.fr?

13:53 <phh> f_: yes

13:54 <f_> cool

13:54 <narmstrong> Side question, is there some plan to upstream more of the other Qualcomm based devices ? (it's my other hat)

13:55 <f_> Neil working on qcom!

14:05 <phh> narmstrong: there is definitely some plan, and I technically have a venus fix for msm8998 to push, and a WIP dts that has hdmi out, venus, wifi, and uh stuff i don't remember. What is known not to work is hdmi 4k, TheScaryMoster© CPR (i don't know if i can get a dumb cpufreq without CPR since we really don't care about power consumption) -- decoding 4K at 300MHz is fun. audio (speaker and mic, both over I2S) is the next in todo list, but later

14:08 <narmstrong> phh: nice, hope you will be able to push all this^^ for the cpr you can perhaps ask to lumag and konradybcio on OFTC #linux-msm, they are basically wizards on qcom SoCs for Display and obscure system related stuff

14:10 <marc|gonzalez> narmstrong: back in 2018, I was supposed to upstream all the bits for the msm8998, then qcom said "You want the HW docs?! Fuck off, lamers."

14:10 <phh> narmstrong: yeah I hope. But I have to point out that we're nowhere near doing it full-time. Using mainline in production on those platforms still look to be an incredibly high hill (we need DRM -- the bad kind -- and HDR, and even Dolby Vision on fbx8am to mention just the obvious ones)

14:11 <narmstrong> marc|gonzalez: yeah I understand the struggle

14:11 <narmstrong> phh: the multimedia stuff will remain the hardest the upstream

14:11 <marc|gonzalez> I don't know if they just don't just a "small" French company, or if they're just typical corporate assholes, but it sucks

14:12 <marc|gonzalez> *don't trust

14:12 <narmstrong> they're hardcore in business...

14:13 <marc|gonzalez> By now, the value of the 8998 HW docs should have dropped to 0, but still they won't release them

14:13 <phh> narmstrong: on amlogic the way to DRM isn't too hard. Kernel-side, in my mind, it pretty much requires just secure dma heap. But actually I feel like meson vdec needs to be completely rewritten for X2/X4 to remove the parser, and switching to what looks like to me a stateless decoder

14:14 <narmstrong> phh: yep, it's also my PoV, the "old" decoder should be split out and "new" ones should bypass the parser

14:14 <narmstrong> the ES parser makes it impossible to correctly track buffers

14:15 <narmstrong> but AFAIK nobody has time for such rework...

14:15 <narmstrong> and yeah I'm pretty sure we could reverse the new decoder state buffers and make them stateless

14:16 <f_> phh, marc|gonzalez: is upstreaming u-boot changes also planned?

14:16 <narmstrong> marc|gonzalez: yep but I'm pretty sure nobody in qcom remembers anything about 8998...

14:17 <narmstrong> only weird irc persons seems to be interesting in those old weird tech

14:17 <narmstrong> even if millions still uses the hw daily

14:18 <phh> f_: sorry, but no... we really don't see how it helps doing long term support. that being said, I wouldn't mind sending you 2 pcs of our STBs, one without secure boot, one with development secure boot keys we can give you. though we have multiple DDR varirants, and what i can send you is only with one variant

14:18 <f_> Am I weird for reverse engineering ~8 year old SoC firmware?

14:18 <narmstrong> f_: nah, well yes, but you're not alone

14:18 <f_> phh: you're talking about SPL support :)

14:19 <narmstrong> some people are reverse engineering gameboy PCBs

14:19 <f_> I said u-boot as in u-boot proper

14:19 <f_> narmstrong: hehe

14:19 <narmstrong> phh: I'll be perhaps interested in one non-secured unit to put in CI, I don't have any SEI510-like left

14:20 <f_> Don't worry, I'll be less weird once I start reversing g12b

14:20 <f_> phh: I'll consider, thanks!

14:20 <narmstrong> phh: basic u-boot mainline would only invold syncing dt to u-boot git and adding a defconfig

14:20 <f_> yeah pretty much

14:21 <f_> phh: But..yeah I wouldn't mind another STB without secureboot :)

14:21 <phh> i'll see what I can do, but those are pretty rare here, since we did it only at the beginning

14:22 <phh> f_: but you're not interested in looking at secure boot?

14:22 <f_> sure

14:23 <f_> I didn't say yes yet lol

14:23 <f_> I'll ping you if I accept. Thanks a bunch!

14:24 <f_> These are S905X2 right?

14:24 <phh> yup

14:24 <phh> I know you didn't say yes yet, but I didn't either :P

14:24 <f_> lol

14:25 <f_> I did say thanks though :)

14:26 <f_> hmm no datasheets for S905X2?

14:27 <f_> Meh.

14:27 <f_> Not a big deal.

14:27 <phh> I do have something that Amlogic calls a datasheet (but I don't), but I can't share it. narmstrong maybe has something though

14:27 <narmstrong> I had one, but it very close to A311D which is public

14:27 <f_> well I can probably use a G12B datasheet

14:28 <phh> yeah it's g12a vs g12b

14:28 <phh> afaik it's just cpu core one pll and npu

14:28 <f_> before it was gxbb vs gxl

14:28 <narmstrong> remove the second cluster, NPU and camera stuff and you have g12a

14:28 <narmstrong> they even share the same sdio controller bug

14:29 <f_> Not really that surprised lol

14:30 <phh> wrt the sdio controller bug, I'm looking at downstream Linux 5.15 for g12a, and they are no longer using ""sd_emmc_a@ffe03000""" with dram-accessquirk, but ""sd_emmc_b3@ffe05000"", and my brain doesn't compute

14:34 <narmstrong> yep, they added a metal fix to be able to route the sd_emmc_a signals to sd_emmc_b and they share the controller between sdio and sdcard

14:35 <phh> ... with a chip select?

14:35 <narmstrong> nop, they dynamically switch the signals out of sd_emmc_b to the sdio or the sdcard when needed

14:36 <marc|gonzalez> Why does SCHEMA complain about snps,dwmac.yaml: mac-mode: missing type definition?

14:36 <marc|gonzalez> Isn't "$ref: ethernet-controller.yaml#/properties/phy-connection-type" a type definition?

14:36 <narmstrong> in theory it works, but it involves a lot of hack to keep signals consistent when switched

14:36 <f_> narmstrong: yeah so it werks™.

14:38 <narmstrong> marc|gonzalez: hmm I don't see

14:39 <narmstrong> marc|gonzalez: dt_binding_check doesn't complain on my side, did you get the latest version of dt-schema tools ?

14:40 <phh> narmstrong: and erm, the DTS we're pushing is using sd_emmc_a. That's still the preferred way in mainline right? we're not going to switch to sd_emmc_b3?

14:40 <phh> gosh that's such a horrible hack

14:41 <narmstrong> phh: yep no, while it would be possible to describe it, multi-slot mmc isn't possible yet in upstream mmc framework, and perhaps forever

14:41 <marc|gonzalez> narmstrong: it's not dtbs_check that prints that, it's when you build the schemas

14:42 <marc|gonzalez> I got it from 'make clean && make dtbs_check'

14:42 <narmstrong> marc|gonzalez: with dt_binding_check ? what do you use to build the schemas ?

14:42 <marc|gonzalez> Let me do a make V=1

14:45 <marc|gonzalez> # SCHEMA Documentation/devicetree/bindings/processed-schema.json

14:45 <marc|gonzalez> f=$(mktemp) ; find ./Documentation/devicetree/bindings \( -name '*.yaml' ! -name 'processed-schema*' \) > $f ; dt-mk-schema -j @$f > Documentation/devicetree/bindings/processed-schema.json ; rm -f $f

14:45 <marc|gonzalez> /home/mgonzalez/linux/Documentation/devicetree/bindings/net/snps,dwmac.yaml: mac-mode: missing type definition

14:45 <marc|gonzalez> $ dt-mk-schema -V

14:45 <marc|gonzalez> 2023.11

14:48 <narmstrong> OK same dt-schema tool version, I can't reproduce on next-20240206

15:02 <marc|gonzalez> I'm on v6.8-rc1

15:02 <marc|gonzalez> If they fixed it in the mean time, good! :)

18:27 <f_> hmm https://bin.vitali64.duckdns.org/65c279f9

18:27 <f_> >unable to select a mode : -74

18:27 <f_> >spl: mmc init failed with error: -524

18:27 <f_> include/linux/errno.h:#define ENOTSUPP 524 /* Operation is not supported */

18:29 <f_> oh wait what

18:30 <f_> https://elixir.bootlin.com/u-boot/latest/source/drivers/mmc/mmc.c#L2249