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

Michal Simek monstr at monstr.eu
Tue Nov 22 10:25:43 CET 2016


On 21.11.2016 14:43, Mike Looijmans wrote:
> 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.

Let me go back to origin patch and clear some things there.

Thanks,
Michal

-- 
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Xilinx Microblaze
Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP ARM64 SoCs
U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP SoCs



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: OpenPGP digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20161122/d84c48cb/attachment.sig>


More information about the U-Boot mailing list