November 2019 - U-Boot

Re: [U-Boot] [EXT] Re: Cavium/Marvell Octeon Support
by Aaron Williams 07 Nov '19

07 Nov '19

Hi Tom, ________________________________ From: Tom Rini Sent: Tuesday, November 5, 2019 6:16 AM To: Wolfgang Denk Cc: Aaron Williams; Daniel Schwierzeck; u-boot(a)lists.denx.de Subject: Re: [EXT] Re: Cavium/Marvell Octeon Support On Tue, Nov 05, 2019 at 09:33:35AM +0100, Wolfgang Denk wrote: > Dear Aaron, > > In message <5376617.97hUrJXovB@flash> you wrote: > > > > > Again you don't answer my question. Why do you need a special new > > > API for such code? Why do you not just link that code with the rest > > > of U-Boot? > > > > The code in question that is calling the API is not GPL and hence cannot be > > linked with U-Boot though the phy code is GPL. > > Ouch. I was afraid to hear that. > > Please be aware that your newly created API does NOT implement a GPL > license exception. the only interface that allows for non-GPL code > to be run under control of U-Boot is the standalone program > interface, which is intentionally very restricted. > > In other words: what you are doing here is a clear (and intentional, > which makes it even worse) GPL license violation. > > > > It has been mentioned before, but just to be sure: this code which > > > uses your new API is licensed under a GPLv2 conforming lincense? > > > > > There should be no need. None of the code is linked against U-Boot, either at > > compile time nor at runtime. The application doesn't even know where it is > > located except by looking for a named block of memory. > > It does not have to be linked. You access internal interfaces of > U-Boot that have not been exported for non-GPL use, so your code > still has to be licensed under GPLv2 or a compatible license. I'm just following up to say that I agree with Wolfgang here. Sorry for the broken formatting (our IT department forces the Outhouse web client). I think there is some misunderstanding here. All of the code we include in U-Boot IS GPL or GPL compatible, including the API. "Even though U-Boot in general is covered by the GPL-2.0/GPL-2.0+, this does *not* cover the so-called "standalone" applications that use U-Boot services by means of the jump table provided by U-Boot exactly for this purpose - this is merely considered normal use of U-Boot, and does *not* fall under the heading of "derived work"." No part of U-Boot is included in these applications and no application code is included in U-Boot. We DO have SDK files used in U-Boot, but the SDK files are under a BSD-like license, basically do whatever you want with the code but don't hold us responsible. The SDK code is also used in stand-alone applications as well as the Linux kernel, where derivatives were upstreamed long-ago. In any event, I think at this point we can remove this support. I don't think it's used any longer. It also looks like EFI does allow for vendor defined services. I hadn't looked at this code for a while but looking at it again it also appears the phy code has been removed. I think the remaining code for QLM configuration could be modified to just use a hook from some environment variables, removing this issue entirely. -- Tom Regards, Aaron

2 1

[U-Boot] Cavium/Marvell Octeon Support
by Aaron Williams 07 Nov '19

07 Nov '19

Hi all, I have been tasked with porting our Octeon U-Boot to the latest U-Boot and merging it upstream. This will involve a very significant amount of code that generally will not be compatible with other MIPS processors due to our needs and requirements. For example, the start.S will need to be completely different than what is present. For example, our existing start.S is 3577 lines of code in order to deal with things like RAS, exceptions, virtual memory and more. We need to use virtual memory since U-Boot can be loaded at any 4MB boundary in memory, not just 0xbfc00000. A number of drivers will need to be updated in order to properly map pointers to physical addresses. This is needed anyway, since I see numerous drivers that assume that a pointer is a DMA address. For MIPS this is never the case (I'm looking at XHCI). The new Octeon U-Boot will be native 64-bit instead of how the earlier one was 32-bit using the N32 ABI (so 64-bit addresses could be accessed). We had to jump through some hoops to make a 32-bit U-Boot fully support 64-bit hardware. I think we can shrink the code by removing support for starting "simple executive" tasks. Simple executive tasks are bare metal applications that can run on dedicated cores beside Linux (or without Linux). I will also not be porting any support for anything older than Octeon3. We also make heavy use of our SDK in order to perform hardware initialization and networking. In our old U-Boot, we have almost 900K lines of code. I can cut out much of this but much will remain. We also have added extensive infrastructure for handling SFP and QSFP cables as well as very extensive phy support for phys from Aquantia/Marvell, Vitesse/Microsemi, Inphi/Cortina and an Avago gearbox. Our customer wants us to port all of this to the new U-Boot and upstream it. I'm worried about the sheer amount of code since it is absolutely massive. Some of these phy drivers are extremely complex and need to tie into the SFP management. We also need to use a background polling thread while at the command prompt. A fair bit of our phy code is not in the normal phy drivers because it did not fit the model. Some of these phy drivers need to interact with the SFP support code in order to handle hot plug events in order to reconfigure themselves based on the cable type. The existing SFP code handles everything from SFP to SFP28 as well as QSFP and 100G QSFP (never tested). In the old U-Boot the PHY support had to be significantly enhanced due to requirements for hot-plugging and how some of the PHYs are configured. It gets quite complicated with phys like the Inphi where one phy can handle either four ports (XFI/SGMII) or a single 4-lane port (XLAUI). It gets even worse since in some boards we use reclocking chips and there is one chip that handles the receive path of a QSFP and another that handles the transmit path. Further complicating things, with a QSFP it can be treated either as XLAUI or as four XFI ports, so you can have four ports spread across two chips, with each port using different slices of each chip. In the case of the Inphi/Cortina chip, a single device can handle one or four ports based on the configuration and it is configured by "slice" which is basically an offset into the MDIO register space. We had to jump through hoops in order to have this stuff work in a sane way in the device tree. We added entries for SFP and QSFP slots in the device tree which point to the MACs, GPIOs and I2C bus because pointing them to the phys just got too insane. This will need to be ported to the new U-Boot. It should not break the existing support since most of it was implemented outside of the core PHY handling code. In the port, it would be far better if this could be integrated in. The SFP management code is architecture agnostic as is all of the PHY support. The callbacks for the SFP support are used by the MAC which then notifies the PHY since the MAC often needs to reconfigure itself. It can handle some crazy configurations. While I see some phy drivers that we also support, i.e. Cortina, our drivers tend to have a lot more functionality. For example, all of our phy drivers that support firmware support commands for upgrading the firmware as well as things like cable testing and other features. Our bootloader needs to be able to be booted from a variety of sources, including SPI, eMMC, NOR flash and booting over the PCI bus from a host system. This is one reason we use virtual memory. The other reason is that it eliminates the need to perform relocation. Our start.S code handles all of these different cases as well as exception handling. I will also say up front that the memory initialization code is a mess and quite large (it was written by a hardware engineer who never heard of functions). One thing is that this will break mips unless it is refactored like ARM is, for example, separating armv7 and armv8. This way we could have arch/mips/cpu/octeon. I did this with the old bootloader to separate our stuff. I'm open to suggestions as for the naming. I don't see how we can share much of the code with the other MIPS CPUs. All in all, I think the final port will add between 500K-1M lines of code for the Octeon CPU. It is much more extensive than what is required for OcteonTX since in the latter case most of the hardware initialization is done by earlier stage bootloaders and the ATF handles things like SFP port management and many of the networking operations. I'm not sure how well I'll be able to upstream all of this code at this point since I was just handed this task. We already have at least 1M lines of code added to the old U-Boot which is based off of 2013.08 with a lot of backports.

5 34

[U-Boot] [GIT] Pull request: u-boot-dfu (06.11.2019)
by Lukasz Majewski 07 Nov '19

07 Nov '19

Dear Marek, The following changes since commit 14d39c9e1dc9397febd58399a70f32e7481bbc27: travis: Rework how we write the ~/.buildman file (2019-11-05 10:44:16 -0500) are available in the Git repository at: git@gitlab.denx.de:u-boot/custodians/u-boot-dfu.git BRANCH: master https://gitlab.denx.de/u-boot/custodians/u-boot-dfu/commits/master Merge TAG: https://gitlab.denx.de/u-boot/custodians/u-boot-dfu/-/tags/u-boot-dfu-06Nov… for you to fetch changes up to 8c5df588e89b2bf4aad4c95b17cfc8634b8dcaaf: usb: composite: add BOS descriptor support to composite framework (2019-11-06 01:01:06 +0100) My remark: - Those patches are new code, (like adding the USB 3.0 controller from Cadence) hence IMHO it would be best to add them to your next PR ---------------------------------------------------------------- Sherry Sun (1): usb: udc: Introduce ->udc_set_speed() method T Karthik Reddy (1): usb: composite: add BOS descriptor support to composite framework Vignesh Raghavendra (7): list: import list_first_entry_or_null() bitmaps: import for_each_set_bit() macro usb: gadget: Add match_ep() op to usb_gadget_ops usb: Add Cadence USB3 host and gadget driver usb: cdns3: gadget: Implement udc_set_speed() callback usb: cdns3: Add TI wrapper driver for CDNS USB3 controller usb: gadget: Add gadget_is_cdns3() macro Travis-CI: https://travis-ci.org/lmajewski/u-boot-dfu/builds/607937090 Best regards, Lukasz Majewski -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lukma(a)denx.de

2 5

[U-Boot] [PATCH] ARM: defconfig: add unified config for RPi3 and RPi4
by matthias.bgg＠kernel.org 06 Nov '19

06 Nov '19

From: Matthias Brugger <mbrugger(a)suse.com> Provide a defconfig which allows us to boot Raspberrry Pi 4 and Raspberry Pi 3 Model B/B+ Instead of using the embedded DTB as done in RPi3 we use the devicetree provided by the firmware. Signed-off-by: Matthias Brugger <mbrugger(a)suse.com> --- This patch is based on the series to enable one binary for RPi3 and RPi4: https://patchwork.ozlabs.org/project/uboot/list/?series=140696 arch/arm/mach-bcm283x/Kconfig | 7 ++++++ configs/rpi_arm64_defconfig | 45 +++++++++++++++++++++++++++++++++++ 2 files changed, 52 insertions(+) create mode 100644 configs/rpi_arm64_defconfig diff --git a/arch/arm/mach-bcm283x/Kconfig b/arch/arm/mach-bcm283x/Kconfig index e8e0ff0eb4..00419bf254 100644 --- a/arch/arm/mach-bcm283x/Kconfig +++ b/arch/arm/mach-bcm283x/Kconfig @@ -188,6 +188,13 @@ config TARGET_RPI_4 This option creates a build targeting the ARMv8/AArch64 ISA. select BCM2711_64B +config TARGET_RPI_ARM64 + bool "Raspberry Pi one binary 64-bit build" + help + Support for all armv8 based Raspberry Pi variants, such as + the RPi 4 model B, in AArch64 (64-bit) mode. + select ARM64 + endchoice config SYS_BOARD diff --git a/configs/rpi_arm64_defconfig b/configs/rpi_arm64_defconfig new file mode 100644 index 0000000000..f4e113f58c --- /dev/null +++ b/configs/rpi_arm64_defconfig @@ -0,0 +1,45 @@ +CONFIG_ARM=y +CONFIG_ARM64=y +CONFIG_TARGET_RPI_ARM64=y +CONFIG_ARCH_BCM283X=y +CONFIG_SYS_TEXT_BASE=0x00080000 +CONFIG_SYS_MALLOC_F_LEN=0x2000 +CONFIG_DISTRO_DEFAULTS=y +CONFIG_NR_DRAM_BANKS=2 +CONFIG_OF_BOARD_SETUP=y +CONFIG_USE_PREBOOT=y +CONFIG_PREBOOT="usb start" +CONFIG_MISC_INIT_R=y +# CONFIG_DISPLAY_CPUINFO is not set +# CONFIG_DISPLAY_BOARDINFO is not set +CONFIG_SYS_PROMPT="U-Boot> " +# CONFIG_CMD_FLASH is not set +CONFIG_CMD_GPIO=y +CONFIG_CMD_MMC=y +CONFIG_CMD_USB=y +CONFIG_CMD_FS_UUID=y +CONFIG_OF_BOARD=y +CONFIG_ENV_FAT_INTERFACE="mmc" +CONFIG_ENV_FAT_DEVICE_AND_PART="0:1" +CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG=y +CONFIG_DM_KEYBOARD=y +CONFIG_DM_MMC=y +CONFIG_MMC_SDHCI=y +CONFIG_MMC_SDHCI_BCM2835=y +CONFIG_PHYLIB=y +CONFIG_DM_ETH=y +CONFIG_PINCTRL=y +# CONFIG_PINCTRL_GENERIC is not set +# CONFIG_REQUIRE_SERIAL_CONSOLE is not set +CONFIG_USB=y +CONFIG_DM_USB=y +CONFIG_USB_DWC2=y +CONFIG_USB_KEYBOARD=y +CONFIG_USB_HOST_ETHER=y +CONFIG_USB_ETHER_LAN78XX=y +CONFIG_USB_ETHER_SMSC95XX=y +CONFIG_DM_VIDEO=y +CONFIG_SYS_WHITE_ON_BLACK=y +CONFIG_CONSOLE_SCROLL_LINES=10 +CONFIG_PHYS_TO_BUS=y +CONFIG_OF_LIBFDT_OVERLAY=y -- 2.23.0

3 2

[U-Boot] [PATCH] Makefile: fix dependency for imx targets
by Heiko Schocher 06 Nov '19

06 Nov '19

imx targets are defined in arch/arm/mach-imx/Makefile. Some of them are dependent on targets defined in main Makefile. For the Makefile in arch/arm/mach-imx this targets must be finished before the imx targets are build, if not you get for example the error: make -f /home/hs/abb/mainlining/u-boot/scripts/Makefile.build obj=arch/arm/mach-imx u-boot-dtb.imx make[2]: *** No rule to make target 'u-boot-fit-dtb.bin', needed by 'u-boot-dtb.imx'. Stop. make[1]: *** [/home/hs/abb/mainlining/u-boot/Makefile:1123: u-boot-dtb.imx] Error 2 make[1]: *** Waiting for unfinished jobs.... make[1]: Leaving directory '/work/hs/compile/u-boot/aristainetos2_defconfig' make: *** [Makefile:148: sub-make] Error 2 compile failed In above case of CONFIG_MULTI_DTB_FIT is defined, the u-boot-dtb.imx is dependent on the u-boot-fit-dtb.bin which may is not build yet ... I could reproduce this error on a travis build also if I build an out-of-tree build on a local machine with a build directory on a "slow" slow storage device. If building the same source target with a build dir on a fast storage device, the build works. I found no solution to tell the arch/arm/mach-imx/Makefile to find the targets in main Makefile, if there is a way this would be the better fix. I solved it by adding a IMX_DEPS var, which holds a list of main u-boot targets, which must be finished, before calling imx targets and fixed the build for imx targets which enabled CONFIG_MULTI_DTB_FIT. I think it is just luck, that imx targets with CONFIG_OF_SEPARATE enabled build, because the u-boot-dtb.imx target depends on u-boot-dtb.bin which gets build early enough before starting with u-boot-dtb.imx. May this targets should be fixed too. Signed-off-by: Heiko Schocher <hs(a)denx.de> --- travis build: https://travis-ci.org/hsdenx/u-boot-test/builds/602656876 Makefile | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/Makefile b/Makefile index cbacf1cfe2..1d2c778bd5 100644 --- a/Makefile +++ b/Makefile @@ -1119,7 +1119,15 @@ u-boot.bin: u-boot-nodtb.bin FORCE $(call if_changed,copy) endif -%.imx: %.bin +# we call Makefile in arch/arm/mach-imx which +# has targets which are dependent on targets defined +# here. make could not resolve them and we must ensure +# that they are finished before calling imx targets +ifeq ($(CONFIG_MULTI_DTB_FIT),y) +IMX_DEPS = u-boot-fit-dtb.bin +endif + +%.imx: $(IMX_DEPS) %.bin $(Q)$(MAKE) $(build)=arch/arm/mach-imx $@ $(BOARD_SIZE_CHECK) -- 2.21.0

2 2

[U-Boot] [PULL] u-boot-usb/master
by Marek Vasut 06 Nov '19

06 Nov '19

The following changes since commit 412326d1bc2d346d7b4faad6fa547eaf065681a2: Merge tag 'u-boot-clk-23Oct2019' of https://gitlab.denx.de/u-boot/custodians/u-boot-clk (2019-10-30 13:13:46 -0400) are available in the Git repository at: git://git.denx.de/u-boot-usb.git master for you to fetch changes up to 02b0e1a36c5bc20174299312556ec4e266872bd6: usb: ehci-hcd: Keep async schedule running (2019-10-31 12:13:40 +0100) ---------------------------------------------------------------- Marek Szyprowski (5): gadget: f_thor: properly enable 3rd endpoint defined by the protocol cmd: thor: select DFU subsystem also for 'thor' download tool dfu: mmc: add support for in-partition offset dwc3: flush cache only if there is a buffer attached to a request thor: fix error path after g_dnl_register() failure Marek Vasut (3): usb: storage: Limit transfer size to 120 kiB usb: storage: Only clear READY flag on error usb: ehci-hcd: Keep async schedule running Patrick Delaunay (10): dfu: cosmetic: cleanup sf to avoid checkpatch error doc: dfu: Add dfu documentation dfu: sf: add partition support for nor backend dfu: prepare the support of multiple interface dfu: allow to manage DFU on several devices dfu: allow read with no data without error for EOF indication dfu: add backend for MTD device dfu: add partition support for MTD backend dfu: add DFU virtual backend dfu: add callback for flush and initiated operation Ralph Siemsen (1): dfu: dfu_nand: reduce verbosity Vignesh Raghavendra (1): dwc3-generic: Don't fail probe if clk/reset entries are absent cmd/Kconfig | 1 + cmd/dfu.c | 21 ++++--- cmd/thordown.c | 3 +- common/usb_storage.c | 49 ++++++++-------- doc/README.dfu | 270 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ drivers/dfu/Kconfig | 21 +++++++ drivers/dfu/Makefile | 2 + drivers/dfu/dfu.c | 145 +++++++++++++++++++++++++++++++++++++++++------ drivers/dfu/dfu_mmc.c | 13 ++++- drivers/dfu/dfu_mtd.c | 311 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ drivers/dfu/dfu_nand.c | 2 +- drivers/dfu/dfu_sf.c | 56 ++++++++++++++++++- drivers/dfu/dfu_virt.c | 49 ++++++++++++++++ drivers/usb/dwc3/dwc3-generic.c | 4 +- drivers/usb/dwc3/gadget.c | 3 +- drivers/usb/gadget/f_thor.c | 7 +++ drivers/usb/host/ehci-hcd.c | 51 +++++++---------- include/dfu.h | 71 +++++++++++++++++++++++ 18 files changed, 992 insertions(+), 87 deletions(-) create mode 100644 doc/README.dfu create mode 100644 drivers/dfu/dfu_mtd.c create mode 100644 drivers/dfu/dfu_virt.c

2 1

[U-Boot] [PULL] u-boot-mmc mmc-2019-11-5
by Peng Fan 06 Nov '19

06 Nov '19

Hi Tom, Please pull u-boot-mmc mmc-2019-11-5 CI: https://travis-ci.org/MrVan/u-boot/builds/607453537 ------------------------------------------------------- fsl_esdhc driver cleanup fsl_esdhc_imx driver improvement and compatible string update ------------------------------------------------------- Thanks, Peng. The following changes since commit 73b6e6ad254b36763419cdd3fdf406c0094517b7: Merge tag 'u-boot-imx-20191104' of https://gitlab.denx.de/u-boot/custodians/u-boot-imx (2019-11-04 12:57:41 -0500) are available in the Git repository at: https://gitlab.denx.de/u-boot/custodians/u-boot-mmc.git tags/mmc-2019-11-5 for you to fetch changes up to f65d08411d76f01ddfb5d44909c667b91b847ddf: mmc: fsl_esdhc_imx: Update compatible string for imx8m (2019-11-05 11:21:25 +0800) ---------------------------------------------------------------- Peng Fan (2): mmc: fsl_esdhc_imx: drop redundant clock settings mmc: fsl_esdhc_imx: Update compatible string for imx8m Yangbo Lu (7): mmc: fsl_esdhc: drop controller initialization in fsl_esdhc_init() mmc: fsl_esdhc: fix voltage validation mmc: fsl_esdhc: clean up bus width configuration code mmc: fsl_esdhc: convert to use fsl_esdhc_get_cfg_common() mmc: fsl_esdhc: drop redundant code for non-removable feature mmc: fsl_esdhc: always check write protect state mmc: fsl_esdhc: clean up DM and non-DM code drivers/mmc/fsl_esdhc.c | 370 ++++++++++++++++++++++++++++++++++++++++++++++++------------------------------------------------------------------------------------------------ drivers/mmc/fsl_esdhc_imx.c | 15 ++++-- include/fsl_esdhc.h | 14 +++--- 3 files changed, 139 insertions(+), 260 deletions(-)

2 1

[U-Boot] [PATCH] pinctrl: bcm283x: Add compatible for RPi4
by matthias.bgg＠kernel.org 06 Nov '19

06 Nov '19

From: Matthias Brugger <mbrugger(a)suse.com> The Raspberry Pi 4 upstream kernel device tree instroduces a new compatible for the pinctroller. Add this to the driver so that we can boot with the upstream kernel DT. Signed-off-by: Matthias Brugger <mbrugger(a)suse.com> --- drivers/pinctrl/broadcom/pinctrl-bcm283x.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/pinctrl/broadcom/pinctrl-bcm283x.c b/drivers/pinctrl/broadcom/pinctrl-bcm283x.c index 3be080d29e..8d9074e0c1 100644 --- a/drivers/pinctrl/broadcom/pinctrl-bcm283x.c +++ b/drivers/pinctrl/broadcom/pinctrl-bcm283x.c @@ -99,6 +99,7 @@ static int bcm283x_pinctrl_get_gpio_mux(struct udevice *dev, int banknum, static const struct udevice_id bcm2835_pinctrl_id[] = { {.compatible = "brcm,bcm2835-gpio"}, + {.compatible = "brcm,bcm2711-gpio"}, {} }; -- 2.23.0

1 0

[U-Boot] required host packages on Travis CI
by AKASHI Takahiro 06 Nov '19

06 Nov '19

Hi Tom, In test/py/README.md, all the required host packages and their versions to be used on 14.04(Trusty) are listed. On the other hand, ".travis.yml" names a similar but different list of packages. The latter also specifies the distribution to be used, which is xenial(16.04). * How would like to sync those two different lists? * Do you still think it appropriate to mention the "tested versions" in README.md at all? # I'm planning to update the list for UEFI secure boot test. -Takahiro Akashi

2 5

[U-Boot] [PATCH] rockchip: rk3399: rock960: Update config for TPL
by Peter Robinson 06 Nov '19

06 Nov '19

The SPL is now running at SDRAM, and 0x10000 is used by BL31, and the ARM SPL do not support relocate now, we need reserved 0x50000 so that it won't overwrite the code when we load the bl31 to target space. We should remove this after we enable the relocate feature. The SPL need malloc 0x9000 for MMC as buffer used for transfer data to IRAM(The EMMC DMA can not transfer data to IRAM directly). Signed-off-by: Peter Robinson <pbrobinson(a)gmail.com> --- configs/rock960-rk3399_defconfig | 10 +++++++--- 1 file changed, 7 insertions(+), 3 deletions(-) diff --git a/configs/rock960-rk3399_defconfig b/configs/rock960-rk3399_defconfig index cb3c68db6b..f211a65587 100644 --- a/configs/rock960-rk3399_defconfig +++ b/configs/rock960-rk3399_defconfig @@ -2,19 +2,21 @@ CONFIG_ARM=y CONFIG_ARCH_ROCKCHIP=y CONFIG_SYS_TEXT_BASE=0x00200000 CONFIG_ROCKCHIP_RK3399=y -CONFIG_ROCKCHIP_SPL_RESERVE_IRAM=0x4000 +CONFIG_ROCKCHIP_SPL_RESERVE_IRAM=0x50000 CONFIG_TARGET_ROCK960_RK3399=y CONFIG_SPL_STACK_R_ADDR=0x80000 CONFIG_DEBUG_UART_BASE=0xFF1A0000 CONFIG_DEBUG_UART_CLOCK=24000000 CONFIG_DEBUG_UART=y -CONFIG_SPL_TEXT_BASE=0xff8c2000 CONFIG_DEFAULT_FDT_FILE="rockchip/rk3399-rock960.dtb" # CONFIG_DISPLAY_CPUINFO is not set CONFIG_DISPLAY_BOARDINFO_LATE=y # CONFIG_SPL_RAW_IMAGE_SUPPORT is not set CONFIG_SPL_STACK_R=y -CONFIG_SPL_STACK_R_MALLOC_SIMPLE_LEN=0x4000 +CONFIG_SPL_STACK_R_MALLOC_SIMPLE_LEN=0x10000 +CONFIG_SPL_ATF=y +CONFIG_SPL_ATF_NO_PLATFORM_PARAM=y +CONFIG_TPL=y CONFIG_SYS_PROMPT="rock960 => " CONFIG_CMD_BOOTZ=y CONFIG_CMD_GPT=y @@ -56,4 +58,6 @@ CONFIG_USB_ETHER_ASIX88179=y CONFIG_USB_ETHER_MCS7830=y CONFIG_USB_ETHER_RTL8152=y CONFIG_USB_ETHER_SMSC95XX=y +CONFIG_USE_TINY_PRINTF=y +CONFIG_SPL_TINY_MEMSET=y CONFIG_ERRNO_STR=y -- 2.21.0

4 4