Building kernel from source

elatllat · Unread post by **elatllat** » Sun Feb 18, 2018 10:46 am

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 · Unread post by **crashoverride** » Sun Feb 18, 2018 10:56 am

elatllat wrote: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 · Unread post by **elatllat** » Sun Feb 18, 2018 8:36 pm

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 · Unread post by **rooted** » Mon Feb 19, 2018 7:00 pm

mlinuxguy wrote: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 · Unread post by **OverSun** » Sun Jun 10, 2018 1:48 am

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 · Unread post by **rooted** » Sun Jun 10, 2018 2:24 am

OverSun wrote: 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 · Unread post by **mad_ady** » Sun Jun 10, 2018 2:40 am

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

OverSun · Unread post by **OverSun** » Sun Jun 10, 2018 3:25 am

rooted wrote:
OverSun wrote: 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 · Unread post by **rooted** » Sun Jun 10, 2018 5:31 am

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

crashoverride · Unread post by **crashoverride** » Sun Jun 10, 2018 7:24 am

OverSun wrote: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 · Unread post by **crashoverride** » Sun Jun 10, 2018 12:46 pm

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 · Unread post by **crashoverride** » Sun Jun 10, 2018 1:22 pm

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 · Unread post by **rooted** » Sun Jun 10, 2018 2:06 pm

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

crashoverride · Unread post by **crashoverride** » Sun Jun 10, 2018 2:56 pm

rooted wrote: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 · Unread post by **OverSun** » Sun Jun 10, 2018 5:23 pm

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 · Unread post by **mad_ady** » Sun Jun 10, 2018 6:29 pm

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 · Unread post by **rooted** » Mon Jun 11, 2018 2:59 pm

@oversun

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

OverSun · Unread post by **OverSun** » Mon Jun 11, 2018 3:14 pm

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

rooted · Unread post by **rooted** » Mon Jun 11, 2018 3:20 pm

OverSun wrote: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 · Unread post by **OverSun** » Mon Jun 11, 2018 3:24 pm

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 · Unread post by **OverSun** » Mon Jun 11, 2018 5:25 pm

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 · Unread post by **crashoverride** » Tue Jun 12, 2018 6:40 am

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 · Unread post by **OverSun** » Tue Jun 12, 2018 3:24 pm

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 · Unread post by **crashoverride** » Wed Jun 13, 2018 4:59 am

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 · Unread post by **OverSun** » Wed Jun 13, 2018 5:09 am

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 · Unread post by **crashoverride** » Wed Jun 13, 2018 11:42 am

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 · Unread post by **rooted** » Wed Jun 13, 2018 12:29 pm

Good catch, who is up for updating uboot

OverSun · Unread post by **OverSun** » Wed Jun 13, 2018 3:30 pm

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 · Unread post by **AreaScout** » Thu Jun 14, 2018 2:07 am

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 · Unread post by **rooted** » Thu Jun 14, 2018 5:24 am

AreaScout wrote: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 · Unread post by **OverSun** » Thu Jun 14, 2018 6:45 am

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 · Unread post by **AreaScout** » Thu Jun 14, 2018 5:57 pm

rooted wrote:Says that commit was a year ago?

Oversun is right it was commited on 24.April 2018 https://github.com/rockchip-linux/kerne ... k3399.dtsi cherry picked

and I totally agree with that:

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

rooted · Unread post by **rooted** » Thu Jun 14, 2018 6:26 pm

AreaScout wrote:
rooted wrote:Says that commit was a year ago?
Oversun is right it was commited on 24.April 2018 https://github.com/rockchip-linux/kerne ... k3399.dtsi cherry picked

and I totally agree with that:
OverSun wrote: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 · Unread post by **OverSun** » Wed Jun 20, 2018 5:25 pm

rooted wrote: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 · Unread post by **mad_ady** » Wed Jun 20, 2018 5:40 pm

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 · Unread post by **OverSun** » Tue Jul 03, 2018 9:29 pm

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 · Unread post by **mad_ady** » Thu Jul 12, 2018 12:01 am

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?

mad_ady · Unread post by **mad_ady** » Mon Jul 23, 2018 10:57 pm

It seems the stock kernel/uboot combination sometimes have reboot issues:
My reboot command got stuck there:

Code: Select all

[  OK  ] Stopped target Swap.
[  OK  ] Reached target Shutdown.
[  OK  ] Reached target Final Step.
         Starting Reboot...
[  959.286195] dw_wdt: unexpected close, system will reboot soon
[  959.470937] reboot: Restarting system

Edit:
It seems reboot -f has the same symptom:

Code: Select all

root@n1-pre:~# reboot -f
Rebooting.
[   52.141958] reboot: Restarting system

I'm running a custom kernel, based on stock with more modules enabled: 4.4.114-net

Not even kernel crash + automatic reboots can wake the board up:

Code: Select all

# echo c > /proc/sysrq-trigger
...
[   56.810486] rockchip-thermal ff260000.tsadc: channal 0: temperature(41 C)
[   56.817266] THERMAL REGS:
[   56.819894] 00000000: 00000200 00030133 00000031 00000002 00000000 00000000 00000000 00000000
[   56.828416] 00000020: 0000021e 0000021e 00000000 00000000 00000234 00000000 00000000 00000000
[   56.836937] 00000040: 00000279 00000279 00000000 00000000 00000000 00000000 00000000 00000000
[   56.845459] 00000060: 00000004 00000004 00000753 00000753 00000000 00000000 00000000 00000000
[   56.853974] 00000080: 00000000 00000000
[   56.857806] Rebooting in 5 seconds..

How didn't I notice this before?

rooted · Unread post by **rooted** » Mon Jul 23, 2018 11:13 pm

I haven't had any issues rebooting, any way to reproduce?

wdt is watchdog timer

mad_ady · Unread post by **mad_ady** » Mon Jul 23, 2018 11:33 pm

I've just moved to a 18.04 rootfs, but with the kernel compiled on the debian image ([ 0.000000] Linux version 4.4.114-net (odroid@n1-pre) (gcc version 6.3.0 20170516 (Debian 6.3.0-18+deb9u1) ) #3 SMP Fri Jul 20 17:28:58 EEST 2018)

mad_ady · Unread post by **mad_ady** » Wed Nov 28, 2018 5:48 pm

I'd like to revive this thread since I started working on the n1 again. My goal is to have a stable kernel (based on Hardkernel's 4.4.114 for now), with added support for ir-blaster (I will attempt to port the odroid_lirc driver). For now, the kernel on my branch compiles and boots fine on Ubuntu 18.04, gcc 7.3.0. I haven't noticed the reboot issue anymore. Here are the instructions:

Code: Select all

git clone --depth 1 --single-branch -b odroidn1-4.4.y https://github.com/mad-ady/linux
cd linux
make odroidn1_defconfig
make -j 6 Image dtbs modules
sudo cp arch/arm64/boot/Image arch/arm64/boot/dts/rockchip/rk3399-odroidn1-linux.dt* /media/boot/
sudo make modules_install
sudo make firmware_install
sudo make headers_install INSTALL_HDR_PATH=/usr
kver=`make kernelrelease`
sudo cp .config /boot/config-${kver}
cd /boot
sudo update-initramfs -c -k ${kver}
sudo mkimage -A arm64 -O linux -T ramdisk -a 0x0 -e 0x0 -n initrd.img-${kver} -d initrd.img-${kver} uInitrd-${kver}
sudo cp uInitrd-${kver} /media/boot/uInitrd

joy · Unread post by **joy** » Fri Nov 30, 2018 8:51 am

Thank you for sharing the update, mad_ady.