[U-Boot] [PATCH v2 0/8] arm: Tidy up early init

Simon Glass
2015-09-02T02:48:52Z

Hi Mchal,

On 1 September 2015 at 03:10, Michal Simek <monstr@monstr.eu> wrote:
> Hi Simon,
>
> On 08/28/2015 10:50 PM, Simon Glass wrote:
>> This series collects the previous RFT patches I sent out.
>>
>> https://patchwork.ozlabs.org/patch/508167/
>> https://patchwork.ozlabs.org/patch/508168/
>>
>> It turns out that I originally sent a version of these in April:
>>
>> https://patchwork.ozlabs.org/patch/461687/
>> https://patchwork.ozlabs.org/patch/461690/
>>
>> so this series mirrors that one and includes the Zynq patches from that
>> series.
>>
>> I hope these can sneak in to this release so that I don't forget them
>> again!
>>
>> I have tested this on a few ARM platforms: Zynq Zybo, Beaglebone Black,
>> pcduino3 (sunxi), Jetson-TK1 (tegra).
>>
>> Changes in v2:
>> - Put this into common/init/ and just Makefiles accordingly
>> - Add comments as to why this is needed, deal with arch-specific memset()
>>
>> Simon Glass (8):
>> Move board_init_f_mem() into a common location
>> board_init_f_mem(): Don't require memset()
>> board_init_f_mem(): Don't create an unused early malloc() area
>> arm: Switch aarch64 to using generic global_data setup
>> arm: Switch 32-bit ARM to using generic global_data setup
>> microblaze: Add a TODO to call board_init_f_mem()
>> zynq: Move SPL console init out of board_init_f()
>> Revert "ARM: zynq: disable CONFIG_SYS_MALLOC_F to fix MMC boot"
>>
>> arch/arm/lib/crt0.S | 28 +++---------------
>> arch/arm/lib/crt0_64.S | 15 ++--------
>> arch/arm/mach-zynq/spl.c | 2 +-
>> arch/microblaze/cpu/start.S | 2 ++
>> common/Makefile | 1 +
>> common/board_f.c | 29 ------------------
>> common/init/Makefile | 7 +++++
>> common/init/board_init.c | 60 ++++++++++++++++++++++++++++++++++++++
>> configs/zynq_microzed_defconfig | 1 -
>> configs/zynq_zc702_defconfig | 1 -
>> configs/zynq_zc706_defconfig | 1 -
>> configs/zynq_zc70x_defconfig | 1 -
>> configs/zynq_zc770_xm010_defconfig | 1 -
>> configs/zynq_zc770_xm011_defconfig | 1 -
>> configs/zynq_zc770_xm012_defconfig | 1 -
>> configs/zynq_zc770_xm013_defconfig | 1 -
>> configs/zynq_zed_defconfig | 1 -
>> configs/zynq_zybo_defconfig | 1 -
>> scripts/Makefile.spl | 1 +
>> 19 files changed, 79 insertions(+), 76 deletions(-)
>> create mode 100644 common/init/Makefile
>> create mode 100644 common/init/board_init.c
>>
>
> I am getting compilation warning about USE_MEMCPY which should be
> resolved too.
>
>
> [u-boot]$ ./tools/buildman/buildman -b xnext/serial2 zynq_zc702 -sSed
> boards.cfg is up to date. Nothing to do.
> Summary of 9 commits for 1 boards (1 thread, 8 jobs per thread)
> 01: Merge branch 'master' of http://git.denx.de/u-boot-sunxi
> 02: Move board_init_f_mem() into a common location
> 03: board_init_f_mem(): Don't require memset()
> arm: + zynq_zc702
> + #define USE_MEMCPY
> + ^
> +In file included from ../include/common.h:1064:0,
> + from ../common/init/board_init.c:10:
> +../include/malloc.h:355:0: note: this is the location of the previous
> definition
> + #define USE_MEMCPY 1
> w+../common/init/board_init.c:21:0: warning: "USE_MEMCPY" redefined
> [enabled by default]
> 04: board_init_f_mem(): Don't create an unused early malloc() area
> 05: arm: Switch aarch64 to using generic global_data setup
> 06: arm: Switch 32-bit ARM to using generic global_data setup
> arm: (for 1/1 boards) all +28.0 spl/u-boot-spl:all +28.0
> spl/u-boot-spl:text +28.0 text +28.0
> zynq_zc702 : all +28 spl/u-boot-spl:all +28
> spl/u-boot-spl:text +28 text +28
> 07: microblaze: Add a TODO to call board_init_f_mem()
> 08: zynq: Move SPL console init out of board_init_f()
> arm: (for 1/1 boards) spl/u-boot-spl:all +8.0
> spl/u-boot-spl:text +8.0
> zynq_zc702 : spl/u-boot-spl:all +8 spl/u-boot-spl:text +8
> 09: Revert "ARM: zynq: disable CONFIG_SYS_MALLOC_F to fix MMC boot"
> arm: (for 1/1 boards) all +257.0 rodata +37.0
> spl/u-boot-spl:all +180.0 spl/u-boot-spl:text +180.0 text +220.0
> zynq_zc702 : all +257 rodata +37 spl/u-boot-spl:all
> +180 spl/u-boot-spl:text +180 text +220

Yes, unfortunately I found that later and also I found a conflict with
the malloc change also:

http://patchwork.ozlabs.org/patch/512147/

Once we figure out zynqmp I can resend it.

Regards,
Simon