02:01 <chewitt> nekomancer[m] not aware that I did anything specific for either of them, N2 is relatively untouched (and upstream)

02:02 <chewitt> and I don't track the HK forum much as it's always dog slow for me

02:05 <chewitt> have a look https://github.com/chewitt/linux/blob/amlogic/arch/arm64/boot/dts/amlogic/meson-g12b-odroid-n2.dts

02:09 <chewitt> doesn't look the N2 has any i2c stuff defined

03:19 <chewitt> if someone can point me to the device-tree content required i'll happily add it, and if someone then confirms it works I will send it upstream

04:58 <chewitt> nekomancer[m] if you build from https://github.com/chewitt/linux/commits/amlogic there is a patch from the HK forums in the branch

04:58 <chewitt> let me know if the rtc chip works

04:59 <chewitt> my N2 is being remotely used by someone for testing at the moment so I can't check myself

05:47 <Werner> Good morning

08:19 <IgorPec> good morning

08:51 <Werner> A fresh built cubietruck image from trunk has gzip compression properly in place.

09:10 <IgorPec> ... and upgrade should not break that

09:10 <IgorPec> in the deb, config file is properly defined

09:13 <Werner> Either in the .2 image the compression was not set properly and the upgrade killed because of that or the compression got overwritten for whatever reason.

09:14 <IgorPec> yes

09:14 <IgorPec> if you still have the board up, go an upgrade

09:14 <Werner> I do not have the board. I just built the image and mounted it then to check

09:19 <IgorPec> ok, will double check before rebuilding

09:22 <Werner> Okay got it. I just checked the still available .2 image for cubietruck and the compressoin is set to lz4

09:22 <Werner> That is why the upgrade killed it. So a rebuild of the affected images should suffice

09:23 <IgorPec> yep, but which are affected ?:)

09:23 <IgorPec> all focal ones?

09:23 <Werner> Good question. Better rebuild all sunxi with Focal/Bullseye?

09:23 <IgorPec> yes, probably

09:25 <Werner> The version could be confusing since not all images get bumps.

09:26 <IgorPec> which version?

09:27 <IgorPec> so you mean because only some are getting upgrade?

09:28 <Werner> Yeah. 20.05.3 is not the most recent version for all boards

09:28 <Werner> It is not that important anyways since you always get the latest one from the download section.

13:47 <nekomancer[m]> how to use both https://github.com/chewitt/linux/tree/amlogic and https://github.com/armbian/build ?

14:33 <chewitt> I guess the second one points to a URL somewhere

14:34 <chewitt> I can also point you to an LE image that you can put on an SD card to validate that the RTC bits are working

14:53 <ArmbianTwitter> @DevDread (DevDread): @armbian @AmlogicPR @AllwinnerTech @IloveRockchip @MediaTek @NXP @marvellsemi @Arm @ubuntu @debian @orangepixunlong @Olimex @librecomputer @thepine64 @kobol_io @radxa_oshw @TeeFirefly @cnxsoft Might as well ask here as anywhere else. How is the performance of 20.05. I heard murmurs about performance improvements, are they true? (17s ago)

14:59 <ArmbianTwitter> @DieZuckerbude (Ben Zucker 🍰): @DevDread @armbian @AmlogicPR @AllwinnerTech @IloveRockchip @MediaTek @NXP @marvellsemi @Arm @ubuntu @debian @orangepixunlong @Olimex @librecomputer @thepine64 @kobol_io @radxa_oshw @TeeFirefly @cnxsoft Depends. #Allwinner #H6 for example is now unlocked to 1.8GHz while it was soft-limited to 1488MHz before due to thermal issues. In general all Allwinner SoC based devices (1 more message)

15:12 <nekomancer[m]> chewitt: LE image? where to get it?

15:13 <chewitt> https://chewitt.libreelec.tv/testing/9.80/LibreELEC-AMLG12.arm-9.80.0-odroid-n2.img.gz

15:13 <nekomancer[m]> currently I have N2 with "nightly" setting in armbian-config

15:13 <chewitt> write to a spare SD card and have the boot switch to the right

15:13 <nekomancer[m]> oh, LE means Libre Elec

15:13 <chewitt> indeed

15:18 <chewitt> test the image, if it works you can nag one of the Armbian maintainers to pick the same patch to their kernel patch-set

15:19 <chewitt> and if you confirm, I'll send it upstream so we (LE/Armbian) can later drop the patch

15:19 <chewitt> looking at the collection of stuff in the Armbian repo the other day, some upstreaming is needed :)

15:30 <nekomancer[m]> sad — libreelec not listens for ssh

15:31 <nekomancer[m]> 111,139,445.8080 ports. so — how to enter into root shell?

15:35 <nekomancer[m]> but howto about first connection written like ssh available

15:50 <nekomancer[m]> then, rtc work, but it have to be mapped as rtc0, or at least /dev/rtc sgould point to /dev/rtc1.

15:51 <nekomancer[m]> chewitt: is renumbering possible on dtb level?

15:59 <chewitt> sad, or secure?

15:59 <chewitt> first-run wizard has a screen for "enable SSH"

16:00 <chewitt> or you can add "ssh" to kernel boot params in extlinux.conf to force the daemon to start

16:01 <nekomancer[m]> first run wizard on aheadless host — sad

16:01 <chewitt> LE is not a headless distro :)

16:01 <chewitt> Armbian might be, but we expect a TV to be connected

16:02 <chewitt> numbering is prob. dependent on probe order so vrtc (needed for wake) is /dev/rtc0 and on-board is prob. /dev/rtc1

16:02 <nekomancer[m]> but I found solution with kernel string and go ahead to test

16:03 <nekomancer[m]> then — there no way to make it "just work"?

16:04 <chewitt> no idea

16:04 <nekomancer[m]> every N2 will require to manual add line aout /dev/rtc1 into hwclock settings?

16:04 <chewitt> i'm not sure it's been thought through by the maintainers

16:05 <chewitt> I've seen khadas adding a &vrtc; node in device-tree to disable vrtc

16:05 <nekomancer[m]> with kernel 4.x it works as rtc0

16:06 <chewitt> disabling vrtc ensures the on-board will be /dev/rtc0, but also ensures the device cannot self-wake on timer, as (reading the commits) this requires vrtc

16:06 <nekomancer[m]> you tell rtc0 need for wake... but what wake can be on not powered and not set timer?

16:07 <nekomancer[m]> and hwclock can't set rtc0 even if can read.

16:07 <chewitt> https://patchwork.kernel.org/cover/11090979/

16:09 <chewitt> this was done for the next-gen Google device, so there was a reason behind it

16:09 <nekomancer[m]> aha. it's not a clock.

16:10 <chewitt> https://patchwork.kernel.org/patch/11090987/

16:10 <chewitt> ^ better description

16:10 <nekomancer[m]> nice for google. bad for all other meson users.

16:11 <chewitt> as long as they continue to bankroll upstream development I'll not whinge too much :)

16:13 <nekomancer[m]> 🥴

16:21 <nekomancer[m]> okay. rtc1 much better than nothing. chewitt , please, push it at least as rtc1

16:21 <chewitt> I've no idea how that might be done, but I'll start a convo with the folks who added it

16:26 <nekomancer[m]> please

16:34 <chewitt> "It can be implemented but not sure it will be accepted upstream"

16:35 <chewitt> but, now it's been mentioned someone will sleep on it and likely have an idea

16:35 <chewitt> some udev fu might be possible

16:40 <nekomancer[m]> on libreelec-like at least I can run `echo "HCTOSYS_DEVICE=rtc1" >> /etc/default/hwclock`

16:44 <nekomancer[m]> interesting hardkernel's devs vision. what they means to use it when design oard

17:00 <chewitt> if you consider that Amlogic itself is blind to the existence of Linux .. everything is focussed on Android

17:00 <chewitt> vendors like HK that dare to offer something with 5.4 LTS kernels is already a bold move

17:01 <chewitt> I see about 50% are happy with that kind of "board support package" approach

17:01 <chewitt> the other 50% want (or need) to be on the bleeding edge, which is, err.. bloody

17:09 <nekomancer[m]> old products usable in old sectors of life. sectors where progress stopped or very slow. where no new functions required.

17:09 <nekomancer[m]> linux and sbc far from that state. there are a lot of unanswered requirements, lots empty niches, new standartsand protocols every month. And trying to publish product and forget, or "support as released, just most bloody security fixes" — sabotage.

20:14 <das_coach> hi@all, I'm looking for someone who knows a bit about u-boot, dts's and buildroot, as i'm trying to create my own image for a s905x3 based box, but i'm stuck/confused about how u-boot internally works (i only know bios/uefi based systems, so i'm completely new to arm boxes)