RFC: dm: Add proposed timeline and guide for porting serial drivers
PATCH 1/1 RFC: dm: Add proposed timeline and guide for porting serial drivers
Add a README with a brief guide to porting serial drivers over to use driver model.
Add a timeline also.
---
I intend to cc the final patch to all U-Boot maintainers using something like this:
(for f in $(find . -name MAINTAINERS); do grep ^M: $f; done) | \
awk '{$1=""; print "Series-cc:" $0}' |sort | uniqThis is about 229 email address, of which 217 seem to be different people.
doc/driver-model/serial-howto.txt | 58 +++++++++++++++++++++++++++++++++++++++ 1 file changed, 58 insertions(+) create mode 100644 doc/driver-model/serial-howto.txt
doc/driver-model/serial-howto.txt new file +58 -0
@@ -0,0 +1,58 @@ +How to port a serial driver to driver model +=========================================== + +About 16 of 33 serial drivers have been converted as at September 2015. It +is time for maintainers to start converting over the remaining serial drivers: + + altera_jtag_uart.c + altera_uart.c + arm_dcc.c + lpc32xx_hsuart.c + mcfuart.c + mxs_auart.c + opencores_yanu.c + serial_bfin.c + serial_imx.c + serial_lpuart.c + serial_max3100.c + serial_pxa.c + serial_s3c24x0.c + serial_sa1100.c + serial_stm32.c + serial_xuartlite.c + usbtty.c + +You should complete this by Christmas 2015. + +Here is a suggested approach for converting your serial driver over to driver +model. Please feel free to update this file with your ideas and suggestions. + +- #ifdef out all your own serial driver code (#ifndef CONFIG_DM_SERIAL) +- Define CONFIG_DM_SERIAL for your board, vendor or architecture +- If the board does not already use driver model, you need CONFIG_DM also +- Your board should then build, but will not boot since there will be no serial + driver +- Add the U_BOOT_DRIVER piece at the end (e.g. copy serial_s5p.c for example) +- Add a private struct for the driver data - avoid using static variables +- Implement each of the driver methods, perhaps by calling your old methods +- You may need to adjust the function parameters so that the old and new + implementations can share most of the existing code +- If you convert all existing users of the driver, remove the pre-driver-model + code + +In terms of patches a conversion series typically has these patches: +- clean up / prepare the driver for conversion +- add driver model code +- convert at least one existing board to use driver model serial +- (if no boards remain that don't use driver model) remove the old code + +This may be a good time to move your board to use device tree also. Mostly +this involves these steps: + +- define CONFIG_OF_CONTROL and CONFIG_OF_SEPARATE +- add your device tree files to arch/<arch>/dts +- update the Makefile there +- Add stdout-path to your /chosen device tree node if it is not already there +- build and get u-boot-dtb.bin so you can test it +- Your drivers can now use device tree +- For device tree in SPL, define CONFIG_SPL_OF_CONTROL
Signature · 1 line
2.5.0.457.gab17608
PATCH 1/1 RFC: dm: Add proposed timeline and guide for porting serial drivers
Hi,
Quoted 6 lines · Simon Glass
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 <[email protected]>
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.
With the new nand SPL support we have already been hitting the 24k limit without bringing in dm + a dtb + a dtb parser ...
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.
Regards,
Hans
Quoted 78 lines
---
I intend to cc the final patch to all U-Boot maintainers using something like this:(for f in $(find . -name MAINTAINERS); do grep ^M: $f; done) | \ awk '{$1=""; print "Series-cc:" $0}' |sort | uniqThis is about 229 email address, of which 217 seem to be different people.
doc/driver-model/serial-howto.txt | 58 +++++++++++++++++++++++++++++++++++++++ 1 file changed, 58 insertions(+)create mode 100644
doc/driver-model/serial-howto.txtdoc/driver-model/serial-howto.txt new file +58
-0@@ -0,0 +1,58 @@ +How to port a serial driver to driver model +=========================================== + +About 16 of 33 serial drivers have been converted as at September 2015. It +is time for maintainers to start converting over the remaining serial drivers: + + altera_jtag_uart.c + altera_uart.c + arm_dcc.c + lpc32xx_hsuart.c + mcfuart.c + mxs_auart.c + opencores_yanu.c + serial_bfin.c + serial_imx.c + serial_lpuart.c + serial_max3100.c + serial_pxa.c + serial_s3c24x0.c + serial_sa1100.c + serial_stm32.c + serial_xuartlite.c + usbtty.c + +You should complete this by Christmas 2015. + +Here is a suggested approach for converting your serial driver over to driver +model. Please feel free to update this file with your ideas and suggestions. + +- #ifdef out all your own serial driver code (#ifndef CONFIG_DM_SERIAL) +- Define CONFIG_DM_SERIAL for your board, vendor or architecture +- If the board does not already use driver model, you need CONFIG_DM also +- Your board should then build, but will not boot since there will be no serial + driver +- Add the U_BOOT_DRIVER piece at the end (e.g. copy serial_s5p.c for example) +- Add a private struct for the driver data - avoid using static variables +- Implement each of the driver methods, perhaps by calling your old methods +- You may need to adjust the function parameters so that the old and new + implementations can share most of the existing code +- If you convert all existing users of the driver, remove the pre-driver-model + code + +In terms of patches a conversion series typically has these patches: +- clean up / prepare the driver for conversion +- add driver model code +- convert at least one existing board to use driver model serial +- (if no boards remain that don't use driver model) remove the old code + +This may be a good time to move your board to use device tree also. Mostly +this involves these steps: + +- define CONFIG_OF_CONTROL and CONFIG_OF_SEPARATE +- add your device tree files to arch/<arch>/dts +- update the Makefile there +- Add stdout-path to your /chosen device tree node if it is not already there +- build and get u-boot-dtb.bin so you can test it +- Your drivers can now use device tree +- For device tree in SPL, define CONFIG_SPL_OF_CONTROL
PATCH 1/1 RFC: dm: Add proposed timeline and guide for porting serial drivers
Hi Hans,
Quoted 12 lines · Hans de Goede
Hi,
Quoted 7 lines · Simon Glass
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 <[email protected]>
Quoted 7 lines
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.
Yes I think device tree in SPL will only work for newer SoCs with enough SRAM. With Rockchip the device tree added about 3KB of code. If you are already hitting the limit then it isn't going to help!
Still, there is the option of adding platform data for the SPL case, and still using driver model. That should work for most (but not all) boards.
Quoted 8 lines
With the new nand SPL support we have already been hitting the 24k limit without bringing in dm + a dtb + a dtb parser ...
Which reminds me I still need to look at your version of the patch for only using
malloc_simple.cin the SPL and not build indl_malloc.c, that saves about 1k which we could use really well. I still have this on my todo list.
Yes - the down-side is when you want to use SDRAM for your malloc() region in SPL's board_init_r(). Then it's nice to have the full malloc().
Quoted 6 lines
Regards,
Hans
Regards,
Simon
[snip]
PATCH 1/1 RFC: dm: Add proposed timeline and guide for porting serial drivers
In reply to Hans de GoedeQuoted 10 lines · On Sat, 5 Sep 2015 15:52:03 +0200 Hans de Goede <[email protected]> wrote:
Hi,
Quoted 6 lines · Simon Glass
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 <[email protected]>
Quoted 7 lines
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.
Quoted 2 lines
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=3361251c8e7fffcb4ccbc3e29eb5e2e956608b0c;hb=HEAD#l66
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.
Quoted 4 lines
Which reminds me I still need to look at your version of the patch for only using
malloc_simple.cin the SPL and not build indl_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.
Signature · 2 lines
Best regards, Siarhei Siamashka
PATCH 1/1 RFC: dm: Add proposed timeline and guide for porting serial drivers
Hi,
Quoted 19 lines · Siarhei Siamashka
Quoted 15 lines · On Sat, 5 Sep 2015 15:52:03 +0200 Hans de Goede <[email protected]> wrote:
Hi,
Quoted 6 lines · Simon Glass
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 <[email protected]>I assume that the purpose of the timeline is to retire the non dm serial drivers ?
What about SPL use ?
Quoted 7 lines
Quoted 2 lines
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.
Quoted 39 lines
Quoted 4 lines
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=3361251c8e7fffcb4ccbc3e29eb5e2e956608b0c;hb=HEAD#l66
says that the limit is0x7600, 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_compressionWhen 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
0x0in SRAM. So these 38K would have to be uncompressed to some other location andCONFIG_SPL_TEXT_BASEwould 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.
Quoted 4 lines
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.
Quoted 9 lines
Quoted 6 lines
Which reminds me I still need to look at your version of the patch for only using
malloc_simple.cin the SPL and not build indl_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
PATCH 1/1 RFC: dm: Add proposed timeline and guide for porting serial drivers
Hi,
Quoted 18 lines · Simon Glass
Hi,
Quoted 14 lines · Siarhei Siamashka
Quoted 10 lines · On Sat, 5 Sep 2015 15:52:03 +0200 Hans de Goede <[email protected]> wrote:
Hi,
Quoted 6 lines · Simon Glass
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 <[email protected]>
[snip]
Are there any more comments on this patch? Does December seem like a reasonable deadline to convert serial drivers over?
Regards,
Simon
PATCH 1/1 RFC: dm: Add proposed timeline and guide for porting serial drivers
Hi,
Quoted 19 lines · Simon Glass
Hi,
Quoted 16 lines · Simon Glass
Hi,
Quoted 12 lines · Siarhei Siamashka
Quoted 8 lines · On Sat, 5 Sep 2015 15:52:03 +0200 Hans de Goede <[email protected]> wrote:
Hi,
Quoted 5 lines · Simon Glass
Add a README with a brief guide to porting serial drivers over to use driver model.
Add a timeline also.
Quoted 7 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 1 line
Signed-off-by Simon Glass <[email protected]>[snip]
Are there any more comments on this patch? Does December seem like a reasonable deadline to convert serial drivers over?
December seems fine, with the caveat that we need to keep non a non dm version around for SPL. That or maybe look into doing none dt instantiation of dm serial ports for the SPL.
Regards,
Hans