Proper/Valid memory regions for uboot to locate initramfs/DTB for Kernel

[soccercheng]

I'd like to adjust the uboot configurations to load initramfs and DTB to specific memory area for Kernel, and I have the following questions, hope you can provide some hints for my reference.

• What is the valid memory region for uboot to locate initramfs/DTB for Linux Kernel on the following platforms
• ARC HS4x/HS4xD Development Kit

BTW, The memory regions is CPU or board level configuration specific ?

[abrodkin]

HSDK as a platform & ARC HS processors are very flexible in a sense of how memory might be visible to the processor and so how it might be used. You may want to check HSDK's User's manuals and in particular its "Memory Map" section. Links to those manuals are here:

• User's manual for the original HSDK board: https://github.com/foss-for-synopsys-dwc-arc-processors/ARC-Development-Systems-Forum/wiki/docs/ARC_HSDK_User_Guide.pdf
• User's manual for more recent HSDK-4xD board: https://github.com/foss-for-synopsys-dwc-arc-processors/ARC-Development-Systems-Forum/wiki/docs/ARC_HSDK_4xD_User_Guide.pdf

Now, speaking of our current settings of U-Boot for this board it uses DDR visible for ARC HS processor from address 0x8000_0000 to 0xbfff_ffff (1 GiB total).
U-Boot itself early on start self-relocates into the very end of that region (close to 0xbfff_ffff), leaving majority of 1 GiB address-space that starts from 0x8000_0000 for something useful like the Linux kernel image, .dtb, initramfs etc. That said you'll have a plenty of options on how to use that almost full 1 GiB of DDR.

What we do is:

1. Link the Linux kernel to 0x9000_0000 and since running kernel will be located there, we "reserve" that region for the kernel image
2. Load "uImage" (with built-in initramfs) from either micro-SD card or from TFTP server to 0x8200_0000 (assuming the image will be much smaller than 256 Mib and won't over with 0x9000_0000+ addresses)
3. Load .dtb to 0x8000_0000 (assuming it won't be that large to overla with uImage located starting from 0x8200_0000).

[soccercheng]

What we do is:

1. Link the Linux kernel to 0x9000_0000 and since running kernel will be located there, we "reserve" that region for the kernel image
2. Load "uImage" (with built-in initramfs) from either micro-SD card or from TFTP server to 0x8200_0000 (assuming the image will be much smaller than 256 Mib and won't over with 0x9000_0000+ addresses)
3. Load .dtb to 0x8000_0000 (assuming it won't be that large to overla with uImage located starting from 0x8200_0000).

It seems 0x8000_0000 ~ 0x8200_0000 might be the adequate area if DTB/initramfs are load by uboot itself because uboot releases '0x8100_0000 ~ 0x8200_0000' after it relocates itself to near top of 1G memory area.

What we're working on is enabling SPL for ARC platform and SPL loads U-Boot, kernel, DTB, initramfs, if this is the case, 0x8000_0000 ~ 0x8100_0000 might be the proper area cause SPL loads U-Boot to 0x8100_0000.

And, The current U-Boot for HSDK implementation occupies 0x8000_0000 ~ 0x8000_1000 as the u-Boot stack usage, so we need to prevent this area as well. you can check include/configs/hsdk-4xd.h

#define CONFIG_SYS_INIT_SP_ADDR
(CONFIG_SYS_SDRAM_BASE + 0x1000 - GENERATED_GBL_DATA_SIZE)

BTW,
I don't think "- GENERATED_GBL_DATA_SIZE" is NOT necessary cause GBL will be preserve later on U-Boot inits sp (stack pointer register) stage.

[abrodkin]

U-Boot as a boot-loader is supposed to be tailored for each particular board, so please feel free to use available memory in the way which works the best for you. There's no strict reason to load .dtb or anything else to 0x8100_0000 or 0x8300_0000. We just implemented something for our board and it works good for us. If you need another layout of memory, please change it.