00:00 <tokyovigilante> apritzel: great will do, thanks

00:09 <apritzel> vaughngx4: the UART situation is odd, those pins are working on almost every device we had our hands on

00:09 <vaughngx4> apritzel: Awesome! So I run your script with the image file as arg1?

00:10 <apritzel> yes

00:11 <apritzel> vaughngx4: for the UART there are a few exceptions, though. At least one device was missing a FET to connect RX and TX, see https://linux-sunxi.org/Eachlink_H6_Mini#Adding_a_serial_port_.28might_void_warranty.3F.29

00:16 <vaughngx4> apritzel: There are a few spots on my board that could potentially be missing a resistor for UART but the manufacturer decided to be a pain and mounted the eMMC on top of the UART traces so I can't exactly follow them. If you don't mind having a look, this is the device: https://ibb.co/album/208yPZ

00:27 <apritzel> vaughngx4: did you try just connecting GND and TX?

00:27 <vaughngx4> apritzel: Unfortunately your script did not find a DTB in any of the images I dumped be it by-name or nandX.

00:27 <vaughngx4> apritzel: I did, still nothing

00:28 <apritzel> DTB script: are those image files somehow compressed? Did binwalk find something?

00:30 <apritzel> can you try to use a multimeter in continuity mode to find if the TX pin connects to some of the (unpopulated) resistor pads?

00:31 <vaughngx4> apritzel: No compression AFAIK? I used dd to dump the partitions directly to .img files. I didn't read through all the binwalk output, will run it again. Is there something I can grep for? Not exactly sure what I'm looking for

00:31 <apritzel> and btw: this chips looks more like raw NAND flash rather than eMMC, unfortunately. Which means there will be no easy mainline Linux support for that :-(

00:35 <vaughngx4> apritzel: Oh dear. So I probably just bricked a device for nothing

00:36 <apritzel> vaughngx4: there should be something like "2117484 0x204F6C device tree image (dtb)", though my copy of binwalk doesn't seem to identify a DTB, for some reason

00:37 <apritzel> vaughngx4: it's not all hope lost. How did you dump the image? From a running system, or via U-Boot or fastboot?

00:38 <vaughngx4> apritzel: no there is no continuity but now that I'm testing I think maybe I damaged the board during soldering as there is no continuity from TX to anything it seems

00:40 <vaughngx4> apritzel: I dumped it from a running system (KitKat) but I bricked the device by flashing a bad boot.img via fastboot (booted using adb reboot fastboot)

00:41 <vaughngx4> apritzel: The bad boot.img is a v22.1 Magisk patched boot.img

00:44 <apritzel> vaughngx4: ah, which device did you dump it from? /dev/mmc.... or /dev/mtd... ?

00:45 <apritzel> I think you might not need a vendor DTB, those H3 devices are pretty straight-forward, as they typically don't contain a programmable PMIC

00:46 <apritzel> not having a UART is of course a pain, but I wonder if a basic "guessed" DTB would give you HDMI output already in U-Boot

00:47 <vaughngx4> apritzel: Oddly enough there was no such device. The only things I could find were /dev/block/by-name and /dev/block/nandX

00:47 <apritzel> ah yeah, Android

00:48 <apritzel> /dev/block/by-name is a symlink to the actual device, but /dev/block/nandX sounds indeed more like raw NAND flash rather than eMMC

00:49 <vaughngx4> apritzel: Yeah that's why I dumped all. It was /dev/block/nanda /dev...nandb etc.

00:49 <vaughngx4> apritzel: I did try a few existing configs but I'll try more and see if I get any output

00:51 <apritzel> try as basic as you can get: copy a config and a .dts, and remove as much as possible (but keep the system peripherals like GIC and timer, and clocks and pinctrl)

00:51 <apritzel> and of course the HDMI and de2 nodes

00:53 <apritzel> see if you can identify the DRAM chip (the BGA chip next to the CPU): to see whether it's DDR3 or LPDDR3

00:58 <vaughngx4> apritzel: I'll give that a go a bit later. It's almost 3AM here I should probably call it a night soon lol. Failing which, someone else mentioned that the fastboot key min and max I found after running "strings" on env.img (https://pastebin.com/5DjTn5Ru) look like lradc values I might just have to do something very hacky to get into fastboot

01:16 <vaughngx4> apritzel: It's a GCAI GDB41A32ED7-D2S and I can't find anything about it online. I really appreciate the assistance thank you so much. I'll be back soon. Hopefully I'll catch you again.

14:35 <loki666> So I've pinned down the kernel panic and other random instabilities of tokyovigilante's hack branch to the inclusion of dtb dvfs opp

14:36 <loki666> I don't know if I'm missing something from TFA or uboot

14:37 <loki666> Using TFA v2.10 and tokyovigilante uboot rg35xx-upstream-extras branch

14:37 <loki666> I'm testing on a RG35XX H

16:10 <apritzel> loki666: there shouldn't be any dependency on U-Boot or TF-A when it comes to DVFS

16:10 <apritzel> but it might be worth rebasing your branch onto v6.10-rc1, which contains the official and final cpufreq patches

17:40 <loki666> v6.11-rc1 you mean?

23:43 <tokyovigilante> loki666: I have found specific bins of the opp table do cause instability, and have disabled those specific ones in my testing, that's why I haven't wanted to push support for the RG35XX yet. My plan is to look at that once I send the LCD/TCON/DE patches which either need to go together or closely sequentially