March 2019 - U-Boot

Re: [U-Boot] [REGRESSION] tegra124: nyan-big: LPAE not working
by Thierry Reding 04 Mar '19

04 Mar '19

On Mon, Feb 11, 2019 at 10:04:37AM +0000, Tristan Bastian wrote: > > > > Thierry Reding – Mon, 11. February 2019 10:38 > > On Mon, Feb 11, 2019 at 09:20:33AM +0000, Tristan Bastian wrote: > > > > > > Thierry Reding – Mon, 11. February 2019 9:52 > > > > On Sun, Feb 10, 2019 at 08:53:11PM +0100, Tristan Bastian wrote: > > > > > Thierry, do you have any news on this? > > > > > > > > > > I don't think, that google is going to push an updated version of > > coreboot > > > > > to each nyan-big device.. > > > > > So reverting this patch at least for the nyan devices would be the best > > I > > > > > think.. > > > > > > > > Yes, I agree. I had a brief chat with Rob Herring about this and he too > > > > agrees that we should revert it for now. I'll make it a manual revert > > > > and add a comment to the device tree node that will hopefully avoid any > > > > future janitorial "cleanups" of this sort. > > > > > > great news! :) > > > > > > > > BTW: I'm now running u-boot natively and it seems like u-boot always has > > a > > > > > problem with the memory.. > > > > > If u-boot is used chainloaded to coreboot it is only getting 2GB of > > memory > > > > > and running u-boot natively also just gives me 2GB.. > > > > > I've tested that with a kernel with "ARM: tegra: Fix unit_address_vs_reg > > DTC > > > > > warnings for /memory" reverted and also on a kernel, before this patch > > was > > > > > applied.. > > > > > > > > It's possible that U-Boot doesn't support LPAE and therefore may not be > > > > able to use more than the 2 GiB of memory. > > > > > > So I at least enabled LPAE in u-boot with "CONFIG_ARMV7_LPAE=y" and > > > this was for some reason also needed to get some output on the > > > display.. > > > I'm not sure why LPAE needs to activated in u-boot for display output > > > on the nyan-big.. > > > Without LPAE enabled u-boot was still working, and booted linux, but > > > u-boot didn't display anything on screen, linux then did.. > > > > Yeah, that's surprising. Perhaps without LPAE U-Boot thinks there's not > > enough memory for the framebuffer? There should be plenty, so maybe > > there is something else going on here. > > > > > > However, U-Boot should be > > > > able to tell the kernel exactly how much memory the system has and pass > > > > that on via device tree. That still does work, right? > > > > > > It seems like this is not working.. > > > And this seems to be the case with both, u-boot chainloaded and > > > running u-boot natively.. > > > > > > I've used these scripts for flashing: > > > github.com/NVIDIA/tegra-uboot-flasher-scripts > > > And used the norrin device since it seems like it is the nyan-big dev > > > board? > > > But going with the norrin device config should not be the issue here > > > since the problem also exists when chainloading u-boot, right? > > > > It could be a problem. The memory bank configuration is stored in what's > > called a BCT along with a bunch of other parameters that define what the > > memory controller needs to access the given memory chips. So if you've > > flashed a BCT that's for a board with only 2 GiB of memory you would end > > up with a system that can't address any more than that. It's somewhat > > surprising that memory accesses work at all with a BCT that's for > > different memory chips, but sometimes you can get lucky. > > > > You may want to try reflashing with the right BCT. The simplest would > > probably be to duplicate the cbootimage configuration for Norrin and > > substitute the relevant bits by what you have from the Chromebook flash > > utilities. Looks like the BCT in really the only thing you can replace > > there. Make sure to replace it with the one that matches your Chromebook > > and it should give you the right memory bank configuration. > > Is there a way to check if the correct bct for my 4GB model was used? > What I tried was to edit the existing bct config file of norrin from here: > https://github.com/NVIDIA/cbootimage-configs/blob/master/tegra124/nvidia/no… > by replacing all entries for each memory bank with the entries from here: > https://github.com/coreboot/coreboot/blob/master/src/mainboard/google/nyan_… > > I also added the SDRAM[0], SDRAM[1], SDRAM[2], SDRAM[3] each time in front of each line.. > This also booted for me, but also just leaves me with only 2Gb of my 4GB.. > > And since this problem also occurs, when chainloading u-boot, this must be a problem with u-boot, I think.. Not necessarily. U-Boot reads the memory size from EMC registers and those EMC registers are programmed based on the contents of the BCT. So if the BCT is wrong, then it's going to be wrong irrespective of what bootloader you use. That said, I does indeed look as if U-Boot only supports 2 GiB of memory on 32-bit Tegra. arch/arm/mach-tegra/board.c contains the relevant code. If you look at dram_init() it uses query_sdram_size() to get the size of RAM. That will allow to convey up to 4 GiB of RAM, but then the code in board2.c (see dram_init_banksize()) only uses a single bank on 32-bit Tegra (CONFIG_PHYS_64BIT is only set for 64-bit Tegra). According to the comments for dram_init_bank_size() we can't store the second bank because the .start field is 32 bits wide and therefore can't store the 0x100000000 start address for the bank. It sounds to me like ARMV7_LPAE should perhaps select PHYS_64BIT to make sure all the appropriate variables can store addresses beyond the 32-bit boundary. It's one thing to not support > 2 GiB of memory in U-Boot, but it's an entirely different story if we can't even pass > GiB of memory to the kernel if they exist. Stephen, do you remember if there was anything preventing us from going 64-bit for phys_addr_t and phys_size_t on LPAE enabled systems? Cc Tom for visibility and U-Boot since this is a U-Boot bug. Thierry > Tristan > > > > Simon Glass used his servo board to enter the tegrarcm mode: > > > patchwork.ozlabs.org/patch/1019003/ > > > > > > I had to erase the internal SPI flash in order to boot into the > > > tegrarcm mode.. > > > Do you have some instructions or internal documentation to tell me, if > > > some of the unpopulated buttons on the nyan-big mainboard can be used > > > to enter the tegrarcm state? > > > > You should be able to boot into recovery mode with the "enterrcm" > > command in U-Boot. I'm not aware of any buttons on the mainboard that > > can be used for this, unfortunately. > > > > Thierry

5 4

[U-Boot] [PATCH 1/9] pinctrl: renesas: Fix r8a779{5, 6, 65} assign to GP7_03/02 of GPSR7
by Marek Vasut 04 Mar '19

04 Mar '19

From: Hiroyuki Yokoyama <hiroyuki.yokoyama.vx(a)renesas.com> This patch is change the bit assignment of "HDMI1_CEC" to "GP7_03", and "HDMI0_CEC" to "GP7_02". This information was confirmed in the R-Car Gen3 Hardware Manual Rev.1.50. Signed-off-by: Hiroyuki Yokoyama <hiroyuki.yokoyama.vx(a)renesas.com> Signed-off-by: Marek Vasut <marek.vasut+renesas(a)gmail.com> Cc: Nobuhiro Iwamatsu <iwamatsu(a)nigauri.org> --- drivers/pinctrl/renesas/pfc-r8a7795.c | 55 ++++++++++++++------------- drivers/pinctrl/renesas/pfc-r8a7796.c | 42 +++++++++++++------- 2 files changed, 58 insertions(+), 39 deletions(-) diff --git a/drivers/pinctrl/renesas/pfc-r8a7795.c b/drivers/pinctrl/renesas/pfc-r8a7795.c index a6ecc0cabe..7c0990c2c7 100644 --- a/drivers/pinctrl/renesas/pfc-r8a7795.c +++ b/drivers/pinctrl/renesas/pfc-r8a7795.c @@ -2,7 +2,7 @@ /* * R8A7795 ES2.0+ processor support - PFC hardware block. * - * Copyright (C) 2015-2016 Renesas Electronics Corporation + * Copyright (C) 2015-2019 Renesas Electronics Corporation */ #include <common.h> @@ -202,8 +202,8 @@ #define GPSR6_0 F_(SSI_SCK01239, IP14_23_20) /* GPSR7 */ -#define GPSR7_3 FM(HDMI1_CEC) -#define GPSR7_2 FM(HDMI0_CEC) +#define GPSR7_3 FM(GP7_03) +#define GPSR7_2 FM(GP7_02) #define GPSR7_1 FM(AVS2) #define GPSR7_0 FM(AVS1) @@ -588,8 +588,8 @@ static const u16 pinmux_data[] = { PINMUX_SINGLE(AVS1), PINMUX_SINGLE(AVS2), PINMUX_SINGLE(CLKOUT), - PINMUX_SINGLE(HDMI0_CEC), - PINMUX_SINGLE(HDMI1_CEC), + PINMUX_SINGLE(GP7_02), + PINMUX_SINGLE(GP7_03), PINMUX_SINGLE(I2C_SEL_0_1), PINMUX_SINGLE(I2C_SEL_3_1), PINMUX_SINGLE(I2C_SEL_5_1), @@ -2126,20 +2126,23 @@ static const unsigned int du_disp_mux[] = { DU_DISP_MARK, }; -/* - HDMI ------------------------------------------------------------------- */ -static const unsigned int hdmi0_cec_pins[] = { - /* HDMI0_CEC */ +/* - GP7_02/03 -------------------------------------------------------------- */ +static const unsigned int gp7_02_pins[] = { + /* GP7_02 */ RCAR_GP_PIN(7, 2), }; -static const unsigned int hdmi0_cec_mux[] = { - HDMI0_CEC_MARK, + +static const unsigned int gp7_02_mux[] = { + GP7_02_MARK, }; -static const unsigned int hdmi1_cec_pins[] = { - /* HDMI1_CEC */ + +static const unsigned int gp7_03_pins[] = { + /* GP7_03 */ RCAR_GP_PIN(7, 3), }; -static const unsigned int hdmi1_cec_mux[] = { - HDMI1_CEC_MARK, + +static const unsigned int gp7_03_mux[] = { + GP7_03_MARK, }; /* - HSCIF0 ----------------------------------------------------------------- */ @@ -4230,8 +4233,8 @@ static const struct sh_pfc_pin_group pinmux_groups[] = { SH_PFC_PIN_GROUP(du_oddf), SH_PFC_PIN_GROUP(du_cde), SH_PFC_PIN_GROUP(du_disp), - SH_PFC_PIN_GROUP(hdmi0_cec), - SH_PFC_PIN_GROUP(hdmi1_cec), + SH_PFC_PIN_GROUP(gp7_02), + SH_PFC_PIN_GROUP(gp7_03), SH_PFC_PIN_GROUP(hscif0_data), SH_PFC_PIN_GROUP(hscif0_clk), SH_PFC_PIN_GROUP(hscif0_ctrl), @@ -4613,12 +4616,12 @@ static const char * const du_groups[] = { "du_disp", }; -static const char * const hdmi0_groups[] = { - "hdmi0_cec", +static const char * const gp7_02_groups[] = { + "gp7_02", }; -static const char * const hdmi1_groups[] = { - "hdmi1_cec", +static const char * const gp7_03_groups[] = { + "gp7_03", }; static const char * const hscif0_groups[] = { @@ -5027,8 +5030,8 @@ static const struct sh_pfc_function pinmux_functions[] = { SH_PFC_FUNCTION(drif2), SH_PFC_FUNCTION(drif3), SH_PFC_FUNCTION(du), - SH_PFC_FUNCTION(hdmi0), - SH_PFC_FUNCTION(hdmi1), + SH_PFC_FUNCTION(gp7_02), + SH_PFC_FUNCTION(gp7_03), SH_PFC_FUNCTION(hscif0), SH_PFC_FUNCTION(hscif1), SH_PFC_FUNCTION(hscif2), @@ -5749,8 +5752,8 @@ static const struct pinmux_drive_reg pinmux_drive_regs[] = { { RCAR_GP_PIN(0, 15), 24, 3 }, /* D15 */ { RCAR_GP_PIN(7, 0), 20, 3 }, /* AVS1 */ { RCAR_GP_PIN(7, 1), 16, 3 }, /* AVS2 */ - { RCAR_GP_PIN(7, 2), 12, 3 }, /* HDMI0_CEC */ - { RCAR_GP_PIN(7, 3), 8, 3 }, /* HDMI1_CEC */ + { RCAR_GP_PIN(7, 2), 12, 3 }, /* GP7_02 */ + { RCAR_GP_PIN(7, 3), 8, 3 }, /* GP7_03 */ { PIN_A_NUMBER('P', 7), 4, 2 }, /* DU_DOTCLKIN0 */ { PIN_A_NUMBER('P', 8), 0, 2 }, /* DU_DOTCLKIN1 */ } }, @@ -6004,8 +6007,8 @@ static const struct pinmux_bias_reg pinmux_bias_regs[] = { [25] = RCAR_GP_PIN(0, 15), /* D15 */ [26] = RCAR_GP_PIN(7, 0), /* AVS1 */ [27] = RCAR_GP_PIN(7, 1), /* AVS2 */ - [28] = RCAR_GP_PIN(7, 2), /* HDMI0_CEC */ - [29] = RCAR_GP_PIN(7, 3), /* HDMI1_CEC */ + [28] = RCAR_GP_PIN(7, 2), /* GP7_02 */ + [29] = RCAR_GP_PIN(7, 3), /* GP7_03 */ [30] = PIN_A_NUMBER('P', 7), /* DU_DOTCLKIN0 */ [31] = PIN_A_NUMBER('P', 8), /* DU_DOTCLKIN1 */ } }, diff --git a/drivers/pinctrl/renesas/pfc-r8a7796.c b/drivers/pinctrl/renesas/pfc-r8a7796.c index f73f67dad6..47184753f7 100644 --- a/drivers/pinctrl/renesas/pfc-r8a7796.c +++ b/drivers/pinctrl/renesas/pfc-r8a7796.c @@ -209,7 +209,7 @@ /* GPSR7 */ #define GPSR7_3 FM(GP7_03) -#define GPSR7_2 FM(HDMI0_CEC) +#define GPSR7_2 FM(GP7_02) #define GPSR7_1 FM(AVS2) #define GPSR7_0 FM(AVS1) @@ -596,7 +596,7 @@ static const u16 pinmux_data[] = { PINMUX_SINGLE(AVS2), PINMUX_SINGLE(CLKOUT), PINMUX_SINGLE(GP7_03), - PINMUX_SINGLE(HDMI0_CEC), + PINMUX_SINGLE(GP7_02), PINMUX_SINGLE(MSIOF0_RXD), PINMUX_SINGLE(MSIOF0_SCK), PINMUX_SINGLE(MSIOF0_TXD), @@ -2133,13 +2133,23 @@ static const unsigned int du_disp_mux[] = { DU_DISP_MARK, }; -/* - HDMI ------------------------------------------------------------------- */ -static const unsigned int hdmi0_cec_pins[] = { - /* HDMI0_CEC */ +/* - GP7_02/03 -------------------------------------------------------------- */ +static const unsigned int gp7_02_pins[] = { + /* GP7_02 */ RCAR_GP_PIN(7, 2), }; -static const unsigned int hdmi0_cec_mux[] = { - HDMI0_CEC_MARK, + +static const unsigned int gp7_02_mux[] = { + GP7_02_MARK, +}; + +static const unsigned int gp7_03_pins[] = { + /* GP7_03 */ + RCAR_GP_PIN(7, 3), +}; + +static const unsigned int gp7_03_mux[] = { + GP7_03_MARK, }; /* - HSCIF0 ----------------------------------------------------------------- */ @@ -4200,7 +4210,8 @@ static const struct sh_pfc_pin_group pinmux_groups[] = { SH_PFC_PIN_GROUP(du_oddf), SH_PFC_PIN_GROUP(du_cde), SH_PFC_PIN_GROUP(du_disp), - SH_PFC_PIN_GROUP(hdmi0_cec), + SH_PFC_PIN_GROUP(gp7_02), + SH_PFC_PIN_GROUP(gp7_03), SH_PFC_PIN_GROUP(hscif0_data), SH_PFC_PIN_GROUP(hscif0_clk), SH_PFC_PIN_GROUP(hscif0_ctrl), @@ -4578,8 +4589,12 @@ static const char * const du_groups[] = { "du_disp", }; -static const char * const hdmi0_groups[] = { - "hdmi0_cec", +static const char * const gp7_02_groups[] = { + "gp7_02", +}; + +static const char * const gp7_03_groups[] = { + "gp7_03", }; static const char * const hscif0_groups[] = { @@ -4975,7 +4990,8 @@ static const struct sh_pfc_function pinmux_functions[] = { SH_PFC_FUNCTION(drif2), SH_PFC_FUNCTION(drif3), SH_PFC_FUNCTION(du), - SH_PFC_FUNCTION(hdmi0), + SH_PFC_FUNCTION(gp7_02), + SH_PFC_FUNCTION(gp7_03), SH_PFC_FUNCTION(hscif0), SH_PFC_FUNCTION(hscif1), SH_PFC_FUNCTION(hscif2), @@ -5692,7 +5708,7 @@ static const struct pinmux_drive_reg pinmux_drive_regs[] = { { RCAR_GP_PIN(0, 15), 24, 3 }, /* D15 */ { RCAR_GP_PIN(7, 0), 20, 3 }, /* AVS1 */ { RCAR_GP_PIN(7, 1), 16, 3 }, /* AVS2 */ - { RCAR_GP_PIN(7, 2), 12, 3 }, /* HDMI0_CEC */ + { RCAR_GP_PIN(7, 2), 12, 3 }, /* GP7_02 */ { RCAR_GP_PIN(7, 3), 8, 3 }, /* GP7_03 */ { PIN_A_NUMBER('P', 7), 4, 2 }, /* DU_DOTCLKIN0 */ { PIN_A_NUMBER('P', 8), 0, 2 }, /* DU_DOTCLKIN1 */ @@ -5946,7 +5962,7 @@ static const struct pinmux_bias_reg pinmux_bias_regs[] = { [25] = RCAR_GP_PIN(0, 15), /* D15 */ [26] = RCAR_GP_PIN(7, 0), /* AVS1 */ [27] = RCAR_GP_PIN(7, 1), /* AVS2 */ - [28] = RCAR_GP_PIN(7, 2), /* HDMI0_CEC */ + [28] = RCAR_GP_PIN(7, 2), /* GP7_02 */ [29] = RCAR_GP_PIN(7, 3), /* GP7_03 */ [30] = PIN_A_NUMBER('P', 7), /* DU_DOTCLKIN0 */ [31] = PIN_A_NUMBER('P', 8), /* DU_DOTCLKIN1 */ -- 2.19.2

1 8

[U-Boot] [PATCH] ARM: imx6q_logic: Enable UUID support
by Adam Ford 03 Mar '19

03 Mar '19

With UUID support, the root can now point to UUID. This makes swiching between mmc 0 and mmc 1 easier by simplying changing mmcdev between 0 and 1. From there, the scripts handle the rest. Signed-off-by: Adam Ford <aford173(a)gmail.com> diff --git a/configs/imx6q_logic_defconfig b/configs/imx6q_logic_defconfig index 5017e5831b..b3ca44eb20 100644 --- a/configs/imx6q_logic_defconfig +++ b/configs/imx6q_logic_defconfig @@ -45,6 +45,7 @@ CONFIG_CMD_USB_SDP=y CONFIG_CMD_USB_MASS_STORAGE=y CONFIG_CMD_CACHE=y # CONFIG_CMD_LED is not set +CONFIG_CMD_UUID=y CONFIG_CMD_PMIC=y CONFIG_CMD_EXT4_WRITE=y CONFIG_CMD_MTDPARTS=y diff --git a/include/configs/imx6_logic.h b/include/configs/imx6_logic.h index 70cc63fc1b..e51b6a0931 100644 --- a/include/configs/imx6_logic.h +++ b/include/configs/imx6_logic.h @@ -23,7 +23,7 @@ /* MMC Configs */ #define CONFIG_SYS_FSL_ESDHC_ADDR 0 #define CONFIG_SYS_FSL_USDHC_NUM 2 -#define CONFIG_MMCROOT "/dev/mmcblk1p2" /* Dev kit SD card */ + /* Ethernet Configs */ #define CONFIG_FEC_XCV_TYPE RMII @@ -43,10 +43,10 @@ "console=" CONSOLE_DEV "\0" \ "mmcdev=1\0" \ "mmcpart=1\0" \ - "mmcroot=" CONFIG_MMCROOT " rootwait rw\0" \ + "finduuid=part uuid mmc ${mmcdev}:2 uuid\0" \ "nandroot=ubi0:rootfs rootfstype=ubifs\0" \ "mmcargs=setenv bootargs console=${console},${baudrate}" \ - " root=${mmcroot} ${mtdparts}\0" \ + " root=PARTUUID=${uuid} rootwait rw\0 ${mtdparts}\0" \ "nandargs=setenv bootargs console=${console},${baudrate}" \ " ubi.mtd=fs root=${nandroot} ${mtdparts}\0" \ "ramargs=setenv bootargs console=${console},${baudrate}" \ @@ -60,8 +60,8 @@ "loadfdt=fatload mmc ${mmcdev}:${mmcpart} ${fdt_addr_r} ${fdt_file}\0" \ "loadramdisk=fatload mmc ${mmcdev}:${mmcpart} ${ramdisk_addr_r}" \ " ${ramdisk_file}; setenv ramdisksize ${filesize}\0" \ - "mmcboot=echo Booting from mmc...; run mmcargs; run loadimage;" \ - " run loadfdt; bootz ${loadaddr} - ${fdt_addr_r}\0" \ + "mmcboot=echo Booting from mmc...; run finduuid; run mmcargs;" \ + "run loadimage; run loadfdt; bootz ${loadaddr} - ${fdt_addr_r}\0" \ "mmcramboot=run ramargs; run loadimage;" \ " run loadfdt; run loadramdisk;" \ " bootz ${loadaddr} ${ramdisk_addr_r} ${fdt_addr_r}\0" \ -- 2.17.1

1 0

[U-Boot] [PATCHv2] ARM: socfpga: fix data and tag latency values for pl310 cache controller
by Dinh Nguyen 03 Mar '19

03 Mar '19

The values for the data and tag latency settings on the PL310 caches controller is an (n-1). For example, the "arm,tag-latency" is specified as <1 1 1>, so the values that should be written to register should be 0x000. And for the "arm,data-latency" specified as <2 1 1>, the register value should be 0x010. Signed-off-by: Dinh Nguyen <dinguyen(a)kernel.org> --- arch/arm/mach-socfpga/misc.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arm/mach-socfpga/misc.c b/arch/arm/mach-socfpga/misc.c index fcf211d62b..ec8339e045 100644 --- a/arch/arm/mach-socfpga/misc.c +++ b/arch/arm/mach-socfpga/misc.c @@ -62,8 +62,8 @@ void v7_outer_cache_enable(void) /* Disable the L2 cache */ clrbits_le32(&pl310->pl310_ctrl, L2X0_CTRL_EN); - writel(0x111, &pl310->pl310_tag_latency_ctrl); - writel(0x121, &pl310->pl310_data_latency_ctrl); + writel(0x0, &pl310->pl310_tag_latency_ctrl); + writel(0x10, &pl310->pl310_data_latency_ctrl); /* enable BRESP, instruction and data prefetch, full line of zeroes */ setbits_le32(&pl310->pl310_aux_ctrl, -- 2.20.0

2 1

[U-Boot] [PATCH] arm64: dts: rockchip: Fix io power source for sdmmc0 on Firefly-RK3399
by Maruyama Shohei 03 Mar '19

03 Mar '19

From: Shohei Maruyama <cheat.sc.linux(a)outlook.com> This commit fixes the following error: Card did not respond to voltage select! The error occurs due to it does not describe correct io power source for the sdmmc0. Signed-off-by: Shohei Maruyama <cheat.sc.linux(a)outlook.com> --- arch/arm/dts/rk3399-firefly.dts | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/arch/arm/dts/rk3399-firefly.dts b/arch/arm/dts/rk3399-firefly.dts index f90e7e88db1..496be656d92 100644 --- a/arch/arm/dts/rk3399-firefly.dts +++ b/arch/arm/dts/rk3399-firefly.dts @@ -594,6 +594,14 @@ &sdmmc { u-boot,dm-pre-reloc; bus-width = <4>; + vqmmc-supply = <&vcc_sd>; + cap-mmc-highspeed; + cap-sd-highspeed; + cd-gpios = <&gpio0 RK_PA7 GPIO_ACTIVE_LOW>; + disable-wp; + max-frequency = <150000000>; + pinctrl-names = "default"; + pinctrl-0 = <&sdmmc_clk &sdmmc_cmd &sdmmc_bus4>; status = "okay"; }; -- 2.21.0

1 0

[U-Boot] Marvell DDR training custom ODT configuration
by Baruch Siach 03 Mar '19

03 Mar '19

Hi Chris, Currently the value of g_odt_config is hard coded in Marvell SoC platform headers. Some SolidRun A388 SOMs need a custom value. These SOMs use both DDR chip-selects, but ODT0 alone is connected to both chips. For that to work we need to set g_odt_config to 0x30000, that is, ODT0 is configured for both CS0 and CS1. How can we do that in a clean way so as to not interfere too much with your periodic code syncs from Marvell's DDR training source tree? Thanks, baruch -- http://baruch.siach.name/blog/ ~. .~ Tk Open Systems =}------------------------------------------------ooO--U--Ooo------------{= - baruch(a)tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -

2 3

[U-Boot] [v2] powerpc: t104xrdb: Add support of MTA9ADF1G72AZ DDR
by Peng Ma 03 Mar '19

03 Mar '19

T1040RDB has been upgraded to support new DDR ie. MTA9ADF1G72AZ-3G2, 8GB. So adding support of new DDR part by updating board_specific_parameters udimm0. Signed-off-by: Peng Ma <peng.ma(a)nxp.com> --- change for V2: - update comments and subject board/freescale/t104xrdb/ddr.h | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/board/freescale/t104xrdb/ddr.h b/board/freescale/t104xrdb/ddr.h index 319fc59..f9d667f 100644 --- a/board/freescale/t104xrdb/ddr.h +++ b/board/freescale/t104xrdb/ddr.h @@ -29,6 +29,7 @@ static const struct board_specific_parameters udimm0[] = { */ #ifdef CONFIG_SYS_FSL_DDR4 {2, 1600, 4, 8, 6, 0x07090A0c, 0x0e0f100a}, + {1, 1600, 4, 8, 5, 0x0607080B, 0x0C0C0D09}, #elif defined(CONFIG_SYS_FSL_DDR3) {2, 833, 4, 8, 6, 0x06060607, 0x08080807}, {2, 833, 0, 8, 6, 0x06060607, 0x08080807}, -- 1.7.1

2 1

[U-Boot] [PATCH v3 1/1] efi_loader: HII protocols: debug messages
by Heinrich Schuchardt 02 Mar '19

02 Mar '19

When package types are not supported by our implementation of the HII database protocol supported error messages are displayed. Essentially the output is only needed for debugging. By using EFI_PRINT() the messages are only written for in debug mode and with correct indentation. Signed-off-by: Heinrich Schuchardt <xypron.glpk(a)gmx.de> --- v3 Use EFI_PRINT() and add no further prefix. v2 Use "EFI HII:" as prefix. --- lib/efi_loader/efi_hii.c | 36 ++++++++++++++++++------------------ 1 file changed, 18 insertions(+), 18 deletions(-) diff --git a/lib/efi_loader/efi_hii.c b/lib/efi_loader/efi_hii.c index 0ed4b19633..3a966fa4df 100644 --- a/lib/efi_loader/efi_hii.c +++ b/lib/efi_loader/efi_hii.c @@ -388,7 +388,7 @@ add_packages(struct efi_hii_packagelist *hii, (struct efi_hii_guid_package *)package); break; case EFI_HII_PACKAGE_FORMS: - printf("\tForm package not supported\n"); + EFI_PRINT("Form package not supported\n"); ret = EFI_INVALID_PARAMETER; break; case EFI_HII_PACKAGE_STRINGS: @@ -396,19 +396,19 @@ add_packages(struct efi_hii_packagelist *hii, (struct efi_hii_strings_package *)package); break; case EFI_HII_PACKAGE_FONTS: - printf("\tFont package not supported\n"); + EFI_PRINT("Font package not supported\n"); ret = EFI_INVALID_PARAMETER; break; case EFI_HII_PACKAGE_IMAGES: - printf("\tImage package not supported\n"); + EFI_PRINT("Image package not supported\n"); ret = EFI_INVALID_PARAMETER; break; case EFI_HII_PACKAGE_SIMPLE_FONTS: - printf("\tSimple font package not supported\n"); + EFI_PRINT("Simple font package not supported\n"); ret = EFI_INVALID_PARAMETER; break; case EFI_HII_PACKAGE_DEVICE_PATH: - printf("\tDevice path package not supported\n"); + EFI_PRINT("Device path package not supported\n"); ret = EFI_INVALID_PARAMETER; break; case EFI_HII_PACKAGE_KEYBOARD_LAYOUT: @@ -416,7 +416,7 @@ add_packages(struct efi_hii_packagelist *hii, (struct efi_hii_keyboard_package *)package); break; case EFI_HII_PACKAGE_ANIMATIONS: - printf("\tAnimation package not supported\n"); + EFI_PRINT("Animation package not supported\n"); ret = EFI_INVALID_PARAMETER; break; case EFI_HII_PACKAGE_END: @@ -522,33 +522,33 @@ update_package_list(const struct efi_hii_database_protocol *this, remove_guid_package(hii); break; case EFI_HII_PACKAGE_FORMS: - printf("\tForm package not supported\n"); + EFI_PRINT("Form package not supported\n"); ret = EFI_INVALID_PARAMETER; break; case EFI_HII_PACKAGE_STRINGS: remove_strings_package(hii); break; case EFI_HII_PACKAGE_FONTS: - printf("\tFont package not supported\n"); + EFI_PRINT("Font package not supported\n"); ret = EFI_INVALID_PARAMETER; break; case EFI_HII_PACKAGE_IMAGES: - printf("\tImage package not supported\n"); + EFI_PRINT("Image package not supported\n"); ret = EFI_INVALID_PARAMETER; break; case EFI_HII_PACKAGE_SIMPLE_FONTS: - printf("\tSimple font package not supported\n"); + EFI_PRINT("Simple font package not supported\n"); ret = EFI_INVALID_PARAMETER; break; case EFI_HII_PACKAGE_DEVICE_PATH: - printf("\tDevice path package not supported\n"); + EFI_PRINT("Device path package not supported\n"); ret = EFI_INVALID_PARAMETER; break; case EFI_HII_PACKAGE_KEYBOARD_LAYOUT: remove_keyboard_package(hii); break; case EFI_HII_PACKAGE_ANIMATIONS: - printf("\tAnimation package not supported\n"); + EFI_PRINT("Animation package not supported\n"); ret = EFI_INVALID_PARAMETER; break; case EFI_HII_PACKAGE_END: @@ -609,7 +609,7 @@ list_package_lists(const struct efi_hii_database_protocol *this, break; continue; case EFI_HII_PACKAGE_FORMS: - printf("\tForm package not supported\n"); + EFI_PRINT("Form package not supported\n"); ret = EFI_INVALID_PARAMETER; continue; case EFI_HII_PACKAGE_STRINGS: @@ -617,19 +617,19 @@ list_package_lists(const struct efi_hii_database_protocol *this, break; continue; case EFI_HII_PACKAGE_FONTS: - printf("\tFont package not supported\n"); + EFI_PRINT("Font package not supported\n"); ret = EFI_INVALID_PARAMETER; continue; case EFI_HII_PACKAGE_IMAGES: - printf("\tImage package not supported\n"); + EFI_PRINT("Image package not supported\n"); ret = EFI_INVALID_PARAMETER; continue; case EFI_HII_PACKAGE_SIMPLE_FONTS: - printf("\tSimple font package not supported\n"); + EFI_PRINT("Simple font package not supported\n"); ret = EFI_INVALID_PARAMETER; continue; case EFI_HII_PACKAGE_DEVICE_PATH: - printf("\tDevice path package not supported\n"); + EFI_PRINT("Device path package not supported\n"); ret = EFI_INVALID_PARAMETER; continue; case EFI_HII_PACKAGE_KEYBOARD_LAYOUT: @@ -637,7 +637,7 @@ list_package_lists(const struct efi_hii_database_protocol *this, break; continue; case EFI_HII_PACKAGE_ANIMATIONS: - printf("\tAnimation package not supported\n"); + EFI_PRINT("Animation package not supported\n"); ret = EFI_INVALID_PARAMETER; continue; case EFI_HII_PACKAGE_END: -- 2.20.1

1 0

[U-Boot] [PATCH 1/1] efi_loader: HII protocols: fix new_package_list()
by Heinrich Schuchardt 02 Mar '19

02 Mar '19

In new_package_list() we call new_packagelist() to create a new package list. Next we try to add the packages which fails for form packages. Due to this error we call free_packagelist(). Now in free_packagelist() list_del() is called for an uninitialized field hii->link. This leads to changing random memory addresses. To solve the problem move the initialization of hii->link to new_packagelist(). Signed-off-by: Heinrich Schuchardt <xypron.glpk(a)gmx.de> --- @Takahiro: Please, review the patch. --- lib/efi_loader/efi_hii.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lib/efi_loader/efi_hii.c b/lib/efi_loader/efi_hii.c index d63d2d84184..0ed4b196333 100644 --- a/lib/efi_loader/efi_hii.c +++ b/lib/efi_loader/efi_hii.c @@ -343,6 +343,7 @@ static struct efi_hii_packagelist *new_packagelist(void) struct efi_hii_packagelist *hii; hii = malloc(sizeof(*hii)); + list_add_tail(&hii->link, &efi_package_lists); hii->max_string_id = 0; INIT_LIST_HEAD(&hii->string_tables); INIT_LIST_HEAD(&hii->guid_list); @@ -465,7 +466,6 @@ new_package_list(const struct efi_hii_database_protocol *this, } hii->driver_handle = driver_handle; - list_add_tail(&hii->link, &efi_package_lists); *handle = hii; return EFI_EXIT(EFI_SUCCESS); -- 2.20.1

4 4

[U-Boot] [PATCH 1/1] efi_loader: error handling for `efidebug boot add`
by Heinrich Schuchardt 02 Mar '19

02 Mar '19

In `efidebug boot add iPXE scsi 0:1 snp-arm64.efi --foo` a parameter is missing. Hence the command should not silently return as if everything were ok but should display the usage info. Signed-off-by: Heinrich Schuchardt <xypron.glpk(a)gmx.de> --- cmd/efidebug.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/cmd/efidebug.c b/cmd/efidebug.c index 5072a7b39bc..db96682c5a4 100644 --- a/cmd/efidebug.c +++ b/cmd/efidebug.c @@ -491,7 +491,7 @@ static int do_efi_boot_add(cmd_tbl_t *cmdtp, int flag, id = (int)simple_strtoul(argv[1], &endp, 16); if (*endp != '\0' || id > 0xffff) - return CMD_RET_FAILURE; + return CMD_RET_USAGE; sprintf(var_name, "Boot%04X", id); p = var_name16; -- 2.20.1

2 1