<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 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?
2021-02-07
<chewitt>
archetech what did I do now?
<archetech>
chewitt_: "raided my patch set" lol
2021-01-28
<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
<ArmbianHelper>
chewitt meant to say: not in the thing I pasted
<chewitt>
s/think/thing
<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>
Tony_mac32 this might be useful for Armbian .. needs testing (looking for testers to confirm)
2020-11-11
<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
<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
2020-11-08
<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>
^ 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
2020-11-01
<c0rnelius>
Chewitts uboot bin is also under files/boot if the builders is broke.
2020-10-31
<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