[U-Boot] [PATCH v2 16/17] rockchip: rk3036: Add core Soc start-up code

[hl]

Hi

On 06/11/15 17:11, Sjoerd Simons wrote:
> On Wed, 2015-11-04 at 20:53 +0800, Lin Huang wrote:
>> rk3036 only 4K size SRAM for SPL, so only support
>> timer, uart, sdram driver in SPL stage, when finish
>> initial sdram, back to bootrom.
>>
>> Signed-off-by: Lin Huang <hl at rock-chips.com>
>>   
>>   
>> diff --git a/arch/arm/mach-rockchip/rk3036/save_boot_param.S
>> b/arch/arm/mach-rockchip/rk3036/save_boot_param.S
>> new file mode 100644
>> index 0000000..3d3883d
>> --- /dev/null
>> +++ b/arch/arm/mach-rockchip/rk3036/save_boot_param.S
>> @@ -0,0 +1,34 @@
>> +/*
>> + * (C) Copyright 2015 Google, Inc
>> + *
>> + * SPDX-License-Identifier:     GPL-2.0+
>> + */
>> +
>> +#include <linux/linkage.h>
>> +
>> +.globl	SAVE_SP_ADDR
>> +SAVE_SP_ADDR:
>> +	.word 0
>> +
>> +/*******************************************************************
>> ******
>> + *
>> + * void save_boot_params
>> + *
>> + * Save sp, lr, r1~r12
>> + *
>> +
>> *********************************************************************
>> ****/
>> +ENTRY(save_boot_params)
>> +	push	{r1-r12, lr}
>> +	ldr	r0, =SAVE_SP_ADDR
>> +	str	sp, [r0]	
>> +	b	save_boot_params_ret		@ back to my
>> caller
>> +ENDPROC(save_boot_params)
>> +
>> +
>> +.globl back_to_bootrom
>> +ENTRY(back_to_bootrom)
>> +	ldr	r0, =SAVE_SP_ADDR
>> +	ldr	sp, [r0]
>> +	mov	r0, #0
>> +	pop	{r1-r12, pc}
>> +ENDPROC(back_to_bootrom)
> Is this way of going back to be bootrom generic for other Rockchip SOCs
> as well?
>
> Specifically for RK3288 in maskrom mode we can currently load the
> u-boot SPL, but not the main loader. If we could use this method of
> going to the bootrom on that board that should be a nice way forward.
>
>
>> diff --git a/include/configs/rk3036_common.h
>> b/include/configs/rk3036_common.h
>> new file mode 100644
>> index 0000000..f7bd852
>> --- /dev/null
>> +++ b/include/configs/rk3036_common.h
>> @@ -0,0 +1,120 @@
>> +/*
>> + * (C) Copyright 2015 Rockchip Electronics Co., Ltd
>> + *
>> + * SPDX-License-Identifier:     GPL-2.0+
>> + */
>>   
>> +/* RAW SD card / eMMC locations. */
>> +#define CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR	256
>> +#define CONFIG_SYS_SPI_U_BOOT_OFFS	(128 << 10)
> I don't think you need to define these if you're having the main u-boot
> image loaded by your bootrom rather then SPL directly.
yes, you are right, i just sended v3, will correct it in v4, thank you.
>> +/* FAT sd card locations. */
>> +#define CONFIG_SYS_MMCSD_FS_BOOT_PARTITION	1
>> +#define CONFIG_SPL_FS_LOAD_PAYLOAD_NAME		"u-boot.img"
> ditto
>
>> +/* #define CONFIG_SPL_PINCTRL_SUPPORT
>> +#define CONFIG_SPL_GPIO_SUPPORT
>> +#define CONFIG_SPL_RAM_SUPPORT
>> +#define CONFIG_SPL_DRIVERS_MISC_SUPPORT */
>> +
>> +#define CONFIG_CMD_CACHE
>> +#define CONFIG_CMD_TIME
>> +
>> +#define CONFIG_SYS_SDRAM_BASE		0x60000000
>> +#define CONFIG_NR_DRAM_BANKS		1
>> +#define SDRAM_BANK_SIZE			(512UL << 20UL)
>> +
>> +#define CONFIG_SPI_FLASH
>> +#define CONFIG_SPI
>> +#define CONFIG_CMD_SF
>> +#define CONFIG_CMD_SPI
>> +#define CONFIG_SPI_FLASH_GIGADEVICE
>> +#define CONFIG_SF_DEFAULT_SPEED 20000000
>> +#define CONFIG_CMD_I2C
>> +
>> +#ifndef CONFIG_SPL_BUILD
>> +#include <config_distro_defaults.h>
>> +
>> +#define ENV_MEM_LAYOUT_SETTINGS \
>> +	"scriptaddr=0x00000000\0" \
>> +	"pxefile_addr_r=0x00100000\0" \
>> +	"fdt_addr_r=0x01f00000\0" \
>> +	"kernel_addr_r=0x02000000\0" \
>> +	"ramdisk_addr_r=0x04000000\0"
> I suspect these offset don't make sense for this board given your
> SYS_SDRAM_BASE is 0x60000000
     Have been correct in v3 patch.
>> +/* First try to boot from SD (index 0), then eMMC (index 1 */
>> +#define BOOT_TARGET_DEVICES(func) \
>> +	func(MMC, mmc, 0) \
>> +	func(MMC, mmc, 1)
>> +
>> +#include <config_distro_bootcmd.h>
>> +
>> +/* Linux fails to load the fdt if it's loaded above 512M on a Rock 2
>> board, so
>> + * limit the fdt reallocation to that */
> You probably want to change the comment here :)
>
     yes, will modify it in v4
>> +#define CONFIG_EXTRA_ENV_SETTINGS \
>> +	"fdt_high=0x1fffffff\0" \
> Hopefully the fdt_high isn't needed on 3036? (It's hopefully temporary
> as well on 3288 until someone figures out what's wrong.
     sorry, i am not very clear why 3288 need it.
>> +	ENV_MEM_LAYOUT_SETTINGS \
>> +	BOOTENV
>> +#endif
>> +
>> +#endif

-- 
Lin Huang