nightMode not toggling or reading gpios on hi3518ev100 about majestic HOT 6 CLOSED

ok after a bit more experimentation, this is certainly a pinmux'ing issues
when majestic starts, and I'm assuming it opens gpio ports, the pinmuxing is reset to 0 for the pins, which is wrong (at least for hi3518ev100) for gpio. Per datasheet, these should be set to 1 to use gpio function of these pins.

root@openipc-hi3518ev100:~# #GPIO9_1, GPIO73
root@openipc-hi3518ev100:~# devmem 0x200F00CC
0x00000000
root@openipc-hi3518ev100:~# #GPIO9_4, GPIO76 
root@openipc-hi3518ev100:~# devmem 0x200F00D8
0x00000000
root@openipc-hi3518ev100:~# #GPIO9_5, GPIO77
root@openipc-hi3518ev100:~# devmem 0x200F00DC
0x00000000
root@openipc-hi3518ev100:~# #GPIO9_7, GPIO79
root@openipc-hi3518ev100:~# devmem 0x200F00E4
0x00000000

Interestingly, after majestic is started, if I manually set the pinmuxes on these, it works.

root@openipc-hi3518ev100:~# devmem 0x200F00CC 32 0x1
root@openipc-hi3518ev100:~# devmem 0x200F00D8 32 0x1
root@openipc-hi3518ev100:~# devmem 0x200F00DC 32 0x1
root@openipc-hi3518ev100:~# devmem 0x200F00E4 32 0x1

But when majestic is restarted, the pinmuxes are reset to 0 (non-working).

I'm not sure what the convention is for these - if the pinmuxing is supposed to be set as a default on the OS, or if this is something the application (majestic) is supposed to do when opening gpio ports (but I have no idea how majestic is interacting with gpios, e.g. sysfs, devmem, syscalls, etc)
also unfortunately, these hi3518ev100/hi3516cv100 are stuck on a very ancient kernel (3.0.8), so not sure how much this might be related to why this isnt working

from majestic.

also possibly interesting
with majestic running a fresh config with no nightMode pins defined:

ipctool reginfo:

...
muxctrl_reg50 0x200f00c8 0x1 reserved [GPIO9_0]
muxctrl_reg51 0x200f00cc 0x1 reserved [GPIO9_1]
muxctrl_reg52 0x200f00d0 0x1 reserved [GPIO9_2]
muxctrl_reg53 0x200f00d4 0x1 reserved [GPIO9_3]
muxctrl_reg54 0x200f00d8 0x1 reserved [GPIO9_4]
muxctrl_reg55 0x200f00dc 0x1 reserved [GPIO9_5]
muxctrl_reg56 0x200f00e0 0x1 reserved [GPIO9_6]
muxctrl_reg57 0x200f00e4 0x1 reserved [GPIO9_7]
...

after setting majestic settings:

.nightMode.irSensorPin: 77
.nightMode.irCutPin1: 76
.nightMode.irCutPin2: 79
.nightMode.backlightPin: 73

when majestic restarts, output of ipctool reginfo:

muxctrl_reg50 0x200f00c8 0x1 reserved [GPIO9_0]
muxctrl_reg51 0x200f00cc 0x1 reserved [GPIO9_1]
muxctrl_reg52 0x200f00d0 0x1 reserved [GPIO9_2]
muxctrl_reg53 0x200f00d4 0x1 reserved [GPIO9_3]
muxctrl_reg54 0x200f00d8 0 [reserved] GPIO9_4
muxctrl_reg55 0x200f00dc 0x1 reserved [GPIO9_5]
muxctrl_reg56 0x200f00e0 0x1 reserved [GPIO9_6]
muxctrl_reg57 0x200f00e4 0 [reserved] GPIO9_7

it seems that something about the way majestic opens/configures the gpios/regs is causing the pinmux to get reset for the irCutPin1 & irCutPin2 pins

furthermore, enabling nightMode and night mode api, and then calling nightmode on also changes the pinmux registers in this way

muxctrl_reg50 0x200f00c8 0x1 reserved [GPIO9_0]
muxctrl_reg51 0x200f00cc 0 [reserved] GPIO9_1
muxctrl_reg52 0x200f00d0 0x1 reserved [GPIO9_2]
muxctrl_reg53 0x200f00d4 0x1 reserved [GPIO9_3]
muxctrl_reg54 0x200f00d8 0 [reserved] GPIO9_4
muxctrl_reg55 0x200f00dc 0 [reserved] GPIO9_5
muxctrl_reg56 0x200f00e0 0x1 reserved [GPIO9_6]
muxctrl_reg57 0x200f00e4 0 [reserved] GPIO9_7

from majestic.

ok after a bit of exploration into the majestic binary w/ cutter, I can see that there is some function which sets up the pin mux according to some configuration table in the code. (set_mux_reg, mux_gpio, ?).
If I patch the table for my muxctrl register addresses it works.

So I'm sure that this has to do with some hardcoded pinmux table in majestic codebase.
At least for hi3518 it seems like all the GPIO9_0 through GPIO9_7 should certainly have a pinmux value of 1, selecting the alternate "gpio" pin function, rather than the primary "nand flash data pins" function.

from majestic.

Thanks for your research, it looks impressive.
We will try to fix the issue soon and give you the information for testing.
In any case, we are very happy to have you with us.

from majestic.

looks like this has been resolved on recent builds of majestic master branch

from majestic.

Done

from majestic.