Hi Tom,
On 09/03/2018 21:42, Tom Rini wrote:
> On Fri, Mar 09, 2018 at 01:10:53PM +0100, Stefano Babic wrote:
>
>> Hi Tom,
>>
>> as discussed: this contains two fixes that should go into release - thanks !
>>
>>
>> The following changes since commit 5e62f828256d66e2b28def4f9ef20a2a05c2d04f:
>>
Hi Grygorii,
El 09/03/2018 a las 0:07, Grygorii Strashko escribió:
Hi Álvaro,
On 03/05/2018 02:05 PM, Álvaro Fernández Rojas wrote:
This adds channels support for dma controllers that have multiple channels
which can transfer data to/from different devices (enet, usb...).
Signed-off-by:
On 03/09/2018 07:51 AM, Patrick Brünn wrote:
From: Patrick Brünn
Sent: Donnerstag, 8. März 2018 06:39
From: Jaehoon Chung [mailto:jh80.ch...@samsung.com]
Sent: Donnerstag, 8. März 2018 04:57
On 03/08/2018 12:12 PM, Marek Vasut wrote:
On 03/08/2018 03:17 AM, Jaehoon Chung wrote:
On 03/06/2018
On Fri, Mar 09, 2018 at 01:10:53PM +0100, Stefano Babic wrote:
> Hi Tom,
>
> as discussed: this contains two fixes that should go into release - thanks !
>
>
> The following changes since commit 5e62f828256d66e2b28def4f9ef20a2a05c2d04f:
>
> Prepare v2018.03-rc4 (2018-03-05 20:27:08 -0500)
>
On Mon, Mar 05, 2018 at 11:20:41PM +0200, Tuomas Tynkkynen wrote:
> CONFIG_SYS_CBSIZE determines the maximum length of the kernel command
> line, and the default value of 256 is too small for booting some Linux
> images in the wild.
>
> Signed-off-by: Tuomas Tynkkynen
On Tue, Mar 06, 2018 at 01:46:37AM +0200, Tuomas Tynkkynen wrote:
> The following config symbols are only defined once and never referenced
> anywhere else:
>
> CONFIG_DBAU1X00
> CONFIG_PB1X00
>
> Most of them are config symbols named after the respective boards which
> seems to have been a
On Tue, Mar 06, 2018 at 01:46:38AM +0200, Tuomas Tynkkynen wrote:
> The following config symbols are only defined once and never referenced
> anywhere else:
>
> CONFIG_ARM926EJS
> CONFIG_CPUAT91
> CONFIG_EXYNOS5800
> CONFIG_SYS_CORTEX_R4
>
> Most of them are config symbols named after the
On Tue, Mar 06, 2018 at 01:46:39AM +0200, Tuomas Tynkkynen wrote:
> The following config symbols are only defined once and never referenced
> anywhere else:
>
> CONFIG_AT91SAM9263EK
> CONFIG_AT91SAM9RLEK
> CONFIG_BARIX_IPAM390
> CONFIG_BOARD_H2200
> CONFIG_EP9301
> CONFIG_KZM_A9_GT
>
On Wed, Mar 07, 2018 at 04:04:29AM +0100, Heinrich Schuchardt wrote:
> NETWORK should be after NAND_FLASH.
>
> Signed-off-by: Heinrich Schuchardt
Applied to u-boot/master, thanks!
--
Tom
signature.asc
Description: PGP signature
On Thu, Mar 08, 2018 at 09:00:13AM +0100, Stefan Theil wrote:
> The system call used by mkimage to run dtc redirects stdout to a
> temporary file. This can cause problems on Windows (with a MinGW
> cross-compiled version). Using the "-o" dtc parameter avoids
> this problem.
>
> Signed-off-by:
On Thu, Mar 08, 2018 at 08:56:17PM +0100, Heinrich Schuchardt wrote:
> kmerr: verify that malloc and calloc are followed by a check to verify
> that we are not out of memory.
>
> badzero: Compare pointer-typed values to NULL rather than 0
>
> Both checks are copied from the Linux kernel
On Wed, Mar 07, 2018 at 10:08:25PM +0100, Alexander Graf wrote:
> After the UART was initialized, we may still have bogus data in the
> RX queue if it was enabled with incorrect pin muxing before.
>
> So let's flush the RX queue whenever we initialize baud rates.
>
> This fixes a regression
On Wed, Mar 07, 2018 at 10:08:24PM +0100, Alexander Graf wrote:
> After the UART was initialized, we may still have bogus data in the
> RX queue if it was enabled with incorrect pin muxing before.
>
> So let's flush the RX queue whenever we initialize baud rates.
>
> This fixes a regression
On Tue, Mar 06, 2018 at 08:04:58AM +0100, Mario Six wrote:
> From: Mario Six
>
> The @gdsys.cc addresses are supposed to be used for mailing lists.
> Switch all occurrences of @gdsys.de mail addresses to their @gdsys.cc
> equivalent.
>
> Also, Dirk's address was wrong in one
On 03/09/2018 09:24 AM, Jaehoon Chung wrote:
Dear Patrick,
On 03/09/2018 03:51 PM, Patrick Brünn wrote:
From: Patrick Brünn
Sent: Donnerstag, 8. März 2018 06:39
From: Jaehoon Chung [mailto:jh80.ch...@samsung.com]
Sent: Donnerstag, 8. März 2018 04:57
On 03/08/2018 12:12 PM, Marek Vasut wrote:
On Thu, Mar 08, 2018 at 10:52:29PM +0100, Heinrich Schuchardt wrote:
> The iterator of list_for_each() is never NULL.
>
> Identified with coccinelle.
>
> Signed-off-by: Heinrich Schuchardt
Applied to u-boot/master, thanks!
--
Tom
signature.asc
Description: PGP
On Thu, Mar 08, 2018 at 12:26:08AM +0100, Marek Behún wrote:
> Other filesystem drivers don't do this.
>
> Signed-off-by: Marek Behun
Applied to u-boot/master, thanks!
--
Tom
signature.asc
Description: PGP signature
___
U-Boot
Hi Bryan,
On Fri, Mar 9, 2018 at 10:07 AM, Bryan O'Donoghue
wrote:
> commit 8c4037a09a5c ("imx: hab: Ensure the IVT DCD pointer is Null prior
> to calling HAB authenticate function.") makes the DCD field being NULL a
> dependency.
>
> This change though will break
From: Ye Li
When using ethernet DM driver, the recv interface has a
change with non-DM interface, that driver needs to set
the packet pointer and provide it to upper layer to process.
In fec driver, the fecmxc_recv functions does not handle the
packet pointer parameter. This may
On Sat, Mar 10, 2018 at 7:16 AM, Fabio Estevam wrote:
> Hi Jagan,
>
> On Fri, Mar 9, 2018 at 9:09 AM, Jagan Teki wrote:
>
>> Do you have a partition table details, I'm trying GPT as below
>
> Here is the partition scheme that Shawn used in his test:
On Fri, Mar 9, 2018 at 10:07 AM, Bryan O'Donoghue
wrote:
> commit cd2d46003ce1 ("arm: imx: hab: Add IVT header definitions") declares
> struct ivt_header as "__attribute__((packed))".
>
> commit ed286bc80e9d ("imx: hab: Check if CSF is valid before
> authenticating
On Fri, Mar 9, 2018 at 10:07 AM, Bryan O'Donoghue
wrote:
> commit ed286bc80e9d ("imx: hab: Check if CSF is valid before authenticating
> image") makes use of "__packed" as a prefix to the "struct hab_hdr"
> declaration.
>
> With my compiler "gcc version 7.2.1 20171011
Hi Bryan,
2018-03-09 10:07 GMT-03:00 Bryan O'Donoghue :
> commit 8c4037a09a5c ("imx: hab: Ensure the IVT DCD pointer is Null prior
> to calling HAB authenticate function.") makes the DCD field being NULL a
> dependency.
>
> This change though will break loading and
Hi Jagan,
On Fri, Mar 9, 2018 at 9:09 AM, Jagan Teki wrote:
> Do you have a partition table details, I'm trying GPT as below
Here is the partition scheme that Shawn used in his test:
https://patchwork.ozlabs.org/patch/867705/
Add i.MX6UL/SX/SL compatible.
Signed-off-by: Peng Fan
---
drivers/net/fec_mxc.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/net/fec_mxc.c b/drivers/net/fec_mxc.c
index e8f8fef66a..ffe3bae59f 100644
--- a/drivers/net/fec_mxc.c
+++ b/drivers/net/fec_mxc.c
@@
On i.MX6SX, 6UL and 7D, there are two enet controllers each has a
MDIO port. But Some boards share one MDIO port for the two enets. So
introduce a configuration CONFIG_FEC_MXC_MDIO_BASE to indicate
the MDIO port for sharing.
Signed-off-by: Peng Fan
---
drivers/net/Kconfig |
No need to provide two prototype for this function.
Use ulong for the first parameter, then this function
could be shared for DM/non DM case.
Signed-off-by: Peng Fan
---
drivers/net/fec_mxc.c | 13 ++---
include/netdev.h | 6 +-
2 files changed, 3
To platforms has two enet interface, using dev->seq could
avoid conflict.
i.MX6UL/ULL evk board net get the wrong MAC address from fuse,
eth1 get MAC0 address, eth0 get MAC1 address from fuse. Set the
priv->dev_id to device->seq as the real net interface alias id then
.fec_get_hwaddr() read the
Hi Stefano,
On Fri, Mar 9, 2018 at 6:20 PM, Stefano Babic wrote:
> Yes, I saw Brian's post for HAB, and there are a couple from Jagan that
> I'll pick up. I will send a new PR, then.
Patches 1/3 and 2/3 from Bryan look good.
We have some concerns about patch 3/3 and Breno will
Sometimes imximage throws the following error:
CFGSboard/freescale/vf610twr/imximage.cfg.cfgtmp
CFGSboard/freescale/vf610twr/imximage.cfg.cfgtmp
MKIMAGE u-boot-dtb.imx
Error: No BOOT_FROM tag in board/freescale/vf610twr/imximage.cfg.cfgtmp
arch/arm/mach-imx/Makefile:100: recipe for
Hi Tom,
as discussed: this contains two fixes that should go into release - thanks !
The following changes since commit 5e62f828256d66e2b28def4f9ef20a2a05c2d04f:
Prepare v2018.03-rc4 (2018-03-05 20:27:08 -0500)
are available in the git repository at:
git://www.denx.de/git/u-boot-imx.git
Pass tools/env/fw_env.c through indent to correct style violations. This
commit consists of only one non-whitespace change:
tools/env/fw_env.c:549: error: do not use assignment in if condition
Signed-off-by: Alex Kiernan
---
Changes in v2:
- Clean style violations in
Replace HaveRedundEnv with have_redund_env to fix style violation.
Signed-off-by: Alex Kiernan
---
Changes in v2:
- new
tools/env/fw_env.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/tools/env/fw_env.c b/tools/env/fw_env.c
Extract write path of flash_io() into a separate function. This patch
should be a functional no-op.
Signed-off-by: Alex Kiernan
Reviewed-by: Stefano Babic
---
Changes in v2:
- Acommodate white space changes from predecessor commit
tools/env/fw_env.c |
On Fri, Mar 09, 2018 at 08:53:40AM +0100, Miquel Raynal wrote:
> Hi Tom,
>
> On Thu, 8 Mar 2018 12:20:30 -0500, Tom Rini wrote:
>
> > On Thu, Mar 08, 2018 at 04:40:03PM +0100, Miquel Raynal wrote:
> >
> > > Current U-Boot supports TPM v1.2 specification. The new
Dear Wolfgang,
On 9.3.2018 13:02, Wolfgang Denk wrote:
> Dear Michal,
>
> In message you wrote:
>>
>> We are not seeing any issue from u-boot code itself and I can believe
>> that structures and accesses are aligned properly.
>>
>> The initial
On 9.3.2018 13:23, Mark Kettenis wrote:
>> From: Wolfgang Denk
>> Date: Fri, 09 Mar 2018 12:26:01 +0100
>>
>> Dear Michal,
>>
>> In message you wrote:
>>>
Can you please add some comments what the consequences of this
From: Fabio Estevam
Sometimes imximage throws the following error:
CFGSboard/freescale/vf610twr/imximage.cfg.cfgtmp
CFGSboard/freescale/vf610twr/imximage.cfg.cfgtmp
MKIMAGE u-boot-dtb.imx
Error: No BOOT_FROM tag in
Dear Michal,
In message you wrote:
>
> > Can you please add some comments what the consequences of this
> > change are? I guess there are advantages, but I also guess these
> > come at a price?
>
> That's something what I am expecting from this
Dear Michal,
In message you wrote:
>
> We are not seeing any issue from u-boot code itself and I can believe
> that structures and accesses are aligned properly.
>
> The initial reason was that u-boot allows you to run for example command
> md 1
Hi Stefano,
On Tue, Mar 6, 2018 at 6:45 PM, Fabio Estevam wrote:
> On Tue, Mar 6, 2018 at 8:45 AM, Jagan Teki wrote:
>> This patch fixes the wrongly included dtsi file which was
>> breaking mainline support for Engicam i.CoreM6 DualLite/Solo RQS.
>>
If the U-Boot environment is stored in a regular file and redundant
operation isn't set, then write to a temporary file and perform an
atomic rename.
Signed-off-by: Alex Kiernan
---
Changes in v2:
- Use mkstemp() to create temporary filename, not a fixed one
Dear Alex,
In message <1520597582-12979-1-git-send-email-alex.kier...@gmail.com> you wrote:
>
> For environments stored on filesystems where you can't have a redundant
> configuration, rather than just over-writing the existing environment
> in fw_setenv, do the tradtional create temporary file,
Hi Tom,
Fabio fixed a build issue yesterday. It is just a single patch, but it
should be flow into the release. You can pick it udirectly p, but I have
also applied to u-boot-imx to make things easier.
The following changes since commit
5e62f828256d66e2b28def4f9ef20a2a05c2d04f:
Prepare
On Fri, Mar 9, 2018 at 10:03 AM, Stefano Babic wrote:
> On 09/03/2018 10:54, Alex Kiernan wrote:
>> On Thu, Mar 8, 2018 at 5:04 PM, Stefano Babic wrote:
>>> Hi alex,
>>>
>>> On 08/03/2018 12:52, Alex Kiernan wrote:
If the U-Boot environment is stored in a
[Adding Stefano]
On Thu, Mar 8, 2018 at 1:21 AM, Yasushi SHOJI wrote:
> Without the volatile attribute, compilers are entitled to optimize out
> the same asm(). In the case of __udelay() in syscounter.c, it calls
> `get_ticks()` twice, one for the starting time and the
Hi Stefano,
On Fri, Mar 9, 2018 at 8:11 AM, Stefano Babic wrote:
If you like I can resent a v2 of option 1 where the error message is removed.
>
> It is a hack, but we can do just for the release. I have already applied
> V1, I will drop it from u-boot-imx. I will also apply
>From: Patrick Brünn
>Sent: Donnerstag, 8. März 2018 06:39
>>From: Jaehoon Chung [mailto:jh80.ch...@samsung.com]
>>Sent: Donnerstag, 8. März 2018 04:57
>>On 03/08/2018 12:12 PM, Marek Vasut wrote:
>>> On 03/08/2018 03:17 AM, Jaehoon Chung wrote:
On 03/06/2018 05:07 PM,
Hi Fabio,
On Sun, Feb 18, 2018 at 3:14 AM, Fabio Estevam wrote:
> From: Fabio Estevam
>
> With fastboot support enabled, it is useful to be able to list
> the eMMC EFI partitions, so select the CONFIG_EFI_PARTITION option.
>
> Signed-off-by: Fabio
For environments stored on filesystems where you can't have a redundant
configuration, rather than just over-writing the existing environment
in fw_setenv, do the tradtional create temporary file, rename, sync,
sync directory dance to achieve ACID semantics when writing through
fw_setenv.
> From: Wolfgang Denk
> Date: Fri, 09 Mar 2018 12:26:01 +0100
>
> Dear Michal,
>
> In message you wrote:
> >
> > > Can you please add some comments what the consequences of this
> > > change are? I guess there are advantages, but
Hi Stefano,
On Fri, Mar 9, 2018 at 7:13 AM, Stefano Babic wrote:
> Hi Tom,
>
> Fabio fixed a build issue yesterday. It is just a single patch, but it
> should be flow into the release. You can pick it udirectly p, but I have
> also applied to u-boot-imx to make things easier.
Hi Fabio,
On 09/03/2018 11:42, Fabio Estevam wrote:
> Hi Stefano,
>
> On Fri, Mar 9, 2018 at 7:13 AM, Stefano Babic wrote:
>> Hi Tom,
>>
>> Fabio fixed a build issue yesterday. It is just a single patch, but it
>> should be flow into the release. You can pick it udirectly p, but
Dear Wolfgang,
On 9.3.2018 12:26, Wolfgang Denk wrote:
> Dear Michal,
>
> In message you wrote:
>>
>>> Can you please add some comments what the consequences of this
>>> change are? I guess there are advantages, but I also guess these
>>> come
On 09/03/2018 11:46, Fabio Estevam wrote:
> [Adding Stefano]
>
> On Thu, Mar 8, 2018 at 1:21 AM, Yasushi SHOJI wrote:
>> Without the volatile attribute, compilers are entitled to optimize out
>> the same asm(). In the case of __udelay() in syscounter.c, it calls
>>
On 09/03/2018 12:25, Fabio Estevam wrote:
> From: Fabio Estevam
>
> Sometimes imximage throws the following error:
>
> CFGSboard/freescale/vf610twr/imximage.cfg.cfgtmp
> CFGSboard/freescale/vf610twr/imximage.cfg.cfgtmp
> MKIMAGE u-boot-dtb.imx
> Error: No
Hi,
On Fri, Mar 02, 2018 at 04:24:22PM +, Andre Przywara wrote:
> On 02/03/18 15:58, Maxime Ripard wrote:
> > On Fri, Mar 02, 2018 at 12:56:52AM +, Andre Przywara wrote:
> >> Linux kernels before 4.12-rc1 don't know about the AXP803 PMIC, so can't
> >> enable the MMC driver with the
Dear Patrick,
On 03/09/2018 03:51 PM, Patrick Brünn wrote:
>> From: Patrick Brünn
>> Sent: Donnerstag, 8. März 2018 06:39
>>> From: Jaehoon Chung [mailto:jh80.ch...@samsung.com]
>>> Sent: Donnerstag, 8. März 2018 04:57
>>> On 03/08/2018 12:12 PM, Marek Vasut wrote:
On 03/08/2018 03:17 AM,
Hi,
On Wed, Mar 7, 2018 at 11:27 PM, Tom Rini wrote:
> On Wed, Mar 07, 2018 at 10:42:44AM -0300, Fabio Estevam wrote:
>> Patch looks good. Make sure to add your Signed-off-by line, then you
>> can send it via git send-email.
>
> Yes please, thanks!
I've sent it to you with
On 09/03/2018 10:54, Alex Kiernan wrote:
> On Thu, Mar 8, 2018 at 5:04 PM, Stefano Babic wrote:
>> Hi alex,
>>
>> On 08/03/2018 12:52, Alex Kiernan wrote:
>>> If the U-Boot environment is stored in a regular file and redundant
>>> operation isn't set, then write to a temporary
On Thu, Mar 8, 2018 at 5:04 PM, Stefano Babic wrote:
> Hi alex,
>
> On 08/03/2018 12:52, Alex Kiernan wrote:
>> If the U-Boot environment is stored in a regular file and redundant
>> operation isn't set, then write to a temporary file and perform an
>> atomic rename.
>>
>
> Even
This patch adds code to lib to enable sharing of useful OPTEE code between
board-ports and architectures. The code on lib/optee/optee.c comes from the
TI omap2 port. Eventually the OMAP2 code will be patched to include the
shared code. The intention here is to add more useful OPTEE specific code
v5:
This patchset now works by making a bootable OPTEE image
mkimage -A arm -T kernel -O tee -C none -d tee.bin uTee.optee
The concept is the same as the earlier version of this patchset except
instead of "mkimage -T tee" we do "mkimage -T kernel -O tee". Andrew
suggested this and it is
Add a helper function for extracting the least significant 32 bits from the
OPTEE entry point address, which will be good enough to load OPTEE binaries
up to (2^32)-1 bytes.
We may need to extend this out later on but for now (2^32)-1 should be
fine.
Signed-off-by: Bryan O'Donoghue
OPTEE is currently linked to a specific area of memory called the TrustZone
DRAM. This patch adds a CONFIG entry for the default size of TrustZone DRAM
that a board-port can over-ride. The region that U-Boot sets aside for the
OPTEE run-time should be verified before attempting to hand off to the
This patch adds a new type IH_OS_TEE. This new OS type will be used for
chain-loading to Linux via a TEE.
With this patch in-place you can generate a bootable OPTEE image like this:
mkimage -A arm -T kernel -O tee -C none -d tee.bin uTee.optee
where "tee.bin" is the input binary prefixed with
OPTEE is currently linked to a specific area of memory called the TrustZone
DRAM. This patch adds a CONFIG entry for the default address of TrustZone
DRAM that a board-port can over-ride. The region that U-Boot sets aside for
the OPTEE run-time should be verified before attempting to hand off to
When encountering an error in OPTEE verification print out various details
of the OPTEE header to aid in further debugging of encountered errors.
Signed-off-by: Bryan O'Donoghue
Cc: Harinarayan Bhatta
Cc: Andrew F. Davis
Cc: Tom Rini
This patch adds optee_verify_bootm_image() which will be subsequently used
to verify the parameters encoded in the OPTEE header match the memory
allocated to the OPTEE region, OPTEE header magic and version prior to
handing off control to the OPTEE image.
Signed-off-by: Bryan O'Donoghue
This patch adds optee_image_get_load_addr() a helper function used to
calculate the load-address of an OPTEE image based on the lower
entry-point address given in the OPTEE header.
Signed-off-by: Bryan O'Donoghue
Cc: Harinarayan Bhatta
Cc: Andrew
CONFIG_OPTEE_LOAD_ADDR is used to tell u-boot where to load the OPTEE
binary into memory prior to handing off control to OPTEE.
We need to pull this value out of u-boot in order to produce an IMX IVT/CSF
signed pair for the purposes of secure boot. The best way to do that is to
have
This patch makes it possible to verify the contents and location of an
OPTEE image in DRAM prior to handing off control to that image. If image
verification fails we won't try to boot any further.
Signed-off-by: Bryan O'Donoghue
Suggested-by: Andrew F. Davis
On Fri, Mar 9, 2018 at 12:30 PM, Wolfgang Denk wrote:
> Dear Alex,
>
> In message <1520597582-12979-1-git-send-email-alex.kier...@gmail.com> you
> wrote:
>>
>> For environments stored on filesystems where you can't have a redundant
>> configuration, rather than just over-writing
commit 8c4037a09a5c ("imx: hab: Ensure the IVT DCD pointer is Null prior
to calling HAB authenticate function.") makes the DCD field being NULL a
dependency.
This change though will break loading and executing of existing pre-signed
binaries on a u-boot update i.e. if this change is deployed on a
This set fixes a few errors and gotchas I've found when rebasing my project
on top of 2018-rc4.
First is a breakage with the Linaro compiler -> gcc-linaro-7.2.1 which is a
simple one.
Second is consistency of the __packed attribute - more of a housekeeping
activity.
Last patch fixes a behaviour
On 03/03/2018 03:52 PM, Heinrich Schuchardt wrote:
From: Leif Lindholm
Not complete, but enough for Shell.efi and SCT.efi. We'll implement the
rest as needed or once we have SCT running properly so there is a way to
validate the interface against the conformance test
On 03/03/2018 03:48 PM, Heinrich Schuchardt wrote:
When running on the sandbox the stack is not necessarily at a higher memory
address than the highest free memory.
There is no reason why the checking of the highest memory address should be
more restrictive for EFI_ALLOCATE_ANY_PAGES than for
On Thu, Mar 08, 2018 at 09:57:58AM +0900, Masahiro Yamada wrote:
> 2018-03-07 23:45 GMT+09:00 Tom Rini :
> > On Wed, Mar 07, 2018 at 03:28:20PM +0100, Patrick Delaunay wrote:
> >
> >> avoid warning: no previous prototype for ‘mach_cpu_init’
> >>
> >> Signed-off-by: Patrick
On 03/03/2018 03:41 PM, Heinrich Schuchardt wrote:
The console control protocol is not defined in the UEFI standard.
It exists in EDK2's EdkCompatiblityPkg package. But this package
is deprecated according to
From: Ian Ray
Enable display backlight only if a message needs to be displayed.
The kernel re-initializes the backlight, which results in some
unwanted artifacts.
Signed-off-by: Ian Ray
Signed-off-by: Sebastian Reichel
---
The "net_try_count" counter starts from "1".
And the "retrycnt" contains requested amount of retries.
With current logic, that means that the actual retry amount
will be one time less then what we set in "netretry" env.
For example setting "netretry" to "once" will make "retrycnt"
equal "1", so
On 06/03/18 01:28, Tom Rini wrote:
Hey all,
It's release day and I've released v2018.03-rc4. I've included a few
different regression fixes I've seen along with some fixes and cleanups.
I would like to do the release on March 12th, and likely will so long as
no big regressions show up. I am
On Mon, Mar 05, 2018 at 02:57:26PM -0600, Adam Ford wrote:
> There are several items in the whitelist which don't appear to be
> used anywhere outside of the whitelist itself. These include:
>
> CONFIG_IMX_NAND
> CONFIG_MXS_AUART
> CONFIG_MXS_AUART_BASE
> CONFIG_NORFLASH_PS32BIT
> CONFIG_QSPI
>
On 03/09/2018 02:23 PM, Alexander Graf wrote:
> On 03/03/2018 03:41 PM, Heinrich Schuchardt wrote:
>> The console control protocol is not defined in the UEFI standard.
>>
>> It exists in EDK2's EdkCompatiblityPkg package. But this package
>> is deprecated according to
>>
Add a new file init.h with the prototype for arch_cpu_init
Add a prototype for mach_cpu_init() to avoid a warning:
no previous prototype for ‘mach_cpu_init’
It is a first step to move all the functions prototype
used during U-Boot initialization (board_f.c / board_r.c)
from common.h to init.h
Subsequent patches will want to include hab.h but in doing so include it on
an assembly compile path causing a range of compile errors. Fix the errors
pre-emptively by encasing the majority of the declarations in hab.h inside
an ifdef __ASSEMBLY__ block.
Signed-off-by: Bryan O'Donoghue
This patch adds IVT_PAD_SIZE at 0xC00. The IVT header is padded to this
size. Defining the size explicitly makes it possible to use the define to
locate the start/end of an IVT header without using magic numbers in code.
Signed-off-by: Bryan O'Donoghue
Cc: Utkarsh
On Sat, 3 Mar 2018 10:30:17 +0100
Heinrich Schuchardt xypron.g...@gmx.de wrote:
> Inform the EFI subsystem that the framebuffer memory is reserved.
>
> Without the patch the AllocatePool boot service allocates memory from the
> framebuffer which will will be overwritten by screen output.
>
>
On Fri, 9 Mar 2018 16:49:49 +0100
Heinrich Schuchardt xypron.g...@gmx.de wrote:
...
> If efi_allocate_memory is called with type = EFI_ALLOCATE_MAX_ADDRESS we
> can already have an error. So, please, put the patch into your v2018.05
> queue. There is no need to wait for Alex.
okay, done.
--
Greetings.
This set adds some helper functions as a pre-cursor to an upcoming set of
changes to a BSP adding scripted HAB authentication.
Calculating a HAB IVT address based on a base address and a +/- offset is a
trivial but, useful function for HAB. It means you can have a load address
for a
This patch adds hab_auth_img_or_fail() a command line function that
encapsulates a common usage of authenticate and failover, namely if
authenticate image fails, then drop to BootROM USB recovery mode.
For secure-boot systems, this type of locked down behavior is important to
ensure no unsigned
I have an ARM CPU on a board that has 3 optional sub boards plugged into it,
all of which have 3 hardware rev bits connected to the CPU
Rather than getting the CPU to do mmap type stuff or sys/class/gpio stuff to
read those versions in the kernel, is there a way for u-boot to push that
On 03/09/2018 01:48 PM, Alexander Graf wrote:
> On 03/03/2018 03:48 PM, Heinrich Schuchardt wrote:
>> When running on the sandbox the stack is not necessarily at a higher
>> memory
>> address than the highest free memory.
>>
>> There is no reason why the checking of the highest memory address
>>
On Wed, 7 Mar 2018 22:08:25 +0100
Alexander Graf wrote:
> After the UART was initialized, we may still have bogus data in the
> RX queue if it was enabled with incorrect pin muxing before.
>
> So let's flush the RX queue whenever we initialize baud rates.
>
> This fixes a
On Wed, 7 Mar 2018 22:08:24 +0100
Alexander Graf wrote:
> After the UART was initialized, we may still have bogus data in the
> RX queue if it was enabled with incorrect pin muxing before.
>
> So let's flush the RX queue whenever we initialize baud rates.
>
> This fixes a
From: Leif Lindholm
Not complete, but enough for Shell.efi and SCT.efi. We'll implement the
rest as needed or once we have SCT running properly so there is a way to
validate the interface against the conformance test suite.
Initial skeleton written by Leif, and then
On 03/06/2018 11:21 AM, Anatolij Gustschin wrote:
> Hello Heinrich,
>
> On Mon, 5 Mar 2018 17:55:52 +0100
> Heinrich Schuchardt xypron.g...@gmx.de wrote:
> ...
>> v2018.05 is fine. The problem will become visible in more cases with
>>
>> [PATCH 1/1] efi_loader: efi_allocate_pages is too
On 03/09/2018 04:58 PM, Heinrich Schuchardt wrote:
On 03/09/2018 01:48 PM, Alexander Graf wrote:
On 03/03/2018 03:48 PM, Heinrich Schuchardt wrote:
When running on the sandbox the stack is not necessarily at a higher
memory
address than the highest free memory.
There is no reason why the
On 03/09/2018 05:19 PM, Alexander Graf wrote:
> On 03/09/2018 04:58 PM, Heinrich Schuchardt wrote:
>> On 03/09/2018 01:48 PM, Alexander Graf wrote:
>>> On 03/03/2018 03:48 PM, Heinrich Schuchardt wrote:
When running on the sandbox the stack is not necessarily at a higher
memory
99 matches
Mail list logo