Hi,
On Saturday, 5 September 2015, Siarhei Siamashka siarhei.siamashka@gmail.com wrote:
On Sat, 5 Sep 2015 15:52:03 +0200 Hans de Goede hdegoede@redhat.com wrote:
Hi,
On 05-09-15 15:45, Simon Glass wrote:
Add a README with a brief guide to porting serial drivers over to use driver model.
Add a timeline also.
Signed-off-by: Simon Glass sjg@chromium.org
I assume that the purpose of the timeline is to retire the non dm serial drivers ?
What about SPL use ?
I do not see the SPL for sunxi move to dm / devicetree anytime soon, there simply does not seem to be enough space.
Based on my experience, introducing code bloat is always easier than removing it. As long as the dm /devicetree remains optional for the SPL, it is safer to stay away from it for sunxi. And prioritize the use of precious SRAM space for user visible features.
I think it will be optional for the forseeable future. But I think it would be worth exploring for sunxi to see what the cost is.
I think device tree is a great unifier for SoCs that have the space and don't impose some arbitrary limit on the amount of code the boot ROM will load.
An interesting avenue that I have not explored is static binding of devices. If device tree is not used a lot of the code size comes from device_bind() and device_probe(). The first one could perhaps be dropped by using some sort of static table. The second one is less clear, but if we only have serial then perhaps some efforts can be made to reduce space.
With the new nand SPL support we have already been hitting the 24k limit without bringing in dm + a dtb + a dtb parser ...
What is the exact limit for the SPL size when it is loaded by the BROM? The comment in http://git.denx.de/?p=u-boot.git;a=blob;f=tools/mksunxiboot.c;h=3361251c8e7f... says that the limit is 0x7600, which means 30208 bytes. I guess, somebody needs to do some experiments on different Allwinner SoC variants and try to confirm this information.
Regarding gaining more space, there is still a decades old trick we can take advantage of: https://en.wikipedia.org/wiki/Executable_compression
When using GCC 4.8.4, I'm getting 22756 bytes size for the Cubieboard u-boot-spl.bin file. Running "lzop -9 u-boot-spl.bin" results in 17876 bytes for the compressed file. Running "uclpack --10 u-boot-spl.bin u-boot-spl.bin.ucl" results in 16652 bytes for the compressed file. Both LZO and UCL have very simple small decompressors.
Basically, using compression can provide us with something like 4 or 5 extra kilobytes. And we are not limited with just 32K for the uncompressed SPL size. For example, even Allwinner A13 has the total size of SRAM equal to 48K. A small part of it needs to be reserved for the USB (FEL) boot mode, but I think that maybe up to something like ~38K of contiguous SRAM space can be used for the uncompressed SPL (code+data+stack). The other SoC variants are a bit tricky, for example A31 does not have 38K of contiguous space starting at the address 0x0 in SRAM. So these 38K would have to be uncompressed to some other location and CONFIG_SPL_TEXT_BASE would need to be adjusted. And if we want the same SPL binary to be in principle bootable on all SoC variants (including A80), then relocations support can be added too (fixup them immediately after the decompression). Though additionally storing relocations can waste some space.
It's all about trade-offs. Compression tricks can provide extra space at the cost of increasing complexity. The dm /devicetree wastes space for the sake of architectural aesthetics and codebase unification.
I'm not a huge fan of the additional complexity from compression. As it happened this was implemented in the Chrome OS U-Boot to improve boot time, but the effect was pretty small. But perhaps as an option to enable to get more features, it could be useful.
Which reminds me I still need to look at your version of the patch for only using malloc_simple.c in the SPL and not build in dl_malloc.c, that saves about 1k which we could use really well. I still have this on my todo list.
The current printf related machinery is a little bit heavyweight too.
Yes a minimal printf() would be nice - perhaps just strings, hex and maybe decimal.
Regards, Simon