[U-Boot] [PATCH] board: topic: Detect RAM size at boot

[Mike Looijmans]

On 21-11-16 10:04, Michal Simek wrote:
> Hi Mike,
>
> On 21.11.2016 09:30, Mike Looijmans wrote:
>> Miami boards can have memory sizes of 256M, 512M or 1GB. To prevent requiring
>> separate bootloaders for each variant, just detect the RAM size at boot time
>> instead of relying on the devicetree information.
>>
>> Signed-off-by: Mike Looijmans <mike.looijmans at topic.nl>
>> ---
>>  board/topic/zynq/board.c          | 39 +++++++++++++++++++++++++++++++++++++++
>>  configs/topic_miami_defconfig     |  1 +
>>  configs/topic_miamiplus_defconfig |  1 +
>>  3 files changed, 41 insertions(+)
>>
>> diff --git a/board/topic/zynq/board.c b/board/topic/zynq/board.c
>> index a95c9d1..8a5765e 100644
>> --- a/board/topic/zynq/board.c
>> +++ b/board/topic/zynq/board.c
>> @@ -1 +1,40 @@
>> +/*
>> + * (C) Copyright 2016 Topic Embedded Products
>> + *
>> + * SPDX-License-Identifier:	GPL-2.0+
>> + */
>> +
>> +/*
>> + * Miami boards can have memory sizes of 256M, 512M or 1GB. To prevent needing
>> + * separate bootloaders for each variant, just detect the RAM size at boot time
>> + * instead of relying on the devicetree information.
>> + */
>> +#define CONFIG_SYS_SDRAM_BASE	0
>> +#define CONFIG_SYS_SDRAM_SIZE	topic_get_sdram_size()
>> +#define CONFIG_SYS_SDRAM_SIZE_MAX 0x40000000u
>> +
>> +static unsigned int topic_get_sdram_size(void);
>> +
>>  #include "../../xilinx/zynq/board.c"
>> +
>> +#include <fdt_support.h>
>> +
>> +int ft_board_setup(void *blob, bd_t *bd)
>> +{
>> +	fdt_fixup_memory(blob, (u64)CONFIG_SYS_SDRAM_BASE, (u64)gd->ram_size);
>> +
>> +	return 0;
>> +}
>> +
>> +void dram_init_banksize(void)
>> +{
>> +	gd->bd->bi_dram[0].start = CONFIG_SYS_SDRAM_BASE;
>> +	gd->bd->bi_dram[0].size = gd->ram_size;
>> +}
>> +
>> +unsigned int topic_get_sdram_size(void)
>> +{
>> +	/* Detect and fix ram size */
>> +	return get_ram_size((void *)CONFIG_SYS_SDRAM_BASE,
>> +					   CONFIG_SYS_SDRAM_SIZE_MAX);
>> +}
>> diff --git a/configs/topic_miami_defconfig b/configs/topic_miami_defconfig
>> index 3d6161e..8a02668 100644
>> --- a/configs/topic_miami_defconfig
>> +++ b/configs/topic_miami_defconfig
>> @@ -24,6 +24,7 @@ CONFIG_CMD_EXT4=y
>>  CONFIG_CMD_FAT=y
>>  CONFIG_CMD_FS_GENERIC=y
>>  CONFIG_OF_EMBED=y
>> +CONFIG_OF_BOARD_SETUP=y
>>  CONFIG_SPL_DM_SEQ_ALIAS=y
>>  CONFIG_ZYNQ_SDHCI=y
>>  CONFIG_SPI_FLASH=y
>> diff --git a/configs/topic_miamiplus_defconfig b/configs/topic_miamiplus_defconfig
>> index 3160f00..08bfab2 100644
>> --- a/configs/topic_miamiplus_defconfig
>> +++ b/configs/topic_miamiplus_defconfig
>> @@ -24,6 +24,7 @@ CONFIG_CMD_EXT4=y
>>  CONFIG_CMD_FAT=y
>>  CONFIG_CMD_FS_GENERIC=y
>>  CONFIG_OF_EMBED=y
>> +CONFIG_OF_BOARD_SETUP=y
>>  CONFIG_SPL_DM_SEQ_ALIAS=y
>>  CONFIG_ZYNQ_SDHCI=y
>>  CONFIG_SPI_FLASH=y
>>
>
>
> Sorry I am not getting this. I can't see that detection algorithm above
> and just looking at above description again that you have 256, 512 and
> 1G why not just run u-boot with 256MB - it should be enough for boot
> images and u-boot self, disable ARCH_FIXUP_FDT and update your
> bootscript to detect ram size and update dts by fdt commands?

Lack of knowledge is one part.

The only difference between the boards is the RAM chip installed on it. 
There's nothing else to detect which board you're running on.

As far as I can see, it would be more difficult to perform this in a 
bootscript. I'd be happy to be proven wrong though.

Plus, this way u-boot tells the truth at boot. Customers will yell at me if 
the bootloader reports only 256M at boot.

> This will be much cleaner solution than code above.

I only need 3 lines of code here to determine the memory configuration from 
the actual hardware. They look nice and clean to me. The original code in 
zynq/board.c needs a few dozen lines to fetch it from a devicetree.

It could be made cleaner by replacing the 0x40000000 constant with reading the 
DDR config registers, but that'd be overkill and probably take more cycles 
than just running the test. And, from reading the documentation, calling 
get_ram_size is actually a good thing to do since it verifies that the memory 
actually works before using it.

At this point I don't know how to proceed here.

Mike.


Kind regards,

Mike Looijmans
System Expert

TOPIC Products
Materiaalweg 4, NL-5681 RJ Best
Postbus 440, NL-5680 AK Best
Telefoon: +31 (0) 499 33 69 79
E-mail: mike.looijmans at topicproducts.com
Website: www.topicproducts.com

Please consider the environment before printing this e-mail