Hi Matwey,
Please add commit message for the patch.
On 05/08/2019 02:34 PM, Matwey V. Kornilov wrote:
> Signed-off-by: Matwey V. Kornilov
> ---
> configs/rock64-rk3328_defconfig | 91
> +
> 1 file changed, 91 insertions(+)
> create mode 100644 confi
On Thu, May 16, 2019 at 1:47 AM Andre Przywara wrote:
>
> The first USB controller on the A64 SoC shares a PHY with the OTG
> controller. Reportedly to avoid problems with the VBUS regulator under
> Linux, we don't link OHCI0/EHCI0 to the USB PHY in the A64 .dtsi file.
>
> However on boards which
Hi,
On 11/05/2019 20:24, Krzysztof Kozlowski wrote:
> The CONFIG_POWER and CONFIG_POWER_I2C were introduced in
> include/configs/exynos5-common.h in commit 19bd3aaa5991 ("exynos5: fix
> build break by adding CONFIG_POWER") and then it propagated up to
> include/configs/arndale.h. However before t
Hi,
On 11/05/2019 20:24, Krzysztof Kozlowski wrote:
> The CONFIG_DM_I2C_COMPAT was introduced in
> include/configs/exynos5-common.h in commit 189d80166b31 ("exynos5:
> enable dm i2c") and then it propagated up to configs/arndale_defconfig.
> However since beginning the Arndale board (Exynos5250) w
Hi,
On 11/05/2019 20:24, Krzysztof Kozlowski wrote:
> Arndale board has an Asix AX88760 USB 2.0 Hub and Fast Ethernet combo.
> The appropriate driver for it is USB_ETHER_ASIX.
>
> The mistake probably came from misinterpretation of commit e9954b867ce0
> ("usb: eth: add ASIX AX88179 DRIVER") which
This patch series updates mccmon6 configuration to remove some "removal"
warnings (i.e. disables the USB related code).
It also on purpose disables gigabig ethernet, as this board works on
10/100 Mib environments.
Patches applicable on top of master branch:
SHA1: 5b4b680cfe29a67171ccbe439c66374c
This comment is a leftover from the Kconfig CONFIG_*MTD* move.
Signed-off-by: Lukasz Majewski
---
include/configs/mccmon6.h | 2 --
1 file changed, 2 deletions(-)
diff --git a/include/configs/mccmon6.h b/include/configs/mccmon6.h
index a1774c027a..b97373512f 100644
--- a/include/configs/mccmon
mccmon6 works in 10/100 MiB Ethernet environment, so disabling 1GiB support
improves robustness of the network after power up (as one don't need to
wait for autoneg).
Signed-off-by: Lukasz Majewski
---
include/configs/mccmon6.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/confi
The IMX6Q based MCCMON6 is not using USB for any purpose.
Signed-off-by: Lukasz Majewski
---
configs/mccmon6_nor_defconfig | 2 --
configs/mccmon6_sd_defconfig | 2 --
include/configs/mccmon6.h | 5 -
3 files changed, 9 deletions(-)
diff --git a/configs/mccmon6_nor_defconfig b/configs
Hi Urja,
>
> 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
> ---
> Note: I didnt touch the test/dm/sysreset.c code yet,
Hi Fabien
On 5/14/19 11:20 AM, Fabien Dessenne wrote:
> On STM32 family, the IPCC peripheral allows the communication
> between 2 processors offering doorbells mechanism.
>
> Signed-off-by: Fabien Dessenne
> Signed-off-by: Loic Pallardy
> ---
> drivers/mailbox/Kconfig | 7 ++
> drivers/
On 5/14/19 11:20 AM, Fabien Dessenne wrote:
> Activate the ipcc mailbox for stm32mp15 configs.
>
> Signed-off-by: Fabien Dessenne
> ---
> configs/stm32mp15_basic_defconfig | 2 ++
> configs/stm32mp15_trusted_defconfig | 2 ++
> 2 files changed, 4 insertions(+)
>
> diff --git a/configs/stm32
On 5/14/19 11:20 AM, Fabien Dessenne wrote:
> Signed-off-by: Fabien Dessenne
> ---
> MAINTAINERS | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 33fd465..5523c4a 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -301,6 +301,7 @@ S:Maintained
On 5/14/19 11:20 AM, Fabien Dessenne wrote:
> Add IPCC mailbox support on stm32mp157 eval and disco boards.
>
> Signed-off-by: Fabien Dessenne
> ---
> arch/arm/dts/stm32mp157a-dk1.dts | 4
> arch/arm/dts/stm32mp157c-ed1.dts | 4
> arch/arm/dts/stm32mp157c.dtsi| 13 +
Add CONFIG_SPL_MMC_SUPPORT and CONFIG_SPL_NAND_SUPPORT for
Kconfig selection.
Signed-off-by: Jagan Teki
Signed-off-by: Shyam Saini
---
configs/imx6dl_icore_nand_defconfig | 1 +
configs/imx6dl_mamoj_defconfig | 1 +
configs/imx6q_icore_nand_defconfig | 1 +
configs/imx6q_logic_defco
Right now, i.MX6 supports single image variants like u-boot-with-spl.imx
and u-boot-nand-with-spl.imx for MMC and NAND boots respectively.
But, it requires an explicit argument passing to 'make' to build
these images, like 'make u-boot-with-spl.imx'
This patch would fix this by selecting BUILD_T
On 16.05.19 08:48, Weijie Gao wrote:
The initr_watchdog is currently placed before initr_serial. The
initr_watchdog calls printf and printf finally calls ops->putc of a serial
driver.
However, gd->cur_serial_dev points to a udevice allocated in board_f. The
gd->cur_serial_dev->driver->ops->putc
On 16.05.19 08:49, Weijie Gao wrote:
U-Boot passes timeout in milliseconds for ops->start. However the driver
treats this value as seconds. This will cause an overflow on writing wdt
register.
This patch divides the timeout by 1000 before writing to wdt register.
Reviewed-by: Ryder Lee
Signed-
On 16.05.19 08:49, Weijie Gao wrote:
The watchdog of mediatek chips is enabled by bootrom before u-boot is
running. Previously we choose to enable the wdt driver only to disable the
watchdog hardware.
Now wdt service is enabled by default. The function arch_misc_init which is
only used to disabl
On Thu, 9 May 2019 01:13:15 +
Peng Fan wrote:
> > Subject: Re: [i.MX8MM+CCF 11/41] clk: fixed_rate: export
> > clk_fixed_rate
> >
> > On Wed, 8 May 2019 07:45:39 +
> > Peng Fan wrote:
> >
> > > > -Original Message-
> > > > From: Lukasz Majewski [mailto:lu...@denx.de]
> > > >
On Thu, 2019-05-16 at 10:21 +0200, Stefan Roese wrote:
> On 16.05.19 08:48, Weijie Gao wrote:
> > The initr_watchdog is currently placed before initr_serial. The
> > initr_watchdog calls printf and printf finally calls ops->putc of a serial
> > driver.
> >
> > However, gd->cur_serial_dev points to
At present the GEM ethernet on SiFive Unleashed board can only work
in 1000 Mbps mode. With a 10/100 Mbps connection it just fails to do
any network communication.
This adds a new GEMGXL clock driver to adjust the clock settings per
the connection speed so that 10/100 Mbps works.
Bin Meng (4):
This adds a clock driver to support the GEMGXL management IP block
found in FU540 SoCs to control GEM TX clock operation mode for
10/100/1000 Mbps.
Signed-off-by: Bin Meng
---
drivers/clk/sifive/Kconfig | 7 +
drivers/clk/sifive/Makefile | 2 ++
drivers/clk/sifive/gemgxl-mgmt.c
At present the link speed change callback is a nop. According to
macb device tree bindings, an optional "tx_clk" is used to clock
the ethernet controller's TX_CLK under different link speed.
In 10/100 MII mode, transmit logic must be clocked from a free
running clock generated by the external PHY.
This updates DM version macb_linkspd_cb() signature for future
expansion, eg: adding an implementation for link speed changes.
Signed-off-by: Bin Meng
---
drivers/net/macb.c | 22 +-
1 file changed, 21 insertions(+), 1 deletion(-)
diff --git a/drivers/net/macb.c b/drivers/n
Enable the new GEMGXL MGMT driver so that GEM 10/100 Mbps works now.
Signed-off-by: Bin Meng
---
board/sifive/fu540/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/board/sifive/fu540/Kconfig b/board/sifive/fu540/Kconfig
index f464379..8eb5e30 100644
--- a/board/sifive/fu540/Kconfig
The initr_watchdog is currently placed before initr_serial. The
initr_watchdog calls printf and printf finally calls ops->putc of a serial
driver.
However, gd->cur_serial_dev points to a udevice allocated in board_f. The
gd->cur_serial_dev->driver->ops->putc points the the code region before
reloc
U-Boot passes timeout in milliseconds for ops->start. However the driver
treats this value as seconds. This will cause an overflow on writing wdt
register.
This patch divides the timeout by 1000 before writing to wdt register.
Reviewed-by: Stefan Roese
Reviewed-by: Ryder Lee
Signed-off-by: Weij
The watchdog of mediatek chips is enabled by bootrom before u-boot is
running. Previously we choose to enable the wdt driver only to disable the
watchdog hardware.
Now wdt service is enabled by default. The function arch_misc_init which is
only used to disable wdt is no longer needed.
Reviewed-by
On Thu, 16 May 2019 08:15:23 +0100
Peter Robinson wrote:
Hi Peter,
> On Thu, May 16, 2019 at 1:47 AM Andre Przywara wrote:
> >
> > The first USB controller on the A64 SoC shares a PHY with the OTG
> > controller. Reportedly to avoid problems with the VBUS regulator under
> > Linux, we don't lin
> Subject: Re: [i.MX8MM+CCF 11/41] clk: fixed_rate: export clk_fixed_rate
>
> On Thu, 9 May 2019 01:13:15 +
> Peng Fan wrote:
>
> > > Subject: Re: [i.MX8MM+CCF 11/41] clk: fixed_rate: export
> > > clk_fixed_rate
> > >
> > > On Wed, 8 May 2019 07:45:39 +
> > > Peng Fan wrote:
> > >
> > >
On Thu, 16 May 2019 10:34:38 +0800
Icenowy Zheng wrote:
Hi Icenowy,
thanks for having a look!
> 于 2019年5月16日 GMT+08:00 上午9:26:29, Andre Przywara 写到:
> >The Allwinner H6 pin controller is not really special, at least not
> >when it comes to normal GPIO operation.
> >
> >Add the H6 compatible st
This series enables support for boot from SATA on the SolidRun Clearfog
platform.
Patches 1-3 are preparations for the addition of loading U-Boot main image from
raw SATA device. They make spl sata code independent of board macros and
specific kconfig symbols.
Patch 4 adds to SPL generic support
Add sensible defaults for the FAT partition selection and the main
U-Boot image file name. This allows spl_sata to build when the board
headers does not select them explicitly.
Signed-off-by: Baruch Siach
---
common/spl/spl_sata.c | 8
1 file changed, 8 insertions(+)
diff --git a/commo
SPL does not initialize mbus_dram_info. Don't change the ahci mbus
settings of the ROM. This allows the ahci to work in SPL.
Signed-off-by: Baruch Siach
---
arch/arm/mach-mvebu/cpu.c | 4
1 file changed, 4 insertions(+)
diff --git a/arch/arm/mach-mvebu/cpu.c b/arch/arm/mach-mvebu/cpu.c
ind
The init_sata() routine is only present when DM_SCSI is not enabled.
Don't call init_sata() when DM_SCSI is enabled. The code will fall back
to scsi_scan() in this case.
Signed-off-by: Baruch Siach
---
common/spl/spl_sata.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/c
Allow the code to build when FS_FAT is not enabled, and thus
spl_load_image_fat() is not provided.
A subsequent patch should add alternative raw access U-Boot main image
load method.
Signed-off-by: Baruch Siach
---
common/spl/spl_sata.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions
Support load of the U-Boot image from raw SATA disk sector. This is
equivalent to load from MMC raw sector.
Signed-off-by: Baruch Siach
---
common/spl/Kconfig| 14 ++
common/spl/spl_sata.c | 29 +
2 files changed, 43 insertions(+)
diff --git a/common/
Add the required Kconfig and macro definitions to allow boot from SATA
on Armada 38x systems.
Signed-off-by: Baruch Siach
---
arch/arm/mach-mvebu/Kconfig| 5 +
arch/arm/mach-mvebu/Makefile | 3 +++
arch/arm/mach-mvebu/include/mach/soc.h | 2 ++
arch/arm/mach-mvebu/spl.c
See the offset of U-Boot in raw SATA disk to the same value as the MMC
offset. That is 0x140 sectors from the beginning of the SPL, which is
0x141 sectors from the beginning of the device (after the MBR sector).
Signed-off-by: Baruch Siach
---
include/configs/clearfog.h | 2 +-
1 file changed, 1
Enable SATA peripherals in SPL to allow boot from SATA.
Signed-off-by: Baruch Siach
---
arch/arm/dts/armada-388-clearfog-u-boot.dtsi | 8
1 file changed, 8 insertions(+)
diff --git a/arch/arm/dts/armada-388-clearfog-u-boot.dtsi
b/arch/arm/dts/armada-388-clearfog-u-boot.dtsi
index a126
Enable SATA peripherals in SPL to allow boot from SATA.
Signed-off-by: Baruch Siach
---
arch/arm/dts/armada-388-clearfog-u-boot.dtsi | 8
1 file changed, 8 insertions(+)
diff --git a/arch/arm/dts/armada-388-clearfog-u-boot.dtsi
b/arch/arm/dts/armada-388-clearfog-u-boot.dtsi
index a126
Add the required Kconfig and macro definitions to allow boot from SATA
on Armada 38x systems.
Signed-off-by: Baruch Siach
---
arch/arm/mach-mvebu/Kconfig| 5 +
arch/arm/mach-mvebu/Makefile | 3 +++
arch/arm/mach-mvebu/include/mach/soc.h | 2 ++
arch/arm/mach-mvebu/spl.c
On Thu, 16 May 2019 09:58:17 +
Peng Fan wrote:
> > Subject: Re: [i.MX8MM+CCF 11/41] clk: fixed_rate: export
> > clk_fixed_rate
> >
> > On Thu, 9 May 2019 01:13:15 +
> > Peng Fan wrote:
> >
> > > > Subject: Re: [i.MX8MM+CCF 11/41] clk: fixed_rate: export
> > > > clk_fixed_rate
> > > >
Document the main U-Boot image offset when booting from SATA disk on the
Clearfog board.
Signed-off-by: Baruch Siach
---
board/solidrun/clearfog/README | 6 ++
1 file changed, 6 insertions(+)
diff --git a/board/solidrun/clearfog/README b/board/solidrun/clearfog/README
index 0b0e98de90a0..61
Hi u-boot list, Stefan,
Please ignore this patch and the next. The patch series starts at the
0/9 cover letter.
Sorry for the spam.
baruch
On Thu, May 16 2019, Baruch Siach wrote:
> Add the required Kconfig and macro definitions to allow boot from SATA
> on Armada 38x systems.
>
> Signed-off-b
On Sat, 27 Apr 2019 at 12:03, Heinrich Schuchardt
wrote:
> On 4/27/19 7:31 AM, Paolo Bonzini wrote:
> >
> I've done porting linux's pkcs7/x509 parsers and they work well
> with my UEFI secure boot patch, but I'm still looking for other
> options
> as well.
>
> * openssl
>
Dear Tom,
The following changes since commit 5b4b680cfe29a67171ccbe439c66374cb31faca3:
Prepare v2019.07-rc2 (2019-05-15 15:58:48 -0400)
are available in the git repository at:
git://git.denx.de/u-boot-samsung master
for you to fetch changes up to f4b2ab97ed37ea6b202aaa951d31dab9187e3720:
Dear Sughosh Ganu,
In message
you wrote:
>
> There is LibreSSL as well which is a fork of openssl. Guess that too should
> be fine. What would be the more preferred solution here. The relevant bits
> can be imported from the kernel code into u-boot, or there can be a
> solution with linking of
On Thu, May 16, 2019 at 12:39:02PM +0200, Wolfgang Denk wrote:
Hello Wolfgang,
Thanks for taking the time with this
> >
> > There is LibreSSL as well which is a fork of openssl. Guess that too should
> > be fine. What would be the more preferred solution here. The relevant bits
> > can be import
From: Xiaowei Bao
The VF_BARn_REG register's Prefetchable and Type bit fields
are overwritten by a write to VF's BAR Mask register.
workaround: Before writing to the VF_BARn_MASK_REG register,
write 0b to the PCIE_MISC_CONTROL_1_OFF register.
Signed-off-by: Xiaowei Bao
---
v2:
- Add the NXP co
From: Xiaowei Bao
Signed-off-by: hongbo.wang
Signed-off-by: Minghuan Lian
Signed-off-by: Xiaowei Bao
---
v2:
- Add the NXP copyright and make the function readability.
drivers/pci/pcie_layerscape.c | 117 +++--
drivers/pci/pcie_layerscape.h | 19 +-
On Thu, May 16, 2019 at 01:45:54PM +0300, Ilias Apalodimas wrote:
> On Thu, May 16, 2019 at 12:39:02PM +0200, Wolfgang Denk wrote:
> Hello Wolfgang,
>
> Thanks for taking the time with this
> > >
> > > There is LibreSSL as well which is a fork of openssl. Guess that too
> > > should
> > > be fi
Hi Tom,
> > On Thu, May 16, 2019 at 12:39:02PM +0200, Wolfgang Denk wrote:
> > Hello Wolfgang,
> >
> > Thanks for taking the time with this
> > > >
> > > > There is LibreSSL as well which is a fork of openssl. Guess that too
> > > > should
> > > > be fine. What would be the more preferred solut
Hi,
On Thu, May 16, 2019 at 7:44 AM Patrick DELAUNAY
wrote:
>
> Hi Urja,
>
> > - if (type != SYSRESET_POWER)
> > + if (type != SYSRESET_POWER_OFF)
> > return -EPROTONOSUPPORT;
>
> In fact in the next part of the code, we are supporting
> only SYSRESET_POWER (reset with PMIC1
Hi,
On Tue, May 14, 2019 at 4:07 PM Patrice CHOTARD wrote:
>
> Hi Urja
>
> This patch doesn't compile using the stm32mp15_trusted_defconfig
> configuration:
>
> ...
> LD drivers/pinctrl/built-in.o
> LD drivers/core/built-in.o
> LD drivers/mmc/built-in.o
> LD drivers/bu
Hi Tom,
On Thu, May 16, 2019 at 07:13:59AM -0400, Tom Rini wrote:
> On Thu, May 16, 2019 at 01:45:54PM +0300, Ilias Apalodimas wrote:
> > On Thu, May 16, 2019 at 12:39:02PM +0200, Wolfgang Denk wrote:
> > Hello Wolfgang,
> >
> > Thanks for taking the time with this
> > > >
> > > > There is Libr
Hi,
On Thu, May 16, 2019 at 7:02 PM Xiaowei Bao wrote:
>
> From: Xiaowei Bao
>
> Signed-off-by: hongbo.wang
> Signed-off-by: Minghuan Lian
> Signed-off-by: Xiaowei Bao
> ---
> v2:
> - Add the NXP copyright and make the function readability.
>
> drivers/pci/pcie_layerscape.c | 117
> ++
On Thu, May 16, 2019 at 11:57 AM Wen He wrote:
>
> The video driver causes a link failure when config VIDEO built-in,
>
> drivers/video/cfb_console.c:2022: undefined reference to `video_hw_init'
>
> Adding a empty video hw init to slove the build issue, now the board
> does not support display any
On Thu, May 16, 2019 at 08:56:40PM +0900, AKASHI Takahiro wrote:
> Hi Tom,
>
> On Thu, May 16, 2019 at 07:13:59AM -0400, Tom Rini wrote:
> > On Thu, May 16, 2019 at 01:45:54PM +0300, Ilias Apalodimas wrote:
> > > On Thu, May 16, 2019 at 12:39:02PM +0200, Wolfgang Denk wrote:
> > > Hello Wolfgang,
Hi,
On Wed, Apr 10, 2019 at 4:50 PM Yuantian Tang wrote:
>
> Ls1028a Soc is based on Layerscape Chassis Generation 3.2
> architecture with features:
> 2 ARM v8 Cortex-A72 cores, CCI400, SEC, DDR3L/4, LCD, GPU, TSN
> ENETC, 2 USB 3.0, 2 eSDHC, 2 FlexCAN, 2 SPI, SATA, 8 I2C controllers,
> 6 LPUA
On Thu, May 16, 2019 at 2:48 PM Wen He wrote:
>
> The video driver causes a link failure when config VIDEO built-in,
>
> drivers/video/cfb_console.c:2022: undefined reference to `video_hw_init'
>
> Adding an empty video hw init to slove the build issue, now the board
> does not support display any
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 regularly synced (or updated) with the origin?
> Who maintains that? and how?
Comes from Linux: a ton... Kconfig, Linker
Some times we want to relocate spl code to dram after dram
initialization or relocate spl code to a high memory to avoid
code overid.
For example on Rockchip armv8 platform, we run with boot flow
TPL->SPL->ATF->U-Boot.
TPL run in sram and is responsible for dram initialization.
SPL run from the st
Move CONFIG_SPL_RELOC_TEXT_BASE and CONFIG_SPL_SKIP_RELOCATE
to Kconfig, so we can reuse it for cross other platform.
Signed-off-by: Andy Yan
---
Changes in v2: None
common/spl/Kconfig | 13 +
configs/BSC9131RDB_NAND_SYSCLK100_defconfig | 2 ++
configs/B
Some times we want to relocate spl code to dram after dram
initialization or relocate spl code to a high memory to avoid
code overid.
For example on Rockchip armv8 platform, we run with boot flow
TPL->SPL->ATF->U-Boot.
TPL run in sram and is responsible for dram initialization.
SPL run from the st
Some times we want to relocate spl code to dram after dram
initialization or relocate spl code to a high memory to avoid
code overid.
For example on Rockchip armv8 platform, we run with boot flow
TPL->SPL->ATF->U-Boot.
TPL run in sram and is responsible for dram initialization.
SPL run from the st
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,
but if you do CONFIG_DM_I2C_COMPAT=y When compiling,
there will be the following warning
Hi Simon,
On Thu, May 9, 2019 at 10:57 AM Simon Glass wrote:
>
> At present the iasl tool (Intel ACPI (Advanced Configuration and Power
> Interface) Source Language compiler) is called in such a way that it uses
> the source directory for its temporary files.
>
> This means we end up with these f
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
> ---
> arch/x86
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 proces
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(+)
d
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
@@ -325
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
--- a/cmd/Kconf
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
+
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 configuraiton)
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 chang
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 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
do
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 1
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
>
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 a
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 a
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
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 sa
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 writ
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 cat
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 s
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 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 co
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
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 2
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 haven'
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
purp
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
purp
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 DM-S
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
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 UBo
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
1 - 100 of 176 matches
Mail list logo