2020-06-12

<[TheBug]> chewitt: I am currently compiling a list of people who are interested in participating in Armbian TV Box support discussions, if you have any interest in helping support or some idea on how that can be done, let me know and I am happy to invite you -- you can pm me your forum nick or your e-mail if you like
<chewitt> I work on whatever I get my hands on, or whenever the other person has half a clue and can follow instructions
<[TheBug]> chewitt: do you do work for any other TV boxes?
<chewitt> what chip is in the K3 pro?
<chewitt> ethernet will not be recognised on 5.6 or plain 5.7 kernel
<chewitt> you'll need to compile your own kernel from https://github.com/chewitt/linux/commits/amlogic
<chewitt> ahh.. that dtb is configured for rgmii-id ethernet so requires 5.7 + some 5.8 patches
<chewitt> k3 pro is an S912 device IIRC
<chewitt> that's also an image for 5.7 kernel although it will probably be fine on 5.6 too
<chewitt> I don't have the dtb only kicking around
<chewitt> would be interested to see tho
<chewitt> i've no idea what sei610-ethfix is
<chewitt> in my branch it's meson-sm1-a95xf3-air.dtb
<chewitt> no wifi and ethernet is forced to 100-BaseT or it doesn't work
<chewitt> ram_ no, but I have a mostly-working device-tree in my kernel branch

2020-05-21

<Tonymac32> maybe? but it looks like it needs some alsa configuration as well from the script chewitt linked yesterday

2020-05-20

<chewitt> nagging and persuading being important maintainer skills :)
<chewitt> i'm still figuring out who knows what, who does what, and how that translates into me nagging people to fix stuff
<chewitt> feedback welcomed, as XU4 is new and unexplored territory for me
<chewitt> ahh, okay :)
<IgorPec> chewitt: XU4 its a DEV branch for experimenting, so no worries if it gets deleted ;)
<chewitt> money is rather good
<chewitt> the original recordings are quadrophonic and there's a DTS version been kicking around for years
<chewitt> those are quite fun for testing
<chewitt> have you got the DTS versions of DSOTM?
<chewitt> never a bad thing :)
<chewitt> plntyk was pointing some things out to me the other day in #linux-amlogic
<chewitt> I have been trying (and not succeeding) to understand this for a while
<chewitt> i.e. the confs might be right for a pass-thru device
<chewitt> it may be the case that my alsa confs are wrong as these include the hdmi/iec958 devices for hdmi/spdif
<chewitt> beyond this point my knowledge gets fuzzy
<chewitt> as I understand it the current drivers implement PCM only, no pass-thru
<chewitt> most of the time the base commit can be bumped 3-4 times before some fix infiltrates upstream and forces a rebase of the patches
<chewitt> it means the build-system has a ton of patches, but it's more resilient
<chewitt> the approach I'm taking with LE is to always work from an upstream commit (e.g. 5.7-rc6) and then create a patch-set (via git format-patch) that applies to that commit
<chewitt> the main thing to understand about that branch is .. it will be rebased, frequently
<chewitt> but git is still git, so in the grand scheme of things i'm still a n00b and will screw things up occasionally
<chewitt> over time my git habits have become more structured and less chaotic
<chewitt> I'll try harder not to mess up the branch or delete it :)
<chewitt> let me know if you do things like that
<chewitt> IgorPec I noticed you linked to my 5.7 xu4 branch
<chewitt> I have been trying to improve my incompetence with alsa by reading docs, but everything kind of assumes you understand the actual code, it's all rather inpentrable for an outsider
<chewitt> for now my branch reverts Jerome's change and I'll take time to figure it out properly
<chewitt> https://github.com/chewitt/alsa-lib/commits/amlogic seems to work on everything (except VIM3/3L)
<chewitt> everything else remains with TDMOUT_B and works using the configs and such that I was playing around with recently
<chewitt> I'm currently stuck on VIM3/VIM3L audio as Jerome moved things from TDMOUT_B to TDMOUT_A and I'm still trying to understand what that means :)
<chewitt> G12 bits are just above
<chewitt> have you got the matching userspace bits?
<chewitt> Tony_mac32 what are you stuck with?

2020-05-15

<Tenkawa> chewitt: I want to pass along a big thank you..
<chewitt> hence the need for the Amlogic partitioning scheme (MBR/GPT shifted away from 1st sector)
<chewitt> GXBB and older needs BL2 in first sector for eMMC, but can have it in 512 sector for SD
<chewitt> so you can use u-boot.bin.sd.bin for both SD/eMMC
<chewitt> the SoC checks for BL2 in the first sector and 512 sector on all GXL and newer devices
<Tony_mac32> cornelius chewitt I haven't looked that closely at the N2 yet other than building and flashing SD, it does have a different binary for SD vs eMMC, or at least a different flashing address, correct? like GX?
<c0rnelius> chewitt: hmm. I'll give it a go.
<chewitt> but LE (and that u-boot I linked) work fine from SD or eMMC modules
<chewitt> I'm not sure I ever successfully managed to coax petitboot into doing something useful
<chewitt> N2 has the switch on the front
<c0rnelius> chewitt: thats what I figured. I can get it booting from sd, but emmc keeps giving me trouble. I'll fiddle with it more, thanx.
<Tony_mac32> chewitt but we haven't moved to mainline yet on N2. My uboot is fine, I think it's boot script or missing patch related
<IgorPec> chewitt: yeah. u-boot is in terrible state and
<chewitt> c0rnelius: works fine with mainline
<chewitt> I need to fiddle with the ancient C1 u-boot so that I don't have to change our boot arrangements
<chewitt> I have one in-front of me :)
<chewitt> ISTR it worked for me tho
<chewitt> I did some across a tester the other week who was unable to boot the mainline LE image tho
<chewitt> I haven't had any issues booting C2 for ages, but most of my testing is done with an emmc module (as it's faster, and saves me running out of cards)
<Tony_mac32> @igorpec are we having fun yet? chewitt is this same behavior seen on 5.7? I haven't built 5.7 yet
<chewitt> ^ this is another piece of the puzzle
<chewitt> the card confs prob need some tweaking
<chewitt> seems to work
<chewitt> Tony_mac32 I was missing a change to Makefile.am https://github.com/chewitt/alsa-lib/commits/amlogic
<chewitt> the other approach will be patching device-trees to use common names, but I prefer to keep the linux patch-set to a minimum
<chewitt> we still need to map new devices to confs, but we don't end up with 20+ identical card confs in the filesystem
<chewitt> basically.. use a single card.conf and map the board-specific cards to the conf
<chewitt> this is not working yet, but according to someone who knows more alsa than me, should work
<chewitt> this requires a different alsa conf
<chewitt> the problem I was trying to solve is that each board/dts has a unique audio card name
<chewitt> ^ has audio working on everything, but the dtsi approach was shot-down by Jerome
<chewitt> if you're following my branch(es)
<chewitt> btw, I'm in the process of reworking the audio stuff .. I had various attempts a simplifying rejected so I need to retool/drop those changes
<chewitt> each recent kernel bump has culled ~50 patches from my branch
<chewitt> I guess it depends on what functionality is important to you, but for anything slightly media oriented there's a lot of changes going on so the patch-sets end up a little large
<chewitt> for Amlogic I'd aim at 5.7
<chewitt> so backporting to 5.4 might be a challenge
<chewitt> IIRC
<chewitt> IRIC
<chewitt> there are also dependencies on other things in the ASoC tree from morimoto
<chewitt> if you're looking at Jerome's branches in gitlab
<chewitt> some of the modules changed name over time
<chewitt> that's from 5.7 but it has all the audio module bits set
<chewitt> so the ChromeOS download is the way to go
<chewitt> IANAL, but even I can spot that the terms are somewhat in Googles favour and you indemnify them against *everything*
<chewitt> Google allows redistribution of the libs, but if you do this, it implies you accept their terms for distribution
<chewitt> inputstream.helper downloads a 3.1GB ChromeOS update package that we can extract the libs from
<chewitt> LE uses a 64/32 arrangement similar to ChromeOS/Android specifically so we can use the 32-bit libs
<chewitt> not sure it will work on Armbian tho, as the widevine libs are only available in 32-bit packaging for Linux/ARM
<chewitt> via inputstream.helper
<chewitt> this uses inputstream.adaptive, which will install the required widevine bits
<chewitt> the Sandmann79 add-on is the one that I use
<chewitt> ?
<chewitt> Amazon works well these days
<chewitt> Play1 is 8726MX, Play2 is GXBB
<chewitt> I guess GXBB needs a tweak/quirk or such somewhere
<chewitt> hrtimer things .. I have no clue about it but it appears to be harmless
<chewitt> it seems to trigger some warning splats on GXBB devices, but I don't see them on GXL/GXM
<c0rnelius> chewitt: thank you for that bit of info.
<chewitt> aka, I had a fair crack at the device-tree changes, then Neil pointed out the mistakes :)
<chewitt> I reworked the VIM2 thermal zones support so it applies to all boards
<chewitt> c0rnelius Linux 5.7 onwards should expose thermal things for LePotato (and all other GX devices)
<chewitt> not sure, probably not
<chewitt> timing is everything in some of these devices
<chewitt> I have a search filter on eBay in case one gets posted in a cupboard clearoutt
<chewitt> I haven't seen issues with rebooting C2 or VIM1 .. still need to find a K2 sometime
<chewitt> i'm not sure it fixes anything, but it otherwise appears to be harmless so I left it in my branch
<chewitt> btw, that SD card shutdown patch is not proven

2020-05-14

<lanefu> IgorPec: trying to thing of hte best way to pull chewitt's patches and test
<IgorPec> we talked with chewitt the other day and there might be some fixes ...

2020-05-11

<chewitt> there's a u-boot folder .. current files are 2020.04 + any current Amlogic patches floating around
<chewitt> secret stash of things that may or may not boot, if it's at all useful https://chewitt.libreelec.tv/testing/9.80/
<chewitt> onwards and upwards!
<chewitt> I don't recall any issues with 5.4 .. but that was some time ago :)
<chewitt> I have a couple of extra bits in mine I think, but probably not anything Armbian would be interested in
<chewitt> his repo is largely (originally) downstream from mine
<chewitt> yes, all the same
<Tonymac32> chewitt right, Neil added https://gitlab.com/superna9999/amlogic-boot-fip/-/tree/master/ to the build, equivalent?
<chewitt> it's mostly not an issue, but some hardware seems to get stuck and fail
<chewitt> but the same issue exists on all
<chewitt> ^ that hack was targeting something on an older GXBB device IIRC
<chewitt> all my testing has been done with mainline u-boot not the vendor one
<chewitt> ^ was needed for u-boot, but hasn't been investigated further yet
<chewitt> the second one is valid, but we didn't figure out the logic behind it needed to avoid magic values and send something upstream
<chewitt> the first one is experimental
<chewitt> much more fun to experiment with old broken stuff !
<chewitt> all the usual stuff I care about worked far too easily so it's very boring :)
<chewitt> I haven't had any issues, although also haven't done much with C4
<chewitt> ouch, how?
<chewitt> inc. C4 and the next board from LibreComputer (tartiflettte)
<chewitt> has all the fip goodness you could want :)

2020-05-06

<chewitt> top banana :)
<chewitt> before I go install an ancient Ubuntu VM to compile an equally ancient u-boot :)
<chewitt> can anyone share a compiled Odroid C1 u-boot.bin ?
<chewitt> ahh, /etc/network/interfaces
<chewitt> I pinged Oleg .. I'll let him figure it out
<chewitt> most odd
<chewitt> and I also tried ethaddr/eth_mac
<chewitt> I created /boot/armbianEnv.txt with the same, but this doesn’t work either
<chewitt> I added “mac=xx:xx:xx:xx:xx:xx” to /boot/uEnv.txt but this doesn’t seem to work
<chewitt> thanks
<chewitt> /boot has what looks like a greatest-hits collection of boot scripts and such, so no idea which is actually being used :)
<chewitt> no ArmbianEnv.txt file
<chewitt> how to fix on Armbian? .. LE has a background service that forces a consistent MAC based on CPU serials
<chewitt> device is using "U-Boot 2019.10-armbian"
<chewitt> but, I'm seeing a different MAC on each reboot
<chewitt> I need to put the device on a static IP address
<chewitt> I've used an image from @balbes150 as this is using the same overall kernel patch-set as my LE images
<chewitt> I'm setting up an Odroid N2 for someone to do some remote V4L2 ffmpeg work on
<chewitt> morning all

2020-05-01

<chewitt> ash94 see if you can boot with the SEI610 dtb, it seems to be very close to various sm1 'air' boxes

2020-04-30

<chewitt> whoever is responsible for realtek's open-source strategy needs taking into a dark alleyway and giving a swift kicking..
<chewitt> I refuse to add them
<chewitt> I also don't bundle mali kbase and wanky realtek drivers into the kernel
<chewitt> memeka has a bunch of i2c overlay commits in his branch that I didn't pick, it's not stuff the LE cares about
<chewitt> time to figure out what combination of juju is needed for hw accelerated playback
<chewitt> had to abandon the idea of using panfrost tho .. but blob seems to work fine
<chewitt> IgorPec: after picking some patches from memeka's 5.4 branch I have XU4 running stable on 5.7-rc3 now

2020-04-28

<chewitt> he's moonlighting.. should be working on HEVC support !
<chewitt> ahh, explains what he was up to yesterday
<chewitt> mainline u-boot avoids the funky colours seen with bsp u-boot
<chewitt> both tested and working
<chewitt> IgorPec: C4 support is already on the amlogic mailing list, and I have u-boot support in my u-boot repo if you need it
<chewitt> booting from sd
<chewitt> sd
<chewitt> [ 34.210199] mmc_host mmc0: Bus speed (slot 0) = 50000000Hz (slot req 400000Hz, actual 396825HZ div = 63)
<chewitt> also, I have a ton of this in dmesg .. any ideas on how to silence?
<chewitt> can you point me to the script that Armbian uses for copying images to emmc?
<chewitt> I noticed most of the gaming distro's do that
<chewitt> Kodi isn't the most demanding workload and mainline u-boot doesn't overclock the board
<chewitt> I'll see how I go
<chewitt> time to get the dymo labeller uot
<chewitt> must be my lucky day
<chewitt> apparently not
<IgorPec> chewitt: but c4 is 12V ... and you didn't burn the board?
<chewitt> too many boards and bits lying around :)
<chewitt> IgorPec: turns out it helps when you boot the XU4 with the XU4 PSU not the C4 PSU
<chewitt> annoying.. but happy it's probably not my shoddy hacking at fault :)
<chewitt> any known gotchas?
<chewitt> this is with LE not Armbian, but I suspect there are more XU4 people here :)
<chewitt> but then it does some kind of reset, and reboots again
<chewitt> I got this far https://pastebin.com/RgyXWD6B
<chewitt> morning all .. I am experimenting in with mainline u-boot and 5.7-rc3 on an Odroid XU4

2020-03-22

<Tonymac32> chewitt https://github.com/armbian/odroidc2-blobs (it was originally just C2 back in the day).
<Tonymac32> chewitt thanks, we have a repo with all the blobs as well, I'm working it out, but will def. look at this. I put the K2 together and Neil committed it to mainline (same as C2 but without their special blob)
<chewitt> ^ newer image
<chewitt> the only board in that fip repo that I have not personally tested with mainline u-boot is the NanoPi K2
<chewitt> N2 works fine
<chewitt> I got bored of using different packages for every board so repackaged all the fip sources for all the Amlogic SBCs
<chewitt> Tonymac32: https://github.com/LibreELEC/amlogic-boot-fip might be an interesting resource for you