On 5/21/19 10:10 PM, Tom Rini wrote: > On Tue, May 21, 2019 at 10:01:42PM +0200, Marek Vasut wrote: >> 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 ? > > For the cases where writing is required, OK, so not possible here, > that's a fine trade-off.
Isn't there CONFIG_MMC_WRITE for that ? >>> 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. > > Where/how? I don't see it from the code right away.. CCing Ezequiel, he was digging in that recently and he likes CI20 . >>> 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. > > Yes, and now I'm trying to get it understood, so we can update the > Kconfig help if nothing else, how limited the driver is and how to > switch to it. So what would it look like to use this on SoCFPA, or > some other platform you're familiar with and that uses SPL? iMX6 is > another "we have no SPL space!" platform that isn't using MMC_TINY, for > example. See above, I'll deflect this question to the expert(s). -- Best regards, Marek Vasut _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
