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 sjg@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.