> Subject: [PATCH v4 09/13] dm: clk: Define clk_get_by_id() for clk operations
>
> This commit adds the clk_get_by_id() function, which is responsible for
> getting
> the udevice with matching clk->id. Such approach allows re-usage of inherit
> DM list relationship for the same class
> Subject: [PATCH v4 07/13] dm: clk: Define clk_get_parent() for clk operations
>
> This commit adds the clk_get_parent() function, which is responsible for
> getting the parent's struct clock pointer.
>
> U-boot's DM support for getting parent is different (the parent relationship
> is
> in
> Subject: [PATCH v4 08/13] dm: clk: Define clk_get_parent_rate() for clk
> operations
>
> This commit adds the clk_get_parent_rate() function, which is responsible for
> getting the rate of parent clock.
> Unfortunately, u-boot's DM support for getting parent is different (the parent
>
> Subject: Re: [U-Boot] [PATCH v4 07/13] dm: clk: Define clk_get_parent() for
> clk operations
>
>
>
> > -Original Message-
> > From: Lukasz Majewski [mailto:lu...@denx.de]
> > Sent: 2019年5月17日 6:11
> > To: Stefano Babic ; Fabio Estevam
> > ; Marek Vasut ; Simon Glass
> > ; Tom Rini ;
>
> Subject: [PATCH v4 06/13] clk: Provide struct clk for fixed rate clock
> (clk_fixed_rate.c)
>
> Up till now the fixed rate clock ('osc') has been added to UCLASS_CLK without
> declaring struct clk. As a result it was only accessible by iterating the
> udevice's uclass list.
>
> This is a
> Subject: [PATCH v4 05/13] clk: Extend struct clk to provide clock type
> agnostic
> flags
>
> This commit extends the struct clk to provide information regarding the flags
> related to this devices.
>
> Those flags are clk device agnostic and indicate generic features (like e.g.
>
> Subject: [PATCH v4 03/13] clk: Remove clock ID check in .get_rate() of
> clk_fixed_*
>
> This check requires the struct clk passed to .get_rate() to be always cleared
> out as any clock with valid ID causes -EINVAL return value.
>
> The return code of fixed clocks shall always be returned.
>
> Subject: [PATCH v4 02/13] dm: Fix documentation entry as there is no
> UCLASS_CLOCK uclass
>
> There is no UCLASS_CLOCK uclass defined. Instead we do use the
> UCLASS_CLK.
>
> Signed-off-by: Lukasz Majewski
> Reviewed-by: Simon Glass
>
> ---
>
> Changes in v4:
> - None
>
> Changes in v3:
> -Original Message-
> From: Lukasz Majewski [mailto:lu...@denx.de]
> Sent: 2019年5月17日 6:11
> To: Stefano Babic ; Fabio Estevam ;
> Marek Vasut ; Simon Glass ; Tom Rini
> ; u-boot@lists.denx.de; Jagan Teki
> ; Peng Fan ; Marcel
> Ziswiler ; Adam Ford
> Cc: Lukasz Majewski ; Neil
Will these changes be on U-Boot repository?
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
hi, Heiko Schocher
> -Original Message-
> From: Heiko Schocher
> Sent: 2019年5月17日 11:33
> To: Chuanhua Han
> Cc: U-Boot-Denx
> Subject: [EXT] Re: The CONFIG_DM_I2C_COMPAT option is not available
>
> Caution: EXT Email
>
> Hello Chuanhua Han,
>
> Am 16.05.2019 um 13:44 schrieb
Hello Chuanhua Han,
Am 16.05.2019 um 13:44 schrieb Chuanhua Han:
hi, Heiko Schocher
Some soc related files use i2c_read, i2c_write similar function interface,
if you do not use the CONFIG_DM_I2C_COMPAT option to compile,
there will be a function undefined compilation error,
For which
Hi Bin,
> -Original Message-
> From: Bin Meng
> Sent: 2019年5月16日 20:10
> To: Andy Tang ; Simon Glass ;
> Tom Rini
> Cc: Prabhakar Kushwaha ; Sudhanshu
> Gupta ; U-Boot Mailing List
> ; Ran Wang ; Bhaskar
> Upadhaya
> Subject: [EXT] Re: [U-Boot] [PATCH 1/3 v3] armv8: ls1028a: Add NXP
Hi Lukasz,
On Fri, May 17, 2019 at 6:16 AM Lukasz Majewski wrote:
>
> This commit brings the files from Linux kernel to provide clocks support
> as it is used on the Linux kernel with common clock framework [CCF] setup.
>
> The directory structure has been preserved. The ported code only
On Wed, 15 May 2019 at 16:30, Julius Werner wrote:
>
> This patch adds support for compressing non-kernel image nodes in a FIT
> image (kernel nodes could already be compressed previously). This can
> reduce the size of FIT images and therefore improve boot times
> (especially when an image
On Wed, 15 May 2019 at 16:30, Julius Werner wrote:
>
> This patch adds support for an optional optimization to compatible
> string matching where the compatible string property from the root node
> of the kernel FDT can be copied into the configuration node of the FIT
> image. This is most useful
Hi Xiaowei,
On Fri, May 17, 2019 at 10:23 AM Xiaowei Bao wrote:
>
>
>
> -Original Message-
> From: Bin Meng
> Sent: 2019年5月16日 19:58
> To: Xiaowei Bao
> Cc: M.h. Lian ; Z.q. Hou ;
> Mingkai Hu ; Hongbo Wang ; York Sun
> ; u-boot@lists.denx.de; Jiafei Pan
> Subject: [EXT] Re:
> Subject: Re: Cannot boot mx6qsabred with 2019.07-rc2
>
> Hi Peng,
>
> On Thu, May 16, 2019 at 11:17 PM Peng Fan wrote:
> >
> > Hi Fabio
> >
> > Booting from SD3, it works for me. See below log.
> >
> > "
> > U-Boot SPL 2019.07-rc2 (May 17 2019 - 10:24:45 +0800) Trying to boot
> > from MMC1
Hi Peng,
On Thu, May 16, 2019 at 11:17 PM Peng Fan wrote:
>
> Hi Fabio
>
> Booting from SD3, it works for me. See below log.
>
> "
> U-Boot SPL 2019.07-rc2 (May 17 2019 - 10:24:45 +0800)
> Trying to boot from MMC1
>
>
> U-Boot 2019.07-rc2 (May 17 2019 - 10:24:45 +0800)
>
> CPU: Freescale
-Original Message-
From: Bin Meng
Sent: 2019年5月16日 19:58
To: Xiaowei Bao
Cc: M.h. Lian ; Z.q. Hou ; Mingkai
Hu ; Hongbo Wang ; York Sun
; u-boot@lists.denx.de; Jiafei Pan
Subject: [EXT] Re: [U-Boot] [PATCHv2 1/2] PCI: layerscape: Add Support for
ls2088 PCIe EP mode
Caution: EXT
Hi Lukasz,
On Thu, May 16, 2019 at 6:49 PM Lukasz Majewski wrote:
> Please find following repository with DM/DTS conversion for TPC70 imx6q
> board (it also has SPL DM conversion working - board boots from SD
> card and eMMC):
>
> https://github.com/lmajewski/u-boot-dfu/commits/DM-SPL-TPC70
>
>
Hi Fabio
Booting from SD3, it works for me. See below log.
"
U-Boot SPL 2019.07-rc2 (May 17 2019 - 10:24:45 +0800)
Trying to boot from MMC1
U-Boot 2019.07-rc2 (May 17 2019 - 10:24:45 +0800)
CPU: Freescale i.MX6Q rev1.5 996 MHz (running at 792 MHz)
CPU: Automotive temperature grade (-40C
Thank all of you who commented on my question.
@Laszlo, I agree to the criteria that you mentioned.
good user base is a crucial factor for security code.
@Paolo, I have had no idea about license term issues. You're right.
@Heinrich, thank you for pointing out gnutls. I'm stilling
Tom, Wolfgang,
Thank you for your inputs.
On Thu, May 16, 2019 at 02:18:03PM +0200, Wolfgang Denk wrote:
> Dear Akashi Takahiro,
>
> In message <20190516115636.GA8052@fireball> you wrote:
> >
> > Can you give me an example of U-Boot code which comes from linux (or
> > other projects) and is
On 5/17/19 12:10 AM, Lukasz Majewski wrote:
> This commit extends the struct clk to provide information regarding the
> clock rate.
> As a result the clock tree traversal is performed at most once, and further
> reads are using the cached value.
>
> Signed-off-by: Lukasz Majewski
>
> ---
>
>
On 5/17/19 12:10 AM, Lukasz Majewski wrote:
> This patch describes the design decisions considerations and taken approach
> for porting in a separate documentation entry.
>
> Signed-off-by: Lukasz Majewski
>
> ---
>
> Changes in v4:
> - New patch
>
> Changes in v3: None
>
>
This commit adds the clk_get_by_id() function, which is responsible
for getting the udevice with matching clk->id. Such approach allows
re-usage of inherit DM list relationship for the same class (UCLASS_CLK).
As a result - we don't need any other external list - it is just enough
to look for
This commit provides sandbox unit test for clk_get_by_id() method.
To test it default test clocks setup had to be adjusted to emulate
structure similar to clocks in the Common Clock Framework [CCF] (for
iMX devices).
The clk_get_by_id() relies on dev->driver_data having the pointer to
struct
Up till now the fixed rate clock ('osc') has been added to UCLASS_CLK
without declaring struct clk. As a result it was only accessible by
iterating the udevice's uclass list.
This is a problem for clock code, which operates on pointers to struct
clk (like clk_get_rate()), not udevices.
After
This commit brings the files from Linux kernel to provide clocks support
as it is used on the Linux kernel with common clock framework [CCF] setup.
The directory structure has been preserved. The ported code only supports
reading information from PLL, MUX, Divider, etc and enabling/disabling
the
This commit extends the struct clk to provide information regarding the
clock rate.
As a result the clock tree traversal is performed at most once, and further
reads are using the cached value.
Signed-off-by: Lukasz Majewski
---
Changes in v4:
- None
Changes in v3: None
include/clk.h | 2 ++
This commit provides sandbox unit test for clk_get_parent_rate() method.
For testing the default test clocks setup had to be adjusted to emulate
structure similar to clocks in the Common Clock Framework [CCF]
(for iMX devices).
The clk_get_parent_rate() relies on dev->driver_data having the
This commit adds the clk_get_parent_rate() function, which is responsible
for getting the rate of parent clock.
Unfortunately, u-boot's DM support for getting parent is different
(the parent relationship is in udevice) than the one in common clock
framework (CCF) in Linux.
To alleviate this
This commit adds the clk_get_parent() function, which is responsible
for getting the parent's struct clock pointer.
U-boot's DM support for getting parent is different (the parent
relationship is in udevice) than the one in common clock framework (CCF)
in Linux. To obtain the pointer to struct
If the CLK_GET_RATE_NOCACHE flag is set - the clk_get_parent_rate()
provides recalculated clock value without considering the cache setting.
This may be necessary for some clocks tightly coupled with power domains
(i.e. imx8), and prevents from reading invalid cached values.
Signed-off-by:
This check requires the struct clk passed to .get_rate() to be always
cleared out as any clock with valid ID causes -EINVAL return value.
The return code of fixed clocks shall always be returned.
Signed-off-by: Lukasz Majewski
---
Changes in v4:
- None
Changes in v3: None
There is no UCLASS_CLOCK uclass defined. Instead we do use the UCLASS_CLK.
Signed-off-by: Lukasz Majewski
Reviewed-by: Simon Glass
---
Changes in v4:
- None
Changes in v3: None
include/clk.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/clk.h b/include/clk.h
This commit extends the struct clk to provide information regarding the
flags related to this devices.
Those flags are clk device agnostic and indicate generic features
(like e.g. CLK_GET_RATE_NOCACHE - the need to always recalculate the rate).
Signed-off-by: Lukasz Majewski
---
Changes in
This patch series brings the files from Linux kernel to provide clocks support
as it is used on the Linux kernel with common clock framework [CCF] setup.
This series also fixes several problems with current clocks and provides
sandbox tests for functions addded to clk-uclass.c file.
Repository:
This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.
Signed-off-by: Lukasz Majewski
---
Changes in v4:
- New patch
Changes in v3: None
doc/imx/clk/ccf.txt | 83 +
1 file
On Thu, 16 May 2019 16:40:56 -0300
Fabio Estevam wrote:
> On Thu, May 16, 2019 at 2:32 PM Fabio Estevam
> wrote:
> >
> > Hi,
> >
> > I get the following error when trying to boot mx6q sabresd with
> > 2019.07-rc2:
> >
> > U-Boot SPL 2019.07-rc2 (May 16 2019 - 14:28:55 -0300)
> > Trying to boot
This is a generic implementation. Add CONFIG_SYSRESET_CMD_POWEROFF
to signal when we need it. Enable it from the STPMIC1 config and in
sandbox.
The config flag is transitionary, that is it can be removed after all
poweroff implementations use sysreset, and just have CMD_POWEROFF depend
on
Based on snooping around the linux kernel rk8xx driver.
Tested on an ASUS C201.
Signed-off-by: Urja Rannikko
---
drivers/power/pmic/Kconfig | 1 +
drivers/power/pmic/rk8xx.c | 62 +++---
include/power/rk8xx_pmic.h | 4 +++
3 files changed, 63 insertions(+), 4
It seems that SYSRESET_POWER_OFF was added recently, and all previous code
used SYSRESET_POWER for poweroff. SYSRESET_POWER is supposed to be a
PMIC-level power cycle, not a poweroff.
Signed-off-by: Urja Rannikko
---
v2: Do not change STPMIC1 driver (thats actually SYSRESET_POWER)
Note: I didnt
Not checking the parameters may lead reading or writing from NULL.
Implement the parameter checks prescribed in the UEFI spec.
Signed-off-by: Heinrich Schuchardt
---
lib/efi_loader/efi_boottime.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git
Introduce a framework that allows loading the System Firmware (SYSFW)
binary as well as the associated configuration data from an image tree
blob named "sysfw.itb" from an FS-based boot media using the FS loader
framework.
Signed-off-by: Andreas Dannenberg
---
arch/arm/mach-k3/Kconfig
From: Lokesh Vutla
In order to load the sysfw.itb from an MMC device, clocks should be hard
coded to the same value as ROM configured frequency. Clock updates cannot
happen at this point as SYSFW is not yet available. So updating the clock
properties for MMC nodes.
Furthermore, create a new
To give us more flexibility using the FS loader eliminate the need of
always having to use the ENV to configure the block device but rather
allow the respective block device and partition to be setup through
platform data.
Signed-off-by: Andreas Dannenberg
---
drivers/misc/fs_loader.c | 17
On some platform we have sufficient memory available early on to allow
setting up and using a basic BSS prior to relocation. In order to be
able to preserve data written to BSS during early startup add a Kconfig
option allowing to skip the clearing of the BSS section during setting
up of the final
Enable all the relevant configs that enables support for loading
sysfw via MMC.
Signed-off-by: Andreas Dannenberg
---
configs/am65x_hs_evm_r5_defconfig | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/configs/am65x_hs_evm_r5_defconfig
b/configs/am65x_hs_evm_r5_defconfig
Enable all the relevant configs that enables support for loading
sysfw via MMC.
Signed-off-by: Andreas Dannenberg
---
configs/am65x_evm_r5_defconfig | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/configs/am65x_evm_r5_defconfig b/configs/am65x_evm_r5_defconfig
index
In order to be able to use more advanced driver functionality which often
relies on having BSS initialized during early boot prior to relocation
several things need to be in place:
1) Memory needs to be available for BSS to use. For this, we locate BSS
at the top of the MCU SRAM area, with the
Switch to using the full malloc scheme in post-relocation SPL to allow
better utilization of available memory for example by allowing memory
to get freed. Initially allocate a 16MB-sized region in DDR starting
at address 0x8400 for this purpose.
Signed-off-by: Andreas Dannenberg
---
This series provides an alternative solution to the previously posted
series titled "System Firmware Loader for TI K3 family SoCs" [1] using
the existing FS loader driver rather than extending the SPL loader
framework like the original patch series. Unlike the original series,
it does not support
To better support use cases where we want to side-load additional files
during SPL execution from MMC media export the SPL MMC framework function
for determining the MMC boot device index.
Signed-off-by: Andreas Dannenberg
---
common/spl/spl_mmc.c | 2 +-
include/spl.h| 2 ++
2 files
We would like to use the driver even without power domains being
specified for cases such as during early boot when the required power
domains have already gotten enabled by the SoC's boot ROM and such
explicit initialization is not needed and possible.
Signed-off-by: Andreas Dannenberg
Use the System Firmware (SYSFW) loader framework to load and start
the SYSFW as part of the AM654 early initialization sequence. While
at it also initialize the WKUP_UART0 pinmux as it is used by SYSFW
to print diagnostic messages.
Signed-off-by: Andreas Dannenberg
---
On 4/19/19 9:00 AM, Jagan Teki wrote:
Hello Jagan,
> Dropped
> - sh_spi driver
> - CONFIG_SH_SPI,SH_SPI_BASE
>
> Dropped due to:
> - no active updates
> - no dm conversion
> - multiple pings for asking dm-conversion
> - no response for dm converted patch
> - driver-model migration expiry
>
>
Hi Tom,
On Wed, May 15, 2019 at 11:16:43AM -0400, Tom Rini wrote:
> On Tue, May 07, 2019 at 12:25:29PM -0500, Andreas Dannenberg wrote:
>
> > TI K3 SoCs like the AM654x devices are fundamentally dependent on a
> > firmware called SYSFW (System Firmware) being loaded into the dedicated
> > DMSC
On 09/05/19 3:07 AM, Andreas Dannenberg wrote:
> This series adds the pieces needed to fully configure the TI AM654x EVM
> and its associated (optional) daughtercards using a GPIO-based card
> presence detection scheme. It then reads out and parses any I2C EEPROM
> data present on any such
Add myself as an SH maintainer.
Signed-off-by: Marek Vasut
Cc: Nobuhiro Iwamatsu
Cc: Tom Rini
---
MAINTAINERS | 1 +
1 file changed, 1 insertion(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index c41bc89fe9..00f271d181 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -698,6 +698,7 @@ S:
After the conversion to DM there is no need to have mmc initialization
code inside U-Boot proper.
Remove the unneeded code.
Signed-off-by: Fabio Estevam
---
board/freescale/mx6sabresd/mx6sabresd.c | 44 -
1 file changed, 44 deletions(-)
diff --git
With CONFIG_SPL_DM enabled the board does not boot:
U-Boot SPL 2019.07-rc2 (May 16 2019 - 14:28:55 -0300)
Trying to boot from MMC1
spl: could not find mmc device 0. error: -19
SPL: failed to boot from all boot devices
### ERROR ### Please RESET the board ###
Remove such option, so that we can
With the conversion to DM we should select the pinctrl driver.
Signed-off-by: Fabio Estevam
---
configs/mx6sabresd_defconfig | 2 ++
1 file changed, 2 insertions(+)
diff --git a/configs/mx6sabresd_defconfig b/configs/mx6sabresd_defconfig
index 5c2d055561..f7ba632b2a 100644
---
According to the UEFI spec InstallMultipleProtocolInterfaces() must check
if a device path has already been installed. In this case it must return
EFI_ALREADY_STARTED.
Cf. UEFI SCT II 2.6 A (2017),
3.3.16 InstallMultipleProtocolInterfaces(), 5.1.3.16.1.
Signed-off-by: Heinrich Schuchardt
---
On Thu, May 16, 2019 at 2:32 PM Fabio Estevam wrote:
>
> Hi,
>
> I get the following error when trying to boot mx6q sabresd with 2019.07-rc2:
>
> U-Boot SPL 2019.07-rc2 (May 16 2019 - 14:28:55 -0300)
> Trying to boot from MMC1
> spl: could not find mmc device 0. error: -19
> SPL: failed to boot
Hi Tom,
On Thu, May 16, 2019 at 10:47:30AM -0500, Andreas Dannenberg wrote:
> Hi Tom,
>
> On Wed, May 15, 2019 at 05:50:31PM -0400, Tom Rini wrote:
> > On Wed, May 15, 2019 at 04:39:22PM -0500, Andreas Dannenberg wrote:
> > > Hi Tom,
> > >
> > > On Wed, May 15, 2019 at 11:17:22AM -0400, Tom
Hi Jagan,
On Thu, May 16, 2019 at 2:37 PM Jagan Teki wrote:
>
> On Thu, May 16, 2019 at 11:02 PM Fabio Estevam wrote:
> >
> > Hi,
> >
> > I get the following error when trying to boot mx6q sabresd with 2019.07-rc2:
> >
> > U-Boot SPL 2019.07-rc2 (May 16 2019 - 14:28:55 -0300)
> > Trying to boot
On 16/05/19 09:23, Sughosh Ganu wrote:
>
> > It's also license-incompatible with U-Boot's GPLv2 I think. I guess
> > grub can use it because GPLv3 and Apache v2 can be combined just fine.
> > Reusing Linux's code seems like the best match.
> >
> > Paolo
> >
>
> You
Hello,
I have recently been investigating u-boot for booting VxWorks on to the APU and
an RPU core of a ZU+ ZCU102 Rev1.1. For some general context, it would be ideal
if it were possible to run u-boot on an RPU core to boot VxWorks on to the APU
and RPU, instead of running u-boot on the APU.
I have accustom hardware uses IMX6q which has a intel i210 ethernet controller
connected to PCIE of IMX6Q , I had configured the PCIE in Kernel and enabled
the e1000 driver , I am able to enumerate the controller ping works fine, etc.
whereas when I try to configure the controller and PCIE 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:
> >
On Thu, May 16, 2019 at 11:02 PM Fabio Estevam wrote:
>
> Hi,
>
> I get the following error when trying to boot mx6q sabresd with 2019.07-rc2:
>
> U-Boot SPL 2019.07-rc2 (May 16 2019 - 14:28:55 -0300)
> Trying to boot from MMC1
> spl: could not find mmc device 0. error: -19
No device.
Is it
In EFI 1.10 a version of the Unicode collation protocol using ISO 639-2
language codes existed. This protocol is not part of the UEFI specification
any longer. Unfortunately it is required to run the UEFI Self Certification
Test (SCT) II, version 2.6, 2017. So we implement it here for the sole
Rename variables to make it clear they refer to the Unicode collation
protocol identified by the EFI_UNICODE_PROTOCOL2_GUID.
Signed-off-by: Heinrich Schuchardt
---
include/efi_loader.h | 4 ++--
lib/efi_loader/Kconfig | 4 ++--
lib/efi_loader/Makefile
In EFI 1.10 a version of the Unicode collation protocol using ISO 639-2
language codes existed. This protocol is not part of the UEFI specification
any longer. Unfortunately it is required to run the UEFI Self Certification
Test (SCT) II, version 2.6, 2017. So we implement it here for the sole
Hi,
I get the following error when trying to boot mx6q sabresd with 2019.07-rc2:
U-Boot SPL 2019.07-rc2 (May 16 2019 - 14:28:55 -0300)
Trying to boot from MMC1
spl: could not find mmc device 0. error: -19
SPL: failed to boot from all boot devices
### ERROR ### Please RESET the board ###
I
Hi Tim,
Missed aggressive timeline, first RFC series should be out in three weeks
time as priority.
Regards,
Suneel
On Tue, May 7, 2019 at 8:10 AM Tim Harvey wrote:
>
> On Fri, Mar 22, 2019 at 11:23 AM Suneel Garapati
wrote:
> >
> > Hi Tim,
> >
> > First series will be out week ending April
The TPM specification says that the EXPECT_DATA bit is not valid until
the VALID bit is set. Wait for that bit to be set. Fixes problems with
Ifineon SPI TPM.
Signed-off-by: Roman Kapl
---
drivers/tpm/tpm2_tis_spi.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git
On Thu, May 16, 2019 at 5:14 PM Matthias Brugger wrote:
> On 30/04/2019 21:07, Heinrich Schuchardt wrote:
> >
> > I think we should have a u-class for hardware RNGs as one source of entropy.
>
> Anyone working on this already?
Not me.
> If not I can have a look.
green_light_on(); // :)
> It
Hi Tom,
On Wed, May 15, 2019 at 05:50:31PM -0400, Tom Rini wrote:
> On Wed, May 15, 2019 at 04:39:22PM -0500, Andreas Dannenberg wrote:
> > Hi Tom,
> >
> > On Wed, May 15, 2019 at 11:17:22AM -0400, Tom Rini wrote:
> > > On Tue, May 07, 2019 at 12:25:33PM -0500, Andreas Dannenberg wrote:
> > >
>
On 03/05/2019 01:07, Timothy Froehlich wrote:
> We've had a problem the past few days that we've traced back to U-Boot.
> We're generating images using Yocto with Mender's update routine. The issue
> is the first time a clean image is booted on a Raspberry Pi, the mac
> address gets permanently
From: Hannes Schmelzer
The first memory location of ${dtbaddr} may be still valid after a warm
restart of the machine and 'fdt addr ${dtbaddr}' doesn't recognize that
the cfgscript didn't run properly and fallback mechanism with copying
the internal fdt ${fdtcontroladdr} to ${dtbaddr} doesn't
On 30/04/2019 21:07, Heinrich Schuchardt wrote:
> On 4/30/19 4:53 AM, Eugeniu Rosca wrote:
>> The random uuid values (enabled via CONFIG_RANDOM_UUID=y) on our
>> platform are always the same. Below is consistent on each cold boot:
>>
>> => ### interrupt autoboot
>> => env default -a; gpt
Hi Mario, you are right. I shall send a new patch chaning pci_init to
use the _check functions after I test it.
Marek
On Wed, 15 May 2019 07:05:43 +0200
Mario Six wrote:
> Hi Marek,
>
> On Tue, May 14, 2019 at 5:12 PM Marek Behún
> wrote:
> >
> > The documentation for the uclass_next_device
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
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 short is that
> when
> using -mcpu=xscale gcc-8.x throws
fat_itr_root() allocates fatbuf so we free it on the exit path, if
the function fails we should not free it, check the return value
and skip freeing if the function fails.
Signed-off-by: Andrew F. Davis
---
fs/fat/fat.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git
Hi Kever,
sorry for the delay.
Will do within the next couple of days.
Thanks,
Christoph
On 09.05.19 12:46, Kever Yang wrote:
> Hi Christoph,
>
> Could you re-send this patch with re-base on top of master,
>
> because there is a conflict when I try to merge it.
>
>
> Thanks,
> - Kever
>
This commit updates the doc/README.falcon regarding Falcon boot on
NOR flash memories.
This code is used by MCCMON6 board - so for more details please refer to
configs/mccmon6_nor_defconfig.
Signed-off-by: Lukasz Majewski
---
Changes in v2:
- Fix the description
- Update the comit message
This option will provide the offset in the parallel NOR flash memory to,
which the falcon boot data is stored.
Signed-off-by: Lukasz Majewski
---
Changes in v2: None
cmd/Kconfig | 8
1 file changed, 8 insertions(+)
diff --git a/cmd/Kconfig b/cmd/Kconfig
index 4dec190a38..b4b10cce00
The CMD_SPL_NAND_OFS description was a bit misleading, has
been updated.
Signed-off-by: Lukasz Majewski
---
Changes in v2: None
cmd/Kconfig | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/cmd/Kconfig b/cmd/Kconfig
index 7bc275f135..4dec190a38 100644
--- a/cmd/Kconfig
+++
This commit makes the CMD_SPL_NAND_OFS only visible when we use NAND
memory.
Before this change it was present when only CMD_SPL was enabled (and
would stay when board with other falcon boot medium is used).
Signed-off-by: Lukasz Majewski
---
Changes in v2: None
cmd/Kconfig | 1 +
1 file
On Thu, May 16, 2019 at 10:33 AM Lukasz Majewski wrote:
> CONFIG_CMD_SPL_NAND_OFSOffset in NAND where the parameters area was
> saved.
>
> +CONFIG_CMD_SPL_NOR_OFS Offset in NOR where the parameters area was saved.
> + (Please refer to MCCMON6 board's
This commit updates the doc/README.falcon regarding Falcon boot on
NOR flash memories.
Signed-off-by: Lukasz Majewski
---
doc/README.falcon | 3 +++
1 file changed, 3 insertions(+)
diff --git a/doc/README.falcon b/doc/README.falcon
index 9a7f0bc235..204f4b12b6 100644
--- a/doc/README.falcon
This option will provide the offset in the parallel NOR flash memory to,
which the falcon boot data is stored.
Signed-off-by: Lukasz Majewski
---
cmd/Kconfig | 8
1 file changed, 8 insertions(+)
diff --git a/cmd/Kconfig b/cmd/Kconfig
index 4dec190a38..b4b10cce00 100644
---
This commit makes the CMD_SPL_NAND_OFS only visible when we use NAND
memory.
Before this change it was present when only CMD_SPL was enabled (and
would stay when board with other falcon boot medium is used).
Signed-off-by: Lukasz Majewski
---
cmd/Kconfig | 1 +
1 file changed, 1 insertion(+)
The CMD_SPL_NAND_OFS description was a bit misleading, has
been updated.
Signed-off-by: Lukasz Majewski
---
cmd/Kconfig | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/cmd/Kconfig b/cmd/Kconfig
index 7bc275f135..4dec190a38 100644
--- a/cmd/Kconfig
+++ b/cmd/Kconfig
@@
On Thu, May 16, 2019 at 9:18 PM Bin Meng wrote:
>
> On Wed, Apr 17, 2019 at 8:42 PM Christian Gmeiner
> wrote:
> >
> > coreboot makes it possible to add own entries into coreboot's
> > table at a per mainboard basis. As there might be some custom
> > ones it makes sense to provide a way to
On Wed, Apr 17, 2019 at 8:42 PM Christian Gmeiner
wrote:
>
> coreboot makes it possible to add own entries into coreboot's
> table at a per mainboard basis. As there might be some custom
> ones it makes sense to provide a way to process them.
>
> Signed-off-by: Christian Gmeiner
> ---
>
1 - 100 of 174 matches
Mail list logo
