Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 28 Oct 2019 13:23:58 +0100
From:      Emmanuel Vadot <manu@bidouilliste.com>
To:        mmel@freebsd.org
Cc:        Michal Meloun <meloun.michal@gmail.com>, Sleep Walker <s199p.wa1k9r@gmail.com>, 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:  <CAHa8N8_s5Q2kgoMBnOtN3-QnJNaKWX13yDVOdVOOkcR-_Wfkjg@mail.gmail.com> <20191028121027.8c89aef2a2809cd844ccad80@bidouilliste.com> <150c9db3-26f9-bd3b-eb16-c2801d6944f6@freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 28 Oct 2019 12:59:30 +0100
Michal Meloun <meloun.michal@gmail.com> wrote:

> 
> 
> On 28.10.2019 12:10, Emmanuel Vadot wrote:
> > On Mon, 28 Oct 2019 13:57:57 +0300
> > Sleep Walker <s199p.wa1k9r@gmail.com> 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 <manu@bidouilliste.com>



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20191028132358.cd225b5127fb7396c11c4585>