On 22.10.18 08:22, AKASHI Takahiro wrote:
> On Mon, Oct 22, 2018 at 01:40:05PM +0900, AKASHI Takahiro wrote:
>> The current scenario for default UEFI booting, scan_dev_for_efi, has
>> several issues:
>> * load dtb dynamically even if its loacation (device) is not the same
>> as BOOTEFI_NAME
On Sat, Oct 20, 2018 at 6:11 AM Lukas Auer
wrote:
>
> Store the hart ID and device tree passed by the prior boot stage (in a0
> and a1) in registers s0 and s1. Replace one use of s1 in start.S to
> avoid overwriting it.
>
> The device tree is also stored in memory to make it available to u-boot
On Sat, Oct 20, 2018 at 6:11 AM Lukas Auer
wrote:
>
> The mstatus CSR includes WPRI (writes preserve values, reads ignore
> values) fields and must therefore not be set to zero without preserving
> these fields. It is not apparent why mstatus is set to zero here since
> it is not required for
On Sat, Oct 20, 2018 at 6:11 AM Lukas Auer
wrote:
>
> QEMU provides a device tree, which is passed to u-boot using register
nits: U-Boot
> a1. We are now able to directly select the device tree with the
> configuration CONFIG_OF_PRIOR_STAGE. Replace the hard-coded address in
> qemu-riscv with
On 22.10.18 06:37, AKASHI Takahiro wrote:
> On Thu, Oct 18, 2018 at 10:46:36AM +0200, Alexander Graf wrote:
>>
>>
>> On 18.10.18 07:48, AKASHI Takahiro wrote:
>>> On Wed, Oct 17, 2018 at 10:43:22AM +0200, Alexander Graf wrote:
On 17.10.18 09:32, AKASHI Takahiro wrote:
> With
On 10/22/18 2:26 AM, Icenowy Zheng wrote:
> 在 2018-05-17四的 09:16 +0100，Andre Przywara写道：
>> This series tries to solve three issues we currently have on
>> Allwinner boards:
>> - The DRAM sizing routine can only cope with power-of-two sized DRAM.
>> - The DRAM sizing routine steps through all
From: Rick Chen
AndeStar V5 provide mcache_ctl register which can configure
I/D cache as enabled or disabled.
This CSR will be encapsulated by CONFIG_NDS_V5.
If you want to configure cache on AndeStar V5
AE350 platform. YOu can enable [*] AndeStar V5 ISA support
by make menuconfig.
Hi Lukas,
On Sat, Oct 20, 2018 at 6:09 AM Lukas Auer
wrote:
>
> Add Kconfig entries for the C (compressed instructions) and A (atomic
> instructions) ISA extensions. Only the C ISA extension is selectable.
> This matches the configuration in Linux.
>
> The Kconfig entries are not used yet. A
Hi Lukas,
On Sat, Oct 20, 2018 at 6:09 AM Lukas Auer
wrote:
>
> Use the new Kconfig entries to construct the ISA string for the -march
> compiler flag. The -mabi compiler flag is selected based on the base
> integer instruction set.
>
> With this change, the C (compressed instructions) ISA
Hi Lukas,
On Sat, Oct 20, 2018 at 6:10 AM Lukas Auer
wrote:
>
> RISC-V u-boot reimplements the generic io functions from
nits: U-Boot
> asm-generic/io.h. Remove the redundant implementation and include the
> generic io.h instead.
>
> Signed-off-by: Lukas Auer
> ---
>
>
On Sat, Oct 20, 2018 at 6:10 AM Lukas Auer
wrote:
>
> Only the first four exception codes are defined. Add the missing
> exception codes from the definition in RISC-V Privileged Architecture
> Version 1.10.
>
> Signed-off-by: Lukas Auer
> ---
>
> arch/riscv/lib/interrupts.c | 13 -
>
On Sat, Oct 20, 2018 at 6:10 AM Lukas Auer
wrote:
>
> Undefined exception codes currently lead to an out-of-bounds array
> access. Prevent this by treating undefined exception codes as
> "reserved".
>
> Signed-off-by: Lukas Auer
> ---
>
> arch/riscv/lib/interrupts.c | 8 ++--
> 1 file
Hi Lukas,
On Sat, Oct 20, 2018 at 6:10 AM Lukas Auer
wrote:
>
> Replace the barrier functions in arch/riscv/include/asm/io.h with those
> defined in barrier.h, which is imported from Linux. This version is
> modified to remove the include statement of asm-generic/barrier.h, which
> is not
On Sat, Oct 20, 2018 at 6:10 AM Lukas Auer
wrote:
>
> The labels nmi_vector, trap_vector and handle_reset in start.S are not
> used for RISC-V. Remove them.
>
> While we are here, also remove the code from the beginning of start.S,
> which stores the contents of a2 to memory. Only registers a0
Hi Lukas,
On Sat, Oct 20, 2018 at 6:10 AM Lukas Auer
wrote:
>
> CONFIG_INIT_CRITICAL is deprecated and not used for RISC-V. Remove it.
>
> Signed-off-by: Lukas Auer
> ---
>
> arch/riscv/cpu/start.S | 11 ---
> 1 file changed, 11 deletions(-)
>
Please see my patch which does more :)
Hi Rajat,
On 17.10.18 13:52, Rajat Srivastava wrote:
Hi Stefan
Sorry for top-posting.
Why can't we read SFDP parameters from flash and auto-detect
3-byte/4-byte addressing mode?
Using address width information we can support both types of flash
i.e. flashes supporting 3-byte addressing mode
Hi Lukas,
On Sat, Oct 20, 2018 at 6:10 AM Lukas Auer
wrote:
>
> Move the target selection into a separate file (Kconfig.board) to avoid
> clutter once we support more boards.
>
> Signed-off-by: Lukas Auer
> ---
>
> arch/riscv/Kconfig | 17 ++---
> arch/riscv/Kconfig.board |
Hi Lukas,
On Sat, Oct 20, 2018 at 6:10 AM Lukas Auer
wrote:
>
> RISC-V has two code models, medium low (medlow) and medium any (medany).
> Medlow limits addressable memory to a single 2 GiB range between the
> absolute addresses -2 GiB and +2 GiB. Medany limits addressable memory
> to any single
On Sat, Oct 20, 2018 at 6:10 AM Lukas Auer
wrote:
>
> Enable the -fdata-sections compiler option for RISC-V. Buildman reports
> the binary size decrease from this as 8365.3 bytes.
>
> Signed-off-by: Lukas Auer
> ---
>
> arch/riscv/config.mk | 3 ++-
> 1 file changed, 2 insertions(+), 1
Hi Lukas,
On Sat, Oct 20, 2018 at 6:08 AM Lukas Auer
wrote:
>
> Ignore all device tree binaries in arch/riscv/dts.
I don't think this patch is necessary.
>
> Signed-off-by: Lukas Auer
> ---
>
> arch/riscv/dts/.gitignore | 1 +
> 1 file changed, 1 insertion(+)
> create mode 100644
Hi Lukas,
On Sat, Oct 20, 2018 at 6:10 AM Lukas Auer
wrote:
>
> Start.S uses both tabs and spaces after instructions. Fix this by only
nits: start.S
> using tabs after instructions.
>
> Signed-off-by: Lukas Auer
> ---
>
> arch/riscv/cpu/start.S | 322 -
Hi Lukas,
On Sat, Oct 20, 2018 at 6:10 AM Lukas Auer
wrote:
>
> The machine trap-vector base address (mtvec) must be aligned on a 4-byte
> boundary. Add the necessary align directive to trap_entry.
>
I don't think this explicit alignment is needed because the
instructions before trap_entry are
On Mon, Oct 22, 2018 at 01:40:05PM +0900, AKASHI Takahiro wrote:
> The current scenario for default UEFI booting, scan_dev_for_efi, has
> several issues:
> * load dtb dynamically even if its loacation (device) is not the same
> as BOOTEFI_NAME binary's, (reported by Alex)
> * invoke 'bootmgr'
On Sat, Oct 20, 2018 at 6:09 AM Lukas Auer
wrote:
>
> CONFIG_PHYS_64BIT should be enabled on RV64I systems. Select it.
>
> Signed-off-by: Lukas Auer
> ---
>
> arch/riscv/Kconfig | 1 +
> 1 file changed, 1 insertion(+)
>
Reviewed-by: Bin Meng
___
Hi Lukas,
On Sat, Oct 20, 2018 at 6:09 AM Lukas Auer
wrote:
>
> RISC-V defines the base integer instruction sets as RV32I and RV64I.
> Rename CPU_RISCV_32 and CPU_RISCV_64 to ARCH_RV32I and ARCH_64I to match
ARCH_RV64I
> this convention.
>
> Signed-off-by: Lukas Auer
> ---
>
>
On Sat, Oct 20, 2018 at 6:09 AM Lukas Auer
wrote:
>
> Signed-off-by: Lukas Auer
> ---
>
> dts/Makefile | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
Reviewed-by: Bin Meng
___
U-Boot mailing list
U-Boot@lists.denx.de
On Sat, Oct 20, 2018 at 6:08 AM Lukas Auer
wrote:
>
> Ignore tools/prelink-riscv.
>
> Signed-off-by: Lukas Auer
> ---
>
> tools/.gitignore | 1 +
> 1 file changed, 1 insertion(+)
>
Reviewed-by: Bin Meng
___
U-Boot mailing list
U-Boot@lists.denx.de
Hi Lukas,
On Sat, Oct 20, 2018 at 6:10 AM Lukas Auer
wrote:
>
> The RISC-V arch incorrectly uses 32-bit instead of 64-bit variables in
> several places. Fix this.
> In addition, BITS_PER_LONG is set to 64 on RV64I systems.
>
> Signed-off-by: Lukas Auer
> ---
>
> arch/riscv/include/asm/io.h
On Sat, Oct 20, 2018 at 6:10 AM Lukas Auer
wrote:
>
> Implement the functions invalidate_icache_range() and
> invalidate_icache_all().
>
> RISC-V does not have instructions for explicit cache-control. The
> functions in this patch are implemented with the memory ordering
> instruction for
On Sat, Oct 20, 2018 at 6:10 AM Lukas Auer
wrote:
>
> Hang on unhandled exceptions to prevent execution in a faulty state.
>
> Signed-off-by: Lukas Auer
> ---
>
> arch/riscv/lib/interrupts.c | 2 ++
> 1 file changed, 2 insertions(+)
>
Reviewed-by: Bin Meng
i2c_get_chip_for_busnum() really should check the presence of the chip on
the bus. Most of the users of this function assume that this is done.
Signed-off-by: Jean-Jacques Hiblot
---
Changes in v3:
- removed commit introducing dm_i2c_probe_device(). Instead probe the
presence of the chip on
DM_I2C_COMPAT is a compatibility layer that allows using the non-DM I2C
API when DM_I2C is used. The goal is to eventually remove DM_I2C_COMPAT
when all I2C "clients" have been migrated to use the DM API.
This a step in that direction for the TI based platforms.
Build tested with buildman:
It is currently not possible to include the support to remove devices in
the SPL. This is however needed by platforms that re-select their dtb after
DM is initialized; they need to remove all the previously bound devices
before triggering a scan of the new DT.
Add a Kconfig option to be able to
In some cases it may be useful to be able to change the fdt we have been
using and use another one instead. For example, the TI platforms uses an
EEPROM to store board information and, based on the type of board,
different dtbs are used by the SPL. When DM_I2C is used, a first dtb must
be used
When changing some MIPS configs from CONFIG_OF_EMBED to
CONFIG_OF_SEPARATE, I ran into this compile issue since SPL is not
enabled. The fix is to guard the header with the
CONFIG_SPL_LIBCOMMON_SUPPORT preprocessor symbol.
It seems that the is not needed even when SPL is enabled, but
I'm not
When the "w1 bus" command is used with no bus master present
a data abort may occur.
This is because uclass_first_device() returns zero, but sets the output
struct udevice pointer to NULL in the no device found case.
Fix w1_get_bus() to account for this and return an error code
as is expected by
Data abort was occurring when using "w1 bus" with a DS24B33 present.
The abort occurred in the ds24xxx_probe() because the struct w1_device
pointer was NULL. This is because that structure is allocated by
the parent device uclass (by .per_child_platdata_auto_alloc_size)
and thus the correct
On Mon, Oct 22, 2018 at 04:12:52PM +0200, Jean-Jacques Hiblot wrote:
> am57xx configs uses DM_I2C both in SPL and u-boot.
> Remove code for non-DM I2C support.
>
> Signed-off-by: Jean-Jacques Hiblot
Reviewed-by: Tom Rini
--
Tom
signature.asc
Description: PGP signature
On Mon, Oct 22, 2018 at 04:12:45PM +0200, Jean-Jacques Hiblot wrote:
> If DM_I2C is used , the I2C controllers must be registered as U_BOOT_DEVICE
> because OF_CONTROL is not used in the SPL.
>
> Signed-off-by: Jean-Jacques Hiblot
Reviewed-by: Tom Rini
--
Tom
signature.asc
Description:
On Mon, Oct 22, 2018 at 04:12:43PM +0200, Jean-Jacques Hiblot wrote:
> From: Vignesh R
>
> Move away from SoC specific headers to handle different register layout.
> Instead use driver data to get appropriate register layouts like in the
> kernel. While at it, perform some mostly cosmetic
This config is mostly identical to the Macchiatobin one
(mvebu_mcbin-88f8040_defconfig) with only the default device-tree
changed.
Signed-off-by: Baruch Siach
---
This patch depends on the Clearfog GT 8K DT patch.
https://patchwork.ozlabs.org/patch/985828/
---
configs/clearfog_gt_8k_defconfig
On Mon, Oct 22, 2018 at 04:12:42PM +0200, Jean-Jacques Hiblot wrote:
> Those platforms need CONFIG_SPL_DM_SEQ_ALIAS because they enable both
> DM_I2C and SPL_DM. Without CONFIG_SPL_DM_SEQ_ALIAS, it is not possible to
> get the I2C bus with i2c_get_chip_for_busnum().
>
> Signed-off-by:
From: Vignesh R
Move away from SoC specific headers to handle different register layout.
Instead use driver data to get appropriate register layouts like in the
kernel. While at it, perform some mostly cosmetic alignment/cleanup in
the functions being updated.
Signed-off-by: Vignesh R
Signed-off-by: Jean-Jacques Hiblot
Reviewed-by: Simon Glass
---
Changes in v3: None
Changes in v2: None
arch/arm/dts/am437x-gp-evm-u-boot.dtsi | 4
arch/arm/dts/omap5-u-boot.dtsi | 4
2 files changed, 8 insertions(+)
diff --git a/arch/arm/dts/am437x-gp-evm-u-boot.dtsi
If DM_I2C is used , the I2C controllers must be registered as U_BOOT_DEVICE
because OF_CONTROL is not used in the SPL.
Signed-off-by: Jean-Jacques Hiblot
---
Changes in v3: None
Changes in v2: None
arch/arm/mach-omap2/am33xx/board.c | 15 +++
1 file changed, 15 insertions(+)
diff
To reset the DM after a new dtb is loaded, we need to call dm_uninit()
and then dm_init(). This fails however because gd->dm_root is not nullified
by dm_uninit().
Fixing it by setting gd->dm_root in dm_uninit().
Signed-off-by: Jean-Jacques Hiblot
Reviewed-by: Simon Glass
---
Changes in v3:
Hi Stefan,
Stefan Roese writes:
> On 18.10.18 13:51, Baruch Siach wrote:
>> From: Rabeeh Khoury
>>
>> The SolidRun Clearfog GT-8K is based on Armada 8040.
>>
>> https://wiki.solid-run.com/doku.php?id=products:a8040:clearfoggt8k
>>
>> Signed-off-by: Rabeeh Khoury
>> Signed-off-by: Baruch Siach
Hi Alison,
I get a build error when I try to build the vf610 boards. This is not
due to recent patches for the board, but it is implicitly done on the
current tree after other branches were merged, because the resulting
binary becomes bigger.
In fact, it exceeds the maximum size:
arm:
On 22/10/2018 18:16, Lukasz Majewski wrote:
Hi Jean-Jacques,
Hi Lukasz,
gentle ping on the status on this series.
Do we have tested by from somebody from RockChip community?
I haven't seen anything on the ML. I pinged Kever Yang earlier today
about it.
JJ
JJ
On 09/10/2018 16:29,
On Mon, Oct 22, 2018 at 04:12:39PM +0200, Jean-Jacques Hiblot wrote:
> The implementation of the EEPROM commands does not support the DM I2C API.
> Prevent compilation breakage by not enabling it if the non-DM API is not
> available (if DM_I2C is used without DM_I2C_COMPAT)
>
> Signed-off-by:
On 15.10.18 12:16, Baruch Siach wrote:
The dm_gpio_set_value() call sets the logical level of the GPIO signal.
That is, it takes the GPIO_ACTIVE_{LOW,HIGH} property into account. The
driver needs to assert the reset, and then deassert it. Not the other
way around.
Cc: Stefan Chulski
If OF_CONTROL is not enabled and DM_SEQ_ALIAS is enabled, we must
assign an alias (requested sequence number) to devices that belongs to a
class with the DM_UC_FLAG_SEQ_ALIAS flag. Otherwise
uclass_find_device_by_seq() cannot be used to get/probe a device. In
particular i2c_get_chip_for_busnum()
Those platforms need CONFIG_SPL_DM_SEQ_ALIAS because they enable both
DM_I2C and SPL_DM. Without CONFIG_SPL_DM_SEQ_ALIAS, it is not possible to
get the I2C bus with i2c_get_chip_for_busnum().
Signed-off-by: Jean-Jacques Hiblot
Reviewed-by: Felix Brack
Tested-by: Felix Brack
---
Changes in v3:
This series remove the usage of the DM_I2C_COMPAT option for all the ti
platforms. It also takes this opportunity to not disable DM_I2C in the SPL.
There are a couples of issues to fix:
- CMD_EEPROM does not support the DM API. Fixed by removing this option
when DM_I2C is used without
am57xx configs uses DM_I2C both in SPL and u-boot.
Remove code for non-DM I2C support.
Signed-off-by: Jean-Jacques Hiblot
---
Changes in v3: None
Changes in v2: None
board/ti/am57xx/board.c | 36 +++-
1 file changed, 3 insertions(+), 33 deletions(-)
diff --git
On 15.10.18 12:16, Baruch Siach wrote:
The default Linux PHY reset delay is 10ms. This is also the requirement
for Marvell 88E151x PHYs, which are likely to be used with this Ethernet
MAC.
Cc: Stefan Chulski
Signed-off-by: Baruch Siach
---
drivers/net/mvpp2.c | 2 +-
1 file changed, 1
Those driver are not DM drivers per se (not using the PMIC/regulator
framework) and are using the legacy I2C API. Make them compatible with
the DM_I2C API.
This impacts the following drivers:
- palmas (used by am57xx/dra7xx evms)
- tps65218 (used by am43xx evms)
- tps65217 and tps65910 (used by
From: Andreas Dannenberg
The EEPROM reading in the board detection code is done through legacy
I2C functions which on platforms using DM_I2C this functionality is
provided via the CONFIG_DM_I2C_COMPAT layer. To allow newer platforms
to use the board detection code without relying on
On 10/12/18 07:45, Rajesh Bhagat wrote:
> Includes changes in u-boot framework to support TF-A for NXP Chassis 2
> platforms. A new defconfig is added namely ls*_tfa_defconfig which will
> be used for all boot sources when TF-A is used.
>
>
Add initial support for AM654 based EVM running on R5.
Signed-off-by: Lokesh Vutla
Signed-off-by: Andreas Dannenberg
---
board/ti/am65x/Kconfig| 24
include/configs/am65x_evm.h | 6 ++
include/configs/ti_armv7_common.h | 2 ++
3 files changed,
Update Makefiles to generate:
- tiboot3.bin: Image format that can be processed by ROM.
Below is the tiboot3.bin image format that is required by ROM:
+---+
| X509 |
| Certificate |
|
Signed-off-by: Lokesh Vutla
---
arch/arm/dts/k3-am65-main.dtsi | 51 +--
arch/arm/dts/k3-am65-mcu.dtsi| 18
arch/arm/dts/k3-am65-wakeup.dtsi | 46 ++
arch/arm/dts/k3-am65.dtsi| 54 ++-
Hi Lukas,
On Sat, Oct 20, 2018 at 6:08 AM Lukas Auer
wrote:
>
>
> This patch series includes general fixes and cleanup for RISC-V. It also
> adds support for booting Linux on qemu-riscv. At the moment, only
> single-core systems are supported. Support for multi-core systems will
> be added with
The build breaks because its not fitting the U-Boot binary into the ROM
image. So lets move VGA BIOS a bit to make room for the grown U-Boot
binary.
Signed-off-by: Stefan Roese
---
configs/theadorable-x86-conga-qa3-e3845-pcie-x4_defconfig | 2 +-
To allow bigger 64 bit prefetchable PCI regions in Linux, this patch
changes the base address and range of the ACPI area passed to Linux.
BayTrail can only physically access 36 bit of PCI address space. So
just chaning the range without changing the base address won't work
here, as 0xf..
This is needed for the PCIe hotplug to work correctly on some boards
with the newer Linux kernel versions.
Signed-off-by: Stefan Roese
Cc: Bin Meng
---
include/configs/theadorable-x86-common.h | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git
On 10/10/18 03:10, Breno Matheus Lima wrote:
> This patch set is restructuring and cleaning up the current i.MX documentation
> included in the U-Boot doc directory.
>
> The current i.MX documentation is in the root directory so we cannot easily
> check which one is i.MX related:
>
This allows the driver to be used without OF_CONTROL.
AM335x support DM_SPL but does not use SPL_OF_CONTROL. Enabling DM_I2C in
SPL thus requires that the omap I2C can be passed platdata.
Signed-off-by: Jean-Jacques Hiblot
---
Changes in v3: None
Changes in v2: None
This is required to take advantage of MULTI_DTB_FIT before relocation.
If it is too low, DM will be initialized only after relocation has
taken place. That is too late for the DRA7 because I2C DM is used before
the relocation to setup the voltages required, among other things, to
properly
The DRA7 platforms requires that the dtb used in the SPL really matches the
platform to have the best MMC performances.
To detect the board type/version an I2C EEPROM is read. This requires that
DM is initialized before the detection. As a consequence we must reset the
DM after the board
In order to use DM_I2C, we need to move the board detection after the
early SPL initialization.
Signed-off-by: Jean-Jacques Hiblot
---
Changes in v3: None
Changes in v2: None
arch/arm/mach-omap2/am33xx/board.c | 9 ++---
arch/arm/mach-omap2/hwinit-common.c | 5 ++---
2 files changed, 8
The implementation of the EEPROM commands does not support the DM I2C API.
Prevent compilation breakage by not enabling it if the non-DM API is not
available (if DM_I2C is used without DM_I2C_COMPAT)
Signed-off-by: Jean-Jacques Hiblot
Reviewed-by: Simon Glass
---
Changes in v3: None
Changes
Hi Joe,
On 15.10.18 23:45, Joe Hershberger wrote:
On Mon, Oct 8, 2018 at 8:50 AM Stefan Roese wrote:
This patch adds ethernet support for the Mediatek MT76xx SoC, including
a minimum setup of the integrated switch. This driver is loosly based on
the driver version included in this MediaTek
On 22/10/2018 10:48, Lars Povlsen wrote:
When changing some MIPS configs from CONFIG_OF_EMBED to
CONFIG_OF_SEPARATE, I ran into this compile issue since SPL is not
enabled. The fix is to guard the header with the
CONFIG_SPL_LIBCOMMON_SUPPORT preprocessor symbol.
It seems that the is not
Hi Lukasz,
gentle ping on the status on this series.
JJ
On 09/10/2018 16:29, Loic Devulder wrote:
On 9/25/18 11:03 AM, Jean-Jacques Hiblot wrote:
This series aims at bringing improvements to the dwc3_generic driver so
that it can be used by most of the platforms using the dwc3 controller.
Hi Baruch,
On 18.10.18 13:51, Baruch Siach wrote:
From: Rabeeh Khoury
The SolidRun Clearfog GT-8K is based on Armada 8040.
https://wiki.solid-run.com/doku.php?id=products:a8040:clearfoggt8k
Signed-off-by: Rabeeh Khoury
Signed-off-by: Baruch Siach
Is a dts file enough for a functional
Remove the last call to the non-DM I2C API.
Also remove the #undef CONFIG_DM_I2C_COMPAT because it is not defined
in the common header file anymore.
Signed-off-by: Jean-Jacques Hiblot
Reviewed-by: Felix Brack
Tested-by: Felix Brack
---
Changes in v3: None
Changes in v2:
- remove the
Hi Tom,
This fixed the QEMU x86_64 support which has been broken here and
here, e.g.: built with newer version GCC compiler, EFI loader
relocation, TSC as early timer. Now all issues have been addressed and
we can finally turn on build/testing for this target on travis-ci!
The following changes
On 22.10.18 16:30, Baruch Siach wrote:
Hi Stefan,
Stefan Roese writes:
On 18.10.18 13:51, Baruch Siach wrote:
From: Rabeeh Khoury
The SolidRun Clearfog GT-8K is based on Armada 8040.
https://wiki.solid-run.com/doku.php?id=products:a8040:clearfoggt8k
Signed-off-by: Rabeeh Khoury
Hi Jean-Jacques,
> Hi Lukasz,
>
> gentle ping on the status on this series.
Do we have tested by from somebody from RockChip community?
>
> JJ
>
>
> On 09/10/2018 16:29, Loic Devulder wrote:
> >
> > On 9/25/18 11:03 AM, Jean-Jacques Hiblot wrote:
> >> This series aims at bringing
On 10/12/18 07:45, Rajesh Bhagat wrote:
> Adds TFABOOT support and allows to pick QE firmware
> on basis of boot source.
>
> Signed-off-by: Pankit Garg
> Signed-off-by: Rajesh Bhagat
> ---
> Change in v4: None
>
>
> Change in v3:
On Mon, Oct 22, 2018 at 04:12:47PM +0200, Jean-Jacques Hiblot wrote:
> In order to use DM_I2C, we need to move the board detection after the
> early SPL initialization.
>
> Signed-off-by: Jean-Jacques Hiblot
Reviewed-by: Tom Rini
--
Tom
signature.asc
Description: PGP signature
On Mon, Oct 22, 2018 at 04:12:46PM +0200, Jean-Jacques Hiblot wrote:
> Signed-off-by: Jean-Jacques Hiblot
> Reviewed-by: Simon Glass
Reviewed-by: Tom Rini
--
Tom
signature.asc
Description: PGP signature
___
U-Boot mailing list
On Mon, Oct 22, 2018 at 04:12:57PM +0200, Jean-Jacques Hiblot wrote:
> The DRA7 platforms requires that the dtb used in the SPL really matches the
> platform to have the best MMC performances.
> To detect the board type/version an I2C EEPROM is read. This requires that
> DM is initialized before
On Mon, Oct 22, 2018 at 04:12:44PM +0200, Jean-Jacques Hiblot wrote:
> This allows the driver to be used without OF_CONTROL.
> AM335x support DM_SPL but does not use SPL_OF_CONTROL. Enabling DM_I2C in
> SPL thus requires that the omap I2C can be passed platdata.
>
> Signed-off-by: Jean-Jacques
On Mon, Oct 22, 2018 at 04:12:50PM +0200, Jean-Jacques Hiblot wrote:
> Remove the last call to the non-DM I2C API.
> Also remove the #undef CONFIG_DM_I2C_COMPAT because it is not defined
> in the common header file anymore.
>
> Signed-off-by: Jean-Jacques Hiblot
> Reviewed-by: Felix Brack
>
On Mon, Oct 22, 2018 at 08:42:32AM +0100, Alexander Graf wrote:
>
>
> On 22.10.18 08:22, AKASHI Takahiro wrote:
> > On Mon, Oct 22, 2018 at 01:40:05PM +0900, AKASHI Takahiro wrote:
> >> The current scenario for default UEFI booting, scan_dev_for_efi, has
> >> several issues:
> >> * load dtb
On Mon, Oct 22, 2018 at 07:58:29AM +0100, Alexander Graf wrote:
>
>
> On 22.10.18 06:37, AKASHI Takahiro wrote:
> > On Thu, Oct 18, 2018 at 10:46:36AM +0200, Alexander Graf wrote:
> >>
> >>
> >> On 18.10.18 07:48, AKASHI Takahiro wrote:
> >>> On Wed, Oct 17, 2018 at 10:43:22AM +0200, Alexander
> > On Sat, Oct 20, 2018 at 6:10 AM Lukas Auer
> > wrote:
> > >
> > > Enable the -fdata-sections compiler option for RISC-V. Buildman
> > > reports the binary size decrease from this as 8365.3 bytes.
> > >
> > > Signed-off-by: Lukas Auer
> > > ---
> > >
> > > arch/riscv/config.mk | 3 ++-
> > >
> > Subject: Re: [PATCH 09/30] riscv: move target selection into separate file
> >
> > Hi Lukas,
> >
> > On Sat, Oct 20, 2018 at 6:10 AM Lukas Auer
> > wrote:
> > >
> > > Move the target selection into a separate file (Kconfig.board) to
> > > avoid clutter once we support more boards.
> > >
> > >
Hi Hannes,
On Tue, Oct 23, 2018 at 5:12 AM Hannes Schmelzer wrote:
>
> This commit creates the freedom for boards to do nothing with the whole
> IRQ stuff on x86 during u-boot.
>
> This is especially important on older systems which have many legacy irq
> and no ACPI support within BIOS, they
On Mon, Oct 22, 2018 at 8:08 PM Stefan Roese wrote:
>
> To enable the root device selection (kernel cmd-line) via PARTUUID, this
> patch enables CMD_PART on all missing theadorable-x86 boards and
> changes the default environment to generate the root=PARTUUID string
> automatically.
>
> This
On Mon, Oct 22, 2018 at 8:08 PM Stefan Roese wrote:
>
> This is needed for the PCIe hotplug to work correctly on some boards
> with the newer Linux kernel versions.
>
> Signed-off-by: Stefan Roese
> Cc: Bin Meng
> ---
> include/configs/theadorable-x86-common.h | 3 +--
> 1 file changed, 1
On Mon, Oct 22, 2018 at 8:09 PM Stefan Roese wrote:
>
> The build breaks because its not fitting the U-Boot binary into the ROM
> image. So lets move VGA BIOS a bit to make room for the grown U-Boot
> binary.
>
> Signed-off-by: Stefan Roese
> ---
>
On Mon, Oct 22, 2018 at 8:08 PM Stefan Roese wrote:
>
> To allow bigger 64 bit prefetchable PCI regions in Linux, this patch
> changes the base address and range of the ACPI area passed to Linux.
> BayTrail can only physically access 36 bit of PCI address space. So
> just chaning the range
Hi Stefan
> -Original Message-
> From: Stefan Roese [mailto:s...@denx.de]
> Sent: Monday, October 22, 2018 12:45 PM
> To: Rajat Srivastava ; ja...@openedev.com;
> simon.k.r.goldschm...@gmail.com
> Cc: Ashish Kumar ; u-boot@lists.denx.de
> Subject: Re: [U-Boot] [PATCH v3] sf: Add auto
This series adds r5 build support for booting am654 evm.
There is still 1 step(loading system firmware) missing to complete
the full boot. This will be posted as a separate series.
Lokesh Vutla (10):
ram: Introduce K3 AM654 DDR Sub System driver
armv7R: K3: am654: Enable MPU regions
Hi Tom,
On Tue, Oct 9, 2018 at 3:47 PM Miquel Raynal wrote:
>
> Hi Bin,
>
> Bin Meng wrote on Mon, 8 Oct 2018 02:27:44 -0700:
>
> > Currently in pmecc_get_sigma(), the code tries to clear the memory
> > pointed by smu with wrong size 'sizeof(int16_t) * ARRAY_SIZE(smu)'.
> > Since smu is
On Mon, Oct 22, 2018 at 05:46:20PM +0800, Bin Meng wrote:
> Hi Simon,
>
> On Fri, Oct 19, 2018 at 8:10 PM Tom Rini wrote:
> >
> > On Thu, Oct 18, 2018 at 09:27:49PM -0600, Simon Glass wrote:
> > > Hi,
> > >
> > > On 17 October 2018 at 11:14, Stephen Warren wrote:
> > > > On 10/16/18 8:33 PM,
To enable the root device selection (kernel cmd-line) via PARTUUID, this
patch enables CMD_PART on all missing theadorable-x86 boards and
changes the default environment to generate the root=PARTUUID string
automatically.
This fixes problems that have been noticed on systems with multiple
1 - 100 of 226 matches
Mail list logo
