Possible bug in GXM device tree

I’m trying to find out the reason of sporadical freezes of my Vontar tx92 (1Gbit + 3Gb LPDDR). I’ve compared device trees from android firmware and gxm_q201_3g_1gbit.dtb from CE. I’ve found difference in operating-points. There is corresponding change: https://github.com/CoreELEC/linux-amlogic/commit/b489e8d11264c70dadd14fcd1f9bdaf3428fb15f
But looks like 125MHz have been removed from some tbl and 800MHz have been added twice.

-tbl = <&dvfs125_cfg &dvfs285_cfg &dvfs400_cfg &dvfs500_cfg &dvfs666_cfg>;
+tbl = <&dvfs285_cfg &dvfs400_cfg &dvfs500_cfg &dvfs666_cfg &dvfs800_cfg &dvfs800_cfg>;

Can this cause freezes?
The pattern for freezes is quite stable, it may freeze on boot, may freeze few minutes after start (only if I view film or stream something). But after that it will work without any problem.
I’ll apreciate any help.

It’s possible, but I’m not sure what frequency the GPU is rated for.
Anyway I recompiled the 9.0.1 DTB and removed the 792MHz option.
Give it a go and see if it helps your box’s stability.
gxm_q201_3g_1gbit.zip (11.2 KB)

Just wanted to say that i have a Vorke Z6 Plus which i believe is the identical device. For the past few months i have actually been using the q200 dtb for this device instead and everything has been working perfectly. (But i have to say i dont use wifi or bluetooth so if those have a problem i wouldnt know)

Thanks, I’ll try it out. I’ve talked not about 800MHz,but about 125, which is listed in operating points, but not in tbl

Is it 3Gb with LPDDR? And you haven’t experienced any problems? I’m already thinking about hardware issues

Memory speed can be the reason of freezes
Could you execute all commands and upload the output of 2nd command?

dd if=/dev/bootloader of=/storage/downloads/ddr_clk.bin bs=1 count=2 skip=41482
hexdump -e '"%d"' /storage/downloads/ddr_clk.bin
rm /storage/downloads/ddr_clk.bin
1 Like

The output is 1120. Is that the frequency? There is kenel parameter with another frequency androidboot.ddrclk=708MHz

If you have LPDDR than possible you need u-boot with lower values than 1120
See details about other boxes here.

You need to compile your own u-boot or try to use correct H96Pro+ uboot on your own risk. I can’t help with details in u-boot area more.

Thanks, I’ll try it out!

With a Clk.Rate of 1120Mhz, LPDDR3 memory initialization would not be possible. Either you have a DDR4-2400 memory, or you may have to move the bytes in the first command slightly. Make a dump of your bootloader partition and post it here.

1 Like

Thanks. My board is marked CS_912_TX92_LP_V1.0
From bad resolution photos from my phone I can see that mem is marked with PB049-107BT
Google shows that it seems to be lpddr3 (from forums).
I’ll make a dump at the evening. (is that just dd of my /dev/bootloader?)

I’ve dd’ed my bootloader

And here is a photo of the stack trace right after boot. I also have some uart logs, but they a quite corrupted. I think because of different logical levels.

I could not read the RAM frequency from your dump, but you definitely have a LPDDR3 memory. TX92 works well with the custom uboot, you can install the v5_v6 precompiled binary (@ 792Mhz) from CE-Git or compile your own. I do not believe that replacing the bootloader solves this problem. But you may need a script that cleans the RAM before it gets full.

1 Like

Could you please elaborate more on this? I’ve never ran out of memory (at least that’s what I think). The average RAM consumption is about 400MB out of 3GB. I’ve done memory tests with memtester, OOM killer works like a charm, if I pass more memory than currently free to memtester

Okay, that changes the situation. Do you have a chance to create the uart log? Are the two ranks really initialized properly? By a certain function in the uboot, the RAM memory size can be set to any value, this is then output as actual RAM size. This function uses e.g. the Beelink on its A/B706 … devices to make 2G -> 3g :). You must exclude this for the time being.

Here are my logs: dead after few minutes and successful
Sorry, but they are a little corrupted. I don’t know why my USB-TTL adapter works fine for other devices.
That’s on 115200 rate, I also tried other rates, bitness, all the options - nothing helped. Do you have any idea how to have them clean?

From logs I can see LPDDR3 cjl: Rank0+1 708MHz

U-Boot 2015.01-g192c172-dirty (Dec!07 2017 - 96:54:05)

DRAM:  3 GiB

Is that OK?

Rank0: 2048MB-2T-3

Rank1: 1024MB-2T-3

I think you’ve got me wrong about memtester. If I have 400MB occupied and run memtester - it fails, because tries to allocate 3GB. When I pass option to allocate 2.6GB - everything is fine and it can access to all the memory.

As I said freezes may occur only on/after start. After some “warm up” when I leave it idle for 5-10 minutes, it works all day long without any problem.

Remember, a certain memory area (about 200-300MB) is always reserved. In your case, you would not have been able to release the 2.6GB, since in fact only 2.7 ~ 2.8GB of total memory is available. Look at the “reserved-memory” node in the DTS file. According to your description, it looks more like a HW problem. First, try replacing the uboot, set the clock frequency between 720Mhz-792Mhz (always in 24Mhz steps), 744Mhz and 768Mhz, I would test in your place. Unfortunately I could not read your logs, use * .txt format.

The ranks look good…

Sorry, these are text logs, but without txt extension. I moved fail log to paste bin for convenience: log.
Yesterday I’ve update u-boot, but that does not help. I think that I should find out reason first :wink: .
That may be interesting to people with freezes:
I’ve investigated a little in possibility to persist panics. Our kernel have ramoops enabled, and it works. The only problem was that panics were freezing device and the only possibility to restart is to pull power cord out, but that purges ram.
Luckily setting echo -1 > /proc/sys/kernel/panic causes system to reboot instead of freezing (why don’t we have that as default?). Positive values (reboot after timeout) do not work. I’ve persisted that behaviour by echo 'kernel.panic = -1' > /etc/sysctl.d/00-panic.conf. Maybe it’s better to set that as kernel cmdline option.
Manual triggering of panic created dump, available after reboot in /sys/fs/pstore/. The only way I found to manully trigger panic is to set echo 1 > /proc/sys/vm/panic_on_oom and call memtester 3G :smile:.
Now I need to find out, how to read that dumps. And collect real failures.

To be continued…

You are using a 1.90GiB SDcard, which is very slow, you are guaranteed to have a big data jam about it :slight_smile: . Use at least one 16GiB SDcard.