sunxi: Single u-boot binary for Allwinner A10/A13/A20 devices
Get series with b4
b4 am [email protected]Versions newest first
- v1 Latest1 of 2 patches 0 repliesNew
1 of 2 patches is in this archive. The cover letter announces 2.
Patches in v1 No applies recorded yet
| # | Subject and files | Size | Replies | Applied |
|---|---|---|---|---|
| 1/2 | sunxi: Replace CONFIG_SUN[457]I ifdefs with SOC_IS_SUN[457]I() calls | +0 | 0 replies |
Reviews trailers per patch
No Reviewed-by, Acked-by or Tested-by trailers for v1 yet.
Cover letter [U-Boot] [PATCH 0/2] sunxi: Single u-boot binary for Allwinner A10/A13/A20 devices
Hi Siarhei,
Quoted 46 lines · Siarhei Siamashka
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.)
Quoted 3 lines
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
Quoted 36 lines
The patches depend on
https://patchwork.ozlabs.org/patch/375971/ and http://lists.denx.de/pipermail/u-boot/2014-August/185200.htmlSiarhei 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 supportarch/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