Re: [U-Boot] QSPI "sf probe ...", "sf read ..." on Altera SoC FPGA

 Pepperl+Fuchs GmbH, Mannheim Geschaeftsfuehrer/Managing Directors: Dr.-Ing. Gunther Kegel (Vors./CEO), Werner Guthier, Mehmet Hatiboglu Vorsitzender des Aufsichtsrats/Chairman of the supervisory board: Claus Michael Registergericht/Register Court: AG Mannheim HRB 4713 On 18.01.2018 06:07,

Re: [U-Boot] [PATCH 3/3] clk: clk_stm32f: Move SYSCFG clock setup into configure_clocks()

Hi Vikas On 01/17/2018 08:55 PM, Vikas Manocha wrote: > Hi Patrice, > > On 01/17/2018 12:46 AM, patrice.chot...@st.com wrote: >> From: Patrice Chotard >> >> Move SYSCFG clock setup into configure_clocks() instead of calling >> clock_setup() from drivers. > > It is in

[U-Boot] [PATCH v2 2/2] efi_selftest: test start image

This test checks the StartImage boot service. An EFI application is loaded into memory and started. The test is not built on x86_64 because the relocation code for the efi binary cannot be created. Signed-off-by: Heinrich Schuchardt --- v2 Do not build test on

[U-Boot] [PATCH v2 1/2] efi_loader: correctly call images

Avoid a failed assertion when an EFI app calls an EFI app. Avoid that the indent level increases when calling 'bootefi hello' repeatedly. Avoid negative indent level when an EFI app calls an EFI app that calls an EFI app (e.g. iPXE loads grub which starts the kernel). Return the status code of

[U-Boot] [PATCH v2 0/2] efi_loader: correctly call images

This patch series fixes various problems with the StartImage boot service. It further provides a unit test. v2 Do not build test on x68_64 due to a problem with the build system for EFI images. Heinrich Schuchardt (2): efi_loader: correctly call images efi_selftest: test

Re: [U-Boot] X86 Broadwell-DE override FSP configuration

Hi Vincenzo, On Thu, Jan 18, 2018 at 4:45 AM, vnktux wrote: > Thank you Bin, > > I managed to fully boot Broadwell-DE on platform with memory down enabled :) > > Now before submitting the patch I have to solve a small problem. > In either case memory down is enable or not

Re: [U-Boot] [PATCH v6 2/2] common: Generic firmware loader for file system

On 27.12.2017 06:04, tien.fong.c...@intel.com wrote: From: Tien Fong Chee This is file system generic loader which can be used to load the file image from the storage into target such as memory. The consumer driver would then use this loader to program whatever, ie.

[U-Boot] [RFC PATCH] mmc: Skipping the MMC initialization at the boot time

From: Vipul Kumar By enabling CONFIG_SKIP_EARLY_MMC_INIT config, user can skip the MMC initialization at the boot time. After getting the u-boot console, user can select the device using mmc dev and can communicate with that. This is useful where user don't want to

Re: [U-Boot] QSPI "sf probe ...", "sf read ..." on Altera SoC FPGA

On 18.01.2018 06:07, Jason Rush wrote: On 1/17/2018 7:46 AM, RB23 wrote: i checked, and if you mean these patches: https://patchwork.ozlabs.org/patch/765992/ https://patchwork.ozlabs.org/patch/765996/ https://patchwork.ozlabs.org/patch/765997/ https://patchwork.ozlabs.org/patch/765998/ i

Re: [U-Boot] QSPI "sf probe ...", "sf read ..." on Altera SoC FPGA

On 1/17/2018 7:46 AM, RB23 wrote: > i checked, and if you mean these patches: > https://patchwork.ozlabs.org/patch/765992/ > https://patchwork.ozlabs.org/patch/765996/ > https://patchwork.ozlabs.org/patch/765997/ > https://patchwork.ozlabs.org/patch/765998/ > > i already applied them, and they

Re: [U-Boot] [PATCH v2 2/2] mmc: Add bcm2835 sdhost controller

On 01/18/2018 08:33 AM, Alexander Graf wrote: > The BCM2835 family of SoCs has 2 different SD controllers: One based on > the SDHCI spec and a custom, home-grown one. > > This patch implements a driver for the latter based on the Linux driver. > This is needed so that we can make use of device

Re: [U-Boot] [PATCH v6 2/2] common: Generic firmware loader for file system

On Tue, 2018-01-16 at 15:41 +0100, Marek Vasut wrote: > On 12/27/2017 06:04 AM, tien.fong.c...@intel.com wrote: > > Whoa, this improved substantially since last time I checked. Minor > nitpicks below. > > [...] > > > > > +/* USB build is not supported yet in SPL */ > > +#ifndef

[U-Boot] [PATCH v2 3/4] ddr: marvell: update additional ODT setting

The RD_SAMPLE_DELAY field is 5 bits so it needs to be masked with 0x1f instead of 0xf. Rather than checking the read sample delay for all DDR chip selects use the values for the chip selects that are actually configured. Finally continue searching for the max_phase value even if the current

[U-Boot] [PATCH v2 4/4] ddr: marvell: update ddr controller init and freq

Update the calculation for tWR and tPD. This improves the DDR refresh interval and brings the initialization into line with the binary blobs currently being supplied by Marvell. Signed-off-by: Chris Packham --- Changes in v2: - new

[U-Boot] [PATCH v2 1/4] ddr: marvell: only assert M_ODT[0] on write for a single CS

When using only a single DDR chip select only assert M_ODT[0] on write. Do not assert it on read and do not assert M_ODT[1] at all. Also set tODT_OFF_WR to 0x9 which contradicts the recommendation from the functional spec but is what Marvell's binary training blob does and seems to give better

[U-Boot] [PATCH v2 2/4] ddr: marvell: use correct TREFI value

The ternary operation had the HIGH/LOW values the wrong way round. Update it to use the correct value. Signed-off-by: Chris Packham --- Changes in v2: - new drivers/ddr/marvell/a38x/ddr3_training.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

[U-Boot] [PATCH v2 0/4] ddr: marvell: update DDR driver

I have a custom board that sees correctable ECC errors (when running memtester[1] from Linux). When I used Marvell's bootloader I didn't see the errors. I've also had a tame hardware engineer (if there is such a thing) looking at the timing waveforms comparing the stock u-boot behaviour against

[U-Boot] [PATCH v2] ARM: dts: Freescale: re-license device tree files under GPLv2+/X11

The current GPL only licensing on the device trees makes it very impractical for other software components licensed under another license. To make it easier to reuse them, re-license the the device trees for Freescale (now NXP) SoCs and boards under GPLv2+/X11 dual license. Same trend is

Re: [U-Boot] [U-Boot, v6, 2/2] common: Generic firmware loader for file system

On Tue, 2018-01-16 at 09:35 -0500, Tom Rini wrote: > On Tue, Jan 16, 2018 at 07:58:00AM +, Chee, Tien Fong wrote: > > > > On Mon, 2018-01-15 at 11:36 -0500, Tom Rini wrote: > > > > > > On Wed, Dec 27, 2017 at 01:04:38PM +0800, tien.fong.c...@intel.co > > > m > > > wrote: > > > > > > > > >

[U-Boot] [PATCH v2 1/1] dm: video: Correct color ANSI escape sequence support

Support special rendition code 0 - reset attributes. Support special rendition code 1 - increased intensity (bold). Get RGB sequence in pixels right (swap blue and red). Do not set reserved bits. Use u32 instead of unsigned for color bit mask. qemu-system-i386 -display sdl -vga virtio and

Re: [U-Boot] [PATCH] ARM: dts: Freescale: re-license device tree files under X11

On Wed, Jan 17, 2018 at 07:26:00PM +, Leo Li wrote: > > > > -Original Message- > > From: Pankaj Bansal > > Sent: Monday, January 15, 2018 11:06 PM > > To: Leo Li > > Cc: u-boot@lists.denx.de; albert.u.b...@aribaud.net; Tom Rini > > ; Priyanka

Re: [U-Boot] [U-Boot, v4, 07/11] spl: add support to booting with OP-TEE

Bryan, On 01/18/2018 01:48 AM, Bryan O'Donoghue wrote: On 15/01/18 04:48, Peng Fan wrote: On Mon, Jan 15, 2018 at 11:25:00AM +0800, Kever Yang wrote: Bryan, On 01/12/2018 11:10 PM, Bryan O'Donoghue wrote: On 12/01/18 11:27, Philipp Tomsich wrote: OP-TEE is an open source trusted OS,

Re: [U-Boot] [PATCH V5 00/31] imx: add i.MX8M support and i.MX8MQ EVK

Hi Stefano, Do you have any comments on this v5 patchset? I would like this patchset could catch up 2018.03. Thanks, Peng. > -Original Message- > From: Peng Fan > Sent: Wednesday, January 10, 2018 1:20 PM > To: sba...@denx.de; Fabio Estevam > Cc:

Re: [U-Boot] [PATCH V5 00/31] imx: add i.MX8M support and i.MX8MQ EVK

> -Original Message- > From: Diego Dorta [mailto:diegohdo...@gmail.com] > Sent: Wednesday, January 17, 2018 11:00 PM > To: Peng Fan > Cc: Peng Fan ; Fabio Estevam > ; U-Boot-Denx ; Diego > Dorta

[U-Boot] [PATCH v2 2/2] mmc: Add bcm2835 sdhost controller

The BCM2835 family of SoCs has 2 different SD controllers: One based on the SDHCI spec and a custom, home-grown one. This patch implements a driver for the latter based on the Linux driver. This is needed so that we can make use of device trees that assume driver presence of both SD controllers.

[U-Boot] [PATCH v2 1/2] bcm283x: Add pinctrl driver

The bcm283x family of SoCs have a GPIO controller that also acts as pinctrl controller. This patch introduces a new pinctrl driver that can actually properly mux devices into their device tree defined pin states and is now the primary owner of the gpio device. The previous GPIO driver gets moved

[U-Boot] [PATCH v2 0/2] Rpi: Add support for second sd host controller

The Raspberry Pi (bcm283x SoC) family contains 2 IP blocks to drive SD peripherals: A pretty standard SDHCI one called iProc and a home grown one called "sdhost". When driving U-Boot by the same device tree that we use for Linux, we end up in situations where only the "sdhost" device is available

Re: [U-Boot] [PATCH v2 7/7] rpi: Force skip_init on serial devices

Hi Alex, On 17 January 2018 at 15:08, Alexander Graf wrote: > > > On 17.01.18 20:40, Simon Glass wrote: >> Hi Alex, >> >> On 17 January 2018 at 00:54, Alexander Graf wrote: >>> The serial devices on the raspberry pi are based on clocks we can't easily >>> read and

Re: [U-Boot] [PATCH v2 2/7] serial: Allow boards to determine whether a serial device is usable

Hi Alex, On 17 January 2018 at 14:37, Alexander Graf wrote: > > > On 17.01.18 23:11, Simon Glass wrote: >> Hi Alex, >> >> On 17 January 2018 at 15:03, Alexander Graf wrote: >>> >>> >>> On 17.01.18 20:39, Simon Glass wrote: Hi Alex, On 17 January 2018

Re: [U-Boot] [PATCH v2 5/7] rpi: Properly detect which serial device is active

Hi Alex, On 17 January 2018 at 15:05, Alexander Graf wrote: > > > On 17.01.18 20:46, Simon Glass wrote: >> Hi Alex, >> >> On 17 January 2018 at 00:54, Alexander Graf wrote: >>> Now that we have all infrastructure in place to dynamically determine >>> whether >>> a

Re: [U-Boot] [PATCH v2 2/7] serial: Allow boards to determine whether a serial device is usable

On 17.01.18 23:11, Simon Glass wrote: > Hi Alex, > > On 17 January 2018 at 15:03, Alexander Graf wrote: >> >> >> On 17.01.18 20:39, Simon Glass wrote: >>> Hi Alex, >>> >>> On 17 January 2018 at 00:54, Alexander Graf wrote: On some boards, serial devices may

Re: [U-Boot] [PATCH v2 2/7] serial: Allow boards to determine whether a serial device is usable

Hi Alex, On 17 January 2018 at 15:03, Alexander Graf wrote: > > > On 17.01.18 20:39, Simon Glass wrote: >> Hi Alex, >> >> On 17 January 2018 at 00:54, Alexander Graf wrote: >>> On some boards, serial devices may or may not be muxed properly to actual >>> pins,

Re: [U-Boot] [PATCH v2 08/15] env: common: Make the debug messages play a little nicer

On 16 January 2018 at 01:16, Maxime Ripard wrote: > Since we have global messages to indicate what's going on, the custom > messages in the environment drivers only make the output less readable. > > Make the common code play a little nicer by removing all the

Re: [U-Boot] [PATCH v2 11/15] env: mmc: depends on the MMC framework

On 16 January 2018 at 01:16, Maxime Ripard wrote: > The raw MMC environment directly calls into the MMC framework. Make sure > it's enabled before we can select it. > > Signed-off-by: Maxime Ripard > --- > env/Kconfig | 1 + >

Re: [U-Boot] [PATCH v2 13/15] env: Mark env_get_location as weak

Hi Maxime, On 16 January 2018 at 01:16, Maxime Ripard wrote: > Allow boards and architectures to override the default environment lookup > code by overriding env_get_location. > > Reviewed-by: Andre Przywara > Reviewed-by: Lukasz

Re: [U-Boot] [PATCH v2 10/15] env: Initialise all the environments

On 16 January 2018 at 01:16, Maxime Ripard wrote: > Since we want to have multiple environments, we will need to initialise > all the environments since we don't know at init time what drivers might > fail when calling load. > > Let's init all of them, and only

Re: [U-Boot] [PATCH v2 7/7] rpi: Force skip_init on serial devices

On 17.01.18 20:40, Simon Glass wrote: > Hi Alex, > > On 17 January 2018 at 00:54, Alexander Graf wrote: >> The serial devices on the raspberry pi are based on clocks we can't easily >> read and influence in U-Boot. However, the serial devices are always already >> properly set

Re: [U-Boot] [PATCH v2 07/15] env: mmc: Make the debug messages play a little nicer

On 16 January 2018 at 01:16, Maxime Ripard wrote: > Since we have global messages to indicate what's going on, the custom > messages in the environment drivers only make the output less readable. > > Make MMC play a little nicer by removing all the extra \n and

Re: [U-Boot] [PATCH v2 5/7] rpi: Properly detect which serial device is active

On 17.01.18 20:46, Simon Glass wrote: > Hi Alex, > > On 17 January 2018 at 00:54, Alexander Graf wrote: >> Now that we have all infrastructure in place to dynamically determine whether >> a serial device is actually usable (read: routed to user accessible pins), we >> can wire

Re: [U-Boot] [PATCH v2 03/15] env: Pass additional parameters to the env lookup function

Hi Maxime, On 16 January 2018 at 01:16, Maxime Ripard wrote: > In preparation for the multiple environment support, let's introduce two > new parameters to the environment driver lookup function: the priority and > operation. > > The operation parameter is meant

Re: [U-Boot] [PATCH v2 06/15] env: fat: Make the debug messages play a little nicer

Hi Maxime, On 16 January 2018 at 01:16, Maxime Ripard wrote: > Since we have global messages to indicate what's going on, the custom > messages in the environment drivers only make the output less readable. > > Make FAT play a little nicer by removing all the

Re: [U-Boot] [PATCH v2 2/7] serial: Allow boards to determine whether a serial device is usable

On 17.01.18 20:39, Simon Glass wrote: > Hi Alex, > > On 17 January 2018 at 00:54, Alexander Graf wrote: >> On some boards, serial devices may or may not be muxed properly to actual >> pins, depending on firmware configuration. To determine whether we should >> use a serial

Re: [U-Boot] [PATCH v2 1/7] serial: Use next serial device if probing fails

On 17.01.18 20:34, Simon Glass wrote: > On 17 January 2018 at 00:54, Alexander Graf wrote: >> Currently our serial device search chokes on the fact that the serial >> probe function could fail. If it does, instead of searching for the next >> usable serial device, it just quits.

Re: [U-Boot] [PATCH] ubi: Fix filesystem corruption on detach when fastmap enabled

Hi, On Wed, Jan 17, 2018 at 3:47 PM, Richard Weinberger wrote: > Martin, > > Am Dienstag, 16. Januar 2018, 15:13:04 CET schrieb Martin Townsend: >> > Martin, can you please explain what corruption you see? >> > From reading the code I'd assume that you miss volumes but a

Re: [U-Boot] [PATCH 1/3] bcm2835_gpio: Add support for pinmux

On 17.01.18 10:26, Amit Tomer wrote: > Hi, > >> + val = readl(>reg->gpfsel[BCM2835_GPIO_FSEL_BANK(gpio)]); >> + val &= ~(BCM2835_GPIO_FSEL_MASK << BCM2835_GPIO_FSEL_SHIFT(gpio)); >> + val |= (func << BCM2835_GPIO_FSEL_SHIFT(gpio)); >> + writel(val,

Re: [U-Boot] [PATCH 3/3] mmc: bcm2835_sdhci: Add pinmux support

On 17.01.18 21:06, Simon Glass wrote: > Hi Alex, > > On 16 January 2018 at 05:46, Alexander Graf wrote: >> The bcm2835 firmware provided device trees expect device tree users >> to support pin muxing for the SD devices to work properly. >> >> This patch adds pin muxing support

Re: [U-Boot] X86 Broadwell-DE override FSP configuration

Thank you Bin, I managed to fully boot Broadwell-DE on platform with memory down enabled :) Now before submitting the patch I have to solve a small problem. In either case memory down is enable or not the booting process takes 1 hour and 20 minutes. On the output there are no error at all. I

Re: [U-Boot] [PATCH 2/3] clk: clk_stm32f: Remove STMMAC clock setup

Hi, On 01/17/2018 12:46 AM, patrice.chot...@st.com wrote: > From: Patrice Chotard > > Thanks to 'commit ba1f96672522 ("net: designware: add clock support")' > we don't need anymore to setup the STMMAC clock in board. > > Signed-off-by: Patrice Chotard

Re: [U-Boot] [PATCH 3/3] clk: clk_stm32f: Move SYSCFG clock setup into configure_clocks()

Hi Patrice, On 01/17/2018 12:46 AM, patrice.chot...@st.com wrote: > From: Patrice Chotard > > Move SYSCFG clock setup into configure_clocks() instead of calling > clock_setup() from drivers. It is in board configuration. > Move the RMII setup from board_early_init_f()

Re: [U-Boot] [PATCH 1/3] bcm2835_gpio: Add support for pinmux

Hi Alex, On 16 January 2018 at 05:46, Alexander Graf wrote: > On the bcm2835 the GPIO IP block is responsible to control pin muxing > of the configurable pins on the chip. > > This adds a simple helper function that allows a device driver to set > pin muxing according to device

Re: [U-Boot] [PATCH 3/3] mmc: bcm2835_sdhci: Add pinmux support

Hi Alex, On 16 January 2018 at 05:46, Alexander Graf wrote: > The bcm2835 firmware provided device trees expect device tree users > to support pin muxing for the SD devices to work properly. > > This patch adds pin muxing support to the sdhci based SD controller > on said family

Re: [U-Boot] [PATCH 3/3] configs: odroid-xu3: enable the configs relevant to regulator

On 15 January 2018 at 22:33, Jaehoon Chung wrote: > Enable the CONFIG_CMD_REGULATOR and CONFIG_DM_REGULATOR_S2MPS11. > > Signed-off-by: Jaehoon Chung > --- > configs/odroid-xu3_defconfig | 2 ++ > 1 file changed, 2 insertions(+) Reviewed-by:

Re: [U-Boot] [PATCH 2/3] power: pmic: s2mps11: probe the regulator driver

On 15 January 2018 at 22:33, Jaehoon Chung wrote: > Add the probe function to support the s2mps11 regulator driver. > > Signed-off-by: Jaehoon Chung > --- > drivers/power/pmic/s2mps11.c | 28 > 1 file changed, 28

Re: [U-Boot] [PATCH 1/3] power: regulator: s2mps11: add a regulator driver for s2mps11

On 15 January 2018 at 22:33, Jaehoon Chung wrote: > exynos5422 has the s2mps11 PMIC. > s2mps11 pmic has the 10-BUCK and 38-LDO regulators. > Each IP and devices in exynos5422 can be controlled by each regulators. > This patch is support for s2mps11 regulator driver. > >

Re: [U-Boot] [PATCH 1/3] ARM: dts: stm32: Add STMMAC clocks for stm32f746

Hi, On 01/17/2018 12:46 AM, patrice.chot...@st.com wrote: > From: Patrice Chotard > > Add ETHMAC, ETHMACRX and ETHMACTX clocks for STMMAC. > > Signed-off-by: Patrice Chotard Reviewed-by: Vikas Manocha Cheers, Vikas >

Re: [U-Boot] [PATCH v2 5/7] rpi: Properly detect which serial device is active

Hi Alex, On 17 January 2018 at 00:54, Alexander Graf wrote: > Now that we have all infrastructure in place to dynamically determine whether > a serial device is actually usable (read: routed to user accessible pins), we > can wire it up to the board. > > This patch adds support to

Re: [U-Boot] [PATCH v2 7/7] rpi: Force skip_init on serial devices

Hi Alex, On 17 January 2018 at 00:54, Alexander Graf wrote: > The serial devices on the raspberry pi are based on clocks we can't easily > read and influence in U-Boot. However, the serial devices are always already > properly set up when coming up, so all we need to do is leave

Re: [U-Boot] [PATCH v2 2/7] serial: Allow boards to determine whether a serial device is usable

Hi Alex, On 17 January 2018 at 00:54, Alexander Graf wrote: > On some boards, serial devices may or may not be muxed properly to actual > pins, depending on firmware configuration. To determine whether we should > use a serial device for U-Boot in-/output, we need to check whether

Re: [U-Boot] [PATCH v2 1/7] serial: Use next serial device if probing fails

On 17 January 2018 at 00:54, Alexander Graf wrote: > Currently our serial device search chokes on the fact that the serial > probe function could fail. If it does, instead of searching for the next > usable serial device, it just quits. > > This patch changes the fallback logic so

[U-Boot] [PATCH v2 15/18] tools: provide a tool to convert a binary file to an include

For testing EFI disk management we need an in-memory image of a disk. The tool file2include converts a file to a C include. The file is separated into strings of 8 bytes. Only the non-zero strings are written to the include. The output format has been designed to maintain readability. #define

[U-Boot] [PATCH v2 12/18] efi_loader: correct EFI_BLOCK_IO_PROTOCOL definitions

Add the revision constants. Depending on the revision additional fields are needed in the media descriptor. Use efi_uintn_t for number of bytes to read or write. Signed-off-by: Heinrich Schuchardt --- v2 no change --- include/efi_api.h | 10 --

[U-Boot] [PATCH v2 09/18] efi_loader: make efi_block_io_guid a global symbol

The GUID of the EFI_BLOCK_IO_PROTOCOL is needed in different code parts. To avoid duplication make efi_block_io_guid a global symbol. Signed-off-by: Heinrich Schuchardt --- v2 no change --- include/efi_loader.h | 2 ++ lib/efi_loader/efi_disk.c | 2 +- 2 files

[U-Boot] [PATCH v2 10/18] efi_loader: provide a function to create a partition node

Provide new function efi_dp_part_node() to create a device node for a partition. Signed-off-by: Heinrich Schuchardt --- v2 no change --- include/efi_loader.h | 2 + lib/efi_loader/efi_device_path.c | 106 ++- 2 files

[U-Boot] [PATCH v2 16/18] efi_driver: EFI block driver

This patch provides * a uclass for EFI drivers * a EFI driver for block devices For each EFI driver the uclass * creates a handle * adds the driver binding protocol The uclass provides the bind, start, and stop entry points for the driver binding protocol. In bind() and stop() it checks if the

[U-Boot] [PATCH v2 18/18] efi_loader: fix ExitBootServices

This patch lets the implementation of ExitBootServices conform to the UEFI standard. The timer events must be disabled before calling the notification functions of the exit boot services events. The boot services must be disabled in the system table. The handles in the system table should be

[U-Boot] [PATCH v2 17/18] efi_selftest: provide a test for block io

Signed-off-by: Heinrich Schuchardt --- v2 no change --- lib/efi_selftest/Makefile| 4 + lib/efi_selftest/efi_selftest_block_device.c | 395 +++ lib/efi_selftest/efi_selftest_disk_image.h | 69 + 3 files changed, 468

[U-Boot] [PATCH v2 14/18] efi_loader: provide links between devices EFI handles

U-Boot devices and EFI handles can be related, e.g. an IDE disk relates to a handle with the EFI_BLOCK_IO_PROTOCOL. Provide pointers to store these links. Signed-off-by: Heinrich Schuchardt --- v2 no change --- include/dm/device.h | 4

[U-Boot] [PATCH v2 06/18] efi_loader: check tables in helloworld.efi

Check if the device tree and the SMBIOS table are available. Signed-off-by: Heinrich Schuchardt --- v2 no change --- lib/efi_loader/helloworld.c | 26 ++ 1 file changed, 26 insertions(+) diff --git a/lib/efi_loader/helloworld.c

[U-Boot] [PATCH v2 08/18] efi_loader: efi_disk_register: correctly determine if_type_name

The interface type name can be used to look up the interface type. Don't confound it with the driver name which may be different. Signed-off-by: Heinrich Schuchardt --- v2 no change --- lib/efi_loader/efi_disk.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)

[U-Boot] [PATCH v2 07/18] efi_loader: fix StartImage bootservice

The calling convention for the entry point of an EFI image is always 'asmlinkage'. Signed-off-by: Heinrich Schuchardt --- v2 no change --- lib/efi_loader/efi_boottime.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git

[U-Boot] [PATCH v2 11/18] efi_loader: make efi_disk_create_partitions a global symbol

Up to now we have been using efi_disk_create_partitions() to create partions for block device that existed before starting an EFI application. We need to to call it for for block devices created by EFI applications at run time. The EFI application will define the handle for the block device and

[U-Boot] [PATCH v2 04/18] efi_loader: print device path when entering efi_load_image

Use %pD to print the device path instead of its address when entering efi_load_image. Signed-off-by: Heinrich Schuchardt --- v2 no change --- lib/efi_loader/efi_boottime.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

[U-Boot] [PATCH v2 03/18] efi_loader: correct find simple file system protocol

In contrast to the description the code did not split the device path into device part and file part. The code should use the installed protocol and not refer to the internal structure of the the disk object. Signed-off-by: Heinrich Schuchardt --- v2 no change ---

[U-Boot] [PATCH v2 05/18] efi_loader: allocate correct memory type for EFI image

The category of memory allocated for an EFI image should depend on its type (application, bootime service driver, runtime service driver). Our helloworld.efi built on arm64 has an illegal image type. Treat it like an EFI application. Signed-off-by: Heinrich Schuchardt --- v2

[U-Boot] [PATCH v2 13/18] efi_loader: provide function to get last node of a device path

On a block device and its partions the same protocols can be installed. To tell the apart we can use the type of the last node of the device path which is not the end node. The patch provides a utility function to find this last node. Signed-off-by: Heinrich Schuchardt ---

[U-Boot] [PATCH v2 02/18] efi_loader: address of the simple file system protocol

When installing the the simple file system protocol we have to path the address of the structure and not the address of a pointer ot the structure. Signed-off-by: Heinrich Schuchardt --- v2 no change --- lib/efi_loader/efi_disk.c | 2 +- 1 file changed, 1

[U-Boot] [PATCH v2 00/18] efi_loader: enable EFI driver provided block device

With this patch series an EFI application or driver can supply a block device which in turn can be used to download an image. E.g. we can load iPXE, connect iSCSI drives, download grub from the SAN and afterwards with grub download and run an EFI application. Booting Linux from an iSCSI drive was

[U-Boot] [PATCH v2 01/18] efi_loader: return NULL from device path functions

For the construction of device paths we need to call the AllocatePool service. We should not ignore if it fails due to an out of memory situation. This patch changes the device path functions to return NULL if the memory allocation fails. Additional patches will be needed to fix the callers.

Re: [U-Boot] Pull request: u-boot-net.git master

Hi Tom, On Mon, Jan 15, 2018 at 8:25 PM, Tom Rini wrote: > On Mon, Jan 15, 2018 at 12:06:17PM -0600, Joe Hershberger wrote: > >> Hi Tom, >> >> The following changes since commit 3dde8f20377c3a051dda64497bdf0cdb23e03a2d: >> >> Merge git://git.denx.de/u-boot-mmc (2018-01-14

[U-Boot] Please pull u-boot-fsl-qoriq master

Tom, The following changes since commit 3dde8f20377c3a051dda64497bdf0cdb23e03a2d: Merge git://git.denx.de/u-boot-mmc (2018-01-14 22:26:38 -0500) are available in the git repository at: git://git.denx.de/u-boot-fsl-qoriq.git for you to fetch changes up to

[U-Boot] [BUG] x86: Could not get phandle node for /gpios@0:num-gpios(cell 0)

When running the Travis test suite for master I see warnings arch/sandbox/dts/sandbox.dtb: Warning (gpios_property): Could not get phandle node for /gpios@0:num-gpios(cell 0) (https://travis-ci.org/xypron2/u-boot/jobs/329755777) The warning is created by check_gpios_property() in

Re: [U-Boot] [U-Boot, v4, 07/11] spl: add support to booting with OP-TEE

On 15/01/18 04:48, Peng Fan wrote: On Mon, Jan 15, 2018 at 11:25:00AM +0800, Kever Yang wrote: Bryan, On 01/12/2018 11:10 PM, Bryan O'Donoghue wrote: On 12/01/18 11:27, Philipp Tomsich wrote: OP-TEE is an open source trusted OS, in armv7, its loading and running are like this: loading:

Re: [U-Boot] [PATCH] ubi: Fix filesystem corruption on detach when fastmap enabled

Martin, Am Dienstag, 16. Januar 2018, 15:13:04 CET schrieb Martin Townsend: > > Martin, can you please explain what corruption you see? > > From reading the code I'd assume that you miss volumes but a full scan > > would recover everything. > > I didn't do much analysis of the corruption I'm

Re: [U-Boot] [PATCH v4 0/6] Support for the Turris Omnia router

Hi Marek and Stefan, Am 09.06.2017 um 19:28 schrieb Marek Behún: > This is the fourth version of patches for adding support for the > Turris Omnia board, a router developed by the CZ.NIC. I'm still facing trouble testing turris_omnia on latest v2018.01. First, that made me notice there's no

Re: [U-Boot] [PATCH V5 00/31] imx: add i.MX8M support and i.MX8MQ EVK

Hi Peng, 2018-01-16 10:25 GMT-02:00 Peng Fan : > > >> -Original Message- >> From: Diego Dorta [mailto:diegohdo...@gmail.com] >> Sent: Tuesday, January 16, 2018 8:15 PM >> To: Peng Fan >> Cc: Peng Fan ; Fabio Estevam >>

Re: [U-Boot] [PATCH] mmc: fix the wrong dislabing clock

On 17/01/2018 11:56, Jaehoon Chung wrote: Hi, On 01/17/2018 07:36 PM, Jaehoon Chung wrote: When power is off, clock is not disabling. Because it's passed to 1, mmc->clock should be set to f_min value. Some drivers can't initialize the eMMC/SD card with current status. This patch is to fix

[U-Boot] [PATCH 4/5] zynq: board: Remove checkboard

Now that showing silicon version is part of the CPU info display, let's remove checkboard(). Note that the generic show_board_info() will still show the DT 'model' property. For instance: U-Boot 2018.01-00172-g5e296ab7317a (Jan 17 2018 - 09:57:36 -0300) CPU: Zynq 7z010 Silicon: v3.1

[U-Boot] [PATCH 3/5] zynq: Support CPU info display

This commit adds CPU and silicon version information consuming the SLCR IDCODE and DEVCFG MCTRL registers, respectively. Signed-off-by: Ariel D'Alessandro Signed-off-by: Ezequiel Garcia --- arch/arm/mach-zynq/cpu.c | 46

[U-Boot] [PATCH 5/5] configs: zynq: Enable DISPLAY_CPUINFO

Now that silicon version has been moved from checkboard() to print_cpuinfo(), we need to enable DISPLAY_CPUINFO option. Signed-off-by: Ezequiel Garcia --- configs/syzygy_hub_defconfig | 1 - configs/topic_miami_defconfig | 1 -

[U-Boot] [PATCH 2/5] zynq: Rework FPGA initialization

This commit moves the FPGA descriptor definition to mach-zynq, where it makes more sense. Also, the implementation is reworked to be cleaner and a bit smaller. add/remove: 2/11 grow/shrink: 0/1 up/down: 420/-608 (-188) function old new delta

[U-Boot] [PATCH 1/5] zynq: Define macros for the device names

This will allow to reuse the macros when showing the CPU info. Signed-off-by: Ezequiel Garcia --- include/zynqpl.h | 32 ++-- 1 file changed, 22 insertions(+), 10 deletions(-) diff --git a/include/zynqpl.h b/include/zynqpl.h index

[U-Boot] [PATCH 0/5] zynq: Fun with board and CPU info display

This series aims at adding support for CPU information display. While here, following suggestions from Michal, the FPGA initialization is cleaned up. Ezequiel Garcia (5): zynq: Define macros for the device names zynq: Rework FPGA initialization zynq: Support CPU info display zynq: board:

Re: [U-Boot] QSPI "sf probe ...", "sf read ..." on Altera SoC FPGA

i checked, and if you mean these patches: https://patchwork.ozlabs.org/patch/765992/ https://patchwork.ozlabs.org/patch/765996/ https://patchwork.ozlabs.org/patch/765997/ https://patchwork.ozlabs.org/patch/765998/ i already applied them, and they didn't work as well. i also found these patches

Re: [U-Boot] QSPI "sf probe ...", "sf read ..." on Altera SoC FPGA

On 01/17/2018 02:06 PM, Simon Goldschmidt wrote: > On 17.01.2018 14:01, RB23 wrote: >> hey, i downloaded the september and november versions and i applied >> the patches on both of them, re-compiled the u boot, >> and still, it gives me the same error when trying the command "sf probe" >> i'm not

Re: [U-Boot] [PATCH v2 00/15] env: Multiple env support and env transition for sunxi

On Wed, Jan 17, 2018 at 08:01:34AM -0500, Tom Rini wrote: > On Wed, Jan 17, 2018 at 09:58:53AM +0100, Maxime Ripard wrote: > > Hi, > > > > On Tue, Jan 16, 2018 at 04:56:49PM -0500, Tom Rini wrote: > > > On Tue, Jan 16, 2018 at 10:16:36AM +0100, Maxime Ripard wrote: > > > > Hi, > > > > > > > >

Re: [U-Boot] QSPI "sf probe ...", "sf read ..." on Altera SoC FPGA

On 17.01.2018 14:01, RB23 wrote: hey, i downloaded the september and november versions and i applied the patches on both of them, re-compiled the u boot, and still, it gives me the same error when trying the command "sf probe" i'm not sure what to do, is it possible that i missed something?

Re: [U-Boot] [PATCH v2 00/15] env: Multiple env support and env transition for sunxi

On Wed, Jan 17, 2018 at 09:58:53AM +0100, Maxime Ripard wrote: > Hi, > > On Tue, Jan 16, 2018 at 04:56:49PM -0500, Tom Rini wrote: > > On Tue, Jan 16, 2018 at 10:16:36AM +0100, Maxime Ripard wrote: > > > Hi, > > > > > > Here is a second attempt at transitioning away from the MMC raw > > >

Re: [U-Boot] QSPI "sf probe ...", "sf read ..." on Altera SoC FPGA

hey, i downloaded the september and november versions and i applied the patches on both of them, re-compiled the u boot, and still, it gives me the same error when trying the command "sf probe" i'm not sure what to do, is it possible that i missed something? like a define or something in the make

Re: [U-Boot] [PATCH] configs: keystone2: env: Fix burn_uboot_spi command

On Wed, Jan 17, 2018 at 01:08:19PM +0530, Faiz Abbas wrote: > Hi, > > +Vignesh > > On Tuesday 16 January 2018 08:55 PM, Tom Rini wrote: > > On Tue, Jan 16, 2018 at 01:43:40PM +0530, Faiz Abbas wrote: > >> Now the u-boot spi image is greater than 0x9, increase the same in > >> env during spi

Re: [U-Boot] [PATCH V5 29/31] power: pmic/regulator allow dm be omitted by SPL

On 01/10/2018 02:20 PM, Peng Fan wrote: > Allow the dm driver be omitted by SPL. > > Signed-off-by: Peng Fan > Reviewed-by: Simon Glass > Cc: Jaehoon Chung > Cc: Stefano Babic Sorry, i add the reviewed-by tag at

  1   2   >