# SD card boots on one CM4 but fails on another **URL:** \ **Category:** Debian family\ **Created:** [January 3, 2024, 3:23pm UTC](https://hub.mender.io/t/sd-card-boots-on-one-cm4-but-fails-on-another/6437 "2024-01-03T15:23:24Z")\ **Posts on this page:** 16\ **Page:** 1
**Author:** ![jjsteele](https://avatars.discourse-cdn.com/v4/letter/j/dfb087/32.png) [@jjsteele](https://hub.mender.io/u/jjsteele)\ **Post date:** [January 3, 2024, 3:23pm UTC](https://hub.mender.io/t/sd-card-boots-on-one-cm4-but-fails-on-another/6437/1 "2024-01-03T15:23:24Z")
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? ---
**Author:** ![TheYoctoJester](https://yyz2.discourse-cdn.com/flex036/user_avatar/hub.mender.io/theyoctojester/32/1444_2.png) [@TheYoctoJester](https://hub.mender.io/u/TheYoctoJester)\ **Post date:** [January 5, 2024, 7:59am UTC](https://hub.mender.io/t/sd-card-boots-on-one-cm4-but-fails-on-another/6437/2 "2024-01-05T07:59:29Z")
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 ---
**Author:** ![jjsteele](https://avatars.discourse-cdn.com/v4/letter/j/dfb087/32.png) [@jjsteele](https://hub.mender.io/u/jjsteele)\ **Post date:** [January 5, 2024, 9:17am UTC](https://hub.mender.io/t/sd-card-boots-on-one-cm4-but-fails-on-another/6437/3 "2024-01-05T09:17:14Z")
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 ---
**Author:** ![TheYoctoJester](https://yyz2.discourse-cdn.com/flex036/user_avatar/hub.mender.io/theyoctojester/32/1444_2.png) [@TheYoctoJester](https://hub.mender.io/u/TheYoctoJester)\ **Post date:** [January 5, 2024, 9:49am UTC](https://hub.mender.io/t/sd-card-boots-on-one-cm4-but-fails-on-another/6437/4 "2024-01-05T09:49:17Z")
Hi @jjsteele, Well, I wouldn’t call it “persuasion” to add OTA to a product 😉 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](https://www.get-edi.io/), possibly @lueschem can share some insights. Greetz, Josef ---
**Author:** ![jjsteele](https://avatars.discourse-cdn.com/v4/letter/j/dfb087/32.png) [@jjsteele](https://hub.mender.io/u/jjsteele)\ **Post date:** [January 5, 2024, 10:24am UTC](https://hub.mender.io/t/sd-card-boots-on-one-cm4-but-fails-on-another/6437/6 "2024-01-05T10:24:06Z")
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 ---
**Author:** ![jjsteele](https://avatars.discourse-cdn.com/v4/letter/j/dfb087/32.png) [@jjsteele](https://hub.mender.io/u/jjsteele)\ **Post date:** [January 5, 2024, 10:49am UTC](https://hub.mender.io/t/sd-card-boots-on-one-cm4-but-fails-on-another/6437/7 "2024-01-05T10:49:31Z")
@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)](https://github.com/mendersoftware/uboot-mender)? Thanks again, John ---
**Author:** ![jjsteele](https://avatars.discourse-cdn.com/v4/letter/j/dfb087/32.png) [@jjsteele](https://hub.mender.io/u/jjsteele)\ **Post date:** [January 5, 2024, 12:24pm UTC](https://hub.mender.io/t/sd-card-boots-on-one-cm4-but-fails-on-another/6437/8 "2024-01-05T12:24:03Z")
@TheYoctoJester Where would I get the patches needed for Pi4, please? Thanks again, John ---
**Author:** ![TheYoctoJester](https://yyz2.discourse-cdn.com/flex036/user_avatar/hub.mender.io/theyoctojester/32/1444_2.png) [@TheYoctoJester](https://hub.mender.io/u/TheYoctoJester)\ **Post date:** [January 5, 2024, 12:32pm UTC](https://hub.mender.io/t/sd-card-boots-on-one-cm4-but-fails-on-another/6437/9 "2024-01-05T12:32:57Z")
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 ---
**Author:** ![jjsteele](https://avatars.discourse-cdn.com/v4/letter/j/dfb087/32.png) [@jjsteele](https://hub.mender.io/u/jjsteele)\ **Post date:** [January 5, 2024, 1:34pm UTC](https://hub.mender.io/t/sd-card-boots-on-one-cm4-but-fails-on-another/6437/10 "2024-01-05T13:34:12Z")
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 ---
**Author:** ![TheYoctoJester](https://yyz2.discourse-cdn.com/flex036/user_avatar/hub.mender.io/theyoctojester/32/1444_2.png) [@TheYoctoJester](https://hub.mender.io/u/TheYoctoJester)\ **Post date:** [January 5, 2024, 1:35pm UTC](https://hub.mender.io/t/sd-card-boots-on-one-cm4-but-fails-on-another/6437/11 "2024-01-05T13:35:12Z")
> [@TheYoctoJester](#): > > The repository that you linked to is the right one, and it already carries the patches for RPi4 This refers to the Mender patches, as the RPi4 has mainline support in uboot. Greetz, Josef ---
**Author:** ![jjsteele](https://avatars.discourse-cdn.com/v4/letter/j/dfb087/32.png) [@jjsteele](https://hub.mender.io/u/jjsteele)\ **Post date:** [January 5, 2024, 1:37pm UTC](https://hub.mender.io/t/sd-card-boots-on-one-cm4-but-fails-on-another/6437/12 "2024-01-05T13:37:41Z")
Many thanks, Have a great weekend! John ---
**Author:** ![lueschem](https://yyz2.discourse-cdn.com/flex036/user_avatar/hub.mender.io/lueschem/32/214_2.png) [@lueschem](https://hub.mender.io/u/lueschem)\ **Post date:** [January 8, 2024, 11:25am UTC](https://hub.mender.io/t/sd-card-boots-on-one-cm4-but-fails-on-another/6437/13 "2024-01-08T11:25:14Z")
> [@TheYoctoJester](#): > > try an alternate flow which does not need `u-boot`. An example here is [EDI](https://www.get-edi.io/), possibly @lueschem can share some insights. Sure - this is something you can try out. However, the [edi-pi](https://github.com/lueschem/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. ---
**Author:** ![jjsteele](https://avatars.discourse-cdn.com/v4/letter/j/dfb087/32.png) [@jjsteele](https://hub.mender.io/u/jjsteele)\ **Post date:** [January 8, 2024, 12:09pm UTC](https://hub.mender.io/t/sd-card-boots-on-one-cm4-but-fails-on-another/6437/14 "2024-01-08T12:09:32Z")
@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 ---
**Author:** ![lueschem](https://yyz2.discourse-cdn.com/flex036/user_avatar/hub.mender.io/lueschem/32/214_2.png) [@lueschem](https://hub.mender.io/u/lueschem)\ **Post date:** [January 8, 2024, 12:42pm UTC](https://hub.mender.io/t/sd-card-boots-on-one-cm4-but-fails-on-another/6437/15 "2024-01-08T12:42:38Z")
> [@jjsteele](#): > > I am looking at getting logging to file working using file\_fat\_write. Do you think this is sensible? Sure - the logs might contain some hints. ---
**Author:** ![jjsteele](https://avatars.discourse-cdn.com/v4/letter/j/dfb087/32.png) [@jjsteele](https://hub.mender.io/u/jjsteele)\ **Post date:** [January 10, 2024, 12:01pm UTC](https://hub.mender.io/t/sd-card-boots-on-one-cm4-but-fails-on-another/6437/16 "2024-01-10T12:01:59Z")
@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 ---
**Author:** ![lueschem](https://yyz2.discourse-cdn.com/flex036/user_avatar/hub.mender.io/lueschem/32/214_2.png) [@lueschem](https://hub.mender.io/u/lueschem)\ **Post date:** [January 10, 2024, 12:47pm UTC](https://hub.mender.io/t/sd-card-boots-on-one-cm4-but-fails-on-another/6437/17 "2024-01-10T12:47:28Z")
> [@jjsteele](#): > > Is there any way I can use edi-pi on Buster? 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.