Re: [U-Boot] [PATCH v1 0/2] sandbox: Fixes the regmap tests

Hi Jean-Jacques, On Wed, 2 Oct 2019 at 03:29, Jean-Jacques Hiblot wrote: > > The sandbox architecture does not implement the writeX nor readX functions. > This prevents testing properly the regmaps and the other stuff relying on > it. I just added a feature to sandbox to support mmio. I'll send

[U-Boot] [PATCH v1 0/2] sandbox: Fixes the regmap tests

The sandbox architecture does not implement the writeX nor readX functions. This prevents testing properly the regmaps and the other stuff relying on it. Jean-Jacques Hiblot (2): arch: sandbox: Provide working writeX/readX functions test: regmap: check the values read from the regmap

Re: [U-Boot] [U-BOOT PATCH v1 0/2] add gpio support for HiFive Unleashed A00 board.

Hi Bin, On Thu, Sep 26, 2019 at 7:26 AM Bin Meng wrote: > > Hi Sagar, > > On Thu, Sep 26, 2019 at 1:54 AM Sagar Kadam wrote: > > > > Hi Bin, > > > > On Wed, Sep 18, 2019 at 1:23 PM Bin Meng wrote: > > > > > > Hi Sagar, > > > > > > On Tue, Sep 10, 2019 at 11:44 PM Sagar Shrikant Kadam > > >

Re: [U-Boot] [U-BOOT PATCH v1 0/2] add gpio support for HiFive Unleashed A00 board.

Hi Sagar, On Thu, Sep 26, 2019 at 1:54 AM Sagar Kadam wrote: > > Hi Bin, > > On Wed, Sep 18, 2019 at 1:23 PM Bin Meng wrote: > > > > Hi Sagar, > > > > On Tue, Sep 10, 2019 at 11:44 PM Sagar Shrikant Kadam > > wrote: > > > > > > U-Boot currently is missing GPIO support for FU540-C000 SoC which

Re: [U-Boot] [U-BOOT PATCH v1 0/2] add gpio support for HiFive Unleashed A00 board.

Hi Bin, On Wed, Sep 18, 2019 at 1:23 PM Bin Meng wrote: > > Hi Sagar, > > On Tue, Sep 10, 2019 at 11:44 PM Sagar Shrikant Kadam > wrote: > > > > U-Boot currently is missing GPIO support for FU540-C000 SoC which is > > mounted on HiFive Unleashed A00 board. This patch is intended to add DM > >

Re: [U-Boot] [U-BOOT PATCH v1 0/2] add gpio support for HiFive Unleashed A00 board.

Hi Sagar, On Tue, Sep 10, 2019 at 11:44 PM Sagar Shrikant Kadam wrote: > > U-Boot currently is missing GPIO support for FU540-C000 SoC which is > mounted on HiFive Unleashed A00 board. This patch is intended to add DM > based GPIO controller driver in order to access GPIO pins within the SoC >

[U-Boot] [U-BOOT PATCH v1 0/2] add gpio support for HiFive Unleashed A00 board.

U-Boot currently is missing GPIO support for FU540-C000 SoC which is mounted on HiFive Unleashed A00 board. This patch is intended to add DM based GPIO controller driver in order to access GPIO pins within the SoC using GPIO command in U-Boot. More details on the GPIO controller within the SoC can

[U-Boot] [PATCH v1 0/2] imx6ull: Fix missing initial output from UART

For Colibri iMX6ULL we have to set pinmux for uart configuration ASAP (ideally before relocation) to get serial console working. Without this we miss almost the half of output (U-boot version, CPU defails, Reset cause, DRAM details etc.). To achieve this we need to force pinctrl-mx6 to get probed

Re: [U-Boot] [PATCH v1 0/2] android: colibri_imx7: reserve DDR memory for Cortex-M4

On Fri, Jul 12, 2019 at 1:50 PM Igor Opaniuk wrote: > > i.MX 7's Cortex-M4 core can run from DDR and uses DDR memory for > the rpmsg communication. Both use cases need a fixed location of > memory reserved. For the rpmsg use case the reserved area needs > to be in sync with the kernel's hardcoded

[U-Boot] [PATCH v1 0/2] android: colibri_imx7: reserve DDR memory for Cortex-M4

i.MX 7's Cortex-M4 core can run from DDR and uses DDR memory for the rpmsg communication. Both use cases need a fixed location of memory reserved. For the rpmsg use case the reserved area needs to be in sync with the kernel's hardcoded vring descriptor location. Introduce support for adding

[U-Boot] [PATCH v1 0/2] Add SDHCI card detection support

This patch series adds card detection support in sdhci framework & added functionality to read card detect dt properties. Thanks, Michal T Karthik Reddy (2): mmc: sdhci: Implement SDHCI card detect mmc: sdhci: Read sdhci card detect properties from DT drivers/mmc/sdhci.c | 47

[U-Boot] [PATCH v1 0/2] Use SPL_FIT_IMAGE_TINY to reduce the size the SPL for the am335x_evm

Patch #1 handles a corner case: SPL_FIT_IMAGE and SPL_OS_BOOT at the same time Patch #2 enables SPL_FIT_IMAGE_TINY for the am335x_evm platform Jean-Jacques Hiblot (2): spl: fit: Always enable tracking of os-type if SPL_OS_BOOT is enabled configs: am335x_evm: enable SPL_FIT_IMAGE_TINY

Re: [U-Boot] [PATCH v1 0/2] Allow platform specific service handling on PSCI

On Wed, 2019-03-13 at 12:01 -0400, Tom Rini wrote: > On Wed, Mar 13, 2019 at 08:10:31AM +, Ang, Chee Hong wrote: > > > > On Mon, 2019-03-11 at 15:48 -0400, Tom Rini wrote: > > > > > > On Mon, Mar 11, 2019 at 03:27:52PM +, Ang, Chee Hong wrote: > > > > > > > > > > > > On Fri, 2019-03-08

[U-Boot] [PATCH v1 0/2] support for ROHM BD71827 and BD71847 PMICs

Patch series to support for ROHM BD71827 and BD71847 PMICs. ROHM BD71837 and BD71847 is PMIC intended for powering single-core, dual-core, and quad-core SoC’s such as NXP-i.MX 8M. BD71847 is used for example on NXP imx8mm EVK. Series adds PMIC driver with register read and write support, and

Re: [U-Boot] [PATCH v1 0/2] Allow platform specific service handling on PSCI

On Wed, Mar 13, 2019 at 08:10:31AM +, Ang, Chee Hong wrote: > On Mon, 2019-03-11 at 15:48 -0400, Tom Rini wrote: > > On Mon, Mar 11, 2019 at 03:27:52PM +, Ang, Chee Hong wrote: > > > > > > On Fri, 2019-03-08 at 13:09 -0500, Tom Rini wrote: > > > > > > > > On Tue, Feb 12, 2019 at

Re: [U-Boot] [PATCH v1 0/2] Allow platform specific service handling on PSCI

On Mon, 2019-03-11 at 15:48 -0400, Tom Rini wrote: > On Mon, Mar 11, 2019 at 03:27:52PM +, Ang, Chee Hong wrote: > > > > On Fri, 2019-03-08 at 13:09 -0500, Tom Rini wrote: > > > > > > On Tue, Feb 12, 2019 at 12:27:01AM -0800, chee.hong@intel.com > > > wrote: > > > > > > > > > > > > >

Re: [U-Boot] [PATCH v1 0/2] Allow platform specific service handling on PSCI

On Mon, Mar 11, 2019 at 03:27:52PM +, Ang, Chee Hong wrote: > On Fri, 2019-03-08 at 13:09 -0500, Tom Rini wrote: > > On Tue, Feb 12, 2019 at 12:27:01AM -0800, chee.hong@intel.com > > wrote: > > > > > > > > From: "Ang, Chee Hong" > > > > > > Currently u-boot only support standard PSCI

Re: [U-Boot] [PATCH v1 0/2] Allow platform specific service handling on PSCI

On Fri, 2019-03-08 at 13:09 -0500, Tom Rini wrote: > On Tue, Feb 12, 2019 at 12:27:01AM -0800, chee.hong@intel.com > wrote: > > > > > From: "Ang, Chee Hong" > > > > Currently u-boot only support standard PSCI functions for power > > management > > and lack of convenient method to allow the

Re: [U-Boot] [PATCH v1 0/2] Allow platform specific service handling on PSCI

On Tue, Feb 12, 2019 at 12:27:01AM -0800, chee.hong@intel.com wrote: > From: "Ang, Chee Hong" > > Currently u-boot only support standard PSCI functions for power management > and lack of convenient method to allow the users to extend the PSCI functions > to support platform specific

Re: [U-Boot] [PATCH v1 0/2] Allow platform specific service handling on PSCI

On Tue, 2019-02-12 at 00:27 -0800, chee.hong@intel.com wrote: > From: "Ang, Chee Hong" Hi Tom/Albert,        Any comment on this patch ? Best Regards, Ang > > Currently u-boot only support standard PSCI functions for power > management > and lack of convenient method to allow the users to

[U-Boot] [PATCH v1 0/2] Update pinctrl-uclass

This series adds: - For system with multiple pincontroller device, insure probe order to avoid race condition using sequence number (alias) - Avoid to bind child node with gpio-controller properties. Patrice Chotard (1): dm: pinctrl: Avoid race condition on probe for UCLASS_PINCTRL

Re: [U-Boot] [PATCH v1 0/2] Allow platform specific service handling on PSCI

Hi Tom,         Any comments on this patch ? Best Regards, Ang On Tue, 2019-02-12 at 00:27 -0800, chee.hong@intel.com wrote: > From: "Ang, Chee Hong" > > Currently u-boot only support standard PSCI functions for power > management > and lack of convenient method to allow the users to

[U-Boot] [PATCH v1 0/2] Allow platform specific service handling on PSCI

From: "Ang, Chee Hong" Currently u-boot only support standard PSCI functions for power management and lack of convenient method to allow the users to extend the PSCI functions to support platform specific services. Most of the u-boot users still rely on ATF (ARM Trusted Firmware) to handle the

[U-Boot] [PATCH v1 0/2] stm32f7 gpio driver fixes

This series adds: - Fix gpio bank hole management for stm32 F7 and H7 - Fix SPL code size for stm32 F7 Patrice Chotard (2): gpio: stm32f7: Fix gpio bank hole management gpio: stm32f7: Fix SPL code size drivers/gpio/stm32f7_gpio.c | 22 +- 1 file changed, 17

[U-Boot] [PATCH v1 0/2] Fix USB port indexes for USB gadget commands

The USB gadget commands take the USB port index as a parameter. This is not playing well with the current DM support for gadget when USB0 is dedicated to host and USB1 dedicated to gadget. This problem has been reported by Sam Protsenko This patch fixes this by using the aliases provided by the

[U-Boot] [PATCH v1 0/2] ACPI: Generate SPCR table

This is a WIP series (I have no time to continue with it, so, that's why WIP) to enable SPCR table generation in U-Boot. This table is useful to get early console in Linux for debugging purposes. The benefit of using it is not only for x86, but also for arm64 community (actually they introduced

[U-Boot] [PATCH v1 0/2] Replace serial setparity by setconfig

This series : _ replace setparity ops by more complete setconfig in serial uclass _ replace setparity by setconfig in STM32 serial driver Patrice Chotard (1): serial: stm32: Replace setparity by setconfig Patrick Delaunay (1): dm: serial: Replace setparity by setconfig

[U-Boot] [PATCH v1 0/2] Update STM32 QSPI driver

This series : _ assign operation mode in _stm32_qspi_gen_ccr() _ rework mode management to solve quad read issue with Macronix/Micron spi nor. Christophe Kerello (2): spi: stm32_qspi: assign functional operation mode in _stm32_qspi_gen_ccr spi: stm32_qspi: rework mode management

[U-Boot] [PATCH v1 0/2] Add bootlimit to Kconfig

This patch series adds the bootlimit environment variable to Kconfig and migrates users to it. Alex Kiernan (2): Add BOOTCOUNT_BOOTLIMIT to set reboot limit Migrate bootlimit to Kconfig configs/brppt1_mmc_defconfig | 1 + configs/brppt1_nand_defconfig | 1 +

[U-Boot] [PATCH v1 0/2] stm32_serial fixes

This series : _ enable overrun uart feature _ rename status register flags Patrice Chotard (2): serial: serial_stm32: Enable overrun serial: serial_stm32: Rename status register flags drivers/serial/serial_stm32.c | 21 ++--- drivers/serial/serial_stm32.h | 12

[U-Boot] [PATCH v1 0/2] Add STM32MP157 SoC Power regulator

This series : _ adds stmpu157 SoC power regulator driver _ populates DT with SoC power regulator entry Patrice Chotard (1): ARM: dts: stm32mp157: Add SoC pwr regulator entry Patrick Delaunay (1): stm32mp: regulator: add SoC pwr regulator support arch/arm/dts/stm32mp157.dtsi

Re: [U-Boot] [PATCH v1 0/2] Fix DM_SCSI on DRA7 platforms

On 6.4.2018 15:58, Jean-Jacques Hiblot wrote: > > > On 06/04/2018 14:00, Michal Simek wrote: >> Hi, >> >> On 6.4.2018 11:13, Jean-Jacques Hiblot wrote: >>> Enhancements to SCSI support for driver model have broken the support >>> for >>> DM_SCSI on DRA7 platforms. This series fixes it. >>> >>>

Re: [U-Boot] [PATCH v1 0/2] Fix DM_SCSI on DRA7 platforms

On 06/04/2018 14:00, Michal Simek wrote: Hi, On 6.4.2018 11:13, Jean-Jacques Hiblot wrote: Enhancements to SCSI support for driver model have broken the support for DM_SCSI on DRA7 platforms. This series fixes it. Tested on: - dra76 evm Jean-Jacques Hiblot (2): dwc_ahci: Fix breakage

Re: [U-Boot] [PATCH v1 0/2] Fix DM_SCSI on DRA7 platforms

Hi, On 6.4.2018 11:13, Jean-Jacques Hiblot wrote: > Enhancements to SCSI support for driver model have broken the support for > DM_SCSI on DRA7 platforms. This series fixes it. > > Tested on: > - dra76 evm > > > Jean-Jacques Hiblot (2): > dwc_ahci: Fix breakage > configs:

[U-Boot] [PATCH v1 0/2] Fix DM_SCSI on DRA7 platforms

Enhancements to SCSI support for driver model have broken the support for DM_SCSI on DRA7 platforms. This series fixes it. Tested on: - dra76 evm Jean-Jacques Hiblot (2): dwc_ahci: Fix breakage configs: dra7xx_evm/dra7xx_hs_evm: Enable AHCI and PIPE3 configs/dra7xx_evm_defconfig| 2

[U-Boot] [PATCH v1 0/2] ARM: mvebu: a38x: updates

This small series represents some low hanging fruit needed before we can bring in the updated version of Marvell's DDR training code. These are things that really shouldn't have been part of the DDR code in the first place but for one reason or another ended up there. Patch 2 is borrowed in part

[U-Boot] [PATCH v1 0/2] Add pinctrl support for RK3399 I2C[123467]

This patch series adds support for the I2C controller 1-4 and 6-7 Philipp Tomsich (2): rockchip: pinctrl: rk3399: fix GPIO2B1 and GPIO2B2 shift value rockchip: pinctrl: rk3399: add support for I2C[123467] arch/arm/include/asm/arch-rockchip/grf_rk3399.h | 34 +-

[U-Boot] [PATCH v1 0/2]

This series is about fixing 2 issues: - SD breakage with QEmu / vexpress-a15 - incorrect version identification for MMC above version 4.41 (included) Thanks to Jonathan Gray and eil Eilmsteiner Heribert for reporting them. Jean-Jacques Hiblot (2): mmc: Fix bug in sd_set_card_speed() mmc:

[U-Boot] [PATCH v1 0/2] arm: ppc: Share DPAA1 fixups between ARCHs

- Support DPAA1 QBMan device tree fixups in a shared location for both arm and ppc architectures - cleanup a define from header files and add as Kconfig with auto selection based on SOC Ahmed Mansour (2): drivers/misc: Share qbman init between archs Move SYS_DPAA_QBMAN to Kconfig

Re: [U-Boot] [PATCH v1 0/2] Add support for the A64-uQ7 modules

On Tue, Feb 21, 2017 at 5:17 AM, Philipp Tomsich wrote: > This changeset adds support for the A64-uQ7 modules from Theobroma > Systems, which is based on Allwinner's A64 (sun50iw1p1). > > It depends on the device-model support for the sunxi subarchitecture >

Re: [U-Boot] [PATCH v1 0/2] DS1307 RTC update

+Tom Hi Chris, On 21 April 2017 at 10:27, Chris Packham wrote: > > The first patch is the addition of a KConfig option for the date > command. I haven't updated any boards to use the new option due to the > sheer number of boards that would affect. It's probably better

[U-Boot] [PATCH v1 0/2] DS1307 RTC update

The first patch is the addition of a KConfig option for the date command. I haven't updated any boards to use the new option due to the sheer number of boards that would affect. It's probably better if board maintainers switch if/when they're ready. The second patch is the change I really want

Re: [U-Boot] [PATCH v1 0/2]

Hi Eric Please don't forget the title of cover letter next time. 2017-04-18 16:21 GMT+08:00 Eric Gao : > Add bmp logo display support for evb-rk3399 > Can you elaborate the commit message? > > > Changes in v1: > -Add bmp logo display support. > -Enable logo display for

[U-Boot] [PATCH v1 0/2]

Add bmp logo display support for evb-rk3399 Changes in v1: -Add bmp logo display support. -Enable logo display for evb-rk3399 Eric Gao (2): board: rockchip: common: Add bmp logo support rockchip: include: Enable logo display for evb-rk3399 board/rockchip/common/Makefile |9 +

[U-Boot] [PATCH v1 0/2]

Add bmp logo display support for evb-rk3399 Changes in v1: -Add bmp logo display support. -Enable logo display for evb-rk3399 Eric Gao (2): board: rockchip: common: Add bmp logo support rockchip: include: Enable logo display for evb-rk3399 board/rockchip/common/Makefile |9 +

[U-Boot] [PATCH v1 0/2] rockchip: dts: rk3399-puma: Update to use DDR3-1600 timings

With our validation having progresses to the point of tuning the DRAM interface, we can now use a DDR3-1600 timing (i.e. 800MHz base clock) as the default for the RK3399-Q7 (Puma). This series - adds a DDR3-1600 timing for the RK3399-Q7 - switches the RK3399-Q7 over to use this new timing -

Re: [U-Boot] [PATCH v1 0/2] disk: efi: allow gap before partition entries

On Tue, Feb 21, 2017 at 07:21:42PM +0100, Dr. Philipp Tomsich wrote: > > > On 21 Feb 2017, at 18:45, Maxime Ripard > > wrote: > > > > However, I'm a bit skeptical on the /config node. First, this node > > doesn't exist at all, and needs to be documented and

Re: [U-Boot] [PATCH v1 0/2] disk: efi: allow gap before partition entries

> On 22 Feb 2017, at 07:11, Rask Ingemann Lambertsen wrote: > > On Fri, Feb 17, 2017 at 06:31:29PM +0100, Philipp Tomsich wrote: >> Motivated by the the SPL layout for SD/MMC devices on Allwinner SoCs >> (the SPL code needs to reside an 8K offset into the device), we add >>

Re: [U-Boot] [PATCH v1 0/2] disk: efi: allow gap before partition entries

On Fri, Feb 17, 2017 at 06:31:29PM +0100, Philipp Tomsich wrote: > Motivated by the the SPL layout for SD/MMC devices on Allwinner SoCs > (the SPL code needs to reside an 8K offset into the device), we add > support for leaving a gap between the MBR (LBA#0), GPT header (LBA#1) > and GPT partition

Re: [U-Boot] [PATCH v1 0/2] disk: efi: allow gap before partition entries

> On 21 Feb 2017, at 18:45, Maxime Ripard > wrote: > > However, I'm a bit skeptical on the /config node. First, this node > doesn't exist at all, and needs to be documented and acked by the DT > maintainers. And why would one need to change that per device?

Re: [U-Boot] [PATCH v1 0/2] disk: efi: allow gap before partition entries

Maxime, > On 21 Feb 2017, at 18:45, Maxime Ripard > wrote: > > Hi Philipp, > > On Fri, Feb 17, 2017 at 06:31:29PM +0100, Philipp Tomsich wrote: >> Motivated by the the SPL layout for SD/MMC devices on Allwinner SoCs >> (the SPL code needs to reside an 8K

Re: [U-Boot] [PATCH v1 0/2] sun8i_emac: set MDC divider for MDIO read/write

On Fri, Feb 17, 2017 at 06:46:51PM +0100, Philipp Tomsich wrote: > To ensure compatibility with all PHYs, we need to keep the MDIO clock > (MDC) below 2.5MHz (the guaranteed operating limit from IEEE 802.3), > even if some PHYs will tolerate higher speeds. > > This changeset also cleans up the

Re: [U-Boot] [PATCH v1 0/2] disk: efi: allow gap before partition entries

Hi Philipp, On Fri, Feb 17, 2017 at 06:31:29PM +0100, Philipp Tomsich wrote: > Motivated by the the SPL layout for SD/MMC devices on Allwinner SoCs > (the SPL code needs to reside an 8K offset into the device), we add > support for leaving a gap between the MBR (LBA#0), GPT header (LBA#1) > and

[U-Boot] [PATCH v1 0/2] Add support for the A64-uQ7 modules

This changeset adds support for the A64-uQ7 modules from Theobroma Systems, which is based on Allwinner's A64 (sun50iw1p1). It depends on the device-model support for the sunxi subarchitecture and the DM-based, dual-IO capable SPI driver which we submitted over the last couple of days. Given

[U-Boot] [PATCH v1 0/2] sunxi: A64: support GPIO

This changeset adds support for the PIO and the R_PIO block on the sun50iw1p1 (A64). Philipp Tomsich (2): sunxi: sun50i/a64: enabled GPIO via sunxi_gpio.c sunxi: sun50i/a64: add r_pio (bank 'L') gpio support arch/arm/dts/sun50i-a64.dtsi | 11 +++ drivers/gpio/sunxi_gpio.c| 7

[U-Boot] [PATCH v1 0/2] sunxi: Gigabit PHY support for SUN8I_EMAC

The sun8i_emac is a triple-speed Ethernet controller. This changeset adds support for negotiating links at gigabit speeds: * enables CONFIG_PHY_GIGE * enables support for the Micrel KSZ9031 GbE PHY Separated out into two changes, as CONFIG_PHY_GIGE is needed with any GbE PHY for

[U-Boot] [PATCH v1 0/2] sun8i_emac: set MDC divider for MDIO read/write

To ensure compatibility with all PHYs, we need to keep the MDIO clock (MDC) below 2.5MHz (the guaranteed operating limit from IEEE 802.3), even if some PHYs will tolerate higher speeds. This changeset also cleans up the MDIO read/write functions by removing pointless bit-masking in a variable

[U-Boot] [PATCH v1 0/2] sunxi: A64: support I2C and R_I2C

This changeset adds the necessary defines and pin-config to enable I2C and R_I2C on the sun50iw1p1 (A64). Tested on the A64-uQ7. Philipp Tomsich (2): sunxi (sun50i): support i2c on A64 (pin-config, clocking) sunxi (sun50i): support R_I2C on A64 (pin-config, clocking)

[U-Boot] [PATCH v1 0/2] sunxi: MUSB support for the sun50i (A64)

The A64 has 3 USB controllers and 2 USB PHYs, but a somewhat odd (actually it's wasteful, as there's no way to use the 2 PHYs and the HSIC output concurrently) muxing scheme between those: * PHY 0 is multiplexed to either MUSB (dual-role) or HCI0 * PHY 1 is dedicated to HCI1 This changeset

[U-Boot] [PATCH v1 0/2] disk: efi: allow gap before partition entries

Motivated by the the SPL layout for SD/MMC devices on Allwinner SoCs (the SPL code needs to reside an 8K offset into the device), we add support for leaving a gap between the MBR (LBA#0), GPT header (LBA#1) and GPT partition entries (linked from field in the GPT header). Note that this affects

Re: [U-Boot] [PATCH v1 0/2] ARM: dts: at91: add dts files for the boards of SAMA5D3

Hi Andreas, There are several patches I sent two months ago using the your older mail address, I am not sure if you received them successfully. If not, I will resent them. Sorry for the inconvenience caused. Best Regards, Wenyou Yang > -Original Message- > From: Wenyou Yang

[U-Boot] [PATCH v1 0/2] ARM: dts: at91: add dts files for the boards of SAMA5D3

The purpose of the patchset is add the dts files for boards, sama5d3 Xplained board and sama5d3xek board. Wenyou Yang (2): ARM: at91: dt: add dts files for sama5d3ek board ARM: at91: dt: add dts file for sama5d3 Xplained arch/arm/dts/Makefile |7 +

[U-Boot] [PATCH v1 0/2] ARM: dts: at91: add dts files for the boards of SAMA5D4

The purpose of the patchset is add the dts files for boards, sama5d4 Xplained board and sama5d4ek board. Wenyou Yang (2): ARM: dts: at91: add dts file for sama5d4 Xplained board ARM: dts: at91: add dts file for sama5d4ek board arch/arm/dts/Makefile |6 +

[U-Boot] [PATCH v1 0/2] pinctrl: at91: Add pinctrl driver

The purpose of this patch set is to add the pinctrl driver for AT91 PIO controller. Wenyou Yang (2): gpio: at91_gpio: Remove CPU_HAS_PIO3 macro pinctrl: pinctrl-at91: Add pinctrl driver arch/arm/mach-at91/include/mach/at91_pio.h | 67 ++-- arch/arm/mach-at91/include/mach/at91sam9x5.h

Re: [U-Boot] [PATCH v1 0/2] spl: move SPL_OS_BOOT and SYS_OS_BASE to Kconfig

Hello Andrew, Am 06.10.2016 um 18:29 schrieb Andrew F. Davis: On 10/06/2016 12:55 AM, Heiko Schocher wrote: This 2 patches move SPL_OS_BOOT and SYS_OS_BASE to Kconfig. Checked with tbot testcase: https://github.com/hsdenx/tbot/blob/master/src/tc/uboot/tc_uboot_check_kconfig.py result: Boards

Re: [U-Boot] [PATCH v1 0/2] spl: move SPL_OS_BOOT and SYS_OS_BASE to Kconfig

On Thu, Oct 06, 2016 at 11:29:27AM -0500, Andrew F. Davis wrote: > On 10/06/2016 12:55 AM, Heiko Schocher wrote: > > This 2 patches move SPL_OS_BOOT and SYS_OS_BASE > > to Kconfig. Checked with tbot testcase: > > https://github.com/hsdenx/tbot/blob/master/src/tc/uboot/tc_uboot_check_kconfig.py > >

Re: [U-Boot] [PATCH v1 0/2] spl: move SPL_OS_BOOT and SYS_OS_BASE to Kconfig

On 10/06/2016 12:55 AM, Heiko Schocher wrote: > This 2 patches move SPL_OS_BOOT and SYS_OS_BASE > to Kconfig. Checked with tbot testcase: > https://github.com/hsdenx/tbot/blob/master/src/tc/uboot/tc_uboot_check_kconfig.py > > result: > > Boards : 1213 > compile err : 13 > not checked : 1 >

[U-Boot] [PATCH v1 0/2] spl: move SPL_OS_BOOT and SYS_OS_BASE to Kconfig

This 2 patches move SPL_OS_BOOT and SYS_OS_BASE to Kconfig. Checked with tbot testcase: https://github.com/hsdenx/tbot/blob/master/src/tc/uboot/tc_uboot_check_kconfig.py result: Boards : 1213 compile err : 13 not checked : 1 U-Boot good : 1185 bad 14 SPL good: 1199 bad 0 Boards not

[U-Boot] [PATCH v1 0/2] serial: atmel_usart: Support to enable an early debug UART

The patch set is to add support to enable an early debug UART for debugging. And add ATMEL_USART option to enable the Atmel usartdriver from Kconfig. Wenyou Yang (2): serial: Kconfig: Add ATMEL_USART option serial: atmel_usart: Support enable an early debug UART drivers/serial/Kconfig

[U-Boot] [PATCH v1 0/2] clk: at91: Fix the wrong used class ID

This patch set is to fix the wrong used class ID. The class ID of the at91-pmc and at91-sckc driver should be UCLASS_SIMPLE_BUS, instead of UCLASS_CLK. And add an empty .ops callback for the clk_generic driver to avoid a wild pointer. Wenyou Yang (2): clk: at91: Fix at91-pmc and at91-sckc's

[U-Boot] [PATCH v1 0/2] Rename all B boards to more meaningful name

We've internally decided to name all B boards to be related in the final product where they are built in, which is more meaningful than the name of the circuit board itself. Hannes Schmelzer (2): board/BuR: rename tseries board to brppt1 board/BuR: rename kwb board to brxre1

[U-Boot] [PATCH v1 0/2] Add back P2020DS

Recently Freescale (now NXP) received order to make more P2020DS. It's better have to U-Boot support than digging out old releases. Changes in v1: Add back P2020DS, using generic board structure. Initial patch to adjust DDR speed tables. York Sun (2): Revert "powerpc: mpc85xx: remove P2020DS

[U-Boot] [PATCH v1 0/2] MIPS: refactor machine setup

Refactor machine setup like it is done on ARM. While on it, also support "include mach-au1x00/include/mach}/au1x00.h | 0 board/dbau1x00/dbau1x00.c| 2 +- board/dbau1x00/lowlevel_init.S | 2 +- board/pb1x00/lowlevel_init.S

[U-Boot] [PATCH v1 0/2] This little series fixes some issues with kwbimage.

It makes kwbimage working on BE build hosts and fixes some flaws in computation of image header sizes. Reinhard Pfau (2): kwbimage: fix endianess issue kwbimage: fix size computations for v1 images tools/kwbimage.c | 50 -- tools/kwbimage.h |

Re: [U-Boot] [PATCH v1 0/2] arm, imx6, aristainetos2: set gpr register after reset

Hello Stefano, Am 25.09.2015 um 12:31 schrieb Heiko Schocher: setting the gpr 1,8 and 12 registers to a fix value. This is needed because after a WDT reset, this registers are not correct resettet, and prevent linux from booting again. with this patches no compileerrors found: $

Re: [U-Boot] [PATCH v1 0/2] arm, imx6, aristainetos2: set gpr register after reset

On 29/10/2015 11:40, Heiko Schocher wrote: > Hello Stefano, > > Am 25.09.2015 um 12:31 schrieb Heiko Schocher: >> setting the gpr 1,8 and 12 registers to a fix value. >> This is needed because after a WDT reset, this registers >> are not correct resettet, and prevent linux from booting >> again.

[U-Boot] [PATCH v1 0/2] arm, imx6, aristainetos2: set gpr register after reset

setting the gpr 1,8 and 12 registers to a fix value. This is needed because after a WDT reset, this registers are not correct resettet, and prevent linux from booting again. with this patches no compileerrors found: $ ./tools/buildman/buildman -b 20150925 mx6 boards.cfg is up to date. Nothing to

[U-Boot] [PATCH v1 0/2] Fix init_ram for e6500 and e5500

We have been using locked cache for init_ram for MPC85xx for quite a long time. It works until e6500 comes. On e6500, L1 cache is write-through. L2 cache has to be enabled to hold the data. We have not locked L2 cache and we used reserved space in ccsr to make the address valid. Now the reserved

Re: [U-Boot] [PATCH v1 0/2] Rename DDR4 target names

Hello York, For T1040QDS, we can change the name. For T1024 also, I think there should not be any issue. Shengzhou please confirm. Regards Priyanka From: Sun York-R58495 Sent: Monday, August 10, 2015 8:18 PM To: Jain Priyanka-B32167; Sun York-R58495; U-Boot Mailing List Cc: Wood Scott-B07421;

Re: [U-Boot] [PATCH v1 0/2] Rename DDR4 target names

Priyanka, If the boards have been officially named T1040D4RDB/T1042D4RDB, we can keep the names. How about QDS and T1024 boards? York Original message From: Jain Priyanka-B32167 Date:08/09/2015 22:01 (GMT-08:00) To: Sun York-R58495 , U-Boot Mailing List Cc: Wood Scott-B07421

Re: [U-Boot] [PATCH v1 0/2] Rename DDR4 target names

Hello York, T1040D4RDB/T1042D4RDB boards have other difference as well apart from DDR4 w.r.t old T1040RDB/T1042RDB. T1040D4RDB/T1042D4RDB is the naming convection that has been used to distinguished new T1040RDB/T1042RDB board with DDR4 memory, new serdes protocol support , new muxes , etc.

[U-Boot] [PATCH v1 0/2] Rename DDR4 target names

Freescale T1 series supports both DDR3 and DDR4. We have boards for each type of memory. To make the naming consistence and easy to understand, use _DDR4 instead of _D4 for the names. The same applies to Layerscape LS1 series, which already has _ddr4 in the name. LS2 series doesn't support DDR3,

[U-Boot] [PATCH v1 0/2] SHEEVAPLUG : OPENWRT READY

Prepare ENV settings for sheevaplugs to be OpenWRT ready. +--+ | UBOOT| 896 Kb (7x128) = uboot +--+ | ENV | 128 Kb = uboot_env +--+ | IMAGES | 23 Mb @ 1 Mb= image - UIMAGE+UINITRD+FDT

[U-Boot] [PATCH v1 0/2] Fix SoC-specific exception handling

Short version: * this patch fixes exception handling on i.MX27 which was broken, probably from day one. * i.MX27-based board Maintainers please test this patch: make sure your board boots with it and make sure e.g. a write to address 0 causes U-Boot to signal a data abort. * i.MX

[U-Boot] [PATCH v1 0/2] Fix some ppc4xx i2c controller issues

From: Dirk Eibach dirk.eib...@gdsys.cc Dirk Eibach (2): ppc4xx: Fix i2c repeated start ppc4xx: Handle i2c stuck on combined xfer arch/powerpc/include/asm/ppc4xx-i2c.h | 2 ++ drivers/i2c/ppc4xx_i2c.c | 30 ++ 2 files changed, 28 insertions(+), 4

Re: [U-Boot] [PATCH v1 0/2] usb: dfu: am335x: allow dfu in fullspeed mode only

Hi all -Ursprüngliche Nachricht- Von: Heiko Schocher [mailto:h...@denx.de] Gesendet: Dienstag, 9. September 2014 16:22 An: Lukasz Majewski Cc: u-boot@lists.denx.de; Tom Rini; Marek Vasut; Liu Bin; Stockmann, Lukas Betreff: Re: [PATCH v1 0/2] usb: dfu: am335x: allow dfu in fullspeed

[U-Boot] [PATCH v1 0/2] usb: dfu: am335x: allow dfu in fullspeed mode only

This patchserie adds the new config option CONFIG_DFU_FULLSPEED. If this is enabled DFU uses fullspeed only. This is used on the siemens boards. Cc: Tom Rini tr...@ti.com Cc: Lukasz Majewski l.majew...@samsung.com Cc: Marek Vasut ma...@denx.de Cc: Liu Bin b-...@ti.com Cc: Lukas Stockmann

Re: [U-Boot] [PATCH v1 0/2] usb: dfu: am335x: allow dfu in fullspeed mode only

Hi Heiko, This patchserie adds the new config option CONFIG_DFU_FULLSPEED. Is there any special reason to support Full Speed (12 Mbit/sec - USB 1.1) and not rely solely on the High Speed (USB 2.0) as we do now? If this is enabled DFU uses fullspeed only. This is used on the siemens boards.

Re: [U-Boot] [PATCH v1 0/2] usb: dfu: am335x: allow dfu in fullspeed mode only

Lukasz, On 09/09/2014 08:43 AM, Lukasz Majewski wrote: Hi Heiko, This patchserie adds the new config option CONFIG_DFU_FULLSPEED. Is there any special reason to support Full Speed (12 Mbit/sec - USB 1.1) and not rely solely on the High Speed (USB 2.0) as we do now? The drivers must

Re: [U-Boot] [PATCH v1 0/2] usb: dfu: am335x: allow dfu in fullspeed mode only

Hello Lukasz, Am 09.09.2014 15:43, schrieb Lukasz Majewski: Hi Heiko, This patchserie adds the new config option CONFIG_DFU_FULLSPEED. Is there any special reason to support Full Speed (12 Mbit/sec - USB 1.1) and not rely solely on the High Speed (USB 2.0) as we do now? If this is enabled

Re: [U-Boot] [PATCH v1 0/2] usb: dfu: am335x: allow dfu in fullspeed mode only

Hi Bin, Lukasz, On 09/09/2014 08:43 AM, Lukasz Majewski wrote: Hi Heiko, This patchserie adds the new config option CONFIG_DFU_FULLSPEED. Is there any special reason to support Full Speed (12 Mbit/sec - USB 1.1) and not rely solely on the High Speed (USB 2.0) as we do now?

Re: [U-Boot] [PATCH v1 0/2] Add CONFIG_SYS_GENERIC_BOARD to all gdsys boards

Ping. 2014-06-30 13:05 GMT+02:00 dirk.eib...@gdsys.cc: From: Dirk Eibach dirk.eib...@gdsys.cc Dirk Eibach (2): ppc: Make ppc4xx ready for CONFIG_SYS_GENERIC_BOARD board: Add CONFIG_SYS_GENERIC_BOARD to all gdsys boards arch/powerpc/cpu/ppc4xx/cpu_init.c | 2 ++

[U-Boot] [PATCH v1 0/2] mtd,ubi,ubifs: sync with v3.15

as Tom Rini suggested, I tried to update the mtd,ubi and ubifs subsystem with linux v3.15: commit 1860e379875dfe7271c649058aeddffe5afd9d0d Author: Linus Torvalds torva...@linux-foundation.org Date: Sun Jun 8 11:19:54 2014 -0700 Linux 3.15 First patch in this patchserie is a patch, which

[U-Boot] [PATCH v1 0/2] Add SD boot support for LS1021AQDS/TWR board

This series contain SD boot support for LS1021AQDS/TWR board.SPL framework is used. PBL initialize the internal RAM and copy SPL to it, then SPL initialize DDR using SPD and copy u-boot from SD card to DDR, finally SPL transfer control to u-boot. The patches are based on the former

[U-Boot] [PATCH v1 0/2] Add CONFIG_SYS_GENERIC_BOARD to all gdsys boards

From: Dirk Eibach dirk.eib...@gdsys.cc Dirk Eibach (2): ppc: Make ppc4xx ready for CONFIG_SYS_GENERIC_BOARD board: Add CONFIG_SYS_GENERIC_BOARD to all gdsys boards arch/powerpc/cpu/ppc4xx/cpu_init.c | 2 ++ include/configs/controlcenterd.h | 2 ++ include/configs/dlvision-10g.h | 1

Re: [U-Boot] [PATCH v1 0/2] mtd: nand: omap: booting from NAND using u-boot

Hi Pekon, On Tue, Jan 28, 2014 at 07:42:09AM +, Pekon Gupta wrote: From: Brian Norris On Fri, Dec 13, 2013 at 02:42:56PM +0530, Pekon Gupta wrote: As there were parallel set of patches running between u-boot and kernel. I don't know what patches you're talking about. Following

Re: [U-Boot] [PATCH v1 0/2] mtd: nand: omap: booting from NAND using u-boot

Hi Brian, From: Gupta, Pekon I'm preparing a 3.14 pull request soon, and since you seem committed to fixing and properly testing a known regression here, I'd like to see this go in. But given the late timing and the unanswered questions, I think it's unlikely to go in -rc1. Perhaps I can send a

Re: [U-Boot] [PATCH v1 0/2] mtd: nand: omap: booting from NAND using u-boot

On Mon, Jan 27, 2014 at 9:46 AM, Gupta, Pekon pe...@ti.com wrote: From: Brian Norris 1. This patch series talks extensively about U-Boot. U-Boot is not my interest, nor should it be the focus of kernel (driver) development. Any work done here should be framed in the kernel driver context.

Re: [U-Boot] [PATCH v1 0/2] mtd: nand: omap: booting from NAND using u-boot

Hi Brian, From: Brian Norris 1. This patch series talks extensively about U-Boot. U-Boot is not my interest, nor should it be the focus of kernel (driver) development. Any work done here should be framed in the kernel driver context. [1] Apologies for cross-posting, I understand that you

Re: [U-Boot] [PATCH v1 0/2] mtd: nand: omap: booting from NAND using u-boot

Hi Brian, From: Brian Norris Hi Pekon, Sorry, I'm revisiting your patch series a bit late. There are a few factors that contributed to this, though. 1. This patch series talks extensively about U-Boot. U-Boot is not my interest, nor should it be the focus of kernel (driver) development.

  1   2   >