March 2019 - U-Boot

[U-Boot] [RFC v2 00/15] dm, efi: integrate efi objects into DM
by AKASHI Takahiro 19 Mar '19

19 Mar '19

# bootefi doesn't work with this patch set yet This patch set came from the past discussion[1] on my "removable device support" patch and is intended to be an attempt to integrate efi objects into u-boot's Driver Model as much seamlessly as possible. [1] https://lists.denx.de/pipermail/u-boot/2019-January/354010.html Since this patch is a prototype (or POC, Proof-Of-Concept), the aim here is to discuss further about how in a better shape we will be able to merge the two worlds. After RFC, Simon suggested that efi protocols could be also presented as DM devices. This is a major change in RFC v2. Basic idea is * efi_root is a DM device * Any efi object, refered to by efi_handle_t in UEFI world, has a corresponding DM device. - define efi_handle_t as "struct udevice *" - for efi_disk, * add "struct efi_disk_obj" to blk_desc - for the objects below, there is only one instance for each and so they are currently global data: efi_gop_obj, efi_net_obj, simple_text_output_mode - for loaded_image, * link efi_loaded_image_obj to device's platdata * Any efi protocol has a corresponding DM device. - link "struct efi_handler" to device's uclass_platdata - be a child of a efi object (hence DM device) in DM device hierarchy so that enumerating protocols belonging to efi object is done by traversing the tree. * Any efi object which has a backing DM device should be created when that DM device is detected (and probed). * For efi_disk (or any object with EFI_BLOCK_IO_PROTOCOL), - add UCLASS_PARTITION - put partitions under a raw block device - partitions as well as raw devices can be efi_disk With those extensive changes, there still exists plenty of "wrapper" code. Do you have any idea to reduce it? ***** Example operation ****** (Two scsi disks, one with no partition, one with two partitions) => efi dev EFI: Initializing UCLASS_EFI_DRIVER Device Device Path ================ ==================== 000000007eef9470 /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b) => scsi rescan Reset SCSI scanning bus for devices... Target spinup took 0 ms. Target spinup took 0 ms. SATA link 2 timeout. SATA link 3 timeout. SATA link 4 timeout. SATA link 5 timeout. AHCI 0001.0000 32 slots 6 ports 1.5 Gbps 0x3f impl SATA mode flags: 64bit ncq only Device 0: (0:0) Vendor: ATA Prod.: QEMU HARDDISK Rev: 2.5+ Type: Hard Disk Capacity: 16.0 MB = 0.0 GB (32768 x 512) Device 0: (1:0) Vendor: ATA Prod.: QEMU HARDDISK Rev: 2.5+ Type: Hard Disk Capacity: 256.0 MB = 0.2 GB (524288 x 512) => efi dev Device Device Path ================ ==================== 000000007eef9470 /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b) 000000007ef01c90 /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/Scsi(0,0) 000000007ef04910 /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/Scsi(1,0) 000000007ef04ee0 /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/Scsi(1,0)/HD(335544330,MBR,0x086246ba,0x17ff4f1a0,0x7eee3770) 000000007ef055a0 /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/Scsi(1,0)/HD(335544330,MBR,0x086246ba,0x17ff4f1a0,0x7eee3770) => dm tree Class index Probed Driver Name ----------------------------------------------------------- root 0 [ + ] root_driver root_driver simple_bus 0 [ ] generic_simple_bus |-- platform@c000000 virtio 0 [ + ] virtio-mmio |-- virtio_mmio@a000000 [snip] pci 0 [ + ] pci_generic_ecam |-- pcie@10000000 pci_generi 0 [ ] pci_generic_drv | |-- pci_0:0.0 virtio 32 [ ] virtio-pci.l | |-- virtio-pci.l#0 ahci 0 [ + ] ahci_pci | `-- ahci_pci scsi 0 [ + ] ahci_scsi | `-- ahci_scsi blk 0 [ + ] scsi_blk | |-- ahci_scsi.id0lun0 efi_protoc 8 [ + ] efi_disk | | |-- BLOCK_IO efi_protoc 9 [ + ] efi_device_path | | `-- Scsi(0,0) blk 1 [ + ] scsi_blk | `-- ahci_scsi.id1lun0 efi_protoc 10 [ + ] efi_disk | |-- BLOCK_IO efi_protoc 11 [ + ] efi_device_path | |-- Scsi(1,0) partition 0 [ + ] blk_partition | |-- ahci_scsi.id1lun0:1 efi_protoc 12 [ + ] efi_disk | | |-- BLOCK_IO efi_protoc 13 [ + ] efi_device_path | | |-- HD(335544330,MBR,0x086246ba,0x17ff4f1a0,0x7eee3770) efi_protoc 14 [ + ] efi_simple_file_syst | | `-- SIMPLE_FILE_SYSTEM partition 1 [ + ] blk_partition | `-- ahci_scsi.id1lun0:2 efi_protoc 15 [ + ] efi_disk | |-- BLOCK_IO efi_protoc 16 [ + ] efi_device_path | |-- HD(335544330,MBR,0x086246ba,0x17ff4f1a0,0x7eee3770) efi_protoc 17 [ + ] efi_simple_file_syst | `-- SIMPLE_FILE_SYSTEM rtc 0 [ ] rtc-pl031 |-- pl031@9010000 serial 0 [ ] serial_pl01x |-- pl011@9050000 serial 1 [ + ] serial_pl01x |-- pl011@9000000 efi_protoc 0 [ + ] efi_simple_text_outp | |-- SIMPLE_TEXT_OUTPUT efi_protoc 1 [ + ] efi_simple_text_inpu | |-- SIMPLE_TEXT_INPUT efi_protoc 2 [ + ] efi_simple_text_inpu | `-- SIMPLE_TEXT_INPUT_EX mtd 0 [ + ] cfi_flash |-- flash@0 firmware 0 [ + ] psci |-- psci sysreset 0 [ ] psci-sysreset | `-- psci-sysreset efi 0 [ + ] efi_root `-- UEFI sub system efi_protoc 3 [ + ] efi_device_path |-- VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b) efi_protoc 4 [ + ] efi_device_path_to_t |-- DEVICE_PATH_TO_TEXT efi_protoc 5 [ + ] efi_device_path_util |-- DEVICE_PATH_UTILITIES efi_protoc 6 [ + ] efi_unicode_collatio |-- en efi_driver 0 [ + ] EFI block driver `-- EFI block driver efi_protoc 7 [ + ] efi_driver_binding `-- DRIVER_BINDING Thanks, -Takahiro Akashi AKASHI Takahiro (15): efi_loader: efi objects and protocols as DM devices efi_loader: boottime: convert efi_loaded_image_obj to DM efi_loader: image_loader: aligned with DM efi_driver: rename UCLASS_EFI to UCLASS_EFI_DRIVER efi_loader: convert efi_root_node to DM efi_loader: device path: convert efi_device_path to DM efi_loader: unicode_collation: converted to DM efi_loader: console: convert efi console input/output to DM efi_loader: net: convert efi_net_obj to DM efi_loader: gop: convert efi_gop_obj to DM dm: blk: add UCLASS_PARTITION efi_loader: disk: convert efi_disk_obj to DM drivers: align block device drivers with DM-efi integration efi_driver: converted to DM cmd: efidebug: aligned with DM-efi integration cmd/bootefi.c | 61 +-- cmd/efidebug.c | 5 +- common/usb_storage.c | 27 +- drivers/block/blk-uclass.c | 61 +++ drivers/scsi/scsi.c | 22 + drivers/serial/serial-uclass.c | 6 + drivers/video/video-uclass.c | 9 + include/blk.h | 24 + include/dm/device.h | 3 + include/dm/uclass-id.h | 6 +- include/efi.h | 4 +- include/efi_loader.h | 50 +- lib/efi_driver/efi_block_device.c | 36 +- lib/efi_driver/efi_uclass.c | 37 +- lib/efi_loader/efi_boottime.c | 605 ++++++++++++++------- lib/efi_loader/efi_console.c | 64 ++- lib/efi_loader/efi_device_path.c | 136 +++-- lib/efi_loader/efi_device_path_to_text.c | 55 ++ lib/efi_loader/efi_device_path_utilities.c | 14 + lib/efi_loader/efi_disk.c | 216 +++++--- lib/efi_loader/efi_file.c | 14 + lib/efi_loader/efi_gop.c | 28 +- lib/efi_loader/efi_image_loader.c | 61 ++- lib/efi_loader/efi_net.c | 50 +- lib/efi_loader/efi_root_node.c | 14 +- lib/efi_loader/efi_setup.c | 60 +- lib/efi_loader/efi_unicode_collation.c | 19 + net/eth-uclass.c | 5 + 28 files changed, 1226 insertions(+), 466 deletions(-) -- 2.19.1

3 30

[U-Boot] [PATCH v2] of-platdata: improve documentation
by Simon Goldschmidt 19 Mar '19

19 Mar '19

Improve some things in the documentation of OF_PLATDATA that I found while porting socfgpa_gen5 to it. Signed-off-by: Simon Goldschmidt <simon.k.r.goldschmidt(a)gmail.com> --- Changes in v2: - further fixes noted by Simon Glass - added info about missing node relations - moved the passage about phandles into section 'caveats' doc/driver-model/of-plat.txt | 31 ++++++++++++++++++++----------- dts/Kconfig | 6 ++---- 2 files changed, 22 insertions(+), 15 deletions(-) diff --git a/doc/driver-model/of-plat.txt b/doc/driver-model/of-plat.txt index 732bc34f06..0109ec56c3 100644 --- a/doc/driver-model/of-plat.txt +++ b/doc/driver-model/of-plat.txt @@ -64,17 +64,24 @@ strictly necessary. Notable problems include: normally also supports device tree it must use #ifdef to separate out this code, since the structures are only available in SPL. + - Correct relations between nodes are not implemented. This means that + parent/child relations (like bus device iteration) do not work yet. + Some phandles (those that are recognised as such) are converted into + a pointer to platform data. This pointer can potentially be used to + access the referenced device (by searching for the pointer value). + This feature is not yet implemented, however. + How it works ------------ -The feature is enabled by CONFIG SPL_OF_PLATDATA. This is only available -in SPL and should be tested with: +The feature is enabled by CONFIG OF_PLATDATA. This is only available in +SPL/TPL and should be tested with: - #if CONFIG_IS_ENABLED(SPL_OF_PLATDATA) + #if CONFIG_IS_ENABLED(OF_PLATDATA) A new tool called 'dtoc' converts a device tree file either into a set of -struct declarations, one for each compatible node, or a set of +struct declarations, one for each compatible node, and a set of U_BOOT_DEVICE() declarations along with the actual platform data for each device. As an example, consider this MMC node: @@ -156,6 +163,13 @@ This avoids the code overhead of converting the device tree data to platform data in the driver. The ofdata_to_platdata() method should therefore do nothing in such a driver. +Note that for the platform data to be matched with a driver, the 'name' +property of the U_BOOT_DEVICE() declaration has to match a driver declared +via U_BOOT_DRIVER(). This effectively means that a U_BOOT_DRIVER() with a +'name' corresponding to the devicetree 'compatible' string (after converting +it to a valid name for C) is needed, so a dedicated driver is required for +each 'compatible' string. + Where a node has multiple compatible strings, a #define is used to make them equivalent, e.g.: @@ -165,8 +179,8 @@ equivalent, e.g.: Converting of-platdata to a useful form --------------------------------------- -Of course it would be possible use the of-platdata directly in your driver -whenever configuration information is required. However this meands that the +Of course it would be possible to use the of-platdata directly in your driver +whenever configuration information is required. However this means that the driver will not be able to support device tree, since the of-platdata structure is not available when device tree is used. It would make no sense to use this structure if device tree were available, since the structure has @@ -282,11 +296,6 @@ prevents them being used inadvertently. All usage must be bracketed with The dt-platdata.c file contains the device declarations and is is built in spl/dt-platdata.c. -Some phandles (thsoe that are recognised as such) are converted into -points to platform data. This pointer can potentially be used to access the -referenced device (by searching for the pointer value). This feature is not -yet implemented, however. - The beginnings of a libfdt Python module are provided. So far this only implements a subset of the features. diff --git a/dts/Kconfig b/dts/Kconfig index 8917f42444..3e85914d11 100644 --- a/dts/Kconfig +++ b/dts/Kconfig @@ -265,8 +265,7 @@ config SPL_OF_PLATDATA This option works by generating C structure declarations for each compatible string, then adding platform data and U_BOOT_DEVICE - declarations for each node. See README.platdata for more - information. + declarations for each node. See of-plat.txt for more information. config TPL_OF_PLATDATA bool "Generate platform data for use in TPL" @@ -287,8 +286,7 @@ config TPL_OF_PLATDATA This option works by generating C structure declarations for each compatible string, then adding platform data and U_BOOT_DEVICE - declarations for each node. See README.platdata for more - information. + declarations for each node. See of-plat.txt for more information. endmenu -- 2.17.1

5 4

[U-Boot] [PATCH 1/6] fdtdec: Add cpu_to_fdt_{addr,size}() macros
by Thierry Reding 19 Mar '19

19 Mar '19

From: Thierry Reding <treding(a)nvidia.com> These macros are useful for converting the endianness of variables of type fdt_addr_t and fdt_size_t. Signed-off-by: Thierry Reding <treding(a)nvidia.com> --- include/fdtdec.h | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/include/fdtdec.h b/include/fdtdec.h index b7e35cd87c55..a965c33157c9 100644 --- a/include/fdtdec.h +++ b/include/fdtdec.h @@ -27,11 +27,15 @@ typedef phys_size_t fdt_size_t; #define FDT_ADDR_T_NONE (-1U) #define fdt_addr_to_cpu(reg) be64_to_cpu(reg) #define fdt_size_to_cpu(reg) be64_to_cpu(reg) +#define cpu_to_fdt_addr(reg) cpu_to_be64(reg) +#define cpu_to_fdt_size(reg) cpu_to_be64(reg) typedef fdt64_t fdt_val_t; #else #define FDT_ADDR_T_NONE (-1U) #define fdt_addr_to_cpu(reg) be32_to_cpu(reg) #define fdt_size_to_cpu(reg) be32_to_cpu(reg) +#define cpu_to_fdt_addr(reg) cpu_to_be32(reg) +#define cpu_to_fdt_size(reg) cpu_to_be32(reg) typedef fdt32_t fdt_val_t; #endif -- 2.20.1

2 17

[U-Boot] [PATCH] dm: check OF_LIVE is enabled
by Ibai Erkiaga 19 Mar '19

19 Mar '19

Livetree implemented functions does not have conditional compilation so check if CONFIG_IS_ENABLED prior using those functions. The issue does not report any error in a normal build as the toolchain optimize the code. Using -O0 triggers the error so the patch is intended to fix issues on a ongoing effor to build U-Boot with -O0. Signed-off-by: Ibai Erkiaga <ibai.erkiaga-elorza(a)xilinx.com> --- drivers/core/ofnode.c | 60 +++++++++++++++++++++--------------------- drivers/serial/serial-uclass.c | 2 +- 2 files changed, 31 insertions(+), 31 deletions(-) diff --git a/drivers/core/ofnode.c b/drivers/core/ofnode.c index 0e584c1..caa7fa5 100644 --- a/drivers/core/ofnode.c +++ b/drivers/core/ofnode.c @@ -20,7 +20,7 @@ int ofnode_read_u32(ofnode node, const char *propname, u32 *outp) assert(ofnode_valid(node)); debug("%s: %s: ", __func__, propname); - if (ofnode_is_np(node)) { + if (ofnode_is_np(node) && CONFIG_IS_ENABLED(OF_LIVE)) { return of_read_u32(ofnode_to_np(node), propname, outp); } else { const fdt32_t *cell; @@ -63,7 +63,7 @@ int ofnode_read_u64(ofnode node, const char *propname, u64 *outp) assert(ofnode_valid(node)); debug("%s: %s: ", __func__, propname); - if (ofnode_is_np(node)) + if (ofnode_is_np(node) && CONFIG_IS_ENABLED(OF_LIVE)) return of_read_u64(ofnode_to_np(node), propname, outp); cell = fdt_getprop(gd->fdt_blob, ofnode_to_offset(node), propname, @@ -109,7 +109,7 @@ const char *ofnode_read_string(ofnode node, const char *propname) assert(ofnode_valid(node)); debug("%s: %s: ", __func__, propname); - if (ofnode_is_np(node)) { + if (ofnode_is_np(node) && CONFIG_IS_ENABLED(OF_LIVE)) { struct property *prop = of_find_property( ofnode_to_np(node), propname, NULL); @@ -141,7 +141,7 @@ ofnode ofnode_find_subnode(ofnode node, const char *subnode_name) assert(ofnode_valid(node)); debug("%s: %s: ", __func__, subnode_name); - if (ofnode_is_np(node)) { + if (ofnode_is_np(node) && CONFIG_IS_ENABLED(OF_LIVE)) { const struct device_node *np = ofnode_to_np(node); for (np = np->child; np; np = np->sibling) { @@ -166,7 +166,7 @@ int ofnode_read_u32_array(ofnode node, const char *propname, assert(ofnode_valid(node)); debug("%s: %s: ", __func__, propname); - if (ofnode_is_np(node)) { + if (ofnode_is_np(node) && CONFIG_IS_ENABLED(OF_LIVE)) { return of_read_u32_array(ofnode_to_np(node), propname, out_values, sz); } else { @@ -179,7 +179,7 @@ int ofnode_read_u32_array(ofnode node, const char *propname, ofnode ofnode_first_subnode(ofnode node) { assert(ofnode_valid(node)); - if (ofnode_is_np(node)) + if (ofnode_is_np(node) && CONFIG_IS_ENABLED(OF_LIVE)) return np_to_ofnode(node.np->child); return offset_to_ofnode( @@ -189,7 +189,7 @@ ofnode ofnode_first_subnode(ofnode node) ofnode ofnode_next_subnode(ofnode node) { assert(ofnode_valid(node)); - if (ofnode_is_np(node)) + if (ofnode_is_np(node) && CONFIG_IS_ENABLED(OF_LIVE)) return np_to_ofnode(node.np->sibling); return offset_to_ofnode( @@ -201,7 +201,7 @@ ofnode ofnode_get_parent(ofnode node) ofnode parent; assert(ofnode_valid(node)); - if (ofnode_is_np(node)) + if (ofnode_is_np(node) && CONFIG_IS_ENABLED(OF_LIVE)) parent = np_to_ofnode(of_get_parent(ofnode_to_np(node))); else parent.of_offset = fdt_parent_offset(gd->fdt_blob, @@ -213,7 +213,7 @@ ofnode ofnode_get_parent(ofnode node) const char *ofnode_get_name(ofnode node) { assert(ofnode_valid(node)); - if (ofnode_is_np(node)) + if (ofnode_is_np(node) && CONFIG_IS_ENABLED(OF_LIVE)) return strrchr(node.np->full_name, '/') + 1; return fdt_get_name(gd->fdt_blob, ofnode_to_offset(node), NULL); @@ -223,7 +223,7 @@ ofnode ofnode_get_by_phandle(uint phandle) { ofnode node; - if (of_live_active()) + if (of_live_active() && CONFIG_IS_ENABLED(OF_LIVE)) node = np_to_ofnode(of_find_node_by_phandle(phandle)); else node.of_offset = fdt_node_offset_by_phandle(gd->fdt_blob, @@ -236,7 +236,7 @@ int ofnode_read_size(ofnode node, const char *propname) { int len; - if (ofnode_is_np(node)) { + if (ofnode_is_np(node) && CONFIG_IS_ENABLED(OF_LIVE)) { struct property *prop = of_find_property( ofnode_to_np(node), propname, NULL); @@ -256,7 +256,7 @@ fdt_addr_t ofnode_get_addr_index(ofnode node, int index) int na, ns; fdt_size_t size; - if (ofnode_is_np(node)) { + if (ofnode_is_np(node) && CONFIG_IS_ENABLED(OF_LIVE)) { const __be32 *prop_val; uint flags; @@ -267,7 +267,7 @@ fdt_addr_t ofnode_get_addr_index(ofnode node, int index) ns = of_n_size_cells(ofnode_to_np(node)); - if (IS_ENABLED(CONFIG_OF_TRANSLATE) && ns > 0) { + if (CONFIG_IS_ENABLED(CONFIG_OF_TRANSLATE) && ns > 0) { return of_translate_address(ofnode_to_np(node), prop_val); } else { na = of_n_addr_cells(ofnode_to_np(node)); @@ -292,7 +292,7 @@ fdt_addr_t ofnode_get_addr(ofnode node) int ofnode_stringlist_search(ofnode node, const char *property, const char *string) { - if (ofnode_is_np(node)) { + if (ofnode_is_np(node) && CONFIG_IS_ENABLED(OF_LIVE)) { return of_property_match_string(ofnode_to_np(node), property, string); } else { @@ -360,7 +360,7 @@ int ofnode_parse_phandle_with_args(ofnode node, const char *list_name, int index, struct ofnode_phandle_args *out_args) { - if (ofnode_is_np(node)) { + if (ofnode_is_np(node) && CONFIG_IS_ENABLED(OF_LIVE)) { struct of_phandle_args args; int ret; @@ -389,7 +389,7 @@ int ofnode_parse_phandle_with_args(ofnode node, const char *list_name, int ofnode_count_phandle_with_args(ofnode node, const char *list_name, const char *cells_name) { - if (ofnode_is_np(node)) + if (ofnode_is_np(node) && CONFIG_IS_ENABLED(OF_LIVE)) return of_count_phandle_with_args(ofnode_to_np(node), list_name, cells_name); else @@ -400,8 +400,8 @@ int ofnode_count_phandle_with_args(ofnode node, const char *list_name, ofnode ofnode_path(const char *path) { - if (of_live_active()) - return np_to_ofnode(of_find_node_by_path(path)); + if (of_live_active() && CONFIG_IS_ENABLED(OF_LIVE)) + return np_to_ofnode(of_find_node_opts_by_path(path, NULL)); else return offset_to_ofnode(fdt_path_offset(gd->fdt_blob, path)); } @@ -516,7 +516,7 @@ int ofnode_decode_display_timing(ofnode parent, int index, const void *ofnode_get_property(ofnode node, const char *propname, int *lenp) { - if (ofnode_is_np(node)) + if (ofnode_is_np(node) && CONFIG_IS_ENABLED(OF_LIVE)) return of_get_property(ofnode_to_np(node), propname, lenp); else return fdt_getprop(gd->fdt_blob, ofnode_to_offset(node), @@ -525,7 +525,7 @@ const void *ofnode_get_property(ofnode node, const char *propname, int *lenp) bool ofnode_is_available(ofnode node) { - if (ofnode_is_np(node)) + if (ofnode_is_np(node) && CONFIG_IS_ENABLED(OF_LIVE)) return of_device_is_available(ofnode_to_np(node)); else return fdtdec_get_is_enabled(gd->fdt_blob, @@ -535,7 +535,7 @@ bool ofnode_is_available(ofnode node) fdt_addr_t ofnode_get_addr_size(ofnode node, const char *property, fdt_size_t *sizep) { - if (ofnode_is_np(node)) { + if (ofnode_is_np(node) && CONFIG_IS_ENABLED(OF_LIVE)) { int na, ns; int psize; const struct device_node *np = ofnode_to_np(node); @@ -547,7 +547,7 @@ fdt_addr_t ofnode_get_addr_size(ofnode node, const char *property, ns = of_n_size_cells(np); *sizep = of_read_number(prop + na, ns); - if (IS_ENABLED(CONFIG_OF_TRANSLATE) && ns > 0) + if (CONFIG_IS_ENABLED(CONFIG_OF_TRANSLATE) && ns > 0) return of_translate_address(np, prop); else return of_read_number(prop, na); @@ -561,7 +561,7 @@ fdt_addr_t ofnode_get_addr_size(ofnode node, const char *property, const uint8_t *ofnode_read_u8_array_ptr(ofnode node, const char *propname, size_t sz) { - if (ofnode_is_np(node)) { + if (ofnode_is_np(node) && CONFIG_IS_ENABLED(OF_LIVE)) { const struct device_node *np = ofnode_to_np(node); int psize; const __be32 *prop = of_get_property(np, propname, &psize); @@ -668,7 +668,7 @@ int ofnode_read_pci_vendev(ofnode node, u16 *vendor, u16 *device) int ofnode_read_addr_cells(ofnode node) { - if (ofnode_is_np(node)) + if (ofnode_is_np(node) && CONFIG_IS_ENABLED(OF_LIVE)) return of_n_addr_cells(ofnode_to_np(node)); else /* NOTE: this call should walk up the parent stack */ return fdt_address_cells(gd->fdt_blob, ofnode_to_offset(node)); @@ -676,7 +676,7 @@ int ofnode_read_addr_cells(ofnode node) int ofnode_read_size_cells(ofnode node) { - if (ofnode_is_np(node)) + if (ofnode_is_np(node) && CONFIG_IS_ENABLED(OF_LIVE)) return of_n_size_cells(ofnode_to_np(node)); else /* NOTE: this call should walk up the parent stack */ return fdt_size_cells(gd->fdt_blob, ofnode_to_offset(node)); @@ -684,7 +684,7 @@ int ofnode_read_size_cells(ofnode node) int ofnode_read_simple_addr_cells(ofnode node) { - if (ofnode_is_np(node)) + if (ofnode_is_np(node) && CONFIG_IS_ENABLED(OF_LIVE)) return of_simple_addr_cells(ofnode_to_np(node)); else return fdt_address_cells(gd->fdt_blob, ofnode_to_offset(node)); @@ -692,7 +692,7 @@ int ofnode_read_simple_addr_cells(ofnode node) int ofnode_read_simple_size_cells(ofnode node) { - if (ofnode_is_np(node)) + if (ofnode_is_np(node) && CONFIG_IS_ENABLED(OF_LIVE)) return of_simple_size_cells(ofnode_to_np(node)); else return fdt_size_cells(gd->fdt_blob, ofnode_to_offset(node)); @@ -726,7 +726,7 @@ bool ofnode_pre_reloc(ofnode node) int ofnode_read_resource(ofnode node, uint index, struct resource *res) { - if (ofnode_is_np(node)) { + if (ofnode_is_np(node) && CONFIG_IS_ENABLED(OF_LIVE)) { return of_address_to_resource(ofnode_to_np(node), index, res); } else { struct fdt_resource fres; @@ -758,7 +758,7 @@ int ofnode_read_resource_byname(ofnode node, const char *name, u64 ofnode_translate_address(ofnode node, const fdt32_t *in_addr) { - if (ofnode_is_np(node)) + if (ofnode_is_np(node) && CONFIG_IS_ENABLED(OF_LIVE)) return of_translate_address(ofnode_to_np(node), in_addr); else return fdt_translate_address(gd->fdt_blob, ofnode_to_offset(node), in_addr); @@ -766,7 +766,7 @@ u64 ofnode_translate_address(ofnode node, const fdt32_t *in_addr) int ofnode_device_is_compatible(ofnode node, const char *compat) { - if (ofnode_is_np(node)) + if (ofnode_is_np(node) && CONFIG_IS_ENABLED(OF_LIVE)) return of_device_is_compatible(ofnode_to_np(node), compat, NULL, NULL); else diff --git a/drivers/serial/serial-uclass.c b/drivers/serial/serial-uclass.c index d4488a2..ee64616 100644 --- a/drivers/serial/serial-uclass.c +++ b/drivers/serial/serial-uclass.c @@ -86,7 +86,7 @@ static void serial_find_console_or_panic(void) } } else if (CONFIG_IS_ENABLED(OF_CONTROL) && blob) { /* Live tree has support for stdout */ - if (of_live_active()) { + if (CONFIG_IS_ENABLED(OF_LIVE) && of_live_active()) { struct device_node *np = of_get_stdout(); if (np && !uclass_get_device_by_ofnode(UCLASS_SERIAL, -- 1.8.3.1

3 3

[U-Boot] [PATCH] mmc: tmio: Clamp SD_SECCNT to 16bit values on 16bit IP
by Marek Vasut 18 Mar '19

18 Mar '19

On 16bit variants of the TMIO SD IP, the SECCNT register can only be programmed to 16bit values, while on the 32bit and 64bit variants it can be programmed to 32bit values. The SECCNT register indicates the maximum number of blocks in a continuous transfer. Hence, limit the maximum continuous transfer block count to 65535 blocks on 16bit variants of the TMIO IP and to BIT(32)-1 blocks on 32bit and 64bit variants. Signed-off-by: Marek Vasut <marek.vasut+renesas(a)gmail.com> Cc: Masahiro Yamada <yamada.masahiro(a)socionext.com> --- drivers/mmc/tmio-common.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/drivers/mmc/tmio-common.c b/drivers/mmc/tmio-common.c index 01d8c2b925..812205a21f 100644 --- a/drivers/mmc/tmio-common.c +++ b/drivers/mmc/tmio-common.c @@ -783,7 +783,10 @@ int tmio_sd_probe(struct udevice *dev, u32 quirks) plat->cfg.f_min = mclk / (priv->caps & TMIO_SD_CAP_DIV1024 ? 1024 : 512); plat->cfg.f_max = mclk; - plat->cfg.b_max = U32_MAX; /* max value of TMIO_SD_SECCNT */ + if (quirks & TMIO_SD_CAP_16BIT) + plat->cfg.b_max = U16_MAX; /* max value of TMIO_SD_SECCNT */ + else + plat->cfg.b_max = U32_MAX; /* max value of TMIO_SD_SECCNT */ upriv->mmc = &plat->mmc; -- 2.20.1

1 0

Re: [U-Boot] [PATCH 1/1] cmd: usb: display bus number
by Heinrich Schuchardt 18 Mar '19

18 Mar '19

Spam detection software, running on the system "lists.denx.de", has identified this incoming email as possible spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: On 1/2/19 7:33 PM, Heinrich Schuchardt wrote: > On 1/2/19 5:37 PM, Marek Vasut wrote: >> On 1/2/19 5:03 PM, Heinrich Schuchardt wrote: >>> On 1/2/19 3:21 PM, Marek Vasut wrote: >>>> On 1/2/19 12:29 PM, Heinrich Schuchardt wrote: >>>>> If multiple USB buses exist, the output of the commands 'usb tree' and 'usb >>>>> info' is confusing because it is not clear where the output for a new bus >>>>> starts. >>>>> >>>>> Print an additional line for each bus indicating the bus number, e.g. >>>>> >>>>> => usb tree >>>>> USB device tree: >>>>> USB bus 0 >>>>> 1 Hub (5 Gb/s, 0mA) >>>>> U-Boot XHCI Host Controller >>>>> >>>>> USB bus 1 >>>>> 1 Hub (5 Gb/s, 0mA) >>>>> U-Boot XHCI Host Controller >>>>> >>>>> Signed-off-by: Heinrich Schuchardt >>>>> --- >>>>> cmd/usb.c | 1 + >>>>> 1 file changed, 1 insertion(+) >>>>> >>>>> diff --git a/cmd/usb.c b/cmd/usb.c >>>>> index 0ccb1b5148..6da945c376 100644 >>>>> --- a/cmd/usb.c >>>>> +++ b/cmd/usb.c >>>>> @@ -470,6 +470,7 @@ static void usb_for_each_root_dev(usb_dev_func_t func) >>>>> if (!device_active(bus)) >>>>> continue; >>>>> >>>>> + printf("USB bus %d\n", bus->seq); >>>> >>>> Isn't this only valid if you use SEQ_ALIAS ? >>> >>> Kconfig symbol SEQ_ALIAS does not exist. I assume you mean DM_SEQ_ALIAS. >>> >>> In device_probe() seq is set unconditionally >>> (drivers/core/device.c:306). >>> >>> CONFIG_DM_SEQ_ALIAS=y allows to influence the value of seq via the >>> device tree. >> >> I know what it does. Without this option being set, the bus->seq number >> will be either some obscure gigantic number or undefined, right ? >> > > I disabled CONFIG_DM_SEQ_ALIAS and this is the output on my MACCHIATObin > (with the second USB bus enabled in the device tree). > > => usb start > starting USB... > USB0: Register 2000120 NbrPorts 2 > Starting the controller > USB XHCI 1.00 > USB1: Register 2000120 NbrPorts 2 > Starting the controller > USB XHCI 1.00 > scanning bus 0 for devices... 1 USB Device(s) found > scanning bus 1 for devices... 1 USB Device(s) found > scanning usb [...] Content analysis details: (5.5 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 3.0 SINGLE_HEADER_3K A single header contains 3K-4K characters 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (xypron.glpk[at]gmx.de) 2.5 DRUGS_MUSCLE Refers to a muscle relaxant

2 1

[U-Boot] [BUG] efi_loader: self-tests fail on qemu-x86_defconfig when compiled with GCC 8.3 and CONFIG_CC_OPTIMIZE_FOR_SIZE=y
by Heinrich Schuchardt 18 Mar '19

18 Mar '19

Debian has recently (march 8th) upgraded GCC from 8.2 to 8.3. When I compile qemu-x86_defconfig with CONFIG_CC_OPTIMIZE_FOR_SIZE=y some of the UEFI selftests (bootefi selftest) fail. It looks to me like ebx is not conserved. With CONFIG_CC_OPTIMIZE_FOR_SIZE=n everything is fine. Best regards Heinrich

2 2

[U-Boot] [PATCH 1/2] usb: gadget: fastboot: Request status and length check in rx handler
by Paul Kocialkowski 18 Mar '19

18 Mar '19

This avoids handling requests that have an error status or no data. In particular, this avoids showing unnecessary error messages when the USB gadget gets disconnected (e.g. with fastboot continue) and the fastboot USB gadget driver sends an error back to the host (that has disconnected already). Signed-off-by: Paul Kocialkowski <contact(a)paulk.fr> --- drivers/usb/gadget/f_fastboot.c | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/drivers/usb/gadget/f_fastboot.c b/drivers/usb/gadget/f_fastboot.c index 206b6d1..b9a9099 100644 --- a/drivers/usb/gadget/f_fastboot.c +++ b/drivers/usb/gadget/f_fastboot.c @@ -635,6 +635,9 @@ static void rx_handler_command(struct usb_ep *ep, struct usb_request *req) void (*func_cb)(struct usb_ep *ep, struct usb_request *req) = NULL; int i; + if (req->status != 0 || req->length == 0) + return; + for (i = 0; i < ARRAY_SIZE(cmd_dispatch_info); i++) { if (!strcmp_l1(cmd_dispatch_info[i].cmd, cmdbuf)) { func_cb = cmd_dispatch_info[i].cb; @@ -656,9 +659,7 @@ static void rx_handler_command(struct usb_ep *ep, struct usb_request *req) } } - if (req->status == 0) { - *cmdbuf = '\0'; - req->actual = 0; - usb_ep_queue(ep, req, 0); - } + *cmdbuf = '\0'; + req->actual = 0; + usb_ep_queue(ep, req, 0); } -- 1.9.1

4 15

[U-Boot] rpi: bcm2835_sdhost: occasional errors while writing
by Zubair Lutfullah Kakakhel 18 Mar '19

18 Mar '19

Hi, I've encountered occasional glitches while writing to the sd card via u-boot(2018.07) on a Pi 3 B+. The goal is to write the bootcount in the boot partition. As a test, this is the loop I used to read, display contents, write to the same file over and over again. ``` mw 200000 0 while itest *200000 == 0 ; do fatload mmc 0:1 $kernel_addr_r resin-image md $kernel_addr_r 18 fatwrite mmc 0:1 $kernel_addr_r resin-image 18 echo === done ==== done ``` resin-image is a file in the boot partition that has some text in it. After a few minutes of this loop running, I 'sometimes' get this error and the sd card stops working ``` writing resin-image wait_transfer_complete - still waiting after 100001 retries mmc write failed Error: flush fat buffer ** Unable to write "resin-image" from mmc 0:1 ** WARNING at /home/zubairlk/resin/yocto/resin-raspberrypi3/build/tmp/work/raspberrypi3-poky-linux-gnueabi/u-boot/1_2018.07-r0/git/drivers/mmc/bcm2835_sdhost.c:376/bcm2835_prepare_data()! WARNING at /home/zubairlk/resin/yocto/resin-raspberrypi3/build/tmp/work/raspberrypi3-poky-linux-gnueabi/u-boot/1_2018.07-r0/git/drivers/mmc/bcm2835_sdhost.c:408/bcm2835_send_command()! WARNING at /home/zubairlk/resin/yocto/resin-raspberrypi3/build/tmp/work/raspberrypi3-poky-linux-gnueabi/u-boot/1_2018.07-r0/git/drivers/mmc/bcm2835_sdhost.c:408/bcm2835_send_command()! WARNING at /home/zubairlk/resin/yocto/resin-raspberrypi3/build/tmp/work/raspberrypi3-poky-linux-gnueabi/u-boot/1_2018.07-r0/git/drivers/mmc/bcm2835_sdhost.c:408/bcm2835_send_command()! WARNING at /home/zubairlk/resin/yocto/resin-raspberrypi3/build/tmp/work/raspberrypi3-poky-linux-gnueabi/u-boot/1_2018.07-r0/git/drivers/mmc/bcm2835_sdhost.c:408/bcm2835_send_command()! WARNING at /home/zubairlk/resin/yocto/resin-raspberrypi3/build/tmp/work/raspberrypi3-poky-linux-gnueabi/u-boot/1_2018.07-r0/git/drivers/mmc/bcm2835_sdhost.c:408/bcm2835_send_command()! ** Can't read partition table on 0:0 ** ** Invalid partition 1 ** 00080000: 4e204f44 5220544f 564f4d45 48542045 DO NOT REMOVE TH 00080010: 46205349 0a454c49 0f030f03 0f030f03 IS FILE......... 00080020: 0f030f03 0f030f03 01600103 03030300 ..........`..... 00080030: 03030303 03030303 03030303 03030303 ................ 00080040: 03030303 03030303 03030303 03034103 .............A.. 00080050: 03030303 03030303 03030303 03030303 ................ WARNING at /home/zubairlk/resin/yocto/resin-raspberrypi3/build/tmp/work/raspberrypi3-poky-linux-gnueabi/u-boot/1_2018.07-r0/git/drivers/mmc/bcm2835_sdhost.c:408/bcm2835_send_command()! WARNING at /home/zubairlk/resin/yocto/resin-raspberrypi3/build/tmp/work/raspberrypi3-poky-linux-gnueabi/u-boot/1_2018.07-r0/git/drivers/mmc/bcm2835_sdhost.c:408/bcm2835_send_command()! WARNING at /home/zubairlk/resin/yocto/resin-raspberrypi3/build/tmp/work/raspberrypi3-poky-linux-gnueabi/u-boot/1_2018.07-r0/git/drivers/mmc/bcm2835_sdhost.c:408/bcm2835_send_command()! WARNING at /home/zubairlk/resin/yocto/resin-raspberrypi3/build/tmp/work/raspberrypi3-poky-linux-gnueabi/u-boot/1_2018.07-r0/git/drivers/mmc/bcm2835_sdhost.c:408/bcm2835_send_command()! WARNING at /home/zubairlk/resin/yocto/resin-raspberrypi3/build/tmp/work/raspberrypi3-poky-linux-gnueabi/u-boot/1_2018.07-r0/git/drivers/mmc/bcm2835_sdhost.c:408/bcm2835_send_command()! WARNING at /home/zubairlk/resin/yocto/resin-raspberrypi3/build/tmp/work/raspberrypi3-poky-linux-gnueabi/u-boot/1_2018.07-r0/git/drivers/mmc/bcm2835_sdhost.c:408/bcm2835_send_command()! ** Can't read partition table on 0:0 ** ** Invalid partition 1 ** ``` What is even more concerning is that the device can't boot. Even if a write failed. Subsequent reads seem to fail as well. ``` U-Boot> mmc part Partition Map for MMC device 0 -- Partition Type: DOS Part Start Sector Num Sectors UUID Type WARNING at /home/zubairlk/resin/yocto/resin-raspberrypi3/build/tmp/work/raspberrypi3-poky-linux-gnueabi/u-boot/1_2018.07-r0/git/drivers/mmc/bcm2835_sdhost.c:408/bcm2835_send_command()! WARNING at /home/zubairlk/resin/yocto/resin-raspberrypi3/build/tmp/work/raspberrypi3-poky-linux-gnueabi/u-boot/1_2018.07-r0/git/drivers/mmc/bcm2835_sdhost.c:408/bcm2835_send_command()! WARNING at /home/zubairlk/resin/yocto/resin-raspberrypi3/build/tmp/work/raspberrypi3-poky-linux-gnueabi/u-boot/1_2018.07-r0/git/drivers/mmc/bcm2835_sdhost.c:408/bcm2835_send_command()! WARNING at /home/zubairlk/resin/yocto/resin-raspberrypi3/build/tmp/work/raspberrypi3-poky-linux-gnueabi/u-boot/1_2018.07-r0/git/drivers/mmc/bcm2835_sdhost.c:408/bcm2835_send_command()! WARNING at /home/zubairlk/resin/yocto/resin-raspberrypi3/build/tmp/work/raspberrypi3-poky-linux-gnueabi/u-boot/1_2018.07-r0/git/drivers/mmc/bcm2835_sdhost.c:408/bcm2835_send_command()! WARNING at /home/zubairlk/resin/yocto/resin-raspberrypi3/build/tmp/work/raspberrypi3-poky-linux-gnueabi/u-boot/1_2018.07-r0/git/drivers/mmc/bcm2835_sdhost.c:408/bcm2835_send_command()! ** Can't read partition table on 0:0 ** U-Boot> ``` I can recover the device after a reboot. Any thoughts/ideas about where/what I should look for? Or if I'm lucky, any wip patches floating around? Thanks Regards, ZubairLK p.s. The sd card is a good SanDisk one..

2 2

[U-Boot] i.MX6 Code Consolidation suggestion/question
by Adam Ford 18 Mar '19

18 Mar '19

I am looking into the SPL code to boot the imx6_logic board and comparing its board file to other i.MX6 boards. Nearly every board has a virtually identical board_init_f function. Some of the entries are done is slightly different orders, but what happens appears to be the same. I don't know if there is an advantage to one order or another. We have a common mach-imx/spl.c file and the very end there exisrts an MX6-only ifdef with the dram_init_banksize function in side the ifdef. Any objections to my creating a weak function called board_init_f inside there, then wiping out all the individual board entries that are identical? For those who have a slightly different variation, they can be left alone. It seems logical to me, but I don't have access to everyone's hardware, so before I do that, I thought I'd ask first. adam

2 3