From mboxrd@z Thu Jan 1 00:00:00 1970 From: Marek Vasut Date: Tue, 21 May 2019 21:54:33 +0200 Subject: [U-Boot] Making U-Boot smaller In-Reply-To: <20190521195311.GP22232@bill-the-cat> References: <1b28727d-efb0-cadb-4541-9383d4056808@denx.de> <20190521195311.GP22232@bill-the-cat> Message-ID: <21ce98e8-d687-14dc-5023-d7e005cf5c74@denx.de> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On 5/21/19 9:53 PM, Tom Rini wrote: > On Tue, May 21, 2019 at 09:32:29PM +0200, Marek Vasut wrote: >> On 5/21/19 6:56 PM, Jagan Teki wrote: >>> On Tue, May 21, 2019 at 10:14 PM Simon Glass wrote: >>>> >>>> Hi, >>>> >>>> (moved from thread "U-Boot PXA support") >>>> >>>> We have of-platdata, which produces C data from the DT, for linking >>>> into U-Boot. It saves libfdt and DT space. But we still have the DM >>>> overhead. >>>> >>>> We have binman which can insert values into the binary after >>>> link-time. This is barely used at present, only for accessing the >>>> location of things in flash. >>>> >>>> Another thing is that every little tweak and feature adds a few bytes >>>> and there are dozens of them in each release. It would be interesting >>>> to build a board from 10 years ago (like PXA) and see where the growth >>>> is. My bet is that we could add Kconfig options to disable extra >>>> features (and enhancements of features) and make quite a difference. >>>> >>>> For DM, I think it would be interesting to revisit and compare against >>>> the initial release, and see if some features could be made optional >>>> in SPL. >>>> >>>> Finally I feel we could implement a single-device API for where >>>> CONFIG_SPL_DM is not set. We could use the debug UART for serial, a >>>> single instance of tiny MMC for MMC, etc. >>> >>> This is what I'm looking for quite sometime, a tiny MMC which would >>> bypass the mmc stack and do the possible stuff in SPL, since we don't >>> have any option to use full DM in SPL (specifically for Allwinner 64 >>> SoC's). API that would atleast compatible with DM with small >>> foot-print would help. >> >> It's been in mainline for a long time, MMC_TINY. Creator CI20 uses it. > > I want to start by saying I'm not criticizing MMC_TINY. But I think > this highlights part of the problem of "lets do something that's not the > normal framework". Developers come up with a one-off, do their best to > make others know about it, and then a year later when someone else has a > similar problem, they may or may not stumble into the alternate path > fix. > > So, getting back to specifics, what would it take to do both: > - Make MMC_TINY abstract enough sunxi or TI or ... could plug-in and use > this for the "we just need MMC read, ROM probably already did enough > init for us for this" > - NOT blow up CI20 which I know is super tight on space. You can already do just that. Isn't the current problem a good/searchable documentation then ? Like the readthedocs stuff ? -- Best regards, Marek Vasut