03:21 <efqw> On that matter, I’d like to express my gratitude towards everyone who has put in time and effort to upstream support or develop/distribute relevant utilities/communities images, including but not limited to narmstrong, repk, hexdump0815, balbes, and more.

03:51 <chewitt> @narmstrong @khilman I’ve done some experiments with the GT-King Pro to see if we can pinpoint the "under load" deadlock issue

03:51 <chewitt> replacing vendor u-boot with mainline (2020.10) 100% mitigates the problem

03:52 <chewitt> I can zero the entire emmc, and copy files of any size between emmc, sd, usb, etc.

03:52 <chewitt> whereas before it would deadlock quickly

03:53 <Tonymac32> chewitt which SoC is that?

03:53 <chewitt> S922X-H

03:53 <chewitt> Armbian has the same reports in the forums, and Manjaro

03:54 <Tonymac32> ok. I have a PR in at Armbian to move to mainline u-boot, just waiting on getting the kernel image into the right format (no time)

03:54 <Tonymac32> because I was going to say exactly what you just did

03:54 <Tonymac32> I've seen the same reports

03:54 <chewitt> the challenge is .. erasing vendor u-boot

03:55 <chewitt> the issue doesn't exhibit on Android, and the CE devs commented they don't see it either

03:56 <chewitt> booting to mainline Linux is simple enough using the usual bootscripts

03:56 <chewitt> but under mainline when you attempt erase, there's a high risk of the deadlock leaving you with a partially erased bootloader

03:57 <chewitt> GT-King Pro isn't hard to resolve that with since it has (for reasons Beelink have never described) a large RS232 port on the box which gets UART output

03:58 <chewitt> but GT-King (non-pro) and the GS-King-X would need dismantling and pins soldering.. or shorting pins on RAM etc.

03:58 <chewitt> to get SD to boot

03:59 <chewitt> In mainline u-boot it also shows up as a 2GB device, when it has 4GB

04:10 <efqw> How does DRAM detection work in modern u-boot by the way?

04:11 <efqw> In the old u-boot 1.1.6 era I see some platforms have ram timings hard-coded in the u-boot source

04:14 <chewitt> no idea

04:21 <Tonymac32> but, to the point, I don't know either I'm afraid

04:32 <chewitt> but to get back on-topic .. I'm wondering what could be the issue with vendor u-boot?

04:32 <chewitt> I have /some/ sources, but no history and the usual vendor hacking to add their board/name filess

04:33 <chewitt> but ultimately it'll be the same bsp source that every other vendor uses

04:33 <chewitt> as much as they hacked it for their boards, they probably didn't have imagination to hack anything more than those minimal changes

04:45 <efqw> I have some devices that are stuck with USB1.1 speeds under vendor u-boot for some reason

04:45 <efqw> Especially on gxm

04:45 <efqw> Loading anything from usb mass storage takes forever as a result

04:46 <efqw> Mainline u-boot doesn't have this problem at all.

04:52 <Tonymac32> vendor is 2015, after all

04:52 <Tonymac32> there's only so much hacking you can do

07:22 <efqw> 2015 should at least have fully functional USB2.0 :P

07:41 <narmstrong> Did you try chainloading mainline u-boot and doing an usb init before loading Linux ?

07:42 <narmstrong> Amlogic enables some more bits in dwc3 and has more agressive usb phy settings

07:43 <narmstrong> But we reset all these so it must be a axi bus setting or something similar

08:04 <brads> chewitt: could maybe try to dump out the usb memory map booting different uboot's with the same kernel and see what registers are different? long shot but might be easier than working out the vendor uboot code

08:04 <brads> you might find something obvious