Jump to content

ODroid C2 will not boot (latest image 22.08)

Bob Warren

Recommended Posts

Ok I tried a lot of images and the only one that boots to terminal and runs is the jammy-cli.  This is fine for my use and I’ll install x11 for super basic use if needed.  I think what could be wrong is the video is not working on those other images and possibly it did in fact boot and try to start the setup. 

Link to comment
Share on other sites

@thedocbwarren How did you start and connect to the Ordoid C2?

Because I used the bullseye-cli and it booted right away - BUT I had only the "problem" (like before on C2 images)
that I cant connect via SSH to the C2 for the initial setup.


The initial setup is only at the HDMI-Port :( (and an the first boot the filesystem-resize took some time)
After I completed the inital setup via HDMI and USB-Keyboad I can connect normally via SSH ;)


BTW: After a rebout I have to power off/on for the next startup (u-boot problem)

u-boot seems to be actual from the new installation on the MicroSD-Card:

dd if=/dev/mmcblk0 of=/tmp/installed_uboot.bin skip=97 count=1376

1376+0 records in
1376+0 records out
704512 bytes (705 kB, 688 KiB) copied, 0.0471277 s, 14.9 MB/s

strings /tmp/installed_uboot.bin | grep "U-Boot 20"

U-Boot 2022.01-armbian (Aug 30 2022 - 06:46:25 +0000) odroid-c2



Edited by guidol
Link to comment
Share on other sites

Hi, I join this thread, I have the same issue: Odroid C2 won't boot on Armbian 22.08 Jammy XFCE.

I tried to flash with Balena, Rufus, Win32DiskImager, and same result: black screen, no led blinking.


Is there a fix since the last post ? 


Thx !

Link to comment
Share on other sites

Hi, I'm also having this problem, or a similar one. I grabbed a UART breakout and am getting an exception when trying to boot:


Applying kernel provided DT fixup script (meson-fixup.scr)
## Executing script at 32000000
## Loading init Ramdisk from Legacy Image at 13000000 ...
   Image Name:   uInitrd
   Image Type:   AArch64 Linux RAMDisk Image (gzip compressed)
   Data Size:    20195814 Bytes = 19.3 MiB
   Load Address: 00000000
   Entry Point:  00000000
   Verifying Checksum ... OK
## Flattened Device Tree blob at 04080000
   Booting using the fdt blob at 0x4080000
   Loading Ramdisk to 7ac02000, end 7bf449e6 ... OK
   Loading Device Tree to 000000007ab90000, end 000000007ac01fff ... OK
"Synchronous Abort" handler, esr 0x96000004
elr: 000000000106056c lr : 000000000104fee8 (reloc)
elr: 000000007dfb756c lr : 000000007dfa6ee8
x0 : 040da13e7bc5efcf x1 : 000000007dfbebc8
x2 : 0000000000000010 x3 : 0000000000000000
x4 : 0000000000000000 x5 : 040da13e7bc5efcf
x6 : 000000007bf5ce00 x7 : 0000000000000000
x8 : 0000000000000007 x9 : 0000000000000000
x10: 00000000000001dc x11: 000000007bf4928c
x12: 00000000000000b0 x13: 000000007bf49248
x14: 000000007ab90000 x15: 0000000000000020
x16: 000000007bf449e6 x17: 0000000000000000
x18: 000000007bf54db0 x19: 000000007af49040
x20: 000000007df57b20 x21: 000000007dfbebc8
x22: 0000000000001000 x23: 000000007bf5cd50
x24: 000000007dfdc8a0 x25: 0000000001000000
x26: 0000000001000000 x27: 0000000001000000
x28: 0000000000001000 x29: 000000007bf49240

Code: eb02009f 54000061 52800000 14000006 (386468a3)
Resetting CPU ...

resetting ...


Disassembling the code shows that it's trying to load the byte at the address x4 + x5, which is very clearly not valid memory.

Link to comment
Share on other sites

I did more digging. It seems like the U-boot build is buggy somehow. I managed to work around it and get it to boot by adding this line to the armbianEnv.txt file:




I don't really know why this works, but it did.

Edited by endrift
Link to comment
Share on other sites

20 minutes ago, ママベンガ said:

still not working 😐


What if you have a problem and I will lost my precious time for nothing? You will cover it?

We even got an email today stating:

"The no start odroidc2 bug I had with the oct27 release was fixed in the newest November release;"


Be a hero and I will check it again. This is the only motive left.

Link to comment
Share on other sites

There is an issue in recent u-boot versions that causes this behaviour. The commit that introduced it is a9bf024b2933bba0e23038892970a18b72dfaeb4. A possible solution is to disable all the EFI-stuff in u-boot, then it boots perfectly fine in recent u-boot versions aswell. So if armbian wants to update u-boot for this board, keep this in mind. I have reported this to u-boot aswell so hopefully it will be fixed at some point there.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines