03:42 <tito-me-doe> I am in the US, but more than that, I am a father and full time employee. I admit there’s a lot I don’t know about the social aspect of the existing community specifically surrounding LibreELEC and its forks. I have over 20 years expertise in general *nix, FOSS, and software development, but I’m yeah very new to this specific niche

05:24 <chewitt> morning :)

08:09 <f_> wait you don't use the one true timezone UGT?

08:13 <f_> tito-me-doe: May I ask, have you looked at vendor BSPs before?

08:14 <chewitt> I usually feel unclean after looking at them :)

08:14 <f_> haha, same :)

08:15 <f_> Though I kinda have to stare at them sometimes, they often contain interesting clues

08:15 <chewitt> laziness is your friend

08:15 <f_> but would I try cleaning that up or even use it in production? Naaaahhhhhh

08:16 <f_> chewitt: eh when I'm lazy I help folks in IRC instead

08:16 <chewitt> I mean; lazy vendor devs leave lots of clues

08:16 <f_> ah right

08:16 <f_> yes, lots of copy-paste of the same code everywhere :D

08:16 <chewitt> the demands of shipping a product require you to play the "choose your compromise" game

08:17 <f_> Even on their firmware there's a lot of copy-pasting done

08:17 <f_> if it works don't fix it

08:17 <chewitt> as long as it 'works' the task is completed and you move onto the next task

08:18 <f_> until somebody finds a vulnerability in the code

08:18 <f_> in which case you have to fix it ;p

08:18 <chewitt> I love the "problem: x does not support y" .. "fix: add support for y to x" commit messages :D

08:18 <f_> same :D

08:18 <f_> Problem: Bl30 does not work on S805X

08:18 <f_> Solution: Add S805X support for BL30

08:19 <f_> ahh if only it were so simple lol

08:19 <f_> Problem: amlogic firmware is proprietary

08:19 <f_> Solution: spend years reversing it

08:19 <chewitt> mind you .. if I were asked to make commit messages in Chinese .. expect similar brevity

08:20 <f_> chewitt: If I were asked to do it I would probably write meaningless junk, not "problem/solution" commit messages :D

08:20 <f_> so props to them in any case

08:21 <chewitt> I guess someone did it once, and then others cribbed the idea and it became the standard

08:21 <f_> The coding style though.... I know for sure amlogic employees can do better than that

08:21 <chewitt> or management said "commits must have a problem and solution description" but never checked the result

08:22 <f_> But I suppose management also puts deadlines and such (as usual) and doesn't check the result as long as it 'works'

08:22 <chewitt> if there's only four of you working on something in isolation, all of your ideas sound great

08:22 <f_> well.

08:22 <chewitt> the ideas are never subjected to serious peer review

08:22 <f_> I know Amlogic started letting a 3rd-party to look at their source code

08:22 <f_> a good while ago

08:22 <chewitt> there's a bunch of them

08:23 <f_> Have you heard of riscure?

08:23 <chewitt> but those third parties are mostly hired to do a task for a price, and that generally precludes large amounts of refactoring and improvement

08:24 <f_> Firmware-wise I mean, some of their BL2's have the strong "riscure-review-[numbers]" in their "Built :" string

08:24 <chewitt> no, but I heard of Keysight who now appears to own them

08:24 <f_> s/strong/string/

08:25 <f_> Until I got a Mi TV Stick I haven't actually owned any device that came with such a binary

08:25 <chewitt> there are known exploits in the bootrom code so it's only sensible to outsource a security review and implement the findings

08:25 <f_> yeah.

08:25 <f_> wait I might be misremembering

08:25 <f_> $ strings bl2.dec | grep Built

08:25 <f_> Built : 02:44:47, Jul 31 2023. gxl g20499a1 - jenkins@walle02-sh

08:26 <f_> might've been BL31 or BL32

08:26 <f_> Uh no https://bouncy.vitali64.duckdns.org/uploads/funderscore/d10953ba-xiaomi-aquaman_uartlogs

08:27 <chewitt> the latest boards are basically hostile to open-source

08:27 <f_> They're hostile to users in general

08:27 <chewitt> as all the video firmware must be loaded from secure-world, which implies vendor u-boot (and blobs)

08:27 <f_> Xiaomi is also pretty hostile to FOSS w/ their tv stick

08:28 <f_> Lots of security through obscurity there

08:28 <f_> ..that ultimately failed anyway

08:28 <chewitt> the technical direction Amlogic is headed in makes me think they're an evolutionary dead-end for upstream support

08:28 <f_> In stock Android 9 their vendor U-Boot exposed a shell over uart

08:28 <f_> Then after an upgrade all of the u-boot UART logging was gone

08:29 <f_> Then the Android 10 upgrade brought back the shell

08:29 <chewitt> they will have achieved their goal of being so obfuscated and problematic that nobody with any FOSS principles will want to work with their chips

08:29 <f_> chewitt: Looks like, yeah.

08:30 <f_> Their TV SoCs are also pretty much black box

08:31 <chewitt> I never looked at them but I doubt they're too different aside from having different connectivity

08:31 <f_> that's the thing. No one ever looked at them

08:31 <f_> No one ever ran mainline u-boot on those

08:32 <f_> let alone mainline linux

08:33 <chewitt> there's support for some of them in the BSP drops I've seen, although whether that's leftovers and another codebase is used or that's the actual codebase .. anyone's guess

08:33 <chewitt> bsp stuff has a large sep field around it for me

08:34 <f_> What I have trouble understanding also, is how in the world did xiaomi get android 10 on gxl

08:35 <chewitt> customer with enough sales volume to be taken seriously made the request, so someone forked the bsp, hacked it to work, and shipped it

08:35 <chewitt> but as they want to minimise support, it's not made available to all

08:35 <f_> Apparently there are some gxl leftovers in Amlogic's Android 10 BSP yeah

08:36 <f_> "minimise support" yeah that could explain why not everyone got the upgrade

08:37 <f_> and rn either upgrading to A10 or staying on old A9 is a prerequisite to booting Mainline linux as far as we (I and a few pmOS contributors) know ;p

08:39 <f_> booting mainline u-boot on it is doable, it's just tedious

08:39 <f_> and means you'll need to bring a computer everytime you want to boot it up ATM

10:36 <tito-me-doe> Good morning. For me at least

10:39 <tito-me-doe> Yeah I have looked at a BSP kernel. Specifically the RK3566 E5 plus and E6 plus kernels, which are themselves modifications of the PowKiddy x55 BSP kernel

10:40 <tito-me-doe> I’m currently trying to isolate the differences so I can hopefully PR mainline for it, since the x55 now can boot mainline

10:56 <f_> tito-me-doe: Don't know about RK, but the Amlogic BSP kernels' coding style is .. incredible ;p

10:56 <chewitt> i've seen ones from Realtek that make Amlogic's ones look masterful

10:57 <chewitt> RK aren't so bad in terms of code quality

10:58 <chewitt> but their recent chips shipped without a whole heap 'o drivers

10:58 <tito-me-doe> Fun

10:58 <tito-me-doe> But I can’t say I’ve never made any mistakes

10:58 <chewitt> hence why RK3588 is only just reaching the point where we can look at it, three years after shipment

10:59 <chewitt> everyone leaves the fun stuff (media codecs) till last

11:01 <tito-me-doe> I mean, I once accidentally upgraded a production server from a two server 10.04 14.04

11:01 <tito-me-doe> From Ubuntu 10 to 14 I mean

11:10 <tito-me-doe> My only defense was I was using a terminal and thought I was on my own machine

21:38 <tito-me-doe> Oh cmon now, it was over 10 years ago, it can’t be so bad that everyone gets quiet

21:42 <f_> lol

21:42 <f_> tito-me-doe: it's night time in UTC world

21:43 <f_> chewitt is probably Zzz right now

22:23 <tito-me-doe> Oh I sent the first message at 7am, then the next at 5pm

22:23 <tito-me-doe> Das a long Zzz