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

2018-06-06 Thread Florian Fainelli 
On 06/06/2018 01:39 PM, Thomas Fitzsimmons wrote:
> Florian Fainelli  writes:
> 
>> On 05/10/2018 06:04 AM, Thomas Fitzsimmons wrote:
>>> Florian Fainelli  writes:
>>>
 On 05/06/2018 04:09 AM, Thomas Fitzsimmons wrote:
> 
> [...]
> 
> +
> +config BCMSTB_ACCOMMODATE_STBLINUX
> + bool ""
> + default y
> + help
> +   This prevents U-Boot from adding memory reservations for the
> +  lengths of initramfs and DTB.  Without skipping these,
> +  stblinux's "contiguous memory allocator" (CMA) Linux driver
> +  (cma_driver) will allocate memory ranges smaller than what
> +  are actually available, because it only checks reservation
> +  sizes.  It doesn't check if the reserved range overlaps the
> +  range it allocates.  stblinux also tries to move the DTB to
> +  a lower memory location early in the Linux boot.  If the FIT
> +  image specifies a load address for the initramfs then
> +  sometimes the DTB is moved into the range where the
> +  initramfs image is loaded.  Defining this will mean that
> +  FIT-provided initramfs load addresses are ignored.

 What STB Linux kernel did you observe this with? I am afraid this is
 still true about the ranges vs. allocation even in newer kernels, but
 that is kind of intented to keep the logic KISS (because it's already
 too complicated IMHO).
>>>
>>> I investigated the allocation discrepancy and wrote the workaround while
>>> we were still using stblinux-3.14.  Since then we've updated to
>>> stblinux-4.1 and I've left the workaround enabled, but I haven't
>>> investigated its interactions with the newer bmem mechanism.  I should
>>> probably revisit this though, with stblinux-4.1 and stblinux-4.9, just
>>> to make sure this macro is still useful.
>>
>> Sounds good, let me know if there is something that does not seem quite
>> right, we could fix it.
> 
> [...]
> 
> In the v3 patch, I keep the FIT's RFS and DTB in-place.  This approach
> eliminates the bmem/cma allocation discrepancies.  I compared bmem/cma
> dmesg output for stblinux 3.14, 4.1 and 4.9, zImage and ITB builds, on
> my eval board, and they're all the same for the same kernel version.
> The only thing I noticed is that in 3.14 and 4.1 (zImage and ITB), the
> first bmem region is:
> 
>768 MiB at 0x1000
> 
> whereas in 4.9 (zImage and ITB), it is:
> 
>760 MiB at 0x1080
> 
> This is booting with no kernel command line arguments, so I guess some
> default may have changed between stblinux 4.1 and 4.9?

This upstream commit is responsible for what you see:
6ff0966052c46efb53980b8a1add2e7b49c9f560 ("ARM: 8432/1: move VMALLOC_END
from 0xff00 to 0xff80") we've backported that change to our 3.14
and 4.1 kernels since then.
-- 
Florian
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

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

2018-06-06 Thread Thomas Fitzsimmons 
Florian Fainelli  writes:

> On 05/10/2018 06:04 AM, Thomas Fitzsimmons wrote:
>> Florian Fainelli  writes:
>> 
>>> On 05/06/2018 04:09 AM, Thomas Fitzsimmons wrote:

[...]

 +
 +config BCMSTB_ACCOMMODATE_STBLINUX
 +  bool ""
 +  default y
 +  help
 +This prevents U-Boot from adding memory reservations for the
 +  lengths of initramfs and DTB.  Without skipping these,
 +  stblinux's "contiguous memory allocator" (CMA) Linux driver
 +  (cma_driver) will allocate memory ranges smaller than what
 +  are actually available, because it only checks reservation
 +  sizes.  It doesn't check if the reserved range overlaps the
 +  range it allocates.  stblinux also tries to move the DTB to
 +  a lower memory location early in the Linux boot.  If the FIT
 +  image specifies a load address for the initramfs then
 +  sometimes the DTB is moved into the range where the
 +  initramfs image is loaded.  Defining this will mean that
 +  FIT-provided initramfs load addresses are ignored.
>>>
>>> What STB Linux kernel did you observe this with? I am afraid this is
>>> still true about the ranges vs. allocation even in newer kernels, but
>>> that is kind of intented to keep the logic KISS (because it's already
>>> too complicated IMHO).
>> 
>> I investigated the allocation discrepancy and wrote the workaround while
>> we were still using stblinux-3.14.  Since then we've updated to
>> stblinux-4.1 and I've left the workaround enabled, but I haven't
>> investigated its interactions with the newer bmem mechanism.  I should
>> probably revisit this though, with stblinux-4.1 and stblinux-4.9, just
>> to make sure this macro is still useful.
>
> Sounds good, let me know if there is something that does not seem quite
> right, we could fix it.

[...]

In the v3 patch, I keep the FIT's RFS and DTB in-place.  This approach
eliminates the bmem/cma allocation discrepancies.  I compared bmem/cma
dmesg output for stblinux 3.14, 4.1 and 4.9, zImage and ITB builds, on
my eval board, and they're all the same for the same kernel version.
The only thing I noticed is that in 3.14 and 4.1 (zImage and ITB), the
first bmem region is:

   768 MiB at 0x1000

whereas in 4.9 (zImage and ITB), it is:

   760 MiB at 0x1080

This is booting with no kernel command line arguments, so I guess some
default may have changed between stblinux 4.1 and 4.9?

Thomas
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

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

2018-05-23 Thread Thomas Fitzsimmons 
Tom Rini  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 
>> Cc: Stefan Roese 
> [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
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

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

2018-05-10 Thread Florian Fainelli 
On 05/10/2018 06:04 AM, Thomas Fitzsimmons wrote:
> Florian Fainelli  writes:
> 
>> On 05/06/2018 04:09 AM, 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 
>>> Cc: Stefan Roese 
>>
>>>
>>> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
>>> index 9bd70f4..b2df30a 100644
>>> --- a/arch/arm/Kconfig
>>> +++ b/arch/arm/Kconfig
>>> @@ -498,6 +498,17 @@ config TARGET_VEXPRESS_CA15_TC2
>>> select CPU_V7_HAS_VIRT
>>> select PL011_SERIAL
>>>  
>>> +config TARGET_BCM7445D0
>>> +   bool "Broadcom 7445D0 TSBL"
>>> +   select CPU_V7
>>> +   select SUPPORT_SPL
>>> +   help
>>> + Support for the Broadcom 7445D0 SoC.  This port assumes Bolt
>>
>> BOLT
>>
>>> + is acting as the second stage bootloader, and U-Boot is
>>> + acting as the third stage bootloader (TSBL), loaded by Bolt.
>>
>> again BOLT
> 
> Oops, will fix in a v2 patch.
> 
>>> + This port may work on other BCM7xxx boards with
>>> + configuration changes.
>>
>> There are other revisions than D0, so I would just name this
>> TARGET_BCM7445. You would likely want to create a TARGET_BRCMSTB general
>> menu which would encompass all ARMv7-A based SoCs from the Broadcom
>> STB/CM division, and then have per-chip Kconfig options (similar to what
>> the older <= 3.14 STB Linux kernels did).
> 
> OK, will try this in v2.
> 
>>> +
>>> +config BCMSTB_ACCOMMODATE_STBLINUX
>>> +   bool ""
>>> +   default y
>>> +   help
>>> + This prevents U-Boot from adding memory reservations for the
>>> +  lengths of initramfs and DTB.  Without skipping these,
>>> +  stblinux's "contiguous memory allocator" (CMA) Linux driver
>>> +  (cma_driver) will allocate memory ranges smaller than what
>>> +  are actually available, because it only checks reservation
>>> +  sizes.  It doesn't check if the reserved range overlaps the
>>> +  range it allocates.  stblinux also tries to move the DTB to
>>> +  a lower memory location early in the Linux boot.  If the FIT
>>> +  image specifies a load address for the initramfs then
>>> +  sometimes the DTB is moved into the range where the
>>> +  initramfs image is loaded.  Defining this will mean that
>>> +  FIT-provided initramfs load addresses are ignored.
>>
>> What STB Linux kernel did you observe this with? I am afraid this is
>> still true about the ranges vs. allocation even in newer kernels, but
>> that is kind of intented to keep the logic KISS (because it's already
>> too complicated IMHO).
> 
> I investigated the allocation discrepancy and wrote the workaround while
> we were still using stblinux-3.14.  Since then we've updated to
> stblinux-4.1 and I've left the workaround enabled, but I haven't
> investigated its interactions with the newer bmem mechanism.  I should
> probably revisit this though, with stblinux-4.1 and stblinux-4.9, just
> to make sure this macro is still useful.

Sounds good, let me know if there is something that does not seem quite
right, we could fix it.

> 
>>> +
>>> +config BCMSTB_SDHCI
>>> +   bool ""
>>> +   default y
>>> +
>>> +config BCMSTB_SDHCI_BASE
>>> +   hex ""
>>> +   default 0xf03e0200
>>> +
>>> +config BCMSTB_SPI_BASE
>>> +   hex ""
>>> +   default 0xf03e3400
>>
>> Why don't you get those from the Device Tree blob that BOLT passes?
> 
> During development I did implement that for SDHCI_BASE, so it is
> possible.  But I ended up #ifdef'ing it out and hard-coding the address
> in production, to keep the runtime logic simpler.  Doing DTB traversal
> in code adds complexity but it may achieve portability to different
> BCM7xxx SoCs without further code changes, which would be nice.

Given what I see with Broadcom STB customers, I don't think there is a
strong push for anything other than BOLT, or another proprietary TSBL,
so with that, I am not sure about whether there would be an use case for
e.g; a single u-boot binary that would run on more than a flavor of a
given SoC. I would be inclined to put the different base register
addresses into a header file and use those constants in the respective
drivers (or even better, in the part of code that does register those).

> 
>>> +
>>> +config CMD_FDT_MAX_DUMP
>>> +   int ""
>>> +   default 256
>>> +
>>> +config GENERIC_MMC
>>> +   bool ""
>>> +   default y
>>> +
>>> +config MMC_SDMA
>>> +   bool ""
>>> +   default y
>>> +
>>> +config SDHCI
>>> +   bool ""
>>> +   default y
>>> +
>>> +config SYS_BCMSTB_SPI_WAIT
>>> +   int ""
>>> +   default 10
>>> +
>>> +config SYS_FDT_SAVE_ADDRESS
>>> +   hex ""
>>> +   default 0x1f0
>>> +
>>> +config SYS_NO_FLASH
>>> +   bool ""
>>> +   default y
>>> +
>>> +config

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

2018-05-10 Thread Thomas Fitzsimmons 
Florian Fainelli  writes:

> On 05/06/2018 04:09 AM, 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 
>> Cc: Stefan Roese 
>
>> 
>> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
>> index 9bd70f4..b2df30a 100644
>> --- a/arch/arm/Kconfig
>> +++ b/arch/arm/Kconfig
>> @@ -498,6 +498,17 @@ config TARGET_VEXPRESS_CA15_TC2
>>  select CPU_V7_HAS_VIRT
>>  select PL011_SERIAL
>>  
>> +config TARGET_BCM7445D0
>> +bool "Broadcom 7445D0 TSBL"
>> +select CPU_V7
>> +select SUPPORT_SPL
>> +help
>> +  Support for the Broadcom 7445D0 SoC.  This port assumes Bolt
>
> BOLT
>
>> +  is acting as the second stage bootloader, and U-Boot is
>> +  acting as the third stage bootloader (TSBL), loaded by Bolt.
>
> again BOLT

Oops, will fix in a v2 patch.

>> +  This port may work on other BCM7xxx boards with
>> +  configuration changes.
>
> There are other revisions than D0, so I would just name this
> TARGET_BCM7445. You would likely want to create a TARGET_BRCMSTB general
> menu which would encompass all ARMv7-A based SoCs from the Broadcom
> STB/CM division, and then have per-chip Kconfig options (similar to what
> the older <= 3.14 STB Linux kernels did).

OK, will try this in v2.

>> +
>> +config BCMSTB_ACCOMMODATE_STBLINUX
>> +bool ""
>> +default y
>> +help
>> +  This prevents U-Boot from adding memory reservations for the
>> +  lengths of initramfs and DTB.  Without skipping these,
>> +  stblinux's "contiguous memory allocator" (CMA) Linux driver
>> +  (cma_driver) will allocate memory ranges smaller than what
>> +  are actually available, because it only checks reservation
>> +  sizes.  It doesn't check if the reserved range overlaps the
>> +  range it allocates.  stblinux also tries to move the DTB to
>> +  a lower memory location early in the Linux boot.  If the FIT
>> +  image specifies a load address for the initramfs then
>> +  sometimes the DTB is moved into the range where the
>> +  initramfs image is loaded.  Defining this will mean that
>> +  FIT-provided initramfs load addresses are ignored.
>
> What STB Linux kernel did you observe this with? I am afraid this is
> still true about the ranges vs. allocation even in newer kernels, but
> that is kind of intented to keep the logic KISS (because it's already
> too complicated IMHO).

I investigated the allocation discrepancy and wrote the workaround while
we were still using stblinux-3.14.  Since then we've updated to
stblinux-4.1 and I've left the workaround enabled, but I haven't
investigated its interactions with the newer bmem mechanism.  I should
probably revisit this though, with stblinux-4.1 and stblinux-4.9, just
to make sure this macro is still useful.

>> +
>> +config BCMSTB_SDHCI
>> +bool ""
>> +default y
>> +
>> +config BCMSTB_SDHCI_BASE
>> +hex ""
>> +default 0xf03e0200
>> +
>> +config BCMSTB_SPI_BASE
>> +hex ""
>> +default 0xf03e3400
>
> Why don't you get those from the Device Tree blob that BOLT passes?

During development I did implement that for SDHCI_BASE, so it is
possible.  But I ended up #ifdef'ing it out and hard-coding the address
in production, to keep the runtime logic simpler.  Doing DTB traversal
in code adds complexity but it may achieve portability to different
BCM7xxx SoCs without further code changes, which would be nice.

>> +
>> +config CMD_FDT_MAX_DUMP
>> +int ""
>> +default 256
>> +
>> +config GENERIC_MMC
>> +bool ""
>> +default y
>> +
>> +config MMC_SDMA
>> +bool ""
>> +default y
>> +
>> +config SDHCI
>> +bool ""
>> +default y
>> +
>> +config SYS_BCMSTB_SPI_WAIT
>> +int ""
>> +default 10
>> +
>> +config SYS_FDT_SAVE_ADDRESS
>> +hex ""
>> +default 0x1f0
>> +
>> +config SYS_NO_FLASH
>> +bool ""
>> +default y
>> +
>> +config TIMER_FREQUENCY_REGISTER_ADDRESS
>> +hex ""
>> +default 0xf0412020
>> +
>> +config TIMER_LOW_REGISTER_ADDRESS
>> +hex ""
>> +default 0xf0412008
>
> All of these physical address ares not going to change given a
> 7445-based design, so why not hard code them in a header file unless you
> are keen on taking them from the passed Device Tree blob from BOLT?

Agreed, a header file or BOLT DTB lookup for these values would be
better.  I think for a v2 of the patch, I'll move these to a header
file.  If I get to adding another BCM7xxx board (I'm looking at BCM7260
right now) then I can revisit BOLT DTB lookups in the context of
portability between the two SoCs.

>> +int dram_init_banksize(void)
>> +{
>> +bd_t *bd = gd->bd;
>> +
>> +bd->bi_dram[0].start

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

2018-05-08 Thread Florian Fainelli 
On 05/06/2018 04:09 AM, 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 
> Cc: Stefan Roese 

> 
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index 9bd70f4..b2df30a 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -498,6 +498,17 @@ config TARGET_VEXPRESS_CA15_TC2
>   select CPU_V7_HAS_VIRT
>   select PL011_SERIAL
>  
> +config TARGET_BCM7445D0
> + bool "Broadcom 7445D0 TSBL"
> + select CPU_V7
> + select SUPPORT_SPL
> + help
> +   Support for the Broadcom 7445D0 SoC.  This port assumes Bolt

BOLT

> +   is acting as the second stage bootloader, and U-Boot is
> +   acting as the third stage bootloader (TSBL), loaded by Bolt.

again BOLT

> +   This port may work on other BCM7xxx boards with
> +   configuration changes.

There are other revisions than D0, so I would just name this
TARGET_BCM7445. You would likely want to create a TARGET_BRCMSTB general
menu which would encompass all ARMv7-A based SoCs from the Broadcom
STB/CM division, and then have per-chip Kconfig options (similar to what
the older <= 3.14 STB Linux kernels did).

> +
> +config BCMSTB_ACCOMMODATE_STBLINUX
> + bool ""
> + default y
> + help
> +   This prevents U-Boot from adding memory reservations for the
> +  lengths of initramfs and DTB.  Without skipping these,
> +  stblinux's "contiguous memory allocator" (CMA) Linux driver
> +  (cma_driver) will allocate memory ranges smaller than what
> +  are actually available, because it only checks reservation
> +  sizes.  It doesn't check if the reserved range overlaps the
> +  range it allocates.  stblinux also tries to move the DTB to
> +  a lower memory location early in the Linux boot.  If the FIT
> +  image specifies a load address for the initramfs then
> +  sometimes the DTB is moved into the range where the
> +  initramfs image is loaded.  Defining this will mean that
> +  FIT-provided initramfs load addresses are ignored.

What STB Linux kernel did you observe this with? I am afraid this is
still true about the ranges vs. allocation even in newer kernels, but
that is kind of intented to keep the logic KISS (because it's already
too complicated IMHO).

> +
> +config BCMSTB_SDHCI
> + bool ""
> + default y
> +
> +config BCMSTB_SDHCI_BASE
> + hex ""
> + default 0xf03e0200
> +
> +config BCMSTB_SPI_BASE
> + hex ""
> + default 0xf03e3400

Why don't you get those from the Device Tree blob that BOLT passes?

> +
> +config CMD_FDT_MAX_DUMP
> + int ""
> + default 256
> +
> +config GENERIC_MMC
> + bool ""
> + default y
> +
> +config MMC_SDMA
> + bool ""
> + default y
> +
> +config SDHCI
> + bool ""
> + default y
> +
> +config SYS_BCMSTB_SPI_WAIT
> + int ""
> + default 10
> +
> +config SYS_FDT_SAVE_ADDRESS
> + hex ""
> + default 0x1f0
> +
> +config SYS_NO_FLASH
> + bool ""
> + default y
> +
> +config TIMER_FREQUENCY_REGISTER_ADDRESS
> + hex ""
> + default 0xf0412020
> +
> +config TIMER_LOW_REGISTER_ADDRESS
> + hex ""
> + default 0xf0412008

All of these physical address ares not going to change given a
7445-based design, so why not hard code them in a header file unless you
are keen on taking them from the passed Device Tree blob from BOLT?

> +int dram_init_banksize(void)
> +{
> + bd_t *bd = gd->bd;
> +
> + bd->bi_dram[0].start = 0x;
> + bd->bi_dram[0].size  = 0x4000;
> + bd->bi_dram[1].start = 0x4000;
> + bd->bi_dram[1].size  = 0x4000;
> + bd->bi_dram[2].start = 0x8000;
> + bd->bi_dram[2].size  = 0x4000;

This may be true for your system if you have 3x1GB populated, but 7445
supports additional extension regions, so this must be configurable if
you want to make this flexible enough for other people to use it.


> +/* Copied from stblinux, include/linux/brcmstb/brcmstb.h. */
> +#define DEV_RD(x) (readl((x)))
> +#define DEV_WR(x, y) do { writel((y), (x)); } while (0)
> +#define DEV_UNSET(x, y) do { DEV_WR((x), DEV_RD(x) & ~(y)); } while (0)
> +#define DEV_SET(x, y) do { DEV_WR((x), DEV_RD(x) | (y)); } while (0)
> +
> +#define DEV_WR_RB(x, y) do { DEV_WR((x), (y)); DEV_RD(x); } while (0)
> +#define DEV_SET_RB(x, y) do { DEV_SET((x), (y)); DEV_RD(x); } while (0)
> +#define DEV_UNSET_RB(x, y) do { DEV_UNSET((x), (y)); DEV_RD(x); } while (0)

I would just flat out drop those macros and instead use standard
accessors. Those happen to work just fine given Broadcom STB's GISB bus,
but if you want portable drivers in u-boot, and you likely would want
those, you should use more standard I/O accessors.

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

2018-05-07 Thread Tom Rini 
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 
> Cc: Stefan Roese 
[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?

> +config BCHP_BSPI_MAST_N_BOOT_CTRL
> + hex ""
> + default 0x003e3208

Doing hex "" seems wrong.  What are you doing here exactly?

> 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?

> +#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!

-- 
Tom


signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

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

2018-05-06 Thread Thomas Fitzsimmons 
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 
Cc: Stefan Roese 
---
 arch/arm/Kconfig|  12 +
 arch/arm/cpu/armv7/Makefile |   1 +
 arch/arm/cpu/armv7/bcm7445d0/Makefile   |  11 +
 arch/arm/cpu/armv7/bcm7445d0/lowlevel_init.S|  24 ++
 arch/arm/lib/crt0.S |   2 +
 arch/arm/mach-bcm7445d0/include/mach/gpio.h |  12 +
 arch/arm/mach-bcm7445d0/include/mach/hardware.h |  12 +
 arch/arm/mach-bcm7445d0/include/mach/sdhci.h|  15 +
 board/broadcom/bcm7445d0/Kconfig| 132 
 board/broadcom/bcm7445d0/Makefile   |  11 +
 board/broadcom/bcm7445d0/bcm7445d0.c| 147 
 common/fdt_support.c|   9 +-
 common/image-fit.c  |   2 +
 configs/bcm7445d0_defconfig |  21 ++
 drivers/mmc/Makefile|   1 +
 drivers/mmc/bcmstb_sdhci.c  |  59 
 drivers/spi/Kconfig |   7 +
 drivers/spi/Makefile|   1 +
 drivers/spi/bcmstb_spi.c| 428 
 dts/Kconfig |   6 +
 include/configs/bcm7445d0.h | 227 +
 include/configs/bcmstb.h|  57 
 lib/fdtdec.c|   8 +
 23 files changed, 1204 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/cpu/armv7/bcm7445d0/Makefile
 create mode 100644 arch/arm/cpu/armv7/bcm7445d0/lowlevel_init.S
 create mode 100644 arch/arm/mach-bcm7445d0/include/mach/gpio.h
 create mode 100644 arch/arm/mach-bcm7445d0/include/mach/hardware.h
 create mode 100644 arch/arm/mach-bcm7445d0/include/mach/sdhci.h
 create mode 100644 board/broadcom/bcm7445d0/Kconfig
 create mode 100644 board/broadcom/bcm7445d0/Makefile
 create mode 100644 board/broadcom/bcm7445d0/bcm7445d0.c
 create mode 100644 configs/bcm7445d0_defconfig
 create mode 100644 drivers/mmc/bcmstb_sdhci.c
 create mode 100644 drivers/spi/bcmstb_spi.c
 create mode 100644 include/configs/bcm7445d0.h
 create mode 100644 include/configs/bcmstb.h

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 9bd70f4..b2df30a 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -498,6 +498,17 @@ config TARGET_VEXPRESS_CA15_TC2
select CPU_V7_HAS_VIRT
select PL011_SERIAL
 
+config TARGET_BCM7445D0
+   bool "Broadcom 7445D0 TSBL"
+   select CPU_V7
+   select SUPPORT_SPL
+   help
+ Support for the Broadcom 7445D0 SoC.  This port assumes Bolt
+ is acting as the second stage bootloader, and U-Boot is
+ acting as the third stage bootloader (TSBL), loaded by Bolt.
+ This port may work on other BCM7xxx boards with
+ configuration changes.
+
 config TARGET_VEXPRESS_CA5X2
bool "Support vexpress_ca5x2"
select CPU_V7
@@ -1320,6 +1331,7 @@ source "board/armltd/vexpress/Kconfig"
 source "board/armltd/vexpress64/Kconfig"
 source "board/broadcom/bcm23550_w1d/Kconfig"
 source "board/broadcom/bcm28155_ap/Kconfig"
+source "board/broadcom/bcm7445d0/Kconfig"
 source "board/broadcom/bcmcygnus/Kconfig"
 source "board/broadcom/bcmnsp/Kconfig"
 source "board/broadcom/bcmns2/Kconfig"
diff --git a/arch/arm/cpu/armv7/Makefile b/arch/arm/cpu/armv7/Makefile
index b14ee54..7183d4d 100644
--- a/arch/arm/cpu/armv7/Makefile
+++ b/arch/arm/cpu/armv7/Makefile
@@ -30,6 +30,7 @@ endif
 
 obj-$(if $(filter bcm235xx,$(SOC)),y) += bcm235xx/
 obj-$(if $(filter bcm281xx,$(SOC)),y) += bcm281xx/
+obj-$(if $(filter bcm7445d0,$(SOC)),y) += bcm7445d0/
 obj-$(if $(filter bcmcygnus,$(SOC)),y) += bcmcygnus/
 obj-$(if $(filter bcmnsp,$(SOC)),y) += bcmnsp/
 obj-$(if $(filter ls102xa,$(SOC)),y) += ls102xa/
diff --git a/arch/arm/cpu/armv7/bcm7445d0/Makefile 
b/arch/arm/cpu/armv7/bcm7445d0/Makefile
new file mode 100644
index 000..796f482
--- /dev/null
+++ b/arch/arm/cpu/armv7/bcm7445d0/Makefile
@@ -0,0 +1,11 @@
+#
+# (C) Copyright 2018
+# Cisco Systems, Inc. 
+#
+# Author :
+#  Thomas Fitzsimmons 
+#
+# SPDX-License-Identifier: GPL-2.0+
+#
+
+obj-y  := lowlevel_init.o
diff --git a/arch/arm/cpu/armv7/bcm7445d0/lowlevel_init.S 
b/arch/arm/cpu/armv7/bcm7445d0/lowlevel_init.S
new file mode 100644
index 000..1eb67a0
--- /dev/null
+++ b/arch/arm/cpu/armv7/bcm7445d0/lowlevel_init.S
@@ -0,0 +1,24 @@
+/*
+ * (C) Copyright 2018
+ * Cisco Systems, Inc. 
+ *
+ * Author :
+ * Thomas Fitzsimmons 
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include 
+
+ENTRY(save_boot_params)
+   ldr r6, =bcm7445d0_boot_parameters
+   str r0, [r6,