Eraseenv new #1

frank-w · 2019-04-10T09:31:32Z

No description provided.

"mmc eraseenv" allows to erase the section on mmc where env is stored Signed-off-by: Frank Wunderlich <frank-w@public-files.de>

Signed-off-by: Frank Wunderlich <frank-w@public-files.de>

frank-w · 2019-04-10T09:33:21Z

due to rebase of target-branch not only erase-commits are shown

v2019.04-rc3 sandbox U-Boot fails to boot when compiled with -fsanitize=address and linked against -lasan, reporting [1]. Git bisecting shows that the issue is contributed by v2019.01 commit 1678754 ("core: ofnode: Fix ofnode_get_addr_index function"). The root cause seems to be the mismatch between sizeof(u64) and sizeof(fdt_size_t) on sandbox. Luckily, thanks to the fact that the size argument of both of_get_address() and fdtdec_get_addr_size_fixed() is optional, we can pass NULL in its place, avoiding the problem. [1] Backtrace reported by ASAN (gcc 8.1.0): $> ./u-boot -d arch/sandbox/dts/sandbox.dtb [..] Reviewed-by: Simon Glass <sjg@chromium.org> ================================================================= ==10998==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7ffcc2331140 at pc 0x0000004eeeb0 bp 0x7ffcc2330f80 sp 0x7ffcc2330f70 WRITE of size 8 at 0x7ffcc2331140 thread T0 #0 0x4eeeaf in of_get_address drivers/core/of_addr.c:154 #1 0x4f7441 in ofnode_get_addr_index drivers/core/ofnode.c:263 #2 0x5b2a78 in sb_eth_ofdata_to_platdata drivers/net/sandbox.c:422 #3 0x4dccd8 in device_probe drivers/core/device.c:407 #4 0x753170 in eth_initialize net/eth-uclass.c:428 #5 0x47d9bf in initr_net common/board_r.c:557 #6 0x6bcfa7 in initcall_run_list lib/initcall.c:30 #7 0x47e1fe in board_init_r common/board_r.c:859 #8 0x4060e5 in main arch/sandbox/cpu/start.c:356 #9 0x7fb8d135482f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2082f) #10 0x40a3a8 in _start (/path/to/u-boot/u-boot+0x40a3a8) Address 0x7ffcc2331140 is located in stack of thread T0 at offset 32 in frame #0 0x4f72b8 in ofnode_get_addr_index drivers/core/ofnode.c:255 This frame has 3 object(s): [32, 36) 'size' <== Memory access at offset 32 partially overflows this variable [96, 100) 'flags' [160, 168) 'node' HINT: this may be a false positive if your program uses some custom stack unwind mechanism or swapcontext (longjmp and C++ exceptions *are* supported) SUMMARY: AddressSanitizer: stack-buffer-overflow drivers/core/of_addr.c:154 in of_get_address Shadow bytes around the buggy address: 0x10001845e1d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x10001845e1e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x10001845e1f0: 00 00 00 00 00 00 00 00 00 00 00 00 f1 f1 f1 f1 0x10001845e200: 04 f2 f2 f2 f2 f2 f2 f2 04 f2 f2 f2 f2 f2 f2 f2 0x10001845e210: 04 f2 f2 f2 f3 f3 f3 f3 00 00 00 00 00 00 00 00 =>0x10001845e220: 00 00 00 00 f1 f1 f1 f1[04]f2 f2 f2 f2 f2 f2 f2 0x10001845e230: 04 f2 f2 f2 f2 f2 f2 f2 00 f2 f2 f2 f3 f3 f3 f3 0x10001845e240: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x10001845e250: 00 00 00 00 f1 f1 f1 f1 00 00 f2 f2 f3 f3 f3 f3 0x10001845e260: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f1 f1 0x10001845e270: f1 f1 00 f2 f2 f2 f3 f3 f3 f3 00 00 00 00 00 00 Shadow byte legend (one shadow byte represents 8 application bytes): Addressable: 00 Partially addressable: 01 02 03 04 05 06 07 Heap left redzone: fa Freed heap region: fd Stack left redzone: f1 Stack mid redzone: f2 Stack right redzone: f3 Stack after return: f5 Stack use after scope: f8 Global redzone: f9 Global init order: f6 Poisoned by user: f7 Container overflow: fc Array cookie: ac Intra object redzone: bb ASan internal: fe Left alloca redzone: ca Right alloca redzone: cb ==10998==ABORTING 'To' list: git log --since=1year drivers/core/ofnode.c | grep "\-by: .*@" | \ sed 's/.*-by: //' | sort | uniq -c | sort -rn 10 Simon Glass <sjg@chromium.org> 3 Mario Six <mario.six@gdsys.cc> 2 Martin Fuzzey <mfuzzey@parkeon.com> 2 Marek Vasut <marek.vasut+renesas@gmail.com> 1 Tom Rini <trini@konsulko.com> 1 Masahiro Yamada <yamada.masahiro@socionext.com> 1 Keerthy <j-keerthy@ti.com> 1 Jens Wiklander <jens.wiklander@linaro.org> 1 Bin Meng <bmeng.cn@gmail.com> Fixes: 1678754 ("core: ofnode: Fix ofnode_get_addr_index function") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com>

Enable CONFIG_ARMV7_BOOT_SEC_DEFAULT by default to avoid a kernel crash when booting NXP linux kernels in non-secure world, when job ring device allocation is done by CAAM hw accelerator driver: caam 30900000.caam: job rings = 3, qi = 0 caam_jr 30901000.jr0: failed to flush job ring 0 caam_jr: probe of 30901000.jr0 failed with error -5 caam_jr 30902000.jr1: failed to flush job ring 1 caam_jr: probe of 30902000.jr1 failed with error -5 caam_jr 30903000.jr2: failed to flush job ring 2 caam_jr: probe of 30903000.jr2 failed with error -5 caam algorithms registered in /proc/crypto Job Ring Device allocation for transform failed caam 30900000.caam: caam pkc algorithms registered in /proc/crypto Unable to handle kernel NULL pointer dereference at virtual address 00000010 pgd = c0004000 [00000010] *pgd=00000000 Internal error: Oops: 5 [#1] PREEMPT SMP ARM Modules linked in: CPU: 0 PID: 1 Comm: swapper/0 Tainted: Hardware name: Freescale i.MX7 Dual (Device Tree) task: ec0d8000 task.stack: ec0ce000 PC is at caam_sm_startup+0x3f8/0x4f4 Signed-off-by: Igor Opaniuk <igor.opaniuk@toradex.com>

Right now the rk3399 sdram driver assume that the board has configured with 2 channels, so any possibility to enable single channel on the same driver will encounter channel #1 data training failure. Log: U-Boot TPL board init sdram_init: data training failed rk3399_dmc_init DRAM init failed -5 So, add an algorithm that can capable to compute the active or configured rank with associated channel like a) do rank loop to compute the active rank, with associated channel numbers b) then, succeed the data training only for configured channel c) preserve the rank for given channel d) do channel loop for setting the active channel e) if given rank is zero or inactive on the specific channel, clear the timings for the associated channel f) finally, return error if number of channels is zero Tested in NanoPI-NEO4 since it support single channel sdram configuration. Signed-off-by: Jagan Teki <jagan@amarulasolutions.com> Signed-off-by: YouMin Chen <cym@rock-chips.com> Reviewed-by: Kever Yang <Kever.yang@rock-chips.com> (add PI_READ_GATE_TRAINING for LPDDR3 to support rk3399-evb case) Signed-off-by: Kever Yang <Kever.yang@rock-chips.com>

Add support to boot some remoteprocs at U-boot prompt on the J721E EVM boards by using the 'boot_rprocs' and other env variables defined in the common environment file k3_rproc.h, and updating the 'DEFAULT_RPROCS' macro. The list of R5F cores to be started before loading and booting the Linux kernel are as follows, and in this order: Main R5FSS0 (Split) Core1 : 3 /lib/firmware/j7-main-r5f0_1-fw Main R5FSS1 (LockStep) : 4 /lib/firmware/j7-main-r5f1_0-fw The MCU R5FSS0 and Main R5FSS1 are currently in LockStep mode, so the equivalent Core1 rprocs (rproc #1 and #5) are not included. The Main R5FSS0 Core0 (rproc #2) is already started by R5 SPL, so is not included in the list either. The DSP cores are started in the following order before loading and booting the Linux kernel: C66_0: 6 /lib/firmware/j7-c66_0-fw C66_1: 7 /lib/firmware/j7-c66_1-fw C71_0: 8 /lib/firmware/j7-c71_0-fw The order of the rprocs to boot can be changed at runtime if desired by overwriting the 'rproc_fw_binaries' environment variable at U-boot prompt. Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com> Signed-off-by: Suman Anna <s-anna@ti.com> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>

After updating libavb to most recent version from AOSP/master, two new warnings appear: Warning #1: lib/libavb/avb_cmdline.c: In function 'avb_append_options': lib/libavb/avb_cmdline.c:365:15: warning: 'dm_verity_mode' may be used uninitialized in this function [-Wmaybe-uninitialized] new_ret = avb_replace( ^~~~~~~~~~~~ slot_data->cmdline, "$(ANDROID_VERITY_MODE)", dm_verity_mode); ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ lib/libavb/avb_cmdline.c:374:8: warning: 'verity_mode' may be used uninitialized in this function [-Wmaybe-uninitialized] if (!cmdline_append_option( ^~~~~~~~~~~~~~~~~~~~~~ slot_data, "androidboot.veritymode", verity_mode)) { ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Warning #2: lib/libavb/avb_slot_verify.c: In function 'avb_slot_verify': lib/libavb/avb_slot_verify.c:1349:23: warning: 'ret' may be used uninitialized in this function [-Wmaybe-uninitialized] AvbSlotVerifyResult ret; ^~~ Fix those by providing default return values to affected functions. Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org>

Trying to extend 'adtimg' functionality [1], we've been severely hit by a major limitation in the command's usage scheme. Specifically, the command's user interface appears to be too centric to getting the DTB/DTBO entry [3] based on the index of the desired DT in the image, which makes it really difficult retrieving the DT entry based on alternative criteria (e.g. filtering by id/rev fields), the latter being demanded by real life customer use-cases [1]. This went to the point of receiving below feedback from Sam [2]: -- snip -- As for 'dtimg' command: after giving it some thought, I think not much people using it yet. So in this particular case I don't have some strong preference, and if you think the 'dtimg' interface is ugly, and it overcomes "don't break interfaces" rule, maybe now is a good time to rework it (before it gets widely used). -- snip -- Given the above, rework the usage pattern from [4] to [5], in order to allow an intuitive enablement of "by id|rev" DT search [6]. [1] https://patchwork.ozlabs.org/cover/1202575/ ("cmd: dtimg: Enhance with --id and --rev options (take #1)") [2] https://patchwork.ozlabs.org/patch/1182207/#2317020 [3] https://source.android.com/devices/architecture/dto/partitions [4] Old usage adtimg dump <addr> - Print image contents adtimg start <addr> <index> <varname> - Get DT address by index adtimg size <addr> <index> <varname> - Get DT size by index [5] New usage adtimg addr <addr> - Set image location to <addr> adtimg dump - Print out image contents adtimg get dt --index=<i> [avar [svar]] - Get DT address and size by index [6] Soon-to-be-provided "by id|rev" add-on functionality adtimg get dt --id=<id> --rev=<rev> [avar [svar [ivar]]] - Get DT address/size/index by id|rev fields Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Sam Protsenko <semen.protsenko@linaro.org>

Add device trees describing possible uses of mezzanine cards depending on the SERDES protocol employed. This patch adds DPAA2 networking support for the following protocols on each SERDES block: * SD #1: 3, 7, 19, 20 * SD #2: 11 Each SERDES block has a different device tree file per protocol supported, where the IO SLOTs used are enabled and PHYs located on the mezzanine cards are described. Also, dpmac nodes are edited and their associated phy-connection-type and phy-handle are added. Top DTS files are also added for each combination of protocol on the 3 SERDES blocks. Signed-off-by: Ioana Ciornei <ioana.ciornei@nxp.com> Reviewed-by: Razvan Ionut Cirjan <razvanionut.cirjan@nxp.com> [Rebased] Signed-off-by: Priyanka Jain <priyanka.jain@nxp.com>

Enable RTC command to be able to check available. And also enable ZynqMP RTC driver to be possible to use by default. Here is the list when both drivers are enabled: ZynqMP> rtc list RTC #0 - rtc_emul RTC #1 - rtc@ffa60000 Signed-off-by: Michal Simek <michal.simek@xilinx.com>

Lot of PCI and PCIe controllers are using standard Config Address for PCI Configuration Mechanism #1 or its extended version. So add PCI_CONF1_ADDRESS() and PCI_CONF1_EXT_ADDRESS() macros into U-Boot's pci.h header file which can be suitable for most PCI and PCIe controller drivers. Drivers do not have to invent their own macros and can use these new U-Boot macros. Signed-off-by: Pali Rohár <pali@kernel.org> Reviewed-by: Simon Glass <sjg@chromium.org>

PCI gt64120 driver uses standard format of Config Address for PCI Configuration Mechanism #1. So use new U-Boot macro PCI_CONF1_ADDRESS() and remove old custom driver address macros. Signed-off-by: Pali Rohár <pali@kernel.org> Reviewed-by: Simon Glass <sjg@chromium.org>

PCI mpc85xx driver uses extended format of Config Address for PCI Configuration Mechanism #1. So use new U-Boot macro PCI_CONF1_EXT_ADDRESS(). Signed-off-by: Pali Rohár <pali@kernel.org> Reviewed-by: Simon Glass <sjg@chromium.org>

PCI msc01 driver uses standard format of Config Address for PCI Configuration Mechanism #1 but with cleared Enable bit. So use new U-Boot macro PCI_CONF1_ADDRESS() with clearing PCI_CONF1_ENABLE bit and remove old custom driver address macros. Signed-off-by: Pali Rohár <pali@kernel.org> Reviewed-by: Simon Glass <sjg@chromium.org>

PCI mvebu driver uses extended format of Config Address for PCI Configuration Mechanism #1. So use new U-Boot macro PCI_CONF1_EXT_ADDRESS() and remove old custom driver address macros. Signed-off-by: Pali Rohár <pali@kernel.org> Reviewed-by: Simon Glass <sjg@chromium.org>

PCI tegra driver uses extended format of Config Address for PCI Configuration Mechanism #1 but with cleared Enable bit. So use new U-Boot macro PCI_CONF1_EXT_ADDRESS() with clearing PCI_CONF1_ENABLE bit and remove old custom driver address function. Signed-off-by: Pali Rohár <pali@kernel.org> Reviewed-by: Simon Glass <sjg@chromium.org>

PCI fsl driver uses extended format of Config Address for PCI Configuration Mechanism #1. So use new U-Boot macro PCI_CONF1_EXT_ADDRESS(). Signed-off-by: Pali Rohár <pali@kernel.org> Reviewed-by: Simon Glass <sjg@chromium.org>

PCI mediatek driver uses extended format of Config Address for PCI Configuration Mechanism #1 but with cleared Enable bit. So use new U-Boot macro PCI_CONF1_EXT_ADDRESS() with clearing PCI_CONF1_ENABLE bit and remove old custom driver address macros. Signed-off-by: Pali Rohár <pali@kernel.org> Reviewed-by: Simon Glass <sjg@chromium.org>

PCI sh7780 driver uses standard format of Config Address for PCI Configuration Mechanism #1. So use new U-Boot macro PCI_CONF1_ADDRESS(). Signed-off-by: Pali Rohár <pali@kernel.org> Reviewed-by: Simon Glass <sjg@chromium.org>

x86 platform uses standard format of Config Address for PCI Configuration Mechanism #1. So use new U-Boot macro PCI_CONF1_ADDRESS(). Signed-off-by: Pali Rohár <pali@kernel.org> Reviewed-by: Simon Glass <sjg@chromium.org>

mcf5445x platform uses standard format of Config Address for PCI Configuration Mechanism #1. So use new U-Boot macro PCI_CONF1_ADDRESS(). Signed-off-by: Pali Rohár <pali@kernel.org> Reviewed-by: Simon Glass <sjg@chromium.org>

sh7751 platform uses standard format of Config Address for PCI Configuration Mechanism #1. Commit 72c2f4a ("pci: sh7751: Convert to DM and DT probing") which did conversion of PCI sh7751 driver to DM, broke access to config space as that commit somehow swapped device and function bits in config address. Fix all these issues by using new U-Boot macro PCI_CONF1_ADDRESS() which calculates Config Address correctly. Also remove nonsense function sh7751_pci_addr_valid() which was introduced in commit 72c2f4a ("pci: sh7751: Convert to DM and DT probing") probably due to workarounded issues with mixing/swapping device and function bits of config address which probably resulted in non-working access to some devices. With correct composing of config address there should not be such issue anymore. Signed-off-by: Pali Rohár <pali@kernel.org> Fixes: 72c2f4a ("pci: sh7751: Convert to DM and DT probing") Cc: Marek Vasut <marek.vasut+renesas@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>

There are three different kinds of EEPROM possibly present on boards. 1. 1byte address. For those we should avoid 2byte address in order not to rewrite the data. Second byte of the address can potentially be interpreted as the data to write. 2. 2byte address with defined behaviour. When we try to use 1byte address they just return "FF FF FF FF ... FF" 3. 2byte address with undefined behaviour (for instance, 24LC32AI). When we try to use 1byte address, then their internal read pointer is changed to some value. Subsequential reads may be broken. To gracefully handle both case #1 and case #3 we read all required data from EEPROM at once (about 80 bytes). So either all the data is valid or we fallback to 2byte address. Cc: Nishanth Menon <nm@ti.com> Fixes: a58147c ("board: ti: common: board_detect: Do 1byte address checks first.") Reference: https://lore.kernel.org/all/CAJs94Ebdd4foOjhGFu9Bop0v=B1US9neDLxfhgcY23ukgLzFOQ@mail.gmail.com/ Signed-off-by: Matwey V. Kornilov <matwey.kornilov@gmail.com> Acked-by: Nishanth Menon <nm@ti.com>

Since commit de39dc7 ("arm: armv7-a: Compile and tune for armv7-a instead of armv5") is used -march=armv7-a option for Omap3 platforms. With directive ".arch_extension sec" it is possible for -march=armv7-a to directly use ARM SMC instruction. So enable ".arch_extension sec" in Omap3 lowlevel_init.S and replace hand assembled ".word 0xe1600071" by "SMC #1". Since commit 51d0638 ("arm: omap-common: add secure smc entry") same pattern is already used in arch/arm/cpu/armv7/omap-common/lowlevel_init.S. Signed-off-by: Pali Rohár <pali@kernel.org>

FVP PMUv3 SPIs legacy interrupts are only listed for cluster #0 and are missing for cluster #1. This patch changes FVP SPIs to PMUv3 PPI as in arm_fpga.dtsi, morello.dtsi and n1sdp.dtsi. Signed-off-by: AlexeiFedorov <Alexei.Fedorov@arm.com> Change-Id: Ic624cec09ba932666c746ae1a6a4b78b6decde96

Add support for the USB 3.0 devices in rk3588: - USB DRD(dual role device) 3.0 #0 as usbdrd3_0 which is available in rk3588s - USB DRD(dual role device) 3.0 #1 as usbdrd3_1 which is available in rk3588 only - USB DP PHY (combo USB3.0 and DisplayPort Alt Mode ) #0 phy interface as usbdp_phy0 - USB DP PHY (combo USB3.0 and DisplayPort Alt Mode ) #1 phy interface as usbdp_phy1 - USB 2.0 phy #2 , the USB 3.0 device can work with this phy in USB 2.0 mode - associated GRFs (general register files) for the devices. Signed-off-by: Joseph Chen <chenjh@rock-chips.com> [eugen.hristev@collabora.com: move nodes to right place, adapt from latest linux kernel] Signed-off-by: Eugen Hristev <eugen.hristev@collabora.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>

In part_get_info_by_name() the inability to get some partition info shouldn't be a reason for dropping out of the loop. That might happen e.g. if the partition is hidden or unused. An example of such case are Samsung devices, where they use the "unused" GUID type (00000000-0000-0000-0000-000000000000) to indicate that the partition should be hidden from the OS. Such partitions might not be seen in "part list" output, which creates "gaps" in numbering in between of the visible partitions: Part Start LBA End LBA Name 1 0x00000400 0x0000a3ff "efs" 5 0x00026420 0x00026c1f "dtbo" 12 0x0003f390 0x0074738f "super" In that case, the loop in part_get_info_by_name() would break after partition #1, so any attempt to obtain "dtbo" or "super" partition will fail. Fix that by continuing to iterate over the remaining partitions to make sure none of the visible ones is missed. That makes "part" command (e.g. "part start", "part size") able to work with such tables. Fixes: 87b8530 ("disk: part: implement generic function part_get_info_by_name()") Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

frank-w added 6 commits March 23, 2019 15:07

add build.sh, defconfig and build-in-environment (uenv.txt)

4c59f78

increase size for environment 4k => 8k

3006b33

[bootmenu] added key-input (1-9,a-f)

e9bab50

mmc: add eraseenv command

94ba117

"mmc eraseenv" allows to erase the section on mmc where env is stored Signed-off-by: Frank Wunderlich <frank-w@public-files.de>

env: register erase command

11488a3

Signed-off-by: Frank Wunderlich <frank-w@public-files.de>

env: mmc: add erase-function

f3bbde4

Signed-off-by: Frank Wunderlich <frank-w@public-files.de>

frank-w closed this Apr 10, 2019

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Eraseenv new #1

Eraseenv new #1

frank-w commented Apr 10, 2019

frank-w commented Apr 10, 2019

Eraseenv new #1

Eraseenv new #1

Conversation

frank-w commented Apr 10, 2019

frank-w commented Apr 10, 2019