[U-Boot] [PATCH 1/1] board: arm: Add support for Broadcom BCM7445D0

Thomas Fitzsimmons fitzsim at fitzsim.org
Thu May 24 00:47:23 UTC 2018


Tom Rini <trini at konsulko.com> writes:

> On Sun, May 06, 2018 at 07:09:22AM -0400, Thomas Fitzsimmons wrote:
>
>> Add support for loading U-Boot on the Broadcom 7445D0 SoC.  This port
>> assumes Broadcom's BOLT bootloader is acting as the second stage
>> bootloader, and U-Boot is acting as the third stage bootloader, loaded
>> as an ELF program by BOLT.
>> 
>> Signed-off-by: Thomas Fitzsimmons <fitzsim at fitzsim.org>
>> Cc: Stefan Roese <sr at denx.de>
> [snip]
>> diff --git a/arch/arm/lib/crt0.S b/arch/arm/lib/crt0.S
>> index fa81317..f1a6f35 100644
>> --- a/arch/arm/lib/crt0.S
>> +++ b/arch/arm/lib/crt0.S
>> @@ -94,6 +94,7 @@ ENTRY(_main)
>>   * 'here' but relocated.
>>   */
>>  
>> +#if !defined(CONFIG_OF_PRIOR_STAGE)
>>  	ldr	r0, [r9, #GD_START_ADDR_SP]	/* sp = gd->start_addr_sp */
>>  	bic	r0, r0, #7	/* 8-byte alignment for ABI compliance */
>>  	mov	sp, r0
>> @@ -108,6 +109,7 @@ ENTRY(_main)
>>  #endif
>>  	ldr	r0, [r9, #GD_RELOCADDR]		/* r0 = gd->relocaddr */
>>  	b	relocate_code
>> +#endif
>>  here:
>>  /*
>>   * now relocate vectors
>
> Can you explain this bit a good bit more?

When BOLT loads U-Boot as an ELF program, this relocation code hangs --
I haven't found out why yet -- but if I skip the relocation, U-Boot runs
successfully.  I figured out a different approach to preventing the
relocation, one that only requires logic in an SoC-specific file, so v2
of the patch will not have any crt0.S changes.

>> +config BCHP_BSPI_MAST_N_BOOT_CTRL
>> +	hex ""
>> +	default 0x003e3208
>
> Doing hex "" seems wrong.  What are you doing here exactly?

I've reorganized all these into more appropriate locations, and
documented all the remaining Kconfig items, which you'll see in the v2
patch I'll post shortly.

>> diff --git a/common/fdt_support.c b/common/fdt_support.c
>> index 66a313e..f07dfe3 100644
>> --- a/common/fdt_support.c
>> +++ b/common/fdt_support.c
>> @@ -242,11 +242,13 @@ int fdt_initrd(void *fdt, ulong initrd_start, ulong initrd_end)
>>  		}
>>  	}
>>  
>> +#if !defined(CONFIG_BCMSTB_ACCOMMODATE_STBLINUX)
>>  	err = fdt_add_mem_rsv(fdt, initrd_start, initrd_end - initrd_start);
>>  	if (err < 0) {
>>  		printf("fdt_initrd: %s\n", fdt_strerror(err));
>>  		return err;
>>  	}
>> +#endif
>
> Why do we need this?

The background is that stblinux is designed to use some physical memory
for Linux itself, and leave the rest of physical memory for direct use
by video decode blocks in the SoC.

Basically, without making accommodations for it in U-Boot, stblinux will
allocate less memory for use by the video decode blocks than is actually
available, even if it could safely allocate more.

In v2 of the patch, I've documented a different approach to loading FIT
images (one that keeps the RFS and DTB in-place), which eliminates the
need for this configuration macro.

>> +#ifdef DEBUG
>> +static int debug_tx_rx;
>> +#define D(fmt, args...) debug_cond(debug_tx_rx, fmt, ##args)
>> +#else
>> +#define D(fmt, args...)
>> +#endif
>
> We have dbg() etc, please use.  Thanks!

OK, done in v2 of the patch.

Thanks for reviewing,
Thomas


More information about the U-Boot mailing list