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.looijm...@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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
