gk7205v300 + imx335 — updates newer than nightly-20260913-910e724 do not work correctly #2439

Activity

1. widgetii commented on Sep 18, 2026

   

   widgetii

   on Sep 18, 2026

   Member

   More actions

   Sorry — the command I sent you earlier was wrong: BusyBox tar has no -j. Use bzcat. Everything below is now verified end to end on a gk7205v300 + IMX335 here.

   Why a majestic binary and not a firmware image

   You were right that there is no nightly-20260914 in the list — the firmware nightly did not publish that day. The majestic binary did. So the exact midpoint between your good 09-13 and your bad 09-15 is reachable without reflashing anything: 30 commits, split into 17 and 13.

   Stay on the firmware you trust (nightly-20260913-910e724) and swap only majestic:

   cd /tmp
   curl -sLo m.tar.bz2 'https://openipc.s3-eu-west-1.amazonaws.com/majestic.gk7205v200.lite.master.tar.bz2?versionId=M1EZFDKpRCh3LmEepaHfulnxy32OUZlX'
   bzcat m.tar.bz2 | tar -x
   chmod +x /tmp/majestic-gk7205v200/majestic
   /tmp/majestic-gk7205v200/majestic --version

   Expected: Lite HiSilicon (gk7205v200), master+b54735d, 2026-09-14 17:32. If that line is right:

   /etc/init.d/S95majestic stop
   cp /tmp/majestic-gk7205v200/majestic /usr/bin/majestic
   /etc/init.d/S95majestic start
   majestic --version

   Copy only majestic. The tarball also contains a majestic.yaml — do not copy that one, it would overwrite your settings.

   Then use the camera as usual and tell us which happened:

   • black within the usual 30 minutes → the change is in 09-13..09-14 (17 commits)
   • several hours clean → the change is in 09-14..09-15 (13 commits)

   Either answer halves the search and we can go to individual commits from there.

   Putting it back

   Same recipe, different versionId — no reflash and no backup needed:

   build	versionId	reports
   09-13, your known-good	OP5L7k91Fb7JdDM6xTEP713xLm7ljSw1	master+98b8049
   09-15, your known-bad	yTcLV3Rr1f7ojlYa9qqcZFRURnyWIkrW	master+ad673e2

   All three were downloaded, extracted and run on this hardware before being suggested.

   About the i2c errors — they are not your wiring

   On a lab gk7205v300 + IMX335 set to your exact build, your memory layout (mmz_allocator=cma mmz=anonymous,0,0x44000000,64M) and your settings (5M_imx335.ini, isp.blkCnt: 4, jpeg off, h265 2592x1944 + 1280x960, mirror+flip, automatic day/night on pins 11/10), the same burst appeared on its own after a couple of hours:

   15:07:53  Nameserver 1.1.1.1:53 has failed: request timed out
   15:07:53  dns_cb result 67, retrying
   15:07:54  Change mode to NIGHT
   15:07:54  set_gpio(11, 1) / set_gpio(10, 0)
   15:07:55  goke-i2c 12060000.i2c: wait idle abort!, RIS: 0x611      x23
   15:07:55  [sensor_i2c_write 112] i2c_master_send error, ret=-5     x23
   15:08:17  All nameservers have failed
   

   That is the same three things arriving together — night switch, sensor-bus storm, DNS stall — that your 17.09 log shows at 13:48. So it reproduces here, and it is not something particular to your board.

   What has not reproduced here yet is the black picture itself. That is exactly why your half-hour is worth more than a day of ours, and why the test above is the thing that will actually settle it.

   ---

   По-русски

   Извините — команда, которую я присылал раньше, была неверной: в BusyBox у tar нет опции -j. Нужно использовать bzcat. Всё, что ниже, проверено целиком на gk7205v300 + IMX335 здесь.

   Почему бинарник majestic, а не образ прошивки. Вы были правы: сборки прошивки nightly-20260914 действительно нет — в тот день ночная сборка прошивки не публиковалась. А вот бинарник majestic за 14-е есть. Значит ровная середина между вашим рабочим 13-м и нерабочим 15-м достижима вообще без перепрошивки: 30 коммитов делятся на 17 и 13.

   Оставайтесь на прошивке, которой доверяете (nightly-20260913-910e724), и подмените только majestic:

   cd /tmp
   curl -sLo m.tar.bz2 'https://openipc.s3-eu-west-1.amazonaws.com/majestic.gk7205v200.lite.master.tar.bz2?versionId=M1EZFDKpRCh3LmEepaHfulnxy32OUZlX'
   bzcat m.tar.bz2 | tar -x
   chmod +x /tmp/majestic-gk7205v200/majestic
   /tmp/majestic-gk7205v200/majestic --version

   Ожидается: Lite HiSilicon (gk7205v200), master+b54735d, 2026-09-14 17:32. Если строка версии верная:

   /etc/init.d/S95majestic stop
   cp /tmp/majestic-gk7205v200/majestic /usr/bin/majestic
   /etc/init.d/S95majestic start
   majestic --version

   Копируйте только majestic. В архиве есть ещё majestic.yaml — его копировать не надо, он перезапишет ваши настройки.

   Дальше просто пользуйтесь камерой и напишите, что получилось:

   • чёрный экран в привычные 30 минут → изменение в диапазоне 13–14 сентября (17 коммитов)
   • несколько часов без проблем → изменение в диапазоне 14–15 сентября (13 коммитов)

   Любой из ответов вдвое сокращает поиск, дальше дойдём до отдельных коммитов.

   Вернуть как было — та же последовательность, другой versionId, без перепрошивки и без резервной копии:

   сборка	versionId	версия
   13-е, ваша рабочая	OP5L7k91Fb7JdDM6xTEP713xLm7ljSw1	master+98b8049
   15-е, ваша нерабочая	yTcLV3Rr1f7ojlYa9qqcZFRURnyWIkrW	master+ad673e2

   Все три скачаны, распакованы и запущены на этом железе перед тем, как предлагать.

   Про ошибки i2c — это не ваша пайка. На лабораторной gk7205v300 + IMX335, настроенной на вашу сборку, вашу разметку памяти (mmz_allocator=cma mmz=anonymous,0,0x44000000,64M) и ваши настройки (5M_imx335.ini, isp.blkCnt: 4, jpeg выключен, h265 2592x1944 + 1280x960, mirror+flip, автоматический день/ночь на пинах 11/10), такая же пачка появилась сама через пару часов — переключение в ночь, шторм на шине датчика и отвал DNS приходят вместе, ровно как в вашем логе от 17.09 в 13:48.

   Чего здесь пока не удалось воспроизвести — это самой чёрной картинки. Именно поэтому ваши полчаса стоят больше, чем наши сутки.
2. Dionisgr commented on Sep 19, 2026

   

   Dionisgr

   on Sep 19, 2026

   Last edited by Dionisgr

   Author

   More actions

   I performed a test of Majestic master+b54735d, 2026-09-14 17:32. The result: 30 minutes and then a black screen again. At 07:51:34 the camera started, at 08:21:48 — black screen. On the recorder, it simply turns into a black screen with OSD, no artifacts. Logs attached

   root@Parking-cam:~# cd /tmp
   root@Parking-cam:/tmp# curl -sLo m.tar.bz2 'https://openipc.s3-eu-west-1.amazonaws.com/majestic.gk7205v200.lite.master.t
   ar.bz2?versionId=M1EZFDKpRCh3LmEepaHfulnxy32OUZlX'
   root@Parking-cam:/tmp# bzcat m.tar.bz2 | tar -x
   root@Parking-cam:/tmp# chmod +x /tmp/majestic-gk7205v200/majestic
   root@Parking-cam:/tmp# /etc/init.d/S95majestic start
   Starting majestic: OK (already running)
   root@Parking-cam:/tmp# majestic --version
   Lite HiSilicon (gk7205v200), master+98b8049, 2026-09-13 17:28
   root@Parking-cam:/tmp# /tmp/majestic-gk7205v200/majestic --version
   Lite HiSilicon (gk7205v200), master+b54735d, 2026-09-14 17:32
   root@Parking-cam:/tmp# /etc/init.d/S95majestic stop
   Stopping majestic: OK
   root@Parking-cam:/tmp# cp /tmp/majestic-gk7205v200/majestic /usr/bin/majestic
   root@Parking-cam:/tmp# /etc/init.d/S95majestic start
   Starting majestic: OK
   root@Parking-cam:/tmp# majestic --version
   
   
   Lite HiSilicon (gk7205v200), master+b54735d, 2026-09-14 17:32
   

   

   majestic-logs fr13 m14.txt

   2026-09-19.08_21_50-2026-09-19.08_21_55.mp4
3. widgetii commented on Sep 19, 2026

   

   widgetii

   on Sep 19, 2026

   Member

   More actions

   We found it, and it is not your hardware. Here is a build with the fix, if you are willing to run one more test.

   What it turned out to be

   The sensor's clock was being switched off underneath a running pipeline. One bit, in one register.

   0x120100F0, bit 0 (sensor0_cken) on your SoC family:

   healthy   0x00000011
   broken    0x00000010    <- clock off
   

   A sensor with no clock cannot answer i2c at all, which is why the kernel prints i2c_master_send error, ret=-5 — the driver is talking to a sensor that has stopped listening. The encoder keeps running on the last frame it latched, so you get a frozen/black picture with the OSD still drawn on it, and only a pipeline rebuild fixes it — which is exactly why a reboot or any settings change brought it back.

   Reproduced here on a lab hi3516ev300 + IMX335 this morning, deterministically:

   07:44:04  pipeline up, clock 0x11
   08:14:04  clock 0x10        <- 1800 seconds later, to the second
   08:14:07  [sensor_i2c_write 112] i2c_master_send error, ret=-5 ...
   

   1800 seconds is thirty minutes. majestic's telemetry sends its first report 30 minutes after start and every 6 hours after that, and to fill in one field it asked the sensor over i2c who it was. That probe switched the clock off and did not put it back. Your own numbers — 30 minutes, 30 minutes, 30 minutes, and one run of 6 hours — are those two timers and nothing else. That is also why it looked like it depended on the firmware version: it always could happen, and a change in mid-September made the probe start arriving while the pipeline was streaming.

   Writing that one bit back by hand stopped 908 accumulated errors dead and brought the picture back instantly, with nothing else touched.

   The test build

   Same procedure you already ran — only the URL differs, and this one needs no versionId:

   cd /tmp
   curl -sLo m.tar.bz2 'https://openipc.s3-eu-west-1.amazonaws.com/majestic.gk7205v200.lite.sensor-clock-fix.tar.bz2'
   bzcat m.tar.bz2 | tar -x
   chmod +x /tmp/majestic-gk7205v200/majestic
   /tmp/majestic-gk7205v200/majestic --version

   Expected: Lite HiSilicon (gk7205v200), HEAD+483231119, 2026-09-19 08:12. Then:

   /etc/init.d/S95majestic stop
   cp /tmp/majestic-gk7205v200/majestic /usr/bin/majestic
   /etc/init.d/S95majestic start

   Copy only majestic — the archive also has a majestic.yaml which would overwrite your settings.

   This build has been started on a lab gk7205v300 first: both encoders come up and it streams, with the same memory footprint as the stock build.

   You no longer have to wait for a black screen

   You can watch the actual fault directly, which takes seconds instead of half an hour:

   devmem 0x120100F0

   • 0x00000011 — sensor clock on, healthy
   • 0x00000010 — this is the bug happening

   Worth checking about 35 minutes after a start, and again the next day. If it reads 0x...11 both times, the fix is holding. If you ever see 0x...10, that is the fault and the picture will be frozen.

   Back to stock

   cd /tmp
   curl -sLo g.tar.bz2 'https://openipc.s3-eu-west-1.amazonaws.com/majestic.gk7205v200.lite.master.tar.bz2?versionId=OP5L7k91Fb7JdDM6xTEP713xLm7ljSw1'
   bzcat g.tar.bz2 | tar -x
   /etc/init.d/S95majestic stop
   cp /tmp/majestic-gk7205v200/majestic /usr/bin/majestic
   /etc/init.d/S95majestic start

   Thank you for running the 14 September build — that measurement is what made this findable.

   ---

   По-русски

   Нашли, и это не ваше железо. Ниже сборка с исправлением, если готовы проверить ещё раз.

   Что оказалось. У сенсора выключался тактовый сигнал прямо под работающим конвейером. Один бит в одном регистре: 0x120100F0, бит 0 (sensor0_cken) — 0x00000011 норма, 0x00000010 поломка. Сенсор без такта не отвечает по i2c вообще, отсюда i2c_master_send error, ret=-5: драйвер обращается к сенсору, который перестал слушать. Энкодер продолжает работать на последнем кадре, поэтому картинка замирает с наложенным OSD, и помогает только пересборка конвейера — ровно поэтому перезагрузка или любое изменение настроек всё чинило.

   Воспроизвели сегодня утром на лабораторной hi3516ev300 + IMX335, детерминированно:

   07:44:04  конвейер поднят, такт 0x11
   08:14:04  такт 0x10        <- ровно через 1800 секунд
   08:14:07  [sensor_i2c_write 112] i2c_master_send error, ret=-5 ...
   

   1800 секунд — это тридцать минут. Телеметрия majestic отправляет первый отчёт через 30 минут после старта и далее каждые 6 часов, и ради одного поля опрашивала сенсор по i2c. Этот опрос выключал такт и не возвращал его обратно. Ваши цифры — 30 минут, 30 минут, 30 минут и один прогон на 6 часов — это ровно эти два таймера.

   Сборка для проверки — та же процедура, что вы уже выполняли, только ссылка другая и versionId не нужен:

   cd /tmp
   curl -sLo m.tar.bz2 'https://openipc.s3-eu-west-1.amazonaws.com/majestic.gk7205v200.lite.sensor-clock-fix.tar.bz2'
   bzcat m.tar.bz2 | tar -x
   chmod +x /tmp/majestic-gk7205v200/majestic
   /tmp/majestic-gk7205v200/majestic --version

   Ожидается Lite HiSilicon (gk7205v200), HEAD+483231119, 2026-09-19 08:12. Затем:

   /etc/init.d/S95majestic stop
   cp /tmp/majestic-gk7205v200/majestic /usr/bin/majestic
   /etc/init.d/S95majestic start

   Копируйте только majestic — в архиве есть ещё majestic.yaml, он перезапишет ваши настройки. Сборка предварительно запущена на лабораторной gk7205v300: оба энкодера поднимаются, поток идёт.

   Теперь не нужно ждать чёрного экрана — саму неисправность видно сразу:

   devmem 0x120100F0

   0x00000011 — такт включён, всё хорошо; 0x00000010 — это и есть баг. Имеет смысл посмотреть минут через 35 после старта и потом на следующий день.

   Вернуться на штатную сборку — та же последовательность с versionId=OP5L7k91Fb7JdDM6xTEP713xLm7ljSw1 (это ваша рабочая от 13 сентября).

   Спасибо, что прогнали сборку от 14 сентября — именно это измерение и позволило это найти.
4. widgetii

   added a commit that references this issue on Sep 19, 2026

   hal: a sensor clock we did not turn on is not ours to turn off (#219)

   ...

   034298e
5. Dionisgr commented on Sep 20, 2026

   

   Dionisgr

   on Sep 20, 2026

   Last edited by Dionisgr

   Author

   More actions

   The cameras worked normally for 24 hours, 0x00000011 did not change. The issue can be considered resolved.
   But when updating from version nightly-20260913-910e724 on another camera via sysupgrade --build=nightly-20260919-02d6035, after 30 minutes there is a black screen. It turns out that in the majestic master+e0521b4, 2026-09-19 17:32, changes for the gk7205v300 were not included, or is this a problem specifically with my modules?
6. widgetii

   added a commit that references this issue on Sep 20, 2026

   hal: an entitlement must not outlive the probe that took it (#220)

   ...

   955e762
7. widgetii commented on Sep 20, 2026

   

   widgetii

   on Sep 20, 2026

   Member

   More actions

   Thank you for both halves of that — the 24-hour confirmation and the second camera. They are more useful together than either would be alone, because between them they caught a mistake of mine.

   Short answer to your question

   The gk7205v300 changes were included in nightly-20260919. I checked all three links: that build's majestic contains the fix, and it pins the fixed ipctool. It is not your modules.

   What happened is that I broke it again, a few hours after the build you tested.

   What the two cameras tell us

   camera	build	result
   the first	the build I gave you on 19 Sept, 08:12	0x00000011 held 24 h — correct
   the second	nightly-20260919, built 17:32	black after 30 min

   Between those two builds the fix went through code review, and I changed it in response to a review comment. That change was wrong.

   The original fix said: if the clock is already running when a probe starts, it is not ours, so leave it alone. Review pointed out this means a probe that had itself turned the clock on sometimes fails to turn it back off, and asked me to keep track of that case. I did — by checking whether the register still held the exact value we had written.

   It does. But so does the value the camera's own video pipeline writes. Both write 0x11. So that check cannot tell "our own change, still in place" from "the pipeline is simply running", and the old fault came straight back:

   boot          probe turns the clock on
   pipeline up   the SDK writes the same value
   t+30 min      next probe thinks the clock is still "ours"
                 and hands it back to off        <- black screen
   

   Your first camera never saw this because its build predates that change.

   Fixed

   OpenIPC/ipctool#220 is merged, restoring the original behaviour and pinning it with a test that replays your exact sequence — probe at boot, pipeline starts, probe thirty minutes later — and fails against the build you have. The majestic side follows now, and the next nightly will carry it.

   The trade the review was worried about is real but small: a probe that switches the clock on may leave it on. That costs microamps. Switching off a clock a running camera is using costs the picture, which is what you have been living with.

   If you want the second camera working before the next nightly

   The build you already proved over 24 hours is still the right one:

   cd /tmp
   curl -sLo m.tar.bz2 'https://openipc.s3-eu-west-1.amazonaws.com/majestic.gk7205v200.lite.sensor-clock-fix.tar.bz2'
   bzcat m.tar.bz2 | tar -x
   /etc/init.d/S95majestic stop
   cp /tmp/majestic-gk7205v200/majestic /usr/bin/majestic
   /etc/init.d/S95majestic start

   Or wait for the nightly after this lands. devmem 0x120100F0 tells you which state a camera is in without waiting for the picture to go: 0x00000011 good, 0x00000010 the fault.

   Sorry for the extra round trip — and thank you for testing the second camera rather than assuming the first result covered it. That is the only reason this was caught in a day.

   ---

   По-русски

   Спасибо за обе половины — и за подтверждение по 24 часам, и за вторую камеру. Вместе они поймали мою ошибку.

   Коротко по вашему вопросу. Изменения для gk7205v300 вошли в nightly-20260919 — я проверил все три звена. Дело не в ваших модулях. Просто я сломал это заново, через несколько часов после той сборки, которую вы тестировали.

   камера	сборка	результат
   первая	сборка от 19.09, 08:12	0x00000011 держится 24 ч — верно
   вторая	nightly-20260919, 17:32	чёрный экран через 30 минут

   Между этими двумя сборками исправление прошло ревью, и я изменил его по замечанию. Изменение было неверным.

   Исходное правило: если такт уже включён, когда начинается опрос, значит он не наш — не трогаем. Ревьюер заметил, что тогда опрос, который сам включил такт, иногда его не выключает обратно, и попросил это учесть. Я учёл — проверкой, что в регистре всё ещё ровно то значение, которое мы записали.

   Оно там. Но такое же значение записывает и сам видеоконвейер камеры. Оба пишут 0x11. Поэтому проверка не отличает «наше изменение ещё на месте» от «конвейер просто работает», и старая неисправность вернулась:

   загрузка      опрос включает такт
   конвейер      SDK пишет то же значение
   +30 минут     следующий опрос считает такт «нашим»
                 и возвращает его в выключенное состояние   <- чёрный экран
   

   Ваша первая камера этого не видела, потому что её сборка старше того изменения.

   Исправлено: OpenIPC/ipctool#220 влит, поведение возвращено, и закреплено тестом, который повторяет ровно вашу последовательность. Сторона majestic — следом, ближайший nightly это получит.

   Если хотите поднять вторую камеру до следующего nightly — та сборка, которую вы уже проверили сутками, по-прежнему правильная (команды выше). devmem 0x120100F0 показывает состояние сразу: 0x00000011 хорошо, 0x00000010 неисправность.

   Извините за лишний круг — и спасибо, что проверили вторую камеру, а не сочли, что первый результат всё покрывает. Только поэтому это нашлось за день.
8. Dionisgr

   closed this as completedon Sep 28, 2026