TonyMac32 Posted November 12, 2018 Posted November 12, 2018 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 0 Quote
TonyMac32 Posted November 13, 2018 Author Posted November 13, 2018 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 0 Quote
matt407 Posted November 14, 2018 Posted November 14, 2018 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. 0 Quote
mboehmer Posted November 16, 2018 Posted November 16, 2018 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 0 Quote
TonyMac32 Posted November 17, 2018 Author Posted November 17, 2018 @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. 0 Quote
mboehmer Posted November 17, 2018 Posted November 17, 2018 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 0 Quote
TonyMac32 Posted November 17, 2018 Author Posted November 17, 2018 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. 0 Quote
TonyMac32 Posted November 18, 2018 Author Posted November 18, 2018 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. 0 Quote
picosoft Posted December 26, 2018 Posted December 26, 2018 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. 0 Quote
TonyMac32 Posted December 26, 2018 Author Posted December 26, 2018 If you know how to make overlays, you can give nightly dev images a try, I haven't made PWM overlays yet though. 0 Quote
oleid Posted December 29, 2018 Posted December 29, 2018 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 0 Quote
TonyMac32 Posted December 29, 2018 Author Posted December 29, 2018 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. 0 Quote
oleid Posted December 29, 2018 Posted December 29, 2018 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. 0 Quote
JMCC Posted January 15, 2019 Posted January 15, 2019 Sorry if the question seems silly, but is there any way to set the higher clock speeds with the mainline kernel? 0 Quote
TonyMac32 Posted January 15, 2019 Author Posted January 15, 2019 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) 0 Quote
JMCC Posted January 15, 2019 Posted January 15, 2019 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? 0 Quote
TonyMac32 Posted January 15, 2019 Author Posted January 15, 2019 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. 0 Quote
JMCC Posted January 15, 2019 Posted January 15, 2019 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). 0 Quote
wtarreau Posted January 16, 2019 Posted January 16, 2019 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. 0 Quote
TonyMac32 Posted January 16, 2019 Author Posted January 16, 2019 @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. 0 Quote
bolemo Posted August 15, 2020 Posted August 15, 2020 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? 0 Quote
Igor Posted August 15, 2020 Posted August 15, 2020 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. 1 Quote
bolemo Posted August 16, 2020 Posted August 16, 2020 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). 0 Quote
Igor Posted August 16, 2020 Posted August 16, 2020 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 0 Quote
NicoD Posted August 17, 2020 Posted August 17, 2020 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. 0 Quote
Igor Posted August 17, 2020 Posted August 17, 2020 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/ 1 Quote
bolemo Posted August 18, 2020 Posted August 18, 2020 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? 0 Quote
hexdump Posted August 18, 2020 Posted August 18, 2020 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 0 Quote
JMCC Posted August 22, 2020 Posted August 22, 2020 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 1 Quote
JMCC Posted August 22, 2020 Posted August 22, 2020 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. 1 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.