All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andre Przywara <andre.przywara@arm.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH] arm64: allwinner: a64: Disable ehci1 and ohci1 for bananapi, nanopi
Date: Wed, 4 Jul 2018 09:33:34 +0100	[thread overview]
Message-ID: <1f435033-97e8-2908-5c89-84100268a21c@arm.com> (raw)
In-Reply-To: <CA+E=qVfjT=54WtntrUgrU_2noZGdQ-FpRrLbdLW_Ntv3pP9iRQ@mail.gmail.com>

Hi,

On 04/07/18 01:50, Vasily Khoruzhick wrote:
> On Tue, Jul 3, 2018 at 5:45 PM, André Przywara <andre.przywara@arm.com> wrote:
> 
>>>
>>> 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.
> 
> Yes, I did. We'll need it to handle all the controller quirks
> eventually (new clock mode, calibration, delays).
> Currently we have a number of ifdefs in the driver.

Yes, and they somewhat have to stay because of that, and we might have
to add some more, even. That's admittedly not pretty, and we were
discussing that already (the other thread that Jagan pointed you to).
But for the SPL specifically we just need some basic functionality to
load 600KB or so of data.
Or did you experience any problems with that? In general I think we can
get away with less performance for the sake of a simpler driver. For
instance I believe we will probably never need support for HS modes.

So yes: the usefulness of the DM_MMC conversion is somewhat questionable
because of this. As you have shown below ("overflowed by 10K") DM_MMC is
not really an option for the SPL, so we need to keep the old code
around. Or we follow the idea of having a much simpler, separate driver
just for the SPL.

>>> 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.
> 
> That won't be enough:
> 
> aarch64-linux-gnu-ld.bfd: region `.sram' overflowed by 10584 bytes

Well, I don't see a way of achieving this, really. I think adding
SPL_DM_MMC would even overflow a 32-bit (Thumb2) SPL. And I am not sure
that adding a TPL is the right answer to this problem of using the
driver model. It's a boot loader, after all.

Cheers,
Andre.

      reply	other threads:[~2018-07-04  8:33 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-07-02 20:53 [U-Boot] [PATCH] arm64: allwinner: a64: Disable ehci1 and ohci1 for bananapi, nanopi Jagan Teki
2018-07-02 21:27 ` Marek Vasut
2018-07-02 21:40   ` Tom Rini
2018-07-02 21:57     ` Marek Vasut
2018-07-03  6:48       ` Maxime Ripard
2018-07-03 15:22       ` Andre Przywara
2018-07-03 16:25         ` Jagan Teki
2018-07-03 16:45           ` Marek Vasut
2018-07-03 16:44         ` Marek Vasut
2018-07-03 17:09           ` Jagan Teki
2018-07-03 17:56             ` Marek Vasut
2018-07-03 18:02               ` Jagan Teki
2018-07-03 18:16                 ` Marek Vasut
2018-07-03 18:29                   ` Jagan Teki
2018-07-03 12:36     ` Jagan Teki
2018-07-03 14:52       ` Tom Rini
2018-07-03 21:22         ` André Przywara
2018-07-04  0:25           ` Vasily Khoruzhick
2018-07-04  0:45             ` André Przywara
2018-07-04  0:50               ` Vasily Khoruzhick
2018-07-04  8:33                 ` Andre Przywara [this message]

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=1f435033-97e8-2908-5c89-84100268a21c@arm.com \
    --to=andre.przywara@arm.com \
    --cc=u-boot@lists.denx.de \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.