[zhh_2007]

I think you haven't read that AMLUtils.ccp carefully at all. Look at the implementation of aml_get_cputype(). It is naive. There's no detection for m8, yet. Checking for !=8 will get you nowhere since that function will never return 8. It should return -1 since m8 is "unsupported", so the patch should be just fine. It's essentially, "Don't touch unsupported AML SOCs."

EDIT: I authored the patch.

Really?

int aml_get_cputype()
{
static int aml_cputype = -1;
if (aml_cputype == -1)
{
std:tring cpu_hardware = g_cpuInfo.getCPUHardware();

// default to AMLogic M1
aml_cputype = 1;
if (cpu_hardware.find("MESON-M3") != std:tring::npos)
aml_cputype = 3;
else if (cpu_hardware.find("MESON3") != std:tring::npos)
aml_cputype = 3;
else if (cpu_hardware.find("Meson6") != std:tring::npos)
aml_cputype = 6;
else if (cpu_hardware.find("Meson8") != std:tring::npos)
aml_cputype = 8;
}

return aml_cputype;
}
It can't be -1 because cpu freq and governor were changed successfully.
But I am not sure about what it returns.

[althekiller]

Proper fix should be in https://github.com/xbmc/xbmc/pull/5035

[zhh_2007]

Proper fix should be in https://github.com/xbmc/xbmc/pull/5035

Thank you very much.
By the way, can amcodec support rmvb in recent builds?

[MrMC]

XBMC's amcodec will never support rmvb without major work. The reason is the native amcodec wants rmvb packets in rmvb format and that is not what ffmpeg demuxer delivers. You need to a) reconstruct proper rmvb file format from ffmpeg demux or b) modify ffmpeg. Both require complete understanding of rmvb format.

[stane1983]

I think you haven't read that AMLUtils.ccp carefully at all. Look at the implementation of aml_get_cputype(). It is naive. There's no detection for m8, yet. Checking for !=8 will get you nowhere since that function will never return 8. It should return -1 since m8 is "unsupported", so the patch should be just fine. It's essentially, "Don't touch unsupported AML SOCs."

EDIT: I authored the patch.

EDIT2: Whoops, looks like I did that patch against a Gotham branch... Whoever added the m8 support in master didn't take the time to check what this might affect.

Guilty as charged Most of M8 and 4k patches for Aml are mine and forgot to check AMLUtils. Since t-nelson is working now on modifications for aml platform, I'll just point to him to change this part of code.

On the other side, I did not notice any lags in firmware usage (both Android and Linux) on M8. I'm using Gotham 13.1 + all aml patches from master.

[zhh_2007]

I think you haven't read that AMLUtils.ccp carefully at all. Look at the implementation of aml_get_cputype(). It is naive. There's no detection for m8, yet. Checking for !=8 will get you nowhere since that function will never return 8. It should return -1 since m8 is "unsupported", so the patch should be just fine. It's essentially, "Don't touch unsupported AML SOCs."

EDIT: I authored the patch.

EDIT2: Whoops, looks like I did that patch against a Gotham branch... Whoever added the m8 support in master didn't take the time to check what this might affect.

Guilty as charged Most of M8 and 4k patches for Aml are mine and forgot to check AMLUtils. Since t-nelson is working now on modifications for aml platform, I'll just point to him to change this part of code.

On the other side, I did not notice any lags in firmware usage (both Android and Linux) on M8. I'm using Gotham 13.1 + all aml patches from master.

Really? Some guys told me they noticed lag too.
After xbmc started, the cpu freq seemed out of control and fps was lower than 25.
Are you using a rooted m8 box?

[stane1983]

I think you haven't read that AMLUtils.ccp carefully at all. Look at the implementation of aml_get_cputype(). It is naive. There's no detection for m8, yet. Checking for !=8 will get you nowhere since that function will never return 8. It should return -1 since m8 is "unsupported", so the patch should be just fine. It's essentially, "Don't touch unsupported AML SOCs."

EDIT: I authored the patch.

EDIT2: Whoops, looks like I did that patch against a Gotham branch... Whoever added the m8 support in master didn't take the time to check what this might affect.

Guilty as charged Most of M8 and 4k patches for Aml are mine and forgot to check AMLUtils. Since t-nelson is working now on modifications for aml platform, I'll just point to him to change this part of code.

On the other side, I did not notice any lags in firmware usage (both Android and Linux) on M8. I'm using Gotham 13.1 + all aml patches from master.

Really? Some guys told me they noticed lag too.
After xbmc started, the cpu freq seemed out of control and fps was lower than 25.
Are you using a rooted m8 box?

I'm creating firmwares for Amlogic devices.... and yes, they are rooted

[zhh_2007]

I have tried jul 18 nightly build.
LAG!!!!!

---

Perhaps we should not chmod 666 any cpu related flie.

[zhh_2007]

system("su -c chmod 666 /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq");
system("su -c chmod 666 /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq");
system("su -c chmod 666 /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor");

---

codes above cause lag
I have tested them on terminal.

[stane1983]

system("su -c chmod 666 /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq");
system("su -c chmod 666 /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq");
system("su -c chmod 666 /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor");

---

codes above cause lag
I have tested them on terminal.

Fix is already merged in mainline, check here.

[zhh_2007]

system("su -c chmod 666 /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq");
system("su -c chmod 666 /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq");
system("su -c chmod 666 /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor");

---

codes above cause lag
I have tested them on terminal.

Fix is already merged in mainline, check here.

I know xbmc won't change freq now, but changing permissions of those files causes lag too.

---

Plese check void aml_permissions
I think we should move those lines to somewhere after line 202.

[zhh_2007]

It will be fixed soon. I thank everybody who replied. Great job!