December 2019 - U-Boot

[PATCH v2 0/4] Add support for booting EFI FIT images
by Cristian Ciocaltea 11 Dec '19

11 Dec '19

Currently the only way to run an EFI binary like GRUB2 is via the 'bootefi' command, which cannot be used in a verified boot scenario. The obvious solution to this limitation is to add support for booting FIT images containing those EFI binaries. The implementation relies on a new image type - IH_OS_EFI - which can be created by using 'os = "efi"' inside an ITS file: / { #address-cells = <1>; images { efi-grub { description = "GRUB EFI"; data = /incbin/("EFI/BOOT/bootarm.efi"); type = "kernel_noload"; arch = "arm"; os = "efi"; compression = "none"; load = <0x0>; entry = <0x0>; hash-1 { algo = "sha256"; }; }; }; configurations { default = "config-grub"; config-grub { kernel = "efi-grub"; signature-1 { algo = "sha256,rsa2048"; sign-images = "kernel"; }; }; }; }; The bootm command has been extended to handle the IH_OS_EFI images. To enable this feature, a new configuration option has been added: BOOTM_EFI I tested the solution using the 'qemu_arm' board: => load scsi 0:1 ${kernel_addr_r} efi-image.fit => bootm ${kernel_addr_r}#config-grub Changes since v1: * Rebase patches on Heinrich Schuchardt's patch series: efi_loader: prepare for FIT images https://lists.denx.de/pipermail/u-boot/2019-December/393192.html * Add sample configuration: doc/uImage.FIT/uefi.its * Update uefi documentation: doc/uefi/uefi.rst Cristian Ciocaltea (4): image: Add IH_OS_EFI for EFI chain-load boot bootm: Add a bootm command for type IH_OS_EFI doc: Add sample uefi.its image description file doc: uefi.rst: Document launching UEFI binaries from FIT images cmd/Kconfig | 7 +++++ common/bootm_os.c | 61 +++++++++++++++++++++++++++++++++++++ common/image-fit.c | 3 +- common/image.c | 1 + doc/uImage.FIT/uefi.its | 67 +++++++++++++++++++++++++++++++++++++++++ doc/uefi/uefi.rst | 34 +++++++++++++++++++++ include/image.h | 1 + 7 files changed, 173 insertions(+), 1 deletion(-) create mode 100644 doc/uImage.FIT/uefi.its -- 2.17.1

4 17

[U-Boot] [PATCH 0/2] sandbox: enable UEFI unit tests
by Heinrich Schuchardt 11 Dec '19

11 Dec '19

This patch series enables the UEFI unit tests on the sandbox. The first patch add the missing compatible property in the device trees which is required by on of the unit tests. The real time clock unit test will fail if the sandbox is openend without passing a device tree (parameter -D). A separate series will enable building UEFI binaries for the sandbox and enable the corresponding UEFI unit tests. Heinrich Schuchardt (2): sandbox: add missing compatible property in device tree configs: sandbox: enable CONFIG_CMD_BOOTEFI_SELFTEST arch/sandbox/dts/sandbox.dts | 1 + arch/sandbox/dts/sandbox64.dts | 1 + configs/sandbox64_defconfig | 1 + configs/sandbox_defconfig | 1 + configs/sandbox_flattree_defconfig | 1 + configs/sandbox_spl_defconfig | 1 + 6 files changed, 6 insertions(+) -- 2.24.0.rc1

2 10

Please pull u-boot-video
by Anatolij Gustschin 11 Dec '19

11 Dec '19

Hi Tom, please pull fixes for v2020.01. gitlab CI: https://gitlab.denx.de/u-boot/custodians/u-boot-video/pipelines/1599 Travis-CI: https://travis-ci.org/vdsao/u-boot-video/builds/623099426 Thanks, Anatolij The following changes since commit 28a4516cf154d6f7e738f8e0519b41eccef5af5c: Merge branch '2019-12-05-master-imports' (2019-12-05 16:37:36 -0500) are available in the Git repository at: https://gitlab.denx.de/u-boot/custodians/u-boot-video.git tags/fixes-for-2020.01 for you to fetch changes up to 2cc393f32fd9ffcf47f4877e8d1345a7981a0d02: video: make BPP and ANSI configs optional (2019-12-06 16:38:51 +0100) ---------------------------------------------------------------- - fix crash and board reset when drawing RLE8 bitmaps bigger than the framebuffer resolution - reduce dead code in video and console uclass routines (tested on mx53cx9020, sama5d2_xplained, stm32mp157c-ev1, stm32f746-disco, stm32f769-disco and wandboard) ---------------------------------------------------------------- Anatolij Gustschin (2): video: add guards around 16bpp/32bbp code video: make BPP and ANSI configs optional Patrice Chotard (2): video: bmp: Fix video_splash_align_axis() video: bmp: Fix video_display_rle8_bitmap() configs/apalis_imx6_defconfig | 1 + configs/at91sam9x5ek_dataflash_defconfig | 1 + configs/at91sam9x5ek_mmc_defconfig | 1 + configs/at91sam9x5ek_nandflash_defconfig | 1 + configs/at91sam9x5ek_spiflash_defconfig | 1 + configs/chromebit_mickey_defconfig | 2 ++ configs/chromebook_jerry_defconfig | 2 ++ configs/chromebook_minnie_defconfig | 2 ++ configs/chromebook_speedy_defconfig | 2 ++ configs/colibri-imx6ull_defconfig | 3 +++ configs/colibri_imx6_defconfig | 1 + configs/colibri_imx7_defconfig | 3 +++ configs/colibri_imx7_emmc_defconfig | 3 +++ configs/colibri_t20_defconfig | 2 ++ configs/colibri_vf_defconfig | 1 + configs/evb-px30_defconfig | 3 +++ configs/evb-rk3288_defconfig | 2 ++ configs/evb-rk3399_defconfig | 2 ++ configs/firefly-rk3288_defconfig | 2 ++ configs/gazerbeam_defconfig | 3 +++ configs/ge_bx50v3_defconfig | 1 + configs/gurnard_defconfig | 2 ++ configs/harmony_defconfig | 2 ++ configs/imx6dl_icore_nand_defconfig | 1 + configs/imx6q_icore_nand_defconfig | 1 + configs/imx6qdl_icore_mmc_defconfig | 1 + configs/imx6qdl_icore_nand_defconfig | 1 + configs/libretech-ac_defconfig | 1 + configs/libretech-cc_defconfig | 1 + configs/m53menlo_defconfig | 1 + configs/medcom-wide_defconfig | 2 ++ configs/miqi-rk3288_defconfig | 2 ++ configs/mx53cx9020_defconfig | 1 + configs/mx6sabreauto_defconfig | 1 + configs/mx6sabresd_defconfig | 1 + configs/mx6ul_14x14_evk_defconfig | 3 +++ configs/mx6ul_9x9_evk_defconfig | 3 +++ configs/novena_defconfig | 1 + configs/nyan-big_defconfig | 1 + configs/opos6uldev_defconfig | 1 + configs/paz00_defconfig | 2 ++ configs/peach-pi_defconfig | 2 ++ configs/peach-pit_defconfig | 2 ++ configs/pico-dwarf-imx7d_defconfig | 3 +++ configs/pico-hobbit-imx7d_defconfig | 3 +++ configs/pico-imx7d_bl33_defconfig | 3 +++ configs/pico-imx7d_defconfig | 3 +++ configs/pico-nymph-imx7d_defconfig | 3 +++ configs/pico-pi-imx7d_defconfig | 3 +++ configs/pm9261_defconfig | 2 ++ configs/pm9263_defconfig | 2 ++ configs/puma-rk3399_defconfig | 2 ++ configs/rock2_defconfig | 2 ++ configs/rpi_0_w_defconfig | 1 + configs/rpi_2_defconfig | 1 + configs/rpi_3_32b_defconfig | 1 + configs/rpi_3_b_plus_defconfig | 1 + configs/rpi_3_defconfig | 1 + configs/rpi_4_32b_defconfig | 1 + configs/rpi_4_defconfig | 1 + configs/rpi_arm64_defconfig | 1 + configs/rpi_defconfig | 1 + configs/sama5d27_som1_ek_mmc1_defconfig | 1 + configs/sama5d27_som1_ek_mmc_defconfig | 1 + configs/sama5d27_som1_ek_qspiflash_defconfig | 1 + configs/sama5d27_wlsom1_ek_mmc_defconfig | 1 + configs/sama5d27_wlsom1_ek_qspiflash_defconfig | 1 + configs/sama5d2_xplained_emmc_defconfig | 1 + configs/sama5d2_xplained_mmc_defconfig | 1 + configs/sama5d2_xplained_qspiflash_defconfig | 1 + configs/sama5d2_xplained_spiflash_defconfig | 1 + configs/sama5d36ek_cmp_mmc_defconfig | 1 + configs/sama5d36ek_cmp_nandflash_defconfig | 1 + configs/sama5d36ek_cmp_spiflash_defconfig | 1 + configs/sama5d3xek_mmc_defconfig | 3 +++ configs/sama5d3xek_nandflash_defconfig | 3 +++ configs/sama5d3xek_spiflash_defconfig | 3 +++ configs/sama5d4_xplained_mmc_defconfig | 1 + configs/sama5d4_xplained_nandflash_defconfig | 1 + configs/sama5d4_xplained_spiflash_defconfig | 1 + configs/sama5d4ek_mmc_defconfig | 1 + configs/sama5d4ek_nandflash_defconfig | 1 + configs/sama5d4ek_spiflash_defconfig | 1 + configs/sandbox64_defconfig | 1 + configs/sandbox_defconfig | 1 + configs/sandbox_flattree_defconfig | 1 + configs/sandbox_spl_defconfig | 1 + configs/seaboard_defconfig | 2 ++ configs/sei510_defconfig | 1 + configs/sei610_defconfig | 1 + configs/snow_defconfig | 2 ++ configs/spring_defconfig | 2 ++ configs/stm32f746-disco_defconfig | 3 +++ configs/stm32f769-disco_defconfig | 3 +++ configs/stm32mp15_basic_defconfig | 3 +++ configs/stm32mp15_optee_defconfig | 3 +++ configs/stm32mp15_trusted_defconfig | 3 +++ configs/tec_defconfig | 2 ++ configs/theadorable_debug_defconfig | 1 + configs/tinker-s-rk3288_defconfig | 2 ++ configs/ventana_defconfig | 2 ++ configs/vyasa-rk3288_defconfig | 2 ++ configs/wandboard_defconfig | 1 + drivers/video/Kconfig | 8 ++++---- drivers/video/console_normal.c | 10 +++++----- drivers/video/vidconsole-uclass.c | 6 ++++++ drivers/video/video-uclass.c | 4 ++++ drivers/video/video_bmp.c | 12 +++++------- 108 files changed, 195 insertions(+), 16 deletions(-)

2 1

[PATCH] i2c: i2c_cdns: fix write timeout on fifo boundary
by Michael Auchter 11 Dec '19

11 Dec '19

This fixes an issue that would cause I2C writes to timeout when the number of bytes is a multiple of the FIFO depth (i.e. 16 bytes). Within the transfer loop, after writing the data register with a new byte to transfer, if the transfer size equals the FIFO depth, the loop pauses until the INTERRUPT_COMP bit asserts to indicate data has been sent. This same check is performed after the loop as well to ensure data has been transferred prior to returning. In the case where the amount of data to be written is a multiple of the FIFO depth, the transfer loop would wait for the INTERRUPT_COMP bit to assert after writing the final byte, and then wait for this bit to assert once more. However, since the transfer has finished at this point, no new data has been written to the data register, and hence INTERRUPT_COMP will never assert. Fix this by only waiting for INTERRUPT_COMP in the transfer loop if there's still data to be written. Signed-off-by: Michael Auchter <michael.auchter(a)ni.com> --- drivers/i2c/i2c-cdns.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/i2c/i2c-cdns.c b/drivers/i2c/i2c-cdns.c index 2c0301ad08..ff3956d8c2 100644 --- a/drivers/i2c/i2c-cdns.c +++ b/drivers/i2c/i2c-cdns.c @@ -265,7 +265,7 @@ static int cdns_i2c_write_data(struct i2c_cdns_bus *i2c_bus, u32 addr, u8 *data, while (len-- && !is_arbitration_lost(regs)) { writel(*(cur_data++), &regs->data); - if (readl(&regs->transfer_size) == CDNS_I2C_FIFO_DEPTH) { + if (len && readl(&regs->transfer_size) == CDNS_I2C_FIFO_DEPTH) { ret = cdns_i2c_wait(regs, CDNS_I2C_INTERRUPT_COMP | CDNS_I2C_INTERRUPT_ARBLOST); if (ret & CDNS_I2C_INTERRUPT_ARBLOST) -- 2.23.0

3 3

[PATCH] ddr: imx8m: Return error values from LPDDR4 training
by Schrempf Frieder 11 Dec '19

11 Dec '19

From: Frieder Schrempf <frieder.schrempf(a)kontron.de> In cases when the same SPL should run on boards with i.MX8MM, that differ in DDR configuration, it is necessary to try different parameters and check if the training done by the firmware suceeds or not. Therefore we return the DDR training/initialization success to the upper layer in order to be able to retry with different settings if necessary. Signed-off-by: Frieder Schrempf <frieder.schrempf(a)kontron.de> --- arch/arm/include/asm/arch-imx8m/ddr.h | 6 +++--- drivers/ddr/imx/imx8m/ddr_init.c | 11 +++++++++-- drivers/ddr/imx/imx8m/ddrphy_train.c | 9 +++++++-- drivers/ddr/imx/imx8m/ddrphy_utils.c | 8 ++++---- 4 files changed, 23 insertions(+), 11 deletions(-) diff --git a/arch/arm/include/asm/arch-imx8m/ddr.h b/arch/arm/include/asm/arch-imx8m/ddr.h index 53d46256d8..7a2a2d8edc 100644 --- a/arch/arm/include/asm/arch-imx8m/ddr.h +++ b/arch/arm/include/asm/arch-imx8m/ddr.h @@ -703,14 +703,14 @@ struct dram_timing_info { extern struct dram_timing_info dram_timing; void ddr_load_train_firmware(enum fw_type type); -void ddr_init(struct dram_timing_info *timing_info); -void ddr_cfg_phy(struct dram_timing_info *timing_info); +int ddr_init(struct dram_timing_info *timing_info); +int ddr_cfg_phy(struct dram_timing_info *timing_info); void load_lpddr4_phy_pie(void); void ddrphy_trained_csr_save(struct dram_cfg_param *param, unsigned int num); void dram_config_save(struct dram_timing_info *info, unsigned long base); /* utils function for ddr phy training */ -void wait_ddrphy_training_complete(void); +int wait_ddrphy_training_complete(void); void ddrphy_init_set_dfi_clk(unsigned int drate); void ddrphy_init_read_msg_block(enum fw_type type); diff --git a/drivers/ddr/imx/imx8m/ddr_init.c b/drivers/ddr/imx/imx8m/ddr_init.c index d6e915c9b9..e927f0896d 100644 --- a/drivers/ddr/imx/imx8m/ddr_init.c +++ b/drivers/ddr/imx/imx8m/ddr_init.c @@ -20,9 +20,10 @@ void ddr_cfg_umctl2(struct dram_cfg_param *ddrc_cfg, int num) } } -void ddr_init(struct dram_timing_info *dram_timing) +int ddr_init(struct dram_timing_info *dram_timing) { unsigned int tmp, initial_drate, target_freq; + int ret; printf("DDRINFO: start DRAM init\n"); @@ -98,7 +99,11 @@ void ddr_init(struct dram_timing_info *dram_timing) * accessing relevant PUB registers */ debug("DDRINFO:ddrphy config start\n"); - ddr_cfg_phy(dram_timing); + + ret = ddr_cfg_phy(dram_timing); + if (ret) + return ret; + debug("DDRINFO: ddrphy config done\n"); /* @@ -165,4 +170,6 @@ void ddr_init(struct dram_timing_info *dram_timing) /* save the dram timing config into memory */ dram_config_save(dram_timing, CONFIG_SAVED_DRAM_TIMING_BASE); + + return 0; } diff --git a/drivers/ddr/imx/imx8m/ddrphy_train.c b/drivers/ddr/imx/imx8m/ddrphy_train.c index 18f7ed7fea..306af82504 100644 --- a/drivers/ddr/imx/imx8m/ddrphy_train.c +++ b/drivers/ddr/imx/imx8m/ddrphy_train.c @@ -8,13 +8,14 @@ #include <asm/arch/ddr.h> #include <asm/arch/lpddr4_define.h> -void ddr_cfg_phy(struct dram_timing_info *dram_timing) +int ddr_cfg_phy(struct dram_timing_info *dram_timing) { struct dram_cfg_param *dram_cfg; struct dram_fsp_msg *fsp_msg; unsigned int num; int i = 0; int j = 0; + int ret; /* initialize PHY configuration */ dram_cfg = dram_timing->ddrphy_cfg; @@ -60,7 +61,9 @@ void ddr_cfg_phy(struct dram_timing_info *dram_timing) dwc_ddrphy_apb_wr(0xd0099, 0x0); /* Wait for the training firmware to complete */ - wait_ddrphy_training_complete(); + ret = wait_ddrphy_training_complete(); + if (ret) + return ret; /* Halt the microcontroller. */ dwc_ddrphy_apb_wr(0xd0099, 0x1); @@ -83,4 +86,6 @@ void ddr_cfg_phy(struct dram_timing_info *dram_timing) /* save the ddr PHY trained CSR in memory for low power use */ ddrphy_trained_csr_save(ddrphy_trained_csr, ddrphy_trained_csr_num); + + return 0; } diff --git a/drivers/ddr/imx/imx8m/ddrphy_utils.c b/drivers/ddr/imx/imx8m/ddrphy_utils.c index e60503309e..863fb43897 100644 --- a/drivers/ddr/imx/imx8m/ddrphy_utils.c +++ b/drivers/ddr/imx/imx8m/ddrphy_utils.c @@ -84,7 +84,7 @@ static inline void decode_streaming_message(void) debug("\n"); } -void wait_ddrphy_training_complete(void) +int wait_ddrphy_training_complete(void) { unsigned int mail; @@ -95,10 +95,10 @@ void wait_ddrphy_training_complete(void) decode_streaming_message(); } else if (mail == 0x07) { debug("Training PASS\n"); - break; + return 0; } else if (mail == 0xff) { - printf("Training FAILED\n"); - break; + debug("Training FAILED\n"); + return -1; } } } -- 2.17.1

1 0

[PATCH] rockchip: make_fit_atf: explicitly use python3
by ml＠embed.me.uk 11 Dec '19

11 Dec '19

From: Jack Mitchell <ml(a)embed.me.uk> On a distribution with no python2 installed and no python->python3 symlink the script will fail to execute. Specify python3 explicitly as it's already a requirement to build u-boot. Signed-off-by: Jack Mitchell <ml(a)embed.me.uk> --- arch/arm/mach-rockchip/make_fit_atf.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/mach-rockchip/make_fit_atf.py b/arch/arm/mach-rockchip/make_fit_atf.py index 3c045a5e17..c79317d6c5 100755 --- a/arch/arm/mach-rockchip/make_fit_atf.py +++ b/arch/arm/mach-rockchip/make_fit_atf.py @@ -1,4 +1,4 @@ -#!/usr/bin/env python +#!/usr/bin/env python3 """ # SPDX-License-Identifier: GPL-2.0+ # -- 2.24.0

2 1

FOSDEM Hardware Enablement Devroom: call for speakers.
by Luc Verhaegen 10 Dec '19

10 Dec '19

Hi, At FOSDEM on sunday the 2nd of february 2020, there will be another hardware enablement DevRoom. URL: https://fosdem.org/2020/ This devroom covers topics related to hardware support and enablement with free software. It includes the following topics: * peripheral/controller firmwares * hw support and drivers in bootloaders * kernel drivers and hardware interfaces * hardware-related adaptation in operating systems * tools for firmware flashing * tools for low-level development FOSDEM is very much an open source community event, please refrain from turning in a talk that is meant to be purely corporate or a product commercial. Also, this is a highly technical devroom on a conference aimed at developers and advanced users, so only submit a talk on a subject you actually are involved with. Finally, this devrooms focus is the technical aspects of the hardware and its enablement in free projects, rather than the specific applications and use cases that benefit from it. With the return of the Embedded and Automotive DevRoom, we have the ability to schedule full hour talks again, and to go in-depth. If you however only need half an hour, then this is of course also possible. Talk Submission: The venerable pentabarf system will once again be used for talk submission. https://penta.fosdem.org/submission/FOSDEM20 When in pentabarf, spend some time on the abstract and description, for both the event and the speaker. The abstract should be a shortened description, and the event abstract will sometimes even be printed directly in the booklet. BUT, on the website the abstract is immediately followed by the full description. If your abstract is fully descriptive, while terse, you might get away with just the abstract. As soon as your talk is scheduled by the devroom managers, you can see the result of your handiwork on the main website. Please re-use your old pentabarf account instead of creating a new one: lost password: https://penta.fosdem.org/user/forgot_password Talks are either 50 minutes or 20 minutes long, plus 5 minutes for questions. All talks will be recorded, and will be streamed out live, and will later be made available as CC-BY, sometimes minutes after your talk has finished. As for deadlines, the fosdem organizers want to have a finished schedule by the 15th of december, but do not count on that deadline, there are only a limited number of slots available. Given my belatedness in sending out this CFP, i might get a few more days if i am really really nice to the core FOSDEM organizers, but again, do not count on that (extra hugs only go so far when you're built like i am). On your personal page: * General: * First and last name * Nickname * Image * Contact: * email address * mobile number (this is a very hard requirement as there will be no other reliable form of emergency communication on the day) * Description: * Abstract * Description Create an event: * On the General page: * Event title * Event subtitle. * Track: Hardware Enablement Devroom * Event type: Lecture (talk) or Meeting (BoF) * Persons: * Add yourself as speaker. * Description: * Abstract: * Full Description * Schedule: * select your preferred talk length, either 55 or 25 minutes. * Links: * Add relevant links. The mobile phone number is the hardest requirement, so you can be contacted on-the-day when something comes up. Speakers will all receive my mobile number in return. Neither email nor phonenumber are publicy visible, nor will this information be used for anything outside of devroom organization. After your talk has been scheduled, i usually only send out a single email with some organizational details in the days before the event. Everything else can be ignored or will be filled in by me or the FOSDEM organizers. I will be keeping a keen eye on your submissions and will come back with further questions or make small fixes as needed. Feel free to poke me with any questions or anything, both on irc (libv@freenode) and on email (hardware-devroom-manager(a)fosdem.org). That's about it. Hope to see you all at FOSDEM :) Luc Verhaegen.

1 0

[U-Boot] [PATCH 0/5] remoteproc: add elf resource table loader
by Fabien Dessenne 10 Dec '19

10 Dec '19

Add some helpers that can be called by the drivers to load the firmware resource table from an elf32 / elf64 image. The stm32 remoteproc driver makes use of it, to load the resource table before the elf image itself. This series applies on top of the "remoteproc: Add support for R5F and DSP processors" series [1] proposed by Lokesh Vutla which introduces the elf64 support. [1]: https://patchwork.ozlabs.org/project/uboot/list/?series=128946 Fabien Dessenne (5): remoteproc: elf_loader: Add elf resource table load support stm32mp1: declare backup register for copro resource table address remoteproc: stm32: load resource table from firmware stm32mp1: Fixup the Linux DeviceTree with coprocessor information remoteproc: stm32: invert the is_running() return value arch/arm/mach-stm32mp/include/mach/stm32.h | 1 + board/st/stm32mp1/stm32mp1.c | 16 +- drivers/remoteproc/rproc-elf-loader.c | 269 +++++++++++++++++++++++++++++ drivers/remoteproc/stm32_copro.c | 17 +- include/remoteproc.h | 70 ++++++++ test/dm/remoteproc.c | 91 ++++++++-- 6 files changed, 448 insertions(+), 16 deletions(-) -- 2.7.4

4 18

serial_bcm283x_mu driver crashes on RPi CM 1
by Ed Rose 10 Dec '19

10 Dec '19

Hi all, I've been working on a project recently that uses a Raspberry Pi Compute Module 1, and it uses U-Boot as a bootloader. The main UART port is required for the project, so the mini-UART is required to be used for the console. Unfortunately I've not been able to get U-Boot to boot when enabling the mini-UART port, and I'm only greeted by a rainbow splash screen when I enable it and select it for use as the console. Some background on the work I've done to get to this point: - I'm using U-Boot 2019.10 as a base. - I made a copy of /arch/arm/dts/bcm2835-rpi-cm1-io1.dts and appended the following line to the end to enable the secondary UART port: &uart1 { pinctrl-names = "default"; pinctrl-0 = <&uart1_gpio14>; status = "okay"; }; This new dts file is added to the Makefile and selected in KConfig. - I modified /drivers/serial/serial_bcm283x_mu.c to remove the checks for pin MUXing. Since this only checks GPIO14, it wasn't going to work when the pin is actually on GPIO 40 and the check was useless for my purposes anyway. - I set CONSOLE_CONS_INDEX to 2 (selecting serial1) in KConfig. This selects the mini-UART which is set as serial1 in the aliases in /arch/arc/dts/bcm283x.dtsi. The result of this is that the rainbow splash screen comes up and nothing is sent from either serial port. However if I set CONFIG_CONS_INDEX to 1, I get output on the main UART port as normal. Setting CONFIG_OF_BOARD instead of CONFIG_OF_EMBED makes no difference. There was a time where I was able to get some early boot messages, and setting CONFIG_CONS_INDEX to 2 did cause U-Boot to select the mini-UART, but the messages stopped just before relocation. Again, changing the console index back to 1 would select the main UART and the messages would continue all the way to boot. I haven't been able to get these early messages to work recently however. I have a slight suspicion that it may be something to do with pin MUXing, since changing the uart0 pins in the device-tree to GPIO 32 causes the console to TX over both GPIO 32 and GPIO 14, but nothing can be received on either port. This doesn't seem like the correct behaviour. At this point I'm really stuck. I'm able to modify the DTS to set the pin MUXings (I hope anyway), and I can select the correct serial port, however I can't debug this any further since the crash prevents any debug info from coming out of the board on 2019.10, even if I enable early UART debugging. Has anyone successfully managed to get this UART port working on the Compute Modules? Or have any tips on how to debug it? I'm very appreciative of any help I can get. Kindest regards, Ed

1 0

[PATCH] drivers: net: fsl_enetc: Pass on primary MAC address to Linux
by Alex Marginean 10 Dec '19

10 Dec '19

Passes on the primary address used by u-boot to Linux. The code does a DT fix-up for ENETC PFs and sets the primary MAC address in IERB. The address in IERB is restored on ENETC PCI functions at FLR. Signed-off-by: Alex Marginean <alexandru.marginean(a)nxp.com> --- The code is called fom ft_board_setup in board/freescale/ls1028a/ls1028a.c mostly for consistency with other LS parts. I'm open to suggestions though. board/freescale/ls1028a/ls1028a.c | 4 ++ drivers/net/fsl_enetc.c | 65 ++++++++++++++++++++++++++++++- 2 files changed, 68 insertions(+), 1 deletion(-) diff --git a/board/freescale/ls1028a/ls1028a.c b/board/freescale/ls1028a/ls1028a.c index 3977ecf896..fac03f55e9 100644 --- a/board/freescale/ls1028a/ls1028a.c +++ b/board/freescale/ls1028a/ls1028a.c @@ -150,6 +150,10 @@ int ft_board_setup(void *blob, bd_t *bd) fdt_fixup_icid(blob); +#ifdef CONFIG_FSL_ENETC + fdt_fixup_enetc_mac(blob); +#endif + return 0; } #endif diff --git a/drivers/net/fsl_enetc.c b/drivers/net/fsl_enetc.c index 02c1ee70d9..f8fe7d4d8d 100644 --- a/drivers/net/fsl_enetc.c +++ b/drivers/net/fsl_enetc.c @@ -14,6 +14,69 @@ #include "fsl_enetc.h" +#define ENETC_DRIVER_NAME "enetc_eth" + +/* + * sets the MAC address in IERB registers, this setting is persistent and + * carried over to Linux. + */ +static void enetc_set_ierb_primary_mac(struct udevice *dev, int devfn, + const u8 *enetaddr) +{ +#ifdef CONFIG_ARCH_LS1028A +/* + * LS1028A is the only part with IERB at this time and there are plans to change + * its structure, keep this LS1028A specific for now + */ +#define IERB_BASE 0x1f0800000ULL +#define IERB_PFMAC(pf, vf, n) (IERB_BASE + 0x8000 + (pf) * 0x100 + (vf) * 8 \ + + (n) * 4) + +static int ierb_fn_to_pf[] = {0, 1, 2, -1, -1, -1, 3}; + + u16 lower = *(const u16 *)(enetaddr + 4); + u32 upper = *(const u32 *)enetaddr; + + if (ierb_fn_to_pf[devfn] < 0) + return; + + out_le32(IERB_PFMAC(ierb_fn_to_pf[devfn], 0, 0), upper); + out_le32(IERB_PFMAC(ierb_fn_to_pf[devfn], 0, 1), (u32)lower); +#endif +} + +/* sets up primary MAC addresses in DT/IERB */ +void fdt_fixup_enetc_mac(void *blob) +{ + struct pci_child_platdata *ppdata; + struct eth_pdata *pdata; + struct udevice *dev; + struct uclass *uc; + char path[256]; + int offset; + int devfn; + + uclass_get(UCLASS_ETH, &uc); + uclass_foreach_dev(dev, uc) { + if (!dev->driver || !dev->driver->name || + strcmp(dev->driver->name, ENETC_DRIVER_NAME)) + continue; + + pdata = dev_get_platdata(dev); + ppdata = dev_get_parent_platdata(dev); + devfn = PCI_FUNC(ppdata->devfn); + + enetc_set_ierb_primary_mac(dev, devfn, pdata->enetaddr); + + snprintf(path, 256, "/soc/pcie@1f0000000/ethernet@%x,%x", + PCI_DEV(ppdata->devfn), PCI_FUNC(ppdata->devfn)); + offset = fdt_path_offset(blob, path); + if (offset < 0) + continue; + fdt_setprop(blob, offset, "mac-address", pdata->enetaddr, 6); + } +} + /* * Bind the device: * - set a more explicit name on the interface @@ -551,7 +614,7 @@ static const struct eth_ops enetc_ops = { }; U_BOOT_DRIVER(eth_enetc) = { - .name = "enetc_eth", + .name = ENETC_DRIVER_NAME, .id = UCLASS_ETH, .bind = enetc_bind, .probe = enetc_probe, -- 2.17.1

3 3