narmstrong changed the topic of #linux-amlogic to: Amlogic mainline kernel development discussion - our wiki http://linux-meson.com/ - ml linux-amlogic@lists.infradead.org - official channel moved from Freenode - publicly logged on https://libera.irclog.whitequark.org/linux-amlogic
kilobyte_ch has quit [Ping timeout: 268 seconds]
kilobyte_ch has joined #linux-amlogic
Terry137322934 has joined #linux-amlogic
jacobk has quit [Ping timeout: 250 seconds]
jacobk has joined #linux-amlogic
jacobk has quit [Ping timeout: 250 seconds]
jernej has joined #linux-amlogic
vagrantc has quit [Quit: leaving]
<HackerKkillinghi> is this patch good?
elastic_dog has quit [Ping timeout: 240 seconds]
elastic_dog has joined #linux-amlogic
f_ has joined #linux-amlogic
warpme has quit [Quit: Connection closed for inactivity]
warpme has joined #linux-amlogic
JohnnyonFlame has quit [Ping timeout: 240 seconds]
Daanct12 has quit [Quit: Quitting]
anessen97 has quit [Ping timeout: 276 seconds]
anessen97 has joined #linux-amlogic
jacobk has joined #linux-amlogic
JohnnyonFlame has joined #linux-amlogic
jacobk has quit [Ping timeout: 260 seconds]
jacobk has joined #linux-amlogic
jacobk has quit [Ping timeout: 260 seconds]
chewitt has joined #linux-amlogic
<chewitt> HackerKkillinghi the patch needs to be rebased on the current u-boot-amlogic custodians branch
<f_> Hi chewitt!
<chewitt> the index.rst content is wrong
<f_> It has been a very long time since you last connected!
<f_> Glad to see you here!
<chewitt> the patches I sent to cleanup documentation are merged, so the format changed a little
<f_> brb
<chewitt> I cleaned up my own GT1 patches here: https://github.com/chewitt/u-boot/commits/amlogic-next-chewitt
<chewitt> you also need to provide patch descriptions; you can't just have the same content for all three patches
<chewitt> f_ I forget IRC exists
<chewitt> or if it's easier I can just submit my patches .. you've beaten me to it by ~24h
<HackerKkillinghi> <chewitt> "Hacker ΞЖKƆ killing his LGA..." <- yeah i know that
<chewitt> ???
<HackerKkillinghi> <chewitt> "you also need to provide patch..." <- Ah i have to learn how mail list work
<HackerKkillinghi> chewitt: yeah i know it needs to be rebased on the current u-boot-amlogic custodians branch
<HackerKkillinghi> <chewitt> "f_ I forget IRC exists" <- LOL
<chewitt> each patch needs title that follows the format for that patch type .. use git log to see previous submissions for amlogic boards
<HackerKkillinghi> i use martix in this irc room
<chewitt> each patch should have a description of the changes in the patch
<HackerKkillinghi> chewitt: ok
<chewitt> just a factual description; opinions and other supporting info are underneath the --- or in a seperate cover letter
<HackerKkillinghi> i dont know should i upstream my x96 mini
<HackerKkillinghi> u-boot
<chewitt> submit the dts to the kernel first
<HackerKkillinghi> yeah
<chewitt> then the u-boot patches can include the merged dts
<HackerKkillinghi> but that uboot is using the fip that from another device
<HackerKkillinghi> to the build the image
<chewitt> kernel submission is simple .. but .. most users (me included) make 'etiquette' mistakes; patches in wrong format etc.
<HackerKkillinghi> chewitt: i will try
<HackerKkillinghi> HackerKkillinghi: Not sure is that kind of thing is allowed or not
<HackerKkillinghi> on upstearm uboot
<chewitt> if you push the patches (with titles/descriptions) to a public git repo and ping me first; I'll be happy to spot mistakes and explain them
<HackerKkillinghi> Ah
<chewitt> it's normally all simple stuff, but either you conform to kernel standards, or your patch doesn't get merged :)
<HackerKkillinghi> ok
<chewitt> I'm not an expert.. but I made most of the mistakes and have learned
<f_> chewitt: Did you take a look at the chat logs while you weren't there?
<HackerKkillinghi> Oh
<HackerKkillinghi> yeah
<HackerKkillinghi> i also made a lof of mistake in pm os
<chewitt> re u-boot .. the signing recipe and FIPs used have nothing to do with U-Boot support
<HackerKkillinghi> ok
<f_> chewitt: If you want I can give you a synopsis.
<chewitt> see WeTeK Core2 in U-Boot .. It uses the Khadas VIM2 FIP sources
<HackerKkillinghi> chewitt: nice
<HackerKkillinghi> then my worries has gone
<chewitt> It happens to use the same RAM chips as VIM2 so the acs.bin (which contains RAM timing data) works
<HackerKkillinghi> OH
<HackerKkillinghi> is acs.bin inside the fip
<chewitt> one of the things I'd like to add to the FIP repo is some info on the RAM chips on the boards
<HackerKkillinghi> which? repo
<chewitt> as a general rule the FIPs are board specific and don't work on others, but there are occasional exceptions
<chewitt> github.com/LibreELEC/amlogic-boot-fip
<chewitt> ^ this is used with LE and Armbian, and likely other distros too, as it's simple to consume content from
<HackerKkillinghi> chewitt: ^it is also used by pm os
<f_> s/pm os/postmarketOS/ :)
<f_> chewitt: Little synopsis of what happened while you forgot IRC existed:
<f_> * My postmarketOS KII Pro port got merged
<f_> * The IR receiver there works
<HackerKkillinghi> f_: Ah btw
<f_> * I started documenting the DVB hardware combo
<HackerKkillinghi> HackerKkillinghi: most of amglic based device in pmos are ported by me
<HackerKkillinghi> i think
<f_> Why are you pinging yourself?
<f_> Well, rather.
elastic_1 has joined #linux-amlogic
elastic_dog is now known as Guest9423
Guest9423 has quit [Killed (platinum.libera.chat (Nickname regained by services))]
<f_> Why is Appservice-IRC trying to make you look dumb?
<f_> (Jokes aside..)
<chewitt> https://github.com/chewitt/linux/commits/dvb-sucks <= some drivers hacked/fixed-up to compile under Linux 6.1
<f_> Yeah I linked to that too.
<HackerKkillinghi> chewitt: well it work
<HackerKkillinghi> fot u f_
<chewitt> but DVB is a lost cause without some writing a demux driver
<chewitt> s/some/someone
<HackerKkillinghi> chewitt: i think peopel from linux tv might able to help with this
<chewitt> feel free to speak to them, but I rather doubt you'll get any help
<HackerKkillinghi> chewitt: yeah
<chewitt> the code quality in most of the drivers is low
<f_> I don't think LinuxTV's interested on getting an obscure demodulator to work either.
<f_> s/demodulator/tuner/ my bad..
<f_> My STB uses the R912 tuner. I didn't find much documentation about it..
<chewitt> the availink folks are partially interested in their newer chips .. but not/less interested in the older ones
<HackerKkillinghi> my x96 mini use SP6330 wifi chip . the driver for is bad
<f_> Availink is in a better position right now than RafaelMicro.
<HackerKkillinghi> HackerKkillinghi: *fot it is
<chewitt> most of the tuner drivers have license/provenance issues
<f_> Hmm...
<HackerKkillinghi> i have tunner card that should work on linux
<chewitt> esp. the ones that claim to be GPLv2 .. because there's no license in the original code and someone just slapped GPL text on them
<HackerKkillinghi> HackerKkillinghi: (i know linux has for them)
<HackerKkillinghi> *drivers
<f_> I think that's the case for the file I just linked..
<f_> 8: // Author: Ryan Chang
<chewitt> even if you get the tuner and demod drivers to work .. there is no demux to combine the audio/video data output from them into something that can be played
<f_> 5612: MODULE_AUTHOR("Luis Alves <ljalvs@gmail.com>");
<chewitt> luis is the author of a lot of drivers
<f_> Yeah, but the file itself comes from who?
<f_> Is Luis the author, or is Ryan the author?
<HackerKkillinghi> chewitt: maybe there are some hardware hack to make it can be playbe
<f_> Or did Luis just slap that?
<chewitt> the hardware hack is .. write an upstream version of the Amlogic demux driver
<chewitt> the tertiary challenge is that all the drivers are hacked to work with a single board
<chewitt> with all the bits compiled into a single monolithic driver
<f_> Do you have a copy of the Amlogic demux driver downstream?
<chewitt> and this is not how the upstream kernel does things
<HackerKkillinghi> chewitt: no that is software hack
<HackerKkillinghi> the hardware hack is converter the output to hdmi and use a hdmi cupture
<HackerKkillinghi> care
<HackerKkillinghi> *card
<f_> HackerKkillinghi: That won't work...
<f_> DVB doesn't work like that. (IIRC)
<chewitt> the vendor driver is in all the usual vendor source locations .. but that doesn't get you anywhere
<HackerKkillinghi> f_: oh
<f_> chewitt: Is it obfuscated?
<chewitt> well.. depends on how nice you are in describing the quality of Amlogic authored code
<f_> Show it to me.
<HackerKkillinghi> that has the card
<HackerKkillinghi> chewitt: unless work in the company who made the device
<HackerKkillinghi> *you work
<chewitt> the start of the problem is .. Amlogic were supporting 4K/HDR in ye olde 3.10 kernel days
<f_> HackerKkillinghi: That isn't what I'm looking for.
<chewitt> this is long before the upstream kernel had UAPI and a solid DRM framework
<chewitt> so they authored their own DRM framework and video drivers
<chewitt> and the 3.10 stuff was forward-ported to 3.14, and then 4.9, and now 5.4
<HackerKkillinghi> f_: that is kernel from amazon which modded the kernel feom amlogic
<HackerKkillinghi> chewitt: Holy
<chewitt> over time the code evolved, and it all works (mostly) .. but it's so far removed from upstream frameworks
<chewitt> so you can't take the driver and clean it up or port it
<chewitt> you need to rewrite it from scratch
<f_> Yeah sure.
<HackerKkillinghi> chewitt: yeah
<f_> What we can do though....
<f_> Take a look at the driver, write how it works, and reimplement it in a cleaner way?
<chewitt> the other challenge with some of the Amlogic drivers is they are like a swiss army knife .. supporting every possible silicon feature
<f_> XD
<chewitt> instead of the 20% that you need and care about
<HackerKkillinghi> f_: use the old driver
<f_> HackerKkillinghi: No.
<HackerKkillinghi> HackerKkillinghi: for reverse engineering
<f_> As chewitt said, we can't do that.
<f_> We can't put it in the kernel directly.
<f_> Oh wait what?
<f_> Didn't fully understand?
<HackerKkillinghi> HackerKkillinghi: and make new a new one
* f_ (?)
<HackerKkillinghi> f_: i mean use the old driver for learning how the hardware work
<HackerKkillinghi> and make a new driver for it
<chewitt> it sounds so simple .. good luck with that
<HackerKkillinghi> i guess it is easier then reverse engineering a chip that dont have any doc and make a driver for it
<chewitt> marginally
<chewitt> then when you finally get it done, you'll see that the hardware decoding drivers are in sucky condition too
<chewitt> rinse/repeat
<chewitt> so as much as I'd love the DVB stuff to work .. it's way down my priority list
<HackerKkillinghi> maybe porting the drive to mainline by replacing thing that made for amlogic frameworks with thing that made for miniline frameworks but doing that is basiclly mean you are rewrttie half of the driver
<chewitt> in the history of Amlogic 'community' development there has only ever been one developer who made progress with making stuff work
<chewitt> and he went out for a motor bike ride in 2020 (ish) and hasn't been heard of since .. or something like that
<f_> chewitt: Where?
<chewitt> (progress on the dvb drivers)
<chewitt> the developer was Hungarian, so I'd guess somewhere around there
<f_> I mean.
<f_> Where's his work?
<chewitt> look for commits from afl1 in the LE/CE sources
<f_> Which sources?
<chewitt> but this is all vendor kernel fixing .. most of which breaks as much as it fixes
<HackerKkillinghi> f_: Also where the work of the hdmi of meson 8
<chewitt> CE never supported Meson 8
<f_> Thanks!
<chewitt> and we abandoned it aeons ago
<chewitt> xdarklight has been rewriting Meson 8 support slowly .. there is early HDMI support in his github branches
<HackerKkillinghi> chewitt: i dont care
<HackerKkillinghi> chewitt: Thank
<HackerKkillinghi> I might take that
<f_> That one's from kszaq..
<HackerKkillinghi> HackerKkillinghi: and put it in pm os
<chewitt> the CE source is probably the most complete one for vendor DVB code
<f_> s/pm os/pmOS/
<chewitt> but (again) that will be fcuk all use to an upstream codebase
<chewitt> the vendor drivers are not portable to upstream
<HackerKkillinghi> chewitt: yeah but having that is good
<chewitt> you might be able to get things compiled (as I have done) but that's a long way from being usable
<HackerKkillinghi> Since we can lernal how it wotk from that
<chewitt> a. very. very. long. way.
<HackerKkillinghi> chewitt: Likr meson6
<chewitt> Meson 6 is dead
<HackerKkillinghi> It is almost unusable with msinlin
<HackerKkillinghi> *mainline
<chewitt> too old and too different for anyone to be interested in it
<chewitt> Meson 8 has 'a' developer (Martin)
<HackerKkillinghi> chewitt: well i have a the only meson6 device that upstreamed
<chewitt> anyway.. time for Zzz here
<HackerKkillinghi> the only way to boot a os with mainline on meson6 to netboot
<HackerKkillinghi> The emmc/nand dont work on nand
<HackerKkillinghi> *meson 6
jernej has quit [Ping timeout: 268 seconds]
<HackerKkillinghi> Ah
<HackerKkillinghi> Btw there are some amgic tv / digital whiteboard
<HackerKkillinghi> has a hdmi chip inside
<HackerKkillinghi> *mux chip
<HackerKkillinghi> according to the dts
<HackerKkillinghi> That extected from a digital whiteboard
<narmstrong> To easy posting patches to the mailing lists (Linux and uboot) the b4 tool was created: https://people.kernel.org/monsieuricon/sending-a-kernel-patch-with-b4-part-1
<narmstrong> It avoids all the format-patch/cover-letter/maintainers/send-mail manual steps et does it automatically in the expected way
<f_> narmstrong: Can't you just use `git send-email` for that?
<narmstrong> This is the final step, before you need to prepare & format the patchset with the correct text and To/Cc lists
<f_> What do you mean by 'prepare & format'?
<f_> IIRC just commiting, then running send-email's enough, right?
<f_> You can even add Cc's when running it.
<f_> But I never sent a patch to U-Boot/Linux so can't tell how it works...
<HackerKkillinghi> <f_> "But I never sent a patch to U-..." <- https://www.youtube.com/watch?v=LLBrBBImJt4
vagrantc has joined #linux-amlogic
f_ has quit [Quit: \o going offline.]
jacobk has joined #linux-amlogic
warpme has quit [Quit: Connection closed for inactivity]