New Pi Compute Modules Not Initializing

[bhjelstrom]

• 1.7.9
• Ubuntu 20.04, Win10
• No Dev Tools output

I have tested 7 new CM4s with HW revision c03141 and new bootloaders. The progress bar appears for the cm, but the cm is never mounted as a storage device and the progress bar remains at 0%.

The new CM4s function as expected only when I run the latest rpiboot manually. Assuming https://github.com/balena-io-modules/node-raspberrypi-usbboot needs an update.

lsusb:

  bLength                18
  bDescriptorType         1
  bcdUSB               2.00
  bDeviceClass            0 
  bDeviceSubClass         0 
  bDeviceProtocol         0 
  bMaxPacketSize0        64
  idVendor           0x0a5c Broadcom Corp.
  idProduct          0x2711 
  bcdDevice            0.00
  iManufacturer           1 
  iProduct                2 
  iSerial                 3 
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength       0x0020
    bNumInterfaces          1
    bConfigurationValue     1
    iConfiguration          0 
    bmAttributes         0xc0
      Self Powered
    MaxPower              100mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           2
      bInterfaceClass       255 Vendor Specific Class
      bInterfaceSubClass      0 
      bInterfaceProtocol      0 
      iInterface              0 
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x01  EP 1 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval               0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x02  EP 2 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval               0

[mcraa]

Thanks for sharing, we are working on it already.

[aessig]

@mcraa What should we do in the meantime?

[mcraa]

Sorry for the long reply, I don't know what you should do I only know what workaround is possible, similar to what we are working on. The CM4s should be a 2711 device. So you can clone the repos and hardcode it in node-raspberrypi-usbboot to always detect 2711. Then update it (locally) in the etcher-sdk, and update the etcher-sdk in etcher and build etcher for yourself. This version of etcher then would work only work with cm4 and cm4s. Or you can run your updated sdk directly like ts-node examples/usb-boot.ts <..args> without the struggle of building etcher.

It will probably take us this or the next week at least to test everything and make sure we don't break the support of any already supported devices.

[aessig]

@mcraa Thanks for your reply. Will try it.

[tosuns]

What is the current status of this issue? Do you guys have an idea when you will release a new version which contains a fix this issue ?

[fix3000]

Also here to poke. I can use rpiboot to work around the issue for now, but would be good to have the direct route back. It might be worth mentioning that "older" CM4s with a 2020 manufacturing date are directly recognized by balenaEtcher 1.7.9. It's the newer ones with a 2021 mfg date that I'm seeing the issue with. Suspecting there may be a newer bootloader when they roll off the line that's causing the issue.

This may not be the right place for this, but would any update also be usable on Etcher Pro?

I can do some limited testing if that's helpful; feel free to reach out.

[bhjelstrom]

I can confirm what @fix3000 is saying. To be clear, we are seeing this with 2021 and newer "CM4" units. There is a new "CM4-s" model that may or may not be detected, but I haven't tested the "CM4-s".

Shipping CM4 based products now so bumping again.

[mcraa]

Well, that name is confusing. CM4s meaning plural CM4, and CM4S as the new small format devices. Seeing "New Pi" and "CM4s" I thought about the new small devices, it is good to point out there are "normal" size devices which have the issue. cc @zwhitchcox

[lurch]

We've not added it to our general documentation (because CM4S is a limited-distribution product), but the CM4S has a Type code of 0x15 https://github.com/raspberrypi/documentation/pull/2557 (regular CM4 has Type code 0x14).

https://forums.raspberrypi.com/viewtopic.php?t=339279 has more info about the CM4 with revision code c03141.

[tosuns]

@lurch What is the meaning of "limited-distribution product" and what kind of implication does it have with lifetime and support ?

[lurch]

As it says on the CM4S product page:

Based on the Raspberry Pi 4 Model B architecture, Compute Module 4S is intended for specific industrial customers migrating from Compute Module 3 or Compute Module 3+ and is not for general sale. For new customers who are designing products, we recommend using Raspberry Pi Compute Module 4.

[fix3000]

I haven't seen any recent update here on this issue, but is it something that's being worked on? Or planned to be worked on?

We're reaching a decision point on how we're going to flash all these new CM4 devices we'll soon be getting. If we need to work out an alternate plan, that's ok, just want to get ahead of it.

[zwhitchcox]

Hey, we think we have identified the problem, but still needs more testing. I will post an update here hopefully very soon.

[fix3000]

That's good to hear, hope it progresses well. Thanks.

[iamk3]

Hey, we think we have identified the problem, but still needs more testing. I will post an update here hopefully very soon.

If you have a beta, I'd love to test it out. I'm bummed at the moment not being able to flash my two 32GB CM4.

[fix3000]

Hey, we think we have identified the problem, but still needs more testing. I will post an update here hopefully very soon.

If you have a beta, I'd love to test it out. I'm bummed at the moment not being able to flash my two 32GB CM4.

FYI, you can use rpiboot first to get the module mounted as storage and then use balenaEtcher to flash it.

I'd also be open to testing a beta if one is available.

[bhjelstrom]

Also applies to a03141 units

[iamk3]

Hey, we think we have identified the problem, but still needs more testing. I will post an update here hopefully very soon.

If you have a beta, I'd love to test it out. I'm bummed at the moment not being able to flash my two 32GB CM4.

FYI, you can use rpiboot first to get the module mounted as storage and then use balenaEtcher to flash it.

I'd also be open to testing a beta if one is available.

Would you mind listing the steps to do this? I can't seem to figure it out. I have tried both running rpiboot and then plugging in the cm4 and plugging in the cm4 then running rpiboot.

[lurch]

AFAIK it should just be a case of following the instructions here, but then using balenaEtcher instead of dd or Raspberry Pi Imager? :man_shrugging:

[jellyfish-bot]

[hraftery] This has attached https://jel.ly.fish/b72fb655-5c21-412c-8546-77f31366931e

[zwhitchcox]

Hey, thanks for the community support and willingness to test. We actually have an internal tester with the required hardware, so that won't be necessary. We have a working version of the low level model. Working on getting an Etcher release right now. Just wanted to give an update.

Thank you for your patience!!

[fix3000]

That's fantastic news, thanks so much for looking at this.

Relatedly, when the release is, well... released, would it also be available for those of us that have Etcher Pro?

Thanks again.

On Thu, Oct 20, 2022, 9:10 AM Zane Hitchcox @.***> wrote:

Hey, thanks for the community support and willingness to test. We actually have an internal tester with the required hardware, so that won't be necessary. We have a working version of the low level model. Working on getting an Etcher release right now. Just wanted to give an update.

Thank you for your patience!!

— Reply to this email directly, view it on GitHub https://github.com/balena-io/etcher/issues/3792#issuecomment-1285513905, or unsubscribe https://github.com/notifications/unsubscribe-auth/A2S7ZNYMINRX5YKUQJWWMN3WEFADJANCNFSM55JP6W5A . You are receiving this because you were mentioned.Message ID: @.***>

[zwhitchcox]

Great question @fix3000 We are currently working on automating the process, but for now, I can go ahead and just manually change push the changes to EtcherPro repo.

[zwhitchcox]

Oops, didn't mean to close this yet.

[iamk3]

Just out of curiosity, is there any update on expected release timeframe?

[bhjelstrom]

https://github.com/balena-io/etcher/actions/runs/3423085558 Watching this PR in real time but has failed a few times now :)

[vrajesh-patel03]

I am waiting for this fix too.

[zwhitchcox]

You can try this out now in version 1.10.0 I do not have a CM4, so I haven't been able to test it myself though. Would someone mind letting me know if it is working?

[bhjelstrom]

@zwhitchcox It is not working, but I'm pretty sure etcher-sdk needs to be updated to 7.4.2. The PR that upgrades etcher-sdk to 7.4.2 is still failing:

https://github.com/balena-io/etcher/pull/3848

https://github.com/balena-io-modules/etcher-sdk/commits/master

[vrajesh-patel03]

I can also confirm that it is still not working.