Odroid C2 general

[TonyMac32]

This week we discontinued the default 3.x kernel for the Odroid C2, and are working on the 4.18/4.19 kernels.

 

A few odds and ends have come up, the biggest one appears to be the gpio-hog in the C2 device tree somehow not working, causing the USB hub on the board to never be powered on. 

root@odroidc2:/sys/class/gpio# cat /sys/kernel/debug/gpio
gpiochip1: GPIOs 378-496, parent: platform/c8834000.periphs:pinctrl@4b0, periphs-banks:
 gpio-392 (                    |mdio-reset          ) out hi
 gpio-407 (                    |reset               ) out hi
 gpio-422 (                    |cd                  ) in  lo
 gpio-465 (                    |TFLASH_VDD          ) out hi

gpiochip0: GPIOs 497-511, parent: platform/c8100000.bus:pinctrl@14, aobus-banks:
 gpio-500 (                    |TF_IO               ) out lo
 gpio-501 (                    |usb-hub-reset       ) out hi
 gpio-502 (                    |USB_OTG_PWR         ) out hi
 gpio-510 (                    |c2:blue:alive       ) out lo

The hog claims it is there, but I get no power to the port.

 

 

The other is the HDMI output becoming extremely fussy about the sort of monitor it's been given.

[update]

 

On the NanoPi K2 I actually get a crash on boot with my HDMI --> DVI adapter monitor.  With both monitors, if plugged in after boot, desktop displays (on C2 only the pure HDMI monitor will display at all), but a fault occurs:

Spoiler

 

[  312.393869] WARNING: CPU: 3 PID: 2809 at drivers/gpu/drm/meson/meson_crtc.c:150 meson_crtc_atomic_begin+0x64/0x70 [meson_drm]
[  312.393880] Modules linked in: fuse brcmfmac brcmutil lz4hc cfg80211 lz4hc_compress snd_soc_hdmi_codec rc_cec rfkill snd_soc_simple_card dw_hdmi_cec dw_hdmi_i2s_audio snd_soc_simple_card_utils meson_vdec snd_soc_core snd_pcm_dmaengine videobuf2_dma_contig snd_pcm meson_dw_hdmi videobuf2_memops snd_timer v4l2_mem2mem dw_hdmi snd meson_drm cec videobuf2_v4l2 drm_kms_helper soundcore videobuf2_common drm videodev meson_rng rng_core media drm_panel_orientation_quirks meson_ir rc_core meson_gxbb_wdt pwm_meson scpi_hwmon zram zsmalloc ip_tables x_tables realtek
[  312.394080] CPU: 3 PID: 2809 Comm: Xorg Tainted: G        W         4.19.1-meson64 #2
[  312.394086] Hardware name: friendlyarm,nanopi-k2 (DT)
[  312.394095] pstate: 40000005 (nZcv daif -PAN -UAO)
[  312.394117] pc : meson_crtc_atomic_begin+0x64/0x70 [meson_drm]
[  312.394138] lr : meson_crtc_atomic_begin+0x20/0x70 [meson_drm]
[  312.394144] sp : ffff00000dbb3a00
[  312.394149] x29: ffff00000dbb3a00 x28: 0000000000000000
[  312.394162] x27: ffff80007085e600 x26: ffff80005ce4be00
[  312.394176] x25: ffff8000707cb078 x24: ffff80005ccc5900
[  312.394189] x23: 0000000000000038 x22: 0000000000000000
[  312.394201] x21: 0000000000000000 x20: 0000000000000001
[  312.394214] x19: ffff8000707cb018 x18: 0000000000000000
[  312.394227] x17: 0000000000000000 x16: 0000000000000000
[  312.394239] x15: 0000000000000000 x14: 0000046500000441
[  312.394252] x13: 0000043c00000465 x12: 0000043800000438
[  312.394264] x11: 0000000000000898 x10: 00000804000007d8
[  312.394277] x9 : ffff000008e69888 x8 : ffff000000bea000
[  312.394290] x7 : 0000000000000000 x6 : ffff800070f2d168
[  312.394302] x5 : 0000000000000000 x4 : 0000000000000001
[  312.394315] x3 : 0000000000000000 x2 : 0000000000000000
[  312.394327] x1 : ffff800066ae8000 x0 : 00000000ffffffea
[  312.394340] Call trace:
[  312.394362]  meson_crtc_atomic_begin+0x64/0x70 [meson_drm]
[  312.394461]  drm_atomic_helper_commit_planes+0x70/0x208 [drm_kms_helper]
[  312.394543]  drm_atomic_helper_commit_tail+0x30/0x78 [drm_kms_helper]
[  312.394628]  commit_tail+0x74/0x78 [drm_kms_helper]
[  312.394712]  drm_atomic_helper_commit+0xe8/0x168 [drm_kms_helper]
[  312.394919]  drm_atomic_commit+0x48/0x58 [drm]
[  312.395001]  drm_atomic_helper_set_config+0x84/0xc0 [drm_kms_helper]
[  312.395174]  drm_mode_setcrtc+0x140/0x600 [drm]
[  312.395344]  drm_ioctl_kernel+0x88/0x100 [drm]
[  312.395511]  drm_ioctl+0x1ac/0x3e0 [drm]
[  312.395527]  do_vfs_ioctl+0xb8/0x8e0
[  312.395536]  ksys_ioctl+0x80/0xb8
[  312.395546]  __arm64_sys_ioctl+0x1c/0x28
[  312.395559]  el0_svc_common+0x60/0xe8
[  312.395569]  el0_svc_handler+0x24/0x80
[  312.395578]  el0_svc+0x8/0xc
[  312.395584] ---[ end trace 6dcc4ef2fc3d8888 ]---
[  312.395999] WARNING: CPU: 0 PID: 0 at drivers/gpu/drm/drm_vblank.c:1026 drm_vblank_put+0xa0/0xb8 [drm]
[  312.396019] Modules linked in: fuse brcmfmac brcmutil lz4hc cfg80211 lz4hc_compress snd_soc_hdmi_codec rc_cec rfkill snd_soc_simple_card dw_hdmi_cec dw_hdmi_i2s_audio snd_soc_simple_card_utils meson_vdec snd_soc_core snd_pcm_dmaengine videobuf2_dma_contig snd_pcm meson_dw_hdmi videobuf2_memops snd_timer v4l2_mem2mem dw_hdmi snd meson_drm cec videobuf2_v4l2 drm_kms_helper soundcore videobuf2_common drm videodev meson_rng rng_core media drm_panel_orientation_quirks meson_ir rc_core meson_gxbb_wdt pwm_meson scpi_hwmon zram zsmalloc ip_tables x_tables realtek
[  312.396395] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G        W         4.19.1-meson64 #2
[  312.396400] Hardware name: friendlyarm,nanopi-k2 (DT)
[  312.396410] pstate: 20000085 (nzCv daIf -PAN -UAO)
[  312.396589] pc : drm_vblank_put+0xa0/0xb8 [drm]
[  312.396762] lr : drm_crtc_vblank_put+0x18/0x20 [drm]
[  312.396768] sp : ffff000008003de0
[  312.396773] x29: ffff000008003de0 x28: 0000000000000001
[  312.396787] x27: ffff000008ceee28 x26: ffff000008ef0c8a
[  312.396817] x25: ffff80007134c000 x24: ffff000008e69000
[  312.396871] x23: 0000000000000020 x22: 0000000000000080
[  312.396897] x21: ffff8000707cb018 x20: ffff000008e69000
[  312.396910] x19: ffff800070f2c218 x18: 0000000000000000
[  312.396922] x17: 0000000000000000 x16: 0000000000000000
[  312.396935] x15: 000000000000684c x14: 0000000000006878
[  312.396947] x13: 0000000000006874 x12: 0000000000006870
[  312.396960] x11: 000000000000686c x10: 0000000000006840
[  312.396972] x9 : 0000000000007498 x8 : 0000000040000000
[  312.396984] x7 : 0000000000210d00 x6 : ffff000008e69888
[  312.396997] x5 : ffff000000ba5a5c x4 : 0000000000000001
[  312.397030] x3 : 0000000000000170 x2 : 0000000000000000
[  312.397074] x1 : ffff800070f2d000 x0 : ffff800070a51800
[  312.397087] Call trace:
[  312.397265]  drm_vblank_put+0xa0/0xb8 [drm]
[  312.397456]  drm_crtc_vblank_put+0x18/0x20 [drm]
[  312.397494]  meson_crtc_irq+0x7c/0x608 [meson_drm]
[  312.397514]  meson_irq+0x20/0x30 [meson_drm]
[  312.397533]  __handle_irq_event_percpu+0x74/0x188
[  312.397559]  handle_irq_event_percpu+0x34/0x88
[  312.397574]  handle_irq_event+0x48/0x78
[  312.397587]  handle_fasteoi_irq+0xa8/0x180
[  312.397597]  generic_handle_irq+0x24/0x38
[  312.397607]  __handle_domain_irq+0x5c/0xb0
[  312.397616]  gic_handle_irq+0x58/0xa8
[  312.397640]  el1_irq+0xb0/0x128
[  312.397665]  arch_cpu_idle+0x10/0x18
[  312.397678]  do_idle+0x1d4/0x298
[  312.397686]  cpu_startup_entry+0x24/0x28
[  312.397699]  rest_init+0xcc/0xd8
[  312.397712]  start_kernel+0x3d4/0x400
[  312.397718] ---[ end trace 6dcc4ef2fc3d8889 ]---

FYI @Neil Armstrong

[TonyMac32]

I've found something additional, it appears the vendor U-boot toggled the line low to assert reset, then brought it high upon the driver being configured.  I don't see any evidence of that happening, and using the datasheet I'm less than certain about trying to do that given this: https://github.com/trini/u-boot/blob/master/arch/arm/include/asm/arch-meson/gx.h

 

 

[matt407]

I tested Kernel 4.18.8-odroidc2 for a few days and I noticed that the something network related crashes under load. Probably this is network-manager related as Igor mentioned in another thread? 

Due to the lack of time for more investigation, I went back to the legacy kernel. 

[mboehmer]

Damned, I compiled new images for C2 recently, but operating it headless, I never checked USB ports.

Network was stable so far, I did not notice any hangups or really bad performance.

 

I can check lines with logic analyzer, in case that helps.

 

Just let me know how I can support debugging (I will need C2 boards soon for next deep sea operation, and it also seems to be a really cool board for Antarctica setup)...

 

Michael

[TonyMac32]

@mboehmer I am tempted to try just pulling that out of the device tree and making it an available GPIO with a rule attached, in case anyone wants to shut down the extra USB's. 

[mboehmer]

Sounds reasonable. Many people won't need it anyway. If peeking around with DT it would be great to have also entries for PWM and 1wire (just commented out, but known working). I2C should also be prepared...

Frpm my experience it is hardcto get correct entries for that periphials unless you are a DT expert

[TonyMac32]

7 hours ago, mboehmer said:

Frpm my experience it is hardcto get correct entries for that periphials unless you are a DT expert

I would agree with that, but some of these are simple enough with the documentation in the kernel.  The C2 appears to be set up for overlays, I'll have to experiment with that as well.

[TonyMac32]

Looks like u-boot 2018.11 is viable for all Meson64 boards, oddly enough USB works on C2 from boot with this U-boot, but now USB on K2 does not.    I've got quite a bit of cleaning to do, C2 doesn't need it's own top-level u-boot patch folder/etc.

 

[edit]  It looks like CEC is crashing the board, disabling any mention of it in the config makes it boot successfully, however the HDMI doesn't want to come up either, unless you boot without the HDMI plugged in, and plug it in after Linux is up.  Then you can have a 4K 30Hz desktop if your monitor is so capable.  HDMI --> DVI on my Acer monitor though, a no-go.

 

[edit]   My 7" Waveshare HDMI worked from boot.

[picosoft]

Hi,

I want to use PWM signal, but, no working.

 

I am using an odroid c2.

>uname -a

Linux odroidc2 4.18.20-meson64 #1 SMP PREEMPT Fri Dec 21 16:26:12 KST 2018 aarch64 GNU/Linux

 

Please, let me know how to do.

Thanks.

[TonyMac32]

If you know how to make overlays, you can give nightly dev images a try, I haven't made PWM overlays yet though.

[oleid]

Dear all,

 

first of all, thanks a lot for working on this device. It's great to run a mainline kernel on odroid C2.

 

I just installed armbian to my C2 and noticed USB devices are unpowered and thus, don't show up via lsusb. Reading this thread and the notes on the device's page (https://www.armbian.com/odroid-c2/), I assumed that gpio126 or maybe 501 would be the one to use to power up the hub.

 

$ cat /sys/kernel/debug/gpio
gpiochip1: GPIOs 378-496, parent: platform/c8834000.periphs:pinctrl@4b0, periphs-banks:
 gpio-392 (                    |mdio-reset          ) out hi    
 gpio-407 (                    |reset               ) out hi    
 gpio-422 (                    |cd                  ) in  lo    
 gpio-465 (                    |TFLASH_VDD          ) out hi    

gpiochip0: GPIOs 497-511, parent: platform/c8100000.bus:pinctrl@14, aobus-banks:
 gpio-500 (                    |TF_IO               ) out lo    
 gpio-501 (                    |usb-hub-reset       ) out hi    
 gpio-502 (                    |USB_OTG_PWR         ) out hi    
 gpio-510 (                    |c2:blue:alive       ) out lo    

But I cannot export either gpio pin. Is there a work-around to enable the usb hub?

 

Kind regards,

Olaf

[TonyMac32]

The gpio is claimed by the "hog", so is not able to be used by users.  This issue (non-powered hub) went away with 4.19, we're only dealing with HDMI issues so far there.

[oleid]

15 minutes ago, TonyMac32 said:

The gpio is claimed by the "hog", so is not able to be used by users.  This issue (non-powered hub) went away with 4.19, we're only dealing with HDMI issues so far there.

Ah, thanks a lot! 4.19.0 seems to work.

[JMCC]

Sorry if the question seems silly, but is there any way to set the higher clock speeds with the mainline kernel?

[TonyMac32]

1 hour ago, JMCC said:

Sorry if the question seems silly, but is there any way to set the higher clock speeds with the mainline kernel?

 

The Odroid blob is used for the C2, so it should be able to run up to it's maximum (15xx MHz)

[JMCC]

44 minutes ago, TonyMac32 said:

 

The Odroid blob is used for the C2, so it should be able to run up to it's maximum (15xx MHz)

That's an improvement over S905X, for sure. But I guess the old settings for higher clock speeds (1.6, 1.75, etc. Ghz) in boot.ini were bound to legacy kernel or uboot, weren't they?

[TonyMac32]

6 minutes ago, JMCC said:

were bound to legacy kernel or uboot, weren't they?

 

That I'm not sure of, and I'm also uncertain they were ever "real".  I'd have to scour around in here and find what @wtarreau has to say on the matter, since Amlogic processors are under the command of the mighty M4 micro of doom with super-secret firmware.  We have the same secret sauce blobs as the legacy u-boot, so it should be there.

[JMCC]

1 minute ago, TonyMac32 said:

I'm also uncertain they were ever "real"

I'm not sure whether they correspond exactly with the number you set, but I can tell they mean a real higher clock speed. I tried with HK's image, and increasing the clock speed through that method causes an increase in hashes/sec with a CPU miner (like ~14.50 hash/s at 1512MHz, vs ~16.50 at 1752Mhz).

[wtarreau]

4 hours ago, JMCC said:

I'm not sure whether they correspond exactly with the number you set, but I can tell they mean a real higher clock speed. I tried with HK's image, and increasing the clock speed through that method causes an increase in hashes/sec with a CPU miner (like ~14.50 hash/s at 1512MHz, vs ~16.50 at 1752Mhz).

I understood as well that HK got their hands on the blob part and were able to figure the highest stable frequency they could use. I don't know how this blob is used but definitely without it you won't go above 1.5 GHz.

[TonyMac32]

@wtarreau right, I haven't tried to go past "stock" 1.5 GHz since I haven't really had reason, however on my little bit of testing comparing to some data I think you had, I was able to verify the C2 was the only Amlogic board I have running at the clock speed it was reporting.

[bolemo]

Any news on cpu max freq support on Odroid C2?

With armbian kernel 5.x, I can't go beyond 1.5 Ghz.

I used to run at 1.7 before I switched to armbian buster (from ubuntu 18 with hardkernel kernel 3.x)

 

Also, is there an equivalent of setEnv nographics "1" in armbian kernel?

[Igor]

7 hours ago, bolemo said:

I used to run at 1.7 before I switched to armbian buster (from ubuntu 18 with hardkernel kernel 3.x)

Armbian shows real speed, while hardware vendors (Amlogic not Hardkernel) are sometimes selling you bullshit.
 

 

[bolemo]

On 8/15/2020 at 7:33 PM, Igor said:

Armbian shows real speed, while hardware vendors (Amlogic not Hardkernel) are sometimes selling you bullshit.
 

 

It made a real difference for me between 15xx and 17xx. I’ve read somewhere that in the case of Odroid C2, armlogic cpu frequencies are accurate (but not so much for other).

[Igor]

10 minutes ago, bolemo said:

It made a real difference for me

This is exactly how the victims of cheating will feel. We can say higher numbers are just a https://en.wikipedia.org/wiki/Placebo Very common.

 

14 minutes ago, bolemo said:

I’ve read somewhere that in the case of Odroid C2, armlogic cpu frequencies are accurate (but not so much for other).

Now they are since no cheating last long. Perhaps this will open your eyes:
https://www.cnx-software.com/2016/08/28/amlogic-s905-and-s912-processors-appear-to-be-limited-to-1-5-ghz-not-2-ghz-as-advertised/#comment-530956

[NicoD]

On 8/15/2020 at 7:33 PM, Igor said:

On 8/15/2020 at 11:43 AM, bolemo said:

I used to run at 1.7 before I switched to armbian buster (from ubuntu 18 with hardkernel kernel 3.x)

Armbian shows real speed, while hardware vendors (Amlogic not Hardkernel) are sometimes selling you bullshit.

The C2 can really run at 1.75Ghz well. After it was found out they cheated Hardkernel has tried a lot to overclock. I've used 1.75Ghz for years on it with ram OC. Haven't used the C2 with armbian in a long time. So no idea how it is.
Here the numbers t prove it was 1.75Ghz.
 

Odroid C2              |SBC bench result  |CPU Miner          |7-zip big core           |7-zip multi avg. of 3 |Blender    
Armbian Stretch Core    http://ix.io/1pZu  4.65kH/s            1390                      5342
Armbian Stretch Core Nightly //ix.io/1pZJ  4.66kH/s            1391                      5340
Armbian Stretch Desktop http://ix.io/1q1C  4.65kH/s            1394                      5363                              
Armbian Stretch Desktop NGHT //ix.io/1p02  4.59kH/s            1394                      5356                   2h38m18s    

Meveric Stetch  No-OC                                          1337                      5223                   2h40m00s   

Meveric Stretch Only RAM OC                                    1361                      5292                               
Meveric Stretch OC 1.75Ghz                                     1548                      6049                   2h14m17s            
Ubuntu Mate Bionic OC   SBCBench Don't work/Clocked to 100Mhz  1607                      5960                   2h10m21s   

Clearly OC was not on Armbian or else I'd done the OC benchmarks in Armbian too.
 

 

4 hours ago, bolemo said:

It made a real difference for me between 15xx and 17xx. I’ve read somewhere that in the case of Odroid C2, armlogic cpu frequencies are accurate (but not so much for other). Still love the C2. Great SBC.

Maybe Meveric his Debian images are better for you, or the Ubuntu from Hardkernel. I'm a big Armbian fan, but rarely used it on the C2 since there are better choices for my needs.

[Igor]

But you probably need to use different boot blob and EOL legacy 3.14.y / 3.16.y kernel? AFAIK mainline kernel - which is what we only provide for C2 - is not having support for higher numbers. Well, if someone feels the need for this ... https://docs.armbian.com/Process_Contribute/ 

[bolemo]

To be clear, when I was talking about real difference, I was not talking about a feeling but a concrete difference (same task maxing CPU at 1.5 but not at 1.7).

 

Now, the whole idea is to have the mainline kernel to support all C2 frequencies.

I don’t know much about kernels and how I could help to add frequencies.

Since all is open source why is it so hard? Should not that be just adding the frequencies to a file or some settings in the mainline kernel?

[hexdump]

it does not work as the cpu frequencies are controlled by a non open source binary blob firmware running on an invisible m3 core in your soc - hardkernel had created a special blob for the c2 which was dongled to their stuff and quite unstable at higher freqs with all cores on - so no way for mainline

[JMCC]

Just to be clear: last time I checked, our mainline was using the custom HK blob for the C2 ( @TonyMac32 can you confirm this?). 

 

Which means that, even though the max frequency is 1.5 GHz, you get the real frequency. Unlike all the other S905' that report 1.5 but are actually running 1.4 GHz.

 

Now, in order to unlock higher frequencies, you need patches both for the kernel and for the DT. The patches were done for HK's 3.16.x kernel, and it may or may not be possible to port them to mainline.

 

On 8/18/2020 at 10:24 AM, bolemo said:

Since all is open source why is it so hard?

It is probably not hard. But it needs a person to dive into the old 3.16.x kernel, extract the patches, and try to adapt them to mainline. You're welcome to try, you will for sure learn a lot, whether you finally get to fix it or not 

[JMCC]

On 8/17/2020 at 2:45 AM, NicoD said:

Clearly OC was not on Armbian

It used to work once upon a time, like 2018-ish. But it broke at some point in the latest legacy images.

[bolemo]

On 8/22/2020 at 11:18 PM, JMCC said:

Just to be clear: last time I checked, our mainline was using the custom HK blob for the C2 ( @TonyMac32 can you confirm this?). 

 

Which means that, even though the max frequency is 1.5 GHz, you get the real frequency. Unlike all the other S905' that report 1.5 but are actually running 1.4 GHz.

 

Now, in order to unlock higher frequencies, you need patches both for the kernel and for the DT. The patches were done for HK's 3.16.x kernel, and it may or may not be possible to port them to mainline.

 

It is probably not hard. But it needs a person to dive into the old 3.16.x kernel, extract the patches, and try to adapt them to mainline. You're welcome to try, you will for sure learn a lot, whether you finally get to fix it or not 

I sure would like to do that, but I have zero experience in Linux kernels so...