July 2016 - U-Boot

[U-Boot] [PATCH 2/3] x86: Add a reference to README.efi
by Simon Glass 19 Jul '16

19 Jul '16

UEFI is commonly used on x86. Add a reference to U-Boot's support for this in the x86 README. Signed-off-by: Simon Glass <sjg(a)chromium.org> --- doc/README.x86 | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/doc/README.x86 b/doc/README.x86 index 7d694b1..04e7a54 100644 --- a/doc/README.x86 +++ b/doc/README.x86 @@ -1035,10 +1035,21 @@ command from the OS. For other platform boards, ACPI support status can be checked by examining their board defconfig files to see if CONFIG_GENERATE_ACPI_TABLE is set to y. +EFI Support +----------- +U-Boot supports booting as a 32-bit or 64-bit EFI payload, e.g. with UEFI. +This is enabled with CONFIG_EFI_STUB. U-Boot can also run as an EFI +application, with CONFIG_EFI_APP. The CONFIG_EFI_LOADER option, where U-Booot +provides an EFI environment to the kernel (i.e. replaces UEFI completely but +provides the same EFI run-time services) is not currently supports on x86. + +See README.efi for details of EFI support in U-Boot. + TODO List --------- - Audio - Chrome OS verified boot +- Support for CONFIG_EFI_LOADER References ---------- -- 2.8.0.rc3.226.g39d4020

2 6

[U-Boot] [PATCH 1/3] x86: Mention how to boot a 64-bit kernel from U-Boot
by Simon Glass 19 Jul '16

19 Jul '16

The README indicates that this is not supported, but this is no-longer true. Update the text to indicate this and describe the FIT changes required. Signed-off-by: Simon Glass <sjg(a)chromium.org> --- doc/uImage.FIT/kernel.its | 4 ++++ doc/uImage.FIT/x86-fit-boot.txt | 14 +++++--------- 2 files changed, 9 insertions(+), 9 deletions(-) diff --git a/doc/uImage.FIT/kernel.its b/doc/uImage.FIT/kernel.its index e668c3f..0aaf47e 100644 --- a/doc/uImage.FIT/kernel.its +++ b/doc/uImage.FIT/kernel.its @@ -85,3 +85,7 @@ For x86 a setup node is also required: see x86-fit-boot.txt. }; }; }; + +Note: the above assumes a 32-bit kernel. To directly boot a 64-bit kernel, +change both arch values to "x86_64". U-Boot will then change to 64-bit mode +before booting the kernel (see boot_linux_kernel()). diff --git a/doc/uImage.FIT/x86-fit-boot.txt b/doc/uImage.FIT/x86-fit-boot.txt index 61c10ff..02238f9 100644 --- a/doc/uImage.FIT/x86-fit-boot.txt +++ b/doc/uImage.FIT/x86-fit-boot.txt @@ -63,9 +63,8 @@ executed. Build the kernel ---------------- -Note: these instructions assume a 32-bit kernel. U-Boot does not currently -support booting a 64-bit kernel as it has no way of going into 64-bit mode on -x86. +Note: these instructions assume a 32-bit kernel. U-Boot also supports directly +booting a 64-bit kernel by jumping into 64-bit mode first (see below). You can build the kernel as normal with 'make'. This will create a file called 'vmlinux'. This is a standard ELF file and you can look at it if you like: @@ -168,8 +167,9 @@ Create a FIT ------------ To create a FIT you will need a source file describing what should go in the -FIT. See kernel.its for an example for x86. Put this into a file called -image.its. +FIT. See kernel.its for an example for x86 and also instructions on setting +the 'arch' value for booting 64-bit kernels if desired. Put this into a file +called image.its. Note that setup is loaded to the special address of 0x90000 (a special address you just have to know) and the kernel is loaded to 0x01000000 (the address you @@ -263,10 +263,6 @@ In the Linux kernel, Documentation/x86/boot.txt defines the boot protocol for the kernel including the setup.bin format. This is handled in U-Boot in arch/x86/lib/zimage.c and arch/x86/lib/bootm.c. -The procedure for entering 64-bit mode on x86 seems to be described here: - - http://wiki.osdev.org/64-bit_Higher_Half_Kernel_with_GRUB_2 - Various files in the same directory as this file describe the FIT format. -- 2.8.0.rc3.226.g39d4020

2 2

[U-Boot] [PATCH] x86: doc: Add note about the debug FSP usage on BayTrail
by Stefan Roese 19 Jul '16

19 Jul '16

The debug FSP image is bigger in size than the normal FSP image. This patch adds a small description on how to use this FSP debug version by changing CONFIG_FSP_ADDR. Signed-off-by: Stefan Roese <sr(a)denx.de> Cc: Bin Meng <bmeng.cn(a)gmail.com> Cc: Simon Glass <sjg(a)chromium.org> --- doc/README.x86 | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/doc/README.x86 b/doc/README.x86 index 7d694b1..f28605f 100644 --- a/doc/README.x86 +++ b/doc/README.x86 @@ -314,6 +314,10 @@ Offset Description Controlling config Overall ROM image size is controlled by CONFIG_ROM_SIZE. +Note that the debug version of the FSP is bigger in size. If this version +is used, CONFIG_FSP_ADDR needs to be configured to 0xfffb0000 instead of +the default value 0xfffc0000. + --- Intel Galileo instructions for bare mode: -- 2.9.1

2 2

[U-Boot] erasing u-boot from u-boot
by Mike.Worster＠Emerson.com 19 Jul '16

19 Jul '16

I'm working with a 2015.04 version of U-Boot, I have it flashed on a i.MX6 DualLite based device in eMMC. I'm now trying to blow away that version of U-Boot from within U-Boot itself (so the device goes back into Serial Download mode). I've tried erasing the mmc0 (eMMC), the command works, but for some reason every time I power cycle the device U-Boot is still present. How do I delete it? => mmc info Device: FSL_SDHC Manufacturer ID: 1e OEM: 1ff Name: TSEMM Tran Speed: 52000000 Rd Block Len: 512 MMC version 4.5 High Capacity: Yes Capacity: 3.5 GiB Bus Width: 8-bit Erase Group Size: 512 KiB HC WP Group Size: 8 MiB User Capacity: 3.5 GiB ENH WRREL User Enhanced Start: 0 Bytes User Enhanced Size: 3.5 GiB Boot Capacity: 4 MiB ENH RPMB Capacity: 4 MiB ENH => => mmc dev switch to partitions #0, OK mmc0(part 0) is current device => => mmc erase 2 8 MMC erase: dev # 0, block # 2, count 8 ... Caution! Your devices Erase group is 0x400 The erase range would be change to 0x0~0x3ff 8 blocks erased: OK Thanks. -Mike

3 3

[U-Boot] [PATCH 1/1] configs/wandboard.h: fix dtb file name for findfdt.
by Adam Duskett 18 Jul '16

18 Jul '16

With the release of kernel 4.1.15 for the imx6 line of processors, wandboard now uses imx6q-wandboard-revc1.dtb and imx6dl-wandboard-revc1.dtb. This patch fixes the naming convention to work with kernel 4.1.15 Signed-off-by: Adam Duskett <adamduskett(a)outlook.com> --- include/configs/wandboard.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/include/configs/wandboard.h b/include/configs/wandboard.h index 99f5c0c..d41b600 100644 --- a/include/configs/wandboard.h +++ b/include/configs/wandboard.h @@ -135,9 +135,9 @@ "setenv bootargs ${bootargs} ${fbmem}\0" \ "findfdt="\ "if test $board_name = C1 && test $board_rev = MX6Q ; then " \ - "setenv fdtfile imx6q-wandboard.dtb; fi; " \ + "setenv fdtfile imx6q-wandboard-revc1.dtb; fi; " \ "if test $board_name = C1 && test $board_rev = MX6DL ; then " \ - "setenv fdtfile imx6dl-wandboard.dtb; fi; " \ + "setenv fdtfile imx6dl-wandboard-revc1.dtb; fi; " \ "if test $board_name = B1 && test $board_rev = MX6Q ; then " \ "setenv fdtfile imx6q-wandboard-revb1.dtb; fi; " \ "if test $board_name = B1 && test $board_rev = MX6DL ; then " \ -- 2.7.4

5 4

[U-Boot] is minicom still discouraged as the serial comms program?
by Robert P. J. Day 18 Jul '16

18 Jul '16

i know that minicom has been discouraged for quite some time WRT u-boot, is that still the case? and what was the flaw with minicom, anyway? and is there any problem with picocom, which seems to work for me just fine. rday -- ======================================================================== Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ========================================================================

4 5

[U-Boot] more "#if 0" pedantry related to moving macros in header files
by Robert P. J. Day 18 Jul '16

18 Jul '16

my apologies for yet more pedantic nitpickery, this time related to how to properly move/locate macro definitions in header files. i notice this bit in include/mpc8xx.h (note the two tests of "#if 0"): /*----------------------------------------------------------------------- * TBSCR - Time Base Status and Control Register 11-26 */ #define TBSCR_TBIRQ7 0x8000 /* Time Base Interrupt Request 7 */ #define TBSCR_TBIRQ6 0x4000 /* Time Base Interrupt Request 6 */ #define TBSCR_TBIRQ5 0x2000 /* Time Base Interrupt Request 5 */ #define TBSCR_TBIRQ4 0x1000 /* Time Base Interrupt Request 4 */ #define TBSCR_TBIRQ3 0x0800 /* Time Base Interrupt Request 3 */ #define TBSCR_TBIRQ2 0x0400 /* Time Base Interrupt Request 2 */ #define TBSCR_TBIRQ1 0x0200 /* Time Base Interrupt Request 1 */ #define TBSCR_TBIRQ0 0x0100 /* Time Base Interrupt Request 0 */ #if 0 /* already in asm/8xx_immap.h */ #define TBSCR_REFA 0x0080 /* Reference Interrupt Status A */ #define TBSCR_REFB 0x0040 /* Reference Interrupt Status B */ #define TBSCR_REFAE 0x0008 /* Second Interrupt Enable A */ #define TBSCR_REFBE 0x0004 /* Second Interrupt Enable B */ #define TBSCR_TBF 0x0002 /* Time Base Freeze */ #define TBSCR_TBE 0x0001 /* Time Base Enable */ #endif /*----------------------------------------------------------------------- * PISCR - Periodic Interrupt Status and Control Register 11-31 */ #undef PISCR_PIRQ /* TBD */ #define PISCR_PITF 0x0002 /* Periodic Interrupt Timer Freeze */ #if 0 /* already in asm/8xx_immap.h */ #define PISCR_PS 0x0080 /* Periodic interrupt Status */ #define PISCR_PIE 0x0004 /* Periodic Interrupt Enable */ #define PISCR_PTE 0x0001 /* Periodic Timer Enable */ #endif sure enough, the parts that are "if 0"ed out are indeed in arch/powerpc/include/asm/8xx_immap.h: #define TBSCR_TBIRQ_MASK ((ushort)0xff00) #define TBSCR_REFA ((ushort)0x0080) #define TBSCR_REFB ((ushort)0x0040) #define TBSCR_REFAE ((ushort)0x0008) #define TBSCR_REFBE ((ushort)0x0004) #define TBSCR_TBF ((ushort)0x0002) #define TBSCR_TBE ((ushort)0x0001) ... snip ... #define PISCR_PIRQ_MASK ((ushort)0xff00) #define PISCR_PS ((ushort)0x0080) #define PISCR_PIE ((ushort)0x0004) #define PISCR_PTF ((ushort)0x0002) #define PISCR_PTE ((ushort)0x0001) but this brings up the question, where should content like that properly be defined? it seems awkward to break the bit flag definitions for a single register over two header files (especially when they're not defined syntactically identically). is there a historical reason that that content is split over two header files? oh, and about the above, there is only one reference in the entire tree to PISCR_PIRQ (where it's being undef'ed): include/mpc8xx.h:#undef PISCR_PIRQ /* TBD */ so i'm guessing that's superfluous (perhaps the old form for defining PISCR_PIRQ_MASK?). i'd submit a patch to get rid of it, but i'll hold off if i can do a larger cleanup that covers that as well in one shot. thoughts? rday p.s. hang on ... this bit in arch/powerpc/include/asm/8xx_immap.h: #define TBSCR_TBIRQ_MASK ((ushort)0xff00) #define TBSCR_REFA ((ushort)0x0080) #define TBSCR_REFB ((ushort)0x0040) #define TBSCR_REFAE ((ushort)0x0008) #define TBSCR_REFBE ((ushort)0x0004) #define TBSCR_TBF ((ushort)0x0002) #define TBSCR_TBE ((ushort)0x0001) #define RTCSC_RTCIRQ_MASK ((ushort)0xff00) #define RTCSC_SEC ((ushort)0x0080) #define RTCSC_ALR ((ushort)0x0040) #define RTCSC_38K ((ushort)0x0010) #define RTCSC_SIE ((ushort)0x0008) #define RTCSC_ALE ((ushort)0x0004) #define RTCSC_RTF ((ushort)0x0002) #define RTCSC_RTE ((ushort)0x0001) #define PISCR_PIRQ_MASK ((ushort)0xff00) #define PISCR_PS ((ushort)0x0080) #define PISCR_PIE ((ushort)0x0004) #define PISCR_PTF ((ushort)0x0002) #define PISCR_PTE ((ushort)0x0001) i just noticed that none of the *_MASK macros are referenced anywhere in the entire source tree: $ grep -r TBSCR_TBIRQ_MASK * arch/powerpc/include/asm/8xx_immap.h:#define TBSCR_TBIRQ_MASK ((ushort)0xff00) $ grep -r RTCSC_RTCIRQ_MASK * arch/powerpc/include/asm/8xx_immap.h:#define RTCSC_RTCIRQ_MASK ((ushort)0xff00) $ grep -r PISCR_PIRQ_MASK * arch/powerpc/include/asm/8xx_immap.h:#define PISCR_PIRQ_MASK ((ushort)0xff00) arch/powerpc/include/asm/immap_8260.h:#define PISCR_PIRQ_MASK ((ushort)0xff00) $ so what are they used for? -- ======================================================================== Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ========================================================================

2 1

[U-Boot] what is with the "#if 0"ed part of ARP hdr in include/net.h?
by Robert P. J. Day 18 Jul '16

18 Jul '16

was poking around in include/net.h, and noticed this snippet: /* * Address Resolution Protocol (ARP) header. */ struct arp_hdr { ... snip ... #define ar_sha ar_data[0] #define ar_spa ar_data[ARP_HLEN] #define ar_tha ar_data[ARP_HLEN + ARP_PLEN] #define ar_tpa ar_data[ARP_HLEN + ARP_PLEN + ARP_HLEN] #if 0 u8 ar_sha[]; /* Sender hardware address */ u8 ar_spa[]; /* Sender protocol address */ u8 ar_tha[]; /* Target hardware address */ u8 ar_tpa[]; /* Target protocol address */ #endif /* 0 */ }; i just checked, and that "#if 0" has been there since 2002: 2d966958 (Wolfgang Denk 2002-10-31 22:12:35 +0000 421) #if 0 717234e0 (Sergey Temerkhanov 2015-04-08 01:41:23 -0500 422) u8 ar_sha[]; /* Sender hardware address */ 717234e0 (Sergey Temerkhanov 2015-04-08 01:41:23 -0500 423) u8 ar_spa[]; /* Sender protocol address */ 717234e0 (Sergey Temerkhanov 2015-04-08 01:41:23 -0500 424) u8 ar_tha[]; /* Target hardware address */ 717234e0 (Sergey Temerkhanov 2015-04-08 01:41:23 -0500 425) u8 ar_tpa[]; /* Target protocol address */ 2d966958 (Wolfgang Denk 2002-10-31 22:12:35 +0000 426) #endif /* 0 */ is it doing anything, like acting as a comment or something? rday p.s. there's quite a lot of "#if 0" throughout the source code, some of which i may submit patches to get rid of just in the areas i'm confortable with. -- ======================================================================== Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ========================================================================

2 1

[U-Boot] [PATCH] ARM: tegra: p2371-2180: A03 board PMIC config update
by Stephen Warren 18 Jul '16

18 Jul '16

From: Stephen Warren <swarren(a)nvidia.com> Rev A03 of P2180 requires some PMIC programming adjustments, yet the PMIC's own OTP has not been updated. Consequently, U-Boot must make these changes itself. NVIDIA's syseng team has confirmed that these changes can be enabled on all board revisions without issue. Signed-off-by: Stephen Warren <swarren(a)nvidia.com> --- board/nvidia/p2371-2180/p2371-2180.c | 22 ++++++++++++++++++++++ board/nvidia/p2571/max77620_init.h | 2 ++ 2 files changed, 24 insertions(+) diff --git a/board/nvidia/p2371-2180/p2371-2180.c b/board/nvidia/p2371-2180/p2371-2180.c index 0f587eaaa796..dbdc1b65e680 100644 --- a/board/nvidia/p2371-2180/p2371-2180.c +++ b/board/nvidia/p2371-2180/p2371-2180.c @@ -30,6 +30,28 @@ void pin_mux_mmc(void) ret = dm_i2c_write(dev, MAX77620_CNFG1_L2_REG, &val, 1); if (ret) printf("i2c_write 0 0x3c 0x27 failed: %d\n", ret); + + /* Disable LDO4 discharge */ + ret = dm_i2c_read(dev, MAX77620_CNFG2_L4_REG, &val, 1); + if (ret) { + printf("i2c_read 0 0x3c 0x2c failed: %d\n", ret); + } else { + val &= ~BIT(1); /* ADE */ + ret = dm_i2c_write(dev, MAX77620_CNFG2_L4_REG, &val, 1); + if (ret) + printf("i2c_write 0 0x3c 0x2c failed: %d\n", ret); + } + + /* Set MBLPD */ + ret = dm_i2c_read(dev, MAX77620_CNFGGLBL1_REG, &val, 1); + if (ret) { + printf("i2c_write 0 0x3c 0x00 failed: %d\n", ret); + } else { + val |= BIT(6); /* MBLPD */ + ret = dm_i2c_write(dev, MAX77620_CNFGGLBL1_REG, &val, 1); + if (ret) + printf("i2c_write 0 0x3c 0x00 failed: %d\n", ret); + } } /* diff --git a/board/nvidia/p2571/max77620_init.h b/board/nvidia/p2571/max77620_init.h index 92c3719112a4..39e550149aae 100644 --- a/board/nvidia/p2571/max77620_init.h +++ b/board/nvidia/p2571/max77620_init.h @@ -13,6 +13,8 @@ #define MAX77620_I2C_ADDR 0x78 #define MAX77620_I2C_ADDR_7BIT 0x3C +#define MAX77620_CNFGGLBL1_REG 0x00 + #define MAX77620_SD0_REG 0x16 #define MAX77620_SD1_REG 0x17 #define MAX77620_SD2_REG 0x18 -- 2.9.2

1 0

[U-Boot] [PATCH 1/3] ARM: tegra: fix Tegra186 DT GPIO binding header
by Stephen Warren 18 Jul '16

18 Jul '16

From: Stephen Warren <swarren(a)nvidia.com> Tegra186 uses different GPIO port IDs compared to previous chips. Make sure the SoC DT file includes the correct GPIO binding header. Signed-off-by: Stephen Warren <swarren(a)nvidia.com> --- arch/arm/dts/tegra186.dtsi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/dts/tegra186.dtsi b/arch/arm/dts/tegra186.dtsi index fce34fa6500e..99d49254b36b 100644 --- a/arch/arm/dts/tegra186.dtsi +++ b/arch/arm/dts/tegra186.dtsi @@ -1,5 +1,5 @@ #include "skeleton.dtsi" -#include <dt-bindings/gpio/tegra-gpio.h> +#include <dt-bindings/gpio/tegra186-gpio.h> #include <dt-bindings/interrupt-controller/arm-gic.h> #include <dt-bindings/mailbox/tegra-hsp.h> -- 2.9.2

1 2