Odroid C4


Recommended Posts

Armbian is a community driven open source project. Do you like to contribute your code?

No SPI - is very bad. Use an SD card (speed 50) or eMMC (speed 125) , if you have USB 3 (speed 340), to work - you need to be an idiot. At the same time, u-boot placement is possible only on SD\eMMC\SPI and therefore for the system to work with USB, you will have to have either an SD card (all SD cards are complete crap in speed and reliability and I generally consider them only as temporary media , such as CD\DVD on a PC), or buy an expensive branded EMMC module (almost 15$ for 8Gb), just for the sake of starting the system from USB. HK needs to be added before mass release SPI (only 4Mb is enough) and make it the main carrier for u-boot placement.

Link to post
Share on other sites
11 hours ago, Technicavolous said:

Will the C2 image (S905) work with the C4 (S905X3)?

No

 

11 hours ago, Technicavolous said:

Is anything coming for Armbian to support the C4?

If  have test sample, it will take 2-3 hours to release the finished image (this is taking into account the complete build and testing / debugging of the launch).

Link to post
Share on other sites

I just received an odroid c4, and fired up on sd:

Armbian_20.02.12_Odroidc4_focal_current_5.4.35.img

It comes up and I'm able to log in with root@, but after setting up a user and rebooting the device, it is not available over the network. The network light stays dark, although the normal blue light is blinking.

When I connect an HDMI interface, I see:

meson8b-dwmac ff3f0000.ethernet: Failed to reset the dma

meson8b-dwmac ff3f0000.ethernet eth0: stmmac_hw_setup: DMA engine initialization failed

Is there anything I can try to get the eth0 interface to work after power cycle?

Link to post
Share on other sites
10 minutes ago, Terence said:

I just received an odroid c4


I expect to get once next week, then I will try how our images work ;) 

 

10 minutes ago, Terence said:

meson8b-dwmac ff3f0000.ethernet: Failed to reset the dma

meson8b-dwmac ff3f0000.ethernet eth0: stmmac_hw_setup: DMA engine initialization failed

Is there anything I can try to get the eth0 interface to work after power cycle?


This is a very fist build without any end user support. I can only give you hint that we have seen this before, but without research I have no idea where to look.

Link to post
Share on other sites

FYI - updating the linux-image to the latest version (linux-image-current-meson64/buster 20.05.0-trunk) renders my system unbootable. Nothing comes out via HDMI, and the system never appears back on the network. I get this is an initial testing image with no support, just thought I'd warn anyone reading this thread and save them the time of reflashing.

 

Haven't had any issues with Ethernet yet though, aside from one of my cables not sitting well in the case.

Link to post
Share on other sites
9 hours ago, acwell said:

renders my system unbootable. Nothing comes out via HDMI, and the system never appears back on the network. I get this is an initial testing image with no support, just thought I'd warn anyone reading this thread and save them the time of reflashing.


You should only power cycle it ;)

Reboot works properly on eMMC, while on SD card it simply doesn't come back. But ethernet issues are quite often for me https://armbian.atlassian.net/browse/AR-231 - I spent a day trying to fix them, but nothing. Can't really afford working more on this right now. We have a release coming up and C4 is will anyway not be ready by then.

Link to post
Share on other sites

Hmm, I do have eMMC - a 16GB module from the manufacturer. Given that the Ethernet ports were blinking in a weirdly steady fashion after my "failed" upgrade, maybe I just ran into some other aspect of the broken Ethernet. I didnt try hooking up a serial console to see if anything came out. I dont recall if I tried a hard power cycle, though.

 

Anyways, certainly no rush to get this up and working, I more than appreciate you guys even making a bootable test image available.

 

I assume you already saw the patches here? http://lists.infradead.org/pipermail/linux-amlogic/2020-May/016638.html

 

I think you guys already pulled the first one, but I'm not sure where the device tree patch would go.

Link to post
Share on other sites

For what its worth, they claim the following are "fully functional":

 

- USB2+USB3

- USB2 OTG

- eMMC

- SDCard

- HDMI

- DVFS

- Gigabit Ethernet with RTL8211F PHY <---

- ADC

- Debug UART

- Infrared Receiver

Link to post
Share on other sites
2 hours ago, acwell said:

I assume you already saw the patches here?

 

2 hours ago, acwell said:

For what its worth, they claim the following are "fully functional":

 

We have the exact same implementation, which works well "on paper" ... just ("fully functional") network sometimes hangs. Now, after this little correction, it doesn't hang anymore. Images were recreated and I hope this is not the case just with my device. Welcome to test.

Link to post
Share on other sites
1 hour ago, c0nfused said:

Did I miss anything?


Yes. Reading comments on the download page, saying that SD card reboot does not work. (we write this down to hopefully limit the support costs)

 

Spoiler

c4.png

 

and also on eMMC might fail due to missing support for C4 in a kernel from repository. Images are for testing, so nobody cares if something like that doesn't work.

 

Armbian uses modern kernel only, which has few troubles on the list to solve. We will skip support for stock legacy 4.9.y kernel, which is currently in a better state - all those little problems are fixed there ...

Link to post
Share on other sites
Posted (edited)

I installed Armbian_20.02.14_Odroidc4_buster_current_5.4.39.img.xz and it seems much better, but I also found my C4 does not boot after apt update. However, it works if I do not let it upgrade the kernel, I ran this:

 

sudo apt update
sudo apt-mark hold linux-image-current-meson64
sudo apt-mark hold linux-dtb-current-meson64
sudo apt upgrade

and after this it reboots without a problem (on emmc card, btw).

It seems to me it's kernel version 20.05.0-trunk that's causing the failure to boot:

linux-image-current-meson64:
  Installed: 20.02.14
  Candidate: 20.05.0-trunk
  Version table:
     20.05.0-trunk 500
        500 http://apt.armbian.com buster/main arm64 Packages
 *** 20.02.14 100
        100 /var/lib/dpkg/status
     20.02.8 500
        500 http://apt.armbian.com buster/main arm64 Packages
     20.02.5 500
        500 http://apt.armbian.com buster/main arm64 Packages
     20.02.3 500
        500 http://apt.armbian.com buster/main arm64 Packages

 

Edited by Terence
Link to post
Share on other sites
31 minutes ago, Terence said:

It seems to me it's kernel version 20.05.0-trunk that's causing the failure to boot:


Exactly. Which was uploaded by mistake and has to be manually removed ... and because WIP target is failing, its not worth wasting time.

Link to post
Share on other sites
On 5/8/2020 at 10:54 PM, Terence said:

I installed Armbian_20.02.14_Odroidc4_buster_current_5.4.39.img.xz and it seems much better, but I also found my C4 does not boot after apt update. However, it works if I do not let it upgrade the kernel, I ran this:

 

 

Thanks.  I just ran into the same thing with the upgrade to the Focal image.   (Perhaps Igor's fix for the updating problem mentioned later in this thread hasn't trickled out to whatever mirror I had updated from.)

Link to post
Share on other sites
4 hours ago, jimt said:

I just ran into the same thing with the upgrade to the Focal image. 


Did you run apt update before? If not, that would explain the problem.

 

I did some double checking - just updated, rebooted, switched to nightly images ... power off, on, ... reboot, no troubles whatsoever. But this still doesn't mean everything is alright. It is working for me, but not working for you :) Too small sample, too little tests ... perhaps somebody else is fixing the driver with some other approach.

Link to post
Share on other sites

Just ran an update on Buster, and its unbootable again. I was under the impression the broken kernel was removed, but it seems there is a new, also broken one now: 20.02.15. My board is somewhere remote, so I'll have to go check next week to see what happened.

Link to post
Share on other sites
39 minutes ago, acwell said:

so I'll have to go check next week to see what happened.


This board is not production ready - at least not with a modern kernel - and without your input we can't do much - we have one board, which works fine for me and we can only rely on our private resources. If you wish to speed things up, we/you need to hire people. Support - if we decide to sponsor it for this board - goes this way https://github.com/armbian/build#support And we are not even there yet.

Link to post
Share on other sites

Yeah, I experienced the same problem doing

apt update && apt upgrade

The fix was in what you said in your post Igor:

 

Quote

just updated, rebooted, switched to nightly images

 

Yes, of course. I forgot that to recieve latest updates we must use nightly images. After switching to nightly and updating things everything works ok.

 

Thank you!

Link to post
Share on other sites
17 hours ago, Igor said:


Did you run apt update before? If not, that would explain the problem.

 

I did some double checking - just updated, rebooted, switched to nightly images ... power off, on, ... reboot, no troubles whatsoever. But this still doesn't mean everything is alright. It is working for me, but not working for you :) Too small sample, too little tests ... perhaps somebody else is fixing the driver with some other approach.

 

Yes, I had done:

apt update && apt -y dist-upgrade

 

I've just (2020-05-11T02:28:00Z) tried again:

  1. reflashed 32GB eMMC with Armbian_20.02.14_Odroidc4_focal_current_5.4.39.img
  2. did initial boot, created user account
  3. successfully rebooted
  4. logged in as newly created user and did apt update && apt -y dist-upgrade
  5. reboot... board never returns

Start-Date: 2020-05-11  02:22:39
Commandline: apt -y dist-upgrade
Requested-By: jim (1000)
Upgrade: linux-image-current-meson64:arm64 (20.02.14, 20.02.15), linux-libc-dev:arm64 (5.4.0
-26.30, 5.4.0-29.33), libldap-2.4-2:arm64 (2.4.49+dfsg-2ubuntu1, 2.4.49+dfsg-2ubuntu1.2), li
bpython3.8-minimal:arm64 (3.8.2-1ubuntu1, 3.8.2-1ubuntu1.1), libpython3.8:arm64 (3.8.2-1ubun
tu1, 3.8.2-1ubuntu1.1), python3.8:arm64 (3.8.2-1ubuntu1, 3.8.2-1ubuntu1.1), linux-dtb-curren
t-meson64:arm64 (20.02.14, 20.05.0-trunk), armbian-firmware:arm64 (20.02.14, 20.05.0-trunk),
python3.8-minimal:arm64 (3.8.2-1ubuntu1, 3.8.2-1ubuntu1.1), libldap-common:arm64 (2.4.49+df
sg-2ubuntu1, 2.4.49+dfsg-2ubuntu1.2), distro-info-data:arm64 (0.43ubuntu1, 0.43ubuntu1.1), a
rmbian-config:arm64 (20.02.14, 20.05.0-trunk), linux-u-boot-odroidc4-current:arm64 (20.02.14
, 20.05.0-trunk), libpython3.8-stdlib:arm64 (3.8.2-1ubuntu1, 3.8.2-1ubuntu1.1)
 

 

Link to post
Share on other sites
17 hours ago, Igor said:

I did some double checking - just updated, rebooted, switched to nightly images ... power off, on, ... reboot, no troubles whatsoever. But this still doesn't mean everything is alright. It is working for me, but not working for you :) Too small sample, too little tests ... perhaps somebody else is fixing the driver with some other approach.

 

Oh.  I hadn't done the switched to nightly images step. :blink: I had been expecting the updates to magically appear in the standard package pool so that apt update was sufficient.  Sorry for the misunderstanding.

 

I just reflashed, created user account, rebooted, used armbian-config to switch to nightly... and have successfully rebooted. 

 

Thanks for your help (and patience).

Link to post
Share on other sites
4 hours ago, jimt said:

Thanks for your help (and patience).


I don't need this board working now 100% and it is also impossible to do that in a short time. Even if we put all our resources into it. It is also expensive and slow to bring this support from where it is now, to perfectly working. Since we pay for everything and you for nothing, we proceed with our speed. Until then we will only rely on upstream fixes (like everyone else), which will ofc takes months to emerge: keep updating and once it will just start working ...

 

I have zero time to deal with this, nor is anyone dealing with this board to iron out those problems ... if you can't debug and fix some problem, forget it and use stock images which I assume might be better, but also not without bugs at this early stage. Usually it takes months to year that a board is production stable.
 

Temporally closing this thread since this board does not have end user support. If you are not a developer, you can only help this way: https://www.armbian.com/donate or doing something else that is in the project interest.

 

We haven't decide if we will pay the costs for dealing with you for this board which is on average around 20.000 EUR / year. You expect some real help or someone who has no clue about?

 

Edit: I also manage to kill the only board.

Link to post
Share on other sites
  • Igor locked this topic
  • Igor unlocked this topic

Hi,

 

will join testing next week, my board is on the way. The C4 would have been a great choice for this year's deployment, the 4GB option would have helped.

BTW, it's unclear for me, but does the C4 have a hardware SPI master in contrast to the C2 software SPI master?

 

See you, Michael

 

Link to post
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.

Guest
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.

Loading...