Skip to content

Commit

Permalink
h616: some readme cleanup
Browse files Browse the repository at this point in the history
  • Loading branch information
hexdump0815 committed Sep 14, 2023
1 parent ebf1f3e commit 0db0111
Showing 1 changed file with 4 additions and 4 deletions.
8 changes: 4 additions & 4 deletions systems/allwinner_h616/readme.md
Original file line number Diff line number Diff line change
Expand Up @@ -45,14 +45,14 @@
- sound is not working, wifi, bluetooth and sometimes even ethernet might work or might not work depending on the tv box
- as allwinner socs always boot by default from sd card the emmc can safely be overwritten (but do a backup of the original android system via dd command beforehand - it might be useful later)
- a suitable dtb should be chosen in /boot/extlinux/extlinux.conf (maybe even trying them all to see which works best - default is x96q)
- in the extra dir of the boot partition are a few different boot block options which might be worth a try - for h618 based tv boxes boot-allwinner_h616-axp313a.dd might work - those boot blocks have to be written via "dd if=boot-xyz.dd of=/dev/sd_card_device bs=512 seek=1 skip=1" to the sd card after writing the image to it
- there seem to be newer (as 2022 or newer maybe) h313/h616 tv boxes which use lpddr3/lpddr4 memory and partially also slightly different soc versions and thuse will not boot at all with those images here for now (see https://oftc.irclog.whitequark.org/linux-sunxi/2023-03-27#32013409 and arround for more info)
- panfrost opengl gpu acceleration does not seem to work completely stable yet, thus it is disabled by default
- if panfrost is enabled there are some visual glitches visible like for instance a missing font for the input field of the login window (this seems to be better with the latest v5.18 kernel and v22.1 mesa)
- the whole system seems to be a bit unstable depending on the hardware, it might be require to disable more of the higher freq opp points in the dtb to get more stability
- it looks like gpu frequency scaling does not work properly yet resulting in gpu errors like "gpu sched timeout", "AS_ACTIVE bit stuck" or page faults, what seems to help is to lock the gpu freq to just a single one for now by echoing a freq from /sys/class/devfreq/1800000.gpu/available_frequencies to both /sys/class/devfreq/1800000.gpu/min_freq and /sys/class/devfreq/1800000.gpu/max_freq (maybe in rc.local or similar) - 250000000 seems to work (others most probably as well)
- if panfrost is enabled there are some visual glitches visible like for instance a missing font for the input field of the login window, this should be no longer relevant for the newwer images
- if the whole system seems to be a bit unstable depending on the hardware, it might be require to disable more of the higher freq opp points in the dtb to get more stability (see experimental box dtb section below)
- it looks like gpu frequency scaling does not work properly yet resulting in gpu errors like "gpu sched timeout", "AS_ACTIVE bit stuck" or page faults, what seems to help is to lock the gpu freq to just a single one - see the corresponding section in /etc/rc.local
- it looks like its a good idea to disable any power management options for the display in the power manager, as otherwise xorg seems to get into a strange state (no more xorg, but console output instead on vt7 - all this without any error or traces) when the power management kicks in
- there are some experimental box dtb files for three voltage levels: around normal voltage levels, 30mv and 60mv overvoltage added
- the higher the overvoltage the higher is the chance it will work on lower quality socs at the cost of shorter lifetime, higher temperature and higher energy consumption
- the cpu freqs for those box dtb files is limited to 1.2 ghz by default to make it hopefully run with the lowest quality devices, this limit can be raised in /etc/rc.local to whatever is possible to still get a stable system (instability might mean a non booting system or the system crashin after a few days in the end)
- a good procedure is to start with the 60mv dtb and if it is stable either go to the 30mv or normal dtb (if low temperature, energy consumption and long life time is the goal) or to start raising the max cpu freq (if max performance is the goal) - both approaches can also be mixed to end up somewhere in the middle or in case the soc is of higher quality, i.e. going from 60mv to 30mv after still being stable at 1.8ghz and then raising the max cpu freq again ...
- for h618 based tv boxes the boot-allwinner_h616-axp313a.dd boot blocks from the extra dir of the boot partition might work, it has to be written via "dd if=boot-allwinner_h616-axp313a.dd of=/dev/sd_card_device bs=512 seek=1 skip=1" to the sd card after writing the image to it

0 comments on commit 0db0111

Please # to comment.