On 07/04/2018 01:25 AM, Vasily Khoruzhick wrote: > On Tue, Jul 3, 2018 at 2:22 PM, André Przywara <andre.przyw...@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. _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
