SD card boots on one CM4 but fails on another

Board Integrations Debian family
1

I have used Mender-Convert to create a new SD Card and it workd perfectly in my Wireless CM4 Lite with IO Board. However, when I put the card in a headerless CM4 Lite it never boots the image. I know it gets as far as reading and obeying the config.txt but doesn’t seem to get any further. I can’t see any output logs on the card so am stuck with what could be the problem. The headerless board has an SD card reader and two Camera sockets but nu USB or HDMI. ANy ideas on what it could be or where I can find any debug output?

2

Hi @jjsteele,

Do you have access to the serial console? And, is it a fresh image directly from the RPi people, or based off a golden image that you created?

Reason why I’m asking is, the generic image runs a setup wizard which needs keyboard and screen.

Greetz,
Josef

3

Hi @TheYoctoJester,

I’m afraid I don’t have access to the serial console, this is a pre-production board that was running a straight Buster image, the client was persuded they needed OTAU before releasing the product to the world, so that is where we are at. The board only has an RGB LED, a brief contact button, two Camera connecters, SD card holder and power socket.

It is based on the original golden image and workd perfectly in the IO board but only seems to get as far as obeying the contents on config.txt, as I can see the LED light up white or whatever colour I set it there.

Thanks for replying,

John

4

Hi @jjsteele,

Well, I wouldn’t call it “persuasion” to add OTA to a product :wink: But adding it last minute is often painful, agreed.

But anyways, once you don’t have any debugging facilities, it becomes tricky. My gut feeling is that the generic boot path does pass/modify something, possibly in the DTB before it hands off to the kernel. The original RasPi bootflow goes from their closed firmware straight to kernel.

mender-convert inserts u-boot into the chain for doing the A/B switching. My guess would be that this u-boot somehow doesn’t start properly due to the custom hardware.

Things you can do now:

  • create a drop-in binary u-boot which carries the patches that the board probably has, or
  • try an alternate flow which does not need u-boot. An example here is EDI, possibly @lueschem can share some insights.

Greetz,
Josef

6

Hi @TheYoctoJester,
I don’t believe there are any patches for the board, it just runs the standard buster without a problem. Would it be worthwhile building the latest u-boot with debugging to the SD card do you think.

Alternatively, @lueschem I already have a mender enabled build that runs on the IO board. Can I use this is the basis for switching to EFI?

Cheers,

John

7

@TheYoctoJester Would the u-boot repo I would need GitHub - mendersoftware/uboot-mender: U-boot fork containing Mender integration (used by https://github.com/mendersoftware/mender-convert)?

Thanks again,

John

8

@TheYoctoJester Where would I get the patches needed for Pi4, please?

Thanks again,

John

9

Hi @jjsteele,

I think you are mixing up two things. The repository that you linked to is the right one, and it already carries the patches for RPi4.

But uboot needs to know about board specifics, and as far as I can see, you probably do not have a patchset that adds support for your custom board to uboot. Hence, it does not boot.

So why does plain buster boot? Because it does not use uboot. There is some magic in the RPi firmware that can boot into the kernel directly.

So your options are: either add support for your custom board to uboot, on top of the repo, or to switch to a non-uboot path such as the one that EDI provides.

Greetz,
Josef

10

Hi @TheYoctoJester,

Sorry for all the questions! Last one today I promise. Does the repo also have the patches for mender integration or do those need to be added?

John

11

This refers to the Mender patches, as the RPi4 has mainline support in uboot.

Greetz,
Josef

12

Many thanks,

Have a great weekend!

John

13

Sure - this is something you can try out. However, the edi-pi project setup is based on Debian bullseye or bookworm.

What is preventing your current setup from booting is really hard to find out without further logs.

14

@lueschem Thanks Matthias, this project is running Buster so I assume edi-pi is not suitable. I am looking at getting logging to file working using file_fat_write. Do you think this is sensible?

John

15

Sure - the logs might contain some hints.

16

@lueschem I’m having problems getting file_fat_write to work. It seems 1 out of 10 times I get a file otherwise nothing.
Is there any way I can use edi-pi on Buster?

John

17

Technically this should be possible. However, I currently do not have enough spare time to backport the u-boot less solution to a Debian variant that is close to EOL.