Skip to content

Add moes wcm-p52 - #80

Open
PeterBeklemishev wants to merge 2 commits into
OpenIPC:masterfrom
PeterBeklemishev:add-moes-wcm-p52
Open

Add moes wcm-p52#80
PeterBeklemishev wants to merge 2 commits into
OpenIPC:masterfrom
PeterBeklemishev:add-moes-wcm-p52

Conversation

@PeterBeklemishev

@PeterBeklemishev PeterBeklemishev commented Mar 8, 2026

Copy link
Copy Markdown
Contributor

Moes WCM-P52 (T31L / sc3336 (3338))

https://www.moestech.com/blogs/news/wcm-p52?_pos=1&_sid=79e9a1a1e&_ss=r

Other variations exists under same model (at least on anyka #36)

Known problems:

  • GPIO for reset btn - not identified
  • GPIO for mmc power - not identified
  • GPIO for wifi power - not identified
  • "Call" btn (on the stationary part of the camera) is connected to adc pin (ADC_AUX0), which appears to be not muxable as regular GPIO - ????

original fw dump: https://t.me/c/1247643198/259055/341894

@PeterBeklemishev

Copy link
Copy Markdown
Contributor Author
image image

@BasicallyBubba

Copy link
Copy Markdown

Here is another sample of direct-from-factory firmware.
http://bubber.me/filez/moescam_new.bin

@openipc-ai openipc-ai left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for this, and I'm sorry it sat six months without a word — that is on us, not on you. Reviewed against master e0a643f with a firmware checkout at 9e7cf5b.

The hardware description looks right and is internally consistent: led1=16 matches gpio clear 16 in muxes.sh, light_ir=6 matches .nightMode.backlightPin 6, and motors= matches fw_setenv gpio_motors. muxes.sh is a real hook too — S30customizer runs /usr/share/openipc/muxes.sh when present. What needs fixing is mostly where things were put, and none of it needs the camera on your desk.

Since you opened this, a close sibling landed in-tree worth diffing against: t31_lite_tuya-gv7630-t31-ptz — T31L, ATBM USB Wi-Fi, 8M NOR, PTZ.

1. The kernel CONFIG_* lines in the defconfig do nothing — just delete them.

CONFIG_CFG80211*, CONFIG_MAC80211* and CONFIG_MFD_JZ_* are Linux kconfig symbols, not Buildroot ones, so in a *_defconfig they are unknown symbols and are dropped when the config is loaded. They came out of the kernel config verbatim — lines 540-561 and 1173-1175 of br-ext-chip-ingenic/board/t31/t31.generic.config.

You do not need to move them anywhere, because the stock t31.generic.config your defconfig already points at has every one of them at exactly those values:

540:CONFIG_CFG80211=m
551:CONFIG_MAC80211=m
1173:CONFIG_MFD_JZ_SADC_V13=y
1175:CONFIG_MFD_JZ_TCU=y

So the whole block comes out with nothing to replace it.

2. The exclude list is never read — and the correct one would delete your own sensor.

general/scripts/rootfs_script.sh picks the list by SoC model and variant:

LIST="${BR2_EXTERNAL_GENERAL_PATH}/scripts/excludes/${OPENIPC_SOC_MODEL}_${OPENIPC_VARIANT}.list"

Your defconfig sets BR2_OPENIPC_SOC_MODEL="t31", so the file has to be t31_lite.list. t23_lite.list is never opened, and its contents are T23 paths (/etc/sensor/*-t23.bin, 3.10.14__isvp_swan_1.0__ modules) that would not match on a T31 image anyway. On an 8M NOR board you do want this working.

Start from devices/t31_lite_tp-link-tapo-tc70-v3/general/scripts/excludes/t31_lite.list, but delete the two lines for your own sensor first — it strips /etc/sensor/sc3338-t31.bin and /etc/sensor/sc3338.yaml, and the WCM-P52 is SC3338, so copying it as-is costs you video. rootfs_script.sh prints excludes: N of M entries matched no file, so the build log will tell you if the list is aimed at the wrong tree.

3. Self-update is commented out. The URL in customizer.sh is correct — it matches the directory name, which is exactly what CI renames the artifact to — it is just commented. Uncomment it.

4. Wi-Fi. Two things:

  • BR2_PACKAGE_ATBM_WIFI_USB_PID=0x888B is not a Kconfig symbol; nothing in the tree declares it, so it is dropped along with the kernel lines. atbm-wifi.mk does consume it as CONFIG_ATBM_USB_PID, but only inside ifeq ($(BR2_PACKAGE_ATBM_WIFI_INTERFACE_USB),y), which this defconfig also does not set. Add BR2_PACKAGE_ATBM_WIFI_INTERFACE_USB=y — that is what ssc333_lite_tp-link-tapo-c110-v26 does for the same 6012B part. If the module genuinely needs PID 0x888B rather than the driver default, that wants a small config BR2_PACKAGE_ATBM_WIFI_USB_PID added to firmware's general/package/atbm-wifi/Config.in; happy to help with that one. As written the line is silently inert.
  • The /etc/wireless/usb overlay replaces firmware's shared profile table with a copy that knows only your profile. It works, but the convention is a one-hunk firmware PR adding the profile to general/overlay/etc/wireless/usb — that is how atbm603x-t31-zte-k540 and atbm6012b-ssc333-tapo-c110 got there — after which the overlay disappears from this repo. While you are at it: the profile is named atbm601x-… but loads atbm6012b_wifi_usb, so atbm6012b-t31-moes-wcm-p52 would match the others.

5. resetd.sh cannot run as shipped. Two independent reasons: it is committed 0644, so rc.local's (resetd.sh …) & will not execute it; and gpio.conf sets button=-1, so it would log GPIO pin for resetd is not set and exit immediately. Either fill in the real pin and make it executable, or drop it and the rc.local line until the pin is known.

6. Motors: pick one package. You enable both BR2_PACKAGE_GPIO_MOTORS=y and BR2_PACKAGE_MOTORS=y. They are different stacks — motors installs camhi-motor, i2c-motor, xm-kmotor, xm-uart, ingenic-motor — and no device in the tree enables both. Your pin list is read by gpio-motors, so BR2_PACKAGE_MOTORS=y is dead weight on an 8M image. Also worth checking: fw_setenv ptz true matches nothing else in the tree — the GPIO PTZ boards use ptz_control gpio together with ptz_gpio '<pins>' (ptz_gpio is the current name for the pin list, gpio_motors is the legacy one and still works).

7. Drop BR2_PACKAGE_JSONFILTER=y. #128 removed it from all 97 defconfigs after firmware/#2304 — it drags in libubox for nothing unless uqmi-openipc or wifibroadcast-ng is enabled, and it had three boards over their rootfs cap. That matters on 8M NOR.

The majestic respawn loop in rc.local is fine mechanically (busybox here is built with CONFIG_ASH_BASH_COMPAT=y, so [[ ]] works), but it is a generic band-aid in a device overlay. If majestic is dying on this board I would rather find out why than restart it every 30 seconds — not a blocker either way.

Last thing: device registration is automatic now. Since #120 the CI matrix is read off the tree, so a rebase and push is enough to get t31_lite_tuya-moes-wcm-p52 built here for the first time, narrowed to just your device.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants