Linux-Rockchip Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Robin Murphy <robin.murphy-5wv7dgnIgG8@public.gmane.org>
To: Peter Geis <pgwipeout-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: heiko.stuebner-SN7IsUiht6C/RdPyistoZJqQE7yCjDx5@public.gmane.org,
	"open list:ARM/Rockchip SoC..."
	<linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org>
Subject: Re: [BUG] rk3399 fails to reboot correctly with PCIE device inserted
Date: Thu, 5 Dec 2019 17:31:08 +0000	[thread overview]
Message-ID: <eb09e106-e708-8857-690e-0052f860f19c@arm.com> (raw)
In-Reply-To: <CAMdYzYorsxrb1_xWjeAW-76QQ3a+Y+5iHskhM4M1N5rsUzoY7w-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>

On 05/12/2019 1:07 pm, Peter Geis wrote:
[...]
> The power off issue still exists, but I dug into the psci pm code for
> the poweroff function and unless there is a gpio this function is a
> no-op.
> For this reason I think the rk808 driver should be modified to set
> itself as the primary poweroff provider if the
> rockchip,system-power-controller flag is set.
> The other option is to somehow make ATF aware of the rk808 and have it
> trigger the poweroff.
> Thoughts on this?

Yeah, this seems to be a fundamental limitation of the RK808 that, short 
of wiring up a GPIO to literally hold down the power button, the only 
way to convince it to turn off is over I2C. Downstream kernels seem to 
hack around this by short-circuiting ATF on shutdown such that the RK808 
driver pulls the plug before PSCI_SYSTEM_OFF ever gets called, but I'm 
not sure that's viable in general since it precludes gracefully shutting 
down the Secure world software stack.

The main challenge in implementing I2C-based shutdown in ATF would be 
making it sufficiently robust without being incredibly complicated. 
Since the hardware resources are owned by the Non-Secure world, ATF 
can't make any assumptions about them being in a sane and usable state 
at the point where it might want to touch them - a shutdown could 
potentially be invoked while the I2C controller is already in the middle 
of a transfer. Possibly bit-banging GPIOs, including a bus recovery 
sequence, might be sufficient yet still relatively small and simple?

Robin.

> [0] https://github.com/ARM-software/arm-trusted-firmware/commit/45d4611563038486890b40d61e41b68213326afc
> [1] https://github.com/armbian/build/blob/master/patch/atf/atf-rk3399/switch-power-domains-on-before-reset.patch
>>
>>>
>>>>
>>>> Log is below:
>>>> [    0.261198] Detected PIPT I-cache on CPU5
>>>> [    0.261223] GICv3: CPU5: found redistributor 101 region 0:0x00000000fefa0000
>>>> [    0.261235] GICv3: CPU5: using allocated LPI pending table
>>>> @0x00000000f0120000
>>>> [    0.261263] CPU5: Booted secondary processor 0x0000000101 [0x410fd082]
>>>> [    0.261377] smp: Brought up 1 node, 6 CPUs
>>>> [    0.274833] SMP: Total of 6 processors activated.
>>>> [    0.275297] CPU features: detected: 32-bit EL0 Support
>>>> [    0.275801] CPU features: detected: CRC32 instructions
>>>> [    0.290797] CPU: All CPU(s) started at EL2
>>>> [    0.291242] alternatives: patching kernel code
>>>> [    0.294848] devtmpfs: initialized
>>>> [    0.311658] clocksource: jiffies: mask: 0xffffffff max_cycles:
>>>> 0xffffffff, max_idle_ns: 7645041785100000 ns
>>>> [    0.312629] futex hash table entries: 2048 (order: 5, 131072 bytes, linear)
>>>> [    0.315223] pinctrl core: initialized pinctrl subsystem
>>>> [    0.318097] DMI not present or invalid.
>>>> [    0.318989] NET: Registered protocol family 16
>>>> [    0.326798] DMA: preallocated 256 KiB pool for atomic allocations
>>>> [    0.327415] audit: initializing netlink subsys (disabled)
>>>> [    0.328106] audit: type=2000 audit(0.320:1): state=initialized
>>>> audit_enabled=0 res=1
>>>> [    0.330213] cpuidle: using governor menu
>>>> [    0.331160] hw-breakpoint: found 6 breakpoint and 4 watchpoint registers.
>>>> [    0.334653] Serial: AMBA PL011 UART driver
>>>> [    0.384125] HugeTLB registered 1.00 GiB page size, pre-allocated 0 pages
>>>> [    0.384800] HugeTLB registered 32.0 MiB page size, pre-allocated 0 pages
>>>> [    0.385483] HugeTLB registered 2.00 MiB page size, pre-allocated 0 pages
>>>> [    0.386146] HugeTLB registered 64.0 KiB page size, pre-allocated 0 pages
>>>> [    0.390063] cryptd: max_cpu_qlen set to 1000
>>>> [    0.396205] ACPI: Interpreter disabled.
>>>> [    0.399113] vcc3v3_pcie: supplied by vcc12v_dcin
>>>> [    0.400706] vcc5v0_sys: supplied by vcc12v_dcin
>>>> [    0.401426] vcc5v0_usb: supplied by vcc12v_dcin
>>>> [    0.402060] vcc3v3_sys: supplied by vcc5v0_sys
>>>> [    0.403275] iommu: Default domain type: Translated
>>>> [
>>>>
>>>>>
>>>>>>
>>>>>>>
>>>>>>>> With miniloader and both variants of u-boot, if you attempt a reboot
>>>>>>>> it never fires the "reboot: Restarting system" message.
>>>>>>>> If you trigger a sysrq reboot at this stage, it will reboot, but fails
>>>>>>>> to start up the two a72 cores and subsequently hangs a second later
>>>>>>>> when it loads the first dma driver.
>>>>>>>>
>>>>>>>> With TPL/SPL on mainline-u-boot (I can't get rockchip-u-boot to work
>>>>>>>> with TPL/SPL), it fires the "reboot: Restarting system" message, but
>>>>>>>> never reboots.
>>>>>>>> sysrq does not function at this point.
>>>>>>>>
>>>>>>>> I believe the pcie controller is not being halted, and gets stuck in a
>>>>>>>> loop with the two a72 cores.
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> Linux-rockchip mailing list
>>>>>>>> Linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
>>>>>>>> http://lists.infradead.org/mailman/listinfo/linux-rockchip
>>>>>>>>

  parent reply	other threads:[~2019-12-05 17:31 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-25 16:28 [BUG] rk3399 fails to reboot correctly with PCIE device inserted Peter Geis
     [not found] ` <CAMdYzYrLX=z-OVoW9RVecjoYK1J8EfLQ=cV1aNUqPsXqiOU+2g-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2019-11-25 16:52   ` Robin Murphy
     [not found]     ` <2a5d91f1-033e-8acc-5b57-16ca77204a0b-5wv7dgnIgG8@public.gmane.org>
2019-11-25 17:10       ` Peter Geis
     [not found]         ` <CAMdYzYpdW13roxwHxD5w=XLBiyASp+biMqP-n2+QD9cL5g_hvg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2019-11-26  0:05           ` Peter Geis
     [not found]             ` <CAMdYzYoCzU4F66Hpdy6XBTWwWi+WmSo50R+sCSDEFOBKr84U1w-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2019-12-04 17:28               ` Peter Geis
     [not found]                 ` <CAMdYzYrHvGHRq51fbNp4Y=9HhaEUXhyoYt-dy70xVFrOmkNOTA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2019-12-04 17:42                   ` Robin Murphy
     [not found]                     ` <55c56fb7-9402-9798-9631-c1c3f607d663-5wv7dgnIgG8@public.gmane.org>
2019-12-04 18:28                       ` Peter Geis
     [not found]                         ` <CAMdYzYqvNa5_5xMnw=MVOL5iJQq_-cBVGtwQMXQ_JqLvyx=mYA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2019-12-05 13:07                           ` Peter Geis
     [not found]                             ` <CAMdYzYorsxrb1_xWjeAW-76QQ3a+Y+5iHskhM4M1N5rsUzoY7w-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2019-12-05 17:31                               ` Robin Murphy [this message]
     [not found]                                 ` <eb09e106-e708-8857-690e-0052f860f19c-5wv7dgnIgG8@public.gmane.org>
2019-12-05 18:10                                   ` Peter Geis

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=eb09e106-e708-8857-690e-0052f860f19c@arm.com \
    --to=robin.murphy-5wv7dgnigg8@public.gmane.org \
    --cc=heiko.stuebner-SN7IsUiht6C/RdPyistoZJqQE7yCjDx5@public.gmane.org \
    --cc=linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
    --cc=pgwipeout-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox