etatto

Well I've tried your image and mine on one of my VIM Pro: It boots without any issue (with the right dtb of course ). I might say the images are not the cause of the hang on my VIM2 Max Perhaps a stupid question and not related to my issue: Which revision of the VIM2 Max do you have? Mine is a V1.2 201707. I have spotted on Google V1.0 and V1.1 for the VIM2 and I don't know what might be the differences...

Also I forget to ask : What are the use case of these dtbs? They are for the partioning of the emmc, right?

Sorry I forget to list this step but I have done it. For a matter of fact, I have tried all the dtbs for VIM2 with the same result...

Well I'm puzzled, but maybe I'm doing it the wrong way coz' your image @balbes150 also doesn't boot with the same hang/error... I'm doing the same as I have done when installing Armbian on my Khadas VIM Pros: - Android on the emmc, - Flashing aml_autoscript.zip with System update application under android, - Burning the image on sdcard with Etcher, - Sdcard in sd-slot, - Power on => Boot Armbian from the sdcard So have these steps changed for the VIM2 (or perhaps for all S905x/S912) ??? Thanks.

[ 6.531439@3] hdmitx: update physcial size: 16 9 [ 6.536003@3] config: hdmitx: unknown cmd: 0x14000000 [ 27.556171@3] INFO: rcu_preempt detected stalls on CPUs/tasks: [ 27.577311@6] 3-...: (1 GPs behind) idle=4f9/140000000000000/0 softirq=341/342 fqs=2593 [ 27.585638@6] (detected by 6, t=5259 jiffies, g=-78, c=-79, q=51) [ 27.593029@6] Task dump for CPU 3: [ 27.598885@6] hdmi_init.sh R running task 0 2371 1 0x00000002 [ 27.606987@6] Call trace: [ 27.612905@6] [<ffffff8009086434>] __switch_to+0x94/0xa8 [ 27.618911@6] [<0000000000000001>] 0x1 [ 62.476130@1] fb: mem_free_work, free memory: addr:6af000 [ 90.576173@1] INFO: rcu_preempt detected stalls on CPUs/tasks: [ 90.592272@5] 3-...: (1 GPs behind) idle=4f9/140000000000000/0 softirq=341/342 fqs=10404 [ 90.601310@5] (detected by 5, t=21014 jiffies, g=-78, c=-79, q=66) [ 90.609069@5] Task dump for CPU 3: [ 90.615263@5] hdmi_init.sh R running task 0 2371 1 0x00000002 [ 90.623679@5] Call trace: [ 90.629876@5] [<ffffff8009086434>] __switch_to+0x94/0xa8 [ 90.636119@5] [<0000000000000001>] 0x1 [ 153.600178@5] INFO: rcu_preempt detected stalls on CPUs/tasks: [ 153.616626@7] 3-...: (1 GPs behind) idle=4f9/140000000000000/0 softirq=341/342 fqs=18194 [ 153.625694@7] (detected by 7, t=36768 jiffies, g=-78, c=-79, q=66) [ 153.633622@7] Task dump for CPU 3: [ 153.639999@7] hdmi_init.sh R running task 0 2371 1 0x00000002 [ 153.648565@7] Call trace: [ 153.654867@7] [<ffffff8009086434>] __switch_to+0x94/0xa8 [ 153.661227@7] [<0000000000000001>] 0x1 [ 167.944416@0] random: crng init done [ 216.624164@0] INFO: rcu_preempt detected stalls on CPUs/tasks: [ 216.645877@6] 3-...: (1 GPs behind) idle=4f9/140000000000000/0 softirq=341/342 fqs=25995 [ 216.654917@6] (detected by 6, t=52528 jiffies, g=-78, c=-79, q=66) [ 216.662897@6] Task dump for CPU 3: [ 216.669308@6] hdmi_init.sh R running task 0 2371 1 0x00000002 [ 216.677892@6] Call trace: [ 216.684205@6] [<ffffff8009086434>] __switch_to+0x94/0xa8 [ 216.690568@6] [<0000000000000001>] 0x1 [ 242.696550@4] INFO: task kworker/1:1:1238 blocked for more than 120 seconds. [ 242.715772@4] Not tainted 4.9.40 #1 [ 242.722104@4] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 242.730956@4] kworker/1:1 D 0 1238 2 0x00000000 [ 242.740331@4] Workqueue: events aml_tvout_mode_work [ 242.748435@4] Call trace: [ 242.754944@4] [<ffffff8009086434>] __switch_to+0x94/0xa8 [ 242.761530@4] [<ffffff8009bf2cc4>] __schedule+0x21c/0x748 [ 242.768131@4] [<ffffff8009bf3230>] schedule+0x40/0xa8 [ 242.774691@4] [<ffffff8009bf3724>] schedule_preempt_disabled+0x1c/0x30 [ 242.782158@4] [<ffffff8009bf4ff4>] __mutex_lock_slowpath+0xac/0x188 [ 242.789341@4] [<ffffff8009bf5138>] mutex_lock+0x68/0x80 [ 242.795992@4] [<ffffff8009821e40>] validate_vmode+0x30/0x90 [ 242.802614@4] [<ffffff8009822ae8>] refresh_tvout_mode+0x58/0xf0 [ 242.809496@4] [<ffffff8009822e20>] aml_tvout_mode_work+0x30/0xa8 [ 242.816486@4] [<ffffff80090bbf58>] process_one_work+0x1e0/0x498 [ 242.823435@4] [<ffffff80090bc260>] worker_thread+0x50/0x4a8 [ 242.830124@4] [<ffffff80090c2cd8>] kthread+0xf8/0x110 [ 242.836821@4] [<ffffff8009083680>] ret_from_fork+0x10/0x50 [ 279.648172@4] INFO: rcu_preempt detected stalls on CPUs/tasks: [ 279.670232@6] 3-...: (1 GPs behind) idle=4f9/140000000000000/0 softirq=341/342 fqs=33795 [ 279.679620@6] (detected by 6, t=68284 jiffies, g=-78, c=-79, q=66) [ 279.687897@6] Task dump for CPU 3: [ 279.694527@6] hdmi_init.sh R running task 0 2371 1 0x00000002 [ 279.703470@6] Call trace: [ 279.710197@6] [<ffffff8009086434>] __switch_to+0x94/0xa8 [ 279.717022@6] [<0000000000000001>] 0x1 Is it perhaps because I'm running headless with a screen?

Ok, I will try this week-end. Thanks a lot!

Thanks, I wait

Sorry I forget these kernel = dev, 4.9.40 image = debian stretch dtb = kvim2.dtb; I also try kvim2_linux.dtb with the same result

Hi @balbes150 Could you please tell me if the latest (on the 27th of January as of this writing) on your github is working on a Khadas VIM2 Max? I have compiled for Debian Stretch and the boot doesn't pass this stage, with a stack trace: [ 6.477332@3] hdmitx: update physcial size: 16 9 [ 6.481921@3] config: hdmitx: unknown cmd: 0x14000000 [ 27.491744@3] INFO: rcu_preempt detected stalls on CPUs/tasks: [ 27.495829@1] 3-...: (0 ticks this GP) idle=0f7/140000000000000/0 softirq=392/393 fqs=2626 [ 27.502733@1] (detected by 1, t=5255 jiffies, g=-98, c=-99, q=48) [ 27.508858@1] Task dump for CPU 3: [ 27.513010@1] hdmi_init.sh R running task 0 2370 1 0x00000002 [ 27.520873@1] Call trace: [ 27.525077@1] [<ffffff8009086434>] __switch_to+0x94/0xa8 [ 27.529331@1] [<000000000000000a>] 0xa [ 62.475758@1] fb: mem_free_work, free memory: addr:6af000 [ 90.511743@1] INFO: rcu_preempt detected stalls on CPUs/tasks: [ 90.516096@1] 3-...: (0 ticks this GP) idle=0f7/140000000000000/0 softirq=392/393 fqs=10502 [ 90.523339@1] (detected by 1, t=21010 jiffies, g=-98, c=-99, q=70) [ 90.529551@1] Task dump for CPU 3: [ 90.533926@1] hdmi_init.sh R running task 0 2370 1 0x00000002 [ 90.541768@1] Call trace: [ 90.546145@1] [<ffffff8009086434>] __switch_to+0x94/0xa8 [ 90.550546@1] [<000000000000000a>] 0xa [ 153.531742@1] INFO: rcu_preempt detected stalls on CPUs/tasks: [ 153.536221@1] 3-...: (0 ticks this GP) idle=0f7/140000000000000/0 softirq=392/393 fqs=18377 [ 153.543592@1] (detected by 1, t=36765 jiffies, g=-98, c=-99, q=70) [ 153.549803@1] Task dump for CPU 3: [ 153.554288@1] hdmi_init.sh R running task 0 2370 1 0x00000002 [ 153.562099@1] Call trace: [ 153.566551@1] [<ffffff8009086434>] __switch_to+0x94/0xa8 [ 153.571047@1] [<000000000000000a>] 0xa [ 160.067789@0] random: crng init done [ 216.551741@0] INFO: rcu_preempt detected stalls on CPUs/tasks: [ 216.556227@1] 3-...: (0 ticks this GP) idle=0f7/140000000000000/0 softirq=392/393 fqs=26252 [ 216.563637@1] (detected by 1, t=52520 jiffies, g=-98, c=-99, q=70) [ 216.569849@1] Task dump for CPU 3: [ 216.574384@1] hdmi_init.sh R running task 0 2370 1 0x00000002 [ 216.582187@1] Call trace: [ 216.586653@1] [<ffffff8009086434>] __switch_to+0x94/0xa8 [ 216.591156@1] [<000000000000000a>] 0xa [ 242.695808@0] INFO: task kworker/1:1:1237 blocked for more than 120 seconds. [ 242.701706@0] Not tainted 4.9.40 #1 [ 242.706184@0] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 242.713600@0] kworker/1:1 D 0 1237 2 0x00000000 [ 242.721111@0] Workqueue: events aml_tvout_mode_work [ 242.728395@0] Call trace: [ 242.732988@0] [<ffffff8009086434>] __switch_to+0x94/0xa8 [ 242.737651@0] [<ffffff8009be2864>] __schedule+0x21c/0x748 [ 242.742638@0] [<ffffff8009be2dd0>] schedule+0x40/0xa8 [ 242.747644@0] [<ffffff8009be32c4>] schedule_preempt_disabled+0x1c/0x30 [ 242.754111@0] [<ffffff8009be4b94>] __mutex_lock_slowpath+0xac/0x188 [ 242.760663@0] [<ffffff8009be4cd8>] mutex_lock+0x68/0x80 [ 242.765499@0] [<ffffff80098139e0>] validate_vmode+0x30/0x90 [ 242.771017@0] [<ffffff8009814688>] refresh_tvout_mode+0x58/0xf0 [ 242.776880@0] [<ffffff80098149c0>] aml_tvout_mode_work+0x30/0xa8 [ 242.782836@0] [<ffffff80090bbf58>] process_one_work+0x1e0/0x498 [ 242.788700@0] [<ffffff80090bc260>] worker_thread+0x50/0x4a8 [ 242.794219@0] [<ffffff80090c2cd8>] kthread+0xf8/0x110 [ 242.799221@0] [<ffffff8009083680>] ret_from_fork+0x10/0x50 [ 279.571742@0] INFO: rcu_preempt detected stalls on CPUs/tasks: [ 279.576483@1] 3-...: (0 ticks this GP) idle=0f7/140000000000000/0 softirq=392/393 fqs=34127 [ 279.584149@1] (detected by 1, t=68275 jiffies, g=-98, c=-99, q=70) [ 279.590466@1] Task dump for CPU 3: [ 279.595164@1] hdmi_init.sh R running task 0 2370 1 0x00000002 [ 279.602956@1] Call trace: [ 279.607721@1] [<ffffff8009086434>] __switch_to+0x94/0xa8 [ 279.612556@1] [<000000000000000a>] 0xa Do you have an idea? Tks.

Tks balbes150! I will check when you have updated Github.

Well after 2 days of testing, I don't have a clue why a true Jessie or Stretch image made for my Khadas VIM pro doesn't boot as it doesn't mount the rootfs. A true Buster boot like a charm, so I will continue my current project with such an image since I not really care which Debian flavor I use for it. I was first thinking it might be the initramsfs package version, but no : The Stretch and Buster versions are the same. After maybe the mounting with label identification : Nope, mounting with a device name or with UUID are also a no go. Puzzling, puzzling If someone has the slightest clue to put me on track, he/she will be in my dept BTW, debootstraping/updating packages on a Buster and newer qemu chroot, as of the 3rd of November, will not work anymore: it will froze with "qemu: Unsupported syscall: 277" since the apt 1.6~alpha3 version was migrated to testing/Buster at this date and seccomp is used on the 1.6 branch of apt, which is not implemented in the current version of qemu, so the Unsupported syscall message. The workaround I found out is to use snapshot.debian.org/archive/debian/20171101T160520Z as package repository, in place of httpredir.debian.org to build my Buster image. CU

Thanks for your answer concerning the testing repository. Maybe you might have a clue about the issue when commenting out this repository? I'm trying ti build a jessie image with the next kernel (it is the 4.14.0-rc5 as of this writing) for a Khadas VIM Pro board (S905X board) So to pinpoint the issue, I have build 2 images, one with the testing repository and one without. With logging the boot sequence, it seems the "true" jessie image hangs after printing the message "[drm] Cannot find any crtc or sizes" : [ 3.076125] mmcblk0: p1 p2 [ 3.081542] leds_pwm pwmleds: unable to request PWM for vim:red:power: -517 omain-0 init dvfs: 4 [ 3.105941] systemd-udevd[1237]: starting version 215 [ 3.596017] mmc1: new HS200 MMC card at address 0001 [ 3.596479] mmcblk1: mmc1:0001 AWPD3R 14.6 GiB [ 3.600079] mmcblk1boot0: mmc1:0001 AWPD3R partition 1 4.00 MiB [ 3.605844] mmcblk1boot1: mmc1:0001 AWPD3R partition 2 4.00 MiB [ 3.611774] mmcblk1rpmb: mmc1:0001 AWPD3R partition 3 4.00 MiB, chardev (242:0) [ 3.624449] leds_pwm pwmleds: unable to request PWM for vim:red:power: -517 [ 3.677968] [drm] Cannot find any crtc or sizes With the "buster upgraded" jessie image, it doesn't hang and the login prompt is displayed : [ 3.096645] mmcblk0: p1 p2 [ 3.101569] leds_pwm pwmleds: unable to request PWM for vim:red:power: -517 omain-0 init dvfs: 4 [ 3.303982] mmc1: new HS200 MMC card at address 0001 [ 3.304459] mmcblk1: mmc1:0001 AWPD3R 14.6 GiB [ 3.308099] mmcblk1boot0: mmc1:0001 AWPD3R partition 1 4.00 MiB [ 3.317859] mmcblk1boot1: mmc1:0001 AWPD3R partition 2 4.00 MiB [ 3.319723] mmcblk1rpmb: mmc1:0001 AWPD3R partition 3 4.00 MiB, chardev (242:0) [ 3.333393] leds_pwm pwmleds: unable to request PWM for vim:red:power: -517 [ 3.677882] [drm] Cannot find any crtc or sizes [ 3.946149] EXT4-fs (mmcblk0p2): mounted filesystem with writeback data mode. Opts: data=writeback [ 4.515283] systemd[1]: System time before build time, advancing clock. [ 4.547073] NET: Registered protocol family 10 [ 4.547969] Segment Routing with IPv6 [ 4.557808] ip_tables: (C) 2000-2006 Netfilter Core Team [ 4.572838] systemd[1]: systemd 235 running in system mode. (+PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD -IDN2 +IDN default-hierarchy=hybrid) [ 4.588257] systemd[1]: Detected architecture arm64. [ 4.594745] systemd[1]: Set hostname to <amlogic>. [ 4.751436] systemd[1]: File /lib/systemd/system/systemd-journald.service:33 configures an IP firewall (IPAddressDeny=any), but the local system does not support BPF/cgroup based firewalling. [ 4.762857] systemd[1]: Proceeding WITHOUT firewalling in effect! [ 4.775827] systemd[1]: File /lib/systemd/system/systemd-udevd.service:32 configures an IP firewall (IPAddressDeny=any), but the local system does not support BPF/cgroup based firewalling. [ 4.786943] systemd[1]: Proceeding WITHOUT firewalling in effect! [ 4.847590] systemd[1]: File /lib/systemd/system/systemd-logind.service:35 configures an IP firewall (IPAddressDeny=any), but the local system does not support BPF/cgroup based firewalling. [ 4.858856] systemd[1]: Proceeding WITHOUT firewalling in effect! [ 4.948859] systemd[1]: Created slice User and Session Slice. [ 5.111335] EXT4-fs (mmcblk0p2): re-mounted. Opts: commit=600,errors=remount-ro Debian GNU/Linux buster/sid amlogic ttyAML0 amlogic login: The "EXT4-fs (mmcblk0p2): mounted filesystem with writeback data mode. Opts: data=writeback" is displayed after when booting the "buster upgraded" jessie image, I think it might be the rootfs that is not mounted so the boot sequence cannot continue on the "true" jessie image...

Hi All! @balbes150: I saw you have added a Debian testing (buster/sid currently) repository when building jessie or stretch flavor of Armbian -> lib/general.sh#L142 So when building myself, the jessie (or stretch) image is not anymore a true Debian Jessie. Could you please explain your reasoning for adding this testing repository? Tks. On the side note also, my build images are not booting if I commented out this repository when buiding...

And mine has got an AP6212 without the A The pictures on FriendlyARM site show an AP6212A on the PCB, but the features listing and the pdf schematics clearly indicate AP6212

Yes I first try with this ap6212-bluetooth script but without success. A "bcm43xx_init" always time out, like "Initialization timed out."