On Tue, Jan 29, 2019 at 12:46 PM Lukasz Majewski wrote:
>
> Hi Stefano, Fabio,
>
> > Hi Lukasz,
> >
> > On 21/01/19 15:19, Lukasz Majewski wrote:
> > > Hi Fabio,
> > >
> > >> Hi Lukasz,
> > >>
> > >> On Sat, Jan 19, 2019 at 7:15 AM Lukasz Majewski
> > >> wrote:
> > >>> +static ulong
Hi Stefano, Fabio,
> Hi Lukasz,
>
> On 21/01/19 15:19, Lukasz Majewski wrote:
> > Hi Fabio,
> >
> >> Hi Lukasz,
> >>
> >> On Sat, Jan 19, 2019 at 7:15 AM Lukasz Majewski
> >> wrote:
> >>> +static ulong imx6q_clk_get_rate(struct clk *clk)
> >>> +{
> >>> + ulong rate = 0;
> >>> +
> >>>
From: Grygorii Strashko
The Ring Accelerator (RINGACC or RA) provides hardware acceleration to
enable straightforward passing of work between a producer and a consumer.
There is one RINGACC module per NAVSS on TI AM65x SoCs.
The RINGACC converts constant-address read and write accesses to
From: Grygorii Strashko
Add TI Communications Port Programming Interface (CPPI) 5
interface description and helpers
Signed-off-by: Grygorii Strashko
Signed-off-by: Vignesh R
---
include/linux/soc/ti/cppi5.h | 995 +++
1 file changed, 995 insertions(+)
create
Merge drivers/soc/keystone/ into drivers/soc/ti/
and convert CONFIG_TI_KEYSTONE_SERDES into Kconfig.
Signed-off-by: Vignesh R
---
arch/arm/mach-keystone/Kconfig | 8
drivers/soc/Makefile | 1 -
drivers/soc/keystone/Makefile | 3
From: Grygorii Strashko
Add DT node for MCU NAVSS its components to get DMA working on AM654
SoC.
Signed-off-by: Grygorii Strashko
Signed-off-by: Vignesh R
---
arch/arm/dts/k3-am654-base-board-u-boot.dtsi | 46
1 file changed, 46 insertions(+)
diff --git
From: Grygorii Strashko
Texas Instruments' System Control Interface (TI-SCI) Message Protocol
abstracts management of NAVSS resources, like PSI-L pairing and
unpairing, UDMAP tx/rx/flow configuration and Rings.
This patch adds support for requesting and configuring such resources
from TI-SCI
This series adds DMA support for TI's AM654 SoC.
v3:
Minor comment/whitespace cleanups as pointed out by Tom Rini
v2:
Align DT bindings with latest proposed bindings as pointed out by Peter.
Merge drivers/soc/keystone into drivers/soc/ti
Background:
The AM65x TRM
From: Grygorii Strashko
Enable TI K3 AM65x PSI-L, Ring Accelerator and UDMA drivers
Signed-off-by: Grygorii Strashko
Signed-off-by: Vignesh R
---
configs/am65x_evm_a53_defconfig | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/configs/am65x_evm_a53_defconfig
Add a tiny SPI flash stack that just supports reading data/images from
SPI flash. This is useful for boards that have SPL size constraints and
would need to use SPI flash framework just to read images/data from
flash. There is approximately 1.5 to 2KB savings with this.
Based on prior work of
The UDMA-P is intended to perform similar (but significantly upgraded) functions
as the packet-oriented DMA used on previous SoC devices. The UDMA-P module
supports the transmission and reception of various packet types.
The UDMA-P also supports acting as both a UTC and UDMA-C for its internal
SF_DUAL_FLASH claims to enable support for SF_DUAL_STACKED_FLASH and
SF_DUAL_PARALLEL_FLASH. But, in current U-Boot code, grepping for above
enums yield no user and therefore support seems to be incomplete. Remove
these configs so as to avoid confusion.
Signed-off-by: Vignesh R
---
Linux uses "jedec,spi-nor" as compatible string for JEDEC compatible
SPI Flash device nodes. Therefore make U-Boot also to look for the same
compatible string so that we can use Linux DTS files as is.
Signed-off-by: Vignesh R
Tested-by: Simon Goldschmidt
Tested-by: Stefan Roese
Tested-by:
Now that new SPI NOR layer uses stateless 4 byte opcodes by default,
don't enable SPI_FLASH_BAR. For SPI controllers that cannot support
4-byte addressing, (stm32_qspi.c, fsl_qspi.c, mtk_qspi.c, ich.c,
renesas_rpc_spi.c) add an imply clause to enable SPI_FLASH_BAR so as to
not break functionality.
For legacy reasons, we will have to keep around U-Boot specific
SPI_FLASH_BAR and SPI_TX_BYTE. Add them back to the new framework
Signed-off-by: Vignesh R
---
drivers/mtd/spi/spi-nor-core.c | 162 -
include/linux/mtd/spi-nor.h| 9 ++
2 files changed, 168
Add myself as co-maintainer for U-Boot SPI NOR subsystem.
Signed-off-by: Vignesh R
---
MAINTAINERS | 9 +
1 file changed, 9 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 33f1127e50a4..e06089133731 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -668,6 +668,15 @@ F:
spi_flash and spi_flash_ids are no longer needed after SPI NOR
migration. Remove them.
Signed-off-by: Vignesh R
Tested-by: Simon Goldschmidt
Tested-by: Stefan Roese
Tested-by: Horatiu Vultur
---
drivers/mtd/spi/spi_flash.c | 1337 ---
SPL only needs to be able to read from SPI Flash to load next stage and
does not really need write/erase etc. Therefore in order to reduce SPI
Flash code size in SPL, enable SPI_FLASH_TINY, that only supports
reading from SPI flash, as default.
Note: Since, SPI_FLASH_TINY does not support
Switch spi_flash_* interfaces to call into new SPI NOR framework via MTD
layer. Fix up sf_dataflash to work in legacy way. And update sandbox to
use new interfaces/definitions
Signed-off-by: Vignesh R
Tested-by: Simon Goldschmidt
Tested-by: Stefan Roese
Tested-by: Horatiu Vultur
---
Sync Serial Flash Discoverable Parameters (SFDP) parsing support from
Linux. This allows auto detection and configuration of Flash parameters.
Signed-off-by: Vignesh R
Tested-by: Simon Goldschmidt
Tested-by: Stefan Roese
Tested-by: Horatiu Vultur
---
common/spl/Kconfig | 13 +-
Current U-Boot SPI NOR support (sf layer) is quite outdated as it does not
support 4 byte addressing opcodes, SFDP table parsing and different types of
quad mode enable sequences. Many newer flashes no longer support BANK
registers used by sf layer to a access >16MB of flash address space.
So,
> Le 28 janv. 2019 à 07:53, Jun Nie a écrit :
>
> Joris Offouga 于2019年1月25日周五 下午8:27写道：
>>
>>
Le 25/01/2019 à 02:19, Jun Nie a écrit :
Joris Offouga 于2019年1月24日周四 下午9:07写道：
>> Le 24/01/2019 à 13:54, Jun Nie a écrit :
>> Joris Offouga 于2019年1月24日周四 下午6:30写道：
>>
Add non DM version of SPI_MEM to support easy migration to new SPI NOR
framework. This can be removed once DM_SPI conversion is complete.
Signed-off-by: Vignesh R
Tested-by: Simon Goldschmidt
Tested-by: Stefan Roese
Tested-by: Horatiu Vultur
---
drivers/spi/Kconfig| 4 +-
Extend spi_mem_adjust_op_size() to take spi->max_write_size and
spi->max_read_size into account.
Signed-off-by: Vignesh R
Tested-by: Simon Goldschmidt
Tested-by: Stefan Roese
Tested-by: Horatiu Vultur
---
drivers/spi/spi-mem.c | 19 +++
1 file changed, 19 insertions(+)
diff
Many SPI controllers have special MMIO interfaces which provide
accelerated read/write access but require knowledge of flash parameters
to make use of it. Recent spi-mem layer provides a way to support such
controllers.
Therefore, add spi-mem support to spi-nor-core as a way to support SPI
Add hweight*() macros required for moving to new SF layer
Signed-off-by: Vignesh R
---
arch/sh/include/asm/bitops.h | 4
1 file changed, 4 insertions(+)
diff --git a/arch/sh/include/asm/bitops.h b/arch/sh/include/asm/bitops.h
index 8cb8385d76db..765f28f116bc 100644
---
It is necessary to call spi_claim_bus() before starting any SPI
transactions and this restriction would also apply when calling spi-mem
operations. Therefore claim and release bus before requesting transfer
via exec_op.
Signed-off-by: Vignesh R
Tested-by: Simon Goldschmidt
Tested-by: Stefan
Sync changes from Linux SPI NOR framework to add 4 byte addressing
support. This is required in order to support flashes like MT35x
that no longer support legacy Bank Address Register(BAR) way of accessing
>16MB region.
Signed-off-by: Vignesh R
Tested-by: Simon Goldschmidt
Tested-by: Stefan
In arch/sandbox/include/asm/types.h we have
Therefore for 32 bit Sandbox build BITS_PER_LONG turns out to be 32 as
CONFIG_PHYS64 is not set
This messes up the current logic of GENMASK macro due to mismatch b/w
size of unsigned long (64 bit) and that of BITS_PER_LONG.
Fix this by using
SPI controllers support all types of SPI modes including dual/quad bus
widths. Therefore remove constraint wrt SPI mode from spi-mem layer.
Signed-off-by: Vignesh R
Tested-by: Simon Goldschmidt
Tested-by: Stefan Roese
Tested-by: Horatiu Vultur
---
drivers/spi/spi-mem.c | 9 -
1 file
Here is the v3 of SPI NOR migration(github branch at [1]). I have
retained Tested-by from v2 as this is just re split of patches and
minor fixups.
Travis ci reports all green.
Change log:
Since v2:
Split sync up patches into smaller versions so that its easier for review.
Address comments by
Completely move CONFIG_SPI_FLASH from remaining board header files to
defconfigs
Signed-off-by: Vignesh R
---
configs/cgtqmx6eval_defconfig| 1 +
configs/chromebit_mickey_defconfig | 1 +
configs/chromebook_jerry_defconfig | 1 +
configs/chromebook_minnie_defconfig
# This is a replacement of my patch#1[1] with minor updates.
# The other patches are the exact same as in v6.
# [1] https://lists.denx.de/pipermail/u-boot/2019-January/356035.html
"env [print|set] -e" allows for handling uefi variables without
knowing details about mapping to corresponding u-boot
The internal DMAC asserts DMA transfer end bit too early on older
version of the TMIO IPs which use bit 17 for DTRAEND. Add 1uS
delay after the completion of DMA transfer and before invalidating
the cache to let the DMAC fully complete the transfer. Otherwise,
it could happen that the last few
Different versions of the SDHI core use either bit 17 or bit 20 for the
DTRAEND indication, which can differ even between SoC revisions. Make
the DTRAEND bit position part of the driver private data, so that the
probe function can set this accordingly. Set this to 20 on Socionext
SoCs and either
On Fri, Jan 25, 2019 at 01:42:17PM +0100, Alexander Graf wrote:
>
>
> On 24.01.19 12:04, AKASHI Takahiro wrote:
> > "env [print|set] -e" allows for handling uefi variables without
> > knowing details about mapping to corresponding u-boot variables.
> >
> > Signed-off-by: AKASHI Takahiro
> >
On Tue, 29 Jan 2019, AKASHI Takahiro wrote:
My $.25 -- IMHO, block device partitions in Device Tree is _NOT_ a very good
idea.
What if one decided to re-partition his drive? Or just use bigger or smaller
drive? Would he has to re-write DTS file and re-compile everything? And such
change is not
Alex,
On Fri, Jan 25, 2019 at 12:56:52PM +0100, Alexander Graf wrote:
>
>
> On 24.01.19 12:04, AKASHI Takahiro wrote:
> > This patch set is a collection of patches to enhance efi user interfaces
> > /commands. It will help improve user experience on efi boot and make it
> > more usable
Efi_disk_create() should be hook up at every creation of block device
at each driver. Associated blk_desc must be properly set up before
calling this function.
Signed-off-by: AKASHI Takahiro
---
common/usb_storage.c | 27 +--
drivers/scsi/scsi.c
efi_disk_create() will initialize efi_disk attributes for each device,
either UCLASS_BLK or UCLASS_PARTITION.
Currently (temporarily), efi_disk_obj structure is embedded into
blk_desc to hold efi-specific attributes.
Signed-off-by: AKASHI Takahiro
---
drivers/block/blk-uclass.c | 9 ++
This patch set came from the past discussion[1] on my "removable device
support" patch and is intended to be an attempt to integrate efi_disk
(more precisely, EFI_BLOCK_IO_PROTOCOL-capable efi object) into u-boot's
Driver Model as much seamlessly as possible
[1]
UCLASS_PARTITION device will be created as a child node of
UCLASS_BLK device.
Signed-off-by: AKASHI Takahiro
---
drivers/block/blk-uclass.c | 52 ++
include/dm/uclass-id.h | 1 +
2 files changed, 53 insertions(+)
diff --git a/drivers/block/blk-uclass.c
Hi,
On Tue, Jan 29, 2019 at 1:32 AM DJM-Avalesta wrote:
>
> Dear Bin Meng,
>
> I have a version of U-Boot, on my Jetson TX2 hardware, which does not support
> USB 3.0.
>
>
> U-Boot 2016.07-g9c3b9a4
>
> (May 17 2018 - 00:08:48 -0700)
>
>
Can you please use latest U-Boot instead? That will be
Simon,
On Mon, Jan 28, 2019 at 05:46:21PM -0700, Simon Glass wrote:
> Hi,
>
> On Mon, 28 Jan 2019 at 01:55, AKASHI Takahiro
> wrote:
> >
> > On Fri, Jan 25, 2019 at 10:31:20AM +0100, Alexander Graf wrote:
> > >
> > >
> > > On 25.01.19 10:18, AKASHI Takahiro wrote:
> > > > On Fri, Jan 25, 2019
> -Original Message-
> From: Fabio Estevam [mailto:feste...@gmail.com]
> Sent: 2019年1月28日 22:24
> To: Stefano Babic
> Cc: Peng Fan ; Fabio Estevam
> ; u-boot@lists.denx.de; dl-uboot-imx
> ; Lukasz Majewski
> Subject: Re: [U-Boot] [PATCH 07/10] clk: imx8: add i.MX8QM clk driver
>
> Hi
Hi Stefano
> > +
> >
>
> Ok - I see you decide to split the code on depend of the SOC type.
> Nevertheless, even if defines are different, it seems to me that there is
> still a
> lot of common code (_imx8_clk_enable is very similar). Do we need really a
> separate file for each MX8 variant ?
Hi Alex,
On Mon, 28 Jan 2019 at 13:08, Alexander Graf wrote:
>
>
>
> On 28.01.19 20:47, Simon Glass wrote:
> > Hi Alex,
> >
> > On Mon, 28 Jan 2019 at 12:39, Alexander Graf wrote:
> >>
> >>
> >>
> >> On 28.01.19 20:36, Simon Glass wrote:
> >>> Hi Alex,
> >>>
> >>> On Mon, 28 Jan 2019 at 12:34,
Hi,
On Mon, 28 Jan 2019 at 01:55, AKASHI Takahiro
wrote:
>
> On Fri, Jan 25, 2019 at 10:31:20AM +0100, Alexander Graf wrote:
> >
> >
> > On 25.01.19 10:18, AKASHI Takahiro wrote:
> > > On Fri, Jan 25, 2019 at 09:52:31AM +0100, Alexander Graf wrote:
> > >>
> > >>
> > >> On 25.01.19 09:27, AKASHI
On Mon, Jan 28, 2019 at 02:23:00PM -0600, Adam Ford wrote:
> On Mon, Jan 28, 2019 at 9:14 AM Tom Rini wrote:
> >
> > On Mon, Jan 28, 2019 at 09:08:54AM -0600, Adam Ford wrote:
> > > On Fri, Jan 25, 2019 at 3:39 PM Adam Ford wrote:
> > > >
> > > > On Thu, Jan 24, 2019 at 7:19 AM Felix Brack
On Mon, 28 Jan 2019 09:50:58 +0100
Mario Six mario@gdsys.cc wrote:
> The ihs_video_out driver's error handling is incorrect in two places
> (one is a missing negation, and in one place a error should be ignored).
>
> Fix these two instances.
>
> Signed-off-by: Mario Six
> ---
>
On Mon, Jan 28, 2019 at 9:14 AM Tom Rini wrote:
>
> On Mon, Jan 28, 2019 at 09:08:54AM -0600, Adam Ford wrote:
> > On Fri, Jan 25, 2019 at 3:39 PM Adam Ford wrote:
> > >
> > > On Thu, Jan 24, 2019 at 7:19 AM Felix Brack wrote:
> > > >
> > > > Hello Adam,
> > > >
> > > > On 23.01.2019 22:13,
On Thu, 17 Jan 2019 11:29:55 +0200
Priit Laes pl...@plaes.org wrote:
...
> Signed-off-by: Priit Laes
> ---
> drivers/video/videomodes.c | 2 --
> 1 file changed, 2 deletions(-)
Applied to u-boot-video/master, thanks!
--
Anatolij
___
U-Boot mailing
On Fri, 4 Jan 2019 09:11:05 +
Ye Li ye...@nxp.com wrote:
> When framebuffer driver init is failed, we should return the err value not 0.
> So the video init can exit immediately.
>
> Signed-off-by: Ye Li
> ---
> arch/arm/mach-imx/video.c | 4 ++--
> 1 file changed, 2 insertions(+), 2
On Tue, 15 Jan 2019 17:17:58 +0100
Neil Armstrong narmstr...@baylibre.com wrote:
> From: Maxime Jourdan
>
> With the recent addition of the meson VPU driver, enable the following
> config entries by default for meson-64 targets: CONFIG_CONSOLE_MUX,
> CONFIG_SYS_CONSOLE_IS_IN_ENV.
>
> This
On Tue, 15 Jan 2019 17:17:59 +0100
Neil Armstrong narmstr...@baylibre.com wrote:
> From: Maxime Jourdan
>
> libretech-cc being the main device tested with CONFIG_VIDEO_MESON, let's
> enable it by default.
>
> Also enable:
> - CONFIG_SYS_WHITE_ON_BLACK for prettiness
> -
On Tue, 15 Jan 2019 17:17:57 +0100
Neil Armstrong narmstr...@baylibre.com wrote:
> Allows displaying the console via video and using a USB keyboard.
>
> Also enables CONFIG_SPLASH_SCREEN if using video.
>
> Signed-off-by: Neil Armstrong
> Signed-off-by: Maxime Jourdan
Reviewed-by: Anatolij
On 28.01.19 20:47, Simon Glass wrote:
> Hi Alex,
>
> On Mon, 28 Jan 2019 at 12:39, Alexander Graf wrote:
>>
>>
>>
>> On 28.01.19 20:36, Simon Glass wrote:
>>> Hi Alex,
>>>
>>> On Mon, 28 Jan 2019 at 12:34, Alexander Graf wrote:
On 28.01.19 20:31, Simon Glass wrote:
>
On Tue, 15 Jan 2019 17:17:56 +0100
Neil Armstrong narmstr...@baylibre.com wrote:
> From: Maxime Jourdan
>
> If VIDEO_MESON is enabled, we need to setup the fdt for the framebuffer.
>
> Call meson_vpu_rsv_fb() which reserves the framebuffer memory region for
> EFI, and sets up
On Tue, 15 Jan 2019 17:17:49 +0100
Neil Armstrong narmstr...@baylibre.com wrote:
> From: Maxime Jourdan
>
> MESON_GX_VPU_POWER_DOMAIN should depend on POWER_DOMAIN.
>
> Signed-off-by: Maxime Jourdan
> Signed-off-by: Neil Armstrong
Reviewed-by: Anatolij Gustschin
--
Anatolij
On Tue, 15 Jan 2019 17:17:52 +0100
Neil Armstrong narmstr...@baylibre.com wrote:
> This adds video output support for Amlogic GXBB/GXL/GXM chips.
> The supported ports are CVBS and HDMI (based on DW_HDMI).
>
> When using HDMI, only DMT modes are supported.
>
> There is support for
Hi Alex,
On Mon, 28 Jan 2019 at 12:39, Alexander Graf wrote:
>
>
>
> On 28.01.19 20:36, Simon Glass wrote:
> > Hi Alex,
> >
> > On Mon, 28 Jan 2019 at 12:34, Alexander Graf wrote:
> >>
> >>
> >>
> >> On 28.01.19 20:31, Simon Glass wrote:
> >>> Hi Alex,
> >>>
> >>> On Mon, 28 Jan 2019 at 12:27,
On 28.01.19 20:36, Simon Glass wrote:
> Hi Alex,
>
> On Mon, 28 Jan 2019 at 12:34, Alexander Graf wrote:
>>
>>
>>
>> On 28.01.19 20:31, Simon Glass wrote:
>>> Hi Alex,
>>>
>>> On Mon, 28 Jan 2019 at 12:27, Alexander Graf wrote:
On 28.01.19 20:24, Simon Glass wrote:
>
Hi Alex,
On Mon, 28 Jan 2019 at 12:34, Alexander Graf wrote:
>
>
>
> On 28.01.19 20:31, Simon Glass wrote:
> > Hi Alex,
> >
> > On Mon, 28 Jan 2019 at 12:27, Alexander Graf wrote:
> >>
> >>
> >>
> >> On 28.01.19 20:24, Simon Glass wrote:
> >>> Hi Alex,
> >>>
> >>> On Mon, 28 Jan 2019 at 12:15,
On 28.01.19 20:31, Simon Glass wrote:
> Hi Alex,
>
> On Mon, 28 Jan 2019 at 12:27, Alexander Graf wrote:
>>
>>
>>
>> On 28.01.19 20:24, Simon Glass wrote:
>>> Hi Alex,
>>>
>>> On Mon, 28 Jan 2019 at 12:15, Alexander Graf wrote:
On 28.01.19 20:13, Simon Glass wrote:
>
Hi Alex,
On Mon, 28 Jan 2019 at 12:27, Alexander Graf wrote:
>
>
>
> On 28.01.19 20:24, Simon Glass wrote:
> > Hi Alex,
> >
> > On Mon, 28 Jan 2019 at 12:15, Alexander Graf wrote:
> >>
> >>
> >>
> >> On 28.01.19 20:13, Simon Glass wrote:
> >>> Hi,
> >>>
> >>> On Mon, 28 Jan 2019 at 08:42,
On 28.01.19 20:24, Simon Glass wrote:
> Hi Alex,
>
> On Mon, 28 Jan 2019 at 12:15, Alexander Graf wrote:
>>
>>
>>
>> On 28.01.19 20:13, Simon Glass wrote:
>>> Hi,
>>>
>>> On Mon, 28 Jan 2019 at 08:42, Alexander Graf wrote:
Our selftest will soon test the actual runtime reset
On 1/28/19 8:17 PM, Simon Goldschmidt wrote:
> Am 28.01.2019 um 20:02 schrieb Marek Vasut:
>> On 1/28/19 1:38 PM, Simon Goldschmidt wrote:
>>> On Mon, Jan 28, 2019 at 12:59 PM Marek Vasut wrote:
On 1/28/19 12:49 PM, Simon Goldschmidt wrote:
> On Mon, Jan 28, 2019 at 12:30 PM Marek
Hi Alex,
On Mon, 28 Jan 2019 at 12:15, Alexander Graf wrote:
>
>
>
> On 28.01.19 20:13, Simon Glass wrote:
> > Hi,
> >
> > On Mon, 28 Jan 2019 at 08:42, Alexander Graf wrote:
> >>
> >> Our selftest will soon test the actual runtime reset function rather than
> >> the boot time one. For this, we
Am 28.01.2019 um 20:02 schrieb Marek Vasut:
On 1/28/19 1:38 PM, Simon Goldschmidt wrote:
On Mon, Jan 28, 2019 at 12:59 PM Marek Vasut wrote:
On 1/28/19 12:49 PM, Simon Goldschmidt wrote:
On Mon, Jan 28, 2019 at 12:30 PM Marek Vasut wrote:
On 1/27/19 9:47 AM, Simon Goldschmidt wrote:
Am
On 28.01.19 20:13, Simon Glass wrote:
> Hi,
>
> On Mon, 28 Jan 2019 at 08:42, Alexander Graf wrote:
>>
>> Our selftest will soon test the actual runtime reset function rather than
>> the boot time one. For this, we need to ensure that the runtime version
>> actually succeeds on x86 to keep our
On 1/28/19 1:38 PM, Simon Goldschmidt wrote:
> On Mon, Jan 28, 2019 at 12:59 PM Marek Vasut wrote:
>>
>> On 1/28/19 12:49 PM, Simon Goldschmidt wrote:
>>> On Mon, Jan 28, 2019 at 12:30 PM Marek Vasut wrote:
On 1/27/19 9:47 AM, Simon Goldschmidt wrote:
> Am 26.01.2019 um 09:58
Hi,
On Mon, 28 Jan 2019 at 08:42, Alexander Graf wrote:
>
> Our selftest will soon test the actual runtime reset function rather than
> the boot time one. For this, we need to ensure that the runtime version
> actually succeeds on x86 to keep our travis tests work.
>
> So this patch implements
On 1/28/19 4:42 PM, Alexander Graf wrote:
> Our selftest will soon test the actual runtime reset function rather than
> the boot time one. For this, we need to ensure that the runtime version
> actually succeeds on x86 to keep our travis tests work.
>
> So this patch implements an x86 runtime
On 1/28/19 4:42 PM, Alexander Graf wrote:
> While discussing something compeltely different, Ard pointed out
> that it might be legal to omit calling SetVirtualAddressMap altogether.
>
> While that sounds great, we currently rely on that call to remove
> all function pointers to code that we do
On 1/26/19 9:51 PM, Tom Rini wrote:
> On Thu, Jan 17, 2019 at 01:43:06PM -0600, Andrew F. Davis wrote:
>
>> Add a new defconfig file for the DRA7xx High Security EVM. This config
>> is specific for the case of USB booting.
>>
>> Signed-off-by: Andrew F. Davis
>> Reviewed-by: Tom Rini
>
> OK,
Booting from UART and USB on HS devices is now supported for this
platform. Update documentation for the same.
Signed-off-by: Andrew F. Davis
Reviewed-by: Tom Rini
---
doc/README.ti-secure | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/doc/README.ti-secure
Add a new defconfig file for the DRA7xx High Security EVM. This config
is specific for the case of USB booting.
Signed-off-by: Andrew F. Davis
Reviewed-by: Tom Rini
---
MAINTAINERS | 1 +
configs/dra7xx_hs_evm_usb_defconfig | 113
2 files
Additions have been made to the non-HS defconfig without the same
being made to the HS defconfig, sync them.
Signed-off-by: Andrew F. Davis
---
configs/dra7xx_hs_evm_defconfig | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/configs/dra7xx_hs_evm_defconfig
Add a new defconfig file for the AM57xx High Security EVM. This config
is specific for the case of USB/UART booting.
Signed-off-by: Andrew F. Davis
Reviewed-by: Tom Rini
---
MAINTAINERS | 1 +
configs/am57xx_hs_evm_usb_defconfig | 98 +
2
Additions have been made to the non-HS defconfig without the same
being made to the HS defconfig, sync them.
Signed-off-by: Andrew F. Davis
---
configs/am57xx_hs_evm_defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/configs/am57xx_hs_evm_defconfig b/configs/am57xx_hs_evm_defconfig
Hello all,
This series adds USB boot support to HS DRA7xx/AM57xx platforms.
Thanks,
Andrew
Changes from v3:
- Rebase on upstream
- Sync defconfigs
Changes from v2:
- Only use ISW_ENTRY_ADDR for system with a set default
Changes from v1:
- Drop explicit UART boot support from DRA7xx as
This adds initial support for micro-DPU (uDPU) board which is based on
Armada-3720 SoC.
micro-DPU is the single-port FTTdp "distribution point unit" made by Methode
Electronics
which offers complete modularity with replaceable SFP modules both for uplink
and downlink
(G.hn over twisted-pair,
Hi Jagan, Tom,
On 15/01/2019 13:59, Neil Armstrong wrote:
> There is no reason not to use the Linux "jedec,spi-nor" binding in u-boot.
> This patchset :
> - adds this compatible into sf_probe and will avoid changing the
> device tree files to add a u-boot specific compatible to probe a spi
On Tue, 15 Jan 2019 17:17:51 +0100
Neil Armstrong narmstr...@baylibre.com wrote:
> From: Jorge Ramirez-Ortiz
>
> Some IPs like the meson VPU can only feed a particular pixel format to
> dw_hdmi. As of now, the driver is hardcoded to use RGB888 as input.
>
> This commit enables different pixel
Hi Neil,
On Tue, 15 Jan 2019 17:17:50 +0100
Neil Armstrong narmstr...@baylibre.com wrote:
> From: Jorge Ramirez-Ortiz
>
> Some IPs like the meson VPU have a specific way to write to dw_hdmi
> registers. Make it configurable.
>
> Signed-off-by: Jorge Ramirez-Ortiz
> [added commit description]
While discussing something compeltely different, Ard pointed out
that it might be legal to omit calling SetVirtualAddressMap altogether.
While that sounds great, we currently rely on that call to remove
all function pointers to code that we do not support outside of
boot services.
So let's patch
While discussing something compeltely different, Ard pointed out
that it might be legal to omit calling SetVirtualAddressMap altogether.
While that sounds great, we currently rely on that call to remove
all function pointers to code that we do not support outside of
boot services.
So let's patch
Our selftest will soon test the actual runtime reset function rather than
the boot time one. For this, we need to ensure that the runtime version
actually succeeds on x86 to keep our travis tests work.
So this patch implements an x86 runtime reset function. It is missing
shutdown functionality
On 19-01-18 10:30:24, Tom Rini wrote:
> On Fri, Jan 18, 2019 at 03:26:42PM +, Abel Vesa wrote:
> > On 19-01-18 13:16:07, Fabio Estevam wrote:
> > > Hi Abel,
> > >
> > > On Fri, Jan 18, 2019 at 12:59 PM Abel Vesa wrote:
> > >
> > > > +CONFIG_OF_CONTROL=y
> > > > +CONFIG_SPL_OF_CONTROL=y
> >
On Tue, Jan 22, 2019 at 05:09:26PM -0500, Tom Rini wrote:
> Make use of "IMAGE_MAX_SIZE" and "IMAGE_TEXT_BASE" rather than
> CONFIG_SPL_MAX_SIZE and CONFIG_SPL_TEXT_BASE. This lets us re-use the
> same script for both SPL and TPL. Add logic to scripts/Makefile.spl to
> pass in the right value
On Tue, Jan 22, 2019 at 05:09:25PM -0500, Tom Rini wrote:
> Per Kever Yang, 32768 is a reasonable max size for TPL on RK3288.
>
> Cc: Kever Yang
> Cc: Philipp Tomsich
> Signed-off-by: Tom Rini
> Reviewed-by: Kever Yang
Applied to u-boot/master, thanks!
--
Tom
signature.asc
Description:
On Tue, Jan 22, 2019 at 05:09:24PM -0500, Tom Rini wrote:
> Rather than checking for CONFIG_TPL_BUILD and then re-defining
> CONFIG_SPL_TEXT_BASE make use of CONFIG_TPL_TEXT_BASE directly.
>
> Cc: York Sun
> Cc: Po Liu
> Cc: Qiang Zhao
> Cc: Timur Tabi
> Signed-off-by: Tom Rini
After some
On 26.01.19 10:31, Heinrich Schuchardt wrote:
> On 1/25/19 10:43 PM, Ard Biesheuvel wrote:
>> On Fri, 25 Jan 2019 at 19:21, Heinrich Schuchardt wrote:
>>>
>>> On 1/23/19 6:33 PM, Alexander Graf wrote:
While discussing something compeltely different, Ard pointed out
that it might be
On Mon, Jan 28, 2019 at 09:08:54AM -0600, Adam Ford wrote:
> On Fri, Jan 25, 2019 at 3:39 PM Adam Ford wrote:
> >
> > On Thu, Jan 24, 2019 at 7:19 AM Felix Brack wrote:
> > >
> > > Hello Adam,
> > >
> > > On 23.01.2019 22:13, Adam Ford wrote:
> > > > By removing EXT support from SPL, it makes
On Fri, Jan 25, 2019 at 3:39 PM Adam Ford wrote:
>
> On Thu, Jan 24, 2019 at 7:19 AM Felix Brack wrote:
> >
> > Hello Adam,
> >
> > On 23.01.2019 22:13, Adam Ford wrote:
> > > By removing EXT support from SPL, it makes room for the extra
> > > overhead of enabling OF_CONTROL in SPL. With
Hi Lukasz,
On 21/01/19 15:19, Lukasz Majewski wrote:
> Hi Fabio,
>
>> Hi Lukasz,
>>
>> On Sat, Jan 19, 2019 at 7:15 AM Lukasz Majewski wrote:
>>
>>> +static ulong imx6q_clk_get_rate(struct clk *clk)
>>> +{
>>> + ulong rate = 0;
>>> +
>>> + debug("%s(#%lu)\n", __func__, clk->id);
>>>
Hi Ye,
On 07/01/19 10:29, Ye Li wrote:
> Apply errata based on PL310 version instead of compile
> time. Also set Prefetch offset to 15, since it improves
> memcpy performance by 35%. Don't enable Incr double
> Linefill enable since it adversely affects memcpy
> performance by about 32MB/s and
Enable watchdog and reboot with watchdog in the configuration.
Signed-off-by: Philippe Reynes
---
configs/bcm968580_ram_defconfig | 2 ++
1 file changed, 2 insertions(+)
Changelog:
v2:
- add a commit message (thanks Marek)
v3:
- no change
diff --git a/configs/bcm968580_ram_defconfig
This commit add watchdog and sysreset watchdog
in the bcm6858 device tree.
Signed-off-by: Philippe Reynes
---
arch/arm/dts/bcm6858.dtsi | 17 +
1 file changed, 17 insertions(+)
Changelog:
v2:
- add a commit message (thanks Marek)
v3:
- no change
diff --git
Enable watchdog and reboot with watchdog in the configuration.
Signed-off-by: Philippe Reynes
---
configs/bcm968380gerg_ram_defconfig | 2 ++
1 file changed, 2 insertions(+)
Changelog:
v2:
- add a commit message (thanks Marek)
v3:
- no change
diff --git a/configs/bcm968380gerg_ram_defconfig
1 - 100 of 199 matches
Mail list logo
