public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Thomas Fitzsimmons <fitzsim@fitzsim.org>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH 1/1] board: arm: Add support for Broadcom BCM7445D0
Date: Wed, 23 May 2018 20:47:23 -0400	[thread overview]
Message-ID: <m336yh282s.fsf@fitzsim.org> (raw)
In-Reply-To: <20180507234818.GB12235@bill-the-cat.ec.rr.com> (Tom Rini's message of "Mon, 7 May 2018 19:48:18 -0400")

Tom Rini <trini@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@fitzsim.org>
>> Cc: Stefan Roese <sr@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

  reply	other threads:[~2018-05-24  0:47 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-05-06 11:09 [U-Boot] [PATCH 0/1] board: arm: Add support for Broadcom BCM7445D0 Thomas Fitzsimmons
2018-05-06 11:09 ` [U-Boot] [PATCH 1/1] " Thomas Fitzsimmons
2018-05-07 23:48   ` Tom Rini
2018-05-24  0:47     ` Thomas Fitzsimmons [this message]
2018-05-08 17:44   ` Florian Fainelli
2018-05-10 13:04     ` Thomas Fitzsimmons
2018-05-10 17:43       ` Florian Fainelli
2018-06-06 20:39         ` Thomas Fitzsimmons
2018-06-06 22:06           ` Florian Fainelli
2018-05-24  1:24 ` [U-Boot] [PATCH v2 0/1] board: arm: Add support for Broadcom BCM7445 Thomas Fitzsimmons
2018-05-24  1:24   ` [U-Boot] [PATCH v2 1/1] " Thomas Fitzsimmons
2018-06-06 11:16     ` [U-Boot] [U-Boot, v2, " Tom Rini
2018-06-06 19:32       ` Thomas Fitzsimmons
2018-06-06 18:35   ` [U-Boot] [PATCH v3 0/1] " Thomas Fitzsimmons
2018-06-06 18:35     ` [U-Boot] [PATCH v3 1/1] " Thomas Fitzsimmons
2018-06-07 16:54       ` Florian Fainelli
2018-06-08 22:25         ` Thomas Fitzsimmons
2018-06-08 21:59     ` [U-Boot] [PATCH v4 0/1] " Thomas Fitzsimmons
2018-06-08 21:59       ` [U-Boot] [PATCH v4 1/1] " Thomas Fitzsimmons
2018-07-11 12:42         ` [U-Boot] [U-Boot, v4, " Tom Rini
2019-08-26 15:54         ` [U-Boot] [PATCH v4 " Bin Meng
2019-08-27 22:31           ` Thomas Fitzsimmons
2019-08-28 10:19             ` Bin Meng
2019-08-28 17:24               ` Thomas Fitzsimmons
2019-08-29 15:24                 ` Bin Meng
2019-09-05 12:10                   ` Bin Meng
2019-09-17  5:48                     ` Simon Glass
2019-09-06 11:51                   ` [U-Boot] [PATCH 0/2] dm: CONFIG_OF_PRIOR_STAGE request number fixes Thomas Fitzsimmons
2019-09-06 11:51                     ` [U-Boot] [PATCH 1/2] dm: device: Request next sequence number Thomas Fitzsimmons
2019-09-06 13:24                       ` Bin Meng
2019-09-14 13:41                         ` Thomas Fitzsimmons
2019-09-27  1:49                           ` Simon Glass
2019-09-27 23:28                             ` sjg at google.com
2019-09-06 11:51                     ` [U-Boot] [PATCH 2/2] dm: spi: Do not assume first SPI bus Thomas Fitzsimmons
2019-09-27  1:49                       ` Simon Glass
2019-09-27 23:28                         ` sjg at google.com
2019-08-26 15:50   ` [U-Boot] [PATCH v2 0/1] board: arm: Add support for Broadcom BCM7445 Bin Meng

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=m336yh282s.fsf@fitzsim.org \
    --to=fitzsim@fitzsim.org \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox