Playing with upstream (Exynos4412)

Share here your ideas for new projects

Moderators: odroid, meveric, mdrjr

Re: Playing with upstream (Exynos4412)

Unread postby memeka » Thu Jun 16, 2016 12:57 pm

Hi @LiquidAcid

I tried your kernel on the odroid-u3+. Installing on eMMC is a bit tricky - for those that want to try, you need to modify the sd_fusing script with the eMMC offsets (defaults are for SD) and also modify boot.scr and fstab to use mmcblk1 instead of mmcblk0. I tried using UUID instead of mmcblk but it did not work (got stuck at waiting for root device).

My issue is that I don't have HDMI output.
Here's the dmesg: http://paste.ubuntu.com/17390059/
Here's my config (it's based on your config + wifi drivers): http://paste.ubuntu.com/17390064/

Any idea why this happens?
EDIT: and you can see from dmesg, there are errors with the mali driver too...

Thanks.
Last edited by memeka on Fri Jun 17, 2016 6:03 am, edited 1 time in total.
User avatar
memeka
 
Posts: 3356
Joined: Mon May 20, 2013 10:22 am
languages_spoken: english
ODROIDs: XU rev2 + eMMC + UART
U3 + eMMC + IO Shield + UART

Re: Playing with upstream (Exynos4412)

Unread postby memeka » Fri Jun 17, 2016 5:50 am

More:

poweroff/reboot is not working properly, and eMMC support is not complete - after a poweroff/reboot command (reboot does not work) the eMMC is not reseted, so subsequent boots (even after disconnecting the power) will result in kernel panics. The only way to "fix" this was to disconnect the power while the kernel was loading, before it panics.

EDIT: power reset was enabled:
Code: Select all
$ cat .config | grep POWER_RESET
CONFIG_POWER_RESET=y
# CONFIG_POWER_RESET_BRCMSTB is not set
# CONFIG_POWER_RESET_GPIO is not set
# CONFIG_POWER_RESET_GPIO_RESTART is not set
# CONFIG_POWER_RESET_LTC2952 is not set
# CONFIG_POWER_RESET_RESTART is not set
# CONFIG_POWER_RESET_VERSATILE is not set
CONFIG_POWER_RESET_SYSCON=y
CONFIG_POWER_RESET_SYSCON_POWEROFF=y

any ideas why this still happens?

EDIT: looks like this is NOT an eMMC issue, I had the same when i tried with sd-card.
User avatar
memeka
 
Posts: 3356
Joined: Mon May 20, 2013 10:22 am
languages_spoken: english
ODROIDs: XU rev2 + eMMC + UART
U3 + eMMC + IO Shield + UART

Re: Playing with upstream (Exynos4412)

Unread postby memeka » Sun Jun 19, 2016 12:07 pm

I switched to my U3, same kernel panics.
The reboot issue was because of governor at least on 4.4 U3.
Now with 4.4 on U3, EMMC, reboot works. There are still some panics in Mali and still don't have a terminal console tho.
User avatar
memeka
 
Posts: 3356
Joined: Mon May 20, 2013 10:22 am
languages_spoken: english
ODROIDs: XU rev2 + eMMC + UART
U3 + eMMC + IO Shield + UART

Re: Playing with upstream (Exynos4412)

Unread postby LiquidAcid » Mon Jun 27, 2016 1:58 am

- odroid-4.5.y is EOL, branch locked
- odroid-4.6.y rebased on stable/linux-4.6.3
- pushed odroid-4.7.y to linux-odroid-public

odroid-4.7.y is currently based on torvalds/master (which is rc4 + epsilon). I did another rewrite of the G2D command parser since the last design didn't accommodate for some planned features. The current parser should be more robust and a bit faster. The API is still compatible and I dropped the coordinate register grouping restriction. I also added a working reset API in case the engine hangs, so less system restarts when debugging.

I don't think the parser is going to change much now, except for some tweaks. Once the remaining bits are implemented I'll try to upstream the changes.

TODO:
- clipping window (window coordinates have to be checked against the destination rectangle)
- rotation (needs some coordinate swapping, interacts with rectangle validation)
- YCbCr support

Basic infrastructure for YCbCr is there but I've yet to write some tests which check if stride and coordinate validation works correctly.
LiquidAcid
 
Posts: 1053
Joined: Fri Oct 11, 2013 11:07 pm
languages_spoken: english
ODROIDs: X2

Re: Playing with upstream (Exynos4412)

Unread postby memeka » Mon Jun 27, 2016 6:16 am

@LiquidAcid - any ideas why
* no console output on U3
* pretty unstable (sometimes there's still some panics on reboot)?

EDIT: also, any thoughts if for U3 shield do i need HK's driver, or should it work with something from the mainline?
User avatar
memeka
 
Posts: 3356
Joined: Mon May 20, 2013 10:22 am
languages_spoken: english
ODROIDs: XU rev2 + eMMC + UART
U3 + eMMC + IO Shield + UART

Re: Playing with upstream (Exynos4412)

Unread postby memeka » Mon Jun 27, 2016 12:13 pm

also, reboot still not working even with performance gov (on 4.4 or 4.6 kernels):

Code: Select all
[  OK  ] Stopped Apply Kernel Variables.
[  OK  ] Stopped Load Kernel Modules.
[  OK  ] Stopped Network Time Synchronization.
[  OK  ] Stopped Load/Save Random Seed.
[  OK  ] Stopped Update UTMP about System Boot/Shutdown.
[  OK  ] Stopped Create Volatile Files and Directories.
[  OK  ] Stopped target Local File Systems.
         Unmounting /boot...
         Unmounting /tmp...
[  OK  ] Unmounted /tmp.
[  OK  ] Unmounted /boot.
[  OK  ] Reached target Unmount All Filesystems.
[  OK  ] Stopped target Local File Systems (Pre).
[  OK  ] Stopped Create Static Device Nodes in /dev.
[  OK  ] Stopped Remount Root and Kernel File Systems.
[  OK  ] Reached target Shutdown.
[  OK  ] Reached target Final Step.
         Starting Reboot...
[


maybe uboot?
User avatar
memeka
 
Posts: 3356
Joined: Mon May 20, 2013 10:22 am
languages_spoken: english
ODROIDs: XU rev2 + eMMC + UART
U3 + eMMC + IO Shield + UART

Re: Playing with upstream (Exynos4412)

Unread postby memeka » Sun Jul 10, 2016 9:30 am

looks like nobody seems interested in these issues.

anyway, console output was fixed by forcing DVI mode in exynos_hdmi.c and using edid binary blobs compiled into the kernel (seems like i have a bad monitor).

i still have issues with reboot. reboot works fine for me on the samsung 4.1 tizen kernel, but it hangs on all the LiquidAcid kernels. i have tried using the 4.1 pmu.c code that contained the reboot notifier, and removing the syscon power (and the exynos-syscon dtsi entry), but it behaves the same. I put some printk's in syscon - i do get the reboot notifier registered, but there's no printk from the actual reboot notifier function. I have no idea how to debug this further.

Interestingly, reboot via sysrq (echo b > /proc/sysrq-trigger) works fine. So maybe it's not a kernel issue, but systemd? Then why does the 4.1 reboot works?
Maybe related, the S3C2410 watchdog may not work properly. I get this message in the log:

Code: Select all
Jul 10 00:17:10 adolin systemd[1]: Reached target Final Step.
Jul 10 00:17:10 adolin systemd[1]: Starting Reboot...
Jul 10 00:17:10 adolin systemd[1]: Shutting down.
Jul 10 00:17:11 adolin systemd[1]: Hardware watchdog 'S3C2410 Watchdog', version 0
Jul 10 00:17:11 adolin systemd[1]: Failed to set timeout to 254s: Invalid argument
Jul 10 00:17:11 adolin systemd-shutdown[1]: Sending SIGTERM to remaining processes...
Jul 10 00:17:11 adolin systemd-journald[949]: Journal stopped


The initial value was 600, but some watchdog drivers use a char to store the value, so I reduced the value to 254 in /etc/systemd/system.conf (ShutdownWatchdogSec). But even with 254, i still get this error.

I would appreciate any ideas in fixing this.

PS: @LiquidAcid - what mali binary blobs are you using?

EDIT: log from working 4.1 kernel:

Code: Select all
Jul 10 00:35:37 adolin systemd[1]: Starting Reboot...
Jul 10 00:35:37 adolin systemd[1]: Shutting down.
Jul 10 00:35:37 adolin systemd[1]: Hardware watchdog 'S3C2410 Watchdog', version 0
Jul 10 00:35:37 adolin systemd[1]: Failed to set timeout to 254s: Invalid argument
Jul 10 00:35:37 adolin kernel: s3c2410-wdt 10060000.watchdog: timeout 254 too big
Jul 10 00:35:37 adolin systemd-shutdown[1]: Sending SIGTERM to remaining processes...
Jul 10 00:35:37 adolin systemd-journald[826]: Journal stopped


EDIT2: with the watchdog code from 4.1 - reboot still hangs :(

EDIT2: 4.6.3 with 4.1 dtb's behave more randomly, sometimes reboot works, sometimes it hangs with the last console message:
[ 35.274765] reboot: Restarting system
whereas 4.6.3 with 4.6.3 dtb's last message is:
[ or at most: [ 35.274765] re
User avatar
memeka
 
Posts: 3356
Joined: Mon May 20, 2013 10:22 am
languages_spoken: english
ODROIDs: XU rev2 + eMMC + UART
U3 + eMMC + IO Shield + UART

Re: Playing with upstream (Exynos4412)

Unread postby Panzerknacker » Sun Jul 10, 2016 5:36 pm

There is an upcoming reboot driver in -next that might solve your reboot problems:

-*- Generic SYSCON regmap reset driver │ │
-*- Generic SYSCON regmap poweroff driver │ │
<*> Generic SYSCON regmap reboot mode driver
User avatar
Panzerknacker
 
Posts: 237
Joined: Sat Feb 22, 2014 10:08 pm
languages_spoken: German, English
ODROIDs: U3, X, XU, XU3, XU4, W

Re: Playing with upstream (Exynos4412)

Unread postby memeka » Sun Jul 10, 2016 9:28 pm

Panzerknacker wrote:There is an upcoming reboot driver in -next that might solve your reboot problems:

-*- Generic SYSCON regmap reset driver │ │
-*- Generic SYSCON regmap poweroff driver │ │
<*> Generic SYSCON regmap reboot mode driver


I doubt it.

This driver parses the reboot commands like "reboot bootloader"
and "reboot recovery" to get a boot mode described in the
device tree
User avatar
memeka
 
Posts: 3356
Joined: Mon May 20, 2013 10:22 am
languages_spoken: english
ODROIDs: XU rev2 + eMMC + UART
U3 + eMMC + IO Shield + UART

Re: Playing with upstream (Exynos4412)

Unread postby memeka » Sat Jul 16, 2016 8:05 am

to put things to rest:
after changing the config, probably CONFIG_POWER_RESET=y did the trick and now i can reboot.
the funny bit is that reboot still hangs when issued from the serial console. but from tty1 or ssh it works.
here's my config: http://paste.debian.net/781849/

it provides a more close experience to the HK 3.8 kernel, with wireless drivers for the odroid wifi adapters (all of them), mali, mfc, fimc, etc ... enabled. i even added the i2c-gpio-custom module in my kernel tree to enable the u3 io shield, and changed the hdmi driver to work in dvi mode by default, solving issues for some monitors. ping me here anyone that wants me to github my tree.

i've tested MFC, and works fantasically - decoding that used all 4 cores @ 100% was then using one core @ max 40%.
gstreamer has an experimental encoder as well for mfc, and i was able to encode in h264, but it's not very stable yet.
the only major problem is with the FIMC driver (for colorspace conversion) - which has issues when accessed via the v4l2 interface. so probably kodi won't work, and a media player would still be slow due to software color conversion.
And even with that, things might be slow due to the u-boot mpll clock.

@LiquidAcid - maybe i get an answer this time: i see you got a patch for mpll clock in your u-boot repo. it it working? is it stable?

EDIT: well ... reboot still works only sometimes :o :evil:
User avatar
memeka
 
Posts: 3356
Joined: Mon May 20, 2013 10:22 am
languages_spoken: english
ODROIDs: XU rev2 + eMMC + UART
U3 + eMMC + IO Shield + UART

Re: Playing with upstream (Exynos4412)

Unread postby deivid » Mon Aug 01, 2016 9:12 am

With "CONFIG_POWER_RESET=y" I always get hangs on reboot on u2. Although our configs are pretty different

diff asd /boot/config-4.6.4-gb5ce513 | wc -l
2189
deivid
 
Posts: 52
Joined: Wed Jun 05, 2013 11:34 pm
languages_spoken: english, spanish
ODROIDs: U2

Re: Playing with upstream (Exynos4412)

Unread postby memeka » Mon Aug 01, 2016 10:50 am

Since this issue now made it to samsung-soc mailinglist, a possible solution was to increase the CPU voltage - that made things a bit better, I could reboot *sometime* but it was still not a fix - I would still have hangs on reboot sometimes.

Currently, I've set min freq in dt to 1Ghz (it's enough for my workload), and disabled CPUFREQ in kernel. It's been running stable for a while now, and no more hangs on reboot.

To answer my question in prev message - @LiquidAcid's u-boot with mpll patch applied is not able to boot atm.
User avatar
memeka
 
Posts: 3356
Joined: Mon May 20, 2013 10:22 am
languages_spoken: english
ODROIDs: XU rev2 + eMMC + UART
U3 + eMMC + IO Shield + UART

Re: Playing with upstream (Exynos4412)

Unread postby daviessm » Mon Aug 01, 2016 5:36 pm

memeka wrote:Since this issue now made it to samsung-soc mailinglist, a possible solution was to increase the CPU voltage - that made things a bit better, I could reboot *sometime* but it was still not a fix - I would still have hangs on reboot sometimes.

Currently, I've set min freq in dt to 1Ghz (it's enough for my workload), and disabled CPUFREQ in kernel. It's been running stable for a while now, and no more hangs on reboot.

I had a similar issue when I first started using this kernel, I worked around it by setting the CPU governor to performance just before a reboot. Have you tried that?
daviessm
 
Posts: 84
Joined: Thu Jul 25, 2013 2:14 am
Location: Belfast, UK
languages_spoken: English, German
ODROIDs: X2, XU4

Re: Playing with upstream (Exynos4412)

Unread postby memeka » Mon Aug 01, 2016 9:18 pm

yes, i compiled the kernel with only performance governor. on u3 i always ran with only performance gov...
User avatar
memeka
 
Posts: 3356
Joined: Mon May 20, 2013 10:22 am
languages_spoken: english
ODROIDs: XU rev2 + eMMC + UART
U3 + eMMC + IO Shield + UART

Re: Playing with upstream (Exynos4412)

Unread postby LiquidAcid » Mon Sep 26, 2016 11:02 pm

I have been busy lately, so here's a late update:
- odroid-4.5.y was removed
- odroid-4.6.y rebased on stable/linux-4.6.7 and branch locked (EOL upstream)
- odroid-4.7.y rebased on stable/linux-4.7.5
- pushed odroid-4.8.y to linux-odroid-public

odroid-4.8.y is currently based on torvalds/master (which is rc8 + some patches). I tweaked by G2D command parser some more, but it's slowly settling down. Due to some upstream changes to runtime PM support, I had to rewrite PM handling in the driver. In particular this should improve performance a bit, since the clock is now only gated when the engine is idle for long enough. This also applies to enabling/disabling the corresponding IOMMU (see below). Because of this rewrite I also changed the reset API. The YCbCr support should also be completed, minus some weird restrictions with respect to scaling, which I still need to model correctly.
I also looked more deeply into the relation between engine clock and DMC clock. With the current overclock to 400MHz, starting the engine with a DMC clock below 400MHz results in HCF. My current workaround is to abuse devfreq to lock the minimal frequency when the device is opened.

The new IOMMU patchset by Marek is applied, together with hack/workaround that allows for proper shutdown/reboot. It's probably going through some more iterations before it can land.
Also Andrzej's patches to the vblank handling code are worth pointing out.

The 'clipping window' and 'rotation' items from the previous TODO list are still valid.
LiquidAcid
 
Posts: 1053
Joined: Fri Oct 11, 2013 11:07 pm
languages_spoken: english
ODROIDs: X2

Re: Playing with upstream (Exynos4412)

Unread postby LiquidAcid » Sun Oct 02, 2016 8:03 am

Pushed some small update to odroid-4.8.y. The RGB range (narrow/full) of the mixer/HDMI can now be controlled through userspace. A CRTC property 'RGB Range' is introduced.

Code: Select all
liquid@chidori ~/sourcecode/video/drm/tests/modetest $ ./modetest -M exynos
Encoders:
id   crtc   type   possible crtcs   possible clones   
34   0   TMDS   0x00000001   0x00000000
44   0   TMDS   0x00000002   0x00000000
53   0   TMDS   0x00000004   0x00000000

Connectors:
id   encoder   status      name      size (mm)   modes   encoders
35   0   connected   VGA-1             0x0      1   34
  modes:
   name refresh (Hz) hdisp hss hse htot vdisp vss vse vtot)
  1366x768 0 1366 1414 1446 1526 768 771 776 790 500 flags: phsync, pvsync; type: preferred, driver
  props:
   1 EDID:
      flags: immutable blob
      blobs:

      value:
   2 DPMS:
      flags: enum
      enums: On=0 Standby=1 Suspend=2 Off=3
      value: 0
45   0   disconnected   HDMI-A-1          0x0      0   44
  props:
   1 EDID:
      flags: immutable blob
      blobs:

      value:
   2 DPMS:
      flags: enum
      enums: On=0 Standby=1 Suspend=2 Off=3
      value: 0
54   0   disconnected   Virtual-1         0x0      0   53
  props:
   2 DPMS:
      flags: enum
      enums: On=0 Standby=1 Suspend=2 Off=3
      value: 0

CRTCs:
id   fb   pos   size
33   0   (0,0)   (0x0)
   0 0 0 0 0 0 0 0 0 0 flags: ; type:
  props:
42   0   (0,0)   (0x0)
   0 0 0 0 0 0 0 0 0 0 flags: ; type:
  props:
   43 RGB Range:
      flags: enum
      enums: Automatic=0 Full=1 Narrow (16:235)=2
      value: 0
52   0   (0,0)   (0x0)
   0 0 0 0 0 0 0 0 0 0 flags: ; type:
  props:

Planes:
id   crtc   fb   CRTC x,y   x,y   gamma size   possible crtcs
23   0   0   0,0      0,0   0          0x00000001
  formats: C8   XR15 RG16 XR24 AR24
  props:
   5 type:
      flags: immutable enum
      enums: Overlay=0 Primary=1 Cursor=2
      value: 1
   24 zpos:
      flags: immutable range
      values: 0 0
      value: 0
25   0   0   0,0      0,0   0          0x00000001
  formats: C8   XR15 RG16 XR24 AR24
  props:
   5 type:
      flags: immutable enum
      enums: Overlay=0 Primary=1 Cursor=2
      value: 0
   26 zpos:
      flags: immutable range
      values: 0 0
      value: 0
27   0   0   0,0      0,0   0          0x00000001
  formats: C8   XR15 RG16 XR24 AR24
  props:
   5 type:
      flags: immutable enum
      enums: Overlay=0 Primary=1 Cursor=2
      value: 0
   28 zpos:
      flags: immutable range
      values: 0 0
      value: 0
29   0   0   0,0      0,0   0          0x00000001
  formats: C8   XR15 RG16 XR24 AR24
  props:
   5 type:
      flags: immutable enum
      enums: Overlay=0 Primary=1 Cursor=2
      value: 0
   30 zpos:
      flags: immutable range
      values: 0 0
      value: 0
31   0   0   0,0      0,0   0          0x00000001
  formats: C8   XR15 RG16 XR24 AR24
  props:
   5 type:
      flags: immutable enum
      enums: Overlay=0 Primary=1 Cursor=2
      value: 2
   32 zpos:
      flags: immutable range
      values: 0 0
      value: 0
36   0   0   0,0      0,0   0          0x00000002
  formats: XR12 AR12 XR15 AR15 RG16 XR24 AR24
  props:
   5 type:
      flags: immutable enum
      enums: Overlay=0 Primary=1 Cursor=2
      value: 1
   37 zpos:
      flags: range
      values: 0 4
      value: 0
38   0   0   0,0      0,0   0          0x00000002
  formats: XR12 AR12 XR15 AR15 RG16 XR24 AR24
  props:
   5 type:
      flags: immutable enum
      enums: Overlay=0 Primary=1 Cursor=2
      value: 2
   39 zpos:
      flags: range
      values: 0 4
      value: 1
40   0   0   0,0      0,0   0          0x00000002
  formats: NV12 NV21
  props:
   5 type:
      flags: immutable enum
      enums: Overlay=0 Primary=1 Cursor=2
      value: 0
   41 zpos:
      flags: range
      values: 0 4
      value: 2
46   0   0   0,0      0,0   0          0x00000004
  formats: XR24 AR24 NV12
  props:
   5 type:
      flags: immutable enum
      enums: Overlay=0 Primary=1 Cursor=2
      value: 1
   47 zpos:
      flags: immutable range
      values: 0 0
      value: 0
48   0   0   0,0      0,0   0          0x00000004
  formats: XR24 AR24 NV12
  props:
   5 type:
      flags: immutable enum
      enums: Overlay=0 Primary=1 Cursor=2
      value: 0
   49 zpos:
      flags: immutable range
      values: 0 0
      value: 0
50   0   0   0,0      0,0   0          0x00000004
  formats: XR24 AR24 NV12
  props:
   5 type:
      flags: immutable enum
      enums: Overlay=0 Primary=1 Cursor=2
      value: 2
   51 zpos:
      flags: immutable range
      values: 0 0
      value: 0

Frame buffers:
id   size   pitch
LiquidAcid
 
Posts: 1053
Joined: Fri Oct 11, 2013 11:07 pm
languages_spoken: english
ODROIDs: X2

Re: Playing with upstream (Exynos4412)

Unread postby LiquidAcid » Thu Oct 06, 2016 6:08 pm

Some misc changes:
- 4.8 is out of rc-phase, so I rebased onto stable-4.8.0
- the aforementioned frequency locking is now done in runtime PM handlers
- IOMMU runtime PM patchsets updated to v4

I'm still seeing an Oops on reboot/shutdown which is most likely related to the 'functional dependencies' (see here) patchset by Rafael. I'm only able to reproduce this on my non-debug config, so something is fishy here. Might be another of these list corruptions that Marek has already fixed plenty of.
LiquidAcid
 
Posts: 1053
Joined: Fri Oct 11, 2013 11:07 pm
languages_spoken: english
ODROIDs: X2

Re: Playing with upstream (Exynos4412)

Unread postby LiquidAcid » Sun Oct 09, 2016 9:46 am

Rebased onto stable-4.8.1 and fixed up some stuff (thanks to Markus for the heads up). Reboot and shutdown is working again.
LiquidAcid
 
Posts: 1053
Joined: Fri Oct 11, 2013 11:07 pm
languages_spoken: english
ODROIDs: X2

Re: Playing with upstream (Exynos4412)

Unread postby LiquidAcid » Sat Oct 22, 2016 11:28 pm

The usual update:
- removed odroid-4.6.y
- rebased odroid-4.7.y on stable/linux-4.7.10 and locked branch (4.7.y is not officially EOL, but I doubt there's going to be a 4.7.11)
- rebased odroid-4.8.y on stable/linux-4.8.4
- updated the X2 guide on the Exynos Wiki

First steps with 4.9-rc1 done, but I have so far only checked if things compile. Probably not going to push until some of the later rcs.
LiquidAcid
 
Posts: 1053
Joined: Fri Oct 11, 2013 11:07 pm
languages_spoken: english
ODROIDs: X2

Re: Playing with upstream (Exynos4412)

Unread postby krinekk » Fri Oct 28, 2016 1:18 am

I've downloaded this kernel and compiling by myself and I have some sort of questions:

1. Which odroid image did you use?
2. Are the I2C enabled? I cannot see /dev/i2c-* (with kernel option enabled) Maybe I miss something?

Thank you
krinekk
 
Posts: 7
Joined: Mon Oct 03, 2016 11:41 pm
languages_spoken: english, spanish
ODROIDs: odroid-x, odroid-x2

Re: Playing with upstream (Exynos4412)

Unread postby LiquidAcid » Fri Oct 28, 2016 6:59 am

Back when I installed the system I used an ALARM image to bootstrap my Gentoo installation. In that sense I'm not using any of the various images found on the forums.
No idea about I2C, I don't use any peripherical hw connected to that bus.
LiquidAcid
 
Posts: 1053
Joined: Fri Oct 11, 2013 11:07 pm
languages_spoken: english
ODROIDs: X2

Re: Playing with upstream (Exynos4412)

Unread postby Panzerknacker » Fri Oct 28, 2016 4:39 pm

krinekk wrote:Are the I2C enabled? I cannot see /dev/i2c-* (with kernel option enabled) Maybe I miss something?


Do you have the following in your kernel config?

CONFIG_I2C_CHARDEV=y
CONFIG_HAVE_S3C2410_I2C=y
CONFIG_I2C_S3C2410=y
User avatar
Panzerknacker
 
Posts: 237
Joined: Sat Feb 22, 2014 10:08 pm
languages_spoken: German, English
ODROIDs: U3, X, XU, XU3, XU4, W

Re: Playing with upstream (Exynos4412)

Unread postby krinekk » Fri Oct 28, 2016 10:42 pm

Panzerknacker wrote:
Do you have the following in your kernel config?

CONFIG_I2C_CHARDEV=y
CONFIG_HAVE_S3C2410_I2C=y
CONFIG_I2C_S3C2410=y


I have the 3 configs enabled, I have i2c-dev enabled also.
krinekk
 
Posts: 7
Joined: Mon Oct 03, 2016 11:41 pm
languages_spoken: english, spanish
ODROIDs: odroid-x, odroid-x2

Re: Playing with upstream (Exynos4412)

Unread postby LiquidAcid » Fri Oct 28, 2016 11:06 pm

This is on my X2:
Code: Select all
liquid@chidori ~ $ for arg in /sys/class/i2c-dev/i2c-?; do cat $arg/name; done
s3c2410-i2c
s3c2410-i2c
s3c2410-i2c
s3c2410-i2c
LiquidAcid
 
Posts: 1053
Joined: Fri Oct 11, 2013 11:07 pm
languages_spoken: english
ODROIDs: X2

Re: Playing with upstream (Exynos4412)

Unread postby krinekk » Fri Oct 28, 2016 11:53 pm

LiquidAcid wrote:This is on my X2:
Code: Select all
liquid@chidori ~ $ for arg in /sys/class/i2c-dev/i2c-?; do cat $arg/name; done
s3c2410-i2c
s3c2410-i2c
s3c2410-i2c
s3c2410-i2c


I've got the same looking on that place, but to use i2c-tools, it is needed that i2c are mounted on /dev, but it is not. Maybe there's some bug on mounting or the module are not correcly actived. When I call lsmod, the result are empty.
krinekk
 
Posts: 7
Joined: Mon Oct 03, 2016 11:41 pm
languages_spoken: english, spanish
ODROIDs: odroid-x, odroid-x2

Re: Playing with upstream (Exynos4412)

Unread postby LiquidAcid » Sat Oct 29, 2016 12:12 am

krinekk wrote:I've got the same looking on that place, but to use i2c-tools, it is needed that i2c are mounted on /dev, but it is not.

It is for me, all four nodes show up.

krinekk wrote:Maybe there's some bug on mounting or the module are not correcly actived. When I call lsmod, the result are empty.

I don't think you can have s3c2410-i2c as module, since it is vital for system operation. In particular the PMIC is on the i2c bus.
LiquidAcid
 
Posts: 1053
Joined: Fri Oct 11, 2013 11:07 pm
languages_spoken: english
ODROIDs: X2

Re: Playing with upstream (Exynos4412)

Unread postby krinekk » Sat Oct 29, 2016 12:19 am

LiquidAcid wrote:
krinekk wrote:I've got the same looking on that place, but to use i2c-tools, it is needed that i2c are mounted on /dev, but it is not.

It is for me, all four nodes show up.

krinekk wrote:Maybe there's some bug on mounting or the module are not correcly actived. When I call lsmod, the result are empty.

I don't think you can have s3c2410-i2c as module, since it is vital for system operation. In particular the PMIC is on the i2c bus.


I can check that i2c are working because I'm using a touchscreen with i2c and it's working, but I cannto access to the register bank to check the info contained. Also, the max77686-rtc are not setting up the clock, maybe that issue are related.
krinekk
 
Posts: 7
Joined: Mon Oct 03, 2016 11:41 pm
languages_spoken: english, spanish
ODROIDs: odroid-x, odroid-x2

Re: Playing with upstream (Exynos4412)

Unread postby LiquidAcid » Sat Oct 29, 2016 12:28 am

No idea what you're doing, but none of the i2c busses enabled have anything to do with a touchscreen.
Code: Select all
i2c_0: PMIC
i2c_1: audio codec
i2c_2: HDMI/DDC
i2c_8: HDMI/PHY
LiquidAcid
 
Posts: 1053
Joined: Fri Oct 11, 2013 11:07 pm
languages_spoken: english
ODROIDs: X2

Re: Playing with upstream (Exynos4412)

Unread postby Panzerknacker » Sat Oct 29, 2016 12:33 am

root@odroidu3:~# ls /dev/i2*
/dev/i2c-0 /dev/i2c-1 /dev/i2c-2 /dev/i2c-4 /dev/i2c-8
User avatar
Panzerknacker
 
Posts: 237
Joined: Sat Feb 22, 2014 10:08 pm
languages_spoken: German, English
ODROIDs: U3, X, XU, XU3, XU4, W

Re: Playing with upstream (Exynos4412)

Unread postby krinekk » Sat Oct 29, 2016 12:43 am

Panzerknacker wrote:root@odroidu3:~# ls /dev/i2*
/dev/i2c-0 /dev/i2c-1 /dev/i2c-2 /dev/i2c-4 /dev/i2c-8


That's exactly what I'm expecting, but when I've tried the command, it returns nothing. Could you tell me which distro are you using or share me the image? Thanks
krinekk
 
Posts: 7
Joined: Mon Oct 03, 2016 11:41 pm
languages_spoken: english, spanish
ODROIDs: odroid-x, odroid-x2

Re: Playing with upstream (Exynos4412)

Unread postby LiquidAcid » Sat Oct 29, 2016 1:05 am

You should run a test with udevadm on one of the sysfs nodes.

Example:
Code: Select all
chidori ~ # udevadm test --action=add /sys/class/i2c-dev/i2c-1/
calling: test
version 225
This program is for debugging only, it does not run any program
specified by a RUN key. It may show incorrect results, because
some values may be different, or not available at a simulation run.

=== trie on-disk ===
tool version:          225
file size:         6850247 bytes
header size             80 bytes
strings            1751287 bytes
nodes              5098880 bytes
Load module index
timestamp of '/etc/systemd/network' changed
timestamp of '/lib/systemd/network' changed
Parsed configuration file /lib/systemd/network/99-default.link
Created link configuration context.
timestamp of '/etc/udev/rules.d' changed
Reading rules file: /lib/udev/rules.d/10-dm.rules
Reading rules file: /etc/udev/rules.d/10-local.rules
Reading rules file: /lib/udev/rules.d/11-dm-lvm.rules
Reading rules file: /lib/udev/rules.d/13-dm-disk.rules
Reading rules file: /lib/udev/rules.d/40-gentoo.rules
Reading rules file: /lib/udev/rules.d/50-udev-default.rules
Reading rules file: /lib/udev/rules.d/60-block.rules
Reading rules file: /lib/udev/rules.d/60-cdrom_id.rules
Reading rules file: /lib/udev/rules.d/60-drm.rules
Reading rules file: /lib/udev/rules.d/60-evdev.rules
Reading rules file: /lib/udev/rules.d/60-persistent-alsa.rules
Reading rules file: /lib/udev/rules.d/60-persistent-input.rules
Reading rules file: /lib/udev/rules.d/60-persistent-storage-tape.rules
Reading rules file: /lib/udev/rules.d/60-persistent-storage.rules
Reading rules file: /lib/udev/rules.d/60-persistent-v4l.rules
Reading rules file: /lib/udev/rules.d/60-serial.rules
Reading rules file: /run/udev/rules.d/61-dev-root-link.rules
Reading rules file: /lib/udev/rules.d/64-btrfs.rules
Reading rules file: /etc/udev/rules.d/64-rtc.rules
Reading rules file: /etc/udev/rules.d/65-gamepad.rules
Reading rules file: /lib/udev/rules.d/69-dm-lvm-metad.rules
Reading rules file: /lib/udev/rules.d/70-mouse.rules
Reading rules file: /etc/udev/rules.d/70-net-config.rules
Reading rules file: /lib/udev/rules.d/70-udev-acl.rules
Reading rules file: /lib/udev/rules.d/75-net-description.rules
Reading rules file: /lib/udev/rules.d/75-probe_mtd.rules
Reading rules file: /lib/udev/rules.d/78-sound-card.rules
Reading rules file: /lib/udev/rules.d/80-drivers.rules
Reading rules file: /lib/udev/rules.d/80-libinput-device-groups.rules
Reading rules file: /lib/udev/rules.d/80-net-setup-link.rules
Reading rules file: /lib/udev/rules.d/80-udisks2.rules
Reading rules file: /lib/udev/rules.d/85-regulatory.rules
Reading rules file: /lib/udev/rules.d/90-alsa-restore.rules
Reading rules file: /lib/udev/rules.d/90-libinput-model-quirks.rules
Reading rules file: /lib/udev/rules.d/90-network.rules
Reading rules file: /lib/udev/rules.d/90-pulseaudio.rules
Reading rules file: /lib/udev/rules.d/95-dm-notify.rules
Reading rules file: /lib/udev/rules.d/97-hid2hci.rules
Reading rules file: /lib/udev/rules.d/99-fuse.rules
rules contain 24576 bytes tokens (2048 * 12 bytes), 13119 bytes strings
2018 strings (25785 bytes), 1334 de-duplicated (13351 bytes), 685 trie nodes used
handling device node '/dev/i2c-1', devnum=c89:1, mode=0600, uid=0, gid=0
preserve permissions /dev/i2c-1, 020600, uid=0, gid=0
preserve already existing symlink '/dev/char/89:1' to '../i2c-1'
created empty file '/run/udev/data/c89:1' for '/devices/platform/13870000.i2c/i2c-1/i2c-dev/i2c-1'
ACTION=add
DEVNAME=/dev/i2c-1
DEVPATH=/devices/platform/13870000.i2c/i2c-1/i2c-dev/i2c-1
MAJOR=89
MINOR=1
SUBSYSTEM=i2c-dev
USEC_INITIALIZED=8799408673
Unload module index
Unloaded link configuration context.
LiquidAcid
 
Posts: 1053
Joined: Fri Oct 11, 2013 11:07 pm
languages_spoken: english
ODROIDs: X2

Re: Playing with upstream (Exynos4412)

Unread postby krinekk » Wed Nov 02, 2016 9:51 pm

LiquidAcid wrote:You should run a test with udevadm on one of the sysfs nodes.


There's my output using the same command:
Code: Select all
root@odroid:~# udevadm test --action=add /sys/class/i2c-dev/i2c-1/
calling: test
version 204
This program is for debugging only, it does not run any program
specified by a RUN key. It may show incorrect results, because
some values may be different, or not available at a simulation run.

=== trie on-disk ===
tool version:          204
file size:         5759486 bytes
header size             80 bytes
strings            1267110 bytes
nodes              4492296 bytes
load module index
read rules file: /etc/udev/rules.d/10-odroid-mali.rules
read rules file: /etc/udev/rules.d/10-odroid-shield.rules
read rules file: /lib/udev/rules.d/40-gnupg.rules
read rules file: /lib/udev/rules.d/40-hyperv-hotadd.rules
read rules file: /lib/udev/rules.d/40-i2c-tools.rules
read rules file: /lib/udev/rules.d/40-inputattach.rules
read rules file: /lib/udev/rules.d/40-libgphoto2-6.rules
GOTO 'libgphoto2_usb_end' has no matching label in: '/lib/udev/rules.d/40-libgphoto2-6.rules'
read rules file: /lib/udev/rules.d/40-libpisock9.rules
read rules file: /lib/udev/rules.d/40-libsane.rules
read rules file: /lib/udev/rules.d/40-usb_modeswitch.rules
read rules file: /lib/udev/rules.d/42-usb-hid-pm.rules
read rules file: /lib/udev/rules.d/50-firmware.rules
read rules file: /etc/udev/rules.d/50-odroid-hdmi.rules
read rules file: /lib/udev/rules.d/50-udev-default.rules
read rules file: /lib/udev/rules.d/55-dm.rules
read rules file: /lib/udev/rules.d/56-hpmud.rules
read rules file: /lib/udev/rules.d/60-cdrom_id.rules
read rules file: /lib/udev/rules.d/60-keyboard.rules
read rules file: /etc/udev/rules.d/60-odroid-cec.rules
read rules file: /lib/udev/rules.d/60-pcmcia.rules
read rules file: /lib/udev/rules.d/60-persistent-alsa.rules
read rules file: /lib/udev/rules.d/60-persistent-input.rules
read rules file: /lib/udev/rules.d/60-persistent-serial.rules
read rules file: /lib/udev/rules.d/60-persistent-storage-dm.rules
read rules file: /lib/udev/rules.d/60-persistent-storage-tape.rules
read rules file: /lib/udev/rules.d/60-persistent-storage.rules
read rules file: /lib/udev/rules.d/60-persistent-v4l.rules
read rules file: /lib/udev/rules.d/61-accelerometer.rules
read rules file: /lib/udev/rules.d/62-google-cloudimg.rules
read rules file: /lib/udev/rules.d/64-btrfs.rules
read rules file: /lib/udev/rules.d/64-xorg-xkb.rules
read rules file: /lib/udev/rules.d/69-cd-sensors.rules
IMPORT found builtin 'usb_id --export %p', replacing /lib/udev/rules.d/69-cd-sensors.rules:89
read rules file: /lib/udev/rules.d/69-libmtp.rules
read rules file: /etc/udev/rules.d/70-persistent-net.rules
read rules file: /lib/udev/rules.d/70-power-switch.rules
read rules file: /lib/udev/rules.d/70-printers.rules
read rules file: /lib/udev/rules.d/70-uaccess.rules
read rules file: /lib/udev/rules.d/71-seat.rules
read rules file: /lib/udev/rules.d/73-idrac.rules
read rules file: /lib/udev/rules.d/73-seat-late.rules
read rules file: /lib/udev/rules.d/75-net-description.rules
read rules file: /lib/udev/rules.d/75-persistent-net-generator.rules
read rules file: /lib/udev/rules.d/75-probe_mtd.rules
read rules file: /lib/udev/rules.d/75-tty-description.rules
read rules file: /lib/udev/rules.d/77-mm-ericsson-mbm.rules
read rules file: /lib/udev/rules.d/77-mm-huawei-net-port-types.rules
read rules file: /lib/udev/rules.d/77-mm-longcheer-port-types.rules
read rules file: /lib/udev/rules.d/77-mm-nokia-port-types.rules
read rules file: /lib/udev/rules.d/77-mm-pcmcia-device-blacklist.rules
read rules file: /lib/udev/rules.d/77-mm-platform-serial-whitelist.rules
read rules file: /lib/udev/rules.d/77-mm-qdl-device-blacklist.rules
read rules file: /lib/udev/rules.d/77-mm-simtech-port-types.rules
read rules file: /lib/udev/rules.d/77-mm-usb-device-blacklist.rules
read rules file: /lib/udev/rules.d/77-mm-usb-serial-adapters-greylist.rules
read rules file: /lib/udev/rules.d/77-mm-x22x-port-types.rules
read rules file: /lib/udev/rules.d/77-mm-zte-port-types.rules
read rules file: /lib/udev/rules.d/77-nm-olpc-mesh.rules
read rules file: /lib/udev/rules.d/78-graphics-card.rules
read rules file: /lib/udev/rules.d/78-sound-card.rules
read rules file: /lib/udev/rules.d/80-drivers.rules
read rules file: /lib/udev/rules.d/80-mm-candidate.rules
read rules file: /lib/udev/rules.d/80-udisks2.rules
read rules file: /lib/udev/rules.d/80-uvcdynctrl.rules
read rules file: /lib/udev/rules.d/85-hdparm.rules
read rules file: /lib/udev/rules.d/85-hplj10xx.rules
read rules file: /lib/udev/rules.d/85-keyboard-configuration.rules
read rules file: /lib/udev/rules.d/85-usbmuxd.rules
read rules file: /lib/udev/rules.d/90-alsa-restore.rules
read rules file: /lib/udev/rules.d/90-alsa-ucm.rules
read rules file: /lib/udev/rules.d/90-libgpod.rules
read rules file: /lib/udev/rules.d/90-pulseaudio.rules
read rules file: /etc/udev/rules.d/95-ads7846.rules
read rules file: /lib/udev/rules.d/95-cd-devices.rules
read rules file: /lib/udev/rules.d/95-udev-late.rules
read rules file: /lib/udev/rules.d/95-upower-battery-recall-dell.rules
read rules file: /lib/udev/rules.d/95-upower-battery-recall-fujitsu.rules
read rules file: /lib/udev/rules.d/95-upower-battery-recall-gateway.rules
read rules file: /lib/udev/rules.d/95-upower-battery-recall-ibm.rules
read rules file: /lib/udev/rules.d/95-upower-battery-recall-lenovo.rules
read rules file: /lib/udev/rules.d/95-upower-battery-recall-toshiba.rules
read rules file: /lib/udev/rules.d/95-upower-csr.rules
read rules file: /lib/udev/rules.d/95-upower-hid.rules
read rules file: /lib/udev/rules.d/95-upower-wup.rules
read rules file: /lib/udev/rules.d/97-bluetooth-hid2hci.rules
read rules file: /etc/udev/rules.d/99-input.rules
read rules file: /etc/udev/rules.d/suunto-ant2.rules
rules contain 196608 bytes tokens (16384 * 12 bytes), 31590 bytes strings
18265 strings (158165 bytes), 15302 de-duplicated (129539 bytes), 2964 trie nodes used
GROUP 122 /lib/udev/rules.d/40-i2c-tools.rules:1
MODE 0660 /lib/udev/rules.d/40-i2c-tools.rules:1
IMPORT builtin 'usb_id' /lib/udev/rules.d/40-libgphoto2-6.rules:3
unable to access usb_interface device of '/sys/devices/platform/13870000.i2c/i2c-1/i2c-dev/i2c-1'
IMPORT builtin 'usb_id' returned non-zero
handling device node '/dev/i2c-1', devnum=c89:1, mode=0660, uid=0, gid=122
can not stat() node '/dev/i2c-1' (No such file or directory)
ACTION=add
DEVNAME=/dev/i2c-1
DEVPATH=/devices/platform/13870000.i2c/i2c-1/i2c-dev/i2c-1
MAJOR=89
MINOR=1
SUBSYSTEM=i2c-dev
USEC_INITIALIZED=300333732
unload module index
krinekk
 
Posts: 7
Joined: Mon Oct 03, 2016 11:41 pm
languages_spoken: english, spanish
ODROIDs: odroid-x, odroid-x2

Re: Playing with upstream (Exynos4412)

Unread postby Panzerknacker » Wed Nov 02, 2016 10:30 pm

Is i2c-dev blacklisted somwhere?
/etc/modprobe.d
User avatar
Panzerknacker
 
Posts: 237
Joined: Sat Feb 22, 2014 10:08 pm
languages_spoken: German, English
ODROIDs: U3, X, XU, XU3, XU4, W

Re: Playing with upstream (Exynos4412)

Unread postby LiquidAcid » Wed Nov 02, 2016 11:07 pm

Only a guess, but this bit looks suspicious:
Code: Select all
IMPORT builtin 'usb_id' /lib/udev/rules.d/40-libgphoto2-6.rules:3
unable to access usb_interface device of '/sys/devices/platform/13870000.i2c/i2c-1/i2c-dev/i2c-1'
IMPORT builtin 'usb_id' returned non-zero


Not sure what the libgphoto rule does there, but it certainly shouldn't identify the i2c node as usb device, or part of a usb device.
LiquidAcid
 
Posts: 1053
Joined: Fri Oct 11, 2013 11:07 pm
languages_spoken: english
ODROIDs: X2

Re: Playing with upstream (Exynos4412)

Unread postby Panzerknacker » Wed Nov 02, 2016 11:29 pm

Hi,

tried to revive an old odroid-X (1GB RAM) as I could not get an -X2 and need the I/O_Pins.

Used recent uboot + patch for odroid-X: https://patchwork.ozlabs.org/patch/532735/

This is boot.txt -> boot.scr:

setenv initrd_high "0xffffffff"
setenv fdt_high "0xffffffff"
setenv bootcmd "fatload mmc 0:1 0x40008000 zImage; fatload mmc 0:1 0x42000000 uInitrd; fatload mmc 0:1 0x40800000 exynos4412-odroidx.dtb; bootz 0x40008000 0x42000000 0x40800000"
setenv bootargs "console=tty1 console=ttySAC1,115200n8 earlyprintk=ttySAC1,115200n8 root=/dev/mmcblk0p2 rootwait ro mem=1023M"
boot

This the serial console output;

\0x00\0xff\0x00

U-Boot 2016.11-rc2-00092-gaf223f3 (Oct 28 2016 - 11:25:04 +0200)

CPU: Exynos4412 @ 1 GHz
Model: Odroid based on Exynos4412
Board: Odroid based on Exynos4412
Type: x
DRAM: 1 GiB
LDO20@VDDQ_EMMC_1.8V: set 1800000 uV; enabling
LDO22@VDDQ_EMMC_2.8V: set 2800000 uV; enabling
LDO21@TFLASH_2.8V: set 2800000 uV; enabling
MMC: EXYNOS DWMMC: 0
*** Warning - bad CRC, using default environment

Net: No ethernet found.
Hit any key to stop autoboot: 0
reading boot.scr
443 bytes read in 4 ms (107.4 KiB/s)
## Executing script at 42000000
reading zImage
4547280 bytes read in 162 ms (26.8 MiB/s)
reading uInitrd
2636767 bytes read in 98 ms (25.7 MiB/s)
reading exynos4412-odroidx.dtb
53994 bytes read in 8 ms (6.4 MiB/s)
Kernel image @ 0x40008000 [ 0x000000 - 0x4562d0 ]
## Loading init Ramdisk from Legacy Image at 42000000 ...
Image Name: initramfs
Image Type: ARM Linux RAMDisk Image (uncompressed)
Data Size: 2636703 Bytes = 2.5 MiB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
## Flattened Device Tree blob at 40800000
Booting using the fdt blob at 0x40800000
Using Device Tree in place at 40800000, end 408102e9

Starting kernel ...

Uncompressing Linux... done, booting the kernel.

Error: unrecognized/unsupported machine ID (r1 = 0x000010c1).

Available machine support:

ID (hex)\0x09NAME

ffffffff\0x09Generic DT based system
ffffffff\0x09SAMSUNG EXYNOS (Flattened Device Tree)

Please check your kernel config and/or bootloader.
---------------------------------------------------------------------
Any idea? I might be just blind about some addresses...

Thanks.

BTW. Old 3.8. kernel boots with this u-boot.
New kernel uses exynos_defconfig and runs on U3.
User avatar
Panzerknacker
 
Posts: 237
Joined: Sat Feb 22, 2014 10:08 pm
languages_spoken: German, English
ODROIDs: U3, X, XU, XU3, XU4, W

Re: Playing with upstream (Exynos4412)

Unread postby LiquidAcid » Tue Nov 08, 2016 6:56 am

Small update:
- odroid-4.8.y rebased on stable/linux-4.8.6
- build system cleanups for Mali GPU (renamed the module to 'maligpu' in the process)
- implemented runtime pm support for Mali
- added OPP support for Mali (enables frequency/voltage changes during runtime)

The power management type can now be selected via Kconfig. The OPP support is implemented using the GPU utilization API.
LiquidAcid
 
Posts: 1053
Joined: Fri Oct 11, 2013 11:07 pm
languages_spoken: english
ODROIDs: X2

Re: Playing with upstream (Exynos4412)

Unread postby ztombol » Thu Nov 10, 2016 8:02 am

Thank you

@LiquidAcid, thank you for your hard work on bringing a fully-functional and up-to-date Linux kernel to these boards. I can't stress enough how important this is.

In my opinion, the main problem with most SBCs is not their relatively low performance comparing to average x86 machines, but their kernel support. Having an out-of-date kernel is pretty much a no-go for me, and many others, I suspect.

And while these boards have gained partial mainline support that makes many uses possible, e.g. headless torrent box or music player, the lack of hardware accelerated graphics and video encoding/decoding squanders their true potential.

Sure, these aren't the newest and fastest boards available, in fact they are EOL, but they are still more than capable of handling many popular tasks, e.g. 1080p video playback and retro gaming.

Again, I can't stress enough how important your work is. Thank you!
ztombol
 
Posts: 7
Joined: Wed Nov 09, 2016 11:16 pm
languages_spoken: English, Japanese, Hungarian
ODROIDs: U2

Re: Playing with upstream (Exynos4412)

Unread postby ztombol » Thu Nov 10, 2016 8:18 am

@LiquidAcid

I tried compiling 4.8.6 with CONFIG_MALI_PM_DVFS, as that was the default until the previous release, but the compilation failed. Compiling with CONFIG_MALI_PM_NONE or CONFIG_MALI_PM_UTILIZATION succeeds though.

Error message:
Code: Select all
  CC [M]  drivers/gpu/arm/mali/platform/exynos4412/platform.o
drivers/gpu/arm/mali/platform/exynos4412/platform.c:34:3: error: #error Platform does not implement power management via DVFS.
  #error Platform does not implement power management via DVFS.
   ^~~~~
drivers/gpu/arm/mali/platform/exynos4412/platform.c:411:13: warning: ‘exynos4412_utilization_callback’ defined but not used [-Wunused-function]
 static void exynos4412_utilization_callback(void *ctx, const struct mali_gpu_utilization_data *udata)
             ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
drivers/gpu/arm/mali/platform/exynos4412/platform.c:378:13: warning: ‘exynos4412_power_work’ defined but not used [-Wunused-function]
 static void exynos4412_power_work(struct work_struct *work)
             ^~~~~~~~~~~~~~~~~~~~~
make[4]: *** [scripts/Makefile.build:290: drivers/gpu/arm/mali/platform/exynos4412/platform.o] Error 1
make[3]: *** [scripts/Makefile.build:440: drivers/gpu/arm/mali] Error 2
make[2]: *** [scripts/Makefile.build:440: drivers/gpu/arm] Error 2
make[1]: *** [scripts/Makefile.build:440: drivers/gpu] Error 2
make: *** [Makefile:968: drivers] Error 2
ztombol
 
Posts: 7
Joined: Wed Nov 09, 2016 11:16 pm
languages_spoken: English, Japanese, Hungarian
ODROIDs: U2

Re: Playing with upstream (Exynos4412)

Unread postby ztombol » Thu Nov 10, 2016 9:12 am

Panzerknacker wrote:Starting kernel ...

Uncompressing Linux... done, booting the kernel.

Error: unrecognized/unsupported machine ID (r1 = 0x000010c1).

Available machine support:

ID (hex)\0x09NAME

ffffffff\0x09Generic DT based system
ffffffff\0x09SAMSUNG EXYNOS (Flattened Device Tree)


It seems that the kernel is thinking it has received traditional ATAGs and not a Device Tree. The error message comes from here. Your addresses look okay to me.

I'm guessing 3.8 boots because it doesn't need a device tree. Have you tried the mainline kernel?

I have a U-Boot fork (currently at 2016.09.01) that supports the X. It also adds extlinux.conf support for easy configuration. The X support is based on the more traditional patch used by Arch Linux ARM. Though I haven't tested on the X yet.
ztombol
 
Posts: 7
Joined: Wed Nov 09, 2016 11:16 pm
languages_spoken: English, Japanese, Hungarian
ODROIDs: U2

Re: Playing with upstream (Exynos4412)

Unread postby Panzerknacker » Thu Nov 10, 2016 6:09 pm

ztombol wrote: Have you tried the mainline kernel?


Yes, plain 4.8.5.
User avatar
Panzerknacker
 
Posts: 237
Joined: Sat Feb 22, 2014 10:08 pm
languages_spoken: German, English
ODROIDs: U3, X, XU, XU3, XU4, W

Re: Playing with upstream (Exynos4412)

Unread postby LiquidAcid » Thu Nov 10, 2016 7:01 pm

ztombol wrote:I tried compiling 4.8.6 with CONFIG_MALI_PM_DVFS, as that was the default until the previous release, but the compilation failed.

That is expected (and intended). I thought it was a better way to bail out than to fail on unresolved symbols later.
LiquidAcid
 
Posts: 1053
Joined: Fri Oct 11, 2013 11:07 pm
languages_spoken: english
ODROIDs: X2

Re: Playing with upstream (Exynos4412)

Unread postby ztombol » Fri Nov 11, 2016 12:02 am

Panzerknacker wrote:
ztombol wrote: Have you tried the mainline kernel?


Yes, plain 4.8.5.


Well? Did that work? If mainline dosn't work either, you should try another bootloader. You can try the one I forked, which is untested on the X, although the support is based on a patch that's proven to work. Or copy a tested one from a distro that supports the X and uses a recent version, e.g. Arch Linux ARM's alarm/uboot-odroid-x.
ztombol
 
Posts: 7
Joined: Wed Nov 09, 2016 11:16 pm
languages_spoken: English, Japanese, Hungarian
ODROIDs: U2

Re: Playing with upstream (Exynos4412)

Unread postby ztombol » Fri Nov 11, 2016 12:18 am

LiquidAcid wrote:
ztombol wrote:I tried compiling 4.8.6 with CONFIG_MALI_PM_DVFS, as that was the default until the previous release, but the compilation failed.

That is expected (and intended). I thought it was a better way to bail out than to fail on unresolved symbols later.


Okay, got it. Thanks!
ztombol
 
Posts: 7
Joined: Wed Nov 09, 2016 11:16 pm
languages_spoken: English, Japanese, Hungarian
ODROIDs: U2

Re: Playing with upstream (Exynos4412)

Unread postby Panzerknacker » Fri Nov 11, 2016 1:34 am

Loading the fdt to address 41f00000 instead of 40800000 makes my above setup working.
Probably kernel nowadays is too big and overwrites the fdt at 40800000.
Thanks guys.
User avatar
Panzerknacker
 
Posts: 237
Joined: Sat Feb 22, 2014 10:08 pm
languages_spoken: German, English
ODROIDs: U3, X, XU, XU3, XU4, W

Re: Playing with upstream (Exynos4412)

Unread postby LiquidAcid » Fri Nov 11, 2016 2:26 am

I'm not sure how the early boot code on ARM works, but AFAIK kernel image decompression happens inplace, so if the unpacked image is larger than 0x40800000 - 0x40008000 = 0x7F8000 bytes, then it overwrites the FDT. All under the assumption that the kernel doesn't relocate the FDT.
LiquidAcid
 
Posts: 1053
Joined: Fri Oct 11, 2013 11:07 pm
languages_spoken: english
ODROIDs: X2

Re: Playing with upstream (Exynos4412)

Unread postby ztombol » Fri Nov 11, 2016 5:09 am

@LiquidAcid I think you are right.

It always bugged me why upstream U-Boot leaves more space for the FDT than to the kernel (~7MiB).
It does not document how the addresses were chosen. The kernel address 0x40007fc0 is especially odd.
I may try changing it in my U-Boot fork to allow for larger kernels.
ztombol
 
Posts: 7
Joined: Wed Nov 09, 2016 11:16 pm
languages_spoken: English, Japanese, Hungarian
ODROIDs: U2

Re: Playing with upstream (Exynos4412)

Unread postby frol » Sun Nov 20, 2016 9:39 pm

I second @ztombol's words of gratitude. @LiquidAcid you have done a great job! Thank you!

Also, @ztombol thank you for preparing Arch Linux packages for this kernel and the patched U-boot!

Currently, I am able to boot to the kernel on my U3 (the first time I succeeded with 4.8.4, and now I am running 4.8.9), though it boots only every second time (just like @memeka and @deivid have reported, I need to disconnect power before it panics and the next boot is fine then), and `/dev/mali` is not always available, and my boards usually goes dead after 10-20 minutes.

Here is the relevant dmesg log for mali:

Code: Select all
[    6.111539] mali-utgard 13000000.gpu: Mali platform: G3D clock rate = 24 MHz
[    6.113097] mali-utgard 13000000.gpu: Mali platform: initial G3D core clock rate = 160 MHz
[    6.138396] Mali: ERR: drivers/gpu/arm/mali/common/mali_gp.c
[    6.138515]            mali_gp_reset_wait() 178
                          Mali GP: Failed to reset core Mali_GP, rawstat: 0x00000000
[    6.150605] Mali: ERR: drivers/gpu/arm/mali/common/mali_kernel_core.c
[    6.157109]            mali_create_group() 315
[    6.167268] Mali: ERR: drivers/gpu/arm/mali/linux/mali_kernel_linux.c
[    6.172740]            mali_probe() 490
                          mali_probe(): Failed to initialize Mali device driver.
[    6.182372] mali-utgard: probe of 13000000.gpu failed with error -14
[    6.188896] Mali: Mali device driver loaded


lsmod lists maligpu module, and I can rmmod and modprobe it again, but `/dev/mali` is still not available.

CEC support is also missing if you compare the features of 3.8 kernel. I think these PRs can be helpful for adding CEC support: https://github.com/hardkernel/linux/pull/23, https://github.com/hardkernel/linux/pull/24
frol
 
Posts: 11
Joined: Fri Sep 05, 2014 2:07 pm
languages_spoken: english, russian, ukrainian
ODROIDs: U3

Re: Playing with upstream (Exynos4412)

Unread postby LiquidAcid » Sun Nov 20, 2016 10:10 pm

frol wrote:Currently, I am able to boot to the kernel on my U3 (the first time I succeeded with 4.8.4, and now I am running 4.8.9), though it boots only every second time (just like @memeka and @deivid have reported, I need to disconnect power before it panics and the next boot is fine then)

First of all, I don't read memeka's posts. He's on ignore for more than a yr and that is unlikely to change.

Concerning any reboot issues:
- check if the problem also happens with vanilla and if yes, report a bug upstream
- if not, use git bisect to isolate the troublesome commit

The only reboot issue that I know of is gargabe in the UART FIFO, but that only affects u-boot, i.e. interrupts auto-boot and drops you to the prompt. See the corresponding patch in my 'stable' u-boot branch.

frol wrote:and `/dev/mali` is not always available, and my boards usually goes dead after 10-20 minutes.

That sounds more like a power supply issue. I've done a 48h run of glmark2-es2 and I didn't see any Oopses during that time. If voltage ramping is an issue, you could try increasing the ramp delay. Although I'm not sure if we're already using the maximum value of the PMIC.

frol wrote:Here is the relevant dmesg log for mali:

Code: Select all
[    6.111539] mali-utgard 13000000.gpu: Mali platform: G3D clock rate = 24 MHz
[    6.113097] mali-utgard 13000000.gpu: Mali platform: initial G3D core clock rate = 160 MHz
[    6.138396] Mali: ERR: drivers/gpu/arm/mali/common/mali_gp.c
[    6.138515]            mali_gp_reset_wait() 178
                          Mali GP: Failed to reset core Mali_GP, rawstat: 0x00000000
[    6.150605] Mali: ERR: drivers/gpu/arm/mali/common/mali_kernel_core.c
[    6.157109]            mali_create_group() 315
[    6.167268] Mali: ERR: drivers/gpu/arm/mali/linux/mali_kernel_linux.c
[    6.172740]            mali_probe() 490
                          mali_probe(): Failed to initialize Mali device driver.
[    6.182372] mali-utgard: probe of 13000000.gpu failed with error -14
[    6.188896] Mali: Mali device driver loaded

Looks like PSU to me.

frol wrote:lsmod lists maligpu module, and I can rmmod and modprobe it again, but `/dev/mali` is still not available.

Please also read the messages: mali-utgard: probe of 13000000.gpu failed with error -14

frol wrote:CEC support is also missing if you compare the features of 3.8 kernel. I think these PRs can be helpful for adding CEC support: https://github.com/hardkernel/linux/pull/23, https://github.com/hardkernel/linux/pull/24

Not helpful since the patches (which are garbage btw) are based on the ancient platform device code, which isn't available anymore since quite some time. Also upstream already has a CEC driver, see VIDEO_SAMSUNG_S5P_CEC. No idea if it works, I don't have a CEC enabled device.
LiquidAcid
 
Posts: 1053
Joined: Fri Oct 11, 2013 11:07 pm
languages_spoken: english
ODROIDs: X2

Re: Playing with upstream (Exynos4412)

Unread postby frol » Mon Nov 21, 2016 5:29 am

LiquidAcid wrote:- check if the problem also happens with vanilla and if yes, report a bug upstream

The mainline kernel works completely fine (linux-armv7-4.8.8).

LiquidAcid wrote:- if not, use git bisect to isolate the troublesome commit

I will try.

LiquidAcid wrote:Please also read the messages: mali-utgard: probe of 13000000.gpu failed with error -14

I am not a kernel hacker, so I just figured I would start with stating the problem. I will read more about the error.

LiquidAcid wrote:Not helpful since the patches (which are garbage btw) are based on the ancient platform device code, which isn't available anymore since quite some time. Also upstream already has a CEC driver, see VIDEO_SAMSUNG_S5P_CEC. No idea if it works, I don't have a CEC enabled device.

Thank you for the pointer, I will recompile the kernel with VIDEO_SAMSUNG_S5P_CEC option enabled.

Just for the record, I have the following setup:
  • Odroid U3
  • eMMC root/boot storage
  • Arch Linux (ALARM)
  • Ethernet connection
  • Micro-HDMI to a TV with CEC support (tested on the 3.8 kernel)
The board is working absolutely fine on the "official" 3.8 kernel and on the mainline 4.8 kernel. I am using @ztombol's PKGBUILD (https://github.com/ztombol/odroid-tools ... nux-odroid) to build Arch Linux packages with your kernel.
frol
 
Posts: 11
Joined: Fri Sep 05, 2014 2:07 pm
languages_spoken: english, russian, ukrainian
ODROIDs: U3

Re: Playing with upstream (Exynos4412)

Unread postby memeka » Mon Nov 21, 2016 7:43 am

LiquidAcid wrote:First of all, I don't read memeka's posts. He's on ignore for more than a yr and that is unlikely to change.

Concerning any reboot issues:
- check if the problem also happens with vanilla and if yes, report a bug upstream
- if not, use git bisect to isolate the troublesome commit

The only reboot issue that I know of is gargabe in the UART FIFO, but that only affects u-boot, i.e. interrupts auto-boot and drops you to the prompt. See the corresponding patch in my 'stable' u-boot branch.


LOL.
I debugged a lot the reboot issue, and the problem is that the PMIC does not get reset on the U3. Since he's been ignoring my posts completely, he kind of missed a lot of chatter.
I reported the issue on samsung ml a while ago, and I was not the only one having the issue. @mdrjr also confirmed and actually had a patch to reset pmic on the 4.8 kernel (which he deleted before making it public :D).
Afaik 4.8 should still have the issue. I tried many things, and sometimes it looked like it was fixed, I could reboot sometimes, just to see the issue back after a while, it was pretty random. If the PMIC will not reset, it will keep whatever voltage it has on the next reboot, so it's actually pretty nasty - maybe the mali issue comes from that as well? But test the power source too.
Try changing the DT to have only one frequency available, e.g. lock it at 1Ghz, since that's the frequency uboot uses too. Also try disabling frequency scaling in kernel config, it will get your board to behave better, although you will still have issues.

EDIT: if you know what you're doing, try to look at the reset code from the HK kernel (in the platform files), and copy the sequence (2 lines of code) to the new kernel (in the new generic reset driver).
User avatar
memeka
 
Posts: 3356
Joined: Mon May 20, 2013 10:22 am
languages_spoken: english
ODROIDs: XU rev2 + eMMC + UART
U3 + eMMC + IO Shield + UART

PreviousNext

Return to The Ideas

Who is online

Users browsing this forum: No registered users and 1 guest