11:53 <asdf28> :->

17:39 <efqw> Hello everyone, I'm trying to get linux running on an S905L2 box.

17:40 <efqw> Lately the architecture acronyms have became quite confusing. According to the stock dtb, this is "gxlx". Is this related to "g12a" in any way?

17:44 <efqw> I compiled mainline u-boot for gxl (p212_defconfig) and managed to chainload it from the stock u-boot without any issues, but I get a kp whenever I try to boot a pre-built arm64 image from the armbian forum (using the same p212 dtb).

18:49 <hexdump0815> efqw: gxlx seems to be a lower end s905w - for me it worked perfectly with the gxl-s905w-p281.dtb ... one difference i found so far is that the mapi only has 2 pp cores instead of 3 usually, so be prepared for potential trouble if you want to use mali

18:54 <efqw> hexdump0815: Cool, I'll try that image in a bit. By the way, how was the u-boot.bin.usb.tpl files generated?

18:55 <efqw> I dumped the first bit of the emmc and have the ATF binaries extracted with gxlimg already

18:56 <efqw> u-boot.bin.usb.bl2 seems to be just bl2.sign, but I'm not sure how to merge the bl3x blobs into one.

18:57 <hexdump0815> efqw: https://github.com/repk/gxlimg/blob/master/README#L97-L112 - but this is for booting via pyamlboot

18:58 <efqw> yeah, sorry, I was trying to use this with pyamlboot, it's unrelated to the dtb issue

18:59 <hexdump0815> this one should work: https://github.com/hexdump0815/u-boot-misc/releases/download/200926-01/s905l2-u-boot.bin.usb.tpl.gz - for the bl2 you can use the khadas vim one - worked for me

19:02 <hexdump0815> and please keep in mind that for usb booring via paymlboot you'll have to either erase the emmc, ground the emmc clock pin or use some special hdmi dongle to force usb boot

19:05 <efqw> yes, I've got one of those hdmi eeprom dongles

19:05 <efqw> https://www.irccloud.com/pastebin/db2OvjpR/

19:06 <efqw> Still got a kp :(

19:13 <narmstrong> Weird stuff, which kernel it is ?

19:14 <efqw> https://forum.armbian.com/topic/12162-single-armbian-image-for-rk-aml-aw-aarch64-armv8/

19:19 <efqw> Nice, pyamlboot works great with the files I just generated, I was able to load mainline u-boot into memory without any issues.

19:22 <narmstrong> Nice to read !

19:24 <efqw> narmstrong: would you please add the chip ID to u-boot and the linux kernel?

19:24 <efqw> `SoC: Amlogic Meson GXLX (Unknown) Revision 26:e (c1:2)` this is what I'm getting right now

19:25 <efqw> The SoC still says "S905L" but now with 2-B printed at the bottom right corner.

19:29 <efqw> It looks just like the one in this post but says "2-B" instead of "2" in the corner: https://discourse.coreelec.org/t/support-for-amlogic-gxlx-p261-board-request/1520/14

19:37 <efqw> I wonder which variant of the S905L2 is in that x7-5g box that hexdump0815 mentioned in their u-boot-misc repo.

19:37 <efqw> I'd like to know if the S905L2-B and the S905L2 share the same ID.

19:44 <efqw> Not sure what does the B suffix represent.

19:44 <narmstrong> The -B represent licencing options

19:45 <narmstrong> We have « { "S905L", 0x21, 0xc0, 0xf0 }, » so only replacing 0x21 by 0x26 would fix it

19:46 <narmstrong> efqw: if you can rebuild the kernel, try to fix this line https://github.com/torvalds/linux/blob/659caaf65dc9c7150aa3e80225ec6e66b25ab3ce/drivers/soc/amlogic/meson-gx-socinfo.c#L58

19:52 <efqw> I can but it would take me quite a while. I'd rather just test with u-boot for now since board-info.c has the same structure.

20:01 <efqw> I added a line after https://elixir.bootlin.com/u-boot/latest/source/arch/arm/mach-meson/board-info.c#L63 and SoC is not shown as "unknown" anymore: `{ "S905L2", 0x26, 0xc0, 0xf0 },`

20:01 <efqw> `SoC: Amlogic Meson GXLX (S905L2) Revision 26:e (c1:2)`

20:08 <xdarklight> efqw: I don't know if it's related but hexdump0815 mentioned that the Mali GPU only has 2 PP cores on that SoC. since it's crashing inside lima: try removing the "incorrect" PP interrupt lines from arch/arm64/boot/dts/amlogic/meson-gx-mali450.dtsi

20:08 <xdarklight> efqw: this is especially important with newer lima versions (I think starting with Linux 5.9) where we also have runtime power management (where cores are turned on/off for power saving reasons)

20:13 <efqw> Good idea, but I'm not really familiar with it, which lines should I remove?

20:14 <efqw> There are 10 entries in the interrupts cell

20:15 <xdarklight> efqw: I am going with the assumption that PP core 2 was removed. so this would be the patch for that: https://pastebin.com/DeFXEEJm

20:16 <xdarklight> (I have no evidence or information whether PP core 2 is really the one which was removed though)

20:16 <efqw> cool, I'll give it a shot, thanks

20:32 <efqw> xdarklight: your assumption was correct, I decompiled the p212 dtb because I was lazy, took out the relevant entries, and the kernel is not panicking anymore

20:32 <hexdump0815> efqw: sorry i got dropped - your patch looks good to me - i removed pp2 and it worked for the legacy mali driver, so i assume it should work for lima too

20:33 <efqw> https://www.irccloud.com/pastebin/jDDjfhZ1/

20:33 <efqw> Now I only get an oops instead

20:33 <hexdump0815> i got two of those x7g5 boxes which i bought as 4g+32g from the same dealer and both were only 1g+8g plus both were even different hw (wifi ship, memory)

20:34 <efqw> ouch, that was awful

20:34 <hexdump0815> on one box i looked at the soc and it only had a small 2 at the bottom

20:34 <hexdump0815> i had a dispute with the dealer and at least they ended up very cheap this way, but anyway they are complete garbage

20:37 <efqw> What should we do about this mali thing moving forward? Perhaps a new special dtsi?

20:37 <hexdump0815> you still seem to use the p212 dtb - better use the p281 one - not sure if that really makes a significant difference - xdarklight: might know as he added s905w support i think

20:40 <xdarklight> from the top of my head I don't remember the differences between p212 and p281

20:42 <hexdump0815> p281 has the scpi freq limited to 1.2ghz and i thinkg there was some special cases somewhere in the code - i think p212 boards run fine with the p281 dtb but not vice versa, but i might be wrong

20:46 <hexdump0815> efqw: my board inside looked very similar to the one from your picture, also without sd card - i think they produced a lot of those as cheap as possible and put it into a bunch of different boxes

20:56 <efqw> Thanks to pyamlboot at least we have a reliable way to revive these devices without MicroSD card slots now.

20:56 <efqw> As long as you have an ATF dump and console access, it's not to brick the device anymore :P

20:56 <efqw> *not possible

21:02 <hexdump0815> yes - i was also very happy about pyamlboot in this case :) ... i have meanline simply created a mainline u-boot and put that onto emmc directly to get rid of all the lagacy stuff on emmc and it works very well

21:02 <efqw> Previously I was always wary of these cheap stuff without MicroSD card slots, because if I somehow manage to break u-boot, it will be impossible to recover without using the usb burner tool and the vendor's android based firmware bundle, which is usually quite hard to find in the wild.

21:03 <hexdump0815> i'm even running with mainline atf, but bl2 and bl30 are still the blobs extracted with gxlimg

21:05 <efqw> I tried using mainline atf on a gxm device as well, obviously that didn't work out, 4 out of the 8 cores failed to start :P

21:06 <hexdump0815> for me it even crashed in the gxm case - but it works well for gxbb, gxl, gxlx, g12a and with some minor tweaks sm1

21:07 <efqw> By the way, how did you manage to enable the HDMI console in u-boot?

21:08 <efqw> I tried digging for this a while ago but didn't find anything

21:11 <hexdump0815> https://github.com/hexdump0815/u-boot-misc/tree/master/misc.gxl - this is for gxl - see the patches in there: one for serial and one for hdmi/usb kbd - the price to pay for hdmi/usb kbd is that you'll have to disable the serial console

21:13 <hexdump0815> otherwise i very often got noise from the serial console giving me ghost input on the hdmi/usb kbd console so that it was unuseable ... those patches are working for gxl and gxm, for gxbb i have it working too, but not yet for g12a and sm1

21:15 <efqw> I've also been trying to use efi but so far it's unsuccessful. Seems like every step of the way is broken for some reason. shim has a long-standing bug that makes it fail to read the next efi binary that it needs to chainload (grub), grub will start if I boot it directly but will not start the kernel, it just dumps me back to the grub menu without telling me why it failed.

21:16 <hexdump0815> here is my gxlx boot block with hdmi/usb kbd which i have dumped directly onto the emmc on the gxlx boxes: https://github.com/hexdump0815/u-boot-misc/releases/download/200926-01/boot-amlogic_gxl_atf-aarch64-s905l2.dd.gz - either dumped directly or with seek=1 skip=1 to keep the partition table if there is already one

21:16 <efqw> If I boot the kernel (with efi stub) in u-boot with bootefi, I'll get that dreadful "synchrnous abort" thing again.

21:18 <efqw> I saw the patches, will probably give them a shot next week.

21:18 <efqw> It's unfortunate that uart has to be disabled, because I'd rather keep it for obvious reasons.

21:19 <hexdump0815> yes - but compared to some years ago the situation is already quite good with all the open sourcing efforts going on - it simply takes ages until it is really ready ... like with lima and panfrost too, but they start to be useable now after years (although still have quite a few bugs and problems in them)

21:19 <efqw> fwiw efi boot seems to work on sunxi

21:19 <efqw> (with mainline u-boot)

21:20 <efqw> I have an interest in this because some linux distributions insist on using UEFI for arm64, such as Fedora and openSUSE

21:21 <efqw> If u-boot can at least load grub, and grub can successfully boot the kernel, this would make more distros available on this platform with relatively minimal tinkering required.

21:22 <efqw> In practice efi boot will slow down the boot time for quite a bit (especially on slow platforms like the RaspberryPi3), but the slightly better compatibility is an acceptable tradeoff imo.

21:37 <emOne[m]> narmstrong: is it just me or has there been HEVC video decoding since Linux 5.7?

21:40 <emOne[m]> Or anyone else for that matter

21:45 <efqw> It would be nice if someone can post some basic instructions on how to utilize the hw vdec support with players such as mpv.

21:46 <emOne> efqw I didn't even know that there was a h265 driver

21:47 <efqw> I was mostly referring to h264 :P

21:48 <emOne> What os do you use?

21:48 <emOne> "mpv has good hardware acceleration support, although it is not enabled by default. To enable it, use the –hwdec command line switch"

21:49 <emOne> Efqw have you tried that?

21:55 <emOne> @efqw I didn't even know that Hardware acceleration was disabled by default in mpv

21:55 <emOne> That would explain the sluggish performance and screen tearing of even low res video

21:55 <emOne> Hmm

23:55 <brads> emOne: for mpv make sure ffmpeg is at least version 4.3 and use mpv --hwdec=auto