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