On 5/21/19 9:59 PM, Tom Rini wrote: > On Tue, May 21, 2019 at 09:54:33PM +0200, Marek Vasut wrote: >> 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 <s...@chromium.org> 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 ? > > Oh? Good! So, yes, it's documented as: > Enable MMC framework tinification support. This option is useful if > if your SPL is extremely size constrained. Heed the warning, enable > this option if and only if you know exactly what you are doing, if > you are reading this help text, you most likely have no idea :-) > > The MMC framework is reduced to bare minimum to be useful. No malloc > support is needed for the MMC framework operation with this option > enabled. The framework supports exactly one MMC device and exactly > one MMC driver. The MMC driver can be adjusted to avoid any malloc > operations too, which can remove the need for malloc support in SPL > and thus further reduce footprint. > > So, is write supported?
No, what for ? > When you say "one MMC device", is that static > at run-time or you can run-time init and use only one? IIRC it's compile time. > What would a > patch look like that enabled this on SoCFPGA? Thanks! Like nothing , since SoCFPGA probes itself from DT in SPL and there's enough space for that. However, if you want an example, CI20 is one. -- Best regards, Marek Vasut _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot