15:19 <hexdump0815> narmstrong: xdarklight: i updated the hdmi dongle wiki page (i was surprised that i'm able to edit it) - the i2c /sys path was wrong (/sys/class instead of /sys/bus and thus there was not new_device node as it seems to be only at /sys/bus

15:21 <hexdump0815> narmstrong: xdarklight: while i was there already i also added a note about using a fine needle to lift the pin and about the needed CONFIG_EEPROM_AT24 kernel option

15:22 <hexdump0815> narmstrong: xdarklight: my first dongle broke, so i had to build a new one - if anyone else plans to create on: better get a few of those dongles to work with as you might need more than one :)

15:23 <hexdump0815> to all of you: get well into the new year!

19:30 <_49616e> narmstrong: I've noticed that discarding blocks on mmc devices does not work on all of my amlogic devices when running the mainline kernel, would you mind taking a look at it? I've tested up to 5.4.1 and none of them can do fstrim on mmc devices.

19:32 <_49616e> The exact same mmc devices (MicroSD cards and eMMC chips) can be trimmed just fine if I use the heavily modified amlogic 4.x kernel.

19:37 <_49616e> By the way, are there any good references that I can refer to for converting Android devicetree files to be used with the mainline kernel? The board I have is based on p211_1g (S905L), and I can use meson-gxl-s905x-p212 to boot the kernel. However, quite a lot of peripherals aren't working, especially HDMI.

19:40 <_49616e> I've tried reading the stock devicetree and diff it with the p212 one, but the nodes for non-functional peripherals are completely different from what's written in the mainline devicetree files.

20:29 <xdarklight> hexdump0815: thank you for updating the wiki page as well as for the wishes to get well into the next year. get well into 2020 as well and see you next year :)

21:01 <_49616e> hexdump0815: Thanks for the update, I just tried the dongle, and it doesn't seem to work for me. I've tried boot@USB and boot@SDC, but neither of them appear to work, the 2 different boards (S905L and S905D) I have will still load u-boot from the eMMC.

21:06 <_49616e> This is the hexdump of the eeprom: 000000f0 00 00 00 00 00 00 00 00 62 6f 6f 74 40 53 44 43 |........boot@SDC|

21:06 <xdarklight> _49616e: re SD discard: I think the controller supports it but it's not enabled at the moment (I think due to lack of testing). just add " | MMC_CAP_ERASE" to mmc->caps |= MMC_CAP_CMD23; in drivers/mmc/host/meson-gx-mmc.c

21:06 <xdarklight> if it works for you (and discard doesn't wipe all your data) then please submit it as a patch :)

21:07 <_49616e> Thanks, I'll give it a shot later today.

21:24 <hexdump0815> _49616e: i was also partially thinking, that it does not work properly, but for me it indeed works - some things to keep in mind:

21:25 <hexdump0815> i did not get it to work with boot@USB - maybe it does not mean booting from usb storage but maybe going into that usb command mode? or its just a usb powerup timing issue - for me it did not work with different usb disks

21:26 <hexdump0815> boot@SDC looks better - initially it did not work neither, but then i realized, that it works after rebooting from a running linux or u-boot - this way it works quite reliable for me ... maybe also some powerup / initialization timing issue?

21:27 <hexdump0815> so what i do now is to boot, interrupt the u-boot to get the command prompt and then use either reboot or reset command depending on u-boot version and on the next boot it will boot from sd card ... good luck

21:42 <hexdump0815> xdarklight: do you understand how this scpi stuff works on gxl? i used the dongle to force a s905w tv-box from sd card and used the khadas vim1 u-boot

21:44 <hexdump0815> xdarklight: that booted ok, but later crashed because the bl301 (or was it bl31?) of the vim s905x provides to high clocks for a s905w - so i restricted the clocks used via https://patchwork.kernel.org/patch/9555763 to 1200000 -> result it boots fine and runs stable

21:48 <hexdump0815> xdarklight: strange thing - although i restricted the scpi clocks to up to 1.2ghz it only runs up to 667mhz - no real idea why ...

21:49 <hexdump0815> xdarklight: and i'm getting a lot of "cpufreq: __target_index: Failed to change cpu frequency: -5"

22:01 <xdarklight> hexdump0815: I'm not sure about SCPI, I *think* BL2 does the frequency and voltage control so you may be lucky with swapping the BL2 of vim1's u-boot with some S905W BL2

22:05 <hexdump0815> xdarklight: the problem is that i'm not aware of any available s905w bl2 - it looked a bit like all gxl are using the same maybe?

22:05 <hexdump0815> repk: maybe you have an idea about the above? at which state is the atf stuff for gxl? might this be a way around this problem?

22:09 <hexdump0815> repk: i think you wrote the gxlimg tool to assemble the final gxl u-boot from all the bl's - would it be possible to go the other way around too, i.e. taking a u-boot from disk and extracting the blxy from it somehow?

22:10 <hexdump0815> i must admin that i only understand only about half (or less ...) of all this u-boot, scpi, bl* magic :)

22:19 <xdarklight> hexdump0815: maybe your kvim1 u-boot is simply too old? https://github.com/khadas/u-boot/commits/khadas-vims-nougat/fip/gxl shows this commit: https://github.com/khadas/u-boot/commit/f3ac2ced86edea0617586c4606945d718659708d#diff-8c1b3acab273dd57088384cbb28c031e

22:22 <hexdump0815> xdarklight: thanks for this hint - this looks promising ... looks like i'll have to build my own vim u-boot maybe - so far i used a prebuilt balbes150/arbian one for testing

22:23 <xdarklight> if you're tinkering with it anyways: why not directly port it to mainline u-boot?

22:25 <hexdump0815> i think this is maybe a bit beyond my skills - but lets see ... if i get anywhere with it i might give it a try - with your help :)

22:26 <hexdump0815> but there seems to be some khadas vim code in mainline u-boot from neil already ... i'll have to build my own u-boot and see where it gets

22:28 <hexdump0815> but looks like that is using the Vim branch of the khadas u-boot repo and the commit you just found is in the khadas-vims-nougat branch ... looks like a bit of deeper investigation is needed :)

22:30 <xdarklight> starting with mainline KVIM1 sounds good - once it works we can look at getting S905W P281 board (and related) support to u-boot

22:35 <hexdump0815> yes - that sounds like a good plan