April 2016 - U-Boot

[U-Boot] [PATCH v3 0/2] spl: Add support to load FIT from Filesystem
by Lokesh Vutla 02 May '16

02 May '16

Some devices like MMC, USB can be formatted to a FS and can act as a boot media. Given that FIT image load support in SPL support only raw devices, SPL should also be able to support loading FIT image from a File system. This series add support to load FIT image from a filesystem and also adding hooks to FAT FS. Verified on DRA74-evm, DRA72-evm, AM57xx-evm, AM437x-GP-evm with SPL_LOAD_FIT enabled. V2: https://www.mail-archive.com/u-boot%40lists.denx.de/msg209279.html V1: https://www.mail-archive.com/u-boot%40lists.denx.de/msg208648.html Lokesh Vutla (2): spl: Add an option to load a FIT containing U-Boot from FS spl: Support loading a FIT from FAT FS common/spl/spl_fat.c | 27 +++++++++- common/spl/spl_fit.c | 148 +++++++++++++++++++++++++++++++++++++++++++-------- include/spl.h | 31 +++++++++++ 3 files changed, 181 insertions(+), 25 deletions(-) -- 2.1.4

3 5

[U-Boot] [PATCH 00/11] ARM: Keystone2: Convert davinci_spi to DM
by Vignesh R 02 May '16

02 May '16

This series converts davinci_spi driver to adapt to driver model framework. And enables the driver on k2l, k2e, k2hk evms. Also, added support for davinci_spi on k2g evm. Tested on k2l, k2e, k2hk and k2g evms. Vignesh R (11): spi: davinci_spi: Convert to driver to adapt to DM keystone2: spi: do not define DM_SPI and DM_SPI_FLASH for SPL build ARM: dts: keystone2: add SPI aliases for davinci SPI nodes ARM: dts: k2hk: Enable Davinci SPI controller defconfig: k2hk_evm_defconfig: enable SPI driver model ARM: dts: k2e: Enable Davinci SPI controller defconfig: k2e_evm_defconfig: enable SPI driver model ARM: dts: k2l: Enable Davinci SPI controller defconfig: k2l_evm_defconfig: enable SPI driver model ARM: dts: k2g: add support for Davinci SPI controller defconfig: k2g_evm_defconfig: enable SPI driver model arch/arm/dts/k2e-evm.dts | 3 +- arch/arm/dts/k2g-evm.dts | 24 +++ arch/arm/dts/k2g.dtsi | 47 +++++ arch/arm/dts/k2hk-evm.dts | 3 +- arch/arm/dts/k2l-evm.dts | 3 +- arch/arm/dts/keystone.dtsi | 3 + configs/k2e_evm_defconfig | 2 + configs/k2g_evm_defconfig | 2 + configs/k2hk_evm_defconfig | 2 + configs/k2l_evm_defconfig | 2 + drivers/spi/davinci_spi.c | 326 +++++++++++++++++++++++++---------- include/configs/ti_armv7_keystone2.h | 4 + 12 files changed, 329 insertions(+), 92 deletions(-) -- 2.8.1

3 27

[U-Boot] [PATCH v2 00/27] spl: Support loading a FIT image containing U-Boot
by Simon Glass 02 May '16

02 May '16

4 60

[U-Boot] buildman: arm: undefined reference to `__aeabi_ldivmod'
by Jagan Teki 02 May '16

02 May '16

Hi, Did anyone encounter this issue? please let me know for any inputs. arm: + venice2 +drivers/mtd/spi-nor/built-in.o: In function `spi_nor_write': +build/../drivers/mtd/spi-nor/spi-nor.c:585: undefined reference to `__aeabi_ldivmod' +arm-unknown-linux-gnueabi-ld.bfd: BFD (GNU Binutils) 2.24 assertion fail /home/tony/buildall/src/binutils/bfd/elf32-arm.c:7696 +arm-unknown-linux-gnueabi-ld.bfd: error: required section '.rel.plt' not found in the linker script +arm-unknown-linux-gnueabi-ld.bfd: final link failed: Invalid operation +make[1]: *** [u-boot] Error 1 +make: *** [sub-make] Error 2 thanks! -- Jagan.

3 8

[U-Boot] [PATCH 0/8] net: Split out the Ethernet uclass into its own file
by Simon Glass 01 May '16

01 May '16

Every other uclass is in its own file. It makes sense to put the Ethernet uclass code into its own file too. The result is less code in each file, and it becomes easier to see which code is related to driver model. This series creates a new common file to hold the common code, moves the driver-model into its own file and tidies up. Some boards use PCI to obtain Ethernet. With driver model, unless this is mentioned in the device tree, the Ethernet device will not be present on initial startup. So we need to probe PCI just in case there is a device there. Simon Glass (8): tegra: Report errors from PCI init net: Don't call board/cpu_eth_init() with driver model net: Move common init into a new eth_common.c file net: Move environment functions to the common file net: Move remaining common functions to eth_common.c net: Move driver-model code into its own file net: Rename eth.c to eth_lecacy.c net: Probe PCI before looking for ethernet devices drivers/pci/pci_tegra.c | 6 +- net/Makefile | 7 +- net/{eth.c => eth-uclass.c} | 601 +------------------------------------------- net/eth_common.c | 166 ++++++++++++ net/eth_internal.h | 40 +++ net/eth_legacy.c | 439 ++++++++++++++++++++++++++++++++ 6 files changed, 664 insertions(+), 595 deletions(-) rename net/{eth.c => eth-uclass.c} (50%) create mode 100644 net/eth_common.c create mode 100644 net/eth_internal.h create mode 100644 net/eth_legacy.c -- 2.6.0.rc2.230.g3dd15c0

4 37

[U-Boot] A problem about 'sf probe' using DM_SPI
by Qianyu Gong 01 May '16

01 May '16

Hi Simon, I think I'm not very clear with this code in common/cmd_sf.c: " # ifdef CONFIG_DM_SPI_FLASH /* Remove the old device, otherwise probe will just be a nop */ ret = spi_find_bus_and_cs(bus, cs, &bus_dev, &new); if (!ret) { device_remove(new); device_unbind(new); } " I may understand the remove but why need to unbind the device? The unbind would cause a series of free operations on the device list, correct? Then if I probe a flash twice, at the second time the driver model will create a new flash named 'spi_flash@xx:xx' using default settings because it doesn't find such a device in the device list and never probes it from the board's fdt again. => dm tree Class Probed Name ---------------------------------------- root [ + ] root_driver simple_bus [ + ] `-- soc spi [ + ] |-- dspi@2100000 spi_flash [ ] | |-- n25q128a spi_flash [ + ] | |-- spi_flash@1:1 spi_flash [ + ] | `-- spi_flash@1:2 Fortunately the default SPI mode set by U-Boot is SPI_MODE_3 so it doesn't cause issues on our boards. But if an SPI flash which only supports SPI_MODE_0 is used, I think it wouldn't work properly from the second probe. Sorry if there is something wrong with my understandings. Just because I found my flash's name was changed to spi-flash@xx:xx in dm tree after several probes, I began to read something about driver model.:) Regards, Qianyu

2 5

[U-Boot] [PATCH 00/44] dm: blk: Add more driver-model support for block devices
by Simon Glass 01 May '16

01 May '16

This series adjusts the block device code to support conversion to driver model. Specifically - A new 'legacy' block interface is created, allowing block devices to be defined by a linker list and accessed through function calls - Block device commands (such as sata and scsi) are adjusted to use these functions rather than the block device array directly - These same function calls are then implemented by the block uclass - The existing block-device table in part.c is dropped - The opportunity is taken to clean up the code style, as block devices are one of the few remaining dark corners in U-Boot It is useful to enable all block device drivers with sandbox. This improves sandbox code coverage and allows tests to be written. The following are enabled by this series: - IDE - SCSI - SATA - Systemace USB was already enabled. MMC will be enabled by a future series. Note that these devices do not actually function in sandbox, but the code is compiled. As mentioned, future work will enable MMC for sandbox including adding rudimentary sandbox SD card emulation. It would also be possible to create emulations for IDE, SCSI, SATA and Systemace but that work is not planned. It should be noted that the current CONFIG_DM_MMC option does not fully enable driver model for MMC, since the MMC operations are not running through driver model. This will need to be addressed at some point. This series is available at u-boot-dm/blka-working Simon Glass (44): Revert "dm: sandbox: Drop the pre-DM host implementation" dm: sandbox: Add a board for sandbox without CONFIG_BLK pci: Drop CONFIG_SYS_SCSI_SCAN_BUS_REVERSE dm: Rename disk uclass to ahci Allow iotrace byte access to use an address of any size sandbox: Add string and 16-bit I/O functions sandbox: Add dummy SCSI functions sandbox: Add dummy SATA functions dm: scsi: Remove the forward declarations dm: scsi: Fix up code style dm: ide: Correct various code style problems dm: ide: Remove the forward declarations dm: sata: Fix code style problems in cmd/sata.c dm: scsi: Rename CONFIG_CMD_SCSI to CONFIG_SCSI dm: blk: Add a legacy block interface dm: systemace: Add a legacy block interface dm: sandbox: Add a legacy host block interface dm: usb: Add a legacy block interface for USB storage dm: mmc: Add a legacy block interface for MMC dm: mmc: Add an implementation of the 'devnum' functions dm: scsi: Separate the non-command code into its own file dm: ide: Separate the non-command code into its own file dm: sata: Separate the non-command code into its own file dm: disk: Use legacy block driver info for block device access dm: usb: Drop the get_dev() function dm: ide: Drop the get_dev() function dm: mmc: Drop the get_dev() function dm: scsi: Drop the get_dev() function dm: sata: Drop the get_dev() function dm: systemace: Drop the get_dev() function dm: blk: Drop the systemace.h header dm: sandbox: Drop the host_get_dev() function dm: part: Drop the get_dev() method dm: ide: Add support for driver-model block devices dm: sandbox: Enable IDE dm: scsi: Add support for driver-model block devices dm: sandbox: Enable SCSI dm: sata: Add support for driver-model block devices dm: sandbox: Enable SATA dm: blk: Allow blk_create_device() to allocate the device number dm: blk: Add a easier way to create a named block device dm: systemace: Reorder function to avoid forward declarataions dm: systemace: Add driver-mode block-device support dm: sandbox: Enable systemace README | 4 +- api/api_storage.c | 2 +- arch/arm/include/asm/arch-ls102xa/config.h | 2 +- arch/sandbox/include/asm/io.h | 22 + arch/x86/Kconfig | 3 + arch/x86/cpu/broadwell/sata.c | 2 +- arch/x86/cpu/intel_common/cpu.c | 2 +- arch/x86/cpu/ivybridge/bd82x6x.c | 2 +- arch/x86/cpu/ivybridge/sata.c | 2 +- board/cm5200/fwupdate.c | 2 +- board/mpl/pip405/README | 6 +- board/sandbox/MAINTAINERS | 7 + cmd/Makefile | 8 +- cmd/disk.c | 2 +- cmd/ide.c | 1352 +----------------------- cmd/mmc.c | 2 +- cmd/sata.c | 142 +-- cmd/scsi.c | 753 ++----------- cmd/usb.c | 16 +- common/Makefile | 6 + common/board_r.c | 4 +- common/ide.c | 1231 +++++++++++++++++++++ common/sata.c | 115 ++ common/scsi.c | 592 +++++++++++ common/spl/spl_sata.c | 2 +- common/spl/spl_usb.c | 2 +- common/usb_storage.c | 37 +- configs/sandbox_noblk_defconfig | 98 ++ disk/part.c | 22 +- drivers/Makefile | 1 + drivers/block/Kconfig | 5 +- drivers/block/Makefile | 8 +- drivers/block/{disk-uclass.c => ahci-uclass.c} | 6 +- drivers/block/blk-uclass.c | 324 ++++++ drivers/block/blk_legacy.c | 258 +++++ drivers/block/sandbox.c | 103 +- drivers/block/sandbox_scsi.c | 29 + drivers/block/sata_sandbox.c | 33 + drivers/block/sym53c8xx.c | 2 +- drivers/block/systemace.c | 110 +- drivers/mmc/mmc.c | 24 +- drivers/pci/pci.c | 4 - fs/fat/fat.c | 2 +- include/blk.h | 226 +++- include/config_cmd_all.h | 2 +- include/config_distro_bootcmd.h | 6 +- include/config_fallbacks.h | 2 +- include/configs/MPC8544DS.h | 2 +- include/configs/MPC8572DS.h | 2 +- include/configs/MPC8610HPCD.h | 2 +- include/configs/MPC8641HPCN.h | 4 +- include/configs/PIP405.h | 2 +- include/configs/am57xx_evm.h | 2 +- include/configs/cm_t54.h | 2 +- include/configs/db-88f6820-gp.h | 2 +- include/configs/dra7xx_evm.h | 2 +- include/configs/efi-x86.h | 2 +- include/configs/galileo.h | 2 +- include/configs/highbank.h | 2 +- include/configs/ls1043aqds.h | 2 +- include/configs/ls2080aqds.h | 2 +- include/configs/ls2080ardb.h | 2 +- include/configs/omap5_uevm.h | 2 +- include/configs/qemu-x86.h | 2 +- include/configs/sandbox.h | 23 + include/configs/sbc8641d.h | 2 - include/configs/sunxi-common.h | 2 +- include/configs/x86-common.h | 2 +- include/configs/xilinx_zynqmp.h | 2 +- include/dm/uclass-id.h | 2 +- include/ide.h | 8 + include/iotrace.h | 5 +- include/part.h | 15 - include/systemace.h | 17 - include/usb.h | 1 - 75 files changed, 3392 insertions(+), 2308 deletions(-) create mode 100644 common/ide.c create mode 100644 common/sata.c create mode 100644 common/scsi.c create mode 100644 configs/sandbox_noblk_defconfig rename drivers/block/{disk-uclass.c => ahci-uclass.c} (72%) create mode 100644 drivers/block/blk_legacy.c create mode 100644 drivers/block/sandbox_scsi.c create mode 100644 drivers/block/sata_sandbox.c delete mode 100644 include/systemace.h -- 2.8.0.rc3.226.g39d4020

3 61

[U-Boot] ARMv7 / RK3288 Hypervisor Support
by Timothy Pearson 01 May '16

01 May '16

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 All, I recently ported U-Boot over to the RK3288-based Veyron Speedy 4GB Chromebook in an attempt to gain KVM (hypervisor) support [1]. However, in addition to the GIC being completely masked off in non-secure mode by the AXI bus, the machine hangs immediately upon exiting the NS/HYP switch monitor mode call in arch/arm/cpu/armv7/nonsec_virt.S. I notice that the hypervisor setup code was revised back in 2014 to support platforms with secure RAM, effectively replacing the early hvc 0 call with a late smc 0-based setup routine. Has the current hypervisor implementation been tested on the original Versatile Express TC-2 board since the setup code modification? Is anyone else working on RK3288 hypervisor support? The datasheet claims virtualization extensions are supported, but right now that seems quite dubious unless 1.) the GIC can be un-masked in normal mode and 2.) the hang on HYP mode switch can be traced to an implementation fault in u-boot. Thanks! [1] Work-in-progress patches: http://raptorengineering.com/u-boot/rk3288/patches/wip/ - -- Timothy Pearson Raptor Engineering +1 (415) 727-8645 (direct line) +1 (512) 690-0200 (switchboard) http://www.raptorengineeringinc.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJXFVHXAAoJEK+E3vEXDOFbop0IAJk6D2lvb4dPwUvo/EUDo1CJ A7YEQTIYc7i5Fa0jTd3ttpVDMbwt2Q6PSdhl2xBT1GoY1aWtI65r6cNgZxRE081C YQ7VFHNa7uR9Li+dKYeKA0JWrOYe8WQDL1/8jphAfMRZZ3D0mTfbV6xa+vdQI5La I493OwS3yssMXha0PCO7PN5+HrFYPFg2UCQMkz1uwH3JCi879XR/+Wy0luvDnx7c tTD589bggKlbY/cHnEG0XNjj4ChfCcTNQ1r62GTnRgSsGCRklvTi+B40aM9vLg5f swIiKCUAWqle8aQyRxVsyGEwr6N11SvU4NjRryybUgLvV6SfaIWCUejuCT92ZE4= =grIP -----END PGP SIGNATURE-----

3 2

[U-Boot] Introduce clk framework
by Peng Fan 01 May '16

01 May '16

Hi, Since we are moving towards to use dtb and driver model, we still lack of a clk framework. I just have an idea to introduce linux clk framework to u-boot, then in driver code, we can do as linux "clk_enable/clk_disable/clk_set_freq". I'd like to hear more voice on clk framework before I began porting the clk framework from kernel to U-Boot. Or redesign a simple one, if the kernel one is too complicated? Thanks, Peng.

2 1

[U-Boot] u-boot wiki page on "fdt" command full of "FDT_ERR_BADMAGIC"
by Robert P. J. Day 01 May '16

01 May '16

was perusing the wiki page on "fdt": http://www.denx.de/wiki/view/DULG/UBootCmdFDT and it's fairly loaded with examples of commands that generate only the error message: libfdt fdt_path_offset() returned FDT_ERR_BADMAGIC were those supposed to be eventually replaced by valid output? rday -- ======================================================================== Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ========================================================================

2 1