Hello Brandon,

Do you have any updates regarding the booting issue?

Thanks!

    Hi pikelcw ,

    Sorry about not circling back. Have been underwater overall. I could not figure out how/why this is happening. It seems to actually have something to do with the CM4 modules themselves, as far as I can tell. And specifically, if they are eMMC or uSD.

    We can send you one of these to address it for sure if that works for you:

    If so please shoot an email to support@luxonis.com and we'll get one sent your way.

    Thanks,
    Brandon

      Hello Brandon

      I have tried the exact same HDMI Dummy Plug. But I am still not able to boot with that plugged in.
      Any other suggestions?

      Thanks

      Shoot. So odd. We could try sending you another one? I'm not sure what makes some refuse to boot w/out HDMI and others don't have a problem.

        Brandon
        Do you mind sharing your whole /boot/config.txt?
        I want to double-check if I have changed anything that I should not.

        Thanks

          pikelcw

          Great question. I trashed mine unfortunately so I don't have working config right now. Was testing something else and corrupted the SD-Card. Will ask for others on the team to share.

          @pikelcw I tried to use the CM4 without HDMI and couldn't boot it up too, same after sudo rpi-update. Also hdmi_safe or hdmi_force_hotplug flags didn't work, tried disabling desktop GL driver, setting default desktop resolution (both via raspi-config or manually editing /boot/config.txt ) or even disabling HDMI completely and setting the default to composite output.

          I'll investigate with the team further and circle back with more details. Seems that the OS is not booting at all without HDMI, but here is the /boot/config.txt I used if needed for reference

          As another update it is seeming that this does depend on the CM4 module itself. With a given module we could not get HDMI boot on one module, and it would boot on the other - and this followed the CM4 module itself - no matter what Luxonis board we put it on. Even across different revisions of the Luxonis carrier board.

          Test we did below:

          Two OAK-D-CM4 (DM1097_R0M0E0), both equipped with the same CM4-Lite WiFi capable Raspberry CM4 modules.
          I have tested both with the same uSD card one after another:

          • first OAK-D-CM4 1 with CM4 Lite module 1 I was able to boot it without the HDMI attached, and the LED works as on the CM3 in your case.
          • second OAK-D-CM4 2 with CM4 module 2 won't boot and the ACT LED does not blink at all as you observed (tested with the same uSD)
          • after this test I swapped the CM4 modules on both devices and now the first device 1 with CM4 module 2 won't boot and the device 2 with CM4 module 1 will

          So it has to be related to CM4 module, not sure but might be related to CM4 bootloader as there probably are some deviations across the different CM4 modules.

          We're wondering if some of the modules simply need a bootloader update. We're investigating in this direction:

          https://github.com/raspberrypi/rpi-eeprom/blob/master/firmware/release-notes.md

            4 days later

            Hello Brandon

            I just tried using the same CM4, that was on my OAK-D-CM4, with another carrier board(PITray mini). And it booted without HDMI connected to it.
            Does that mean that it is not the bootloader's issue?

            Thanks

              pikelcw Oh that's great to know!

              Can you share a link for purchasing that one? We'd like to compare.

                We looked into this issue thoroughly today and we found out that it is actually not related directly to the HDMI connected or not, as we first thought that if it is not a bootloader it must be something with HDMI interface signaling/detection.
                But the issue really lies somewhere else, that is in the power up procedure. We found out that Raspberry Pi CM4 datasheets states that

                All pins should not have any power applied to them before the +5V rail is applied.

                We come to that when seeing that device boots up successfully w/out HDMI connected, if the PSU is immediately reattached to the barrel jack connector after disconnection (in ms), or sometimes when PSU is first connected to the jack and after that to wall plug.


                To get to the point; we are using external power supply for 3V3 rail which is connected to the RPi CM4 module over pull-up resistors on the input/output signals going to/from the CM4 module.
                After 5V is applied, it seems that the 3V3 rail rises to quick (1ms) and kind of a latch-up happens.
                We modified the hardware enabling the PMIC with 3V3 generated from RPi, that way ensuring 3V3 power rail voltage will always rise later than 5V is supplied. That resulted in all boards boot up without HDMI connected, no matter the version,, CM4 module variant used... It boots, if we are using CM4 Lite with uSD and booting from there, or if we attach the CM4 with eMMC, booting from eMMC.
                Modification that works for now: removed the 10k PU from EN pin on PMIC, and connected EN pin to CM4_3V3 rail.

                We believe that the reason for that some of the CM4 modules booted - no matter what Luxonis board we used it on (Luxonis carrier board) while some didn't, is that we were/are really on the edge here with this issue.
                On the other hand and we are not aware of the exact boot procedure on the CM4 and what causes the latch before boot, so can not explain the real reason behind this.
                Nevertheless in the Raspberry PI compute module datasheet is clearly stated that none of the pins, on a CM4 module, should have any power applied to them before the +5V rail is applied. We are also not sure about why connecting the HDMI cable solves this issue, it could be that the CM4 has different boot procedure when HDMI is connected or not.

                To close that up, we will update the design and we can also offer sending a reworked unit for now for everyone affected by this issue.
                We are sorry for any inconvenience brought in by this issue.

                Best regards David,
                Luxonis lead EE

                  (We'll rework a unit and send it to you... future production will have this design fix.)