August 2015 - U-Boot

[U-Boot] [RFC PATCH 0/3] fix netconsole for CONFIG_DM_ETH
by Bernhard Nortmann 25 Aug '15

25 Aug '15

With the introduction of driver model and accompanying changes, outdated code in netconsole leads to compilation errors when both CONFIG_NETCONSOLE and CONFIG_DM_ETH are set. This is a series of patches to fix these issues and get netconsole working again. I have deliberately marked it "RFC" since I'm not entirely sure of what I'm doing here... Especially the bootm.c change (patch 3/3) probably needs review or improvement by someone more knowledgable on U-Boot networking / driver model. Nevertheless I have tested the resulting code on my Banana Pi (sun7i / Allwinner A20) and had a functional netconsole again. I've also backported eth_is_active() and netconsole.c to v2015.04 to make sure they properly worked in case CONFIG_DM_ETH is absent. Regards, B. Nortmann Bernhard Nortmann (3): expose eth_is_active() function to test network device state fix netconsole when CONFIG_DM_ETH is set avoid eth_unregister() call when function is unavailable common/bootm.c | 2 ++ drivers/net/netconsole.c | 14 +++++++++++--- include/net.h | 6 ++++++ net/eth.c | 18 +++++++++++++++++- 4 files changed, 36 insertions(+), 4 deletions(-) -- 2.4.6

3 12

[U-Boot] x86: EFI: boot fails at exit_boot_services - Was: Stuck trying to build a non-qemu EFI payload
by Stoppa, Igor 25 Aug '15

25 Aug '15

Hi Bin, Simon, On 18 August 2015 at 15:47, Stoppa, Igor <igor.stoppa(a)intel.com> wrote: > Hi, > I have verified that I can reproduce a working build of U-Boot as > x86-64bit EFI payload for Qemu: I can boot it, interact with various > filesystems of both real and emulated disks, etc. > > > Now I would like to build and boot it for a real board, still as EFI payload. > > The docs/README.efi file states: > >> U-Boot is packaged up and loaded in its entirety by EFI. Once >> started, U-Boot changes to 32-bit mode (currently) and takes over the >> machine. You can use devices, boot a kernel, etc. > > My test device is a a D4250WYK NUC with a 4th generation Core i5 > Haswell processor. > I tried booting it with an USB stick that I prepared and tested with qemu. > The build is based on the qemu-x86_defconfig, plus the EFI settings > needed for generating a 64 bit payload. > > On qemu I can reach the U-Boot shell and run commands, however on the > NUC it stops at > the message "U-Boot EFI Payload", which is printed by the stub. I've added traces to my setup and somewhat narrowed down the place where it gets stuck. It happens much earlier than I thought: I was expecting it would get stuck during the handover from the stub to the real U-Boot, after the jump_to_uboot call, instead it never reaches that point. On the NUC I get a system hang at the first ret = boot->exit_boot_services(image, key); in efi_main. I traced it with some putc(). My assumption was that, even if the payload is configured for QEmu, rather than for the real board I am using, the loading should be successful anyway, because it relies on the EFI API. Is my assumption in correct? I noticed something (unrelated?) regarding exit_boot_services: There's a comment in the efi_stub.c file, stating: /* * Unfortunately it happens that we cannot exit boot services * the first time. But the second time it work. I don't know * why but this seems to be a repeatable problem. To get * around it, just try again. */ But, with Qemu, "exit_boot_services" always work at the first attempt: the execution never enters the braces containing that comment. -- thanks, igor

2 4

[U-Boot] [PATCH v5 0/8] omap-common: Common boot code OMAP3 support and SYS_BOOT-based fallback boot device
by Paul Kocialkowski 25 Aug '15

25 Aug '15

Changes since v4: * Take care of BOOT_DEVICE_USBETH and don't use the fallback when it's defined and active. This way, we can have both BOOT_DEVICE_USBETH and BOOT_DEVICE_USB defined to the same value and use USB eth or not based on CONFIG_SPL_USBETH_SUPPORT. * boot_params casting clarification. Changes since v3: * Tested on the OMAP5 uEVM, adjusted SYS_BOOT interpretation. * Typo fixup, other minor cleanups. Changes since v2: * ifdef save_boot_params definition and save_omap_boot_params calls with CONFIG_SPL to only use all this when U-Boot is loaded from the U-Boot SPL. This was always the case on != omap3 omap platforms, but is no longer the case with omap3 support (since some devices like the RX-51 are OMAP HS and have proprietary bootloaders loading U-Boot, and might even need some specific code instead). The first part of this changeset introduces OMAP3 support for the common omap boot code, as well as a major cleanup of the common omap boot code. First, the omap_boot_parameters structure becomes platform-specific, since its definition differs a bit across omap platforms. The offsets are removed as well since it is U-Boot's coding style to use structures for mapping such kind of data (in the sense that it is similar to registers). It is correct to assume that romcode structure encoding is the same as U-Boot, given the description of these structures in the TRMs. The original address provided by the bootrom is passed to the U-Boot binary instead of a duplicate of the structure stored in global data. This allows to have only the relevant (boot device and mode) information stored in global data. It is also expected that the address where the bootrom stores that information is not overridden by the U-Boot SPL or U-Boot. The save_omap_boot_params is expected to handle all special cases where the data provided by the bootrom cannot be used as-is, so that spl_boot_device and spl_boot_mode only return the data from global data. The second part of this changeset adds support for reading the SYS_BOOT pins on omap devices (no am33xx support yet) in order to fallback to the memory-preferred boot device described by the pins when peripheral booting is used. In particular, this allows loading the U-Boot SPL through either UART or USB and still having it to load U-Boot from memory when UART or USB are not valid boot devices. This whole changeset was build-tested on all omap boards (omap3, omap4, omap5, am33xx) and tested at run-time on the Nokia RX-51 (N900), the LG Optimus Black (not supported yet) and the OMAP5 EVM.

4 21

[U-Boot] [PATCH] MIPS: add atomic operations support.
by Govindraj Raja 25 Aug '15

25 Aug '15

some of the u-boot frameworks like ubi-fs and eth_gadget uses atomic_* api's. So add atomic api's for mips. This makes ubi-fs on nand work with mips platform. Signed-off-by: Govindraj Raja <Govindraj.Raja(a)imgtec.com> --- arch/mips/include/asm/atomic.h | 90 ++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 90 insertions(+) create mode 100644 arch/mips/include/asm/atomic.h diff --git a/arch/mips/include/asm/atomic.h b/arch/mips/include/asm/atomic.h new file mode 100644 index 0000000..163e7e2 --- /dev/null +++ b/arch/mips/include/asm/atomic.h @@ -0,0 +1,90 @@ +/* + * Based on: linux/arch/mips/include/asm/atomic.h + * + * SPDX-License-Identifier: GPL-2.0+ + */ + +#ifndef __ASM_MIPS_ATOMIC_H +#define __ASM_MIPS_ATOMIC_H + +typedef struct { volatile int counter; } atomic_t; + +#define ATOMIC_INIT(i) { (i) } + +#include <asm/system.h> + +#define atomic_read(v) ((v)->counter) +#define atomic_set(v, i) (((v)->counter) = (i)) + +static inline void atomic_add(int i, volatile atomic_t *v) +{ + unsigned long flags; + + local_irq_save(flags); + v->counter += i; + local_irq_restore(flags); +} + +static inline void atomic_sub(int i, volatile atomic_t *v) +{ + unsigned long flags; + + local_irq_save(flags); + v->counter -= i; + local_irq_restore(flags); +} + +static inline void atomic_inc(volatile atomic_t *v) +{ + unsigned long flags; + + local_irq_save(flags); + v->counter += 1; + local_irq_restore(flags); +} + +static inline void atomic_dec(volatile atomic_t *v) +{ + unsigned long flags; + + local_irq_save(flags); + v->counter -= 1; + local_irq_restore(flags); +} + +static inline int atomic_dec_and_test(volatile atomic_t *v) +{ + unsigned long flags; + int val; + + local_irq_save(flags); + val = v->counter; + v->counter = val -= 1; + local_irq_restore(flags); + + return val == 0; +} + +static inline int atomic_add_negative(int i, volatile atomic_t *v) +{ + unsigned long flags; + int val; + + local_irq_save(flags); + val = v->counter; + v->counter = val += i; + local_irq_restore(flags); + + return val < 0; +} + +static inline void atomic_clear_mask(unsigned long mask, unsigned long *addr) +{ + unsigned long flags; + + local_irq_save(flags); + *addr &= ~mask; + local_irq_restore(flags); +} + +#endif /* __ASM_MIPS_ATOMIC_H */ -- 1.9.1

1 0

[U-Boot] [PATCH v1 1/1] lib/display_options: Fix print_freq
by Suriyan Ramasami 25 Aug '15

25 Aug '15

Build without CONFIG_SPL_SERIAL_SUPPORT does not print the cpu freq. I have seen this in the odroid U3 board, where on boot one sees this: CPU: Exynos4412 @ GHz instead of: CPU: Exynos4412 @ 1 GHz I am assuming that this change was done to get rid of compiler warnings related to unused variables when building with CONFIG_SPL_SERIAL_SUPPORT not being defined in an SPL build. Signed-off-by: Suriyan Ramasami <suriyan.r(a)gmail.com> --- lib/display_options.c | 6 ------ 1 file changed, 6 deletions(-) diff --git a/lib/display_options.c b/lib/display_options.c index df134cd..80316a4 100644 --- a/lib/display_options.c +++ b/lib/display_options.c @@ -26,9 +26,7 @@ int display_options (void) void print_freq(uint64_t freq, const char *s) { unsigned long m = 0; -#if defined(CONFIG_SPL_SERIAL_SUPPORT) unsigned long n; -#endif uint32_t f; static const char names[] = {'G', 'M', 'K'}; unsigned long d = 1e9; @@ -48,9 +46,7 @@ void print_freq(uint64_t freq, const char *s) } f = do_div(freq, d); -#if defined(CONFIG_SPL_SERIAL_SUPPORT) n = freq; -#endif /* If there's a remainder, show the first few digits */ if (f) { @@ -63,9 +59,7 @@ void print_freq(uint64_t freq, const char *s) m = (m / 10) + (m % 100 >= 50); } -#if defined(CONFIG_SPL_SERIAL_SUPPORT) printf("%lu", n); -#endif if (m) printf(".%ld", m); printf(" %cHz%s", c, s); -- 1.9.1

3 5

[U-Boot] 2015.10-rc2 Chromebook Snow boot failure
by Misha Komarovskiy 25 Aug '15

25 Aug '15

Hello, I have failure in attempt to boot Chromebook Snow with 2015.10-rc2 build snow_defconfig, here is error message, it maybe not full as i have some noise on serial console with device: U-Boot 2015.10-rc2 (Aug 21 2015 - 15:43:43 +0000) for snow GPU: Exynos5250 @ 1.7 GHz Model: Google Snow Board: Google Snow DRAM: 2 GiB ERROR: read error from device: bad39118 register: 0x1e! at drivers/power/pmic/max77686.c:44/max77686_read() initcall sequence bfdaf3bc failed at call 43e0418c (err=-5) ### ERROR ### Please RESET the board ### --- Best Regards, Misha Komarovskiy zombahatgmaildotcom

2 6

[U-Boot] [PULL] u-boot-pxa/master
by Marek Vasut 25 Aug '15

25 Aug '15

The following changes since commit c851a2458fbc12495f4f786d4eabb612850a5143: Merge git://git.denx.de/u-boot-socfpga (2015-08-23 20:44:25 -0400) are available in the git repository at: git://git.denx.de/u-boot-pxa.git HEAD for you to fetch changes up to 3664fa1beec3921dcfed605a9b37f63dee28ce6a: arm: pxa: colibri_pxa270: add optional i2c support (2015-08-24 20:30:38 +0200) ---------------------------------------------------------------- Andrew Ruder (2): pxa: Fix boot hang by avoiding vector relocation arm: pxa: use common timer functions Marcel Ziswiler (9): arm: pxa: clean-up include file order arm: pxa: mmc: clean-up include file order serial: pxa: clean-up include file order usb: pxa27x_udc: clean-up include file order lcd: pxa: clean-up include file order arm: pxa: palmtreo680: get rid of obsolete CONFIG_SYS_LCD_PXA_NO_L_BIAS arm: pxa: colibri_pxa270: add some more nor flash details arm: pxa: colibri_pxa270: add optional lcd support arm: pxa: colibri_pxa270: add optional i2c support arch/arm/cpu/pxa/Makefile | 1 + arch/arm/cpu/pxa/pxa2xx.c | 4 ++-- arch/arm/cpu/pxa/relocate.S | 23 +++++++++++++++++++++++ arch/arm/cpu/pxa/timer.c | 71 ++--------------------------------------------------------------------- arch/arm/include/asm/arch-pxa/config.h | 25 +++++++++++++++++++++++++ arch/arm/include/asm/config.h | 5 ++++- drivers/mmc/pxa_mmc_gen.c | 8 +++----- drivers/serial/serial_pxa.c | 4 ++-- drivers/usb/gadget/pxa27x_udc.c | 5 ++--- drivers/video/pxa_lcd.c | 9 ++++----- include/configs/colibri_pxa270.h | 26 ++++++++++++++++++++++++++ include/configs/palmtreo680.h | 1 - 12 files changed, 94 insertions(+), 88 deletions(-) create mode 100644 arch/arm/cpu/pxa/relocate.S create mode 100644 arch/arm/include/asm/arch-pxa/config.h

2 1

[U-Boot] [PATCH] net: e1000: Support 64-bit physical address
by York Sun 25 Aug '15

25 Aug '15

From: Mingkai Hu <Mingkai.Hu(a)freescale.com> High 32-bit address is needed when u-boot runs in 64-bit space. Tested on armv8-based LS2085ARDB. Signed-off-by: Mingkai Hu <Mingkai.Hu(a)freescale.com> Signed-off-by: York Sun <yorksun(a)freescale.com> --- drivers/net/e1000.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/net/e1000.c b/drivers/net/e1000.c index d5d48b1..e816410 100644 --- a/drivers/net/e1000.c +++ b/drivers/net/e1000.c @@ -4980,8 +4980,8 @@ e1000_configure_tx(struct e1000_hw *hw) unsigned long tipg, tarc; uint32_t ipgr1, ipgr2; - E1000_WRITE_REG(hw, TDBAL, (unsigned long)tx_base); - E1000_WRITE_REG(hw, TDBAH, 0); + E1000_WRITE_REG(hw, TDBAL, (unsigned long)tx_base & 0xffffffff); + E1000_WRITE_REG(hw, TDBAH, (unsigned long)tx_base >> 32); E1000_WRITE_REG(hw, TDLEN, 128); @@ -5124,8 +5124,8 @@ e1000_configure_rx(struct e1000_hw *hw) E1000_WRITE_FLUSH(hw); } /* Setup the Base and Length of the Rx Descriptor Ring */ - E1000_WRITE_REG(hw, RDBAL, (unsigned long)rx_base); - E1000_WRITE_REG(hw, RDBAH, 0); + E1000_WRITE_REG(hw, RDBAL, (unsigned long)rx_base & 0xffffffff); + E1000_WRITE_REG(hw, RDBAH, (unsigned long)rx_base >> 32); E1000_WRITE_REG(hw, RDLEN, 128); -- 1.7.9.5

3 3

Re: [U-Boot] [PATCH 0/3] arm: tegra20/colibri_t20: early pmic rail configuration
by Marcel Ziswiler 25 Aug '15

25 Aug '15

On 24 Aug 2015 18:25, Stephen Warren <swarren(a)wwwdotorg.org> wrote: > That almost sounds like there's no need for this patch/series then, > since we're assuming that SW won't leave the HW in a bad state. Well, define bad state please. > If SW > can leave HW in a bad state, the only choice is to fix the issue in HW. As mentioned before I don't quite agree. > However, perhaps you mean there are some states that are worse than > others; we assume that the rails required for the AVP are always in a > good state but the rails required for the CPU/CCPLEX may not be? No, at the end I'm just talking about regular DVFS operation. In fact the AVPs rail gets adjusted too however not in any way such that it won't operate any longer.

1 0

Re: [U-Boot] [PATCH 3/5] arm: tegra30: video: integrate display driver for t30
by Marcel Ziswiler 25 Aug '15

25 Aug '15

On 22 Aug 2015 02:38, Simon Glass <sjg(a)chromium.org> wrote: > Please take a look at tegra124's display driver for an > example. You mean that second copy of the existing Tegra stuff I find myself now certainly in the middle of having to clean up? Thank you!

1 0