Werner changed the topic of #armbian to: armbian - Linux for ARM development boards | www.armbian.com | Github: github.com/armbian | Commits: #armbian-commits | Forums Feed: #armbian-rss | This channel is logged -> irc.armbian.com
sassinak-work has quit [Ping timeout: 240 seconds]
sassinak-work has joined #armbian
ChriChri_ has joined #armbian
ChriChri has quit [Ping timeout: 265 seconds]
ChriChri_ is now known as ChriChri
<Tony_mac32> this looks unbelievably similar to the tinkerboard issue
<Tony_mac32> uuuuuugh
<Tony_mac32> that's why I asked for testing with non-uhs cards if anyone happened to have one
<lanefu> "please test with shitty SD cards" :P
<buZz> :D
<Tenkawa> go to microcenter and buy the bargain bin ones
Tenkawa has left #armbian [#armbian]
_whitelogger has joined #armbian
sassinak-work has quit [Ping timeout: 246 seconds]
sassinak-work has joined #armbian
dddddd has quit [Remote host closed the connection]
torv has quit [Ping timeout: 240 seconds]
torv has joined #armbian
redentor has joined #armbian
<Tony_mac32> ewww
<Tony_mac32> lol
<c0rnelius> :)
<lanefu> i'v never been to a microcenter.. there's one near DC i guess i could check out sometime
archetech has joined #armbian
<c0rnelius> i think i saw one when i lived in maryland, but never been to one either
<c0rnelius> currently in Miami and I gotta say... not even a radio shack here :)
<c0rnelius> place is said
<c0rnelius> and Igor was right. the C4 is way more stable with the eMMC.
<c0rnelius> said? sad*
<nekomancer[m]> C4 — not a safe word in post-9/11 world
<nekomancer[m]> all "bugz" and "carniwors" etc looks to us
<c0rnelius> so the lepotato's thermals aren't out of the box with mainline or the latest lts?
<c0rnelius> or am I missing something?
drobo_01 has joined #armbian
drobo_00 has quit [Ping timeout: 258 seconds]
drobo_01 is now known as drobo_00
<lanefu> c0rnelius: kernel 5.6 yes.. kernel 5.4 i dont think so
<lanefu> hmm
<lanefu> wait ignore my words
<lanefu> when you say thermals you don't mean temp readings
<c0rnelius> really cuz i'm not getting on 5.6.y
<c0rnelius> yeah temps
<lanefu> Welcome to Armbian buster with Linux 5.4.35-meson64
<lanefu> No end-user support: built from trunk
<lanefu> System load: 1.08 1.02 1.01 Up time: 2 days 11:23
<lanefu> Memory usage: 63 % of 1967MB Zram usage: 2 % of 983Mb IP:
<lanefu> CPU temp: 49°C
<c0rnelius> hmm
<c0rnelius> k
<c0rnelius> thanx lanefu
<lanefu> word
<c0rnelius> son
redentor has quit [Quit: Leaving]
xec has joined #armbian
<Tony_mac32> what
xecuter has quit [Ping timeout: 260 seconds]
<chewitt> btw, that SD card shutdown patch is not proven
<chewitt> i'm not sure it fixes anything, but it otherwise appears to be harmless so I left it in my branch
<Tony_mac32> That is well understood
<Tony_mac32> I need to get my K2, C2, and Vim1 down to test reboot on all
<chewitt> I haven't seen issues with rebooting C2 or VIM1 .. still need to find a K2 sometime
<Tony_mac32> I don't think that will be easy, I believe they are gone
<chewitt> I have a search filter on eBay in case one gets posted in a cupboard clearoutt
<Tony_mac32> A shame, the board came out too early, and didn't have as much interest from FrienlyARM as the C2 had from Hardkernel
<chewitt> timing is everything in some of these devices
<Tony_mac32> for the 3.3V patch, has anyone probed a board?
<chewitt> not sure, probably not
<Tony_mac32> ok
<Tony_mac32> this is within my power
<Tony_mac32> ;)
<Tony_mac32> the Tinker had this issue, which I also need to revisit, as the solution is similar, but had to be wrapped in a device tree check because it would break the MiQi
<Tony_mac32> obviously the ASUS code is unconditional
<chewitt> c0rnelius Linux 5.7 onwards should expose thermal things for LePotato (and all other GX devices)
<chewitt> I reworked the VIM2 thermal zones support so it applies to all boards
<Tony_mac32> nice
<chewitt> aka, I had a fair crack at the device-tree changes, then Neil pointed out the mistakes :)
<c0rnelius> chewitt: thank you for that bit of info.
<chewitt> it seems to trigger some warning splats on GXBB devices, but I don't see them on GXL/GXM
<chewitt> hrtimer things .. I have no clue about it but it appears to be harmless
<chewitt> I guess GXBB needs a tweak/quirk or such somewhere
<Tony_mac32> probably, but why mighjt be an interesting question
<Tony_mac32> The Wetek play was a GXBB? In those days I still had a mini-ITX serving as my media server. Then amazon/etc quit working on Kodi and I gave up. :/
<chewitt> Play1 is 8726MX, Play2 is GXBB
<chewitt> Amazon works well these days
<Tony_mac32> Yeah, the dumb part of my brain never considered why you'd be so Amlogic-oriented.
<chewitt> ?
<Tony_mac32> I'll have to check that out, of course my issue was the wife/kids
<Tony_mac32> so I have an Android TV
<chewitt> the Sandmann79 add-on is the one that I use
<chewitt> this uses inputstream.adaptive, which will install the required widevine bits
<chewitt> via inputstream.helper
<Tony_mac32> ah ok
<chewitt> not sure it will work on Armbian tho, as the widevine libs are only available in 32-bit packaging for Linux/ARM
<Tony_mac32> right, it turns out the SBC's I have a surplus of include the Tinker Board
<chewitt> LE uses a 64/32 arrangement similar to ChromeOS/Android specifically so we can use the 32-bit libs
<Tony_mac32> yeah. We spend a lot of time explaining we're not really a media-centric distro
<chewitt> inputstream.helper downloads a 3.1GB ChromeOS update package that we can extract the libs from
<chewitt> Google allows redistribution of the libs, but if you do this, it implies you accept their terms for distribution
<Tony_mac32> ugh yeah
<chewitt> IANAL, but even I can spot that the terms are somewhat in Googles favour and you indemnify them against *everything*
<chewitt> so the ChromeOS download is the way to go
<Tony_mac32> agreed
<Tony_mac32> I need to look at the kernel config more closely, this audio thing is killing me. the device trees look right, but nothing.
<chewitt> that's from 5.7 but it has all the audio module bits set
<chewitt> some of the modules changed name over time
<chewitt> if you're looking at Jerome's branches in gitlab
<Tony_mac32> Yeah, I've handled all 3 iteration
<Tony_mac32> ;-)
<chewitt> there are also dependencies on other things in the ASoC tree from morimoto
<chewitt> IRIC
<chewitt> IIRC
<chewitt> so backporting to 5.4 might be a challenge
<Tony_mac32> we're (trying) to move to 5.6
<chewitt> for Amlogic I'd aim at 5.7
<Tony_mac32> I have (had?) the last generation patchset working on 5.4
<Tony_mac32> might be tight, I could check feasability in parallel
<Tony_mac32> the release leader lanefu would be better to advise timing
<Tony_mac32> I'm just the EE who got too curious and fell into the well
<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
<Tony_mac32> :)
<chewitt> each recent kernel bump has culled ~50 patches from my branch
<Tony_mac32> I can agree with that, but we didn't really care so much about having the vdec/etc before, but now it seems different, so we have 128 patches last count
<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> if you're following my branch(es)
<Tony_mac32> I had a bit of a family emergency most of last year, so I fell off the radar entirely, I'm trying to catch back up
<Tony_mac32> I'll take a look
<chewitt> ^ has audio working on everything, but the dtsi approach was shot-down by Jerome
<Tony_mac32> hmm ok
<chewitt> the problem I was trying to solve is that each board/dts has a unique audio card name
<chewitt> this requires a different alsa conf
<Tony_mac32> right
<chewitt> this is not working yet, but according to someone who knows more alsa than me, should work
<chewitt> basically.. use a single card.conf and map the board-specific cards to the conf
<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> the other approach will be patching device-trees to use common names, but I prefer to keep the linux patch-set to a minimum
<Tony_mac32> yeah, I can agree with that
<Tony_mac32> lol the pinephone made it into mainline I see. I need to talk Pine into making a modern Jornada 720
<Tony_mac32> :-)
sbbg has joined #armbian
<Werner> Good morning.
sassinak-work has quit [Ping timeout: 272 seconds]
sassinak-work has joined #armbian
<chewitt> Tony_mac32 I was missing a change to Makefile.am https://github.com/chewitt/alsa-lib/commits/amlogic
<chewitt> seems to work
<chewitt> the card confs prob need some tweaking
<chewitt> ^ this is another piece of the puzzle
sunshavi has quit [Remote host closed the connection]
sunshavi has joined #armbian
<IgorPec> good morning
<HerculeP> moin
Elpaulo has quit [Read error: Connection reset by peer]
Elpaulo has joined #armbian
<IgorPec> tony_mac32: K2 reboots succcesfully in 10 out of 10 cases while C2 hangs at first. Using same SD card, with that patch included
dddddd has joined #armbian
Elpaulo has quit [Quit: Elpaulo]
macc24 has joined #armbian
sassinak-work has quit [Ping timeout: 240 seconds]
sassinak-work has joined #armbian
archetech has quit [Quit: Leaving]
dddddd has quit [Ping timeout: 260 seconds]
dddddd has joined #armbian
archetech has joined #armbian
<lanefu> good morning
<HerculeP> moin
<HerculeP> hopefully ;)
<HerculeP> oops, wrong #ch
<IgorPec> morning
Tenkawa has joined #armbian
DaRock has quit [Ping timeout: 272 seconds]
dddddd has quit [Remote host closed the connection]
drobo_00 has quit [Ping timeout: 244 seconds]
drobo_00 has joined #armbian
<Tony_mac32> @igorpec are we having fun yet? chewitt is this same behavior seen on 5.7? I haven't built 5.7 yet
<Tony_mac32> lol spending too much time in Discord, keep @'ing people
<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)
<chewitt> I did some across a tester the other week who was unable to boot the mainline LE image tho
<chewitt> ISTR it worked for me tho
<Tony_mac32> I don't remember having reboot issues with amlogic until 5.6, but maybe I missed it during my leave of absense
<IgorPec> hey. mmc works flawlesly
<IgorPec> i spent a day with C1 :)
<IgorPec> boot logs are flooded with ext4 / fs related errors
<Tony_mac32> I've never beheld the C1 ;)
<chewitt> I have one in-front of me :)
<TomTheDragon> anyone else have issues getting display to show up on rockchip platforms? I... think there's a weird edid thing that interferes with my particular video device
<IgorPec> i got it as a gift once
<c0rnelius> can the N2 boot from the emmc using mainline uboot?
<chewitt> I need to fiddle with the ancient C1 u-boot so that I don't have to change our boot arrangements
<Tony_mac32> I believe it can, I booted mine from SD, but my u-boot to kernel handoff went wrong somehow and I moved on to the more pressing issues of 5.6
<chewitt> c0rnelius: works fine with mainline
<TomTheDragon> actually.. ANY platform with one of the cheap HDMI->VGA adapters
<IgorPec> chewitt: yeah. u-boot is in terrible state and
<TomTheDragon> because the other system that works perfectly with is RPi and I've only ever run Raspbian
<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
<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.
<chewitt> N2 has the switch on the front
<IgorPec> tomthedragon: then use rpi :)
<chewitt> I'm not sure I ever successfully managed to coax petitboot into doing something useful
<TomTheDragon> IgorPec: well, I like rpi but they aren't the fastest or most featureful things around, so want to be able to use the rockchip
<chewitt> but LE (and that u-boot I linked) work fine from SD or eMMC modules
<IgorPec> tomthedragon: elsewhere you will need to invest something in sw
<c0rnelius> chewitt: hmm. I'll give it a go.
<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?
<chewitt> the SoC checks for BL2 in the first sector and 512 sector on all GXL and newer devices
<TomTheDragon> IgorPec: i'm able to get display by doing xrandr -s 1280x720, xrandr -s 1024x768... but... it's senseless. it defaults to 1024x768
<chewitt> so you can use u-boot.bin.sd.bin for both SD/eMMC
<c0rnelius> ah thats what I thought
<chewitt> GXBB and older needs BL2 in first sector for eMMC, but can have it in 512 sector for SD
<IgorPec> TomTheDragon: which hardware?
<chewitt> hence the need for the Amlogic partitioning scheme (MBR/GPT shifted away from 1st sector)
<TomTheDragon> IgorPec: Rock Pi 4 (and Rockpro64)
<IgorPec> TomTheDragon: aha. we might get to this in couple of months
<TomTheDragon> oh? you know something about it?
<IgorPec> without asking around and doing a research, only general stuff
<IgorPec> we are fixing those problems for older rokcchip devices but its also not finished
<IgorPec> similar has to be done also here.
<IgorPec> but before you get too exicted, those are general terms: https://github.com/armbian/build#support
<TomTheDragon> but I'm able to get display....
<IgorPec> it just doesn't work properly, right?
<TomTheDragon> it just requires so much finicking... that suggests it's pulling from a submodeline (like, does that exist)
<IgorPec> sorry, i don't know what to do to fix that
<TomTheDragon> but why would 1280x720 "activate" the display
<TomTheDragon> upon which I can set 1024x768 back and actually see
<IgorPec> wrong detection?
<TomTheDragon> maybe
<IgorPec> clerly something is wrong. if you want full functions, you have basically two options: diy or hire someone
<IgorPec> or wait ... it will be fixed one day
<TomTheDragon> i'm thinking wait, but not sure if anyone even cares about vga these days
<IgorPec> in this world, you buy a device that you suits your needs. not the other way around
<TomTheDragon> that's true
<IgorPec> devices are dirt cheap, software support ain't
<TomTheDragon> of course, when I got it I thought it was supported :P
<IgorPec> hehe, all those hw dealers selling bs
<IgorPec> its just a matter of the size
* nekomancer[m] set boinc rosetta to n2... and then can't login via ssh. timeouts.
<Tony_mac32> nekomancer[m], needed to limit CPU usage so only the big cores get the work, basically it's ignoring you
<Tony_mac32> igorpec did you see the refactor of the dtb install script on 5.7?
<IgorPec> no
<IgorPec> or you mean that from the-going?
<IgorPec> can have
<IgorPec> but i haven't been able to review, so can't tell much about
<Tony_mac32> hmmm
<IgorPec> so its like to go away from stock debian way
<IgorPec> no more patching
<Tony_mac32> I stumbled on the change because it kills our overlay patches
<Tony_mac32> but I have kind of felt like we needed to do those differently
<IgorPec> yeah, i think this way overlays should be covered well ... without beeing affraid from upstream changes
<Tony_mac32> this post by going is quite interestingly written. :)
<IgorPec> first sentence ?:)
<Tony_mac32> I don't often hear "sacred" and "rectilinear" in conversation.
<Tony_mac32> ;-
<[TheBug]> You need to have more sacred and rectilinear conversations then ;) lol
<[TheBug]> rectilinear is fun to say..
<IgorPec> i envy you natives :)
<Tenkawa> chewitt: I want to pass along a big thank you..
<Tenkawa> I am one of the N2 users that was running into emmc hiccups with u-boot
Xander55 has joined #armbian
xec has quit [Quit: God Nite]
dddddd has joined #armbian
xecuter has joined #armbian
Xander55 has quit [Remote host closed the connection]
Naka is now known as Nakaori
sunshavi has quit [Remote host closed the connection]
sunshavi has joined #armbian
archetech has quit [Quit: Konversation terminated!]
macc24_ has joined #armbian
macc24 has quit [Ping timeout: 256 seconds]
macc24_ has quit [Ping timeout: 272 seconds]
macc24 has joined #armbian
Tenkawa has quit [Quit: Leaving.]
jakogut has quit [Read error: Connection reset by peer]
jakogut has joined #armbian