0.7.9 Linux release from ayufan

[Bullet64]

Since kernel 4.4.132-1081-rockchip-ayufan this is fixed.

https://gitlab.com/ayufan-repos/rock64/l...s/26902413

[lucho]

This is a known issue with pulseaudio with the 4.4.132-1075 kernel that is default in the 0.7.9 Ayufan release.

You can check your kernel version with
uname -a

You can upgrade your kernel with
sudo apt-get update
sudo apt-get install linux-image-4.4.132-1083-rockchip-ayufan-gfd3f12ca5fae
and reboot

Thanks! I upgraded to the latest version at the moment (1087) and the audio started to work normally. Didn't remove the old kernel as it depends on a couple of other packages that, if that kernel is removed, would be removed on "autoremove" too, which seemed too dangerous to me.

Then I changed the timeout in /boot/extlinux/extlinux.conf from 10 to 3, and after a reboot, the RockPro64 stopped booting. I should had taken a look at its description first, because it turned out that it's in units of 100 ms, not 1 second as I have assumed (never assume anything!), and obviously 0,3 seconds are too short time for the timeout!

So I had to plug the microSD card again, turn the power on, remove the jumper after a few seconds, mount the eMMC module again, and fix the delay. This time I increased it to 30 (i.e., 3 seconds). Now the SBC boots from the eMMC module again. Unfortunately, it doesn't boot when both the microSD card and the eMMC module are installed, unless the jumper is inserted, in which case it boots from the microSD card. Also, it boots from the eMMC module only when neither the microSD card nor the jumper is inserted. And it's impossible to select the boot device only by inserting or removing the jumper when both the microSD card and the eMMC module are inserted. All the possible combinations are summarised below (S = boot from the microSD card, M = boot from the eMMC module, X = unsupported combination):

Code:

microSD eMMC jumper boot
     0    0    0    X
     0    0    1    X
     0    1    0    M
     0    1    1    X
     1    0    0    S
     1    0    1    S
     1    1    0    X
     1    1    1    S

Is this table correct?

Does extlinux show its prompt for the timeout duration to the serial console only, or also on the HDMI monitor? I can't see that since I have great trouble with the Vestel 22L1333G TV, which shows image only sometimes (EDID says 1080i interlaced mode is native, but it shows image only on 1080p progressive which I set after login with xrandr).

[Deathcrow]

Hello,

first off: Thank you for your hard work with this linux image!

Now to my question: Is it possible to get the eMMC module to work with linux-mainline kernel (4.18-rc8)? I encounter the following error:

Code:

Aug 30 17:56:26 rockpro64 kernel: mmc1: cqhci: timeout for tag 7
Aug 30 17:56:26 rockpro64 kernel: mmc1: cqhci: ============ CQHCI REGISTER DUMP ===========
Aug 30 17:56:26 rockpro64 kernel: mmc1: cqhci: Caps:      0x00000000 | Version:  0x00000510
Aug 30 17:56:26 rockpro64 kernel: mmc1: cqhci: Config:    0x00000001 | Control:  0x00000000
Aug 30 17:56:26 rockpro64 kernel: mmc1: cqhci: Int stat:  0x00000000 | Int enab: 0x00000006
Aug 30 17:56:26 rockpro64 kernel: mmc1: cqhci: Int sig:   0x00000006 | Int Coal: 0x00000000
Aug 30 17:56:26 rockpro64 kernel: mmc1: cqhci: TDL base:  0x00000000 | TDL up32: 0x00000000
Aug 30 17:56:26 rockpro64 kernel: mmc1: cqhci: Doorbell:  0x00000000 | TCN:      0x00000000
Aug 30 17:56:26 rockpro64 kernel: mmc1: cqhci: Dev queue: 0x00000000 | Dev Pend: 0x00000000
Aug 30 17:56:26 rockpro64 kernel: mmc1: cqhci: Task clr:  0x00000000 | SSC1:     0x00011000
Aug 30 17:56:26 rockpro64 kernel: mmc1: cqhci: SSC2:      0x00000000 | DCMD rsp: 0x00000000
Aug 30 17:56:26 rockpro64 kernel: mmc1: cqhci: RED mask:  0xfdf9a080 | TERRI:    0x00000000
Aug 30 17:56:26 rockpro64 kernel: mmc1: cqhci: Resp idx:  0x00000000 | Resp arg: 0x00000000
Aug 30 17:56:26 rockpro64 kernel: mmc1: sdhci: ============ SDHCI REGISTER DUMP ===========
Aug 30 17:56:26 rockpro64 kernel: mmc1: sdhci: Sys addr:  0x00000000 | Version:  0x00001002
Aug 30 17:56:26 rockpro64 kernel: mmc1: sdhci: Blk size:  0x00007200 | Blk cnt:  0x00000000
Aug 30 17:56:26 rockpro64 kernel: mmc1: sdhci: Argument:  0x00010000 | Trn mode: 0x00000010
Aug 30 17:56:26 rockpro64 kernel: mmc1: sdhci: Present:   0x1fff0000 | Host ctl: 0x00000034
Aug 30 17:56:26 rockpro64 kernel: mmc1: sdhci: Power:     0x0000000b | Blk gap:  0x00000080
Aug 30 17:56:26 rockpro64 kernel: mmc1: sdhci: Wake-up:   0x00000000 | Clock:    0x00000007
Aug 30 17:56:26 rockpro64 kernel: mmc1: sdhci: Timeout:   0x0000000e | Int stat: 0x00000000
Aug 30 17:56:26 rockpro64 kernel: mmc1: sdhci: Int enab:  0x02ff4000 | Sig enab: 0x02ff4000
Aug 30 17:56:26 rockpro64 kernel: mmc1: sdhci: AC12 err:  0x00000000 | Slot int: 0x00000000
Aug 30 17:56:26 rockpro64 kernel: mmc1: sdhci: Caps:      0x44edc880 | Caps_1:   0x800020f7
Aug 30 17:56:26 rockpro64 kernel: mmc1: sdhci: Cmd:       0x00000d1a | Max curr: 0x00000000
Aug 30 17:56:26 rockpro64 kernel: mmc1: sdhci: Resp[0]:   0x00000900 | Resp[1]:  0x642017c8
Aug 30 17:56:26 rockpro64 kernel: mmc1: sdhci: Resp[2]:   0x4e436172 | Resp[3]:  0x00880103
Aug 30 17:56:26 rockpro64 kernel: mmc1: sdhci: Host ctl2: 0x00000083
Aug 30 17:56:26 rockpro64 kernel: mmc1: sdhci: ADMA Err:  0x00000000 | ADMA Ptr: 0xf711c208
Aug 30 17:56:26 rockpro64 kernel: mmc1: sdhci: ============================================
Aug 30 17:56:26 rockpro64 kernel: mmc1: running CQE recovery
Aug 30 17:56:26 rockpro64 kernel: print_req_error: I/O error, dev mmcblk1boot0, sector 8064

I also tried to compile kernel for myself and tried the torvalds 4.19 sources. Both with similar results. 4.4 kernel works without problems.

Is usage of eMMC module currently impossible with mainline kernel?

Edit: There appears to be another kernel error (null pointer reference) in relation to the zram module, when using kernel 4.18. This one seems to appear more or less randomly, but I was able to reliable reproduce it by running 'mkswap' a bunch of times on the /dev/zram* devices. Looks something like this

Code:

Sep  7 16:05:31 rockpro64 kernel: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000
Sep  7 16:05:31 rockpro64 kernel: Mem abort info:
Sep  7 16:05:31 rockpro64 kernel:   ESR = 0x96000005
Sep  7 16:05:31 rockpro64 kernel:   Exception class = DABT (current EL), IL = 32 bits
Sep  7 16:05:31 rockpro64 kernel:   SET = 0, FnV = 0
Sep  7 16:05:31 rockpro64 kernel:   EA = 0, S1PTW = 0
Sep  7 16:05:31 rockpro64 kernel: Data abort info:
Sep  7 16:05:31 rockpro64 kernel:   ISV = 0, ISS = 0x00000005
Sep  7 16:05:31 rockpro64 kernel:   CM = 0, WnR = 0
Sep  7 16:05:31 rockpro64 kernel: user pgtable: 4k pages, 39-bit VAs, pgdp = 00000000604aa84e
Sep  7 16:05:31 rockpro64 kernel: [0000000000000000] pgd=0000000000000000, pud=0000000000000000
Sep  7 16:05:31 rockpro64 kernel: Internal error: Oops: 96000005 [#1] SMP
Sep  7 16:05:31 rockpro64 kernel: Modules linked in: zram xt_iprange iptable_filter xt_owner iptable_mangle ipt_MASQUERADE xt_mark iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack ip_tables x_tables rockchip_rga videobuf2_dma_sg v4l2_mem2mem rockchip_saradc crct10dif_ce dw_hdmi_i2s_audio phy_rockchip_pcie [last unloaded: zram]
Sep  7 16:05:31 rockpro64 kernel: CPU: 0 PID: 3115 Comm: mkswap Tainted: G        W         4.18.6-pf5-g45828c4d-dirty #1
Sep  7 16:05:31 rockpro64 kernel: Hardware name: Pine64 RockPro64 (DT)
Sep  7 16:05:31 rockpro64 kernel: pstate: 80000005 (Nzcv daif -PAN -UAO)
Sep  7 16:05:31 rockpro64 kernel: pc : zcomp_compress+0x34/0x60 [zram]
Sep  7 16:05:31 rockpro64 kernel: lr : zram_bvec_rw.isra.26+0x1f8/0x720 [zram]
Sep  7 16:05:31 rockpro64 kernel: sp : ffffffc0e9dbf830
Sep  7 16:05:31 rockpro64 kernel: x29: ffffffc0e9dbf830 x28: 0000000000000000
Sep  7 16:05:31 rockpro64 kernel: x27: 0000000000000000 x26: ffffff8000ff0000
Sep  7 16:05:31 rockpro64 kernel: x25: 000000000040020a x24: ffffffc0e9c25280
Sep  7 16:05:31 rockpro64 kernel: x23: 000000010003864e x22: ffffffc0e67c13c0
Sep  7 16:05:31 rockpro64 kernel: x21: ffffffc0e95f2000 x20: ffffffc0e9dbf8dc
Sep  7 16:05:31 rockpro64 kernel: x19: 0000000000000000 x18: 000000000000002f
Sep  7 16:05:31 rockpro64 kernel: x17: 00000055843c12a8 x16: ffffff80082ae470
Sep  7 16:05:31 rockpro64 kernel: x15: 000000000000013e x14: 0000007f99a4fdd8
Sep  7 16:05:31 rockpro64 kernel: x13: 000000000000000c x12: ffffff80098b2000
Sep  7 16:05:31 rockpro64 kernel: x11: 0000000000000000 x10: 0000000000000000
Sep  7 16:05:31 rockpro64 kernel: x9 : 0000000000000000 x8 : ffffffc0ef7eb870
Sep  7 16:05:31 rockpro64 kernel: x7 : 0000000000000000 x6 : 000000000000003f
Sep  7 16:05:31 rockpro64 kernel: x5 : 0000000000000008 x4 : ffffffc0e9dbf8dc
Sep  7 16:05:31 rockpro64 kernel: x3 : ffffffc0ee4c5bcc x2 : ffffffc0e9dbf8dc
Sep  7 16:05:31 rockpro64 kernel: x1 : ffffffc0e95f2000 x0 : 0000000000002000
Sep  7 16:05:31 rockpro64 kernel: Process mkswap (pid: 3115, stack limit = 0x000000001829a9a6)
Sep  7 16:05:31 rockpro64 kernel: Call trace:
Sep  7 16:05:31 rockpro64 kernel:  zcomp_compress+0x34/0x60 [zram]
Sep  7 16:05:31 rockpro64 kernel:  zram_bvec_rw.isra.26+0x1f8/0x720 [zram]
Sep  7 16:05:31 rockpro64 kernel:  zram_make_request+0x120/0x2fc [zram]
Sep  7 16:05:31 rockpro64 kernel:  generic_make_request+0xf4/0x320
Sep  7 16:05:31 rockpro64 kernel:  submit_bio+0x44/0x150
Sep  7 16:05:31 rockpro64 kernel:  submit_bh_wbc+0x178/0x1c0
Sep  7 16:05:31 rockpro64 kernel:  __block_write_full_page+0x230/0x440
Sep  7 16:05:31 rockpro64 kernel:  block_write_full_page+0x114/0x130
Sep  7 16:05:31 rockpro64 kernel:  blkdev_writepage+0x30/0x40
Sep  7 16:05:31 rockpro64 kernel:  __writepage+0x38/0x90
Sep  7 16:05:31 rockpro64 kernel:  write_cache_pages+0x1d4/0x420
Sep  7 16:05:31 rockpro64 kernel:  generic_writepages+0x48/0x80
Sep  7 16:05:31 rockpro64 kernel:  blkdev_writepages+0x28/0x40
Sep  7 16:05:31 rockpro64 kernel:  do_writepages+0x3c/0xe0
Sep  7 16:05:31 rockpro64 kernel:  __filemap_fdatawrite_range+0xbc/0x110
Sep  7 16:05:31 rockpro64 kernel:  file_write_and_wait_range+0x48/0xd0
Sep  7 16:05:31 rockpro64 kernel:  blkdev_fsync+0x3c/0x70
Sep  7 16:05:31 rockpro64 kernel:  vfs_fsync_range+0x4c/0x90
Sep  7 16:05:31 rockpro64 kernel:  do_fsync+0x48/0x90
Sep  7 16:05:31 rockpro64 kernel:  sys_fsync+0x24/0x40
Sep  7 16:05:31 rockpro64 kernel:  el0_svc_naked+0x30/0x34
Sep  7 16:05:31 rockpro64 kernel: Code: 52840000 b9000280 aa1503e1 aa1403e4 (a9401663)
Sep  7 16:05:31 rockpro64 kernel: ---[ end trace 43b007dfa181aadd ]---

As long as I remove the eMMC module and disable zram the mainline kernel seems to run very stable for a headless server and I'm quite happy with the USB3.0 performance.

[dukla2000]

Now to my question: Is it possible to get the eMMC module to work with linux-mainline kernel (4.18-rc8)? I encounter the following error:
...
I also tried to compile kernel for myself and tried the torvalds 4.19 sources. Both with similar results. 4.4 kernel works without problems.
...
Is usage of eMMC module currently impossible with mainline kernel?

I have the exact same fault with 4.18 rc8 from Ayufan, never a problem with 4.4. I suspect it is fixable - my guess is something DTS? But way beyond my skills so have to sit and wait. (I was gonna wait till Ayufan does a 4.18 "final" release and then figure a thread on what works/does not at 4.18. Because the memory and NVMe stuff is really enticing, it is a question if I can work around the limitations. e.g. also lots of modules missing in Ayufan rc builds, e.g. btusb)

[Deathcrow]

it is a question if I can work around the limitations. e.g. also lots of modules missing in Ayufan rc builds, e.g. btusb

You could just try to build the kernel with the modules you need yourself in order to try them out. It's pretty easy. Just git clone ayufan's linux-mainline repo, apt-get install gcc and friends (if you haven't already), run 'make menuconfig', select Y or M for the stuff you need, then build with 'make -j6 bindeb-pkg'. The package will be in the parent folder and can just be installed as usual with dpkg -i. Thanks to the work of the maintainers of this image it will even take care of modifying extlinux.conf. If you mess it up you can just go back to the old kernel by editing extlinux.conf manually or choosing a dfiferent kernel via serial console.

[antofede91]

Hi, i've a ROCKPRO64 with 0.7.9 Linux release from ayufan from Micro SD and it says:

Direct firmware load for rockchip/dptx.bin failed with error -2

Do you know how to resolve this problem?

[dukla2000]

Hi, i've a ROCKPRO64 with 0.7.9 Linux release from ayufan from Micro SD and it says:

Direct firmware load for rockchip/dptx.bin failed with error -2

Do you know how to resolve this problem?

It is only a problem if you are trying to get displayport to work. In which case no current options.

[Raikiri1316]

Had issues with 079 getting the PCIE SATA card to work.

Ended up reverting to 1077 so I could utilize my hard disks.

[festor89]

Hello all. Is there somewhere description step by step how to install, Ubuntu 18.04 Bionic Containers Image (DockerCE & Kubernetes) [microSD / eMMC Boot] [0.7.9] by ayufan

I'm a beginner, I was looking at the forum but I did not find anything specific.
The idea is that after copying the image to the emmc memory, I start the system, log in, the system information screen and the command line start up. And here I stuck what command to enter to run the system ?? Thank you for your understanding and help.
Sorry for my bad english

[festor89]

I attach a screenshot
 Link