FreeBSD 13-CURRENT download status on RK3399 SBC`s

Mon Oct 28 14:00:44 UTC 2019

On 28.10.2019 14:27, Sleep Walker wrote:
> Will there be any recommendations on how to avoid a mistake
> clknode_init_parent_idx: Invalid parent index 5 for clock sclk_sdmmc
> You will offer some patches.
> I am ready to try them. 
Only gross hack, nothing which can be committed. (added clock at index 4
is wrong (it should be 'upll'.
But we don't have this branch defined at all, and rk_clk_composite don't
likes sparse clock arrays...)

Michal
> пн, 28 окт. 2019 г. в 16:21, Emmanuel Vadot <manu at bidouilliste.com>:
> 
>> On Mon, 28 Oct 2019 14:10:32 +0100
>> Michal Meloun <meloun.michal at gmail.com> wrote:
>>
>>>
>>>
>>> On 28.10.2019 13:23, Emmanuel Vadot wrote:
>>>> On Mon, 28 Oct 2019 12:59:30 +0100
>>>> Michal Meloun <meloun.michal at 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 at 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 ?
>>>>
>>>
>>> See attached log. It occurs on every second hard reboot (by pressing
>>> reset button) reboot, only if both clusters are enabled. And, please,
>>> don't ask me why :)
>>> Michal
>>>
>>> ----------------------------------------------------------------------
>>> ...
>>> WARNING: WITNESS option enabled, expect reduced performance.
>>> uhub2: 1 port with 1 removable, self powered
>>> uhub4: 1 port with 1 removable, self powered
>>> uhub3: 2 ports with 2 removable, self powered
>>> Root mount waiting for: usbus4 usbus2 usbus0
>>> uhub0: 1 port with 1 removable, self powered
>>> uhub1: 1 port with 1 removable, self powered
>>> Root mount waiting for: usbus4 usbus0
>>> ugen4.2: <JetFlash Mass Storage Device> at usbus4
>>> umass0 on uhub3
>>> umass0: <JetFlash Mass Storage Device, class 0/0, rev 2.00/11.00, addr
>>> 1> on usbus4
>>> umass0:  SCSI over Bulk-Only; quirks = 0x8100
>>> umass0:0:0: Attached to scbus0
>>> da0 at umass-sim0 bus 0 scbus0 target 0 lun 0
>>> da0: <JetFlash Transcend 4GB 1100> Removable Direct Access SPC-2 SCSI
>> device
>>> da0: Serial Number 02UIG9DQD7J9880G
>>> da0: 40.000MB/s transfers
>>> da0: 3764MB (7708672 512 byte sectors)
>>> da0: quirks=0x12<NO_6_BYTE,NO_RC16>
>>> ugen0.2: <JetFlash Mass Storage Device> at usbus0
>>> umass1 on uhub0
>>> umass1: <JetFlash Mass Storage Device, class 0/0, rev 2.00/11.00, addr
>>> 2> on usbus0
>>> umass1:  SCSI over Bulk-Only; quirks = 0x8100
>>> umass1:1:1: Attached to scbus1
>>> Kernel page fault with the following non-sleepable locks held:
>>> exclusive sleep mutex CAM bus lock (CAM bus lock) r = 0
>>> (0xfffffd0003fe7260) locked @
>> /usr2/Meloun/git/pmap/sys/cam/cam_xpt.c:1039
>>> exclusive sleep mutex XPT topology lock (XPT topology lock) r = 0
>>> (0xffff000000d0dee8) locked @
>> /usr2/Meloun/git/pmap/sys/cam/cam_xpt.c:5367
>>> exclusive sleep mutex CAM device lock (CAM device lock) r = 0
>>> (0xfffffd000e02d4d0) locked @
>> /usr2/Meloun/git/pmap/sys/cam/cam_xpt.c:5494
>>> stack backtrace:
>>> #0 0xffff0000005b3ae0 at witness_checkorder+0xd04
>>> #1 0xffff0000005b4afc at witness_warn+0x3f8
>>> #2 0xffff000000899c6c at do_el1h_sync+0x318
>>> #3 0xffff000000899a78 at do_el1h_sync+0x124
>>> #4 0xffff000000880874 at handle_el1h_sync+0x74
>>> #5 0xffff0000000161f0 at xpt_remove_periph+0x38
>>> #6 0xffff000000012674 at cam_periph_release_locked_buses+0x158
>>> #7 0xffff00000001284c at cam_periph_release_locked+0x1c
>>> #8 0xffff00000002de74 at nvme_get_identify_ns+0x6d18
>>> #9 0xffff00000001b474 at xpt_done_direct+0x3b4
>>> #10 0xffff00000001d26c at xpt_register_async+0x13fc
>>> #11 0xffff00000050b040 at fork_exit+0x7c
>>>   x0: fffffd0003fe7260
>>
>>  Ah yes this is known too, I only use the small cluster. I've presume a
>> mutex problem between the clusters but I'm not sure. Not that this only
>> shows up if you use a usb disk (well anything CAM I guess).
>>
>> --
>> Emmanuel Vadot <manu at bidouilliste.com>
>>
> 
-------------- next part --------------

diff --git a/sys/arm64/rockchip/clk/rk3399_cru.c b/sys/arm64/rockchip/clk/rk3399_cru.c
index 316efedf3e2..a19c8a8fb9e 100644
--- a/sys/arm64/rockchip/clk/rk3399_cru.c
+++ b/sys/arm64/rockchip/clk/rk3399_cru.c
@@ -1739,7 +1739,7 @@ static struct rk_clk_composite_def hclk_sd = {
 
 #define	SCLK_SDMMC		76
 
-static const char *sclk_sdmmc_parents[] = {"cpll", "gpll", "npll", "ppll"};
+static const char *sclk_sdmmc_parents[] = {"cpll", "gpll", "npll", "ppll", "xin24m", "xin24m"};
 
 static struct rk_clk_composite_def sclk_sdmmc = {
 	.clkdef = {
