Building kernel from source

[elatllat]

It would be nice if The N1 kernel were as close to official LTS as possible but instead it looks like it's filled with bloat from the linaro kernel...

[crashoverride]

but instead it looks like it's filled with bloat from the linaro kernel...

For kernel 4.4 there was no other choice. Things like HDMI2.0 did not exist in it.

[elatllat]

I guess the other choices (selective code from linaro or starting from 4.14) were more work in the short term. It would be nice to see what the issues with 4.14 were.

[EDIT]
odroid linked this elsewhere.

[rooted]

Doing a make with -j12 did nothing for the speed to compile the kernel. We're still capped somewhere
I think its still under-utilizing the BIG cores

Code: Select all

real    22m54.167s
user    123m23.938s
sys     10m57.495s


I grabbed your configuration and compiled (-j6), same real time as you.

Code: Select all

real    22m43.572s
user    117m35.032s
sys     11m22.298s


Good to see no inconsistencies between boards.

[OverSun]

For everyone interested I've forked rockchip kernel repo, merged odroid changes to it, and adjusted things for odroid that has changed in rockchip kernel (they have 4.4.126 and a lot of changes done in it).
The repo is here https://github.com/Owersun/linux-hardke ... idn1-4.4.y
Warning, I've put my defconfig options as odroidn1_defconfig (because there are things that changed the way config required to be adjusted) and seems disabled too much wifi stuff that was enabled as modules in hardkernel defconfig. If you use some of custom wifi dongles and need drivers for them - check this when you build. Everything else seems to be same.
I find that kernel bring many improvements, for example my board temperature dropped at least 10 degree and now is always lower than 50 without load, I guess more other stuff was improved, rockchip work hard on their kernel.
Mali is renewed, but kept compatible with current userspace libraries, and so on.
I intend to keep up to rockchip kernel and merge odroid changes when there are any.

[rooted]

I find that kernel bring many improvements, for example my board temperature dropped at least 10 degree and now is always lower than 50 without load, I guess more other stuff was improved, rockchip work hard on their kernel.

You sure you didn't go from performance to ondemand governors?

[mad_ady]

Great news OverSun! Let's keep the N1 alive!

[OverSun]

I find that kernel bring many improvements, for example my board temperature dropped at least 10 degree and now is always lower than 50 without load, I guess more other stuff was improved, rockchip work hard on their kernel.

You sure you didn't go from performance to ondemand governors?

I'm always on ondemand, just to make sure devfreq scaling works properly.
Moreover, I applied LibreELEC patches on top of this kernel, that boosts Mali chip to always be in performance mode, and the temp is still cooler than it was before.
I didn't commit those patches in, since there are many changes that are questionable for a board if you don't use it specifically for media.

[rooted]

I'm going to check your git out when I get home, I will try to verify your findings. Sounds good.

[crashoverride]

For everyone interested I've forked rockchip kernel repo, merged odroid changes to it

Thanks! I was recently considering doing exactly that myself. I did not expect that I would become as fond of the N1 as I have.

[crashoverride]

I compiled and installed the updated kernel, but it wont boot. I then connected a console cable to debug. However, after the kernel loads it changes baud rate, and I get garbage. Does anyone know where the UART speed is set at so I can change it back to 115200?

[crashoverride]

I appear to have got it working. I copied over the new device tree and create a new uInitrd:

Code: Select all

sudo update-initramfs -c -k 4.4.126
mkimage -A arm64 -O linux -T ramdisk -C gzip -d /boot/initrd.img-4.4.126 uInitrd


(Note: compile was done on the N1. Console baud rate magically started working too.)

Code: Select all

$ uname -a
Linux odroidn1 4.4.126 #1 SMP Sun Jun 10 03:00:40 UTC 2018 aarch64 aarch64 aarch64 GNU/Linux


Now I need to add back my network bridge and virtualization support.

[rooted]

Notice a lower temperature? I haven't built it yet, just got home for good finally.

[crashoverride]

Notice a lower temperature?

I never measured temperature because I have my fan set to always-on. I skimmed through the commit history, and the majority of Rockchip changes are not applicable to RK3399. The main benefit is getting generic Linux LTS bug fixes.

[OverSun]

Well, considering how much I have to investigate to make all vdd and pwm connections working changing dts and config for options, there were changes targeted to rk3399 related to power.
Yeah, new dts and config with few options enabled are required, or it wont boot properly. Or, which is even worse, boot the way I cracked my head what's wrong, I thought all kind ideas, that my eMMC is dying, that dts is corrupted, etc.

[mad_ady]

I wonder if the new kernel improved reading/writing from spi flash. The current kernel corrupts data if written too fast. I'll give it a try in a week or so.

[rooted]

@oversun

My idle temperature is the exact same (43.888°C). Great work on the updates though.

[OverSun]

43.8 is pretty low, I always had something around 55 idle...

[rooted]

43.8 is pretty low, I always had something around 55 idle...

My N1 runs really cool, very cool compared to the XU4.

I don't have HDMI plugged so maybe that's why? You are using the GPU I'm guessing?

[OverSun]

yeah, I use mine mostly as media center. maybe that's why.
gpu temperature mostly follow cpu with a little lag behind, so I guess cpu is the most contributor to the temp, but kodi uses cpu pretty a lot as well.

[OverSun]

and the 4.4.132 is there.
I'll test how it runs and push it to my repo. I guess there is not much changes related to rockchip to adjust for odroid-n1, since it's only 6 days including 2 weekends since previous commit. I guess there are only mainline merge changes.

[crashoverride]

I seem to be having a lot more issues with rebooting on the newer kernel. I think we may need updated uboot/ATF to go along with it. The main symptom I see is a complete lock up at reboot.

[OverSun]

I think @kwiboo know more about it.
From what I read in the slack, some sd cards are underpowered, wchich causes reboot issue. You use and sd card, right I guess? There are already patches to address that, to rise power right before reboot, but they are not finished.

[crashoverride]

I am booting from eMMC. My guess is that the issue is somewhere in the uboot/ATF because RockPro64 also has a reboot issue. On both, sometimes a power cycle is required to restore operation after reboot.

[OverSun]

that also was happening to me, but I thought this is my local issue.
When this actually was happening the u-boot was failing completely to find eMMC after power cycle, so the problem was happening after the OS.

[crashoverride]

I captured uboot when the issue occurs:

Code: Select all

U-Boot 2017.07-gf788668 (Feb 07 2018 - 02:16:39 -0200)

Model: Hardkernel ODROID-N1
DRAM:  3.9 GiB
MMC:   dwmmc@fe320000: 1, sdhci@fe330000: 0
*** Warning - read failed, using default environment

In:    serial@ff1a0000
Out:   serial@ff1a0000
Err:   serial@ff1a0000
U-Boot 2017.07-gf788668 (Feb 07 2018 - 02:16:39 -0200)

Model: Hardkernel ODROID-N1
scan boot: block read fail
Card did not respond to voltage select!
mmc_init: -95, time 16
MMC: block number 0x4001 exceeds max(0x0)
scan boot: block read fail
board: scan boot stoarge fail
initcall sequence 00000000f7fa4558 failed at call 00000000002026c8 (err=-1)
### ERROR ### Please RESET the board ###


All the reboot failures are related to eMMC errors, though sometimes the fault differs.

[rooted]

Good catch, who is up for updating uboot

[OverSun]

Exactly, I have the same thing.
But it become less and less after dts was properly adjusted (with patches that are in the repo). For now I didn't see this issue since several reboots.

[AreaScout]

Well i saw some nice commits for the rk3399, i.e HDCP2.2 support which you need for 4k streaming https://github.com/rockchip-linux/kerne ... 5240973760

RG

[rooted]

Well i saw some nice commits for the rk3399, i.e HDCP2.2 support which you need for 4k streaming https://github.com/rockchip-linux/kerne ... 5240973760

RG

Says that commit was a year ago?

[OverSun]

it matters when it was merged.
rockchip kernel really gives an example how things committed long time ago could be released only recently with enormous spans of months.
for example latest commit in the tree now is “22 days old”, the one before latest is “3 days old”. and there are a lot of things like this. really takes an effort to build a clear picture what goes after what

[AreaScout]

Says that commit was a year ago?

Oversun is right it was commited on 24.April 2018 https://github.com/rockchip-linux/kernel/commits/release-4.4/arch/arm64/boot/dts/rockchip/rk3399.dtsi cherry picked

and I totally agree with that:

really takes an effort to build a clear picture what goes after what

[rooted]

Says that commit was a year ago?

Oversun is right it was commited on 24.April 2018 https://github.com/rockchip-linux/kernel/commits/release-4.4/arch/arm64/boot/dts/rockchip/rk3399.dtsi cherry picked

and I totally agree with that:

really takes an effort to build a clear picture what goes after what

I tried to find this link to see when it was picked up, I usually do know the difference but the link you originally provided shows it was committed a year ago and I just went by that.

Thanks for the second link and information.

[OverSun]

Good catch, who is up for updating uboot

Well, n1 is the first board I was completely not able to update u-boot on.
Every u-boot I try to build ends up with:

Code: Select all

U-Boot 2017.09-ged2c138a24-dirty (Jun 16 2018 - 16:14:39 +0300)

Model: Hardkernel ODROID-N1
DRAM:  initcall sequence 000000000025c050 failed at call 0000000000202804 (err=-19)
### ERROR ### Please RESET the board ###


I have no ideas where I should look.
So yeah, I stick to the default one board came with.

[mad_ady]

Though it's probably a different u-boot, there are some instructions for rebuilding the stock one with SPI flash support: viewtopic.php?f=29&t=29976#p218209, viewtopic.php?f=155&t=30698&start=0#p221489
I was unable though to get it to boot from SPI flash.

[OverSun]

There is a bugfix in the latest linux 4.14.53, not related to N1 or rockchip at all, but description of which looks seriously similar to the issue with the card that is being observed:

Code: Select all

commit 728ea2302acc19cd83164b38408fd5f84e5153b2
Author: Jerome Brunet <jbrunet@baylibre.com>
Date:   Thu Apr 26 12:50:46 2018 +0200

    ARM64: dts: meson: disable sd-uhs modes on the libretech-cc
   
    commit d5b4885b1dff72ac670b518cfeaac719d768bd4d upstream.
   
    There is a problem with the sd-uhs mode when doing a soft reboot.
    Switching back from 1.8v to 3.3v messes with the card, which no longer
    respond (timeout errors). According to the specification, we should
    perform a card reset (power cycling the card) but this is something we
    cannot control on this design.
   
    Then the only solution to restore the communication with the card is an
    "unplug-plug" which is not acceptable
   
    Until we find a solution, if any, disable the sd-uhs modes on this design.
    For the people using uhs at the moment, there will a performance drop as
    a result.
   
    Fixes: 3cde63ebc85c ("ARM64: dts: meson-gxl: libretech-cc: enable high speed modes")
    Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Kevin Hilman <khilman@baylibre.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>


I guess someone who understands voltage regulators and how it is configured in dts could review this for rockchip in their 4.4.132 kernel...

[mad_ady]

I need some advice - should I use the stock kernel on the N1 for production use, or should I use this version? As far as I understand it has issues with booting/rebooting, right?