On Tue, 2019-06-18 at 22:49 +0200, Heinrich Schuchardt wrote:
> Just use https, e.g
>
> git remote set-url net \
> https://gitlab.denx.de/u-boot/custodians/u-boot-net.git
>
> And in .gitconfig put your email address:
>
> [credential "https://gitlab.denx.de";]
> username = joe.hershber..
Hi Joe,
On Tue, 2019-06-18 at 15:08 -0500, Joe Hershberger wrote:
>
> I tried to push to u-boot-net an got this...
>
> --8<--
>
> $ git push -u -v net-push master
> Pushing to g...@gitlab.denx.de:u-boot/custodians/u-boot-net.git
> gitaly-receive-pack: fatal: error: %v
> fatal: Could not
Hi Wolfgang
On 6/18/19 4:04 PM, Daniel Schwierzeck wrote:
> On Tue, Jun 18, 2019 at 3:47 PM Wolfgang Denk wrote:
> ...
>>> 4. The custodian can resume work using the gitlab server, as soon as
>>>he can "see" his repository there. Tom should already be
>>>prepared to pull from the gitlab
On Tue, 18 Jun 2019 22:49:44 +0200
Heinrich Schuchardt xypron.g...@gmx.de wrote:
...
>> I tried to push to u-boot-net an got this...
>>
>> --8<--
>>
>> $ git push -u -v net-push master
>> Pushing to g...@gitlab.denx.de:u-boot/custodians/u-boot-net.git
>
>Just use https, e.g
>
>git remote
On 6/18/19 10:08 PM, Joe Hershberger wrote:
On Tue, Jun 18, 2019 at 8:47 AM Wolfgang Denk wrote:
Hello everybody,
I wrote:
as discussed before, we want to switch from the old git server to
more powerful soft- and hardware. We will move the U-Boot master
repository and all custodian reposit
On Tue, Jun 18, 2019 at 8:47 AM Wolfgang Denk wrote:
>
> Hello everybody,
>
> I wrote:
>
> > as discussed before, we want to switch from the old git server to
> > more powerful soft- and hardware. We will move the U-Boot master
> > repository and all custodian repositories to gitlab.
> ...
> > Th
On Tue, Jun 18, 2019 at 10:50 PM Wolfgang Denk wrote:
>
> Dear Daniel,
>
> In message
> you
> wrote:
> >
> > > All these steps have been completed by now. All custodians should
> > > be able to access the new repositories now, and use all teh gitlab
> > > features that are enabled for this pro
Dear Daniel,
In message
you wrote:
>
> > All these steps have been completed by now. All custodians should
> > be able to access the new repositories now, and use all teh gitlab
> > features that are enabled for this project (including CI runners).
>
> works for me and the MIPS repository, than
On Tue, Jun 18, 2019 at 3:47 PM Wolfgang Denk wrote:
>
...
> >
> > 4. The custodian can resume work using the gitlab server, as soon as
> >he can "see" his repository there. Tom should already be
> >prepared to pull from the gitlab repos.
>
> All these steps have been completed by now. A
On 6/18/19 2:00 PM, Tom Rini wrote:
> On Tue, Jun 18, 2019 at 08:49:57AM +, Patrice CHOTARD wrote:
>>
>> On 6/18/19 9:46 AM, Wolfgang Denk wrote:
>>> Dear Patrice,
>>>
>>> In message <561e5fe4-3b32-e45f-ed5d-100c51a7f...@st.com> you wrote:
Patrick Delaunay and i are the STM32 MCU/MPU's U-B
> -Original Message-
> From: U-Boot-Custodians On
> Behalf Of Wolfgang Denk
> Sent: Monday, June 17, 2019 8:12 PM
> To: u-boot-custodi...@lists.denx.de
> Cc: u-boot@lists.denx.de; h...@denx.de
> Subject: [U-Boot-Custodians] [ANNOUNCEMENT] Switching to gitlab.denx.de
>
> Hello everybody,
>
Dear Joe,
> -Original Message-
> From: Florinel Iordache
> Sent: Wednesday, May 15, 2019 2:40 PM
> To: u-boot@lists.denx.de
> Cc: Prabhakar Kushwaha ; Jagdish Gediya
> ; Florinel Iordache
> Subject: [u-boot 2/2] drivers/fsl-mc: Support DPSPARSER object and apply spb
> command
>
> Add sup
On 6/11/19 1:15 PM, Tom Rini wrote:
> On Tue, Jun 11, 2019 at 04:56:24AM +0200, Marek Vasut wrote:
>> On 6/11/19 3:31 AM, Tom Rini wrote:
>>> Hey all,
>>>
>>> It's release day and here is v2019.07-rc4. At this point, I know we
>>> have some regression fixes for i.MX that are coming, and I'm expec
On Tue, Jun 11, 2019 at 04:56:24AM +0200, Marek Vasut wrote:
> On 6/11/19 3:31 AM, Tom Rini wrote:
> > Hey all,
> >
> > It's release day and here is v2019.07-rc4. At this point, I know we
> > have some regression fixes for i.MX that are coming, and I'm expecting a
> > fix to the build time failu
On 4/21/19 6:57 PM, Philipp Tomsich wrote:
>> The SPL for the Tinker Board has to fit into 32 KiB. Currently this limit
>> is exceeded.
>>
>> CONFIG_SPL_I2C_SUPPORT is not needed to move to main U-Boot. So let's
>> disable it.
>>
>> Suggested-by: David Wu
>> Signed-off-by: Heinrich Schuchardt
>>
Hi Tom,
> Hey all,
>
> It's release day and here is v2019.07-rc4. At this point, I know we
> have some regression fixes for i.MX that are coming, and I'm
> expecting a fix to the build time failure for tinker-rk3288.
>
> To repeat myself about DM migration deadlines, first, let me say
> again,
On 6/11/19 3:31 AM, Tom Rini wrote:
> Hey all,
>
> It's release day and here is v2019.07-rc4. At this point, I know we
> have some regression fixes for i.MX that are coming, and I'm expecting a
> fix to the build time failure for tinker-rk3288.
>
> To repeat myself about DM migration deadlines,
On 5/30/19 1:47 PM, Marcel Ziswiler wrote:
> On Thu, 2019-05-30 at 11:29 +0200, Marek Vasut wrote:
>> On 5/30/19 11:14 AM, Marcel Ziswiler wrote:
>>> Hi Tom
>>>
>>> On Wed, 2019-05-29 at 10:12 -0400, Tom Rini wrote:
On Thu, May 16, 2019 at 02:53:55PM +, Marcel Ziswiler wrote:
> Hi Tom
On Sat, May 25, 2019 at 10:41 AM Tom Rini wrote:
>
> On Sat, Mar 09, 2019 at 06:02:51PM -0600, Adam Ford wrote:
>
> > This converts the following to Kconfig:
> >CONFIG_NAND
> >
> > A bunch of boards have dependent NAND drivers, and CONFIG_NAND
> > is already in Kconfig, so this patch enabl
On Thu, 2019-05-30 at 11:29 +0200, Marek Vasut wrote:
> On 5/30/19 11:14 AM, Marcel Ziswiler wrote:
> > Hi Tom
> >
> > On Wed, 2019-05-29 at 10:12 -0400, Tom Rini wrote:
> > > On Thu, May 16, 2019 at 02:53:55PM +, Marcel Ziswiler wrote:
> > > > Hi Tom
> > > >
> > > > On Mon, 2019-05-06 at 09:
On Thu, May 30, 2019 at 01:45:22PM +0300, Alex Sadovsky wrote:
> > - HP iPAQ Pocket PC h2200
> >
> > A consumer device with PXA255 from back in 2002. There has not been any
> > activity on h2200 from its maintainer Lukasz Dalek for almost 5 years
> > now. Without anybody actually owning such hardwa
> - HP iPAQ Pocket PC h2200
>
> A consumer device with PXA255 from back in 2002. There has not been any
> activity on h2200 from its maintainer Lukasz Dalek for almost 5 years
> now. Without anybody actually owning such hardware stepping up it will
> be quite impossible to maintain.
I still have o
On 5/30/19 11:14 AM, Marcel Ziswiler wrote:
> Hi Tom
>
> On Wed, 2019-05-29 at 10:12 -0400, Tom Rini wrote:
>> On Thu, May 16, 2019 at 02:53:55PM +, Marcel Ziswiler wrote:
>>> Hi Tom
>>>
>>> On Mon, 2019-05-06 at 09:26 -0400, Tom Rini wrote:
Hey folks,
I'm attempting, again, to
Hi Tom
On Wed, 2019-05-29 at 10:12 -0400, Tom Rini wrote:
> On Thu, May 16, 2019 at 02:53:55PM +, Marcel Ziswiler wrote:
> > Hi Tom
> >
> > On Mon, 2019-05-06 at 09:26 -0400, Tom Rini wrote:
> > > Hey folks,
> > >
> > > I'm attempting, again, to see what we need to do in order to use
> > > g
Hello everyone,
Apologize if it's not the right channel to ask this kind of questions. I
have build an image using YOCTO for an arm7 platform. I'm creating a
fitImage with the kernel and the dtb file, but after installing the
image and starting the device I get this error:
```
Starting kerne
On Thu, May 16, 2019 at 02:53:55PM +, Marcel Ziswiler wrote:
> Hi Tom
>
> On Mon, 2019-05-06 at 09:26 -0400, Tom Rini wrote:
> > Hey folks,
> >
> > I'm attempting, again, to see what we need to do in order to use gcc-
> > 8.x
> > for U-Boot and ran into, again:
> > https://patchwork.ozlabs.or
On Sat, Mar 09, 2019 at 06:02:51PM -0600, Adam Ford wrote:
> This converts the following to Kconfig:
>CONFIG_NAND
>
> A bunch of boards have dependent NAND drivers, and CONFIG_NAND
> is already in Kconfig, so this patch enables that flag for a
> variety of boards to make their respective
Hi,
On Tue, 21 May 2019 at 08:50, Tom Rini wrote:
>
> On Tue, May 21, 2019 at 04:34:19PM +0200, Marek Vasut wrote:
> > On 5/21/19 4:29 PM, Marcel Ziswiler wrote:
> > > On Tue, 2019-05-21 at 14:49 +0200, Marek Vasut wrote:
> > >> On 5/21/19 12:33 PM, Marcel Ziswiler wrote:
> > >>> On Tue, 2019-05-
On Tue, May 21, 2019 at 04:34:19PM +0200, Marek Vasut wrote:
> On 5/21/19 4:29 PM, Marcel Ziswiler wrote:
> > On Tue, 2019-05-21 at 14:49 +0200, Marek Vasut wrote:
> >> On 5/21/19 12:33 PM, Marcel Ziswiler wrote:
> >>> On Tue, 2019-05-21 at 12:50 +0300, Alex Sadovsky wrote:
> It's slightly off
On 5/21/19 4:29 PM, Marcel Ziswiler wrote:
> On Tue, 2019-05-21 at 14:49 +0200, Marek Vasut wrote:
>> On 5/21/19 12:33 PM, Marcel Ziswiler wrote:
>>> On Tue, 2019-05-21 at 12:50 +0300, Alex Sadovsky wrote:
It's slightly off-topic but I wonder whether this ongoing
deprecation
of ARMv4
On Tue, 2019-05-21 at 14:49 +0200, Marek Vasut wrote:
> On 5/21/19 12:33 PM, Marcel Ziswiler wrote:
> > On Tue, 2019-05-21 at 12:50 +0300, Alex Sadovsky wrote:
> > > It's slightly off-topic but I wonder whether this ongoing
> > > deprecation
> > > of ARMv4 and ARMv5 (first in GCC, then in U-Boot) r
On 5/21/19 3:47 PM, Alex Sadovsky wrote:
> On 21/05/2019, Marek Vasut wrote:
>> On 5/21/19 11:50 AM, Alex Sadovsky wrote:
>>> It's slightly off-topic but I wonder whether this ongoing deprecation
>>> of ARMv4 and ARMv5 (first in GCC, then in U-Boot) really simplifies
>>> anything at all.
>>> There
On Tue, May 21, 2019 at 04:47:44PM +0300, Alex Sadovsky wrote:
> On 21/05/2019, Marek Vasut wrote:
> > On 5/21/19 11:50 AM, Alex Sadovsky wrote:
> >> It's slightly off-topic but I wonder whether this ongoing deprecation
> >> of ARMv4 and ARMv5 (first in GCC, then in U-Boot) really simplifies
> >>
On 21/05/2019, Marek Vasut wrote:
> On 5/21/19 11:50 AM, Alex Sadovsky wrote:
>> It's slightly off-topic but I wonder whether this ongoing deprecation
>> of ARMv4 and ARMv5 (first in GCC, then in U-Boot) really simplifies
>> anything at all.
>> There are tons of devices that are still working good
On Tue, May 21, 2019 at 10:33:39AM +, Marcel Ziswiler wrote:
> On Tue, 2019-05-21 at 12:50 +0300, Alex Sadovsky wrote:
> > It's slightly off-topic but I wonder whether this ongoing deprecation
> > of ARMv4 and ARMv5 (first in GCC, then in U-Boot) really simplifies
> > anything at all.
> > There
On 5/21/19 11:50 AM, Alex Sadovsky wrote:
> It's slightly off-topic but I wonder whether this ongoing deprecation
> of ARMv4 and ARMv5 (first in GCC, then in U-Boot) really simplifies
> anything at all.
> There are tons of devices that are still working good and there are
> even ARMv5-based MCUs th
On 5/21/19 12:33 PM, Marcel Ziswiler wrote:
> On Tue, 2019-05-21 at 12:50 +0300, Alex Sadovsky wrote:
>> It's slightly off-topic but I wonder whether this ongoing deprecation
>> of ARMv4 and ARMv5 (first in GCC, then in U-Boot) really simplifies
>> anything at all.
>> There are tons of devices that
On Tue, May 21, 2019 at 08:44:57AM +, Marcel Ziswiler wrote:
> On Thu, 2019-05-16 at 17:02 +0200, Marek Vasut wrote:
> > On 5/16/19 4:53 PM, Marcel Ziswiler wrote:
> > > Hi Tom
> > >
> > > On Mon, 2019-05-06 at 09:26 -0400, Tom Rini wrote:
> > > > Hey folks,
> > > >
> > > > I'm attempting, ag
On Tue, 2019-05-21 at 12:50 +0300, Alex Sadovsky wrote:
> It's slightly off-topic but I wonder whether this ongoing deprecation
> of ARMv4 and ARMv5 (first in GCC, then in U-Boot) really simplifies
> anything at all.
> There are tons of devices that are still working good and there are
> even ARMv5
It's slightly off-topic but I wonder whether this ongoing deprecation
of ARMv4 and ARMv5 (first in GCC, then in U-Boot) really simplifies
anything at all.
There are tons of devices that are still working good and there are
even ARMv5-based MCUs that are still produced (such as CH561
manufactured by
On Thu, 2019-05-16 at 17:02 +0200, Marek Vasut wrote:
> On 5/16/19 4:53 PM, Marcel Ziswiler wrote:
> > Hi Tom
> >
> > On Mon, 2019-05-06 at 09:26 -0400, Tom Rini wrote:
> > > Hey folks,
> > >
> > > I'm attempting, again, to see what we need to do in order to use
> > > gcc-
> > > 8.x
> > > for U-B
On Sun, May 19, 2019 at 08:55:53AM +0800, Bin Meng wrote:
> Hi Tom,
>
> On Sun, May 19, 2019 at 12:07 AM Simon Glass wrote:
> >
> > Hi Tom,
> >
> > On Sat, 18 May 2019 at 06:13, Tom Rini wrote:
> > >
> > > Hey guys,
> > >
> > > Looking at https://travis-ci.org/trini/u-boot/jobs/534037240 this is
Hi Tom,
On Sun, May 19, 2019 at 12:07 AM Simon Glass wrote:
>
> Hi Tom,
>
> On Sat, 18 May 2019 at 06:13, Tom Rini wrote:
> >
> > Hey guys,
> >
> > Looking at https://travis-ci.org/trini/u-boot/jobs/534037240 this is the
> > only board that doesn't build (having switched ARM to gcc-8.3 from
> >
Hi Tom,
On Sat, 18 May 2019 at 06:13, Tom Rini wrote:
>
> Hey guys,
>
> Looking at https://travis-ci.org/trini/u-boot/jobs/534037240 this is the
> only board that doesn't build (having switched ARM to gcc-8.3 from
> Arm/Linaro) and the error is pretty odd. Do you have any idea what's
> going on?
Hey guys,
Looking at https://travis-ci.org/trini/u-boot/jobs/534037240 this is the
only board that doesn't build (having switched ARM to gcc-8.3 from
Arm/Linaro) and the error is pretty odd. Do you have any idea what's
going on? Thanks!
--
Tom
signature.asc
Description: PGP signature
___
On Thu, 2019-05-16 at 13:49 -0400, Tom Rini wrote:
> On Thu, May 16, 2019 at 02:53:55PM +, Marcel Ziswiler wrote:
> > Hi Tom
> >
> > On Mon, 2019-05-06 at 09:26 -0400, Tom Rini wrote:
> > > Hey folks,
> ...
> > > So, what should we do about this? Is there still active interest
> > > in
> > >
On Thu, May 16, 2019 at 02:53:55PM +, Marcel Ziswiler wrote:
> Hi Tom
>
> On Mon, 2019-05-06 at 09:26 -0400, Tom Rini wrote:
> > Hey folks,
> >
> > I'm attempting, again, to see what we need to do in order to use gcc-
> > 8.x
> > for U-Boot and ran into, again:
> > https://patchwork.ozlabs.or
On 5/16/19 4:53 PM, Marcel Ziswiler wrote:
> Hi Tom
>
> On Mon, 2019-05-06 at 09:26 -0400, Tom Rini wrote:
>> Hey folks,
>>
>> I'm attempting, again, to see what we need to do in order to use gcc-
>> 8.x
>> for U-Boot and ran into, again:
>> https://patchwork.ozlabs.org/patch/920329/ which in shor
y
debugging. I may pick that one up tomorrow again.
Cheers
Marcel
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> https://lists.denx.de/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Add support for DPSPARSER object (create/destroy, open/close, apply spb)
required to configure Soft Parser by using MC. Also add uboot command to
apply a Soft Parser Blob by using a command like: fsl_mc apply spb
Signed-off-by: Florinel Iordache
---
drivers/net/fsl-mc/Kconfig | 12 ++
dri
Create drivers/net/fsl-mc/Kconfig and move fsl-mc specific configs
from arch/arm/cpu/armv8/fsl-layerscape/Kconfig to this new Kconfig
Signed-off-by: Florinel Iordache
---
arch/arm/cpu/armv8/fsl-layerscape/Kconfig | 17 -
drivers/net/Kconfig | 1 +
drivers/n
On Thu, May 09, 2019 at 05:12:25PM +0200, Marek Vasut wrote:
> On 5/9/19 5:03 PM, Vasily Khoruzhick wrote:
> > On Thu, May 9, 2019 at 7:56 AM Marek Vasut wrote:
> >>
> >> On 5/9/19 4:02 PM, Tom Rini wrote:
> >>> On Mon, May 06, 2019 at 09:26:04AM -0400, Tom Rini wrote:
> >>>
> Hey folks,
> >>
On 5/9/19 5:03 PM, Vasily Khoruzhick wrote:
> On Thu, May 9, 2019 at 7:56 AM Marek Vasut wrote:
>>
>> On 5/9/19 4:02 PM, Tom Rini wrote:
>>> On Mon, May 06, 2019 at 09:26:04AM -0400, Tom Rini wrote:
>>>
Hey folks,
I'm attempting, again, to see what we need to do in order to use gcc-
On Thu, May 9, 2019 at 7:56 AM Marek Vasut wrote:
>
> On 5/9/19 4:02 PM, Tom Rini wrote:
> > On Mon, May 06, 2019 at 09:26:04AM -0400, Tom Rini wrote:
> >
> >> Hey folks,
> >>
> >> I'm attempting, again, to see what we need to do in order to use gcc-8.x
> >> for U-Boot and ran into, again:
> >> ht
On 5/9/19 4:02 PM, Tom Rini wrote:
> On Mon, May 06, 2019 at 09:26:04AM -0400, Tom Rini wrote:
>
>> Hey folks,
>>
>> I'm attempting, again, to see what we need to do in order to use gcc-8.x
>> for U-Boot and ran into, again:
>> https://patchwork.ozlabs.org/patch/920329/ which in short is that when
On Mon, May 06, 2019 at 09:26:04AM -0400, Tom Rini wrote:
> Hey folks,
>
> I'm attempting, again, to see what we need to do in order to use gcc-8.x
> for U-Boot and ran into, again:
> https://patchwork.ozlabs.org/patch/920329/ which in short is that when
> using -mcpu=xscale gcc-8.x throws an odd
Hey folks,
I'm attempting, again, to see what we need to do in order to use gcc-8.x
for U-Boot and ran into, again:
https://patchwork.ozlabs.org/patch/920329/ which in short is that when
using -mcpu=xscale gcc-8.x throws an odd error:
cc1: error: switch -mcpu=xscale conflicts with -march=armv5te s
Hi everyone,
I discovered a problem when using upstream U-Boot with Kernel 5.0 and MVPP2
when booting with the bootefi command on the Macchiatobin.
The Macchiatobin runs ARM64 based Armada 8040.
How to reproduce this:
1. Compile and flush upstream U-Boot:
UBOOT_VERSION=v2019.04
BINARIES_VER
I was updating the router, but it took a long time to turn off and it became
a brick. I connected it by serial communication, and the following log only
stopped. What should I do? Actual ram and nand is 128mb.
U-Boot 1.1.4 (Mar 1 2015 - 22:07:55)
ap135 - Scorpion 1.0
DRAM: 4 MB
--
Sent from: h
key inside the U-Boot image?
Sincerely,
Pascal Linder
Student Telekommunikation Netzwerke und Sicherheit
Klasse T-3b
Von: Simon Goldschmidt
Gesendet: Samstag, 27. April 2019 21:12:03
An: Linder Pascal
Betreff: Re: AW: [U-Boot] U-Boot Security
Hello Pascal
On Wed, Apr 17, 2019 at 11:22:05AM +0200, Gregory CLEMENT wrote:
> The purpose of "mtd: nand: raw: allow to disable unneeded ECC layouts"
> was to allow disabling the default ECC layouts if a driver is known to
> provide its own ECC layout. However, this commit did the opposite and
> disabled the
On Tue, Apr 16, 2019 at 01:31:58PM +0200, Heiko Schocher wrote:
> generate define for an alias only if the struct is not
> created already.
>
> This prevents compilerwarning:
> PLATspl/dts/dt-platdata.o
> spl/dts/dt-platdata.c:11:46: error: missing braces around initializer
> [-Werror=miss
On Sun, Apr 21, 2019 at 11:54:37PM +0200, Heinrich Schuchardt wrote:
> Add the device trees for
>
> * vexpress_ca5x2_defconfig
> * vexpress_ca9x4_defconfig
> * vexpress_ca15_tc2_defconfig
>
> as available in Linux 5.1 rc5.
>
> We are using the vexpress_ca15_tc2_defconfig and vexpress_ca9x4_defc
On Fri, Apr 12, 2019 at 12:54:45PM -0400, Andrew F. Davis wrote:
> K3 devices have High Security (HS) variants along with the non-HS already
> supported. Like the previous generation devices (OMAP/Keystone2) K3
> supports boot chain-of-trust by authenticating and optionally decrypting
> images as
On Tue, Apr 09, 2019 at 03:38:14PM +0200, Igor Opaniuk wrote:
> AVB 2.0 spec. revision 1.1 introduces support for named persistent values
> that must be tamper evident and allows AVB to store arbitrary key-value
> pairs [1].
>
> Introduce implementation of two additional AVB operations
> read_per
On Fri, Apr 12, 2019 at 12:54:46PM -0400, Andrew F. Davis wrote:
> K3 HS devices require signed binaries for boot, use the SECDEV tools
> to sign the boot artifacts during build.
>
> Signed-off-by: Andrew F. Davis
> Reviewed-by: Tom Rini
> Reviewed-by: Andreas Dannenberg
Applied to u-boot/mas
On Fri, Apr 12, 2019 at 12:54:47PM -0400, Andrew F. Davis wrote:
> Add new defconfig files for the AM65x High Security EVM.
>
> This defconfigs are the same as for the non-secure part, except for:
> CONFIG_TI_SECURE_DEVICE option set to 'y'
> CONFIG_FIT_IMAGE_POST_PROCESS option set to 'y
On Fri, Apr 12, 2019 at 12:54:42PM -0400, Andrew F. Davis wrote:
> On HS devices the 512b region of reset isolated memory called
> MCU_PSRAM0 is firewalled by default. Until SYSFW is loaded we
> cannot use this memory. It is only used to store a single value
> left at the end of SRAM by ROM that w
On Tue, Apr 16, 2019 at 02:47:14AM +0200, Pierre Bourdon wrote:
> btrfs_search_tree should return the first item in the tree that is
> greater or equal to the searched item.
>
> The search algorithm did not properly handle the edge case where the
> searched item is higher than the last item of th
On Tue, Apr 16, 2019 at 01:31:57PM +0200, Heiko Schocher wrote:
> - at91sam9g20-taurus.dts: use labels
> - cleanup taurus port to compile clean with
> current mainline again. SPL has no serial
> output anymore, so it fits into SRAM.
>
> Signed-off-by: Heiko Schocher
This needs to be reworke
On Fri, Apr 12, 2019 at 12:54:48PM -0400, Andrew F. Davis wrote:
> Signed-off-by: Andrew F. Davis
> Reviewed-by: Tom Rini
> Reviewed-by: Andreas Dannenberg
Applied to u-boot/master, thanks!
--
Tom
signature.asc
Description: PGP signature
___
U-Bo
On Fri, Apr 12, 2019 at 12:54:44PM -0400, Andrew F. Davis wrote:
> SYSFW version 2019.01 introduces a slightly modified version of this API,
> add support for it here.
>
> Signed-off-by: Andrew F. Davis
> Reviewed-by: Tom Rini
> Reviewed-by: Andreas Dannenberg
Applied to u-boot/master, thanks
On Fri, Apr 12, 2019 at 12:54:43PM -0400, Andrew F. Davis wrote:
> TI-SCI message protocol provides support for controlling the firewall
> configurations available in SoC.
>
> Introduce support for the set of TI-SCI message protocol APIs that
> provide us with this capability of controlling firew
On Wed, Apr 10, 2019 at 06:59:26PM +0200, Heinrich Schuchardt wrote:
> %g/rathen then/rather than/
>
> Signed-off-by: Heinrich Schuchardt
Applied to u-boot/master, thanks!
--
Tom
signature.asc
Description: PGP signature
___
U-Boot mailing list
U-B
On Wed, Apr 10, 2019 at 02:13:16PM +0200, Hannes Schmelzer wrote:
> The handling of regarding bootmode and early setup has been moved to
> central location 'common/br_resetc.c', so use this on brxre1 board.
>
> Signed-off-by: Hannes Schmelzer
Applied to u-boot/master, thanks!
--
Tom
signatu
On Wed, Apr 10, 2019 at 02:13:15PM +0200, Hannes Schmelzer wrote:
> - fixup coding style
> - drop unused 'PUSH_KEY' define
>
> Signed-off-by: Hannes Schmelzer
Applied to u-boot/master, thanks!
--
Tom
signature.asc
Description: PGP signature
___
U-
On Wed, Apr 10, 2019 at 02:13:14PM +0200, Hannes Schmelzer wrote:
> On many B&R boards we have a reset-controller, responsible for very
> early board-bringup (voltages, clocks, ...) and bootmode selection.
>
> To be ready for adding more B&R boards to source tree while avoiding
> duplicate code,
On Wed, Apr 10, 2019 at 02:13:13PM +0200, Hannes Schmelzer wrote:
> Many B&R boards are equipped with an I2C-EEPROM where various
> information can be stored.
>
> Today there is only a single byte for 'board_id' used.
>
> We write this 'board_id' into environment for later use during boot.
>
>
On Wed, Apr 10, 2019 at 02:13:11PM +0200, Hannes Schmelzer wrote:
> Today the BuR common stuff is only used on AM33XX boards. In future we
> plan to have many other platforms than AM33XX so we have to move arch-
> specific #include(s) to responsible #ifdef sections. By the way we drop
> unneeded #
On Wed, Apr 10, 2019 at 02:13:12PM +0200, Hannes Schmelzer wrote:
> Signed-off-by: Hannes Schmelzer
Applied to u-boot/master, thanks!
--
Tom
signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de
On 26/04/19 10:16 PM, Tom Rini wrote:
On Fri, Apr 26, 2019 at 10:14:40PM +0530, Keerthy wrote:
On 26/04/19 6:25 PM, Tom Rini wrote:
On Fri, Apr 26, 2019 at 05:23:28PM +0530, Lokesh Vutla wrote:
On 26/04/19 4:46 PM, Tom Rini wrote:
On Fri, Apr 12, 2019 at 12:08:18PM +0530, Keerthy wrote:
On Fri, Apr 26, 2019 at 10:14:40PM +0530, Keerthy wrote:
>
>
> On 26/04/19 6:25 PM, Tom Rini wrote:
> >On Fri, Apr 26, 2019 at 05:23:28PM +0530, Lokesh Vutla wrote:
> >>
> >>
> >>On 26/04/19 4:46 PM, Tom Rini wrote:
> >>>On Fri, Apr 12, 2019 at 12:08:18PM +0530, Keerthy wrote:
> >>>
> From: B
On 26/04/19 6:25 PM, Tom Rini wrote:
On Fri, Apr 26, 2019 at 05:23:28PM +0530, Lokesh Vutla wrote:
On 26/04/19 4:46 PM, Tom Rini wrote:
On Fri, Apr 12, 2019 at 12:08:18PM +0530, Keerthy wrote:
From: Brad Griffis
In case of RTC+DDR resume, need to restore EMIF context
before initiating h
On 26/04/19 5:23 PM, Lokesh Vutla wrote:
On 26/04/19 4:46 PM, Tom Rini wrote:
On Fri, Apr 12, 2019 at 12:08:18PM +0530, Keerthy wrote:
From: Brad Griffis
In case of RTC+DDR resume, need to restore EMIF context
before initiating hardware leveling.
Signed-off-by: Brad Griffis
Signed-off-
On 26/04/19 4:46 PM, Tom Rini wrote:
On Fri, Apr 12, 2019 at 12:08:18PM +0530, Keerthy wrote:
From: Brad Griffis
In case of RTC+DDR resume, need to restore EMIF context
before initiating hardware leveling.
Signed-off-by: Brad Griffis
Signed-off-by: Keerthy
This part off the series blow
On Fri, Apr 26, 2019 at 05:23:28PM +0530, Lokesh Vutla wrote:
>
>
> On 26/04/19 4:46 PM, Tom Rini wrote:
> > On Fri, Apr 12, 2019 at 12:08:18PM +0530, Keerthy wrote:
> >
> >> From: Brad Griffis
> >>
> >> In case of RTC+DDR resume, need to restore EMIF context
> >> before initiating hardware lev
On 26/04/19 4:46 PM, Tom Rini wrote:
> On Fri, Apr 12, 2019 at 12:08:18PM +0530, Keerthy wrote:
>
>> From: Brad Griffis
>>
>> In case of RTC+DDR resume, need to restore EMIF context
>> before initiating hardware leveling.
>>
>> Signed-off-by: Brad Griffis
>> Signed-off-by: Keerthy
>
> This p
On Fri, Apr 12, 2019 at 12:08:18PM +0530, Keerthy wrote:
> From: Brad Griffis
>
> In case of RTC+DDR resume, need to restore EMIF context
> before initiating hardware leveling.
>
> Signed-off-by: Brad Griffis
> Signed-off-by: Keerthy
This part off the series blows up the AM335x and older SoC
>>> Out: serial@5a06
>>> Err: serial@5a06
>>> Net:
>>> Error: ethernet@5b04 address not set.
>>> eth-1: ethernet@5b04
>>> Hit any key to stop autoboot: 0
>>> Signed-off-by: Peng Fan
>>
>> Applied to u-boo
address not set.
> > eth-1: ethernet@5b04
> > Hit any key to stop autoboot: 0
> > Signed-off-by: Peng Fan
>
> Applied to u-boot-imx, master, thanks !
This one introduced a superfluous trailing line continuation in the
Makefile:
https://git.denx.de/?p=u-boot/
> From: Marcel Ziswiler
> Migrate USB to using driver model.
> Add USBH_PEN GPIO regulator.
> While at it also add alias e.g. as required for UMS.
> Signed-off-by: Marcel Ziswiler
> Reviewed-by: Igor Opaniuk
Applied to u-boot-imx, master, thanks !
Best regards,
Stefano Babic
--
=
> Introduce basic dtsi for i.MX8QM, only support SDHC/FEC/LPUART.
> Signed-off-by: Peng Fan
Applied to u-boot-imx, master, thanks !
Best regards,
Stefano Babic
--
=
DENX Software Engineering GmbH, Managing Director: Wolfg
> From: Marcel Ziswiler
> The implicit fallback mechanism for searching the whole MDIO bus for at
> least one PHY has been gone with the following commit b882005a18de
> ("drivers/net/fec: phy_init: remove redundant logic"). This lead to the
> Ethernet driver erroring out as follows:
> Net: Could
> This patch enable convert DM MMC for imx7d-pico board and variant.
> Before the DM conversion only usdhc3 was enabled and therefore it appeared
> as MMC 0 to u-boot. After enabling MMC DM though usdhc3 defaults to MMC 2,
> which left unattended would drive changes to existing pico-pi bootscripts
> From: Marcel Ziswiler
> Add support for lpuart1, lpuart2 and lpuart3.
> Signed-off-by: Marcel Ziswiler
> Reviewed-by: Peng Fan
> Reviewed-by: Igor Opaniuk
Applied to u-boot-imx, master, thanks !
Best regards,
Stefano Babic
--
===
> Move HUSH_PARSER to defconfig, otherwise meet
> "
> => run netboot
> Booting from net ...
> Unknown command 'if' - try 'help'
> Unknown command 'then' - try 'help'
> Unknown command 'else' - try 'help'
> Unknown command 'fi' - try 'help'
> Unknown command '0x8028' - try 'help'
> Unknown comma
> After unification of the rootfs for both HSC and DDC devices, only one,
> common wic file is necessary - without the distinction of specific board.
> Signed-off-by: Lukasz Majewski
Applied to u-boot-imx, master, thanks !
Best regards,
Stefano Babic
--
> From: Stefan Agner
> Using CPU temperature grading as a discriminator if the Wi-Fi /
> Bluetooth chip is populated is no longer possible due to upcoming
> SKUs. Set variant to -wifi only if a valid config block is present
> and the product id mentions a SKU with Wi-Fi / Bluetooth.
> Signed-off-b
> Add i.MX8QM entry
> Signed-off-by: Peng Fan
Applied to u-boot-imx, master, thanks !
Best regards,
Stefano Babic
--
=
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr
> To make it easy to add new clk driver for i.MX8, split
> the code into common part and SoC specific part.
> Make the get/set/enable non static and introduce a num_clks for
> soc_clk_dump, because the arrays are moved to clk-imx8qxp.c.
> Signed-off-by: Peng Fan
Applied to u-boot-imx, master, tha
201 - 300 of 15076 matches
Mail list logo
