Hi Simon,
On Fri, Dec 29, 2017 at 4:13 AM, Simon Glass wrote:
> Hi Mario,
>
> On 20 December 2017 at 07:31, Mario Six wrote:
>> From: Mario Six
>>
>> To debug device tree issues involving 32- and 64-bit platforms, it is useful
>> to
>> have a generic 64-bit platform available.
>>
>> Add a vers
On 11.01.2018 17:20, Tom Rini wrote:
On Thu, Jan 11, 2018 at 07:55:03AM -0800, Simon Glass wrote:
Hi Lokesh,
On 11 January 2018 at 00:33, Lokesh Vutla wrote:
On Wednesday 10 January 2018 07:40 PM, Goldschmidt Simon wrote:
On Wed, 10/01/18 09:48, Lokesh Vutla wrote:
On Wednesday 10 January
On Mon, 2018-01-08 at 09:07 +0100, Lothar Waßmann wrote:
Hi Tom Rini,
> Hi,
>
> On Wed, 3 Jan 2018 08:46:09 + Chee, Tien Fong wrote:
> >
> > On Rab, 2017-12-27 at 13:04 +0800, tien.fong.c...@intel.com wrote:
> > Hi Lothar Waßmann,
> > >
> > > From: Tien Fong Chee
> > >
> > > This patchset
On Wed, 2017-12-27 at 13:04 +0800, tien.fong.c...@intel.com wrote:
Hi Tom Rini,
> From: Tien Fong Chee
>
> This patchset contains generic firmware loader which is very close to
> Linux
> firmware loader but for U-Boot framework. Generic firmware loader can
> be used
> load whatever into target lo
From: Siva Durga Prasad Paladugu
DDR less systems are possible for configuration like mini qspi
and making DDR region as normal memory may cause speculative
access which results u-boot hang if DDR is absent. So, this
patch fixes the issue by not making DDR memory region
entry into MMU table.
Fut
zc770-xm011 is also added and supported. Reflect this in README.
Signed-off-by: Michal Simek
---
doc/README.zynq | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/doc/README.zynq b/doc/README.zynq
index 451743f39eaa..cc5c0de21741 100644
--- a/doc/README.zynq
+++ b/doc/README
On 13.1.2018 21:48, Ezequiel Garcia wrote:
> NAND and QSPI devices are now supported, so mark
> them as such.
>
> Cc: Michal Simek
> Signed-off-by: Ezequiel Garcia
> ---
> doc/README.zynq | 7 +++
> 1 file changed, 3 insertions(+), 4 deletions(-)
>
> diff --git a/doc/README.zynq b/doc/READ
On 12.1.2018 16:33, Ezequiel Garcia wrote:
> Setup proper dependency in Kconfig for SPL_CLK.
> If SPL is not enabled, SPL_CLK shouldn't be selected.
>
> Cc: Michal Simek
> Signed-off-by: Ezequiel Garcia
> ---
> arch/arm/Kconfig | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff -
On 12.1.2018 18:01, York Sun wrote:
> On 01/12/2018 01:12 AM, Michal Simek wrote:
>> On 11.1.2018 20:36, York Sun wrote:
>>> On 12/27/2017 09:20 PM, Alison Wang wrote:
855873: An eviction might overtake a cache clean operation
Workaround: The erratum can be avoided by upgrading cache clea
Enable support for multiple loadable images in SEC firmware FIT image.
Signed-off-by: Sumit Garg
---
arch/arm/cpu/armv8/sec_firmware.c | 51 +++
1 file changed, 41 insertions(+), 10 deletions(-)
diff --git a/arch/arm/cpu/armv8/sec_firmware.c
b/arch/arm/cpu/a
On Mon, Jan 15, 2018 at 11:25:00AM +0800, Kever Yang wrote:
>Bryan,
>
>
>On 01/12/2018 11:10 PM, Bryan O'Donoghue wrote:
>>
>>
>>On 12/01/18 11:27, Philipp Tomsich wrote:
OP-TEE is an open source trusted OS, in armv7, its loading and
running are like this:
loading:
- SPL load both O
Hi Bryan,
On 01/12/2018 10:52 PM, Bryan O'Donoghue wrote:
This series adds a new OPTEE bootable image type to u-boot, which is
directly bootable with the bootm command.
There is already a TEE image type but, in this case the TEE firmware is
loaded into RAM, jumped into and then back out of.
T
Hi Bryan,
On Fri, Jan 12, 2018 at 02:52:15PM +, Bryan O'Donoghue wrote:
>This series adds a new OPTEE bootable image type to u-boot, which is
>directly bootable with the bootm command.
>
>There is already a TEE image type but, in this case the TEE firmware is
>loaded into RAM, jumped into and t
Bryan,
On 01/12/2018 11:10 PM, Bryan O'Donoghue wrote:
On 12/01/18 11:27, Philipp Tomsich wrote:
OP-TEE is an open source trusted OS, in armv7, its loading and
running are like this:
loading:
- SPL load both OP-TEE and U-Boot
running:
- SPL run into OP-TEE in secure mode;
- OP-TEE run into U
Dear Tom,
Could you pull these patches to u-boot/master?
Main topic is the support for HS200/UHS mode.
If there are any problem, let me know. After applying to u-boot/master, will
apply the other patches.
The following changes since commit f3dd87e0b98999a78e500e8c6d2b063ebadf535a:
Prepare v2
On Fri, Jan 12, 2018 at 9:01 PM, Andy Shevchenko
wrote:
> On Fri, 2018-01-12 at 17:00 +0800, Bin Meng wrote:
>> Hi Andy,
>>
>> On Thu, Jan 11, 2018 at 1:40 AM, Andy Shevchenko
>> wrote:
>> > New field acpi_rsdp_addr, which has been introduced in boot protocol
>> > v2.14 [1], in boot parameters te
On Fri, Jan 12, 2018 at 4:31 PM, Bin Meng wrote:
> On Thu, Jan 11, 2018 at 1:33 AM, Andy Shevchenko
> wrote:
>> The commit
>>
>> eece493a7ac1 ("cmd: qfw: bring ACPI generation code into qfw core")
>>
>> moves ACPI related code to another file and missed an update of
>> references in acpi_table.
On Fri, Jan 12, 2018 at 5:00 PM, Bin Meng wrote:
> On Thu, Jan 11, 2018 at 1:40 AM, Andy Shevchenko
> wrote:
>> The commit
>>
>> 20bfac0599bd ("x86: zImage: add Intel MID platforms support")
>>
>> introduced an assignment of subarch field in boot parameters, though
>> missed the right place of
On Fri, Jan 12, 2018 at 4:29 PM, Bin Meng wrote:
> On Thu, Jan 11, 2018 at 12:07 AM, Andy Shevchenko
> wrote:
>> ASL compiler warns:
>>
>> ASL board/intel/edison/dsdt.asl
>> board/intel/edison/dsdt.asl.tmp238: Method (_CRS, 0,
>> NotSerialized)
>> Remark 2120 - C
+ Adding Jaehoon, who is the U-Boot MMC maintainer.
On Sun, Jan 14, 2018 at 9:46 PM, Benoît Thébaudeau
wrote:
> Commit 4f425280fa71 ("mmc: fsl_esdhc: Allow all supported prescaler
> values") made it possible to set SYSCTL.SDCLKFS to 0 in SDR mode on
> i.MX, thus bypassing the SD clock frequency p
Commit 4f425280fa71 ("mmc: fsl_esdhc: Allow all supported prescaler
values") made it possible to set SYSCTL.SDCLKFS to 0 in SDR mode on
i.MX, thus bypassing the SD clock frequency prescaler, in order to be
able to get higher SD clock frequencies in some contexts. However, that
commit missed the fac
Add the config option `CONFIG_SPL_NAND_IDENT` for using the NAND chip ID list
to identify the NAND flash in SPL.
Signed-off-by: Jörg Krause
---
README | 4
drivers/mtd/nand/Makefile| 1 +
scripts/config_whitelist.txt | 1 +
3 files changed, 6 insertions(+)
diff --
For now, the existing SPL MXS NAND driver only supports to identify
ONFi-compliant NAND chips. In order to allow identifying
non-ONFi-compliant chips add `mxs_flash_full_ident()` which uses the
`nand_get_flash_type()` functionality from `nand_base.c` to lookup
for supported NAND chips in the chip I
The existing `mxs_flash_ident()` is limited to identify ONFi compliant
NAND chips only. In order to support non-ONFi NAND chips refactor the
function and rename it to `mxs_flash_onfi_ident()`.
A follow-up patch will add `mxs_flash_full_ident()` which allows to use
the chip ID list to lookup for su
`nand_get_flash_type()` allows identification of supported NAND flashs.
The function is useful in SPL (like mxs_nand_spl.c) to lookup for a NAND
flash (which does not support ONFi) instead of using nand_simple.c and
hard-coding all required NAND parameters.
Signed-off-by: Jörg Krause
---
drivers
RESEND because adding U-Boot NAND maintainer (Scott Wood) on Cc.
When adding SPL support to a custom i.MX6ULL board with Toshiba
TC58NVG0S3 NAND chip the MXS NAND SPL loader failed with "Failed to
identify". This reason is that the SPL MXS NAND driver only supports
ONFi-compliant NAND chips and th
On Sun, 2018-01-14 at 15:55 -0200, Fabio Estevam wrote:
> Hi Jörg,
>
> On Sun, Jan 14, 2018 at 2:14 PM, Jörg Krause
> wrote:
> > `nand_get_flash_type()` allows identification of supported NAND flashs.
> > The function is useful in SPL (like mxs_nand_spl.c) to lookup for a NAND
> > flash (which do
Hi Jörg,
On Sun, Jan 14, 2018 at 2:14 PM, Jörg Krause
wrote:
> `nand_get_flash_type()` allows identification of supported NAND flashs.
> The function is useful in SPL (like mxs_nand_spl.c) to lookup for a NAND
> flash (which does not support ONFi) instead of using nand_simple.c and
> hard-coding
On 12/01/2018 13:39, Bryan O'Donoghue wrote:
> Both usages of authenticate_image treat the result code as a simple binary.
> The command line usage of authenticate_image directly returns the result
> code of authenticate_image as a success/failure code.
>
> Right now when calling hab_auth_img and
The existing `mxs_flash_ident()` is limited to identify ONFi compliant
NAND chips only. In order to support non-ONFi NAND chips refactor the
function and rename it to `mxs_flash_onfi_ident()`.
A follow-up patch will add `mxs_flash_full_ident()` which allows to use
the chip ID list to lookup for su
For now, the existing SPL MXS NAND driver only supports to identify
ONFi-compliant NAND chips. In order to allow identifying
non-ONFi-compliant chips add `mxs_flash_full_ident()` which uses the
`nand_get_flash_type()` functionality from `nand_base.c` to lookup
for supported NAND chips in the chip I
When adding SPL support to a custom i.MX6ULL board with Toshiba
TC58NVG0S3 NAND chip the MXS NAND SPL loader failed with "Failed to
identify". This reason is that the SPL MXS NAND driver only supports
ONFi-compliant NAND chips and the mentioned Toshiba NAND chip is
non-ONFi.
This patch set makes `
`nand_get_flash_type()` allows identification of supported NAND flashs.
The function is useful in SPL (like mxs_nand_spl.c) to lookup for a NAND
flash (which does not support ONFi) instead of using nand_simple.c and
hard-coding all required NAND parameters.
Signed-off-by: Jörg Krause
---
drivers
Add the config option `CONFIG_SPL_NAND_IDENT` for using the NAND chip ID list
to identify the NAND flash in SPL.
Signed-off-by: Jörg Krause
---
README | 4
drivers/mtd/nand/Makefile| 1 +
scripts/config_whitelist.txt | 1 +
3 files changed, 6 insertions(+)
diff --
Without the patch a device path consisting only of an end node is
displayed as '/UNKNOWN(007f,00ff)'. It should be displayed as '/'.
Signed-off-by: Heinrich Schuchardt
---
lib/efi_loader/efi_device_path_to_text.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/lib/efi_loader/efi_device_pat
On 01/14/2018 04:27 AM, Heinrich Schuchardt wrote:
On the x86 architecture the e820 BIOS table defines reserved memory.
Mark it as EFI reserved memory.
Hello Simon, hello Bin,
is there a place in the x86 start up code where we could put the new
e820_memory_reservation() function?
Putting t
36 matches
Mail list logo
