From owner-freebsd-arm@freebsd.org Mon Oct 28 12:24:01 2019 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id B2A021A139D for ; Mon, 28 Oct 2019 12:24:01 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mail.blih.net (mail.blih.net [212.83.177.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.blih.net", Issuer "mail.blih.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 471v5s233Nz3NYV; Mon, 28 Oct 2019 12:24:00 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mail.blih.net (mail.blih.net [212.83.177.182]) by mail.blih.net (OpenSMTPD) with ESMTP id ca3e20f4; Mon, 28 Oct 2019 13:23:58 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=bidouilliste.com; h=date :from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type:content-transfer-encoding; s=mail; bh=eYgQlaMbTJu9Ot6MGfqtvNWxUFU=; b=CnPcCrKFwhl5Fwutx9PnVVnEcZoQ UVO8CXTC1c/Rxl+ZAbkc3WTEC34LLnvz9de/Y821C853IQ4OKJfPG5Ua/Gl8zDZW udLBWbLXowcCSocog/3H9Fsa8Xhd4jAwxf+erF/xOyqFSV2aVyaJ2pN9civUrKJ8 MAVp4YVUnbNu3sg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=bidouilliste.com; h=date :from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type:content-transfer-encoding; q=dns; s= mail; b=joq0JkPgOCVX2dcozH+5e6TWoeh8ysTBIFo0Atp6ynH+UCrneaBpU+Z7 kb8jgIMr+avrfx9OsHbK4X24Lo9+G0otbl3qpSh2d5tMQ1qhv7sHp5Q13KdlOcZV W3Z+ZpTLC3BYoltwcPGe3nudnDNRbJ8Z+E/3ro6DWtk1NMGWO8c= Received: from sonic.home.blih.net (ip-9.net-89-3-105.rev.numericable.fr [89.3.105.9]) by mail.blih.net (OpenSMTPD) with ESMTPSA id 58b739b8 TLS version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO; Mon, 28 Oct 2019 13:23:58 +0100 (CET) Date: Mon, 28 Oct 2019 13:23:58 +0100 From: Emmanuel Vadot To: mmel@freebsd.org Cc: Michal Meloun , Sleep Walker , freebsd-arm@freebsd.org Subject: Re: FreeBSD 13-CURRENT download status on RK3399 SBC`s Message-Id: <20191028132358.cd225b5127fb7396c11c4585@bidouilliste.com> In-Reply-To: <150c9db3-26f9-bd3b-eb16-c2801d6944f6@freebsd.org> References: <20191028121027.8c89aef2a2809cd844ccad80@bidouilliste.com> <150c9db3-26f9-bd3b-eb16-c2801d6944f6@freebsd.org> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.32; amd64-portbld-freebsd13.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 471v5s233Nz3NYV X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-5.99 / 15.00]; NEURAL_HAM_MEDIUM(-0.99)[-0.993,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; TAGGED_RCPT(0.00)[]; REPLY(-4.00)[] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Oct 2019 12:24:01 -0000 On Mon, 28 Oct 2019 12:59:30 +0100 Michal Meloun wrote: > > > On 28.10.2019 12:10, Emmanuel Vadot wrote: > > On Mon, 28 Oct 2019 13:57:57 +0300 > > Sleep Walker wrote: > > > >> Hi All! > >> > >> On Khadas-EDGE-V > >> > >> - mainline uboot U-Boot TPL 2019.10-rc3 > >> - bootup from SD > >> - eth OK > >> - uart OK > >> - emmc OK > >> - sd OK > >> - USB 2.0 OK > >> - USB 3.0 OK > >> - USB HID OK > >> - USB DISK OK > > > > Good to know that everything is working on this board too. > > > >> > >> On Rock Pi4 > >> > >> UEFI booting, very cool. > >> > >> But I can not log into the console. > >> > >> it seems it keeps rebooting. > >> > >> Here is the log: > >> https://pastebin.com/JFX7Ssnz > > > > This is known. Let me try to describe the problem. > > So the sd and panic: clknode_init_parent_idx: Invalid parent index 5 for clock sclk_sdmmc have multiple possible parent, one of them is > > the usb clock that is generated by the usb controller. The problem is > > that when we create the clock domain of the CRU (Clock and Reset > > Unit) the usb controller isn't probed yet because it needs clock from > > the CRU. When a clock domain is finished (by calling clkdom_finit) we > > need all the clocks to be present so we cannot add the unknown for now > > usb clock. > > So to fix this issue we need a way to create a fake clock when the CRU > > clock domain is created that will be later replaced by the usb > > controller. There is multiple approch to this and I'm not yet sure > > which one will work best. > > > > 1) We allow to list non-existing clock as parent and don't throw > > errors anymore at clkdom_finit but at some SYSINIT. > > This will work well with a big static kernel but not if the clock is > > created by a kernel module. > > 2) We create some fake clock domain where we can add clocks to it so > > it became a somewhat valid parent (but not usable so you cannot select > > it with clknode_set_parent for example) and when a clock domain is > > finished we remove clock from the fake domain that are present in the > > newly created one (as clock names are unique this should not cause > > problem). The question is then what should we do when we still have > > clock in the fake domain ? > > > > Maybe mmel@ have more ideas. > > > All above is right but is not related to this panic > "panic: clknode_init_parent_idx: Invalid parent index 5 for clock > sclk_sdmmc". In this case, the parent clock at index 5 for sclk_sdmmc > (named "clk_sdmmc in TRM) is CLK_24M (at least in my TRM). Mhm right, it's the clock parent id 4 ("upll" in the TRM) the one I was talking about. So I guess that puttin parent 4 = NULL and xin24m for parent 5 should work. > Problem (for me) is that rockchip clock code is slightly incomplete and it uses > different nomenclature (naming) that is in TRM. > Unfortunately, putting > right clock for this index doesn't helps much, my RockPRo64 still fails > with another (not yet identified)problem. What are the symptoms ? > I currently working on proper (i hope) solution for this problem -> > something like soft-link clock node - a pure pass-throw node, which can > link clock between domains used for cross-domain clock linking. > > Michal -- Emmanuel Vadot