<chewitt> 5.11.10 is okay tho
<chewitt> I mostly use ethernet everywhere so I've not noticed when it occurred
<chewitt> I didn't work up the enthusiasm to bisect it yet
<chewitt> btw, I'm currently seeing a major regression with SDIO wifi on 5.12-rc8
<chewitt> but everything proposed has been merged
<chewitt> there's a couple of threads on kernel and u-boot lists
<chewitt> ahh, ok
<chewitt> ???
<Tony_mac32> chewitt meson64 got turned into a spaghetti mess with the sudden intro of a few extra boards and patchsets that overlap.
<chewitt> yes, those things are merged some time ago - in slightly different form, but done
<chewitt> hmm
<chewitt> any old patches/rumours/remedies?
<chewitt> (but have them connected before boot and they work)
<chewitt> are there known issues with Odroid C2 and USB devices being recognised after boot?
<chewitt> morning campers :)


<chewitt> so it's the current image I'm running in a few placess
<chewitt> I pushed changes to bump to 5.12rc6 to that branch
<chewitt> @IgorPec I used a heavily lightened defconfig .. more built-in and specific to LE/Amlogic needs (no support for other SoCs)
<chewitt> the other usual variable is defconfig
<chewitt> I'm permanently on some RC from Neil's custodian branches, but again, no fancy patches
<chewitt> *but* all my devices are using a recent u-boot, nothing vendor
<chewitt> I have most devices on emmc storage (wherever I can, it's faster) but I have an older GXBB box on SD card too, so I don't think medium is related
<chewitt> for the sake of testing .. what happens if you build from my 5.12 branch?
<chewitt> but I had reports it caused issues and I dropped it
<chewitt> I don't see any hangs .. and that commit fixes the reboot issues I've had with all devices since .. ages


<chewitt> "32-bit SoCs (Meson8b / S805 or older)"
<chewitt> Meson 8 uses different load addresses to S905 and up
<chewitt> and there is zero u-boot support for Meson-8 hardware, so you're at the mercies of the vendor bootloader which is hideous
<chewitt> there is no nicely written up howto, and your box almost certainly doesn't have a device-tree in Martin's source so you'd need to make one
<chewitt> but it's one of those "if you need to ask for help, best give up now" situations
<chewitt> hieppo there is an experimental kernel for meson-8 hardware, see https://github.com/xdarklight/linux/tree/meson-mx-integration-5.11-20210124


<IgorPec> thanks chewitt. adding them
<chewitt> feel free to raid https://github.com/chewitt/linux/commits/amlogic-5.12.y for anything that mentions lima/panfrost
<chewitt> also btw, lots of panfrost related kernel things didn't make 5.12 so out-of-tree patching is still needed
<chewitt> fixes problem reboots on all the Amlogic boards I have
<chewitt> I think I ran out of device-tree things to upstream for Khadas :)
<chewitt> If using "mainline" kerne/u-boot Odroid C4/N2 and VIM3L/VIM3 are basically identical to support, only the FIP sources are different
<chewitt> I guess depends on kernel source
<chewitt> If you'd ever like samples to aid non-Oleg support in Armbian, let me know..
<chewitt> It's handy to have S905X, S912, S905X3 and S922X/A311D in the same format (same PSU) etc.
<chewitt> I use them a lot for testing
<IgorPec> chewitt: no special reason. we don't have them much around
<chewitt> I'm aware of a couple of other A311D boards, but all aimed at pro/industrial use, nothing consumer oriented
<chewitt> I thought Oleg abandoned support for Khadas devices due to their use of CoreELEC and his issues with their team members
<chewitt> I spotted some user Q's asking for Armbian on VIM3 boards in their forum
<chewitt> @IgorPec is there any reason why none of the Khadas boards are in the Armbian list?


<chewitt> archetech what did I do now?
<archetech> chewitt_: "raided my patch set" lol


<chewitt> man, can't type today.. brain is meh
<chewitt> np
<chewitt> and you won't catch with within 500 yards of a Realtek chip
<chewitt> definitely no wifi going on with an HC4 .. HK doesn't believe in adding chips to their boards
<chewitt> odd .. maybe something freaky with ix.io
<[TheBug]> chewitt: this is what the top of the doc that loaded for me looked like: https://prnt.sc/xrnae5
<chewitt> the HDMI panel connected doesn't support CEC and Kodi attempts to find devices .. so that's normal
<chewitt> :)
<[TheBug]> chewitt: I would have to screen shot this for you to believe me, but I loaded that before and it loaded a complete different output than when I just loaded it again now
<chewitt> s/think/thing
<ArmbianHelper> chewitt meant to say: not in the thing I pasted
<chewitt> not in the think I pasted
<chewitt> no wlan there
<chewitt> Odroid-HC4 is a board, not a WiFi chip
<chewitt> I'm (easily) confused
<chewitt> ignore, I though you were talking to me :)
<[TheBug]> chewitt: ??
<chewitt> there's no wifi on the HC4
<[TheBug]> chewitt I would almost see if Hardkernel have their own git for drivers, may have a bettrer version
<chewitt> HC4 on 5.11-rc5 :) http://ix.io/2NzJ


<chewitt> same way you'd compile anyone else's kernel I guess
<archetech> chewitt, how do you compile your kernel ?
<chewitt> feel free to send supportive comments to the mailing list
<chewitt> and mostly everything I touch with audio is treated as a mistake :)
<chewitt> like all children, I learn by making mistakes
<chewitt> not sure how well that will be received
<chewitt> ^ learned that in the proces
<Tony_mac32> chewitt I saw some patches in the pipeline, cool
<chewitt> current changes in my alsa-lib repo seem to work well with G12 devices
<chewitt> @Tony_mac32 btw, I have been fiddling with alsa confs recently trying to get audio coming out of the right speakers
<chewitt> so true
<chewitt> dmesg http://ix.io/2KGa


<chewitt> I need to find out if they M5 has the same USB silliness of the C4 or they did something different
<chewitt> it's basically a clone of the C4 dts, except for an extra LED
<chewitt> IgorPec I added an initial dts in my 5.10.y kernel branch, which seems to work
<IgorPec> chewitt: thanks. so far those bananas didn't find its way here, but yeah, we might add it
<chewitt> otherwise the u-boot sources have lots of s/odroid/bananapi going on :)
<chewitt> FIPs are different, prob. due to different memory specs
<chewitt> it boots using the C4 u-boot config .. but will need some extra bits adding in device-tree
<chewitt> IgorPec if people ask for bananapi-m5 support, I put working FIPs here https://github.com/LibreELEC/amlogic-boot-fip


<chewitt> whether all.. not sure yet
<chewitt> but I know a bunch of them were merged
<chewitt> I didn't check 5.11 yet, will wait for the first rc
<chewitt> I'm still carrying a bunch of patches that are needed, they were missed for 5.10
<archetech> I heard 10.0 kern has latest pfrost drm true chewitt?
<chewitt> "we the undead, keyboard zombies, creators of distros"
<chewitt> nope, firmly deceased


<stipa> chewitt: i don't know how to phrase it, it seems like everyone is breaking all connections with the UK because of the advanced virus
<chewitt> anyway, what was the UK question?
<chewitt> probably.. the UK gov is piss weak about controlling anything (which is the entire reason things are bad)
<stipa> chewitt: are you even allowed to come back?
<chewitt> (very happy to be not in the UK right now)
<chewitt> stipa: from the UK = yes, in the UK = no
<lanefu> Tonymac32: dont have console cable connected. I bult chewitts kernel via builder and eliminated meson64-dev patches
<lanefu> alright rolling the dice with chewitts kernel
<lanefu> chewitt: oooh that's super promising
<chewitt> in case you wondered why Samsung staff are contributing to Amlogic u-boot/kernel things, that's why..
<chewitt> and the Tizen folks are also using them as reference hardware now
<archetech> chewitt: yes I said that here earlier to rneese
<chewitt> the AOSP "reference" status for VIM3/L will see a lot of adoption on them
<chewitt> I'm expecting N2/C4/VIM3/VIM3L to become very stable over the next few months
<archetech> between tobetter and chewitt they have a great N2 image over there
<archetech> and it dont matter chewitt dont use X he has the goods for it anyhow ;)
<chewitt> far too many people use my branch as their upstream .. despite it being unstable and continuously rebased :)
<chewitt> if you do find anything missing in my branch, please ping me
<chewitt> I'm hoping that all the drm stuff went upstream for 5.11
<chewitt> s/of/or
<chewitt> but I still pick all the drm/panfrost changes whenever I see anything posted to the list of discussed in #panfrost
<chewitt> nope, never
<lanefu> chewitt: yah but you dont use X11 right
<chewitt> all the DRM patches are in my 5.10.y branch


<chewitt> If I had to pay for them I'd be using the 2GB version
<chewitt> I'm only running kodi .. but I get samples whenever they bump revs and such for testing
<pakcjo> chewitt: what are you using the pi4(8gb) for?
<chewitt> Mem: 7722 270 7092 81 359 7149
<chewitt> total used free shared buff/cache available
<chewitt> RPi4:~ # free -m
<chewitt> pakcjo RPi4?


<q4a> Thanks to booth. chewitt - I'll use single idea - how to get `ycbcr_420_allowed`
<chewitt> q4a that branch looks like it's based on drm-tip tho, which might not be the best
<q4a> chewitt Thanks!
<chewitt> ^ knaerzche is our other RK dev, a little more active than Jonas in recent times (Jonas has a lot going on right now)
<chewitt> he won't answer quickly, but I'll drop him a note in team chat (Slack) to let him know there's Qs
<chewitt> ping @kwiboo in #linux-rockchip or #libreelec .. I don't track what we do with RK things (large SEP field around it)
<IgorPec> then lets ask chewitt_ if he have some hints


<chewitt> I've never seen the issue flagged in that series tho ..


<chewitt> Tony_mac32 this might be useful for Armbian .. needs testing (looking for testers to confirm)


<c0rnelius> chewitt: It worked! or so I'm told. As always, thank you very much.
<c0rnelius> chewitt: will do, sir
<chewitt> c0rnelius let me know if it works .. I never use those files directly, I just cache them in the LE image build process and sync them with images
<chewitt> mine are not 'latest' but fairly recent
<chewitt> if you rebuild them from current HK sources (or use mine) both n2/n2+ can share the same fips
<chewitt> if you're using the original n2 fips, they won't boot the n2+
<chewitt> n2/n2+ definitely are
<chewitt> iirc
<chewitt> the n2, n2+ and c4 fips in my repo should be the same files
<chewitt> which might explain differences
<chewitt> it's possible my bl301 is newer than his
<chewitt> mine is a superset of his plus some I acquired
<chewitt> github.com/LibreELEC/amlogic-boot-fip <= all my own work :)
<chewitt> 9.2 I think
<chewitt> more importantly.. does it work?
<chewitt> different compiler options? .. different gcc?
<c0rnelius> chewitt: is there some kind of magic I'm missing when building mainline uboot for the N2+? my uboot bin is .4 smaller than urs.
<chewitt> but I think this will not be useful on desktop distros due to packaging differences
<chewitt> in the images there
<chewitt> I only build uImage kernels with embedded init (for LE)
<chewitt> much easier
<chewitt> I do numbers, not names
<chewitt> ahh, more clever codenames
<chewitt> for a start, I have no real clue what bullseye is :)
<chewitt> Any illusion you're under that i'm a developer is testament to how well the LE build-system works, not my l33t sk1llz
<chewitt> I'm a bit of a n00b when it comes to compiling anything except LibreELEC
<chewitt> archetech for the sake of asking .. what is it that you'd want built?
<archetech> chewitt: you able/willing to pkg a kernel for acrh user (me)


<chewitt> master is normally tracking torvalds/master
<chewitt> I didn't boot 5.10.y more than twice, I am still trying to resolve issues in 5.9.y .. the wip branch is the one I linked (amlogic)
<archetech> chewitt: clone master or amlogic-5.10.y for N2?
<chewitt> as tracking each device manually is make-work
<chewitt> or something along those lines
<chewitt> at some point, I hope someone figures out how to read the A vs B from "dtc" and then set it correctly (dynamically)
<chewitt> so in the LE soundconfig script, I use $(dtname) to set the mixer settings appropriately
<Tonymac32> chewitt yeah, we have a bit of a spiderweb set up in the scripts right now, a single board's config is found spread throughout 5-6 files
<chewitt> eventually I will put them in the same file and detect the called filename to give different output
<chewitt> and I use $(dtname) in some of the userspace setup needed
<chewitt> in LE, some time ago I added some helper scripts like https://github.com/LibreELEC/LibreELEC.tv/blob/master/packages/sysutils/busybox/scripts/dtname
<chewitt> but the upshot is, G12 has a deliberately flexible routing topology, so it can be either, but one is more correct than the other
<chewitt> I'm still not understanding how you should/can tell whether it should be A or B :(
<chewitt> if A, should be B, if B, should be A
<chewitt> each time I submit something jbrunet tells me I did it wrong.. and I should be using A or B
<archetech> chewitt: is that due to c4 vs n2 ya think?
<archetech> chewitt: I resemble that remark ;p but I do test and source build all the stuff that flows out to git
<chewitt> the fix I saw for audio on G12 is incomplete as some devices have audio on TDMOUT_A and others TDMOUT_B .. which needs mixer differences
<chewitt> amlogic seems to attract self-entitled users and lots of idiots
<chewitt> due to the lack of people working on it
<chewitt> it's fun apart from Amlogic, which is just a f**king chore
<chewitt> dev is bending the truth a little tho, I do packaging not code (IMHO)
<chewitt> yes, I work on LE mostly
<chewitt> inch by inch, the difference is reduced, which we have to call progresss
<chewitt> then at the next kernel iteration after the change is merged, tobetter will rebase hacks on upstream
<chewitt> and I will send upstream
<chewitt> then myself with help from narmstrong will redo it properly
<chewitt> often tobetter will do the first pass of the new device dts
<chewitt> partial
<chewitt> neither
<archetech> chewitt: ? here does tobetter pull from you on kernels for odroid ubu mainline builds?
<archetech> chewitt: you got a patched N2 kernel we can pop into a armbian N2 build?
<archetech> but chewitts got a patched kernel I think but using that flysin the face of the armbian way
<lanefu> anyway as far as our paradigm i'd probably use the legacy kernel to tinker, but yeah maybe we can diff some stuff or look at chewitt's patches
<archetech> chewitt can point ya to the patches easy enough
<chewitt> I have no relationship with odroid .. other than they send me samples when I ask for them
<archetech> chewitt or tobetter are odroid afaic
<archetech> chewitt or tobetter


<chewitt> I feel unclean just looking at it
<chewitt> typical wanky vendor approach
<chewitt> as usual, someone else needs to adapt it properly now
<IgorPec> chewitt: didn't made any reseach. i just pulled their work into our tree
<chewitt> instead of fixing it in the core drivers, a hack fix is done for Odroid only]
<chewitt> ahh, the out of tree garbage
<chewitt> IgorPec what was the solution to C4 reboot?
<chewitt> but that's just another layer of incomprehensible alsa stuff for me
<chewitt> there is probably a better way to do this via the new alsa topology stuff
<chewitt> so that device-specific mixer config can be set
<chewitt> in LE there is a helper script called 'dtname' which returns the device-tree compatible for the board, which I use as input for case/esac
<chewitt> some devices are on TDMOUT A, and some TDMOUT B
<chewitt> which is very (very) wip
<chewitt> rneese the soundconfig is not as simple as your script, sadly
<chewitt> saving the mixer config state?
<chewitt> what's the "asound.state.meson64" ?


<chewitt> nekomancer[m] it's merged into Kevin's tree which will sent upstream in the merge window for Linux 5.11


<nekomancer[m]> chewitt: Hi. now I see this http://lists.infradead.org/pipermail/linux-amlogic/2020-November/008863.html. Then, where it is?


<c0rnelius> I must be missing something in the mainline front then. Looking at chewitts uboot bin its 0.3 bigger than the one I generate.
<chewitt> I suspect it will fault like crazy due to the audio issue, but.. I'll get to that eventually
<chewitt> burn to SD card etc.
<chewitt> can't guarantee how usable it will be, but it should boot https://chewitt.libreelec.tv/testing/9.80/LibreELEC-AMLGX.arm-9.80.7-odroid-c2.img.gz
<chewitt> ^ Apple keyboard is fcuked, lots of typos
<chewitt> ss/fun/fund
<chewitt> and my work workload is high, and LE doesn't fun my vacations or porsche habit :)
<chewitt> there is currently an audio regression to track down, which is why LE master hasn't been updated in a while
<chewitt> but I have what runs, running on 5.9.2
<chewitt> LE 10.0 is debatable because progress on vdec/audio has stalled badly for multiple reasons
<chewitt> LE 9.2 was skipped because we'd had enough for 3.14 and mainline wasn't really ready
<chewitt> LE 9.0 was the last release we did for Amlogic which used 3.14
<chewitt> LE10 (next release) is still rather "work in progress" for RPi hardware, but we dropped OMX and MMAL .. will use GBM/V4L2 going forwards
<chewitt> Raspberry Pi will likely drive some of it
<chewitt> GBM/V4L2 things need to evolve a little further
<chewitt> but at some point we might combine them
<chewitt> for maintenance and support reasons we'll probably keep them separate
<chewitt> it's already possible for LE to build an "ARM" image that boots any supported Allwinner, Rockchip, NXP, Amlogic device (one image, lots of u-boot blobs)
<chewitt> the rest have a lot in common
<chewitt> sadly there's still too much interest in the vendor kernel, which is ugly crap code but more functional
<chewitt> Amlogic SoCs need the v4l2 statefull api to firm up, and lots more work to be done on the vdec and audio capabilities, they are a bit rough
<chewitt> buZz whatever works for you (for Kodi) works for us
<chewitt> so the maintainer prefers to drop support and focus on other devices where progress is more worthwhile
<chewitt> i.e. needs a large amount of work, needing a larger than normal amount of reverse engineering
<chewitt> A20 users seem to turn up with particularly low spec boards, and the SoC reached the point where we realised it's quite different
<chewitt> still going strong
<chewitt> correct
<chewitt> LibreELEC
<buZz> chewitt: whats LE
<chewitt> it's "different" to most of the other Allwinner SoCs, and doesn't inherit much code
<chewitt> in LE
<chewitt> A20 support has been dropped
<chewitt> so the wheel is being slowly reinvented in places as that happens
<chewitt> and there are ongoing efforts to make 'Hantro' IP using devices share common code
<chewitt> not all SoC are equal for codec(s) etc.
<chewitt> Allwinner, Rockchip
<thebigfrog> chewitt: ok, for which platforms is that? and what will it enable?
<chewitt> the kernel v4l2 stateless request api is now 'done' afaik, which means we can start upstreaming ffmpeg drmprime bits (which are refused until the api's are set)
<chewitt> i'm afk-ish, on a work call
<chewitt> the Allwinner and RK stuff we support is stateless for vpu and both run lima/panfrost
<chewitt> yes, lima should be fine
<chewitt> and bifrost blobs since .. a month or so ago
<chewitt> and I haven't used mali midgard blobs since late summer 2019
<chewitt> and I haven't used mali utgard blobs since early 2019
<chewitt> I haven't booted an Amlogic bsp kernel since 2018
<chewitt> nope
<chewitt> (me wears two hats, one LE, one Kodi)
<chewitt> app = Kodi
<chewitt> in fact I think we were one of the first apps to ever run it :)
<chewitt> LE uses mesa/lima for some time btw, it's working nicely
<chewitt> because. monolithic.
<chewitt> vendor kernel merges them all into a single file
<chewitt> mainline vdec ultimately uses the same firmware(s) as vendor kernel, only they've been extracted into multiple files
<thebigfrog> chewitt: thanks, the u-boot blobs I saw in the armbian repo and vpu I assumed because libreelec is using a legacy kernel
<chewitt> the vdec also has blobs
<chewitt> if using mesa/lima you avoid one of them
<chewitt> I have no knowledge of where Armbian keeps stuff, but c2 has blobs for u-boot signing and if using the ARM mali GPU driver


<c0rnelius> Chewitts uboot bin is also under files/boot if the builders is broke.


<nekomancer[m]> chewitt: wtd or wdt? mistype or not?
<chewitt> I don't work on Armbian so I'd finger-point t someone like @Tonymac32 to pick it
<chewitt> if the patch is acked by the maintainers .. I'm sure it can/will be picked