Igor Posted April 23, 2020 Posted April 23, 2020 https://wiki.odroid.com/odroid-c4/hardware/hardware 1 Quote
jeanrhum Posted April 23, 2020 Posted April 23, 2020 Nice board to come with cortex A55 and G31. We can hope efficient fanless cooling with this soc. The 12V2A psu seem a bit too much in terms of max power, but 12V psu is nice and will definitely stop bad 5V psu problems. More details on the odroid forum: https://forum.odroid.com/viewtopic.php?f=29&t=38555 0 Quote
balbes150 Posted April 23, 2020 Posted April 23, 2020 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. 1 Quote
guidol Posted April 23, 2020 Posted April 23, 2020 the same non-standard serial-port - against Opi and NanoPi - as the Odroid C2 In the past Allwinner CPUs did work better for me than Rockhip (got an Odroid C2 and a Radxa with Rockchip 3188) But we will see.... 0 Quote
Technicavolous Posted April 23, 2020 Posted April 23, 2020 Will the C2 image (S905) work with the C4 (S905X3)? Is anything coming for Armbian to support the C4? Love my Odroid stuff, love Armbian, marry them as often as possible ;] 0 Quote
balbes150 Posted April 24, 2020 Posted April 24, 2020 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). 1 Quote
Igor Posted April 27, 2020 Author Posted April 27, 2020 Thanks to @Neil Armstrong we already have full blown Armbian for C4. Images are ofc only for testing at this stage. K5.4 and K5.6 in Focal and other variants https://www.armbian.com/odroid-c4/ 2 Quote
lanefu Posted April 27, 2020 Posted April 27, 2020 On 4/23/2020 at 9:55 AM, guidol said: the same non-standard serial-port - against Opi and NanoPi - as the Odroid C2 I just shove female dupont connectors on the pins on the odroid serial ports and works fine. 0 Quote
Terence Posted April 30, 2020 Posted April 30, 2020 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? 0 Quote
Igor Posted April 30, 2020 Author Posted April 30, 2020 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. 0 Quote
acwell Posted May 4, 2020 Posted May 4, 2020 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. 0 Quote
Igor Posted May 5, 2020 Author Posted May 5, 2020 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. 0 Quote
acwell Posted May 7, 2020 Posted May 7, 2020 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. 0 Quote
acwell Posted May 7, 2020 Posted May 7, 2020 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 0 Quote
Igor Posted May 7, 2020 Author Posted May 7, 2020 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. 0 Quote
c0nfused Posted May 8, 2020 Posted May 8, 2020 i have some question. when i download Buster server build date 2020-05-07 and write to sd card ok it find but i run apt-get update && apt-get upgrade -y and reboot my c4 can't booting. Did I miss anything? 0 Quote
Igor Posted May 8, 2020 Author Posted May 8, 2020 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 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 ... 0 Quote
Terence Posted May 8, 2020 Posted May 8, 2020 (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 May 8, 2020 by Terence 0 Quote
Igor Posted May 8, 2020 Author Posted May 8, 2020 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. 0 Quote
jimt Posted May 10, 2020 Posted May 10, 2020 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.) 0 Quote
Igor Posted May 10, 2020 Author Posted May 10, 2020 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. 0 Quote
acwell Posted May 10, 2020 Posted May 10, 2020 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. 0 Quote
Igor Posted May 10, 2020 Author Posted May 10, 2020 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. 0 Quote
cflow Posted May 10, 2020 Posted May 10, 2020 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! 0 Quote
jimt Posted May 11, 2020 Posted May 11, 2020 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: reflashed 32GB eMMC with Armbian_20.02.14_Odroidc4_focal_current_5.4.39.img did initial boot, created user account successfully rebooted logged in as newly created user and did apt update && apt -y dist-upgrade 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) 0 Quote
jimt Posted May 11, 2020 Posted May 11, 2020 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. 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). 0 Quote
Igor Posted May 11, 2020 Author Posted May 11, 2020 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. 1 Quote
mboehmer Posted May 31, 2020 Posted May 31, 2020 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 0 Quote
Recommended Posts
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.