From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-4.0 required=3.0 tests=BAYES_00,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id EDEEAC433B4 for ; Mon, 17 May 2021 09:02:53 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id CFFCA611C2 for ; Mon, 17 May 2021 09:02:53 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235768AbhEQJEI convert rfc822-to-8bit (ORCPT ); Mon, 17 May 2021 05:04:08 -0400 Received: from mail.kernel.org ([198.145.29.99]:38714 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230087AbhEQJEH (ORCPT ); Mon, 17 May 2021 05:04:07 -0400 Received: from disco-boy.misterjones.org (disco-boy.misterjones.org [51.254.78.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 7B9A961184; Mon, 17 May 2021 09:02:51 +0000 (UTC) Received: from 78.163-31-62.static.virginmediabusiness.co.uk ([62.31.163.78] helo=why.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1liZ9F-001lN6-9a; Mon, 17 May 2021 10:02:49 +0100 Date: Mon, 17 May 2021 10:02:40 +0100 Message-ID: <87im3hvikv.wl-maz@kernel.org> From: Marc Zyngier To: Andreas =?UTF-8?B?RsOkcmJlcg==?= Cc: linux-rockchip@lists.infradead.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, devicetree@vger.kernel.org, Rob Herring Subject: Re: [PATCH 0/9] arm64: dts: rockchip: Initial Toybrick TB-RK1808M0 support In-Reply-To: <20210516230551.12469-1-afaerber@suse.de> References: <20210516230551.12469-1-afaerber@suse.de> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/27.1 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT X-SA-Exim-Connect-IP: 62.31.163.78 X-SA-Exim-Rcpt-To: afaerber@suse.de, linux-rockchip@lists.infradead.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, devicetree@vger.kernel.org, robh+dt@kernel.org X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 17 May 2021 00:05:42 +0100, Andreas Färber wrote: > > Hello Heiko et al., > > It seems linux-rockchip list only saw two RK1808 patches for ASoC in 2019. > Following up on a SUSE Hackweek 20 project of mine, here's some patches that > allow me to start booting into the TB-RK1808M0 mPCIe card's eMMC. > > Tested using its USB adapter, which allows to connect a serial cable and a > USB storage device that I load kernel+dtb from. It has a reset button, and > Ctrl+C allows to enter a U-Boot prompt (without EBBR/UEFI support though). > > Patches are based on the shipping toybrick.dtb file. > http://t.rock-chips.com/en/wiki.php?mod=view&id=110 gives instructions for > compiling sources, but no source download or link is actually provided. > > I encountered a hang: earlycon revealed it being related to KVM and > vGIC. Disabling KVM in Kconfig works around it, as does removing > the vGIC irq in DT. I've already tried low and high for the vGIC > interrupt, so no clue what might cause it. On an mPCIe card with 1 > GiB of RAM I figured KVM is not going to be a major use case, so if > we find no other solution, we could just delete the interrupts > property in its .dts, as demonstrated here. I think you figured it out wrong, for a number of reasons: - KVM hanging is usually a sign that you have described the platform the wrong way. Either you are stepping over reserved memory regions, or you have badly described the GIC itself. - It could also be a bug in KVM, which will need to be fixed. If that's because the HW is broken, we need to be able to detect it. - You cannot be prescriptive of what a user is going to run. People have been running KVM on systems with less memory than that. So no, we don't paper over these issues. We work out what is going wrong and we fix it. Thanks, M. -- Without deviation from the norm, progress is not possible.