June 2019 - U-Boot

[U-Boot] OMAP3+ EHCI DM_USB Conversion
by Adam Ford 26 Jun '19

26 Jun '19

Looking at the OMAP3 family, there is a single host controller called usbhshost. It has the option of having up to 3 ports. Under usbhshost, there are sub-nodes which have ohci and ehci. I am trying to port the EHCI controller to DM_USB to pull in the device tree info. I am fairly certain the ehci controller itself needs to be .id = UCLASS_USB, but I am not sure what class of device should be the upper level node, usbhshost, which contains the ohci and ehci sub-nodes. I need to pull the port info from usbhshost to properly configure the ports. I am not sure if my question makes sense, but the linux driver doesn't seem to use the same class info as U-Boot, but I'm trying to model the drivers after something similar in linux. Can I use UCLASS_USB as well? As of right now, by making the ehci node at the root level instead of under usbhshost, and can get the USB to initialize with hard-coded pdata values, but I am not seeing attached devices. I'm still looking into that part, but I want to remove the hard-coded values and replace them with device tree reads as well. If anyone has started this or has thought I'd love to hear them. adam

1 0

[U-Boot] [PATCH] mmc: Do not poll using CMD13 when changing timing
by Marek Vasut 26 Jun '19

26 Jun '19

When using CMD6 to switch eMMC card timing from HS200/HS400 to HS/legacy, do not poll for the completion status using CMD13, but rather wait 50mS. Once the card receives the CMD6 and starts executing it, the bus is in undefined state until both the card finishes executing the command and until the controller switches the bus to matching timing configuration. During this time, it is not possible to transport any commands or data across the bus, which includes the CMD13. Signed-off-by: Marek Vasut <marek.vasut+renesas(a)gmail.com> Cc: Jaehoon Chung <jh80.chung(a)samsung.com> --- NOTE: Linux does the same thing. --- drivers/mmc/mmc.c | 28 ++++++++++++++++++++-------- 1 file changed, 20 insertions(+), 8 deletions(-) diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c index c7730c9233..ababacf65a 100644 --- a/drivers/mmc/mmc.c +++ b/drivers/mmc/mmc.c @@ -720,7 +720,8 @@ static int mmc_send_ext_csd(struct mmc *mmc, u8 *ext_csd) return err; } -int mmc_switch(struct mmc *mmc, u8 set, u8 index, u8 value) +static int __mmc_switch(struct mmc *mmc, u8 set, u8 index, u8 value, + bool send_status) { struct mmc_cmd cmd; int timeout = 1000; @@ -736,19 +737,29 @@ int mmc_switch(struct mmc *mmc, u8 set, u8 index, u8 value) while (retries > 0) { ret = mmc_send_cmd(mmc, &cmd, NULL); - /* Waiting for the ready status */ - if (!ret) { - ret = mmc_send_status(mmc, timeout); - return ret; + if (ret) { + retries--; + continue; + } + + if (!send_status) { + mdelay(50); + return 0; } - retries--; + /* Waiting for the ready status */ + return mmc_send_status(mmc, timeout); } return ret; } +int mmc_switch(struct mmc *mmc, u8 set, u8 index, u8 value) +{ + return __mmc_switch(mmc, set, index, value, true); +} + #if !CONFIG_IS_ENABLED(MMC_TINY) static int mmc_set_card_speed(struct mmc *mmc, enum bus_mode mode, bool hsdowngrade) @@ -780,8 +791,9 @@ static int mmc_set_card_speed(struct mmc *mmc, enum bus_mode mode, default: return -EINVAL; } - err = mmc_switch(mmc, EXT_CSD_CMD_SET_NORMAL, EXT_CSD_HS_TIMING, - speed_bits); + + err = __mmc_switch(mmc, EXT_CSD_CMD_SET_NORMAL, EXT_CSD_HS_TIMING, + speed_bits, !hsdowngrade); if (err) return err; -- 2.19.2

3 10

[U-Boot] Watchdog DM conversion, sram overflow(SPL)
by Suniel Mahesh 26 Jun '19

26 Jun '19

Hi, I am trying to convert watchdog driver(omap3_wdt) on TI AM33XX platform to Driver Model. Since DM is also enabled in SPL, size of SPL image generated(with watchdog DM enabled) is bigger compared to the SRAM size(.u_boot_list section doesn't fit in the region alloted) and build is failing with the following error: LD spl/drivers/usb/gadget/built-in.o LD spl/drivers/usb/musb-new/built-in.o LD spl/drivers/built-in.o LD spl/u-boot-spl arm-linux-ld.bfd: u-boot-spl section `.u_boot_list' will not fit in region `.sram' arm-linux-ld.bfd: region `.sram' overflowed by 48 bytes make[1]: *** [spl/u-boot-spl] Error 1 make: *** [spl/u-boot-spl] Error 2 The SRAM size in the device is 130047 bytes, of which 110592 bytes are allocated for SPL Image, 6144 bytes for stack and the rest 12799 bytes for RAM Exec vectors, tracing data and static variables. Maximum SPL image size is fixed at 110592 bytes SPL size without Watchdog driver model is 110880 bytes. So, the reason for such error is straight forward. I can think of two possible approaches (might be wrong): 1. either disable DM in SPL for watchdog ? (dm: mmc: Allow disabling driver model in SPL - by Simon Glass) 2. The stack allocated for SPL in SRAM is 6KB and 12799 bytes for RAM Exec vectors, tracing data and static variables. can we do something here, by borrowing some bytes ? Or any possible solutions ? Regards -- Suniel Mahesh

4 7

[U-Boot] Install U-boot into rock960 v1.3 issue
by khaled hnaien 26 Jun '19

26 Jun '19

Hi, I need your help to get solution for how to install u-boot and display the u-boot terminal prompt in order to excutes uboot commands. Thanks . Best regards, khaled

2 1

[U-Boot] [PATCH 0/5] Virtex2 FPGA enhancements
by Robert Hancock 26 Jun '19

26 Jun '19

These changes add support for slave serial mode, in addition to the existing slave SelectMAP mode, for programming Xilinx Virtex2 (and later) FPGAs, as well as fixing up code style and an issue with the programming sequence. Robert Hancock (5): fpga: virtex2: cosmetic: Cleanup code style fpga: virtex2: added Kconfig option fpga: virtex2: Split out image writing from pre/post operations fpga: virtex2: Add additional clock cycles after DONE assertion fpga: virtex2: Add slave serial programming support drivers/fpga/Kconfig | 8 + drivers/fpga/virtex2.c | 503 +++++++++++++++++++++++++++++-------------------- include/virtex2.h | 13 +- 3 files changed, 313 insertions(+), 211 deletions(-) -- 1.8.3.1

2 15

[U-Boot] Das U-Boot 'bootaux' command breaks USB communication from and to main CPU
by Lucan de Groot 26 Jun '19

26 Jun '19

Dear sir, madam, Our product uses the i.MX 6SoloX SOC with a Cortex A9 and M4, U-Boot runs on the A9 and boots Linux. But before booting Linux it executes the 'bootaux 0x7F800' command to boot the M4. However, Linux is unable to initialize the USB when this command is executed. This problem persist when: - there is no binary loaded on the M4 (and thus it is not code on the M4 that's breaking the USB); - the bootaux command is called with a different address (and thus not it is not booting the M4 that's breaking the USB). The problem is solved when the bootaux command is removed from the boot sequence. However, this way only the A9 boots and we would like to boot the M4 as well. Our U-Boot version is: 2015.04-master+gc75e0f3 We are currently looking into different ways to boot the M4 from Linux instead of U-Boot, however we were hoping you could help us too. Hope te hear from you soon, Lucan de Groot Embedded Software Engineer + 31 (0)6 409 170 21 lucan.degroot(a)quby.com | www.quby.com<http://www.quby.com/> | subscribe to our newsletter<https://mailchi.mp/66cc8a1f175c/subscribe> Quby is hiring! Join our ambitious team to outsmart energy - https://www.quby.com/careers

2 1

[U-Boot] [PATCH 0/6] rockchip: enable TPL for tinker-rk3288
by Kever Yang 26 Jun '19

26 Jun '19

Tinker board has overflow the SRAM size limit, enable TPL for it so that there will be no size limit for SPL. Also some other fix to bring up Tinker board: - enabel sdmmc pinctrl with dts in SPL - extend raw u-boot.bin size limit Kever Yang (6): rockchip: rk3288: enable TPL configs to chip level rockchip: rk3288: add separate TPL STACK address rockchip: dts: rk3288-tinker: enable sdmmc pinctrl node in spl rockchip: config: update config for TPL support on tinker-rk3288 rockchip: config: tiner-rk3288: extend CONFIG_SYS_MONITOR_LEN to 600KB rockchip: rk3288: enable TPL for tinker-board arch/arm/dts/rk3288-tinker.dts | 26 +++++++++++++++++++++++++- arch/arm/mach-rockchip/Kconfig | 18 ++++++++++++++++++ arch/arm/mach-rockchip/rk3288/Kconfig | 15 +-------------- configs/tinker-rk3288_defconfig | 13 +++++-------- include/configs/tinker_rk3288.h | 2 +- 5 files changed, 50 insertions(+), 24 deletions(-) -- 2.20.1

2 10

Re: [U-Boot] U-Boot Digest, Vol 133, Issue 57
by Francois Ozog 26 Jun '19

26 Jun '19

> From: Wolfgang Denk <wd(a)denx.de> > To: AKASHI Takahiro <takahiro.akashi(a)linaro.org> > Cc: Heinrich Schuchardt <xypron.glpk(a)gmx.de>, Alexander Graf <agraf(a)csgraf.de>, sughosh.ganu(a)arm.com, U-Boot Mailing List <u-boot(a)lists.denx.de> > Bcc: > Date: Tue, 25 Jun 2019 08:33:30 +0200 > Subject: Re: [U-Boot] efi_loader: implementing non-volatile UEFI variables > Dear Takahiro, > > In message <20190625011039.GO6610(a)linaro.org> you wrote: > > > > > Think about secure boot. It is a bad idea to expose variables in this way. > > > > Actually, we are thinking of disabling U-Boot environment (I mean, > > ENV_IS_NOWHERE) still allowing for UEFI variables for security reason. > > OK. I know of systems that have passed security audits with > U-Boot environment enabled. In those cases it as sufficient to make > a certain set of variables immutable. > > Also, adding the new "volatile" attribute to the environment flags > as I suggested would allow to fine-tune which variables get stored > in the persistent nvironment copy at all. > > > One of the differences between U-Boot env and UEFI variables > > is that the former can and should be saved to backing storage > > only with explicit "saveenv" command, while the latter are > > expected to be saved immediately. > > OK - but this does not conflict in any way with the U-Boot > environment concept. In the same way we can add a "volatile" > property to the flags, we can add something like an "autosave" > property which would cause that aany modification of the variable > value would automatically run "env save". > > Once you think about more generic features of the property flags you > can implement all kinds of clever/useful/fancy things. For example, > one could think of a "protected" property, which would require > password entry to change the value, etc. > > Of course you could also flag variables with an "UEFI" attribute and > add all kinds of wanted behaviour. > > > Preserving respective semantics simultaneously would be possible, but > > it would make the implementation a bit complicated and ugly. > > It does not have to be ugly, and I think it is also not so > complicatred. In any case it seems more attractive to me than > adding a completly separate, new implementation for variable > storage. > > > Instead, I believe that it will be a clever idea that we should have > > separate contexts for them as I showed in my non-volatile support patch[1]. > > > > [1] https://lists.denx.de/pipermail/u-boot/2019-June/371601.html > > To be honest: I thinkt his is not really a clever approach. it > would be _much_ easier to add a "volatile" property to the U-Boot > variable flags. Your patch modifies 12 files, and adds more than > 600 lines of code. And since you're modifying env/fat.c I have > the impression that this is not even universally usable - does it > really work only when storing the environment in a FAT file system? > Not with ext4? Or any other storage? And it works only for UEFI, but > "normal" environment variables do not benefit from this? > > Note that my suggested extension of the variable flags would be > completely agnostic of this... > On one side we have UEFI have objects that can be persistent and/or secure. More importantly, a UEFI application can register a storage backend to perform UEFI variable persistence on specific hardware. This facility is used to manage persistent/secure variables in TrustZone. Verification of secure variables can also depend on application registered UEFI protocols: we would import the new security protocol, or the hardware accelerated protocol verification in the U-Boot UEFI environment rather than re-implement the U-Boot way. On the other side, U-Boot has a super lightweight variable system that is used to control boot sequence and hence variable performance has an impact on boot delay and jitter. Because the UEFI variables has additional dependencies on those other UEFI constructs (protocol registration for storage back end, crypto and signature stuff for secure variables) and its easier to allow code import from other UEFI implementations, I would tend to segregate u-boot variables from UEFI objects (I think the term object is more appropriate). In other words UEFI objects shall be say self-contained in the UEFI "subsystem". Combined with the performance goal, and code size (if we do not want the UEFI stuff), I have a second reason to keep them separate. That said, enhancing the u-boot variable concept with persistent attribute is most certainly a good idea, independently from UEFI variables. And it may be a good idea to leverage that facility to implement "simple" persistence from the UEFI world. > > > One of possible improvements here is to refactor the env code and > > parameterize "contexts" at env_save()/env_load(). > > Contexts, or flags. But this does not require much refactoring. It > should be a straighforward extension. > > > > >And I agree on that. But even if it was not the case, having four > > > >different implementations for the same thing is .... sub-optiman. > > > > > > We have a lot of things that can be disabled in U-Boot. Why should we > > > not be able to disable UEFI variables? > > > > To be honest, I'm a bit doubtful about practical meaning of > > disabling UEFI variables for UEFI execution environment. > > This was Heinrich's argument, and I admit that I didn't understandit > either. > > > > UEFI variables should be accessible via the UEFI runtime API and not via > > > some U-Boot specific hack which no other program but U-Boot cares about. > > > > Please notice that one of the reasons that prevents UEFI variables > > from being accessed by OS is a real hardware(device/controller) may be > > shared between firmware(i.e. UEFI runtime) and OS and mutually exclusive > > access must be ensured. > > Again, this was Heinrich's argument. > > Best regards, > > Wolfgang Denk > > -- > DENX Software Engineering GmbH, Managing Director: Wolfgang Denk > HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany > Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd(a)denx.de > There are no data that cannot be plotted on a straight line if the > axis are chosen correctly. > > > _______________________________________________ > U-Boot mailing list > U-Boot(a)lists.denx.de > https://lists.denx.de/listinfo/u-boot -- François-Frédéric Ozog | Director Linaro Edge & Fog Computing Group T: +33.67221.6485 francois.ozog(a)linaro.org | Skype: ffozog

2 1

[U-Boot] [PATCH v2 6/8] x86: slimbootloader: Add a slimbootloader device tree
by Park, Aiden 26 Jun '19

26 Jun '19

- Add minimum nodes such as reset, tsc_timer, serial and pci Signed-off-by: Aiden Park <aiden.park(a)intel.com> --- arch/x86/dts/Makefile | 3 ++- arch/x86/dts/slimbootloader.dts | 27 +++++++++++++++++++++++++++ 2 files changed, 29 insertions(+), 1 deletion(-) create mode 100644 arch/x86/dts/slimbootloader.dts diff --git a/arch/x86/dts/Makefile b/arch/x86/dts/Makefile index fa717bc096..7c382f416b 100644 --- a/arch/x86/dts/Makefile +++ b/arch/x86/dts/Makefile @@ -18,7 +18,8 @@ dtb-y += bayleybay.dtb \ qemu-x86_i440fx.dtb \ qemu-x86_q35.dtb \ theadorable-x86-dfi-bt700.dtb \ - baytrail_som-db5800-som-6867.dtb + baytrail_som-db5800-som-6867.dtb \ + slimbootloader.dtb targets += $(dtb-y) diff --git a/arch/x86/dts/slimbootloader.dts b/arch/x86/dts/slimbootloader.dts new file mode 100644 index 0000000000..d04095c4f8 --- /dev/null +++ b/arch/x86/dts/slimbootloader.dts @@ -0,0 +1,27 @@ +// SPDX-License-Identifier: GPL-2.0+ +/* + * Copyright (C) 2019 Intel Corporation <www.intel.com> + */ + +/dts-v1/; + +/include/ "skeleton.dtsi" +/include/ "reset.dtsi" +/include/ "tsc_timer.dtsi" + +/ { + model = "slimbootloader x86 payload"; + compatible = "slimbootloader,x86-payload"; + + chosen { + stdout-path = &serial; + }; + + serial: serial { + compatible = "intel,slimbootloader-uart"; + }; + + pci { + compatible = "pci-x86"; + }; +}; -- 2.20.1

1 0

[U-Boot] [PATCH v2 5/8] x86: slimbootloader: Set TSC information for timer driver
by Park, Aiden 26 Jun '19

26 Jun '19

- Get TSC frequency from performance info hob - Set tsc_base and clock_rate for timer driver Signed-off-by: Aiden Park <aiden.park(a)intel.com> --- arch/x86/cpu/slimbootloader/slimbootloader.c | 31 +++++++++++++++++++ .../asm/arch-slimbootloader/slimbootloader.h | 26 ++++++++++++++++ 2 files changed, 57 insertions(+) diff --git a/arch/x86/cpu/slimbootloader/slimbootloader.c b/arch/x86/cpu/slimbootloader/slimbootloader.c index 9f3a61ec61..e2bab99461 100644 --- a/arch/x86/cpu/slimbootloader/slimbootloader.c +++ b/arch/x86/cpu/slimbootloader/slimbootloader.c @@ -4,9 +4,40 @@ */ #include <common.h> +#include <asm/arch/slimbootloader.h> + +DECLARE_GLOBAL_DATA_PTR; + +/** + * This sets tsc_base and clock_rate for early_timer and tsc_timer. + * The performance info guid hob has all performance timestamp data, but + * the only tsc frequency info is used for the timer driver for now. + */ +static void tsc_init(void) +{ + struct performance_info *data = NULL; + const struct efi_guid guid = LOADER_PERFORMANCE_INFO_GUID; + + gd->arch.tsc_base = rdtsc(); + debug("tsc_base=0x%llx\n", gd->arch.tsc_base); + + data = (struct performance_info *) + get_next_guid_hob_data(&guid, gd->arch.hob_list); + + if (!data) { + debug("performance info hob not found\n"); + return; + } + + /* frequency is in KHz, so to Hz */ + gd->arch.clock_rate = data->frequency * 1000; + debug("freq=0x%lx\n", gd->arch.clock_rate); +} int arch_cpu_init(void) { + tsc_init(); + return x86_cpu_init_f(); } diff --git a/arch/x86/include/asm/arch-slimbootloader/slimbootloader.h b/arch/x86/include/asm/arch-slimbootloader/slimbootloader.h index b05e527148..0b908f7c3e 100644 --- a/arch/x86/include/asm/arch-slimbootloader/slimbootloader.h +++ b/arch/x86/include/asm/arch-slimbootloader/slimbootloader.h @@ -22,6 +22,12 @@ { 0xbb, 0x98, 0x95, 0x8d, 0x62, 0xde, 0x87, 0xf1 } \ } +#define LOADER_PERFORMANCE_INFO_GUID \ + { \ + 0x868204be, 0x23d0, 0x4ff9, \ + { 0xac, 0x34, 0xb9, 0x95, 0xac, 0x04, 0xb1, 0xb9 } \ + } + /** * A single entry of memory map information * @@ -81,6 +87,26 @@ struct serial_port_info { u32 rsvd1; } __packed; +/** + * This includes timestamp data which has been collected + * in Slim Bootloader stages. + * + * @rev : revision of performance_info structure. currently 1. + * @rsvd : padding for alignment + * @count : the number of collected timestamp data + * @flags : only used in Slim Bootloader + * @frequency: tsc frequency in KHz + * @timestamp: the array of timestamp data which has 64-bit tsc value + */ +struct performance_info { + u8 rev; + u8 rsvd[3]; + u16 count; + u16 flags; + u32 frequency; + u64 timestamp[0]; +} __packed; + /** * This returns a pointer to hob data buffer if the given guid hob is found. * -- 2.20.1

1 0