[U-Boot] [PATCH 0/2] sunxi: Single u-boot binary for Allwinner A10/A13/A20 devices

[Hans de Goede]

Hi Siarhei,

On 08/03/2014 05:26 AM, Siarhei Siamashka wrote:
> This patchset introduces the initial rudimentary support for having
> just a single u-boot binary for certain subsets of Allwinner A10/A13/A20
> devices.
> 
> == Example 1: All Allwinner A10/A13/A20 devices
> 
> We are restricted to only a very basic common subset of peripherals
> (anything that is supported by BROM should be fine). This provides
> a possibility to at least boot from the SD card and use some slow
> fail-safe DRAM settings. UART, USB and HDMI settings are also
> relatively easy to detect at runtime. This provides a possibility
> to implement universal installers, which would somehow boot the
> system and allow the user to change u-boot and dtb to something
> more suitable for his hardware.
> 
> Advantages: just works everywhere
> Disadvantages: poor performance and very limited set of supported peripherals
> 
> == Example 2: Sibling A10/A20 boards (such as Cubieboard1/Cubieboard2)
> 
> Some development boards are using exactly the same PCB for one variant
> with Allwinner A10 SoC and another variant with Allwinner A20 SoC.
> Instead of having two u-boot configurations and two incompatible
> u-boot binaries, it is possible to re-use the same u-boot binary
> for both of these boards.
> 
> Advantages: no performance or feature sacrifices
> Disadvantages: only two boards are supported by a single u-boot binary
>                (not a big overall improvement)
> 
> == Example 3: Univarsal u-boot binary and the settings in non-volatile memory
> 
> Most of Allwinner devices have NAND. Booting from NAND is supported by
> BROM, so there is no reason why u-boot SPL can't read it too. Some
> reserved area in NAND can store the whole DTB file, or even just a
> DTB name (a key for lookup somewhere else). Additionally, DRAM timings
> and unit specific tuning may be stored there too. This might be implemented
> in a (not so) distant future.
> 
> Advantages: no performance of feature sacrifices, support for a large
>             subset of devices
> Disadvantages: somebody has to prepare the correct information in NAND
>                (it could be the device vendor, or maybe some reliability
>                testing/validation tool, etc.)
> 
> 
> Anyway, this is just the beginning. And we have to start with something
> simple. These two patches just provide an option for a single universal
> u-boot binary with just UART and MMC support (essentially, the example 1).

First of all many thanks for these patches.

I like the general principle, but I think we should go further then you do
and instead of introducing CONFIG_SUN4I_SUN5I_SUN7I and keeping
CONFIG_SUN4I and friends, we should merge all of them into a single
CONFIG_SUNXI. I see no reason why the board specific configs could not
still use the generic code paths.

Yes this means that a tiny amount of code which could otherwise be compiled
out because we know we will be on e.g. sun7i will not be compiled out, but it
is such a little amount of code that I don't think it is worth the hassle of
having 4 different CONFIG options, so I suggest that in the first patch
instead of uppercase names you use lower case ones to indicate that this
are (will be) normal functions, and then in the second patch instead
of adding CONFIG_SUN4I_SUN5I_SUN7I drop CONFIG_SUN4I SUN5I and SUN7I
and simply always call the functions checking the soc type even when build
for a specific board. This should lead to quite a nice cleanup (and potential
future cleanups).

We will still need separate board configs for optional dram settings, enabling
of optional pheriphials, etc. But we should be able keep the core code between
a generic board and a board specific build identical, rather then adding
more ifdefs.

This pretty much also summarizes my comments on the second patch.

I've some more specific comments on the first patch so I'll reply to that
one separately.

Regards,

Hans







> 
> The patches depend on
>     https://patchwork.ozlabs.org/patch/375971/
> and
>     http://lists.denx.de/pipermail/u-boot/2014-August/185200.html
> 
> 
> Siarhei Siamashka (2):
>   sunxi: Replace CONFIG_SUN[457]I ifdefs with SOC_IS_SUN[457]I() calls
>   sunxi: Universal Allwinner A10/A13/A20 u-boot binary support
> 
>  arch/arm/Kconfig                                |   3 +
>  arch/arm/cpu/armv7/sunxi/Makefile               |   2 +
>  arch/arm/cpu/armv7/sunxi/board.c                |  98 +++++++++++---
>  arch/arm/cpu/armv7/sunxi/clock_sun4i.c          |  10 +-
>  arch/arm/cpu/armv7/sunxi/cpu_info.c             |  37 ++---
>  arch/arm/cpu/armv7/sunxi/dram.c                 | 171 ++++++++++++------------
>  arch/arm/include/asm/arch-sunxi/sys_proto.h     |   5 +
>  board/sunxi/Kconfig                             |  20 +++
>  board/sunxi/MAINTAINERS                         |   7 +
>  board/sunxi/Makefile                            |   1 +
>  board/sunxi/board.c                             |   1 +
>  board/sunxi/dram_sunxi_ddr3_failsafe.c          |  28 ++++
>  configs/sunxi-generic-a10-a13-a20_FEL_defconfig |   4 +
>  configs/sunxi-generic-a10-a13-a20_defconfig     |   4 +
>  include/configs/sun4i.h                         |   2 +
>  include/configs/sun4i_sun5i_sun7i.h             |  38 ++++++
>  include/configs/sun5i.h                         |   2 +
>  include/configs/sun7i.h                         |   2 +
>  include/configs/sunxi-common.h                  |  12 ++
>  19 files changed, 322 insertions(+), 125 deletions(-)
>  create mode 100644 board/sunxi/dram_sunxi_ddr3_failsafe.c
>  create mode 100644 configs/sunxi-generic-a10-a13-a20_FEL_defconfig
>  create mode 100644 configs/sunxi-generic-a10-a13-a20_defconfig
>  create mode 100644 include/configs/sun4i_sun5i_sun7i.h
>