April 2017 - U-Boot

[U-Boot] [PATCHv4] Retrieve MAC address from EEPROM
by Olliver Schinagl 10 Apr '17

10 Apr '17

This patch-series introduces methods to retrieve the MAC address from an onboard EEPROM. The series does a few small cleanups at the start, as either I ran into them while doing this series and fixed them along the way or actually depended on them. If you want to split the smaller ones off into a smaller series I understand, but again, I do somewhat depend on them. A manufacturer wants to produce boards and may even have MAC addresses for boards. Maintaining unique environments on a per-board basis however is horrible. Also this data should be very persistent, and not easily deletable by simply wiping the environment or device tree. Finally there are chips available on the market with a pre-programmed MAC address chips (proms) that a board manufacturer wants to use. Because of this, the MAC needs to be stored be able to read from such an 'external' source. The current idea of the eeprom layout, is to skip the first 8 bytes, so that other information can be stored there if needed, for example a header with some magic to identify the EEPROM. Or equivalent purposes. After those 8 bytes the MAC address follows the first macaddress. The macaddress is appended by a CRC8 byte and then padded to make for nice 8 bytes. Following the first macaddress one can store a second, or a third etc etc mac address. The CRC8 is optional (via a define) but is strongly recommended to have. It helps preventing user error and more importantly, checks if the bytes read are actually a user inserted address. E.g. only writing 1 macaddress into the eeprom but trying to consume 2. For the added tools, I explicitly did not use the wiser eth_validate_ethaddr_str(), eth_parse_enetaddr() and the ARP_HLEN define as it was quite painful (dependancies) to get these functions into the tools. I would suggest to merge as is, and if someone wants to improve these simple tools to use these functions to happily do so. These patches where tested on Olimex OLinuXino Lime1 (A10/A20), Lime2 (NAND and eMMC) and A20-OLinuXino-MICRO-4G variants and have been in use internally on our production systems since v2 of this patch set. To be able to replicate these tests the second series (which will be separate from this set) are needed. Left TODO: If U-Boot configures eth0 and eth1 it inserts these values into the environment. If the fdt then has an ethernet alias for ethernet0, with a MAC address for a different device, lets say eth2) things will not work at so well. I guess that leaves some discussion with a separated improvement patch as a reliable way is needed to match actual u-boot detected devices, with fdt described devices. E.g. is dev->name the same name to the fdt? Can we blindly match here? ======= Changes since v3: * Split off board specific stuff and only modify the generic functions * Make reading of an eeprom available to every board. By default this is unconfigure and thus should just fall through * Clean some minor bits up (ARP_HLEN) and use it more generically * Update the gen_ethaddr_crc as suggested by simon * Let the fixup_ethernet from fdt_common insert mac addresses to the environment for unconfigured devices. There is a small caveat here however as described in the TODO above. * Print the mac address that u-boot assigned to each device. Changes since v2: * Drop the id byte altogether and just mark it as reserved. The 'index' can be used to indicate the interface instead * Addopt the read_rom_hwaddr hooks * Renamed crc8 tool to gen_ethaddr_crc * Improved the layout EEPROM example * Made a function out of the hwaddress writing function in sunxi_emac so it can be re-used as the write_hwaddr net_ops hook. * No longer handle fdt parameters in board.c Changes since v1: * Do not CRC the id byte, move it just after the crc byte. One of the reasons I decided to move it after the crc8 was mostly due to mass generation of MAC + CRC combo's where the ID is still unknown. Also not crc-ing the ID means that it is much easier for a user to change it (via the u-boot i2c cmd line or from within linux) without having to worry about the crc. * Add a generator to convert a MAC address from the input to a MAC + CRC8 on the output.

10 75

Re: [U-Boot] [PATCH 0/2] Improve Raspberry Pi mmc writes.
by Jaehoon Chung 10 Apr '17

10 Apr '17

On 04/02/2017 03:58 PM, Alex Deymo wrote: > When experimenting with fastboot from U-Boot on the Raspberry Pi 3 we > found that the writes to the sdcard are much more slow than when > accessing it from the userspace. These two patches speed up the write > and allow us to reliably write the sdcard from U-Boot. I'm not sure you can see this email. If you can't receive this, I will resend with my gmail account. I want to know the situation after removing the BROKEN_R1B quirks. Best Regards, Jaehoon Chung > > Alex Deymo (1): > mmc: sdhci: Wait for SDHCI_INT_DATA_END when transferring. > > Jocelyn Bohr (1): > mmc: bcm2835_sdhci: Speed up mmc writes. > > drivers/mmc/bcm2835_sdhci.c | 8 ++++++-- > drivers/mmc/sdhci.c | 15 +++++++++++---- > 2 files changed, 17 insertions(+), 6 deletions(-) >

3 2

[U-Boot] [PATCH v2] mx6sabresd: README: Add eMMC boot configuration
by Breno Lima 10 Apr '17

10 Apr '17

Explain how to flash the eMMC and how to boot from it. Signed-off-by: Breno Lima <breno.lima(a)nxp.com> --- Changes since v1: - Add an extra section for booting from eMMC. board/freescale/mx6sabresd/README | 53 +++++++++++++++++++++++++++++++++------ 1 file changed, 46 insertions(+), 7 deletions(-) diff --git a/board/freescale/mx6sabresd/README b/board/freescale/mx6sabresd/README index 5814b9d..bcdbae6 100644 --- a/board/freescale/mx6sabresd/README +++ b/board/freescale/mx6sabresd/README @@ -3,15 +3,17 @@ How to use and build U-Boot on mx6sabresd: Currently there are three methods for booting mx6sabresd boards: -1. Booting via Normal U-Boot (u-boot.imx) +1. Booting from SD card via normal U-Boot (u-boot.imx) -2. Booting via SPL (SPL and u-boot.img) +2. Booting from eMMC via normal U-Boot -3. Booting via Falcon mode (SPL launches the kernel directly) +3. Booting via SPL (SPL and u-boot.img) +4. Booting via Falcon mode (SPL launches the kernel directly) -1. Booting via Normal U-Boot ----------------------------- + +1. Booting from SD card via normal U-Boot +----------------------------------------- $ make mx6qsabresd_defconfig (If you want to build for mx6qsabresd) @@ -28,7 +30,44 @@ This will generate the image called u-boot.imx. $ sudo dd if=u-boot.imx of=/dev/sdb bs=1K seek=1 && sync -2. Booting via SPL +2. Booting from eMMC via normal U-Boot +-------------------------------------- + +$ make mx6qsabresd_defconfig (If you want to build for mx6qsabresd) + +or + +$ make mx6dlsabresd_defconfig (If you want to build for mx6dlsabresd) + +$ make + +This will generate the image called u-boot.imx. + +- Flash the u-boot.imx binary into the eMMC: + +Set SW6 to download mode: 00001100 + +Plug a usb cable to USB-OTG and load the u-boot image using the imx_usb_loader +tool (https://github.com/boundarydevices/imx_usb_loader): + +$ sudo ./imx_usb u-boot.imx + +In U-boot change the eMMC partition config: + +=> mmc partconf 2 1 0 0 + +Mount the eMMC in the host PC: + +=> ums 0 mmc 2 + +Flash the u-boot.imx binary + +$ sudo dd if=u-boot.imx of=/dev/sdX bs=1K seek=1 && sync + +Set SW6 to eMMC 8-bit boot: 11010110 + + +3. Booting via SPL ------------------ Other method for building U-Boot on mx6qsabresd and mx6qpsabresd is @@ -48,7 +87,7 @@ $ sudo dd if=SPL of=/dev/sdb bs=1K seek=1 && sync $ sudo dd if=u-boot.img of=/dev/sdbbs=1K seek=69 && sync -3. Booting via Falcon mode +4. Booting via Falcon mode -------------------------- $ make mx6sabresd_spl_defconfig -- 2.7.4

1 0

[U-Boot] [RFC] Question about nfs_read_reply()
by Jaehoon Chung 10 Apr '17

10 Apr '17

Dear Joe, I have a question about nfs. I don't have a knowledge for NFS..So i don't know this is right or not.. When i have tested the latest u-boot(v2017.03), nfs doesn't work fine with Odroid-xu3. My question is a below thing...In net/nfs.c, nfs_read_reply() function is called the memcpy(). it should be copied the sizeof(rpc_pkt.u.reply))...is it really right? diff --git a/net/nfs.c b/net/nfs.c index 83ed0a7..09556c7 100644 --- a/net/nfs.c +++ b/net/nfs.c @@ -660,7 +660,8 @@ static int nfs_read_reply(uchar *pkt, unsigned len) debug("%s\n", __func__); memcpy(&rpc_pkt.u.data[0], pkt, sizeof(rpc_pkt.u.reply)); When i changed from "sizeof(rpc_pkt.u.reply)" to "len", it was working fine. Maybe i'm wrong..so i asked this to you... Best Regards, Jaehoon Chung

1 0

[U-Boot] [PATCH] armv8/fsl-layerscape: fdt: remove SYSCLK frequency fixup for ls1012a
by Yangbo Lu 10 Apr '17

10 Apr '17

Generally SYSCLK frequency is dependent on on-board switch settings. It may vary as per requirement, but this doesn't apply to ls1012a. ls1012a has its SYSCLK frequencies specified in the RM. The fixup for all 'fixed-clock' compatibles of ls1012a would cause incorrect SYSCLK frequency values. So remove the SYSCLK frequency fixup for ls1012a. Fixes: 6f14e25 ("armv8: fsl-lsch3: fixup SYSCLK frequency in device tree") Signed-off-by: Yangbo Lu <yangbo.lu(a)nxp.com> --- arch/arm/cpu/armv8/fsl-layerscape/fdt.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm/cpu/armv8/fsl-layerscape/fdt.c b/arch/arm/cpu/armv8/fsl-layerscape/fdt.c index c10ccf9..e59c232 100644 --- a/arch/arm/cpu/armv8/fsl-layerscape/fdt.c +++ b/arch/arm/cpu/armv8/fsl-layerscape/fdt.c @@ -161,8 +161,10 @@ void ft_cpu_setup(void *blob, bd_t *bd) "clock-frequency", CONFIG_SYS_NS16550_CLK, 1); #endif +#ifndef CONFIG_ARCH_LS1012A do_fixup_by_compat_u32(blob, "fixed-clock", "clock-frequency", CONFIG_SYS_CLK_FREQ, 1); +#endif #ifdef CONFIG_PCI ft_pci_setup(blob, bd); -- 2.1.0.27.g96db324

4 9

[U-Boot] Bug in emmc subsystem
by Arno Steffens 10 Apr '17

10 Apr '17

There seems to be a problem handling emmc with configured GP partition. Below the "mmc info". The problem might be that user capacity is calculated/shown as "0". At least it shows the GP1 partition with correct size - which is not the case for "mmc hwpartition" - it denies its existence ;) Can someone help me to fix this? Thanks a lot. - Arno >mmc info Device: sdhci at e0100000 Manufacturer ID: 13 OEM: 14e Name: Q1J54 Tran Speed: 52000000 Rd Block Len: 512 MMC version 5.0 High Capacity: Yes Capacity: 0 Bytes Bus Width: 4-bit Erase Group Size: 512 KiB HC WP Group Size: 8 MiB User Capacity: 0 Bytes WRREL Boot Capacity: 2 MiB ENH RPMB Capacity: 512 KiB ENH GP1 Capacity: 1.8 GiB ENH WRREL >mmc hwpartition Partition configuration: No enhanced user data area No GP1 partition No GP2 partition No GP3 partition No GP4 partition Card already partitioned Failed! >mmc read 0 0 1 MMC read: dev # 0, block # 0, count 1 ... MMC: block number 0x1 exceeds max(0x0) 0 blocks read: ERROR >mmc dev 0 0 MMC: block number 0x1 exceeds max(0x0) switch to partitions #0, OK mmc0(part 0) is current device BTW: The GP partiton was created in Linux by the mmc-utils with “mmc gp create -y 1908736 1 1 0 /dev/mmcblk0” Linux can handle this as you can see in boot message: [ 1.248426] mmc0: new high speed MMC card at address 0001 [ 1.264301] mmcblk0: mmc0:0001 Q1J54A 0 B [ 1.268525] mmcblk0boot0: mmc0:0001 Q1J54A partition 1 2.00 MiB [ 1.284605] mmcblk0boot1: mmc0:0001 Q1J54A partition 2 2.00 MiB [ 1.300666] mmcblk0gp0: mmc0:0001 Q1J54A partition 4 1.82 GiB [ 1.316563] mmcblk0rpmb: mmc0:0001 Q1J54A partition 3 512 KiB [ 1.325255] mmcblk0gp0: p1 p2 p3 … [ 3.083325] EXT4-fs (mmcblk0gp0p1): INFO: recovery required on readonly filesystem [ 3.090893] EXT4-fs (mmcblk0gp0p1): write access will be enabled during recovery [ 3.189597] EXT4-fs (mmcblk0gp0p1): recovery complete [ 3.196310] EXT4-fs (mmcblk0gp0p1): mounted filesystem with ordered data mode. Opts: (null)

2 2

[U-Boot] [PATCH 0/5]
by Eric Gao 10 Apr '17

10 Apr '17

This serials patches add mipi dsi support for rk3399. Except the basic mipi driver, we need also enable pmic rk808 for lcd power and enable i2c for rk808 communication. what's more, the needed clk and pwm for backlight is init in spl stage, make sure spl work first. Eric Gao (3): rockchip: video: Add mipi dsi driver rockchip: Add dts config for mipi dsi rockchip: Enable mipi dsi configs eric.gao (2): rockchip: i2c: enable i2c for rk3399 rockchip: pmic: Enable RK808 for rk3399 evb arch/arm/dts/rk3399-evb.dts | 123 ++++++ arch/arm/dts/rk3399.dtsi | 88 +++++ arch/arm/include/asm/arch-rockchip/cru_rk3399.h | 1 + arch/arm/include/asm/arch-rockchip/grf_rk3399.h | 25 ++ arch/arm/include/asm/arch-rockchip/mipi_rk3399.h | 189 +++++++++ arch/arm/include/asm/arch-rockchip/vop_rk3288.h | 1 + configs/evb-rk3399_defconfig | 12 + drivers/i2c/rk_i2c.c | 1 + drivers/video/Kconfig | 2 + drivers/video/rockchip/Kconfig | 47 +++ drivers/video/rockchip/Makefile | 6 +- drivers/video/rockchip/rk_mipi.c | 465 +++++++++++++++++++++++ drivers/video/rockchip/rk_vop.c | 39 +- 13 files changed, 992 insertions(+), 7 deletions(-) create mode 100644 arch/arm/include/asm/arch-rockchip/mipi_rk3399.h create mode 100644 drivers/video/rockchip/Kconfig create mode 100644 drivers/video/rockchip/rk_mipi.c -- 1.9.1

3 3

[U-Boot] [PATCH v3 0/2] x86: SCU and PMU drivers for Intel MID
by Andy Shevchenko 10 Apr '17

10 Apr '17

There are two crucial drivers to make Intel MID platforms functional in U-Boot: SCU which stands for System Controller Unit PMU which stands for Power Management Unit Since v2: - resend with cover letter including changes from previous versions Since v1: Common: - convert to use REGMAP instead of constant addressed IO - rewrite as UCLASS_SYSCON modules - move to arch/x86/lib since it's related to x86 only and there are already another UCLASS_SYSCON modules there SCU: - convert function documentation to have header and body and be consistent - shrink header and remove unneeded attributes - drop busy loop counter from 3m to 100k as per driver in Linux kernel PMU: - convert to be more generic and move Tangier related part to its own folder (the latter out of scope of this series) Andy Shevchenko (1): x86: Introduce minimal PMU driver for Intel MID platforms Felipe Balbi (1): x86: Add SCU IPC driver for Intel MID platforms arch/x86/Kconfig | 2 + arch/x86/include/asm/cpu.h | 2 + arch/x86/include/asm/pmu.h | 11 +++ arch/x86/include/asm/scu.h | 28 ++++++++ arch/x86/lib/Makefile | 2 + arch/x86/lib/pmu.c | 117 +++++++++++++++++++++++++++++++ arch/x86/lib/scu.c | 168 +++++++++++++++++++++++++++++++++++++++++++++ 7 files changed, 330 insertions(+) create mode 100644 arch/x86/include/asm/pmu.h create mode 100644 arch/x86/include/asm/scu.h create mode 100644 arch/x86/lib/pmu.c create mode 100644 arch/x86/lib/scu.c -- 2.11.0

3 6

[U-Boot] [PATCH v3] serial: Add serial driver for Intel MID
by Andy Shevchenko 10 Apr '17

10 Apr '17

Add a specific serial driver for Intel MID platforms. It has special fractional divider which can be programmed via UART_PS, UART_MUL, and UART_DIV registers. The UART clock is calculated as UART clock = XTAL * UART_MUL / UART_DIV The baudrate is calculated as baud rate = UART clock / UART_PS / DLAB Initialize fractional divider correctly for Intel Edison platform. For backward compatibility we have to set initial DLAB value to 16 and speed to 115200 baud, where initial frequency is 29491200Hz, and XTAL frequency is 38.4MHz. Signed-off-by: Andy Shevchenko <andriy.shevchenko(a)linux.intel.com> --- drivers/serial/Kconfig | 9 +++++ drivers/serial/Makefile | 1 + drivers/serial/serial_intel_mid.c | 69 +++++++++++++++++++++++++++++++++++++++ 3 files changed, 79 insertions(+) create mode 100644 drivers/serial/serial_intel_mid.c diff --git a/drivers/serial/Kconfig b/drivers/serial/Kconfig index b11f3ff89e..99dcdeb00d 100644 --- a/drivers/serial/Kconfig +++ b/drivers/serial/Kconfig @@ -347,6 +347,15 @@ config SYS_NS16550 be used. It can be a constant or a function to get clock, eg, get_serial_clock(). +config INTEL_MID_SERIAL + bool "Intel MID platform UART support" + depends on DM_SERIAL && OF_CONTROL + depends on INTEL_MID + select SYS_NS16550 + help + Select this to enable a UART for Intel MID platforms. + This uses the ns16550 driver as a library. + config ROCKCHIP_SERIAL bool "Rockchip on-chip UART support" depends on DM_SERIAL && SPL_OF_PLATDATA diff --git a/drivers/serial/Makefile b/drivers/serial/Makefile index 8430668bf9..abd9dea4dc 100644 --- a/drivers/serial/Makefile +++ b/drivers/serial/Makefile @@ -28,6 +28,7 @@ obj-$(CONFIG_S5P) += serial_s5p.o obj-$(CONFIG_MXC_UART) += serial_mxc.o obj-$(CONFIG_PXA_SERIAL) += serial_pxa.o obj-$(CONFIG_MESON_SERIAL) += serial_meson.o +obj-$(CONFIG_INTEL_MID_SERIAL) += serial_intel_mid.o ifdef CONFIG_SPL_BUILD obj-$(CONFIG_ROCKCHIP_SERIAL) += serial_rockchip.o endif diff --git a/drivers/serial/serial_intel_mid.c b/drivers/serial/serial_intel_mid.c new file mode 100644 index 0000000000..777c09d6d2 --- /dev/null +++ b/drivers/serial/serial_intel_mid.c @@ -0,0 +1,69 @@ +/* + * Copyright (c) 2017 Intel Corporation + * + * SPDX-License-Identifier: GPL-2.0+ + */ + +#include <common.h> +#include <dm.h> +#include <ns16550.h> +#include <serial.h> + +/* + * The UART clock is calculated as + * + * UART clock = XTAL * UART_MUL / UART_DIV + * + * The baudrate is calculated as + * + * baud rate = UART clock / UART_PS / DLAB + */ +#define UART_PS 0x30 +#define UART_MUL 0x34 +#define UART_DIV 0x38 + +static void mid_writel(struct ns16550_platdata *plat, int offset, int value) +{ + unsigned char *addr; + + offset *= 1 << plat->reg_shift; + addr = (unsigned char *)plat->base + offset; + + writel(value, addr + plat->reg_offset); +} + +static int mid_serial_probe(struct udevice *dev) +{ + struct ns16550_platdata *plat = dev_get_platdata(dev); + + /* + * Initialize fractional divider correctly for Intel Edison + * platform. + * + * For backward compatibility we have to set initial DLAB value + * to 16 and speed to 115200 baud, where initial frequency is + * 29491200Hz, and XTAL frequency is 38.4MHz. + */ + mid_writel(plat, UART_MUL, 96); + mid_writel(plat, UART_DIV, 125); + mid_writel(plat, UART_PS, 16); + + return ns16550_serial_probe(dev); +} + +static const struct udevice_id mid_serial_ids[] = { + { .compatible = "intel,mid-uart" }, + {} +}; + +U_BOOT_DRIVER(serial_intel_mid) = { + .name = "serial_intel_mid", + .id = UCLASS_SERIAL, + .of_match = mid_serial_ids, + .ofdata_to_platdata = ns16550_serial_ofdata_to_platdata, + .platdata_auto_alloc_size = sizeof(struct ns16550_platdata), + .priv_auto_alloc_size = sizeof(struct NS16550), + .probe = mid_serial_probe, + .ops = &ns16550_serial_ops, + .flags = DM_FLAG_PRE_RELOC, +}; -- 2.11.0

5 6

[U-Boot] [PATCH] tools: binman: Add missing filenames for various x86 rom tests
by Bin Meng 10 Apr '17

10 Apr '17

With recent changes, some x86-specific rom tests of binman fail to run. Fix it by adding missing filenames in corresponding entries. Signed-off-by: Bin Meng <bmeng.cn(a)gmail.com> --- tools/binman/test/30_x86-rom-me-no-desc.dts | 1 + tools/binman/test/31_x86-rom-me.dts | 2 ++ tools/binman/test/32_intel-vga.dts | 1 + tools/binman/test/42_intel-fsp.dts | 1 + tools/binman/test/43_intel-cmc.dts | 1 + 5 files changed, 6 insertions(+) diff --git a/tools/binman/test/30_x86-rom-me-no-desc.dts b/tools/binman/test/30_x86-rom-me-no-desc.dts index 4578f66..68d3ce0 100644 --- a/tools/binman/test/30_x86-rom-me-no-desc.dts +++ b/tools/binman/test/30_x86-rom-me-no-desc.dts @@ -9,6 +9,7 @@ end-at-4gb; size = <16>; intel-me { + filename = "me.bin"; pos-unset; }; }; diff --git a/tools/binman/test/31_x86-rom-me.dts b/tools/binman/test/31_x86-rom-me.dts index b484ab3..ee3dac8 100644 --- a/tools/binman/test/31_x86-rom-me.dts +++ b/tools/binman/test/31_x86-rom-me.dts @@ -9,9 +9,11 @@ end-at-4gb; size = <0x800000>; intel-descriptor { + filename = "descriptor.bin"; }; intel-me { + filename = "me.bin"; pos-unset; }; }; diff --git a/tools/binman/test/32_intel-vga.dts b/tools/binman/test/32_intel-vga.dts index 1790833..9c532d0 100644 --- a/tools/binman/test/32_intel-vga.dts +++ b/tools/binman/test/32_intel-vga.dts @@ -8,6 +8,7 @@ size = <16>; intel-vga { + filename = "vga.bin"; }; }; }; diff --git a/tools/binman/test/42_intel-fsp.dts b/tools/binman/test/42_intel-fsp.dts index e0a1e76..8a7c889 100644 --- a/tools/binman/test/42_intel-fsp.dts +++ b/tools/binman/test/42_intel-fsp.dts @@ -8,6 +8,7 @@ size = <16>; intel-fsp { + filename = "fsp.bin"; }; }; }; diff --git a/tools/binman/test/43_intel-cmc.dts b/tools/binman/test/43_intel-cmc.dts index 26c456d..5a56c7d 100644 --- a/tools/binman/test/43_intel-cmc.dts +++ b/tools/binman/test/43_intel-cmc.dts @@ -8,6 +8,7 @@ size = <16>; intel-cmc { + filename = "cmc.bin"; }; }; }; -- 2.9.2

2 2