[U-Boot] [PATCH] arm64: allwinner: a64: Disable ehci1 and ohci1 for bananapi, nanopi

André Przywara andre.przywara at arm.com
Wed Jul 4 00:45:32 UTC 2018


On 07/04/2018 01:25 AM, Vasily Khoruzhick wrote:
> On Tue, Jul 3, 2018 at 2:22 PM, André Przywara <andre.przywara at arm.com> wrote:
> 
>>> Adding a few more people to the list.  It looks like b62cdbddedc3 was in
>>> response to fef73766d9ad.  So, this close to the release, what do we
>>> need to do to get things back to the state things were in for v2018.05?
>>> And then what are the combinations that aren't working and need to be
>>> addressed again in v2018.09 so that we can make forward progress?
>>
>> Without going into much detail here, the clock dependency for two
>> companion controllers on those A64 is weird, and we hack it somehow
>> since we don't have a DM_CLK driver for sunxi (yet, see below). That
>> works for init, since we just set already set bits. For shutdown, we
>> *happen* to take down the AHB gate clocks and resets correctly, because
>> the order of shutdown matches the dependency (EHCI first, the OHCI). Not
>> sure if this is intentional, though. It's fragile, but works.
>>
>> What we don't (and can't easily) model is another oddity: the USB clock
>> for [OE]HCI0 is actually the parent of [OE]HCI1. So if we need to bring
>> down *two* controllers and do it in the natural order, the second one is
>> dead before it can be disabled properly.
>>
>> This was somewhat hidden before, since we had only one controller in
>> operation. b62cdbddedc3 somewhat fixed that, but the DT for the Pine64
>> (which was the test vehicle) has the controller still disabled. Enabling
>> this (what I did) or using other boards (BananaPi and NanoPi from Jagan)
>> triggered this bug though.
>> AFAICS this parent relation only affects the A64 with its two
>> controllers, so:
>> - We could just fix it for now by *not* disabling the USB clocks (and
>> only those, gates and reset still go down) at all. This is basically one
>> part of my patch from yesterday (the second part is not needed).
>> - We do more effort and skip disabling for OHCI0, but disable both
>> clocks for OHCI1. This still relies on the order, but would probably
>> shut down the controllers. A bit hackish to implement, though.
>> I will try the second solution now and let you decide on the list.
>>
>> Long term:
>> The proper solution is a DT based DM_CLK driver, which models it like
>> Linux does. Work is underway[1], but this somewhat opens a can of worms
>> (needs DM support for UART, MMC, a DM_RESET driver, pinctrl ...), so it
>> takes a bit of time.
> 
> I tried enabling DM for MMC on A64 recently and unfortunately it results in
> SPL exceeding 32kb size limit.

Mmh, worked for me with this preliminary branch:
[1] https://github.com/apritzel/u-boot/commits/sunxi-dm-WIP
(which I forgot to link in my original email).
Did you enable SPL_DM_MMC or SPL_DM as well? I think there is not much
benefit in doing so, especially given the code size issue.

> So I guess we'll have to find a workaround for this issue as well...

I recently made a patch that shrinks the ARMv8 exception table code by
250 bytes. Not much, but might help. How much did you overflow?
I think eventually we should generate the exception table and put it
somewhere else than in SRAM A1. That has the potential of freeing up
about 2KB or so. I started rewriting the vectors to make this easier,
but it's not very high on my TODO list.

Cheers,
Andre.


>> Fixing the current ad-hoc solution somewhat properly with ref-counting
>> is not easy (two driver files) and not really worthwhile, I believe, but
>> we can make it work like described above until the proper solution comes
>> into play.
>>
>> Cheers,
>> Andre.



More information about the U-Boot mailing list