Re: [RFC PATCH 0/7] spl: Use common function for loading/parsing images

On 4/1/22 21:03, Sean Anderson wrote: This series adds support for loading all image types (Legacy, FIT (with and without LOAD_FIT_FULL), and i.MX) to the MMC, SPI, NOR, NET, FAT, and EXT load methods. It does this by introducing a helper function which handles the minutiae of invoking the

[RFC PATCH 0/7] spl: Use common function for loading/parsing images

This series adds support for loading all image types (Legacy, FIT (with and without LOAD_FIT_FULL), and i.MX) to the MMC, SPI, NOR, NET, FAT, and EXT load methods. It does this by introducing a helper function which handles the minutiae of invoking the proper parsing function, and reading the rest

Re: [RFC PATCH 0/7]

On Fri, 4 Sep 2020 at 14:25, Ard Biesheuvel wrote: > > On Fri, 4 Sep 2020 at 13:51, Patrick Delaunay wrote: > > > > arm: cache: cp15: don't map reserved region with no-map property > > > > Hi, > > > > On STM32MP15x platform we can use OP-TEE, loaded in DDR in a region > > protected > > by a

Re: [RFC PATCH 0/7]

On Fri, 4 Sep 2020 at 13:51, Patrick Delaunay wrote: > > arm: cache: cp15: don't map reserved region with no-map property > > Hi, > > On STM32MP15x platform we can use OP-TEE, loaded in DDR in a region protected > by a firewall. This region is reserved in device with "no-map" property. > > But

[RFC PATCH 0/7]

arm: cache: cp15: don't map reserved region with no-map property Hi, On STM32MP15x platform we can use OP-TEE, loaded in DDR in a region protected by a firewall. This region is reserved in device with "no-map" property. But sometime the platform boot failed in U-boot on a Cortex A7 access to

[U-Boot] [RFC PATCH 0/7] FPGA changes

Patches 1-3,5-6 are moving existing options to Kconfig. I haven't touched all the boards that use these options so they are still present in the whitelist. Hopefully someone more familiar with the zynq boards can build on top of these. Patches 4 and 7 are the functional changes I actually want to

Re: [U-Boot] [RFC PATCH 0/7] "Transient" (= export-restricted) environment vars

Hi Bernhard, On Mon, Jul 11, 2016 at 1:14 PM, Bernhard Nortmann wrote: > This series evolved around the idea of introducing a new env_op > type to control (and possibly restrict) the export of variables. > This is especially useful if one wants to prevent dynamic >

[U-Boot] [RFC PATCH 0/7] "Transient" (= export-restricted) environment vars

This series evolved around the idea of introducing a new env_op type to control (and possibly restrict) the export of variables. This is especially useful if one wants to prevent dynamic configuration information from ending up in a saved environment - the 'classic' example being network setup

[U-Boot] [RFC PATCH 0/7] DM: pinctrl: Another implemtation of pinctrl framework

I'd like to propose antoher pinctrl design, which is closer to Linux's one. 1/7 adds the uclass support. 2/7 - 5/7 show how low-level drivers can be implemeted on my SoCs as example. You can implement them in your own way, but they are often done with architecture-specific operation +

Re: [U-Boot] [RFC PATCH 0/7] RFC: dm: Add USB support

Hi Simon, On Sat, Jan 31, 2015 at 12:34 AM, Simon Glass s...@chromium.org wrote: This series adds basic driver model support to USB. The intent is to permit the various subsystems (OHCI, EHCI, XHCI) to co-exist and allow any number of USB ports of different types. So far the absolute limit on

Re: [U-Boot] [RFC PATCH 0/7] RFC: dm: Add USB support

On Tuesday, February 10, 2015 at 06:28:30 AM, Simon Glass wrote: Hi Marek, Hi! [...] Hi! I'll look at this by the end of next week, I will be free by then. It's not possible for me to do it earlier, sorry. Does this still work for you please? Definitely, that sounds good.

Re: [U-Boot] [RFC PATCH 0/7] RFC: dm: Add USB support

Hi Marek, On 9 February 2015 at 14:02, Marek Vasut ma...@denx.de wrote: On Friday, January 30, 2015 at 11:41:33 PM, Simon Glass wrote: Hi Marek, Hi! On 30 January 2015 at 15:16, Marek Vasut ma...@denx.de wrote: On Friday, January 30, 2015 at 08:04:50 PM, Simon Glass wrote: This series

Re: [U-Boot] [RFC PATCH 0/7] RFC: dm: Add USB support

On Friday, January 30, 2015 at 11:41:33 PM, Simon Glass wrote: Hi Marek, Hi! On 30 January 2015 at 15:16, Marek Vasut ma...@denx.de wrote: On Friday, January 30, 2015 at 08:04:50 PM, Simon Glass wrote: This series adds basic driver model support to USB. The intent is to permit the

[U-Boot] [RFC PATCH 0/7] RFC: dm: Add USB support

This series adds basic driver model support to USB. The intent is to permit the various subsystems (OHCI, EHCI, XHCI) to co-exist and allow any number of USB ports of different types. So far the absolute limit on the number of USB devices is only slightly relaxed. Only USB controllers have a real

Re: [U-Boot] [RFC PATCH 0/7] RFC: dm: Add USB support

Hi Marek, On 30 January 2015 at 15:16, Marek Vasut ma...@denx.de wrote: On Friday, January 30, 2015 at 08:04:50 PM, Simon Glass wrote: This series adds basic driver model support to USB. The intent is to permit the various subsystems (OHCI, EHCI, XHCI) to co-exist and allow any number of

Re: [U-Boot] [RFC PATCH 0/7] RFC: dm: Add USB support

On Friday, January 30, 2015 at 08:04:50 PM, Simon Glass wrote: This series adds basic driver model support to USB. The intent is to permit the various subsystems (OHCI, EHCI, XHCI) to co-exist and allow any number of USB ports of different types. So far the absolute limit on the number of USB

[U-Boot] [RFC PATCH 0/7] Add Driver Model support to network stack

For now this simply addresses the MAC part of the network hardware. The next part to implement is the PHY children. I wanted to get early feedback on what I have so far to make sure I'm going in the direction that Simon envisioned. Joe Hershberger (7): net: Provide a function to get the

Re: [U-Boot] [RFC PATCH 0/7] Add Driver Model support to network stack

Hi Joe, On 27 January 2015 at 16:27, Joe Hershberger joe.hershber...@ni.com wrote: For now this simply addresses the MAC part of the network hardware. The next part to implement is the PHY children. I wanted to get early feedback on what I have so far to make sure I'm going in the direction

[U-Boot] [RFC PATCH 0/7] Switch am335x_evm.h based boards to use config_distro_bootcmd.

In order to not change behavior significantly, several changes to config_distro_bootcmd were added to make it more flexible, and am335x_evm.h was adapted to make use of them: - Allow multiple partitions per device, rather than only searching on partition 1. Make the number of partitions

Re: [U-Boot] [RFC][PATCH 0/7] TI: OMAP3: Use common config file.

Hi Tom, 2014/1/6 Tom Rini tr...@ti.com: On Mon, Dec 23, 2013 at 12:11:25PM +0100, Enric Balletbo Serra wrote: 2013/12/6 Enric Balletbo i Serra eballe...@gmail.com: Hi all, Most of the boards based on TI processors uses common configuration files (ti_armv7_common.h,

Re: [U-Boot] [RFC][PATCH 0/7] TI: OMAP3: Use common config file.

On Fri, Jan 24, 2014 at 09:45:36AM +0100, Enric Balletbo Serra wrote: Hi Tom, 2014/1/6 Tom Rini tr...@ti.com: On Mon, Dec 23, 2013 at 12:11:25PM +0100, Enric Balletbo Serra wrote: 2013/12/6 Enric Balletbo i Serra eballe...@gmail.com: Hi all, Most of the boards based on TI

Re: [U-Boot] [RFC][PATCH 0/7] TI: OMAP3: Use common config file.

Hi Tom, 2014/1/24 Tom Rini tr...@ti.com: On Fri, Jan 24, 2014 at 09:45:36AM +0100, Enric Balletbo Serra wrote: Hi Tom, 2014/1/6 Tom Rini tr...@ti.com: On Mon, Dec 23, 2013 at 12:11:25PM +0100, Enric Balletbo Serra wrote: 2013/12/6 Enric Balletbo i Serra eballe...@gmail.com: Hi all,

Re: [U-Boot] [RFC][PATCH 0/7] TI: OMAP3: Use common config file.

On Mon, Dec 23, 2013 at 12:11:25PM +0100, Enric Balletbo Serra wrote: 2013/12/6 Enric Balletbo i Serra eballe...@gmail.com: Hi all, Most of the boards based on TI processors uses common configuration files (ti_armv7_common.h, ti_processor_common.h) to avoid duplication of code. This is

Re: [U-Boot] [RFC][PATCH 0/7] TI: OMAP3: Use common config file.

2013/12/6 Enric Balletbo i Serra eballe...@gmail.com: Hi all, Most of the boards based on TI processors uses common configuration files (ti_armv7_common.h, ti_processor_common.h) to avoid duplication of code. This is right except for OMAP3-based boards. In order to use the same schema as

[U-Boot] [RFC][PATCH 0/7] TI: OMAP3: Use common config file.

Hi all, Most of the boards based on TI processors uses common configuration files (ti_armv7_common.h, ti_processor_common.h) to avoid duplication of code. This is right except for OMAP3-based boards. In order to use the same schema as used on am33xx, omap4, omap5 and dra7 TI processors these

[U-Boot] [RFC PATCH 0/7] arm: atmel: sama5d3: enable spl boot from SD card

This patch series enable spl boot from SD card, it only can boot u-boot itself. Bo Shen (7): arm: atmel: sama5d3: early enable PIO peripherals arm: atmel: sama5d3: correct the ID for DBGU and PIT arm: atmel: the offset of MULA is 18 in sama5d3 arm: atmel: sama5: correct the error define

[U-Boot] [RFC PATCH 0/7] RFC: Add Kbuild system to U-Boot

Kbuild in U-Boot has been talked about for a while and I know of at least one functioning attempt and mentions of independent progress. But I don't see any patches on the mailing list and various people have suggested that nothing is far advanced yet, so I decided to take a look. For this effort,

Re: [U-Boot] [RFC PATCH 0/7] reboard: Introduce generic relocation feature

Hi Albert, On Wed, Dec 7, 2011 at 12:10 AM, Albert ARIBAUD albert.u.b...@aribaud.net wrote: Hi Simon, Le 22/11/2011 00:57, Simon Glass a écrit : This is the second patch series aiming to unify the various board.c files in each architecture into a single one. This series creates a libboard

Re: [U-Boot] [RFC PATCH 0/7] reboard: Introduce generic relocation feature

Hi Simon, Le 22/11/2011 00:57, Simon Glass a écrit : This is the second patch series aiming to unify the various board.c files in each architecture into a single one. This series creates a libboard library and implements relocation in it. It then moves ARM over to use this framework, as an

Re: [U-Boot] [RFC PATCH 0/7] reboard: Introduce generic relocation feature

Hi Tomi, On Mon, Nov 28, 2011 at 3:45 PM, Tom Rini tom.r...@gmail.com wrote: On Mon, Nov 21, 2011 at 4:57 PM, Simon Glass s...@chromium.org wrote: This is the second patch series aiming to unify the various board.c files in each architecture into a single one. This series creates a libboard

Re: [U-Boot] [RFC PATCH 0/7] reboard: Introduce generic relocation feature

Hi Tom, On Mon, Nov 28, 2011 at 3:45 PM, Tom Rini tom.r...@gmail.com wrote: On Mon, Nov 21, 2011 at 4:57 PM, Simon Glass s...@chromium.org wrote: This is the second patch series aiming to unify the various board.c files in each architecture into a single one. This series creates a libboard

Re: [U-Boot] [RFC PATCH 0/7] reboard: Introduce generic relocation feature

Hi Simon Sorry for the late review on this - I've only just now had a good chance to look at it... On Wed, Dec 7, 2011 at 12:56 PM, Simon Glass s...@chromium.org wrote: Hi Tom, On Mon, Nov 28, 2011 at 3:45 PM, Tom Rini tom.r...@gmail.com wrote: On Mon, Nov 21, 2011 at 4:57 PM, Simon Glass

Re: [U-Boot] [RFC PATCH 0/7] reboard: Introduce generic relocation feature

Hi Graeme, On Tue, Dec 6, 2011 at 6:56 PM, Graeme Russ graeme.r...@gmail.com wrote: Hi Simon Sorry for the late review on this - I've only just now had a good chance to look at it... Thanks for the comments. On Wed, Dec 7, 2011 at 12:56 PM, Simon Glass s...@chromium.org wrote: Hi Tom,

Re: [U-Boot] [RFC PATCH 0/7] reboard: Introduce generic relocation feature

Hi Simon, On Wed, Dec 7, 2011 at 2:25 PM, Simon Glass s...@chromium.org wrote: Hi Graeme, On Tue, Dec 6, 2011 at 6:56 PM, Graeme Russ graeme.r...@gmail.com wrote: Hi Simon Sorry for the late review on this - I've only just now had a good chance to look at it... Thanks for the comments.

Re: [U-Boot] [RFC PATCH 0/7] reboard: Introduce generic relocation feature

On Mon, Nov 21, 2011 at 4:57 PM, Simon Glass s...@chromium.org wrote: This is the second patch series aiming to unify the various board.c files in each architecture into a single one. This series creates a libboard library and implements relocation in it. It then moves ARM over to use this

[U-Boot] [RFC PATCH 0/7] reboard: Introduce generic relocation feature

This is the second patch series aiming to unify the various board.c files in each architecture into a single one. This series creates a libboard library and implements relocation in it. It then moves ARM over to use this framework, as an example. On ARM the relocation code is duplicated for each

Re: [U-Boot] [RFC PATCH 0/7] spl framework prototype

Dear Wolfgang, Would you please let us know your thoughts on this prototype implementation? best regards, Aneesh On Wednesday 29 June 2011 06:39 PM, Aneesh V wrote: This is an extention of Daniel Schwierzeck's work [1] on a new SPL framework and is intented only as a prototype to facilitate

[U-Boot] [RFC PATCH 0/7] spl framework prototype

This is an extention of Daniel Schwierzeck's work [1] on a new SPL framework and is intented only as a prototype to facilitate further discussion. Please refer [2] for an overview of this approach: I have extended his work to make it a little more generic, did some minor modifications and