January 2019 - U-Boot

[U-Boot] [PATCH v2] misc: fs_loader: Add support for initializing MMC
by tien.fong.chee＠intel.com 10 Jan '19

10 Jan '19

From: Tien Fong Chee <tien.fong.chee(a)intel.com> Firmware loader would encounter problem if the MMC is accessed before initializing it. This patch would adding the support of probing block device and initializing MMC before the MMC is accessed by firmware loader. Signed-off-by: Tien Fong Chee <tien.fong.chee(a)intel.com> --- Changes in v2: - Initializing MMC through probing the blk device --- drivers/misc/fs_loader.c | 33 +++++++++++++++++++++++++++++++++ 1 file changed, 33 insertions(+) diff --git a/drivers/misc/fs_loader.c b/drivers/misc/fs_loader.c index 57a14a3..5858073 100644 --- a/drivers/misc/fs_loader.c +++ b/drivers/misc/fs_loader.c @@ -12,6 +12,7 @@ #include <linux/string.h> #include <mapmem.h> #include <malloc.h> +#include <mmc.h> #include <spl.h> DECLARE_GLOBAL_DATA_PTR; @@ -252,6 +253,38 @@ static int fs_loader_ofdata_to_platdata(struct udevice *dev) static int fs_loader_probe(struct udevice *dev) { +#if defined(CONFIG_DM_MMC) && defined(CONFIG_BLK) + int ret; + struct device_platdata *plat = dev->platdata; + + ret = mmc_initialize(NULL); + if (ret) { + debug("MMC: could not initialize mmc. error: %d\n", ret); + + return ret; + } + + if (plat->phandlepart.phandle) { + ofnode node = ofnode_get_by_phandle(plat->phandlepart.phandle); + + struct udevice *mmc_dev = NULL; + + ret = device_get_global_by_ofnode(node, &mmc_dev); + if (!ret) { + struct mmc *mmc = mmc_get_mmc_dev(mmc_dev); + struct udevice *dev; + + ret = blk_get_from_parent(mmc->dev, &dev); + if (ret) { + debug("MMC: No block device: %d\n", + ret); + + return ret; + } + } + } +#endif + return 0; }; -- 2.2.0

3 4

[U-Boot] Issue with memcpy when booting a fitImage on SPEAr600
by Quentin Schulz 10 Jan '19

10 Jan '19

Hello everyone, I'm working on porting a mainline U-Boot on a custom board based on a SPEAr600. Right now, I'm facing an issue related with fitImage booting. Before starting on the fitImage issue, let me state that the zImage and the custom DTB concatenated in a uImage have the load address and entry point be respectively 0x0200.0000 and 0x0200.0040. The fitImage load and entry are both 0x0200.0000. The uImage loaded at the address 0x0080.0000 is booted fine by U-Boot, the fitImage at the same address, not. The datasheet of the SoC states that the external SDRAM is located between 0x0000.0000 and 0x3fff.ffff. The size of the fitImage is currently 0x0038.9484 bytes, the uImage 0x0038.9007. The fitImage booting abruptly stops right after "Loading Device Tree to 0778a000, end 0778e7d6 ... OK" with the following trace: "prefetch abort pc : [<f188af44>] lr : [<07fca8c7>] reloc pc : [<ed7f8f44>] lr : [<03f388c7>] sp : 0778fb78 ip : fffc4c98 fp : 03f00020 r10: deadbeef r9 : 0778ff00 r8 : 07f922a0 r7 : 00ff0000 r6 : 000047d7 r5 : 00004700 r4 : 0778a1b8 r3 : 00000008 r2 : 000016c4 r1 : 0778a1b8 r0 : 0778a1b8 Flags: nZCv IRQs off FIQs off Mode SVC_32 Code: data abort pc : [<07f931c6>] lr : [<07fb2dd1>] reloc pc : [<03f011c6>] lr : [<03f20dd1>] sp : 0778fa80 ip : 00000114 fp : 03f00020 r10: deadbeef r9 : 0778ff00 r8 : 07f922a0 r7 : 60000000 r6 : 00000698 r5 : f188af44 r4 : fffffffc r3 : fffffff0 r2 : 0778ff00 r1 : 00000020 r0 : 00000006 Flags: NzCv IRQs on FIQs on Mode SVC_32 Code: 23036be5 439d4818 f885f038 42642404 (595a00a3) Resetting CPU ... resetting ... System is going to reboot ..." I've narrowed down the issue to a memmove being called with destination pointer being the source pointer. If I print a debug message before and after this memcpy[1], the first debug message is printed but not the second one. If I add a condition for (dest == src) return dest in the very beginning of memmove, the fitImage boots just fine. This test seemed to have been removed by commit cb0eae8cf8aaca76910dee4c7eb536d0814d1bd2[12], and by reverting this commit, I was able to successfuly boot Linux with a fitImage. Here is the log without debug messages WITHOUT the dest == src check in memmove: U-Boot 2018.11-00007-g0b16f8424a-dirty (Dec 05 2018 - 09:23:31 +0100)-SPEAr CPU: SPEAr600 DRAM: 128 MiB Flash: 512 KiB NAND: 128 MiB Loading Environment from Flash... OK Net: dwmac.e0800000 Hit SPACE in 3 seconds to stop autoboot. => dhcp; tftp fitImage; bootm Speed: 100, full duplex BOOTP broadcast 1 DHCP client bound to address 192.168.0.169 (3 ms) Speed: 100, full duplex Using dwmac.e0800000 device TFTP from server 192.168.0.13; our IP address is 192.168.0.169 Filename 'fitImage'. Load address: 0x800000 Loading: ################################################################# ################################################################# ################################################################# ########################################################## 5.5 MiB/s done Bytes transferred = 3708036 (389484 hex) ## Loading kernel from FIT Image at 00800000 ... Using 'conf@default' configuration Trying 'kernel@0' kernel subimage Description: Linux Type: Kernel Image Compression: uncompressed Data Start: 0x008000b0 Data Size: 3700720 Bytes = 3.5 MiB Architecture: ARM OS: Linux Load Address: 0x02000000 Entry Point: 0x02000000 Hash algo: sha1 Hash value: efe249f573647bad3ce87c9c4b244986a90234db ## Loading fdt from FIT Image at 00800000 ... Using 'conf@default' configuration Trying 'fdt@0' fdt subimage Description: Device Tree Type: Flat Device Tree Compression: uncompressed Data Start: 0x00b87984 Data Size: 6103 Bytes = 6 KiB Architecture: ARM Hash algo: sha1 Hash value: 53089fa031e727f094e6bf9ad4e93f4e95b7fba3 Booting using the fdt blob at 0xb87984 Loading Kernel Image ... OK Loading Device Tree to 0778a000, end 0778e7d6 ... OK prefetch abort pc : [<f188af44>] lr : [<07fca8c7>] reloc pc : [<ed7f8f44>] lr : [<03f388c7>] sp : 0778fb78 ip : fffc4c98 fp : 03f00020 r10: deadbeef r9 : 0778ff00 r8 : 07f922a0 r7 : 00ff0000 r6 : 000047d7 r5 : 00004700 r4 : 0778a1b8 r3 : 00000008 r2 : 000016c4 r1 : 0778a1b8 r0 : 0778a1b8 Flags: nZCv IRQs off FIQs off Mode SVC_32 Code: data abort pc : [<07f931c6>] lr : [<07fb2dd1>] reloc pc : [<03f011c6>] lr : [<03f20dd1>] sp : 0778fa80 ip : 00000114 fp : 03f00020 r10: deadbeef r9 : 0778ff00 r8 : 07f922a0 r7 : 60000000 r6 : 00000698 r5 : f188af44 r4 : fffffffc r3 : fffffff0 r2 : 0778ff00 r1 : 00000020 r0 : 00000006 Flags: NzCv IRQs on FIQs on Mode SVC_32 Code: 23036be5 439d4818 f885f038 42642404 (595a00a3) Resetting CPU ... resetting ... System is going to reboot ... With debug messages (_DEBUG = 1 and a few printf("%s: %d\n", __func__, __LINE__);): => dhcp; tftp fitImage; bootm Trying dwmac.e0800000 Speed: 100, full duplex BOOTP broadcast 1 DHCPHandler: got packet: (src=67, dst=68, len=300) state: 3 Filtering pkt = 0 DHCPHandler: got DHCP packet: (src=67, dst=68, len=300) state: 3 DHCP: state=SELECTING bp_file: "" TRANSITIONING TO REQUESTING STATE dhcp_send_request_packet: Sending DHCPREQUEST Transmitting DHCPREQUEST packet: len = 342 DHCPHandler: got packet: (src=67, dst=68, len=300) state: 4 Filtering pkt = 0 DHCPHandler: got DHCP packet: (src=67, dst=68, len=300) state: 4 DHCP State: REQUESTING net_boot_file_name: DHCP client bound to address 192.168.0.169 (21 ms) Initial value for argc=3 Final value for argc=3 Initial value for argc=3 Final value for argc=3 Initial value for argc=3 Final value for argc=3 Initial value for argc=3 Final value for argc=3 Initial value for argc=3 Final value for argc=3 Initial value for argc=3 Final value for argc=3 Trying dwmac.e0800000 Speed: 100, full duplex TFTP blocksize = 1468, timeout = 5000 ms Using dwmac.e0800000 device TFTP from server 192.168.0.13; our IP address is 192.168.0.169 Filename 'fitImage'. Load address: 0x800000 Loading: send option "timeout 5" Got OACK: timeout 5 Blocksize ack: 1468, 1468 ################################################################# ################################################################# ################################################################# ########################################################## 5.3 MiB/s done Bytes transferred = 3708036 (389484 hex) Initial value for argc=3 Final value for argc=3 Initial value for argc=3 Final value for argc=3 Initial value for argc=3 Final value for argc=3 Initial value for argc=3 Final value for argc=3 Initial value for argc=3 Final value for argc=3 Initial value for argc=3 Final value for argc=3 Initial value for argc=3 Final value for argc=3 ## Current stack ends at 0x0778dd04 * kernel: default image load address = 0x00800000 ## Loading kernel from FIT Image at 00800000 ... No configuration specified, trying default... Found default configuration: 'conf@default' Using 'conf@default' configuration Trying 'kernel@0' kernel subimage Description: Linux Type: Kernel Image Compression: uncompressed Data Start: 0x008000b0 Data Size: 3700720 Bytes = 3.5 MiB Architecture: ARM OS: Linux Load Address: 0x02000000 Entry Point: 0x02000000 Hash node: 'hash@0' Hash algo: sha1 Hash value: efe249f573647bad3ce87c9c4b244986a90234db Hash len: 20 kernel data at 0x008000b0, len = 0x003877f0 (3700720) * ramdisk: using config 'conf@default' from image at 0x00800000 * ramdisk: no 'ramdisk' in config * fdt: using config 'conf@default' from image at 0x00800000 ## Checking for 'FDT'/'FDT Image' at 00800000 ## Loading fdt from FIT Image at 00800000 ... Using 'conf@default' configuration Trying 'fdt@0' fdt subimage Description: Device Tree Type: Flat Device Tree Compression: uncompressed Data Start: 0x00b87984 Data Size: 6103 Bytes = 6 KiB Architecture: ARM Can't get 'load' property from FIT 0x00800000, node: offset 3701020, name fdt@0 (FDT_ERR_NOTFOUND) Hash node: 'hash@0' Hash algo: sha1 Hash value: 53089fa031e727f094e6bf9ad4e93f4e95b7fba3 Hash len: 20 Can't get 'load' property from FIT 0x00800000, node: offset 3701020, name fdt@0 (FDT_ERR_NOTFOUND) fit_uname=fdt@0, fit_uname_config=conf@default Booting using the fdt blob at 0xb87984 of_flat_tree at 0x00b87984 size 0x000017d7 Initial value for argc=3 Final value for argc=3 Loading Kernel Image ... OK kernel loaded at 0x02000000, end = 0x023877f0 ## initrd_high = 0x08000000, copy_to_ram = 1 ramdisk load start = 0x00000000, ramdisk load end = 0x00000000 Initial value for argc=3 Final value for argc=3 Initial value for argc=3 Final value for argc=3 using: FDT ## device tree at 00b87984 ... 00b8915a (len=18391 [0x47D7]) Loading Device Tree to 07788000, end 0778c7d6 ... OK Initial value for argc=3 Final value for argc=3 image_setup_linux: 1511 fdt_setprop: 300 fdt_setprop_placeholder: 283 fdt_splice_: 108 fdt_splice_struct_: 132 fdt_splice_: 108 image_setup_libfdt: 480 arch_fixup_fdt: 54 fdt_fixup_memory_banks: 440 fdt_setprop: 300 fdt_setprop_placeholder: 283 fdt_resize_property_: 215 fdt_splice_struct_: 132 fdt_splice_: 108 memmove: 547 dest=0x77881b8 src=0x77881b8 size=0x16c4 undefined instruction pc : [<07fc9534>] lr : [<07fc9537>] reloc pc : [<03f39534>] lr : [<03f39537>] sp : 0778db58 ip : fffc3f40 fp : 03f00020 r10: deadbeef r9 : 0778df00 r8 : 07f902a0 r7 : 00ff0000 r6 : 077881b8 r5 : 077881b8 r4 : 000016c4 r3 : 07fc952d r2 : 000016c4 r1 : 077881b8 r0 : 077881b8 Flags: nZCv IRQs off FIQs off Mode SVC_32 Code: 48094908 fd17f000 00310022 f0030028 (0028faf1) Resetting CPU ... resetting ... System is going to reboot ... Basically, the error path is: image_setup_linux[2]->image_setup_libfdt[3]->arch_fixup_fdt[4]-> fdt_fixup_memory_banks[5]->fdt_setprop[6]->fdt_setprop_placeholder[7]-> fdt_resize_property_[8]->fdt_splice_struct_[9]->fdt_splice_[10]-> memmove[11]->memcpy The bootloader build is marked as dirty but I'm only adding files (board C and header files, board defconfig, etc...) for board support, no modifications otherwise, it's based on 2018.11. It's weird to me that it's happening with this SoC because it's based on ARM926ejs which is widely used I assume. Shouldn't have anyone already encountered the bug? Or is nobody actually booting a fitImage and had the luck to never call memcpy with src == dest anywhere else in the code? Let me know if I can be of any help for debugging. Thanks, Quentin [1] https://elixir.bootlin.com/u-boot/latest/source/lib/string.c#L547 [2] https://elixir.bootlin.com/u-boot/latest/source/common/image.c#L1511 [3] https://elixir.bootlin.com/u-boot/latest/source/common/image-fdt.c#L480 [4] https://elixir.bootlin.com/u-boot/latest/source/arch/arm/lib/bootm-fdt.c#L54 [5] https://elixir.bootlin.com/u-boot/latest/source/common/fdt_support.c#L440 [6] https://elixir.bootlin.com/u-boot/latest/source/scripts/dtc/libfdt/fdt_rw.c… [7] https://elixir.bootlin.com/u-boot/latest/source/scripts/dtc/libfdt/fdt_rw.c… [8] https://elixir.bootlin.com/u-boot/latest/source/scripts/dtc/libfdt/fdt_rw.c… [9] https://elixir.bootlin.com/u-boot/latest/source/scripts/dtc/libfdt/fdt_rw.c… [10] https://elixir.bootlin.com/u-boot/latest/source/scripts/dtc/libfdt/fdt_rw.c… [11] https://elixir.bootlin.com/u-boot/latest/source/lib/string.c#L547 [12] http://git.denx.de/?p=u-boot.git;a=commit;h=cb0eae8cf8aaca76910dee4c7eb536d…

4 6

[U-Boot] [PATCH 0/3] Introduce regulator_set_enable_if_allowed()
by Lokesh Vutla 10 Jan '19

10 Jan '19

As per the discussion happenned here[1], introducing a new api regulator_set_enable_if_allowed() that discards certain error cases where consumer driver might not be intrested in. Also using the same api for omap_hsmmc driver which fixes the boot on dra7-evm. [1] https://patchwork.ozlabs.org/patch/1018222/ Lokesh Vutla (3): Revert "power: regulator: Return success on attempt to disable an always-on regulator" power: regulator: Introduce regulator_set_enable_if_allowed api mmc: omap_hsmmc: Use regulator_set_enable_if_allowed for enabling regulator drivers/mmc/omap_hsmmc.c | 16 ++++++++-------- drivers/power/regulator/regulator-uclass.c | 13 ++++++++++++- include/power/regulator.h | 11 +++++++++++ 3 files changed, 31 insertions(+), 9 deletions(-) -- 2.19.2

2 6

[U-Boot] Issue with compiling uboot for SoC-eds arria 10
by Sujay Suresh 10 Jan '19

10 Jan '19

Hi, I am trying to compile uboot in my linux machine but the 2 bin file needed are not generating, instead I get these errors as in the picture enclosed. Please Provide your support. Best.

2 1

[U-Boot] [PATCH v1] tools: logos: crop Toradex logo slightly
by Stefan Agner 10 Jan '19

10 Jan '19

From: Stefan Agner <stefan.agner(a)toradex.com> The current bitmap is a bit larger than necessary, it has a black border around the Toradex logo. Crop the logo slightly which safes some space, useful especially on Colibri VFxx. Signed-off-by: Stefan Agner <stefan.agner(a)toradex.com> --- tools/logos/toradex.bmp | Bin 24982 -> 23298 bytes 1 file changed, 0 insertions(+), 0 deletions(-) diff --git a/tools/logos/toradex.bmp b/tools/logos/toradex.bmp index 3e2dcf23358dd46fc7b1bb0dae70d3ba985606ee..8b5cb18e8475b3eda72c9f0e821b2aad17bc1bae 100644 GIT binary patch delta 505 zcmYLEO-oxr6rCd>(HDKjZ>@>Jpis10rD|SMpO}a~;ztZ>#n#YvXDMP^LN{G@Ros~Y z7ZzGv2rXT;2fM2V{0-tp-MG+&1*NzVD!qwH2j<L~d(J&`XLSefe<B*6D4JJ=_0FZ# zqA&|eIdVc37wR8om8$e!Zz<*l6?djGE9YG(S~;)!9=&quRG=vfFLUm4-15@m|9r0G zmizeCFm60Pec_#Ey3_){ltsV`(*{R;a?MtR!GlVHyVU}jnm+JXtq3Lc0*@L5*6#@X zZWM?FBG5Uvi_1-;;7M@9V643tT)ro*yB*RRyf5r!m%wIs7(X6Z&}P4>2dpwK^!TCA z#vApR)u#7*|L~|!Y@L=^>|}#ZB|Th=)POrtDVzOa=q<<Og53sg4CGC*R@M$yfp)Br zTCNWr4?o94(4CgaqoH;%G%TNcHS!SLa%5g3A@fQ&UylZ%jYNRCF+X@VE-pJ+(CWB8 zDGB)@pZ0ionrZ=CrbK@;9R;^%B+8u4K>wYo&*H6Kdi+g)O1ODE*9`if$Qv)_#k`r8 Tu-(CC?xpL%<TJT_e17>4;b52` delta 656 zcmXw!ODIHP6vw|?uE!njFhgTzOi3nYyasb;yv8sxo^!iK9tlwv3RzGrG(|QZDZa9j zB?~JZ+1My$i;az@WKD$CWZ~X(xb^k>&j0++`QLBjQaHR3{E^t<G{Y~D##p(2>lYa7 z)+w+|)TbsGvzX}UqTV=PO%wUG_^qEgSQ8tBeJ!7_i5^I%n~giXW{@^6RYN>W!v46l zZnTmTwxA%p5v^)Y2)QGZeq#<|oysNFT8OjO0P4s2<a;b2$~I!OkeIL&FCDc1-KiRL zf{70}efyfocU>k(xMn2%=P%%;Ou?--52dJHO4+QS`l^!nSw-~J;C6l%lwr~5F=qKz zmy?(Jy*yd_Wjye{4y`=ZDsxrI1-IXU5n+X*mIJivEJ(i7hzuVMUi3JcX#IAJ8&;aF zsBO3WN1EXwgprVHrN`B`5$D^R(R&&puNHN|Pe+lV@v!3JlZpi4&OG#JQJUH6Lh5}x zJarfUd2L|nEy26~M84?DfS$fmoLlIpxszBE*3T+sI<+ON_XaQ<ZsTQGzYS9D9-_I) WVdOzbgrkvqwA_u-FJz9T1ojITOUl0h -- 2.19.2

4 14

[U-Boot] [PATCH v2] mmc: sunxi: Fix mmc clocks for DM_MMC
by Jagan Teki 10 Jan '19

10 Jan '19

Existing clock configure code has been followed based on the legacy MMC dt node definitions and it cannot work with recent dts(i) sync from Linux. So, add clock configure code for Allwinner platforms which support DM_MMC and eventually this will drop once CLK support is in Mainline. Fixes: 3c92cca3cda0 ("ARM: dts: sun4i: Update A10 dts(i) files from Linux-v4.18-rc3") Signed-off-by: Jagan Teki <jagan(a)amarulasolutions.com> --- Changes for v2: - Use u16 for gate and mclk offset, since future support for H6 drivers/mmc/sunxi_mmc.c | 50 ++++++++++++++++++++++++++++++----------- 1 file changed, 37 insertions(+), 13 deletions(-) diff --git a/drivers/mmc/sunxi_mmc.c b/drivers/mmc/sunxi_mmc.c index 9bf040cb40..302332bf97 100644 --- a/drivers/mmc/sunxi_mmc.c +++ b/drivers/mmc/sunxi_mmc.c @@ -19,6 +19,13 @@ #include <asm/arch/mmc.h> #include <asm-generic/gpio.h> +#ifdef CONFIG_DM_MMC +struct sunxi_mmc_variant { + u16 gate_offset; + u16 mclk_offset; +}; +#endif + struct sunxi_mmc_plat { struct mmc_config cfg; struct mmc mmc; @@ -32,6 +39,9 @@ struct sunxi_mmc_priv { int cd_inverted; /* Inverted Card Detect */ struct sunxi_mmc *reg; struct mmc_config cfg; +#ifdef CONFIG_DM_MMC + const struct sunxi_mmc_variant *variant; +#endif }; #if !CONFIG_IS_ENABLED(DM_MMC) @@ -599,7 +609,7 @@ static int sunxi_mmc_probe(struct udevice *dev) struct sunxi_mmc_priv *priv = dev_get_priv(dev); struct mmc_config *cfg = &plat->cfg; struct ofnode_phandle_args args; - u32 *gate_reg; + u32 *gate_reg, *ccu_reg; int bus_width, ret; cfg->name = dev->name; @@ -618,21 +628,21 @@ static int sunxi_mmc_probe(struct udevice *dev) cfg->f_max = 52000000; priv->reg = (void *)dev_read_addr(dev); + priv->variant = + (const struct sunxi_mmc_variant *)dev_get_driver_data(dev); /* We don't have a sunxi clock driver so find the clock address here */ ret = dev_read_phandle_with_args(dev, "clocks", "#clock-cells", 0, 1, &args); if (ret) return ret; - priv->mclkreg = (u32 *)ofnode_get_addr(args.node); + ccu_reg = (u32 *)ofnode_get_addr(args.node); - ret = dev_read_phandle_with_args(dev, "clocks", "#clock-cells", 0, - 0, &args); - if (ret) - return ret; - gate_reg = (u32 *)ofnode_get_addr(args.node); - setbits_le32(gate_reg, 1 << args.args[0]); - priv->mmc_no = args.args[0] - 8; + priv->mmc_no = ((uintptr_t)priv->reg - SUNXI_MMC0_BASE) / 0x1000; + priv->mclkreg = (void *)ccu_reg + + (priv->variant->mclk_offset + (priv->mmc_no * 4)); + gate_reg = (void *)ccu_reg + priv->variant->gate_offset; + setbits_le32(gate_reg, BIT(AHB_GATE_OFFSET_MMC(priv->mmc_no))); ret = mmc_set_mod_clk(priv, 24000000); if (ret) @@ -665,11 +675,25 @@ static int sunxi_mmc_bind(struct udevice *dev) return mmc_bind(dev, &plat->mmc, &plat->cfg); } +static const struct sunxi_mmc_variant sun4i_a10_variant = { + .gate_offset = 0x60, + .mclk_offset = 0x88, +}; + static const struct udevice_id sunxi_mmc_ids[] = { - { .compatible = "allwinner,sun4i-a10-mmc" }, - { .compatible = "allwinner,sun5i-a13-mmc" }, - { .compatible = "allwinner,sun7i-a20-mmc" }, - { } + { + .compatible = "allwinner,sun4i-a10-mmc", + .data = (ulong)&sun4i_a10_variant, + }, + { + .compatible = "allwinner,sun5i-a13-mmc", + .data = (ulong)&sun4i_a10_variant, + }, + { + .compatible = "allwinner,sun7i-a20-mmc", + .data = (ulong)&sun4i_a10_variant, + }, + { /* sentinel */ } }; U_BOOT_DRIVER(sunxi_mmc_drv) = { -- 2.18.0.321.gffc6fa0e3

1 1

[U-Boot] BPI-M2 Magic: DRAM:Timeout initialising DRAM
by Jagan Teki 10 Jan '19

10 Jan '19

Hi, Anyone find this dram timeout issue with BPI-M2 Magic Log: U-Boot SPL 2018.05-00294-g855ff8e6dd (May 21 2018 - 22:27:49 +0530) DRAM:Timeout initialising DRAM resetting ... Look like dram fex values seems ok, any inputs? [1] https://github.com/BPI-SINOVOIP/BPI-M2M-bsp/blob/master/sunxi-pack/allwinne… Jagan. -- Jagan Teki Senior Linux Kernel Engineer | Amarula Solutions U-Boot, Linux | Upstream Maintainer Hyderabad, India.

2 1

[U-Boot] [PATCH] Makefile: Correct logic for DM_SCSI + unconverted drivers check
by Tom Rini 10 Jan '19

10 Jan '19

When checking for boards that are enabling a SATA driver that isn't converted to DM yet we need to be sure to not also trip over boards that do set CONFIG_DM_SCSI by itself, as that is not a bug. Reported-by: Andy Shevchenko <andy.shevchenko(a)gmail.com> Fixes: ea9d7c17fc4c ("dm: MIGRATION: Add migration plan for CONFIG_SATA") Signed-off-by: Tom Rini <trini(a)konsulko.com> --- Makefile | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/Makefile b/Makefile index 27c09199a446..e3e54a393f68 100644 --- a/Makefile +++ b/Makefile @@ -938,7 +938,8 @@ ifneq ($(CONFIG_DM_USB)$(CONFIG_OF_CONTROL)$(CONFIG_BLK),yyy) @echo >&2 "====================================================" endif endif -ifeq ($(CONFIG_LIBATA)$(CONFIG_DM_SCSI)$(CONFIG_MVSATA_IDE),y) +ifeq ($(CONFIG_LIBATA)$(CONFIG_MVSATA_IDE),y) +ifneq ($(CONFIG_DM_SCSI),y) @echo >&2 "===================== WARNING ======================" @echo >&2 "This board does not use CONFIG_DM_SCSI. Please update" @echo >&2 "the storage controller to use CONFIG_DM_SCSI before the v2019.07 release." @@ -946,6 +947,7 @@ ifeq ($(CONFIG_LIBATA)$(CONFIG_DM_SCSI)$(CONFIG_MVSATA_IDE),y) @echo >&2 "See doc/driver-model/MIGRATION.txt for more info." @echo >&2 "====================================================" endif +endif ifeq ($(CONFIG_OF_EMBED),y) @echo >&2 "===================== WARNING ======================" @echo >&2 "CONFIG_OF_EMBED is enabled. This option should only" -- 2.7.4

2 2

[U-Boot] [PATCH] env: sata: Fix saveenv issue
by Ye Li 10 Jan '19

10 Jan '19

Wrong env buffer was passed into sata write function, cause the saveenv not work. Signed-off-by: Ye Li <ye.li(a)nxp.com> --- env/sata.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/env/sata.c b/env/sata.c index 59aedf4..a2ff5c6 100644 --- a/env/sata.c +++ b/env/sata.c @@ -65,7 +65,7 @@ static int env_sata_save(void) return 1; printf("Writing to SATA(%d)...", env_sata); - if (write_env(sata, CONFIG_ENV_SIZE, CONFIG_ENV_OFFSET, &env_new)) { + if (write_env(sata, CONFIG_ENV_SIZE, CONFIG_ENV_OFFSET, (u_char *)env_new)) { puts("failed\n"); return 1; } -- 2.7.4

2 1

[U-Boot] [PATCH] env: sata: Add missed env location for SATA boot
by Ye Li 10 Jan '19

10 Jan '19

The env location label ENVL_ESATA is missed in location tables, so when we configure the ENV in SATA, u-boot fails to get correct env location and cause boot hang in board_f. Signed-off-by: Ye Li <ye.li(a)nxp.com> Reviewed-by: Peng Fan <peng.fan(a)nxp.com> --- env/env.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/env/env.c b/env/env.c index afed0f3..003509d 100644 --- a/env/env.c +++ b/env/env.c @@ -71,6 +71,9 @@ static enum env_location env_locations[] = { #ifdef CONFIG_ENV_IS_IN_REMOTE ENVL_REMOTE, #endif +#ifdef CONFIG_ENV_IS_IN_SATA + ENVL_ESATA, +#endif #ifdef CONFIG_ENV_IS_IN_SPI_FLASH ENVL_SPI_FLASH, #endif -- 2.7.4

2 1