April 2019 - U-Boot

[U-Boot] [PATCH 1/1] efi_loader: parameter check CreateEventEx()
by Heinrich Schuchardt 25 Apr '19

25 Apr '19

CreateEvent() and CreateEventEx() should check that a notify function is provided for either of EVT_NOTIFY_SIGNAL or EVT_NOTIFY_WAIT. Signed-off-by: Heinrich Schuchardt <xypron.glpk(a)gmx.de> --- lib/efi_loader/efi_boottime.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lib/efi_loader/efi_boottime.c b/lib/efi_loader/efi_boottime.c index 601b0a2cb8..a72cbe1559 100644 --- a/lib/efi_loader/efi_boottime.c +++ b/lib/efi_loader/efi_boottime.c @@ -618,7 +618,7 @@ efi_status_t efi_create_event(uint32_t type, efi_uintn_t notify_tpl, } if ((type & (EVT_NOTIFY_WAIT | EVT_NOTIFY_SIGNAL)) && - (is_valid_tpl(notify_tpl) != EFI_SUCCESS)) + (!notify_function || is_valid_tpl(notify_tpl) != EFI_SUCCESS)) return EFI_INVALID_PARAMETER; evt = calloc(1, sizeof(struct efi_event)); -- 2.20.1

1 0

[U-Boot] [PATCH v1 0/3] Add Cadence PCIe endpoint driver with new uclass
by Ramon Fried 25 Apr '19

25 Apr '19

This patchset adds support for new uclass, UCLASS_PCI_EP allowing new set of PCI endpoint drivers. Included in the patchset is also a driver for Cadence PCIe endpoint. Ramon Fried (3): drivers: pci_ep: Introduce UCLASS_PCI_EP uclass pci: pci.h: add missing maskbit pci_ep: add Cadence PCIe endpoint driver .../pci_endpoint/cdns,cdns-pcie-ep.txt | 18 + drivers/Kconfig | 2 + drivers/Makefile | 1 + drivers/pci_endpoint/Kconfig | 25 ++ drivers/pci_endpoint/Makefile | 7 + drivers/pci_endpoint/pci_ep-uclass.c | 192 +++++++++ drivers/pci_endpoint/pcie-cadence-ep.c | 177 +++++++++ drivers/pci_endpoint/pcie-cadence.h | 309 +++++++++++++++ include/dm/uclass-id.h | 1 + include/pci.h | 1 + include/pci_ep.h | 375 ++++++++++++++++++ 11 files changed, 1108 insertions(+) create mode 100644 doc/device-tree-bindings/pci_endpoint/cdns,cdns-pcie-ep.txt create mode 100644 drivers/pci_endpoint/Kconfig create mode 100644 drivers/pci_endpoint/Makefile create mode 100644 drivers/pci_endpoint/pci_ep-uclass.c create mode 100644 drivers/pci_endpoint/pcie-cadence-ep.c create mode 100644 drivers/pci_endpoint/pcie-cadence.h create mode 100644 include/pci_ep.h -- 2.21.0

2 10

[U-Boot] the dm of SPL does not support very well on spiboot
by Chuanhua Han 25 Apr '19

25 Apr '19

Hi,all 1. When I tested and compiled some spiboot boards, I found that the board compilation of these spiflash boot configurations failed. These boards all support the dm mode of spl, and the boot mode used is spiboot. Here is the board configuration I compiled: configs/sama5d2_xplained_spiflash_defconfig configs/sama5d3xek_spiflash_defconfig configs/sama5d4_xplained_spiflash_defconfig configs/sama5d4ek_spiflash_defconfig eg: sama5d4ek_spiflash_defconfig CC spl/drivers/clk/at91/clk-master.o drivers/spi/spi.c: In function 'spi_do_alloc_slave': CC spl/lib/libfdt/fdt_ro.o CC spl/lib/libfdt/fdt_region.o drivers/spi/spi.c:34:8: error: 'struct spi_slave' has no member named 'bus' slave->bus = bus; ^~ drivers/spi/spi.c:35:8: error: 'struct spi_slave' has no member named 'cs' slave->cs = cs; ^~ scripts/Makefile.build:278: recipe for target 'spl/drivers/spi/spi.o' failed So far there seems to be no spiboot board that compiles successfully and works properly. I would like to know how to configure uboot in SPL using dm spiboot to ensure normal compilation. =================== 2. When I compile d with T2080QDS_SPIFLASH_defconfig, a similar error message appears. I have included the following options in the configuration file: CONFIG_DM_SPI=y CONFIG_DM_SPI_FLASH=y The following is the error log: $ make T2080QDS_SPIFLASH_defconfig&&make -j32 all HOSTCC scripts/basic/fixdep HOSTCC scripts/kconfig/conf.o ... LD spl/lib/built-in.o LD spl/u-boot-spl env/built-in.o: In function `setup_flash_device': /home/hanch/DSPI/u-boot-fsl-qoriq/env/sf.c:60: undefined reference to `spi_flash_probe_bus_cs' /home/hanch/DSPI/u-boot-fsl-qoriq/env/sf.c:68: undefined reference to `dev_get_uclass_priv' env/built-in.o: In function `spi_flash_read': /home/hanch/DSPI/u-boot-fsl-qoriq/include/spi_flash.h:118: undefined reference to `spi_flash_read_dm' env/built-in.o: In function `env_sf_load': /home/hanch/DSPI/u-boot-fsl-qoriq/env/sf.c:317: undefined reference to `spi_flash_free' drivers/built-in.o: In function `fsl_spi_spl_load_image': /home/hanch/DSPI/u-boot-fsl-qoriq/drivers/mtd/spi/fsl_espi_spl.c:18: undefined reference to `spi_flash_probe' drivers/built-in.o: In function `spi_flash_read': /home/hanch/DSPI/u-boot-fsl-qoriq/include/spi_flash.h:118: undefined reference to `spi_flash_read_dm' drivers/built-in.o: In function `fsl_spi_boot': /home/hanch/DSPI/u-boot-fsl-qoriq/drivers/mtd/spi/fsl_espi_spl.c:44: undefined reference to `spi_flash_probe' drivers/built-in.o: In function `spi_flash_read': /home/hanch/DSPI/u-boot-fsl-qoriq/include/spi_flash.h:118: undefined reference to `spi_flash_read_dm' drivers/built-in.o: In function `spi_flash_std_write': /home/hanch/DSPI/u-boot-fsl-qoriq/drivers/mtd/spi/sf_probe.c:113: undefined reference to `dev_get_uclass_priv' drivers/built-in.o: In function `spi_flash_std_read': /home/hanch/DSPI/u-boot-fsl-qoriq/drivers/mtd/spi/sf_probe.c:103: undefined reference to `dev_get_uclass_priv' drivers/built-in.o: In function `spi_flash_std_get_sw_write_prot': /home/hanch/DSPI/u-boot-fsl-qoriq/drivers/mtd/spi/sf_probe.c:140: undefined reference to `dev_get_uclass_priv' drivers/built-in.o: In function `spi_flash_std_erase': /home/hanch/DSPI/u-boot-fsl-qoriq/drivers/mtd/spi/sf_probe.c:122: undefined reference to `dev_get_uclass_priv' drivers/built-in.o: In function `spi_flash_std_probe': /home/hanch/DSPI/u-boot-fsl-qoriq/drivers/mtd/spi/sf_probe.c:147: undefined reference to `dev_get_parent_priv' /home/hanch/DSPI/u-boot-fsl-qoriq/drivers/mtd/spi/sf_probe.c:148: undefined reference to `dev_get_parent_platdata' /home/hanch/DSPI/u-boot-fsl-qoriq/drivers/mtd/spi/sf_probe.c:151: undefined reference to `dev_get_uclass_priv' scripts/Makefile.spl:384: recipe for target 'spl/u-boot-spl' failed make[1]: *** [spl/u-boot-spl] Error 1 Makefile:1649: recipe for target 'spl/u-boot-spl' failed make: *** [spl/u-boot-spl] Error 2 So I added the following two options to solve the above error: CONFIG_SPL_DM=y CONFIG_SPL_OF_CONTROL=y But it brings new mistakes: LD spl/drivers/built-in.o LD spl/lib/built-in.o LD spl/u-boot-spl drivers/built-in.o: In function `blk_post_probe': /home/hanch/DSPI/u-boot-fsl-qoriq/drivers/block/blk-uclass.c:645: undefined reference to `part_init' scripts/Makefile.spl:384: recipe for target 'spl/u-boot-spl' failed make[1]: *** [spl/u-boot-spl] Error 1 Makefile:1649: recipe for target 'spl/u-boot-spl' failed make: *** [spl/u-boot-spl] Error 2 The following options have been added for the current error: # CONFIG_SPL_BLK is not set At this time, the compiler passes, but spiboot cannot be performed on the spi-flash, uboot cannot be started. I tried to open the following options: CONFIG_SPL_FRAMEWORK=y Delete the following options: -# CONFIG_SPL_BLK is not set Multiple definitions of error were reported: LD spl/common/spl/built-in.o LD spl/disk/built-in.o LD spl/lib/built-in.o LD spl/u-boot-spl common/spl/built-in.o: In function `board_init_r': /home/hanch/DSPI/u-boot-fsl-qoriq/common/spl/spl.c:567: multiple definition of `board_init_r' board/freescale/t208xqds/built-in.o:/home/hanch/DSPI/u-boot-fsl-qoriq/board/freescale/t208xqds/spl.c:97: first defined here scripts/Makefile.spl:384: recipe for target 'spl/u-boot-spl' failed make[1]: *** [spl/u-boot-spl] Error 1 Makefile:1649: recipe for target 'spl/u-boot-spl' failed make: *** [spl/u-boot-spl] Error 2 Then I guess whether the dm of SPL does not support very well on spiboot. I hope you can help. Looking forward to your reply, thank you very much!!! Thanks, Chuanhua

2 2

[U-Boot] [PATCH v2 1/1] efi_loader: set OsIndicationsSupported at init
by Heinrich Schuchardt 25 Apr '19

25 Apr '19

From: AKASHI Takahiro <takahiro.akashi(a)linaro.org> UEFI variables should be installed using well-defined API. Currently we don't support much, but the value of OsIndicationsSupported will be updated once some features are added in the future. Signed-off-by: AKASHI Takahiro <takahiro.akashi(a)linaro.org> Add comments. Rename a variable. Reviewed-by: Heinrich Schuchardt <xypron.glpk(a)gmx.de> --- Applied to efi-2019-07 branch. --- cmd/bootefi.c | 4 ---- lib/efi_loader/efi_setup.c | 11 +++++++++++ 2 files changed, 11 insertions(+), 4 deletions(-) diff --git a/cmd/bootefi.c b/cmd/bootefi.c index efaa548be4..b93d8c6a32 100644 --- a/cmd/bootefi.c +++ b/cmd/bootefi.c @@ -303,10 +303,6 @@ static efi_status_t do_bootefi_exec(efi_handle_t handle) if (ret != EFI_SUCCESS) return ret; - /* we don't support much: */ - env_set("efi_8be4df61-93ca-11d2-aa0d-00e098032b8c_OsIndicationsSupported", - "{ro,boot}(blob)0000000000000000"); - /* Call our payload! */ ret = EFI_CALL(efi_start_image(handle, NULL, NULL)); diff --git a/lib/efi_loader/efi_setup.c b/lib/efi_loader/efi_setup.c index b32a7b3f93..87db51cbb7 100644 --- a/lib/efi_loader/efi_setup.c +++ b/lib/efi_loader/efi_setup.c @@ -79,6 +79,7 @@ out: */ efi_status_t efi_init_obj_list(void) { + u64 os_indications_supported = 0; /* None */ efi_status_t ret = EFI_SUCCESS; /* Initialize once only */ @@ -90,6 +91,16 @@ efi_status_t efi_init_obj_list(void) if (ret != EFI_SUCCESS) goto out; + /* Indicate supported features */ + ret = EFI_CALL(efi_set_variable(L"OsIndicationsSupported", + &efi_global_variable_guid, + EFI_VARIABLE_BOOTSERVICE_ACCESS | + EFI_VARIABLE_RUNTIME_ACCESS, + sizeof(os_indications_supported), + &os_indications_supported)); + if (ret != EFI_SUCCESS) + goto out; + /* Initialize system table */ ret = efi_initialize_system_table(); if (ret != EFI_SUCCESS) -- 2.20.1

2 1

[U-Boot] [PATCH] misc: uclass: Introduce misc_init_by_ofnode
by Keerthy 25 Apr '19

25 Apr '19

Introduce misc_init_by_ofnode to probe a misc device using its ofnode. Signed-off-by: Keerthy <j-keerthy(a)ti.com> --- drivers/misc/misc-uclass.c | 25 +++++++++++++++++++++++++ include/misc.h | 9 +++++++++ 2 files changed, 34 insertions(+) diff --git a/drivers/misc/misc-uclass.c b/drivers/misc/misc-uclass.c index 55381edc98..835d3f7118 100644 --- a/drivers/misc/misc-uclass.c +++ b/drivers/misc/misc-uclass.c @@ -5,6 +5,8 @@ #include <common.h> #include <dm.h> +#include <dm/device-internal.h> +#include <dm/uclass-internal.h> #include <errno.h> #include <misc.h> @@ -65,6 +67,29 @@ int misc_set_enabled(struct udevice *dev, bool val) return ops->set_enabled(dev, val); } +int misc_init_by_ofnode(ofnode node) +{ + struct udevice *dev = NULL; + int ret; + long temp1, temp2; + + temp1 = ofnode_to_offset(node); + + for (ret = uclass_find_first_device(UCLASS_MISC, &dev); dev; + ret = uclass_find_next_device(&dev)) { + temp2 = ofnode_to_offset(dev_ofnode(dev)); + if (temp1 == temp2) { + ret = device_probe(dev); + if (ret) + debug("%s: Failed to initialize - %d\n", + dev->name, ret); + return ret; + } + } + + return -ENODEV; +} + UCLASS_DRIVER(misc) = { .id = UCLASS_MISC, .name = "misc", diff --git a/include/misc.h b/include/misc.h index 12d1325ee2..79263ed480 100644 --- a/include/misc.h +++ b/include/misc.h @@ -76,6 +76,15 @@ int misc_call(struct udevice *dev, int msgid, void *tx_msg, int tx_size, */ int misc_set_enabled(struct udevice *dev, bool val); +/** + * misc_init_by_ofnode() - Probe a misc device by using ofnode. + * @node: ofnode of the misc device. + * + * A misc device is probed using ofnode. + * + * Return: -ve on error, 0 on success + */ +int misc_init_by_ofnode(ofnode node); /* * struct misc_ops - Driver model Misc operations * -- 2.17.1

2 1

[U-Boot] [PATCH 1/2] eeprom: fix DM_I2C support with CONFIG_SYS_I2C_EEPROM_BUS
by Simon Goldschmidt 25 Apr '19

25 Apr '19

This fixes eeprom for DM_I2C in u-boot-socfpga/master commit 3c43ab903d33 ("eeprom: fix DM_I2C support without CONFIG_SYS_I2C_EEPROM_BUS") which only fixed it without CONFIG_SYS_I2C_EEPROM_BUS defined. Signed-off-by: Simon Goldschmidt <simon.k.r.goldschmidt(a)gmail.com> --- Please amend to commit 3c43ab903d33 in u-boot-socfpga/master --- cmd/eeprom.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/cmd/eeprom.c b/cmd/eeprom.c index 9e44960c7d..7b1f81477f 100644 --- a/cmd/eeprom.c +++ b/cmd/eeprom.c @@ -168,7 +168,7 @@ static int eeprom_rw(unsigned dev_addr, unsigned offset, uchar *buffer, uchar addr[3]; #if defined(CONFIG_SYS_I2C_EEPROM_BUS) - i2c_set_bus_num(CONFIG_SYS_I2C_EEPROM_BUS); + eeprom_init(CONFIG_SYS_I2C_EEPROM_BUS); #endif while (offset < end) { -- 2.17.1

2 2

[U-Boot] evb-rk3328_defconfig: dtc: option requires an argument
by Matwey V. Kornilov 24 Apr '19

24 Apr '19

Hello, I am building u-boot master as the following make evb-rk3328_defconfig make all make u-boot.itb What I see it the following error: LD u-boot OBJCOPY u-boot-nodtb.bin start=$(aarch64-suse-linux-nm u-boot | grep __rel_dyn_start | cut -f 1 -d ' '); end=$(aarch64-suse-linux-nm u-boot | grep __rel_dyn_end | cut -f 1 -d ' '); tools/relocate-rela u-boot-nodtb.bin 0x00200000 $start $end MKIMAGE u-boot.itb dtc: option requires an argument -- 'p' Usage: dtc [options] <input file> Options: -[qI:O:o:V:d:R:S:p:a:fb:i:H:sW:E:@Ahv] -q, --quiet [skipped] -v, --version Print version and exit Error: unknown option ./tools/mkimage: Can't open 0x0.tmp: No such file or directory make[1]: *** [/usr/src/u-boot/Makefile:1247: u-boot.itb] Error 255 My dtc version is 1.4.4

1 0

[U-Boot] [PATCH 1/1] test/py: pytest.mark.notbuildconfigspec()
by Heinrich Schuchardt 24 Apr '19

24 Apr '19

We already can let a Python test depend on a build option being set via @pytest.mark.buildconfigspec(). It may be necessary to let a test depend on a build option *not* being set. So let's introduce @pytest.mark.notbuildconfigspec for this purpose. Signed-off-by: Heinrich Schuchardt <xypron.glpk(a)gmx.de> --- Hello Tom, I will introduce the patch via u-boot-efi.git. Regards Heinrich --- test/py/README.md | 1 + test/py/conftest.py | 14 +++++++++----- 2 files changed, 10 insertions(+), 5 deletions(-) diff --git a/test/py/README.md b/test/py/README.md index 4d9d2b81d1..2156661d6c 100644 --- a/test/py/README.md +++ b/test/py/README.md @@ -310,6 +310,7 @@ instances of: - `buildconfig.get(...` - `@pytest.mark.buildconfigspec(...` +- `@pytest.mark.notbuildconfigspec(...` ### Complete invocation example diff --git a/test/py/conftest.py b/test/py/conftest.py index e40cbf0ba1..00d8ef8ba9 100644 --- a/test/py/conftest.py +++ b/test/py/conftest.py @@ -460,11 +460,15 @@ def setup_buildconfigspec(item): """ mark = item.get_marker('buildconfigspec') - if not mark: - return - for option in mark.args: - if not ubconfig.buildconfig.get('config_' + option.lower(), None): - pytest.skip('.config feature "%s" not enabled' % option.lower()) + if mark: + for option in mark.args: + if not ubconfig.buildconfig.get('config_' + option.lower(), None): + pytest.skip('.config feature "%s" not enabled' % option.lower()) + notmark = item.get_marker('notbuildconfigspec') + if notmark: + for option in notmark.args: + if ubconfig.buildconfig.get('config_' + option.lower(), None): + pytest.skip('.config feature "%s" enabled' % option.lower()) def tool_is_in_path(tool): for path in os.environ["PATH"].split(os.pathsep): -- 2.20.1

3 2

[U-Boot] trouble booting spl/u-boot from emmc on i.mx6ul
by Robert Cagle 24 Apr '19

24 Apr '19

I am trying to debug a failure to boot spl/u-boot on an NXP i.mx6ul using emmc. I'm using u-boot source from: https://github.com/Freescale/u-boot-fslc.git -b 2017.11+fslc and I'm building target mx6ul_14x14_evk_defconfig. I asked for help on the "NXP Community Forum" but was referred here since NXP apparently doesn't support spl configurations. I'm hoping somebody here might be familiar enough with this soc to help. Basically I get a brick after reset, with no output on the console. My jtag interface won't let me halt the cpu immediately after reset, but I can still poke around. I can see the ivt (initial part of spl image) loaded in ocram, but the code at the spl entry point is not correct (more details below). However, if I manually reload (sdp or jtag) the spl image it runs fine. I can also load and run the same spl image on an sd card on a similar reference board (same soc/ddr, but sd instead of emmc). So I think the spl image itself is okay. I should also mention that I can use an older, non-spl u-boot image that boots from emmc just fine, so I think my hw bootmode/emmc jumpers are okay. The big difference is the older u-boot is a monolithic u-boot.imx image (ivt + dcd + u-boot.bin) rather than a split spl + u-boot.img. For anyone familiar with i.mx6ul boot details, here is what I've tried: a) checking imx_usb_loader scripts to make sure emmc installation was done correctly. dd if=/dev/zero of=/dev/mmcblk1 bs=1k seek=512 conv=fsync count=8 echo 0 > /sys/block/mmcblk1boot0/force_ro dd if=SPL of=/dev/mmcblk1boot0 bs=512 seek=2 dd if=u-boot.img of=/dev/mmcblk1boot0 bs=512 seek=138 echo 1 > /sys/block/mmcblk1boot0/force_ro mmc bootpart enable 1 1 /dev/mmcblk1 # My emmc has an 8g user area and two 16MiB boot partitions. # I've tried zeroing them all out and writing the spl image to one # at a time to verify I am programming/using the correct area # of flash. Everything appears ok, and I am able to boot my # 2015 version of u-boot from emmc using the same steps. b) checking the extcsd info on the emmc to make sure boot partition is enabled. Also played around with Boot bus conditions but wound up leaving them at 0x0. Boot configuration bytes [PARTITION_CONFIG: 0x48] Boot Partition 1 enabled No access to boot partition Boot bus Conditions [BOOT_BUS_CONDITIONS: 0x00] # I've tried all combinations I could find, none worked better, # many worked worse. c) after reset, checking smbr1/sbmr2 (they look mostly ok) sbmr1=10004860 [cfg4: 10 - ECSPIx_SS1 - pulled high by mistake, shouldn't hurt?] [cfg3: 00 - reserved] [cfg2: 48 - 8-bit, eSDHC2, 0-500/400mhz, 3.3v] [cfg1: 60 - emmc, regular-boot, high-speed, fast-boot-ack-enb, no-sd-power-cyc, thru-sd] sbmr2=02000041 [bmod=internal, 4=??, sec_config=open] d) after reset, checking whether ivt got loaded in ocram (it was). J-Link>mem32 907400,c 00907400 = 402000D1 00908000 00000000 00000000 00907410 = 00907420 00907400 00000000 00000000 00907420 = 00907000 0000D000 00000000 400400D2 e) checking spl ivt header for correctness (looks ok) (script from https://community.nxp.com/docs/DOC-102453) $ python3 imxbin.py SPL =================IVT data=================== ivt_length=20 ivt_entry=908000 ivt_dcd=0 ivt_boot_data=907420 ivt_self=907400 ivt_csf=0 =================DCD data=================== No DCD data in table f) after reset, checking whether code got loaded into ocram (usually not!) Why is ivt okay but this never got loaded or was it overwritten? J-Link>mem32 908000,8 00908000 = 5880BCE7 9EB3322F E4B82B75 BCA61DFB 00908010 = D81D695D 59B3F13D 483D24F5 21F92F47 when loading from usb-sdp this ocram location contains correct spl code, and it stays there all the way thru the main u-boot prompt. why the difference? J-Link>mem32 908000,8 00908000 = EA00000F E59FF014 E59FF014 E59FF014 00908010 = E59FF014 E59FF014 E59FF014 E59FF014 Any other ideas on how to debug this? It seems like (f) is a big clue, but I don't know where to go with it. Sorry for the length of this email! Bob Cagle

1 0

[U-Boot] [RFC] Migrating iMX LCDIF drivers to Driver Model
by Peng Fan 24 Apr '19

24 Apr '19

HI Igor, > > Marek, Peng, > > Writing to you as you were the main contributors to U-boot mxsfb driver > implementation (i.MX23/i.MX28 LCDIF driver). > > I was about to start working on it's migration to DM (currently mxsfb is being > used on our SoM Colibri iMX7S/D), but found it a bit out-dated (no one > introduced any changes for the last 5 years) and maybe it's really does make a > sense to fetch and port the latest one from the Linux mainline (in a sake of > avoiding divergence in implementation and continue fetching future updates > from the Linux kernel). > > So there are 2 questions spinning in my mind: > 1) In case if you are maybe aware, if there were any intentions to do this > migration before? (maybe someone asked similar questions or even send > some patches, but didn't manage to upstream that; or did similar stuff in some > downstream U-boot forks, whatever). Unfortunately I can't any information > regarding this in U-boot ML archives . I do not have plan to work on this recently. > > 2) Will it be OK if I introduce a brand new mxsfb driver (ported from Linux), > which will be used only when U-boot is built with CONFIG_DM_VIDEO > enabled? Existing mxsfb will be left as it is, so I can be removed easily when > full migration to DM is done for all boards that are using this driver. You mean porting drivers/gpu/drm/mxsfb/ to U-Boot? Regards, Peng. > > Simon, > > Could you also provide you feedback for 2 (if introducing a brand new > dm-enabled driver is a good idea), thanks! > > Thanks in advance for you comments/suggestions! > > -- > Best regards - Freundliche Grüsse - Meilleures salutations > > Senior Development Engineer, > Igor Opaniuk > > Toradex AG > Altsagenstrasse 5 | 6048 Horw/Luzern | Switzerland | T: +41 41 500 48 > 00 (main line)

3 2