Running Mainline Linux Kernel on U3

[Panzerknacker]

i've installed the updated u-boot on this new sd card (seen as /dev/sdb on a U3 running ubuntu) with

Code: Select all

dd if=u-boot-dtb.bin of=/dev/sdb seek=62
sync

After a reboot with this SD, the U3 dosn't boot (the blue light is completely off).
unfortunately i don't have a usb serial cable to see what happens, i'm doing something wrong?

Hi Gulp,

I have not used an SD, but I read somewhere the offset of u-boot on SD is 63 vice 62 on eMMC.
Without serial debug cable your work seems to be impossible.

[gulp]

i've installed the updated u-boot on this new sd card (seen as /dev/sdb on a U3 running ubuntu) with

Code: Select all

dd if=u-boot-dtb.bin of=/dev/sdb seek=62
sync

After a reboot with this SD, the U3 dosn't boot (the blue light is completely off).
unfortunately i don't have a usb serial cable to see what happens, i'm doing something wrong?

Hi Gulp,

I have not used an SD, but I read somewhere the offset of u-boot on SD is 63 vice 62 on eMMC.
Without serial debug cable your work seems to be impossible.

Thank you, this evening i'll try again with seek=63

[LiquidAcid]

I have not used an SD, but I read somewhere the offset of u-boot on SD is 63 vice 62 on eMMC.
Without serial debug cable your work seems to be impossible.

The various offsets are documented in the u-boot readme.

[gulp]

ok, now with

Code: Select all

dd if=u-boot-dtb.bin of=/dev/sdb seek=63
sync

the sd boot kernel 3.19
but, if i try to boot with root filesystem on my hdd, the kernel use always the root partition on SD, ignoring boot.src config.

this is my boot.src to boot from hdd (it works ok on stock kernel and uboot)

Code: Select all

hddboot
setenv initrd_high "0xffffffff"
setenv fdt_high "0xffffffff"
setenv bootcmd "fatload mmc 0:1 0x40008000 zImage; fatload mmc 0:1 0x42000000 uInitrd; bootm 0x40008000 0x42000000"
setenv bootargs "console=tty1 console=ttySAC1,115200n8 root=UUID=04a6125c-95f3-45ec-ab35-2421095aa033 rootwait ro  mem=2047M"
boot

tried also with root=/dev/sda1 but with no luck

[Panzerknacker]

I think you have to set the right u-boot environment.
So first get you the serial debug cable.
Then you might want to read the docs that LiquidAcid pointed us to.

[LiquidAcid]

Also it might be worth pointing out that you can still manipulate the u-boot environment from userspace with the fw_{print,set}env utilities.

[marijus]

Hello!
I am trying to build mainline linux-4.1-rc6 (also tried with stable 4.0.4) on my archlinuxarm setup.
The kernel boots fine from emmc but i am running into two major problems:

1.) the usb keyboard sometime works sometimes not after boot (seems to be a race condition somewhere)
2.) ethernet will not be recognised (this is my main problem)

uboot version is: 2015.01

how i build the kernel:

make exynos_defconfig
make menuconfig ( i need to enable some modules to make the the usb keyboard work)
make -j5 zImage modules dtbs
make modules_install

cat arch/arm/boot/zImage arch/arm/boot/dts/exynos4412-odroidu3.dtb > zImage_dtb

Than i copy zImage_dtb to /boot and rename it to zImage,

Any help is appreceated!

[egan-ru]

today i run gentoo system on odroid u2.
uboot 2015.01
Tobias Jakobi's kernel (4.1.5)
custom config only for exynos4412 support
stage 3
running without initramfs
gcc4.9.3
ethernet and usb-keyboard work well

[hugolp]

How usable are these kernels? I want to try Docker in my U3 but I need a more modern kernel to do so. I use my U3 as a headless server, so I do not care for X or any other graphic library and only use one USB.

[Panzerknacker]

https://github.com/tobiasjakobi/linux-o ... roid-4.3.y
is running on an U3 here now for 60 days.

You can even give mainline 4.4 a try now.
Even X/HDMI is working just without Mali.

[hugolp]

https://github.com/tobiasjakobi/linux-o ... roid-4.3.y
is running on an U3 here now for 60 days.

You can even give mainline 4.4 a try now.
Even X/HDMI is working just without Mali.

The link is not working.

[Panzerknacker]

One day too late, try mainline.

[neagix]

One day too late, try mainline.

Hasn't the repository been renamed? I see this one there now:

https://github.com/tobiasjakobi/linux-odroid-public

Which has 3 4.x branches

[neagix]

https://github.com/tobiasjakobi/linux-o ... roid-4.3.y
is running on an U3 here now for 60 days.

You can even give mainline 4.4 a try now.
Even X/HDMI is working just without Mali.

Interesting discussion thread here! These days I am back around hacking with one of my U2s, which I assume it will run same kernel as U3s do.
My end goal would be to run a modern 4.x kernel (instead of the current 3.8.y); seems like you have already achieved this.

Is there any chance we will get the Mali binaries for accelerated graphics support on a 4.x kernel? (I guess not).

So, to recap, in order to use mainline 4.x (using LiquidAcid's repos) I would have to:

• update the uboot (microSD) instructions
• put in the DTB

I am not using accelerated graphics with this U2 at the moment, so I guess it should work.

[LiquidAcid]

Interesting discussion thread here! These days I am back around hacking with one of my U2s, which I assume it will run same kernel as U3s do.

AFAIK the U2 and U3 differ in routing of USB and audio, both which shouldn't matter for the kernel.

Is there any chance we will get the Mali binaries for accelerated graphics support on a 4.x kernel? (I guess not).

See commit 802ae3bbec8f40840233f2e901f8cf728d47cbc6 to be86fe3ce0a4d10f0b143378d457a615bab9176a in linux-odroid-public/odroid-4.4.y.

I am not using accelerated graphics with this U2 at the moment, so I guess it should work.

Linux-Exynos/ODROID-X2, needs slight modification for the U2.

[odroid]

I want to clarify that the U2 and U3 are very identical and 100% software compatible.

[neagix]

Interesting discussion thread here! These days I am back around hacking with one of my U2s, which I assume it will run same kernel as U3s do.

AFAIK the U2 and U3 differ in routing of USB and audio, both which shouldn't matter for the kernel.

I want to clarify that the U2 and U3 are very identical and 100% software compatible.

Thanks for confirming

Is there any chance we will get the Mali binaries for accelerated graphics support on a 4.x kernel? (I guess not).

See commit 802ae3bbec8f40840233f2e901f8cf728d47cbc6 to be86fe3ce0a4d10f0b143378d457a615bab9176a in linux-odroid-public/odroid-4.4.y.

I am not using accelerated graphics with this U2 at the moment, so I guess it should work.

Linux-Exynos/ODROID-X2, needs slight modification for the U2.

Awesome! I see this project has come a long way Thanks for your replies and your work, will definitely try this out tomorrow (+20h)

[neagix]

@LiquidAcid I see in that commit range that you have merged and cleaned up ARM's driver, that's great. Can't wait to give it a try.

Not sure if it has been mentioned, but once u-boot is built one needs to copy the dtb this way:

Code: Select all

cp ./arch/arm/dts/exynos4412-odroid.dtb /mnt/realBoot/exynos4412-odroidu3.dtb

The name must be exactly exynos4412-odroidu3.dtb, at least in u-boot v2015.01 which I am currently trying.

I built 4.4.y and I am using LiquidAcid's vanilla config (I just removed the -vanilla local suffix); the u-boot process seems fine:

Code: Select all

U-Boot 2015.01 (Mar 28 2016 - 14:23:59)

CPU:    Exynos4412@1000MHz
Board: Odroid based on Exynos4412
Model: u3
I2C:   ready
DRAM:  2 GiB
Board PMIC init
MMC:   SAMSUNG SDHCI: 0, EXYNOS DWMMC: 1
*** Warning - bad CRC, using default environment

DFU alt info setting: done
Net:   No ethernet found.
Hit any key to stop autoboot:  0 
reading exynos4412-odroidu3.dtb
13425 bytes read in 31 ms (422.9 KiB/s)
reading uInitrd
2418815 bytes read in 190 ms (12.1 MiB/s)
reading zImage
2518808 bytes read in 195 ms (12.3 MiB/s)
Kernel image @ 0x40007fc0 [ 0x000000 - 0x266f18 ]
## Loading init Ramdisk from Legacy Image at 42000000 ...
   Image Name:   uInitrd
   Image Type:   ARM Linux RAMDisk Image (uncompressed)
   Data Size:    2418751 Bytes = 2.3 MiB
   Load Address: 00000000
   Entry Point:  00000000
   Verifying Checksum ... OK
## Flattened Device Tree blob at 40800000
   Booting using the fdt blob at 0x40800000
   Loading Ramdisk to 4fdb1000, end 4ffff83f ... OK
   Loading Device Tree to 4fdaa000, end 4fdb0470 ... OK

Starting kernel ...

Only problem is that it gets stuck at that line "Starting kernel ..." and CPU goes probably at 100% use (fan gets spinning). At this point I guess there's something wrong with the initramfs/kernel, I'll keep tinkering around it (not the first time I've seen this behavior). Once fixed this I'll probably try latest u-boot mainline.

Edit: same behavior by removing the uInitrd
Edit 2: other differences I noticed: a boot.scr which works with Hardkernel's older version of u-boot will not work with a more recent (v2015.01) u-boot, thus it will try to boot from the default partition 2 of the SD card instead of boot.scr's specified kernel command line rootfs

[LiquidAcid]

See what u-boot already tells you. It's using the default environment, which is probably your issue here.

[neagix]

See what u-boot already tells you. It's using the default environment, which is probably your issue here.

The root partition issue is not a big problem; I am stuck at the "Starting kernel..." line, the u-boot output is in previous post (although there I was incorrectly using an uInitrd). What could cause the kernel to not be loaded? Normally I would think about compression methods compatibility, but I don't think that's the issue here

[marlemion]

Try 'bootz' instead of 'bootm' in your boot.txt/scr file.

[LiquidAcid]

The root partition issue is not a big problem; I am stuck at the "Starting kernel..." line, the u-boot output is in previous post (although there I was incorrectly using an uInitrd). What could cause the kernel to not be loaded? Normally I would think about compression methods compatibility, but I don't think that's the issue here

You should supply at least the uboot env and everything it depends on, otherwise you won't get much help.

[neagix]

You should supply at least the uboot env and everything it depends on, otherwise you won't get much help.

My boot.scr (the part after binary data):

Code: Select all

setenv fdt_high "0xffffffff"
setenv bootcmd "fatload mmc 0:1 0x40008000 zImage; fatload mmc 0:1 0x42000000 uInitrd; bootm 0x40008000 0x42000000"
setenv bootargs "console=tty1 console=ttySAC1,115200n8 root=UUID=2cba3ad4-817b-4614-a721-f7fd9c040eca rootwait ro  mem=2047M"
boot

exynos4412-odroidu3.dtb (zipped)
kernel is built from https://github.com/tobiasjakobi/linux-o ... ecd1dbaa2e with vanilla config

Note that - as per rootfs parameter - the system would be booting from an external USB hard disk instead of a microSD partition.
I have removed uInitrd from the fat32 partition on purpose to skip it, as I think this kernel (4.4.6) does not need it; it hangs equally when using the built uInitrd.

I still get the hanging and full CPU usage:

Code: Select all

U-Boot 2015.01 (Mar 28 2016 - 14:23:59)

CPU:    Exynos4412@1000MHz
Board: Odroid based on Exynos4412
Model: u3
I2C:   ready
DRAM:  2 GiB
Board PMIC init
MMC:   SAMSUNG SDHCI: 0, EXYNOS DWMMC: 1
*** Warning - bad CRC, using default environment

DFU alt info setting: done
Net:   No ethernet found.
Hit any key to stop autoboot:  0 
reading exynos4412-odroidu3.dtb
13425 bytes read in 33 ms (396.5 KiB/s)
reading uInitrd
** Unable to read file uInitrd **
reading zImage
2518808 bytes read in 197 ms (12.2 MiB/s)
Kernel image @ 0x40007fc0 [ 0x000000 - 0x266f18 ]
## Flattened Device Tree blob at 40800000
   Booting using the fdt blob at 0x40800000
   Loading Device Tree to 4fff9000, end 4ffff470 ... OK

Starting kernel ...

Shall I rebuild boot.scr without the uInitrd references? Maybe I remember incorrectly that it would not be necessary for uInitrd to be there even if specified in boot.scr?

Thanks

[LiquidAcid]

I still don't see your u-boot env there.

[neagix]

I still don't see your u-boot env there.

This line:

Code: Select all

*** Warning - bad CRC, using default environment

Was pretty indicative for me of a default environment, hence I thought it was unnecessary to post it. (Unless the environment is not really default and is being read also from the first sectors of microSD/eMMC? I am quite new to u-boot internals)

Here it is:

Code: Select all

U-Boot 2015.01 (Mar 28 2016 - 14:23:59)

CPU:    Exynos4412@1000MHz
Board: Odroid based on Exynos4412
Model: u3
I2C:   ready
DRAM:  2 GiB
Board PMIC init
MMC:   SAMSUNG SDHCI: 0, EXYNOS DWMMC: 1
*** Warning - bad CRC, using default environment

DFU alt info setting: done
Net:   No ethernet found.
Hit any key to stop autoboot:  0
Odroid # env print
autoboot=if test -e mmc 0 Image.itb; then; run boot_fit;elif test -e mmc 0 zImage; then; run boot_zimg;elif test -e mmc 0 uImage; then; run boot_uimg;fi;
baudrate=115200
boardname=odroidu3
boot_fit=setenv kerneladdr 0x42000000;setenv kernelname Image.itb;run loadkernel;run kernel_args;bootm ${kerneladdr}#${boardname}
boot_uimg=setenv kerneladdr 0x40007FC0;setenv kernelname uImage;run check_dtb;run check_ramdisk;run loadkernel;run kernel_args;bootm ${kerneladdr} ${initrd_addr} ${fdt_addr};
boot_zimg=setenv kerneladdr 0x40007FC0;setenv kernelname zImage;run check_dtb;run check_ramdisk;run loadkernel;run kernel_args;bootz ${kerneladdr} ${initrd_addr} ${fdt_addr};
bootargs=Please use defined boot
bootcmd=run autoboot
bootdelay=0
check_dtb=if run loaddtb; then setenv fdt_addr ${fdtaddr};else setenv fdt_addr;fi;
check_ramdisk=if run loadinitrd; then setenv initrd_addr ${initrdaddr};else setenv initrd_addr -;fi;
console=console=ttySAC1,115200n8
consoleoff=set console console=ram; save; reset
consoleon=set console console=ttySAC1,115200n8; save; reset
dfu_alt_boot=u-boot raw 0x3f 0x800;bl1 raw 0x1 0x1e;bl2 raw 0x1f 0x1d;tzsw raw 0x83f 0x138
dfu_alt_info=u-boot raw 0x3f 0x800;bl1 raw 0x1 0x1e;bl2 raw 0x1f 0x1d;tzsw raw 0x83f 0x138;uImage fat 0 1;zImage fat 0 1;Image.itb fat 0 1;uInitrd fat 0 1;exynos4412-odroidu3.dtb fat 0 1;exynos4412-odroidx2.dtb fat 0 1;boot part 0 1;platform part 0 2
dfu_alt_system=uImage fat 0 1;zImage fat 0 1;Image.itb fat 0 1;uInitrd fat 0 1;exynos4412-odroidu3.dtb fat 0 1;exynos4412-odroidx2.dtb fat 0 1;boot part 0 1;platform part 0 2
fdtaddr=40800000
fdtfile=exynos4412-odroidu3.dtb
initrdaddr=42000000
initrdname=uInitrd
kernel_args=setenv bootargs root=/dev/mmcblk${mmcrootdev}p${mmcrootpart} rootwait ${console} ${opts}
loaddtb=fatload mmc ${mmcbootdev}:${mmcbootpart} ${fdtaddr} ${fdtfile}
loadinitrd=fatload mmc ${mmcbootdev}:${mmcbootpart} ${initrdaddr} ${initrdname}
loadkernel=fatload mmc ${mmcbootdev}:${mmcbootpart} ${kerneladdr} ${kernelname}
mmcbootdev=0
mmcbootpart=1
mmcrootdev=0
mmcrootpart=2
soc_id=4412
soc_rev=2.0

Environment size: 2138/4092 bytes

Edit: I understand the default environment may vary depending on the u-boot build. I built v2015.1 of u-boot mainline with the odroid defconfig as per OP here.

[LiquidAcid]

Correct, the default env depends on your u-boot version. And as you can see it's pretty complex in the sense that does a lot of branching in its script execution, hence my advice to replace it by a simpler version tailored to your system. In particular you might've already noticed that your boot script isn't even loaded by the environment, so your own bootargs never apply (including your rootfs setting).

Additionally to fixing up the env you should also enable earlyprintk support in the kernel and enable it. That should give you more information in the early initialization stage of the kernel.

[neagix]

Correct, the default env depends on your u-boot version. And as you can see it's pretty complex in the sense that does a lot of branching in its script execution, hence my advice to replace it by a simpler version tailored to your system. In particular you might've already noticed that your boot script isn't even loaded by the environment, so your own bootargs never apply (including your rootfs setting).

Additionally to fixing up the env you should also enable earlyprintk support in the kernel and enable it. That should give you more information in the early initialization stage of the kernel.

I reduced it to a simple version that I copy/paste over serial interface (not all at once, can't handle it):

Code: Select all

setenv kerneladdr 0x40007FC0
setenv kernelname zImage
fdtaddr=40800000
fdtfile=exynos4412-odroidu3.dtb
mmcbootdev=0
mmcbootpart=1
setenv fdt_addr ${fdtaddr}
setenv bootargs "console=tty1 console=ttySAC1,115200n8 root=/dev/mmcblk0p2 ro  mem=2047M"
setenv initrd_addr -

fatload mmc ${mmcbootdev}:${mmcbootpart} ${fdtaddr} ${fdtfile}
fatload mmc ${mmcbootdev}:${mmcbootpart} ${kerneladdr} ${kernelname}
bootz ${kerneladdr} ${initrd_addr} ${fdt_addr}

This gets me a completely hung console after:

Code: Select all

Starting kernel ...

So now I'll try enabling early printk as you suggested; for those interested, I have spawn a separate thread for my U-boot issues: http://forum.odroid.com/viewtopic.php?f ... 3&p=163863

Edit: I enabled early printk on UART2, no luck. There is nothing displayed.

Edit 2: there is to say that now I am using U-boot master and that loads correctly boot.scr by default (my March post had no boot.scr loaded because I was using a 2015 u-boot version)

[neagix]

Try 'bootz' instead of 'bootm' in your boot.txt/scr file.

Yeah this was an useful tip, but unfortunately the 2015 version of u-boot didn't load boot.scr for odroid devices. That is in place on u-boot master version now.

[neagix]

I have built several different kernel configs for https://github.com/tobiasjakobi/linux-odroid-public (4.8.y) but they all panic with:

Code: Select all

[    0.000000] Unable to handle kernel paging request at virtual address f8000000
[    0.000000] pgd = c0004000
[    0.000000] [f8000000] *pgd=00000000
[    0.000000] Internal error: Oops: 5 [#1] PREEMPT SMP ARM
[    0.000000] Modules linked in:
[    0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 4.8.1+ #12
[    0.000000] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
[    0.000000] task: c09055c0 task.stack: c0900000
[    0.000000] PC is at s5p_init_cpu+0xc/0x38
[    0.000000] LR is at exynos_init_io+0x28/0x68
[    0.000000] pc : [<c0808028>]    lr : [<c08079ac>]    psr: a00001d3
[    0.000000] sp : c0901eb8  ip : c0901ec8  fp : c0901ec4
[    0.000000] r10: 40100000  r9 : c0824d2c  r8 : 70000000
[    0.000000] r7 : c09393e8  r6 : c090e320  r5 : efffe000  r4 : c090e178
[    0.000000] r3 : ffffffff  r2 : 00000000  r1 : 00002d28  r0 : f8000000
[    0.000000] Flags: NzCv  IRQs off  FIQs off  Mode SVC_32  ISA ARM  Segment none
[    0.000000] Control: 10c5387d  Table: 4000404a  DAC: 00000051
[    0.000000] Process swapper (pid: 0, stack limit = 0xc0900218)
[    0.000000] Stack: (0xc0901eb8 to 0xc0902000)
[    0.000000] 1ea0:                                                       c0901ed4 c0901ec8
[    0.000000] 1ec0: c08079ac c0808028 c0901f34 c0901ed8 c0806280 c0807990 00000000 c0900000
[    0.000000] 1ee0: 00040900 c090e178 c0824d2c 00800000 c0100000 00040100 ffff1000 0006ffff
[    0.000000] 1f00: 00001000 00000007 00000000 40008000 c0824d2c 00000200 000022fc c090244c
[    0.000000] 1f20: 80000200 c090e320 c0901fa4 c0901f38 c08026e4 c0805a60 0000006c 10c5387d
[    0.000000] 1f40: 00000001 00000000 c0901f6c c0901f58 c0161378 c0160c94 000022e4 000093e0
[    0.000000] 1f60: c0901f94 c0901f70 c01be084 c0161358 00000000 00000000 00000000 00000000
[    0.000000] 1f80: c09024b8 ffffffff c0902440 4000406a 00000001 00000000 c0901ff4 c0901fa8
[    0.000000] 1fa0: c0800a2c c08020d0 00000000 00000000 00000000 00000000 00000000 00000000
[    0.000000] 1fc0: 00000000 c08268c0 00000000 c0939294 c09024b8 c08268bc c09067e8 4000406a
[    0.000000] 1fe0: 413fc090 00000000 00000000 c0901ff8 40008078 c0800990 00000000 00000000
[    0.000000] Backtrace: 
[    0.000000] [<c080801c>] (s5p_init_cpu) from [<c08079ac>] (exynos_init_io+0x28/0x68)
[    0.000000] [<c0807984>] (exynos_init_io) from [<c0806280>] (paging_init+0x82c/0xa44)
[    0.000000] [<c0805a54>] (paging_init) from [<c08026e4>] (setup_arch+0x620/0xac0)
[    0.000000]  r10:c090e320 r9:80000200 r8:c090244c r7:000022fc r6:00000200 r5:c0824d2c
[    0.000000]  r4:40008000
[    0.000000] [<c08020c4>] (setup_arch) from [<c0800a2c>] (start_kernel+0xa8/0x3a0)
[    0.000000]  r10:00000000 r9:00000001 r8:4000406a r7:c0902440 r6:ffffffff r5:c09024b8
[    0.000000]  r4:00000000
[    0.000000] [<c0800984>] (start_kernel) from [<40008078>] (0x40008078)
[    0.000000]  r10:00000000 r9:413fc090 r8:4000406a r7:c09067e8 r6:c08268bc r5:c09024b8
[    0.000000]  r4:c0939294
[    0.000000] Code: e89da800 e1a0c00d e92dd800 e24cb004 (e5902000) 
[    0.000000] ---[ end trace f68728a0d3053b52 ]---
[    0.000000] Kernel panic - not syncing: Attempted to kill the idle task!
[    0.000000] ---[ end Kernel panic - not syncing: Attempted to kill the idle task!

I am using the DTB built by U-boot (master). Any ideas?

Edit 1: tried torvalds' v4.8, same kernel panic
Edit 2: now running torvalds' v4.8 successfully! the problem was that I was using U-boot's dtb while by using the kernel (make dtbs) .dtb, everything works fine. Thanks for the help with this

[Cypher]

Hello everyone,

Does anybody here use linux mainline 4.9 or anything close to it?
If so, could you please provide your /boot directory, kernel .config, and boot.scr ?

Currently I have no way of getting the console output of my U3 to debug my boot problems, but it seems the kernel is at least starting because the blue LED is "heartbeating".

Thanks a lot!

[alexei]

@Cypher: there's a package on AUR: linux-odroid-u3-git ( https://aur.archlinux.org/packages/linux-odroid-u3-git )
The package includes a uEnv.txt, just fix the root file system device path.

It's mostly working. FAN is controllable by writing 0 to 255 to /sys/class/hwmon/hwmon0/pwm1
Reboot does NOT work: it shuts the system down fine, but the reboot syscall does not reboot the board. I tried to debug it a little, but the kernel changed a lot between 3.18 from hardkernel and 4.13 mainline, so it's tough.

[LiquidAcid]

The fan should be automatically controlled by the kernel. You're probably missing some kernel config (see e.g. Nico's blog post as reference, there should be a kernel config there).

The reboot problem is known to me. Probably some regression introduced with 4.13.0. Maybe related to EPLL/VPLL.

[alexei]

The fan should be automatically controlled by the kernel. You're probably missing some kernel config

Not any longer, I'm pretty sure. In the hardkernel fork there was a kernel driver for auto fan control, but that does not exist in mainline.

(see e.g. Nico's blog post as reference, there should be a kernel config there).

Yeah, he's doing the same thing I'm doing: a userspace process monitors temp and sets PWM.

Sidenote: There's actually a tool for that 'fancontrol' and 'pwmconfig' from lm_sensors package, BUT I tried it and it looks like pwmconfig requires feedback (RPM sensing from the fan) and refuses to recognize a fan (it finds the PWM control, but fails due to lack of fan_* files). Probably could patch the tool, or patch the kernel to include the fan_* files that the tool expects (even if dummy).

The reboot problem is known to me. Probably some regression introduced with 4.13.0. Maybe related to EPLL/VPLL.

I tried to manually hack in the same wrtie(0x1, S5P_SWRESET), by manually calculating the address of S5P_SWRESET from the hardkernel 3.18 kernel, but the mainline kernel paniced on write to this address. Sad. Please post if you fix it.

[LiquidAcid]

Not any longer, I'm pretty sure. In the hardkernel fork there was a kernel driver for auto fan control, but that does not exist in mainline.

The generic thermal framework now handles this. It already does since some kernel versions. Your information is out-dated.

Also see what Nico writes:

EDIT: I upgraded the Kernel Configuration GIST for my Kernel Config + Docker on 10.02.2017. Thanks to an E-Mail from Tobias Jakobi I found the pieces I missed about adding the Kernel Internal Fanservice into the Config. This works now,...

Yeah, he's doing the same thing I'm doing: a userspace process monitors temp and sets PWM.

See above.

EDIT: Looked it up, and support is in mainline since 4.4, see reference.

[alexei]

Ok, thank you. The config switches are CONFIG_THERMAL, CONFIG_CLOCK_THERMAL, and related, under Device Drivers -> Generic Thermal sysfs driver.

I can confirm that it does control the fan depending on temp/load. The temp trip point is at 70C. But, I lowered the trip points to 50,70,90,100, instead via:
sudo bash -c 'echo 50000 > /sys/class/thermal/thermal_zone0/trip_point_0_temp'
and the rest, respectively.

[LiquidAcid]

Nice, good to know that it works correctly. Please consider adding some information to the Linux-Exynos Wiki. I guess that this might be of interest to a lot of U3 users.

[alexei]

Ok, now we have a major problem. The smsc95x ehternet driver and/or usbnet is dying under load. It appears that a stall of some kind is detected, and then it attempts to reset the usb endpoint, which probably fails. After the death, lots of these get printed, but I think the root cause is the "halt". I'm pretty sure one of the usbnet_defer_kevent (dev, EVENT_TX_HALT) calls (or the EVENT_RX_HALT) happens, which does not look normal but more like an error path.

Code: Select all

smsc95xx 1-2:1.0 eth0: kevent 0 may have been dropped

UPDATE: Same issue on RPi: https://github.com/raspberrypi/linux/issues/2027

[alexei]

UPDATE: The fatal network stall that happened on TobiasJakobi's 4.13, is also happening on 4.9.52 mainline, but has not been happening on 4.4.89 and not on 4.14-rc3, which is great news. It is possible that there is a difference in configs, but I tried to keep configs based on exynos_defconfig with few (and the same) modifications in all tests. Have been running for 2.5 days on 4.14-rc3, whereas network stalled within several hours in the other cases.

[LiquidAcid]

Looks like something that you should report upstream. I can also see these 'kevent 0 may have been dropped' message from time to time on my system, but I have yet to see any Oops.

[LiquidAcid]

Just a short note that odroid-4.20.y is available.

[hexdump]

i just gave the odroid-v4.20.y tree a try and compiled it based on the exynos_defconfig plus enabling the mali driver module for my odroid u3. it boots fine as long as no hdmi monitor is connected, but if i connect a monitor to the hdmi port it hangs in the middle of the boot forever. has this tree been already tested with a hdmi monitor connected? i have this same u3 running perfectly fine with 4.19.10 mainline, also the hdmi monitor does not make any trouble there. comparing the dmesg output of the working 4.19.10 kernel with the one from the odroid-v4.20.y tree without hdmi monitor i noticed the following hdmi related differences in the newer tree:

Code: Select all

[    5.511011] exynos-hdmi 12d00000.hdmi: GPIO lookup for consumer hpd
[    5.511658] exynos-hdmi 12d00000.hdmi: using device tree for GPIO lookup
[    5.518448] of_get_named_gpiod_flags: parsed 'hpd-gpios' property of node '/soc/hdmi@12d00000[0]' - status (0)
...
[    5.913773] vdd_hdmi_1.0V: disabling

not sure if it this is related to the problem. besides that i'm getting the following trace shortly after the mali module gets loaded:

Code: Select all

[   11.123094] INFO: trying to register non-static key.
[   11.123208] the code is fine but needs lockdep annotation.
[   11.127905] turning off the locking correctness validator.
[   11.133386] CPU: 0 PID: 12 Comm: kworker/0:1 Not tainted 4.20.3 #1
[   11.140318] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
[   11.146419] Workqueue: pm pm_runtime_work
[   11.150415] [<c01122fc>] (unwind_backtrace) from [<c010de74>] (show_stack+0x10/0x14)
[   11.158126] [<c010de74>] (show_stack) from [<c0a4c420>] (dump_stack+0x98/0xc4)
[   11.165325] [<c0a4c420>] (dump_stack) from [<c0182eb8>] (register_lock_class+0x638/0x63c)
[   11.173482] [<c0182eb8>] (register_lock_class) from [<c0185e6c>] (__lock_acquire+0x78/0x19c0)
[   11.181983] [<c0185e6c>] (__lock_acquire) from [<c01881d8>] (lock_acquire+0xd8/0x270)
[   11.189802] [<c01881d8>] (lock_acquire) from [<c01453a0>] (__flush_work+0x1f0/0x2ac)
[   11.197711] [<c01453a0>] (__flush_work) from [<bf038204>] (mali_platform_runtime_suspend+0x1c/0x50 [maligpu])
[   11.207520] [<bf038204>] (mali_platform_runtime_suspend [maligpu]) from [<c059d184>] (genpd_runtime_suspend+0
xc4/0x2d8)
[   11.218184] [<c059d184>] (genpd_runtime_suspend) from [<c05912c4>] (__rpm_callback+0xc0/0x1cc)
[   11.226773] [<c05912c4>] (__rpm_callback) from [<c05913f0>] (rpm_callback+0x20/0x80)
[   11.234497] [<c05913f0>] (rpm_callback) from [<c058fc14>] (rpm_suspend+0x134/0x750)
[   11.242135] [<c058fc14>] (rpm_suspend) from [<c0591ba0>] (pm_runtime_work+0x74/0xa8)
[   11.249863] [<c0591ba0>] (pm_runtime_work) from [<c01473ac>] (process_one_work+0x2c8/0x83c)
[   11.258194] [<c01473ac>] (process_one_work) from [<c0147964>] (worker_thread+0x44/0x590)
[   11.266272] [<c0147964>] (worker_thread) from [<c014dc4c>] (kthread+0x160/0x168)
[   11.273648] [<c014dc4c>] (kthread) from [<c01010b4>] (ret_from_fork+0x14/0x20)
[   11.280849] Exception stack(0xee923fb0 to 0xee923ff8)
[   11.285887] 3fa0:                                     00000000 00000000 00000000 00000000
[   11.294043] 3fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[   11.302200] 3fe0: 00000000 00000000 00000000 00000000 00000013 00000000

please let me know if i should provide any more debugging info or should try anything else.

a lot of thanks in advance and best wishes - hexdump

[hexdump]

just a little update: to a/b test i transplanted all of the mali patches of the odroid-v4.20,y tree to a mainline 4.19.17 tree and this one boots fine with the mointor attached and the mali driver initialized properly as well and no more errortrace. looks like the above problem is maybe related to 4.20.

now the questions is: which xf86-video-armsoc tree to use for this driver and the r5p0 mali blob. i found old references to a tree from dsd which seems to have been moved to endlessm - i built this one from the master branch, but then the x-server does not start properly. is another branch or another tree of the armsoc driver required here? any help is appreciated.

[LiquidAcid]

My fork might still work.

[hexdump]

i tried to compile it, but failed as it seems to use other of your patches in your kernel tree as well, which are not in my 4.19.x + your mali patches tree. it did not compile out of the box. maybe to give some more details about the problems i see with the 4.19.x + mali patches tree: mali module loads well and the logs look good, /dev/mali is there and set to proper permissions, armsoc xserver starts, uses the armsoc driver and is useable - at least partially: there is no mouse cursor and i so far was not able to create one despite of playing around with SWCursor and HWCursor options in the xorg.conf. as soon as i try to run an es2 application (like es2_info) with the proper r5p0 mali libs installed i get

Code: Select all

Error: eglCreateContext failed

and the kernel logs:

Code: Select all

Mali<2>: OS allocator: Failed to allocate memory (-14)

looks more like a mali kernel module / kernel interaction problem than a problem with the armsoc driver. any idea what might be the cause of that alloc error? kernel is booted with cma=256M.

is your updated odroid-v4.14.y tree tested to work with mali and armsoc x11? maybe i should give this one a try then. the v4.20.y does hang for me on boot with a hdmi monitor connected as mention above.

a lot of thanks in advance and best wishes - hexdump

[henriku]

I have been trying the latest mainline for my U3. It boots without any freezes so far, obviously without Mali support. The only issue I have is with the ethernet. The interface randomly goes down. Initially it went down as soon as I put some significant network load on it. After disabling turbo mode for the driver it does not go down with load but more randomly, after around 24h, still with the same stack trace. The config is pretty much vanilla with only some netfilter modules added. I havn't been able to find any workaround for the issue.

Code: Select all

odroid-stretch:~$ uname -a
Linux odroid-stretch 5.0.0-rc7 #3 SMP PREEMPT Mon Feb 18 16:49:05 PST 2019 armv7l GNU/Linux

Code: Select all

Feb 21 11:10:32 odroid-stretch kernel: [ 1132.968580] ------------[ cut here ]------------
Feb 21 11:10:32 odroid-stretch kernel: [ 1132.969749] WARNING: CPU: 3 PID: 0 at net/sched/sch_generic.c:461 dev_watchdog+0x24c/0x250
Feb 21 11:10:32 odroid-stretch kernel: [ 1132.976457] NETDEV WATCHDOG: eth0 (smsc95xx): transmit queue 0 timed out
Feb 21 11:10:32 odroid-stretch kernel: [ 1132.983159] Modules linked in: cpufreq_conservative cpufreq_userspace cpufreq_powersave ipt_REJECT nf_reject_ipv4 ipt_MASQUERADE xt_nat xt_tcpudp xt_conntrack iptable_mangle iptable_nat nf_nat_ipv4 nf_nat nf_conntrack nf_defrag_ipv6 libcrc32c nf_defrag_ipv4 ip6table_filter ip6_tables iptable_filter s5p_csis s5p_fimc exynos4_is_common v4l2_fwnode s5p_jpeg s5p_mfc v4l2_mem2mem v4l2_common videobuf2_dma_contig videobuf2_memops videobuf2_v4l2 videobuf2_common videodev media s5p_cec ip_tables x_tables ipv6
Feb 21 11:10:32 odroid-stretch kernel: [ 1133.027475] CPU: 3 PID: 0 Comm: swapper/3 Not tainted 5.0.0-rc7 #3
Feb 21 11:10:33 odroid-stretch kernel: [ 1133.033506] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
Feb 21 11:10:33 odroid-stretch kernel: [ 1133.039625] [<c0112454>] (unwind_backtrace) from [<c010e028>] (show_stack+0x10/0x14)
Feb 21 11:10:33 odroid-stretch kernel: [ 1133.047323] [<c010e028>] (show_stack) from [<c0a09e20>] (dump_stack+0x98/0xc4)
Feb 21 11:10:33 odroid-stretch kernel: [ 1133.054523] [<c0a09e20>] (dump_stack) from [<c01266a4>] (__warn+0x10c/0x124)
Feb 21 11:10:33 odroid-stretch kernel: [ 1133.061543] [<c01266a4>] (__warn) from [<c0126704>] (warn_slowpath_fmt+0x48/0x6c)
Feb 21 11:10:33 odroid-stretch kernel: [ 1133.069015] [<c0126704>] (warn_slowpath_fmt) from [<c0819e78>] (dev_watchdog+0x24c/0x250)
Feb 21 11:10:33 odroid-stretch kernel: [ 1133.077180] [<c0819e78>] (dev_watchdog) from [<c01b0af0>] (call_timer_fn+0xc8/0x414)
Feb 21 11:10:33 odroid-stretch kernel: [ 1133.084896] [<c01b0af0>] (call_timer_fn) from [<c01b0f1c>] (expire_timers+0xe0/0x200)
Feb 21 11:10:33 odroid-stretch kernel: [ 1133.092703] [<c01b0f1c>] (expire_timers) from [<c01b132c>] (run_timer_softirq+0xb0/0x1b4)
Feb 21 11:10:33 odroid-stretch kernel: [ 1133.100866] [<c01b132c>] (run_timer_softirq) from [<c010224c>] (__do_softirq+0x124/0x5dc)
Feb 21 11:10:33 odroid-stretch kernel: [ 1133.109027] [<c010224c>] (__do_softirq) from [<c012e94c>] (irq_exit+0x160/0x16c)
Feb 21 11:10:33 odroid-stretch kernel: [ 1133.116407] [<c012e94c>] (irq_exit) from [<c01960b4>] (__handle_domain_irq+0x80/0xec)
Feb 21 11:10:33 odroid-stretch kernel: [ 1133.124225] [<c01960b4>] (__handle_domain_irq) from [<c0490154>] (gic_handle_irq+0x58/0x9c)
Feb 21 11:10:33 odroid-stretch kernel: [ 1133.132548] [<c0490154>] (gic_handle_irq) from [<c01019f0>] (__irq_svc+0x70/0xb0)
Feb 21 11:10:33 odroid-stretch kernel: [ 1133.140002] Exception stack(0xee929f58 to 0xee929fa0)
Feb 21 11:10:33 odroid-stretch kernel: [ 1133.145041] 9f40:                                                       00000001 00000001
Feb 21 11:10:33 odroid-stretch kernel: [ 1133.153202] 9f60: 00000000 ee91b300 ee928000 c100b470 c100b4b4 00000008 00000000 c0d6487c
Feb 21 11:10:33 odroid-stretch kernel: [ 1133.161360] 9f80: 00000000 c0f86ca8 00000000 ee929fa8 c0188918 c010a3e0 200f0053 ffffffff
Feb 21 11:10:33 odroid-stretch kernel: [ 1133.169529] [<c01019f0>] (__irq_svc) from [<c010a3e0>] (arch_cpu_idle+0x24/0x44)
Feb 21 11:10:33 odroid-stretch kernel: [ 1133.176917] [<c010a3e0>] (arch_cpu_idle) from [<c015f474>] (do_idle+0x1e0/0x2c8)
Feb 21 11:10:33 odroid-stretch kernel: [ 1133.184283] [<c015f474>] (do_idle) from [<c015f8ec>] (cpu_startup_entry+0x18/0x1c)
Feb 21 11:10:33 odroid-stretch kernel: [ 1133.191834] [<c015f8ec>] (cpu_startup_entry) from [<401027ac>] (0x401027ac)
Feb 21 11:10:33 odroid-stretch kernel: [ 1133.198897] irq event stamp: 4265604
Feb 21 11:10:33 odroid-stretch kernel: [ 1133.202408] hardirqs last  enabled at (4265614): [<c0101a0c>] __irq_svc+0x8c/0xb0
Feb 21 11:10:33 odroid-stretch kernel: [ 1133.209817] hardirqs last disabled at (4265621): [<c0192e74>] console_unlock+0xc4/0x668
Feb 21 11:10:33 odroid-stretch kernel: [ 1133.217815] softirqs last  enabled at (4265474): [<c012e7e4>] irq_enter+0x78/0x80
Feb 21 11:10:33 odroid-stretch kernel: [ 1133.225250] softirqs last disabled at (4265475): [<c012e94c>] irq_exit+0x160/0x16c
Feb 21 11:10:33 odroid-stretch kernel: [ 1133.232827] ---[ end trace dd62ec96116457b8 ]---

[mories]

I have compiled a kernel 4.19.26 mainline + @LiquidAcid's mali driver of the 4.20.y tree (the only changes needed are those related to vmf_insert_pfn and devfreq_turbo_get/put).

My U3 boot and run quite correctly.
The problem I have identified for now is the lack of /dev/mali. The driver, both as module or built-in (and with debug enabled), is loaded correctly (see messages),

Code: Select all

[  122.698328] Mali<2>: Inserting Mali v600 device driver. 
[  122.698343] Mali<2>: Driver revision: r5p0-01rel0
[  122.698348] Mali<2>: mali_module_init() registering driver
[  122.698717] Mali: Mali device driver loaded

however, /dev/mali is not created.
Does anyone have any clue what can be the problem?

@hexdump, you have a similar configuration and it seems you have /dev/mali. Can you share your kernel config?

[mories]

...uses the armsoc driver and is useable - at least partially: there is no mouse cursor ....

Using https://github.com/mdrjr/xf86-video-arm ... e/r4p0.zip + patch https://github.com/akuster/meta-odroid/ ... rsor.patch
you get the cursor on X.

Regarding the mali driver (see my previous post) I can't generate /dev/mali, even though driver loads and initializes correctly.
Does anyone have any ideas?

[hexdump]

@mories: i have meanwhile sold my odroid u3, but this was the kernel config i used back then:

https://pastebin.com/vEPHEaEa

some patches which might be interesting for getting this running maybe (i saw similar problems i saw on the odroid u3 on an allwinner board as well and those patches fixed the problems there):

https://github.com/armbian/build/blob/m ... ator.patch
https://github.com/armbian/build/blob/m ... ator.patch

(coming from this issue: https://github.com/mripard/sunxi-mali/issues/63) and interesting might be this one here too - helped me with similar problems on allwinner:

https://github.com/mripard/sunxi-mali/issues/74

and do not forget to adjust the permission of your /dev/mali device once you get it working via udev rule.

good luck for getting mali and mainline working on your odroid u3 - hexdump

[hexdump]

... got another u3 again meanwhile and got mainline working including mali support - in case anyone is interested you can find all my files, patches, notes here:

https://github.com/hexdump0815/linux-ma ... -odroid-u3

maybe there is some interesting stuff in there for others running mainline on the u3 (like working cpu cooling without a fan on the odroid u3 - no more turning off due to overheating and lots of other stuff)

best wishes - hexdump

[hexdump]

some more updates regarding mainline on the odroid u3 are here now: viewtopic.php?f=55&t=3691&p=269246#p269246

best wishes - hexdump