tobetter wrote:I've spent few day to run 200Mhz on 3.14 kernel as well since it has little bit more code tune emmc bus. Unfortunately, no luck. FYI, maintainers are already merge the patch to set the clock to 100MHz.https://patchwork.kernel.org/patch/10254653/

Maybe it would help to change the driver to accept the configuration from kernel command line or device tree itself if such configuration can improve the performance. My small doubt is that the configuration can be permanant to a board.

Just FYI, a couple weeks and 4.16 release candidates later, this change to 100 MHz doesn't appear to have taken effect in the Arch linux-aarch64-rc package yet.

[edit] Still not fixed in 4.16-rc7. Do we have to wait for 4.17 or something?

tobetter wrote:I've spent few day to run 200Mhz on 3.14 kernel as well since it has little bit more code tune emmc bus. Unfortunately, no luck. FYI, maintainers are already merge the patch to set the clock to 100MHz.https://patchwork.kernel.org/patch/10254653/

Maybe it would help to change the driver to accept the configuration from kernel command line or device tree itself if such configuration can improve the performance. My small doubt is that the configuration can be permanant to a board.

Just FYI, a couple weeks and 4.16 release candidates later, this change to 100 MHz doesn't appear to have taken effect in the Arch linux-aarch64-rc package yet.

[edit] Still not fixed in 4.16-rc7. Do we have to wait for 4.17 or something?

If you check the bottom of the patch it says "Applied v4.17 and CCed to stable"

This to me means that we won't see it until 4.17, due to the kernel release schedule - but it *may* come out on 4.15 sooner or later.

campbell wrote:Still not fixed in 4.16-rc7. Do we have to wait for 4.17 or something?

If you check the bottom of the patch it says "Applied v4.17 and CCed to stable"

This to me means that we won't see it until 4.17, due to the kernel release schedule - but it *may* come out on 4.15 sooner or later.

It certainly isn't in linus tree yet ...

The merge window for 4.17 has been open for a few days now and this change still hasn't been applied to Linus's tree...are the right people submitting the patches at the right times? Don't want this to fall off the radar, because it's still broken.

campbell wrote:Still not fixed in 4.16-rc7. Do we have to wait for 4.17 or something?

If you check the bottom of the patch it says "Applied v4.17 and CCed to stable"

This to me means that we won't see it until 4.17, due to the kernel release schedule - but it *may* come out on 4.15 sooner or later.

It certainly isn't in linus tree yet ...

The merge window for 4.17 has been open for a few days now and this change still hasn't been applied to Linus's tree...are the right people submitting the patches at the right times? Don't want this to fall off the radar, because it's still broken.

As was the official kernel maintainers for meson that posted it, then yes I'd still expect it in 4.17. However meson is some way down the food chain in the linux kernel IIRC, so that needs to be merged into various other trees - before it reaches linus. I think the merging should be automatic, as official maintainers - but doesn't mean its fast. So think the crunch point only comes when when rc1 comes out.

campbell wrote:Still not fixed in 4.16-rc7. Do we have to wait for 4.17 or something?

If you check the bottom of the patch it says "Applied v4.17 and CCed to stable"

This to me means that we won't see it until 4.17, due to the kernel release schedule - but it *may* come out on 4.15 sooner or later.

It certainly isn't in linus tree yet ...

The merge window for 4.17 has been open for a few days now and this change still hasn't been applied to Linus's tree...are the right people submitting the patches at the right times? Don't want this to fall off the radar, because it's still broken.

As was the official kernel maintainers for meson that posted it, then yes I'd still expect it in 4.17. However meson is some way down the food chain in the linux kernel IIRC, so that needs to be merged into various other trees - before it reaches linus. I think the merging should be automatic, as official maintainers - but doesn't mean its fast. So think the crunch point only comes when when rc1 comes out.

have you already had time to look into compiling the kernel? I am still struggling converting the kernel into a uboot image I guess, it's simply not booting up no matter what I try. Even some descriptions on what you did last time would already help me.

have you already had time to look into compiling the kernel? I am still struggling converting the kernel into a uboot image I guess, it's simply not booting up no matter what I try. Even some descriptions on what you did last time would already help me.

Thanks for your help

Flole

Can I ask you what version of bootloader are you using now? Do you use 'boot.ini' or 'boot.scr'?

From your 'mkimage' command, I suspect the file format of 'vmlinuz-4.16.0-rc4-arm64-odroidc2' and you can check its format with the command 'file'. If file vmlinuz-4.16.0-rc4-arm64-odroidc2 command give you MS-DOS executable, then the kernel image is not compressed so you must use -C none in mkimage command. If it shows, gzip compressed data, max compression, from Unix, -C gzip option should work.

I was able to get the 4.16-rc5 from your git repository to boot. I extracted the deb archive and then created the Image. However, the Image is missing USB-Serial drivers (I need the CH341 driver). Would it be possible that you compile a kernel with those drivers builtin or at least available as modules?

I was able to get the 4.16-rc5 from your git repository to boot. I extracted the deb archive and then created the Image. However, the Image is missing USB-Serial drivers (I need the CH341 driver). Would it be possible that you compile a kernel with those drivers builtin or at least available as modules?

I really appreciate your work!

OH, I see..from my Github... Let me check if I can add the driver. By the way, are you able to boot with the kernel now? FYI, I also have v4. 17-rc1 kernel as a Debian package, you may try it if you can.https://code.launchpad.net/~tobetter/+a ... d/14769591I am building the Debian installer in which mainline kernel can be updated through Launchpad, planning to share the trivial version by end of this month.

Yes I was able to boot the kernel, thank you so much!! I will check the 4.17 out, but I assume it doesn't contain the USB-Serial drivers. Also if you are recompiling it anyways, could you include the zram module? That would be the perfect kernel for me

emk2203 wrote:@tobetter: Is it possible to just install your kernel version with dpkg -i? I have Ubuntu 18.04 running on the C2 with kernel 3.14. Would I need to change the boot.ini, or is it done automatically?

Well, actually it's little bit tricky since we have many different type of installations, different bootloader and different distribution. I was building such hacky script for Hard kernel stock image first, may be next week if possible? FYI, I am building the Debian Installer instead of flashing pre-built image and can be updated through my Launchpad.

Flole wrote:Yes I was able to boot the kernel, thank you so much!! I will check the 4.17 out, but I assume it doesn't contain the USB-Serial drivers. Also if you are recompiling it anyways, could you include the zram module? That would be the perfect kernel for me

Flole wrote:The new kernel doesn't contain NFS Root support? At least it is not able to mount my root fs over nfs like it used to before. Without that I am unable to test as I only have a 256MB SD Card in the C2

EDIT: Booted with the old kernel and checked the 4.17 config: Indeed no CONFIG_ROOT_NFS in there

New package including CONFIG_ROOT_NFS with other kernel configuration updates is just published, please check if it works for you. I have no idea how exactly you manage the package to run on your ODROID-C2, it would be great if you can share.https://code.launchpad.net/~tobetter/+a ... d/14780258

FYI, if you are installing the linux-image-4.17*.deb it would be a good idea to install the package linux-image-upstream-odroid that will pull up-to-date built kernel images with the ordinary apt update command. In order to register my repository for apt command, you must add my repository with this command.

So what I have done is just installing and then running the mkimage command to copy the uImage onto my sd card (users without NFS would probably simply copy it to the boot partition). That was it in terms of switching from my 4.08 if i remember correctly to the kernels you are providing.

The installation can run directly on c2 inside an existing Debian 9/Ubuntu 16.04 image with 3.14/3.16 kernel.boot.ini will be automatically converted to a boot.cmd/boot.scr for new u-boot. But this only works if you did not change the original layout of boot.ini too much.

You will find a text file in each folder describing how it works and some other details.It already contains some extra patches to make more components work or just enabling them:- CPU frequency scaling- Thermal handling- HDMI Audio- Mali acceleration (GLES2/EGL) with Amlogic mali lib and armsoc video driver

There seems to be an issue with the scpi protocol/mailbox timing, because sometimes you will get a message like this:

I did not get a good solution for this, only some temporary workaround.Mali works with 43 fps in glmark2-es2 and also in mpv with vo sdl I could play a 40 minute FHD video software decoded with no issues.This is just a first try, so its more intended to get an overview of the work already done (not by me).

PS: I did see tobetters version too late, so there may be parts I did not include yet.

Yes sometimes it also happens on boot, I am still working on this like described above. Just try to boot again.If you dont want to wait for a fix: just remove the following patch from patches/series-odroidc2 and/or linux/patches/series:odroidc2-enable-scpi-cpu-thermal.patch

After spending a week of my life patching/trying different kernel versions/sources/fixing drivers/usb/dwc2 in any possible way I give up. Mainline kernel is not usable with Odroid C2 and USB peripherals. It just floods logs with usb errors and than hangs a usb port with a device attached to it. 3.14 acts much much more stable that way.

The mailbox handler (drivers/mailbox/mailbox.c) in kernel 4.1x uses a hrtimer. Since I switched back to a regular timer (like used in 3.14/3.16/4.9) frequency and thermal handling works without any issue.Maybe the meson timer is not precise enough for a hrtimer or there is just a flag missing.

Error is not quite the same. That error (-71) is a consequence but not a cause. 3.14 acts differently."usbmulticam" is not some serious patch but small increase in timing in drivers/usb/dwc2/hcd_queue.c

We may need a port_type in dts to allow running type OTG in mode host.Currently I did not want to add too much extra code, the easiest way is to allow setting a different dr_mode on usbX_phy and if nothing is defined it will fall back to the value defined on usbX.

Mainline kernel appears to have regressed even further w/r USB. It used to work if you plugged in two or more USB devices. Now, with 4.17 rc3 on Arch, no modifications to boot.txt or anything, i can't even successfully boot if i have two things plugged in:

campbell wrote:Still not fixed in 4.16-rc7. Do we have to wait for 4.17 or something?

If you check the bottom of the patch it says "Applied v4.17 and CCed to stable"

This to me means that we won't see it until 4.17, due to the kernel release schedule - but it *may* come out on 4.15 sooner or later.

It certainly isn't in linus tree yet ...

The merge window for 4.17 has been open for a few days now and this change still hasn't been applied to Linus's tree...are the right people submitting the patches at the right times? Don't want this to fall off the radar, because it's still broken.

As was the official kernel maintainers for meson that posted it, then yes I'd still expect it in 4.17. However meson is some way down the food chain in the linux kernel IIRC, so that needs to be merged into various other trees - before it reaches linus. I think the merging should be automatic, as official maintainers - but doesn't mean its fast. So think the crunch point only comes when when rc1 comes out.

The emmc fix is available in 4.16.6+ as well as in 4.14.36+. I just upgraded my system to kernel 4.16.6 via the archlinux package and the system (which was heavily affected before) seems to run nicely without corruption of the emmc. It is also part of the 4.17-rc series.

If you are interested to run headless Debian with mainline kernel, you could consider running Debian Stretch Installer which will set up Debian from scratch on ODROID-C2 itself with up to date Debian packages. The Debian installer is hacked version, you can arrange the partition layout with your preferred file system types on installation. Please visit another thread https://forum.odroid.com/viewtopic.php?f=55&t=30869#p222648 for the instruction and updates.

Currently, I've tested to run the headless machine with mainline kernel v4.17-rc1, GPU is not fully tested yet and not fully customized for ODROID-C2 yet. After having Debian Strech with my installer, the upstream kernel can be updated through my repository in Launchpad (https://launchpad.net/odroid-image), probably every week whenever a new upstream tag is released or updated. I hope myself can keep updating the repository with a new release.

I've missed some posts in this thread and will see if my branch can merge the patches from scpcom's one if he/she permits. Also, if you have a patch or like to request a kernel configuration to be updated, please post the request to my Launchpad or here.

tobetter wrote:I've missed some posts in this thread and will see if my branch can merge the patches from scpcom's one if he/she permits. Also, if you have a patch or like to request a kernel configuration to be updated, please post the request to my Launchpad or here.

VU7 Plus EDID reports a mode with 32000 Hz clock/43 Hz refresh, which is not supported by mainline drm meson driver.Also the old 51450 Hz clock/60 Hz refresh mode from kernel 3.14/3.16 does not work.I tried to define the related clocks in meson_vclk.c but the result did not change.The default 1024x768 (65000 Hz clock/60 Hz refresh) does work (with 128 out-of-screen lines at bottom), based on this I added a mode with modified dimensions and implemented a "mode quirk" in drm_edid.c which only applies if EDID vendor and product id matches.All other VU5/VU7 may not work yet. For screens with HDMI connector only the resolution needs to be added to drm_edid.c and meson_venc.c. For I2C based screens more work may be needed because sx865x.c contains code that only works with old amlogic drivers.